Konsolidierungs-Roadmap — Drei-Track-Synthese¶

Erstellt: 2026-05-11 (Karte D — Konsolidierungs-Roadmap + Tudidi-Format-Synthese) Stand: Post-Karte-C-Merge (22b8a60), Post-Doc-Upload-Saga, Post-Reorg-3, Post-Backlog-Inventur Zweck: Single-Source-of-Truth für die Karten-Sequenz der nächsten 3–6 Monate.

Diese Seite synthetisiert die existing Pläne (IA-Audit, Reorg, Backlog, Customer-Handbuch, SaaS-Detail, Doc-Upload-Pre-Flight) zu einer drei-Track-Roadmap. Sie ist die Eintritts-Bedingung für die SaaS-Phase (Karte E) und der Übergang aus der Plan-Phase (Karten B/C/D) in die Umsetzungs-Phase.

Executive Summary¶

Track	Karten	Real-Range	Customer-Wert
Track 1 Customer-Handbuch	5 (C-1 … C-5)	37–59h	Customer-Launch-Voraussetzung
Track 2a SaaS-Foundation	4 (CI-1, DSGVO-1/2/3)	17–27h	DSGVO-Compliance + Multi-Tenant-Pentest
Track 2b SaaS-Sub-Karten	11 (B-9/10/12 + C-19.5/20 + C-13/13b + D-14/15/16 + E-17)	~130–200h	SaaS-Launch-Voraussetzung
Track 3 Operational + Cleanup	~5 Karten	~5–10h	Tooling-Reife (parallel)
Total bis v1.0.0-Launch	~25 Karten	~190–296h Real	Customer + SaaS Production-Ready

Plan-Phase abgeschlossen mit Karte D. Ab jetzt: Umsetzungs-Karten.

Nächste konkrete Karte: C-1 Endnutzer-Section (~12–20h Real).

Phase 0 — Status-Inventur¶

Existing Pläne (6)¶

Plan	Pfad	Status
IA-Audit 2026-05-09	`methodik/doku-ia-audit-2026-05-09.md`	✅
Reorg-Sequenz 1+2+3	drei Merges (`559600e`, `9a3eb8e`, `9b05330`)	✅
Backlog-Inventur (Karte B)	`audit-trail/backlog/index.md`	✅
SaaS-Detail-Plan	`architektur/v1-0-0-saas-detail-plan.md`	✅
Customer-Handbuch-Plan (Karte C)	`methodik/customer-handbuch-plan.md`	✅
Doc-Upload Pre-Flight (Karte A)	`audit-trail/discovery/doc-upload-ui-pre-flight.md`	✅

Tudidi-Stand (Saga-Reporting)¶

Item	Wert
Tasks Total	~55 (44 vor Saga + 11 in Saga neu angelegt #46–#55)
Completed	3 (#27, #39, #46 + #48 manuell)
Pending	~52
Heute fällig	0
Due-this-week	1 (#47 Block-18 Backup-Cleanup, 2026-05-16)

Saga-Karten bisher¶

Aus Git-Log (rückwärts chronologisch, post-Reorg-3):

Karte B Backlog-Inventur (592ba9c, ~70min)
Block-19 Tag-7 Observation (64aa9c8, ~25min)
Doc-Upload Pre-Flight Stop (27a576d, ~30min)
Doc-Upload A1 Backend (8b1512c, ~3h)
Doc-Upload A2 UI (14986ca, ~2h)
Karte C Customer-Handbuch-Plan (22b8a60, ~50min)
Karte D Konsolidierungs-Roadmap (diese Karte, ~70min geplant)

Total Konsolidierungs-Phase ~11.4h auf 7 Karten (Saga-Lehre 13: 6× unter Cap in Folge, kumulierter Durchschnitt −60%).

Phase 1 — Drei-Track-Synthese¶

Track 1 — Customer-Handbuch (sequentiell, Inhalts-Schreiben)¶

C-1 Endnutzer-Section (12-20h, 🔴)
        ↓
C-2 Admin-Core-Section (10-15h, 🔴)
        ↓
C-3 Admin-Mid-Section (8-13h, 🟠)
        ↓
C-4 Developer-Section (5-8h, 🟠)
        ↓
C-5 Customer-Reviewer-Smoke (2-3h, 🟡, optional)

Voraussetzungen: Reorg-3 ✅ (Stub-Pages da), A1+A2 ✅ (admin/dokumente befüllbar). Keine Code-Abhängigkeit zu Track 2.

Trigger: Customer-Launch-Ready ist Voraussetzung für externe Stakeholder (AVS-Kurverwaltungen). Karte C ist Plan-Page; C-1 bis C-5 sind die Befüllungs-Karten.

Track 2 — SaaS-Multi-Tenancy¶

Track 2a — SaaS-Foundation (4 Karten, Foundation-Reuse hoch)¶

CI-1 Multi-Tenant-Pentest (3-5h, 🟠)
        ↓
DSGVO-1 Per-Tenant-Audit-Export (3-5h, 🟠)
        ↓
DSGVO-2 Hard-Delete-Pfad (5-7h, 🟠)
        ↓
DSGVO-3 Per-Tenant-Daten-Export (6-10h, 🟠)

Voraussetzungen: Defense-in-Depth-Saga ✅ (Pentest-Suite v1.0 existing), Block 1 ✅ (Audit-Tabellen), Block 8 ✅ (Tenant-Data-Foundation).

Trigger: DSGVO-Compliance-Pflicht für v1.0.0-SaaS-Launch. Diese 4 Karten haben kleinstmöglichen Aufwand für höchsten Compliance-Hebel.

Track 2b — SaaS-Sub-Karten (11 Karten, Roadmap-Blöcke)¶

Aus architektur/v1-0-0-saas-detail-plan.md:

Sub-Karte	Refined	Real-Range	Akut
B-9 Vendor-UI	24h	12–18h	🟠
B-10 System-Prompt-Automatismus	16h	8–12h	🟠
B-12 Provisioning-Automatisierung	14h	9–14h	🟠 (Block für D-15)
C-19.5 Reranker-Upgrade	6h	4–6h	🟡 (BGE-stack-Konsistenz)
C-20 AST-Aware Chunking	13h	7–13h	🟡
C-13 Konnektor-Framework	57h	28–46h	🟠 (größter Block)
C-13b Confluence-Konnektor	10–25h	8–20h	🟠
D-14 Deployment-Paket	20h	10–16h	🟠
D-15 Migration & Go-Live	12h	7–11h	🟠
D-16 Testing & Doku	30h	15–25h	🟠
E-17 Tenant-SSO-Self-Service	49h	n/a	⏳ Post-Launch

Total Track 2b ~120–200h Real (E-17 ist Post-Launch und nicht im v1.0.0-Boden).

Track 3 — Operational + Backlog-Cleanup (parallel, kein Block)¶

Aus Backlog-Inventur + Saga-Lehren der letzten Karten:

Item	Aufwand	Trigger
Block-18 Backup-Cleanup	5min	2026-05-16
Backlog-Triage-Mini (Hochstufungen + neue Items)	15–20min	jederzeit
MCP-Fork-Bugfix für tudidi `complete_task`	n/a	falls priorisiert
TODO-Platform-11/12 (alembic-CLI im Container)	~2h	bei 5+ Code-Karten kumuliert
TODO-Block-19-Tooling (tests-Mount)	~2h	CI-Drift-Risiko
TODO-Block-19-5 Reranker-Upgrade	~4–6h	nach Tag-7 freigegeben
Phase-5 Edge-Case-Queries q026–q035	~2–3h	nach Tag-7 freigegeben

Total Track 3 ~10–15h, läuft als Hintergrund-Sprint pro freier Slot.

Phase 1.2 — Abhängigkeits-Graph¶

        Reorg-3 ✅ ──→ ┌─ C-1 ─┐
                       │       │
        A1+A2 ✅ ──────→├─ C-2 ─┼──→ Customer-Launch-Ready
                       │       │
                       ├─ C-3 ─┤
                       │       │
                       └─ C-4 ─┘
                                       (Tracks parallel)
        Defense-Saga ✅ ─→┌─ CI-1 ──┐
        Block 1 ✅ ────────→├─ DSGVO ─┼──→ SaaS-Foundation-Ready
        Block 8 ✅ ────────→└─────────┘
                                       │
                                       ▼
                                B-9 / B-10 / B-12 / C-13 / C-13b
                                  / C-19.5 / C-20 / D-14 / D-15 / D-16
                                       │
                                       ▼
                                  SaaS-Launch-Ready ─→ v1.0.0 Tag

        Track 3 (Operational): Backlog-Cleanup / Tooling — kein Block für Track 1/2

Abhängigkeits-Klassen:

Track 1 → Track 2: keine. Customer-Doku ist nicht-blockierend für SaaS-Code.
Track 2 → Track 1: indirekt — SaaS-Code-Karten können Customer-Doku-Refresh erzeugen (Cluster B in C-3).
Track 3 → Track 1/2: Operational-Items wie tests-Mount beschleunigen 1+2, blockieren aber nicht.
Track 1 ↔ Track 2: Customer-Launch ≠ SaaS-Launch — beides sind unabhängige Meilensteine.

Phase 1.3 — Empfohlene Karten-Reihenfolge¶

Bei sequenzieller Saga-Disposition (aktueller Lutz-Modus, ein-Karte-zur-Zeit):

#	Karte	Track	Real	Trigger
1	Karte D Konsolidierung	Plan	~70min	jetzt
2	C-1 Endnutzer-Section	T1	12–20h	höchste Customer-Sichtbarkeit
3	CI-1 Multi-Tenant-Pentest	T2a	3–5h	Foundation-Reuse-Win
4	C-2 Admin-Core-Section	T1	10–15h	Doc-Upload dokumentierbar
5	DSGVO-1 Audit-Export	T2a	3–5h	DSGVO Art. 30, kleinste DSGVO-Karte
6	Block-18 Backup-Cleanup	T3	5min	2026-05-16
7	C-3 Admin-Mid-Section	T1	8–13h	Pending-Hinweise verlinkt
8	DSGVO-2 Hard-Delete	T2a	5–7h	DSGVO Art. 17
9	C-4 Developer-Section	T1	5–8h	OpenAPI-Auto-Gen wenn möglich
10	DSGVO-3 Daten-Export	T2a	6–10h	DSGVO Art. 20
11	C-5 Reviewer-Smoke (optional)	T1	2–3h	Pre-Launch-Validation
12+	→ SaaS-Sub-Karten-Sequenz	T2b	~120–200h	beginnt nach Customer-Launch-Ready

Total bis Customer-Launch-Ready: ~50–80h (Karten 1–11). Total bis SaaS-Launch-Ready: zusätzlich ~120–200h (Karten 12+).

Operational-Items (Track 3) laufen parallel als Hintergrund-Sprint zwischen den Haupt-Karten.

Phase 1.4 — Aufwand-Bilanz¶

Track	Karten	Real-Range	Customer-Wert
Track 1 Customer-Handbuch	5 (C-1 … C-5)	37–59h	Customer-Launch-Voraussetzung
Track 2a SaaS-Foundation	4 (CI-1 + 3× DSGVO)	17–27h	Compliance + Multi-Tenant-Pentest
Track 2b SaaS-Sub-Karten	11 (Roadmap-Blöcke)	~120–200h	SaaS-Launch-Voraussetzung
Track 3 Operational	~5–7 Karten	~5–15h	Tooling-Reife (parallel)
Total bis v1.0.0-Launch	~25 Karten	~180–300h Real	Customer + SaaS Production-Ready

Realistischer Korridor: ~200–250h Real auf ~25 Karten.

Phase 2 — Tudidi-Format-Konvention¶

Standardisiertes Task-Format¶

Verbindlich für künftige Saga-Karten-Tasks in Tudidi (Browser-Claude Anlage analog Karten-B-Top-8-Setup):

name: "<Karten-ID> <Kurze Beschreibung>"
  # Beispiele:
  # - "C-1 Endnutzer-Section befüllen (8 Pages)"
  # - "DSGVO-1 Per-Tenant-Audit-Export (Art. 30)"
  # - "Block-18 Backup-Cleanup"

priority: high | medium | low
  # high   → 🔴 Akut (User-Schmerzpunkt, blockiert nächste Karte, Compliance-Pflicht)
  # medium → 🟠 Strategisch (v1.0.0-Launch-Voraussetzung)
  # low    → 🟡 Nice-to-have oder 🟢 Vertagt

project_id: <existing Project>
  # Mapping (Stand 2026-05-11):
  # - Customer-Handbuch C-*  → v1.0.0 Multi-Tenancy & Production (id 1)
  # - DSGVO/CI-*            → v1.0.0 Multi-Tenancy & Production (id 1)
  # - Doku/Reorg/Plan       → Operations (id 8) oder v1.0.0 (id 1)
  # - Backend-Implementation → Phase B UIs Automation (id 6) oder
  #                            Phase C Quality Konnektoren (id 9)
  # - Security              → Security-Hardening Phase 2 (id 7)
  # - Operational           → Operations (id 8)

tags:
  - <Klasse>      # 🔧 Infra / ✨ UX / 🎯 Qualität / 💰 Umsatz / ⚡ Quick Win
  - <Optional>    # security / pentest / stream-architecture / etc.
  - follow-up     # Standard für Saga-Folge-Karten

description: |
  <Akut-Indikator + Begründung in 1-2 Sätzen>
    Beispiel: "🔴 Customer-Schmerzpunkt — admin/dokumente.md ohne
    UI-Workflow nicht ehrlich dokumentierbar. A1+A2 schaltet frei."

  **Aufwand:** <h-Range aus Karte-Plan>

  **Scope:**
  - <Bullet 1>
  - <Bullet 2>
  - ...

  **Verweis:** <Karte-Plan + Pfad zur Plan-Page>
    Beispiel: "Karte-C-Plan, methodik/customer-handbuch-plan.md §Phase 2"

  **Validation:** <wie wird Erfolg gemessen>

  **Stop-Bedingung:**
  - <Bedingung 1>
  - <Bedingung 2>

  **Saga-Lehren:** <Liste der angewendeten Saga-Lehren mit Begründung>
    Beispiel: "1 (Phase-0-Discovery vor Code), 13 (Cap-Disziplin)"

Konvention-Status der existing Saga-Tasks #46–#55¶

Task	Name-Format	Priority	Project	Tags	Description
#46 Block-19 Tag-7	✓	high	✓	✓	✓
#47 Block-18 Backup	✓	high	✓	✓	✓
#48 Doc-Upload-UI (A1+A2)	✓	high	✓	✓	✓
#49 DSGVO-1	✓	medium	✓	✓	✓
#50 CI-1	✓	medium	✓	✓	✓
#51 DSGVO-2	✓	medium	✓	✓	✓
#52 DSGVO-3	✓	medium	✓	✓	✓
#53 C-1 Endnutzer	✓	high	✓	✓	✓
#54 C-2 Admin-Core	✓	high	✓	✓	✓
#55 C-3 Admin-Mid	✓	medium	✓	✓	✓

Konvention etabliert — kein Refresh nötig. Künftige Tasks folgen diesem Format.

Bekannte MCP-Limitationen¶

complete_task ist nicht reliabel (race-condition gegen Backend). Workaround: Browser-Claude markiert via UI; Server-Sync verifiziert über list_tasks.
update_task existiert teilweise; bei Priority-Updates Browser-Claude via UI nutzen (siehe Hochstufung #36 in Phase 3).

Phase 3 — Backlog-Triage¶

Hochstufungen aus Saga-Lehren¶

Tudidi-ID	Item	Aktuell	Empfehlung	Begründung
#36	tudidi-MCP-Fork — Endpoints	🟢 low	🟠 medium	Race-Condition + 404-Bugs in `complete_task` verhindern reliable Workflow-Sync

Neue Items aus Saga-Berichten¶

Item	Project	Priority	Klasse	Begründung
TODO-Platform-11/12 (alembic-CLI im Container)	Operations (8)	medium	🔧 Infra	A1 brauchte manuellen DB-Bump; bei 5+ Code-Karten ~2.5h kumuliert
TODO-Block-19-Tooling (tests-Mount)	Operations (8)	medium	🔧 Infra	Integration-Tests nicht im Container; CI-Drift-Risiko (A1 hat das verifiziert)
TODO-Block-19-5 Reranker-Upgrade bge-reranker-v2-m3	Phase C Quality (9)	low	🎯 Qualität	Reranker-Bias dokumentiert (q006/q025), nicht regression-blocking
Phase-5 Edge-Case-Queries q026–q035	Phase C Quality (9)	low	🎯 Qualität	aus Block-19-Tag-7-Bericht freigegeben

Aktionen (Browser-Claude post-Merge)¶

Tudidi-Updates über UI (update_task MCP-fehlt): - #36 Priority low → medium

Neue Tudidi-Tasks (4): - TODO-Platform-11/12 → Operations (8), medium, 🔧 Infra - TODO-Block-19-Tooling → Operations (8), medium, 🔧 Infra - TODO-Block-19-5 → Phase C Quality (9), low, 🎯 Qualität - Phase-5 Edge-Case → Phase C Quality (9), low, 🎯 Qualität

Phase 4 — Status nach Plan-Phase¶

Plan-Phase abgeschlossen mit 7 Karten + Karte D = ~13h Wall-Clock:

Karte B Backlog-Inventur ✅
Block-19 Tag-7 Observation ✅
Doc-Upload Pre-Flight Stop ✅
Doc-Upload A1 Backend ✅
Doc-Upload A2 UI ✅
Karte C Customer-Handbuch-Plan ✅
Karte D Konsolidierungs-Roadmap ✅ (diese)

Saga-Lehre 13 zum 10. Mal validiert (bei Karte-D-Wall-Clock unter Cap).

Eintritts-Bedingungen für Umsetzungs-Phase erfüllt:

26 Stub-Pages aus Reorg-3 klassifiziert (Karte C)
~50 Backlog-Items inventarisiert + priorisiert (Karte B)
8 Top-Karten-Skelette + 5 C-Sub-Karten-Skelette (Karten B+C)
Drei-Track-Roadmap synthetisiert (Karte D)
Tudidi-Format-Konvention etabliert (Karte D)
Backlog-Triage-Hochstufungen vorbereitet (Karte D)

Nächste konkrete Karte: C-1 Endnutzer-Section befüllen (~12–20h Real, 🔴 höchste Customer-Sichtbarkeit). Tudidi-Task #53 ist angelegt und priorisiert.

Verhältnis zu existierender Doku¶

IA-Audit (methodik/doku-ia-audit-2026-05-09.md) — liefert die 47-Files-Klassifikation, identifiziert die 28 Stub-Page-Lücken die Reorg-3 dann angelegt hat.
Karte B Backlog (audit-trail/backlog/index.md) — kanonisch für alle offenen Items, 4-Klassen-Cluster (🔴/🟠/🟡/🟢).
Karte C Customer-Handbuch (methodik/customer-handbuch-plan.md) — liefert die 5 C-Sub-Karten-Skelette + Cluster-Disposition für die 26 Stub-Pages.
SaaS-Detail-Plan (architektur/v1-0-0-saas-detail-plan.md) — kanonisch für die 11 SaaS-Sub-Karten (Track 2b).
Doc-Upload Pre-Flight (audit-trail/discovery/doc-upload-ui-pre-flight.md) — Pattern für Stop-Bedingung-respektierende Karten (kein Code bei fehlender Voraussetzung).
Saga-Lehren (methodik/saga-lehren.md) — Methodik-Anker; Saga-Lehre 13 ist hier 10× hintereinander validiert.

Was dieser Plan nicht ist¶

Keine neue Inventur — alle Daten existieren in Karten A/B/C + Tudidi.
Keine Sub-Karten-Skelette für neue Karten (das war Karten B+C Phase 2).
Kein Tudidi-Backend-Bug-Fix für complete_task — separate Code-Karte (#36 hochgestuft).
Keine Konsolidierung der ~50 Backlog-Items auf granularer Ebene — Karte B ist kanonisch.
Kein Customer-Handbuch-Inhalt — Inhalts-Schreiben in C-1 bis C-5.

Pattern: Saga-Lehre 1 (Phase-0-Discovery: existing Pläne-Inventur statt neue Pläne erfinden), Saga-Lehre 13 (Synthese statt Voll-Reorg). Konsolidierungs-Phase abgeschlossen — Umsetzungs-Phase beginnt mit C-1.