Zum Inhalt

Customer-Handbuch Befüllungs-Plan

Erstellt: 2026-05-10 (Karte C — Customer-Handbuch-Plan) Stand: Post-A2-Merge (14986ca), Post-Reorg-3, Post-Backlog-Inventur (Karte B) Zweck: Inhalts-Plan für die Befüllung der 26 Customer-Handbuch-Stub-Pages aus Reorg-3.

Diese Seite ist kein Customer-Handbuch-Inhalt — sie ist der Befüllungs- Plan. Inhalte schreiben die C-Sub-Karten (C-1 bis C-4). Stub-Pages aus Reorg-3 sind der Befüllungs-Rahmen; diese Plan-Karte klassifiziert sie nach Befüllungs-Reife und priorisiert die Sub-Karten-Sequenz.

Executive Summary

Cluster Pages Aufwand-Range Trigger
✅ A Sofort befüllbar 16 ~28–45h Feature heute funktional
🚧 B Teil-befüllbar 7 ~7–13h Stand dokumentieren + Pending-Hinweise
⏳ C Wartet auf Backlog 2 ~1–2h Coming-Soon mit Backlog-Verlink
🔒 D Strategisch vertagt 1 ~0.5–1h v1.1.0+ Coming-Soon
Total 26 ~37–61h (auf 4–5 Sub-Karten verteilt)

Realistisches Total ~37–61h statt Karte-B-Schätzung 81–120h, weil Cluster-Disposition (nicht alle Pages werden voll befüllt — Cluster C+D bleiben Coming-Soon-Stubs).

Reihenfolge:

  1. C-1 Endnutzer-Section (höchste Schmerz-Sichtbarkeit für externe Konsumenten)
  2. C-2 Admin-Core-Section (Tenant-Admin-Workflows)
  3. C-3 Admin-Mid-Section (Branding/Feedback/Audit/Sessions/Analytics/Rollen/Einstellungen)
  4. C-4 Developer-Section (API-Reference + Coming-Soon)
  5. C-5 Customer-Reviewer-Smoke (Pre-Launch Validation, optional)

Phase 0.1 — Stub-Pages-Inventur (aus Reorg-3)

Endnutzer (8): index, erste-schritte, bedienung, datenschutz, grenzen, sprachen, faq, support

Administratoren (14): index, erste-anmeldung, dashboard, chatbots, dokumente, templates, branding, audit-log, feedback, sessions, evaluation, analytics, rollen-und-berechtigungen, einstellungen

Entwickler (4): index, api-reference, sdk, webhooks

Skelett-Format pro Page (aus Reorg-3): Title + 🚧 STUB-Badge + 2–4 H2-Sections + TODO-Karte-C-N-Marker + Pattern-Vorlage-Verweis auf AVS-Handbuch + Befüllungs-Plan-Verweis.

Phase 0.2 — Feature-Inventur

Pro Page klassifiziert nach Feature-Verfügbarkeit heute (Frontend sichtbar + Backend funktional):

Kategorie Heute funktional
Chat-Widget (öffentlich) ✅
Chatbot-CRUD (Tenant-self) ✅ ChatbotsListPage / CreatePage / DetailPage / EditPage
Doc-Upload + Status-Polling ✅ A1+A2 abgeschlossen 2026-05-10
Chatbot-Branding + Tenant-Branding ✅ ChatbotBrandingPage + TenantBrandingPage
Chatbot-Feedback (Tenant-Read) ✅ ChatbotFeedbackPage
Modules (Tenant-Toggle) ✅ ModulesPage
Templates (Tenant-Auswahl) ✅ TemplatesPage
Dashboard (Operator-Übersicht) ✅ DashboardPage
User-Preferences (Profile) ✅ ProfilePage + Theme
Keycloak-SSO + Bootstrap ✅ CallbackPage + Login-Flow
3-Rollen-Modell (tenant-admin/-editor/-viewer) 🚧 Backend ja, UI für User-Provisioning kommt mit Block 17
Audit-Log Per-Tenant-Export 🚧 Backend-Schema ja, Export-Route ist DSGVO-1 pending
Sessions-View 🚧 ChatHistoryService existing, Tenant-UI fehlt
Analytics-Dashboard 🚧 Prometheus+Grafana existing, kein Tenant-Self-UI
Evaluation-UI ⏳ Eval-Suite existing, kein UI vor Block 13/14
Konnektor-SDK ⏳ Stufe 2 mit Block 16; Stufe 3 ist Backlog langfristig
Webhooks 🔒 v1.1.0+
STT/TTS 🔒 v1.1.0+ (Backlog)

Phase 1 — Cluster-Klassifikation pro Page

✅ Cluster A — Sofort befüllbar (16 Pages, ~28–45h)

Page Aufwand Begründung
enduser/index 1h Section-Übersicht
enduser/erste-schritte 2–3h Widget-Live-Workflow + Screenshot
enduser/bedienung 2–3h Chat-UI, Sources-Chips, Feedback
enduser/datenschutz 2h DSGVO-Stand: Tenant-Isolation per RLS, Aufbewahrungsfristen, Rechte
enduser/grenzen 2h No-Match-Pfad, Halluzinations-Risiko, Eskalation
enduser/faq 2h Standard-FAQ-Sammlung aus AVS-Pattern
enduser/support 1–2h Eskalations-Stufen Tenant → luki
admin/index 1h Section-Übersicht
admin/erste-anmeldung 1–2h Keycloak-SSO + Bootstrap
admin/dashboard 2h DashboardPage-Workflow + Per-Chatbot-Cards
admin/chatbots 2–3h Lifecycle (Create + Edit + Soft-Delete)
admin/dokumente 2–3h Upload-Workflow (A1+A2 frisch live)
admin/branding 2h Tenant-Branding + Chatbot-Override
admin/feedback 2h Feedback-Liste + Filter
developer/index 1h Section-Übersicht
developer/api-reference 4–6h OpenAPI-Auto-Gen via FastAPI-Schema + curl-Beispiele

🚧 Cluster B — Teil-befüllbar mit Pending-Hinweis (7 Pages, ~7–13h)

Page Aufwand Pending-Verlink
enduser/sprachen 1h DE/EN heute, STT/TTS pending → Backlog Tudidi #12/#13
admin/templates 1–2h Tenant-Auswahl heute, Vendor-Templates kommen mit Block 10
admin/audit-log 1–2h Operator-Read heute, Per-Tenant-Export pending → Backlog Karte 4 (DSGVO-1)
admin/sessions 1–2h History-Service existing, Tenant-UI pending
admin/analytics 1–2h Operator-Grafana, Tenant-Self-UI pending
admin/rollen-und-berechtigungen 1–2h 3-Rollen-Modell heute, User-Provisioning kommt mit Block 17
admin/einstellungen 1h CORS via allowed_origins, Rate-Limit Plattform-weit

⏳ Cluster C — Wartet auf Backlog (2 Pages, ~1–2h)

Page Aufwand Backlog-Item
admin/evaluation 30–60min Eval-UI ist Block 13/14-Scope
developer/sdk 30–60min SDK Stufe 2 mit Block 16; Stufe 3 langfristig

🔒 Cluster D — Strategisch vertagt (1 Page, ~0.5h)

Page Aufwand Trigger
developer/webhooks 30min v1.1.0+ (komplett pending)

Phase 2 — C-Sub-Karten-Skelette

Vier Befüllungs-Karten + eine optionale Reviewer-Karte. Max-Cap pro Sub-Karte ist Saga-Lehre-13-konform (kein Mega-Cap).

C-1 — Endnutzer-Section befüllen

name: customer-handbuch-c1-enduser
klasse: Customer-Handbuch-Befüllung
scope: |
  Alle 8 Endnutzer-Stub-Pages aus Reorg-3 mit Customer-Inhalt befüllen.
  enduser/{index,erste-schritte,bedienung,datenschutz,grenzen,sprachen,
  faq,support}. Screenshots aus dem Live-Widget (demo.avs.luki-net.org
  oder kora-platform-demo-frontend). Pattern-Vorlage AVS-Handbuch
  generalisiert. sprachen.md mit STT/TTS-pending-Hinweis (Cluster B).
aufwand_schaetzung: 12-20h Real (Cluster A ~10-14h + sprachen 1h)
abhaengigkeiten: keine — Widget ist live, Backend-Routes existing
risiko: niedrig (kein Code, Inhalts-Schreiben)
saga_lehren_anwendbar: [13 (Cap-Disziplin)]
validation:
  - mkdocs build --strict 0 neue Warnings
  - 1 externer Leser (z.B. AVS-Stakeholder) liest und versteht ohne Rückfragen
  - alle Screenshots aktuell (DE-Widget)
stop_bedingungen:
  - Widget-UI ändert sich vor C-1-Merge → Screenshots veraltet, Refresh
akut_indikator: 🔴 (höchste Schmerz-Sichtbarkeit, externe Konsumenten)

C-2 — Admin-Core-Section befüllen

name: customer-handbuch-c2-admin-core
klasse: Customer-Handbuch-Befüllung
scope: |
  5 Cluster-A-Pages der Admin-Section befüllen:
  admin/{index,erste-anmeldung,dashboard,chatbots,dokumente}.
  Workflow-Doku mit Screenshots aus Tenant-UI. Doc-Upload-Workflow
  (admin/dokumente) profitiert direkt von A1+A2 — kompletter Pfad
  Upload → Polling → Erfolg dokumentierbar.
aufwand_schaetzung: 10-15h Real
abhaengigkeiten:
  - Doc-Upload-Saga (A1 + A2) ✅
  - Tenant-UI deployed mit allen 5 Pages ✅
risiko: niedrig
saga_lehren_anwendbar: [13]
validation:
  - mkdocs build --strict 0 Warnings
  - Workflow-Smoke: Externer Tester folgt Guide → Erste Chatbot-Erstellung + Doc-Upload klappt
  - Screenshots stabil (Tenant-UI v1.3 ist Branch-tagged)
stop_bedingungen:
  - Tenant-UI-Pattern-Drift während C-2-Schreibung
akut_indikator: 🔴 (Tenant-Admin-Onboarding-Pfad, höchste Customer-Wert)

C-3 — Admin-Mid-Section + Pending-Hinweise

name: customer-handbuch-c3-admin-mid
klasse: Customer-Handbuch-Befüllung
scope: |
  8 Pages: 2 Cluster A (branding, feedback) + 6 Cluster B (templates,
  audit-log, sessions, analytics, rollen-und-berechtigungen, einstellungen).
  Cluster-B-Pages haben dokumentierten Stand + Pending-Hinweise mit
  Verlink in Backlog-Page bzw. Roadmap-Block.
aufwand_schaetzung: 8-13h Real
abhaengigkeiten:
  - admin/audit-log: DSGVO-1 als Karte 4 in Backlog (pending, nicht blockierend für Doku)
  - admin/rollen: Block 17 (Post-Launch v1.0.1) — Hinweis genügt
risiko: niedrig-mittel (Cluster-B-Pages müssen ehrlich pending markieren)
saga_lehren_anwendbar: [13]
validation:
  - mkdocs build --strict 0 Warnings
  - Pending-Hinweise verlinken korrekt zu Backlog-Karte oder Roadmap-Block
stop_bedingungen:
  - Pending-Verlinkung zu Backlog-Karte schlägt fehl (Anchor-Drift)
akut_indikator: 🟠 (Customer-Wert mittel, Ehrlichkeits-Pflicht hoch)

C-4 — Developer-Section + Cluster-C+D-Stubs

name: customer-handbuch-c4-developer
klasse: Customer-Handbuch-Befüllung
scope: |
  4 Developer-Pages plus 3 Cluster-C/D-Stub-Pflege:
  - developer/index (Übersicht, Cluster A)
  - developer/api-reference (Cluster A, OpenAPI-Auto-Gen wenn möglich)
  - developer/sdk (Cluster C — Stufe 2 mit Block 16, Coming Soon)
  - developer/webhooks (Cluster D — v1.1.0+, Coming Soon)
  OpenAPI-Generator-Setup ist optional (Mehr-Aufwand) — Fallback
  manuell-curated Endpoint-Liste.
aufwand_schaetzung: 5-8h Real (4-6h api-ref bei Auto-Gen, sonst 6-8h manuell)
abhaengigkeiten: FastAPI-OpenAPI-Schema ist stabil (heute ja)
risiko: niedrig
saga_lehren_anwendbar: [13]
validation:
  - mkdocs build --strict 0 Warnings
  - api-reference matcht echtes /openapi.json
  - Coming-Soon-Stubs verlinken Backlog-Karten
stop_bedingungen:
  - OpenAPI-Schema-Drift während Karten-Run → Auto-Gen-Strategie wechseln
akut_indikator: 🟠 (kleinste Zielgruppe, kann später)

C-5 — Customer-Reviewer-Smoke (optional, Pre-Launch)

name: customer-handbuch-c5-reviewer-smoke
klasse: Pre-Launch-Validation
scope: |
  Externer Reviewer (AVS-Stakeholder oder zukünftiger Test-Tenant)
  liest komplette Customer-Sections nach C-1 bis C-4. Feedback wird
  in C-1-Refresh / C-2-Refresh / etc. zurückgespielt.
aufwand_schaetzung: 2-3h Vorbereitung + Reviewer-Time asynchron
abhaengigkeiten: C-1 bis C-4 abgeschlossen
risiko: niedrig
saga_lehren_anwendbar: [1 (Phase-0-Discovery — Reviewer-Insights vor Launch)]
validation:
  - 1-2 externe Reviewer-Sessions
  - Feedback strukturiert in Refresh-Sub-Karten
stop_bedingungen:
  - Reviewer-Feedback zeigt fundamentalen Strukturfehler → Karten-Refresh
akut_indikator: 🟡 (Pre-Launch-Polish, optional)

Aufwand-Bilanz

Sub-Karte Pages Real-Range Akut
C-1 Endnutzer 8 (7A + 1B) 12–20h 🔴
C-2 Admin-Core 5 (5A) 10–15h 🔴
C-3 Admin-Mid 8 (2A + 6B) 8–13h 🟠
C-4 Developer + Stubs 7 (2A + 2C + 1D + 2 Stubs aus C/D) 5–8h 🟠
C-5 Reviewer (optional) – 2–3h 🟡
Total 26+ ~37–59h

Kalibrierung gegen Karte-B-Schätzung (~81–120h): Cluster-Disposition spart ~30–60h Aufwand gegen Voll-Befüllung der 26 Pages. Cluster B/C/D bleiben Pending-Hinweis-Stubs, nicht Voll-Inhalt — das ist ehrlich gegenüber externen Konsumenten und nicht-frustrationsproduzierend.

Reihenfolge und Abhängigkeiten

                       Reorg-3 (26 Stubs)
                              │
                              ▼
                  ┌──── Backlog-Inventur (Karte B) ────┐
                  │                                    │
                  ▼                                    ▼
        Doc-Upload-Saga (A1+A2)              Pending-Verweise
              ✅ abgeschlossen                  in Cluster B/C/D
                  │
                  ▼
   ┌── C-1 Endnutzer (🔴) ───┐
   │       12-20h            │
   └─────────┬───────────────┘
             │
             ▼
   ┌── C-2 Admin-Core (🔴) ──┐
   │       10-15h            │  ← profitiert von A1+A2 für admin/dokumente
   └─────────┬───────────────┘
             │
             ▼
   ┌── C-3 Admin-Mid (🟠) ───┐
   │       8-13h             │  ← verweist auf DSGVO-1 etc. aus Backlog
   └─────────┬───────────────┘
             │
             ▼
   ┌── C-4 Developer (🟠) ───┐
   │       5-8h              │
   └─────────┬───────────────┘
             │
             ▼
   ┌── C-5 Reviewer (🟡) ────┐
   │       optional 2-3h     │
   └─────────────────────────┘

Parallelisierungs-Pfad: C-1, C-2 und C-3 können vom selben Autor sequentiell abgearbeitet werden (jeweils im Cap-Korridor) — keine technische Parallelisierung nötig.

Karte D Konsolidierungs-Roadmap-Synthese ist nicht abhängig — sie kann parallel laufen (Tudidi-Synchronisation + Cleanup).

Verhältnis zu existierender Doku

  • Reorg-3 (Merge 9b05330) — liefert 26 Stub-Pages als Befüllungs-Rahmen
  • Karte B (audit-trail/backlog/index.md) — liefert Backlog-Items für Pending-Verlinkungen aus Cluster B/C/D
  • Doc-Upload-Saga (Pre-Flight 27a576d + A1 8b1512c + A2 14986ca) — schaltet admin/dokumente für Voll-Befüllung in C-2 frei
  • AVS-Handbuch (docs.avs.luki-net.org/handbuch/) — Pattern-Vorlage für Customer-Sprache und Workflow-Struktur (zu generalisieren in Sub-Karten)
  • Konnektor-Roadmap + Multi-Tenancy-Fundament — Quellen für Pending-Verlinkungen in Cluster B/D

Was dieser Plan nicht ist

  • Kein Customer-Handbuch-Inhalt — Inhalts-Schreiben passiert in C-1 bis C-4
  • Kein Reorg-3-Ersatz — Stub-Pages bleiben als Befüllungs-Rahmen
  • Kein Karte-B-Backlog-Ersatz — Backlog-Page bleibt authoritativ für offene Items
  • Keine Sub-Karten-Tudidi-Anlage — Tudidi-Tasks legt Browser-Claude nach Plan-Karten-Merge an (analog Karte-B-Top-8-Setup)

Pattern: Saga-Lehre 1 (Phase-0-Discovery: Stub-Inventur + Feature-Mapping vor Karten-Schnitt), Saga-Lehre 13 (Cluster-Disposition statt Voll-Befüllung). Befüllungs-Plan: 4–5 Sub-Karten verteilt auf ~37–59h real, im Korridor der Karte-B-Schätzung dank Cluster-B/C/D-Pending-Pflege.