Aor test trace

/aor-test-trace — Test Cases + Traceability Matrix

Drafts test cases for each Software Requirement using the appropriate format, then builds the trace matrix linking UN → PR → SR → TC.

Note on skills vs agents. The AOR bundle contains skills at .claude/skills/aor-*/SKILL.md (invocable directly, like this one) and SME agents at .claude/agents/aor-sme-*.md (sub-agent system prompts spawned only by aor-review / aor-review-adhoc). Do NOT invoke an agent as a skill — it will fail with "skill not found".

Operating discipline

Apply throughout. State each at startup so the user sees it.

• Mode (declared at startup): ask whether this is an exploratory session (single SR, conversational, no files written) or a document session (full TC + traceability authoring against a SPECIFICATION.md). Default to document mode if a specification path is provided; default to exploratory if SR text appears inline in the conversation without a file path.
• Invocation acknowledgement: the first response of the skill states "Running as aor-test-trace in <mode> mode. Files written to TEST_CASES.md / TRACEABILITY.md unless you ask otherwise." Eliminates the "did the skill actually run?" ambiguity.
• Q&A discipline: ask one clarifying question at a time. Wait for the user's answer before asking the next. Do not stack questions. A single AskUserQuestion call presenting one decision with multiple alternatives (e.g., a multi-choice menu) is one question; presenting two unrelated decisions in one call is stacking.
• Failure-disclosure: if any prescribed step cannot be completed (file write blocked, sub-agent invocation failed, reference file unavailable, partial completion, timeout, permission denied), state it in chat. After disclosing, halt and ask whether to retry, fall back to disclosed manual emulation, or abort — do not continue silently. One retry is permitted for clearly transient failures (e.g., network timeout) before mandatory disclosure.

Workflow

Step 1: Locate or accept the specification

Three input modes, in priority order:

1. File path provided. Use the given path.
2. Default file present. Use ./requirements/SPECIFICATION.md (the default output of /aor-req).
3. Inline SR text in the conversation. If no path is given and no default file exists but the conversation contains SR text or a single SR-NNN body, use that as the input — do not error out. This is the exploratory-mode entry point: TC drafting on a single requirement without a file-system dependency.

If none of the three apply, error out and direct the user to /aor-req first.

Step 2: Draft Test Cases (TC-NNN)

For each SR (or each SR clause), generate at least:

1. Happy path — 1-2 scenarios with concrete data
2. Edge cases — boundary values, empty inputs, max/min, off-by-one
3. Unwanted behaviour — every If/Then in the spec gets a negative TC
4. Security cases — when input/auth/data storage is involved
5. Property assertions — invariants that must hold for any valid input

See test-formats.md for which format fits each EARS pattern.

Clause-level traceability: every TC tags the specific clause(s) it verifies, e.g. [SR-001.c1], not just [SR-001]. This catches partial implementations that pass coarse-grained tests.

Step 3: Verify TC quality

Apply the TC drafting checklist in tc-checklist.md. Each TC must satisfy ISTQB T1-T10 (Correct, Complete, Feasible, Necessary, Traceable, Consistent, Precise, Atomic, Observable, Independent).

Step 4: Build the traceability matrix

Create or update ./requirements/TRACEABILITY.md with:

• A UN→PR→SR→TC mapping table
• Coverage indicator per SR clause (covered / partial / gap)
• Any unresolved gaps flagged explicitly

See templates.md for format.

Step 5: Validation plan

For each UN, draft a validation entry — this is human acceptance, distinct from automated test cases:

UN	Validator	Scenario	Question
UN-001	{role}	{realistic usage scenario}	Does this serve the user need described in UN-001?

Step 6: Coverage check

Before declaring done:

• Every SR clause (SR-NNN.cN) has at least one TC
• Every If/Then (Unwanted Behaviour) SR has a negative TC
• Every input field has at least one error-condition TC
• Boundary values tested (min, min-1, max, max+1)
• Every cross-reference resolves to an existing identifier
• Validation plan covers every UN

Large input handling

When the specification has more than ~100 SRs:

1. Process by SR-ID range in batches of 25 SRs.
2. For each batch: a. Draft TCs for the SRs in the batch. b. Append to the TC file (do not overwrite). c. Update TRACEABILITY.md incrementally with the new mappings. d. Report progress: "Batch <N> of <M> complete; <K> TCs drafted."
3. After all batches, run the coverage check on the full set.

If an SR is ambiguous, pause and request clarification before proceeding — do not draft speculative TCs.

Output paths

• ./requirements/TEST_CASES.md — TC definitions
• ./requirements/TRACEABILITY.md — UN→PR→SR→TC matrix and validation plan

(Some teams prefer to keep TCs inline in SPECIFICATION.md. If the user has that convention, append TCs there instead.)

Reference files

• test-formats.md — five TC formats with EARS-pattern mapping
• tc-checklist.md — TC drafting checklist
• templates.md — TRACEABILITY.md format and validation plan template