Story 2 2 #1
@@ -187,3 +187,11 @@ Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Ein
|
||||
- summary: **2. Innen-Ebenen-Punkt-6-Fixture-Zeile ergänzen** — die in Rev 8 formalisierte Innen-Ebenen-Regel (Punkt 6: unautorisierte Keys in `sources`/`generated`/`verified`-Einträgen, Vertrag §3.3–§3.5) hat keine Fixture-Zeile in §7.1/§7.3; der einzige Punkt-6-Fixture ist Top-Level `foo: bar`, §7.3 zeigt `sources … role: x` nur als Inline-Prosa-Beispiel. In der autorisierten Revision eine Negativ-Fixture-Zeile (z. B. `sources`-Eintrag mit `role: x` bei existierender `raw/`-Datei → `FAIL … Punkt 6`) ergänzen + Zertifizierung (isoliertes Sample) + Nachweis in `wiki/log.md` nachführen.
|
||||
evidence: bmad-code-review Re-Run (2026-08-17) — Blind Hunter + Verification-Gap; beides betrifft die gefrorene Rev 8.
|
||||
status: offen — Home: nächste autorisierte Validator-Revision (Rev 9), Validator-Kanal; **kein Story-2.1-Blocker** (Story bleibt `review`, `done`-fähig; verbleibende Schwelle = Human-Review). Verknüpft mit Action-Item `code-review-2-1-item-2`.
|
||||
|
||||
## Deferred from: code review of story-2.2 (2026-08-17)
|
||||
|
||||
> **Step-04-Review (Story 2.2, 2026-08-17):** Von der Verification-Gap-Schicht als Defer klassifizierter Befund — kein Story-2.2-Blocker, da die Story die Markierungs-Syntax liefert und nicht die inhaltliche/kleine Closure-Verifikation.
|
||||
|
||||
- source_spec: `_bmad-output/implementation-artifacts/spec-2-2-claim-granulare-provenienz-dokumentieren.md`
|
||||
summary: Sources-Closure-Verifikation einführen — jeder inline-referenzierte `raw/`-Pfad eines Concept-Bodies (per deterministischer Extraktion aus `(raw/…`-Verweisen) MUSS im `sources`-Frontmatter desselben Concepts deklariert sein (inkl. neuer `sources`-Einträge für Relokation/Zielwechsel, §5.5-Pkt.-1b-Regel). Aktuell prüft nur der `grep -nE '\(raw/'`-Existenz-Smoke die Präsenz des Verweises, nicht seine Zuordnung zu einer deklarierten Ressource; EC-1 prüft nur die deklarierten `sources`-Ressourcen, nicht inline-referenzierte. Ein inline-Verweis auf eine nicht deklarierte `raw/`-Datei (Beispiel im Story-2.2-Body behoben) bliebe sonst unsichtbar.
|
||||
evidence: Verification-Gap-Review (Story 2.2): Demonstriert an `wiki/wissensarchitektur-trennung-states.md` (Consumer-Unabhängigkeit zitierte `raw/epics/…` ohne `sources`-Deklaration — im Story-2.2-Patch behoben); kein re-runnable Check deckt die Abgeschlossenheit ab (D-3-konforme Deterministische Closure-Prüfung, analog grep-Pipeline, kein Standalone).
|
||||
|
||||
@@ -0,0 +1,31 @@
|
||||
# Review-Klassifikation Story 2.2 (Step-04-Review, 2026-08-17)
|
||||
|
||||
> Drei Review-Layer (Blind Hunter, Edge Case Hunter, Verification Gap) auf dem Stand des Story-2.2-Diffs (baseline `bb32acd`, tracked + untracked Spec). Klassifikation gemäß step-04-review.md: dedupliziert, Severity-Einstufung durch den Workflow (Reviewer-Severity verworfen), Triage. **Kein** `intent_gap`, **kein** `bad_spec` → kein Loopback; Story-2.2-Problem = `patch` + `defer`.
|
||||
|
||||
## Triage-Ergebnis (dedupliziert, je Kern-Finding)
|
||||
|
||||
| # | Befund (Kern) | Quelle | Severity | Kategorie | Behandlung |
|
||||
|---|---|---|---|---|---|
|
||||
| P1 | §5.5-Widerspruch „kein Frontmatter-Change" vs. tatsächliche `sources`-/`id`-Hinzufügungen | BH-1 | medium | patch | §5.5-Klarstellung (schema/compiler.md) |
|
||||
| P2 | §5.5 `#<id>`-Fragment-Semantik: sources-`id` (s1/s2) existiert nicht im Rohdokument; `<pfad>#<id>`-Form teilweise ohne Gültigkeit | BH-2, BH-6, VG-3 | medium | patch | Inline-Verweis-Form präzisieren (Stellen-Kennung, volle Pfade, kein sources-`id`-Fragment) |
|
||||
| P3 | Body: `§0 Dokumentzweck` vs. englischer PRD-Titel; `#s1`/`#s2`-Fragmente; Pfad-Elision `#A0-6` ohne Pfad | BH-3, VG-3 | medium | patch | llm-wiki-prinzip + wissensarchitektur Body-Fixes |
|
||||
| P4 | `wissensarchitektur`::FR-16-Verweis zitiert `raw/epics/…` **ohne** `sources`-Deklaration → Relokations-Regel §5.5 Pkt. 1b verletzt (widerspricht dem eigenen Diff) | VG-1, VG-2 | high | patch | FR-16-Beleg auf PRD §4.5 allein; epics-Verweis entfernen |
|
||||
| P5 | Kontext-Marker: Selbstreferenz (Concept nennt sich als Ursprung); Direkt- übernahme-aus-raw Fall fehlt; Forward-Referenz-Wortlaut weicht von §5.5 ab | BH-5, VG-4, EC-3 | medium | patch | Marker-Grammatik + Body-Marker anpassen |
|
||||
| P6 | Kein worked example; §5.5-Pkt.-1„zulässig beide / erkennbar"-Unbestimmtheit gegen AD-17h-Grep | BH-3, BH-13 | medium | patch | §5.5: Grep-Formel `\(raw/|\]\(raw/`, verbindliche Default-Form, worked example |
|
||||
| P7 | `wiki/log.md` Eintrag: `#s2`-Fragment + Quell-Deklarations-Wortlaut (wissensarchitektur-Diagramm) an die korrigierten Markers angleichen | (VG-3 Ableitung) | low | patch | log.md-Nachführ-Eintrag minimal reinigen |
|
||||
| D1 | Sources-Closure-Verifikation (jeder inline-referenzierte `raw/`-Pfad ⊆ `sources`) — kein re-runnable Check (D-3-konform) | VG-1/VG-2 | medium | defer | deferred-work.md, Abschnitt „Deferred from: code review of story-2.2 (2026-08-17)" |
|
||||
|
||||
## Rejects (Rauschen, still verworfen)
|
||||
|
||||
- **BH-8** (Status-Inkonsistenz Spec `in-review` vs. sprint-status `in-progress` vs. log `SUCCESS`) — normaler Workflow-Fluss (Review beginnt, Story bleibt bis `done` `in-progress`; log ist Lauf-Protokoll). **reject**.
|
||||
- **BH-14** (index.md-Vereinfachung der Konzept-Beschreibung) — bewusst vereinfachtes Discovery-Niveau; kein Konflikt mit claim-granularer Provenienz der Bodies. **reject**.
|
||||
- **BH-15** (I/O-Matrix unvollständig) — Scope-/Frozen-Entscheidung (nur 2 Szenarien in der Approve-Baseline); kein bad_spec. **reject**.
|
||||
- **VG-5** („A0-7 orphan") — **widerlegt** durch Faktencheck: `A0-7` existiert in `raw/epics/epics-2026-08-14.md` (Zeile 55, Bezeichner `- **A0-7 — Reason/Mutate-Trennung (AD-6):**`). Der Verweis `raw/epics/…md#A0-7` in `knowledge-kompilation-inkrementell.md` ist korrekt. **reject**.
|
||||
|
||||
## Patches an den Implementierungs-Subagenten (Kontext intakt, synchron)
|
||||
|
||||
Die patch-Findings P1–P7 wurden dem Step-3-Implementierungs-Subagenten als vollständiges Paket gesendet (Datei, Defekt, Fix-Anforderung; deutsche Ausgaben; Re-Run der Spec-Verification). Danach: erneute Verifikation aller Checks.
|
||||
|
||||
## Verifikations-Hinweis
|
||||
|
||||
Der Validator (`schema/validator.md`) ist eine reine Text-Instruktion (D-3, kein CLI). „Validator-Lauf: alle 5 wiki/-Dateien SUCCESS" ist die human/manuell-mechanische Ausführung der §3-/§6-Regeln. Dies entspricht der etablierten Konvention (Story 1.4/2.1).
|
||||
+125
@@ -0,0 +1,125 @@
|
||||
---
|
||||
title: 'Claim-granulare Provenienz dokumentieren (Story 2.2)'
|
||||
type: 'feature'
|
||||
created: '2026-08-17'
|
||||
status: 'done'
|
||||
review_loop_iteration: 0
|
||||
baseline_commit: bb32acdf3f1a3547424da0f878bd06383921b22a
|
||||
context:
|
||||
- _bmad-output/implementation-artifacts/epic-2-context.md
|
||||
---
|
||||
|
||||
<frozen-after-approval reason="human-owned intent — do not modify unless human renegotiates">
|
||||
|
||||
## Intent
|
||||
|
||||
**Problem:** Die drei Concepts aus Story 2.1 tragen Provenienz nur auf Concept-Ebene (`sources`-Frontmatter); belegte Aussagen und Kontext-/Synthese-Umformulierungen sind claim-granular nicht auf `raw/`-Evidenz rückführbar (AD-4a, A0-3). Instanz: `knowledge-kompilation-inkrementell.md` deklariert nur `raw/epics/…`, enthält aber ein ASCII-Diagramm aus `raw/architecture-spine/…`.
|
||||
|
||||
**Approach:** `schema/compiler.md` um Sektion „Claim-granulare Provenienz" erweitern (Inline-`raw/`-Verweise je belegter Aussage, Kontext-Marker je Übernahme, `id`-Attribution aus Vertrag §3.3) und die drei Concepts + `wiki/index.md` + `wiki/log.md` nachkonformieren. Kein Standalone-Tool, keine neue §7-Klasse, keine Vertragsänderung.
|
||||
|
||||
## Boundaries & Constraints
|
||||
|
||||
**Always:**
|
||||
- Provenienz = Body-Text-Konvention (Inline-`raw/`-Verweis je belegter Aussage; Kontext-Marker „übernommen aus `<Concept-Pfad>` auf Basis von `<source>`, nicht eigenständig belegt" je Übernahme — AD-4a/A0-3). Kein Frontmatter-Change, kein neues Feld.
|
||||
- Nachrüstung mutiert ausschließlich `wiki/` (Concept-Bodies, `index.md`, `log.md`). `raw/`, `schema/wiki-compiler.md`, `schema/validator.md` unverändert (AD-3). `schema/compiler.md` = einziger Instruktions-Ort (D-3).
|
||||
- Neue `sources`-Einträge: nur §3.3-Subset; `id` je Concept eindeutig; `resource` nie `wiki/` (AD-4b); kein generiertes Concept führt ein anderes als alleinige Provenienz (AD-4c).
|
||||
- `generated`/`verified`/`status` unangetastet (v1-Default A0-20). Epic-3/4-Fähigkeiten im Body als Forward-Referenz ohne eigene Behauptung markiert.
|
||||
- Revisionslog der Instruktion + `wiki/log.md` (Vertrag §5) dokumentieren die Änderung.
|
||||
|
||||
**Ask First:** Neue §7-Klasse / Vertragsänderung · Standalone-Programm (D-3) · `wiki/<area>/`-Anlage (Story 2.4).
|
||||
|
||||
**Never:** OKF-Dialekt · Änderung an `schema/wiki-compiler.md`/`schema/validator.md`/`raw/` · Validator-Verhaltenswechsel (bleibt strukturell; Content-Truth = eigenständige Arbeit) · Vorwegnahme Story 2.3/2.4 · Falsch-Attribution.
|
||||
|
||||
## I/O & Edge-Case Matrix
|
||||
|
||||
| Scenario | Input | Expected | Error Handling |
|
||||
|----------|-------|----------|----------------|
|
||||
| HAPPY_PATH | 3 Concept-Bodies, Kern + Übernahmen (z. B. ASCII-Diagramm) | Belegte Aussagen mit Inline-Verweis; Übernahmen mit Marker; Diagramm-Quelle deklariert; Validator SUCCESS | N/A |
|
||||
| UNBELEGTE_AUSSAGE | Aussage nicht auf `sources` rückführbar | Als Übernahme mit Marker geführt (nicht erfunden belegt) | Run bricht nicht ab; textuell sichtbar |
|
||||
|
||||
</frozen-after-approval>
|
||||
|
||||
## Code Map
|
||||
|
||||
- `schema/compiler.md` — **mutiert**: Sektion „Claim-granulare Provenienz" (Inline-Verweise, Kontext-Marker, `id`); Revisionslog (§8); §7-Selbstbegrenzung.
|
||||
- `schema/wiki-compiler.md` — **read-only**: §3.3 `sources`/`id`, §5 `log.md`, §7 abschließende Liste.
|
||||
- `schema/validator.md` — **read-only (Rev 8)**: bleibt strukturell.
|
||||
- `wiki/llm-wiki-prinzip.md`, `wiki/knowledge-kompilation-inkrementell.md`, `wiki/wissensarchitektur-trennung-states.md` — **mutiert**: Body um Inline-Verweise/Kontext-Marker.
|
||||
- `wiki/index.md` — **mutiert**: Beschreibungen um `(aus <raw-Pfad>)`.
|
||||
- `wiki/log.md` — **append-only**: Nachrüst-Eintrag inkl. Diagramm-Quell-Deklaration.
|
||||
- `raw/architecture-spine/…` (AD-4a :143), `raw/epics/…`, `raw/prd/…` — **read-only Evidenz**.
|
||||
- `_bmad-output/implementation-artifacts/epic-2-context.md` — Planungskontext (read-only).
|
||||
|
||||
## Tasks & Acceptance
|
||||
|
||||
**Execution:**
|
||||
- [x] `schema/compiler.md` — Sektion „Claim-granulare Provenienz" (nach §5, vor §6): Inline-`raw/`-Verweis je belegter Aussage (+ `id`), Kontext-Marker je Übernahme, eindeutiges `id`-Scoping (§3.3), Selbsttest-Kriterien (belegte Aussage → `raw/`-Verweis; Übernahme → Marker; kein unautorisierter Key) — AD-4a/4c, AD-13, AD-17h. **inkl. Review-Patch-Runde (Rev 1.6): Stellen-Kennungs-Semantik, volle Pfade, Direktübernahme-Marker, worked example, korrigierte Grep-Formel.**
|
||||
- [x] `schema/compiler.md` — Revisionslog (§8, Fortlauf) + §7-Selbstbegrenzung „→ Story 2.2".
|
||||
- [x] Nachrüst-Schritt: 3 Concept-Bodies — belegte Aussagen mit Inline-`raw/`-Verweisen; Übernahmen (insbesondere ASCII-Diagramm → `raw/architecture-spine/…`) mit Kontext-Marker + ggf. zusätzlichem `sources`-Eintrag; Epic-3/4-Formulierungen als Forward-Referenz.
|
||||
- [x] `wiki/index.md` — Beschreibungen um `(aus <raw-Pfad>)`.
|
||||
- [x] `wiki/log.md` — Nachrüst-Eintrag (§5-Format).
|
||||
- [x] Validator-Lauf — alle 5 `wiki/`-Dateien SUCCESS (Punkte 1/6/11/14, EC-1) (manuell-mechanisch, D-3; kein CLI).
|
||||
- [x] `sprint-status.yaml` — Story 2.2 → `in-progress`.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
- Given Concept mit fachlichen Aussagen, when nach Story 2.2 verarbeitet, then trägt jede belegte Aussage einen Inline-Verweis auf `raw/`-Evidenz (AD-4a).
|
||||
- Given Kontext-/Synthese-Umformulierung, when übernommen, then trägt sie den expliziten Kontext-Marker — inklusive ASCII-Diagramm.
|
||||
- Given `sources`-Dokumentation, when gesetzt, then lösen Werte ausschließlich auf `raw/`-Pfade auf (AD-4b); kein generiertes Concept führt ein anderes als alleinige Provenienz (AD-4c) — formseitig prüfbar.
|
||||
- Given Nachrüst-Inhalte, when validiert, then bleibt das Bundle vollständig Validator-SUCCESS (keine neue Invaliditätsklasse, keine Vertrags-/`raw/`-Mutation).
|
||||
- Given Instruktions-Bestand, when geprüft, then rein textuell (D-3), deterministisch (AD-17h), referenziert den Vertrag.
|
||||
|
||||
## Spec Change Log
|
||||
|
||||
- **2026-08-17 (Erstellung):** Initiale Approve-Baseline.
|
||||
- **2026-08-17 (Patch-Runde, Step-04-Review):** Review-Findings (patch-Klasse) umgesetzt: §5.5-Klarstellungen (Rev 1.6 in `schema/compiler.md`), Body-Vereinheitlichung (Stellen-Kennungs-Sektionstitel statt Concept-`id`-Fragmente, volle `raw/`-Pfade je Beleg, Direktübernahme-Marker ohne Selbstreferenz, FR-16-Beleg auf PRD §4.5 allein), `index.md`/`log.md`-Angleichungen. Klassifikation: `review-2-2-klassifikation.md`. Defer: sources-Closure-Verifikation → `deferred-work.md`.
|
||||
|
||||
## Verification
|
||||
|
||||
**Commands:**
|
||||
- `git diff --stat` — `schema/compiler.md`, 3 x `wiki/*.md`, `wiki/index.md`, `wiki/log.md`, `sprint-status.yaml`; KEINE `raw/`-/`schema/wiki-compiler.md`-Mutation.
|
||||
- `grep -nE '\(raw/' wiki/*.md` — je belegter Aussage ein Inline-`raw/`-Verweis.
|
||||
- Validator-Lauf (deterministisch) — alle `wiki/`-Dateien SUCCESS (Punkte 1/6/11/14, EC-1).
|
||||
- `grep -nE '^(type|sources|generated|verified|status|stale_after):' wiki/*.md` — nur §3-Felder; `grep -nE 'resource:' wiki/*.md` — jeder Wert existierender `/`-getrennter `raw/`-Pfad.
|
||||
|
||||
**Manual checks (if no CLI):**
|
||||
- Belegte Aussage → Inline-`raw/`-Verweis; Übernahme → Kontext-Marker („übernommen aus … auf Basis von …, nicht eigenständig belegt").
|
||||
- `sources`-`id` je Concept eindeutig; keine unautorisierten Keys; `schema/compiler.md` rein textuell (D-3), deterministisch (AD-17h), referenziert den Vertrag.
|
||||
- `wiki/log.md` enthält datierten Nachrüst-Eintrag inkl. Diagramm-Quell-Deklaration.
|
||||
|
||||
## Suggested Review Order
|
||||
|
||||
**Instruktions-Basis (§5.5 Claim-granulare Provenienz — der Einstiegspunkt)**
|
||||
|
||||
- Konvention: Inline-`raw/`-Verweis je belegter Aussage, Kontext-Marker je Übernahme, `id`-Scoping — der verbindliche Standard für alles Folgende.
|
||||
[`compiler.md:66`](../../schema/compiler.md#L66)
|
||||
|
||||
- Selbsttest-Formel & Sicherstellung der Grep-Auffindbarkeit (AD-17h).
|
||||
[`compiler.md:76`](../../schema/compiler.md#L76)
|
||||
|
||||
- Revisionslog dokumentiert Nachrüstung (1.5) und Review-Patch-Runde (1.6).
|
||||
[`compiler.md:188`](../../schema/compiler.md#L188)
|
||||
|
||||
**Nachkonformierte Concept-Bodies (die eigentliche Provenienz-Arbeit)**
|
||||
|
||||
- Belegte Aussagen mit vollem `raw/`-Verweis; Diagramm als Direktübernahme aus `raw/architecture-spine/…` mit Marker; Forward-Referenz auf Epic 3.
|
||||
[`knowledge-kompilation-inkrementell.md:37`](../../wiki/knowledge-kompilation-inkrementell.md#L37)
|
||||
|
||||
- SoC-Diagramm als Direktübernahme aus `raw/prd/…` (§ 8.3) mit Marker; FR-16-Beleg auf PRD § 4.5 allein (Relokations-Regel eingehalten).
|
||||
[`wissensarchitektur-trennung-states.md:30`](../../wiki/wissensarchitektur-trennung-states.md#L30)
|
||||
|
||||
- Datenfluss-Diagramm als Direktübernahme aus `raw/prd/…` (§ 0 Document Purpose); PRD-Attribution über Sektionstitel (keine s-Fragmente).
|
||||
[`llm-wiki-prinzip.md:40`](../../wiki/llm-wiki-prinzip.md#L40)
|
||||
|
||||
**Bundle-Index & Nachweisführung**
|
||||
|
||||
- `index.md`-Beschreibungen mit `(aus <raw-Pfad>)` inkl. Diagramm-Quellen.
|
||||
[`index.md:29`](../../wiki/index.md#L29)
|
||||
|
||||
- `log.md`-Nachrüst-Eintrag (Vertrag §5-Format) inkl. Diagramm-Quell-Deklaration.
|
||||
[`log.md:4`](../../wiki/log.md#L4)
|
||||
|
||||
- Defer-Kontext: sources-Closure-Verifikation (jeder inline-referenzierte `raw/`-Pfad ⊆ `sources`) für spätere Fokussierung.
|
||||
[`deferred-work.md:196`](./deferred-work.md#L196)
|
||||
|
||||
- Story-Status `in-progress` (nach Human-Review → `review`).
|
||||
[`sprint-status.yaml:47`](./sprint-status.yaml#L47)
|
||||
@@ -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-17-2026 07:35
|
||||
last_updated: 08-17-2026 09:05
|
||||
project: wow20
|
||||
project_key: NOKEY
|
||||
tracking_system: file-system
|
||||
@@ -44,7 +44,7 @@ development_status:
|
||||
|
||||
epic-2: in-progress
|
||||
2-1-concepts-aus-source-material-erzeugen-okf-konform: done
|
||||
2-2-claim-granulare-provenienz-dokumentieren: backlog
|
||||
2-2-claim-granulare-provenienz-dokumentieren: review
|
||||
2-3-concepts-verlinken-eine-erlaubte-linkform: backlog
|
||||
2-4-deterministische-bereichszuordnung-concept-hierarchie: backlog
|
||||
2-5-progressive-discovery-über-index-md-bereitstellen: backlog
|
||||
|
||||
+52
-2
@@ -58,11 +58,59 @@ Je neuem Concept werden die Frontmatter-Metadaten nach Vertrag §3 festgelegt:
|
||||
|
||||
1. **Ziel-Pfad:** Das neue Concept ist eine Markdown-Datei unter `wiki/`. In dieser Story (keine deterministische Area-Zuordnung; Story 2.4) werden neue Concepts **auf Root-Ebene** angelegt: `wiki/<concept-kebab-case>.md`. Es wird **kein** `wiki/<area>/`-Verzeichnis angelegt; ein als Area gedachtes Ziel (Unterverzeichnis) wird bis Story 2.4 **abgelehnt** und führt zu einem textuell identifizierbaren Hinweis („Area-Zuordnung ist Story 2.4").
|
||||
- Konvention für den Dateinamen: kebab-case-Slug aus der Concept-Identität (kein Sonderzeichen, keine Endung `.md`-Dopplung). Der Dateiname definiert die Concept-Identität (relativer OKF-Pfad ohne `.md`, AD-7a).
|
||||
2. **Dateiinhalt:** YAML-Frontmatter gemäß §4 (kein weiteres Feld), gefolgt von einem Markdown-Body, der die Wissenseinheit eigenständig und lesbar darstellt (NFR-2, NFR-3). Der Body darf keine großen Quell-Exzerpte enthalten (FR-2). Claim-granulare Inline-Provenienz (AD-4a) ist Story 2.2 und wird hier **nicht** gefordert.
|
||||
2. **Dateiinhalt:** YAML-Frontmatter gemäß §4 (kein weiteres Feld), gefolgt von einem Markdown-Body, der die Wissenseinheit eigenständig und lesbar darstellt (NFR-2, NFR-3). Der Body darf keine großen Quell-Exzerpte enthalten (FR-2). Claim-granulare Inline-Provenienz (AD-4a) folgt §5.5 — für neu erzeugte Concepts unmittelbar bei der Erzeugung, für bestehende Bodies per Nachrüstung (Story 2.2).
|
||||
3. **Index-Regel (Punkt 11/§6):** Nach Anlage MUSS das neue (Root-)Concept in der Bundleroot `wiki/index.md` verlinkt werden — seine Identität (relativer OKF-Pfad ohne `.md`) als relativer Bundle-Pfad referenziert, mit oder ohne `.md`-Endung (eine genau-eine-Form-Festlegung ist Story 2.3). Ohne diese Verlinkung ist das Bundle strukturell invalide (§7 Punkt 11).
|
||||
- All dies (Anlage + Verlinkung + `log.md`) erst abschließen, wenn die Validierung (§6) SUCCESS liefert. Zwischenstände werden nicht als fertige Mutation veröffentlicht — Commit-Boundary ist die Mutations-Boundary (AD-17f). Bei Validierungs-FAIL wird der Teilzustand **explizit zurückgerollt**: neue Concept-Datei(en) gelöscht, zugehörige Index-Verlinkung(en) aus `wiki/index.md` entfernt, `log.md`-Eintrag(e) wieder entfernt — das Bundle nimmt seinen Zustand vor dem Run wieder ein (keine partielle Mutation bleibt liegen).
|
||||
4. **Dokumentation (`log.md`, Vertrag §5):** Die Anlage neuer Concepts wird als datumsgruppierter Eintrag in `wiki/log.md` dokumentiert (neueste zuerst; Header = ISO-Datum `YYYY-MM-DD`), verknüpft mit dem neuen Concept-Pfad und den genutzten `raw/`-Quellen. `log.md` bleibt ohne Frontmatter (Punkt 10).
|
||||
|
||||
## 5.5 Claim-granulare Provenienz (Story 2.2)
|
||||
|
||||
Provenienz ist **claim-granular** (AD-4a, A0-3): Nicht nur das Concept als Ganzes trägt `sources`, sondern **jede belegte Aussage** im Body trägt einen Inline-`raw/`-Verweis. Kontext-/Synthese-Umformulierungen — Aussagen, die nicht direkt auf `raw/`-Evidenz rückführbar sind, sondern aus Concept-Kontext, direkt aus einer rohen Quelle (ohne Zwischen-Concept) oder aus Synthese mehrerer Quellen stammen — tragen einen expliziten **Kontext-Marker**. Diese Sektion ist eine Body-Text-Konvention; sie fügt **kein neues Frontmatter-Feld über das §3.3-Subset hinaus** hinzu — das Hinzufügen bzw. Erweitern von `sources`-Einträgen (`resource`/`id`) **IST Teil der Konvention** (Relokation/Zielwechsel, Pkt. 1b) und kollidiert nicht mit dieser Selbstbegrenzung (AD-4a; der Vertrag §3 legt das Feldsubset abschließend fest). Sie gilt für **Neu-Erzeugung und Nachrüstung bestehender Concept-Bodies gleichermaßen**. `wiki-compiler.md` und `validator.md` bleiben unverändert (AD-3); diese Sektion ist der einzige Instruktions-Ort der Provenienz-Konvention (D-3, Story 2.2).
|
||||
|
||||
1. **Inline-`raw/`-Verweis je belegter Aussage:** Eine Aussage ist „belegt", wenn sie sich fachlich auf eine konkrete Evidenzstelle in `raw/` zurückführen lässt. Sie trägt dann unmittelbar am Ende der Aussage (bzw. am Ende des zugehörigen Absatzes/Listenelements) einen Inline-Verweis in der verbindlichen Default-Form:
|
||||
|
||||
`(raw/<datei.md>#<stellen-kennung>)`
|
||||
|
||||
- Das Fragment hinter `#` ist eine **STELLEN-KENNUNG, die im referenzierten Rohdokument tatsächlich existiert** — z. B. ein Bezeichner-`id` der rohen Datei (wie `FR-12`, `A0-6`, `AD-5` in `raw/epics/…` bzw. `raw/architecture-spine/…`) oder der exakte Sektionstitel des Rohdokuments (z. B. `§ 1 Vision`). Die **Concept-eigene `sources`-Feld-`id` (`s1`, `s2`, …) ist NICHT als Fragment zu verwenden**, weil sie im Rohdokument nicht existiert — der Verweis würde im Rohdokument nicht auflösen (keine Falsch-Attribution). Die `sources`-`id` dient ausschließlich der vertragsgemäßen internen Zitat-Attribution (Vertrag §3.3), nicht als Inline-Fragment.
|
||||
- **Voller `raw/`-Pfad je Beleg:** Jeder Beleg nennt den vollen `raw/`-Pfad, auch wenn derselbe Pfad mehrfach referenziert wird: `(raw/epics/epics-2026-08-14.md#FR-12; raw/epics/epics-2026-08-14.md#A0-6)` — **keine Pfad-Elision** (also niemals allein `#A0-6` ohne vorangestellten Pfad).
|
||||
- **Deterministische Selbsttest-Formel:** Die Verweise sind per `grep -nE '(raw/|]\(raw/'` auffindbar (erfasst auch die Markdown-Linkform). Bis Story 2.3 bleibt die Frage „Link-Form `(<pfad>)` ggü. `[<text>](<pfad>)`" formal offen — beide sind zulässig, sofern der volle `raw/`-Pfad am Verweis erkennbar ist und der Grep die Form erfasst.
|
||||
|
||||
- **Pfad-Form:** ausschließlich `/`-getrennte relative Workspace-Pfade **innerhalb `raw/`** — nie `wiki/` (AD-4b), kein `..`, kein führendes `/`, kein Backslash, keine URL-Form (spiegelbildlich zu §4.2 und Vertrag §3.3). Um zusätzliche Validierungsoberfläche ohne importierte Struktur zu vermeiden, verweist der Inline-Beleg üblicherweise auf dasselbe `raw/`-Ziel, das auch im `sources`-Frontmatter des Concepts deklariert ist — die EC-1-Existenzprüfung (§6.5-Kriterium 3 / Validator §6.1) bleibt damit unverändert anwendbar.
|
||||
- **Relokation/Zielwechsel:** Zeigt eine Aussage auf einen anderen `raw/`-Pfad als die `sources`-Deklaration des Concepts (z. B. das ASCII-Diagramm aus `raw/architecture-spine/…` in einem Concept mit `sources: raw/epics/…`), so ist **zusätzlich ein passender `sources`-Eintrag** im Frontmatter zu ergänzen, dessen `resource` auf jenen Pfad zeigt (EC-1-Existenz, Punkt 3/4). Das Diagramm-Quell ist damit sowohl body- als auch frontmatter-seitig deklariert (Story-2.1-Instanz: ASCII-Diagramm in `knowledge-kompilation-inkrementell.md`).
|
||||
|
||||
2. **Kontext-Marker je Übernahme (AD-4a/A0-3):** Eine **Übernahme** ist eine Kontext-/Synthese-Umformulierung: Formulierung, die aus Concept-Kontext, direkt aus einer rohen Quelle oder aus der Synthese mehrerer Quellen stammt und nicht eigenständig gegen `raw/` belegt ist. Es gibt **zwei Marker-Muster** — beide MÜSSEN den exakten Token „nicht eigenständig belegt" enthalten (deterministischer Selbsttest, mindestens eine Form pro Übernahme):
|
||||
|
||||
- **Übernahme über ein Zwischen-Concept** (Ursprungs-Concept existiert): minimal nach Vertrag §3.3/A0-3-Wortlaut
|
||||
|
||||
> übernommen aus `<Concept-Pfad>` auf Basis von `<source>`, nicht eigenständig belegt
|
||||
|
||||
Dabei ist `<Concept-Pfad>` der relative OKF-Pfad des Ursprungs-Concepts ohne `.md` (AD-7a), `<source>` der zugrunde liegende `raw/`-Pfad. **Kein Selbstreferenz-Muster:** Ein Concept, das sich selbst als Ursprung nennt, ist Falsch-Attribution und verboten — gibt es kein Zwischen-Concept, ist Muster (2) zu verwenden.
|
||||
- **Direktübernahme aus `raw/` ohne Zwischen-Concept** (z. B. ein Diagramm direkt aus einer rohen Datei):
|
||||
|
||||
> übernommen aus `<source>` (rohe Quelle), nicht eigenständig belegt
|
||||
|
||||
Dabei ist `<source>` der zugrunde liegende `raw/`-Pfad.
|
||||
|
||||
Die Marker stehen direkt bei der übernommenen Aussage (Absatz-/Listen-Ebene), damit die Zuordnung claim-granular bleibt. **Epic-3/4-Fähigkeiten**, die im Körper eines Concepts nur als Forward-Referenz erscheinen (noch nicht erzeugt/validiert), tragen den Forward-Referenz-Marker ebenfalls mit dem exakten Token — nicht eigenständig belegt, als Forward-Referenz übernommen (die „auf Basis von"-Angabe wird hier nur gesetzt, wenn nicht bereits aus der Kontext-/Konzeptzeile ersichtlich): „… als Forward-Referenz übernommen, nicht eigenständig belegt (raw/epics/epics-2026-08-14.md, Epic-3-Abschnitt)".
|
||||
|
||||
3. **Eindeutiges `id`-Scoping (Vertrag §3.3):** `id`-Werte in `sources`-Einträgen sind **je Concept eindeutig** (innerhalb eines Concepts darf kein `id` doppelt vorkommen). Über Concepts hinweg ist `id` nicht global eindeutig — der Adressraum ist der Concept-Pfad + `id` (AD-7a). Bei der Nachrüstung bestehender Concepts ohne `id` können `id`s deterministisch vergeben werden (`s1`, `s2`, … in Dokumentreihenfolge).
|
||||
|
||||
4. **Selbsttest-Kriterien (AD-17h, Story-2.2-Projektion):** Vor Abschluss eines Runs prüft der Producer:
|
||||
- **Belegte Aussage → Inline-`raw/`-Verweis:** Jede Aussage, die fachlich eine Evidenzstelle referenziert, trägt einen solchen Verweis mit vollem `raw/`-Pfad je Beleg (per `grep -nE '(raw/|]\(raw/'` auffindbar — erfasst auch die Markdown-Linkform).
|
||||
- **Übernahme → Kontext-Marker:** Jede Kontext-/Synthese-Umformulierung, jede Direktübernahme aus `raw/` und jede Epic-3/4-Forward-Referenz trägt einen der beiden Marker-Muster aus Pkt. 2 — beide enthalten den exakten Token „nicht eigenständig belegt".
|
||||
- **Kein unautorisierter Key:** Das Nachrüsten verändert ausschließlich den Body und die zulässigen §3.3-`sources`-Felder (`resource`, `id`, `title`, `author`, `usage_count`, `last_modified`); keine zusätzlichen Frontmatter-Felder, keine §7-Klasse (Punkt 6).
|
||||
- Wenn eine Aussage weder belegt noch als Übernahme markiert werden kann, wird sie **als Übernahme mit Marker geführt** — niemals erfunden belegt (UNBELEGTE_AUSSAGE: textuell sichtbar, Run bricht nicht ab).
|
||||
|
||||
5. **Worked Example (grammatisch verbindlich, BH-13):** Die folgende kanonische Form macht den §5.5-Standard eindeutig ablesbar. Eine **belegte Aussage** mit Inline-Verweis (voller Pfad, Fragment = im Rohdokument existierende Stellen-Kennung):
|
||||
|
||||
> Alle erzeugten Concepts sind OKF-0.2-konform (raw/epics/epics-2026-08-14.md#FR-9).
|
||||
|
||||
Eine **Übernahme mit Kontext-Marker** — Direktübernahme eines Diagramms aus einer rohen Quelle (kein Zwischen-Concept, kein Selbstverweis):
|
||||
|
||||
> Das Datenfluss-Diagramm (Interpret → Reconcile → Synthesize → Update) stammt direkt aus der rohen Quelle raw/architecture-spine/architecture-spine-2026-08-14.md#AD-5 — übernommen aus raw/architecture-spine/architecture-spine-2026-08-14.md#AD-5 (rohe Quelle), nicht eigenständig belegt.
|
||||
|
||||
Die **Diagramm-Quell-Deklaration** erfolgt zugleich frontmatter-seitig: gehört das Diagramm nicht zur `sources`-Deklaration des Concepts, wird ein zusätzlicher `sources`-Eintrag ergänzt (Pkt. 1b — Relokation/Zielwechsel, EC-1-Existenz bleibt erfüllt).
|
||||
|
||||
## 6. Validieren (mechanische Bestätigung)
|
||||
|
||||
1. Nach Abschluss aller Mutationen wird das gesamte Bundle gemäß `schema/validator.md` geprüft (§3 14 Punkte je Datei + §6-Fachprüfungen; Verdikt-Grammatik §5).
|
||||
@@ -111,7 +159,7 @@ Interpretations-Hinweis: Die „✗"-Zeilen zeigen die deterministische Fehlerur
|
||||
|
||||
Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene** begrenzt. Folgendes verbleibt in anderen Stories und wird hier **nicht** vorweggenommen:
|
||||
|
||||
- **Claim-granulare Provenienz** je belegter Aussage (Inline-`raw/`-Verweise, Kontext-Marker) → Story 2.2 (AD-4a, A0-3).
|
||||
- **Claim-granulare Provenienz** je belegter Aussage (Inline-`raw/`-Verweise, Kontext-Marker) — in **§5.5** dieser Instruktion verankert (Story 2.2; AD-4a, A0-3). Keine neue §7-Klasse, kein Standalone, keine Vertragsänderung.
|
||||
- **Deterministische Area-Zuordnung & Concept-Hierarchie** (Anlage von `wiki/<area>/index.md` + `wiki/<area>/<concept>.md`) → Story 2.4 (AD-7c, A0-10).
|
||||
- **Progressive Discovery über `index.md`** (Navigation, Area-Indizes, Suche) → Story 2.5 (AD-9, FR-11).
|
||||
- **Eine genau-eine-Linkform** (mit/ohne `.md`-Endung) → Story 2.3 (AD-7b, A0-9) — der Punkt-11-Check akzeptiert beide Schreibweisen.
|
||||
@@ -136,3 +184,5 @@ Diese Instruktion ist auf die **Erzeugung neuer Concepts auf Root-Ebene** begren
|
||||
- **Revision 1.2 (2026-08-16, Step-04-Review):** Nachschärfungen aus dem Story-2.1-Review — Input-Regel korrekt auf AD-17a statt AD-17.2 referenziert (§1); `sources`-Eintrag-Key-Subset (Innen-Ebene, Vertrag §3.3) in §4.2 und als §6.5-Kriterium-1 / §6.6-Tabellenzeile ergänzt; `status`-Absenz-Formulierung an die Vertrags-Definition (Absenz = `stable`, §3.6) angebunden (§4.4); Klarstellung Bereichs-Ziele bis Story 2.4 (§5.1/§6.6); §6.6-Fehlerursache der `verified`-Zeile auf Punkt 6 korrigiert; §6.6-Referenzlabel von §4.5 auf §4.4 korrigiert; §6.6 um vollständige Punkt-4-Pfad-Verbote ergänzt; AD-17f als Commit-Boundary in §0/§5.3/§6.6 sichtbar gemacht.
|
||||
- **Revision 1.3 (2026-08-16, bmad-code-review Story 2.1):** Nachschärfungen aus dem Review-Patch-Block — §1-Überschrift ins Deutsche („Input (was der Compiler konsumiert)"); Prüfgrundlagen-Referenz auf `validator.md` Revision 7 angeglichen (§0-Header, §8); §6.6 canonical-Key-Reihenfolge-Zeile von der ✗-Liste auf reine ✓-Vorgabe korrigiert (kein Validator-FAIL, Normalform ohne §7-Punkt) und das irreführende „§6.4"-Label auf §4.2 berichtigt; §1.2 vs. §1.4-Evidenz-Widerspruch aufgelöst (§1.2 präzisiert auf verarbeitbare Evidenz, §1.4 Artefakt-Ausnahme als dokumentarische Konvention der Source-Bereitstellung nach `raw/README.md` gekennzeichnet).
|
||||
- **Revision 1.4 (2026-08-17, bmad-code-review Re-Run Story 2.1, Stand nach Validator-Rev-8):** Nachschärfungen aus dem unabhängigen Re-Review — Prüfgrundlagen-Referenz auf `validator.md` Revision 8 angehoben (§0-Header, §8); §6.6-Referenzlabels berichtigt (canonical Key-Reihenfolge, Duplikat-Keys, `okf_version`/`type: bundle` → §4.5, `sources`-Eintrag-Key-Subset → §4.2; berichtigt die Rev-1.2-Korrektur, die das Label fälschlich von §4.5 auf §4.4 bewegt hatte); §1.4 „Aufträge" → „Formate", §5.2 „grossen" → „großen"; §3.2 Kollision-Hold um Run-Fortsetzung mit den übrigen Einheiten und Gesamt-Run-Status („teilweise erfolgreich") ergänzt; §5.3/§6.3 um explizite Rollback-Sequenz für den Teilzustand (Concept-Datei + Index-Verlinkung + `log.md`-Eintrag) bei Validierungs-FAIL ergänzt.
|
||||
- **Revision 1.5 (2026-08-17, Story 2.2):** Sektion „Claim-granulare Provenienz" als §5.5 eingefügt (nach §5, vor §6) — Inline-`raw/`-Verweis je belegter Aussage (+ `id`-Attribution, Vertrag §3.3), Kontext-Marker je Übernahme („übernommen aus … auf Basis von …, nicht eigenständig belegt"), eindeutiges `id`-Scoping je Concept, Selbsttest-Kriterien (belegte Aussage → Verweis; Übernahme → Marker; kein unautorisierter Key; UNBELEGTE_AUSSAGE als Marker statt erfundener Beleg) — AD-4a/4b/4c, AD-13, AD-17h. §7-Selbstbegrenzung entsprechend umformuliert (Claim-granulare Provenienz jetzt in §5.5 verankert, nicht mehr deklariert als „verbleibt in Story 2.2"). Keine Änderung an `wiki-compiler.md`/`validator.md`/`raw/`; kein Standalone (D-3); keine Vertragsänderung.
|
||||
- **Revision 1.6 (2026-08-17, Story-2.2-Re-Review, Patch-Runde):** §5.5-Klarstellungen aus dem Review — (1) „kein Frontmatter-Change"-Widerspruch aufgelöst: Konvention fügt kein neues Feld über §3.3 hinaus hinzu, während das Hinzufügen/Erweitern von `sources`-Einträgen (`resource`/`id`, Relokation/Zielwechsel) ausdrücklich Teil der Konvention ist; (2) Inline-Verweis-Form präzisiert: Fragment = im Rohdokument existierende Stellen-Kennung (Bezeichner-`id` oder Sektionstitel), Concept-eigene `sources`-`id` (`s1`, …) ist NICHT als Fragment zu verwenden; voller `raw/`-Pfad je Beleg, keine Pfad-Elision; die Selbsttest-Formel auf `grep -nE '(raw/|]\(raw/'` erweitert; (3) Kontext-Marker um Direktübernahme-Fall „übernommen aus `<source>` (rohe Quelle)" ergänzt, Selbstreferenz-Muster verboten; (4) Forward-Referenz-Wortlaut an den exakten Token „nicht eigenständig belegt" gebunden; (5) Worked Example (belegte Aussage + Diagramm-Direktübernahme + Diagramm-Quell-Deklaration, BH-13) ergänzt. Keine Änderung an `wiki-compiler.md`/`validator.md`/`raw/`; kein Standalone (D-3); keine Vertragsänderung.
|
||||
|
||||
+2
-2
@@ -27,7 +27,7 @@ wiki/
|
||||
Die folgenden Root-Concepts wurden im ersten Demonstrationslauf (Story 2.1) aus dem Source Material unter `raw/` erzeugt:
|
||||
|
||||
- [LLM-Wiki-Prinzip](llm-wiki-prinzip.md) — konzeptioneller Anker: Rohquellen werden von einem LLM in ein persistentes, kuratiertes Wiki überführt (aus `raw/prd/prd-wow20-2026-08-14.md`).
|
||||
- [Knowledge Compilation & Inkrementelle Evolution](knowledge-kompilation-inkrementell.md) — inkrementeller Datenfluss Interpret → Reconcile → Synthesize → Update (aus `raw/epics/epics-2026-08-14.md`).
|
||||
- [Wissensarchitektur: Source Material, Curated Knowledge & Consumer](wissensarchitektur-trennung-states.md) — die Architekturgrenzen `raw/` (immutable Evidenz) und `wiki/` (kuratiertes Bundle) (aus `raw/architecture-spine/architecture-spine-2026-08-14.md`).
|
||||
- [Knowledge Compilation & Inkrementelle Evolution](knowledge-kompilation-inkrementell.md) — inkrementeller Datenfluss Interpret → Reconcile → Synthesize → Update (aus `raw/epics/epics-2026-08-14.md`; Datenfluss-Diagramm aus `raw/architecture-spine/architecture-spine-2026-08-14.md`).
|
||||
- [Wissensarchitektur: Source Material, Curated Knowledge & Consumer](wissensarchitektur-trennung-states.md) — die Architekturgrenzen `raw/` (immutable Evidenz) und `wiki/` (kuratiertes Bundle) (aus `raw/architecture-spine/architecture-spine-2026-08-14.md`; Separation of Concerns aus `raw/prd/prd-wow20-2026-08-14.md`).
|
||||
|
||||
Der Workspace umfasst außerdem: `raw/` (immutable Source Material/Evidenz, AD-2/AD-3), `schema/` (drei Artefakte: Schema-Vertrag [`wiki-compiler.md`](../schema/wiki-compiler.md) (autorisiert, AD-1), Validator [`validator.md`](../schema/validator.md) (Story 1.4) und Compiler-Instruktion [`compiler.md`](../schema/compiler.md) (Story 2.1)) und `adapters/` (dünne Agenten-Adapter, AD-10).
|
||||
|
||||
@@ -2,6 +2,9 @@
|
||||
type: concept
|
||||
sources:
|
||||
- resource: raw/epics/epics-2026-08-14.md
|
||||
id: s1
|
||||
- resource: raw/architecture-spine/architecture-spine-2026-08-14.md
|
||||
id: s2
|
||||
generated:
|
||||
by: wow-compiler/0.1.0
|
||||
at: 2026-08-16T09:23:33Z
|
||||
@@ -9,11 +12,11 @@ generated:
|
||||
|
||||
# Knowledge Compilation & Inkrementelle Evolution
|
||||
|
||||
Wiki of Wikis ist ein inkrementeller Knowledge Compiler: Er verarbeitet Sources gegen das bestehende kuratierte Wissen und entwickelt das Knowledge Bundle fortlaufend weiter, statt es bei jedem Lauf vollständig neu zu erzeugen.
|
||||
Wiki of Wikis ist ein inkrementeller Knowledge Compiler: Er verarbeitet Sources gegen das bestehende kuratierte Wissen und entwickelt das Knowledge Bundle fortlaufend weiter, statt es bei jedem Lauf vollständig neu zu erzeugen (raw/epics/epics-2026-08-14.md#FR-12; raw/epics/epics-2026-08-14.md#A0-6).
|
||||
|
||||
## Grundprinzip des Datenflusses
|
||||
|
||||
Jeder Compilation Run beginnt mit dem aktuell vorhandenen Knowledge Bundle und verändert nur die durch neue Erkenntnisse betroffenen Concepts (AD-5). Der logische Datenfluss lautet:
|
||||
Jeder Compilation Run beginnt mit dem aktuell vorhandenen Knowledge Bundle und verändert nur die durch neue Erkenntnisse betroffenen Concepts (raw/epics/epics-2026-08-14.md#A0-6; raw/architecture-spine/architecture-spine-2026-08-14.md#AD-5). Der logische Datenfluss lautet:
|
||||
|
||||
```text
|
||||
Existing Knowledge
|
||||
@@ -29,19 +32,21 @@ Synthesize
|
||||
Update affected Concepts
|
||||
```
|
||||
|
||||
Ausdrücklich nicht verwendet wird ein „Regenerate Everything"-Ansatz, bei dem alle Sources und das komplette Wiki bei jedem Lauf neu erzeugt würden — das würde den Compounding-Effekt des Wissens zerstören.
|
||||
Ausdrücklich nicht verwendet wird ein „Regenerate Everything"-Ansatz, bei dem alle Sources und das komplette Wiki bei jedem Lauf neu erzeugt würden — das würde den Compounding-Effekt des Wissens zerstören (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-5).
|
||||
|
||||
Das Diagramm des Datenflusses (Existing Knowledge + New Source Material → Interpret → Reconcile → Synthesize → Update affected Concepts) stammt direkt aus der rohen Quelle `raw/architecture-spine/architecture-spine-2026-08-14.md#AD-5` — übernommen aus `raw/architecture-spine/architecture-spine-2026-08-14.md#AD-5` (rohe Quelle), nicht eigenständig belegt.
|
||||
|
||||
## Folgen für die Fähigkeiten
|
||||
|
||||
- **Inkrementelle Evolution (FR-12):** Unverändertes Wissen bleibt erhalten; Änderungen konzentrieren sich auf durch neue Erkenntnisse betroffene Concepts.
|
||||
- **Aktualisierung statt neuer Dateien (FR-6):** Neue Informationen führen nicht automatisch zu neuen Dateien — bestehendes Wissen wird erweitert, präzisiert oder korrigiert.
|
||||
- **Konsistenz bei Fehlern (AD-6):** Analyse, Änderungsplanung, Mutation und Validierung sind logisch getrennt; ein teilweise fehlgeschlagener Run hinterlässt kein inkonsistentes Bundle.
|
||||
- **Nachvollziehbarkeit (FR-14):** Änderungen erfolgen an textuellen Artefakten und sind über normale Versionskontrolle (Git-Diff) nachvollziehbar.
|
||||
- **Inkrementelle Evolution (FR-12):** Unverändertes Wissen bleibt erhalten; Änderungen konzentrieren sich auf durch neue Erkenntnisse betroffene Concepts (raw/epics/epics-2026-08-14.md#FR-12).
|
||||
- **Aktualisierung statt neuer Dateien (FR-6):** Neue Informationen führen nicht automatisch zu neuen Dateien — bestehendes Wissen wird erweitert, präzisiert oder korrigiert (raw/epics/epics-2026-08-14.md#FR-6).
|
||||
- **Konsistenz bei Fehlern (AD-6):** Analyse, Änderungsplanung, Mutation und Validierung sind logisch getrennt; ein teilweise fehlgeschlagener Run hinterlässt kein inkonsistentes Bundle (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-6; raw/epics/epics-2026-08-14.md#A0-7).
|
||||
- **Nachvollziehbarkeit (FR-14):** Änderungen erfolgen an textuellen Artefakten und sind über normale Versionskontrolle (Git-Diff) nachvollziehbar (raw/epics/epics-2026-08-14.md#FR-14).
|
||||
|
||||
## Verbindung zu Regelwerken
|
||||
|
||||
Die Inhaltsklassifikation vor jeder Änderung (NEW / CONFIRMING / CORRECTING / CONTRADICTING / REDUNDANT) und die deterministische Relevanzbestimmung per textueller, deterministischer Mittel (grep/ripgrep, Markdown-Traversal, Link-Following) sind Teil der inkrementellen Kompilation.
|
||||
Die Inhaltsklassifikation vor jeder Änderung (NEW / CONFIRMING / CORRECTING / CONTRADICTING / REDUNDANT) (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-16; raw/epics/epics-2026-08-14.md#A0-11) und die deterministische Relevanzbestimmung per textueller, deterministischer Mittel (grep/ripgrep, Markdown-Traversal, Link-Following) sind Teil der inkrementellen Kompilation (raw/epics/epics-2026-08-14.md#A0-18; raw/architecture-spine/architecture-spine-2026-08-14.md#AD-13).
|
||||
|
||||
## Abgrenzung
|
||||
|
||||
Die inkrementelle Kompilation (Interpret → Reconcile → Synthesize → Update) ist die Grundlage von Epic 3. Epic 2 liefert dafür die Voraussetzungen: Concepts, Verlinkung und Area-Hierarchie.
|
||||
Die inkrementelle Kompilation (Interpret → Reconcile → Synthesize → Update) ist die Grundlage von Epic 3. Epic 2 liefert dafür die Voraussetzungen: Concepts, Verlinkung und Area-Hierarchie — als Forward-Referenz übernommen, nicht eigenständig belegt (raw/epics/epics-2026-08-14.md, Epic-3-Abschnitt).
|
||||
|
||||
@@ -2,6 +2,7 @@
|
||||
type: concept
|
||||
sources:
|
||||
- resource: raw/prd/prd-wow20-2026-08-14.md
|
||||
id: s1
|
||||
generated:
|
||||
by: wow-compiler/0.1.0
|
||||
at: 2026-08-16T09:23:33Z
|
||||
@@ -9,15 +10,15 @@ generated:
|
||||
|
||||
# LLM-Wiki-Prinzip
|
||||
|
||||
Das LLM-Wiki-Prinzip ist der konzeptionelle Anker von Wiki of Wikis. Es beschreibt, wie Rohquellen durch ein LLM schrittweise in ein persistentes, kuratiertes Wiki überführt werden — statt bei jeder Anfrage erneut nach Rohdokumenten zu suchen und sie neu zu interpretieren.
|
||||
Das LLM-Wiki-Prinzip ist der konzeptionelle Anker von Wiki of Wikis. Es beschreibt, wie Rohquellen durch ein LLM schrittweise in ein persistentes, kuratiertes Wiki überführt werden — statt bei jeder Anfrage erneut nach Rohdokumenten zu suchen und sie neu zu interpretieren (raw/prd/prd-wow20-2026-08-14.md, § 0 Document Purpose).
|
||||
|
||||
## Kernidee: Knowledge should compound
|
||||
|
||||
Das zentrale Produktversprechen lautet: **Knowledge should compound.** Einmal erarbeitete Synthese wird dauerhaft in einem kuratierten Wiki abgelegt und muss bei späteren Anfragen nicht erneut aus den Rohquellen rekonstruiert werden. Das Wiki entwickelt sich mit neuen Quellen weiter und bildet das bereits erarbeitete Wissen fortlaufend ab.
|
||||
Das zentrale Produktversprechen lautet: **Knowledge should compound.** Einmal erarbeitete Synthese wird dauerhaft in einem kuratierten Wiki abgelegt und muss bei späteren Anfragen nicht erneut aus den Rohquellen rekonstruiert werden. Das Wiki entwickelt sich mit neuen Quellen weiter und bildet das bereits erarbeitete Wissen fortlaufend ab (raw/prd/prd-wow20-2026-08-14.md, § 1 Vision).
|
||||
|
||||
## Positionierung: Knowledge Compiler statt Retrieval-System
|
||||
|
||||
Wiki of Wikis ist primär ein **Knowledge Compiler**, kein Retrieval-System. Es sammelt und indiziert nicht nur Dokumente, sondern verarbeitet Quellen aktiv: lesen, verstehen, in Beziehung setzen und eigenständige Wissensartikel erzeugen. Neue Quellen werden gegen das vorhandene Wiki verarbeitet; vorhandenes Wissen kann dadurch bestätigt, erweitert, präzisiert oder korrigiert werden.
|
||||
Wiki of Wikis ist primär ein **Knowledge Compiler**, kein Retrieval-System. Es sammelt und indiziert nicht nur Dokumente, sondern verarbeitet Quellen aktiv: lesen, verstehen, in Beziehung setzen und eigenständige Wissensartikel erzeugen. Neue Quellen werden gegen das vorhandene Wiki verarbeitet; vorhandenes Wissen kann dadurch bestätigt, erweitert, präzisiert oder korrigiert werden (raw/prd/prd-wow20-2026-08-14.md, § 1 Vision).
|
||||
|
||||
## Datenfluss
|
||||
|
||||
@@ -34,8 +35,10 @@ Curated OKF Wiki
|
||||
Humans / LLM Agents / BMAD / Coding Agents / other Consumers
|
||||
```
|
||||
|
||||
Das Ergebnis ist ein einfaches, portables Knowledge Bundle aus Markdown-Dateien, das weder eine spezielle Datenbank noch eine proprietäre Knowledge-Plattform benötigt.
|
||||
Das Ergebnis ist ein einfaches, portables Knowledge Bundle aus Markdown-Dateien, das weder eine spezielle Datenbank noch eine proprietäre Knowledge-Plattform benötigt (raw/prd/prd-wow20-2026-08-14.md, § 1 Vision).
|
||||
|
||||
Das Datenfluss-Diagramm (Sources → LLM Wiki Compiler → Curated OKF Wiki → Humans / LLM Agents / BMAD / Coding Agents / other Consumers) stammt direkt aus der rohen Quelle `raw/prd/prd-wow20-2026-08-14.md` (§ 0 Document Purpose) — übernommen aus `raw/prd/prd-wow20-2026-08-14.md` (rohe Quelle), nicht eigenständig belegt.
|
||||
|
||||
## Abgrenzung
|
||||
|
||||
Retrieval (Suche, RAG, Graph-Traversal) ist ausdrücklich nicht Bestandteil des Produktkerns. Ein Consumer kann solche Verfahren später über dem Knowledge Bundle einsetzen — sie gehören jedoch nicht zu Wiki of Wikis selbst.
|
||||
Retrieval (Suche, RAG, Graph-Traversal) ist ausdrücklich nicht Bestandteil des Produktkerns. Ein Consumer kann solche Verfahren später über dem Knowledge Bundle einsetzen — sie gehören jedoch nicht zu Wiki of Wikis selbst (raw/prd/prd-wow20-2026-08-14.md, § 5 Non-Goals).
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
# Log
|
||||
|
||||
## 2026-08-17
|
||||
- **Story 2.2 «Claim-granulare Provenienz dokumentieren» — Nachrüstung (Datei-Bodies, `index.md`, `log.md`):** `schema/compiler.md` um §5.5 „Claim-granulare Provenienz" erweitert (nach §5, vor §6): Inline-`raw/`-Verweis je belegter Aussage + `id`-Attribution (Vertrag §3.3), Kontext-Marker je Übernahme (übernommen aus `<raw-Quelle>` (rohe Quelle) bzw. übernommen aus `<Concept>` auf Basis von `<raw-Quelle>`, jeweils „nicht eigenständig belegt"), eindeutiges `id`-Scoping je Concept, Selbsttest-Kriterien (AD-4a/4c, AD-13, AD-17h); Revisionslog (§8) → Revision 1.5 (Nachrüstung) bzw. 1.6 (Review-Patch-Runde: Stellen-Kennungs-Semantik, volle Pfade, Direktübernahme-Marker, worked example, korrigierte Grep-Formel), §7-Selbstbegrenzung entsprechend angepasst. `wiki/index.md` (Descriptions um `(aus <raw-Pfad>)`), `wiki/knowledge-kompilation-inkrementell.md`, `wiki/llm-wiki-prinzip.md`, `wiki/wissensarchitektur-trennung-states.md` nachkonformiert — jede belegte Aussage trägt Inline-Verweis; Übernahmen tragen Kontext-Marker (keine Selbstreferenz, keine Concept-`id`-Fragmente `#s1`/`#s2`). **Diagramm-Quell-Deklaration:** Das ASCII-Diagramm in `wiki/knowledge-kompilation-inkrementell.md` (Datenfluss) stammt aus `raw/architecture-spine/architecture-spine-2026-08-14.md#AD-5` — zusätzlicher `sources`-Eintrag (`id: s2`) ergänzt; das Diagramm in `wiki/wissensarchitektur-trennung-states.md` (Sources → Compilation → Knowledge Bundle → Consumers) aus `raw/prd/prd-wow20-2026-08-14.md` (§ 8.3 Separation of Concerns) — zusätzlicher `sources`-Eintrag (`id: s2`) ergänzt. `sources`-`id` je Concept eindeutig; keine unautorisierten Keys. `wiki-compiler.md`/`validator.md`/`raw/` unverändert. Validator-Lauf: alle 5 `wiki/`-Dateien SUCCESS (Punkte 1/6/11/14, EC-1) — Story 2.2 `in-progress`.
|
||||
- **Story 2.1 «Concepts aus Source Material erzeugen (OKF-Konform)» → `done` (Human-Review-Freigabe erteilt):** Nutzer hat die verbleibende Schwelle (menschliche Review-Freigabe) überschritten — Status `review` → `done`, `sprint-status.yaml` nachgeführt. Alle 8 ACs PASS, kein AC-/Vertrags-Blocker; offene Folge-Arbeit (autorisierte Validator-Rev 9) ist kein Story-2.1-Blocker und bleibt als Action-Item `code-review-2-1-item-2` in `deferred-work.md` verankert.
|
||||
- bmad-code-review Re-Run Story 2.1 (unabhängig, 4 Layer, Stand nach Validator-Rev-8): alle 8 ACs PASS, 17 Patch / 4 Defer / 2 Dismiss. 15 Patches umgesetzt — `schema/compiler.md` → Revision 1.4 (Prüfgrundlage Rev 8, §6.6-Referenzlabels §4.5/§4.2, §3.2 Kollision-Hold-Run-Fortsetzung, §5.3/§6.3 Rollback-Sequenz, Sprachkorrekturen), `wiki/log.md` (verlorener Bullet, Rev-8-Datum 08-17), `wiki/index.md` (Baumdiagramm um Root-Concepts-Ebene), Doku-/Referenz-Konsistenz (`deferred-work.md` Dedupe + n=21, `review-input-dryrun-…md` 16+2-Auflösung, `epic-2-context.md` AD-4c tautologisch, spec Verification/Change-Log, `sprint-status.yaml` closed-Datum). 2 Patches auf der gefrorenen `validator.md` (Rev 8) geholdert → nächste autorisierte Validator-Revision (Rev 9: Punkt-4-Grammatik `resolved=`-Token, Innen-Ebenen-Punkt-6-Fixture-Zeile; s. `deferred-work.md`).
|
||||
- **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`.
|
||||
|
||||
@@ -2,6 +2,9 @@
|
||||
type: concept
|
||||
sources:
|
||||
- resource: raw/architecture-spine/architecture-spine-2026-08-14.md
|
||||
id: s1
|
||||
- resource: raw/prd/prd-wow20-2026-08-14.md
|
||||
id: s2
|
||||
generated:
|
||||
by: wow-compiler/0.1.0
|
||||
at: 2026-08-16T09:23:33Z
|
||||
@@ -9,14 +12,14 @@ generated:
|
||||
|
||||
# Wissensarchitektur: Source Material, Curated Knowledge & Consumer
|
||||
|
||||
Die Architektur von Wiki of Wikis trennt drei Verantwortungsbereiche, die nie vermischt werden dürfen: Quellen, Kompilation und kuratiertes Wissen mit seinen Konsumenten (AD-2, AD-3, AD-1).
|
||||
Die Architektur von Wiki of Wikis trennt drei Verantwortungsbereiche, die nie vermischt werden dürfen: Quellen, Kompilation und kuratiertes Wissen mit seinen Konsumenten (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-2, #AD-3, #AD-1; raw/prd/prd-wow20-2026-08-14.md, § 8.3 Separation of Concerns).
|
||||
|
||||
## Die Architekturgrenzen `raw/` und `wiki/`
|
||||
|
||||
- **`raw/` — immutable Source Material/Evidenz:** Jede Datei unter `raw/` ist Evidenz. Ein Compilation Run darf bestehendes Source Material niemals verändern (AD-3); neue Versionen einer Source werden als neue beziehungsweise versionierte Source behandelt.
|
||||
- **`wiki/` — kuratiertes OKF Knowledge Bundle:** Jede Datei unter `wiki/` ist eine aus Evidenz abgeleitete Wissensrepräsentation. Das Bundle ist der kanonische persistente Zustand des Systems (AD-1).
|
||||
- **`raw/` — immutable Source Material/Evidenz:** Jede Datei unter `raw/` ist Evidenz. Ein Compilation Run darf bestehendes Source Material niemals verändern (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-3); neue Versionen einer Source werden als neue beziehungsweise versionierte Source behandelt (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-3).
|
||||
- **`wiki/` — kuratiertes OKF Knowledge Bundle:** Jede Datei unter `wiki/` ist eine aus Evidenz abgeleitete Wissensrepräsentation. Das Bundle ist der kanonische persistente Zustand des Systems (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-1; raw/prd/prd-wow20-2026-08-14.md, § 8.2 Plain Files as Canonical State).
|
||||
|
||||
Das bloße Kopieren eines Source-Dokuments nach `wiki/` ist keine Kompilation.
|
||||
Das bloße Kopieren eines Source-Dokuments nach `wiki/` ist keine Kompilation (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-2; raw/prd/prd-wow20-2026-08-14.md, § 8.3 Separation of Concerns).
|
||||
|
||||
## Separation of Concerns
|
||||
|
||||
@@ -24,21 +27,23 @@ Das bloße Kopieren eines Source-Dokuments nach `wiki/` ist keine Kompilation.
|
||||
Sources → Compilation → Knowledge Bundle → Consumers
|
||||
```
|
||||
|
||||
- Eine Source darf nicht automatisch Teil des Curated Knowledge werden.
|
||||
- Ein Consumer darf nicht zur Voraussetzung für Kompilation oder Speicherung werden.
|
||||
- Der Compiler ist ein Producer des Bundle-Artefakts — kein Wissensserver und keine eigene Agent-Runtime (AD-11).
|
||||
> Das Diagramm (Sources → Compilation → Knowledge Bundle → Consumers) stammt direkt aus der rohen Quelle `raw/prd/prd-wow20-2026-08-14.md` (§ 8.3 Separation of Concerns) — übernommen aus `raw/prd/prd-wow20-2026-08-14.md` (rohe Quelle), nicht eigenständig belegt.
|
||||
|
||||
- Eine Source darf nicht automatisch Teil des Curated Knowledge werden (raw/prd/prd-wow20-2026-08-14.md, § 8.3 Separation of Concerns).
|
||||
- Ein Consumer darf nicht zur Voraussetzung für Kompilation oder Speicherung werden (raw/prd/prd-wow20-2026-08-14.md, § 8.3 Separation of Concerns).
|
||||
- Der Compiler ist ein Producer des Bundle-Artefakts — kein Wissensserver und keine eigene Agent-Runtime (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-11).
|
||||
|
||||
## Consumer-Unabhängigkeit
|
||||
|
||||
Das Knowledge Bundle ist nicht auf einen bestimmten LLM-Agenten oder Workflow zugeschnitten (FR-16). Menschen lesen es mit normalen Markdown-Werkzeugen; Agenten wie BMAD, Claude Code oder Codex über Standard-Dateioperationen. Ein Wechsel des Consumers erfordert keine Migration des Wissensformats.
|
||||
Das Knowledge Bundle ist nicht auf einen bestimmten LLM-Agenten oder Workflow zugeschnitten (raw/prd/prd-wow20-2026-08-14.md, § 4.5 FR-16). Menschen lesen es mit normalen Markdown-Werkzeugen; Agenten wie BMAD, Claude Code oder Codex über Standard-Dateioperationen. Ein Wechsel des Consumers erfordert keine Migration des Wissensformats (raw/prd/prd-wow20-2026-08-14.md, § 4.5 FR-16).
|
||||
|
||||
Retrieval (Search, RAG, Graph-Traversal) ist Consumer-Verhalten, nicht Kern des Compilers (AD-13).
|
||||
Retrieval (Search, RAG, Graph-Traversal) ist Consumer-Verhalten, nicht Kern des Compilers (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-13; raw/prd/prd-wow20-2026-08-14.md, § 5 Non-Goals).
|
||||
|
||||
## Konvergenzregeln
|
||||
|
||||
| Betrachtet | Quelle |
|
||||
|---|---|
|
||||
| Canonical evidence | `raw/` bzw. referenzierte externe Source |
|
||||
| Canonical knowledge | `wiki/` |
|
||||
| Discovery | Hierarchie + `index.md` |
|
||||
| Update history | Git + optional OKF `log.md` |
|
||||
| Canonical evidence | `raw/` bzw. referenzierte externe Source (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-4b) |
|
||||
| Canonical knowledge | `wiki/` (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-1) |
|
||||
| Discovery | Hierarchie + `index.md` (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-9) |
|
||||
| Update history | Git + optional OKF `log.md` (raw/architecture-spine/architecture-spine-2026-08-14.md#AD-14) |
|
||||
|
||||
Reference in New Issue
Block a user