feat: Sources lokal unter raw/ materialisieren (Story 1.2)
- PRD, Architecture-Spine und epics als erste Evidenz-Sources unter raw/ materialisiert (Per-Quelle-Verzeichnis + source.md Provenienz-Sidecar) - raw/README um Quellen-Konvention erweitert (Benennung, additive Versionierung AD-3, Artefakt-Carve-out, lokale statt URL-Fetches) - sprint-status.yaml: Story 1.2 auf review gesetzt Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Michael Tamse
@@ -0,0 +1,19 @@
|
|||||||
|
# Deferred Work
|
||||||
|
|
||||||
|
Noch nicht adressierte, aber real erkannte Arbeit — gesammelt aus Reviews. Einträge werden append-only ergänzt; bestehende Einträge werden nicht verändert.
|
||||||
|
|
||||||
|
- source_spec: `_bmad-output/implementation-artifacts/spec-1-2-sources-lokal-unter-raw-bereitstellen.md`
|
||||||
|
summary: Checksum-/Fingerprint (SHA-256) der evtl. Git-Revision der Herkunftsquelle in `source.md` aufnehmen, damit die Provenienz reproduzierbar ist.
|
||||||
|
evidence: Blind-Hunter-Review (Finding 1/2): `source.md`-Provenienz ist ohne Fingerprint der Quelle in einem reinen Clone nicht verifizierbar; AD-3-basiertes „neue, datierte Datei"-Schema braucht einen Maschinen-Lesbaren Stand.
|
||||||
|
|
||||||
|
- source_spec: `_bmad-output/implementation-artifacts/spec-1-2-sources-lokal-unter-raw-bereitstellen.md`
|
||||||
|
summary: Maschinen-lesbares, validierbares Metadaten-Schema (YAML-frontmatter) für `source.md` einführen.
|
||||||
|
evidence: Blind-Hunter-Review (Finding 13): Dokumentstand ist nur Prosa; ein späterer Ingestion-/Validierungsschritt (Story 1.3/1.4) kann ihn nicht prüfen.
|
||||||
|
|
||||||
|
- source_spec: `_bmad-output/implementation-artifacts/spec-1-2-sources-lokal-unter-raw-bereitstellen.md`
|
||||||
|
summary: Definition für die URL-Rückweisung operationalisieren (Fehlerartefakt/Exit-Code/Log), damit Story 1.2 AC-4 testbar wird.
|
||||||
|
evidence: Blind-Hunter-Review (Finding 17): „URL wird zurückgewiesen" ist im Source Material nur als Prosa beschrieben; kein testbares Verhalten abgelegt.
|
||||||
|
|
||||||
|
- source_spec: `_bmad-output/implementation-artifacts/spec-1-2-sources-lokal-unter-raw-bereitstellen.md`
|
||||||
|
summary: Asset-Zuordnung (roh-`assets/` vs. `<quelle>/assets/`) in der Konvention festlegen.
|
||||||
|
evidence: Blind-Hunter-Review (Finding 14): README nennt „einer Quelle zugeordnet oder global"; die aktuellen Sources nutzen nur global `raw/assets/`.
|
||||||
+80
@@ -0,0 +1,80 @@
|
|||||||
|
---
|
||||||
|
title: 'Sources lokal unter `raw/` bereitstellen (Story 1.2)'
|
||||||
|
type: 'feature'
|
||||||
|
created: '2026-08-14'
|
||||||
|
status: 'done'
|
||||||
|
route: 'one-shot'
|
||||||
|
review_loop_iteration: 0
|
||||||
|
context:
|
||||||
|
- _bmad-output/implementation-artifacts/epic-1-context.md
|
||||||
|
---
|
||||||
|
|
||||||
|
# Sources lokal unter `raw/` bereitstellen (Story 1.2)
|
||||||
|
|
||||||
|
## Intent
|
||||||
|
|
||||||
|
**Problem:** Der Workspace besitzt die `raw/`-Grenze, aber noch kein materialisiertes Source Material — ein Compilation Run hätte nichts zu verarbeiten.
|
||||||
|
|
||||||
|
**Approach:** Die ersten realen Sources (PRD, Architecture-Spine, epics) lokal unter `raw/` als immutable Evidenz materialisieren und in `raw/README.md` die Quellen-Konvention festhalten (pro-Quelle-Verzeichnis, `source.md`-Provenienz, additive Versionierung, lokale statt URL).
|
||||||
|
|
||||||
|
## Suggested Review Order
|
||||||
|
|
||||||
|
**Konvention & Grenze**
|
||||||
|
|
||||||
|
- Quellen-Konvention, Artefakt- vs. Evidenz-Carve-out, Benennung/Versionierung
|
||||||
|
[`raw/README.md`](../../raw/README.md#L11)
|
||||||
|
|
||||||
|
- Provenienz-Sidecar: einheitliche Metadaten, „keine Evidenz"-Hinweis
|
||||||
|
[`raw/prd/source.md`](../../raw/prd/source.md#L1)
|
||||||
|
[`raw/architecture-spine/source.md`](../../raw/architecture-spine/source.md#L1)
|
||||||
|
[`raw/epics/source.md`](../../raw/epics/source.md#L1)
|
||||||
|
|
||||||
|
**Materialisierte Evidenz (byte-identische Kopien der Planungs-Artefakte)**
|
||||||
|
|
||||||
|
- [`raw/prd/prd-wow20-2026-08-14.md`](../../raw/prd/prd-wow20-2026-08-14.md#L1)
|
||||||
|
- [`raw/architecture-spine/architecture-spine-2026-08-14.md`](../../raw/architecture-spine/architecture-spine-2026-08-14.md#L1)
|
||||||
|
- [`raw/epics/epics-2026-08-14.md`](../../raw/epics/epics-2026-08-14.md#L1)
|
||||||
|
|
||||||
|
**Status**
|
||||||
|
|
||||||
|
- Story-Status & `last_updated`
|
||||||
|
[`sprint-status.yaml`](../../_bmad-output/implementation-artifacts/sprint-status.yaml#L31)
|
||||||
|
|
||||||
|
## Tasks & Acceptance
|
||||||
|
|
||||||
|
**Execution:**
|
||||||
|
- [x] `raw/prd/`, `raw/architecture-spine/`, `raw/epics/` — erste reale Sources als Per-Quelle-Verzeichnisse anlegen — stellt dem Compiler Evidenz bereit (FR-1, AD-12)
|
||||||
|
- [x] `raw/<quelle>/source.md` — Provenienz-Sidecar je Quelle (Herkunft, Kopierdatum, Kurzbeschreibung) — Tracebarkeit & AD-3-Versionierung
|
||||||
|
- [x] `raw/README.md` — Quellen-Konvention dokumentieren — kanonischer Ort der Konvention; Benennung, additive Versionierung, Artefakt-Carve-out, lokale statt URL
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
- Given ein initialisierter Workspace, When Sources unter `raw/` materialisiert sind, Then werden sie als immutable Evidenz erkannt und nicht automatisch nach `wiki/` kopiert (FR-2, AD-3)
|
||||||
|
- Given mehrere Quellen (1..n), When bereitgestellt, Then sind sie als Eingabe für einen Run lokalisierbar (FR-1)
|
||||||
|
- Given eine bereits verarbeitete Source, When erneut verarbeitet, Then bleibt die Originaldatei unter `raw/` unverändert; neue Versionen sind neue, datierte Dateien (AD-3)
|
||||||
|
- Given der manuelle Import (v1), When eine URL statt lokalen Materials angegeben wird, Then wird dies gemäß Konvention als nicht unterstützt zurückgewiesen (A-4)
|
||||||
|
|
||||||
|
## Spec Change Log
|
||||||
|
|
||||||
|
<!-- Append-only. Populated by step-04 during review loops. Empty until the first bad_spec loopback. -->
|
||||||
|
|
||||||
|
## Design Notes
|
||||||
|
|
||||||
|
Konvention (aus Blind-Hunter-Review um Artefakt-Carve-out, kebab-case und additive Versionierung geschärft):
|
||||||
|
|
||||||
|
```text
|
||||||
|
raw/<quelle>/
|
||||||
|
<quelle-kebab-case>-<jjjj-mm-tt>.md # Evidenz (AD-3, immutable)
|
||||||
|
source.md # Artefakt (keine Evidenz): Herkunft, Kopierdatum, Kurzbeschreibung
|
||||||
|
```
|
||||||
|
|
||||||
|
`source.md` ist als Artefakt kein Evidenz-Bestandteil — dieselbe Grenz-Logik wie `raw/README.md`. Herkunftspfade unter `_bmad-output/` sind generierte Planungs-Artefakte (nicht versioniert); Checksummen-/Fingerprint und maschinenlesbares Source-Metadaten-Schema sind als Deferred Work erfasst (Story 1.3/1.4 bzw. Provenienz).
|
||||||
|
|
||||||
|
## Verification
|
||||||
|
|
||||||
|
**Commands:**
|
||||||
|
- `git status --short && git diff --stat` — expected: 3 neue Quellen-Verzeichnisse + `source.md` je Quelle + `raw/README.md`-Erweiterung + `sprint-status.yaml`-Wired-Up (Story 1.2 in-progress, epic-1 in-progress)
|
||||||
|
- Copy-Verifikation: `git diff --no-index --stat <kanonisch> <raw-Kopie>` — expected: ply 0/keine Differenz (byte-identische Kopien)
|
||||||
|
|
||||||
|
**Manual checks (if no CLI):**
|
||||||
|
- `raw/README.md` Quellen-Konvention stimmt mit dem tatsächlichen `raw/`-Baum überein (Verzeichnisse `prd/`, `epics/`, `architecture-spine/`, `assets/`)
|
||||||
|
- Alle `source.md` referenzieren die tatsächlich vorhandene Evidenz-Datei im selben Verzeichnis
|
||||||
@@ -29,7 +29,7 @@
|
|||||||
# - Dev moves story to 'review', then runs code-review (fresh context, different LLM recommended)
|
# - 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
|
# - Retrospective appends its action items to action_items; the status view surfaces open ones
|
||||||
generated: 08-14-2026 00:00
|
generated: 08-14-2026 00:00
|
||||||
last_updated: 08-14-2026 19:55
|
last_updated: 08-14-2026 20:08
|
||||||
project: wow20
|
project: wow20
|
||||||
project_key: NOKEY
|
project_key: NOKEY
|
||||||
tracking_system: file-system
|
tracking_system: file-system
|
||||||
@@ -37,7 +37,7 @@ story_location: D:/mita/wow-2nd/_bmad-output/implementation-artifacts
|
|||||||
development_status:
|
development_status:
|
||||||
epic-1: in-progress
|
epic-1: in-progress
|
||||||
1-1-kanonischen-workspace-stamm-erstellen: done
|
1-1-kanonischen-workspace-stamm-erstellen: done
|
||||||
1-2-sources-lokal-unter-raw-bereitstellen: backlog
|
1-2-sources-lokal-unter-raw-bereitstellen: review
|
||||||
1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren: backlog
|
1-3-okf-schema-vertrag-schema-wiki-compiler-md-autorisieren: backlog
|
||||||
1-4-schema-validierung-für-bundle-implementieren: backlog
|
1-4-schema-validierung-für-bundle-implementieren: backlog
|
||||||
epic-1-retrospective: optional
|
epic-1-retrospective: optional
|
||||||
|
|||||||
@@ -9,5 +9,27 @@ Dieses Verzeichnis ist die Architekturgrenze für **Source Material** (AD-2, AD-
|
|||||||
|
|
||||||
Unterverzeichnisse (z.B. `assets/`) können je nach Quelle ergänzt werden. Die Quelle selbst wird nie automatisch nach `wiki/` kopiert — das Kopieren eines Quell-Dokuments ist keine Wissensintegration (FR-2).
|
Unterverzeichnisse (z.B. `assets/`) können je nach Quelle ergänzt werden. Die Quelle selbst wird nie automatisch nach `wiki/` kopiert — das Kopieren eines Quell-Dokuments ist keine Wissensintegration (FR-2).
|
||||||
|
|
||||||
|
## Quellen-Konvention
|
||||||
|
|
||||||
|
Jede Quelle liegt in einem eigenen Verzeichnis `raw/<quelle>/` mit dem Quelldokument und optional einer `source.md` (Provenienz-Sidecar: kanonische Herkunft, Kopierdatum, Kurzbeschreibung). Die Benennung folgt `<quelle-kebab-case>-<jjjj-mm-tt>.md`; Verzeichnisname und Dateiname nutzen denselben kebab-case-Namen der Quelle (AD-3). Eine neue Version einer Quelle wird **additiv als neue, datierte Datei** angelegt (z.B. `prd-wow20-2026-08-15.md`) — bestehende Dateien unter `raw/` bleiben unverändert (Immutable Evidenz, AD-3). `source.md` ist als Grenz-/Artefakt-Datei (Orientierung) **keine Evidenz**; ihre Einträge sind Reproduktionshinweise, nicht das eigentliche Source Material.
|
||||||
|
|
||||||
|
Beispiel:
|
||||||
|
|
||||||
|
```text
|
||||||
|
raw/
|
||||||
|
prd/
|
||||||
|
prd-wow20-2026-08-14.md # Evidenz
|
||||||
|
source.md # Artefakt (nicht Evidenz)
|
||||||
|
epics/
|
||||||
|
epics-2026-08-14.md # Evidenz
|
||||||
|
source.md # Artefakt (nicht Evidenz)
|
||||||
|
architecture-spine/
|
||||||
|
architecture-spine-2026-08-14.md # Evidenz
|
||||||
|
source.md # Artefakt (nicht Evidenz)
|
||||||
|
assets/ # optionale Assets, einer Quelle zugeordnet oder global
|
||||||
|
```
|
||||||
|
|
||||||
|
Lokal materialisiertes Source Material ist die einzige in v1 unterstützte Eingabe (FR-1, A-4): **URL-Abrufe werden zurückgewiesen**, es findet keine automatische Internetrecherche statt.
|
||||||
|
|
||||||
> Diese README-Datei ist ein **Grenz-/Artefakt-Datei** (Orientierung), keine Evidenz; sie markiert die Grenze, ist selbst aber kein zu verarbeitendes Source Material.
|
> Diese README-Datei ist ein **Grenz-/Artefakt-Datei** (Orientierung), keine Evidenz; sie markiert die Grenze, ist selbst aber kein zu verarbeitendes Source Material.
|
||||||
|
|
||||||
|
|||||||
@@ -0,0 +1,953 @@
|
|||||||
|
---
|
||||||
|
name: Wiki of Wikis
|
||||||
|
type: architecture-spine
|
||||||
|
purpose: build-substrate
|
||||||
|
altitude: product
|
||||||
|
paradigm: agent-native file-based compiler pipeline
|
||||||
|
scope: Wiki of Wikis MVP
|
||||||
|
status: final
|
||||||
|
created: 2026-08-14
|
||||||
|
updated: 2026-08-14
|
||||||
|
binds:
|
||||||
|
- FR-1..FR-16
|
||||||
|
- NFR-1..NFR-7
|
||||||
|
sources:
|
||||||
|
- PRD — Wiki of Wikis
|
||||||
|
- Andrej Karpathy — LLM Wiki
|
||||||
|
- Open Knowledge Format 0.2
|
||||||
|
companions:
|
||||||
|
- PRD — Wiki of Wikis
|
||||||
|
---
|
||||||
|
|
||||||
|
# Architecture Spine — Wiki of Wikis
|
||||||
|
|
||||||
|
## Design Paradigm
|
||||||
|
|
||||||
|
**Agent-native file-based compiler pipeline**
|
||||||
|
|
||||||
|
Wiki of Wikis wird als inkrementeller Knowledge Compiler aufgebaut.
|
||||||
|
|
||||||
|
Der Compiler transformiert unveränderliches Source Material und bereits vorhandenes kuratiertes Wissen in ein aktualisiertes OKF Knowledge Bundle.
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
flowchart LR
|
||||||
|
S[Raw Sources] --> C[LLM Wiki Compiler]
|
||||||
|
W[Existing OKF Wiki] --> C
|
||||||
|
|
||||||
|
C --> P[Proposed Changes]
|
||||||
|
P --> V[Validation]
|
||||||
|
V -->|valid| W2[Updated OKF Wiki]
|
||||||
|
|
||||||
|
W2 --> H[Humans]
|
||||||
|
W2 --> A[LLM Agents]
|
||||||
|
W2 --> B[BMAD]
|
||||||
|
W2 --> X[Other Consumers]
|
||||||
|
```
|
||||||
|
|
||||||
|
Der Compiler ist **kein Wissensserver**.
|
||||||
|
|
||||||
|
Das Knowledge Bundle ist das Produktartefakt.
|
||||||
|
|
||||||
|
Der Compiler ist lediglich der Producer dieses Artefakts.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Invariants & Rules
|
||||||
|
|
||||||
|
## AD-1 — OKF Knowledge Bundle is canonical knowledge state `[ADOPTED]`
|
||||||
|
|
||||||
|
- **Binds:** FR-9..FR-16, NFR-1..NFR-6
|
||||||
|
- **Prevents:** Eine proprietäre Datenbank, ein Index oder eine Agent-Runtime wird versehentlich zum eigentlichen Knowledge Store.
|
||||||
|
- **Rule:** Das kanonische kuratierte Wissen besteht ausschließlich aus einem OKF-0.2-konformen Markdown Knowledge Bundle.
|
||||||
|
|
||||||
|
Caches, Datenbanken, Embeddings, Search-Indizes oder Graph-Repräsentationen dürfen zukünftig existieren, sind jedoch ausschließlich abgeleitete Artefakte.
|
||||||
|
|
||||||
|
```text
|
||||||
|
Canonical
|
||||||
|
wiki/**/*.md
|
||||||
|
|
||||||
|
Derived
|
||||||
|
indexes
|
||||||
|
embeddings
|
||||||
|
caches
|
||||||
|
search databases
|
||||||
|
visualizations
|
||||||
|
```
|
||||||
|
|
||||||
|
Das Knowledge Bundle muss auch ohne diese Derived Artifacts vollständig verständlich bleiben.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## AD-2 — Raw Sources and Curated Knowledge are separate states `[ADOPTED]`
|
||||||
|
|
||||||
|
- **Binds:** FR-1, FR-2, FR-3, FR-4
|
||||||
|
- **Prevents:** Rohdokumente und LLM-generiertes Wissen werden vermischt und verlieren ihre unterschiedliche semantische Bedeutung.
|
||||||
|
- **Rule:** Source Material und Knowledge Bundle werden physisch und semantisch getrennt gespeichert.
|
||||||
|
|
||||||
|
```text
|
||||||
|
raw/ immutable source material
|
||||||
|
wiki/ curated OKF knowledge
|
||||||
|
```
|
||||||
|
|
||||||
|
Eine Datei unter `raw/` ist Evidenz.
|
||||||
|
|
||||||
|
Eine Datei unter `wiki/` ist eine aus Evidenz abgeleitete Wissensrepräsentation.
|
||||||
|
|
||||||
|
Das bloße Kopieren eines Source-Dokuments nach `wiki/` ist keine Compilation.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## AD-3 — Raw Sources are immutable `[ADOPTED]`
|
||||||
|
|
||||||
|
- **Binds:** FR-1..FR-8
|
||||||
|
- **Prevents:** Der Compiler verändert rückwirkend seine eigene Evidenzbasis.
|
||||||
|
- **Rule:** Ein Compilation Run darf bestehendes Source Material niemals verändern.
|
||||||
|
|
||||||
|
Neue Versionen einer Source werden als neue beziehungsweise versionierte Source behandelt.
|
||||||
|
|
||||||
|
Source Lifecycle und Replacement-Semantik bleiben für den MVP deferred.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## AD-4 — Generated knowledge must remain source-grounded
|
||||||
|
|
||||||
|
- **Binds:** FR-3, FR-7, FR-8, NFR-7
|
||||||
|
- **Prevents:** Das Wiki beginnt, seine eigenen LLM-Synthesen als neue Evidenz zu behandeln und verstärkt dadurch unbelegte Aussagen.
|
||||||
|
- **Rule:** Ein generiertes Concept darf vorhandene Concepts zur Synthese und Kontextbildung verwenden, muss fachliche Aussagen jedoch auf nachvollziehbare Sources zurückführen.
|
||||||
|
|
||||||
|
Wiki-to-Wiki-Links dienen insbesondere:
|
||||||
|
|
||||||
|
- Navigation,
|
||||||
|
- Kontext,
|
||||||
|
- Beziehungen,
|
||||||
|
- Synthese.
|
||||||
|
|
||||||
|
Sie ersetzen nicht die Provenienz zur ursprünglichen Evidenz.
|
||||||
|
|
||||||
|
Bei einer Synthese aus mehreren Concepts wird relevante Source-Provenienz in das resultierende Concept übernommen.
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
flowchart LR
|
||||||
|
R1[Raw Source A] --> C1[Concept A]
|
||||||
|
R2[Raw Source B] --> C2[Concept B]
|
||||||
|
|
||||||
|
C1 --> S[Synthesized Concept]
|
||||||
|
C2 --> S
|
||||||
|
|
||||||
|
R1 -. provenance .-> S
|
||||||
|
R2 -. provenance .-> S
|
||||||
|
```
|
||||||
|
|
||||||
|
### AD-4a — Claim-granular provenance
|
||||||
|
|
||||||
|
Provenance must be referencible per asserting unit (block/paragraph), not only per Concept. Minimum form: every backed claim carries an inline reference to `raw/` evidence; context/synthesis reformulations carry an explicit context marker ("taken over from <Concept path> based on <source>, not independently evidenced").
|
||||||
|
|
||||||
|
### AD-4b — Sources target only raw/ or external evidence
|
||||||
|
|
||||||
|
`sources` entries must resolve to `raw/` paths or to externally referenced immutable evidence — never to a `wiki/` concept path. Wiki links remain the navigation/relationship layer (AD-8) and are format-side disambiguated from provenance.
|
||||||
|
|
||||||
|
### AD-4c — No generated Concept is sole provenance of another (binding)
|
||||||
|
|
||||||
|
"Ein generiertes Concept darf nie ein anderes generiertes Concept als alleinige Provenienz führen" wurde von einer ASSUMPTION in eine Rule überführt und ist Teil der `schema/wiki-compiler.md`-Validierung.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## AD-5 — Compilation is incremental `[ADOPTED]`
|
||||||
|
|
||||||
|
- **Binds:** FR-4..FR-8, FR-12
|
||||||
|
- **Prevents:** Jeder Lauf erzeugt das Wiki erneut aus sämtlichen Rohquellen und verliert den compounding-knowledge Effekt.
|
||||||
|
- **Rule:** Jeder Compilation Run beginnt mit dem aktuell vorhandenen Knowledge Bundle und verändert nur die durch neue Erkenntnisse betroffenen Concepts.
|
||||||
|
|
||||||
|
Der logische Datenfluss lautet:
|
||||||
|
|
||||||
|
```text
|
||||||
|
Existing Knowledge
|
||||||
|
+
|
||||||
|
New Source Material
|
||||||
|
↓
|
||||||
|
Interpret
|
||||||
|
↓
|
||||||
|
Reconcile
|
||||||
|
↓
|
||||||
|
Synthesize
|
||||||
|
↓
|
||||||
|
Update affected Concepts
|
||||||
|
```
|
||||||
|
|
||||||
|
Nicht:
|
||||||
|
|
||||||
|
```text
|
||||||
|
All Sources
|
||||||
|
↓
|
||||||
|
Regenerate Everything
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## AD-6 — Compilation separates reasoning from mutation `[ASSUMPTION]`
|
||||||
|
|
||||||
|
- **Binds:** FR-5..FR-14
|
||||||
|
- **Prevents:** Ein Agent hinterlässt während einer teilweise fehlgeschlagenen Verarbeitung ein inkonsistentes Knowledge Bundle.
|
||||||
|
- **Rule:** Ein Compilation Run unterscheidet logisch zwischen:
|
||||||
|
|
||||||
|
1. Analyse,
|
||||||
|
2. Änderungsplanung,
|
||||||
|
3. Mutation,
|
||||||
|
4. Validierung.
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
flowchart LR
|
||||||
|
A[Analyze] --> R[Reconcile]
|
||||||
|
R --> P[Plan Changes]
|
||||||
|
P --> M[Mutate Bundle]
|
||||||
|
M --> V[Validate]
|
||||||
|
```
|
||||||
|
|
||||||
|
Ein Agent darf diese Phasen technisch innerhalb einer Session durchführen.
|
||||||
|
|
||||||
|
Die Architektur schreibt keine separate Workflow Engine vor.
|
||||||
|
|
||||||
|
Der beobachtbare Endzustand muss jedoch ein konsistentes Bundle sein.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## AD-7 — Concept identity is its OKF path `[ADOPTED]`
|
||||||
|
|
||||||
|
- **Binds:** FR-5, FR-6, FR-9..FR-12
|
||||||
|
- **Prevents:** Unterschiedliche Producer führen zusätzliche IDs oder proprietäre Identity-Systeme ein.
|
||||||
|
- **Rule:** Die Identität eines Concepts entspricht der OKF-Konvention und wird durch den relativen Pfad innerhalb des Knowledge Bundle bestimmt.
|
||||||
|
|
||||||
|
Beispiel:
|
||||||
|
|
||||||
|
```text
|
||||||
|
wiki/
|
||||||
|
flowable/
|
||||||
|
timers.md
|
||||||
|
```
|
||||||
|
|
||||||
|
Concept ID:
|
||||||
|
|
||||||
|
```text
|
||||||
|
flowable/timers
|
||||||
|
```
|
||||||
|
|
||||||
|
Renames sind deshalb semantische Änderungen und keine rein kosmetischen Dateioperationen.
|
||||||
|
|
||||||
|
### AD-7a — One canonical concept-ID normalization
|
||||||
|
|
||||||
|
Exactly one canonical ID form must be fixed, e.g.: lowercase, path relative to the bundle root, without extension, `index.md` → area path, no trailing dots. Example table:
|
||||||
|
|
||||||
|
```text
|
||||||
|
wiki/flowable/timers.md → flowable/timers
|
||||||
|
wiki/spring/index.md → spring
|
||||||
|
wiki/spring/testing.md → spring/testing
|
||||||
|
```
|
||||||
|
|
||||||
|
### AD-7b — One permitted link form
|
||||||
|
|
||||||
|
AD-8's "normal Markdown links" must be pinned to exactly one form: bundle-relative with or without extension — one of them, never both. (This prevents two producers computing different IDs from the same tree.)
|
||||||
|
|
||||||
|
### AD-7c — Deterministic area attribution
|
||||||
|
|
||||||
|
A rule for "where does a topic belong" is required. The relevance determination is already pinned to textual, deterministic means (AD-17 appendix, deterministic relevance); the same textual determinism must determine the target area, e.g. via an existing `index.md` link or top-level collision-hold on existing paths.
|
||||||
|
|
||||||
|
### AD-7d — Renaming compatibility
|
||||||
|
|
||||||
|
A rename is a new object plus an explicit redirect/deprecation entry in `log.md` (or the OKF `references/` convention), so that old IDs remain machine-discoverable.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## AD-8 — Standard Markdown links express concept relationships `[ADOPTED]`
|
||||||
|
|
||||||
|
- **Binds:** FR-10, FR-11, FR-15
|
||||||
|
- **Prevents:** Beziehungen funktionieren nur noch mit einer speziellen Graphdatenbank oder einem proprietären Linkformat.
|
||||||
|
- **Rule:** Beziehungen zwischen Concepts werden mit normalen Markdown-Links ausgedrückt. Die eine erlaubte Linkform ist durch AD-7b gepinnt (bundle-relativ, eine einzige Form — nie beide).
|
||||||
|
|
||||||
|
Eine zukünftige Graph-Repräsentation darf diese Links auswerten.
|
||||||
|
|
||||||
|
Der Graph selbst ist jedoch nicht kanonisch.
|
||||||
|
|
||||||
|
```text
|
||||||
|
Markdown Links
|
||||||
|
↓
|
||||||
|
optional derivation
|
||||||
|
↓
|
||||||
|
Knowledge Graph
|
||||||
|
```
|
||||||
|
|
||||||
|
Nicht:
|
||||||
|
|
||||||
|
```text
|
||||||
|
Knowledge Graph
|
||||||
|
↓
|
||||||
|
generated Markdown projection
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## AD-9 — Progressive discovery uses OKF hierarchy and indexes `[ADOPTED]`
|
||||||
|
|
||||||
|
- **Binds:** FR-11, FR-15
|
||||||
|
- **Prevents:** Consumer müssen das komplette Wiki in ihren Context laden oder benötigen frühzeitig eine externe Search Engine.
|
||||||
|
- **Rule:** `index.md` und die hierarchische Bundle-Struktur bilden die erste Discovery-Ebene.
|
||||||
|
|
||||||
|
Beispiel:
|
||||||
|
|
||||||
|
```text
|
||||||
|
wiki/
|
||||||
|
index.md
|
||||||
|
|
||||||
|
spring/
|
||||||
|
index.md
|
||||||
|
testing.md
|
||||||
|
transactions.md
|
||||||
|
|
||||||
|
flowable/
|
||||||
|
index.md
|
||||||
|
timers.md
|
||||||
|
job-execution.md
|
||||||
|
|
||||||
|
project/
|
||||||
|
index.md
|
||||||
|
release-train.md
|
||||||
|
```
|
||||||
|
|
||||||
|
Ein Consumer soll von einer Übersicht schrittweise zu relevanten Concepts navigieren können.
|
||||||
|
|
||||||
|
Search ist eine optionale spätere Optimierung.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## AD-10 — Compiler behavior is defined independently of a specific agent `[ADOPTED]`
|
||||||
|
|
||||||
|
- **Binds:** FR-15, FR-16, NFR-6
|
||||||
|
- **Prevents:** Wiki of Wikis wird untrennbar mit Claude Code, Codex, BMAD oder einem bestimmten Modell verbunden.
|
||||||
|
- **Rule:** Die kanonischen Compiler-Regeln werden agent-unabhängig beschrieben.
|
||||||
|
|
||||||
|
Provider- oder agentenspezifische Instruktionsdateien sind dünne Adapter.
|
||||||
|
|
||||||
|
```text
|
||||||
|
Canonical compiler contract
|
||||||
|
│
|
||||||
|
┌────┼────┐
|
||||||
|
▼ ▼ ▼
|
||||||
|
Claude Codex Other
|
||||||
|
adapter adapter adapter
|
||||||
|
```
|
||||||
|
|
||||||
|
Ein Adapter darf keine abweichende Knowledge-Semantik definieren.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## AD-11 — Agent runtime provides reasoning; Wiki of Wikis provides protocol `[ASSUMPTION]`
|
||||||
|
|
||||||
|
- **Binds:** MVP
|
||||||
|
- **Prevents:** Für den MVP entsteht unnötig eine eigene LLM-Orchestrierungsplattform.
|
||||||
|
- **Rule:** Wiki of Wikis implementiert zunächst keine eigene LLM Runtime.
|
||||||
|
|
||||||
|
Ein vorhandener agentischer Host führt den Compiler-Workflow aus und stellt Fähigkeiten wie:
|
||||||
|
|
||||||
|
- Dateien lesen,
|
||||||
|
- Dateien schreiben,
|
||||||
|
- suchen,
|
||||||
|
- LLM Reasoning
|
||||||
|
|
||||||
|
bereit.
|
||||||
|
|
||||||
|
Die konkrete Runtime ist austauschbar.
|
||||||
|
|
||||||
|
Damit ist für den MVP insbesondere **kein eigener Serverprozess erforderlich**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## AD-12 — Source acquisition is outside the compiler core `[ADOPTED]`
|
||||||
|
|
||||||
|
- **Binds:** FR-1, MVP boundary
|
||||||
|
- **Prevents:** Der Knowledge Compiler wächst zu Webcrawler, Dokumentenplattform oder Connector Framework.
|
||||||
|
- **Rule:** Der Compiler verarbeitet bereitgestelltes Source Material.
|
||||||
|
|
||||||
|
Wie eine Source beschafft wurde, liegt außerhalb des Compiler-Kerns.
|
||||||
|
|
||||||
|
Beispiele:
|
||||||
|
|
||||||
|
```text
|
||||||
|
Context7 --------\
|
||||||
|
Web Clipper ------\
|
||||||
|
BMAD Archive ------> raw/ ---> Compiler
|
||||||
|
Arc42 ------------/
|
||||||
|
Vendor Docs ------/
|
||||||
|
```
|
||||||
|
|
||||||
|
Zukünftige Source Adapter dürfen Material nach `raw/` materialisieren.
|
||||||
|
|
||||||
|
Sie umgehen nicht die Source-Grenze.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## AD-13 — Retrieval belongs to consumers `[ADOPTED]`
|
||||||
|
|
||||||
|
- **Binds:** FR-15, FR-16, MVP Non-Goals
|
||||||
|
- **Prevents:** Search, RAG, Embeddings oder CodeGraph werden wieder zum Zentrum der Architektur.
|
||||||
|
- **Rule:** Retrieval ist nicht Bestandteil des kanonischen Knowledge Compilers.
|
||||||
|
|
||||||
|
Ein Consumer kann beispielsweise verwenden:
|
||||||
|
|
||||||
|
```text
|
||||||
|
grep / ripgrep
|
||||||
|
Markdown traversal
|
||||||
|
BM25
|
||||||
|
Vector Search
|
||||||
|
Hybrid Search
|
||||||
|
Knowledge Graph
|
||||||
|
CodeGraph
|
||||||
|
```
|
||||||
|
|
||||||
|
Diese Verfahren lesen das Knowledge Bundle.
|
||||||
|
|
||||||
|
Sie verändern dessen kanonisches Datenmodell nicht.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## AD-14 — Git provides history, not domain state `[ADOPTED]`
|
||||||
|
|
||||||
|
- **Binds:** FR-14, NFR-4
|
||||||
|
- **Prevents:** Eine zusätzliche proprietäre Versions- oder Audit-Datenbank wird eingeführt.
|
||||||
|
- **Rule:** Änderungen am Knowledge Bundle werden als normale textuelle Änderungen behandelt und können mit Git versioniert werden.
|
||||||
|
|
||||||
|
Git ist verantwortlich für:
|
||||||
|
|
||||||
|
- Diffs,
|
||||||
|
- Version History,
|
||||||
|
- Attribution,
|
||||||
|
- Branching,
|
||||||
|
- Restore.
|
||||||
|
|
||||||
|
Fachliche Provenienz verbleibt dennoch im OKF Concept und darf nicht ausschließlich aus Git-Historie abgeleitet werden.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## AD-15 — Human curation and machine curation share the same knowledge model `[ADOPTED]`
|
||||||
|
|
||||||
|
- **Binds:** FR-13, NFR-2
|
||||||
|
- **Prevents:** Ein separates Datenmodell für manuelles und generiertes Wissen entsteht.
|
||||||
|
- **Rule:** Sowohl menschlich als auch maschinell gepflegtes Wissen wird als OKF Concept repräsentiert.
|
||||||
|
|
||||||
|
Unterschiede bezüglich Autor, Generierung oder Review werden über OKF-Metadaten ausgedrückt, nicht über getrennte Dateiformate.
|
||||||
|
|
||||||
|
Der Compiler behandelt vorhandene menschliche Inhalte als persistentes Wissen und darf sie nicht allein wegen fehlender Herkunft aus dem aktuellen Compilation Run entfernen.
|
||||||
|
|
||||||
|
Die Trust- und Review-Metadaten folgen der OKF-0.2-Konvention:
|
||||||
|
|
||||||
|
- maschinell erzeugt und ungeprüft → `generated: { by, at }` setzen, kein `verified`;
|
||||||
|
- Evidence-basiert bzw. menschlich reviewed → `verified` mit `human:`-Präfix-Actor;
|
||||||
|
- Lifecycle → `status` (`draft` | `stable` | `deprecated`) und optional `stale_after`.
|
||||||
|
|
||||||
|
Der v1-Default nach PRD-Annahme ist: maschinell erzeugt und ungeprüft, d.h. Trust-Metadaten nur über `generated`, und `verified` bleibt ungesetzt, bis ein Mensch das Concept reviewt.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## AD-16 — Conflicts are preserved explicitly, never silently resolved `[ADOPTED]`
|
||||||
|
|
||||||
|
- **Binds:** FR-8, FR-13, NFR-7
|
||||||
|
- **Prevents:** Widersprüche werden stillschweigend zu einer scheinbar eindeutigen Aussage zusammengeführt und verlieren damit ihre Quelle.
|
||||||
|
- **Rule:** Der Compiler klassifiziert neue Information vor jeder Änderung:
|
||||||
|
|
||||||
|
```text
|
||||||
|
NEW? → create or extend knowledge
|
||||||
|
CONFIRMING? → strengthen existing knowledge if material
|
||||||
|
CORRECTING? → revise existing knowledge
|
||||||
|
CONTRADICTING?→ preserve the disagreement explicitly
|
||||||
|
REDUNDANT? → no knowledge mutation required
|
||||||
|
```
|
||||||
|
|
||||||
|
Diese Klassifikation ist konzeptionell.
|
||||||
|
|
||||||
|
Sie schreibt keine konkrete interne Datenstruktur vor.
|
||||||
|
|
||||||
|
Relevante Widersprüche (Contradictions) verbleiben als explizite, in `log.md` dokumentierte Disagreements im Bundle. Die jeweiligen Sources bleiben nachvollziehbar; Unsicherheit darf explizit Teil eines Concepts sein.
|
||||||
|
|
||||||
|
### AD-16a — Preservation is the default
|
||||||
|
|
||||||
|
Deterministic default: on contradiction, the default is preservation (CONTRADICTING), unless the new source explicitly supersedes the old one with explicit evidence; otherwise CORRECTING with documented replacement logic. This makes the classification (and hence who owns the resolution artifact) deterministic instead of being left to each producer's discretion.
|
||||||
|
|
||||||
|
### AD-16b — Classification is public and bound to the mutation
|
||||||
|
|
||||||
|
The classification including its rationale must land in the same artifact as the mutation — a `log.md` entry linked to the mutated Concept path — so the resolution decision is reproducible and ownership is auditable.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## AD-17 — Producer mechanism is the bundle-relative Workspace Convention (Leasing) `[ADOPTED]`
|
||||||
|
|
||||||
|
- **Binds:** PRD OQ-3, OQ-4, AD-5, AD-6, AD-10
|
||||||
|
- **Prevents:** Zwei unabhängige Compiler / Producer / Nutzer (Claude, Codex oder der Mensch selbst) mutieren denselben Concept-Pfad gleichzeitig; Last-Writer-Wins überschreibt damit stillschweigend die Arbeit des jeweils anderen.
|
||||||
|
- **Rule:** Producer arbeiten nach einem lease/branch-basierten Modell auf dem Git-Workspace:
|
||||||
|
|
||||||
|
1. Jeder Producer arbeitet in einem eigenen Workspace (Branch oder Worktree) und räumt Konflikte auf Git-Ebene (Rebase/Merge) selbst ab.
|
||||||
|
2. Der Compiler darf nur veröffentlichte (committed) Inhalte als Input für Compilation verwenden. Während einer Mutation angelegte Zwischenstände sind nie Input.
|
||||||
|
3. Konvergenz auf `data`-Ebene (Konflikte über Datei-Inhalte) folgen dem Sequenz-Diagramm (orkestriert durch den ausführenden Adapter):
|
||||||
|
|
||||||
|
- neue Sources unter `raw/` materialisieren,
|
||||||
|
- den relevanten existierenden Concept-Bereich auf dem Workspace disabled (Lease) holen,
|
||||||
|
- auf delektierte/importierte Areas folgt `raw/` als Zugriffs- und Consistency-Basis,
|
||||||
|
- Mutationen nur innerhalb des geleasten Bereichs, sonst Reichweite nicht verlassen,
|
||||||
|
- nach Abschluss Änderungen committen und Lease freigeben.
|
||||||
|
|
||||||
|
4. **Konfliktbehandlung:** Bei konkurrierenden Änderungen zählt in der `log.md` der produktive Nutzen/Beitrag als Auflösungs-Prinzip (erhaltbarer Inhalt). Der Compiler darf einen bestehenden Concept-Bereich nicht löschen, erweitern oder umschreiben, wenn die Änderung eines anderen Producers davon wirksam ersetzt wäre; stattdessen wird der Konflikt in `log.md` dokumentiert und offengelegt.
|
||||||
|
|
||||||
|
> **Wichtig — funktionaler Grund:** Retrieval ist Consumer-Verhalten (AD-13), daher ist **Relevanzbestimmung** (PRD OQ-3: "Wie findet der Compiler relevante vorhandene Concepts?") begrenzt: Sie muss mit textuellen, deterministischen Mitteln (grep/ripgrep, Markdown-Traversal, Link-Following) umgesetzt werden, nicht mit Embedding- oder Vector-Infrastruktur. Diese Klärung ist eine Antwort des Compilers auf den PRD-Auftrag.
|
||||||
|
|
||||||
|
### AD-17a — Lease contract (mechanism, commit-binding)
|
||||||
|
|
||||||
|
AD-17 must define what a lease is and how it is acquired — against a unique commit-object value (merge-base discipline) and via a single deterministic mechanism (e.g. branch-prefix convention `lease/<area>/<id>` plus a lockfile realized semantically identically in every adapter). The realization must not be freely selectable per adapter.
|
||||||
|
|
||||||
|
### AD-17b — Lease scope includes the bundle root
|
||||||
|
|
||||||
|
The lease must explicitly cover `wiki/` including `log.md`, `index.md`, and all root files ("root scope"): the preservation artifact is otherwise defenseless.
|
||||||
|
|
||||||
|
### AD-17c — No silent textual auto-merge
|
||||||
|
|
||||||
|
Two branches that modified the same Concept path must not be merged via textual Git auto-merge. The merge is compiler-mediated and goes through the AD-16 classification — with an explicit `log.md` entry if the contents are not identical.
|
||||||
|
|
||||||
|
### AD-17d — Lease staleness
|
||||||
|
|
||||||
|
Either a time-to-live plus registration of the lease in the clone-root state, or the rule that uncommitted leases count as stale after a run abort and `raw/` (immutable, AD-3) is the recovery basis.
|
||||||
|
|
||||||
|
### AD-17e — Dirty-tree protection
|
||||||
|
|
||||||
|
Before any mutation the producer must check the working copy for the area being mutated; non-committed foreign changes must be protected (stash/divert into a protected scratch zone), and any displaced uncommitted content must be documented in `log.md`.
|
||||||
|
|
||||||
|
### AD-17f — Commit boundary is the mutation boundary
|
||||||
|
|
||||||
|
Mutation may only operate at directory/commit level, so a foreign dirty working-tree change is never deleted as a side-effect of checkout/rebase.
|
||||||
|
|
||||||
|
### AD-17g — Resolution authority
|
||||||
|
|
||||||
|
Who resolves an AD-16 collision must be fixed (MVP: the compiler run holding the lease, per the AD-16a default; human escalation only when undecidable), and the resolution must be bound to the same commit/log documentation (minimal: commit hash + classification in the entry).
|
||||||
|
|
||||||
|
### AD-17h — Determinism contract
|
||||||
|
|
||||||
|
Over the same Git state and the same input set, two independent runs must produce the same bundle state (as an explicit fitness test analogous to FT-6); otherwise the AD-16 classification is not deterministic enough.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Consistency Conventions
|
||||||
|
|
||||||
|
| Concern | Convention |
|
||||||
|
|---|---|
|
||||||
|
| Concept identity | relativer OKF-Dateipfad ohne `.md` (AD-7a) |
|
||||||
|
| Concept format | Markdown + YAML Frontmatter |
|
||||||
|
| Concept relationships | Standard-Markdown-Links (eine erlaubte Form, AD-7b) |
|
||||||
|
| Provenance | OKF `sources` — nie auf `wiki/`-Pfade (AD-4b) |
|
||||||
|
| Source state | immutable |
|
||||||
|
| Knowledge state | mutable, incremental |
|
||||||
|
| Canonical knowledge | `wiki/` |
|
||||||
|
| Canonical evidence | `raw/` bzw. referenzierte externe Source |
|
||||||
|
| Discovery | Hierarchie + `index.md` |
|
||||||
|
| Update history | Git + optional OKF `log.md` |
|
||||||
|
| Agent-specific behavior | Adapter, nicht Knowledge-Modell |
|
||||||
|
| NFR-3 Agent Readability (explicit binding) | gut verlinktes, atomares, frontmatter-sauberes Markdown, konsumierbar von jeder Tool-Klasse — keine Optimierung für eine einzelne Agenten-Familie (FR-16-konform) |
|
||||||
|
| Schema | `schema/wiki-compiler.md` bindet das OKF-Feld-Subset, `log.md`-Typ, Index-Regel, Validitätsprädikate (AD-1a) |
|
||||||
|
| Errors | kein erfolgreicher Run bei OKF-invalidem Bundle laut `schema/wiki-compiler.md` (F-2/AD-1b: strukturell-invalid, nicht bei fehlenden optionalen Feldern) |
|
||||||
|
| Human correctability | ein Mensch kann ein maschinell erzeugtes Concept editieren/corrigieren; die Korrektur wird wie normale Kuratierung behandelt (A-1/SM-C3, FT-9) |
|
||||||
|
| Configuration | textuell und versionierbar |
|
||||||
|
| Derived indexes | rebuildable, niemals Source of Truth |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Structural Seed
|
||||||
|
|
||||||
|
**Bundle root:** `wiki/` ist die Bundleroot des OKF Knowledge Bundle. Alle strukturellen OKF-Konventionen (reservierte `index.md`/`log.md`; `okf_version` nur in der Bundleroot-`index.md`) beziehen sich auf dieses Verzeichnis. `raw/`, `schema/` und `adapters/` liegen **außerhalb** des Bundles und sind keine Concept-Dateien.
|
||||||
|
|
||||||
|
```text
|
||||||
|
wiki-of-wikis/
|
||||||
|
│
|
||||||
|
├── raw/
|
||||||
|
│ ├── ...
|
||||||
|
│ │
|
||||||
|
│ └── assets/
|
||||||
|
│
|
||||||
|
├── wiki/
|
||||||
|
│ ├── index.md
|
||||||
|
│ ├── log.md
|
||||||
|
│ │
|
||||||
|
│ ├── <area>/
|
||||||
|
│ │ ├── index.md
|
||||||
|
│ │ └── <concept>.md
|
||||||
|
│ │
|
||||||
|
│ └── ...
|
||||||
|
│
|
||||||
|
├── schema/
|
||||||
|
│ └── wiki-compiler.md
|
||||||
|
│
|
||||||
|
└── adapters/
|
||||||
|
├── claude/
|
||||||
|
├── codex/
|
||||||
|
└── ...
|
||||||
|
```
|
||||||
|
|
||||||
|
`raw/` und `wiki/` sind Architekturgrenzen.
|
||||||
|
|
||||||
|
Die übrige Verzeichnisstruktur ist Seed und darf sich mit der Implementierung verändern.
|
||||||
|
|
||||||
|
Insbesondere sind `schema/` und `adapters/` keine Domain Stores.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Capability → Architecture Map
|
||||||
|
|
||||||
|
| Capability | Lives in | Governed by |
|
||||||
|
|---|---|---|
|
||||||
|
| FR-1 Source intake | `raw/` boundary | AD-2, AD-3, AD-12 |
|
||||||
|
| FR-2 Source/Knowledge separation | repository boundaries | AD-2 |
|
||||||
|
| FR-3 Provenance | OKF Concepts | AD-4 |
|
||||||
|
| FR-4 Existing knowledge processing | compiler | AD-5 |
|
||||||
|
| FR-5 Concept creation | compiler → `wiki/` | AD-5, AD-7 |
|
||||||
|
| FR-6 Concept update | compiler → `wiki/` | AD-5 |
|
||||||
|
| FR-7 Cross-source synthesis | compiler | AD-4, AD-5 |
|
||||||
|
| FR-8 Contradictions | compiler + Concepts | AD-16 |
|
||||||
|
| FR-9 OKF compliance | `wiki/` | AD-1 |
|
||||||
|
| FR-10 Relationships | Markdown links | AD-8 |
|
||||||
|
| FR-11 Progressive discovery | hierarchy + indexes | AD-9 |
|
||||||
|
| FR-12 Incremental evolution | compiler | AD-5 |
|
||||||
|
| FR-13 Human curation | `wiki/` | AD-15 |
|
||||||
|
| FR-14 Change history | Git | AD-14 |
|
||||||
|
| FR-15 Tool-independent access | filesystem / Markdown | AD-1, AD-8, AD-9 |
|
||||||
|
| FR-16 Consumer independence | consumer boundary | AD-10, AD-13 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Stack
|
||||||
|
|
||||||
|
The MVP intentionally has no conventional application stack.
|
||||||
|
|
||||||
|
| Concern | Bound technology / standard |
|
||||||
|
|---|---|
|
||||||
|
| Knowledge representation | Open Knowledge Format 0.2 |
|
||||||
|
| Content | Markdown |
|
||||||
|
| Metadata | YAML Frontmatter according to OKF |
|
||||||
|
| Versioning | Git |
|
||||||
|
| Storage | Filesystem / Git repository |
|
||||||
|
| LLM | not bound |
|
||||||
|
| Agent runtime | not bound |
|
||||||
|
| Programming language | not bound |
|
||||||
|
| Database | none required |
|
||||||
|
| Vector database | none |
|
||||||
|
| Server runtime | none required |
|
||||||
|
| MCP | none required |
|
||||||
|
|
||||||
|
Any implementation technology introduced later must justify why the capability cannot reasonably be provided by the existing agent runtime plus filesystem operations.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Operational Envelope
|
||||||
|
|
||||||
|
## Local-first execution
|
||||||
|
|
||||||
|
The complete canonical system state can exist inside a normal Git working copy.
|
||||||
|
|
||||||
|
```text
|
||||||
|
git clone
|
||||||
|
↓
|
||||||
|
raw + wiki + compiler contract
|
||||||
|
↓
|
||||||
|
usable knowledge workspace
|
||||||
|
```
|
||||||
|
|
||||||
|
No central service is required to read the Knowledge Bundle.
|
||||||
|
|
||||||
|
## Failure behavior
|
||||||
|
|
||||||
|
A failed Compilation Run must not redefine source truth.
|
||||||
|
|
||||||
|
Because `raw/` is immutable, the original evidence remains available.
|
||||||
|
|
||||||
|
Git provides recovery of erroneous wiki mutations.
|
||||||
|
|
||||||
|
## Portability
|
||||||
|
|
||||||
|
Moving the repository to another machine or agent runtime must not require migration of the canonical knowledge.
|
||||||
|
|
||||||
|
## Environments & access
|
||||||
|
|
||||||
|
Where is the canonical read/write surface? In the MVP the canonical surface is the Git working copy and its remote (e.g. `main` as the canonical read surface; producer branches `lease/<area>/<id>` as the write surface, promoted to `main` via `log.md`-recorded merges). There is no deployment or separate environment, server, or service in the MVP (AD-11).
|
||||||
|
|
||||||
|
Security/access for v1 (PRD A-1: personal/team-internal tool) is deferred: who may write `raw/` vs. `wiki/`, who may set `verified`-trust, and how Git repo access (read vs. write) is granted to team members are decided as D-9 in the Deferred section rather than fixed by this spine.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Architectural Boundary
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
flowchart TB
|
||||||
|
subgraph Sources
|
||||||
|
C7[Context7]
|
||||||
|
DOC[Vendor Docs]
|
||||||
|
ARC[Arc42]
|
||||||
|
BMADA[BMAD Archive]
|
||||||
|
OTHER[Other Sources]
|
||||||
|
end
|
||||||
|
|
||||||
|
subgraph Core["Wiki of Wikis Core"]
|
||||||
|
RAW[Raw Source Collection]
|
||||||
|
SCM[Operator Contract: schema/wiki-compiler.md]
|
||||||
|
COMP[LLM Wiki Compiler]
|
||||||
|
OKF[OKF Knowledge Bundle]
|
||||||
|
end
|
||||||
|
|
||||||
|
subgraph Consumers
|
||||||
|
HUMAN[Humans]
|
||||||
|
BMAD[BMAD]
|
||||||
|
CLAUDE[Claude Code]
|
||||||
|
CODEX[Codex]
|
||||||
|
CG[CodeGraph]
|
||||||
|
SEARCH[Search / RAG]
|
||||||
|
end
|
||||||
|
|
||||||
|
C7 --> RAW
|
||||||
|
DOC --> RAW
|
||||||
|
ARC --> RAW
|
||||||
|
BMADA --> RAW
|
||||||
|
OTHER --> RAW
|
||||||
|
|
||||||
|
RAW --> COMP
|
||||||
|
OKF --> COMP
|
||||||
|
COMP --> OKF
|
||||||
|
SCM --> COMP
|
||||||
|
|
||||||
|
OKF --> HUMAN
|
||||||
|
OKF --> BMAD
|
||||||
|
OKF --> CLAUDE
|
||||||
|
OKF --> CODEX
|
||||||
|
OKF --> CG
|
||||||
|
OKF --> SEARCH
|
||||||
|
```
|
||||||
|
|
||||||
|
**Only the middle box is Wiki of Wikis.**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Deferred
|
||||||
|
|
||||||
|
The following decisions are deliberately not fixed by this spine.
|
||||||
|
|
||||||
|
## D-1 — Source acquisition adapters
|
||||||
|
|
||||||
|
Deferred until sources must be imported automatically.
|
||||||
|
|
||||||
|
Examples:
|
||||||
|
|
||||||
|
- HTTP fetch
|
||||||
|
- Context7 acquisition
|
||||||
|
- Git repositories
|
||||||
|
- PDFs
|
||||||
|
- BMAD artifacts
|
||||||
|
- local documentation trees
|
||||||
|
|
||||||
|
**Revisit when:** manual source materialization becomes a measurable bottleneck.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## D-2 — Retrieval engine
|
||||||
|
|
||||||
|
No search infrastructure is selected.
|
||||||
|
|
||||||
|
**Revisit when:** hierarchy, Markdown links and ordinary file search no longer allow an agent to find relevant Concepts reliably.
|
||||||
|
|
||||||
|
Possible future solutions are evaluated at that time rather than preselected.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## D-3 — Standalone compiler implementation
|
||||||
|
|
||||||
|
No Java, Python, Rust, TypeScript or other standalone application is selected.
|
||||||
|
|
||||||
|
**Revisit when:** the agent-instruction implementation proves insufficiently deterministic, testable or portable. (The determinism-enforcement mechanism of AD-17h / Q-6 is explicitly deferred and will likely live as an agent-instruction validator until then.)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## D-4 — MCP
|
||||||
|
|
||||||
|
No MCP Server is part of the MVP.
|
||||||
|
|
||||||
|
**Revisit when:** multiple Consumers need a shared runtime interface that cannot efficiently operate directly on the Knowledge Bundle.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## D-5 — Source deletion and replacement semantics
|
||||||
|
|
||||||
|
The MVP assumes additive Source ingestion.
|
||||||
|
|
||||||
|
**Revisit before:** supporting deletion, superseding or revocation of Sources.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## D-6 — Automatic stale-knowledge detection
|
||||||
|
|
||||||
|
Freshness metadata may be stored using OKF mechanisms.
|
||||||
|
|
||||||
|
Automatic detection of changed external truth is not part of the compiler core.
|
||||||
|
|
||||||
|
**Revisit when:** Sources representing mutable external systems become common.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## D-7 — Human review workflow
|
||||||
|
|
||||||
|
OKF metadata shall represent the resulting trust/review state.
|
||||||
|
|
||||||
|
A dedicated review workflow or UI is not selected.
|
||||||
|
|
||||||
|
**Revisit when:** multiple humans routinely review generated Concepts.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## D-8 — Query-to-Wiki writeback
|
||||||
|
|
||||||
|
Karpathy's pattern allows useful conclusions discovered during questions to become new Wiki knowledge.
|
||||||
|
|
||||||
|
This is not required for the first compiler MVP.
|
||||||
|
|
||||||
|
**Revisit after:** Source ingestion, provenance and incremental updates are demonstrably reliable.
|
||||||
|
|
||||||
|
## D-9 — Security & access model
|
||||||
|
|
||||||
|
For v1 no separate access model is selected: who may write `raw/` vs. `wiki/`, who may set `verified` trust metadata, and how team access (read vs. write) is granted follows the Git repository's own access controls.
|
||||||
|
|
||||||
|
**Revisit when:** more than one human routinely writes the wiki, or access boundaries become a requirement.
|
||||||
|
|
||||||
|
## D-10 — Exact OKF field-subset & validator
|
||||||
|
|
||||||
|
The exact OKF-0.2 field subset (list vs. map form of `sources`, `generated`/`verified`, `status` policing) and the concrete validator are pinned by `schema/wiki-compiler.md` (AD-1a) but not fixed by this spine.
|
||||||
|
|
||||||
|
**Revisit when:** the first validator / schema file is authored.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Open Questions
|
||||||
|
|
||||||
|
Die folgenden Fragen sind nicht als offene Entscheidungen zu behandeln, solange sie oben über eine ableitbare Regel (hoher +++, D-Items) bereits entschieden sind:
|
||||||
|
|
||||||
|
- Dateisystem-Case und Physical vs. Logical Path: durch AD-7a (eine kanonische ID-Normalisierung) entschieden.
|
||||||
|
- `log.md`-Format: durch AD-1a (Schema-Bindung) und § 9 von OKF entschieden.
|
||||||
|
- Verhältnis `raw/` vs. extern referenzierbare Sources: durch AD-4b entschieden (Sources-Einträge dürfen beide referenzieren, nie `wiki/`-Pfade).
|
||||||
|
|
||||||
|
## Q-1 — AD-4 Source grounding
|
||||||
|
|
||||||
|
Should a generated Concept ever be allowed to use another generated Concept as its sole provenance?
|
||||||
|
|
||||||
|
Current assumption: **No.**
|
||||||
|
|
||||||
|
Existing Concepts may supply context and synthesis, but material claims must remain transitively grounded in actual Sources.
|
||||||
|
|
||||||
|
(The enforceability of this was tightened in AD-4a/b/c: provenance is claim-granular and `sources` entries never point at `wiki/` paths.)
|
||||||
|
|
||||||
|
## Q-2 — Agent ownership
|
||||||
|
|
||||||
|
Should humans routinely edit generated Concepts directly?
|
||||||
|
|
||||||
|
Current interpretation:
|
||||||
|
|
||||||
|
```text
|
||||||
|
Human:
|
||||||
|
supplies sources
|
||||||
|
asks questions
|
||||||
|
reviews
|
||||||
|
corrects when necessary
|
||||||
|
|
||||||
|
Agent:
|
||||||
|
performs routine wiki maintenance
|
||||||
|
```
|
||||||
|
|
||||||
|
This follows the original LLM-Wiki model but does not prevent human edits.
|
||||||
|
|
||||||
|
The coexistence of human edit workflows and compiler runs is coordinated by AD-17e/f (dirty-tree protection, commit boundary as mutation boundary).
|
||||||
|
|
||||||
|
## Q-3 — Raw source location
|
||||||
|
|
||||||
|
Must all Sources be physically copied under `raw/`, or may `raw/` also contain stable references to external immutable resources?
|
||||||
|
|
||||||
|
This affects Source identity and reproducibility and should be resolved before implementation of Source intake.
|
||||||
|
|
||||||
|
(Partially answered by AD-4b: `sources` entries may reference `raw/` paths or external resources, never `wiki/` paths. Whether the external resources themselves must be materialized under `raw/` remains open.)
|
||||||
|
|
||||||
|
## Q-4 — Product name
|
||||||
|
|
||||||
|
Is **Wiki of Wikis** the final product name or only the project name?
|
||||||
|
|
||||||
|
This spine deliberately does not settle it: the frontmatter `name:` is the project name. **Owner:** Product Manager. **Revisit:** before the first external-facing documentation or a UX preparation.
|
||||||
|
|
||||||
|
## Q-5 — Source lifecycle & revocation
|
||||||
|
|
||||||
|
What happens to derived knowledge when a source is removed, replaced, or recognized as false?
|
||||||
|
|
||||||
|
This is currently only deferred (D-5: additive ingestion). The revocation case (false source) is not yet designed. **Owner:** Architecture. **Revisit:** before supporting deletion, superseding, or revocation of sources; must determine the revocation behavior (e.g., removing a provenance link from a Concept vs. deleting the Concept) without silently dropping claims that are still supported by other sources.
|
||||||
|
|
||||||
|
## Q-6 — Determinism envelope
|
||||||
|
|
||||||
|
How is "same Git state + same input set ⇒ same normalized bundle" enforced without a dedicated validator in the MVP (D-3, AD-17h)?
|
||||||
|
|
||||||
|
This is the enforcement mechanism behind the AD-17h determinism contract. It can live as an agent-instruction validator and must be confirmed mechanical before it becomes load-bearing on claims.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Architecture Fitness Tests
|
||||||
|
|
||||||
|
The architecture remains conformant only while all of the following are true.
|
||||||
|
|
||||||
|
### FT-1 — No-runtime test
|
||||||
|
|
||||||
|
Delete every optional runtime component.
|
||||||
|
|
||||||
|
The contents of `wiki/` remain understandable.
|
||||||
|
|
||||||
|
### FT-2 — Agent replacement test
|
||||||
|
|
||||||
|
Replace Claude Code with another capable agent.
|
||||||
|
|
||||||
|
No Knowledge Bundle migration is required.
|
||||||
|
|
||||||
|
### FT-3 — Retrieval replacement test
|
||||||
|
|
||||||
|
Replace grep with vector search or vice versa.
|
||||||
|
|
||||||
|
No Concept format changes.
|
||||||
|
|
||||||
|
### FT-4 — Rebuildability test
|
||||||
|
|
||||||
|
Delete all derived indexes.
|
||||||
|
|
||||||
|
The canonical knowledge remains intact.
|
||||||
|
|
||||||
|
### FT-5 — Provenance test
|
||||||
|
|
||||||
|
Select a generated Concept.
|
||||||
|
|
||||||
|
Its material source basis can be traced to actual Source Material.
|
||||||
|
|
||||||
|
### FT-6 — Incrementality test
|
||||||
|
|
||||||
|
Ingest one additional Source.
|
||||||
|
|
||||||
|
Unaffected Concepts do not require regeneration.
|
||||||
|
|
||||||
|
### FT-7 — Portability test
|
||||||
|
|
||||||
|
Clone the repository onto another machine.
|
||||||
|
|
||||||
|
The Knowledge Bundle is readable without Wiki-of-Wikis-specific software.
|
||||||
|
|
||||||
|
### FT-8 — Scope test
|
||||||
|
|
||||||
|
For every proposed new component ask:
|
||||||
|
|
||||||
|
> Is this component required to transform Sources plus existing Knowledge into improved Curated Knowledge?
|
||||||
|
|
||||||
|
If **no**, it belongs outside the Compiler Core unless a later architecture decision explicitly changes this boundary.
|
||||||
|
|
||||||
|
### FT-9 — Human correctability test
|
||||||
|
|
||||||
|
Take a machine-produced Concept. A human must be able to correct or amend it directly (file edit + Git), and the correction must survive as long as it is not itself contradicted by new evidence — without requiring re-compilation of the whole bundle. (Carries the A-1/SM-C3 guardrail "nachvollziehbar/korrigierbar > Autonomie".)
|
||||||
|
|
||||||
|
### FT-10 — Determinism / reproducibility test
|
||||||
|
|
||||||
|
Over the same Git state and the same input set, two independent runs must produce the same bundle state (formalizes AD-17h). If they diverge, the AD-16 classification is not deterministic enough.
|
||||||
@@ -0,0 +1,14 @@
|
|||||||
|
# source.md — Architecture Spine
|
||||||
|
|
||||||
|
Materialisiert als Quelle unter `raw/` (Story 1.2, AD-12).
|
||||||
|
|
||||||
|
- **Datei (Evidenz):** `architecture-spine-2026-08-14.md`
|
||||||
|
- **Herkunft (kanonisch):** `_bmad-output/planning-artifacts/architecture/architecture-wow20-2026-08-14/ARCHITECTURE-SPINE.md`
|
||||||
|
- **Kopie erstellt:** 2026-08-14
|
||||||
|
- **Kurzbeschreibung:** Architektur-Spine inkl. AD-2 (raw/ vs. wiki/), AD-3 (raw/ immutable), AD-12 (Source-Akquisition außerhalb des Compiler-Kerns).
|
||||||
|
|
||||||
|
## Provenienz-Hinweis
|
||||||
|
|
||||||
|
- Diese `source.md` ist ein Artefakt, **keine Evidenz** (vgl. `raw/README.md`).
|
||||||
|
- Herkunftspfade unter `_bmad-output/` sind generierte Planungs-Artefakte und im Repo nicht versioniert — Reproduktionshinweis, keine feste Referenz.
|
||||||
|
- Ändert sich die Herkunftsquelle, wird eine **neue, datierte Datei** angelegt (AD-3); diese Datei bleibt unverändert.
|
||||||
@@ -0,0 +1,471 @@
|
|||||||
|
---
|
||||||
|
stepsCompleted: ["1-requirements-extraction", "2-design-epics", "3-create-stories", "4-final-validation"]
|
||||||
|
inputDocuments:
|
||||||
|
- _bmad-output/specs/spec-wow20/SPEC.md
|
||||||
|
- _bmad-output/planning-artifacts/prds/prd-wow20-2026-08-14/prd.md
|
||||||
|
- _bmad-output/planning-artifacts/architecture/architecture-wow20-2026-08-14/ARCHITECTURE-SPINE.md
|
||||||
|
- _bmad-output/specs/spec-wow20/glossary.md
|
||||||
|
---
|
||||||
|
|
||||||
|
# wow20 - Epic Breakdown
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
This document provides the complete epic and story breakdown for wow20 — **Wiki of Wikis**, a knowledge compiler that decomposes the requirements from the PRD, the SPEC, and the Architecture Spine into implementable stories. It transforms `Sources + existing knowledge → improved curated knowledge` as an OKF-0.2-compliant, Git-versioned, agent-native file-based knowledge bundle.
|
||||||
|
|
||||||
|
## Requirements Inventory
|
||||||
|
|
||||||
|
### Functional Requirements
|
||||||
|
|
||||||
|
FR-1: Der Nutzer kann dem Compiler eine oder mehrere Sources zur Verarbeitung bereitstellen; in v1 nur lokal bereitgestelltes Source Material (keine URL-Abrufe).
|
||||||
|
FR-2: Das System unterscheidet Source Material (`raw/`) eindeutig und physisch vom kuratierten Knowledge Bundle (`wiki/`); eine Kopie einer Source ist keine Wissensintegration.
|
||||||
|
FR-3: Abgeleitetes Wissen bewahrt seine Provenienz; jede belegte Aussage trägt einen Inline-Beleg auf `raw/`; neue Quellen entfernen bestehende Provenienz nicht unbeabsichtigt.
|
||||||
|
FR-4: Ein Compilation Run verarbeitet neues Source Material zusammen mit relevantem bestehenden kuratierten Wissen; das bestehende Wiki ist Input.
|
||||||
|
FR-5: Der Compiler kann aus Source Material neue eigenständige Concepts erzeugen; Concepts sind nicht an die Source-Struktur gebunden.
|
||||||
|
FR-6: Der Compiler kann bestehende Concepts erweitern, präzisieren oder korrigieren; neue Informationen führen nicht automatisch zu neuen Dateien.
|
||||||
|
FR-7: Der Compiler synthetisiert Informationen aus mehreren Sources zu einer gemeinsamen Wissensrepräsentation mit gemischter Provenienz (keine getrennten Zusammenfassungen).
|
||||||
|
FR-8: Widersprüchliche Informationen werden nie stillschweigend zu einer scheinbar eindeutigen Aussage zusammengeführt; Disagreements bleiben in `log.md` sichtbar; Unsicherheit darf Teil eines Concepts sein.
|
||||||
|
FR-9: Alle erzeugten Concepts sind OKF-0.2-konform (Markdown + YAML-Frontmatter, `type` Pflichtfeld, optionale `sources`/`generated`/`verified`/`status`/`stale_after`); kein eigener OKF-Dialekt.
|
||||||
|
FR-10: Beziehungen zwischen Concepts werden mit normalen Markdown-Links ausgedrückt, in genau einer erlaubten Form (AD-7b: bundle-relativ, mit oder ohne Endung — nie beides).
|
||||||
|
FR-11: Das Knowledge Bundle ermöglicht Progressive Discovery über Hierarchie + `index.md`, ohne proprietäre Datenbank.
|
||||||
|
FR-12: Ein Compilation Run entwickelt das bestehende Knowledge Bundle inkrementell weiter; unverändertes Wissen bleibt erhalten.
|
||||||
|
FR-13: Vorhandene menschliche Kuratierung wird als bestehendes Wissen behandelt; sie wird nicht ohne Provenienz aus dem aktuellen Run entfernt; Konflikte mit neuen Sources werden sichtbar (AD-15).
|
||||||
|
FR-14: Änderungen an Concepts sind über normale Versionskontrolle nachvollziehbar (Git-Diff); kein proprietäres Change-Tracking.
|
||||||
|
FR-15: Ein Consumer liest das Knowledge Bundle ohne Wiki-of-Wikis-spezifische Runtime (normale Markdown-Tools bzw. Standard-Dateioperationen).
|
||||||
|
FR-16: Das Knowledge Bundle ist nicht auf einen bestimmten LLM-Agenten oder Workflow zugeschnitten; BMAD, Claude Code, Codex etc. sind Consumer (Compilersemantik agent-unabhängig, AD-10).
|
||||||
|
|
||||||
|
### NonFunctional Requirements
|
||||||
|
|
||||||
|
NFR-1: Portability — Das Knowledge Bundle muss ohne Wiki-of-Wikis-spezifische Software kopiert, archiviert und gelesen werden können.
|
||||||
|
NFR-2: Human Readability — Alle kanonischen Wissensinhalte müssen für Menschen unmittelbar als Markdown lesbar sein.
|
||||||
|
NFR-3: Agent Readability — Das Knowledge Bundle muss mit Standard-Dateioperationen durch LLM-Agenten erschließbar sein.
|
||||||
|
NFR-4: Version-Control Friendliness — Änderungen müssen in einer Form erfolgen, die sinnvolle textuelle Diffs ermöglicht.
|
||||||
|
NFR-5: No Mandatory Runtime — Das Lesen des Knowledge Bundle setzt weder Server noch Datenbank noch laufenden Wiki-of-Wikis-Prozess voraus.
|
||||||
|
NFR-6: Vendor Independence — Das kanonische Knowledge Bundle hängt von keinem LLM-Hersteller oder Agent Framework ab.
|
||||||
|
NFR-7: Graceful Partial Knowledge — Das System stellt unvollständiges, ungeprüftes oder teilweise widersprüchliches Wissen dar, ohne künstlich Gewissheit zu erzeugen.
|
||||||
|
|
||||||
|
### Additional Requirements
|
||||||
|
|
||||||
|
- **A0-1 — Schema-Vertrag (`schema/wiki-compiler.md`, AD-1a):** Verbindliches OKF-0.2-Feldsubset (Liste vs. Map-Form von `sources`, Zulässigkeit von `generated`/`verified`, `status`-Policing), `log.md`-Typdefinition, Index-Regel und Validitätsprädikate; schemaspezifische Validierung bindet das Feldsubset (AD-1a/1b).
|
||||||
|
- **A0-2 — OKF-Validierung (F-2/AD-1b):** Kein erfolgreicher Compilation Run bei OKF-invalidem Bundle laut `schema/wiki-compiler.md`; strukturelle Invalidität schlägt den Run fehl, fehlende optionale Felder nicht.
|
||||||
|
- **A0-3 — Claim-granulare Provenienz (AD-4a):** 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").
|
||||||
|
- **A0-4 — Provenienz-Ziellinie (AD-4b):** `sources`-Einträge lösen ausschließlich auf `raw/`-Pfade oder extern referenzierte immutable Evidenz auf — nie auf `wiki/`-Concept-Pfade.
|
||||||
|
- **A0-5 — Keine abgeleitete Provenienz (AD-4c):** Ein generiertes Concept darf nie ein anderes generiertes Concept als alleinige Provenienz führen (Teil der `schema/wiki-compiler.md`-Validierung).
|
||||||
|
- **A0-6 — Inkrementeller Datenfluss (AD-5):** Interpret → Reconcile → Synthesize → Update affected Concepts; niemals Regenerate Everything aus allen Rohquellen.
|
||||||
|
- **A0-7 — Reason/Mutate-Trennung (AD-6):** Analyse → Änderungsplanung → Mutation → Validierung; Endzustand muss konsistent sein; keine eigene Workflow Engine.
|
||||||
|
- **A0-8 — Concept-Identität (AD-7/7a):** Identität = relativer OKF-Pfad ohne `.md` (`wiki/spring/index.md` → `spring`); genau eine kanonische ID-Normalisierung; Renames sind semantische Änderungen mit `log.md`-Redirect (AD-7d).
|
||||||
|
- **A0-9 — Eine erlaubte Linkform (AD-7b):** AD-8-Links bundle-relativ, mit oder ohne Endung — genau eine Form, nie beide.
|
||||||
|
- **A0-10 — Deterministische Bereichszuordnung (AD-7c):** Wohin ein Thema gehört, wird textual-deterministisch bestimmt (bestehender `index.md`-Link oder Top-Level-Kollisions-Hold auf bestehende Pfade).
|
||||||
|
- **A0-11 — Konflikterhaltung (AD-16a/b):** Default bei Widerspruch ist Erhaltung (CONTRADICTING), außer die neue Source ersetzt die alte mit expliziter Evidenz (CORRECTING mit dokumentierter Ersetzungslogik); Klassifikation samt Begründung landet im selben Artefakt wie die Mutation — `log.md`-Eintrag, verknüpft mit dem mutierten Concept-Pfad.
|
||||||
|
- **A0-12 — Leasing-Konvention (AD-17/17a):** Producer arbeiten auf `lease/<area>/<id>`-Branches; ein Lockfile realisiert semantisch identisch in jedem Adapter; Lease-Akquise gegen eindeutigen Commit-Object-Wert (Merge-Base-Disziplin).
|
||||||
|
- **A0-13 — Lease-Root-Scope (AD-17b):** Die Lease umfasst `wiki/` inklusive `log.md`, `index.md` und aller Root-Dateien.
|
||||||
|
- **A0-14 — Kein textuelles Auto-Merge (AD-17c):** Zwei Branches mit Änderungen am selben Concept-Pfad werden nicht textuell automatisch gemerged; Merge ist compiler-vermittelt und durchläuft die AD-16-Klassifikation mit explizitem `log.md`-Eintrag bei ungleichem Inhalt.
|
||||||
|
- **A0-15 — Lease-Staleness (AD-17d):** TTL plus Lease-Registrierung im Clone-Root-State; uncommittete Leases gelten nach Run-Abbruch als stale; `raw/` (immutable, AD-3) ist die Recovery-Basis.
|
||||||
|
- **A0-16 — Dirty-Tree-Schutz (AD-17e/f):** Vor jeder Mutation Prüfung der Working Copy auf den mutierten Bereich; fremde uncommittete Änderungen werden geschützt (Stash/Scratch-Zone) und in `log.md` dokumentiert; Mutation nur auf Directory-/Commit-Ebene (Commit-Boundary = Mutation-Boundary).
|
||||||
|
- **A0-17 — Auflösungsautorität (AD-17g):** MVP: Der Compilation Run, der die Lease hält, löst AD-16-Kollisionen gemäß AD-16a-Default auf; menschliche Eskalation nur bei Unentscheidbarkeit; Auflösung gebunden an Commit-Hash + Klassifikation im `log.md`.
|
||||||
|
- **A0-18 — Deterministische Relevanzbestimmung (AD-13, AD-17, PRD OQ-3):** Wie der Compiler relevante vorhandene Concepts findet, wird mit textuellen, deterministischen Mitteln umgesetzt: grep/ripgrep, Markdown-Traversal, Link-Following — keine Embedding-/Vector-Infrastruktur.
|
||||||
|
- **A0-19 — Determinsmus-Vertrag (AD-17h/FT-10):** Über denselben Git-State und dasselbe Eingabeset produzieren zwei unabhängige Runs denselben Bundle-State; Validierungsmechanismus (D-3/Q-6) lebt zunächst als Agent-Instruktions-Validator.
|
||||||
|
- **A0-20 — A0-Trust-Metadaten v1 (AD-15, PRD A-1/SM-C3):** v1-Default: maschinell erzeugt und ungeprüft → `generated: { by, at }` gesetzt, `verified` ungesetzt; human reviewed → `verified` mit `human:`-Präfix; Lifecycle via `status` (`draft`|`stable`|`deprecated`) und optional `stale_after`.
|
||||||
|
- **A0-21 — Inkrementelle Evolution (AD-5, FT-6/FT-9):** Unabhängige Concepts werden nicht bei jedem Lauf regeneriert; eine menschliche Korrektur eines maschinell erzeugten Concepts überlebt als normale Kuratierung (Datei-Edit + Git) — kein Nulling-Diff.
|
||||||
|
- **A0-22 — Agent-unabhängiger Kompiliervertrag (AD-10):** Kanonische Compiler-Regeln werden agent-unabhängig beschrieben; Provider-/Agenten-Instruktionen sind dünne Adapter (`adapters/claude|codex|...`), die keine abweichende Knowledge-Semantik definieren.
|
||||||
|
|
||||||
|
### UX Design Requirements
|
||||||
|
|
||||||
|
Keine UX-Design-Anforderungen im MVP berücksichtigt: PRD A-3 (keine GUI in v1), AD-11 (kein Serverprozess). Retained: keine UI-Tokens, keine Komponenten, keine Accessibility-Anforderungen für grafische Oberflächen.
|
||||||
|
|
||||||
|
## Epic List
|
||||||
|
|
||||||
|
### Epic 1: Wissens-Workspace & Quellen-Aufnahme
|
||||||
|
Der Nutzer richtet den kanonischen Wissens-Workspace ein (`raw/` | `wiki/` | `schema/` | `adapters/`), stellt Sources lokal bereit, und kann Source Material jederzeit vom kuratierten Wissen unterscheiden. Der Workspace ist Git-versioniert und zerlegt Sources/Knowledge gemäß Separation of Concerns; die OKF-Schema-Validierung (F-2/AD-1b) verhindert erfolgreiche Runs auf invaliden Bundles.
|
||||||
|
**FRs covered:** FR-1, FR-2
|
||||||
|
**NFRs covered:** NFR-1, NFR-4
|
||||||
|
**AD/A0:** AD-2, AD-3, AD-12, AD-1a, AD-1b, A0-1, A0-2
|
||||||
|
|
||||||
|
### Epic 2: OKF-Concepts erzeugen & verlinken
|
||||||
|
Aus den Sources entstehen eigenständige, OKF-0.2-konforme Concepts mit claim-granularer Provenienz und v1-Trust-Metadaten (`generated` ohne `verified`); Concepts werden über genau eine Markdown-Linkform (AD-7b) miteinander verlinkt, über eine deterministische Bereichszuordnung (AD-7c) in eine Bundle-Hierarchie eingeordnet und über `index.md` progressiv entdeckbar.
|
||||||
|
**FRs covered:** FR-3, FR-5, FR-9, FR-10, FR-11
|
||||||
|
**NFRs covered:** NFR-2, NFR-3, NFR-7
|
||||||
|
**AD/A0:** AD-1, AD-4, AD-4a, AD-4b, AD-4c, AD-7, AD-7a..7d, AD-8, AD-9, A0-3, A0-4, A0-5, A0-8, A0-9, A0-10, A0-20
|
||||||
|
|
||||||
|
### Epic 3: Inkrementelle Kompilation & Synthese
|
||||||
|
Der Nutzer verarbeitet neue Sources gegen das bestehende Wiki: bestehende Concepts werden erweitert, präzisiert oder korrigiert; mehrere Sources werden zu einer gemeinsamen Wissensrepräsentation synthetisiert; unverändertes Wissen bleibt erhalten. Die Relevanzbestimmung erfolgt textual-deterministisch (grep/ripgrep/Traversal, AD-13); Producer arbeiten auf `lease/<area>/<id>`-Branches mit Dirty-Tree-Schutz, Root-Scope-Lease und commit-gebundener Mutation (AD-17a..h).
|
||||||
|
**FRs covered:** FR-4, FR-6, FR-7, FR-12
|
||||||
|
**NFRs covered:** NFR-7
|
||||||
|
**AD/A0:** AD-5, AD-6, AD-13, AD-17, AD-17a..17h, A0-6, A0-7, A0-12..A0-18, A0-19, A0-21
|
||||||
|
|
||||||
|
### Epic 4: Wissenstreue — Widersprüche & menschliche Kuratierung
|
||||||
|
Widersprüche werden nie stillschweigend zur scheinbar eindeutigen Aussage zusammengeführt; relevante Disagreements bleiben als explizite Einträge in `log.md` erhalten; menschlich kuratierte Inhalte werden als bestehendes Wissen respektiert und bleiben über OKF-Trust-Metadaten (`verified: human:...`) von ungeprüftem maschinellem Output unterscheidbar; unvollständiges/ungeprüftes Wissen wird ohne künstliche Gewissheit dargestellt.
|
||||||
|
**FRs covered:** FR-8, FR-13
|
||||||
|
**NFRs covered:** NFR-7
|
||||||
|
**AD/A0:** AD-16, AD-16a, AD-16b, AD-15, A0-11, A0-17, A0-20
|
||||||
|
|
||||||
|
### Epic 5: Consumer-Zugriff & Nachvollziehbarkeit
|
||||||
|
Menschen und beliebige LLM-Agenten (BMAD, Claude Code, Codex, ...) lesen das Knowledge Bundle ohne Wiki-of-Wikis-spezifische Runtime; Änderungen sind über Git-Diffs nachvollziehbar; die kanonischen Compiler-Regeln sind agent-unabhängig mit dünnen Adaptern; es gibt keinen obligatorischen Server, keine Datenbank und keine proprietäre Abhängigkeit.
|
||||||
|
**FRs covered:** FR-14, FR-15, FR-16
|
||||||
|
**NFRs covered:** NFR-1, NFR-3, NFR-5, NFR-6
|
||||||
|
**AD/A0:** AD-10, AD-11, AD-13, AD-14, A0-21, A0-22
|
||||||
|
|
||||||
|
### FR Coverage Map
|
||||||
|
|
||||||
|
FR1: Epic 1 - Sources bereitstellen (lokal, 1..n)
|
||||||
|
FR2: Epic 1 - Sources vs. Curated Knowledge trennen
|
||||||
|
FR3: Epic 2 - Provenienz bewahren (claim-granular auf raw/)
|
||||||
|
FR4: Epic 3 - Sources gegen bestehendes Wissen verarbeiten
|
||||||
|
FR5: Epic 2 - Neue Concepts erzeugen
|
||||||
|
FR6: Epic 3 - Bestehende Concepts aktualisieren
|
||||||
|
FR7: Epic 3 - Wissen synthetisieren (mehrere Sources)
|
||||||
|
FR8: Epic 4 - Widersprüche sichtbar behandeln
|
||||||
|
FR9: Epic 2 - OKF-konforme Concepts erzeugen
|
||||||
|
FR10: Epic 2 - Concepts mit Markdown-Links verlinken
|
||||||
|
FR11: Epic 2 - Progressive Discovery (Hierarchie + index.md)
|
||||||
|
FR12: Epic 3 - Knowledge Bundle inkrementell weiterentwickeln
|
||||||
|
FR13: Epic 4 - Menschliche Kuratierung berücksichtigen
|
||||||
|
FR14: Epic 5 - Änderungen nachvollziehbar machen (Git)
|
||||||
|
FR15: Epic 5 - Tool-unabhängigen Zugriff
|
||||||
|
FR16: Epic 5 - Consumer vom Compiler entkoppeln
|
||||||
|
|
||||||
|
## Epic 1: Wissens-Workspace & Quellen-Aufnahme
|
||||||
|
|
||||||
|
Der Nutzer richtet den kanonischen Wissens-Workspace ein (`raw/` | `wiki/` | `schema/` | `adapters/`), stellt Sources lokal bereit und unterscheidet Source Material jederzeit vom kuratierten Wissen. Der Workspace ist Git-versioniert und zerlegt Sources/Knowledge gemäß Separation of Concerns; die OKF-Schema-Validierung (F-2/AD-1b) verhindert erfolgreiche Runs auf invaliden Bundles.
|
||||||
|
**FRs covered:** FR-1, FR-2 · **NFRs:** NFR-1, NFR-4 · **AD/A0:** AD-2, AD-3, AD-12, AD-1a, AD-1b, A0-1, A0-2
|
||||||
|
|
||||||
|
### Story 1.1: Kanonischen Workspace-Stamm erstellen
|
||||||
|
|
||||||
|
As a Nutzer/Compiler,
|
||||||
|
I want den kanonischen Workspace-Stamm mit `raw/`, `wiki/`, `schema/`, `adapters/` und einer OKF-Bundleroot (`wiki/index.md` mit `okf_version: "0.2"`) einzurichten,
|
||||||
|
So that Source Material (immutable Evidenz) physisch und semantisch getrennt vom kuratierten OKF-Knowledge Bundle liegt (FR-1, FR-2, AD-2, AD-3).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** ein leerer Git-repo-fähiger Projektordner, **When** der Workspace-Stamm initialisiert wird, **Then** existieren die Verzeichnisse `raw/`, `wiki/`, `schema/` und `adapters/` (AD-2, AD-10).
|
||||||
|
**Given** die Initialisierung, **When** `wiki/` angelegt wird, **Then** existiert eine Bundleroot `wiki/index.md` mit Frontmatter `okf_version: "0.2"` und `type: bundle` sowie eine leere `wiki/log.md` (AD-1, AD-9).
|
||||||
|
**Given** die Bundleroot, **When** ein Consumer oder Agent den Workspace scannt, **Then** unterscheiden sich `raw/` (Evidenz) und `wiki/` (kuratiertes Wissen) eindeutig über ihre Verzeichnisgrenzen (FR-2, AD-2).
|
||||||
|
**And** `schema/wiki-compiler.md` und `adapters/` (z.B. `adapters/claude/`) existieren als Platzhalter außerhalb des Bundles — nicht als Concept-Dateien (AD-1a, AD-10).
|
||||||
|
|
||||||
|
### Story 1.2: Sources lokal unter `raw/` bereitstellen
|
||||||
|
|
||||||
|
As a Nutzer,
|
||||||
|
I want eine oder mehrere lokale Sources (Dokumente, Spezifikationen, Projektartefakte) unter `raw/` zu materialisieren,
|
||||||
|
So that der Compiler sie in einem Compilation Run verarbeiten kann, ohne dass ich vorab über die Wiki-Struktur entscheiden muss (FR-1, AD-12, A-4).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** ein initialisierter Workspace, **When** ich eine einzelne Quelle unter `raw/` platziere, **Then** wird sie als immutable Source Material erkannt und nicht automatisch nach `wiki/` kopiert (FR-2, AD-3).
|
||||||
|
**Given** ein initialisierter Workspace, **When** ich mehrere Quellen (1..n) bereitstelle, **Then** akzeptiert der Compiler sie für einen Run als Eingabe.
|
||||||
|
**Given** eine bereits verarbeitete Source, **When** ein weiterer Compilation Run sie erneut verarbeitet, **Then** bleibt die Originaldatei unter `raw/` unverändert (AD-3).
|
||||||
|
**Given** der manuelle Source-Import (v1), **When** eine URL statt lokalen Materials angegeben wird, **Then** wird dies als nicht unterstützt zurückgewiesen (A-4: keine URL-Abrufe im MVP).
|
||||||
|
|
||||||
|
### Story 1.3: OKF-Schema-Vertrag `schema/wiki-compiler.md` autorisieren
|
||||||
|
|
||||||
|
As a Konsument des Schema-Vertrags,
|
||||||
|
I want mit `schema/wiki-compiler.md` verbindlich das erlaubte OKF-0.2-Feldsubset festzulegen,
|
||||||
|
So that alle Producer (Compiler/Adapter) validierbar, portabel und deterministisch dieselben Regeln anwenden (AD-1a, AD-1b, FR-9, NFR-6).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** der Schemadatei-Standort `schema/wiki-compiler.md`, **When** das Schema autorisiert wird, **Then** definiert es das OKF-Feldsubset (u.a. Liste-vs.-Map-Form von `sources`, Zulässigkeit von `generated`/`verified`, `status`-Policing) sowie Validitätsprädikate für Concepts und Bundle-Root.
|
||||||
|
**Given** das Schema, **When** ein Concept erzeugt wird, **Then** gilt `type` als einziges Pflichtfeld; optionale Felder (`sources`, `generated`, `verified`, `status`, `stale_after`) werden als Subset validiert (AD-1a).
|
||||||
|
**Given** das Schema, **When** ein neues Area-Verzeichnis in `wiki/` angelegt wird, **Then** bindet es die Index-Regel (`index.md` vorhanden) und die `log.md`-Typdefinition (AD-1a).
|
||||||
|
**And** das Schema bindet das Verbot: `sources`-Einträge lösen niemals auf `wiki/`-Concept-Pfade auf (AD-4b, A0-4).
|
||||||
|
|
||||||
|
### Story 1.4: Schema-Validierung für Bundle implementieren
|
||||||
|
|
||||||
|
As ein Compiler,
|
||||||
|
I want vor jeder Mutation das Bundle gegen `schema/wiki-compiler.md` zu validieren,
|
||||||
|
So that ein OKF-invalides Bundle nie als erfolgreicher Run gilt (F-2/AD-1b, A0-2, FR-9).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** ein Bundle mit struktureller OKF-Invalidität (z.B. fehlender `type`), **When** ein Compilation Run versucht zu mutieren, **Then** schlägt der Run fehl und meldet einen Validierungsfehler — kein erfolgreicher Run (F-2/AD-1b).
|
||||||
|
**Given** ein Bundle mit fehlenden optionalen Feldern (kein `sources`/`verified`), **When** ein Compilation Run läuft, **Then** gilt der Run nicht als invalide (F-2: strukturell-invalid, nicht bei fehlenden optionalen Feldern).
|
||||||
|
**Given** ein invalides Bundle, **When** ein Run fehlschlägt, **Then** bleibt `raw/` unverändert und die Fehlerursache ist textuell identifizierbar (AD-3, NFR-4).
|
||||||
|
**And** die Validierung ist als eigenständige, deterministische Prüfung ohne LLM-Urteil aufrufbar (AD-13/AD-17h-konform).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Epic 2: OKF-Concepts erzeugen & verlinken
|
||||||
|
|
||||||
|
Aus den Sources entstehen eigenständige, OKF-0.2-konforme Concepts mit claim-granularer Provenienz und v1-Trust-Metadaten (`generated` ohne `verified`); Concepts werden über genau eine Markdown-Linkform (AD-7b) verlinkt, über deterministische Bereichszuordnung (AD-7c) in eine Bundle-Hierarchie eingeordnet und über `index.md` progressiv entdeckbar.
|
||||||
|
**FRs covered:** FR-3, FR-5, FR-9, FR-10, FR-11 · **NFRs:** NFR-2, NFR-3, NFR-7 · **AD/A0:** AD-1, AD-4, AD-4a, AD-4b, AD-4c, AD-7, AD-7a..7d, AD-8, AD-9, A0-3, A0-4, A0-5, A0-8, A0-9, A0-10, A0-20
|
||||||
|
|
||||||
|
### Story 2.1: Concepts aus Source Material erzeugen (OKF-Konform)
|
||||||
|
|
||||||
|
As a Nutzer,
|
||||||
|
I want dass der Compiler aus Source Material neue, eigenständige OKF-0.2-Concepts erzeugt,
|
||||||
|
So that neues kuratiertes Wissen entsteht, das nicht an die Struktur der Source gebunden ist (FR-5, FR-9, AD-5, AD-7).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** eine neue Source mit mehreren Abschnitten, **When** ein Compilation Run sie verarbeitet, **Then** erzeugt der Compiler eigenständige Concepts gemäß der erkannten Wissenseinheiten — nicht 1:1 pro Abschnitt, und nicht an die Source-Struktur gebunden (FR-5).
|
||||||
|
**Given** die Concept-Erzeugung, **When** ein Concept geschrieben wird, **Then** ist es OKF-0.2-konform: Markdown mit YAML-Frontmatter, `type` als verpflichtendes Feld (AD-1a, FR-9).
|
||||||
|
**Given** ein erzeugtes Concept, **When** dessen V1-Trust-Metadaten gesetzt werden, **Then** sind sie `generated: { by, at }` ohne `verified` (AD-15: v1-Default maschinell erzeugt und ungeprüft).
|
||||||
|
**And** mehrere Source-Abschnitte können in unterschiedliche Concepts einfließen (FR-5: keine Bindung an Source-Struktur).
|
||||||
|
|
||||||
|
### Story 2.2: Claim-granulare Provenienz dokumentieren
|
||||||
|
|
||||||
|
As a Nutzer/Compiler,
|
||||||
|
I want dass jede belegte Aussage in einem Concept einen Inline-Verweis auf `raw/`-Evidenz trägt,
|
||||||
|
So that die Herkunft des Wissens claim-granular nachvollziehbar bleibt (FR-3, AD-4a, A0-3).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** ein Concept mit fachlichen Aussagen, **When** es erzeugt wird, **Then** hat jede belegte Aussage einen Inline-Verweis auf `raw/`-Evidenz (AD-4a).
|
||||||
|
**Given** eine Kontext-/Synthese-Umformulierung, **When** sie in ein Concept übernommen wird, **Then** trägt sie einen expliziten Kontext-Marker ("übernommen aus <Concept-Pfad> auf Basis von <source>, nicht eigenständig belegt") (AD-4a, A0-3).
|
||||||
|
**Given** ein Concept mit mehreren Quellen, **When** deren `sources` dokumentiert werden, **Then** lösen diese ausschließlich auf `raw/`-Pfade oder externe immutable Evidenz auf — nie auf `wiki/`-Concept-Pfade (AD-4b, A0-4).
|
||||||
|
**And** ein generiertes Concept darf niemals ein anderes generiertes Concept als alleinige Provenienz führen (AD-4c, A0-5) — prüfbar über das Schema.
|
||||||
|
|
||||||
|
### Story 2.3: Concepts verlinken (eine erlaubte Linkform)
|
||||||
|
|
||||||
|
As a Consumer/Compiler,
|
||||||
|
I want Beziehungen zwischen Concepts mit normalen Markdown-Links auszudrücken — in genau einer erlaubten Form,
|
||||||
|
So that Concepts navigierbar bleiben und zwei Producer nie unterschiedliche IDs aus demselben Baum berechnen (FR-10, AD-7b, AD-8, A0-9).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** zwei zusammengehörige Concepts, **When** eine Beziehung ausgedrückt wird, **Then** nutzt sie einen normalen Markdown-Link in genau einer erlaubten Form: bundle-relativ, mit oder ohne Endung — nie beides (AD-7b, A0-9).
|
||||||
|
**Given** der Link-Form-Standard (unabhängig von Endungs-Wahl), **When** ein Consumer die Links traversiert, **Then** sind die Ziel-Concepts auffindbar (FR-10, AD-8).
|
||||||
|
**Given** ein Link, **When** er gespeichert wird, **Then** verändert er weder den Concept-Inhalt der Quelle noch das Knowledge-Modell (Links sind die Navigations-/Beziehungsschicht, nicht die Provenienz).
|
||||||
|
**And** keine proprietäre Link-Datenbank ist nötig; Konsumenten ohne Wiki-of-Wikis-Software können den Link verstehen (FR-10, AD-8).
|
||||||
|
|
||||||
|
### Story 2.4: Deterministische Bereichszuordnung & Concept-Hierarchie
|
||||||
|
|
||||||
|
As a Compiler,
|
||||||
|
I want neu erkannte Themen textual-deterministisch einem bestehenden Bereich (Area) oder einem neuen `index.md`-Bereich zuzuordnen,
|
||||||
|
So that die Concept-Identität eine stabile, kanonische Form hat und der Baum nicht vom Producer-Willkür abhängt (AD-7, AD-7a, AD-7c, A0-8, A0-10).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** ein erkanntes Thema, **When** der Bereich bestimmt wird, **Then** geschieht dies textual-deterministisch (bestehender `index.md`-Link oder Top-Level-Kollisions-Hold auf bestehende Pfade) — nicht per Embedding (A0-10, AD-13).
|
||||||
|
**Given** die Concept-Identität, **When** ein Concept abgelegt wird, **Then** entspricht sie dem relativen OKF-Pfad ohne `.md` (`wiki/spring/index.md` → `spring`) mit genau einer kanonischen ID-Normalisierung (AD-7a, A0-8).
|
||||||
|
**Given** eine Bereichsnavigation, **When** ein Consumer sich orientiert, **Then** führt die Hierarchie (Area-`index.md`) schrittweise zu den Concepts (AD-9, FR-11).
|
||||||
|
**And** ein Konflikt mit einem existierenden Top-Level-Pfad löst einen Kollisions-Hold aus, statt stillschweigend zu überschreiben (A0-10).
|
||||||
|
|
||||||
|
### Story 2.5: Progressive Discovery über `index.md` bereitstellen
|
||||||
|
|
||||||
|
As a Consumer/Compiler,
|
||||||
|
I want dass das Knowledge Bundle über `index.md`-Indexstrukturen progressiv entdeckbar ist,
|
||||||
|
So that ein Consumer relevantes Wissen schrittweise findet, ohne das gesamte Wiki lesen zu müssen (FR-11, AD-9, A0-10).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** ein Bundle mit mehreren Areas, **When** ein Consumer die Navigation startet, **Then** liest er zunächst die Bundle-Root `wiki/index.md` und dann relevante Area-`index.md` (AD-9).
|
||||||
|
**Given** die Hierarchie, **When** ein Concept neu angelegt wird, **Then** wird es passend in `index.md` des zugehörigen Bereichs verlinkt (AD-9, A0-10).
|
||||||
|
**Given** eine Suche (optional spätere Optimierung), **When** der Consumer sie nutzt, **Then** ist sie klar extern bzw. Consumer-seitig — die Discovery selbst braucht keine proprietäre Datenbank (AD-9, FR-11).
|
||||||
|
**And** das Bundle bleibt ohne geladene Indizes (z.B. nach Git-Clone) vollständig verständlich (NFR-2, NFR-5, AD-1).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Epic 3: Inkrementelle Kompilation & Synthese
|
||||||
|
|
||||||
|
Der Nutzer verarbeitet neue Sources gegen das bestehende Wiki: bestehende Concepts werden erweitert, präzisiert oder korrigiert; mehrere Sources werden zu einer gemeinsamen Wissensrepräsentation synthetisiert; unverändertes Wissen bleibt erhalten. Relevanzbestimmung erfolgt textual-deterministisch (grep/ripgrep/Traversal, AD-13); Producer arbeiten auf `lease/<area>/<id>`-Branches mit Dirty-Tree-Schutz, Root-Scope-Lease und commit-gebundener Mutation (AD-17a..h).
|
||||||
|
**FRs covered:** FR-4, FR-6, FR-7, FR-12 · **NFRs:** NFR-7 · **AD/A0:** AD-5, AD-6, AD-13, AD-17, AD-17a..17h, A0-6, A0-7, A0-12..A0-18, A0-19, A0-21
|
||||||
|
|
||||||
|
### Story 3.1: Inkrementellen Datenfluss implementieren (Interpret → Reconcile → Synthesize → Update)
|
||||||
|
|
||||||
|
As a Compiler,
|
||||||
|
I want neue Sources nur gegen die tatsächlich betroffenen Concepts zu verarbeiten,
|
||||||
|
So that unverändertes Wissen bewahrt bleibt und Wissen nicht bei jedem Lauf aus Rohquellen neu aufgebaut wird (FR-4, FR-12, AD-5, A0-6, SM-1, FT-6).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** ein bestehendes Bundle und neue Source Material, **When** ein Compilation Run startet, **Then** folgt er dem inkrementellen Datenfluss: Interpret → Reconcile → Synthesize → Update affected Concepts (AD-5, A0-6).
|
||||||
|
**Given** ein Run, **When** er einen bestehenden Concept-Pfad nicht betrifft, **Then** bleibt dessen Inhalt unverändert erhalten — keine Regeneration (FT-6, FR-12).
|
||||||
|
**Given** ein Lauf, **When** er abgeschlossen ist, **Then** konzentrieren sich die Git-Änderungen auf durch die neue Erkenntnis betroffene Concepts (AD-5, FR-6).
|
||||||
|
**And** der Run verwendet published/committed Inhalte als Input und niemals Zwischenstände während der Mutation (AD-17.2).
|
||||||
|
|
||||||
|
### Story 3.2: Relevanzbestimmung textual-deterministisch umsetzen (grep/ripgrep/Traversal)
|
||||||
|
|
||||||
|
As a Compiler,
|
||||||
|
I want relevante vorhandene Concepts zu einer neuen Source zu finden — mit grep/ripgrep, Markdown-Traversal und Link-Following,
|
||||||
|
So dass ohne Embedding-/Vector-Infrastruktur deterministisch bestimmt wird, welche Concepts zu prüfen sind (PRD OQ-3, AD-13, AD-17 Appendix, A0-18).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** eine neue Source, **When** der Run die Relevanzbestimmung durchführt, **Then** nutzt er ausschließlich textuelle, deterministische Verfahren (Term-übergreifende grep/ripgrep auf `wiki/`; Markdown-Traversal von `index.md`; Link-Following) (AD-13, A0-18).
|
||||||
|
**Given** gleiche Git-State + gleiche Eingabemenge, **When** zwei unabhängige Runs die Relevanzbestimmung ausführen, **Then** erzeugen sie dasselbe Ergebnis (Ad-17h-Determinsmus, A0-19).
|
||||||
|
**Given** ein Ergebnis der Relevanzbestimmung, **When** es in einem Run weiterverarbeitet wird, **Then** ist es als nachvollziehbare Candidate-Liste (Concept-Pfade) verfügbar — deterministisch statt probabilistisch.
|
||||||
|
**And** es findet kein Einsatz von Embeddings, Vektor-Suche oder Knowledge-Graph-Datenbank im Compiler-Kern statt (AD-13, No-Goals).
|
||||||
|
|
||||||
|
### Story 3.3: Bestehende Concepts erweitern/präzisieren/korrigieren
|
||||||
|
|
||||||
|
As a Compiler,
|
||||||
|
I want bestehende Concepts zu aktualisieren, ohne automatisch neue Dateien anzulegen,
|
||||||
|
So dass neues Wissen das vorhandene kuratierte Wissen ergänzt, präzisiert oder korrigiert (FR-6, AD-5).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** eine neue Erkenntnis zu einem bestehenden Concept, **When** der Run sie verarbeitet, **Then** erweitert er das bestehende Concept anstelle der Anlage einer neuen Datei (FR-6).
|
||||||
|
**Given** eine präzisierende Information, **When** sie eingearbeitet wird, **Then** wird der Text präzisiert oder korrigiert, ohne die Struktur zu zerstören.
|
||||||
|
**Given** eine Aktualisierung, **When** sie erfolgt, **Then** bleiben Beziehungen und Provenienz bestehender Concepts soweit weiterhin gültig erhalten (FR-6).
|
||||||
|
**And** die Mutation erfolgt nur innerhalb des geleasten Bereichs (AD-17.3).
|
||||||
|
|
||||||
|
### Story 3.4: Wissen aus mehreren Sources synthetisieren
|
||||||
|
|
||||||
|
As a Nutzer,
|
||||||
|
I want dass der Compiler Informationen aus mehreren Sources zu einer gemeinsamen Wissensrepräsentation zusammenführt,
|
||||||
|
So dass kein separates Summary pro Quelle entsteht und die gemischte Provenienz erhalten bleibt (FR-7, AD-4, AD-5).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** mehrere Sources zum selben Thema, **When** der Run synthetisiert, **Then** entsteht eine gemeinsame Wissensrepräsentation statt mehrerer getrennter Zusammenfassungen (FR-7).
|
||||||
|
**Given** eine Synthese aus mehreren Concepts/Sources, **When** das resultierende Concept erzeugt wird, **Then** übernimmt es relevante Source-Provenienz der beteiligten Sources (AD-4) — claim-granular mit Inline-Verweisen (A0-3).
|
||||||
|
**Given** redundante Informationen aus mehreren Sources, **When** sie synthetisiert werden, **Then** werden sie konsolidiert, ohne Provenienz zu verlieren (FR-7).
|
||||||
|
**And** das resultierende Concept reflektiert den erkannten Wissensstand — keine bloße Aneinanderreihung von Source-Zusammenfassungen (FR-7).
|
||||||
|
|
||||||
|
### Story 3.5: Leasing & Dirty-Tree-Schutz für konkurrierende Producer umsetzen
|
||||||
|
|
||||||
|
As a Producer/Compiler,
|
||||||
|
I want auf `lease/<area>/<id>`-Branches mit Root-Scope-Lease und Dirty-Tree-Schutz zu arbeiten,
|
||||||
|
So dass zwei Producer denselben Concept-Pfad nicht stillschweigend überschreiben und Fremdänderungen nie als Nebenwirkung gelöscht werden (AD-17, AD-17a..f, A0-12..A0-16).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** ein Producer, **When** er einen Bereich bearbeitet, **Then** arbeitet er auf einem `lease/<area>/<id>`-Branch und akquiriert die Lease gegen einen eindeutigen Commit-Object-Wert (Merge-Base-Disziplin) (AD-17a, A0-12).
|
||||||
|
**Given** eine Lease, **When** sie vergeben ist, **Then** umfasst sie die Root-Scope inklusive `log.md`, `index.md` und aller Root-Dateien (AD-17b, A0-13).
|
||||||
|
**Given** eine vorliegende uncommittete Fremdänderung im zu mutierenden Bereich, **When** der Producer mutieren will, **Then** schützt er sie (Stash/Scratch-Zone) und dokumentiert den Vorgang in `log.md` (AD-17e, A0-16).
|
||||||
|
**Given** zwei Branches mit Änderungen am selben Concept-Pfad, **When** gemerged werden soll, **Then** erfolgt kein stiller textueller Auto-Merge (AD-17c, A0-14) — Auflösung compiler-vermittelt über AD-16 mit explizitem `log.md`-Eintrag.
|
||||||
|
**And** Mutationen operieren nur auf Directory-/Commit-Ebene — Commit-Boundary ist die Mutation-Boundary (AD-17f, A0-16).
|
||||||
|
|
||||||
|
### Story 3.6: Lease-Staleness & Recovery-Basis absichern
|
||||||
|
|
||||||
|
As a Consumer/Operator,
|
||||||
|
I want dass uncommittete Leases nach Run-Abbruch als stale gelten und `raw/` als Recovery-Basis dient,
|
||||||
|
So dass ein abgebrochener Run nie dauerhaft Wissen blockiert und die Evidenzbasis intakt bleibt (AD-17d, A0-15).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** ein abgebrochener Run, **When** uncommittete Leases hinterlassen wurden, **Then** gelten sie als stale (TTL plus Lease-Registrierung im Clone-Root-State) und blockieren keine nachfolgenden Runs (AD-17d, A0-15).
|
||||||
|
**Given** ein abgebrochener Run, **When** jeweilige uncommittete Änderungen wiederhergestellt werden sollen, **Then** dient `raw/` (immutable, AD-3) als Zugriffs- und Consistency-Basis (AD-17d, A0-15).
|
||||||
|
**Given** ein neuer Run, **When** er eine verwaiste Lease vorfindet, **Then** kann er die Lease übernehmen oder als stale markieren und protokollieren (AD-17d).
|
||||||
|
**And** `raw/` wird bei keinem dieser Vorgänge verändert (AD-3).
|
||||||
|
|
||||||
|
### Story 3.7: Reason/Mutate-Trennung und Konsistenz-Endzustand sicherstellen
|
||||||
|
|
||||||
|
As a Compiler,
|
||||||
|
I want Analyse, Änderungsplanung, Mutation und Validierung logisch zu trennen,
|
||||||
|
So dass ein teilweise fehlgeschlagener Run nie ein inkonsistentes Bundle hinterlässt (AD-6, A0-7).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** ein Run, **When** er Änderungen plant, **Then** erzeugt er zunächst eine konsistente Änderungsplanung (Analyse → Reconcile → Plan Changes → Mutate → Validate) (AD-6, A0-7).
|
||||||
|
**Given** ein Fehler während der Mutation, **When** der Run abbricht, **Then** bleibt der beobachtbare Endzustand des Bundles konsistent (AD-6).
|
||||||
|
**Given** ein Run, **When** er abgeschlossen ist, **Then** wurden alle geplanten Mutations-Validierungen erfolgreich durchlaufen (A0-7).
|
||||||
|
**And** die Architektur erfordert keine eigene Workflow Engine — die Trennung ist logisch, nicht zwingend als separate Prozesse umgesetzt (AD-6).
|
||||||
|
|
||||||
|
### Story 3.8: Determinismus-Vertrag (AD-17h) als Agent-Instruktions-Validator umsetzen
|
||||||
|
|
||||||
|
As a Compiler,
|
||||||
|
I want dass derselbe Git-State + dieselbe Eingabemenge bei zwei unabhängigen Runs denselben Bundle-State erzeugt,
|
||||||
|
So dass die AD-16-Klassifikation deterministisch genug ist (AD-17h, FT-10, A0-19).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** einen Fixed Git-State und eine feste Eingabemenge, **When** zwei unabhängige Runs ausgeführt werden, **Then** produzieren sie identische Bundle-Zustände (FT-10, AD-17h).
|
||||||
|
**Given** eine Abweichung bei zwei solchen Runs, **When** sie festgestellt wird, **Then** wird sie als Fehler im AD-16-Klassifikations-Mechanismus behandelt (nicht als akzeptables Rauschen) (AD-17h).
|
||||||
|
**Given** der MVP (D-3), **When** die Determinsmus-Enforcement fehlt, **Then** lebt sie als Agent-Instruktions-Validator und ist vor Last tragenden Anspruch als mechanisch bestätigt (Q-6, A0-19).
|
||||||
|
**And** der Validator hält keine Embedding-/Vector-Infrastruktur vor (AD-13; FT-3, FT-4).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Epic 4: Wissenstreue — Widersprüche & menschliche Kuratierung
|
||||||
|
|
||||||
|
Widersprüche werden nie stillschweigend zur scheinbar eindeutigen Aussage zusammengeführt; relevante Disagreements bleiben als explizite Einträge in `log.md` erhalten; menschlich kuratierte Inhalte werden als bestehendes Wissen respektiert und bleiben über OKF-Trust-Metadaten (`verified: human:...`) von ungeprüftem maschinellem Output unterscheidbar; unvollständiges/ungeprüftes Wissen wird ohne künstliche Gewissheit dargestellt.
|
||||||
|
**FRs covered:** FR-8, FR-13 · **NFRs:** NFR-7 · **AD/A0:** AD-16, AD-16a, AD-16b, AD-15, A0-11, A0-17, A0-20
|
||||||
|
|
||||||
|
### Story 4.1: Information vor jeder Änderung klassifizieren (NEW/CONFIRMING/CORRECTING/CONTRADICTING/REDUNDANT)
|
||||||
|
|
||||||
|
As a Compiler,
|
||||||
|
I want neue Informationen vor jeder Änderung gemäß AD-16 zu klassifizieren,
|
||||||
|
So dass Widersprüche nie stillschweigend aufgelöst werden und die Klassifikation deterministisch ist (FR-8, AD-16, AD-16a, A0-11).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** eine neue Information, **When** der Run sie verarbeitet, **Then** klassifiziert er sie als NEW / CONFIRMING / CORRECTING / CONTRADICTING / REDUNDANT (AD-16).
|
||||||
|
**Given** ein Widerspruch ohne explizite Ersetzungsevidenz, **When** er klassifiziert wird, **Then** ist der Default Erhaltung (CONTRADICTING), nicht stille Auflösung (AD-16a, A0-11).
|
||||||
|
**Given** eine Korrektur mit expliziter Ersetzungsevidenz, **When** sie klassifiziert wird, **Then** wird sie als CORRECTING mit dokumentierter Ersetzungslogik behandelt, nicht als CONTRADICTING (AD-16a).
|
||||||
|
**And** die Klassifikation ist deterministisch und über denselben Git-State reproduzierbar (AD-16a, AD-17h).
|
||||||
|
|
||||||
|
### Story 4.2: Disagreements in `log.md` explizit dokumentieren
|
||||||
|
|
||||||
|
As a Consumer/Compiler,
|
||||||
|
I want dass relevante Widersprüche als explizite Disagreements in `log.md` verbleiben — verknüpft mit dem mutierten Concept-Pfad,
|
||||||
|
So dass Konflikte sichtbar, nachvollziehbar und auditierbar bleiben (FR-8, AD-16b, A0-11).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** ein Konflikt, **When** der Run ihn feststellt, **Then** wird er als `log.md`-Eintrag dokumentiert, der mit dem betroffenen Concept-Pfad verknüpft ist (AD-16b, A0-11).
|
||||||
|
**Given** ein `log.md`-Eintrag, **When** er gespeichert wird, **Then** enthält er Klassifikation samt Begründung sowie die zugehörigen Sources (AD-16b, A0-11).
|
||||||
|
**Given** ein widersprüchliches Concept, **When** es gelesen wird, **Then** bleiben die betroffenen Aussagen und ihre Sources nachvollziehbar; Unsicherheit kann explizit Teil des Concepts sein (FR-8, AD-16).
|
||||||
|
**And** `log.md` ist selbst Bestandteil der Lease-Root-Scope (AD-17b, A0-13).
|
||||||
|
|
||||||
|
### Story 4.3: Menschliche Kuratierung respektieren (Human Curation)
|
||||||
|
|
||||||
|
As a Nutzer/Compiler,
|
||||||
|
I want manuell gepflegte Inhalte als bestehendes Wissen zu behandeln und nicht ohne Provenienz aus dem aktuellen Run zu entfernen,
|
||||||
|
So dass menschliche Kuratierung überlebt und nur bei echtem Widerspruch mit neuer Evidenz zurücktritt (FR-13, AD-15, A0-21, FT-9).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** ein manuell kuratiertes Concept ohne Provenienz aus dem aktuellen Run, **When** ein Run es trifft, **Then** wird es nicht entfernt — menschliche Inhalte sind persistentes Wissen (FR-13, AD-15).
|
||||||
|
**Given** ein Konflikt zwischen menschlicher Kuratierung und neuer Source, **When** er auftritt, **Then** wird er sichtbar (z.B. `log.md`-Eintrag gemäß AD-16), statt stillschweigend überschrieben zu werden (FR-13, AD-16).
|
||||||
|
**Given** eine menschliche Korrektur eines maschinell erzeugten Concepts, **When** sie erfolgt, **Then** überlebt sie als normale Kuratierung (Datei-Edit + Git), solange sie nicht durch neue Evidenz widerlegt wird (FT-9, A0-21).
|
||||||
|
**And** die Korrektur erfordert keine Re-Kompilation des ganzen Bundles (FT-9).
|
||||||
|
|
||||||
|
### Story 4.4: Trust-Metadaten: maschinell vs. human-reviewed unterscheiden
|
||||||
|
|
||||||
|
As a Consumer/Compiler,
|
||||||
|
I want maschinell erzeugtes (ungeprüftes) von human-reviewed Wissen über OKF-Trust-Metadaten zu unterscheiden,
|
||||||
|
So dass Leser die Vertrauenswürdigkeit einer Quelle erkennen können, ohne künstliche Gewissheit zu erzeugen (AD-15, A0-20, NFR-7, FR-13).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** ein maschinell erzeugtes Concept, **When** erzeugt wird, **Then** hat es `generated: { by, at }` und kein `verified` (AD-15, A0-20: v1-Default).
|
||||||
|
**Given** ein human-reviewed Concept, **When** es reviewt wird, **Then** setzt ein Mensch `verified` mit `human:`-Präfix-Actor (AD-15, A0-20).
|
||||||
|
**Given** ein Concept mit Lifecycle, **When** es gepflegt wird, **Then** nutzt es `status` (`draft` | `stable` | `deprecated`) und optional `stale_after` (AD-15).
|
||||||
|
**And** das Verhalten bleibt für alle Consumer agent-unabhängig und in Rein-Markdown lesbar (NFR-2, NFR-3, NFR-7).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Epic 5: Consumer-Zugriff & Nachvollziehbarkeit
|
||||||
|
|
||||||
|
Menschen und beliebige LLM-Agenten (BMAD, Claude Code, Codex, ...) lesen das Knowledge Bundle ohne Wiki-of-Wikis-spezifische Runtime; Änderungen sind über Git-Diffs nachvollziehbar; die kanonischen Compiler-Regeln sind agent-unabhängig mit dünnen Adaptern; es gibt keinen obligatorischen Server, keine Datenbank und keine proprietäre Abhängigkeit.
|
||||||
|
**FRs covered:** FR-14, FR-15, FR-16 · **NFRs:** NFR-1, NFR-3, NFR-5, NFR-6 · **AD/A0:** AD-10, AD-11, AD-13, AD-14, A0-21, A0-22
|
||||||
|
|
||||||
|
### Story 5.1: Git-nachvollziehbare Änderungen & Konsistenz (Commit-Boundary)
|
||||||
|
|
||||||
|
As a Consumer,
|
||||||
|
I want dass Concept-Änderungen über normale Versionskontrolle nachvollziehbar sind,
|
||||||
|
So dass Git-Diffs fachlich relevante Veränderungen sichtbar machen und kein proprietäres Change-Tracking nötig ist (FR-14, AD-14, A0-21).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** eine Mutation eines Concepts, **When** sie committet wird, **Then** ist sie über einen normalen Git-Diff textuell nachvollziehbar (FR-14, AD-14).
|
||||||
|
**Given** eine Änderung, **When** sie erstellt wird, **Then** verbleibt fachliche Provenienz im OKF Concept — nicht ausschließlich aus Git-Historie abgeleitet (AD-14).
|
||||||
|
**Given** eine übernommene Fremdänderung (aus Dirty-Tree-Schutz, AD-17e), **When** sie in einem Commit auftaucht, **Then** ist sie in `log.md` dokumentiert und keine uncommittete Fremdänderung wurde gelöscht (AD-17e/f).
|
||||||
|
**And** Änderungen erfolgen textuell und als normale Dateiänderungen (NFR-4).
|
||||||
|
|
||||||
|
### Story 5.2: Tool-unabhängigen Zugriff und Agent-Lesbarkeit gewährleisten
|
||||||
|
|
||||||
|
As a Nutzer/Agent,
|
||||||
|
I want das Knowledge Bundle ohne Wiki-of-Wikis-spezifische Runtime zu lesen,
|
||||||
|
So dass Menschen normale Markdown-Werkzeuge und LLM-Agenten Standard-Dateioperationen nutzen können (FR-15, NFR-2, NFR-3, NFR-5).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** ein Knowledge Bundle, **When** ein Mensch es liest, **Then** nutzt er gewöhnliche Markdown-Werkzeuge ohne spezielle Software (FR-15, NFR-2).
|
||||||
|
**Given** ein Knowledge Bundle, **When** ein LLM-Agent es erschließt, **Then** genügen Standard-Dateioperationen (Lesen/Grep/Traversal) — kein proprietäres SDK (FR-15, NFR-3).
|
||||||
|
**Given** ein Bundle ohne Server/Datenbank/Prozess, **When** es gelesen wird, **Then** bleibt es vollständig verständlich (NFR-5).
|
||||||
|
**And** das Bundle (inkl. `wiki/` nach Git-Clone auf andere Maschine) bleibt portabel lesbar (NFR-1, FT-7).
|
||||||
|
|
||||||
|
### Story 5.3: Agent-unabhängige Compiler-Regeln & dünne Adapter
|
||||||
|
|
||||||
|
As a Consumer/Operator,
|
||||||
|
I want dass die Compiler-Regeln agent-unabhängig bleiben und Provider-Instruktionen als dünne Adapter ausgeführt werden,
|
||||||
|
So dass BMAD, Claude Code, Codex und zukünftige Agenten ohne Knowledge-Modell-Migration wechseln können (FR-16, AD-10, A0-22).
|
||||||
|
|
||||||
|
**Acceptance Criteria:**
|
||||||
|
|
||||||
|
**Given** die kanonischen Compiler-Regeln, **When** ein Provider-Adapter erstellt wird, **Then** beschreibt er nur spezifische Instruktionen, definiert aber keine abweichende Knowledge-Semantik (AD-10, A0-22).
|
||||||
|
**Given** ein Adapter-Wechsel (z.B. Claude Code → Codex), **When** er erfolgt, **Then** ist keine Migration des Knowledge Bundle nötig (FR-16, A0-22, FT-2).
|
||||||
|
**Given** ein optionales Retrieval, **When** ein Consumer es einsetzt, **Then** ist es Consumer-Verhalten (grep/BM25/Vector etc.), das das kanonische Datenmodell nicht verändert (AD-13, FT-3).
|
||||||
|
**And** die Kompilierung produziert weiterhin ein rein markdown-basiertes Bundle, unabhängig vom Agenten (FR-16, NFR-6).
|
||||||
@@ -0,0 +1,14 @@
|
|||||||
|
# source.md — Epics
|
||||||
|
|
||||||
|
Materialisiert als Quelle unter `raw/` (Story 1.2, AD-12).
|
||||||
|
|
||||||
|
- **Datei (Evidenz):** `epics-2026-08-14.md`
|
||||||
|
- **Herkunft (kanonisch):** `_bmad-output/planning-artifacts/epics.md`
|
||||||
|
- **Kopie erstellt:** 2026-08-14
|
||||||
|
- **Kurzbeschreibung:** Feature-Breakdown in Epics/Stories inkl. Story 1.2 (lokale Sources unter `raw/`, URL-Rückweisung, AD-3).
|
||||||
|
|
||||||
|
## Provenienz-Hinweis
|
||||||
|
|
||||||
|
- Diese `source.md` ist ein Artefakt, **keine Evidenz** (vgl. `raw/README.md`).
|
||||||
|
- Herkunftspfade unter `_bmad-output/` sind generierte Planungs-Artefakte und im Repo nicht versioniert — Reproduktionshinweis, keine feste Referenz.
|
||||||
|
- Ändert sich die Herkunftsquelle, wird eine **neue, datierte Datei** angelegt (AD-3); diese Datei bleibt unverändert.
|
||||||
@@ -0,0 +1,665 @@
|
|||||||
|
---
|
||||||
|
title: Wiki of Wikis
|
||||||
|
status: final
|
||||||
|
created: 2026-08-14
|
||||||
|
updated: 2026-08-14
|
||||||
|
---
|
||||||
|
|
||||||
|
# PRD: Wiki of Wikis
|
||||||
|
|
||||||
|
## 0. Document Purpose
|
||||||
|
|
||||||
|
Dieses PRD definiert den Produktumfang von **Wiki of Wikis**.
|
||||||
|
|
||||||
|
Wiki of Wikis implementiert das von Andrej Karpathy beschriebene **LLM-Wiki-Prinzip**: Rohquellen werden nicht bei jeder Anfrage erneut durchsucht und interpretiert, sondern durch ein LLM schrittweise in ein persistentes, kuratiertes Wiki überführt. Dieses Wiki entwickelt sich mit neuen Quellen weiter und bildet das bereits erarbeitete Wissen dauerhaft ab.
|
||||||
|
|
||||||
|
Als strukturelles Format für dieses Wiki wird Googles **Open Knowledge Format (OKF) 0.2** verwendet. OKF definiert Knowledge Bundles aus Markdown-Dokumenten mit YAML-Frontmatter sowie Konventionen unter anderem für Provenienz, Lifecycle und Verlinkung. Beide konzeptionellen Anker sind in § 13 referenziert.
|
||||||
|
|
||||||
|
Das Produkt folgt bewusst dem Modell:
|
||||||
|
|
||||||
|
```text
|
||||||
|
Sources
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
LLM Wiki Compiler
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
Curated OKF Wiki
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
Humans / LLM Agents / BMAD / Coding Agents / other Consumers
|
||||||
|
```
|
||||||
|
|
||||||
|
Dieses PRD beschreibt **was** Wiki of Wikis leisten soll. Technische Mechanismen wie konkrete LLMs, Agent Frameworks, CLI-Technologien oder Retrieval-Implementierungen gehören in nachgelagerte Architekturentscheidungen.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 1. Vision
|
||||||
|
|
||||||
|
Wiki of Wikis verwandelt eine wachsende Menge heterogener Informationsquellen in eine **persistente, kuratierte und fortlaufend verbesserte Wissensbasis für Menschen und LLM-Agenten**.
|
||||||
|
|
||||||
|
Das System soll nicht lediglich Dokumente sammeln oder indizieren. Ein LLM soll Quellen lesen, verstehen, miteinander in Beziehung setzen und daraus eigenständige Wissensartikel erzeugen. Neue Quellen werden gegen das bereits vorhandene Wiki verarbeitet. Vorhandenes Wissen kann dadurch bestätigt, erweitert, präzisiert oder korrigiert werden.
|
||||||
|
|
||||||
|
Das zentrale Produktversprechen lautet:
|
||||||
|
|
||||||
|
> **Knowledge should compound.**
|
||||||
|
|
||||||
|
Eine einmal durch das LLM erarbeitete Synthese soll nicht bei jeder zukünftigen Anfrage erneut aus Rohdokumenten rekonstruiert werden müssen.
|
||||||
|
|
||||||
|
Das Ergebnis ist ein einfaches, portables Knowledge Bundle aus Markdown-Dateien, das weder eine spezielle Datenbank noch eine proprietäre Knowledge-Plattform benötigt.
|
||||||
|
|
||||||
|
Wiki of Wikis ist damit primär ein **Knowledge Compiler**, nicht ein Retrieval-System.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2. Target User
|
||||||
|
|
||||||
|
## 2.1 Primary User
|
||||||
|
|
||||||
|
Primärer Nutzer ist ein technisch versierter Wissensarbeiter oder Softwareentwickler, der eine größere Menge langlebiger technischer oder projektspezifischer Informationen für LLM-Agenten verfügbar machen möchte.
|
||||||
|
|
||||||
|
[ASSUMPTION: In v1 handelt es sich primär um ein persönliches bzw. teaminternes Developer Tool und nicht um ein öffentliches Endanwenderprodukt.]
|
||||||
|
|
||||||
|
## 2.2 Jobs To Be Done
|
||||||
|
|
||||||
|
Der Nutzer möchte:
|
||||||
|
|
||||||
|
- neue Informationsquellen bereitstellen können, ohne selbst entscheiden zu müssen, in welche Wiki-Seite jede einzelne Information gehört;
|
||||||
|
- Wissen aus mehreren Quellen durch ein LLM synthetisieren lassen;
|
||||||
|
- Erkenntnisse aus früheren Verarbeitungsläufen dauerhaft bewahren;
|
||||||
|
- bestehendes Wissen automatisch erweitern oder korrigieren lassen, wenn neue Informationen hinzukommen;
|
||||||
|
- jederzeit nachvollziehen können, auf welchen Quellen eine Erkenntnis basiert;
|
||||||
|
- das Wiki direkt mit Git versionieren können;
|
||||||
|
- das Wiki mit unterschiedlichen LLM-Agenten verwenden können;
|
||||||
|
- Wissen lesen und bearbeiten können, ohne eine spezielle Anwendung zu benötigen;
|
||||||
|
- BMAD, Claude Code, Codex oder andere Agenten als Consumer anschließen können, ohne das Wiki auf einen dieser Consumer auszurichten.
|
||||||
|
|
||||||
|
## 2.3 Non-Users v1
|
||||||
|
|
||||||
|
Wiki of Wikis richtet sich in v1 ausdrücklich **nicht** an:
|
||||||
|
|
||||||
|
- Nutzer, die ein klassisches Wiki-CMS mit Weboberfläche suchen;
|
||||||
|
- Unternehmen, die eine vollständige Enterprise-Knowledge-Management-Plattform benötigen;
|
||||||
|
- Nutzer, die lediglich eine semantische Suchmaschine über Dokumente benötigen;
|
||||||
|
- Nutzer, die einen allgemeinen Webcrawler oder Dokumenten-Downloader benötigen;
|
||||||
|
- Nutzer, die ein Vector-RAG-System erwarten.
|
||||||
|
|
||||||
|
## 2.4 Key User Journeys
|
||||||
|
|
||||||
|
### UJ-1 — Neue Quelle in das Wissen integrieren
|
||||||
|
|
||||||
|
Michael besitzt bereits ein Wiki über ein Softwareprojekt. Eine neue technische Dokumentation oder Projektspezifikation wird verfügbar.
|
||||||
|
|
||||||
|
Er stellt diese Quelle dem Wiki Compiler zur Verfügung.
|
||||||
|
|
||||||
|
Der Compiler liest:
|
||||||
|
|
||||||
|
1. die neue Quelle,
|
||||||
|
2. relevante vorhandene Wiki-Inhalte,
|
||||||
|
3. vorhandene Provenienz-Informationen.
|
||||||
|
|
||||||
|
Anschließend entscheidet er, welche vorhandenen Concepts aktualisiert und welche neuen Concepts angelegt werden müssen.
|
||||||
|
|
||||||
|
Nach dem Lauf enthält das Wiki die neuen Erkenntnisse, ohne dass Michael die Wissensstruktur manuell pflegen musste.
|
||||||
|
|
||||||
|
### UJ-2 — Wissen über mehrere Quellen synthetisieren
|
||||||
|
|
||||||
|
Mehrere Quellen behandeln dasselbe Thema aus unterschiedlichen Perspektiven.
|
||||||
|
|
||||||
|
Der Compiler erkennt diese Zusammenhänge und aktualisiert eine gemeinsame Wissensrepräsentation, anstatt für jede Quelle eine isolierte Zusammenfassung anzulegen.
|
||||||
|
|
||||||
|
Das resultierende Concept beschreibt den aktuellen Wissensstand und verweist auf die zugrunde liegenden Quellen.
|
||||||
|
|
||||||
|
### UJ-3 — Ein anderer Agent verwendet das Wiki
|
||||||
|
|
||||||
|
Ein LLM-Agent benötigt Hintergrundwissen über ein bereits verarbeitetes Thema.
|
||||||
|
|
||||||
|
Der Agent liest relevante Wiki Concepts und deren Verlinkungen.
|
||||||
|
|
||||||
|
Die ursprünglichen Rohquellen müssen für diese Fragestellung nicht erneut vollständig analysiert werden.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 3. Glossary
|
||||||
|
|
||||||
|
**Source**
|
||||||
|
Ein Informationsartefakt, aus dem Wissen gewonnen werden kann. Beispiele sind technische Dokumentationen, Spezifikationen, Projektartefakte, Webseiten, Forschungsunterlagen oder bestehende interne Dokumente.
|
||||||
|
|
||||||
|
**Source Material**
|
||||||
|
Der tatsächlich für einen Compilation Run verfügbare Inhalt einer Source.
|
||||||
|
|
||||||
|
**Knowledge Bundle**
|
||||||
|
Die Gesamtheit des durch Wiki of Wikis verwalteten OKF-Wikis.
|
||||||
|
|
||||||
|
**Concept**
|
||||||
|
Eine einzelne Wissenseinheit innerhalb des Knowledge Bundle. Ein Concept wird gemäß OKF als Markdown-Dokument repräsentiert.
|
||||||
|
|
||||||
|
**Wiki Page**
|
||||||
|
Informelle Bezeichnung für ein Concept. In Anforderungen wird bevorzugt der OKF-Begriff **Concept** verwendet.
|
||||||
|
|
||||||
|
**Compiler**
|
||||||
|
Die Produktfunktion, die Source Material und das bestehende Knowledge Bundle analysiert und daraus ein aktualisiertes Knowledge Bundle erzeugt.
|
||||||
|
|
||||||
|
**Compilation Run**
|
||||||
|
Ein einzelner Verarbeitungsvorgang des Compilers.
|
||||||
|
|
||||||
|
**Curated Knowledge**
|
||||||
|
Vom Compiler oder einem Menschen bewusst strukturierte, zusammengeführte und interpretierte Wissensinhalte. Curated Knowledge ist keine bloße Kopie oder Sammlung von Source Material.
|
||||||
|
|
||||||
|
**Provenance**
|
||||||
|
Nachvollziehbare Beziehung zwischen einem Concept beziehungsweise darin enthaltenen Aussagen und den zugrunde liegenden Sources.
|
||||||
|
|
||||||
|
**Consumer**
|
||||||
|
Ein Mensch oder Software-Agent, der das Knowledge Bundle liest oder für weitere Aufgaben verwendet.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 4. Features
|
||||||
|
|
||||||
|
## 4.1 Source Intake
|
||||||
|
|
||||||
|
Wiki of Wikis muss Source Material als Eingang für einen Compilation Run akzeptieren können.
|
||||||
|
|
||||||
|
### FR-1: Sources bereitstellen
|
||||||
|
|
||||||
|
Der Nutzer kann dem Compiler eine oder mehrere Sources zur Verarbeitung bereitstellen. In v1 akzeptiert der Compiler bereitgestelltes Source Material (assumption A-4); das eigenständige Abrufen von URLs ist nicht Bestandteil von v1 (siehe Out of Scope für den MVP).
|
||||||
|
|
||||||
|
**Consequences:**
|
||||||
|
|
||||||
|
- Ein Compilation Run kann eine einzelne oder mehrere Sources verarbeiten.
|
||||||
|
- Sources können unabhängig von der bestehenden Wiki-Struktur bereitgestellt werden.
|
||||||
|
- Der Nutzer muss vor der Verarbeitung nicht bestimmen, welchem Concept eine Source zugeordnet wird.
|
||||||
|
- Source Material wird lokal bereitgestellt; die automatische Internetrecherche und das Abrufen von URLs gehören nicht zu v1.
|
||||||
|
|
||||||
|
### FR-2: Sources und Curated Knowledge unterscheiden
|
||||||
|
|
||||||
|
Das System muss Source Material eindeutig vom erzeugten Knowledge Bundle unterscheiden.
|
||||||
|
|
||||||
|
**Consequences:**
|
||||||
|
|
||||||
|
- Rohquellen werden nicht automatisch zu Wiki Concepts.
|
||||||
|
- Eine Kopie eines Quelldokuments gilt nicht als erfolgreiche Wissensintegration.
|
||||||
|
- Consumers können zwischen Source Material und Curated Knowledge unterscheiden.
|
||||||
|
|
||||||
|
### FR-3: Provenienz bewahren
|
||||||
|
|
||||||
|
Wissen, das aus Sources abgeleitet wird, muss seine Provenienz bewahren.
|
||||||
|
|
||||||
|
**Consequences:**
|
||||||
|
|
||||||
|
- Ein erzeugtes oder aktualisiertes Concept kann auf seine zugrunde liegenden Sources zurückgeführt werden.
|
||||||
|
- Neue Quellen dürfen bestehende Provenienz nicht unbeabsichtigt entfernen.
|
||||||
|
- Wenn mehrere Sources zu einem Concept beitragen, können diese gemeinsam dokumentiert werden.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4.2 LLM Knowledge Compilation
|
||||||
|
|
||||||
|
Der Compiler ist die zentrale Produktfunktion von Wiki of Wikis.
|
||||||
|
|
||||||
|
### FR-4: Sources gegen bestehendes Wissen verarbeiten
|
||||||
|
|
||||||
|
Bei einem Compilation Run muss der Compiler sowohl das neue Source Material als auch relevantes bereits vorhandenes Curated Knowledge berücksichtigen.
|
||||||
|
|
||||||
|
**Consequences:**
|
||||||
|
|
||||||
|
- Das bestehende Wiki ist Input für zukünftige Compilation Runs.
|
||||||
|
- Bereits erarbeitete Erkenntnisse müssen nicht aus Rohquellen neu aufgebaut werden.
|
||||||
|
- Neue Informationen können vorhandenes Wissen ergänzen oder verändern.
|
||||||
|
|
||||||
|
### FR-5: Concepts erzeugen
|
||||||
|
|
||||||
|
Der Compiler kann aus Source Material neue Concepts erzeugen.
|
||||||
|
|
||||||
|
**Consequences:**
|
||||||
|
|
||||||
|
- Ein neues Concept beschreibt eine eigenständige Wissenseinheit.
|
||||||
|
- Concepts sind nicht zwangsläufig an die Struktur der Source gebunden.
|
||||||
|
- Mehrere Abschnitte einer Source können in unterschiedliche Concepts einfließen.
|
||||||
|
|
||||||
|
### FR-6: Bestehende Concepts aktualisieren
|
||||||
|
|
||||||
|
Der Compiler kann vorhandene Concepts aktualisieren, wenn neue Erkenntnisse dazu vorliegen.
|
||||||
|
|
||||||
|
**Consequences:**
|
||||||
|
|
||||||
|
- Neue Informationen führen nicht automatisch zu neuen Dateien.
|
||||||
|
- Bestehendes Wissen kann erweitert, präzisiert oder korrigiert werden.
|
||||||
|
- Beziehungen und Provenienz bestehender Concepts bleiben soweit weiterhin gültig erhalten.
|
||||||
|
|
||||||
|
### FR-7: Wissen synthetisieren
|
||||||
|
|
||||||
|
Der Compiler muss Informationen aus mehreren Sources zu einer gemeinsamen Wissensrepräsentation zusammenführen können.
|
||||||
|
|
||||||
|
**Consequences:**
|
||||||
|
|
||||||
|
- Mehrere Sources zum selben Thema müssen nicht in getrennten Zusammenfassungen enden.
|
||||||
|
- Das Ergebnis soll den erkannten Wissensstand darstellen und nicht lediglich eine Aneinanderreihung von Source-Zusammenfassungen sein.
|
||||||
|
- Redundante Informationen können konsolidiert werden.
|
||||||
|
|
||||||
|
### FR-8: Widersprüche sichtbar behandeln
|
||||||
|
|
||||||
|
Widersprüchliche Informationen dürfen nicht stillschweigend zu einer scheinbar eindeutigen Aussage zusammengeführt werden.
|
||||||
|
|
||||||
|
**Consequences:**
|
||||||
|
|
||||||
|
- Relevante Widersprüche bleiben im Curated Knowledge erkennbar.
|
||||||
|
- Die jeweiligen Sources bleiben nachvollziehbar.
|
||||||
|
- Unsicherheit darf explizit Teil eines Concepts sein.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4.3 OKF Knowledge Bundle
|
||||||
|
|
||||||
|
Das erzeugte Wiki muss ein gültiges Open Knowledge Format Knowledge Bundle bilden.
|
||||||
|
|
||||||
|
### FR-9: OKF-konforme Concepts erzeugen
|
||||||
|
|
||||||
|
Alle vom Compiler erzeugten Concepts müssen dem für das Projekt festgelegten OKF-Standard entsprechen.
|
||||||
|
|
||||||
|
Für v1 ist dies **OKF 0.2** (referenziert in § 13). Aus OKF 0.2 folgen unter anderem: `type` ist das einzige verpflichtende Frontmatter-Feld; optional unterstützt werden Provenienz (`sources`), Autorenschaft/Trust (`generated`, `verified`), Lifecycle (`status`, `stale_after`) sowie die Bundledeklaration `okf_version: "0.2"` in einer Bundleroot-`index.md`. Konkrete Feldauswahlen legt die Architekturentscheidung im Rahmen einer OKF-0.2-Validierung fest.
|
||||||
|
|
||||||
|
**Consequences:**
|
||||||
|
|
||||||
|
- Concepts bestehen aus Markdown mit YAML-Frontmatter.
|
||||||
|
- Das von OKF verpflichtend geforderte `type`-Attribut wird gesetzt.
|
||||||
|
- Unterstützte Provenienz-, Trust- und Lifecycle-Metadaten können verwendet werden.
|
||||||
|
- Producer-spezifische Erweiterungen dürfen die Portabilität des Knowledge Bundle nicht verhindern.
|
||||||
|
|
||||||
|
### FR-10: Concepts miteinander verlinken
|
||||||
|
|
||||||
|
Der Compiler kann Beziehungen zwischen Concepts durch normale Markdown-Links ausdrücken.
|
||||||
|
|
||||||
|
**Consequences:**
|
||||||
|
|
||||||
|
- Zusammengehörige Concepts können navigiert werden.
|
||||||
|
- Links bleiben auch für Consumer verständlich, die keine Wiki-of-Wikis-spezifische Software verwenden.
|
||||||
|
- Die Wissensstruktur kann durch Agenten traversiert werden.
|
||||||
|
|
||||||
|
### FR-11: Progressive Discovery ermöglichen
|
||||||
|
|
||||||
|
Das Knowledge Bundle muss einem Consumer ermöglichen, vorhandenes Wissen schrittweise zu entdecken, ohne zunächst sämtliche Concepts lesen zu müssen.
|
||||||
|
|
||||||
|
**Consequences:**
|
||||||
|
|
||||||
|
- Bereiche des Knowledge Bundle können über geeignete Index-Strukturen erschlossen werden.
|
||||||
|
- Ein Consumer kann zunächst Übersichten lesen und anschließend relevante Concepts öffnen.
|
||||||
|
- Wiki-Navigation darf keine proprietäre Datenbank voraussetzen.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4.4 Incremental Knowledge Evolution
|
||||||
|
|
||||||
|
Das Knowledge Bundle ist kein einmalig generiertes Ergebnis, sondern ein langlebiges Artefakt.
|
||||||
|
|
||||||
|
### FR-12: Knowledge Bundle inkrementell weiterentwickeln
|
||||||
|
|
||||||
|
Ein Compilation Run muss ein bestehendes Knowledge Bundle weiterentwickeln können.
|
||||||
|
|
||||||
|
**Consequences:**
|
||||||
|
|
||||||
|
- Der Compiler erzeugt nicht bei jedem Lauf ein vollständig unabhängiges Wiki.
|
||||||
|
- Unverändertes Wissen bleibt erhalten.
|
||||||
|
- Änderungen konzentrieren sich auf Concepts, die durch neue Erkenntnisse betroffen sind.
|
||||||
|
|
||||||
|
### FR-13: Vorhandene menschliche Kuratierung berücksichtigen
|
||||||
|
|
||||||
|
Manuell gepflegte Inhalte im Knowledge Bundle müssen als bestehendes Wissen behandelt werden.
|
||||||
|
|
||||||
|
**Consequences:**
|
||||||
|
|
||||||
|
- Ein Compilation Run darf menschliche Ergänzungen nicht allein deshalb entfernen, weil sie nicht aus der aktuellen Source stammen.
|
||||||
|
- Bei Konflikten zwischen menschlich kuratiertem Wissen und neuer Source muss der Konflikt erkennbar werden.
|
||||||
|
- Human-reviewed Knowledge kann gegenüber ungeprüftem maschinell erzeugtem Wissen unterscheidbar bleiben.
|
||||||
|
|
||||||
|
### FR-14: Änderungen nachvollziehbar machen
|
||||||
|
|
||||||
|
Änderungen an Concepts müssen über normale Versionskontrollmechanismen nachvollziehbar bleiben.
|
||||||
|
|
||||||
|
**Consequences:**
|
||||||
|
|
||||||
|
- Änderungen erfolgen an textuellen Artefakten.
|
||||||
|
- Ein Git-Diff kann fachlich relevante Veränderungen sichtbar machen.
|
||||||
|
- Es ist keine proprietäre Änderungsverfolgung notwendig.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4.5 Knowledge Consumption
|
||||||
|
|
||||||
|
### FR-15: Tool-unabhängigen Zugriff ermöglichen
|
||||||
|
|
||||||
|
Ein Consumer muss das Knowledge Bundle ohne Wiki-of-Wikis-spezifische Runtime lesen können.
|
||||||
|
|
||||||
|
**Consequences:**
|
||||||
|
|
||||||
|
- Menschen können Concepts mit normalen Markdown-Werkzeugen lesen.
|
||||||
|
- LLM-Agenten können Concepts über normale Dateioperationen lesen.
|
||||||
|
- Consumer benötigen kein proprietäres SDK.
|
||||||
|
|
||||||
|
### FR-16: Consumer vom Compiler entkoppeln
|
||||||
|
|
||||||
|
Das Knowledge Bundle darf nicht auf einen bestimmten LLM-Agenten oder Workflow zugeschnitten sein.
|
||||||
|
|
||||||
|
**Consequences:**
|
||||||
|
|
||||||
|
- BMAD kann Consumer sein.
|
||||||
|
- Claude Code kann Consumer sein.
|
||||||
|
- Codex kann Consumer sein.
|
||||||
|
- Zukünftige Agenten können Consumer werden.
|
||||||
|
- Ein Wechsel des Consumers erfordert keine Migration des Wissensformats.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 5. Non-Goals
|
||||||
|
|
||||||
|
Die folgenden Punkte gehören ausdrücklich **nicht** zum Produktkern von Wiki of Wikis v1.
|
||||||
|
|
||||||
|
Wiki of Wikis ist **keine**:
|
||||||
|
|
||||||
|
- Vector-Datenbank;
|
||||||
|
- Graphdatenbank;
|
||||||
|
- allgemeine RAG-Plattform;
|
||||||
|
- Enterprise-Suchmaschine;
|
||||||
|
- Knowledge-Management-Suite;
|
||||||
|
- Dokumentenmanagement-Plattform;
|
||||||
|
- Dokumentenarchivierungslösung;
|
||||||
|
- Web-Crawling-Plattform;
|
||||||
|
- Content-Management-System;
|
||||||
|
- Confluence- oder Obsidian-Alternative;
|
||||||
|
- Code-Analyseplattform;
|
||||||
|
- Projektmanagement-Plattform;
|
||||||
|
- BMAD-Erweiterung;
|
||||||
|
- CodeGraph-Erweiterung.
|
||||||
|
|
||||||
|
Insbesondere gilt:
|
||||||
|
|
||||||
|
> **Retrieval ist Consumer-Verhalten, nicht Kern des Wiki Compilers.**
|
||||||
|
|
||||||
|
Ein Consumer darf selbstverständlich später Search, RAG, Graph Traversal oder andere Retrieval-Verfahren über dem Knowledge Bundle einsetzen. Diese Mechanismen gehören jedoch nicht zum Kernprodukt.
|
||||||
|
|
||||||
|
Ebenso sind folgende Quellen **nicht selbst Bestandteil der Produktarchitektur**:
|
||||||
|
|
||||||
|
- Context7;
|
||||||
|
- Arc42-Dokumentation;
|
||||||
|
- BMAD-Artefakte;
|
||||||
|
- `_bmad-archive`;
|
||||||
|
- Projektdokumentationen;
|
||||||
|
- Herstellerdokumentationen;
|
||||||
|
- CodeGraph.
|
||||||
|
|
||||||
|
Sie können Sources oder Consumers sein.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 6. MVP Scope
|
||||||
|
|
||||||
|
## 6.1 In Scope
|
||||||
|
|
||||||
|
Der MVP muss:
|
||||||
|
|
||||||
|
- Sources entgegennehmen;
|
||||||
|
- vorhandenes Wiki lesen;
|
||||||
|
- neue Informationen analysieren;
|
||||||
|
- neue Concepts erzeugen;
|
||||||
|
- bestehende Concepts aktualisieren;
|
||||||
|
- Informationen aus mehreren Sources synthetisieren;
|
||||||
|
- Provenienz dokumentieren;
|
||||||
|
- widersprüchliche Erkenntnisse sichtbar behandeln;
|
||||||
|
- OKF-0.2-konforme Markdown-Concepts erzeugen;
|
||||||
|
- Concepts miteinander verlinken;
|
||||||
|
- ein bestehendes Knowledge Bundle inkrementell weiterentwickeln;
|
||||||
|
- Änderungen Git-freundlich erzeugen;
|
||||||
|
- ohne spezielle Datenbank oder Knowledge Runtime nutzbar bleiben.
|
||||||
|
|
||||||
|
## 6.2 Out of Scope for MVP
|
||||||
|
|
||||||
|
Nicht Bestandteil des MVP sind:
|
||||||
|
|
||||||
|
- Vector Embeddings;
|
||||||
|
- Vector Search;
|
||||||
|
- Knowledge Graph Database;
|
||||||
|
- MCP Server;
|
||||||
|
- Web UI;
|
||||||
|
- Wiki Rendering Server;
|
||||||
|
- automatische Internetrecherche;
|
||||||
|
- allgemeiner Webcrawler;
|
||||||
|
- automatisches Scheduling;
|
||||||
|
- automatische Source-Beobachtung;
|
||||||
|
- BMAD-spezifische Integration;
|
||||||
|
- Claude-Code-spezifische Integration;
|
||||||
|
- CodeGraph-Integration;
|
||||||
|
- Multi-User-Rechtesystem;
|
||||||
|
- Enterprise Governance;
|
||||||
|
- eigener OKF-Dialekt;
|
||||||
|
- eigenes Knowledge Schema zusätzlich zu OKF.
|
||||||
|
|
||||||
|
Diese Funktionen können später als **Integrationen um den Compiler herum** entstehen, sofern dafür ein tatsächlicher Bedarf nachgewiesen wird.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 7. Cross-Cutting Non-Functional Requirements
|
||||||
|
|
||||||
|
### NFR-1: Portability
|
||||||
|
|
||||||
|
Das Knowledge Bundle muss ohne Wiki-of-Wikis-spezifische Software kopiert, archiviert und gelesen werden können.
|
||||||
|
|
||||||
|
### NFR-2: Human Readability
|
||||||
|
|
||||||
|
Alle kanonischen Wissensinhalte müssen für Menschen unmittelbar als Markdown lesbar sein.
|
||||||
|
|
||||||
|
### NFR-3: Agent Readability
|
||||||
|
|
||||||
|
Das Knowledge Bundle muss mit Standard-Dateioperationen durch LLM-Agenten erschließbar sein.
|
||||||
|
|
||||||
|
### NFR-4: Version-Control Friendliness
|
||||||
|
|
||||||
|
Änderungen müssen in einer Form erfolgen, die sinnvolle textuelle Diffs ermöglicht.
|
||||||
|
|
||||||
|
### NFR-5: No Mandatory Runtime
|
||||||
|
|
||||||
|
Das Lesen eines erzeugten Knowledge Bundle darf weder einen Server noch eine Datenbank noch einen laufenden Wiki-of-Wikis-Prozess voraussetzen.
|
||||||
|
|
||||||
|
### NFR-6: Vendor Independence
|
||||||
|
|
||||||
|
Das kanonische Knowledge Bundle darf nicht von einem bestimmten LLM-Hersteller oder Agent Framework abhängen.
|
||||||
|
|
||||||
|
### NFR-7: Graceful Partial Knowledge
|
||||||
|
|
||||||
|
Das System muss unvollständiges, ungeprüftes oder teilweise widersprüchliches Wissen darstellen können, ohne daraus künstlich Gewissheit zu erzeugen.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 8. Constraints and Guardrails
|
||||||
|
|
||||||
|
## 8.1 OKF as the Canonical Format
|
||||||
|
|
||||||
|
OKF ist der normative Standard für die Wissensrepräsentation.
|
||||||
|
|
||||||
|
Wiki of Wikis soll OKF **verwenden**, nicht ersetzen oder eine konkurrierende Ontologie darüberlegen.
|
||||||
|
|
||||||
|
## 8.2 Plain Files as Canonical State
|
||||||
|
|
||||||
|
[ASSUMPTION: Das Knowledge Bundle in Git ist der kanonische persistente Zustand des Systems.]
|
||||||
|
|
||||||
|
Abgeleitete Indizes, Caches oder Retrieval-Strukturen dürfen zukünftig existieren, sind jedoch nicht Source of Truth.
|
||||||
|
|
||||||
|
## 8.3 Separation of Concerns
|
||||||
|
|
||||||
|
Die Produktarchitektur muss konzeptionell drei Verantwortungsbereiche getrennt halten:
|
||||||
|
|
||||||
|
```text
|
||||||
|
Sources → Compilation → Knowledge Bundle → Consumers
|
||||||
|
```
|
||||||
|
|
||||||
|
Ein Consumer darf nicht zur Voraussetzung für Compilation oder Speicherung werden.
|
||||||
|
|
||||||
|
Eine Source darf nicht automatisch Teil des Curated Knowledge werden.
|
||||||
|
|
||||||
|
## 8.4 Complexity Guardrail
|
||||||
|
|
||||||
|
Neue Infrastruktur gehört nur dann in den Produktkern, wenn sie für die zentrale Funktion
|
||||||
|
|
||||||
|
> **Sources + existing knowledge → improved curated knowledge**
|
||||||
|
|
||||||
|
erforderlich ist.
|
||||||
|
|
||||||
|
Andernfalls ist sie als Source Adapter, Consumer Adapter oder optionale Integration zu behandeln.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 9. Success Metrics
|
||||||
|
|
||||||
|
## Primary
|
||||||
|
|
||||||
|
### SM-1: Compounding Knowledge
|
||||||
|
|
||||||
|
Nach einem zweiten Compilation Run kann das System vorhandenes Wissen weiterentwickeln, ohne das Knowledge Bundle vollständig aus den ursprünglichen Sources neu erzeugen zu müssen.
|
||||||
|
|
||||||
|
Validiert FR-4, FR-6 und FR-12.
|
||||||
|
|
||||||
|
### SM-2: Source-to-Knowledge Transformation
|
||||||
|
|
||||||
|
Eine neue Source führt zu kuratierten Concepts beziehungsweise Änderungen bestehender Concepts und nicht lediglich zu einer Kopie oder Zusammenfassung des Quelldokuments.
|
||||||
|
|
||||||
|
Validiert FR-5 und FR-7.
|
||||||
|
|
||||||
|
### SM-3: Provenance
|
||||||
|
|
||||||
|
Für aus Sources abgeleitetes Wissen ist nachvollziehbar, aus welchen Sources es entstanden ist.
|
||||||
|
|
||||||
|
Validiert FR-3 und FR-9.
|
||||||
|
|
||||||
|
### SM-4: Consumer Independence
|
||||||
|
|
||||||
|
Ein bisher nicht integrierter LLM-Agent kann ein Knowledge Bundle über gewöhnliche Markdown-Dateien lesen und für seine Aufgaben verwenden, ohne Wiki-of-Wikis-spezifische APIs zu benötigen.
|
||||||
|
|
||||||
|
Validiert FR-15 und FR-16.
|
||||||
|
|
||||||
|
### SM-5: Zero Mandatory Infrastructure
|
||||||
|
|
||||||
|
Ein erzeugtes Knowledge Bundle bleibt vollständig lesbar, wenn Compiler, LLM, Indizes und sonstige Hilfsdienste nicht verfügbar sind.
|
||||||
|
|
||||||
|
Validiert NFR-1, NFR-2 und NFR-5.
|
||||||
|
|
||||||
|
## Counter-Metrics
|
||||||
|
|
||||||
|
### SM-C1: File Count
|
||||||
|
|
||||||
|
Eine möglichst geringe Anzahl Concepts ist **kein** Optimierungsziel.
|
||||||
|
|
||||||
|
Zu große Concepts dürfen nicht allein zur Reduzierung der Dateianzahl entstehen.
|
||||||
|
|
||||||
|
### SM-C2: Compilation Speed
|
||||||
|
|
||||||
|
Maximale Compilation-Geschwindigkeit ist kein Primärziel, wenn dadurch Synthesequalität oder Provenienz leiden.
|
||||||
|
|
||||||
|
### SM-C3: Maximum Automation
|
||||||
|
|
||||||
|
Vollständige Automatisierung ist kein Selbstzweck.
|
||||||
|
|
||||||
|
Eine nachvollziehbare und korrigierbare Wissensbasis ist wichtiger als ein autonomes System ohne menschliche Eingriffsmöglichkeit.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 10. Open Questions
|
||||||
|
|
||||||
|
1. **Human-authored Concepts:**
|
||||||
|
Sollen vollständig manuell erstellte Concepts explizit als First-Class-Knowledge behandelt werden oder lediglich vom Compiler toleriert werden?
|
||||||
|
|
||||||
|
2. **Verification Workflow:**
|
||||||
|
Wie soll ein Nutzer ein maschinell erzeugtes Concept als human-reviewed kennzeichnen?
|
||||||
|
[NOTE FOR PM: Die Antwort legt nicht nur den Human-Workflow fest, sondern auch, welche OKF-Trust-Metadaten (`verified`, `human:`-Präfix) der Compiler erzeugen soll — v1-Default ist maschinell erzeugt und ungeprüft.]
|
||||||
|
|
||||||
|
3. **Compilation Scope:**
|
||||||
|
Wie bestimmt der Compiler, welche vorhandenen Concepts für eine neue Source relevant sind?
|
||||||
|
|
||||||
|
Dies ist primär eine Architekturfrage und muss nicht im PRD entschieden werden.
|
||||||
|
|
||||||
|
4. **Conflict Resolution:**
|
||||||
|
Welche Konflikte darf der Compiler selbst auflösen und bei welchen muss er den Nutzer einbeziehen?
|
||||||
|
[NOTE FOR PM: Diese Entscheidung muss sich gemäß A-3 (keine GUI in v1) innerhalb eines rein CLI-/dateibasierten Workflows umsetzen lassen.]
|
||||||
|
|
||||||
|
5. **Source Lifecycle:**
|
||||||
|
Was geschieht mit Wissen, wenn eine Source entfernt, ersetzt oder als falsch erkannt wird?
|
||||||
|
|
||||||
|
6. **Product Name:**
|
||||||
|
Ist **Wiki of Wikis** der endgültige Produktname oder lediglich der Projektname?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 11. Assumptions Index
|
||||||
|
|
||||||
|
|
||||||
|
- **A-1 — Target User:** v1 ist primär ein persönliches bzw. teaminternes Developer Tool. Dieser Fokus darf nicht zu einem vollständig autonomen, unbeaufsichtigten Prozess führen (siehe SM-C3).
|
||||||
|
- **A-2 — Canonical State:** Das Git-versionierte OKF Knowledge Bundle ist der kanonische persistente Zustand.
|
||||||
|
- **A-3 — UI:** Für v1 ist keine dedizierte grafische Benutzeroberfläche erforderlich.
|
||||||
|
- **A-4 — Source Acquisition:** Source-Beschaffung ist nicht Kern des Produkts; der Compiler verarbeitet grundsätzlich bereitgestelltes Source Material. Für v1 gilt: lokal bereitgestelltes Source Material, keine URL-Beschaffung (siehe FR-1 und § 6.2).
|
||||||
|
- **A-5 — Integrations:** BMAD, Claude Code, Codex, CodeGraph und vergleichbare Werkzeuge sind Sources oder Consumers, aber keine Bestandteile des Kernprodukts.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 12. Product Boundary
|
||||||
|
|
||||||
|
|
||||||
|
Die wichtigste Architektur- und Produktregel dieses PRDs lautet:
|
||||||
|
|
||||||
|
```text
|
||||||
|
┌────────────────────┐
|
||||||
|
│ Sources │
|
||||||
|
│ │
|
||||||
|
│ Docs │
|
||||||
|
│ Arc42 │
|
||||||
|
│ Context7 │
|
||||||
|
│ BMAD artifacts │
|
||||||
|
│ Project archive │
|
||||||
|
│ Web documentation │
|
||||||
|
└─────────┬──────────┘
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
┌────────────────────┐
|
||||||
|
│ Wiki of Wikis │
|
||||||
|
│ │
|
||||||
|
│ LLM Compilation │
|
||||||
|
└─────────┬──────────┘
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
┌────────────────────┐
|
||||||
|
│ OKF Knowledge │
|
||||||
|
│ Bundle │
|
||||||
|
│ │
|
||||||
|
│ Markdown │
|
||||||
|
│ Provenance │
|
||||||
|
│ Links │
|
||||||
|
│ Git History │
|
||||||
|
└─────────┬──────────┘
|
||||||
|
│
|
||||||
|
┌────────────────┼────────────────┐
|
||||||
|
▼ ▼ ▼
|
||||||
|
Humans BMAD Coding Agents
|
||||||
|
/ Other LLMs
|
||||||
|
```
|
||||||
|
|
||||||
|
Alles, was nicht zwingend zwischen **Sources** und **Knowledge Bundle** benötigt wird, ist zunächst **kein Bestandteil des Kernprodukts**.
|
||||||
|
|
||||||
|
Das ist der zentrale Scope Guardrail von Wiki of Wikis.
|
||||||
|
|
||||||
|
An die Architektur weitergereichte Umsetzungsfragen (bewusst nicht im PRD entschieden):
|
||||||
|
|
||||||
|
- **Relevanzbestimmung (Open Question 3 — Compilation Scope):** Wie der Compiler relevante bestehende Concepts zu einer neuen Source findet, ist eine Architekturfrage. Die Umsetzung darf die Scope-No-Goals (§ 5, § 6.2) nicht unterlaufen: Für v1 ist keine Embedding- oder Vector-Infrastruktur vorgesehen; die Relevanzbestimmung muss mit textuellen, deterministischen Mitteln umgesetzt werden.
|
||||||
|
- **Bundle-Layout (Source vs. Curated Knowledge):** Wie Source Material und Curated Knowledge konkret im Dateisystem getrennt platziert werden, bleibt der Architektur überlassen. Die Separation-of-Concerns-Pflicht aus FR-2/§ 8.3 bleibt unverändert bestehen.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 13. Anker-Referenzen
|
||||||
|
|
||||||
|
Die konzeptionellen Grundlagen dieses PRDs sind an folgenden Quellen verankert. Diese Referenzen sind Teil der Definitionsgrundlage; Abweichungen vom hier fixierten Stand müssen explizit im PRD vermerkt werden.
|
||||||
|
|
||||||
|
- **Karpathy, Andrej — "LLM wiki" / LLM-Wiki-Prinzip:**
|
||||||
|
https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
|
||||||
|
Idee: Rohquellen (immutable raw sources) werden durch ein LLM in ein persistentes Wiki überführt und aktuell gehalten — statt Retrieval über Rohdateien bei jeder Anfrage. In § 0 und § 1 verarbeitet; für v1 prägend für Concepts, Provenienz und das "Knowledge should compound."-Versprechen.
|
||||||
|
|
||||||
|
- **Open Knowledge Format (OKF), Version 0.2 — Spezifikation (Google Cloud):**
|
||||||
|
https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md
|
||||||
|
Normativer Format-Standard für das Knowledge Bundle (§ 8.1, FR-9). OKF 0.2 definiert: Knowledge Bundle aus Markdown mit YAML-Frontmatter; `type` als einziges Pflichtfeld (nicht gesperrte `.md`-Dateien im Bundle müssen einen `type` tragen); optionale Mindest-Metadaten für Provenienz (`sources`), Trust (`generated`, `verified` mit `human:`-Präfix), Lifecycle (`status`, `stale_after`) und Verlinkung (bundle-relative Links, `references/`-Konvention); `okf_version: "0.2"`-Deklaration optional in einer `index.md` des Bundleroots; Konformität: Konsumenten sollen Bundles auch ohne optionale Felder und Indexes akzeptieren.
|
||||||
|
|
||||||
|
Diese Referenzen dienen dem PRD als fixierte Bezugspunkte; die jeweils gültige Version für v1 ist wie angegeben.
|
||||||
@@ -0,0 +1,15 @@
|
|||||||
|
# source.md — PRD (Wiki of Wikis)
|
||||||
|
|
||||||
|
Materialisiert als Quelle unter `raw/` (Story 1.2, AD-12).
|
||||||
|
|
||||||
|
- **Datei (Evidenz):** `prd-wow20-2026-08-14.md`
|
||||||
|
- **Herkunft (kanonisch):** `_bmad-output/planning-artifacts/prds/prd-wow20-2026-08-14/prd.md`
|
||||||
|
- **Kopie erstellt:** 2026-08-14
|
||||||
|
- **Dokumentationstand (Quelle):** `status: final`, `updated: 2026-08-14`
|
||||||
|
- **Kurzbeschreibung:** Produktanforderungen inkl. FR-1 (Sources bereitstellen), FR-2 (Source/Knowledge-Trennung), A-3 (keine GUI), A-4 (lokale Bereitstellung, keine URL-Abrufe).
|
||||||
|
|
||||||
|
## Provenienz-Hinweis
|
||||||
|
|
||||||
|
- Diese `source.md` ist ein Artefakt, **keine Evidenz** (vgl. `raw/README.md`).
|
||||||
|
- Herkunftspfade unter `_bmad-output/` sind generierte Planungs-Artefakte und im Repo nicht versioniert — Reproduktionshinweis, keine feste Referenz.
|
||||||
|
- Ändert sich die Herkunftsquelle, wird eine **neue, datierte Datei** angelegt (AD-3); diese Datei bleibt unverändert.
|
||||||
Reference in New Issue
Block a user