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.

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