# Path A Legacy-Host Increment Rule Implementation Plan（老宿主增量 element 选源 —— R7 场景 2 的 mockup 侧镜像）

> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.

**Goal:** 给 Path A（mockup 侧）补上「已有**不符合**设计系统的老产品做小功能迭代」时的 element 级选源规则，使其与 Path B 的 `code-conventions.md` R7 场景 2 构成登记在册的 mirror pair。

**Architecture:** 新条文以 **M21 家族子规则**（占位 `M-NEW`，预计 M21.3）落在 `docs/internal/design-process.md` §M21.2 之后；四件套一次做齐 —— 规则正文（含四档表 mockup 版 + trace 产出物）、`mockup-conventions.md` 顶部 jump 表触发行、与 R7 场景 2 的双向 cross-ref、实证段（owner 2026-08-12 裁定 + M17 2026-08-05 泛化先例）。另改 Task Entry Modes 的 US-3 行、条件性给 `CONVENTIONS-OVERVIEW.md` §3.3 mirror pairs 表加行。

**Tech Stack:** 纯 Markdown 规则文档编辑 · `pnpm rule:next` 取号 · `audit:rule-load-map` / `audit:rule-inventory` / `audit:stale-anchors` / `audit:rule-number-collision` 四道机械闸。

## 判据真源（owner 裁定记录 · 2026-08-12）

- **Owner 裁定（逐字）**：「**这个应该是以产品当前版本为准，遵循所有产品页面的 UX 交互一致性**」—— 确认 Path A（mockup）与 Path B（code，R7 场景 2）同原则。
- **边界（同轮确认）**：**判定单位是 element，不是页面** —— 老页面加宿主从没有过的控件仍从 DS 取，因为宿主里没有可一致的对象。
- **缺口定位**：code 侧已有完整条文（R7 场景 2 element 级四档决策表 + 场景 4「TVU 规范校正须显式发起」边界，`code-conventions.md:437-635`）；mockup 侧只有 US-7（redesign 提案，重活）和 US-3（增量，默认宿主合规），中间「老 mockup 不合规、只改一小块」这档落空。
- **同型病先例**：2026-08-05 M17 泛化（`docs/internal/domain-tvu.md` §M17 头部注记，owner 拍板）——「根因不是缺规则，而是**规则的 surface 覆盖不对称**：LCD 有本条、另一端没有对应条文，于是同一个 feature 的两端一边合规、一边完全没对齐宿主页面」。本计划补的是同型病在 Path A / Path B 轴上的实例。

## Placement 结论（执行前置判断，已按活源实测）

**扩 M21 家族（子规则，预计 M21.3），不开新顶级 M-rule。** 依据（全部为 2026-08-12 活源实测）：

1. `CONVENTIONS-OVERVIEW.md` §7 第 5 条：「Check for umbrella fit — prefer adding a sub-section rather than a new top-level ID」。
2. **M21 主条已含同原则的一半**：`design-process.md` §M21 决策树（existing local > source > 自制）+ §例外里逐字存在「**澄清 — pre-design-system 不视为 bug**：pre-design-system 时代的违反 = 合规的历史范式，增量任务继续 mirror，不做 in-place 修正。需用户显式发起独立任务。」——开新顶级 ID 会与 M21 形成双真源；子规则把这句「澄清」升格为正式档位，不分叉。
3. **M21.2 是既有范式**：M21.2（Feature Iteration Color Contract）已是 US-3 前置，管「颜色**值**从 sibling 实测取、禁默认套 DS token 值」。本条 = 同一原则从颜色泛化到组件/布局/交互——管「**型**」。家族内分工清晰（见规则正文的分工表）。
4. **机械成本**：M21.x 是 `### `（H3）子标题，不进 `design-process.md` 头部 `rule-inventory` 块（该块只列 H2）——`audit:rule-inventory` 免动。若误写成 H2，该闸会红，这是护栏。

## Global Constraints

每个 Task 的要求都隐含包含本节。

- **规则编号不预写死**：本计划一律用占位符 **`M-NEW`**（预计 = M21.3）。执行 Task 1 时 `pnpm rule:next M21` **从 origin/master 取号**，以其返回为准——本地工作树是会过期的镜像（2026-08-11 PR #9 实证：分支分叉 62 天后按本地最大号编，撞了 master 上早已占用的号）。取号后全局替换 `M-NEW`，收尾 `grep -rn "M-NEW" docs/` 必须 0 命中。
- **四件套一次落地、一次 commit**：规则正文 + jump 表触发行 + 与 R7 场景 2 的**双向** cross-ref（mirror pair 惯例 = 两侧都有完整条文 + 互引，不是单侧引用）+ 实证段。缺任何一件不许提交。
- **规则正文必须含**（Task 2 候选文本已全写好，执行者只做粘贴+替号+微调）：① element 级四档决策表 mockup 版（与 R7 逐档对齐，用 frame / instance / library 语言）② 「pre-DS mockup 不视为 bug」③ 「整体规范化须显式发起 → US-7」④ 与 M21.2 的分工声明（M21.2 管颜色取值，本条管组件/布局/交互选型）⑤ trace 产出物小节（给并行计划留锚点，见下方 §依赖与并行计划）。
- **活源优先**：本计划引用的现行条文片段（含行号）是 2026-08-12 快照。执行时若与活源不一致（并行 session 可能已改），**以活源为准**，按语义找等价锚点，改不动就 STOP 回报——禁按本计划的引文硬贴（plan 的 fixture 不是判据真源）。
- **锚点形态**：新增跨文件引用一律「文件级链接 + § 号写在链接文本里」（如 `[\`design-process.md\` §M-NEW](./design-process.md)`），**不带 `#fragment`**——`audit:stale-anchors` 会核 fragment slug，无 fragment 则只核文件存在 + rule-ref 存在，最稳。
- **提交纪律**（多 session 并行、共享 git index）：先 `git diff --stat -- <路径…>` 核行数；`git commit -F <msg 文件> -- <显式路径…>`（**`-F` 在 `--` 之前**）；**紧跟 `git reset -- <路径…>`**。pre-commit 闸链可超 2 分钟 → commit 用 `run_in_background` 跑。撞 `.git/index.lock` = 对方正在提交，等一下重来。
- **纯 docs 改动不写 changeset**；不开 worktree（纯 .md session 不开，repo memory 实证）；owner 惯例直 commit master。
- **执行后必须全绿**：`pnpm run audit:rule-load-map` + `pnpm run audit:rule-inventory` + `pnpm run audit:stale-anchors`（外加 `pnpm run audit:rule-number-collision`，pre-commit 也会拦，但先手跑省一轮）。
- **STATUS.md / work-log 更新走执行 session 自己的 wrap-up 协议**，不在本计划任务面内。

## 依赖与并行计划

- **`docs/superpowers/plans/2026-08-12-element-decision-trace-product.md`**（判定表 trace 产出物，并行计划，撰写本计划时**尚未落仓**）：trace 表的 **mockup 侧镜像随本条规则落地**（= Task 2 候选文本里的 `#### M-NEW trace 产出物（mockup 侧 element 判定 trace）` 小节，此标题即给对方的稳定锚点）。列结构约定：`element / 宿主有？（实证）/ TVU 库有？（实证）/ 档位 / 决策` 五列。**谁后落地谁对齐**：若对方先 ship 了 code 侧 trace 列结构且与五列不一致，执行本计划时把示例表列名对齐对方并在 commit msg 注明；若本计划先落地，对方以本条为镜像基准。
- **rule-inventory-mirror-gate-extension（并行计划）可能把 `CONVENTIONS-OVERVIEW.md` 指针化**：Task 5 对 OVERVIEW 的动作写成条件步骤——§3.3 表仍存在则加行，已指针化则跳过。

---

## File Structure

| 文件 | 责任 | 动作 |
|---|---|---|
| `docs/internal/design-process.md` | M-NEW 规则正文（M21.2 之后）+ M21 主条两处指针 | 新增 1 节 + 改 2 处 |
| `docs/internal/code-conventions.md` | R7 场景 2 四档表下加 mirror 指针 + §与既有规则关系 追加一句 | 改 2 处 |
| `docs/internal/mockup-conventions.md` | 顶部 §🤖 AI 读取指引 jump 表加触发行 + Task Entry Modes US-3 行加限定 | 改 2 处 |
| `docs/internal/CONVENTIONS-OVERVIEW.md` | §3.3 Mirror pairs 表加一行（**条件步骤**） | 条件改 1 处 |

---

## Task 1: 取号 + 活源基线核对

**Files:**
- 只读 + 命令，无文件改动。

**Interfaces:**
- Produces: 实际规则号（下文所有 `M-NEW` 的替换值）→ Task 2/3/4/5 全部消费。

- [ ] **Step 1: fetch 并从 origin/master 取号**

```bash
git -C /Users/nancy/Documents/AICoding/VS_Code/tvu-design-system fetch origin
pnpm rule:next M21
```

预期：输出下一个可用子号（预计 `M21.3`）。若输出降级提示（拿不到 origin/master）→ STOP，先解决网络/远端，**不许用降级结果直接开写**（本条规则会进 master，撞号成本高于等待）。

- [ ] **Step 2: 核对本计划引用的活源片段仍在（防并行 drift）**

```bash
cd /Users/nancy/Documents/AICoding/VS_Code/tvu-design-system
grep -n "场景 2 视觉真源细化" docs/internal/code-conventions.md
grep -n "pre-design-system 不视为 bug" docs/internal/design-process.md
grep -n "M21.2 — Feature Iteration Color Contract" docs/internal/design-process.md
grep -n "US-3.* Existing product 增/改/删" docs/internal/mockup-conventions.md
grep -n "### 3.3 Mirror pairs" docs/internal/CONVENTIONS-OVERVIEW.md
```

预期：前四条各 ≥1 命中。第五条命中 → Task 5 走「加行」分支；0 命中（已被并行计划指针化）→ Task 5 走「跳过」分支。任何前四条 0 命中 → STOP 回报（活源已被并行 session 改动，需重对齐）。

- [ ] **Step 3: 确认取到的号未在活源出现**

```bash
git grep -n "M21\.3" origin/master -- docs/ || echo "CLEAN"
grep -rn "M21\.3" docs/internal/ || echo "CLEAN-LOCAL"
```

（把 `M21.3` 换成 Step 1 实际返回号。）预期两条都 CLEAN。不 CLEAN → 用 `rule:next` 提示的更高号。

---

## Task 2: design-process.md —— 写入 M-NEW 规则正文 + M21 主条两处指针

**Files:**
- Modify: `docs/internal/design-process.md`（三处；2026-08-12 快照行号：§M21 决策树 ≈1157-1165、§M21 例外澄清 ≈1188、§M21.2 实证段结尾 ≈1267。**以锚点文本为准，行号仅导航**）

**Interfaces:**
- Consumes: Task 1 的实际规则号。
- Produces: 规则正文标题 `### <号> — Legacy Host Increment Element Selection（老宿主增量 element 级选源）` + trace 小节标题（并行计划的锚点）→ Task 3/4/5 引用。

- [ ] **Step 1: 在 §M21.2 之后插入 M-NEW 正文（H3，禁 H2）**

定位锚点：M21.2 实证段结尾一句「本规则（M21.2）记录此次失误为防重设计。」之后、下一个 `---` 分隔线之前。插入下方候选文本（把 `M-NEW` 全部替换为实际号；**标题必须是 `###`**——写成 `##` 会进 H2 清单、`audit:rule-inventory` 红，那是护栏不是麻烦）：

```markdown

### M-NEW — Legacy Host Increment Element Selection（老宿主增量 element 级选源）（2026-08-12 新增）

> **Mirror（Path B / code 侧）**：本条与 [`code-conventions.md` R7 §场景 2 视觉真源细化](./code-conventions.md) 是 mirror pair —— 同一纪律在 mockup 层与 code 层各有完整条文并互引（登记见 [`CONVENTIONS-OVERVIEW.md`](./CONVENTIONS-OVERVIEW.md) §3.3）。
>
> **Owner 裁定（2026-08-12，逐字）**：「这个应该是以产品当前版本为准，遵循所有产品页面的 UX 交互一致性」。边界同轮确认：**判定单位是 element，不是页面** —— 老页面加宿主从没有过的控件仍从 DS 取（宿主里没有可一致的对象）。

**触发条件**：US-3 增量（含 US-5 小调整这类子集），且宿主产品的既有 mockup / 线上页面**整体不符合 TVU 设计系统**（pre-design-system 老产品）——本次只做小功能迭代，**不是** redesign（那是 US-7）。宿主本就 TVU 合规时不需本条（M21 主条 + M32 已覆盖）。

**四档判定表（判定单位 = element；与 code 侧 R7 场景 2 表逐档同构）**：

| element 状况 | 决策（mockup 语言） |
|---|---|
| ✅ 宿主既有 frame 里有该 element 的既有做法 + ✅ TVU 库也有对应组件 | **优先照宿主既有做法 mirror**（复用宿主 frame 的既有 instance / 自制样式 / 交互型式，避免同产品跨页面割裂） |
| ❌ 宿主没有 + ✅ TVU 库有 | **用 TVU 库 instance** ← 完全合法且鼓励（宿主里没有可一致的对象） |
| ❌ 宿主没有 + ❌ TVU 库没有 | **自建候选**（走 [`mockup-conventions.md` §M32.2](./mockup-conventions.md) 自建三件套 + 标 🟡 入库候选；需用户授权 + 登记 backlog） |
| ⚠️ 宿主有但旧 / 不符 TVU 规范 + ✅ TVU 库有新版 | **仍照宿主既有做法**（除非用户显式说「换 TVU 新版」）—— **pre-DS mockup 不视为 bug**（M21 §例外那句澄清在此升为正式档位） |

**整体规范化边界**：把老 mockup / 老页面整体改到 TVU 规范 = 独立 redesign 任务，须用户**显式发起**，入口 = [`mockup-conventions.md` §Task Entry Modes **US-7**](./mockup-conventions.md)，不混在增量任务里 —— 与 code 侧 R7 场景 4「须显式发起」同构。

**与 M21 家族分工（避免重叠管辖）**：

| 条 | 管什么 |
|---|---|
| M21 主条 | US-3 复用次序（existing local > source > 自制）+ Sibling Visual Contract probe |
| M21.1 | 建 component 时 clone existing vs from-scratch |
| M21.2 | **颜色取值**（「值」）：sibling frame 实测 hex，禁默认套 DS token 值 |
| **M-NEW（本条）** | **element 选型**（「型」：组件 / 布局 / 交互样式选宿主还是选库）的四档判定 + trace 产出物；选定「照宿主」后，具体色值仍走 M21.2 |

本条 = M21.2 同一原则（产品当前状态 > DS 规范文本）从颜色到组件 / 布局 / 交互的泛化，两条正交不重叠。

#### M-NEW trace 产出物（mockup 侧 element 判定 trace）

每个新增 / 改动 element 在 Phase 0 mapping 表上方（或并入 mapping 表加列）产出一行判定 trace，禁凭印象归档：

| element | 宿主有？（实证：frame / node id） | TVU 库有？（实证：catalog / library key 命中） | 档位 | 决策 |
|---|---|---|---|---|
| （例）筛选下拉 | ✅ Settings 页 `3014:9330` 自制下拉 | ✅ `Drop down List` | ⚠️ 档 4 | 照宿主自制下拉 mirror |

> code 侧（Path B）同构 trace 另行落地；两侧**列结构保持同构**（element / 宿主实证 / 库实证 / 档位 / 决策）。

**Acceptance**：

- [ ] 任务起手显式声明命中本条（宿主 pre-DS + 增量），并声明判定单位 = element
- [ ] 每个新增 / 改动 element 有一行 trace，「宿主有 / 无」结论带实证 frame / node id，不是印象
- [ ] 档 4 element 没有被「顺手换新」——除非对话里有用户显式指令
- [ ] 出现「整体规范化」意图时 STOP → 指到 US-7，未被混进本次增量

**Why**：产品用户的一致性感知来自「产品当前版本」，不来自 DS 规范文本。老产品小迭代里把单个 element 换成 DS 新版，制造的是页面内 / 页面间割裂，不是合规。DS 的正确进入方式是档 2（宿主真空处）与 US-7（显式 redesign），不是增量夹带。

**实证**（2026-08-12 owner 裁定 + 2026-08-05 同型病先例）：

- 2026-08-12：owner 确认 Path A 与 Path B（R7 场景 2）同原则（裁定逐字见本条头部）。此前 mockup 侧只有 US-7（redesign 提案，重活）与 US-3（增量，默认宿主合规），「老 mockup 不合规、只改一小块」这档落空——code 侧一直有 R7 场景 2 拦，mockup 侧同一件事没人拦。
- 2026-08-05 [`domain-tvu.md` §M17](./domain-tvu.md) 泛化先例（owner 拍板）：「根因不是缺规则，而是**规则的 surface 覆盖不对称**：LCD 有本条、另一端没有对应条文，于是同一个 feature 的两端一边合规、一边完全没对齐宿主页面」。本条即同型病在 Path A / Path B 轴上的补齐。
```

- [ ] **Step 2: M21 决策树尾部加指针**

定位锚点：§M21「### 决策树」列表第 3 项「3. 都没有 → 按 Library-First 例外（自制候选）」之后，紧跟插入：

```markdown

> **宿主为 pre-DS 老产品（整体不符 TVU 规范）时**：逐 element 的完整四档判定表 + trace 产出物见 §M-NEW（本决策树的 legacy-host 细化；mirror = [`code-conventions.md`](./code-conventions.md) R7 场景 2）。
```

- [ ] **Step 3: M21 例外澄清句尾加指针**

定位锚点：§M21「**澄清 — pre-design-system 不视为 bug**：……需用户显式发起独立任务。」把句尾改为「……需用户显式发起独立任务（入口 = US-7；四档判定表 + trace 产出物见 §M-NEW）。」

- [ ] **Step 4: 自验**

```bash
grep -n "Legacy Host Increment Element Selection" docs/internal/design-process.md
grep -c "§M-NEW\|§M21\.3" docs/internal/design-process.md   # 号已替换后用实际号
awk '/^## /' docs/internal/design-process.md | grep -i "legacy host" || echo "OK-not-H2"
```

预期：标题 1 命中；指针 ≥2；第三条输出 `OK-not-H2`（确认没写成 H2）。

---

## Task 3: code-conventions.md —— R7 场景 2 的双向 cross-ref（code 侧半边）

**Files:**
- Modify: `docs/internal/code-conventions.md`（两处；快照行号 ≈469-471 与 ≈582）

**Interfaces:**
- Consumes: Task 1 实际规则号；Task 2 的规则标题（链接文本用）。

- [ ] **Step 1: 四档表下插 mirror 指针**

定位锚点：§「场景 2 视觉真源细化（element-level + 成熟度光谱）」内，四档表最后一行「⚠️ local 有但旧/不规范 + ✅ TVU 有新版 | **仍用 local**（……）— pre-design-system 不视为 bug」之后、「产品 TVU 化成熟度光谱」段之前，插入：

```markdown

> **Mirror（Path A / mockup 侧）**：本表在 mockup 侧的完整镜像 = [`design-process.md` §M-NEW](./design-process.md)（同构四档，frame / instance / library 语言 + trace 产出物）。同根 owner 裁定（2026-08-12）：「这个应该是以产品当前版本为准，遵循所有产品页面的 UX 交互一致性」；判定单位 = element，非页面。
```

- [ ] **Step 2: §与既有规则关系 追加**

定位锚点：R7「### 与既有规则关系」的 bullet「- 与 mockup-conventions 的 M2 / M21 同根（同源原则在 mockup scope 的镜像）」，在句尾追加：「；**场景 2 四档表的 mockup 侧完整条文 = [`design-process.md` §M-NEW](./design-process.md)（2026-08-12 mirror pair 补齐）**」。

- [ ] **Step 3: 自验**

```bash
grep -n "Mirror（Path A / mockup 侧）" docs/internal/code-conventions.md
grep -n "mirror pair 补齐" docs/internal/code-conventions.md
```

预期：各 1 命中。

---

## Task 4: mockup-conventions.md —— jump 表触发行 + US-3 行限定

**Files:**
- Modify: `docs/internal/mockup-conventions.md`（两处；快照行号 ≈56 与 ≈141）

**Interfaces:**
- Consumes: Task 1 实际规则号。

- [ ] **Step 1: §🤖 AI 读取指引「触发后再读」表加行**

定位锚点：`| §M46 | 迭代既有 mockup（clone 上期 page 改本期）起手前必读 |` 行之后，插入新行（与 §M17 行同款跨文件指针形态）：

```markdown
| [`design-process.md` §M-NEW](./design-process.md) **老宿主增量 element 选源四档**（宿主既有做法 vs TVU 库；pre-DS mockup 不视为 bug；判定单位 = element 非页面；整体规范化 → US-7） | **在整体不符 TVU 规范的老产品 mockup / 老页面上做小功能迭代（US-3 / US-5），要为任一 element 选「照宿主」还是「取库」**时——起手先出四档判定 trace，禁把宿主旧样式当 bug 顺手换 TVU 新版 |
```

- [ ] **Step 2: Task Entry Modes US-3 行加限定**

定位锚点（整行替换）。现行：

```markdown
| **US-3** Existing product 增/改/删 | "MicroApps Console mockup 加/改/删任意 frame 或元素" | Read handoff → Pre-Phase 0（仅变化部分）→ M0 → 画（仅 update 变化部分）|
```

替换为：

```markdown
| **US-3** Existing product 增/改/删 | "MicroApps Console mockup 加/改/删任意 frame 或元素" | Read handoff → Pre-Phase 0（仅变化部分）→ M0 → 画（仅 update 变化部分）。**宿主是 pre-DS 老产品（整体不符 TVU 规范）时，每个 element 选源先过 [`design-process.md` §M-NEW](./design-process.md)（四档判定，判定单位 = element；整体规范化 ≠ 本模式 → US-7）** |
```

> 决策记录：选「US-3 行内限定」而非新增 US-3b 行——US-3b 会涟漪到 R7 的 US↔场景映射表（`code-conventions.md:549-554`，现行「US-3 → 默认场景 2」对 legacy 宿主依然成立）、US-7 子流程「才进 US-1/US-3」、OVERVIEW §6 等多处枚举面；行内限定零涟漪且语义等价。owner 若更想要独立 ID 可推翻（见文末）。

- [ ] **Step 3: 自验**

```bash
grep -n "老宿主增量 element 选源四档" docs/internal/mockup-conventions.md
grep -n "整体规范化 ≠ 本模式" docs/internal/mockup-conventions.md
```

预期：各 1 命中。

---

## Task 5: CONVENTIONS-OVERVIEW.md §3.3 Mirror pairs 加行（条件步骤）

**Files:**
- Modify: `docs/internal/CONVENTIONS-OVERVIEW.md`（≈102-105 表内；**仅当 §3.3 表仍存在**）

**Interfaces:**
- Consumes: Task 1 实际规则号 + Task 1 Step 2 对 §3.3 存在性的核对结果。

- [ ] **Step 1: 按 Task 1 Step 2 的结果分支**

分支 A（`### 3.3 Mirror pairs` 仍存在）：在 `| M35 | R13 | Affordance-category search trace |` 行后加：

```markdown
| M-NEW (design-process.md) | R7 场景 2 (code-conventions.md) | Legacy-host increment element-level source selection |
```

分支 B（已被并行计划 rule-inventory-mirror-gate-extension 指针化 / 表不存在）：**跳过本 Task**，在 commit msg 里注明「OVERVIEW §3.3 已指针化，mirror 登记随其新真源」，并把这一点写进执行报告让 owner 知晓。

> 注：§9 Glossary 的 mirror pair 词条括号里是示例列表（M31↔R14…），非穷举登记面，**不改**。

- [ ] **Step 2: 自验（分支 A）**

```bash
grep -n "Legacy-host increment element-level source selection" docs/internal/CONVENTIONS-OVERVIEW.md
```

预期：1 命中（分支 B 则 0 命中且有跳过记录）。

---

## Task 6: 机械闸全绿 + 占位符清零 + 提交

**Files:**
- 无新改动；提交 Task 2-5 的全部文件。

- [ ] **Step 1: 占位符清零核验**

```bash
grep -rn "M-NEW" docs/ && echo "FAIL：还有占位符" || echo "CLEAN"
```

预期：CLEAN。

- [ ] **Step 2: 四道闸全绿**

```bash
pnpm run audit:rule-number-collision
pnpm run audit:rule-load-map
pnpm run audit:rule-inventory
pnpm run audit:stale-anchors
```

预期：全部 exit 0。任何一道红 → 按其输出修（这些闸的输出会直接指出该改成什么），修完重跑，**不许绕**。

- [ ] **Step 3: 核 diff 面**

```bash
git diff --stat -- docs/internal/design-process.md docs/internal/code-conventions.md docs/internal/mockup-conventions.md docs/internal/CONVENTIONS-OVERVIEW.md
```

预期：只有这 4 个文件（分支 B 则 3 个）；行数量级 = design-process 约 +60、其余各 ±2~4。异常大 → 先查是否卷入并行 session 的改动。

- [ ] **Step 4: 提交（后台跑，pre-commit 可超 2 分钟）**

msg 文件写入 scratchpad 后：

```bash
git commit -F <msg文件> -- docs/internal/design-process.md docs/internal/code-conventions.md docs/internal/mockup-conventions.md docs/internal/CONVENTIONS-OVERVIEW.md
git reset -- docs/internal/design-process.md docs/internal/code-conventions.md docs/internal/mockup-conventions.md docs/internal/CONVENTIONS-OVERVIEW.md
```

msg 候选（`M21.3` 换实际号；Co-Authored-By 按执行 session harness 惯例追加）：

```
docs(conventions): M21.3 老宿主增量 element 选源四档 —— 补齐 R7 场景 2 的 mockup 侧镜像

owner 2026-08-12 裁定：以产品当前版本为准，遵循所有产品页面的 UX 交互一致性；
判定单位 = element 非页面。四件套：M21.3 正文（design-process.md，含 trace 产出物）
+ mockup-conventions jump 行 + US-3 行限定 + R7 场景 2 双向互引 + OVERVIEW §3.3 登记。
同型病先例：2026-08-05 M17 泛化（规则的 surface 覆盖不对称）。
```

- [ ] **Step 5: push 后 `git ls-remote` 验落地**（本项目 commit 默认含 push）

```bash
git push origin master
git ls-remote origin master   # 比对本地 HEAD sha
```

---

## Owner 可推翻点（执行前不需再问，owner review 时可改判）

1. **Placement**：扩 M21 家族（M21.3）vs 在 mockup-conventions.md 开新顶级 M-rule。本计划选前者（依据见 §Placement 结论）；若 owner 要顶级 ID，改用 `pnpm rule:next M` 取号、正文落 mockup-conventions.md、且需同步动该文件 jump 表的 load-map 路由 + design-process.md §M21 处只留指针。
2. **US-3 行内限定 vs 新增 US-3b 行**：本计划选行内限定（零枚举面涟漪）；owner 若要独立 US-3b，需连带改 R7 US↔场景映射表等多处。
3. **Mirror pairs 登记形态**：既有四对都是「整条 M ↔ 整条 R」，本对是「子规则 ↔ R7 的一个场景段」——登记行把范围写进单元格；owner 若嫌形态不齐可改为登记「M21 ↔ R6/R7-场景2」族级对。
4. **trace 表列结构**（五列）：与并行计划 element-decision-trace-product 的对齐权在后落地方。

## Self-Review 记录（写完自审三查，2026-08-12）

1. **Spec 覆盖**：owner 裁定逐字收录（判据真源节 + M-NEW 头部）✅；四档表 mockup 版逐档对齐 R7 ✅；pre-DS 不视为 bug ✅；整体规范化 → US-7 ✅；M21.2 分工声明 ✅；四件套各有 Task ✅；编号占位 + rule:next ✅；Entry Modes 具体行文本 ✅；OVERVIEW 条件步骤 ✅；实证段（owner 裁定 + M17 泛化先例）✅；并行计划锚点 ✅。
2. **占位符扫描**：全文无 TBD/TODO；唯一故意占位 = `M-NEW`（Global Constraints 已定义其替换协议 + Task 6 Step 1 清零核验）。
3. **一致性**：规则标题「Legacy Host Increment Element Selection（老宿主增量 element 级选源）」在 Task 2/3/4/5 的链接文本与 grep 判据中一致；trace 五列列名在 §依赖与并行计划 与 Task 2 候选文本一致；四个文件路径在 File Structure / 各 Task / Task 6 提交清单一致。