project-tiny-context-harness 0.8.0 → 0.8.2

package/assets/skills/context_development_engineer/SKILL.md

@@ -9,7 +9,7 @@ description: Use when the user explicitly asks for 开发工程师, 软件工程
 
 This generated Skill provides portable engineering judgment. Project-specific rules belong in `<harnessRoot>/skills/development_engineer/SKILL.md`; the repo-local Skill is more specific while durable conclusions still belong in `project_context/**`.
 
-When an active `/long-task-workflow` binding exists, that Skill owns lifecycle, one-workspace, no-proactive-subagent and Final Gate boundaries. This Skill contributes architecture and implementation judgment only; it must not create a second plan, agent scheduler or acceptance path.
+When an active `/long-task-workflow` binding exists, that Skill owns lifecycle, the selected verification workspace, Goal-owned implementation/delegation boundary and Final Gate. This Skill contributes architecture and implementation judgment only; it must not create a second plan, delegation scheduler/state or acceptance path.
 
 ## 目标
 
@@ -94,7 +94,7 @@ sample provider / interface / page 证据不能替代 all-provider / all-interfa
 
 For material production UI, first confirm Design Authority readiness; then carry declared Context, `DESIGN.md` and Source intent into the real implementation without creating another workflow:
 
-- when a selected implementation handoff exists, run `ty-context design-resource preflight <handoff.md>` before fidelity implementation. Open the strict residual block and every indexed exact/constraint resource. Route each covered Source Item and verification method into the internal implementation plan and project-owned checks. Missing applicability cells, unsupported evidence, unresolvable typed locators, incomplete/truncated implementation source, unresolved rows or stale digests fail closed. Provider retrieval and preflight prove input completeness/integrity only, not the implementation;
+- when a selected implementation handoff exists, run `ty-context design-resource preflight <handoff.md>` before fidelity implementation. Open the strict residual block and every indexed exact/constraint resource. Keep one exact task-local accounting of covered Source Items, declared verification methods, acceptance blockers, selected targets and conditions; route every applicable item to the production owner, cold-start journey and a project-owned check whose failure remains attributable. Missing applicability cells, unsupported evidence, unresolvable typed locators, incomplete/truncated implementation source, unresolved rows or stale digests fail closed. Provider retrieval and preflight prove input completeness/integrity only, not the implementation;
 - treat an unconfigured starter, style-only guidance, inspiration-only references or conflicting targets as insufficient authority for invented production layout; route explicit design authoring through `context_uiux_design` or return for a genuine material decision;
 - classify referenced targets as `exact-target`, `constraint` or `inspiration`; for every affected selected exact target/constraint, traverse its stable key from owning Context through `DESIGN.md` and open the immutable adopted locator/digest before deciding or coding—a registry mention alone is not consumption. Bind fidelity claims only to the named conditions;
 - resolve the editable upstream owner/locator/update route before changing a design resource. Missing, unreadable, stale or conflicting adopted resources fail closed for the affected claim. If the immutable target is readable but upstream editing is unavailable, implementation may consume it but a resource change remains a named manual/external boundary. Never overwrite an adopted baseline; use a new immutable version and update the owning reference;
@@ -102,13 +102,15 @@ For material production UI, first confirm Design Authority readiness; then carry
 - reuse production components and real product routes for states/specimens instead of building a detached static imitation as the acceptance target;
 - trace each selected target and declared viewport/mode/state condition through a stable surface/control key to its production route/component owner, cold-start real-user entry journey and project-owned rendered/interactive Check;
 - preserve approved semantic tokens and component APIs; do not bypass them with undeclared raw color, spacing, typography or motion values merely to match one screenshot;
-- implement the declared Visual Coverage Set across the applicable viewport, theme/mode, state, content-stress and accessibility/motion combinations, while avoiding an unrequested full Cartesian expansion;
-- after the first runnable vertical slice, inspect it through the real production entry so wrong shell/navigation ownership is discovered before broad rollout; rerun the affected cold-start journey on the final candidate;
+- implement the declared Visual Coverage Set across every applicable viewport, theme/mode, state, content-stress and accessibility/motion combination. Do not synthesize unrequested dimensions, but never prune a declared/applicable combination or replace its coverage with risk-only or pairwise sampling unless authoritative Source explicitly narrows the requirement or a project-owned proof establishes equivalence;
+- use the first useful runnable vertical slice as a recommended real-production-entry feedback point when its expected early-localization value exceeds the run cost; it is not an implementation gate. Always rerun the affected cold-start journey on the final candidate;
 - run project-owned rendered/component/browser verification and report only the combinations actually checked. Design file hashes, registry membership and counts prove resource integrity; static analysis, generated kits and screenshot artifacts are supporting review material rather than implementation-conformance proof.
 - For each applicable material control, preserve region/location, type/label, user task, visibility/availability, trigger/input/validation/default, interaction/navigation, loading/empty/success/failure/recovery/permission/feedback and accessibility semantics. An omitted field is not permission to invent durable product behavior; resolve it through UI Authority Closure.
 - never promote the implementation's own generated screenshot/diff into its target; exact targets and acceptance-affecting baselines are selected Source/verifier inputs before comparison.
 
-If an active Long-Task applies, express material visual expectations through its existing Requirement, full Control projection, Product `surface_bindings`, Assertion, Check, Stage, Technical Binding and external-confirmation mechanisms. Include the validated residual handoff in real `task.source_paths` and every declared immutable resource in target verification inputs; make target keys/conditions/files equal the handoff. Map covered Source Items into the root conformance Assertion and one independent Assertion per declared verification method; bind each handoff blocker with the same Source Items and methods. Bind every Control to a required production target and root-entry journey; bind selected exact/constraint targets to typed `design_conformance` actual/comparison evidence. A blocker cannot be dismissed in-band, and scope removal requires revised Source/Contract authority. A design candidate or planned target cannot unlock fidelity implementation: selection must become real Context-reachable Source with an owning Context/`DESIGN.md` reference and an adopted Authority Revision first. Do not introduce a second visual plan, acceptance document or lifecycle.
+Without an active Long-Task, final-current-candidate Contract Conformance confirms every accounted item is mapped, resolved, executed and passing. One project check may cover several methods only when each method and covered fact remains independently attributable on failure. A selected-target, implementation or declared check-input change stales closure. Any unresolved, unmapped, unexecuted, stale or indistinguishable item blocks a complete selected-design-conformance claim; report the checked scope and exact gaps. Do not persist the accounting as a matrix, Claim set, readiness state or Gate.
+
+If an active Long-Task applies, do not run the preceding default closure. Express material visual expectations through its existing Requirement, full Control projection, Product `surface_bindings`, Assertion, Check, Stage, Technical Binding and external-confirmation mechanisms. Include the validated residual handoff in real `task.source_paths` and every declared immutable resource in target verification inputs; make target keys/conditions/files equal the handoff. Map covered Source Items into the root conformance Assertion and one independent Assertion per declared verification method; bind each handoff blocker with the same Source Items and methods. Bind every Control to a required production target and root-entry journey; bind selected exact/constraint targets to typed `design_conformance` actual/comparison evidence. Final Gate is the sole Long-Task carrier. A blocker cannot be dismissed in-band, and scope removal requires revised Source/Contract authority. A design candidate or planned target cannot unlock fidelity implementation: selection must become real Context-reachable Source with one canonical adoption record and an adopted Authority Revision first. Do not introduce a second visual plan, acceptance document or lifecycle.
 
 ## Modularity Check
 

package/assets/skills/context_full_project_export/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: context_full_project_export
-description: Use when the user explicitly asks to 导出尽可能详细的项目全量上下文, 全量上下文导出, 项目上下文全量导出, 项目整体上下文, full project context export, export full project context, project context export, project overall context, Source Pack export, source-pack export, code index export, task context export, 当前项目代码实现, 代码级实现导出, or code-level implementation export in a Minimal Context Harness project.
+name: context_full_project_export
+description: Use when the user explicitly asks to 导出尽可能详细的项目全量上下文, 全量上下文导出, 项目上下文全量导出, 项目整体上下文, full project context export, export full project context, project context export, project overall context, Source Pack export, source-pack export, code index export, task context export, 当前项目代码实现, 代码级实现导出, or code-level implementation export in a Minimal Context Harness project.
 ---
 
 # Context Full Project Export
@@ -13,55 +13,55 @@ This Skill creates a temporary export artifact only. It does not author durable
 
 ## Purpose
 
-When the user needs a full project context export, project overall context export or external LLM handoff, create temporary export artifacts that collect project Context, key agent guidance, architecture/module facts, code navigation and bounded source support for copying into an external tool or one-off discussion.
-
-When the user needs a code-level implementation export, create one temporary Markdown snapshot of current source and engineering configuration files for upload to Web GPT or another external model.
-
-## Workflow
-
-1. Prefer the bounded Source Pack for external LLM / Web GPT planning. It writes at most 5 files total under `tmp/ty-context/context-exports/latest/` and removes old timestamped export rounds:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --source-pack`
-2. Use `--code-index` when implementation navigation is enough and full source bodies are not needed:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code-index`
-3. Use `--task-context <name>` for focused handoff, preferably with a profile or explicit include selectors:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --task-context <name> --profile <profile-id>`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --task-context <name> --include-context project_context/areas/main.md --include-code 'src/example/**'`
-4. Use legacy `--all` when the user explicitly wants both old temporary artifacts in one command. Do not hand-write tracked export documents:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --all`
-5. Use legacy `--full` when only the project Context bundle is needed:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --full`
-6. Use legacy `--code` when only the full code-level implementation snapshot is needed. It generates one Markdown file by default and is the full fallback when Source Pack bundles are not enough:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code`
-7. Custom output paths are allowed only for legacy single-artifact modes and must stay under the temporary export directory. `--all` and Source Pack modes do not accept `--output`:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --full --output tmp/ty-context/context-exports/my-export.md`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code --output tmp/ty-context/context-exports/my-code-export.md`
-8. Use dry-run mode to inspect planned sources before writing:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --source-pack --check`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code-index --check`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --task-context <name> --check`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --all --check`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --full --check`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code --check`
-9. After exporting, report artifact paths, source counts, recommended upload sets and warnings to the user. Do not summarize export contents back into Context.
+When the user needs a full project context export, project overall context export or external LLM handoff, create temporary export artifacts that collect project Context, key agent guidance, architecture/module facts, code navigation and bounded source support for copying into an external tool or one-off discussion.
+
+When the user needs a code-level implementation export, create one temporary Markdown snapshot of current source and engineering configuration files for upload to Web GPT or another external model.
+
+## Workflow
+
+1. Prefer the bounded Source Pack for external LLM / Web GPT planning. It writes at most 5 files total under `tmp/ty-context/context-exports/latest/` and removes old timestamped export rounds:
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --source-pack`
+2. Use `--code-index` when implementation navigation is enough and full source bodies are not needed:
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code-index`
+3. Use `--task-context <name>` for focused handoff, preferably with a profile or explicit include selectors:
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --task-context <name> --profile <profile-id>`
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --task-context <name> --include-context project_context/areas/main.md --include-code 'src/example/**'`
+4. Use legacy `--all` when the user explicitly wants both old temporary artifacts in one command. Do not hand-write tracked export documents:
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --all`
+5. Use legacy `--full` when only the project Context bundle is needed:
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --full`
+6. Use legacy `--code` when only the full code-level implementation snapshot is needed. It generates one Markdown file by default and is the full fallback when Source Pack bundles are not enough:
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code`
+7. Custom output paths are allowed only for legacy single-artifact modes and must stay under the temporary export directory. `--all` and Source Pack modes do not accept `--output`:
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --full --output tmp/ty-context/context-exports/my-export.md`
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code --output tmp/ty-context/context-exports/my-code-export.md`
+8. Use dry-run mode to inspect planned sources before writing:
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --source-pack --check`
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code-index --check`
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --task-context <name> --check`
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --all --check`
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --full --check`
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code --check`
+9. After exporting, report artifact paths, source counts, recommended upload sets and warnings to the user. Do not summarize export contents back into Context.
 
 ## Output Boundaries
 
-- Export artifacts must remain temporary export artifacts, not Context.
-- `--source-pack` defaults to `tmp/ty-context/context-exports/latest/`, with `source-pack-manifest.json`, `full-project-context.md`, `code-index.md` and optional `code-bundle-core.md` / `code-bundle-extended.md`.
-- `--source-pack` and `--task-context` are capped at 5 output files. `--max-pack-files` cannot exceed 5.
-- `--code-index` creates a navigation index and manifest without complete source bodies.
-- `--task-context <name>` creates `task-contexts/task-context-<name>.md` plus optional support bundle; profile verification entries are listed, not executed.
-- `--full` defaults to `tmp/ty-context/context-exports/full-project-context-<timestamp>.md`.
-- `--code` defaults to `tmp/ty-context/context-exports/code-level-implementation-<timestamp>/code-level-implementation.md`.
+- Export artifacts must remain temporary export artifacts, not Context.
+- `--source-pack` defaults to `tmp/ty-context/context-exports/latest/`, with `source-pack-manifest.json`, `full-project-context.md`, `code-index.md` and optional `code-bundle-core.md` / `code-bundle-extended.md`.
+- `--source-pack` and `--task-context` are capped at 5 output files. `--max-pack-files` cannot exceed 5.
+- `--code-index` creates a navigation index and manifest without complete source bodies.
+- `--task-context <name>` creates `task-contexts/task-context-<name>.md` plus optional support bundle; profile verification entries are listed, not executed.
+- `--full` defaults to `tmp/ty-context/context-exports/full-project-context-<timestamp>.md`.
+- `--code` defaults to `tmp/ty-context/context-exports/code-level-implementation-<timestamp>/code-level-implementation.md`.
 - `--all` generates both default artifacts with the same timestamp.
 - `--all` does not accept `--output`; custom filenames are supported only for `--full` or `--code`.
 - `--code` creates one Markdown file, not shards or `all.md`.
 - Do not output to `project_context/**`.
 - Do not modify `project_context/context.toml`.
 - Do not register export artifacts as `[[context]]`, `implementation-index` or any Context graph node.
-- Do not write tracked docs; if the user asks for an ordinary docs path, redirect to `tmp/ty-context/context-exports/**`.
-- Export contents may include redaction warnings; do not bypass secret/token/cookie/password/api_key/credential/bearer/authorization filtering. Use `--redaction-strict` when the user wants the command to fail if any redaction occurred.
-- Profiles under `<harnessRoot>/config.yaml` are export selectors only. They must not become durable Context facts or execute verification commands.
+- Do not write tracked docs; if the user asks for an ordinary docs path, redirect to `tmp/ty-context/context-exports/**`.
+- Export contents may include redaction warnings; do not bypass secret/token/cookie/password/api_key/credential/bearer/authorization filtering. Use `--redaction-strict` when the user wants the command to fail if any redaction occurred.
+- Profiles under `<harnessRoot>/config.yaml` are export selectors only. They must not become durable Context facts or execute verification commands.
 
 ## Handoff
 

package/assets/skills/context_uiux_design/SKILL.md

@@ -1,6 +1,6 @@
 ---
 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.
+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
@@ -19,24 +19,38 @@ Project-specific UI/UX and visual design rules belong in a separate project-loca
 
 按需使用而不是默认加载全部层级：全局体验原则；跨 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/reference interpretation 属于 `DESIGN.md`，具体构图属于 selected target，交付范围与证明属于现有 Delivery Contract/verification。使用稳定 surface/control/target key 连接，不复制成彼此竞争的说明。
+一项事实只有一个主要 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-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。探索候选不需要此文件；provider/preflight 也不等于采纳或验收。
+- 如果上游交付是用于实现的已选资源，先要求一个通过 `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。探索候选不需要此文件；provider/preflight 也不等于采纳或验收。
 - 候选、灵感和未选定输出不是 Context readiness 或实现权威，不能写入 selected registry；选定目标仍必须完成 UI Authority Closure 和 `Context Delta`。
-- 消费时沿 owning Context 的 surface/control/target key 到 `DESIGN.md` 登记，主动打开每个受影响的 selected `exact-target`/`constraint`，而不是把登记存在视为已消费。核对产品 Source、Screen/Control Context、token owner、不可变 adopted locator/digest、覆盖条件以及 editable upstream owner/locator/update route；只把长期稳定且无冲突的事实写入其唯一 owner，不要求统一 pack、目录或工具格式。
+- 消费时沿 owning Context 的 surface/control/target key 到 canonical adoption record，主动打开每个受影响的 selected `exact-target`/`constraint`，而不是把登记存在视为已消费。核对产品 Source、Screen/Control Context、token owner、不可变 adopted locator/digest、覆盖条件以及 editable upstream owner/locator/update route；按 Design Source Projection 只把长期稳定且无冲突的事实写入其唯一 owner，不要求统一 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 源/生成方向和设计引用。仅当当前开发工作流经 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 整理需要采纳的用户流程、页面/组件清单、关键状态、交互反馈、响应式边界、a11y、视觉约束、token 和 design reference registry。若当前请求只是生成资源，转到 `design-resource-authoring`；不要在本 Skill 内复制 provider 生成流程或另建交付格式。
+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`。
@@ -111,26 +125,26 @@ Configured is system-level visual authority only, not surface implementation-rea
 - 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.
+- 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 universal pixel-perfect thresholds. 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.
 
-- Select risk-proportional representative combinations across production surface/route/component, viewport, theme or product mode, interaction/state, content stress and accessibility/motion conditions. Do not expand the full Cartesian product unless Source explicitly requires full combination coverage, and never claim an unchecked combination.
+- 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 and inspect the first runnable production slice before expanding the rest of the UI; deep links remain supplemental when users normally enter through a shell or navigation owner.
+- 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-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`。
 
@@ -138,7 +152,7 @@ For material design-system, redesign, high-fidelity implementation or visual-pol
 
 - 使用 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 reference registry；每个 durable reference 记录稳定 id、surface/route/component、path/URI、`exact-target` / `constraint` / `inspiration` 解释及覆盖条件。不要添加 Google schema 不支持的 front-matter keys。
+- 在 `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` 生成临时输出。
@@ -153,6 +167,6 @@ For material design-system, redesign, high-fidelity implementation or visual-pol
 - `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 和 design reference registry。
+- `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`。

package/assets/skills/design-resource-authoring/SKILL.md

@@ -12,7 +12,7 @@ Commission the smallest sufficient set of design resources for the explicitly re
 - A raw initial proposal is a valid input. Never require, invoke, regenerate or edit a Source Plan.
 - During candidate iteration, keep accepted/rejected/unresolved proposal effects in a task-local delta buffer. Only after a direction is final may this Skill reconcile the initial proposal once. Never continuously rewrite it.
 - Proposal reconciliation changes only the initial proposal: never mutate `project_context/**`, `DESIGN.md`, a Source Plan, Delivery Contract, production code or tests as a design-resource side effect.
-- Never make a prototype, wireframe, high-fidelity candidate, design-system slice, provider-native file, variant count or directory layout universally mandatory.
+- Never make a prototype, wireframe, high-fidelity candidate, design-system slice, provider-native file, variant count or directory layout universally mandatory.
 - Treat the user's explicit output/development scope as the hard ceiling. Include only the surrounding context needed to design that slice.
 - Never require one artifact per control. Reuse selected component sources and group repeated controls by family; commission a dedicated study only for unique or complex uncovered meaning.
 - Never infer that a page frame or prototype covers states, responsiveness, accessibility or interaction it does not explicitly specify or demonstrate.
@@ -25,8 +25,8 @@ Commission the smallest sufficient set of design resources for the explicitly re
 ## Read the references
 
 1. Always read [resource-selection.md](references/resource-selection.md) before deciding what to generate or whether the request is style-bearing.
-2. Read [open-design-provider.md](references/open-design-provider.md) before capability discovery, Design Authority gating, provider execution, implementation-source acquisition or recovery.
-3. Read [downstream-handoff.md](references/downstream-handoff.md) before final selection, initial-proposal reconciliation, handoff or downstream use. A simple unselected non-fidelity preview may stop before this reference.
+2. Read [open-design-provider.md](references/open-design-provider.md) before capability discovery, Design Authority gating, provider execution, implementation-source acquisition or recovery.
+3. Read [downstream-handoff.md](references/downstream-handoff.md) before final selection, initial-proposal reconciliation, handoff or downstream use. A simple unselected non-fidelity preview may stop before this reference.
 
 ## Core workflow
 
@@ -38,10 +38,10 @@ Commission the smallest sufficient set of design resources for the explicitly re
 6. **Discover live capabilities.** Inspect the current Open Design agent/model, skills, templates, design systems, plugins and export paths. Treat absent/non-enumerable capabilities honestly.
 7. **Choose the minimum sufficient commission.** Give each considered resource `selected`, `optional`, `not-needed`, `unavailable` or `decision-required` with one reason. Ask only when a missing preference materially changes the commission.
 8. **Bind and commission through Open Design.** For style-bearing work, create or verify the Open Design project with the adopted design-system ID and require `get_project.designSystemId` to match. Send a bounded product commission through structured MCP; use documented fallbacks only when required.
-9. **Acquire a complete implementation source when applicable.** For Web/App implementation handoff, require Open Design to emit a canonical machine-readable entry plus the full declared dependency set—not only a screenshot or preview. Enumerate and retrieve every selected file without truncation, preserve exact bytes/digests, record one `implementation_web` or `implementation_app` source profile with `acquisition: complete`, and make all local HTML/CSS/JS dependencies resolve inside that frozen set. Non-Web resources use the bounded `reference` profile and are not forced into HTML.
+9. **Acquire a complete implementation source when applicable.** For Web/App implementation handoff, require Open Design to emit a canonical machine-readable entry plus the full declared dependency set—not only a screenshot or preview. Enumerate and retrieve every selected file without truncation, preserve exact bytes/digests, record one `implementation_web` or `implementation_app` source profile with `acquisition: complete`, and make all local HTML/CSS/JS dependencies resolve inside that frozen set. Non-Web resources use the bounded `reference` profile and are not forced into HTML.
 10. **Observe, inspect and iterate.** Keep provider execution, artifact readiness and design suitability separate. Iterate within scope. Keep proposal effects only in the delta buffer while candidates remain unsettled.
 11. **Finalize selection and reconcile once.** After explicit human selection or explicit delegated selection, preserve immutable identity and consolidate accepted, rejected and unresolved effects. Apply only accepted decisions once to a writable initial-proposal file; if it exists only in conversation, return one complete revised proposal. Preserve original intent/provenance and make reruns idempotent. Do not write unresolved or rejected choices as requirements.
-12. **Compile the residual implementation handoff when requested.** For final selected resources intended for development, write one project-native Markdown Source at an authorized path. Preserve readable `ty-source-item` facts and exactly one fenced `design-resource-handoff-v1` YAML block. Keep exact code-expressible UI facts in the canonical resources; the handoff indexes them through typed, locally resolvable locators and adds only scope, applicability, residual product meaning, explicit exclusions/unresolved items, blockers and downstream bindings. Close every applicable subject × target × condition × dimension cell, bind covered cells to same-target/same-condition evidence, Source Items and verification methods, and run `ty-context design-resource preflight <handoff.md>`. Missing/unresolvable locators, partial dependency closure, `decision_required`/`unavailable`, stale digests and unsupported evidence are blocking. Do not create this file for exploration.
+12. **Compile the residual implementation handoff when requested.** For final selected resources intended for development, write one project-native Markdown Source at an authorized path. Preserve readable `ty-source-item` facts and exactly one fenced `design-resource-handoff-v1` YAML block. Keep exact code-expressible UI facts in the canonical resources; the handoff indexes them through typed, locally resolvable locators and adds only scope, applicability, residual product meaning, explicit exclusions/unresolved items, blockers and downstream bindings. Close every applicable subject × target × condition × dimension cell, bind covered cells to same-target/same-condition evidence, Source Items and verification methods, and run `ty-context design-resource preflight <handoff.md>`. Missing/unresolvable locators, partial dependency closure, `decision_required`/`unavailable`, stale digests and unsupported evidence are blocking. Do not create this file for exploration.
 13. **Return an intent-sized result.** Exploration shows the artifact promptly. An implementation handoff returns the validated handoff path, selected immutable resources, stable-key coverage, provenance, binding, limitations and preflight result. Include the reconciled initial proposal or its updated path when final selection occurred.
 
 ## Conditional Design Authority gate
@@ -65,7 +65,7 @@ initial proposal
   -> explicit or delegated final selection
   -> one consolidated, idempotent initial-proposal reconciliation
   -> revised proposal + selected immutable resources
-     + canonical source-rich resource set
+     + canonical source-rich resource set
   -> validated residual design-resource-handoff-v1 (implementation intent only)
   -> default Goal execution or long-task-workflow
 ```
@@ -82,4 +82,4 @@ Small requests may complete generation, selection and reconciliation in one turn
 
 ## Completion response
 
-Report scope, necessary context/exclusions, style dependency and gate result; selected/omitted/unavailable resources; visible artifacts/typed locators; provider, project/run and design-system binding status; review and selection basis; immutable provenance; implementation source profile, entry/dependency closure and acquisition completeness when applicable; material applicability/coverage and unresolved decisions; proposal reconciliation status/path; and forbidden inferences. For implementation intent, report the residual `design-resource-handoff-v1` path and successful shared preflight; never call a failing or unresolved handoff ready.
+Report scope, necessary context/exclusions, style dependency and gate result; selected/omitted/unavailable resources; visible artifacts/typed locators; provider, project/run and design-system binding status; review and selection basis; immutable provenance; implementation source profile, entry/dependency closure and acquisition completeness when applicable; material applicability/coverage and unresolved decisions; proposal reconciliation status/path; and forbidden inferences. For implementation intent, report the residual `design-resource-handoff-v1` path and successful shared preflight; never call a failing or unresolved handoff ready.

package/assets/skills/design-resource-authoring/references/downstream-handoff.md

@@ -16,7 +16,7 @@ For every material in-scope surface/flow/region/component/control condition, rec
 
 Design resources may show user-visible triggers, transitions, states, feedback and product-rule presentation. Business, data, permission and algorithmic rules remain owned by product/technical Source and must not be invented by visuals.
 
-Canonical implementation resources own exact code-expressible layout, visual, content, state, interaction, adaptation, motion, semantic and asset facts. The structured handoff is the residual semantic and index layer for scope, applicability and downstream binding: it indexes those facts through typed locators instead of manually duplicating their values, and it is not a second numeric/style source.
+Canonical implementation resources own exact code-expressible layout, visual, content, state, interaction, adaptation, motion, semantic and asset facts. The structured handoff is the residual semantic and index layer for scope, applicability and downstream binding: it indexes those facts through typed locators instead of manually duplicating their values, and it is not a second numeric/style source.
 
 ## Final proposal reconciliation
 
@@ -64,7 +64,7 @@ Return scope/intent, visible candidates, resource dispositions, obvious limitati
 
 ### Implementation handoff
 
-After final selection for implementation, add one project-native Markdown Source at an authorized repository path. It is ordinary Source, not a pack or Authority. Frozen canonical resources carry addressable implementation facts, while this residual handoff closes scope, applicability, uncovered meaning, product/technical semantics, blockers and downstream bindings. The file contains readable `ty-source-item:start/end` facts plus exactly one:
+After final selection for implementation, add one project-native Markdown Source at an authorized repository path. It is ordinary Source, not a pack or Authority. Frozen canonical resources carry addressable implementation facts, while this residual handoff closes scope, applicability, uncovered meaning, product/technical semantics, blockers and downstream bindings. The file contains readable `ty-source-item:start/end` facts plus exactly one:
 
 ````markdown
 ```yaml design-resource-handoff-v1
@@ -79,17 +79,17 @@ The strict block includes:
 - selected exact-target/constraint/supporting classification; candidates and inspiration do not enter covered implementation rows;
 - provider version, project/run, capability/template, agent/model and live design-system binding;
 - each repository-local immutable resource path, media type and exact SHA-256;
-- for implementation Web/App targets, a canonical entry, complete declared dependency set and `acquisition: complete`; non-Web resources use `reference` and are not forced into HTML;
+- for implementation Web/App targets, a canonical entry, complete declared dependency set and `acquisition: complete`; non-Web resources use `reference` and are not forced into HTML;
 - editable upstream owner, locator and update/export method, or an explicit manual/external-update boundary when unavailable;
 - declared platform, viewport, mode, state, content, input and full/reduced/not-applicable motion conditions;
-- typed, locally resolvable evidence locators (`html_selector`, `markdown_anchor`, `json_pointer`, `css_selector`, `css_custom_property` or bounded `whole_resource`) whose kinds distinguish frame/component variant/prototype state or transition/motion/responsive/input/accessibility/semantic/token/asset/annotation meaning;
+- typed, locally resolvable evidence locators (`html_selector`, `markdown_anchor`, `json_pointer`, `css_selector`, `css_custom_property` or bounded `whole_resource`) whose kinds distinguish frame/component variant/prototype state or transition/motion/responsive/input/accessibility/semantic/token/asset/annotation meaning;
 - stable subjects grouped only when they truly share meaning;
 - every declared scope surface represented by one unambiguous surface subject, with no stable key owned by two subjects;
-- explicit target applicability for each subject and complete subject × target × condition × dimension coverage for `surface_flow`, `visual_content`, `component_control`, `state_interaction`, `motion`, `adaptation_input`, `accessibility` and `assets`;
-- exactly one disposition per applicable cell: `covered`, `not_applicable`, `excluded_by_scope`, `decision_required` or `unavailable`;
-- covered-cell same-target/same-condition evidence, Source-item refs and dimension-appropriate project verification methods; referenced design Source Items use `requirement`, `control` or `acceptance` markers;
+- explicit target applicability for each subject and complete subject × target × condition × dimension coverage for `surface_flow`, `visual_content`, `component_control`, `state_interaction`, `motion`, `adaptation_input`, `accessibility` and `assets`;
+- exactly one disposition per applicable cell: `covered`, `not_applicable`, `excluded_by_scope`, `decision_required` or `unavailable`;
+- covered-cell same-target/same-condition evidence, Source-item refs and dimension-appropriate project verification methods; referenced design Source Items use `requirement`, `control` or `acceptance` markers;
 - source-backed rationales for non-applicable/excluded rows; unresolved rows remain visible and make preflight fail;
-- target-local acceptance blockers that downstream checks must bind rather than dismiss;
+- target-local acceptance blockers with exact target/subject/dimension/Source-item/verification-method lineage and a non-empty `required_capabilities` set; use the narrowest truthful capability such as physical device, sensor, camera, orientation, haptic, screen reader, pixel-density, safe-area, input or production runtime rather than weakening it to an available proxy;
 - selection basis, proposal reconciliation path/status and known limitations;
 - outer review and separate provider/artifact/design qualifiers.
 
@@ -107,7 +107,7 @@ Do not call the handoff ready until it passes. Exploration, candidates and unsel
 initial proposal
   -> design-resource-authoring
   -> selected immutable resources
-     + complete canonical implementation resources
+     + complete canonical implementation resources
      + reconciled initial proposal
   -> validated residual design-resource-handoff-v1
   -> long-task-workflow (explicit long delivery)
@@ -118,11 +118,11 @@ initial proposal
 
 ### Default Workflow consumption
 
-The consuming Goal brings the revised proposal, selected resources and residual handoff as ordinary Source. It reruns shared preflight before UI Authority Closure, opens affected exact/constraint resources before deciding, classifies coverage, decides `Context Delta`, and makes every adopted decision-relevant target Context-reachable through existing owners. It routes every covered Source Item and verification method through the production owner and real-entry checks. A later update creates a new immutable version rather than overwriting the adopted baseline.
+The consuming Goal brings the revised proposal, selected resources and residual handoff as ordinary Source. It reruns shared preflight before UI Authority Closure, opens affected exact/constraint resources before deciding, classifies coverage, decides `Context Delta`, and makes every adopted decision-relevant target Context-reachable through existing owners. It routes every covered Source Item and verification method through the production owner and real-entry checks. A later update creates a new immutable version rather than overwriting the adopted baseline.
 
 ### Long-Task consumption
 
-The same revised proposal, selected resources and validated residual handoff enter `long-task-workflow`'s Source-bound Contract Draft loop immediately. The marked handoff is `task.source_paths`; each Contract design target's frozen `source_paths` and Check `verification_inputs` equal that handoff plus every declared resource path and condition. Covered Source Items map through `source_claims` to the root conformance Assertion. Every verification method maps to an independently failing Assertion carrying its relevant Source Claims; every blocker preserves its Source-item/method lineage into a target-local machine Claim or target-blocking External Confirmation. Authority Lock, Authority Revision and Final Gate remain the sole lifecycle. This Skill creates no Contract Draft, Outcome, Receipt, Check result or Gate.
+The same revised proposal, selected resources and validated residual handoff enter `long-task-workflow`'s Source-bound Contract Draft loop immediately. The marked handoff is `task.source_paths`; each Contract design target's frozen `source_paths` and Check `verification_inputs` equal that handoff plus every declared resource path and condition. Covered Source Items map through `source_claims` to the root conformance Assertion. Every verification method maps to an independently failing Assertion carrying its relevant Source Claims; every blocker preserves its Source-item/method/required-capability lineage into a machine Claim proved on the exact capability-qualified target or a target-blocking External Confirmation. Authority Lock, Authority Revision and Final Gate remain the sole lifecycle. This Skill creates no Contract Draft, Outcome, Receipt, Check result or Gate.
 
 ## Forbidden inferences
 
@@ -131,6 +131,6 @@ Unless independently proven downstream, never infer that a generated resource:
 - is selected, authoritative or accepted;
 - covers unlisted states, viewports, modes, platforms or accessibility;
 - is native implementation because an HTML/image preview renders;
-- is complete because a preview, URL, metadata response, file hash or provider run exists; implementation handoff requires the declared entry/dependency closure and resolvable evidence;
+- is complete because a preview, URL, metadata response, file hash or provider run exists; implementation handoff requires the declared entry/dependency closure and resolvable evidence;
 - changed Context, `DESIGN.md`, a Source Plan, code or Contract;
 - proves production fidelity, correctness, test completion or release readiness.

package/assets/skills/design-resource-authoring/references/open-design-provider.md

@@ -18,7 +18,7 @@ Discover rather than remember:
 - functional skills and plugins;
 - rendering templates or project types;
 - design systems and their selected project binding;
-- specialist paths such as collaborative design platforms, image, video or 3D/WebGL;
+- specialist paths such as collaborative design platforms, image, video or 3D/WebGL;
 - supported project creation, run, cancellation, file and artifact operations.
 
 Current structured tool names may include `list_agents`, `list_skills`, `list_plugins`, `create_project`, `get_project`, `get_active_context`, `start_run`, `get_run`, `cancel_run`, `list_files`, `get_file` and `get_artifact`. Feature-detect them; tool names and provider versions may evolve.
@@ -86,22 +86,22 @@ Use these qualifiers when needed:
 - `artifact-ready/run-unreconciled`: a complete retrievable artifact exists, but the provider run remains nonterminal or inconsistent;
 - `artifact-ready/provider-failed`: the artifact remains complete and retrievable, but the provider later reports failure/timeout.
 
-In both cases preserve the exact run locator, last update, failure diagnostic and artifact hash. Do not claim provider success or downstream acceptance. Retry only when the promised resource is incomplete/corrupt or the user requests another attempt; do not discard a useful independently inspected artifact merely because the terminal state differs.
-
-## Implementation-level output profile
-
-Open Design has demonstrated that a complex Web page can emit a machine-readable implementation set such as `index.html`, component/design specifications, tokens and an asset manifest. Capability is not a per-run guarantee. When the selected resource will drive Web/App implementation, make this an explicit commission and retrieval invariant:
-
-1. request a canonical machine-readable entry and implementation-readable state, interaction, responsive, motion, semantic/accessibility and asset facts for the declared conditions;
-2. enumerate the complete output set and retrieve every selected entry/dependency without truncation;
-3. preserve exact bytes, media types and SHA-256 digests in repository-local immutable files;
-4. record `implementation_web` or `implementation_app`, the canonical entry, every dependency and `acquisition: complete`;
-5. for Web output, require every local HTML/CSS/JS dependency discovered from the frozen source to be present in the declared target set;
-6. use stable IDs/data attributes, Markdown anchors, JSON Pointers, CSS selectors/custom properties or bounded whole-file binary locators that shared preflight can resolve.
-7. before emitting `ready`, exercise every declared verification method against the canonical entry under its claimed conditions and compare facts repeated across code, specifications, tokens and asset manifests. Refine any mismatch; if it cannot be resolved, keep the affected cell `decision_required`/`unavailable` with a blocker. Preserve the checked immutable hashes and report this only as authoring source QA, never production acceptance.
-
-A PNG may be a useful derived visual baseline, but it cannot be the sole source for implementation-level state, interaction, adaptation, accessibility or motion facts. Non-Web resources use the `reference` profile; do not manufacture HTML merely to satisfy this profile.
-
+In both cases preserve the exact run locator, last update, failure diagnostic and artifact hash. Do not claim provider success or downstream acceptance. Retry only when the promised resource is incomplete/corrupt or the user requests another attempt; do not discard a useful independently inspected artifact merely because the terminal state differs.
+
+## Implementation-level output profile
+
+Open Design has demonstrated that a complex Web page can emit a machine-readable implementation set such as `index.html`, component/design specifications, tokens and an asset manifest. Capability is not a per-run guarantee. When the selected resource will drive Web/App implementation, make this an explicit commission and retrieval invariant:
+
+1. request a canonical machine-readable entry and implementation-readable state, interaction, responsive, motion, semantic/accessibility and asset facts for the declared conditions;
+2. enumerate the complete output set and retrieve every selected entry/dependency without truncation;
+3. preserve exact bytes, media types and SHA-256 digests in repository-local immutable files;
+4. record `implementation_web` or `implementation_app`, the canonical entry, every dependency and `acquisition: complete`;
+5. for Web output, require every local HTML/CSS/JS dependency discovered from the frozen source to be present in the declared target set;
+6. use stable IDs/data attributes, Markdown anchors, JSON Pointers, CSS selectors/custom properties or bounded whole-file binary locators that shared preflight can resolve.
+7. before emitting `ready`, exercise every declared verification method against the canonical entry under its claimed conditions and compare facts repeated across code, specifications, tokens and asset manifests. Refine any mismatch; if it cannot be resolved, keep the affected cell `decision_required`/`unavailable` with a blocker. Preserve the checked immutable hashes and report this only as authoring source QA, never production acceptance.
+
+A PNG may be a useful derived visual baseline, but it cannot be the sole source for implementation-level state, interaction, adaptation, accessibility or motion facts. Non-Web resources use the `reference` profile; do not manufacture HTML merely to satisfy this profile.
+
 ## Explicit entry and immutable identity
 
 Provider project metadata may omit or stale its entry file. Resolve in this order:
@@ -117,14 +117,14 @@ A preview URL is mutable navigation, not immutable identity. It may be reported
 ## Review proportional to intent
 
 - **Exploration:** open/render the requested entry, confirm artifact count/scope and obvious corruption, then show it. Do not launch a packaging or validator sequence.
-- **Handoff:** additionally perform the method-proportional source QA above, including relevant structure, states/transitions, viewport behavior, accessibility semantics, assets, obvious console/runtime errors and requested interaction hooks. State exactly what was and was not checked.
+- **Handoff:** additionally perform the method-proportional source QA above, including relevant structure, states/transitions, viewport behavior, accessibility semantics, assets, obvious console/runtime errors and requested interaction hooks. State exactly what was and was not checked.
 - **Selected-source preparation:** require explicit human selection basis, preserve identity/snapshot, and prepare downstream metadata. It still does not verify production behavior.
 
 Provider self-checks, outer artifact sanity review and downstream project verification are separate evidence layers. Never claim native rendering, accessibility, responsive coverage, product correctness or acceptance unless the appropriate downstream project checks actually prove them.
 
-## Specialist paths
-
-Figma, Penpot, OpenPencil, image, video, 3D/WebGL and other providers are optional upstream producers. Use one only when its collaboration/editability or native inspection value is material and its connector/auth/read/export path is operational. A listed plugin, URL, thumbnail or metadata response is not proof of usable native input. If a requested provider is unavailable, report the missing capability precisely, offer another artifact only when it preserves the requested design decision, and never relabel an export as native editable design. Every selected provider still emits repository-readable immutable resources through the same provider-neutral handoff.
+## Specialist paths
+
+Figma, Penpot, OpenPencil, image, video, 3D/WebGL and other providers are optional upstream producers. Use one only when its collaboration/editability or native inspection value is material and its connector/auth/read/export path is operational. A listed plugin, URL, thumbnail or metadata response is not proof of usable native input. If a requested provider is unavailable, report the missing capability precisely, offer another artifact only when it preserves the requested design decision, and never relabel an export as native editable design. Every selected provider still emits repository-readable immutable resources through the same provider-neutral handoff.
 
 ## Failure and recovery
 

package/assets/skills/design-resource-authoring/references/resource-selection.md

@@ -85,7 +85,7 @@ For exploration, ask what remains uncertain inside the scope. For a handoff, ask
 - **visual direction:** composition, typography, color, density, imagery or brand character;
 - **platform/responsiveness:** safe areas, breakpoints, input methods or viewport behavior;
 - **system reuse:** tokens, component variants or cross-surface rules needed by more than the requested artifact;
-- **team editability/native inspection:** a real need for collaborative editable frames/libraries, inspectable component/token facts or an organizational native-platform handoff.
+- **team editability/native inspection:** a real need for collaborative editable frames/libraries, inspectable component/token facts or an organizational native-platform handoff.
 
 Do not manufacture a gap already resolved by selected Source.
 
@@ -100,7 +100,7 @@ Do not manufacture a gap already resolved by selected Source.
 | Flow/journey board | Multiple surfaces, branches or recovery paths must be compared together | The request is one isolated surface/control |
 | Design-system slice | Several requested artifacts need shared tokens/components or reuse rules | One exploratory candidate does not justify a system |
 | Component inventory/specification | Development handoff needs explicit reusable families, variants, state behavior or mappings for several control instances | Exploration is visual only, or selected component sources already cover every mapped instance |
-| Collaborative native design input | Existing team authority, editable collaboration, native component/library reuse or organizational handoff is explicitly valuable and the connector/auth/read/export path is operational | Open Design/project-native implementation source is sufficient or the native path would create a second synchronized representation |
+| Collaborative native design input | Existing team authority, editable collaboration, native component/library reuse or organizational handoff is explicitly valuable and the connector/auth/read/export path is operational | Open Design/project-native implementation source is sufficient or the native path would create a second synchronized representation |
 | Image/illustration/icon/media study | Bespoke content materially defines the selected direction | Generic placeholders answer the present decision |
 
 A prototype is often valuable for new Web/App flows, but it is never automatically required. Low- and high-fidelity resources may both be selected only when they answer independent questions. One comprehensive, inspectable artifact may cover page composition and several component families; a static frame cannot claim unseen interaction or state coverage merely because all controls appear in it.
@@ -155,7 +155,7 @@ This is an explanatory shape, not a required file or schema. Never paste or para
 
 - Keep each revision inside the original scope ceiling unless the user explicitly expands it.
 - Reuse the current Open Design project when that preserves context and provenance; preserve the prior artifact hash before overwriting a selected candidate.
-- Do not create low-fi, high-fi, component boards or native-platform copies merely because a process diagram lists them.
+- Do not create low-fi, high-fi, component boards or native-platform copies merely because a process diagram lists them.
 - For exploration, stop as soon as the requested decision is supported.
 - For an implementation handoff, stop only when every material in-scope coverage item has an explicit disposition and the resource mapping leaves no material user-visible design decision for the implementer to invent. Honest `decision-required` or `unavailable` items may stop further generation, but the result is a blocked authoring outcome: it cannot pass shared preflight, be called a ready implementation handoff or authorize fidelity work. This does not claim Design Authority or implementation acceptance.