正文
获取原文件methodology/03b-stage1.6-promotion-gate.md
为什么需要这一步
阶段 1.5 回答的是"这个候选是否值得保留"（知识验证）。它没有回答第二个问题： 它是否值得成为一个独立、可发现、可安装的 Skill（产品化验证）。
把每个通过验证的知识点都变成独立 Skill,会制造安装负担、命名理解成本和相邻能力 之间的触发竞争（《纳瓦尔宝典》样本因此产出 19 个 Skill,这是真实读者反馈"Skill 太多"的直接来源）。晋级门把"知识保留"和"Skill 数量"解耦：未晋级的方法完整保留 为来源路由入口内的能力卡,不会被删掉,也不会失联。
五条判据
一个候选只有同时满足以下条件,才有资格成为晋级 Skill：
| # | 判据 | 问题 | 要求 |
|---|---|---|---|
| 1 | 独立意图 | 用户会不提书名、单独提出这个任务吗？ | 必须通过 |
| 2 | 独立契约 | 有自己的输入、步骤、输出和完成标准,不只是一个观点或术语？ | 必须通过 |
| 3 | 独立运行 | 不加载全书或多个兄弟能力也能正确执行？ | 必须通过 |
| 4 | 独立复用 | 预计会在多个任务/项目中重复调用,或需要被其他 Skill 组合？ | 与 5 至少 1 条通过 |
| 5 | 独立评测 | 能写出明确的正向、负向、近邻和输出断言？ | 与 4 至少 1 条通过 |
执行步骤
- 对
verified.md中每个单元逐条评审五条判据,记录布尔结果与一句话理由;reference/needs_review不进入晋级门；前者落实到参考文件，后者先补来源/条件/验证。单处完整机制通过新版三关后与其他 verified 候选平等参与，不因语境数量再被拦截。 - 把结果写入 Capability Bundle（
verified.yaml）中该能力的promotion字段:- 通过 →
destination: promoted - 未通过 →
destination: router（保留为能力卡,经来源路由入口访问）
- 通过 →
- 检查预算: 可发现入口总数（1 个来源路由入口 + 晋级 Skill 数）默认软预算 8。 超出时按预期调用频率、跨场景复用、独特性、证据强度和触发可分性排序, 超出预算的候选先降为能力卡;只有用户明确选择 exhaustive 且验证证明不能安全合并时才允许超过;
- 同步
destinations.json: 每个 active 能力恰好一个主要去向（promoted_to或served_by）。
硬规则
- 不能为了卡数量,把输出契约不同的能力强行拼成一个模糊 Skill;
- 未晋级候选不进入 rejected/,它们通过了知识验证,只是不单独发现;
- 晋级 Skill 与来源路由入口必须互有近邻负例（阶段 4 验证）,避免同一请求双触发;
- 晋级判定的目标函数是: 用最少的可发现入口覆盖最多的高价值用户意图,同时不让任何能力失联。
split-on-evidence
single-first 不是单向门。当出现以下证据时,可把能力卡提升为独立 Skill：
- 用户显式请求（
cangjie.py replan-output --dry-run生成 side-by-side 预览）; - 用户自愿导出的本地路由记录（默认关闭,只记 capability_id 与时间戳）;
- 社区反馈聚合（issue / 反馈表中"我希望 X 能单独触发"的诉求）。
任何情况下都不得在用户不知情时上报使用数据。拿不到证据就诚实保持现状,不用猜测代替证据。