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.5 KiB

Raw Blame History

WP-61 — Bootstrap the behandelportal app

Status: todo Phase: 11 — Behandelportal

Why

ADR-0002 already designed the Behandelaar/backoffice as a separate sibling frontend app, not a folder in this repo. Nothing exists yet — /beheer/zaken is confirmed to be only a cross-owner list+delete, no treatment workflow. The new-ssp skill exists precisely to bootstrap a new portal from this template; this slice is running that recipe for real, with no business context yet — an empty, correctly-scaffolded shell.

Read first

.claude/skills/new-ssp/SKILL.md
ADR-0002 — user groups & bounded contexts
ADR-0001 — BFF-lite decision DTOs

Decisions (pre-made, don't relitigate)

Follow new-ssp's own "keep vs. strip" checklist as-is: keep the shared/ui kernel, tooling/CI gates, ADRs 0001-0003; strip the four citizen contexts and citizen branding.
The new app talks to the same BigRegister.Api backend — no new backend service (confirmed by ADR-0002: contexts integrate through the backend).
Repo layout for the new app (separate repo vs. a second app in this monorepo) — decide at kickoff based on how new-ssp is meant to be invoked.

Files

Whatever new-ssp's recipe touches (new app root, package.json, shared/ui copy or workspace reference, CI config) — enumerate at kickoff by following the skill.

Steps

Run the new-ssp bootstrap per its own checklist.
Confirm the known un-genericizable rough edges it flags (shared/ui/debug-state/, the /dashboard route) are handled per the skill's own guidance (delete / TODO stopgap) rather than re-solved from scratch.
Land an empty landing/login page only — no behandeling context yet (that's WP-64+).
Get the new app's own CI green.

Acceptance criteria

New app boots and its own npm run ci is green.
No citizen-facing business context (registratie, herregistratie, brief, showcase) present.
Points at the same backend (BigRegister.Api) as this repo, no new backend stood up.

Verification

npm run ci in the new app; manual smoke — app loads to an empty shell page.

Out of scope

Any behandeling screens (WP-64/65), identity (WP-62), status lifecycle (WP-63).

Risks

new-ssp's own docs already name its rough edges (debug-state, /dashboard) — budget time for those rather than being surprised by them.

2.5 KiB Raw Blame History