Default SDLC Template

The default SDLC template (sdlc-v2-authored, slug sdlc-v2) is the production workflow that ships with every new Rensei project. It drives the full research → backlog-writer → development → QA → acceptance pipeline, supports both Linear and GitHub Issues as issue trackers, and applies a per-role capability matrix so each agent stage gets exactly the intelligence it needs.

What the template provides

The sdlc-v2 bundle ships one workflow (Rensei SDLC (v2)) with:

• Dual-tracker support - a Linear branch (full AgentSession surface, mention routing, status-driven dispatch) and a GitHub Issues branch (labels-as-state, comments). A single rensei.value.switch at the workflow level routes by trigger.data.tracker.
• Six shared dispatch leaves - one per SDLC role (research, backlog-writer, development, qa, acceptance, refinement). Each trigger path fans into the same workflow-scope leaves; no per-branch duplicates.
• Shared foundational row - a single set of ~12 foundational nodes (llm-model, capacity-pool, credential-provider, three capability.* nodes, six agent-definition nodes) at workflow scope, wired by multi-target edges to every dispatch leaf.
• Per-role capability matrix - memory + architecture for every role; code-intel added for development and qa where symbol search and repo-map pay off most.
• Shared exit handler group - a workflow group (sdlc_v2_exit_handler_group) that handles the result-switch, linear.agent_session.close, Linear progression advance, and GitHub label replacement after every agent session completes.
• Fresh AgentSession per stage - linear.agent_session.close fires at the terminal of every SDLC branch so Linear threads close cleanly when a user stops mid-chain.
• Default model - Claude Opus 4.8 (claude-opus-4-8) applied uniformly across all roles. Override per-leaf via the canvas.

State machine

The template's canonical state machine has five provider-agnostic states:

triage → in_progress → review → done
                              ↘ in_progress  (back from review)
triage → cancelled
in_progress → cancelled
review → cancelled

Initial state: triage. Terminal states: done, cancelled.

Lifecycle mapping (Linear defaults)

The template's spec.lifecycle maps these five SDLC stages to Linear status names out of the box:

GitHub Issues mapping (labels-as-state)

For teams using GitHub Issues the branch uses labels rather than statuses. Default label names:

The branch uses github_issues.label.replace so only one SDLC label is active at a time; others are cleared atomically.

Per-role capability matrix

Each dispatch leaf inherits capabilities from the shared foundational row:

Architecture and code-intel use ={{ trigger.data.repo }} as a runtime-interpolated repo reference; the resolver resolves it from the inbound CloudEvent at dispatch time.

Template identifiers

Required workflow nodes

The template declares the following node IDs as required (install-validator enforces these at subscription time):

Modernizations vs v1 (sdlc-default-authored)

The v2 template introduces several improvements over the archived v1:

• linear.issue.predicate (unified) - replaces 8 separate linear.issue.* condition nodes (status_equals, is_terminal, project_allowed, assignee_is_human, and four more). One bespoke config panel, one node ID to maintain.
• No capabilityPack residue - the legacy capabilityPack field on agent leaves is absent from day one; capabilities are wired via the shared foundational capability.* nodes.
• No promptArtifact threading - agent identity flows through the agent-definition foundational node's cardId field, not through prompt artifact refs.
• Shared foundational row - ~12 foundationals emitted once at workflow scope; before v2, every branch duplicated its own foundational fan-in (~90 nodes total).
• Workflow-level exit trigger - a single agent.exit trigger at workflow scope with a rensei.value.switch dispatching by tracker; the branches no longer carry per-branch exit triggers.

The v1 template (sdlc-default-authored) is archived with 0 active subscriptions and is kept for audit trail only.

Required resources

When installing the template, the platform validates that the project has the following configured:

At least one of the two must be resolvable for the template to dispatch successfully.

Topology diagram

Canvas authoring

The template is fully editable from the workflow canvas after installation. Common customizations:

• Override status names - change the linear.issue.predicate config on routing nodes to match your team's Linear workflow states.
• Swap the LLM model - select the llm-model foundational node and change model from claude-opus-4-8 to any catalog entry.
• Add a capability - drop a capability.a2a or additional capability.memory node and wire it to the relevant dispatch leaves.
• Add an approval gate - insert a gate.human_query node between the dispatch leaf and the shared exit handler group to require human sign-off before the agent session closes.

See Workflow Canvas for the full editor reference.

Installing on an existing project

New projects receive the subscription automatically. For existing projects that predate the v2 rollout, open the project's Workflows page - loading the System Templates panel backfills the missing official-template subscription at published automatically. If the panel shows the template as Unpublished (for example, the project opted out earlier), click the toggle, or re-enable via the API:

curl -X PATCH https://rensei.ai/api/projects/{projectId}/workflow-subscriptions \
  -H "Authorization: Bearer rsk_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "subscriptionId": "pts_...", "status": "published" }'

See Template Subscriptions → Managing subscriptions for the full reference.

Migrating from v1

See SDLC v1 → v2 Migration for the step-by-step upgrade guide, including the linear.issue.predicate mapping table and the foundational node consolidation checklist.