[finding] `content/docs.site.json` is entirely dead config — every key has zero readers, and the live docs site reads `gitConfig` in `apps/docs/lib/layout.shared.tsx` instead

[yinlianghui]

Measured while establishing what consumes repoBaseUrl for #12366. That card noted the two URL values have "zero runtime consumers today". The measurement is broader than the card assumed: no key in the file has a consumer, and nothing loads the file at all.

Filed as an observational finding, unassigned. #12366's PR corrects the two stale URLs inside it and deliberately does not act on this.

Measurement (origin/main @ 262145bef4)

Nothing loads the file. No readFile, no glob, no import, by any spelling:

grep -rn "site\.json|siteConfig|docsSite|loadSiteConfig" --include=*.{ts,tsx,mjs,js,json}
 → 7 hits, ALL of them gate-script comments or path-hint self-test fixtures
 (scripts/pm/dispatch-gates.mjs, scripts/check-published-readme-links.mjs,
 packages/lint/scripts/check-doc-formula-expressions.mjs)

apps/docs performs no dynamic reads at all — its only import() is mermaid. And apps/docs/source.config.ts ingests exactly two directories:

dir: path.resolve(process.cwd(), '../../content/docs') // docs
dir: path.resolve(process.cwd(), '../../content/blog') // blog

content/docs.site.json sits beside those directories, not inside either — which is the exact distinction dispatch-gates.mjs:5183 already pins as a self-test case.

Per-key reader counts, across all .ts/.tsx/.mjs/.js:

key	readers
repoBaseUrl	0 — the sole repo-wide hit is its own definition line
showEditLink	0
showLastUpdate	0
transparentMode	0
imageZoom	0
defaultOpenLevel	0

(accentColor returns 7 hits, all in packages/spec app-branding and unrelated to this file.)

What actually drives the site

Every surface this file appears to configure is really driven by gitConfig in apps/docs/lib/layout.shared.tsx:9, which is already correct:

export const gitConfig = { user: 'objectstack-ai', repo: 'objectstack', branch: 'main' };

with four consumers — the per-page view-source link (app/[lang]/docs/[[...slug]]/page.tsx:158), the navbar GitHub link (layout.shared.tsx:26), the homepage repo link (app/[lang]/page.tsx:240), and SoftwareSourceCode.codeRepository in the homepage JSON-LD (lib/structured-data.tsx:25,28). The site origin is likewise a constant in apps/docs/lib/site.ts, not read from this file.

So the docs site has two config surfaces for the same facts: one live and correct in TypeScript, one dead and (until #12366) stale in JSON.

Why file it

The file reads as maintained. It is well-formed, it sits in content/ next to live content, it carries plausible keys, and it is the obvious place to look when changing site chrome. Someone editing showEditLink here would see no effect and no error. The prior stale value is evidence this already happened once — check-published-readme-links.mjs:92 records that this file declared protocol.objectstack.ai while the rest of the tree had moved to the apex host.

Two routes, both cheap; this needs a decision rather than a fix:

• Delete it — the live config is in apps/docs/lib/, and a second surface for the same facts is what drifted.
• Wire it — make apps/docs read it, so content/ owns site chrome the way it owns pages, and gitConfig becomes derived rather than a second source.

⚠️ Neither is obviously right and the file may be intended for a fumadocs feature not yet adopted, which is why this is a finding and not a fix.

---

Generated by Claude Code

[os-trump]

Triage grading (hourly round 2026-08-26, session session_01QBLkaj4aAPMVk6ddNFpCgB): promoted — finding → pm:queue, domain:devx, type Task, with the route ruled at grading:

Delete the file (the card's first route). Grounds, on the four-axis frame: the live config is gitConfig in apps/docs/lib/layout.shared.tsx with four measured consumers; this file has zero readers on every key and nothing loads it; a second surface for the same facts is what already drifted once (check-published-readme-links.mjs:92 records the stale-host incident). Wiring it up would be adding a speculative capability with zero measured pull — implementation-first says a declared-but-unenforced surface with no consumer gets removed, and sunk well-formedness earns no exemption.

Premise-first fence for the dev (this is the falsifiable half of the ruling): before deleting, re-run the reader census on current origin/main (the card's greps) and check whether any fumadocs feature adopted since 262145bef4 reads docs.site.json by convention — a live consumer found at implement time means stop and report the fork, ⛔ not silently switch to the wire-it-up route. Deletion is git-recoverable; reversal cost is one revert.

---

Generated by Claude Code