决策与讨论记录

状态：本页是 YUDS 的决策日志，按日期记录用户确认的方向与原文、代理依用户授权采用的可修订设计输入，以及仍属拟议、待验证或已被替代的方案。建议、研究推导与候选方案不写成已批准规则；所涉组件、视觉与平台细则均未经产品实现验收或真实平台运行。 更新：2026-10-22

本页维护 YUDS 的已确认边界与讨论结论，不把建议、研究推导或候选方案写成已批准规则。体系议程见体系大纲与阅读路线，入口见YUDS 统一设计系统。

记录方式

每次讨论后，归纳问题、适用范围、结论与状态、理由及取舍、未决问题、验证方法和相关来源。已有专题直接更新主档；本页保留关键决定与变更索引，避免重复保存一整份规范。未决内容继续明确标记，不通过整理措辞悄悄变成决定。

状态使用：已确认／拟议／待验证／被替代。已确认方向与实现验证通过分别记录。正式改变既有决定时，注明替代关系、日期与影响范围。

2026-10-18 · 建立 YUDS 讨论基线

日期按 UTC+8 记录；用户原始请求时间为 2026-10-17 UTC。

已确认

• 名称为 YUDS — Yiplex Unified Design System。
• 为 Yiplex 建立自己的统一设计系统，主要面向数据复杂型企业软件。
• 参考此前整理的 OUDS 研究。
• 核心参考产品为 AMKit；用户提供的 demo 用于理解业务流程，不代表最终设计。
• 先建立大纲，再逐条讨论；每次讨论的总结按现有知识库维护约定更新归档。

依据：用户明确提出以上要求。原话摘录：“你先帮我建立这套系统的大纲，然后我们开始逐条讨论。讨论的过程你进行总结，然后把总结内容按照要求更新到知识库里”。

提供的讨论稿

体系大纲与阅读路线 v0.1 提出十二章：定位与边界、设计原则、信息架构与工作空间、视觉与语义基础、基础组件、复杂数据工作模式、数据表达与分析、表单与业务流程、系统状态与权限、页面与端到端模板、跨平台与智能交互、治理交付与质量。

状态

拟议。这是供逐条讨论的地图，不是用户已批准的完整规范、实现排期或首版功能清单。无障碍、国际化、键盘、权限表达、状态和质量验证贯穿各章，不等到最后补做。

下一项讨论

以 AMKit 为核心参考，先理解 demo 业务流程，再决定具体检验任务。

用户已在后续消息明确核心产品为 AMKit，并提供 https://demo.amkit.com ↗，强调它表达业务流程，不是最终设计。下一步据此开展只读业务调查，再提出设计建议与落地方案；本条记录不宣称调查已经完成（调查结果见下文「AMKit 演示业务调研完成观察」）。目标是确定首批使用者、任务与失败条件，再收敛原则和质量基线。AMKit 的“筛选资产 → 查看经营数据 → 发现异常 → 跟进处理”仅是候选，不是已确认的首发范围。

尚未决定

• AMKit 中优先的角色、具体流程与可量化目标。
• 首期支持的平台、实现技术栈及支持版本；不预设只做 Web，也不把过往 OUDS 原生研究当作此次平台决定。
• 品牌色、字体、间距、圆角、token 具体值与命名。
• 组件与模式首版目录、密度级别、主题组合和默认行为。
• AI 是否进入首期，及其允许承担的任务与执行边界。
• YUDS 与 Teasim 的 UI 体系如何衔接；与 Teakit 库框架、Tealess 能力及产品层如何划界。
• 代码或设计资产是否采用 OUDS；当时只参考研究方法。

关联事实与边界

2026-10-12 18:39（UTC+8）用户已明确恢复 Teakit 提供库与框架、Teasim 做 UI 体系。此前此处误沿用当日较早的互换方案，2026-10-18 已按原始消息时序校正。参见 Teakit 产品定位与边界 ↗、Teasim 产品定位与边界 ↗。这组已确认背景不自动决定 YUDS 的产品承载关系。

既有 OUDS 学习索引记录 68 篇专题及一篇总览，此次重点参考整体组织、基础架构、数据表达与自建决策方法。外部资料复核范围和读取限制见大纲的参考说明；未运行 SDK，也未完成产品实现验收。

建立基线时保留 OUDS 原档，新建 YUDS 入口、大纲与本记录。讨论与取舍保存在工程实践中；未来产品特有方案仍归产品档案。

2026-10-18 · 补全系统定义

已确认的修订要求

原先“YUDS 是 Yiplex Unified Design System，面向数据复杂型企业软件”的描述不够完整，应参考 OUDS 更清晰地说明系统本身。

用户原话：“YUDS 是 Yiplex Unified Design System，面向数据复杂型企业软件。这样的描述就不够完整，你参考 OUDS 写得更加清晰”。

修订内容

入口补充服务团队、共同语言与用户价值；大纲补充体系组成、跨产品与跨平台的统一边界、AMKit 参考关系和当前建设阶段。完整定位以体系大纲与阅读路线为主，入口只保留简要介绍和导航（已确认的定位原文后移入定位、使用者与职责边界）。

当时状态

扩展定位是回应反馈的修订稿；其后用户确认的范围见下节。不把用户要求写清定义视作已经逐项批准所有规则或交付物。十二章范围保持不变，目标平台、技术栈、资源交付与产品承载关系仍待后续讨论和验证。

参考依据

既有 OUDS 统一设计系统中文解读 ↗、OUDS 深读 02：设计系统原则与治理 ↗及官方 OUDS 介绍 ↗将统一设计系统解释为跨团队、品牌和平台衔接设计与开发的整体。YUDS 的受众、复杂工作价值和体系说明是结合 Yiplex 情境编写的定位，不是 OUDS 原文翻译，也不沿用 Orange 品牌与支持承诺。

2026-10-18 · 确认定位并删除验证产品介绍

用户原话

“AMKit 是首个核心验证产品， 这个不需要写，其他同意”。

已确认

从 YUDS 对外定位和介绍中删除“AMKit 首个核心验证／参考产品”及其衍生说明；其余定位描述按用户反馈确认。入口和大纲开头同步更新，保留“正在建设”与资源、实现和支持范围仍需建立验证的阶段说明。

范围

这次同意针对当时的系统定位，不代表十二章具体规范、组件清单、技术栈、支持平台或产品承载关系全部获批。既有“拟议／待验证”边界继续有效。

调研安排

删除定位介绍中的产品句，不等于取消 AMKit demo 业务调研。用户提供 demo 以帮助理解业务流程、而非作为最终设计，这项调研任务继续；历史记录保留供追溯，当前系统介绍不再列出 AMKit。

2026-10-18 · 分层阅读编号提案

状态

拟议，未执行重命名。后续结论见下文「确定扁平存放，讨论固定三段编号」与「全知识库统一固定六位编号」。

用户提出以 yuds-01-index 等名称表达阅读顺序，以 0101 表示 01 下的二级，每层占两位，并询问这种方法是否合理。这是命名方法讨论，不视为立即改名的指令。

建议范围与结构

先在 YUDS 内讨论，保留英文主题和全库唯一文件标识；目录与编号层次对应，通常控制在三层。纯语法示例为 01-section/ 下的 yuds-01-index.textbundle 与 yuds-0101-topic.textbundle；再深一层可用 yuds-010101-topic.textbundle。这些示例不替换十二章顺序，不表示已决定 01 的主题，也不要求预建空目录。正式编号前先确定总入口、十二章与决策记录的位置，以及一级编号的意义。

与现有维护约定的关系

英文小写、数字、连字符、保留英文描述、TextBundle 整包移动及改名同步全库 Wiki 引用均保持不变。现有 101-10-... 规则针对产品笔记，不自动约束工程实践下的 YUDS；新编号方案也不自动修改其他目录或全库规则。编号确定后应尽量稳定，插入内容不默认触发连续重编号；必要时先决定留号或仅调整索引阅读顺序。

排序核查与限制

2026-10-18（UTC+8）核对 FSNotes 固定版本源码 ↗，标题排序使用 localizedStandardCompare。Apple 将其定义为 Finder 式排序 ↗，具体行为受系统与地区设置影响。连续数字串不能直接当作树形阅读路径：同一扁平列表中，0101 可能作为数值 101 排在 02 之后，不能保证 01 → 0101 → 02 的顺序。这是源码与排序机制推导，当时尚未在用户的 FSNotes 环境实测。

若主要按分层目录阅读，每层两位、连续编码的方案可继续评估；若要求“所有笔记”混层展示时也按树序，应比较分段编号（如 01-01）或统一总宽编码，并用小样实测后再定。需要标题升序才能发挥编号排序作用；置顶、搜索匹配及时间排序仍可能影响列表顺序。目录显示与笔记列表不是同一排序机制，不能仅凭文件名承诺整个应用展示一致。

当时待确认

连续或分段形式、总入口与章节编号、索引所在层级、是否需要混层排序，以及插入和弃用策略。确认后才生成迁移映射、同步所有 Wiki 链接并检查回链；提出时只更新本记录，不改文件名、目录路径、十二章范围或 FSNotes 设置。

2026-10-18 · OUDS 全量副本的编号排序验证

状态

验证结果已记录，命名方案当时仍待确认。验证只在云端副本上作源码审计与排序模型对照，没有改动 OUDS 原笔记、文件路径或 FSNotes 设置。前节的连续编号与简单分段编号均需结合以下结果理解，不能直接作为已验证的迁移方案。

数据范围

以锁定的知识库提交为准，实际 OUDS 目录有 71 个 TextBundle：69 篇内容，以及学习索引与覆盖清单两个导航。此前“68 专题加总览”的 69 篇内容口径不包括这两个导航。验证依据既有 20 步学习顺序建立可逆映射，未重新批准知识架构；三级父子边界另用合成案例检验。

源码依据

上游 FSNotes 固定提交的 Storage.swift 543–570 ↗ 按显示标题调用 title.localizedStandardCompare，置顶优先；Note.swift 1414–1445 ↗ 的标题解析涉及 YAML 标题、正文首行与文件名。只改文件名不保证改变显示标题排序；修改时间排序、降序、置顶及搜索匹配优先仍会影响结果。这是上游源码行为，不是对用户安装版本或设置的读取。

本库维护约定将“首行作为标题”和“按标题自动重命名”均关闭管理，也不新增 YAML 标题；这次验证不改变该约定。所谓“显示标题同号”，是保证实际参与排序的标题带有对应编号：在本库约定下应沿用文件名；如果以后明确选择首行为标题或已有 YAML 标题，才需同步核验这些显示标题，不默认要求修改全部中文正文标题。

模型对照结果

在云端使用 Python 字典序与 Linux Node 数值排序模型，对英文、简体中文运行 51 组案例。这些结果不是 Apple Foundation 或 FSNotes 实机验收。

• 连续 01 / 0101 / 010101 在混层数值排序模拟中失败；如 19、20 会排在 0501 之前。
• 简单分段 01 / 01-01 不保证父页先出现：01-01-color 在测试中先于 01-index。
• 同目录内同级两位编号的分组测试通过；固定三段、空层补 00 的父子混排候选也在该模型中通过，但仍待 Apple 与应用实测。
• 插入编号、重复排序键、超过两位容量或扩展层数均需要额外规则，不能临时增加一位解决。

当时的优先建议（已被后续用户反馈否决，见下节）

采用真实分层目录，每层两位编号，保证实际显示标题的排序键一致，先满足单目录同级阅读顺序。目录索引预留 00 号可作为候选，未作最终决定。当时 OUDS 全部笔记在同一目录，因此此建议涉及另行讨论目录组织，不能当作已批准迁移。

只有确实需要全库混合列表仍保持严格树序时，再考虑统一三段、每段两位、空层补 00，例如父页 01-00-00、二级父页 01-01-00、三级内容 01-01-01、下一章 02-00-00。这仍是待验方案，不替换 YUDS 十二章，也不决定最终一级编号。

证据与后续边界

交付《OUDS 层级编号排序验证》报告及验证包，包含 71 项映射、51 组案例、模拟结果和 macOS 只读验证脚本。最终采用前仍需验证真正的 Apple Foundation 比较函数，并在临时副本中检查实际 FSNotes 标题升序、显示标题、置顶与搜索状态；不需要先改原库。这次只追加结论，不重命名、不搬目录、不实施批量链接迁移。

2026-10-18 · 确定扁平存放，讨论固定三段编号

用户原话

“首先我不建议采用分层目录的方式，因为内容我想要更加扁平的, 你还有更好的建议吗”。

已确认

YUDS 内容采用扁平目录思路，不按阅读层级建立物理子目录。前节“优先采用真实分层目录”的建议已被用户否决，不再作为当前推荐。逻辑层级与阅读顺序通过文件编号和索引导航表达。

新的建议（当时仍待确认）

在同一个 YUDS 目录中，采用固定三段、每段两位的编号；不足的层级补 00，后接英文主题。语法示例：

• yuds-01-00-00-index.textbundle
• yuds-03-00-00-foundations.textbundle
• yuds-03-01-00-colors.textbundle
• yuds-03-01-01-semantic-colors.textbundle

以上仅演示父页、二级、三级在扁平列表中的编码方式，不把 foundations 改定为第三章，也不替换现有十二章顺序。总入口和各章的具体编号应另行确定；不因 00 占位就自动创建对应空页。

理由与代价

固定长度的分段键可以区分层级，00 占位使父项有机会排在子项之前；云端字典序与数值排序模拟已支持该候选，但未完成 Apple Foundation 或用户当前 FSNotes 实机验收。采用时仍依赖标题升序和实际显示标题含相同排序键，置顶、搜索和时间排序会改变展示。文件名会更长；中间插入、重排或超过三层可能需要重新编号并同步全部 Wiki 链接，不能承诺零维护成本。英文主题保留可读性，索引负责解释阅读顺序与关联关系。

执行边界

这次只确认扁平存放偏好、记录三段编号建议。用户尚未批准具体命名方案或立即迁移；未改文件路径、目录、正文标题、十二章内容或 FSNotes 设置。

2026-10-18 · 固定六位连续编号的补充验证

用户问题

“用010000代替01-00-00 这个顺序会错乱吗”。

结论

统一固定六位、每层两位、未使用层补 00 时，010000 可作为 01-00-00 的连续形式；这与前面被否定的变长 01 / 0101 / 010101 不同。固定宽度能使字典序与数值排序按同一层级键比较，前提是不混用不同位数。

新增证据

在既有 71 项 OUDS 映射上删除三段编号之间的连字符，71 个文件名与 71 个标题键均唯一。对全量文件名、全量标题与 7 项父子孙样本，分别运行字典序、英文及中文数值排序模拟，新增 9 组全部通过。样本次序为 000000 → 010000 → 010100 → 010101 → 010102 → 010200 → 020000。这仍是云端模拟，不是 Apple Foundation 或 FSNotes 实机验收。

适用边界

• 最多三级，每层 01–99，00 保留为空层；不得混入 01、0101 等变长码。
• FSNotes 仍需按实际显示标题升序，显示标题含相同编号；置顶、搜索和时间排序的影响不由编码解决。
• 沿用本库关闭首行标题的维护约定，不因此新增 YAML 或修改中文正文标题。
• 连续六位更短，但层级分隔不如带连字符直观，插入或重排仍可能带来链接更新成本。

当时状态

六位连续码是通过模型测试的候选，尚未最终确认命名规则或授权迁移（随后由下节确认）。YUDS 扁平存放决定不变；这次只追加结论，没有重命名或调整十二章。

2026-10-18 · 全知识库统一固定六位编号

状态

已确认，执行迁移。用户明确要求：“现在统一固定用这个方式来处理知识库的内容，就是每一个文件夹下面的内容都需要按照这个规则来处理。”此决定替代前述“六位连续码尚待确认”的状态；前文保留为讨论历史。

当前规则

• 文件名由主题前缀、固定六位连续码和英文主题组成；每层两位，缺位补 00，序号 01 起，最多三级。
• 同主题文件夹内扁平存放，保留全库现有主题目录边界。
• 按已有入口和索引确定阅读顺序，不因编码新增空章节或改变十二章讨论内容。
• TextBundle 包内固定文件和附件不改名；根导航与维护文件保留稳定名称。
• 改名同时修复全库引用。

详见知识库维护约定 ↗。

迁移先处理 OUDS 与 YUDS，再按既有分类扩展全库。云端模型验证不等于 macOS FSNotes 实机验收，未改用户的应用设置。

2026-10-18 · AMKit 演示业务调研完成观察

状态

观察已归档；设计建议与落地方案仍属拟议。完整研究主档见 AMKit 演示业务流程审阅与 YUDS 落地建议 ↗，资料归属 AMKit 来源与核查，避免在工程实践重复维护产品细节。检查截至 2026-10-17 21:15 UTC；当前 demo 是业务流程原型，不是最终设计。本条更新此前“调查未完成”的进度，不改变 YUDS 正式介绍，也不重新加入“AMKit 首个核心验证产品”。

已观察

资产 100/100、组合 10/10 已加载，不等于每条全部验收。双击版本可进入投资模拟与滚动 BASE 工作台；Hold 九步有内容，含空间矩阵、楼层画布、租赁单元详情与收入假设。商业、办公、酒店、土地四类抽样显示模板复用，不能证明行业专用模型完整。Sale 七步及 Mixed 五步正文为空；预算显示“Unable to load budget workspace”。

未知／待确认

创建、编辑、成员配置、实际数据 View、版本比较、组合详情与 Marketplace 本次未取得可读内容；不能据此证明尚未实现。未提交计算或写入，未验证真实计算依赖、数据同步、审批和权限继承。授权格与模型导航步骤不直接等同。

拟议的跨产品抽象

统一对象与版本身份、数据截止日与来源、状态和责任人表达；定义数值单位与期间、Loading/Empty/Error/PermissionDenied/Stale/Partial，以及显式打开、键盘访问、筛选恢复、可解释禁用与错误反馈等交互契约。多期矩阵、流程步进、版本选择与差异比较是候选通用模式。资产、物业、经营策略、租赁假设、税务、贷款与行业模型规则留在产品层，不直接固化为 YUDS 规范。

下一项讨论

优先澄清 Property 与 Template 的绑定、STEP 的任务／权限／审批含义、BASE/F/B 版本冻结与生效规则，以及数据来源和截止日。再选择一个有边界的纵向业务闭环验证；首期角色、平台、技术栈、组件范围和阶段排期尚未获批。全文的优先级、数据契约和五阶段路线是建议，不是既定实施计划。（2026-10-19「通用组件优先与参考体系分工」一节已把优先级改为先做通用组件与受控组合。）

2026-10-18 · 确认 YUDS、实现项目与产品的职责边界

用户原话

“同意你的职责划分”。

状态

已确认。这次同意针对以下三方分工：

• YUDS 规定共同设计语言、组件行为、业务交互模式，以及可用性与无障碍验收要求。
• 具体实现项目将规范实现为组件代码，并维护规范与代码的对应关系。
• 产品负责业务模型、计算规则与流程配置。

边界示例

表格筛选、编辑反馈、错误提示与键盘操作属于 YUDS 的交互规范；资产估值公式属于产品业务规则；组件代码及其规范对应关系由具体实现项目维护。

确认范围

这里只确认职责分工，不指定具体实现项目、框架、平台、技术栈或产品承载关系，也不代表具体组件规则、验收指标及首版交付范围已获批。YUDS 正式介绍继续不写“AMKit 首个核心验证产品”。

同步更新

职责边界当时记入体系大纲与阅读路线第 01 章（现位于定位、使用者与职责边界），YUDS 统一设计系统入口更新讨论状态；大纲末尾的调研进度按已归档的AMKit 演示业务流程审阅与 YUDS 落地建议 ↗修正。AMKit 的观察结论与产品细节继续以该产品主档为准。

2026-10-18 · 确认一致与适配、清晰与复杂度两条原则

状态

已确认并按展示原文入库。用户先后表示“同意语义与行为一致，布局与密度按场景适配”和“清晰优先，保留必要信息，逐步呈现复杂度 这个也同意”。在完整文案展示后，针对“上一条一致与适配和这一条清晰与复杂度的两份完整文案，你看是否都可以按原文入库？”回复“可以”。

两份原则正文、具体要求及示例原样保存在当时大纲第 02 章（现为六条设计原则），本页只记录确认事实，不重复规范正文。此次未增加其他原则或验收条款；既有职责划分保持不变。

当时的入库流程（已被下节新流程替代）

用户明确要求“你在写入了知识库之前，需要先把具体的内容写出来，我确认”。即先展示拟写入的具体文案，经用户确认后再更新知识库；对原则方向的认可不自动视为批准未展示的详细条款。

2026-10-18 · 采用先写后展示流程，确认数据可信度原则方向

流程已确认

用户原话：“或者你可以先写入，写入后再把内容展示出来，如果我要调整的话我跟你说，不需要调整的话就默认通过”。自此按先写入、再展示实际写入全文、收到反馈后修订的方式推进；不需要调整时默认通过。此流程替代前节“先展示并确认后入库”的要求，仍逐条推进。

原则方向已确认

用户原话：“数据含义明确，状态真实可辨，依据可追溯 同意”。

默认采用、可修订

该原则的简短定义、五项具体要求及工单统计界面示例写入当时大纲第 02 章（现为六条设计原则），随后展示实际写入全文。这些细则按上述流程整理，不记为用户已逐项明确确认；如有调整，更新正文并记录变更。

范围

此次只新增这一条原则；计算与推导逻辑仍由产品定义，YUDS 规定表达与交互要求。未决定技术实现、审计后台或首版交付范围，未进行产品实现验收。六位编号与 TextBundle 结构保持不变。

2026-10-18 · 确认操作预期、过程反馈与恢复原则方向

原则方向已确认

针对“操作后果可预期，处理过程可感知，出现问题可恢复”的建议及其要点，用户回复“同意”。

默认采用、可修订

沿用先写后展示流程，将该原则的一段定义、五项具体要求及 100 条记录中 97 条成功、3 条失败的示例写入当时大纲第 02 章（现为六条设计原则）。整理后的细则不记为用户已逐项明确确认；如有调整，再更新正文并记录变更。

范围与边界

此次只新增这一条原则。

• 要求明确操作对象与范围、真实反馈过程及结果、保留输入和任务上下文，并提供与实际能力相符的恢复路径。
• 不承诺所有动作都能撤销，不自动重新执行不能安全重试的操作，不把结果未知直接当作失败。
• 不可逆或高风险操作事先说明并确认，普通操作不处处弹窗。
• 不规定后端技术实现、行业权限细则或首版交付范围，未进行产品实现验收；既有职责边界保持不变。

2026-10-18 · 确认易理解的基础操作与高频任务效率原则方向

原则方向已确认

针对“基础操作容易理解，高频任务高效完成”的建议及其要点，用户回复“同意”。

默认采用、可修订

沿用先写后展示流程，将该原则的一段定义、四项具体要求及新用户逐条编辑、熟练用户使用键盘与批量编辑的示例写入当时大纲第 02 章（现为六条设计原则）。整理后的细则不记为用户已逐项明确确认；如有调整，再更新正文并记录变更。

范围与边界

此次只新增这一条原则。

• 常用操作名称与入口清楚，高频任务按实际重复成本提供效率方式；普通路径与快捷路径遵守相同的权限、校验和风险保护。
• 返回时仅在权限允许、数据与上下文仍有效的前提下保留筛选和位置，不盲目恢复过期选择或重复执行操作。
• 不要求每个组件都支持批量处理，不预设各平台实现，也不覆盖既有一致性、信息清晰、数据表达与操作恢复原则。
• 不确定平台、技术栈或首版交付范围，未进行产品实现验收；既有职责边界保持不变。

2026-10-18 · 确认可访问的基本任务与替代输入原则方向

原则方向已确认

针对“基本任务可访问，不依赖单一感官或输入方式”作为第六条核心原则的建议，用户回复“同意”。

默认采用、可修订

沿用先写后展示流程，将该原则的一段定义、五项具体要求及记录分配界面示例写入当时大纲第 02 章（现为六条设计原则）。整理后的细则不记为用户已逐项明确确认；如有调整，再更新正文并记录变更。

范围与边界

此次只新增这一条原则。

• 涵盖多通道信息表达、符合平台的键盘或替代输入、焦点顺序与弹层返回、辅助技术语义和反馈，以及文字放大、可读性与减少动态效果的合理适配。
• 基本任务的完整可访问路径是底线，不表示其他任务可忽略可访问性；各平台可以采用不同操作方式，业务含义、权限与风险保护保持一致。
• 不指定 WCAG 版本或等级、具体尺寸与对比度标准、平台及辅助技术支持矩阵，也不声称产品已符合任何可访问性标准；具体规则和验收方式仍待后续讨论。
• 当时第 03 章保持原有讨论稿，未新增已确认方案；既有职责边界保持不变。

2026-10-18 · 确认业务对象与用户任务的导航组织方向

方向已确认

针对“以业务对象＋用户任务作为导航组织基本方向吗”的问题及其说明，用户回复“同意”。

默认采用、可修订

沿用先写后展示流程，将一段定义、四项具体要求及从合同或待办进入同一合同审核任务的示例写入当时大纲第 03 章（现为信息架构与工作空间）。整理后的细则不记为用户已逐项明确确认；如有调整，再更新正文并记录变更。

范围与边界

• 此次只确认导航围绕业务对象与用户任务组织，使用面向用户的名称，使角色所需且有权使用的入口容易找到；不同入口指向同一业务事实并遵守相同权限，进入工作后明确对象、任务及必要上下文。
• 不要求每个产品建立两套导航或为所有对象增加版本，不照搬 AMKit 层级。
• 全局与对象内部导航的职责、具体布局、侧栏或顶栏、多租户结构与工作空间层级仍待讨论；未据此确定平台、实现栈或首版范围，也未作产品实现验收。既有职责边界保持不变。

2026-10-18 · 确认全局与对象内部导航的职责划分

职责划分已确认

针对全局导航回答“去哪类工作”、对象内部导航回答“当前对象的哪一部分”，以及内部切换时对象明确、切换另一对象时变化明确的建议，用户回复“同意”。

默认采用、可修订

沿用先写后展示流程，将一段定义、四项具体要求及合同 A 内部切换与切换至合同 B 的示例写入当时大纲第 03 章（现为信息架构与工作空间）。整理后的细则不记为用户已逐项明确确认；如有调整，再更新正文并记录变更。

范围与边界

• 明确全局工作类别与当前对象内容分区的不同作用范围、当前所在位置，以及对象切换与视图切换的区别。
• 导航层级与布局仍按实际任务讨论，不限定永远只有两级，不预定侧栏或顶栏，不要求所有对象具备版本；返回时继续遵循第 02 章既有的有效上下文保留规则。
• 列表、详情与返回路径的进一步方案仍待讨论，当时未写入新的方案。
• 未确定平台、实现栈或首版范围，未作产品实现验收；既有职责边界保持不变。

2026-10-18 · 补充按业务流程操作的支持

用户原话

“除此之外也需要按照业务流程来操作”。

已确认的补充方向

在已确认的业务对象与用户任务组织方向上，增加业务流程操作支持。对象说明处理什么，任务说明当前做什么，流程说明事情如何推进；此补充不替代此前方向，也不表示需要重复建立一套菜单。

默认采用、可修订

沿用先写后展示流程，将一段定义、四项具体要求及合同起草、审核、签署、生效的示例写入当时大纲第 03 章（现为信息架构与工作空间）。整理后的细则不记为用户已逐项明确确认；如有调整，再更新正文并记录变更。

范围与边界

• 流程按任务需要表达当前阶段、已完成事项、下一步、前置条件与责任人或负责角色，并衔接对象与任务。
• 产品定义顺序、跳过、退回、并行与完成条件，YUDS 定义呈现和交互反馈。
• 不强制线性流程，不要求每个产品或对象都有固定步骤，不把浏览信息或切换页面等同于改变业务状态。
• 流程步骤的具体组织及流程操作与对象浏览之间的切换方式当时仍待讨论，不预定控件和布局；未决定平台、实现栈或首版范围，未作产品实现验收。

2026-10-18 · 衔接流程操作与对象浏览，完善十二章完整初稿

用户新授权

“同意，我现在去洗澡，你按照顺序把整个设计系统完善”。按此授权不再逐项等待确认，按原十二章顺序补齐可阅读、可用于设计和开发讨论的文档初稿；沿用先写入、再展示、按反馈修订的方式。展示时同时说明下一项讨论问题。

此次同意对应的衔接方向

• 查看相关资料后回到原任务，保留仍然有效的输入与上下文。
• 区分业务当前阶段和正在浏览的内容。
• 发生并发修改或任务已被处理时提示重新确认，不以旧内容直接提交。

具体规范见导航、深链接与上下文保留与权限变化、并发修改与保存冲突。

文档组织

保留现有入口、大纲与决策记录名称；原大纲内已确认的定位、职责与原则原文移入第 01、02 章，已讨论的导航与流程正文移入第 03 章。原文不改写；主档通过专题链接定位。本记录早前提到“大纲第 02／03 章”的文字属于历史位置，当前主档分别为六条设计原则和信息架构与工作空间。

新增范围

十二章主线与基础、组件家族、复杂数据模式、数据表达、表单与流程、异步权限并发、页面任务、跨平台及 AI、治理交付的专题。各专题提供用途、状态、操作规则、例子、失败路径及验收方法。完整目录见体系大纲与阅读路线。

状态边界

已明确确认的方向与原文保留其状态。此次新写的细则、候选参数、平台基线、组件范围、AI 能力和实施顺序均为可调整建议；不记成用户逐项明确确认，不将沉默等同于实现验收。首期平台、具体技术栈、品牌最终取值、承载项目、AI 首期范围、发布承诺仍需后续决定。

未执行事项

未改应用代码、网站、Stitch、用户电脑或 FSNotes 设置；未声称组件已开发、SDK 已接入或产品测试已通过。文档结构与引用核验不替代设计或实现验收。

下一步建议

先选一条真实任务及支持环境，随后按任务验证视觉基础、组件与恢复路径。每次展示正文并带出下一个问题，继续保留可修订的工作方式。（2026-10-19「通用组件优先与参考体系分工」一节已把先定产品任务的优先级改为先做通用组件与受控组合。）

2026-10-18 · 工作空间边界文档审阅

状态

文档走查完成，新增细则为可调整建议，产品测试未执行。用户要求开始审阅，沿用先写后展示流程；完整发现、证据、三个场景及实际修订条款见工作空间边界审阅（2026-10-18）。

审阅修正了批量恢复的无条件能力措辞；补齐工作空间与安全范围的区分、切换时输入和在途动作归属、多窗口浏览位置、保存视图范围、跨范围比较与后台任务、可选 AI 上下文。已确认方向和原文保持不变。工作空间与租户／组织关系、跨范围能力、产品版本模型均未代用户定稿；没有代码、demo 或真实产品测试结果。

2026-10-18 · 确认工作空间权限范围与跨范围能力边界

用户原话

“工作空间的权限范围明确且稳定，跨范围能力单独定义”。

方向已确认

工作空间采用清楚声明、不会随页面或对象切换而隐式扩大的数据权限范围；跨范围能力独立定义和授权。范围可以是单一组织，也可以是明确定义且获准共同访问的数据组，不据此确定工作空间等于租户或某个组织层级。稳定不意味着冻结权限；当前授权及撤销继续约束展示与执行。

默认采用、可修订

沿用先写后展示流程，定义、四项要求与示例集中写入信息架构与工作空间第 3.5 节；不将整理细则记为用户逐项明确批准。入口、大纲及工作空间边界审阅的当前状态同步更新，原审阅结论和条款快照保留为当时记录。

仍未决定

各项跨范围能力是否提供，是否允许写入及具体作用对象；工作空间与租户／组织的映射；保存视图选择固定范围或使用时显式解析。已核对保存视图、后台任务、权限撤回与可选 AI 建议：它们继续受已声明范围及当前授权约束，没有因此增加跨范围访问或执行能力。实现验收仍未执行。

2026-10-19 · 与 Billgo Standard Design 对齐

已确认，规范对齐；实现未验证

用户明确选择：① Token 架构严格采用 Billgo 两维体系；② 一个任务上下文一个主操作；③ Typography 统一三角色九档，保留业务用途映射。

• 颜色消费契约采用 role + step，七角色统一；替代此前三层公共颜色 Token 架构候选。物理色板是配置输入，图表数据颜色独立。见Token 契约、主题与状态。
• 主按钮限制按独立任务上下文，而非机械按整页；统一八种视觉变体。见操作组件：按钮与动作入口。
• 文字角色采用 label / prose / heading，各九档；业务用途映射保留，具体跨端值待验证。见排版层级与文字可读性。
• 「减少不必要的视觉复杂度，而不是减少完成任务所必需的信息」作为已确认第二条设计原则的取舍解释，不增加第七条原则。

不变

六条原则、职责边界、TextBundle、固定六位编号、数据可信与恢复要求保持不变。此前讨论历史不删除。

待验证

品牌值、实际尺寸、平台 API、设计资产、实现与辅助技术测试。

2026-10-19 · Billgo Standard Design 确认

已确认

用户决定：(1) 颜色 Token 严格采用角色＋色阶两维体系，取代此前三层公共颜色 Token 候选；(2) 每个任务上下文一个主操作，而非机械地每个 View 一个；(3) Typography 统一 label、prose、heading 三角色，各九档，业务用途继续映射至三角色。

新决定已补入Token 契约、主题与状态、操作组件：按钮与动作入口、排版层级与文字可读性，旧候选保留为历史。六条原则不变。具体色值、字号映射、完整组件 API 与实际实现验收尚未批准或执行。

2026-10-19 · 现行规范整理与效力澄清（P0）

状态

文档修复完成；不是新设计决定，也不是实现验收。依据入口的《YUDS v0.3 整理与核验执行说明》和用户授权，在独立检出的副本上完成 P0（现行规范整理）。49 篇逐篇检查、冲突表与验证证据见YUDS 统一设计系统入口的 P0 交付附件；当时 P1 暂停，等待用户审阅。

当前效力

颜色统一七角色＋固定职责色阶；旧三层公共颜色模型整体移入Token 契约、主题与状态的历史附录。排版统一 label／prose／heading 各九档，业务用途显式映射，不批准原型字号。主操作按独立任务上下文识别，不能以每个 View、分栏或按钮组代替任务边界。六条原则正文、职责、权限与业务数据／恢复契约保持原有确认范围。

早前记录的范围澄清

上文两条与 Billgo Standard Design 对齐、确认的记录及专题追加原文保留追溯。其中“统一八种视觉变体”不应解释成已批准完整 API／六材质实现；入口后续执行说明明确要求 P1 先做映射与冲突表。“批准与拒绝配对例外”是否允许同一任务有两个状态主操作，尚无独立确认依据，保留待用户决定；不从参考系统自动引入该例外。八个名称仅作映射核对词汇，不表示实现已有。

参考边界

已读取当时可用的 Billgo Standard Design（其自述决策日期 2026-10-19）及颜色、排版、布局、UI、文案、可访问性技能，并核对颜色角色与色阶参考。参考中的每 View 一个品牌按钮不替代 YUDS 的任务上下文决定；13px 建议等不覆盖本体系已记录的无 13px 规则。TeaCSS 新映射在该参考中仍标进行中，未查验发布制品，不声称可直接调用。

未执行与保留问题

没有产品代码修改、真实平台测试或外部参考系统的新一轮完整研究。品牌色、平台九档具体值及字体许可、按钮／材质 API、动效值、首个真实任务与支持环境仍未批准。

2026-10-19 · 全量文档整理与提交授权

用户原话

“你现在重新整理所有yuds的内容，需要阅读通畅合理，整理完成后就提交并推送到知识库”。

整理范围

在 P0 基础上通读全部 49 篇，整理中文表达、章节叙事、术语、标题导航、重复规则与交叉引用。已有 P0 成果保留，整理另行提交；授权包括核验后正常推送到知识库，不改写远端历史。

决定与历史边界

六原则、已确认的系统定义与职责、导航原文及历史快照保持。文字整理不批准批准／拒绝双主操作例外，也不批准 P1 的具体颜色、字号、字体、动效、组件 API 或材质映射。P1 未决设计和产品开发当时没有启动。

证据范围

逐篇覆盖、独立审阅及文档核验见YUDS 统一设计系统的全量整理入口。原 P0 附件保留为当时证据，其中的行号和文件哈希不能当成后续最新值。真实平台对比度、读屏、触控、布局与动画测试仍未执行；不将知识库推送等同于 FSNotes 本地已同步。

2026-10-19 · 启动 P1：后续规范完善与迭代评审

用户原话

“继续参考 之前提到的几个手机系统，继续把这套设计的规范做到10分，每次修改完成后就迭代审查，觉得不完美的地方就继续修改直到你觉得可以达到9.5分以上才能停止”。

执行范围

核查 Apple／iOS、Android／Material、HarmonyOS 官方资料，补可执行规则、状态组合和正常／失败案例；每轮修改后独立反向审阅、修复和回归核验。固定 100 分评分表在修改前冻结，规范与实现成熟度分别记录；证据见YUDS 统一设计系统。这更新此前“P1 未启动／暂停”的状态，历史交付原文保留。允许核验后分阶段提交并正常推送，不改写远端历史。

仍不变

六原则原文、十二章与扁平六位 TextBundle、业务模型职责、七角色＋固定职责色阶两维公共 Token、三文字角色各九档、独立任务上下文主操作规则。外部系统、Billgo 更新和候选平台映射不能自动改写已确认决定；TeaCSS 和原生配套未核实发布能力的，不写成可调用。

规范效力

从已确认方向推导的规则、文档追踪 ID 与夹具属于可修订的工作稿，不记为用户逐条批准的发布规范。新增品牌色、具体字号、正式 API、批准／拒绝双状态主操作例外和重大产品能力继续列为拟议。独立审阅结果不是对这些取舍的审批。

待决清单主档

索引附件 p1-decisions.json 给出问题、候选与建议、受影响条款、保守路径和验证要求。候选可供评估，不因规范得分达到目标变成已确认值。真实平台、组件及产品任务未执行时继续明确标记；未取得最低支持版本或正式组件证据的映射不宣称全平台支持。

2026-10-19 · 纠正评分解释与扫描复现缺口

状态

此前的达标结论撤回，原记录保留。R3 的 100/100 只记录当时的描述检查表判断，不能换算为整体设计系统达到 9.5 分。后续只读复核发现：Q14.5 候选配置尚未冻结为真实可复现矩阵；Q19.2 旧核验包没有独立重生成规范性用语索引。前者继续未满足（Q14.5 的现行判定见质量基线、门禁与验收证据），后者补充生成脚本、原始输入、完整基线、期望输出与独立复跑证据；不得更改冻结量表来提高得分。

该次授权允许修复可自主处理的证据与声明问题、独立复审后正常提交推送；不重写已正确的设计规则，不替用户批准色值、字号、API 或支持范围。现行状态以索引纠正报告及针对 Q14.5、Q19.2 和 Q20 的复核为准；历史 R3 报告不可冒充最新判定，也不生成新的整体质量数字。

2026-10-19 · 通用组件优先与参考体系分工

用户确认方向

先打造通用组件，不先切入具体业务系统；体系完整度应以 SAP 为主要基准，视觉吸收 Geist 的简洁克制，同时参考 OUDS 与 Stripe Sail 的优点。用户已确认 Sail 指 Stripe 的 Sail 设计系统。

当前范围

建立四系统八维证据矩阵、SAP 覆盖差距、行业无关组合夹具，并继续修复与独立迭代。SAP 覆盖基础、组件、状态、组合模式、可访问性、适配和治理；分别记录 Web／iOS／Android／Digital 适用域，不复制其行业模型、品牌或具体产品 API。Geist 的视觉克制不能牺牲必要信息与交互。OUDS 重点参考跨平台组织、组件解剖与成熟度／版本；Sail 只采用已核实的系统定位及工程实践，Stripe Apps 另列公开实践，不冒充 Sail 全貌。这不是四套体系等权拼接。

替代旧阶段安排

原索引 P2“优先验证 AMKit 真实任务”、旧大纲“先定第一条产品任务”的优先级改为通用组件与受控组合。原业务旅程、AMKit 研究及历史证据保留；产品业务集成另列为阶段外／未评估。现有 41 项组件仅为已整理目录，不能据此宣布与 SAP 齐全。

不变与未验证

六原则、十二章与六位扁平 TextBundle、权限职责边界、七角色＋固定职责色阶两维公共 Token、三文字角色各九档及独立任务一个主操作保持。外部三层 Token、每页主按钮规则或宿主 API 不覆盖 YUDS 确认决定；具体品牌值、正式 API 和重大取舍仍待批准。原 100 点评分要求和权重不改，Q14.5 实际运行矩阵仍未满足，整体 9.5 目标尚未证明。组件测试宿主可以作为验证对象，无须先绑定业务产品；当时未运行组件或平台验收。

证据效力

四系统来源登记区分目标正文、官方索引与缺证，记录日期／版本／读取者。新增工作稿与夹具不是用户逐条批准的发布规范，正常提交推送不等于发布或实现验收。

2026-10-19 · 通用规范扩展：十个高优先族

用户要求继续推进通用组件，以 SAP 齐全程度为目标，并吸收 Geist 克制视觉、OUDS 及经核实的 Sail 优点。

十个高优先族作为可修订规范扩展，合入现有专题；四项现有行为漏洞经反审修订，保留规则来源与未执行测试。新增 INP／DSP 等标识只用于文档追踪，不批准正式 API；没有新增已批准色值、字体字号、主操作例外或平台支持承诺。七角色×职责色阶、三文字角色各九档、独立任务上下文主操作、六原则、十二章及历史保持。

SAP Web 历史目录差距保留，新增三分支局部目录明确不完整；公开资料缺证不包装成对等通过。独立文档反审只关闭具体文本缺口，不给整体评分，不改变冻结量表或整体目标。后续继续补高优先族与组合；真实平台验收仍未执行。证据入口见YUDS 统一设计系统。

2026-10-19 · 通用组件深化：键盘焦点、异步与内容增长

深化 14 个已有及通用能力族，将键盘焦点、数据与事件、异步失效、撤权、内容增长和 74 条中性夹具合入已有专题。族数只表示该批审查范围，不能与前批相加作为系统组件总数或完成率。

反审关闭具体文档缺口，所有运行仍未执行。两维 Token、三文字角色各九档、独立任务主操作、六原则、十二章、扁平编号和既有历史保持；具体主题值、正式 API 和平台支持仍待决。当前 SAP 公开目录／正文证据不足的，不转换为通过；Stripe Apps 与 Sail 的证据边界保留。不宣称达到整体 9.5 或工作结束。

2026-10-19 · 输入、动作与表单深化

13 个通用子类与 73 条中性夹具合入现有 49 篇。重点将输入草稿、候选选择、明确接受、提交快照与已确认结果分开；菜单／日期取消、父范围失效、拆分默认乱序、旧拒绝与新草稿均有具体规则和反审记录。

不增加组件总数，不以静态文档当平台通过；SAP 等价、全体系覆盖和整体质量目标仍未证明。未改变两维 Token、文字三角色九档、独立任务主操作、六原则、十二章及原有历史；新增标识仅为规范追踪，不批准 API、数值或实现能力。

2026-10-19 · 通用选择、数据与容器

加入剩余 A 族通用契约及其独立反审，修正取消丢失原始无效草稿、子稿异步接受跨版本、尺寸中断写入、查询能力假定等可判定问题。A 目录标签的草案映射范围齐备仍不是组件完工；不改变两维 Token、三角色九档、独立任务主操作、六原则、十二章或既有历史。所有运行未执行，整体质量目标与 SAP 全体系对等继续未证明。后续按唯一主档收拢并开展中性 Web 候选实验，不以无限文档追加替代设计验证。

2026-10-19 · 组件主档收拢与可追溯定位

将通用组件的早期概述、CMP 目录行及深化契约归入同名连续主节，索引仅承担导航；完整 CMP-05 菜单主档归操作组件：按钮与动作入口（080100），浮层组件：对话框、抽屉与提示（080500）保留共享层职责。每个旧节、CMP 行和稳定规则／夹具均保留迁移关系；旧阶段登记继续作为原提交快照，不改写成当前位置。

YUDS 统一设计系统（010000）整理为当前入口，原索引全文及阶段文字冻结为证据附件；两处已确认历史原文不变。修复菜单首焦点、非模态关闭焦点、权限与取消快照、真实查询能力等冲突，并核对跨章引用目标。颜色两维、三角色九档、独立任务主操作、十二章六原则和未批准设计取舍保持原边界。

这是结构与语义文字修订，不是组件实现或平台验收。中性 Web 候选源码另行准备，真实浏览器因执行环境与文件协议限制未能运行，无截图和通过结论；不得用静态检查代替整体 95 目标。后续继续 B 族通用组合并明确剩余差距。

2026-10-19 · 七族通用组合与四端设计授权

将卡片、壳、侧区、树表、视图设置、导出及向导深化到各自连续主档，85 项中性夹具全部未执行。独立反审关闭账户切换迟到回执、取消原稿、树表完整键盘及导出撤权能力口径等具体文档问题；夹具数量不转化为 SAP 对等或整体 95 分。

用户新增要求：整套规范梳理后在 Stitch 新建 YUDS 项目，为 Web、iOS、Android、HarmonyOS 重新设计组件库；有疑问时可代作决定以推进。由此，普通可逆设计取舍可由代理依据用户授权决定，须逐项记录理由和验证状态，不把代理选择伪称用户亲自确认。此授权不使任何尚未记录的颜色、字号或 API 自动生效，不证明原生支持，也不授权编造产品业务或实际服务能力。费用、权限及不可逆事项仍按其授权边界处理。

两维 Token、三角色各九档、独立任务至多一个突出主操作、六原则、十二章及历史保持。中性 Web 实验源码可检查，但受执行环境浏览器与文件协议限制，实际运行未执行，无截图。下一步将历史 D01—D08 分为可逆设计决定、实际证据缺口与外部权限，形成四端目录和设计批次输入；规范就绪后才进入 Stitch 设计，设计稿不等于实现验收。

2026-10-19 · 代理初始设计基线 D01—D08

代理依据用户授权决定。授权原文：

• 用户（Sentinel_27c0322388788191aab90d3bc6a7e062）：等到你把整个设计系统都梳理完成以后就在stitch上开一个yuds的项目，参考sap的设计资源，帮我重新设计一整套组件库，包括 web ios android harmong 都需要。
• 用户（Sentinel_63f1bb1cc0188191b089000aa0a5f0ed）：如果有疑问你就帮忙做决策目标是把这个问题往前推进

各项为普通可逆设计采用，不写成用户逐值亲自确认。原阶段候选／未决表保留历史意义；本节及各现行专题更新当前采用状态，API、生产能力、实际支持与真实运行仍单独取证。

D01 的物理值其后由下文 D01-R1、D01-R2 修订。值与规则的唯一主档从YUDS 统一设计系统「现行设计基线」进入；冻结的决定、来源、算术与反审在其附件。64 HEX／198 配对仅为静态算术，27×4 文字与几何仅为初始设计。全部 18 项真实运行未执行，未声称 95 分、SAP 对等或四端已支持。费用、权限、需确认的新条款与不可逆动作仍按授权处理；遇工具权限拒绝须停止并核验授权，不绕路，不借设计采用扩张权限。

2026-10-19 · B2 组合深化

五族采用已独立反审的保守通用交互候选：

• 比较集合及字段版本冻结。
• 预览按层实例／关闭原因管理焦点。
• 收藏的安全跨设备修改与补偿须有真实原子冲突能力。
• 页头默认静态，空间不足时取消粘性且保留宿主。
• 横幅默认静态，会话内关闭与远端偏好分开记账。

完整规则仅在五篇主档，索引提供入口。本记录不重开 D01–D08、不更改原历史决定、不授予新服务／权限，也不宣称运行通过。63 项新夹具全部未执行，待合入独立反审及真实平台验证。

2026-10-19 · 数据、流程、轮播与颜色的候选合入

微图、九组分析图、图表工具与流程可视化采用已独立反审的通用数据身份／范围／视觉状态边界。轮播默认手动并提供静态等价，自动播放仅由用户明确启动，且有停止／代次仲裁。颜色族限定为用户内容的 sRGB 六位 HEX 与独立 alpha，保留非法原文、父子草稿及版本边界，不更改系统 Token。六族 87 项新夹具全部未运行，进入整合独立反审；既有 D01–D08 采用及真实能力证据缺口均保持。

2026-10-19 · 最后四个 B 标签的有界候选

公式／规则首期语言与类型边界、富文本／HTML 安全和能力边界、云文件引用选择及扫描／手工输入沿各自唯一主档；共同的原稿／IME／快照／撤权契约不重复定义。最后四族 74 项夹具与此前 235 项合计 309 项，全部未运行。22 个 B 分析标签都有明确子范围候选，这仅是文档状态，绝不构成整族全变体、SAP 等价或运行通过。D01–D08 设计采用不变，真实服务／设备／权限仍须逐项取证。

2026-10-19 · C 通用组合与有限阅读清理

四个 C 标签采用建议审阅、评论回复、用户输入翻译建议与输出交付扩展的有界候选；真实外部服务、传输授权和结果核查能力是门槛。AI 辅助与用户控制（140200）中无条件查询／撤销／确认的旧句已按实际能力精确替换。四族 40 项与 B 族 309 项共 349 项文档夹具全部未运行；后 7 个 C 标签只保留边界分类。采纳的 50 项阅读清理逐条施加，保持历史阶段证据，不启动新的纯文风扩写。D01–D08 设计输入保持，SDK／平台／服务／可访问运行仍另行验证。

2026-10-19 · D01-R1 TeaCSS 默认映射纠正与高可读修订

用户确认：

“teacss 默认的primary 是选择 ink, neutral 是选择 gray, 当然用户可以自己再去修改 primary的颜色，如果用户不修改默认就是 ink, 你按照这个思路去矫正 YUDS 的设计。”

此前用户也授权按 TeaCSS 当前规范另做改进版本。

本记录替代 D01 代理初始蓝黑／蓝灰物理值的现行效力，不改写前文历史。默认 primary=ink、neutral=gray 和未覆盖时回退 ink 是用户确认；具体高可读 64 值由代理依据授权决定，保持 TeaCSS 角色／色阶规范。Token 契约、主题与状态（070100）是唯一色值主档，色彩语义与可辨状态（070200）是唯一配对／焦点构造主档；默认 focused 随 neutral，自定义 primary 需完整两主题允许步骤及重新验收。TeaCSS 源码固定在提交 7532869，只修 YUDS，不更改 TeaCSS 上游。

原样 TeaCSS 的 sRGB 派生在 YUDS 更宽的配对矩阵下 132/198 通过；这不等于 TeaCSS 自身较窄用法的承诺失败。修订 14/64 槽位以加强必要边界、辅助文字及浅色状态 900，198/198 静态通过。视觉、实际合成、浏览器、原生、强制颜色仍未执行；不把 Stitch 成图当运行证据。真实配对失败、文字层级不足或用户替换品牌时，只修改中心映射并重验所有消费者，不增加角色或反转编号。

D02 仍是三文字角色各九档、系统字体及四端初始尺度的原设计采用；本次不改字号、字体、缩放或 D02 状态，不把颜色修正当排版验证。D00／D01／D02 等 Stitch 批次 ID 与设计决定 D01／D02 是不同命名空间，不能互相覆盖。旧 D01 附件和原决定保留为不可变历史，当前入口指向 D01-R1 的新证据 ↗。

2026-10-20 · 文档优先修订：普通可逆决定

代理依据用户授权决定，先修规范并独立反审，再讨论具体设计。已知文档发现及复审残留已修订闭合；这不代表具体设计或运行通过。不修改六原则、七角色固定职责、三文字角色九档、64 色物理值、字体值或独立任务主操作边界。没有改写旧证据、Q14.5 或历史评分，未发布设计／代码。

• D03-B01：八按钮变体采用操作组件：按钮与动作入口（080100）的最小状态消费配方；默认 label-3x，显式小文字选项 label-2x 且命中不缩小。理由是消除同一允许集合下的无依据自由选值；状态 950 hover 保持原许可，pressed 仍按既有平台反馈边界验证，不新增视觉标记。自定义 primary 需重验配对。真实视觉不清晰时可修订配方，不能私改公共 token 或降低可访问目标。
• D03-M01：六材质采用基础组件与交互契约（080000）的中性不透明面／必要边界／既有几何；最小起点不加阴影、玻璃或半透明遮罩。理由是可复原且不新增颜色；未来需要遮罩或阴影须记录用途、允许消费和合成验证，不把模态等同深色遮罩。
• D07-I01—I04：首批应用图标采用 Lucide 1.59.0 锁定提交、七类语义八源 SVG 及 16／20／24 初始绘制档；许可保留完整 ISC 及 Feather MIT 通知。理由、尺寸／文字对齐、RTL 和资源失败见图标、层级与动态反馈（070500）。仅采用来源策略，未导入资产或安装 SDK；不清晰时先用较大档或文字回退，再记录修订，不声称最终视觉通过。
• PAT-AUTH（权限变化、并发修改与保存冲突）／PAT-ONBOARD（流程推进与协作责任）／PAT-CONSENT（表单校验、草稿与提交）／PAT-OFFLINE（系统状态、权限与恢复）／PAT-IMPORT（表单与业务流程）及 SUP-HANDWRITING（输入组件：文本、结构化编辑与专用输入）：在既有专题增加有界文档候选及批次入口。认证不等于授权／业务完成，告知选择不裁定法律效力，手写输入不提供法律签署，默认无离线写队列，上传不等于导入。合同依真实能力提供可退出分支；新增有界合同已完成独立文档反审，不能以目录存在声称 SAP 全体系对等。
• 平台补充只在选定的 OS × targetSDK／框架／窗口／输入环境适用，不升级历史测试环境或承诺最新 OS。原生语义和键盘／inset 所有权补充沿已有行为主档。

文档审查、设计采用、实现成熟度及运行证据分别记录；以上不是用户逐项数字批准，均可在保持已确认边界的前提下撤回或修订。修复台账 ↗记录实际修改和待验边界。

2026-10-22 · D01-R2 默认主题选择面淡彩修订

用户决定：保留 ink 作为默认 primary，只给默认 primary-200/300 一个带轻微彩度的值，并由代理找到方案后写回知识库。起因是架构审查发现 D01-R1 默认主题下 primary-200/300 与 neutral-200/300 同值，Token 契约、主题与状态（070100）第 1 节“已选择行悬浮才用 primary-300”及夹具 C01 的失败注入在默认主题下无法观测，primary 与 neutral 两个角色在默认配置下不可辨。

采用：浅色 primary-200/300 = #EBE4FF/#E1D9FF，深色 = #291F43/#33255B，取 @teasim/colors（teakit/colors@7474f74e）violet 浅色第 4/5 阶、深色第 3/4 阶；其余 60 值不变。198 项允许配对按色彩语义与可辨状态（070200）同一算法重算，全部通过，最低为浅色 warning-900 对 primary-300 4.602:1 与浅色 neutral-600 对 primary-300 3.183:1。可辨性以 OKLab ΔE 记录，不作为门槛。

不采用：lime 作为默认 primary（品牌面白字对比只有 1.5–3.1:1，需压暗成橄榄绿或改 D03-B01 配对规则）；带彩灰第 3/4 阶（与 gray 的差异低于 neutral 单步差）。撤回条件：真实绘制或色觉模拟显示选中行与状态柔和面不可辨、深色主题层级失真，或用户指定品牌替代；撤回时整份回到 D01-R1 四值，不混搭。

Token 契约、主题与状态（070100）第 1.1 节仍是唯一色值主档，色彩语义与可辨状态（070200）是唯一配对主档；v2 证据见 color-revision-v2 ↗。本记录不改变 primary=ink 身份、七角色色阶、三角色九档或 D02—D08；真实运行仍未执行。