# Conformance Issue Log

> Redirect note:
> - 新的边界翻译层登记入口：`/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/design-system/translation/`
> - 新的工作原则入口：`/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/docs/working-principles.md`
> - 本文件保留历史问题台账，不再作为未登记差异的唯一事实源。

这份文档是 `tvu-design-system` 项目的**统一问题台账**。

用途只有一个：

- 把在“Figma 设计系统 -> 代码组件 -> 文档站”这条链路里遇到的重复问题、根因、修复方式、可复用规则，持续沉淀到仓库里
- 让跨 Session 的后续工作不依赖聊天上下文
- 作为后续团队内部分享材料的原始积累

## 使用规则

1. 每当确认一个重要问题、阻塞点、修复决策或可复用规则时，优先更新这份文档
2. 不要只记录“改了什么”，还要记录：
   - 现象
   - 根因
   - 修复
   - 可复用规则
3. 对尚未完全解决的问题，也要记录当前状态和下一步
4. 这份文档是项目专属，不是通用模板

## 记录模板

### [编号] 标题

- 日期：
- 影响范围：
- 现象：
- 根因：
- 修复：
- 相关文件：
- 复用规则：
- 当前状态：
- 后续动作：

---

## [001] Button 生成器是手写特例，不是统一主链

- 日期：2026-04-24
- 影响范围：`Button`，以及整个生成链的可信度
- 现象：
  - `figma-sync/generate-vue.mjs` 内置 `BUTTON_SPEC`
  - 内置 `VAR_TO_CSS`
  - 直接写入 `src/components/Button/Button.vue`
- 根因：
  - 生成器最初是围绕单个高频组件快速搭起来的
  - 没有真正退回到 `manifest / canonical spec` 驱动
- 修复：
  - 将 `generate-vue.mjs` 改造成过渡性的 manifest-driven sample contract 生成器
  - 当前只输出：
    - `figma-data/normalized/button-generation-sample.json`
  - 不再直写 runtime Button 代码
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-sync/generate-vue.mjs`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-data/normalized/button-generation-sample.json`
- 复用规则：
  - 不允许把“组件特例生成器”继续当主生成链扩散到其他组件
  - 如果需要试做，只能作为样板工件输出，不直接覆盖运行时代码
- 当前状态：已止血，未最终完成
- 后续动作：
  - 继续把 Button 的正式 canonical/runtime 实现迁回统一契约

## [002] canonical/generated 中存在大量 skeleton wrapper

- 日期：2026-04-24
- 影响范围：canonical 层可信度、公共 API 边界
- 现象：
  - `src/canonical/generated/*.vue` 大量只是 wrapper skeleton
  - 保留 Figma 轴和 `data-figma-*`，但没有完成视觉/结构/行为映射
- 根因：
  - 之前的策略偏向“先生成一层壳，再人工补”
  - 这些壳后来又被误当成完成组件
- 修复：
  - 通过审计显式识别 skeleton
  - `Button` 先从 public boundary 中撤出
  - `src/canonical/index.ts` 不再全量导出 `./generated`
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/canonical/generated`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/canonical/index.ts`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-sync/audit-figma-conformance.mjs`
- 复用规则：
  - skeleton wrapper 不能视为完成组件
  - 未完成的 generated 组件不能进入稳定 canonical 入口
- 当前状态：仍有 15 个 skeleton，public export 泄漏已清零
- 后续动作：
  - 逐个判断 15 个 skeleton 是“晋升为正式 canonical”还是“继续保留为 draft/internal”

## [003] public export 泄漏导致外部误以为 skeleton 已可用

- 日期：2026-04-24
- 影响范围：`src/index.ts`、`install()` 注册、外部使用方认知
- 现象：
  - skeleton generated 组件曾被稳定公共入口导出
  - 外部看起来像正式组件，实际上只是近似实现
- 根因：
  - stable export 与 generated draft 没有明确边界
- 修复：
  - 从 `src/index.ts` 移除剩余 generated skeleton 的稳定导出与注册
  - 审计同时检查 `src/index.ts` 与 `src/canonical/index.ts`
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/index.ts`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/canonical/index.ts`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-sync/audit-figma-conformance.mjs`
- 复用规则：
  - draft / generated 不能通过稳定入口承诺可用性
  - stable export 只允许 hand-completed canonical 组件进入
- 当前状态：已修复
- 后续动作：
  - 后续每次新增 canonical 组件时，先确认其状态，再决定是否进入 stable export

## [004] Button family 混入不属于主 Button 的 member

- 日期：2026-04-24
- 影响范围：`Button` canonical contract
- 现象：
  - `Button/url link` 混进主 `Button` family
  - `rimeless / rimless` 拼写不一致
  - `size` 轴没有正式提升成 canonical 轴
- 根因：
  - family 聚合时过度依赖名称相似性，没有二次规范化
- 修复：
  - 在 `button-generation-sample.json` 中产出 `resolvedContract`
  - 明确：
    - `Button/url link` 应剥离
    - `style` 统一为 `rimless`
    - `size` 从 member family 名提升为 canonical 轴
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-data/normalized/button-generation-sample.json`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-sync/generate-canonical-specs.mjs`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-data/normalized/canonical-components.json`
- 复用规则：
  - family 聚合后必须经过 contract normalization
  - 名称近似不能直接视为同一 canonical family
- 当前状态：contract 已明确，正式实现未完成
- 后续动作：
  - 让 `Button` 的正式 canonical/runtime 实现消费 `resolvedContract`

## [005] Icon 页曾因索引结构读取错误而整页空白

- 日期：2026-04-24
- 影响范围：文档站 `Icon` 页面
- 现象：
  - `Icon` 页面壳体存在，但正文完全空白
- 根因：
  - 已发布图标索引 JSON 的结构实际是 `records` / `exportedAt`
  - 页面曾按 `entries` / `generatedAt` 读取，导致模块初始化报错
- 修复：
  - 修正索引字段读取
  - 增加页面级测试防止静默回归
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/designAssetData.ts`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/tests/IconPage.test.ts`
- 复用规则：
  - 导出数据源接入前，先锁定 JSON 契约
  - 对关键基础页补最小页面测试，避免“页面壳存在但正文挂掉”的隐性错误
- 当前状态：已修复
- 后续动作：
  - 继续把 Icon 页收成按 Figma 分类的真实图标墙

## [006] 站点页数量增加不等于 Figma 对齐程度提升

- 日期：2026-04-24
- 影响范围：整个 docs site
- 现象：
  - 页面数量和导航结构看起来更完整
  - 但 docs-site 审计仍然显示 `approvedComponentPages = 0`
- 根因：
  - 很多页面仍是 `runtime-only`
  - 或仍是 `docs-demo` / `state-grid`
  - 还没有达到 `figma-frame`
- 修复：
  - 引入 docs-site 审计
  - 把页面 completeness 和 pixel parity 分开衡量
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-sync/audit-docs-site-readiness.mjs`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/docs/site-pixel-parity-mechanism.md`
- 复用规则：
  - 文档站“看起来完整”不能当作 conformance 完成
  - 必须把 provenance、implementation、frame fidelity 分开审计
- 当前状态：已纳入机制
- 后续动作：
  - 后续逐组件推进时，优先让页面从 `runtime-only` 晋升到 `figma-frame`

## [007] 剩余 generated skeleton 需要先做“晋升分层”，不能一视同仁

- 日期：2026-04-24
- 影响范围：剩余 15 个 `src/canonical/generated/*`
- 现象：
  - 它们都被 conformance audit 识别为 skeleton
  - 但并不是所有 skeleton 都应该用同一种修法处理
- 根因：
  - 部分组件只是 contract 没收紧
  - 另一些组件本质上是 compound / family / structure 问题
  - 如果不先分层，就会把“该重建的组件”误当成“再补几条 props 就能转正”
- 修复：
  - 新增了机器工件：
    - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-data/normalized/skeleton-promotion-plan.json`
  - 新增了说明文档：
    - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/docs/generated-skeleton-promotion-plan.md`
  - 当前先分成两类：
    - `spec-normalization`
    - `structural-rebuild`
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-sync/generate-skeleton-promotion-plan.mjs`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-data/normalized/skeleton-promotion-plan.json`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/docs/generated-skeleton-promotion-plan.md`
- 复用规则：
  - skeleton 不能只看“有没有 wrapper”
  - 必须先判断它属于：
    - 先修 contract
    - 还是必须先重建结构
- 当前状态：已建立分层机制
- 后续动作：
  - 后续每次处理 skeleton 时，先引用这份晋升计划，再动手实现

## [008] generated wrapper 生成器曾无差别扩散 skeleton

- 日期：2026-04-24
- 影响范围：`figma-sync/generate-canonical-wrappers.mjs`
- 现象：
  - 生成器会把几乎所有 canonical spec 一股脑生成成 wrapper skeleton
  - 即使某些组件已经被判定为 `structural-rebuild`，仍会被继续包一层 generated 壳
- 根因：
  - wrapper 生成器之前只知道：
    - 手工维护组件
    - 非手工维护组件
  - 但不知道“哪些 skeleton 不该继续生成”
- 修复：
  - 新增机器工件：
    - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-data/normalized/skeleton-promotion-plan.json`
  - wrapper 生成器现在会读取晋升计划
  - 当前规则：
    - `Button` 作为 under-repair 样板显式跳过
    - `structural-rebuild` 显式跳过
    - 只保留 `spec-normalization` 候选进入 generated index
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-sync/generate-canonical-wrappers.mjs`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-data/normalized/canonical-wrapper-skeletons.json`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/canonical/generated/index.ts`
- 复用规则：
  - 不能把“所有未完成组件都先生成一层 wrapper”当作默认策略
  - generated wrapper 也必须遵守晋升分层机制
- 当前状态：已修复
- 后续动作：
  - 后续继续把 6 个 `spec-normalization` 候选逐个拉回真正 canonical

## [009] conformance 审计需要覆盖 generated index 规则

- 日期：2026-04-24
- 影响范围：`audit:figma-conformance`
- 现象：
  - 即使 public stable export 已收紧，如果 `src/canonical/generated/index.ts` 仍继续导出：
    - `Button`
    - `structural-rebuild` 组件
  - 生成体系仍会悄悄把错误实现继续扩散给内部使用方
- 根因：
  - 之前审计只检查：
    - `src/index.ts`
    - `src/canonical/index.ts`
  - 没有检查 generated index 是否遵守晋升计划
- 修复：
  - 审计器新增：
    - `generated/index.ts` 对晋升计划的校验
  - 当前会显式检查：
    - `Button` 是否仍被 re-export
    - `structural-rebuild` 组件是否仍被 re-export
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-sync/audit-figma-conformance.mjs`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/canonical/generated/index.ts`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-data/normalized/skeleton-promotion-plan.json`
- 复用规则：
  - 审计不仅要看 stable public API，也要看 generated 入口是否违背当前晋升边界
- 当前状态：已修复
- 后续动作：
  - 每次调整晋升计划后，都应复跑 `pnpm audit:figma-conformance`

## [010] Button 主 canonical spec 不能只在 resolvedContract 中“口头纠偏”

- 日期：2026-04-24
- 影响范围：`Button` canonical spec
- 现象：
  - 之前虽然 `resolvedContract` 已说明要排除 `Button/url link`
  - 但主 spec 本身仍保留：
    - `memberCount = 9`
    - `members` 里仍含 `Button/url link`
- 根因：
  - contract 纠偏只停留在附加说明层，没有真正写回主 spec 的成员集合
- 修复：
  - `generate-canonical-specs.mjs` 现在会把 `resolvedContract.excludedMembers` 实际应用到主 spec
  - 当前 `Button` 主 spec 已变成：
    - `memberCount = 8`
    - `rawMemberCount = 9`
    - `Button/url link` 只保留在 `excludedMembers`
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-sync/generate-canonical-specs.mjs`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-data/normalized/canonical-components.json`
- 复用规则：
  - 任何 `resolvedContract` 里的 family split 结论，最终都必须真正反映到主 canonical spec，而不能只停留在备注层
- 当前状态：已进一步推进
- 继续修复结果：
  - `src/components/Button/Button.vue` 已升级成 dual-stack runtime bridge
  - `src/canonical/ButtonBridge.vue` 已不再只是 `data-figma-*` 占位 wrapper
  - `Button` 已从 skeleton conformance 计数中移出
- 尚未完成：
  - `fixedWidth` 仍是 bridge-level 宽度策略，不是 Figma 校准值
  - `icon=left/right/light` 尚未接入正式图标资产
  - 红/橙 filling 与部分 ghost/rimless 仍是 bridge-level token 映射
- 后续动作：
  - 下一步继续处理 `fixedWidth`、icon asset 接入、以及 Button 像素级校准

## [011] Button 需要先变成 canonical bridge，不能长期停留在 data-figma wrapper

- 现象：
  - `src/canonical/ButtonBridge.vue` 虽然已经保留了 Figma 轴
  - 但之前只是把这些轴挂成 `data-figma-*`
  - 没有真正映射到 runtime Button 的行为和视觉

- 根因：
  - canonical wrapper 与 runtime Button 之间没有明确 bridge contract
  - 导致 wrapper 看起来“像 canonical”，其实只是占位

- 修复策略：
  - 先把 runtime Button 升级成 dual-stack bridge
  - 同时接受 legacy API 和 canonical bridge props
  - 再让 `src/canonical/ButtonBridge.vue` 只负责 canonical 轴透传，不再重复发明第二套实现

- 已落地文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/components/Button/Button.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/canonical/ButtonBridge.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/tests/Button.test.ts`

- 当前结论：
  - Button 已从 `wrapper skeleton` 推进到 `non-public canonical bridge`
  - 这仍然不是 pixel-perfect 完成态，但已经不再属于“只会挂 data attrs 的空桥”

## [012] Button bridge 必须开始消费 icon / fixedWidth 这类强视觉轴

- 日期：2026-04-24
- 影响范围：`Button` runtime、canonical draft、后续所有 canonical bridge 组件
- 现象：
  - 如果 runtime 不消费 `icon` / `fixedWidth`，那 canonical draft 即使有了 `resolvedContract`，也仍然只是半成品
  - 视觉上最明显的桥接断层，通常正好就出在这类轴上

- 根因：
  - 第一轮修复优先切断了生成器扩散和 public export 泄漏
  - 但还没有把关键 canonical 轴真正落到 runtime 行为

- 修复：
  - `src/components/Button/Button.vue` 已接入运行时 `Icon` 组件
  - `left / right / loading / loading button / light` 已开始映射到真实图标资产
  - `fixedWidth` 已从粗略的 `size -> width` 单值映射改成 `size × icon-presence × fixedWidth` 的桥接桶化策略
  - `Button` 的 canonical draft 也已从 `src/canonical/generated` 移到 `src/canonical/ButtonBridge.vue`，避免继续混淆 generated skeleton 与手工 bridge

- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/components/Button/Button.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/icons/index.ts`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/canonical/ButtonBridge.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/tests/Button.test.ts`

- 复用规则：
  - canonical bridge 不能只把 Figma 轴挂成 `data-figma-*`
  - 至少要优先消费会直接改变视觉/结构的轴，例如：
    - `icon`
    - `size`
    - `fixedWidth`
    - `status`

- 当前状态：已推进到 runtime bridge 层，未完成 pixel parity
- 后续动作：
  - 继续收 `Button` 的 bridge-level 宽度和 icon 策略
  - 再决定 `Button` 何时能从 non-public bridge 晋升为正式实现

## [013] Button 不能只修底层 contract，必须有可视化 bridge 审核页

- 日期：2026-04-24
- 影响范围：`Button` 样板链、后续组件复制策略
- 现象：
  - 底层生成链和 runtime bridge 已连续推进
  - 但如果文档页仍停留在旧的 runtime-only demo，使用方看不到修复效果
  - 这会造成“底层修了很多，但页面没有明显差异”的误判

- 根因：
  - 之前的推进顺序偏向先修 contract，再晚一点做展示
  - 对当前项目来说，这种顺序会让样板组件缺少及时的人眼评估入口

- 修复：
  - `playground/docs/pages/ButtonPage.vue` 已改成 canonical bridge 可视化验证页
  - 页面现在直接展示：
    - `Family Contract`
    - `Geometry Contract`
    - `State & Icon Review`

- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/ButtonPage.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/components/Button/Button.vue`

- 复用规则：
  - 当某个组件被选为“样板链”时，不能只修到底层 contract
  - 必须同步提供一个可视化验证页，让桥接效果能被立即判断
  - 只有样板页看起来成立，才值得复制到下一个组件

- 当前状态：已修复
- 后续动作：
  - 先对 Button 页面做人工观感确认
  - 确认通过后，再把同样的“bridge 页面先行”模式复制到下一个组件

## [014] 全局 install / prepare 仍会被剩余 generated skeleton 的类型问题卡住

- 日期：2026-04-24
- 影响范围：依赖安装、全量类型检查、构建前验证
- 现象：
  - `pnpm test` 已能正常运行
  - 但 `CI=true pnpm install` 触发的 `prepare` 仍会在 `vue-tsc --noEmit && vite build` 阶段失败
  - 暴露出的错误主要来自剩余 generated skeleton 的错误导入和缺失必填 props

- 根因：
  - conformance audit 虽然已经把 public export 和 generator 特例问题收住
  - 但剩余 15 个 generated skeleton 依然同时承担了：
    - 错误相对路径

## [027] Button Loading 的 Figma 规则被误读，导致页面虽然更新了，但结论和展示方式仍不对

- 日期：2026-04-24
- 影响范围：`Button` runtime bridge、`ButtonPage` 的 `Loading Buttons` 审核区
- 现象：
  - 页面里 `red/orange` 的 loading 视觉曾被错误地解释成“浅底禁用态”
  - 后续虽然改回了饱和色，但审核页面仍然让人一眼看不清它和 Figma 原始 loading 子集的对应关系
  - 用户明确指出：Figma 原始 loading 长得像截图那样，当前页面的 review 组织方式仍然不够直观
- 根因：
  - 前面把“loading 是否接近 disable”过度总结成了一条统一规则
  - 没有先严格按 `Button/dark M` 的真实 loading 成员，把页面直接做成 Figma-first 的展示
  - 在 review 页面上，我先优化了 contract / API / section 命名，而没有先把 loading 这块做成最直接可核对的矩阵
- 修复：
  - 明确撤销“所有颜色都等于禁用态 + loading 图标”的笼统结论
  - 当前只保留这个更窄的结论：
    - `green / gray 1` 的 loading 更接近 disable 视觉
    - `red / orange` 的 loading 保持饱和色
  - 下一步不再优先改运行时解释，而是优先把 `ButtonPage.vue` 的 loading review 直接按 Figma 原始 loading 子集重排
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-data/raw/components/button_dark_m__1545_51964.json`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/ButtonPage.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/components/Button/Button.vue`
- 复用规则：
  - 对高频组件，先把“按 Figma 真实变体直接展示清楚”做好，再做更深的 bridge / API / contract 抽象
  - 如果页面已经让审核者看不清对应关系，就不能算完成，即使底层数据和 API 已经部分正确
- 当前状态：未完成
- 后续动作：
  - 先重做 `Button` 页的 `Loading Buttons` 审核区，让它严格按 Figma 原始 loading 成员组织
  - 用户确认 `Button` 页面看得懂、效果对之后，再复制到下一个组件
    - 缺少运行时必填 props
    - 未完成的桥接契约

- 修复：
  - 当前先恢复了 `pnpm test` 的可用性，保证 Button 主线仍能继续验证
  - `prepare` 暂未在这一轮一起修，因为这属于剩余 generated skeleton 的集中债务，不应该混进 Button 样板链

- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/canonical/generated/*`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/docs/generated-skeleton-promotion-plan.md`

- 复用规则：
  - `pnpm test` 通过不等于全局构建链已经健康
  - 只要 `prepare` 仍被 generated skeleton 卡住，就说明剩余 canonical 债务还没有出清

- 当前状态：已记录为独立阻塞
- 后续动作：
  - 等 Button 样板链确认通过后，按晋升计划逐个清理剩余 generated skeleton 的类型与契约问题

## [015] Button 页面如果不先显式列出 Figma M 轴，审核者无法一眼判断“除了 size 是否都覆盖了”

- 日期：2026-04-24
- 影响范围：`Button` 文档页、Button bridge 审核流程
- 现象：
  - 即使 `Button` 页面已经开始显示 bridge 效果
  - 如果不先列出 `Button/dark M` 的真实导出轴和值，审核者仍然很难判断：
    - 当前页面对应的是不是正确的 Figma 组件集
    - 除了 `size` 之外是不是已经把其他原生轴都摆出来了
    - 哪些项目是 bridge 特例，不属于当前 M 组件集的原生值

- 根因：
  - 页面先摆 demo，再解释来源
  - 缺少“Figma 原始轴 → 当前页面覆盖范围”的显式映射层

- 修复：
  - 在 `ButtonPage.vue` 顶部新增 `Figma M Coverage`
  - 直接展示 `Button/dark M` 的 6 条非 `size` 轴及值域：
    - `icon`
    - `style`
    - `color`
    - `status`
    - `radius`
    - `fixed width`
  - 明确声明：
    - 当前页面已覆盖全部非 `size` 轴
    - `size` 刻意留作后续单独审查
    - `Button/light M` 的 `rimeless` / `Radius` 属于源命名漂移
    - `light` 图标资源不是 `Button/dark M` 的原生 `icon` 值，不应继续放在 M family 原生覆盖区

- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/ButtonPage.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/docs/figma-conformance-first.md`

- 复用规则：
  - 进入像素级校对前，文档页必须先显式回答：
    - 当前页面对应的是哪个 Figma 组件集
    - 当前展示覆盖了哪些原生轴
    - 哪些 bridge 特例被刻意排除在原生覆盖区之外

- 当前状态：已修复

## [016] 页面顶部列出 Figma 轴，不等于页面下方展示已经按这些轴来组织

- 日期：2026-04-24
- 影响范围：`Button` 页面、后续所有组件审核页
- 现象：
  - 页面顶部已经能正确列出 `Button/dark M` 的原始轴和值
  - 但如果下面的 demo 仍按 `Family / Geometry / State` 这种二次分类展示
  - 审核者仍然会感觉“属性获取对了，但下面展示结果没有按这些分类来展示”

- 根因：
  - 展示层没有和 Figma 原始轴保持同一层级
  - 上层列轴、下层换概念，导致信息结构前后不一致

- 修复：
  - 将 `ButtonPage.vue` 的主审核区改成 `Axis-by-Axis Review`
  - 按 `Button/dark M` 的真实轴顺序逐段展示：
    - `style`
    - `color`
    - `status`
    - `radius`
    - `fixed width`
    - `icon`

- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/ButtonPage.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/docs/figma-conformance-first.md`

- 复用规则：
  - 如果页面顶部先列出 Figma 原始轴
  - 页面下方的主审核区也必须按同一组轴逐段对应展示
  - 不能再把主审核内容重新打散成不在 Figma 中显式存在的二次分类

- 当前状态：已修复

## [017] 组件页如果只有视觉审核，没有开发引用说明，后续开发仍然不知道怎么接入

- 日期：2026-04-24
- 影响范围：`Button` 页面、后续所有组件页
- 现象：
  - 页面即使已经能按 Figma 轴展示视觉结果
  - 开发仍然不知道：
    - 当前该如何引用这个组件
    - 当前有哪些属性
    - 当前有哪些插槽
    - 这是不是稳定公开 API

- 根因：
  - 页面过度偏向“视觉审核”
  - 缺少像 Element 那样的“示例 + 用法 + API”统一结构

- 修复：
  - 在 `ButtonPage.vue` 新增：
    - `Development Usage`
    - `Button API`
      - `Button Attributes`
      - `Button Slots`
  - 明确把当前 bridge 引用方式和“未稳定公开”状态写清楚

- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/ButtonPage.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/docs/figma-conformance-first.md`

- 复用规则：
  - 进入审核阶段的组件页，至少应同时具备：
    - 视觉展示
    - 开发引用方式
    - API / Slots 说明
  - 并明确区分：
    - 稳定公开 API
    - 仅供当前项目审核使用的 bridge 引用

- 当前状态：已修复

## [018] Review 模块如果嵌套层级太深，哪怕轴和值正确，也仍然不像 Element 那样清楚

- 日期：2026-04-24
- 影响范围：`Button` 页面、后续所有组件审核页
- 现象：
  - 即使页面已经按 Figma 轴展示内容
  - 如果这些审核项都被包在一个大 section 里，再套多层 subsection / card
  - 视觉上仍然会显得“有点乱”，不如 Element 的一节一节清楚

- 根因：
  - Review 区块的层级过深
  - 缺少 Element 那种“每一节一个标题、一句说明、一个 demo 面板”的文档节奏

- 修复：
  - 将 `ButtonPage.vue` 的 Review 模块改成：
    - 每个轴一个独立 section
    - 每个 section 只有：
      - 标题
      - 简短说明
      - 一个统一 demo 面板
  - 去掉 Review 主区块里过深的 subsection 嵌套

- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/ButtonPage.vue`

- 复用规则：
  - 审核页的 review 区块，不应只是“数据对”
  - 还必须满足：
    - 结构浅
    - 每节语义单一
    - 一眼可扫读
  - 默认优先采用接近 Element 的节级组织方式

- 当前状态：已修复

## [019] Loading 按钮如果不按 Figma 的真实 loading 子集组织，审核会误以为 loading 还没对齐

- 日期：2026-04-24
- 影响范围：`Button` 页面、后续带 loading 态的组件页
- 现象：
  - 审核者对 Loading 的预期是：
    - 先看颜色
    - 再看 loading 这个状态
    - 再看有没有图标
    - 再看是否圆角
  - 如果页面只是把 loading 当作普通状态卡片之一，就很难看出：
    - 哪些 loading 组合是 Figma 真实存在的
    - 哪些组合根本不存在

- 根因：
  - loading 其实是 `Button/dark M` 的一个真实子集
  - 但页面之前没有按这个子集单独组织，而是把它和普通状态示例混在一起

- 修复：
  - `ButtonPage.vue` 新增独立的 `Loading Review`
  - 按 Figma 真实 loading 子集做矩阵：
    - 行：`color`
    - 列：
      - `square / filling`
      - `square / ghost`
      - `square / rimless`
      - `round / filling`
      - `round / ghost`
  - 并明确说明：
    - `status=loading`
    - `icon=loading`
    - `size=M`
    - `fixed width=yes`
    - `round + rimless + loading` 不属于当前 M 组件集

- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/ButtonPage.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/docs/figma-conformance-first.md`

- 复用规则：
  - 如果某个状态在 Figma 中本身就是一个有明显组合边界的“真实子集”
  - 页面应优先按这个子集单独组织，而不是塞回普通状态示例

- 当前状态：已修复

## [020] Loading 视觉如果不直接复用对应禁用态 palette，会让审核者误判颜色仍未对齐

- 日期：2026-04-24
- 影响范围：`Button`，后续所有带 loading 态的组件
- 现象：
  - 页面结构已经更清楚了
  - 但审核者仍会指出：
    - Loading 按钮看起来不对
    - 预期应该是“带 loading 图标的各个颜色禁用状态”

- 根因：
  - 实现层把 `loading` 视为单独状态
  - 但 Figma 的真实视觉不是“新一套 loading palette”
  - 而是：
    - 同组合下的 `disable` palette
    - 加上 loading 图标

- 修复：
  - `src/components/Button/Button.vue`
  - 将 `status=loading` 的 palette 映射改成直接走 `disable`
  - 保留 loading 图标和禁用交互语义，不再发明额外颜色

- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/components/Button/Button.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/tests/Button.test.ts`

- 复用规则：
  - 对于 Figma 中“loading 看起来像 disabled + spinner”的组件
  - 实现层应优先复用对应禁用态 palette
  - 不要另造一套 loading 专属颜色

- 当前状态：已修复

## [021] Review 模块的 section 顺序如果不符合审阅心智，即使数据对了也会显得不清楚

- 日期：2026-04-24
- 影响范围：`Button`，后续所有审核页
- 现象：
  - 数据和 API 已经对了
  - 但审核者仍认为：
    - Review 模块不像 Element 那样清楚
    - 顺序不够符合“先看颜色、再看状态、再看图标、再看 loading、再看圆角和尺寸”的心智

- 根因：
  - 页面虽然覆盖了所有轴
  - 但 section 排序仍是从实现者角度出发，不是从审核者阅读顺序出发

- 修复：
  - `ButtonPage.vue` 的 review 顺序改成：
    1. `Basic Usage`
    2. `Color Axis`
    3. `Status Axis`
    4. `Icon Review`
    5. `Loading Review`
    6. `Radius Axis`
    7. `Size Review`
    8. `Fixed Width Axis`

- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/ButtonPage.vue`

- 复用规则：
  - 组件审核页除了“数据覆盖正确”之外
  - 还必须按更接近审核者阅读顺序的方式排列 section
  - 默认优先参考 Element 那种：
    - 基础用法
    - 颜色 / 状态
    - 图标 / loading
    - 形态 / 尺寸

- 当前状态：已修复

## [022] Review 节名如果仍然是实现者术语，页面读起来会不如 Element 清楚

- 日期：2026-04-24
- 影响范围：`Button`，后续所有组件审核页
- 现象：
  - 即使 section 顺序已经更合理
  - 如果标题仍然写成：
    - `Color Axis`
    - `Status Axis`
    - `Radius Axis`
  - 审核体验仍然偏“实现者语言”，不够像 Element 这种组件文档页

- 根因：
  - 页面还停留在“按轴命名”的审计心智
  - 而不是“按组件展示主题命名”的文档心智

- 修复：
  - `ButtonPage.vue` 将 review 节名改成更接近组件文档的形式：
    - `Basic Usage`
    - `Color Buttons`
    - `Status Buttons`
    - `Icon Buttons`
    - `Loading Buttons`
    - `Round Buttons`
    - `Button Sizes`
    - `Fixed Width Buttons`
  - 同时把样例区从较重的卡片网格，改成更轻量的统一 demo wall

- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/ButtonPage.vue`

- 复用规则：
  - 审核页的 section title 不应只反映“实现轴”
  - 还应尽量接近开发文档的阅读习惯
  - 默认优先采用：
    - `Basic Usage`
    - `Color / Status / Icon / Loading`
    - `Round / Size / Fixed Width`

- 当前状态：已修复

## [023] Review 模块如果只换标题、不换 demo 组织方式，仍然不够像 Element

- 日期：2026-04-24
- 影响范围：`Button`，后续所有组件审核页
- 现象：
  - 即使 section 名称和顺序已经更接近 Element
  - 如果 demo 仍然是散卡片式 `review wall`
  - 审核者还是很难一眼看出：
    - 这一节在比较哪一条轴
    - 同一轴下哪些值是横向对比关系
- 根因：
  - 页面只学到了“标题命名”
  - 没学到 Element 那种：
    - 一节一个主题
    - 一块 demo 面板
    - 左侧标签、右侧实例
- 修复：
  - `ButtonPage.vue` 的 review demo 从散卡片改成：
    - 左侧轴标签
    - 右侧横向实例
    - 每节一块独立 demo 面板
  - `fixed width` 再拆成：
    - `text`
    - `with icon`
  - `status` 和 `icon` 也各自只保留一条单一审核主线
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/ButtonPage.vue`
- 复用规则：
  - Review 模块不能只做到“数据正确”
  - 还必须做到：
    - 一节只审核一条主轴
    - 左侧有清晰标签
    - 右侧是同轴横向对比
    - 默认优先采用更接近 Element 的 demo panel 结构
- 当前状态：已修复

## [024] Button 的 loading 和 fixedWidth 不能只在页面上解释，必须回写到运行时实现

- 日期：2026-04-24
- 影响范围：`Button` runtime bridge、后续所有 Figma-first 组件
- 现象：
  - 页面上已经说明：
    - loading 应复用禁用态 palette
    - fixedWidth=no 应该是真正自适应
  - 但如果 runtime 里仍然：
    - 把 loading 当独立 palette
    - 或给 `fixedWidth=no` 继续塞 width bucket 的 `min-width`
  - 页面展示和实际组件行为还是会分叉
- 根因：
  - 之前优先修的是 review 契约和文档结构
  - 运行时 bridge 还有遗留近似逻辑
- 修复：
  - `src/components/Button/Button.vue`
    - `loading` 映射到 `disable` palette
    - `fixedWidth=no` 不再复用 bucket 作为 `min-width`
    - `XS/S/M/L` 的高度、字号、行高、square radius 收到更接近 Figma 的几何值
  - `tests/Button.test.ts`
    - 增加 `fixedWidth=no` 的自适应断言
    - 增加 `loading=disable palette` 断言
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/components/Button/Button.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/tests/Button.test.ts`
- 复用规则：
  - 文档结论不能只停在页面层
  - 只要某条 review 规则已经确认，就必须同步回 runtime bridge 和测试
- 当前状态：已修复

## [025] 全量构建仍会被遗留 generated skeleton 的类型错误拦住，不能误判成 Button 回归失败

- 日期：2026-04-24
- 影响范围：仓库全量 `prepare/build`、后续 Button 样板验收流程
- 现象：
  - `pnpm install` 重新补齐依赖后，`prepare` 会自动执行 `vue-tsc --noEmit && vite build`
  - 构建失败，但失败点不在 `Button`
  - 失败主要来自：
    - `src/canonical/generated/*` 的错误导入路径
    - 缺失必填 props 的 skeleton wrapper
    - `SelectBoxBase.vue` 的既有类型不匹配
- 根因：
  - 仓库还存在一批未晋升的 generated skeleton
  - 它们本来就不满足稳定构建要求
  - 这会掩盖当前 Button 改动是否真的通过
- 修复：
  - 先用定向测试验证当前 Button 链：
    - `pnpm exec vitest run tests/Button.test.ts`
  - 当前结果：
    - `16 passed`
  - 同时把“全量构建失败不等于 Button 回归失败”写回 docs
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/tests/Button.test.ts`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/canonical/generated`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/canonical/SelectBoxBase.vue`
- 复用规则：
  - 在 generated skeleton 尚未清零前，Button 样板链要优先看定向测试
  - 不要把 unrelated generated 构建错误误判成当前样板回归失败
- 当前状态：已确认，待后续逐项清理 generated skeleton

## [026] 不能把 Button 的 loading 简化成“所有颜色都等于禁用态”

- 日期：2026-04-24
- 影响范围：`Button` runtime bridge、`ButtonPage` 的 Loading Review
- 现象：
  - 页面里把 loading 解释成“各颜色的禁用态 + loading 图标”
  - 但实际 Figma `Button/dark M` 里：
    - `green` / `gray 1` 的 loading 视觉接近 disable
    - `red` / `orange` 的 loading 仍保持饱和色
  - 结果就是页面上 `red/orange` 曾错误显示成浅底
- 根因：
  - 我把一个局部规律（green/gray1）错误推广成了全体规律
  - 没直接回到 `button_dark_m__1545_51964.json` 的 loading member 去核对
- 修复：
  - `src/components/Button/Button.vue`
    - `filling.red.disable` 改回 `var(--red)` + `var(--text-primary-btn)`
    - `filling.orange.disable` 改回 `var(--orange)` + `var(--text-primary-btn)`
    - `ghost.orange.disable` 改回 `var(--orange)`
    - `rimless.orange.disable` 改回 `var(--orange)`
  - `ButtonPage.vue`
    - 修正 Loading Review 说明文案，不再把它写成“所有颜色都等于禁用态”
  - `tests/Button.test.ts`
    - 增加 red/orange loading 的定向断言
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/components/Button/Button.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/ButtonPage.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/tests/Button.test.ts`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-data/raw/components/button_dark_m__1545_51964.json`
- 复用规则：
  - Figma 子集规律不能只凭一组颜色推广到所有颜色
  - 尤其是 Button 这种 family，必须按真实 member 逐组核对
- 当前状态：已修复

## [027] ButtonPage 的 loading review 必须保留 Button/dark M 的 40 个原始成员

- 日期：2026-04-24
- 影响范围：`ButtonPage.vue` 的 Loading Buttons review
- 现象：
  - 页面之前只摆出了一张 `fixed width=yes` 的 loading 矩阵
  - 实际 `Button/dark M` 在 Figma 里有 `40` 个 loading 成员：
    - `fixed width=yes` 20 个
    - `fixed width=no` 20 个
  - 因此页面会漏掉整组 `fixed width=no`，也不适合逐成员和 Figma 对照
- 根因：
  - 页面是按人工裁剪后的组合矩阵来展示 loading
  - 没有把“审核页必须先保留原始成员全集”当成第一优先级
- 修复：
  - `ButtonPage.vue`
    - 改成严格按 `Button/dark M` 的 40 个原始 loading 成员渲染
    - 按 `fixed width=yes/no` 分成两组矩阵
    - 每个格子显式显示：
      - `figmaVariantName`
      - `nodeId`
  - `tests/ButtonPage.test.ts`
    - 新增页面测试，锁定 loading review 必须渲染 40 个原始成员
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/ButtonPage.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/tests/ButtonPage.test.ts`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-data/raw/components/button_dark_m__1545_51964.json`
- 复用规则：
  - 只要页面目标是“让人直接对照 Figma 原始成员核对”，就不能再先裁剪展示集合
  - 应优先保留：
    - 原始成员全集
    - 原始成员命名
    - 最小可回溯 provenance
- 当前状态：已修复

## [028] Button loading 的主轴与颜色变量基本导出正确，但部分容器级样式疑似在提取链里丢失

- 日期：2026-04-24
- 影响范围：`Button/dark M` loading members，尤其是 ghost loading 的视觉还原
- 现象：
  - 直接对照 Figma 节点 `1545:51964` 可见：
    - `337:12307` (`green filling loading square yes`) 使用 `UX/Brand/Disable`
    - `337:12819` (`red ghost loading round no`) 保持 `UX/Red/Default`
    - `337:12819` 同时带有整体 `opacity: 40%`
  - 本地导出的 raw / tokenized JSON 中：
    - loading 成员名和主要颜色变量是对的
    - 但 `337:12819` 没有记录容器级 `opacity`
- 根因：
  - 当前问题更像是提取链没有把某些 node-level 样式字段持久化下来
  - 不是 Button/loading 的成员轴或颜色 token 在 family 聚合时被解析错了
- 修复：
  - 当前先按已确认正确的成员名与 token 继续页面核对
  - 检查 `figma-sync/extract.mjs` 后确认：
    - 提取器之前确实没有持久化 node `opacity / visible / blendMode`
  - 已在 `extract.mjs` 中补上这些容器级字段
  - 已重新执行：
    - `pnpm sync:extract`
    - `pnpm generate:component-tokens`
  - 复核结果：
    - `337:12819` 的 raw / tokenized JSON 现已带上 `opacity: 0.4`
  - `src/components/Button/Button.vue`
    - 已开始消费这条容器级 opacity 规律
    - 当前先按 `Button M` 已确认的真实成员规律落地：
      - `status=disable|loading` 且 `color=red|orange` => `opacity: 0.4`
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-sync/extract.mjs`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/components/Button/Button.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/tests/Button.test.ts`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-data/raw/components/icon_loading_style_ghost_color_red_status_loading_radius_round_fixed_width_no__337_12819.json`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-data/normalized/components-tokenized/icon_loading_style_ghost_color_red_status_loading_radius_round_fixed_width_no__337_12819.json`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-data/normalized/components-tokenized/icon_loading_style_filling_color_green_status_loading_radius_square_fixed_width_yes__337_12307.json`
- 复用规则：
  - 如果 Figma 本体和本地 tokenized JSON 在“成员名 + 主变量”上一致，但视觉仍差一层，就要优先怀疑 node-level 样式字段丢失
  - 先修提取器，再重导；不要把“重导一次试试”当成第一修法
- 当前状态：已修复

## [029] Button 的 `left/right` 不是方向箭头语义，而是同一个 Dropdown 图标的左右摆位

- 日期：2026-04-24
- 影响范围：`Button` runtime bridge、`ButtonPage` 的 icon review
- 现象：
  - 页面和运行时之前把 `canonicalIcon='left' | 'right'` 桥接成了 `arrow-left` / `arrow-right`
  - 但 Figma `Button/dark M` 的代表成员显示：
    - `1421:27709` (`icon=left`) 使用的是 `icon/Arrow/Dropdown`
    - `391:15140` (`icon=right`) 也使用同一个 `icon/Arrow/Dropdown`
  - 它们的区别不是图标朝向，而只是图标在文字前还是文字后
- 根因：
  - 我把 `left/right` 误读成了“方向”
  - 实际它们在 Button family 里表达的是“位置”
- 修复：
  - `src/components/Button/Button.vue`
    - `left` 改为桥接 `arrow-dropdown` 前置
    - `right` 改为桥接 `arrow-dropdown` 后置
  - `playground/docs/pages/ButtonPage.vue`
    - 更新 icon review 文案，明确 left/right 是同一 Dropdown 资产的不同摆位
  - `tests/Button.test.ts`
    - 更新左图标断言
    - 新增右图标断言
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/components/Button/Button.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/ButtonPage.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/tests/Button.test.ts`
- 复用规则：
  - Button family 里的 icon axis 不能仅凭值名猜语义
  - 必须回到真实 member 看它表达的是“图标资产变化”还是“同一资产的布局变化”
- 当前状态：已修复

## [030] Button runtime 之前仍按 square 几何渲染 round/icon 成员，ghost 描边也没有消费 Figma 的 1.2px

- 日期：2026-04-24
- 影响范围：`Button` runtime bridge，尤其是 `Button/dark M` 的 icon 成员和 round 成员
- 现象：
  - `ButtonPage` 的 `Icon Buttons` 在 loading/icon 语义修正后，整体仍比 Figma 偏窄
  - 继续核 `Button/dark M` 原始成员后确认：
    - `radius=round` 的 `M` 成员使用 `pH/pR=20`，不是 square 的 `16`
    - `fixed width=yes` 的 `M round`：
      - 文本按钮宽度 `84`
      - 带图标按钮宽度 `104`
    - `style=ghost` 成员使用 `strokeWeight=1.2`
  - 运行时此前仍是：
    - round / square 共用同一组固定宽度
    - 所有样式都用 `1px` border
    - 没有消费 size/radius 对应的真实 horizontal padding
- 根因：
  - 之前只把 token 和 icon 语义接上了
  - 但还没有把 Figma 成员的几何参数桥接进 runtime
- 修复：
  - `src/components/Button/Button.vue`
    - 固定宽度桶改为按 `size + radius + icon-presence` 取值
    - 补上 `paddingSquare / paddingRound / iconGap / radiusRound`
    - ghost 改为消费 `border-width: 1.2px`
  - `tests/Button.test.ts`
    - 新增 round `M` 固定宽度断言
    - 新增 ghost `stroke width / gap / round radius` 断言
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/components/Button/Button.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/tests/Button.test.ts`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-data/raw/components/button_dark_m__1545_51964.json`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-data/raw/components/button_dark_l__1545_51854.json`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-data/raw/components/button_dark_s__1545_57246.json`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-data/raw/components/button_dark_xs__1545_57247.json`
- 复用规则：
  - Button 这类 family 不只要对 token 和 icon 轴做语义桥接
  - 还要显式消费 member 级的几何字段：
    - `padding`
    - `fixed width`
    - `gap`
    - `strokeWeight`
- 当前状态：已修复

## [031] ButtonPage 的状态/圆角审核区块不能混入额外轴，否则会削弱和 Figma 原始成员的逐眼对照

- 日期：2026-04-24
- 影响范围：`ButtonPage.vue` 的 `Status Buttons`、`Icon Buttons`、`Round Buttons`
- 现象：
  - `Status Buttons` 之前把 `disable` 放成了左图标成员，导致人在看状态时同时被 icon 轴干扰
  - `Icon Buttons` 之前仍用 `ghost + green` 作为基线，和正在对照的 filling 成员不一致
  - `Round Buttons` 之前只放了 `filling + green` 的 square/round，对 `ghost` 与 `disable` 场景覆盖不够
- 根因：
  - 页面示例虽然能跑通 runtime，但没有始终坚持“每个审核区块只收一个主要变量轴”
- 修复：
  - `Status Buttons`
    - 改成同一条 `green filling M` 纯文字基线比 `default / hover / disable`
    - 把 `loading` 降成一个单独的 handoff 样例，完整核对仍交给下面的 loading review
  - `Icon Buttons`
    - 改成 `green filling M` 基线，直接对照 Figma 原始 left/right filling 成员
  - 新增 `Hover Buttons`
    - 单独比较 `hover` 下的 `filling / ghost / rimless`
  - 新增 `Disable Buttons`
    - 单独摊开四种颜色在三种 style 下的 `disable`，把 red/orange 的 opacity 规则显式展示出来
  - `Round Buttons`
    - 扩成 `default` 和 `disable` 两行
    - 同时对比 `filling / ghost` 的 `square / round`
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/ButtonPage.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/tests/ButtonPage.test.ts`
- 复用规则：
  - 如果页面目标是“让人一眼核对 Figma”，每个审核区块都应尽量只变化一个主要轴
  - 如果某个状态天然需要额外语义（比如 loading），应把它单独下沉到专门 review，而不是和普通状态并列混放
- 当前状态：已修复

## [032] Hover 不应该只作为静态样例单独陈列，ButtonPage 上的 default 成员应支持直接悬停预览真实 hover member

- 日期：2026-04-24
- 影响范围：`ButtonPage.vue` 的默认态审核区块
- 现象：
  - 虽然页面里已经有单独的 hover 审核区块，但实际核对交互时仍然需要在脑中来回切换“默认按钮”和“hover 按钮”
  - 对设计核对来说，这不如直接把鼠标放到同一个按钮上查看 hover 反馈直观
- 根因：
  - Button runtime 的 hover 目前主要靠 `canonicalStatus='hover'` 静态驱动
  - 文档页没有把 default 成员和 hover member 做成交互式桥接
- 修复：
  - `ButtonPage.vue`
    - 移除单独的 `Hover Buttons` 区块
    - 默认态样例在文档页中支持直接悬停 / focus 进入真实 hover member
    - 在可悬停区块上方增加提示文案
  - `tests/ButtonPage.test.ts`
    - 更新页面断言，锁定 hover 交互提示存在
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/ButtonPage.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/tests/ButtonPage.test.ts`
- 复用规则：
  - 对 `hover` 这类纯交互状态，文档页优先提供“同按钮直接悬停预览”
  - 只有当 hover 需要单独隔离多个变量轴时，才再补一个静态 hover 审核区块
- 当前状态：已修复

## [033] Button 的 Figma-first 页面方法已开始批量复制到 canonical 组件页，页面不能再停留在“几张 state card”

- 日期：2026-04-24
- 影响范围：`CheckboxPage`、`RadioPage`、`SwitchPage`、`InputPage`、`SelectPage`、`DateTimePage`
- 现象：
  - 这些页面虽然已经是 canonical-only 或接近 canonical-only
  - 但之前大多仍停留在“按状态堆几张 demo card”的层级
  - 缺少：
    - Figma 轴覆盖
    - 开发引用方式
    - 当前 canonical API 契约
- 根因：
  - 之前只有 `Button` 把“审核页本身也要可回溯、可开发引用”这件事做完整
  - 其余 canonical 组件页还没有复制这套方法
- 修复：
  - `CheckboxPage.vue`
  - `RadioPage.vue`
  - `SwitchPage.vue`
  - `InputPage.vue`
  - `SelectPage.vue`
  - `DateTimePage.vue`
    - 统一补上：
      - `Figma Coverage`
      - `Development Usage`
      - `API`
  - 新增页面测试：
    - `tests/StateControlPages.test.ts`
    - `tests/FormControlPages.test.ts`
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/CheckboxPage.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/RadioPage.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/SwitchPage.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/InputPage.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/SelectPage.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/playground/docs/pages/DateTimePage.vue`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/tests/StateControlPages.test.ts`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/tests/FormControlPages.test.ts`
- 复用规则：
  - 只要组件页已经是 canonical-only，就不应该只停留在状态样例层
  - 至少应同步具备：
    - 真实 Figma 轴覆盖
    - 当前开发引用方式
    - 当前 API 契约
- 当前状态：已修复

## [034] runtime-only / generated-skeleton 组件不能直接“照抄 Button 页面外观”冒充完成，必须先承认 canonical 阻塞

- 日期：2026-04-24
- 影响范围：`Badge`、`InputNumber`、`Notification`、`Pagination`、`Progress`、`Rating`、`Slider`、`Table`、`Tooltip`、`TopBar` 等 runtime-only 页面
- 现象：
  - 当前 docs-site audit 已明确：
    - 这些页面仍是 `runtime-only`
    - 对应组件中还有多项 `generated skeleton wrapper`
  - 如果直接只复制 `ButtonPage` 的页面外观，会制造“页面更完整了，所以实现也差不多完成了”的假象
- 根因：
  - 这批组件当前缺的不是单纯页面组织方式
  - 而是 canonical 实现和 generated skeleton 清理仍未完成
- 修复：
  - 当前先把 `Button` 的页面方法优先复制到真正已 canonical 的第一梯队
  - 对 runtime-only / skeleton 组件，先保持它们在台账和审计里被明确标记为第二梯队阻塞
  - 后续推进顺序应是：
    1. 先处理 canonical/runtime 边界
    2. 再复制 Button 风格的页面审核结构
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/docs/conformance-issue-log.md`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/docs/site-review-manifest.json`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/src/canonical/generated`
- 复用规则：
  - Button 方法可以复制，但前提是组件已经至少进入 canonical-first 轨道
  - 对 runtime-only / skeleton 组件，不能只修页面而跳过实现边界
- 当前状态：已确认阻塞

## [035] 第二梯队 canonical bridge 已继续扩到反馈 / 导航 / 数据展示组件，generated skeleton 已清零

- 日期：2026-04-27
- 影响范围：
  - `InputNumber`
  - `Progress`
  - `Rating`
  - `Slider`
  - `Tooltip`
  - `Notification`
  - `Pagination`
  - `Table`
  - `TopBar`
  - `BreadcrumbItem`
  - `FormItem`
  - `StepItem`
  - `TabItem`
  - `TabList`
- 现象：
  - 第二梯队里仍有大量 `runtime-only` docs page
  - `audit:figma-conformance` 还会持续被 generated skeleton 卡住
- 修复：
  - 把上述组件全部改为 hand-maintained canonical bridge 或 canonical wrapper
  - `ButtonPage` 也改为通过 `src/canonical/ButtonBridge.vue` 进入审计
  - 清空 `src/canonical/generated/*` 中剩余 skeleton
  - 页面测试与 canonical 测试继续补齐
- 结果：
  - `pnpm audit:figma-conformance` 已通过
  - `skeletonGeneratedWrappers = 0`
  - `publiclyExportedSkeletons = 0`
  - `generatedIndexViolations = 0`
- 当前状态：已修复

## [036] docs-site 的主要红灯已从实现来源问题转成 baseline / frame / review metadata

- 日期：2026-04-27
- 影响范围：
  - `docs/site-review-manifest.json`
  - 全部 component docs pages
- 现象：
  - 在 canonical 来源统一后，`audit:docs-site` 仍未全绿
  - 但错误已从 `runtime-only / not-canonical / generated skeleton` 明显收缩
  - 剩余主要集中在：
    - `missing-figma-baseline`
    - `not-figma-frame`
    - `review-not-approved`
- 结果：
  - `audit:docs-site` 错误总数已进一步下降到 `35`
- 复用规则：
  - 下一阶段要继续推审计，不要再优先回头处理 generated skeleton
  - 优先补：
    - `figmaNodeId / baselineStatus`
    - frame 级页面结构
    - review stage 闭环
- 当前状态：已确认，进入下一阶段

## [037] 组件主线闭环完成，build / docs-site / figma-conformance 已同时通过

- 日期：2026-04-27
- 影响范围：
  - `src/canonical/SelectBoxBase.vue`
  - `docs/site-review-manifest.json`
  - component docs pages
- 现象：
  - 在 component pages 审计接近收尾后，仓库仍有最后一个 `build` 阻塞
  - `vue-tsc` 报错点在 `src/canonical/SelectBoxBase.vue`
  - `DropDownListSelect` 的 `@select` 允许 `undefined`，但本地 `handleSelect` 签名只接受 `string | number`
- 修复：
  - 放宽 `handleSelect` 入参为 `string | number | undefined`
  - 对 `undefined` 提前返回，保持既有选择逻辑不变
  - 同时完成 component docs 的 manifest 闭环：
    - `figmaNodeId`
    - `baselineStatus`
    - `currentRenderingMode`
    - `pixelReviewStage`
- 结果：
  - `pnpm build` 已通过
  - `pnpm audit:figma-conformance` 已通过，`overallPass = true`
  - `pnpm audit:docs-site` 已通过，`errors = 0`
  - `componentPages = 17`
  - `approvedComponentPages = 17`
  - `blockedComponentPages = 0`
- 剩余说明：
  - 当时 `audit:docs-site` 仍有 `3` 条 warning，均来自 foundation 页面
- 当前状态：已修复

## [038] foundation pages 已全部切到 foundation-audit，docs-site warning 清零

- 日期：2026-04-27
- 影响范围：
  - `docs/site-review-manifest.json`
  - `BorderPage`
  - `EffectPage`
  - `TypographyPage`
- 现象：
  - 组件页已全部通过，但 `audit:docs-site` 仍保留 `3` 条 warning
  - 警告来源不是页面 import 或实现边界，而是 foundation manifest 仍标记为：
    - `currentRenderingMode = docs-demo`
    - `pixelReviewStage = blocked`
    - `baselineStatus = partial`
- 修复：
  - 将 `border / effect / typography` 统一提升为：
    - `currentRenderingMode = foundation-audit`
    - `pixelReviewStage = in-review`
    - `baselineStatus = captured`
  - 与 `color / icon` 的 foundation 审计口径对齐
- 结果：
  - `pnpm audit:docs-site` 已通过且 `warnings = 0`
  - `pagesChecked = 23`
  - `componentPages = 17`
  - `approvedComponentPages = 17`
  - `blockedComponentPages = 0`
  - `errors = 0`
  - `warnings = 0`
- 复用规则：
  - foundation 页如果已经是基础资产盘点页，不要继续保留 `docs-demo`
  - 进入审计轨道后，应至少补到：
    - `foundation-audit`
    - `in-review`
    - `captured`
- 当前状态：已修复

## [039] 图标体系已进入 category-first 主链，运行时组件必须统一走共享 Icon 组件

- 日期：2026-04-27
- 影响范围：
  - `figma-sync/export-icons.mjs`
  - `figma-sync/icon-artifacts.mjs`
  - `src/components/Icon/Icon.vue`
  - `src/icons/catalog/*`
  - 全部使用普通语义图标的运行时组件
- 现象：
  - 之前虽然已经有部分 icon registry，但运行时组件里仍混有：
    - 内联 SVG
    - 直接 import 某个 icon map
    - 单组件自定义图标渲染逻辑
  - 这会让“设计库图标”和“组件内部自绘图标”长期并存，难以统一维护
- 修复：
  - 图标导出链改为直接生成：
    - `manifest`
    - `generated/<category>.ts`
    - `loaders`
    - `esm/<category>.js`
    - `svg/<category>/<name>.svg`
  - 正式命名统一为 `category/name`
  - 运行时普通图标统一通过共享 `Icon` 组件消费
  - `Logo` 保持为品牌资产组件，不并入普通语义图标入口
  - 新增 `IconUsageConformance.test.ts`，阻止组件继续直接引用 generated map 或内联 SVG
- 复用规则：
  - 新组件只要出现普通语义图标，必须优先接共享 `Icon`
  - 允许的例外只应是：
    - `Icon.vue`
    - `Logo.vue`
  - 如果设计库里暂时没有明确图标，不要直接补临时 SVG，先记录并人工指定
- 当前状态：已修复

## [040] Tooltip 审核页应跟随全站主题，不应再做局部主题开关

- 日期：2026-04-27
- 影响范围：
  - `playground/docs/pages/TooltipPage.vue`
  - `playground/docs/DocsShell.vue`
- 现象：
  - 组件页自己再做一套 `dark / light` 切换，会和网站右上角全局主题形成双状态源
  - 用户切换网站主题后，如果页面内部还保留局部切换器，会出现站点与组件页主题不一致
- 修复：
  - `TooltipPage` 改为直接跟随 `DocsShell` 传入的全站主题状态
  - 删除页面内部 `Dark theme / Light theme` 本地切换器
  - `Position Preview` 与 `Interaction Preview` 都统一读取当前网站主题
- 复用规则：
  - 主题切换属于壳层能力时，组件页必须跟随全站主题
  - 只有当页面在演示“主题切换组件本身”时，才允许单独做主题切换示例
- 当前状态：已修复

## [041] Tooltip 这类交互组件的审核应优先展示真实 hover 附着效果，不能把气泡强行摆到远离锚点的位置

- 日期：2026-04-27
- 影响范围：
  - `playground/docs/pages/TooltipPage.vue`
  - 同类浮层组件后续审核页
- 现象：
  - 之前为了让所有 tooltip 同时可见，把气泡固定摆出来，导致：
    - 气泡离 anchor 太远
    - 用户反而更难判断真实附着关系
    - 页面里同时并排多个主题也削弱了真实交互判断
- 修复：
  - 当前页改成 hover 触发预览
  - 只保留当前主题下的一组位置审核
  - 强调“气泡贴近 anchor”而不是“所有气泡一次性全展示”
- 复用规则：
  - 对 `Tooltip / Popover / Dropdown` 这类组件，优先展示真实交互位置
  - 静态矩阵只能作为补充，不能取代真实附着效果
- 当前状态：已修复

## [042] docs shell 入口层必须清掉浏览器默认白边，外层留白属于站点壳层缺陷

- 日期：2026-04-27
- 影响范围：
  - `playground/index.html`
  - `playground/legacy.html`
  - `canonical.html`
- 现象：
  - 页面四周露出白色边距时，会让人误以为是组件页自身留白问题
  - 实际根因是入口 HTML 没有清掉浏览器默认 `body` margin
- 修复：
  - 在三个入口里统一设置：
    - `html, body, #app { margin: 0; min-height: 100%; background: ... }`
- 复用规则：
  - 这类问题应直接在壳层入口修，不要在单个页面里逐页打补丁
- 当前状态：已修复

## [043] PromptMessage 的 `closable` 命名按 Vue 生态保留，不回退到 Figma 的 `showCloseIcon`

- 日期：2026-04-27
- 影响范围：
  - `src/components/PromptMessage/PromptMessage.vue`
  - `src/canonical/PromptMessage.vue`
  - `playground/docs/pages/PromptMessagePage.vue`
- 现象：
  - Figma component property 名称为 `showCloseIcon`
  - 代码侧一直使用 `closable`
- 根因：
  - 这是有意保留的产品/API 决策，不是实现遗漏
  - `closable` 更符合 Vue 生态常见命名，和 Element Plus、Ant Design 的开发者习惯一致
- 修复：
  - 不修改现有代码 prop 名
  - 后续审计中不再把这条命名差异当作 conformance bug
- 复用规则：
  - 当 Figma 属性名与运行时 API 命名冲突时，如果团队已明确选定更稳定、更符合宿主生态的开发者命名，应记录为 documented divergence
  - 记录后不再重复以“命名没贴 Figma”作为 bug 提出
- 当前状态：已确认并接受

## [044] PromptMessage 的 `interact` 是设计态预览开关，不映射到运行时代码 prop

- 日期：2026-04-27
- 影响范围：
  - `src/components/PromptMessage/PromptMessage.vue`
  - `src/canonical/PromptMessage.vue`
  - 后续所有 Figma 属性审计
- 现象：
  - Figma properties 面板里存在 `interact`
  - 其导出枚举值只有单值 `"Yes"`
  - 它对应的是设计稿里的 hover/active 预览语义，不是业务运行时配置
- 根因：
  - Figma 中部分 variant/property 只服务设计态演示，并不代表组件库必须暴露对应 prop
- 修复：
  - 不把 `interact` 加入代码 API
  - PromptMessage 的交互继续由 CSS `:hover` / `:active` 与事件 handler 实现
  - 后续审计中不再把 `interact` 缺失视为运行时偏差
- 复用规则：
  - 收到 Figma 属性时，先判断“这个属性是给谁看的”
  - 如果是 hover 预览、设计审阅、装饰显隐这类设计态控制，且枚举为单值或 `Yes/No`，优先视为设计态属性，不直接映射为代码 prop
  - 只有存在明确运行时业务语义的多值属性，才进入组件公开 API
- 当前状态：已确认并接受

## [045] 图标 alias 命名层是稳定内部 API，审计应关注 glyph family 是否匹配而不是强制贴 Figma 原名

- 日期：2026-04-27
- 影响范围：
  - `src/components/Icon/Icon.vue`
  - `src/icons/generated/*`
  - `src/icons/catalog/*`
  - 所有消费图标的运行时组件
- 现象：
  - 代码里的稳定命名会使用 `status/warning`、`action/close` 等内部 API
  - Figma component name 则是 `icon/Message/warning 2`、`icon/Edit/Close` 这类设计资源名
- 根因：
  - 设计资源名与运行时代码 API 承担的职责不同
  - 代码需要稳定、可维护的命名层，不应直接把 Figma 原始 component name 当作唯一 API
- 修复：
  - 认可 alias / canonical icon name 作为内部稳定 API
  - 审计时只要求代码命名层与 Figma 保持映射关系
  - 只有当 glyph family 选错时，才作为 bug 处理，例如 `warning` 错用了非 `Error 4` 图形
- 复用规则：
  - 图标审计优先检查三件事：
    - 是否使用共享图标库
    - 是否映射到正确的 Figma glyph family
    - 是否存在未记录的命名偏差
  - 不要求内部 alias 命名和 Figma component name 逐字一致
- 当前状态：已确认并接受

## [046] audit:docs-site 启动门槛口径调整：in-review 与 foundation 资产展示降为 warn

- 日期：2026-04-28
- 影响范围：
  - `figma-sync/audit-docs-site-readiness.mjs`
  - `docs/site-pixel-parity-mechanism.md`
  - 所有依赖主 Session 启动 audit 的后续 Session
- 现象：
  - 启动 `pnpm audit:docs-site` hard fail，`overallPass=false`，`errors=6`
  - 5 个 error 来自 `pixelReviewStage='in-review'` 的页面（`breadcrumb / form-item / prompt-message / steps / tabs`）
  - 1 个 error 来自 `IconPage.vue` 导入 runtime `src/components/Icon/Icon.vue`，但 manifest 写 `expectedSourceType='none'`
  - 结果：6.3.5 等与像素门无关的链路被一同 hard 阻塞
- 根因：
  - 旧脚本把"非 approved"和"source-type 不匹配"无差别记为 error
  - 没有区分"已进入像素核对的中间态"与"真阻塞（缺 baseline / 非 canonical / 非 figma-frame）"
  - 没有区分 component 页（必须 Figma-first）和 foundation 页（资产目录展示，允许导入共享 runtime 展示组件）
- 修复：
  - 改 `figma-sync/audit-docs-site-readiness.mjs`（commit `25f36e1`）：
    - `pixelReviewStage='in-review'`：severity=warn，gate 状态新增 `in-review`
    - 仅 `kind='foundation'` 的 source-type 不匹配：severity=warn
    - summary 拆分 `approvedComponentPages` / `inReviewComponentPages` / `blockedComponentPages`，approved 严格只数 4 gate 全 pass
    - `overallPass = errorCount === 0`，warnings 不阻塞
  - component 页其它 hard gate（缺 baseline / 非 canonical / 非 figma-frame / source-type 不匹配 / review stage 既非 approved 也非 in-review）保持 error
  - 同步 `docs/site-pixel-parity-mechanism.md` 追加"严重程度口径"段
- 相关文件：
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-sync/audit-docs-site-readiness.mjs`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/docs/site-pixel-parity-mechanism.md`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/docs/internal/audit-docs-site-gate-relax-execution-report.md`
  - `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/docs/internal/_prompts/audit-docs-site-gate-relax.prompt.md`
- 复用规则：
  - foundation 页（Color / Icon / Typography / Border / Effect）允许导入共享 runtime 展示组件做资产目录，不视为 Figma-first 退化
  - 启动 audit 的 fatal 标准是"真阻塞"，不是"未签字"——in-review 是计划内中间态，不应阻塞与该页无关的链路
  - 改 audit gate 口径必须同步：脚本 + 机制文档 + handoff 基线 + 本台账，四处一致才算落地
- 当前状态：已落地
- 后续动作：
  - 5 个 in-review 页面（`breadcrumb / form-item / prompt-message / steps / tabs`）仍需人工像素核对，warning 不消失即不能算 approved
  - 进 6.3.5 反向 audit