docs: correct permission finding — auto+haiku denies writes (not a CLI regression), §2 happy-path PASS

This commit is contained in:
mika kuns
2026-07-24 08:08:15 +02:00
parent 79ce7afe46
commit 3211bfc0f9
2 changed files with 2 additions and 2 deletions
+1 -1
View File
@@ -36,7 +36,7 @@ Kein Code-Aufwand, nur Durchspielen mit explizit notiertem Pass-Kriterium. Der G
## Offene Code-Punkte
- **[OFFEN, 2026-07-24] `--permission-mode auto` denied headless Task-Writes (CLI-Regression):** Mit claude CLI **2.1.207** werden in headless `-p`-Runs unter `--permission-mode auto` alle Writes/Edits `denied` (empirisch verifiziert: `auto``permission_denials:[Write]`, keine Datei; `bypassPermissions` → Write ok). `ClaudeArgsBuilder` nutzt `auto` als Default UND mappt explizites `bypassPermissions``auto` (seit `b2eb5fc`, 2026-04-25). Folge: autonome Tasks können im aktuellen Setup keine Dateien ändern (leerer Worktree → WaitingForReview ohne Änderung). `auto` **lief früher** (Gap-Tasks 2026-07-23 unter CLI 2.1.191 haben geschrieben+committet) — es ist eine CLI-seitige Verhaltensänderung von `auto`. Bewusst noch NICHT gefixt (Mika: erst beobachten/abwarten, ob `auto` wieder greift bzw. via settings-allowlist gedacht ist). Fix-Option falls nötig: Default → `bypassPermissions` + auto-Remap raus in `ClaudeArgsBuilder`/`PermissionModeRegistry`. **Blockiert §2 Happy-Path im Verifikations-Handoff.**
- **[OFFEN, 2026-07-24] `--permission-mode auto` + Modell `haiku` → Writes werden denied (haiku-Footgun, KEINE CLI-Regression):** Kontrolliert verifiziert (CLI 2.1.207, gleicher Worker/Tag): unter dem Default-Mode `auto` bekommt **sonnet** Writes auto-approved (`permission_denials:[]`, Datei entsteht), **haiku** wird `denied` (`permission_denials:[Write]`, keine Datei) — haiku steigt beim auto-Permission-Flow aus, statt zu schreiben. Folge: eine Task, die (per MCP `model:"haiku"` oder Task-Override) auf haiku läuft, macht unter `auto` **still nichts** und landet ohne Änderung in `WaitingForReview`. Normalbetrieb (Default = sonnet) ist nicht betroffen; die Gap-Tasks 2026-07-23 liefen sonnet und haben geschrieben+committet. Ursprünglich fälschlich als CLI-`auto`-Regression gemeldet — das war ein Testartefakt (haiku-Tasks zum „Sparen"). Optionen falls es nervt: haiku aus der Auswahl nehmen, ODER Runner auf `acceptEdits`/`bypassPermissions` (modell-unabhängig) statt `auto`.
- **Status-Bar Live-Update:** Prüfen, ob `RunNow`-Enable/Disable pro Task-Row bei Connection-Change sauber re-evaluiert. Connection-Status lebt in `IslandsShellViewModel` / `WorkerConnectionModalViewModel` (es gibt keinen `StatusBarViewModel` mehr). Erst messen, dann ggf. fixen. Klein.
## Nachklapp Refactoring-/Bug-Runde (2026-06-09/10)
+1 -1
View File
@@ -19,7 +19,7 @@ Konsolidierte manuelle Verifikationen aus `docs/open.md` + Memory-Ständen — g
## 2. Worktree-Pipeline (3 falsifizierbare Fälle)
- [ ] Happy-Path: Task mit WorkingDir → `worktrees.state='active'`, `head_commit` gesetzt, `diff_stat` non-empty, Branch `claudedo/<id[:8]>` existiert auf Disk. — **BLOCKIERT (2026-07-24)** durch den Permission-Bug (CLI 2.1.207 `--permission-mode auto` denied Writes; s. open.md „Offene Code-Punkte"). Worktree/Branch wurden korrekt angelegt, aber der Agent konnte nichts schreiben → kein Commit/Diff. Re-Test nach Fix.
- [x] Happy-Path: Task mit WorkingDir → `worktrees.state='active'`, `head_commit` gesetzt, `diff_stat` non-empty, Branch `claudedo/<id[:8]>` existiert auf Disk. — **PASS (2026-07-24)** via Task `e63eb2f5` (sonnet): Worktree active, `headCommit 8a3ae86` (ahead=1 vom Base), `diff_stat` non-empty (`review-cancel.txt`), Branch `claudedo/e63eb2f5…` auf Disk. (Mein erster Versuch mit `model=haiku` schlug fehl — das war ein haiku/auto-Footgun, keine Pipeline-Sache; s. open.md.)
- [x] No-Changes-Run: → `status='Done'`, `head_commit IS NULL`, `diff_stat IS NULL`. — **PASS (2026-07-24)**; Präzisierung: aktueller Flow endet in `WaitingForReview` (nicht `Done`, das ist erst nach Approve) — Doc-„Done" ist veraltet. Kein neuer Commit, leerer Diff bestätigt.
- [x] Kein Git-Repo (WorkingDir = `C:\Temp`): → `status='Failed'`, KEINE `worktrees`-Row, Git-Fehler im Log. — **PASS (2026-07-24)**; Fehler: „Worktree creation failed: working_dir is not a git repository".