feat(backend): expand stamdata + OpenZaak-ready cases seam (WP-49)
CI / frontend (push) Successful in 2m59s
CI / backend (push) Successful in 1m27s
CI / semgrep (push) Successful in 58s
CI / e2e (push) Successful in 2m30s
CI / api-client-drift (push) Canceled after 1m14s
CI / storybook-a11y (push) Canceled after 29m8s
CI / frontend (push) Successful in 2m59s
CI / backend (push) Successful in 1m27s
CI / semgrep (push) Successful in 58s
CI / e2e (push) Successful in 2m30s
CI / api-client-drift (push) Canceled after 1m14s
CI / storybook-a11y (push) Canceled after 29m8s
Stamdata: add beroepen, opleidingen (temporal), and specialismen tables to the schema-driven catalog (zero UI code). opleidingen.beroep and specialismen.beroep both reference beroepen.code — the first stamdata->stamdata references, enforced by two new StamdataRef entries in the CI gate. OpenZaak/ZGW (WP-49, slice 1 — read-only zaken): introduce IZaakSource as the cases read seam. Default LocalZaakSource reads the local SQLite store (offline); an OpenZaakZaakSource (Zgw/ client: HS256 per-call JWT, ZGW->existing-DTO mapper, paginating HTTP source) is selected behind Zgw:Enabled (default false). The FE never changes — same ApplicationSummaryDto, no api-client drift. Unit-tested with fixtures + a stub HttpMessageHandler; no live OpenZaak needed. Docs: ADR-0005, reference/openzaak-integration.md, WP-49..52 roadmap, stamdata.md update, README index rows. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
@@ -6,6 +6,11 @@ build**, not a runtime-editable database. For the _why_, see
|
||||
[ADR-0004 — Stamdata as code](architecture/0004-stamdata-as-code.md); this page is _how the
|
||||
code is laid out and how to add a table without coupling_. Built in WP-29, hardened in WP-48.
|
||||
|
||||
Tables today: `professions` (opleiding-program → beroep), `beroepen` (the BIG professions master
|
||||
list), `opleidingen` (temporal; `beroep` → `beroepen.code`) and `specialismen` (`beroep` →
|
||||
`beroepen.code`). The last two are **stamdata → stamdata** references — one table keyed on by two
|
||||
others — enforced by the CI gate below.
|
||||
|
||||
## The one rule that shapes everything: no runtime write path
|
||||
|
||||
The catalog is the source of truth and lives in code. The admin editor **downloads** an
|
||||
@@ -50,8 +55,11 @@ component**. This is the payoff of the schema-driven design.
|
||||
|
||||
`backend/tests/BigRegister.Tests/StamdataValidationTests.cs`. `Every_catalog_table_is_valid`
|
||||
covers every registered table generically; the `StamdataRef` list catches dangling
|
||||
references (today: `Diploma.Opleiding → professions.program`). A bad edit, an orphaning
|
||||
delete, or a premature expire **fails the PR build** — never prod.
|
||||
references — both seed → stamdata (`Diploma.Opleiding → professions.program`) and
|
||||
stamdata → stamdata (`Opleiding.beroep → beroepen.code`, `Specialisme.beroep →
|
||||
beroepen.code`). A bad edit, an orphaning delete, or a premature expire **fails the PR
|
||||
build** — never prod. Adding a cross-table FK is one `StamdataRef` entry: the referencing
|
||||
keys + a resolver against the target table's (valid-today) keys.
|
||||
|
||||
## Coupling
|
||||
|
||||
|
||||
Reference in New Issue
Block a user