How the pipeline works

The SDLC pipeline turns a Request for Proposal into a reviewed document set: scope, requirements, design, test plan, build tickets, a compliance check, a traceability matrix and a client proposal. Each step runs on your project's agent, the bridge checks what the agent wrote, and a person approves the result before the next step can build on it. This page shows the steps in order, the gates between them, the states a step moves through, and what happens downstream when an earlier document changes.

The steps in order

The core chain is RFP, Scope, SRS, SDS and STS. Each of these produces a document that someone reviews, and the next step unlocks only when that document is approved. After STS the pipeline branches: Tasks, Compliance and Traceability run as soon as their input exists, and the Proposal waits for the approved STS.

Drawing diagram…

A diamond is a human approval. A plain arrow means "the document must exist" — it can still be a draft awaiting review.

All steps at a glance

Every file lives under .sdlc/artifacts/ in the project's working folder. The skills are the reference files on your project's agent; see Set up the project agent.

Reviewed and unreviewed steps

Six steps are reviewed: RFP, Scope, SRS, SDS, STS and Proposal. When one of them finishes, its document waits for Approve or Request changes.

Tasks, Compliance and Traceability are not reviewed. They are complete the moment they produce their output, and they have no Approve button. You can re-run them whenever you like.

What every step does

Whatever the step, a run follows the same pattern:

1. Check the inputs. The bridge confirms the documents and data the step reads are in place. A missing input stops the run before the agent is called.
2. Call the agent. The bridge sends one message per skill call to the project's agent, as the person who started the run. The agent replies with one JSON object; documents travel inside it as Markdown.
3. Check the reply. The bridge validates the data against its schema and the Markdown against the step's document rules: required section headings, every id the step owns, the minimum number of Mermaid diagrams, closed code fences and a size limit.
4. Correct. When a check fails, the bridge sends the agent its own reply back with each problem located — where, expected, found, how to fix — and the agent edits that reply. Most calls get up to 3 attempts, and the best reply is kept. If document problems remain, the draft is saved with them listed for the reviewer; if the data a later step reads is still invalid, the run stops and lists the checks that failed.
5. Assemble the document. The bridge puts a title block on top (the document title, then a table of project, client, version and date), adds the tables it owns — such as the requirement catalogue or the test-case catalogue — and appends the version history. The agent never writes those parts.
6. Record it. The document is written as <step>-vN.md, hashed, and registered in the project's state.

You can follow each of these stages live in the run panel. See Run the pipeline.

Step states

Each step is always in one of five states. The step rail in SDLC Studio shows each one: an available step with a play button, an approved step with a re-run button, and a locked step with a lock and what it is waiting for — "Approve Requirements Spec to unlock this" or "Run System Design Spec first". Once every document is approved you can start a new version of the pipeline; see Start a new version.

Drawing diagram…

A step's completion is judged by its document, not just by its run record: a run that ends without registering its file does not count, and the run is marked failed with "finished but did not produce the expected artifact".

Versions

A version number marks an approved milestone, not every generation:

• The first draft of a document is version 1.
• Regenerating a draft that has not been approved yet — a Request changes, or a re-run that failed and was run again — keeps the same version number and replaces the draft.
• Changing a document after it has been approved starts the next version: v1 approved, then a re-run produces v2 for review.

Compliance and Traceability are never approved, so they count up by one on every run. Tasks is never approved either, and keeps the same version number, replacing its files on every run.

Requesting changes

Request changes is available only while a document is awaiting review. You write the changes in the composer, one per line, and only that step runs again; the new draft comes back for review under the same version number.

How the changes reach the agent depends on the step. For the RFP, the agent receives its previous draft and edits it. For Scope, SRS, SDS, STS and Proposal, the change list is passed to the agent as notes alongside the original inputs and the document is written again from those inputs — so describe exactly what should change, and check the parts you did not mention too. See Review, approve, request changes.

When an upstream document changes

Approvals are tied to content. When you approve a document, the bridge records the approver, the time, the version and a SHA-256 hash of the file. An approval stays valid only while the document's current hash still matches the one recorded.

Re-running an approved step

Say the SRS and SDS are both approved, and you re-run /srs:

1. The SRS run produces v2, which waits for review. Its old approval no longer matches, so the SRS reads as awaiting review again, and any of its earlier approved runs are re-opened to match.
2. The SDS keeps its approval — it was given for the SDS's own content, which has not changed. But the SDS was built from an older SRS, so it is flagged stale: its button reads /sds re-run, upstream changed.
3. The same flag spreads down the chain. The STS, built on that SDS, is also flagged stale, because an upstream step somewhere in its chain was produced more recently than it was.

A stale flag clears only when the stale step itself is re-run. Nothing downstream is regenerated for you: approve the new SRS, then re-run the SDS, and carry on down the chain.

Drawing diagram…

Replacing the RFP

While an agent-drafted RFP is awaiting review, the composer offers Replace RFP in place of Upload RFP. An uploaded file becomes the project's RFP and is recorded as approved by you, then the bridge runs the same approval check it runs after any regeneration. Documents already built from an earlier RFP keep their approvals; if the RFP step was re-run after they were produced, they carry the stale flag. Re-run /scope to build on the new RFP.

A re-run that changes nothing

If you re-run an approved step and the agent produces a document identical to the approved one, there is nothing new to review. The run is marked failed with "did not produce a new version — the artifact is unchanged since the last approval", and the existing approval stands.

Under the hood

• The gate table lives in bridge/sdlc-engine/lib/sdlc/gate-rules.js, loaded through bridge/src/lib/eccRoot.ts; bridge/src/services/phaseGate.service.ts reads the project's state and run history and resolves each step's state. The client's composer shows exactly the reason the bridge would give.
• GET /api/projects/:id/commands returns every step's state, with blockedBy (a missing document), blockedByApproval (a missing approval) and stale. Starting a locked step returns 422 PHASE_GATE_LOCKED.
• Starting a step is POST /api/projects/:id/commands/:cmd. Request changes is POST /api/projects/:id/commands/amend with the phase and a non-empty changes list; it is refused with ARTIFACT_NOT_UNDER_REVIEW unless the document is awaiting review.
• Approval is POST /api/projects/:id/approvals/:phase. It uploads the draft to storage as projects/<id>/approved/<phase>-vN.md before recording the approval, and refuses while a step is running.
• The project's state is .sdlc/state.json: artifacts.<step> holds each document's path, version, hash and version history, and approvals.<step> holds each approval.
• More detail: Document checks and versioning, Run lifecycle and streaming, and The agent protocol.