project-tiny-context-harness 0.8.4 → 0.8.6

package/assets/skills/context_uiux_design/SKILL.md

@@ -1,172 +1,172 @@
----
-name: context_uiux_design
-description: Use when the user explicitly asks to establish, adopt or repair durable UI/UX Design Authority, DESIGN.md, design-system governance, visual standards, stable interaction/surface Context, Impeccable review, visual polish, frontend redesign, or when material production UI lacks sufficient or consistent Design Authority in a Minimal Context Harness project. For standalone generation of low/high-fidelity wireframes, visual candidates, a design prototype or implementation resource handoff, use design-resource-authoring instead; do not trigger this Skill solely for resource generation, routine implementation with sufficient authority, local CSS fixes, UI bugs, explicit throwaway prototypes or generic mentions of design.
----
-
-# Context UIUX Design
-
-## Package-Managed Boundary
-
-This Skill is generated by `ty-context sync` and owned by the Harness package. Do not edit the generated `context_uiux_design` Skill directly.
-
-Project-specific UI/UX and visual design rules belong in a separate project-local Skill under `<harnessRoot>/skills/uiux_design/SKILL.md`. When a project-local Skill and this package-managed Skill both apply, use the more specific project-local Skill as the primary instruction source while keeping durable conclusions in `project_context/**` and `DESIGN.md`. Keep the project-local Skill front matter `description` trigger keywords aligned with this package-managed Skill and the project `AGENTS.md` role-trigger rule; if the project adds or narrows trigger terms, update both places together so agent activation and Tiny Context guidance do not drift apart.
-
-## 目标
-
-帮助 agent 在开发工作流中审查、采纳或修复设计权威，把已经选定的界面、交互和视觉结论沉淀成可恢复的 Minimal Context 和 `DESIGN.md`，并保持实现与验证对齐。
-
-## Design Context Depth / 设计上下文深度
-
-按需使用而不是默认加载全部层级：全局体验原则；跨 surface 的 Product Surface Contract；单屏 Screen Contract；可复用的 Control interaction Context；`DESIGN.md` 视觉系统/引用解释；项目原生 authored targets；verification Context。继续使用现有 `global`、`contract`、area/subdomain、`decision-rationale`、`verification` 和 `implementation-index` 角色，不新增笼统 `design` 或 `screen` 角色。
-
-一项事实只有一个主要 owner：跨页面职责属于 Surface Context，稳定的单屏层级/交互属于 Screen/interaction Context，视觉 token/rationale 属于 `DESIGN.md`，具体构图属于 selected target，交付范围与证明属于当前任务或现有 Delivery Contract/verification。使用稳定 surface/control/target key 连接，不复制成彼此竞争的说明。
-
-## Design Source Projection / 设计资源事实投影
-
-消费已选资源时，先把每项 material fact 在内部分类为：已有 durable owner、需要更新 owner、task-local、out of scope 或 decision required；不要持久化这张映射。
-
-- `surface_flow`：长期跨页面职责进入 Product Surface Context；稳定单屏层级/region/navigation 进入 Screen Contract；本次交付路径留在任务/Contract。
-- `visual_content`：长期视觉系统、token、组件族视觉规则和 rationale 进入 `DESIGN.md`；产品文案/信息语义进入 Screen/Control Context；精确构图、数值和条件差异留在 immutable target。
-- `component_control` 与 `state_interaction`：可复用的控件任务、可见性、输入/校验、状态、反馈、恢复、权限和导航语义进入 Screen/interaction Context；本次实现细节留在任务/Contract。
-- `motion`：系统级 motion/reduced-motion policy 进入 `DESIGN.md`；交互行为进入 Screen/Control Context；精确 timeline/easing/关键帧留在 target/handoff。
-- `adaptation_input` 与 `accessibility`：长期响应式、平台/input/focus/语义替代规则进入 Screen/Control Context；精确 condition/value 留在 target；可重复检查入口进入 verification Context。
-- `assets`：长期资产使用/归属政策进入 owning Context 或 `DESIGN.md`；精确文件、字节和 digest 留在 target/handoff。
-- provider provenance、source profile/dependencies、coverage/applicability cells、typed locators、交付 blockers、Claims/Assertions/Progress/Final Gate 不是 durable UI/UX Context；只有它们暴露的稳定产品决定、风险或可重复验证路径才投影到对应 owner。
-
-每个 adopted target 只能有一个 canonical adoption record。项目级、系统级或 component-family target 由 `DESIGN.md` 记录；单 screen/interaction target 由 owning Screen Contract 记录。canonical record 独占 interpretation、selection basis、immutable locator/digest、condition coverage 和 editable upstream owner/locator/update route；其他 Context、handoff 或 Contract 只保留 stable target key、canonical owner/anchor 与本层 applicability。handoff 的变化型 coverage index 不复制进 Context。
-
-## External Design Resource Consumption / 外部设计资源消费
-
-- `design-resource-authoring` 可以按明确请求在上游动态委托 Open Design 产生 flow、低保真、候选方向、组件族/独特复杂控件状态、交互原型或实现级资源；它以明确输出/开发内容为上限，在范围内补齐材料性 UI/UX 含义但不要求逐控件一份稿，不复制 provider 的提示词/模板，也不把任何资源设为全局必选。
-- `design-system-authoring` 是另一个仅显式调用的冷启动/修复 Skill：它用 Open Design 生成或选择候选，经过明确或受托选择后，把结果采纳到 canonical `DESIGN.md`、唯一 token source/direction 与 owning Context。缺少设计系统不会让本 Skill 或 `design-resource-authoring` 自动调用它。
-- 本 Skill 不承担独立资源生产。只有进入默认开发流程或 Long-Task、需要采纳稳定结论时，本 Skill 才消费这些或其他外部设计 Source。
-- 如果上游交付是用于实现的已选资源，先要求一个通过 `ty-context design-resource preflight <handoff.md>` 的 `design-resource-handoff-v1`。Web/App target 必须声明完整取得的 canonical entry 与依赖闭包；handoff 作为残余语义/coverage 适配器，以 typed locator 原子索引资源内每个受支持、范围内、可观察的设计事实，逐资源记录完整检查闭包，并逐 subject × target × condition 闭合 surface/flow、visual/content、component/control、state/interaction、motion、adaptation/input、accessibility、assets。Control 是产品交互语义单位，不是 UI 原子粒度上限；图片、文字、图标、组件内部片段、更小视觉 primitive、布局/样式/状态/行为事实只要资源表达就要索引。探索候选不需要此文件；provider/preflight 也不等于采纳或验收。
-- 候选、灵感和未选定输出不是 Context readiness 或实现权威，不能写入 selected registry；选定目标仍必须完成 UI Authority Closure 和 `Context Delta`。
-- 消费时沿 owning Context 的 surface/control/target key 到 canonical adoption record，主动打开每个受影响的 selected `exact-target`/`constraint`，而不是把登记存在视为已消费。核对产品 Source、Screen/Control Context、token owner、不可变 adopted locator/digest、覆盖条件、完整 fact/resource closure 以及 editable upstream owner/locator/update route；`exact-target` 每个条件必须具备整目标 layout 与 pixel 事实，否则应保持 partial `constraint` 或阻断。按 Design Source Projection 只把长期稳定且无冲突的事实写入其唯一 owner，精确值仍留在 canonical resource，不要求统一 pack、目录或工具格式。
-- 缺失、不可读、过期或冲突的 adopted resource 对受影响 claim 一律 fail closed。若 immutable adopted target 可读而 editable upstream 不可用，可以继续理解/实现既有目标，但修改资源必须保留为明确人工/外部边界。更新经 upstream 完成后生成/批准新 immutable version 并更新 owning reference，不能静默覆盖旧基线。
-- 设计资源生成本身不改 `project_context/**`、`DESIGN.md` 或 production code；定稿后只可一次性回改初始方案。设计系统采纳则由显式 `design-system-authoring` 完成。下游实现与验证仍由当前 Workflow Contract 或 `long-task-workflow` 负责。
-
-## 工作方式
-
-1. 先读取 `project_context/global.md` 和 `project_context/context.toml`，按 default area、triggers、read_when 选择相关 context。
-2. 如果项目存在 `DESIGN.md`，先读取其 Design Authority 状态、唯一 token 源/生成方向和由它 canonical owning 的项目/系统/component-family targets；screen-specific target 则跟随 pointer 读取 owning Screen Contract。仅当当前开发工作流经 UI Authority Closure 判断长期视觉体系需要采纳或修复时，按 Google `@google/design.md` 的格式创建或更新根目录 `DESIGN.md`；独立资源生成阶段不写入。
-3. 读取已有外部设计资源或其他 selected Source。若有 implementation handoff，先运行共享 preflight，再主动打开 handoff 索引的 exact/constraint 资源；不能用索引、provider 成功或 hash 替代资源消费。按稳定 subject/target/condition/Source-item key 应用 Design Source Projection，并为每个 adopted target 确认 exactly-one canonical owner。若当前请求只是生成资源，转到 `design-resource-authoring`；不要在本 Skill 内复制 provider 生成流程或另建交付格式。
-4. 涉及 Product Surface（Web 页面、移动/桌面屏幕、游戏 UI/HUD/菜单、CLI/TUI 输出、扩展或设备界面）、前端布局、UI/UX、产品模块边界或信息放置时，把产品/页面定位检查作为前置动作：用户在这个 surface 要完成的判断、产品必须提供的信息/动作/反馈、不应常驻的信息、主层/下钻/运维/诊断/详情归属、布局和信息密度是否匹配任务。多 surface、多平台或多模块归属不清时，先读取相关 Context、搜索入口并结合已有 UI 代码/截图做信息架构 sweep，必要时使用 `context_surface_contract` 做 Surface Contract Check，再收窄到具体视觉或交互实现。该检查是下一步变更分类的输入；只有形成长期 surface 职责、信息架构、交互契约或模块边界结论时才更新 Context 或 `DESIGN.md`。
-   - 若存在 Product Surface Contract，读取并对齐 primary user question、main allows/forbids、drilldown ownership、long-task state 和 verification。
-   - 若缺失且本任务改变 durable surface responsibility，将唯一 `Context Delta` 设为 `required`，把界面职责写入 `project_context/**`；视觉 token、颜色、字体、间距、圆角和视觉 rationale 仍写入 `DESIGN.md`。
-5. 涉及输入、选择、搜索、筛选、表单/配置、调度/时间窗口、预算/配额/限流或加载/空态/错误态等 UI 控件时，用“控件交互框架”检查控件语义、反馈状态、校验、错误预防、可供性和信息密度；这只是通用判断框架，不是固定控件处方。
-6. 界面职责、流程归属和长期交互契约以 `project_context/**` 为准；`DESIGN.md` 负责视觉 token、视觉 rationale、唯一 authored token source/generation direction 和设计引用解释；versioned authored targets 保留在项目原生路径，代码与生成截图只说明当前实现状态。Context 决定“应该是什么”，代码和实现截图揭示“现在是什么”，代码不能静默重定义 Context。
-7. 设计判断或第一处实现编辑前，执行 UI Authority Closure，并给出唯一长期事实判断 `Context Delta: none|required`。对 affected stable surface/control/target keys，在 agent 内部逐项判断 durable surface / IA / interaction / verification constraint 已被 Context / `DESIGN.md` 覆盖、需要先更新、仅属 task-local、显式 out-of-scope 或需要真实用户决策；不要创建 `plan.md`、Task Contract 文件或 Markdown 映射表。冲突的 controlling owners 必须修正 Source/Context/target 或保留 decision required，不能让当前实现或 YAML 静默决定。
-8. 普通 UI bug、局部样式或 CSS 修复、测试修复或探索性 spike 不更新 Context，可先改代码；一旦形成长期交互或视觉结论，继续对齐或交付前必须回写 Context 或 `DESIGN.md`。不要把 Context 机械补成代码改动摘要。
-9. 如果二者冲突，显式标记为实现漂移、缺失工作或 Context 过期。
-10. 如果涉及已有 UI，优先结合代码入口、运行截图或用户提供的参考图来描述差异。
-11. 当任务涉及设计稿、重做设计、视觉方案、设计系统、visual polish、frontend redesign 或 frontend styling，且存在可扫描的 UI 代码、页面文件、构建产物目录或本地/远程 URL 时，默认运行 `npx impeccable detect <target>`；实现前可用于识别既有视觉问题，实现后或交付前用于审查结果。没有可扫描目标、命令不可用或扫描失败时，说明原因并继续。
-12. 需要长期沉淀时：
-   - 项目级体验原则和屏幕清单写入 `global.md`。
-   - 模块级 screen contract、state、interaction 和视觉约束写入对应 area / subdomain Context。
-   - 颜色、字体、间距、圆角、组件视觉 token 和视觉 rationale 写入 `DESIGN.md`。
-   - 新 UI context unit 可新增 `project_context/areas/<unit>.md`，并更新 `global.md#Context Index`；复杂项目同时更新 `project_context/context.toml`。
-   - 如果 `upgrade` 自动把深层 `.md` 注册成 area，但语义上更像 foundation / contract / archive，后续应显式调整 manifest role；不要依赖自动迁移判断语义。
-13. Context 只能声明设计验收入口或 smoke 入口，不能伪造“已验证通过”。
-14. Verification / Deployment Role Context 只记录长期可复用的设计验证、smoke、部署或运行初始化路径事实：特殊准备、最短命令或路径、预期阶段 / 信号、可接受 warning、已排除的重复探索点。不要记录一次性测试日志、完整输出、临时 JSON、CI artifact、测试报告、release ledger、secret、token、cookie、device id、raw payload 或完整截图报告。
-15. 收尾时做 `Contract Conformance` 和 Context drift check，只报告轻量状态：`Context: 已更新 ...` 或 `Context: 本次无长期事实变化`。Conformance 说明本次契约满足情况、未满足或延期项和截图 / 手动检查入口；一次性证据、截图结果、测试日志、任务契约和实现摘要不写入 Context。
-
-## 内部执行约束与 Conformance
-
-- `Context Delta` 只能是 `none` 或 `required`。`required` 先更新 owning Context 或 `DESIGN.md`；`none` 按现有事实工作，不制造 Context 噪音。
-- Agent 内部计划应保持页面 / 组件任务、用户判断、主辅信息归属、动作层级、输入语义、loading / empty / no-results / stale / error / degraded / success 状态、布局稳定性、非目标与验收入口清晰。
-- 触及 Product Surface 时，同时保持 surface platform、primary user question、main allows/forbids、drilldown ownership、long-task state requirement 和 verification 清晰；字段、枚举、JSON 和截图仅是实现证据。
-- 当 Product Surface 粒度不足以支持 material screen 时，使用 `screen-contract.md` 的按需结构保持 entry/exit/shared state、information hierarchy、regions、fixed/scroll/overlay ownership、navigation/variants 和 material controls 清晰；局部样式修复不补建 Screen Contract。
-- 外部来源的重要约束在内部分类为 Context / `DESIGN.md` 已覆盖、已更新、task-local、显式 out-of-scope 或需要用户决策；存在未处理项时不能声称全量完成。
-- 默认流程不要求或验证固定 `plan.md`、Task Contract 文件、Source-to-Context 表、Context-to-Implementation 表、matrix、verdict 或 evidence ledger；可选 scratch 没有固定名称或权威。
-- `Contract Conformance` 直接检查 controlling Context / `DESIGN.md` 是否到达正确 surface、状态、交互与验证路径并避开 forbidden shortcut。实现偏差修实现；缺少长期事实则返回 `Context Delta: required`，先更新长期事实再对齐。
-- small code task、普通 UI bug、局部 CSS 修复、小重构、测试修复或探索性 spike 不创建额外流程 artifact。
-
-## 信息呈现校准
-
-- 页面设计先回答：产品/页面定位是什么、要解决什么问题、用户需要什么、页面需要提供什么内容/能力/反馈；再决定元素放什么、放哪里、为什么。这是页面变更前置判断，不是实现后的视觉润色。常驻元素应证明它比位置、图标、状态、数据或交互提示更能省注意力。
-- 追求有效信息密度，而不是塞满页面。判断标准是更少无效 chrome、更少解释、更靠近真实内容和可执行动作；警惕用大标题、大容器、空卡片、假摘要或装饰区块制造仪式感。
-- 对返回、刷新、同步、关闭、搜索、展开/收起等熟悉动作，比较 icon-only、紧凑控件、文字按钮和图标+文字哪种最省注意力；如果使用 icon-only，必须保留 `aria-label`、`title`、tooltip 或 hover/focus 说明。动作不熟悉、风险高或需要区分多个相近命令时，文字通常更合适。
-- 常驻文字要克制。用户已经知道且不帮助行动的页面标题、面包屑、说明句或分区名，先判断是否可以删除，而不是先润色；必要解释可进入 tooltip、hover/focus 展开层、空态、详情页、帮助或 Context。
-- 空间应由内容价值支撑。内容少时布局可以收缩到内容附近；警惕保留一整行只有几个字的 header、空指标槽、空列表容器或没有真实数据支撑的摘要。
-- 信息架构按归属放置：真正跨页面的动作可放系统级 chrome，模块动作放模块内部，运维/连接/缓存/后台任务状态只在影响用户判断或行动时进入主工作面，低频系统解释放详情、日志、调试视图或文档。
-- 空态、加载态和错误态必须真实。不要用 fixture、看似真实的 fallback 行或“这里不展示示例数据”这类元说明遮住没有数据；筛选无结果、系统无数据和连接失败要视觉上可区分。
-- 页面稳定性是 UX 合同。滚动条出现、列表加载、tab 切换、虚拟列表高度变化、面板展开收起都不应导致布局跳动；需要时预留 `scrollbar-gutter`、稳定容器尺寸、固定关键控件尺寸和可预测的 loading skeleton。
-- 文案服务任务，不解释设计。主界面避免内部黑话、实现边界说明、生产/示例数据规则和后端来源说明；必要技术细节放到详情、日志、调试视图或运维区域。
-
-## 控件交互框架
-
-- 当界面涉及输入、选择、搜索、筛选、表单/配置、调度/时间窗口、预算/配额/限流或状态反馈时，先判断控件承载的交互语义，而不是直接沿用后端字段形态。
-- 判断输入数据是自由文本、枚举、实体选择、时间/区间、数量/预算还是规则配置；不同语义需要不同的可供性、约束、校验和错误恢复。
-- 明确用户完成动作前后需要的反馈状态：loading、empty、no results、error、disabled、saving、success 和 validation feedback 应该支持用户判断下一步。
-- 检查控件是否给足单位、范围、默认值、示例、推荐值、风险/成本/影响提示；解释应靠近决策点，低频细节可以进 tooltip、详情或帮助。
-- 检查可见标签、helper text、错误文案和状态文案是否是用户语言，而不是内部字段、接口名或枚举名。
-- 自由输入不是禁用项，但要和错误成本匹配：当格式固定、错误代价高或反馈复杂时，应考虑更明确的约束、选择机制或校验反馈。
-- 不把本框架读成固定控件清单：搜索是否自动触发、时间是否用 picker、预算是否用 stepper，都应由数据规模、API 成本、用户任务、错误成本和项目组件体系决定。
-
-## 视觉质量校准
-
-- 先判断界面 register：品牌页、营销页、作品集等让设计承载表达；产品工具、后台、dashboard、表单等让设计服务任务。品牌界面可以更强烈地使用图像、色彩和编排；产品界面优先可扫读、稳定组件、熟悉交互和任务效率。
-- 已有 UI 优先保持身份连续性：先找现有 token、组件库、全局 CSS、Tailwind config、截图或代表性页面；除非用户明确要求重设计，不要推翻已建立的字体、颜色、组件语言。
-- 绿色地设计视觉体系时，先说明场景和色彩策略，再选 token：谁在什么环境下使用、界面应该 restrained / committed / full palette / drenched 到什么程度。不要按品类套默认审美。
-- 做设计方案或视觉规范时，显式检查：文字对比度、65-75ch 正文行长、清晰字号层级、响应式边界、44px 触控目标、焦点态、hover/active/disabled/loading/error/success 状态、空态/错误态/长文本、reduced motion 和文本不溢出。
-- 避免常见 AI 视觉反模式：嵌套卡片、无意义玻璃拟态、紫蓝渐变或渐变文字、灰字压在彩色背景上、默认米色/奶油色大背景、过度圆角、边框加大模糊阴影的幽灵卡片、每段一个圆角 icon tile、每节重复小号全大写 eyebrow 或 `01 / 02 / 03` 标记、bounce/elastic easing、空泛营销 buzzword。
-- 视觉审查时先分清问题类型：a11y / responsive / theming / interaction / copy / performance / anti-pattern。把真正影响用户理解、操作或品牌信任的问题列为高优先级；少量纯审美偏好不要淹没关键问题。
-- Harness 默认携带 Impeccable CLI 能力；做设计稿、重做设计、视觉设计方案、设计系统方案、frontend redesign、visual polish 或既有 UI 视觉审查时，默认尝试运行 `npx impeccable detect <target>` 作为辅助证据，不必等待用户点名。其输出只能作为设计缺陷线索，不是 Harness gate，也不能替代人工截图检查、项目测试或 `validate-context`。
-
-## Design Authority Readiness / 设计权威就绪
-
-Use this check before material production UI: a new or redesigned screen, primary layout/navigation/theme/component system, high-fidelity implementation or substantial visual polish. Routine implementation with sufficient authority, local style fixes and explicit throwaway prototypes stay on the lightweight path.
-
-Configured is system-level visual authority only, not surface implementation-ready status. `DESIGN.md` 被识别为 configured 只说明项目级视觉系统不是 starter，不表示任一页面已可高保真实现。affected surface 还必须拥有充分的 Screen/Control meaning、覆盖该 claim 的 selected target/constraints、唯一 token source 和项目可执行的验证路径；任何缺失都按 UI Authority Closure 路由，而不是伪造一个全局 readiness 状态。
-
-- Read the owning surface/interaction Context, `DESIGN.md`, the authored exact-value token source and generation direction, existing production components/routes and every affected selected exact/constraint resource through its immutable locator; also resolve its editable upstream/update route before authoring a resource change.
-- Classify each reference as `exact-target`, `constraint` or `inspiration`. Record the affected surface/route/component, project path or URI and relevant viewport/theme/mode/state. Exact targets authorize fidelity comparison only for those conditions; constraints authorize only their named rule; inspiration proves no reproduction claim.
-- Treat a missing `DESIGN.md`, its package starter with Design authority status: `unconfigured`, style-only prose, an inspiration-only set or conflicting references as insufficient authority for invented production layout.
-- If the user explicitly asks to initialize/generate/select/adopt the project design system, use the explicit-only `design-system-authoring`; never infer it from a missing starter. If the user explicitly delegates standalone resource generation, use `design-resource-authoring`. Style-bearing resources must stop on unconfigured authority and bind the adopted Open Design system; low-fidelity/IA/semantics-only resources remain lightweight. After final selection, resource authoring may reconcile accepted decisions into the initial proposal once, but this downstream Skill adopts durable target meaning only after UI Authority Closure.
-- Never use the implementation's own generated screenshot or diff as the target it claims to match. A target is selected Source; an implementation render is evidence. Baseline replacement requires deliberate review and cannot merely erase a failure.
-- Keep resource integrity and implementation conformance separate: a valid file hash, provider extraction/export, registry entry or resource count proves only acquisition/integrity, not that the production route/component renders or behaves like the selected target under the declared conditions.
+---
+name: context_uiux_design
+description: Use when the user explicitly asks to establish, adopt or repair durable UI/UX Design Authority, DESIGN.md, design-system governance, visual standards, stable interaction/surface Context, Impeccable review, visual polish, frontend redesign, or when material production UI lacks sufficient or consistent Design Authority in a Minimal Context Harness project. For standalone generation of low/high-fidelity wireframes, visual candidates, a design prototype or implementation resource handoff, use design-resource-authoring instead; do not trigger this Skill solely for resource generation, routine implementation with sufficient authority, local CSS fixes, UI bugs, explicit throwaway prototypes or generic mentions of design.
+---
+
+# Context UIUX Design
+
+## Package-Managed Boundary
+
+This Skill is generated by `ty-context sync` and owned by the Harness package. Do not edit the generated `context_uiux_design` Skill directly.
+
+Project-specific UI/UX and visual design rules belong in a separate project-local Skill under `<harnessRoot>/skills/uiux_design/SKILL.md`. When a project-local Skill and this package-managed Skill both apply, use the more specific project-local Skill as the primary instruction source while keeping durable conclusions in `project_context/**` and `DESIGN.md`. Keep the project-local Skill front matter `description` trigger keywords aligned with this package-managed Skill and the project `AGENTS.md` role-trigger rule; if the project adds or narrows trigger terms, update both places together so agent activation and Tiny Context guidance do not drift apart.
+
+## 目标
+
+帮助 agent 在开发工作流中审查、采纳或修复设计权威，把已经选定的界面、交互和视觉结论沉淀成可恢复的 Minimal Context 和 `DESIGN.md`，并保持实现与验证对齐。
+
+## Design Context Depth / 设计上下文深度
+
+按需使用而不是默认加载全部层级：全局体验原则；跨 surface 的 Product Surface Contract；单屏 Screen Contract；可复用的 Control interaction Context；`DESIGN.md` 视觉系统/引用解释；项目原生 authored targets；verification Context。继续使用现有 `global`、`contract`、area/subdomain、`decision-rationale`、`verification` 和 `implementation-index` 角色，不新增笼统 `design` 或 `screen` 角色。
+
+一项事实只有一个主要 owner：跨页面职责属于 Surface Context，稳定的单屏层级/交互属于 Screen/interaction Context，视觉 token/rationale 属于 `DESIGN.md`，具体构图属于 selected target，交付范围与证明属于当前任务或现有 Delivery Contract/verification。使用稳定 surface/control/target key 连接，不复制成彼此竞争的说明。
+
+## Design Source Projection / 设计资源事实投影
+
+消费已选资源时，先把每项 material fact 在内部分类为：已有 durable owner、需要更新 owner、task-local、out of scope 或 decision required；不要持久化这张映射。
+
+- `surface_flow`：长期跨页面职责进入 Product Surface Context；稳定单屏层级/region/navigation 进入 Screen Contract；本次交付路径留在任务/Contract。
+- `visual_content`：长期视觉系统、token、组件族视觉规则和 rationale 进入 `DESIGN.md`；产品文案/信息语义进入 Screen/Control Context；精确构图、数值和条件差异留在 immutable target。
+- `component_control` 与 `state_interaction`：可复用的控件任务、可见性、输入/校验、状态、反馈、恢复、权限和导航语义进入 Screen/interaction Context；本次实现细节留在任务/Contract。
+- `motion`：系统级 motion/reduced-motion policy 进入 `DESIGN.md`；交互行为进入 Screen/Control Context；精确 timeline/easing/关键帧留在 target/handoff。
+- `adaptation_input` 与 `accessibility`：长期响应式、平台/input/focus/语义替代规则进入 Screen/Control Context；精确 condition/value 留在 target；可重复检查入口进入 verification Context。
+- `assets`：长期资产使用/归属政策进入 owning Context 或 `DESIGN.md`；精确文件、字节和 digest 留在 target/handoff。
+- provider provenance、source profile/dependencies、coverage/applicability cells、typed locators、交付 blockers、Claims/Assertions/Progress/Final Gate 不是 durable UI/UX Context；只有它们暴露的稳定产品决定、风险或可重复验证路径才投影到对应 owner。
+
+每个 adopted target 只能有一个 canonical adoption record。项目级、系统级或 component-family target 由 `DESIGN.md` 记录；单 screen/interaction target 由 owning Screen Contract 记录。canonical record 独占 interpretation、selection basis、immutable locator/digest、condition coverage 和 editable upstream owner/locator/update route；其他 Context、handoff 或 Contract 只保留 stable target key、canonical owner/anchor 与本层 applicability。handoff 的变化型 coverage index 不复制进 Context。
+
+## External Design Resource Consumption / 外部设计资源消费
+
+- `design-resource-authoring` 可以按明确请求在上游动态委托 Open Design 产生 flow、低保真、候选方向、组件族/独特复杂控件状态、交互原型或实现级资源；它以明确输出/开发内容为上限，在范围内补齐材料性 UI/UX 含义但不要求逐控件一份稿，不复制 provider 的提示词/模板，也不把任何资源设为全局必选。
+- `design-system-authoring` 是另一个仅显式调用的冷启动/修复 Skill：它用 Open Design 生成或选择候选，经过明确或受托选择后，把结果采纳到 canonical `DESIGN.md`、唯一 token source/direction 与 owning Context。缺少设计系统不会让本 Skill 或 `design-resource-authoring` 自动调用它。
+- 本 Skill 不承担独立资源生产。只有进入默认开发流程或 Long-Task、需要采纳稳定结论时，本 Skill 才消费这些或其他外部设计 Source。
+- 如果上游交付是用于实现的已选资源，先要求一个通过 `ty-context design-resource preflight <handoff.md>` 的 `design-resource-handoff-v1`。正式 Web/App target 必须完整取得 canonical entry、依赖闭包和 frozen-Inspector Fact manifest，并证明 `Expected Fact Universe = Canonical Resource Facts = Handoff Indexed Facts`。作者端在生成前从需求、产品语义、设计系统和目标环境推导全集；原子身份是 `subject × target × condition × variation × property`，包含组件 instance/Anatomy Part/primitive/relation、动态 population、全部适用 condition/variation 组合、完整标准/自定义属性、显式 N/A/exclusion、每个 property 要求的 Fact × method proof、设计系统 lineage、资产和 blocker。Control 是产品交互语义单位，八个 UI/UX dimension 是 roll-up，都不是 UI Fact 粒度上限；默认页面、状态汇总字符串、抽样或截断都不能代替原子枚举。精确值只留在 canonical resource，handoff 用 typed located digest、comparator/tolerance/mask、Oracle/environment 和 sensitivity policy 投影而不复制 CSS。探索候选不需要此文件；provider/preflight 只证明相对于 named Inspector/Oracle TCB 的输入闭包，不等于采纳或生产验收。
+- 候选、灵感和未选定输出不是 Context readiness 或实现权威，不能写入 selected registry；选定目标仍必须完成 UI Authority Closure 和 `Context Delta`。
+- 消费时沿 owning Context 的 surface/control/target key 到 canonical adoption record，主动打开每个受影响的 selected `exact-target`/`constraint`，而不是把登记存在视为已消费。核对产品 Source、Screen/Control Context、token owner、不可变 adopted locator/digest、完整 Fact Cell/Fact/proof/resource closure、Inspector Census、条件/variation/property 集、设计系统 effective-value/conflict lineage 以及 editable upstream owner/locator/update route；`exact-target` 每个条件必须具备整目标 layout 与 pixel Facts，否则应保持 partial `constraint` 或阻断。按 Design Source Projection 只把长期稳定且无冲突的事实写入其唯一 owner，精确值仍留在 canonical resource，不要求统一 pack、目录或工具格式。
+- 缺失、不可读、过期或冲突的 adopted resource 对受影响 claim 一律 fail closed。若 immutable adopted target 可读而 editable upstream 不可用，可以继续理解/实现既有目标，但修改资源必须保留为明确人工/外部边界。更新经 upstream 完成后生成/批准新 immutable version 并更新 owning reference，不能静默覆盖旧基线。
+- 设计资源生成本身不改 `project_context/**`、`DESIGN.md` 或 production code；定稿后只可一次性回改初始方案。设计系统采纳则由显式 `design-system-authoring` 完成。下游实现与验证仍由当前 Workflow Contract 或 `long-task-workflow` 负责。
+
+## 工作方式
+
+1. 先读取 `project_context/global.md` 和 `project_context/context.toml`，按 default area、triggers、read_when 选择相关 context。
+2. 如果项目存在 `DESIGN.md`，先读取其 Design Authority 状态、唯一 token 源/生成方向和由它 canonical owning 的项目/系统/component-family targets；screen-specific target 则跟随 pointer 读取 owning Screen Contract。仅当当前开发工作流经 UI Authority Closure 判断长期视觉体系需要采纳或修复时，按 Google `@google/design.md` 的格式创建或更新根目录 `DESIGN.md`；独立资源生成阶段不写入。
+3. 读取已有外部设计资源或其他 selected Source。若有 implementation handoff，先运行共享 preflight，再主动打开 handoff 索引的 exact/constraint 资源和 canonical Fact manifest；不能用索引、Inspector `complete`、provider 成功或 hash 替代资源消费。按稳定 subject/target/condition/variation/property/Fact/Source-item key 应用 Design Source Projection，并为每个 adopted target 确认 exactly-one canonical owner。若当前请求只是生成资源，转到 `design-resource-authoring`；不要在本 Skill 内复制 provider 生成流程或另建交付格式。
+4. 涉及 Product Surface（Web 页面、移动/桌面屏幕、游戏 UI/HUD/菜单、CLI/TUI 输出、扩展或设备界面）、前端布局、UI/UX、产品模块边界或信息放置时，把产品/页面定位检查作为前置动作：用户在这个 surface 要完成的判断、产品必须提供的信息/动作/反馈、不应常驻的信息、主层/下钻/运维/诊断/详情归属、布局和信息密度是否匹配任务。多 surface、多平台或多模块归属不清时，先读取相关 Context、搜索入口并结合已有 UI 代码/截图做信息架构 sweep，必要时使用 `context_surface_contract` 做 Surface Contract Check，再收窄到具体视觉或交互实现。该检查是下一步变更分类的输入；只有形成长期 surface 职责、信息架构、交互契约或模块边界结论时才更新 Context 或 `DESIGN.md`。
+   - 若存在 Product Surface Contract，读取并对齐 primary user question、main allows/forbids、drilldown ownership、long-task state 和 verification。
+   - 若缺失且本任务改变 durable surface responsibility，将唯一 `Context Delta` 设为 `required`，把界面职责写入 `project_context/**`；视觉 token、颜色、字体、间距、圆角和视觉 rationale 仍写入 `DESIGN.md`。
+5. 涉及输入、选择、搜索、筛选、表单/配置、调度/时间窗口、预算/配额/限流或加载/空态/错误态等 UI 控件时，用“控件交互框架”检查控件语义、反馈状态、校验、错误预防、可供性和信息密度；这只是通用判断框架，不是固定控件处方。
+6. 界面职责、流程归属和长期交互契约以 `project_context/**` 为准；`DESIGN.md` 负责视觉 token、视觉 rationale、唯一 authored token source/generation direction 和设计引用解释；versioned authored targets 保留在项目原生路径，代码与生成截图只说明当前实现状态。Context 决定“应该是什么”，代码和实现截图揭示“现在是什么”，代码不能静默重定义 Context。
+7. 设计判断或第一处实现编辑前，执行 UI Authority Closure，并给出唯一长期事实判断 `Context Delta: none|required`。对 affected stable surface/control/target keys，在 agent 内部逐项判断 durable surface / IA / interaction / verification constraint 已被 Context / `DESIGN.md` 覆盖、需要先更新、仅属 task-local、显式 out-of-scope 或需要真实用户决策；不要创建 `plan.md`、Task Contract 文件或 Markdown 映射表。冲突的 controlling owners 必须修正 Source/Context/target 或保留 decision required，不能让当前实现或 YAML 静默决定。
+8. 普通 UI bug、局部样式或 CSS 修复、测试修复或探索性 spike 不更新 Context，可先改代码；一旦形成长期交互或视觉结论，继续对齐或交付前必须回写 Context 或 `DESIGN.md`。不要把 Context 机械补成代码改动摘要。
+9. 如果二者冲突，显式标记为实现漂移、缺失工作或 Context 过期。
+10. 如果涉及已有 UI，优先结合代码入口、运行截图或用户提供的参考图来描述差异。
+11. 当任务涉及设计稿、重做设计、视觉方案、设计系统、visual polish、frontend redesign 或 frontend styling，且存在可扫描的 UI 代码、页面文件、构建产物目录或本地/远程 URL 时，默认运行 `npx impeccable detect <target>`；实现前可用于识别既有视觉问题，实现后或交付前用于审查结果。没有可扫描目标、命令不可用或扫描失败时，说明原因并继续。
+12. 需要长期沉淀时：
+   - 项目级体验原则和屏幕清单写入 `global.md`。
+   - 模块级 screen contract、state、interaction 和视觉约束写入对应 area / subdomain Context。
+   - 颜色、字体、间距、圆角、组件视觉 token 和视觉 rationale 写入 `DESIGN.md`。
+   - 新 UI context unit 可新增 `project_context/areas/<unit>.md`，并更新 `global.md#Context Index`；复杂项目同时更新 `project_context/context.toml`。
+   - 如果 `upgrade` 自动把深层 `.md` 注册成 area，但语义上更像 foundation / contract / archive，后续应显式调整 manifest role；不要依赖自动迁移判断语义。
+13. Context 只能声明设计验收入口或 smoke 入口，不能伪造“已验证通过”。
+14. Verification / Deployment Role Context 只记录长期可复用的设计验证、smoke、部署或运行初始化路径事实：特殊准备、最短命令或路径、预期阶段 / 信号、可接受 warning、已排除的重复探索点。不要记录一次性测试日志、完整输出、临时 JSON、CI artifact、测试报告、release ledger、secret、token、cookie、device id、raw payload 或完整截图报告。
+15. 收尾时做 `Contract Conformance` 和 Context drift check，只报告轻量状态：`Context: 已更新 ...` 或 `Context: 本次无长期事实变化`。Conformance 说明本次契约满足情况、未满足或延期项和截图 / 手动检查入口；一次性证据、截图结果、测试日志、任务契约和实现摘要不写入 Context。
+
+## 内部执行约束与 Conformance
+
+- `Context Delta` 只能是 `none` 或 `required`。`required` 先更新 owning Context 或 `DESIGN.md`；`none` 按现有事实工作，不制造 Context 噪音。
+- Agent 内部计划应保持页面 / 组件任务、用户判断、主辅信息归属、动作层级、输入语义、loading / empty / no-results / stale / error / degraded / success 状态、布局稳定性、非目标与验收入口清晰。
+- 触及 Product Surface 时，同时保持 surface platform、primary user question、main allows/forbids、drilldown ownership、long-task state requirement 和 verification 清晰；字段、枚举、JSON 和截图仅是实现证据。
+- 当 Product Surface 粒度不足以支持 material screen 时，使用 `screen-contract.md` 的按需结构保持 entry/exit/shared state、information hierarchy、regions、fixed/scroll/overlay ownership、navigation/variants 和 material controls 清晰；局部样式修复不补建 Screen Contract。
+- 外部来源的重要约束在内部分类为 Context / `DESIGN.md` 已覆盖、已更新、task-local、显式 out-of-scope 或需要用户决策；存在未处理项时不能声称全量完成。
+- 默认流程不要求或验证固定 `plan.md`、Task Contract 文件、Source-to-Context 表、Context-to-Implementation 表、matrix、verdict 或 evidence ledger；可选 scratch 没有固定名称或权威。
+- `Contract Conformance` 直接检查 controlling Context / `DESIGN.md` 是否到达正确 surface、状态、交互与验证路径并避开 forbidden shortcut。实现偏差修实现；缺少长期事实则返回 `Context Delta: required`，先更新长期事实再对齐。
+- small code task、普通 UI bug、局部 CSS 修复、小重构、测试修复或探索性 spike 不创建额外流程 artifact。
+
+## 信息呈现校准
+
+- 页面设计先回答：产品/页面定位是什么、要解决什么问题、用户需要什么、页面需要提供什么内容/能力/反馈；再决定元素放什么、放哪里、为什么。这是页面变更前置判断，不是实现后的视觉润色。常驻元素应证明它比位置、图标、状态、数据或交互提示更能省注意力。
+- 追求有效信息密度，而不是塞满页面。判断标准是更少无效 chrome、更少解释、更靠近真实内容和可执行动作；警惕用大标题、大容器、空卡片、假摘要或装饰区块制造仪式感。
+- 对返回、刷新、同步、关闭、搜索、展开/收起等熟悉动作，比较 icon-only、紧凑控件、文字按钮和图标+文字哪种最省注意力；如果使用 icon-only，必须保留 `aria-label`、`title`、tooltip 或 hover/focus 说明。动作不熟悉、风险高或需要区分多个相近命令时，文字通常更合适。
+- 常驻文字要克制。用户已经知道且不帮助行动的页面标题、面包屑、说明句或分区名，先判断是否可以删除，而不是先润色；必要解释可进入 tooltip、hover/focus 展开层、空态、详情页、帮助或 Context。
+- 空间应由内容价值支撑。内容少时布局可以收缩到内容附近；警惕保留一整行只有几个字的 header、空指标槽、空列表容器或没有真实数据支撑的摘要。
+- 信息架构按归属放置：真正跨页面的动作可放系统级 chrome，模块动作放模块内部，运维/连接/缓存/后台任务状态只在影响用户判断或行动时进入主工作面，低频系统解释放详情、日志、调试视图或文档。
+- 空态、加载态和错误态必须真实。不要用 fixture、看似真实的 fallback 行或“这里不展示示例数据”这类元说明遮住没有数据；筛选无结果、系统无数据和连接失败要视觉上可区分。
+- 页面稳定性是 UX 合同。滚动条出现、列表加载、tab 切换、虚拟列表高度变化、面板展开收起都不应导致布局跳动；需要时预留 `scrollbar-gutter`、稳定容器尺寸、固定关键控件尺寸和可预测的 loading skeleton。
+- 文案服务任务，不解释设计。主界面避免内部黑话、实现边界说明、生产/示例数据规则和后端来源说明；必要技术细节放到详情、日志、调试视图或运维区域。
+
+## 控件交互框架
+
+- 当界面涉及输入、选择、搜索、筛选、表单/配置、调度/时间窗口、预算/配额/限流或状态反馈时，先判断控件承载的交互语义，而不是直接沿用后端字段形态。
+- 判断输入数据是自由文本、枚举、实体选择、时间/区间、数量/预算还是规则配置；不同语义需要不同的可供性、约束、校验和错误恢复。
+- 明确用户完成动作前后需要的反馈状态：loading、empty、no results、error、disabled、saving、success 和 validation feedback 应该支持用户判断下一步。
+- 检查控件是否给足单位、范围、默认值、示例、推荐值、风险/成本/影响提示；解释应靠近决策点，低频细节可以进 tooltip、详情或帮助。
+- 检查可见标签、helper text、错误文案和状态文案是否是用户语言，而不是内部字段、接口名或枚举名。
+- 自由输入不是禁用项，但要和错误成本匹配：当格式固定、错误代价高或反馈复杂时，应考虑更明确的约束、选择机制或校验反馈。
+- 不把本框架读成固定控件清单：搜索是否自动触发、时间是否用 picker、预算是否用 stepper，都应由数据规模、API 成本、用户任务、错误成本和项目组件体系决定。
+
+## 视觉质量校准
+
+- 先判断界面 register：品牌页、营销页、作品集等让设计承载表达；产品工具、后台、dashboard、表单等让设计服务任务。品牌界面可以更强烈地使用图像、色彩和编排；产品界面优先可扫读、稳定组件、熟悉交互和任务效率。
+- 已有 UI 优先保持身份连续性：先找现有 token、组件库、全局 CSS、Tailwind config、截图或代表性页面；除非用户明确要求重设计，不要推翻已建立的字体、颜色、组件语言。
+- 绿色地设计视觉体系时，先说明场景和色彩策略，再选 token：谁在什么环境下使用、界面应该 restrained / committed / full palette / drenched 到什么程度。不要按品类套默认审美。
+- 做设计方案或视觉规范时，显式检查：文字对比度、65-75ch 正文行长、清晰字号层级、响应式边界、44px 触控目标、焦点态、hover/active/disabled/loading/error/success 状态、空态/错误态/长文本、reduced motion 和文本不溢出。
+- 避免常见 AI 视觉反模式：嵌套卡片、无意义玻璃拟态、紫蓝渐变或渐变文字、灰字压在彩色背景上、默认米色/奶油色大背景、过度圆角、边框加大模糊阴影的幽灵卡片、每段一个圆角 icon tile、每节重复小号全大写 eyebrow 或 `01 / 02 / 03` 标记、bounce/elastic easing、空泛营销 buzzword。
+- 视觉审查时先分清问题类型：a11y / responsive / theming / interaction / copy / performance / anti-pattern。把真正影响用户理解、操作或品牌信任的问题列为高优先级；少量纯审美偏好不要淹没关键问题。
+- Harness 默认携带 Impeccable CLI 能力；做设计稿、重做设计、视觉设计方案、设计系统方案、frontend redesign、visual polish 或既有 UI 视觉审查时，默认尝试运行 `npx impeccable detect <target>` 作为辅助证据，不必等待用户点名。其输出只能作为设计缺陷线索，不是 Harness gate，也不能替代人工截图检查、项目测试或 `validate-context`。
+
+## Design Authority Readiness / 设计权威就绪
+
+Use this check before material production UI: a new or redesigned screen, primary layout/navigation/theme/component system, high-fidelity implementation or substantial visual polish. Routine implementation with sufficient authority, local style fixes and explicit throwaway prototypes stay on the lightweight path.
+
+Configured is system-level visual authority only, not surface implementation-ready status. `DESIGN.md` 被识别为 configured 只说明项目级视觉系统不是 starter，不表示任一页面已可高保真实现。affected surface 还必须拥有充分的 Screen/Control meaning、覆盖该 claim 的 selected target/constraints、唯一 token source 和项目可执行的验证路径；任何缺失都按 UI Authority Closure 路由，而不是伪造一个全局 readiness 状态。
+
+- Read the owning surface/interaction Context, `DESIGN.md`, the authored exact-value token source and generation direction, existing production components/routes and every affected selected exact/constraint resource through its immutable locator; also resolve its editable upstream/update route before authoring a resource change.
+- Classify each reference as `exact-target`, `constraint` or `inspiration`. Record the affected surface/route/component, project path or URI and relevant viewport/theme/mode/state. Exact targets authorize fidelity comparison only for those conditions; constraints authorize only their named rule; inspiration proves no reproduction claim.
+- Treat a missing `DESIGN.md`, its package starter with Design authority status: `unconfigured`, style-only prose, an inspiration-only set or conflicting references as insufficient authority for invented production layout.
+- If the user explicitly asks to initialize/generate/select/adopt the project design system, use the explicit-only `design-system-authoring`; never infer it from a missing starter. If the user explicitly delegates standalone resource generation, use `design-resource-authoring`. Style-bearing resources must stop on unconfigured authority and bind the adopted Open Design system; low-fidelity/IA/semantics-only resources remain lightweight. After final selection, resource authoring may reconcile accepted decisions into the initial proposal once, but this downstream Skill adopts durable target meaning only after UI Authority Closure.
+- Never use the implementation's own generated screenshot or diff as the target it claims to match. A target is selected Source; an implementation render is evidence. Baseline replacement requires deliberate review and cannot merely erase a failure.
+- Keep resource integrity and implementation conformance separate: a valid file hash, provider extraction/export, registry entry or resource count proves only acquisition/integrity, not that the production route/component renders or behaves like the selected target under the declared conditions.
 - Do not require Figma, a fixed `docs/design/**` tree, an image for every local change or a universal numeric pixel tolerance. For a selected `exact-target`, however, require project-owned condition-specific full-target layout and pixel comparison; if the resource or oracle cannot support that claim, classify it as a constraint or blocking gap. Use project-native design assets and the smallest authority sufficient for the claimed fidelity.
-
-## Visual Delivery Coverage / 视觉交付覆盖
-
-For material design-system, redesign, high-fidelity implementation or visual-polish work, keep a task-local **Visual Coverage Set** before implementation and verification. When external design Source declares coverage, reconcile it with current delivery scope rather than creating competing authority. The downstream working set remains internal planning, not a required file, matrix, Context role, workflow artifact or completion authority.
-
-- Start from the complete set of combinations that authoritative Source, selected targets/constraints and applicable Control semantics declare across production surface/route/component, viewport, theme or product mode, interaction/state, content stress and accessibility/motion conditions. Risk-proportional reasoning may prioritize execution order or add exploratory combinations beyond that authority, but must never prune a declared/applicable combination or replace it with representative/pairwise sampling unless authoritative Source explicitly narrows the scope or a project-owned proof establishes equivalence. Do not invent a Cartesian product across dimensions outside declared scope, and never claim an unchecked combination.
-- Cover relevant states such as default, hover, focus, active, disabled, loading, empty/no-results, error, success and long/extreme content. Use the project's declared viewport, contrast, target-size, reduced-motion and localization rules rather than inventing universal thresholds.
-- Keep the authority split explicit: `project_context/**` owns durable surface/interaction responsibility and `DESIGN.md` owns durable visual-system semantics and rationale. Record one authored exact-value token source and one generation direction; generated CSS/theme/export files are implementation outputs, not competing authored truth. If `DESIGN.md` is not the machine-token source, name the project-native source it governs instead of hand-maintaining the same exact values twice.
-- Map every claimed fidelity combination to its selected `exact-target` or named `constraint`; do not let the Visual Coverage Set turn inspiration or missing authority into an implicit target.
-- Inspect production components or real product routes. A detached static kit, mock, poster, marketing specimen or generated showcase may guide design review, but it cannot be the only evidence for product UI behavior or fidelity.
-- For each selected combination, identify the cold-start real-user entry journey. A first useful runnable production slice is a recommended real-entry feedback point when early localization is worth its cost, not a prerequisite for expanding implementation; deep links remain supplemental when users normally enter through a shell or navigation owner. Always rerun the affected cold-start journey on the final candidate.
-- Render and inspect the declared coverage with project-owned browser/component tests plus screenshots or manual review as appropriate. Report the combinations actually checked and any omitted or external review explicitly. A screenshot baseline may be updated only through deliberate review; replacing it merely to erase a diff is not verification.
-
-## 输出边界
-
-- 不默认创建 `.work_products/**`、UI/UX 独立文档、handoff matrix、review/test/release 文档。
-- 不要求 lifecycle phase、plan task、phase gate 或阶段 Skill。
-- 如果用户明确要求初始化/生成/选择/采纳项目设计系统，使用仅显式调用的 `design-system-authoring`；如果明确要求独立设计稿、mock、线框图、原型或 implementation resource/handoff，使用 `design-resource-authoring`。本 Skill 只在后续开发流程中采纳其他长期事实。
-- `DESIGN.md` 是视觉设计系统事实源；项目流程、模块契约和下一步动作仍以 `project_context/**` 为准。
-- 如果普通页面实现已经有充分 Design Authority，或用户只要求修复 UI bug、局部改 CSS、换颜色、明确的 throwaway prototype，或只是泛泛提到“设计 / design / user experience”，不需要触发本 Skill；durable 视觉体系/Context 采纳，或 material production UI 缺失/冲突的 Design Authority 才使用。明确要求设计资源产物但尚未进入采纳/实现流程时使用 `design-resource-authoring`。
-
-## DESIGN.md 使用规则
-
-- 使用 Google `@google/design.md` 格式：YAML front matter 存 tokens，Markdown body 存设计理由。
-- 优先包含 `name`、`colors`、`typography`、`spacing`、`rounded` 和必要 `components` token。
-- 在 `Overview` 内维护 Design Authority 状态、唯一 authored token source/generation direction，以及仅由 `DESIGN.md` canonical owning 的项目/系统/component-family target records。每条 canonical record 记录 stable id、interpretation、selection basis、immutable path/URI + digest、condition coverage 和 editable upstream/update route。screen-specific target 只记录 stable id + owning Screen Contract anchor，不在两处重复完整 metadata。不要添加 Google schema 不支持的 front-matter keys。
-- Markdown section 顺序优先为：`Overview`、`Colors`、`Typography`、`Layout`、`Elevation & Depth`、`Shapes`、`Components`、`Do's and Don'ts`。
-- 写入或修改后，如本地可用，运行 `npx @google/design.md lint DESIGN.md` 检查结构；不要把 lint 结果写成“已通过”除非本轮真实执行。
-- 需要给工程消费 token 时，可用 `npx @google/design.md export --format css-tailwind DESIGN.md` 或 `json-tailwind` 生成临时输出。
-
-## 建议沉淀位置
-
-- `global.md#UX / Screen Brief`：全局体验原则、主要屏幕、跨模块流程。
-- `areas/*.md#User / System Contract`：页面、组件、状态、交互和数据展示契约。
-- `areas/*.md#Key Constraints`：responsive、a11y、品牌/视觉边界、加载/空态/错误态约束。
-- role=`contract` Context：跨页面 / 跨域界面契约及其 durable rationale。
-- role=`decision-rationale` Context：更大或跨切面的稳定交互、信息架构或 surface ownership 取舍原因。
-- `areas/*/verification.md` 或 role=`verification` Context：UI smoke、截图验收、可访问性检查或项目自己的关键验证重复执行路径。
-- `areas/*/deployment.md` 或 role=`deployment` Context：前端部署、预览环境、运行拓扑或健康检查重复执行路径。
-- `project_context/context.toml`：复杂项目的产品域 area/context_unit、role、触发词、按需读取策略和可选边界规则。
-- `DESIGN.md`：视觉 identity、design tokens、组件视觉规则、do/don't、视觉 rationale、唯一 token source/generation direction，以及项目/系统/component-family target 的 canonical adoption records；screen-specific target 只保留 owner/anchor pointer。
-
-不要编造 rationale；仅由当前代码或截图形态反推的理由、实现摘要、PR notes、命令输出、测试通过声明、截图审查、debug 过程和 agent reasoning 不进入 Context 或 `DESIGN.md`。
+
+## Visual Delivery Coverage / 视觉交付覆盖
+
+For material design-system, redesign, high-fidelity implementation or visual-polish work, keep a task-local **Visual Coverage Set** before implementation and verification. When external design Source declares coverage, reconcile it with current delivery scope rather than creating competing authority. The downstream working set remains internal planning, not a required file, matrix, Context role, workflow artifact or completion authority.
+
+- Start from the complete set of combinations that authoritative Source, selected targets/constraints and applicable Control semantics declare across production surface/route/component, viewport, theme or product mode, interaction/state, content stress and accessibility/motion conditions. Risk-proportional reasoning may prioritize execution order or add exploratory combinations beyond that authority, but must never prune a declared/applicable combination or replace it with representative/pairwise sampling unless authoritative Source explicitly narrows the scope or a project-owned proof establishes equivalence. Do not invent a Cartesian product across dimensions outside declared scope, and never claim an unchecked combination.
+- Cover relevant states such as default, hover, focus, active, disabled, loading, empty/no-results, error, success and long/extreme content. Use the project's declared viewport, contrast, target-size, reduced-motion and localization rules rather than inventing universal thresholds.
+- Keep the authority split explicit: `project_context/**` owns durable surface/interaction responsibility and `DESIGN.md` owns durable visual-system semantics and rationale. Record one authored exact-value token source and one generation direction; generated CSS/theme/export files are implementation outputs, not competing authored truth. If `DESIGN.md` is not the machine-token source, name the project-native source it governs instead of hand-maintaining the same exact values twice.
+- Map every claimed fidelity combination to its selected `exact-target` or named `constraint`; do not let the Visual Coverage Set turn inspiration or missing authority into an implicit target.
+- Inspect production components or real product routes. A detached static kit, mock, poster, marketing specimen or generated showcase may guide design review, but it cannot be the only evidence for product UI behavior or fidelity.
+- For each selected combination, identify the cold-start real-user entry journey. A first useful runnable production slice is a recommended real-entry feedback point when early localization is worth its cost, not a prerequisite for expanding implementation; deep links remain supplemental when users normally enter through a shell or navigation owner. Always rerun the affected cold-start journey on the final candidate.
+- Render and inspect the declared coverage with project-owned browser/component tests plus screenshots or manual review as appropriate. Report the combinations actually checked and any omitted or external review explicitly. A screenshot baseline may be updated only through deliberate review; replacing it merely to erase a diff is not verification.
+
+## 输出边界
+
+- 不默认创建 `.work_products/**`、UI/UX 独立文档、handoff matrix、review/test/release 文档。
+- 不要求 lifecycle phase、plan task、phase gate 或阶段 Skill。
+- 如果用户明确要求初始化/生成/选择/采纳项目设计系统，使用仅显式调用的 `design-system-authoring`；如果明确要求独立设计稿、mock、线框图、原型或 implementation resource/handoff，使用 `design-resource-authoring`。本 Skill 只在后续开发流程中采纳其他长期事实。
+- `DESIGN.md` 是视觉设计系统事实源；项目流程、模块契约和下一步动作仍以 `project_context/**` 为准。
+- 如果普通页面实现已经有充分 Design Authority，或用户只要求修复 UI bug、局部改 CSS、换颜色、明确的 throwaway prototype，或只是泛泛提到“设计 / design / user experience”，不需要触发本 Skill；durable 视觉体系/Context 采纳，或 material production UI 缺失/冲突的 Design Authority 才使用。明确要求设计资源产物但尚未进入采纳/实现流程时使用 `design-resource-authoring`。
+
+## DESIGN.md 使用规则
+
+- 使用 Google `@google/design.md` 格式：YAML front matter 存 tokens，Markdown body 存设计理由。
+- 优先包含 `name`、`colors`、`typography`、`spacing`、`rounded` 和必要 `components` token。
+- 在 `Overview` 内维护 Design Authority 状态、唯一 authored token source/generation direction，以及仅由 `DESIGN.md` canonical owning 的项目/系统/component-family target records。每条 canonical record 记录 stable id、interpretation、selection basis、immutable path/URI + digest、condition coverage 和 editable upstream/update route。screen-specific target 只记录 stable id + owning Screen Contract anchor，不在两处重复完整 metadata。不要添加 Google schema 不支持的 front-matter keys。
+- Markdown section 顺序优先为：`Overview`、`Colors`、`Typography`、`Layout`、`Elevation & Depth`、`Shapes`、`Components`、`Do's and Don'ts`。
+- 写入或修改后，如本地可用，运行 `npx @google/design.md lint DESIGN.md` 检查结构；不要把 lint 结果写成“已通过”除非本轮真实执行。
+- 需要给工程消费 token 时，可用 `npx @google/design.md export --format css-tailwind DESIGN.md` 或 `json-tailwind` 生成临时输出。
+
+## 建议沉淀位置
+
+- `global.md#UX / Screen Brief`：全局体验原则、主要屏幕、跨模块流程。
+- `areas/*.md#User / System Contract`：页面、组件、状态、交互和数据展示契约。
+- `areas/*.md#Key Constraints`：responsive、a11y、品牌/视觉边界、加载/空态/错误态约束。
+- role=`contract` Context：跨页面 / 跨域界面契约及其 durable rationale。
+- role=`decision-rationale` Context：更大或跨切面的稳定交互、信息架构或 surface ownership 取舍原因。
+- `areas/*/verification.md` 或 role=`verification` Context：UI smoke、截图验收、可访问性检查或项目自己的关键验证重复执行路径。
+- `areas/*/deployment.md` 或 role=`deployment` Context：前端部署、预览环境、运行拓扑或健康检查重复执行路径。
+- `project_context/context.toml`：复杂项目的产品域 area/context_unit、role、触发词、按需读取策略和可选边界规则。
+- `DESIGN.md`：视觉 identity、design tokens、组件视觉规则、do/don't、视觉 rationale、唯一 token source/generation direction，以及项目/系统/component-family target 的 canonical adoption records；screen-specific target 只保留 owner/anchor pointer。
+
+不要编造 rationale；仅由当前代码或截图形态反推的理由、实现摘要、PR notes、命令输出、测试通过声明、截图审查、debug 过程和 agent reasoning 不进入 Context 或 `DESIGN.md`。