feat: Story 2.2 Claim-granulare Provenienz dokumentieren (Review fertig)

schema/compiler.md §5.5 als Beweis-Konvention (Inline-raw-Verweise je belegter
Aussage, Kontext-Marker je Uebernahme, id-Scoping §3.3, worked example);
Revision 1.5/1.6. 3 Concept-Bodies nachkonformiert (Diagramm-Quellen als
sources-Eintraege deklariert, keine Selbstreferenz, volle raw-Pfade).
index.md/log.md nachgefuehrt; sprint-status Story 2.2 -> review.
Review 3 Layer: 7 patch + 1 defer (sources-Closure) verankert;
spec -> done inkl. Suggested Review Order. Keine raw/-/Vertrag-Mutation.

Co-Authored-By: Claude <noreply@anthropic.com>

schema/compiler.md

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