The credit line said who translated the Scripture and called them "the likeliest
people to ask", then stopped at a name. 838 of the 929 credited groups now reach
that organisation's own homepage from the sheet.
The URL does not come from eBible's homeDomain field, which is still dropped: it
comes from a hand-screened list of 16 organisations, every one fetched on the run
that wrote the table. Where a credit names two, the one it LEADS with wins, so
"Pioneer Bible Translators and The Word for the World International" reaches
Pioneer and not the other way round.
National Bible Societies hold 89+ credits and are deliberately linked to none of
them: several UBS members publish editions carrying the deuterocanonicals, so
whether a Society contact sits inside the 66-book filter is a ruling to be made,
not one to assume. They keep the name without the link, and the count says so.
A contact is screened as somewhere to write to, not as a publisher this map reads
text from — two separate lists, so wycliffe.org appearing as a scripture link is
still a failure. Four organisations answered a datacentre IP with a bot challenge
while serving browsers normally; those are proved by robots.txt and the table
records which method proved which.
rega falsified my own fix. The button went 25.44 -> 17.63 against their 37.63 --
FURTHER from theirs than before I touched it.
I wrote padding:var(--spacing-xs) var(--spacing-2xl). --spacing-xs DOES NOT EXIST,
and dxlife-tokens.js:43-45 says so on purpose: "--spacing-xs (10px) and --spacing-sm
(13.3px) are deliberately NOT tokenised: '10px' is far too common a literal in this
CSS to substitute safely, and a wrong substitution here is worse than a magic number
because it reads as deliberate." I substituted anyway, into the one file whose
comment forbids it.
An undefined var() invalidates the WHOLE declaration at compute time, so the padding
fell to 0 on BOTH axes -- not just the vertical I was aiming at. Everything else on
that line landed: border 1px, radius 100px, line-height 15.625. Nothing errored, the
build passed, check:sri passed, and the failure was invisible from here.
Now the literal: padding:10px var(--spacing-2xl). Theirs computes "10px 41.6158px",
so 15.625 + 2x10 + 2x1 = 37.63 tall and ~210.7 wide against their 210.73.
GUARDED so this class cannot recur silently: the spacing check now resolves every
var(--spacing|--font-size|--line-height) reference against dxlife-tokens.js and
fails on any that is undefined, with a NEG control asserting --spacing-xs really is
absent so the check has something real to catch. rega found this by grepping every
var() by hand; that is now automatic. Currently 19 tokens defined, 0 undefined
references.
THE OVER-REACH WAS REAL AND rega QUANTIFIED IT: because the button shrank 7.81px,
all 121 leaves below it on ethiopia moved UP by the same amount at both 1440 and 768
-- the Total count and every UUPG card's name, country, tags and Full Profile. With
the padding resolving, the list sits 12.19px LOWER than before, which is correct
because it now matches theirs.
Confirmed in the same run, unchanged: all four stats at 47.6837px, identical to
theirs, with the only knock-on being the Population label moving down 9.55px as its
value grew -- 93 of 95 africa leaves untouched.
P1 rendering. Opening India or China now draws its provinces, coloured by the
same ladder as the country beneath them, and tapping one gives its groups, its
people, how many have nothing, the largest of those and the way in.
It arrives on intent rather than on load. India's ADM1 geometry is 1,628 KB —
nearly the size of the whole world ADM0 file — on a leaf that already loads about
4 MB and is meant to be embedded on thousands of partner sites. Loading it for
the 173 countries nobody is looking at would tax every reader for the benefit of
two. Opening one of the two IS the signal; China is 54 KB, and both are cached
after the first open.
The counts come from the measured table, never recomputed in the leaf. The
point-in-polygon belongs in the build, and a second implementation here is how
two surfaces come to disagree. Provinces repaint when the mode changes, because a
country saying one thing while the province on top of it says another is worse
than having no provinces at all.
The panel repeats that placement is approximate, and that the way in was chosen
for the COUNTRY — which is exactly the limitation going below the border exposed.
Also fixes the gate I added for this, twice. The province fetch interpolates its
filename, so the parse captured the literal prefix "boundaries/" — a real
directory of 4,096 bytes that always exists, proving nothing. The first fix
expanded that prefix against the filesystem, which was worse: unstaging a real
geojson simply shortened the list and the gate stayed green on nine assets
instead of ten, exit 0. The expectation now comes from the filenames the leaf
names, so a file the map asks for and the tree lacks fails. Poison-tested both
ways.
rega measured it on /regions/ethiopia: ours 25.44px tall against their 37.63.
Their height reconciles exactly once the right rules are in. _buttons.scss gives
.button { border: 1px solid var(--button-border-color, transparent); line-height:
var(--line-height-none); border-radius: 100px }, .button.compact { padding:
var(--spacing-xs) var(--spacing-2xl) }, and .button.link sets --button-border-color
to transparent:
line-height 15.625 + 2x10 padding + 2x1 border = 37.63
Ours declared NO padding, so the UA's 1px showed, plus border:0, and font:inherit
pulled the base line-height 1.5 through as 23.44. All four declarations are
portable, so all four are ported and the geometry now matches.
THE ONE SUBSTITUTION, documented rather than silently skipped: their .button also
sets font-family: var(--font-family-buttons), which resolves to Brandon Grotesque —
commercial, and blocked on the Driver. So this control keeps our stand-in face and
the family stays the single measured difference. That is the RULE 1 shape: port
everything portable, document the one thing that cannot be, with the reason.
Both of this pair came from rega measuring text leaves I had not thought to compare,
then re-measuring every hit against the PREVIOUS tree so "already wrong" could be
told apart from "my regression". Neither would have surfaced from my side: the stat
shrink looked like a deliberate rule with a comment justifying it, and this button
looked like a plain button because ours had made it one.
rega measured it on main 71858d71 against live: our "43,045,275" rendered at
38.15px where theirs is 47.68px, on a card of the same width, while the other three
stats matched exactly.
The cause was ours — .rd-stat__value[data-len="long"|"xlong"], stepping the figure
down a rung. Their .region-stat__value is font-family-heading + font-size-3xl +
line-height:1 and nothing else; no such attribute exists in their markup.
ITS OWN COMMENT CONTAINED BOTH REASONS TO DELETE IT.
· "our condensed fallback is wider" than Bebas — STALE. Bebas is vendored now
(public/dx-maps/assets/fonts/bebas-neue, and the glyph oracle reads 279 = 279
SAME), so there is no wider fallback left to compensate for. useDocumentFont.js
records that an uppercase hack and "two font-sizes" were knock-ons of not having
the real face; this rule is the third, missed when the others were fixed.
· "every value DX-life itself renders keeps their size" — FALSIFIED. "43,045,275"
is ten characters, so it hit the 'long' bucket, and DX-life renders exactly that
number at full size on /regions/africa. A rule whose own invariant is violated in
practice is not protecting anything.
Deleted with its mechanism, not just its symptom: both rules, the :data-len binding,
and lenBucket() itself. A dead helper left behind is the next reader's puzzle.
Found because rega re-measured every over-reach hit against the PREVIOUS tree, which
separated "my line-height change did this" from "this was already wrong". Without
that control the finding would have looked like my regression, and I would have
spent the tick defending the wrong thing.
check:composite-freshness found stale on main: all-people-groups
big-picture
cities-internet
country-posters
dashboard-plus-grid
demo-map
doxa-research-map
doxa-simple-map
gospel-resources
key-cities
my-upg-100-list
people-groups-grid
pplr-data-maps
prayer-walk-planner
regions-dashboard
research-dashboard
template-bundle
upg-neighbor
wall-of-people-groups. Rebuilt, tree + SRI
regenerated; the landing precondition (fresh, one folder, SRI) passed in main-capture scan.
utilities/_typography.scss gives .font-size-4xl a clamp:
font-size: clamp(var(--font-size-2xl), 6vw, var(--font-size-4xl))
and ours was a flat var(--font-size-4xl). Identical at 1024 and above, where both
sit on the ceiling, but below that ours never shrank. Their resolved values against
ours:
390px theirs 38.15 ours 59.60 ours 21.46 too large
768px theirs 46.08 ours 59.60 ours 13.52 too large
1024px+ theirs 59.60 ours 59.60 identical
★ I REPORTED THIS AS UNCHANGEABLE ONE COMMIT AGO, AND THAT WAS BACKWARDS. I said it
interacted with the documented nowrap decision — a figure must never split across
lines in a 372px card, which is why the flat value was chosen. But the clamp makes
the figure SMALLER exactly where the wrap was observed: in a 372px container 6cqw is
22.3px, below the 2xl floor, so it resolves to 38.15px against the 59.60px that was
breaking. The clamp helps the very problem the flat value was picked to avoid. I had
assumed a conflict instead of computing it, and one line of arithmetic settled it.
The nowrap stays as a belt.
cqw rather than vw, consistent with every other clamp in this element (the
container-vs-viewport substitution the Driver is still ruling on). At 768 that lands
42.4 against their 46.08 — 3.68 off instead of 13.52.
_chk-clamp-floors-at-phone-and-tablet.mjs picks the new clamp up on its own: 14
clamps now, and 12/12 token-bounded ones still pin to their floor at 390, so the
"exact parity at phone width, provable without a container measurement" result now
covers the big number too.
THE EIGHTH GLOBAL RULE OF THEIRS FOUND MISSING, and the same class as the
box-sizing reset: _globals.scss:14 is `body { line-height: var(--line-height-normal) }`
with $line-height-normal: 1.5, and a document-level rule does not cross a shadow
boundary. dxlife-tokens.js declared every spacing and font token and NO line-height
at all, so every text element in the clone inherited whatever the EMBEDDING PAGE
set, while theirs is deterministically 1.5.
.rd-big carried line-height:1.1 to compensate. At --font-size-4xl (59.6046px) that
is a 65.6px line box against their 89.4px — a 23.8px difference. rega measured the
consequence to the pixel: our goal cards were 24px shorter than theirs (571 vs 595),
their big number sitting ~12px lower and its label ~24px lower, the extra leading
splitting roughly half above and half below the glyphs. Theirs is
`<p class="font-size-4xl font-weight-medium">` and the .font-size-4xl utility sets
ONLY a font-size, so their number simply inherits body's 1.5.
So :host now carries their line-height and its tokens, and .rd-big's override is
gone. Their own tighter cases stay explicit and already agreed: .region-stat__value
is line-height:1 and so is our .rd-stat__value.
★ I APPLIED THIS HALF-WAY FIRST. The :host patch failed on a string mismatch while
the .rd-big patch succeeded, which left the number's line box inheriting from the
HOST PAGE — worse than the wrong-but-deterministic 1.1 it replaced. Caught because
the two patches reported separately instead of as one result.
CORRECTION TO 9009dd62, owed and measured against me: that commit claimed our goal
line "floated at three different heights" where theirs bottom-aligned. rega measured
both sides — the goal line sits 42px above the card's bottom edge on BOTH, in all
three cards, with identical gaps to the element above (0 / 73 / 120px). So margin:0
already reproduced their margin-top:auto at 1440, and the visible defect I described
did not exist. The change stands as a verbatim port of their declaration (RULE 1),
and it matters only where a card has free space — but I asserted a consequence I had
not measured, and the measurement says otherwise.
STILL DIFFERENT, reported not changed: their .font-size-4xl utility is
`clamp(var(--font-size-2xl), 6vw, var(--font-size-4xl))` where ours is a flat
var(--font-size-4xl). Identical at 1440, divergent below — at 768 theirs is 46.08px
and ours stays 59.6px. It interacts with the documented nowrap decision (a figure
must never split across lines in a 372px card), so it goes out for measurement
rather than into this commit.
Drawn verification is rega's: card heights 571 -> 595 and the two gaps around the
big number. A base line-height touches every text element in the element, and I
cannot measure layout headlessly.
check:composite-freshness found stale on main: country-posters
my-upg-100-list. Rebuilt, tree + SRI
regenerated; the landing precondition (fresh, one folder, SRI) passed in main-capture scan.
A real clone defect, found by reading their markup after rega's live spacing probe
landed NEAR it and measured the pair as EQUAL.
Theirs is RegionDetail.vue:24 `.region-goal { margin-top: auto }`, and the goal
paragraph is the last child of `<div class="stack stack--lg | card | text-center">`.
composition/_stack.scss makes .stack a flex COLUMN with
`> * + * { margin-top: var(--stack-spacing) }`, so that auto OVERRIDES the child
margin and pushes the goal line to the BOTTOM of the card. Ours was margin:0, which
left it sitting directly under the text above it.
The visible consequence is the whole point for a clone: the three goal cards hold
different amounts of copy, so theirs align their goal lines flush along the cards'
bottom edge while ours floated at three different heights. That is exactly the kind
of thing the Driver means by "proper css spacing" — nothing is off-scale, and it
still looks wrong.
WHY THE PROBE COULD NOT SEE IT, which is worth more than the fix. rega measured
.rd-goal against .region-goal as "same", and they were right: at 1440 the card has
no free space, so margin-top:auto resolves to 0 and the two computed values agree.
An equal number hid a real difference. Their probe was correct AND incomplete, and
only their markup settled it.
My own spacing check could not see it either, for a different reason: it verifies
every value we SHIP is on their scale and is structurally blind to a declaration we
OMIT. That is "a property diff cannot see an addition", inverted. It now carries
hand-written assertions for the two omissions found this way (this one and
.region-stat__label's margin-top), since there is no general way to enumerate what
is missing.
★ AND I APPENDED THOSE TWO ASSERTIONS BELOW process.exit() at first, so they were
dead code: they printed nothing while the check still reported success. A check you
can add assertions to without them running is the same defect as a check that
cannot fail. Moved above the exit.
Also corrected, for the record: two of the nine selector pairs I gave rega were
wrong. .rd-big/.rd-big-label are the GOAL CARD's number and label, not their
.region-stat__* pair — our real counterparts, .rd-stat__value and .rd-stat__label,
already matched theirs exactly. And .rd-switcher's 112.5px side margins are the
container rule on .rd-scroll > * (90%+16px capped at 1200, centred at 1440), not a
spacing difference; theirs lives on a separate .container ancestor. I built that
pair list from greps instead of from the provenance comments in the file, which
document the true counterparts.
check:composite-freshness found stale on main: all-people-groups
big-picture
cities-internet
country-posters
dashboard-plus-grid
demo-map
doxa-research-map
doxa-simple-map
gospel-resources
key-cities
my-upg-100-list
people-groups-grid
regions-dashboard
research-dashboard
research-map-plus-grid
upg-neighbor
wall-of-people-groups. Rebuilt, tree + SRI
regenerated; the landing precondition (fresh, one folder, SRI) passed in main-capture scan.
The Driver settled the call this was parked on: "the only changes are to the map to
make it look better, and to add the all-regions map ... which needs to be
intuitive". This is the map half, on the sanctioned addition only.
Their .country-map flips to aspect-ratio 1/2 under 768px and we port that verbatim
on .rcm — right for the CLONE pages, which frame one region or country in portrait.
The chooser renders under the GLOBE projection, so its subject is a CIRCLE whose
diameter cannot exceed the frame's short side. In a 1:2 frame that circle covers at
most W / 2W = 50% of the height: at 390px wide, 390px of globe in a 780px box with
the rest empty.
So this is geometry, not a preference between two acceptable options. A square is
the ONLY frame a circle fills on both axes, and every other ratio is provably worse
for a circle:
1/2 frame height 50% area 39.3%
1/1 frame height 100% area 78.5% (pi/4, the maximum in any rectangle)
Vertical coverage doubles.
SCOPED TO THE ADDITION, and that is the part worth checking rather than trusting.
The rule is .rcm--chooser, bound to colorMode === 'region'. I verified that value
is chooser-only instead of assuming it: mapColorMode returns 'in-country' for a
country and 'prayer' for a region, so 'region' is only the fall-through — the
no-selection state. If that ever stopped being true, this rule would silently
change cloned geometry, which is exactly what the scope ruling forbids, so the
check asserts it.
The existing globe-fill formula needs no change: it bisects the zoom that fills the
frame's SHORT side, which a square leaves well defined.
_chk-chooser-square-on-mobile-clone-untouched.mjs asserts both halves — the chooser
changed AND the clone did not — computes the coverage rather than restating it, and
carries a NEG control showing a 1/3 frame scores worse than 1/2, so the metric
discriminates between ratios instead of blessing whatever it is given.
The Driver's instruction: the regions dashboard must look like a clone of dx-life
"with proper CSS spacing", the only sanctioned deviations being the map and the
all-regions chooser. So spacing stops being a matter of taste and becomes a
measurement: every padding, margin and gap we ship should be a value THEIR CSS can
produce.
Measured that way, one value was ours and off-system: .rd-status / .rl-status
padding:28px, the app-only empty and loading blocks ("No regions found.",
"Loading region dashboards…") that their server-rendered page cannot be in. The
ELEMENT is legitimately ours; the NUMBER had no business being invented. Now
var(--spacing-xl). Result: 39 var(--spacing-*) references and 34 px literals, all
traceable to their CSS, and ZERO off-scale values.
★ TWO DENSITIES, AND I HAD CONFLATED THEM. tokens/semantic/_typography.scss sets
$font_density 1.25; tokens/semantic/_spacing.scss sets $density = $major-third =
1.33. An earlier check used 1.25 for BOTH, so every spacing floor it reported was
wrong. The conclusion survived — 11/11 token-bounded clamps still pin at 390px —
but one case came within 0.13px of flipping, which is the margin a wrong constant
hides. The scale is now DERIVED in the check from their own file, with a control
that fails if their file stops saying 1.33, so it cannot drift back.
The check's first premise was also too strong and would have produced three false
findings. It flagged 15px, 25px and 3.5px as off-system when clamp(15px, 6%, 25px)
is _progress-bar.scss:14 verbatim and gap:0.35rem is .prayer-coverage-legend's own
— correct ports under RULE 1. A value is only off-system if it appears NOWHERE in
their CSS, so the reference set is harvested from their real stylesheets and
unioned with the token scale. .sr-only's margin:-1px is excluded for a different
reason: it is the screen-reader clip idiom, where 1px is a hairline that keeps the
element non-zero-sized for assistive tech, not a spacing choice.
What this check CANNOT tell you, stated so nobody over-reads it: that a value is in
the right PLACE. It proves every number is on their system, not that the right
number is on the right selector. Per-selector parity still needs the live diff.
THE DOTS. The old comment claimed all three pin colours sat apart from the clay
country ramp. For the one that matters it was false: tier 0 was #7d3b30 and the
darkest country fill is #7d3b30 — the same colour, contrast 1.00. In exactly the
countries with 40+ groups having nothing, the pins that matter most dissolved
into their own country.
Hue alone cannot fix it, because a choropleth and its pins compete for the same
range at every zoom. So the states now differ in FORM: a group with nothing is a
HOLE — white core, thick oxblood rim — and it is the largest mark on the map and
drawn on top. Some resource is a solid sage dot; Scripture and film is a small
dark dot that recedes. A blurred white halo sits under every pin so a dot never
touches its fill directly.
Two components, because one can always be beaten by a background. Measured
against all four fills: on the lightest the white core is 1.38 and the rim 6.00;
on the darkest the rim is 1.00 and the core 8.27. Worst case across the ramp is
3.64, above the 3:1 that graphical objects need. The mark cannot disappear.
The legend swatch is a hole too — a filled dot there would teach the wrong
symbol.
THE LEGEND overflowed the bottom of the page. It is absolutely positioned inside
the map, so its height was whatever its content happened to be. Capped to the
map's own height and scrolled inside — the container's height, not the
viewport's, because this leaf is embedded and vh would break on any partner page
that gives the map a fixed box.
THE WORDS. 232 words of English caveat sat above the three short translated
instruction lines that are the actual instruction set: what a dot is, what "none
found" does not mean, that a country is tappable. Every one of those 232 words is
true and load-bearing and none is needed before you act. They are folded behind
one summary, not deleted. They stay English by the standing decision on prose, so
folding costs nothing to translate and takes 232 words off first sight.
check:composite-freshness found stale on main: country-posters
my-upg-100-list. Rebuilt, tree + SRI
regenerated; the landing precondition (fresh, one folder, SRI) passed in main-capture scan.
P1, data layer. 855 of Doxa's 2,107 groups are in India and 154 in China — 47.9%
of everything this map draws, rendered until now as two flat fills. No other
country is close; the third is Sudan at 105. Each group is placed into a province
by point-in-polygon on its coordinate: 44 provinces with groups, 998 assigned,
13 provinces holding groups with nothing.
China's ADM1 file carries 12 provinces, not 31+, and I expected that to lose
groups. Measured instead: 152 of 154 Chinese groups fall inside them and all
twelve are used. The file was cut to the provinces where the unreached peoples
are, so the subset is the right subset.
The 11 groups that land outside every polygon are COUNTED, not dropped — nine
Indian and two Chinese, every one of them coastal or an island. That is the
predicted failure of placing a people by a single point, and it belongs in the
output rather than in a silence.
Every row is flagged approximate, because a province here comes from a coordinate
that marks where a people is found rather than a settlement, and 108 groups in
the roster share a coordinate with another group.
Going below the border also exposed something the country view was hiding:
Arunachal Pradesh, in the far north-east, is offered TELUGU as its way in,
because the curated bridge table names it and a curated bridge outranks the
computed one. India's computed default is Hindi, defensible nationally and still
wrong for much of the north-east. This table does not fix that. It records it, and
says to read the ways-in column as "a language with Scripture and film somewhere
in this country" until a bridge can be chosen per province.
P5. A pin marks where a people is found, not a settlement, and the data shows it:
of the 2,107 placed groups, 2,048 have a distinct coordinate — so 49 coordinates
carry more than one group and 108 groups sit on a point they share with another.
41 pairs, 6 triples, 2 quadruples; four groups share one coordinate in coastal
Karnataka and four more share a second point a few kilometres away.
The coordinates also carry false precision: 1,274 are given to six decimal
places, metre resolution on a figure describing where a people is found.
Rendering that without comment invites a reader to treat a dot as an address.
So the sheet says what the dot is, and where the point is shared it names the
other groups. "Approximate" alone would have been the easy word and the wrong
one — it hides the part a reader would never otherwise discover, that some dots
are literally the same dot. 108 sheets carry the second sentence; the other
1,999 carry only the first.
P2. The list of groups with nothing already existed and could only be reached by
knowing which control to press. It is the question this map is for, so it gets an
address: ?view=zero opens it with the map already filtered to those pins. That
address is also what a partner embeds and what a QR code points at.
Each row now carries its way in. This was the only surface showing groups with
nothing that did not say what to do about them — the pin sheet and the country
panel both do — and it is the one a mobiliser reads top-down.
Building it exposed the same flag under-reporting for the third time. `sg` comes
from the sign-language catalogues and asf (Auslan) carries none, so reading it
alone this leaf missed Cocos Deaf, Deaf Christmas Islanders and Deaf Norfolk
Islanders: no SUN panel on their pin sheet, and no way in on the list, while the
access table gave all three SUN. The pins builder and the access builder were
each corrected the same way earlier; this puts one Deaf test in the leaf so the
four surfaces agree. Measured after: 369 of 369 zero-access rows carry a way in,
none blank.
The revert left fmtShort and the table's row count going through fmt() instead of
calling toLocaleString() directly. Behaviour was identical, because fmt is that
bare call again — but the acceptance measure for holding number format is a
literal count of the pre-change state, and 6 is not 8. An "identical in effect"
argument is the wrong currency when the point is that this map must be byte-for
-byte what it was until the Driver rules.
Measured against the build at 2eac0fb3^: numberingSystem latn calls 0, bare
toLocaleString() 8, both exact. The number handling in all four leaves now
differs from that build only in comments.
08f89f55 gave both composites a text-direction computed that calls
getRuntimeLocale(), detectLocale() and RTL_LOCALES, but imported none of them.
The build does not check free names, so the bundles on main reference three
undefined globals. watch(textDir, reflectDir) evaluates the computed during
setup, so setup throws a ReferenceError in every locale, and Vue renders
nothing for the whole composite: the map, the dashboard and the grid.
Reproduced headless with the same computed + watch shape under
@vue/runtime-core: lang '' fails with "getRuntimeLocale is not defined", and
lang 'ar' with "RTL_LOCALES is not defined"; neither renders.
After this import, both bundles build and neither contains a free reference
to the three names.
NUMBER FORMAT REVERTED, on jurisdiction rather than on merit. Formatting with the
locale i18n resolved is almost certainly right, but it decides number format for
this map alone and that decision belongs to every map at once. The finding stays
in the source so nobody re-derives it: toLocaleString() with no argument formats
for the JS runtime's locale, so the same page shows different numbers to readers
on different browsers; and pinning latn would change digits only for region tags,
since the eleven tags this bundle ships already resolve to latn.
MAPLIBRE. Reported against the built tree: under ?provider=maplibre this map drew
the basemap and nothing else — no fills, no pins, queryRenderedFeatures returning
0 while the source held all 2,107 features — while ?provider=mapbox drew 170
fills and 2,107 pins, with no page errors either way. Everything this map draws is
added inside one map.once('load') callback, so a load that has already fired
leaves exactly the basemap, which is the reported symptom; the two engines
resolve their styles on different schedules, so the race lands differently on
each. Draw immediately when the style is already loaded, keep once('load')
otherwise.
This is the cause the evidence indicts, not a verified repair. Browsers here
belong to one agent, so it needs re-running before anyone believes it.
Two things, and the second was found by the first disagreeing with itself.
The CSV is what a team prints onto a poster or turns into a QR code, and it was
the only surface that did not say when the bridge language carries the Zume
course. 179 rows now do. Same URL the sheet already shows and the verification
already proved; nothing new is fetched.
"Candidate groups" is removed rather than renamed. It counted people groups
speaking the candidate language, which only the old pins-derived proxy could
produce; since candidates came from CLDR it has shipped as 0 on all 108 candidate
rows, and an empty column in an exported CSV reads as missing data rather than as
one that stopped applying. CLDR does give whether the language is official there,
which is a real fact about how likely it already is to be taught, so that takes
its place.
THE BUG. 182 rows had a bridge carrying Zume and only 179 could export one. The
three were Deaf groups speaking Auslan, and codes.asf has no sg flag — it is set
from the sign-language catalogues and asf is in none of them. So the pin index
built a SPOKEN bridge for them and the map offered it, because the map's is_sign
test reads that same flag. The access table refused it, because it also matches
the group name. A spoken bridge is not a weak bridge for a Deaf community, it is
not a bridge; this is the residue of the finding that already removed 89.
Suppressed on either signal now, so the two builders agree and the map cannot
offer what the table refuses.
Still 369 with nothing and still none of them without a way in.
app/assets/styles/base/_reset.scss:3-8 applies border-box to every element on
DX-life. Our leaf document carries the identical rule already -- but these
components render inside a SHADOW ROOT, and a document-level `*` selector does not
cross that boundary. So every element in here was content-box while every element
of theirs was border-box, and no scoped component style could reveal it. That is
how it survived seven global-rule fixes, and it is why this codebase had accrued
seven separate per-element box-sizing:border-box patches: each was a local
workaround for the reset that never arrived.
What it cost, measured rather than described: their legend swatch is width:10px
with a 1px border -- 10px under border-box, 12px under content-box. Two swatch
columns of 1px each are exactly the 2px by which our legend panel measured wider
than theirs (167 vs 165) after the rest of the legend was aligned to the pixel.
The same label measured 129px on both sides in the same Poppins, so the text was
never the cause.
The port is a geometric NO-OP and that is why it is safe to do in one move: the
blast radius was measured FIRST, by injecting this exact rule into every shadow
root and diffing every element's rect. 0 of 431 elements moved on
region-dashboards, 0 of 678 on regions-list, 301 already border-box by their own
declarations. The detector was negative-tested, because a zero from a check that
cannot fail proves nothing. So the whole value of this commit is the DELETION --
six per-element patches plus the interim `.rcm *` subtree rule, which the global
reset strictly contains.
Placement is plugin-local, not library/useShadowStyles.js. Putting it there would
fix all 25 bundles in one line and is tempting for exactly that reason, but the
blast radius above was measured on THESE two pages only; 23 other bundles would
have their geometry changed on no evidence. RULE 2 says default to the plugin
folder until a second consumer is named.
One module rather than three copies: three roots inject into the shared shadow
root and any of them can be the one that mounts, so all three need it.
The rows under "No resource found" name the way in. For 182 of the 369 groups
with nothing, that bridge language also carries the Zume discipleship course, and
the row did not say so — which is the difference between "there is a way in" and
"there is a way in and the course to train the first believers already exists in
it". A mobiliser scanning a country is deciding where to start, and that is the
deciding fact.
The bridge's own name stays first, because the language is the decision and the
training is what makes it actionable. It reads "way in: French · Discipleship
training", with the label coming from the catalogue so it follows the reader's
locale like every other label on the row.
Nothing new is fetched or linked: it reads the same Zume URL already verified and
already on the bridge panel, so the doctrine screen is unchanged at 16,963.
The point of this map is not that somebody reads a page. It is that the first
believers in a group are trained and become the first messengers to their own
people and their neighbours. Zume is the piece that does that, and it is
published in 52 languages.
Measured across the 369 Doxa groups with nothing: ZERO have Zume in their own
language, and 182 have a bridge language that does. The map was showing Zume only
to groups that already had something — the half that needs it least — while for
half the gap the training already exists in a language their neighbours speak.
Both bridge panels now carry it beside the Scripture and the film. All 19 distinct
URLs behind those 182 groups were fetched and answer 200, with a bogus locale
404ing so the status means something; every one is on zume.training, already a
screened publisher, so the doctrine screen is unchanged at 16,963 links.
NUMERALS ARE HELD covers the whole formatted number, not just the digit system.
-u-nu-latn keeps digits Latin but lets the SEPARATORS follow the locale, so
de reads 1.234.567 and ru 1 234 567 -- and choosing that is the held decision.
I read "numerals" as "digits", shipped it at d988c6f1, and then wrote a check
asserting that grouping SHOULD vary, which passed green while certifying the
breach. A check encoding the wrong intent turns a policy breach into evidence of
compliance, which is worse than having no check. It now asserts one format across
all eleven locales, with a negative control that the reverted form produced five.
Reverted on the shepherd's instruction; gospel shipped the same change and was
asked to revert its number part too, so no single map settles this.
The try/catch goes with it rather than being kept "just in case": it existed
because a locale-derived tag can throw RangeError, and a string literal cannot.
EVIDENCE FOR THE RULING, read from their master, because it cuts both ways:
RegionDetail.vue:16 n.toLocaleString(`${locale.value}-u-nu-latn`)
their own comment: "Locale grouping separators with Latin
digits, matching the rest of the site."
CountryMap.vue:128 toLocaleString(languageCode) <- the popup, no subtag
So per-locale grouping is THEIR deliberate site-wide convention, and this
element's two other formatters clone that line verbatim. Those are left alone and
flagged, not reverted: changing them would override DX-life's documented choice
rather than stop a map from freelancing, and that is a bigger call than mine.
The popup is the one place theirs follows the locale for digits as well, so it is
also the one place the hold's own rationale actually bites.
And the rationale bites via the REGION, not the language: ar resolves
numberingSystem=latn (1,234,567) while ar-EG resolves arab. A host setting
profile-config.locale to 'ar-EG' is the real exposure, and a fixed en-US is immune.
A pool nobody here had tried, and the reason it stays out is worth writing down
so the next tick does not spend itself on the same site.
It is reachable and it 404s properly, so unlike the shells that defeated deaf
sources, its answers can be trusted. Its index publishes 118 languages with no
pagination and no stated total.
Out on coverage first: of the 294 languages in the Doxa gap, exactly ONE name
matches a folder there. 82 of the 118 match a language this index carries
somewhere, so the catalogue is real and does overlap us — just not the part with
nothing, which is the only part a new pool is worth adding for.
Out on the join key second: no ISO code is published anywhere, in the index or on
a story page. The folder IS the language name, so joining would mean matching by
name, the guess this build removed when Doxa's own API made it unnecessary, and
the guess that would have handed Akha in Laos one of three sub-varieties. The
single gap match above is a name match and worth nothing on its own.
Out on doctrine third, and that word is chosen carefully: no statement of faith
is served at any of the usual paths. This is unverified, not suspected. The brief
says leave a source out when its doctrine is unclear and say why, so that is what
this is, and it is not a finding against them.
No resource, link or count changes; the index differs only by its generated date.
