7e04a94c34
The rail's rendering is unchanged. What changed is where its last two plugin imports point. 4b had already removed the research COLOUR and LABEL tables -- those stay in plugin-designs and arrive on dashboardConfig.legend -- which left exactly two, and both now read the module that OWNS the function rather than a re-export: useDashboardAggregations -> @map/composables/useFacetAggregation.js (extracted by 4c-1) useDashboardShell -> @map/composables/useDashboardSearch.js (extracted by 4a) Pointing at the shim instead would have been invisible and wrong in a way this tree has already measured: check:filter-multivalue carries the note from landing 3 that a gate left at the plugin path read the shim, found no predicate to object to, and PASSED VACUOUSLY. The dead injects go too. `dataStore` and `searchSourceId` were here only to construct useTreeLegendColors and useTreeLegendLabels, and 4b removed both constructions. An unused inject is a claim about the host: a kit component that appears to need a research dataStore is one a new dashboard will dutifully provide before finding out it was never read. The chip bar shed the same pair in 4c-2. check:filter-multivalue and check:legend-mirrors follow the file rather than being left pointing at a path that no longer exists -- the multivalue gate fails loudly on a missing panel, which is what it is for, and it is how I would have caught forgetting. UNLIKE THE CHIP BAR, THIS ONE IS ON SCREEN. 4c-2's component is mounted by nobody, so its gate was the whole story. The rail is mounted by research-dashboard.vue and is 770 lines of tree, search and drag behaviour: "the imports resolve" says nothing about whether it still opens four trees by default or whether its search still narrows. It needs eyes. The barrel re-exports from the library for one cycle, so no importer's line changes in the same landing that moves the file. documentation/reference-library-index.md regenerated. |
||
|---|---|---|
| .. | ||
| architecture | ||
| assets | ||
| contributing | ||
| needs-eyes | ||
| readme-images | ||
| screenshots | ||
| CONTRIBUTING.md | ||
| develop-a-plugin-and-see-it-live.md | ||
| explanation.md | ||
| how-to.md | ||
| README-embed-example.md | ||
| README-embed-gospel-resources.md | ||
| README-SECTION-3-cli-commands.md | ||
| README.md | ||
| reference-capability-exemplars.md | ||
| reference-library-index.md | ||
| reference-universal-props.md | ||
| reference.md | ||
| tutorial.md | ||
| vendored-font-noto-serif-devanagari.md | ||
| why.md | ||
documentation/ — pick your path
"what is this?" "teach me" "how do I …?" "look it up" "all the detail"
│ │ │ │ │
why.md ──────────► tutorial.md ────► how-to.md ────► reference.md ───► architecture/
(2 min, 1 diagram) (first map) (task recipes) (tables) (contracts)
- why.md — the problem and the "map islands" idea. Start here.
- tutorial.md — build your first map, no jargon.
- how-to.md — recipes: embed, iframe, SPA, colors, CDN, mobile, tokens.
- reference.md — config fields, build scripts, the
profile-configcontract. - explanation.md — the model in 15 lines.
- architecture/ — the deep end: full contracts, the per-file catalog.
- README-embed-example.md — the drop-in README used when this bundler is embedded inside a host repo.
- README-embed-gospel-resources.md — the gospel map's URL contract for partner embeds: bring your own ISO 639-3 list, one country, one group, or the zero-access view.
Working on the repo:
- develop-a-plugin-and-see-it-live.md — ★ the golden path: zero to a plugin live, in 6 steps.
- README-SECTION-3-cli-commands.md — every command, per deployment method, with prerequisites.
- reference-capability-exemplars.md — which bundle is at which capability tier (generated).
- reference-library-index.md — the reusable
library/pieces you can import (generated). - CONTRIBUTING.md and contributing/ — how to contribute, and the bar for
library/.
Nothing on the simple path is longer than a few minutes; everything complex lives in
architecture/, linked from where you'd need it.