chore: reconcile skills + add scenario-traces and casus leak-guard

Voegt de uiteengelopen user-level en engine-repo skill-kopieën samen tot één
canonieke set. Engine-versies waren inhoudelijk vooruit (Step 0 drift-check,
source-refs integriteitsscan, striktere private-repo-guard); de scenario-traces-
kruisverwijzingen die alleen user-level bestonden zijn erin geport.

- regelrecht-scenario-traces toegevoegd als nieuwe (dossier-agnostische) skill
- script/check-skills-no-casus.sh + pre-commit hook 'skills-no-casus' die
  casus-specifieke inhoud (HHNK/waterschap-codes/corpus-repo-namen) blokkeert
  zodat trajectinformatie niet in de publieke skills lekt

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: humanintheloop25

.claude/skills/regelrecht-audit-products/templates/testcase-scenarios.md

@@ -8,6 +8,12 @@ de engine? En hoe rekenen jullie eigenlijk?"*
 > casussen — **nooit echte persoonsgegevens**. De BDD-versie kan in een
 > `features/`-feature-file staan.
 
+> **Methode**: bouw de scenario's met `regelrecht-scenario-traces` — geef elke casus een
+> naam (persona op casus-assen, niet een losse leaf-bundel) zodat experts 'm herkennen, en
+> kies personas die samen verschillende keten-paden raken. Bij verschil met de praktijk
+> wijzen de keten-checkpoints aan wélke schakel afwijkt, niet alleen dát de uitkomst
+> verschilt.
+
 ---
 
 ## 1. {Scenario-titel — kort beoordelings-pad}

.claude/skills/regelrecht-dossier/SKILL.md

@@ -15,6 +15,10 @@ eigenlijke werk gebeurt in de twee skills waarnaar het routeert.
   bevindingen.
 - **`regelrecht-audit-products`** — de menselijke validatielaag (live): valideert met
   domein-experts. Levert consensus + correctiepunten + testcases.
+- **`regelrecht-scenario-traces`** — gedeelde techniek-laag (geen aparte fase): maakt
+  casuïstiek vindbaar (persona's/assen) en norm-ketens leesbaar/geassert (keten-checkpoints
+  + golden-traces). Wordt door beide werk-skills gebruikt bij het schrijven van scenario's
+  en het reviewen van traces.
 
 De volledige flow, het gate-criterium en de handoff-lus staan in `references/routing.md`
 (de canonieke bron; beide werk-skills verwijzen hierheen). Voor het inwerken van nieuwe

.claude/skills/regelrecht-dossier/references/routing.md

@@ -85,3 +85,9 @@ wat eigenlijk onze modelleerfout is. Voor kennis-ontginning is een ruw corpus pr
 | Untranslatables | factual vs judgment geclassificeerd | judgment-set = beslispunten |
 | Scenario's | `engine-tests` (regressie) | `testcase-scenarios` (expert-validatie) |
 | Verslag/rapport | `eindrapport` (per cyclus) | `verslag-intern`/`-extern` (per sessie) |
+
+Beide scenario-bruggen zijn gebouwd met de techniek-skill **`regelrecht-scenario-traces`**
+(casus vindbaar via persona's/assen; keten leesbaar/geassert via keten-checkpoints +
+golden-traces). Het is geen vierde laag in de flow maar een gedeelde methode die desk
+(`engine-tests`, de features-vs-YAML meta-check) en workshop (`testcase-scenarios`) allebei
+gebruiken.

.claude/skills/regelrecht-scenario-traces/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: regelrecht-scenario-traces
+description: Maakt regelrecht-scenario's vindbaar en hun norm-ketens leesbaar/geassert. Aan de invoerkant — vertaal een platte lijst leaf-parameters naar benoemde casus-assen + een herbruikbare persona-bibliotheek, met een reverse-lookup casus-matrix. Aan de uitvoerkant — maak de norm-keten zichtbaar via keten-checkpoints (assert elke knoop op het kritieke pad, niet alleen de endpoint) en golden-trace-snapshots + branch-coverage. Gebruik dit bij het schrijven of opschonen van scenario-/feature-files, het terugvinden of ontwerpen van een specifieke casus in een grote variabelenlijst, het reviewen van engine-traces, of het regressie-bestendig maken van cross-law-ketens zodat een ketenfout niet stil achter een correcte endpoint verdwijnt. Dossier-agnostisch; de regelrecht-methode is de vaste taal. Haakt aan op regelrecht-stelselanalyse (engine-tests / meta-check) en regelrecht-audit-products (testcase-scenario's).
+allowed-tools: Read, Write, Edit, Grep, Glob, Bash, AskUserQuestion, Agent
+---
+
+# Regelrecht scenario's & traces — casus vindbaar, keten leesbaar
+
+Een dossier-agnostische techniek-skill die beide werk-skills delen:
+`regelrecht-audit-products` schrijft scenario's (de casus-kant),
+`regelrecht-stelselanalyse` reviewt traces (de keten-kant). Deze skill levert de
+*methode* om scenario's zó te modelleren dat (A) de casuïstiek terugvindbaar is en
+(B) de juridische logica-keten zichtbaar én geassert is.
+
+Geen casus-inhoud in de skill; concrete persona's, assen en norm-namen komen uit het
+corpus tijdens toepassing.
+
+## Het probleem dat deze skill oplost
+
+Een scenario dat alleen een handvol leaf-parameters flipt en de **endpoint** assert,
+verbergt twee dingen tegelijk:
+
+- **A — casus onvindbaar.** De casus ("welke persoon is dit?") bestaat alleen in je
+  hoofd, in de scenario-titel en in comments. Met tientallen platte booleans moet je de
+  mapping *persona → leafs* elke keer handmatig reverse-engineeren. Twee scenario's met
+  identieke invoer maar een ander bedóeld onderscheid zien er identiek uit.
+- **B — keten onzichtbaar.** De engine berekent een keten van tussen-normen tussen de
+  leafs en de endpoint. Alleen de endpoint asserten betekent: een *foute keten* die op
+  jouw gesamplede casus toevallig dezelfde endpoint geeft, slipt er geluidloos door. En
+  lezend is de juridische structuur niet uit het scenario te halen.
+
+## Kernprincipe: de ontbrekende middenlaag
+
+Tussen *menselijke casus* en *engine-output* zit een middenlaag die first-class,
+vindbaar én geassert moet zijn:
+
+```
+   menselijke casus            ENGINE                 uitkomst
+   "wie is deze persoon?"  ─►  leaf-feiten ─► keten ─► endpoint
+        │                          │           │          │
+   [A] benoemde persona ───────────┘           │          │
+       op casus-assen                           │          │
+                                   [B] benoemde norm-keten ┘
+                                       (keten-checkpoints + golden trace)
+```
+
+- **Invoerkant (A):** geef de casus een naam en plaats hem op een paar **casus-assen**;
+  bundel de leaf-deltas in een herbruikbare **persona**. → `references/casus-assen.md`,
+  `references/persona-bibliotheek.md`.
+- **Uitvoerkant (B):** bepaal het **kritieke pad** door de YAML-DAG en assert *elke knoop*
+  erop; leg de volledige trace vast als **golden snapshot** met branch-coverage. →
+  `references/keten-checkpoints.md`, `references/golden-traces.md`.
+
+## De vier mechanismen
+
+| # | Mechanisme | Lost op | Reference / template |
+|---|---|---|---|
+| 1 | **Assen-groepering** — platte leaf-lijst → casus-assen (dimensie-reductie) | A | `references/casus-assen.md` |
+| 2 | **Persona-bibliotheek** — benoemde, herbruikbare leaf-bundel op de assen; twin-persona's (één-as-verschil) | A | `references/persona-bibliotheek.md` · `templates/persona-bibliotheek.md` · `templates/casus-matrix.md` |
+| 3 | **Keten-checkpoints** — assert elke knoop op het kritieke pad, niet alleen de endpoint | B | `references/keten-checkpoints.md` · `templates/keten-kaart.md` |
+| 4 | **Golden traces** — volledige trace snapshotten + diffen + branch-coverage | B | `references/golden-traces.md` · `templates/golden-trace-review.md` |
+
+Schaal naar de vraag: een snelle opschoning gebruikt 1+3; een regressie-bestendige
+cross-law-keten gebruikt alle vier.
+
+## Werkstroom
+
+1. **Vind de assen.** Reduceer de platte leaf-lijst tot een handvol onafhankelijke
+   casus-assen (zie `references/casus-assen.md`). Groepeer de baseline-parameters per as
+   — alleen al volgorde + kopjes maken de lijst scanbaar.
+
+2. **Bouw de persona-bibliotheek + casus-matrix.** Druk elke casus uit als benoemde
+   bundel leaf-deltas op de assen (`templates/persona-bibliotheek.md`). Leg de
+   reverse-lookup vast: persona ↔ scenario ↔ keten-pad ↔ uitkomst
+   (`templates/casus-matrix.md`). Voeg twin-persona's toe waar een onderscheid anders
+   onzichtbaar blijft.
+
+3. **Bepaal het kritieke pad & leg keten-checkpoints vast.** Leid uit de YAML de DAG van
+   tussen-normen naar de endpoint af (`templates/keten-kaart.md`). Laat elk scenario
+   *elke knoop op zijn pad* asserten, niet alleen de endpoint
+   (`references/keten-checkpoints.md`).
+
+4. **Snapshot golden traces + branch-coverage.** Leg de volledige engine-trace per
+   scenario vast en diff bij wijziging; rapporteer welke takken nog ongetest zijn
+   (`references/golden-traces.md`, `templates/golden-trace-review.md`).
+
+5. **Voer de meta-check uit.** Maken de scenario's en de YAML dezelfde fout? Dan
+   valideert de suite de YAML, niet de wet. Keten-checkpoints + golden-traces zijn het
+   concrete wapen hiertegen — zie de hook naar `regelrecht-stelselanalyse`.
+
+6. **Schrijf naar het corpus/dossier, niet in de skill.** Persona's, matrices en
+   trace-snapshots horen bij het corpus (bijv. `scenarios/`, `features/`, `docs/`).
+   Wijzig nooit de skill-bestanden met casus-inhoud. Commit/push alleen op verzoek.
+
+## Bestanden in deze skill
+
+**references/**
+- `casus-assen.md` — van een platte leaf-lijst naar onafhankelijke casus-assen
+  (dimensie-reductie); hoe je assen herkent en de baseline groepeert.
+- `persona-bibliotheek.md` — persona = benoemde leaf-bundel op de assen; expressievormen
+  (Scenario Outline / custom `Given persona`-step / fixtures); twin-persona's.
+- `keten-checkpoints.md` — kritiek pad uit de YAML-DAG; de conventie "assert elke knoop";
+  sensitiviteits-/twin-scenario's; band met de features-vs-YAML meta-check.
+- `golden-traces.md` — volledige trace vastleggen, diffen, branch-coverage; wanneer wel/niet.
+
+**templates/**
+- `persona-bibliotheek.md` — persona | assen-coördinaat | leaf-deltas | keten-checkpoints | endpoint.
+- `casus-matrix.md` — reverse-lookup index: persona ↔ scenario ↔ keten-pad ↔ uitkomst.
+- `keten-kaart.md` — per endpoint de knoop-DAG met coverage-markering per schakel.
+- `golden-trace-review.md` — trace-snapshot-review + branch-coverage-rapport.
+
+## Routing & handoff
+
+Dit is een techniek-laag die beide werk-skills bedienen. Twijfel je waar te beginnen →
+`regelrecht-dossier`. Bij het ontwerpen van expert-testcases gebruikt
+`regelrecht-audit-products/templates/testcase-scenarios` deze persona-methode; bij
+regressie/validatie voert `regelrecht-stelselanalyse` (engine-tests + de
+features-vs-YAML meta-check) de keten-checkpoints + golden-traces uit.
+
+## Belangrijke regels
+
+- **Dossier-agnostisch blijven.** Geen vaste wet-namen, norm-namen, bedragen of
+  casus-voorbeelden in de skill-bestanden. In *output* (corpus/features) mag casus-inhoud
+  uiteraard wel.
+- **Assert de keten, niet alleen de endpoint.** Een groene endpoint met een ongeteste
+  keten bewijst niets over de tussenstappen.
+- **Persona is de bron, scenario is de afgeleide.** Eén persona-definitie, hergebruikt
+  over scenario's — niet dezelfde leaf-bundel telkens opnieuw met de hand.
+- **Twin-scenario's voor elk onderscheid dat het model niet vanzelf ziet.** Eén-as-verschil
+  maakt de keten falsifieerbaar.
+- **Stille truncatie loggen.** Cap je coverage (top-N personas, niet alle takken) → meld
+  expliciet wat je overslaat.

.claude/skills/regelrecht-scenario-traces/references/casus-assen.md

@@ -0,0 +1,70 @@
+# Casus-assen — van platte leaf-lijst naar dimensies
+
+Een endpoint met veel leaf-parameters geeft een baseline van tientallen platte booleans
+(meestal allemaal op de neutrale waarde) waarin elk scenario er een paar flipt. Die
+lijst is niet scanbaar: je vindt een casus niet terug, en je ziet niet welke combinaties
+betekenisvol zijn. De oplossing is **dimensie-reductie**: groepeer de leafs tot een
+handvol onafhankelijke *casus-assen*.
+
+## Waarom assen werken
+
+De meeste leafs zijn niet vrij-combineerbaar. Ze clusteren rond een paar onderliggende
+vragen over de persoon/situatie, en binnen een cluster zijn waarden vaak wederzijds
+uitsluitend of alleen samen relevant. Een casus is dan een **coördinaat** op enkele
+assen in plaats van een speld in een hooiberg van losse vlaggen.
+
+## Een as herkennen
+
+Een as is een groep leafs die samen één onderliggende vraag beantwoorden. Heuristieken:
+
+- **Gedeeld onderwerp** — leafs die over hetzelfde gaan (status, relatie, plaats, een
+  registratie, een tijdvak) horen op één as.
+- **Wederzijdse uitsluiting** — als hoogstens één van een groep tegelijk waar kan zijn,
+  is die groep waarschijnlijk één as met meerdere waarden.
+- **Gezamenlijke relevantie** — leafs die alleen iets doen in elkaars aanwezigheid
+  (A telt alleen mee als B) horen bij elkaar.
+- **Voedt dezelfde tussen-norm** — leafs die in de YAML naar dezelfde tussen-knoop leiden
+  (zie `keten-checkpoints.md`) vormen een natuurlijke as.
+
+Mik op een **klein** aantal assen (richtlijn: een handvol). Te veel assen = je hebt de
+platte lijst alleen hernoemd; te weinig = je verliest betekenisvol onderscheid.
+
+## Twee soorten assen
+
+- **Categorische as** — één-uit-N waarden (een statussoort, een relatietype). Modelleer
+  als één keuze, niet als N losse booleans waarvan er meerdere tegelijk waar kunnen
+  staan (dat zou onmogelijke casussen toelaten).
+- **Onafhankelijke vlag** — een echt losstaand ja/nee dat met alles combineert. Houd
+  deze apart; dwing ze niet in een as.
+
+## De baseline groeperen (de goedkoopste winst)
+
+Nog vóór je persona's bouwt: herorden de baseline-parameterlijst per as, met een kopje
+per as. Dezelfde 60 booleans worden dan 6 leesbare groepen. Dit is puur volgorde +
+commentaar — geen gedragswijziging — en maakt de lijst meteen scanbaar.
+
+```
+# === AS: <onderwerp 1> ===
+<leaf_a> | <neutrale waarde>
+<leaf_b> | <neutrale waarde>
+
+# === AS: <onderwerp 2> ===
+...
+
+# === Losse vlaggen ===
+...
+```
+
+## Onmogelijke-combinatie-bewaking
+
+Door assen expliciet te maken zie je welke combinaties juridisch onmogelijk zijn (twee
+elkaar uitsluitende waarden op één categorische as). Markeer die als verboden — een
+scenario dat ze toch zet, test een casus die niet bestaat. Dit is ook input voor de
+twin-persona's in `persona-bibliotheek.md`: een twin verschilt op precies één as-waarde.
+
+## Resultaat
+
+De assen zijn de coördinaten-taal voor de rest van de skill: persona's worden benoemde
+punten in de assen-ruimte (`persona-bibliotheek.md`), en de casus-matrix indexeert op
+assen (`templates/casus-matrix.md`). Leg de assen-definitie vast bij het corpus, niet in
+de skill.

.claude/skills/regelrecht-scenario-traces/references/golden-traces.md

@@ -0,0 +1,53 @@
+# Golden traces — de volledige keten vastleggen tegen regressie
+
+Keten-checkpoints (`keten-checkpoints.md`) asserten de knopen die je *bewust* hebt
+gekozen. Een **golden trace** legt de *volledige* engine-trace per scenario vast — alle
+tussen-knopen + welke tak vuurde — als snapshot. Een wijziging die de endpoint én je
+checkpoints ongemoeid laat maar elders in de keten iets verschuift, wordt dan een
+trace-diff. Dit is de sterkste verdediging tegen stille ketenfouten.
+
+## Wat je vastlegt
+
+Per scenario een genormaliseerd trace-snapshot: de geëvalueerde knopen, hun waarden, en
+welke tak/conditie waar werd. Normaliseer wat ruis is (volgorde, timestamps, interne
+ids) zodat de diff alleen betekenisvolle veranderingen toont. Sla de snapshots bij het
+corpus op (bijv. naast de scenario's), niet in de skill.
+
+## De workflow
+
+1. **Genereer** de trace via de runner/engine voor elk scenario.
+2. **Normaliseer** tot een stabiele, diff-bare vorm.
+3. **Review & commit** de snapshot als "golden" zodra je 'm hebt geverifieerd tegen de
+   verwachte keten (niet blind: een golden trace is pas goud na menselijke/expert-check).
+4. **Diff** bij elke YAML-/feature-wijziging. Een onverwachte diff = mogelijk een
+   ketenfout; een verwachte diff = bewust herijken (update de golden + leg uit waarom).
+
+> Een golden trace die je nooit tegen de wettekst hebt geverifieerd, bevriest alleen je
+> huidige interpretatie. Verifieer vóór je 'm tot goud verklaart — anders is het
+> regressie-bescherming van een mogelijk foute keten (zie de meta-check in
+> `keten-checkpoints.md`).
+
+## Branch-coverage over de wet-logica
+
+De trace vertelt ook welke **takken** je scenario's raken. Voor elke conditie/operatie in
+de YAML: wordt zowel de waar- als de onwaar-kant ergens geraakt? Een nooit-geraakte tak
+is een plek waar een ketenfout zich ongezien kan verstoppen.
+
+- Inventariseer de takken per endpoint (uit de keten-kaart).
+- Markeer per tak: geraakt-waar / geraakt-onwaar / ongetest.
+- Ongeteste takken → nieuwe persona's of twin-scenario's om ze te dekken.
+- Rapporteer de dekking in `templates/golden-trace-review.md`.
+
+## Wanneer wel, wanneer niet
+
+- **Wel**: cross-law-ketens, endpoints met veel takken, alles wat je regressie-bestendig
+  wilt houden over cycli heen.
+- **Lichter**: een kleine, stabiele keten heeft vaak genoeg aan keten-checkpoints alleen.
+  Golden traces kosten onderhoud (elke bewuste wijziging vraagt een herijking) — zet ze
+  in waar de regressie-winst dat waard is.
+
+## No silent caps
+
+Snapshot je maar een deel van de scenario's of dek je niet alle takken → log dat
+expliciet in het review-rapport. Stille truncatie leest als "alles gedekt" terwijl dat
+niet zo is.

.claude/skills/regelrecht-scenario-traces/references/keten-checkpoints.md

@@ -0,0 +1,68 @@
+# Keten-checkpoints — assert elke knoop, niet alleen de endpoint
+
+De engine berekent tussen de leaf-feiten en de endpoint een **keten** van tussen-normen.
+Wie alleen de endpoint assert, test de keten niet: een foute keten die op de gesamplede
+casus toevallig dezelfde endpoint oplevert, slipt er geluidloos door. Keten-checkpoints
+maken elke knoop op het kritieke pad expliciet uitgesproken.
+
+## Het kritieke pad afleiden uit de YAML
+
+1. Begin bij de endpoint-output van het scenario.
+2. Volg in de YAML de bindingen terug: elke `output`/tussen-norm hangt af van andere
+   outputs, van leaf-parameters, en (bij cross-law) van outputs van andere wetten via
+   `source`. Dit vormt een gerichte acyclische graaf (DAG).
+3. Voor een gegeven persona is het **kritieke pad** de subset knopen die de uitkomst
+   daadwerkelijk bepalen — inclusief de knopen die een uitsluiting *neutraliseren* of een
+   tak *afsluiten* (een tegen-uitsluiting die "uit" staat is net zo bepalend als één die
+   "aan" staat).
+4. Leg de DAG + per-persona-pad vast in `templates/keten-kaart.md`.
+
+## De conventie
+
+Elk scenario assert **elke knoop op zijn kritieke pad**, niet alleen de endpoint. Dus
+naast de eind-output ook de relevante tussen-normen: de hoofdgrond die geldt, elke
+uitsluiting die wel/niet van toepassing is, en elke tegen-uitsluiting die wel/niet
+neutraliseert. Een lezer ziet dan de juridische structuur in het scenario zelf; een
+ketenfout flipt een checkpoint, ook als de endpoint toevallig gelijk blijft.
+
+Houd het **kritiek**: assert de knopen die de uitkomst dragen, niet elke berekende
+waarde. Te veel checkpoints maken het scenario bros en onleesbaar; te weinig laten gaten.
+De keten-kaart helpt kiezen: assert de knopen waar paden splitsen of samenkomen.
+
+## Cross-law-ketens
+
+Bij een keten over meerdere wetten: assert minstens de **scharnierpunten** — de output
+van elke wet die de volgende wet ingaat. Een cross-law-binding die alleen in de endpoint
+zichtbaar wordt, verbergt waar in de keten het misgaat. (Forwarding van leaf-feiten over
+meerdere hops is een bekende valkuil: elke hop moet zijn eigen inputs doorkrijgen — een
+checkpoint per scharnier maakt een gebroken hop direct zichtbaar.)
+
+## Sensitiviteits-/twin-scenario's
+
+Een checkpoint bewijst dat een knoop *een* waarde heeft; een **sensitiviteitstest**
+bewijst dat de knoop op het *juiste* leaf reageert. Bouw scenario-paren die op precies
+één as-waarde verschillen (zie de twin-persona's in `persona-bibliotheek.md`), gekozen
+zó dat het verschil door één ketenschakel loopt:
+
+- Als de schakel correct is, flipt exact het verwachte checkpoint (en alleen dat).
+- Als de schakel fout is (verkeerde EN/OF, gemiste voorwaarde, verkeerde forwarding),
+  flipt het verkeerde of geen checkpoint.
+
+Dekt zo de scharnier-logica af: conjuncties (beide voorwaarden nodig), disjuncties (één
+voldoende), en neutralisaties (de tegen-uitsluiting doet wat hij hoort).
+
+## Band met de features-vs-YAML meta-check
+
+`regelrecht-stelselanalyse` waarschuwt: *als de scenario's en de YAML uit dezelfde
+(mogelijk foute) interpretatie komen, bewijzen groene tests geen juridische
+correctheid.* Keten-checkpoints alleen lossen dat niet op — ze komen nog steeds uit jouw
+interpretatie. Wat ze wél doen: ze maken de interpretatie **expliciet en
+controleerbaar** per knoop, zodat een externe verificatie (wettekst, nota van
+toelichting, expert) elke schakel los kan toetsen in plaats van alleen de endpoint. Leg
+de verwachte checkpoint-waarden naast de wettekst, niet alleen naast de YAML.
+
+## Resultaat
+
+Per endpoint een keten-kaart met geannoteerde knopen, en scenario's die hun pad-knopen
+asserten + twin-paren voor de scharnieren. Dit is de leesbare, falsifieerbare uitvoerkant
+die golden traces (`golden-traces.md`) vervolgens dichttimmeren tegen regressie.