Status

Summary

已完成 issue worktree manager 讨论 #13 与当前仓库实现的对照分析，结论是："把现有 worktree-manager 直接改成 OpenCode 插件并让 OpenCode 额外暴露 create_worktree HTTP 接口"在当前代码架构下不属于低风险改造。
当前仓库已明确采用“Bridge -> companion service(worktree-manager) -> OpenCode session/prompt_async”的分层链路，边界清晰、可跨 Agent 复用。
综合可行性与通用性，建议短期不做“并入 OpenCode 插件并暴露 HTTP 路由”的重构，优先做契约标准化与可插拔 provider 抽象。

已读取 issue 正文与线程评论。
已检查架构与文档：AGENTS.md、README.md、plugins/worktree-manager/README.md。
已检查核心代码路径：internal/agent/opencode.go、internal/agent/worktree_manager.go、plugins/worktree-manager/main.go、internal/config/config.go、cmd/server/main.go。
已通过 Context7 检索 OpenCode 插件文档：现有资料强调插件可扩展 hooks/tools，但未发现“插件向 OpenCode server 动态注册 HTTP 路由”的明确能力描述。

先做决策澄清（ADR 级）：明确目标是“OpenCode 内部插件化路由”还是“Bridge 侧可插拔 worktree provider”。建议将目标定义为后者，保持与具体 Agent 解耦。
抽象 provider 契约（不改行为）：在设计层定义 WorktreeProvider 能力面（create/reuse/health/auth/error/idempotency），让当前 worktree-manager 成为首个实现。
配置模型演进：在 internal/config/config.go 规划从单一 worktree_manager_host 走向 provider 化配置（含默认 provider、repo 级覆盖、超时和鉴权），并给出兼容映射策略。
调用链解耦设计：在 internal/agent/opencode.go 的 ensureWorktree 路径设计 provider 接口注入点，保持 DispatchTask fire-and-forget 语义不变。
保留现有 companion service：plugins/worktree-manager/main.go 继续作为默认实现；仅补充“可替换实现”的契约文档与错误码约定。
验证与回归方案：补充契约级测试清单（issue/pr_worktree 复用、PR head 刷新、鉴权、异常返回），并确认 internal/agent/opencode_test.go 与 plugins/worktree-manager/main_test.go 的覆盖扩展点。

现状分析：当前仓库并不存在 OpenCode server 路由扩展机制；Bridge 仅配置并调用外部 worktree manager HTTP 服务。
风险与影响：若强行改为“OpenCode 插件 + 新 HTTP 路由”，将引入对 OpenCode 内核能力与版本行为的耦合，且弱化“可接入其它 AI agent”的通用性目标。
建议路线：短期“标准化 companion service + provider 抽象”，中期可单独立项做 OpenCode 插件化 Spike（仅验证，不直接替换生产链路）。
测试建议：优先保留现有行为回归，再增加 provider 兼容测试，确保 issue/pr 两类任务的 worktree 隔离与复用规则不回退。