From 243be04fecdb6d8b69fcfd80fb374bed7c6aef0e Mon Sep 17 00:00:00 2001 From: Kun Date: Mon, 20 Apr 2026 05:53:51 +0800 Subject: [PATCH] docs(plan): add circle 2 expanded parity plan --- ...-deepgent-circle-2-expanded-parity-plan.md | 474 ++++++++++++++++++ .../coding-deepgent-full-cc-parity-roadmap.md | 4 + .trellis/project-handoff.md | 10 +- .../prd.md | 225 +++++++++ .../task.json | 44 ++ 5 files changed, 755 insertions(+), 2 deletions(-) create mode 100644 .trellis/plans/coding-deepgent-circle-2-expanded-parity-plan.md create mode 100644 .trellis/tasks/04-20-brainstorm-circle-2-parity-plan/prd.md create mode 100644 .trellis/tasks/04-20-brainstorm-circle-2-parity-plan/task.json diff --git a/.trellis/plans/coding-deepgent-circle-2-expanded-parity-plan.md b/.trellis/plans/coding-deepgent-circle-2-expanded-parity-plan.md new file mode 100644 index 0000000..4b134b7 --- /dev/null +++ b/.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/-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 diff --git a/.trellis/plans/coding-deepgent-full-cc-parity-roadmap.md b/.trellis/plans/coding-deepgent-full-cc-parity-roadmap.md index c8b31f4..2c98095 100644 --- a/.trellis/plans/coding-deepgent-full-cc-parity-roadmap.md +++ b/.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` diff --git a/.trellis/project-handoff.md b/.trellis/project-handoff.md index 0ae2b9a..0156d95 100644 --- a/.trellis/project-handoff.md +++ b/.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: diff --git a/.trellis/tasks/04-20-brainstorm-circle-2-parity-plan/prd.md b/.trellis/tasks/04-20-brainstorm-circle-2-parity-plan/prd.md new file mode 100644 index 0000000..708b681 --- /dev/null +++ b/.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` diff --git a/.trellis/tasks/04-20-brainstorm-circle-2-parity-plan/task.json b/.trellis/tasks/04-20-brainstorm-circle-2-parity-plan/task.json new file mode 100644 index 0000000..19f2cf0 --- /dev/null +++ b/.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": {} +}