Token Architecture

You are a design systems architect. I'm providing you with a raw design audit JSON from an existing codebase. Your job is to transform this chaos into a structured token architecture.

## Input
{{audit_json}}

## Token Hierarchy

Design a 3-tier token system:

### Tier 1 — Primitive Tokens (raw values)
Named, immutable values. No semantic meaning.
- Colors: `color-gray-100`, `color-blue-500`
- Spacing: `space-1` through `space-N`
- Font sizes: `font-size-xs` through `font-size-4xl`
- Radii: `radius-sm`, `radius-md`, `radius-lg`

### Tier 2 — Semantic Tokens (contextual meaning)
Map primitives to purpose. These change between themes.
- `color-text-primary` → `color-gray-900`
- `color-bg-surface` → `color-white`
- `color-border-default` → `color-gray-200`
- `spacing-section` → `space-16`
- `font-heading` → `font-size-2xl` + `font-weight-bold` + `line-height-tight`

### Tier 3 — Component Tokens (scoped to components)
- `button-padding-x` → `spacing-4`
- `button-bg-primary` → `color-brand-500`
- `card-radius` → `radius-lg`
- `input-border-color` → `color-border-default`

## Consolidation Rules
1. Merge values within 2px of each other (e.g., 14px and 15px → pick one, note which)
2. Establish a consistent spacing scale (4px base recommended, flag deviations)
3. Reduce color palette to ≤60 total tokens (flag what to deprecate)
4. Normalize font size scale to a logical progression
5. Create named animation presets from one-off values

## Output Format

Provide:
1. **Complete token map** in JSON — all three tiers with references
2. **Migration table** — current value → new token name → which files use it
3. **Deprecation list** — values to remove with suggested replacements
4. **Decision log** — every judgment call you made (why you merged X into Y, etc.)

For each decision, explain the trade-off. I may disagree with your consolidation
choices, so transparency matters more than confidence.

你是一位设计系统架构师。我向你提供一份来自现有代码库的原始设计审计 JSON。你的任务是将这种混乱转化为结构化的 token 架构。

## 输入
{{audit_json}}

## Token 层级

设计一个三层 token 系统：

### 第 1 层 — 原始 Token（原始值）
命名的、不可变的值。无语义含义。
- 颜色：`color-gray-100`, `color-blue-500`
- 间距：`space-1` 到 `space-N`
- 字号：`font-size-xs` 到 `font-size-4xl`
- 圆角：`radius-sm`, `radius-md`, `radius-lg`

### 第 2 层 — 语义 Token（上下文含义）
将原始值映射到用途。这些值在不同主题之间会变化。
- `color-text-primary` → `color-gray-900`
- `color-bg-surface` → `color-white`
- `color-border-default` → `color-gray-200`
- `spacing-section` → `space-16`
- `font-heading` → `font-size-2xl` + `font-weight-bold` + `line-height-tight`

### 第 3 层 — 组件 Token（作用于组件范围内）
- `button-padding-x` → `spacing-4`
- `button-bg-primary` → `color-brand-500`
- `card-radius` → `radius-lg`
- `input-border-color` → `color-border-default`

## 合并规则
1. 合并彼此相差在 2px 以内的值（例如 14px 和 15px → 选择其一，并注明是哪一个）
2. 建立一致的间距比例（建议使用 4px 基数，标记出偏离项）
3. 将颜色调色板减少至 ≤60 个 token（标记出应弃用的内容）
4. 将字号比例规范化为逻辑递进序列
5. 从一次性值中创建命名的动画预设

## 输出格式

提供：
1. **完整 token 映射表**，以 JSON 格式 — 包含全部三层及引用关系
2. **迁移表** — 当前值 → 新 token 名称 → 使用该值的文件
3. **弃用列表** — 应移除的值及其建议的替代项
4. **决策日志** — 你做出的每一个判断（为何将 X 合并为 Y 等）

对于每个决策，请说明权衡取舍。我可能会不同意你的合并选择，因此透明度比自信更重要。