Files
atomic-design-poc/docs/project/backlog/WP-64-behandelportal-werkvoorraad.md
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.4 KiB

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.