Defend Against the Forgotten Compile

Six commits into the bracket display fixes, three pages still pointed at /src/

Six commits deep into the tournament bracket display fixes: court-name alignment, the X’d-out slot spacing, the 8am-plus-orange date change, a sticky left nav driven by a scroll handler, the location pin and court arrow icons nudged to vertical center, the schedule-slots court text nudged down a couple pixels to stop descenders clipping. Small, real UI fixes, the kind you iterate on by refreshing the browser forty times. And to make that iteration fast, the bracket-editor page, the schedule-slots page, and the schedule-build page had all been pointed straight at their /src/ source files instead of the compiled, dated bundles the platform actually ships.

That’s not a mistake by itself. Editing a page’s /src/ source directly and reloading is the whole point of working that way; nobody wants to run a compile step for a one-pixel nudge. The mistake is what happens if nobody flips the refs back before the branch goes to develop.

Why the dated bundle exists at all

The platform’s release process has a compile step that takes a /src/Name.js file and produces Name{YYMMDD}.js next to it using terser. The comment at the top of that script explains why it’s terser and not something homegrown:

regex-based “minifiers” (sed s|//.*||, custom scripts, in-app tools) silently corrupt strings that contain ://, producing files that break the page they ship to. terser is the only safe tool. This script enforces it and verifies the output parses, so a broken compile fails loud at compile time instead of silently shipping to the dated file.

The script also refuses to run unless the source path contains /src/, because output goes to the parent directory and the parent directory is what production actually serves. A .asp page loads a specific dated filename, like Name260617e.js, not Name.js. That same afternoon, on a completely different ticket, a hotfix session needed the exact same facts spelled out from scratch: how the dated bundle gets produced, whether the filename date has to bump, where the .asp references live. Two unrelated tickets, same afternoon, both needing to rediscover the same mechanism. That’s the tell that it isn’t written down anywhere a developer actually looks at the moment it matters.

The guard that already existed, and already failed

This wasn’t the first time. The session log calls it “the recurring forgot-to-compile-bundles-before-release trap,” which means it had already bitten before, gotten written up somewhere in the internal workflow docs as a step to remember, and bitten again anyway. A documented step in a workflow doc is not a gate. It’s a thing you read once, or don’t read at all if you weren’t the one who wrote it, and it does nothing at the moment a branch is about to merge. This ticket almost shipped the same way: three files still wired to /src/, caught by someone actually reading the diff before pushing rather than by any check in the pipeline.

Catching it by reading the diff carefully works until the day it doesn’t.

What actually stops it

The fix was to stop trusting anyone, including future us, to remember, and put the check where the ticket physically cannot close without passing it. The close-time guard does two things before a ticket is allowed to transition:

1. Scans every .asp file touched in the branch for a script reference under /src/. If a shipped page is still loading source instead of a dated bundle, the close fails immediately with the file and line.
2. For every dated bundle reference that is present, recompiles from the current /src/ source via the platform’s compile script and diffs the result against what’s actually referenced. If they don’t match, the bundle is stale, meaning someone edited the source after the last compile and never regenerated the file the page loads.

That second check is the one that matters more than the first. You can remember to flip a reference and still ship stale code, because the bug isn’t “forgot to point at a compiled file,” it’s “compiled once, then kept editing.” The guard doesn’t ask whether you remembered to compile. It recompiles for you and checks whether what you’re about to ship is what the source actually says.

The bracket display fixes shipped clean, refs flipped, bundles compiled, closed to Staging. The guard now sits in the close path for every ticket that touches a /src/*.js file, not just that one. The workflow doc still says the same thing it said before. The difference is that now something other than a person reading carefully has to agree before the ticket closes.

dxdev LESSON · paste into your AI coding agent
LESSON: A Guard That Recompiles And Diffs Beats A Workflow Doc That Says Remember To Compile
SOURCE: dxdev.com/blog/2026-09-10_release-gate-prevents-forgot-compile
WHAT HAPPENED: While iterating on tournament bracket UI fixes, the bracket-editor, schedule-slots, and schedule-build pages had been pointed at their /src/ source files for fast reload during development. That wiring needed to be flipped back to the compiled, dated bundles before the branch shipped, but nothing in the pipeline enforced it. The session log names this the recurring forgot-to-compile-bundles trap, already documented once in workflow docs and already bitten again despite that. The fix was a close-time guard that scans touched .asp files for lingering /src/ references and, more importantly, recompiles every referenced bundle from current source and diffs it against what's actually shipped, catching the case where someone compiled once and kept editing afterward.
THE RULE: When a failure mode has already recurred after being written down in a doc, stop relying on someone reading carefully and put an automated check at the point the work can't proceed without passing it.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Does merging or closing a ticket require passing an automated check, or only a documented manual step?
      2. For any generated/compiled artifact referenced by shipped code, is there a check that recompiles from current source and diffs it against what's referenced, not just a check that a reference exists?
      3. Has this exact mistake happened more than once despite being documented, indicating the documentation itself isn't the fix?
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.