Gas Town Convoy 稳定性路线图从管道可靠性到自主史诗磨削的分阶段演进【免费下载链接】gastownGas Town - multi-agent workspace manager项目地址: https://gitcode.com/GitHub_Trending/ga/gastown导读本文是 Gas Town多 Agent 工作区管理器中Convoy车队系统稳定性路线图的完整解读。Convoy 是 Gas Town 中跨 rig 批量工作的核心跟踪单元本文围绕其演进路线梳理了从当前手工创建 bead 批量 sling的现状到gt convoy stage/launch分阶段调度、子史诗评审门禁、直至 Mountain-Eater 自主史诗磨削的目标形态。读完本文你将掌握 Convoy 系统的三大保留工作流、sling→done→refinery 管道上的六大关键失效点、五个里程碑的依赖关系以及每一阶段的源码级实现依据涉及 internal/convoy/operations.go、internal/daemon/convoy_manager.go、internal/cmd/convoy_stage.go 等核心文件。1. 背景Convoy 系统当前状态在 Gas Town 中Convoy是跨 rig 跟踪一批相关 issue 的持久化单元hq-cv-*前缀存在于 town 级 beads 中而Swarm蜂群只是当前正在这批 issue 上工作的 polecat 集合是临时性的。二者的关系、生命周期与基础命令在 docs/concepts/convoy.md 中有完整说明。路线图文档给出的当前状态非常明确Milestone 0基础已全部完成所有基础 PR 已合并。接下来的工作不是重建系统而是在保留现有工作流的前提下修复用户实际遇到的可靠性问题并逐步走向目标 UX。关联主文档docs/design/convoy/roadmap.md配套规格文档docs/design/convoy/spec.md、docs/design/convoy/convoy-lifecycle.md。2. 必须保留的三种现有工作流路线图反复强调一个约束演进不能破坏现有工作流。以下是社区当前实际使用的三种模式。2.1 工作流 A手工创建 bead 批量 sling这是当前最常见的模式bd create --typetask Fix auth timeout → sh-task-1 bd create --typetask Add validation → sh-task-2 bd create --typetask Integration tests → sh-task-3 bd dep add sh-task-2 sh-task-1 --typeblocks gt sling sh-task-1 sh-task-2 sh-task-3 gastown在批量 sling对应 PR #1759 时代行为下实际发生的处理流程是批量 sling 会创建一个 convoy跟踪全部 3 个任务而非每个任务一个 convoyrig 从 bead 前缀自动解析resolveRigFromBeadIDs位于 internal/cmd/sling_batch.go显式指定 rig 已被弃用任务以 2 秒间隔顺序 sling共享同一个 convoyblocks依赖会被 daemon 喂料器feeder尊重——sh-task-2 在 sh-task-1 关闭前不会被 daemon 喂料但初始调度会把所有任务无条件派发出去无视依赖。用户的期望是任务按依赖顺序派发被阻塞的任务在其阻塞者关闭前不被 sling完成任务经由 refinery 落到目标分支。这一初始调度并行、后续喂料尊重依赖的语义在 internal/convoy/operations.go 的feedNextReadyIssue中有清晰的实现证据每次 close 事件后只派发一个 ready issue且必须通过IsSlingableType与isIssueBlocked双重过滤。2.2 工作流 Bdesign-to-beads 手工 sling/design-to-beads PRD.md → creates: root epic, sub-epics, leaf tasks → adds: parent-child deps (organizational hierarchy) → adds: blocks deps (execution ordering between tasks) gt sling task1 task2 task3 gastown与工作流 A 的最终结果一致一个共享 convoy、blocks依赖由 daemon 喂料器尊重。epic 与 sub-epic 结构存在于 beads 中并影响 daemon 驱动的喂料——epic 通过IsSlingableType被过滤不会派发给 polecat被阻塞的任务等待其阻塞者关闭。2.3 工作流 C手工创建 convoygt convoy create Auth overhaul sh-task-1 sh-task-2 sh-task-3 gt sling sh-task-1 gastown → witness feeds sh-task-2 when sh-task-1 closes (serial) → witness feeds sh-task-3 when sh-task-2 closes (serial) → convoy auto-closes when all 3 are done这条路径在上游 main 分支可用但是串行的一次只跑一个任务且 witness 喂料会忽略blocks依赖、类型过滤与 rig 容量。这正是路线图要解决的结构性矛盾工作流 A/B 能并行但初始派发无视依赖工作流 C 尊重串行顺序但过慢且无过滤。目标 UX 试图把两者的优点合并。3. 目标 UX分阶段调度的理想形态路线图给出的最终体验如下/design-to-beads PRD.md → creates: root epic → sub-epics → leaf tasks → adds: parent-child (hierarchy) blocks (ordering) deps → sub-epics get integration branches gt convoy stage epic-id → walks DAG, validates structure, displays route plan (tree waves) → creates staged convoy tracking all beads gt convoy launch convoy-id → activates convoy, dispatches Wave 1 tasks → daemon feeds subsequent waves as tasks close → sub-epic status auto-managed (open → in_progress → closed) → when sub-epic closes: sling sub-epic with review formula → review formula examines accumulated changes on integration branch → on approval: integration branch lands to main/parent branch → convoy closes when root epic closes这一目标在仓库中已具备实现骨架internal/cmd/convoy_stage.go 实现了 DAG 行走、校验、wave 计算、树/波次路线图展示与staged_ready/staged_warnings状态创建internal/cmd/convoy_launch.go 实现激活与 Wave 1 派发。详细 PRD 见 docs/design/convoy/stage-launch/prd.md。4. 用户实际报告的问题两类失效点路线图最有价值的部分是它对用户到底在抱怨什么的诚实盘点。最常见的抱怨是任务无法通过 refinery 落到目标分支。文档明确指出——这不是 convoy 的问题而是sling→done→refinery 管道可靠性问题convoy 系统只是叠加在这条管道之上。4.1 独立于 convoy 的关键失效点影响所有 polecat 工作#失效位置严重度恢复方式1Dolt 分支合并失败done.go已解决由 all-on-main 架构消除不再有 per-polecat Dolt 分支。2Push 失败全部 3 层done.go:531-572严重仅本地提交。工作树保留。需要手工恢复。3MR bead 创建失败done.go:744-752高分支已推送但无 MR。通知 witness。无自动恢复。4Refinery 永不唤醒Agent 停滞Agent 层高心跳会重启但间隙可能长达数分钟。5合并冲突无限期阻塞 MRengineer.go:764-786中必须派发冲突任务并解决。rig 满载时会停滞。6孤立 MR分支被删、MR 仍打开engineer.go:1086-1198中异常检测可发现。需 Agent 处理。文档强调这些失效影响所有polecat 工作无论是否被 convoy 跟踪修复它们将惠及整个系统。这也是 Milestone 1 被定位为最高影响力工作的原因——如果底层管道会丢任务convoy 再完善也无法兑现任务落地的承诺。4.2 Convoy 特有失效点Milestone 0 的修复清单#失效修复方式状态7被阻塞任务仍被 sling忽略 blocks 依赖isIssueBlockedPR #1759未合并8epic 被 sling 给 polecat无类型过滤IsSlingableTypePR #1759未合并9跨 rig 关闭事件对 daemon 不可见多 rig SDK 轮询已合并10close 后 daemon 不喂下一个任务连续喂料continuation feeding已合并11Refinery convoy 检查传错路径从未生效移除该调用已合并12首次派发失败导致整个 convoy 被弃派发失败迭代PR #1759未合并13stranded 扫描仅报告、不自动派发feedFirstReady已合并其中 #9 和 #10 在 internal/daemon/convoy_manager.go 中有对应实现daemon 内驻留的ConvoyManager运行两个 goroutine——事件轮询每 5 秒调用GetAllEventsSince覆盖所有 rig store hq与stranded 扫描每 30 秒执行gt convoy stranded --json作为崩溃/重启后的安全网。#11 的根因refinery 传入了 rig path 而非 town root导致CheckConvoysForIssueWithAutoStore静默返回 nil在 docs/design/convoy/spec.md 的 S-17/S-18 故事中有完整记录。5. 分阶段计划五个里程碑Milestone 0奠定基础已完成所有基础 PR 已合并。文档特别强调 PR #1759feeder 安全护栏即上表 #7/#8/#12 的修复仍需评审与合并以补全此里程碑。Milestone 1管道可靠性独立于 convoy目标修复导致任务不落地投诉的 sling→done→refinery 管道失效。#问题建议修复复杂度1aDolt 分支合并失败已解决——all-on-main 消除 per-polecat Dolt 分支。N/A1bDolt 分支上的 stranded MR beads已解决——不再有可搁浅的 per-polecat Dolt 分支。N/A1cRefinery Agent 停滞加固 refinery 心跳增加 daemon 级 MR 队列监视器当 MR 超阈值未处理时 nudge或重启refinery。中1d合并冲突无限期阻塞跟踪冲突任务年龄N 小时未解决则升级至 Mayor/owner附具体冲突细节。低此里程碑独立于 convoy 工作可由不同贡献者并行推进或排在 Milestone 0 之后。Milestone 2stage 与 launchgt convoy stage、gt convoy launch目标打通/design-to-beads → gt convoy stage → gt convoy launch工作流。依赖Milestone 0喂料器必须尊重 blocks 依赖并过滤类型staged convoy 才能正确工作。交付内容源自 Phase 2 PRDgt convoy stage bead-id——DAG 行走、校验、wave 计算、树 wave 路线图展示gt convoy launch convoy-id——激活 convoy、派发 Wave 1epic 状态管理open → in_progress → closedintegration branch 感知缺失时告警staged 状态流转staged_ready ↔ staged_warnings → open。已定的关键设计决策parent-child仅具组织意义永不阻塞与bd ready及 beads SDK 对齐执行顺序通过显式blocks依赖表达wave 计算仅作展示信息性运行时派发使用每周期的isIssueBlocked检查更动态能应对外部状态变化integration branch 的创建与落地保持手工或由 refinery 自动落地。此阶段尚不能实现子史诗评审公式Milestone 3、史诗 sling 的自动公式检测Phase 3、协调者 polecatPhase 3。实现层面internal/cmd/convoy_stage.go 已经支持三种输入形态epic ID、任务列表、convoy ID、错误/警告分类输出、--json机器可读输出以及 restage 语义重新分析并更新状态而非新建 convoywave 计算使用拓扑排序并处理 gated 任务如被未关闭任务门控的情况的告警提示。Milestone 3子史诗评审门禁目标当子史诗下所有任务完成并合并到该子史诗的 integration branch 后在落地前自动触发对累积变更的综合评审。现状痛点integration branch 落地是纯机械的——所有子任务关闭 所有 MR 合并 可落地。没有任何评审步骤去检查合并后的完整 diff。提议机制子史诗完成触发器当 convoy 的 epic 状态管理Milestone 2 US-014关闭某个子史诗时不或先不自动落地而是用评审公式 sling 该子史诗本身。评审公式新公式如mol-integration-review或改造code-review.formula.toml其行为包括检出 integration branch、计算与 base branch 的完整 diff、评审累积变更跨任务一致性、任务间 API 契约违例、组合功能的测试缺失、合并冲突残留、产出评审报告通过则执行gt mq integration land sub-epic-id拒绝则创建修复任务并让子史诗阻塞于该任务。Convoy 感知评审期间 convoy 保持打开。评审 polecat 的完成触发下一个子史诗若 root epic 在子史诗间有blocks依赖或 root epic 关闭。集成点internal/convoy/operations.go——关闭 epic 后检查其是否有 integration branch若有则以评审公式 sling而非调用gt mq integration landinternal/daemon/convoy_manager.go——事件轮询检测评审 polecat 的 bead 关闭喂入下一个子史诗或关闭 root epic新公式mol-integration-review.formula.toml。design-to-beads 所需变更确保子史诗获得 integration branch由 design-to-beads 创建或gt convoy stage在 stage 时创建若需要串行顺序确保子史诗间存在blocks依赖。Milestone 4高级派发Phase 3 PRD目标可插拔派发策略与协调者 polecat。交付内容FeederStrategy接口层级深度校验opt-in从层级自动生成blocks依赖--infer-blocksgt sling中的自动公式检测epic → 协调者公式协调者 polecat 策略动态 DAG 分解。该里程碑最远且最不紧急。默认派发策略Phase 1 feeder blocks 检查已覆盖常见场景协调者 polecat 面向复杂史诗——其 AI 驱动的任务选择优于静态依赖排序。Milestone 5Mountain-Eater自主史诗磨削目标在机械的 ConvoyManager 之上叠加 Agent 驱动的判断层使大型史诗自主磨削至完成。依赖Milestone 2stage-launch 管道是 mountain 的地基。完整设计见 docs/design/convoy/mountain-eater.md。交付组件组件描述gt mountain epicCLIvalidate stage label launchgt mountain statusCLI富进度视图active、ready、blocked、skippedgt mountain pause/resume/cancelCLI生命周期管理Witness 失败跟踪Patrol 步骤统计每个 convoy issue 的 polecat 失败次数3 次后自动跳过Deacon mountain-auditPatrol 步骤周期性进度检查停滞时派发 Dogmol-mountain-dog公式Dog 公式调查停滞、sling 孤儿 issue、升级ConvoyManager skip-after-N全局stranded 扫描停止反复重 sling 重复失败的 issue增强的 convoy 状态全局gt convoy status显示活跃 polecat、ready front、被阻塞 issue关键洞见没有任何 Agent 持有主线。convoy 上的mountain标签触发 Witness失败跟踪与 Deacon进度审计的 patrol 行为。Dog 为停滞调查带来全新上下文。ConvoyManager 的机械喂料处理快乐路径判断层处理那 20% 卡住的情况。全局改进惠及所有 convoypolecat 失败跟踪Witness、stranded 扫描中的 skip-after-N 失败ConvoyManager、增强的gt convoy status输出。6. 依赖图与并行策略路线图给出了明确的依赖图Milestone 0: Foundation ← MERGED │ ├──────────────────────────┐ │ │ v v Milestone 1: Pipeline Milestone 2: Stage/Launch (done/refinery fixes) (gt convoy stage/launch) │ │ │ ├───────────────────────┐ │ v v │ Milestone 3: Review gate Milestone 5: Mountain-Eater │ │ │ └──────────┬───────────────┘ │ │ │ v │ Milestone 4: Advanced dispatch ◄────────────┘Milestone 1 与 2 相互独立可并行Milestone 3 依赖 Milestone 2需要 epic 状态管理Milestone 4 依赖 2 与 3 均稳定Milestone 5 依赖 Milestone 2使用 stage-launch 管道Milestone 3 与 5 相互独立可并行。7. design-to-beads 需要改变什么当前 design-to-beads 插件创建的结构是正确的带 parent-child 依赖的 epic、带 blocks 依赖的任务。为支持 staged convoy 工作流需要变更何时需要责任方在子史诗间创建blocks依赖不仅是任务间Milestone 2design-to-beads 插件为子史诗创建 integration branchMilestone 3design-to-beads 插件或gt convoy stage输出 root epic ID 供gt convoy stage输入Milestone 2design-to-beads 插件当前插件已在任务间创建 blocks 依赖。缺口是子史诗间排序若 Sub-Epic A 应先于 Sub-Epic B 完成则二者之间或 A 的最后一个任务与 B 的第一个任务之间必须存在blocks依赖。若 design-to-beads 不创建子史诗间的 blocks 依赖gt convoy stage会显示它们并行派发全部在 Wave 1这可能并非期望行为。--infer-blocks标志Milestone 4可按创建顺序自动生成这些依赖但源自 PRD 结构的显式依赖更可靠。8. 下一步行动总结路线图的收尾部分给出了清晰的分步建议现在推动 PR #1759feeder 安全护栏评审并合并以补全 Milestone 0接下来视优先级启动 Milestone 1管道可靠性和/或 Milestone 2stage/launch。Milestone 1 影响面更广为所有人修复任务不落地Milestone 2 开启 staged convoy UX。两者可并行M2 之后Milestone 3子史诗评审门禁与 Milestone 5Mountain-Eater可并行。Milestone 5 是去吃午饭回来就做完的自主磨削特性Milestone 3 是评审质量门禁更晚常见场景稳定后再做 Milestone 4高级派发。9. 延伸阅读与源码锚点路线图主文档docs/design/convoy/roadmap.mdConvoyManager 规格S-01S-18 全部 DONEdocs/design/convoy/spec.mdConvoy 生命周期设计创建路径、事件驱动完成、手工覆盖docs/design/convoy/convoy-lifecycle.mdStage Launch PRD用户故事 US-001US-011docs/design/convoy/stage-launch/prd.mdMountain-Eater 设计四层磨削架构、mountain 标签、Dog 公式docs/design/convoy/mountain-eater.mdConvoy 概念与命令速查docs/concepts/convoy.md核心实现共享观察者CheckConvoysForIssue、IsSlingableType、isIssueBlocked、feedNextReadyIssue见 internal/convoy/operations.godaemon 双 goroutine 见 internal/daemon/convoy_manager.gostage/launch CLI 见 internal/cmd/convoy_stage.go 与 internal/cmd/convoy_launch.go批量 sling 的 rig 自动解析见 internal/cmd/sling_batch.go。理解这条路线图的关键在于分清三层职责管道sling→done→refinery负责把单个任务真正落地ConvoyManager 负责机械地把下一批任务喂给空闲的 polecat而Mountain-Eater 之类的判断层负责处理那 20% 会卡住的特殊情况。Milestone 1 修管道、Milestone 2/3 建调度与评审、Milestone 5 加判断——每一层都建立在前一层之上这正是 Convoy 系统从被动跟踪器走向主动驱动批量工作收敛的完整路径。【免费下载链接】gastownGas Town - multi-agent workspace manager项目地址: https://gitcode.com/GitHub_Trending/ga/gastown创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Gas Town Convoy 稳定性路线图：从管道可靠性到自主史诗磨削的分阶段演进
Gas Town Convoy 稳定性路线图从管道可靠性到自主史诗磨削的分阶段演进【免费下载链接】gastownGas Town - multi-agent workspace manager项目地址: https://gitcode.com/GitHub_Trending/ga/gastown导读本文是 Gas Town多 Agent 工作区管理器中Convoy车队系统稳定性路线图的完整解读。Convoy 是 Gas Town 中跨 rig 批量工作的核心跟踪单元本文围绕其演进路线梳理了从当前手工创建 bead 批量 sling的现状到gt convoy stage/launch分阶段调度、子史诗评审门禁、直至 Mountain-Eater 自主史诗磨削的目标形态。读完本文你将掌握 Convoy 系统的三大保留工作流、sling→done→refinery 管道上的六大关键失效点、五个里程碑的依赖关系以及每一阶段的源码级实现依据涉及 internal/convoy/operations.go、internal/daemon/convoy_manager.go、internal/cmd/convoy_stage.go 等核心文件。1. 背景Convoy 系统当前状态在 Gas Town 中Convoy是跨 rig 跟踪一批相关 issue 的持久化单元hq-cv-*前缀存在于 town 级 beads 中而Swarm蜂群只是当前正在这批 issue 上工作的 polecat 集合是临时性的。二者的关系、生命周期与基础命令在 docs/concepts/convoy.md 中有完整说明。路线图文档给出的当前状态非常明确Milestone 0基础已全部完成所有基础 PR 已合并。接下来的工作不是重建系统而是在保留现有工作流的前提下修复用户实际遇到的可靠性问题并逐步走向目标 UX。关联主文档docs/design/convoy/roadmap.md配套规格文档docs/design/convoy/spec.md、docs/design/convoy/convoy-lifecycle.md。2. 必须保留的三种现有工作流路线图反复强调一个约束演进不能破坏现有工作流。以下是社区当前实际使用的三种模式。2.1 工作流 A手工创建 bead 批量 sling这是当前最常见的模式bd create --typetask Fix auth timeout → sh-task-1 bd create --typetask Add validation → sh-task-2 bd create --typetask Integration tests → sh-task-3 bd dep add sh-task-2 sh-task-1 --typeblocks gt sling sh-task-1 sh-task-2 sh-task-3 gastown在批量 sling对应 PR #1759 时代行为下实际发生的处理流程是批量 sling 会创建一个 convoy跟踪全部 3 个任务而非每个任务一个 convoyrig 从 bead 前缀自动解析resolveRigFromBeadIDs位于 internal/cmd/sling_batch.go显式指定 rig 已被弃用任务以 2 秒间隔顺序 sling共享同一个 convoyblocks依赖会被 daemon 喂料器feeder尊重——sh-task-2 在 sh-task-1 关闭前不会被 daemon 喂料但初始调度会把所有任务无条件派发出去无视依赖。用户的期望是任务按依赖顺序派发被阻塞的任务在其阻塞者关闭前不被 sling完成任务经由 refinery 落到目标分支。这一初始调度并行、后续喂料尊重依赖的语义在 internal/convoy/operations.go 的feedNextReadyIssue中有清晰的实现证据每次 close 事件后只派发一个 ready issue且必须通过IsSlingableType与isIssueBlocked双重过滤。2.2 工作流 Bdesign-to-beads 手工 sling/design-to-beads PRD.md → creates: root epic, sub-epics, leaf tasks → adds: parent-child deps (organizational hierarchy) → adds: blocks deps (execution ordering between tasks) gt sling task1 task2 task3 gastown与工作流 A 的最终结果一致一个共享 convoy、blocks依赖由 daemon 喂料器尊重。epic 与 sub-epic 结构存在于 beads 中并影响 daemon 驱动的喂料——epic 通过IsSlingableType被过滤不会派发给 polecat被阻塞的任务等待其阻塞者关闭。2.3 工作流 C手工创建 convoygt convoy create Auth overhaul sh-task-1 sh-task-2 sh-task-3 gt sling sh-task-1 gastown → witness feeds sh-task-2 when sh-task-1 closes (serial) → witness feeds sh-task-3 when sh-task-2 closes (serial) → convoy auto-closes when all 3 are done这条路径在上游 main 分支可用但是串行的一次只跑一个任务且 witness 喂料会忽略blocks依赖、类型过滤与 rig 容量。这正是路线图要解决的结构性矛盾工作流 A/B 能并行但初始派发无视依赖工作流 C 尊重串行顺序但过慢且无过滤。目标 UX 试图把两者的优点合并。3. 目标 UX分阶段调度的理想形态路线图给出的最终体验如下/design-to-beads PRD.md → creates: root epic → sub-epics → leaf tasks → adds: parent-child (hierarchy) blocks (ordering) deps → sub-epics get integration branches gt convoy stage epic-id → walks DAG, validates structure, displays route plan (tree waves) → creates staged convoy tracking all beads gt convoy launch convoy-id → activates convoy, dispatches Wave 1 tasks → daemon feeds subsequent waves as tasks close → sub-epic status auto-managed (open → in_progress → closed) → when sub-epic closes: sling sub-epic with review formula → review formula examines accumulated changes on integration branch → on approval: integration branch lands to main/parent branch → convoy closes when root epic closes这一目标在仓库中已具备实现骨架internal/cmd/convoy_stage.go 实现了 DAG 行走、校验、wave 计算、树/波次路线图展示与staged_ready/staged_warnings状态创建internal/cmd/convoy_launch.go 实现激活与 Wave 1 派发。详细 PRD 见 docs/design/convoy/stage-launch/prd.md。4. 用户实际报告的问题两类失效点路线图最有价值的部分是它对用户到底在抱怨什么的诚实盘点。最常见的抱怨是任务无法通过 refinery 落到目标分支。文档明确指出——这不是 convoy 的问题而是sling→done→refinery 管道可靠性问题convoy 系统只是叠加在这条管道之上。4.1 独立于 convoy 的关键失效点影响所有 polecat 工作#失效位置严重度恢复方式1Dolt 分支合并失败done.go已解决由 all-on-main 架构消除不再有 per-polecat Dolt 分支。2Push 失败全部 3 层done.go:531-572严重仅本地提交。工作树保留。需要手工恢复。3MR bead 创建失败done.go:744-752高分支已推送但无 MR。通知 witness。无自动恢复。4Refinery 永不唤醒Agent 停滞Agent 层高心跳会重启但间隙可能长达数分钟。5合并冲突无限期阻塞 MRengineer.go:764-786中必须派发冲突任务并解决。rig 满载时会停滞。6孤立 MR分支被删、MR 仍打开engineer.go:1086-1198中异常检测可发现。需 Agent 处理。文档强调这些失效影响所有polecat 工作无论是否被 convoy 跟踪修复它们将惠及整个系统。这也是 Milestone 1 被定位为最高影响力工作的原因——如果底层管道会丢任务convoy 再完善也无法兑现任务落地的承诺。4.2 Convoy 特有失效点Milestone 0 的修复清单#失效修复方式状态7被阻塞任务仍被 sling忽略 blocks 依赖isIssueBlockedPR #1759未合并8epic 被 sling 给 polecat无类型过滤IsSlingableTypePR #1759未合并9跨 rig 关闭事件对 daemon 不可见多 rig SDK 轮询已合并10close 后 daemon 不喂下一个任务连续喂料continuation feeding已合并11Refinery convoy 检查传错路径从未生效移除该调用已合并12首次派发失败导致整个 convoy 被弃派发失败迭代PR #1759未合并13stranded 扫描仅报告、不自动派发feedFirstReady已合并其中 #9 和 #10 在 internal/daemon/convoy_manager.go 中有对应实现daemon 内驻留的ConvoyManager运行两个 goroutine——事件轮询每 5 秒调用GetAllEventsSince覆盖所有 rig store hq与stranded 扫描每 30 秒执行gt convoy stranded --json作为崩溃/重启后的安全网。#11 的根因refinery 传入了 rig path 而非 town root导致CheckConvoysForIssueWithAutoStore静默返回 nil在 docs/design/convoy/spec.md 的 S-17/S-18 故事中有完整记录。5. 分阶段计划五个里程碑Milestone 0奠定基础已完成所有基础 PR 已合并。文档特别强调 PR #1759feeder 安全护栏即上表 #7/#8/#12 的修复仍需评审与合并以补全此里程碑。Milestone 1管道可靠性独立于 convoy目标修复导致任务不落地投诉的 sling→done→refinery 管道失效。#问题建议修复复杂度1aDolt 分支合并失败已解决——all-on-main 消除 per-polecat Dolt 分支。N/A1bDolt 分支上的 stranded MR beads已解决——不再有可搁浅的 per-polecat Dolt 分支。N/A1cRefinery Agent 停滞加固 refinery 心跳增加 daemon 级 MR 队列监视器当 MR 超阈值未处理时 nudge或重启refinery。中1d合并冲突无限期阻塞跟踪冲突任务年龄N 小时未解决则升级至 Mayor/owner附具体冲突细节。低此里程碑独立于 convoy 工作可由不同贡献者并行推进或排在 Milestone 0 之后。Milestone 2stage 与 launchgt convoy stage、gt convoy launch目标打通/design-to-beads → gt convoy stage → gt convoy launch工作流。依赖Milestone 0喂料器必须尊重 blocks 依赖并过滤类型staged convoy 才能正确工作。交付内容源自 Phase 2 PRDgt convoy stage bead-id——DAG 行走、校验、wave 计算、树 wave 路线图展示gt convoy launch convoy-id——激活 convoy、派发 Wave 1epic 状态管理open → in_progress → closedintegration branch 感知缺失时告警staged 状态流转staged_ready ↔ staged_warnings → open。已定的关键设计决策parent-child仅具组织意义永不阻塞与bd ready及 beads SDK 对齐执行顺序通过显式blocks依赖表达wave 计算仅作展示信息性运行时派发使用每周期的isIssueBlocked检查更动态能应对外部状态变化integration branch 的创建与落地保持手工或由 refinery 自动落地。此阶段尚不能实现子史诗评审公式Milestone 3、史诗 sling 的自动公式检测Phase 3、协调者 polecatPhase 3。实现层面internal/cmd/convoy_stage.go 已经支持三种输入形态epic ID、任务列表、convoy ID、错误/警告分类输出、--json机器可读输出以及 restage 语义重新分析并更新状态而非新建 convoywave 计算使用拓扑排序并处理 gated 任务如被未关闭任务门控的情况的告警提示。Milestone 3子史诗评审门禁目标当子史诗下所有任务完成并合并到该子史诗的 integration branch 后在落地前自动触发对累积变更的综合评审。现状痛点integration branch 落地是纯机械的——所有子任务关闭 所有 MR 合并 可落地。没有任何评审步骤去检查合并后的完整 diff。提议机制子史诗完成触发器当 convoy 的 epic 状态管理Milestone 2 US-014关闭某个子史诗时不或先不自动落地而是用评审公式 sling 该子史诗本身。评审公式新公式如mol-integration-review或改造code-review.formula.toml其行为包括检出 integration branch、计算与 base branch 的完整 diff、评审累积变更跨任务一致性、任务间 API 契约违例、组合功能的测试缺失、合并冲突残留、产出评审报告通过则执行gt mq integration land sub-epic-id拒绝则创建修复任务并让子史诗阻塞于该任务。Convoy 感知评审期间 convoy 保持打开。评审 polecat 的完成触发下一个子史诗若 root epic 在子史诗间有blocks依赖或 root epic 关闭。集成点internal/convoy/operations.go——关闭 epic 后检查其是否有 integration branch若有则以评审公式 sling而非调用gt mq integration landinternal/daemon/convoy_manager.go——事件轮询检测评审 polecat 的 bead 关闭喂入下一个子史诗或关闭 root epic新公式mol-integration-review.formula.toml。design-to-beads 所需变更确保子史诗获得 integration branch由 design-to-beads 创建或gt convoy stage在 stage 时创建若需要串行顺序确保子史诗间存在blocks依赖。Milestone 4高级派发Phase 3 PRD目标可插拔派发策略与协调者 polecat。交付内容FeederStrategy接口层级深度校验opt-in从层级自动生成blocks依赖--infer-blocksgt sling中的自动公式检测epic → 协调者公式协调者 polecat 策略动态 DAG 分解。该里程碑最远且最不紧急。默认派发策略Phase 1 feeder blocks 检查已覆盖常见场景协调者 polecat 面向复杂史诗——其 AI 驱动的任务选择优于静态依赖排序。Milestone 5Mountain-Eater自主史诗磨削目标在机械的 ConvoyManager 之上叠加 Agent 驱动的判断层使大型史诗自主磨削至完成。依赖Milestone 2stage-launch 管道是 mountain 的地基。完整设计见 docs/design/convoy/mountain-eater.md。交付组件组件描述gt mountain epicCLIvalidate stage label launchgt mountain statusCLI富进度视图active、ready、blocked、skippedgt mountain pause/resume/cancelCLI生命周期管理Witness 失败跟踪Patrol 步骤统计每个 convoy issue 的 polecat 失败次数3 次后自动跳过Deacon mountain-auditPatrol 步骤周期性进度检查停滞时派发 Dogmol-mountain-dog公式Dog 公式调查停滞、sling 孤儿 issue、升级ConvoyManager skip-after-N全局stranded 扫描停止反复重 sling 重复失败的 issue增强的 convoy 状态全局gt convoy status显示活跃 polecat、ready front、被阻塞 issue关键洞见没有任何 Agent 持有主线。convoy 上的mountain标签触发 Witness失败跟踪与 Deacon进度审计的 patrol 行为。Dog 为停滞调查带来全新上下文。ConvoyManager 的机械喂料处理快乐路径判断层处理那 20% 卡住的情况。全局改进惠及所有 convoypolecat 失败跟踪Witness、stranded 扫描中的 skip-after-N 失败ConvoyManager、增强的gt convoy status输出。6. 依赖图与并行策略路线图给出了明确的依赖图Milestone 0: Foundation ← MERGED │ ├──────────────────────────┐ │ │ v v Milestone 1: Pipeline Milestone 2: Stage/Launch (done/refinery fixes) (gt convoy stage/launch) │ │ │ ├───────────────────────┐ │ v v │ Milestone 3: Review gate Milestone 5: Mountain-Eater │ │ │ └──────────┬───────────────┘ │ │ │ v │ Milestone 4: Advanced dispatch ◄────────────┘Milestone 1 与 2 相互独立可并行Milestone 3 依赖 Milestone 2需要 epic 状态管理Milestone 4 依赖 2 与 3 均稳定Milestone 5 依赖 Milestone 2使用 stage-launch 管道Milestone 3 与 5 相互独立可并行。7. design-to-beads 需要改变什么当前 design-to-beads 插件创建的结构是正确的带 parent-child 依赖的 epic、带 blocks 依赖的任务。为支持 staged convoy 工作流需要变更何时需要责任方在子史诗间创建blocks依赖不仅是任务间Milestone 2design-to-beads 插件为子史诗创建 integration branchMilestone 3design-to-beads 插件或gt convoy stage输出 root epic ID 供gt convoy stage输入Milestone 2design-to-beads 插件当前插件已在任务间创建 blocks 依赖。缺口是子史诗间排序若 Sub-Epic A 应先于 Sub-Epic B 完成则二者之间或 A 的最后一个任务与 B 的第一个任务之间必须存在blocks依赖。若 design-to-beads 不创建子史诗间的 blocks 依赖gt convoy stage会显示它们并行派发全部在 Wave 1这可能并非期望行为。--infer-blocks标志Milestone 4可按创建顺序自动生成这些依赖但源自 PRD 结构的显式依赖更可靠。8. 下一步行动总结路线图的收尾部分给出了清晰的分步建议现在推动 PR #1759feeder 安全护栏评审并合并以补全 Milestone 0接下来视优先级启动 Milestone 1管道可靠性和/或 Milestone 2stage/launch。Milestone 1 影响面更广为所有人修复任务不落地Milestone 2 开启 staged convoy UX。两者可并行M2 之后Milestone 3子史诗评审门禁与 Milestone 5Mountain-Eater可并行。Milestone 5 是去吃午饭回来就做完的自主磨削特性Milestone 3 是评审质量门禁更晚常见场景稳定后再做 Milestone 4高级派发。9. 延伸阅读与源码锚点路线图主文档docs/design/convoy/roadmap.mdConvoyManager 规格S-01S-18 全部 DONEdocs/design/convoy/spec.mdConvoy 生命周期设计创建路径、事件驱动完成、手工覆盖docs/design/convoy/convoy-lifecycle.mdStage Launch PRD用户故事 US-001US-011docs/design/convoy/stage-launch/prd.mdMountain-Eater 设计四层磨削架构、mountain 标签、Dog 公式docs/design/convoy/mountain-eater.mdConvoy 概念与命令速查docs/concepts/convoy.md核心实现共享观察者CheckConvoysForIssue、IsSlingableType、isIssueBlocked、feedNextReadyIssue见 internal/convoy/operations.godaemon 双 goroutine 见 internal/daemon/convoy_manager.gostage/launch CLI 见 internal/cmd/convoy_stage.go 与 internal/cmd/convoy_launch.go批量 sling 的 rig 自动解析见 internal/cmd/sling_batch.go。理解这条路线图的关键在于分清三层职责管道sling→done→refinery负责把单个任务真正落地ConvoyManager 负责机械地把下一批任务喂给空闲的 polecat而Mountain-Eater 之类的判断层负责处理那 20% 会卡住的特殊情况。Milestone 1 修管道、Milestone 2/3 建调度与评审、Milestone 5 加判断——每一层都建立在前一层之上这正是 Convoy 系统从被动跟踪器走向主动驱动批量工作收敛的完整路径。【免费下载链接】gastownGas Town - multi-agent workspace manager项目地址: https://gitcode.com/GitHub_Trending/ga/gastown创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
