---
title: INFRA-F58 残余「规则三层化重构」scoping
date: 2026-07-10
backlog: INFRA-F58
status: draft
---

# INFRA-F58 残余「规则三层化重构」— scoping 分析

> 只读分析产出，未改任何源文件。目的：让下个 session 能直接进 `superpowers:writing-plans`，不用重新做发现工作。

## 0. 前置警告（执行前必读）

1. **本 session 期间有并行 session 在动 `mockup-conventions.md` / `design-process.md` / skills**——本报告读到的行号/内容是 2026-07-10 当时的快照。下个 session 开工前必须先 `git log -1 --format=%H -- docs/internal/mockup-conventions.md docs/internal/design-process.md` 核对是否有新 commit，若有需重新核对本报告的行号锚点。
2. **本仓库已有一次相关但更大胆的尝试被 owner 否决**：`docs/internal/rule-registry-design-2026-06-12.md`（"规则注册表 + 任务路由" JSON SoT 方案）在其自身文档里写明 **非目标**"❌ 不搬动/重排规则文件（wholesale reorg 已否——错杠杆、高风险）"，2026-06-12 owner reframe 后 `_plans/2026-06-12-rule-registry-p1.md` 被标记 **SUPERSEDED**，改用「执行优先」路线（`2026-06-12-execution-first-mockup-discipline.md`）。**F58 的 MERGE/SPLIT 范围比那次窄**（局部镜像去重 + 单文件内部段落搬迁，不建新索引层、不做任务路由），但下个 session 起手应显式向 owner 确认："这次是内容级去重，不是被否决的 wholesale reorg / registry" ——避免被当成同一个已否决提案的复活。
3. **`R13`（Affordance-Category Search Discipline）↔ `M35`** 这一对被 `affordance-search` subagent 的描述直接引用（"Forces M35 / R13 search discipline"）。改这两条前必须先确认该 agent 定义文件里有没有写死摘录/行号引用，否则可能静默破坏一个活的 subagent 契约。

---

## 1. code-conv R14-R23 ↔ mockup-conv M31-M43 重叠量化

### 1.1 「R14-R23」是简写，不是连续编号区间

实际镜像对不是连续数字块，而是这 9 对（外加 R13/M35 常被一并提及）：

| Code 侧 | 行号范围（`code-conventions.md`，1397 行）| Mockup 侧 | 行号范围（`mockup-conventions.md`，2572 行）| 行数（R/M）|
|---|---|---|---|---|
| R13 | 1040–1144 | M35 | 1565–1667 | 104 / 102 |
| R14 | 889–924 | M31 | 1366–1400 | 35 / 34 |
| R15 | 924–976 | M32(+32.1-32.3) | 1416–1535 | 52 / 119 |
| R16 | 976–1040 | M33 | 1535–1565 | 64 / 30 |
| R17 | 1144–1165 | M36(+36.1) | 1667–1743 | 21 / 76 |
| R18 | 1165–1196 | M37 | 1743–1771 | 31 / 28 |
| R19 | 1196–1228 | M38 | 1771–1817 | 32 / 46 |
| R23 | 1228–1337 | M43(+43.2) | 2045–2194 | 109 / 149 |
| R-DISCIPLINE | 1337–1397 | M-DISCIPLINE(+SYNC) | 2389–2459 | 60 / 70 |
| **合计** | | | | **508 / 654 = 1162 行** |

`R20`/`R21`/`R22` **不存在**（编号缺口，非本次删除所致——历史遗留，需在执行前确认是否早年被合并/废弃，不是本次分析的产物）。

- R 侧镜像内容占 `code-conventions.md` 全文 **36%**（508/1397）
- M 侧镜像内容占 `mockup-conventions.md` 全文 **25%**（654/2572）

### 1.2 逐对实读结论——不是均质可 MERGE

实际读取 R14/M31、R15/M32、R16/M33、R19/M38、R23/M43、R-DISCIPLINE/M-DISCIPLINE 全文后：

- **真重复（可安全合并的部分）**：开场 1-2 句 rationale、"为什么"段、"与既有规则关系"交叉引用样板、"实证"段的历史事件复述。这部分**逐字或近逐字重复**，是真正的 MERGE 收益来源。
- **假重复（表面同构，内容不可合并）**：决策树表格（CSS `flex/grid` vs Figma `Auto Layout/Slot/Boolean/Absolute`）、反例表、Acceptance 清单、脚本/probe 命令——两侧工具不同，机制本来就该分开写（[[feedback_audit-whitelist-vs-sot-refactor]] 警惕的"为凑精简改 SoT"正是这类）。R15/M32 尤其：M32 有 M32.1-M32.3 三个纯 Figma 机制子条（key 三连验、自建三件套、`includeLibraryKeys` 装配锁），**code 侧完全没有对应物**，不是"该合并没合并"，是天生不对称。R23/M43 同理：R23 有大段 JS truncation-detection / center-ellipsis 代码，M43 是 Figma 侧 wrap-vs-ellipsis 决策，机制不重叠。
- **已经 drift、不是简单镜像的一对（重要发现）**：**R19 与 M38 内容已不同步**。M38 在 2026-05-26 扩展为"3 层信号"（rail + fill + **selection-driven action chrome**），且 M38 正文里已经写好了 code 端应该怎么用 `[data-selected="true"] .row-actions { display:flex }` 实现第 3 层；但 **R19 正文本身仍只讲 2 层**（border-left + background），完全没提 chrome 层。→ MERGE 前必须先把 R19 补齐第 3 层，否则合并会把"已经修过的规则"合并出一个不完整版本。这不是"去重"，是先修 bug 再去重。

### 1.3 预计省行数（对 backlog 估计的修正）

backlog 记的"省~500-700行"是 3-subagent review 的估计，**基于本次逐对实读，建议下调**：

- 真正可无损合并的是"框架性重复"（开场句/why/交叉引用样板/实证复述），逐对采样占比大约 **15-25%**，不是全部 1162 行。
- 保守估计合并后净省 **150-300 行**（且要扣掉合并后新增的指针/交叉引用行），而不是 500-700 行。
- 500-700 的估计如果是把"两侧总行数"当成"可省行数"直接算，会系统性高估——两侧机制表格本来就不该合并。**下个 session 写 plan 时不要直接照搬 500-700 这个数字**，按 pair 逐一算完再定 acceptance 里的目标行数。

---

## 2. meta-rules / design-process / AGENTS 各自 SPLIT 边界

### 2.1 meta-rules.md（823 行）

- §6 触发器 A-Q 占 174-793 行 = **620 行 = 75% 的文件**。
- 文件**已经有**一个专门的实证档案区："## 附录：本规则的实证沉淀"（802-823，22 行，每行一条紧凑案例）——SPLIT 的落点已存在，不用新建文件。
- 各触发器内联的"#### 实证"/"实证案例"子段（触发器 N 655-658、触发器 O 695-701、触发器 P 758-763、触发器 Q 788-793，§5 案例 166-178）合计约 **35-45 行**——这是应该搬进附录的部分。
- **SPLIT 边界**：可移植契约 = 触发条件 + 应对 + 反模式 + Acceptance（AI 执行时必须读的"现在怎么做"）；实证档案 = 具体某次事故的复述（"当年为什么定这条"，读一次就够，不需要每次任务都重新加载）。
- **量化**：这个 SPLIT 大约只搬 35-45 行到既有附录，**不是大杠杆**，主要价值是 scoped-load 意义上的（触发器正文变薄，AI 执行时不用扫描历史案例段）。

### 2.2 design-process.md（1413 行）

- backlog 提到的"六段式"在仓库里**没有被显式定义过**（`grep 六段式` 只命中 backlog.md 自己）——这是审阅时观察到的隐含结构，不是既有命名规范，下个 session 写 plan 时应先把这个结构显式定义一次（六段大概是：定义/触发条件/正文条款/反例/Acceptance/实证），否则"SPLIT 六段式"这个任务名没有可执行的验收标准。
- 抽样最大的 M-rule 段 M49（Design Quality Contract Gate，288-441，153 行）：实证段（432-437）只有 **6 行**，占该段 4%。其余 M22/M48/M50/M51/M-PRD-EG/M-CARDINALITY/M-IA-FIRST/M-LIFECYCLE-CRUD 合计约 300 行的 M-rule 区块，同类"实证"占比预期同量级（个位数百分比）。
- **结论**：design-process.md 的"实证"内容占比远低于假设，SPLIT 收益同样是**几十行级**，不是几百行级。真正占篇幅的是 Stage 0-8 流程叙述本身（约 900 行），那部分是流程说明文档，不属于本次"规则三层化"讨论范围（不是 R/M 式的 rule contract，是 process narrative）。
- design-process.md 是 `audit-stale-anchors.mjs` 的 **DEF_FILES**（被 code-conv/mockup-conv/meta-rules 的链接指向此文件时会被校验），但**不是 SCAN_FILES**（它自己发出的链接不被扫描）——SPLIT 挪动它内部标题时，必须靠人工/单独跑一次全仓 grep 确认它自己指出去的链接没断（现有 audit 不覆盖这个方向）。

### 2.3 AGENTS.md Team Comms（640-740，约 100 行 / 747 行全文 = 13%）

- 这段（Slack mrkdwn 规则 + Jira ADF 评论规则）**内容自成一体，不依赖 AGENTS.md 其余部分**，是最干净的 SPLIT 候选——抽到独立文件（如 `docs/internal/team-comms-conventions.md`），AGENTS.md 留 5-10 行指针 + acceptance 摘要。
- 全仓 grep 未发现任何文件用 markdown 链接引用 `AGENTS.md#team-comms...` 锚点——外部引用风险低（但执行时需重新 grep 一次，防止这份报告之后又有新引用加入）。
- **注意**：AGENTS.md **既不在** `audit-stale-anchors.mjs` 的 SCAN_FILES 也不在 DEF_FILES 里——挪动这段完全**没有现成机检兜底**，全靠人工 grep + review。
- 这个 SPLIT 的价值不是省行数（挪走 100 行 + 加万一 10 行指针，全仓净变化几乎为零），是让 AGENTS.md（起手必读文件）变薄，减轻 onboarding 负担。

---

## 3. 风险清单

1. **R19/M38 已 drift**——见 §1.2，MERGE 前必须先修复 R19 缺失的 chrome 层，否则会把过期内容当"权威版本"合并。
2. **有意的工具分工冗余不能合并**——R15/M32、R23/M43 的机制表格类内容是天生不对称（Figma-only 三连验/装配锁 vs code-only JS truncation），MERGE 只能动框架句，不能动机制表。误判会导致删掉某侧独有的必要规则（呼应 memory `feedback_audit-whitelist-vs-sot-refactor`）。
3. **scoped-load 路由表 / stale-anchors 锚点**：
   - `code-conventions.md` / `mockup-conventions.md` / `meta-rules.md` 三个都在 `audit-stale-anchors.mjs` 的 SCAN_FILES 里——任何标题改名/段落搬移**必须**跑 `pnpm run audit:stale-anchors`（已挂在 `prepublishOnly`，但开发期最好单独跑，别等发布才发现）。
   - `design-process.md` 是 DEF_FILES 但非 SCAN_FILES——它自己发出的链接没有机检覆盖，SPLIT 时人工 grep 补位。
   - `AGENTS.md` 两个列表都不在——Team Comms 抽取全靠人工核查。
4. **R13/M35 被 `affordance-search` subagent 引用**——改动前先读该 agent 定义文件，避免破坏一个依赖具体规则文字的活契约。
5. **与已否决的 rule-registry 方案边界模糊**——见 §0.2，执行前需 owner 显式确认这次是"内容去重"不是"重排/建索引层"。
6. **并行 session 正在改 mockup-conventions.md / design-process.md**——本报告的行号是快照，执行前必须重新核对（见 §0.1）。
7. **backlog 的 500-700 行估计偏高**——照抄这个数字定 acceptance 会导致过度合并（把工具特定机制也硬并）以凑数字，应按逐对实读结果定更保守的目标（见 §1.3）。

---

## 4. Task 拆分骨架（供下个 session 进 `writing-plans`）

| # | Task | 动哪些文件 | 验证方式 | 需要 SDD？ |
|---|---|---|---|---|
| 0 | Preflight：核对并行 session 是否已改动 mockup-conventions.md / design-process.md；向 owner 确认本次范围 ≠ 已否决的 rule-registry wholesale reorg | 无（只读 + 对话确认）| `git log` diff 核对 | 否 |
| 1 | 逐对 reconciliation audit：对 9 对镜像（R13/M35 … R-DISCIPLINE/M-DISCIPLINE）产出 drift 判定表（同步/已 drift/天生不对称三类）；**修复 R19 缺失的第 3 层 chrome 内容**（先修 bug 再谈合并） | `code-conventions.md`（R19 内容补全） | 人工 reread + `pnpm run audit:stale-anchors`（预期无影响，纯内容编辑） | 否（内容修复，单文件小改） |
| 2 | Class A pairs MERGE（真重复占比高的）：R14/M31、R16/M33、R17/M36、R18/M37、R-DISCIPLINE/M-DISCIPLINE——收窄开场句/why/交叉引用样板为单一权威表述 + 指针，机制表格两侧各留 | `code-conventions.md` + `mockup-conventions.md` | `pnpm run audit:stale-anchors` + `pnpm run audit:doc-sync`（如适用）+ owner 内容 reread | **是**（跨两个 SCAN_FILES 协同编辑，锚点风险） |
| 3 | Class C pairs 轻量整理（天生不对称，只删框架性重复句，机制表格原样保留）：R15/M32、R23/M43 | 同上两文件 | 同上 | 是（同风险等级，虽然改动量更小） |
| 4 | R13/M35 专项处理——先读 `affordance-search` agent 定义确认无硬编码摘录/行号依赖，再决定 MERGE 范围 | `code-conventions.md` + `mockup-conventions.md` + 核查 agent 定义文件（不改） | 同上 + 手动跑一次 affordance-search 场景验证 agent 未受影响 | 是 |
| 5 | meta-rules.md SPLIT：触发器 N/O/P/Q + §5 的内联"实证"子段（约 35-45 行）迁移进既有"## 附录：本规则的实证沉淀"表，原位置留一行指针 | `docs/meta-rules.md`（单文件）| `pnpm run audit:stale-anchors` | 否（单文件、低风险，可 executor 直接做） |
| 6 | design-process.md SPLIT：先显式定义"六段式"结构（定义/触发/正文/反例/Acceptance/实证），再迁移各 M-rule 的实证子段到统一档案区（新增 "## 附录：M-rule 实证沉淀" 或复用同一模式） | `docs/internal/design-process.md` | `pnpm run audit:stale-anchors`（DEF_FILES 侧）+ 人工 grep 确认 design-process.md 自身出站链接未断 | 是（design-process.md 当前有并行 session 在动，冲突风险最高，务必最后排且先确认 §0.1） |
| 7 | AGENTS.md Team Comms 拆出：640-740 行迁至新文件 `docs/internal/team-comms-conventions.md`，AGENTS.md 留指针 + acceptance 摘要 | `AGENTS.md`（编辑）+ 新文件 | 全仓 grep `AGENTS.md#team-comms` 类锚点引用（当前 0 命中，需在执行时重新确认）+ 人工 reread | 否（自成一体，低风险，可 executor 直接做） |
| 8 | 收尾：全量重跑 `audit:stale-anchors` / `audit:doc-sync` / `audit:doc-de-mirror`；owner 逐文件 spot-check；`backlog.md` 移除本条已完成部分；如满足 meta-rules 触发器 D 阈值（≥3 个真源 .md 改）→ 写复盘 | `docs/internal/backlog.md` + 新 retrospection 文件 | 三个 audit 全绿 + owner ack | 否 |

**排序建议**：0→1（先修 drift，别在过期内容上做合并）→2/3/4（MERGE 主体，可并行但共享同两个文件、避免同时改会冲突，建议串行）→5/7（低风险单文件 SPLIT，可插空并行做）→6（design-process.md，风险最高，排最后且先重新确认 §0.1 前提）→8（收尾）。

---

## 附：与 backlog.md 原文的对应

本报告对应 `docs/internal/backlog.md` §INFRA-F58 "残余精简 worklist" 中：

> 归 [[INFRA-F55]] 支柱① 规则三层化重构（review M1/S1-S3，最高精简杠杆，需专门 plan）：code-conv R14-R23 ↔ mockup-conv M31-M43 镜像 MERGE（省~500-700行）· meta-rules(820) SPLIT 可移植契约+实证档案 · design-process 六段式 SPLIT 正文/档案 · AGENTS §640-738 Team Comms 拆出。

结论：这条不是"最高精简杠杆"——逐对实读后，真正可无损省下的行数（150-300，MERGE 为主）明显低于 backlog 估计的 500-700，且 SPLIT 两项（meta-rules / design-process）本质是 scoped-load 清晰度改善而非行数杠杆。建议下个 session 写 plan 时把这条的"预期收益"表述下修，避免为了凑行数目标而误伤工具特定的必要内容。