Aus dem Review von PR #60 (GUI-Härtung) — bewusst nach Phase 4 verschoben.
Problem: Der GUI-Cancel (RunSession.cancel → proc.terminate() in generative/gui/app.py, plus iter_run_events finally in generative/gui/runner.py) beendet nur den direkten Orchestrator-Subprocess. Von der Pipeline gestartete Enkel-Prozesse (z.B. claude -p im subscription-Backend) erhalten auf Windows kein Signal über die Prozesshierarchie und können weiterlaufen.
Fix-Richtung: Subprocess in eigener Prozessgruppe/Job starten und bei Cancel den gesamten Prozessbaum mit Timeout beenden:
- POSIX:
start_new_session=True + os.killpg(os.getpgid(proc.pid), SIGTERM/SIGKILL).
- Windows:
creationflags=CREATE_NEW_PROCESS_GROUP bzw. taskkill /PID <pid> /T /F oder ein Job Object.
Severity: MED (lokales Solo-Tool, 127.0.0.1). Keine Korrektheits-/Sicherheitslücke, aber verwaiste LLM-Subprozesse nach Abbruch.
Kontext/SSoT: [[atomic-notes Frontend-Stack-Entscheidung]] §Phase 4, [[Atomic-Agent-Pipeline]].
Aus dem Review von PR #60 (GUI-Härtung) — bewusst nach Phase 4 verschoben.
Problem: Der GUI-Cancel (
RunSession.cancel→proc.terminate()ingenerative/gui/app.py, plusiter_run_eventsfinally ingenerative/gui/runner.py) beendet nur den direkten Orchestrator-Subprocess. Von der Pipeline gestartete Enkel-Prozesse (z.B.claude -pim subscription-Backend) erhalten auf Windows kein Signal über die Prozesshierarchie und können weiterlaufen.Fix-Richtung: Subprocess in eigener Prozessgruppe/Job starten und bei Cancel den gesamten Prozessbaum mit Timeout beenden:
start_new_session=True+os.killpg(os.getpgid(proc.pid), SIGTERM/SIGKILL).creationflags=CREATE_NEW_PROCESS_GROUPbzw.taskkill /PID <pid> /T /Foder ein Job Object.Severity: MED (lokales Solo-Tool, 127.0.0.1). Keine Korrektheits-/Sicherheitslücke, aber verwaiste LLM-Subprozesse nach Abbruch.
Kontext/SSoT: [[atomic-notes Frontend-Stack-Entscheidung]] §Phase 4, [[Atomic-Agent-Pipeline]].