这份文档真正覆盖什么
v0.8.8 协调器提示词文档说明了某个版本里编排行为是怎样被塑造的,以及协调器指令为什么会直接影响代理结果。
怎么用这页
- 先看右侧目录,直接跳到你当前最关心的小节。
- 如果你只是来解决具体问题,优先读正文里的相关标题,再回站内对应 hub。
- 如果你要核对原始来源,可以直接打开 GitHub 原文链接。
v0.8.8 协调器提示词文档说明了某个版本里编排行为是怎样被塑造的,以及协调器指令为什么会直接影响代理结果。
v0.8.8 协调器提示词文档说明了某个版本里编排行为是怎样被塑造的,以及协调器指令为什么会直接影响代理结果。
Feed this entire document as a single message to a coordinating agent in YOLO mode (deepseek --mode yolo or /mode yolo). The coordinator will decompose the v0.8.8 milestone into independent workstreams, spawn sub-agents into git worktrees, monitor progress, and integrate results.
You are a coordinating agent responsible for delivering the v0.8.8 milestone. You must NOT attempt to implement issues yourself. Your job is to:
update_plan.agent_list / agent_result.cargo check, cargo clippy, cargo test) after each integration.All issues with the v0.8.8 label on GitHub, plus the 23 v0.8.6 carry-forward issues listed in #482. Use gh issue list --label v0.8.8 --state open --limit 100 to enumerate them. For the carry-forward list, read issue #482 to get the full set of issue numbers.
Read every issue body before spawning work. You need to understand cross-cutting concerns (which issues touch the same files, which depend on others).
Group the issues into these workstreams. The exact issue-to-stream mapping is for you to determine after reading every issue, but this is the expected shape:
worktrees/tui-bugfixesworktrees/opencode-*.worktrees/agent-uxworktrees/app-serverdeepseek serve --http.worktrees/web-uiworktrees/vscodeEach workstream gets its own git worktree to prevent file conflicts, stale checkouts, and merge headaches:
# Bootstrap (you do this once, before spawning sub-agents):
git worktree add ../worktrees/tui-bugfixes -b feat/v0.8.8-tui-bugfixes
git worktree add ../worktrees/opencode-permissions -b feat/v0.8.8-opencode-permissions
git worktree add ../worktrees/opencode-lsp-hooks -b feat/v0.8.8-opencode-lsp-hooks
git worktree add ../worktrees/opencode-config -b feat/v0.8.8-opencode-config
git worktree add ../worktrees/opencode-agents -b feat/v0.8.8-opencode-agents
git worktree add ../worktrees/opencode-misc -b feat/v0.8.8-opencode-misc
git worktree add ../worktrees/agent-ux -b feat/v0.8.8-agent-ux
git worktree add ../worktrees/app-server -b feat/v0.8.8-app-server
git worktree add ../worktrees/web-ui -b feat/v0.8.8-web-ui
git worktree add ../worktrees/vscode -b feat/v0.8.8-vscode
When spawning a sub-agent, set its cwd to the corresponding worktree path. The sub-agent works entirely within that worktree and never touches the main checkout or other worktrees.
Once issue #452 (worktree manager) is completed, you may switch to using /worktree new instead of manual git worktree add. Until then, use the manual approach above.
For each workstream, spawn one or more sub-agents:
agent_spawn(
type: "general",
cwd: "../worktrees/<name>",
prompt: "<detailed workstream prompt, including specific issue numbers and acceptance criteria>"
)
Each sub-agent prompt should include:
gh issue view <N> before implementing.cargo check and cargo test --workspace --all-features before reporting completion.feat(v0.8.8): <issue title> (fixes #NNN).For large streams (B, E, F), subdivide further: spawn one sub-agent per subsystem, each in its own worktree. Do NOT spawn one agent for all 35 OPENCODE issues — it will thrash.
Parallelism rule: spawn independent workstreams concurrently. Example: once worktrees exist, spawn A, B-permissions, B-lsp-hooks, B-config, B-agents, and B-misc all in one turn (up to 5 max in flight). When some complete, spawn the next batch.
Merge worktrees in this order to minimize conflicts:
opencode-config (config/profile changes — other things depend on config shape) b. opencode-permissions (permission model — agents depend on it) c. opencode-lsp-hooks (LSP and hooks infrastructure) d. opencode-agents (subagent infrastructure — needed by Stream C) e. opencode-misc (everything else in Stream B)For each merge:
cd /Volumes/VIXinSSD/deepseek-tui # main worktree
git merge feat/v0.8.8-<stream> --no-ff -m "merge(v0.8.8): <stream> workstream"
Run verification gates after every merge:
cargo check --workspace --all-features
cargo clippy --workspace --all-targets --all-features
cargo test --workspace --all-features
If a merge fails or gates break, do NOT proceed to the next stream. Diagnose, report the conflict, and either fix it yourself or spawn a remediation sub-agent.
These areas have high collision risk across streams:
| Area | Streams touching it | Mitigation |
|---|---|---|
crates/tui/src/tools/subagent/ | A (#421, #409), B (#404, #405, #425, #426), C (#407) | Assign subagent tooling changes to B-agents ONLY. Streams A and C depend on B-agents completing first. |
crates/tui/src/tui/sidebar.rs | A (#409), C (#403, #407, #408) | Assign ALL sidebar changes to Stream C. Stream A skips #403, #409. |
crates/app-server/ | D (all), E (#471, #472, #475), F (#462, #463) | Stream D completes first. Streams E and F build on D's stable API. |
crates/execpolicy/ | B (#410–#418) | All execpolicy changes in B-permissions only. |
crates/config/ | B (#436, #437, #454), D (#475) | All config changes in B-config first. Stream D reads the new config shape. |
Cargo.toml / workspace members | E (new apps/web/ crate), F (new extensions/vscode/), B (new crates) | New crate additions handled in their respective streams. Merge order prevents Cargo.toml conflicts — add new members in dependency order. |
The coordinator is responsible for detecting file-level overlaps when reading issue bodies and adjusting assignments so no two workstreams independently modify the same file.
Every sub-agent must pass these before reporting completion:
cargo check --workspace --all-features
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo test --workspace --all-features
cargo fmt --all -- --check
After every merge, the coordinator runs the same gates on the main worktree. Use task_gate_run to record structured evidence.
For the Web UI stream (E), also verify:
cd apps/web && npm run build
For the VS Code stream (F), also verify:
cd extensions/vscode && npm run compile
Use update_plan with phases matching the integration order:
in_progresspendingpendingpendingpendingpendingpendingpendingUse checklist_write under each phase with individual sub-agent tasks. Update status as sub-agents complete.
agent_result, diagnose, and either respawn with corrected instructions or fix the issue in the worktree directly.worktrees/merge-fix-<name>), spawn a sub-agent to resolve the conflict, and retry the merge.These issues are explicitly NOT implemented in 0.8.8:
Read each umbrella issue (#480, #481) carefully — they may scope some child issues as "Phase 2" or "deferred." Only implement what's accepted for 0.8.8.
gh issue list --label v0.8.8 --state open --limit 100 --json number,title,body,labels and read every body.gh issue view 482 to get the v0.8.6 carry-forward list, then read those issue bodies.update_plan with the 8 phases above.