History

Doxa Maps 65017fefa4 The prayer packet shows how its list was narrowed out of all the earth Page 2 of every packet is now the funnel: 12,379 people groups on earth, 7,341 unreached, 4,754 frontier, 2,107 on this prayer network's list, and N of those in the reader's hand. A partner holding one list can see where it sits in the whole, which is the argument the packet is making. ★ IT RENDERS NUMBERS IT DID NOT COMPUTE. Every count is read from data/people-groups/vision-funnel.json, which build-vision-funnel.mjs generates from the IMB CSV and the live network list and which already drives the Vision Card. Re-deriving them in the packet would give one fact two sources; they would drift, and two internally-consistent surfaces disagreeing is worse than one wrong number because a reader cannot tell which to trust. K AND THE SHARE ARE MEASURED AT RENDER TIME, NEVER TYPED, and this mattered: the brief said "~30 lists of 50-100" and the catalogue says K=27 with counts from 8 to 118 (west-africa 118, asia-india-rajasthan 116, uncovered-scatter 8). Only about half sit in that band, so no copy claims it. The page states what the data can defend -- "1 of 27 lists" and "N of the 2,107" -- and a footnote states plainly that 21 of the 2,107 are in no list, because a partner adding up rows would find the gap anyway. Reported to the Driver; K=27 pending his ruling on whether the two residual buckets count. A SHARE MUST NEVER ROUND TO ZERO. One decimal gave the single-group fixture "0.0%", which reads as "this packet covers none of them". Verified exhaustively over all 2,108 possible list sizes against 2,107: no size prints 0 and none is malformed. 1 group -> 0.05%, 20 -> 0.95%, 21 -> 1%, 43 -> 2%, 118 -> 5.6%. NUMERALS STAY WESTERN, as required. num() is toLocaleString(lang), and CLDR's default numbering system for the bare ar/hi tags is latn -- verified 12,379 and 2,107 in both. Reusing num() rather than writing a second formatter is also what keeps the funnel's digits identical to every other page of the packet. PAGE COUNT NOW COUNTS THE ARTIFACT. packet.mjs computed `1 + ceil(n/PER_PAGE) + 2` under a comment claiming the number was "asked of the renderer, not recomputed here". It WAS recomputed, and the funnel page silently made it wrong by one -- exactly the drift the comment warned of. It now counts the emitted sheets. THE GATE IS TAUGHT, NOT LOOSENED. check-packet-render went red on every fixture ("43 cards should lay out as 6 sheets, but the packet has 7") -- correct behaviour on a structure it had not been told about. The wrong fix is to accept N or N+1: that assertion exists to catch silently dropped people groups, and a ±1 tolerance is the slack a lost list page hides in. So the funnel is DETECTED via .funnel-title and added as a known term, and a funnel page that renders its title but no share figure is now its own failure -- a number printed but not asserted on is decoration. The page is OPTIONAL: buildPacket omits it when no funnel data was supplied, so every existing caller keeps working and a host without the data still gets a correct packet. Better a 4-section packet than one asserting figures it could not read. A multi-list batch selection keeps the steps but drops "1 of 27", which is false for a custom selection, while "N of the 2,107" stays exactly true. Verified: check:packet-strings-parity PASS (31 string keys x 11 locales, my 10 new ones present and translated in all 10 non-English blocks, 0 declared-absent additions). A partial locale with 3 of 10 funnel keys translated renders those 3 translated and the other 7 in English, nothing blank. Arabic packet generated: dir="rtl", funnel is sheet 2 of 7, all four steps carry Western digits. All 16 generated packets satisfy the corrected sheet arithmetic, including the 11 older laos packets that have no funnel page. Mutation-tested: dropping a list sheet is caught by the independent page-header witness (20 DROPPED), a funnel page with no share figure is caught by the new assertion, and removing the funnel page passes. BUNDLE=my-upg-100-list vite build 319 modules clean. NOT verified in a browser: check:packet-render launches Chromium, which the Playwright policy reserves to rega. The simulations above parse the same attributes from the same generated HTML.		2026-09-26 04:38:59 +00:00
..
all-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
big-picture	Translate the eight strings that had no catalogue entry, keeping their English exactly	2026-09-26 03:34:42 +00:00
cities-internet	Cities list + tables: keep numbers in their previous format while numerals are held	2026-09-26 02:38:06 +00:00
country-posters	"Show on map" switched the view and the map never acted: retain the request	2026-09-26 04:21:49 +00:00
dashboard-plus-grid	Big Picture and Simple Research mount again: import the three locale names they use	2026-09-26 03:02:46 +00:00
demo-map	Move internal files out of the repo; fix five dead links; a fuller delegation diagram	2026-09-25 05:14:10 +00:00
doxa-maps-spa	Research Gallery: PPLR Data Maps and Wall of People Groups are named in all 11 languages	2026-09-25 23:41:17 +00:00
doxa-research-map	The map follows the list: filter the grid and the camera goes there	2026-09-25 23:28:53 +00:00
doxa-simple-map	Prayer Progress: no hardcoded English left in the map's own chrome	2026-09-26 03:34:16 +00:00
doxa-vision-card	Doxa Vision Card: take the page language from profile-config lang as well as locale	2026-09-26 01:10:51 +00:00
golden-path-check	golden-path-check: walk the develop-a-plugin-and-see-it-live path end to end	2026-09-22 03:55:18 +00:00
gospel-resources	Gospel map: give the zero-access view an address, and say the way in on every row	2026-09-26 03:56:24 +00:00
key-cities	Key Cities (gated): the map, list, tables and posters speak the reader's language	2026-09-26 03:34:30 +00:00
my-upg-100-list	The prayer packet shows how its list was narrowed out of all the earth	2026-09-26 04:38:59 +00:00
people-groups-grid	Match the live page's wording where we differed only by case	2026-09-25 17:08:16 +00:00
plugin-studio	Engine and token props: a token-service URL is honoured, Clear clears, and a pending token is awaited	2026-09-26 03:34:15 +00:00
pplr-data-maps	PPLR data maps: tab labels and status lines speak the reader's language	2026-09-26 03:34:28 +00:00
prayer-walk-planner	Export gate reads the tree name from the build config	2026-09-25 21:32:35 +00:00
regions-dashboard	Port their box-sizing reset into the shadow root, and delete the seven patches it replaces	2026-09-26 02:10:30 +00:00
research-dashboard	Translate the eight strings that had no catalogue entry, keeping their English exactly	2026-09-26 03:34:42 +00:00
research-map-plus-grid	A gate for the mistake I shipped: a name used but never bound	2026-09-26 04:21:49 +00:00
stack-demo	Studio and stack-demo hand the host's language down to what they mount	2026-09-25 13:26:01 +00:00
template-bundle	template-bundle: the starter's first screen is now a real map	2026-09-26 04:38:12 +00:00
upg-neighbor	Flower Mesh opens on an SVG lens: the leaf-engine gate stops expecting a canvas there	2026-09-26 04:21:49 +00:00
wall-of-people-groups	Wall of People Groups: nothing leaks onto the host page (no Font Awesome, no window.d3)	2026-09-26 03:34:31 +00:00
.gitkeep	Rename app-profiles -> plugin-designs; build green under new naming (load-bearing paths updated, guards pass)	2026-09-17 18:18:18 +00:00
README.md	plugin-designs/README: the tree is dx-maps, and a bundle's tag is its folder name	2026-09-26 01:19:53 +00:00

README.md

plugin-designs/ — where YOUR maps live

The shared template lives in ../library/ (aliased @map) — you never edit it per-map. You build your map by making a folder here, plugin-designs/<your-map>/, and composing the template's building blocks. Your folder is yours (colors, API, i18n); the template is shared (Apache-2.0, propagated to every map on the next build).

Shared vs. yours — the balance

  library/  (@map)  ── SHARED, reusable, parameterized ──►  legend · map · map-controls
        │                                                    (every map reuses these)
        │  imported by
        ▼
  plugin-designs/<your-map>/  ── YOURS ──►  the map's "main" class (the .vue profile = the Vue
        │                                  instance for that map)
        └── src/            ── YOURS ──►  this map's OWN non-reusable components, colors, API, utils

  One bundle can hold as many maps as you want — add another .vue profile and rebuild.

Reusable → library/. The legend, the map, the map-controls are shared, parameterized components every map reuses. Fix once, every map benefits. Never edit it to customize one map.
This map's own → plugin-designs/<your-map>/. It holds two things: the map's "main" class (each .vue profile is the Vue instance for that map) and that map's own non-reusable components (in src/). Nothing here leaks to another map.
Many maps per bundle. The bundler bundles one map or many — add another flat .vue and rebuild.

Production or experimental — every profile declares itself

Every app profile is one of two things, and experimental profiles are unlimited and encouraged — create as many as you need:

Experimental, not built: prefix the folder with _ — the build skips it; it just sits in code. Zero cost, zero risk.
Experimental, built: builds normally, but it belongs in the Experimental section of the power app's layout (nav section) — never embedded on partner surfaces.
Production: a real product — main sections of the power app + individually embeddable.

(The power app = the SPA layout that composes all profiles into one application.)

The pattern in one picture

plugin-designs/<your-map>/     ← one FOLDER = one BUNDLE, named after the folder
   ├── index.js               ← entry: registers the custom element, finds the profiles
   ├── overview.vue           ← one .vue = one PROFILE (flat in the folder — no profiles/ subfolder)
   └── detail.vue             ← another profile in the SAME bundle

     builds to ─────────────► public/dx-maps/<your-map>/<your-map>.js   (one file)

Folder name = bundle name. Folders starting with _ or . are skipped (handy for WIP).
Each .vue = one profile (one map screen). One bundle can hold many.
Pick the profile at embed time with the profile field — every profile shares one bundle:

<script src="/dx-maps/<your-map>/<your-map>.js"></script>
<your-map profile-config='{"profile":"overview","tk":"pk.eyJ..."}'></your-map>
<your-map profile-config='{"profile":"detail","tk":"pk.eyJ..."}'></your-map>

Add a map — three steps

# 1. create the folder + one profile
mkdir -p plugin-designs/<your-map>
#    index.js   ← copy doxa-simple-map/index.js, rename the tag
#    <name>.vue ← your screen, built from @map/* blocks (flat in the folder)

# 2. build
npm run build            # → public/dx-maps/<your-map>/<your-map>.js
#    (just this one:  BUNDLE=<your-map> npm run build:bundle)

# 3. embed the script tag + element (dev staging at `npm run dev` shows a paste-ready snippet)

Your three things (everything else is shared)

Colors — how pins are colored. Pick one the template ships (getColorStrategy('language-family')), or drop your own in plugin-designs/<your-map>/src/colors/ (start from template-bundle/src/colors/example-mode.js). Never edit @map/colors/ to recolor your map.
API — your map reads its data from the profile-config on the page, so the same bundle points at different data with no rebuild. DataSourceManager accepts csv (bundled file), api (one JSON URL), or rest-api (a live REST endpoint, the default). Prefer the real API over inlined JSON.
i18n — the template ships 11 base locales in @map/i18n/locales/. Use useI18n() for strings and RTL_LOCALES for right-to-left; add or override strings from your own profile.

The one hosting variable

The only thing that changes between hosting modes is the <script src>: a relative path when your own site serves the file, or an absolute CDN URL when a partner site serves it. The bundle is identical either way. See ../documentation/CONTRIBUTING.md for the two CDN modes and partner-site embedding.

Profile patterns (mix freely)

Individual — one .vue per bundle (simplest).
Parameterized — one profile, behavior driven by profile-config props (e.g. tabs[]).
Nested — one profile that renders others (workbench-style, like doxa-research-map).