用途：convoy 系统用于跟踪跨 rig 的批量工作。convoy 本身是一个 bead，通过依赖关系跟踪其他 bead；守护进程监控关闭事件，当某个任务完成时投喂下一个就绪 issue。
主要能力：三条创建路径（gt sling 自动创建、gt convoy create 显式创建、gt convoy stage 校验后创建）与两条投喂路径（约 5 秒轮询的事件驱动投喂、约 30 秒的 stranded 扫描），共用同一套安全守卫。守卫包括：类型过滤（仅 task、bug、feature、chore 及空类型可派发，epic、convoy、decision 跳过）、blocks 依赖检查（未关闭的 blocks、conditional-blocks、waits-for 会跳过，parent-child 不阻塞，存储错误时 fail-open）、派发失败后继续迭代下一个就绪 issue。
使用方式：常用命令包括 gt convoy stage <epic-id>（分析依赖、构建 DAG、计算波次、创建 staged convoy）、gt convoy launch hq-cv-abc（staged 转 open 并派发 Wave 1）、gt convoy create/add/check/status/list/stranded/close/land，以及 gt convoy -i 交互式浏览。批量 gt sling <bead1> <bead2> <bead3> 会创建一个 convoy 跟踪全部 bead，rig 由 bead 前缀自动解析。
适用场景：epic 交付、批量任务跟踪、按依赖波次有序派发。限制：staged convoy 对守护进程完全惰性，不会被投喂；混合前缀、未映射前缀或已被其他 convoy 跟踪的 bead 会报错；波次计算仅纳入可派发类型，epic 不进入波次。测试命令与更多细节见原文。