Skip to content

Commit 91771c1

Browse files
authored
Merge pull request #874 from ConductionNL/fix/procest-gate53-removals-replaced-by
fix(menu): declare where six retired nav surfaces went — and refuse the seventh (gate-53)
2 parents e0532d4 + 357e384 commit 91771c1

1 file changed

Lines changed: 9 additions & 1 deletion

File tree

‎src/menu-layout.json‎

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,15 @@
33
"spdx-license": "EUPL-1.2",
44
"spdx-copyright": "2026 Conduction B.V.",
55
"description": "Canonical navigation layout applied AFTER all manifest.d fragments merge (see applyMenuRelocations in main.js). Fragments stay the source of WHAT exists in the menu (ADR-037); this file is the single place deciding WHERE entries live. relocations: sourceId -> targetGroupId (groups dissolve into the target, leaves move under it). removals: leaf menu-entry ids retired as duplicate navigation — their PAGES stay routable for deep links and e2e specs. settingsSection: top-level config/definition/admin ids lifted into Nextcloud's settings foldout (NcAppNavigationSettings gear, outside the scrollable nav) — see applySettingsSection in main.js; operational/report/dashboard items stay in the main nav.",
6-
"removalsCoverageNote": "The 8 entries in `removals` (BezwaarBeroepGroup, Bezwaren, Beroepen, SubsidiesGroup, CaseMap, Voorstellen, Advice, BesluitvormingAgenda) each orphan their route under the static top-level `.menu` tree gate-53 (effective-manifest-crossref) inspects — deliberately, per two sequential, documented architecture changes: (1) `case-type-navigation` (commit d6824aa20) replaced the standalone Bezwaar/Beroep/Subsidie nav with case-type children resolved dynamically onto the `Cases` page's own `folderSidebar`, and gave `Cases` a `map` viewMode superseding the standalone `CaseMap` leaf; (2) `consume-decidesk-besluitvorming-leaf` (commit d2df51b8b) replaced the standalone Besluitvorming nav (Voorstellen/Advice/Agenda) with a `BesluitvormingLeafTab` sidebar tab on `CaseDetail`. Both replacements are live, wired, and menu-reachable via `Cases`/`CaseDetail` — but gate-53 only walks the static `.menu` tree and cannot see a runtime folderSidebar filter, a page viewMode, or a per-object sidebar tab as 'reachability'. Restoring these as static top-level entries would reintroduce the exact anti-pattern both changes explicitly rejected (hard-coding the case-type taxonomy into the bundled manifest; duplicating the decision surface across two apps). Retiring the ROUTES instead would violate each change's own explicit ADR-044 'hard invariant' to keep them deep-link/e2e routable. Left red pending a gate-53 enhancement that recognises folderSidebar/viewMode/sidebarTab reachability."
6+
"removalsCoverageNote": "Of the 8 entries in `removals`, ONE needs no waiver: `Voorstellen` is reachable because `CaseDetail`'s `case-voorstellen` widget carries `viewAllRoute: /voorstellen`, which gate-53 follows as a real navigation edge. SIX are waived in `removalsReplacedBy` above. ONE (`BesluitvormingAgenda`) is deliberately NOT waived and stays a live gate-53 finding — see the end of this note. The six waivers rest on two documented architecture changes, and each was re-verified against the ASSEMBLED manifest rather than taken from this note's earlier prose. (1) `case-type-navigation` (commit d6824aa20) replaced the standalone Bezwaar/Beroep/Subsidie nav with case-type children resolved dynamically onto the `Cases` page's `folderSidebar`. Measured: `Bezwaren`, `Beroepen` and `Subsidies` are each `type: index` over register `procest` / schema `case` whose only narrowing is `filter: { caseType: <uuid> }`, and `Cases` is the same register/schema with `folderSidebar.filterField: caseType` sourced from the `caseType` schema — so picking that folder on `Cases` produces the same rows the retired page produced, the same filter field over the same data rather than an approximation. `BezwaarBeroepOverview` is a card grid whose own `_note` already records that objections/appeals are case types under Cases. `CaseMap` is superseded by `Cases`' `viewModes: [table, cards, map]` plus `mapConfig`; the retired page's full-screen split layout is a presentation difference and its case-type filter sidebar is the `folderSidebar`. (2) `consume-decidesk-besluitvorming-leaf` (commit d2df51b8b) moved decision-making to decidesk, surfaced in procest as the `besluitvorming` sidebar tab (`BesluitvormingLeafTab`) and the `case-decidesk-decisions` widget on `CaseDetail`. `Advice` was an index over schema `adviesAanvraag`; per-case advice now reaches the user through that leaf, so `CaseDetail` is its replacement inside procest, while the CROSS-CASE advice queue is decidesk's by design because procest no longer owns that model. NOT WAIVED, ON PURPOSE: `BesluitvormingAgenda` (route `AgendaCompiler`). Its page is a bespoke meeting-agenda compiler — it assembles a meeting agenda from selected proposals with drag-ordering and section grouping — which is a cross-case, meeting-level surface. `CaseDetail` does not carry it: a string walk of the assembled manifest finds `agenda` / `vergadering` / `meeting` on exactly two pages, `AgendaCompiler` and `VergaderingDetail`, both themselves off the menu, and on no widget or sidebar tab of `CaseDetail`. Naming `CaseDetail` here would make `removalsReplacedBy` assert something untrue, and the gate cannot catch that — it verifies the named page exists and is reachable, never that it does the job. The agenda compiler moved to decidesk, which `removalsReplacedBy` cannot name because it only resolves ids within this app's own manifest. So this one stays RED: one true finding, rather than a green gate carrying a false claim. Closing it needs a product decision — either surface decidesk's agenda in procest, or retire the route."
7+
},
8+
"removalsReplacedBy": {
9+
"BezwaarBeroepGroup": "Cases",
10+
"Bezwaren": "Cases",
11+
"Beroepen": "Cases",
12+
"SubsidiesGroup": "Cases",
13+
"CaseMap": "Cases",
14+
"Advice": "CaseDetail"
715
},
816
"relocations": {
917
"MyWork": "WorkGroup",

0 commit comments

Comments
 (0)