构建 UI 组件与设计系统

领域结果

交付可被声明消费者真实导入、组合、验证和升级的界面合同，而不是组件展厅、业务页面换名或一组截图。系统的核心链是：token → component API → behavior/a11y → distribution → consumer → governance。

本 Skill 保持介质中立。先明确最终消费者、目标媒介与 target renderer，并记录组件、字体、图标和 数据的来源与许可；验收发生在真实消费接口、状态与最终像素，不默认落到浏览器展示页。

只有最终消费者或合同交付确为 Web 时，才调用 $build-polished-visual-frontends，由它负责 Web 技术栈、整体视觉语言和浏览器最终像素；非网页媒介不得为了预览方便加载该 Skill，也不能用浏览器证据冒充目标消费者证据。本 Skill 始终拥有组件系统合同与领域 gate；共享 visual-artifact-design 拥有工具证据、authority graph、渲染、review 和 scoped promotion，这里不另造生命周期或晋升状态。

按需读取：

• patterns.md：子型、consumer contract、API、token/state、a11y、分发与治理模式；
• tool-profiles.md：领域工具能力、分发形态与选择失败条件。

1. 路由任务与声明上限

先记录 mode / primary_domain / final_consumer / target_medium / target_renderer / target_profile / consumer_scope / target_claims / source_provenance / risk_triggers / explicit_non_goals。模式为 create / edit / diagnose / audit / migrate；migrate 必须有真实旧实现或明确标注的 synthetic fixture。

• greenfield 才从消费者任务建立所需的最小 token、API、行为、分发和治理权威链，不预造企业级全家桶。
• 已有系统先锁定现有 owner、公共合同、消费者和兼容边界，再按变更影响图只检查和修改受影响类别；未受影响的 token、组件、状态、文档、分发或治理保持原样，不因局部 Edit 全量重做、换肤或迁移。
• Diagnose/Audit 一律零写入，只定位最早失效的 concern、受影响类别和返回 owner；无修复授权时不创建 proof、快照、缓存或“顺手修正”。

以下是目标档案与 claim ceiling，不是所有项目必须依次走完的线性流程：

target_profile	可声明的最高结果	必要边界
D10-M0	组件契约样张	可说明 token、API 与状态；不声称可导入或采用
D10-M1	实现支撑的系统试验版	有真实源码、public entry、状态证据与文档；可仍限本仓库
D10-M2	可采用 Preview	有版本化可消费边界、显式 exports、独立消费者及行为/a11y 证据
D10-M3	Stable 系统	有生产采用或双消费者验证、升级/弃用、owner 与发布历史
D10-M4	治理型多产品系统	有多平台或多品牌采用、兼容政策、同步与长期治理证据

直接选择与任务相称的档案；更高档案只增加被其 claims 触发的 gate。未满足证据时降低实际 claim ceiling，不用“完成度”掩盖缺口。

2. 建立 concern authority chain

先列消费者和 concern，再实现。一个 concern 只能有一个权威 owner；多个原生母版可以并存，但导出、截图、catalog 和 Gallery 都是派生物。