Graceful degradation and edge cases

[pento]

Handle failure modes and edge cases across the plugin and MCP command system.

MCP Disconnection Mid-Command

• If the MCP's SSE/polling connection drops while a command is running, the command stays in running state until expires_at is reached, then transitions to expired
• Browser shows "Command timed out — Claude may not be connected" via snackbar notification
• On MCP reconnection, it does not resume expired commands — the user must resubmit

Browser Refresh During Active Command

• On page reload, the sidebar re-fetches command history from GET /wpce/v1/commands?post_id={current}
• Active (pending, claimed, running) commands are picked up and displayed with correct status
• Polling resumes for active commands

Expired Command Cleanup

• Lazy expiry: when querying commands, any pending or claimed commands past expires_at are transitioned to expired
• Periodic cleanup: a lightweight garbage collection pass (e.g., on wp_loaded or via a low-frequency cron event) deletes wpce_command CPT entries older than 24 hours regardless of status, to prevent unbounded growth

Plugin Deactivation

• On deactivation, clean up:
  • Unregister the wpce_command CPT
  • Optionally delete all wpce_command posts (or leave them for reactivation — make this a deactivation hook vs uninstall hook decision)
  • Remove registered comment meta
• MCP handles plugin disappearance gracefully: GET /wpce/v1/status returns 404, command listener stops, MCP continues working as before

Post-Switch Queuing

When the MCP has post A open and a command arrives for post B:

• The command is claimed and queued, not rejected
• MCP finishes all remaining commands on post A first
• Once post A's queue is drained, MCP closes post A, opens post B, and starts processing post B's commands
• Browser feedback: The AI Actions sidebar on post B's editor shows "Claude is finishing work on [Post A Title] — your command is queued" so the user understands why there's a delay
• Commands still respect expires_at — if a queued command expires before the MCP gets to it, it transitions to expired and is skipped

Context Management on Post Switch

When switching from post A to post B, the previous post's content pollutes Claude's context — stale block indices, note threads, and tool call history can cause confusion and waste context window space.

Goal: On post switch, compact or clear context so Claude starts fresh on the new post while retaining useful session-level information.

• Retain: Connection state, plugin state, user preferences/instructions from the channel, summary of what was done on previous posts
• Discard: Post-specific content, block listings, note threads, tool call details from the previous post

Exploration Needed

• Does Claude Code expose a mechanism for an MCP server to request context compaction or clearing? (API, notification, or tool call)
• If not, can the channel instructions guide Claude to treat a post switch as a fresh context? (e.g., "When you open a new post, disregard all block indices and content from the previous post")
• Should this be a hard clear (new conversation) or a compaction with custom instructions that preserve session-level context?

Acceptance Criteria

• Commands expire correctly when MCP disconnects mid-command
• Browser recovers command state after page refresh
• Expired/old commands are cleaned up to prevent CPT bloat
• Plugin deactivation cleans up cleanly
• MCP handles plugin disappearance without errors
• Commands for a different post are queued, not rejected
• MCP drains current post's commands before switching posts
• Browser shows queued state with explanation of the delay
• Queued commands that expire before processing are skipped
• Context is compacted or cleared on post switch (or documented workaround if no mechanism exists)
• Tests for expiry logic, cleanup, and post-switch queuing

Part of #28.