79e373d7cb
THE GROUP WAS SCHEDULED AS ONE LANDING AND DELIVERED AS TWO. Section 8 of the spec puts the facet rail, the chip bar and the BREADCRUMB in a single landing. The rail moved in 4c-3 and the chips in 4c-2; the breadcrumb was left behind, and nothing failed, because it is mounted by nobody. A leftover like that is invisible unless someone re-reads the spec against the tree, which is what this landing came out of. The breadcrumb gets exactly the inversion the chip bar got: no useTreeLegendLabels import, the resolver read from dashboardConfig.legend, and the SAME unconfigured default — identity, joining an array. Identical on purpose rather than by copy-paste: the breadcrumb and the chips render the same filterSet in the same band, so if their defaults differed a half-configured dashboard would show one value resolved and the other raw, side by side. Its dead `dataStore` / `searchSourceId` injects go too; they existed only to build the composable that is no longer imported. ★ AND THREE ONE-CYCLE SHIMS FROM LANDINGS 2 AND 3 WERE NEVER RETIRED. plugin-designs/research- dashboard/src/composables/ still held useDashboardLayout.js (11 lines), useSelectionCamera.js (11) and useCsvExport.js (14), each a pure re-export of the library module. MEASURED before deleting: ZERO importers. Every consumer — including DashboardMapPanel, DashboardDataTable, DashboardDetailDrawer, useDashboardShell, gospel-internet's board and research-dashboard.vue — already reads '@map/composables/…' directly, and a tree-wide grep for a relative import of any of the three returns nothing. So they were dead code that made the plugin look like it still owned three library modules. I wrote "a one-cycle shim that nobody retires is permanent" into the previous landing's gate comment while three older ones were sitting in the tree unnoticed. They were not found by a gate; they were found by listing what is still in plugin-designs and comparing it against the spec. check:legend-mirrors arm 5 now guards three moved names instead of two, so a re-export of the breadcrumb creeping back into the plugin barrel is caught the same way. Source only. research-dashboard and dashboard-plus-grid need a rebuild. |
||
|---|---|---|
| .. | ||
| charts | ||
| dashboards | ||
| hints | ||
| legends | ||
| map-controls | ||
| poster | ||
| qa | ||
| regions | ||
| search | ||
| tables | ||
| PeopleGroupDetail.vue | ||
| README.md | ||
| ResearchMapFilterPanel.vue | ||
| ResearchMapSideMenu.vue | ||
| SideMenuDrawer.vue | ||
| ViewSelect.vue | ||
| WARNING.md | ||
library/components/ — shared Vue components
The map UI, built from parameterized pieces every app-profile reuses. Fix one here and every map benefits — never edit a shared component to customize one map.
library/components/
┌───────────────────────────────────────────┐
│ legends/ map-controls/ poster/ │
│ charts/ tables/ │
│ PeopleGroupDetail.vue SideMenuDrawer.vue │
│ ResearchMapFilterPanel.vue …SideMenu.vue │
└───────────────────────────────────────────┘
reused by every app-profile via @map/components/…
legends/,map-controls/,poster/each have their own README.- Every component uses
<script setup>, callsuseShadowStyles(), and reaches stores viainject('mapStore' | 'uiStore' | 'dataStore')— never a direct store import.
Full catalog + conventions:
../../documentation/architecture/components.md ·
per-file roles: ../../documentation/reference.md.