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
parent 66f8125ccd
commit f21c3c7ca2
13 changed files with 840 additions and 0 deletions
@@ -0,0 +1,73 @@
+# WP-56 — Idempotent catalogus provisioning
+
+Status: todo
+Phase: 10 — OpenZaak production hardening
+
+## Why
+
+`backend/openzaak/bootstrap-catalogus.sh` seeds catalogus/zaaktype/statustype/roltype/zaak
+via hand-rolled curl+JWT and is explicitly **not idempotent** (fails on `domein`+`rsin`
+uniqueness on rerun) — fine for a one-shot WP-54 harness, wrong for an environment that
+needs to be rebuildable. OpenZaak already ships a documented, scripted alternative — the
+`setup_configuration` mechanism (already used in the harness for the JWTSecret/Applicatie,
+see `setup_configuration/data.yaml`) — this WP extends that same mechanism to the catalogus
+content too.
+
+## Read first
+
+- `backend/openzaak/bootstrap-catalogus.sh`
+- `backend/openzaak/setup_configuration/data.yaml`
+- `backend/openzaak/docker-compose.openzaak.yml` (`web-init` service)
+- OpenZaak's own `setup_configuration` / `openzaak_config_cli` docs (upstream)
+
+## Decisions (pre-made, don't relitigate)
+
+- Move catalogus/zaaktype/statustype/roltype provisioning into `setup_configuration`,
+  run by the existing `web-init` one-shot service, instead of the separate curl script.
+- Keep `bootstrap-catalogus.sh` only for whatever content `setup_configuration` genuinely
+  can't express (e.g. a demo zaak instance) — confirm what's left at kickoff.
+- Provisioning must be safe to run against an already-provisioned instance — either
+  genuinely idempotent, or the compose is structured to only run it once per fresh
+  volume (document which, don't leave it ambiguous).
+
+## Files
+
+- `backend/openzaak/setup_configuration/data.yaml`
+- `backend/openzaak/bootstrap-catalogus.sh` (trim to whatever remains)
+- `backend/openzaak/docker-compose.openzaak.yml`
+- `backend/openzaak/README.md`
+
+## Steps
+
+1. Express the catalogus/zaaktype/statustype/roltype definitions currently created by
+   curl as `setup_configuration` YAML.
+2. Wire it into the `web-init` command alongside the existing JWTSecret/Applicatie config.
+3. Trim `bootstrap-catalogus.sh` to only what setup_configuration can't cover, if anything.
+4. Test: tear down + `docker compose up` twice in a row (fresh volume, then existing
+   volume); confirm no failure on rerun.
+5. Update the README describing the provisioning flow.
+
+## Acceptance criteria
+
+- [ ] Catalogus/zaaktype/statustype/roltype provisioning is declarative
+      (`setup_configuration`), not imperative curl.
+- [ ] Running the compose stack up twice in a row doesn't error.
+- [ ] WP-54's `OpenZaakIntegrationTests` still pass unchanged (same content, different
+      provisioning mechanism).
+
+## Verification
+
+`docker compose -f backend/openzaak/docker-compose.openzaak.yml up` twice in a row (fresh
+volume, then existing volume); `cd backend && dotnet test --filter Category=Integration`
+against the harness.
+
+## Out of scope
+
+Secrets/TLS (WP-55, unrelated but sequenced first in the table only by number), client
+scopes (WP-57), notifications (WP-58).
+
+## Risks
+
+OpenZaak's `setup_configuration` coverage for zaaktype/besluittype content may be
+incomplete upstream — if a piece genuinely can't be expressed declaratively, keep it in a
+clearly-labeled idempotent script rather than forcing a bad fit.