feat(versiebeheer): content-versiebeheer van vragenlijst-bronnen (epic)

[robbertbos]

Epic: content-versiebeheer van vragenlijst-bronnen

Integratie-branch voor het gefaseerd invoeren van content-versiebeheer (Pre-scan/DPIA/IAMA): expliciete versies, concept-kanaal, per-assessment pinning, "nieuwere versie"-detectie + migratie, en een transparante modeloverzichtspagina. main blijft schoon; elke fase als sub-PR.

Aanbevolen review-volgorde

Stack A — Fase 2 core (gestapeld):

1. feat(versiebeheer): versie-bewuste schemaStore (Fase 2a) #408 — versie-bewuste schemaStore-registry (fundament)
2. feat(versiebeheer): D1 — officieel coarse, concept precies in de urn #409 — D1 (officieel coarse / concept precies) + canonical-urn-consistentie
3. feat(versiebeheer): per-assessment pin-kolom (Fase 2b) #410 — per-assessment pin-kolom + migratie 0004 + security-hardening (jouw review-punt)

Stack B — Fase 1 build (gestapeld):
4. #411 — build_sources.py (manifest-gedreven multi-versie build, additief)
5. #412 — buildsites omhangen naar build_sources.py + platte drop-in (byte-identiek geverifieerd; raakt deploy-workflows)

Op stack B:
6. #413 — Fase 4: /modellen transparantiepagina (publiek, RVO, 100% getest)

Los: #407 — afstemmingsplan (doc, voor het team)

Status per fase

• Fase 0 + manifest-fundament (feat(versiebeheer): fundament content-versiebeheer sources (Fase 0 + manifest) #405, gemerged)
• Fase 2a registry (feat(versiebeheer): versie-bewuste schemaStore (Fase 2a) #408) · D1+canonical (feat(versiebeheer): D1 — officieel coarse, concept precies in de urn #409) · Fase 2b pin (feat(versiebeheer): per-assessment pin-kolom (Fase 2b) #410) — core 1227 + backend 432 @ 100%
• Fase 1a build_sources (feat(versiebeheer): build_sources.py — manifest-gedreven multi-versie build (Fase 1a) #411) · Fase 1b buildsites (feat(versiebeheer): buildsites → build_sources.py (Fase 1b) #412) — python 58, byte-identiek, actionlint groen
• Fase 4 /modellen (feat(versiebeheer): /modellen transparantiepagina (Fase 4) #413) — frontend 829 @ 100%
• Review-pass Fase 2 (13 bevindingen verwerkt) + review-pass Fase 1/4 (loopt)
• resolve-by-pin (editor laadt gepinde versie via registry + getUrn pin-bewust) — fixt latente urn-drift; dormant tot een 2e versie bestaat
• Fase 3 — versie kiezen (project-default + per-assessment override op create)
• Fase 5 — useVersionUpgrade detectie + "nieuwere versie"-banner
• Manifest afslanken (DRY) + bronbestand-verhuizing (sources/<type>/<versie>.yaml) — nodig bij de 2e versie
• Fase 6 (concept-kanaal/gating) · Fase 7 (migratie-engine) · Fase 8 ("terug")

Stand

De multi-versie build is nu actief (#412): elke build levert geneste per-versie output + manifest.json. /modellen (#413) consumeert dat al. resolve-by-pin / picker / detectie zijn de volgende stappen — gedrag-loos tot er een echte 2e versie (bv. een DPIA-concept) aan het manifest wordt toegevoegd; de infrastructuur staat klaar.

[github-actions]

🚀 Preview Deployment

Your changes have been deployed to a preview environment:

api: https://pr-406-asses-k2n.rig.prd1.gn2.quattro.rijksapps.nl

frontend: https://pr-406-asses-k2n.rig.prd1.gn2.quattro.rijksapps.nl

This deployment will be automatically cleaned up when the PR is closed.

[robbertbos]

Review + security-audit pass (multi-agent, adversarieel geverifieerd)

5-dimensie review-workflow (security · correctness · db-migratie · NeRDS/standaarden · test-gaps) over de hele stack: 16 bevindingen -> 13 bevestigd na adversariele verificatie.

Opgelost in deze stack

• canonical-urn-consistentie (feat(versiebeheer): D1 — officieel coarse, concept precies in de urn #409): de registry keyde op de volledige bronversie terwijl getUrn een officiele versie coarset -> getByUrn(getUrn(ns)) miste bij een 3-segment-officiele versie. Nu leiden beide af van een canonicalVersion (officieel coarse, concept volledig); round-trip + tests toegevoegd.
• route-grammatica (feat(versiebeheer): per-assessment pin-kolom (Fase 2b) #410): definitionVersion accepteerde 3.1.0/bare-major die het output-schema metadata.urn afwijst; op het stateless create-pad (zonder validateState) kon zo'n out-of-grammar pin ongevalideerd de kolom in. Pattern nu gelijk aan de urn-grammatica + maxLength.
• NULL-fallback-doc (feat(versiebeheer): per-assessment pin-kolom (Fase 2b) #410): de kolom-comment beloofde een read-pad-fallback die nog niet bestaat -> verduidelijkt als contract voor resolve-by-pin.
• test-gaps: register-invariant (raakt de actieve view niet), last-write-wins, canonicalVersion, de round-trip, en de 3-segment-rejectie.

Bewust uitgesteld (geflagd)

• Pin <-> metadata.urn-coercion wanneer de client beide aanlevert en ze verschillen: hoort bij de server-autoritatieve coercion (plan E) - vervolg-PR.

Alle suites groen: core 1227 + backend 432 @ 100% coverage.