docs(quick-260911-mkj): WINDOWS #27 geschlossen und verifiziert

.planning/quick/260911-mkj-windows-27-schliessen-relations-blindste/260911-mkj-SUMMARY.md

@@ -0,0 +1,144 @@
+---
+phase: quick-260911-mkj
+plan: 01
+subsystem: testing
+tags: [prisma, rls, multi-tenancy, static-analysis, vitest]
+
+requires:
+  - phase: quick-260911-e2s
+    provides: "Bestandsaufnahme-Grundgeruest (rls-access-inventory.spec.ts, drei Erkennungsformen), WINDOWS #27 aufgedeckt"
+provides:
+  - "Vierte Erkennungsform in rls-access-inventory.spec.ts: Relationszugriffe (include:/select:/_count:/Relationsfilter) werden ueber schema.prisma auf ihr Zielmodell aufgeloest und als eigene Fundstelle gefuehrt"
+  - "72 (Datei, Modell)-Paare in der Bestandsaufnahme (65 -> 72, sieben neue, drei fortgeschriebene Staende)"
+  - "WINDOWS #27 fixed mit Nachweis; neuer Ledger-Eintrag #33 fuer die von allen vier Formen unerreichbare Restmenge (tenders.seed.ts, backfill-tender-source.ts)"
+affects: [etappe-4-scharfschalten, rls-preflight]
+
+actuals:
+  tokens: 19657
+  tasks: 2
+  commits: 2
+  plan_head_before: 926359b067596b8d627660d926831b885e74d8d9
+
+tech-stack:
+  added: []
+  patterns:
+    - "Kontextstapel-Parser (scanRelationKeys) fuer verschachtelte Prisma-Query-Objekte, aufgeloest gegen ein zur Testzeit geparstes schema.prisma"
+    - "String-Blanking (blankStringLiterals) fuer klammertiefen-sichere Argumentbereichs-Erkennung, getrennt von der unveraenderten Kommentarfrei-Quelle der Formen 1-3"
+
+key-files:
+  created: []
+  modified:
+    - apps/api/src/prisma/rls-access-inventory.spec.ts
+    - docs/mandantentrennung-zugriffsklassifikation.md
+    - docs/mandantentrennung-etappe2-fehlerrichtung.md
+    - .planning/WINDOWS.md
+
+key-decisions:
+  - "Vierte Erkennung schreibt Relationsziele direkt in unboundModels/boundModels (Klientenname = Modellname mit kleinem Anfangsbuchstaben) statt eines eigenen Fundstellentyps, damit findAccessSites/computeStandByKey und die bestehenden Vergleichstests unveraendert bleiben"
+  - "ldap-config.service.ts/ldapFieldMapping wechselt von muss-mandantengebunden auf beides — der Elternpfad getAllActiveConfigs() ist bereits als Hintergrunddienst-Fall an Etappe 3 uebergeben, kein neuer Befund"
+  - "RELATION_SPEC_EXCEPTIONS bleibt schmal (eine Datei, backfill-tender-source.ts); die zweite unerreichbare Datei (tenders.seed.ts, kein Relationszugriff) wird stattdessen als eigener Ledger-Eintrag #33 gefuehrt, nicht stillschweigend mit #27 mitgeschlossen"
+
+requirements-completed: [WINDOWS-27, ETAPPE-4-VORAUSSETZUNG]
+
+duration: ~45min
+completed: 2026-09-11
+status: complete
+---
+
+# Phase quick-260911-mkj: WINDOWS #27 schliessen — Relations-Blindstelle Summary
+
+**Vierte Erkennungsform in `rls-access-inventory.spec.ts` macht Relationszugriffe (`include:`/`select:`/`_count:`/Relationsfilter) sichtbar, die Prisma als Unterabfrage auf eine zweite Tabelle unter DEREN Regel rendert — Bestandsaufnahme waechst von 65 auf 72 Paare, WINDOWS #27 ist geschlossen.**
+
+## Performance
+
+- **Duration:** ~45 min
+- **Completed:** 2026-09-11
+
+## Nachweis WINDOWS #27
+
+**Zwischenmessung (Aufgabe 1, VOR dem Nachziehen der Bestandsaufnahme) — woertlich, wie im Plan verlangt:**
+
+```
+× jede im Quelltext gefundene (Datei, Modell)-Fundstelle ist im Dokument eingetragen
+  Fehlende Eintraege im Dokument:
+  apps/api/src/groups/module-grants.service.ts::module
+  apps/api/src/ldap/ldap-config.service.ts::tenant
+  apps/api/src/module-registry/module-access.service.ts::group
+  apps/api/src/module-registry/module-access.service.ts::groupMembership
+  apps/api/src/tenders/tender-digest.scheduler.ts::tender
+  apps/api/src/tenders/tender-digest.scheduler.ts::tenderSavedSearch
+  apps/api/src/tenders/tenders.controller.ts::tenderSource
+
+× der eingetragene Stand stimmt mit dem im Quelltext gemessenen ueberein
+  Abweichender Stand (Dokument vs. Quelltext):
+  apps/api/src/ldap/ldap-config.service.ts::ldapFieldMapping — dokumentiert=gebunden, gemessen=gemischt
+  apps/api/src/module-registry/module-registry.service.ts::module — dokumentiert=ungebunden, gemessen=gemischt
+  apps/api/src/tenders/tender-matching.service.ts::tender — dokumentiert=ungebunden, gemessen=gemischt
+
+Test Files  1 failed (1)
+     Tests  2 failed | 22 passed (24)
+```
+
+Das ist EXAKT die zur Planungszeit gemessene Untergrenze: 7 fehlende Paare,
+3 Stand-Abweichungen. Der Detektor SIEHT die Relationszugriffe, bevor das
+Dokument nachgezogen ist — der geforderte Beweis der Wirkung.
+
+**Zahlen (Aufgabe 1/2, aus der Ausgabe von `rls-access-inventory.spec.ts` und den Gates entnommen, nicht geschaetzt):**
+
+- 7 neue Paare, 3 fortgeschriebene Staende, davon 1 Klassenwechsel (`ldap-config.service.ts`/`ldapFieldMapping`: `muss-mandantengebunden` → `beides`)
+- 1 Waechter-(a)-Ausnahme (`RELATION_SPEC_EXCEPTIONS`: `apps/api/src/tenders/backfill-tender-source.ts`), 0 Waechter-(b)-Verstoesse
+- Bestandsaufnahme: 65 → **72 Paare** (35 muss-mandantengebunden, 21 keine-mandantengebundene-tabelle, 14 beides, 2 bewusst-uebergreifend — exakt die zur Planungszeit projizierte Verteilung)
+- Acht gepinnte Proben, darunter A (WINDOWS #27 ungebunden) und B (WINDOWS #27 gebunden, derselbe Aufruf auf einem `forTenant(`-Klienten) — beide bestanden
+- Gesamtsuite: **1007/1007 Tests, 62/62 Dateien gruen** (Baseline 994/62); Typpruefung sauber; `rls-scratch-check.mjs` **137/137** bestanden
+- WINDOWS-Ledger: #27 `fixed`; neuer Eintrag **#33** fuer die von allen vier Erkennungsformen unerreichbare Restmenge (`tenders/tenders.seed.ts`, `tenders/backfill-tender-source.ts`). Kopf nach diesem Lauf: `open_count: 14`, `total_count: 33`.
+
+## Accomplishments
+
+- **Task 1** (`test(quick-260911-mkj): vierte Erkennungsform fuer Relationszugriffe, WINDOWS #27`, Commit `5ad23d0`):
+  - `analyzeFile` in `analyzeSource(source, relPath)` herausgeloest (testbar gegen Probestrings)
+  - `parseSchemaRelations()` liest `schema.prisma` zur Testzeit, `SCHEMA_RELATIONS` (Map Modell -> Map Feld -> Zielmodell), `CLIENT_NAME_TO_MODEL` fuer den Anker; Lookahead `(?=\s|$)` bewusst gesetzt (ohne ihn verliert die Feldzeilen-Regex jede Listenrelation am Zeilenende — der im Plan benannte erste Prototyp-Fehler, hier vermieden)
+  - Vierte Erkennung: Ankerregex nur ueber bekannte Empfaenger (`this.prisma`, `boundNames`, Transaktionsparameter beider Formen), Argumentbereich per Klammertiefe auf einer string-geblankten Kopie (`blank`), Wertform-Aufloesung gegen gleichnamige Konstanten derselben Datei, Kontextstapel-Scan (`scanRelationKeys`) fuer verschachtelte Relationsfelder inkl. `_count: true`
+  - Drei neue Waechter (Rohzahl vs. erkannte Modellaufrufe, Stale-Check `RELATION_SPEC_EXCEPTIONS`, `unresolvedRelationSpecValues` leer), zwei Schema-Tests, acht gepinnte Proben — alle 24 Tests der Spec-Datei gruen
+  - Bestandsaufnahme fortgeschrieben: sieben neue Zeilen, drei geaenderte Staende, Kopfabsatz "Erkennungsluecke GESCHLOSSEN" ersetzt den alten "seit 260911-e2s vermessen"-Absatz
+- **Task 2** (`docs(quick-260911-mkj): Abschnitte abgeleitet, WINDOWS #27 geschlossen, Restmenge als eigener Eintrag`, Commit `388690f`):
+  - Klassifikationsdokument: Uebersichtsabsatz ("Zweite methodische Luecke ... geschlossen"), Klassen-Verteilung (Ueberschrift + Summenzeile + Tabelle, aus der Bestandsaufnahme GEZAEHLT: 35/21/14/2/72), Hintergrunddienst-Nachtrag zum ersten Fall (`getAllActiveConfigs()` reicht auch in `LdapFieldMapping` hinein — kein neuer Fall, Ueberschrift bleibt "sechs Faelle")
+  - Kritikschrift: `Nachtrag (260911-mkj)` unter `(n4)` im `## Bereich tenant` (verweist auf Befund G/(b) und die Restmenge), Vermerk im `## Etappe 2 — Abschluss`, dass #27 geschlossen ist
+  - Ledger: neuer Eintrag `#33` angelegt (Ledger fuer die Restmenge), dann `#27` auf `fixed` gesetzt, dann der `WINDOWS #TBD-MKJ`-Platzhalter im Spec-Kommentar durch `WINDOWS #33` ersetzt
+
+## Deviations from Plan
+
+### Auto-fixed Issues
+
+None — plan executed exactly as specified for the actual detector/document logic.
+
+### Documented Drift (nicht auto-fixed, nicht Teil dieses Plans)
+
+**1. [Vorbestehende Abweichung, nicht dieser Plan] `docs/mandantentrennung-etappe3-auftrag.md` und Teile von `.planning/HANDOFF.json` weichen bereits VOR Beginn dieser Ausfuehrung von der Basis `cc26197` ab.**
+- **Gefunden bei:** dem Allowlist-Diff-Gate in Aufgabe 1 (`git diff --name-only cc26197`)
+- **Ursache:** Commit `926359b` ("docs: Auftrag fuer Etappe 3 der Mandantentrennung, gemessen statt erinnert", Autor Schalli) landete auf `main`, BEVOR diese Ausfuehrung begann — die im Auftrag genannte Basis-HEAD `261e736` war zu diesem Zeitpunkt bereits um einen fremden Commit veraltet.
+- **Pruefung:** `git show --stat 926359b` zeigt ausschliesslich `docs/mandantentrennung-etappe3-auftrag.md` (neu) und `.planning/HANDOFF.json` — nichts unter `apps/api/src`, kein Schema, keine Migration, keine Compose-/Umgebungsdatei. Ausserhalb des Geltungsbereichs dieses Plans, nicht angefasst.
+- **Auswirkung auf die Verify-Gates:** das im Plan definierte Allowlist-Gate (`git diff --name-only cc26197` gegen eine feste Dateiliste) meldet `docs/mandantentrennung-etappe3-auftrag.md` als "unerwartete Aenderung", weil es diesen fremden, bereits gemergten Commit mitzaehlt. Die tatsaechlich von dieser Ausfuehrung veraenderten Dateien sind ausschliesslich die vier oben genannten (bestaetigt durch `git status --short` vor jedem Commit und durch die beiden Commits `5ad23d0`/`388690f` selbst — je genau die im Plan als Deliverables genannten Dateien, keine mehr).
+- **Nicht behoben, weil:** ausserhalb der Erlaubnisliste dieses Plans (nur die Spec-Datei, `apps/api/prisma/**`, zwei benannte Dokumente, `.planning/`) — ein fremder, bereits abgeschlossener Commit gehoert nicht in diesen Auftrag.
+
+## Known Stubs
+
+None — dieser Plan aendert ausschliesslich Testcode und Dokumentation, keine UI/keine Laufzeitpfade.
+
+## Threat Flags
+
+None — die Aenderungen liegen vollstaendig innerhalb des im Plan definierten `threat_model` (T-MKJ-01 bis T-MKJ-05), keine neue Angriffsflaeche ausserhalb dessen.
+
+## BEFUND — nicht behoben
+
+Keiner. Die Zwischenmessung lieferte exakt 7 fehlende Paare / 3 Stand-Abweichungen (die geplante Untergrenze, keine zusaetzlichen ungenannten Funde); jedes der sieben neuen Paare wurde einzeln am Quelltext geprueft (siehe Zeilenverweise in der Bestandsaufnahme-Tabelle) und ist entweder `keine-mandantengebundene-tabelle` (Elternbindung wirkungslos, nicht schaedlich) oder `muss-mandantengebunden`/`gebunden` (Relationsfilter auf einem bereits gebundenen Klienten in eine Tabelle desselben Mandanten). Keine ungebundene Einbindung in eine geschuetzte Tabelle auf ungeschuetztem Elternpfad, die nicht bereits als Hintergrunddienst-Fall benannt waere.
+
+## Self-Check: PASSED
+
+- `apps/api/src/prisma/rls-access-inventory.spec.ts`: FOUND, enthaelt `analyzeSource`, `parseSchemaRelations`, `SCHEMA_RELATIONS`, `RELATION_SPEC_EXCEPTIONS`, 24 `it(`-Bloecke, alle gruen
+- `docs/mandantentrennung-zugriffsklassifikation.md`: FOUND, 72 (Datei, Modell)-Paare, Klassen-Verteilung 35/21/14/2
+- `docs/mandantentrennung-etappe2-fehlerrichtung.md`: FOUND, `Nachtrag (260911-mkj)` unter `(n4)` und im Abschluss-Abschnitt
+- `.planning/WINDOWS.md`: FOUND, `#27` Status `fixed`, `#33` neu mit Status `open`, Kopfzaehler (`open_count: 14`, `total_count: 33`) konsistent mit den Tabellenzeilen
+- Commit `5ad23d0`: FOUND in `git log --oneline --all`
+- Commit `388690f`: FOUND in `git log --oneline --all`
+- Baseline: 1007/1007 Tests, 62/62 Dateien gruen; `npm --prefix apps/api run type-check` sauber; `rls-scratch-check.mjs` 137/137 bestanden
+- Schalter aus, kein Dienstcode, kein Schema/Migration, keine Compose-/Umgebungsdatei veraendert (bestaetigt per `git status --short` vor jedem Commit)

.planning/quick/260911-mkj-windows-27-schliessen-relations-blindste/260911-mkj-VERIFICATION.md

@@ -0,0 +1,82 @@
+---
+phase: quick-260911-mkj
+verified: 2026-09-11T16:56:00Z
+status: passed
+score: 6/6 must-haves verified
+covered_files: [".planning/WINDOWS.md", ".planning/quick/260911-mkj-windows-27-schliessen-relations-blindste/260911-mkj-PLAN.md", ".planning/quick/260911-mkj-windows-27-schliessen-relations-blindste/260911-mkj-SUMMARY.md", "apps/api/src/prisma/rls-access-inventory.spec.ts", "docs/mandantentrennung-etappe2-fehlerrichtung.md", "docs/mandantentrennung-zugriffsklassifikation.md"]
+covered_digest: "v1:sha256:d22ed49a10962fbdcd4ce1b6d931c9f4bf40f3caab84bb2af3b05b80fddba855"
+behavior_unverified: 0
+overrides_applied: 0
+---
+
+# Quick Task quick-260911-mkj: WINDOWS #27 schliessen — Relations-Blindstelle Verification Report
+
+**Task Goal:** Vierte Erkennungsform in `rls-access-inventory.spec.ts` fuer Relationszugriffe (`include:`/`select:`/`_count:`) hinzufuegen, Bestandsaufnahme fortschreiben, WINDOWS #27 schliessen, Restmenge als eigener Ledger-Eintrag fuehren.
+**Verified:** 2026-09-11T16:56:00Z
+**Status:** passed
+**Commits reviewed:** 5ad23d0, 388690f (base cc26197)
+
+## Goal Achievement
+
+### Observable Truths
+
+| # | Truth | Status | Evidence |
+|---|-------|--------|----------|
+| 1 | Der Detektor kann nicht still unterberichten (Waechter faellt laut, nicht `\|\| echo 0`) | ✓ VERIFIED | Falsified live: added `someClient.tenant.findMany({ include: { users: true } })` on an unknown receiver in a throwaway file (`apps/api/src/tmp-verify-probe/tmp-probe.service.ts`) → named test `jede include:/select:/_count:-Angabe liegt innerhalb eines erkannten Modellaufrufs...` went red (`1 failed \| 23 passed`). Also injected `select: IMPORTED_SELECT_XYZ` (unresolved identifier) in a second throwaway file → `unresolvedRelationSpecValues ist ueberall leer` went red (`2 failed \| 22 passed`). Both probes removed; suite restored to 24/24 green; `git status --short` clean before/after. |
+| 2 | Acht gepinnte Proben, darunter WINDOWS #27 ungebunden UND gebunden | ✓ VERIFIED | `rls-access-inventory.spec.ts:773-913`: Probe A (`this.prisma.tenant` → `unboundModels ⊇ {tenant, user}`), Probe B (same on `forTenant(` client → `boundModels ⊇ {tenant, user}`), plus real ldap form, nested `where` chain, scalar-select negative probe, `_count: true`, unknown receiver, constant resolution/unresolved — all 8 present and passing. |
+| 3 | 7 new pairs + 3 Stand-changes are in the classification doc with class/Stand/reason; `ldapFieldMapping` reads `beides`/`gemischt` | ✓ VERIFIED | All 10 required table rows found verbatim in `docs/mandantentrennung-zugriffsklassifikation.md`. Recomputed class distribution independently from the table: `muss-mandantengebunden 35, keine-mandantengebundene-tabelle 21, beides 14, bewusst-uebergreifend 2` = 72, matching the claimed 35/21/14/2. `ldapFieldMapping` row (line 597) carries reason text referencing `getAllActiveConfigs()`/`include: { fieldMappings: true }`. |
+| 4 | Ledger #33 exists, is open, names both zero-coverage files, not folded into #27 | ✓ VERIFIED | `.planning/WINDOWS.md` line 50: `\| 33 \| quick-260911-mkj \| unmet-truth \|...` status `open`, description names both `tenders/tenders.seed.ts` and `tenders/backfill-tender-source.ts`. Line 44: `#27` status `fixed`. Header counters (`open_count: 14`, `total_count: 33`) match table row counts exactly (33 rows, 14 open). |
+| 5 | Documented drift (926359b) is pre-existing, not caused by this execution | ✓ VERIFIED | `926359b` (docs-only: `.planning/HANDOFF.json`, `docs/mandantentrennung-etappe3-auftrag.md`) is an ancestor of `5ad23d0`. `git diff 926359b -- docs/mandantentrennung-etappe3-auftrag.md .planning/HANDOFF.json` against current HEAD is empty — neither executor commit touched these files further. The allow-list gate (`git diff --name-only cc26197`) does flag `docs/mandantentrennung-etappe3-auftrag.md` as unexpected, exactly as SUMMARY documents. |
+| 6 | Constraints held: no schema/migration/compose/env change, switch off, no service code converted | ✓ VERIFIED | `git diff --name-only cc26197 -- apps/api/prisma` empty. `git diff --name-only cc26197 \| grep -E '^(docker-compose\|apps/api/\.env\|\.env)'` empty. Only file changed under `apps/api/src` is the spec (`apps/api/src/prisma/rls-access-inventory.spec.ts`) — confirmed by grep. |
+
+**Score:** 6/6 truths verified (0 present-behavior-unverified)
+
+### Required Artifacts
+
+| Artifact | Expected | Status | Details |
+|----------|----------|--------|---------|
+| `apps/api/src/prisma/rls-access-inventory.spec.ts` | `analyzeSource`, `parseSchemaRelations`, `SCHEMA_RELATIONS`, 4th form, `RELATION_SPEC_EXCEPTIONS`, 3 watchdogs, 2 schema tests, 8 pinned probes | ✓ VERIFIED | All present (lines 209-360 for schema parsing/4th-form, 754-913 for describe block); 24 `it(` total, 24/24 green. |
+| `docs/mandantentrennung-zugriffsklassifikation.md` | 7 new rows, 3 revised Stand, rewritten gap paragraph, dated overview paragraph, `Stand 260911-mkj` paragraph + new class-distribution table, background-service nachtrag | ✓ VERIFIED | All present and recomputed to match (see truth 3 evidence). Heading stays "sechs Fälle" (no phantom new case). |
+| `docs/mandantentrennung-etappe2-fehlerrichtung.md` | `Nachtrag (260911-mkj)` under `(n4)`, note under `## Etappe 2 — Abschluss` | ✓ VERIFIED | Line 2474 `Nachtrag (260911-mkj)` inside `(n4)` block; `## Etappe 2 — Abschluss` section references `#27 ... seit 260911-mkj geschlossen`. |
+| `.planning/WINDOWS.md` | #27 `fixed`, new entry `quick-260911-mkj` for out-of-form receivers | ✓ VERIFIED | See truth 4. |
+
+### Key Link Verification
+
+| From | To | Via | Status | Details |
+|------|----|----|--------|---------|
+| `analyzeSource()` fourth form | `SCHEMA_RELATIONS` → `boundModels`/`unboundModels` | direct write, same client-name-lowercasing as doc's `Modell` column | ✓ WIRED | `scanRelationKeys()` (lines 303-360) writes directly into the same sets consumed by `findAccessSites`/`computeStandByKey`, which the pre-existing comparison tests (`jede im Quelltext gefundene (Datei, Modell)-Fundstelle ist im Dokument eingetragen`, `der eingetragene Stand stimmt`) already exercise — confirmed green. |
+| Raw count vs. matched count | `RELATION_SPEC_EXCEPTIONS` | watchdog test | ✓ WIRED | Falsified live (see truth 1). |
+
+### Behavioral Spot-Checks
+
+| Behavior | Command | Result | Status |
+|----------|---------|--------|--------|
+| Detector red on out-of-form unbound `include:` | inject throwaway file, run spec | `1 failed \| 23 passed` | ✓ PASS |
+| Detector red on unresolved constant identifier | inject throwaway file, run spec | `2 failed \| 22 passed` (cumulative) | ✓ PASS |
+| Spec green after cleanup | `npm --prefix apps/api run test -- src/prisma/rls-access-inventory.spec.ts` | 24/24 passed | ✓ PASS |
+| Full suite baseline | `npm --prefix apps/api run test` | 1007/1007 tests, 62/62 files | ✓ PASS (matches orchestrator's pre-measured baseline exactly) |
+| Type-check | `npm --prefix apps/api run type-check` | exit 0, no output | ✓ PASS |
+| Allow-list diff against `cc26197` | `git diff --name-only cc26197` | only spec + 2 docs + `.planning/**` (plus pre-existing, untouched `docs/mandantentrennung-etappe3-auftrag.md` drift) | ✓ PASS (as documented) |
+
+### Anti-Patterns Found
+
+| File | Line | Pattern | Severity | Impact |
+|------|------|---------|----------|--------|
+| `apps/api/src/prisma/rls-access-inventory.spec.ts` | 203-207 | Code comment claims the `(?=\s\|$)` lookahead in `parseSchemaRelations`'s field pattern is necessary to avoid losing list relations (`User[]` at line end) — reverting it (`(?:\[\]\|\?)?` kept, trailing lookahead removed) was tried live against the current `schema.prisma` and against the pinned `Tenant.users -> User` test; **no test went red**, and `SCHEMA_RELATIONS` still resolved identically (34 relation fields, same set) with or without the lookahead. | ℹ️ Info | Does not indicate an actual under-reporting risk today — `\w+` already stops before `[`/`?`, so the guard is currently redundant for this schema. It does mean the specific historical-bug narrative in the comment is not backed by a dedicated regression test; a future schema/regex change that reintroduces the described failure mode would not be caught by any existing assertion. Not a blocker: the primary anti-under-report protections (raw-vs-matched watchdog, unresolved-value watchdog) were independently falsified and confirmed live (see truth 1). Reverted cleanly, `git status --short` confirmed clean before continuing. |
+
+### Requirements Coverage
+
+Quick task — no formal `.planning/REQUIREMENTS.md` entries exist for `WINDOWS-27`/`ETAPPE-4-VORAUSSETZUNG` (expected; quick tasks declare requirements inline in PLAN frontmatter, not the milestone requirements ledger). Both requirement IDs are addressed by the verified truths above.
+
+### Human Verification Required
+
+None. This phase is entirely static analysis (a Vitest spec) and Markdown documentation — no UI, no runtime service behavior, no external integration. All claims were verifiable by direct command execution and falsification.
+
+### Gaps Summary
+
+None. All six derived must-haves (detector cannot silently under-report; eight pinned probes including both #27 forms; seven new pairs / three Stand changes / ldapFieldMapping reclass; Ledger #33 open and correctly scoped; documented pre-existing drift; constraints held) are verified against the actual codebase, not just against SUMMARY.md's narrative. The one ℹ️ Info finding (lookahead-revert falsification produced no red test) is a documentation/robustness nuance, not a functional gap — the detector's actual anti-under-report mechanism (the raw/matched watchdog) was independently and successfully falsified.
+
+---
+
+_Verified: 2026-09-11T16:56:00Z_
+_Verifier: Claude (gsd-verifier)_