refactor(nav): retire five superseded pages instead of only hiding them (#1682)

* refactor(nav): retire five superseded pages instead of only hiding them

`removals` in src/menu-layout.json hid a menu entry and left the page routable.
For five entries the page had nothing left to show, so this deletes the page
rather than the link to it, and the array drops to 9.

Bezwaren and Beroepen were each an index over register dossiq and schema case
narrowed only by filter.caseType, and both narrowed on case types sitting under
_caseTypes_disabled in lib/Settings/bezwaar_seed_data.json, so both listed zero
rows in every install. Cases carries the same register, the same schema and the
same field through folderSidebar.filterField. complaints-bezwaar.spec.ts had
been describe.fixme on exactly that ground since procest#675.

Advice was an index over adviesAanvraag, a model decidesk has owned since
consume-decidesk-besluitvorming-leaf. Parafeerroutes was the design screen for
approval routes, which dossiq#1632 turned into flows, so editing there reached
nothing that runs. Both detail routes stay registered: /advice/:id and
/settings/parafeerroutes/:id keep resolving, and so does the audit context that
names parafeerrouteId.

BezwaarBeroepOverview goes with them. Its four cards pointed at Bezwaren,
Beroepen, BezwaarDecisions and BezwaarAdviceRequests; the last two were already
retired by case-type-navigation, so every card on the page resolved to nothing.
Its change proposal is marked superseded rather than rewritten.

BesluitvormingAgenda leaves the array as a stale entry matching no merged menu
entry, which is what gate-53 had been reporting.

CaseMap and SubstitutionAdminMenu stay hidden rather than deleted, and the
coverage note now records why. Both pages are type: custom, which means the
standard types cannot host what they do, so a waiver naming Cases covers where
the user lands and not what they can do there. Cases carries one of
SubstitutionAdmin's five capabilities, and its own _note says the standard list
type cannot host the others. The three Reports waivers stay for the opposite
reason: the Reports page's cards route straight at those pages.

Also declares requiredApp on the case-kpis-hours widget, which reads register
humaniq without it (gate-55, pre-existing on development).

* style(registry): drop the blank line left by removing the BezwaarBeroepOverview entry

Removing that registry block left the object literal opening on a blank line,
which prettier --check rejects. Whitespace only.

---------

Co-authored-by: Conduction Release Bot <release-bot@conduction.nl>

Author: rubenvdlinde

openspec/changes/bezwaar-beroep-cards-collapse/proposal.md

@@ -1,5 +1,16 @@
 # Proposal: bezwaar-beroep-cards-collapse
 
+> **SUPERSEDED 2026-09-02.** The landing page this change delivered
+> (`BezwaarBeroepOverview`, route `/bezwaar-beroep`) has been deleted, along with
+> its manifest fragment, its Vue component and its registry entry. Every one of
+> its four cards had stopped resolving: `BezwaarDecisions` and
+> `BezwaarAdviceRequests` were retired by `case-type-navigation`, and `Bezwaren`
+> and `Beroepen` were retired as pages on 2026-09-02 because each was an index
+> over register `dossiq` and schema `case` narrowed by a `caseType` that sits
+> under `_caseTypes_disabled`, so both listed nothing. Objections and appeals are
+> case types on `Cases`. Their detail routes `/bezwaren/:id` and `/beroepen/:id`
+> stay registered. Read this file as history, not as a description of the app.
+
 ## Summary
 
 Collapse the **Bezwaar & Beroep** group (`BezwaarBeroepGroup`) in the dossiq navigation into a single top-level menu item that links to a new card-grid landing page. Each of the four former child leaves (`Bezwaren`, `Beroepen`, `BezwaarDecisions`, `BezwaarAdviceRequests`) is rendered as a card on that landing page. All former leaf page routes remain registered and reachable as deep links; only the navigation nesting changes. This change follows the ADR-044 "Menu architecture" cards-collapse rule.

openspec/specs/advice-management/spec.md

@@ -12,22 +12,21 @@ Advice management lets behandelaars request, track, and process internal and ext
 
 ## Requirements
 
-**Advice Page Render (UI surface)**
-
-### Requirement: Advice index page render
-
-The Advice (adviezen) index page (`CnIndexPage`, route `/advice`) SHALL mount and
-render its stable list shell on navigation — the Cards/Table view toggle, an "Add"
-create button, a per-row "Actions" control, and an empty-state message when no
-advice requests are visible — independently of whether the OpenRegister collection
-returns rows.
-
-#### Scenario: Advice index page renders list shell
-- **GIVEN** an authenticated user on the Dossiq app
-- **WHEN** they navigate to the Advice page
-- **THEN** the Cards/Table view-mode toggle MUST be visible
-- **AND** an "Add" create button MUST be visible
-- **AND** the page MUST NOT show an Internal Server Error
+**Advice surface (UI surface)**
+
+### Requirement: Advice surface
+
+Per-case advice SHALL reach the user through the `besluitvorming` leaf on
+CaseDetail and the `case-decidesk-decisions` widget. `/advice/:id` SHALL stay
+registered so every advice detail link keeps resolving.
+
+REPLACED 2026-09-02. The standalone `/advice` index page is retired, not hidden.
+`consume-decidesk-besluitvorming-leaf` moved decision-making to decidesk, which
+owns the `adviesAanvraag` model and the CROSS-CASE advice queue by design. dossiq
+keeps the per-case view and the detail route. A dossiq-side list over a model
+dossiq no longer owns is the duplication that change set out to remove.
+
+@e2e exclude The per-case surface is covered by the besluitvorming leaf specs; the cross-case queue is decidesk's and is not a dossiq surface to test.
 
 **ADDED Requirements**
 

openspec/specs/bezwaar-lifecycle/spec.md

@@ -12,22 +12,23 @@ Defines the end-to-end bezwaar (objection) lifecycle: the pre-seeded Bezwaar cas
 
 ## Requirements
 
-**Bezwaren Page Render (UI surface)**
-
-### Requirement: Bezwaren index page render
-
-The Bezwaren (objections) index page (`CnIndexPage`, route `/bezwaren`) SHALL mount
-and render its stable list shell on navigation — the Cards/Table view toggle, an
-"Add" create button, a per-row "Actions" control, and an empty-state message when
-no objection cases are visible — independently of whether the OpenRegister
-collection returns rows.
-
-#### Scenario: Bezwaren index page renders list shell
-- **GIVEN** an authenticated user on the Dossiq app
-- **WHEN** they navigate to the Bezwaren page
-- **THEN** the Cards/Table view-mode toggle MUST be visible
-- **AND** an "Add" create button MUST be visible
-- **AND** the page MUST NOT show an Internal Server Error
+**Bezwaren list surface (UI surface)**
+
+### Requirement: Bezwaren list surface
+
+Objections SHALL be listed on the Cases page, narrowed to the Bezwaar case type.
+`/bezwaren/:id` SHALL stay registered so every objection detail link keeps
+resolving.
+
+REPLACED 2026-09-02. The standalone `/bezwaren` index page is retired, not hidden.
+It was an index over register `dossiq` and schema `case` whose only narrowing was
+`filter: { caseType: <bezwaar> }`. Cases carries the same register and the same
+schema, and narrows the same field through its `folderSidebar`
+(`filterField: caseType`). Picking the Bezwaar folder returns the rows the retired
+page returned, so this is the same query on the same data rather than an
+approximation.
+
+@e2e exclude The list shell is covered by `case-management/spec.md#cases-index-page-renders-list-shell`, which drives the same `CnIndexPage` over the same register and schema.
 
 **ADDED Requirements**
 

openspec/specs/dossiq-config-to-settings/spec.md

@@ -85,14 +85,20 @@ Neither SHALL be added to the `SettingsGroup` relocations.
 ### Requirement: REQ-PCTS-004 — Relocated Pages Stay Routable
 
 Every page whose nav leaf is relocated SHALL remain reachable by its existing route after the change.
+
+AMENDED 2026-09-02. One exception: the `/settings/parafeerroutes` INDEX page is retired outright.
+dossiq#1666 moved parafering to the decision app and retired the local engine, so the design screen
+invited edits that reach nothing that runs. `/settings/parafeerroutes/:id` stays registered, so a
+reader can still open a legacy route object, and the audit context naming `parafeerrouteId` keeps
+resolving.
 dossiq SHALL NOT change any page `id`, `route`, `type` or `component` as part of this relocation; the
 change SHALL touch only the menu structure (`src/manifest.json#menu`, `src/menu-layout.json`) and the
 `Legesberekeningen` section flag.
 
 #### Scenario: Deep links to relocated config pages still resolve
 
 - **GIVEN** the configuration leaves have been relocated under `SettingsGroup`
-- **WHEN** a user navigates directly to `/settings/tenants`, `/settings/parafeerroutes`,
+- **WHEN** a user navigates directly to `/settings/tenants`, `/settings/parafeerroutes/:id`,
   `/settings/wms-layers`, `/settings/workflow-definitions`, `/settings/automatic-actions`,
   `/settings/lhs-matrices`, `/legesverordeningen`, `/tenant-onboarding`, `/leges/verordeningen` or `/settings`
 - **THEN** each route SHALL resolve to its existing page

openspec/specs/objections-appeals-nav-group/spec.md

@@ -56,18 +56,26 @@ contiguous run (`Bezwaren`=45, `Beroepen`=46, `BezwaarDecisions`=47, `BezwaarAdv
 
 ### Requirement: REQ-POAG-003 — Every Grouped Page Stays Routable (Relocation Moves The Entry, Not The Page)
 
-dossiq SHALL keep every objections-and-appeals page routable at its existing route after the
-grouping. Relocation SHALL move only the menu entry; the `pages[]` declarations and their routes —
-`/bezwaren` (+`/bezwaren/:id`), `/beroepen` (+`/beroepen/:id`), `/bezwaar-decisions`
-(+`/bezwaar-decisions/:id`), `/bezwaar-advice-requests` (+`/bezwaar-advice-requests/:id`),
-`/settings/bezwaar-committees` (+`/settings/bezwaar-committees/:id`) — SHALL remain registered and
-reachable by direct URL and e2e specs. No page SHALL be added to `src/menu-layout.json#removals`.
+dossiq SHALL keep every objections-and-appeals DETAIL page routable at its existing route.
+Relocation moves only the menu entry, so `/bezwaar-decisions` (+`/bezwaar-decisions/:id`),
+`/bezwaar-advice-requests` (+`/bezwaar-advice-requests/:id`), `/settings/bezwaar-committees`
+(+`/settings/bezwaar-committees/:id`), `/bezwaren/:id` and `/beroepen/:id` SHALL remain registered
+and reachable by direct URL and e2e specs.
+
+AMENDED 2026-09-02. The `/bezwaren` and `/beroepen` INDEX pages are retired outright, not hidden.
+Each was an index over register `dossiq` and schema `case` whose only narrowing was
+`filter: { caseType: <uuid> }`, and Cases carries the same register, the same schema and the same
+narrowing through its `folderSidebar` (`filterField: caseType`). A second list over identical data
+is the duplication this grouping set out to remove, so hiding the entry stopped half way. Detail
+routes stay, so every objection and appeal link keeps resolving. The original clause forbidding a
+`src/menu-layout.json#removals` entry now holds for a different reason: there is no entry left to
+remove.
 
 #### Scenario: Deep links to grouped pages still resolve
 
 - **GIVEN** the grouping has shipped
-- **WHEN** a user navigates directly to `/bezwaren`, `/beroepen`, `/bezwaar-decisions`,
-  `/bezwaar-advice-requests`, or `/settings/bezwaar-committees`
+- **WHEN** a user navigates directly to `/bezwaar-decisions`, `/bezwaar-advice-requests`, or
+  `/settings/bezwaar-committees`
 - **THEN** the corresponding page SHALL load
 - **AND** the page route SHALL be unchanged from before the grouping
 

openspec/specs/parafeerroute-engine/spec.md

@@ -55,18 +55,27 @@ The system SHALL execute parafeerroute steps in sequential order. Each step SHAL
 - **AND** the step 4 actor SHALL receive a Nextcloud notification
 - **AND** the voorstel updatedAt SHALL be refreshed
 
-### Requirement: Admin Parafeerroute Configuration
+### Requirement: Admin parafeerroute configuration
 
-The system SHALL provide an admin UI for creating and managing parafeerroutes. Routes SHALL be linkable to case types and voorstel types.
+Approval routes SHALL be authored in the decision app. dossiq raises a voorstel's
+chain there and records the outcome, and SHALL NOT offer a local authoring surface.
+
+AMENDED 2026-09-02. dossiq#1666 moved the parafering RUNTIME to decidiq and retired
+the local engine with no facade, including the dossiq-side flow projection that
+dossiq#1632 had introduced. So there is no dossiq authoring surface left to keep,
+and the `/settings/parafeerroutes` index page is retired with it: editing a route
+object here would reach nothing that runs. `/settings/parafeerroutes/:id` stays
+registered so a reader can still open a legacy route object, and so the frozen
+`procest.parafering.*` audit trail that names `parafeerrouteId` keeps resolving.
 
 **Feature tier**: V1
 
-#### Scenario: Create a new parafeerroute
+#### Scenario: Create a new approval route
 
-- **WHEN** the beheerder navigates to admin settings and opens the "Parafeerroutes" tab
+- **WHEN** the beheerder authors the approval route in the decision app
 - **THEN** the beheerder SHALL be able to create a new route with a name
 - **AND** the beheerder SHALL be able to add steps with: step type (advies/parafering/accordering), actor type (user/group/role), actor selection, mandatory flag
-- **AND** the beheerder SHALL be able to reorder steps via drag-and-drop
+- **AND** the beheerder SHALL be able to reorder steps on the canvas
 
 #### Scenario: Link route to case type