Two bundles stale, two different causes:
my-upg-100-list — my own alt-assertion work merged last tick, never published
gospel-resources — five commits landed on main since the last publish
★ RE-CLONED RATHER THAN REBASED. My first push was rejected: another agent
published 553b6ff (the base team's plugin library) between my clone and my push.
A plain rebase would have replayed my 24-bundle rsync -a --delete on top of
theirs, and a bulk file operation replayed against a state it never saw can
delete what that state added. Re-cloning and re-rsyncing means merging onto
their ACTUAL tree rather than a snapshot taken before it existed.
Verified afterwards: their README.md intact, identical bundle sets so nothing
deleted, and zero files touched outside app/doxa-maps. Only my two bundles
differ from their catalog.
Verified before push: 24 bundles, 22 manifest bundles resolving, 57 leaves with
zero unresolved script srcs, tree settled (waited out a concurrent build).
Three bundles stale — country-posters, gospel-resources, regions-dashboard —
all SAME SIZE, DIFFERENT HASH, which is why this is compared by sha384 and not
byte length.
Diagnosed before publishing rather than assuming. Source main had NOT moved
(zero commits since the last publish) and the catalog HEAD was still my own
previous publish, so neither end had changed. The bundles' mtimes settled it:
all three were rebuilt at 02:51:50, six minutes AFTER the 02:45:21 publish.
Another agent rebuilt in this shared worktree, and the rebuild compiled
translation refinements that were already committed but not yet in those
bundles.
The changes are deliberate corrections, verified present in main's committed
source and the superseded forms absent from it:
ru "Загрузить еще" -> "Загрузить ещё" (the ё it should always have had)
ru "Поиск по именам" -> "Поиск по названиям" (names -> titles)
ar "إبحث عن الأسماء" -> "ابحث عن الأسماء" (hamza corrected)
A token-set comparison shows 6 lost and 6 gained per bundle — the same strings
in better form, nothing dropped.
Verified before push: 24 bundles, 22 manifest bundles resolving, 57 leaves with
zero unresolved script srcs, zero bundles carrying the old broken asset path,
tree settled, diff scoped to app/doxa-maps.
The previous attempt at this publish (b7fea73, reverted as bb160bc) broke the
live map: resolveAssetsBase computed <treeRoot>/../assets, one segment too high,
so boundary geojson 404'd and the map painted a basemap with none of our data.
Fixed at source in 852310d0 -- the asset pool lives INSIDE the tree, which is
what a leaf's own '../../assets' has always meant and what generate-tree stages.
Now covered by check:embed-base, pure path arithmetic, mutation-tested against
the exact off-by-one.
Verified before push: 24 bundles, 22 manifest bundles all resolving, 57 leaves
with zero unresolved script srcs, boundaries present at the path the fix
targets, tree settled, diff scoped to app/doxa-maps only.
The catalog was serving a tree many merges behind the source. Measured before
this publish: 19 of 19 comparable leaves STALE by SRI hash, 0 current, and three
bundles absent from the catalog entirely (prayer-walk-planner, regions-dashboard,
upg-neighbor) while present in the build.
After: 24 bundles, 57 leaves, every leaf's baked integrity matching the bundle it
loads, every leaf script src resolving, and all 22 manifest bundles present on
disk.
Built tree verified settled before merge (builders=0, waiters=0, churn=0, quiet
465s) and scoped to app/doxa-maps only — no other team's subtree touched.
KNOWN PRE-EXISTING, NOT INTRODUCED HERE: app/index.json references 12
<bundle>.iife.js paths that no build produces. Zero .iife.js files existed in the
previous catalog commit and zero exist in the source tree, and the live site
already 404s them today while the .js files beside them serve 200. That file is
outside app/doxa-maps and is untouched by this publish.
