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,68 @@
+# WP-58 — Real notifications (celery + scripted abonnement)
+
+Status: todo
+Phase: 10 — OpenZaak production hardening
+
+## Why
+
+The WP-54 harness deliberately trims celery/celery-beat/celery-flower and nginx, and sets
+`NOTIFICATIONS_DISABLED: 'true'` — without a Celery worker, OpenZaak 500s and rolls back on
+every write to a notified resource. Fine for a fixture-driven integration harness; a real
+deployment that wants live Notificaties (WP-52's webhook) needs the workers running and the
+`abonnement` (subscription) actually registered against the BFF's public callback URL —
+today that registration step is manual.
+
+## Read first
+
+- `backend/openzaak/docker-compose.openzaak.yml` (top-of-file ponytail note)
+- [openzaak-integration.md](../reference/openzaak-integration.md) (Notificaties section)
+- [WP-52](WP-52-openzaak-notificaties.md)
+
+## Decisions (pre-made, don't relitigate)
+
+- Add celery + celery-beat as additional compose services (same `openzaak/open-zaak`
+  image, different command), pointed at the same redis broker already in the harness.
+- Registering the `abonnement` becomes a scripted, idempotent step — not a manual
+  admin-UI action — parameterized by the BFF's real public URL.
+- Keep the existing WP-54 harness variant (`NOTIFICATIONS_DISABLED: 'true'`) available for
+  fast local iteration where a live webhook round-trip isn't needed; this WP is additive
+  (a "with notifications" profile/override), not a replacement.
+
+## Files
+
+- `backend/openzaak/docker-compose.openzaak.yml` (or an override file)
+- New script/config for `abonnement` registration
+- `docs/reference/openzaak-integration.md`
+
+## Steps
+
+1. Add celery/celery-beat services to a notifications-enabled compose profile.
+2. Flip `NOTIFICATIONS_DISABLED` off for that profile.
+3. Script the `abonnement` registration (POST to the NRC, pointed at the BFF's
+   `/zgw/notificaties` endpoint from WP-52), idempotent on rerun.
+4. Verify a real write (e.g. a status change) triggers a live webhook delivery to the BFF.
+
+## Acceptance criteria
+
+- [ ] A notifications-enabled harness profile runs celery/celery-beat and delivers a real
+      notification end-to-end to the BFF's webhook.
+- [ ] The `abonnement` registration step is a script, re-runnable without erroring on an
+      already-registered subscription.
+
+## Verification
+
+Bring up the notifications-enabled profile; create a zaak/status change; confirm the BFF's
+`/zgw/notificaties` endpoint receives and logs it.
+
+## Out of scope
+
+Cache invalidation on notification receipt (flagged separately in
+`openzaak-integration.md` as a `ponytail:` marker, not part of this slice);
+celery-flower/monitoring UI.
+
+## Risks
+
+Celery/celery-beat add real operational surface (another process to keep alive) — scope
+this WP to "works, documented," not a fully monitored deployment.
+
+Depends on: WP-56 (provisioning mechanism this extends).