Zum Inhalt

Drift-Status vor Block 11 — 2026-04-30

Erstellt: 2026-04-30 (post-v1.1.0-Tag) Zweck: Vollständige Bestandsaufnahme offener Drifts und TODOs vor der Block-11-Run-Entscheidung Vorgänger-Tag: v1.1.0 (f163cba)

Ohne diese Audit-Doku würde der Block-11-Run mit Annahmen über den Drift-Zustand starten (Pattern aus 8.1-Re-Diagnose: Status-Annahmen müssen über find/grep verifiziert werden, nicht über Konversations-Erinnerung). Die Empfehlungen am Ende sind als Diskussions-Grundlage gedacht, nicht als Direktiven.

Zusammenfassung

Kategorie Offen Block-11-blockierend Block-11-relevant Spätere Phase
Auth-Drifts 1 0 0 1
Platform-TODOs 4 0 1 3
UX-TODOs 0 – – –
Konzept-Drifts 1 0 1 0
Block-Review-TODO-Familien 6 (Familien) 0 0 6
Operations-Lücken (Datapoints, kein TODO) 3 0 1 2
Total offen ~45 Items in 6 Familien + 6 Solo-Items 0 3 45

Belastbare Block-11-Empfehlung am Ende der Doku.

Inventur-Methode

  • Phase 0a: grep -nE '^### TODO-' docs-kora/docs/offene-todos.md und Status-Pairing per awk — liefert vollständige Liste mit Status-Labels.
  • Phase 0b: grep -nE '^## |^###' docs-kora/docs/roadmap.md — findet Backlog-Sektion (Zeile 1820), Phase-D-Inhalte und Block-Status.
  • Phase 0c: grep §17.2a in konzepte/multitenancy-fundament.md — bestätigt §17.2a-Reconciliation-Pattern.
  • Phase 0d: grep TODO|FIXME|XXX src/kora_platform/ — 31 Marker über 16 Dateien, alle verweisen auf bestehende oder erledigte TODOs.
  • Phase 0e: git log --grep für Block-8-Merge-Hashes als Audit-Spur.

Block-11-Vorbedingungen / -relevant

TODO-Platform-15 — Playwright-E2E-Coverage-Lücke (Block-11-relevant)

  • Status: Open (seit Block-8.7-Hand-off, 2026-04-30)
  • Severity: Low (Score 35)
  • Block-11-Bezug: Block 11 berührt den Branding-Read-Pfad (Widget-Config-Resolver) und macht aus dem Feedback-Schreib-Pfad einen Platform-First-Pfad. E2E-Regression-Schutz für die in 8.6/8.7 angelegten Sub-Routes (/chatbots/:id/branding, /chatbots/:id/feedback, Operator /tenants/:id/branding) ist Versicherung dagegen, dass Block 11 ohne sichtbares UI-Brechen passiert.
  • Empfehlung: Lutz-Entscheidung zwischen
    1. Vorab-Mini-Run (~6–8h) — strikte Disziplin, sauberer Block-11-Start.
    2. Integriert in Block 11 — E2E-Sweep wird Teil der Block-11-Akzeptanz-Matrix; spart einen Kontext-Switch, verlängert Block 11 um die gleichen 6–8h.
  • Verweis: offene-todos.md §TODO-Platform-15

TODO-Konzept-01 — §17.2/§18 + Block-11-Widget-Aufwand (Block-11-relevant)

  • Status: Open
  • Severity: Low (Score 40)
  • Block-11-Bezug: TODO-Konzept-01 listet u. a. die Diskrepanz zwischen Block 11 mit 12h in §17.2 vs. 16h in roadmap.md:698. Der Refined-Plan im Strategie-Pause-Abschnitt arbeitet mit 12–14h Refined und Pattern-Reife-Quote 60 % → ~8–10h real. Vor Block-11-Start sollte Lutz die Schätz-Basis klären (12 oder 16 oder 12–14).
  • Empfehlung: kurze Klarstellung im Konzept (~15–30min) bevor Block 11 startet — keine Code-Arbeit, nur Aufwand-Zahl konsistent ziehen. Konzept §17.2a-Reconciliation-Pattern existiert dafür.
  • Verweis: offene-todos.md §TODO-Konzept-01, konzepte/multitenancy-fundament.md §17.2a

Widget-Schreib-Pfad-Refactor (kein TODO, im Block-11-Scope)

  • Status: bekannt; in v1.1.0-Release-Notes als Block-11-Inhalt markiert.
  • Begründung: Discovery aus Block 8.7 zeigte, dass das Widget Feedback aktuell nach src/avs_chatbot/api/routes/feedback.py schreibt, nicht nach Platform. Platform-feedback-Tabelle ist in Production leer. Block 11 muss POST /api/v1/feedback in der Platform spiegeln und den Widget-Endpoint umstellen.
  • Empfehlung: Block-11-Scope-Inhalt, keine Vorbedingung. Sub- Block-Granularität analog 8.6 (Discovery-Refinement zu Beginn).
  • Verweis: releases/v1.1.0.md

Spätere Phase / Cleanup-Welle

TODO-Auth-NEU — JWT-sub-Claim-Mapper-Fix

  • Status: Open, monitored seit v1.0.0
  • Severity: M2/40
  • Begründung kein Block-11-Bezug: Widget-Sessions sind anonym, kein JWT-Actor im Schreib-Pfad. Tenant-UI/Operator-UI nutzen weiter die Composite-PK-Workarounds aus v1.0.0 (user_preferences.realm+username, platform_audit_log.actor_keycloak_id nullable). Drift bleibt über verify-auth-stack.sh-Checks 58a/58b sichtbar.
  • Trigger: v1.x-Patch-Release oder beim ersten Refactor mit echtem sub-Bedarf (z. B. wenn Widget User-Identification bekommt — nicht Block-11-Scope).

TODO-Platform-03 — File-Write-Hook blockt Substring-Match

  • Status: Open
  • Begründung: Toolchain-/Editor-Hook-Thema, nicht Code. Operations-Friction, kein funktionaler Drift.
  • Trigger: wenn der Hook produktiv stört.

TODO-Platform-11 — Backend-Pytest-Env-Bootstrap

  • Status: Open
  • Severity: Low (Score 35)
  • Begründung: Block 11 lebt mit dem v1.1.0-Akzeptanz-Workaround (docker cp tests + docker exec pytest). Bootstrap ist hard- Vorbedingung für Block 14 (CI), nicht für Block 11.
  • Trigger: vor Block 14.

TODO-Platform-12 — Pytest-Profil-Trennung Platform vs. AVS-Demo

  • Status: Open
  • Severity: Low (Score 45)
  • Begründung: Block 11 betrifft nur den kora-platform-Pfad; AVS-Demo-Test-Failures sind irrelevant für Block-11-Akzeptanz.
  • Trigger: vor Block 14.

Block-Review-TODO-Familien (Cleanup-Welle vor Block 13/14)

Aus Block-7-Review-Sweeps und Block-4/5-Reviews stehen sechs TODO-Familien offen. Sie sind alle Cleanup-Niveau (Review-M/L), keiner brennt für Block 11:

Familie Items offen Quelle Beispiele
TODO-Block-7-1b-NN 7 (von 8, -03 ✅) Block-7.1b-Code-Review E2E-Seed-Flag-Gate, Slug-ILIKE, useConfirm
TODO-Block-7-2-NN 6 (von 7, -05 verworfen) Block-7.2-Code-Review A11y, listsEqual, Trim-Diff
TODO-Block-7-3-NN 7 Block-7.3-Code-Review useModule, Optimistic-Update, Footer
TODO-Block-7-4-NN 8 Block-7.4-Code-Review Bulk-Loop-Cap, CSV-Export, Date-Range, KNOWN_ACTIONS-Drift
TODO-Block-7-NN (1-stellig) 7 Block-7-Generic-Review Route-Präfix, TOCTOU, pydantic[email]
TODO-Block-5e/5f/5g + 4b 4 Block-4/5-Reviews Audit-Rollback, DELETE-Scope, ON CONFLICT-updated_at, Qdrant-Backup

Empfehlung: Cleanup-Welle vor Block 13 oder Block 14. Keiner der Items ist Block-11-Pre-Condition, weil Block 11 weder Operator-UI-Reviews noch Block-4/5-Pfade berührt. Ausnahme zu prüfen: TODO-Block-7-4-04 (KNOWN_ACTIONS-Drift gegen Block 13/14) — Block 11 wird neue Audit-Actions einführen (tenant_widget.requested, chatbot_feedback.created o. ä.) und sollte direkt im Audit-Action-Whitelist landen, statt später nachgezogen zu werden. Keine Vorbedingung, aber „bei Gelegenheit mitnehmen".

Erledigte TODOs aus Block 8 (Audit-Spur)

TODO / Sub-Block Erledigt in Merge-Commit
TODO-Platform-13 (Module-Auto-Seed) Block 8.0 a6081d8
TODO-UX-03 (Tenant-Edit-UI) Block 8.1 (Verifikation, war bereits in 7.1b/7.4) fd7e5be
Block 8.2 (Multi-Lang Clone) – 8c5a37d
TODO-Platform-14 (Template-Audit-Trail) TODO-14-Run 44ecf06
Block 8.3 (Module-Toggle) – 1c8e656
Block 8.4 (Chatbots-CRUD + Wizard) – 0a65362
Block 8.6 (Branding) – 1713490
Block 8.7 (Feedback-View) – 7280d33
TODO-Platform-15 (Doku-Eintrag) Mini-Run 605c02f
v1.1.0-GA-Tag-Merge – f163cba

Discovery-Datapoints (kein TODO-Eintrag)

Mkdocs-Strict-Pre-Commit-Hook

Pattern bestätigt sich: v1.0.0-Tag hatte Anchor-Drift, v1.1.0-Tag hatte fehlende Akzeptanz-Matrix-Datei beim ersten make docs-kora-build-Lauf. Beide wurden gefangen, weil das make-Target strict läuft — aber erst nach dem Edit. Ein pre-commit-Hook, der make docs-kora-build --strict vor Doku-Commits laufen lässt, würde das eine Iteration früher fangen.

  • Aufwand: ~30 min (Hook in .pre-commit-config.yaml bzw. .git/hooks/pre-commit plus Path-Filter docs-kora/**).
  • Block-11-Bezug: keiner. Nice-to-have.
  • Empfehlung: kein TODO-Eintrag (zu klein für Tracking). Beim nächsten Doku-Drift-Vorfall als 30-min-Mini-Run einlösen.

ChatbotLifecycle.soft_delete vs. ChatbotService.deactivate (aus 8.4)

Block 8.4 hat im Tenant-Pfad chatbot.deleted_at = now() inline im Route-Handler gesetzt, statt ChatbotLifecycle.soft_delete aufzurufen — aus dokumentiertem Grund: ChatbotLifecycle.soft_delete ist auf admin_session mit eigenem Commit ausgelegt (Block-4-Phase-C-Pattern), passt nicht zur tenant-scoped, RLS-enforced Session aus 8.4. Pattern-Konsistenz mit operator_tenants.soft_delete_tenant ist gewahrt.

  • Block-11-Bezug: keiner. Block 11 berührt Lifecycle nicht.
  • Empfehlung: kein TODO-Eintrag jetzt; bei nächstem Lifecycle-Touch (z. B. Hard-Delete-Operator-Aktion oder Audit-Action-Sweep) als Refactor-Datapoint mitnehmen.

Code-TODO-/FIXME-Marker im Source

grep TODO|FIXME|XXX src/kora_platform/ liefert 31 Marker. Alle referenzieren entweder erledigte TODOs (TODO-B2-NN, TODO-B3-NN, TODO-Platform-13/14) oder offene, getrackte TODOs (TODO-Block-7-01, TODO-Block-7-4-NN, TODO-Block-4c, TODO-Block-5b/c, TODO-B2-03 — der Cross-Cut-Audit-Poller-Hinweis, kein Drift). Keine verwaisten Marker.

  • Block-11-Bezug: keiner.
  • Empfehlung: kein TODO-Eintrag.

Empfehlung für Block 11

Vorbedingung-Disziplin

Strikt notwendig vor Block 11: keine. Empfehlung im Sinne von „Versicherung":

  1. TODO-Konzept-01-Mini-Klarstellung (~15–30 min) für die Block-11-Aufwand-Zahl — entweder 12, 14 oder 16h verbindlich ziehen, damit der Block-11-Plan eine Boden-Schätzung hat.
  2. TODO-Platform-15 entweder direkt vor Block 11 (~6–8h) oder als integrierter Teil der Block-11-Akzeptanz-Matrix. Lutz- Entscheidung — ich lehne keine der beiden Varianten ab.

In Block 11 mitnehmen

  • Widget-Schreib-Pfad-Refactor: POST /api/v1/feedback in Platform spiegeln, Widget-Endpoint umstellen. Discovery-Phase 0 des Block-11-Plans muss prüfen, was AVS-Demo-Schreib-Pfad und Platform-Schema unterscheidet.
  • Audit-Action-Whitelist mitwachsen lassen (TODO-Block-7-4-04): neue Block-11-Actions direkt im KNOWN_ACTIONS-Set landen, nicht später nachziehen.
  • CORS-Origin-Check aus 8.6-Foundation einlösen (tenant_branding.allowed_origins ist validiert, fehlt nur die Middleware).
  • Embed-Code-Generator als Frontend-Mini-Komponente.

Nicht in Block 11

  • TODO-Auth-NEU (Workarounds bleiben aktiv)
  • TODO-Platform-11 / -12 (vor Block 14)
  • Block-7-Review-Cleanup-Familien (vor Block 13 oder 14)
  • Block-4b Qdrant-Backup, Block-5e/5f/5g Audit-Cleanup

Aufwand-Erwartung Block 11

Refined 12–14h × Pattern-Reife-Quote 60 % (aus Block 8) ≈ 8–10h real. Voraussetzung: Discovery-First-Phase analog Block 8.4/8.6/8.7. Falls TODO-Platform-15 integriert wird: +6–8h, also 14–18h Gesamt-Block.

Pattern-Reife-Datapoint

Block-8-Real (~30.5h) vs. Refined (50–64h) = 60 % Quote. Pattern- Reife wurde ab 8.4 sichtbar — 8.6 (5h) und 8.7 (3h) profitierten direkt vom Sub-Route-Pattern aus 8.6 plus Audit-Helper aus TODO-14. Block 11 baut auf der gleichen Foundation (tenant_branding.allowed_origins, chatbot_branding-Fallback- Tree, request_scoped_session-Pattern), eine ähnliche Quote ist erwartbar.

Wichtige Kalibrierungs-Lesson aus diesem Audit: Refined- Schätzungen sind eine Boden-Schätzung, keine Real-Schätzung. Das v1.1.0-Release-Notes-Dokument macht das explizit; das Drift- Status-Dokument wiederholt es als Block-11-Vorab-Disziplin.