project-tiny-context-harness 0.7.9 → 0.8.0

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

@@ -1,80 +1,85 @@
----
-name: design-resource-authoring
-description: Use when the user explicitly asks to generate, author, plan, commission, or iterate design resources; use Open Design; create a scoped wireframe, prototype, visual candidate, component/control state study, implementation handoff, or the design resources needed for an explicitly named development scope from raw drafts, product/technical plans, visual briefs, screenshots, or existing design resources; or asks to “生成设计资源”, “使用 Open Design”, “生成原型图”, “生成高保真/低保真设计”, “为开发准备设计资源”, or “先看一个控件/页面效果” in a Minimal Context Harness project. Do not trigger for generic design discussion, UX audits, ordinary UI implementation without an explicit resource request, local CSS fixes, durable Design Authority adoption, initial-proposal authoring itself, or Long-Task execution.
----
-
-# Design Resource Authoring
-
-Commission the smallest sufficient set of design resources for the explicitly requested output or development scope from live Open Design capabilities. This Skill is a thin task-local planner, provider adapter, iteration guide, final proposal reconciler and handoff layer; Open Design owns generation logic and Tiny Context owns neither its prompts nor runtime.
-
-## Hard boundaries
-
-- 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.
-- 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.
-- 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.
-- Do not create a resource pack, provider registry, workflow state, Contract artifact, acceptance record or parallel authority lifecycle.
-
-## 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.
+---
+name: design-resource-authoring
+description: Use when the user explicitly asks to generate, author, plan, commission, or iterate design resources; use Open Design; create a scoped wireframe, prototype, visual candidate, component/control state study, implementation handoff, or the design resources needed for an explicitly named development scope from raw drafts, product/technical plans, visual briefs, screenshots, or existing design resources; or asks to “生成设计资源”, “使用 Open Design”, “生成原型图”, “生成高保真/低保真设计”, “为开发准备设计资源”, or “先看一个控件/页面效果” in a Minimal Context Harness project. Do not trigger for generic design discussion, UX audits, ordinary UI implementation without an explicit resource request, local CSS fixes, durable Design Authority adoption, initial-proposal authoring itself, or Long-Task execution.
+---
+
+# Design Resource Authoring
+
+Commission the smallest sufficient set of design resources for the explicitly requested output or development scope from live Open Design capabilities. This Skill is a thin task-local planner, provider adapter, iteration guide, final proposal reconciler and handoff layer; Open Design owns generation logic and Tiny Context owns neither its prompts nor runtime.
+
+## Hard boundaries
+
+- 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.
+- 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.
+- Do not create a resource pack, provider registry, workflow state, Contract artifact, acceptance record or parallel authority lifecycle.
+
+## 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.
-
-## Core workflow
-
-1. **Fix the scope ceiling.** Name in-scope surfaces, flows, regions, component families, unique controls, conditions, necessary context, exclusions and whether the intent is exploration, handoff or selected-source preparation.
-2. **Inventory inputs.** Accept initial proposals, notes, product/technical plans, visual briefs, screenshots, references and existing resources. Preserve each role as exact target, constraint, inspiration, current-implementation evidence or background; report unreadable/unused material.
-3. **Classify visual-style dependency.** Mark the commission `style-bearing` when it materially expresses visual fidelity, brand, typography/color/density, component visual treatment or a production-style prototype. Mark it `non-fidelity` for IA/flow topology, low-fidelity structure, semantics-only behavior/state studies or an explicitly non-fidelity prototype. Mixed work is style-bearing unless split into an independent non-fidelity commission.
-4. **Apply the conditional Design Authority gate.** For style-bearing work, read `DESIGN.md` and its token source. If authority is unconfigured, stop before project/run creation and tell the user to explicitly invoke `$design-system-authoring`; do not invoke it automatically. A combined explicit request authorizes running that Skill first and then resuming this one. Non-fidelity work remains allowed.
-5. **Find design gaps.** For handoff, account for material in-scope structure, control anatomy/variants, content/visual treatment, states, interaction/feedback/motion, adaptation/input, accessibility and assets. Subtract only coverage explicitly supplied by selected Source.
-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.
-
-## Conditional Design Authority gate
-
-Unconfigured means `DESIGN.md` is missing, explicitly says `Design authority status: unconfigured`, remains a starter, contains only style prose/inspiration, or lacks one authored exact-value token source/generation direction. This gate applies only to style-bearing resource authoring; it is not a general project-init gate and configured system-level authority does not by itself prove surface-level implementation readiness.
-
-The stop message must state:
-
-```text
-Style-bearing design resources require an adopted project design system. Explicitly invoke $design-system-authoring to generate/select/adopt one, then resume $design-resource-authoring. I will not initialize it automatically.
-```
-
-## Initial-proposal reconciliation
-
-The normal design-first loop is:
-
-```text
-initial proposal
-  -> bounded Open Design candidates
-  -> feedback and iteration with a task-local delta buffer
-  -> explicit or delegated final selection
-  -> one consolidated, idempotent initial-proposal reconciliation
-  -> revised proposal + selected immutable resources
-  -> default Goal execution or long-task-workflow
-```
-
-Small requests may complete generation, selection and reconciliation in one turn; the invariant is one final semantic writeback, not an artificial pause. Reconciliation may clarify product information, controls/states, interaction and visual constraints supported by the selected resource. It preserves original requirements and records selected resource keys/locators/digests without turning provider output into product authority. If selection never occurs, return candidates and the buffered delta only; do not rewrite.
-
-## Stop and route elsewhere
-
-- Route explicit design-system initialization/adoption to `design-system-authoring`.
-- Route broader durable UI/UX authority repair during development to `context_uiux_design`.
-- Route ordinary implementation with sufficient authority to the default Workflow Contract and current native Goal.
-- Route a complete explicit Single-Goal delivery, using the revised proposal plus selected resources, to `long-task-workflow`.
-- If no new resource is justified, say so instead of generating filler.
-
-## 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.
+
+## Core workflow
+
+1. **Fix the scope ceiling.** Name in-scope surfaces, flows, regions, component families, unique controls, conditions, necessary context, exclusions and whether the intent is exploration, handoff or selected-source preparation.
+2. **Inventory inputs.** Accept initial proposals, notes, product/technical plans, visual briefs, screenshots, references and existing resources. Preserve each role as exact target, constraint, inspiration, current-implementation evidence or background; report unreadable/unused material.
+3. **Classify visual-style dependency.** Mark the commission `style-bearing` when it materially expresses visual fidelity, brand, typography/color/density, component visual treatment or a production-style prototype. Mark it `non-fidelity` for IA/flow topology, low-fidelity structure, semantics-only behavior/state studies or an explicitly non-fidelity prototype. Mixed work is style-bearing unless split into an independent non-fidelity commission.
+4. **Apply the conditional Design Authority gate.** For style-bearing work, read `DESIGN.md` and its token source. If authority is unconfigured, stop before project/run creation and tell the user to explicitly invoke `$design-system-authoring`; do not invoke it automatically. A combined explicit request authorizes running that Skill first and then resuming this one. Non-fidelity work remains allowed.
+5. **Find design gaps.** For handoff, account for material in-scope structure, control anatomy/variants, content/visual treatment, states, interaction/feedback/motion, adaptation/input, accessibility and assets. Subtract only coverage explicitly supplied by selected Source.
+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.
+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
+
+Unconfigured means `DESIGN.md` is missing, explicitly says `Design authority status: unconfigured`, remains a starter, contains only style prose/inspiration, or lacks one authored exact-value token source/generation direction. This gate applies only to style-bearing resource authoring; it is not a general project-init gate and configured system-level authority does not by itself prove surface-level implementation readiness.
+
+The stop message must state:
+
+```text
+Style-bearing design resources require an adopted project design system. Explicitly invoke $design-system-authoring to generate/select/adopt one, then resume $design-resource-authoring. I will not initialize it automatically.
+```
+
+## Initial-proposal reconciliation
+
+The normal design-first loop is:
+
+```text
+initial proposal
+  -> bounded Open Design candidates
+  -> feedback and iteration with a task-local delta buffer
+  -> 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
+```
+
+Small requests may complete generation, selection and reconciliation in one turn; the invariant is one final semantic writeback, not an artificial pause. Reconciliation may clarify product information, controls/states, interaction and visual constraints supported by the selected resource. It preserves original requirements and records selected resource keys/locators/digests without turning provider output into product authority. If selection never occurs, return candidates and the buffered delta only; do not rewrite.
+
+## Stop and route elsewhere
+
+- Route explicit design-system initialization/adoption to `design-system-authoring`.
+- Route broader durable UI/UX authority repair during development to `context_uiux_design`.
+- Route ordinary implementation with sufficient authority to the default Workflow Contract and current native Goal.
+- Route a complete explicit Single-Goal delivery, using the revised proposal plus selected resources, to `long-task-workflow`.
+- If no new resource is justified, say so instead of generating filler.
+
+## 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.

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

@@ -1,108 +1,136 @@
-# Design Resource Handoff And Proposal Reconciliation
-
-Generated resources remain ordinary external Source. Preserve enough identity and meaning for downstream work without creating a Tiny Context pack, registry or authority lifecycle.
-
-## Candidate, selection and authority are separate
-
-- **Candidate:** provider output proposed for review; it authorizes no fidelity.
-- **Selection:** an explicit user/team choice, or explicit delegation with known criteria; it permits proposal reconciliation and selected-source preparation.
-- **Authority adoption:** a downstream development workflow reconciles selected Source with product/surface Context and `DESIGN.md` and binds implementation/verification to declared conditions.
-
-This Skill may preserve an input already classified as `exact-target`; it may not promote its own candidate to one. Unknown coverage remains unknown.
-
-## Development-scope coverage
-
-For every material in-scope surface/flow/region/component/control condition, record selected existing Source, newly generated Source, `not-applicable`, `excluded-by-scope`, `decision-required` or `unavailable`. Include only necessary surrounding context and explicit exclusions. One larger addressable artifact may cover several items; a static frame covers only conditions it actually shows.
-
-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.
-
-## Final proposal reconciliation
-
-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
-accepted:
-  - decision, rationale and affected proposal section/stable keys
-rejected:
-  - alternative and reason
-unresolved:
-  - genuine remaining choice
-impacts:
-  product_rules: []
-  information_hierarchy: []
-  surface_keys: []
-  control_keys: []
-  state_keys: []
-  interaction_rules: []
-  visual_constraints: []
-```
-
-This is an explanatory shape, not a schema or required file. Do not write during iteration. Once the direction is final:
-
-1. confirm the selection basis and immutable resource identity;
-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;
-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.
-
-Never mutate a Source Plan, `project_context/**`, `DESIGN.md`, Delivery Contract, production code or tests. A small request may generate, select and reconcile in one turn; “once” describes final semantic writeback, not a required waiting phase.
-
-If no selection occurs, return candidates plus a consolidated pending delta and leave the proposal unchanged.
-
-## Intent-sized handoff
-
-### Exploration
-
-Return scope/intent, visible candidates, resource dispositions, obvious limitations, provider/artifact qualifiers and the sanity review performed. Do not require a pack, hash or validator for a throwaway unselected preview unless retrieval needs it.
-
-### Implementation handoff
-
-Add:
-
-- output/development scope, necessary context and exclusions;
-- stable resource, surface/control/state/target keys;
-- candidate/inspiration/constraint/pre-existing-exact-target classification;
-- 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;
-- 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.
-
-## Recommended downstream routing
-
-```text
-initial proposal
-  -> design-resource-authoring
-  -> selected immutable resources + reconciled initial proposal
-  -> long-task-workflow (explicit long delivery)
-     OR current native Goal + default Workflow Contract (non-long delivery)
-```
-
-`source-plan-authoring` is not an intermediate stage. A legacy Source Plan remains valid ordinary Source if supplied, but design-resource authoring never creates or edits one.
-
-### 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.
-
-### 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.
-
-## Forbidden inferences
-
-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;
-- changed Context, `DESIGN.md`, a Source Plan, code or Contract;
-- proves production fidelity, correctness, test completion or release readiness.
+# Design Resource Handoff And Proposal Reconciliation
+
+Generated resources remain ordinary external Source. Preserve enough identity and meaning for downstream work without creating a Tiny Context pack, registry or authority lifecycle.
+
+## Candidate, selection and authority are separate
+
+- **Candidate:** provider output proposed for review; it authorizes no fidelity.
+- **Selection:** an explicit user/team choice, or explicit delegation with known criteria; it permits proposal reconciliation and selected-source preparation.
+- **Authority adoption:** a downstream development workflow reconciles selected Source with product/surface Context and `DESIGN.md` and binds implementation/verification to declared conditions.
+
+This Skill may preserve an input already classified as `exact-target`; it may not promote its own candidate to one. Unknown coverage remains unknown.
+
+## Development-scope coverage
+
+For every material in-scope surface/flow/region/component/control condition, record selected existing Source, newly generated Source, `not-applicable`, `excluded-by-scope`, `decision-required` or `unavailable`. Include only necessary surrounding context and explicit exclusions. One larger addressable artifact may cover several items; a static frame covers only conditions it actually shows.
+
+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:
+
+```yaml
+selection_basis: explicit user/team choice | explicit delegated selection
+selected_resources:
+  - 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:
+  - alternative and reason
+unresolved:
+  - genuine remaining choice
+impacts:
+  product_rules: []
+  information_hierarchy: []
+  surface_keys: []
+  control_keys: []
+  state_keys: []
+  interaction_rules: []
+  visual_constraints: []
+```
+
+This is an explanatory shape, not a schema or required file. Do not write during iteration. Once the direction is final:
+
+1. confirm the selection basis and immutable resource identity;
+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, 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.
+
+Never mutate a Source Plan, `project_context/**`, `DESIGN.md`, Delivery Contract, production code or tests. A small request may generate, select and reconcile in one turn; “once” describes final semantic writeback, not a required waiting phase.
+
+If no selection occurs, return candidates plus a consolidated pending delta and leave the proposal unchanged.
+
+## Intent-sized handoff
+
+### Exploration
+
+Return scope/intent, visible candidates, resource dispositions, obvious limitations, provider/artifact qualifiers and the sanity review performed. Do not require a pack, hash or validator for a throwaway unselected preview unless retrieval needs it.
+
+### 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:
+
+````markdown
+```yaml design-resource-handoff-v1
+...
+```
+````
+
+The strict block includes:
+
+- output/development scope, necessary context and exclusions;
+- 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;
+- 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.
+
+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
+     + 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)
+```
+
+`source-plan-authoring` is not an intermediate stage. A legacy Source Plan remains valid ordinary Source if supplied, but design-resource authoring never creates or edits one.
+
+### 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.
+
+### 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.
+
+## Forbidden inferences
+
+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;
+- changed Context, `DESIGN.md`, a Source Plan, code or Contract;
+- proves production fidelity, correctness, test completion or release readiness.