cac041da42
Of the 369 Doxa groups with nothing in their language, 94 had no bridge either, and 93 of those were Deaf — 17.5 million people, the largest untouched number on the map. That was structural, not bad luck: every bridge here is a spoken language widely used in the same country, and a spoken bridge is worthless to a Deaf community, so the build correctly refused to offer one and then had nothing else to say. SUN is a signed language built to be learnt across sign languages, with the Old Testament, New Testament and Bible stories in it. It is carried the way a spoken bridge is — something to learn, no substitute for Scripture in a group's own sign language — in its own columns, never folded into the access rung, which stays the honest "nothing found in their language". 28 countries where it is already being taught come with the named local Deaf church or organisation doing the teaching, which is the difference between a resource and a lead. Only URLs verified by their content ship. sun.bible answers 200 for /sun/<anything> and /resource/<anything>, so a per-language URL built by pattern would look valid and could be empty; the fetcher re-measures that catch-all on every run rather than trusting a note. Hosts left out are listed with the reason, including three that are reachable by a person but not by a script. Doctrine was checked harder here, not less. The Deaf are the most heavily targeted group in this dataset by publishers this build must never carry, and the thinner the pickings the stronger the pull. SUN is Wycliffe Associates'. Screening the result exposed the bigger hole. The doctrine scan read the pin index only, and within it skipped the Words of Life and Scripture Earth fields, so the access table — the one the page renders and the one exported to CSV for posters and QR codes — was never screened at all. The least supervised links in the build were the ones most likely to be printed and handed to a stranger. Scanning both, and both fully, takes the screened count from 6,497 to 16,960. The gate also now proves the server holds these tables. It adopted a server from another worktree on the default port and reported PASS on it: all three manifests are byte-identical, because a manifest describes bundles and the change was to a data asset it never mentions. A planted excluded-publisher link went undetected, which is the worst possible failure for this particular check. |
||
|---|---|---|
| .. | ||
| external-bundles | ||
| people-groups | ||
| posters | ||
| pplr | ||
| tables | ||
| vendor | ||
| README.md | ||
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.