The Board, the Rules and the Handoff to QA

TL;DR Left to taste, AI agents write two list endpoints in two styles, collide on the same file, and deploy on the developer's word. In sdlc, AI coding standards each have one owner and one gate that can fail it, and development ends at one file, qa-handoff.md. G10 refuses to deploy until QA's report passes and is dated after the shipped commit's G8 run, a sign-off says GO, or a named person waives QA in writing.

Do this: Check one of your list endpoints against DEV-CONTRACTS.md §13: cursor pagination, limit 20 by default, and RFC 9457 errors.

Part 3 left case-search with several agents building its tasks, and two questions: is any of them stuck or about to collide, and what stops the code shipping before QA has tested it?

This series, in four parts:

1. Your AI Coding Agent Grades Its Own Homework. Add Gates.: the problem, and the route sdlc takes.
2. Your First sdlc Run: case-search From Problem to Design: install, then the first three gates and their logs.
3. When Something Changes: STALE, Reaffirm and Who May Override: an edit lands after approval.
4. The Board, the Rules and the Handoff to QA (you are here).

Who is working on case-search right now

Scrolling transcripts will not tell you which agent is stuck. The Agents tab reads Claude Code's own transcripts, read-only, and draws every chat and the subagents it spawned. Each agent keeps a stable first name, so "Anh is on TASK-003" works in a stand-up.

On one of my projects an implementer ran for two hours before it stopped on a file another lane owned. Parallel tasks save time until that happens.

One rule per list endpoint

Ask two agents for two list endpoints and you get two pagination styles and two error shapes. sdlc decides once, in DEV-CONTRACTS.md §13, and each rule names the skill that owns it and the gate that checks it. The list endpoint answers to these when its contract is reviewed (G4) and again when its code is (G7):

So case-search's acceptance criterion reads "20 cases and a next cursor, sorted by title then id". Security findings work the same way: one ledger, one SEC-NNN row each for life, and only a named person can mark one accepted. By default an open critical or high finding fails G8 and G9.

One file, and a deploy that waits

/sdlc-release case-search writes release/case-search/qa-handoff.md: the REQ table, acceptance criteria, contract and data-model paths, the shipped commit, and the criteria only a running product can prove. For case-search that is AC-101, p95 under 300 ms at 50 requests a second, against staging.

G10 will not deploy on the developer's word. It waits for one of these:

1. the latest QA report is dated after the shipped commit's G8 run and every gate line passes;
2. a release sign-off covering it says GO;
3. a named person has waived QA in writing.

So the deploy waits for a QA verdict newer than the last G8 run, and the series stops at the handoff. What QA does with qa-handoff.md, from requirement ids to a verdict on that commit, is the stlc series.

Try it

cd your-project
npx agentic-fx@latest install

Pick dev; the installer adds the VS Code board. Then run SDLC: Open Board, or SDLC: Open Agents while a /sdlc-implement is running. The standards are rows in DEV-CONTRACTS.md §13, in your repo.

Read this with your AI

Read the post "The Board, the Rules and the Handoff to QA".
1. Pick 3 rows of the API standards table that my API breaks (below), and say which gate would fail each.
2. Ask me 3 questions to check I understood; wait, then correct me.
3. List what my next release should put in its QA handoff.
<paste an endpoint or two>