docs(plan): add circle 2 expanded parity plan

.trellis/plans/coding-deepgent-circle-2-expanded-parity-plan.md

@@ -0,0 +1,474 @@
+# coding-deepgent Circle 2 Expanded Product Parity Plan
+
+Status: proposed
+Updated: 2026-04-20
+Parent roadmap: `.trellis/plans/coding-deepgent-full-cc-parity-roadmap.md`
+Planning task: `.trellis/tasks/04-20-brainstorm-circle-2-parity-plan/`
+Strategy: substrate-first
+
+## Purpose
+
+Circle 2 begins after the Circle 1 local daily-driver parity baseline.
+
+Circle 1 intentionally avoided mailbox, coordinator/team runtime, durable daemon,
+remote/IDE control plane, full extension lifecycle, and richer cross-day memory.
+Circle 2 is where those expanded product-parity capabilities can be planned and
+implemented without overloading the Circle 1 `subagents`, `sessions`, or
+frontend bridge seams.
+
+## Strategy Decision
+
+Use a substrate-first sequence.
+
+Rationale:
+
+* current Circle 1 background subagent controls are active-process features, not
+  durable workers
+* mailbox and coordinator semantics need real delivery/lifecycle state
+* remote/IDE surfaces need replayable event/control infrastructure
+* daemon/worker substrate reduces the chance of faking durable behavior with
+  process-local handles
+
+## Evidence Ladder
+
+Use the global evidence order from
+`.trellis/plans/coding-deepgent-full-cc-parity-roadmap.md`:
+
+1. real Claude Code public behavior
+2. `cc-haha` source-backed implementation reference
+3. high-quality analogous OSS
+4. secondary analysis
+
+For Circle 2, `cc-haha` evidence is sufficient to justify the major feature
+families, but OSS fallback is still useful for implementation details around
+runtime server boundaries, extension lifecycle, and sandbox/remote control.
+
+## Source Evidence
+
+### `cc-haha`
+
+Worker / session ingress:
+
+* `/root/claude-code-haha/src/cli/transports/ccrClient.ts`
+  * worker lifecycle protocol
+  * `PUT /worker`
+  * worker heartbeat
+  * visible client events
+  * internal worker events for resume
+  * worker state restore after restart
+* `/root/claude-code-haha/src/cli/transports/SSETransport.ts`
+* `/root/claude-code-haha/src/cli/transports/WebSocketTransport.ts`
+
+Task lifecycle and control:
+
+* `/root/claude-code-haha/src/cli/print.ts`
+  * `task_started`
+  * `task_progress`
+  * `task_notification`
+  * `session_state_changed`
+  * `stop_task`
+* `/root/claude-code-haha/src/entrypoints/sdk/controlSchemas.ts`
+
+Mailbox / permission routing:
+
+* `/root/claude-code-haha/src/context/mailbox.tsx`
+* `/root/claude-code-haha/src/hooks/useInboxPoller.ts`
+* `/root/claude-code-haha/src/hooks/useSwarmPermissionPoller.ts`
+* `/root/claude-code-haha/src/hooks/toolPermission/handlers/swarmWorkerHandler.ts`
+
+Coordinator / workers:
+
+* `/root/claude-code-haha/src/cli/print.ts`
+  * coordinator mode references and resume-mode matching
+* `/root/claude-code-haha/src/components/PromptInput/*`
+  * coordinator task selection/UI state
+* `/root/claude-code-haha/src/state/AppStateStore.ts`
+  * coordinator task index/count and worker permission state
+
+Remote / IDE:
+
+* `/root/claude-code-haha/src/remote/*`
+* `/root/claude-code-haha/src/services/mcp/vscodeSdkMcp.ts`
+* `/root/claude-code-haha/src/services/mcp/client.ts`
+  * IDE-specific MCP server/tool handling
+
+Daemon / cron / proactive:
+
+* `/root/claude-code-haha/src/entrypoints/cli.tsx`
+  * `--daemon-worker`
+* `/root/claude-code-haha/src/cli/print.ts`
+  * cron scheduler and proactive tick references
+* `/root/claude-code-haha/src/skills/bundled/loop.ts`
+* `/root/claude-code-haha/src/skills/bundled/scheduleRemoteAgents.ts`
+
+Plugin / extension lifecycle:
+
+* `/root/claude-code-haha/src/services/plugins/pluginOperations.ts`
+* `/root/claude-code-haha/src/services/plugins/PluginInstallationManager.ts`
+* `/root/claude-code-haha/src/services/mcp/config.ts`
+  * plugin MCP loading, dedup, enabled/disabled config, marketplace/policy gates
+
+Session / cross-day memory:
+
+* `/root/claude-code-haha/src/services/SessionMemory/sessionMemory.ts`
+* `/root/claude-code-haha/src/services/SessionMemory/sessionMemoryUtils.ts`
+* `/root/claude-code-haha/src/services/extractMemories/extractMemories.ts`
+* `/root/claude-code-haha/src/services/compact/sessionMemoryCompact.ts`
+
+### Analogous OSS
+
+OpenHands:
+
+* Runtime docs describe a client-server runtime using Docker containers.
+* Runtime README describes a `Runtime` interface, action execution client/server,
+  multiple implementations including local, Docker, and remote, and plugin
+  management.
+* Reusable essence: isolate runtime lifecycle and action execution behind a
+  formal runtime/control interface.
+
+opencode:
+
+* README describes provider-agnostic terminal coding agent with a TUI focus and
+  client/server architecture where the TUI is only one possible client.
+* Reusable essence: separate frontend clients from the backend agent/runtime
+  server.
+
+goose:
+
+* README describes desktop app, CLI, and API surfaces over one local agent.
+* Extension docs describe MCP-based extensions, enable/disable UX, extension
+  management, malware checks, access controls, and extension directory.
+* Reusable essence: extension lifecycle is a first-class product domain, not
+  just schema validation.
+
+## New Domain Boundaries
+
+Circle 2 should introduce new domains instead of stretching Circle 1 modules:
+
+* `daemon/`
+  * process lifecycle
+  * worker registry
+  * heartbeats
+  * durable run ownership
+  * restart/recovery
+* `worker_runtime/`
+  * worker execution state
+  * queued/running/cancelled/completed lifecycle
+  * run logs/events
+  * stop/cancel semantics
+* `events/` or `event_stream/`
+  * replayable user-visible events
+  * internal worker events
+  * delivery sequence/ack model
+  * remote/TUI/CLI consumers
+* `mailbox/`
+  * addressable messages
+  * inbox/outbox
+  * send/receive/ack
+  * permission response routing
+* `teams/` or `orchestration/`
+  * coordinator
+  * worker roles
+  * task assignment
+  * progress synthesis
+  * concurrency/write-scope rules
+* `remote/`
+  * remote session API
+  * SSE/WebSocket gateway
+  * control messages
+  * replay/reconnect
+* `extension_lifecycle/`
+  * install/enable/disable/update
+  * trust/source metadata
+  * rollback
+  * managed policy gates
+* `continuity/` or extended `memory/`
+  * cross-day session memory extraction
+  * richer agent-private memory
+  * long-session/cross-restart continuity policy
+
+Do not hide these inside:
+
+* `sessions/`
+* `subagents/tools.py`
+* `tool_system/`
+* `frontend/producer.py`
+
+## Circle 2 Waves
+
+### Wave 1: Durable Daemon / Worker / Event Substrate
+
+Goal:
+
+* establish real durable lifecycle semantics before mailbox/coordinator/remote
+  features are built
+
+Primary modules:
+
+* `daemon`
+* `worker_runtime`
+* `event_stream`
+* `runtime`
+* `sessions`
+
+Planned features:
+
+* local daemon command group
+* worker registry
+* durable worker records
+* heartbeat and stale-worker detection
+* restart-safe run ownership
+* event stream with visible and internal events
+* stop/cancel request model
+* replayable event sequence numbers
+
+Acceptance:
+
+* a background run can survive parent CLI exit as durable state
+* worker heartbeat/state can be inspected
+* stop/cancel is persisted and eventually observed
+* visible and internal events can be replayed in order
+
+Out of scope:
+
+* coordinator decisions
+* mailbox message routing
+* remote/IDE network API
+
+### Wave 2: Mailbox / SendMessage Substrate
+
+Goal:
+
+* add addressable message delivery for agents/workers/human permission flows
+
+Primary modules:
+
+* `mailbox`
+* `worker_runtime`
+* `permissions`
+* `event_stream`
+
+Planned features:
+
+* mailbox message schema
+* inbox/outbox
+* delivery status and ack
+* idempotent send
+* `SendMessage`-equivalent local tool
+* permission request/response messages
+* CLI/TUI mailbox inspection
+
+Acceptance:
+
+* worker can send message to parent/coordinator
+* parent can reply
+* permission request can route through mailbox without bypassing policy
+* duplicate delivery is harmless
+
+Out of scope:
+
+* autonomous coordinator planning
+* remote transport
+
+### Wave 3: Coordinator / Worker Team Runtime
+
+Goal:
+
+* add local team runtime with coordinator and bounded workers
+
+Primary modules:
+
+* `teams` or `orchestration`
+* `mailbox`
+* `worker_runtime`
+* `tasks`
+* `subagents`
+* `permissions`
+
+Planned features:
+
+* coordinator role
+* worker role
+* team task graph
+* worker assignment
+* progress synthesis
+* worker stop/cancel
+* write-scope/concurrency policy
+* verifier/acceptance integration
+
+Acceptance:
+
+* coordinator can decompose a complex task into worker jobs
+* workers report progress and results through mailbox/events
+* coordinator can synthesize final status
+* conflicting write scopes are blocked or serialized
+
+Out of scope:
+
+* remote/cloud workers
+* cross-machine team runtime
+
+### Wave 4: Remote / IDE Control Plane
+
+Goal:
+
+* make CLI/TUI only one consumer of a broader control plane
+
+Primary modules:
+
+* `remote`
+* `event_stream`
+* `daemon`
+* `frontend`
+* `mcp`
+
+Planned features:
+
+* local HTTP/SSE or WebSocket gateway
+* replayable session event stream
+* control messages
+* remote permission bridge
+* IDE MCP/control hooks
+* reconnect/replay
+
+Acceptance:
+
+* a non-TUI client can observe session events
+* a non-TUI client can issue bounded control messages
+* reconnect receives missed events
+* permission prompts remain policy-governed
+
+Out of scope:
+
+* hosted SaaS session ingress
+* multi-user auth
+
+### Wave 5: Extension Lifecycle
+
+Goal:
+
+* move beyond inspect/debug into install/enable/disable/update lifecycle
+
+Primary modules:
+
+* `extension_lifecycle`
+* `plugins`
+* `mcp`
+* `skills`
+* `hooks`
+* `permissions`
+
+Planned features:
+
+* local install source registry
+* enable/disable state
+* update metadata
+* trust/source policy
+* rollback
+* MCP/plugin dedup
+* managed policy gates
+* CLI/TUI extension manager surfaces
+
+Acceptance:
+
+* user can install/enable/disable/update a local extension
+* invalid/untrusted extension is blocked with clear reason
+* MCP/plugin duplicates are detected deterministically
+* rollback restores prior state
+
+Out of scope:
+
+* public marketplace backend
+* paid/hosted distribution
+
+### Wave 6: Cross-Day Continuity And Richer Memory
+
+Goal:
+
+* strengthen continuity beyond a single-day Circle 1 session
+
+Primary modules:
+
+* `memory`
+* `continuity`
+* `sessions`
+* `compact`
+* `daemon`
+
+Planned features:
+
+* richer session-memory extraction
+* cross-day memory artifacts
+* agent-private memory lifecycle
+* memory quality review
+* session-memory compact integration
+* away/resume summary
+* workspace migration/export/import
+
+Acceptance:
+
+* long-running work can resume across process restarts and days
+* current task, decisions, blockers, and next steps survive
+* stale memory is detected and refreshed
+* memory extraction remains bounded and auditable
+
+Out of scope:
+
+* organization/team memory sync unless explicitly scoped later
+
+### Circle 2 Final: Expanded Parity Acceptance Harness
+
+Acceptance workflows:
+
+* Workflow D: Durable background lifecycle
+  * start work
+  * parent exits
+  * worker state/events survive
+  * control plane can inspect/stop/resume
+* Workflow E: Local team execution
+  * coordinator decomposes
+  * workers execute bounded tasks
+  * mailbox/progress/result synthesis works
+* Workflow F: Remote/IDE control
+  * secondary client observes and controls a live session
+  * reconnect/replay is correct
+* Workflow G: Extension lifecycle
+  * install/enable/disable/update/rollback local extension
+* Workflow H: Cross-day continuity
+  * resume next day with session memory and evidence intact
+
+## Risks
+
+* Building coordinator before daemon will likely create process-local fake
+  durability.
+* Adding mailbox into `subagents` will make team routing hard to reason about.
+* Adding remote/IDE to frontend JSONL bridge will blur local transport with
+  control-plane API.
+* Extension lifecycle without trust/source policy can create unsafe defaults.
+
+## Out Of Scope For Circle 2 Unless Reopened
+
+* hosted SaaS control plane
+* multi-user auth/billing
+* public marketplace backend
+* enterprise managed settings sync
+* full organization/team memory sync
+
+## First Implementation Task
+
+Create:
+
+`.trellis/tasks/<date>-circle-2-wave-1-daemon-worker-event-substrate/`
+
+Goal:
+
+* implement the durable local daemon/worker/event substrate only
+
+Must state before coding:
+
+* durable worker record schema
+* event stream schema
+* stop/cancel semantics
+* heartbeat/stale policy
+* recovery/replay behavior
+* which existing Circle 1 background controls are migrated or left process-local

.trellis/plans/coding-deepgent-full-cc-parity-roadmap.md

@@ -277,6 +277,10 @@ Implemented checkpoint:
 Circle 2 begins only after Circle 1 is coherent enough to act as a daily-driver
 local coding agent.
 
+Canonical Circle 2 plan:
+
+* `.trellis/plans/coding-deepgent-circle-2-expanded-parity-plan.md`
+
 Likely Circle 2 bands:
 
 * mailbox / `SendMessage`

.trellis/project-handoff.md

@@ -21,6 +21,7 @@ Canonical goal/backlog docs:
 
 * `.trellis/tasks/archive/2026-04/04-14-redefine-coding-deepgent-final-goal/prd.md`
 * `.trellis/plans/coding-deepgent-full-cc-parity-roadmap.md`
+* `.trellis/plans/coding-deepgent-circle-2-expanded-parity-plan.md`
 * `.trellis/plans/coding-deepgent-cc-core-highlights-roadmap.md` (historical MVP dashboard)
 
 ## Minimal Resume Procedure
@@ -201,6 +202,9 @@ Latest completed stages and what they changed:
   * `coding-deepgent sessions history|projection|timeline|evidence|events|permissions` expose resume/history/projection/recovery state without raw JSONL inspection
   * `coding-deepgent skills|mcp|hooks|plugins list|inspect|validate|debug` expose usable local extension inspect/debug seams
   * `coding-deepgent acceptance circle1` records the deterministic local Circle 1 acceptance boundary for workflows A/B/C
+* `2026-04-20 Circle 2 planning`
+  * `.trellis/plans/coding-deepgent-circle-2-expanded-parity-plan.md` defines the substrate-first Circle 2 execution sequence
+  * Circle 2 Wave 1 should start with durable daemon/worker/event substrate before mailbox/coordinator/remote features
 
 ## Current Active Topology
 
@@ -243,8 +247,10 @@ Core domains:
 Next planned direction:
 
 * Circle 1 local daily-driver parity is now implemented as the current baseline
-* next work should begin Circle 2 only after release/PR validation, or else
-  address concrete Circle 1 regressions found by acceptance workflows
+* next implementation wave should be Circle 2 / Wave 1:
+  durable daemon / worker / event substrate
+* use `.trellis/plans/coding-deepgent-circle-2-expanded-parity-plan.md` as the
+  canonical Circle 2 execution plan
 
 Intent:
 

.trellis/tasks/04-20-brainstorm-circle-2-parity-plan/prd.md

@@ -0,0 +1,225 @@
+# brainstorm: Circle 2 parity execution plan
+
+## Goal
+
+制定 `coding-deepgent` 的 `Circle 2` 专项执行计划，承接已完成的 Circle 1 local daily-driver parity baseline，明确 expanded product parity 的 waves、domain boundaries、source evidence、OSS fallback 触发点、验收方式和明确 out-of-scope。
+
+## What I already know
+
+* Circle 1 baseline 已完成并验证，包含 runtime core、CLI/TUI visibility/control、local extension inspect/debug surfaces、acceptance harness。
+* Circle 2 不是继续补 CLI 小功能，而会引入 mailbox/coordinator/remote/IDE/daemon/extension lifecycle/cross-day continuity 等新架构边界。
+* 现有 roadmap 已把 Circle 2 定位为 expanded product parity。
+* 用户要求规划要对照 Claude Code / `cc-haha`，缺源码时先搜索高质量类似 OSS。
+* `cc-haha` 有 worker lifecycle / session ingress / task events / mailbox / coordinator / daemon / cron / plugin lifecycle / session memory 的源码线索。
+* OpenHands、opencode、goose 的公开源码/文档支持把 Circle 2 规划成 runtime substrate、client/server/control plane、extension lifecycle、memory/continuity 的架构序列。
+
+## Assumptions (temporary)
+
+* 本次 brainstorm 只制定 Circle 2 专项计划，不直接实现。
+* Circle 2 需要拆成多个执行 wave，每个 wave 可独立 task 化、验证、归档。
+* Circle 2 仍以本地产品价值为主，不做无价值的 closed-source 外观复制。
+
+## Open Questions
+
+* none
+
+## Requirements (evolving)
+
+* 明确 Circle 2 included / excluded boundaries。
+* 每个 wave 必须说明 user/runtime effect、source evidence、domain ownership、acceptance criteria。
+* 标记哪些能力需要 OSS fallback research。
+* 避免污染现有 `sessions/`, `subagents/`, `runtime/`, `tool_system/` 边界。
+* 明确 Circle 2 需要新增哪些 domain，例如 `mailbox`, `teams`, `daemon`, `remote`, `extension_lifecycle`。
+* 明确哪些当前 Circle 1 能力只能作为 substrate，不能继续直接扩张，例如 active TUI background subagent control 不能假装是 daemon。
+
+## Acceptance Criteria (evolving)
+
+* [ ] Circle 2 plan defines waves and sequencing.
+* [ ] Plan includes source evidence and missing-source fallback rules.
+* [ ] Plan defines new domain boundaries.
+* [ ] Plan defines Circle 2 acceptance harness.
+* [ ] Plan states out-of-scope / deferred items.
+* [ ] Plan asks maintainer to pick one sequencing strategy before implementation.
+
+## Definition of Done (team quality bar)
+
+* Trellis plan created/updated.
+* PRD records final decisions.
+* Source/OSS research notes captured where needed.
+* No code implementation begins until plan is approved.
+
+## Out of Scope (explicit)
+
+* Implementing Circle 2 runtime code in this brainstorm task.
+* Reopening Circle 1 unless planning finds a hard dependency.
+* Marketplace distribution or remote SaaS backend implementation details unless needed for sequencing.
+
+## Technical Notes
+
+* Initial source of truth: `.trellis/plans/coding-deepgent-full-cc-parity-roadmap.md`
+* Resume status: `.trellis/project-handoff.md`
+* Prior Circle 1 completion commits: `7248889`, `386602b`, `f073945`
+
+## Auto-Context Findings
+
+### Local `coding-deepgent` constraints
+
+* Circle 1 added local file-backed `runtime.store`, session JSONL ledger, recovery/evidence/compact/collapse views, active TUI bridge controls, and extension inspect/debug surfaces.
+* Current background subagent worker handles are process-local. Cross-process lifecycle requires a new daemon/worker substrate, not more CLI commands over the current manager.
+* Current `subagents` domain supports bounded child/fork execution and background records, but not mailbox, coordinator, worker addressing, team routing, or durable delivery.
+* Current `sessions` domain owns transcript/evidence/resume; it should not become a generic team/orchestration database.
+* Current `plugins` and `mcp` are local inspect/debug seams; install/enable/update/trust lifecycle is intentionally outside Circle 1.
+
+### `cc-haha` source notes
+
+* Worker/session ingress:
+  * `/root/claude-code-haha/src/cli/transports/ccrClient.ts`
+  * worker lifecycle protocol, `PUT /worker`, heartbeat, event upload, internal events, restore after worker restart.
+* Task lifecycle / stop control:
+  * `/root/claude-code-haha/src/cli/print.ts`
+  * `task_started`, `task_progress`, `task_notification`, `session_state_changed`, `stop_task`.
+  * `/root/claude-code-haha/src/entrypoints/sdk/controlSchemas.ts`
+  * explicit `stop_task` control schema.
+* Mailbox / swarm permission:
+  * `/root/claude-code-haha/src/context/mailbox.tsx`
+  * `/root/claude-code-haha/src/hooks/useInboxPoller.ts`
+  * `/root/claude-code-haha/src/hooks/useSwarmPermissionPoller.ts`
+  * worker/leader permission messages and inbox polling.
+* Coordinator:
+  * `/root/claude-code-haha/src/cli/print.ts`
+  * `coordinatorModeModule`, coordinator resume matching, worker-related status.
+  * `/root/claude-code-haha/src/components/PromptInput/*`
+  * coordinator task UI selection.
+* Remote / IDE control:
+  * `/root/claude-code-haha/src/cli/transports/SSETransport.ts`
+  * `/root/claude-code-haha/src/cli/transports/WebSocketTransport.ts`
+  * `/root/claude-code-haha/src/remote/*`
+  * `/root/claude-code-haha/src/services/mcp/vscodeSdkMcp.ts`
+* Daemon / cron / proactive:
+  * `/root/claude-code-haha/src/entrypoints/cli.tsx`
+  * `--daemon-worker`
+  * `/root/claude-code-haha/src/cli/print.ts`
+  * cron scheduler and proactive tick references.
+  * `/root/claude-code-haha/src/skills/bundled/loop.ts`
+  * `/root/claude-code-haha/src/skills/bundled/scheduleRemoteAgents.ts`
+* Extension lifecycle:
+  * `/root/claude-code-haha/src/services/plugins/pluginOperations.ts`
+  * `/root/claude-code-haha/src/services/plugins/PluginInstallationManager.ts`
+  * `/root/claude-code-haha/src/services/mcp/config.ts`
+  * plugin MCP loading, dedup, enabled/disabled config, marketplace/policy gates.
+* Session/cross-day memory:
+  * `/root/claude-code-haha/src/services/SessionMemory/sessionMemory.ts`
+  * `/root/claude-code-haha/src/services/extractMemories/extractMemories.ts`
+  * `/root/claude-code-haha/src/services/compact/sessionMemoryCompact.ts`
+
+## Research Notes
+
+### What similar tools do
+
+* OpenHands uses a sandbox/runtime client-server architecture with clear runtime interfaces, action execution server, event stream, and multiple runtime implementations including Docker/local/remote. Relevant sources: OpenHands runtime docs and `openhands/runtime/README.md`.
+* opencode advertises provider-agnostic TUI and client/server architecture, where TUI is only one possible client.
+* goose is a local desktop/CLI/API agent and treats extensions as MCP-based with install/enable/disable and access-control concepts.
+
+### Constraints from our repo/project
+
+* LangChain/LangGraph-native runtime should remain the hidden implementation default.
+* Existing `runtime.store` can support durable records, but not durable process worker handles.
+* Team/multi-agent runtime must not be added by overloading `run_subagent`, `sessions`, or `task` records.
+* Remote/IDE surfaces must be separate from CLI/TUI JSONL bridge.
+
+### Feasible approaches here
+
+**Approach A: Substrate-first Circle 2** (Recommended)
+
+* How it works:
+  * Wave 1 daemon/worker/session-event substrate.
+  * Wave 2 mailbox/send-message over durable substrate.
+  * Wave 3 coordinator/worker team runtime.
+  * Wave 4 remote/IDE control plane.
+  * Wave 5 extension lifecycle.
+  * Wave 6 cross-day continuity/memory.
+* Pros:
+  * Avoids fake mailbox/team features over process-local handles.
+  * Aligns with `cc-haha` worker/session ingress evidence and OpenHands/opencode client/server patterns.
+  * Gives later coordinator/remote work a real lifecycle foundation.
+* Cons:
+  * First wave is infrastructure-heavy and user-visible payoff is delayed.
+
+**Approach B: User-visible team first**
+
+* How it works:
+  * Build mailbox/coordinator user flows first using current file store and active process.
+  * Add daemon/remote later.
+* Pros:
+  * Faster visible parity with Agent/teams concepts.
+  * Good for demos.
+* Cons:
+  * High risk of repeating the Circle 1 background-subagent problem: process-local behavior masquerading as durable team runtime.
+  * Likely refactor later.
+
+**Approach C: Remote/IDE first**
+
+* How it works:
+  * Turn existing frontend SSE/gateway into a remote control plane first.
+  * Then add worker/session ingress and coordinator.
+* Pros:
+  * UI/control-plane progress is visible quickly.
+  * Aligns with opencode multi-client and OpenHands client/server directions.
+* Cons:
+  * Remote UI without daemon/worker substrate can become thin transport over weak lifecycle.
+  * Coordinator/mailbox still need later architectural work.
+
+## Expansion Sweep
+
+### Future evolution
+
+* Circle 2 likely becomes the boundary where `coding-deepgent` needs durable process orchestration, not only in-memory background threads.
+* Remote/IDE/daemon work should preserve a future API surface, not hard-code one CLI/TUI implementation.
+
+### Related scenarios
+
+* Permission prompts from workers must route to a leader/human without bypassing current permission policy.
+* Task/progress events should reuse session evidence/event stream concepts but not pollute transcript messages.
+
+### Failure and edge cases
+
+* Worker crash/restart, duplicate delivery, stale run ownership, stop/cancel races.
+* Message delivery idempotency, permission response timeout, remote reconnect/replay.
+* Extension install/enable trust and rollback.
+
+## Preliminary Recommendation
+
+Use Approach A: substrate-first. Circle 2 should start with a durable daemon/worker/session-event substrate, then mailbox, then coordinator/team runtime, then remote/IDE, then extension lifecycle, then cross-day memory.
+
+## Decision (ADR-lite)
+
+**Context**: Circle 2 introduces durable background lifecycle, mailbox, coordinator/team runtime, remote/IDE control, extension lifecycle, and cross-day continuity. These features cannot safely be modeled as more fields on current process-local subagent/background APIs.
+
+**Decision**: Use Approach A, substrate-first. Build durable daemon/worker/session-event substrate before mailbox/coordinator/remote features.
+
+**Consequences**:
+
+* First Circle 2 implementation wave will be infrastructure-heavy.
+* Later mailbox/coordinator/remote/IDE features can build on real lifecycle semantics instead of fake process-local handles.
+* Current Circle 1 active-TUI background controls remain valid as local process features, but not as durable team runtime.
+
+## Final Requirements
+
+* Create a Circle 2 execution plan that starts with daemon/worker/session-event substrate.
+* Split Circle 2 into ordered waves with clear scope, domain ownership, and acceptance criteria.
+* Include source evidence and OSS fallback notes for each wave.
+* Explicitly prevent boundary pollution in `sessions`, `subagents`, `runtime`, and `tool_system`.
+* Define Circle 2 acceptance harness before implementation begins.
+
+## Final Acceptance Criteria
+
+* [x] Circle 2 plan defines waves and sequencing.
+* [x] Plan includes source evidence and missing-source fallback rules.
+* [x] Plan defines new domain boundaries.
+* [x] Plan defines Circle 2 acceptance harness.
+* [x] Plan states out-of-scope / deferred items.
+* [x] Plan asks maintainer to pick one sequencing strategy before implementation.
+
+## Output
+
+* `.trellis/plans/coding-deepgent-circle-2-expanded-parity-plan.md`

.trellis/tasks/04-20-brainstorm-circle-2-parity-plan/task.json

@@ -0,0 +1,44 @@
+{
+  "id": "brainstorm-circle-2-parity-plan",
+  "name": "brainstorm-circle-2-parity-plan",
+  "title": "brainstorm: Circle 2 parity execution plan",
+  "description": "",
+  "status": "completed",
+  "dev_type": "docs",
+  "scope": null,
+  "priority": "P2",
+  "creator": "kun",
+  "assignee": "kun",
+  "createdAt": "2026-04-20",
+  "completedAt": "2026-04-20",
+  "branch": null,
+  "base_branch": "codex/stage-12-14-context-compact-foundation",
+  "worktree_path": null,
+  "current_phase": 0,
+  "next_action": [
+    {
+      "phase": 1,
+      "action": "implement"
+    },
+    {
+      "phase": 2,
+      "action": "check"
+    },
+    {
+      "phase": 3,
+      "action": "finish"
+    },
+    {
+      "phase": 4,
+      "action": "create-pr"
+    }
+  ],
+  "commit": null,
+  "pr_url": null,
+  "subtasks": [],
+  "children": [],
+  "parent": null,
+  "relatedFiles": [],
+  "notes": "",
+  "meta": {}
+}