PRD-Lebenszyklus

Was macht PRD-Lebenszyklus?

Vereinheitlicht die zuvor verteilten Fähigkeiten zur PRD-Erstellung, Vervollständigung, Prüfung und Ausführungsplanung in einem einzigen Einstiegspunkt, während gleichzeitig die unterschiedlichen Berechtigungsgrenzen und Bestätigungs-Gates der einzelnen Phasen erhalten bleiben.

Modus-Routing

Prüft zunächst, welche Materialien der Benutzer besitzt und welches Ergebnis er erwartet, und startet nur den erforderlichen Modus, ohne den Benutzer zu zwingen, den gesamten Prozess von vorne zu durchlaufen.

Modus	Typische Eingabe	Hauptergebnis	Wichtige Grenze
create Erstellung	Funktionsidee + vorhandenes Repository	Statusbericht, Bestätigungsbaseline, versioniertes PRD	Erst Beweise sammeln, dann schrittweise bestätigen; kein PRD ohne genehmigte Baseline
refine Vervollständigung	PRD-/Anforderungsentwurf	Schrittweise Überarbeitung, Versionshistorie, optional .docx	Jeden Schritt zuerst prüfen, erst nach Bestätigung schreiben und versionieren
review Red-Team-Prüfung	Bestimmtes PRD + optionale Baseline/Repository	Gestufte Probleme, Beweise, Überarbeitungsvorschläge	Nur prüfen, kein Dokument ändern, keinen Code implementieren
execute Ausführungsplanung	Genehmigtes PRD + vorhandenes Repository	Bereitschafts-Audit, Entwicklungsausführungsdokument, Traceability-Matrix, Steuer-Prompts	Nur planen, kein PRD ändern, keinen Code implementieren

Routing-Regeln:

• Nur eine Idee, die in ein PRD umgesetzt werden soll, unter Berücksichtigung des bestehenden Projekts: create verwenden.
• Bereits ein Entwurf, Ziel ist Vervollständigung, Überarbeitung, Verfeinerung oder Finalisierung: refine verwenden.
• Ziel ist es, Widersprüche, Risiken, Auslassungen oder nicht verifizierbare Punkte zu finden, ohne Änderungen zu verlangen: review verwenden.
• Bereits eine explizit genehmigte Version, Ziel ist die Übergabe an Codex für die phasenweise Entwicklung: execute verwenden.
• Wenn der Benutzer eine End-to-End-Verarbeitung wünscht, starte mit der frühesten anwendbaren Phase; halte an jedem unten genannten Gate an und warte auf Autorisierung, ohne automatisch die Phase zu wechseln.
• Wenn "prüfen" sowohl eine Prüfung als auch eine Änderung bedeuten könnte, bevorzuge den schreibgeschützten review Modus und erkläre, dass die Prüfergebnisse nach separater Autorisierung in den refine Modus übernommen werden können.
• Wenn der Benutzer nur lokale Code-, UI-, Interaktions-, Refactoring- oder Architekturänderungen im bestehenden Repository bewerten und umsetzen möchte, verwende repo-grounded-change; zwinge nicht dazu, zuerst ein PRD zu schreiben.

Gemeinsame Einschränkungen

Autoritäre Reihenfolge

Sofern der Benutzer nichts anderes angibt, werden Konflikte in der folgenden Reihenfolge behandelt:

1. Aktuelle explizite Anweisung des Benutzers.
2. In der aktuellen Aufgabe bereits explizit bestätigte Entscheidungen.
3. Festgelegte genehmigte Anforderungsbaseline und PRD.
4. Aktuelles Verhalten, das durch Code und Tests nachgewiesen ist.
5. Aktuelle Produktdokumentation.
6. Historische Entwürfe, Prüfprotokolle und Empfehlungen.

Das Ziel-PRD ist nicht von Natur aus korrekt; bei Konflikten zeige den Konflikt, die Auswirkungen und die erforderliche Entscheidung auf, wähle nicht stillschweigend eine Seite. Code dient zum Nachweis des Ist-Zustands, er kann neu genehmigte Anforderungen nicht verneinen.

Fakten- und Empfehlungs-Tags

Verwende bei möglicher Verwechslung von Schlussfolgerungen: Bestätigt, Code-Fakt, Dokumentations-Fakt, Produktannahme, Technische Empfehlung, Ausstehend, In dieser Version nicht implementiert.

Autorisierungsgrenzen

• Keine Geschäftsregeln, Zustände, Schwellenwerte, Berechtigungen, Prioritäten, Abhängigkeiten, externen Integrationen oder Abnahmekriterien erfinden.
• Abschluss einer Phase, Bestehen einer Prüfung oder Erstellung eines Plans nicht als Implementierungsautorisierung betrachten.
• Keinen Geschäftscode ändern, nicht committen, pushen, deployen oder externe Produktionssysteme aufrufen.
• Arbeitsbaum prüfen und vorhandene Änderungen des Benutzers schützen; bei unsicherer Umgehung anhalten und Überlappungsbereich erläutern.
• Nur den vom Benutzer angeforderten aktuellen Modus ausführen. Für den Eintritt in den nächsten Modus ist eine explizite Anfrage oder Bestätigung erforderlich.

create: PRD-Erstellung nach Repository-Audit

1. Lese project-discovery.md, überprüfe Repository, Produktmaterialien, Tests und Arbeitsbaum, und erstelle einen aktuellen Statusbericht. Halte an und warte auf die Bestätigung des Status, es sei denn, der Benutzer fordert explizit einen zusammengeführten Prozess.
2. Lese clarification-rounds.md und plane Themen basierend auf Beweislücken. Diskutiere immer nur ein Thema pro Runde, stelle 1–3 sich gegenseitig ausschließende Multiple-Choice-Fragen; empfehle die erste Option und erläutere die Auswirkungen.
3. Nach der Antwort des Benutzers fasse zunächst die bestätigten Punkte, unbestätigten Punkte, Konflikte und nachgelagerten Auswirkungen dieser Runde zusammen und warte dann auf die Zusammenfassungsbestätigung. Nichtbestätigte Punkte dürfen nicht in das nächste Thema übernommen werden.
4. Nach Bestätigung aller relevanten Themen lese baseline-and-prd.md, erstelle die Anforderungsbestätigungs-Baseline und halte an.
5. Nur wenn der Benutzer die Baseline explizit genehmigt und die Erstellung eines PRD anfordert, erstelle ein versioniertes PRD; suche nach vorhandenen Versionen und inkrementiere, überschreibe nicht stillschweigend.

Vollständigkeitskriterien: PRD stimmt mit bestätigten Entscheidungen überein, Umfang und Nicht-Ziele sind klar, Anforderungen und Abnahmen sind nachverfolgbar, Repository-Auswirkungen sind belegt, offene Punkte sind nicht als endgültige Anforderungen getarnt.

refine: Schrittweise Vervollständigung und versionierte Überarbeitung

1. Lese den vollständigen Originaltext, behalte die ursprüngliche Bedeutung und erstelle eine Arbeits-Baseline. Wenn ein neues Markdown-Arbeitsdokument erforderlich ist, verwende scripts/prd_doc.py init, um v1.0 und ein Kapitelgerüst zu erstellen.
2. Lese den aktuellen Schritt-Abschnitt aus refinement-steps.md. Das Standardgerüst ist:
   • Anforderungsklärung und User Stories;
   • Funktionsumfang;
   • Randbedingungen;
   • Abnahmekriterien.
3. Bearbeite immer nur den aktuellen Schritt. Präsentiere den zu prüfenden Inhalt zunächst im Dialog, schreibe nicht vorzeitig in Dateien.
4. Wenn der Benutzer Änderungen oder Ergänzungen anfordert, bleibe im aktuellen Schritt, führe kein Upgrade durch. Schreibe nur in das Dokument und führe ein Minor-Upgrade und eine Änderungsaufzeichnung gemäß versioning.md durch, wenn der Benutzer es explizit bestätigt.
5. Wenn Metriken, Abhängigkeitsplanung, Risiko-Rollback, Compliance oder das Einpflegen von Prüfungskommentaren erforderlich sind, können Erweiterungsschritte eingefügt werden; wende ebenfalls den Gate "Ergebnis → Prüfung → Bestätigung → Schreiben → Upgrade" an.
6. Nach Bestätigung aller Schritte führe einen kompletten Merge-Durchlauf durch und führe ein Major-Upgrade durch. Wenn der Benutzer ein .docx wünscht, verwende scripts/prd_doc.py export und führe die Formatvalidierung mit verfügbaren Dokumenttools durch.

Der Inhalt jedes Schrittes soll sowohl vervollständigen als auch auf vage, widersprüchliche, nicht verifizierbare Punkte und leicht übersehene Szenarien im Originaltext hinweisen. User Stories, Funktion, Grenzen und Abnahmen müssen rückverfolgbar sein; Abnahmepunkte sollten klare Bedingungen und beobachtbare Ergebnisse enthalten.

Der Abschluss der Überarbeitung bedeutet nicht, dass das PRD geschäftlich genehmigt ist, und führt nicht automatisch zu review oder execute.

review: Evidenzbasierte Red-Team-Prüfung

1. Lese review-protocol.md, identifiziere Zielversion, Prüfungsumfang, autoritäre Quellen, Repository-Beweise und fehlende Materialien. Lese das gesamte Ziel-PRD.
2. Extrahiere Umfang, Typ, Status, Schwellenwerte, Berechtigungen, Daten, Zeit, Prioritäten und Abnahme-Invarianten.
3. Lese finding-taxonomy.md und überprüfe separat Baseline-Regression, interne Konsistenz, Lebenszyklus, Datenhistorie, Schnittstellen-Idempotenz, Berechtigungs-Audit, Prototyp-Grenzen, NFR, Ausführbarkeit und FR/AC-Traceability.
4. Entferne Duplikate und behalte nur Probleme bei, die Beweise, Konsequenzen und Korrigierbarkeit haben. Erfinde keine Probleme, um den Eindruck von Gründlichkeit zu erwecken.
5. Lese review-report.md, gib Pass, Pass with changes, Blocked oder Limited review aus und liste die Probleme nach Schweregrad auf, zusammen mit Beweisen, Auswirkungen und minimalen Korrekturvorschlägen.

Die Prüfung ist standardmäßig schreibgeschützt. Selbst wenn offensichtliche Probleme gefunden werden, darf das PRD nicht direkt geändert werden; erst nach Autorisierung durch den Benutzer zur Überarbeitung in refine eintreten.

execute: Umwandlung in Codex-Entwicklungsausführungsdokument

Voraussetzung ist ein identifizierbares, genehmigtes PRD. Der Abschluss einer Überarbeitung oder das Bestehen einer Red-Team-Prüfung allein ist keine Genehmigung.

1. Lese readiness-audit.md, gleiche PRD-Version, Bestätigungs-Baseline, Ziel-Release-Umfang, offene Punkte, aktuelles Repository und Tests ab, und erstelle eine Lückenanalyse und Bereitschafts-Schlussfolgerung.
2. Wenn das Produktverhalten nicht eindeutig bestimmt werden kann, autoritäre Konflikte bestehen, Abnahmen nicht beobachtbar sind oder eine nicht autorisierte Abhängigkeit/Integration/Migration erforderlich ist, lautet die Schlussfolgerung BLOCKED; stoppe und verstecke das Problem nicht in technischen Annahmen.
3. Lese execution-document.md, definiere die minimalen Architekturgrenzen, Eigentumsverhältnisse, Zustände, Daten, Schnittstellen, Persistenz, Uhren, Degradierung und Schutz bestehender Systeme, die das PRD erfüllen.
4. Beginne mit der schreibgeschützten Phase 0, erstelle abhängig geordnete, unabhängig prüfbare Phasen. Schreibe für jede Phase FR/AC, Dateiumfang, Verbote, Tests, Abnahmebeweise, Qualitäts-Gates und Stop-Gates.
5. Lese traceability-and-gates.md, bilde jeden FR/AC im Umfang auf Phase, Codebereich, Test und Beweis ab, identifiziere verwaiste Anforderungen und nicht autorisierte Arbeit.
6. Lese codex-control-prompt.md und generiere einen übergeordneten Steuer-Prompt sowie phasenspezifische Prompts. Die Prompts müssen Version, autoritäre Reihenfolge, echte Tests, Schutz von Benutzeränderungen und phasenweise Autorisierung beibehalten.

Vollständigkeitskriterien: Eine andere Codex-Instanz kann mit einem schreibgeschützten Audit beginnen, nur eine genehmigte Phase ausführen, mit echten Befehlen verifizieren, Traceability-Ergebnisse melden und anhalten; das Dokument macht Annahmen, Ausgeschlossenes, Blocker, Verschobenes und geschütztes Verhalten explizit.

Phasenübergangs-Gates

• create → refine: Nur eintreten, wenn der Benutzer der Meinung ist, dass das erstellte PRD noch vervollständigt oder überarbeitet werden muss.
• create/refine → review: Muss vom Benutzer explizit als Prüfung angefordert werden; die Prüfung ändert nicht automatisch.
• review → refine: Nach expliziter Autorisierung des Benutzers zur Bearbeitung bestimmter Findings eintreten, dabei die Finding-ID und den Überarbeitungs-Mapping pro Punkt beibehalten.
• create/refine/review → execute: Explizite Angabe einer "genehmigten" PRD-Version und des Ziel-Release-Umfangs erforderlich.
• execute → implementation: Das Ausführungsdokument bietet nur einen Steuerplan; die eigentliche Implementierung muss vom Benutzer in einer nachfolgenden Aufgabe separat autorisiert werden.

Feedback-Lernen

Zu Beginn des Workflows lerne feedback-learning.md und learned-guidance.md. Feedback wird zunächst auf die aktuelle Aufgabe angewendet; eine Persistierung ist nur erlaubt, wenn der Benutzer explizit die Speicherung und Bestätigung der spezifischen Regel und ihres Geltungsbereichs anfordert. Gelernte Regeln dürfen keine aktuellen Anweisungen, Phasen-Gates, Faktenprüfung, Versionsverwaltung oder Autorisierungsgrenzen überschreiben.