Extension re-implements the CLI session engine (parallel session stack + partial agent registry)

[muqsitnawaz]

Problem

The swarmify extension carries a full parallel session stack that duplicates the CLI's session engine, so every CLI change silently drifts the extension.

• core/session.activity.ts re-parses raw JSONL for activity/throughput/waiting — the CLI already ships activity/preview/awaitingReason (apps/cli/src/lib/session/active.ts:63, state.ts:200).
• vscode/sessions.vscode.ts:390 + monitor/sessionParse.ts:124 re-walk ~/.claude|.codex|.gemini on disk — CLI has discoverSessions() / getAgentSessionDirs() (apps/cli/src/lib/session/discover.ts:165,403).
• core/agents.ts:25 + swarmifyConfig.ts:7 keep a partial 8-agent registry vs the CLI's 14-harness AGENTS table (apps/cli/src/lib/types.ts:12).

Why this is architectural

This is the single largest structural rot: two implementations of one contract. Divergences already shipped (see the per-host mapCloudStatus and gemini sessions vs tmp path bugs). Left alone it keeps generating drift bugs on every CLI release.

Fix

Make the Factory Floor consume CLI session JSON exclusively (agents sessions --json, agents sessions <id> --json); delete the extension's format parsers and BUILT_IN_AGENTS/VALID_AGENT_IDS. Where the CLI JSON lacks a field, add it to the CLI (see the plan-text gap issue) rather than re-parsing.

Source: rot-audit swarm, cross-repo track (read-only, file:line verified).

---

Linear: RUSH-1503

[muqsitnawaz]

Deferred from the 2026-07-09 batch drain: prerequisite #743 (plan text in agents sessions --json) is in flight now (teammate caps-json). Beyond that this needs a design decision before an agent can take it: the extension reads JSONL from disk for low-latency polling, and replacing that with a agents sessions --json subprocess round-trip per poll cycle needs an agreed latency/contract (push vs poll, cache, or a long-lived daemon query). Revisit once #743 is merged.

[muqsitnawaz]

Note from #743 (PR #853): parsePlanFromClaudeJsonl at apps/factory/src/core/agents.ts:80 is now redundant on the CLI side — PR #853 exposes the plan text on SessionMeta.plan and at .session.plan in agents sessions <id> --json.

I left the parser and its call site (apps/factory/src/vscode/settings.vscode.ts:441) untouched in that PR because switching it to consume the new field is exactly the extension session-engine rework this issue tracks: the call site is inside the dispatch/plan-ready polling loop, reading the JSONL directly with fs.readFile. A trivial swap doesn't exist — the extension needs to either shell out to agents sessions --json for each poll or import the CLI's session pipeline in-process, both of which belong to the broader rework.

When this issue is picked up: after switching waitForPlanFromClaude (settings.vscode.ts) to consume .session.plan from the CLI, parsePlanFromClaudeJsonl and parsePlanFromClaudeJsonl.test.ts can be deleted.