Story QA pipeline (multi-agent)

You are the orchestrator. Do not audit the code yourself - resolve the spec, dispatch, then format the result. Boundary: the review pipeline hunts defects in a diff; this pipeline verifies a story against its spec. Same branch, different question.

Paths below are relative to this skill's base directory. The spec-discovery cascade and output contract live in the sibling skill: ../../../skills/dotnet-techne-story-qa/references/.

Step 0 - Check the budget, then the roles

A spec-mode run spends four agent turns - three QA lanes plus the maintainer (three turns in no-spec mode). Say in one line what the run will cost; a small story on a constrained plan is better served by the single-context dotnet-techne-story-qa skill.

List your available agent roles. If qa-acceptance, qa-reuse-design, qa-dead-code, or review-maintainer is missing, stop and tell the user to run scripts/install-codex.sh from the plugin, and use the dotnet-techne-story-qa skill in the meantime.

Step 1 - Resolve target

The story diff: the current branch vs its merge-base with the default branch, unless the user names a branch, ticket, or base. Slug the story (ticket key if known, else branch name). Nothing to diff - halt and say so.

Step 2 - Resolve the spec (cascade)

Follow ../../../skills/dotnet-techne-story-qa/references/spec-discovery.md exactly: explicit spec path or pasted spec → ticket key from the argument or branch name (Jira-style [A-Z][A-Z0-9]+-\d+; fetch via an issue-tracker MCP tool when one is available) → repo artifacts (.episteme/DESIGN-*.md, PLAN files, docs) → ask the user with exactly two options: provide a reference, or continue without a spec. Never infer no-spec mode from a missing path.

Build the spec pack (numbered ACs, constraints, out-of-scope notes, claimed file/task lists, source, issue links and relevant ticket comments as one-liners, and the contract source of truth if the ticket names one - an external schema, consumer test suite, WSDL, or OpenAPI document, plus the consumer of the API; fetch its content yourself and put the relevant excerpts in the pack - the read-only roles cannot dereference a URL) and a practices pack (5-15 lines of the project's established conventions; when the host repo ships its own QA skill or QA instructions, fold its rules in - repo-local wins). Workers receive these packs and the diff - never conversation narration.

Step 3 - Fan out

Capture the story diff once (read-only git), then spawn the lanes in parallel, in one go: qa-acceptance (only in spec mode) with the spec pack, qa-reuse-design with the practices pack, qa-dead-code with the comment-rules path (../../../skills/dotnet-techne-story-qa/references/comment-rules.md; host-repo conventions override it). Each with the repo root, the diff (the roles run read-only, so the inline diff saves redundant work), and the finding block format (Severity / Area / Owner / Location / Evidence / Impact / Fix / Confidence). In no-spec mode announce the skipped acceptance lane - degradation is stated, never silent. If your host caps concurrent agent threads, lanes run in waves - say so, and do not mistake a wave for a finished lane.

Step 4 - Merge, then let the maintainer attack

Merge and dedupe: same Location+Area merges, highest severity and strongest evidence win; number the list. Then spawn review-maintainer with the numbered findings, the AC coverage table, the spec pack (its issue links back the "another ticket covers it" counter-argument; its full criterion texts back any AC dispute), the diff scope, and both ../../../skills/dotnet-techne-code-review/references/maintainer-playbook.md and ../../../skills/dotnet-techne-story-qa/references/falsification.md. Spawn it even when the lanes returned zero findings in spec mode - an all-IMPLEMENTED table is exactly the result that needs an adversary. Apply its verdicts: drop REFUTED (keep a one-line Dropped list with the refutation), adjust DOWNGRADED and UPGRADED. The maintainer never rewrites the AC table; it may dispute a verdict whose evidence does not hold - a dispute is advisory, listed under the table, and gates CONCERNS. If the maintainer fails to run, say so and gate CONCERNS - unfalsified findings never read as a clean result.

Step 4b - Run the suite (the roles cannot)

The QA roles run read-only - they judge tests statically but cannot build or run them. You can. Build the touched projects, run the relevant tests, record the counts and warnings, and feed the result into the Summary and Checked table. A passing suite you executed outranks a test file only read; a failing build turns a PASS into a FAIL. Skip only when there is no runnable project or the user says so.

Step 5 - Gate, report, persist

Format exactly per ../../../skills/dotnet-techne-story-qa/references/qa-output-contract.md: the gate (FAIL / CONCERNS / PASS) and the skimmable verdict line first, then Summary (spec source, contract source of truth, build/test result, lanes run and any that failed), AC coverage table, findings ranked by consequence with Owner and Counter-check, the Dropped honesty section, the Checked table, and Yours to call.

Persist the verdict to .episteme/QA-<slug>.md (create .episteme/ if missing) with frontmatter target, spec_source, gate, date - skip only if the user asked for report-only. The QA changes no code: apply fixes only if the user asks afterwards (offering to is fine). One narrow exception - comment findings (area: comments): offer to apply the comment-line fixes (each finding carries the exact replacement line or "delete"), and apply them yourself ONLY after the user explicitly confirms. The workers never edit.