Files

T

ehoandClaude Sonnet 5 f21c3c7ca2 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

2.8 KiB

Raw Blame History

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

Backend: mutation endpoint advancing aanvraag status (goedkeuren/afwijzen/meer-info- opvragen), validating the transition.
FE: zaak-detail page (documents + current status) + a decision form machine + submit command.
Wire the werkvoorraad list (WP-64) to link into this detail page.
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.

2.8 KiB Raw Blame History