Commit graph

11 commits

Author SHA1 Message Date
doxa-maps-88655c70
502a4186dc Cities with Internet and the phone legend speak the page's language
Cities with Internet was English end to end: the legend title, the four bands,
the World Bank caveat, the new people-group row and the whole country sheet. Its
chrome now comes from a connectivity catalog area in all eleven locales, following
gospel-resources: i18n is optional, English from the shipped catalog is the
fallback, and carrier and platform names stay as data. The legend and the sheets
are anchored with logical insets, so in Arabic the legend sits opposite the control
rail instead of under the zoom buttons.

LegendMobile hard-coded its column labels ("Prayer Status", "Engagement Status",
…) and titles ("Legend", "Languages", …) in English. They now read
legend.colLabel.* and legend.titleBar.*, which every catalog already translates.
English is byte-identical, so other consumers are unchanged until they rebuild.

Measured in the Research Gallery tab on a served built tree, at 1280 and 390, in
en/ar/zh/ru/hi: Cities shows no English UI string (only the Mapbox and
geoBoundaries attribution); ar is right-to-left with 0 clipped and the legend
clear of the control rail.
2026-09-25 06:05:46 +00:00
doxa-maps-88655c70
d6496bd87d Rebuild my six bundles to carry the useMapInstance unmount guard (0c1a91cd)
doxa-simple-map, cities-internet, all-people-groups, upg-neighbor,
prayer-walk-planner and demo-map compile useMapInstance in, so 0c1a91cd reaches
them only through a rebuild. check:shared-reached reports all five that use it as
carrying the guard.

cities-internet builds its map directly and never calls ensureEngineCSS, so it gets
its own guard: onMounted stops before new gl.Map if the pane unmounted during its
awaits. Removing the element 150, 400 or 900 ms after mount did not throw on either
build, so this is defensive, not a measured fix.
2026-09-25 05:23:08 +00:00
doxa-maps-88655c70
299eb24a14 Cities with Internet: red people-group dots that open the people-group panel
Driver: "cities with internet map should have red dots on the map to show me
where the people groups are." Every DOXA people group is now a dot over the
connectivity shading, using the pray-tools list that Prayer Progress draws. It
carries the slug the detail panel fetches by. The dots are #e11d48 with a white
ring so they read on the "under 25%" red countries too, and the legend gains a
"people group" row with the count.

Tapping a dot opens the same PeopleGroupDetail panel Prayer Progress uses, through
useSelectedPin and the shared LegendDesktop / LegendMobile wrappers: a card on
desktop, the bottom sheet on a phone. Tapping a country still opens its carriers.

Measured on a served built tree: 2,107 dots for 2,107 groups; a tapped dot opens
the panel with the group's data at 1280 and at 390, in English and in Arabic; the
Research Gallery tab shows the same 2,107.
2026-09-25 05:06:11 +00:00
doxa-maps-88655c70
34cb921b96 connectivity-map honours the provider switch
Found by verifying the GOAL rather than the checklist. The rollout table
only ever listed plugins with a search bar, so a sweep of all 16 isMap
leaves was run under both providers: 12 of 16 swapped, and this leaf made
18 requests to api.mapbox.com under ?provider=maplibre — identical to its
mapbox run, because it builds its map RAW (new gl.Map on window.mapboxgl)
and never reaches the resolution useMapInstance does for everyone else.

Same shape and same fix as my-upg-100-list, minus the token gate this file
never had: the engine comes from the shared ensureEngineScript/engineGlobal
rather than a hardcoded global, and the two hardcoded mapbox:// style URLs
are paired through the registry — 'ink' (dark-v11 / OpenFreeMap dark) and
'paper' (light-v11 / positron) — so both engines show one intent. The
engine loader is imported, never re-declared; a second ENGINES table in a
profile is how two copies of one fact drift apart.

No geocoder is mounted here, so the deferred-search-bar rule does not apply
and nothing about the search behaviour changed.

MEASURED on the built tree:
  mapbox    canvas=1  18 mapbox requests  (unchanged)
  maplibre  canvas=1   4 mapbox requests  maplibregl loaded
Screenshot read: positron basemap, connectivity choropleth, legend and
controls all intact.

Also recorded from the sweep: poster-wall and regions-list draw NO canvas on
either engine — they are the already-filed isMap misclassification, not
gaps, and must not be "fixed".

7/7 pre, 18/18 post.
2026-09-24 03:14:35 +00:00
doxa-maps-88655c70
566ad4676e Commit the two pinHint:false metas that were only on disk
Some checks are pending
build-gate / build (push) Waiting to run
cities-internet/connectivity-map.meta.json and
gospel-resources/resources-map.meta.json carry the pinHint:false
opt-out (no 'Tap a coloured dot' on maps with no dots). They were
authored and BUILT INTO the leaf pages but never committed -- a clean
clone would silently regress the fix on its first rebuild.
2026-09-24 00:01:08 +00:00
doxa-maps-88655c70
1cf4e89dab Resolve a composite's child bundles against the tree root, not a guessed depth
Some checks are pending
build-gate / build (push) Waiting to run
Driver-reported console text:
  Could not load <doxa-research-map> from ../../doxa-research-map/doxa-research-map.js

A composite declares children as src: '../../<bundle>/<bundle>.js'. That literal
is right from a one-deep leaf and wrong from a two-deep one, and the generator
emits both:
  .../research-map-plus-grid/index.html          ../../ -> /doxa-maps/          200
  .../research-map-plus-grid/default/index.html  ../../ -> /doxa-maps/rmpg/     404

So the path encoded an assumption about the host's depth that the host does not
control and cannot see. It survived because every gate exercised the shallow
leaf, which is genuinely fine.

StackLayout now derives the tree root from the document's own pathname (up to
and including the /doxa-maps/ segment) and rebuilds the path from there --
depth-independent by construction, so a third leaf depth cannot reintroduce it.
Absolute, protocol-relative and root-relative srcs pass through untouched, and
a missing /doxa-maps/ segment returns the original string, so this can only fix
a path, never break a working one.

Measured, both leaves, real browser with live data:
  one-deep  mapEl=true mapH=792 canvasH=856 0 4xx
  two-deep  mapEl=true mapH=792 canvasH=856 0 4xx   (was 404, map absent)

Also carries source that had been left behind by its own built output:
the cities/gospel legend bounding (shipped in 5008a6f as output only) and the
per-profile config carrier in generate-tree.mjs, plus a new fits-screen clause
that wheels inside every column rather than one.
2026-09-23 19:34:28 +00:00
doxa-maps-88655c70
bd2a77e82d Resolve the shared asset base per bundle, so nested tabs stop 404ing
Eleven profiles across six bundles each carried the same line:

    profileConfig?.assetsBase || './assets'

That default is right on a standalone leaf page, where the generated host passes
'../../assets' and the tree root is two segments up. It is wrong the moment the
element is nested in the cap-5 shell, because a relative path resolves against
the SHELL's page, not the child's. Measured in a browser on the built tree:

    leaf  /doxa-maps/gospel-resources/resources-map/index.html ... 0 failed
    shell /doxa-maps/doxa-maps-spa/doxa-maps-spa/index.html ...... 404 assets/tables/gospel-by-country.json
                                                                   404 assets/boundaries/world-adm0.geojson

No build-time gate could see it: './assets' is a valid string in both hosts, and
only the host decides what it resolves to. check-composite-srcs proves a nested
src exists on disk, which is a different question.

resolveAssetsBase() in library/utils/embedBase.js now derives an absolute base
from the bundle's own script URL (or the treeBase the shell already forwards),
and deliberately REJECTS a relative assetsBase from config -- honouring it would
reintroduce the defect through the config meant to cure it.

The fix is in the child, not the shell, so a new bundle that fetches assets
works nested on day one with no edit to doxa-maps-spa.vue.

Verified: shell 404s 2 -> 0 on Gospel Resources; Cities & Internet, UPG-100 and
Big Picture also 0 asset 404s; leaf hosts unchanged at 0.
2026-09-23 12:14:52 +00:00
doxa-maps
344c4dc831 Describe every plugin: 15 of 26 profiles shipped with no description
Some checks are pending
build-gate / build (push) Waiting to run
More than half the catalog had an empty description in manifest.json, so the
plugin-studio — the surface a Doxa inheritor browses to learn what exists —
showed flagship plugins as a bare "bundle - <tag>" with no explanation, while
a demo bundle explained itself fully.

Cause: the generator reads a JSDoc @description TAG, and these files carried
only prose. Every description added here is a summary of what that file's own
header already documented, not new invention. Claims were checked against the
artifacts: doxa-simple-map's "three presets" was verified against
simple-map.instances.json (prayer, engagement, adoption).

The two cap-5 shells needed a second pass. Their headers are HTML comments
with no leading asterisk, and the real TAG_RE requires `* @tag value`, so the
first attempt extracted nothing.

Result: 26/26 profiles described, 0 empty; the built gallery went from 15
empty / 11 populated to 0 / 26. Verified in a browser, not just in the
manifest. Embed suite 40/40.
2026-09-22 03:11:07 +00:00
doxa-maps-88655c70
85014aad11 Session work: strobe fix, grid layout, stacked tree legend, selection camera, chip bounding, asset inheritance, gates 2026-09-20 04:49:25 +00:00
doxa-maps-88655c70
2d64e21fbf Complete app-profiles->plugin-designs sweep across comments/docs; build green; layouts kept at root (load-bearing) 2026-09-17 18:18:19 +00:00
doxa-maps-88655c70
1a3925c6a6 Rename app-profiles -> plugin-designs; build green under new naming (load-bearing paths updated, guards pass) 2026-09-17 18:18:18 +00:00