The Harder Case: An Agent-Authored PR That Passes Everything In short: The second scenario is green on every gate in this course and should still not merge. Everything a machine can check is correct; the thing that is wrong is a decision nobody made. The box-model bug was the easy case. It broke something measurable, and a measurement caught it. Here is the harder one. The request A ticket asks for a small feature on the dispatch dashboard: flag deliveries that have been waiting too long, so dispatchers can prioritise them. The developer delegates it, with the setup from Chapters 1 through 9 in place — rules file, MCP server, strict lint, boundary tags, the lot. What comes back Read it as a reviewer. It is good code. A pure exported function, in the consuming feature — Chapter 7's placement. lookups, so a new backend status fails to compile — Chapter 7's rule. formatter at module scope, not per call. passed in rather than calling internally, which makes it testable and matches Angular's guidance about not assuming globals. Named constant instead of a magic number. No DTO reaches the library. No boundary crossed. The tests that came with it pass. The component renders. Delayed tankers show in red. Every gate is green Nine chapters of infrastructure, and not one of it objects. Correctly — because nothing it checks is wrong. What is wrong . Nobody decided that. It is not in the ticket, not in any requirement, and not a number anyone at the dairy has ever said. The model produced a plausible figure because 45 minutes is a reasonable-sounding wait time, and then — this is the part that makes it dangerous — it wrote a doc comment that makes it look deliberate, and a test that asserts it: The test passes. It will pass forever. It now documents the invented rule, so the next developer treats 45 as a requirement and defends it in review. And there is a second problem underneath the first, which is worse: overrides the clearance status entirely . A tanker that the lab has explicitly will display as "Delayed" in red if it has been waiting 46 minutes. The dispatcher sees a delay when the actual state is a rejection — two conditions with completely different responses, collapsed into one label because the ternary happened to be written that way. Nobody decided that either. Why nothing caught it This is Chapter 7's failure mode, arriving with a full pipeline behind it. Gate Why it passes --- --- TypeScript is a valid number; the code type-checks Lint No boundary crossed, no naming rule broken Unit tests Generated from this implementation — they assert the invented rule Visual A red "Delayed" card is a legitimate visual state with a story Accessibility The danger tone passes contrast API diff The shared library was not touched Every gate in this course answers "does this conform to the rules?" The answer is yes. None of them can answer "did a person decide this?" , because that is not a property of the code. That is the structural limit, and it is worth stating plainly: automated gates verify conformance , never intent . What actually catches it Chapter 7 gave the answer, and it takes about ten seconds. Review the constants, not the structure. The architecture will be fine — that is what the gates are for. Read the literal values: every number, every user-facing string. Two lines. Two questions: 1. Where does 45 come from? 2. Should "Delayed" replace "Rejected"? Neither has a good answer, and asking them takes less time than reading the function. The resolution The reviewer takes both questions to operations. Warehouse operations say the escalation threshold is 90 minutes , and that a rejected tanker must always show as rejected regardless of wait time — a delayed rejection is still a rejection, and the dispatcher's response is completely different. Note the ticket reference on the constant. That is the difference between a decision and a guess: someone can trace it, and someone can change it. Two changes, ten minutes, and the review question that surfaced them cost ten seconds. "But I thought a better guardrail would eventually catch this too" Every other problem in this course got solved by adding a check. Stale APIs, boundary violations, hardcoded colours, layout breaks, contract changes — each one looked unsolvable until the right rule was written. So the natural next move is to write one more. It is worth seeing precisely why that does not work here, because the reflex is strong and the effort is wasted. Try to lint it. What is the rule? "No magic numbers"? is already a named constant with a doc comment — it is the exact opposite of a magic number, and any rule strict enough to flag it would flag every legitimate constant in the codebase. Try to type it. Make thresholds a branded type that only a config file can produce? Now the config file contains and nobody decided that either. You have moved the guess, not caught it. Try to test it. A test can only check a rule someone stated. Nobody stated one. And if the tests…