{
  "generator": "S2 AI 判定（人工驱动的 AI 裁决，非脚本产出）",
  "subject": "tvu-ds",
  "subjectSha": "71ac2711f7f18ac1eba521bdd5999f66659dbf82",
  "judgeModel": "claude-opus-5[1m]",
  "promptTemplateVersion": "n/a（无模板；本轮由会话内逐份通读驱动）",
  "judgePanel": "single-judge ⚠️ 未满足 spec §6.1 铁律 1 的异构陪审团（3 个不同厂商/型号投票），也未做铁律 2 的评委方差抽样复判。见报告 §边界登记。",
  "verdictVocabulary": {
    "delete": "0 引用 + 结论已在现行文档固化（已由 s2-claims 核实）+ 无未闭合项 ⇒ 可进分批删除",
    "extract-then-delete": "含**尚未固化到现行文档**的可复用结论 ⇒ 先提炼进 ADR，提炼后原件才可删（§11.2）",
    "hold-for-human": "存在 AI 不该单方拍板的冲突（未闭合决策 / 自述留存目的与删除相抵）⇒ 交 T3"
  },
  "criterion": "§11.3 判断标准：「这份内容，你还希望 AI 读到吗？」希望 → 提炼进现行文档；不希望 → 删。⛔ 拒绝「既不想让 AI 读到、又不敢删」的囤积态。",
  "rows": [
    {
      "file": "docs/_archive/retrospection/2026-07-14-m23-18-auto-apply-calibration.md",
      "verdict": "extract-then-delete",
      "confidence": "high",
      "reason": "M23.18 规则本体已固化（s2-claims 核实 mockup-conventions.md:876）。但真正可复用的是那条**元准则**——「触发方式该默认自动还是要显式」的判据——而它只存在于 repo 外的跨 session memory 文件里，仓内零落点。删原件 = 该准则在 DS 仓内彻底消失。",
      "evidence": [
        { "line": 24, "quote": "新规则/新机制定触发方式时" },
        { "line": 18, "quote": "AI 把这种谨慎本能不加区分地套用到了低风险场景" },
        { "line": 11, "quote": "M23.18" }
      ],
      "extract": [
        "定触发方式的判据：正确答案能否从上下文客观推出 + 做错代价是否低且可逆 —— 两者皆是则默认自动应用，任一为否才要显式触发。",
        "反模式：因为项目里到处是「改动前先确认」的硬规矩，就把谨慎本能不加区分地套到低风险、可逆、可探测的场景上。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-06-11-contrast-closure-axe-artifact.md",
      "verdict": "extract-then-delete",
      "confidence": "high",
      "reason": "两条命名纪律（axe 背景伪影一律先疑 / 「等设计师」类 entry 报给 owner 前先 live 复核 staleness）都是可复用的测量有效性纪律，仓内无对应规则。且 §pattern 2 末尾留了 4 条**明确未复核**的遗留项。",
      "evidence": [
        { "line": 23, "quote": "一律先疑伪影" },
        { "line": 29, "quote": "下次拿它们说事前先 live 验" },
        { "line": 12, "quote": "回退到 body 色" }
      ],
      "extract": [
        "axe/自动审计报告里「light 主题 + dark-layer 背景色」的配对一律先疑测量伪影，用 painted-ancestor 链实测真实绘制底后才进清单。",
        "「等设计师」类 backlog entry 报给 owner 前先 live 复核是否已 stale —— owner 是并发编辑者，文档记载滞后于产品真值。",
        "⚠️ 未闭合：select placeholder 散绑 / input·select clear 图标 / multi-select padding / disabled 变体 4 条未复核。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-13-layout-a-line-by-line.md",
      "verdict": "extract-then-delete",
      "confidence": "medium",
      "reason": "主结论（Layout A-逐行 pattern）已固化，s2-claims 核实 mockup-conventions.md:51 有「A-逐行」。残留一条 Figma API 技术陷阱（set characters 后按位置继承旧样式），属 figma-technical-reference 的 Q-类知识，未核实在册 ⇒ 先提炼。",
      "evidence": [
        { "line": 33, "quote": "§双语支持" },
        { "line": 23, "quote": "Figma 会按位置保留旧字符的样式" }
      ],
      "extract": [
        "Figma 陷阱：`node.characters = newChars` 后旧字符样式按位置残留；必须先对 (0, len) 强制 reset 为基准样式，再逐 range 套用，否则继承上一版污染。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-12-evolution-step-1.md",
      "verdict": "extract-then-delete",
      "confidence": "medium",
      "reason": "C1-C4 四项规则改动本体已落地。残留一条**反增生**设计原则：用 generic 维度表覆盖一类问题，而不是为每个新 case 加一条规则 —— 这正是本 lab 关注的规则增生反面教材，仓内未见成文。",
      "evidence": [
        { "line": 22, "quote": "任何未来出现的 context mismatch 都被表格覆盖，不需逐个加规则" },
        { "line": 21, "quote": "instance 过度 override 失去 library 同步价值" }
      ],
      "extract": [
        "反增生原则：同一类偏差用一张 generic 维度检查表覆盖，而不是为每个新出现的 case 追加一条规则。",
        "规则不应隐含要求逐个 override 默认值 —— 那既违反举一反三，也让 instance 失去 library 同步价值；正确措辞是「必须评估」而非「必须改」。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-12-evolution-step-2.md",
      "verdict": "extract-then-delete",
      "confidence": "medium",
      "reason": "M11/M12/M13 合并与 M17-M20 迁出均已落地（s2-claims 核实 figma-technical-reference.md 存在，Q1-Q4 自标「原 M17-M20」）。残留一条规则重构约定：合并规则时用 sub-number 保留可追溯性，而不是直接删号。",
      "evidence": [
        { "line": 22, "quote": "cross-ref 用 M11.1/M11.2/M11.3 保持追溯性" },
        { "line": 24, "quote": "不动顺序不动内容" }
      ],
      "extract": [
        "规则重构约定：合并多条规则时保留 sub-number（M11.1/M11.2/M11.3）而非直接删号，让历史 cross-reference 仍可解析。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-12-evolution-step-4.md",
      "verdict": "delete",
      "confidence": "high",
      "reason": "纯过程记录，且产物落在 repo 之外（`~/.claude/agents/design-walkthrough.md`），lab 只读 DS 仓、不追踪用户主目录（§8）。自陈 dogfood 跳过、未验证；三个月后该 agent 的 report 格式已被 design-process.md 的 F1 走查取代。仓内零可提炼结论。",
      "evidence": [
        { "line": 12, "quote": "~/.claude/agents/design-walkthrough.md" },
        { "line": 29, "quote": "Figma MCP 当前 session 断连" }
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-12-evolution-step-5.md",
      "verdict": "delete",
      "confidence": "high",
      "reason": "同 step-4：产物全在 repo 外（persona-simulation.md / design-qa-loop.md）。dogfood 结果本身是一次性的具体 bug 修复记录，已随 Figma 文件变更失效。仓内零可提炼结论。",
      "evidence": [
        { "line": 12, "quote": "~/.claude/agents/persona-simulation.md" },
        { "line": 43, "quote": "design-qa-loop.md" }
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-14-tier1a-translation-schema.md",
      "verdict": "extract-then-delete",
      "confidence": "medium",
      "reason": "gate 本体已固化（s2-claims 核实 package.json:90 有 audit:translation-completeness）。但 §Follow-Up 三条是**allowlist 条目的裁决理由**，其中 BreadcrumbItem.showIcon 明写「需要专门的 plan-owner 决策」⇒ 属未闭合项，删前须转移。",
      "evidence": [
        { "line": 35, "quote": "needs a dedicated plan-owner decision" },
        { "line": 31, "quote": "10 explicit allowlisted findings" },
        { "line": 37, "quote": "prose/script-level rather than grep/rg" }
      ],
      "extract": [
        "⚠️ 未闭合：`BreadcrumbItem.showIcon` 被 allowlist 的理由是 code 实际暴露 `showSeparator`，改 translation SoT 前需 plan-owner 单独裁决。",
        "⚠️ 未闭合：Popup Box / Drop down List / Chart / Slider / Rating 的 coverage finding 属 allowlist-until-scope，非永久豁免。",
        "两条 divergence verifyHint 仍是散文/脚本级而非 grep 可判 —— 属规则可判定率缺口。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-06-02-wave1a-verifier-confirm-and-color-mix-blindspot.md",
      "verdict": "extract-then-delete",
      "confidence": "high",
      "reason": "lesson 1（color-mix 假阳）自陈已在 code + tracker 落地。但 lesson 2 是**口径纪律**：覆盖面一变分母就重置，跨段数字不可比 —— 与 lab 独立得出的 N19/AGENTS §2.4 同形，仓内仅在 tracker 某段有个案说明，无通用成文规则。这是本批提炼价值最高的一条。",
      "evidence": [
        { "line": 25, "quote": "覆盖率一变，数字不可跨段比较" },
        { "line": 19, "quote": "已在 code + tracker ledger 落地" },
        { "line": 16, "quote": "只可能把 fail 变 pass" }
      ],
      "extract": [
        "口径纪律：审计余量（A 数）是相对「当前覆盖的 manifest」的，不是绝对健康度。覆盖面 backfill 会重置分母 ⇒ 跨段数字不可续接，必须重取 baseline 而非估值。",
        "修判据时论证单调性：只可能把 fail 变 pass、不可能反向的修复是安全的，可免于全量回归。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-12-evolution-step-3.md",
      "verdict": "extract-then-delete",
      "confidence": "high",
      "reason": "三个拆分文件都已存在（s2-claims 三条 present）。残留两条高价值内容：①「thin 的实现方式」——为何不删规则正文只加必读链路入口（这是上下文经济学的一次真实取舍记录）；② 一次早期的 cold-start 观测（只读两份文件覆盖 80% 决策路径）。两者仓内均无成文。",
      "evidence": [
        { "line": 28, "quote": "删除会破坏历史 AI 依赖这些文件的 session onboard 路径" },
        { "line": 37, "quote": "可以覆盖 80% 决策路径" },
        { "line": 29, "quote": "voice-neutral" }
      ],
      "extract": [
        "「变薄」的实现取舍：不删规则正文，而是在顶部加必读链路入口表 —— 理由是删除会打断历史 AI 依赖这些文件的 onboarding 路径。（⚠️ 这条也是 _archive 只进不出的同源病灶，提炼时应与 §11.3 出口规则并读。）",
        "早期 cold-start 观测：新 session 只读 design-process.md + domain-tvu.md（约 16 条规则）即可覆盖约 80% 决策路径 —— 可作 §12.3 cold-start 维度的历史锚点。",
        "规则措辞 path-neutral 化：改用「生成 deliverable / 采用 source 组件」，不说「画 mockup」或「写代码」，使同一条规则跨 Figma 与 code 两面适用。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-13-canonical-011-prompt-gap.md",
      "verdict": "extract-then-delete",
      "confidence": "high",
      "reason": "**文件自陈结论未落地**（「本次先存档此 retrospect」），s2-claims 两条 absent 判据已独立确认 meta-rules 无 export-wiring 段、模板文件不存在。⇒ 删它就是删掉那张 8 项 export wiring 清单 + cascade 边界原则。此外 §5 自陈「AI 不会去 grep 历史复盘」，是 discoverability 的一手证据。",
      "evidence": [
        { "line": 60, "quote": "本次先存档此 retrospect" },
        { "line": 51, "quote": "影响远超本任务直接动的文件" },
        { "line": 58, "quote": "不在协议里，建议加进 META checklist" }
      ],
      "extract": [
        "cascade 边界原则：layout-affecting 改动（nav / shared shell / page lattice）的影响面远超本任务直接动的文件；prompt 必须穷尽列出 cascade 边界（base impl + canonical wrapper + index re-exports + nav wiring + DocsShell + page + baseline + audit 数据源），不能只列主线文件。",
        "canonical 新组件的 export wiring 完整清单（8 项，历史最易漏 `src/canonical/index.ts` —— 它是 `audit:published-vs-code` 的真源依赖）。",
        "discoverability 一手证据：该复盘自陈「应 grep 历史复盘看教训」这件事**不在任何协议里**，即结论虽写下但 AI 起手不会读到。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-06-01-affordance-sot-shard-and-parallel-session.md",
      "verdict": "extract-then-delete",
      "confidence": "high",
      "reason": "loader 本体已落地（s2-claims 核实 figma-sync/lib/affordance-sot.mjs 存在）。但 loader-shard 模式的**设计约束**（分片不得成为第二份真源、幂等 round-trip、拆分键选全值字段）与并行 session 共享工作树的认知纠正，仓内无成文规则；后者自陈「无新增 memory」⇒ 只活在这份复盘里。",
      "evidence": [
        { "line": 16, "quote": "把单文件 SoT 拆成目录时" },
        { "line": 46, "quote": "共享同一个工作树" },
        { "line": 24, "quote": "先验消费方再动手" }
      ],
      "extract": [
        "loader-shard 模式：拆大 JSON SoT 成目录时，唯一知道磁盘形状的地方是一个共享 loader，它把目录重组回旧的合并形状，使所有消费方零语义改动；写操作必须幂等（write(load()) 产出 byte-identical）。",
        "拆分键必须选**全值字段**（644/644 有值）而非可 null 字段，否则产生孤儿桶。",
        "改共享数据结构前先 grep 出全部硬消费方并逐个判断顺序敏感性 —— 「先验消费方再动手」。",
        "并行 session 认知纠正：同机同目录的并行 session **共享同一个工作树**，不存在「留给那个 session」；提交对其他 session 无害，但基于起手 Read 快照直接改 dirty 文件会 clobber 在途工作。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-13-vitest-fixture-drift.md",
      "verdict": "extract-then-delete",
      "confidence": "medium",
      "reason": "P1 的缓解措施已落地（s2-claims 核实 .husky/pre-commit:8 含测试）。残留 P3（stash 分诊标准动作，文件自陈要「存档为 debugging 标准动作」）与 P4（最小 diff 纪律），以及 P2 那条「source-grep test 测的是错的层」——都是可复用判据设计教训，仓内未成文。",
      "evidence": [
        { "line": 48, "quote": "做 baseline 分诊很有用" },
        { "line": 36, "quote": "fixture drift 是 silent failure pattern" },
        { "line": 58, "quote": "最小 diff = 最低回归风险" }
      ],
      "extract": [
        "分诊标准动作：怀疑某改动引入回归时，`git stash -u && 跑测 ; git stash pop` 是数秒给出确凿答案的诊断，先做它再诊断。",
        "source-grep 测试测错了层：断言 `.vue` 源码里有某字面字符串，在页面重构成运行时渲染后必然失效；rendered-text 检查应走 mount-based 测试而非源码 grep。",
        "fixture drift 是 silent failure：写死 runtime 渲染文本的断言，数据漂移时不编译错也不运行错，只在跑测时报错 ⇒ commit 不跑测就直接进主干。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-06-03-infra-f39-verifier-accuracy.md",
      "verdict": "extract-then-delete",
      "confidence": "high",
      "reason": "verifier 能力（gapTargetSelector / suppressRootSize）已在代码里。但两条测量有效性教训未成文：①「量错元素」既虚高也**掩盖**真 drift（与 lab 的 N10 fail-fast 遮蔽同形）；② `audit:tokenized-diff` 的 raw↔tokenized 恒等约束限定了 fix 只能落在哪一层 —— 这是动手前必须知道的硬约束，丢了会返工。",
      "evidence": [
        { "line": 70, "quote": "既虚高也掩盖真 drift" },
        { "line": 71, "quote": "修 fix 前 grep 下游消费方" },
        { "line": 24, "quote": "raw↔tokenized 结构恒等" }
      ],
      "extract": [
        "测量有效性：「量错元素」不只是把数字虚高，它同时**掩盖**真 drift（错误测量点上两边巧合相等 ⇒ 假 PASS）。retarget 到正确元素会同时清幻影 + 暴露真问题；数字只有在拓扑对了之后才双向可信。",
        "硬约束（动手前必知）：`audit:tokenized-diff` 断言 raw 与去 token 后的 tokenized **结构恒等**，tokenize 只能新增 token 字段。⇒ 任何「把某字段置 null」的修法不能落在 normalize 层，只能落在 verifier 层。",
        "修 fix 前先 grep 下游消费方 —— 这次正是动手前 grep 才没撞上 prepublishOnly 的 strict gate。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-13-onboarding-gate-enforcement.md",
      "verdict": "extract-then-delete",
      "confidence": "high",
      "reason": "规则本体已固化（s2-claims 核实 AGENTS.md:61 有 Onboarding Gate、meta-rules.md:37 有触发器 K）。但 §5 五条通用工程教训未成文，其中「L1 文本 = 提示、L3 hook = 触发」「文本提及 ≠ checklist 显式步骤」「跨工具兜底」三条分别对应 lab 的 rule-hit、discoverability、portability 三个维度，提炼价值很高。",
      "evidence": [
        { "line": 76, "quote": "L1 文本规则 = 提示，L3 hook = 触发" },
        { "line": 80, "quote": "文本提及 ≠ checklist 显式步骤" },
        { "line": 77, "quote": "跨工具兜底" }
      ],
      "extract": [
        "enforcement 分层：L1 文本规则只是提示，L3 hook 才是触发。客观可测的关键流程必须升到 L3，文本规则不可替代机械触发（本 session 实证：链路已文档化，AI 仍跳步）。",
        "discoverability：**文本提及 ≠ checklist 显式步骤**。文档顶部提过某个 SoT，不等于它进了起手必读的编号清单 —— 前者 AI 会漏，后者才会执行。",
        "portability 兜底：hook 只在单一 harness 生效，跨工具靠 L1 文本 + 项目契约文档兜底 ⇒ 机械触发与中立表达要**同时**存在，不能二选一。",
        "加 hook 前先读现有配置并 merge 而非覆盖（本次差点覆盖掉另一个已注册 hook，靠 schema 校验才拦住）；hook 脚本 commit 前先 pipe-test 验证输出合法。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-11-mockup-conventions-trifecta-rule-update.md",
      "verdict": "extract-then-delete",
      "confidence": "medium",
      "reason": "M14/M21/M22 三规则均已固化（s2-claims 三条 relocated 到 design-process.md）。残留：① meta lesson「单一规则防不住一次 build 踩多条盲点，规则之间必须 cross-reference」——这是规则集架构原则；② §元规则补强 是一条**明确未落地**的提案（s2-claims absent 判据已确认 meta-rules 无此条）。",
      "evidence": [
        { "line": 80, "quote": "规则之间必须 cross-reference" },
        { "line": 72, "quote": "Single-rule defense 不够防 build trifecta" },
        { "line": 97, "quote": "考虑在 meta-rules.md 加一条" }
      ],
      "extract": [
        "规则集架构原则：一次错误可同时踩多条规则的盲点，单条规则补强不够；相关规则必须互相 cross-reference + 在优先级表里写明谁 override 谁，否则未来 review 从任一条都找不到完整案例。",
        "⚠️ 未落地提案：「规则文档更新类任务 plan owner 可直接 edit + commit，无需 executor 中转」—— 至今仅为可选 future improvement，未进 meta-rules。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-11-m21-r6-existing-pattern-reuse.md",
      "verdict": "extract-then-delete",
      "confidence": "high",
      "reason": "M21/R6 本体已固化（s2-claims：M21 relocated 到 design-process.md、R6 present 于 code-conventions.md:399）。残留 §元规则启发 三条是**写规则的方法论**，抽象层级高于任何单条 M/R 规则，仓内 meta-rules 未见成文。",
      "evidence": [
        { "line": 108, "quote": "写规则当下 self-test" },
        { "line": 109, "quote": "import 机制存在不等于复用行为自动发生" },
        { "line": 110, "quote": "scope 显式标注" }
      ],
      "extract": [
        "写规则当下就在当前任务上 self-test：新规则的首要验收标准是它能指导手头这个决策。如果在自己的任务里都用不上，说明规则错或用得不到位。",
        "规则不能假设「机制 = 行为」：机制存在（如 import 复用）不等于行为自动发生；规则要约束行为，不要假设机制保证。⛔ 也不能因为「看似不会发生」就省略镜像规则。",
        "scope 显式标注：新规则与既有规则不冲突的关键，是把适用时序差（greenfield vs incremental）写进规则正文，避免后续 AI 误判适用范围。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-06-01-source-type-mockup-batch.md",
      "verdict": "extract-then-delete",
      "confidence": "high",
      "reason": "三条技术规则全部回流且已核实（s2-claims Q18/Q19/Q20 三条 present）。残留一条通用纪律「脚本返回无报错 ≠ 结果正确」——与 AGENTS §4 同形、且是批量操作的具体动作（先单例验证再批量、批量后立刻查计数），仓内未成文。",
      "evidence": [
        { "line": 98, "quote": "setCurrentPageAsync" },
        { "line": 85, "quote": "脚本返回无报错 ≠ 结果正确" },
        { "line": 83, "quote": "先跑 1 个，截图确认正确，再批量" }
      ],
      "extract": [
        "批量写操作纪律：先单例验证（跑 1 个 + 截图确认）再批量；批量后立刻查计数核对实物。**脚本返回无报错 ≠ 结果正确** —— 本次「运行成功」的批量脚本写错了页面，产生 44 个重复 frame。",
        "克隆操作三件套：① 确认目标页 ② 克隆 ③ 验证关键属性（width / layoutSizing）—— 隐性假设（当前页、sizing 继承）在批量执行时会放大成不可逆事故。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-18-v050-release.md",
      "verdict": "extract-then-delete",
      "confidence": "high",
      "reason": "release 流水账本身可删，但含三条仍然有效的工程结论，其中「本地 prepublishOnly 跑过 ≠ CI 一定过」直接关系到当前 gate 链改造（第 9 步）的可信度边界；另有一份跨 release 的估时/CI 一次过率量化历史，是难以重建的实测语料。",
      "evidence": [
        { "line": 60, "quote": "Local prepublishOnly 跑过 ≠ CI 一定过" },
        { "line": 102, "quote": "本地 prepublishOnly 不能完全替代" },
        { "line": 81, "quote": "都要 grep + 修一遍" }
      ],
      "extract": [
        "本地 prepublishOnly 跑过 ≠ CI 一定过：Node 版本差异会在 module load 期就 SyntaxError（try/catch 来不及兜底）。⇒ 脚本只用稳定 stdlib，或 dynamic import + 兜底；长期应 CI matrix 双版本或把本地 Node 钉到 CI 同版本。",
        "真源 migration 时，所有引用该真源命名的代码点都要 grep 一遍修全（token-aliases / divergences / prop-aliases），不能只修 extract 输出端 —— 反向引用漏改会在 release CI 才被抓出。",
        "量化历史（勿重建）：v0.2–v0.5 估时偏差 3–8x，release CI 一次过率约 60%（3/5）⇒ 「本地全绿」不能替代 release CI 这道质量门。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-09-f23-formitem-page-rewrite.md",
      "verdict": "extract-then-delete",
      "confidence": "medium",
      "reason": "§实证沉淀 自标「建议入 meta-rules.md 附录」，属**自陈未落地**；三行反模式/正解表 + D2 元教训（:deep override 要先枚举所有 child layout state）都是可复用的产物约束，仓内未见。其余（bug 链路、commit 清单、三个月前的待办排序）已失效可弃。",
      "evidence": [
        { "line": 67, "quote": "建议入 meta-rules.md 附录" },
        { "line": 59, "quote": "先列出所有可能 child layout state" },
        { "line": 51, "quote": "架构兼容性需要在 prompt 设计阶段 verify" }
      ],
      "extract": [
        "架构兼容性必须在 prompt 设计阶段 verify，不能让 executor 跑完才发现 ——「通用 grid 渲染模型」与「必须 slot 真组件」是冲突约束，命名上看不出来。",
        "写 `:deep` CSS override 前先枚举 child 的所有 layout state（Normal / Error / Loading / Disabled）再决定 align-items；历史 override 常基于「Normal 假设」，扩展状态一来就错位。默认 flex-start 比 center 鲁棒。",
        "prompt 设计阶段要逐个检查 child 组件的 theme 相关 prop 清单并写进任务步骤，不能假设 executor 会「自然识别」。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-13-v020-release-and-infra-f30.md",
      "verdict": "extract-then-delete",
      "confidence": "high",
      "reason": "release 流水账可删，但含两条高复用度的决策框架：① destructive 操作的三维判断框架（实物影响 / 可逆性 / 替代成本）；② scope creep 的可接受边界（同 commit + 同 pattern + 同 user pain）。两者仓内均无成文，且正是 AI 反复需要判断的场景。",
      "evidence": [
        { "line": 84, "quote": "destructive 不等于不能做" },
        { "line": 105, "quote": "同一 commit 内、同一 pattern、同一 user pain → 扩 ok" },
        { "line": 71, "quote": "协议价值实证" }
      ],
      "extract": [
        "destructive 操作判断框架：按「实物影响 + 历史可追 + 可重做 + 替代成本」四维判断，而不是「看上去 destructive 就绕」。本次删远端 tag 因无 consumer 实物、tag 指向仍在 history、可重打，明确优于 bump patch 留版本洞。",
        "scope creep 的可接受边界：同一 commit 内 + 同一 pattern + 同一 user pain → 顺手扩 OK；换 pattern 或产生新 deliverable → 不扩。",
        "协议价值需要实证：v0.1 silent fail 后加的「verify registry 实物」步骤，在本次第一次真正拦住误判（否则会以为 CI green 就是发布成功）—— 说明它不是 ceremony。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-06-30-dual-framework-generator-and-low-risk-batch.md",
      "verdict": "extract-then-delete",
      "confidence": "high",
      "reason": "含三条已被反复验证的协作纪律（核磁盘实物别信摘要 / handoff 里的「修法」未经 gate 实证一律当假设 / review 的根因判断本身也要 probe 再信），以及一条极具体的架构结论（light-DOM 模式下 Vue 拒绝注入 styles，须手动注入）。这些是 29 组件双框架落地的真实约束，仓内未成文，重建成本极高。",
      "evidence": [
        { "line": 63, "quote": "核磁盘实物别信摘要" },
        { "line": 106, "quote": "一律当假设" },
        { "line": 125, "quote": "review 的根因判断也要实证" },
        { "line": 104, "quote": "在 light-DOM 模式明确拒绝注入 styles" }
      ],
      "extract": [
        "「核磁盘实物别信摘要」：subagent 摘要未提的越权改动，靠 controller 核 git log 才抓出 ⇒ 完成声明必须用磁盘实物/git 实物复核，不采信文字总结。",
        "pickup / handoff 里写的「修法」若未被 gate 实证，一律当假设：本次 pickup 的 `shadowRoot:false` 修法实测更糟（1 A → 134 A），spike 后才找到正解。",
        "review 的根因判断也要 probe 再信：review 说「transition race」方向对但**位置**判错（是 text locator 而非 shadow 边界）⇒ 凡另行定位读 computed style 的节点都要先 disable transition，不止 root。false-PASS 与 false-FAIL 同源于此。",
        "架构结论：Vue 3.5 在 light-DOM 自定义元素模式下明确拒绝注入编译后 styles（只 warn）⇒ `shadowRoot:false` 必须配手动把 styles 注入 document.head；样式在 base 组件时还需额外声明样式来源。",
        "gate scope 诚实界定：canvas 内像素无法经 getComputedStyle 自省 ⇒ 该 gate 只覆盖容器/主题 token，不是 chart-rendering gate，必须写明而不是让读者以为全覆盖。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-11-bridge-mockup-004-baseline-assumption-invalid.md",
      "verdict": "extract-then-delete",
      "confidence": "medium",
      "reason": "具体路线决策（CANONICAL-010/011 派生）已完成失效。残留三条可复用范式：baseline 实跑先于定路径、tracker entry 范式、audit gate「warn-only by design」这一状态语义 —— 后者尤其重要，它区分「基线 FAIL 等修」与「预期长期状态」，直接关系到 gate 读数怎么解释。",
      "evidence": [
        { "line": 10, "quote": "必须 baseline 实跑后才能定路径" },
        { "line": 71, "quote": "STOP + 重新 propose 路线" },
        { "line": 102, "quote": "预期长期状态" }
      ],
      "extract": [
        "backlog entry 里的工作量估值必须标明是「估（假设）」还是「baseline 实跑后已验证」；路径设计前必须 baseline 实跑，即使 backlog 已给估值。真相与假设差 >2x 时 STOP 重新 propose，不要 fight 走完原路径。",
        "audit gate 的 `warn-only` 有两种语义：「基线 FAIL 等修复」与「**预期长期状态、由某 tracker 维持**」。后者必须在 gate 表里备注「由谁维持 + 升级触发条件」，否则读数无法解释。",
        "tracker entry 范式：单一 task entry 工作量爆炸（>2x 估值）且可自然拆分时，改为 tracker + child entries，并写明 Resolved 条件与关联 gate 升级动作。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-27-bridge-mockup-007-roi-validation.md",
      "verdict": "extract-then-delete",
      "confidence": "high",
      "reason": "这是 DS 自己做过的一次**带阈值的 A/B 对照实验**（3 轮 32 题 + 真画 Figma，Δ=44pp vs 30pp 阈值），其方法论教训与 lab 的 §6.2 噪声地板/MDE 概念同形且更早。三条 lessons（baseline 接近天花板则实验无区分度 / 只跑一边等于只测一半 / AI 自由 search 优于 SoT 时是 scope 洞不是 schema 坏）仓内均无成文。",
      "evidence": [
        { "line": 128, "quote": "如果 baseline 接近天花板，实验本身没区分度" },
        { "line": 131, "quote": "只跑一边等于只测一半" },
        { "line": 134, "quote": "schema 没坏，要扩 scope" },
        { "line": 62, "quote": "mockup 视觉碎片化无法跨产品复用" }
      ],
      "extract": [
        "ROI/对照实验设计：起手先估 baseline 能拿几分。**baseline 接近天花板 ⇒ 实验没有区分度**，加难度不如换测量路径（本次白跑 2 轮才发现 A 路径自己就 8/8）。",
        "双消费者的 SoT 必须两边都测：「只跑一边等于只测一半」—— code 侧无增益不代表 mockup 侧无增益（实测差 44pp）。",
        "当 AI 自由检索优于 SoT 时，根因通常是 SoT 的 **scope 洞**而非 schema 坏 —— 结论应是扩 scope，不是改 schema。",
        "目标重定义：这类 SoT 的价值不是「让 AI 选对」，而是**一致性收敛器** —— 保证同一业务意图在不同任务/session/时间点收敛到同一个组件 key，否则视觉碎片化无法跨产品复用。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-14-v040-release.md",
      "verdict": "extract-then-delete",
      "confidence": "medium",
      "reason": "release 流水账可删。残留三条：①「我没找到」≠「不存在」，rationale 实证必须 grep 全仓库含 tests/scripts/.husky/config；② pickup/spec 与代码现状 desync 时应修 spec 而不是改代码追上错误 spec；③ 18 步 release wrap-up checklist（自陈供未来参考）。前两条是反复出现的判断错误。",
      "evidence": [
        { "line": 75, "quote": "rationale 实证必须 grep 全仓库" },
        { "line": 46, "quote": "不是改代码追上错误 spec" },
        { "line": 101, "quote": "tracker 估时往后可以 ÷ 4 作 baseline" }
      ],
      "extract": [
        "「我 grep 没找到」≠「不存在」：下「不存在」结论前必须覆盖全仓库（tests/ + scripts/ + .husky/ + config，不止 markdown）。本次因只 grep docs/ 就断言 executor 编造，实际那条 contract 真实存在于 tests/。",
        "spec 与代码现状 desync 时，修 spec 而不是改代码去追上错误 spec（tail wagging the dog）；实施前先 baseline 实跑对照现状。",
        "命名 slot vs default slot：default slot 已承载 content/trigger 时不能兼做 label/content，须用命名 slot —— 属翻译层最小化原则的具体落点。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-28-bridge-mockup-008-closure.md",
      "verdict": "extract-then-delete",
      "confidence": "medium",
      "reason": "sprint 交付本体已落地并可核（s2-claims：icon-naming-convention R1-R5 present、audit-figma-vs-sot.mjs 存在）。残留三条战略学习：ROI gate 实验法值得 codify、「真源 + 持续 drift 检测」模式、memory 实证完成即 divergence closure 触发器。⚠️ 它以同目录相对链接引用 bridge-mockup-007，两份必须同批处理。",
      "evidence": [
        { "line": 93, "quote": "先做半小时 5-10 case 对照实验" },
        { "line": 101, "quote": "memory 实证完成 = divergence closure 触发器" },
        { "line": 105, "quote": "commit 边界不总是按 sprint 干净切分" }
      ],
      "extract": [
        "扩量前先做小样对照：不直接做 N× scope expansion，先花半小时跑 5–10 case 的 A/B 对照，Δ 超过阈值才扩量。",
        "「真源 + 持续 drift 检测」模式：SoT 一次 author 完后不再依赖人工对照，任何上游改名/增删由 sync pipeline 的 drift gate 自动报警 —— 这是「onboarding 知识有 staleness 风险，需 audit 持续验证产品真值」的具体落地。",
        "memory/决策的实证完成即 closure 触发器：不应永久保留「modification direction: 待某端改名」这类 open-ended action，实证到位就该关掉。",
        "并行 session + 共享工作树下 commit 边界不总按 sprint 干净切分 ⇒ 写复盘引 commit hash 前要核对实际 staged 范围。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-09-microapps-mockup-retrospect.md",
      "verdict": "extract-then-delete",
      "confidence": "medium",
      "reason": "M11–M20 十条规则均已固化（s2-claims：M11.1/M15 relocated 到 design-process.md、M20 relocated 到 figma-technical-reference.md Q4）。⚠️ 但本文件 §七 自陈其价值是「作为下次起手的 onboarding artifact」，与删除直接相抵 —— 按 §11.3 的标准，自陈「希望被读到」的内容应**提炼进现行文档**而非留在归档，故判 extract 而非 hold。提炼必须带走那句元教训，否则删除等于丢掉它。",
      "evidence": [
        { "line": 155, "quote": "文档只能 capture rule，没法 capture discipline" },
        { "line": 149, "quote": "写下一条规则的下一秒，我违反了它" },
        { "line": 92, "quote": "规则放进 conventions 文档不等于会被执行" }
      ],
      "extract": [
        "元教训（本批最重要的一条）：**写下一条规则的下一秒就违反了它**。这不是认知问题而是 execution discipline 问题 —— 规则不会自动 enforce 自己，没有外部触发器（脚本 / checklist / 用户追问）就会被反射习惯覆盖。「规则放进 conventions 文档」≠「规则会被执行」。",
        "「Adequate 当 Done」：完成度阈值由自己默认设定而非由「产物能否直接交付」决定 ⇒ 任何 we're-done 类断言前必须先输出 probe 数值，禁止直接给视觉结论。",
        "把库和参考稿当 lookup table 而不是需要先建 mental model 的 system，会导致反复搜不到、抄错、以及主观断言「库没有 X」。",
        "⚠️ 该文件自陈其留存目的是「起手 onboarding artifact，激发 vigilance」；提炼进现行文档时应保留这一意图（例如放进起手必读链路而非普通归档），否则删除会丢掉它自陈的功能。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-11-package-rename-scope-alignment.md",
      "verdict": "extract-then-delete",
      "confidence": "high",
      "reason": "具体协议补丁已固化且可核（s2-claims：Release wrap-up 必改项 relocated 到 WRAP-UP.md:23，且该处仍逐字保留 v0.1.0/v0.1.1 silent fail 依据）。但 §5 的**一般化**结论（中间步骤成功 ≠ 链路成功；release flow 必须显式定义并 verify final artifact）比那条 checklist 抽象一级，仓内只有具体条目没有通则。",
      "evidence": [
        { "line": 7, "quote": "Release tag pushed + CI green 不等于 publish 成功" },
        { "line": 152, "quote": "单步成功 ≠ 链路成功" },
        { "line": 91, "quote": "历史快照" }
      ],
      "extract": [
        "通则：**中间步骤成功 ≠ 链路成功**。任何流程都要显式写出 final artifact 是什么（registry 实物 / production 状态 / 用户可见结果），并有一步专门 verify 它 —— tag pushed / CI green / CLI exit 0 都只是 means。",
        "协议盲点是正常的，关键是暴露时显式 patch 到机制层（checklist + hook + 文档），而**不 retrofit 历史叙事**掩盖错判 —— 错判要留作 baseline 实证。",
        "错判会沿「上游文档这么写所以是真的」的链式信任传播（本次跨 STATUS / 复盘 / pickup / CHANGELOG 四处放大，持续 1–2 周）⇒ 派生文档不能作为事实来源。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-08-phase-x4-2-and-badge-rename.md",
      "verdict": "extract-then-delete",
      "confidence": "high",
      "reason": "自陈「必记入册」的 4 条行为约束（#16–#19）**实测未入册**：AGENTS.md §plan owner 角色行为约束 现有 9 条不含它们，全仓非归档面 grep「by-design」零命中，「dark-only」在 AGENTS.md 零命中。⇒ 删原件就是丢掉 4 条自称强制的约束。这是本批提炼价值最高的两份之一。",
      "evidence": [
        { "line": 160, "quote": "设计意图判断" },
        { "line": 165, "quote": "报视觉差异前必先 grep figma 真源" },
        { "line": 175, "quote": "跨 session 任务必须在 repo 留锚点" },
        { "line": 106, "quote": "前者是 commit scope 控制" }
      ],
      "extract": [
        "#16 不替真源编设计理由：不下「by-design / 设计意图」判断。看到低对比等问题时只报告「引用了哪个 token、token 值是多少、真源同值」，由 owner 决定真源是否要改。（⚠️ 全仓零落点）",
        "#17 报「视觉与真源不一致」前，必先 grep 真源 token 值（两个 mode）对照实现侧定义 —— 一致则是真源本身如此，不是实现漂移。（⚠️ 全仓零落点）",
        "#18 「不入本次 commit」≠「从工作区删除」：前者是 commit scope 控制（用选择性 `git add`），后者是文件生命周期管理。⛔ 不允许用 `rm` / 卸依赖去达成「不入 commit」。（⚠️ 全仓零落点）",
        "#19 跨 session 任务必须在 repo 留锚点（最低一条 backlog entry）—— 对话里的计划新 session 看不到。（⚠️ 全仓零落点）",
        "vite/构建的 alias 解析 ≠ 审计脚本的静态 text-grep：同一个 alias 概念在两套系统里独立处理，审计脚本会因此长期静默失效（本次那条 regex 自写出来就 broken，因为构建侧照常跑通所以无人发现）。",
        "⚠️ 需 owner 确认：「docs site 默认 dark-only 显示」这条当年新加的项目约束，在 AGENTS.md 已无落点，且与后续 M23.18 浅色主题工作可能相抵 —— 提炼前请裁定它是被有意废弃还是漏登记。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-14-v030-release.md",
      "verdict": "extract-then-delete",
      "confidence": "medium",
      "reason": "release 流水账可删。残留四条：SoT drift 的链式传染根因（每步都合理、没人 cross-check）、pre-flight gate 应写否定式判断（本 sprint 范围内文件未 dirty，而非全树 clean）、估时「实跑前不信」、plan-owner 直改的 pragmatic exception 边界。这些是流程设计经验，仓内未成文。",
      "evidence": [
        { "line": 134, "quote": "每一步看起来合理，没人做 cross-check" },
        { "line": 130, "quote": "本 sprint 范围内文件未 dirty" },
        { "line": 114, "quote": "实跑前不信" },
        { "line": 152, "quote": "Pragmatic exception" }
      ],
      "extract": [
        "SoT drift 的链式传染：resolved 只更新了一处、下游复制时没 cross-check、再下游沿用 stale —— 每一步看起来都合理，链路上没人做 cross-check，drift 放任十余天。⇒ 派生段（active 列表）不是真源，必须有机械 cross-check gate 而非文本规则。",
        "pre-flight gate 写**否定式**判断：列出「哪几类 dirty 触发 STOP」（本 sprint 输出路径已脏 / 已 ship 产物被改 / 明示不动的文件被改 / baseline 不绿），而不是要求「全工作树 clean」—— 后者必被无关 dirty 打破。",
        "估时栏标「实跑前不信」，下一轮重估用上一轮实跑数据（本项目实测 4–8x 乐观偏差，且 baseline 后路径常大幅简化）。",
        "plan owner 直改代码的 pragmatic exception 边界：trivial（<5 行）+ 已读上下文 + 立刻 verify 可直改；10+ 行复杂改动仍走 executor。边界不应频繁突破。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-04-29-meta-rules-and-bridge-goal-establishment.md",
      "verdict": "extract-then-delete",
      "confidence": "high",
      "reason": "meta-rules.md / PROJECT_GOAL 的结构性升级本体已落地。残留 §反思 4 那张表是**判据设计教训**：三层核对（normalized JSON → audit JSON → markdown report）、「文件存在」不能当验证通过、报告渲染层的空白不等于数据缺失。与 lab 自己的 fail-closed / must-not-hit 纪律同形，且是 DS 最早一次成文的判据方法论。",
      "evidence": [
        { "line": 196, "quote": "先做三层核对" },
        { "line": 191, "quote": "topology success 必须有子验证器的具体 evidence" },
        { "line": 177, "quote": "规则必须落到仓库" }
      ],
      "extract": [
        "判据/报告 bug 的三层核对：`normalized JSON` → `audit JSON` → `markdown report`。⛔ 不要只看报告 grep 结果 —— 「报告为空 / 轴消失」多半是渲染层或验证命令本身的问题（起止 pattern 相同让 awk 立即结束、`-A1` 只抓到空行），数据其实在。",
        "「文件存在」不能算验证通过：任何 `✅ xxx-match-via-*` 都必须有真实 evidence（CSS 值 / prop 枚举 / 变量链），否则是假阳性。",
        "角色化而非工具化：规则不绑具体 AI 工具，用 plan owner / executor 等角色表述，切换工具不需要改任何规则文件 —— 这是可移植性的最早一次成文。",
        "「我会记住」无效（有数据印证）：规则必须落到仓库文件，下次 session 读到才生效。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-11-v0-1-publish-flow.md",
      "verdict": "extract-then-delete",
      "confidence": "medium",
      "reason": "⚠️ 本文件的标题结论是**已被推翻的假断言**（自称 0.1.0 已发布成功，实为 registry silent reject），更正在 package-rename 那份里，且已机制化。留着它在仓内意味着 AI 可能读到并采信一句假事实 —— 按 §11.3「你还希望 AI 读到吗」应删。但 §工程技巧 与 §团队分享 里有若干仍成立的可复用范式（尤其那句多 AI 协作的中立表达），提炼后再删。⚠️ 它被 package-rename 当 baseline 实证引用（同目录相对链接），两份必须同批删。",
      "evidence": [
        { "line": 5, "quote": "已发到 GitHub Packages" },
        { "line": 216, "quote": "关键是把规则" },
        { "line": 182, "quote": "不用 \"manually inspect\" 类指令" }
      ],
      "extract": [
        "portability 表述（值得单独归集）：多 AI 工具在同一项目协作不互相破坏，关键是把规则「硬」在仓库里，而不是「软」在某个 AI 的 prompt 历史里。",
        "验证机械化：prompt 的验证段只用可机械执行的命令（exit code / 行数 / 字段计数 / JSON 校验），不写「manually inspect」类指令。",
        "audit gate 分层（strict / warn-only）：strict 走 prepublishOnly 任一 fail 即阻断，warn 走独立步骤 continue-on-error；follow-up 修完后升级只需一处改动。",
        "⚠️ 提炼时必须注明：本文件的「已发布成功」是假断言，其价值在于作为 silent-failure 的 baseline 实证，不可作为事实引用。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-07-phase-a4-deep-debug.md",
      "verdict": "extract-then-delete",
      "confidence": "high",
      "reason": "自陈「必记入册」的 15 条行为约束里，实测多条未入册：AGENTS.md §plan owner 角色行为约束 现有 9 条不含 destructive 操作前授权、不含 commit 前逐个 git diff M 文件；working-principles.md 也没有那条自陈要加的「共享组件不 emit no-op inline style」。⇒ 与 05-08 那份并列为本批提炼价值最高。另含一条 CSS specificity 结构性结论。",
      "evidence": [
        { "line": 242, "quote": "前必须先报告 + 等用户授权" },
        { "line": 145, "quote": "共享 UI 组件默认不 emit no-op inline style" },
        { "line": 168, "quote": "sample-first" },
        { "line": 137, "quote": "类别化假设" }
      ],
      "extract": [
        "共享组件不得 emit no-op inline style：`color: currentColor` 语义等于 inherit，但作为 inline style 具有最高 specificity，会屏蔽所有外部 class 的 color 规则 ⇒ 任何 consumer 用外部 CSS 改色都失效。prop 未显式设置时不要 emit inline style。（⚠️ 自陈要写进 working-principles，实测未写）",
        "destructive 操作（git checkout / reset / clean）前必须先报告并等授权；且每次重新 `git diff` 独立判断，不复用上一次的诊断结论 —— 本次 anchoring bias 直接 revert 掉 38 个路径的真实工作。（⚠️ 现行 AGENTS 约束表未含）",
        "commit 前必须对**每个**未 staged 的 M 文件 `git diff` 看内容并显式分类（进本 commit / 是噪音 / 属另一任务 / 是越权改动）。⛔ 不允许「忽略 M 文件直接 commit」。（⚠️ 现行 AGENTS 约束表未含）",
        "算法类 fix 的 spec 必须**枚举所有匹配形态**（alias / 显式登记 / identity 三条路径），只写 happy path 会让 executor 漏掉分支，而单个样本可能恰好蒙混过关。",
        "sample-first 不只是降风险，更是**发现机制完整性的工具**：第 1 个样本暴露契约缺口，第 2 个样本的准备阶段才暴露上一个 fix 不完整 ⇒ 复杂批量任务必须 sample-first，不要线性单 prompt 复用。",
        "删 CSS 前逐个实证每个 icon 的 SVG fill 实际值（hardcoded vs currentColor），不用「这类都是 X」的类别化假设 —— 本次误删导致视觉回归。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/2026-05-06-t2-sample-extension-and-phase-a-bootstrap.md",
      "verdict": "extract-then-delete",
      "confidence": "high",
      "reason": "Phase A 自动化本体已完成失效。但 §复盘后续发现 三条是**协作机制**教训：anchoring bias 导致误 revert、commit stage 复审不彻底让越权改动滞留 4 个 commit、以及由此立的「完成报告必须列全部改动文件」条款。这条 prompt 条款是可复用的反藏匿机制，仓内 AGENTS §executor 约束未见「完整改动清单」要求。",
      "evidence": [
        { "line": 418, "quote": "完成报告必须列出" },
        { "line": 370, "quote": "anchoring bias" },
        { "line": 399, "quote": "任何 commit 前 plan owner" },
        { "line": 110, "quote": "跨 session 检索成本高" }
      ],
      "extract": [
        "反藏匿条款：executor prompt 必须要求「完成报告列出 **全部** 改动文件（含修改/新增/删除），即使不在 prompt 显式范围内」，并与「按任务的改动」分开列 —— 否则前瞻性 silent enhancement 会滞留工作区，之后被误判成噪音。",
        "anchoring bias：看到同样的 diff 直接套用上一次的诊断结论（「这是 scope creep 噪音」）⇒ 误 revert 掉真实工作。每次重新独立过 diff。",
        "把散落在各份复盘「待办」段的问题集中成一份项目级 backlog 真源 —— 散落的待办跨 session 检索成本高、易忘、无统一入口。（⚠️ 与 §11.3 归档出口规则同源：本次 S2 的 35 份里仍有多份带未闭合待办。）",
        "真源消费者不得成为编辑者：generator/audit 读 alias 真源，缺条目时 warn 而不是自动写入。"
      ]
    },
    {
      "file": "docs/_archive/retrospection/process-gap-report-2026-06-11.md",
      "verdict": "hold-for-human",
      "confidence": "high",
      "reason": "⛔ 这份不是复盘，是**带未闭合决策的诊断台账**，且是活状态而非历史记录：B3 / B5 / C2 / C3 四条既无「已落」也无「砍掉」标记，仍是 owner-gated 待决；同时它是 10 条已决项（含 2 条 owner 明确砍掉、附砍掉理由）的唯一出处。AI 无权代替 owner 判定这些是否放弃 ⇒ 交 T3。附带发现：一份仍有未闭合决策的文件被放进了 `_archive`，属「归档池装了活状态」，本身是 §11.3 的反向病例。",
      "evidence": [
        { "line": 4, "quote": "所有建议等 owner 逐条 ack" },
        { "line": 424, "quote": "QA 验收标准与 M23 UX 卡绑定" },
        { "line": 426, "quote": "IA Compatibility Check" },
        { "line": 433, "quote": "补 Figma Library sync 验证 gate" },
        { "line": 434, "quote": "触发器 N 门槛升级" }
      ],
      "extract": [
        "⚠️ 交 owner：B3（QA 验收标准与 M23 UX 卡绑定）、B5（1→1.x 增量 IA Compatibility Check）、C2（WRAP-UP 补 Figma Library sync 验证 gate）、C3（触发器 N 门槛升级）四条至今无 ack / 无砍掉标记。",
        "建议：该文件应从 `_archive` 移回现行目录（或把四条未决项转成 backlog entry 后再归档）—— 归档池不该装未闭合决策。"
      ]
    }
  ]
}