Your First sdlc Run: case-search From Problem to Design

TL;DR An AI review you cannot audit is just a nod, and you ship on its green. In a first sdlc run, the reviewer rejected "listing is usable" and "fast", then left a log that records the SHA-256 of every file it judged and every upstream file it relied on, with the command it ran as evidence. That is an AI code review gate you can check.

Do this: Install with npx agentic-fx@latest install, fill four sections of DEV-PROFILE.md, and open your first gate log under .sdlc/reviews/.

Part 1 ended on one question: what does a gate actually write, and how would you know the reviewer did more than nod? To find out, run case-search through its first three gates and open the files each one leaves.

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 (you are here).
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: the agents on screen, the standards, the packet QA starts from.

The first draft failed G1

/sdlc-intake case-search writes problem.md: testers cannot find a case they wrote last month, so they rewrite it, with 47 near-duplicates as evidence. The reviewer passed G0 with one MINOR finding, CR-001: the threshold behind "47" is not stated.

G1 looked fine to the author. The reviewer returned CHANGES_REQUESTED with two MAJOR findings:

The author rewrote them as "paginated and sorted" and "p95 under 300 ms at 50 requests per second, measured by k6". Round two passed. Had it failed again, the command would have stopped and asked a person, because two rounds is the limit.

Why this reviewer is not nodding

Author and reviewer are different skills in different subagents, each starting from an empty context (DEV-CONTRACTS.md §4.5). Three rules keep the reviewer honest:

1. It gets file paths only, never the author's summary, so it cannot inherit the author's blind spots. In round two it also gets one line per finding saying what changed, and checks each against the files.
2. It may run read-only commands: a linter, EXPLAIN, a grep. A verdict needs evidence.
3. It never edits, migrates, pushes or deploys. If it could fix things, it would stop flagging them.

The log you can check

For G2, /sdlc-design case-search wrote ADR-004: one table, two handlers behind the existing gateway, keyset pagination. The reviewer proved "extend what exists" with a command, grep -rn "func.*List.*Case" internal/, which found no existing list handler. It passed with two MINOR findings.

gate: G2
verdict: PASS
inputs:
  - path: .sdlc/requirements/case-search/requirements.md
    sha256: 0000ade17d352cb1…
outputs:
  - path: .sdlc/design/case-search/architecture.md
    sha256: f17a1015cb41b057…
findings: { blocker: 0, major: 0, minor: 2, info: 0 }
override: null

Run it yourself

cd your-project
npx agentic-fx@latest install

Pick dev when it asks. For a first run, four sections of DEV-PROFILE.md are enough: §Project, one row of §Stacks, §Quality gates and §Delivery. A stage that meets a placeholder stops and says so rather than guess.

In your repo, two things should hold for every stage: the agent that wrote it did not approve it, and its log names the exact bytes it judged.

The hashes are the part this run has not used yet. After G2 passed, one line of requirements.md was tightened and G1 approved the new version. G2 judged the old bytes: does its approval still count, and must the whole ladder run again? Part 3 follows that edit.

Read this with your AI

Read the post "Your First sdlc Run: case-search From Problem to Design".
1. Explain in 4 steps what happens between "author finishes" and "next stage runs".
2. Ask me 3 questions to check I understood; wait, then correct me.
3. Rewrite one requirement from my project (below) the way G1 forced REQ-002 to be rewritten.
<paste one requirement>