53 lines
11 KiB
Markdown
53 lines
11 KiB
Markdown
# 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.
|