docs: ADR-0004 stamdata data-file + WP-29 stamdata beheer editor

Amend ADR-0004 to record what shipped in 0e77faf: a table may live as typed
C# or as a typed JSON data-file (the compile-time value check traded for
editor ergonomics, caught by StamdataValidationTests instead); valid-time and
the generic StamdataCatalog/StamdataTable model; the low-code PR-emitting
editor is no longer "future". Add WP-29 backlog file (done) + README row.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/reference/architecture/0004-stamdata-as-code.md

@@ -35,10 +35,17 @@ production database, never runtime-editable.
 
 1. **One home, typed.** Business-editable reference data lives in the
    `BigRegister.Stamdata` namespace (`backend/src/BigRegister.Api/Stamdata/`), one file per
-   concern, as plain typed C# data (records / dictionaries). Separate the **data** (what the
-   business tunes) from the **rules** (dev-owned logic that consumes it): the profession
-   *table* is `Stamdata.Professions`; the *rule* "an English diploma needs a B2 question"
-   stays in `DiplomaRules`.
+   concern. A table lives **either** as plain typed C# data (records / dictionaries) **or** as
+   a typed JSON data-file deserialized into a record (`professions.json` → `ProfessionMapping`,
+   loaded via `StamdataFile`). Both are checked-in config-as-code, gated the same way; the
+   data-file trades the compiler's *value* check (gate #1 sees only the shape, not a wrong
+   `beroep`) for hand-editing ergonomics and the low-code editor below — the value gate becomes
+   `StamdataValidationTests`. Separate the **data** (what the business tunes) from the **rules**
+   (dev-owned logic that consumes it): the profession *table* is `Stamdata.Professions`; the
+   *rule* "an English diploma needs a B2 question" stays in `DiplomaRules`. Tables may carry
+   **valid-time** (`geldigVan`/`geldigTot`, half-open `[van, tot)`); `StamdataCatalog` +
+   `StamdataTable.Of<T>` describe every table generically (columns reflected from the record)
+   so one endpoint pair and one grid editor serve all of them.
 2. **Served unchanged.** The existing BFF-lite endpoints keep serving this data
    (`/duo/diplomas`, `/intake/policy`, `/uploads/categories`, …). No frontend change — the
    FE still renders decisions.
@@ -54,7 +61,7 @@ production database, never runtime-editable.
 
 | Kind | Home | Gate |
 | --- | --- | --- |
-| Reference tables + tunable numbers (professions↔diplomas, thresholds, policy questions, document categories) | `Stamdata/` typed C# | compiler + `StamdataValidationTests` |
+| Reference tables + tunable numbers (professions↔diplomas, thresholds, policy questions, document categories) | `Stamdata/` typed C# **or** typed JSON data-file (`professions.json`), optionally valid-timed | compiler (shape; + values when C#) + `StamdataValidationTests` (values, references, validity windows) |
 | User-facing UI copy | `$localize` → `src/locale/*.xlf` | build (`i18nMissingTranslation: error`) |
 | Letter / brief passage content | config-as-code in the backend (seed content), **not** the DB | compiler + endpoint tests |
 
@@ -80,3 +87,9 @@ everyone. Stamdata (the rules and reference tables the whole register runs on) s
   which now consumes both (behaviour unchanged), guarded by `StamdataValidationTests`.
   Document-category definitions follow the same pattern as the obvious next step; not moved
   yet.
+- **Shipped as a follow-on (WP-29):** the "future low-code editor" and "data-file format" this
+  ADR floated are now real. `professions` moved to `professions.json` (typed, valid-timed) and
+  the generic `StamdataCatalog`/`StamdataTable`/`StamdataFile` model plus read-only, admin-gated
+  `GET /stamdata` endpoints back an Angular `beheer/stamdata` editor. It is **not** a runtime
+  write path: the admin edits a grid and downloads the edited JSON to commit as a reviewed PR —
+  the compile/validation gate stays the authority, so this ADR's core decision is unchanged.