Two gaps in the build-owner tooling, found by rega while landing 13f5f3a3:
- check:composite-freshness judged only COMPOSITES. A library change (bd75f609's Arabic catalogue:
library/i18n eager-loads every locale into every bundle that uses it) left 12 of 25 bundles stale on main,
most of them not composites; my consumer rebuild d1af039a saw none of it. The check takes --all and
--bundles a,b; the landing precondition scopes it by what the landing changed (shared code -> every
bundle; otherwise composites + the bundles whose own folder changed); the build-owner landing always
uses --all. Proven: at d1af039a it names prayer-walk-planner STALE (0b695f70 vs 0042dda2, rega's numbers);
on main 13f5f3a3 --all finds the 12.
- fix:sri repaired manifest.json but not the Research Gallery's byte-identical copy
(doxa-maps-spa/manifest.json, read first on a foreign origin), so an embedded gallery refused a rebuilt
bundle; it now rewrites the copy too (tested: a changed bundle -> both repaired, identical, check:sri
PASS). And generate-tree now writes the front page's integrity itself, so `bun run tree` after fix:sri no
longer strips it (tree alone: 115 agreed, 0 added).
The output tree's name has always been configurable (vite.doxa-maps-build-config.json "name"),
but 61 tooling files ignored it and hardcoded 'doxa-maps' (181 literals), so a rename would have
moved the build while the gates kept reading the old folder.
- internal/_tree-name.mjs reads it once (validated as one URL-safe path segment; falls back to the
historical name) and exports TREE_NAME / TREE_NAME_RE; `node internal/_tree-name.mjs` prints it
for shell scripts.
- A codemod rewrote 171 literals in internal/ to TREE_NAME; the regex literals, messages with
backticks, atomic-public-swap.sh (fails loudly if the name cannot be read), build-lock.sh and
vite.config.js (its duplicate readMfeName is gone) were done by hand.
- The name is unchanged: old and new tooling produce all 1408 files under public/ byte for byte.
Code lines still naming the tree in internal/ + vite.config.js: 2, both intended (the helper's
fallback, the private-repo-name pattern in public-hygiene-check).
This renames nothing visible; the eventual rename becomes a one-line config change.
check:sri failed whenever a single-bundle `BUNDLE=x bun x vite build` left a
leaf's baked integrity behind its bundle — and the gate then told the agent the
fix was `bun run build`, whose first step deletes public/doxa-maps/ and tears
the tree out from under every concurrent reader.
Adds `bun run fix:sri`: rewrites the disagreeing hashes in the built tree and
nothing else — leaf <script integrity>, manifest bundles[].integrity, and the
paste-verbatim embed snippets. 0.4s, writes only the offending pages, and the
bytes it writes are identical to what the full build wrote.
check:sri's failure text now prescribes that instead of a rebuild, and its
header no longer claims generate-tree runs only inside the full build (it does
not; `bun run tree` re-bakes the hashes too, at the cost of rewriting 1234
files under public/ and re-reading .vue source every run).
Negative-tested: `node internal/fix-sri.mjs --self-test` builds a poisoned
synthetic tree, requires check:sri to go RED on it first, then green, then a
second repair to write zero files.
