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>
66 lines
2.4 KiB
Markdown
66 lines
2.4 KiB
Markdown
# WP-64 — Behandelportal: werkvoorraad (queue) screen
|
|
|
|
Status: todo
|
|
Phase: 11 — Behandelportal
|
|
|
|
## Why
|
|
|
|
First real screen in the new app — a read-only list of aanvragen needing treatment (the
|
|
"werkvoorraad"), gated by the medewerker identity from WP-62 and backed by the real status
|
|
DTO from WP-63. This is the smallest useful vertical slice of actual case-treatment
|
|
functionality — usable and demoable on its own, even before any decision can be recorded
|
|
(WP-65).
|
|
|
|
## Read first
|
|
|
|
- WP-61/62/63 outcomes
|
|
- `bff-endpoint` skill (screen-shaped decision DTO recipe)
|
|
- `src/app/registratie/ui/admin-cases.page.ts` (the existing cross-owner list, for what
|
|
to avoid repeating — that page is audit/delete, this one is a queue)
|
|
|
|
## Decisions (pre-made, don't relitigate)
|
|
|
|
- New BFF-lite endpoint (decision-enriched DTO) shaped for a werkvoorraad screen — not a
|
|
reuse of the existing `/admin/cases` endpoint, which is audit-shaped, not queue-shaped
|
|
(per CLAUDE.md's per-screen endpoint discipline).
|
|
- Gated by the `canBeoordelen`-style capability from WP-62, not a new ad hoc role check.
|
|
- Domain first, then infrastructure, application, UI — per the house `new-feature`
|
|
recipe.
|
|
|
|
## Files
|
|
|
|
New backend endpoint + DTO in `BigRegister.Api`; new `behandeling` context in the
|
|
behandelportal app (domain/infrastructure/application/ui per the house layering).
|
|
|
|
## Steps
|
|
|
|
1. Backend: new screen-shaped endpoint returning aanvragen needing treatment
|
|
(status = `InBehandeling`/`Ingediend`), gated by WP-62's capability.
|
|
2. FE: scaffold the `behandeling` context (domain → infrastructure → application → ui),
|
|
following `new-feature`.
|
|
3. UI: a list page (queue), composed from the shared `shared/ui` kernel — no new atoms
|
|
unless nothing existing fits.
|
|
4. Storybook story for the new list component/page, a11y-checked.
|
|
|
|
## Acceptance criteria
|
|
|
|
- [ ] Werkvoorraad screen lists aanvragen needing treatment for an authenticated
|
|
medewerker.
|
|
- [ ] `npm run ci` green in the behandelportal app; Storybook story present.
|
|
- [ ] Endpoint follows BFF-lite discipline (decision-enriched, not raw passthrough).
|
|
|
|
## Verification
|
|
|
|
`npm run ci` in the behandelportal app; `cd backend && dotnet test`; manual: log in as a
|
|
stub medewerker, see the queue populated from seeded aanvragen.
|
|
|
|
## Out of scope
|
|
|
|
Viewing a single zaak's detail (WP-65); recording any decision (WP-65).
|
|
|
|
## Risks
|
|
|
|
None major — this is a read-only composition slice once WP-61-63 exist.
|
|
|
|
Depends on: WP-61, WP-62, WP-63.
|