--- title: "Your First sdlc Run: case-search From Problem to Design" author: "Harry" published: 2026-10-31T04:14:13.075Z updated: 2026-10-31T05:05:43.911Z category: "AI Agents: SDLC & STLC" tags: ["sdlc"] canonical: "https://fxblog.dev/posts/how-an-ai-code-review-gate-works" --- # Your First sdlc Run: case-search From Problem to Design ## Key takeaways - A first run needs one install command and four sections of DEV-PROFILE.md: project, one stack, quality gates and delivery. - Intake frames the problem with evidence before any solution, and its reviewer checks that no solution slipped in. - The requirements review rejected 'listing is usable' and 'fast', because a requirement that cannot fail cannot pass. - The reviewer gets file paths only, never the author's reasoning, and may run read-only commands as evidence. - Each gate log records the SHA-256 of every file it judged and relied on, next to its verdict and findings. > **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](01-why-gates.md) 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: | Finding | As written | Why it failed | | ------- | ---------------------------- | --------------------------------- | | CR-002 | REQ-002: "listing is usable" | It cannot fail, so it cannot pass | | CR-003 | REQ-101: the list is "fast" | "Fast" is not a target | ![The G1 log for case-search, attempt 1: verdict CHANGES_REQUESTED, two failed checklist rows, and findings CR-002 and CR-003 both MAJOR](https://fxblog.dev/media/01a18fc8-f21f-7053-909d-5ea5752bf8d0/1600) _The first draft failed, in the reviewer's own file_ 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. ![What a gate log pins: case-search G2 records requirements.md in and architecture.md out, each with its sha256, a checklist with evidence, findings CR-005 and CR-006, and a verdict](https://fxblog.dev/media/01a18fc8-fcfb-7066-b0a2-c3ed6abb69e2/1600) _The verdict is tied to the exact bytes the reviewer read_ ```yaml 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 ``` ![The Findings tab for case-search: four minor findings and one info finding, CR-001 to CR-007, each with the problem and the gate that raised it](https://fxblog.dev/media/01a18fc9-05e5-7745-9b4b-659c6a5ab842/1600) _Every finding the gates carried forward_ > **Tip** > > A PASS with zero findings is "correct and common", in the contract's words. And not every finding is a defect: on one project, 41% of 257 review findings were documents drifting apart or bookkeeping. Since 1.3.0 I cap those at MINOR, and they spend no attempt. ## Run it yourself ```sh 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 ```text 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. ``` > **Success** > > You have read a gate log byte by byte. Next: **When Something Changes: STALE, Reaffirm and Who May Override**. ## FAQ ### Why does the reviewer only get file paths? A reviewer that reads the author's reasoning inherits its blind spots. Paths only means it judges the files as they are, with a fresh context. ### How many review rounds does a gate get? Two. The author fixes, the reviewer checks each finding by id, and if the second round still fails the command stops and asks a person. ### What does sdlc need before the first run? One install command, then four sections of DEV-PROFILE.md. A repository that already has code should also run /sdlc-onboard first.