Feature: Signal file / webhook when GSD auto mode hits a decision point

[allcounter]

Problem

When running GSD 2.0 in auto mode, the agent sometimes hits decision points that require user input:

• ask_user_questions during discuss/plan/execute phases
• showNextAction at phase boundaries (e.g., "M001 verified. Deploy or start M002?")

These decision points block silently in the TUI — there's no external signal that the agent is waiting. This is a problem when:

1. Monitoring multiple projects — running 3+ GSD auto sessions simultaneously, you can't tell which one needs attention without checking each terminal
2. Building Pi1↔Pi2 orchestration — a supervising Claude Code instance (Pi1) monitors autonomous GSD sessions (Pi2) but has no way to detect when Pi2 is waiting for input
3. Mobile/remote workflows — using CCNotifier or similar push notification systems to get alerts when attention is needed

Current behavior

• STATE.md is updated at phase boundaries but NOT when ask_user_questions blocks
• No auto.lock file is created during interactive question prompts
• The only way to know GSD is waiting is to visually check the terminal

Proposed solution

When GSD enters a blocking decision point, write a signal file:

.gsd/WAITING.json
{
  "status": "waiting",
  "type": "ask_user_questions" | "next_action",
  "question": "Skal vi tilføje global navigation nu?",
  "options": ["Hurtig opgave nu", "Del af M003", "None of the above"],
  "since": "2026-03-14T01:15:00Z",
  "phase": "execute",
  "slice": "S04"
}

When the user answers and the agent resumes, delete the file.

Alternative: Webhook/callback

A preferences.md option to call an external script/URL when a decision point is reached:

## Notifications
on_waiting: ~/.claude/hooks/pi2-waiting-hook.sh

This would complement the existing remote-questions Slack/Discord integration by supporting arbitrary notification backends.

Context

• Already aware of remote-questions extension (Slack/Discord polling) — this is great but doesn't cover custom notification backends
• The signal file approach is simpler and works with any watcher (fswatch, polling, inotify)
• Event hooks (session_start, agent_end, etc.) exist in the SDK but none fires on decision points

Environment

• GSD 2.0 v0.3.3 via Homebrew
• Running 3 concurrent auto sessions
• macOS, Claude Opus 4.6

[allcounter]

Additional context: Agent Teams integration

Claude Code has experimental Agent Teams support (SendMessage between named agents). If GSD auto sessions could be spawned as Claude Code subagents (via the Agent tool), there would be full bidirectional communication — the supervising instance (Pi1) could receive questions and send answers directly.

Currently this isn't possible because gsd runs as its own process (pi-agent harness), not as a Claude Code subagent. The signal file / webhook approach solves this for the current architecture where GSD sessions are independent processes.

However, if GSD 2.0 ever supports being invoked as a Claude Code subagent (or via Agent Teams), the decision-point signaling would come for free through the existing SendMessage protocol.

[trek-e]

PR #1133 implements the signal file approach:

• gsd-tools state signal-waiting writes WAITING.json with type, question, options, timestamp, phase
• gsd-tools state signal-resume removes it when the agent resumes
• Works with any external watcher (fswatch, inotify, polling)

Workflow integration (calling these before/after AskUserQuestion) would be the next step — this PR provides the infrastructure.

[trek-e]

This issue is addressed by PR #1133. The fix is ready for review and merge.