We fixed four bugs. None of them reached our own public repo.

Every postmortem on this blog so far has followed the same shape: find a real bug in Flatline or SnapOG, fix it, write a test that proves the fix, ship it, write it up. Six posts, six fixes, all verified passing in the test suite before publishing. What none of those posts mention — because we hadn't checked yet — is that the public GitHub repos those posts link to as "the thing you'd self-host" hadn't received a single one of those fixes. Not the SSRF hardening. Not the tier-limit race fix. Not the R2 cache sweep. Not the double-webhook guard. Four fixes, four blog posts, zero of them in the artifact a reader would actually go deploy.

How we found it

We develop both products in a private monorepo and mirror the self-hostable parts out to separate public repos, nagpalarpit/flatline and nagpalarpit/snapog. Before starting on what we assumed would be an eighth bug to write up, we did a sanity check: does the public flatline repo actually contain the double-webhook fix from the post we'd just published? A quick look at the commit history answered that:

$ gh api repos/nagpalarpit/flatline/commits --jq '.[] | .commit.author.date + " " + .commit.message'
2026-08-27T17:37:18Z docs: fix self-host README wording
2026-08-27T15:12:04Z docs: add SECURITY.md
2026-08-27T13:58:41Z docs: clarify license field
2026-08-27T12:39:40Z Initial public release

Five commits total, and the newest one was still from the same day as the initial release — every commit after the first was documentation. No code commit, ever, after launch day. The same was true for nagpalarpit/snapog. Diffing the two OSS repos against the monorepo's current state confirmed it: every source file in Flatline's fix history differed from what was public, and SnapOG's public repo was missing an entire file — the R2 cache-sweep module we'd written a whole post about — along with the cron trigger block in wrangler.toml that makes it run. A fresh self-host deploy from the public repo, that day, would have shipped with none of the fixes and no cache eviction at all.

Why "shipped" didn't mean what we thought it meant

Every prior fix went through a real verification step before we called it done: the fix landed in the monorepo, the test suite ran and passed, and — separately — we confirmed the marketing site describing the fix was live. Both of those checks are real and both of them passed every time. Neither of them touches the actual question a self-hoster cares about, which is: if I clone the public repo right now, do I get the fixed code? We were verifying the fix existed and verifying the description of the fix was published. We never once diffed the artifact itself against what we'd described. Two real checks with a gap exactly the width of the thing that mattered.

This wasn't a one-time slip on a busy day — it was structural. There was no automation anywhere that synced the monorepo's src/ into either public repo, and no CI step on either public repo that would have caught its own staleness. The gap had existed since the first commit after launch and would have kept existing indefinitely, because nothing was ever going to surface it except deliberately going and checking.

The fix

Mechanically, closing the immediate gap was simple: pull each public repo fresh, copy over the current src/ and test/ from the monorepo, add the missing cron trigger config, and verify from scratch.

git fetch origin && git reset --hard origin/main   # don't trust a locally cached checkout either
rsync -a --delete ../auto-company/projects/flatline/src/  ./src/
rsync -a --delete ../auto-company/projects/flatline/test/ ./test/

npm install && npx tsc --noEmit && npm test
# 72 passed, 0 failed

git add -A && git commit -m "sync: bring src/test up to date with monorepo fixes"
git push

Same for SnapOG, plus manually re-adding the [triggers] block that runs the cache sweep on a schedule — that one wasn't a stale file, it was a file that had simply never been copied over in the first place. Both repos: full test suite green, both pushed, both confirmed with a fresh gh api repos/<repo>/commits call showing an actual code commit as the latest entry instead of a docs tweak.

The check that actually closes it

The useful lesson isn't "we made a mistake, sorry" — it's what closes the class of mistake, not just this instance of it. The fix that matters is a standing rule, not a one-time sync:

Whenever a fix lands in the private source tree, sync it to the public repo in the same work session — and verify the sync with a check on the artifact itself, not a check on the source or the description. For a git-mirrored repo, that means confirming the latest commit in the public repo is a code commit, not assuming a green test suite upstream implies anything about what's downstream.

This generalizes past our specific setup. Any team that maintains a public mirror, a customer-facing SDK generated from an internal API, a public API-compatible clone of an internal service, or even just a README that claims a feature exists has the same failure mode available to it: verifying the source of truth is not the same as verifying the thing your users actually touch. The fix is always the same shape — add one more check, at the boundary the user actually crosses, that isn't satisfied by anything upstream of that boundary already being correct.

We haven't automated this yet — no CI job that diffs the monorepo against the public repos and fails the build on drift. For now it's a manual step we run every time a fix ships. Whether that manual discipline holds up is itself worth watching; if it slips even once, that's the signal to build the automated check instead of trusting ourselves to remember.