build-design-system

构建设计系统

1. 确定本次运行的框架：模式与基础、基础参考、试点、应用默认值后的框架问题、运行分支和 .design-system/run.md（references/modes.md、references/run-record.md、references/coordinator-path.md 中的 Start）。
2. 确定规模：小型应用路径，或根据从内存压力读取的机器预算进行扇出（references/coordinator-path.md 中的 Small app 和 Machine budget）。
3. 使用脚本进行盘点，并在任何编辑之前捕获每个界面（references/inventory.md、references/browser.md）。
4. 按用途命名令牌：相同值的替换、作为决策处理的容差范围内合并，以及默认允许合并的门槛（references/token-architecture.md）。
5. 组件：先端到端处理使用最多的组件系列，再将其余工作扇出（references/component-contract.md、references/rule-method.md、references/worker-brief.md）。
6. 检查项必须能在预置违规时失败，并设置棘轮机制和两个 CI 层级（references/checks.md）。
7. 在设计系统上运行试点流程，与基线进行比较并完成审查（references/browser.md）。
8. 明确试点范围之外的安全操作，并且只在获得许可后迁移（references/coordinator-path.md 中的 Clearance）。
9. 编写文档、生成配套副本和 AGENTS.md 索引（references/system-structure.md）。
10. 交接：核对最终数字，优先列出尚未答复的默认项，并附上已发现但未修复事项列表（references/run-record.md 中的 Handoff report）。

绝不交付：

• 应用中不存在的颜色、字体、阴影、渐变或动态效果值，除非有人选择了设计来源并确认了样例（references/modes.md）。
• 在起始分支上的提交、推送、发布或部署。
• 修改过的基线、测试固件或检查项。应改正代码。
• 既不是安全操作、也未获准的试点范围外更改。
• 根据源码而非渲染结果读取的无障碍或对比度结果。
• 任何脚本未生成的计数，或从未见过失败的检查。
• 除 Don't: 行之外，任何地方出现的人员禁令。

此流程调用 token-mapping、component-docs 和 ui-review，而不是重新描述它们。基础设计的基础参考（references/base-*.md）优先于通用参考。

协调器调用时

协调器可以移交目标、试点、预算、运行分支或运行记录路径，其余内容按 Inputs 中的默认值处理。将门槛写入运行记录，而不是提问；并返回交接报告或停止格式。回复以状态行开头，接着写 Commit: <run branch head>。在 design-system-boss 下，遵循 boss 的规则和上限。作为子 Agent 时，以前台调用运行工作进程，并且绝不在工作进程仍在运行时返回。

完成标准

运行以检查优先的方式结束（references/modes.md）。阶段 1 的判定条件成立，且所有数字均在阶段 8 测量：“N 个规范组件覆盖 M 个已盘点的组件系列，每个令牌都有用途，检查项在预置违规时失败并能在干净克隆中以退出码 0 结束，且试点与基线一致，已列出的预期更改除外。”若某部分未通过，就如实报告未通过。绝不放宽标准。

• 每个令牌都说明其用途，并且每项安全操作都已完成并得到验证（references/run-record.md 中的 Terms）。
• 试点使用的每个规范组件都有注册表条目，其规范通过 node scripts/check-spec.mjs docs/system；注册表组件中跳过的普通条目数为 0。
• 完整检查在干净克隆中以退出码 0 结束，本次会话中每条规则都曾因其错误测试固件而失败，并且生产构建中的每条路由都返回 200。
• 试点捕获结果中的每项差异，以及试点范围之外的每次提交，都可追溯到某项决策或门槛。
• 交接报告符合 references/run-record.md，所有计数均来自 .design-system/close.md。

不同模式和项目规模对应的其余完成标准见 references/coordinator-path.md（Close）。如果流程停止，则返回停止条件、已完成的产物、运行记录路径，以及解除阻碍所需的最简回复。

输入

根据仓库或其默认值填写每一项，绝不询问路径。

输入	缺失时
具有写入权限的仓库	停止。基于截图构建的系统没有代码可用于强制执行
运行应用的方式	尝试 dev 或 start 脚本。如果无法启动，则根据代码运行阶段 3、4、5 和 7，跳过试点，并报告“代码已完成，未经运行时验证”
单体仓库中的目标应用	Frame 的一个目标问题（references/run-record.md，Questions）。同时，对每个候选项运行阶段 2 的只读脚本
试点流程	投诉中提到的屏幕；否则，使用家族最多且包含带错误状态表单的流程；若仍有并列，则选择 high 层级的流程；否则，选择模式页面（references/modes.md）
预算	Frame 的“Go, ”回复；否则，使用主机的会话；否则，参考 references/coordinator-path.md（阶段上限）
主题	使用应用自带的主题，不新增主题
模式和基础	采用路由器分诊结果；否则，参考 references/modes.md
现有令牌、库、设计规范或品牌	根据基础参考和 references/modes.md（由什么决定问题）从现有内容着手
此人的原话和已保存的记忆、AGENTS.md、CLAUDE.md	它们的优先级高于此文件，包括分支和推送策略

需要 shell、git 和 Node。

流程

其他文件引用的是这些阶段编号，而非顶部的列表。每个阶段结束时都会给出产物路径和决策行，并在达到上限时停止（references/coordinator-path.md，阶段上限）。任何共享 UI 或令牌编辑后，capture.mjs --status 必须显示所有路由均已加载（references/browser.md）。

1. 框定。 阅读 Agent 指令、清单、样式入口、主题提供方和路由树。用当事人的原话写下投诉，以及回应投诉的第一个可见改动；写出带有计数空位的谓词和长期指令。视口采用应用支持的最窄和最宽宽度，默认分别为 390 和 1280 px。搭建项目范围，然后运行 node scripts/check-system.mjs --init，再确定 Lock 后开始分派。无需等待即可开始第 2 阶段。
2. 盘点。 运行脚本，然后列出每个界面及其状态和层级，并用一条 capture.mjs --kind before 命令捕获它们。记录动画列表并测量试点中的陷阱。对系列分组，标记重复项，按照 references/traps.md 执行渲染样式检查，并在单独的提交中删除无人使用的内容（references/inventory.md，删除计划）。除非协调者已执行，否则在令牌提交后立即以审计、只读模式启动 migrate-design-system。
3. 基础。 按类别和角色将原始值归类为语义令牌，并配对表面与前景色。token-mapping 容差范围内的合并即为决定。超出容差时，每个簇开启一个门控项，默认采用合并方案，并注明最大偏移及受影响的屏幕，同时立即在令牌文件中应用每个默认方案。如果配置中有生成器，就编写它。针对完整清单运行 token-mapping，直到每个原始值都映射到一个角色、一个合并项或一个已列出的例外。对每条路由应用所有相同值替换，并将发生变化的路由提供给迁移映射。编写 AGENTS.md 区块，命名动效预设和图标尺寸，并在当事人通过浏览器审查时启动实时展示（references/system-structure.md）。
4. 组件。 按照契约选择每个规范实现。需求中指定状态时，每个组件都要补齐缺失状态。优先端到端构建使用最多的系列，并在一个提交中完成：组件、测试、展示页及其规则规范。在分派前展示其页面。编写新旧映射，以及一个与手动迁移的试点屏幕相符的代码修改工具；若没有，则记录原因。分派试点和零散项涉及的系列，并拒绝超出简报范围的任何差异。弃用被替换的包装组件，绝不弃用内置基础组件。按照 references/coordinator-path.md 收尾（组件收尾）。
5. 检查。 遵循 references/checks.md。进入第 6 阶段前，检查必须以 0 退出。运行 node scripts/check-system.mjs --self-test --fixtures <skills>/build-design-system/fixtures/check-system，证明已落实的规则有效。
6. 试点，然后安全迁移。 使用代码修改工具迁移试点，并阅读每个代码块。使用基线的视口、主题和数据进行迁移后捕获。任何未追踪的差异都是缺陷；有渲染改动却没有捕获报告的，标记为 checks-only。通过键盘走查流程，触发错误和加载状态，并测量迁移前后的每个陷阱。对迁移后捕获运行 ui-review。将现有令牌和组件能够修复的问题以及行为缺陷作为决定项处理。其余问题都是门控项。然后逐个界面、每个提交一次，落实安全迁移（references/coordinator-path.md，运行分支上的界面）。
7. 文档。 对任何仍缺少规范的规范组件运行 component-docs。编写基础页面、共享状态模式（references/system-structure.md）和写作页面（references/writing-method.md）。首次运行时使用 --name 运行 node scripts/gen-docs.mjs，并在 docs/system/writing.md 存在后将 copy-check.mjs 加入检查流程。然后审查、决策、修复（references/coordinator-path.md），并重新生成。
8. 交接。 重新运行盘点脚本，为每个组件评级并填写谓词。覆盖完整项目范围后，编写项目技能。运行新 Agent 试验，并按照 references/coordinator-path.md 收尾（收尾）。

边界

仅在以下情况下暂停并询问：

• 无法访问仓库。
• 删除操作会影响其他程序包或公共 API 导出的内容。
• 执行 Git 无法撤销的步骤，例如发布程序包或更改共享远程仓库。

设置默认选项后继续工作，即使无人回复也不例外：

• 代码以两种方式声明的品牌颜色、字体或徽标值。
• 包含产品词的名称，例如“Plan”或“Workspace”。
• 超出容差的合并，或会更改已发布屏幕的变体移除。
• 代码与规范或旧文档之间的冲突，且项目规则无法裁定。
• 链接颜色或下划线的更改，并列出影响的所有界面。主要内容中的链接须保留常态提示。
• 工作范围：当仓库看起来属于他人，或请求提及 PR 或上游时，默认采取最小范围（references/coordinator-path.md）。