A) quickJudgePrompt()/quickJudgeWithTestsPrompt(): Runde 1 ohne --continue nutzt einen
kompakten Prompt ohne TASK.md — spart 15-30% Inference-Zeit bei direktem PASS
B) switchModel()-Caching via currentModelKey: Überspringt setModel() wenn Modell
bereits korrekt gesetzt ist; currentModelKey wird im finally-Block resettet
C) normalizeForComparison() für Loop-Detection: Whitespace/Satzzeichen-Normalisierung
verhindert False-Negatives bei minimalen Formulierungsunterschieden im Judge-Output
D) Parallele Server-Bereitschaftsprüfung im --continue-Modus via Promise.all:
Spart bis zu 3 min bei Kaltstart beider Server
E) --no-tests Flag: überspringt detectTestCommands() und autoTestCmds-Befüllung
F) --approve-concerns Flag: behandelt "PASS WITH CONCERNS" wie "PASS" (kein ShipIt-Call)
H) sendAndWait() settle-Delay 400ms → 150ms: ~1-2 s weniger Wartezeit pro Durchlauf
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- /optimize --interactive pausiert nach erstem PASS; /continue setzt fort,
/continue "Zusatz" hängt weiteren Auftrag an und wiederholt den Judge-Loop
- Klares PASS → direkt SHIP ohne zweiten ShipIt-Inference-Call (1-3 min gespart)
- PASS WITH CONCERNS → ShipIt-Runde weiterhin als finale Abwägung
- Default --rounds 3→2 (~30 % schnellere Durchläufe für typische Tasks)
- /continue-Command erkennt interactivePauseActive und leitet Signal weiter
- Alle drei Interactive-Zustandsvariablen werden im finally-Block resettet
- Dokumentation (README, BEDIENUNGSANLEITUNG, CLAUDE.md) vollständig aktualisiert
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Nach SHIP-Verdikt (sowohl in /optimize als auch /shipit):
- autoCommitIfDirty(): committet uncommitted Änderungen via git add -A + commit,
falls der LLM keinen abschließenden Commit gemacht hat (Sicherheitsnetz)
- notifyShipSuccess(): zeigt prominente Meldung
"✅ Fertig! Das Programm ist jetzt produktionsreif und committed."
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
runTestsParallel() wrappte jede Test-Suite mit 'timeout N bash -c ...'
(Standard: 120s). Exit 124 wird als Timeout erkannt und im Output markiert.
Neues Flag --test-timeout N für Integration-Tests die länger brauchen:
/optimize "..." --test-timeout 300
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- sendAndWait(): fängt "Agent is already processing" mit exponentiellem
Backoff ab (5 Versuche: 500ms, 1s, 2s, 4s). Race Condition zwischen
waitForIdle() und sendUserMessage() wird damit toleriert.
- /optimize: prüft Port 8002 vor dem Loop (20× alle 3s = max. 60s).
Bei 503 "Loading model" wird gewartet statt sofort zu scheitern.
Ist der Server nach 60s nicht erreichbar: Abbruch mit Hinweis.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Tests werden jetzt von der Extension selbst erkannt und als parallele
CPU-Prozesse gestartet — Judge bekommt den fertigen Output und führt
keine Tests mehr selbst aus.
- detectTestCommands(): erkennt pytest, npm test, cargo, go test, make test
anhand von Framework-Markern (alle Checks parallel via Promise.all)
- runTestsParallel(): startet alle erkannten Suiten gleichzeitig, kombiniert
Output mit Status-Header pro Suite (max. 6000 Zeichen gesamt)
- /optimize: Auto-Erkennung läuft einmalig nach Coder-Phase, vor dem Loop
- --test-cmd bleibt als Override für Sonderfälle erhalten
- Fallback: kein Framework erkannt → Judge führt Tests wie bisher selbst aus
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Neues Flag: /optimize <auftrag> --test-cmd "pytest -x"
Die Extension führt den Test-Befehl vor jedem Judge-Call selbst aus (pi.exec).
Judge bekommt den Output fertig übergeben und muss keine Tests mehr starten.
Das entkoppelt Test-Laufzeit vom LLM-Call und spart Judge-Inferenz-Zeit.
- judgeWithTestsPrompt(): wie judgePrompt, aber mit Test-Output im Prompt,
explizites Verbot weitere Tests zu starten
- runTests(): führt Shell-Befehl aus, kürzt Output auf 6000 Zeichen
- Ohne --test-cmd: bisheriges Verhalten unverändert
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Wenn --continue mit einem Auftragstext kombiniert wird, wurde writeTaskMd()
bisher nicht aufgerufen — der Text wurde ignoriert. Jetzt wird er als
Zusatzauftrag angehängt, bevor die Judge→Fix-Schleife startet.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
