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,65 @@
+# WP-59 — Per-document-type confidentialiteit config
+
+Status: todo
+Phase: 10 — OpenZaak production hardening
+
+## Why
+
+`OpenZaakDocumentSource` hardcodes `vertrouwelijkheidaanduiding` to `"openbaar"` for every
+uploaded document, regardless of document type. Real BIG-register documents (diploma's, ID
+scans) plausibly need different confidentiality levels. This repo already has a house
+pattern for exactly this kind of business-tunable value — stamdata-as-code (ADR-0004) — so
+this slice is "apply the existing pattern," not invent a new one.
+
+## Read first
+
+- [ADR-0004 — Stamdata as code](../reference/architecture/0004-stamdata-as-code.md)
+- `backend/src/BigRegister.Api/Stamdata/` (an existing table for the shape to imitate)
+- `backend/src/BigRegister.Api/Zgw/OpenZaakDocumentSource.cs`
+
+## Decisions (pre-made, don't relitigate)
+
+- Confidentiality level is keyed by document type (whatever type already distinguishes
+  uploads, e.g. diploma vs. id-bewijs) via a new Stamdata table, using the existing
+  `StamdataTable.Of<T>` mechanism — not a new ad hoc config format.
+- Default/fallback value stays `"openbaar"` if a document type isn't in the table, to
+  avoid a silent upload failure.
+
+## Files
+
+- `Stamdata/` (new table + validation)
+- `Zgw/OpenZaakDocumentSource.cs`
+- `StamdataCatalog.cs` (register the new table)
+
+## Steps
+
+1. Add a `DocumentConfidentialiteit` stamdata table (document type →
+   vertrouwelijkheidaanduiding), validated at build like every other stamdata table
+   (`StamdataValidationTests`).
+2. Register it in `StamdataCatalog` so it's editable via the existing `/beheer/stamdata`
+   grid.
+3. `OpenZaakDocumentSource` looks up the level by document type instead of hardcoding
+   `"openbaar"`.
+
+## Acceptance criteria
+
+- [ ] Confidentiality level for a real upload varies by document type per the new
+      stamdata table.
+- [ ] `StamdataValidationTests` cover the new table (a bad edit fails CI, per ADR-0004).
+- [ ] `/beheer/stamdata` can edit the new table without a code change (existing generic
+      editor).
+
+## Verification
+
+`cd backend && dotnet test`; manual: `/beheer/stamdata` shows and edits the new table; an
+upload for a mapped document type carries the mapped confidentiality level (test
+asserted).
+
+## Out of scope
+
+Any UI-facing confidentiality display/change on the citizen side (FE keeps rendering
+decisions, not recomputing them, per ADR-0001).
+
+## Risks
+
+None significant — this is a config/data-shape change reusing an established mechanism.