25405d571a
Door43 entries carry their own book list. Each ingredient is categorised bible-ot or bible-nt, so a Door43 Scripture entry can say how much Scripture it is, exactly as an eBible one does — and it is already in the response we fetch, so this costs no extra requests. 35 entries scoped: 15 New Testament, 13 Portions, 4 Full Bible, 3 Portions of both Testaments. THE SUBJECT LABEL IS NOT THE SCOPE, which is why it is counted from the data. An entry filed under "Bible" can be 27 NT books and nothing else. Calling that a Bible because of its folder name is the same error as calling Open Bible Stories Scripture. ★ AND THAT ERROR WAS ALREADY SHIPPING, 70 ROWS OF IT, BY MY OWN HAND. Tick 15 added owner disambiguation so two same-named entries could be told apart — "Open Bible Stories (OBS-TLF)". The type test was `d.s === 'Open Bible Stories'`, an exact match, so every disambiguated label fell through to Scripture. 70 story sets have been typed as Scripture for seven ticks: Bhojpuri, Maithili and 68 more told a reader they had a translation when they have 50 illustrated narratives. Found only because the type counts moved when this tick changed the test to a prefix. An exact match against a label that can grow a suffix is the whole defect, and the fix is not enough on its own — so clause H now asserts that nothing named "Open Bible Stories" is typed as Scripture, poisoned with the rest. 8/8 clauses fail on demand. The Door43 chip in the sheet had the same exact-match and now reads "Bible Stories (OBS-TLF) · Door43 · <scope>". The one `===` left in the fetcher is correct and was checked rather than blanket-replaced: it compares the RAW subject from the API, which never carries an owner suffix. Every Scripture row on the map now has a scope. The 2,278 blanks reconcile exactly to 2,087 film plus 191 Bible Stories — none of which is a portion of the canon. Verified: gate passes, its self-test fails 8/8 on demand, and the Door43, pins, table, scope and deep-link probes all pass. |
||
|---|---|---|
| .. | ||
| external-bundles | ||
| people-groups | ||
| posters | ||
| 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.