Roadmap: RAG Support Desk

Milestones

• ✅ v1.0 Stable Service — Phases 1–2 (shipped 2026-03-24) → archive
• 🚧 v2.0 Channel-Based Knowledge System — Phases 3–5 (in progress)

Phases

🚧 v2.0 Channel-Based Knowledge System

• [x] Phase 3: DB + API Channel-Awareness — DB-Schema und alle API-Endpoints kennen Channels (completed 2026-03-24)
• [x] Phase 4: Channel CRUD API — Channels können per API angelegt und aufgelistet werden; reset ist channel-scoped (completed 2026-03-24)
• [ ] Phase 5: Browser UI Redesign — Crew navigiert Channels in der Sidebar und trennt Chat von Ingest in Tabs

Definition of Done (v2.0):
- Chunks sind einem Channel zugeordnet (channel_id in DB)
- Query und Ingest sind channel-aware (nur aktiver Channel durchsucht)
- Default-Channel "general" existiert als Fallback
- Channels können per API angelegt und aufgelistet werden
- POST /admin/reset ist channel-scoped (löscht nur Chunks des angegebenen Channels)
- Browser-UI zeigt Channel-Liste links, Chat/Ingest-Tabs rechts
- Aktiver Channel ist hervorgehoben und steuert Query + Ingest
- Aktiver Channel bleibt nach Seiten-Reload erhalten

Phase Details

Phase 01: Docker Compose Stack

Goal: Gesamtes System läuft containerisiert und startet mit docker compose up auf macOS ARM64 und Linux x86_64.
Milestone: v1.0 (SHIPPED 2026-03-24) — see milestones/v1.0-ROADMAP.md
Plans: 3/3 complete
Status: Complete — 2026-03-23

Phase 02: Operations & Maintenance

Goal: Betrieb und Wartung sind einfach — Health-Check, Reset, plattformunabhängiges Deployment.
Milestone: v1.0 (SHIPPED 2026-03-24) — see milestones/v1.0-ROADMAP.md
Plans: 4/4 complete
Status: Complete — 2026-03-24

Phase 3: DB + API Channel-Awareness

Goal: DB-Schema und alle API-Endpoints kennen Channels — jede Schicht akzeptiert channel_id mit "general" als Default.
Depends on: Phase 2
Requirements: DAT-01, DAT-02, DAT-03, DAT-04
Success Criteria (what must be TRUE):
1. chunks-Tabelle hat channel_id Spalte mit FK auf channels.id
2. POST /query mit channel_id durchsucht nur Chunks dieses Channels
3. POST /ingest mit channel_id ordnet neue Chunks diesem Channel zu
4. Alle API-Calls ohne channel_id funktionieren unverändert (Default "general")
Plans: 03-01, 03-02 (both complete)
Status: Complete — 2026-03-24

Phase 4: Channel CRUD API

Goal: Channels können per API angelegt und aufgelistet werden — und POST /admin/reset löscht nur Chunks des angegebenen Channels.
Depends on: Phase 3
Requirements: CH-01, CH-02, CH-03, CH-04
Success Criteria (what must be TRUE):
1. User kann Channel anlegen via POST /channels mit name und category — bekommt channel id zurück
2. User kann alle Channels abrufen via GET /channels — Antwort enthält id, name, category pro Channel
3. POST /channels mit bereits vorhandenem Channel-Namen gibt 409 zurück (kein 500er)
4. POST /admin/reset?channel_id=X löscht nur Chunks dieses Channels, alle anderen bleiben erhalten
Plans: 1/1 plans complete
Plans:
- [x] 04-01-PLAN.md — Channel CRUD routes, scoped reset, ingest guard, smoke tests

Key decisions (carry into planning):
- channels-Tabelle braucht category TEXT Spalte — ALTER TABLE channels ADD COLUMN category TEXT als Migration + schema.sql aktualisieren im selben Plan
- POST /admin/reset bekommt optionalen channel_id Query-Parameter — ohne Parameter weiterhin globaler Reset (Backward-Compat)
- Duplicate-Name-Handling: catch psycopg2.errors.UniqueViolation (pgcode 23505) → HTTPException(status_code=409) vor allgemeinem except Exception
- slug-Validierung: ^[a-z0-9_-]+$ Regex auf channel id bei POST /channels
- Channel-Existenz-Check vor ingest: SELECT id FROM channels WHERE id = %s vor ingest_file() → 404 wenn nicht gefunden
- Keine neuen Python-Pakete nötig — nur api.py berührt

Phase 5: Browser UI Redesign

Goal: Der User wählt den aktiven Channel links in der Sidebar und fragt oder ingestet rechts in den Tabs — der aktive Channel steuert alle Requests.
Depends on: Phase 4
Requirements: UI-01, UI-02, UI-03, UI-04, UI-05, UI-06, UI-07
Success Criteria (what must be TRUE):
1. Sidebar links zeigt alle Channels aus GET /channels — aktiver Channel visuell hervorgehoben, Klick wechselt sofort
2. User kann zwischen Chat-Tab und Ingest-Tab wechseln — beide Tabs gehören zum aktiven Channel
3. POST /query und POST /ingest enthalten channel_id des aktiven Channels
4. Channel-Wechsel leert Antwortbereich, Frage-Input und Ingest-Status sofort — kein Carry-over
5. User kann Channel direkt in der Sidebar anlegen (Name + Kategorie) — Sidebar aktualisiert sich ohne Reload
6. Aktiver Channel bleibt nach Seiten-Reload erhalten (localStorage)
7. Jeder Channel-Eintrag in der Sidebar zeigt seinen Category-Badge (Wert aus DB)
Plans: 1 plan
Plans:
- [ ] 05-01-PLAN.md — Full index.html rewrite: two-column layout, sidebar, tabs, channel state machine
UI hint: yes

Key decisions (carry into planning):
- Aktiver Channel als module-level JS-Variable (let activeChannelId = "general") — niemals aus DOM-Klassen lesen
- setActiveChannel(id) synchron alle Output-Bereiche leeren bevor Channel gewechselt wird
- loadChannels() auf DOMContentLoaded — Sidebar füllt sich ohne manuellen Reload
- Nur public/index.html berührt — api.py, ingest.py, query.py, schema.sql unverändert
- CSS Flexbox: body { flex-direction: row }, <aside class="sidebar"> links, <main> rechts
- const channelId = activeChannelId am Anfang von doQuery() und doIngest() — kein DOM-Lookup mid-request

Progress Table

Roadmap erstellt: 2026-03-23
Last updated: 2026-03-24 — Phase 5 plan created