project-tiny-context-harness 0.7.9 → 0.8.1

package/assets/agents/AGENTS_CORE.md

@@ -1,8 +1,6 @@
 # Minimal Context Harness Protocol
 
-This project uses Tiny Context. The Harness maintains durable Context and workflow authority; project tests, CI, runtime evidence and human acceptance prove product quality.
-
-Tiny Context has three capabilities: Minimal Context, the default Workflow Contract, and the explicitly enabled Single-Goal Long-Task Workflow.
+This project uses Tiny Context. The Harness maintains durable Context and workflow authority; project tests, CI, runtime evidence and human acceptance prove product quality. Its three capabilities are Minimal Context, the default Workflow Contract and the explicitly enabled Single-Goal Long-Task Workflow.
 
 ## Shared Architecture Quality Obligation
 
@@ -16,16 +14,22 @@ Unless an active Long-Task binding exists:
 
 1. Read `project_context/global.md`, `project_context/architecture.md`, `project_context/context.toml` and the default area root, then collect graph/trigger candidates.
 2. Before deciding `Context Delta`, run one bounded text search over `project_context/**` using a small set of high-signal task terms such as explicit area/module names and API/schema/state/security/verification/deployment terms. Merge matching Context with manifest candidates and read only relevant files; search supplements rather than replaces semantic judgment.
-3. For UI/product-surface work, confirm information/action/feedback ownership and use `context_surface_contract` when durable responsibility is unclear or changes; Product Surface Contracts own cross-surface interfaces and optional on-demand Screen Contracts use existing area/subdomain/contract/verification roles for deeper screen/control facts. Before material production UI implementation, reconcile each affected stable surface/control/target key as Context-covered, requiring a Context update, task-local, out of scope or decision-required, then read `DESIGN.md`, its token source and referenced design targets. An unconfigured starter, candidate, style-only guidance or inspiration does not authorize invented production layout; only a selected exact/constraint target with adequate declared coverage authorizes fidelity. `design-system-authoring` is an explicit-only cold-start/repair capability that uses Open Design to generate/select/adopt project Design Authority; never infer or auto-run it. For an explicit standalone request to generate or iterate resources, `design-resource-authoring` keeps the requested output/development content as the hard ceiling. Style-bearing work stops on unconfigured Design Authority and points to the explicit design-system Skill; non-fidelity work remains lightweight. Configured style-bearing Open Design projects bind and verify the adopted provider design-system ID. After final selection, design-resource authoring may reconcile accepted decisions into the initial proposal exactly once, but it never changes Context, `DESIGN.md`, a Source Plan, code or Contract. Its resources remain ordinary Source until the consuming workflow adopts durable meaning.
+3. For UI/product-surface work, confirm information/action/feedback ownership and use `context_surface_contract` when durable responsibility is unclear or changes. For material UI, reconcile affected stable surface/control/target keys as Context-covered, requiring a Context update, task-local, out of scope or decision-required; traverse owning Context and `DESIGN.md`; and open every affected selected `exact-target` or `constraint`. Missing, stale, unreadable or conflicting authority fails closed for the affected claim. Local fixes and explicit non-fidelity prototypes stay lightweight.
 4. Complete the shared `Architecture Deliberation`, then decide exactly one `Context Delta: none|required`. Update owning Context before code when durable product ownership, architecture, API/schema/data, state/recovery, dependency, security, product-surface responsibility or repeatable verification/deployment changes. Local fixes preserving durable semantics are `none`.
 5. Use the agent/platform internal plan. Keep `Architecture Context Hit`, `Decision Rationale Hit: existing|required|none` and `Modularity Check: none|required|exception` as internal routing and maintenance questions, not artifacts or extra deltas.
-6. Implement precisely, run project-owned verification, perform Contract Conformance including the shared `Architecture Conformance`, then run the separate Context drift check and report implementation, verification, architecture conformance, Context status and blockers.
+6. Implement precisely, run project-owned verification, perform Contract Conformance including the shared `Architecture Conformance` and any selected-design closure below, then run the separate Context drift check. Report implementation, verification, architecture conformance, Context status and blockers. For material UI, inspect the real production entry after the first runnable vertical slice and rerun the affected cold-start journey on the final candidate; a detached route, specimen or deep link is supplemental evidence only.
 
 The default workflow never requires a plan artifact, matrix, verdict, evidence ledger or result document. Optional scratch is not Context or completion proof. The bounded Context search creates no index, cache, state or second authority.
 
-Externally authored design resources such as Figma frames, images, prototypes and component specifications are ordinary Source. Resource authoring may reconcile a selected direction into the initial proposal once, but it does not update `project_context/**` or `DESIGN.md`, edit a Source Plan/Contract/production implementation or claim acceptance. Explicit `design-system-authoring` separately adopts a selected Open Design system into canonical `DESIGN.md`, one token source/direction and owning Context. The consuming development workflow still owns UI Authority Closure, implementation and verification; candidates authorize no fidelity.
+## Selected-Design Conformance Obligation
+
+This shared obligation activates only for a selected implementation handoff. Run `ty-context design-resource preflight <handoff.md>` before UI Authority Closure. A Web/App target needs one completely acquired machine-readable canonical entry and its exact dependency closure; unresolved locators/cells/meaning, unsupported evidence or stale digests fail closed. Preflight and hashes prove input completeness/integrity, never production conformance.
+
+Every adopted target has exactly one canonical record: `DESIGN.md` for project/system/component-family scope or the owning Screen Contract for one-screen/interaction scope. That record owns interpretation, selection basis, immutable locator/digest, condition coverage and editable-upstream update route; other layers keep only the stable key, owner/anchor and local applicability. Use the on-demand UIUX Skill for deterministic Design Source Projection. Never overwrite an adopted baseline; update upstream, approve a new immutable version and update the canonical record.
 
-For external product, architecture, technical or acceptance sources, internally classify every material constraint as covered by Context, requiring a Context update, task-local, explicitly out of scope or requiring a genuine user decision. Conformance must confirm controlling Context reached the correct modules, surfaces, APIs, state machines and verification paths without forbidden shortcuts or duplicate authority.
+Default work keeps one ephemeral exact accounting of covered Source Items, declared verification methods, blockers, targets and conditions. Route every applicable item to the production owner, cold-start journey and an executed final-candidate project check whose failure remains attributable; one check may cover several methods only when each method/fact can fail distinctly. A selected-target, implementation or declared check-input change stales closure. Any unresolved, unmapped, unexecuted, stale or indistinguishable item blocks a complete-conformance claim and must be reported as a gap. This creates no file, matrix, Claim set, state or Gate.
+
+Externally authored resources remain ordinary Source and exploration remains schema-free. `design-system-authoring` is explicit-only; `design-resource-authoring` keeps the requested scope ceiling and may reconcile final accepted decisions into the initial proposal once, but neither authoring path changes Context/code/Contract or claims acceptance. An active Long-Task projects this same obligation into its existing Claims, Assertions, bindings and Final Gate and never also runs the default closure. For every external product, architecture, technical or acceptance constraint, internally classify it as covered by Context, requiring a Context update, task-local, out of scope or decision-required; Conformance confirms it reached the correct owner and verification without shortcuts or duplicate authority.
 
 ## Long-Task Routing
 
@@ -35,22 +39,24 @@ Do not infer long-task mode from duration, complexity, file count or agent prefe
 2. Explicit `/long-task-workflow` authors or resumes exactly one complete `long-task-delivery-v2` Contract for the selected delivery.
 3. `/normal-long-task` is a retirement pointer. Otherwise remain on the default Workflow Contract, even when work is long.
 
-Source-quality authoring and Contract Draft authoring belong inside `long-task-workflow`: inventory and refine raw/revised proposals, selected design resources and mixed attachments into self-contained real Source, then continuously revise the same non-authoritative `delivery-contract.yaml` until formal Compile creates Authority Lock. No standalone Source Plan handoff is required; a legacy Source Plan remains ordinary input. Candidate resources authorize no fidelity Claim; selected targets enter marked Source and existing verification inputs, and after Authority Lock use protected revision.
+Raw/revised proposals, selected design resources and mixed attachments enter one Source-bound Contract Draft loop immediately. Source inventory, refinement, provenance, markers and Contract mapping converge in the same non-authoritative `delivery-contract.yaml` until Preflight is ready and formal Compile creates Authority Lock; there is no prior or internal Source-authoring stage. A legacy Source Plan remains ordinary input. Candidate resources authorize no fidelity Claim. A selected implementation handoff must pass the shared design-resource preflight; its marked residual handoff enters `task.source_paths`, its handoff and source-profile entry/dependencies enter target Check `verification_inputs`, and Long-Task Preflight/Compile requires exact target/condition/file equality, covered Source Claims, one independent positive Assertion per declared verification method and blocker Source-item/method lineage before Authority Lock. After lock, resource changes use Authority Revision.
+
+When an Outcome declares Controls, its Product `surface_bindings` bind every Control to an owner surface, required product target, existing route/component Bindings and a root-entry success journey. Each bound Control's navigation result—or interaction, trigger or location fallback—must be proved on that target with interaction plus target-runtime evidence. Selected exact/constraint targets additionally bind declared conditions and frozen inputs to current actual/comparison artifacts through `design_conformance`; `verification_method_bindings` map every handoff method to a separate positive Assertion with relevant Source Claims and required evidence capabilities. Every declared design-acceptance blocker preserves exact Source-item/method provenance and resolves to target-local machine proof or a target-blocking external confirmation; it cannot be dismissed in-band, and scope removal requires revised Source/Contract authority. These are protected Contract semantics, not a UI registry, second Gate or per-surface state.
 
 The workflow uses one native Goal, one selected workspace, one Contract and one Final Gate. New authoring uses inline vertical Outcomes grouped by ordered Stages; existing `outcome_files` are physical compatibility only. Target profiles name required product targets and root runtimes; Checks declare Given/When journeys and all-of Evidence Capabilities. Stage/frontier state is derived from ordinary Progress and creates no second Gate, Receipt, scheduler or completion authority.
 
-After the first Authority Lock, stop once before implementation and ask the user to continue with the current model or switch models and then resume the active Long-Task. A model choice already stated explicitly for this task satisfies the checkpoint; later revisions do not repeat it. Harness records no model route or checkpoint state.
+After the first Authority Lock, treat `execution_model_checkpoint.required: true` as a terminal-turn boundary. Unless the user already stated an explicit task-specific choice naming current-model continuation or a model switch, end the current turn before product implementation, file edits, builds or tests and ask the user to choose `continue_current_model` or switch models and then resume. Generic continue/resume/finish/continue-goal language does not satisfy the checkpoint; later revisions do not repeat it. Harness records no model route or checkpoint acknowledgement state.
 
-Before authoring, proof design or authority lifecycle work, read the phase-specific references in the package-managed `long-task-workflow` Skill. Use `ty-context long-task help` for CLI syntax instead of treating this startup router as a command reference.
+During Draft authoring, proof design or authority lifecycle work, read the applicable references in the package-managed `long-task-workflow` Skill. Use `ty-context long-task help` for CLI syntax instead of treating this startup router as a command reference. Before first Authority Lock, Preflight and Compile classify current HEAD-relative workspace changes against protected paths and declared expected/support ownership; after lock, Verify and Final Gate apply the same fail-closed categories against the immutable baseline. During first enable, protection covers only exact files present in the current package asset tree for configured managed destinations plus the exact harness config/hook files; managed directory roots and broad `.codex/**` are never exempt.
 
-Final Gate, Stop and close recompile the source Contract and rerun every declared Check on one clean current snapshot. Final Gate is the Long-Task path's sole `Architecture Conformance` owner; do not run a second default-workflow closure. Required targets cannot substitute for one another; presence cannot prove behavior; success and degradation remain distinct; typed boundary effects require an observer. Targeted verify is repair evidence only. Status, progress, Stage/frontier projections, receipts and compiled cache are audit/recovery surfaces only; prose, historical tests or Agent judgment never create acceptance. An adopted Authority Revision returns to rolling execution and is never delivery completion. External confirmations remain typed and explicit; machine acceptance reports target/stage qualification but cannot by itself authorize completing the platform-native Goal, CI, deployment or human acceptance.
+Final Gate, Stop and close recompile the source Contract and rerun every declared Check on one clean current snapshot. Final Gate is the Long-Task path's sole `Architecture Conformance` and selected-design closure owner; do not run either default-workflow closure. Required targets cannot substitute for one another; presence cannot prove behavior; resource integrity or `visual_render` cannot substitute for selected-target `design_conformance`; success and degradation remain distinct; typed boundary effects require an observer; unresolved design blockers remain blocking. `verify --explain` is a read-only declared-execution preview and creates no proof or Progress. Targeted verify is repair evidence only; `progress_stale` is a freshness fact, not a per-edit rerun instruction, so coalesce related edits and refresh the cheapest reliable owning Check before dependent reliance or Final Gate. Status, progress, Stage/frontier projections, receipts and compiled cache are audit/recovery surfaces only; prose, historical tests or Agent judgment never create acceptance. Authority Revision separates authority change from user decision: mechanically bounded revisions may auto-adopt but still invalidate affected evidence; semantic/proof/forbidden-boundary/verifier-kernel changes and unknown reasons require one exact decision. Present the self-contained brief first. If an explicit current task instruction exactly covers every listed reason, mechanically relay it without a second question; generic continuation, blanket authorization, recommendation or Agent inference never qualifies. Coalesce withdrawn candidates and ask only for the final blocking identity. An adopted revision returns to rolling execution and is never delivery completion. External confirmations remain typed and explicit; machine acceptance reports target/stage qualification but cannot by itself authorize completing the platform-native Goal, CI, deployment or human acceptance.
 
 Tiny Context does not create or restore platform Goals, invoke models, spawn agents, call an App Server, create branches/worktrees, merge, push, open PRs, deploy or manage process trees. `ty-context enable long-task` installs the Long-Task Workflow Skill, the retired Source Plan compatibility pointer and package-owned completion Hook.
 
 ## Durable Facts And Generated Surfaces
 
 - Context is intended ownership/boundary/contract truth; code is current implementation truth. Treat disagreement as drift, missing work or stale Context.
-- Long-term facts live only in `project_context/**` or `DESIGN.md`; versioned authored design targets remain upstream project Source/verifier inputs until the consuming workflow adopts durable meaning, while generated implementation screenshots/diffs, logs, raw evidence, secrets, runtime state and receipts do not become Context.
+- Long-term facts live only in `project_context/**` or `DESIGN.md`; adopted decision-relevant design targets remain Context-reachable project Source/verifier inputs through stable keys and exactly one canonical adoption record rather than becoming Context themselves. Generated implementation screenshots/diffs, logs, raw evidence, secrets, runtime state and receipts do not become Context.
 - Managed `AGENTS.md` blocks, `<harnessRoot>/ty-context-managed/**` and package-managed Skills are generated and sync-overwritten.
 - Explicit upgrades use `context_harness_upgrade`; package sync never imports retired Campaign or development-period authority state.
 

package/assets/context_templates/global.md

@@ -36,6 +36,7 @@
 - Capture durable screen, flow, interaction, responsive and accessibility facts. Use `DESIGN.md` for visual identity and design tokens when needed.
 - For web/front-end surfaces, record durable page responsibilities, core user judgments, persistent information boundaries and cross-page or cross-layer ownership when they guide future changes.
 - Reference durable versioned design targets at their project-native path or URI and classify them as `exact-target`, `constraint` or `inspiration`; do not paste generated implementation screenshots, diffs or review logs into Context.
+- When selected resources arrive through a validated `design-resource-handoff-v1`, keep only durable surface/control/target ownership and a route to its immutable Source here. Do not copy the handoff's condition/evidence/coverage index into Context; future work must open the handoff and affected exact/constraint resources and rerun shared preflight before fidelity implementation.
 
 ## Verification Entry Points
 

package/assets/context_templates/screen-contract.md

@@ -11,8 +11,8 @@ Write project-specific facts only. Do not copy visual token values, binary targe
 ## Authority Boundary
 
 - Product Surface Contract owns cross-surface responsibility, main/drilldown placement and shared invariants.
-- This Screen Contract owns stable screen hierarchy, regions, state/navigation behavior and durable material-control semantics.
-- `DESIGN.md` owns visual-system semantics, the authored token source/generation direction and durable target interpretations.
+- This Screen Contract owns stable screen hierarchy, regions, state/navigation behavior, durable material-control semantics and canonical adoption records for one-screen/interaction-specific targets.
+- `DESIGN.md` owns visual-system semantics, the authored token source/generation direction and canonical adoption records for project/system/component-family targets.
 - Versioned authored design targets own their declared concrete composition for named viewport/mode/state/content conditions.
 - Verification Context owns repeatable proof paths. Code is current implementation evidence, not silent design authority.
 
@@ -131,13 +131,22 @@ Describe composition or responsibility changes, not one-off screenshots.
 
 ## Design Target References
 
-Reference project-native targets; do not embed binary content.
+Reference project-native targets; do not embed binary content. Every adopted target has exactly one canonical adoption record. Use this Screen Contract as the canonical owner only for a one-screen/interaction-specific target. For a project/system/component-family target owned by `DESIGN.md`, fill only its stable ID, `DESIGN.md` anchor and this screen's local applicability; do not repeat the full record.
 
-| Target ID | Interpretation | Path / Immutable URI | Viewport / Platform | Theme / Mode | State / Content Coverage | Selection Basis |
-|---|---|---|---|---|---|---|
-| `<stable-target-id>` | `exact-target` / `constraint` / `inspiration` |  |  |  |  |  |
+| Target ID | Canonical Owner / Anchor | Interpretation | Immutable Adopted Path / URI + Digest | Editable Upstream / Owner / Update Route | Declared Condition Coverage | Selection Basis | Local Applicability |
+|---|---|---|---|---|---|---|---|
+| `<stable-target-id>` | `this Screen Contract#...` / `DESIGN.md#...` | `exact-target` / `constraint` / `inspiration` |  |  |  |  |  |
 
-An `exact-target` authorizes fidelity comparison only for its declared conditions. A `constraint` governs only its named rule. `inspiration` does not authorize reproduction. An implementation screenshot cannot register itself as its own target.
+The canonical record owns interpretation, selection basis, immutable locator/digest, declared condition coverage and editable upstream/update route. Leave those fields pointer-only when this Screen Contract is not the canonical owner. An `exact-target` authorizes fidelity comparison only for its declared conditions. A `constraint` governs only its named rule. `inspiration` does not authorize reproduction. For an adopted exact target/constraint, the immutable locator must be readable and the editable upstream/update route must be verified or explicitly marked as a manual/external boundary. Relevant work opens the resource rather than treating this row as consumption. Update upstream and register a new immutable version/digest in the canonical record; never overwrite the adopted baseline. An implementation screenshot cannot register itself as its own target.
+
+### Selected Implementation Handoff
+
+- Handoff Source Path:
+- Handoff Scope Key:
+- Affected Subject / Target Keys:
+- Durable Owner / Update Boundary:
+
+Fill this pointer only when selected implementation resources use a validated `design-resource-handoff-v1`. The handoff remains ordinary Source and owns its strict subject-by-eight-dimension condition/evidence/verification index; do not duplicate that changing index into Context. This Screen Contract owns durable screen/control meaning and makes the handoff/targets reachable. Consumers must rerun shared preflight and open affected exact/constraint resources; neither this pointer nor a successful digest proves implementation conformance.
 
 ## Verification
 

package/assets/skills/context_development_engineer/SKILL.md

@@ -94,17 +94,23 @@ 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. 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` and bind fidelity claims only to the named target/constraint conditions;
+- 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;
 - identify the production token source, its generation direction, the owning components/routes and any project-local UI/UX Skill before choosing implementation values;
 - 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;
-- run project-owned rendered/component/browser verification and report only the combinations actually checked. Static analysis, generated kits and screenshot artifacts are supporting review material rather than proof of every visual or behavioral claim.
+- 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;
+- 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, Assertion, Check, Stage, Binding and external-confirmation mechanisms. A design candidate or planned target cannot unlock fidelity implementation: selection must become real Source/registry authority and an adopted protected 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_product_plan/SKILL.md

@@ -22,6 +22,7 @@ Project-specific product planning rules belong in a separate project-local Skill
 3. 涉及 Product Surface（Web 页面、移动/桌面屏幕、游戏 UI/HUD/菜单、CLI/TUI 输出、扩展或设备界面）、前端布局、UI/UX、产品模块边界或信息放置时，把产品/页面定位检查作为前置动作：用户在这个 surface 要完成的判断、产品必须提供的信息/动作/反馈、不应常驻的信息、主层/下钻/运维/诊断/详情归属、布局和信息密度是否匹配任务。多 surface、多平台或多模块归属不清时，先读取相关 Context 并搜索入口，必要时使用 `context_surface_contract` 做 Surface Contract Audit，再收窄到具体实现。该检查是下一步变更分类的输入；只有形成长期产品归属、surface 职责、信息架构或模块边界结论时才更新 Context。
    - 若存在 Product Surface Contract，读取并对齐 primary user question、main allows/forbids、drilldown ownership、long-task state 和 verification。
    - 若产品方案只到 surface/流程粒度而 material screen 的实现、验收需要更深事实，不要宣称已有控件级权威。使用稳定 surface/control key 将缺口分类为已有 Screen/interaction Context 覆盖、需要 Context 更新、task-local、out-of-scope 或 decision required；按需从 `screen-contract.md` 提炼 durable hierarchy/regions/navigation/variants/control semantics，视觉系统和 target 仍由 `DESIGN.md`/authored target 所有。
+   - 若本次产品判断会受已采用的 `exact-target` 或 `constraint` 影响，必须沿 owning Context → stable target key → `DESIGN.md` 登记主动打开资源，而不是只读取登记文字。核对不可变 adopted locator/digest、覆盖条件以及 editable upstream owner/locator/update route。缺失、不可读、过期或冲突时将受影响判断保留为 decision required；只有 editable upstream 不可用时仍可读取 immutable target，但“修改设计资源”必须明确为人工/外部更新边界。更新后采用新 immutable version 并更新 owning reference，不覆盖旧基线。
    - 若缺失且本任务改变 durable surface responsibility，将唯一 `Context Delta` 设为 `required`，把具体答案写入 `project_context/**`，跨 surface 或跨 area 使用现有 `contract` role，不新增 surface-specific role。
 4. 涉及输入、选择、搜索、筛选、表单/配置、调度/时间窗口、预算/配额/限流或加载/空态/错误态等 UI 控件时，用“控件任务框架”重新理解用户任务和产品反馈；这只是通用判断框架，不是业务处方库。
 5. 当一个产品对象、能力或接口的增删改需要跨多个页面、模块、Context 或产品域同步调整时，将该影响范围视为产品边界复核信号；先判断它是否应沉淀为独立能力、subdomain 或 area，并明确对外契约、所有权和消费方边界，避免通过手工清单长期维护各消费面的重复映射。

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 Figma 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,22 +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、低保真、候选方向、组件族/独特复杂控件状态、交互原型或条件式 Figma handoff；它以明确输出/开发内容为上限，在范围内补齐材料性 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 也不等于采纳或验收。
 - 候选、灵感和未选定输出不是 Context readiness 或实现权威，不能写入 selected registry；选定目标仍必须完成 UI Authority Closure 和 `Context Delta`。
-- 消费时核对产品 Source、Screen/Control Context、`DESIGN.md`、token owner、资源稳定身份及 exact-target 覆盖条件；只把长期稳定且无冲突的事实写入其唯一 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，整理需要采纳的用户流程、页面/组件清单、关键状态、交互反馈、响应式边界、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`。
@@ -104,11 +120,12 @@ Use this check before material production UI: a new or redesigned screen, primar
 
 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 material design reference.
+- 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 universal pixel-perfect thresholds. Use project-native design assets and the smallest authority sufficient for the claimed fidelity.
 
 ## Visual Delivery Coverage / 视觉交付覆盖
@@ -120,13 +137,14 @@ For material design-system, redesign, high-fidelity implementation or visual-pol
 - 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.
 - 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、线框图、原型或 Figma 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`。
 
@@ -134,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` 生成临时输出。
@@ -149,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,10 +12,11 @@ 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, Figma 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.
+- Exploration and unselected previews stay schema-free. Only a final selected implementation handoff requires the shared strict Markdown adapter; this is input preparation, not a resource pack or acceptance result.
 - Design resources may express user-visible interaction and presentation, but must not invent or become sole owner of business, data, permission or algorithmic rules.
 - Candidates are ordinary external Source. They do not select themselves, become `exact-target`, create Design Authority or prove acceptance.
 - Do not install or persistently configure MCP, plugins, authentication or disclosure paths without separate authorization.
@@ -24,7 +25,7 @@ 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, recovery or Figma routing.
+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
@@ -37,9 +38,11 @@ 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. **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.
-10. **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.
-11. **Return an intent-sized result.** Exploration shows the artifact promptly. Handoff adds stable-key coverage, provenance, binding, limitations and immutable identity. Include the reconciled initial proposal or its updated path when final selection occurred.
+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.
+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
 
@@ -62,6 +65,8 @@ initial proposal
   -> explicit or delegated final selection
   -> one consolidated, idempotent initial-proposal reconciliation
   -> revised proposal + selected immutable resources
+     + canonical source-rich resource set
+  -> validated residual design-resource-handoff-v1 (implementation intent only)
   -> default Goal execution or long-task-workflow
 ```
 
@@ -77,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/locators; provider, project/run and design-system binding status; review and selection basis; immutable provenance; material coverage/unresolved decisions; proposal reconciliation status/path; and forbidden inferences.
+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,6 +16,8 @@ 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.
+
 ## Final proposal reconciliation
 
 Keep a task-local buffer during candidate iteration:
@@ -23,7 +25,7 @@ Keep a task-local buffer during candidate iteration:
 ```yaml
 selection_basis: explicit user/team choice | explicit delegated selection
 selected_resources:
-  - stable key, provider/project/run/entry, declared conditions, immutable digest/snapshot
+  - stable key, provider/project/run/entry, declared conditions, immutable digest/snapshot, editable upstream owner/locator/update method
 accepted:
   - decision, rationale and affected proposal section/stable keys
 rejected:
@@ -46,7 +48,7 @@ This is an explanatory shape, not a schema or required file. Do not write during
 2. consolidate duplicate/intermediate notes;
 3. apply accepted decisions once while preserving all unaffected original requirements and source provenance;
 4. exclude rejected and unresolved choices from requirements, keeping unresolved items visibly unresolved;
-5. record selected resource keys, conditions, locators and digests in the proposal where downstream consumers can recover them;
+5. record selected resource keys, conditions, immutable locators/digests and editable upstream owner/locator/update method in the proposal where downstream consumers can recover and later change them;
 6. make reruns idempotent—update the existing decision/reference instead of appending it again;
 7. if the initial proposal has an authorized writable path, edit that file; otherwise return the full revised proposal in the response.
 
@@ -62,26 +64,52 @@ Return scope/intent, visible candidates, resource dispositions, obvious limitati
 
 ### Implementation handoff
 
-Add:
+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
+...
+```
+````
+
+The strict block includes:
 
 - output/development scope, necessary context and exclusions;
-- stable resource, surface/control/state/target keys;
-- candidate/inspiration/constraint/pre-existing-exact-target classification;
+- stable resource, subject, surface/control/state and target keys;
+- 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;
-- exact entry/preview locator plus SHA-256 or approved snapshot;
-- declared platform, viewport, mode, state, content, interaction, accessibility and motion coverage;
-- stable-key coverage mapping and unresolved dispositions;
+- 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;
+- 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;
+- 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;
+- 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;
 - selection basis, proposal reconciliation path/status and known limitations;
 - outer review and separate provider/artifact/design qualifiers.
 
-No dedicated Markdown/YAML file or directory is mandatory.
+Unknown fields fail closed. A static frame may support only visible layout/visual/component facts for its shown condition; it cannot cover unseen interaction, motion, adaptation/input or accessibility. Run:
+
+```text
+ty-context design-resource preflight <handoff.md>
+```
+
+Do not call the handoff ready until it passes. Exploration, candidates and unselected previews still require no file, schema, hash sequence or validator. There is no fixed directory or one-file-per-control requirement.
 
 ## Recommended downstream routing
 
 ```text
 initial proposal
   -> design-resource-authoring
-  -> selected immutable resources + reconciled initial proposal
+  -> selected immutable resources
+     + complete canonical implementation resources
+     + reconciled initial proposal
+  -> validated residual design-resource-handoff-v1
   -> long-task-workflow (explicit long delivery)
      OR current native Goal + default Workflow Contract (non-long delivery)
 ```
@@ -90,11 +118,11 @@ initial proposal
 
 ### Default Workflow consumption
 
-The consuming Goal brings the revised proposal and selected resources as ordinary Source, performs UI Authority Closure, classifies coverage, decides `Context Delta`, adopts durable facts through existing owners, implements and runs project-owned verification.
+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 and selected resources enter `long-task-workflow`. Its integrated Source-quality authoring makes the delivery self-contained, then Contract `source_paths`, Bindings, `verification_inputs`, Check `input_paths` and `artifact_globs` name only stable locators and conditions actually consumed. Authority Lock, protected 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 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.
 
 ## Forbidden inferences
 
@@ -103,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 editable in Figma because a capability was listed;
+- 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 Figma, 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.
@@ -88,6 +88,20 @@ Use these qualifiers when needed:
 
 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:
@@ -103,22 +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 inspect relevant structure, key states/transitions, viewport behavior, 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.
 
-## Figma and other specialist paths
-
-Figma is optional. Select it only when editable collaboration or library handoff materially benefits the request and a real connector/plugin/export path plus authentication is operational. A listed plugin, skill description or catalogue entry is not proof that editable Figma export works.
-
-If Figma is requested but unavailable:
-
-- report the missing connector/auth/export capability precisely;
-- offer a non-Figma artifact only when it still answers the user's design decision;
-- never relabel HTML, an image or a manifest record as an editable Figma design.
+## Specialist paths
 
-Apply the same capability/readiness rule to image, video, 3D/WebGL and other specialist providers.
+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