# Phase A4 深度 debug 复盘（2026-05-07）

> 接续 [`2026-05-06-t2-sample-extension-and-phase-a-bootstrap.md`](2026-05-06-t2-sample-extension-and-phase-a-bootstrap.md)。
> 本复盘覆盖 commit 99be418 之后到 commit e966d41 期间的工作 + 暴露的多层 plan owner / executor / 共享组件 bug。
> 新 session onboarding 时**必读**本复盘，避免重蹈 5+ 个已暴露的协作失误。

---

## TL;DR

- **范围**：A4.0 generator theme fix + A4.1 NotificationPage sample (含 grid contract 扩展 / dark-only 规则建立 / Interactive Scenario / Icon stack 多层 root fix) + A4.0 follow-up identity fallback
- **6 commits**：c623544 → 8679c3a → e966d41（其中 8679c3a 大 commit 30 文件 +1306/-354）
- **暴露 bug 链路**：
  - Generator: A4.0 fix 不完整（仅 alias path + Known Entries，遗漏 canonical theme axis identity case）
  - Grid: cellMinWidth 默认 176px 不适合大组件（Notification 重叠）
  - CSS: Icon.vue inline `style="color: currentColor"` specificity 屏蔽外部 CSS（结构性 bug）
  - 真源: status-error 别名指向 Error 2 圆叉但 raw.ts 渲染三角（运行时 vs 真源不一致）
- **暴露 plan owner 失误链路**：
  - 漏发触发器 D（写复盘晚 4 commits）
  - 误 git checkout revert Codex A4.0 实际工作（anchoring bias）
  - commit stage 复审 M 文件不彻底（Codex silent scope creep 4 commits 未 detect）
  - 看不到 user-Codex 直接通道（误判 silent scope creep）
  - CSS dead code 误诊（没核 status-* vs message-* fill 模式差异）
  - A4.0 fix 不完整（设计意图与实施落差）

---

## 阶段 9：A4.0 generator theme identity fix（commit c623544）

### 推进
- A4.1 sample 准备时 plan owner 实证发现 Notification figma axis 是 `'theme'` (canonical identity) 但 generator 派生 variant.theme 仅在 GLOBAL alias 触发时生效——Notification 14 variants 缺该字段
- Codex 实施 fix：propByAxis 派生加 `componentPropAliases` (Known Entries) fallback + theme axis 检测加 `hasValueAlias / hasCanonicalThemeValues` 双触发
- Notification 14 variants 加 variant.theme（dark/light）
- NotificationPage α verdict: N/A → fail (correctness improvement)

### 关键决策
- variant.theme 派生应基于 canonical axis name === 'theme'（不论 alias 或 identity）—— plan owner spec
- Codex 实施时**只**走 globalAxisAliases + componentPropAliases 双路径，**未**加 identity 三 fallback —— 这是阶段 9 fix 不完整的根因（阶段 11 follow-up 补完）

---

## 阶段 10：A4.1 NotificationPage sample 多轮 debug（commit 8679c3a）

### 5 个连续 prompts 暴露 unforeseen issues

| # | Prompt | 暴露问题 |
|---|---|---|
| Round 1 主轮 | NotificationPage 改造 | ✅ 改造合规但视觉 cells 重叠 |
| Round 2 follow-up | Grid `cellMinWidth` prop + dark-only 删 Light Members + Interactive Scenario | 暴露：(a) 4 行 CSS color rules 误判全 dead，部分 restore 后仍 white；(b) 1 column 强制需 cell-min-width=`'100%'` |
| Round 3 follow-up-2 | restore 2 selector + cellMinWidth='100%' | 视觉 reverify 仍 error/info 白色 → 暴露 Icon.vue inline override 设计 bug |
| Round 4 follow-up-3 | Icon.vue conditional inline color emission | + Codex 顺手改 raw.ts (status-error 三角 → X 圆) |
| user-Codex 直接 channel | 用户授权 Codex 走 raw.ts 真源对齐 | plan owner 误判 silent scope creep → 用户截图澄清 |

### 关键发现 1：Grid contract gap

`FigmaMembersGrid` 默认 `grid-template-columns: repeat(auto-fit, minmax(176px, 1fr))` 适合 Badge/Tooltip 小组件，**不适合大组件**（Notification 480px width hardcoded 致内容溢出）。

**Fix**：加 `cellMinWidth?: string` prop（默认 `'176px'`）→ NotificationPage 传 `'100%'` 强制 1 column。

### 关键发现 2：Docs site dark-only 规则

User 报"提过很多遍" docs site 不该同时显示 light + dark。Plan owner 在 prompt §0 让 NotificationPage 保留 Light Theme Members 段是错误延续 BadgePage/TooltipPage 范式。

**Fix**：
- 删 Light Theme Members 段 / 任何 light-displaying section
- AGENTS.md "项目约束" 段加 "Docs site 默认 dark-only 显示" 规则（扩展 `dark-theme-only-monitoring` memory rule）
- Theme-axis 组件 grid 用 `:site-theme="'dark'"` 静态注入

### 关键发现 3：Icon.vue inline `color: currentColor` 是 CSS specificity 灾难

[`src/components/Icon/Icon.vue`](../../src/components/Icon/Icon.vue) default `color = 'currentColor'` → render `<span style="color: currentColor">`。

CSS 后果：
- inline `style="color: ..."` specificity (1, 0, 0, 0)
- 外部 class `.notif--error .notif__icon { color: var(--red) }` specificity (0, 2, 0)
- **inline 永远赢** → 任何 Consumer 用外部 CSS 改 icon color 失效

CSS spec：`color: currentColor` 等于 `color: inherit`——意图是 "使用父级颜色"，但作为 inline style **有 specificity 屏蔽外部 CSS**。这是 Icon.vue 设计 bug，可能 affecting 整个项目所有 Icon consumers。

**Fix**：`iconStyle` computed，仅 prop ≠ default 'currentColor' 才 emit inline style.color。

### 关键发现 4：BaseNotification iconMap 真源不一致 + raw.ts 运行时漂移

| iconMap key | 解析到 | SVG fill | 视觉 shape |
|---|---|---|---|
| `'message/error-4'` (warning) | `IconMessageError4` | hardcoded `#EA4233` | 三角 |
| `'message/warning-2'` (secondary warning) | `IconMessageWarning2` | hardcoded `#F68512` | 圆 |
| `'status-error'` (error) | `IconStatusError` | `fill="currentColor"` | **三角**（run-time）但 icon-aliases.ts 真源说 = `'icon/Message/Error 2'` 圆 X |
| `'status-info'` (info) | `IconStatusInfo` | `fill="currentColor"` | i 圆 |

两层不一致：
1. iconMap 内 message-* 与 status-* 共存（一种 hardcoded 一种 currentColor）
2. status-error 真源 (icon-aliases.ts) 登记圆 X 但 raw.ts 渲染三角

**用户授权 Codex 走根因修法**：raw.ts `IconStatusError` SVG path 三角 → X 圆（保 `fill="currentColor"`）+ 保 BaseNotification iconMap.error 用 'status-error' 别名。Runtime 真源对齐。

---

## 阶段 11：A4.0 follow-up canonical theme axis identity fallback（commit e966d41）

### 推进
- A4.2 sample 准备读 ProgressPage 时实证：Progress / Rating / Slider 缺 variant.theme 字段（A4.0 fix 漏）
- 根因：A4.0 fix 派生只走 globalAxisAliases + componentPropAliases 双路径，遗漏 figma axis 名直接是 canonical 'theme' 但没在 Known Entries 段登记的 identity case
- Notification 偶然 work 因为 Known Entries 段 happen to 有 `Notification.theme` exact-match entry
- Fix: 1 行 identity fallback `?? (figmaAxis === 'theme' ? 'theme' : undefined)`
- 受影响 3 .ts 加 variant.theme（progress 16 / rating 10 / slider 4）

### 关键决策
- A4.0 fix 设计意图 vs 实施落差是 plan owner 监督失败 —— prompt 没枚举所有 axis 名形态（应包括 identity case 的 explicit 期望）
- Sample-second 范式 (A4.2 ProgressPage 准备前) 实证 catches A4.0 incomplete —— 验证了 sample-first 切分的价值

---

## 触发器 / 反模式 实证（新增 5 条，超 commit 9dc00ac）

### 🔴 plan owner 看不到 user-Codex 直接通道（meta gap）

A4.1 follow-up-3 raw.ts 出现意外 SVG path 改动，plan owner 标 silent scope creep 警告。但实际 user 已在 plan owner prompt 之外**直接**指示 Codex"走更根本的修法"——这指令 plan owner 看不到。

**机制修复**：
- Plan owner 复审 Codex STOP 报告时，**先查报告原文**（如用户贴 STOP 报告截图）再下"silent scope creep"判断
- 用户给 Codex 直接指令属正常协作 —— plan owner 不该假设 Codex 只听 prompt
- 任何"scope creep"surface 措辞应**先 ask 用户是否授权**（"以下改动不在 prompt 范围，是你单独授权 Codex 还是 silent creep？"）—— 不下结论性判断

### 🔴 plan owner CSS 知识 gap

A4.1 follow-up cleanup 把 4 行 `.notif--<status> .notif__icon { color: var(--*) }` 全标 dead code 删除。

实际：
- warning / secondary warning：dead（icons hardcoded SVG fill）✓ 删 OK
- **error / info**：not dead（icons 用 `fill="currentColor"`）❌ 误删 → 视觉 white

二次自检后才发现 status-* 用 currentColor 而 message-* hardcoded —— iconMap 真源不一致。Plan owner 没机械跑"逐 icon 验 SVG fill 模式"。

**机制修复**：
- 删任何 CSS 涉及 component icon / SVG color 之前**强制**实证检查每个 icon 的 SVG fill 实际值（hardcoded vs currentColor）
- 不依赖"SVG 都是 hardcoded fill" 这种**类别化假设**——逐 SVG 查

### 🔴 CSS specificity 隐 trap：inline style 屏蔽外部 CSS

Icon.vue default `color = 'currentColor'` + inline emit → `style="color: currentColor"` —— 看似 no-op（语义等于 inherit）但**有 specificity (1,0,0,0)** 屏蔽外部 class color rules。

**机制修复**：
- 任何共享组件 inline style 含 `color`/`background` 等 token-driven 属性时**必须**：(a) prop 未设时不 emit inline；(b) 文档 callout"外部 CSS 不能直接覆盖 inline，必须传 prop"
- `working-principles.md` 加新原则："共享 UI 组件默认不 emit no-op inline style 屏蔽外部 CSS"

### 🟠 A4.0 fix 不完整 — plan owner spec 不够具体

Plan owner spec "variant.theme 派生应基于 canonical axis name === 'theme'"——意图清楚，但 Codex 实施只覆盖 alias path + Known Entries。

根因：plan owner spec 没**枚举**所有 axis 名进入 'theme' 的形态：
- alias 'dark theme' → 'theme'（Codex 实施 ✓）
- Known Entries `Notification.theme` exact match（Codex 实施 ✓）
- **identity 'theme' 直接是 canonical**（Codex 漏，需 plan owner spec 显式列出）

**机制修复**：
- Plan owner spec 算法 fix 时**枚举所有匹配条件**（不只是 happy path），让 executor 测试每条
- Sample-second / sample-third 是关键：单 sample 暴露 fix 不完整（Notification 偶然 work 蒙混过关；ProgressPage 准备时 catch）

### 🔴 触发器 K（新）：sample-first 切分的真实价值

User 选 (c) "sample-first" 切分 A4.2 时 plan owner 推荐 ProgressPage 作 2nd sample。准备时实证 A4.0 fix 不完整 → 在批量 fire 前 catch。

**机制 / 教训**：
- "Sample-first" 不只是降风险，**还是发现机制完整性的工具**
- 第 1 sample (NotificationPage) catches Grid contract gap + dark-only + Icon stack
- 第 2 sample (ProgressPage 准备阶段) catches A4.0 incomplete
- 推论：未来类似复杂 phase **必须** sample-first，不要"线性单 prompt 复用"

---

## 待办（更新于 commit e966d41 之后）

### 立刻（新 Session 开始时）
- 🔴 **A4.2 sample (ProgressPage transform) prompt 已写未 fire**：[`docs/internal/_prompts/phase-a4-2-progress-page-sample.prompt.md`](../_prompts/phase-a4-2-progress-page-sample.prompt.md)
  - 用户在新 session 直接 fire 给 Codex
  - 跑完 plan owner 复审 + 视觉验收 → commit → 进 A4.2 batch (8 page) 或 A4.3

### Phase A4 后续
- A4.2 batch：BreadcrumbPage / FormItemPage / InputNumberPage / PaginationPage / PromptMessagePage / RatingPage / StepsPage / TablePage（剩 8 🟡 page，ProgressPage sample 通过后批量）
- A4.3 主题批：CheckboxPage / RadioPage / SwitchPage（3 🟠 page）
- A4.4 token 批：SliderPage / TabsPage / TopBarPage（3 🔴 page，含 δ token 修）

### Backlog 中（不阻塞 Phase A）
- ✅ CANONICAL-001 已 Resolved (commit 616e719)
- ✅ CANONICAL-003 已 Resolved (commit 8679c3a)
- 🟡 CANONICAL-002 PromptMessage auto-dismiss (Medium, 等业务用例)
- 🔴 BRIDGE-Tier2: Input/Select 多 set 合并模型（独立设计）
- 🔴 BRIDGE-Tier3: Button 21 sets mega 聚合模型（独立设计，需 Org plan）

### 未 commit dirty / 独立 task
- `docs/internal/figma-component-catalog.md` (用户 mockup 工作流，独立 task，**不进** Phase A commits)
- `docs/internal/mockup-conventions.md` (untracked unrelated)
- `.claude/settings.json` (本地)

---

## 工作区状态（新 Session pickup）

### git
- HEAD: `e966d41 fix(t2-sample): A4.0 follow-up — canonical theme axis identity fallback`
- 本 session 累积 commits（按日期）：
  - 2026-05-06 (≈12 commits)
  - 2026-05-07 早段 (commit e966d41)
- branch: master，工作区干净（除 .claude / catalog / mockup-conventions / 1 prompt 待 fire 是 untracked）

### Phase A 进度概览（commit e966d41 后）
```
✅ A0 prop-aliases cleanup (20445f3)
✅ A1 generator auto-discovery for 19 Tier 1 (130fc13)
✅ A2 audit auto-discovery + ε audit (f9ca71c)
✅ A3 sweep + 工作清单 (隐式 in A2)
✅ A4.0 generator variant.theme uniform derivation (c623544)
✅ A4.0 follow-up identity fallback (e966d41)
✅ A4.1 NotificationPage sample (8679c3a — huge: grid + dark-only + Interactive + Icon stack)
⏳ A4.2 ProgressPage sample (prompt 已写未 fire)
⏸️ A4.2 batch (8 page)
⏸️ A4.3 主题批 (3 page)
⏸️ A4.4 token 批 (3 page)
⏸️ Tier 2 / Tier 3 独立 ticket
```

---

## 新 Session onboarding checklist

新 session 启动时按下面顺序读：

1. [`AGENTS.md`](../../AGENTS.md) — 跨工具入口 + 硬规则 6 条 + 项目约束（Pro plan + **Docs site 默认 dark-only 显示**——本 session 新加）
2. [`docs/meta-rules.md`](../meta-rules.md) — 元规则 + 反模式清单 + 触发器（特别 G + I + 9dc00ac 加的 ABCD/E/H/I 触发器）
3. [`docs/internal/long-term-plan-v2-2026-04-29.md`](../long-term-plan-v2-2026-04-29.md) — v2 路线图
4. [`docs/internal/retrospection/2026-05-06-t2-sample-extension-and-phase-a-bootstrap.md`](2026-05-06-t2-sample-extension-and-phase-a-bootstrap.md) — 前一份复盘（含 Phase A 启动 + 4 个新发现失误）
5. **本文件** — 阶段 9-11 lessons + Phase A4 当前状态
6. [`docs/internal/backlog.md`](../backlog.md) — 必读 backlog
7. `git log --oneline -20` — recent commits
8. **A4.2 sample prompt 已写**：[`docs/internal/_prompts/phase-a4-2-progress-page-sample.prompt.md`](../_prompts/phase-a4-2-progress-page-sample.prompt.md) —— 新 session 第一个动作就是 fire 这个

---

## 必记入册的 plan owner 行为约束（新 Session 必遵守）

1. **destructive 操作（git checkout / reset / clean）前必须先报告 + 等用户授权**——commit 9dc00ac 教训
2. **commit stage 前 git diff 每个 M 文件实证**——不假定 timestamp 噪音
3. **Plan owner 看不到 user-Codex 直接通道**——任何"silent scope creep"surface 应先 ask 用户而不是下结论
4. **prompt §4 完成报告必须含"§4.X 完整改动清单"段**——让 silent 修改无法藏匿
5. **dev 视觉 executor 不自评**——启动 dev 后 STOP 等用户截图
6. **CSS 涉及 dead code 删除前实证**每个 icon SVG fill 实际值（hardcoded vs currentColor）
7. **算法 fix prompt 必枚举所有匹配条件**（不只 happy path），spec 显式列出 identity / alias / Known Entries 三 path
8. **Sample-first 是发现机制完整性的工具**——任何复杂 phase 必须 sample-first，不要"线性批量"
9. **改造 figma-data-missing 8 组件之一的 page 前，plan owner 必须先视觉对比 Figma 真源截图 vs canonical 渲染**（FormItem / Rating / Switch / Notification / TopBar / StepItem / Slider / Checkbox+Input + Progress）—— 发现 token mismatch → 先修 canonical 或入 backlog → 再 fire page transform prompt
   - **Why**：T1c PAUSED → 这 8 组件的 canonical token 选择是历史/猜测，未真源 verify。Page transform 不暴露 canonical 视觉问题；A4.2 ProgressPage sample 是因为用户主动对比才发现 track invisible
   - **How to apply**：进入 A4.2 batch / A4.3 / A4.4 任何 figma-data-missing 组件 page 改造前，plan owner 用 figma 真源截图（用户提供 / Figma MCP `get_screenshot`）+ canonical dev 截图对比；mismatch → 入 backlog (类似 CANONICAL-004) → 修 canonical token 或决定延后 → 再 fire page transform
   - **实证 case**：CANONICAL-004 Progress track `--bg-layer3` (#262626) vs figma 真源 #353535 (--line-deep) mismatch（commit fae0c04）

10. **Page transform prompt §0 必须 explicit 约束 "template restructure 禁止替代动态 prop binding"**——不能假设 executor 理解"只改数据来源"语义边界
    - **Why**：A4.2-safe PaginationPage sample executor (Codex) 把 `<Pagination :type="item.type">` 单 instance silent 拆成 `v-if/v-else-if/v-else` 3 分支硬编码 type，违反反模式 #2（打补丁不抽象）+ silent scope creep。Plan owner prompt §0 写"item.type 调用全保留——只改数据来源"对 executor 不够 explicit——它能 rationalize "数据来源没变 v-if 不算改数据来源"
    - **How to apply**：page transform prompt §0 改造裁定段必须 explicit 列：
      - "保留 single `<{Component} :prop="item.{prop}">` instance"
      - "禁止拆分多个 conditional renders (v-if/v-else-if/v-else) 替代动态 prop binding"
      - "如 type widening 担忧 → STOP 报 blocker，不要自由发挥加 type cast 或拆条件渲染"
    - **实证 case**：A4.2-safe PaginationPage sample executor 拆 v-if 3 分支（commit 待 follow-up fix 一并落）；触发器 G "executor 不做加料式评论 / 不发明新轨道" 在 template 层面也适用

11. **boolean / instance-swap component properties 是独立机制层（非 page transform scope）**——发现 figma 真源有这类 property 时入 backlog (BRIDGE-*)，不在当前 page transform sample 内 fix
    - **Why**：A4.2-safe PaginationPage sample 时用户截图揭示 figma Pagination 有 `Show Total` / `Show page size` (Boolean) + `Content` (Instance swap) 三类 component property，但 generator schema 只处理 variant axes。Plan owner 容易把"figma 真源有 X 没渲染"误判为"page transform 漏处理"——实际是 generator schema 设计 gap
    - **How to apply**：page transform sample / batch 视觉验收时如果发现 figma 真源有未导出/未渲染的 component property，**不修 page**——入 backlog (BRIDGE-*)，作为独立 generator + canonical + prop-aliases 三层机制升级。Page transform 只 verify 已 generator 导出的 axis values 是否正确渲染
    - **实证 case**：BRIDGE-005 入 backlog（commit 待 sample 一并落）

12. **grid `cellMinWidth` 必须基于 component 实际渲染宽度**——宽组件 (figma w >~400px) 用 `"100%"`，小组件 (<~200px) 用默认 `176px`
    - **Why**：A4.2-safe PaginationPage sample 用户报 grid 折行——Pagination Classic figma w=652px，默认 cellMinWidth 176px 把 component 强行 squeeze 到 ~233px → 折行不优雅
    - **How to apply**：page transform prompt §0 必须 explicit 列每 page 的 cellMinWidth 决策；plan owner 用 figma MCP get_design_context 拿 component w，决定 100% (≥400px) 还是 176px (<200px) 还是中间值
    - **实证 case**：Pagination Classic w 652 / Small w 628 / Simple w 460 → 100%（commit 待 sample 一并落）；Notification 480px hardcoded → 100%（A4.1 已 commit）

13. **Sample commit 后 plan owner 不发掘 canonical 层 finding 阻塞 commit**——所有非 page-transform-范畴的 finding（spacing / composition / boolean / token 选择）→ 入 backlog 不阻塞 → 后续独立 ticket 排期
    - **Why**：A4.2-safe PaginationPage sample 完成后 plan owner 连续发掘 6 个 canonical 层 finding（v-if 反模式 / cellMinWidth / boolean properties / button composition / spacing mismatch / sub-frame 真源缺失）让用户拍板 → 决策疲劳 + 项目失去线性流程
    - **How to apply**：sample 验过 page transform 范式（5+1 verdict + dev 视觉范式确认）后 → 立刻 commit；canonical 层 finding 静默入 backlog（不打断流程）；只在 dev 视觉验收 + commit 授权时找用户
    - **实证 case**：用户元提醒 "感觉你一直在不停地拆步骤、停步骤，没有完整的流程" → plan owner 必须收口 sample，停止发掘新 findings

15. **Plan owner 改 / 加 canonical token 前必须先 grep canonical 现有定义**——避免"漏看已有 token"错误
    - **Why**：Phase X.2 时 plan owner 错误 propose "canonical 没 effect tokens 需新加 / canonical 没 typography tokens 需新加" — 实际 canonical `variables.css` 早就有 `--shadow-l1/l2/l3 + --mask-overlay`（typography 真无 dedicated token, 全 hardcode）。User 用 docs site 截图 (`/component/effect`) 实证, plan owner 才发现 effect tokens 遗漏。Library-first search discipline 实质强化版
    - **How to apply**：任何"canonical 缺 X token"论断前**必须**:
      1. `grep -nE '<token-name>|<alternative-naming>' src/tokens/variables.css` 全 grep 现有 token
      2. 检查 docs site token-display pages：`/component/effect` / `/component/typography` / `/component/color` / `/component/border`
      3. 实证 0 命中 + docs page 0 列后才能下"缺失"结论
    - **实证 case**: 2026-05-07 Phase X.2 — plan owner 误以为 canonical 没 L1/L2/Mask effect tokens; user 截图 docs `/component/effect` 暴露 `--shadow-l1/l2/l3 + --mask-overlay` 4 token 早存在 → plan owner 重新检查发现真问题是 simplified 单层 vs figma 3-layered → user 后续 export figma Design Tokens plugin 解锁 L1/L2 真源 3-layered values

14. **Plan owner 改 canonical 之前必须 fire Figma MCP `get_design_context` 拿真源数据**——不依赖 figma-data normalized JSON 顶层 only
    - **Why**：figma extract pipeline 当前只抽 COMPONENT 顶层 fills/strokes/layoutMode/gap，sub-node 真源未抽到（T1c PAUSED）。Plan owner 之前被这个局限绑住，每次 canonical alignment 检查都"猜测/标 unknown 等 T1c"，让用户感觉"不智能"——实际上 Figma MCP `get_design_context` 是 live API 直通车，能拿到 sub-node 完整 layout（spacing / padding / fills）+ design tokens + 子组件 hierarchy + 文字 styling
    - **How to apply**：
      1. 任何 canonical refactor / alignment 工作前，**第一步**先 fire `mcp__claude_ai_Figma__get_design_context(fileKey, nodeId)` 拿 figma 真源
      2. Parse 返回的 React+Tailwind 代码：解析 Tailwind class 得到 spacing 真源（如 `gap-[8px]` / `gap-[var(--spacing/xxs,4px)]`）+ token 引用（如 `var(--ux/brand/brand,#2fb54e)`）
      3. 列 canonical vs figma mismatch 表（grounded by MCP）后再写 fix prompt
      4. 不再标 "等 T1c 复活" / "依赖 figma extract pipeline 升级"——MCP 是 live alternative
    - **实证 case**：CANONICAL-006 Pagination 用 MCP 拿到完整 sub-node hierarchy 真源（Classic nav row gap=8 / Small=4 / Simple `<>` 80px justify-between / page button bg/border/font-weight）→ 一次性 grounded 7 mismatch + hierarchy refactor scope（commit 待）
    - **机制 effect**：T1c 复活 priority 降低（不再阻塞 canonical alignment 工作）；Phase X canonical-figma alignment audit 用 MCP 即可执行

---

## 元说明

- 本复盘是 plan owner 主动写（触发器 D 命中：≥ 3 真源 .md 改 + ≥ 5 阶段 + 完成 v2 plan A4.0/A4.1 子任务）
- 新 session 启动时**必读** + 一条 onboarding 任务（fire A4.2 sample prompt）
- 后续 Phase A 整体收口（A4.2/A4.3/A4.4 全 done）时再写一份"Phase A complete"复盘