状态：完整工作稿，拟议、可调整。YUDS／实现项目／产品三方职责已确认；本章对负责人、贡献、发布和验收的细则仍是建议，尚未任命人员、批准排期或完成实现验证。D06 中性设计任务、D05 四端设计目标与 Web WCAG 2.2 AA 目标已采用；当前真实四端测试全部未执行。 更新：2026-10-18（UTC+8）
1. 治理目标
让团队能够回答五个问题：目前采用哪条规则；谁对它负责；哪个实现版本承载它；在哪些真实环境和任务中验证过；变化后谁需要迁移。治理不以文档数量、设计页数或组件数量衡量完成度。
每个共同能力应有清楚的主档、稳定标识、版本、适用范围与证据。设计、代码和产品可以分别演进，但不能在同名能力下长期隐藏不同含义。
2. 已确认的职责与拟议的负责人分工
| 层面 | 已确认或细化的责任 | 不应代替的责任 |
|---|---|---|
| YUDS 规范 | 共同设计语言、组件行为、业务交互模式、可用性与无障碍要求；建议由指定规范负责人维护决定与适用范围 | 产品公式、业务审批、所有实现 API |
| 设计资产 | 建议由设计维护者负责变量、组件变体、样例、状态及与规范的对应 | 以图稿存在证明代码或流程已完成 |
| 实现项目 | 按规范实现组件、平台行为、测试及规范映射；由实现维护者维护实际 API 与版本 | 擅自用一个平台的限制覆盖共同规范 |
| 产品与领域 | 业务模型、计算规则、流程配置、权限政策、任务范围和端到端验收 | 把个别产品规则未经判断提升为通用能力 |
| 验证与发布 | 建议由明确的验证责任人与发布责任人核实证据、缺陷、迁移和版本说明 | 用自动化绿灯代替所有人工判断，或自行豁免安全责任 |
角色可由同一人在小团队中兼任，但每项变更需要一个明确的最终责任人。尚未指定的角色写“待指定”，不能凭文档作者身份推定其获得发布或风险接受权限。
Teakit 的背景定位为 TypeScript 库与框架，Teasim 为 UI 体系。此背景不决定 YUDS 必须由 Teasim 承载、必须依赖 Teakit，或所有平台使用同一栈。实际承载、依赖、仓库与包名须另行决定。详见 规范、设计与实现映射。
3. 分别记录四类状态
| 状态轴 | 回答的问题 | 记录方式 |
|---|---|---|
| 决策状态 | 团队是否已确认这项规则 | 已确认／拟议／待验证／被替代；保留依据 |
| 资产状态 | 哪些交付物实际存在 | 规范、设计、Token、实现、示例分别记录版本或缺失 |
| 成熟度 | 当前能力适合怎样使用 | 草案 draft／已验证 validated／已弃用 deprecated，并注明范围 |
| 测试状态 | 某次检查真实发生了什么 | 通过／失败／未执行／不适用；不适用须附理由 |
本章“已验证”成熟度不等于全平台支持、零缺陷或认证，也不能替代逐项测试结果。讨论完成、文件入库和代码合并分别是不同事件。
4. 变更的最小闭环
- 提出问题：真实任务、现有困难、影响人群和证据。
- 判断归属：基础、组件、模式、模板、实现或领域；先检查现有能力能否解决。
- 形成提案：规则、适用边界、状态、替代方案、风险及可观察验收。
- 审阅并记录决定：相关维护者参与；无结论时继续标为拟议。
- 限定范围试验：明确试验版本、使用者和限制，不默认全产品发布。
- 验证并发布：发布实际通过的范围，附未完成项、迁移和恢复限制。
- 反馈与维护：收集任务失败、使用困难、兼容问题和例外；必要时修正或弃用。
完整机制见 贡献、决定、版本与迁移；质量门禁见 质量基线、门禁与验收证据。
5. 建议的分阶段交付
以下按依赖关系描述，不构成已批准排期或首版清单。
- 基线成形：已确认定位与职责；整理可调整的完整规则、术语、状态和未决问题。完成条件是能对真实任务提出一致的设计判断，不能宣称已有组件库。
- 通用任务闭环：当前阶段按 D06 选用固定合成对象和受控事件，连接基础、组件、模式和页面，补齐异常、权限和恢复；实际运行另留可复现证据。真实产品流程在后续集成阶段选择并验证，不作为通用设计启动的前置，也不以静态顺利路径代替运行。
- 可复用实现：建立版本映射、设计资源、组件实现和测试样例；验证另一条具有不同风险的任务，检查是否过度贴合单一产品。
- 受控发布与迁移：公布实际支持范围、兼容规则、责任人和已知问题；完成使用方迁移与回归。
- 持续治理：按实际问题和使用情况安排复查，处理弃用、平台升级和例外到期。复查频率待团队能力与风险明确后决定。
6. 发布证据的最低要求
每次发布应能定位规范与设计资产版本、实现包与提交、支持矩阵、关键任务测试、缺陷和例外、变更影响及迁移步骤。缺少哪类证据就明确标注，不能用一条“已完成”概括全部交付物。发布清单见 贡献、决定、版本与迁移，证据格式见 质量基线、门禁与验收证据。
一个包通过单元测试，不能说明组合页面的键盘、读屏或业务审批通过；一个产品流程通过，不能说明该组件在全部平台、主题、密度和语言下通过。
7. 本章目录
- 贡献、决定、版本与迁移
- D05 可访问设计基线、质量门禁与测试清单：质量基线、门禁与验收证据
- 设计、规范、代码、领域与证据映射：规范、设计与实现映射
8. 待决定事项
- 责任与承载：规范和发布责任人，正式主档与代码仓库的承载关系。
- 范围与质量：D06 中性设计任务、D05 四端设计目标与 Web WCAG 2.2 AA 目标已采用；真实产品任务、实际支持矩阵及任务性能证据仍待建立。
- 发布与维护：版本号、发布渠道、缺陷分级、例外期限和弃用窗口。
上述事项须有明确决定依据后再更新决策与讨论记录，不因本章已写完而自动批准。
9. 当前交付的可复核边界
规范完善所依据的评审收据索引（评分、全量覆盖、差异、核验与待决策证据）见 贡献、决定、版本与迁移 第 11 节。日常采用从规则主档进入，核验从 规范、设计与实现映射 第 12 节登记进入。
规范质量评价的是条款是否一致、可执行和可追溯；实现成熟度评价的是固定构建上的实际资产与任务证据。二者分别评分，不能相互加分。当前真实四端测试全部未执行；各端缺口见 质量基线、门禁与验收证据 第 10 节，未关联资产不等于资产不存在。