# 处方：retrospection 归档提炼成 ADR + 分批删除（S3）

- 日期：2026-08-24 · 对应 spec §11.2 / §11.4 · 第二轮第 8 步
- 出处：[`reports/2026-08-24-retrospection-s2-s3.md`](../reports/2026-08-24-retrospection-s2-s3.md)
- pin：`71ac2711` · 裁判来源：S1/claims/verify 三个器（零 AI）+ S2 裁决（**单裁判 AI**，见 §6 边界）
- 完整逐条数据：`subjects/tvu-ds/inventory/retrospection-s2-verdicts-71ac2711.json`（106 条提炼、108 条证据定位）
- **执行状态**：🟢 **已由 DS 落地** —— 亲验 pin **`7fcca917`**（2026-09-01，`lab:N93`）。`docs/_archive/retrospection/` **53 → 18 份**（删掉的 35 正是「35 份进 S2 判定」那批，逐字对上）；提炼产物 [`docs/internal/archive-extracted-adr.md`](../../tvu-design-system/docs/internal/archive-extracted-adr.md) 存在（183 行），其 `:4-5` 逐字自陈「**提炼与删除在同一个 commit 里**，依据是本仓归档规则「提炼完原件才可删」（ai-ds-lab spec §11.2）」⇒ **本处方 §1「不可换序」的 extract-then-delete 顺序守住了**。⚠️ **口径差、⛔ lab 未复核**：DS 实提 **66 条**（A–I 组 63 + J 组 3），⛔ 不是本处方 §2 的 106 条；DS 自己在该文件 `:82-83` 登记「处方 §2 的 106 条**不是穷尽的**，提炼这件事本身也有 recall 缺口」。⇒ **66/106 是 DS 的取舍判断，lab ⛔ 没有逐条复核哪 40 条被判为不必提炼** —— ⛔ 不得把本行读成「提炼完整性已验证」。另 §2.4 那批（自称「必记入册」→ 建议落 `AGENTS.md`）在提炼产物 `:74` 被标「**不在本文件**」，⛔ 其去向 lab 本轮未追
- **执行状态重取**：@`d07be8e9`（2026-09-11 §30 全量重取，量具 `metrics/proposal-execution-status-refresh.mjs`）—— 锚 1/1 仍成立（`docs/internal/archive-extracted-adr.md`） ⇒ **结论不变**。

---

## 0. 一句话

`docs/_archive/retrospection` **53 份 / 7,524 行**：18 份是现行资产（有入站引用），
35 份进 S2 判定 ⇒ **32 份要先提炼再删、2 份可直接删、1 份交 owner**。
提炼出 **106 条**结论候选，其中相当一部分**从未进过任何现行文档**（§2.4 那批自称「必记入册」的尤其突出）。

⛔ **前置**：先落 [`stale-anchors-codespan-gap.md`](2026-08-24-stale-anchors-codespan-gap.md)，
再动任何删除。理由：实测 §11.4 安全网第 1 层对归档删除**近乎无覆盖**（删 34 份、闸读数一字未变），
不补闸就删，等于没有安全网还以为有。

---

## 1. 执行顺序（不可换序）

```
① 落 stale-anchors 补漏处方 + 造故障验收
        ↓
② lab 重跑全量演练：期望闸**由绿转红**；红的那几份必须与 lab path 口径的「有入站」逐条对上
        ↓  （对不上 ⇒ 两边至少一个错，停下查，不放行）
③ 提炼：按 §2 把 ADR 写进现行文档（这一步不删任何东西）
        ↓
④ 逐批删原件，每批后跑 audit:stale-anchors + audit:plan-lifecycle（见 §4 批次与同批约束）
        ↓
⑤ 每批把实测 exit code + 孤儿清单原文回报 lab
```

**为什么提炼必须早于删除**：§11.2 逐字「**提炼完原件才可删**」。本轮 32 份是
`extract-then-delete`，不是 `delete` —— 顺序颠倒就是丢结论。

---

## 2. 要提炼什么（按主题归并，106 条的完整逐条清单在 JSON 里）

> 每组末尾标出处文件与行号，便于逐条回溯原文。
> 建议落点是 lab 的建议，**owner 可改**；但「必须有落点」不可省——没落点就等于没提炼。

### 2.0 ⚠️ 勘误 E34：106 条**不穷尽**，且原来没写扫描面（2026-08-25 补）

原标题里的「**完整**逐条清单」指的是「这 106 条的清单是完整的」，
**不是**「DS 的复盘结论已被穷尽提炼」。DS 指出这点是对的。lab 复核后把口径与扫描面补齐如下
（AGENTS §2.4：**凡引用一个分母，必须带口径名；扫描面本身也要写进报告**）：

**106 条的口径 = 「`docs/_archive/retrospection` 中经 S2 裁定的 35 份 / 4,665 行」**，⛔ 不是「DS 全部复盘文档」。

| 面 | 份 | 行 | 是否已提炼 |
|---|---:|---:|---|
| `docs/_archive/retrospection` · S2 裁定（`superseded-weak` 7 + `residual` 28） | **35** | **4,665** | ✅ 106 条出自这里 |
| `docs/_archive/retrospection` · S1 判为 `live-source`（仍有外部入站，不在删除范围） | 18 | 2,859 | ⛔ **未提炼** |
| `docs/internal/retrospection`（**现行面**，非归档） | 22 | 2,246 | ⛔ **未提炼**（= 已登记的 N8） |
| **合计未提炼** | **40** | **5,105** | — |

⇒ **提炼覆盖率 = 4,665 / 9,770 = 47.7%（行口径，分母 = 归档 retrospection 7,524 行 + 现行 retrospection 2,246 行）。**
   也就是说**过半的复盘语料从未被提炼过**，「106 条」远不是上界。

**这条改变什么、不改变什么**：
- ⛔ **不改变本处方的删除范围** —— 未提炼的那 40 份本来就不在删除清单上（`live-source` 有入站不删；
  `docs/internal/retrospection` 是现行面，压根不在本处方范围内）。⇒ **DS 可照常执行，不必为此停手。**
- ✅ **改变的是「提炼完了」这个声明的效力**：删完这批 ≠ DS 的复盘知识已被收敛。
  §5 的验收判据里不得出现「106 条已穷尽提炼」这类措辞。
- ✅ **新增一条后续项**：现行面 `docs/internal/retrospection` 22 份 / 2,246 行需要单独排期
  （它不是归档，不适用三分法，得另立处方）。

⚠️ **一处对不上号，需 DS 确认**：DS 给这条勘误的依据写的是「E9 是实证」，
但 lab 勘误表里的 **E9 是 spec §14 把噪声地板排在第一轮第 6 步的排序错误**，与提炼穷尽性无关。
⇒ lab 按**实质主张**（106 条不穷尽）独立复核并采纳了，但**没能对上 DS 那个编号**。
请 DS 确认引用的是哪一份文档的 E9；若指的是 DS 侧自己的勘误编号，请补一句出处，lab 好归档。

### 2.1 判据与测量有效性 → 建议落 `docs/working-principles.md` 或 `meta-rules.md`

| # | 结论 | 出处 |
|---|---|---|
| A1 | **口径纪律**：审计余量（A 数）是相对「当前覆盖的 manifest」的，不是绝对健康度。覆盖面 backfill 会重置分母 ⇒ 跨段数字不可续接，必须重取 baseline 而非估值 | `2026-06-02-wave1a…:25` |
| A2 | **「量错元素」既虚高也掩盖真 drift**：错误测量点上两边巧合相等 ⇒ 假 PASS。retarget 到正确元素会同时清幻影 + 暴露真问题；数字只在拓扑对了之后才双向可信 | `2026-06-03-infra-f39…:70` |
| A3 | **判据/报告 bug 的三层核对**：`normalized JSON → audit JSON → markdown report`。⛔ 不要只看报告 grep 结果——「报告为空 / 轴消失」多半是渲染层或验证命令自身的问题（起止 pattern 相同让 awk 立即结束、`-A1` 只抓到空行），数据其实在 | `2026-04-29-meta-rules…:196` |
| A4 | **「文件存在」不能算验证通过**：任何 `✅ xxx-match-via-*` 都必须有真实 evidence（CSS 值 / prop 枚举 / 变量链），否则是假阳性 | 同上 `:191` |
| A5 | 修判据时**论证单调性**：只可能把 fail 变 pass、不可能反向的修复是安全的，可免全量回归 | `2026-06-02-wave1a…:16` |
| A6 | **fixture drift 是 silent failure**：写死 runtime 渲染文本的断言，数据漂移时不编译错也不运行错，只在跑测时报错 | `2026-05-13-vitest…:36` |
| A7 | **source-grep 测试测错了层**：断言源码里有某字面字符串，在页面重构成运行时渲染后必然失效；rendered-text 检查应走 mount-based 测试 | 同上 `:44`（见 JSON） |
| A8 | **分诊标准动作**：怀疑某改动引入回归时，`git stash -u && 跑测 ; git stash pop` 数秒给出确凿答案，先做它再诊断 | 同上 `:48` |

> A1/A2 与 lab 独立得出的 N19 / E3 / N10 是同一件事 —— 见报告 §5.1「归档里躺着的，是 lab 后来自己重新推导的方法论」。

### 2.2 规则的执行力（rule-hit / discoverability）→ 建议落 `meta-rules.md`

| # | 结论 | 出处 |
|---|---|---|
| B1 | **L1 文本规则 = 提示，L3 hook = 触发**。客观可测的关键流程必须升 L3，文本规则不可替代机械触发 | `2026-05-13-onboarding-gate…:76` |
| B2 | **文本提及 ≠ checklist 显式步骤**。文档顶部提过某个 SoT，不等于它进了起手必读的编号清单——前者会漏，后者才会执行 | 同上 `:80` |
| B3 | **写下一条规则的下一秒就违反了它**。这不是认知问题而是 execution discipline 问题——规则不会自动 enforce 自己；「规则放进 conventions 文档」≠「规则会被执行」 | `2026-05-09-microapps…:149`、`:92`、`:155` |
| B4 | **规则不能假设「机制 = 行为」**：机制存在（如 import 复用）不等于行为自动发生；规则要约束行为。⛔ 也不能因为「看似不会发生」就省略镜像规则 | `2026-05-11-m21-r6…:109` |
| B5 | discoverability 一手证据：`canonical-011-prompt-gap` 自陈「应 grep 历史复盘看教训」这件事**不在任何协议里**——结论写下了但起手不会被读到 | `2026-05-13-canonical-011…:58` |

### 2.3 写规则的方法论 → 建议落 `meta-rules.md` §反模式清单 附近

| # | 结论 | 出处 |
|---|---|---|
| C1 | **写规则当下就在当前任务上 self-test**：新规则的首要验收标准是它能指导手头这个决策。在自己任务里都用不上 = 规则错或用得不到位 | `2026-05-11-m21-r6…:108` |
| C2 | **scope 显式标注**：把适用时序差（greenfield vs incremental）写进规则正文，避免后续误判适用范围 | 同上 `:110` |
| C3 | **规则之间必须 cross-reference** + 优先级表写明谁 override 谁；一次错误可同时踩多条规则的盲点，单条补强不够 | `2026-05-11-trifecta…:80`、`:72` |
| C4 | **反增生**：同一类偏差用一张 generic 维度检查表覆盖，而不是为每个新 case 追加一条规则 | `2026-05-12-evolution-step-1:22` |
| C5 | 规则措辞不应隐含「逐个 override 默认值」——那违反举一反三，也让 instance 失去 library 同步价值；写「必须评估」而非「必须改」 | 同上 `:21` |
| C6 | **合并规则时保留 sub-number**（M11.1/.2/.3）而非删号，让历史 cross-reference 仍可解析 | `2026-05-12-evolution-step-2:22` |
| C7 | 规则措辞 **path-neutral 化**（「生成 deliverable / 采用 source 组件」），使同一条规则跨 Figma 与 code 两面适用 | `2026-05-12-evolution-step-3:29` |

### 2.4 ⚠️ 自称「必记入册」但实测**未入册**的行为约束 → 建议落 `AGENTS.md §plan owner 角色行为约束`

实测该节现有 **9 条**，**不含**下面任何一条；`by-design` 在全仓非归档面 grep **零命中**。
⇒ 这组是本批提炼价值最高的，删原件就是丢掉它们。

| # | 结论 | 出处 |
|---|---|---|
| D1 | **不替真源编设计理由**：不下「by-design / 设计意图」判断。只报告「引用了哪个 token、token 值多少、真源同值」，由 owner 决定真源是否要改 | `2026-05-08-phase-x4-2…:160`（原 #16） |
| D2 | 报「视觉与真源不一致」前，**必先 grep 真源 token 值（两个 mode）对照实现侧定义**——一致则是真源本身如此，不是实现漂移 | 同上 `:165`（原 #17） |
| D3 | **「不入本次 commit」≠「从工作区删除」**：前者是 commit scope 控制（选择性 `git add`），后者是文件生命周期管理。⛔ 不允许用 `rm` / 卸依赖去达成「不入 commit」 | 同上 `:106`（原 #18） |
| D4 | **跨 session 任务必须在 repo 留锚点**（最低一条 backlog entry）——对话里的计划新 session 看不到 | 同上 `:175`（原 #19） |
| D5 | **destructive 操作（git checkout / reset / clean）前必须先报告并等授权**；且每次重新 `git diff` 独立判断，不复用上一次的诊断结论（**anchoring bias** 曾直接 revert 掉 38 个路径的真实工作） | `2026-05-07-phase-a4…:242`、`2026-05-06-t2-sample…:370` |
| D6 | **commit 前必须对每个未 staged 的 M 文件 `git diff` 看内容并显式分类**（进本 commit / 噪音 / 属另一任务 / 越权改动）。⛔ 不允许「忽略 M 文件直接 commit」 | `2026-05-06-t2-sample…:399` |
| D7 | **反藏匿条款**：executor prompt 必须要求「完成报告列出**全部**改动文件（含增删改），即使不在 prompt 显式范围内」，并与「按任务的改动」分开列 | 同上 `:418` |
| D8 | **算法类 fix 的 spec 必须枚举所有匹配形态**（alias / 显式登记 / identity），只写 happy path 会让 executor 漏分支，而单个样本可能恰好蒙混过关 | `2026-05-07-phase-a4…:151` |
| D9 | **sample-first 是发现机制完整性的工具**，不只是降风险：第 1 个样本暴露契约缺口，第 2 个样本的**准备阶段**才暴露上一个 fix 不完整 ⇒ 复杂批量任务必须 sample-first | 同上 `:168` |
| D10 | **架构兼容性必须在 prompt 设计阶段 verify**，不能让 executor 跑完才发现——「通用 grid 渲染模型」与「必须 slot 真组件」是冲突约束，命名上看不出来 | `2026-05-09-f23…:51` |
| D11 | plan owner 直改代码的 **pragmatic exception 边界**：trivial（<5 行）+ 已读上下文 + 立刻 verify 可直改；10+ 行仍走 executor。边界不应频繁突破 | `2026-05-14-v030…:152` |

### 2.5 完成声明与证据（与 AGENTS §4 同源）→ 建议落 `AGENTS.md` / `WRAP-UP.md`

| # | 结论 | 出处 |
|---|---|---|
| E1 | **「核磁盘实物别信摘要」**：subagent 摘要未提的越权改动，靠核 git log 才抓出 ⇒ 完成声明必须用磁盘/git 实物复核 | `2026-06-30-dual-framework…:63` |
| E2 | **中间步骤成功 ≠ 链路成功**。任何流程都要显式写出 final artifact 是什么，并有一步专门 verify 它——tag pushed / CI green / CLI exit 0 都只是 means | `2026-05-11-package-rename…:152`、`:7` |
| E3 | **脚本返回无报错 ≠ 结果正确**：批量写操作先单例验证再批量，批量后立刻查计数核对实物（本次「运行成功」的脚本写错了页面，产生 44 个重复 frame） | `2026-06-01-source-type…:85`、`:83` |
| E4 | **pickup / handoff 里写的「修法」若未被 gate 实证，一律当假设**：本次 pickup 的 `shadowRoot:false` 修法实测更糟（1 A → 134 A），spike 后才找到正解 | `2026-06-30-dual-framework…:106` |
| E5 | **review 的根因判断也要 probe 再信**：review 说「transition race」方向对但**位置**判错 ⇒ 凡另行定位读 computed style 的节点都要先 disable transition，不止 root。false-PASS 与 false-FAIL 同源于此 | 同上 `:125` |
| E6 | **「我 grep 没找到」≠「不存在」**：下结论前必须覆盖全仓库（`tests/` + `scripts/` + `.husky/` + config，不止 markdown） | `2026-05-14-v040…:75` |
| E7 | 协议盲点是正常的，关键是暴露时**显式 patch 到机制层**，且**不 retrofit 历史叙事**掩盖错判——错判要留作 baseline 实证 | `2026-05-11-package-rename…` §5 |
| E8 | 错判会沿「上游文档这么写所以是真的」**链式信任**传播（曾跨 STATUS / 复盘 / pickup / CHANGELOG 四处放大，持续 1–2 周）⇒ 派生文档不能作为事实来源 | 同上 |

### 2.6 实验设计（与 lab §6.2 MDE 同形）→ 建议落 `meta-rules.md` 或新建 `docs/internal/experiment-protocol.md`

| # | 结论 | 出处 |
|---|---|---|
| F1 | **baseline 接近天花板 ⇒ 实验没有区分度**，加难度不如换测量路径（本次白跑 2 轮才发现 A 路径自己就 8/8） | `2026-05-27-bridge-mockup-007…:128` |
| F2 | **双消费者的 SoT 必须两边都测**：「只跑一边等于只测一半」——code 侧无增益不代表 mockup 侧无增益（实测差 44pp） | 同上 `:131` |
| F3 | **扩量前先做小样对照**：不直接做 N× scope expansion，先花半小时跑 5–10 case 的 A/B，Δ 超阈值才扩量 | `2026-05-28-bridge-mockup-008…:93` |
| F4 | 当 AI 自由检索优于 SoT 时，根因通常是 SoT 的 **scope 洞**而非 schema 坏——结论应是扩 scope | `2026-05-27…:134` |
| F5 | **baseline 实跑先于定路径**：backlog 的工作量估值必须标「估（假设）」vs「已验证」；真相与假设差 >2x 时 STOP 重新 propose，不要 fight 走完原路径 | `2026-05-11-bridge-mockup-004…:10`、`:71` |
| F6 | 估时栏标「**实跑前不信**」，下一轮重估用上一轮实跑数据（本项目实测 4–8x 乐观偏差） | `2026-05-14-v030…:114` |

### 2.7 上下文经济学 / portability（lab §7.2、§12.3）→ 建议落 `docs/PROJECT_GOAL.md` 或 `working-principles.md`

| # | 结论 | 出处 |
|---|---|---|
| G1 | **「变薄」的实现取舍**：不删规则正文，而是在顶部加必读链路入口表——理由是删除会打断历史 AI 依赖这些文件的 onboarding 路径。⚠️ 这条也是 `_archive` 只进不出的同源病灶，与 §11.3 出口规则并读 | `2026-05-12-evolution-step-3:28` |
| G2 | **早期 cold-start 观测**：新 session 只读 `design-process.md` + `domain-tvu.md`（约 16 条规则）即可覆盖约 **80%** 决策路径——可作 §12.3 cold-start 维度的历史锚点 | 同上 `:37` |
| G3 | **portability 表述**：多 AI 工具在同一项目协作不互相破坏，关键是把规则「硬」在仓库里，而不是「软」在某个 AI 的 prompt 历史里 | `2026-05-11-v0-1-publish-flow:216` |
| G4 | **portability 兜底**：hook 只在单一 harness 生效，跨工具靠 L1 文本 + 项目契约文档兜底 ⇒ 机械触发与中立表达要**同时**存在，不能二选一 | `2026-05-13-onboarding-gate…:77` |
| G5 | **角色化而非工具化**：规则用 plan owner / executor 等角色表述，切换工具不需改任何规则文件——这是可移植性最早一次成文 | `2026-04-29-meta-rules…` §5 |
| G6 | 把散落在各份复盘「待办」段的问题集中成一份项目级 backlog 真源——散落待办跨 session 检索成本高、易忘、无统一入口 | `2026-05-06-t2-sample…:110` |

### 2.8 具体技术约束（动手前必知，丢了会返工）→ 建议落 `figma-technical-reference.md` / `working-principles.md`

| # | 结论 | 出处 |
|---|---|---|
| H1 | **`audit:tokenized-diff` 断言 raw 与去 token 后的 tokenized 结构恒等**，tokenize 只能新增 token 字段 ⇒ 任何「把某字段置 null」的修法不能落在 normalize 层，只能落在 verifier 层 | `2026-06-03-infra-f39…:24` |
| H2 | **共享组件不得 emit no-op inline style**：`color: currentColor` 语义等于 inherit，但作为 inline style 具最高 specificity，会屏蔽所有外部 class 的 color 规则 ⇒ prop 未显式设置时不要 emit（⚠️ 自陈要写进 `working-principles.md`，实测未写） | `2026-05-07-phase-a4…:145` |
| H3 | **Vue 3.5 在 light-DOM 自定义元素模式下明确拒绝注入编译后 styles（只 warn）** ⇒ `shadowRoot:false` 必须配手动把 styles 注入 `document.head`；样式在 base 组件时还需额外声明样式来源 | `2026-06-30-dual-framework…:104` |
| H4 | **loader-shard 模式**：拆大 JSON SoT 成目录时，唯一知道磁盘形状的地方是一个共享 loader，把目录重组回旧的合并形状使消费方零语义改动；写操作必须幂等（`write(load())` byte-identical）；拆分键必须选**全值字段**，否则产生孤儿桶 | `2026-06-01-affordance-sot-shard…:16`、`:24` |
| H5 | **并行 session 认知纠正**：同机同目录的并行 session **共享同一个工作树**，不存在「留给那个 session」；但基于起手 Read 快照直接改 dirty 文件会 clobber 在途工作 | 同上 `:46` |
| H6 | **Figma**：`node.characters = newChars` 后旧字符样式按位置残留，必须先对 (0, len) 强制 reset 再逐 range 套用 | `2026-05-13-layout-a…:23` |
| H7 | 删 CSS 前**逐个**实证每个 icon 的 SVG fill 实际值（hardcoded vs currentColor），不用「这类都是 X」的类别化假设——本次误删导致视觉回归 | `2026-05-07-phase-a4…:137` |
| H8 | **vite/构建的 alias 解析 ≠ 审计脚本的静态 text-grep**：同一个 alias 概念在两套系统里独立处理，审计脚本会因此长期静默失效（那条 regex 自写出来就 broken，因构建侧照常跑通所以无人发现） | `2026-05-08-phase-x4-2…` §阶段 C |
| H9 | **本地 `prepublishOnly` 跑过 ≠ CI 一定过**：Node 版本差异会在 module load 期就 SyntaxError（try/catch 来不及兜底）⇒ 脚本只用稳定 stdlib，或 dynamic import + 兜底 | `2026-05-18-v050…:60`、`:102` |
| H10 | 真源 migration 时，**所有引用该真源命名的代码点都要 grep 一遍修全**（token-aliases / divergences / prop-aliases），不能只修 extract 输出端 | 同上 `:81` |

### 2.9 流程机制 → 建议落 `WRAP-UP.md` / `RELEASING.md` / `backlog` 模板

| # | 结论 | 出处 |
|---|---|---|
| I1 | **audit gate 的 `warn-only` 有两种语义**：「基线 FAIL 等修复」与「**预期长期状态、由某 tracker 维持**」。后者必须在 gate 表备注「由谁维持 + 升级触发条件」，否则读数无法解释 | `2026-05-11-bridge-mockup-004…:102` |
| I2 | **audit gate 分层**（strict / warn-only）：strict 走 `prepublishOnly` 任一 fail 即阻断，warn 走独立步骤 continue-on-error；升级只需一处改动 | `2026-05-11-v0-1-publish-flow` §工程技巧 5 |
| I3 | **pre-flight gate 写否定式判断**：列「哪几类 dirty 触发 STOP」，而不是要求「全工作树 clean」——后者必被无关 dirty 打破 | `2026-05-14-v030…:130` |
| I4 | **SoT drift 的链式传染**：resolved 只更新一处、下游复制时没 cross-check、再下游沿用 stale——每步都合理，链路上没人 cross-check ⇒ 派生段不是真源，必须有机械 cross-check gate 而非文本规则 | 同上 `:134` |
| I5 | **destructive 操作判断框架**：按「实物影响 + 历史可追 + 可重做 + 替代成本」四维判断，而不是「看上去 destructive 就绕」 | `2026-05-13-v020…:84` |
| I6 | **scope creep 的可接受边界**：同 commit + 同 pattern + 同 user pain → 顺手扩 OK；换 pattern 或产生新 deliverable → 不扩 | 同上 `:105` |
| I7 | **「真源 + 持续 drift 检测」模式**：SoT 一次 author 完后不再依赖人工对照，上游任何改名/增删由 sync pipeline 的 drift gate 自动报警 | `2026-05-28-bridge-mockup-008…:97` |
| I8 | **memory/决策的实证完成即 closure 触发器**：不应永久保留「待某端改名」这类 open-ended action | 同上 `:101` |
| I9 | **cascade 边界原则** + canonical 新组件的 **export wiring 完整清单（8 项）**，历史最易漏 `src/canonical/index.ts`（它是 `audit:published-vs-code` 的真源依赖） | `2026-05-13-canonical-011…:51` |
| I10 | **tracker entry 范式**：单一 task entry 工作量爆炸（>2x 估值）且可自然拆分时，改为 tracker + child entries，写明 Resolved 条件与关联 gate 升级动作 | `2026-05-11-bridge-mockup-004…` §工程技巧 1 |
| I11 | **写 `:deep` CSS override 前先枚举 child 的所有 layout state**（Normal / Error / Loading / Disabled）再决定 align-items；默认 flex-start 比 center 鲁棒 | `2026-05-09-f23…:59` |
| I12 | **gate scope 诚实界定**：canvas 内像素无法经 `getComputedStyle` 自省 ⇒ 该 gate 只覆盖容器/主题 token，必须写明而不是让读者以为全覆盖 | `2026-06-30-dual-framework…` |

### 2.10 量化历史（勿重建，重建成本高）→ 建议落 tracker 或 `reports/`

- v0.2–v0.5 估时偏差 **3–8x**；release CI **一次过率约 60%（3/5）** ⇒「本地全绿」不能替代 release CI 这道门（`2026-05-18-v050…:102`、`2026-05-14-v040…:97`）
- 一次三轮 A/B 对照实验的完整读数：v1 0pp / v2 0pp / **v3 +44pp**（阈值 30pp），含 8 题逐题评分（`2026-05-27-bridge-mockup-007…`）
- 「tracker 估时往后可以 ÷ 4 作 baseline」（`2026-05-14-v040…:101`）

---

## 3. ⚠️ 需 owner 裁定的（AI 不代拍）

| # | 项 | 出处 |
|---|---|---|
| P1 | **`process-gap-report-2026-06-11.md` 的 4 条 owner-gated 未决项**：B3（QA 验收标准与 M23 UX 卡绑定）、B5（1→1.x 增量 IA Compatibility Check）、C2（WRAP-UP 补 Figma Library sync 验证 gate）、C3（触发器 N 门槛升级）。⇒ 该文件判 `hold-for-human`，**本处方不删它** | `process-gap-report…:424,426,433,434` |
| P2 | 建议该文件**移回现行目录**，或把 4 条未决项转成 backlog entry 后再归档——归档池不该装未闭合决策（§11.3 的反向病例） | 同上 |
| P3 | **「docs site 默认 dark-only 显示」这条当年新加的项目约束在 AGENTS.md 已无落点**，且与后续 M23.18 浅色主题工作可能相抵 ⇒ 请裁定它是被有意废弃还是漏登记 | `2026-05-08-phase-x4-2…:66` |
| P4 | **`BreadcrumbItem.showIcon`** 被 allowlist 的理由是 code 实际暴露 `showSeparator`，改 translation SoT 前需 plan-owner 单独裁决（至今未决） | `2026-05-14-tier1a…:35` |
| P5 | contrast 遗留 **4 条未复核**（select placeholder 散绑 / input·select clear 图标 / multi-select padding / disabled 变体） | `2026-06-11-contrast-closure…:29` |
| P6 | 一条**未落地提案**：「规则文档更新类任务 plan owner 可直接 edit + commit，无需 executor 中转」——至今仅可选 future improvement | `2026-05-11-trifecta…:97` |
| P7 | `2026-05-09-microapps-mockup-retrospect.md` **自陈其留存目的是「起手 onboarding artifact，激发 vigilance」**，与删除直接相抵。lab 按 §11.3 判为 extract（自陈希望被读到 ⇒ 应提炼进现行文档而非留归档），但这是**唯一一处 AI 裁决压过了文件自述意图**，请复核 | `…microapps…:155` |

---

## 4. 删除批次（含**同批约束**，不可拆）

归档内互引边实测 16 条。下列括注「同批」的**必须在同一批**，否则留死链。

| 批 | 文件 | 份 | 行 | 约束 |
|---|---|---|---|---|
| **B1** 校准批 | `2026-05-12-evolution-step-4` + `step-5` | 2 | 94 | 这 2 份是唯一的 `delete`（产物全在 repo 外）。**先跑这批校准闸的信号**：补闸后应仍为绿（无人引用它们） |
| **B2** evolution 链 | `evolution-step-1/2/3` + `2026-05-09-microapps-mockup-retrospect`（step-4/5 已在 B1 删掉） | 4 | 289 | **同批**：step-2→step-1、step-3→step-2，且 step-2/3 → microapps。⚠️ B1 必须在 B2 之前或同时（step-5→step-4→step-3 的出站边随 B1 一起消失） |
| **B3** publish 对 | `2026-05-11-package-rename-scope-alignment` + `2026-05-11-v0-1-publish-flow` | 2 | 443 | **同批**：前者把后者当 baseline 实证引用。⚠️ 后者含**已被推翻的假断言**，提炼时须注明 |
| **B4** phase 链 | `2026-05-08-phase-x4-2` + `2026-05-07-phase-a4-deep-debug` + `2026-05-06-t2-sample-extension` | 3 | 926 | **同批**：x4-2→a4→t2-sample。⚠️ 含 §2.4 D1–D9 那批未入册约束，务必先提炼 |
| **B5** bridge-mockup | `2026-05-27-bridge-mockup-007` + `2026-05-28-bridge-mockup-008` + `2026-05-11-bridge-mockup-004` | 3 | 451 | **同批**：008→007 |
| **B6** v020 对 | `2026-05-13-v020-release-and-infra-f30` + `2026-05-13-canonical-011-prompt-gap` | 2 | 191 | **同批**：v020→canonical-011 |
| **B7** trifecta | `2026-05-11-mockup-conventions-trifecta-rule-update` | 1 | 98 | ⚠️ **必须同时改** `2026-05-11-saas-dashboard-2-option-pm-review.md:3`（**live-source，保留**）里指向它的 markdown 链接，否则留死链 |
| **B8** 其余单件 | `m23-18` / `contrast-closure` / `layout-a` / `tier1a-translation` / `wave1a` / `affordance-sot-shard` / `vitest-fixture-drift` / `infra-f39` / `onboarding-gate` / `m21-r6` / `source-type-mockup-batch` / `v050-release` / `f23-formitem` / `dual-framework` / `v040-release` / `v030-release` / `2026-04-29-meta-rules` | 17 | 1,707 | 无同批约束（`t2-sample→t4-spike`、`dual-framework→react-pilot` 是指向 **live-source** 的出站边，删来源侧无害） |

合计 **34 份 / 4,199 行**（**删除清单口径** · pin 处读数 · = 94+289+443+926+451+191+98+1,707）。
⚠️ **DS 实删 34 份 / 4,165 行**（`c1db57b8`），差 34 行 —— 量级无影响，但引用时**必须带口径名**
（见 `docs/ds-reply-2026-08-25.md` §4 与 **`lab:E39`**）。

> ⚠️ **`lab:E39`：4,199 与 E34 的 47.7% 不是同一个算式，别混。**
> 4,199 = **34 份删除清单**口径；4,665 = **35 份 S2 裁定面**口径（= 4,199 + `process-gap-report` 那 466 行）。
> **E34 的覆盖率 47.7% 用的是后者（4,665 / 9,770）⇒ 不受本处订正影响。**

~~保留 **19 份 / 3,325 行** = 18 份 live-source（2,859）+ `process-gap-report`（466）。~~
⇒ **已被 DS `6b8ad767` 推翻**：现为 **18 份 / 2,841 行**（DS 主工作树口径）。
`process-gap-report-2026-06-11.md`（465 行）**已删** —— 它判 `hold-for-human` 的理由是装着 4 条
owner-gated 未决项（B3/B5/C2/C3），而**那 4 条 2026-08-25 已由 owner 全部拍完 ⇒ hold 的前提消失**。
DS 删前逐行核过 §五 Action List 11 行，恰好只有那 4 行无结论标记 ⇒ 无其它未闭合决策。
> 对账：DS 实测删完是 **3,306** 行（不是处方那个 pin 处旧读数 3,325），3,306 − 465 = **2,841** ✅ 两边对得上。

> ~~**保留面复核**：18 份 live-source 里，`consistency-dimensions-audit-2026-06-12.md:5` 用 markdown 链接指向
> `process-gap-report-2026-06-11.md` —— 后者判 `hold-for-human` 保留，故无死链。这是 hold 决定的一个独立旁证。~~
> ⛔ **这个旁证已失效**（DS `6b8ad767`）：删掉 `process-gap-report` 之后那一行**确实成了死链**，
> DS 已同批把该 markdown 链接**改成裸文本**（沿用 B7 那处的同一处置）。
> ⚠️ 留下的教训：**「无死链」这个旁证的成立条件是「被指向者不删」** ——
> 它从来不是 hold 决定的独立证据，而是**依赖于 hold 决定本身**的循环旁证。⇒ 那种旁证不该被当独立证据用。

---

## 5. 验收判据（⛔ 逐条实测，不接受「已完成 / 通过」式断言）

| # | 判据 | 期望 |
|---|---|---|
| 1 | §1 步骤 ① 的补闸处方已落地并通过其自身 8 条验收 | 贴那份处方的实测输出 |
| 2 | 步骤 ② 全量演练：删 34 份后 `audit:stale-anchors` | **exit ≠ 0**（补闸前是 exit 0，这个由绿转红就是补闸生效的证明） |
| 3 | 步骤 ② 红的文件清单 vs lab `path 口径` 的「有入站」清单 | **逐条一致**；不一致就停下查，不放行 |
| 4 | §2 每一组的 ADR 都有**具体落点**（文件 + 章节），逐组列出 | 无落点的组要说明为何不落 |
| 5 | §2.4 D1–D11 落进 `AGENTS.md §plan owner 角色行为约束` 后，该节条数 | 从 **9 条**上升；grep `by-design` 在非归档面**由 0 变 ≥1** |
| 6 | §3 的 P1–P7 逐条给 owner 裁决结果（ack / 砍掉 / 延后），**砍掉要写理由** | 逐条 |
| 7 | 每批删除后两闸的 exit code + finding 原文 | 逐批贴；`audit:plan-lifecycle` 应始终只有那 1 条 pre-existing（`infra-f129`），**多出任何一条都要查** |
| 8 | B7 批：`saas-dashboard-2-option-pm-review.md:3` 的链接已改 | 贴改后原文 |
| 9 | 删完后 `docs/_archive/retrospection` 剩余份数 / 行数 | ~~19 份 / 3,325 行~~ ⇒ **18 份 / 2,841 行**（18 live-source；`process-gap-report` 已随 hold 前提消失一并删除，DS `6b8ad767`）。⚠️ 引用时带口径名：这是**主工作树口径** |
| 10 | 全量闸链跑一遍 —— ⚠️ **入口按仓当时的形态取**：有 `scripts['gate-chain']` 就跑它，没有才跑 `prepublishOnly`（见下方注） | 与删前对照，**不得新增 finding** |
| 11 | §2 的提炼**不得**被声明成「已穷尽」 | 引用 106 条时必须带口径名（见 §2.0 / E34），否则这条验收不通过 |

> ⚠️ **判据 10 的入口注（2026-08-25，发现 N45）**：DS 在 pin `4a68e02d` 之后把那条 39 步链
> 从 `prepublishOnly` 挪进了 `scripts['gate-chain']`，`prepublishOnly` 退化成一步委托。
> ⇒ 删前删后若一边跑旧 key、一边跑新 key，比的是**两个不同的分母**。
> lab 的三个量具已按 `chainEra` 分档并把读的是哪个 key 写进产物（`chainSource`）；
> 人工执行这条判据时同样要**两次跑同一个 key**，并把 key 名写进验收记录。

---

## 6. 边界与已知不足（这是边界，不是 TODO）

1. **S2 裁决是单裁判 AI 判定，未满足 spec §6.1 铁律 1**（三票须来自不同厂商/型号），铁律 2 的抽样复判与评委方差也未做。
   ⇒ 本处方的 `verdict` 列**不具备 §6.1 要求的统计有效性**。机械复核器只验裁决自洽与证据逐字可定位（35 份 / 108 条证据全过），**不验裁决对不对**。
2. 因为安全网第 1 层实测无覆盖，**当前没有任何机制验证 S2 裁决的语义正确性**——这正是把补闸设为前置、并把「闸红清单 vs lab 口径清单逐条对账」写成验收判据 3 的原因。那步是本处方唯一的语义交叉验证。
3. `docs/internal/retrospection` **22 份 / 2,246 行**（现行、非归档）不在本处方范围（N8）。
4. 提炼是**有损压缩**：106 条来自 **4,165 行**（**删除清单口径** · DS 实删值；⛔ 这**不是** E34 那个 47.7% 的分母 —— 那个用的是 **35 份 S2 裁定面**口径的 4,665，见 `lab:E39`），原文的具体现场（哪个 commit、哪个 node id、哪次对话）不进 ADR。**这是有意的**，但意味着删除不可逆地丢掉现场细节（git history 仍可查，但不会被检索到——§11.3 原话）。
5. evolution-step-2/3 里指向 `docs/internal/retrospection/…` 的路径**已经失效**（那批文件后来移进 `_archive`）——pre-existing，非本处方引入，未处理。