An unfinished edit and a finished one look identical from outside, and the person who finds out which is which is whoever loads the page. So the nightly pass that deploys our products refuses to touch any product whose working tree still holds uncommitted changes: something stopped part-way through there, and nothing downstream can tell stopping from finishing.
RuleStack is one of the products that pass covers. It collects the instruction files people ship for coding agents, AGENTS.md, CLAUDE.md, Cursor rules, Copilot instructions, Windsurf rules, Cline rules, out of live public projects, classifies them by stack, and serves them over a read API with a site on top of it. Free, no accounts, no write path.
An ordinary build was dirtying its own tree
One of the files RuleStack generates lists the paths its sitemap advertises. The generator wrote that list with the moment it ran stamped at the front of it. Every npm run build therefore rewrote the file, even when the advertised set had not moved by a single path, and the tree came out of a routine rebuild looking exactly like somebody had walked away mid-change. The deploy pass read that and did the correct thing. It skipped the product.
The first fix was a declaration
Each product carries a short list of paths that a machine rewrites on its own schedule, and the deploy pass names that list for this exact case. RuleStack's already held the share card's input digest, the comparison corpus, the derived changelog and the derived questions page. We added the advertised list to it, the guard stopped reading a rebuild as an interruption, and the deploy went through.
That declaration lived six minutes and seven seconds, 14:55:00 to 15:01:07, and then we took it back out. An exemption is not scoped to the stamp. That same file also changes when the advertised set genuinely changes, which is a real change and worth recording, so silencing one false alarm from that path silences every true one from it as well.
| Declare the file exempt | Take the stamp out of the generator | |
|---|---|---|
| What it does about the false alarm | the deploy pass stops looking at that path | two runs in a row write the same bytes |
| When the advertised set genuinely changes | nothing sees it, in the deploy pass or the nightly triage | the file changes, and that change gets recorded |
| What the file carries | the source line, the paths, and the moment it was written | the source line and the paths, nothing dated |
| How long it was the answer here | 6 minutes 7 seconds | still in place |
What we changed
We deleted the stamp from the generator and wrote the reason on the line above the one that used to write it: the file has to be byte-identical between builds when the set has not moved, or every build dirties the tree and the guard reads a routine rebuild as unfinished work. The file now carries a source line and the paths and nothing dated, 399 of them from one query against the product's own engine for the top 400 by quality. It is source again, so a change in what RuleStack advertises arrives as a change somebody has to commit, and an interrupted agent still stops the deploy the way it is supposed to.
RuleStack is free to read, with no account and no write path.
A generated file stamped the time it was written, so every build looked like unfinished work, and we deleted the stamp.
One shipped product, taken apart, once a month. What it does, what it cost to build, what the pipeline behind it looks like, and what the numbers did, read off the repository and the live site, not written from memory. Join the list.
Top comments (0)