Risikoregister (Taktano)
Lebendes Register relevanter Risiken (Technik · Sicherheit · Datenschutz · Regulatorik) für die Zielmärkte DE · AT · CH und generell. Pflicht (CLAUDE.md §Compliance): zu Session-/PR-Beginn die relevanten Risiken sichten, neue eintragen, Status/Maßnahme pflegen; bei kritischen/regulatorisch relevanten Themen aktiv hinweisen + Optionen zeigen.
Skala: W = Wahrscheinlichkeit (1 niedrig · 2 mittel · 3 hoch) · A = Auswirkung (1 · 2 · 3) · Score = W×A (1–9; ≥6 = vorrangig). Status: offen · in Arbeit · gemindert · akzeptiert.
| ID | Risiko | Bereich | W | A | Score | Status | Maßnahme / Owner | Bezug | Letzte Prüfung |
|---|---|---|---|---|---|---|---|---|---|
| RISK-1 | DO-Blob wächst unbegrenzt (auftraege/leistungsnachweise/archivierte nie beschnitten) → DO-Storage-Limit & Ladezeit | Persistenz/Skalierung | 2 | 3 | 6 | offen | Pruning/Archiv-Auslagerung; queryable Store (D1) für Historie | OP-AUDIT-1 | 2026-06-24 |
| RISK-2 | Vergangene Wunschfrei/Bereitschaft nicht wiederherstellbar (removeAbwesenheit löscht ohne Historie) → Fairness-Historie & Audit unmöglich | Daten/Audit | 3 | 2 | 6 | offen | Append-only-Historie / Audit-Log | OP-AUDIT-1, OP-OPT-7 | 2026-06-24 |
| RISK-3 | Klartext-PII in Logs/State/URLs (DSGVO DE/AT/CH) | Datenschutz | 2 | 3 | 6 | offen | PII-Scrubbing im Logger-Wrapper; EU-Residenz; Datenminimierung (Kunde = Name + CRM-Link) | OP-LOG-1, OP-OBS-1, OP-SEC-1 | 2026-06-24 |
| RISK-4 | Supply-Chain / verwundbare (transitive) Dependencies | Sicherheit | 2 | 3 | 6 → 4 | gemindert (06-27) | SBOM (CycloneDX) + ✅ Dependabot (npm/pip/actions) + ✅ CI-Gate Security-Audit (Job checks, npm audit prod-Deps high+ / pip-audit, blockiert PR/CI — nicht Deploy, Availability); gepinnte Actions. CodeQL ✅ aktiv via GitHub Default Setup (TS+Python automatisch, kein eigener Workflow; 06-27). Snyk = spätere Komfort-Option, nicht zwingend (Befund/Umsetzung 06-27, docs/betrieb/Compliance.md). Vuln-Assessment 07-03: 0 Prod-Runtime-Vulns (Server/Client npm audit --omit=dev = 0, pip-audit Solver grün) — alle Findings lagen in Dev-/Build-Toolchains und wurden nicht-brechend behoben: wrangler ^4.105 (Server + docs-site → undici/ws/miniflare-Highs weg), Client npm audit fix (Angular 20.3.31/vite 7.3.5) + Patch-Override http-proxy-middleware 3.0.7 (Angular pinnte exakt 3.0.5); flyctl-Action SHA-gepinnt (war letzte @master-Referenz). Akzeptierte Dev-only-Residuen (kein nicht-brechender Fix; nicht ausgeliefert): drizzle-kit→esbuild (moderate), Client babel/uuid-Ketten (low/moderate, Angular-exakt-Pins), docs-site serialize-javascript (high, aber nur Build-Cache der statischen Doku-Site, vertrauenswürdige Inputs — npm-„Fix" wäre Docusaurus-Downgrade) | OP-SBOM-1, OP-SEC-1 | 2026-07-03 |
| RISK-5 | Secret-Leak (FLY_API_TOKEN · Cloudflare · GitHub-Bot) | Secrets/CI | 1 | 3 | 3 | gemindert | Keine Secrets im Repo (GitHub-Secrets), least-privilege Deploy-Token, gepinnte Actions | OP-SEC-1 | 2026-06-24 |
| RISK-6 | Mandanten-Isolation: Cross-Tenant-Zugriff über DO-State/Broadcast/Insights | Multi-Tenancy | 2 | 3 | 6 | offen | Authz je Message, keine Fremd-State-Broadcasts, Pentest vor Mehr-Mandanten-Betrieb | OP-SEC-1, OP-AUTH-1 | 2026-06-24 |
| RISK-7 | CP-SAT-Solver (Fly.io) nicht erreichbar | Verfügbarkeit | 2 | 1 | 2 | gemindert | TS-Fallback aktiv; Solver-Status-Hinweis im Cockpit (30-s-Ping) | OP-DEPLOY-2 | 2026-06-24 |
| RISK-8 | E-Rechnungs-Pflicht DE-B2B (ab 2025) nicht erfüllt | Regulatorik (DE) | 2 | 2 | 4 | offen | SevDesk erzeugt XRechnung/ZUGFeRD (zurückgestellt, vor Produktivbetrieb) | OP-BILLING-1 | 2026-06-24 |
| RISK-9 | Zahlungs-gesteuerter Zugang sperrt fälschlich bei Sync-Ausfall | Zugang | 1 | 2 | 2 | gemindert | Bewusst fail-open + Admin-Override + Audit jedes Stufenwechsels | OP-ACCESS-1, OP-AUDIT-1 | 2026-06-24 |
| RISK-10 | Prompt-Injection / Tool-Missbrauch im In-App-Assistenten | KI/Sicherheit | 2 | 2 | 4 | in Arbeit (07-01) | Härtung gebaut: Tools nur read/simulate (Hebel kein Auto-Apply, §3), Rundenlimit je Turn (MAX_RUNDEN), Feature-Flag-Allowlist (ASSISTENT_ALLOWLIST), Feedback dormant-guarded. Offen: externe vs. interne Doku-Sicht scharf schalten (OP-DOCS-5), Eingabe-Rate-Limit je Nutzer | OP-AI-4 §5, OP-SEC-1 | 2026-07-01 |
| RISK-11 | Falsche Kosten-Stammdaten (Stundensätze/Materialpreise) → irreführende Margen/Fehlentscheidungen | Daten/Steuerung | 2 | 2 | 4 | offen | Sprechende Stammdaten-Pflege, Soll-Ist-Plausibilisierung, Audit der Änderungen (G-1/D-2) | OP-COST-1, OP-AUDIT-1 | 2026-06-25 |
| RISK-12 | Sensible Kostendaten vor verifiziertem Rollenmodell sichtbar (Marge/Sätze ohne OP-AUTH-1 A-3) | Datenschutz/Zugang | 2 | 2 | 4 → 1 | gemindert (09-22, v0.165.0) | Verifizierte Rolle gebaut (A-3): die Rolle steht am Konto (vergeben in Verwaltung → Zugänge), kommt aus der Anmelde-Sitzung und wird vom Worker als X-Taktano-Rolle an das DO gereicht — client-seitig nicht fälschbar (der Worker entfernt jede mitgeschickte Kopie des Headers, bevor er den eigenen setzt). Damit ist die Selbstauskunft (A-1.5) als Autorisierungsquelle abgelöst; sie greift nur noch, wenn die Anmeldung gar nicht konfiguriert ist (lokal/E2E — dort gibt es keine verifizierbare Identität). Restrisiko (klein): genau dieser Dormant-Pfad; er verschwindet mit der Aktivierung (Runbook docs/architektur/Anmeldung.md §6) | OP-COST-1, OP-AUTH-1, OP-SEC-1 | 2026-09-22 |
| RISK-13 | Etablierter Wettbewerber (branchennahes Bestandssystem / KFZ-DMS) kopiert die Veredelungs-Nische inkl. Taktung → Differenzierungsvorsprung schmilzt | Markt/Wettbewerb | 2 | 2 | 4 | offen | Vorsprung über Tiefe (CP-SAT-Taktung, „Mensch entscheidet, KI schlägt vor") + Referenzkunden/Verbands-Hebel ausbauen, bevor Nachahmer aufschließen; Roadmap auf den Burggraben fokussieren | OP-COMPETE-1, OP-MARKET-1 | 2026-06-28 |
| RISK-14 | Markt zu klein / SOM überschätzt (zu wenige Betriebe mit echtem Planungsschmerz) → Vertriebsinvestition trägt nicht | Markt/Strategie | 2 | 3 | 6 | offen | Pilot-Validierung VOR großer Vertriebsinvestition (Vorher/Nachher-Messung); TAM/SAM/SOM-Annahmen mit Verbands-/IHK-Statistik kalibrieren; Beachhead scharf halten (Folierer DE) | OP-MARKET-1, OP-COMPETE-1 | 2026-06-28 |
| RISK-15 | Assistent-Prompts/Live-State (Auftrags-/Standortdaten) verlassen die EU an den LLM-Provider → DSGVO/AVV-Pflicht | Datenschutz (DE/AT/CH) | 2 | 3 | 6 | in Arbeit (07-01) | EU-gehostetes Modell gewählt (Residenz in der EU, ASSISTENT_LLM_BASE_URL); dormant ohne Key; Datenminimierung (schmale Insight-Projektion statt Roh-State); kein Klartext-PII im Prompt. Offen: AVV mit Provider abschließen + in Compliance.md belegen, EU-Region final verifizieren | OP-AI-4, OP-LOG-1, OP-SEC-1 | 2026-07-01 |
| RISK-16 | OTel-Betriebs-Logs/-Metriken an Grafana-Cloud-Region → Telemetrie-Datentransfer (DSGVO DE/AT/CH) | Datenschutz (DE/AT/CH) | 2 | 2 | 4 → 2 | gemindert (07-02) | EU-Umstellung erfolgt: Stack auf Grafana Cloud EU (otlp-gateway-prod-eu-west-2) umgestellt (Nutzer 07-02) → Telemetrie bleibt in der EU. Zuvor kurzzeitig US-Test-Stack (nur Dev, PII-gescrubbt, keine echten Kundendaten) — abgelöst. AVV/DPA dokumentiert (07-02): als Tracker-Zeile C-18 in Compliance.md erfasst (Datenminimierung: nur PII-gescrubbte Betriebs-Telemetrie, keine Kundendaten; EU-Region belegt) — Rest-Offen (Nutzer/Legal): Grafana-Labs-Standard-DPA gegenzeichnen + ins VVT (C-10) aufnehmen, Retention dokumentieren, vor Go-Live final verifizieren. Wechsel ist code-frei via OTLP (nur OTEL_EXPORTER_OTLP_ENDPOINT/_HEADERS) | OP-OBS-1, OP-LOG-1, OP-SEC-1 | 2026-07-02 |
| RISK-18 | Self-hosted CI-Runner (OP-CI-2) führt bei einem Fork-PR fremden Code aus (Build-/Test-Skripte) → Zugriff auf den lokalen Runner-Host/das Netz der Org | Sicherheit/CI | 2 | 3 | 6 → 2 | gemindert (07-04) | Fork-Gate im Workflow: in ci.yml läuft jeder Job als runs-on: ${{ github.event.pull_request.head.repo.fork && 'ubuntu-latest' || vars.CI_RUNNER || 'self-hosted' }} → PRs aus Forks landen immer auf GitHub-gehosteten Wegwerf-Runnern, nie auf dem self-hosted Runner. sync-pr-logs.yml weist Fork-PRs zusätzlich per Guard 2 vor dem Checkout ab. Deploy-/Schedule-Workflows (fly-deploy/docs-deploy/weekly-audit) laufen nur auf main-Push/Dispatch/Cron im eigenen Repo (kein Fremd-PR). Rest-Offen: Runner-Host härten (ephemer/isoliert, least-privilege im Org-Netz), sobald der lokale Runner produktiv trägt | OP-CI-2, OP-SEC-1 | 2026-07-04 |
| RISK-17 | Vectorize (Doku-RAG-Index) bietet keine EU-Jurisdiktions-Option (anders als R2) → Doku-Chunks (inkl. sichtbarkeit:'intern') liegen in einem global verteilten Store | Datenschutz (DE/AT/CH) | 2 | 1 | 2 | in Arbeit (07-02, akzeptiert) | Aktiviert (Nutzer-Entscheidung 07-02, überstimmt die frühere Zurückstellung): RAG live geschaltet — Index taktano-doku self-provisioniert + Embeddings-Push via scripts/push-doku-index.mjs (CI deploy + docs-deploy). Exposure gering + by design begrenzt: nur Doku-Inhalte + Metadaten, kein PII, keine Kunden-/Tenant-Daten; Frage-Embeddings über das EU-Modell (RISK-15/C-17), nur der Vektor geht an Vectorize. Compliance-Nachzug erledigt: Zeile C-19 in Compliance.md (Residenz + AVV-Scope C-10). Offen (wiederkehrend): prüfen, ob CF EU-Jurisdiktion für Vectorize anbietet (dann pinnen); bei sensibleren Index-Inhalten (Tenant-Doku) neu bewerten | OP-DOCS-2, OP-AI-4, OP-SEC-1, C-19 | 2026-07-02 |
| RISK-19 | Akquise-/Orga-Tool (OP-VERTRIEB-2) — falls Standard-CRM/Marketing-Tool (z. B. Hubspot) statt Eigenbau gewählt wird: Lead-Kontaktdaten fremder Betriebe (kein Taktano-Mandantendatum) landen bei einem externen Anbieter → AVV-/EU-Residenz-Pflicht (DSGVO DE/AT/CH), noch nicht geprüft | Datenschutz (DE/AT/CH) | 2 | 2 | 4 | offen | Vor Tool-Entscheidung klären (Teil der Build-vs-Buy-Prüfung OP-VERTRIEB-2 selbst): EU-Residenz/AVV-Fähigkeit des gewählten Anbieters, Datenminimierung (nur Kontakt-/Call-Status-Daten, keine weiteren PII), VVT-Eintrag (C-10) bei Go-Live | OP-VERTRIEB-2 | 2026-07-11 |
| RISK-20 | Barrierefreiheit (WCAG 2.1 AA) nicht erfüllt → im DE-Markt regulatorisch relevant (BFSG seit 06-2025, Referenzstandard EN 301 549); systemischer Kontrast-Alt-Bestand (~130 Knoten: --tk-text-faint, Marken-Rot-als-Text, Grün-Status < 4,5:1) + Struktur (nested-interactive) | Regulatorik/Barrierefreiheit (DE/AT/CH) | 2 | 2 | 4 | in Arbeit (09-13) | axe-Gate eingeführt (OP-E2E-1 Stufe 2): fängt jede neue serious/critical-Regel; der Alt-Bestand ist als OP-A11Y-1 erfasst und im Gate transparent zurückgestellt (protokolliert, nicht ignoriert). Offen: Palette-/Token-Remediation (AA-Kontrast, verzahnt mit OP-REDESIGN-1) + Karten-Entschachtelung; danach Regeln aus dem Gate-DEFERRED entfernen → blocken wieder. Für reines B2B enger, aber AA ist realistisches Ziel (Ausschreibungen/EU-Trend) | OP-A11Y-1, OP-E2E-1, OP-REDESIGN-1 | 2026-09-13 |
| RISK-21 | Fehldiagnose-getriebene Änderung bricht ein funktionierendes Prod-Feature: „Weg 1" (#799) baute einen Worker-JWT-Gate auf /parties/*, verifiziert nur an unauthentifizierten Edge-Probes (302) statt am echten eingeloggten Pfad — der Gate lehnte den authentifizierten WebSocket mit 401 ab → Live-Daten produktiv tot | Prozess/Verifikation | 2 | 3 | 6 → 2 | gemindert (09-22) | Revert (v0.164.1): ACCESS_TEAM_DOMAIN/ACCESS_AUD geleert → Gate aus; Access-Allow bleibt (der WS lief immer darüber). Lehre (verbindlich): Infra-/Auth-Verhalten am authentifizierten Pfad beweisen, nie an unauth-Probes; ein Worker-Gate darf WS-Upgrades nie ablehnen; „verifiziert" heißt live gegen den echten Nutzer-Flow, nicht gegen einen curl-Probe. Vor breiten Prod-Deploys eines Netz-/Auth-Gates: erst an einem eingeloggten Client gegenprobt | OP-AUTH-1 | 2026-09-22 |
| RISK-22 | Datenresidenz von Cloudflare Email Sending unbelegt: die Magic-Link-Mail trägt die Mitarbeiter-E-Mail (PII) durch einen Dienst, für den keine EU-Residenz-Zusage gefunden wurde (anders als R2/D1 mit jurisdiction = eu bzw. weur) | Datenschutz (DE/AT/CH) | 2 | 2 | 4 | offen | Vor produktivem Kundenbetrieb klären (Compliance C-20): Residenz/Subprozessoren bei Cloudflare erfragen, in AVV/VVT (C-10) aufnehmen. Datenminimierung greift schon heute: die Mail enthält nur Adresse + Einmal-Link, keine Betriebs-/Kundendaten. Ausweichweg ohne Code-Umbau: mail.ts kapselt den Versand — ein EU-Anbieter (Brevo/SES eu-central-1) wäre ein Austausch dieser einen Funktion | OP-AUTH-1, OP-SEC-1, C-10 | 2026-09-22 |
| RISK-23 | /api/anmelden ist öffentlich erreichbar (Folge der Golden-Rule-Abweichung AU-2) → ohne Deckel ist Mail-Flooding gegen bekannte Adressen bzw. Kostenerzeugung über den bezahlten Mailversand möglich | Sicherheit/Kosten | 2 | 2 | 4 → 2 | gemindert (09-23) | Zwei Schichten, verschiedene Aufgaben (Volltext: docs/architektur/Anmeldung.md §6a). RL-2 (gebaut): Deckel je Konto im Worker — höchstens 3 Magic-Link-Mails/Stunde, Prüfen und Zählen in einer D1-Anweisung (sonst kämen gleichzeitige Anfragen beide durch), Zähler an der Konto-Id statt an der Adresse (kein zweiter PII-Ort, ON DELETE CASCADE räumt mit ab). Still, d. h. gleiche Antwort wie ein gesendeter Versuch — eine Sonderantwort wäre selbst die Auskunft, dass das Konto existiert. RL-1 (offen, Betreiber): Cloudflare-Rate-Limiting-Regel je IP; Werte vom Free-Plan diktiert (1 Regel, 10-s-Fenster, 10-s-Sperre, nur der Pfad im Ausdruck) → 20 Anfragen/10 s, bewusst großzügig, weil die Werkstatt hinter einem NAT sitzt und eine scharfe Schwelle den Schichtbeginn aussperrt. Rest-Risiko benannt: schlimmster Fall ist 3 Mails je Konto und Zählfenster (bei 30 Mitarbeitern 90 Mails je Fenster) — an der Fixed-Window-Grenze kurzzeitig bis zu 6 je Konto, das ist die bewusst in Kauf genommene Schwäche dieser Zählweise; null ginge nur mit Enterprise-Features oder CAPTCHA. Gemindert wird es zusätzlich durch: 15-Min-Token, Einmal-Verwendung, disableSignUp, und die Antwort verrät nicht, ob eine Adresse existiert | OP-AUTH-1, OP-SEC-1 | 2026-09-23 |
| RISK-24 | Cloudflare Email Sending ist Public Beta (seit 2026-04-16) — kein GA-SLA; ein Ausfall/Breaking Change legt die einzige Anmeldemöglichkeit lahm (kein Passwort als zweiter Weg) | Betrieb/Verfügbarkeit | 2 | 3 | 6 | offen | Vor dem Lösen der Access-App: Wiederanlauf-Weg festlegen — Access-App als Rückfall (Runbook §6 Rollback) genügt heute. Mittelfristig: zweiter Versandweg hinter dem mail.ts-Adapter oder ein zweiter Anmeldeweg (z. B. Passkey) für den Betreiber-Zugang | OP-AUTH-1, OP-SEC-1 | 2026-09-22 |
| RISK-25 | Durable-Object-onStart-Crash = Totalausfall: wirft ein datenabhängiger Nachlade-Schritt (Migration/abgeleitete Felder/Backfill) in onStart, startet die DO nicht → jede Verbindung (WS und HTTP) bekommt Cloudflare-1101 → App „keine Verbindung". Fresh-Seed-E2E übt den realen Prod-State nicht → grün trotz Prod-Ausfall. Vom Weg-1-Gate (401) zeitweise maskiert, nach dem Revert als eigentliche Ursache sichtbar | Verfügbarkeit/Persistenz | 2 | 3 | 6 → 3 | gemindert (09-23) | Fail-soft onStart (v0.165.1): der essenzielle Saved-State-Load bleibt hart; die Nachverarbeitung ist in try/catch — scheitert sie, bootet die DO trotzdem und die exakte Ursache wird strukturiert in den Observability-Sink geloggt (OP-OBS-1) statt in einem opaken 1101. Rollback: ein Snapshot (structuredClone) vor der Nachverarbeitung wird bei Fehler zurückgerollt, damit kein teilmigrierter Stand persistiert wird. Offen: die im Log sichtbare Wurzel (welcher Schritt/welches Feld im Prod-State) gezielt fixen + einen Selbsttest mit realitätsnahem Alt-State ergänzen (E2E-Lücke: nur Fresh-Seed). Vor DO-Startup-Änderungen gegen realistische Alt-Blobs testen | OP-DATA-1, OP-OBS-1 | 2026-09-23 |
| RISK-26 | Re-Run eines älteren CI-Laufs deployt den alten Commit und macht damit einen neueren Prod-Stand rückgängig. Ein Re-Run ist an den Commit des Laufs gebunden, nicht an den aktuellen main — wer ihn nutzt, um einen Deploy ohne Code-Änderung auszulösen (z. B. nach dem Setzen eines Secrets), rollt unbemerkt zurück | Prozess/Verfügbarkeit | 2 | 3 | 6 → 2 | gemindert (09-23) | Eingetreten am 2026-09-23: um ein Secret (AUTH_SECRET) wirksam zu machen, wurde der CI-Lauf von 4686473 (0.165.0) neu gestartet — main stand da schon auf eaf168f (0.165.1, Prod-1101-Fix aus #807, deployt 07:14). Der Re-Run deployte 07:24:38 wieder 0.165.0 und nahm den Fix aus der Produktion; wiederhergestellt 07:28:12 = 3½ Minuten Rückfall (Zeiten aus den Deploy-Logs). Erkannt beim Neu-Aufsetzen des Feature-Branches (main war weiter als erwartet), behoben durch Re-Run des eaf168f-Laufs. Maßnahme: workflow_dispatch in ci.yml — ein manueller Lauf läuft gegen einen Ref (main = aktueller Stand), nicht gegen einen eingefrorenen Commit; damit gibt es für „Deploy ohne Code-Änderung" einen richtigen Weg. Regel: Re-Run nur zum Wiederholen desselben Stands (Flake); für einen Deploy immer Dispatch auf main. Vor jedem Eingriff in den Deploy-Pfad git fetch origin main und den Stand prüfen | OP-CI-1, OP-CI-2 | 2026-09-23 |
| RISK-27 | Veralteter PWA-Shell nach Deploy strandet den Bediener: Die App ist eine PWA — der Angular-Service-Worker (ngsw-worker.js) cached den App-Shell und liefert ihn nach einem Deploy weiter aus dem Cache, bis alle Tabs geschlossen werden. Ein normaler Reload holt den neuen Client nicht. Bringt ein Deploy eine für die Verbindung nötige Client-Änderung (z. B. den WS-Handshake-Token ?wsauth=, #818), verbindet der alte Shell nicht mehr → rotes „Keine Verbindung"-Banner, obwohl Server und Client korrekt deployt sind. Trifft besonders Kiosk-/Werkstatt-Tablets, die nie ganz geschlossen werden | Verfügbarkeit/Betrieb | 2 | 3 | 6 → 2 | gemindert (09-23) | Einordnung (09-25): Die unten als „eingetreten" gewertete Episode vom 2026-09-23 war nachträglich betrachtet das CPU-Limit des Live-Servers (RISK-28), nicht der veraltete Shell — die Workers Logs zeigten „Durable Object exceeded its CPU time limit". Der Mechanismus bleibt generell möglich, Bewertung und Maßnahmen bleiben (schadlos). Ursprünglich als eingetreten gewertet (09-23): nach dem #818/#820-Deploy blieb der rote Banner beim Bediener stehen; das ausgelieferte Bundle (main-CZTBG6HE.js) enthielt den Fix nachweislich, der Browser lief aber auf dem alten SW-Shell. Maßnahme (v0.169.0): VerbindungService.selbstheileVeralteteShell() — bei gescheiterter Verbindung (rotes Banner) und vorhandenem Netz prüft die App einmal pro Sitzung (sessionStorage-Guard) proaktiv auf eine neue Version und aktiviert+lädt sie automatisch; der Shell heilt sich so nach einem Deploy selbst. Guard gegen Reload-Schleifen; gibt es keine neue Version, bleibt der manuelle „Neu laden"-Button (SW-umgehender Neustart) — v0.169.1 härtet diesen Button: er leert jetzt zusätzlich die Cache-Storage (nicht nur unregister()), sonst bediente der Reload teils weiter den alten Shell. Live-Beleg 09-23: /api/ws-token lieferte eingeloggt einen gültigen Token, das Bundle war der neue Stand — der Bediener lief auf dem alten SW-Cache. Regel: verbindungsrelevante Client-Änderungen immer zusammen mit dem Server deployen; nach einem Deploy nicht annehmen, dass offene Tablets ihn sofort haben. Offen: aktive Versions-Signalisierung (Server→Client „Pflicht-Update") als härtere Variante, falls je ein Breaking-Client-Change nötig wird | OP-OFFLINE-1, OP-AUTH-1 | 2026-09-23 |
| RISK-28 | Durable Object sprengt das CPU-Limit durch mitwachsende Historie: abgeleitete Rechnungen im Stand-Aufbau (snapshot(), z. B. Auslastungs-Quote über alle Teilschritte seit Betriebsbeginn) wachsen mit der Datenmenge; ein quadratischer Intervall-Helfer (subtract) plus mehrfacher Stand-Aufbau je Verbindung trieb am 2026-09-23 den Prod-DO über das CPU-Limit → „Durable Object exceeded its CPU time limit and was reset" (Workers Logs) → keine Live-Verbindung. Fresh-Seed-Tests sehen das nie | Verfügbarkeit/Performance | 3 | 3 | 9 → 4 | gemindert (09-23) | v0.169.5: subtract linear (Äquivalenz-Selbsttest test:subtract, 20 000 Zufallsfälle + Laufzeit-Schranke); Stand-Aufbau nur mit Empfängern und einmal je Verbindung; /api/diagnose zeigt Rohgrößen (Aufträge, Teilschritte, Historie in Tagen) ohne teuren Aufbau; Workers Logs zeigen CPU-Abbrüche (v0.169.4). Messung nach Deploy: Verbindung steht wieder (PO 09-23). Auslastungs-Quote auf heute + 14 Tage begrenzt (PO-Entscheidung Z1, 09-23) → Rechenlast wächst nicht mehr mit der Historie. Gantt-Ausfall-Bänder (ressourcenDTO) ebenso auf die Gantt-Aufträge ± 7 Tage begrenzt (ganttAusfallFenster). Selbsttest mit großem Alt-Datenbestand test:last-altbestand (CI-Gate): 3 Jahre / >20 000 Teilschritte — Quote + Gantt-Bänder unabhängig von der Historie + Zeitbudget; Gegenprobe (alte Ganze-Historie-Rechnung) schlägt an | OP-OBS-1, OP-DATA-1 | 2026-09-23 |
Review-Rhythmus
- Je Session/PR: betroffene Risiken sichten; neue Risiken aus dem Change eintragen; Score/Status aktualisieren.
- Vorrangig behandeln: Score ≥ 6. Bei neuen kritischen/regulatorischen Themen für DE/AT/CH sofort flaggen + Optionen aufzeigen (CLAUDE.md §Compliance) und hier eintragen.
- Verknüpfung: Maßnahmen hängen an den offenen Punkten (GitHub-Issues
offener-punkt, Single Source der Umsetzung seit TKT-D-862, →Offene-Punkte.md); dieses Register bündelt die Risiko-Sicht.
↩ Zurück zur Doku-Landkarte · Lesepfade · Register (alle OPs)