Pflicht-Checkliste: P0-Freeze → LIVE

Vor jedem „LIVE"-Stempel werden ALLE relevanten Punkte abgehakt. Wenn ein MUSS rot ist, ist das Feature nicht live, Punkt.

Phase 1 — P0-Freeze (vor der ersten Zeile Code)

Eine versionierte Spec in prilog_docs/umsetzung/<thema>/ mit:

• [ ] MUSS P0-Ziel in einem Satz formuliert („Was kann der User nach diesem Sprint?")
• [ ] MUSS Explizit ausgeschlossen aus P0 (was kommt nicht rein — sonst wird P0 unendlich)
• [ ] MUSS Datenmodell-Skizze (Entitäten, FKs, Indizes, Unique-Constraints)
• [ ] MUSS Rollen-Modell + Capability-Flags pro Rolle
• [ ] MUSS Sicht-Resolver pro Resource (wer sieht/schreibt was unter welchen Bedingungen)
• [ ] MUSS Workflow-State-Machine wenn Status sich ändert (Diagramm oder Tabelle)
• [ ] MUSS Datenschutz-Klassifikation (was sind die personenbezogenen Felder, welche Audience)
• [ ] MUSS Aufbewahrungsfristen + Löschpfad (RPO/RTO + Retention-Worker)
• [ ] MUSS Bestehende Entitäten wiederverwenden statt parallel anlegen (z. B. Subject, Person, Space, GradeBand sind tenant-shared)
• [ ] SOLL Risiken-Tabelle (Eintrittswahrscheinlichkeit × Schweregrad × Maßnahme)
• [ ] SOLL Mock-UI / Wireframe für die drei wichtigsten Klick-Pfade
• [ ] KANN Quick-Win-Variante: was wäre P0-minus, wenn wir 70 % der Zeit hätten?

Versionierung: jede iterative Änderung bekommt neuen File-Suffix (z. B. _v4, _v5, …), die letzte vollständige Version trägt den Namen ohne Suffix oder ist über 13-status.md verlinkt.

Phase 2 — DSGVO/Compliance (vor Implementierung der ersten Endpoint)

• [ ] MUSS Eintrag im ComplianceGate-Modul (DSB-Konsole) angelegt
• [ ] MUSS Anlage einer DSFA-Vorlage in prilog_docs/umsetzung/datenschutz/ (Schule unterzeichnet später)
• [ ] MUSS Klassifikation der Daten: technisch / pädagogisch / besonders schutzwürdig (Art. 9)
• [ ] MUSS Pseudonymisierungs-Strategie im Audit-Log
• [ ] MUSS Break-Glass-Pfad spezifiziert (Pflicht-Begründung ≥ 20 Zeichen, max. 24h, voll auditiert)
• [ ] SOLL Schul-DSB hat die Spec vorab gelesen (für externe Schulen) oder internal Review

Phase 3 — Backend-Implementierung

• [ ] MUSS Prisma-Migration in prisma/migrations/0NNN_<thema>/ (Reihenfolge!), inkl. Backfill für bestehende Daten
• [ ] MUSS Migration auf lokaler Test-DB und mind. einem Tenant probeweise gespielt — Rollback geprüft
• [ ] MUSS Tabellen-Namen referenzieren korrekt (tenants, nicht Tenant — siehe Lessons)
• [ ] MUSS Zod-Validator für jeden Endpoint-Body
• [ ] MUSS Tenant-Isolation: jedes findFirst/findMany filtert auf tenantId
• [ ] MUSS Capability-Check vor jedem schreibenden Endpoint (requireWorkspaceAdmin etc.)
• [ ] MUSS Audit-Log-Eintrag für jeden schreibenden Endpoint
• [ ] MUSS Sicht-Resolver-Helper in assert-visibility.ts (oder vergleichbar) als Pre-Handler
• [ ] MUSS 404 / 403 mit strukturierter Diagnose statt nur {error:'not_found'} (Reasons + Remedies)
• [ ] SOLL Indizes für alle Hot-Path-Queries (@@index([tenantId, ...]))
• [ ] SOLL Aggregat-Audit für Bulk-Operationen (z. B. report.bulk_import)
• [ ] KANN OpenAPI-Schema generiert (siehe 03-industrie-standards.md)

Phase 4 — Tests

• [ ] MUSS Vitest-Tests für jeden Service (mind. happy path + 2-3 error cases)
• [ ] MUSS Sicht-Resolver-Tests (mind. 10-15 Cases: Rolle, Capability, Status, Break-Glass)
• [ ] MUSS TypeScript-Check npx tsc --noEmit -p tsconfig.json clean
• [ ] MUSS Real-DB-Probe: npx tsx scripts/... gegen Live-Tenant prüft ob die Datensätze existieren, die der Workflow erwartet (Stundenplan, Bausteine, Klassen, …)
• [ ] SOLL Mind. ein E2E-Test (Playwright) für den Hauptpfad (sobald Playwright eingerichtet, siehe Backlog)
• [ ] SOLL Performance-Audit für Hot-Path-Queries (EXPLAIN ANALYZE bei verdächtigen findMany)
• [ ] KANN Snapshot-Tests für PDF-Layouts, Export-CSVs

Phase 5 — Frontend-Implementierung

• [ ] MUSS TanStack Query + ReactiveBridge für jede Datenabfrage (kein manuelles useState+useEffect+fetch)
• [ ] MUSS Native fetch, kein Axios
• [ ] MUSS URL-Konvention ${env.platformBaseUrl}/platform/v1/... (nicht /api/platform/... — wäre /api/api/...)
• [ ] MUSS Slide-Over statt Modal (außer System-confirms via window.confirm)
• [ ] MUSS Klarnamen statt IDs (kein id.slice(0, 16)… außer als font-mono Fallback bei fehlendem DisplayName)
• [ ] MUSS Bei stillen Fehler-Zuständen: Diagnose-Banner mit Ursache + nächstem Schritt
• [ ] MUSS Loading-State sichtbar (auch wenn nur 200ms), Error-State sichtbar, Empty-State sichtbar
• [ ] MUSS Keine catch-Blöcke ohne sichtbare Fehlermeldung
• [ ] MUSS i18n-Strings (DE primary, weitere ohne Lücken)
• [ ] SOLL Optimistic Updates bei häufigen Aktionen (Toggle, Status-Change)
• [ ] SOLL Auto-Save mit visuellem Status („Speichere…", „Gespeichert.", „Konflikt.")
• [ ] SOLL Hover-Tooltips für Icons + abgekürzte IDs

Phase 6 — UX-Audit (Real-Test mit echtem User)

Das war der entscheidende Punkt, der bei Zeugnis-Sprint 5/6 gefehlt hat.

• [ ] MUSS Einmal per Hand durchgeklickt als Fachlehrer:in (oder analog: minor / staff)
• [ ] MUSS Einmal per Hand durchgeklickt als Klassenleitung (oder analog: Coordinator / Approver)
• [ ] MUSS Einmal per Hand durchgeklickt als Schulleitung / Admin
• [ ] MUSS Einmal per Hand durchgeklickt als Eltern / Schüler:in (falls diese die Domain sehen)
• [ ] MUSS Daten-Realitäts-Probe auf einem Live-Tenant: existieren alle Voraussetzungen?
  • Klassen-Spaces da
  • Stundenplan veröffentlicht (oder manuelle Zuordnung möglich)
  • Bausteine / Stammdaten gepflegt
  • Capability-Flags an den Rollen
  • Designvorlagen aktiviert
• [ ] MUSS Setup-Status-Check oder vergleichbarer Healthcheck — zeigt grün/rot pro Pflicht-Voraussetzung
• [ ] SOLL Eine echte Schul-Person als „Beta-User" hat den Pfad einmal selbst gegangen und Feedback gegeben

Phase 7 — Deployment

• [ ] MUSS Backend-Commit + Push (crm-foundation für laufende Feature-Arbeit, main für Release)
• [ ] MUSS npx prisma migrate deploy auf api.prilog.chat
• [ ] MUSS npx prisma generate nach Migration (sonst undefined-Errors)
• [ ] MUSS pm2 restart backend-api + Log-Check für Startup-Fehler
• [ ] MUSS Web-Client: Build → Tarball → prilog-artifacts-Repo → promote-web-client.sh <sha> → reconcile-tenant.ts --all
• [ ] MUSS Health-Check der wichtigsten Endpoints (curl 200 nach Deploy)
• [ ] MUSS Bei Schema-Änderungen: Smoke-Test auf mindestens einem Real-Tenant
• [ ] SOLL Rollback-Plan: bei welcher Migration / welchem Commit drehe ich zurück, wenn's hakt
• [ ] KANN Canary auf einem Test-Tenant zuerst (siehe 04-fortgeschritten.md)

Phase 8 — Doku + Memory

• [ ] MUSS Sprint-Recap als prilog_docs/umsetzung/<thema>/NN-sprintN-...-live.md
• [ ] MUSS 13-status.md (oder analog) aktualisiert
• [ ] MUSS Memory-Eintrag in ~/.claude/projects/-home-lee/memory/ (User + KI haben gleiches Bild beim Wiedereinstieg)
• [ ] MUSS Offen-Backlog-Punkte explizit notiert (was wurde bewusst ausgeklammert?)
• [ ] SOLL Falls neue Onboarding-Erkenntnis: in Handbuch (docs/handbuch/...) ergänzen

Phase 9 — LIVE-Stempel

Erst jetzt darf der Sprint im Status-Doc als „LIVE" markiert werden. Der Stempel bedeutet:

1. Alle Phasen 1–8 grün
2. Mindestens 1× per Hand pro betroffene Rolle durchgeklickt
3. Daten-Realitäts-Probe gegen Live-Tenant erfolgreich
4. Backlog-Punkte (das was wir bewusst ausgelassen haben) sind sichtbar dokumentiert

Wenn nach LIVE eine echte Schul-Person den Pfad nicht gehen kann, war der Stempel zu früh → das ist ein Verstoß gegen dieses Manifest, kein „Software-Bug". Nachbearbeitung dokumentieren in 02-lessons-aus-prilog.md.