token-mapping

Token 映射

一份只读报告，将原始值（十六进制、px、阴影）对应到由他人维护的 token 列表。分类、规范化和容差见 references/mapping-rules.md。“检查一下设置页面上的 token”就是足够明确的要求。自己查找值和列表。

步骤

1. 查找列表。 Token 文件、主题条目、:root 上的自定义属性、组件库的变量配对。框架的默认主题不是团队的列表，公共设计系统的列表也不是（Geist 的名称绝不能代替团队的名称）。记录列表名称、位置和读取方式。如果读取失败，说明情况并停止。绝不要凭记忆补全列表。
2. 查找值。 查找对方指定的内容；若未指定，则查找分支差异；再否则查找产品代码。记录每个值对应的文件、行、属性和用途。
3. 解析。 在每种模式下，将每个别名追溯到最终值。记录任意两个来源之间的所有分歧。
4. 规范化双方的值（长度换算为 px，颜色换算为 OKLCH 并按 delta E OK 比较），必须用代码，绝不能凭肉眼判断。
5. 分类每行在每种模式下的情况。先看用途，再看值。
   • 精确：token 声明的用途涵盖该行，且值匹配。
   • 语义匹配：用途涵盖该行，且值在容差范围内。用数字说明差异。
   • 模糊：有两个或更多 token 符合，且没有依据可以择一。列出所有候选项。
   • 缺口：没有 token 的用途涵盖该行，或唯一符合的 token 超出容差。缺口绝不新命名。
6. 统计并收尾。 当缺口占比超过 30%，且数量达到 12 行或以上时，通常说明列表选错了。指出这一点，仍然提交表格，并以 Status: not actionable (gap threshold) 开头。

报告

摘要、映射、请勿使用（值匹配但用途不同的 token）、模糊项、缺口、需要人工决定的事项、来源。最后一行写 Coverage:，说明扫描了哪些内容以及哪些内容未扫描。单独运行时，聊天回复应给出带数字的答案，并附上一条可供对方复制粘贴以继续下一步的提示词。

规则

• 先比对值、后考虑用途，是错误的。错误示例：因为十六进制值相同，就将 #6b7280 映射到 color.border.default。正确做法：它是文本，因此候选项应为文本 token；边框 token 应列入“请勿使用”。
• 语义 token 优先于其别名所指向的原始 token。仅当没有语义 token 涵盖该用途时，才映射到原始 token，并说明原因。
• 调色板类（text-gray-500）只指明一个值，不指明用途。将其单独列为一行，并与原始值分开统计。
• 任何推断而非读取所得的信息，例如从类名推断用途，都要标记为“推断”。
• 数量必须注明单位：出现次数、行数或映射行数。

停止条件

仅遇到以下情况时停止并报告：不存在列表。同一模式下，一个名称对应两个值。两个来源存在分歧，且项目规则未说明以哪个为准（报告两者）。说明导致停止的原因、迄今完成的准备工作，以及解除阻碍所需的最简消息，例如“粘贴 tokens.json 或提供其路径。”

完成标准

每行都有用途、分类和理由。每个模糊项都列出两个或更多候选项。仓库内容没有变化（前后 git status 相同）。最后一行写 Coverage:。