wow20/_bmad-output/implementation-artifacts/epic-2-context.md

# Epic 2 Context: OKF-Concepts erzeugen & verlinken

<!-- Compiled from planning artifacts. Edit freely. Regenerate with compile-epic-context if planning docs change. -->

## Goal

Aus dem lokal bereitgestellten Source Material (Epic 1) entstehen eigenständige, OKF-0.2-konforme Concepts: neue kuratierte Wissenseinheiten, die nicht an die Struktur der Quelle gebunden sind. Jede belegte Aussage trägt claim-granulare Provenienz auf `raw/`-Evidenz; maschinell erzeugte Concepts tragen die v1-Trust-Metadaten (`generated` ohne `verified`). Concepts werden über genau eine erlaubte Markdown-Linkform (AD-7b) miteinander verlinkt, per deterministischer Bereichszuordnung (AD-7c) in eine Bundle-Hierarchie eingeordnet und über `index.md` progressiv entdeckbar — ohne proprietäre Datenbank.

## Stories

- Story 2.1: Concepts aus Source Material erzeugen (OKF-konform)
- Story 2.2: Claim-granulare Provenienz dokumentieren
- Story 2.3: Concepts verlinken (eine erlaubte Linkform)
- Story 2.4: Deterministische Bereichszuordnung & Concept-Hierarchie
- Story 2.5: Progressive Discovery über `index.md` bereitstellen

## Requirements & Constraints

- Concepts werden anhand erkannter Wissenseinheiten erzeugt, nicht 1:1 pro Source-Abschnitt; mehrere Abschnitte einer Source können in verschiedene Concepts fließen. Concepts sind eigenständiges kuratiertes Wissen, keine Kopie oder Zusammenfassung des Quelldokuments (FR-5).
- Jedes erzeugte Concept ist OKF-0.2-konform: Markdown mit YAML-Frontmatter, `type` als einziges Pflichtfeld; optional `sources`, `generated`, `verified`, `status`, `stale_after`. Das zulässige Feldsubset und seine Validität bindet `schema/wiki-compiler.md` (AD-1a). Kein eigener OKF-Dialekt.
- Provenienz ist claim-granular: jede belegte Aussage trägt einen Inline-Verweis auf `raw/`-Evidenz; Kontext-/Synthese-Umformulierungen tragen einen expliziten Kontext-Marker ("übernommen aus `<Concept>` auf Basis von `<source>`, nicht eigenständig belegt") (AD-4a, A0-3).
- `sources`-Einträge lösen ausschließlich auf `raw/`-Pfade oder extern referenzierte immutable Evidenz auf — nie auf `wiki/`-Concept-Pfade (AD-4b, A0-4).
- Es muss wirkungsvoll verhindert werden, dass generierte Concepts als eigene Evidenz verwendet werden: kein generiertes Concept darf ein anderes generiertes Concept als alleinige Provenienz führen — prüfbar über die Schema-Validierung (AD-4c, A0-5).
- Beziehungen zwischen Concepts werden als normale Markdown-Links ausgedrückt — in genau einer erlaubten Form: bundle-relativ, mit oder ohne Endung, nie beides (FR-10, AD-7b, A0-9). Links sind die Navigations-/Beziehungsschicht, nicht die Provenienz; keine proprietäre Link-Datenbank, herkömmliche Markdown-Tools müssen den Link auflösen können (AD-8).
- Bereichszuordnung ist textual-deterministisch zu bestimmen (bestehender `index.md`-Link oder Top-Level-Kollisions-Hold auf bestehende Pfade), nie per Embedding/Vector-Infrastruktur (AD-7c, A0-10, AD-13).
- Concepts bleiben unmittelbar menschlich lesbares Markdown und für LLM-Agenten über Standard-Dateioperationen erschließbar; unvollständiges, ungeprüftes Wissen wird ohne künstliche Gewissheit dargestellt (NFR-2, NFR-3, NFR-7).

## Technical Decisions

- **Concept-Identität (AD-7a, A0-8):** Identität ist der relative OKF-Pfad ohne `.md`-Endung (`wiki/spring/index.md` → `spring`); genau eine kanonische ID-Normalisierung für alle Producer. Renames sind semantische Änderungen und erfordern einen Redirect-/Deprecation-Eintrag in `log.md`, damit alte IDs maschinell auffindbar bleiben (AD-7d).
- **Linkform ist gepinnt (AD-7b):** exakt eine Form (bundle-relativ, mit oder ohne Endung) — verhindert, dass zwei Producer aus demselben Baum unterschiedliche IDs berechnen. Der Link-Bestand ist die Navigationsschicht; eine spätere Graph-Ableitung ist optional und nie kanonisch (AD-8).
- **Provenienzmodell (AD-4a..c):** Inline-`raw/`-Verweise pro Aussage plus Kontext-Marker für Übernahmen; `sources` zeigen nie auf `wiki/`; die "keine abgeleitete Provenienz"-Regel ist Teil der `schema/wiki-compiler.md`-Validierung.
- **Hierarchie & Discovery (AD-9, AD-1):** `wiki/` ist Bundleroot; Areas folgen `<area>/index.md` + `<concept>.md`. Discovery läuft Bundle-Root `index.md` → Area-`index.md` → Concepts; ein neu angelegtes Concept wird im `index.md` seines Bereichs verlinkt. Search ist optionale, spätere, Consumer-seitige Optimierung; das Bundle bleibt ohne geladene Indizes (z.B. nach Git-Clone) vollständig verständlich.
- **Trust-Metadaten v1 (AD-15, A0-20):** maschinell erzeugte Concepts erhalten `generated: { by, at }`, `verified` bleibt ungesetzt; Lifecycle optional über `status` (`draft` | `stable` | `deprecated`) und `stale_after`.
- **Kein Server, keine Datenbank:** alle erzeugten Artefakte sind normale textuelle Dateien im Git-Workspace; jede Änderung bleibt über Git-Diff nachvollziehbar (AD-1, AD-11, AD-14).

## Cross-Story Dependencies

- Setzt Workspace-Trennung, Bundle-Root und das OCKF-Feldsubset aus Epic 1 (Story 1.1, 1.3, 1.4) voraus. AD-4c (keine abgeleitete Provenienz) ist in v1 tautologisch erfüllt — `sources` zeigt ausschließlich auf `raw/`, daher kann kein generiertes Concept ein anderes generiertes Concept als alleinige Provenienz führen (Vertrag §6.1: erzeugt **kein** eigenes Validitätsprädikat; kein eigener Validator-Check).
- Die hier erzeugten Concepts, Links und `index.md`-Strukturen sind die Eingabe für die inkrementelle Kompilation und Synthese (Epic 3) sowie für Widerspruchs- und Kuratierungs-Kontexte (Epic 4).
- Identität und Verlinkung dieses Epics werden von den Consumers in Epic 5 unverändert gelesen.
- Keine UX-/Design-Anteile relevant für diesen Epic: v1 ist datei-/CLI-basiert ohne GUI (A-3, AD-11).