diff --git a/PLATFORM_ROADMAP.md b/PLATFORM_ROADMAP.md
index 8d67e54..87476df 100644
--- a/PLATFORM_ROADMAP.md
+++ b/PLATFORM_ROADMAP.md
@@ -100,6 +100,75 @@ Compliance wird **nicht** als nachträgliche Parallelarchitektur gebaut. Datensc
 - AI-Provider erhalten Compliance-Metadaten (Region, DPA/Vertragsstatus, Retention, Training-on-Customer-Data, Transfer-/Hosting-Hinweise, erlaubte Datenklassen). Der zentrale LLM-Client erzwingt die konfigurierte Provider-/Datenpolicy.
 - High-Risk-/regulierte Branchenplugins nutzen dieselben Plattformmechanismen, bringen aber ihre **fachspezifische** Dokumentation, Risikobewertung und zusätzliche Kontrollen selbst mit. Der Core wird nicht auf Verdacht zu einer High-Risk-Suite aufgeblasen.
 
+### Execution Principles (verbindlich für alle Phasen)
+
+Diese 10 Prinzipien sind keine Tasks sondern **Arbeitsweise-Regeln** die für alle 12 Phasen gelten. Sie kosten keine zusätzliche Zeit sondern verändern wie gearbeitet wird.
+
+1. **Spike First** — Riskante Phasen werden vorher mit einem 2-Tage-Spike validiert (siehe Spike-Tasks unten). Keine 6-Wochen-Phase ohne Proof-of-Concept.
+2. **Test-First** — Jeder Task beginnt mit failing Tests, dann Code bis grün, dann Refactor. „Es compiliert" ist nicht „fertig".
+3. **Phase-Gate-Disziplin** — Nach jeder Phase: AI-Review gegen 7 Kriterien. Bei ❌ → Bugfix-Sprint, keine neue Phase. Zeitbewusst: 2-3 Stunden Review, nicht 2 Tage.
+4. **AI-Code-Review vor Merge** — Jeder Commit wird von AI reviewed bevor er gemerged wird: Forbidden Patterns, Permission-Bypass, Tenant-Isolation, Error-Handling, Test-Abdeckung.
+5. **Task-Block-Deploy** — Pro Task-Block deployen (z.B. alle B-LLM Tasks zusammen = 1 Deploy), nicht pro Einzel-Task und nicht pro ganzer Phase. Mittelweg zwischen Micro-Deploy und 6-Wochen-Sammler.
+6. **Architektur-Reviews** — Nach Phase B, F und I: AI-Architektur-Review. Dependency-Graph, Pattern-Check, Cross-Plugin-Imports, zirkuläre Abhängigkeiten. 2-3 Stunden pro Review.
+7. **AI nach Stärken** — AI für repetitive Tasks (CRUD, Tests, Migrationen, Doku, Refactoring, Code-Review). Mensch für kritische Logik (ReAct-Loop, Workflow-Engine, Permission-Checks, Race-Conditions, Performance-Tuning, Security-Review).
+8. **Fortlaufende Integration-Tests** — Nach jeder Phase: neue Features mit vorherigen Phasen zusammen testen. Nicht erst in Phase I alles kombinieren.
+9. **Rollback-Lite** — Jeder Task hat Rollback-Plan (`git revert` + redeploy). Riskante Änderungen hinter Feature-Flag. Migrationen immer downgrade-fähig.
+10. **Ehrliche Status-Reports** — „done" = bewiesen mit Test-Output, Build-Result, Health-Check. „Glaube ich" = `in_progress`, nicht `done`. PROGRESS.md bei jedem Status-Wechsel aktualisieren.
+
+### Spike-Tasks (vor riskanten Phasen)
+
+Vor den 4 Hochrisiko-Phasen (E, F, G, I) wird je ein 2-Tage-Spike durchgeführt. Spikes sind keine Tasks die in die Phase fallen — sie laufen **vor** der Phase und validieren das Kernrisiko.
+
+| Spike | Vor Phase | Was wird validiert | Aufwand |
+|-------|----------|-------------------|--------|
+| SPIKE-E | Phase E | Minimaler FTS+Vector+Permission-Proof auf 10k Datensätzen. Funktioniert Permission-Filterung? Ist pgvector schnell genug? | 2 Tage |
+| SPIKE-F | Phase F | Minimaler ReAct-Loop mit 3 Tools, 5 Steps, Permission-Check. Funktioniert Tool-Calling? Sind Responses brauchbar? | 2 Tage |
+| SPIKE-G | Phase G | Minimaler durable WorkflowRun mit Wait+Resume+Idempotency. Überlebt er einen Worker-Restart? | 2 Tage |
+| SPIKE-I | Phase I | Agent → Search → Knowledge → Workstream → Task → Approval in einem minimalen Flow. Funktionieren die Übergänge? | 2 Tage |
+
+**Regel:** Spike scheitert → Risiko wird in der Phase adressiert oder Phase wird angepasst. Spike erfolgreich → Phase kann fokussiert umgesetzt werden.
+
+### Phase-Gate-Reviews (zeitbewusst)
+
+Nach jeder Phase führt AI ein Phase-Gate-Review durch. Dauer: 2-3 Stunden. Format: 7-Kriterien-Checkliste.
+
+| Kriterium | Was wird geprüft |
+|----------|----------------|
+| 1. Tests grün | `pytest` + `vitest` + `tsc --noEmit` alle grün |
+| 2. Build erfolgreich | `npm run build` erfolgreich |
+| 3. Health 200 | Deployed → `curl /api/v1/health` → 200 |
+| 4. Cross-Tenant safe | `test_cross_tenant_security.py` grün |
+| 5. E2E pass | Kritische Playwright-Flows grün |
+| 6. Docs aktualisiert | Betroffene `docs/` Dateien aktualisiert |
+| 7. PROGRESS.md aktuell | Alle Task-Status eingetragen und verifiziert |
+
+**Regel:** Bei ❌ bei einem Kriterium → Bugfix-Sprint bis ✅, keine neue Phase starten.
+
+### Architektur-Reviews (nach B, F, I)
+
+Nach den 3 wichtigsten Fundament-Phasen führt AI ein Architektur-Review durch. Dauer: 2-3 Stunden.
+
+| Review | Nach Phase | Was wird geprüft |
+|--------|-----------|----------------|
+| ARCH-B | Phase B | LLM/Redis/Storage/WS/Error/Observability/Shutdown — funktioniert das Zusammenspiel? Gibt es zirkuläre Abhängigkeiten? |
+| ARCH-F | Phase F | Agent+Tasks+Permissions+Approval+Workstream — gibt es Permission-Lücken? Ist das Task-Modell konsistent? |
+| ARCH-I | Phase I | Alle Systeme verbunden — Search↔Agent↔Workflow↔Knowledge↔Workstream↔Tasks↔Approval — gibt es zirkuläre Abhängigkeiten oder inkonsistente Patterns? |
+
+### Integration-Tests (fortlaufend)
+
+Nach jeder Phase werden die neuen Features mit den vorherigen Phasen zusammen getestet. Nicht erst in Phase I alles kombinieren.
+
+| Nach Phase | Was wird zusammen getestet |
+|-----------|--------------------------|
+| B | LLM-Client + Error-Handling + Observability + Shutdown |
+| C | Frontend Error Boundaries + B-Systeme |
+| D | Undo/Restore + Hooks + Outbox + B-Systeme |
+| E | Search + Permission + Outbox + LLM + B-Systeme |
+| F | Agent + Tasks + Permissions + Approval + Workstream + B+E-Systeme |
+| G | Workflow + Agent + Approval + Workstream + B+E+F-Systeme |
+| H | Knowledge + Search + RAG + Graph + B+E+F+G-Systeme |
+| I | Alle Systeme — vollständiger Integration-Test |
+
 ### Migration-Staffelung
 
 Nicht: neu → migrieren → alt sofort löschen.