Capmap Scheme

---
name: capmap-scheme
description: >-
  编写或修订进行中方案：位于 <docs_root>/方案/<主题>/（docs_root 见
  .agents/skills/capmap-system/capmap.yaml），必须维护 ## 变更记录。
  写完或改完后须按 grilling 方式把待确认点分轮反问用户，达成共识后再标已确认/开干。
  已归档方案的新需求须开增量版本（Vn）。方案主状态承载开发/验证/落地进度。可独立使用。
---

# capmap-scheme — 写 / 改方案

原则：[capmap-system](../capmap-system/SKILL.md) · Tag：[status-tags](../capmap-system/reference/status-tags.md)

## 启动

1. 读 `.agents/skills/capmap-system/capmap.yaml` → `docs_root`
2. 无配置 → 先 [capmap-init](../capmap-init/SKILL.md) 或询问用户
3. **Inbox**：读 `<docs_root>/文档首页.md` 的 `## Inbox · 未立项`（见下节）

## Inbox（跨会话接力）

契约：[directory-contract](../capmap-system/reference/directory-contract.md) · 样例：[templates](../capmap-system/reference/templates.md)

首页一节，**不是**方案、**不是**台账。列：`碎片`（唯一）/ **`开干指令`（必填，可当 user prompt）** / `出口` / `记下日期` / `来源`。无 `状态/*`，碎片不进底图 §1。

1. **扫**：有数据行时列出碎片 + 开干指令 + 出口，问是否对应某行；空表不问。新对话**默认不**倒表。
2. **记**：用户说「先记下」或本轮明确不做的合格念头 → **先建议整行**（必须含开干指令），点头再写。写不出开干指令、已在做的票、已落盘观察项 → 不进表。单次最多 3 行。
3. **干**：人点名一行 → **当场执行**该开干指令（写了先 grilling 则不得偷跑）。执行已启动后按 `碎片` 列删行。出口允许改判。
4. **丢掉**：人点名后只删行；**不**写任何方案「未采纳」。

## 硬规则

1. 路径：`<docs_root>/方案/<主题>/<方案标题>.md`（活跃方案禁止留在 `_archive`）
2. 必须有 **`## 变更记录`**
3. 大改方向：仅 `方案中` 可自由改；`已确认` 及之后大改 → 开 Vn（实现期小修正可 append 变更记录）
4. 文首链底图；底图 §0 挂进行中方案
5. 文首 YAML：`方案` + **一个**主状态 +（`已确认` 及之后）**一个** `体量/小|大`：  
   - 小：`方案中` → `已确认` → `开发中` → `已开发` → … → `已归档`  
   - 大：`方案中` → `已确认` → `规格中` → `已拆分` → `开发中` → `已开发` → … → `已归档`  
   **禁止跳步**，见 [status-tags](../capmap-system/reference/status-tags.md)
6. **开干编码**时：小需求方案改为 `开发中`；大需求须先经 spec/slice，由 gate 点名后进入 `开发中`（不要只改底图）
7. 能力底图**不要**加 `状态/*` Tag
8. 不在此阶段归档（除非用户同时要求）
9. **写完 / 改完方案后必须走「待确认反问」**（见下节）；在用户确认共识之前：禁止标 `已确认`、禁止暗示可以开干编码、禁止擅自把待确认当成已决写入正文定案
10. **禁止**在方案阶段或开发未测时标 `已落地`
11. 升 `已确认` 时必须做 **体量判断**（见下节）：Agent 先建议小/大并说明理由，询问用户是否可行，确认后再写入 `体量/*`

### 体量判断（升已确认时）

1. Agent 根据是否多会话、是否需逐步质检、是否要垂直切片等，给出 **小 / 大** 建议与一句理由。  
2. **询问用户是否可行**；用户可改判。  
3. 确认后写入 YAML `体量/小` 或 `体量/大`。  
4. **禁止**静默自定体量后直接开干。  
5. 小 → 提醒短路径（编码 → Agent 对照方案 → capmap-dev → **询问是否转测试**）；大 → 提醒 [capmap-spec](../capmap-spec/SKILL.md) → [capmap-slice](../capmap-slice/SKILL.md) → [capmap-gate](../capmap-gate/SKILL.md)。

### 已归档后再改需求 → 开 Vn

基线留 `_archive` 且 `状态/已归档`；新建 Vn 为 `方案中`；底图 §1 可新增能力行（正文状态列，非 YAML Tag）。

## 待确认反问（grilling）

参考 grilling：把方案里的未决点当成**设计树**，按轮追问到共识，再落笔。

### 何时触发

- 新建方案写完首稿后（默认仍为 `方案中`）
- 方向微调改正文后，若仍有未决点
- 用户说「确认一下」「评审」「开干前过一遍」等

### 怎么做

1. **抽取待确认点**（事实自己查，决策问用户）：范围边界、取舍、不做项、接口/数据假设、验收标准、与既有能力冲突等。可在方案中维护 `## 待确认`（可选），但反问不依赖用户先写好该节。
2. **按轮推进**：每一轮只问当前 **frontier**（前置已决、现在就能答的问题）。一轮内问题编号列出，**等用户答完再开下一轮**。依赖本轮答案的问题留给后续轮。
3. **单题格式**（必须带推荐项）：

```
❓ **Q1** - **<题目标题>**：题干（可含选项 A/B/C）

➡️ <你的推荐答案与一句理由>
```

4. **事实 vs 决策**：环境/代码/仓库里能查到的事实 → Agent 自查（可并行），不要问用户；决策 → 必须反问并等待。
5. **收口**：frontier 为空、用户明确「就这样 / 确认 / 开干」后：
   - 把拍板写入 **`## 变更记录`**（触发可写「评审/grilling」）
   - 改正文中仍写着「待定」的段落
   - 删除或清空已决的 `## 待确认`
   - 做 **体量判断 + 询问用户**（见上节）
   - 方案 Tag → **`状态/已确认`** + `体量/小|大`（若用户只要改文案不升状态，听从用户）
6. **未收口前**：保持 `方案中`；可先保存草案，但回复里必须抛出本轮 grilling 问题，而不是只丢「方案写好了」。

### 与 grilling 的关系

- 不要求用户再说「grill me」；**capmap-scheme 写方案即默认带一轮以上反问**。
- 用户明确「先别问、只要草稿」→ 可跳过，但文首/回复注明「待确认未 grilling」；之后升 `已确认` 前仍须补问（含体量）。

## Checklist

```
- [ ] 1. 解析 docs_root；确认主题与底图存在
- [ ] 1b. Inbox 非空则列出碎片/开干指令/出口，问是否对应某行；对上则执行该指令再删行（空表跳过）
- [ ] 2. 已归档目标 → 新建 Vn
- [ ] 3. 写/改方案正文 + ## 变更记录；文首回链底图；§0/索引更新
- [ ] 4. 方案仅一个合法主状态 Tag；底图无状态 Tag
- [ ] 5. 抽取待确认点 → grilling 分轮反问（带 ➡️ 推荐）→ 等用户答完
- [ ] 6. 共识后：变更记录落定案；正文去待定；体量判断+询问 → Tag 已确认+体量
- [ ] 7. 提醒下一步：小 → 开发中 →（对照方案）capmap-dev → 询问转测试；大 → capmap-spec → slice → gate → capmap-dev → test → …
```