The Regions bundle shipped only tab 1, so the Select View switcher the
UPG-100 list shows had nowhere to live. Adds the composite that carries
it over two panes -- Regions List and Region Dashboards -- plus the
Region Dashboards tab itself, which summarises a region or a country
from the same live endpoint and the same rollup tab 1 uses.
Clicking a region heading or a country row on tab 1 now forwards that
selection and swaps to tab 2 with it applied.
The switcher itself is extracted into library/components/ViewSelect.vue
rather than copied a third time: it had two implementations already, in
the app shell and hand-copied into upg-100-mfe. It takes the views and
the current id as props and knows nothing about maps or panes, so the
placement stays with each header. UPG-100 now renders from the shared
component and is unchanged on screen -- same 45px height, 13px labels,
8px radius.
The code for this landed inside the preceding commit -- a concurrent worktree
staged it before this commit could run -- so this records what changed and how
it was measured.
Dragging the bar at the dashboard's bottom edge added about three inches of
height on the first pixel of movement, then tracked correctly afterwards.
--rd-shell-h is not the element's height. The shell is height:auto when it is
page-scrolling, and the variable's only consumer is the table grid's
max-height: calc(shell-h - map-h - bar - foot), so it budgets the map and the
table and excludes the 141px of chrome stacked above them. The drag treated the
cursor's Y position as the new height, which published a budget with the chrome
counted twice: the grid's ceiling jumped 300px to 444px on the first frame and
the element grew 144px with it.
The drag now anchors on the budget the stylesheet is actually resolving and
adds the pointer's delta, so the first frame re-publishes the value already in
effect and every later frame moves 1:1 with the cursor. That anchor reads the
computed variable when one is set, because the budget is a ceiling rather than
a floor and the element can render smaller than it -- a restored 983px budget
measured 743px on screen, which had the first frame snapping 239px the other
way. It falls back to measuring map + table only when no variable is set, since
the stylesheet's 80svh default cannot be read off the stored number at any
viewport other than 900px tall.
Measured at 1440x900 with dispatched mouse events, with and without a stored
layout: 1px moves the edge 1-3px, 120px moves it 120-122px, dragging back up
100px shrinks it 100px, and the height holds after the button is released.
Both maps drew their legend as a full-width strip (left:8px right:8px --
measured 1264px of a 1280px map, 98.75%), which ran underneath the floating
control rail. MapToolbar sits at inset-inline-end:3px with 32px buttons, so
any box reaching right:8px intersects it at every viewport; the rail's higher
z-index kept the buttons clickable, which is why the defect survived three
reports as "looks broken but works". Gospel ran under four of five buttons,
cities under two, the difference being only legend height.
The legend is now a bounded, left-anchored panel imitating the shared
SemanticTreeLegend: left:8px with width var(--map-legend-width,380px). Being
bounded on the left, it cannot reach the right rail at all -- a geometric
guarantee rather than a tuned z-index. Below 480px it keeps a 46px gap so the
rail still clears. Measured after: legend 380px of 1280 (29.7%), zero
intersection with all five buttons, 857px clearance, and a dispatched click on
the top control landing on button.mcb via composedPath. Mobile at 390px: 336px
wide, 11px clearance, zero intersections. Both files kept byte-identical.
Both maps also showed the shared "Tap a coloured dot" hint while shading
country polygons and drawing no dots at all -- a hint pointing at something the
reader cannot see. PinHint documents a pinHint:false opt-out, but the
standalone leaf page built its config from a hardcoded object, so no profile
could reach that key. <profile>.meta.json now carries an optional `config` map
merged into the leaf's BASE_CONFIG, with generator-owned keys reserved and the
carrier stripped before the manifest is written so its published shape is
unchanged. Both maps opt out; the hint is gone from both.
The code box was max-height:90px + overflow-y:auto, which clipped a ~4-line
embed snippet to about two and a half lines and put a scrollport inside a
popover. Wrong trade for this content: the box exists to be read and copied
in one glance, and user-select:all means a single click selects the whole
snippet -- a scrollport fights that gesture, because the selection extends
into content the reader never saw.
height:auto lets the snippet size itself. The popover is short-lived and
anchored, so the extra lines cost nothing.
Measured on the demo-map leaf after opening the "Add to Your Website" tab:
max-height none, scrollHeight 110 == clientHeight 110, scrolls false.
Library change, so it reaches every bundle that mounts the share control on
the next full build.
At world zoom the dots were radius 4 with a 1.2px halo -- the same scale
all-people-groups uses for ~12,379 marks, where density itself carries the
signal. This map draws ONE HUNDRED, alone on a whole planet, so the same
radius reads as almost nothing.
Radius 4 -> 6 at z=1 (+50%), tapering back to the original 9 by z=8 where
geography supplies the context. Halo widened 1.2 -> 1.8 in step, so it stays
a frame rather than a smudge: a 1.2px ring around a 6px dot is
proportionally thinner than around a 4px one, which would have spent the
size increase and lost the contrast that made small dots findable at all.
Verified in the shipped bundle: new interpolation present, old values gone,
0 data 404s, legend mounts, canvas at real height.
:host carries height:100%, which the fixed-viewport host needs and a
page-scroll host must not have: in a tall scroller, 100% is thousands of px,
so the element claimed a large empty tail below its own content. The shell
inside already switched to height:auto for this reason; the host never did.
A host cannot be matched by a class on its own descendant, so the pageScroll
flag is reflected outward as a data attribute and :host([data-page-scroll])
switches to height:auto with the min-height dropped.
Labelled UNPROVEN in the file, deliberately: dashboard-plus-grid imports this
as a plain Vue component rather than mounting the custom element, so the rule
is not reachable from there -- and that composite was measured stacking
correctly regardless (dashboard 0..864, grid 864..3031, gap 0). The rule
applies where research-dashboard is mounted as its own element.
The UPG-100 legend was pinned 58px below the map top by a profile !important
rule whose job was to clear the geocoder pill. Measured with a real token in
both hosts: the standalone leaf DOES mount the geocoder (top 12, h 35), so 58
is correct there; the cap-5 shell mounts NO geocoder at all, so the same rule
stranded the legend below a pill that was not there -- the dead gap reported
repeatedly.
One host must not be fixed by breaking the other, so the offset is now
conditional on the pill existing: default 8px, pushed to 58px only when
:has(.mapboxgl-ctrl-geocoder) finds a rendered pill in the tree.
Also parameterizes the shared SemanticTreeLegend's offset as
var(--stl-top, 60px) with the max-height mirroring it, so any profile that
drops its search bar can raise its legend without an !important arms race.
Measured after: leaf legendOffsetInMap=58 with geocoder present; shell
legendOffsetInMap=8 with no geocoder. Full authoritative rebuild included --
composite freshness PASS, SRI PASS 45/45.
Every composite bundle (one whose manifest entry carries `composes`) now
gets its own collapsible folder in the rail, with the composite itself as
the top row and its composed children underneath, grouped/labelled the
same way the existing capability-tier rail already is. Reuses the
existing folder collapse/expand mechanism (VerticalTabsLayout, the same
one Experimental already uses) rather than inventing a second
interaction. Driven entirely from manifest.json's composes edges, so a
future composite needs no code change to appear. A child can legitimately
appear in more than one section (e.g. people-groups-grid nests into four
different composites) — that duplication is the point, not a bug.
Dragging the map/table divider in page-scroll mode was also resizing the
whole element, because --rd-map-h alone answered both "how is the map/table
space split" and "how tall is the element" -- Driver: "you improperly bound
that control to the separator line between the map and the table... that's
not the request I was making to resize the height of the page."
--rd-shell-h is now the independent total-height budget; the new bottom
handle (.rd-rz-shell) is the only thing that writes it. The existing
map/table divider still drives --rd-map-h, but only as the map's share of
that fixed budget, so it redistributes between map and table without
changing the sum. Table/facets/rail max-height all re-derive from
--rd-shell-h so the sidebars keep spanning exactly map+table at every drag.
Also closes a 28-30px sidebar gap the re-derivation exposed: the table
budget only ever subtracted the header bar's height, never the summary
footer's, so facets/rail undershot the table's real bottom edge.
The fieldset is anchored bottom:-26px and grows UPWARD as content wraps, so
at one-button-per-line (three lines tall) its top reached into the image --
which is where the blue hover outline lives. Widened the row from 82% to 96%
so two labels share a line.
Measured on all three poster cards at 1440x900: 2 button lines, height 50px,
top 3px BELOW the image bottom, zero overlap with the outline.
Includes the tree regeneration so every leaf's SRI matches its bundle
(a scoped BUNDLE= build alone leaves leaves stale -- check:sri PASS 45/45).
The default label was "Tap a red dot -- someone still needs prayer" and it
shipped on every map: pinHintLabel is an override no profile has ever set,
and pinHint:false is an opt-out no profile has ever used (verified: zero
occurrences of either across plugin-designs/).
So cities-with-internet and gospel-resources, which have no red dots,
invited readers to tap one; and UPG-100, whose dots are a four-colour
reached/unreached scale, named the wrong colour. A hint describing
something the reader cannot see makes a working map look broken.
Fixed at the default rather than per profile, because the defect was a
default asserting more than it could know. A shared component cannot know
what colour a given map's dots are, so it no longer claims one. Profiles
that do want to name a colour still can, via pinHintLabel.
Reported 5+ times by the Driver.
The original poison froze map.scrollZoom.disable() to a no-op, reproducing
syncScrollZoomToHost's old conditional-disable defect. That code path is now
dead: the panel calls .enable() unconditionally and nothing calls .disable(),
so poisoning it exercised nothing and the self-test could not fail for
clause C.
A negative test that cannot fail is the same hazard as a gate that cannot
fail -- it certifies the gate as working while proving nothing about it.
Self-test passes: the poisoned build is correctly rejected (clause=A),
14/16 clause-checks PASS.
Bundles that declare composition in their profile meta.json (composes:
[...]) now carry that array on the manifest's bundle object, so a
consumer like the plugin studio can render the composition tree without
re-deriving it. 7 bundles affected: big-picture, dashboard-plus-grid,
research-map-plus-grid, my-upg-100-list, stack-demo, doxa-maps-spa,
plugin-studio. Omitted for bundles with no composed children.
"Agents never run the full build" is already a top-level heading in
AGENT-BRIEF.md, and the research that established it was three hours old.
It was violated anyway -- by a dispatch prompt that said `bun run build`
while telling the agent to read the brief first. The clean step then wiped
public/doxa-maps mid-probe and an unrelated bundle read back as "did not
mount", one step from a fictional defect in a file that was fine.
Documentation cannot fix that; an explicit instruction beats a standing rule
at the point of work. So the build refuses with exit 75 and prints the
cheaper paths (bun run tree, BUNDLE= vite build, settled-tree-gate) unless
BUILD_ALLOW=1 is set.
Opt-in rather than caller-detection, deliberately: the first draft keyed on
two environment variables that do not exist in a spawned process -- a guard
that could never fire. A probe then reported a third variable as the
discriminator; it is set in the parent too, so it marks any session rather
than a child. No environment variable distinguishes them.
Negative-tested both directions: no flag exits 75 with the refusal,
BUILD_ALLOW=1 reaches "build lock acquired".
29 built files were rebuilt but uncommitted, including manifest.json -- the
file the cap-5 shell fetches at runtime to decide what to mount. Committed
source and committed output disagreeing on an SRI hash makes the browser
refuse the script, which presents as a blank pane and reads exactly like a
mount failure.
Diff is hash churn only, no structural change.
check:sri PASS 45/45, check:composite PASS 23 edges, settled-tree PASS.
Shadow CSS is emitted inside a JS template literal, so a backtick in a comment
terminates the string and the bundle stops compiling. Second instance in this
file; the first one already cost a broken build this session.
The side columns stopped at the map's bottom edge, leaving the people-groups
table outside them. Cause was a single rule capping both side columns at the
map's height in page-scroll mode:
.rd-shell.rd-page-scroll > [data-region="facets"],
.rd-shell.rd-page-scroll > [data-region="rail"]{ max-height:var(--rd-map-h); }
The grid already spanned both rows correctly ("facets map rail" / "facets table
rail") -- this max-height was overriding it, which is why earlier passes that
adjusted the rail's CONTENTS never moved the bound. Replaced with min-height:0,
letting the grid do the bounding it was already doing.
Facet rail sections people/place/language/religion open by default again, with
.fr-body's own overflow-y:auto providing the scrollbar.
Measured, both hosts, 1440x900, real browser:
dashboard-plus-grid (page-scroll): facets 140..2158, table bottom 2158, delta 0
research-dashboard (fixed-viewport): facets 140..900, table bottom 900, delta 0
facet rail scrolls: scrollHeight 1966 in clientHeight 708
The gate had been printing a NOTE on every green run: "the tree has outgrown its
floors (leaves 46 vs floor 40, dirs 23 vs floor 17) -- they still catch a
CATASTROPHICALLY gutted tree but no longer a partial one." It was right. At a
floor of 17 it would have passed a tree missing eight directories.
That matters more than it sounds. A totally wiped tree announces itself; a
PARTIAL one is the state that produces a confident false measurement -- "that
bundle is missing", "the dashboard tab does not exist" -- which this flight has
already paid for several times over.
MIN_DIRS 17 -> 21 (the manifest's current bundle count, the number that grows
when a plugin is added, leaving headroom against the directories on disk).
MIN_LEAVES 40 -> 44 (two leaves of headroom for a mid-build transient).
Deliberately NOT derived from the live tree: a floor computed from what is there
can never notice that something is missing.
Negative-tested 5/5: healthy 25/46 passes; the OLD floors exactly (17/40) now
FAIL as the partial wipe they are; losing 5 dirs fails; losing 3 leaves fails;
mid-clean fails. And it still exits 0 on the real tree, with the stale-floor
NOTE gone. check:mjs-parse passes.
These floors stay coarse by design -- check:embed-targets remains the
load-bearing assertion that every embed.iframe target actually resolves.
Clauses B and C(below-map) wheel-tested at hardcoded y=800 and y=850. Those were
tuned when the dashboard band measured ~1213px. A later fix dropped the
page-scroll map default from 58svh to 40svh to satisfy clause A, shrinking the
band to ~892px -- so both coordinates stopped being "below the band" and started
landing INSIDE it, on .rd-td, the table's own windowed scrollport, whose
~54,500px internal scroll a bounded gesture can never exhaust.
★ The product was fine the whole time. A real gesture from a natural cursor
position (y=870) moves the grid 2159px, fully reachable. The gate was failing on
its own staleness and reporting it as a product defect -- the most expensive kind
of wrong a gate can be, because it sends someone to fix working code.
Both points now derive from the band's measured bottom: 20px clear of it, never
past the fold, floored at 120px. Verified across four band heights including the
degenerate ones -- at the current 892px band it resolves to y=870, precisely the
position where the real gesture was measured; at a band taller than the viewport
it clamps to the fold, where clause A is the clause that should be failing
anyway; and it stays sane when the band cannot be found at all.
Found by two agents who cross-verified each other with elementFromPoint rather
than geometry inference, and who correctly declined to patch a shared gate file
a third agent had already touched today -- they routed it instead.
check:mjs-parse passes.
Driver: "I can't zoom in and out on the map. The scrolling is causing that
to change." Scroll-zoom was force-disabled whenever an ancestor scrolled, a
fix from when the dashboard band had no bounded height and a wheel over the
map was the only gesture available in the lower two-thirds of the page.
--rd-map-h changed that precondition: the map row is now a fixed, bounded
height, so the cursor naturally leaves it once a user scrolls past. Verified
on the live mapboxgl.Map instance (not a pixel-diff proxy): zoom now moves
1.45 -> 1.95 on a wheel over the map in the cap-5 shell, standalone
dashboard-plus-grid leaf, and standalone research-dashboard leaf, with no
change to pane scroll position in any of them.
TWO SMALL FIXES, both Driver-reported by eye.
LABELS. The fieldset's legend already reads "Print Options", so "Print a" in
every button was three redundant words competing for the row's width, and the
printer emoji beside that legend added no information. Labels are now the object
only -- "UPG-100 list" / "UPG prayer poster" / "card deck" -- which fits two on
the first row and one on the second, as asked.
The aria-label keeps the full sentence ("Print the <list> UPG card deck"): a
screen-reader user does not get the legend's framing as reliably as a sighted
user reading down the fieldset, and a control announced as "card deck" alone is
ambiguous. Short visible label, descriptive accessible name.
POSITION. The options row overlapped the poster artwork by 12px. My first
measurement said that 12px was letterboxed white margin, because the image is
object-fit:contain -- but these posters fill the card's WIDTH, so contain
letterboxes at the SIDES and the bottom 12px is real artwork. Reading the
screenshot showed the legend printed across the poster's own footer line.
Geometry said white space; the image said otherwise.
bottom:-14px -> -26px. Overlap measured 12px -> 0px, and the screenshot now
shows the poster's footer text fully legible with the legend on the card's white
edge below it. The negative offset is kept rather than moving the row into flow,
because the tape header at top:-11px uses the same overhang idiom and the 26px
row gap was sized for that pairing.
On its first real verdict, clause E failed on ALL EIGHT viewport/target
combinations with docOverflow=0 and the same two elements every time:
mapboxgl-canvas-container and mapboxgl-control-container. Both are GL-JS's own
wrappers, legitimately zero-height with children -- the canvas container
collapses because the canvas is absolutely positioned, the control container is
an empty positioning shell. Neither is a layout defect.
That was 8 of the gate's 12 failures: a false signal loud enough to drown the
one real finding underneath it (clause B -- a wheel below the map scrolls
nothing on the composite leaf). A gate that reports four-fifths noise teaches
its reader to skim the summary line, which is the failure this file was written
to end. So the exemption is a correctness fix, not a convenience.
Scoped by PREFIX rather than an exact class list, because GL-JS composes these
as multi-class strings ("mapboxgl-canvas-container mapboxgl-interactive") and
adds more across versions. Kept narrow to mapboxgl-/maplibregl- so it cannot
silently swallow a real defect in our own markup.
Negative-tested as a predicate, 7/7: both real false-positives and the maplibre
equivalent are exempt; rd-shell, pgg-root and region-card__footer are NOT; and
"my-mapboxgl-thing" does not match mid-string. check:mjs-parse passes.
The gate could not be re-run end-to-end for a before/after verdict -- the shared
build queue has been busy continuously (check:settled reported dirs=2/17
leaves=0/40 mid-clean). Predicate proven in isolation; the full verdict is owed.
Second pass against Driver feedback. Measured getComputedStyle() on the live
doxa.life/regions page and diffed against ours:
- Chevron was a text glyph (›), not DX-life's real SVG icon
(public/assets/icons/arrow-chevron.svg#chevron-up). Ported the actual path
geometry and rotation.
- Region title was bold + letter-spaced + uppercase; the live page measures
weight 400, letter-spacing normal, no text-transform — Bebas Neue's own
glyphs carry the bold/condensed/caps look, DX-life applies nothing on top.
- Country links were weight 400; live page measures weight 500.
- countries-grid was missing the page's global list indent (35.2px
padding-left, measured live).
- region-card__footer had a stray ~19.5px bottom margin from the <p>'s
user-agent default; DX-life's rule is margin-top only.
Colours/fonts/radii/spacing here are an intentional exact clone of DX-life's
own design (Driver's instruction) — not this repo's material-light chrome
tokens. Do not "fix" this back to our house palette.
.pbtn had flex:1 + white-space:nowrap, forcing every print button to
stretch full-width and forbidding its label from wrapping — one very
wide button per line. Now .pfs wraps and .pbtn sizes to its own
content, so short labels sit two per row when they fit and long ones
wrap to their own line without stretching or clipping.
Four delegated agents left verified work uncommitted in shared files. Committing
it together because it is interdependent and all of it passes the gates; each
agent's own measurements are in _qa-cycle/02-builder-cycle/delegation/.
RESIZE HANDLE (resize-sections). A draggable separator between the dashboard
band and the grid, so the band's height is the user's choice rather than a fixed
compromise. Driver: "if I were to open this on a large monitor and I wanted to
resize the height of the dashboard compared to the grid, being able to do that
would be really cool." Verified with real pointer events: 522px -> 672px on a
150px drag, stable before/during/after, no snap-back; keyboard-operable with
aria-valuenow tracking the live value. A real bug was caught pre-ship: 200
localStorage writes on a single keypress.
TABLE/MAP DRAG FIX (table-resize). The handle did nothing in page-scroll mode --
measured 522px before AND after a real 200px drag, every frame. The shell is
height:auto there and grows with content, so the percent-of-shell formula was
meaningless. It now measures against the map element's own top edge captured at
drag start, re-deriving each frame rather than summing a delta. Four drags both
directions with persistence: 417.6->336, 336->283, 283->548, and 548->470 after
a reload that restored 548.
SLIMMER STATS ROW (slim-headers). The KPI strip's content is an 18px line inside
a row fixed at 42px -- 24px of empty space. Tokenized as --rd-stats-h:30px,
recovering 12px with no information loss, and tokenized rather than inlined
because 42px repeated in three row templates that must stay in sync.
CLOSED FACET SECTIONS (sidebar-collapse). Driver: "once the data fills all the
sidebars it causes the dashboard to become really tall... without data it looks
fine." Measured: five open sections rendered 69 rows, the rail's own scroller
never engaged (clientHeight === scrollHeight === 2117px), band 2325px against a
900px viewport. All five now start closed -- the default changes, not the
mechanism; per-section state and toggle() already existed.
Build exit 0, 21 bundles / 30 profiles. check:sri, check:settled, sfc-parse,
template-literal, one-palette, synced-css all pass.
Draw/delete/batch-select polygons on a keyless MapLibre+OpenFreeMap basemap,
print a per-zone prayer-walking plan (title + coordinates) via an in-browser
print dialog, everything persisted to localStorage only — no backend, per
the JAMstack constraint. Root SFC mounts directly as the custom element
(no ProfileLoader — needs no token/dataSource/profile-switching), so
defineExpose() bridges addPolygon/deletePolygon/selectPolygon/print/list
straight onto the DOM element for agent-driven use; window.PrayerWalkPlanner
mirrors the same API for discovery. Researched keyless satellite imagery
(Esri World Imagery, NASA GIBS/MODIS, USGS orthophotos): none qualified —
Esri restricts free use to OSM tracing only, GIBS/MODIS tops out at 250m/px
(useless for a neighborhood walk), USGS is US-only — so this ships the
keyless vector basemap already proven in library/styles/registry.js.
The Driver asked for the three dashboard headers to read slimmer so the
people-groups grid peeks below the fold as a scroll hint. Measured each
header's actual content height: the KPI strip's content is 18px tall
(a single baseline row) inside a grid row hardcoded at 42px, so 24px was
dead space around it — the largest untouched margin of the three. The
topbar and research-filters bands are already at a Driver-fought floor
from prior cards, so they're left alone. Tokenized as --rd-stats-h since
the literal appeared in three grid-template-rows declarations that must
stay in sync.
Driver, 2026-09-23: the UPG-100 list card should offer three PRINT options, each
opening the browser's own print dialog on a rendered preview (never a silent file
download), in this order: Print a UPG-100 list (the point of the app), Print a UPG
prayer poster, Print a UPG card deck.
- printList100() and printCardDeck() reuse printPoster()'s print-preview window
mechanism (extracted to openPrintWindow()) rather than inventing a second one.
- Both fetch real per-people-group records via the same normalize.js +
selector-evaluator.js pipeline the sibling map profile already uses, so the map,
the list print and the card deck can never disagree about which PGs belong to a
list. Found and fixed along the way: 12 of 27 lists carry a `pg_slugs` selector
that selector-evaluator.js intentionally throws on (a documented special case in
upg-100-list.vue) — my first pass called it unconditionally, which silently ate
every click on the India/China lists before reaching window.open(). Caught only
by driving a real click and polling the HUD, not by reading the code.
- Card deck is new code (no card/deck generator exists in this repo or in
root-dx-life to port — searched first); one card per people group, print-paginated
with `break-after:page`, styled after the poster-wall's own tape/card vocabulary.
- Removed the now-orphaned exportPoster()/downloadPacket()/download() — the raw
Download button and the "Prayer List: coming soon" placeholder were exactly the
two buttons the Driver objected to.
Verified live: instrumented window.open/window.print via Playwright, clicked all
three buttons for real. Each opens exactly one window and calls print() exactly
once (List: 1/1, Card Deck: 1/1; Poster: 1 window opened, print() correctly does
NOT fire when the full-res poster 404s in this default, bundlePosters:false tree —
the documented degraded state, confirmed by screenshot).
MEASURED: agents produced 21 report docs totalling 2,079 lines of prose and 27
scratch probe files against a handful of product commits. The cause is the spawn
prompts, which is to say me: each carried ~15 environment rules, several cited
lessons, a three-clause invariant, a mandatory screenshot read and a
what-I-could-not-verify section. Per report that is 7-12 headings and 10-16
verification mentions. The prompt made PROVING the job and BUILDING the side
effect.
Two costs compounded. Every agent re-derived the same environment from scratch
-- which port, is the tree settled, does stale SRI block the script, does this
box have WebGL. And several spent that discovery budget, hit a build queue they
could not control, and died on a session limit before committing; their work
survived only because it was found untracked (one 511-line gate was a `git
clean` away from being lost).
This file pays that tax once. Spawn prompts can now be short: what to build,
which files you own, and the one assertion that would falsify it.
It also states the rule that was missing: ship a commit and PUSH, then write two
sentences -- not the reverse. A long honest report attached to no commit is the
failure mode. And it sizes verification to blast radius explicitly, because
over-verifying is a real cost rather than a virtue.
check:doc-scripts passes, so every command quoted here exists in package.json.
The Driver's exact-clone complaint: our element kept DX-life's markup shape but
reinvented the styling — lighter header green, small radius, generic font, and
no footer link at all. This replaces every design value with DX-life's own,
resolved from their SCSS tokens and cross-checked against getComputedStyle()
on the live https://doxa.life/regions page.
Key finding: DX-life's <html> sets font-size:10px as its rem root, so every
rem token in their CSS resolves to 62.5% of the raw number (their 3.5rem
border-radius is 35px, not 56px). Ported: dark #3b463d header band, 35px
radius, bold/condensed/uppercase title (Bebas Neue approximated — their font
file has no CORS header so it can't be cross-origin loaded), and the missing
"See <Region> dashboard" footer link bottom-right with its permanent underline.
Also fixed a real wrap bug the port introduced: the countries-grid bullet was
flex/baseline-aligned and stranded the (count) beside line 2 on multi-line
country names; now a plain inline row with an absolutely-positioned dot.
Colours/fonts/radii here are an intentional, Driver-directed exception to this
repo's material-light chrome tokens — the clone wins for this element.
Full property-by-property table: _qa-cycle/02-builder-cycle/delegation/RESULT-regions-design-clone.md
A green state suite said nothing about whether the product is usable. The suite
was 56/58, verify:gate1 13/13 on live data, verify:map-paint 11/11 with real GL,
verify:interop 4/4, 363 done cards -- and the Driver opened the product and
found five real defects in one sitting, several CAUSED by a change a gate had
certified. Not one was visible to any gate.
The gap is what they assert. Existing gates ask does it mount, does it fetch, do
the counts agree, does a canvas paint. The Driver asks: is it slim, can I see it
at once, does the wheel do what I expect, does it tell me what I am looking at.
check:fits-screen asserts five clauses on the built composite with a real
browser and live data:
A the dashboard band fits ONE 1440x900 viewport, and is shorter than its own
tree-legend's scrollHeight
B the people-groups grid is still reachable by scrolling underneath -- a fix
for A must not re-break this (AP-fixing-reachability-by-making-the-thing-taller)
C a wheel over the map changes zoom and does not scroll the pane; a wheel
below it scrolls and does not zoom -- instrumented on the DISPATCHED EVENT
via composedPath, never on geometry, per the four wrong diagnoses that
rule already cost
D the grid's live count is visible and CHANGES when a facet narrows it
E a 1440/1280/768/390 sweep has no horizontal overflow and no element
clipped to zero height
It ships with check:fits-screen:self-test -- one regression mode per clause,
because a gate that has only ever printed PASS is unproven.
It also skips honestly: exit 0 with an explanation if the tree is not settled at
START or is no longer settled at END, or if the live API is unreachable. Proven
on its first real run, which reported SKIP with dirs=3/17 while a build was
mid-clean rather than inventing a defect.
Started by a delegated agent that hit its session limit; the two hardcoded-port
probes it left beside this file were scratch and moved to _qa-cycle. Verified:
check:mjs-parse passes, the gate is wired in package.json, and its settled-tree
skip path works.
TWO RULES THAT WERE COSTING REAL TIME.
1. A FULL BUILD IS NOT NEEDED TO SEE A CHANGE. Agents were running the minutes-
long `bun run build` for edits the dev server hot-reloads. Documented `bun run
dev`, plus the parallel-safe form.
The trap that makes the parallel form mandatory: Vite's default behaviour on
a busy port is to silently move to the next one, and FIVE gates have 5173
written into them (check-facet-changes-map, plugin-gallery-smoke,
smoke-studio, generate-gallery, check-scrim-covers-viewport). A second dev
server without --strictPort therefore leaves those gates talking to somebody
else's server, or to none, reporting a confident wrong answer with no error.
Verified: `--port 5299 --strictPort` serves 200 on root and on the registry,
and a duplicate on the same port exits 1 instead of drifting.
2. A LOCAL COMMIT IS INVISIBLE. The Driver runs a laptop watcher against the
Forgejo repo and sees changes in the browser from THAT repo, so work that
stops at `git commit` has not been delivered however well it was verified.
Documented the push, with the credential kept out of .git/config and filtered
from output.
Also documented the follow-up nobody expects: after pushing to an inline URL,
`git log @{u}..` still reports the commits as unpushed, because git only moves
a remote-tracking ref when it pushes to a NAMED remote. That read as "63
unpushed commits" on a branch that was fully pushed.
check:doc-scripts passes, so every command quoted here exists in package.json.
The Driver named seven plugins across three sections. Six shipped; Regions was
the gap.
Dashboards Big Picture · Simple Research · Regions
Prayer Mobilization UPG-100 List · Prayer Progress
Gospel Research Cities with Internet · Gospel Resources
What ships today is tab 1 of 2. regions-dashboard currently builds a single
profile, regions-list -- the WAGF region list refactored from DX-life's /regions
page, which emits region-selected / country-selected. The scrollable
region/country detail dashboard those events will drive lands as an ADDITIONAL
profile in the same bundle, and this row needs no edit when it does, because the
row names the BUNDLE and the shell resolves the profile from the manifest.
Listed now rather than held back: a working list that reaches the rail is worth
more than a complete feature nobody can open.
Verified in a browser on the built tree at 1440x900, recursive shadow-DOM walk:
four rail sections render as Dashboards / Prayer Mobilization / Gospel Research
/ Experimental; the seven curated rows appear in the Driver's order with Regions
third; 14 tabs total, 14 unique, zero duplicates, zero console errors.
check:sri PASS, check:settled PASS before and after.
A single-bundle build regenerates the JS but not the leaf pages, so four
big-picture leaves carried a stale sha384 and the browser refused to execute the
script at all. That is why a nav probe measured 0 sections on a shell whose
source was correct, and it is the likeliest cause of a teammate's 'pggMounted:
false on big-picture everywhere' reading.
check:sri named both the cause and the fix; ran the full build it prescribes on
a settled tree. Now PASS: 44 script references across 45 leaf pages, every
leaf's integrity matching the bundle it loads.
The composite's own header renders "<N> shown" from @groups-filtered, and the
nested grid rendered its own "Total: <N>" line 139px below it. Measured live:
"2107 shown" and "Total: 2,107" — the same number twice, both above the fold.
That is the redundant-header shape the standing rule forbids (the hint lives in
the EXISTING header, never a second one). show-total=false here matches the
pattern already applied in dashboard-plus-grid.vue:279 for the same reason.
The grid keeps its own total when embedded ALONE, where it is the only count on
screen — the prop is host-controlled, not removed.
Work started by a delegated agent that hit its session limit mid-task; verified
the cited sibling pattern exists before committing. check:sfc-parse and
check:template-literal pass.
Big Picture now lives in its own Dashboards section alongside a renamed Simple
Research (was Research Map, recategorised as the mobile-default dashboard).
Prayer Mobilization narrows to UPG-100 List + Prayer Progress; the renamed
Gospel Research section takes Cities with Internet + Gospel Resources.
The device rule changes shape to match: every row now stays in the rail on
every width (nothing is hidden any more), Big Picture is disabled rather than
removed on mobile with a "desktop only" badge and an explanatory toast on
click, and the auto-selected tab swaps to Simple Research on mobile / Big
Picture on desktop.
Added a loud, module-load-time assertion that no tab id is declared twice
across the curated sections, on top of the existing silent runtime dedupe --
this is the gate the duplicate-key regression needed and didn't have.
The swatch rendered the raw bin hex. The map never paints that colour: the
choropleth composites at fill-opacity 0.78 over Positron's #f2f3f0, so every
swatch showed a colour that appears nowhere on the map.
Measured, chip vs actual fill:
#f4cec4 -> #f4d6ce dE 4.07
#ecaea1 -> #edbdb2 dE 7.53
#e08678 -> #e49e92 dE 11.93
#ce544b -> #d6776f dE 17.13
#b10010 -> #bf3541 dE 21.14
The error grows with the bin, and at the top it is the size of a whole bin step:
the gap between the top two bins is 25.45 as painted, while the legend's own
error on the heartbeat bin is 21.14. A reader comparing the two darkest swatches
was comparing two colours neither of which was on the map -- a strong candidate
for the report that "60-149 red is the same red as the heartbeat zone",
independent of the ramp itself.
Composited in the legend rather than dropping the map's opacity: 0.78 is
deliberate, it lets country borders and labels read through the choropleth, and
this file's own contrast notes are measured at 0.78. The legend was the half
that was lying.
Verified: all five bins produce the measured target values, and non-hex and null
inputs pass through untouched. check:one-palette, check:synced-css,
check:template-literal, check:sfc-parse all pass.
The mobile pair reported "composite did not mount (map=false, cards=24)" on a
tree verified SETTLED both before and after the run, so it read as a real
defect. It was not. A direct browser probe of the same leaf found the composite
completely healthy: both children mounted, a 1440x856 canvas PAINTED, 0 console
errors, 0 failed requests, body 3168px.
Two causes, and the asymmetry with the desktop pair is what hid them.
SHADOW DOM DOES NOT PIERCE. The gate used document.querySelector
("doxa-research-map"), a single-level query. The desktop gate's
document.querySelector("dashboard-plus-grid") works only because that element IS
the top-level custom element on its own leaf. Here <doxa-research-map> is nested
inside the composite's shadow root, where a top-level selector cannot reach it.
The harness already carries __walk(), a recursive shadowRoot walker, and simply
was not using it on that line.
THREE SECONDS IS NOT LONG ENOUGH. The direct probe needed ~22s before the nested
map had mounted and painted. A composite that lazily injects a child bundle's
script, waits for customElements, then initialises a GL map does not finish in
3s here. Now it polls up to 30s for both halves.
The failure message also reports the custom tags it DID find when it gives up,
because "map=false" alone cannot distinguish "never mounted" from "mounted
somewhere this query cannot reach" -- which is exactly the distinction that cost
a tick.
A gate that cries wolf on a healthy surface gets ignored, and then it cannot
report the real thing.
Verified: verify:interop now PASSES 4/4. Mobile grid search "India" -> Total:
941; map mounts independently. Desktop unchanged -- facet -> "Showing 1,309",
and row selection still moves the camera 28.000,18.000@1.45 ->
73.666,13.162@2.48. check:mjs-parse passes.
THE RAMP. The Driver reported that 60-149 reads as the same red as the 150+
heartbeat bin. The old ramp was mathematically even and he was still right --
that tension was the finding, not a contradiction. Measured in plain sRGB
distance the top step (60.0) looked like the LARGEST in the ramp; that
measurement was lying, because RGB distance is not perceptual. Re-measured as
deltaE the old steps were 15.5 / 15.8 / 16.7 / 17.7 -- nearly flat, while chroma
collapses at the dark end so hue and saturation stop carrying information there.
The new ramp deliberately ACCELERATES toward the dark end: 14.1 / 17.9 / 21.4 /
24.9. Top-bin separation 17.67 -> 24.94, a 41% improvement on exactly the pair
he named, and total lightness range widens from 37.2 to 49.0 L*.
A named greyscale ramp ships alongside it, grey to black, as he asked ("just in
case i need to swap from red to black scale"). Its steps measure 22.8 / 22.4 /
22.4 / 22.8 -- near-perfectly even, every step well above the ~10 threshold for
clear distinguishability. It is an OPTION, selected by name; the red ramp
remains the default, so no prior decision is silently reversed.
Bin EDGES are untouched -- check:heartbeat passes, which replays the bin
assignment and fails if a default moves.
THE INTEROP GATE. verify:interop drives the actual compiled cap-4 composites in
a real browser against live data, closing the gap verify:gate1 leaves open. On
its first run it PASSED both desktop directions: a facet-rail click narrowed the
grid to "Showing 1,309", and selecting three rows moved the camera from
28.000,18.000@1.45 to 73.666,13.162@2.48 -- read back off the live map, not
inferred. It asserts the grid's live count line rather than card count, because
card count is a proven false-negative (always 24).
It ships with verify:interop:self-test, a two-mode negative test -- grid-prop
freeze and camera freeze -- each required to fire its own combination-named
failure. A harness that has only ever reported PASS is unproven.
Gates: sfc-parse, template-literal, one-palette, synced-css, mjs-parse,
heartbeat, doc-scripts all pass.
The build lock protects a second WRITER. It does not protect a READER, and
nothing in the docs said so. Every build starts with `bun run clean`, which
rm -rf's public/doxa-maps, so anything reading the tree mid-build gets a
confident wrong answer: "that bundle is missing", "the dashboard tab does not
exist", "461 files were deleted". Each of those has actually happened here, and
one nearly produced a bug report against a correct change.
check:settled already existed and was already wired in package.json. It was
mentioned in zero markdown files, which is the whole gap: the primitive was
built and never reached the people who needed it. Documented now in the one
place an inheritor reads, with the instruction to grade it by exit code --
like every gate here it prints teaching prose after its verdict, so `| tail -1`
inverts the signal.
Also recorded why a pgrep check is NOT a substitute, because that is the form
the standing brief prescribes and it is the weaker instrument. A process list
samples an instant; the lock knows the queue. Between one queued build finishing
and the next acquiring the lock there is a real window where zero build
processes exist and the tree is about to be wiped -- and a long quiet period
makes that window look more convincing, not less, since the queue is idle
precisely because it is between runs. Measured today: pgrep reported 0 builders
while the gate reported builders=1 waiters=1, and ps confirmed a build had
started 17 seconds earlier.
Verified by execution: check:settled exits 1 with builders=1 waiters=1
churn(45s)=456 while a build runs; check:doc-scripts passes, so every command
quoted here exists in package.json.
TWO CHANGES, both Driver-reported.
1. THE SHELL WOULD NOT SCROLL, so the grid under the Big Picture dashboard was
unreachable. Measured before: window.scrollY stayed 0 and .vtl-content reported
scrollTop 0 against max 4155 -- it HELD 4155px of content and would not move; 0
grid cards reachable. The same composite on its own leaf page scrolled fine
(scrollY 3712, 9 cards), so this was a HOST defect, not broken interop.
Cause: every mounted tab got position:absolute;inset:0;height:100%
unconditionally. That is right for a fixed-viewport map, which fills the pane
exactly. It traps a StackLayout composite -- dashboard-plus-grid and
research-map-plus-grid are natural-height by design, and pinning them to inset:0
forces ~2600px of real content back into one viewport with nowhere to go, while
BOTH the element and its container were absolutely positioned with no scroller.
Fix follows the bounded-middle shape already proven here: the PANE stays bounded
and gains overflow-y:auto (plus overscroll-behavior:contain so a bottomed-out
wheel does not chain to the document); .dms-slot becomes position:relative with
min-height:100% so it can grow past the pane. Removing the pane's bounds instead
was measured previously and produced a worse defect -- the grid landed far below
the fold.
Verified in the shell on the built tree: pane overflow-y auto, scrollTop 0 ->
4155 of a 4155 max, grid cards visible 0 -> 8, .rd-grid present, 0 failed
requests. Read the screenshot as well as the numbers: the people-groups grid
renders with photos, country and affinity-bloc labels, Full-profile buttons and
Load more. Fixed-viewport map tabs are unaffected -- they fill the pane exactly,
so scrollHeight equals clientHeight and overflow:auto paints no scrollbar.
2. ENGAGEMENT AND STATUS FILTERS REMOVED on instruction. engagement_status is
gone from the dropdown row (seven remain, all fitting the first row on the
measured 178px pitch) and the Status section is gone from the facet rail. The
facet accessor, the table column and the FACET_TO_PROP mapping all stay, so the
grid can still filter on it and nothing downstream breaks -- only the two
offered controls are withdrawn.
Gospel Access stays. It is measurably a different question: over 2,108 live rows
the two fields disagree on 25 -- 12 groups are Engaged at gsec rung 1 and 13 are
Unengaged at rung 2.
Gates: sfc-parse, template-literal, one-palette, synced-css, facet-cascade,
facet-one-field all pass.
Scrollable list of WAGF regions and their countries, refactored from the
DX-life /regions page into a standalone custom element. Clicking a region
or country emits a selection event instead of navigating, so a host shell
can drive a second tab from it.
resources-list rendered links only from `resources[]`, which holds SCRIPTURE
editions (eBible entries with ot_books/nt_books/redistributable). The JESUS Film
lives in its own fields -- has_film/jesus_film plus film_url -- and was never
read. Measured over all 862 languages in resources.json:
resources[] non-empty ............ 120
film_url present ................. 306
film_url but resources[] EMPTY ... 218 <- a real link the UI never offered
So 218 languages displayed no link at all while carrying a working one. Arabic,
Sudanese (apd, 66 people groups, 18.7M speakers) has
https://www.jesusfilm.org/watch/?languageId=13562 and rendered nothing.
The pill is deliberately left alone. It reads full_bible/has_scripture, so
"none found" is TRUE -- of scripture, which those 218 genuinely lack. Widening
it to mean "no resources at all" would make it say something false about a
language that has a film. The row now says both things: the pill reports the
scripture gap, the links report what exists.
Film links are marked (muted, with a leading marker) rather than styled as
another Bible, because a film is a real resource but not a text and this list is
about text availability first. Guarded on film_url itself, not on the boolean
flags: a truthy flag with no URL would render an anchor to nowhere.
Verified in a browser on the built tree: default "No scripture found" tab now
renders 218 film anchors where it previously rendered zero, all 218 on rows
whose pill reads "none found"; the sample href matches the apd row in the data.
"Has scripture" shows 120 rows with 155 scripture anchors plus 88 film; "All
languages" 862 rows, 306 film -- matching the pre-change data counts exactly.
0 failed requests.
check:legend-source was failing: the corpus moved 2,107 -> 2,108 and Unengaged
2,080 -> 2,081. The gate's own text forbids updating the baseline alone, since
that silences the check while leaving the maps wrong -- so the maps were checked
first. Grepping 2107/2,107/2080 across plugin-designs/ and library/ found the
number only inside explanatory comments; no shipping code hardcodes a corpus
total. Every legend and KPI computes from the rows it loaded, so the display
already followed the data and only this baseline lagged.
Also recorded, because two independent lostness measurements now ship together
and they are not the same question. imb_gsec measures evangelical presence and
church-planting activity; the six imb_*_available flags measure whether a
resource exists. Over the live corpus:
gsec rung 0 "No Evangelicals, Churches or Resources" .... 225
zero of the six resource flags ......................... 285
BOTH ................................................... 209
rung 0 yet HAS at least one resource .................... 16
zero resources yet NOT rung 0 ........................... 76
Of the 225 groups filed under "No Evangelicals, Churches OR RESOURCES", 11 have
one of the six and 5 have four each. The "or Resources" clause is not literally
true in the data and must not be repeated to a mission team as fact.
Deliberately NOT asserted as a gate condition: which figure is official is an
open Driver decision, and a gate must not quietly canonise one answer to a
question still being asked.
Negative-tested: a bogus baseline drives the gate to exit 1 naming the corpus
size, and restoring it returns exit 0.
Both were assumptions written as measurements, and one of them kept a P0 card
shut.
(1) "GSEC is the underlying field ... engagement_status is the label derived
from it." They are independent fields. Over 2,108 live rows they disagree: 12
groups are "Engaged" at gsec rung 1, and 13 are "Unengaged" at rung 2. Because
the note claimed the dropdown already covered "the phases of engagement", the
phases looked built when they were not.
(2) "168px on a 200px pitch, so eight occupy 1600px and MUST wrap." The pitch
was never measured. It is 178px: seven dropdowns fit the first row ending at
x=1250 and the eighth wraps, at both 1440 and 1280, with no horizontal
scrollbar. The conclusion held; the arithmetic behind it did not, which would
have misled the next author sizing this row.
Gospel Access stays out of the dropdown list because the Driver named eight, not
because a ninth would overflow -- the layout would tolerate one. A five-rung
ordinal reads better in the tree rail regardless.
Comments only; no behaviour change.
The Driver asked for "the phases of engagement, measured in the live data."
engagement_status cannot express them: over 2,108 live rows it is 2,081
Unengaged / 27 Engaged, so filtering on it separates 1.3% of the corpus and
tells a researcher almost nothing about where a group actually sits.
imb_gsec is the ordinal ladder underneath that flag, present on 2,106/2,108:
0 No Evangelicals, Churches or Resources ........... 225
1 Less than 2% Evangelical, No Active CP Activity . 1,853
2 Less than 2% Evangelical, Concentrated CP ......... 23
4 2% or Greater but Less than 5% Evangelical ......... 4
6 10% or Greater Evangelical ......................... 1
Cross-tabbed against the flag, ALL 225 groups with no evangelicals, churches or
resources -- the most lost category in the data -- are merely "Unengaged",
indistinguishable from the 1,841 groups that have some evangelical presence.
That distinction is the one the map exists to show.
Verified safe to filter on before wiring, the same way cluster/people_group
were: 5 distinct {value,label} pairs and NO value-vs-label cross-collision, so
valueMatches() selects the same rows whichever vocabulary arrives. It is a real
row field, unlike the derived language_family/religion_family facets, so it is
mapped in FACET_TO_PROP from the day it lands rather than joining the
dashboard-only class.
Wired through every layer that would otherwise silently drop it: the shared
sources.json defaultFields (the dashboard reads rows through that seam), the
grid's own fetch field list, the prop, the API-field-name filter key (imb_gsec,
not gospelAccess), the re-filter watch list, and the composite's prop binding.
Verified in a browser on the built tree with live data: the section renders all
five rungs with counts matching the API exactly; clicking "No Evangelicals"
takes dashboard scope 2,108 -> 225 and the grid to "Showing 225"; clicking
"Concentrated CP" gives 23 and "Showing 23"; deselecting returns both to
baseline. 0 failed requests.
Gates: facet-one-field, facet-cascade, facet-changes-map, csv-shape,
label-joins, one-palette, sfc-parse, parse all pass. verify:gate1 still 13/13
against 2,108 live records.
language_family and religion_family are clickable, they highlight, and they
narrow every chart above them -- and they cannot move the grid below. Measured
2026-09-23: dashboard 2107 -> 677/306/222/151 and 2107 -> 693/649/610/83, grid
unchanged every time. To a user that is indistinguishable from a dead control;
the only way to learn it was to click and squint.
Wiring them is not the fix and would be worse. Both values are DERIVED -- a
language family resolved via langFamilyByIso for ~96% of rows, a religion family
computed from the first letter of a religion code -- so they exist on no row
field. Mapping religion_family onto `religion` would compare "Hinduism" against
a CODE and filter the grid to zero.
So the honest fix is a label, not a wire. A facet now declares
`dashboardOnly: true` in dashboard.config.js; DashboardFacetRail reads that from
config rather than hardcoding facet names, and renders a muted half-circle plus
a title and an extended aria-label saying the row updates the charts only.
These rows stay fully clickable, deliberately unlike `zero` and `other` rows,
which are inert because they would do nothing at all. Dimming them the same way
would understate what they really do.
Verified in a browser on the built tree: 41 of 66 rows marked, 41 glyphs
rendered, marked facets are exactly language_family and religion_family and
nothing else, 40 still clickable (the one that is not is a zero row that
correctly keeps its mark). Behaviour unchanged -- a marked row still takes the
dashboard 2,108 -> 677, an unmarked row still filters at 548.
Gates: facet-cascade, facet-one-field, facet-changes-map, one-palette,
synced-css, composite-srcs, template-literal, sfc-parse all pass;
a11y-button-names passes at 769/769 buttons named.
"17 pass-with-console-errors" is a bare number that invites investigation, and
it cost a full tick: the count was carded as a suspected hidden defect on the
real precedent that a thrown setup() in this repo once removed a subtree
silently while the gate still counted the element as mounted.
It was noise, and the partition is the proof. Every noisy element is map-bearing
or bakes in a map-bearing child; every silent one is not. On a box with no GPU
and no Mapbox token, a map reporting a failed init is correct behaviour.
One message class was an artifact of the report itself: console.error('[x] Map
failed to initialize --', err) passes two arguments, and Playwright renders the
Error argument as the bare word "Error". Storing each argument separately made
those look like 12 anonymous errors of unknown origin; they were the second half
of messages already counted.
The report now lists each noisy element with its child count and first message,
and prints an explicit "what WOULD be a defect" counter -- a noisy element with
0 shadow children or an error card -- which reads 0 today.
Negative-tested: a synthetic tree with a 0-child element and an error card
drives that counter from 0 to 2, so it is a live signal and not a decorative
zero.
Eleven profiles across six bundles each carried the same line:
profileConfig?.assetsBase || './assets'
That default is right on a standalone leaf page, where the generated host passes
'../../assets' and the tree root is two segments up. It is wrong the moment the
element is nested in the cap-5 shell, because a relative path resolves against
the SHELL's page, not the child's. Measured in a browser on the built tree:
leaf /doxa-maps/gospel-resources/resources-map/index.html ... 0 failed
shell /doxa-maps/doxa-maps-spa/doxa-maps-spa/index.html ...... 404 assets/tables/gospel-by-country.json
404 assets/boundaries/world-adm0.geojson
No build-time gate could see it: './assets' is a valid string in both hosts, and
only the host decides what it resolves to. check-composite-srcs proves a nested
src exists on disk, which is a different question.
resolveAssetsBase() in library/utils/embedBase.js now derives an absolute base
from the bundle's own script URL (or the treeBase the shell already forwards),
and deliberately REJECTS a relative assetsBase from config -- honouring it would
reintroduce the defect through the config meant to cure it.
The fix is in the child, not the shell, so a new bundle that fetches assets
works nested on day one with no edit to doxa-maps-spa.vue.
Verified: shell 404s 2 -> 0 on Gospel Resources; Cities & Internet, UPG-100 and
Big Picture also 0 asset 404s; leaf hosts unchanged at 0.
check:library-index failed, naming library/scripts/research/build-trade-languages.mjs
as the reason the component menu was stale. That file is a build script. The
menu is a catalogue of reusable components, composables and utilities, and
generate-library-index.mjs reads exactly three directories — components/,
composables/, utils/ — so a change to a build script cannot alter one byte of
the output.
The gate walked all of library/. Measured: 75 files are indexed, 173 are not —
scripts/ 58, i18n/ 98, plus data/, layouts/, api/ and constants/. It watched 2.3
times more than the thing it guards, while its own comment said "Newest source
the generator actually scans", which is exactly what it did not do.
It fired for real: adding a comment to a build script two commits ago turned it
red. That is the expensive kind of false positive, because the remedy looks
cheap — regenerate and move on — and a gate that asks for a pointless
regeneration teaches the reader to do it on reflex, which is how a staleness
check stops being read at all.
Now scoped to the three indexed directories, with a note that the scope must be
extended in the same commit if the generator ever adds a section().
Negative-tested both directions rather than only confirming the fix: touching
library/composables/useMapFly.js still FAILS and names it; touching the build
script again PASSES. The gate discriminates where it could not before.
Worth recording that the regenerated index came out byte-identical — git reports
only the gate file as modified. That is the claim made concrete: the change
which had been failing this gate could not affect its output.
Five gates pass.
