feat: Granular notification control — per-channel toggle with curl suppression

[virtualian]

Problem

The PAI Algorithm currently executes voice notification curl commands unconditionally at every phase transition (7 curls per Algorithm run). These bash calls:

1. Produce visible noise in the terminal even when the user doesn't want notifications
2. Waste execution time when the notification server isn't running or notifications are unwanted
3. Cannot be selectively disabled — it's all-or-nothing

There is no granular control over notification channels (voice, desktop, etc.).

Proposed Solution

Slash Command Interface

Add a /notification skill with per-channel toggle control:

/notification voice on       # Enable voice (curl) notifications
/notification voice off      # Disable voice notifications — suppresses ALL curl calls
/notification desktop on     # Enable desktop notifications
/notification desktop off    # Disable desktop notifications
/notification status         # Show current notification channel states
/notification all off        # Disable all notification channels
/notification all on         # Enable all notification channels

Settings Persistence

Store notification state in settings.json:

{
  "notifications": {
    "voice": true,
    "desktop": true
  }
}

Curl Suppression Behavior

Critical requirement: When notifications.voice is false, the Algorithm MUST NOT execute the phase-announcement curl commands at all. They should be conditionally gated, not executed-and-ignored.

Current behavior (unconditional):

# Always fires, even when unwanted
curl -s -X POST http://localhost:8888/notify -H "Content-Type: application/json" -d '{"voice_id":"...","message": "Entering the Observe phase"}'

Desired behavior (conditional):

# Only fires when notifications.voice is enabled in settings.json
# When disabled: no curl command appears in output, no execution, zero noise

Implementation Considerations

• The Algorithm template marks voice curls as [VERBATIM - Execute exactly as written] — this directive would need to become conditional on notification state
• The /notification command should provide immediate feedback: "Voice notifications disabled. Phase announcement curls will be suppressed."
• Background agents should respect the same notification settings
• The notification server (localhost:8888) health check could be part of the status command

Acceptance Criteria

• /notification voice off suppresses all curl calls to the notification server
• /notification desktop off suppresses desktop notifications
• Settings persist across sessions via settings.json
• /notification status shows current state of all channels
• No visible curl commands appear in output when voice is disabled
• Background agents inherit notification settings from parent

[virtualian]

Bug Report: VoiceGate Hook Blocks Non-Voice Bash Commands

Problem

VoiceGate.hook.ts uses a naive substring check (command.includes('localhost:8888')) on the entire Bash command string. Any command that mentions localhost:8888 in its text — even as quoted content inside a gh issue comment body — gets falsely classified as a voice curl and blocked.

Reproduction

1. Set notifications.voice = false in settings.json
2. Run any gh command whose body text contains localhost:8888 as an example
3. Result: PreToolUse:Bash hook error — command is denied

Also observed: plain gh issue edit commands were blocked (see screenshot from session).

Root Cause

Line 105 in VoiceGate.hook.ts:

if (!command.includes('localhost:8888')) {

This matches ANY command containing the substring, not just actual curl invocations to the voice server.

Fix

Check that the command is a curl command AND targets localhost:8888:

const isVoiceCurl = /^\s*curl\s/.test(command) && command.includes('localhost:8888');

This ensures only actual voice curls are gated — all other Bash commands pass through regardless of their text content.

[virtualian]

Architectural Fix: Replace curl pattern-matching with self-gating CLI tool

Problem (deeper than the substring bug)

The current architecture is backwards:

1. Algorithm template hardcodes 7 raw curl commands (one per phase)
2. VoiceGate.hook.ts intercepts ALL Bash calls, tries to pattern-match voice curls
3. False positives block unrelated commands (e.g., gh issue comment whose body mentions localhost:8888)

The substring fix (/^\s*curl\s/.test(command)) is better but still fragile — it's a hook trying to reverse-engineer intent from command text.

Root Cause

The notification gate is in the wrong place. It's a hook (external observer) instead of being at the source (the tool that makes the call).

Proposed Fix: Notify.ts CLI tool

Create ~/.claude/skills/PAI/Tools/Notify.ts that:

1. Reads notifications.voice from settings.json
2. If disabled → exits silently (zero noise, zero execution, zero hook needed)
3. If enabled → POSTs to localhost:8888/notify
4. Reads voice_id from settings.json (no hardcoding in template)
5. Handles main-session vs subagent detection internally

Before (current — 7 places in Algorithm template):

curl -s -X POST http://localhost:8888/notify -H "Content-Type: application/json" \
  -d '{"voice_id":"21m00Tcm4TlvDq8ikWAM","message": "Entering the Observe phase"}'

After:

bun ~/.claude/skills/PAI/Tools/Notify.ts "Entering the Observe phase"

What this eliminates

• VoiceGate.hook.ts — no longer needed; the gate is built into the tool
• False positive risk — no Bash command pattern matching at all
• Hardcoded voice_id — read from settings.json once, centrally
• Subagent detection in hook — moved into the tool itself

Acceptance Criteria

• Notify.ts reads notifications.voice from settings.json and exits silently if disabled
• Notify.ts reads voice_id from settings.json (not hardcoded)
• Notify.ts detects subagent context and suppresses (same logic as current hook)
• Algorithm template v1.8.0 curls replaced with bun Notify.ts "message" calls
• VoiceGate.hook.ts removed or reduced to minimal pass-through
• No other Bash commands are affected by notification settings
• Existing /notification voice on/off skill still works (same settings.json contract)