# R7 场景 2 Element 归属判定表（decision trace）Implementation Plan

> **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:** 把 R7 场景 2（已有产品增量）的 element 级归属判定从「AI 脑内判完就动手」物化为**起手第一产出物**——一张 element 归属判定表（宿主有? / DS 有? / 落档 / 档号依据），让换 session / 换工具后可复核「这次到底照哪档判的」。

**Architecture:** 判定表规范文本**单点**落在 `docs/internal/code-conventions.md` R7 新小节（SOT）；两处激活指针（R7 后方「起手 5 步 checklist」step 1 + `skills/tvu-design-code/SKILL.md` 起手协议 step 6 的 R7 维度 bullet 内追加，不加新步骤号）；mockup 侧由并行 Path A 计划引用同一 SOT（见 §Path A 镜像锚点），本计划不写 mockup 侧任何文件。

**Tech Stack:** 纯 Markdown 文档 + skill 文本改动，无代码；验证 = 既有 4 条机械闸（`audit:rule-load-map` / `audit:rule-inventory` / `audit:stale-anchors` / `lint-skills`）。

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

owner 已确认方案：场景 2/3（已有产品增量，宿主合规或不合规）的 element 级归属判定，**起手先输出一张 element 级判定表当产出物**，形如：

```
| 元素 | 宿主有? | DS 有? | 落档 | 依据 |
|---|---|---|---|---|
| 保存按钮 | ✅ 旧样式 | ✅ | 宿主 | 第 3 档 · 跨页一致 |
| progress bar | ❌ | ✅ | DS | 第 2 档 · 宿主无可一致对象 |
```

- **不引入阈值、不引入自动判据**——R7 场景 2 四档表本身就是确定判据，本计划只把判定过程物化（同 [`CONVENTIONS-OVERVIEW.md`](../../internal/CONVENTIONS-OVERVIEW.md) §8 第 3 条 Externalize thinking as trace；同族先例 M24 / M35·R13 / M48）。
- **Enforcement 定位（owner 裁定，落地文本必须照写）**：trace 表是对话 / handoff 产出物而非 repo 文件，无法上 pre-commit 闸 → **L1 + skill checklist 层落地**。落地文本**禁止声称「有闸兜底」**。
- **编号对照（本计划的映射，见 owner 可推翻点 #5）**：裁定原文的「场景 2/3（宿主合规或不合规）」在 R7 编号体系下都落在**场景 2**——R7 场景 3 是 greenfield、无宿主、element 级产出物已有 R0 mapping 表；宿主合规 / 不合规两形态被场景 2 的「成熟度光谱」（高/中/低 TVU 化）覆盖。故 R7 侧新小节只锚定场景 2。
- **示例行编号归一（见 owner 可推翻点 #2）**：裁定示例中「保存按钮 · 第 3 档」按四档表**行序编号**应为「第 4 档（local 有但旧 + TVU 有新版 → 仍用 local）」，且「✅ 旧样式」归一为四档表原文的「⚠️ 旧」标记；示例仅示意格式，落地文本采用行序编号。

## Global Constraints

- **只动两个文件**：`docs/internal/code-conventions.md` + `skills/tvu-design-code/SKILL.md`。**不动** `mockup-conventions.md` / `design-process.md`（M48）/ `skills/tvu-design-mockup/SKILL.md`——那是并行计划 `2026-08-12-path-a-legacy-host-increment-rule.md` 的 scope（见 §Path A 镜像锚点）。
- **判定表规范文本在本计划 Task 1 Step 2 完整给出**（含表头、示例行、触发条件、US-5 豁免、不触发反例，照 M24 骨架）——执行者只做粘贴 + 行号定位 + 锚点微调，**不自行改写判据措辞**。
- **与 R7 既有文字零冲突**：新增段不得改动四档表本身的任何判据文字。Task 1 Step 1 给四档表加的「档」列是**纯数字新列**——既有单元格逐字不动，执行后用 `git diff` 逐行核：被改的 6 行中每行旧内容必须原样出现在新行内（只在行首多 `| N `／表头多 `| 档 `）。若 owner 复审认为「加列也算动表」→ 降级为方案 B（表不动，档号映射写进新小节），见 owner 可推翻点 #1。
- **不声称有闸**：判定表 enforcement = **L1 + skill 起手 checklist**。新小节内的 Enforcement 声明（Meta-K）必须写「无 pre-commit 闸可挂」，不得出现「audit 拦截」「闸兜底」等措辞。
- **skill 起手协议不打乱编号**：不新增步骤号、不用 x.5 半号——只在既有 **step 6** 的「R7 维度」bullet 文本内追加半句（该 skill 惯例：R7 classify 相关要求全部内聚在 step 6）。
- **提交纪律**：`git commit -F <msg文件> -- <显式路径>`（**-F 在 -- 之前**），提交后**紧跟** `git reset -- <路径>`；msg 文件写在 session scratchpad（不进 repo）。pre-commit 可能 >2min → 后台跑；遇 `index.lock` = 并行 session 在提交，等待重试、**不删锁**。push 后 `git ls-remote` 验 ref 已更新。
- **纯 docs/skill 改动不写 changeset**。执行完毕 `pnpm run audit:rule-load-map` + `pnpm run audit:rule-inventory` + `pnpm run audit:stale-anchors` + `pnpm lint-skills` **全绿**才允许 commit。
- **锚点纪律**：新增文本不得引用尚不存在的 mockup 侧规则 ID（Path A 未落地）——镜像指针只写文字描述 + 既有文件链接，升级为具体 § 指针的动作归 Path A 计划（`audit:stale-anchors` 会拦不存在的 rule-ref）。
- **行号是撰写时基线**（master `4c96c198` 工作树）：Task 1 Step 2 插入约 40 行后，其后所有行号整体下移——执行时**以各步骤给出的引文锚定**，行号仅助定位；引文找不到 = 活源已变，停下重核，不硬套行号。

## 四个设计判断（已定，不留 open question）

1. **落点 = 扩 R7 正文，不开 R7.1**。判定表是 R7 场景 2 disambiguate 动作的**产出物**，不是新的独立判据（同 R0 的 mapping 表长在 R0 正文里）；扩正文让「四档表（判据）→ 判定表（产出物）」在同一个 scoped-load jump 单元内被一次读到。新小节用 `###` 无规则 ID 前缀标题（已核 `scripts/lib/rule-ids.mjs` 的 `RULE_HEADING_RE`：不匹配 → `audit:rule-load-map` / `rule:next` 要号纪律均不触发，零新规则号）。插入点选在「场景 2 视觉真源细化」（四档表所在小节，L460-479）**之后**、「常见子场景」（L481）之前——比 owner 提示的「4 大场景段后」更贴：判据和它的产出物紧邻。
2. **表结构 = 五列保持 owner 形态，不加「涉及帧/文件」列**——证据下沉进单元格：「元素」列带一处需求/落点指针；「宿主有?」「DS 有?」的 ✅ 必附可复核指针（文件/组件名 · code 侧用文件路径，mockup 侧 Path A 换成帧/node 指针）、❌ 必附一句扫描面（治 name-search-absent fallacy：grep 没命中 ≠ 不存在）。「依据」列合法取值 = `第 N 档`（N=四档表档号列 1-4）+ ≤1 句理由；第 3 档必须再附 R0/R1 例外授权 + backlog 登记 ID。**最小触发规模 = 新增/借用/替换 element ≥ 3**；US-5（1-2 element）**豁免表格产出物**（对齐 US-5「跳过所有前置」惯例 + R8 既有「场景 2 小增量 ≤2 elem 豁免」同一条线），四档判断本身照做、只免表。
3. **mockup 侧镜像不在本计划写**——判定表规范全文以 R7 新小节为 SOT，Path A 那条老产品增量新规则**引用**它（把证据指针从文件路径换成 Figma 帧/node id），不复写规范文本（INFRA-F58「一个值只有一处定义，多处引用」）。本计划在 §Path A 镜像锚点写清对方该引用哪段 + 双向指针如何升级。
4. **M48 清单本计划不加行**。实测 M48（`design-process.md` L300-348）作用面是 mockup/设计任务（code 任务不跑 M48，code 侧激活面是 skill step 6 + R7 正文 + 起手 5 步 checklist）；mockup 侧的判定表要求是 Path A 新规则的一部分——M48 Acceptance 的条件 bullet 应与 Path A 规则**同 commit** 落地，否则 M48 出现指向不存在规则的行（读者落空 + stale-anchors 风险）。建议 bullet 文本已写在 §Path A 镜像锚点，供对方直接采用。

## Path A 镜像锚点（供 `2026-08-12-path-a-legacy-host-increment-rule.md` 引用，本计划不执行）

Path A 计划落地 mockup 侧老产品增量规则时，照以下三点接线（避免两份计划重复写同一段）：

1. **规范引用（不复写）**：Path A 规则正文里判定表段落只写——「element 归属判定表的表结构 / 触发条件 / US-5 豁免 / 不触发反例，全文见 [`code-conventions.md`](../../internal/code-conventions.md) R7 §场景 2 起手产出物（SOT）；mockup 侧照用，仅把证据指针从代码文件路径换成 Figma 帧 / node id / catalog entry」。
2. **双向指针升级**：R7 新小节首行的镜像指针（Task 1 Step 2 引文块首行，文字描述形态「Path A 老产品增量规则（并行落地中）」）→ Path A 落地后由 **Path A 的计划**负责升级为具体 §M-id，并在其规则首行加回指 R7 的镜像行（对齐 M35↔R13 mirror-pair 惯例「改此段必同步对面」）。
3. **M48 挂点（随 Path A 规则同 commit）**：建议在 M48 Acceptance 追加条件 bullet——「**场景 2 增量判定表（命中老产品增量时必勾）**：动手前已产出 element 归属判定表（表规范 SOT = code-conventions R7 §场景 2 起手产出物），每行「依据」带档号；US-5 豁免时已显式声明」。

---

### Task 1: R7 正文 —— 四档表加档号列 + 新小节 + Acceptance 追加

**Files:**
- Modify: `docs/internal/code-conventions.md:464-469`（四档表加「档」列）
- Modify: `docs/internal/code-conventions.md:479` 之后（插入新小节，在 L481 `### 常见子场景` 之前）
- Modify: `docs/internal/code-conventions.md:560` 之后（R7 Acceptance criteria 追加一条）

**Interfaces:**
- Consumes: 无（链条起点）
- Produces: R7 §场景 2 起手产出物（判定表规范 SOT）——Task 2 的两处激活指针与 Path A 计划都指向它。

- [ ] **Step 1: 四档表加「档」列（判据文字零改动）**

`docs/internal/code-conventions.md` L464-469，将「场景 2 视觉真源细化」小节内的四档表整块替换为（既有单元格逐字保留，只新增行首数字列）：

```markdown
| 档 | element 状况 | 决策 |
|---|---|---|
| 1 | ✅ local 有 + ✅ TVU 也有 | **优先 local**（避免跨页面割裂） |
| 2 | ❌ local 没 + ✅ TVU 有 | **用 TVU** ← 完全合法且鼓励 |
| 3 | ❌ local 没 + ❌ TVU 没 | **自写候选**（走 R0 / R1 例外，需用户授权 + 登记 backlog） |
| 4 | ⚠️ local 有但旧/不规范 + ✅ TVU 有新版 | **仍用 local**（除非用户显式说"用 TVU 替换"）— pre-design-system 不视为 bug |
```

自检：`git diff -U0 docs/internal/code-conventions.md` 中本表 6 行，每行 `-` 侧内容必须原样包含在对应 `+` 侧行内（仅行首多 `| N ` / `| 档 ` / `|---`）。不满足 = 判据文字被动了，回退重做。

- [ ] **Step 2: 插入新小节（L479「规则统一——不因 TVU 化程度而变。」之后、L481 `### 常见子场景` 之前）**

粘贴以下全文（执行者不改写判据措辞；仅当上下行距 / 空行不合 markdown 惯例时做空行微调）：

````markdown
### 场景 2 起手产出物 — Element 归属判定表（decision trace）

> **↔ Mockup 端镜像**：Path A 老产品增量规则（[`mockup-conventions.md`](./mockup-conventions.md)，2026-08-12 并行落地中；落地后本行升级为具体 § 指针，改此段必同步对面）。

场景 2 的 element 级归属（上方四档表）此前在 AI 脑内判完即动手，判定过程不落地——换 session / 换工具后同一 element 可能落到另一档，事后也无法核「这次到底照哪档判的」。故场景 2 起手 classify 声明行之后、R0 mapping / build 之前，**必须先输出一张 element 归属判定表作为第一产出物**（[CONVENTIONS-OVERVIEW §8](./CONVENTIONS-OVERVIEW.md) 第 3 条 Externalize thinking as trace；同族先例：M24 Code→Token mapping table / M35·R13 3-line affordance trace / M48 起手清单。owner 拍板 2026-08-12。四档表本身就是确定判据——本节不加阈值、不加自动判据，只物化判定过程）。

**触发条件（严格 AND）**：
1. R7 classify 落到**场景 2**（含 Hybrid「场景 2 scope + 场景 1 视觉」中仍需宿主/DS 归属仲裁的 element——纯按源 1:1 还原的 element 不进表）；**且**
2. 本次新增 / 借用 / 替换的 element **≥ 3**（US-5 判定线之上）。

**不触发**（误产表 = 过度套规则）：
- 场景 3 greenfield —— 无宿主可判；element 级产出物已有 R0 mapping 表，别产两张表
- 场景 1 纯视觉还原 —— 落档恒为「按源还原」，表无判定意义
- 场景 4 TVU 规范校正 —— 归属已被用户显式覆写为 TVU
- **US-5 小调整（1-2 element）—— 豁免表格产出物**（对齐 US-5「跳过所有前置」惯例；四档判断本身照做，只免表）
- US-6 audit —— 产 audit report，不动手建

**表结构（5 列固定）**：

| 元素 | 宿主有? | DS 有? | 落档 | 依据 |
|---|---|---|---|---|
| 保存按钮（`SettingsPage.vue`） | ⚠️ 旧样式（`ProfilePage.vue` 同款） | ✅（canonical `Button`） | 宿主 | 第 4 档 · 跨页一致 |
| progress bar（PRD §3.2） | ❌（grep progress/bar/loading 无命中） | ✅（canonical `Progress`） | DS | 第 2 档 · 宿主无可一致对象 |

列规范：
- **元素**：element 名 + 一处需求 / 落点指针（文件、PRD 段等）
- **宿主有?**：`✅ / ⚠️ 旧 / ❌`。✅/⚠️ 必附可复核指针（文件或组件 / composable 名）；❌ 必附一句扫描面（扫了哪些目录 / 关键词）——grep 没命中 ≠ 不存在，❌ 无扫描面不算判过
- **DS 有?**：`✅ / ❌`。✅ 附 canonical 组件名 / `dist/icons/svg/<ns>/…` / token 名；❌ 附扫描面（catalog + icons + tokens）
- **落档**：`宿主 / DS / 自写候选` 三值；与档号必须互洽（第 1 / 4 档 → 宿主，第 2 档 → DS，第 3 档 → 自写候选）
- **依据**：`第 N 档`（N = 上方四档表「档」列）+ ≤1 句理由；**第 3 档必须再附**「已走 R0 / R1 例外授权 + [`backlog.md`](./backlog.md) 登记 ID」

**纪律**：表贴出（对话内；有 handoff 时同步贴入 handoff）后才动手；建造中途新冒出的 element **先追加行再动手**；改判不改旧行——追加新行 + 一句推翻原因（保住「事后可核」）。

**Enforcement 层级（Meta-K）**：**L1 + skill 起手 checklist**（`tvu-design-code` 起手协议 step 6 + 本文件「起手 5 步 checklist」step 1）。表是对话 / handoff 产出物，不是 repo 文件，**无 pre-commit 闸可挂**；走查核验点 = 起手消息含此表 + handoff 内 `grep -E '\|\s*落档\s*\|'` 命中。
````

- [ ] **Step 3: R7 Acceptance criteria 追加一条**

在 L560「- 场景 2 任务中是否**抑制**了……」一行之后插入：

```markdown
- 场景 2 任务（≥3 element）动手前是否产出了 element 归属判定表（§场景 2 起手产出物），每行「依据」带档号且与「落档」互洽？US-5 豁免时是否显式声明了豁免？
```

---

### Task 2: 激活层 —— 速查表 + 起手 5 步 + code skill step 6

> 为什么必须有这层：读取指引里 R7 的 jump 触发条件是「任务意图未明 / 多场景候选时」——场景 2 意图清晰的任务在 scoped-load 下可能不读 R7 全文，激活只能靠 skill step 6 与速查表这两个「所有任务必经面」。

**Files:**
- Modify: `docs/internal/code-conventions.md:594` 之后（适用矩阵加一行）
- Modify: `docs/internal/code-conventions.md:620`（起手 5 步 checklist step 1 追加半句）
- Modify: `skills/tvu-design-code/SKILL.md:67`（step 6 R7 维度 bullet 内追加半句，不加新步骤号）

**Interfaces:**
- Consumes: Task 1 的新小节标题「场景 2 起手产出物」（两处指针的锚定对象）
- Produces: 激活完成态——Task 3 验收它。

- [ ] **Step 1: 适用矩阵加一行**（L594 `| **R7** 意图 disambiguate（起手必判） | ...` 之后插入）：

```markdown
| **R7 §场景 2 起手产出物** element 归属判定表 | ❌ | ✅ ≥3 element 必产（US-5 豁免） | ❌ | ❌ |
```

- [ ] **Step 2: 起手 5 步 checklist step 1 追加**（L620）。原行末尾追加半句，改后整行为：

```markdown
1. **R7 classify**：判场景 1/2/3/4 + 子场景 X.Y → 显式声明 `"intent classified as 场景 X.Y"`；场景 2 且 ≥3 element → 再产 element 归属判定表（§场景 2 起手产出物，US-5 豁免）
```

- [ ] **Step 3: `skills/tvu-design-code/SKILL.md` step 6 R7 维度 bullet 追加**（L67）。在该 bullet 末尾（「…显式声明 "intent classified as 场景 X.Y（子场景）" 一行」之后）追加：

```markdown
；**场景 2 命中且 ≥3 element** → 声明行之后、动手前先产 element 归属判定表（表规范见 code-conventions.md R7 §场景 2 起手产出物；US-5 豁免）
```

自检：`git diff skills/tvu-design-code/SKILL.md` 只有 step 6 一行变化；步骤号 0/1/1.5/2-7 原样。

---

### Task 3: 机械闸全绿 + 提交

**Files:**
- No new files. 验证 + commit Task 1/2 的两个文件。

- [ ] **Step 1: 四闸全绿**

```bash
pnpm run audit:rule-load-map && pnpm run audit:rule-inventory && pnpm run audit:stale-anchors && pnpm lint-skills
```

预期全部 exit 0。若 `audit:stale-anchors` 红在新增文本 → 检查是否误写了不存在的 rule-ref / 链接（Global Constraints 锚点纪律），修正文本本身，**不豁免**。

- [ ] **Step 2: 判据零改动终审**

```bash
git diff -U0 docs/internal/code-conventions.md
```

逐行核：四档表 6 行只有行首档号差异；其余 diff 均为纯新增行（新小节 / Acceptance / 矩阵行 / step 1 半句）。

- [ ] **Step 3: 提交（按 Global Constraints 提交纪律）**

msg 文件（scratchpad）内容：

```
docs(conventions): R7 场景 2 起手产出物 —— element 归属判定表（decision trace）

- 四档表加档号列（判据文字零改动）；场景 2 落档判定物化为起手第一产出物
- 触发 = 场景 2 且 ≥3 element；US-5 豁免；场景 1/3/4/US-6 不触发
- 激活：适用矩阵 + 起手 5 步 step 1 + tvu-design-code skill step 6
- Enforcement = L1 + skill checklist（表为对话/handoff 产物，无 pre-commit 闸可挂）
- mockup 侧镜像由 Path A 计划引用本节 SOT，不复写（owner 拍板 2026-08-12）
```

```bash
git commit -F <scratchpad-msg文件> -- docs/internal/code-conventions.md skills/tvu-design-code/SKILL.md
git reset -- docs/internal/code-conventions.md skills/tvu-design-code/SKILL.md
git push
git ls-remote origin master   # 验 ref 已更新（瞬时 remote-rejected 不作数）
```

---

## Owner 可推翻点

1. **四档表加「档」列 vs 表完全不动**：本计划判「零冲突」指判据文字（纯数字列不触碰任何既有 cell），选加列 = 编号单点、不可漂移。若 owner 认为加列也算动表 → 方案 B：表不动，新小节内加一行档号映射「第 1 档=表第 1 行（✅local+✅TVU）… 第 4 档=表第 4 行（⚠️local 旧）」，代价是表改行序时映射可能漂。
2. **档号顺序 = 四档表行序**（1 两有→local / 2 仅 TVU→TVU / 3 两无→自写候选 / 4 local 旧→仍 local）。owner 裁定示例「保存按钮·第 3 档」按此应为第 4 档——若 owner 坚持示例编号，只改档号列数字与示例行，行序与判据文字仍不动。
3. **触发规模线 ≥3 element**：取自 US-5 上界（1-2 element）+ R8 既有「≤2 elem 豁免」同一条线。owner 可改为「所有非 US-5 的场景 2 任务一律产表」。
4. **M48 不加行**（归 Path A 随 mockup 规则同 commit）：owner 若要本计划现在加，须接受该 bullet 在 Path A 落地前指向「并行落地中」的规则。
5. **「场景 2/3」→ R7 场景 2 的映射**：裁定原文的编号被解读为「宿主合规 / 不合规两形态，均属 R7 场景 2」；若 owner 的 2/3 另有所指（如 Path A 侧场景体系），R7 侧触发条件文字需按其重述。