erstellt PRD

.idea/vcs.xml

@@ -0,0 +1,6 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="VcsDirectoryMappings">
+    <mapping directory="$PROJECT_DIR$" vcs="Git" />
+  </component>
+</project>

_bmad-output/planning-artifacts/prds/prd-wow20-2026-08-14/.memlog.md

@@ -0,0 +1,20 @@
+---
+topic: Wiki of Wikis (LLM Wiki Compiler / OKF 0.2)
+updated: 2026-08-14T17:31
+---
+
+- (event) Run gestartet: Create aus vollständigem Nutzer-Entwurf (FAQ/Headless, kein Interaktives Review möglich)
+- (decision) Kernposition: Wiki of Wikis ist Knowledge Compiler, kein Retrieval-System; Karpathy's LLM-Wiki-Prinzip (Sources -> LLM Compilation -> Curated Wiki)
+- (decision) Kanonisches Format: OKF 0.2 als normativer Standard (Markdown+YAML-Frontmatter, type-Attribut, Provenienz/Lifecycle-Konventionen), kein eigener OKF-Dialekt
+- (decision) Kanonischer Zustand: Git-versioniertes Knowledge Bundle als Source of Truth (A-2); abgeleitete Indizes/Caches nicht Source of Truth
+- (decision) Scope-Guardrail: Sources + existing knowledge -> improved curated knowledge; Source-Adapter/Consumer-Adapter nur als Integrationen, nicht Kern; Retrieval ist Consumer-Verhalten
+- (decision) FR-Modell: 16 FRs, gruppiert 4.1 Source Intake / 4.2 LLM Compilation / 4.3 OKF Bundle / 4.4 Incremental Evolution / 4.5 Consumption; 7 NFRs; 5 SMs + 3 Counter-Metrics
+- (assumption) A-1 Target User premium persönl./teaminternes Dev-Tool; A-3 keine GUI in v1; A-4 Source-Beschaffung nicht Kern (nur bereitgestelltes Material) - aus Nutzerdokument übernommen
+- (assumption) Open Questions 1-7 bleiben offen (u.a. Source Acquisition, Human-authored Concepts, Verification Workflow, Conflict Resolution, Source Lifecycle, Produktname); Q4 explizit Architekturfrage
+- (event) Reviewer-Gate: Rubrik-Review (2 high / 3 medium / 3 low) + Adversarial (2 critical / 3 high / rest low) abgeschlossen; Befunde gesichtet
+- (event) Reconcile: Nur minor gaps (Item-Fidelity nur stichprobenhaft geprüft, Straffungen UJ-1/FR-9/FR-11, Tonelemente); kein materialer Verlust
+- (decision) Anpassung 1: OKF-0.2-Bezug gepinnt und verifiziert (Speclink GoogleCloudPlatform/knowledge-catalog/okf/SPEC.md v0.2; type Pflichtfeld; sources/generated/verified/okf_version definiert); Karpathy-Gist und OKF-SPEC als Anker-Referenzen in PRD aufgenommen (Wunsch ProMods)
+- (decision) Anpassung 2: A-4 als Entscheidung formuliert ('v1 lokal bereitgestelltes Material, keine URL-Beschaffung'); OQ-1 dadurch geklärt und aus Open Questions entfernt
+- (decision) Nicht im PRD präskribiert: OQ-4 Relevanzsuche und Bundle-Layout verbleiben als Architektur-Entscheidungen; PRD belässt Separation-of-Concerns-Guardrail unverändert
+- (decision) OQ-Triage: OQ-1(Source Acquisition) gestrichen, durch A-4/FR-1 geklärt (v1 lokal) - alle nachfolgenden OQ neu nummeriert; OQ-2/3/5(Verification-Interaktionsmodell) bleibt PRD-schwebend, Owner bmad-architecture (v1-Modell: maschinell erzeugt+ungeprüft); OQ-3(Compilation Scope)/OQ-4(Conflict Resolution)/OQ-5(Source Lifecycle) verbleiben als Architektur-Tickets; OQ-6(Produktname) Owner PM, Revisit vor UX-vorbereitung
+- (event) PRD finalisiert (status: final, updated 2026-08-14); § 13 Anker-Referenzen (Karpathy-Gist, OKF SPEC) und Triage-Dokumentation aufgenommen

_bmad-output/planning-artifacts/prds/prd-wow20-2026-08-14/prd.md

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

_bmad-output/planning-artifacts/prds/prd-wow20-2026-08-14/reconcile-input.md

@@ -0,0 +1,16 @@
+# Input Reconciliation — Wiki of Wikis
+
+## Input name
+"Vollständiger Nutzer-PRD-Entwurf (Task-Eingabe /bmad-prd)"
+
+## Urteil
+**Minor gaps** — Auf Basis der im Prompt gelieferten Zusammenfassungen ist KEINE materiale Lücke belegbar (Struktur deckungsgleich: Abschnitte 0–12, 16 FRs, 7 NFRs, 5 SMs + 3 Counter, 7 OQs, 5 Assumptions, Glossary 10 Begriffe inkl. Wiki Page). Es gibt drei vom Facilitator eingestandene Straffungen (UJ-1, FR-9, FR-11, Listen→Fließtext) sowie zwei Risiko-Vektoren (Tonelemente, Item-Fidelity), die auf dieser Evidenz nicht verifiziert werden können. Einschränkung des Runs: Headless/Offline, ausschließlich die beiden Zusammenfassungen im Prompt — keine Dateizugriffe, daher keine Wort-für-Wort-Prüfung möglich.
+
+## Gaps (4, priorisiert)
+- **[mittel] Item-Fidelity unbelegt — JTBD-/Scope-/Mapping-Details** — Die Final-Summary bestätigt nur Zähler (16 FRs, 7 NFRs, 5+3 SMs, 7 OQs, 5 Assumptions, 10 Glossary-Begriffe), nicht die Items selbst: keins der 9 JTBD-Bullets, keins der 13 In-Scope-Items, keins der 18 Out-of-Scope-Items, keine §5-Non-Goal-Position, kein SM-"Validiert FR-x"-Mapping wird in der Final-Summary genannt. Auf dieser Lauf-Evidenz ist also nicht beweisbar, dass gerade diese Checklisten-Elemente verlustfrei übernommen wurden — das ist die einzige Stelle, wo ein unentdeckter echter Verlust möglich bleibt. *Handling:* Parent führt den Item-Zahlenabgleich (9/13/18/§5-Liste/SM-Mappings) direkt gegen prd.md vs. Entwurf aus — bei Headless-Lauf reicht ein Zähl-Check der enumerierten Listen.
+- **[gering] Straffung UJ-1 / FR-9 / FR-11 (Listen→Fließtext)** — Vom Facilitator bestätigte Inhaltsedits. Bei der Zusammenlegung enumerierter Listen ist die FR-Consequence der erste Verlustkandidat; FR-9 und FR-11 sind per Struktur consequence-verwaltete Features, UJ-1 trägt die JTBD-Logik. Die Zusicherung „ohne Inhalt zu verlieren" ist plausibel, aber nicht geprüft. *Handling:* Parent gleicht die Consequences von FR-9 und FR-11 sowie die UJ-1-Schritte (inkl. Rückbindung an die 9 JTBD-Bullets) im Finaltext gegen den Entwurf ab.
+- **[gering] Tonelemente nicht bestätigt** — Die vier qualitativen Motive des Entwurfs („Knowledge should compound."-Versprechen, Curator-/Human-in-der-Schleife-Aspekt, Betonung „nicht erneut rekonstruieren müssen", Anti-Plattform-Ton bzw. „Retrieval ist Consumer-Verhalten") sind nicht FR-strukturiert; eine rein strukturelle Transkription würde sie stillschweigend fallenlassen, und die Final-Summary erwähnt keines davon. *Handling:* Parent sucht im finalen prd.md nach diesen vier Motiven (Stichworte: „compound", „curat"/„kurat", „rekonstruier", Anti-Plattform/Consumer-Verhalten); Fehlen einer Formulierung = Dämpfung melden.
+- **[info] Glossary-Zählung „9" vs. „10" im Entwurf** — Der Entwurf etikettiert §3 als „9 Begriffe", zählt aber 10 auf (Source, Source Material, Knowledge Bundle, Concept, Wiki Page, Compiler, Compilation Run, Curated Knowledge, Provenance, Consumer). Das Finale meldet korrekt 10 inkl. Wiki Page. Keine Lücke — die Abweichung stammt aus dem Ursprungsdokument selbst. *Handling:* Keine Aktion; „10" im Finalen belassen, ggf. im Entwurf die Etikette nicht „korrigieren".
+
+## Schlussbemerkung
+Auf der ausschließlich im Prompt verfügbaren Evidenz ist keine dokumentschädigende Lücke belegbar; die drei Straffungen sind die einzigen eingestandenen Inhaltsedits. Die tatsächliche Item-Fidelity (JTBD, In-/Out-of-Scope, SM→FR-Mappings) und der Ton sind auf diesem Offline-Lauf nicht überprüfbar — beide Punkte sollten durch den Parent per Datei-Spot-Check geschlossen werden, bevor der PRD als finalisiert gilt.

_bmad-output/planning-artifacts/prds/prd-wow20-2026-08-14/review-adversarial.md

@@ -0,0 +1,25 @@
+# Adversarial Review — Wiki of Wikis (Scope & Decision-Readiness)
+
+## Verdict
+
+Der PRD hat eine überraschend gut gezogene Produktgrenze — §12, §5 und §6.2 setzen die "Nichts-Zwingendes"-Disziplin überzeugend um; die meisten FRs bleiben innerhalb der Linie. Die eigentliche Schwäche ist die Decision-Readiness: Kernentscheidungen werden als Open Questions geführt (OQ-1 vs. A-4), und zwei Open Questions (OQ-3, OQ-5) setzen ein Nutzer-Interaktionsmodell voraus, das zu A-3 und §6.2 nicht existiert. Der größte ungelöste Risikopunkt liegt im Inneren des Compilers selbst: die Relevanzsuche für bestehende Concepts (OQ-4) und die operative Trennung von Sources und Bundle im selben Baum — genau dort können Search-, Index- und Layout-Entscheidungen stillschweigend in ein Produkt zurückkehren, das Retrieval und DBs explizit ausgeschlossen hat. Das zentrale Wertversprechen — Synthese statt Kopie — ist mit FR-2/SM-2 weder geschützt noch messbar.
+
+## Findings
+
+- **[critical] OQ-1 ist kein offener Punkt, sondern ein versteckter Beschluss — der Widerspruch wird als Spannungsfeld an die Architektur weitergereicht.** A-4 entscheidet faktisch vor ("der Compiler verarbeitet grundsätzlich bereitgestelltes Source Material"), während OQ-1 als offen geführt wird. Es ist verdienstvoll, dass der PRD das "Widerspruch-Spannungsfeld" selbst benennt — aber ein benanntes Spannungsfeld ohne Auflösung ist kein Review-Ergebnis, sondern Schiebung: Die Architektur wird die Antwort still selbst wählen (vermutlich "nur lokal", weil am günstigsten) und sie als nicht dokumentierte Entscheidung tragen. Der Default-Fall ist für V1 sicher richtig — das Problem ist die Form. *Fix:* OQ-1 als Entscheidung schreiben: "V1: nur bereitgestelltes Material, keine URL-Beschaffung; Auflösung erst bei explizitem Trigger (z. B. erste reale Nutzung von Context7-/Web-Notizen als Quelle)." A-4 dann als getroffene Scoping-Entscheidung deklarieren statt als Annahme. Wenn OQ-1 wirklich offen bleiben soll, muss umgekehrt A-4 abgeschwächt werden.
+
+- **[critical] Der Compiler liest den eigenen Output — ohne Layout-Entscheidung ist die Separation-of-Concerns-Guardrail nicht durchsetzbar.** FR-4/FR-7/FR-12 kompilieren "gegen bestehendes Wissen", FR-13 (Human Curation) wirkt auf dieselbe Struktur, und der kanonische Zustand ist ein Git-versioniertes Markdown-Bundle. Operativ heißt das: Sources, bestehendes Wissen und Schreibziel leben im selben Arbeitsbaum bzw. Repository. Ohne operationale Trennung ist nicht entscheidbar, was der Compiler als unantastbare Source behandelt und was er überschreiben darf — gerade dann, wenn Mensch und Compiler dieselbe Datei fassen. Dazu kommt, dass "Source" und "Source Material" synonym verwendet werden, ohne dass geklärt wäre, was eine Source ist (eine Datei? ein Dokument? ein Verzeichnis? ein versioniertes Set?). Das ist kein Architektur-Kosmetikpunkt, sondern die betriebliche Kante der §12-Linie. *Fix:* Im PRD ein Minimal-Layout festlegen (z. B. `_sources/` getrennt vom Bundle, plus Ingest-Manifest mit Source-Status), "Source" operational definieren, und eine explizite Regel: "Der Compiler schreibt ausschließlich in das Bundle, nie in Sources; Human-Curation ist Bestandteil des Bundles."
+
+- **[high] "Retrieval ist Consumer-Verhalten" hat einen Blind Spot: Der Compiler selbst muss relevante Concepts finden (OQ-4) — das ist interne Retrieval-Infrastruktur, die an §6.2 vorbei wieder reinkommen kann.** FR-11 (Progressive Discovery / Index-Strukturen) ist vordergründig noch als statischer, generierter Bundle-Inhalt lieferbar (Index als OKF-Concept) — wenn explizit gemacht. Die eigentliche Falltür ist OQ-4: "Wie findet der Compiler relevante bestehende Concepts?" ist die Retrieval-Frage eines Produkts, das Retrieval per Dogma ausgrenzt. Lösungsraum: deterministisch-lexikalisch (Tags, Links, Dateinamen-Index, String-Matching — kompatibel), Embedding-Similarität (laut §6.2 vermutlich verboten) oder LLM-Browsen (langsam, teuer, nicht-deterministisch, konterkariert FR-14). Ohne V1-Eingrenzung nimmt die Architektur die billigste plausible Option — und wir hätten leise die Such-/Index-Infrastruktur, die Non-Goals und §6.2 ausschließen. *Fix:* OQ-4 patronieren: "V1: deterministische, strukturelle Relevanzbestimmung (Frontmatter-Tags, Links, Index-Map, String-Matching); Embeddings und externe Suche explizit verboten." FR-11 parallel als "statische, vom Compiler-Run generierte Bundle-Artefakte, kein Discovery-Service" verankern.
+
+- **[high] NFR-3 (Agent Readability) kollidiert mit FR-16 (Consumer-Neutralität) und wird zur Schema-Falle gegen §6.2.** Der PRD nennt zwei Consumer-Klassen (Menschen, LLM-Agenten: BMAD, Claude Code, Codex), und NFR-3 macht daraus eine Design-Optimierung für eine spezifische Agenten-Familie. Jeder Agent hat andere Lese-Gewohnheiten; sobald der Bundle für "Agent-Readability" optimiert wird, entsteht Druck auf exotische Konventionen — und das ist der direkte Weg in den von §6.2 verbotenen "eigenen OKF-Dialekt". Der Widerspruch zu FR-16 ist real: FR-16 entkoppelt die Consumer vom Compiler, NFR-3 koppelt die Bundle-Gestaltung an einen bestimmten Consumer. *Fix:* NFR-3 auf Format-Ebene zurückstufen: "Agent-Readability = gut verlinktes, atomares, frontmatter-sauberes Markdown, konsumierbar von jeder Tool-Klasse"; explizit keine Optimierung für eine Agenten-Familie in V1. Agenten-Ergonomie ist Consumer-Verhalten (FR-16), nicht Bundle-Eigenschaft. Soll tatsächlich ein Agent primär bedient werden, dann als benannte Entscheidung mit benanntem Trade-off.
+
+- **[high] Die Produktgrenze beschränkt Infrastruktur, aber nicht Verhalten — das Kernwertversprechen (Synthese statt Kopie) ist ungeschützt und ungemessen (FR-2, SM-2).** FR-2 verbietet nur "eine Kopie des Quelldokuments". Eine V1, die quellennahe Paraphrasen mit Link-Anhängseln erzeugt, erfüllt alle Guardrails — sie braucht keinerlei neue Infrastruktur — und ist wertlos. Der Complexity Guardrail (§12) gatekeeper ausschließlich Infrastruktur, nicht die Semantik der Transformation. SM-2 (Source-to-Knowledge Transformation) ist ohne operationale Definition von "Transformation vs. Querreferenz vs. Paraphrase" nicht testbar — die Metrik degeneriert zum Selbst-Score oder Placebo. Dasselbe betrifft die LLM-Varianz (siehe nächster Punkt): Der Guardrail-Ansatz des PRD greift systematisch an der falschen Ebene. *Fix:* SM-2 operationalisieren (z. B. "Anteil der Concepts mit Referenzen aus ≥2 Sources" plus Stichproben-Human-Review auf Copy-vs-Synthesis) und in FR-2 ein positives Kriterium ergänzen: Ein Concept gilt als integriert, wenn es in der Bundle-Struktur re-expressiert, verlinkt, mit Provenienz markiert und typischerweise aus mehr als einer Quelle/Concept synthetisiert wurde. Alternativ die V1-Grenze "Ein-Quellen-Paraphrase erlaubt" explizit als Limitation benennen.
+
+- **[high] OQ-5 (Nutzer-Einbindung bei Konflikten) und OQ-3 (Human-Review-Markierung) setzen ein Interaktionsmodell voraus, das zu A-3/§6.2 (keine GUI, kein Web-UI, kein Render/Runtime) nicht spezifiziert ist.** FR-8 "Widersprüche sichtbar behandeln" klingt harmlos, aber "sichtbar" ist die Frage: in welchem Medium und für wen? Ohne GUI bleiben nur (a) der Compiler schreibt Konflikte und Human-Review-Marker als First-Class-Inhalt ins Bundle, der Mensch entscheidet per Datei-Edit und Git-Commit im eigenen Workflow; (b) interaktiver CLI-Prompt während des Runs (bricht die Batch-/Inkremental-Logik von FR-12); (c) eine "Entscheide mich"-Warteschlange aus Dateien. Jede Variante hat andere Architekturkonsequenzen, keine wird auch nur skizziert. Zusätzlich bleibt in FR-13 die Nutzungsfrage unausgesprochen: Gewinnt bei Kollision der Compiler-Update (FR-6) oder die menschliche Kuratierung? Die Kosten beider Antworten sind benennbar — Compiler gewinnt → Wiki driftet selbst, Mensch gewinnt → Wiki verkommt zum statischen Archiv (bewusst gegen SM-1) — und sollten deshalb benannt werden. *Fix:* Im PRD eine V1-Baseline treffen: "Konflikte und Human-Review-Markierungen sind First-Class-Bundle-Inhalt; der Mensch wirkt ausschließlich über Datei-Edits + Git, kein Laufzeit-Dialog." Was danach offen bleibt, ist das Format der Markierung — nicht das Interaktionsmodell.
+
+- **[medium] LLM-Varianz vs. "nachvollziehbar per Git-Diff" (FR-14, FR-12): eine Weiche, deren aufgegebenes Gut nicht genannt wird.** Git als kanonischer Zustand und "Änderungen nachvollziehbar" tragen die stillschweigende Annahme stabiler, vergleichbarer Compiler-Outputs. Ein LLM, das dieselbe Source zweimal kompiliert, erzeugt unterschiedlichen Text — Git-Churn, Diffs, die Review-Nutzer nicht mehr unterscheidbar machen zwischen "Concept aktualisiert" und "Concept umformuliert", und ein inhaltlich unlesbares Diff für jede Human-Curation. Der PRD schweigt dazu; SM-C2 (Speed nicht primär) adressiert nur die Laufzeit, nicht die Stabilität. *Fix:* Als eigene Design-Entscheidung festschreiben: "Compiler-Output ist normalisiert/deterministisch anzustreben (temperaturarm, feste Prompt-IDs, stabile Sektionsreihenfolge, minimal-diff Inkarnation von Updates), sodass FR-14-Diffs Review-tauglich bleiben" — oder bewusst die Varianz mit kostenpflichtiger Konsequenz (OQ im PRD) akzeptieren. In der Folge auch die Run-Semantik klären ("Was ist ein Compilation Run — CLI-Invocation, Batch über ein Sourceset, Inkrement über Diff?"), damit FR-12 "inkrementell" testbar wird; beide Punkte gehören in den PRD, nicht in die Architektur.
+
+- **[medium] OKF 0.2 als kanonisches Format ist eine Entscheidung ohne Trade-off-Formulierung und kollidiert latent mit NFR "Vendor Independence" respektive §6.2 "kein eigener Dialekt".** OKF 0.2 ist früh (Version 0.2), extern fremdgesteuert, evolutionär mit Breaking-Change-Risiko. Der PRD kauft damit eine Fidelity-Decke (der Bundle kann nie mehr Struktur tragen als OKF hergibt) und eine externe Governance-Abhängigkeit — neben einem NFR, das Unabhängigkeit fordert. Konkret: Wenn OKF 0.2 keinen Platz für Konflikt-Marker (FR-8), Human-Review-Flags (OQ-3) oder Diff-freundliche Aktualisierungen (FR-14) bietet, entsteht sofort Erweiterungsdruck — der von §6.2 verboten ist. Der PRD umgeht das, indem er es ausspart; damit bleibt die Grenze des Formats unbestimmt und wandert als Rate-Runde in die Architektur. *Fix:* Eine explizite "OKF-Boundary-Notiz" einfügen: "Wo OKF 0.2 in V1 nicht trägt, wird [Feature zurückgehalten | Erweiterung als offene Frage | Sidecar-Datei]" — die Grenze des Formats als Entscheidung markieren, nicht als Implikation stehen lassen.
+
+- **[low] OQ-7 (Name) ist keine technische Entscheidung und belegt einen Slot in einer Warteschlange mit echten Posten.** Zudem ist die Benennung nicht folgenlos, sondern macht selbst Scope-Arbeit: "Wiki" lädt zu Wiki-Feature-Erwartungen ein (das §5/§6.2 ausschließt), "Compiler" verspricht deterministische Batch-Transformation — eine Eigenschaft, die angesichts der LLM-Varianz (siehe oben) tatsächlich erst noch zu entscheiden wäre. *Fix:* OQ-7 schließen ("Arbeitsname, kein Product-Decision-Item") und stattdessen die längst entscheidbare Compilation-Run-Semantik als OQ bzw. Mini-Entscheidung aufnehmen.

_bmad-output/planning-artifacts/prds/prd-wow20-2026-08-14/review-rubric.md

@@ -0,0 +1,52 @@
+# PRD Quality Review — Wiki of Wikis
+
+## Overall verdict
+
+Ungewöhnlich reifes PRD: Substanz, Scope-Honesty und strategische Kohärenz sind durchgehend stark, der Assumptions-Index und die Open Questions sind ehrlich, die FR-Ebene (FR-1..16) mit Consequences ist entscheidungsfähiges Rohmaterial für Architektur und Stories. Gefährdet wird die Durchgängigkeit durch zwei Punkte: (1) der normative OKF-0.2-Bezug ist nicht gepinnt/verifizierbar (§0, §8.1, FR-9), obwohl fast alle NFRs und SM darauf aufbauen; (2) die Done-ness ist die schwächste Dimension — Modalitäten-Drift "kann"/"muss" in §4 plus Erfolgsmetriken ohne Zielwerte in §9. Kein kritisches Richtungsrisiko; die offenen Fragen (OQ-3/4/5) sind jedoch architekturrelevant und müssen vor oder als expliziter Entscheidungsauftrag in bmad-architecture entschieden werden.
+
+## Decision-readiness — adequate
+
+Die Basis ist robust entscheidbar: MVP-Mussliste (§6.1), explizite Out-of-Scope (§6.2), Guardrails (§8.1–8.4), Assumptions-Index (§11), ehrliche Non-Goals (§5). Abschwächungen:
+- Drei Open Questions sind nicht kosmetisch, sondern v1-blockierend für die Compiler-Architektur: OQ-4 (Relevanzbestimmung = Kernalgorithmus; im PRD selbst als "primär Architekturfrage" markiert — korrekt delegiert, muss aber als expliziter Architektur-DR beauftragt werden), OQ-5 (Conflict Resolution, kollidiert direkt mit den Konsequenzen von FR-8) und OQ-3 (Review-Kennzeichnung, blockiert eine FR-13-Konsequenz).
+- OKF 0.2 ist normativ gesetzt (§8.1 "OKF ist der normative Standard", FR-9), aber ohne Link/Version/Feld-Schema nicht prüfbar — siehe Finding H-1. Das ist die größte Einzelunsicherheit für alle konformitätsabhängigen Anforderungen.
+
+### Findings
+- **[high]** OKF 0.2 nicht verifizierbar / nicht gepinnt (§0, §8.1, FR-9, FR-11; NFR-1/5; SM-3/SM-5) — "Googles Open Knowledge Format (OKF) 0.2" wird als normativer Standard gesetzt, aber es fehlen Link, Versions-/Stand-Pin und die Konventionen (Pflicht-Frontmatter-Felder, type-Vokabular, Provenienz-/Lifecycle-/Trust-Regeln). Da FR-9, FR-11, NFR-1..NFR-5 und SM-3/SM-5 auf Konformität aufbauen, kann die Architektur keine Konformitätskriterien und die Stories keine Akzeptanzkriterien ableiten. *Fix:* Spec-Link und Stand/Version im PRD verankern oder als ersten Decision Record zur Architektur mit v1-Feld-Schema und Konformitäts-Checkliste festlegen. Confidence: high.
+- **[high]** Modalitäten-Drift + Erfolgsmetriken ohne Zielwerte (§4 passim, §6.1, §9) — Features sind überwiegend als "kann" formuliert (FR-1, FR-5, FR-6, FR-10) statt "muss"; die harte v1-Verpflichtung steht nur in der §6.1-Liste. SM-1, SM-3 und SM-5 sind Verhaltensbeschreibungen ohne falsifizierbares Ziel ("nachvollziehbar", "vollständig lesbar" — gemessen woran?). Damit ist "done" für SM-1/SM-3 und für einzelne FRs nicht entscheidbar; bmad-create-epics-and-stories wird die Kriterien neu erfinden. *Fix:* Modalitäten in §4 auf MUST (v1) vs. MAY konsolidieren; SM-1/SM-3 mit beobachtbaren Tests schärfen (z.B. SM-1: "Lauf 2 auf identischem Source-Set erzeugt Git-Diff nur in betroffenen Concepts und erhält ≥N % der Provenienz-Links"; SM-3: "zu jedem aus Sources abgeleiteten Concept existiert eine Provenienz-Referenz auf ≥1 Source, stichprobenprüfbar"). Confidence: high.
+- **[medium]** Source-Retraction/Lifecycle ohne Feature-Abdeckung (OQ-6; §4, §5, §6) — "Source entfernt, ersetzt oder als falsch erkannt" ist für ein persönliches/teaminternes Tool ein realer v1-Fall (falsch eingespielte Quelle, korrigierte Dokumentation), aber kein FR deckt Entfernen/Retraction ab; OQ-6 bleibt offen und FR-13/NFR-7 helfen nur teilweise. *Fix:* OQ-6 als Architektur-Entscheidungspflicht deklarieren und ein minimales Retraction-Verhalten definieren (z.B. "Provenienz-Link entfernen ≠ Concept löschen; Retraction als explizite Concept-Mutation"), oder den Verzicht bewusst dokumentieren. Confidence: high.
+- **[medium]** OQ-3 blockiert FR-13-Konsequenz "Human-reviewed Knowledge ... unterscheidbar bleiben" (§10 OQ-3; FR-13; FR-9 "Trust-Metadaten können verwendet werden") — erst mit der Entscheidung, wo und in welchem Metadatum die Review-Kennzeichnung liegt, ist diese Konsequenz erfüllbar. Da FR-9 Trust-Metadaten bereits erlaubt, liegt ein v1-Default nahe (Frontmatter trust/lifecycle-Feld, Edit-Route via Git-Commit). *Fix:* OQ-3 in bmad-architecture auf so einen Default festlegen, damit FR-13 abprüfbar wird. Confidence: high.
+- **[medium]** OQ-5 unentschieden bei FR-8 im MVP (§10 OQ-5, FR-8, §6.1) — "Welche Konflikte darf der Compiler selbst auflösen ...?" entscheidet über das Kernverhalten des Compilers; solange offen, muss die Architektur beide Pfade (Auto-Auflösung vs. Nutzer-Einbindung) vorsehen. Für ein Dev-Tool ohne UI ist "Nutzer einbeziehen" zusätzlich ein Designproblem (Block-Status/Review-Warteschlange ohne Weboberfläche). *Fix:* Heuristik-Liste (Datum/Frische, Provenienzstärke, Human-Priorität) + Escalation als Architektur-DR definieren. Confidence: high.
+- **[low]** OQ-1 vs. A-4 Assumptions-Roundtrip (§10 OQ-1, §11 A-4) — A-4 behauptet "Source-Beschaffung ist nicht Kern", OQ-1 lässt "URLs selbst abrufen?" für v1 offen; fällt die Antwort "ja" aus, müssen A-4 und §4.1 nachgezogen werden. *Fix:* OQ-1 entscheiden oder A-4 um "URL-Abruf nur als optionaler Source-Adapter außerhalb des Kerns" präzisieren. Confidence: high.
+- **[low]** Größenszenario fehlt (§4, §7, §9) — keine Angabe zu erwartetem Source-Volumen (Anzahl Dateien, MB), Concept-Anzahl oder akzeptabler Laufzeit eines Compilation Runs; relevant für Kontextfenster-/Chunking-Strategie der Architektur und Story-Schätzungen. *Fix:* typische Größenordnung im PRD oder als Architektur-Input benennen (z.B. "personales Team-Wiki < 500 Concepts, Sources im MB-Bereich"). Confidence: medium.
+- **[low]** "Producer-spezifische Erweiterungen" vs. "eigener OKF-Dialekt" (FR-9-Konsequenz vs. §6.2) — FR-9 erlaubt Erweiterungen (solange portabel), §6.2 schließt den eigenen OKF-Dialekt aus; die Grenzlinie ist unklar und kann zwischen PRD, Architektur und Stories unterschiedlich ausgelegt werden. *Fix:* eine Kriterienzeile anfügen (z.B. "Erweiterungen nur in optionalen Metadaten, keine Erweiterung des Pflicht-Feld-Schemas"). Confidence: medium.
+
+## Substance over theater — strong
+
+Kein Füllmaterial. Jede FR trägt eine beobachtbare Konsequenz; Counter-Metrics (SM-C1..C3) verhindern Fehloptimierung; die Kernaussage "Retrieval ist Consumer-Verhalten, nicht Kern des Wiki Compilers" (§5) wird konsequent durchgehalten. Die drei UJs sind konkret und nutzen mit "Michael" die reale Persona des Verfassers — für ein persönliches Tool ein Vorteil, keine Schwäche. Der einzige theaternahe Rest: §12 "Product Boundary" ist eine Prosa-Kapsel, obwohl als "[ASCII-Diagramm: …]" bezeichnet — kosmetisch.
+
+## Strategic coherence — strong
+
+Vision (Compiler, kein Retrieval-System, §1) ↔ Features (FR-4 "bestehendes Wiki als Input") ↔ Non-Goals (§5) ↔ Scope (§6) ↔ Guardrails (§8.4) bilden eine geschlossene Kette; NFR-7 (Graceful Partial Knowledge) und FR-8 greifen konsistent ineinander; §8.2 (abgeleitete Indizes nicht Source of Truth) ist mit §6.2 (Index-Strukturen out of scope) kohärent. Restspannung: das Spannungsfeld "autonome Synthese" vs. "menschliche Kuratierung" ist über FR-13 erst halb aufgelöst (siehe Finding zu OQ-3).
+
+## Done-ness clarity — thin
+
+Die schwächste Dimension. Gründe: (a) Modalitäten-Drift in §4 (H-2); (b) Erfolgsmetriken ohne Zielwerte und ohne Mapping auf mehrere Kern-FRs (SM-Mapping ist einseitig — siehe Mechanical); (c) keine Akzeptanz-/Exit-Kriterien je Feature — die "Consequences" sind gutes, aber nicht ausreichendes Ersatzmaterial für Story-Akzeptanzkriterien (z.B. FR-5 "kann … erzeugen" lässt offen, was einen erfolgreichen Lauf von einem teilfehlgeschlagenen unterscheidet). UJs besitzen ebenfalls keine Erfolgsbeobachtung; die UJs sind zudem nirgends auf FRs/SMs verlinkt, sodass Stories nicht erkennen, welche Journeys welche FRs abdecken.
+
+## Scope honesty — strong
+
+Vorbildlich: nicht nur abstrakte Non-Goals (§5 mit präziser Negativ-Liste inkl. "BMAD-Erweiterung", "CodeGraph-Erweiterung"), sondern explizite MVP-Grenze (§6.2) und Counter-Metrics, die Fehlannahmen über Metriken vorbeugen. Offene Punkte sind transparent als OQ 1–7 geführt und als Entscheidungsbedarf markiert. Einzige Kante: die Extension-vs.-Dialekt-Unschärfe (FR-9/§6.2) und die OQ-1/A-4-Spannung (siehe Findings) — beide klein, aber sie betreffen genau die Scope-Grenze.
+
+## Downstream usability — adequate
+
+Für bmad-architecture gut vorbereitet: technische Mechanismen sind bewusst delegiert (§0); §8.4 gibt dem Architekten ein klares Aufnahmekriterium für neue Infrastruktur; FR-4 und §8.2 sind direktals Komponenten-/State-Design lesbar. Ausbaufähig: (a) OKF-Pin (H-1) blockiert Konformitätsdesign; (b) Retraction fehlt (OQ-6) — die Architektur muss selbst einen Default bauen; (c) Null-Skalenszenario; (d) keine UJ-zu-FR-Zuordnung (für Story-Ableitung relevant). Der Architekt wird die drei offenen Compiler-Fragen (OQ-3/4/5) als eigene Decision Records beantworten müssen — das PRD weiß das bereits und sollte es als expliziten Auftrag formulieren statt als bloße OQ-Liste.
+
+## Shape fit — adequate
+
+Vollständige Sektionen 0–12 mit Frontmatter (status/created/updated) und Assumptions-Index; passt zur PRD-Rolle im Workflow und übergibt sauber an Architektur. Unschärfen in der Form: Tiefe Features (FR mit Consequences) vs. flache Metriken (SM ohne Zielwerte) — das Ungleichgewicht gehört behoben (Done-ness); §12 ist eine Zusammenfassung statt eines Diagramms; UJs stehen ohne Referenzen auf FRs/SMs. Kein strukturelles Hindernis, aber die Form spiegelt die inhaltliche Schieflage bei Metriken.
+
+## Mechanical notes
+
+- ID-Kontinuität: FR-1..16, NFR-1..7, SM-1..5 + SM-C1..3, OQ-1..7, A-1..5 — lückenlos, keine Duplikate.
+- SM→FR-Mappings: SM-1→FR-4/6/12, SM-3→FR-3/9, SM-4→FR-15/16, SM-5→NFR-1/2/5 sind zutreffend. Lücken: FR-8 (Widersprüche), FR-13 (Kuratierung) und NFR-3/4/6/7 werden von keiner Metrik validiert — FR-8/NFR-7 sind Kern des Wertversprechens und verdienen mindestens einen SM-Bezug. SM-2 listet "Validiert FR-5, FR-7", obwohl der SM-2-Text "bzw. Änderungen bestehender Concepts" auch FR-6 betrifft (Mapping unvollständig).
+- Glossary-Drift: Lemma "Provenance" (§3) gegen Körper "Provenienz" (FR-3, §2.2); sowie "Curated OKF Wiki" (§0-Diagramm) gegen Canonical "Knowledge Bundle" (§3) — je eine einheitliche Benennung empfohlen.
+- Assumptions-Index-Roundtrip: A-1↔[ASSUMPTION §2.1] und A-2↔[ASSUMPTION §8.2] konsistent; A-3 (UI) ohne Inline-Duplikat, aber mit §6.2 kompatibel; A-4↔OQ-1 unter Spannung (siehe Low-Finding). UJ-Protagonist "Michael" ist mit §2.1-Fokus ("Michael" = Verfasser) abgestimmt, UJ-3 wechselt zur generischen Form — kein Fehler, aber Inkonsistenz der Perspektive, die bei Story-Ausformulierung stolpern kann.