Cleanup-Welle Discovery — 2026-05-01¶
Reine Discovery-Notiz, kein Code. Ziel: belastbare Aufwand-Schätzung pro Block-7-Review-Familie + Cluster-Empfehlung als Entscheidungs-Input für die Strategie-Pause nach v1.2.0-GA (Pfad B/C/D/E aus
roadmap.md).Quellen-Snapshot:
offene-todos.mdStand 2026-05-01 nach v1.2.0-Tag (Block 11 Merge149c699, Hash-Sync4e8dd60).
1 Inventur-Datapoint (Prompt vs. Realität)¶
| Metrik | Prompt-Annahme | Reale Zählung | Delta |
|---|---|---|---|
| Aktive TODOs | ~31 | 42 | +11 |
| Familien (nicht-leere Sektionen) | 5 | 9 | +4 |
Im Prompt vergessene Familien:
- Block 7.1a (
TODO-Block-7-01..07) — 7 Backend-TODOs aus dem ersten Tenants-CRUD-Block. War in der „Block 7"-Naming-Kollision der Roadmap- Umnummerierung versteckt; semantisch eine eigenständige Familie. - Block 5/Cleanup-Reste (
TODO-Block-5e/5f/5g) — 3 Audit-/Schema- Hygiene-Items, übrig nach dem Block-5-Cleanup-Lauf vom 2026-04-24. - Block 4 (
TODO-Block-4b) — Qdrant-Backup-Strategie, eigene Block-Größe (8–12h). - Auth/Drift-Stack (
TODO-Auth-NEU) — JWT-sub-Claim-Mapper-Fix als 8. Drift-Datapunkt.
Bereits archiviert/verworfen (zählen nicht in den 42): 6 Items
(7-1b-03 ✅, 7-1b-04 ✅ verworfen, 7-2-05 ✅ verworfen, 4c ✅
erledigt c898d85, Platform-15 ✅ Block 11, Konzept-01 ✅ 2026-05-01).
Konsequenz: Die im Prompt veranschlagten „~30–40h Cleanup-Aufwand" treffen mit der realen Inventur, wenn Cluster D3 (strategisch verschoben) korrekt ausgegrenzt wird — siehe §3 unten.
2 Aufwand-Schätzung pro Familie (Refined-h)¶
Heuristik: Doku/Comment-Fix 15–30min · Single-File-Code-Fix mit Test 1–2h · Multi-File-Pattern-Refactor 2–4h · Schema-Migration mit Tests 2–3h · Audit-Konsolidierung pro Action ~30min · Test-Erweiterung pro Pfad ~1h.
2.1 Block 7.1a — Tenants-Backend (7 TODOs)¶
| TODO | Sev | Heuristik-Klasse | Roh |
|---|---|---|---|
| 7-01 Operator-Route-Vereinheitlichung | 45 | Multi-File-Pattern (Helper + 4 Routen-Files) | 3h |
| 7-02 GET-List TOCTOU Window-Function | 65 | Single-File + Test | 1.5h |
| 7-03 Session-Identity-Trap Audit-Delta | 60 | Single-File + Test | 1h |
7-04 updated_at server-side onupdate |
55 | Schema-Migration + Tests (bundle 5g) | 2h |
7-05 pydantic[email] Runtime-Image |
40 | → Cluster D3 Supply-Chain-Decision | – |
7-06 search ILIKE-Metachar-Escape |
35 | Helper + Test | 30min |
7-07 include_deleted Vendor-Test |
30 | Test-Erweiterung | 1h |
| Familie-Roh (ohne D3) | 9h |
2.2 Block 7.1b — Operator-UI Frontend (6 aktive TODOs)¶
| TODO | Sev | Heuristik-Klasse | Roh |
|---|---|---|---|
| 7-1b-01 E2E-Seed Build-Flag-Gate | 65 | One-Liner + Sec-Test | 30min |
| 7-1b-02 Slug-Availability ILIKE-Substring | 60 | Backend-Endpoint + Composable | 1.5h |
7-1b-05 Stale-While-Revalidate useTenants |
40 | Cache-Pattern + Tests | 2.5h |
7-1b-06 useConfirm Singleton-Queue |
35 | Refactor + Tests | 1h |
| 7-1b-07 PATCH-Diff Trim | 30 | bundled mit 7-2-07 (Helper) | – |
| 7-1b-08 PORTING.md verschieben | 25 | File-Move + Link | 15min |
| Familie-Roh | 5.75h |
2.3 Block 7.2 — Templates-CRUD (6 aktive TODOs)¶
| TODO | Sev | Heuristik-Klasse | Roh |
|---|---|---|---|
| 7-2-01 ListInput A11y | 60 | A11y-Pattern + Tests | 2h |
| 7-2-02 Backend-Search Templates | 55 | Backend-Endpoint + Composable | 1.5h |
| 7-2-03 listsEqual Reorder | 55 | Single-File + Test (nur mit -01) | 1h |
| 7-2-04 Empty-List im POST | 45 | Single-File One-Liner | 30min |
| 7-2-06 Busy-Wait Sleep | 35 | Async-Refactor | 30min |
| 7-2-07 Trim-Diff (mit 7-1b-07) | 30 | Helper + 2 Caller adaptieren | 1h |
| Familie-Roh | 6.5h |
2.4 Block 7.3 — Modules-Registry (6 aktive TODOs ohne D3)¶
| TODO | Sev | Heuristik-Klasse | Roh |
|---|---|---|---|
| 7-3-01 Pakete/Tier/Limits Backend+UI | 65 | → Cluster D3 (Block 12 Provisioning) | – |
7-3-02 useModule Detail-Endpoint |
60 | Backend-Endpoint + Composable | 1.5h |
| 7-3-03 Aggregate-Endpoint TenantModules | 55 | Backend-Endpoint + Refactor | 2h |
| 7-3-04 Optimistic-Update Toggle | 50 | Single-File-Code-Fix | 1h |
| 7-3-05 Mutation-Errors Detail | 45 | flattenError-Helper + Caller-Sweep |
1.5h |
| 7-3-06 UUID-Truncation Tooltip | 35 | Cosmetic | 30min |
| 7-3-07 Footer veraltet | 30 | Cosmetic | 15min |
| Familie-Roh (ohne D3) | 6.75h |
2.5 Block 7.4 — Audit/Bulk/Connectors (8 aktive TODOs ohne D3)¶
| TODO | Sev | Heuristik-Klasse | Roh |
|---|---|---|---|
| 7-4-01 Bulk-Loop Cap+Hydration (mit 08) | 70 | Multi-File-Pattern + Tests | 3h |
| 7-4-02 CSV forensische Felder | 65 | Single-File + Test | 1h |
| 7-4-03 Bulk-Audit-Auffindbarkeit | 60 | Doku-Fix in konzepte/audit.md |
30min |
7-4-04 KNOWN_ACTIONS-Drift |
55 | → Cluster D3 (Block 13/14) | – |
7-4-05 Playwright workers: 1 |
40 | → Cluster D3 (>50 Specs Trigger) | – |
7-4-06 datetime.utcnow() deprecated |
35 | One-Liner | 15min |
| 7-4-07 Date-Range-Validation | 30 | Pydantic-Validator + Test | 1h |
| 7-4-08 Bulk-Progress-Indicator | 25 | bundled mit 7-4-01 | – |
| Familie-Roh (ohne D3) | 5.75h |
2.6 Block 5 / Cleanup-Reste (3 TODOs)¶
| TODO | Sev | Heuristik-Klasse | Roh |
|---|---|---|---|
| 5e Audit-Rollback-Test | 35 | Integration-Test (Permission-Sabotage) | 2h |
| 5f DELETE Defense-in-Depth-Scope-Check | 30 | Service-Refactor + Test | 1.5h |
5g tenant_modules.updated_at Upsert |
40 | bundle mit 7-04 (gleiche Migration) | – |
| Familie-Roh | 3.5h |
2.7 Cluster D3 — Strategisch verschoben¶
| TODO | Sev | Trigger / Eigen-Block | Roh |
|---|---|---|---|
| 4b Qdrant Backup-Strategie | 60 | Eigener Block (Backup-Konzept + Snapshots + Restore-Runbook) | 8–12h |
| 7-3-01 Pakete/Tier/Limits | 65 | Block 12 (Provisioning, Limits-Enforcement) | 12–16h |
Auth-NEU JWT-sub-Claim-Mapper |
40 | Eigener Sub-Block (Realm-JSON + Init-Skript) | 1.5h + 2h opt. |
| Platform-11 Pytest-Env-Bootstrap | 35 | Block 14 (CI-Pipeline) zwingend | 2h |
| Platform-12 Pytest-Profil-Trennung | 45 | Block 14 (CI) zwingend | 3h |
7-NN-05 pydantic[email] Supply-Chain |
40 | Supply-Chain-Review vor v1.0.0-GA-Audit | 1h Decision |
7-4-04 KNOWN_ACTIONS-Drift |
55 | Beim Block 13/14-Start mitnehmen | 1h |
7-4-05 Playwright workers: 1 |
40 | Trigger >50 Specs (heute 8 Specs) | – |
| Platform-03 File-Write-Hook eval | 20 | Externe Claude-Code-Hook-Config, kein Repo-Code | 0h |
3 Pfad-D-Total (Cleanup-Welle)¶
3.1 Roh-Aufwand pro Cluster¶
| Cluster | Familien | Aktive TODOs | Roh-h |
|---|---|---|---|
| D1 — Frontend Polish (UX/A11y/Cosmetic) | 7.1b + 7.2 + 7-3-Frontend-Anteil + 7-4-Frontend-Anteil | ~15 | ~14h |
| D2 — Backend Polish (DB-Hygiene, Audit, Service-Layer) | 7.1a + 5e/5f/5g + 7-3-Backend-Anteil + 7-4-Backend-Anteil | ~13 | ~23h |
| Pfad-D Roh-Summe (D1+D2) | ~28 | ~37h |
Aufteilung 7.3/7.4 in Frontend/Backend:
- 7.3 Frontend (-04, -05, -06, -07): ~3h
- 7.3 Backend (-02, -03): ~3.75h
- 7.4 Frontend (-08 in -01 gebündelt, -05 D3): 0h aktiv
- 7.4 Backend (-01, -02, -03, -06, -07): ~5.75h
→ D1 Frontend: 7.1b 5.75h + 7.2 6.5h + 7.3-FE 3h ≈ 15.25h
→ D2 Backend: 7.1a 9h + 5e/5f/5g 3.5h + 7.3-BE 3.75h + 7.4-BE 5.75h ≈ 22h
→ Pfad-D Roh-Summe: ~37h
3.2 Real-Aufwand mit Pattern-Reife-Quote¶
Erwartete Quote: ~60% (Block-8-Niveau, weil Cleanup-Wellen typischerweise viele Single-File-Fixes mit etablierten Patterns sind — keine neuen Foundations wie Block 11).
| Roh | Quote | Real | |
|---|---|---|---|
| D1 Frontend | ~15h | 60% | ~9h |
| D2 Backend | ~22h | 60% | ~13h |
| Pfad-D Real-Summe | ~37h | 60% | ~22h |
3.3 Cluster-Empfehlung¶
Empfehlung: Pfad-D als zwei separate Sub-Branches, nicht als ein Mega-Cleanup-Branch. Begründung:
- D1 (Frontend) und D2 (Backend) sind orthogonal — kein Pattern teilt sich Backend-Migration mit Frontend-A11y.
- Reviewable-Größe: Ein 37h-Roh-Diff ist Review-feindlich (vgl. Block 8.4 Review-Friction bei großen Diffs). Zwei ~10h-Diffs sind sauber abnehmbar.
- Bundling-Synergien innerhalb der Cluster sind klar:
- D2: 7-NN-04 + 5g teilen die
updated_at-Migration - D1: 7-1b-07 + 7-2-07 teilen den Trim-Helper
- D2: 7-4-01 + 7-4-08 teilen die Bulk-Cap-UI
- D2: 7-NN-04 + 5g teilen die
Sub-Branch-Naming-Vorschlag:
chore/cleanup-welle-d1-frontend-polish(~9h Real, ~15 TODOs)chore/cleanup-welle-d2-backend-polish(~13h Real, ~13 TODOs)
Beide einzeln gegen platform/v1.0.0 mergen, dann v1.3.0-Tag.
4 Strategie-Empfehlung für Strategie-Pause-Diskussion¶
4.1 Pfad-Vergleichs-Matrix¶
| Pfad | Aufwand (Real) | Marketing-Wert | Tech-Debt-Reduktion | Voraussetzungen |
|---|---|---|---|---|
| B — Block 13 (Connectors) | ~30–40h Refined | Hoch (Konnektor-Marketing) | Niedrig (eher neue Schuld) | Connector-SDK-Konzept stabil |
| C — Block 12 (Provisioning) | ~30–40h Refined | Mittel (Tenant-Onboarding) | Mittel (Lifecycle-Service) | Pakete/Limits (D3 7-3-01) muss mit |
| D — Cleanup-Welle (D1+D2) | ~22h Real | Niedrig (intern) | Hoch (~28 TODOs weg) | Keine Vorarbeit nötig |
| E — Operator-UI Per-Chatbot-Page | ~6–8h Refined | Mittel (Operator-Friction-Reduktion) | Niedrig | Discovery-Datapoint aus v1.2.0-Run |
4.2 Reihenfolge-Vorschlag¶
Empfehlung A — Cleanup-First: Pfad D vor Pfad B. Begründung:
- Block 13 (Connectors) wird neue Audit-Actions, neue Frontend-Pages und neue Backend-Routen mitbringen. Ein Cleanup vor Block 13 reduziert das Tech-Debt-Fundament, auf dem Block 13 baut. Insbesondere
- 7-NN-01 (Operator-Route-Vereinheitlichung) — Block 13 wird weitere Operator-Routen anlegen, jetzt zentralen Helper bauen ist günstiger als später nachziehen.
- 7-4-04 (
KNOWN_ACTIONS-Drift) — Block 13 ergänzt das Dropdown natürlich; aber die Backend-Endpoint-Variante aus dem Fix-Pfad (GET /api/v1/platform/audit/known-actionsDISTINCT-Query) wäre ideal vor Block 13 schon da, statt mit Block 13 zwei Patterns zu pflegen. - 22h Real ist eine kompakte 2-Wochen-Sprint-Größe, klar abgrenzbar. Block 13 würde 30–40h und mehrere Konzept-Entscheidungen brauchen.
- Pfad E (~6–8h) lässt sich opportunistisch in D1 oder als eigener D1.5-Sub-Branch direkt nach D1 erledigen — Frontend-Cluster sowieso.
Empfehlung B — Marketing-First: Pfad B vor Pfad D, falls Konnektor-Demos für Vertrieb dringender sind als interne Schuld-Reduktion. Risiko: Block 13 baut auf doppelten Patterns (lokale Scope-Guards, etc.).
4.3 Konkrete Vorschläge für die Strategie-Pause¶
- Default-Empfehlung: Pfad D in Reihenfolge D2 → D1 → E (≈22h D + 7h E = ~29h Real, ein Sprint), dann Pfad B (Block 13). Begründung: D2 entzerrt Block 13's Backend-Foundation, D1 polished das, was Block 13 als Operator-UI-Erweiterung sieht, E räumt einen bekannten Friction-Punkt aus dem v1.2.0-Run ab.
- Falls Strategie-Pause kürzer: Nur D2 (~13h Real) ziehen — die Backend-Hygiene ist das, was Block 13 strukturell braucht. D1+E können nach Block 13 als kosmetische Welle nachkommen.
- Falls Strategie-Pause länger: Pfad-D komplett + Pfad E + Auth-NEU (D3-Item, 1.5h Pflicht-Anteil ohne den optionalen Backfill) ≈ ~31h Real. Auth-Stack-Drift ist die einzige D3-Position, die sich eigenständig lohnt (alle anderen sind an spätere Blöcke gekoppelt).
4.4 Cluster-D3-Behandlung (nicht in Pfad D)¶
Bewusst nicht in Pfad D:
- 4b Qdrant-Backup ist ein eigener 8–12h-Block mit Konzept-Anteil (Snapshots, Storage, Restore-Runbook) — größer als die meisten D1/D2-Items zusammen. Sollte nach v1.3.0 als „Block 4-Backup" geplant werden, oder vor dem ersten Prod-Tenant-Onboarding (= vor Pfad C).
- 7-3-01 Pakete/Tier/Limits wartet sinnvollerweise auf Block 12, weil Limits-Enforcement nur dort echte UX-Wirkung hat.
- Platform-11/-12 sind Block-14-CI-Voraussetzungen — sinnlos früher zu lösen, weil ohne CI-Runner kein Validierungs-Konsument existiert.
- Auth-NEU kann in Pfad D mitgenommen werden (s. Empfehlung 3), ist aber nicht Cleanup-typisch — daher als optional markiert.
5 Discovery-Datapoints (zusammengefasst)¶
| # | Datapoint | Konsequenz |
|---|---|---|
| 1 | Inventur-Drift +11 TODOs / +4 Familien gegen Prompt-Annahme | Pfad-D-Aufwand-Schätzung im Prompt war zu niedrig — siehe §3.2 |
| 2 | Block 7.1a wurde im Prompt vergessen (eigene 7-NN-Familie unter „Block 7"-Naming-Kollision) | TODO-Inventur-Skript vor jeder Cleanup-Welle nötig |
| 3 | Familie 7.4 hat 8 TODOs, davon 1 schon Block-11-erledigt — größte aktive Familie | D2-Backend-Cluster wird primär von 7.4 getrieben |
| 4 | 5g + 7-NN-04 lassen sich in einer Migration bündeln | Sub-Branch-Naming sollte das andeuten |
| 5 | 7-1b-07 + 7-2-07 lassen sich in einem Trim-Helper bündeln | D1-Frontend-Cluster |
| 6 | 7-4-01 + 7-4-08 lassen sich in einem Bulk-Cap-Refactor bündeln | D2-Backend-Cluster |
| 7 | Pattern-Reife-Quote für reine Cleanup-Wellen erwartbar 60% (Block-8-Niveau) | 37h Roh → 22h Real |
| 8 | Pfad E (Operator-UI Per-Chatbot-Page) ist orthogonal zur Cleanup-Welle, lässt sich opportunistisch ankoppeln | Empfehlung A bündelt D2 → D1 → E |
6 Verworfene Cleanup-Optionen (für Nachvollziehbarkeit)¶
- Mega-Cleanup als ein Branch (~37h Roh / ~22h Real): Verworfen wegen Review-Friction. Die Cluster-Trennung D1 vs. D2 ist sauber genug, dass zwei Branches die Reviewbarkeit dramatisch verbessern.
- Cleanup nach Block 13: Verworfen, weil Block 13 die Tech-Debt vergrößert (neue Routen, neue Audit-Actions) und damit die Cleanup-Welle rückwirkend größer macht.
- Pfad D komplett überspringen, direkt Block 13: Möglich (Pfad B direkt), aber siehe §4.2 Empfehlung A — jeder Tech-Debt-Block, der nicht vorab gelöst wird, repliziert sich in Block 13.
7 Quellen¶
offene-todos.mdStand 2026-05-01 (48####-Einträge, davon 6 archiviert/verworfen → 42 aktiv)releases/v1.2.0.md§„Was kommt als Nächstes"roadmap.mdStrategie-Pause v1.2.0 mit Pfad B/C/D/E- Block-11-Hand-off (Merge
149c699, Hash-Sync4e8dd60) für Pattern- Reife-Quote-Referenz (40% Quote bei Block 11 mit Branding-Foundation; 60%-Quote-Erwartung für reine Cleanup-Wellen ist konservativer)