HiveGrid-Wireframes/hivegrid-cloud/docs/improvement-plan/00-execution-order.md

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