Status: dauerhaft im Wartezimmer, nur on-demand vom Operator aktivierbar Tasks: 7 dokumentierte Items Ziel: Features dokumentieren, die bewusst nicht jetzt umgesetzt werden, aber so vorbereitet sind, dass ein späterer Agent sie ohne erneute Architektur-Diskussion starten kann, sobald die jeweilige Trigger-Condition eintritt.

Warum es diese Phase überhaupt gibt

Ein paar Features wurden in der ursprünglichen Boilerplate-Analyse als „eigentlich sinnvoll, aber heute zu früh" eingestuft:

Sie skalieren erst ab einem bestimmten Markt-/Kunden-Reifegrad sinnvoll (z.B. Plugin-Marketplace ohne Product-Market-Fit verbrennt nur Entwicklungszeit).
Sie sind politisch/strategisch abhängig (z.B. Multi-Region nur wenn die EU-only-Annahme bricht).
Sie haben hohe Maintenance-Kosten (z.B. WCAG-Zertifizierung muss jährlich reauditiert werden).
Sie sind komplette Sales-/Compliance-Driver, deren Aufwand nicht ohne konkreten Enterprise-Deal gerechtfertigt ist (z.B. Customer-Tenant-SSO).

Damit der „spätere Agent" nicht bei Null anfängt, dokumentiert jede Backlog-Datei:

Trigger Condition — was muss passieren, bevor das Item aus dem Backlog kommt
Approach — der gewählte technische Weg inkl. Begründung gegen Alternativen
Implementation Steps — knapp, aber konkret (nicht so granular wie aktive Tasks)
Test Requirements + Acceptance Criteria — kürzer, aber existent
Depends on — realistische Vorbedingungen aus früheren Phasen

Aktivierungs-Regel

Ein Backlog-Item wechselt von backlog: <trigger> auf pending nur wenn:

Der Operator explizit das Item zur Aktivierung freigibt (PR / Issue / direkte Anweisung)
Die im Item dokumentierte Trigger-Condition nachweisbar eingetreten ist
Alle Depends on-Tasks aus früheren Phasen sind completed

Der ausführende Agent darf nicht eigenmächtig Backlog-Items ziehen, auch wenn die aktive Roadmap leer ist. Stattdessen: BLOCKERS.md aktualisieren und Operator informieren.

Übersicht der Backlog-Items

Task-ID	Datei	Trigger Condition	Aufwand (wenn aktiviert)	Depends on
#24	`plugin-marketplace.md`	Plugin-System (Phase 06) fertig + Product-Market-Fit + Bedarf nach Drittentwickler-Ökosystem	6-8 Wochen	Phase 06 vollständig, Phase 05 (Feature-Flags + AI-Cost)
#52	`multi-region.md`	EU-only-Markt-Annahme bricht (z.B. US-Customer relevant)	4-5 Wochen + laufende Mehrkosten	Phase 03 (PgBouncer + Read-Write-Split + Outbox)
#57	`stripe-marketplace-ui.md`	B2B2C-Marketplace-Modell aktiviert (Portal-Owner verkaufen via Plattform an Endkunden)	3-4 Wochen	Phase 05 (Feature-Flags), bestehendes Stripe-Subscription-Setup
#64	`python-sdk.md`	Data-Engineering-Use-Cases oder Python-Backend-Integrations für Tenants werden spürbar	1 Woche	Phase 08 (`ts-sdk.md` — gleiche OpenAPI-Spec)
#66	`customer-tenant-sso.md`	Enterprise-Verkauf ab Deal-Größe ~$50k/Jahr oder Compliance-Anforderungen	2-3 Wochen	Phase 09 (Authentik + Admin-SSO) — Federation auf gleicher Authentik-Instanz
#74	`wcag-external-cert.md`	Enterprise-Sales-Pipeline besteht auf zertifizierter Accessibility-Compliance	3-4 Wochen + €5-15k externer Audit	Phase 10 (`wcag-internal.md`) muss durch sein
#77	`stryker.md`	Coverage-Pflicht (`test-coverage.md`) fertig + Bedarf nach höherer Test-Quality (z.B. nach Critical-Bug-Production-Incident)	1 Woche Setup + Tuning + Initial-Fix-Sprint	Phase 10 (`test-coverage.md`)

Wann ein Backlog-Item geprüft werden sollte

Quarterly: Operator + Agent gehen die Liste gemeinsam durch und prüfen, ob ein Trigger eingetreten ist.
Bei jedem Enterprise-Deal-Pipeline-Update: customer-tenant-sso.md + wcag-external-cert.md neu bewerten.
Bei jedem Plugin-System-Milestone (Phase 06): plugin-marketplace.md neu bewerten.
Bei Production-Incidents: stryker.md + ggf. weitere reaktiv prüfen.

Verweise

Detail-MD-Template: ../DETAIL-MD-TEMPLATE.md
Agent-Workflow: ../AGENT-INSTRUCTIONS.md (insb. Regel 7 zu Dependencies)
Execution-Order: ../00-execution-order.md
Live-Status: ../PROGRESS.md
Vorgänger-Phasen, die Backlog-Items entblocken: ../06-plugin-system/README.md, ../09-authentik-admin-sso/README.md, ../10-compliance-polish/README.md