wow20/_bmad-output/implementation-artifacts/deferred-work.md

# Deferred Work

Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Einträge werden append-only ergänzt; bestehende Einträge werden nicht verändert.

## Deferred from: code review of spec-3-3-bestehende-concepts-erweitern-präzisieren-korrigieren (Story 3.3, 2026-08-19)

- source_spec: `_bmad-output/implementation-artifacts/spec-3-3-bestehende-concepts-erweitern-präzisieren-korrigieren.md`
  summary: **`sprint-status.yaml last_updated`-Präzisions-Regression** — die Story-3.3-Sprint-Sync hat `last_updated` von `08-19-2026 13:14` (mit Uhrzeit, HEAD-Stand) auf reines Datum `08-19-2026` reduziert; die Pre-3.3-Konvention hielt die `HH:MM`-Granularität. Das Verhalten ist eine General-Eigenschaft des sync-sprint-status-Shared-Sub-Steps (Schritt-06), keine Story-3.3-Inhaltsentscheidung. Home: nächstes Sprint-Sync (Step-06) oder Sync-Verbesserung, die `last_updated` aus dem Zeitstempel ableitet.
  evidence: `git show HEAD:_bmad-output/implementation-artifacts/sprint-status.yaml` → `last_updated: 08-19-2026 13:14` vs. Working Tree `08-19-2026` (Step-04-Review 2026-08-19, Verification-Gap-Layer, re-executiert verifiziert).
  status: offen

- source_spec: `_bmad-output/implementation-artifacts/spec-3-3-bestehende-concepts-erweitern-präzisieren-korrigieren.md`
  summary: **Frozen Story-3.1-No-Op-Bullet trägt die Typos „Schärferung" und „Formata"** — `schema/compiler.md` §5.9 Pkt. 2 (No-Op, `:267`): „keine Schärferung" (inkonsistent zur konsistenten „Schärfung" der neuen operationellen Ebene) und „keiner der drei Formata" (→ „Formate"). Beide sitzen im **frozen** Story-3.1-Text (HEAD-identisch, nicht durch Story 3.3 eingeführt), den die Story-3.3-Operationelle-Ebene operationalisiert; ein fix wäre Re-Negotiation des frozen Textes (Ask-First). Home: nächste Compiler-Instruktions-Revision, die §5.9 Pkt. 2 ohnehin berührt.
  evidence: `git show HEAD:schema/compiler.md` `:267` (frozen): „keine Schärferung, keine Ersetzung … keiner der drei Formata greift" — Step-04-Review (2026-08-19, Verification-Gap-Layer), via `git show` verifiziert.
  status: offen

- source_spec: `_bmad-output/implementation-artifacts/spec-3-3-bestehende-concepts-erweitern-präzisieren-korrigieren.md`
  summary: **U6-Zwei-Run-Identitäts-Nachweis überzeichnet „auch nach Commit" und kreuzreferenziert den `generated.at`↔AD-17h-Gap nicht** — der Claim „identische SHA-256 … auch nach Commit" gilt für alpha.md (reproduzierbar `6b148dd1…`) im Worktree-/Staged-Zustand; `wiki/log.md` embeddet den random `$BASE`-SHA (`log_update`), daher weicht der log.md-Hash je Run ab (konstruktionsbedingt — der Commit ist die jeweilige Mutations-Boundary). Der at↔AD-17h-Gap (gleiche Evidenz, zwei Runs → verschiedene `at`) ist in compiler.md offen verankert. Home: Story 3.8 (Determinismus-Vertrag, AD-17h — Behandlung von `at` und des Bundle-State-Vergleichs).
  evidence: Step-04-Review (2026-08-19, Verification-Gap-Layer): Sandbox-Doppellauf — alpha.md SHA `6b148dd1…` reproduzierbar, log.md SHA je Lauf verschieden (`89b82cb2…`, `358bad3b…`); compiler.md at↔AD-17h-Hinweis (generated.at-Konvention).
  status: offen (Home: Story 3.8)

- source_spec: `_bmad-output/implementation-artifacts/spec-3-3-bestehende-concepts-erweitern-präzisieren-korrigieren.md`
  summary: **Sandbox-U2-Szenario ist selbst-erfüllend und U7 misst die reale REIHENFOLGE nicht** — U2 schärft durch Hinzufügen einer neuen Faktenbehauptung (neue Stelle), die nach dem Erweitern-Kriterium Erweitern wäre, und passt nur, weil das Präzisieren-Wording hartkodiert ist; die Form-Wahl-Prozedur selbst wird nicht geprüft. U7 begründet „v2 vor v3" als „lexikografischer Tie-Break", obwohl v2/v3 verschiedene Dateien sind (Tie-Break gilt nur bei identischem Ort); der Fall „R-1-Dateiordnung ≠ lexikografische Ordnung" bleibt ungetestet. Kein Instruktions-Defekt (Abgrenzungs-Reihenfolge ist jetzt deterministisch fixiert), sondern Test-Eigenschaften-Hinweis. Home: nächste Sandbox-Erweiterung (Story 3.4/3.5) — eine Form-Wahl-Klassifikationsprobe + U7-Ordnungs-Variante mit nicht-lexikografischer R-1-Reihenfolge.
  evidence: Step-04-Review (2026-08-19, Blind-Hunter + Verification-Gap-Layer): `run-sandbox.sh` U2 (neue Faktenbehauptung via `sed`, hartkodiertes Präzisieren-Wording), U7 (Ordering-Rationale vs. `compiler.md:268` REIHENFOLGE-Definition — Zuwachs-Sicht, lexikografisch nur bei identischem Ort).
  status: offen

- source_spec: `_bmad-output/implementation-artifacts/spec-3-3-bestehende-concepts-erweitern-präzisieren-korrigieren.md`
  summary: **Gemischte Normalisierungs-Politik im Sandbox-Evidenztext (Umlaute vs. Transkriptionen) ist ein Determinismus-Hazard für den Term-Abgleich** — Sandbox-Bodies nutzen Umlaut-Schreibweisen („Schlüssel", „läuft"), raw-Evidenz transkribiert („Schluessel"); die Abgrenzungskriterien beruhen auf Term-/Stellen-Abgleichen gegen §5.5-Inline-Verweise, und die §3.2-Normalisierung (lowercasing + `[-–_ ]`-Kollaps) deckt Umlaut-/Em-Dash-Divergenzen nicht. Bekannte Story-3.2-Lücke (Em-Dash, Home Story 3.8) plus Sandbox-interne Divergenzen. Home: Story 3.8 (Determinismus-Vertrag, Normalisierungs-Vollständigkeit) oder Sandbox-Vereinheitlichung in einer Folge-Story.
  evidence: Step-04-Review (2026-08-19, Verification-Gap-Layer): `run-sandbox.sh` — U1/U2/U3/U7 Body mit Umlaut-Schreibweisen vs. raw-Evidenz mit Transkriptionen; §3.2-Pkt.-1b-Kollaps-Klasse ohne Umlaut-/Em-Dash.
  status: offen (Home: Story 3.8)

- source_spec: `_bmad-output/implementation-artifacts/spec-1-2-sources-lokal-unter-raw-bereitstellen.md`
  summary: Checksum-/Fingerprint (SHA-256) der evtl. Git-Revision der Herkunftsquelle in `source.md` aufnehmen, damit die Provenienz reproduzierbar ist.
  evidence: Blind-Hunter-Review (Finding 1/2): `source.md`-Provenienz ist ohne Fingerprint der Quelle in einem reinen Clone nicht verifizierbar; AD-3-basiertes „neue, datierte Datei"-Schema braucht einen Maschinen-Lesbaren Stand.
  status: umgesetzt (2026-08-16, Retrospective F-09/AI-4) — Commit-Hash `6cc667d` + SHA-256 der jeweiligen Herkunftsdatei in allen drei `raw/*/source.md` aufgenommen; Byte-Identität zur materialisierten Evidenz geprüft.

- source_spec: `_bmad-output/implementation-artifacts/spec-1-2-sources-lokal-unter-raw-bereitstellen.md`
  summary: Maschinen-lesbares, validierbares Metadaten-Schema (YAML-frontmatter) für `source.md` einführen.
  evidence: Blind-Hunter-Review (Finding 13): Dokumentstand ist nur Prosa; ein späterer Ingestion-/Validierungsschritt (Story 1.3/1.4) kann ihn nicht prüfen.

- source_spec: `_bmad-output/implementation-artifacts/spec-1-2-sources-lokal-unter-raw-bereitstellen.md`
  summary: Definition für die URL-Rückweisung operationalisieren (Fehlerartefakt/Exit-Code/Log), damit Story 1.2 AC-4 testbar wird.
  evidence: Blind-Hunter-Review (Finding 17): „URL wird zurückgewiesen" ist im Source Material nur als Prosa beschrieben; kein testbares Verhalten abgelegt.

- source_spec: `_bmad-output/implementation-artifacts/spec-1-2-sources-lokal-unter-raw-bereitstellen.md`
  summary: Asset-Zuordnung (roh-`assets/` vs. `<quelle>/assets/`) in der Konvention festlegen.
  evidence: Blind-Hunter-Review (Finding 14): README nennt „einer Quelle zugeordnet oder global"; die aktuellen Sources nutzen nur global `raw/assets/`.

- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
  summary: Existenzprüfung eines `sources`-`resource`-Pfads (für Validity-Zwecke MUSS die `raw/`-Datei am Validierungszeitpunkt materialisiert vorliegen).
  evidence: Edge-Case-Review (EC-1): ein `resource` unter `raw/`, das nicht existiert, würde als Provenienz akzeptiert; der Compiler konsumiert fehlende Evidenz. Validator-Verhalten (Story 1.4), nicht Schema-Text.

- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
  summary: Kalender-Validität der Datumsfelder (`last_modified`, `stale_after`, `generated.at`/`verified.at`) — Phantom-Daten wie `2025-02-30` müssen abgelehnt werden.
  evidence: Edge-Case-Review (EC-3): reines Regex-Matching (`YYYY-MM-DD`) akzeptiert nicht existierende Kalenderdaten. Validator-Detail (Story 1.4).

- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
  summary: Operative Konsequenz von `stale_after` festlegen (Lifecycle-Übergang, Nutzungssperre als `sources`-Ziel o. ä.).
  evidence: Blind-Hunter (BH-8): §3.7 definiert nur die Veraltungsschwelle, nicht was ein veraltetes Concept bedeutet; die Folgeentscheidung gehört in Story 1.4/Lifecycle (Epic 3).

- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
  summary: `sources`-`id`-Eindeutigkeit (je `resource` bzw. je Concept) für zuverlässige per-Claim-Zitat-Attribution festlegen.
  evidence: Blind-Hunter (BH-13): §3.3 motiviert `id` für Attribution, ohne Eindeutigkeit/Scoping zu fordern; Claim-granulare Provenienz (A0-3) wird in Epic 2 konkretisiert.

- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
  summary: Verhalten nicht-Markdown-Dateien im Bundle (z. B. Bilder/Assets unter `wiki/`) definieren — Ablehnung oder Konvention.
  evidence: Edge-Case-Review (EC-11): der Vertrag regelt nur `.md`-Dateien; ein `wiki/<area>/logo.png` hat keinen definierten Status. Structural-Seed-/Validator-Frage (Story 1.4).

- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
  summary: Exakte ISO-8601-Form für `generated.at`/`verified.at` festlegen (z. B. `YYYY-MM-DDTHH:MM:SS(Z|±HH:MM)?`, reine Datumsangaben zulässig?).
  evidence: Blind-Hunter (BH-14)/Edge-Case-Review (EC-7): „ISO-8601-Datetime" lässt den Validator-Spielraum; Story 1.4 muss eine Normalform bestimmen, um Run-Determinismus zu sichern.

- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
  summary: Normalisierung von `sources: []`/`verified: []` vs. Absenz für deterministische Ausgabe-/Diff-Baselines klären.
  evidence: Edge-Case-Review (F2, Loop 2): beide Formen sind laut Vertrag gültig und semantisch gleichwertig; NFR-4 („sinnvolle Diffs") bleibt unterdeterminiert. Normierungsentscheidung des Compilers/Validators — Story 1.4.

- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
  summary: Trust-Semantik von `generated.by` mit `human:`-Präfix festlegen (Person als Generator vs. „human-reviewed"-Klassifikation).
  evidence: Edge-Case-Review (F15, Loop 2): `generated.by: human:michael` ohne `verified` ist formzulässig, aber die Trust-Klassifikation (nicht-human-reviewed trotz `human:` in `generated.by`) ist für Leser missverständlich. Für Story 1.4/Epic 4 (Trust-Metadaten) klären.

- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
  summary: Reihenfolge/atomare Kopplung von `log.md`-Eintrag (AD-16b) und `status`-Mutation (Deprecation) in denselben Compilation Run festlegen.
  evidence: Edge-Case-Review (F5, Loop 2): `status: deprecated` erfordert einen `log.md`-Disagreement-Eintrag; der Vertrag regelt nicht die atomare Kopplung dieser zwei Bundle-Mutationen. AD-16/Story 4.2/Compiler-Verhalten.

- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
  summary: Feingranularität von `log.md` festlegen (leeres Log zulässig? Pflicht der AD-16-Konfliktklassifikation je Eintrag?).
  evidence: Edge-Case-Review (F17, Loop 2): §5 definiert Format (Datum + Eintragsliste), aber nicht, ob ein leeres `log.md` gültig ist bzw. ob die Konfliktklassifikation Pflicht-Inhalt je Eintrag ist. OKF §9-Feinheiten für Story 1.4.

- source_spec: `_bmad-output/implementation-artifacts/spec-1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren.md`
  summary: Semantische Konsequenz von `stale_after` im Verhältnis zur Validität klären („veraltet" ist kein struktureller Validierungsfehler).
  evidence: Edge-Case-Review (F18, Loop 2): §7 zählt die Konsequenz nicht auf; ein vergangenes `stale_after` ist gültiges YAML, aber „veraltet". Lifecycle-Semantik — Story 1.4/Epic 3.

- source_spec: `_bmad-output/implementation-artifacts/spec-1-4-schema-validierung-für-bundle-implementieren.md`
  summary: Genau-eine-erlaubte-Linkform für den Punkt-11-Index-Check festlegen (mit vs. ohne `.md`-Endung) — Story 2.3.
  evidence: Step-04-Review (Story 1.4, Loop 1): Der Validator-Punkt-11-Check akzeptiert beide Linkformen (relativer Bundle-Pfad mit oder ohne `.md`-Endung), weil die genau-eine-Form-Regel (A0-9/AD-7b) erst Story 2.3 definiert. Der Determinismus-Anspruch des Validators bleibt gewahrt (beide Formen zählen als verlinkt); eine Endungs-Festlegung würde die abschließende §7-Liste erweitern und gehört in Story 2.3.
  status: umgesetzt (2026-08-17, Story 2.3) — Linkform in `schema/compiler.md` §5.6 gepinnt (bundle-relativ **mit** `.md`-Endung; Rationale: Null-Migration der 3 Concept-Links in `wiki/index.md`, explizite Datei-Ziele, Standard-Markdown-Tools — AD-7b/A0-9/FR-10/AD-8) inkl. vier re-executierbarer Selbsttest-Formeln (AD-17h). Der Validator bleibt strukturell unverändert (Punkt 11 akzeptiert beide Schreibweisen — Story-2.2-Präzedenz, D-3); die konsistente Nachführung der „Story 2.3"-Notizen in `schema/validator.md` (Punkt 11, §8) bleibt Rev-9-Kandidat (Eintrag unten).

- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md`
  summary: F-03/AI-3 — gewählter Weg dokumentiert: §3.2-Voraussetzungsprüfungen als V-1/V-2-fachliche Prüfklasse (Revision 5). Die alternative Option „Vertrag §7 um Fall ‚fehlende Bundleroot' erweitern (mit Autorisierung)" wurde bewusst NICHT gewählt; sollte später ein Fall „fehlende Bundleroot" in den §7-Katalog selbst (statt als V-1) gefordert sein, ist dies nachzuholen (Vertrags-Änderung via Story-Verfahren).
  evidence: Retrospective F-03 Disposition „Fix-now (als fachliche Prüfungen V-1/V-2 labeln … oder Vertrag §7 erweitern)" — Entscheidung für Option 1 getroffen (2026-08-16, AI-3).

## Folge-Aufgaben aus Epic-1-Retrospective (Defer-Kontexte, AI-7; 2026-08-16)

> Diese Einträge sichern die von der Epic-1-Retrospective (2026-08-15) als Defer klassifizierten Befunde als konkrete Folge-Aufgaben. Sie sind **nicht** durch die Validator-Revisionen 3–6 behoben — nur als Kontext für Epic-2/3 bzw. die nächste Validator-Revision notiert.

- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-04)
  summary: Verschachtelte Duplikat-Keys in `sources`/`verified`-Einträgen behandeln — Punkt 13 zählt nur doppelte Keys auf oberster Frontmatter-Ebene; YAML erlaubt mehrdeutig doppelte `resource`-Keys innerhalb eines Eintrags (Parser-abhängiger Gewinner). Bei der nächsten Validator-Revision (Epic-2-Start) klären: Abdeckung der Innen-Ebenen oder bewusst dokumentierte Abgrenzung.
  evidence: Retrospective F-04.

- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-06)
  summary: `today`-Zeitzone für die `stale_after`-WARN (Validator §6.4) deterministisch festlegen — „heute in UTC abgeleitet" ist nicht hart definiert (Kalenderdatum des UTC-Zeitpunkts vs. lokaler Tag). Determinismus-Anspruch (AD-17h) vor Epic-3 (Lifecycle-Konsequenz) sauber machen.
  evidence: Retrospective F-06.

- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-07)
  summary: Index-Regel bei verschachtelten Areas/Unter-Ebenen konkretisieren — „Area als eine `index.md` tiefer als `wiki/`" lässt für `wiki/a/b/concept.md` offen, was „Area mit Inhalt" ist. Epic-2-Story 2.5 (progressive Discovery) legt die Antwort fest; vorher gilt die heutige Definition.
  evidence: Retrospective F-07; Offene Frage 2 der Retro; spec-1-4 Story 2.3-Linkform.
  status: umgesetzt (2026-08-18, Story 2.5 — konsolidierte Zwei-Ebenen-Kartografie, §5.8)

- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-08)
  summary: Konvention für `.MD`-Großschreibung unter `wiki/` klären (Windows-Portabilität, NFR-1/NFR-5) — heute ist nur exakt `.md` (case-sensitive) ein Concept; auf win32 kann ein Tool `foo.MD` erzeugen. Vor Epic-2-Concepts entscheiden: Ablehnung/FAIL oder case-insensitive Behandlung.
  evidence: Retrospective F-08.

- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-11)
  summary: Normreferenz der OKF-0.2-Spezifikation verlinkbar machen (Vertrag §8, Validator §8) — das Prosa-Zitat „OKF-Spezifikation (Google Cloud, `knowledge-catalog`)" ohne URL/Version ist nicht auflösbar; `okf_version`-Regel und §7-Punkt-14 hängen daran. Kleine Korrektur bei nächster Autorisierung (Vertrag) ergänzen.
  evidence: Retrospective F-11.

- source_spec: `_bmad-output/implementation-artifacts/epic-1-retro-2026-08-15.md` (F-14)
  summary: Negativ-Fixture für `resource`-Pfade, die außerhalb `raw/` landen aber existieren (z. B. `README.md`) — §6.2 Schritt 5 deckt den Fall ab, aber das Durchstechen ist nur durch Beispiele belegt. Fixture bei nächster Validator-Revision ergänzen (analog §7.3).
  evidence: Retrospective F-14.

## Folge-Aufgaben aus Story-2.1-Review (Defer-Kontexte; 2026-08-16)

> Diese Einträge sichern die im Step-04-Review von Story 2.1 als Defer klassifizierten Befunde als konkrete Folge-Aufgaben. Sie sind **nicht** durch die Nachschärfungen (compiler.md Revision 1.2, validator.md Revision 7, index.md, log.md, sprint-status) behoben.

- source_spec: `_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md` (Story-2.1-Review)
  summary: Content-Truth-Verifikation einführen — kein bestehender Check verifiziert, dass der Body eines Concepts seinen deklarierten `raw/`-Quellen (Inhalt) entspricht. Die drei Concepts sind aktuell inhaltlich korrekt (Spot-Checks im Review bestätigt), aber Validator (§3 rein strukturell), spec-Verification (grep-Smoke) und compiler.md-Selbsttests (Kriterien 1–3) decken nur Form/Existenz, nicht den Inhalt. Verifikation, dass erfundenes/gegenläufiges Body-Content nicht als kuratierte Wahrheit durchgeht, ist die Kern-Fähigkeit (FR-2/FR-5).
  evidence: Verification-Gap-Review (Story 2.1): Demonstriert — Body-Fälschung bei byte-identischem Frontmatter ändert kein Verdikt und keinen grep-Check. Für Story 2.2 (Claim-granulare Provenienz, AD-4a/A0-3) bzw. eine spätere Inhaltstreue-Prüfung.

- source_spec: `_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md` (Story-2.1-Review)
  summary: Determinismus-Selbsttest-Dokumentation in `schema/compiler.md` schärfen — §6.6-Interpretations-Hinweis behauptet, die ✓-Form sei „genau diese Form … im Demonstrationslauf erfüllt"; da `generated.at` pro Run variiert (Ausführungszeitpunkt, AD-15), ist der Selbsttest (Kriterium 2 „at-Normalform") als Form-Verifikation über die Normalform statt über einen festen `at`-Sekundenwert zu formulieren, damit ein „Regenerate"-Vergleich auf einem OTHER-Diff-Basis nicht an der Run-Zeit scheitert (Punkt-14-sicher). Für Story 2.3 (Determinismus/A0-7-Verifikation) bzw. nächste Validator-Revision.
  evidence: Edge-Case-Review (Story 2.1): „Determinism self-test compares generated.at which varies per run" — eines von mehreren als Defer klassifizierten Findings (die übrigen ebenfalls in diesem Block).

## Deferred from: code review of story-2.1 (2026-08-16)

> **Code-Review-Defer (bmad-code-review, 2026-08-16):** Diese Einträge decken die im externen Adverse-Review von Story 2.1 als Defer klassifizierten Befunde ab, die bewusst nicht in Story 2.1 behoben werden. Sie sind getrennt von den Step-04-Review-Defer-Kontexten oben (die der Implementierung selbst entstammen).

> **Dedupe-Verweis (bmad-code-review Re-Run, 2026-08-17):** „Content-Truth-Verifikation einführen" und „Determinismus-Selbsttest-Dokumentation schärfen" wurden am 2026-08-16 bereits im Block „Folge-Aufgaben aus Story-2.1-Review (Defer-Kontexte; 2026-08-16)" oben erfasst (gleicher Tag, nahezu identischer Text, nur anderes `source_spec`-Label). Die Ownership liegt dort; dieser Code-Review-Block trägt beide Punkte **nicht** ein zweites Mal (vermeidet Doppel-Erledigung). Konkret: Content-Truth → Story 2.2; Determinismus-Selbsttest → Story 2.3 / nächste Validator-Revision.

- source_spec: `schema/validator.md` (Story 1.4) — aufgelöst via Option A
  summary: Frieren-Verletzung heilen — die Innen-Ebenen-Klarstellung (Punkt-6 / Key-Subset auf `sources`/`generated`-Eintragsebene), die Spot 2.1 als Rev-7-Notiz in `schema/validator.md` eingetragen hat, muss in der **nächsten autorisierten Validator-Revision** formal mitlaufen (gemeinsam mit der F-14-Negativ-Fixture). Dadurch verliert die Abweichung ihren Status als unautorisierte Mutation und Story 2.1 ist `done`-fähig. Der Rev-7-Hinweis bleibt bis dahin erhalten (kein Rückbau).
  evidence: Code Review (Story 2.1) — Decision-Befund, aufgelöst als Option A am 2026-08-16.

- source_spec: `raw/README.md` (Konvention, Story 1.2) — R-1
  summary: R-1 (Compiler-Input-Interface) — Verdikt **Bestanden**: `schema/compiler.md` definiert seine Source-Eingabe als Menge beliebiger `raw/`-Dateien (Set-Interface, §1.2 „jede Datei unter `raw/` ist Evidenz"), nicht als einzelnen Pfad. Der erkennungsseitige Mechanismus, WELCHE `raw/`-Dateien wann verarbeitet werden („Run-ohne-Pfad"-Nutzererwartung aus DRYRUN.md: Kompilation via git diff + SHA-256-Record aus den `source.md`-Records), ist bewusst nicht in Story 2.1 enthalten und gehört als Erkennungs-/Auswahl-Mechanismus in die AD-5-Home-Story (Epic 3, Story 3.1/3.2).
  evidence: Code Review (Story 2.1) R-1 — Epic-3-Forward-Risk, keine AC-Verletzung.
  status: aufgegriffen (2026-08-18, Story 3.1 — §5.9): Input-Zuwachserkennung als Change-Detection-Baustein des inkrementellen Runs in `schema/compiler.md` §5.9 Pkt. 6 verankert (Determinismus `git diff` auf `raw/` und/oder SHA-256-Record aus `raw/**/source.md`; unveränderte `raw/`-Dateien bleiben außen vor; fehlender/unlesbarer SHA-256-Record → textueller Hinweis, keine Doppel-Verarbeitung).

- source_spec: `raw/README.md` / `schema/compiler.md` §1.2–§1.4 — R-2
  summary: R-2 (Nicht-Markdown-Quellen) — Verdikt **Bestanden**: die Compiler-Instruktion liest Sources endungsneutral als Datei (§1.2/§1.4), unterstellt keine `.md`-Endung; PDF ist zulässige Evidenz (Vertrag §3.3 verlangt nur einen Dateipfad unter `raw/`, Validator EC-1 prüft nur Existenz). Die Konventions-/Asset-Zuordnungsfrage (Namensschema für Nicht-Markdown-Quellen) bleibt offen und gehört zu Epic 2/3 (Nutzer-Input-Gestaltung für den Dryrun-Forderungskatalog). Als dokumentarischer Hinweis: §1.2/§1.4-Widerspruch („jede Datei ist Evidenz" vs. „Artefakt-Dateien sind KEIN Input") in der Instruktion selbst klären (siehe Patch-Findings in der Story).
  evidence: Code Review (Story 2.1) R-2 — Konventionsfrage, kein Blocker.

## Deferred from: code review of story-2.1 (2026-08-16) — Arbeitsauftrag: autorisierte Validator-Revision (Option-A-Heilung)

> **Konkreter Arbeitsauftrag (aus Re-Review vom 2026-08-16):** Sobald die nächste **autorisierte Validator-Revision** beginnt (Story-/Autorisierungs-Kanal, Bereich `schema/`, Konsistenz mit dem Story-1.4-Prozess), sind die folgenden drei Punkte dort formal zu tragen. Sie machen Story 2.1 `done`-fähig und schließen die Referenzkette compiler.md → validator.md sauber. `validator.md` selbst bleibt bis dahin unverändert (Frieren/AD-3).

- summary: **1. F-14-Negativ-Fixture ergänzen** — ein `resource`-Pfad, der außerhalb `raw/` landet, aber existiert (z. B. `resource: README.md`), hat bislang kein Negativ-Fixture; §6.2 deckt den Fall, §7.1-Fixtures belegen ihn nicht (Retrospective F-14, epic-1-retro AI-7). In der autorisierten Revision als Negativ-Fixture ergänzen (erwartetes Verdikt: `FAIL … Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (…|…)`), Beleg unter §7.1 (Punkt 4).
- summary: **2. Innen-Ebenen-Key-Subset-Klarstellung formal tragen** — die heute als unautorisierte Rev-7-Notiz in `validator.md` §7.3 (Punkt 6: unautorisierte Keys innerhalb `sources`/`generated`/`verified`-Einträgen, Vertrag §3.3–§3.5) liegende Klarstellung wird Teil der autorisierten Revision; damit verliert sie ihren Status als unautorisierte Mutation und Story 2.1 ist `done`-fähig. (Kann mit F-14 in einer gemeinsamen Revision laufen.)
- summary: **3. Validator-Header-Revisionszahl anheben (OBS-1)** — `schema/validator.md` §0-Header trägt weiter „Validator-Revision: 6", während der Revisionslog (§8) als letzten Eintrag „Revision 7" führt (pre-existing Selbst-Inkonsistenz). In derselben autorisierten Revision den Header auf die dann aktuelle Revisionszahl anheben — damit schließt sich die von compiler.md §0/§8 auf „Revision 7" referenzierte Kette header-seitig. (Korrektur jetzt nicht möglich, da `validator.md` friert.)
  evidence: Re-Review (Code Review Story 2.1), 2026-08-16 — Option-A-Home-Story; Epic-1-Retrospective F-14/AI-7 (Defer-Kontexte, deferred-work.md).
  status: umgesetzt (2026-08-17) — siehe autorisierte Validator-Revision 8 (`validator-revision-8-autorisationsrunde-f14-innen-ebenen.md`): F-14-Fixture 4a, Innen-Ebenen-Klarstellung formal getragen, Header auf „Revision 8" angehoben (OBS-1 behoben); Story 2.1 damit `done`-fähig.

## Folge-Einträge aus dem Sandbox-Dryrun (PDF/RADIUM, Prozess-Optimierungs-Bericht; 2026-08-17)

> **Herkunft:** Nutzer-Probelauf in `D:\mita\wow-2nd-sandbox` (Compiler Rev 1.3 gegen `raw/MetaModel.pdf`, 11 radium-Concepts OKF-konform als positivem R-2-Beleg ausgeführt) — siehe `review-input-dryrun-2-1-pdf-radium.md` im selben Verzeichnis. Der Bericht (vom Nutzer erstellt) enthält Tooling-/Prozess-Optimierungs-Maßnahmen (P1/P2/P3) **auf Ausführungs-/Werkzeug-Ebene**, keine Norm-Änderungen (D-3). Diese Einträge sichern die Folge-Aufgaben; die detaillierte Zuordnung (inkl. Konformitäts-Bewertung) steht im Review-Input-Dokument.

- source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P1)
  summary: Fixture-Selbsttest des Validator-Prüfwerkzeugs vor jedem Bundle-Lauf etablieren (P1) — jede Negativ-Fixture (`validator.md` §7.1, n=21) muss ein deterministisches FAIL mit Ursache erzeugen, jede Positiv-Fixture (§7.2/§7.3, ~20) SUCCESS; optional die „Skript-Fallen" (PyYAML-`datetime`-Parsing statt Textform §4.3, relative Link-Auflösung Punkt 11, `usage_count`-Float) als eigene Negativ-Fixtures ergänzen. Nutzen: Fehler des Prüfwerkzeugs werden vor Berührung des Bundles sichtbar (im Probelauf 2 Diagnose-Zyklen durch Falsch-FAILs des Prüfskripts vermeidbar). D-3-tauglich (rein textueller Check-Block, kein Standalone).
  evidence: Prozess-Optimierungs-Bericht §3.1/§4.1 (Tooling-Diagnose-Zyklen, Punkt-11-Identity-Match; korrigiert: kein Instruktions-Defekt); Review-Input §2/§4 (Konformität: D-3/AD-17h).

- source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P1)
  summary: Feste `.compile-run/`-Arbeitskonvention einführen (P1) — vom Workspace getragene, per Konvention (.gitignore) ausgeschlossene Fläche für deterministische Textextraktion der Quelle (z. B. `sources-<quelle>-<datum>.txt`), Prüfskripte (inkl. Fixture-Selbsttest) und `run-protokoll.md` (Prüfsummen, Verlinkungs-Check, Verdikte je Run). Nutzen: Reproduzierbarkeit/Auditierbarkeit (AD-17h) ohne `raw/` zu berühren (AD-3), agent-übergreifend gleiche Konvention (AD-10). Kein Verstoß gegen D-3 (textuelle Artefakte, kein Standalone-Programm).
  evidence: Prozess-Optimierungs-Bericht §3.4/§4.2; Review-Input §4 (Konformität: AD-3/AD-10/AD-17h/D-3).

- source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P1)
  summary: Einmalige `at`-Festlegung pro Compilation Run deterministisch identisch in alle erzeugten `generated.at` schreiben (P1) — der Run bestimmt **einen** Ablauf-Zeitstempel (UTC) für alle Dateien; optional als textuelle Konvention in `compiler.md` §4.3 ergänzen (Kanonisierung auf `Z`-Form, da der Validator §4.3 sowohl `±HHMM` als auch `Z` akzeptiert — keine Vertrags-Änderung nötig). Nutzen: keine Timing-Drift/Inkonsistenz über Dateien, einfachere Diff-/Nachvollziehbarkeit. Deckt sich mit dem Defer zur Determinismus-Selbsttest-Schärfung (Kriterium 2 „`at`-Normalform").
  evidence: Prozess-Optimierungs-Bericht §3.3/§4.3; Review-Input §4 (Validator-neutral: §4.3 akzeptiert `Z` und `±HHMM`).

- source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P2)
  summary: Pre-Run-Reconcile-Vorphase als deterministischen Pre-Plan-Schritt bündeln und dokumentieren (P2) — die textuellen Reconcile-Prüfungen (Ziel-Pfad-Kollision, Quellen-Existenz, AD-5-Relevanz der Quelle auf bestehende Concepts, `index.md`-Vorbedingung V-1) zu einem wiederverwendbaren Check-Block zusammenfassen (statt manueller Mehrfach-Checks, Bericht §3.2). Kein neuer Standalone-Prozess — nur ein reproduzierbarer Check-Block innerhalb der Instruktions-Ausführung; als Compiler-Instruktions-Schärfung (Story 2.1-Follow-up) oder Epic-3-Home (AD-5) einzuarbeiten.
  evidence: Prozess-Optimierungs-Bericht §3.2/§4.4; Review-Input §4 (D-3-konform).
  status: aufgegriffen (2026-08-18, Story 3.1 — §5.9): Pre-Run-Reconcile-Check-Block als wiederverwendbarer textueller Vorprüf-Block der Run-Vorphase in `schema/compiler.md` §5.9 Pkt. 6 verankert (Ziel-Pfade bzw. Ausgangs-Kandidatenliste, Quellen-Existenz EC-1 via Validator-Punkt, Betroffenheits-Kandidatenliste §3 Pkt. 2, `wiki/index.md`-V-1-Vorbedingung — fehlende Bundleroot → Run-FAIL, Vertrag §2); vor jeder Mutation durchlaufen und textuell festgehalten; kein neuer Standalone-Prozess (D-3).

## Review-Findings Story 3.1 (Step-04-Review, 2026-08-18) — Patch-/Klärungs-Protokoll

> **Herkunft:** Step-04-Review der Story 3.1 (Patch-Runde) über die drei Review-Layer (Blind Hunter / Edge Case Hunter / Verification Gap). Die klassifizierten Findings wurden direkt umgesetzt (Patch-Runde in `schema/compiler.md` Revision **2.4.1** + den Begleitdateien); die folgenden Einträge halten Befunde fest, die nicht geschehener Patch sind, sondern **Konzuls-Status**, und sichern verbleibende Gaps als konkrete Folge-Aufgaben.

- summary: **Story-3.1-Review: Diff-Selbsttest-Ausgabe (Pkt. 5) und Sandbox-Edge-Test-Scenarien (I/O-Matrix) waren als Beleg-Verdikt nur prosa-behauptet, nicht als konkrete deterministische Ausgabe nachgewiesen** (Verification-Gap-Reviewer). Heilung: `wiki/log.md`-Eintrag 2026-08-18 wurde in einen realen **Story-3.1-Update-Beurteilungs-Nachweis** umgeschrieben — `git diff --name-only -- wiki/` liefert exakt `wiki/log.md` (deterministischer Ist-Ausgabe-Befund, kein Ghost-Diff); die fünf Sandbox-Edge-Tests der I/O-Matrix (HAPPY_PATH_UPDATE, UNTOUCHED_CONCEPT, CONCEPT_COLLISION_BESTEHEND, CHANGE_DETECTION, PRE_RUN_RECONCILE) sind als deterministische Proben auf synthetischen Bäumen re-executierbar dokumentiert. Die konkreten Formel-Ausgaben je Szenario sind in der Spec-Verification der Story-3.1-Spezifikation enthalten.
  evidence: Step-04-Review Story 3.1, VG-Reviewer; Verifikations-Nachweis.
  status: umgesetzt (2026-08-18, Story 3.1 Patch-Runde) —
   - `git diff --name-only -- wiki/` → `wiki/log.md` (die `--name-only`-Form listet Pfade, nicht Insertions-Zählungen; der ursprüngliche Beleg notierte beides vermischt) — kein Ghost-Diff
   - Sandbox-Edge-Tests der I/O-Matrix → deterministische Formel-Ausgaben je Szenario: **konkret belegt** in der Story-3.1-Spec-`## Verification Record (Ausführungs-Beleg, 2026-08-19)` (re-executierbar: `bash _bmad-output/implementation-artifacts/sandbox-3-1/run-sandbox.sh` — S1–S5 I/O-Matrix + S6 INPUT_UNCOMMITTED-Kontrolle; bmad-code-review Loop 2, D-4-Resolution)
   - `git status --porcelain` → 4 modificiert + 2 untracked (der Schema-/Artefakt-/Spec-Teil liegt außerhalb `wiki/` und ist kein Ghost-Diff)
   - Loop-2-Nachführung (2026-08-19): die operative Probe ist seit `schema/compiler.md` Revision 2.4.2 (D-1) `git diff --name-only <Baseline-Commit> -- wiki/` + `git status --porcelain -- wiki/` (vor Commit, Pfad-Normalisierung Strip `wiki/` + `.md`); die zitierte Vor-2.4.1-Form (`--stat`) war die Rev-2.4-Notation — s. `wiki/log.md` 2026-08-19-Eintrag (b)
- summary: **Story-3.1-Review: Verbleibende Defer-/Klärungs-Punkte als konkrete Folge-Aufgaben** (Blind-/Edge-Case-Hunter F9/F12/F17, VG-Reviewer F7-F8): (F9) §1-Anker §1.1/§1.4 → §1 Pkt. 1/Pkt. 4 nachgeführt (Patch in Revision 2.4.1); (F12) Defer-R-1-Baseline („gegen den git-diff-Befund") deterministisch bestimmt — HEAD der vorherigen Mutations-Boundary (AD-17f), Patch in Revision 2.4.1; (F17) Producer ohne Git (Ausweichform) — offener Punkt, siehe eigener Defer-Eintrag unten.
  evidence: Step-04-Review Story 3.1, EH/BH/VG (F9/F12/F17).
  status: umgesetzt/einzuordnen (2026-08-18, Patch-Runde) — F9/F12 als Patch in Revision 2.4.1; F17 als neue Defer-Aufgabe unten.
- source_spec: `_bmad-output/implementation-artifacts/spec-3-1-inkrementellen-datenfluss-implementieren-interpret-reconcile-synthesize-update.md`
  summary: **Neue Folge-Aufgabe (Story-3.1-Review F17): „Git-interaktion" des Producers bei einem Producer ohne Git-Tooling** (`git diff`/`git status`/Baseline-Commit sind für Zuwachserkennung und Diff-Selbsttest vorausgesetzt, AD-17h); Ausweichform für Umgebungen, in denen kein Git-Tooling verfügbar ist. Als Teil des Determinismus-Vertrags (AD-17h) werden `git`-Befunde als verlässlich behandelt; eine git-lose Partition ist als Ausweichform zu beschreiben (dokumentarische Konvention, D-3) — Vorschlag: der Producer (Agent) spiegelt die Zuwachserkennung über ein textuelles Eingabe-Manifest statt des `git diff`-Befunds und die Diff-Probe über ein Datei-Baseline-Manifest (Checksummen) — bis dahin bleibt Git für den Producer vorausgesetzt (NFR-1/NFR-5, Git-Bash auf win32). (Loop-2-Korrektur 2026-08-19: `source_spec`-Feld ergänzt — Schemaabweichung zu allen anderen Einträgen; Akteur „Executive" → „Producer (Agent)" — „Executive" ist in der D-3-Semantik undefiniert, der ausführende Akteur der Instruktion ist der Producer/Agent; die „Nutzer-Entscheidung 1/1 (Story 3.2)"-Referenz entfällt — Story 3.2 ist `backlog`, eine solche Entscheidung existiert nicht.)
  evidence: Step-04-Review Story 3.1, EH (F17).
  status: offen — Home: mit Story 3.2 (Relevanzbestimmung, `backlog`) oder der AD-17h-Absicherung (Story 3.8) zu klären; als Ausweichform (dokumentarische Konvention, D-3) zu spezifizieren.

- summary: **Story-3.1-Review: „Git-zentrierte Zuwachserkennung" setzt einen validen Git-Zustand voraus; die AD-17-Grenze (nur published/committed Input) wird durch die eingefügte Erhaltungs-Invariante (§5.9 Pkt. 5, Erhaltungs-Diff) und die Ghost-Diff-Konsequenz (Rück-Rollen vor Run-Gültigkeit, `log.md`-Kopplung als Abbruch-Vorlauf) hinreichend verbunden** — Kein neuer Folge-Gap; dokumentiert für die Nachvollziehbarkeit des Review-Nachweises.
  status: Kein Gap — abgeschlossen (Patch in Revision 2.4.1).

- source_spec: `_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md` (Sandbox-Dryrun, P2)
  summary: Provenienz-Checksumme bei mehrfacher Verwendung einer Quelle im Blick behalten (P2, Vorbereitung Epic 3/Story 2.2) — bei 11 Concepts aus einer Quelle (`raw/MetaModel.pdf`) ist eine wie auch immer geartete SHA-256/`last_modified`-Angabe Kandidat für `sources`-Metadaten; erst ab der zulässigen Schema-Erweiterung (Story 2.2 Claim-provenienz / Epic 3) in der Instruktion verankern. NICHT jetzt implementieren — `sources`-Subset (Vertrag §3.3, Punkt 6/§7) bleibt unverändert.
  evidence: Prozess-Optimierungs-Bericht §4.5; Review-Input §4 (vertragskonform: Schema-Subset unangetastet); verknüpft mit Defer zum „`sources`-`id`-Eindeutigkeit" (BH-13).

## Deferred from: code review of story-2.1 (2026-08-17)

> **Unabhängiger Re-Run (bmad-code-review, 2026-08-17)** auf dem Stand nach Validator-Rev-8 (HEAD `ae5e0aa`). Die tragenden Story-2.1-Artefakte sind validator-clean (alle 8 ACs PASS); die Defer-Einträge unten sind bewusst nicht in Story 2.1 behobene bzw. vorbestehende Punkte.

- source_spec: `_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md` (Code-Review-Re-Run 2026-08-17)
  summary: Content-Truth-Verifikation — keine Änderung zum bereits deferrierten Punkt (Story 2.2), aber der Re-Run liefert eine konkrete, prüfbare Instanz: das ASCII-Datenfluss-Diagramm-Layout in `wiki/knowledge-kompilation-inkrementell.md` stammt aus `raw/architecture-spine/…`, während das Concept `sources: raw/epics/…` deklariert (Inhalt kuratiert/korrekt, nur die exakte Diagrammform nicht von der deklarierten Source gedeckt).
  evidence: Acceptance-Auditor (Informational) + Blind Hunter; die anderen beiden Concepts sind vollständig in ihren deklarierten Sources verankert.

- source_spec: `_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md` (Code-Review-Re-Run 2026-08-17)
  summary: Concept-Bodies präsentieren Epic-3/4-Fähigkeiten als aktuelle Tatsache ohne Forward-Referenz-Marker — `knowledge-kompilation-inkrementell.md`: „Verbindung zu Regelwerken" (NEW/CONFIRMING-CORRECTING-Klassifikation, grep/ripgrep-Relevanzbestimmung → Story 3.2/4.1) und „FR-6 Aktualisierung statt neuer Dateien" (→ Story 3.1, die `compiler.md` §7 explizit nicht baut und deren Kollision-Hold §3.2 auf bestehendem Pfad abbricht). Zu markieren, sobald die Claim-Provenienz-/Kontext-Marker-Logik (Story 2.2) existiert.
  evidence: Blind Hunter (2 Einzelfindings); Epic-3/4-Zuordnung belegt in `raw/epics/…` (Story 3.1/3.2, 4.1).

- source_spec: `_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md` (Code-Review-Re-Run 2026-08-17)
  summary: `wiki/log.md` akkumuliert Meta-/Prozess-Einträge (Review-Verdikt, Action-Item-Statusflips, Validator-Revision-Ankündigungen) ohne Marker, der sie von Vertrag-§5-„fachlichen Änderungen" unterscheidet — vorbestehendes Muster (die Retrospective-Follow-up-Einträge tun dasselbe), nicht neu durch diesen Diff verursacht; F17 defert Log-Content-Validierung bewusst.
  evidence: Blind Hunter; pre-existing.

### Geholderte validator.md-Patches — Arbeitsauftrag für die nächste autorisierte Validator-Revision (Rev 9)

> **Herkunft:** Unabhängiger bmad-code-review Re-Run (2026-08-17), Patches 16/17. Beide betreffen die am 2026-08-17 autorisierte, gefrorene `schema/validator.md` (Rev 8) — ihre Anwendung setzt einen **neuen Autorisierungsschlag** auf `schema/` voraus und wurde im Re-Run bewusst **nicht** mitgepatcht (Frieren-Prinzip, Analogie zur Option-A-Heilung F-14). `validator.md` selbst bleibt bis zur autorisierten Revision unverändert.

- summary: **1. Punkt-4-Fehlerursachen-Grammatik um `resolved=`-Token erweitern** — Fixture 4a (§7.1) erwartet `FAIL … Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (resolved=README.md)`, aber die §3-Punkt-4-Vorlage `(..-Traversal|absolut|URL|Backslash|file://)` trägt kein `resolved=`-Token; §7 verlangt „exakt die aus §3". In der autorisierten Revision die Punkt-4-Vorlage um ein optionales `resolved=<Pfad>`-Token ergänzen (oder die Fixture-Vorlage an die Vorlage angleichen) + Zertifizierung der Fixture 4a (isoliert, genau Punkt 4) neu ausführen.
- summary: **2. Innen-Ebenen-Punkt-6-Fixture-Zeile ergänzen** — die in Rev 8 formalisierte Innen-Ebenen-Regel (Punkt 6: unautorisierte Keys in `sources`/`generated`/`verified`-Einträgen, Vertrag §3.3–§3.5) hat keine Fixture-Zeile in §7.1/§7.3; der einzige Punkt-6-Fixture ist Top-Level `foo: bar`, §7.3 zeigt `sources … role: x` nur als Inline-Prosa-Beispiel. In der autorisierten Revision eine Negativ-Fixture-Zeile (z. B. `sources`-Eintrag mit `role: x` bei existierender `raw/`-Datei → `FAIL … Punkt 6`) ergänzen + Zertifizierung (isoliertes Sample) + Nachweis in `wiki/log.md` nachführen.
  evidence: bmad-code-review Re-Run (2026-08-17) — Blind Hunter + Verification-Gap; beides betrifft die gefrorene Rev 8.
  status: offen — Home: nächste autorisierte Validator-Revision (Rev 9), Validator-Kanal; **kein Story-2.1-Blocker** (Story bleibt `review`, `done`-fähig; verbleibende Schwelle = Human-Review). Verknüpft mit Action-Item `code-review-2-1-item-2`.

## Deferred from: code review of story-2.2 (2026-08-17)

> **Step-04-Review (Story 2.2, 2026-08-17):** Von der Verification-Gap-Schicht als Defer klassifizierter Befund — kein Story-2.2-Blocker, da die Story die Markierungs-Syntax liefert und nicht die inhaltliche/kleine Closure-Verifikation.

- source_spec: `_bmad-output/implementation-artifacts/spec-2-2-claim-granulare-provenienz-dokumentieren.md`
  summary: Sources-Closure-Verifikation einführen — jeder inline-referenzierte `raw/`-Pfad eines Concept-Bodies (per deterministischer Extraktion aus `(raw/…`-Verweisen) MUSS im `sources`-Frontmatter desselben Concepts deklariert sein (inkl. neuer `sources`-Einträge für Relokation/Zielwechsel, §5.5-Pkt.-1b-Regel). Aktuell prüft nur der `grep -nE '\(raw/'`-Existenz-Smoke die Präsenz des Verweises, nicht seine Zuordnung zu einer deklarierten Ressource; EC-1 prüft nur die deklarierten `sources`-Ressourcen, nicht inline-referenzierte. Ein inline-Verweis auf eine nicht deklarierte `raw/`-Datei (Beispiel im Story-2.2-Body behoben) bliebe sonst unsichtbar.
  evidence: Verification-Gap-Review (Story 2.2): Demonstriert an `wiki/wissensarchitektur-trennung-states.md` (Consumer-Unabhängigkeit zitierte `raw/epics/…` ohne `sources`-Deklaration — im Story-2.2-Patch behoben); kein re-runnable Check deckt die Abgeschlossenheit ab (D-3-konforme Deterministische Closure-Prüfung, analog grep-Pipeline, kein Standalone).
  status: offen — Home: spätere fokussierte Validator-/Instruktions-Runde (Rev 9-Kandidat), Validator-/Instruktions-Kanal; **kein Story-2.2-Blocker** (Story liefert die Markierungs-Syntax, nicht die Closure-Prüfung).
- source_spec: `_bmad-output/implementation-artifacts/spec-2-2-claim-granulare-provenienz-dokumentieren.md`
  summary: **Stellen-Kennung-Existenz im Rohdokument wird nirgends geprüft** — §5.5 Pkt.1 macht die Existenz des `#`-Fragments im referenzierten Rohdokument zur harten Regel (ganzer Sinn der s1/s2-Korrektur), aber kein Check verifiziert sie: nicht der strukturelle Validator (keiner der 14 Punkte liest Fragment-Targets), nicht die Spec-Verification-Greps (nur `(raw/`-Präsenz), nicht die Selbsttest-Formel. Fragment-Typo (z. B. `#FR-19`) oder verbotenes Concept-`id`-Fragment `#s1` durchläuft den gesamten Pfad mit SUCCESS und liefert genau die Falsch-Attribution, die die Regel verhindern soll (Worked-Example-Grammatik ungeprüft). D-3-konforme deterministische Prüfung (Fragment tritt als Zeilenanker/Sektionstitel in `raw/<pfad>` auf; Negativ: kein `^s[0-9]+$`-Fragment), Schwester zu W1.
  evidence: Verification-Gap-Review (bmad-code-review Story 2.2, 2026-08-17): Validator-14-Punkte-Katalog + EC-1 im Volltext gelesen (keine Fragment-Auflösung); alle aktuellen Fragmente der drei Concepts händisch gegen `raw/` verifiziert (alle auflösen) — aber nichts pinnt es; Demonstrationsfall `…(raw/epics/…md#FR-19)` → SUCCESS.
  status: offen — Home: spätere fokussierte Validator-/Instruktions-Runde (Rev 9-Kandidat), Schwester zu W1; **kein Story-2.2-Blocker**.
- source_spec: `_bmad-output/implementation-artifacts/spec-2-2-claim-granulare-provenienz-dokumentieren.md`
  summary: **Kontext-Marker-Grammatik (Selbstreferenz-Verbot, Musterwahl, exakter Token-Platz) ungeprüft** — §5.5 Pkt.2 definiert die Marker-Muster mit obligatorischem exaktem Token „nicht eigenständig belegt" und das neue Selbstreferenz-Verbot (Rev 1.6); der Lauf-Gate-Selbsttest (Pkt.4) und die Spec-Manual-Checks behaupten nur Token-Präsenz, nicht die Musterform oder das Selbstreferenz-Verbot. Ein Selbstreferenz-Marker (Concept nennt sich selbst als Ursprung) trägt den exakten Token und passiert jede re-runnable Prüfung mit SUCCESS — das Verbot ist durch nichts erzwingbar. Demonstrationsfall `übernommen aus wiki/<eigenes-Concept> auf Basis von raw/epics/… nicht eigenständig belegt` → SUCCESS. D-3-konforme Prüfung (Token pro Concept extrahieren, Pattern-Match gegen die kanonischen Formen, `<Concept-Pfad>` gegen eigenen OKF-Pfad vergleichen), Schwester zu W1.
  evidence: Verification-Gap-Review (bmad-code-review Story 2.2, 2026-08-17): Punkt 9-Inhaltsscan prüft nur `okf_version`/`type: bundle`; die drei aktuellen Marker-Stellen (`knowledge-kompilation:37,52`, `llm-wiki-prinzip:40`, `wissensarchitektur:30`) konform gelesen — aber nichts pinnt die Grammatik; die Pre-Patch-Selbstreferenz (Klassifikation P5) beweist, dass der Fehler nur durch Review-Lesbarkeit, nicht durch re-runnable Checks auffindbar war.
  status: offen — Home: spätere fokussierte Validator-/Instruktions-Runde, Schwester zu W1; **kein Story-2.2-Blocker**.
- source_spec: `_bmad-output/implementation-artifacts/spec-2-2-claim-granulare-provenienz-dokumentieren.md`
  summary: **`sources`-`id`-Eindeutigkeit je Concept ohne Check und ohne Selbsttest-Hook** — §5.5 Pkt.3 führt die Regel „`id`-Werte je Concept eindeutig" ein und wird in allen drei Concepts angewendet (neue `id: s1`/`s2`), aber Validator Punkt 6 prüft Keys (nicht Wert-Duplikate), Punkt 13 nur Top-Level-Frontmatter-Duplikate, die Spec-Greps prüfen Feldpräsenz/`resource`-Werte, und §5.5 Pkt.4 (Selbsttest-Kriterien) führt die id-Eindeutigkeitsregel gar nicht auf. Duplizierte `id`-Werte (z. B. beide `s1` in `knowledge-kompilation:4-7`) liefern SUCCESS. D-3-konforme Prüfung (kein `sources[].id`-Wert tritt im selben File doppelt auf) + Eintrag in §5.5 Pkt.4, Schwester zu W1.
  evidence: Verification-Gap-Review (bmad-code-review Story 2.2, 2026-08-17): Punkt 6/13 im Volltext gelesen; Demonstrationsfall beide Einträge `id: s1` → alle Punkte + Greps SUCCESS.
  status: offen — Home: spätere fokussierte Validator-/Instruktions-Runde, Schwester zu W1; **kein Story-2.2-Blocker**.
- source_spec: `_bmad-output/implementation-artifacts/spec-2-3-concepts-verlinken-eine-erlaubte-linkform.md`
  summary: **Stale „Story 2.3"-Klauseln in `schema/validator.md`** (Punkt 11, L70; §8, L297) tragen weiterhin die Notiz „Festlegung ist Story 2.3", obwohl Story 2.3 die Linkform in `schema/compiler.md` §5.6 gepinnt hat. Der Validator bleibt strukturell unverändert (akzeptiert beide Schreibweisen — D-3, Story-2.2-Präzedenz), aber die Notizen sind jetzt inkonsistent mit dem Ist-Zustand; eine konsistente Nachführung (Notiz auf „gepinnte Form: compiler.md §5.6" umstellen) gehört in die nächste autorisierte Validator-Revision (Rev-9-Kandidat), nicht in Story 2.3 (kein Validator-Change, Ask-First).
  evidence: Step-04-Review (Blind-Hunter, Loop 1): `validator.md` Punkt 11 und §8 gelesen — beide nennen Story 2.3 als offene Festlegung; Story 2.3 ist `in-review` und hat §5.6 gesetzt.
  status: offen — Home: nächste autorisierte Validator-Revision (Rev 9-Kandidat), Validator-Kanal; **kein Story-2.3-Blocker** (Validator-Einschränkung wäre eigene Autorisierung, Ask-First).
- source_spec: `_bmad-output/implementation-artifacts/spec-2-3-concepts-verlinken-eine-erlaubte-linkform.md`
  summary: **Selbsttest-Formeln in `compiler.md` §5.6 sind gegenüber `)` im Link-Target blind** — die Grep-Pipeline `grep -ohE '\]\([^)]+\)'` beendet die Ziel-Extraktion am ersten `)`, so dass ein (inadäquates) Ziel wie `wiki/foo).md` als `wiki/foo.` extrahiert wird; der Dangling-Check meldet dann `DANGLING: wiki/foo.` und der Form-Check zählt das Ziel als Formfehler — die Detektion ist also konservativ (faust-positiv, kein Stiller-Vorbei), aber die Fehlerursache-Meldung benennt das falsche (abgeschnittene) Ziel. Für den aktuellen flachen Bundle-Root (keine Areas, keine Sonderzeichen in Kebab-Case-Slugs, AD-7a) ist der Fall nicht erreichbar; bei künftiger Area-Einbettung (Story 2.4) oder wenn OKF-Pfade `)` zulassen sollten, wäre die Formel zu präzisieren (z. B. balanciertes-Parens-Matching via `awk`/`sed`-Pipeline, D-3-konform, kein Standalone).
  evidence: Step-04-Review (Edge-Case-Hunter, Loop 1): Negativ-Test in `/tmp/lk/wiki` — `](foo).md)`-Ziel wird als `foo.` extrahiert; aktuelle 8 internen Ziele des Bundles enthalten kein `)` (Bestands-Check), Kebab-Case-Slug-Regel (§5.1) verbietet `)` strukturell.
  status: offen — Home: fokussierte Instruktionseinschärfung ab Story 2.5 (Story-2.4-Kandidat-Home vorangeschoben — Story 2.4 ist 2026-08-18 ohne Umsetzung dieses Falls abgeschlossen, Loop-2-Review-Weiterleitung); **kein Story-2.3-Blocker** (Detektion bleibt konservativ korrekt).
- source_spec: `_bmad-output/implementation-artifacts/spec-2-3-concepts-verlinken-eine-erlaubte-linkform.md`
  summary: **Cross-Page-Anker in Concept-Links (`file.md#sec`) sind derzeit Form-Verletzung** — die gepinnte Form ist strikt „bundle-relativ mit `.md`-Endung"; ein Ziel wie `llm-wiki-prinzip.md#s1` endet nicht mit `.md` und wird vom Form-Check gezählt (Run-FAIL, NFR-4), vom Dangling-Check zusätzlich als `DANGLING` benannt. Das Verhalten ist deterministisch und korrekt gem. Pin, aber ob AD-7b („bundle-relativ, mit oder ohne Endung") Fragmente zulassen soll, ist eine normative Frage, die kein Check beantwortet. Entscheidung + ggf. Formel-Anpassung (Fragment-Stripping vor dem `-f`-Test, Analogie Gleichseit-Anker) gehören in eine spätere Instruktions-/Validator-Runde — nicht in Story 2.3 (feste Pin-Form nicht öffnen).
  evidence: Step-04-Review (Edge-Case-Hunter, Loop 1): Synthese-Test `concepts.md#s1` → Form-Check `1` + `DANGLING: concepts.md#s1` (Zieldatei existiert); I/O-Matrix-Zeile GLEICHSSEIT_ANKER deckt nur `#…`-Ziele ab, Cross-Page-Fall ist nicht Gegenstand der gefrorenen Intent.
  status: offen — Home: fokussierte Instruktionsrunde ab Story 2.5 (Story-2.4-Kandidat-Home vorangeschoben — Story 2.4 ist 2026-08-18 ohne Umsetzung dieser Frage abgeschlossen, Loop-2-Review-Weiterleitung); **kein Story-2.3-Blocker** (Detektion konservativ korrekt, kein stiller Vorbeilass).
- source_spec: `_bmad-output/implementation-artifacts/spec-2-3-concepts-verlinken-eine-erlaubte-linkform.md`
  summary: **Area-Kontext: Bundlerelativ vs. Dateirelativ bei Standard-Tools** — §5.6 Pkt. 1 führt als Rationale an, Standard-Markdown-Tools lösten Links „ohne Konventionswissen" auf; das gilt exakt im flatten Bundle (Root-Concepts), wo datei- und bundlerelativ identisch sind. In künftigen `wiki/<area>/`-Concepts (Story 2.4) löst ein Standard-Tool `](beta/c2.md)` dateirelativ (→ `wiki/alpha/beta/c2.md`, falsch), während die gepinnte Form nach AD-7b bundlerelativ bleibt und der Dangling-Check bundleroot-relativ prüft. Die Spannung zwischen AD-7b (bundlerelativ) und „Standard-Tools-Auflösung" in Areas ist ein Story-2.4-Thema (dort: deterministische Area-Zuordnung + Index-Regel für Areas).
  evidence: Step-04-Review (Verification-Gap, Loop 1): Rationale-Satz in §5.6 Pkt. 1 gelesen; Dangling-Check-Auflösung `[ -f "wiki/$t" ]` ist bundleroot-relativ; Synthese-Baum `/tmp/area` zeigt: bundlerelative Area-Links (`beta/c2.md` aus `alpha/c1.md`) lösen im Check korrekt auf, in Standard-Renderern aber nicht.
  status: umgesetzt (2026-08-18, Story 2.4) — §5.7 Pkt. 4 der Compiler-Instruktion legt das **file-relative** Link-Auflösungsmodell fest (`../`-Präfix für in-Bundle-Aufwärts-Ziele; eine syntaktische Form für Root + Area; Standard-Markdown-Tools lösen dateirelativ auf — die Rationale „ohne Konventionswissen" gilt damit auch in Areas). §5.6 Pkt. 1/2/3 um die `../`-Schärfung nachgeführt (Formel 3: file-relatives Resolve mit `..`-Kollabierung und Containment unter `wiki/`, Out-of-Bundle-`..`-Escape → `DANGLING`); der Rationale-Satz in §5.6 Pkt. 1 nennt die Form jetzt explizit zwei-ebenentauglich (Root + Area, Story 2.4). **kein Story-2.3-Blocker** war / bleibt gelöst.

## Deferred from: code review of spec-2-3-concepts-verlinken-eine-erlaubte-linkform (2026-08-17)

- source_spec: `_bmad-output/implementation-artifacts/spec-2-3-concepts-verlinken-eine-erlaubte-linkform.md`
  summary: **`log.md`-Exklusions-Begründung in §5.6 Pkt.2/Verification ist für Formeln 1–3 gegenstandslos** — die Begründung „sie enthält die Formel-Texte selbst als Zitate und würde die Zählungen verunreinigen" ist im Ist-Zustand unzutreffend: `wiki/log.md` enthält aktuell **0** `](`-Muster, die Exklusion ändert für Formeln 1–3 nichts; lasttragend ist sie nur für Formel 4 (log.md enthält 4 `(raw/`-Vorkommen — ohne Exklusion 34 statt 30 ggü. Baseline 30). Solange der Story-2.2-`27-Treffer`-Zitat-Zeile (enthält `(raw/`) in log.md bleibt, ist die Formel korrekt re-executierbar; die Begründungs-Formulierung ist präzisierenswert, kein Funktionsfehler.
  evidence: bmad-code-review Story 2.3 (2026-08-17, Verification-Gap-Layer): `grep -roE ']\([^)]*\)' wiki/log.md` → 0; `grep -oE '\(raw/' wiki/log.md` → 4.
  status: offen — Home: dokumentarische Präzisierung einer späteren Instruktions-Runde; **kein Story-2.3-Blocker** (Formel bleibt AD-17h-re-executierbar).

- source_spec: `_bmad-output/implementation-artifacts/spec-2-3-concepts-verlinken-eine-erlaubte-linkform.md`
  summary: **Cross-Page-Defer-Eintrag (L221–222) beschreibt Prä-Patch-Dangling-Verhalten als Ist-Zustand** — der Eintrag behauptet, ein Ziel `concepts.md#s1` liefere vom Dangling-Check zusätzlich `DANGLING: concepts.md#s1` (Zieldatei existiert), während die im selben Change shipende §5.6-Pkt.3-/Verification-Formel 3 das Fragment VOR dem Existenztest stripped (`p=${t%%#*}`) und genau diesen Fall als „keine Ausgabe" benennt. Die Evidenz-Zeile dokumentiert den Stand vor Rev 1.9 (Punkt 5 des Patchs); die Beschreibung des Solutions-Verhaltens (Cross-Page-Anker ist Form-Verletzung, normativ offen) bleibt korrekt.
  evidence: bmad-code-review Story 2.3 (2026-08-17, Blind-Hunter-Layer): Defer-Text L221–222 vs. `schema/compiler.md` §5.6 Pkt.3 (`p=${t%%#*}`) + Verification Formel 3 gelesen; Fragment-Strip ist Teil von Revision 1.9 (gleicher Commit). 
  status: umgesetzt (2026-08-18, Story 2.4, dokumentarische Korrektur) — Eintrag auf Ist-Verhalten korrigiert: der §5.6-Formel-3-Dangling-Check stripped das Fragment vor dem Existenztest (`p=${t%%#*}`), ein Ziel `concepts.md#s1` erzeugt bei existierender Datei **keine** Dangling-Ausgabe (die Pin-Form-Frage bleibt beim Form-Check); die Beschreibung des Solutions-Verhaltens (Cross-Page-Anker ist Form-Verletzung, normativ offen) bleibt korrekt und ist als offene normative Frage in deferred-work.md weiterhin notiert.

- source_spec: `_bmad-output/implementation-artifacts/spec-2-3-concepts-verlinken-eine-erlaubte-linkform.md`
  summary: **Image-/Nicht-Navigations-`](...)` ohne definierten Scope in §5.6** — die Formeln werten `![alt](img.png)` (Markdown-Image) und `[x](./y.md)` als „Concept-Link" und zählen Images als Form-Verletzung; §5.6 Pkt.2 definiert den Geltungsbereich („Beziehungen zwischen Concepts … normale Markdown-Links") ohne `![`-Guard oder Sachlich-Ausnahme. Für das aktuelle Bundle irrelevant (keine Images); bei künftigem Wiki-Media-Einsatz erzwingt die Formel `.md`-Endung für Bildpfade oder erzeugt False-Positives. Ggf. `grep -vE '!\['`-Guard bei Bedarf (Story 2.4/2.5).
  evidence: bmad-code-review Story 2.3 (2026-08-17, Edge-Case-Hunter-Layer): Synthese-Test ` ![alt](img.png)` → Form-Check zählt `1`; §5.6-Pkt.2-Scope-Text ohne Image-Ausnahme.
  status: offen — Home: spätere Instruktions-/Media-Runde; **kein Story-2.3-Blocker** (aktuell keine Images im Bundle).

- source_spec: `_bmad-output/implementation-artifacts/spec-2-3-concepts-verlinken-eine-erlaubte-linkform.md`
  summary: **Multi-Line-Link-Targets für alle §5.6-Formeln unsichtbar** — `grep -roE ']\([^)]*\)'` ist ein Ein-Zeilen-Matcher; ein über zwei Zeilen geteiltes Ziel `](nichtda\nbar.md)` wird von Form-Check, Dangling-Check und Bestands-Check nicht erfasst → toter Link passiert **stillschweigend** (NFR-4-Verletzung, kein Fehlalarm). CommonMark erlaubt Zeilenumbrüche in Link-Zielen; bei künftiger Verwendung wäre balanciertes-Parens-/Multi-Line-Matching nötig (D-3-konform, kein Standalone). Für das aktuelle Bundle irrelevant (keine Multi-Line-Links, Kebab-Case-Slug-Konvention, AD-7a).
  evidence: bmad-code-review Story 2.3 (2026-08-17, Edge-Case-Hunter-Layer): Synthese-Eingabe `[x](foo.md\nbar.md)` → alle drei Formeln ohne Treffer.
  status: offen — Home: fokussierte Instruktionsrunde ab Story 2.5 (Story-2.4-Kandidat-Home vorangeschoben — Story 2.4 ist 2026-08-18 ohne Umsetzung dieser Frage abgeschlossen, Loop-2-Review-Weiterleitung); **kein Story-2.3-Blocker** (aktuell keine Multi-Line-Ziele).

- source_spec: `_bmad-output/implementation-artifacts/spec-2-3-concepts-verlinken-eine-erlaubte-linkform.md`
  summary: **Reference-Style-Links (`[x][ref]` + `[ref]: ziel.md`) für die §5.6-Formeln unsichtbar** — keine Formel scannt Definitionszeilen `^\[[^]]+\]:`; ein per Reference-Style verlinktes Ziel passiert Bestands-, Form- und Dangling-Check ohne Meldung (zweite Form der Konzept-Verlinkung, AD-7b-Zwei-Producer-Problem wiederherstellbar). Für das aktuelle Bundle irrelevant (alle Links inline); bei künftiger Nutzung Definitions-Scan ergänzen oder Reference-Form explizit ausschließen.
  evidence: bmad-code-review Story 2.3 (2026-08-17, Edge-Case-Hunter-Layer): Synthese-`[x][ref]`/`[ref]: ziel.md` → keine Formel-Ausgabe.
  status: offen — Home: spätere Instruktions-Runde; **kein Story-2.3-Blocker** (aktuell keine Reference-Style-Links).

- source_spec: `_bmad-output/implementation-artifacts/spec-2-3-concepts-verlinken-eine-erlaubte-linkform.md`
  summary: **Leading-Space-Ziel `]( ziel.md)` wird als Form-konform UND vorhanden gewertet** — `grep -oE ']\([^)]*\)'` matcht das Leerzeichen nach `(`; `sed`/`read` strippen es nicht; `^[^#]+\.md$` matcht ` ziel.md` (führendes Leerzeichen ist `[^#]+`), `[ -f "wiki/ ziel.md" ]` schlägt fehl → Form-Check `0` (falsch), Dangling-Check `DANGLING:  ziel.md` (getrimmt). CommonMark erlaubt keine Leerzeichen direkt nach `(`. Konservativ richtungsweisend, aber Form-Check-Aussage „0" ist für solch ähnelnde Ziele unzuverlässig. Für das aktuelle Bundle irrelevant (keine solchen Ziele); Whitespace-Verbot vor `-f`-Test ergänzbar.
  evidence: bmad-code-review Story 2.3 (2026-08-17, Edge-Case-Hunter-Layer): Synthese-Eingabe `]( ziel.md)` → Form-Check `0` + Dangling `DANGLING: ziel.md`.
  status: offen — Home: spätere Instruktions-Runde; **kein Story-2.3-Blocker** (aktuell keine solchen Ziele).

- source_spec: `_bmad-output/implementation-artifacts/spec-2-3-concepts-verlinken-eine-erlaubte-linkform.md`
  summary: **künftiges `wiki/<area>/log.md` bricht die Baseline-Extraktion (Formel 4)** — der Baseline-Filter `grep -v "wiki/log.md$"` entfernt nur das Top-Level-log.md; `--exclude=log.md` in der Ist-Zählung schließt aber auch ein zukünftiges Area-log.md aus → Baseline/Ist-Dateimengen divergieren, falscher FAIL (AD-17h-Nicht-Determinismus). Für den aktuellen flachen Bundle-Root irrelevant (keine Areas bis Story 2.4); bei Area-Einführung Filter auf Basename umstellen (`grep -v 'log.md$'` analog zu `--exclude=log.md`).
  evidence: bmad-code-review Story 2.3 (2026-08-17, Edge-Case-Hunter-Layer): Synthese-Baum `wiki/alpha/log.md` → Baseline-Filter lässt sie durch, `--exclude=log.md` nicht.
  status: umgesetzt (2026-08-18, Story 2.4, Area-Einführung) — §5.6 Pkt. 3, Formel 4: der Baseline-Filter ist jetzt `grep -v "log.md$"` (Basename-Match) statt des bisherigen `grep -v "wiki/log.md$"` (Pfad-Match); damit sind Baseline-Extraktion und Ist-Zählung konsistent beide Basename-`log.md`-exkludierend (konsistent mit `--exclude=log.md`), auch bei künftigen Area-`log.md`-Dateien (AD-17h-Determinismus).

## Deferred from: code review of spec-2-4-deterministische-bereichszuordnung-concept-hierarchie (2026-08-18)

- source_spec: `_bmad-output/implementation-artifacts/spec-2-4-deterministische-bereichszuordnung-concept-hierarchie.md`
  summary: **Spec-Frontmatter `status: 'done'` bei offenem Review-Zyklus** — spec-2-4 trägt `status: 'done'` + `review_loop_iteration: 1`, während `sprint-status.yaml` `review` (Review offen) zeigt; nach dem spec-2-3-Präzedenz (`done` erst nach Review-Freigabe) ist das Frontmatter der Prozesslage voraus. Der Status wird mit dem Abschluss dieses Review-Loops (Loop 2) synchron — kein separates Patch.
  evidence: bmad-code-review Story 2.4 (2026-08-18, Blind-Hunter-Layer): spec-Frontmatter vs. `sprint-status.yaml:49` + spec-2-3-Präzedenz (status done, review_loop_iteration 2).
  status: umgesetzt (2026-08-18, Loop-2-Abschluss) — Status synchronisiert: `sprint-status.yaml` `2-4-…` → `done` (Review-Loop 2 abgeschlossen: 3 Decision-Resolutions 1/1/1, 14 Patches umgesetzt, Defer-Regelungen hier verankert); die spec-Frontmatter `status: 'done'` ist damit deckungsgleich mit dem Sprint-Status (spec-2-3-Präzedenz erfüllt).

- source_spec: `_bmad-output/implementation-artifacts/spec-2-4-deterministische-bereichszuordnung-concept-hierarchie.md`
  summary: **Gefrorene I/O-Matrix „6 `wiki/`-Dateien" + Grammatik „stillem Overwrite"** — die frozen-after-approval-I/O-Matrix (HAPPY_PATH: „Validator SUCCESS (6 `wiki/`-Dateien; Punkte 1/6/8/9/10/11/14, EC-1)"; TOP_LEVEL_COLLISION: „kein stiller Overwrite" → „stillem") ist nur per menschlicher Renegotiation änderbar; der Log dokumentiert 7 Dateien inkl. `log.md`. Wird mit der Loop-2-Spec-Amendierung (Decision-Resolution) nachgeführt.
  evidence: bmad-code-review Story 2.4 (2026-08-18, Blind-Hunter-Layer): spec-I/O-Matrix L74/L75 vs. `wiki/log.md:4` (7 Dateien, anderer Punkt-Satz) + Validator-Punkt-9-Semantik (`okf_version`/`type: bundle`-Verbot, nicht log.md-Validierung).
  status: umgesetzt (2026-08-18, Loop-2-Abschluss) — Die nicht-gefrorene Spec-Verification ist auf 7 `wiki/`-Dateien + korrekten Punkt-Satz nachgeführt; die frozen-after-approval-I/O-Matrix bleibt „6 `wiki/`-Dateien" (Defizitzählung) und „stillem Overwrite" (Grammatik) — beides bleibt frozen (nur per menschlicher Renegotiation änderbar, AD-3) und ist Änderungskandidat für die nächste Renegotiations-Runde.

- source_spec: `_bmad-output/implementation-artifacts/spec-2-4-deterministische-bereichszuordnung-concept-hierarchie.md`
  summary: **ID-Kollision Area-`index.md` vs. Root-Concept nicht vom §3.2-Hold gedeckt** — `wiki/<a>/index.md` (Identität `<a>` per index-Strip) und `wiki/<a>.md` (Identität `<a>`) normalisieren auf dieselbe AD-7a-Identität, ohne dass eine Dateikollision entsteht; der §3.2-Kollisions-Hold feuert nur auf Dateikollision, das Verhalten bei reiner Identitätskollision ist undefiniert. Ein Fix erfordert §3.2-Erweiterung bzw. Vertrags-/Validator-Änderung (AD-3 read-only, „kein neues Prädikat") — übersteigt den Story-2.4-Rahmen.
  evidence: bmad-code-review Story 2.4 (2026-08-18, Edge-Case-Hunter-Layer): §5.7 Pkt. 2-ID-Tabelle (`wiki/wissensarchitektur/index.md` → `wissensarchitektur`) vs. §3.2-Dateikollisions-Prädikat (compiler.md L40); kein Fixture, kein Hold-Trigger für Identitäts-Kollision.
  status: offen — Home: nächste autorisierte Validator-/Vertragsrevision (analog Rev-8/Rev-9-Verfahren).

- source_spec: `_bmad-output/implementation-artifacts/spec-2-4-deterministische-bereichszuordnung-concept-hierarchie.md`
  summary: **Spec-These „Validator Punkt 11 akzeptiert bereits Areas" wird vom read-only-Validator-Text nicht gedeckt** — Punkt 11 (validator.md L70) verlangt, die Concept-Identität sei „als relativer Bundle-Pfad referenziert (mit oder ohne `.md`-Endung)"; die Area-`index.md` verlinkt file-relativ `source-material.md`, die Bundle-Identität `wissensarchitektur/source-material` erscheint in der Area-`index.md` textuell weder mit noch ohne Endung → ein wörtlicher mechanischer Punkt-11-Check meldete `Concept nicht verlinkt=wissensarchitektur/source-material`; der SUCCESS-Nachweis der Log (7/7 SUCCESS inkl. Punkt 11) ist damit nicht unabhängig überprüfbar. Fix = autorisierte Validator-Revision (Punkt 11 um die Area-Lesart schärfen: Area-Index erfüllt den Link per Area-localem Pfad der Concept-Datei) — AD-3-Blocker.
  evidence: bmad-code-review Story 2.4 (2026-08-18, Acceptance-Auditor-Layer): validator.md L70 (Punkt 11, read-only) vs. `wiki/wissensarchitektur/index.md` L9 (`[Source Material…](source-material.md)`) + Spec-Always-Bullet „Validator Punkt 11 akzeptiert bereits Areas … strukturell unverändert".
  status: offen — Home: Rev-9-Aktionsitem (`code-review-2-1-item-2`, open) — dort um Punkt-11-Area-Lesart ergänzen.

## Deferred from: code review of spec-2-5-progressive-discovery-über-index-md-bereitstellen (2026-08-18)

- source_spec: `_bmad-output/implementation-artifacts/spec-2-5-progressive-discovery-über-index-md-bereitstellen.md`
  summary: **Spec-Frontmatter `status: 'done'` bei offenem Review-Zyklus** (spec Z. 5) — Story-2.4-Präzedenz (deferred-work.md Z. 269–272): `done` erst nach Review-Freigabe; mit dem Abschluss dieses Review-Loops synchron (s. Step 6), kein separates Patch.
  evidence: bmad-code-review Story 2.5 (2026-08-18, Loop 3, 4 Layer: Blind-Hunter + Edge-Case-Hunter + Verification-Gap + Acceptance-Auditor): Review-Findings-Sektion der Spec (2026-08-18).
  status: umgesetzt (2026-08-18, Loop-3-Abschluss) — Status synchronisiert: Spec-Frontmatter `status: 'done'` + `review_loop_iteration: 3` deckungsgleich mit `sprint-status.yaml` (Key `2-5-…` → `done`, `last_updated` nachgeführt); alle `decision-needed` und `patch`-Befunde aufgelöst/umgesetzt.

- source_spec: `_bmad-output/implementation-artifacts/spec-2-5-progressive-discovery-über-index-md-bereitstellen.md`
  summary: **Frozen-Text-Wortfehl- und Konsistenz-Kandidaten (nur per menschlicher Renegotiation änderbar)** (spec Z. 18/42/43) — Änderungskandidaten für die nächste Renegotiationsrunde (Story-2.4-Präzedenz): (a) Intent Z. 18 „Revisionslog **(3.x)**" — implementiert ist **2.3** (Reihenfolge 2.0/2.1/2.2/2.3); (b) I/O-Matrix `DISCOVERY_DEMO_ROOT_AREA_LINK` Z. 42: „zusätzlich **überdacht** in das Area-Concept" — Wortfehler + Verlinkungsrichtung unauflösbar (nicht-gefrorene Seite s. Patch „Index-Link-Oxymoron"); (c) I/O-Matrix `SEARCH_GREP` Z. 43: `grep -n <term> wiki/` nicht ausführbar (nicht-gefrorene Seite s. Patch „Consumer-Suchbeispiel"); (d) Intent Z. 18 „Kein Interface-/Backend-/Datenbank-**Änderung**" (Grammatik: „Keine … Änderungen").
  evidence: bmad-code-review Story 2.5 (2026-08-18, Loop 3, 4 Layer: Blind-Hunter + Edge-Case-Hunter + Verification-Gap + Acceptance-Auditor): Review-Findings-Sektion der Spec (2026-08-18).
  status: offen



## Deferred from: code review of spec-3-1-inkrementellen-datenfluss-implementieren-interpret-reconcile-synthesize-update (2026-08-19)

- source_spec: `_bmad-output/implementation-artifacts/spec-3-1-inkrementellen-datenfluss-implementieren-interpret-reconcile-synthesize-update.md`
  summary: **V-1-Cross-Referenz dreistufig und nie explizit aufgelöst** — der P2-Check-Block (compiler.md §5.9 Pkt. 6) zitiert `wiki/index.md`-V-1 als „Vertrag §2", während V-1 die §3.2-Voraussetzungsprüfung des Validators ist; die Kette compiler-§3-Pkt.-3 ↔ Validator-§3.2 ↔ Vertrag-§2 ist dreistufig und nicht explizit aufgelöst. Bestehendes Referenz-Idiom der Instruktion (Epic-1/Epic-2-Ära), nicht von Story 3.1 verursacht; Home: nächste Compiler-Instruktions-Revision, die §3/Pkt. 3 ohnehin berührt.
  evidence: bmad-code-review Story 3.1 (2026-08-19, Blind-Hunter-Layer F14): compiler.md §5.9 Pkt. 6 Pkt. (4) vs. validator.md §3.2-Voraussetzungsprüfung (V-1/V-2-Label, Epic-1-Retro-F-03) vs. wiki-compiler.md §2 (Bundleroot).
  status: offen

- source_spec: `_bmad-output/implementation-artifacts/spec-3-1-inkrementellen-datenfluss-implementieren-interpret-reconcile-synthesize-update.md`
  summary: **`epic-3-context.md` ist ein neues Artefakt außerhalb der Spec-Code-Map** — die Code Map listet exakt compiler.md / log.md / deferred-work.md / sprint-status.yaml (sonst read-only); die 50-Zeilen-Context-Datei (im Story-3.1-Commit neu) wird nirgends referenziert oder als erzeugt dokumentiert. Vom build-Verfahren (compile-epic-context) erzeugtes Kontext-Artefakt, keine Story-Inhalts-Mutation, kein Always/Ask-First/Never-Verstoß; Home: Story-3.2-Handoff oder nächstes Sprint-Sync (einzeilige Nennung im log.md-Nachweis genügt).
  evidence: bmad-code-review Story 3.1 (2026-08-19, Acceptance-Auditor-Layer): Spec-Code-Map vs. `git show efc543c --stat` (6 Dateien, `epic-3-context.md` new file).
  status: aufgegriffen (2026-08-19, Story 3.2) — einzeilige Nennung im `wiki/log.md`-Eintrag der Story 3.2 erfolgt; `epic-3-context.md` bleibt als vom build-Verfahren erzeugtes Kontext-Artefakt bestehen (keine Story-Inhalts-Mutation; Deckung über die Spec-`context:`-Frontmatter der Story-3.2-Spezifikation).
## Deferred from: Story 3.2 (Relevanzbestimmung, 2026-08-19)

- source_spec: `schema/compiler.md` §3.2-Pkt.-1b (Story 3.2)
  summary: **Em-Dash-»—«-Varianten-Lücke der Normalisierung** — die Kollaps-Klasse `[-–_ ]` (En-Dash »–«, Bindestrich »-«, Unterstrich »_«, Leerzeichen) deckt den Em-Dash »—« **nicht** ab. Eine Schreibvariante mit Em-Dash (z. B. »wissen — relevanz«, aus dem Kontext einer externen Quelle eingelesen) fällt nicht unter den Kollaps und wird nicht zu einer identischen canonischen Form normalisiert — eine erkannte Synonym-/Determinismus-Lücke der Relevanzbestimmung (A0-18/A0-19). Wird nicht stillschweigend in §3.2 ergänzt, sondern als offene Determinismus-Frage an **Story 3.8** (Determinismus-Vertrag, AD-17h) übergeben; bis dahin wird ein nicht auflösbarer Em-Dash-Term **wie notiert** verwendet (Kollaps-normalisiert, kein stiller Ausschluss).
  evidence: Story-3.2-Review-Umsetzung (2026-08-19) — §3.2-Pkt.-1b dokumentiert die Lücke explizit als »Bekannte Determinismus-Lücke (aufgezeichnet, nicht still hinzugefügt)« und beruft sich auf diesen deferred-work-Eintrag als Handoff-Ziel.
  status: offen (Home: Story 3.8)

## Deferred from: code review of spec-3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip (2026-08-19)

- source_spec: `_bmad-output/implementation-artifacts/spec-3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip.md`
  summary: **`§3.2`-Pkt.-2a: Wortgrenzen-/Frontmatter-Scope der Stufe-a-Match-Semantik ist offen** — die Grep/rg-Erhebung matcht ohne Wortgrenze (Substring: `alpha` trifft `alphabet`) und dateiweit inkl. YAML-Frontmatter (`sources[].resource`, `generated.by` — Provenanz-/Tool-Strings können nicht-thematische Concepts als Kandidaten markieren). Keine deterministischen Lücke im Ist-Sinn (das Verhalten ist reproduzierbar), aber die Match-Semantik ist nicht fixiert; zwei Producer-Readings sind möglich. Home: nächste Compiler-Instruktions-Revision, die §3.2 ohnehin berührt (oder Story 3.8, Determinismus-Vertrag-Abgleich).
  evidence: bmad-code-review Story 3.2 (2026-08-19, Loop 3, Edge-Case-Hunter + Verification-Gap-Layer): `schema/compiler.md:55` (Stufe-a-Form ohne `\b`/Frontmatter-Klausel) vs. §3.2-Intro („Concept-Bodies").
  status: offen

- source_spec: `_bmad-output/implementation-artifacts/spec-3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip.md`
  summary: **`§3.2`-Pkt.-1b-ii: Kollaps-Reichweite bei aufeinanderfolgenden/führenden/trailenden Separatoren unbestimmt** — „jedes Vorkommen wird in einen einzelnen Bindestrich kollabiert" ist für Läufe (`a--b`), führende (`-x`) und trailende (`x-`) Separatoren nicht eindeutig (Kollaps auf genau ein `-` + Trim? oder 1:1-Ersatz?). Bis dahin ist die Normalisierung für solche Terme nicht vollständig pinbar (AD-17h-Nähe). Home: nächste Compiler-Instruktions-Revision (mit- oder in Story 3.8 zusammen mit der Em-Dash-Lücke, s. obiger Eintrag).
  evidence: bmad-code-review Story 3.2 (2026-08-19, Loop 3, Edge-Case-Hunter-Layer): `schema/compiler.md:51` (Pkt. 1b-ii).
  status: offen

- source_spec: `_bmad-output/implementation-artifacts/spec-3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip.md`
  summary: **Stufe-a-Treffer auf `index.md`-Pfade deterministisch aus der finalen Candidate-Liste entfernen** — Pkt. 2b definiert `index.md`-Treffer als Stufe-**b**-Trigger (gewurzelte Concept-Pfade sind die Stufe-b-Treffer), aber Pkt. 3b ordnet „Stufe-a-Treffer zuerst" ohne Fixierung, dass reine `index.md`-Stufe-a-Treffer *nicht* als Candidate (nicht-Concept-Pfad) in die finale Liste einfließen (Sandbox-T2-Ausgabe `index`+`alpha` illustriert den ungeklärten Fall; die Candidate-Liste ist per Definition auf Concept-Pfade beschränkt). Home: nächste Compiler-Instruktions-Revision, die §3.2 berührt.
  evidence: bmad-code-review Story 3.2 (2026-08-19, Loop 3, Blind-Hunter + Edge-Case-Hunter-Layer): `schema/compiler.md:55-56,60`; `_bmad-output/implementation-artifacts/sandbox-3-2/run-sandbox.sh` T2-Kommentar.
  status: offen

- source_spec: `_bmad-output/implementation-artifacts/spec-3-2-relevanzbestimmung-textual-deterministisch-umsetzen-grep-rip.md`
  summary: **Rev-2.5/2.6-Beleg-Klarigungen ohne Semantik-Auswirkung (Bündel)** — (a) Rev-2.5-Log-Zelle zitiert die `rg --exclude`-Form im aktiven Mechanismus-Teil ohne eigene Inline-Korrektur (Rev-2.6-Zelle erklärt sie nur — ein Producer, der nur Rev 2.5 liest, kopiert ein nicht-existentes Flag); (b) `sprint-status.yaml last_updated: 08-19-2026 07:10` liegt vor dem Story-3.2-Commit (09:16) — Zeitstempel dokumentiert nicht den Abschluss-Zeitpunkt (Story-3.1-Präzedenz: `last_updated` wird im Review-Loop-2-Commit ebenfalls nicht fortgeschrieben); (c) `compiler.md`-Revisionslog: Rev 2.6 steht über Rev 2.5 (chronologisch umgekehrt — Rev-2.6 wurde an der Einfüge-Stelle statt nach 2.5 angehängt); (d) Validator-Beleg „alle 7 `wiki/`-Dateien SUCCESS" als Aggregat ohne per-Datei-Liste (Spec-Verification Pkt. 4 verlangt „per-Datei-Verdikt als Ausführungs-Nachweis"; die Zählung 7 ist korrekt: 5 Root- + 2 Area-Concepts + log — re-executiert); (e) Rev-2.6-`git status`-Beleg listet `schema/canonical-terms.md` (neue Datei) und die `_bmad-output/`-Änderungen nicht, obwohl „`git status`" als Prüfgrundlage genannt wird; (f) Formel-4-Beleg: Ist-Zählung `38` ohne Baseline-`≡`-Partner (re-executiert: Ist = 38, korrekt — nur der Beleg-String ist unvollständig gegenüber der §5.6-Formel-4-Semantik „Ist ≡ Extraktion aus dem Baseline-Commit"). Home: nächste Log-/Nachweis-Runde (Story-3.3-Implementierungseintrag oder Story-3.2-Re-Review), keine Instruktions-Änderung nötig.
  evidence: bmad-code-review Story 3.2 (2026-08-19, Loop 3, Blind-Hunter + Verification-Gap + Acceptance-Auditor-Layer): `wiki/log.md:4-5`, `schema/compiler.md:372-373`, `_bmad-output/implementation-artifacts/sprint-status.yaml:32`; re-executierte Formel-4-Zählung (38) und `ls wiki/` (7 `.md`-Dateien) bestätigen Korrektheit der Werte.
  status: offen


## Deferred from: code review of spec-3-4-wissen-aus-mehreren-sources-synthetisieren (Story 3.4, 2026-08-19)

- source_spec: `_bmad-output/implementation-artifacts/spec-3-4-wissen-aus-mehreren-sources-synthetisieren.md`
  summary: **AD-16-Disagreement- und AD-4c-Übernahme-Marker-Pfad erst in der Sandbox demonstriert, nicht als reale Bundle-Demonstration** — die zwei vom Verification-Gap-Layer als „unbeobachtete Vertragsverpflichtungen" markierten Zweige (§5.10 Pkt. 3 AD-16-Default, Pkt. 4 AD-4c) sind durch die neuen Sandbox-Szenarien **N2 (Disagreement: beide Behauptungen + je Beleg bleiben, kein `(e; f)`-Falsch-Multi-Beleg, `Disagreement:`-log-Eintrag)** und **N3 (AD-4c-Kontext-Marker: „übernommen aus `gamma` auf Basis von `raw/gamma-v1.md#S-1`, nicht eigenständig belegt"; übernommene Quelle nicht in `sources`)** hart assertiert. Eine **reale** Disagreement- oder Übernahme-Synthese im echten Bundle bleibt Aufgabe der Epic-4-Stories (4.1 Klassifikation, 4.2 Disagreements in `log.md`), die hier bewusst nicht vorweggenommen wird (Story-3.4-Boundaries: keine Korrektur-Klassifikation, kein reales Bundle-Testmaterial). Home: Epic-4 (Story 4.1/4.2) — reale Anwendung der Sandbox-verankerten Mechanik.
  evidence: Step-04-Review (2026-08-19, Verification-Gap-Layer) — Kernbefund „AD-16-Disagreement-Pfad untested" + „AD-4c-Übernahme-Marker untested"; geschlossen durch `_bmad-output/implementation-artifacts/sandbox-3-4/run-sandbox.sh` N2/N3 (Exit 0, 10 Szenarien).
  status: offen (Home: Epic-4)

- source_spec: `_bmad-output/implementation-artifacts/spec-3-4-wissen-aus-mehreren-sources-synthetisieren.md`
  summary: **Orphan-Kontrolle (§5.10 Pkt. 8) textuell verankert, aber nicht in der Sandbox demonstriert** — die Regel „neu committete `raw/`-Evidenz ohne Ziel-Pfad-Treffer bleibt unzugeordnet und wird in `log.md` als verwaist protokolliert" ist Teil der Pkt.-8-Erhaltungs/Determinismus-Ebene; das Review wies darauf hin, dass der Orphan-Fall (Zuwachs ohne Kandidaten-Treffer) kein eigenes Sandbox-Szenario hat. Die Negativ-Kontroll-Dichte der Sandbox (S3 Reflektiertheit, S5 `??`-Sicht/Struktur, N1 No-Op, N2/N3) deckt die übrigen Pkt.-8-Aspekte; ein Orphan-Szenario wurde zugunsten des verbleibenden Review-Scopes nicht ergänzt. Home: Story 3.8 (Reconcile-Orphan-Politik) oder Epic-4 — verwaiste Evidenz-Politik als Folge-Story.
  evidence: Step-04-Review (2026-08-19, Blind-Hunter-Layer) — Befund „unknown/orphaned raw evidence path without target"); `schema/compiler.md` §5.10 Pkt. 8 (Orphan-Kontrolle, in dieser Runde formuliert).
  status: offen (Home: Story 3.8)

- source_spec: `_bmad-output/implementation-artifacts/spec-3-4-wissen-aus-mehreren-sources-synthetisieren.md`
  summary: **Sandbox-Evidenztexte transkribieren Umlaute, die Concept-Bodies nutzen Umlaut-Schreibweisen (Determinismus-Hazard für den Term-Abgleich)** — die Story-3.4-Sandbox setzt den bekannten Story-3.2-/Sandbox-Normalisierungs-Hazard fort (already known: Em-Dash-Lücke + Umlaut vs. Transkription, Home Story 3.8). Die §3.2-Normalisierung (lowercasing + `[-–_ ]`-Kollaps) deckt Umlaut-Divergenzen („Schlüssel" vs. „Schluessel") nicht; die Sandbox-Bodies (Umlaut) vs. raw-Evidenz (Transkription, z. B. „Bestaetigungen", „Repraesentationen") nutzen bewusst beide Schreibweisen. Home: Story 3.8 (Determinismus-Vertrag, Normalisierungs-Vollständigkeit) oder Sandbox-Vereinheitlichung in einer Folge-Story — kein Instruktions-Defekt.
  evidence: Step-04-Review (2026-08-19, Verification-Gap-Layer): `run-sandbox.sh` N2 (`Quorum-Bestaetigungen`) / S6 / S2/`Sitzungsschluessel` etc.; §3.2-Pkt.-1b-Kollaps-Klasse ohne Umlaut-/Em-Dash.
  status: offen (Home: Story 3.8)

- source_spec: `_bmad-output/implementation-artifacts/spec-3-4-wissen-aus-mehreren-sources-synthetisieren.md`
  summary: **Frozen Spec-Intent-Typo „Nickel" im §5.10-Form-Wahl-Aufgaben-Pfad (Story-3.3-Defer U2/U7-Empfehlung)** — der Intent-Satz „Nickel die Story-3.3-Defer U2/U7-Empfehlung (…) im Sandbox auf" enthält „Nickel" statt „Nimm/Trage … auf" (oder „Schließe … auf"); er sitzt im `<frozen-after-approval>`-Block des Specs, dessen Text erst nach humaner Re-Negotiation geändert werden darf. Kein Instruktions-Defekt (der Sandbox-/authored-Text ist korrekt — FW-Szenario implementiert die Empfehlung inhaltlich). Home: Spec-Re-Negotiation (Ask-First: menschliche Autorisierung) oder Akzeptanz als kosmetischer Frozen-Fehler.
  evidence: Step-04-Review (2026-08-19, Blind-Hunter-Layer): `spec-3-4-…md` Zeile ~18 (frozen Intent) — „Nickel die Story-3.3-Defer U2/U7-Empfehlung … auf".
  status: offen

## Deferred from: code review of spec-3-6-lease-staleness-recovery-basis-absichern-umsetzen (Story 3.6, 2026-08-19)

- source_spec: `_bmad-output/implementation-artifacts/spec-3-6-lease-staleness-recovery-basis-absichern.md`
  summary: **Schicksal des `lease/<area>/<id>`-Branch nach Übernahme/Stale-Markierung nicht definiert** — §5.12 Pkt. 3 „Nie gelöscht (AD-17e)" deckt die verwaiste Lease selbst ab (Lockfile, Registrierung, Marker), die Registry-Invariante Pkt. 6 den höchsten Reg-Generator; der isolierte `lease/<area>/<id>`-Branch-Ref (im Refspace von einer Verwaist-Behandlung unabhängig überlebend, da die Sandbox-Szenarien isolierte Branches über `isolate` aufbauen und die Folge-Konvergenz des Branch-Refs nicht hart prüfen) bleibt im Refspace zurück, ohne dass Übernehmen/Stale-Markieren ein deterministisches Folgeziel für ihn benennt (Branch-Cleanup/Einordnung). Kein Instruktions-Defekt für die Staleness-/Recovery-Mechanik (kein Branch blockiert eine Akquise — die Koordination läuft allein über Lockfile + Registry; AD-17e schützt Lockfile/Registry/Marker, ein gelöschter Branch zerstört keinerlei Commits), aber eine offene Evidenz-/Spez-Grenze am absetzenden (nicht akquirierenden) Nebenpfad des `lease/`-Baums. Home: spätere Instruktions-/Sandbox-Runde (Branch-Ref-Lebenszyklus) oder Story 3.8 (Determinismus des adressierbaren Zustands) — nicht in dieser Story.
  evidence: Step-04-Review (2026-08-19, Blind-Hunter-Layer) — „orphan branch fate / isolate-branch cleanup signal"; `schema/compiler.md` §5.12 Pkt. 3/6, `sandbox-3-6/run-sandbox.sh` (isolate/Branch-Aufbau).
  status: offen (Home: spätere Instruktions-/Sandbox-Runde oder Story 3.8)

## Deferred from: code review of spec-3-5-leasing-dirty-tree-schutz-für-konkurrierende-producer-umsetzen (Story 3.5, 2026-08-19)

- source_spec: `_bmad-output/implementation-artifacts/spec-3-5-leasing-dirty-tree-schutz-für-konkurrierende-producer-umsetzen.md`
  summary: **holder_id Quelle/Uniqueness (Pkt. 1) nicht definiert** — das Lockfile-Feld `holder_id` („eindeutige Producer-/Run-Kennung") legt nicht fest, welcher deterministische Git-/Umgebungs-Wert es erzeugt (Branch-Suffix? Producer-Name? Run-Identifier?). Die Sandbox vergibt Beispiele (`run-a-holder`), §5.11 Pkt. 1 benennt keinen Ableitungs-Operanden. Kein Instruktions-Defekt für die Koordinations-Mechanik (Eindeutigkeit ist eine Producer-Verantwortung), aber eine offene Determinismus-Frage am Feld. Home: Story 3.6 (Lease-Registrierung) oder Story 3.8 (Determinismus-Ableitung) — ableitbarer holder_id-Default.
  evidence: Step-04-Review (2026-08-19, Blind-Hunter-Layer) — „holder_id uniqueness source undefined"; `schema/compiler.md` §5.11 Pkt. 1, `run-lock-Write`.
  status: offen (Home: Story 3.6 oder 3.8)

- source_spec: `_bmad-output/implementation-artifacts/spec-3-5-leasing-dirty-tree-schutz-für-konkurrierende-producer-umsetzen.md`
  summary: **baseline_commit-Merge-Base-Ableitung (Pkt. 1) nicht von `git merge-base`-Laufzeit vs. notiertem `<Baseline-Commit>` reconciliert** — §5.11 nennt beide Quellen („deterministisch über `git merge-base` bzw. den notierten `<Baseline-Commit>` aus §5.9 Pkt. 6"), ohne Diskrepanz-Regel (welche gewinnt, wenn `git merge-base` eine andere Spitze liefert als die letzte notierte Mutations-Boundary? §5.9 Pkt. 6 hat die Differenz-Regel für Diff-Prüfungen, §5.11 nicht). Kein akuter Instruktionsdefekt (die Merge-Base-Disziplin zielt auf denselben Punkt), aber eine offene Disambiguierung. Home: Story 3.6 (Lease-Registrierung/Baseline) — Baseline-Auflösungs-Regel vereinheitlichen.
  evidence: Step-04-Review (2026-08-19, Blind-Hunter+Verification-Gap) — „baseline_commit merge-base derivation not reconciled"; `schema/compiler.md` §5.11 Pkt. 1.
  status: offen (Home: Story 3.6)

- source_spec: `_bmad-output/implementation-artifacts/spec-3-5-leasing-dirty-tree-schutz-für-konkurrierende-producer-umsetzen.md`
  summary: **Sandbox-log-Akkumulator vs. eigener `# Log`-Stand jedes isolierten Szenarios** — die Sandbox richtet je Szenario via `isolate` einen frischen (leeren) `wiki/log.md`-Stand ein und D2 demonstriert die kumulative Aufzeichnung separat; der Akkumulator lebt damit nur im Diskurs, nicht in einem durchgängigen Run-Baum. Die Koordinations-Aufzeichnung über MEHRERE Runs hinweg (consecutive Producers, die dieselbe `wiki/log.md`-Datei fortschreiben, ohne dass `isolate` sie zurücksetzt) ist nicht als eigenständiges Szenario demonstriert. Kein Instruktions-Defekt — die Regel (Pkt. 6) ist kumulativ formuliert, D2 belegt sie hart. Home: Story 3.6 (Registrierung/Verfahrnaher) oder Doku-Verbesserung der Sandbox — nichts funktionales offen.
  evidence: Step-04-Review (2026-08-19, Blind-Hunter-Layer) — „isolate wipes per-scenario log entries so cumulative coordination recording never demonstrated"; geschlossen durch D2 (Story-3.5-Sandbox).
  status: offen (Home: Story 3.6) — D2 demonstriert die kumulative Aufzeichnung hart.

- source_spec: `_bmad-output/implementation-artifacts/spec-3-5-leasing-dirty-tree-schutz-für-konkurrierende-producer-umsetzen.md`
  summary: **`isolate`-Skript nutzt native `git stash`-Variante für den Dirty-Tree-Schutz nicht** — §5.11 Pkt. 3 nennt „`git stash push -- <Pfade>` … oder Kopie in eine benannte Scratch-Zone"; die Sandbox demonstriert nur die Kopier-Variante (Scratch-Zone). Die `git stash`-Variante bleibt ungetestet. Kein Instruktions-Defekt (beide Wege sind textuell zulässig, die Determinismus-Anforderung betrifft das Ergebnis), aber eine Test-Lücke der alternativen Schutz-Umsetzung. Home: Story 3.6 (Lease-/Recovery-Stash-Semantik) oder Sandbox-Erweiterung — nichts funktional offen.
  evidence: Step-04-Review (2026-08-19, Verification-Gap-Layer) — „native git stash alternative untested (only manual cp-into-scratch)"; `schema/compiler.md` §5.11 Pkt. 3.
  status: offen (Home: Story 3.6)

### Aufgegriffen: holder_id-Quelle/Uniqueness (Story-3.5-Defer, Home Story 3.6) — Story 3.6, 2026-08-19

- Bezug: Defer `holder_id Quelle/Uniqueness (Pkt. 1) nicht definiert` (Defer-Block „Deferred from … spec-3-5 …", Eintrag 1).
- Umsetzung: `schema/compiler.md` §5.12 Pkt. 2 „holder_id-Ableitung (deterministischer Default; Defer ‚holder_id-Quelle' Story 3.5 aufgegriffen)": `holder_id := <producer>-<id>` — `<producer>` aus dem Lockfile-Feld `producer`, `<id>` der Run-Identifier aus der Branch-Form `lease/<area>/<id>`; reproduzierbar aus dem committeten Git-State (AD-17h/A0-19), kein Wanduhr-Operand.
- Sandbox-Nachweis: `_bmad-output/implementation-artifacts/sandbox-3-6/run-sandbox.sh` STALE-2 (holder_id deterministisch uebernommen nach `lock_write`, `lock_holder`-Assertion) — Exit 0.
- status: aufgegriffen (Home erledigt in §5.12 Pkt. 2)

### Aufgegriffen: baseline_commit-Merge-Base-Diskrepanz (Story-3.5-Defer, Home Story 3.6) — Story 3.6, 2026-08-19

- Bezug: Defer `baseline_commit-Merge-Base-Ableitung (Pkt. 1) nicht … reconciliert` (Defer-Block „Deferred from … spec-3-5 …", Eintrag 2).
- Umsetzung: `schema/compiler.md` §5.12 Pkt. 4 „baseline_commit-Merge-Base-Diskrepanz-Regel (Vereinheitlichung; Defer ‚baseline_commit-Diskrepanz' Story 3.5 aufgegriffen)": bei Widerspruch gewinnt der `git merge-base`-Laufzeitbefund (Commit-Boundary-Prinzip), der notierte `<Baseline-Commit>` bleibt Sekundär-Fingerprint; Fallback ohne Boundary = alle `raw/`-Dateien Zuwachs, Merge-Base = ältester committeter Fundamentpunkt (§5.9 Pkt. 6 R-1, AD-14). Dieselbe Regel für Lease-Übernahme (Pkt. 3/4).
- Sandbox-Nachweis: STALE-2 (`git merge-base HEAD $BASE` == `$BASE`-Assertion, Merge-Base-Prüfung bei Übernahme) — Exit 0.
- status: aufgegriffen (Home erledigt in §5.12 Pkt. 4)

### Aufgegriffen: Sandbox-log-Akkumulator / kumulative Registry (Story-3.5-Defer, Home Story 3.6) — Story 3.6, 2026-08-19

- Bezug: Defer `Sandbox-log-Akkumulator vs. eigener # Log-Stand …` (Defer-Block „Deferred from … spec-3-5 …", Eintrag 3).
- Umsetzung: `schema/compiler.md` §5.12 Pkt. 6 „Registrierungs-Invariante & kumulativer Registry-Aufbau über Runs (Vertrag §5)": der Registry-Aufbau ist kumulativ über Runs (mehrere aufeinanderfolgende Producer schreiben dieselbe Registrierung fort, analog zum `log.md`-Akkumulator); **kein eigener `# Log`-Stand** — `wiki/log.md` ist der alleinige Aufzeichnungs-Ort. Registrierung lebt im Clone-Root-State (`registry/`), Marker Git-/Datei-Ebene ohne Eintrags-Body.
- Sandbox-Nachweis: STALE-1 (kumulative Registry-Zeilen run-a + run-b), STALE-5 (drei Runs in EINER `registry/wiki`, Gen-Invariante 3 gehalten) — Exit 0.
- status: aufgegriffen (Home erledigt in §5.12 Pkt. 6)

### Aufgegriffen: native `git stash`-Variante (Story-3.5-Defer, Home Story 3.6) — Story 3.6, 2026-08-19

- Bezug: Defer `isolate-Skript nutzt native git stash-Variante für den Dirty-Tree-Schutz nicht` (Defer-Block „Deferred from … spec-3-5 …", Eintrag 4).
- Umsetzung: `schema/compiler.md` §5.12 Pkt. 5 „`raw/`-Recovery-Basis & native `git stash`-Variante (AD-3, AD-17d/A0-15)": `git stash push -- <Pfade>` als zweite textuell zulässige Schutzvariante neben der Scratch-Zonen-Kopie (beide deterministisch im Ergebnis, byte-identisch geschützt, nie gelöscht, Restore dokumentiert).
- Sandbox-Nachweis: STALE-4 (`git stash push`/`pop` um `wiki/alpha.md`, byte-identischer Restore via SHA-256; `raw/`-SHA-256 unverändert, AD-3) — Exit 0.
- status: aufgegriffen (Home erledigt in §5.12 Pkt. 5)

## Deferred from: code review of spec-3-7-reason-mutate-trennung-und-konsistenz-endzustand-sicherstell (Story 3.7, 2026-08-20)

- CONSIST-7-Label praezisie: das Zwei-Run-Label behauptet "identische Plan-/Rollback-/State-Outputs", verglichen werden aber nur die Plan-Outputs (plan_sha/plan_state); der Rollback-/State-Nachweis (s7c) laeuft einmalig, log_sha ist dokumentierte Baseline-Konstante. Die non-vakuum-Kern-Assertion (plan_sha byte-identisch ueber beide Runs) ist real; das Label ist breiter als die Assertion. Home: Sandbox-Haertungsrunde.
- A0-20-Post-Zustand-Negativkontrolle in der Sandbox fehlt: §5.13 Pkt. 3/7 bindet den Determinismus-Vertrag an den Post-Zustand; der dokumentierte generated.at-Wanduhr-Gap (§5.10 Pkt. 8, offene A0-20-Konvention) macht den Post-Zustand ueber unabhaengige Runs nicht byte-identisch — die Sandbox testet den Gap weder negativ noch positiv. Home: Story 3.8 (A0-20-Home).
- Pre-existing-Zeitpunktswort-Fuge: §5.9 Pkt. 6 "am Anfang der Mutationsphase" vs. gefrorene I/O-Matrix + §5.13 "Abbruch vor der Mutationsphase" — §5.9 ist in Story 3.7 Wortlaut-unververaendert (Rueckverweis-Vertrag); die Fuge ist ohne Ask-First nicht schliessbar. Home: spaetere Instruktionsrunde.

### Delokalisierung: Terminologie-Drift INPUT_UNCOMMITTED/UNCOMMITTED_INPUT (Story-3.7-Review, 2026-08-20)

- Bezug: `schema/compiler.md` §5.9 Pkt. 6 Element (1) nennt die I/O-Matrix `INPUT_UNCOMMITTED`, §5.11 Pkt. 3 nennt dieselbe Pre-Run-Prüfung `UNCOMMITTED_INPUT` — dieselbe Prüfung, zwei Labels (pre-existing seit Story 3.1/3.5; in Story 3.6/3.7 als dieselbe §5.9-P2-Prüfung deklariert, §5.11-Wortlaut geschützt). Die Story-3.7-Sandbox (`p2_plan`-Element (1)) nutzt `INPUT_UNCOMMITTED` wie §5.9-Pkt.-6-Element (1).
- status: delokalisiert (kein Defekt — terminologische Präferenz; Home: spätere Instruktionsrunde, falls die Labels vereinheitlicht werden)

### Delokalisierung: Misch-Run-Coverage Neu-Anlage+Update in der Story-3.7-Sandbox (Story-3.7-Review, 2026-08-20)

- Bezug: §5.9 Pkt. 2/§5.7 Misch-Runs (Neu-Anlage + Update im selben Run) sind in der CONSIST-Sandbox ab Review-Loop-2 im CONSIST-2 abgedeckt (Neu-Anlage `delta` + Update `alpha`, Plan-Freeze-Menge + Voll-Rollback, Neu-Anlage-Absenz nach Rollback); übrige Phasen-/Synthese-Misch-Formen bleiben Home Story 3.8 (Determinismus-Vertrag AD-17h als Agent-Instruktions-Validator, inkl. A0-20-Post-Zustand-Test).
- status: delokalisiert (Home: Story 3.8)

## Deferred from: code review of spec-3-8-determinismus-vertrag-ad-17h-als-agent-instruktions-validator (Story 3.8, 2026-08-20)

### Aufgegriffen: Em-Dash-Varianten-Lücke der Normalisierung (Story-3.2-Defer, Home Story 3.8) — Story 3.8, 2026-08-20

- Bezug: Defer «Em-Dash-"—"-Varianten-Lücke der Normalisierung» (Defer-Block „Deferred from: Story 3.2", Eintrag 1; `status: offen (Home: Story 3.8)`).
- Umsetzung: `schema/compiler.md` §3.2 Pkt. 1b „Geschlossene Determinismus-Lücken (Story 3.8)": die Kollaps-Klasse ist um den Em-Dash `—` ergänzt (`[-–— _]` → `-`) — En-Dash, Em-Dash, Bindestrich, Unterstrich, Leerzeichen kollabieren identisch auf genau einen Bindestrich. Verankerung: §5.14 Pkt. 5 verweist auf §3.2-Pkt.-1b. Kein stiller Ausschluss; append-only-Regel-Ergänzung, bestehender §3.2-Wortlaut unverändert.
- Sandbox-Nachweis: `_bmad-output/implementation-artifacts/sandbox-3-8/run-sandbox.sh` DET-5 (Em-Dash → identische canonische Form wie En-Dash/Bindestrich/Unterstrich/Leerzeichen) — Exit 0.
- status: aufgegriffen (Home erledigt in §3.2 Pkt. 1b / §5.14 Pkt. 5)

### Aufgegriffen: Kollaps-Reichweite bei Läufen/führenden/trailenden Separatoren (Story-3.2-Defer, Home Story 3.8) — Story 3.8, 2026-08-20

- Bezug: Defer «§3.2-Pkt.-1b-ii: Kollaps-Reichweite bei aufeinanderfolgenden/führenden/trailenden Separatoren unbestimmt» (Defer-Block „Deferred from: code review of spec-3-2…", Eintrag 2).
- Umsetzung: `schema/compiler.md` §3.2 Pkt. 1b „Geschlossene Determinismus-Lücken": Kollaps-Reichweite deterministisch — jedes Separator-Vorkommen kollabiert auf genau ein `-`; Läufe (`a--b` → `a-b`); führende (`-x` → `x`) und trailende (`x-` → `x`) Separatoren werden getrimmt. Verankerung §5.14 Pkt. 5; die in der Sandbox etablierte Semantik wird normativ fixiert.
- Sandbox-Nachweis: DET-6 (Läufe `a--b`, führende `-x`, trailende `x-`, Kombination `---x---` → `x`) — Exit 0.
- status: aufgegriffen (Home erledigt in §3.2 Pkt. 1b / §5.14 Pkt. 5)

### Aufgegriffen: Match-Scope der Stufe a (Wortgrenzen, Frontmatter-exklusiv) (Story-3.2-Defer, Home Story 3.8) — Story 3.8, 2026-08-20

- Bezug: Defer «§3.2-Pkt.-2a: Wortgrenzen-/Frontmatter-Scope der Stufe-a-Match-Semantik ist offen» (Defer-Block „Deferred from: code review of spec-3-2…", Eintrag 1).
- Umsetzung: `schema/compiler.md` §3.2 Pkt. 1b „Geschlossene Determinismus-Lücken" (c) Match-Scope der Stufe a: Stufe a matcht ganze Wörter (Wortgrenzen) über den Body, exklusive YAML-Frontmatter — Substring- und Frontmatter-Treffer (z. B. in `sources[].resource`/`generated.by`) liefern keine Kandidaten (deterministischer Stufe-a-Scope). Verankerung §5.14 Pkt. 5.
- Sandbox-Nachweis: DET-7 (ganzes Wort trifft alpha; Substring `opplung` und Frontmatter-only-Kandidat `mirror` liefern keine Kandidaten) — Exit 0.
- status: aufgegriffen (Home erledigt in §3.2 Pkt. 1b / §5.14 Pkt. 5)

### Aufgegriffen: Orphan-Kontrolle als deterministische Reconcile-Orphan-Regel (Story-3.4-Defer, Home Story 3.8) — Story 3.8, 2026-08-20

- Bezug: Defer «Orphan-Kontrolle (§5.10 Pkt. 8) textuell verankert, aber nicht in der Sandbox demonstriert» (Defer-Block „Deferred from: code review of spec-3-4…", Eintrag 2; `status: offen (Home: Story 3.8)`).
- Umsetzung: `schema/compiler.md` §5.10 Pkt. 8 „Deterministische Reconcile-Orphan-Regel (Story 3.8; §5.14-Präzisierung)": Verwaist-Befund deterministisch aus dem committeten Git-State (Zuwachs gg. `<Baseline-Commit>`, §5.9 Pkt. 6 R-1); datumsgruppierter `log.md`-Eintrag (Header `YYYY-MM-DD`, neueste zuerst; Quell-Pfad + `<Baseline-Commit>`); kein Banner/keine stille Vorbearbeitung/keine eigenständige Anlage (AD-16-Default, Epic-4-Interface). Verankerung §5.14 Pkt. 5.
- Sandbox-Nachweis: DET-8 (verwaiste `raw/`-Evidenz ohne Ziel-Pfad-Treffer → unzugeordnet, `log.md`-Verwaist-Eintrag mit `<Baseline-Commit>`, kein Banner, keine eigenständige Anlage, Erhaltungs-Invariante nur `log.md`) — Exit 0.
- status: aufgegriffen (Home erledigt in §5.10 Pkt. 8 / §5.14 Pkt. 5)

### Aufgegriffen: generated.at↔AD-17h-Gap & Zwei-Run-Identitäts-Nachweis (Story-3.3-Defer, Home Story 3.8) — Story 3.8, 2026-08-20

- Bezug: Defer «U6-Zwei-Run-Identitäts-Nachweis … kreuzreferenziert den generated.at↔AD-17h-Gap nicht» (Defer-Block „Deferred from: code review of spec-3-3…", Eintrag 3; `status: offen (Home: Story 3.8)`).
- Umsetzung: `schema/compiler.md` §5.14 Pkt. 1 (Bundle-State-Definition: `generated.at`/`verified[].at` als benannte Ausnahme der Projektion), Pkt. 3 (Ausnahme-Menge: allein der `generated.at`-Wanduhr-Gap; alle übrigen Bestandteile byte-identisch) und Pkt. 2 (Zwei-Run-Mechanik: identische Plan-/Kandidaten-/Reihenfolge-Outputs und byte-identische mutierte Bundle-Bestandteile bis auf die `at`-Ausnahme). Der A0-20-Wanduhr-Gap bleibt verhaltens-seitig unverändert (Ask-First bei Verhaltens-Wechsel).
- Sandbox-Nachweis: DET-2 (Zwei-Run-Identität nicht-vakuum, echte Content-Hashes) + DET-4 (at-Gap-Ausnahme: diff ausschließlich auf der at-Zeile, nach at-Maskierung byte-identisch; Negativkontrolle Body-Differenz = AD-16-Defekt) — Exit 0.
- status: aufgegriffen (Home erledigt in §5.14 Pkt. 1–3)

### Aufgegriffen: A0-20-Post-Zustand-Negativkontrolle in der Sandbox (Story-3.7-Defer, Home Story 3.8) — Story 3.8, 2026-08-20

- Bezug: Defer «A0-20-Post-Zustand-Negativkontrolle in der Sandbox fehlt … Home: Story 3.8 (A0-20-Home)» (Defer-Block „Deferred from: code review of spec-3-7…", Eintrag 2).
- Umsetzung: §5.14 Pkt. 3 definiert die Ausnahme-Menge des Bundle-State-Vergleichs (allein der `generated.at`-Wanduhr-Gap; jede andere Differenz außerhalb der Ausnahme = AD-16-Klassifikationsdefekt, Pkt. 4, textuell benannt NFR-4). Der Post-Zustand wird damit über die Zwei-Run-Mechanik (Pkt. 2) einschließlich at-Handhabung instruiert; die Sandbox demonstriert den Gap positiv und negativ.
- Sandbox-Nachweis: DET-4 (positiv: zwei Runs mit unterschiedlichen `at` → diff nur at-Zeile, nach Maskierung byte-identisch; negativ: Body-Differenz → AD-16-Klassifikationsdefekt) — Exit 0.
- status: aufgegriffen (Home erledigt in §5.14 Pkt. 2–4)

### Aufgegriffen: Misch-Run-Coverage Determinismus-Vertrag (Story-3.7-Delokalisierung, Home Story 3.8) — Story 3.8, 2026-08-20

- Bezug: Delokalisierung «Misch-Run-Coverage Neu-Anlage+Update in der Story-3.7-Sandbox … übrige Phasen-/Synthese-Misch-Formen bleiben Home Story 3.8 (Determinismus-Vertrag AD-17h als Agent-Instruktions-Validator, inkl. A0-20-Post-Zustand-Test)» (Block „### Delokalisierung …", `status: delokalisiert (Home: Story 3.8)`).
- Umsetzung: Der Determinismus-Vertrag wird als geschlossene Bestätigungs-Mechanik in §5.14 verankert (Bundle-State-Projektion, Zwei-Run-Bestätigung, at-Ausnahme, Abweichungs-Klassifikation); die §5.13-Determinismus-Nachweise bleiben unverändert, die at-A0-20-Konvention ist auf die §5.14-Pkt.-3-Ausnahme-Menge verlagert (§5.13 Pkt. 7 Seam).
- Sandbox-Nachweis: DET-1..DET-4 (Bundle-State-Definition, Zwei-Run-Identität, Abweichungs-Klassifikation, at-Gap-Ausnahme) — Exit 0.
- status: aufgegriffen (Home erledigt in §5.14)

### Aufgegriffen (teilweise): Gemischte Normalisierungs-Politik Umlaute vs. Transkription — Em-Dash-Anteil (Story-3.3/Story-3.4-Defers, Home Story 3.8) — Story 3.8, 2026-08-20

- Bezug: Defer «Gemischte Normalisierungs-Politik im Sandbox-Evidenztext (Umlaute vs. Transkriptionen) ist ein Determinismus-Hazard für den Term-Abgleich» (Defer-Block „Deferred from: code review of spec-3-3…", Eintrag 5, `status: offen (Home: Story 3.8)`) und Defer «Sandbox-Evidenztexte transkribieren Umlaute, die Concept-Bodies nutzen Umlaut-Schreibweisen» (Defer-Block „Deferred from: code review of spec-3-4…", Eintrag 3, `status: offen (Home: Story 3.8)`).
- Umsetzung: Der Em-Dash-Anteil beider Einträge ist in `schema/compiler.md` §3.2 Pkt. 1b / §5.14 Pkt. 5 geschlossen (Em-Dash in der Kollaps-Klasse `[-–— _]` → `-`). Der Umlaut-vs-Transkription-Anteil bleibt offen: die §3.2-Normalisierung (lowercasing + Kollaps-Klasse) deckt Umlaut-Divergenzen („Schlüssel" vs. „Schluessel") weiterhin nicht ab — kein neuer Normalisierungs-Schritt in Story 3.8 (kein neuer Regel-Operand, D-3/append-only).
- Sandbox-Nachweis: DET-5 (Em-Dash-Anteil) — Exit 0.
- status: teilweise aufgegriffen (Em-Dash-Anteil geschlossen in §3.2 Pkt. 1b / §5.14 Pkt. 5; Umlaut-vs-Transkription-Divergenz bleibt offen — Home: Sandbox-Vereinheitlichung oder folgende Compiler-Instruktions-Revision; kein Instruktions-Defekt)

## Deferred from: code review of spec-3-8-determinismus-vertrag-ad-17h-als-agent-instruktions-validato (2026-08-20)

- **Sandbox-Härtungs-Guards (8 Befunde):** `mktemp` (Z. 37), `git init` (Z. 41), Baseline-Commit (Z. 94-96), `isolate()`-Sequenz (Z. 104-107), fehlende Match-Datei (Z. 136-141), verwaiste unregistrierte Worktree-Verzeichnisse (Z. 243-244) und Porcelain-Pfade mit Leerzeichen (`awk '{print $2}'`, Z. 217/682) tragen keine Fehler-Guards; ein Fehlgeschlagener init-Schritt lässt einen späteren „PASS" auf kaputtem Zustand drucken. — Defer-Grund: Testharness-Robustheit, keine normative Instruktion-Semantik; Re-Run-Risiko dokumentiert. Home: nächste Sandbox-Revision. — status: offen
- **DET-1/DET-2-Plan-/Form-Literale vs. AC-5 „nicht hart codiert":** `plan=$(printf 'cand=alpha;form=update;baseline=%s')` (run-sandbox.sh:189) und `echo "form=update"` in `bs_a()` (Z. 221) sind wörtliche Skript-Konstanten; B1==B2-Identität damit trivial. — Defer-Grund: Loop-1-/Loop-2-Präzedenz (Loop-1 hat „DET-2-Plan-Literal (dev-demo, echte Content-Hashes decken)" rejected; DET-1 trägt den Demo-Kommentar Z. 211-214); die Nicht-Vakuum-Assertion tragen die echten Content-Hashes. Home: Story-3.13-Abnahme (echte Gate-Runs über die Instruktion). — status: offen
- **`norm()`-Locale-Pinning (`LC_ALL`) fehlt:** unter C/POSIX-Locale zerfällt die Byte-Klasse `[–—]` in {E2,80,93,94} (übermatcht z. B. `…`/`„`), `tr 'A-Z' 'a-z'` ist locale-abhängig → die Kanon-Form hängt am Host-Locale statt am committeten Git-State. — Defer-Grund: Testharness-Host-Locale-Abhängigkeit (Host = Ubuntu-Sandbox, dort UTF-8-Default; auf C-Locale-Hosts falsch), keine normative Semantik der Instruktion. Home: Sandbox-Härtung (gemeinsam mit den Hards-Guards). — status: offen
- **Mehrfach-Term-Vereinigung unübend:** §3.2 Pkt. 1c/§5.14 Pkt. 5 pinnen die Vereinigung der Treffer über alle Terme (besuchte Menge, Zuwachs-Sicht-Ordnung) als „vollständig pinbar" — die Sandbox übt nur den Einzel-Term-Pfad; eine Regressions in Union-/Dedup-/visited-Set-Logik würde unbemerkt durchgehen. — Defer-Grund: Story-3.8-Scope (Bestätigungs-Mechanik + Lückenschließung) ist erfüllt; ausführbare Union-Coverage gehört zur deterministischen Term-Gewinnung/Routing. Home: Story 3.9. — **status: offen → aufgegriffen (Story 3.9, 2026-08-20):** in `schema/compiler.md` §5.15 Pkt. 1 verankert (Mehrfach-Term-Vereinigung D-8: kollabierter Gesamt-Name als primärer Term + jedes ≥2-Zeichen-Segment als weiterer Term; Einzelzeichen-Segmente -a/-b tragen keinen eigenen Term); Sandbox R-1 übt die Vereinigung real aus (`beta-kommunikation` → `beta beta-kommunikation kommunikation`, Sidecar-exkludiert, Diff↔Manifest-Äquivalenz)
- **Orphan-Term hand-gesteuert + feste 2-Datei-Scan:** DET-8 pinnen den Term `fremdes` und scannen nur `wiki/alpha.md wiki/gamma.md` (run-sandbox.sh:669); die Determinismus der Orphan-ermittlung (Term-Ableitung aus dem `raw/`-Zuwachs, voller Kandidaten-Scan über Stufen a/b/c) ist nicht ausgeübt — nur die Log-Seite wird hart assertiert. — Defer-Grund: Mechanik ist textuell korrekt (DET-8-Assertions Z. 688-692 solide); Term-Derivation ist Story-3.9-AC („geschlossener, geordneter Algorithmus oder persistiertes Term-Manifest"). Home: Story 3.9. — **status: offen → aufgegriffen (Story 3.9, 2026-08-20):** Sandbox R-5 leitet die Terme AUS dem committeten `raw/`-Zuwachs ab (`git diff --name-only HEAD~1 -- raw/`, Dateiname→Term) und scannt **Stufe a** über den Root-`wiki/*.md`-Glob statt eines festen 2-Datei-Scans — Orphan-/CREATE-Term-Derivation auf der Stufe-a-Ebene mechanisch ausgeübt (D-9; §5.15 Pkt. 1). **Scope-Präzisierung (Loop-3, 2026-08-21):** die ausgeübte Termination-Derivation + Scan beschränkt sich auf **Stufe a über den Root-`wiki/*.md`-Glob** (keine Area-Rekursion, keine Stufen b/c); die volle Stufen-b/c-Traversal-Coverage des Kandidaten-Baums bleibt verbleibend offen (Home: Story 3.13-Abnahme / Sandbox-Härtung — benannter Defer, keine instruktionsseitige Lücke, §5.15 Pkt. 2/3 verankern die Stufen)
- **Umlaut-vs-Transkription im Match-Pfad unübend:** die §3.2-Normalisierung deckt Umlaut-Divergenzen („Schlüssel" vs. „Schluessel") nicht ab, und kein DET-Szenario treibt einen Umlaut-Term durch den Match-Pfad. — Defer-Grund: bereits „Aufgegriffen (teilweise)" dokumentiert (Block oben, Home: Sandbox-Vereinheitlichung oder folgende Compiler-Instruktions-Revision; „kein Instruktions-Defekt") — keine neue offene Frage, nur fehlende Sandbox-Abdeckung. Home: wie dort. — status: offen

## Deferred from: code review of spec-3-9-deterministische-relevanz-und-reconcile-routing-schliessen (2026-08-21)

- **`norm()`/`tr` ohne `LC_ALL`-Pinning (Sandbox-3.9, 952 Zeilen):** unter C/POSIX-Locale zerfällt die Byte-Klasse `[–—]` in {E2,80,93,94} (übermatcht z. B. `…`/`„`), `tr 'A-Z' 'a-z'` ist locale-abhängig → die Kanon-Form hängt am Host-Locale statt am committeten Git-State. — Defer-Grund: bekannter Story-3.8-Defer (D-7, Block oben „`norm()`-Locale-Pinning fehlt"), hier in den Sandbox-3.9-Scope ausgeweitet (alle R-Szenarien + R-9-Worktree-Läufe laufen auf derselben `norm()`); keine normative Instruktion-Semantik (Instruktion nennt Kollaps-Klasse + lowercasing, keine Locale-Bindung). Home: Sandbox-Härtung (gemeinsam mit den Story-3.8-Hard-Guards). — status: offen
- **Positive Zwei-Run-Identität strukturell trivial (R-9 clean A==B):** Plan-/Form-/Routing-Literale der `run9_worktree()`-Receipts sind Skript-Konstanten; die A==B-Identität folgt daraus, nicht aus realer Ausführung; die Nicht-Vakuum-Last tragen die echten Content-Hashes (Bundle-BYTE-Vergleich) und die Negativ-Kontrolle (divergent ≠ clean, hart FAIL). — Defer-Grund: Präzedenz Story-3.8-Defer „DET-1/DET-2-Plan-/Form-Literale vs. AC-5 „nicht hart codiert"" (Block oben, Home: Story-3.13-Abnahme, echte Gate-Runs über die Instruktion); Story-3.9-Sandbox folgt demselben Demo-Muster. Home: Story-3.13-Abnahme. — status: offen