doxa-maps/data
doxa-maps-88655c70 df3e383c42 One source for the bridge candidate, and the map shows it too
The table offered 107 groups a next step the map did not show. The candidate is
now computed once, in the pin build beside the curated bridge, and both surfaces
read it — the same rule that put the tier in one place. 1,167 candidates across
the research index; 107 of them reach Doxa groups the curated bridge misses.

The map's sheet renders it as its own weaker panel, and the words carry the
limit: "Possibly a way in — worth checking locally", with the language, how
many groups there speak it and what share of the country they are, and "not
ranked and not recommended". No strength, because none can honestly be
computed. Never for a sign language.

A REGRESSION I INTRODUCED AND ALMOST SHIPPED. The edit that wired this used
pinCandidates without declaring it — a string replace that matched nothing and
said nothing. The ReferenceError died inside the custom-element boundary, so the
map never mounted AND the page reported zero errors. My probe then failed with a
30-second timeout that I had caused separately, by passing playwright's timeout
as the waitForFunction ARG rather than its options, which had been silently
using the default in eleven scripts. Two faults stacked: a broken page that
looked error-free, and a probe too impatient to say so.

Zero page errors is not the same as working, and that is the only reason this
was caught: __grState never appeared, which no assertion about pins could have
explained away. Verified after the fix: 2,107 pins, gap cuts to 370, the
candidate panel renders for Abai Sungai naming Malay, and 25 Deaf sheets still
show no bridge at all.
2026-09-25 09:29:48 +00:00
..
external-bundles Data out of public/: sources live in data/, the web-root is generated 2026-09-16 01:24:41 +00:00
people-groups All People Groups loads fast on a light map; the Vision Card becomes a true funnel from data 2026-09-25 07:18:30 +00:00
posters The poster print preview rasterises too, and a deployment can ship sources without rasters 2026-09-24 08:07:22 +00:00
pplr PPLR data maps (WIP): move the ten PPLR research views into plugin-designs 2026-09-25 06:33:49 +00:00
tables One source for the bridge candidate, and the map shows it too 2026-09-25 09:29:48 +00:00
vendor Vendor Vue for the gallery shell, so the self-hosted rung finally exists 2026-09-22 04:59:30 +00:00
README.md Complete app-profiles->plugin-designs sweep across comments/docs; build green; layouts kept at root (load-bearing) 2026-09-17 18:18:19 +00:00

data/ — the bundler's source-of-truth data

The law: data lives here; public/ is generated. Every folder in data/ is copied into the served web-root by the build (internal/generate-tree.mjs), exactly like the per-profile data in plugin-designs/*/data/. You should be able to rm -rf public/ and get it all back with bun run build.

Folder Served at What it is
people-groups/ /assets/people-groups/ People-group datasets (CSV/JSON) the maps read at runtime
vendor/ /assets/vendor/ Third-party runtime assets (e.g. table libraries)
posters/ /assets/posters/ Rendered poster webp set (heavy pipeline output; poster walls fetch these)
tables/ /assets/tables/ The MERGED served table set (its index.json is the merge; per-profile plugin-designs/*/data/tables are build-time sources)
external-bundles/ not served Prebuilt map IIFEs vendored from sibling projects (not built here); only the optional layouts/ shell mounted them, so the build no longer copies them into public/

Don't edit anything under public/ by hand — change it here (or in plugin-designs/*/data/, layouts/*/assets/) and rebuild.