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.

• 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 Determinsmus-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). Determinsmus-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.

• 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).

• 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