doxa-life/doxa-maps
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
doxa-maps/documentation/reference-capability-exemplars.md
doxa-maps-88655c70 e8ad1d56e6
Some checks are pending
build-gate / build (push) Waiting to run
Details
packet: a partial translation renders 12 prayer points, not 3 
packet-render.js resolved the prayer points with `L.points || EN.points`.
That is a whole-block fallback when the key is ABSENT, and TRUNCATING when a
translator has done some of the 12 — a 3-element array is truthy. Measured at
the rendered layer with a deliberately partial locale block: a page headed
"12 Prayer Points" containing THREE, points 4..12 silently gone, including the
Mark 5:1-20 passage point 4 prints in full. Nothing blank, no error raised.

Invisible in all 11 shipping locales because every one of them is complete.
It would have appeared on the next language added — and "a new language is a
NEW BLOCK, never a code change" only holds if a PARTIAL block degrades per key,
since half-finished is the normal state of a language in progress.

Now merges per point and per field against English: English fixes the LENGTH
and supplies every missing field, so a point translated for `text` but not
`sub` keeps the English `sub` — and keeps its NUMBER, which the merge supplies.

The sheet-sum invariant could not see this: a 3-point page is still exactly one
sheet, so every number check-packet-render printed stayed correct while nine
points were missing. It now measures and asserts the count. Mutation-tested —
reverting the fix prints "prayer points : 2 / 12" and fails.

All 11 locales regenerated with photos and swept: check:packets-all 11/11, each
12/12 points, including RTL ar and Devanagari hi. Renderer, generator and gate
synced to doxa-maps-plugin-studio, which also lacked the .points-title and
.wheel-title test hooks the new assertion needs.

Also wires check:capability-exemplars into gates:post (33 -> 34 steps). It reads
public/doxa-maps/manifest.json, a build artifact, so ordering mattered: `tree`
writes the manifest and is &&-chained immediately before gates:post, and the
gate SKIPs rather than fails when the manifest is absent. Full wave: 34/34.
The quoted gates:post line in the README is re-synced in the same commit,
because check:quoted-scripts goes red on the drift this commit creates.
2026-09-24 12:20:38 +00:00

4.2 KiB
Raw Blame History

Reference — capability exemplars (GENERATED)

Do not hand-edit. Regenerate with bun run capability-exemplars; bun run check:capability-exemplars fails if this file falls behind the manifest.

This answers one question authoritatively: which bundles are the capability-N examples right now? It is derived from public/doxa-maps/manifest.json, which is what the build computed from each folder's real shape — so it cannot drift from what ships.

Cite this file rather than remembering. The same citation has been wrong in three separate places: a gate, the README, and the /plugin-designer skill. The trap is that a folder's apparent simplicity does not decide its tier — an *.instances.json makes a bundle parameterized (cap-2) no matter how light it looks, and a meta.json type declares tiers 3/4/5.

Generated from 22 bundle(s).

One canonical exemplar per tier (generated — quote these)

Capability Machine key Cite this
1 — single-element single all-people-groups
2 — preset-element (prop-table) parameterized doxa-simple-map
3 — multi-view-element (monolithic) monolithic research-dashboard
4 — composite-element (nested-element SPA) nested-elements-mfe big-picture
5 — app-shell (nested-SPA) nested-mfe-spa doxa-maps-spa

Known-wrong citations this block replaces (both measured 2026-09-22, both in the /plugin-designer skill, which lives outside this repo and so cannot be gated from here): unified-research-dashboard as the cap-4 reference — that bundle does not exist; it became research-dashboard (cap-3) plus dashboard-plus-grid (cap-4). And doxa-vision-card as the cap-1 example — it ships a doxa-vision-card.instances.json with 2 instances, which makes it cap-2 parameterized by the project's own rule.

Capability 1 — single-element

Bundle Profile Machine key
all-people-groups all-people-groups single
cities-internet connectivity-list single
cities-internet connectivity-map single
cities-internet data-tables single
country-posters countries-map single
country-posters country-poster-wall single
golden-path-check golden-path-check single
gospel-resources charts single
gospel-resources data-tables single
gospel-resources resources-list single
gospel-resources resources-map single
my-upg-100-list poster-wall single
my-upg-100-list upg-100-list single
prayer-walk-planner prayer-walk-planner single
regions-dashboard region-dashboards single
regions-dashboard regions-list single
template-bundle template-map-a single
template-bundle template-map-b single

Capability 2 — preset-element (prop-table)

Bundle Profile Machine key
demo-map demo-map parameterized
doxa-simple-map doxa-simple-map parameterized
doxa-vision-card doxa-vision-card parameterized
people-groups-grid people-groups-grid parameterized
upg-neighbor upg-neighbor parameterized

Capability 3 — multi-view-element (monolithic)

Bundle Profile Machine key
doxa-research-map research-map monolithic
research-dashboard research-dashboard monolithic

Capability 4 — composite-element (nested-element SPA)

Bundle Profile Machine key
big-picture big-picture nested-elements-mfe
country-posters country-posters-mfe nested-elements-mfe
dashboard-plus-grid dashboard-plus-grid nested-elements-mfe
my-upg-100-list upg-100-mfe nested-elements-mfe
regions-dashboard regions-mfe nested-elements-mfe
research-map-plus-grid research-map-plus-grid nested-elements-mfe
stack-demo stack-demo nested-elements-mfe

Capability 5 — app-shell (nested-SPA)

Bundle Profile Machine key
doxa-maps-spa doxa-maps-spa nested-mfe-spa
plugin-studio plugin-studio nested-mfe-spa