# Generated Skeleton Promotion Plan

这份文档只服务一个目的：

**把剩余 `src/canonical/generated/*` skeleton 的处理方式固定下来，避免它们再次被误当成完成组件，或在后续 Session 中反复从零判断。**

配套机器工件：

- `/Users/nancy/Documents/AICoding/VS_Code/tvu-design-system/figma-data/normalized/skeleton-promotion-plan.json`

生成命令：

```bash
pnpm generate:skeleton-plan
```

## 当前结论（2026-04-24）

剩余 skeleton 共 `15` 个，已分成两条处理路径：

- `spec-normalization`：`6`
- `structural-rebuild`：`9`

## A. 先走 spec-normalization 的组件

这些组件的共同特征是：

- Figma 轴较集中
- 更接近单一视觉 primitive
- 问题主要在 contract、命名、状态映射
- 不应直接晋升，但适合先修 canonical contract，再决定是否转正

### 组件名单

1. `Badge`
2. `BreadcrumbItem`
3. `InputNumber`
4. `Progress`
5. `Rating`
6. `Tooltip`

### 处理规则

1. 先核对 canonical spec 是否真的表达了 Figma 轴  
2. 再核对 runtime base 是否已经有足够的结构承载这些轴  
3. 如果只是 prop contract 混乱，优先修 spec，不直接重写结构  
4. 只有在：
   - Figma 轴清晰
   - runtime 结构能承载
   - 站点页 provenance 明确
   三者都满足时，才允许从 generated 晋升为 stable canonical

## B. 必须先做 structural-rebuild 的组件

这些组件的共同特征是：

- 本质上是 compound family
- 当前 runtime base 只是近似物或通用壳
- 不能靠一层 generated wrapper 就宣称符合 Figma

### 组件名单

1. `FormItem`
2. `Notification`
3. `Pagination`
4. `Slider`
5. `StepItem`
6. `TabItem`
7. `TabList`
8. `Table`
9. `TopBar`

### 处理规则

1. 先拆 family / interaction model / structural owner  
2. 不允许直接从 wrapper 晋升  
3. 先明确：
   - compound 结构
   - owner / child 契约
   - 是否需要 family split
4. 结构未重建前，必须继续停留在 `draft/generated`

## 当前优先顺序

在 `Button` 之外，后续如果继续推进 skeleton，优先顺序应为：

1. `Badge`
2. `InputNumber`
3. `Progress`
4. `Tooltip`
5. `FormItem`
6. `Pagination`
7. `Slider`
8. `TopBar`

原因：

- 前 4 个更适合继续验证 “spec-normalization 是否足以把 generated 拉回 canonical”
- 后 4 个更适合验证 “什么时候必须认定为 structural-rebuild，不能再靠 wrapper 近似”

## 当前红线

1. 不因为这份计划存在，就默认这些组件已经可以晋升  
2. `spec-normalization` 不等于“已经完成”，只是更适合先修 contract  
3. `structural-rebuild` 组件在未重建前，不得重新公开导出  
4. 每次真正处理某个组件后，要把结论同步写回：
   - `docs/conformance-issue-log.md`
   - `docs/session-handoff.md`