e3d25ff6db
Every map showed DOXA's people groups, and only those. The same maps must serve other projects'
lists: Project 7000 (unreached), 4700 (frontier), 700 (frontier of 500,000 or more), 2000 (DOXA).
The list is now chosen the way the engine is:
profile-config `list` > ?list= > window.MAP_LIST > 'doxa' (exactly today's behaviour)
with ids or project aliases ('700', 'project-7000').
- library/lists/lists.json: each list is a FILTER over the IMB / peoplegroups.org dataset already
in the repo (Lostness Priority, Population, Engagement Status), never a hand-kept roster.
- library/scripts/people-groups/build-lists.mjs (`bun run lists`): writes each list's DOXA members
to data/people-groups/lists/<id>.json, joined the way the Vision Card funnel joins, so the
counts agree with it: unreached 7,341 (2,082 DOXA), frontier 4,754 (1,745), frontier-500k 737
(71), unengaged 2,982 (1,929).
- library/lists/peopleGroupList.js: resolvePeopleGroupList and applyPeopleGroupList(rows, cfg).
The default list returns the same array, unfetched. A list whose membership cannot load shows no
groups (fails closed) rather than DOXA's whole list under another list's name.
- Tier A, every production map: DataSourceManager applies it (and the maps that build one pass
their profileConfig), and so does every direct people-group fetch: people-groups-grid, the
Big Picture header, research-dashboard (data, CSV export; the DOXA-wide /statistics baselines
are skipped under another list), Regions (list, dashboards, their table), UPG-100 (4 fetches +
the poster wall), Gospel's roster, and the Experimental upg-neighbor and Wall. The composites
thread `list` to their children like `provider`.
Gates: check:universal-props gains a `list` column (LIST-FETCH, LIST-DSM, LIST-KEYS; its
self-test now plants 9 bypasses) and passes across 18 bundles, with all-people-groups allowed:
it draws the IMB dataset, so its list is Tier B. New check:list-prop-unit (Node, 17 cases, in
gates:post); poisoning the ladder order or deleting a membership file fails it. Documented in
documentation/reference-universal-props.md section 5.
Headless: all 14 touched bundles build; check:composites-mount 20/20 and check:composite-interop
17 links pass on this tree; no-orphan-gates, script-flags, quoted-scripts, doc-scripts pass. Not
rendered in a browser.
|
||
|---|---|---|
| .. | ||
| _registry.js | ||
| apiBaseUrl.js | ||
| DataSourceManager.js | ||
| README.md | ||
| sources.json | ||
library/api/ — where map data comes from
One of the three customization seams (colors/, api/, i18n/). This one decides where
people-group data comes from and how its raw fields map onto the field names the map reads.
The components are source-agnostic — only the connection knows the source's shape.
sources.json DataSourceManager.js the map
┌──────────────────┐ ┌───────────────────┐ ┌──────────────┐
│ your connection │──►│ fetch → normalize │──────►│ map · legend │
│ (type, endpoint, │ │ → cache │ │ · detail card │
│ fieldMappings) │ └───────────────────┘ └──────────────┘
└──────────────────┘ maps raw rows → system field names
sources.jsonis your surface — add a connection (csv,api, orrest-api) and setactiveSource. No code.DataSourceManager.jsis shared machinery — you never edit it.- Import through
_registry.js(SOURCES,getSourceConfig(),listSources(), …).
Adding or overriding a connection? The full contract (required fields, checklist, integration) is in ../../documentation/architecture/data-sources.md.