Datenfluss¶
Diese Seite dokumentiert den Fluss von Daten durch das CC-Sprint System in verschiedenen Szenarien.
Übersicht¶
CC-Sprint hat zwei primäre Datenpfade:
- Write-Path: Benutzer-Änderungen in der UI → Backlog.md
- Read-Path: Externe Backlog.md Änderungen → UI
Beide Pfade treffen sich in der SQLite-Datenbank, die als zentrale Cache- und Index-Schicht dient.
Write-Path: UI → Backlog.md¶
Szenario: Benutzer ändert Item-Status¶
Wichtige Schritte:
| Schritt | Beschreibung | Zweck |
|---|---|---|
| 3 | Optimistic Update | UI reagiert sofort, fühlt sich schneller an |
| 7-9 | DB Transaction | ACID-Garantien, Rollback bei Fehler möglich |
| 14-15 | Full Render | Alle Items werden neu gerendert (deterministisch) |
| 17-19 | Hash speichern | Verhindert, dass FileWatcher eigene Änderung meldet |
| 24 | Hash-Vergleich | Unterscheidet Self-Write von External-Write |
Szenario: Auto-Save¶
Auto-Save funktioniert ähnlich, wird aber durch einen Timer getriggert:
Timing: - Debounce: 2 Sekunden nach letzter Änderung - Trigger: Bei jeder Änderung wird Timer neu gestartet - Abbruch: Manuelles Speichern (Ctrl+S) cancelled Auto-Save Timer
Read-Path: Backlog.md → UI¶
Szenario: Externe Änderung (z.B. via Claude Code)¶
Wichtige Schritte:
| Schritt | Beschreibung | Problem |
|---|---|---|
| 9-13 | Hash-Vergleich | ⚠️ Hash wird nach Write gespeichert → Window für Race Condition |
| 20-21 | Parser | ⚠️ Bei Parse-Fehler: Keine Daten in DB → Datenverlust-Risiko |
| 30-33 | Conflict Check | ✅ Gut: Verhindert versehentliches Überschreiben von App-Änderungen |
| 39-42 | rebuild_database | ⚠️ DELETE vor INSERT → Bei Fehler: Leere DB |
Konflikte: Konkurrierende Änderungen¶
Szenario: User ändert Item in App, Claude ändert Backlog.md¶
Optionen im Detail:
| Option | Vorteil | Nachteil | Use Case |
|---|---|---|---|
| Reload | Einfach, sauber | App-Änderungen gehen verloren | Externe Änderungen wichtiger |
| Keep | App-Änderungen bleiben | Externe Änderungen gehen verloren | App-Änderungen wichtiger, Backup vorhanden |
| Merge | Keine Daten verloren | Komplex, manuell | Beide Änderungen wichtig |
ID-Generierung¶
Szenario: Neues Item erstellen¶
Wichtig:
- Atomare Operation: SELECT + UPDATE in Transaction → Keine ID-Duplikate
- Pro Typ: F, T, B, C haben jeweils eigene Sequenz
- Max: 9999 Items pro Typ (4-stellige Zahlen)
Performance-Kritische Pfade¶
Bottlenecks¶
| Operation | Dauer | Bottleneck | Optimierung |
|---|---|---|---|
| Parse 1000 Items | ~100ms | Regex, String Allocations | ✅ Akzeptabel |
| Render 1000 Items | ~50ms | String Formatting | ✅ Akzeptabel |
| Full DB Rebuild | ~200ms | DELETE + INSERT (1000 rows) | ⚠️ Transaktional, aber riskant |
| File Write | ~10ms | Disk I/O | ✅ Schnell |
| Hash Calculation | ~5ms | SHA-256 | ✅ Schnell |
Optimierungen¶
Virtualized List:
- UI rendert nur sichtbare Zeilen (~20-30 Items)
- react-window für Virtualisierung
- Scrolling bleibt flüssig bei 1000+ Items
Debouncing: - FileWatcher: 500ms → Verhindert Mehrfach-Parse bei schnellen Schreiboperationen - AutoSave: 2s → Verhindert Mehrfach-Schreiben bei schnellem Tippen
Indexed Queries:
- SQLite Indexes auf (project_id, status), (project_id, phase), (project_id, type)
- Filtered Queries bleiben <10ms
Nächste Schritte¶
- File-Sync - Details zu Hash-basierter Change Detection
- Probleme: Race Conditions - Bekannte Timing-Issues
- Probleme: Datenverlust-Risiken - rebuild_database Probleme