用途：为同一 epic 内的工作项（Work Item，WI）提供一种编号约定，用 Subject__c 的数字前缀表达先后顺序与并行关系。适合 epic 级规划，或用户明确说明依赖关系时使用；独立工作项不必编号。该约定是 gus-cli 的配套，后者负责查询、创建、更新、状态与 ID 等 CLI 操作。
编号形式：在 Subject__c 前加带点号的数字和单个空格，例如 1 Set up the runtime service、2 Migrate the parser to the runtime、1.1 Add config schema、1.2 Add config loader。顺序编号（1、2、3）表示按序执行，2 等 1，3 等 2；并行编号（1.1、1.2）为同父级兄弟，彼此不等待。组门控：某层级的下一编号需等待前一编号下的全部工作（含 1.x、1.x.y）完成，支持任意深度递归。
就绪规则：某个 WI 之前排序的全部 WI（更浅或同级祖先层）完成时，该 WI 就绪；兄弟并行，兄弟组门控父级下一编号。例如 1.1 及其后代完成后 1.2 就绪，1 下全部完成后 2 就绪。完成定义为 Status__c 为 Closed 或 Completed；Fixed 不算完成（通常表示 PR 未合并），Fixed、Ready for Review、QA In Progress 等非终态不满足前置条件。
分配方法：先铺开工作项，必须先后发生的用顶层顺序编号（1、2），某步骤下并行的用同父级不同后缀（1.1、1.2），独立的保持无编号；编号加空格写入 Subject__c，通过 gus-cli 创建。建议每组从 1 密集编号，允许有间隔（按数值排序，间隔无害）。
读取方法（如询问 epic 中哪些就绪/未阻塞）：查询 epic 的 WI 及 Status__c，查询时不要加“仅未完成”过滤，因为已完成的前置是 Closed，会被该过滤排除；解析 Subject__c 开头的点分数字，无编号即独立；编号项在其之前排序的祖先全部完成时才就绪；结果分三组报告：当前就绪（未阻塞的编号项与全部无编号项）、被阻塞（注明阻塞编号）、已完成（可选）。按整数段排序（1.2 在 1.10 前），无编号排最后。
边界情况：格式错误（1.、1..2、1.x）按无编号处理并标记，可能是依赖笔误；重复编号（两个 1.2）视为并行兄弟，不标记；孤儿子项（有 1.1 无 1）规则仍成立，不要求父项存在；非序列数字（如 W-12345 回移、版本 2.40 发布）只有开头的 N/N.N… 加空格计为编号，含义不明时先询问。跨 epic 依赖写入 WI 正文文字，不用编号表达。本资料未提供具体版本、许可或收费信息。