project-tiny-context-harness 0.7.4 → 0.7.6

package/assets/skills/context_uiux_design/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: context_uiux_design
-description: Use when the user explicitly asks for 设计稿, 重做设计, UI/UX 设计方案, UI 设计师, UX 设计师, 视觉设计方案, 视觉专家, 交互设计方案, 界面设计方案, 页面设计方案, 原型设计, 线框图方案, 视觉规范, 设计系统方案, DESIGN.md, Impeccable review, UX designer, UI designer, frontend redesign, visual polish, or design system spec, or when material production UI lacks sufficient or consistent Design Authority in a Minimal Context Harness project. Do not trigger for routine implementation that already has sufficient design authority, local CSS tweaks, UI bug fixes, explicit throwaway prototypes, or generic mentions of 设计, design, or user experience.
+description: Use when the user explicitly asks to establish, adopt or repair durable UI/UX Design Authority, DESIGN.md, design-system governance, visual standards, stable interaction/surface Context, Impeccable review, visual polish, frontend redesign, or when material production UI lacks sufficient or consistent Design Authority in a Minimal Context Harness project. For standalone generation of low/high-fidelity wireframes, visual candidates, a design prototype or Figma handoff, use design-resource-authoring instead; do not trigger this Skill solely for resource generation, routine implementation with sufficient authority, local CSS fixes, UI bugs, explicit throwaway prototypes or generic mentions of design.
 ---
 
 # Context UIUX Design
@@ -13,19 +13,33 @@ Project-specific UI/UX and visual design rules belong in a separate project-loca
 
 ## 目标
 
-帮助 agent 把界面、交互和视觉设计结论沉淀成可恢复的 Minimal Context 和 `DESIGN.md`。
+帮助 agent 在开发工作流中审查、采纳或修复设计权威，把已经选定的界面、交互和视觉结论沉淀成可恢复的 Minimal Context 和 `DESIGN.md`，并保持实现与验证对齐。
+
+## Design Context Depth / 设计上下文深度
+
+按需使用而不是默认加载全部层级：全局体验原则；跨 surface 的 Product Surface Contract；单屏 Screen Contract；可复用的 Control interaction Context；`DESIGN.md` 视觉系统/引用解释；项目原生 authored targets；verification Context。继续使用现有 `global`、`contract`、area/subdomain、`decision-rationale`、`verification` 和 `implementation-index` 角色，不新增笼统 `design` 或 `screen` 角色。
+
+一项事实只有一个主要 owner：跨页面职责属于 Surface Context，稳定的单屏层级/交互属于 Screen/interaction Context，视觉 token/rationale/reference interpretation 属于 `DESIGN.md`，具体构图属于 selected target，交付范围与证明属于现有 Delivery Contract/verification。使用稳定 surface/control/target key 连接，不复制成彼此竞争的说明。
+
+## External Design Resource Consumption / 外部设计资源消费
+
+- `design-resource-authoring` 可以按明确请求在上游动态委托 Open Design 产生 flow、低保真、候选方向、控件状态、交互原型或条件式 Figma handoff；它不复制 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、目录或工具格式。
+- 设计资源生成本身不改 `project_context/**`、`DESIGN.md` 或 production code。下游采纳、实现与验证仍由当前 Workflow Contract 或 `long-task-workflow` 负责。
 
 ## 工作方式
 
 1. 先读取 `project_context/global.md` 和 `project_context/context.toml`，按 default area、triggers、read_when 选择相关 context。
-2. 如果项目存在 `DESIGN.md`，先读取其 Design Authority 状态、唯一 token 源/生成方向和设计引用；如果用户要求视觉体系、设计稿或界面风格，按 Google `@google/design.md` 的 DESIGN.md 格式创建或更新根目录 `DESIGN.md`。
-3. 整理或生成：用户流程、页面/组件清单、关键状态、交互反馈、响应式边界、a11y 要求、视觉约束、设计 token，以及需要长期复用的 design reference registry。
+2. 如果项目存在 `DESIGN.md`，先读取其 Design Authority 状态、唯一 token 源/生成方向和设计引用。仅当当前开发工作流经 UI Authority Closure 判断长期视觉体系需要采纳或修复时，按 Google `@google/design.md` 的格式创建或更新根目录 `DESIGN.md`；独立资源生成阶段不写入。
+3. 读取已有外部设计资源或其他 selected Source，整理需要采纳的用户流程、页面/组件清单、关键状态、交互反馈、响应式边界、a11y、视觉约束、token 和 design reference registry。若当前请求只是生成资源，转到 `design-resource-authoring`；不要在本 Skill 内复制 provider 生成流程或建立强制交付格式。
 4. 涉及 Product Surface（Web 页面、移动/桌面屏幕、游戏 UI/HUD/菜单、CLI/TUI 输出、扩展或设备界面）、前端布局、UI/UX、产品模块边界或信息放置时，把产品/页面定位检查作为前置动作：用户在这个 surface 要完成的判断、产品必须提供的信息/动作/反馈、不应常驻的信息、主层/下钻/运维/诊断/详情归属、布局和信息密度是否匹配任务。多 surface、多平台或多模块归属不清时，先读取相关 Context、搜索入口并结合已有 UI 代码/截图做信息架构 sweep，必要时使用 `context_surface_contract` 做 Surface Contract Check，再收窄到具体视觉或交互实现。该检查是下一步变更分类的输入；只有形成长期 surface 职责、信息架构、交互契约或模块边界结论时才更新 Context 或 `DESIGN.md`。
    - 若存在 Product Surface Contract，读取并对齐 primary user question、main allows/forbids、drilldown ownership、long-task state 和 verification。
-   - 若缺失且本任务改变 durable surface responsibility，输出 `Surface Contract Delta: required`，把界面职责写入 `project_context/**`；视觉 token、颜色、字体、间距、圆角和视觉 rationale 仍写入 `DESIGN.md`。
+   - 若缺失且本任务改变 durable surface responsibility，将唯一 `Context Delta` 设为 `required`，把界面职责写入 `project_context/**`；视觉 token、颜色、字体、间距、圆角和视觉 rationale 仍写入 `DESIGN.md`。
 5. 涉及输入、选择、搜索、筛选、表单/配置、调度/时间窗口、预算/配额/限流或加载/空态/错误态等 UI 控件时，用“控件交互框架”检查控件语义、反馈状态、校验、错误预防、可供性和信息密度；这只是通用判断框架，不是固定控件处方。
 6. 界面职责、流程归属和长期交互契约以 `project_context/**` 为准；`DESIGN.md` 负责视觉 token、视觉 rationale、唯一 authored token source/generation direction 和设计引用解释；versioned authored targets 保留在项目原生路径，代码与生成截图只说明当前实现状态。Context 决定“应该是什么”，代码和实现截图揭示“现在是什么”，代码不能静默重定义 Context。
-7. 设计判断或第一处实现编辑前，先给出唯一长期事实判断 `Context Delta: none|required`。若输入包含产品、架构、技术、界面或验收来源，在 agent 内部逐项判断 durable surface / IA / interaction / verification constraint 已被 Context / `DESIGN.md` 覆盖、需要先更新、仅属 task-local、显式 out-of-scope 或需要真实用户决策；不要创建 `plan.md`、Task Contract 文件或 Markdown 映射表。
+7. 设计判断或第一处实现编辑前，执行 UI Authority Closure，并给出唯一长期事实判断 `Context Delta: none|required`。对 affected stable surface/control/target keys，在 agent 内部逐项判断 durable surface / IA / interaction / verification constraint 已被 Context / `DESIGN.md` 覆盖、需要先更新、仅属 task-local、显式 out-of-scope 或需要真实用户决策；不要创建 `plan.md`、Task Contract 文件或 Markdown 映射表。冲突的 controlling owners 必须修正 Source/Context/target 或保留 decision required，不能让当前实现或 YAML 静默决定。
 8. 普通 UI bug、局部样式或 CSS 修复、测试修复或探索性 spike 不更新 Context，可先改代码；一旦形成长期交互或视觉结论，继续对齐或交付前必须回写 Context 或 `DESIGN.md`。不要把 Context 机械补成代码改动摘要。
 9. 如果二者冲突，显式标记为实现漂移、缺失工作或 Context 过期。
 10. 如果涉及已有 UI，优先结合代码入口、运行截图或用户提供的参考图来描述差异。
@@ -45,6 +59,7 @@ Project-specific UI/UX and visual design rules belong in a separate project-loca
 - `Context Delta` 只能是 `none` 或 `required`。`required` 先更新 owning Context 或 `DESIGN.md`；`none` 按现有事实工作，不制造 Context 噪音。
 - Agent 内部计划应保持页面 / 组件任务、用户判断、主辅信息归属、动作层级、输入语义、loading / empty / no-results / stale / error / degraded / success 状态、布局稳定性、非目标与验收入口清晰。
 - 触及 Product Surface 时，同时保持 surface platform、primary user question、main allows/forbids、drilldown ownership、long-task state requirement 和 verification 清晰；字段、枚举、JSON 和截图仅是实现证据。
+- 当 Product Surface 粒度不足以支持 material screen 时，使用 `screen-contract.md` 的按需结构保持 entry/exit/shared state、information hierarchy、regions、fixed/scroll/overlay ownership、navigation/variants 和 material controls 清晰；局部样式修复不补建 Screen Contract。
 - 外部来源的重要约束在内部分类为 Context / `DESIGN.md` 已覆盖、已更新、task-local、显式 out-of-scope 或需要用户决策；存在未处理项时不能声称全量完成。
 - 默认流程不要求或验证固定 `plan.md`、Task Contract 文件、Source-to-Context 表、Context-to-Implementation 表、matrix、verdict 或 evidence ledger；可选 scratch 没有固定名称或权威。
 - `Contract Conformance` 直接检查 controlling Context / `DESIGN.md` 是否到达正确 surface、状态、交互与验证路径并避开 forbidden shortcut。实现偏差修实现；缺少长期事实则返回 `Context Delta: required`，先更新长期事实再对齐。
@@ -86,16 +101,18 @@ Project-specific UI/UX and visual design rules belong in a separate project-loca
 
 Use this check before material production UI: a new or redesigned screen, primary layout/navigation/theme/component system, high-fidelity implementation or substantial visual polish. Routine implementation with sufficient authority, local style fixes and explicit throwaway prototypes stay on the lightweight path.
 
+Configured is system-level visual authority only, not surface implementation-ready status. `DESIGN.md` 被识别为 configured 只说明项目级视觉系统不是 starter，不表示任一页面已可高保真实现。affected surface 还必须拥有充分的 Screen/Control meaning、覆盖该 claim 的 selected target/constraints、唯一 token source 和项目可执行的验证路径；任何缺失都按 UI Authority Closure 路由，而不是伪造一个全局 readiness 状态。
+
 - Read the owning surface/interaction Context, `DESIGN.md`, the authored exact-value token source and generation direction, existing production components/routes and every material design reference.
 - 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 design, use known product goals, preferences and references to author/select a separate target before implementation and update durable Context/`DESIGN.md` when the choice is stable. 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 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.
 - 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.
 
 ## Visual Delivery Coverage / 视觉交付覆盖
 
-For material design-system, redesign, high-fidelity implementation or visual-polish work, keep a task-local **Visual Coverage Set** before implementation and verification. It is internal planning, not a required file, matrix, Context role, workflow artifact or completion authority.
+For material design-system, redesign, high-fidelity implementation or visual-polish work, keep a task-local **Visual Coverage Set** before implementation and verification. When external design Source declares coverage, reconcile it with current delivery scope rather than creating competing authority. The downstream working set remains internal planning, not a required file, matrix, Context role, workflow artifact or completion authority.
 
 - Select risk-proportional representative combinations across production surface/route/component, viewport, theme or product mode, interaction/state, content stress and accessibility/motion conditions. Do not expand the full Cartesian product unless Source explicitly requires full combination coverage, and never claim an unchecked combination.
 - Cover relevant states such as default, hover, focus, active, disabled, loading, empty/no-results, error, success and long/extreme content. Use the project's declared viewport, contrast, target-size, reduced-motion and localization rules rather than inventing universal thresholds.
@@ -108,9 +125,9 @@ For material design-system, redesign, high-fidelity implementation or visual-pol
 
 - 不默认创建 `.work_products/**`、UI/UX 独立文档、handoff matrix、review/test/release 文档。
 - 不要求 lifecycle phase、plan task、phase gate 或阶段 Skill。
-- 如果用户明确要求独立设计稿、mock 或页面说明，可以临时生成；长期事实仍要提炼回 `project_context/**` 和 `DESIGN.md`。
+- 如果用户明确要求独立设计稿、mock、线框图、原型或 Figma handoff，使用 `design-resource-authoring`；本 Skill 只在后续开发流程中采纳长期事实。
 - `DESIGN.md` 是视觉设计系统事实源；项目流程、模块契约和下一步动作仍以 `project_context/**` 为准。
-- 如果普通页面实现已经有充分 Design Authority，或用户只要求修复 UI bug、局部改 CSS、换颜色、明确的 throwaway prototype，或只是泛泛提到“设计 / design / user experience”，不需要触发本 Skill；明确角色/产物、视觉体系工作，或 material production UI 缺失/冲突的 Design Authority 才使用。
+- 如果普通页面实现已经有充分 Design Authority，或用户只要求修复 UI bug、局部改 CSS、换颜色、明确的 throwaway prototype，或只是泛泛提到“设计 / design / user experience”，不需要触发本 Skill；durable 视觉体系/Context 采纳，或 material production UI 缺失/冲突的 Design Authority 才使用。明确要求设计资源产物但尚未进入采纳/实现流程时使用 `design-resource-authoring`。
 
 ## DESIGN.md 使用规则
 

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

@@ -0,0 +1,65 @@
+---
+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.
+---
+
+# 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.
+
+## 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.
+
+## 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 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.
+
+## 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 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.

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

@@ -0,0 +1,126 @@
+# 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.
+
+## 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:
+
+- 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.
+
+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,124 @@
+# 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 boundary before interpreting the background:
+
+- subject: one control/component, one page, named pages, a flow or a reusable system;
+- 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.
+
+## 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 |
+| `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. Identify independent gaps
+
+Ask what remains uncertain inside the scope:
+
+- **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.
+
+## 5. 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 |
+| 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 |
+| 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.
+
+## 6. 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.
+
+## 7. 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
+  platform: known-or-unknown
+  viewports: []
+coverage:
+  required_content: []
+  required_states: []
+  required_transitions: []
+inputs:
+  exact_targets: []
+  constraints: []
+  inspiration: []
+  background: []
+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
+
+- 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.
+
+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.
+- **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/assets/skills/long-task-workflow/SKILL.md

@@ -44,11 +44,12 @@ A Draft Outcome is an Outcome in that pre-Authority-Lock Draft, not a new schema
 ## Entry And Authoring Loop
 
 1. Read the user request or external proposal plus minimum controlling Context and decide `Context Delta: none|required`.
-   - For material production UI, read the Contract-authoring visual guidance before Compile. An unconfigured starter, style-only rule or inspiration-only reference is incomplete design authority unless Source explicitly scopes the result as prototype/non-fidelity or delegates a separate selected target before implementation.
+   - For material production UI, read the Contract-authoring visual guidance before Compile. Inspect any external design resources as ordinary Source, including selection basis, stable identity and declared surface/viewport/mode/state coverage. An unconfigured starter, candidate, style-only rule or inspiration-only reference is incomplete design authority unless Source explicitly scopes the result as prototype/non-fidelity or supplies a selected target before implementation.
+   - If the user is asking to generate or iterate standalone design resources before Contract authoring rather than execute this delivery, use `design-resource-authoring` instead. Its result may later return as ordinary Source; it creates no Contract Draft or Authority.
 2. If a valid active binding exists, run `ty-context long-task resume <workdir>` and read the lifecycle reference.
 3. Otherwise author one complete Delivery Contract for the whole selected delivery. Declare the target profile, its non-empty required product target refs, each target's runtime family/root entrypoint, ordered Stages and vertical Outcomes. Do not create a second Contract plan, matrix or top-level Contract split.
 4. Preserve at least one real `source_path`. Wrap every material Source item in its original Markdown with non-rendering `ty-source-item:start/end` markers without rewriting the text; marked Source Item keys and `source_claim` keys are exactly equal.
-5. An ordinary prose plan or optional Source Plan remains valid Source after marker-only enumeration and does not need to match the recommended Source Plan structure. Preserve stable semantic keys and Markdown anchors where practical.
+5. An ordinary prose plan, optional Source Plan or externally authored design resource remains valid Source after marker-only enumeration and does not need to match a recommended authoring structure. Preserve stable semantic keys and Markdown anchors where practical. External design authoring neither updates Context nor creates Contract authority by itself; candidate resources authorize no fidelity Claim.
 6. Continue reading repository, Source and Context and revise the same Draft. A request to synthesize, refine, complete, implement or use judgment delegates plan-level authoring, but it does not invent the user's tradeoff priorities. Before comparative research or a material product, technical, architecture or provider selection, identify the criteria that could change the research scope, candidate set or recommendation. Infer them only from the user's words, Source, Context or controlling constraints. If quality versus cost, speed, reliability, privacy, lock-in, operational burden or another material priority is unknown or ambiguous, stop before that research or selection and ask one concise targeted clarification. Do not impose a questionnaire, re-ask known preferences or interrupt minor reversible choices whose recommendation would not change.
 7. Once the material preference envelope is clear, decide what research is needed. Use current authoritative or primary evidence for external capability, pricing, quota, license, compatibility, region, security posture or support claims. When one recommendation is then defensible, record it in real Source with the authoring instruction, preference/evidence basis and exact added meaning instead of pausing for approval. Append the delegated item without rewriting the user's original text when ordinary prose is the Source. Return only when authoritative requirements conflict, the user explicitly reserves the choice, a material preference remains unknown, critical semantics have no defensible recommendation or no falsifiable acceptance standard can be formed.
 8. Contract expansion remains limited to meaning-preserving structural decomposition, evidence-backed repository binding and choices first recorded as delegated real Source. Never place a new product rule, default, threshold, recovery behavior, permission or platform/data scope only in Contract YAML. Default plan delegation authorizes meaning, not action: payment, contracting, production deployment or publication, destructive production mutation, real permission grants, sensitive-data transmission and required legal/security/human approval remain named external confirmations. Any conflicting, user-reserved, missing-preference or unsupported semantic remains `decision_required`.

package/assets/skills/long-task-workflow/references/authority-lifecycle.md

@@ -30,6 +30,8 @@ Every path-bearing field uses canonical grammar. Internal `.`/`..`, control char
 
 Controlling Context includes core Context, explicit `context_refs`, verification/deployment Context and every file in full snapshot mode. In referenced mode only graph-derived, non-explicit `implementation-index` and `archive` files are Supporting Context; a supporting-only `compile --revise` may preserve otherwise-fresh targeted Progress.
 
+A selected design target, its exact/constraint interpretation, an authored token source or any applicable Control semantic is product/verification authority, not generated evidence. External design resources are ordinary Source: a candidate or unresolved selection cannot authorize fidelity work, while a selected exact target still requires downstream UI Authority Closure and Contract adoption. Adding or changing its selected resource, selection basis, immutable identity, condition coverage or acceptance-affecting token/prototype fixture after Authority Lock follows the existing protected revision path and returns to rolling implementation; a candidate/planned target, implementation screenshot or historical diff cannot authorize fidelity work or preserve affected Progress by itself.
+
 `context.toml` retrieval guidance (`triggers`, `read_when`, `read_policy`, default selection and unselected nodes) is excluded from the selected delivery-authority projection. Selected area ownership, role/dependency structure and selected Context contents remain protected revision material. Retrieval-only edits may preserve scoped Progress, but a changed final Git tree still invalidates historical final acceptance and must pass the Live Final Gate again.
 
 ## Targeted Verification And Recovery

package/assets/skills/long-task-workflow/references/contract-authoring.md

@@ -77,17 +77,21 @@ A proxy check, static repository shape, tracked status report, prior screenshot,
 
 When the selected delivery includes a new/redesigned screen, primary layout/navigation/theme/component system, high-fidelity implementation or other material production UI, resolve Design Authority before Compile and author the result through existing Contract semantics:
 
+- when external design resources are material Source, place stable authored files or an accompanying controlling brief/index in `source_paths`, enumerate material statements with ordinary Source markers and preserve stable surface/state/control/target keys where available. Treat candidates and unresolved decisions honestly; only a selected exact target with a valid selection basis, declared condition coverage and immutable identity can be proposed for fidelity authority, and downstream UI Authority Closure still owns adoption;
+- perform UI Authority Closure over stable surface/control/target keys: classify each material item as covered by owning Context/`DESIGN.md`, requiring an owner update, task-local Source, explicitly out of scope or genuinely `decision_required`. Product Surface Context owns cross-surface responsibility, Screen/interaction Context owns durable hierarchy/behavior, `DESIGN.md` owns visual-system/reference semantics and selected targets own concrete composition; Contract YAML must not duplicate or invent those owners;
 - inspect owning surface/interaction Context, `DESIGN.md`, its authored token source/generation direction and material design references. Classify every reference as `exact-target`, `constraint` or `inspiration`, with its surface/route/component, path/URI and covered viewport/theme/mode/state;
 - an unconfigured starter, style-only prose, inspiration-only set or conflicting target is not sufficient production authority. Resolve it by explicitly scoping Source to a prototype/non-fidelity result, recording an explicitly delegated and selected design target in real Source after material preferences are known, or keeping the unresolved/user-reserved direction `decision_required`;
 - never let implementation output authorize itself: a generated implementation screenshot/diff is an Artifact, not the target. An acceptance-affecting target or baseline must be selected Source/verifier input before fidelity implementation can be accepted;
 - derive a task-local, risk-proportional Visual Coverage Set from declared Source, `project_context/**` and `DESIGN.md`: production surface/route/component, viewport, theme or product mode, interaction/state, content stress and accessibility/motion conditions;
 - select representative combinations rather than silently creating a full Cartesian requirement; an omitted combination remains unproven, while Source that explicitly requires full coverage must retain that scope;
 - encode each independently falsifiable visual expectation as an atomic Requirement, applicable Control field or named AC Assertion. Name the surface, viewport, theme/state/content condition and observable result when they matter to the claim;
-- bind the declared result to the owning Context/`DESIGN.md`, one authored token source and generation direction, selected target/constraint inputs, production component/route carriers, path envelopes and project-owned target checks. Detached kits, mocks or marketing specimens may be references but not substitute implementation carriers;
+- preserve every applicable material Control field independently: `surface`, `region`, `location`, `control_type`, `label_content`, `user_task`, `visibility`, `availability`, `trigger`, `input`, `validation`, `default_value`, `interaction`, `navigation_result`, `loading_state`, `empty_state`, `success_state`, `failure_state`, `recovery`, `permission`, `feedback` and `accessibility`. Empty/non-applicable fields create no Claim; do not collapse decided fields into broad prose that loses Source-to-Control traceability;
+- bind the declared result to the owning Context/`DESIGN.md`, one authored token source and generation direction, selected target/constraint inputs, production component/route carriers, path envelopes and project-owned target checks. Freeze acceptance-affecting selected target files, token sources and fixed prototype fixtures in `verification_inputs`; bind production carriers through `input_paths`/Bindings and reserve `artifact_globs` for generated implementation renders, diffs and reports. Detached kits, mocks or marketing specimens may be references but not substitute implementation carriers;
 - use `ui_browser` only for declared browser ACs. A browser or Expo-Web proxy cannot prove a native/mobile/desktop target that can fail independently; use a project-owned current-execution target Check when existing proof surfaces can truthfully represent the claim, otherwise retain named human/device confirmation as an external confirmation rather than inventing machine proof;
 - keep subjective visual direction, taste or approval outside false machine proof. Resolve an undecided direction as `decision_required`; represent required human design or new-baseline approval as an explicit external confirmation.
+- for combined design-and-implementation delivery, ordinary design Outcomes/Stages may author candidates before selection, but candidate/planned artifacts cannot authorize fidelity Claims. Append the selected result to real marked Source and the owning registry/target input; after Authority Lock adopt it through the existing protected revision before downstream fidelity implementation. This creates no target-selection state, second Contract or second Gate.
 
-This guidance adds no visual Schema, Claim kind, risk level, lifecycle state, coverage artifact, required design directory or Gate. It only makes visual meaning explicit enough for existing Source, Requirement/Control/Assertion, proof-surface, verification-input and external-confirmation mechanisms to verify what was actually declared.
+External authored design resources remain ordinary upstream Source rather than a Contract Draft, verification result or alternate authority. This guidance adds no UI-specific Contract block, Claim kind, risk level, lifecycle state, required design package, design directory or Gate. The additive generic Control fields only preserve Source meaning through existing Source, Requirement/Control/Assertion, Stage, Binding, proof-surface, verification-input, revision and external-confirmation mechanisms.
 
 ## Compact Authoring