feat(rpi): integrate Dexter Horthy's RPI framework findings without truncating files

Co-Authored-By: Craft Agent <agents-noreply@craft.do>

- Introduce 'Research Summary' as mandatory section in plan.md
- Introduce 'Outline' alignment before writing plan.md
- Ensure iterative loop (Back-and-Forth) in Clarify/Plan phases
- Add Plan Fidelity Check (F3) to review and Gate G5
- Enable 'Isolated Research' (Discover without feature-ticket bias)
- Apply Prompt-Diet via Execution Rules to enforce step-by-step processing without truncating content

Author: aheusingfeld

references/01-specify.md

@@ -2,6 +2,11 @@
 
 **Trigger:** Feature, Problem, Idee oder Prozess wird beschrieben.
 
+**Prompt Diet & Execution Rules (RPI Framework):**
+- Führe diesen Modus NIEMALS als einen einzigen großen Schritt aus.
+- Gehe strikt sequenziell vor: Lade Phase 0/1a, stoppe und frage den Nutzer. Erst nach Freigabe gehst du zu Phase 1b über (Back-and-Forth).
+- Max. 40 aktive Instruktionen pro Interaktion!
+
 ---
 
 ## Phase 0: Komplexitätseinschätzung (optional, empfohlen bei neuen Produkten)

references/02-clarify.md

@@ -5,6 +5,10 @@
 
 **Trigger:** spec.md existiert, offene Fragen oder unterspezifizierte Bereiche vorhanden.
 
+**Prompt Diet & Execution Rules (RPI Framework):**
+- **Iterativer Loop:** Research und Plan sind nicht linear. Wenn dir im Planungs- oder Klärungsprozess Systemwissen fehlt, stoppe sofort. Kehre in die Recherche zurück, lies den Code, und setze erst danach fort.
+- Arbeite in kleinen Schritten (Back-and-Forth) mit dem Nutzer. Max. 40 Instruktionen auf einmal verarbeiten!
+
 ---
 
 ## Wann Pflicht vs. Optional (profilabhängig)

references/03-plan.md

@@ -2,6 +2,11 @@
 
 **Trigger:** spec.md existiert und Clarify ist abgeschlossen (oder bewusst übersprungen).
 
+**Prompt Diet & Execution Rules (RPI Framework):**
+- **Outline First:** Bevor du die detaillierte `plan.md` schreibst, präsentiere dem Nutzer zwingend eine High-Level Outline und kläre offene Fragen (Back-and-Forth).
+- **Iterativer Loop:** Fehlt dir Kontext? Stoppe die Planung und wechsle zurück in die Code-Recherche (Modus 9). Rate niemals Code-Strukturen!
+- Max. 40 Instruktionen pro Schritt.
+
 ---
 
 ## Profil-Steuerung
@@ -58,6 +63,8 @@
 ## Phase 3a: Plan
 
 Erzeugt `plan.md` mit:
+
+**WICHTIG (RPI-Framework):** Jeder Plan MUSS zwingend mit der Sektion `## 0. Research Summary & Context` beginnen. Fasse hier objektiv zusammen, was du in der Codebasis gelesen hast, BEVOR du Implementierungsschritte vorschlägst.
 - Technische Architekturentscheidungen → ADR in `specs/decisions/`
 - **Technisches Datenmodell** (WIE — abgeleitet vom fachlichen Modell in spec.md):
   - Persistenz-Strategie (RDBMS, Document Store, Event Store)

references/07-review.md

@@ -3,6 +3,10 @@
 **Trigger:** Bestehende Requirements, Specs oder Stories als Input.
 **Methode:** 3-Ebenen-Prüfkatalog mit deterministischer Schweregrad-Zuordnung.
 
+**Prompt Diet & Execution Rules (RPI Framework):**
+- Gehe strikt Phase für Phase vor. Präsentiere Zwischenergebnisse, bevor du den kompletten Review abschließt.
+- Max. 40 Instruktionen auf einmal verarbeiten.
+
 ## Profil-Steuerung
 
 - **KRITIS:** Alle 3 Ebenen Pflicht; STRIDE vollständig (alle 6 Kategorien); GP-Score ≥ 9/10; Keine offenen BLOCKER/MAJOR erlaubt
@@ -40,6 +44,12 @@ Jede Ebene wird vollständig durchlaufen. Keine Ebene darf übersprungen werden,
 
 #### Story-Quality-Score (SQS) — numerische Qualitätsbewertung
 
+#### Ebene 1.5 — Plan Fidelity Check (Bei Code-Review)
+
+Wenn Code *nach* einem Plan (z.B. `plan.md`) implementiert wurde, vergleiche den generierten Code zwingend mit dem Plan.
+- Jede Datei/Logik, die geändert wurde, aber *nicht* im Plan stand, ist "Drift" (eigenmächtiges Handeln).
+- **Schweregrad bei Drift:** Zwingend **F3 (CONDITIONAL)**. Erfordert explizite Risiko-Akzeptanz vom Nutzer.
+
 Zusätzlich zur binären Prüfung (bestanden/nicht bestanden) erzeugt der Review einen numerischen **Story-Quality-Score (SQS)** pro Story. Der SQS misst *Formulierungsqualität*, nicht Governance-Compliance (das ist der GP-Score).
 
 | Dimension | Gewichtung | 0 Punkte | 2.5 Punkte | 5 Punkte |

references/09-discover.md

@@ -3,6 +3,11 @@
 **Methode:** Reverse Engineering + Domain Analysis.
 **Trigger:** Bestehender Code/System, Bestandsdokumentation, Reverse-Engineer-Anfrage.
 
+**Prompt Diet & Execution Rules (RPI Framework):**
+- **Isoliertes Research:** Ignoriere zu Beginn (Phase 9a-9e) jegliche Feature-Tickets oder Soll-Zustände des Nutzers. Dokumentiere den Ist-Zustand absolut wertfrei und objektiv.
+- **Delta ganz am Schluss:** Wende das Feature-Ticket erst ganz am Ende an, um den Confirmation Bias zu umgehen.
+- Gehe in kleinen Schritten vor (Back-and-Forth). Max. 40 Instruktionen pro Interaktion.
+
 ## Profil-Steuerung
 
 - **KRITIS:** Beide QS-Schleifen Pflicht (keine Ausnahme); STRIDE + KRITIS-NFRs in generierter Spec; Keine offenen BLOCKER/MAJOR nach QS-2

references/enforcement/enforcement-engine.md

@@ -150,6 +150,7 @@ Die F-Stufe eines Prüfpunkts kann je nach Perspektive variieren. In `checks_con
 ```
 ── Gate G5 ─────────────────────────────────
 [ ] Artefakt-Vollständigkeits-Check (siehe I.6)  [F4]
+[ ] Plan Fidelity Check (Diff vs plan.md)        [F3]
 [ ] Alle Tasks aus tasks.md abgeschlossen        [F4]
 [ ] Spec-First Chain Compliance geprüft          [F4]
 [ ] ARCHITECTURE.md aktuell                      [F3]