The SDLC pipeline

STS — test plan

Test cases mapped to requirements and the IEEE 829 test plan around them.

The STS step writes the test plan. The agent authors a test case for every requirement, linked to the design components that implement it; the bridge validates the links, computes coverage, and the agent then writes the IEEE 829 test-plan narrative around the result. The test cases also flow on into the build tickets: each ticket carries the test cases for the requirements it implements.

What you get

A Markdown document titled Software Test Specification:

Order	Section	Written by
1	Title block: project, client, version, date	Bridge
2	1. Introduction — purpose, test scope, definitions, references	Agent
3	2. Test Items — what is and is not tested, citing requirement and component ids	Agent
4	3. Test Approach — test levels, approach, automation, and a test-process flowchart	Agent
5	4. Entry and Exit Criteria — plus suspension and resumption criteria	Agent
6	5. Test Environment — hardware, software, network, test data, set-up	Agent
7	6. Coverage — coverage by level and by type, a pie chart of test cases by type, and the uncovered requirements with a plan for each	Agent
8	7. Schedule and Resources — a test-phase Gantt chart and a role table	Agent
9	8. Defect Management — severity classification and tracking	Agent
10	9. Risks — three to six real test risks	Agent
11	10. Deliverables	Agent
12	Test Case Catalogue — every test case with its description, type, level, priority, requirements and expected result	Bridge
13	Version History	Bridge

The bridge requires the headings Introduction, Test Approach, Test Environment, Entry, Exit and Coverage. The catalogue is written from the validated test cases, so every test case id is in the document by construction.

Before you run it

The SDS must be approved. Until it is, /sts is locked with "Approve /sds to unlock this".
The project state must hold the SDS, a non-empty requirement list and a non-empty list of design components. Otherwise the run stops naming the step to run first.

How it works

Two skills run in sequence: sdlc-test-author for the test cases, then sdlc-sts-narrative-writer for the document. Each has up to three attempts.

Drawing diagram…

1. Test cases

The test author receives every requirement (with priority, acceptance criteria and its links so far), every design component, the project and client names, and any notes. It returns testCases[]. The skill's rules:

Every requirement gets at least one test case.
Each case has one test type — unit, integration, system, uat, performance or security — chosen as the lowest level that fully validates the requirement. Performance and scalability requirements get performance tests; security and compliance requirements get security tests.
Priority follows the requirement: a "must" requirement's cases are critical or high, "should" high or medium, "could" medium or low.
Steps are ordered, concrete actions; the expected result is a binary pass or fail drawn from the acceptance criteria.
Every case starts as "not-run", with no actual result, date or tester.

The bridge validates each case against the test-case schema and checks that every linked requirement and component exists. An empty list stops the run immediately; any other failure goes back as a correction.

2. Coverage

The bridge then computes coverage without the agent: total and covered requirements, the ids of uncovered ones, the coverage percentage, how many requirements have 0, 1, 2 or 3+ tests, and coverage by requirement type. The narrative writer receives these figures as they are, so the Coverage section reports the real numbers and names the real gaps.

3. The narrative

The narrative writer receives the requirements, components, test cases and coverage summary, and returns the document as Markdown. It uses only the test levels present in the cases, never invents named people for the schedule, and states plainly where the input is silent.

The project state is written only after the narrative passes, so a run that fails at the narrative leaves the state as it was. On success each test case is linked both ways: the case lists its requirements and components, and each requirement lists its test cases.

The run panel shows: Checking project state, Authoring test cases, Validating test cases, Computing requirement coverage, Writing the narrative, Persisting to project state, Writing the Markdown document. The completion message reads "STS vN generated with X test cases covering Y/Z requirements (P%)".

Ids this step owns

Id	Meaning
`TC-NNN`	A test case. Zero-padded, one sequence for the whole plan starting at `TC-001`, at most `TC-999`. Ids are permanent once assigned — never reused or renumbered.

Each test case links to requirement ids (REQ-…) and, where relevant, design component ids (DC-NNN).

Reviewing it

Check that:

the Coverage section reports 100%, or that every uncovered requirement has a sensible plan;
"must" requirements have critical or high test cases, and the expected results really are pass-or-fail;
test types are sensible — a performance requirement tested by a performance case, not a unit test;
the risks and environment reflect your project rather than boilerplate.

Approving the STS is what unlocks the Proposal. Test-case status stays "not-run" on approval; it describes execution, not review.

Request changes runs both skills again with your change list as notes; neither sees the previous draft. Refer to cases and requirements by id — "Add a negative test for REQ-FUNC-012 with an expired token", "Make TC-031 a security test" — and re-check the catalogue when it comes back, since the cases are authored again.

When it fails

What you see	Why	What to do
"test-author returned no testCases[]."	The reply had no test cases. There is no retry for this.	Run it again.
"ECC script failed: scripts/sdlc/validate-test-cases.js"	Three attempts in a row had a malformed case: a bad `TC-` id, a missing field, `testData` not a string, or a link to a requirement or component that does not exist.	Run it again.
"The STS narrative did not pass the Markdown checks."	The narrative kept missing a required heading, or a diagram was malformed.	Run it again; check `sdlc-sts-narrative-writer.md` is attached as shipped.
"The agent declined this step"	The agent answered with a refusal instead of the contract — the reason follows in the message. A project with no client name is sent "My Client", so a missing client name is never the cause.	Read the reason; if it names a missing file, run Check agent in Project Settings › Agent.

Under the hood

The driver is bridge/src/services/stsPipeline.service.ts.
Written to the project state: testCases (replaced on every run), each requirement's links to its test cases, and testCoverageSummary.
The document is .sdlc/artifacts/sts-vN.md, registered as artifacts.sts. The draft is kept in .sdlc/tmp/sts-data.json while under review.
Once the STS exists, Tasks and Compliance become available; once it is approved, so does Proposal.