project-tiny-context-harness 0.7.5 → 0.7.7

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

@@ -0,0 +1,68 @@
+---
+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, 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 without an explicit resource request, local CSS fixes, durable Design Authority/Context adoption, Source Plan 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 the currently available Open Design capabilities. For an implementation handoff, cover every material user-visible UI/UX decision inside that scope down through relevant controls without forcing one artifact per control or expanding into unrelated product surfaces. 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.
+
+## 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.
+- Treat the user's explicit output or development scope as the hard ceiling. When development covers only a region, control or partial flow, include only the surrounding context needed to design that slice; never let broader background expand generation to the rest of the page or product.
+- Never require one separate design artifact per control. Reuse exact existing component sources and group repeated controls by component family; commission a dedicated study only when a unique or complex control has material uncovered anatomy, variants, states, interaction, feedback or motion.
+- Never infer that a page prototype, design system or static frame covers control states, responsive behavior, accessibility or interaction it does not explicitly specify or demonstrate.
+- Design resources may express user-visible interaction semantics and the presentation of product rules, but they must not invent or become the sole owner of business, data, permission or algorithmic logic.
+- 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.
+
+## 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.
+
+## Core workflow
+
+1. **Fix the requested-scope ceiling.** Separate background coverage from requested output or development coverage. Name the in-scope surfaces, flows, regions, component families, unique controls and applicable conditions; record necessary surrounding context, 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.** For exploration, identify only the uncertainties that block or materially improve the requested decision. For an implementation handoff, account for every material in-scope UI/UX need from surface/flow structure and layout constraints through control anatomy and variants, visual treatment, copy/content presentation, states, interaction/feedback/motion, responsive/platform/input behavior, accessibility and necessary assets. Subtract only coverage explicitly supplied by selected Source; use the task-local coverage model in `resource-selection.md`.
+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. A single inspectable artifact may cover several needs; several artifacts are justified only when each closes independent uncovered meaning. 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. Exploration stops when the requested design decision is supported. An implementation handoff stops only when every material in-scope UI/UX need is covered by existing or newly generated Source, is not applicable, is explicitly excluded by the development scope, or is honestly marked unresolved/unavailable; no material user-visible design choice may be left for the implementer to invent.
+9. **Return the intent-sized result.** A simple exploration should show the artifact promptly. A handoff adds compact provenance, limitations and a stable-key coverage mapping sufficient to show which resource owns each material surface/flow/region/component/control condition without requiring a pack or one file per control. Selected-source preparation requires explicit selection basis and an immutable locator/hash or approved snapshot.
+
+## Raw-draft exploration loop
+
+An initial proposal may go directly through this Skill before `source-plan-authoring`:
+
+```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)
+```
+
+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.
+
+## 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.
+
+## Completion response
+
+Report the requested output/development scope, necessary surrounding context and exclusions; intent; selected/omitted/unavailable resources; visible artifacts or durable locators; provider/artifact status; review actually performed; provenance appropriate to intent; material coverage and 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.

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

@@ -0,0 +1,138 @@
+# Design Resource Handoff
+
+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.
+
+## 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.
+
+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.
+
+## Development-scope coverage
+
+An implementation-facing handoff is complete at the authoring layer only for the user's explicit development scope. Record the in-scope surfaces/flows/regions/component families/unique controls, the minimum surrounding context needed to place them and the explicit exclusions. Broader product Source remains background and does not authorize generating detailed resources for unaffected areas.
+
+Map every material in-scope UI/UX item to selected existing Source, a newly generated resource, `not-applicable`, `excluded-by-scope`, `decision-required` or `unavailable`. The mapping may be concise prose or a task-local structured block; it is not a required pack, persistent coverage authority or acceptance record.
+
+A page target, interactive prototype, component-family workbench or one larger addressable design board may each cover several items. Do not require a separate file per control. Reuse selected component variants for repeated controls and commission dedicated resources only for unique or complex uncovered meaning. A static frame covers only the conditions it actually shows; it does not silently cover dynamic states, interaction, motion, responsiveness or accessibility.
+
+The handoff may specify user-visible triggers, transitions, states, feedback, recovery and the presentation of product rules. Business, data, permission and algorithmic rules remain owned by product/technical Source and must be referenced rather than invented or made authoritative only in visuals.
+
+## Intent-sized response
+
+### 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
+
+Add only the fields needed for another person or workflow to consume it:
+
+- explicit output/development scope, necessary surrounding context and exclusions;
+- 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;
+- for an implementation handoff, a stable-key mapping from each material surface/flow/region/component/control condition to its owning existing/generated resource or unresolved disposition;
+- selection basis if a human selection already exists;
+- unresolved decisions, known limitations and forbidden inferences;
+- outer review performed and provider status qualifier.
+
+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:
+
+```yaml
+selection_basis: explicit user/team decision
+selected_resources:
+  - resource key, explicit locator and immutable hash/snapshot
+accepted:
+  - decision and rationale
+rejected:
+  - alternative and reason
+unresolved:
+  - genuine remaining choice
+impacts:
+  product_rules: []
+  information_hierarchy: []
+  surface_keys: []
+  control_keys: []
+  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`.
+
+## Initial proposal and Source Plan routing
+
+The components are independent and composable:
+
+```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
+```
+
+The recommended design-first loop for substantial new Web/App work is:
+
+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`.
+
+This is a useful path, not a universal required lifecycle. `source-plan-authoring` remains optional upstream synthesis and does not generate design resources.
+
+## Default Workflow Contract consumption
+
+When the user later authorizes concrete development:
+
+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.
+
+Open Design run success, a candidate screenshot or this handoff cannot authorize fidelity or acceptance.
+
+## 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.
+
+## 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.

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

@@ -0,0 +1,112 @@
+# Open Design Provider Orchestration
+
+Use Open Design as the generation engine. This Skill supplies a bounded product commission and retrieves results; it does not recreate the provider's prompts, template logic or catalogue.
+
+## Execution priority
+
+1. **Structured Open Design MCP** for discovery, project/run control and artifact retrieval.
+2. **Open Design CLI or daemon API** when MCP is unavailable or cannot expose a required current capability but equivalent structured behavior is locally available.
+3. **Browser/desktop interaction** only for bootstrap, unavoidable UI-only selection, signed-in provider interaction, visual preview inspection or recovery. Prefer browser-specific control over general Computer Use when both can operate the page.
+
+Do not silently install an MCP server/plugin, alter the user's global Open Design/Codex configuration, sign in, create a paid-provider dependency or expand data disclosure. Explain the exact setup need and obtain separate authorization when persistence or a new disclosure path is required.
+
+## Live capability discovery
+
+Discover rather than remember:
+
+- configured agents and models, including whether Open Design's inner agent is Codex CLI;
+- 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;
+- 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.
+
+Functional skills and rendering templates are different registries. Finding `frontend-design` does not prove that a `mobile-app` or `wireframe-mobile-flow` template is installed, and a remembered template ID is not live capability evidence.
+
+### Rendering-template discovery compatibility
+
+Prefer, in order:
+
+1. a live `list_design_templates`-style method/resource when the provider exposes one;
+2. an explicit template ID supplied by the current project/user and validated by the provider;
+3. a version-guarded structured daemon query that reads the provider's current registry;
+4. provider UI inspection when no structured registry is exposed;
+5. an honest `unavailable` or degraded-discovery result.
+
+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.
+
+## 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.
+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.
+6. Resolve the actual entry explicitly, retrieve the artifact/source, inspect it according to intent and preserve its immutable identity before later iterations or handoff.
+
+Open Design may launch Codex CLI as its configured inner agent. That is provider execution, not recursive invocation of this outer Skill. Do not hardcode a model when the provider can report the current configured model.
+
+## Separate three kinds of state
+
+### Provider execution state
+
+Examples: queued, running, succeeded, failed, cancelled, timed out or unknown.
+
+### Artifact readiness
+
+Examples: missing, partial, corrupt, retrievable, rendered or snapshot-preserved.
+
+### Design suitability
+
+Examples: unreviewed, scope-sane, handoff-checked, human-selected or rejected.
+
+Never collapse these into one “success.” A provider success does not prove a good design; a complete artifact can exist even when a provider run later fails.
+
+Use these qualifiers when needed:
+
+- `artifact-ready/run-unreconciled`: a complete retrievable artifact exists, but the provider run remains nonterminal or inconsistent;
+- `artifact-ready/provider-failed`: the artifact remains complete and retrievable, but the provider later reports failure/timeout.
+
+In both cases preserve the exact run locator, last update, failure diagnostic and artifact hash. Do not claim provider success or downstream acceptance. Retry only when the promised resource is incomplete/corrupt or the user requests another attempt; do not discard a useful independently inspected artifact merely because the terminal state differs.
+
+## Explicit entry and immutable identity
+
+Provider project metadata may omit or stale its entry file. Resolve in this order:
+
+1. validate an explicit project entry path when present;
+2. enumerate project files;
+3. identify the intended provider-native entry from the current run/output rather than guessing;
+4. retrieve that exact file/artifact;
+5. preserve an SHA-256 digest or immutable snapshot before selection/handoff.
+
+A preview URL is mutable navigation, not immutable identity. It may be reported for convenience only beside project/run/entry provenance and a digest. If the user explicitly selects the resource for durable use, export or snapshot it to a user-approved location; never silently choose a repository path.
+
+## 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.
+- **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.
+
+Apply the same capability/readiness rule to image, video, 3D/WebGL and other specialist providers.
+
+## Failure and recovery
+
+- Preserve provider diagnostics; do not replace failures with generated placeholders.
+- Avoid unbounded polling or repeated blind reruns.
+- Re-discover capability after provider upgrades or registry mismatches.
+- If structured paths fail but a UI artifact exists, UI inspection may recover it while retaining the degraded-provider qualifier.
+- If the provider is unavailable and no justified fallback exists, return `unavailable` with the minimum setup needed rather than generating with an unrelated image tool and calling it equivalent.

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

@@ -0,0 +1,166 @@
+# Dynamic Resource Selection
+
+Use this reference to derive a bounded design-resource commission from the actual request. It is a decision model, not a fixed production sequence.
+
+## 1. Establish the scope ceiling
+
+Extract the smallest explicit output or development boundary before interpreting the background:
+
+- 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. 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 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.
+
+## 3. Inventory relevant input roles
+
+Preserve each supplied item's actual role:
+
+- `exact-target`: already authoritative only for its declared conditions;
+- `constraint`: a rule that controls only its stated scope;
+- `inspiration`: directionally useful but not fidelity authority;
+- `current-implementation-evidence`: evidence of current behavior, not desired behavior by default;
+- `background`: product/technical context that informs but does not expand generation scope.
+
+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. 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.
+
+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;
+- **behavior:** control states, transitions, gestures, feedback, loading/error/empty/disabled cases;
+- **visual direction:** composition, typography, color, density, imagery or brand character;
+- **platform/responsiveness:** safe areas, breakpoints, input methods or viewport behavior;
+- **system reuse:** tokens, component variants or cross-surface rules needed by more than the requested artifact;
+- **team editability:** a real need for collaborative editable frames/libraries or an organizational Figma handoff.
+
+Do not manufacture a gap already resolved by selected Source.
+
+## 6. Consider resources conditionally
+
+| Resource | Select when it closes this gap | Usually omit when |
+| --- | --- | --- |
+| 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 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. 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.
+
+## 7. Assign a disposition to every considered resource
+
+- `selected`: required to close a current gap;
+- `optional`: useful, but not necessary for the current decision;
+- `not-needed`: redundant or outside the scope ceiling;
+- `unavailable`: justified but not currently supported/configured;
+- `decision-required`: a genuine unresolved preference changes the commission materially.
+
+Give one concrete reason. Do not turn `optional` into automatic extra work.
+
+## 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 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:
+  material_needs: []
+  existing_mappings: []
+  required_content_visual: []
+  required_components_states: []
+  required_interactions_motion: []
+  required_adaptation_accessibility: []
+inputs:
+  exact_targets: []
+  constraints: []
+  inspiration: []
+  background: []
+selected_capability:
+  kind: runtime-discovered-kind
+  id: runtime-discovered-id
+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.
+
+## 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.
+- 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.
+
+## 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 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.