project-tiny-context-harness 0.7.6 → 0.7.7

package/README.md

@@ -137,7 +137,7 @@ npm ci
 npm run smoke:quickstart
 npm run preview:pack
 cd /path/to/your/test-repo
-npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.7.6.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.7.7.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -205,11 +205,13 @@ Combined design-and-implementation work may author candidates in ordinary Outcom
 
 ### Optional Design Resource Authoring
 
-Use `/design-resource-authoring` only for an explicit request to generate, iterate or prepare standalone design resources, or to use Open Design. It accepts raw notes or an initial proposal, product/technical plans, a visual brief, screenshots, existing resources or an optional Source Plan. Source Plan authoring is not a prerequisite; both Skills consume raw inputs independently and neither invokes the other.
+Use `/design-resource-authoring` only for an explicit request to generate, iterate or prepare standalone design resources, prepare resources for a named development scope, or use Open Design. It accepts raw notes or an initial proposal, product/technical plans, a visual brief, screenshots, existing resources or an optional Source Plan. Source Plan authoring is not a prerequisite; both Skills consume raw inputs independently and neither invokes the other.
 
-The Skill enforces the requested scope ceiling, discovers current Open Design capabilities and assigns every considered resource a reasoned `selected`, `optional`, `not-needed`, `unavailable` or `decision-required` disposition. It commissions only the smallest sufficient set through structured MCP with bounded fallback. No prototype, low/high-fidelity pair, component board, Figma handoff, artifact count or directory is mandatory, and Tiny Context copies no provider prompt/template or catalogue.
+The Skill makes the explicit output or development content its hard ceiling; a local slice includes only necessary surrounding context. For an implementation handoff it accounts for material UI/UX meaning through relevant surfaces/flows/regions/components/controls and applicable visual/content, state, interaction/feedback/motion, responsive/platform/input, accessibility and asset conditions, then subtracts only explicit selected-source coverage. It discovers current Open Design capabilities and assigns every considered resource a reasoned `selected`, `optional`, `not-needed`, `unavailable` or `decision-required` disposition.
 
-Exploration returns a visible scoped candidate after minimal sanity review; handoff adds provenance, explicit entry, declared coverage and limitations; selected-source preparation requires explicit human selection and immutable identity. Iteration stays task-local. A final consolidated accepted/rejected/unresolved delta may inform a separately owned proposal revision, but the Skill never edits that proposal, Context, `DESIGN.md`, production code or a Delivery Contract and creates no Design Authority.
+It commissions only the smallest sufficient set through structured MCP with bounded fallback. Repeated controls may map to one component family, one inspectable artifact may cover several needs and only unique/complex uncovered controls need dedicated studies. Static/default views do not imply unseen behavior. No prototype, low/high-fidelity pair, component board, Figma handoff, one-file-per-control rule, artifact count or directory is mandatory, and Tiny Context copies no provider prompt/template or catalogue. Designs carry user-visible interaction semantics, not sole ownership of business/data/permission/algorithmic rules.
+
+Exploration returns a visible scoped candidate after minimal sanity review. An implementation handoff adds provenance, explicit entry, declared coverage, limitations and a concise stable-key mapping from every material in-scope item to existing/generated Source or an explicit non-applicable/excluded/unresolved disposition; it is sufficient only when implementation need not invent a material user-visible choice inside scope. This mapping creates no pack, registry or acceptance authority. Selected-source preparation requires explicit human selection and immutable identity. Iteration stays task-local. A final consolidated accepted/rejected/unresolved delta may inform a separately owned proposal revision, but the Skill never edits that proposal, Context, `DESIGN.md`, production code or a Delivery Contract and creates no Design Authority.
 
 Actual generation remains with configured Open Design/Product Design, Figma, image-generation, prototype or human systems. Their outputs enter the default Workflow or Long-Task as ordinary external Source. Candidates and inspiration authorize no fidelity. A selected exact target controls only its declared conditions and needs stable immutable identity before it can affect a `verification_input`. `context_uiux_design` performs downstream UI Authority Closure; implementation renders and diffs remain evidence rather than self-authorizing targets.
 
@@ -338,7 +340,7 @@ make validate-harness
 
 The modularity gate is `ty-context check-modularity`. Scoped waivers require `owner`, `introduced_at`, `reason`, `tracking_issue` and `expiry_condition`.
 
-The synchronized local preview tarball is named `project-tiny-context-harness-0.7.6.tgz`.
+The synchronized local preview tarball is named `project-tiny-context-harness-0.7.7.tgz`.
 
 ## Community And Further Reading
 

package/assets/README.md

@@ -137,7 +137,7 @@ The smoke packs the local workspace, installs it into a disposable repo and vali
 
 ```sh
 cd /path/to/your/test-repo
-npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.7.6.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.7.7.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -226,11 +226,13 @@ Combined design-and-implementation work may author candidates in ordinary Outcom
 
 ### Optional Design Resource Authoring
 
-Use `/design-resource-authoring` only when explicitly asking to generate, iterate or prepare standalone design resources, or to use Open Design. Inputs may be raw notes or an initial proposal, product/technical plans, a specialized visual brief, screenshots, existing resources or an optional Source Plan. Source Plan authoring is not a prerequisite: both Skills can consume raw inputs independently and neither invokes the other.
+Use `/design-resource-authoring` only when explicitly asking to generate, iterate or prepare standalone design resources, prepare the design resources for a named development scope, or use Open Design. Inputs may be raw notes or an initial proposal, product/technical plans, a specialized visual brief, screenshots, existing resources or an optional Source Plan. Source Plan authoring is not a prerequisite: both Skills can consume raw inputs independently and neither invokes the other.
 
-The Skill fixes the requested output as a hard scope ceiling, discovers current Open Design agents/models, functional skills, rendering templates, design systems, plugins and export routes, then gives every considered resource a reasoned `selected`, `optional`, `not-needed`, `unavailable` or `decision-required` disposition. It commissions only the smallest sufficient set through structured MCP, with bounded CLI/daemon and UI fallback. A prototype, low/high-fidelity pair, component board, Figma handoff, variant count or directory is never universally required, and Tiny Context never copies Open Design prompts/templates or vendors a provider catalogue.
+The Skill fixes the requested output or development content as a hard scope ceiling. A partial feature includes only the surrounding context needed to place it; broad background never expands generation to the rest of the page or product. For an implementation handoff, the Skill accounts for material UI/UX meaning from surface/flow structure through relevant regions and controls: visual/content treatment, component anatomy and variants, static/dynamic states, interaction/feedback/recovery/motion, responsive/platform/input behavior, accessibility and necessary assets. It subtracts only coverage explicitly supplied by selected existing Source, then discovers current Open Design agents/models, functional skills, rendering templates, design systems, plugins and export routes and gives every considered resource a reasoned `selected`, `optional`, `not-needed`, `unavailable` or `decision-required` disposition.
 
-Exploration returns the requested visible candidate after minimal sanity review. Handoff adds project/run/capability provenance, explicit entry, declared coverage and known limitations. Selected-source preparation requires a real human selection basis and immutable hash or approved snapshot, but still creates no Design Authority. Candidate iterations stay task-local; the Skill may return one final consolidated accepted/rejected/unresolved delta for a separately owned proposal revision, but never edits the proposal, `project_context/**`, `DESIGN.md`, production code or a Delivery Contract.
+It commissions only the smallest sufficient set through structured MCP, with bounded CLI/daemon and UI fallback. One page/prototype or component-family workbench may cover many items when its conditions are addressable and inspectable; repeated controls map to shared variants, while unique or complex uncovered controls may need dedicated state/interaction studies. A static/default frame never silently covers unseen state, interaction, motion, responsiveness or accessibility. A prototype, low/high-fidelity pair, component board, Figma handoff, one-file-per-control rule, variant count or directory is never universally required, and Tiny Context never copies Open Design prompts/templates or vendors a provider catalogue. Designs may express user-visible interaction semantics and the presentation of product rules, but business/data/permission/algorithmic rules remain owned by product/technical Source.
+
+Exploration returns the requested visible candidate after minimal sanity review. An implementation handoff adds project/run/capability provenance, explicit entry, declared coverage, known limitations and a concise stable-key mapping from each material in-scope surface/flow/region/component/control condition to existing/generated Source or a non-applicable/excluded/unresolved disposition. The mapping is not a required pack, registry or acceptance result; handoff authoring is sufficient only when no material user-visible choice inside the explicit scope is silently left for implementation to invent. Selected-source preparation requires a real human selection basis and immutable hash or approved snapshot, but still creates no Design Authority. Candidate iterations stay task-local; the Skill may return one final consolidated accepted/rejected/unresolved delta for a separately owned proposal revision, but never edits the proposal, `project_context/**`, `DESIGN.md`, production code or a Delivery Contract.
 
 The actual generation remains with configured Open Design/Product Design, Figma, image-generation, prototype or human systems. Their outputs enter the default Workflow or Long-Task as ordinary external Source. Candidates and inspiration authorize no fidelity. A selected exact target controls only its declared surface/viewport/mode/state/content conditions and needs stable immutable identity before it can affect a `verification_input`. `context_uiux_design` performs downstream UI Authority Closure and adopts only durable facts into Context/`DESIGN.md`; implementation renders and diffs remain evidence artifacts rather than self-authorizing targets.
 
@@ -516,7 +518,7 @@ make validate-harness
 
 The modularity gate is `ty-context check-modularity`. Scoped waivers require `owner`, `introduced_at`, `reason`, `tracking_issue` and `expiry_condition`.
 
-`npm run preview:pack` produces a local preview named `project-tiny-context-harness-0.7.6.tgz` under the preview output directory.
+`npm run preview:pack` produces a local preview named `project-tiny-context-harness-0.7.7.tgz` under the preview output directory.
 
 ## Community And Further Reading
 

package/assets/README.zh-CN.md

@@ -123,11 +123,13 @@ combined design-and-implementation 可以先用普通 Outcome/Stage 生成候选
 
 ### 可选 Design Resource Authoring
 
-只有在用户明确要求生成、迭代、准备独立设计资源或使用 Open Design 时，才使用 `/design-resource-authoring`。输入可以是零散笔记或初版方案、产品/技术方案、专门视觉 brief、截图、已有资源或可选 Source Plan。Source Plan 不是前置项：两个 Skill 都可以独立读取原始输入，互不调用。
+只有在用户明确要求生成、迭代、准备独立设计资源、为一段明确开发内容准备设计资源或使用 Open Design 时，才使用 `/design-resource-authoring`。输入可以是零散笔记或初版方案、产品/技术方案、专门视觉 brief、截图、已有资源或可选 Source Plan。Source Plan 不是前置项：两个 Skill 都可以独立读取原始输入，互不调用。
 
-Skill 先把明确输出当作硬 scope ceiling，再实时发现 Open Design 当前 agent/model、functional skill、rendering template、design system、plugin 与 export route，并把每种候选资源说明为 `selected`、`optional`、`not-needed`、`unavailable` 或 `decision-required`。它只通过结构化 MCP（必要时有限使用 CLI/daemon/UI fallback）委托最小充分资源集；原型、低/高保真组合、组件板、Figma handoff、变体数量和目录都不是全局必选项。Tiny Context 不复制 Open Design 的 prompt/template，也不内置 provider catalogue。
+Skill 把明确输出或开发内容当作硬 scope ceiling。局部功能只可带上定位它所需的周边上下文；再丰富的背景也不能把生成范围扩成页面其余部分或整个产品。面向实现 handoff 时，Skill 要覆盖范围内所有材料性的 UI/UX 含义：surface/flow 与 region 结构、视觉和内容呈现、控件结构/尺寸/变体、静态与动态状态、交互/反馈/恢复/动效、响应式/平台/输入方式、可访问性及必要资产；先扣除已有 selected Source 明确覆盖的条件，再发现 Open Design 当前 agent/model、functional skill、rendering template、design system、plugin 与 export route，并把每种候选资源说明为 `selected`、`optional`、`not-needed`、`unavailable` 或 `decision-required`。
 
-探索模式只做最小完整性检查并尽快展示指定候选；handoff 增加 project/run/capability provenance、明确 entry、声明覆盖与已知限制；selected-source preparation 要求真实人工选择依据和不可变 hash 或已批准 snapshot，但仍不产生 Design Authority。候选迭代保持任务内；Skill 可以在方向最终确定后返回一份合并的 accepted/rejected/unresolved 差异供独立方案步骤处理，但不会修改初版方案、`project_context/**`、`DESIGN.md`、生产代码或 Delivery Contract。
+Skill 只通过结构化 MCP（必要时有限使用 CLI/daemon/UI fallback）委托最小充分资源集。一个可定位、可检查的大页面稿、原型或组件族 workbench 可以覆盖多个事项；重复控件映射到共享变体，只有仍缺少材料性含义的独特/复杂控件才需要专门状态或交互稿。静态/default 页面不能自动代表没展示的动态状态、交互、动效、响应式或可访问性。原型、低/高保真组合、组件板、Figma handoff、逐控件一份稿、变体数量和目录都不是全局必选项。设计资源可以表达用户可感知的交互语义和产品规则的呈现方式，但业务、数据、权限和算法逻辑仍由产品/技术 Source 所有。Tiny Context 不复制 Open Design 的 prompt/template，也不内置 provider catalogue。
+
+探索模式只做最小完整性检查并尽快展示指定候选；面向实现的 handoff 还要增加 project/run/capability provenance、明确 entry、声明覆盖、已知限制，以及每个材料性 surface/flow/region/component/control 条件到已有/新资源或不适用/范围排除/未决项的简洁稳定 Key 映射。该映射不是必选 pack、registry 或验收结果；只有范围内不再有需要开发者自行发明的材料性用户可感知设计决策时，authoring handoff 才算充分。selected-source preparation 要求真实人工选择依据和不可变 hash 或已批准 snapshot，但仍不产生 Design Authority。候选迭代保持任务内；Skill 可以在方向最终确定后返回一份合并的 accepted/rejected/unresolved 差异供独立方案步骤处理，但不会修改初版方案、`project_context/**`、`DESIGN.md`、生产代码或 Delivery Contract。
 
 实际生成仍由已配置的 Open Design/Product Design、Figma、图片生成、原型工具或人工设计流程负责。这些输出以普通 external Source 进入默认 Workflow 或 Long-Task。candidate 与 inspiration 不授权 fidelity；selected exact target 只控制其声明的 surface/viewport/mode/state/content 条件，并且需要稳定不可变身份后才能成为影响验收的 `verification_input`。`context_uiux_design` 在下游执行 UI Authority Closure，只把耐久事实采纳到 Context/`DESIGN.md`；实现截图与 diff 仍是证据 artifact，不能自我授权为目标。
 

package/assets/agents/AGENTS_CORE.md

@@ -10,7 +10,7 @@ Unless an active Long-Task binding exists:
 
 1. Read `project_context/global.md`, `project_context/architecture.md`, `project_context/context.toml` and the default area root, then collect graph/trigger candidates.
 2. Before deciding `Context Delta`, run one bounded text search over `project_context/**` using a small set of high-signal task terms such as explicit area/module names and API/schema/state/security/verification/deployment terms. Merge matching Context with manifest candidates and read only relevant files; search supplements rather than replaces semantic judgment.
-3. For UI/product-surface work, confirm information/action/feedback ownership and use `context_surface_contract` when durable responsibility is unclear or changes; Product Surface Contracts own cross-surface interfaces and optional on-demand Screen Contracts use existing area/subdomain/contract/verification roles for deeper screen/control facts. Before material production UI implementation, reconcile each affected stable surface/control/target key as Context-covered, requiring a Context update, task-local, out of scope or decision-required, then read `DESIGN.md`, its token source and referenced design targets. An unconfigured starter, candidate, style-only guidance or inspiration does not authorize invented production layout; only a selected exact/constraint target with adequate declared coverage authorizes fidelity. For an explicit standalone request to generate or iterate design resources, `design-resource-authoring` may commission the smallest sufficient set from live Open Design capabilities without changing Context, code or Contract. Its output and other externally authored resources remain ordinary Source until this workflow uses `context_uiux_design` when needed to adopt or repair durable Design Authority. Local style fixes and explicit non-fidelity prototypes remain lightweight.
+3. For UI/product-surface work, confirm information/action/feedback ownership and use `context_surface_contract` when durable responsibility is unclear or changes; Product Surface Contracts own cross-surface interfaces and optional on-demand Screen Contracts use existing area/subdomain/contract/verification roles for deeper screen/control facts. Before material production UI implementation, reconcile each affected stable surface/control/target key as Context-covered, requiring a Context update, task-local, out of scope or decision-required, then read `DESIGN.md`, its token source and referenced design targets. An unconfigured starter, candidate, style-only guidance or inspiration does not authorize invented production layout; only a selected exact/constraint target with adequate declared coverage authorizes fidelity. For an explicit standalone request to generate or iterate design resources, `design-resource-authoring` keeps the requested output/development content as the hard ceiling and may commission the smallest sufficient set from live Open Design capabilities; an implementation handoff covers material in-scope UI/UX meaning through relevant controls without requiring one artifact per control or changing Context, code or Contract. Its output and other externally authored resources remain ordinary Source until this workflow uses `context_uiux_design` when needed to adopt or repair durable Design Authority. Local style fixes and explicit non-fidelity prototypes remain lightweight.
 4. Decide exactly one `Context Delta: none|required`. Update owning Context before code when durable product ownership, architecture, API/schema/data, state/recovery, dependency, security, product-surface responsibility or repeatable verification/deployment changes. Local fixes preserving durable semantics are `none`.
 5. Use the agent/platform internal plan. For high-risk work keep `Architecture Context Hit`, `Decision Rationale Hit: existing|required|none` and `Modularity Check: none|required|exception` as internal routing and maintenance questions, not artifacts or extra deltas.
 6. Implement precisely, run project-owned verification, perform Contract Conformance and a Context drift check, then report implementation, verification, Context status and blockers.

package/assets/skills/context_uiux_design/SKILL.md

@@ -23,7 +23,7 @@ Project-specific UI/UX and visual design rules belong in a separate project-loca
 
 ## External Design Resource Consumption / 外部设计资源消费
 
-- `design-resource-authoring` 可以按明确请求在上游动态委托 Open Design 产生 flow、低保真、候选方向、控件状态、交互原型或条件式 Figma handoff；它不复制 provider 的提示词/模板，也不把任何资源设为全局必选。
+- `design-resource-authoring` 可以按明确请求在上游动态委托 Open Design 产生 flow、低保真、候选方向、组件族/独特复杂控件状态、交互原型或条件式 Figma handoff；它以明确输出/开发内容为上限，在范围内补齐材料性 UI/UX 含义但不要求逐控件一份稿，不复制 provider 的提示词/模板，也不把任何资源设为全局必选。
 - 本 Skill 不承担独立资源生产。只有进入默认开发流程或 Long-Task、需要采纳稳定结论时，本 Skill 才消费这些或其他外部设计 Source。
 - 候选、灵感和未选定输出不是 Context readiness 或实现权威，不能写入 selected registry；选定目标仍必须完成 UI Authority Closure 和 `Context Delta`。
 - 消费时核对产品 Source、Screen/Control Context、`DESIGN.md`、token owner、资源稳定身份及 exact-target 覆盖条件；只把长期稳定且无冲突的事实写入其唯一 owner，不要求统一 pack、目录或工具格式。
@@ -106,7 +106,7 @@ Configured is system-level visual authority only, not surface implementation-rea
 - Read the owning surface/interaction Context, `DESIGN.md`, the authored exact-value token source and generation direction, existing production components/routes and every material design reference.
 - Classify each reference as `exact-target`, `constraint` or `inspiration`. Record the affected surface/route/component, project path or URI and relevant viewport/theme/mode/state. Exact targets authorize fidelity comparison only for those conditions; constraints authorize only their named rule; inspiration proves no reproduction claim.
 - Treat a missing `DESIGN.md`, its package starter with Design authority status: `unconfigured`, style-only prose, an inspiration-only set or conflicting references as insufficient authority for invented production layout.
-- If the user explicitly delegates standalone design-resource generation, use `design-resource-authoring` to commission the smallest sufficient set from available Product Design/Open Design capabilities. In this downstream Skill, adopt a selected target into durable Context/`DESIGN.md` only after UI Authority Closure. Ask only when an unknown material preference could change the result or the user reserves the choice.
+- If the user explicitly delegates standalone design-resource generation, use `design-resource-authoring` to keep the explicit output/development scope as the ceiling and commission the smallest sufficient set from available Product Design/Open Design capabilities. An implementation handoff covers material in-scope UI/UX meaning through relevant controls, may reuse component families or one inspectable artifact and does not require one file per control. In this downstream Skill, adopt a selected target into durable Context/`DESIGN.md` only after UI Authority Closure. Ask only when an unknown material preference could change the result or the user reserves the choice.
 - Never use the implementation's own generated screenshot or diff as the target it claims to match. A target is selected Source; an implementation render is evidence. Baseline replacement requires deliberate review and cannot merely erase a failure.
 - Do not require Figma, a fixed `docs/design/**` tree, an image for every local change or universal pixel-perfect thresholds. Use project-native design assets and the smallest authority sufficient for the claimed fidelity.
 

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

@@ -1,18 +1,21 @@
 ---
 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, 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 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 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.
-- Never let supplied background expand the user's explicit output scope. “One control,” “one page,” “these three pages” and “exploration only” are hard ceilings.
+- 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.
@@ -26,15 +29,15 @@ Commission the smallest sufficient set of design resources from the currently av
 
 ## 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.
+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.** 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.
+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. 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.
+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. 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.
+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
 
@@ -62,4 +65,4 @@ The Skill performs only the first four transitions and returns differences as ou
 
 ## 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 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

@@ -10,6 +10,16 @@ Generated resources remain ordinary external Source. This reference preserves en
 
 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
@@ -28,11 +38,13 @@ Do not require files, schemas, packs, hashes or validator runs for a throwaway u
 
 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.

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

@@ -4,22 +4,23 @@ 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.
@@ -36,9 +37,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
 
-Ask what remains uncertain inside the scope:
+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;
@@ -50,23 +82,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 +110,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,19 +138,19 @@ 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.
 
@@ -119,6 +158,9 @@ When a human explicitly selects or rejects a direction, return an accepted-desig
 
 - **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.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "project-tiny-context-harness",
-  "version": "0.7.6",
+  "version": "0.7.7",
   "description": "Minimal project memory and validation harness for AI coding agents.",
   "license": "MIT",
   "author": "Seven128",