docs(backlog): add phase 10 (OpenZaak hardening) and phase 11 (behandelportal)

WP-55..60 harden the OpenZaak integration for production (secrets/TLS, idempotent provisioning, least-privilege scopes, real notifications, confidentialiteit config, write-divergence resilience). WP-61..66 stand up a staff-facing behandelportal per ADR-0002, wired to the same backend via BFF-lite decision DTOs. Both phases are independent tracks; WP-60's Decisions block is deliberately left open for a planner-agent kickoff. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-30 11:59:11 +02:00
parent 66f8125ccd
commit f21c3c7ca2
13 changed files with 840 additions and 0 deletions
@@ -0,0 +1,72 @@
+# WP-65 — Behandelportal: zaak detail + beoordeling (decision) screen
+
+Status: todo
+Phase: 11 — Behandelportal
+
+## Why
+
+The core case-treatment write path — a medewerker opens one aanvraag's detail (including
+its documents) and records a decision (goedkeuren/afwijzen/meer info opvragen), advancing
+the status lifecycle WP-63 published. This is the first genuinely new *write* capability
+in the system beyond what the citizen SSP already does to itself.
+
+## Read first
+
+- `mutation-command` skill
+- `form-machine` skill (the decision action is a state-changing form, same idiom as
+  everywhere else in this house)
+- [WP-63](WP-63-aanvraag-status-lifecycle.md) (the status field being advanced)
+
+## Decisions (pre-made, don't relitigate)
+
+- The decision action is modeled as a `*.machine.ts` (Model/Msg/reduce) + a `submit-*`
+  command returning `Result`, per this house's one-idiom-for-forms rule — not a
+  hand-rolled mutable field.
+- The mutation endpoint is a new BFF-lite write (per `mutation-command` recipe) that
+  transitions the status field from WP-63; it validates the transition is legal
+  server-side (e.g. can't approve an already-approved case) — the backend remains the
+  authority.
+- Runs against `LocalZaakSource` for this slice; wiring the decision into real OpenZaak is
+  explicitly WP-66, not bundled here — keeps this slice's surface to app-level behavior
+  only.
+
+## Files
+
+New mutation endpoint + command in `BigRegister.Api`; `behandeling/ui` detail page +
+`behandeling/application` decision machine in the behandelportal app.
+
+## Steps
+
+1. Backend: mutation endpoint advancing aanvraag status (goedkeuren/afwijzen/meer-info-
+   opvragen), validating the transition.
+2. FE: zaak-detail page (documents + current status) + a decision form machine + submit
+   command.
+3. Wire the werkvoorraad list (WP-64) to link into this detail page.
+4. Storybook stories + a11y for the new detail/decision UI.
+
+## Acceptance criteria
+
+- [ ] A medewerker can view one aanvraag's detail and record a decision that advances its
+      status.
+- [ ] Illegal transitions are rejected server-side (tested).
+- [ ] End-to-end smoke: werkvoorraad → detail → decision → status change reflected back
+      in the queue.
+- [ ] `npm run ci` (behandelportal app) + `dotnet test` green.
+
+## Verification
+
+Manual/automated smoke test of the full werkvoorraad → beoordeling → besluit flow against
+`LocalZaakSource`; `npm run ci`; `cd backend && dotnet test`.
+
+## Out of scope
+
+Writing the decision to real OpenZaak (WP-66).
+
+## Risks
+
+This is the largest FE slice in Phase 11 — if it feels too big at kickoff, split
+detail-view (read) from decision-recording (write) into two sessions; the WP as scoped
+already keeps them in one slice because a detail view with no decision action isn't
+independently useful for a caseworker.
+
+Depends on: WP-64.