# 协作复盘 — V4-2402 收尾轮（闸补跑 / PM 分歧 / 流程加固）

- **日期**：2026-09-09　**Session 类型**：收尾轮（非 mockup 轮，**Figma 零改动**）
- **档位**：US-6（Review/Audit）· W1（局部视觉修正档）
- **受众**：UX 团队 / PM 内部分享

> ⚠️ **格式说明**：`tvu-design-mockup` skill 的复盘模板要求 8 段，其中「时间线/迭代表」「附录 use_figma 改动统计」两段**本轮不适用**（全程零 use_figma 调用、零设计迭代），故略去并在此声明，⛔ 不硬凑。这一裁剪本身遵循 owner 2026-09-08 立的 W 档精神：交付层重量要匹配工作大小。

---

## 1. TL;DR

- **总轮次**：6 轮用户交互
- **最终交付**：`library-binding` 闸从四轮「未验」销账 · 3 处文档缺陷订正 · PM 回复定稿（owner 手工发出）· 1 个流程加固 hook
- **核心 process gap**：**4 个**（1 个流程漏做 + 3 个方法论错误，全部当轮修掉）
- **关键 insight**：**「规则存在」和「规则被执行」是两回事，而两者之间唯一可靠的桥是把提醒挂在出错的那一刻**。本轮漏做的转单步骤，规则白纸黑字写在 DS 真源里、AI 起手也读过，仍然漏了——因为漏点在任务最后一步。

---

## 2. Session 概览

**起点**：接续 V4-2402，三个非阻塞待办（字体债 / 措辞订正 / library-binding 补跑）。

**实际落地**（含两次用户中途插入的新任务）：

| # | 事项 | 结果 |
|---|---|---|
| 1 | `library-binding` 闸补跑 | ✅ exit=2 → exit=1，范围内新增 0 |
| 2 | PM 回复（对调序号与徽标） | ✅ 草稿定稿，**owner 手工发出** |
| 3 | 字体债清单核验 | ✅ 订正 2 处（表格 stale + §12.4 措辞） |
| 4 | 漏转 assignee | ⚠️ **owner 发现**，已记录 + 装 hook；**转单动作归 owner** |
| 5 | 总闸补跑 | ✅ 收尾时第三次重试成功，NEW=0 |

**Process artifacts**：commit `be300cd` / `c6ad8e2` / `d45b116` · memory `jira-delivery-reassign-to-dev` · hook `~/.claude/hooks/jira-reassign-reminder.sh`

---

## 3. Top 4 process gap（按代价排序）

### G1 ⛔ 交付收尾漏了「转 assignee 给 dev owner」——规则早就有，是执行漏

- **实证**：`design-process.md:208` 明写此规则，`:206` 的 FYI @ dev owner 理由原文就是「便于后续转单衔接」。9/8 发完交付评论 `271762` 后未转，assignee 至今仍是设计侧。**AI 全程没意识到，是 owner 问「不应该转给对应开发吗？我记得 DS 里面有这个规则」才暴露。**
- **返工成本**：低（补做即可），**但暴露的是系统性风险**——2026-07-09 CPU 温度告警那次做对过，所以这是**回归**。
- **根因（不是"忘了"这么浅）**：handoff 把交付收尾记成一行「Jira 回复 ✅ 已发」，**两步被压成一步**；且漏点在任务最后一步，最容易判定"结束了"。
- **回流落点**：① handoff 拆成独立两行（`d45b116`）② memory `jira-delivery-reassign-to-dev` ③ **PostToolUse hook**，在 AI 发完 Jira 评论那一刻强制判定「转/不转 + 理由」。

### G2 ⚠️ PM 的复数措辞里藏着比他显式提问更要紧的分歧

- **实证**：Trevor 问的是「reverse the slot number and the 4G/5G indicators」——**显式问对调**，但他写的是 "indicator**s**"（复数并列），说明他默认 **4G 和 5G 都显示**，而当前定稿 D22 是「只显 5G」。
- **代价（若未察觉）**：只答对调那一层 ⇒ 双方在「已达成一致」的错觉下继续，而对稿子内容的理解并不相同。这类分歧越晚发现越贵。
- **是 owner 点破的**：AI 第一版草稿只答了对调，owner 说「看起来 PM 希望 4G 和 5G 都一起显示」才补上第 1 点。
- **方法论收获**：**回复 review 意见前，先扫一遍对方措辞里的隐含前提，而不是只回答问号后面那句。**
- **落点**：design-record §13.5（含"若确认要 4G+5G 都显"的影响面清单）。

### G3 空分母假象——脚本取错缓存根，所有节点报 MISSING，看着像"全被删了"

- **实证**：核字体债时用 `JSON.parse(...).document`，而缓存结构是 `{_meta, file:{document}}` ⇒ index 建成空的 ⇒ 22 个节点全部 `⛔ MISSING`，两个交付帧也"不在缓存"。**差一点得出「清单全部失效」的错误结论。**
- **讽刺之处**：这正是被调用的那个闸自己防的病——`audit-mockup-library-binding.mjs` 里 `[[INFRA-F140]]` 空分母 fail-closed 的注释逐字讲的就是「扫了 0 个节点」与「扫了 5000 个全干净」输出无法区分。
- **修法**：加 `indexed nodes = 101078` 的 sanity 校验，且**与闸自报的 `scannedNodes` 对上**才采信。
- **可复用判据**：**任何"批量查询全部落空"的结果，先怀疑分母，再怀疑数据。**

### G4 跨轮比数字前没确认是同一个量，差点造出假警报

- **实证**：总闸 `binding-fidelity` 读到 672，而历史四轮记的是 203，一度以为存量债暴涨。实为 **672 = findings 条数 / 203 = findingNodes 节点数**，两个度量。用同度量比 ⇒ **203 = 203，零变化**。
- **代价**：若直接写进文档，会凭空制造一个不存在的回归，并触发无谓排查。
- **判据**：**跨轮对比先对齐度量口径**；报告里同时存在多个计数字段时尤其危险。

---

## 4. 本轮验证有效的做法（⛔ 不只记教训）

> 依据 memory `收尾复盘拆分记录：教训 vs 验证过的好方法`——只囤教训会让判断力朝过度谨慎单向漂移。

1. **用 owner 亲手建的东西做阴性对照，是本轮最强的证据形态。** 归属核验拿 owner 手建的 `Plan C for UX Design` 当对照组，得出 **componentId 集合双向差集为空** ⇒ 一举排除「是 AI 建法有问题」这个解释。比单纯report「60 条都是存量债」有力得多，**下次归属类核验直接套用**。
2. **fail-closed 的 exit=2 要当成信息读，不是故障。** 本轮查清 exit=2 的真因是「缓存 7/9 抓、节点 9/8 建」，闸是**正确地拒绝给出会被误读的结论**。修法是重抓缓存而非绕过——`grep` 实证 `10247:420` 0 命中 / 7 月前节点 6 命中，两行命令就定了性。
3. **诚实划边界比宣称"已解决"更有用。** hook 只能拦 AI 的工具调用，owner 自己在 Jira 网页发评论那一半兜不住——写进 memory，避免下次谁（包括 AI）以为万无一失。
4. **owner 那句「我记得 DS 里面有这个规则」是高价值介入**：它把 AI 从"接受现状"推回"去查真源"。⇒ **团队提这类质疑时给出线索（哪份文档/大概哪条）比直接给答案更能纠正 AI 的检索路径。**

---

## 5. 高效对话建议

**给 UX / PM（提需求 / 提意见方）**
- 对已交付设计提 review 意见时，**若心里的前提与稿子不同，请直说前提**（如本轮的"4G 也该显示"）。只提改法、不提前提，容易变成两边各说各的。
- 质疑 AI 漏做时，**带上"我记得哪里有这条规则"**——这比只说"你漏了"更快让 AI 找到真源并自查。

**给 AI 协作流程**
- 交付收尾类清单**一步一行**，别把「发评论」「转单」压成一行。压成一行 = 打了勾就以为整件事完了。
- **批量查询全部落空 → 先查分母**；**跨轮比数字 → 先对齐度量**。
- 管道会吞 exit code（`cmd | head` 后的 `$?` 是 head 的）——要判 exit code 就别接管道。

---

## 6. 已回流的规则清单

| 规则 | 落点 | 简述 |
|---|---|---|
| 交付后必须转 assignee | memory `jira-delivery-reassign-to-dev` | 含"谁发评论谁转单"分工 + 机械保证边界表 |
| 发评论即提醒转单 | `~/.claude/hooks/jira-reassign-reminder.sh` + 全局 settings.json | PostToolUse，matcher = `addCommentToJiraIssue` |
| 收尾清单两步分行 | 本项目 handoff §0（`d45b116`） | 6 / 6b 两行 |
| PM 分歧未决 | design-record §13.5 | D22 重标未决 + 影响面清单 |
| 闸口径与度量纪律 | design-record §14.6 | 同度量比较 + 未深究处不假装已核 |

⚠️ **均未写进 DS 真源**：G3/G4 是通用方法论，但按 `M-DISCIPLINE.SOURCE` 三问需 owner 拍板「是规则级问题而非一次性失误」才升 DS。本轮各留一处实证，**攒够再议**。

---

## 7. Model 选型

本轮 Opus 5（1M context），任务形态是**审计核验 + 跨系统查证 + 对外沟通措辞**，非长链路生成。表现符合：查真源、做程序化归属、发现度量口径问题都靠得住；但**G1 那类"规则读过却没在正确时刻想起"的漏，模型能力提升解决不了**——那是流程装置该管的，也正是本轮装 hook 的理由。

---

## 8. 给团队的 action items

| # | 事项 | 归属 |
|---|---|---|
| 1 | **V4-2402 转 assignee → Edward Wu** | owner（谁发评论谁转单，本轮评论由 owner 手工发出）|
| 2 | 等 PM 回话确认「只显 5G」还是「4G+5G 都显」 | PM Trevor → 回来后 owner 决定是否开新一轮 |
| 3 | 字体债 20 个 `Roboto Bold → Verdana Bold`（+ 顺手清 2 个不可见 `4G` override）| owner，本地 Figma |
| 4 | 措辞订正 `I5392:17702;1140:57`（V4-1543 单标题本体）| 需 PM 点头后再改 |
| 5 | 确认 hook 已加载（开一次 `/hooks` 或重启）| owner |