# N2: 进入 Feature

1. 读取该 feature 的 requirements.md、design.md、tasks.md；存在
   `test-cases.json` 时按 `../../../runtime/test-contract.md` 一并加载，并把
   `taskIds` 命中当前任务的用例加入执行计划
2. 断点恢复：`[x]` 已完成 → 跳过，`[DROPPED]` → 跳过，`[CHANGED]` → 按更新后描述执行。**恢复时凭证对账**：每个已 `[x]` 任务 ↔ `{SPECS_DIR}/.reviews/*-{任务号}-r*.md` 配对，缺失项输出一行 `⚠ 凭证缺失: T-xxx,...（存量欠账,如实留档,恢复起严格执行）`——不阻塞恢复，但缺失不许无声混过（实跑失守：json-keeper 7 任务全无凭证,中断前无人发现）
3. 如该 feature 所有任务已完成 → 跳过，进入下一个 feature

## 教训定向注入（防复发，两个动作）

- **筛相关教训**：按本 feature 的领域/模块/技术栈关键词从 `LESSONS.md` 筛出相关条目（文件不存在或无匹配 → 注入 0 条照常继续,执行计划中输出一行说明）（`[仅记忆]` 级优先——`[已结构化]` 的已有代码防线兜底），把要点列进执行计划输出；并行派发时相关教训随 specs 摘录一并写进 agent 指令。全量加载靠注意力,定向注入才可靠（实跑教训：Infinity 防线教训在库仍复发）
- **必扫「待触发备忘」段**：逐条判断触发条件是否与本 feature 相关——命中 → 升级为任务或在执行计划中显式认领；未命中 → 不动。扫过即在执行计划输出一行 `📌 备忘扫描: 命中 {N} 条 / 共 {N} 条`，零条也要输出（可见性纪律）

## 执行计划

分析 tasks.md 的依赖关系，自行决定串行或并行：

| 串行 | 并行 |
| ---- | ---- |
| 有显式依赖 | 无依赖 |
| 会修改同一文件/模块 | 分属不同代码项目 |
| 涉及共享状态定义（schema、API、design token） | 天然隔离 |

并行执行完全遵守 `runtime/orchestration.md`。Codex 中只在运行时确实支持子代理、边界不重叠且主执行者仍保留 specs/度量/git 单写权时派发。指令必须包含：任务编号、specs 摘录、接口契约、文件范围、应用的 `cm-*-engineer` skill 及显式验证命令。任何条件不满足就串行。

**分工原则**：子代理只实现指定任务，不碰界外文件、不写 specs、不提交、不自行标记。主执行者回收产出后逐个验证并走 N4 → N5；QA 与 doc-sync 保持串行。

不依赖任何 Claude 实验开关或固定 agent 文件名；Codex 的具体并行能力由当前会话工具决定。

输出：

```text
📂 Feature {N}/{总数} — {feature名}
📋 执行计划：
  串行 1: T-001 → T-002
  并行 2: T-003 + T-004
  串行 3: T-005 ← 依赖 T-003, T-004
```