One more people group moved from Unengaged to Engaged upstream; the total is
still 2107. The maps compute from the live rows and already show the new
split (read on Prayer Progress's engagement legend), no shipping code
hardcodes the totals, and the live endpoint was read independently, so only
this baseline lagged.
Every reference to the Driver in internal/ is reworded the same way as in
library/: the reason stays, the speaker and the quote go, an open decision
reads "provisional, pending a product decision", and agent names and decision-
sheet rows are dropped. Where a gate printed the word, its message now names
the reviewer or the ruling instead.
Three spots were code, not comments, and changed with their callers:
- the element census's allowlist field `driver` is now `ruling`, in the gate
and both presets (same validation: match, ruling, date and card required);
- check:i18n-never-translated's DRIVER-GATED marker is DECISION-PENDING, in
the entries and in the regex that counts them (its output is otherwise
byte-identical);
- the package.json description of the census says "ruling".
public-hygiene-check keeps its two patterns for the word: they are what keep
it out of the served folder.
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.
check:legend-source was failing: the corpus moved 2,107 -> 2,108 and Unengaged
2,080 -> 2,081. The gate's own text forbids updating the baseline alone, since
that silences the check while leaving the maps wrong -- so the maps were checked
first. Grepping 2107/2,107/2080 across plugin-designs/ and library/ found the
number only inside explanatory comments; no shipping code hardcodes a corpus
total. Every legend and KPI computes from the rows it loaded, so the display
already followed the data and only this baseline lagged.
Also recorded, because two independent lostness measurements now ship together
and they are not the same question. imb_gsec measures evangelical presence and
church-planting activity; the six imb_*_available flags measure whether a
resource exists. Over the live corpus:
gsec rung 0 "No Evangelicals, Churches or Resources" .... 225
zero of the six resource flags ......................... 285
BOTH ................................................... 209
rung 0 yet HAS at least one resource .................... 16
zero resources yet NOT rung 0 ........................... 76
Of the 225 groups filed under "No Evangelicals, Churches OR RESOURCES", 11 have
one of the six and 5 have four each. The "or Resources" clause is not literally
true in the data and must not be repeated to a mission team as fact.
Deliberately NOT asserted as a gate condition: which figure is official is an
open Driver decision, and a gate must not quietly canonise one answer to a
question still being asked.
Negative-tested: a bogus baseline drives the gate to exit 1 naming the corpus
size, and restoring it returns exit 0.
Every gate in this repo verifies INTERNAL consistency. check:facet-changes-map
proves the dots change and that the categories sum to 2,107 — but it asserts
that inside the page, against data the page already loaded. If the upstream
corpus shifted, the page would stay perfectly self-consistent while its legend
quietly stopped describing reality. Nothing fetched the live endpoint: not the
six data guards, not check:label-joins, not any browser gate.
That is the worst failure this product can ship, because it is invisible to
every structural check. The element mounts, the canvas paints, the counts are
formatted correctly, the partition sums. Only comparison against the SOURCE
catches a legend that is beautifully wrong — and these maps exist to say where
the gospel has not reached, so a wrong number is not a cosmetic defect.
Measured by hand first, then encoded. The cap-2 engagement legend shows
Unengaged 2,080 / Engaged 27; the live API returns 2,107 rows splitting exactly
2,080 / 27, with no third bucket and no remainder. The cap-4 dashboard KPI strip
prints "1% ADOPTED"; the live API gives 21 of 2,107, which is 1.0%. Three
independent surfaces agreeing to the unit.
The gate also asserts the partition is COMPLETE and that no category exists which
the two-row legend does not show — a third engagement value would hide rows from
the reader while every count still looked right.
The expected values are a baseline, not a law, and the failure message says so:
the corpus is living data and these numbers will move. A mismatch is a prompt to
update the legend, the KPI and the baseline TOGETHER, which is the coupling that
was missing. Updating the baseline alone would silence the gate and leave the
maps wrong.
Offline SKIPs at exit 0 rather than failing, because reporting a mismatch that
may not exist is the fail-open mistake in reverse. Negative-tested both ways:
drifting the baseline fails naming the exact category and both numbers;
an unreachable host skips and says why.
The browser user-agent is deliberate — pray.doxa.life answers 403 to a default
script UA, a trap already recorded here, and one that presents as "the data is
gone".
