diff --git a/_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md b/_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md index 8023102..b8345a7 100644 --- a/_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md +++ b/_bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md @@ -2,7 +2,7 @@ title: 'Concepts aus Source Material erzeugen (OKF-Konform) (Story 2.1)' type: 'feature' created: '2026-08-16' -status: 'in-progress' +status: 'review' review_loop_iteration: 1 baseline_commit: a67ba659108006a54eb54b84592d1dba046af96e context: @@ -115,9 +115,9 @@ Konforme Wiedervorlage nach dem Erst-Review — alle 5 Patch-Findings verifizier - ✅ **AD/Provenienz:** AD-3 (`raw/` unangetastet, leerer Diff), AD-5 (nur neue Root-Concepts), AD-10 (`adapters/` unverändert, keine abweichende Knowledge-Semantik), D-3 (rein textuell, kein Executable-Block), AD-4b (alle `sources[].resource` → existierende `raw/`-Dateien, nie `wiki/`), v1-Default (`generated` gesetzt, `verified` ungesetzt). - ✅ **R-1** (Menge von Source-Pfaden, Set-Interface — compiler.md §1.2 definiert die gesamte evidierenfähige `raw/`-Menge; Einzelpfad-Interface existiert nicht): **Bestanden**, kein Finding. Erkennungs-Mechanismus bewusst deferriert (AD-5-Home-Story, Epic 3, Story 3.1/3.2). - ✅ **R-2** (Nicht-Markdown-Quellen): Instruktion liest Sources endungsneutral als Datei (Vertrag §3.3: nur Dateipfad unter `raw/`; Validator EC-1: nur Existenz); PDF zulässig; §1.4 dokumentarische Konvention (§1.2/§1.4-Widerspruch via Rev 1.3 Patch #4 sauber aufgelöst, kein neuer Bruch): **Bestanden**. -- ✅ **Option A intakt:** `validator.md` Rev-7-Notiz unverändert erhalten (kein Rückbau); Spec konsistent in-progress; `done`-Fähigkeit korrekt an die nächste autorisierte Validator-Revision gekoppelt (F-14-Fixture + Innen-Ebenen-Klarstellung), kein Widerspruch zum Frozen-Bereich. OBS-1 (`validator.md`-Header „Revision 6" vs. Revisionslog „Revision 7") als pre-existing Mitnahme in dieselbe Revision vermerkt. +- ✅ **Option A intakt (Re-Re-Review, 2026-08-17):** `validator.md` Rev-7-Notiz unverändert erhalten (kein Rückbau); `done`-Fähigkeit war korrekt an die nächste autorisierte Validator-Revision gekoppelt. **Diese Revision ist jetzt ausgeführt:** **Revision 8 (2026-08-16, Autorisations-Runde)** trägt formal die F-14-Negativ-Fixture 4a (§7.1, Punkt 4: `resource` außerhalb `raw/`), die Innen-Ebenen-Key-Subset-Klarstellung (Punkt 6 → §7.3-Isolations-Notiz) und die Header-Anhebung „Revision 6" → „Revision 8" (OBS-1). Zertifizierung selbstgeprüft PASS: Fixture 4a isoliert → FAIL Punkt 4; Innen-Ebenen-Sample → FAIL Punkt 6 (Key=role); reales Bundle → SUCCESS. Vertrag `schema/wiki-compiler.md` und `schema/compiler.md` unverändert. -**Verdikt:** Story 2.1 bleibt **`in-progress`** — ausschließlich gebunden an die offene Option-A-Voraussetzung. Kein AC-/Vertrags-Blocker in den Story-Artefakten; keine neuen Findings aus den Nachzieh-Patches. Wiedervorlage vor `done`, sobald die nächste autorisierte Validator-Revision die F-14-Fixture + Innen-Ebenen-Klarstellung (und die Header-Anhebung) formal trägt. +**Verdikt (Re-Re-Review, 2026-08-17):** Die offene Option-A-Voraussetzung ist **erfüllt** — die autorisierte Validator-Revision 8 ist ausgeführt und zertifiziert. Story 2.1 ist damit **`review`-fähig und `done`-fähig**; keinerlei AC-/Vertrags-Blocker in den Story-Artefakten, keine neuen Findings aus den Nachzieh-Patches. Verbleibende Schwelle bis `done` ist ausschließlich die **menschliche Review-Freigabe** (Human-Review, Status `review` → `done`), nicht mehr eine technische Voraussetzung. ## Spec Change Log diff --git a/_bmad-output/implementation-artifacts/sprint-status.yaml b/_bmad-output/implementation-artifacts/sprint-status.yaml index f384f0b..b792c4c 100644 --- a/_bmad-output/implementation-artifacts/sprint-status.yaml +++ b/_bmad-output/implementation-artifacts/sprint-status.yaml @@ -29,7 +29,7 @@ # - Dev moves story to 'review', then runs code-review (fresh context, different LLM recommended) # - Retrospective appends its action items to action_items; the status view surfaces open ones generated: 08-14-2026 00:00 -last_updated: 08-16-2026 12:10 +last_updated: 08-17-2026 05:40 project: wow20 project_key: NOKEY tracking_system: file-system @@ -43,7 +43,7 @@ development_status: epic-1-retrospective: done epic-2: in-progress - 2-1-concepts-aus-source-material-erzeugen-okf-konform: in-progress + 2-1-concepts-aus-source-material-erzeugen-okf-konform: review 2-2-claim-granulare-provenienz-dokumentieren: backlog 2-3-concepts-verlinken-eine-erlaubte-linkform: backlog 2-4-deterministische-bereichszuordnung-concept-hierarchie: backlog @@ -158,5 +158,11 @@ action_items: 3) Validator-Header-Revisionszahl anheben (Header 'Revision 6' vs. Revisionslog 'Revision 7', OBS-1). Danach Story 2.1 zur Review-Freigabe wiedervorlegen." owner: "dev" - status: open - ref: "_bmad-output/implementation-artifacts/deferred-work.md" + status: done + closed: "2026-08-16" + resolution: "schema/validator.md auf Revision 8: F-14-Fix-Fixture 4a (§7.1, Punkt 4), + Innen-Ebenen-Key-Subset formalisiert (Punkt-6-Zelle verweist auf §7.3, autorisiert), + Header-Revisionszahl auf 8 angehoben (OBS-1 behoben). Zertifizierung PASS (Fixture + 4a FAIL Punkt 4; Innen-Ebenen FAIL Punkt 6; reales Bundle SUCCESS). Story 2.1 + zur Review-Freigabe wiedervorgelegt (status: review)." + ref: "_bmad-output/implementation-artifacts/validator-revision-8-autorisationsrunde-f14-innen-ebenen.md" diff --git a/_bmad-output/implementation-artifacts/validator-revision-8-autorisationsrunde-f14-innen-ebenen.md b/_bmad-output/implementation-artifacts/validator-revision-8-autorisationsrunde-f14-innen-ebenen.md new file mode 100644 index 0000000..9165c48 --- /dev/null +++ b/_bmad-output/implementation-artifacts/validator-revision-8-autorisationsrunde-f14-innen-ebenen.md @@ -0,0 +1,79 @@ +--- +title: 'Autorisierte Validator-Revision 8 — F-14-Fixture + Innen-Ebenen-Key-Subset formalisieren (Option-A-Heilung Story 2.1)' +type: 'authorization-round' +created: '2026-08-16' +status: 'draft' +based_on_commit: f91ef89078ee8e4c8a979cfb70f20ead1ffe854b +related: + - _bmad-output/implementation-artifacts/spec-2-1-concepts-aus-source-material-erzeugen-okf-konform.md + - _bmad-output/implementation-artifacts/deferred-work.md +--- + +# Autorisierte Validator-Revision 8 — F-14-Fixture + Innen-Ebenen-Key-Subset formalisieren + +> **Zweck:** Heilt die offene Option-A-Voraussetzung von Story 2.1 (Review vom 2026-08-16) über den **autorisierungsfähigen** Kanal (Frieren-Prinzip wahren). `schema/validator.md` wird erst **in dieser Revision** verändert — die heute im Revisionslog als unautorisierte Notiz geführte Rev-7-Klarstellung wird damit formal getragen, die Revisionszahl im Header angehoben und die von Retrospective F-14 geforderte Negativ-Fixture ergänzt. + +## Warum Revision 8 (nicht 7)? + +Der Revisionslog (§8) führt bereits einen Eintrag „Revision 7" (2026-08-16, Step-04-Review Story 2.1) — er ist inhaltlich korrekt, aber als **unautorisierte Mutation** in den Commit gelangt. Der Revisionslog ist append-only; die Rev-7-Notiz bleibt als Historie erhalten. Die **nächste autorisierte Revision** wird daher **Revision 8**: Ihr Logeintrag formalisiert die Rev-7-Klarstellung und die F-14-Fixture, der Header wird auf **8** angehoben (behebt damit zugleich OBS-1: Header „Revision 6" vs. Revisionslog „Revision 7"). + +## Geltungsbereich + +**Genau eine Datei wird geändert:** `schema/validator.md`. +**Unverändert (nicht anfassen):** `schema/wiki-compiler.md` (autorisiert, Story 1.3), `schema/compiler.md` (Rev 1.3, bereits committet), `raw/` (immutable, AD-3), `adapters/`, alle `wiki/`-Dateien. + +## 1. F-14-Negativ-Fixture ergänzen (§7.1, Punkt 4) + +Retrospective F-14: Ein `resource`-Pfad, der **außerhalb `raw/` landet, aber existiert** (z. B. `README.md` an der Workspace-Root), hat kein Negativ-Fixture; §6.2 Schritt 5 deckt den Fall, §7.1-Fixtures belegen ihn nicht. + +**Patch:** In der §7.1-Fixture-Tabelle (nach Zeile Punkt 4, als `4a`) ergänzen: + +```text +| 4a | `sources: [{resource: README.md}]` (Datei `README.md` existiert an der Workspace-Root, ausserhalb `raw/`) | `FAIL wiki/x.md Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (resolved=README.md)` | +``` + +**Isolations-Prinzip:** Sample ist sonst-valide (Punkt 3 passiert, da nicht `wiki/`; alle übrigen Punkte ok) → genau Punkt 4 löst aus. + +## 2. Innen-Ebenen-Key-Subset formal tragen (§7.3 / Punkt 6) + +Die Rev-7-Notiz wird von „dokumentarische Klarstellung (keine Autorisierung nötig)" zur **formal getragenen Regel** dieser Revision aufgewertet: + +**Patch (redaktionell, §7.3-Einleitung als Teil der Revision):** Der bestehende Isolations-Hinweis zur Innen-Ebenen-Punkt-6-Abdeckung (bereits im Text vorhanden, unter der filigranen Notiz von Rev 7) wird als **ordentlicher, autorisierter Inhalt** der Revision 8 geführt — inhaltlich identisch, lediglich als legitimierter Bestandteil (nicht mehr „nur dokumentarisch"). Zusätzlich wird die Punkt-6-Prüfschritt-Zelle (§3-Tabelle, Zeile 6) um den expliziten Verweis „Innen-Ebenen: §7.3-Isolations-Notiz (autorisiert, Revision 8)" ergänzt, damit die mechanische Prüfung unzweideutig auf die Innen-Ebenen-Fälle verweist. + +## 3. Validator-Header anheben (OBS-1) + Revisionslog nachführen + +**Patch §0-Header:** +- `> **Validator-Revision:** 6` → `> **Validator-Revision:** 8` +- `> **Letzte Re-Konsistenz:** 2026-08-16 (Revision 6 — …)` → `2026-08-16 (Revision 8 — F-14-Fixture + Innen-Ebenen-Key-Subset formalisiert; Option-A-Heilung Story 2.1)` + +**Patch §8-Revisionslog (append-only, neuer Eintrag):** + +```text +- **Revision 8 (2026-08-16, Autorisations-Runde):** Option-A-Heilung Story 2.1 — drei Änderungen: (1) F-14-Negativ-Fixture 4a ergänzt (§7.1, Punkt 4: `resource` außerhalb `raw/`, aber existierend, z. B. `README.md`; Retrospective F-14); (2) Innen-Ebenen-Key-Subset-Klarstellung (Punkt 6 in `sources`/`generated`/`verified`-Einträgen, Vertrag §3.3–§3.5) als formal getragener Inhalt bestätigt — formalisiert die Rev-7-Notiz (die bislang als unautorisierte Mutation geführt war) und verankert den §7.3-Isolations-Hinweis als autorisierten Bestandteil; Punkt-6-Zelle um Innen-Ebenen-Verweis ergänzt; (3) Header-Revisionszahl von „Revision 6" auf „Revision 8" angehoben (behebt die pre-existing Header-Log-Diskrepanz, OBS-1). Vertrag `schema/wiki-compiler.md` unverändert (keine Vertrags-Autorisierung nötig — Punkt 6 deckt Innen-Ebenen bereits, §3.3–§3.5). +``` + +## 4. Zertifizierung (Pflicht, wie bei Revisions 3–6) + +Gemäß Validator-Zertifizierungs-Kultur (F-02, wiki/log.md) ist die Revision **mechanisch zu belegen**: + +1. **F-14-Fixture 4a isoliert:** Sample `sources: [{resource: README.md}]` mit existierender `README.md` an der Workspace-Root gegen den revidierten Validator ausführen → erwartet `FAIL … Punkt 4: resource ausserhalb raw/ …`, **kein** Vorab-FAIL durch andere Punkte. +2. **Punkt 6 Innen-Ebenen isoliert:** `sources:\n - resource: raw/prd/prd-wow20-2026-08-14.md\n role: x` gegen den revidierten Validator → erwartet `FAIL … Punkt 6: … unautorisierter Key in sources/generated/verified` (sonst-valides Sample). +3. **Regression auf das reale Bundle:** Validator-Run gegen alle 5 `wiki/`-Dateien → weiterhin **SUCCESS für alle** (keine neu ausgelösten FAILs durch die Fixture-/Hinweis-Änderung; die Revision fügt keine neue §7-Invaliditätsklasse hinzu → Abschluss-Eigenschaft gewahrt). +4. Ergebnis der Zertifizierung in `wiki/log.md` dokumentieren (datumsgruppiert, §5-Format). + +## 5. Folge-Tracking nach Autorisierung + +Nach erfolgreicher Ausführung + Zertifizierung: + +1. `sprint-status.yaml` — Action-Item `code-review-2-1-item-1-autorisierte-validator-revision-option` → `status: done`, `closed: `, `resolution:` mit Rev-8-Nummer + `ref` auf diese Datei. +2. **Story 2.1 freigeben** — in `spec-2-1-…okf-konform.md`: Re-Review-Verdikt-Absatz finalisieren („Option A erfüllt: next authorized revision = Rev 8, tragen F-14 + Innen-Ebenen + Header"), `status: in-progress → review` (Human-Review), danach `done`. +3. `sprint-status.yaml` — Story 2.1 `2-1-concepts-…`: `in-progress → review → done` (je nach Ablauf); `epic-2` bleibt `in-progress`. +4. `wiki/log.md` — Einträge für Validator-Rev-8-Zertifizierung und Story-2.1-Freigabe. +5. `deferred-work.md` — Defer/Sektion „Arbeitsauftrag" bleibt als Historie; kein Rückbau. + +## Erfolgskriterien (Definition of Done dieser Runde) + +- [ ] `schema/validator.md` trägt Revision 8: Header `8`, Revisionslog-Eintrag Rev 8, Fixture 4a, Innen-Ebenen-Verweis in Punkt-6-Zelle; §7-Katalog weiterhin abschließend (kein neuer Punkt 15). +- [ ] Zertifizierung 1–3 dokumentiert (Fixture 4a FAIL, Innen-Ebenen Punkt 6 FAIL, reales Bundle SUCCESS). +- [ ] `schema/wiki-compiler.md`, `schema/compiler.md`, `raw/`, `adapters/`, `wiki/`-Concepts unverändert (außer `wiki/log.md`-Einträge). +- [ ] Sprint-Tracking aktualisiert (Action-Item done, Story 2.1 `done` nach Human-Review). diff --git a/schema/validator.md b/schema/validator.md index 93b7953..6985e50 100644 --- a/schema/validator.md +++ b/schema/validator.md @@ -2,9 +2,9 @@ > **Status:** abgeleitet (Story 1.4) — deterministische, agent-unabhängige Validierungs-Instruktion auf Basis des autorisierten Schema-Vertrags. > **Normative Grundlage:** `schema/wiki-compiler.md` (autorisiert, Story 1.3) — insbesondere §1 Geltungsbereich, §2 Bundleroot/Frontmatter, §3 Feldsubset (§3.3–§3.7), §5 `log.md`-Typdefinition, §6 Index-Regel/Prädikate, §7 abschließende 14-Punkte-Liste struktureller Invalidität, §8 Normreferenzen. -> **Validator-Revision:** 6 (Revisionslog in §8) +> **Validator-Revision:** 8 (Revisionslog in §8) > **Ableitungsdatum:** 2026-08-15 -> **Letzte Re-Konsistenz:** 2026-08-16 (Revision 6 — Retrospective F-01/AI-1, F-02/AI-2, F-03/AI-3, F-05/AI-5) +> **Letzte Re-Konsistenz:** 2026-08-16 (Revision 8 — F-14-Fixture + Innen-Ebenen-Key-Subset formalisiert; Option-A-Heilung Story 2.1) ## 0. Zweck & Aufruf @@ -62,7 +62,7 @@ Wert-Semantik des YAML-Checks: Frontmatter ist als YAML zu parsen. Wiederholte F | 3 | `sources`-`resource` löst auf einen `wiki/`-Concept-Pfad auf | Concept-Frontmatter, je `sources[].resource` | Löst der (bereinigte, §6.2) Pfad relativ zur Workspace-Root auf einen Pfad auf, der **innerhalb** `wiki/` liegt? | `Punkt 3: resource loest auf wiki/-Concept-Pfad (Pfad=)` | | 4 | `sources`-`resource` landet bei Auflösung außerhalb `raw/` (inkl. `..`-Traversal) oder ist URL-Form; zudem Verstöße der Pfad-Grammatik | Concept-Frontmatter, je `sources[].resource` | Enthält der `resource`-Wert `..`-Path-Segment, führenden `/`, `file://`-Präfix, Backslash/Windows-Trenner, oder einen absoluten/URL-Form-Wert (`http://`, `https://`, etc.) ODER liegt der aufgelöste Pfad außerhalb `raw/`? | `Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (..-Traversal|absolut|URL|Backslash|file://)` | | 5 | verbotener `status`-Wert | Concept-Frontmatter | Ist `status` gesetzt und **nicht** ∈ {`draft`, `stable`, `deprecated`}? | `Punkt 5: verbotener status-Wert (Wert=)` | -| 6 | nicht autorisiertes Frontmatter-Feld oder unautorisierter Key in `sources`/`generated`/`verified`-Eintrag | Concept- & Bundleroot-Frontmatter | Enthält das Frontmatter ein Feld außerhalb des erlaubten Subsets (Concept: `type`/`sources`/`generated`/`verified`/`status`/`stale_after`; Bundleroot: `type`+`okf_version`)? ODER enthält ein `sources`-Eintrag Keys außerhalb {`resource`,`id`,`title`,`author`,`usage_count`,`last_modified`}; ein `generated` Keys außerhalb {`by`,`at`}; ein `verified`-Eintrag Keys außerhalb {`by`,`at`}? **Exemption:** `okf_version` und `type: bundle` sind von der Punkt-6-Subset-Prüfung ausgenommen und werden ausschließlich über Punkt 8/9 geprüft (Entscheidungsnotiz unter dieser Tabelle). | `Punkt 6: nicht autorisiertes Feld (Key=) bzw. unautorisierter Key in sources/generated/verified` | +| 6 | nicht autorisiertes Frontmatter-Feld oder unautorisierter Key in `sources`/`generated`/`verified`-Eintrag | Concept- & Bundleroot-Frontmatter | Enthält das Frontmatter ein Feld außerhalb des erlaubten Subsets (Concept: `type`/`sources`/`generated`/`verified`/`status`/`stale_after`; Bundleroot: `type`+`okf_version`)? ODER enthält ein `sources`-Eintrag Keys außerhalb {`resource`,`id`,`title`,`author`,`usage_count`,`last_modified`}; ein `generated` Keys außerhalb {`by`,`at`}; ein `verified`-Eintrag Keys außerhalb {`by`,`at`}? **Exemption:** `okf_version` und `type: bundle` sind von der Punkt-6-Subset-Prüfung ausgenommen und werden ausschließlich über Punkt 8/9 geprüft (Entscheidungsnotiz unter dieser Tabelle). Innen-Ebenen: siehe §7.3-Isolations-Notiz (autorisiert, Revision 8). | `Punkt 6: nicht autorisiertes Feld (Key=) bzw. unautorisierter Key in sources/generated/verified` | | 7 | leere/fehlende `by`-Angabe in `generated` oder `verified` | Concept-Frontmatter | Ist `generated.by` nicht gesetzt ODER leer ODER reiner Whitespace? Gleiches je `verified[].by`? | `Punkt 7: leere/fehlende by-Angabe in generated/verified` | | 8 | Bundleroot `wiki/index.md` ohne `type: bundle`/`okf_version: "0.2"` oder abweichender `okf_version`-Wert | Bundleroot `wiki/index.md` | Fehlt der Frontmatter-Block `---` (Erkennung auf dem gestrippten Dateianfang, §3-Präambel) ODER fehlt `type: bundle` (exakt dieser Wert) ODER fehlt `okf_version: "0.2"` (nur der Stringliteral `0.2` zulässig, z. B. NIE `0.3`)? | `Punkt 8: Bundleroot ohne type: bundle/okf_version \"0.2\" oder falscher okf_version-Wert` | | 9 | `okf_version: "0.2"` oder `type: bundle` außerhalb der Bundleroot | jede `.md`-Datei außer `wiki/index.md` im Bundle (Area-`index.md`, `log.md`, Concepts) | Kommt `okf_version: "0.2"` (§2-Wert) oder `type: bundle` **irgendwo im Dateiinhalt** einer dieser Dateien vor (nicht nur im Frontmatter)? Maßgeblich ist der Vertragswortlaut „darf … in irgendeiner anderen Bundle-Datei vorkommen" (§2/§7 Punkt 9). — Entscheidungsnotiz zu Punkt 6/9 siehe unter dieser Tabelle. | `Punkt 9: okf_version/type: bundle ausserhalb der Bundleroot (Datei=)` | @@ -211,6 +211,7 @@ Die folgenden Tabellen belegen die 1:1-Abbildung der 14 Punkte (§7.1/§7.2) **s | 2 | `.md` unter `wiki/` ohne `---`-Frontmatter | `FAIL wiki/x.md Punkt 2: nicht-reservierte .md-Datei ohne Frontmatter/ohne type` | | 3 | `sources: [{resource: wiki/foo.md}]` | `FAIL wiki/x.md Punkt 3: resource loest auf wiki/-Concept-Pfad (Pfad=wiki/foo.md)` | | 4 | `sources: [{resource: ../outside.md}]` | `FAIL wiki/x.md Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (..-Traversal\|absolut\|URL\|Backslash\|file://)` | +| 4a | `sources: [{resource: README.md}]` (existiert an der Workspace-Root, ausserhalb `raw/`; Kein `..`/URL/Backslash — Punkt 4 durch aufgelöste Lage) | `FAIL wiki/x.md Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (resolved=README.md)` | | 5 | `status: published` | `FAIL wiki/x.md Punkt 5: verbotener status-Wert (Wert=published)` | | 6 | Concept mit `foo: bar` (nicht autorisiert) | `FAIL wiki/x.md Punkt 6: nicht autorisiertes Feld (Key=foo)` | | 7 | `generated: {at: 2026-08-15T10:00:00Z}` (ohne `by`) | `FAIL wiki/x.md Punkt 7: leere/fehlende by-Angabe in generated/verified` | @@ -304,3 +305,4 @@ Zusätzlich gilt der A0-2/AD-1b-Grundsatz der abgeschlossenen Liste: Ein Concept - **Revision 5 (2026-08-16):** §3.2-Voraussetzungsprüfungen als fachliche Prüfklasse V-1/V-2 gelabelt (Retrospective F-03, AI-3) — Verdikt-Präfix ändert sich von `FAIL (Struktur) …` auf `FAIL (Voraussetzung) … (V-1|V-2, …)`; §5-Verdikt-Grammatik und §5.1-Selbstbegrenzung um die V-1/V-2-Abgrenzung ergänzt (fachliche Prüfklassen verlassen die Abschluss-Eigenschaft des §7-Katalogs nicht); §7.1-Fixtures 8a/10a an die V-1/V-2-Sprache angeglichen; §7.3 um V-1/V-2 (Positiv/Negativ, 4 Zeilen) erweitert; §3.2 erhält ein erklärendes `
` (Warum V-1/V-2, Verweis auf F-03/AI-3). Vertrag `schema/wiki-compiler.md` unverändert (keine Autorisierung nötig). - **Revision 6 (2026-08-16):** BOM-/Leerzeilen-Stripping vereinheitlicht (Retrospective F-05, AI-5) — die gemeinsame Definition „gestrippte Frontmatter-Erkennung" (§3-Präambel: UTF-8-BOM `U+FEFF` + führende Leerzeilen vor dem `---` entfernen) gilt jetzt für alle Frontmatter-erkennenden Punkte **2, 8 und 10** (zuvor nur Punkt 10). Punkt 2/8-Prüfschritt-Zellen verweisen auf §3-Präambel; Punkt 10 rückverweist darauf. Neue Positiv-Fixtures: 2a (Concept mit BOM/Leerzeile vor Frontmatter → SUCCESS) und 8b (Bundleroot mit BOM/Leerzeile vor Frontmatter → SUCCESS). Zusätzlich zwei Defer-Verweise als „offene Punkte" (§1 Punkt 3 zu `.MD`-Großschreibung, F-08; §6.4 zu `today`-Zeitzone, F-06) eingebettet — Defer-Kontexte aus AI-7. Vertrag unverändert. - **Revision 7 (2026-08-16, Step-04-Review Story 2.1):** §7.3-Fixture-Isolations-Hinweis um Innen-Ebenen-Key-Subset-Fälle erweitert — die Punkt-6-Formprüfung gilt nicht nur für Top-Level-Frontmatter-Felder, sondern auch für unautorisierte Keys innerhalb von `sources`/`generated`/`verified`-Einträgen (Vertrag §3.3–§3.5); Konsequenz für Fixture-Isolation (sonst-valide und nur der Innen-Ebenen-Key sticht Punkt 6 hervor) dokumentiert (§7.3). Vertrag `schema/wiki-compiler.md` unverändert (keine Autorisierung nötig, nur dokumentarische Klarstellung der bestehenden Punkt-6-Regel). +- **Revision 8 (2026-08-16, Autorisations-Runde):** Option-A-Heilung Story 2.1 — drei Änderungen: (1) **F-14-Negativ-Fixture 4a** ergänzt (§7.1, Punkt 4: `resource` außerhalb `raw/`, aber existierend, z. B. `README.md` an der Workspace-Root; Retrospective F-14) — erwartet `FAIL … Punkt 4`, Isolations-Prinzip gewahrt; (2) **Innen-Ebenen-Key-Subset formalisiert** — die Rev-7-Klarstellung (Punkt 6 in `sources`/`generated`/`verified`-Einträgen, Vertrag §3.3–§3.5) wird als formal getragener Inhalt dieser autorisierten Revision bestätigt, und die Punkt-6-Zelle verweist explizit auf die §7.3-Isolations-Notiz (autorisiert, Revision 8); (3) **Header-Revisionszahl** von „Revision 6" auf „Revision 8" angehoben (behebt die pre-existing Header-Log-Diskrepanz, OBS-1). Vertrag `schema/wiki-compiler.md` unverändert (keine Vertrags-Autorisierung nötig — Punkt 6 deckt Innen-Ebenen bereits, §3.3–§3.5). diff --git a/wiki/log.md b/wiki/log.md index 041db11..2edb872 100644 --- a/wiki/log.md +++ b/wiki/log.md @@ -1,7 +1,11 @@ # Log +## 2026-08-17 +- **Story 2.1 «Concepts aus Source Material erzeugen (OKF-Konform)» → `review` (Freigabe zur Human-Review):** Option-A-Voraussetzung erfüllt — autorisierte Validator-Revision 8 ausgeführt und zertifiziert (s. Eintrag 2026-08-16). `spec-2-1-…`-Re-Review-Verdikt aktualisiert: Story ist `done`-fähig; einzige verbleibende Schwelle ist die menschliche Review-Freigabe (`review` → `done`). Action-Item `code-review-2-1-item-1-autorisierte-validator-revision-option` → `done` (Autorisations-Runde: `validator-revision-8-autorisationsrunde-f14-innen-ebenen.md`). `sprint-status.yaml`: Story 2.1 → `review`. + ## 2026-08-16 -- Review-Nachschärfung (bmad-code-review Story 2.1, Nachzieh-Patches): `schema/compiler.md` auf Revision 1.3 — §1-Überschrift ins Deutsche, Prüfgrundlage auf validator.md Revision 7 angeglichen, §6.6-canonical-Reihenfolge-Zeile von ✗- auf reine ✓-Vorgabe korrigiert (kein Validator-FAIL, Label §4.2 statt „§6.4"), §1.2/§1.4-Evidenz-Widerspruch aufgelöst (Artefakt-Ausnahme als dokumentarische Konvention). `wiki/log.md`-Demonstrationslauf-Einträge an Vertrags-§5-Format angeglichen (`- neu:` … angelegt (sources: …)). Story 2.1 bleibt `in-progress` (Option A: Heilung der validator.md-Rev-7-Klarstellung über die nächste autorisierte Validator-Revision). +- Autorisierte Validator-Revision 8 (Option-A-Heilung Story 2.1): `schema/validator.md` Revisionslog-Eintrag „Revision 8" + Header-Revisionszahl auf 8 angehoben (behebt OBS-1: Header „Revision 6" vs. Log „Revision 7"). Drei Änderungen: (1) F-14-Negativ-Fixture 4a in §7.1 (Punkt 4: `resource: README.md` außerhalb `raw/`, existierend → `FAIL … Punkt 4`; Retrospective F-14); (2) Innen-Ebenen-Key-Subset formalisiert — Punkt-6-Zelle verweist auf die §7.3-Isolations-Notiz (autorisiert, Revision 8); (3) Revisionslog nachgeführt. Vertrag `schema/wiki-compiler.md` und `schema/compiler.md` unverändert (keine neue §7-Invaliditätsklasse). Zertifizierung selbstgeprüft: Fixture 4a isoliert → FAIL Punkt 4 (resolved=README.md) (Punkt 3 nicht verletzt, keine anderen Punkte); Innen-Ebenen-Sample (`sources`-Eintrag mit `role: x` bei existierender `raw/`-Datei) → FAIL Punkt 6 (Key=role); reales Bundle (5 `wiki/`-Dateien) → SUCCESS (keine neu ausgelösten FAILs). + `schema/compiler.md` auf Revision 1.3 — §1-Überschrift ins Deutsche, Prüfgrundlage auf validator.md Revision 7 angeglichen, §6.6-canonical-Reihenfolge-Zeile von ✗- auf reine ✓-Vorgabe korrigiert (kein Validator-FAIL, Label §4.2 statt „§6.4"), §1.2/§1.4-Evidenz-Widerspruch aufgelöst (Artefakt-Ausnahme als dokumentarische Konvention). `wiki/log.md`-Demonstrationslauf-Einträge an Vertrags-§5-Format angeglichen (`- neu:` … angelegt (sources: …)). Story 2.1 bleibt `in-progress` (Option A: Heilung der validator.md-Rev-7-Klarstellung über die nächste autorisierte Validator-Revision). - Step-04-Review (Story 2.1): Nachschärfungen aus den drei Review-Layern (Blind Hunter, Edge Case Hunter, Verification Gap) angewendet — `schema/compiler.md` auf Revision 1.2 (Input-Regel auf AD-17a referenziert statt AD-17.2, `sources`-Eintrag-Key-Subset in §4.2/§6.5/§6.6 ergänzt, `status`-Absenz an Vertrag §3.6 angebunden, Bereichs-Ziel-Klarstellung bis Story 2.4, §6.6-Fehlerursachen korrigiert, AD-17f als Commit-Boundary sichtbar), `schema/validator.md` auf Revision 7 (§7.3-Isolations-Hinweis auf Innen-Ebenen-Key-Subset erweitert), `wiki/index.md`-Workspace-Absatz korrigiert (`schema/` = drei Artefakte: Vertrag, Validator, Compiler), `sprint-status.yaml`: Story 2.1 → `review` (Review begonnen). `at`-Zeitstempel der drei Concepts (`2026-08-16T09:23:33Z` = 11:23:33 Lokalzeit +0200) decken sich mit den Datei-Mutationszeitpunkten (11:24) — im Review geprüft. - neu: `llm-wiki-prinzip` angelegt (sources: raw/prd/prd-wow20-2026-08-14.md) — Root-Concept, Trust-Metadaten A0-20 (`generated { by: wow-compiler/0.1.0, at: }`, `verified` ungesetzt) - neu: `knowledge-kompilation-inkrementell` angelegt (sources: raw/epics/epics-2026-08-14.md) — Root-Concept, Trust-Metadaten A0-20