RFC: Pluggable AgentEventSource — decouple activity detection from Claude Code JSONL

[MultiNavi]

Problem

The current activity detection polls ~/.claude/projects/**/*.jsonl transcripts and uses regex/heuristics to map text → activity state. The project's own README notes this "often misfires." This also hard-couples Pixel Agents to Claude Code CLI — users of Aider, Cursor, continue.dev, or custom agent runtimes cannot adopt the extension.

Proposal

Introduce an abstract AgentEventSource interface:

interface AgentEvent {
  agentId: string;
  displayName?: string;
  activity: "idle" | "typing" | "reading" | "running" | "waiting" | "done";
  timestamp: number;
}
interface AgentEventSource {
  start(onEvent: (e: AgentEvent) => void): Promise<void>;
  stop(): Promise<void>;
}

Ship a default ClaudeCodeJsonlSource implementing the interface (preserving current behavior). Allow third-party sources via extension settings or a registration API.

Acceptance criteria (binary)

• AgentEventSource interface exported from extension's public API
• ClaudeCodeJsonlSource is the default implementation, behaviorally identical to v1.3.0
• Third-party sources registrable via pixel-agents.registerSource() or equivalent
• Activity classifier consumes typed AgentEvent, not raw text
• Existing e2e tests pass unchanged
• One doc page added: docs/custom-event-sources.md

Out of scope

• Implementing any specific non-Claude-Code source (only the interface + default)
• UI for source selection (follow-up issue)

Why this benefits all users

Fixes the "misfires" symptom for Claude Code users (typed events > text matching). Unlocks the repo for any AI-agent runtime. Keeps current behavior as default — zero breakage.

[Gundalai-Batkhuu]

Seems like a good direction for development to introduce multiple providers. One thing that's interesting for me is the fixed set of activities per AgentEvent. The list of values for 'activity' key seems small. Also, why we need to have a set here?