Summary

• Problem: resolveChannelRestartReason does not handle disconnected evaluation reason explicitly — it falls through to "stuck", conflating a clean WebSocket drop (e.g. Discord code 1006) with a genuinely stalled channel.
• Why it matters: Operators diagnosing multi-bot restart storms see reason: stuck in logs for bots that simply lost their WebSocket connection. This makes triage harder and prevents future policy logic from treating disconnects differently (e.g. faster reconnect, skip cooldown).
• What changed: Added "disconnected" to ChannelRestartReason union type and added an explicit branch in resolveChannelRestartReason that returns "disconnected" when the evaluation reason is "disconnected". Added a corresponding test case.
• What did NOT change: No changes to evaluateChannelHealth, health-monitor scheduling, restart behavior, or any channel provider code. The restart still happens — only the logged/reported reason is now accurate.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes Discord health-monitor restart storm: 'disconnected' classified as 'stuck', no reconnect config parity with WhatsApp #36404

User-visible / Behavior Changes

• Health-monitor log messages now show reason: disconnected instead of reason: stuck when a channel's WebSocket connection drops while the bot is otherwise running normally.

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: macOS 26.3 (arm64)
• Runtime: Node.js 22
• Integration/channel: Discord (any channel with WebSocket health monitoring)

Steps

1. Configure a Discord bot account
2. Simulate a WebSocket 1006 disconnect (or wait for a natural drop)
3. Observe health-monitor restart logs

Expected

• Log shows reason: disconnected

Actual

• Before fix: log shows reason: stuck
• After fix: log shows reason: disconnected

Evidence

TypeScript compiles cleanly. All 8 tests in channel-health-policy.test.ts pass:

 ✓ src/gateway/channel-health-policy.test.ts (8 tests) 2ms
   Tests  8 passed (8)

New test case:

it("maps disconnected to disconnected instead of stuck", () => {
  const reason = resolveChannelRestartReason(
    { running: true, connected: false, enabled: true, configured: true },
    { healthy: false, reason: "disconnected" },
  );
  expect(reason).toBe("disconnected");
});

Human Verification (required)

• Verified scenarios: disconnected evaluation now returns "disconnected" restart reason; stuck evaluation still returns "stuck"; not-running and stale-socket paths unchanged.
• Edge cases checked: All existing 7 tests continue to pass, confirming no regression in other evaluation→reason mappings.
• What I did not verify: Live multi-bot Discord restart storm scenario (requires 6+ bots and a network partition).

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Failure Recovery (if this breaks)

• How to disable/revert: Revert this commit; the fallthrough to "stuck" is restored.
• Files/config to restore: src/gateway/channel-health-policy.ts
• Known bad symptoms: None expected — this only changes a log/reason string, not restart behavior.

Risks and Mitigations

• Risk: Downstream code may pattern-match on ChannelRestartReason values. Mitigation: Grep confirmed reason is only used in log messages (channel-health-monitor.ts line 153), not in conditional logic.