Dauer: 2-4 Wochen Tasks: 9 Ziel: Quick-Wins abräumen, veraltete/duplizierte Codepfade konsolidieren, Supabase entfernen, Auth-Härtung (TOTP, Password-Policy, Magic-Link), AV-Scanner als Datei-Upload-Schutz. Saubere Foundation für alle nachfolgenden Phasen.

Warum diese Phase zuerst

Dep-Updates (Task #28) ziehen Breaking-Changes in Stripe-API, marked-Renderer und Hashing-Verfahren mit. Wenn Phase 02 (Observability) auf veralteten Stripe-SDK / moment-Modulen aufsetzt, müssen Sentry-Wirings doppelt angepasst werden.
Konsolidierungen (TOTP, Password-Policy) müssen vor Phase 02-Wiring liegen, damit die Sentry-Breadcrumbs nur die "richtigen" Pfade markieren.
Supabase-Removal (Task #18) entfernt eine ganze Adapter-Schicht aus packages/storage — wenn Phase 03 (Skalierung / Asset-CDN) startet, soll dort nur noch S3 als Upload-Backend existieren.
AV-Scanner (Tasks #16/#17) ist Voraussetzung dafür, dass spätere User-Generated-Content-Features (Form-Widget, Chatbot-Uploads) sicher live gehen können.

Task-Reihenfolge

Reihenfolge	Task-ID	Datei	Parallelisierbar mit
1	#25	`dead-code.md`	#28 (independent files)
2	#28	`dep-updates.md`	#25
3	#26	`totp-consolidation.md`	#27 (independent)
4	#27	`password-policy.md`	#26
5	#18	`supabase-removal.md`	— (touches storage-package wide)
6	#16	`av-scanner-layer-1.md`	— (depends on #18 for storage layout)
7	#17	`av-scanner-layer-2.md`	— (depends on #16)
8	#19	`magic-link-reset.md`	#20 (independent files)
9	#20	`magic-link-invitation.md`	#19

Dependency-Graph (intern)

#25 dead-code ─┐
                ├─► #26 totp ──► #27 password ──► #18 supabase ──► #16 av-layer1 ──► #17 av-layer2 ──► #19 magic-reset ─┐
#28 dep-update ┘                                                                                                       ├─► Phase 02
                                                                                                       #20 magic-invite ┘

#25 und #28 haben keine internen Abhängigkeiten — können von zwei Subagents parallel gefahren werden.

#26 und #27 touchen unterschiedliche Dateien (otpauth vs password-policy.server.ts) — parallel möglich, aber beide müssen #28 (bcrypt → argon2) abgewartet haben, weil Password-Policy gegen den neuen Hash-Pfad geschrieben wird.

#16 baut die Schnittstelle ScanAdapter in packages/storage/src/scan/ auf, #17 registriert den ClamAVScanAdapter an derselben Schnittstelle — #17 ist hart abhängig von #16.

#19 und #20 teilen sich magic-link.server.ts — parallel möglich, aber zweiter Merge muss Rebase machen.

Phase Done-Definition

Diese Phase ist completed wenn:

Alle 9 Tasks completed in PROGRESS.md
pnpm lint, pnpm typecheck, pnpm test global grün
Lokales .env.example enthält keine Supabase-/orphan-Keys mehr, neue Keys (AUTH_PASSWORD_*, CLAMAV_HOST, etc.) dokumentiert
Staging-Deployment auf agent/phase-01-final deployed und Smoke-Tests durchlaufen (Registration, MFA-Enrollment, Magic-Link-Login, Datei-Upload mit Bad-Magic-Bytes)
Performance-Regression-Check: Build-Größe + Cold-Start nicht schlechter als pre-Phase-01-Baseline
gsd-code-reviewer-Subagent hat alle 9 Tasks-Commits reviewed; Findings adressiert
Phase-Summary in dieser README.md ergänzt (siehe unten)

Phase Summary

(Wird nach Abschluss der Phase vom ausführenden Agent ergänzt.)

Lessons Learned

(Wird nach Abschluss ergänzt.)

Verweise

Detail-MD-Template: ../DETAIL-MD-TEMPLATE.md
Agent-Workflow: ../AGENT-INSTRUCTIONS.md
Execution-Order: ../00-execution-order.md
Live-Status: ../PROGRESS.md