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,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