[Fluory]

Warum

Fixes #111 · Lücke aus dem Add-on-Audit #65 (Betriebs-Checkliste #13: Incident-Prozess, „72h-Meldepflicht (DSGVO Art. 33) als fester Schritt“; Datenschutz-Checkliste #11). Freigabe zum Start: Orchestrator in der Session vom 2026-10-15.

Arbeitsstand

• Ziel: Ein Incident-Ablauf, mit dem jemand ohne Vorwissen einen Vorfall eindämmt, die DSGVO-Frage stellt und sauber abschließt.
• Nicht-Ziele: echter AVV/Meldevertrag mit einem Kunden (laut Issue); Benennung der Aufsichtsbehörde (Orchestrator/Kunde).
• Erledigt: Abschnitt „Incident“ in operations.md (7 Schritte, DSGVO-Frage, Schaltertabelle, Tabletop); Verweis im Release-Skill und im Vercel-Runbook §9.
• Offen: Aufsichtsbehörde + Kontaktweg eintragen (Platzhalter klar markiert) – Orchestrator.
• Annahmen: keine.
• Nächster kleinster Schritt: Review und Merge durch den Orchestrator.

Was ist passiert (Klartext)

Bisher stand nirgends, was zu tun ist, wenn etwas ernsthaft schiefgeht – etwa ein Passwort öffentlich wird oder eine Firma Daten einer anderen sieht. Jetzt gibt es eine feste Reihenfolge: prüfen, Schaden einschätzen, mit dem kleinsten passenden Schalter stoppen, Issue anlegen, sauber reparieren (mit Test, ohne Abkürzung über main), erst dann wieder freischalten. Ein Pflichtschritt fragt immer: Sind personenbezogene Daten betroffen? Wenn ja, läuft die 72-Stunden-Frist der DSGVO – und beim Kunden muss der Kunde sofort informiert werden, weil er die Meldung macht. Für jede Lage steht der konkrete Schalter dieses Systems in einer Tabelle. Einmal durchgespielt mit einem erfundenen Vorfall (KI-Token in einem Kommentar geleakt).

Plan-Pflicht (SYSTEM.md §4)

• Kein Auslöser – nur Doku; keine Modulgrenze, API, Migration, Auth-Änderung, kein neuer Infrapfad, umkehrbar
• Auslöser zutreffend – Impact Manifest ausgefüllt (Plan vor Code)

Geändert

• docs/technical/operations.md: neuer Abschnitt „Incident“ vor „Frequent failures“ – Schritte 1–7 (kein Auto-Merge, kein Direkt-Push während eines Incidents; Postmortem nur bei relevantem Vorfall, Kriterien genannt), DSGVO-Frage (Art. 33 (1), (2), (5), Art. 34; Kunde = Verantwortlicher, Betreiber = Auftragsverarbeiter), Platzhalter Aufsichtsbehörde, Schaltertabelle, Tabletop-Protokoll
• docs/technical/deployment-vercel.md §9: verweist zuerst auf den Incident-Ablauf
• .claude/skills/release/SKILL.md: Prüfpunkt „Incident-Ablauf und Notschalter bekannt“

Nachweis (SYSTEM.md §11)

• Tabletop 2026-10-15 (synthetisch, „AI token leaked in a public issue comment“) – im Dokument protokolliert: Validieren → Schaden (Token erlaubt nur /v1/extract + Kontingent, kein DB-/Storage-Zugriff, D8) → personenbezogene Daten: nein, Begründung festgehalten → Eindämmen: AI_SERVICE_TOKEN in beiden Projekten rotieren, beide redeployen, requestflow-ai Ready, eine synthetische Anfrage erreicht „Zur Prüfung“ (Health beweist die Rotation nicht), zwischenzeitlich auf ERROR gelaufene Anfragen neu verarbeiten → Issue → kein Code-Fix → kein Postmortem. Lücken: Behörden-Platzhalter; die Token-Zeile behauptete zuerst Wiederholungen (korrigiert).
• Jede Schalter-Aussage gegen Code/Doku geprüft: 401 bei falschem Token, nicht wiederholt (services/ai/.../app.py, src/features/extraction/ai-client.ts, src/features/jobs/drain.ts), /v1/extract, Health-Werte (docs/technical/api.md), Button „Deaktivieren“ beendet alle Sitzungen, nicht für sich selbst/letzten Admin (src/app/users, src/features/identity), Statuslabels „Neu“/„Freigegeben“/„Zur Prüfung“, Drain-Route ohne CRON_SECRET → 404.
• Eine erste Fassung empfahl, ERP_BASE_URL zu entfernen – das fällt aber auf die lokale Mock-Adresse zurück (src/config/env.ts). Ersetzt durch „Hintergrundverarbeitung stoppen“.
• scripts/doku-check.sh: grün (0 WARN); scripts/pr-check.sh lokal gegen diese Beschreibung: grün
• Frischer Review (unabhängiger Subagent): 1 blockierend (401 wird nicht wiederholt) + 4 Nits – behoben in 01f4b3f (ein Nit bewusst belassen, Regel 11); Details im PR-Kommentar
• verify: grün – CI check Run 38705646901 am PR-Kopf 01f4b3f (nur Doku/Skill: Doku- und PR-Guard; kein Code geändert)

Doku-Entscheidung (genau eine)

• Keine langlebige Doku betroffen – Begründung: –
• Doku betroffen und im selben PR aktualisiert:
  • Produktdoku: –
  • Technische Doku: operations.md (Incident), deployment-vercel.md §9
  • Architekturkarte: –
  • ADR: –
  • CHANGELOG [Unreleased]: kein Produktverhalten geändert

Entferntes oder Umbenanntes: nichts

Dateigrößen und neue Bausteine (SYSTEM.md §7)

Dateien über 500 Zeilen im Diff (Ausnahmen: generierter Code, Lockfiles, Fixtures, Migrationen, Schemas, Ressourcen, Doku, Konfiguration):

• keine
• bewusst belassen – Begründung: –
• im selben PR nach fachlicher Verantwortung geteilt
• Folge-Issue –

Über 800 Zeilen mit neuer Fachlogik oder über 1000 Zeilen (P1/P2): nicht betroffen

Neue Shared-Komponente, Utility-Datei, Adapter oder fachlicher Service:

• nein
• ja – gesucht nach: –

Subagent-Einsätze

• 1 Review-Subagent (nur lesend, frischer Kontext): Abgleich jeder Schalter-Aussage mit dem Code; Ergebnis im PR-Kommentar

Risiken / offene Punkte

• security-Issue: Der Ablauf bestimmt, wie ein Datenschutzvorfall behandelt wird – bitte fachlich (DSGVO-Teil) durch den Orchestrator prüfen. Keine Rechtsberatung; der Platzhalter muss vor dem ersten Kundensystem gefüllt sein.
• Der Release-Skill ist deutsch; die neue Zeile folgt der Sprache der Datei (Regel 11: Übersetzung erst bei substanzieller Änderung).

🤖 Generated with Claude Code

https://claude.ai/code/session_0117LRiQKt8ycJEHW7vxLWG3

[vercel]

Deployment failed for project requestflow with the following error:

Resource is limited - try again in 24 hours (more than 100, code: "api-deployments-free-per-day").

Learn More: https://vercel.com/doc-edit?upgradeToPro=build-rate-limit

[Fluory]

Fresh review (independent subagent, read-only) – result and how it was handled

Verdict: changes needed (1 blocking, 4 nits). All acceptance criteria covered; drain switch, ERP fallback, health values, deactivation and GDPR Art. 33/34 checked as correct.

• Blocking – "AI token leaked" claimed retries. A 401 is classified as non-retryable (src/features/extraction/ai-client.ts → AiServiceError("rejected", false, …); src/features/jobs/drain.ts marks the request ERROR at once) → fixed in 01f4b3f: the row says so and says to reprocess after both projects carry the new token.
• Nit – /api/health aiService: ok does not prove a rotation (pingAiService calls the open /healthz without a token) → fixed: proof is one synthetic upload reaching Zur Prüfung; tabletop updated.
• Nit – deactivation is refused for oneself and the last active admin → fixed: the row says so and points to "Data at risk".
• Nit – paused AI service: retries run out and end in ERROR → fixed: "nothing lost" now means reprocess after the pause.
• Nit – German line in the release skill → no change (rule 11: file is German, not a substantive edit).

---

Generated by Claude Code

[Fluory]

The failing Vercel preview deployment is not caused by this PR: the Vercel account hit its free-plan daily limit (api-deployments-free-per-day, more than 100 deployments, "try again in 24 hours"). The PR changes only Markdown; CI (check, compose-smoke) is green on 01f4b3f. No fix is possible from this PR. Note: a merge to main before the limit resets would leave the production deployment pending/failed as well – redeploy once the limit lifts.

---

Generated by Claude Code