Gastown Convoy 系统完全指南：跨 Rig 批量任务跟踪、事件驱动馈送与 Stage-Launch 工作流

Gastown Convoy 系统完全指南跨 Rig 批量任务跟踪、事件驱动馈送与 Stage-Launch 工作流【免费下载链接】gastownGas Town - multi-agent workspace manager项目地址: https://gitcode.com/GitHub_Trending/ga/gastown导读本文系统讲解 Gas Towngastown多 Agent 工作区管理器中Convoy车队系统的完整机制Convoy 是一个通过tracks依赖跟踪其他 bead 的追踪单元守护进程daemon持续监控关闭事件并在某个任务完成后自动馈送下一个就绪任务。你将掌握三条创建路径gt sling自动创建、gt convoy create显式创建、gt convoy stage校验式创建、两条馈送路径5 秒事件驱动轮询与 30 秒滞留扫描、三道安全护栏类型过滤、阻塞依赖检查、失败迭代以及从分析依赖、构建 DAG、计算执行波次到安全投放 Wave 1 的完整 stage-launch 两阶段工作流。读完本文你将能够写出、调试并测试 convoy 相关代码也能在生产中熟练排障。一、Convoy 是什么Convoy 是 Gastown 中跨 Rig 批量工作的跟踪单元。从数据模型上看一个 convoy 就是一个 beadID 形如hq-cv-xxxxx存放在 town 级 hq 存储中它通过tracks类型的依赖关系跟踪其他 bead如gt-task1、bd-task2。tracks关系是非阻塞的被跟踪的问题不会反过来阻塞 convoy 本身。守护进程daemon监听 beads 事件流当某个被跟踪的 issue 关闭时触发CheckConvoysForIssue完成性检查若 convoy 尚未完成则反应式馈送下一个就绪 issue从而让 convoy 持续推进无需等待基于轮询的 patrol 周期。与 convoy 相关的两个概念需要区分Convoy持久化跟踪单元有独立 IDhq-*前缀跨 Rig 跟踪问题所有跟踪问题完成后自动关闭并通知订阅者可通过添加新 issue 重新打开。Swarm临时性概念指当前被分配到 convoy 各 issue 的 worker 集合没有独立 ID复用 convoy ID工作完成后即解散。这一语义在 internal/cmd/convoy.go 的gt convoy命令 Long 描述中有明确记载。二、整体架构三条创建路径与两条馈送路径SKILL 文档用一张架构图概括了系统全貌。三种创建路径殊途同归——都产出hq-cv-*的 convoy bead并通过tracks依赖跟踪若干 issuegt sling beads gt convoy create ... gt convoy stage epic | (auto-convoy) | (explicit) | (validated) v v v status: open status: open staged:ready / staged:warnings | gt convoy launch v status: open (Wave 1 slung)两条馈送路径共享同一套安全护栏事件驱动馈送约 5 秒周期核心逻辑位于 internal/convoy/operations.go通过 beads SDK 的GetAllEventsSince轮询所有 beads storetown 级 hq 各 Rig 存储检测到 close 事件后调用CheckConvoysForIssue进而调用feedNextReadyIssue——该函数在派发前检查IsSlingableType与isIssueBlocked并通过isConvoyStaged跳过 staged 状态 convoy。滞留扫描约 30 秒周期核心逻辑位于 internal/daemon/convoy_manager.gofindStranded运行gt convoy stranded --json找出有就绪 issue 但没有活跃 worker的 convoy再调用feedFirstReady遍历所有就绪 issue 逐一分派。就绪列表在findStrandedConvoysinternal/cmd/convoy.go中已经预先经过IsSlingableType类型过滤。该路径只看到 open 状态的 convoystaged convoy 永远不会出现。守护进程的工程细节从源码看ConvoyManagerinternal/daemon/convoy_manager.go是一个严谨的并发组件以下细节值得注意周期常量事件轮询 5 秒eventPollInterval滞留扫描默认 30 秒defaultStrandedScanInterval轮询失败时指数退避最长 60 秒eventPollMaxBackoff。高水位去重每个 store 维护独立的lastEventIDs高水位并以 1 秒重叠eventPollLookback规避 Dolt 的秒级时间戳精度问题首个轮询周期仅作为预热seeding推进高水位但不处理事件防止守护进程重启时重放整段历史事件。跨周期去重processedCloses与processedLifecycleEvents两张 sync.Map 防止同一 close 事件跨 store 复制或跨轮询周期重复处理reopen 事件会清除对应标记使 close→reopen→close 能再次被处理。并发保护scanMu串行化scan()防止滞留扫描与启动清扫runStartupSweep延迟 10 秒运行一次同时触发重复的 convoy 检查。恢复模式事件轮询报错如 Dolt 宕机时置位recoveryMode滞留扫描缩短为 5 秒重试Dolt 恢复后自动恢复正常周期。启动清扫守护进程启动后约 10 秒执行一次一次性扫描兜底捕获停机期间完成的 convoy。空 convoy 宽限期convoyGracePeriod为 5 分钟防止 sling 的bd dep add尚未在 Dolt 中可见时滞留扫描误关刚创建的空 convoy见 GH#2303。跨 Rig 依赖的精准状态解析isIssueBlocked与getConvoyTrackedIssues支持StoreResolver见 internal/convoy/operations.go提供 resolver 时跨库依赖通过按前缀路由查询所属 Rig store 获取最新状态避免 hq 存储中跨 Rig 依赖元数据快照过期见 GH#2624无 resolver 时回退到bd show子进程逐 Rig 获取。此外FireCrossRigDepNotifications会在一个 issue 关闭解除了其他 Rig 的阻塞依赖后向对应 Rig 的 witness 发送 nudge 通知。三、三道安全护栏两道馈送路径都必须通过这三道检查防止派发不该派发的工作1. 类型过滤IsSlingableType只有叶子工作项可以派发。定义于 internal/convoy/operations.govar slingableTypes map[string]bool{ task: true, bug: true, feature: true, chore: true, : true, // Empty type defaults to task }Epic、sub-epic、convoy、decision 等容器/非工作类型全部跳过。空类型视为可派发legacy bead 未设置 IssueType 时默认是 task若把空串视为不可派发会破坏所有历史 bead。该检查同时应用于feedNextReadyIssue事件路径与findStrandedConvoys滞留路径。2. 阻塞依赖检查isIssueBlocked带未关闭的blocks、conditional-blocks、waits-for依赖的 issue 跳过。parent-child不算阻塞——子任务即使父 epic 仍 open 也可以派发与bd ready、molecule step 行为一致。源码中阻塞依赖类型集合还包含merge-blocksinternal/convoy/operations.go且对merge-blocks有更严格的语义仅 closed 不够blocker 的 CloseReason 必须以Merged in 开头确认代码确实已合并防止针对未合入代码派发工作见 #1893。关键设计存储错误时 fail-open假定未阻塞避免瞬态 Dolt 问题永久卡死 convoy——下一个馈送周期会用新状态重试。3. 派发失败迭代两条馈送路径都在失败后继续尝试而不是放弃feedNextReadyIssue派发失败continue尝试下一个就绪 issuefeedFirstReadyfor range ReadyIssues循环中前缀不可解析、Rig 无路由、Rig 已停靠或 sling 失败都跳过并继续首次成功即return。feedFirstReady的完整实现见 internal/daemon/convoy_manager.go它解析前缀 → 查routes.jsonl映射 Rig → 跳过 parked rig → 执行gt sling issueID rig --no-boot并透传 convoy 的base_branch。四、CLI 命令全览创建与投递stage / launchgt convoy stage epic-id # 分析依赖、构建 DAG、计算波次、创建 staged convoy gt convoy stage gt-task1 gt-task2 # 从显式任务列表 stage gt convoy stage hq-cv-abc # 重新 stage 已有 staged convoyre-stage gt convoy stage epic-id --json # 机器可读输出 gt convoy stage epic-id --launch # stage 后若无错误立即 launch gt convoy launch hq-cv-abc # staged → open派发 Wave 1 gt convoy launch epic-id # 一步完成 stage launch内部委托给 stage --launchgt convoy stage还支持--title自定义标题与--no-validateepic 输入时跳过自动校验 bead 创建见 internal/cmd/convoy_stage.go。创建与管理gt convoy create Auth overhaul gt-task1 gt-task2 gt-task3 gt convoy add hq-cv-abc gt-task4create的扩展能力来自 internal/cmd/convoy.go--owner who指定接收完成通知的负责人默认取创建者身份--notify [addr]追加订阅者无参使用默认值mayor/--merge direct|mr|local设置合并策略direct直接推主分支绕过 refinery、mr走合并队列默认值、local留在功能分支等人工评审--base-branch branchpolecat 的目标分支--molecule id关联 molecule--owned标记为调用方管理生命周期配合gt convoy land--from-epic epic-id通过 BFS 遍历 epic 的叶子可派发子孙自动发现跟踪 issuecollectEpicChildren实现于 internal/cmd/convoy.go。add对已关闭 convoy 会自动重开closed → open并清理完成通知状态。检查与监控gt convoy check hq-cv-abc # 所有跟踪 issue 完成后自动关闭 gt convoy check # 检查所有 open convoy gt convoy check --dry-run # 预演不实际执行关闭 gt convoy status hq-cv-abc # 单个 convoy 详情也支持数字快捷方式如 1 gt convoy list # 列出所有 convoy默认仅 open gt convoy list --all # 包含 closed gt convoy list --statusclosed # 按状态过滤 gt convoy list --tree # 显示 convoy 子状态树 gt convoy list --json # JSON 输出自动关闭逻辑的关键在closeConvoyIfCompleteinternal/cmd/convoy.go只有成功解析到跟踪 issue时才允许自动关闭——0/0 意味着跨 Rig 解析失败而非全部完成避免误发 Convoy landed 通知trackedStatusUnknown跨 Rig 库不可达被视为未完成不阻塞关闭判定但明确标注。关闭后通过notifyConvoyCompletion向 owner、notify 地址、mayor/发送邮件/ nudge 通知并记录CompletionNotifiedAt防止重复通知。查找滞留工作gt convoy stranded # 有就绪工作但没有活跃 worker gt convoy stranded --json # 机器可读输出守护进程即用此接口stranded判定规则isReadyIssueinternal/cmd/convoy.goopen 且无 assignee或 in_progress/hooked 但 assignee 的 tmux 会话已死亡孤儿 molecule / 死 worker且未被阻塞t.Blocked、未被调度scheduledSet、类型可派发、Rig 可路由。输出会分类提示可馈送用gt sling mol-convoy-feed deacon/dogs --var convoy...、需人工评审、需清理gt convoy check。关闭与落地gt convoy close hq-cv-abc --reason done # 默认校验所有跟踪 issue 已完成 gt convoy close hq-cv-abc --force # 强制关闭如废弃 convoy gt convoy land hq-cv-abc # 清理 polecat worktree 关闭 gt convoy land hq-cv-abc --keep-worktrees # 跳过 worktree 清理 gt convoy land hq-cv-abc --dry-run # 预演close幂等重复关闭是 no-op--notify可指定额外通知地址。land仅适用于带gt:owned标签的 owned convoy先通过findConvoyWorktrees匹配跟踪 issue 的 assignee 与各 Rig 的 polecat 目录用gt polecat remove清理 worktree再以 Landed by owner 关闭并发送完成通知。交互式 TUIgt convoy -i # 打开交互式 convoy 浏览器 gt convoy --interactive # 长参数形式五、批量 sling 行为gt sling bead1 bead2 bead3会创建一个convoy 跟踪所有 bead而不是每个 bead 一个 convoy。Rig 从 bead 前缀自动解析经由routes.jsonlconvoy 标题为Batch: N beads to rig见 internal/cmd/sling_convoy.go 的createBatchConvoy。每个 bead 拥有自己的 polecat但共享同一个 convoy 做跟踪。关键实现细节convoy ID 和合并策略会被写入每个 bead 的附加字段attachment fields因此gt done可以通过快路径getConvoyInfoFromIssue直接找到 convoyinternal/cmd/sling_convoy.go避免不可靠的跨 Rig 依赖解析gt-7b6wf 修复。isTrackedByConvoy还提供基于原始依赖表查询bdDepListRawIDs方向 up与描述匹配的两级兜底。Rig 解析规则自动解析推荐gt sling gt-task1 gt-task2 gt-task3—— 从gt-前缀解析 Rig所有 bead 必须解析到同一 Rig。显式指定 Rig已弃用gt sling gt-task1 gt-task2 gt-task3 myrig—— 仍可用但打印弃用警告若某 bead 前缀与显式 Rig 不匹配则报错并给出建议动作。混合前缀bead 解析到不同 Rig 时报错逐一列出每个 bead 解析到的 Rig 及建议动作分开 sling或用--force。未映射前缀前缀无路由时报错并给出诊断信息cat .beads/routes.jsonl | grep prefix。冲突处理若任一 bead 已被其他 convoy 跟踪批量 sling整体报错实现于printConvoyConflictinternal/cmd/sling_convoy.go打印详细冲突信息冲突的 convoy、其中所有 bead 及各自状态open ● / closed ✓ / hooked ◆以及 4 条推荐动作——从批次中移除该 bead、先从旧 convoy 移除跟踪再重 sling、关闭旧 convoy 后统一重 sling、或把其他 bead 加进现有 convoy。这防止了意外双重跟踪。# 自动解析一个 convoy三个 polecat推荐 gt sling gt-task1 gt-task2 gt-task3 # - Created convoy hq-cv-xxxxx tracking 3 beads # 显式 Rig 仍可用但打印弃用警告 gt sling gt-task1 gt-task2 gt-task3 gastown # - Deprecation: gt sling now auto-resolves the rig from bead prefixes. # - Created convoy hq-cv-xxxxx tracking 3 beads六、Stage-Launch 两阶段工作流stage-launch 是在派发任何工作之前校验依赖、计算波次派发顺序的两阶段创建路径是 epic 交付的首选路径。设计文档见 docs/design/convoy/stage-launch/prd.md 与 docs/design/convoy/stage-launch/testing.md其核心洞察是staging 是一次起飞前检查在 spawn 任何 polecat 之前捕获依赖环、路由问题、孤儿任务与容量问题launch 是激活已验证 convoy 的动作。输入类型gt convoy stage接受三种互斥输入输入示例行为Epic IDgt convoy stage bcc-nxk2oBFS 遍历整个 parent-child 树收集全部后代任务列表gt convoy stage gt-t1 gt-t2 gt-t3精确分析给定任务Convoy IDgt convoy stage hq-cv-abc从现有 staged convoy 重新读取跟踪 beadre-stage混合类型如 epic task报错多个 epic 或多个 convoy 报错。此外若已有 staged/open convoy 跟踪了本次要 stage 的 bead会触发重叠检测open convoy 重叠 → 报错要求先关闭单个 staged convoy 重叠 → 自动转为 re-stage多个 staged 重叠 → 报错要求显式指定 convoy见 internal/cmd/convoy_stage.go。处理流水线源码 internal/cmd/convoy_stage.go 的runConvoyStage完整实现了 SKILL 文档的 13 步流水线1. validateStageArgs — 拒绝空参数 / 形似 flag 的参数 2. bdShow each arg — 解析 bead 类型 3. resolveInputKind — 分类 Epic / Tasks / Convoy 4. collectBeads — 收集 BeadInfo DepInfoepic 用 BFS任务直接取 5. buildConvoyDAG — 构建内存 DAG节点 边 6. detectErrors — 环检测 缺失 Rig 检查 7. detectWarnings — 孤儿、parked rig、跨 Rig、容量、缺失分支 8. categorizeFindings — 拆分为 errors / warnings 9. chooseStatus — staged:ready、staged:warnings 或遇错中止 10. computeWaves — Kahn 算法仅在无错误时 11. renderDAGTree — 打印 ASCII 依赖树 12. renderWaveTable — 打印波次派发计划 13. createStagedConvoy — bd create --typeconvoy --statusstaged-statusepic 输入时还会追加一个validation bead作为最终波次阻塞于所有任务formula 为mol-validate-prd用--no-validate可跳过。波次计算Kahn 算法只有可派发类型参与波次task、bug、feature、chore。epic 被排除。执行边决定波次顺序blocks、conditional-blocks、waits-for。非执行边不参与波次排序parent-child仅层级、related、tracks、discovered-from。算法步骤internal/cmd/convoy_stage.go仅保留可派发节点计算每个节点的入度指向其他可派发节点的 BlockedBy 边数Peel 循环收集所有入度为 0 的节点 → 记为 Wave N移除它们递减邻居入度重复每个波次内按字母序排序保证确定性。需要注意epic/decision 等非可派发节点的阻塞边依然被尊重——被 open 的 decision bead 阻塞的任务会被标记为gated无法放入任何波次并产生 warning修复 #2141。输出示例Wave ID Title Rig Blocked By ────────────────────────────────────────────────────────────────────── 1 bcc-nxk2o.1.1 Init scaffolding bcc — 2 bcc-nxk2o.1.2 Shared types bcc bcc-nxk2o.1.1 3 bcc-nxk2o.1.3 CLI wrapper bcc bcc-nxk2o.1.2 3 tasks across 3 waves (max parallelism: 1 in wave 1)环检测detectCycles使用带 3 色标记white/gray/black的 DFS回溯父链提取完整环路径节点遍历按字母序排序保证输出确定性。Convoy 状态模型四种状态及定义转移validateConvoyStatusTransition实现于 internal/cmd/convoy.go状态含义staged:ready已验证无错误无警告可 launchstaged:warnings已验证无错误但有警告。修复后 re-stage或直接 launchopen活跃——daemon 在 bead 关闭时馈送工作closed已完成或已取消合法转移从 → 到允许staged:ready→open是launchstaged:warnings→open是launch需--forcestaged:*→closed是取消staged:ready↔staged:warnings是re-stageopen→closed是closed→open是reopenopen→staged:*否closed→staged:*否值得注意源码中状态常量实际存储为staged_ready/staged_warnings带下划线见 internal/cmd/convoy.goCLI 展示与文档中写作staged:ready/staged:warnings风格isConvoyStaged通过strings.HasPrefix(status, staged_)判断。错误与警告分类错误致命——阻止 convoy 创建退出码非零、无任何副作用类别触发条件修复cycle执行边中检测到环移除环中的一个阻塞依赖no-rig可派发 bead 无 Rig前缀不在 routes.jsonl添加 routes.jsonl 条目警告非致命——convoy 以staged:warnings创建类别触发条件orphan可派发任务在任一方向都没有阻塞依赖仅 epic 输入blocked-rigbead 指向 parked/docked 的 Rigcross-rigbead 所在 Rig 与大多数不同capacity某波次任务数超过 5missing-branch带子任务的 sub-epic 没有集成分支gated任务被 open 的非可派发节点decision/epic阻塞Launch 行为gt convoy launch convoy-id将 staged convoy 转为 open 并派发 Wave 1实现见 internal/cmd/convoy_launch.go校验 convoy 存在且为 staged 状态transitionConvoyToOpenstaged:ready直接转staged:warnings需--forceopen/closed 报错重新读取跟踪 bead重建 DAG重算波次检查 parked/docked RigcheckBlockedRigsForLaunch可--force绕过但提示任务可能失败派发 Wave 1 每个任务dispatchWave1委托gt sling beadID rig单个 sling 失败不中止其余派发打印派发结果每任务 ✓/✗并按字母序排序保证输出确定后续波次由 daemon 自动处理事件驱动 滞留扫描。若gt convoy launch收到的是 epic 或任务列表非 staged convoy则内部设置convoyStageLaunch true委托给gt convoy stage --launch一步完成 stage-then-launch。Staged convoy 对 daemon 完全惰性staged convoy 对守护进程完全惰性两条馈送路径都不会处理它们事件驱动馈送CheckConvoysForIssue中的isConvoyStaged检查跳过任何staged:*状态的 convoy读取失败时 fail-open假定未 staged → 继续处理而读取不存在的 convoy 出错也无副作用因此是安全的。滞留扫描gt convoy stranded只返回 open convoystaged convoy 永远不会出现。这意味着你可以先 stage 一个 convoy、审阅波次计划、确认无误后再 launch——绝无过早派发的风险。Re-staging对已有 staged convoy 执行gt convoy stage convoy-id会重新分析并更新从 convoy 的tracks依赖重新读取跟踪 bead重建 DAG、重新检测错误/警告、重算波次通过bd update更新状态例如警告解决后staged:warnings→staged:ready不会创建新 convoy 或重新添加 track 依赖还会调和跟踪集合为 DAG 新增的可派发 bead 补加tracks为已不在 DAG 中的 bead 移除tracks见updateStagedConvoyinternal/cmd/convoy_stage.go。七、测试 convoy 变更运行测试# 完整 convoy 套件所有相关包 go test ./internal/convoy/... ./internal/daemon/... ./internal/cmd/... -count1 # 按领域 go test ./internal/convoy/... -v -count1 # 馈送逻辑 go test ./internal/daemon/... -v -count1 -run TestConvoy # ConvoyManager go test ./internal/daemon/... -v -count1 -run TestFeedFirstReady go test ./internal/cmd/... -v -count1 -run TestCreateBatchConvoy # 批量 sling go test ./internal/cmd/... -v -count1 -run TestBatchSling go test ./internal/cmd/... -v -count1 -run TestResolveRig # Rig 解析 go test ./internal/daemon/... -v -count1 -run Integration # 真实 beads store # Stage-launch go test ./internal/cmd/... -v -count1 -run TestConvoyStage # staging 逻辑 go test ./internal/cmd/... -v -count1 -run TestConvoyLaunch # launch Wave 1 派发 go test ./internal/cmd/... -v -count1 -run TestDetectCycles # 环检测 go test ./internal/cmd/... -v -count1 -run TestComputeWaves # 波次计算 go test ./internal/cmd/... -v -count1 -run TestBuildConvoyDAG # DAG 构建关键测试不变量feedFirstReady每次调用恰好派发 1 个 issue首个成功者胜出feedFirstReady会越过失败继续尝试sling 退出码 1 → 尝试下一个事件轮询与 feedFirstReady 中都跳过 parked rig即使所有 Rig 都isRigParkedhq store 也绝不跳过高水位防止跨轮询周期重复处理事件首个轮询周期仅预热只播种标记不处理IsSlingableType(epic) false、IsSlingableType(task) true、IsSlingableType() trueisIssueBlocked是 fail-open存储错误 → 未阻塞parent-child依赖不阻塞批量 sling 为 N 个 bead 恰好创建 1 个 convoy而非 N 个resolveRigFromBeadIDs对混合前缀、未映射前缀、town 级前缀报错阻塞依赖中的环阻止 staged convoy 创建退出非零、无副作用Wave 1 只包含在可派发节点中零未满足阻塞依赖的任务epic 与非可派发类型绝不会进入波次daemon 不会从staged:*convoy 馈送 issue两条路径都跳过staged:warningsconvoy 仍可 launch警告是信息性的re-stage 不产生重复原地更新launch 只派发 Wave 1而非后续波次波次计算是确定性的相同输入 → 相同输出波次内字母序深度测试工程完整 stage-launch 测试计划单元、集成、快照、属性四层共 105 个测试见 docs/design/convoy/stage-launch/testing.md通用 convoy 测试计划失败模式、覆盖缺口、harness 计分卡、测试矩阵、推荐策略见 docs/design/convoy/testing.md。八、常见陷阱Common Pitfallsparent-child永远不阻塞。这是刻意的设计选择而非 bug与bd ready、beads SDK 和 molecule step 行为一致。批量 sling 对已被跟踪的 bead 报错。任一 bead 已在 convoy 中整个批量 sling 就失败并给出冲突详情用户必须先解决冲突。滞留扫描有自己的阻塞检查。isReadyIssueinternal/cmd/convoy.go读取 issue 详情中的t.BlockedisIssueBlockedinternal/convoy/operations.go覆盖事件驱动路径。不彻底理解两条路径就不要合并它们。空 IssueType 可派发。IssueType 未设置时 bead 默认为 task。把空串视为不可派发会破坏所有 legacy bead。isIssueBlocked是 fail-open。存储错误假定未阻塞。瞬态 Dolt 错误不应永久卡住 convoy——下一轮馈送周期会用新状态重试。批量 sling 中的显式 Rig 已弃用。gt sling beads... rig仍可用但打印警告优先用自动解析。Staged convoy 是惰性的。daemon 完全忽略它们在gt convoy launch之前不要期待自动馈送。launch 前审查staged:warnings。警告是信息性的——能修就修并 re-stage可接受就直接 launch。gt convoy launch遇到非 staged 输入会委托给 stage。传入 epic 或任务列表时内部执行stage --launch只有已是 staged 的 convoy 走快路径。波次计算是信息性的。波次在 stage 时计算用于展示运行时派发使用 daemon 每周期动态的isIssueBlocked检查。open 的 convoy 不能退回 staged。一旦 launchconvoy 无法回到 staged 状态open → staged:*转移被拒绝。九、关键源码文件索引文件职责internal/convoy/operations.go核心馈送CheckConvoysForIssue、feedNextReadyIssue、IsSlingableType、isIssueBlocked、FireCrossRigDepNotificationsinternal/daemon/convoy_manager.goConvoyManagergoroutinesrunEventPoll5s、runStrandedScan30s、feedFirstReady、启动清扫与恢复模式internal/cmd/convoy.go所有gt convoy子命令 findStrandedConvoys类型过滤 isReadyIssueinternal/cmd/sling.go批量检测约 242 行起、自动 Rig 解析、弃用警告internal/cmd/sling_batch.gorunBatchSling、resolveRigFromBeadIDs、跨 Rig 护栏internal/cmd/sling_convoy.gocreateAutoConvoy、createBatchConvoy、printConvoyConflict、getConvoyInfoFromIssueinternal/cmd/convoy_stage.gogt convoy stageDAG 遍历、波次计算、错误/警告检测、staged convoy 创建internal/cmd/convoy_launch.gogt convoy launch状态转移、Wave 1 派发dispatchWave1、parked rig 检查internal/daemon/daemon.godaemon 启动——约 237 行处创建ConvoyManager设计文档stage-launch 的 PRD 与测试计划见 docs/design/convoy/stage-launch/prd.md 与 docs/design/convoy/stage-launch/testing.md更宏观的 convoy 设计生命周期、规格、路线图见 docs/design/convoy/convoy-lifecycle.md、docs/design/convoy/spec.md 与 docs/design/convoy/roadmap.md。该技能文档的原始出处为 docs/skills/convoy/SKILL.md撰写 convoy 相关代码、调试或测试时可直接以它为触发依据。【免费下载链接】gastownGas Town - multi-agent workspace manager项目地址: https://gitcode.com/GitHub_Trending/ga/gastown创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考