project-tiny-context-harness 0.7.6 → 0.7.8

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

@@ -1,65 +1,80 @@
 ---
 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, or design handoff from raw drafts, product/technical plans, optional Source 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, local CSS fixes, durable Design Authority/Context adoption, Source Plan authoring itself, or Long-Task execution.
+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 from the currently available Open Design capabilities. This Skill is a thin task-local planner, provider adapter, iteration guide and handoff layer. Open Design owns its generation logic; Tiny Context owns neither its prompts nor its runtime.
+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 draft is a valid input. Never require, invoke, regenerate or edit a Source Plan.
-- Never edit an initial proposal, `project_context/**`, `DESIGN.md`, a Delivery Contract, production code or tests as a side effect of design-resource work.
-- Never make a prototype, wireframe, high-fidelity candidate, design system, Figma file, variant count or directory layout universally mandatory.
-- Never let supplied background expand the user's explicit output scope. “One control,” “one page,” “these three pages” and “exploration only” are hard ceilings.
-- Generated candidates are ordinary external Source. They do not select themselves, become `exact-target`, create Design Authority or prove product acceptance.
-- Keep provider projects, runs and generated artifacts task-local until the user requests a handoff or explicitly selects a candidate.
-- Do not install or persistently configure MCP servers, plugins, authentication or new disclosure paths without separate user authorization.
-- Do not create a Tiny Context resource pack, provider registry, workflow state, Contract artifact, acceptance record or parallel authority lifecycle.
+- 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.
-2. Read [open-design-provider.md](references/open-design-provider.md) before capability discovery, provider execution, recovery or Figma routing.
-3. Read [downstream-handoff.md](references/downstream-handoff.md) before a handoff, selected-source preparation, accepted-decision summary or use by Source Plan/default/Long-Task workflows. A simple unselected preview may stop before this reference is needed.
+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.
+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 requested-scope ceiling.** Separate background coverage from requested output coverage. Record explicit exclusions and whether the user wants exploration, handoff or selected-source preparation.
-2. **Inventory every supplied input.** Accept raw notes, an initial proposal, product and technical plans, an optional Source Plan, visual briefs, screenshots, references and existing artifacts. Preserve each input's role as existing exact target, constraint, inspiration, current-implementation evidence or background; report unreadable or intentionally unused material and do not invent missing authority.
-3. **Find the design gaps.** Identify only the uncertainties that block or materially improve the requested decision: information hierarchy, flow, control/state behavior, visual direction, responsive/platform behavior, reusable system detail or editable team handoff.
-4. **Discover live capabilities.** Inspect the current Open Design agent/model, functional skills, rendering templates, design systems, plugins and export routes. Treat absent or non-enumerable capabilities honestly; never substitute a remembered catalogue.
-5. **Choose the minimum sufficient commission.** Give every considered resource one disposition: `selected`, `optional`, `not-needed`, `unavailable` or `decision-required`, with one reason. Select multiple resources only when each closes an independent gap. Ask only when a genuine missing preference materially changes the commission; otherwise use traceable, reversible judgment.
-6. **Commission through Open Design.** Send a product-specific, bounded commission envelope around the selected provider capability. Do not copy, restate or simulate the provider's internal template prompt. Prefer structured MCP; use the bounded fallbacks in the provider reference only when needed.
-7. **Observe and inspect proportionally.** Keep provider execution state, artifact readiness and design suitability separate. Exploration needs only scope/corruption sanity and a visible result; handoff needs relevant structure/interaction inspection; downstream product verification remains downstream.
-8. **Iterate within scope.** Revise the candidate from user feedback without expanding coverage or continuously rewriting the source proposal. Stop when the requested design decision is supported, the user stops, or a genuine decision/provider blocker is reached.
-9. **Return the intent-sized result.** A simple exploration should show the artifact promptly. A handoff adds compact provenance, coverage and limitations. Selected-source preparation requires explicit selection basis and an immutable locator/hash or approved snapshot.
+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.
 
-## Raw-draft exploration loop
+## Conditional Design Authority gate
 
-An initial proposal may go directly through this Skill before `source-plan-authoring`:
+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
-raw initial proposal
-  -> bounded design candidate
-  -> user feedback and iterations
-  -> explicit human selection/rejection
-  -> optional consolidated accepted-design-decision delta (when requested)
-  -> separately authorized revision of the initial proposal
-  -> optional source-plan-authoring(revised proposal + selected resources)
+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
 ```
 
-The Skill performs only the first four transitions and returns differences as output. It does not apply the proposal revision or invoke the optional final step. The delta distinguishes accepted, rejected and unresolved choices and identifies affected surface/control/state keys when available. Do not require or emit an interim delta after every iteration: keep those observations task-local and, when requested, return one consolidated delta after the direction is final. Never continuously synchronize or write back the proposal during candidate iteration.
+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 durable UI/UX authority adoption or repair to `context_uiux_design`.
-- Route synthesis of an implementation-ready Source Plan to `source-plan-authoring` only when the user explicitly requests that separate work.
-- Route ordinary implementation with sufficient design authority to the default Workflow Contract.
-- Route a complete explicit Single-Goal delivery to `long-task-workflow`.
-- If no new resource is justified, say so and route to the appropriate existing path instead of generating filler.
+- 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 the requested scope and intent, selected/omitted/unavailable resources, visible artifacts or durable locators, provider/artifact status, review actually performed, provenance appropriate to intent, unresolved decisions and forbidden inferences. For an explicit selection after raw-draft iteration, return the accepted-design-decision delta when requested, without modifying any source document; it may be deferred until the end and consolidated once.
+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.

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

@@ -1,58 +1,31 @@
-# Design Resource Handoff
+# Design Resource Handoff And Proposal Reconciliation
 
-Generated resources remain ordinary external Source. This reference preserves enough identity and meaning for later work without creating a Tiny Context-specific pack, registry or authority lifecycle.
+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.
-- **Human selection:** an explicit user/team choice with a stated basis. It permits selected-source preparation, not automatic durable adoption.
-- **Authority adoption:** a downstream workflow reconciles the selected Source with product/surface Context and `DESIGN.md`, records durable ownership where required and binds implementation/verification to declared conditions.
+- **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.
 
-The Skill may preserve an input already classified as `exact-target`; it may not promote its own candidate to `exact-target`. Unknown coverage remains unknown.
+This Skill may preserve an input already classified as `exact-target`; it may not promote its own candidate to one. Unknown coverage remains unknown.
 
-## Intent-sized response
+## Development-scope coverage
 
-### Exploration
-
-Return promptly:
-
-- requested scope and intent;
-- visible candidate/preview;
-- resource dispositions and obvious limitations;
-- provider/artifact qualifier when execution is not clean;
-- minimal sanity review actually performed.
-
-Do not require files, schemas, packs, hashes or validator runs for a throwaway unselected preview unless they are needed to retrieve/show it reliably.
-
-### Handoff
+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.
 
-Add only the fields needed for another person or workflow to consume it:
+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.
 
-- stable resource key plus surface/control/state/target keys when known;
-- classification: candidate, inspiration, constraint or pre-existing exact target;
-- provider version, project/run, selected capability/template, agent/model and design-system provenance as reported live;
-- explicit source entry or preview locator and immutable hash/snapshot when available;
-- declared platform, viewport, mode, state, content and interaction coverage;
-- selection basis if a human selection already exists;
-- unresolved decisions, known limitations and forbidden inferences;
-- outer review performed and provider status qualifier.
+## Final proposal reconciliation
 
-No dedicated Markdown/YAML file or directory is mandatory. Use concise prose for simple work and a task-local structured block when fields would otherwise become ambiguous.
-
-### Selected-source preparation
-
-Require explicit human selection and record who/what supplied the selection basis. Preserve the exact artifact by hash or a user-approved durable snapshot. Do not rely on a mutable preview URL. Do not choose a repository destination, edit authority files or start implementation without separate authorization.
-
-## Accepted-design-decision delta
-
-When raw-draft exploration leads to an explicit selection, report a delta for the separately owned proposal-revision step:
+Keep a task-local buffer during candidate iteration:
 
 ```yaml
-selection_basis: explicit user/team decision
+selection_basis: explicit user/team choice | explicit delegated selection
 selected_resources:
-  - resource key, explicit locator and immutable hash/snapshot
+  - stable key, provider/project/run/entry, declared conditions, immutable digest/snapshot
 accepted:
-  - decision and rationale
+  - decision, rationale and affected proposal section/stable keys
 rejected:
   - alternative and reason
 unresolved:
@@ -65,62 +38,71 @@ impacts:
   state_keys: []
   interaction_rules: []
   visual_constraints: []
-forbidden_inference:
-  - candidate iteration did not itself revise the proposal or establish Design Authority
 ```
 
-This is an explanatory shape, not a required schema. Include only known changes. Do not emit or apply a delta after every iteration: interim observations remain task-local and may be returned once as a consolidated delta when the direction is final. The Skill does not write back the proposal, decide when a separately authorized owner rewrites it, or invoke `source-plan-authoring`.
+This is an explanatory shape, not a schema or required file. Do not write during iteration. Once the direction is final:
 
-## Initial proposal and Source Plan routing
+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.
 
-The components are independent and composable:
+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.
 
-```text
-raw draft -> design-resource-authoring -> candidates -> explicit selection
-raw draft -> source-plan-authoring -> Source Plan
-revised raw draft + selected design resources -> source-plan-authoring -> richer Source Plan
-selected design resources -> default Workflow or Long-Task Source
-```
+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.
 
-The recommended design-first loop for substantial new Web/App work is:
+### Implementation handoff
 
-1. explore from the initial proposal;
-2. iterate inside the requested scope;
-3. obtain explicit human selection;
-4. when requested, return one consolidated accepted-design-decision delta;
-5. let a separately authorized plan owner revise the proposal;
-6. if requested, pass both the revised proposal and selected immutable resources to `source-plan-authoring`.
+Add:
 
-This is a useful path, not a universal required lifecycle. `source-plan-authoring` remains optional upstream synthesis and does not generate design resources.
+- 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.
 
-## Default Workflow Contract consumption
+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)
+```
 
-When the user later authorizes concrete development:
+`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.
 
-1. bring the selected generated resource as ordinary Source;
-2. perform UI Authority Closure against product/surface Context, `DESIGN.md`, tokens and declared targets;
-3. classify the resource and confirm selection basis/coverage;
-4. decide `Context Delta` and adopt durable facts only through their existing owners;
-5. implement and run project-owned verification.
+### Default Workflow consumption
 
-Open Design run success, a candidate screenshot or this handoff cannot authorize fidelity or acceptance.
+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
+### Long-Task consumption
 
-- A selected resource and an optional Source Plan are parallel ordinary Source inputs to Contract authoring.
-- Contract `source_paths`, bindings, verification inputs, check input paths and artifact globs should name only the stable locators/conditions they actually consume.
-- Surface/control/state/target keys should connect product meaning, source targets, implementation and checks where applicable.
-- Authority Lock, protected Authority Revision and Final Gate remain the only Long-Task authority lifecycle.
-- This Skill creates no Contract Draft, outcome, receipt, Check result or Gate.
-- A later Open Design rerun does not silently revise locked Source; the downstream workflow uses its normal revision rules.
+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 behavior;
-- is a native implementation because an HTML/image preview renders;
-- is editable in Figma because a Figma capability was listed;
-- changed the initial proposal, Source Plan, Context, `DESIGN.md`, code or Contract;
-- proves production fidelity, product correctness, test completion or release readiness.
+- 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.

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

@@ -37,10 +37,27 @@ Prefer, in order:
 
 Never vendor a fallback template catalogue or guess a template ID from prior runs. Do not implement a transport helper unless the live host truly lacks a safe structured path; any helper may normalize metadata and transport only.
 
+## Conditional Design Authority gate and binding
+
+Before any style-bearing commission, read project `DESIGN.md` and its declared authored exact-value token source/generation direction. Style-bearing means the resource materially expresses visual fidelity, brand, typography/color/density, component visual treatment or a production-style prototype. Low-fidelity structure, IA/flow topology and semantics-only behavior/state studies are non-fidelity and do not require the gate.
+
+If authority is absent, explicitly `unconfigured`, still a starter, style-only/inspiration-only, or lacks one authored token source/generation direction, stop before creating a project or run. Direct the user to explicitly invoke `$design-system-authoring`; never auto-run it. A combined explicit request authorizes the sequence.
+
+For configured style-bearing work:
+
+1. read the adopted Open Design design-system ID and digest/provenance from project Design Authority;
+2. confirm `od://design-systems/<id>/DESIGN.md` is readable through MCP;
+3. pass that ID as `designSystem` to `create_project`;
+4. immediately call `get_project` and require `designSystemId` to match;
+5. when reusing a project, check its binding before every new style-bearing run;
+6. on missing/mismatch, prefer a new bounded project with the correct binding when MCP has no safe update method; otherwise feature-detect and verify the provider's structured update.
+
+Never silently use the provider's default or a different system. A provider-side mismatch is a synchronization/rebinding issue; it does not erase the canonical project `DESIGN.md`.
+
 ## Structured commission sequence
 
-1. Record provider version, selected agent/model, functional capability, rendering template, design system and relevant plugin/export readiness as reported live.
-2. Reuse an existing task-local project only when its scope and prior inputs match; otherwise create a bounded project.
+1. Record provider version, selected agent/model, functional capability, rendering template, adopted design system and relevant plugin/export readiness as reported live.
+2. Reuse an existing task-local project only when its scope, prior inputs and required design-system binding match; otherwise create a bounded project. For style-bearing work, pass `designSystem` and verify `get_project.designSystemId` before the run.
 3. Start a run with the product-specific commission envelope and the provider-native capability identifier.
 4. Poll with a bounded cadence. During a long run, report meaningful progress at least once per minute without flooding the user.
 5. Preserve run IDs and the latest provider diagnostic. Support cancellation when the user requests it and the provider exposes it.

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

@@ -4,25 +4,33 @@ Use this reference to derive a bounded design-resource commission from the actua
 
 ## 1. Establish the scope ceiling
 
-Extract the smallest explicit output boundary before interpreting the background:
+Extract the smallest explicit output or development boundary before interpreting the background:
 
-- subject: one control/component, one page, named pages, a flow or a reusable system;
+- subject: one control/component, one region, one page, named pages, a flow or a reusable system;
+- development coverage when the resource is an implementation handoff: named surfaces/routes, regions, component families, unique controls and conditions that will actually be built;
 - platform and viewport when known;
 - modes, states and transitions explicitly requested;
 - fidelity or editability requested, if any;
 - exclusions such as “other pages not included,” “preview only,” “no Figma” or “do not update files.”
 
-Rich background improves a bounded artifact. It never authorizes more artifacts. If the user supplies a complete app plan but asks to preview one button, generate at most the one-control resource.
+Rich background improves a bounded artifact. It never authorizes more artifacts. Necessary surrounding context may show where a partial feature lives, but it does not place the rest of that page or product in scope. If the user supplies a complete app plan but asks to preview one button, generate at most the one-control resource. If the user asks for design resources for one development slice, cover that slice through its material controls and conditions, not the whole background product.
 
 ## 2. Choose the intent
 
 | Intent | User decision being supported | Default stopping point |
 | --- | --- | --- |
 | `exploration` | “What might this look or feel like?” | Visible scoped candidate plus minimal sanity review |
-| `handoff` | “Can another designer/developer reliably consume this?” | Project-native artifact plus provenance, coverage, limitations and relevant checks |
+| `handoff` | “Can another designer/developer reliably consume this without inventing material in-scope UI/UX decisions?” | Minimum sufficient project-native resources plus scope-bound coverage, provenance, limitations and relevant checks |
 | `selected-source-preparation` | “Preserve this explicitly selected direction for later use.” | Immutable identity or approved snapshot, explicit selection basis and downstream notes |
 
-Intent is task-local and need not be persisted. Selected-source preparation does not itself adopt Design Authority.
+Intent and style dependency are task-local and need not be persisted. Selected-source preparation does not itself adopt Design Authority.
+
+Classify each commission before capability selection:
+
+- `style-bearing`: high-fidelity/branded output, visual-direction candidate, typography/color/density treatment, component visual specification or production-style prototype;
+- `non-fidelity`: low-fidelity hierarchy, IA/flow topology, semantics-only interaction/state study or explicitly non-fidelity prototype.
+
+Mixed work is style-bearing unless it can be split into a genuinely independent non-fidelity commission. Style-bearing work requires configured project Design Authority and an Open Design project bound to the adopted system. Missing authority stops and points to the explicitly invoked `$design-system-authoring`; it never triggers that Skill automatically.
 
 ## 3. Inventory relevant input roles
 
@@ -36,9 +44,40 @@ Preserve each supplied item's actual role:
 
 An optional Source Plan is one possible input. Raw notes or an initial proposal are equally valid. Never require one merely to make the other usable.
 
-## 4. Identify independent gaps
+## 4. Derive development-corresponding coverage
+
+For an implementation handoff, use this task-local equation:
+
+```text
+resources to commission
+  = material UI/UX decisions inside the explicit development scope
+  - decisions sufficiently covered by selected existing Source
+```
+
+A decision is material when changing it would materially change what the user sees, understands, can do or receives as feedback. Pure code structure and non-user-visible implementation choices are not design gaps.
 
-Ask what remains uncertain inside the scope:
+Account for the applicable meaning at each level; do not require filler for non-applicable dimensions:
+
+| Coverage level | Material UI/UX meaning |
+| --- | --- |
+| Surface/flow | information hierarchy, page/route composition, layout grid/constraints, region relationships, stacking/overlay, scrolling/overflow, navigation, branching and recovery context |
+| Visual treatment/content | typography, color, spacing, border, radius, elevation, iconography, imagery, density, exact copy/labels, formatting, localization and content presentation |
+| Component/control | anatomy, dimensions, hit area, variants, defaults, visibility/availability and mapping of repeated controls to an existing component family |
+| State/interaction | trigger/input, validation, loading/empty/success/failure/disabled/permission states, transitions, gestures, navigation result, focus/selection behavior, feedback and recovery |
+| Motion | animated property, start/end state, duration, easing, sequencing, interruption and reduced-motion behavior when motion matters |
+| Adaptation/input | viewport/breakpoint, safe area, theme/mode, platform convention, pointer/touch/keyboard behavior, orientation and content stress |
+| Accessibility | label/role, focus order/visibility, keyboard path, touch target, contrast and other applicable assistive behavior |
+| Assets | exact icons, illustrations, media, sound/haptic cues or other bespoke content whose appearance or feedback affects the result |
+
+For every material in-scope item, record one task-local disposition: `existing-covered`, `new-resource-needed`, `not-applicable`, `excluded-by-scope`, `decision-required` or `unavailable`. This accounting is reasoning/handoff metadata, not a required file, persistent coverage registry, Design Authority or acceptance result.
+
+Existing coverage is sufficient only for the conditions it explicitly specifies or demonstrates. Seeing a control in one default page frame does not cover its variants, dynamic states, feedback, motion, responsive behavior or accessibility. Conversely, a selected component source may cover many control instances, so do not commission duplicate designs merely because several stable control keys map to it.
+
+Design resources express user-visible interaction semantics and the presentation of product rules. Business, data, permission and algorithmic rules remain owned by product/technical Source; reference those rules and show their visible consequences without inventing them or making a visual artifact their sole owner.
+
+## 5. Identify independent gaps
+
+For exploration, ask what remains uncertain inside the scope. For a handoff, ask which material coverage items remain `new-resource-needed`:
 
 - **structure:** information hierarchy, layout regions or page relationships;
 - **flow:** navigation, branching, recovery or multi-step sequence;
@@ -50,23 +89,25 @@ Ask what remains uncertain inside the scope:
 
 Do not manufacture a gap already resolved by selected Source.
 
-## 5. Consider resources conditionally
+## 6. Consider resources conditionally
 
 | Resource | Select when it closes this gap | Usually omit when |
 | --- | --- | --- |
-| Control/component state study | One control's variants, anatomy, feedback or edge states are the decision | The page target already specifies those states precisely |
+| Control/component state study | A unique or complex control has uncovered anatomy, variants, feedback, motion or edge states | A selected page/prototype or component source explicitly specifies and demonstrates the applicable conditions |
 | Low-fidelity wireframe | Hierarchy, topology or flow must be judged without visual-style distraction | Structure is settled and only visual direction is unknown |
 | High-fidelity visual candidate | Visual hierarchy, tone or composition needs selection | Existing selected targets already govern the requested conditions |
 | Interactive prototype | Transitions, navigation, state retention or task feel must be experienced | A static decision is sufficient or the provider cannot produce genuine interaction |
 | Flow/journey board | Multiple surfaces, branches or recovery paths must be compared together | The request is one isolated surface/control |
 | Design-system slice | Several requested artifacts need shared tokens/components or reuse rules | One exploratory candidate does not justify a system |
-| Component inventory/specification | Development handoff needs explicit reusable variants and states | Exploration is visual only and no reuse decision is requested |
+| Component inventory/specification | Development handoff needs explicit reusable families, variants, state behavior or mappings for several control instances | Exploration is visual only, or selected component sources already cover every mapped instance |
 | Figma handoff | Editable collaborative frames/libraries are explicitly valuable and operational | A screenshot/HTML/project-native source is sufficient or connector/auth/export is unavailable |
 | Image/illustration/icon/media study | Bespoke content materially defines the selected direction | Generic placeholders answer the present decision |
 
-A prototype is often valuable for new Web/App flows, but it is never automatically required. Low- and high-fidelity resources may both be selected only when they answer independent questions.
+A prototype is often valuable for new Web/App flows, but it is never automatically required. Low- and high-fidelity resources may both be selected only when they answer independent questions. One comprehensive, inspectable artifact may cover page composition and several component families; a static frame cannot claim unseen interaction or state coverage merely because all controls appear in it.
+
+Do not translate control-level completeness into one artifact per control. Map ordinary controls to selected shared component variants, group related states in one component-family board or workbench, and reserve dedicated resources for unique or complex controls whose material meaning is otherwise uncovered.
 
-## 6. Assign a disposition to every considered resource
+## 7. Assign a disposition to every considered resource
 
 - `selected`: required to close a current gap;
 - `optional`: useful, but not necessary for the current decision;
@@ -76,21 +117,26 @@ A prototype is often valuable for new Web/App flows, but it is never automatical
 
 Give one concrete reason. Do not turn `optional` into automatic extra work.
 
-## 7. Build the commission envelope
+## 8. Build the commission envelope
 
 The task-local envelope should contain only product-specific information:
 
 ```yaml
 intent: exploration | handoff | selected-source-preparation
 scope:
-  subjects: [named control/surface/flow keys]
-  ceiling: one-control | one-page | named-pages | named-flow | system-slice
+  subjects: [named surface/flow/region/component/control keys]
+  ceiling: one-control | one-region | one-page | named-pages | named-flow | system-slice
+  necessary_context: []
+  excluded: []
   platform: known-or-unknown
   viewports: []
 coverage:
-  required_content: []
-  required_states: []
-  required_transitions: []
+  material_needs: []
+  existing_mappings: []
+  required_content_visual: []
+  required_components_states: []
+  required_interactions_motion: []
+  required_adaptation_accessibility: []
 inputs:
   exact_targets: []
   constraints: []
@@ -99,26 +145,29 @@ inputs:
 selected_capability:
   kind: runtime-discovered-kind
   id: runtime-discovered-id
-exclusions: []
 expected_entry: known-or-provider-native
 review_promise: minimal-sanity | handoff-checks | selected-source-snapshot
 ```
 
 This is an explanatory shape, not a required file or schema. Never paste or paraphrase the Open Design capability's own seed/template prompt into it.
 
-## 8. Iterate and stop
+## 9. Iterate and stop
 
 - Keep each revision inside the original scope ceiling unless the user explicitly expands it.
 - Reuse the current Open Design project when that preserves context and provenance; preserve the prior artifact hash before overwriting a selected candidate.
 - Do not create low-fi, high-fi, component boards and Figma copies merely because a process diagram lists them.
-- Stop as soon as the requested decision is supported.
+- For exploration, stop as soon as the requested decision is supported.
+- For an implementation handoff, stop only when every material in-scope coverage item has an explicit disposition and the resource mapping leaves no material user-visible design decision for the implementer to invent. Honest `decision-required` or `unavailable` items may stop generation but remain visible blockers/limitations; this does not claim Design Authority or implementation acceptance.
 
-When a human explicitly selects or rejects a direction, return an accepted-design-decision delta when requested rather than editing the initial proposal. Include accepted, rejected and unresolved choices; product, information, control/state and visual implications; affected stable keys; and selected artifact locators/hashes. Do not require a delta after every iteration. Interim observations remain task-local and may be returned once as a consolidated delta after the design direction is final. A separate plan owner decides whether, when and what to revise.
+During iteration, keep accepted, rejected and unresolved implications in a task-local delta buffer. Do not require or emit an interim delta after every iteration and never continuously synchronize the initial proposal. After explicit human selection or explicitly delegated selection, consolidate the buffer once and reconcile only accepted decisions into the initial proposal. If it is a writable file, update it in place while preserving original intent/provenance; otherwise return one complete revised proposal. The operation must be idempotent, name selected artifact locators/hashes and affected stable keys, and exclude rejected/unresolved choices. Never write a Source Plan, Context, `DESIGN.md`, code, tests or Contract.
 
 ## Worked scope examples
 
 - **Large draft, one filter control:** select a control-state study if anatomy and states are uncertain; omit page/flow resources.
-- **One page, style preview:** select one high-fidelity candidate; do not add a design-system pack or validator run.
+- **One page, style preview:** first require configured Design Authority and matching Open Design binding, then select one high-fidelity candidate; do not add a design-system pack or validator run.
+- **One page scheduled for development:** use a page/flow target for layout and context, map ordinary buttons/inputs to selected component variants, and add grouped component-state or dedicated complex-control studies only where relevant static/dynamic states, feedback, motion, responsiveness or accessibility remain uncovered.
+- **Local panel inside a large app:** include enough surrounding page context to place and size the panel, but generate detailed resources only for the panel, its in-scope controls and affected states.
+- **One comprehensive interactive artifact:** accept it as the minimum set when its sections and reachable states explicitly cover every material in-scope item; do not add duplicate control boards. If it exposes only a static/default view, commission the missing state/interaction coverage instead of inferring it.
 - **Three-screen interaction flow:** select a low-fi flow and an interactive high-fi prototype only if topology and interaction/visual behavior are independently unresolved.
 - **Local style fix with exact target:** select no new design resource and route to implementation.
-- **Raw draft before Source Plan:** iterate only requested candidates, optionally return one consolidated accepted-decision delta when requested after selection, and leave both draft revision and later Source Plan authoring separate.
+- **Initial proposal before execution:** iterate only requested candidates, keep one task-local delta buffer, then after selection reconcile accepted decisions once. Pass the revised proposal plus selected immutable resources directly to the default Goal or `long-task-workflow`.