用途：为同一 epic 内的 GUS 工作项建立编号约定，用 Subject__c 的数字前缀表达先后顺序与并行关系，并据此判断工作项的就绪状态。它是 gus-cli（负责查询、创建、更新、状态与 ID 等 CLI 机制）的配套约定。
主要能力：在 Subject__c 前加“点分数字 + 单个空格”作为前缀。顺序编号（1、2、3）表示依次等待，2 等 1，3 等 2；并行编号（1.1、1.2）表示同父级兄弟项，互不等待；组门控指下一编号需等待前一编号下所有工作（含 1.x、1.x.y）完成；支持任意深度（1.1.1 等），规则递归适用。就绪规则：某工作项之前（在更浅或同级祖先层级）排序的所有工作项都完成时，它才就绪。完成指 Status__c 为 Closed 或 Completed；Fixed 不算完成，通常表示 PR 尚未合并，Fixed、Ready for Review、QA In Progress 等非终态不满足前置条件。
使用方式：编号是可选的。适合 epic 级规划或用户明确说明依赖关系时使用；独立工作可跳过，也不要把一堆独立项组成的 epic 重新编号。无编号表示无依赖、也不被依赖，始终就绪，不参与门控。若 epic 需要新增或更新 ADR，ADR 编写工作项应取最小编号（单个 ADR 为 1，并行兄弟为 1.1/1.2），依赖项从 2 开始；创建其余工作项前先与用户确认所需 ADR 及其位置（仓库级 docs/adr/ 或包级 packages/*/docs/adr/）。规划时按“必须先于”排为顶层顺序编号，同一步骤下的并行项用同父级不同后缀，独立项不编号，再通过 gus-cli 创建。读取时查询 epic 工作项（含 Status__c，不要只筛未完成，因为已完成的前置项是 Closed），解析 Subject__c 前导点分数字，按整数段排序（1.2 在 1.10 前），无编号排最后，并报告“现在就绪”“被阻塞（注明阻塞编号）”“已完成”三组。
限制与边界：编号仅限 epic 内作用域，跨 epic 依赖应写在工作项正文中而非编号。格式异常（如 1.、1..2、1.x）按无编号处理并标记，可能是依赖笔误；重复编号（两个 1.2）视为并行兄弟，不标记；孤立子项（有 1.1 无 1）规则仍成立，不要求父项存在；非顺序数字（如 W-12345 回移、版本 2.40 发布）只有前导 N/N.N… 加空格才算编号，含义不明时应询问。资料未提供更多实现细节。