Michael TamseandClaude
a67ba65910
Re-Konsistenz des Validators mit dem autorisierten Vertrag (schema/validator.md 3->6):
- F-01/AI-1: at-Nur-Datum-Toleranz zurueckgenommen (reines Datum => FAIL Punkt 14), Fixture 14c umgebaut, +HHMM-Positiv; Vertrag unveraendert
- F-02/AI-2: neue Fixture-Tabelle 7.3 (EC-1 Existenz, EC-3 Kalender, stale_after-WARN, EC-11 non-md); Zertifizierung in wiki/log.md nachgefuehrt
- F-03/AI-3: 3.2-Voraussetzungen als fachliche Pruefklasse V-1/V-2 gelabelt (FAIL (Voraussetzung)); 5-Grammatik + Fixtures angeglichen
- F-05/AI-5: BOM-/Leerzeilen-Stripping der Frontmatter-Erkennung auf Punkte 2/8/10 vereinheitlicht (3-Praaembel); Positiv-Fixtures 2a/8b
- F-06/F-08 (AI-7): offene Punkte (today-Zeitzone, .MD-Grossschreibung) im Validator verankert
Weitere Retro-Follow-ups:
- F-09/AI-4: source.md-Provenienz korrigiert (_bmad-output/ ist versioniert, Commit 6cc667d + SHA-256 byte-identisch)
- F-10/AI-6: strenger Vertrag<->Validator<->Fixtures-Abgleich (14 Punkte, keine Punkt 15) als Pflicht-Re-Check in spec-1-4; bleibt in D-3
- F-04/F-06/F-07/F-08/F-11/F-14 (AI-7): Defer-Kontexte in deferred-work.md gesichert
- Action Items AI-1..AI-7 auf done gesetzt (sprint-status.yaml)
Co-Authored-By: Claude <noreply@anthropic.com>
101 lines
11 KiB
Markdown
101 lines
11 KiB
Markdown
# 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.
|