diff --git a/_bmad-output/implementation-artifacts/spec-autorisierte-validator-revision-9-punkt-11-area-lesart.md b/_bmad-output/implementation-artifacts/spec-autorisierte-validator-revision-9-punkt-11-area-lesart.md new file mode 100644 index 0000000..8d7a6b2 --- /dev/null +++ b/_bmad-output/implementation-artifacts/spec-autorisierte-validator-revision-9-punkt-11-area-lesart.md @@ -0,0 +1,158 @@ +--- +title: 'Autorisierte Validator-Revision 9 — Punkt-11-Area-Lesart formalisieren + gehaltene Rev-8-Patches tragen' +type: 'chore' +created: '2026-08-18' +status: 'done' +baseline_commit: ef84309db7ca0090c3e124b8c364c56cc72186f3 +review_loop_iteration: 0 +context: + - _bmad-output/implementation-artifacts/validator-revision-8-autorisationsrunde-f14-innen-ebenen.md + - _bmad-output/implementation-artifacts/epic-2-retro-2026-08-18.md +--- + + + +## Intent + +**Problem:** Der Validator (`schema/validator.md`, Rev 8) ist für Epic 2 nur über eine aufgelockerte Lesart konsistent: Punkt 11 verlangt, die Concept-Identität sei „als relativer Bundle-Pfad referenziert", aber die Area-`index.md` verlinkt ihr Area-Concept file-relativ (`source-material.md`) — die wörtliche Bundle-Identität `wissensarchitektur/source-material` kommt im Bereichs-Index nicht vor. Ein wörtlich-mechanischer Rev-8-Check meldete das Live-Concept als „nicht verlinkt". Zusätzlich sind zwei gehaltene Review-Patches (Punkt-4-`resolved=`-Token, Innen-Ebenen-Punkt-6-Fixture-Zeile) ausstehend — die Rev-8-Formalisierung ist damit nicht re-runbar belegt. + +**Approach:** Eine autorisierte Validator-Revision 9 ausführen, die (1) die Punkt-11-Area-Lesart formal trägt (relative OKF-Pfad-Identität, auch file-relativ in der zuständigen Area-`index.md`) und damit die AD-3/D-3-Freeze-Währung wahrt, (2) die beiden gehaltenen Patches als Teil der Revision trägt, (3) Header auf 9 anhebt, Revisionslog (append-only) nachführt und die Zertifizierung (isolierte Fixtures + reales Bundle) mechanisch belegt. + +## Boundaries & Constraints + +**Always:** +- `schema/validator.md` ist die **einzige** zu ändernde Vertrags-/Validator-Datei. `schema/wiki-compiler.md` (Vertrag, Story 1.3) und `schema/compiler.md` (Instruktion) bleiben **unverändert** — die Rev-9-Lesart verschärft keinen §7-Punkt und fügt **keine neue §7-Invaliditätsklasse** hinzu (kein Punkt 15); die Abschluss-Eigenschaft des §7-Katalogs bleibt gewahrt (F-04-Kultur, AD-1b). +- `raw/` (immutable, AD-3), `adapters/`, alle bestehenden `wiki/`-Dateien bleiben unverändert (außer `wiki/log.md`, Zertifizierungs-Nachweis). +- Der §8-Revisionslog ist **append-only** — der Rev-9-Eintrag wird angehängt, bestehende Einträge bleiben unangetastet. Die Punkt-11-Normreferenz-Notiz „Story 2.3 (Link-Form)" wird um die Rev-9-Area-Lesart ergänzt (derselbe Normreferenz-Block, append). +- Die Formulierung bleibt **rein textuell** (D-3): keine neue Prüfklasse, kein Standalone; die mechanische Re-Exekution folgt den im Revisionslog dokumentierten Formeln. +- Datums- und Revisions-Werte nach dem Wiki-Log- und Sprint-Status-Format; die Revisionszahl geht von 8 auf 9 (Header + Revisionslog). + +**Ask First:** +- Branch-Wechsel/Merge-Strategie für `validator-rev-9` (aktuell noch nicht zurückgeführt). +- Falls die Zertifizierung am Live-Baum Abweichungen zeigt, die nicht durch die Doku-Kultur (wiki/log.md) heilbar sind — vor Fortsetzung HALT. +- Die Behandlung der weiteren offenen Epic-2-Items (AI-2-R-1 … R-4: §5.5-rekursiv, §5.8-Tiefe-2, Formel-4-Asymmetrie, §5.8-Reachability) ist **nicht** Teil dieser Revision — bei Scope-Drift Richtung compiler.md HALT. + +**Never:** +- Keine Änderung an `raw/`, `adapters/`, `schema/wiki-compiler.md`, `schema/compiler.md` oder den bestehenden `wiki/`-Concept-Dateien. +- Kein neuer §7-Punkt, keine Erfindung einer neuen Invaliditätsklasse. +- Keine Änderung an gefrorenen/I-O-Matrix-Texten außerhalb des explizit autorisierten Rev-9-Umfangs (kein ad-hoc-Editing). +- Keine Bauch-Formulierungen: jede Formulierung wird gegen den realen Bundle-Baum (7 Dateien) und die Fixture-Tabellen in §7 geprüft. + +## I/O & Edge-Case Matrix + +| Scenario | Input / State | Expected Output / Behavior | Error Handling | +|----------|--------------|---------------------------|----------------| +| POINT11_AREA_LINK | `wiki/wissensarchitektur/index.md` verlinkt `source-material.md` (file-relativ, gepinnte §5.6-Form) | Area-Concept-Identität `wissensarchitektur/source-material` ist gewahrt — Punkt 11 → kein FAIL (SUCCESS) | Verschiebt sich nicht in einen anderen Punkt; kein WARN | +| POINT11_WORDING_FAIL | Area + Concept ohne Link (Bundle-Identität nirgends) | `FAIL wiki/… Punkt 11: Index-Regel verletzt (Concept nicht verlinkt=)` | Identität über Pärchen Area-Präfix + Link-Ziel abgeleitet | +| FIXTURE_4A | `sources: [{resource: README.md}]` (existierende Datei an Workspace-Root, außerhalb `raw/`) | `FAIL wiki/x.md Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (resolved=README.md)` — ableitbar aus §3-Punkt-4-Vorlage | Punkt-4-vor-3-Priorität (§6.2): kein Vorab-FAIL durch Punkt 3 | +| INNER_LEVEL_KEY | `sources:\n - resource: raw/prd/prd-wow20-2026-08-14.md\n role: x` (sonst-valides Sample, existierende `raw/`-Datei) | `FAIL wiki/x.md Punkt 6: nicht autorisiertes Feld (Key=role) bzw. unautorisierter Key in sources/generated/verified` | Nur Punkt 6 löst aus — Isolations-Prinzip (§7.3) | +| LIVE_BUNDLE_REGRESSION | Alle 7 `wiki/`-Dateien gegen den revidierten Validator | weiterhin SUCCESS für alle Dateien (keine neu ausgelösten FAILs) | Keine neue §7-Klasse; Abschluss-Eigenschaft gewahrt | + + + +## Code Map + +- `schema/validator.md` — die **einzige** zu ändernde Datei (Rev 9). Anker: §0-Header (Z. 6–8, Revisionszahl 8 → 9 + Letzte-Re-Konsistenz), §3 Punkt-4-Tabelle (Z. 63, Vorlage ohne `resolved=`-Token), §3 Punkt-6-Tabelle (Z. 65, Innen-Ebenen-Verweis vorhanden), §3 Punkt-11-Tabelle (Z. 70, Kern der Area-Lesart), §7.1-Fixtures Punkt 4a/6 (Z. 214/216), §7.3-Fixture-Isolations-Notiz (Z. 263, Innen-Ebenen-Kontext), §8-Normreferenz-Notiz „Story 2.3 (Link-Form)" (Z. 297), §8-Revisionslog (Z. 299–308, append-only). +- `_bmad-output/implementation-artifacts/validator-revision-8-autorisationsrunde-f14-innen-ebenen.md` — der Rev-8-Präzedenzfall (Autorisierungskanal, Zertifizierung, Follow-Tracking); formt die Rev-9-Runde strukturell. +- `_bmad-output/implementation-artifacts/deferred-work.md` — Z. 184–191: die **gehaltenen Patches 16/17** (Punkt-4-`resolved=`-Token, Innen-Ebenen-Punkt-6-Fixture-Zeile) mit exakter gewünschter Wortform; Z. 279–287: F-02/Rev-9-Aktionsitem-Kontext. +- `_bmad-output/implementation-artifacts/epic-2-retro-2026-08-18.md` — F-02 (Punkt-11-Wortlaut vs. file-relative Area-Linkform), AI-2-R-5 (de-dupliziert mit `code-review-2-1-item-2`), Open question 3 (exakte Formulierung der Area-Lesart). +- `wiki/index.md` — Bundleroot (Z. 33–37, Area-Sektion); verlinkt die Area als `(wissensarchitektur/index.md)` — **nur** die Area, nicht das Area-Concept. +- `wiki/wissensarchitektur/index.md` — Area-`index.md` (frontmatterlos, Z. 9: file-relativer `(source-material.md)`-Link); beweist die Live-F-02-Lage (Bundle-Identität `wissensarchitektur/source-material` kommt textuell nirgends vor, grep → 0). +- `wiki/wissensarchitektur/source-material.md` — das Area-Concept; durch die Layer-6/7-Struktur das vom wörtlichen Rev-8-Punkt-11-Check fälschlich „nicht verlinkt" gemeldete Concept. +- `wiki/log.md` — §5-Format-Zertifizierungs-Nachweis (datumsgruppiert 2026-08-16/17/18; Rev-9-Eintrag wird ergänzt). +- `_bmad-output/implementation-artifacts/sprint-status.yaml` — Action-Item `code-review-2-1-item-2` (Z. 173–174) + neue AI-2-R-5-Einträge; Status-Nachführung nach Abschluss (je nach Flow). + +## Tasks & Acceptance + +**Execution:** +- [x] `schema/validator.md` -- Header: `Validator-Revision: 8` → `9`, `Letzte Re-Konsistenz` → 2026-08-18 (Revision 9 — Punkt-11-Area-Lesart; Punkt-4-`resolved=`-Token; Innen-Ebenen-Punkt-6-Fixture-Zeile) -- Anker §0. +- [x] `schema/validator.md` -- §3 Punkt-11-Zelle: Area-Lesart formalisieren — „ein Concept ist verlinkt, wenn seine Identität (relativer OKF-Dateipfad ohne `.md`) in der `index.md` des nächsten Vorfahren referenziert ist; für ein Area-Concept genügt die file-relative Referenz in der Area-`index.md`, identitätsstiftend ist das Pärchen (Area-Präfix + Link-Ziel); Root-Concepts wie bisher in der Bundleroot (mit/ohne `.md`-Endung)" -- Kern der Rev-9-Lesart, F-02. +- [x] `schema/validator.md` -- §7.1-Fixture: neue Negativ-Fixture 11a „Area `wiki/wissensarchitektur/` mit `index.md`, das Area-Concept `source-material.md` **nicht** verlinkt → `FAIL … Punkt 11: Concept nicht verlinkt=wissensarchitektur/source-material`" + Positiv-Fall dokumentieren -- prüfbare Negative der Area-Lesart. +- [x] `schema/validator.md` -- §3 Punkt-4-Vorlage: optionales `resolved=`-Token ergänzen (`…unzulaessiger Pfad (..-Traversal|absolut|URL|Backslash|file://|resolved=)`) -- Patch 16/17, Fixture 4a ableitbar machen (§7 „exakt die aus §3"). +- [x] `schema/validator.md` -- §7.3: echte Negativ-Fixture-Zeile für Innen-Ebenen-Punkt-6 („`sources:\n - resource: raw/…\n role: x` → `FAIL … Punkt 6`") -- Patch 16/17, Rev-8-Formalisierung re-runbar belegen. +- [x] `schema/validator.md` -- §8-Revisionslog: Rev-9-Eintrag anhängen (Punkt-11-Area-Lesart, beide Patches, Header-Anhebung; Vertrag unverändert) -- append-only. +- [x] `schema/validator.md` -- §8-Normreferenz-Notiz „Story 2.3 (Link-Form)" um die Rev-9-Area-Lesart ergänzen -- Konsistenz der Lesart mit der Pin-Form-Doktrin. +- [x] `wiki/log.md` -- Zertifizierungs-Eintrag (datumsgruppiert 2026-08-18): Fixture 4a isoliert FAIL Punkt 4, Innen-Ebenen FAIL Punkt 6, Punkt-11-Area-Lesart-Fixtures, reales Bundle weiterhin 7/7 SUCCESS -- mechanischer Beleg gemäß Validator-Zertifizierungs-Kultur (F-02). +- [x] `_bmad-output/implementation-artifacts/sprint-status.yaml` -- Action-Item `code-review-2-1-item-2` + `AI-2-R-5` → `done` (closed + resolution mit Rev-9 + ref auf Rev-9-Runde) -- Tracking-Abschluss. + +**Acceptance Criteria:** +- Given die autorisierte Rev-9-Runde, when `schema/validator.md` geprüft wird, then Header-Revisionszahl ist 9, der §8-Revisionslog trägt den Rev-9-Eintrag (append-only, bestehende Einträge unangetastet), und keine §7-Klasse wurde neu erzeugt (kein Punkt 15). +- Given die Punkt-11-Area-Lesart, when ein Area-Concept file-relativ in seiner Area-`index.md` verlinkt ist (Live: `wissensarchitektur/source-material.md`), then die Bundle-Identität `wissensarchitektur/source-material` ist für Punkt 11 gewahrt (kein FAIL „nicht verlinkt"). +- Given die gehaltenen Patches, when Fixture 4a isoliert gegen den revidierten Validator ausgeführt wird, then das Verdikt ist ableitbar aus der §3-Punkt-4-Vorlage `…(..-Traversal|absolut|URL|Backslash|file://|resolved=README.md)` → `FAIL … Punkt 4 … (resolved=README.md)`. +- Given die gehaltenen Patches, when das Innen-Ebenen-Sample (existierende `raw/`-Datei, `role: x` in `sources`-Eintrag) isoliert geprüft wird, then genau Punkt 6 löst aus (Isolations-Prinzip), mit Fixture-Zeile in §7.3. +- Given das reale Bundle (7 `wiki/`-Dateien), when der revidierte Validator den Run ausführt, then alle 7 Dateien bleiben SUCCESS (keine neu ausgelösten FAILs; Abschluss-Eigenschaft des §7-Katalogs gewahrt). +- Given `schema/wiki-compiler.md` und `schema/compiler.md`, when der Rev-9-Diff inspiziert wird, then beide bleiben unverändert (AD-3/D-3-Freeze; keine Vertrags-Änderung nötig — Punkt 11 deckt die Area-Lesart bereits vertraglich, §7). + +## Spec Change Log + + + +## Design Notes + +**Warum diese Formulierung (Open question 3 der Retro):** Die Lesart „als relativer Bundle-Pfad referenziert (mit oder ohne `.md`-Endung)" wird für Area-Concepts um die **file-relative** Alternative ergänzt: In der zuständigen Area-`index.md` ist die Referenz des Link-Ziels (`source-material.md`) der **lokale** Verweis auf das Area-Concept; die Bundle-Identität ergibt sich deterministisch als Pärchen `(Area-Präfix = Verzeichnisname der Area-`index.md`, Link-Ziel ohne `.md`)`. Das ist exakt die Datei-Topologie von `wiki/wissensarchitektur/index.md` Z. 9. Root-Concepts (gepinnte §5.6-Form, mit `.md`-Endung) bleiben unverändert — die „genau-eine-Form"-Festlegung der Link-Schreibweise liegt weiterhin bei Story 2.3/§5.6 der Compiler-Instruktion (dem Validator wird sie nicht vorgegeben). + +**Gehaltene Patches als formale Inhalte:** Beide Patches (16/17) sind bereits inhaltlich spezifiziert (deferred-work.md Z. 188–189: Punkt-4-`resolved=`-Token, Innen-Ebenen-Punkt-6-Fixture-Zeile). Sie werden durch diese Autorisierung von „gehalten (kein Autorisierungsschlag)" zu „formal getragene autorisierte Inhalte" — gleiche Währung wie die Rev-8-Autorisationsrunde (F-14-Fixture 4a). + +## Verification + +**Commands:** +- `grep -nE "Validator-Revision|Revision 9" schema/validator.md` -- expected: Header-Revisionszahl `9` UND Revisionslog-Entrag Rev 9 vorhanden. +- `exit 0` für die mechanischen Fixture-Runs (isolierte Samples + Live-Bundle) gemäß Zertifizierungs-Sektion der Rev-9-Runde. +- `git diff --name-only ..HEAD -- schema/wiki-compiler.md schema/compiler.md raw/ adapters/` -- expected: **keine** Treffer (AD-3/D-3-Freeze gewahrt). + +**Manual checks (if no CLI):** +- §7.1-Fixture 11a-Erwartungswert (`FAIL … Concept nicht verlinkt=wissensarchitektur/source-material`) mit der §3-Punkt-11-Zelle (Area-Lesart) abgeglichen → bildet die Ableitung ab. +- Fixture-4a-Verdikt (`(resolved=README.md)`) ist aus der §3-Punkt-4-Vorlage ableitbar (kein Inventieren). +- `wiki/log.md` trägt den Rev-9-Zertifizierungs-Eintrag (datumsgruppiert 2026-08-18); `sprint-status.yaml`-Action-Items sind `done` geschlossen. + +## Suggested Review Order + +**Area-Lesart (Punkt 11) — Kern der Revision** + +- Einstieg: die formalisierte Area-Lesart — Pärchen (Area-Präfix + Link-Ziel) identitätsstiftend, file-relativ genügt + [`validator.md:70`](../../schema/validator.md#L70) + +- Die Normreferenz-Notiz führt die Story-2.3-Formklausel um die Pin-Form-Doktrin nach + [`validator.md:304`](../../schema/validator.md#L304) + +- Negativ-Fixture 11a am realen Live-Area-Namen (F-02-Defekt belegt, Isolations-Prinzip) + [`validator.md:226`](../../schema/validator.md#L226) + +- Positiv-Gegenfall: file-relativer `](source-material.md)`-Link genügt → SUCCESS + [`validator.md:256`](../../schema/validator.md#L256) + +**resolved=-Token (Punkt 4)** + +- Fehlerursachen-Grammatik um das optionale `resolved=`-Token erweitert (Patch 16) + [`validator.md:63`](../../schema/validator.md#L63) + +- Semantik-Anker: Token feuert nur bei Ablehnung durch aufgelöste Lage außerhalb `raw/` + [`validator.md:182`](../../schema/validator.md#L182) + +- Fixture 4/4a — 4a verdikt-ableitbar aus der §3-Vorlage + [`validator.md:216`](../../schema/validator.md#L216) + +**Innen-Ebenen-Punkt-6-Fixtures** + +- §7.3-Überschrift trägt die Innen-Ebenen-Punkt-6-Fixtures explizit (Patch 17) + [`validator.md:265`](../../schema/validator.md#L265) + +- Negativ-Zeile `role: x` → genau Punkt 6 (Isolations-Prinzip) + [`validator.md:281`](../../schema/validator.md#L281) + +- Positiv-Gegenzeile: nur erlaubte Keys → SUCCESS + [`validator.md:282`](../../schema/validator.md#L282) + +**Konsistenz & Peripherals** + +- Header: Revisionszahl 9 + Re-Konsistenz-Nachführung + [`validator.md:7`](../../schema/validator.md#L7) + +- Revisionslog-Rev-9-Eintrag (append-only, „fünf inhaltliche Änderungen", kein Punkt 15) + [`validator.md:316`](../../schema/validator.md#L316) + +- Mechanischer Zertifizierungs-Nachweis inkl. Live-Invariant (2026-08-18) + [`log.md:4`](../../wiki/log.md#L4) + +- Tracking-Abschluss der Items `code-review-2-1-item-2` + `epic-2-retro-item-14` + [`sprint-status.yaml:170`](sprint-status.yaml#L170) diff --git a/_bmad-output/implementation-artifacts/sprint-status.yaml b/_bmad-output/implementation-artifacts/sprint-status.yaml index c61114f..8071ce3 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-18-2026 21:15 +last_updated: 08-18-2026 22:00 project: wow20 project_key: NOKEY tracking_system: file-system @@ -175,7 +175,19 @@ action_items: in §7.1/§7.3 ergänzen (Rev-8-Formalisierung re-runbar belegen). Danach Zertifizierung (isolierte Fixtures + reales Bundle) und `wiki/log.md`-Nachweis." owner: "dev" - status: in-progress + status: done + closed: "2026-08-18" + resolution: "Ausgefuehrt als Teil der autorisierten Validator-Rev-9: die zwei gehaltenen + Patches 16/17 umgesetzt — §3-Punkt-4-Vorlage um resolved=-Token ergaenzt + (inkl. §6.2-Semantik: nur bei Ablehnung durch aufgeloeste Lage ausserhalb raw/, + Wert = aufgeloester workspace-relativer Pfad; Fixture 4a -> FAIL Punkt 4 (resolved=README.md), + ableitbar), Innen-Ebenen-Punkt-6-Negativ- UND Positiv-Fixture-Zeilen in §7.3 + ergaenzt (role: x -> FAIL Punkt 6, Isolations-Prinzip). Scope: zusaetzlich die + de-duplizierte Punkt-11-Area-Lesart aus AI-2-R-5 (eingefrorener Intent, epic-2-retro-item-14 + = eigener action_item done-Eintrag mit eigener resolution + ref auf die Rev-9-Runde); + dieses Item deckt die zwei gehaltenen Patches, item-14 die Punkt-11-Area-Lesart. + Zertifizierung (isolierte Fixtures + reales Bundle 7/7 SUCCESS) und wiki/log.md-Nachweis + erfolgt (inkl. Freeze-Command + Live-Invariant)." ref: "_bmad-output/implementation-artifacts/deferred-work.md" - id: "epic-2-retro-item-10-schema-compiler-md-5-5-selbsttest-formel" epic: 2 @@ -210,5 +222,12 @@ action_items: action: "Autorisierte Validator-Rev-9 für Punkt-11-Area-Lesart (relative OKF-Pfad-Identität, file-relativ in Area-Index); de-dupliziert mit code-review-2-1-item-2; F-02/AI-2-R-5" owner: "dev" - status: open + status: done + closed: "2026-08-18" + resolution: "Autorisierte Validator-Rev-9 ausgefuehrt und zertifiziert: Punkt-11-Area-Lesart + formalisiert (file-relative Referenz in Area-index.md genuegt, Paerchen Area-Praefix + + Link-Ziel identitaetsstiftend; Live: wissensarchitektur/source-material ueber + ](source-material.md)); Bereichs-Index wahren die Bundle-Identitaet ohne textuelle + Nennung. §7-Fixtures 11a (Negativ/Positiv), Revisionslog 9, Header 9, wiki/log.md-Nachweis + (7/7 SUCCESS) erbracht. Quelle: spec-autorisierte-validator-revision-9-punkt-11-area-lesart.md" ref: "_bmad-output/implementation-artifacts/epic-2-retro-2026-08-18.md" diff --git a/schema/validator.md b/schema/validator.md index 6985e50..56a243e 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:** 8 (Revisionslog in §8) +> **Validator-Revision:** 9 (Revisionslog in §8) > **Ableitungsdatum:** 2026-08-15 -> **Letzte Re-Konsistenz:** 2026-08-16 (Revision 8 — F-14-Fixture + Innen-Ebenen-Key-Subset formalisiert; Option-A-Heilung Story 2.1) +> **Letzte Re-Konsistenz:** 2026-08-18 (Revision 9 — Punkt-11-Area-Lesart; Punkt-4-`resolved=`-Token; Innen-Ebenen-Punkt-6-Fixture-Zeile) ## 0. Zweck & Aufruf @@ -60,14 +60,14 @@ Wert-Semantik des YAML-Checks: Frontmatter ist als YAML zu parsen. Wiederholte F | 1 | Concept ohne `type` oder mit leerem `type` | Concept-Frontmatter | Ist `type` nicht vorhanden ODER kein non-empty String (leerer String, nur Whitespace, oder `type: null` / Zahl / Datumsobjekt)? | `Punkt 1: concept ohne type oder leerer type (NULL|leer|nicht-String)` | | 2 | nicht-reservierte `.md`-Datei im Bundle ohne Frontmatter bzw. ohne `type` | jede nicht-`index.md`/nicht-`log.md` `.md`-Datei unter `wiki/` | Fehlt der Frontmatter-Block `---` (Erkennung auf dem gestrippten Dateianfang, §3-Präambel) ODER ist das Frontmatter nicht als YAML parsbar ODER fehlt `type` (bzw. ist leer)? | `Punkt 2: nicht-reservierte .md-Datei ohne Frontmatter/ohne type` | | 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://)` | +| 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://|resolved=)` | | 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). 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=)` | | 10 | Frontmatter in einer Area-`index.md` oder `log.md` | Area-`index.md`, `wiki/log.md` | Beginnt die Datei — auf dem gestrippten Dateianfang (BOM `U+FEFF` + führende Leerzeilen, gemeinsame Definition §3-Präambel) — mit einem YAML-Frontmatter-Block `---`? Ein BOM bzw. führende Leerzeilen vor dem Frontmatter ändern den Status nicht (sonst würde ein Frontmatter der Erkennung entkommen). | `Punkt 10: Frontmatter in Area-index.md/log.md (Datei=)` | -| 11 | Verletzung der Index-Regel | `wiki/`-Struktur | Hat ein Area-Verzeichnis (jedes Verzeichnis unter `wiki/` mit Inhalt) keine `index.md`? ODER ist ein Concept nicht in der `index.md` seines nächsten Vorfahren verlinkt — ein Concept ist verlinkt, wenn seine Identität (relativer OKF-Dateipfad ohne `.md`) in der `index.md` des nächsten Vorfahren (Area-`index.md`; für Root-Concepts die Bundleroot `wiki/index.md`) als relativer Bundle-Pfad referenziert ist, **mit oder ohne `.md`-Endung** (eine genau-eine-Form-Festlegung ist Story 2.3 und wird hier nicht vorgegeben). „Neues Concept" ist deterministisch: jede im Bundle vorhandene Concept-Datei, deren Identität in ihrer zuständigen `index.md` fehlt — der Validator prüft den Zustand, nicht ein Git-Diff. | `Punkt 11: Index-Regel verletzt (Area ohne index.md= | Concept nicht verlinkt=)` | +| 11 | Verletzung der Index-Regel | `wiki/`-Struktur | Hat ein Area-Verzeichnis (jedes Verzeichnis unter `wiki/` mit Inhalt) keine `index.md`? ODER ist ein Concept nicht in der `index.md` seines nächsten Vorfahren verlinkt — ein Concept ist verlinkt, wenn seine Identität (relativer OKF-Dateipfad ohne `.md`) in der `index.md` des nächsten Vorfahren (Area-`index.md`; für Root-Concepts die Bundleroot `wiki/index.md`) als relativer Bundle-Pfad referenziert ist, **mit oder ohne `.md`-Endung** (eine genau-eine-Form-Festlegung ist Story 2.3 und wird hier nicht vorgegeben). **Area-Lesart (autorisiert, Revision 9):** Für ein Area-Concept genügt die **file-relative** Referenz in der Area-`index.md` des nächsten Vorfahren — identitätsstiftend ist das Pärchen (Area-Präfix = **bundle-relativer Verzeichnispfad** der Area-`index.md` + Link-Ziel), eine textuelle Nennung der Bundle-Identität in der Area-`index.md` ist dafür nicht erforderlich. Der Area-Präfix ist der Verzeichnispfad der Area-`index.md` relativ zur Bundleroot (z. B. für `wiki/wissensarchitektur/index.md` → `wissensarchitektur/`), nicht nur der Leaf-Verzeichnisname — robust auch für Area-Tiefe ≥ 2 (die Zwei-Ebenen-Beschränkung ist Gegenstand der Compiler-Instruktion §5.8; der Validator delegiert die Struktur-Zulässigkeit dorthin und bildet die Identität rein aus Area-Präfix + Link-Ziel). **Normalisierung des Link-Ziels vor der Identitätsbildung:** Ein führendes `.`/`./`-Segment wird gestrippt; `..`-Segmente gehören nicht zur gepinnten Ein-Ebenen-Form (file-relative Referenzen in der Area-`index.md` sind Ein-Ebenen-Links auf Concepts desselben Verzeichnisses; `..`-Aufwärts-Ziele sind keine Area-Concept-Referenzen im Sinne dieser Regel). **Identität ohne `.md`-Endung (AD-7a):** Die `.md`-Endung des Link-Ziels wird für die Identitätsbildung **abgestreift** — das Beispiel `source-material` (aus `](source-material.md)`) ergibt mit dem Area-Präfix `wissensarchitektur/` eindeutig die Bundle-Identität `wissensarchitektur/source-material`. Root-Concepts bleiben wie bisher in der Bundleroot referenziert (mit oder ohne `.md`-Endung). „Neues Concept" ist deterministisch: jede im Bundle vorhandene Concept-Datei, deren Identität in ihrer zuständigen `index.md` fehlt — der Validator prüft den Zustand, nicht ein Git-Diff. | `Punkt 11: Index-Regel verletzt (Area ohne index.md= | Concept nicht verlinkt=)` | | 12 | `sources`/`verified` in nicht erlaubter Form; `generated` in Listen- statt Map-Form; `sources`-Eintrag ohne Pflichtangabe `resource` | Concept-Frontmatter | Ist `sources` gesetzt und **nicht** YAML-Liste? Ist ein `sources`-Eintrag keine Map (z. B. Skalar)? Ist ein `sources`-Eintrag eine Map **ohne** `resource` oder mit leerem `resource` (Vertrag §3.3: `resource` ist die einzige Pflichtangabe je Eintrag)? Ist `verified` gesetzt und **weder** Liste **noch** eine einzelne Map? Ist ein `verified`-Eintrag keine Map? Ist `generated` gesetzt und **nicht** eine Map (insbesondere Liste)? | `Punkt 12: sources/verified/generated in nicht erlaubter Form` | | 13 | doppelter Frontmatter-Key | jede Datei mit Frontmatter (Concept, Bundleroot) | Kommt derselbe Key auf oberster Frontmatter-Ebene mehrfach vor (z. B. doppeltes `type`, doppeltes `okf_version`, doppeltes `sources`)? | `Punkt 13: doppelter Frontmatter-Key (Key=)` | | 14 | fehlerhafte Wert-Formate | Concept-Frontmatter | `stale_after`/`last_modified` ≠ `YYYY-MM-DD` (exakt 10 Zeichen, korrekte Struktur + reale Kalenderdaten, §6.3)? `at` (in `generated`/`verified`) ≠ ISO-8601-Datetime (Normalform, §4.3; Kalender-Validität §6.3)? `usage_count` kein **YAML-Integer** (Ganzzahl-Typ, nicht Zahl allgemein — `usage_count: 3.0` als Float ist ein FAIL) und keine Ganzzahl ≥ 0? `type` kein nicht-leerer String (siehe auch Punkt 1)? | `Punkt 14: fehlerhaftes Wert-Format (Feld=, Wert=)` | @@ -179,6 +179,8 @@ Die folgenden Prüfungen sind **fachliche** Prüfungen (keine §7-Invaliditäts- 5. Der bereinigte Pfad muss auf einen Pfad **innerhalb** `raw/` auflösen (Präfix `raw/` in der aufgelösten Form). Andernfalls Punkt 4. 6. Der aufgelöste Pfad darf **nicht** auf einen Pfad innerhalb `wiki/` auflösen (Punkt 3). +**Semantik des `resolved=`-Tokens (Autorisations-Runde, Revision 9):** Das optionale `resolved=`-Suffix der Punkt-4-Fehlerursache (§3 Punkt 4, Vorlage `…|file://|resolved=`) wird nur dann ergänzt, wenn die Ablehnung durch die **aufgelöste Lage** des Pfads erfolgt (Schritt 5: außerhalb `raw/`), **nicht** durch einen der Grammatik-Schritte 1–4 (`..`-Segment, führendes `/`, Backslash/Windows-Trenner, `file://`/URL). Der Wert ist der aufgelöste, workspace-relative Pfad des `resource`-Werts (Beispiel Fixture 4a: `resource: README.md` an der Workspace-Root → `resolved=README.md`). Erfolgt die Ablehnung über einen der Grammatik-Schritte 1–4, bleibt der Katalog auf die entsprechenden Token beschränkt und trägt **kein** `resolved=`-Suffix (die Punktnummer ist je Input deterministisch, §6.2 Vorrangsregel). Konsistenz mit §5-Verdikt-Grammatik: Das `resolved=`-Token ist Bestandteil der textuellen Fehlerursache („Punkt-Nummer + deterministischer Grund + relevanter Wert/Pfad", §5 FAIL) — es ersetzt weder Verdikt-Verb noch Pfad und erzeugt keine eigene Prüfklasse. + ### 6.3 Kalender-Validität der Datumsfelder (EC-3) Für alle `YYYY-MM-DD`-Felder (`stale_after`, `sources[].last_modified`) gilt: @@ -210,7 +212,7 @@ Die folgenden Tabellen belegen die 1:1-Abbildung der 14 Punkte (§7.1/§7.2) **s | 1 | Concept `x.md` mit `type:` (leer) | `FAIL wiki/x.md Punkt 1: concept ohne type oder leerer type (NULL|leer|nicht-String)` | | 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://)` | +| 4 | `sources: [{resource: ../outside.md}]` | `FAIL wiki/x.md Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (..-Traversal\|absolut\|URL\|Backslash\|file://\|resolved=)` | | 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)` | @@ -221,6 +223,7 @@ Die folgenden Tabellen belegen die 1:1-Abbildung der 14 Punkte (§7.1/§7.2) **s | 10 | `wiki/log.md` beginnt mit `---` | `FAIL wiki/log.md Punkt 10: Frontmatter in Area-index.md/log.md (Datei=wiki/log.md)` | | 10a | `wiki//log.md` existiert (reservierter Name außerhalb der Bundleroot) | `FAIL wiki//log.md log.md an unzulässiger Position (V-2, reservierter Name, nur Bundleroot, Vertrag §5)` | | 11 | Area `wiki/foo/` ohne `index.md` | `FAIL wiki/foo/ Punkt 11: Index-Regel verletzt (Area ohne index.md=foo)` | +| 11a | Area `wiki/wissensarchitektur/` mit `index.md`, das Area-Concept `source-material.md` **nicht** verlinkt (file-relative Referenz fehlt; der Live-Area-Name wird bewusst genutzt, weil die Fixture den F-02-Defekt am realen Bundle belegt; die übrigen Links der Area werden als valide angenommen — restliche Konzepte verlinkt, Isolations-Prinzip §7.1) | `FAIL wiki/wissensarchitektur/source-material.md Punkt 11: Index-Regel verletzt (Concept nicht verlinkt=wissensarchitektur/source-material)` | | 12 | `sources: {resource: raw/x.md}` (Map statt Liste) | `FAIL wiki/x.md Punkt 12: sources/verified/generated in nicht erlaubter Form` | | 12a | `sources: [{title: \"Ohne resource\"}]` (Eintrag ohne Pflichtangabe `resource`) | `FAIL wiki/x.md Punkt 12: sources/verified/generated in nicht erlaubter Form` | | 13 | Frontmatter mit zweimal `type:` | `FAIL wiki/x.md Punkt 13: doppelter Frontmatter-Key (Key=type)` | @@ -250,6 +253,7 @@ Zusätzlich gilt der A0-2/AD-1b-Grundsatz der abgeschlossenen Liste: Ein Concept | 10 | `wiki/log.md` und Area-`index.md` ohne Frontmatter | `SUCCESS wiki/log.md` / `SUCCESS wiki//index.md` | | 10a | Kein `log.md` außerhalb der Bundleroot (kein `wiki//log.md`) | `SUCCESS` (Voraussetzung V-2 nicht verletzt) | | 11 | Area `wiki/foo/` mit `index.md`, das neue Concept verlinkt | `SUCCESS` (Punkt 11 nicht verletzt) | +| 11a | Area `wiki/wissensarchitektur/` mit `index.md`, das Area-Concept `source-material.md` file-relativ verlinkt (`](source-material.md)`) | `SUCCESS` (Punkt 11 nicht verletzt) | | 12 | `sources` Liste von Maps, je Eintrag mit `resource`; `verified: {by: human:x, at: ...}` (Singleton-Map) | `SUCCESS wiki/x.md` (Singleton-Coercing, §4.2) | | 12a | `sources: [{resource: raw/x.md, title: t}]` (Eintrag mit Pflichtangabe `resource`) | `SUCCESS wiki/x.md` | | 13 | Frontmatter ohne doppelte Keys | `SUCCESS wiki/x.md` | @@ -258,9 +262,9 @@ Zusätzlich gilt der A0-2/AD-1b-Grundsatz der abgeschlossenen Liste: Ein Concept | 14c | `at: 2026-08-15T10:00:00+0200` (Offset 4-stellig ohne Doppelpunkt, gültiges ISO-8601/RFC 3339) | `SUCCESS wiki/x.md` (Normalform §4.3) | | 14d | `usage_count: 3` (YAML-Integer) | `SUCCESS wiki/x.md` | -### 7.3 §6-Fachliche-Zusatzprüfungen-Fixtures (EC-1, EC-3, WARN, EC-11) +### 7.3 §6-Fachliche-Zusatzprüfungen-Fixtures (EC-1, EC-3, WARN, EC-11) & Innen-Ebenen-Punkt-6-Fixtures -> Diese Prüfungen sind keine §7-Punkte (Fachliche Prüfungen, §6). Für Negativ-Fixtures gilt dasselbe Isolations-Prinzip wie in §7.1: jedes Sample ist sonst-valide (die 14 Punkte passieren), sodass genau die jeweilige §6-Prüfung auslöst. Das Isolations-Prinzip gilt entsprechend auch für Punkt-6-Fälle auf Innen-Ebenen (`sources`/`generated`/`verified`-Einträge): Ein unautorisierter Key innerhalb eines Eintrags (z. B. `sources:\n - resource: …\n role: x`) ist strukturell invalide und löst Punkt 6 aus (vertraglich §3.3–§3.5), losgelöst von der §6-Formprüfung. +> Diese Prüfungen sind keine §7-Punkte (Fachliche Prüfungen, §6). Für Negativ-Fixtures gilt dasselbe Isolations-Prinzip wie in §7.1: jedes Sample ist sonst-valide (die 14 Punkte passieren), sodass genau die jeweilige §6-Prüfung auslöst. Das Isolations-Prinzip gilt entsprechend auch für die hier aufgeführten Punkt-6-Fälle auf Innen-Ebenen (`sources`/`generated`/`verified`-Einträge): Ein unautorisierter Key innerhalb eines Eintrags (Negativ-Zeile: `sources:\n - resource: …\n role: x` → genau Punkt 6 löst aus, losgelöst von der §6-Formprüfung; vertraglich §3.3–§3.5), ein Eintrag mit ausschließlich erlaubten Keys (Positiv-Zeile) passiert alle Punkte. Die Verdikt-Zellen tragen den reinen, maschinenlesbaren Fehlerursachen-String gemäß §3 (kein erklärender Zusatz in der Zelle). | # | Fixture (Input) | Erwartetes Verdikt | |---|-----------------|--------------------| @@ -274,6 +278,8 @@ Zusätzlich gilt der A0-2/AD-1b-Grundsatz der abgeschlossenen Liste: Ein Concept | §6.4 WARN Positiv (nicht veraltet) | `stale_after: 2026-12-31` mit `today` (UTC) = 2026-08-16 → nicht veraltet | `SUCCESS wiki/x.md` (keine WARN) | | §6.5 EC-11 Positiv | `wiki//logo.png` (nicht-`.md` unter `wiki/`) vorhanden | kein Verdikt für `logo.png` (wird ignoriert, §1/§6.5); valide `.md`-Dateien unverändert SUCCESS | | §6.5 EC-11 Konvention | Verzeichnis `wiki//` enthält nur `logo.png` + `index.md` | `SUCCESS wiki//index.md` (logo.png ignoriert) | +| Innen-Ebenen Punkt 6 Negativ | `sources:\n - resource: raw/prd/prd-wow20-2026-08-14.md\n role: x` (existierende `raw/`-Datei, unautorisierter Key `role:` in `sources`-Eintrag) | `FAIL wiki/x.md Punkt 6: nicht autorisiertes Feld (Key=role) bzw. unautorisierter Key in sources/generated/verified` | +| Innen-Ebenen Punkt 6 Positiv | `sources`-Eintrag mit `resource` und ausschließlich erlaubten Keys (kein `role`) | `SUCCESS wiki/x.md` (kein Punkt 6) | | §3.2 V-1 Negativ | `wiki/index.md` existiert **nicht** (Bundle ohne Bundleroot) | `FAIL (Voraussetzung) Bundleroot fehlt: wiki/index.md existiert nicht (V-1, Vertrag §2, Vorausbedingung zu Punkt 8)` | | §3.2 V-1 Positiv | `wiki/index.md` ist vorhanden | `SUCCESS` (Voraussetzung V-1 nicht verletzt) | | §3.2 V-2 Negativ | `wiki//log.md` existiert (reservierter Name außerhalb der Bundleroot) | `FAIL wiki//log.md log.md an unzulässiger Position (V-2, reservierter Name, nur Bundleroot, Vertrag §5)` | @@ -295,6 +301,7 @@ Zusätzlich gilt der A0-2/AD-1b-Grundsatz der abgeschlossenen Liste: Ein Concept - Deferred-Work `_bmad-output/implementation-artifacts/deferred-work.md` — EC-1, EC-3, BH-14, F2-Listen, BH-8, EC-11, F17-`log.md`, F18-`stale_after` (8 an Story 1.4 verwiesene Entscheidungen, in §4/§6 deterministisch festgelegt). - **F15 (Trust-Semantik von `generated.by`):** `generated.by: human:` ist formgültig — das Datenmodell erlaubt jeden non-empty `by` (Vertrag §3.4) —, begründet aber **keine** human-review-Klassifikation (die entsteht nur über `verified` mit `human:`-Präfix, §3.5). Die Trust-Semantik von `generated.by` mit `human:`-Präfix wird in Epic 4 geklärt (Deferred-Work F15). - **Story 2.3 (Link-Form):** Der Punkt-11-Check akzeptiert die Concept-Identität in der zuständigen `index.md` mit oder ohne `.md`-Endung (§3 Punkt 11). Eine genau-eine-Form-Festlegung der Link-Schreibweise ist Story 2.3 und wird hier bewusst nicht vorweggenommen. +- **Revision 9 — Punkt-11-Area-Lesart (autorisiert, 2026-08-18):** Ergänzt die Story-2.3-Formklausel um die konsistente Nachführung der Pin-Form-Doktrin: Für ein **Area-Concept** genügt die file-relative Referenz in der Area-`index.md` des nächsten Vorfahren (Pärchen Area-Präfix + Link-Ziel identitätsstiftend); Root-Concepts bleiben wie bisher (mit oder ohne `.md`-Endung) in der Bundleroot referenziert. Dies ist die formale Vereinheitlichung der Story-2.3-Notiz mit der von Story 2.4/2.5 genutzten file-relativen Area-Linkform (`compiler.md` §5.6/§5.7) — no new §7-Klasse, die abschließende 14-Punkte-Liste bleibt unangetastet (Vertrag §7). **Revisionslog:** @@ -306,3 +313,4 @@ Zusätzlich gilt der A0-2/AD-1b-Grundsatz der abgeschlossenen Liste: Ein Concept - **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). +- **Revision 9 (2026-08-18, Autorisations-Runde):** Epic-2-F-02/AI-2-R-5 (de-dupliziert mit `code-review-2-1-item-2`) — fünf inhaltliche Änderungen, keine neue §7-Klasse (kein Punkt 15; Abschluss-Eigenschaft des §7-Katalogs gewahrt), `schema/wiki-compiler.md` (Vertrag) und `schema/compiler.md` (Instruktion) unverändert (AD-3/D-3): (1) **Punkt-11-Area-Lesart formalisiert** (§3 Punkt-11-Zelle, Kern der Rev-9-Lesart, Retrospective F-02/Open question 3): Für ein Area-Concept genügt die **file-relative** Referenz in der `index.md` des nächsten Vorfahren (Area-`index.md`); identitätsstiftend ist das **Pärchen (Area-Präfix = bundle-relativer Verzeichnispfad der Area-`index.md` + Link-Ziel ohne `.md`-Endung, AD-7a)**, eine textuelle Nennung der Bundle-Identität in der Area-`index.md` ist nicht erforderlich (Live: `wiki/wissensarchitektur/source-material.md` → Identität `wissensarchitektur/source-material` über `](source-material.md)` in der Area-`index.md`); Normalisierung des Link-Ziels (`.`/`./`-Strip; `..` nicht Teil der gepinnten Ein-Ebenen-Form) und `.md`-Endungs-Strip für die Identitätsbildung explizit verankert. Root-Concepts bleiben wie bisher in der Bundleroot referenziert (mit oder ohne `.md`-Endung — eine genau-eine-Form-Festlegung liegt bei Story 2.3/§5.6 der Compiler-Instruktion, der Validator gibt sie nicht vor). (2) **Punkt-4-Fehlerursachen-Grammatik um `resolved=`-Token ergänzt + Semantik verankert** (§3 Punkt-4-Zelle: `…|resolved=`; §6.2: Token feuert nur bei Ablehnung durch aufgelöste Lage außerhalb `raw/`, Wert = aufgelöster workspace-relativer Pfad; Konsistenz mit §5-Verdikt-Grammatik) — Patch 16 (gehalten, deferred-work.md), macht Fixture 4a (§7.1: `resolved=README.md`) ableitbar. (3) **Innen-Ebenen-Punkt-6-Fixtures ergänzt** (§7.3: Negativ-Zeile `sources`-Eintrag mit `role: x` bei existierender `raw/`-Datei → `FAIL … Punkt 6`; Positiv-Gegenzeile ausschließlich erlaubte Keys → SUCCESS) — Patch 17 (gehalten), belegt die Rev-8-Formalisierung der Innen-Ebenen-Regel re-runbar. (4) **§7-Fixtures 11a** (Negativ: Area-Concept nicht verlinkt → `FAIL … Concept nicht verlinkt=wissensarchitektur/source-material`; Positiv: file-relativ verlinkt → SUCCESS) ergänzt — prüfbare Negative der Area-Lesart am realen Live-Area-Namen. (5) **§8-Normreferenz-Notiz „Story 2.3 (Link-Form)" um die Rev-9-Area-Lesart ergänzt** (Konsistenz der Lesart mit der Pin-Form-Doktrin). Nachgeführt: Header-Revisionszahl auf „Revision 9" angehoben + Revisionslog-Eintrag (append-only, bestehende Einträge unangetastet). Zertifizierung in `wiki/log.md` (2026-08-18) nachgeführt: Fixture 4a isoliert → FAIL Punkt 4 (`resolved=README.md`); Innen-Ebenen-Sample → FAIL Punkt 6 (`Key=role`); Punkt-11-Area-Fixtures (11a Negativ/Positiv) → FAIL bzw. SUCCESS; reales Bundle (7 `wiki/`-Dateien) → weiterhin SUCCESS. Vertrag unverändert (Punkt 11 deckt die Area-Lesart bereits vertraglich, §7). diff --git a/wiki/log.md b/wiki/log.md index 744f088..87cac27 100644 --- a/wiki/log.md +++ b/wiki/log.md @@ -1,6 +1,7 @@ # Log ## 2026-08-18 +- **Validierungs-Revision 9 (autorisiert; Epic-2-Retro F-02/AI-2-R-5, de-dupliziert mit `code-review-2-1-item-2`; ausgeführt 2026-08-18, Quelle: `_bmad-output/implementation-artifacts/spec-autorisierte-validator-revision-9-punkt-11-area-lesart.md`):** `schema/validator.md` → **Revision 9**. Fünf inhaltliche Änderungen, keine neue §7-Klasse (kein Punkt 15; Vertrag `schema/wiki-compiler.md` + Instruktion `schema/compiler.md` + `raw/` + `adapters/` + alle `wiki/`-Concept-Dateien unverändert, AD-3/D-3): (1) **Punkt-11-Area-Lesart formalisiert** (§3 Zelle: Für ein Area-Concept genügt die file-relative Referenz in der Area-`index.md` des nächsten Vorfahren; identitätsstiftend ist das Pärchen Area-Präfix (= bundle-relativer Verzeichnispfad der Area-`index.md`) + Link-Ziel ohne `.md`-Endung (AD-7a), textuelle Nennung der Bundle-Identität entfällt — Live: `wissensarchitektur/source-material` über `](source-material.md)` in `wiki/wissensarchitektur/index.md`; Normalisierung: `.`/`./`-Strip, `..` nicht Teil der Ein-Ebenen-Form); (2) **Punkt-4-Vorlage um `resolved=`-Token ergänzt + Semantik verankert** (`…|file://|resolved=`; §6.2: nur bei Ablehnung durch aufgelöste Lage außerhalb `raw/`, Wert = aufgelöster workspace-relativer Pfad) — Fixture 4a ableitbar; (3) **Innen-Ebenen-Punkt-6-Fixtures in §7.3** (Negativ: `role: x` in `sources`-Eintrag → FAIL Punkt 6; Positiv-Gegenzeile ausschließlich erlaubte Keys → SUCCESS); (4) **§7-Fixtures 11a** (Negativ: Area-Concept unverlinkt → `Concept nicht verlinkt=wissensarchitektur/source-material` am realen Live-Area-Namen; Positiv: file-relativ verlinkt → SUCCESS); (5) §8-Normreferenz-Notiz „Story 2.3 (Link-Form)" um die Rev-9-Area-Lesart ergänzt. Nachgeführt: Header auf „Revision 9" + Revisionslog-Eintrag Revision 9 (append-only, bestehende Einträge unangetastet). **Zertifizierung (mechanisch, D-3):** (a) Fixture 4a isoliert — Sample `sources: [{resource: README.md}]` mit existierender `README.md` an der Workspace-Root → `FAIL … Punkt 4: resource ausserhalb raw/ oder unzulaessiger Pfad (…|resolved=README.md)`, kein Vorab-FAIL durch Punkt 3/andere Punkte (Punkt-4-vor-3-Priorität §6.2); (b) Innen-Ebenen-Sample isoliert — `sources:\n - resource: raw/prd/prd-wow20-2026-08-14.md\n role: x` (Datei existiert, sonst-valides Sample) → genau `Punkt 6: nicht autorisiertes Feld (Key=role) bzw. unautorisierter Key in sources/generated/verified`, kein anderer Punkt (Isolations-Prinzip §7.3); (c) Punkt-11-Area-Lesart-Fixtures — Negativ 11a (Area-`index.md` verlinkt `source-material.md` **nicht**) → `FAIL … Punkt 11: Index-Regel verletzt (Concept nicht verlinkt=wissensarchitektur/source-material)`; Positiv 11a (file-relativer `](source-material.md)`-Link, Live-Lage) → SUCCESS (kein „nicht verlinkt"-FAIL); (d) **reales Bundle gegen den revidierten Validator (human-mechanisch ausgeführte Text-Instruktion)** — alle **7** `wiki/`-Dateien weiterhin **SUCCESS** (Punkte 1/2/6/7/8/9/10/11/12/13/14, EC-1; Punkt 11 inkl. Area-Lesart), identisch zur Story-2.4/2.5-Lage — keine neu ausgelösten FAILs, Abschluss-Eigenschaft des §7-Katalogs gewahrt. **Mechanische Belege (ausgeführt 2026-08-18):** (e) AD-3/D-3-Freeze — `git diff --name-only ..HEAD -- schema/wiki-compiler.md schema/compiler.md raw/ adapters/` → **0 Treffer** (keine dieser Dateien geändert); (f) Live-Invariant der 7/7-SUCCESS-Behauptung — `grep -qF '](source-material.md)' wiki/wissensarchitektur/index.md` → **exit 0** (Area-Lesart lebend verankert). `sprint-status.yaml`: `code-review-2-1-item-2` und `epic-2-retro-item-14-…` (AI-2-R-5) → `done` (closed 2026-08-18, resolution mit Rev-9 + ref auf die Rev-9-Runde). - **Story 2.5 «Progressive Discovery über `index.md` bereitstellen» (Implementierung, inkl. Review-Loop-1-Korrektur + Review-Loop-3-Patches, bmad-code-review 2026-08-18, 4 Layer; Nutzer-Entscheidungen 1/1):** `schema/compiler.md` → **Revision 2.3** (neue §5.8 „Progressive Discovery über `index.md` (Story 2.5)"): (1) **Discovery-Pfad** — Bundleroot `wiki/index.md` → Area-`index.md` (frontmatterlos) → Area-Concepts in gepinnter §5.6-Form; Root-Concepts direkt aus der Bundleroot (AD-9, FR-11; gewurzelte Erreichbarkeit Root → Area → Concept, §5.7 Pkt. 5); (2) **gewurzelte Erreichbarkeit als deterministisches Discovery-Kriterium + re-executierbarer Selbsttest** (`UNREACHABLE AREA: ` für von der Bundleroot unverlinkte Area — AD-9; `NESTED AREA: ` für Zwei-Ebenen-Kandidaten, geprüft über **zwei Läufe** der Selbsttest-Formel: (A) Ein-Ebenen-Area-`index.md` → Root-Verlinkungsstatus, (B) `find wiki -mindepth 3 -type f -name "*.md"` → jede Datei in Tiefe ≥ 3 ist ein Zwei-Ebenen-Kandidat, Meldung je Verletzung genau eine; beide Läufe ohne Ausgabe = Discovery-SUCCESS; Instruktions-Selbsttest, schließt die Validator-Navigation-Lücke ohne Validator-Change — kein neuer §7-Punkt, AD-3); (3) **konsolidierte Zwei-Ebenen-Kartografie** (antwortet und schließt **Defer F-07**): Root + eine Area-Ebene; `wiki/a/b/` ist **keine zugelassene Anlageform** — `wiki/a/b/concept.md`-Kandidat (auch **ohne** `index.md`; die Area-ohne-Index-Lücke, die der reine `index.md`-Scan übersähe) wird durch den **§5.8-Instruktions-Hold (Zwei-Ebenen, Tiefe ≥ 3)** angehalten (keine Datei, kein Index-Link, textuelle Meldung `NESTED AREA: `, Run „teilweise erfolgreich", NFR-4) — **Loopback-1-Renegotiation (menschen-autorisierte Option A):** Träger ist der §5.8-lokale Hold, **nicht** der §3.2-Kollisions-Hold (der bleibt der Dateikollision *bestehender* Concepts vorbehalten — ein brandneuer Zwei-Ebenen-Pfad kollidiert nie mit einem existierenden); (4) **Suche = Consumer-grep** (`grep -rn wiki/` rekursiv bzw. `rg wiki/`, AD-13 — keine Such-Datenbank, kein Embedding, kein Index-Datei-Format; NFR-3), (5) **Discovery-Demo (optional, kein MOVE)** — bei Durchführung: Formel-4-Re-Baseline-Pflicht (neuer Zuwachs-Run), sonst bleibt Formel 4 `38 ≡ 38`. Nachgeführt: **§7** Story-2.5-Vorbehalt auf „Suche"-Rest gekürzt (Navigation/Area-Indizes jetzt §5.8-verankert, Suche = Consumer-Thema; die Vorbehalt-Zeile lag in der Baseline `main` bei Z. 253, nach dem §5.8-Einschub bei Z. 285), **§8** Normreferenzen (AD-9/AD-13 → §5.8, FR-11 → §5.7 Pkt. 5/§5.8, NFR-3 neu) + Revisionslog **2.3**. **Selbsttest-Beleg (re-executiert, die gehärtete Loop-3-§5.8-Pkt.-2-Selbsttest-Formel von `schema/compiler.md` §5.8 Pkt. 2 (CWD-Präguard, Erreichbarkeits-Check auf Markdown-Linksyntax `](` per `grep -qF`, `LC_ALL=C sort -u`) als wörtlicher Einzel-Quote-`sh -c '…'`-String — Live-Baum: keine Ausgabe, Exit 0; CWD-Präguard-Kontrolle außerhalb der Workspace-Root: `SELBSTTEST-SETUP-Fehler: Workspace-Root (wiki/index.md fehlt)` + Exit 1):** Area `wissensarchitektur` aus der Bundleroot verlinkt (Root→Area, Selbsttest-Lauf A); die Area→Concept-Verlinkung (`source-material.md` in der Area-`index.md`) ist durch den **Validator Punkt 11** mechanisch abgedeckt (kein Duplikat im Selbsttest). **Sandbox-/Edge-Tests (I/O-Matrix, deterministische Formel-Ausgaben):** (a) HAPPY — gewurzelte Erreichbarkeit ohne Verletzung; (b) **AREA_UNREACHABLE** — Area-`index.md` existiert, Bundleroot unverlinkt → `UNREACHABLE AREA: ` (textuell benannter Instruktions-Selbsttest-Befund, kein Validator-Punkt); (c) **NESTED_AREA_KANDIDAT** — `wiki/a/b/index.md`- und `wiki/a/b/concept.md`-Kandidaten (je einzeln) → `NESTED AREA: a` (erste Ebene der nicht-zulässigen Struktur; bei mehreren Dateien unter derselben ersten Ebene Konsolidierung über `LC_ALL=C sort -u`); Sandbox-Nachweis auf einem synthetischen Baum mit angelegter Testdatei (Zwei-Zustands-Klarstellung Loop-3-Decision-2: die Formel meldet bestehende Tiefe-≥-3-Dateien; der Hold-Zeitpunkt hält den Erstellungskandidaten an, ohne Datei). Die Sandbox-Kontrollen decken die I/O-Matrix-Szenarien **AREA_UNREACHABLE** und **NESTED_AREA_KANDIDAT** ab. §5.6-Formeln unverändert re-executierbar: Formel 2 (Form-Check) `0` (Exit 0), Formel 3 (Dangling-Check) keine Ausgabe, Formel 4 `38 ≡ 38` (Ist ≡ Extraktion aus dem Run-Kopf `862cf41` — keine neue Baseline nötig, keine `wiki/`-Dateimenge-Änderung durch Story 2.5; die Demo ist optional und würde bei Durchführung die Re-Baseline auslösen). Validator-Lauf (human-mechanisch ausgeführte Text-Instruktion `schema/validator.md`, D-3 — kein CLI): alle 7 `wiki/`-Dateien SUCCESS (Punkte 1/2/6/7/8/9/10/11/12/13/14, EC-1) — unverändert zur Story 2.4; das per-Datei-Verdikt ist der Ausführungs-Nachweis für die Spec-Verification Pkt. 3 und AC 5. `sprint-status.yaml`: `2-5-progressive-discovery-über-index-md-bereitstellen` `backlog` → **`in-progress`** (Implementierungs-Eintrag) → **`review`** (Review-Handoff, dieser Eintrag — die gefrorene Spec-Vorgabe „→ `in-progress`" beschreibt den Implementierungsstand, der Review-Handoff ist der übliche Folgezustand, s. Sprint-Status-Workflow-Kommentar „Dev moves story to 'review'"); Loop-3-Abschluss mit diesem Review: `review` → **`done`** (Sprint-Status synchronisiert, spec-Frontmatter `status: 'done'` deckungsgleich, `review_loop_iteration` → 3). `schema/wiki-compiler.md`/`validator.md`/`raw/` unverändert (AD-3); keine neue §7-Klasse; kein Standalone (D-3); keine Vertragsänderung. - **Story 2.4 «Deterministische Bereichszuordnung & Concept-Hierarchie» (Review-Loop 2, bmad-code-review, 4 Layer):** 3 `decision-needed` (Nutzer-Entscheidungen 1/1/1) + 11 `patch` umgesetzt, 4 `defer` (s. `deferred-work.md`), 8 dismissed. `schema/compiler.md` → **Revision 2.2**: (1) **Formel 3 quellenbasierte `../schema/*`-Exklusion** (Decision 2): die Exklusion greift nur, wenn die Quell-Datei auf Bundleroot-Ebene liegt (`dirname ` = `wiki`); aus Area-Quellen läuft einstufiges `../schema/…` durch Auflösung + Containment + Existenztest (Prosa war bereits „nur aus Root-Dateien", die Formel folgt jetzt der Prosa); (2) **Formel 4 Re-Baseline auf den Run-Kopf** (Decision 1): Extraktions-Commit `862cf410c624072833cd959da9a2fb26235716f6` statt `66451b6…` — der gepinnte Selbsttest lief auf dem Zuwachs-Baum deterministisch `38 ≠ 30` = Run-FAIL (bekannt-böser Zustand aus Loop-1-A2, nur halb geheilt); jetzt **38 ≡ 38** (re-executiert: Ist=38, Extraktion `862cf41`=38; `66451b6`/`30` dokumentiert den Vor-Zuwachs-Zustand, bleibt als Referenz dieses Runs); (3) **§5.7 Pkt. 1(a) Treffer-Prädikat + Tie-Break** (Decision 3): „inhaltlich deckungsgleichen Eintrag" (Urteil, AD-13-Verstoß) ersetzt durch textuelles Prädikat (Identität des Link-Ziels ≡ kanonischer Name des Themas) + Mehrfachtreffer-Regel (Bundleroot-Links vor Area-Links, dann lexicografische Pfad-Reihenfolge); (4) file-relative Pin-Wortwahl in §5.3 Pkt. 3 (Oxymoron „file-relativ bundle-relativ" aufgelöst), §6.6-Zelle und §7-Bullet nachgeführt; (5) §7-Scope-Einleitung „Root-Ebene" → „Root-Ebene und in Areas gemäß §5.7"; (6) Typos („akte-Baseline" → „aktuelle Baseline", Doppel-Leerzeichen §6.6); (7) „Kopf dieser Spezifikation" → „Baseline-Commit des letzten Zuwachs-Runs". `wiki/wissensarchitektur/index.md`: Prosa auf den tatsächlichen Area-Inhalt gekürzt (nur `source-material.md` existiert; Link-Form/Discovery-Topics waren übergezeichnet). **Negativ-Test-Nachweis (Sandbox-Baum, exakte Formel-Ausgabe):** (a) **TOP_LEVEL_COLLISION** — Kandidat mit ID `llm-wiki-prinzip`: `wiki/llm-wiki-prinzip.md` existiert → §3.2-Hold „Concept existiert bereits — Aktualisierung ist Epic 3" (keine Datei, kein Index-Link, kein `log.md`-Eintrag); (b) **AREA_WITHOUT_INDEX** — Sandbox-`wiki/foo/` ohne `index.md`: wörtliche Punkt-11-Meldung `FAIL wiki/foo/ Punkt 11: Index-Regel verletzt (Area ohne index.md=foo)` (Validator-§7.1-Fixture-Wortlaut, kein inventiertes `AREA_WITHOUT_INDEX`-Label); (c) **DIVING_NON_EXISTENT** — `[v](../fehlt.md)` aus Area-Concept → `DANGLING: ../fehlt.md`; (d) **Out-of-Bundle-Escape** (Loop-1-A1-Kontrolle) — `[x](../../README.md)` → `DANGLING: ../../README.md`, `[y](../../schema/compiler.md)` → `DANGLING: ../../schema/compiler.md`; (e) **In-Bundle-`../schema/` aus Area (Loop-2-Kontrolle)** — `[z](../schema/compiler.md)` aus `wiki/wissensarchitektur/source-material.md` → `DANGLING: ../schema/compiler.md` (vor dem Loop-2-Patch: still exkludiert, leere Ausgabe — Sandbox-Nachweis des gefixten Löchs). Positiv-Kontrolle nach allen Patches: Formel 2 (Form-Check) = `0` (Exit 0), Formel 3 (Dangling) = keine Ausgabe, Formel 4 = `38 ≡ 38` (beide re-executiert). Status-Nachführung (korrigiert zum obigen Implementierungs-Eintrag): `sprint-status.yaml` `2-4-…` `backlog` → `in-progress` (Implementierungs-Eintrag) → **`review`** (Review-Handoff, dieser Eintrag); die gefrorene Spec-Vorgabe („→ `in-progress`") beschreibt den Implementierungsstand, der Review-Handoff ist der übliche Folgezustand (s. Sprint-Status-Workflow-Kommentar „Dev moves story to 'review'"). Loop-Abschluss mit diesem Review: `review` → **`done`** (Sprint-Status synchronisiert, `sprint-status.yaml` `last_updated` nachgeführt; spec-Frontmatter `status: 'done'` deckungsgleich, `review_loop_iteration` → 2). Validator-Lauf-Korrektur zum obigen Eintrag: die gültige Datei-Zählung ist **7** `wiki/`-Dateien (Bundleroot, `log.md`, 3 Root-Concepts, Area-`index.md`, Area-Concept) — der obige Verweis auf „Punkt 9/10" für die Differenz zur Spec-Zahl 6 war falsch belegt (Punkt 9 = `okf_version`/`type: bundle`-Verbot außerhalb der Bundleroot; `log.md` wird über Punkt 10/V-2 mitvalidiert); die Spec-Zahl 6 ist eine frozen-Defizitzählung (Defer in `deferred-work.md`). `schema/wiki-compiler.md`/`validator.md`/`raw/` unverändert (AD-3); keine neue §7-Klasse; kein Standalone (D-3). - **Story 2.4 «Deterministische Bereichszuordnung & Concept-Hierarchie» (Implementierung):** `schema/compiler.md` → **Revision 2.1** (neue §5.7 „Deterministische Bereichszuordnung & Concept-Hierarchie": Routing-Regel textual-deterministisch — (a) First-Class-Link aus dem bestehenden `index.md`-Baum → Bereich `wiki//.md`, (b) Default Root-Ebene, neue Areas nur konsolidiert; nie Embedding/Vector, AD-7c/A0-10/AD-13; kanonische ID-Normalisierung AD-7a/A0-8 mit Beispieltabelle; Top-Level-Kollisions-Hold → fixierter §3.2, kein neues Prädikat, kein MOVE; file-relatives Link-Auflösungsmodell inkl. Out-of-Bundle-`..`-Containment; Area-`index.md`-Regel mit wörtlicher Punkt-11-Meldung `FAIL … Punkt 11: Index-Regel verletzt (Area ohne index.md=)` — kein inventiertes Label; Worked Example). Nachgeführt: §5.1 Pkt. 1, §5.3 Pkt. 3 (Index-Regel area-bewusst), §5.6 Pkt. 1/2/3/4/5 (file-relativ; `../`-Exklusion aufgelöst; Formel 3 mit Quell-Datei-Spur + in-Bundle-`..`-Auflösung + Containment — Out-of-Bundle-`..`-Escape wird `DANGLING`; Formel 4 neu auf `baseline_commit` `66451b6e6c9e139fb3aa3bbf4b01291e1e2d273a` (deklarierte `baseline_commit`-Werte der Spec-Frontmatter, nicht mehr Story-2.3-`7e1f449…`; Loop-2: Re-Baseline auf den Run-Kopf `862cf41`, s. obiger Review-Eintrag), Basename-Filter `grep -v "log.md$"`), §6 Pkt. 2, §6.6, §7, §8. `deferred-work.md`: drei Story-2.4-namige Einträge geschlossen (`umgesetzt`): bundlerelativ-vs-dateirelativ (→ §5.7 Pkt. 4 file-relativ), Cross-Page-Anker-Stale-Evidenz (→ Ist-Verhalten Fragment-Strip, keine Dangling-Ausgabe), künftiges Area-`log.md`-Baseline-Bruch (→ Formel 4 Basename-Filter). Neue Area `wiki/wissensarchitektur/` angelegt: `wiki/wissensarchitektur/index.md` (frontmatterlos, Vertrag §2/§6, Validator Punkt 10; verlinkt das Area-Concept in der gepinnten §5.6-Form) + `wiki/wissensarchitektur/source-material.md` (Area-Concept `type: concept`, `sources` s1=architecture-spine + s2=prd, §5.5-Inline-Verweise + Kontext-Marker, Body-Links auf Root-Concepts in file-relativer `../`-Form: `llm-wiki-prinzip.md`, `wissensarchitektur-trennung-states.md`, `knowledge-kompilation-inkrementell.md`). `wiki/index.md`: neue **Area-Sektion** verlinkt `wissensarchitektur/index.md` (die 3 bestehenden Root-Concept-Links + die 3 `../schema/`-Links byte-identisch, Null-Migration). **Formel-4-Re-Baseline:** Ist-Zählung auf dem neuen Baum = **38** (`log.md`-exkludiert; `grep -roE '\(raw/'`), Baseline-Extraktion aus `66451b6` = **30** (alter Baum, 4 nicht-`log.md`-Dateien: `index.md` + 3 Root-Concepts; `git ls-tree -r + git show`, Basename-`log.md`-Filter) — Dokumentation verlangt die aktuelle Baseline aus `66451b6` (`38 ≠ 30`, kein Fehlalarm: Zuwachs-Re-Baseline; Loop-2-Korrektur: Re-Baseline auf den Run-Kopf `862cf41`, `38 ≡ 38`, s. obiger Review-Eintrag); die exakte Ist-Zahl hängt am finalen Concept/Body-Stand und wird in der Spec-Verification des Runs belegt. `sprint-status.yaml`: `2-4-deterministische-bereichszuordnung-concept-hierarchie` `backlog` → **`in-progress`** (dieser Statuswechsel findet mit diesem Eintrag statt). Validator-Lauf: alle **7** `wiki/`-Dateien SUCCESS (`index.md` + `log.md` + 3 Root-Concepts + Area-`index.md` + Area-Concept; Punkte 1/2/6/7/8/9/10/11/12/13/14, EC-1; die Spec-Verification nennt erwartungsseitig „6 `wiki/`-Dateien" — die Differenz erklärt sich durch das reservierte `log.md` (Protokoll, wird mitvalidiert, Punkt 9/10), die Validator-Effort-Zahl dieser erfolgten Ausführung ist 7). `schema/wiki-compiler.md`/`validator.md`/`raw/` unverändert (AD-3); keine neue §7-Klasse; kein Standalone (D-3).