ConductionNL · rubenvdlinde · Sep 3, 2026 · Sep 2, 2026 · Sep 2, 2026 · Sep 2, 2026
@@ -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.

@@ -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**
 

@@ -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**
 

@@ -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

@@ -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
 

@@ -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