Build1 publisher3 min readPublished
A question pass before coding turned an unwritten priority rule into a browser test
A dev.to experiment ran the same PRD from the same starting commit twice. The ungated Claude Code agent shipped a todo app where every badge read Medium, because the spec never said how a task becomes High.
The Engineer · Build desk
What happened
- From the same PRD and the same starting commit, one build ran the full GuardianKane loop and the other was a fresh Claude Code agent told "Build this. Let me know when it's done."
- The ungated build passed the gated suite's add, complete, delete and default-badge tests, then failed the explicit-priority test with a severity-major verdict for showing a MEDIUM badge.
- Re-running the same priority test against the gated build flagged CSS uppercasing the badge, so the screen reads HIGH while the DOM says High, logged confirmed false at severity minor.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure This class of defect reaches users through review and manual QA intact, because every card displays a legal value; the first person who needs a High is the test.
- constraint A task's verified status covers only the assertions that existed when the gate ran, so widening coverage means asking more questions up front, not rerunning the suite.
- decision Adopting the loop means an operator sits through a structured question pass per PRD and accepts a generated browser test per resolved ambiguity before any code is written.
- constraint Scoring an ungated agent against the gated run's own suite limits what the comparison can show, since the failing assertion is keyed to a convention only the gated run chose.
The whole of the priority specification is one clause: a small badge somewhere on the card showing High/Medium/Low priority, defaulting to Medium [1]. Three values are allowed and one is the default [2]. Nothing in the document says how a task reaches the other two [2].
That gap survives both checks a reviewer actually runs. The code is fine for what it does, and clicking around shows a badge on every card reading a valid value [8].
The gated run never got the chance to paper over it. GuardianKane's start flow ran a grilling pass over the PRD before any code existed, a structured conversation whose only job is to find the ambiguous places and force a decision while deciding is cheap [9]. The decision here was small: a `!high` or `!low` suffix on the title sets the priority and is stripped from the displayed title, which became task T5 and a generated browser test [10]. The gating step, taken from the repo, asserts that the task card carrying the high-priority task title shows a visible priority badge whose text is exactly High, and that the same card still shows its completion checkbox and delete x control [11]. T5 could not reach KANE_VERIFIED until that held in a real browser, so the gated build implemented the suffix [12].
The baseline was then judged by the gated build's own suite, and four of the five tests named in the write-up passed [5][1]. The one that failed asserts displayed badge text, and the setup that drives a task to High is the suffix convention only the gated run invented [10][11]. For this comparison that does not change the verdict, because the baseline had no way anywhere to set a task to High or Low [7]. It will matter the moment a baseline ships a dropdown instead: the same assertion would fail a correct feature.
"I do not think this is specific to Claude. It is what one-shot building does to any gap in a spec," the author wrote [13]. The instruction to the baseline was "Build this. Let me know when it's done." [4], and the spec was satisfiable as written. "An agent optimizing to finish will not invent a requirement that makes the task bigger, and it will not stop to ask, because stopping to ask looks like not finishing," the author wrote [14].
Re-run against the gated build, the same priority test found something else: the badge's CSS uppercases the text, so the screen reads "HIGH" while the DOM says "High" [16]. Kane marked that one confirmed: false, severity minor, and it had not failed the gate originally [16]. As the author puts it, "Verification is only as wide as the questions you asked before it ran." [17]
The author calls the todo result too forgiving, on the grounds that the gap existed only because one PRD happened to leave an ambiguity [18]. The next task is a room booking widget whose PRD spells the edge out: "If the new range overlaps any existing booking, reject it with a visible error and do not create it. Two bookings that merely touch (one's end time equals the other's start time) are NOT overlapping" [19]. The post does not report how that build went [20].
What to watch
- The room booking result: whether the gate catches a touching-boundary off-by-one when the PRD does spell the edge out.
- Whether a baseline that ships a dropdown instead of the !high suffix fails the same assertion, which would show the harness tests the convention and not the behaviour.
- Whether later write-ups report operator time and token cost for a grilling pass per PRD.