ehoandClaude Sonnet 5
f21c3c7ca2
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>
73 lines
2.8 KiB
Markdown
73 lines
2.8 KiB
Markdown
# 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.
|