Verify Said 0 Fail. Bugs Still Shipped.

First two bugs: a sliced token and shattered paragraphs

That day a fresh article had just gone live, my verify tool said 0 fail, and when I opened the page, the heading was cut in half: just "The problem: pushing to", the rest dropped to a new line. Inline code like main got line-broken at random spots, every fragment given its own vertical gap. One paragraph with five inline code spans could shatter into a dozen blocks.

My first guess was completely wrong. I assumed the article content itself was the problem, that the HTML I generated was sloppy. Tracing it into the frontend component showed the real culprit: the article parser splits HTML at every inline <code> tag (deliberately, so embed tokens inside code stay literal), but the renderer displays each fragment as its own div inside a container that auto-spaces children. The fix was twelve lines: merge consecutive HTML fragments back into one div before rendering.

My verify caught none of it. The tool checks SEO structure, code block shape, embed tokens. Not the layout a reader actually sees.

And it wasn't alone. Earlier, a Mermaid diagram token on the branch strategy article rendered as plain text {mermaid:Z3JhcGg... right there on the live page. The cause was trivial: I assembled the content with a Python f-string, and f-strings eat double braces. The %7B%7Bmermaid:%7D%7D form (double braces, written escaped) I intended became {mermaid:}, and the frontend regex only recognizes the double-brace form. Now every article goes through a placeholder plus a regex assertion before push: a single brace fails the build, not the page.

The gates I put up afterwards

From those two incidents I rebuilt the pipeline like CI: dry-run first, push as draft, verify must be 0 fail, only then publish. Then I kept adding gates to the verify tool:

A style gate for Indonesian articles: stock AI phrases (the kind that show up in every first draft from a language model) fail outright. More than three em-dashes, more than three subheadings on a short piece, too much bold, become warnings. A translation gate for id/en article pairs: code block structure must be identical, comments may be translated, comment line count and positions must match too. Automatic rollback: if verify fails after publishing, the article pulls itself back to draft without waiting for me to wake up. Local archives saved on every push. Sitemap checked by polling every 15 seconds instead of a fixed sleep that can undershoot.

I tested the translation gate against a four-case matrix before shipping it:

# comment boleh beda bahasa, struktur nggak boleh bergeser
compare_code_blocks(a, b_trans)    # (True, '')
compare_code_blocks(a, b_no)       # (False, 'blok #1: 4 vs 3 baris')
compare_code_blocks(a, b_moved)    # (False, 'posisi baris comment bergeser')
compare_code_blocks(a, b_changed)  # (False, 'struktur code non-comment bergeser')

All four behaved as intended. I figured that chapter was closed.

Three gaps that stopped me from trusting the gate fully

A few hours after the gate shipped, a question came back that made me go quiet for a moment: you mapped CSS to // comments? CSS has no //. I checked the code. Correct. css sat in the //-stripping language family even though CSS comments use /* */. The consequence cut both ways: translated CSS comments were never stripped, so they registered as structural drift, and the // I did strip in CSS isn't even valid syntax there.

The first fix still leaked. An opening /* line got stripped, but the closing line of a multi-line block still carried leftover comment text, and that text counted as code. The real solution was no longer per-line regex but a small state machine tracking open/close comment state across lines.

There's also php, which I left alone on purpose. Its comments are ambiguous: #, //, and /* */ all exist. Stripping in the wrong direction is more dangerous than not stripping at all, so php gets treated as fully verbatim. My stack is FastAPI plus Next.js; php code will almost certainly never appear in my content. Writing a robust parser for a language I never use would be wasted work, in my opinion.

Gap	Why it slipped through	Fix
Code comments translated between locales	The strict verbatim gate flagged them as failures, but the rule itself was wrong: comments naturally follow the local language	Rev A: structure verbatim, comments free language, line positions locked
CSS mapped to //	CSS comments (/* */) were never stripped	Third comment family plus a state machine
Multi-line /* */ blocks	First fix only looked for openers per line; closing lines leaked	Strip with cross-line open/close state

The pattern that made me think twice: one gap was caught by the gate but the rule was wrong; the other two slipped through entirely and were only found because someone asked. Gates are good at catching problems you already know. The ones you don't know still need a human.

So the daily cron for my article pipeline now runs in draft-only mode. Topic research through verification runs automatically, but publishing still waits for me to press the button. When that button gets removed is written down explicitly: ten consecutive articles with zero corrections of any kind before approval, where "correction" is defined sharply, not just red gates, plus having passed at least one edge case from every category that ever fooled the gate. Ten alone might not be enough for me to leave the checkpoint unattended.

Next week's gate might survive ten clean articles in a row. The decision to start trusting it is still mine to make, slowly, on evidence.