8fc7e2d62a
useDashboardLayout is the second zero-domain piece: it imports nothing but `vue` and reads no row. The four mentions of a people-groups grid in it are comments naming an example of what a host stacks underneath. Body verbatim apart from the one change the spec required before it could be shared, and the same one-cycle re-export at the old path. THE KEY WAS THE REASON THIS COULD NOT JUST BE MOVED. The engine persists the four divider positions to localStorage under a single constant, so every dashboard wrote to the same slot. That was invisible while there was exactly one dashboard — and SHARING THE ENGINE IS PRECISELY WHAT MAKES A SECOND ONE POSSIBLE. Moving it without fixing this would have shipped a collision into the kit's first reuse: drag a divider in one dashboard, reload, and the other has moved. Nothing errors, neither is wrong on its own, and the reader has no reason to suspect the other element on the page. SPEC-DASHBOARD-KIT section 8 named it as this landing's risk; the fix belongs in the commit that shares the engine, not in the one that first trips over it. The key now carries the profile's own id, so a second dashboard gets its own slot without its author knowing this key exists. AND NAMESPACING MUST NOT SILENTLY DISCARD A LAYOUT. Every reader who has dragged a divider has a value under the old shared key; a new key would simply orphan it and reset them for no reason they could see. The engine reads the old key once when the new one is absent. It never writes or deletes it: a migration that also deletes cannot be rolled back, and leaving the old value costs one localStorage entry. check:layout-key-namespaced guards all three. It EVALUATES the storageKey expression the shell actually passes, with two different dashboard ids, rather than retyping the rule — a gate carrying its own copy of the thing it checks passes while the product is broken, which is the lesson from check:linked-vocabulary. Negative-tested: a bare literal fails A, an expression that ignores the id fails B, and writing or removing the legacy key fails C. ★ THE BUS_SRC LESSON WAS APPLIED BEFORE MOVING, NOT AFTER. Landing 1 nearly disarmed check:facet-cascade because that gate reads its subject from a path. I checked first this time: no gate reads useDashboardLayout by path, and the storage-key literal appears in exactly two places, both of them in this diff. The library index is regenerated here, per landing, for the same reason as landing 1 — 101 items now. SOURCE ONLY. Stacked on D1. STUDIO: needs a rebuild of research-dashboard and dashboard-plus-grid. package.json is the parent's copy plus two lines beside check:leaf-engine-per-provider, so D1's registration is preserved. |
||
|---|---|---|
| .. | ||
| api | ||
| colors | ||
| components | ||
| composables | ||
| constants | ||
| data | ||
| i18n | ||
| layouts | ||
| lists | ||
| maps | ||
| packet | ||
| scripts | ||
| stores | ||
| styles | ||
| utils | ||
| index.js | ||
| ProfileLoader.vue | ||
| README.md | ||
library/ (@map) — the shared map template
The other half of the architecture (see ../plugin-designs/README.md):
every map in plugin-designs/<your-map>/ composes the reusable, parameterized pieces that live here.
Fix something here and every map benefits on the next build; break something here and every map
breaks — read components/WARNING.md before touching shared pieces.
| Folder | What lives there |
|---|---|
ProfileLoader.vue |
The root of every bundle: parses profile-config, loads the profile, provides the stores + config |
components/ |
Shared UI — map, legends, controls, popup (PeopleGroupDetail), tables, charts, hints (README) |
composables/ |
Shared logic — map engine (useMapInstance), provider switch, shadow-DOM styles, theming |
stores/ |
Per-instance Pinia stores (ui / map / data) — provided by ProfileLoader, injected by children |
api/ |
Data-source registry (sources.json) + fetch layer — the JAMstack runtime wiring |
colors/ |
Color sets maps opt into via profile-config.colorSet |
i18n/ |
The shared string catalogs (all maps speak the same languages) |
data/ |
Small shared datasets baked at build time (big served data lives in ../data/) |
constants/ |
Shared constants |
scripts/ |
Maintainer pipelines (posters, research) — not part of any bundle |
The rule of thumb (same as WARNING.md): custom code in your app-profile, reusable code here — and things only move from the first to the second once they've earned it.