# Execution Order — Phasen + Dependencies **Pflicht-Lektüre vor jedem neuen Task.** Wenn du einen Task aus einer späteren Phase machst während frühere Phasen noch laufen, riskierst du Dependency-Fehler. ## Phase-Reihenfolge (Top-Down — alles oben muss großteils stehen bevor untenstehende starten) ``` Phase 01 (Tech-Debt-Foundation) ──┐ │ Phase 02 (Observability) ─────────┤ │ Phase 03 (Skalierungs-Infra) ─────┤ │ ┌─────────────────┴─────────────────┐ ▼ ▼ Phase 04 (Search/RAG) Phase 09 (Authentik+Admin-SSO) │ │ ▼ │ Phase 07 (Chatbot V2) │ │ │ Phase 05 (Business-Features) ◄──────────────┘ │ Phase 06 (Plugin-System) │ Phase 08 (Mobile/CLI/Storybook/SDK) │ Phase 10 (Compliance + Polish) │ Phase 11 (Backlog — falls aktiviert) ``` ## Detaillierte Phasen-Dependencies ### Phase 01 — Tech-Debt-Foundation **Depends on:** keine (kann sofort starten) **Blockt:** alle nachfolgenden Phasen **Begründung:** Dep-Updates + Konsolidierungen müssen vor allem anderen — sonst baust du auf veralteten Foundations. ### Phase 02 — Observability **Depends on:** Phase 01 (Dep-Updates für saubere Sentry/OTel-Versionen) **Blockt:** Phase 03+ (du willst Metrics während du Skalierung baust) **Begründung:** Wenn du Skalierungs-Refactoring machst, brauchst du Observability um zu sehen ob es klappt. ### Phase 03 — Skalierungs-Infrastruktur **Depends on:** Phase 01, 02 **Blockt:** Phase 04 (Search braucht Outbox für async-Indexing), Phase 05 (Feature-Flags brauchen SharedStore-Cache) **Sub-Dependencies innerhalb:** - `shared-store.md` zuerst — alle anderen state-related items hängen dran - `pgbouncer.md` vor `read-write-split.md` - `outbox-pattern.md` ist Voraussetzung für Pub/Sub-Cache-Invalidation und Worker-Async-Indexing - `backup-cli.md` + `tenant-snapshot.md` parallel zu Rest möglich ### Phase 04 — Search + RAG **Depends on:** Phase 03 (insbesondere Outbox + Worker-Queues) **Blockt:** Phase 07 (Chatbot V2 braucht RAG-Pipeline) **Sub-Dependencies:** - `meilisearch.md` und `vector-store.md` parallel möglich - `embedding-pipeline.md` braucht beide ### Phase 05 — Business-Features **Depends on:** Phase 03, 04 (Feature-Flags brauchen SharedStore; AI-Cost brauchen Outbox; Marketing-Funnel braucht React-Email aus Phase 10 für Email-Sequences-Templates — sofern parallel arbeitbar) **Blockt:** Phase 06 (Plugin-System nutzt Feature-Flags für Capability-Gating) **Sub-Dependencies:** - `feature-flags.md` zuerst — wird von vielen anderen Features genutzt - `ai-cost-phase-1.md` → `ai-cost-phase-2.md` → `ai-cost-phase-3.md` sequenziell - `form-widget.md` unabhängig - `realtime-collab.md` unabhängig - `marketing-funnel-phase-1.md` → `marketing-funnel-phase-2.md` → `marketing-funnel-phase-3.md` sequenziell; Phase 3 braucht React-Email (kann aus Phase 10 vorgezogen werden) ### Phase 06 — Plugin-System **Depends on:** Phase 03, 05 (Feature-Flags für Plugin-Capability-Toggles, Outbox für Plugin-Events) **Blockt:** nichts kritisches; Phase 08 CLI-Scaffolding kann Plugin-Templates referenzieren **Sub-Dependencies:** - `wasm-sandbox.md` zuerst - `hooks-lifecycle.md` braucht Sandbox - `audit-docs.md` braucht beide ### Phase 07 — Chatbot **Depends on:** - `chatbot-mvp.md`: Phase 05 Feature-Flags - `chatbot-v1.md`: AI-Cost-Phase-2 (Quota-Enforcement aus #55) - `chatbot-v2.md`: Phase 04 komplett (RAG) + AI-Cost-Phase-3 (#56) **Blockt:** Phase 06 nicht direkt, aber Plugin-System kann Chatbot-Tools registrieren ### Phase 08 — Mobile/CLI/Storybook/SDK **Depends on:** Phase 01 (Deps), 02 (Sentry Web-Wiring), 05 (Feature-Flags für CLI-feature-checks) **Blockt:** nichts kritisches **Sub-Dependencies:** - `storybook.md` parallel möglich - `cli-scaffolding.md` parallel möglich - `cli-ops.md` braucht `backup-cli.md` aus Phase 03 - `ts-sdk.md` parallel möglich - `capacitor.md` braucht Push-Notification-Backend (Web-Push erstmal als Vorstufe in `apps/worker`) ### Phase 09 — Authentik + Admin-SSO **Depends on:** Phase 02 (Sentry für Authentik-Container) **Blockt:** Phase 11 Backlog-Customer-SSO (#66) als foundation **Sub-Dependencies:** - `authentik-setup.md` zuerst - `admin-oidc-login.md` zweiter ### Phase 10 — Compliance + Polish **Depends on:** alle vorherigen Phasen — Compliance kommt zum Schluss **Blockt:** nichts (letzte Phase vor Backlog) **Sub-Dependencies:** - `react-email.md` kann früher gezogen werden falls Phase 05 Marketing-Funnel-Phase-3 sie braucht - `lighthouse.md`, `bundle-budget.md`, `i18n-foundation.md`, `wcag-internal.md`, `test-coverage.md` parallel möglich - `dsgvo-bulk-ops.md` braucht `audit-compliance-export.md` (gleiches Modell-Schema-Update) ### Phase 11 — Backlog **Nur ausführen wenn explizit vom Operator freigegeben.** Sonst sind die Items dort dauerhaft im Wartezimmer. ## Reihenfolgen-Tabelle (linear-lesbar) | Reihenfolge | Phase | Task-Files in Reihenfolge | Parallel möglich? | | ----------- | ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------- | | 1 | 01 | dead-code.md, dep-updates.md, totp-consolidation.md, password-policy.md, supabase-removal.md, av-scanner-layer-1.md, av-scanner-layer-2.md, magic-link-reset.md, magic-link-invitation.md | dead-code parallel zu dep-updates; rest sequenziell | | 2 | 02 | sentry-selfhost-setup.md, sentry-wiring-api-worker.md, sentry-wiring-web.md, sentry-ci-integration.md, opentelemetry.md, logging-migration.md, metrics-grafana.md, performance-quickwins.md | sentry-wiring api/worker parallel zu web; metrics + performance-quickwins parallel | | 3 | 03 | shared-store-package.md, shared-store-migration.md, pubsub-cache-invalidation.md, pgbouncer.md, read-write-split.md, outbox-pattern.md, worker-queues.md, streaming-exports.md, job-priority.md, backup-cli.md, tenant-snapshot.md, asset-cdn.md | viele Parallels möglich, siehe Phase-README | | 4 | 04 | meilisearch.md, vector-store.md, embedding-pipeline.md | meilisearch + vector-store parallel | | 5 | 05 | feature-flags.md, ai-cost-phase-1.md, ai-cost-phase-2.md, ai-cost-phase-3.md, form-widget.md, realtime-collab.md, marketing-funnel-phase-1.md, marketing-funnel-phase-2.md, marketing-funnel-phase-3.md | feature-flags zuerst, dann diverse parallel | | 6 | 09 | authentik-setup.md, admin-oidc-login.md | sequenziell | | 7 | 06 | wasm-sandbox.md, hooks-lifecycle.md, audit-docs.md | sequenziell | | 8 | 07 | chatbot-mvp.md, chatbot-v1.md, chatbot-v2.md | sequenziell | | 9 | 08 | storybook.md, ts-sdk.md, cli-scaffolding.md, cli-ops.md, capacitor.md | viele parallel | | 10 | 10 | react-email.md (ggf. vorgezogen), compliance-audit-export.md, dsgvo-bulk-ops.md, security-docs.md, lighthouse.md, bundle-budget.md, i18n-foundation.md, wcag-internal.md, test-coverage.md | viele parallel | | 11 | 11 | Nur on-demand vom Operator | – | ## Wie der Agent das nutzt Jede Detail-MD hat `## Depends on`-Section. Vor Start: 1. Lies dort die Liste 2. Check ob alle gelisteten Tasks in PROGRESS.md `completed` 3. Wenn ja → start 4. Wenn nein → wähle einen anderen Task aus der gleichen Phase oder einer früheren Wenn alle Tasks der aktuellen Phase im Wartemodus blockiert sind: 1. Eskaliere via `BLOCKERS.md` 2. Wähle Tasks aus der nächsten Phase die nicht von blockierten Tasks abhängen 3. Niemals idle bleiben