# 阶段 1.6 — 独立 Skill 晋级门（产品化验证）

## 为什么需要这一步

阶段 1.5 回答的是"这个候选是否值得保留"（知识验证）。它没有回答第二个问题：
**它是否值得成为一个独立、可发现、可安装的 Skill**（产品化验证）。

把每个通过验证的知识点都变成独立 Skill,会制造安装负担、命名理解成本和相邻能力
之间的触发竞争（《纳瓦尔宝典》样本因此产出 19 个 Skill,这是真实读者反馈"Skill
太多"的直接来源）。晋级门把"知识保留"和"Skill 数量"解耦：**未晋级的方法完整保留
为来源路由入口内的能力卡,不会被删掉,也不会失联。**

## 五条判据

一个候选只有同时满足以下条件,才有资格成为晋级 Skill：

| # | 判据 | 问题 | 要求 |
|---|---|---|---|
| 1 | 独立意图 | 用户会不提书名、单独提出这个任务吗？ | **必须通过** |
| 2 | 独立契约 | 有自己的输入、步骤、输出和完成标准,不只是一个观点或术语？ | **必须通过** |
| 3 | 独立运行 | 不加载全书或多个兄弟能力也能正确执行？ | **必须通过** |
| 4 | 独立复用 | 预计会在多个任务/项目中重复调用,或需要被其他 Skill 组合？ | 与 5 至少 1 条通过 |
| 5 | 独立评测 | 能写出明确的正向、负向、近邻和输出断言？ | 与 4 至少 1 条通过 |

## 执行步骤

1. 对 `verified.md` 中每个单元逐条评审五条判据,记录布尔结果与一句话理由;
2. 把结果写入 Capability Bundle（`verified.yaml`）中该能力的 `promotion` 字段:
   - 通过 → `destination: promoted`
   - 未通过 → `destination: router`（保留为能力卡,经来源路由入口访问）
3. 检查预算: 可发现入口总数（1 个来源路由入口 + 晋级 Skill 数）默认软预算 **8**。
   超出时按预期调用频率、跨场景复用、独特性、证据强度和触发可分性排序,
   超出预算的候选先降为能力卡;只有用户明确选择 exhaustive 且验证证明不能安全合并时才允许超过;
4. 同步 `destinations.json`: 每个 active 能力恰好一个主要去向（`promoted_to` 或 `served_by`）。

## 硬规则

- 不能为了卡数量,把输出契约不同的能力强行拼成一个模糊 Skill;
- 未晋级候选**不进入 rejected/**,它们通过了知识验证,只是不单独发现;
- 晋级 Skill 与来源路由入口必须互有近邻负例（阶段 4 验证）,避免同一请求双触发;
- 晋级判定的目标函数是: **用最少的可发现入口覆盖最多的高价值用户意图,同时不让任何能力失联。**

## split-on-evidence

single-first 不是单向门。当出现以下证据时,可把能力卡提升为独立 Skill：

1. 用户显式请求（`cangjie.py replan-output --dry-run` 生成 side-by-side 预览）;
2. 用户自愿导出的本地路由记录（默认关闭,只记 capability_id 与时间戳）;
3. 社区反馈聚合（issue / 反馈表中"我希望 X 能单独触发"的诉求）。

任何情况下都不得在用户不知情时上报使用数据。拿不到证据就诚实保持现状,不用猜测代替证据。