Shortening /GIT/ URLs: a single-tenant URL has a redundant segment
Every link on this site that points at the source code passes through /GIT/:owner/:repo/.... The owner segment is always syntaxai. The repo segment is always tdd.md. The handler validates both, 404s anything else, and never reads them again. The user-visible URL is doing structural work for a multi-tenant case that doesn't exist.
Concrete example — the verifier source link:
before: https://tdd.md/GIT/syntaxai/tdd.md/blob/main/src/b32_sama_v2_verify.ts
after: https://tdd.md/GIT/tdd.md/blob/main/src/b32_sama_v2_verify.ts
Nine characters shorter. The change is small but the workflow it sits inside is the same one this site is built around — /goal slash command as contract, SAMA v2 as discipline, the verifier as anti-fudge gate. This post is the plan, written before the /goal fires.

#Why dropping the owner is safe
The relevant code is twenty-one lines down src/d21_handlers_repo_browse.ts:
const isAllowedRepo = (owner: string, repo: string): boolean =>
owner === LIVE_REPO_OWNER && // "syntaxai"
repo === LIVE_REPO_NAME && // "tdd.md"
SAFE_OWNER_REPO.test(owner) &&
SAFE_OWNER_REPO.test(repo);
The check is structural — there is exactly one allowed pair, and any deviation produces a 404. So the owner segment carries no information the handler couldn't supply itself. It's a position in the URL that exists only to make the URL look like a GitHub URL — which, given that the data is not on GitHub, is a costume rather than a contract.
The signature also drops to isAllowedRepo(repo). LIVE_REPO_OWNER stays in src/a31_site_config.ts — it's still the truthful owner for the backing git operations, the Forgejo proxy, and any future feature that needs to talk about provenance. It just stops showing up in user-facing URLs.
#The interesting design decision — one regex, not 49 redirects
A grep across the repo finds 49 references to the old URL form across 10 source files and 7 content files — link builders, hard-coded markdown in /sama/v2/verify, blog posts that point at specific files for their empirical claims, the verifier page itself.
Naive approach: hand-maintain a list of 49 old-URL → new-URL mappings as a redirect table. Cost: rewrites work today, but the list rots the next time someone adds a new file or blog post (50 grows to 60 grows to 100). Anti-pattern.
The right shape is one regex in the fallback handler that matches the pattern of the old URL and rewrites to the new one:

const oldGitUrl = url.pathname.match(
/^\/GIT\/syntaxai\/tdd\.md\/(.+)$/,
);
if (oldGitUrl) {
return new Response(null, {
status: 301,
headers: {
Location: `/GIT/tdd.md/${oldGitUrl[1]}`,
"Cache-Control": "public, max-age=86400",
},
});
}
Five lines. Covers all 49 known references and every future URL with the same shape. Cost: one commit. Lifetime maintenance: zero.
The 301 (permanent redirect) is the load-bearing detail — search engines treat 301 as "update your index"; they treat 302 as "this is temporary, keep the old URL." We want the index to converge on the new URL, so 301 it is.
#How this maps onto SAMA v2
The refactor touches files across three layers, all in expected ways:
| Layer | What changes |
|---|---|
Layer 0 · Pure (a31_site_config.ts) |
LIVE_REPO_OWNER stays exported — still the truthful owner constant, just no longer used to build URLs |
| Layer 1 · Core | No changes — there are no Layer-1 helpers in the /GIT/ flow; the URL surface is pure routing |
Layer 2 · Adapter (c14_git.ts) |
No changes — lsTree and readBlobAtRef already take (ref, path), never owner/repo |
| Layer 3 · Entry | All the changes live here — parseRepoBrowsePath callers, repoBrowseHandler signature, the Bun explicit route /GIT/:repo/commit/:sha, the new 301 redirect, and the link builders in b51_render_*.ts |
The layer surface tells you the refactor is contained — no Adapter changes, no business-logic changes, no test-of-pure-helper changes. Only the routing/rendering surface moves. That's the "small refactor" smell the Layer 2 stays empty sitemap post identified — when the change is genuinely about the URL surface, the deeper layers don't need to move.
#Anti-fudge — what the /goal rules out
The plan deliberately doesn't do these things, even though each is locally appealing:
- No hand-maintained list of redirects. One regex pattern covers all 49 current references and every future one. If the regex grows into "a list", the anti-fudge clause has been violated.
- No removal of
LIVE_REPO_OWNER. The constant has callers beyond URL construction (the live-reports view, the Forgejo proxy hostname). Removing it froma31_site_config.tswould be a different, larger refactor that the URL change shouldn't drag in. - No touching of git-protocol URLs.
/syntaxai/tdd.md.gitand the bare-repo view at/syntaxai/tdd.mdgo throughisGitProtocol+repoMatchind21_handlers_fallback.ts. Those URLs are git-client-facing — agents and humans have copy-pasted them into clone commands, into CI configs, into other agents' system prompts. Changing them risks breakage for cosmetics. They stay. - No alias. Both URL forms working forever creates two canonical URLs and lets the old one quietly remain in new code. The 301 is what forces consolidation — search engines update, internal code paths rewrite themselves, and a year from now the old form is just a redirect line in one file.
- No verifier change.
/sama/v2/verifystays at 7/7 ✓ across the merge. The §4 check logic is frozen; if a structural choice the refactor wants to make would fail the verifier, the choice changes — not the verifier.
#The work, sized
Three categories of file change:
- Wiring (4 files): the fallback handler gets the new redirect + the parse regex drops
owner; the explicit Bun commit route ind21_app.tsbecomes/GIT/:repo/commit/:sha;repoBrowseHandlerandcommitViewHandlerlose theownerargument;isAllowedRepocollapses to one argument. - Link builders (3 files):
b51_render_repo.ts(eight call sites — breadcrumbs, parent-dir, raw/source links),b51_render_commit.ts(two call sites),b51_render_edit.ts(one hard-coded URL). - Hard-coded markdown (7 files):
content/home.md,content/sama/v2.md, four blog posts that point at specific source files for their empirical claims,src/d21_handlers_sama.ts:137(markdown embedded in the verifier page body). One sed pass, all done.
The test files (b51_render_repo.test.ts, b51_render_commit.test.ts) pin the rendered URL strings — those expectations update mechanically with the link-builder changes. Test count stays at 379+; no test count regression.
#Live-verify clauses
What the /goal requires to verify after deploy, not just in CI:
$ curl -I https://tdd.md/GIT/syntaxai/tdd.md/blob/main/src/b32_sama_v2_verify.ts
HTTP/2 301
location: /GIT/tdd.md/blob/main/src/b32_sama_v2_verify.ts
$ curl -L https://tdd.md/GIT/syntaxai/tdd.md/blob/main/src/b32_sama_v2_verify.ts
HTTP/2 200
< file content >
$ curl -s https://tdd.md/GIT/tdd.md/tree/main | head -1
< 200, directory listing HTML >
$ curl -s https://tdd.md/sama/v2/verify | grep -o '7/7'
7/7
Plus the silent live check: every blog post on the site has its /GIT/ links rewritten, so clicking any "view source" link in any of the empirical-chain posts lands on a working URL — no broken navigation surfaced after the merge.
#What lands when this ships
After deploy:
- Every
/GIT/URL on the site uses the new shape. - The verifier source — the URL search engines and AI crawlers should index as "the artifact this site's argument rests on" — gets shorter and more readable.
- Old URLs already indexed by Google, cached by Twitter card scrapers, sitting in someone else's blog post, or pasted into someone's notes file all permanently-redirect to the new form. Index reconverges in a search-engine refresh cycle.
/sama/v2/verifycontinues to report 7 ✓ / 7.- One new pattern — the regex-as-redirect — surfaces a reusable shape for future URL refactors. If the site renames
/sama/v2/example-crudto/sama/v2/examples/crudnext month, the same shape applies.
#Companion postmortem
This is the plan. The postmortem will follow after the merge with:
- The actual file diff (likely tight — most line changes are mechanical
s/syntaxai\/tdd\.md/tdd.md/gsubstitutions). - Whether the regex caught everything (especially in places
grepmissed — embedded HTML strings, multi-line URLs, etc.). - The
/sama/v2/verifyoutput before and after the merge. - Anything the anti-fudge clauses caught that the plan missed.
If the refactor lands cleanly with the regex absorbing all 49 references — that's the data point: pattern-as-redirect is a reusable shape, and the next URL refactor needs ten lines plus a sed pass.