---
title: "routing-260420.js Shipped Truncated Redirects and Nobody Knew Which Command Built It"
canonical: https://dxdev.com/blog/bug-into-guardrail/
datePublished: 2026-04-25
---
Five days after the commit, a support report told us an account redirect was landing in the wrong place. We treated it as a one-line routing configuration mistake. We opened the production application's long-lived clone set and traced the legacy routing path, because that model made the fastest fix look obvious.

The file with the problem was `routing-260420.js`. Its date-like name showed when it was compiled and said nothing about whether the compile output was correct. Redirect destinations inside it had been truncated. The file threw no script error and the logs showed no failure. It held wrong strings in a minified artifact, and accounts went to the wrong destination until someone wrote in.

We recompiled with corrected settings, restored the redirect, and moved the hotfix through the branch stack. That took most of an afternoon. Then we counted 14 [dated script artifacts](/blog/cursor-rules-as-compiled-asset-map/) in the same folder.

## The minified artifact hid its own origin

The production application follows an older pattern. Source is compiled and minified into a dated artifact, and the artifact is committed. The name carries a date, but the commit never recorded the invocation that produced it. For `routing-260420.js`, the repository could not say which tool or options made the output.

We asked Claude to reconstruct that invocation from the repository context. It could not. There was no build script, no recorded target, and no note naming the command. Its best reading was that the artifact came from an ad-hoc process and was committed directly. That could make the truncation a one-time mistake, or it could be true of all 14 neighboring files. The repository had no way to decide between those without opening each artifact.

Nothing signaled the failure. There was no compile error to search for. For those five days the redirect used truncated destinations, and monitoring had no expected artifact content to compare the output against.

## The new build path recorded the process

We added two checks for future compilations. The first is an explicit configuration file for the minifier, so output comes from one repeatable configuration instead of an ad-hoc command. The second is a syntax check that runs on the output right after compilation. If either step fails, no artifact is produced for commit.

That protects new artifacts. It does not stop a developer or an agent from committing a file made through some other path, so we added a pre-commit hook. A dated script staged for commit gets the syntax check before the commit is accepted. A broken file fails the hook and the commit stops.

The production application has multiple clones on one host, each used for a separate development track. The shared hook directory is registered through a per-clone version-control setting, and a fresh clone does not inherit it. So the validation hook stayed absent until someone performed a configuration step. That was the same fragile reliance on memory that let the artifact through in the first place.

## The hook registers at session start

We put the hook-path registration into the session-start script that Claude runs when it opens a working directory. Each clone session now registers the shared hook path when it is missing, so the compile gate is present before the first edit in that clone.

That removes the remembered setup step from the normal Claude workflow. A clone opened outside that workflow can still commit directly, because it skips the session-start registration. Right now active development sessions all pass through Claude, so we are carrying that as a known assumption rather than a solved problem.

## The older artifacts remain unaudited

The original redirect is fixed. `routing-260420.js` contains the intended output and the account redirect works. The 14 other dated artifacts in the same folder are still unaudited. The pre-commit hook will block the next broken artifact, but it says nothing about one already committed. The audit is separate work, and it is still on the stack.

For every compiled file in production, someone should be able to say which command and settings produced it. Here nobody could, and the only way to find out is to open each of those 14 files.