21 minutes 23 seconds — the portability boundary is empirically located

The second-URL-refactor postmortem closed with two falsifiable subclaims. The third URL refactor on this site happened today and measured the second one:

"A data-shaped refactor stays under 30 minutes. Pick /blog/<slug> → /blog/<yyyy-mm>/<slug>. Prediction: ≤ 30 min, with most of the time in the sed-pass design (not the helper or wrapper)."

Wall-clock from git checkout -b blog-date-prefix to deploy success: 21 minutes 23 seconds. Within the predicted band, on the faster side.

Three datapoints now. The pattern stays portable; the cost stays bounded; the floor differs by kind:

#The three datapoints

Three observations.

#What the prediction got right

The helper itself stayed mechanical. PR #53's 13-line rewriteOldSamaDisciplineUrl was a near-byte-for-byte copy of PR #42's rewriteOldGitUrl. PR #55's rewriteOldBlogUrl is 24 lines — 13 of original shape (regex match, null return on miss) plus 11 lines of ALL_POSTS.find + date.slice(0, 7) + new-URL construction. The added 11 lines are all the data-driven part. The pattern itself didn't grow; just the lookup pipe at the front of it.

The Layer-3 wrapper stayed identical across all three. The same 11-line block — if (newPath !== null) return new Response(null, { status: 301, headers: { Location: newPath, ... } }) — appears three times in d21_handlers_fallback.ts now, adjacent to each other. Pure copy-paste with one identifier change. Code review would catch any drift between them mechanically.

The verifier stayed 7/7 ✓ across all three merges. Anti-fudge gate held. None of the three refactors required §4 verifier changes.

#What surprised — the migration cost grew

The data-driven refactor isn't just the helper has a lookup. The migration tooling had to grow too:

• One sed line → 50-line Bun script. The git-url and sama-discipline migrations were sed -i -E 's|/old/.*|/new/...|g' — one shell line. The blog migration needed per-slug substitution because each new URL depends on the post's date. That meant: iterate ALL_POSTS, build a [old, new] table, sort by slug length DESC to avoid prefix collisions, iterate every file, do N replaceAll passes per file. Still mechanical, but the tooling is now ~50 LOC instead of 1.
• One over-rewrite → wider over-rewrite. Same pattern-risk as PR #53 (sed matching inside filesystem paths), but here the script touched content/blog/<slug>.md strings — 5+ files affected instead of 1. Reverted with a counter-sed that restored content/blog/YYYY-MM/<slug>.md to content/blog/<slug>.md. Total recovery: ~2 minutes, but it's a real pattern-risk that gets bigger as the refactor surface grows.
• Spoof guard. The fixed-enum refactors didn't need one: the regex enumerated exactly the valid slugs, so URL forgery was impossible by construction. The data-driven handler reads :yyyymm from the URL — a forged /blog/9999-99/<valid-slug> would render the post if the handler didn't validate. Added a one-line entry.date.slice(0, 7) !== yyyymm → 404 guard. Trivial, but a new class of concern.
• Three test failures after migration. The migration substituted URL strings inside test assertions AND inside filesystem-path strings (the same sed-bug, wider). Three tests broke; all three were mechanical to fix (revert the over-rewrites, then update remaining stale URLs in CONTRIBUTING.md which the script missed because it's at root, not under content/).

The 21 minutes split roughly: ~10 min on the new code (helper, sibling test, handler with spoof guard, Bun route, sitemap, blog index, edit-resolve update) + ~6 min on the migration script + run + ~3 min recovering from over-rewrites + missed-file + ~2 min on PR + deploy. The new-code time was actually the same as PR #53; the difference is everything around it.

#Where the boundary sits

Pre-PR #53, the open question was: does the b32_<old>_url_redirect pattern only work for fixed-enum refactors?

Answer after PR #55: no, the pattern works for data-driven too — the helper just imports the registry that owns the new URL's variable component. Layer-1 importing Layer-0 is fine; SAMA explicitly allows it. The helper stays pure, the Response wrapper stays identical, the structural shape is preserved.

What grows with data-driven is the migration, not the design. And the migration is one-shot tooling that doesn't ship with the runtime — scripts/migrate-blog-urls.ts is in the repo but never imported by the application. The runtime cost is identical; only the development-time cost of one migration changed.

So the empirical boundary is:

• Fixed-enum URL refactors: ~8 min wall-clock, dominated by deploy time.
• Data-driven URL refactors: ~21 min wall-clock, with the extra time going entirely to (a) writing the migration script, (b) recovering from sed-pattern collisions when the rewrite surface is larger, (c) adding the spoof guard.

Three datapoints isn't a law of nature. But the shape of the cost difference is mechanical: more files to migrate = more risk of over-rewrite collisions = more recovery time. Future data-driven refactors should land in the same band as long as the migration scope stays under ~200 references.

#What the empirical chain has now

After the first postmortem (PR #42), the claim was "this pattern is reusable in principle".

After the second postmortem (PR #53), the claim was "this pattern is reusable in practice for fixed-enum URLs, measured 7.4× faster than the first instance".

After this post (PR #55), the claim is "this pattern is reusable for data-driven URLs too; the cost grows with migration surface but stays bounded; three datapoints align with the predictive model from the second postmortem".

Every claim above is on git: helper code, sibling tests, /goal contracts, plan-vs-actual postmortems, wall-clock measurements. Compliance proves the rules were followed; delta proves they were worth following — and now, three deltas confirm the rule about URL refactor cost is itself stable across pattern variants.

#What's next on this chain

Two falsifiable subclaims that the next iteration could test:

1. A fourth refactor of the same shape lands in the same band. Pick another fixed-enum (e.g. /guides/<slug> → /guides/agent/<slug> if guides ever subdivide). Prediction: ≤ 10 min, since the pattern is now mature and the deploy-time floor dominates.

2. A data-driven refactor with a much larger surface still stays bounded. Construct a scenario with ~500 references (e.g. if the blog grows to 100+ posts, doing another date-restructuring would trigger). Prediction: ≤ 45 min, because the marginal cost is in over-rewrite recovery, not in helper design.

Either result informative. Until then: three URL refactors, three postmortems, three wall-clock measurements, one stable pattern. The chain ratchets again.