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.
Last tick I fixed a dead config read in check-composite-srcs and
check-nested-token, and logged the lesson as an anti-pattern whose advice was:
make the successful path observable — print what was READ, not just what was
used. I did not take my own advice, so this applies it.
Both gates printed "checked against public/doxa-maps/" whether the name came
from the build config or from the hardcoded fallback. Those two states were
indistinguishable in the output, which is precisely why a permanently-failing
read survived unnoticed: nobody was ever going to rename the tree, so the only
thing that could have exposed it was the output, and the output said nothing.
They now print the source. A green run reads "(tree name from
vite.doxa-maps-build-config.json)"; with the read broken it reads "(tree name
from built-in default (build config unreadable))". Negative-tested by pointing
the read at a nonexistent filename and confirming the line changes, then
restoring and confirming it changes back.
Also corrects a comment I got wrong yesterday. The note explaining the bug said
the gate "said vite.doxa-maps-build-config.json — the pre-rename project name",
which is the NEW name; my sed had rewritten the string inside the prose that
described the OLD one. It now names vite.1040-maps-build-config.json, which is
what was actually there. A correction note that misstates what it corrects is
worse than none, because the next reader takes it as the record.
Six gates pass.
check-composite-srcs and check-nested-token-delivery both resolve the output
tree name from the build config, with a comment explaining why the fallback
matters: "Defaulting silently would make this gate check a directory the build
never writes."
Both named vite.1040-maps-build-config.json — the pre-rename project name. That
file does not exist. So the try ALWAYS threw, the catch ALWAYS fired, and the
tree name was ALWAYS the hardcoded default. The read was dead code, and the
gates have been correct only because the default happens to equal the config's
current name, which really is "doxa-maps".
The comment described an intent the code had stopped delivering, which is the
part worth fixing rather than the string. Rename the tree in the build config
and both gates would have walked public/doxa-maps while the build wrote
somewhere else, then SKIPped with "an absent tree is not evidence either way" —
silent, delayed, and the exact outcome that comment exists to prevent.
Proved the read now runs rather than assuming it: parsing
vite.doxa-maps-build-config.json succeeds and yields name "doxa-maps". Then
negative-tested by renaming the tree in the config — the gate now FOLLOWS it and
reports "SKIP — no built tree at public/renamed-tree-probe/", where before it
would have checked the wrong directory and reported PASS. Config restored,
re-verified green.
Seven gates pass, including both repaired ones.
Found by scanning _qa-cycle/CLAUDE.md, the oldest unread doc in the ideation
sweep (2026-07-12) and an inheritor's entry point. It carried the same stale
filename twice, once under the heading "Build config — ONE file", followed by
"Edit it, run bun run build, done" — pointing a reader at a file that is not
there. Corrected in that file too. A third occurrence sits inside a DONE card in
03-deployment-cycle describing a past state; that is a historical record and is
deliberately left alone.
Extending last tick's external-source check from legends to the baked tables
turned up a real discrepancy: gaps-and-opportunities.json has 2,106 rows against
a 2,107-row corpus, with five name mismatches. The table says "Jerba" and
"Tmagourt" where the live API now says "Amazigh of Djerba" and "Amazigh,
Matmata" — the same Tunisian peoples, relabelled upstream since the snapshot.
It is harmless, and the reason is the point. Nothing joins on the name: the
generator keys everything by iso639_3, and the consumer does the same at
resources-map.vue:194, whose comment already states the rule and its stake —
"Never a name match: language names collide and drift ... a fuzzy hit here would
put the wrong scripture in someone's hands."
The generator followed that rule in four places and never said why. So the
decision lived only in the consumer and in my head, and a future author tidying
this file toward a name join would find nothing to stop them. They would
silently drop three groups and orphan two rows: no error, no empty state, just
fewer people on a map about people nobody has reached. That is precisely what
check-label-joins.mjs was written to prevent.
Verified rather than asserted before writing it down: the join key is clean on
every row — heart_iso639_3 present and well-formed on all 2,106, zero blank,
zero malformed, 862 distinct codes; bridge_iso639_3 blank on 461, which is
expected because not every group has a bridge language. gospel-resources/
data-tables renders 50 rows by 21 cells with zero console errors and zero
responses >= 400. Both citations in the new comment were checked against the
files they name.
Comment only; no behaviour change. Five gates pass, including check:label-joins
itself and check:legend-source from last tick.
Every gate in this repo verifies INTERNAL consistency. check:facet-changes-map
proves the dots change and that the categories sum to 2,107 — but it asserts
that inside the page, against data the page already loaded. If the upstream
corpus shifted, the page would stay perfectly self-consistent while its legend
quietly stopped describing reality. Nothing fetched the live endpoint: not the
six data guards, not check:label-joins, not any browser gate.
That is the worst failure this product can ship, because it is invisible to
every structural check. The element mounts, the canvas paints, the counts are
formatted correctly, the partition sums. Only comparison against the SOURCE
catches a legend that is beautifully wrong — and these maps exist to say where
the gospel has not reached, so a wrong number is not a cosmetic defect.
Measured by hand first, then encoded. The cap-2 engagement legend shows
Unengaged 2,080 / Engaged 27; the live API returns 2,107 rows splitting exactly
2,080 / 27, with no third bucket and no remainder. The cap-4 dashboard KPI strip
prints "1% ADOPTED"; the live API gives 21 of 2,107, which is 1.0%. Three
independent surfaces agreeing to the unit.
The gate also asserts the partition is COMPLETE and that no category exists which
the two-row legend does not show — a third engagement value would hide rows from
the reader while every count still looked right.
The expected values are a baseline, not a law, and the failure message says so:
the corpus is living data and these numbers will move. A mismatch is a prompt to
update the legend, the KPI and the baseline TOGETHER, which is the coupling that
was missing. Updating the baseline alone would silence the gate and leave the
maps wrong.
Offline SKIPs at exit 0 rather than failing, because reporting a mismatch that
may not exist is the fail-open mistake in reverse. Negative-tested both ways:
drifting the baseline fails naming the exact category and both numbers;
an unreachable host skips and says why.
The browser user-agent is deliberate — pray.doxa.life answers 403 to a default
script UA, a trap already recorded here, and one that presents as "the data is
gone".
The Plugin Studio header read "18 bundles · 27 elements" while the manifest
holds 19 and 28. The arithmetic was always right: rowsFromManifest skips the
studio itself, because it cannot be one of its own tabs, and 19-1 / 28-1 is
exactly what the header showed.
The problem was that nothing said so. The golden-path self-test — linked from
the golden-path doc as of this flight — reports 19 bundles and 28 profiles from
the same manifest. Two authoritative surfaces disagreeing by one, neither
explaining why, is how a reader stops trusting both; and the studio is the first
thing an admin agent opens, so a number that looks wrong there discredits
everything beside it.
"listed here" is the whole change. It names the population, so the difference
from the catalog total reads as a deliberate exclusion rather than an off-by-one.
The count stays derived from this.rows, which is the honest source — it is a
statement about what the studio shows, and now it says that.
Verified the exclusion accounts for the gap exactly before touching anything:
manifest 19/28, minus the single plugin-studio bundle and its one profile, is
18/27. Then read the rendered header at 1600px — 220px wide, sitting beside the
language selector without crowding it — and confirmed it in the regenerated
screenshot.
Nine gates pass, including check:synced-css: there are two .ps-count rules in
this file, the synced copies that must stay byte-identical, and this change is
JS rather than CSS so both are untouched.
Same shape as the self-test scoping documented earlier today: a number that is
correct for the question it answers, with nothing saying which question that is.
The wall's header pill reads "<n> UPG · Show on map" and is a fixed 82% of the
card. A three-digit count pushed it over that width and it wrapped, so "116 UPG"
cards rendered a two-line pill beside one-line "92 UPG" cards in the same row.
Measured at 1440px on the shipped wall: the same element came out h=34 for
three-digit counts and h=22 for two-digit ones, a 12px step that reads as two
different components sitting side by side.
One property, and the correct value was already three lines away: the sibling
footer pill (.tape-l) carries white-space:nowrap and .tape-h did not. So this was
an inconsistency inside one component rather than a design question. The
.hcount rule sets font-variant-numeric:tabular-nums, which says the author
already wanted digit width not to move things — wrapping undid that intent.
Now h=22 on every card regardless of count, confirmed in the regenerated
screenshot: the three-digit pills in the India and Africa rows sit on one line
like the rest.
Found by looking at the shipped screenshot while verifying
BUG-UPG100-POSTER-PRINT-DIALOG, which the standing brief asks to check visually
and which had closed with verification_kind "state" and no recorded evidence.
The poster wall itself is sound — real posters, named people groups, PRINT
OPTIONS on every card.
Nine gates pass, including template-literal, which matters because this CSS
lives in a JS string and a backtick in a comment there has broken the build
twice before.
Not fixed, and not a product defect: the "Print poster" labels show a tofu box
on this machine. check:shot-fidelity already names these six bundles — the
markup carries the right codepoint and the shot box has no emoji font. The fix
is a font here, never removing emoji from the product.
golden-path-check is the capability-1 element that IS the
develop-a-plugin-and-see-it-live walk: authored from the documented 3-file
minimum, built, published, and then reading the manifest it shipped beside. It
was named in two reference docs and NOT in the golden-path document itself, so
the one artifact that proves the path worked was missing from the page that
teaches the path.
Step 5 ended with "Done = the live site shows it, not a green build", which is
the right instruction and leaves the reader with no reference point — they can
only check their own plugin, and if it fails they cannot tell a mistake in their
plugin from a broken platform. The self-test separates those two questions.
Verified on the live catalog before writing it down, as an inheritor would:
HTTP 200, zero console errors, and it reports 19 bundles, 28 profiles, 28 of 28
self-describing, this plugin listed = yes. Cross-checked by two independent
measurements rather than trusting the element — the live bundle is
byte-identical to local at 73,693 bytes, and fetching the live manifest directly
gives the same 19 and 28 from a different path.
The note also states what the self-test does NOT claim, because that is the way
it could mislead. Its four rows are questions about the catalog's SHAPE, so it
stays green even when bundle CONTENT is stale — my own fixes this flight changed
bytes and not counts, and it reports identically on both trees. Freshness is
check:catalog-currency's job, which compares every live bundle's bytes against
the build. The doc now tells the reader to run both and says which answers what.
The URL printed in the doc was fetched before committing: 200. Three separate
gates this flight were failing because they navigated to a URL nobody had
checked, and a doc that sends a reader to a 404 is the same defect with a slower
feedback loop.
check:filter-width was failing on both hosts with "UNMEASURED: no
.filter-dropdown__trigger found in the composed tree" and "no tab matched
/dashboard-plus-grid/i". Neither was true of the product. Both paths ended in a
trailing slash — directory URLs — and `bun run serve` is serve-strict.mjs, which
404s a directory with no index fallback because the live static layer does. A
404 page has no trigger and no tab rail, so a missing PAGE was reported as two
missing FEATURES. Measured: both directory URLs return 404, both index.html URLs
return 200.
Now passes in both hosts, and what it reports is the Driver's fixed-width
decision holding: all eight triggers at 168px before and after selecting the
longest option, identical in the standalone dashboard and inside the cap-5
studio.
Two things were checked rather than assumed. The tab regex looked like a second
bug — the rail labels tabs "Big Picture", not by bundle id — but the studio also
renders a developer row reading "dashboard-plus-grid<dashboard-plus-grid>", so
/dashboard-plus-grid/i correctly matches tab 3. Single cause, not two. And the
trigger class the gate looks for does exist (FilterDropdown.vue:278), which is
what made "the page is wrong" the remaining explanation.
Also adds a response check before any content assertion, so this failure mode
cannot recur silently. Negative-tested by pointing it at a nonexistent page: it
now fails with "UNMEASURED: HTTP 404 for /research-dashboard/NO-SUCH-PAGE/
index.html — nothing below this means anything", which names the cause instead
of describing a symptom.
Worth recording why this survived: one tick earlier I swept for directory URLs
and reported the class closed. That sweep grepped for goto(`${BASE}...`) as a
template literal, and this file builds its URL as BASE + path by concatenation,
so the pattern could not match it. A sweep is only as wide as its pattern. The
re-sweep looked instead for any goto whose URL lacks ".html" — a property of the
RESULT rather than of the syntax — and found this one plus nothing else among
the static-tree gates. The BASE + '/' users in smoke-studio, smoke and
check-scrim target the vite dev server on 5173, which does resolve directories,
so they are correct as written.
The dashboard ships eight filter dropdowns. Seven fit on the first line and
Status wraps to a second — centred, not aligned with Prayer above it. A lone
centred control under a left-aligned row does not read as a layout decision, it
reads as a mistake.
Measured on the shipped dashboard at three viewports, line-2 left edge against
line-1: 1440px 36 vs 636, six hundred pixels adrift; 1280px 16 vs 556; 1024px
33 vs 132. Never aligned at any width.
The cause is `justify-content: space-evenly`, which I kept when wrapping landed
here earlier today. The comment defending it is about a SCROLLER — a single line
that could push its first item to a negative offset, which `safe` rescues — and
that reasoning does not survive wrapping, because space-evenly distributes EACH
LINE independently. Seven items distribute across the width; one item lands in
the middle.
flex-start keeps every line on one edge at any width. The `safe` keyword goes
with it: it exists to rescue centred and space-* distributions from negative
offsets, and flex-start cannot produce one, so keeping it would preserve a
guard against a hazard the change removes.
Now 14 / 14 / 14 at all three viewports, matching the row's own left edge, and
the regenerated screenshot shows Status sitting directly beneath Prayer.
Blast radius checked before editing, since this is the high-bar library zone:
SearchFilterHeader is consumed by research-dashboard only. check:synced-css
passes, so the two CSS copies remain byte-identical. Nine gates pass and
verify:gate1 is unchanged at 13/13 against 2,107 live records.
Separately noted, not fixed here: check:filter-width fails on HEAD too —
verified by stashing this edit and re-running. It reports "UNMEASURED: no
.filter-dropdown__trigger found in the composed tree", and that class DOES exist
(FilterDropdown.vue:278), so the selector is right and the gate is not reaching
the page — the same stale-navigation family as the tab-order gate fixed earlier.
Left for its own commit rather than bundled into a styling change.
people-groups-grid caught a failed fetch, logged to the console and cleared its
loading flag. The template's `v-else-if="!displayedUUPGs.length"` branch then
rendered "No people groups match this filter." So when pray.doxa.life was
unreachable, the element told the reader their FILTER was wrong.
Measured by blocking that host in a browser: two console errors logged, and the
only thing on screen was the ordinary empty state. A user adjusts filters that
were never the problem; an operator glancing at the page sees normal operation.
The console held the truth and nobody opens it — least of all on a partner site
or inside the cap-4/cap-5 composites, which is exactly what this element is for.
Now distinguishes the two. A `loadFailed` ref drives its own branch: "People-group
data could not be loaded. This is a connection problem, not your filter."
Also checks response.ok, which was a second silent path. fetch() only rejects on
a NETWORK failure, so a 404, a 500 or an HTML error page all resolve — and
response.json() on them either throws into the same silent catch or yields an
object with no `posts`, which sets an empty grid and reports success. Both were
indistinguishable from "nothing matched".
Styling adds no colour: the palette is material-light only and --mut is what
this component already uses, so the failure line is separated by weight and a
hairline rather than an alarm state the design language does not have.
Verified both directions. Host blocked: the new message renders, no cards.
Host reachable: no message, the grid renders. And `bun run verify:gate1` still
passes 13/13 against 2,107 live records, including its "nonsense query -> 0
(empty-state path)" case — so genuine zero-match still works and is now a
different thing from a failed load.
Found by reading EXPLORE-dxlife-people-groups-refactor.md (2026-09-18) in the
staleness scan. Its PLAN is superseded — steps 1-5 describe editing DX-life's
own UupgsList.vue, which the standing law forbids and which this flight solved
by cloning instead. But its RISK register was still testable, and risk 3 named
this exactly: "external data dep on pray.doxa.life/api/people-groups/list". Half
of that was already mitigated — prayBaseUrl is injected three ways — and this
was the unmitigated half. Risk 6 ("FIVE dropdowns not four, confirm with the
Driver") is also settled: four are rendered.
A doc can be stale as a plan and still carry a live finding.
verify:full runs two browser guards that `bun run verify` skips, and both were
failing. Neither was a product defect; both had rotted unnoticed precisely
because verify-all.mjs marks them `browser: true` and skips them unless --full is
passed, so the build chain has never run them.
verify-app-tables was broken four ways, each of which alone made it useless:
Its default port was 8917, which nothing in this repo has ever bound. Now 4173,
the port `bun run serve` binds, so it runs with the same server as every other
browser gate. APP_BASE still overrides.
It navigated to `index.html#key-city-posters` and two sibling fragments,
resolved against the PROFILES object in layouts/app-wrapper-material. That shell
is not what `/` serves — as of 2026-09-22 the root page mounts <plugin-studio>,
and the built root contains ZERO of those three keys. The list is now three real
profile paths taken from manifest.json. key-city-posters is dropped rather than
renamed to something that merely looks similar: no such profile ships.
Its "are we on our page" check matched the shell title "Doxa Maps". A leaf
titles itself "<profile> · <bundle>". My first replacement matched an absolute
script path and was equally wrong, because a leaf references its bundle
relatively (src="../gospel-resources.js") — measured, on a page that was fine.
It now matches the SRI integrity attribute, which this build guarantees by
construction and no other server emits.
Its row counter only counted rows ONE level inside a shadow host, with no seen
set. A row in the light DOM, or one shadow level deeper, counted zero. Now walks
every depth.
The last defect is the one worth reading twice. The app header printed near the
END of the loop body, after the row check, so every verdict appeared ABOVE the
app it described and the whole report was offset by one. That made a PASSING app
(gospel-resources/data-tables, 40 rows) look like the failure and the real
failure look like it had rendered rows. I chased the wrong app through three
rounds of instrumentation before reading the output in order. A report that is
correct but misordered costs a wrong diagnosis, not just time.
Read correctly, the guard now says: cities-internet/data-tables 40 rows and 1
table fetched; gospel-resources/data-tables 40 rows and 1 table fetched; and
gospel-resources/resources-list fetches NOTHING and renders nothing. That last
one is the already-carded gospel-resources data gap, waiting on the three Driver
decisions — the component is built and correctly showing an empty result for
data it was never given. So the guard is reporting one real, known, Driver-gated
absence, which is what it is for.
Everything else in it was already sound and is untouched: the recursive
shadow-root walk for row counting, fail-closed on zero fetches, and third-party
request detection, which the file rightly calls a persecution risk rather than a
performance note.
check:spa-tab-order was FAILING with "no .vtl-tab rows found in the composed
tree", which reads as a missing tab rail. The rail is fine. The gate navigated
to a DIRECTORY url — .../doxa-maps-spa/doxa-maps-spa/ — and `bun run serve` is
serve-strict.mjs, which 404s a directory request with no index fallback because
the live static layer does. Measured: the directory url returns 404, the
explicit index.html returns 200.
Under the old `python3 -m http.server` this line passed, since that server
silently resolved a directory to index.html. So the gate was green locally and
would have 404'd against production — the exact defect class serve-strict was
introduced to expose, after it hid a bad url in verify-shell-scroll for a whole
flight. A repo-wide sweep found this was the last remaining directory url in
internal/.
The symptom deserves recording because it was maximally misleading: a 404 page
has no rail, so a missing PAGE and a missing FEATURE produce the same message,
and the line immediately below warns about that same confusion arising from
shadow roots. A correct warning about one cause makes the wrong diagnosis of
another cause more tempting, not less.
Now passes, and what it prints is the canonical Gate-1 chain: 12 rows opening
Big Picture ("dashboard + people-groups grid, stacked"), UPG-100 List, Prayer
Progress, Gospel Resources. Big Picture is tab-1 of the cap-5 SPA, as specified.
research-map-plus-grid had the same defect fixed yesterday on its desktop
sibling: sharing the composite emitted a link to doxa-research-map, the child it
nests. The gate said it exactly — "share URL reopened <doxa-research-map>, not
<research-map-plus-grid>" — and a recipient got the map alone, losing the grid.
Checked all four cap-4 composites rather than assuming the fix generalised.
my-upg-100-list owns its Share button directly and is fine. big-picture composes
a header plus the grid, owns no map and ships no Share button at all; the gate
reports "window.mapboxgl UNDEFINED" against it, which is its map precondition,
not a share failure — that bundle is out of this gate's scope and I put it in
the probe by mistake. So one real instance, now fixed.
Tier 1 again, for the same reason: this child also hardcodes a prop
(research-map.vue:2149 `:embed-path="'doxa-research-map/research-map/index.html'"`)
and the ladder is `embedPath || cfg?.shareEmbedPath`, so a prop outranks host
config and tier 2 is unreachable. Delivered through the profile-config attribute
rather than Vue provide, because this composite mounts its children as real
custom elements via src — there is no provide chain to reach them.
The url had to be ABSOLUTE, and the first version was not. resolveShareUrl
returns a tier-1 shareUrl verbatim (embedBase.js:95, `return whole.trim()`, no
resolution), and ShareButton feeds the same string into its embed snippet:
<iframe src="{shareUrl}">. A relative '../../…' would have resolved correctly in
the share LINK, because the browser resolves it against this page, and then
404'd in the EMBED, because it resolves against the partner's page instead. That
would have passed the gate — the gate navigates the link — while breaking the
deployment method the link exists for. Tier 1 is documented as "a WHOLE url" for
precisely this reason. Now computed with resolveEmbedBase() so it stays correct
on doxa.life, on nuxtbase.app and in a dropped tree.
Verified the desktop sibling did not have the same latent flaw: it produces a
fully absolute url, confirmed in the live gate output.
smoke:share-all now carries eleven targets. Full suite 11/11 pass · 0 fail.
Eleven gates pass, including sri, composite, composite-srcs and synced-css.
Sharing from dashboard-plus-grid produced a link to
research-dashboard/research-dashboard/index.html — its own nested child. A
recipient opened the inner dashboard alone and silently lost the grid half of
the composite. The gate said it precisely: "share URL reopened
<research-dashboard-map>, not <dashboard-plus-grid>".
The nested dashboard's DashboardTopBar owns the Share button, and inside the
composite that button had no idea it was a passenger, so it shared its own
address.
Two attempts, and the first one is worth keeping in the record because it built
and shipped and changed nothing. I set profileConfig.shareEmbedPath — tier 2 of
ShareButton's documented ladder, and the natural-looking channel. The ladder is
`embedPath || cfg?.shareEmbedPath`, and DashboardTopBar passes an explicit
prop (`<ShareButton :embed-path="SHARE_EMBED_PATH" />`), so a child that has
already made up its mind always wins. The value was baked into the bundle,
resolveShareUrl reads that key, and the rebuilt bundle failed the gate
identically — a fix that is present in the artifact and unreachable at runtime.
Tier 1, `shareUrl`, is the only rung above a prop, and its docs say exactly what
it is for: "a WHOLE url the HOST supplies wins".
Tier 1 takes a whole url, so it is computed rather than hardcoded, via the same
resolveEmbedBase() helper ShareButton itself uses: profileConfig.embedBaseUrl →
window.MAP_EMBED_BASE_URL → the root the built bundle derives from its own
script url. The link therefore stays correct on doxa.life, on nuxtbase.app and
in a dropped tree with no configuration. An absolute url would have pinned every
share to whichever host happened to build it.
Also adds the two uncovered bundles to smoke:share-all. Nine bundles ship a
Share affordance and the hardcoded --url list covered seven; research-dashboard
and dashboard-plus-grid were absent, which is why this survived. The list is now
ten targets over nine bundles. Note the structural difference from
smoke:embeds, which enumerates from manifest.json and therefore cannot omit a
bundle that ships later — a hardcoded list silently omits whatever arrives after
it was written, and that is what happened here.
This is the two-host defect class exactly: research-dashboard standalone PASSES
this gate, and the identical component inside the composite FAILED. No
single-host gate can tell those apart.
Verified: the composite now reopens <dashboard-plus-grid> with a canvas, and the
full suite is 10/10 pass · 0 fail, so nothing regressed. Eleven gates pass,
including sri, composite, composite-srcs, synced-css and one-palette. The share
gate aborts rather than reporting a false failure when handed Firefox, which has
no WebGL here — it told me to re-run with chromium, and it was right.
smoke:embeds reports a node count per profile, and the counts vary enormously:
dashboard-plus-grid mounts 1,499 nodes with a canvas, big-picture 262,
research-map-plus-grid twelve. Read side by side that last one looks like a
capability-4 composite whose two children never rendered.
It is not. Measured with a recursive shadow-root walk at mobile viewport: 518
nodes, 1 canvas, both children present as real custom elements
(doxa-research-map and people-groups-grid), 13,867px of content, zero console
errors and zero responses >= 400.
The gate counts ONE shadow level. research-map-plus-grid nests its children by
TAG and bundle URL rather than importing their .vue files — deliberately, and
its meta.json explains why: importing the research map's component directly
would bypass doxa-research-map/index.js and silently drop that bundle's private
colour strategies, its profileModules registry, its Pinia/i18n pair and the RTL
plugin. Children mounted that way live in their own shadow roots, which a
single-level querySelectorAll cannot see.
So the count is a MOUNT signal, not a quality signal, and the `< 5` bar it feeds
is still exactly right — that bar catches a mount which produced nothing, which
is what this gate exists to assert. Only the reading was wrong, so only a
comment changes here.
Worth recording because this repo already carries the lesson that shadow DOM
does not pierce, and it cost three wrong diagnoses of a non-bug once before. It
reappeared inside a gate rather than in an ad-hoc probe, where it is harder to
notice: the gate is green, the number is simply not measuring what a reader
assumes. A near-miss, caught by checking the outlier in a browser instead of
filing it.
Whole run for the record: 43/43 pages mount cleanly, enumerated generically from
manifest.json — every bundle x every profile, not a hardcoded list. That is the
"Playwright coverage over every plugin" item on the standing work list, and it
is real coverage.
package.json described verify:browser-all as running "ALL 7 browser gates". The
GATES array in internal/verify-browser-all.mjs holds nine. Two were appended
below the count — check:fixed-anchoring and check:shell-scroll, both added the
same week — and the prose was never touched, so a reader who ran the command and
tallied seven would have concluded two gates had not run.
This is the same shape as the runbook's "all 6 DX guards PASS" corrected earlier
today, and the fix is the same: stop stating a number that lives in another
file. A prose count of a list that grows elsewhere rots on the next append, and
it rots silently, because nothing compares the two. The description now says it
runs every gate in the array and explains why it refuses to give a figure. The
script already prints its own GATES.length at runtime, which is the number that
cannot be wrong.
Also repairs a garbled sentence in the same string — "Only smoke:share the
`verify:browser-all:plugin-gallery` script mode is out of scope" appears to be
two edits collided. It now says plainly that the plugin-gallery mode is separate
because it needs the vite dev server.
One line changed; check:quoted-scripts and check:doc-scripts both pass, which
matters because those gates compare this file against the docs that quote it.
The golden-path doc's Step 4 gave the reader a copy-pasteable publish sequence
with no `set -e`, and its verification step was a COMMENT — "# 3. VERIFY every
manifest bundle's <name>/<name>.js resolves BEFORE push". A comment does not
verify anything. Pasted as written, the block clones, rsyncs with --delete, does
nothing, and pushes.
That is both halves of an incident this project already paid for, recorded as
AP-publish-verify-not-gating-plus-midchurn-rsync in the deploy-cycle notes: the
verify was chained into a compound command so a failing check still fell through
to the push, and rsync --delete ran from a source a concurrent build had just
emptied, faithfully mirroring that emptiness into the catalog. The live maps
catalog went to 404.
Step 3 is now three real commands — check:sri, check:embed-targets, and a git
diff that aborts if anything outside app/doxa-maps changed — and `set -e` is the
first line so any of them aborts before the push. Added `bun run check:settled`
as step 0, because `clean` empties public/doxa-maps at the START of every build,
which is what makes --delete catastrophic rather than merely wrong: it deletes
the live tree to match your momentarily-empty one.
The doc was already right to stay narrow ("the fuller runbook with every gotcha
lives in the project's deploy-cycle notes"), and it already carried postBuffer
with a good explanation. `set -e` is not a gotcha to defer — it is what makes
the four-step block safe at all, so it belongs with the block it protects.
Verified rather than assumed: all three commands exist in package.json, the
block extracted on its own passes `bash -n`, and the exclude-pathspec abort was
run against a real diff — it correctly passes when the diff is scoped and would
fire otherwise. Five gates pass.
Also corrected the runbook's own first instruction while checking it, in the
_qa-cycle notes (not a tracked file). It read "EXIT 0 + all 6 DX guards PASS".
No subset called "DX guards" exists anywhere in the repo, and the count was
wrong besides — build:unlocked chains 32 steps including 25 distinct check:*
gates, and that set grew by five in one flight. A hardcoded gate count is a
snapshot of a moving target. The chain is &&-joined under set -e, so EXIT 0
already means every step passed; that is the assertion that stays true as gates
are added, and the note now says so and gives a one-liner to list the current
set rather than copying it.
Two docs understated deploy method 5. README-SECTION-3 headed the section "built
+ contract-proven; no binary emitted", and develop-a-plugin closed its table
with "2, 4 and 5 are scaffolded but no binary/install has been shot".
Measured: `cargo tauri build` has run and its outputs are on disk.
deployment/src-tauri/target/release/doxa-maps-desktop is a 67,379,880-byte ELF
64-bit LSB pie executable, and target/release/bundle/deb/ holds a 60,554,898-byte
.deb. Eight source files are git-tracked under deployment/src-tauri/, and
check:tauri exits 0.
So "no binary emitted" is false. What is true is narrower and worth stating
precisely: no window has been opened, because this build box is headless with no
Xvfb, so nothing has confirmed the app paints rather than launching to a blank
frame — the exact soft failure the section below already warns about. "Not shot"
means nobody has watched it run; it does not mean nothing was produced. The
closing sentence now separates the three built-not-shot methods, because what is
missing differs for each: no APK for mobile, no captured install for WordPress,
and for Tauri artifacts that exist but have never been launched.
The bodies of both sections were already accurate and are untouched. Only the
status labels were wrong, which is the part a reader skims.
Found while reconciling the ideation sources. The 5-cap spec
(01-ideation-research/coolest-ideation/5-cap-5-deploy.md, 2026-09-22) is CURRENT
and correct on all five rows — verified each: 43 embed.iframe entries in the
manifest, 19 SRI hashes, capacitor.config.json with check:mobile green, the
WordPress PHP with check:wp-embed green, and the Tauri artifacts above.
The /plugin-designer skill is now the stale one, and the direction of the error
has reversed. It says method 5 is "ASPIRATIONAL — not scaffolded. No Tauri
config/dir exists in the repo", and instructs the reader not to repeat the
spec's claim. That catch was CORRECT when written: the spec then said "proven
POC", which was unbacked. The spec has since self-corrected, carrying a dated
2026-09-22 block reading "BUILT, not shot ... only the window LAUNCH is
unverified", which matches the files. The skill's correction froze at the old
reading and over-swung from overclaimed to nonexistent.
That is a hazard worth naming: a correction record — "document X is wrong about
Y" — becomes wrong itself the moment X is fixed, and nothing re-reads it.
Correction notes need the same staleness discipline as the claims they correct.
The skill lives in the session config directory with no git repo, so the fix is
surfaced on BUILD-PLUGIN-DESIGNER-SKILL-MEANS-REAL-WORK as a single precise edit
rather than made here.
Seven gates pass, including check:tauri, check:capability-citations,
check:capability-exemplars, check:doc-scripts and check:quoted-scripts.
check:library-index existed, was correct, and had been failing for about 19.6
hours. Nothing noticed because it runs only when a person types it:
build:unlocked chains 24 gates and this was not one of them.
check:no-orphan-gates passes on it, which is worth understanding rather than
treating as a gap in that gate. It asks whether every gate is REACHABLE — "named
in package.json or imported by something that is" — and check:library-index is
named there. Reachable and wired are different properties. 64 gate-shaped files
exist; 24 run on every build; the rest only run on request.
The fix is to regenerate rather than to check harder. check:composite is also
mtime-based and is in the chain, but it guards build output whose freshness
depends on build ORDER — a real invariant only a human can resolve.
reference-library-index.md is DERIVED from library/, so a staleness failure has
exactly one remedy: run the generator. Wiring the check alone would fail builds
and hand the author a chore; wiring the generator makes the staleness
impossible, which is the only way the file's own header — "DERIVED — cannot
drift from the code" — can be true.
Both are now in the pre-build group, generator then check, beside the other
source-only gates and before `clean`. Safe to run unconditionally: measured
deterministic (byte-identical on re-run) and 237ms. The check is kept after it
so a generator that silently writes nothing still fails the build rather than
passing quietly.
Updating package.json made check:quoted-scripts fail, which is the gate doing
its job, and it surfaced that the quoted copy in README-SECTION-3 was ALREADY
stale before this change: it omitted check:tab-radius, check:synced-css,
check:wp-embed and check:doc-scripts. An omitted step in a quoted list is
invisible — there is no wrong character to notice, only a check the reader
believes is not in the chain. The doc now matches what runs.
Verified by a full build: the generator ran, the check passed, vite built every
bundle, exit 0. The index is not dirty afterwards, which is the determinism
claim holding inside the real chain rather than in an isolated test. Five lines
in the build log match /error|FAIL/ and all five are gate DESCRIPTIONS
containing those words, not results.
check:library-index was FAILING: the derived menu was 70,718 seconds — about
19.6 hours — older than library/composables/useMapFly.js, which this flight
edited to give fitBounds an explicit duration. The file's own header says
"DERIVED — cannot drift from the code", which is only true of a file that gets
regenerated, and nothing had regenerated it.
The regeneration added one entry, and it is not cosmetic: viewportScrim.js was
missing from the index entirely while being imported by six files —
PosterDialog, SemanticTreeLegend, PosterWall, DataTable, LegendTools and
my-upg-100-list/poster-wall. A real, widely-used utility that an inheritor
reading the library menu could not discover. 85 reusable items now catalogued.
Measured the wider hygiene question while here, since the standing work list
asks for non-reusable components to be demoted out of the shared zone: of the 82
items the index advertises, exactly ONE has zero code importers —
useMapSelection.js. The other 81 are live. So the shared library is in good
shape and there is no demotion sweep to run.
The first measurement said fifteen components were unused, and it was wrong in a
way worth recording. It counted importers among BUNDLES only, so anything
imported by a sibling library component read as dead — PosterPreview.vue has
five importers and would have been demoted. Counting importers anywhere, not
just in plugin-designs/, is what reduced fifteen candidates to one.
useMapSelection is left in place deliberately, because removing a file from the
shared zone is a different kind of change from regenerating a derived doc and
deserves its own commit. It is carded instead. Worth knowing before that
decision: it is 192 lines, unchanged since the initial commit d5ba21f, so it was
never adopted rather than orphaned by a refactor; its one dependency
(getCircleRadiusInterpolation) still resolves, so it is dead rather than broken;
and it appears in zero of the nineteen built bundles, which is the decisive
evidence since Vite would tree-shake exactly this.
The legend read "GENERATION 1 / 2 / 3" above a list of world regions. A UUPG
list has no notion of a generation, so the label described nothing and invited
the reading that the tabs filter the map by some cohort. They do not.
The cause is a fallback, not a typo. SemanticTreeLegend derives its tab strip
from the `tabs` prop and, where an entry is missing, substitutes
`{ id: 'gen'+(i+1), label: 'Generation '+(i+1) }` so the strip has something to
render. This bundle passed no `tabs` at all, so all three were placeholders.
country-posters and doxa-research-map both pass real tab sets; doxa-simple-map
passes an explicit null. This was the only bundle relying on the fallback.
What a tab actually is: a DEPTH LEVEL of the tree, which is why selecting a node
jumps the strip to that node's depth. The three levels were read out of
data/legend-tree.js rather than guessed — regions are assembled by grouping
leaves under regionFor(), zones are the middle nodes (Frontier Asia (uncovered),
India, Deaf (affinity bloc A017)), and the leaves are the individual groups each
dot belongs to. Hence Region / Zone / People Group, each with an `info` note in
the shape AFFINITY_TABS and REGIONS_TABS already use.
The ids are bundle-scoped, and that was measured rather than chosen on style.
tabLabel() resolves `tabs.<id>` against the shared i18n catalog FIRST and only
falls back to the English label when no entry exists, so a tab id is a global
namespace. The first version used id:'region' and the legend rendered "WAGF
Region" — library/i18n/locales/en/tabs.json already maps that key to the
country-posters taxonomy. id:'group' collides the same way and would have been
right here only by coincidence, since the catalog means the ROP-2.5 sense. The
prefixed ids own no catalog entry, so the labels in this file are what render.
Desktop only, deliberately. LegendMobile computes
`hideTabs = nodes ? !tabs : _isFlatTabMobile`, so with nodes supplied and no
tabs the mobile sheet hides the strip entirely — it never showed the
placeholder. Passing tabs there would reveal a strip that is currently hidden,
which is a design change rather than a bug fix.
Verified by driving the built bundle in Chromium and reading the three chips
back: Region / Zone / People Group, each carrying its info tooltip, where the
same probe returned "WAGF Regioni / Zonei / People Groupi" before the id fix.
Then the README shot was regenerated and read as an image — the strip renders
REGION / ZONE / PEOPLE GROUP and the column header now says REGION where it said
GENERATION 1. Element count moved 311 -> 314, the three info buttons.
Eleven gates pass, including sfc-parse, template-literal, sri, composite,
one-palette and synced-css.
Found while verifying BUG-UPG100-DOTS-HARD-TO-SEE, which is genuinely fixed: the
dots carry a solid dark stroke that frames them against both the pale zone fills
and the white basemap, confirmed by reading the image rather than the card field.
Two related fixes, both about a measurement that had outlived the thing it
measured.
The shot harness fetched its Mapbox token from doxa.life/api/maps/token on every
run. That token belongs to the Mapbox account `doxalife` and is URL-restricted
to doxa.life, which is why the harness also had to spoof a Referer header to get
any tiles at all. Meanwhile the built bundles carry a different token entirely —
`gosystems`, baked in from vite.doxa-maps-build-config.json — and that one is not
restricted. Measured with no Referer: mapbox-streets-v8, country-boundaries-v1
and bathymetry-v2 all return 200 on the baked token and 403 on the fetched one.
The harness was doing extra work to use the weaker of the two.
It now reads the build config first and keeps the fetch as a fallback. Beyond
simply working, a README image is evidence about the SHIPPED artifact, so it
should render with the credential the artifact ships with; rendering with a
different token means the picture stops proving what a reader downloads. The
local read is also deterministic — the network path degraded silently, setting
the token to empty when doxa.life was slow, after which every shot was taken
token-limited and still written to disk.
check:shot-fidelity had the same problem one layer up. It fired its tileset
findings whenever any file referenced a mapbox:// tileset, and printed
"Referer doxa.life -> 200 · 127.0.0.1 -> 403 · no referer -> 403" as though it
were a live reading. It was one, on 2026-09-21, against the token that shipped
then. After the token swap in 1b6316a the sentence kept printing — warning about
a blank void while the shots came out fully painted. A gate that states a
measured fact has to re-measure it, or it becomes a confident lie at exactly the
moment someone fixes what it describes. It now fetches one real tile with the
baked token and no Referer, and suppresses the tileset findings when that
returns 200.
Network failure is deliberately not treated as a restriction. An offline box
cannot tell "restricted" from "unreachable", and asserting a restriction that
may not exist is the defect being repaired.
Negative-tested: pointing the probe at the restricted doxalife token makes the
gate report RESTRICTED and fire all three findings; the shipped token makes it
report REACHABLE and suppress them. The first attempt at that test proved
nothing and is worth recording — the poison never applied, because doxa.life
returns 403 to Python's default user agent, so the copy was never written and
the unmodified gate ran and "passed". A negative test that cannot fail is the
same defect in miniature. Re-run with a browser UA, it discriminated correctly.
The 12 regenerated screenshots are the point of all this. cap3-monolithic-research
was read as an image, not inferred from the generator's exit code: it now shows
coastlines, country borders, place labels, ocean names and Mapbox/OpenStreetMap
attribution, with the 2,107 data dots sitting on real geography instead of an
empty void. Note the PNG got 67KB SMALLER while gaining all of that, so file size
was never going to answer the question.
check:shot-fonts still fails, and that is pre-existing and honest: this box has no
emoji font, so six bundles shoot tofu boxes. Verified by stashing these edits and
re-running — exit 1 either way. The markup is correct; the fix is a font on the
shot machine, never removing emoji from the product.
The working tree carried a rebuild of all 19 bundles that was never committed.
Ten source commits had landed since the last build output went in: the
page-scroll layout that makes the grid reachable, the eighth filter and its
wrapping row, the tab radius token, the studio's remembered tab, the poster
print window, the fitBounds duration, the configurable pin colour, and the
synced-CSS gate repair.
These are not unshipped fixes. check:catalog-currency fetches all 19 bundles
from the live origin and reports 19 current / 0 stale, and research-dashboard.js
compares byte-identical at 413021 bytes against what nuxtbase.app serves. The
publish happened; only the git record of public/ lagged. Committing it closes
the gap so the next reader of this history does not conclude the tree is ahead
of production when it is level with it.
Worth recording how the verification nearly went wrong. Checking the live bundle
by hand with LIVE=$(curl ...) gave a hash that shared not one character with the
local file, which reads as a clear mismatch. Command substitution strips trailing
newlines, so the fetched copy was 413020 bytes against 413021 on disk, and one
absent byte changes every bit of a sha384. The single-byte size difference was
the only visible clue. Fetching to a file instead makes them identical.
The gate and the ad-hoc check disagreed, and this time the gate was right. The
rule that has been serving here is to suspect a gate when it contradicts
plausible reality; the sharper form is to suspect the newer, less-exercised
instrument. The gate fetches through a Node buffer and had just run that path
nineteen times. The curl pipeline was a minute old.
Nineteen gates pass on exit code, including composite freshness, SRI
consistency, catalog identity and catalog currency. Grading them by their last
printed line does not work and briefly showed ten false failures: these gates
print a verdict and then several lines explaining what they do not cover, so the
last line is teaching prose, not a result. Exit status is the contract the build
chain already uses.
Also drops two untracked scratch probes from 2026-09-22 that have served their
purpose.
The hand-off doc said "Verified places a pasted embed works" and listed seven
platforms. The repo holds an artifact for exactly one of them: check:wp-embed
renders the real WordPress shortcode against the real built manifest, asserts it
emits the same SRI hash the catalog ships, and carries a negative case for a
malformed integrity value. Squarespace, Wix, Google Sites, Notion and Trello have
no artifact anywhere -- they are third-party platforms nobody here has an account
on.
The platforms are plausible and the mechanism is identical everywhere: each
accepts an HTML snippet or a URL embed over https, which is all the embed code
needs. So the list stays, split into what we proved and what we expect. The word
"verified" was the part that overreached, and in a doc an inheritor reads as
ground truth it means "someone tried this" when nobody did.
Worth recording how nearly this hid: grepping the repo for "Squarespace" returns
nineteen files and "Wix" twenty-two, which reads like evidence. They are bundled
copies of this very paragraph inside built .js files. The claim was confirming
itself -- the same shape as a pgrep that matches its own command line.
The selection ring beside these already read cfg.map.selectedColor while the pin
fill and its stroke were literals, so half the pin styling was parameterised and
half was not, for no reason. Both now follow the same shape: a config read with
the current value as the fallback.
This matters beyond tidiness. The heartbeat threshold was made a variable so the
dashboard can point at a dataset that is not these 2107 people groups, and a
different corpus can want a different pin -- the orange was chosen against THIS
choropleth, and its legibility is a property of the pair, not of the colour.
Leaving the pin fixed would have made the dashboard reusable in its data and
fixed in its palette.
Verified: with no config the built map reports circle-color #ef6c00 and
circle-stroke-color #ffffff, byte-identical to the literals they replaced.
Not verified: that an override takes effect. Two runtime injections left the
defaults in place, which is expected rather than broken -- like SEL_COLOR, this
is read once when the element upgrades, and I could not prove my injection beat
that moment. The config channel is proven by check:heartbeat, but statically,
never through a live attribute. The comment says so rather than implying a
capability nobody has exercised.
The white stroke is noted as load-bearing: it carries the pin over the dark bins
where the orange falls to about 1.03 contrast, and it is what stopped the pins
reading as eyes. A host that sets it to the fill colour brings that back.
Selecting a row jumped the camera instead of easing to it. The shared helper
spread FLY_CONFIG into the fitBounds call, which looks like it animates and does
not: FLY_CONFIG carries speed and curve, which flyTo understands and fitBounds
ignores. Without an explicit duration, fitBounds is an instant cut. The flyTo
paths in the same file were always eased, which is why the tree rows animated and
the map did not -- different mechanisms, not one broken setting.
Measured before: the camera moved 1.45 to 6 with two distinct zoom values across
fourteen samples. After: it interpolates through 1.453, 1.806, 3.429.
options still spreads last, so a caller passing duration 0 still jumps. That is
why the default lives here rather than in FLY_CONFIG, which is shared with
callers that must not inherit it.
One thing this box cannot settle: whether 900ms FEELS right. Sampling with
requestAnimationFrame returned six frames in 1.6 seconds -- SwiftShader software
rendering paints at roughly 4fps here, so perceived smoothness is not measurable
on this machine and my earlier "hard cut" reading at 90ms intervals was aliasing
against a starved renderer. The easing is proven present; the duration is a
judgement for a real browser.
The preview branch was unreachable for every user. window.open with `noopener`
returns null by specification -- severing the opener relationship is precisely
what the flag does, so there is no handle to hand back. The document.write that
builds the print sheet ran against that null, so every click fell through to the
fallback: the raw .webp in a tab, no print dialog. The card claimed it opened an
in-browser print preview with a dialog.
Measured in a default browser, no headless flags: window.open('','_blank',
'noopener') returns null, the identical call without the flag returns a usable
handle. I had attributed the null to this headless box last tick, and that was
wrong -- it is what the flag means, everywhere.
noopener stays on the fallback, which only navigates to a URL and never needs a
handle, so the protection is kept where it costs nothing. The window we write
into carries same-origin markup we generate, so the opener reference it regains
is our own.
Verified after rebuilding: the click now opens ONE window titled "Doxa UPG-100
poster — Northwest India" carrying the @page rule, where it previously opened two
and wrote into neither. That window then shows "Poster not available yet." from
the img onerror, which is correct and documented: the full-size posters are 42MB
and deliberately not in the default tree, so the preview degrades honestly
instead of hanging. Set bundlePosters or point assetsBase at a host serving
posters/ to see the image.
Applying last tick's lesson -- grep for the class, not the instance -- found a
third surface teaching the old serve command. README-SECTION-3-cli-commands.md
transcribes the package.json scripts so a reader need not open the file, and it
still showed python3 -m http.server two commits after serve became
serve-strict.mjs. An inheritor following the CLI reference would have started the
permissive server, the one whose forgiveness hid a URL bug in two gates for a
whole flight.
Measured before fixing: ten quoted scripts, nine matching, exactly one drifted. I
had expected build:unlocked to be stale too and it is not -- the doc truncates it
rather than misquoting it, which is the right call for a seven-hundred-character
line.
Hand-fixing the one line would leave the next script change to rot the same way,
so the doc is now checked. The comparison is loose in the three ways a
human-facing doc needs: package.json's trailing hash comments are ignored, the
doc's own slash-slash annotations are ignored, and truncation passes on a prefix
match either way. A quoted script that does not exist in package.json is a hard
failure, since that is a command someone would type and get "script not found".
Completeness is deliberately not asserted; the doc is a curated subset and
demanding otherwise would make it churn on every internal gate.
Self-test poisons the doc in memory two ways, a changed body and a nonexistent
script name, and requires both to be caught. Both are. Full build passes with the
gate in the chain.
Last tick I fixed the golden path's token fetch and left the identical
403-fetching command in reference.md twice. Fixing the instance rather than the
class is the same mistake as scrubbing a string whose generator still writes it.
Both are corrected, along with a stale python3 -m http.server line that predates
serve-strict.
The doc had already MEASURED the restriction and kept prescribing its cause: it
recorded that tiles 403 from 127.0.0.1 and treated a blank basemap as the cost of
working here, while the command above it fetched exactly that token.
My first rewrite then overstated the fix, and the correction is in the doc rather
than hidden in a commit. Measured with the doxa.life token: curl gets 403 with no
Referer, 403 with a 127.0.0.1 Referer, 200 with a doxa.life Referer -- so the
restriction is real and does block the curl path. But a browser gate still
fetched 9 /v4/ tiles with zero failures, because the page resolves its token
through a ladder and the built bundle carries the working baked one. The fix is
to the shell commands; the browser gates were never affected.
Two things worth inheriting came out of checking it. The basemap is Mapbox Light,
pale by design -- I looked at a screenshot and briefly called it "not painting"
because I expected terrain and roads, when the labels and borders ARE the
basemap. And verify:map-paint passes under both tokens, since it asserts a live
GL context rather than loaded tiles, so it is not the signal to consult about
whether tiles arrived.
The golden path told a new author to fetch a token from doxa.life/api/maps/token.
Measured: that token is URL-restricted to doxa.life, so a tile request without
that Referer returns 403 and every basemap in their smoke test renders blank
while the pins draw fine. That is exactly the symptom the Driver reported as
loading the pins but not the underlying map, and it is why tokenUrl was emptied
in the build config the day before. The first command in the hand-off doc
reproduced a known bug.
It now reads the token from the build config, which is the source that works:
same tile request, config token 200, endpoint token 403. That is a pk. public
key baked deliberately, protected by URL restrictions rather than secrecy, and
check:public-hygiene allows pk. while failing the build on sk. and tk. -- so it
is safe to read and never a secret to guard. The doc shows the command, not the
key.
The aggregator had the same bug and a worse symptom: it fetched from the same
endpoint and printed "token present", which meant a string had been obtained,
not that it worked. So a run could report a present token while every map gate
measured a blank basemap. It now prefers the config token, falls back to the
endpoint, and validates whichever it gets with one tile request.
Verified in all three states: the config token reports "present and serves
tiles", a fabricated token reports "tiles 401 - basemaps will be blank", and the
old endpoint token reports "tiles 403 - URL-restricted?". The banner reports
what was measured rather than what was fetched.
check:wp-embed existed as a script and nothing invoked it -- the same orphan
shape as check:synced-css, which had been red and unrun for weeks. This one is
green and unrun, which is quieter but no better: a gate the build does not
consult is documentation.
It is worth running. It renders the real shortcode against stubbed WordPress
functions and asserts the output against the real built manifest, so it needs
neither MySQL nor Docker. Its load-bearing assertion is that the wrapper emits
the same SRI integrity hash the catalog ships, which is what gives the WordPress
path the same tamper protection as the direct-script embed. It also carries a
negative case: a malformed integrity value must be rejected.
Full build passes with it in the chain.
A build removes public/doxa-maps before rebuilding it, so a browser gate running
during one reads an empty tree and reports a confident wrong answer.
verify-shell-scroll said it could not find the dashboard-plus-grid tab twice in
ten minutes while a swarm rebuilt underneath it. That reads exactly like a real
regression and cost three ticks of this flight.
The server now answers 503 for anything under /doxa-maps/ while the manifest is
absent, with a body naming the cause. A 503 rather than a 404 is deliberate: 404
means "this is not here", which a gate may reasonably report as a product defect,
while 503 with a reason cannot be mistaken for a finding. Assets outside the
bundle tree are unaffected.
The check belongs in the server because all nine gates fetch through it. Guarding
one chokepoint means none of them can misread a torn tree and none of them needs
editing, where having every gate take the build lock is nine changes plus a rule
every future gate has to remember.
The aggregator already refused to start against a missing tree, but only at
startup, and a full sweep runs for seventeen minutes. It also blamed a missing
server for a 503, sending the reader to start one that was already running; it
now names the real cause. The gap the server closes is the one that actually bit:
a single gate run directly, at any moment, including mid-sweep.
Verified by hiding the manifest in place: a leaf returns 503 with the explanation
while /assets/ still returns 404, and both return to 200 when it is restored.
Second gate caught by the strict server. check-fixed-anchoring loaded both hosts
by bare-directory URL, which the old permissive local server resolved and the
live layer does not, so it was green only because local was more forgiving than
production.
Worth noting how it failed: UNMEASURED for both hosts, not a false pass. It
refuses to report success when it could not measure, which is the difference
between this gate and one that would have found zero dropdowns and called that
zero anchoring problems.
Now passing with 16 triggers anchored across both hosts, Status among them --
so the eighth filter anchors correctly in the composite as well as standalone.
A sweep of internal/ finds no remaining bare-directory leaf URLs.
bun run serve was python3 -m http.server, which resolves a directory request to
its index.html. The live static layer returns 404 for the same request. So a gate
could pass locally on a URL that does not work in production, and nothing local
could ever catch it.
That is not a harness quirk, it is a blind spot with a green light on it: every
defect inside the permissive gap passes locally by construction and can only be
found in production, which is the worst place to find it. It cost a false
"the publish failed, zero filters live" reading on a publish that was
byte-for-byte correct.
serve-strict.mjs returns 404 for a directory, exactly like production, with no
index fallback and no directory listing. It also refuses to read outside its
root. Loopback only, inherited from the script it replaces, whose own comment
records that the bind was once 0.0.0.0 and answered on the box's public IP while
a gate was running. The permissive server is kept as serve:permissive rather
than deleted, so the difference can be demonstrated.
It earned itself immediately: verify-shell-scroll held two bare-directory URLs
and failed the first time it ran against the strict server. Both now ask for
index.html, which is the form the manifest already ships for all 28 profiles,
and the gate passes again -- both wheel gestures moving the grid 1500px onto
screen.
Fixing the server rather than the URLs is the point. The repo was already
production-correct: 28 of 28 manifest URLs and 82 gate references use
index.html. What was missing was anything that could fail when one did not. A
rule you have to remember fails under time pressure; a server that returns 404
does not.
The Driver named eight filters -- people, region, block, country, language,
religion, prayer, engagement -- and the rail rendered seven. engagement_status
was already fully built: a label and getter, the Status section in the tree, and
the Engagement column in the table. It had simply never been registered in the
dropdown list, so the one piece missing was a single entry.
Adding it exposed the constraint that goes with the count. The dropdowns are a
fixed 168px on a 200px pitch, so eight need about 1428px. At a 1440 viewport that
just fits; at 1280 the row reported scrollWidth 1414 against clientWidth 1252 --
a horizontal scrollbar, which is exactly what the Driver asked not to see.
The row now wraps rather than scrolls. Wrapping is the right lever because the
fixed 168px width is itself a Driver decision: a flexible width was what made the
dropdowns jump as a selection changed. The justify-content pair is kept, not
simplified -- its own comment records that `safe` degrades space-evenly to
flex-start rather than pushing the first item to an offset a scroller can never
reach. That hazard belonged to the scroller and costs nothing now, so it stays.
Verified on a settled tree at three widths. 1440, 1280 and 1024 all render eight
filters across two rows at identical offsets, with the row reporting no
horizontal overflow and every filter fully inside the viewport.
The gate reported 14 conflicts across two files. Thirteen were false and it was
blind to real ones, and both came from a single cause: it keyed a rule on the
last class before the brace, so any qualified rule was filed under its own base
rule. A dark-mode override, a .dsm-dark variant and a :host(:fullscreen) rule all
merged into the unconditional rules they were meant to override, and the pair was
then reported as the file disagreeing with itself. In every case both copies were
identical and the code correct.
Merging is last-write-wins, so the same bug also HID conflicts. Poisoning
.dsm-root inset from 0 to 7px in the shadow copy produced no finding at all,
because the fullscreen rule's own inset:0 was merged in afterwards and restored
it. A property could be shared, genuinely divergent, and invisible.
The key is now the full selector, and at-rules are part of it. The header already
claimed media-query variants were treated as distinct rules; nothing implemented
it, and PeopleGroupDetail's 18px name with a 16px @media override read as the
file contradicting itself when the shadow copy simply has no mobile rule -- which
this gate's own contract explicitly allows. At-rule bodies are brace-matched
rather than regex-matched, since a lazy pattern stops at the first inner brace.
The shadow literal is also sliced AFTER its opening backtick. Slicing from the
anchor left useShadowStyles(` at the head of the CSS, which a full-selector
pattern absorbs into the first rule -- .dsm-root was captured as
"useShadowStyles(` .dsm-root" and silently dropped.
That leaves one true finding, and it was real: .action-buttons padding-top was
12px as a Vue child and 4px in a shadow root. Both values date from the initial
commit, so there is no later intent to infer; aligned to the shadow copy's 4px
because that is the copy that reaches the shipped bundles, so it preserves what
users have been seeing rather than changing it.
check:synced-css:self-test poisons three properties in memory and requires each
to be caught. inset is there deliberately -- it is the one the old implementation
missed, so it is the case that proves the fix. Now in build:unlocked, which it
could never be while it was red.
The 999px stadium was a real instruction that shipped, and its rationale is still
in the layout file as history. A superseded rationale that still reads as current
is how a reversed decision gets undone -- a reader trusting it would restore the
pill believing they were fixing a regression. The comment now says not to; this
makes that enforceable.
It asserts the TOKEN rather than the value, because the requirement is that the
tabs, the collapse button and the filter toggles agree. A shared knob guarantees
that; three matching literals only coincidentally satisfy it. The expected
fallback is READ FROM .vtl-collapse rather than hard-coded, so a gate asserting
8px cannot pass while the collapse button moves to 10px and the two surfaces
silently diverge. Both synced copies are checked, so a fix applied to one host
fails here rather than shipping correct in one and wrong in the other.
.vtl-cap keeps its pill and is deliberately not asserted: the complaint was the
ratio of radius to size, and a gate banning 999px everywhere would over-apply the
correction.
check:tab-radius:self-test poisons the source in memory and requires both
regressions to be caught -- the pill restored, and a bare literal beside the
token. Both caught, tree untouched. Wired into build:unlocked beside the other
source-level checks so it fails in a second rather than after the vite loop.
Noted while wiring: check:synced-css is NOT in the build chain, which is how two
files have stayed in conflict. Left alone here -- turning it on is its own change
with its own failures to fix first.
The vertical tabs were a 999px stadium on a 48px row. That was a real earlier
instruction -- imitate the YouTube active row -- and it shipped, but measured
against the product it is the only thing shaped that way: the collapse button is
8px, the filter toggles are 8px, and 8px is already the most common radius in
the layout file. They now read var(--vtl-radius,8px), so a consumer has one knob
and the three surfaces cannot drift apart. The 48px Material row height is
untouched. The YouTube rationale stays in the comment as history with an explicit
note not to restore the pill from it, because a superseded rationale that still
reads as current is how a reversed decision gets quietly undone.
The .vtl-cap badge keeps its pill. The complaint was about the ratio of radius to
size -- a 16px chip at 999px is a chip, a 48px row at 999px is a stadium.
The studio opened on nothing and said "Choose an element from the list." It now
resolves a tab in priority order: the URL hash, since an explicit shareable
request should beat a remembered one; then localStorage, so a reload is not a
fresh start; then the first row, so the pane is never empty. This lives in the
studio rather than the layout because VerticalTabsLayout is controlled via
v-model:active and deliberately holds no selection state.
Storage is keyed by pathname so two shells on one origin do not fight over one
key, every access is wrapped because localStorage throws in private mode and an
exception in setup would blank the whole subtree, and the key is only written
after the row is confirmed to exist so a bad key cannot poison the next load.
Verified in the built shell on a settled tree: first load auto-selects with no
hint and stores the key; clicking big-picture moves the selection and updates
storage; a reload restores big-picture; and a deliberately poisoned key falls
back to the first tab and rewrites itself rather than rendering an empty pane.
The Driver could not scroll down to the people-groups grid. The cause was a
layout mismatch rather than any one property: research-dashboard is a
fixed-viewport app whose table scrolls internally, and the cap-4 composite
stacked it above a grid and expected the page to scroll, pinning the band to one
screen so height:100% would resolve. At a 900px viewport that left the table a
269px window over 54834px of rows, so a wheel anywhere in the lower third landed
on the table and never reached the page.
research-dashboard now accepts layout:page-scroll through profileConfig, the
channel ProfileLoader already exposes as the profile-config attribute. A prop
would not work here: the registered custom element is ProfileLoader, which
renders the profile with no props bound, so a declared prop type-checks, builds
clean and never fires. Default is unset, so every existing embed is unchanged.
In that mode the shell height is auto, the map row carries an explicit height so
it cannot collapse, and the table keeps an internal scroll bounded at 62svh.
Both extremes were measured and both are wrong: at 34% of a screen the table is
a keyhole that captures every wheel event, and released to overflow:visible it
renders all 54834px and puts the grid at y=57777 -- reachable in principle,
useless in practice. A tall bounded panel is neither.
Verified in the cap-5 shell on a settled tree: wheeling over the map and
wheeling below it now both move the page 1500px, which is its entire scroll
range, and the grid lands on screen at top 851. The two gestures agreeing is the
real proof -- the broken state read 300 against 2311, the signature of something
consuming the wheel. The standalone leaf is unchanged: no page-scroll class,
900px shell, internal table scroll intact.
The previous commit set overscroll-behavior:contain on .rd-grid to stop it
swallowing the wheel. That is backwards. contain prevents a scroll which bottoms
out in an element from chaining to its parent, and chaining to the parent is the
behaviour that would let the page keep moving once the table is exhausted.
Measured before and after: the symptom did not move at all, because a table with
54834px of content never bottoms out in the first place.
It is left at the default.
The diagnosis that produced it was reached by geometry, and geometry was the
wrong instrument. getBoundingClientRect placed this element at y=673-880, well
below the y=420 gesture, which appeared to exonerate it; a deep shadow walk had
earlier reported its scrollTop moving, which appeared to convict it. Both are
readings of state at some moment, not of what the browser dispatched. A
capture-phase wheel listener reading event.composedPath() settles it: at y=420
the path is rd-td, rd-row, rd-grid, rd-table-wrap. Use the event path when
geometry and behaviour disagree.
The underlying bug is still open and is a layout mismatch rather than a CSS
property: the research dashboard is a fixed-viewport grid that gives its table
34% of the band and legitimately owns the wheel inside it, hosted in a composite
that expects the page to scroll past it. That needs a design decision, not a
fourth attempt at a one-line fix.
The Driver could not scroll down to the people-groups grid. Three separate
diagnoses blamed the map, including one of mine that shipped. Measured in the
cap-5 shell: a ten-tick wheel with the cursor over the dashboard moved the outer
pane 300px while .rd-grid's own scrollTop went 0 to 2606. The wheel was being
consumed by the table -- a virtualized grid whose scrollHeight is 54834px inside
a ~207px window. That is ordinary scroll-chaining: a nested scrollport eats wheel
events until it reaches its own end, and with 54 thousand pixels of table it
never reaches the end. The Mapbox canvas sits above the cursor and was never
involved.
overscroll-behavior:contain does not stop the table scrolling; it stops it
chaining, so the remainder now reaches the pane.
The gate that should have caught this had two defects of its own. It measured the
gesture the Driver makes and then asserted on a different number, so it passed at
2611px while his gesture moved 300. When that was fixed the threshold was written
as "moved less than 200px" -- a figure picked without comparing it to the value
already measured as broken, which was 300, so it still passed. The threshold is
now derived from a measured baseline: the same gesture performed lower down the
page, where it is known to work. Two identical gestures on one surface should
move it comparably, and there is no constant left to rot.
The panel destroys and re-creates its Map on a re-render, and the dev server's HMR
does this freely, which leaves window.__rdashMap pointing at a torn-down instance
whose getSource() throws "Cannot read properties of undefined (reading
'getOwnSource')". Measured one run in three failing that way on the dev surface
while the product was fine — the first invocation through the package.json script
failed for exactly this reason and the next passed unchanged.
A gate that reports a product bug when its own reference went stale is a gate that
gets switched off. __live() now proves the handle still works before any assertion
reads through it, and readState() waits for the re-created instance to repopulate
rather than treating a dangling reference as a verdict. A state that is still
stale after the grace period is reported as an infrastructure fault, named as such,
not as a filter failure.
Verified 4/4 consecutive passes on the dev surface where it previously flaked, and
all four negative-test modes still catch their regressions (the retry must not mask
a real failure).
Three comment sites still described the pre-heartbeat product in the present
tense, which is the confidently-wrong failure this file warns about elsewhere:
- the measured contrast table cited the old pale-coral hexes
- 'WHAT IT IS NOW. Fill #1a237e ... under a white ring' described a pin that
no longer exists, and listed 'reverting to orange' as a live rejection when
the Driver has since asked for orange
- the constraints list asserted 'navy pin >= 7:1 on every bin. PASS', which
reads as an acceptance criterion someone would try to restore
An orange pin cannot reach 7:1 against a red ramp at any tuning, so the
criterion is replaced rather than quietly lowered: effective visibility is
max(orange disc, white stroke) per bin, worst 1.83.
Also answers the standing 'MEASURE the pale end' note: the two bands swapped
roles. The disc is strongest on the pale bins where the ring is weak, and
collapses on the dark bins where the ring takes over, so both must stay.
check:heartbeat proved the PANEL FALLBACK was intact and called that "default
ramp unchanged". It is not the same property. The running app resolves the ramp
with dashboard.config.js's map.* layered on top of that fallback, and the gate
never read the real config: assertion F checked only that heartbeatThreshold was
DECLARED, never what it was SET TO.
Measured consequence, reproduced before fixing:
sed -i 's/heartbeatThreshold: 150,/heartbeatThreshold: 999,/' \
plugin-designs/research-dashboard/dashboard.config.js
node internal/check-heartbeat-threshold.mjs # exit 0
The shipped map could silently change its ramp while the gate reported it
unchanged. Now exits 1, naming the key and its value.
Adds assertion A2: resolve the ramp the way the running app does — panel
defaults with the shipped map.* applied — and require it to equal the historical
5/20/60/150/Infinity with its labels. A (fallback) and A2 (shipped) share one
comparison helper so they cannot drift. A2 also rejects a shipped heartbeatMode
other than 'fixed': a data-derived ramp is right for an unknown dataset and
wrong for this one, where 150 is deliberate. Changing the shipped ramp is now a
deliberate act that must update HISTORICAL in the same commit.
dashboard.config.js is read by brace-matching its `map:` literal rather than
import(): it pulls in @map/* aliases and a JSON module, so importing it would
need Vite's resolver — a dependency that buys nothing for a bag of scalars.
The self-test now runs three cases, each required to fire the assertion that
exists for it, and poisons in memory so a crash cannot leave the tree edited:
[literal] resolver replaced by the old array -> must fire B
[shipped-default] shipped heartbeatThreshold changed -> must fire A2
[shipped-mode] shipped heartbeatMode flipped to quantile -> must fire A2
The header previously claimed the gate was "negative-tested" on the strength of
the first case alone. True of that case, misleading overall, so it now states
per-case coverage and what is NOT covered (colour contrast, and whether the map
paints at all). Testing that the FEATURE works — a configured threshold moves
the edge — is not testing that the REGRESSION is caught, and only the second
protects the requirement that today's map must not change.
The prayer filter was reported as "not applying" to the map. Measuring it first
changed the fix: the filter was never broken. Selecting "Has Prayer" already
narrowed the rd-bubbles source 2107 -> 689 features, exactly matching the
dropdown's own tally, disjoint from "Needs Prayer" (1418), summing to 2107 and
round-tripping on clear.
What was broken is that circle-color was the flat literal '#ef6c00' — read back
off the live layer, the bare string, not an expression — so every dot painted the
same orange whether it had prayer or not. A prayer question got an answer with no
prayer information in it, and the surviving dots looked identical to the ones the
user started with. That is why a working filter reads as "not applying".
This gate asserts all three halves, because any one alone is a false pass:
1. the selection changes WHICH dots are on the map, by count AND by identity
2. every surviving dot satisfies the level that was selected
3. while a prayer filter is active the colour is a data-driven expression
reading peoplePraying, not a flat literal
Assertion 3 is the one that matters: 1 and 2 were already green while the bug was
visible. Identity is checked as well as count because the filter removes from the
tail of an alphabetical list, so the first five slugs are byte-identical before
and after — a gate reading the head of the list would report "unchanged".
NEGATIVE-TESTED in four modes, each isolating one assertion, all verified caught:
colour reverts only the paint (the reported bug) -> caught by assertion 3
props strips peoplePraying -> caught by assertion 2
frozen blocks the source update entirely -> caught by assertion 1
both reverts the lot -> caught
A gate that cannot fail is worse than no gate.
Verified on both hosts against the BUILT tree: the cap-5 shell and the standalone
leaf. Browser gate, so not in build:unlocked.
The ramp's top bin is now a label red (#cd2027 — the OKLCh cluster that
Heinz, Campbell's and fire-engine all sit in) so the countries holding the
most unreached people groups read as a heart rather than as clay.
Pins move to Material Orange 800 (#ef6c00) and the selection ring takes over
the navy the pins vacated (#1a237e): an orange pin against the old neon-orange
selection ring measured 1.07 contrast, which would have made the selected
state invisible.
Legend labels the top bin 'heartbeat zone', derived at binLabel() so a host
that moves the threshold cannot strand the name on a bin that is no longer
the top one.
The choropleth's bin edges were a 5-stop literal (5/20/60/150/Infinity) in
DashboardMapPanel.vue. Those numbers are not a property of choropleths; they
are a property of THIS dataset — ~2000 people groups in focus. Pointed at a
200-group dataset, a 150 cutoff puts every country in the bottom bin and the
map renders uniformly pale: no crash, no error, correct code, meaningless map.
A dataset assumption wearing the costume of a constant.
The top band is the HEARTBEAT ZONE — the countries holding the most people
groups. Its edge now comes from dashboard.config.js as map.heartbeatThreshold,
alongside the other per-dataset facts (facets, columns, kpis). Re-pointing the
dashboard at a new dataset is a config edit, not a source edit.
Splits the old fused BINS array into the two independent facts it always was:
BIN_COLORS (measured against the navy pin, dataset-independent) and the edges
(pure dataset assumption). Fused, moving a threshold meant restating every hex
— silently reverting the contrast work — and restyling meant restating every
edge. Set either alone now.
Setting heartbeatThreshold alone rescales the three lower edges by their
original ratios, so the ramp keeps its shape (long tail of small counts, short
head of large ones) at any dataset size. Legend labels derive from the edges,
so a moved threshold cannot leave a stale "150+" on the legend. Opt-in
'quantile' mode derives the edges from the data actually loaded; it is NOT the
default, because 150 is a deliberate number for this dataset and a derived
default would silently change today's map.
Two bugs found and fixed while measuring:
- Edges could land at 1, creating a bin no count can enter (colorFor tests
`count < upTo`): the ramp painted 4 of its 5 colours while the legend
advertised 5. Appeared at threshold 40 and again in quantile mode.
- profileConfig merged shallowly, so a host passing the single key it cares
about — {map:{heartbeatThreshold:40}} — replaced the whole map object and
dropped mapStyle:'paper'. The one override a host is most likely to write
was the one that broke the basemap. `map` now merges one level deep; every
other key stays shallow.
No defineProps: the registered custom element is ProfileLoader, which renders
the profile with no props bound, so a prop declared on the profile would read
as configurable and never fire. The reachable attribute path is ProfileLoader's
existing profile-config JSON, verified end-to-end.
Default rendering is unchanged, verified by measurement rather than eyeball:
bin assignment over the 114-row committed fixture (59 countries) plus a 17-point
count sweep is identical before and after, with and without config supplied.
internal/check-heartbeat-threshold.mjs executes the resolver from the live SFC
and asserts the bins MOVE when the config moves — a grep for "150" would both
false-positive (it is the legitimate default) and false-negative (a
re-hard-coding at 200 sails through). Its --self-test re-hard-codes the ramp in
memory and requires the gate to reject it.
The repo is handed to the Doxa team, and a code name from its build history
means nothing to an inheritor. Two places carried it, both regenerating:
- public/.build.lock was TRACKED. internal/build-lock.sh stamps it with
`by=$(whoami)` under flock on every build, so each rebuild committed the
building machine's username. Scrubbing the string would have been useless;
the file is pure runtime state nothing reads but the lock, so it is now
ignored via public/.gitignore instead.
- check-no-absolute-paths.mjs quoted a real home path in its header to
explain the rule. The prose works the same with /home/<user>/.
check:no-codename makes it stick. It scans tracked files only (the set a clone
receives), names every offending file:line in one pass, and refuses to pass
vacuously on a short file list.
Two things it has to get right or it becomes noise. "10x" is ordinary English
for a multiplier and library/scripts/research uses it correctly, so only the
full two-part name matches. And the same letters appear as the unix username
inside /home/ paths, which is a portability defect check:no-abs-paths already
reports better — those are listed, not failed, so the two gates cannot
disagree about one string.
It carries no ALLOW entry for itself. A gate must never be its own witness,
and an exemption is a hole a real leak could hide in, so the pattern is
assembled from fragments at run time and the file scans itself on the same
terms as every other.
Negative-tested: planting the name in README.md fails naming README.md:2,
exit 1; removing it passes. All five spellings (LK10X, LK 10X, lk10x, LK-10X,
lk_10x) planted across five different shipped surfaces are reported together
in one run, exit 1; reverting returns exit 0.
Also quotes check:heartbeat into the CLI doc, which check:quoted-scripts
requires and which landed in package.json without it.
syncScrollZoomToHost decided whether Mapbox should keep scrollZoom by sampling
the layout at 0, 1200 and 4000ms and then never asking again. That is a race,
not a sync: the cap-5 dashboard tab lazy-mounts on activation, so at every one
of those instants the scrollport ancestor had not reached its final height. The
map kept scrollZoom enabled and ate the wheel. Wheeling over the map moved the
grid 300px; wheeling below it moved 2611px. The cursor is over the map, so the
people-groups grid under the dashboard was unreachable.
The condition is layout-dependent, so observe layout instead of guessing when it
settles: a ResizeObserver on the map container, the scrollport that owns the page
scroll, and body, plus a resize listener. Every event that can flip the answer now
re-asks it.
verify-shell-scroll already measured this. It computed movedByMap for the gesture
over the map, then asserted only on movedTotal, which sums in a second gesture
below the map -- so it reported PASS at 2611px while the real gesture moved 300px.
It now asserts on the number it was built to measure. Worth remembering as its own
failure family: a gate that measures the right thing and grades a different
variable, which fails honestly but never on the condition it exists for.
doxa-maps-88655c70