Bekannte Probleme¶

Übersicht aller bekannten Issues im CC-Sprint System.

Kritische Probleme¶

ID	Problem	Schweregrad	Status	Beschrieben in
P-001	Edit-Tool scheitert bei Backlog.md	🔴 Kritisch	Workaround vorhanden	edit-tool-failure.md
P-002	`rebuild_database` löscht Daten ohne Rollback	🔴 Kritisch	Offen	data-loss-risks.md
P-003	Hash wird nach Write gespeichert	🟠 Hoch	Offen	data-loss-risks.md
P-004	Kein Rollback bei Parse-Fehler	🟠 Hoch	Offen	data-loss-risks.md
P-005	Race Condition: FileWatcher vs AutoSave	🟡 Mittel	Selten	race-conditions.md

P-001: Edit-Tool scheitert bei Backlog.md¶

Symptom: Claude Code's Edit tool meldet "String to replace not found"

Ursachen: 1. Timestamp in Header ändert sich zwischen Read und Edit 2. Unicode-Encoding (ä,ö,ü,ß) Mismatches 3. Line-Ending Unterschiede (CRLF vs LF) 4. File zu groß für Context-Fenster (85+ Items = 3900+ Zeilen)

Impact: - Claude Code kann Backlog.md nicht direkt editieren - Workaround nötig: safe_backlog_edit.py (Full-File-Rewrite) - Ineffizient und riskant bei großen Files

Workaround:

# Statt Edit-Tool:
python scripts/safe_backlog_edit.py --write "$(cat <<'EOF'
[kompletter neuer Inhalt]
EOF
)"

Siehe: Detaillierte Analyse

P-002: rebuild_database löscht Daten ohne Rollback¶

Symptom: Bei External-Change wird DB komplett gelöscht, dann re-importiert

Problem: DELETE vor INSERT → Bei Fehler: Leere DB

Code (src-tauri/src/commands/project.rs:459-462):

conn.execute("DELETE FROM backlog_items WHERE project_id = ?", params![project_id])?;
conn.execute("DELETE FROM dependencies WHERE project_id = ?", params![project_id])?;
conn.execute("DELETE FROM acceptance_criteria WHERE project_id = ?", params![project_id])?;
// Wenn jetzt Fehler → Alle Daten weg!

for item in items {
    items_repo::insert(&mut conn, &project_id, &item)?;
}

Impact: - Datenverlust-Risiko bei Parse-Fehler - Keine Möglichkeit zum Rollback

Lösung (Konzept):

BEGIN TRANSACTION;
CREATE TEMP TABLE backup AS SELECT * FROM backlog_items;
DELETE FROM backlog_items;
INSERT INTO backlog_items ...;
IF error THEN ROLLBACK; ELSE COMMIT;

Siehe: Detaillierte Analyse

P-003: Hash wird nach Write gespeichert¶

Symptom: Window zwischen File-Write und Hash-Speicherung

Problem (src-tauri/src/commands/items.rs:395-400):

// 1. Schreibe File
std::fs::write(&backlog_path, &content)?;

// 2. Berechne Hash
let hash = calculate_hash(&content);

// 3. Speichere Hash
store_hash(&mut conn, &project_id, &hash)?;

// Wenn zwischen 1 und 3 ein Crash → Hash falsch

Impact: - Bei Crash: Hash stimmt nicht mit File-Inhalt überein - Permanenter Konflikt-Zustand - FileWatcher denkt immer "External Change"

Lösung (Konzept):

// 1. Berechne Hash VORHER
let hash = calculate_hash(&content);

// 2. Schreibe File
std::fs::write(&backlog_path, &content)?;

// 3. Speichere Hash (bereits berechnet)
store_hash(&mut conn, &project_id, &hash)?;

Siehe: Detaillierte Analyse

P-004: Kein Rollback bei Parse-Fehler¶

Symptom: Bei Parse-Fehler nach DELETE → Leere DB

Problem: rebuild_database löscht Items, dann parsen. Wenn Parser fehlschlägt:

1. DELETE FROM backlog_items  ✓ (alles weg)
2. Parse Backlog.md           ✗ (Fehler!)
3. INSERT INTO ...            (wird nie ausgeführt)
→ Ergebnis: Leere DB

Impact: - Schwerwiegender Datenverlust - User hat ungespeicherte App-Änderungen verloren - Nur Backup kann helfen

Lösung (Konzept):

// 1. Parse ZUERST (vor DELETE)
let items = parser::parse_backlog(&content)?;

// 2. Validiere
validator::validate(&items)?;

// 3. Erst DANN löschen + einfügen (in Transaction)
BEGIN TRANSACTION;
DELETE FROM backlog_items;
INSERT INTO backlog_items ...;
COMMIT;

Siehe: Detaillierte Analyse

P-005: Race Condition: FileWatcher vs AutoSave¶

Symptom: Seltener Konflikt, wenn externe Änderung während AutoSave-Debounce

Szenario:

t=0ms:    User ändert Item in App
t=10ms:   AutoSave Timer startet (2s)
t=500ms:  Claude Code schreibt Backlog.md
t=1000ms: FileWatcher erkennt Änderung (nach 500ms debounce)
t=1001ms: App lädt externe Version (User-Änderung noch nicht gespeichert)
t=2010ms: AutoSave triggert (überschreibt externe Version!)

Impact: - Externe Änderungen gehen verloren - Selten (Timing-abhängig) - User merkt es möglicherweise nicht

Workaround: Modified_in_app Flag prüfen vor Reload

Lösung (Konzept): AutoSave canceln bei External Change Detection

Siehe: Detaillierte Analyse

Mittlere Probleme¶

ID	Problem	Schweregrad	Status
P-006	Context-Overflow bei großen Backlog.md	🟡 Mittel	Workaround
P-007	Kein Incremental Parsing	🟡 Mittel	Enhancement
P-008	Full-File-Rewrite ineffizient	🟡 Mittel	Enhancement

P-006: Context-Overflow bei großen Backlog.md¶

Symptom: Claude Code verlangsamt sich, Edit-Tool scheitert

Ursache: Backlog.md mit 85+ Items = 3900+ Zeilen = Context voll

Impact: - Edit-Tool nicht verwendbar - Langsame Responses - Wiederholungen

Workaround: - Nur relevante Items mit Script lesen - Context regelmäßig clearen (/clear) - Neue Session für große Tasks

Siehe: Prozesse: Context-Management

P-007: Kein Incremental Parsing¶

Problem: Bei External-Change wird immer komplettes File geparst

Impact: - Ineffizient bei Änderung eines einzigen Items - ~100ms für 1000 Items (auch wenn nur 1 geändert)

Enhancement: Streaming Parser mit Line-Range Tracking

Siehe: Lösungskonzepte: Scripts Design

P-008: Full-File-Rewrite ineffizient¶

Problem: safe_backlog_edit.py schreibt komplettes File

Impact: - Git-Diffs zeigen komplettes File als geändert - Merge-Konflikte wahrscheinlicher - Ineffizient bei kleinen Änderungen

Enhancement: Surgical Editing (nur betroffene Zeilen)

Siehe: Lösungskonzepte: Scripts Design

Niedrige Probleme¶

ID	Problem	Schweregrad	Status
P-009	Keine Progress-Bar bei großen Imports	🟢 Niedrig	Enhancement
P-010	Konflikt-Banner verschwindet zu schnell	🟢 Niedrig	UX
P-011	Keine Backup-Größen-Anzeige	🟢 Niedrig	Enhancement

Status-Legende¶

Offen: Problem identifiziert, keine Lösung implementiert
Workaround vorhanden: Temporäre Lösung existiert
In Arbeit: Fix wird entwickelt
Selten: Tritt nur unter spezifischen Bedingungen auf
Enhancement: Verbesserungswunsch, kein kritischer Bug

Priorisierung¶

Kurzfristig (Kritisch)¶

P-002: Transaktionales rebuild_database
P-003: Hash-Timing Fix
P-001: Granulare Item-Operationen (backlog_item.py)

Mittelfristig (Wichtig)¶

P-004: Parse-vor-Delete
P-005: AutoSave Race Condition Fix
P-007: Incremental Parsing

Langfristig (Nice-to-Have)¶

P-006: Context-Management Tools
P-008: Surgical Editing
P-009-P-011: UX Improvements

Nächste Schritte¶

Detaillierte Analysen: - Edit-Tool Fehler - Race Conditions - Datenverlust-Risiken

Lösungskonzepte: - Scripts Design - App-Fixes Design - Workflow Design