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

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.