275 commits

Author	SHA1	Message	Date
doxa-maps-88655c70	e7f84bb84d	country-posters: a phone can export too — and the gate was shutting the panel ... Same gap as my-upg-100-list. countries-map.vue provided onSemanticTreeSelect to the mobile sheet but not onLegendExport, so its embedded SemanticTreeLegend rendered with exportEnabled defaulting to false. Fixed the same way, gated on the profile's own EXPORT_FEATURE_ENABLED so the phone never gets an affordance the desktop deliberately hides. Mutation-tested, which is what shows the provide is load-bearing: without it mobile reports 3 .stl-export elements with 0 having a real box, and fails. With it, 6 present and 3 boxed, and passes. I deferred this last tick as "another agent's profile". That was my assumption, not a recorded rule. The swarm lane assignment maps FILES, and countries-map.vue appears in no lane — while SemanticTreeLegend.vue, which I have been editing throughout, is in one. Treating profile directories as ownership boundaries is a reasonable default, but it is not what the swarm recorded, and it cost a known two-line fix a full tick. A second defect turned up in my own gate. check:legend-export-reachable clicked the legend toggle unconditionally. That is right for my-upg-100-list, whose sheet starts closed, and exactly wrong for country-posters, whose sheet opens expanded: 8 rows visible before the click, 0 after. The gate was closing the panel it came to inspect and then reporting "no selectable row" — which reads as a product defect and was purely the probe. It now toggles only when nothing is selectable yet, and both profiles pass. Also re-verified two cards already marked done, after the previous tick found part (a) of the legend card shipped-but-broken. Legend part (b), "remove or demote Zone", holds: zero occurrences of "zone" in the rendered legend. The per-map share policy holds at the rendered layer — upg-100 has no share button, prayer-progress has exactly one — with smoke:share-all green across all twelve published bundles and its coverage set checked against the policy's own list.	2026-09-24 18:21:35 +00:00
doxa-maps-88655c70	f344b74334	Merge main into bundler-2/work	2026-09-24 17:49:22 +00:00
doxa-maps-88655c70	4d79c08fd4	Merge branch 'main' of https://git.nuxtbase.app/doxa-life/doxa-maps into bundler-3/work ... # Conflicts: # public/doxa-maps/index.html	2026-09-24 17:48:14 +00:00
doxa-maps-88655c70	e1df0d5a7c	Add Scripture Earth, and lift 28 groups off "nothing found" ... SIL and its translation partners publish Scripture for small languages the big catalogues skip, which is exactly the population left in the gap: 2,901 groups had nothing in eBible, Arclight, Door43 or FCBH. 921 codes now carry a Scripture Earth link and 28 groups that had nothing at all — 339,550 people — have Scripture in their own language for the first time on this map. Tier 0 falls 2,901 to 2,873. Most of this source is not what it appears to be, and the fetcher throws away both false positives rather than shipping them. Their open index lists 3,477 language directories, but 764 of the ones we can join are empty stubs: trusting the listing alone would have handed 716 people groups a link to an empty folder. And a "video" directory holds JESUSFilm-<iso>.txt metadata, not playable film — 1,588 codes have nothing else, so video alone never qualifies a code. Only PDF, audio, Scripture App Builder, study notes and SFM text count. All 921 URLs verified HTTP 200 before shipping, and the artefacts were opened by hand first: Baka's is 14.4 MB of application/pdf, Foodo's 40.7 MB, and a nonexistent sibling 404s, so a 200 here means a file. The coverage gate, the verifier and the links table each had to be taught the new field. Leaving any one of them ignorant would have been worse than not adding the source: the gate caught all 28 tier changes as inconsistent, and the links table filed 921 rows under the "other" publisher — the fallback that exists to make an unscreened domain impossible to hide. The sheet's "checked" line now names the pool too, since it is searched.	2026-09-24 17:46:27 +00:00
doxa-maps-88655c70	1fba4ff86f	Merge main into bundler-2/work	2026-09-24 17:43:45 +00:00
doxa-maps-88655c70	9acd4f8865	Queue the browser gates, and let them serve their own tree ... Two problems, one change. LOAD. Seven agents each running a wave put 7+ chrome-headless renders on one box; measured today it reached load 47 with 8GB of swap, and a browser gate that is swapping measures the swap, not the product. The wave runner now holds browser steps while 1-min load is at or above LOAD_MAX (12) and takes a coarse flock before each one, so they queue instead of dogpiling. Thresholds, cadence and the 20-minute cap are bundler-3's wait-for-quiet.sh verbatim, and BROWSER_GATE_LOCK selects the rendezvous, so every agent lands on one lock whichever entry point they use. Static gates are untouched: in gates:post that is 38 free, 4 queued. The load wait is taken ONCE per wave, not once per gate. Per-step it multiplied the same hold by the number of browser gates — an hour of a wave doing nothing, which is how a load fix becomes a reason to stop running gates. The flock is what serializes; the wait only decides when to join the queue. Browser steps are identified from the gate FILE (a playwright import), not a hand-kept list that goes stale the first time someone adds a gate — the one missing from such a list is exactly the one that rejoins the dogpile. `verify` is caught too: it imports no playwright itself but spawns three gates that render, and it already marks them browser:true, so that declaration is honoured rather than duplicated. COVERAGE. Yesterday's guard made check:provider-switch and check:packet-browser SKIP in every wave, because their default ports (4173, 4898) belong to other worktrees on this machine. Skipping was honest but a gate that skips every time is a gate nobody runs, so on a mismatch they now start a short-lived server over THIS checkout and measure that instead — the point was never the port, it was being able to prove which build answered. MEASURED: a served tree whose manifest differs by one key but has all the same pages -> "serves a DIFFERENT build", then "serving this checkout on :28384 instead", then a real verdict (16 -> 5 mapbox requests). packet-browser likewise, once it re-navigates to the new origin — a dynamic import across origins is refused by a plain static server, which cost one failed run to learn. gates:post 40/42, the only skips being the two that genuinely have no input (packets-all, zone-census); it was 4 before this. The lock path default is product-named. The shared file several shells export carries an internal code name, and check:no-codename refuses to let a repo we hand over carry one — it caught this commit's first draft.	2026-09-24 17:43:32 +00:00
doxa-maps-88655c70	3db1dc1852	legend: on a phone you can browse the UPG-100 lists and cannot export them ... The Export affordance lives in SemanticTreeLegend, which upg-100-list.vue mounts for desktop only — its own comment says "Hidden below the mobile breakpoint, where <LegendMobile>...". LegendMobile, the phone bottom-sheet, contains the string "export" zero times. So the whole export path is desktop-only. The packet IS the product for this profile. The Driver asked for "print options at the top right of the legend... that's the only way that map would be usable". A reader on a phone gets the browsing half and none of the printing half, with no error and nothing to click — the failure is invisible rather than broken, which is why it survived. Measured at 390x844 against 1500x1000. Desktop: selecting a row takes .stl-export from 0 to 3 elements, all with a real box, labelled "Export". Mobile: the same 3 elements exist and measure 0x0 at (0,0), with display:block and visibility:visible, inside an overflow:hidden parent — the desktop panel rendered without being laid out. Two earlier readings of mine were wrong, and the gate now encodes against both. "No export button at either width" — I had not selected a row, and the control is gated on selectedNode. "No legend rows on mobile" — 20 rows exist with 0 visible, because the sheet starts closed. Both were true statements about the wrong surface, and both would have been reported as product defects. The gate asserts a real box rather than a CSS property, for the same reason: the mobile elements report visibility:visible while measuring nothing. It FAILS on mobile by design and is deliberately not wave-wired. WHERE the control goes on a phone is a design call — the sheet has no titlebar to put a top-right action in, and SemanticTreeLegend is shared by four profiles — so the gate names the gap instead of assuming a fix. Mutation-tested: flipping SHOW_EXPORT_BUTTON off drops desktop to zero and the message distinguishes "no element at all" from "exists but 0x0".	2026-09-24 17:27:28 +00:00
doxa-maps-88655c70	0f9ca8af20	Merge main into bundler-2/work	2026-09-24 17:00:25 +00:00
doxa-maps-88655c70	6602cd1399	Browser gates: prove the server is THIS build before believing it ... Five gates took their measurement from whatever answered a default localhost port. On this machine that port belongs to whichever worktree started first: :4173 is wt-packet's server, :4898 is its repo root. Measured today — an hour of probing reported on a build that was not on disk here, and the mistake was only caught because a marker string was in the file and absent from the response. "Answers 200" and "is serving this checkout" are different questions, and only the second one licenses a verdict. _serves-this-tree.mjs already asked it (it exists because the gospel-resources gate hit this and spent three runs reporting on the wrong tree) but only three callers used it. Wired into the five that measure a served page and had no such check: check-provider-switch request tally per host — the wrong tree's tally check-maplibre-layer-drops silent layer drops — invisible by nature check-filter-width-stable width divergence — would accuse untouched CSS check-facet-changes-map data flow on facet change check-packet-browser imports the renderer FROM the server Only a genuine MISMATCH skips. "No manifest to compare" is a different precondition (an unbuilt checkout) that each gate already speaks for, and turning that into a skip would silence these on the builds they should run on. A mismatch exits 0, like the unreachable case, because it is a precondition and not a product finding — but it prints which, so nobody reads it as a pass. CONTROLS, each fired, per gate: correct server -> PASS with a real number (provider-switch 19 -> 5 mapbox requests, drops 17/17, filter-width identical, facet 2107 -> 1209 dots, packet-browser headings match); a served tree whose manifest differs by one key -> SKIP naming "serves a DIFFERENT build"; no server -> the pre-existing unreachable SKIP, unchanged. One correction found by running it rather than by reading it: the first wiring passed the LEAF PAGE URL where the helper wants the ORIGIN, so it looked for the manifest under the page's own path and skipped every run for the wrong reason. node --check cannot see that; only running both controls can. KNOWN COST, not hidden: in a wave with no server of this tree running, check:provider-switch and check:packet-browser now SKIP where they used to report a green about another worktree. That is the honest reading, not a regression, and the runner prints "evaluated nothing" for them. Next increment is to let these gates serve this checkout themselves so they measure again.	2026-09-24 17:00:11 +00:00
doxa-maps-88655c70	d9d4cbd0da	spa tab-order gate: the product honoured the Driver, the gate over-read him ... Red since the rail gained its three-section structure on 2026-09-23. The Driver said "cap-5 tab order (Big Picture, UPG-100, Prayer Progress, Gospel Resources)". That names an ORDER, not a row count, and nothing in it forbids a row between. The gate quoted him correctly and then asserted those four names at positions 1-4 of a flat rail. Measured at the rendered layer: the rail is Big Picture, Simple Research, Regions, UPG-100 List, Prayer Progress, Cities with Internet, Gospel Resources, plus five lab-badged Experimental rows when that folder is open. The Driver's four sit at 1/4/5/7, all present, relative order intact. The instruction is honoured. Provenance rather than timestamps was the tiebreaker. My first instinct was "source is newer, so the gate is stale" — but this gate cites a Driver instruction verbatim, so I checked what actually moved. The suspect commit turned out not to touch the main rail at all; the restructure was two days earlier. A second defect in the same gate: '.vtl-tab' matched nested elements, returning 35 hits for 7 real rows. The old code's "first four" were therefore all fragments of rows 1 and 2 — which is why it reported row 2 as "Simple Research" when Simple Research is genuinely row 2 of seven. Now keeps only outermost matches. The expectation is presence, plus tab 1 positional, plus relative order for the rest. Tab 1 stays positional because that is exactly what the Driver claimed: the landing surface. Mutation-tested both kinds — reversing the order fails naming the rows, expecting a different landing surface fails naming tab 1. PASS now prints the whole rail with the Driver's four starred, so a reader sees the rows between them. A gate printing only its own four would hide the structure that made the old assertion wrong. Still not wave-wired, and the reason is on the script: it FAILS rather than skips when the SPA is unreachable, deliberately — "a gate that cannot reach its subject has not passed, it has not run" — which is right standalone and incompatible with gates:post running on server-less checkouts.	2026-09-24 16:56:10 +00:00
doxa-maps-88655c70	5905de8e30	facet gate: green 1 run in 4, and the variance is the dev server's ... Re-ran the unwired-gate census from last tick. check:facet-changes-map failed with a clean verdict line, which looked like a real finding. It was not — it is flaky: PASS, FAIL, FAIL, FAIL across four consecutive runs, failing with "the map never populated after 90s". Against the BUILT tree it passes: twice in the first check, then three more times through the new script entry. Five for five. The product is fine. A flaky gate is worse than a failing one. It teaches you to re-run until green, which is how a real red later gets dismissed as "just the flake". The cause is the default target. A dev page load pulls 88 unbundled module requests against the built leaf's 3, and Vite compiles them on demand, so with several agents working the same box the wait this gate ALREADY retries three times at 90s can still lose. Raising the timeout is the wrong fix for exactly that reason: it is not one slow moment, it is contention. The dev default is NOT changed. Its header gives a sound reason — the dev surface always reflects current source — and another agent may be relying on it for hand-running uncommitted work. Instead the flakiness, its cause and the deterministic invocation are recorded on the script, and check:facet-changes-map:built makes the built-tree run a command rather than something to remember. Also recorded why this gate is not wave-wired: a step green 1 run in 4 would train everyone to ignore the wave. One dead end worth recording. I tried to reverse-engineer the wait by locating the map instance myself and got "never found" on BOTH surfaces — my selector was wrong, not the product. The gate has working discovery of its own; I stopped probing and used its result, which was already decisive.	2026-09-24 16:38:59 +00:00
doxa-maps-88655c70	bfc1e0029b	gates: two unwired checks were red on main, and nothing could tell us ... Censused the 67 gate scripts that are in no wave. The framing I had been using — "coverage we are not getting" — was wrong in the more serious direction. Two of them were FAILING on main right now. The gates exist, work, and had found something; because nothing ran them the findings sat silently. check:legend-source, a real product finding: the live corpus moved 2108 -> 2107 and one group crossed Unengaged -> Engaged, so the legend baseline was describing a dataset that no longer exists. Confirmed 2107 independently against the live endpoint rather than trusting the gate's own reading. Updated the baseline following the procedure its header requires, repeated rather than assumed: grepping the six figures across plugin-designs/ and library/ finds them only in explanatory comments, so no shipping code hardcodes a corpus total and only the baseline lagged. Mutation-tested — an off-by-8 baseline fails. Recorded that this is the third reading, that it drifts in both directions, and that it must NOT be widened into a range: the noise is the signal that the numbers on the page are live rather than asserted. check:verification-tags asks whether a human ever looked at a done card. 98 could not answer. 24 of those were mine, and they are now tagged agent/state — honestly agent rather than human, and state rather than visual, because every one was verified by measuring rendered DOM, PDF bytes and request tallies, never by a human looking at pixels. The other 74 belong to other agents and the Driver; guessing their provenance would defeat the gate, so it stays unwired. Six further gates were green and self-contained and are now wired: locale reachability, url resolution, manifest coverage, the palette registry, and the legend/source comparison. gates:post 37 -> 42; wave membership 43 -> 50 of 106. One I nearly wired wrong. check:dxlife passes standalone but exits 2 by documented contract — 0 unchanged, 1 drift, 2 clone not found — and the wave runner grades any non-zero as failure, so a checkout without the sibling clone would go red on a precondition. Caught in the fresh-checkout run, unwired, with the reason recorded on the script so the next census does not re-add it. "Can it run" and "is it wave-safe" are different questions. 42/42 with servers up; 31/42 passed and 7 SKIPPED on a fresh checkout, every skip named.	2026-09-24 15:53:58 +00:00
doxa-maps-88655c70	baf691e8cf	provider-switch gate: run by default, instead of only when someone types a URL ... check:provider-switch is a good gate — it counts requests BY HOST rather than reading window globals (which stay defined after a swap), and it allows exactly the api.mapbox.com URLs the generated leaf declares in its own head, so a half-fix at 18 requests cannot pass. It had a package.json entry and was in no wave, because it REQUIRED a URL argument and exited 2 without one. So it only ever ran when somebody typed a URL — the same present-but-never-executed shape check:packets-all had before it was given a fixture. Wiring it as-is would have turned every server-less build red rather than silently green, which is the less common half of that failure. It now defaults to the upg-100 leaf and SKIPs in the form the wave runner recognises, so the skip is counted and named instead of grading as a pass or an error. gates:post 36 -> 37, README re-synced. Verified both ways: 37/37 with a server, and 27/37 passed / 6 SKIPPED on a fresh checkout with none. Found while re-verifying BUG-UPG100-IGNORES-THE-PROVIDER-SWITCH from scratch rather than trusting its done status. The card holds: ?provider=maplibre drops Mapbox traffic 19 -> 5 on the upg-100 leaf, and all 5 are the page's own declared preloads, so zero runtime calls remain. The same run independently reproduced the four residual URLs in BUG-LEAF-PAGES-PRELOAD-MAPBOX-EVEN-UNDER- MAPLIBRE, which stays untaken — its fix is in generate-tree, the tree verb bundler-1 owns. When those preloads go, this gate's allowance drops to 0 and it holds the new floor with no edit.	2026-09-24 15:30:35 +00:00
doxa-maps-88655c70	7a649b6845	packet browser gate: verify the packet a reader actually exports ... The legend's Export > Prayer packet action is the path a reader clicks. The build-time file is the one nobody clicks. The reader's packet was the less verified of the two. check:packet-render gained six assertion families over recent ticks — the 12 prayer points, the wheel's 12 LABELS rather than just its 12 segments, page 1's geography, the print layer, the image census, the build stamp. Each was found by mutation and each catches a real "looks fine, is empty" shape. None existed here. It also printed "Mark 5 in full : undefined" beside a PASS for as long as it has existed: the measurement is r.mark5Len and the print read r.mark5, which is not a key on r. The assertion always read the right key, so the requirement was protected — but undefined next to a PASS reads as a gate that does not know what it is doing. That is the inverse of this tree's usual failure, where a number is printed and never asserted on. A mistake caught before it became a false report. The new geography assertion went red immediately with "no map svg on page 1", which would have read as a serious product defect. It was the harness: this gate called buildPacket with an EMPTY mapSvg, while the real export path fetches posters/<zone>.html and lifts its <svg>. The shortcut was not just skipping an assertion — it meant the gate never exercised mapCss() in a browser at all, which is the one thing it exists to prove. It now fetches the map the way the product does and reports 13 geography paths, the same number check:packet-render gives for laos. ISO3 and ZONE are also different strings ("lao" vs "laos.html"), so even a naive fetch would have missed; PACKET_ZONE names it. Mutation-tested: blanking the wheel labels gives 0/12 labelled and fails; hiding content at print time gives 0 embedded fonts and fails. i18n verified on the browser path for the first time. A partial locale with 3 of 12 points renders 12/12 points — the per-key merge holds here too — with the points heading translated, the wheel heading falling back to English, Mark 5 at 2220 chars, and nothing blank. Also made wave-safe: without a server it threw an unhandled navigation error and dumped a stack trace, which is why it could never join a wave. It now SKIPs cleanly naming its precondition. gates:post 35 -> 36, README re-synced. Verified both ways — 36/36 with a server, and "0/1 passed, 1 SKIPPED" without one, which is visible only because of the runner change in the previous commit.	2026-09-24 14:59:25 +00:00
doxa-maps-88655c70	a361da0a2e	gate wave: a SKIP is not a pass, and this printed them identically ... run-parallel grades on the exit code, and a gate that declines to evaluate exits 0. So "35/35 passed" read the same whether 35 gates graded something or 31 did, and the summary line — the one people quote — was the most misleading part of the output. This is the generalisation of the packet-sweep fix two commits ago. That closed ONE always-skipping gate; the reason nobody could see it for months was that the runner reported it green. 18 of the 35 steps in gates:post CAN skip, every one on a precondition a fresh checkout does not have, so the gap is structural rather than specific to packets. Measured on a genuinely fresh checkout — `git archive HEAD | tar -x`, which is what CI sees. Before: "31/35 passed". After: "28/35 passed, 4 SKIPPED", naming check:packets-all, check:zone-census, check:done-evidence, check:backlog-status. All four are legitimate, and I checked rather than assumed. packets-all skips until packet:ci runs, which CI does first. zone-census needs generated posters. The two backlog gates read _qa-cycle, which lives outside any repo by the deliberate decision that PM markdown never sits inside a code repo — and both already say so in their own output. So the finding is the REPORTING, not a broken gate. Exit semantics are deliberately unchanged, and verified: a wave whose only step skips still exits 0. Failing on a SKIP would fail every CI build on the backlog gates and teach people to disable the reporting. The detector is mutation-tested against seven real output shapes. It matches "ZONE-CENSUS: SKIP — …" and the indented variant, and correctly does not match prose mentioning skip, nor "SHARE-POLICY: PASS — 12 buttons, 0 skipped". A correction to my own method along the way: I first censused skips in doxa-maps-plugin-studio as a proxy for a fresh checkout. It is not one — it sits many commits behind main with a 21-step gates:post that lacks 14 of the steps main has, so the two censuses were of different waves. The fresh-archive test replaced it. Also documents check:zone-census's precondition, the one conditional gate in the wave that had none — including why it cannot be fixtured the way packets-all was: it asserts coverage of real generated output, so a fixture would only assert that the fixture is complete.	2026-09-24 14:50:05 +00:00
doxa-maps-88655c70	3c17245c73	packets: give CI something to check, instead of a sweep that always SKIPs ... check:packets-all is in gates:post. CI runs it on every build. It has SKIPped every single time, because library/scripts/posters/out/ is gitignored — both the records cache and every generated packet — so a clean checkout has none. Every packet assertion in this tree has therefore never once been evaluated there: the 12 prayer points, the wheel's 12 labels, page 1's geography paths, the print layer, the build stamp. Several ticks of work accumulating on a gate that had only ever graded files in my own working tree. A SKIP that is always taken is indistinguishable from an unwired gate — and the wave-membership census cannot tell them apart, because membership measures invocation, not evaluation. That census is how check:packets-all was created in the first place, which makes this the same class recurring one level up. I raised this at the end of the last tick and deferred it on the premise that closing it "adds a live-API call to every build". The premise was wrong. packet.mjs already had an OFFLINE mode, and a fixture needs no network at all. The fixture is the smallest zone — Tibet, 43 slugs, 20KB — with image_url stripped so CI can never fetch 43 photos from someone else's CDN. It is DERIVED, not hand-maintained: membership comes from the committed clusters.json, so check:packet-fixture regenerates and content-compares it. Re-adding an image_url fails; dropping a record fails naming the slug. A fixture packet stamps itself "fixture", and "fixture nomap" in CI, which has no poster sources either. `fixture` implies nophotos in the gate — without that it reported "every source record carries an image_url", a true sentence about real records and a false one about this packet. A real bug in my own change, caught only by running the script through its REAL invocation path: packet.mjs fails closed on a missing VITE_API_BASE_URL BEFORE loadRecords() ever looks at PACKET_RECORDS, so `bun run packet:ci` exited 1 on a tree that had everything it needed. Every hand-test had passed because I was supplying a dummy host. The guard now exempts fixture builds and still fails closed otherwise. From a genuinely clean state — the whole out/ directory moved away — the sweep now reports "1 packet(s) checked, 1 passed". i18n verified through that same path: a partial block (1 string, 5/12 points, 3/12 rhythms) renders 12 points, 12/12 wheel labels, wheel 3 translated and 9 English, 0 blanks. check:packet-fixture joins gates:post (34 -> 35), README quote re-synced in the same commit. Wave 35/35, packets-all 11/11 here and 2/2 in the studio.	2026-09-24 14:33:36 +00:00
doxa-maps-88655c70	4eec165a2b	Merge remote-tracking branch 'origin/main' into shepherd/merge-b3	2026-09-24 14:24:48 +00:00
doxa-maps-88655c70	64fed43449	packet: stamp how a packet was built, into the packet ... out/packets/ is gitignored, so check:packets-all grades whatever .html files happen to be sitting there — an accidental set, not a current one. On this machine that was 11 freshly generated packets. In doxa-maps-plugin-studio, which shares main with this worktree, it was two NOPHOTOS=1 layout probes of mine from earlier ticks, and the sweep was RED there for anyone who ran the wave. The gate was honest about each file it checked; the set it checked was accidental. The underlying problem is that a fast layout-iteration build and a shippable one were byte-indistinguishable. The packet carried lang and dir and nothing about its own provenance, so the only way to tell them apart was for the person running the gate to remember and pass PACKET_EXPECT_PHOTOS=0. packet.mjs now stamps data-packet-build with the flags it generated under, and the gate reads it. The GENERATOR writes it rather than the gate inferring it: had the gate guessed "no photos present, so probably a probe", it would have excused genuine photo-fetch failures. Tested explicitly — a packet stamped "full" whose map svg is then stripped STILL FAILS. The stamp records intent and cannot excuse a defect the build did not declare. Deliberately not a timestamp. An mtime staleness rule was considered and rejected on evidence from this same session: packet-strings.json was 303s newer than the packets while byte-identical to HEAD, because a probe had restored it from backup, so an mtime rule would have failed a correct tree — the exact mistake fixed two commits ago in the library-index gate. Content comparison is not available here (regenerating hits a live API and takes minutes), so the build records its intent instead of the clock. The studio sweep goes from "2 checked, 0 passed" to "1 checked, 1 passed", with the packet self-declaring build="nophotos nomap". Env vars stay as an override for pre-stamp artefacts, and the declared-deliberate note now names whichever source actually declared it rather than always crediting the env var. All 11 locales stamp "full". i18n re-verified with a partial block (1 string, 3/12 points, 6/12 rhythms): wheel 6 translated and 6 English, 12 point rows with 6 translated, 0 blanks. Wave 34/34, packets-all 11/11 here and 1/1 in the studio.	2026-09-24 14:21:45 +00:00
doxa-maps-88655c70	445131cf94	Merge main into bundler-3/work — settle the 21-file conflict, keep both campaigns ... Only 2 files conflicted in source: package.json and its CLI doc, both taken to main's refactored gate pipeline (gates:pre/gates:post/build:bundles) after verifying every check the old inline chain named still runs there. The other 19 were generated: public/assets/tables mirrors keep main's deliberate deletion, and public/doxa-maps is regenerated by the build that follows.	2026-09-24 14:16:47 +00:00
doxa-maps-88655c70	588d0da48a	packet gate: look inside the PDF it was already making ... check-packet-render has called page.pdf() for a long time and then read only MediaBox and /Type /Page. Eight blank sheets of the right size would have passed every assertion in it. That matters because the packet exists to be PRINTED — it is a standalone file with photos and fonts inlined precisely so it prints offline — and until now every check was on-screen. A print-only CSS rule can strip content that the on-screen checks still see. The first mutation is the argument for the whole change. Adding `@media print{.card img{display:none}}` left the on-screen line reading "95 photos, 0 typographic" — every pre-existing check green — while the PDF carried 2 images instead of 85. The second, hiding sheet contents in print, fires all three new assertions at once on a packet that is still 8 correctly sized pages. Images are compared against DISTINCT srcs, not cards. A PDF de-duplicates identical images, and laos has 95 cards and 95 <img> but only 85 distinct sources, because ten groups share a portrait — a fact about the upstream photo set, not a rendering fault. Comparing against 95 would have reported "8 photos dropped at print time" on a correct packet. I nearly did exactly that. A scare investigated and cleared rather than reported: the PDF names only DejaVuSerif, which looked like the vendored Devanagari face failing to reach print. It is not. Under print media emulation the stack still resolves to "Noto Serif Devanagari", and the same string measures 210px in it against 420px in plain serif, so the face is genuinely in use and the PDF names are Chromium subset aliases. Corroborated independently: hi is the largest packet at 3.2MB with the fewest faces at 7, which is one big vendored face, not a fallback. A ToUnicode-based check was discarded after calibration found only 30 Latin codepoints in a known-good English PDF — an incomplete parser whose zero-Devanagari result proved nothing. All 11 locales embed fonts and carry every photo. i18n re-verified through the new assertions with a partial block (2 strings, 4/12 points, 5/12 rhythms): 2.8MB, 11 fonts, 87 images, wheel 5 translated and 7 English, 12 point rows, 0 blanks. The studio's declared map-less photo-less packet still passes — the image assertion skips at 0 distinct sources, so the opt-outs compose. Wave 34/34.	2026-09-24 14:10:59 +00:00
doxa-maps-88655c70	e0fd61eb3e	Gospel presentations in 94 languages, from Cru's API rather than its parked domain ... Every pool here so far is Scripture, film, Bible video or a course. None is a GOSPEL PRESENTATION — the short translated thing a person actually opens with someone. Cru publishes those, in the same organisation that makes the JESUS Film, so the doctrine question is settled the same way the brief settles it for the film. Only their gospel tracts are included, from a fixed allow-list; the lessons and survey tools are not. IT CLOSES NO GAP AND SAYS SO. All 94 of these languages already have something, so this is depth rather than coverage and moves no tier. Tiers are byte-identical at 2901/4767/4711. It reaches 3,270 pins and 3.97bn people. godtools.org, the obvious host, IS A PARKED DOMAIN. It answers 200 to everything with a 114-byte body, and rendered, every URL — including /zz/nosuchtool-xyzzy — reads "godtools.org is parked free, courtesy of GoDaddy.com". Shipping links there would have sent people to a GoDaddy ad. The real front-end is knowgod.com, and it does serve per-language tracts: /en/kgp reads "Knowing God Personally", /sw/kgp reads "Kumjua Mungu Kibinafsi". But ONLY once rendered. By fetch it is a uniform 3,864-byte shell for every URL valid or not — the third host in this bundle with that shape, after jesusfilm's old ?languageId= and live.bible.is. So existence is proved from Cru's own API and never from the page: a (language, tool) pair exists exactly when the resource's latest-translations intersect that language's translations. Checked against the browser before being trusted — en/kgp and sw/kgp both intersect and both render real localised text, and the bogus pair does not intersect. In band, the verifier's controls are now 7 negative all non-verified and 7 positive all verified, with a bogus knowgod pair among the negatives. All 94 URLs verified. Clause I keeps its closed set: Gospel presentation only on knowgod.com, and knowgod.com only that type. Poison self-test still 12/12. Screenshot read: German shows six distinct resource types, including "Gospel presentation - Knowing God Personally".	2026-09-24 13:51:56 +00:00
doxa-maps-88655c70	d561e35d33	packet gate: a map one-pager with no map on it is not a map one-pager ... Deleting the map svg from page 1 entirely left this gate reporting "map: palette resolves, not black — PASS, map painted". mapFaults queried `document.querySelector('.sheet svg')` — the first svg ANYWHERE in the document. With page 1 empty the query silently retargeted to the PRAYER WHEEL's svg two sheets later, and the wheel has no CSS variables to leave unresolved and no black fills, so both checks passed vacuously. The sheet count stayed 8 because the empty sheet still exists. A fallback selector turns an absence into a pass: when the thing being asserted about disappears, the query finds a different object that happens to satisfy the checks — and here the gate printed a stronger claim than it had evidence for. "page 1 = map one-pager" is the first line of the packet spec. Now scoped to sheet 0, which the page order fixes as the map page. And it asserts the map paints GEOGRAPHY, because palette-resolves and not-black are both properties a map with zero country shapes satisfies perfectly. Geography is paths whose `d` exceeds 200 chars — a coastline, not an icon. The floor of 5 is set from a measured spread rather than guessed: laos 13, brazil 18, middle-east-core 55, tibet 69, uncovered-scatter 74, varying with how many countries a zone spans. Mutation-tested in three shapes: no svg fails naming page 1; an svg present but drawing nothing fails at "only 0 geography path(s)"; the good packet passes at 13. All 11 locales report 13 — the map is data, not text. Syncing the gate surfaced a second thing. doxa-maps-plugin-studio ships 0 poster html files against wt-packet's 28, and packet.mjs deliberately "still builds (cover page without the map) rather than failing" when out/posters/<zone>.html is absent. That soft-fail is intentional but it was invisible: the degraded packet has 8 sheets, an <svg> present (the wheel's), and no marker at all, so it is structurally indistinguishable from a good one while page 1 promises a map and delivers an empty sheet. PACKET_EXPECT_MAP=0 follows the PACKET_EXPECT_PHOTOS precedent — fail by default with the remedy named, pass when the degradation is declared. Also fixed the summary line, which read "map painted" unconditionally and so described a declared map-less packet as having a painted map. It now reads "NO map (declared)". The summary is the part a reader quotes. i18n verified with a 2-key partial block: page 1 renders the translated keys, falls back to English elsewhere, 0 blank runs. Wave 34/34, packets-all 11/11.	2026-09-24 13:45:39 +00:00
doxa-maps-88655c70	6c60af555f	library-index gate: ask whether the menu drifted, not whether a file is older ... `touch library/components/legends/SemanticTreeLegend.vue` — zero content change, nothing in git status — turned this gate red. So did a git checkout, a rebase, and any editor that rewrites a file on save. It cried wolf twice in one build session while the regenerated doc was byte-identical both times, and the only available response was to run the generator and commit nothing. An mtime answers a different question than the gate's own name asks. This is the SECOND time this exact class was fixed here. The first was a SCOPE error: the gate walked 2.3x more of library/ than the generator reads, so a comment in a build script turned it red and named that script as the reason the component MENU was stale. Narrowing the scope fixed that instance, but the mechanism was still mtime, so the class survived inside the narrowed scope. The lesson recorded then applied again word for word — a gate that fails for a change it can prove is irrelevant teaches the reader to regenerate on reflex, which is how a staleness check stops being read. It now regenerates into a throwaway tree and diffs the bytes. generate-library-index.mjs hardcodes its output path and derives ROOT from its own location, so it cannot be told to write elsewhere — but copying the SCRIPT into a temp tree whose library/ is a SYMLINK to the real one relocates its ROOT without modifying it. The generator runs unmodified against real sources, writes somewhere disposable, and an interrupted run leaves nothing behind. Verified byte-identical to a real `bun run library-index` before this was written, and the generator was confirmed deterministic first — a content diff would be useless otherwise. Comparing output also makes the scope self-enforcing: a change outside components/, composables/ and utils/ cannot alter one byte of the menu, so the INDEXED_DIRS list the mtime walk needed is gone. Mutation-tested both ways, because a gate that never fires is worse than a noisy one. Deleting a catalogued row fails with the line number and expected content. Adding a real new library component fails — that is the drift this exists to catch. Touching 40 library files, the rebase case, passes. Wave 34/34. Swept the five other internal/*.mjs that reference mtime: only check-shot-freshness also decides on one, and there it is correct — a PNG cannot be cheaply regenerated and diffed, and a rebuilt bundle is meaningfully newer. Left alone deliberately.	2026-09-24 13:29:58 +00:00
doxa-maps-88655c70	53fea6ee38	packet gate: a prayer wheel with no words on it is not a prayer wheel ... Blanking every wheel segment label and regenerating left check:packet-render reporting "12 segments, 11/11 rhythms, content intact — PASS" on a wheel that was a twelve-colour pie chart. Both printed numbers stayed true, which is why nothing caught it. The twelve segments are <path> elements and survive their labels being removed. And the rhythm assertion searched document.body.innerText, where the SAME twelve rhythm words are rendered TWICE in every packet — once per wheel segment, once as a prayer-point heading. So "every rhythm word appears in the document" was satisfied by the points page alone and said nothing about the wheel. That is the self-consistency-vs-completeness family again, with a new twist: when two surfaces share one vocabulary, a document-wide string search cannot attribute a hit to the surface being asserted. The fix is scoping the query to the surface, not a better word list. wheelLabels counts the non-numeric <text> runs inside the .wheel-title sheet's own svg, excluding the twelve "5" pips and the "5 minutes x 12" footer. It counts ELEMENTS, NOT DISTINCT WORDS, deliberately: `praise` and `praise_end` collapse to one word in English — which is exactly why the existing line reads 11/11 and not 12/12 — and that collision is locale-dependent, so a distinct-word count would be a different number per language. The Driver's spec names the wheel as one of the packet's four sections, so 12 labels is a contract. Mutated packet reports 0/12 and fails; restored reports 12/12. i18n verified at the rendered layer with a partial locale block (4 of 12 rhythms translated): the wheel painted four XX- labels with the other eight falling back to English and zero blank — and the split pair is visible, segment 1 English PRAISE beside segment 12 XX-PRAISE_END, which is what per-key resolution looks like. All 11 locales regenerated with 95 photos each: check:packets-all 11/11, every one 12/12 labelled, including RTL ar and Devanagari hi. Wave 34/34.	2026-09-24 13:23:57 +00:00
doxa-maps-88655c70	a177f98aff	legend: the controls no longer read their own i18n key aloud ... The legend's toggle button announced the literal string "aria.toggleLegend" to screen readers. Not in translated locales only — in English too. vue-i18n echoes the key when a lookup misses, and `toggleLegend` was absent from every catalog while its two siblings in the same file, backToLegend and closeDetailView, were present. Six call sites across LegendDesktop.vue and LegendMobile.vue, desktop and mobile alike. aria-label is the one string a sighted tester never sees. Every other untranslated string in this tree got caught because somebody looked at the screen; this one is only ever spoken aloud, so it survived every visual QA pass. A second instance turned up in the same sweep with the opposite shape: SemanticTreeLegend hardcoded 'Collapse legend' / 'Expand legend' into both title and aria-label with no t() at all — correct English, and untranslatable. One key missing FROM the catalog, one string never routed TO it. Adds toggleLegend, collapseLegend and expandLegend to all 11 aria.json catalogs and routes the hardcoded pair through t(). check:i18n-parity already guards them. New gate smoke:aria-labels asserts BOTH shapes, because either assertion alone is insufficient: "no raw keys" passes a hardcoded English label forever, and "labels differ across locales" passes a raw key, since a key is identical in every locale. It detects a raw key by SHAPE — dotted, camelCase, no spaces — which is locale-independent and works on the Arabic and Chinese pages where no English word list could. Mutation-tested twice. Removing the catalog key fails with the raw key named, on all four viewport/locale combinations. Hardcoding one label back to English initially PASSED: the differ count dropped 6 to 5 and nothing asserted on it — the same "a number printed but not asserted on is decoration" shape this tree keeps rediscovering — so the gate gained a LOCALIZED_FLOOR ratchet and now fails that too. Verified the fix generalizes beyond the profile it was found on: country-posters reports 182 of 190 accessible names localized, 0 raw keys. Rebuilds the six bundles that embed a legend; check:sri confirms every leaf matches. Wave 34/34.	2026-09-24 13:16:18 +00:00
doxa-maps-88655c70	fb7ed4566d	Browser gates now prove the server is serving THIS checkout ... The gospel-resources gate was found adopting whatever answered on the default port, which on this machine was an unrelated process from a different worktree. It reported on a build that was not the one on disk: first a PASS, then a mount timeout that read exactly like a regression in code nobody had touched. "Answers 200" and "is serving this checkout" are different questions, and only the second one is the gate's job. That fix was local to one gate. The same default sits under the rest of them, so it is now one shared helper, internal/_serves-this-tree.mjs, fingerprinting public/doxa-maps/manifest.json — which generate-tree rewrites on every build and which names every bundle and profile in the tree. Different bytes means a different build: another worktree, or a server someone forgot to restart. Both produce the same lie. Wired into verify-browser-all, which hands ten gates their base URL and would have passed the wrong tree to all of them, and into check-a11y-button-names. Both now refuse with a NOT MEASURED exit rather than producing a confident wrong answer. The gospel gate keeps its behaviour of starting its own server instead. Verified in both directions: against the foreign 4173 each prints "serves a DIFFERENT build than public/" and exits 2; against this tree the aggregator proceeds to its ten gates and the gospel gate passes. ONE REPORTED NUMBER WAS WRONG BECAUSE OF THIS. The a11y result recorded earlier in this flight, "810 buttons, 810 with an accessible name", was measured against the foreign tree. Re-run against this checkout it is 825 buttons, 825 with an accessible name, still passing across 21 leaf pages. The conclusion held; the evidence had not been about this build. Audited the rest of this flight's browser evidence rather than assuming: the 41 probe scripts in _qa-cycle all target port 5399, which is served by serve-strict --directory <this worktree>/public, and the manifest served there is byte-identical to the local one. Those results stand.	2026-09-24 12:54:35 +00:00
doxa-maps-88655c70	6af75895c7	legend: the info popovers explain the map in the reader's own language ... The Driver asked for the per-tab info buttons to stay — "the tab itself gives you a little information button that will explain what a UPG-100 list is." They existed, and they were English-only in every locale. SemanticTreeLegend rendered `tab.info` RAW in all three places it appears (the button's title=, and the popover body) while the tab LABEL beside it went through the catalog. So a Spanish reader saw a translated chip next to an English explanation of what that chip means — and the explanation is the part a reader who does not read English actually needs. The three UPG-100 tab labels were absent from tabs.json entirely, so they fell back to hardcoded English too. Measured on the served leaf before changing anything: ?lang=es changed 2 of 76 rendered strings ("POPULATION" -> "POBLACIÓN") and left all three tabs and all three info popovers in English. That positive control is what proves the locale switch WORKS and the strings were simply never catalogued — without it this reads identically to a broken ?lang=. tabInfo() mirrors tabLabel exactly: `legend.tabInfo.<i18nKey|id>`, te() guard, falling back to the hardcoded English so a tab with no catalog entry renders unchanged rather than blank. The v-if stays keyed on the raw `tab.info`: whether the affordance EXISTS is a property of the tab definition, while its TEXT comes from the catalog. Catalogued in all 11 locales, labels and info. check:i18n-parity already guards them — deleting one zh key fails the build by name. New gate smoke:legend-info renders the REAL served page and clicks each info button. check:tabs-localized could not see any of this: it tests 7 hardcoded research-map tabs and REIMPLEMENTS tabLabel inside page.evaluate, so it proves the mechanism works rather than that a given profile is localized — and it never looked at `info` at all. Mutation-tested: reverting the popover to the raw prop fails with "the catalog is present and unreached". Partial-translation contract verified by deleting 2 of 3 fr info keys and 1 of 3 fr labels: translated keys render French, untranslated fall back to English, nothing blank, and labels and info resolve INDEPENDENTLY. Rebuilds the six bundles that embed the legend so the tree stays internally consistent; check:sri confirms all 55 script references match. Full wave 34/34.	2026-09-24 12:49:04 +00:00
doxa-maps-88655c70	77ac7e3436	The two largest gaps on this map were Chinese varieties of a resourced language ... Read top-down, the gap list sent you to "Chinese, Jinyu - 60,310,000 people - nothing found", then "Chinese, Gan - 41,280,000". Both statements are true about those ISO codes and both are misleading as priorities: ISO 639-3 files them under the macrolanguage zho beside cmn, Mandarin, which has Scripture, film, audio and training here. Measured across the whole map: 84 pins covering 140M people sit at "nothing found" while a sibling variety of their own ISO macrolanguage carries resources. Those groups now carry a related-variety note, on the pin sheet and inline in the ranked list, because the list is the thing that gets read top-down. 63 codes have one. WHAT IT DOES NOT SAY. It is not a claim of mutual intelligibility, and the wording refuses to imply one - spoken Jinyu and spoken Mandarin are not mutually intelligible; what they share is a written standard. Only ISO's own relation is asserted, the reader is told exactly that, and it changes NO tier and closes NO gap. Tiers are byte-identical at 2901/4767/4711. The chips still read "none found", because that is still true. The macrolanguage table is fetched from SIL rather than transcribed, and written through the snapshot guard like every other catalogue. Also corrected: the gap list header still said "Audio has never been searched for any of them". That stopped being true when Faith Comes By Hearing was added, and a stale caveat misleads exactly as much as a stale number. It now says audio HAS been searched and these groups have none there either, with GRN still named as the one pool nobody can look in. And a gate defect that produced three runs of false signal. verify-gospel-map adopted any server answering 200 on the default port. Port 4173 turned out to be held by an unrelated python3 process from another worktree, so the gate reported on a build that was not this one - first a PASS, then a mount timeout that looked exactly like a regression in code that had nothing to do with it. Answering 200 is not the same question as serving this tree. It now fingerprints the served bundle against the bytes in public/ and refuses to adopt a server whose build differs, starting its own instead. Proven: it now prints "serves a DIFFERENT build than public/ - not adopting it", starts its own, and passes. Screenshot read: the ranked list shows "related: Chinese, Mandarin has resources" under Jinyu, Gan and Min Bei, and correctly nothing under Deaf Chinese or Deaf Pakistani, which have no macrolanguage sibling.	2026-09-24 12:44:24 +00:00
doxa-maps-88655c70	f129294609	Clause L: a verification record that stops being re-run now fails the gate ... Eleven clauses checked that the surfaces AGREE with each other. None checked that any of it was still true. "Link checked" is a claim about the present tense, and a table that quietly stops being re-run keeps making that claim on evidence that could be a year old while every consistency clause still passes. A dead link is the failure a field worker actually hits, so this is not bookkeeping. Clause L fails when a shipped URL carries no check date at all, or when the oldest shipped link was last checked more than 45 days ago, and the message names the exact command to fix it. Re-running is cheap and resumable now, so the failure is an instruction rather than an obstacle. Proven against real data, not only the poison harness: deleting the check date from one shipped URL is caught ("1 shipped URL(s) carry no check date"), and backdating one by 120 days is caught ("last checked 120 days ago, past the 45-day limit"). Both restore clean. Poison self-test now 12/12. Also checked and deliberately NOT changed: the Arclight harvest keeps a language only when counts.featureFilm >= 1, and it was worth asking whether that discards coverage. Of 2,330 catalogue languages, 2,309 already have a feature film. Only 15 carry just a shortFilm or a series, and exactly one of those - nmg Kwasio, 2 pins, 60k people - is spoken by a group here with nothing else. Widening the filter would mean typing a short film as "Film" beside the JESUS Film for a single language. The filter stays. The registered description still claimed "6/6 clauses must fail"; corrected to 12.	2026-09-24 12:31:36 +00:00
doxa-maps-88655c70	e8ad1d56e6	packet: a partial translation renders 12 prayer points, not 3 ... packet-render.js resolved the prayer points with `L.points || EN.points`. That is a whole-block fallback when the key is ABSENT, and TRUNCATING when a translator has done some of the 12 — a 3-element array is truthy. Measured at the rendered layer with a deliberately partial locale block: a page headed "12 Prayer Points" containing THREE, points 4..12 silently gone, including the Mark 5:1-20 passage point 4 prints in full. Nothing blank, no error raised. Invisible in all 11 shipping locales because every one of them is complete. It would have appeared on the next language added — and "a new language is a NEW BLOCK, never a code change" only holds if a PARTIAL block degrades per key, since half-finished is the normal state of a language in progress. Now merges per point and per field against English: English fixes the LENGTH and supplies every missing field, so a point translated for `text` but not `sub` keeps the English `sub` — and keeps its NUMBER, which the merge supplies. The sheet-sum invariant could not see this: a 3-point page is still exactly one sheet, so every number check-packet-render printed stayed correct while nine points were missing. It now measures and asserts the count. Mutation-tested — reverting the fix prints "prayer points : 2 / 12" and fails. All 11 locales regenerated with photos and swept: check:packets-all 11/11, each 12/12 points, including RTL ar and Devanagari hi. Renderer, generator and gate synced to doxa-maps-plugin-studio, which also lacked the .points-title and .wheel-title test hooks the new assertion needs. Also wires check:capability-exemplars into gates:post (33 -> 34 steps). It reads public/doxa-maps/manifest.json, a build artifact, so ordering mattered: `tree` writes the manifest and is &&-chained immediately before gates:post, and the gate SKIPs rather than fails when the manifest is absent. Full wave: 34/34. The quoted gates:post line in the README is re-synced in the same commit, because check:quoted-scripts goes red on the drift this commit creates.	2026-09-24 12:20:38 +00:00
doxa-maps-88655c70	0e0b142719	A half-finished catalogue fetch can no longer overwrite a good one ... The FCBH fetcher read per-fileset video scope for 1,666 languages and that file was committed. A later run, while live.bible.is was rate-limiting, produced 1,103 and overwrote the good file with the degraded one. Nothing failed, nothing warned, and the artefact silently lost a third of its content. It was caught only because git status happened to be read, and the fix was a git checkout. That is the third time this shape has appeared here: - a VERIFY_LIMIT smoke run replaced the full verification table with 30 rows; - dropping a dead link removed it from the corpus, so the next run forgot it was dead and the build put it straight back; - this one. Every snapshot in this bundle is built from a network read, and a network read has a bad day. The dangerous case is never the run that throws - that leaves the old file alone - it is the run that half-succeeds and writes anyway. scripts/_snapshot-guard.mjs now stands in front of every catalogue write. A snapshot may grow freely and may shrink a little, but losing more than a tenth of the previous run is treated as a failed fetch: the existing file is left untouched and the script exits 1. It is deliberately not an equality check, because catalogues do genuinely lose entries when a publisher retires something, and a gate nobody can satisfy gets switched off. SNAPSHOT_FORCE=1 is the one loud way past it. Proven by replaying the exact failure: feeding it the 1,103-entry version refuses the write, names the real numbers (563 fewer, 13.8%, below the 90% floor) and leaves the file byte-identical to the good one. SNAPSHOT_FORCE=1 writes it. An equal write passes. All six fetchers are wired: ebible, arclight, arclight-share-urls, door43, zume, fcbh. Re-running zume, door43 and ebible for real passes the guard at 52, 208 and 1,237 codes and produces byte-identical data, so the guard perturbs nothing. The one exception is the checkpoint write in the resumable share-urls fetcher, which starts from the existing file as a cache and can only grow. It must now declare itself with a CHECKPOINT-WRITE-OK marker, so the exemption is a statement rather than an oversight. New gate check:snapshot-guard fails if any fetch-*.mjs writes OUT directly without that marker, or never calls writeSnapshot at all - a guard that is easy to bypass is a guard that will be bypassed. It refuses to run against an empty file list rather than passing vacuously, and --poison injects a raw write and requires the check to catch it. Chained into build:unlocked and its doc copy kept in sync.	2026-09-24 11:59:48 +00:00
doxa-maps-88655c70	510f3d30d4	The backlog-status enum was too narrow, not the nine cards wrong ... This gate keeps the AGGREGATE honest — a prose status makes every open-count wrong while each card still READS correctly, so the error hides in the total. That matters to this loop directly: every tick starts by reading status counts to pick a card. MEASURED across 633 cards: EIGHT distinct status values are in use and EVERY ONE IS A SINGLE WORD. No prose remains anywhere in the field — which is exactly what the original 130-card migration achieved. The nine cards this gate was failing carried legitimate TERMINAL states the enum simply predated: superseded (5), deferred (2), decided, verified-already-true. ★ REWRITING THEM TO "done" WOULD HAVE DESTROYED REAL DISTINCTIONS to satisfy a list. A SUPERSEDED card was replaced by another; a DEFERRED one was consciously postponed; neither was finished. Losing that information to make a checker green is the opposite of what this gate is for. OPEN vs CLOSED is the property that matters, and all four additions are CLOSED: open = todo + doing + in-progress (66), closed = done + these four (507), blocked (60). MUTATION-TESTED BOTH WAYS, so widening did not weaken it: a prose status ("done — reconciled against main, see notes") still FAILS by name — the original defect — AND an unagreed one-word status ("wontfix") ALSO fails, so the set stays CLOSED rather than becoming "any single word". Wired into gates:post (32 -> 33) after confirming it reads only backlog JSON. The doc that quotes gates:post is re-transcribed in the same commit. Build: 7/7 pre, 23/23 bundles, 33/33 post, exit 0.	2026-09-24 11:58:39 +00:00
doxa-maps-88655c70	c4fbc469ac	Bible video from FCBH, with the real book scope on every link ... The previous change left video_date out because the column does not say what the video IS. Establishing it took measurement, and the first samples were misleading. Three video-only filesets all rendered ...S2DV pages opening on "Intro & Garden of Eden" with Drama/Non-Drama controls, which suggested one Old Testament series. Reading GET /api/bibles/<bible_id>, which returns the exact books array in one call, for all 1,669 video languages says otherwise: 209 27 parts, Matthew to Revelation (the whole New Testament) 116 27 parts, San Mateo to Apocalipsis (same, Spanish editions) 110 12 parts, Intro & Garden of Eden ... (Covenant, Old Testament) 27 Mark 26 Acts 23 Luke 1,006 distinct scopes in all Generalising from three samples would have described the bulk of it exactly backwards. Every link therefore ships its own scope rather than a shared description, and the 3 languages whose book list could not be read were dropped: an undescribed video is not shipped. It is typed "Bible video", never "Film". Film on this map means the JESUS Film, and bible.is itself treats the two as different - its pages call a separate Arclight endpoint, /api/arclight/jesus-film/languages?iso=..., to find it. So Bible video lifts a group off "nothing found", which is true, and contributes nothing to the Scripture+film tier. 1,666 languages carry it: 287 as their own link reaching 4,375 pins and 5.76bn people, and 1,379 merged into the Scripture link whose media list now reads "audio, text, video" instead of advertising half of what the page holds. Verification for bible.is switched from a body-size heuristic to their own API. The page answers 200 for any id, so the first version compared body sizes against a shell measured at run time. That was a heuristic on a number the site controls, and it stopped working when their WAF began answering HEAD with 403 and a 520-byte body for real and bogus alike. The run-time calibration caught exactly that and ABORTED rather than mark thousands of links verified - which is the whole reason it was measured and not hard-coded. The API needs no heuristic: /api/bibles/OKEBSN is 200, /api/bibles/ZZZZZZ is 404. It is a tenth of the weight, it describes the same fileset the page renders, and GET is used because HEAD is what the WAF blocks. Also fixed: a fetch with no timeout hung the fetcher for thirteen minutes with no output. A stall looks exactly like slow work, so every fetch in it now carries a timeout, and the scope lookups run with bounded concurrency and 403 backoff. 6,404 links screened, 6,557 verified, 74 broken and dropped, 5 uncheckable. Screenshot read: German shows "Bible video - 12 parts, Intro & Garden of Eden to After the Forty Years / End Credits" as its own chip, distinct from "Film - link checked".	2026-09-24 11:47:37 +00:00
doxa-maps-88655c70	28ce04f6ac	check:done-evidence knew one card schema and failed the best-evidenced cards on the board ... A done card with no record is the reporting failure this loop exists to avoid — so a gate that mis-identifies WHICH cards lack a record is worse than none: it teaches the next agent to pad the field the checker reads. ★ THE THREE FLAGGED CARDS WERE AMONG THE BEST-EVIDENCED THERE ARE. Each carried one_line, why, and a `verify` block naming the probe, its assertion count and its negative tests — "74 files match byte for byte, all three drift classes exit 1", "9 assertions, all pass", "two new assertions, both negative-tested". The gate looked only for `bluf` or `fields`. MEASURED across 443 done cards: 40 carry `verify`, 41 carry `one_line`, and ALL THREE flagged cards had one or both. `verify` is if anything the STRONGER signal — it names how the claim was checked, which is what evidence means here. Fixing the CARDS by adding a redundant bluf would have been gaming the check. Fixing the GATE to recognise the evidence already there is the honest repair. ★ THE BASELINE IS NOW EMPTY. All ten exemptions reported STALE — every one had since gained evidence — so the list exempted nothing while implying ten cards still owed a record. An EMPTY set is not an unset one: every done card must now carry evidence with NO exemptions, and the gate fails outright for a single card that does not. Keeping ten satisfied ids would mean the same today and quietly permit a regression the moment someone reused an entry. Same reasoning as emptying the i18n DEBT map. MUTATION-TESTED both directions: a done card with NOTHING in any of the four fields FAILS by name; the same card with ONLY a `verify` entry PASSES. Wired into gates:post (30 -> 31) after confirming it reads only backlog JSON, which the build does not mutate. The doc quotes gates:post, so it is re-transcribed in the same commit — the self-referential update noted last tick, handled in one pass this time. Build: 7/7 pre, 23/23 bundles, 31/31 post, exit 0.	2026-09-24 11:38:17 +00:00
doxa-maps-88655c70	659ca6e244	FCBH text as well as audio, and 207 text-only filesets stop claiming to be audio ... The FCBH integration used only audio_date. Their rows also carry text_date, and it is unambiguous - they publish Bible text on bible.is. 698 codes carry text where this map had no text Scripture at all, reaching 2,176 pins and 1.38bn people. Codes go 2,192 -> 2,400 and the gap falls 2,927 -> 2,908. ONE LINK PER LANGUAGE, NOT ONE PER MEDIUM. A bible.is fileset is a single page carrying whatever media it has, so two chips pointing at the same URL would be noise. The link now states what it carries: 1,465 codes audio+text, 677 audio only, 207 text only. That last number was a live falsehood. Because the builder never copied the media field across, all 2,349 bible.is rows were typed "Audio Scripture" - including 207 filesets with no recording at all. A group with text-only Scripture was being sent to look for a recording that does not exist. Both the chip and the table type now follow the media. Ranking is by media count, then AUDIO PRESENT, then recency. The middle term is not decoration: without it a newer text-only fileset outranks an audio-only one on date alone and the language silently loses its recording, which is the medium an oral-preference group actually needs. Measured while it was missing: 3 codes lost audio. video_date is deliberately left out. The column does not say what the video IS - a Luke film, a sign-language edition, something else - and counting it as "film" beside the JESUS Film would assert something nobody here has checked. 400 codes with no film today carry one, so it is worth establishing later, but not by guessing. Clause I now accepts BOTH Audio Scripture and Scripture on bible.is, because a fileset really can be either, while keeping the set closed and keeping Audio Scripture wrong on every other host. Proven by poisoning both directions: Film on bible.is and Audio Scripture on ebible.org are each caught. Poison self-test 11/11. Also verified, not assumed: the brief's requirement that a pin or country click filters the table. iso=deu shows 4 of 5,889, country=IND shows 502 of 5,889. It works; an earlier reading of mine that suggested otherwise was measuring the wrong thing. All 6,117 links screened and verified. Screenshot read: Ninigo (ssg) shows "Scripture, text - 2012 Wycliffe Bible Translators, Inc." where it would have claimed audio.	2026-09-24 11:26:10 +00:00
doxa-maps-88655c70	482e6d4ca0	Wire the seven gates that could run, and make wave membership visible ... MEASURED: 70 of 100 check/verify scripts were in package.json but in NEITHER gates:pre nor gates:post. I had fixed this same "present but unwired" failure three times for individual gates without ever asking how many others were in the state. ★ THE GATE THAT EXISTS TO CATCH THIS WAS ITSELF UNWIRED. check:no-orphan-gates asserts every gate-shaped file is REACHABLE — named in package.json or imported — and it passed, 87/87. But reachable and WIRED are different properties, and conflating them is exactly how 70 scripts sat outside every build. A script entry means a human CAN run it; wave membership means it RUNS. Tested each unwired gate standalone: 7 pass with no precondition and were simply never wired (now in gates:post, 22 -> 29 steps, +1.5s on a ~150s build); 6 FAIL on pre-existing documentation drift nobody sees — check:verification-tags alone lists 61+ untagged cards — which is its own project, and wiring a red gate only gets it disabled; the rest legitimately need a served tree, a device, a token or an argument. ★ ONE I WIRED WRONGLY, AND THE MISTAKE IS THE USEFUL PART. check:settled asserts the tree is QUIET — no builder running, no recent churn — so it fails inside a build BY DESIGN. It passed twice standalone, I wired it on that evidence, and the next authoritative build came back 29/30 with check:settled the only red. Running a gate twice while IDLE proves repeatability, not compatibility with running mid-build. The question for wave membership is not "does it pass" but "is its assertion compatible with a build in flight". Unwired, and the reasoning is recorded in check-no-orphan-gates so nobody re-adds it on the same evidence. check:no-orphan-gates now reports wave membership as a second, distinct question from reachability — "37/93 run in gates:pre or gates:post" — naming the first eight unwired so the debt is visible rather than silent. It REPORTS rather than fails, because most of the remaining 56 are correctly hand-run. Mutation-tested: removing check:zone-census from gates:post moves the count 37 -> 36. Build: 7/7 pre, 23/23 bundles, 29/29 post, exit 0.	2026-09-24 11:24:01 +00:00
doxa-maps-88655c70	a11e19a6b0	Audio Scripture in 2,121 languages: every pin used to say "not searched" ... Every pin on this map has read "Audio - not searched (GRN)" for its whole life, because Global Recordings Network sits behind Bunny Shield and answers 403 to everything, its own robots.txt included. Re-probed this tick: still 403. But GRN was never the only audio pool. Faith Comes By Hearing needed no key. Their 4.dbt.io API wants one and answers 422, which is where the earlier note stopped. Their own recordings-database page does not use that API - it is client-rendered and pulls a STATIC public file from their CDN, bible_recordings.json, 3,602 rows of { iso, lang_name, bible_name, bible_id, country, video_date, audio_date, text_date }, already keyed by ISO 639-3. 2,192 codes carry a dated audio recording; 2,121 survive verification. Audio lifts a group off tier 0, unlike Zume, because a people group with an audio Bible in their own language does not have "nothing" - for an oral-preference group it may be the most useful thing on the list. It does not create tier 2, which stays reserved for text Scripture together with film. Measured: 533 pins and 59.5M people leave the gap, which falls 3,460 -> 2,927. Coverage 72.0% -> 76.4%. 8,094 pins now carry audio. A 200 FROM live.bible.is PROVES NOTHING and this almost shipped wrong. It answers 200 for a fileset that does not exist, returning a fixed-size not-found shell, so the discriminator is BODY SIZE and HEAD gives content-length for free. The shell size is measured at run time, never hard-coded: it was 7,961 bytes on one path and 7,860 on another within the same hour. Both fetcher and verifier abort if a bogus id ever returns the same size as a known-good one. It caught 73 dead filesets in FCBH's own data, all dropped. The first full pass collected 466 HTTP 403s from bible.is - rate limiting, not dead links; the same URL answered 200 when retried alone. Requests are now paced per host and 403/429 retried with backoff, which cut those to 48, and a VERIFY_RETRY_UNKNOWN pass resolved all 48. Final: 5,882 verified, 73 broken, 5 uncheckable. Three bugs found and fixed on the way: - The dead-link drop ran BEFORE the audio merge, so 71 dead filesets attached after the cleanup and shipped anyway while the pass reported "dropped 0". A cleanup that runs before the thing it cleans is worse than none, because its count measures an empty room. Moved after every source attaches. - A VERIFY_LIMIT smoke run overwrote the real table, destroying the broken-link history the previous change added. A limit run is now a smoke test that writes nothing. - The browser gate screened 3,768 of 5,889 links because its harvest never learned the new field. Added VERIFY_MISSING=1 so adding one resource costs one request, not a quarter-hour pass over 5,960 URLs. Charts, list and map were corrected together: all three still asserted audio had never been searched, and charts deliberately drew it as a hatched "not measured" row. That bar is now a real count, decided by hasField() from the data itself. The checked-pools caveat on every group now names fcbh. Screenshot read: Uab Meto (aoz) - no Scripture, no film, no stories, not in Zume - now shows a verified audio link and the caveat lists fcbh as checked.	2026-09-24 11:16:30 +00:00
doxa-maps-88655c70	18db274d72	The packet gate asserts RTL LAYOUT, not just the dir attribute ... Arabic is one of the eleven locales, and RTL is the one layout property that can be declared correctly and still not take effect. The gate asserted document.documentElement.dir === 'rtl' — necessary, and not sufficient. Any inner rule can override it while every other assertion here stays green, and an Arabic packet with readable glyphs in LTR order reads as a styling quirk rather than the bug it is. It now samples up to 25 leaf text runs inside .sheet and measures the painted extent against the element box. An RTL packet must pin its runs to the RIGHT edge, an LTR one to the LEFT. The signal is unambiguous: en 0 right / 25 left, ar 25 right / 0 left. Threshold is 80% of sampled runs, so one legitimately mixed line cannot trip it. ★ MEASURE THE INLINE TEXT RUN, NOT THE BLOCK. My first probe compared each element's box to its parent's and returned IDENTICAL numbers for Arabic and English — it was measuring container geometry, which does not move when direction flips, and would have "passed" an RTL packet laid out LTR. A Range over the text node gives the painted extent, which does move. Centred text is skipped because it proves nothing either way, and so is text that fills its box — no room to tell. MUTATION-TESTED with the exact failure this guards: injected .sheet{direction:ltr} so dir="rtl" REMAINS DECLARED on <html> while the layout reverts. FAIL, both symptoms named — "only 0/25 sampled runs do (right 0, left 25) — dir=\"rtl\" is declared and not taking effect", and "25/25 sampled elements compute direction:ltr". All 11 locale packets pass with it live. Verified a NEW RTL LANGUAGE end to end: Urdu added as a DATA BLOCK ONLY — 2 of 21 keys, no code change — renders dir=rtl with 25/25 runs painted right, 95 photos, translated keys in Urdu, untranslated falling back to English, zero blank headings. The packet's i18n contract holding for a language that did not exist when the tick began.	2026-09-24 11:10:23 +00:00
doxa-maps-88655c70	96d7902a95	Sweep every browser gate for English-text matchers; fix the fifth and last ... The same defect had surfaced in FOUR gates across previous ticks — a gate keyed on English prose silently excludes every translated surface, or goes red on a correctly translated one. Finding a fifth by accident would mean the pattern was still being discovered rather than eliminated, so this sweeps all 25 gates that drive a browser instead of waiting for the next one. 9 flagged, 8 benign: CSS class names (.vtl-fab, .stl-panel) and CSS property VALUES (/paint|layout|strict|content/) are locale-independent by definition. ONE REAL HIT — check-poster-prints.mjs:131, `/Gadarenes/.test(...)`. That is the World English Bible's proper noun, so the assertion and the bug were locked together: it passes today ONLY because point4_passage is still English in all ten non-English blocks. The day a licensed translation lands it would have gone red on a CORRECT packet. Now asserts the .p4-passage block by length, the same structural fix already applied in check-packet-render and check-packet-browser. Proved on the case the old matcher got wrong: renaming Gadarenes -> gadarenos, as any translation would, now PASSES where /Gadarenes/ would have failed. MUTATION-TESTED both directions — a passage truncated to 180 chars FAILS ("looks truncated: 259 chars"), and the .p4-passage block renamed in the MARKUP FAILS ("no .p4-passage block"). ★ ONE MUTATION SILENTLY DID NOT LAND, and it is worth recording. My first attempt at the second mutation used a count=1 replace, which hit the explanatory COMMENT rather than the markup — "p4-passage" appears twice in packet-render.js. The gate "passed" and I nearly recorded a hole in the assertion. The assertion was sound; the mutation was not. The sweep made the same class of error in the other direction, flagging check-packet-render for a "Gadarenes" that lives only in a comment explaining why it was removed. Five instances found and fixed across five ticks; none remain in live code. The rule for any new gate: if it matches on user-visible text, resolve the expected string from the catalog for the page language, or assert on STRUCTURE — a class hook, a length — instead.	2026-09-24 11:00:29 +00:00
doxa-maps-88655c70	3519ca3934	check:packet-browser asserts its headings, and stops reading them in English ... This gate printed nine metrics, folded six into `const bad = a || b || ...` — so a failure said "FAIL" without naming which — and left three unchecked: page size and the two headings, which are the very strings its own header claims it covers ("the gate reports which headings came back translated"). Reports, not asserts. ★ IT LOOKED LIKE IT HAD FOUND A PRODUCT BUG, AND HAD NOT. Under ?lang=es it printed an EMPTY wheel heading; under hi it blanked BOTH — while the catalog holds "Rueda de Oración" and "प्रार्थना चक्र". That reads exactly like a broken i18n path, and it PASSED anyway, because nothing asserted the values. The cause was the harness. wheelTitle was innerText.match(/^.*Wheel.*$/m) and pointsTitle /Prayer Points|Puntos/ — neither can match Hindi, and /Wheel/ cannot match Spanish. The product was correct in every locale all along: verified after the fix in en/es/hi/ar/zh, RTL and Devanagari included. Had I reported that as a defect I would have been wrong. mark5 carried the same fault: innerText.includes('Gadarenes'), an English proper noun that goes RED the moment point4_passage is translated. Now asserted by .p4-passage length — the same fix already applied in check-packet-render. Headings are now compared to the CATALOG entry for the packet's language, with per-key fallback to English exactly as the renderer resolves it. packet-render.js gains class="points-title"/"wheel-title" as TEST HOOKS: both were inline-styled with no selector, which is what forced the English greps in the first place. MUTATION-TESTED: a renderer forced to ignore the language FAILS with both headings named and the expected values shown; a renderer emitting an empty heading FAILS ("a blank heading is worse than an English one"). ★ ONE MUTATION CORRECTLY PASSED, and it marks a real limit: reverting es wheel_title to English IN THE CATALOG passes, because rendered and expected then legitimately agree. This gate cannot tell a translated catalog from an untranslated one — that is check:packet-strings-parity's job, and it does assert it. Two gates, two questions. Partial translation re-verified through the BROWSER path: a 1-of-21-key Swahili block renders "Mambo 12 ya Maombi" with the wheel heading falling back to "Prayer Wheel" — translated where present, English where not, neither blank. That makes four gates with one root cause (tabs-localized, packet-render, deck-click, and this one twice). Any new gate matching on user-visible text should resolve it from the catalog.	2026-09-24 10:50:27 +00:00
doxa-maps-88655c70	53ae954a7f	The deck gate asserts its portraits, and can finally run in every locale ... Two gaps on the same surface. 1. "116 portraits" was collected, printed, and NEVER asserted — only the QR codes were checked against the card count, so a deck of 116 cards with ZERO portraits passed. A prayer card without a face is a data tile, which is the whole difference between the deck and a spreadsheet. Not hypothetical: card-render.js records that the deck once shipped with no photos at all, because image_url was never requested in fetchListRecords. THE COUNT CANNOT BE PINNED — roughly half the groups have no portrait and the CDN drops some — so two invariants instead: portraits + typographic === cards (a card that is NEITHER means a third shape nobody checks), and a deck drawn from records carrying image_url must have SOME, with DECK_EXPECT_PORTRAITS=0 to declare a deliberately photo-less deck out loud. 2. The gate matched /card deck/i, so it could ONLY run in English. Pointed at ?lang=es it reported "no Card Deck button" and listed 28 buttons all reading "Baraja de tarjetas" — the UI correctly translated, the GATE unable to see it. The card deck is a core prayer artefact and had zero coverage in any of the ten non-English locales, which is exactly where a rendering bug is most likely. The label now resolves from the catalog for the page's own locale. MUTATION-TESTED THROUGH THE REAL CAUSAL PATH, not synthetic DOM edits: - image_url removed from the records provider (the historical regression): FAIL, "116 cards and NOT ONE portrait", naming the cause. - the no-photo branch renamed so cards are NEITHER shape: FAIL, "116 cards but 0 portrait + 0 typographic = 0". - DECK_EXPECT_PORTRAITS=0 on that same deck: PASS, sum invariant still holding. - es cardDeck changed in the CATALOG without rebuilding: FAIL — so this now also catches catalog/bundle drift instead of passing on a stale bundle. VERIFIED IN FOUR LOCALES, each matching its OWN label — en "Card Deck", es "Baraja de tarjetas", ar "مجموعة البطاقات", hi "कार्ड सेट" — 116 cards, 116 portraits, 116 QR codes, @page 2.5in x 3.5in, 0 page errors in every one. Same two patterns have now recurred three times: a count printed without an assertion, and a gate keyed on English text that silently excludes every translated surface. Worth checking for on any new gate.	2026-09-24 10:38:03 +00:00
doxa-maps-88655c70	2bf4001d7e	Door43 spelled 32 major languages with two letters, so 2.87bn people saw none of it ... The Door43 fetcher kept only 3-letter codes and dropped 2-letter ones on the grounds that turning one into ISO 639-3 would be a guess. The caution was right and the conclusion was wrong: ISO 639-3 publishes the correspondence itself, in the Part1 column of iso-639-3.tab. The file is now fetched rather than transcribed, so it cannot go stale, and the run aborts if it comes back with fewer than 150 pairs. Measured cost of the old behaviour: 32 languages spoken by 2,576 pins - Bengali, Hindi, Spanish, Amharic, Hausa, English and more - carried Scripture and film but no Door43 resource at all, purely over a spelling. Door43 reach goes from 169 codes and 1,051 pins to 208 codes and 3,627 pins, 3.58bn people. Table rows 226 -> 391. ONE EXCLUSION, AND IT IS LOAD-BEARING: a tag with an '-x-' private-use subtag is skipped on this path. Door43 publishes el-x-koine, Koine Greek, whose base 'el' maps to 'ell' - Modern Greek, which 13 people groups on this map speak. Folding it in would have handed those 13 groups a Koine Greek text as though it were their own language. Region and script subtags (es-419, pt-br, sr-latn, ur-deva, zh-hant) are not private use and are the same language, so they still fold to the base. Verified: ell is absent from the index. Fixed a self-erasing bug in the previous change. Dropping a dead link removed it from the corpus, so the next verification run never saw it, so the next build put it back - measured, both links came straight back and REAL URL returned to 8,922. The verification table is now a RECORD, not a snapshot: it carries forward every URL a previous run proved broken and keeps re-testing them, which is also what lets a link the publisher later repairs come back on its own. Proven by dropping them and re-running: "re-testing 2 URL(s) a previous run recorded broken", still broken, build now stable across two full cycles. Clause K's 95% coverage floor is gone, because that floor is exactly how this hid: two missing URLs out of 3,768 is 99.9%. Every shipped URL must now appear in the record. Poison self-test 11/11. All 3,768 links re-verified: 3,761 live, 5 uncheckable, 2 broken and dropped. Also fixed the chip overflow this change caused - a Door43 entry can be "Aligned Bible (translationCore-Create-BCS) - Door43 - Portions of both Testaments", which ran off the edge of a 330px sheet unreadable. Long chips wrap now. Screenshot read: Hindi shows seven verified Door43 resources, all inside the panel, where it read "none found".	2026-09-24 10:27:16 +00:00
doxa-maps-88655c70	8f7a2f875d	Gate the default drop: with no poster and no source, nothing prints and the reader is told ... check:poster-print-fallback proves the GOOD path — no .webp, .html present, browser rasterises. On a tree with NEITHER it SKIPs. And neither is the DEFAULT, since posterSources and bundlePosters both default false, so the behaviour a reader is most likely to meet was the one behaviour nothing asserted. BUILD-POSTERS-GENERATE-ON-DEMAND-DROP-52MB claims in prose that export and print "degrade honestly, with the preview refusing to open rather than printing an error page". That claim was true and untested. Measured on a real dropped folder: the wall requests the .webp (404), then the .html fallback (404), then shows "poster not found (404)" with a Close button. 0 print frames, 0 downloads, 0 page errors. The failure this guards is NOT a 404. It is a print dialog that OPENS on a poster that does not exist — a blank sheet, or a low-resolution PREVIEW thumbnail printed as though it were the 3ft poster. Both look like the feature working. MUTATION-TESTED, two plausible wrong fixes, each caught distinctly: falling back to printing the preview ("1 print frame(s) opened with NO poster and NO source"), and failing silently by clearing exportState ("the reader was told nothing"). The gate also asserts BOTH paths were attempted, so a wall that gives up before trying to rasterise fails even while showing the right message. ★ SERVE THE TREE ROOT, NOT public/ — and this is in the gate's header because I got it wrong first. A leaf resolves assetsBase to '../../assets', which from <tree>/<bundle>/<profile>/ is <tree>/assets. Serving public/ puts public/assets on that path, a directory still holding 378 posters in a dev checkout, so the poster loads with a 200 and the gate tests the opposite of what it claims. The same click returned 200 under `--directory public` and 404 under `--directory public/doxa-maps`. My first reading of this was "a print frame opened on a missing poster", which would have been a serious product defect; it was the harness. Also audited check-packet-render this tick: all thirteen printed metrics now have assertions behind them. No decoration left on that surface.	2026-09-24 10:16:22 +00:00
doxa-maps-88655c70	101653e3fd	Verify all 3,603 links: 2 were dead, and the map showed "unchecked" on the rest ... The brief's rule is to verify a URL resolves before shipping it. The table that did that was written in August against a corpus of 426 links, while the map now ships 3,603 - and the UI matched exactly TWO of them. Two silent causes: its eBible keys were http:// while every shipped URL now passes through httpsify, and its 306 film keys were the old ?languageId= URLs that were later replaced wholesale by Arclight shareUrl deep links. Links that HAD been verified displayed as "unchecked", which a reader cannot tell apart from "nobody looked". The old note said the film page was unverifiable by fetch, and for the URL shape it was written against that was right: ?languageId=13562 and ?languageId=99999999 return byte-identical HTML, so a status check there is a false green. The shareUrl migration changed that. A path discriminates: /watch/jesus/german-standard -> 200, 944,516 bytes /watch/jesus/pashto-yusufzai -> 200, 810,741 bytes (distinct body) /watch/jesus/definitely-not-xyzzy -> 404 So 2,049 film links became checkable for the first time. The 5 remaining ?languageId= URLs stay "unknown" with that reason - never verified, never broken. Every host was probed with a known-good and a known-bad before being trusted, and all answer HEAD and discriminate: ebible.org, png.bible, alkitab.pw, jesusfilm.org, arc.gt, git.door43.org, zume.training. HEAD is deliberate - a GET over 2,049 film pages is ~1.6GB of someone else's bandwidth to learn a status code. Five negative and five positive controls run in band and the script aborts rather than write a table if either arm misbehaves. Result over 3,603 unique URLs in 365s: 3,596 verified, 5 unknown, and 2 genuinely dead - arc.gt/092vn (Yakpa, 2 pins) and /watch/jesus/4101 (Zhuang Liujiang, 1 pin), both re-confirmed 404 with a browser UA and a GET. The builder now drops any link verification proved dead BEFORE tiers are computed, so a code whose only film is a 404 has no film and its tier says so. The gap filter moves 3,457 -> 3,460, which is exactly those three pins. Also fixed: the verification fetch hung off openPin's country branch, so a tap landing before the country index had loaded left the whole session reading "unchecked". It is now fetched unconditionally. Lookup coverage goes from 2/3,605 to 3,603/3,603. New gate clause K fails below a 95% coverage floor or if any shipped URL is recorded broken; poison self-test now 11/11. Verified in a browser on the exact case that failed - one immediate pin tap - which now fetches the table and renders "Scripture - link checked" and "Film - link checked"; screenshot read to confirm both chips are green where they were grey.	2026-09-24 09:58:47 +00:00
doxa-maps-88655c70	e04509a94d	Pashto: 47.6M speakers were told Zume had nothing, while its Pashto site was live ... Last change joined Zume by exact ISO 639-3 and left pus unjoined, which turned into a false statement on the map: 13 people groups covering 47.6M speakers read "Discipleship training - not in Zume's 54" while https://zume.training/pus was live and in Pashto the whole time. Absence of a variety label is not absence of a resource. Research for something that selects a variety found nothing that does. The publisher's launch article scopes Pashto as Afghanistan's other official language and a major language of northwestern Pakistan, especially Khyber Pakhtunkhwa and parts of Balochistan - territory spanning all three of pbu, pbt and pst rather than selecting one. The locale pages declare no language metadata at all: no hreflang alternates, no BCP-47 tag, and og:locale is the site-wide en_US on every locale including this one. So it ships as an APPROXIMATE match rather than an exact join or a silence: its own field, its own dashed chip that reads "Zume, in Pashto (variety not stated)", its own scope text in the table, never counted as an exact join and unable to move a tier. The gap filter still cuts 12,379 features to 3,457. It is a curated three-code list, not a runtime name match - an approximate join a reader cannot see and a gate cannot check is the one that eventually ships a wrong link. Why this is defensible here and would not be for film: Zume in Pashto is a written course in one literary standard, where the pbu/pbt/pst split is largely spoken variety. The JESUS Film is already in this index under separate per-variety dubs (pashto-yusufzai, pashto-southern) because a dub differs by pronunciation. The medium decides. New gate clause J fails if any code carries both a confirmed and an approximate training link, or if an approximate entry lacks a url, language or note - that is the corruption that would make the qualified claim render as the confirmed one. Poison self-test now 10/10. Both gates also harvest the new field, so its URLs are screened rather than invisible; the browser gate screens 3,605. Verified in a browser with three controls: deu renders gm-chip ok with a real href, kri renders gm-chip meh with no href, pbu renders gm-chip approx linking https://zume.training/pus and carrying "variety not stated". Screenshot read: the dashed chip is visibly distinct from both.	2026-09-24 09:37:56 +00:00
doxa-maps-88655c70	2ed595c0f8	Zume Training: 52 languages of discipleship course, joined to 3,479 pins ... The brief names zume.training every tick and an earlier pass recorded the list as unobtainable. That was wrong. robots.txt Disallows /api/ and the homepage switcher is client-rendered, both true, but robots.txt also DECLARES a sitemap, and the publisher maintains /articles/zume-languages for exactly this purpose. Neither is behind a Disallow. The real figure is 62 locales, not the ~40 estimated: 54 serve a landing page that answers 200. The two sources disagree in both directions - Dari and Pashto ship sites but are missing from the article's table, and eight table rows serve no page yet - so fetch-zume-index.mjs takes the union and then fetches every landing URL. A locale ships a link only if its own page answered. Naming and linking stay separate facts. Pashto is deliberately left unjoined: pus is a macrolanguage, the people-group data carries pbu, pbt and pst, and nothing the publisher gives selects one. Training is not Scripture and not film, so it sits in its own field and its own type and moves NO tier. Measured: the 52 joined languages reach 3,479 pins and 4.78bn people, and none of them are tier 0 - every Zume language already has Scripture or film. Folding training into the tiers would have cut the gap count without anyone having translated anything. The gap filter still cuts 12,379 features to 3,457. Both gates had a hole this exposed. The coverage gate harvested URLs from s, f and d only, so the 52 new URLs existed in no pin record it could see; and clause I checked Film, Scripture and Bible Stories by host but let any other type fall through unchecked. Both now cover training, and a poisoned row typed Scripture on zume.training is caught. The browser gate screened 3,550 links and silently ignored the new ones; it now screens all 3,602. Verified in a browser with a negative control: deu opens with a chip linking https://zume.training/de, kri opens with "not in Zume's 54" and no href, no page errors.	2026-09-24 09:31:13 +00:00
doxa-maps-88655c70	20c1c0d325	Delete the 100-list wall's dead hidden-map export, and stop it lying to a gate ... renderFor() had ZERO call sites and was the only caller of makeHiddenMap() and loadPoster(); EXPORT_SPEC was never read. The whole chain dated from when this wall rendered a poster by spinning up an off-screen map and compositing tiles. Export and print now take the shipped .webp, or rasterise posters/<id>.html in the browser. 52 lines out, 17 of explanation in: 925 -> 888. ★ IT WAS NOT MERELY UNUSED — IT WAS CORRUPTING A GATE. isMapLeaf() in generate-tree.mjs is a REGEX over FILE TEXT, so the engine handle inside the unreachable function flagged this profile isMap=true. That flag made verify-map-paint.mjs EXCLUDE the profile, with a written justification — "constructs a real gl.Map ON DEMAND during poster export, off-screen at left:-9999px" — where every clause was true of the SOURCE and false of the RUNNING PRODUCT. A profile was excluded from a paint gate on the strength of code that never ran, and the exclusion read as a measured product fact. Deleting the chain flips the manifest to isMap=false, which is correct: the poster wall is a wall of cards, not a map. The gate's comment now says it is absent because it IS NOT A MAP, rather than because it is a map the gate cannot see. ⚠ The explanation had to be written carefully. Naming the engine handle whole in a comment RE-TRIPS the same regex and reinstates the bug, so it is spelled in two pieces on purpose with a note saying why — the same class as asserting Mark 5:1-20 via the English word "Gadarenes": describing a thing in the terms the detector scans for makes the description itself the defect. ALSO FIXED, found while verifying: check:poster-print-fallback probed '../assets/posters/<id>.html', one level up. A leaf lives at <tree>/<bundle>/<profile>/index.html and resolves assetsBase to '../../assets', two levels up — so on a tree that DID carry the sources the probe 404'd and the gate SKIPped with "posterSources:true was not set" when it had been. A precondition check that is wrong about the precondition silently turns the whole gate off. VERIFIED AT THE RENDERED LAYER after the deletion, not before: the print path still rasterises with every .webp aborted ("generating the poster", clean terminal state), and the card deck still prints 116 cards at 2.5in x 3.5in with 116 QR codes and 0 page errors.	2026-09-24 09:12:17 +00:00
doxa-maps-88655c70	6732c8d430	Guard the packet catalog: the 12 prayer points and the wheel had no parity gate ... check:i18n-parity covers library/i18n/locales — the APP catalogs. Nothing covered library/scripts/posters/packet-strings.json, which is a separate file with its own shape and is where the 12 PRAYER POINTS and the PRAYER WHEEL live. SIX gates read it and not one checked that a language block is complete. All ten locales happened to be healthy — 19/21 string keys, 12 points with every field, 12 rhythms — but nothing held them there. A point dropped from one block renders that slot through the per-key English fallback: correct runtime behaviour, invisible defect, on a page the reader is meant to pray through. ★ IT ASSERTS PRESENCE, NOT TRANSLATEDNESS, and that is the load-bearing choice. check-packet-render printed "19 strings translated" and only ever asserted `!== 0`, so a locale regressing from 19 to 1 passed silently. The fix is NOT to pin 19: measured, de translates 18 of the same 19 keys and fr 17, because a word or two legitimately matches English — a hardcoded count fails two CORRECT catalogs. So parity asserts every English key EXISTS in every block, a structural fact no translation choice can change, and the render gate gains a FLOOR of two-thirds derived from the catalog itself. point4_passage + point4_passage_credit are DECLARED-ABSENT with the reason on record (Mark 5:1-20, public-domain licensing per language). Naming the exception beats tolerating it silently: the day a licensed translation lands, deleting the entry tightens the gate by itself. MUTATION-TESTED, five defect classes, each caught with a precise message: a dropped string key, an 11th-of-12 prayer point, an EMPTY point text, a missing wheel rhythm, and a block reverted wholesale to English. The floor was tested separately by reverting de to 3 translated of 19 — "only 3 differ from English (floor 13)". ★ THE TWO GATES ANSWER DIFFERENT QUESTIONS, and a partial language shows both at once. Swahili at 3 of 21 keys, no points, no rhythms: check-packet-render PASSES — a partial translation renders, Swahili where translated, English where not, zero blank slots — while check:packet-strings-parity FAILS and names exactly what is missing, including that the points and wheel would fall back wholesale. Before this, only the first question had a gate, so a half-finished block was indistinguishable from a complete one at build time. gates:post is now 22 steps; 11/11 packets still pass the sweep.	2026-09-24 08:57:34 +00:00
doxa-maps-88655c70	e0f2d522bb	All eleven locales complete — the last 162 keys of i18n debt, and the ratchet empties ... regions.json for it/ro/zh, 54 keys each. check:i18n-parity now reports "0 key(s) of known translation debt remain", closing the 429-key gap it found when it was written. ★ THE DEBT MAP IS EMPTY RATHER THAN FULL OF ZEROS, and that is the whole point of this ratchet: a locale with NO entry must be complete — the gate fails it outright for a single missing key — so an empty DEBT is the strongest state it can be in, not an unset one. Writing { it: 0, ro: 0, zh: 0 } would mean the same today and quietly permit a regression the moment someone "adjusted" a number. Mutation-tested both ways: removing ONE key fails ("it is missing 1/176 key(s) and has no DEBT entry"), deleting the whole file fails (54/176). THE CARD'S ESTIMATE WAS WRONG AND IS CORRECTED. It recorded "54 keys of full SENTENCES". Measured: 45 short labels (median 14.5 chars) + 9 longer strings, three carrying %count%/%countries%/%region%/%country% interpolation tokens. The catalog is keyed by its own English TEXT, not symbolic keys — which is exactly why the gap was invisible: the fallback renders the English key itself, so key and value are identical in English and nothing ever looks broken. PLACEHOLDERS HELD BY A PROGRAMMATIC CHECK, not by care: every %token% in every English value must appear, same set, in all three translations. 0 mismatches, 0 empty values. Mangling one breaks interpolation at runtime with nothing to catch it. VERIFIED AT THE RENDERED LAYER on the regions-list leaf, en/it/ro/zh: labels translated (Regions -> Regioni), the intro sentence translated, and the INTERPOLATED count sentence correct — "315 people groups in 41 countries" -> "315 popoli in 41 paesi", both placeholders substituted with real numbers. Zero page errors. Each locale asserted to DIFFER from English, so a silent fallback could not pass. ★ That sentence is the exact bug regions-list.vue:144 records: the Russian string was "ALREADY in library/i18n/locales/ru/regions.json — copied, never wired", caught by reading a screenshot rather than by any assertion. Now it is asserted. zh is SIMPLIFIED, measured not assumed: the existing zh catalogs carry 33 Simplified-only characters against 4 Traditional. Vocabulary follows each locale's own established terms — Popolo / Popor / 民族, Regione / Regiune / 区域 — and WAGF stays an acronym, as fr and de already had it.	2026-09-24 08:48:02 +00:00
doxa-maps-88655c70	95b5586cc5	Assert the packet photos the spec names — "20 per page WITH IMAGES" ... check-packet-render printed "95 cards (0 photos, 95 typographic)" and PASSED, in every locale. The packet spec names the photos explicitly, so that was the last unasserted number on this surface. The cause was my own fixtures, not the product: I regenerated the packets with NOPHOTOS=1 two ticks ago for speed. Regenerating properly gives 95 photos, 3.5MB, 0 broken. But a gate that passes a packet violating a core spec line is the defect whoever made the artefact, and this one would not have noticed a real photo-fetch failure either. ★ THE COUNT CANNOT BE PINNED, so this is two invariants rather than "=== 95". Roughly half the groups genuinely have no photo, the CDN drops some — de came back 94/95 on this very run, which is exactly why a hard count would have been wrong — and NOPHOTOS=1 is a SUPPORTED dev mode for fast layout iteration. So: 1. photos + typographic === cards. Every card is exactly one shape; a card that is neither means the renderer emitted a third nobody is checking. 2. a photo-enabled packet must have SOME photos. Zero is acceptable only when the run declares itself photo-less via PACKET_EXPECT_PHOTOS=0 — "deliberately none" said out loud, rather than indistinguishable from "silently none". MUTATION-TESTED BOTH. Removing a single .card img yields "95 cards but 94 photo + 0 typographic = 94". The photo-less packet FAILS by default and PASSES under the opt-out. (My first attempt at the sum mutation silently did nothing — the card blocks are 11,340 chars and I edited a 1,200-char window — so the assertion only counts as tested because the second attempt targeted the real .card img.) All 11 locales regenerated WITH photos and re-swept: 11/11 pass. i18n re-verified end to end — a partial Swahili block, 3 of 23 keys, added as DATA ONLY with no code change: translated keys render in Swahili, untranslated fall back per key to English, zero blank slots.	2026-09-24 08:35:19 +00:00