163 lines
10 KiB
Markdown
163 lines
10 KiB
Markdown
# 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
|