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.

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

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

• source_spec: _bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md (Code Review, Story 2.1) 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 im Review inhaltlich korrekt (Spot-Checks gegen PRD/epics/spine 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): 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 (Code Review, Story 2.1) 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".

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