project-tiny-context-harness 0.7.4 → 0.7.6

package/README.md

@@ -79,13 +79,13 @@ npx --yes project-tiny-context-harness ty-context validate-context
 npx --yes project-tiny-context-harness ty-context doctor
 ```
 
-Default profiles are `core-portable` and `workflow-default`. Explicitly enable long-task support:
+Default profiles are `core-portable` and `workflow-default`; the base managed set includes `/design-resource-authoring`. Explicitly enable long-task support:
 
 ```powershell
 ty-context enable long-task
 ```
 
-This installs `/source-plan-authoring`, `/long-task-workflow` and the completion Hook. Disable only those package-owned surfaces with `ty-context disable long-task`.
+Enabling Long-Task additionally installs `/source-plan-authoring`, `/long-task-workflow` and the completion Hook. Disable only those Long-Task-owned surfaces with `ty-context disable long-task`; the base `/design-resource-authoring` remains. Tiny Context does not install Open Design or another design-generation runtime.
 
 ## Positioning
 
@@ -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.4.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.7.6.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -187,15 +187,33 @@ Newly generated Harness configs default to `strict_except_generated`. Generated/
 
 ### Product Surface Contract
 
-`context_surface_contract` compiles durable screen/page/CLI responsibility using the existing `contract`, area/subdomain and verification roles; `product-surface-contract.md` is the package template. Product Surface Contract authoring uses Source-to-Context judgment and Contract Conformance; it must not add a new product-surface Context role or claim product-quality proof.
+`context_surface_contract` compiles durable screen/page/CLI responsibility using existing `contract`, area/subdomain and verification roles. `product-surface-contract.md` owns cross-surface/main-versus-drilldown responsibility; optional on-demand `screen-contract.md` goes deeper for one screen's entry/exit/shared state, information hierarchy, semantic regions, navigation/variants, material controls and target/verification references. This workflow must not add a new Context role or claim product-quality proof, and local style fixes do not require a Screen Contract.
+
+For material UI, **UI Authority Closure** reconciles each stable surface/control/target key as covered by existing Context, requiring a Context update, task-local, explicitly out of scope or genuinely decision-required. Product Surface Context owns cross-surface responsibility, Screen/interaction Context owns durable hierarchy and behavior, `DESIGN.md` owns visual-system/reference semantics, authored targets own concrete declared composition and the Delivery Contract only binds/proves this delivery. Conflicts fail closed; current code, timestamps, YAML or implementation screenshots do not silently win.
 
 ### Visual Delivery Guidance
 
-The default Workflow performs a conditional Design Authority Check before material production UI. It reads the owning surface Context, `DESIGN.md`, one authored exact token source/generation direction and selected design references. Each reference is `exact-target`, `constraint` or `inspiration`; an unconfigured starter, style-only prose or inspiration does not authorize invented production layout. Explicit design work routes through `context_uiux_design`; ordinary implementation with sufficient authority, local style fixes and throwaway prototypes remain lightweight.
+The default Workflow performs UI Authority Closure and a conditional Design Authority Check before material production UI. It reads the owning Surface/Screen/Control Context, `DESIGN.md`, one authored exact token source/generation direction and selected design references. Each reference is `exact-target`, `constraint` or `inspiration`; an unconfigured starter, candidate, style-only prose or inspiration does not authorize invented production layout, and a configured project visual system does not claim every page is implementation-ready. Explicit standalone resource generation routes to `/design-resource-authoring`, which commissions external Open Design capabilities without adopting authority; downstream durable adoption/repair routes through `context_uiux_design`. Ordinary implementation with sufficient authority, local style fixes and throwaway prototypes remain lightweight.
 
 For material work, `context_uiux_design` keeps a task-local risk-proportional Visual Coverage Set; durable interaction facts remain in `project_context/**`, durable visual semantics and the design-reference registry remain in `DESIGN.md`, and versioned targets stay at project-native paths. `context_development_engineer` binds that intent to production routes and reports only combinations actually rendered and checked. An implementation screenshot cannot become its own target.
 
-An explicit Long-Task resolves missing/conflicting visual authority before Compile, then uses existing Requirement, Control, Assertion, proof-surface, verification-input and `external_confirmation` mechanisms. Browser visual ACs use `ui_browser`; a browser proxy cannot prove an independently failing native target, so native proof remains a project-owned current-execution Check when representable or an external confirmation. Frozen screenshot baselines are verifier inputs, generated screenshots/diffs are review artifacts, and subjective approval remains external. No visual Schema, risk level, lifecycle state, Gate, required design directory or universal pixel threshold is added.
+An explicit Long-Task resolves missing/conflicting UI authority before Compile, then preserves every applicable Control field through the existing projection: surface, region/location, type/label, user task, visibility/availability, trigger/input/validation/default, interaction/navigation, loading/empty/success/failure/recovery/permission/feedback and accessibility. Each non-empty field is an independent Source-backed Control Claim and protected product semantic; omitted fields create no Claim. Existing Requirement, Control, Assertion, Stage, Binding, proof-surface, verification-input, revision and `external_confirmation` mechanisms remain the only lifecycle.
+
+Combined design-and-implementation work may author candidates in ordinary Outcomes/Stages, but a candidate or planned target cannot authorize fidelity implementation. Selection must become real marked Source plus the owning registry/target input and, after Authority Lock, an adopted protected revision. Browser visual ACs use `ui_browser`; a browser proxy cannot prove an independently failing native target, so native proof remains a project-owned current-execution Check when representable or an external confirmation. Frozen screenshot baselines are verifier inputs, generated screenshots/diffs are review artifacts, and subjective approval remains external. No `uiux_delivery` block, visual Claim type, risk level, lifecycle state, Gate, required design directory or universal pixel threshold is added.
+
+`ty-context doctor` keeps its compatible `missing | unconfigured | configured` project-level status and adds advisory Design Authority Index, token-source and classified-reference signals. It explicitly does not infer surface implementation readiness; that requires the owning Screen/Control meaning, selected target/constraints and project-owned verification.
+
+### 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.
+
+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.
+
+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.
+
+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.
+
+Maintainers may set `TY_CONTEXT_OPEN_DESIGN_MCP_COMMAND` plus optional `TY_CONTEXT_OPEN_DESIGN_MCP_ARGS_JSON` and run `npm run smoke:open-design` for an opt-in, read-only discovery smoke. Normal tests use a local mock MCP and do not depend on Open Design or nondeterministic output.
 
 ### Optional Source Plan Authoring
 
@@ -320,7 +338,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.4.tgz`.
+The synchronized local preview tarball is named `project-tiny-context-harness-0.7.6.tgz`.
 
 ## Community And Further Reading
 

package/assets/README.md

@@ -77,7 +77,7 @@ It does not launch or switch models, spawn agents, create branches or worktrees,
 2. **Workflow Contract** — Context-first default engineering behavior using the platform's internal plan; no required plan artifact.
 3. **Long-Task Workflow** — explicit Single-Goal Rolling Delivery with `long-task-delivery-v2`, compiled Claim Coverage and a verifier-owned Live Final Gate.
 
-The opt-in long-task profile also provides `/source-plan-authoring`, an upstream Source-quality helper rather than another authority layer.
+The base managed set also provides `/design-resource-authoring`, an explicitly triggered thin commissioner for task-local Open Design resources rather than a generation engine or authority layer. The opt-in long-task profile additionally provides `/source-plan-authoring`, an upstream Source-quality helper.
 
 Default profiles are `core-portable` and `workflow-default`. Enable the opt-in profile with:
 
@@ -85,7 +85,7 @@ Default profiles are `core-portable` and `workflow-default`. Enable the opt-in p
 ty-context enable long-task
 ```
 
-This installs `/source-plan-authoring`, `/long-task-workflow` and the completion Hook. It does not install an agent runtime, model worker, scheduler, or Git orchestration assets.
+This additionally installs `/source-plan-authoring`, `/long-task-workflow` and the completion Hook. `/design-resource-authoring` is already in the base managed set. Tiny Context does not install Open Design, an agent runtime, model worker, scheduler, Git orchestration assets or another design-generation runtime.
 
 ## Try It In 60 Seconds
 
@@ -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.4.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.7.6.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -208,15 +208,33 @@ Newly generated Harness configs default to `strict_except_generated`. Generated/
 
 ### Product Surface Contract
 
-`context_surface_contract` compiles durable screen/page/CLI responsibility using the existing `contract`, area/subdomain and verification roles; `product-surface-contract.md` is the package template. Product Surface Contract authoring uses Source-to-Context judgment and Contract Conformance; it must not add a new product-surface Context role or claim product-quality proof.
+`context_surface_contract` compiles durable screen/page/CLI responsibility using existing `contract`, area/subdomain and verification roles. `product-surface-contract.md` owns cross-surface/main-versus-drilldown responsibility; optional on-demand `screen-contract.md` goes deeper for one screen's entry/exit/shared state, information hierarchy, semantic regions, navigation/variants, material controls and target/verification references. This workflow must not add a new Context role or claim product-quality proof, and local style fixes do not require a Screen Contract.
+
+For material UI, **UI Authority Closure** reconciles each stable surface/control/target key as covered by existing Context, requiring a Context update, task-local, explicitly out of scope or genuinely decision-required. Product Surface Context owns cross-surface responsibility, Screen/interaction Context owns durable hierarchy and behavior, `DESIGN.md` owns visual-system/reference semantics, authored targets own concrete declared composition and the Delivery Contract only binds/proves this delivery. Conflicts fail closed; current code, timestamps, YAML or implementation screenshots do not silently win.
 
 ### Visual Delivery Guidance
 
-The default Workflow now performs a conditional Design Authority Check before material production UI: new/redesigned screens, primary layout/navigation/theme/component-system work, high-fidelity implementation and substantial visual polish. It reads the owning surface Context, `DESIGN.md`, one authored exact token source/generation direction and selected design references. Each reference is `exact-target`, `constraint` or `inspiration`; an unconfigured starter, style-only prose or inspiration does not authorize invented production layout. Explicit design work routes through `context_uiux_design`; ordinary implementation with sufficient authority, local style fixes and throwaway prototypes remain lightweight.
+The default Workflow now performs UI Authority Closure and a conditional Design Authority Check before material production UI: new/redesigned screens, primary layout/navigation/theme/component-system work, high-fidelity implementation and substantial visual polish. It reads the owning Surface/Screen/Control Context, `DESIGN.md`, one authored exact token source/generation direction and selected design references. Each reference is `exact-target`, `constraint` or `inspiration`; an unconfigured starter, candidate, style-only prose or inspiration does not authorize invented production layout. A configured project visual system is not a claim that every page is implementation-ready. Explicit standalone resource generation routes to `/design-resource-authoring`, which commissions external Open Design capabilities without adopting authority; downstream durable adoption/repair routes through `context_uiux_design`. Ordinary implementation with sufficient authority, local style fixes and throwaway prototypes remain lightweight.
 
 For material work, `context_uiux_design` keeps a task-local risk-proportional Visual Coverage Set across production surfaces/components, viewports, themes/modes, states, content stress and accessibility/motion conditions. Durable surface/interaction facts remain in `project_context/**`; durable visual semantics and the design-reference registry remain in `DESIGN.md`; versioned targets stay at project-native paths. `context_development_engineer` binds that intent to production routes and reports only combinations actually rendered and checked. An implementation screenshot cannot become its own target.
 
-An explicit Long-Task resolves missing/conflicting visual authority before Compile, then uses existing Requirement, Control, Assertion, proof-surface, verification-input and `external_confirmation` mechanisms. Browser visual ACs use `ui_browser`; a browser proxy cannot prove a native target that can fail independently, so native target proof remains a project-owned current-execution Check when representable or an external confirmation. Frozen screenshot baselines are verifier inputs, generated screenshots/diffs are review artifacts, and subjective approval remains external. This adds no visual Schema, risk level, lifecycle state, Gate, required design directory or universal pixel threshold.
+An explicit Long-Task resolves missing/conflicting UI authority before Compile, then preserves every applicable Control field through the existing projection: surface, region/location, type/label, user task, visibility/availability, trigger/input/validation/default, interaction/navigation, loading/empty/success/failure/recovery/permission/feedback and accessibility. Each non-empty field is an independent Source-backed Control Claim and protected product semantic; omitted fields create no Claim. Existing Requirement, Control, Assertion, Stage, Binding, proof-surface, verification-input, revision and `external_confirmation` mechanisms remain the only lifecycle.
+
+Combined design-and-implementation work may author candidates in ordinary Outcomes/Stages, but a candidate or planned target cannot authorize fidelity implementation. The selection must become real marked Source plus the owning registry/target input and, after Authority Lock, an adopted protected revision. Browser visual ACs use `ui_browser`; a browser proxy cannot prove a native target that can fail independently, so native target proof remains a project-owned current-execution Check when representable or an external confirmation. Frozen screenshot baselines are verifier inputs, generated screenshots/diffs are review artifacts, and subjective approval remains external. This adds no `uiux_delivery` block, visual Claim type, risk level, lifecycle state, Gate, required design directory or universal pixel threshold.
+
+`ty-context doctor` keeps its compatible `missing | unconfigured | configured` project-level status and adds advisory Design Authority Index, token-source and classified-reference signals. It explicitly does not infer surface implementation readiness; that requires the owning Screen/Control meaning, selected target/constraints and project-owned verification.
+
+### 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.
+
+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.
+
+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.
+
+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.
+
+Maintainers may set `TY_CONTEXT_OPEN_DESIGN_MCP_COMMAND` plus optional `TY_CONTEXT_OPEN_DESIGN_MCP_ARGS_JSON` and run `npm run smoke:open-design` for an opt-in, read-only discovery smoke. Normal tests use a local mock MCP and never require Open Design, login, paid access or nondeterministic design output.
 
 ### Optional Source Plan Authoring
 
@@ -498,7 +516,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.4.tgz` under the preview output directory.
+`npm run preview:pack` produces a local preview named `project-tiny-context-harness-0.7.6.tgz` under the preview output directory.
 
 ## Community And Further Reading
 

package/assets/README.zh-CN.md

@@ -38,13 +38,13 @@ npx --yes project-tiny-context-harness ty-context sync
 
 `upgrade` 先执行安全迁移再同步；资产刷新不会推断或覆盖用户编写的 Context、Source、Delivery Contract 或历史文件。
 
-默认 Profile 是 `core-portable` 与 `workflow-default`。显式启用长程能力：
+默认 Profile 是 `core-portable` 与 `workflow-default`，基础 managed set 已包含 `/design-resource-authoring`。显式启用长程能力：
 
 ```powershell
 ty-context enable long-task
 ```
 
-它会安装 `/source-plan-authoring`、`/long-task-workflow` 与完成 Hook，不安装模型 Worker、Agent runtime、调度器或 Git 编排资产。
+启用长程能力会额外安装 `/source-plan-authoring`、`/long-task-workflow` 与完成 Hook；`ty-context disable long-task` 只移除这些 Long-Task-owned surfaces，并保留基础 `/design-resource-authoring`。Tiny Context 不安装 Open Design、模型 Worker、Agent runtime、调度器、Git 编排资产或其他设计生成 runtime。
 
 ## Minimal Context 与默认工作流
 
@@ -103,13 +103,35 @@ Context: no durable fact change
 
 Harness 只路由仓库原生 lint/AST/dependency/contract check，不实现跨语言通用架构分析器。`check-modularity` 的语句数/分支风险会定位到最高风险函数和行号。
 
+### Product Surface 与 Screen Contract
+
+`context_surface_contract` 继续使用现有 `contract`、area/subdomain 和 verification 角色。`product-surface-contract.md` 负责跨页面、主层/下钻与共享职责；可选且按需读取的 `screen-contract.md` 负责单屏 entry/exit/shared state、信息层级、语义区域、导航/变体、material controls 和 target/verification 引用。它们不新增 `design`、`screen` 或 product-surface Context role，局部样式修复也不要求补建 Screen Contract。
+
+material UI 在实现前执行 **UI Authority Closure**：每个稳定 surface/control/target key 必须归类为现有 Context 已覆盖、需要 Context 更新、task-local、显式 out-of-scope 或真正 decision-required。Surface Context 负责跨页面职责，Screen/interaction Context 负责稳定层级和行为，`DESIGN.md` 负责视觉系统与引用解释，authored target 负责具体构图，Delivery Contract 只绑定并证明本次交付。出现冲突时 fail closed；当前代码、时间戳、YAML 或实现截图不能静默胜出。
+
 ### 视觉交付指导
 
-默认 Workflow 现在会在 material production UI 前执行条件式 Design Authority Check，包括新建/重做页面、主要布局/导航/主题/组件体系、高保真实现和大幅 visual polish。它读取 owning surface Context、`DESIGN.md`、唯一 authored token source/generation direction 和选定设计引用。引用分为 `exact-target`、`constraint`、`inspiration`；未配置 starter、只有风格文字或灵感图都不能授权 agent 自行发明生产布局。明确的设计任务路由到 `context_uiux_design`；已有充分权威的普通实现、局部样式修复和 throwaway prototype 仍保持轻量。
+默认 Workflow 现在会在 material production UI 前执行 UI Authority Closure 和条件式 Design Authority Check，包括新建/重做页面、主要布局/导航/主题/组件体系、高保真实现和大幅 visual polish。它读取 owning Surface/Screen/Control Context、`DESIGN.md`、唯一 authored token source/generation direction 和选定设计引用。引用分为 `exact-target`、`constraint`、`inspiration`；未配置 starter、候选稿、只有风格文字或灵感图都不能授权 agent 自行发明生产布局；全局视觉系统 configured 也不等于每个页面 implementation-ready。明确的独立设计资源生成请求路由到 `/design-resource-authoring`，由它委托外部 Open Design 能力但不采纳权威；进入开发流程后的耐久权威采纳/修复路由到 `context_uiux_design`。已有充分权威的普通实现、局部样式修复和 throwaway prototype 仍保持轻量。
 
 对 material 工作，`context_uiux_design` 在任务内部维护风险比例化的 Visual Coverage Set；耐久 surface/interaction 事实属于 `project_context/**`，耐久视觉语义和设计引用 registry 属于 `DESIGN.md`，versioned target 保留在项目原生路径。`context_development_engineer` 把这些意图绑定到生产组件/真实 route，只报告真正渲染和检查过的组合；实现截图不能成为它自己的目标。
 
-显式 Long-Task 会在 Compile 前解决缺失/冲突的视觉权威，再复用现有 Requirement、Control、Assertion、proof surface、verification input 与 `external_confirmation`。浏览器视觉 AC 使用 `ui_browser`；浏览器代理不能证明可独立失败的原生目标，因此原生 proof 只能使用项目自己的 current-execution target Check，无法真实表达时保留为外部确认。冻结截图 baseline 是 verifier input，生成截图/diff 是 review artifact，主观批准保持外部。这不新增视觉 Schema、risk level、lifecycle state、Gate、必需设计目录或通用像素阈值。
+显式 Long-Task 会在 Compile 前解决缺失/冲突的 UI 权威，并把每个 applicable Control 的 surface、region/location、type/label、user task、visibility/availability、trigger/input/validation/default、interaction/navigation、loading/empty/success/failure/recovery/permission/feedback/accessibility 完整投影为独立 Source-backed Control Claim 和受保护产品语义；空字段不生成 Claim。仍只复用现有 Requirement、Control、Assertion、Stage、Binding、proof surface、verification input、revision 与 `external_confirmation`。
+
+combined design-and-implementation 可以先用普通 Outcome/Stage 生成候选，但 candidate/planned target 不能解锁 fidelity implementation；选定结果必须先进入真实 marked Source 与 owning registry/target，并在 Authority Lock 后通过现有 protected revision 采用。浏览器视觉 AC 使用 `ui_browser`；浏览器代理不能证明可独立失败的原生目标，因此原生 proof 只能使用项目自己的 current-execution target Check，无法真实表达时保留为外部确认。冻结截图 baseline 是 verifier input，生成截图/diff 是 review artifact，主观批准保持外部。这不新增 `uiux_delivery`、视觉 Claim type、risk level、lifecycle state、Gate、必需设计目录或通用像素阈值。
+
+`ty-context doctor` 保留兼容的项目级 `missing | unconfigured | configured` 状态，并增加 Design Authority Index、token source 和已分类 reference 的 advisory 信号。它明确不推断页面实现就绪；material surface 仍需 owning Screen/Control meaning、selected target/constraints 与项目自己的验证路径。
+
+### 可选 Design Resource Authoring
+
+只有在用户明确要求生成、迭代、准备独立设计资源或使用 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。
+
+探索模式只做最小完整性检查并尽快展示指定候选；handoff 增加 project/run/capability provenance、明确 entry、声明覆盖与已知限制；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，不能自我授权为目标。
+
+维护者可以设置 `TY_CONTEXT_OPEN_DESIGN_MCP_COMMAND` 与可选 `TY_CONTEXT_OPEN_DESIGN_MCP_ARGS_JSON`，运行 `npm run smoke:open-design` 做显式启用、只读的 discovery smoke。正常测试使用本地 mock MCP，不依赖 Open Design、登录、付费能力或不确定的设计输出。
 
 ### 可选 Source Plan Authoring
 

package/assets/agents/AGENTS_CORE.md

@@ -10,13 +10,15 @@ 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; the contract owns interfaces and existing area/subdomain/verification roles own the project facts. Before material production UI implementation, also read `DESIGN.md`, its token source and referenced design targets: an unconfigured starter, style-only guidance or inspiration does not authorize invented production layout; use a declared exact/constraint target, route explicit design work through `context_uiux_design`, or stop for a genuine design decision. Local style fixes and explicit 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` 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.
 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.
 
 The default workflow never requires a plan artifact, matrix, verdict, evidence ledger or result document. Optional scratch is not Context or completion proof. The bounded Context search creates no index, cache, state or second authority.
 
+Externally authored design resources such as Figma frames, images, prototypes, token exports and component specifications are ordinary Source. Their authoring does not update `project_context/**` or `DESIGN.md`, edit production implementation, create a Delivery Contract or claim acceptance. The consuming workflow owns UI Authority Closure, `Context Delta`, durable adoption, implementation and project verification; candidates authorize no fidelity, while selected targets control only their declared surface/viewport/mode/state coverage.
+
 For external product, architecture, technical or acceptance sources, internally classify every material constraint as covered by Context, requiring a Context update, task-local, explicitly out of scope or requiring a genuine user decision. Conformance must confirm controlling Context reached the correct modules, surfaces, APIs, state machines and verification paths without forbidden shortcuts or duplicate authority.
 
 ## Long-Task Routing
@@ -27,7 +29,7 @@ Do not infer long-task mode from duration, complexity, file count or agent prefe
 2. Explicit `/long-task-workflow` authors or resumes exactly one complete `long-task-delivery-v2` Contract for the selected delivery.
 3. `/normal-long-task` is a retirement pointer. Otherwise remain on the default Workflow Contract, even when work is long.
 
-Contract Draft authoring belongs inside `long-task-workflow`: continuously revise the same non-authoritative `delivery-contract.yaml` until the first successful formal Compile creates Authority Lock. An optional Source Plan is ordinary upstream Source guidance, not a Contract Draft or required input protocol.
+Contract Draft authoring belongs inside `long-task-workflow`: continuously revise the same non-authoritative `delivery-contract.yaml` until the first successful formal Compile creates Authority Lock. An optional Source Plan and externally authored design resources are ordinary upstream Source guidance, not a Contract Draft or required input protocol. Candidate design resources authorize no fidelity Claim; selected targets and acceptance-affecting resources enter real marked Source and existing verification inputs, and after Authority Lock use protected revision.
 
 The workflow uses one native Goal, one selected workspace, one Contract and one Final Gate. New authoring uses inline vertical Outcomes grouped by ordered Stages; existing `outcome_files` are physical compatibility only. Target profiles name required product targets and root runtimes; Checks declare Given/When journeys and all-of Evidence Capabilities. Stage/frontier state is derived from ordinary Progress and creates no second Gate, Receipt, scheduler or completion authority.
 
@@ -42,7 +44,7 @@ Tiny Context does not create or restore platform Goals, invoke models, spawn age
 ## Durable Facts And Generated Surfaces
 
 - Context is intended ownership/boundary/contract truth; code is current implementation truth. Treat disagreement as drift, missing work or stale Context.
-- Long-term facts live only in `project_context/**` or `DESIGN.md`; versioned authored design targets may remain referenced project Source/verifier inputs, while generated screenshots/diffs, logs, raw evidence, secrets, runtime state and receipts do not become Context.
+- Long-term facts live only in `project_context/**` or `DESIGN.md`; versioned authored design targets remain upstream project Source/verifier inputs until the consuming workflow adopts durable meaning, while generated implementation screenshots/diffs, logs, raw evidence, secrets, runtime state and receipts do not become Context.
 - Managed `AGENTS.md` blocks, `<harnessRoot>/ty-context-managed/**` and package-managed Skills are generated and sync-overwritten.
 - Explicit upgrades use `context_harness_upgrade`; package sync never imports retired Campaign or development-period authority state.
 

package/assets/context_templates/product-surface-contract.md

@@ -28,6 +28,12 @@ Write only project-specific facts that should guide future implementation. Do no
 
 - `<durable project-specific rule>`
 
+## Screen Contract Routing
+
+Keep this file at cross-surface responsibility depth. When one material screen needs durable entry/exit/shared-state, information hierarchy, semantic region order, fixed/scroll/overlay ownership, navigation, variants, material controls or design-target references, create an on-demand Screen Contract from `screen-contract.md` using an existing area/subdomain role (or `contract` only for a true cross-area interface).
+
+Link by stable surface/control/target keys. Do not duplicate the Screen Contract here, copy exact visual tokens from `DESIGN.md`, or embed authored target binaries and test evidence.
+
 ## Registration Example
 
 Use the existing `contract` role for cross-surface or cross-area contracts:
@@ -52,6 +58,7 @@ Update this Context when:
 - A durable main/drilldown/diagnostic ownership rationale, rejected alternative or tradeoff will guide future changes.
 - A repeated UI/product rule becomes reusable.
 - A platform-specific interaction rule becomes stable.
+- Cross-surface ownership changes which Screen Contract owns a detail.
 
 Do not update this Context for:
 

package/assets/context_templates/screen-contract.md

@@ -0,0 +1,180 @@
+# Screen Contract
+
+## Purpose
+
+This optional on-demand Context records durable responsibility, information hierarchy and interaction semantics for one user-facing screen/surface when a Product Surface Contract is too coarse for future implementation and verification.
+
+A screen may be a Web route, mobile screen, desktop window, game HUD/menu scene, CLI/TUI view, extension panel, kiosk or embedded-device interface. Use only the relevant sections. Do not create a Screen Contract for a semantics-preserving CSS/style fix, one-off UI bug or explicit throwaway prototype.
+
+Write project-specific facts only. Do not copy visual token values, binary targets, implementation screenshots, test logs, raw payloads, implementation summaries or secrets into this file.
+
+## Authority Boundary
+
+- Product Surface Contract owns cross-surface responsibility, main/drilldown placement and shared invariants.
+- This Screen Contract owns stable screen hierarchy, regions, state/navigation behavior and durable material-control semantics.
+- `DESIGN.md` owns visual-system semantics, the authored token source/generation direction and durable target interpretations.
+- Versioned authored design targets own their declared concrete composition for named viewport/mode/state/content conditions.
+- Verification Context owns repeatable proof paths. Code is current implementation evidence, not silent design authority.
+
+If these owners conflict, update the stale owner or retain a genuine decision. Do not resolve a conflict from file order, current code shape or an implementation-generated screenshot.
+
+## Screen Identity
+
+- Surface Key:
+- Surface / Route / Command:
+- Platform:
+- Owning Product Domain:
+- Primary User Question:
+- In-Scope User Tasks:
+- Explicit Non-Goals:
+
+## Entry, Exit And Shared State
+
+- Entry Context / Preconditions:
+- Entry Points / Deep Links:
+- Inherited Shared State:
+- Locally Editable State:
+- Committed State Changes:
+- Exit Outcomes / Destinations:
+- Back / Cancel / Interruption Behavior:
+- Focus / Selection Restoration:
+
+## Information Hierarchy
+
+Record semantic order and responsibility, not pixel coordinates.
+
+1. Primary judgment:
+2. Primary action:
+3. Supporting information:
+4. Secondary actions:
+5. Drilldown / evidence / diagnostics:
+6. Information forbidden from permanent main-surface placement:
+
+## Layout Contract
+
+### Regions
+
+| Region Key | Order | Responsibility | Fixed / Scroll / Overlay | Visibility Conditions |
+|---|---:|---|---|---|
+| `<region-key>` | 1 |  |  |  |
+
+### Spatial And Container Ownership
+
+- Safe-area / system-chrome ownership:
+- Fixed or sticky elements:
+- Scroll owner and restoration:
+- Overlay / modal / sheet owner:
+- Map / canvas / media visible-area contract:
+- Keyboard / input-method behavior:
+- Gesture competition / pointer ownership:
+
+## Control Inventory
+
+Each material control has a stable semantic key. Fill only applicable fields; do not add generic filler for non-applicable states.
+
+### `<control-key>`
+
+- Surface:
+- Region:
+- Location:
+- Control Type:
+- Label / Content:
+- User Task:
+- Visibility:
+- Availability:
+- Trigger:
+- Input:
+- Validation:
+- Default Value / Restored State:
+- Interaction / Commit / Cancel:
+- Navigation / Result:
+- Loading State:
+- Empty / No-Result State:
+- Success State:
+- Failure / Degraded State:
+- Recovery / Retry / Interruption:
+- Permission / Denial Path:
+- Feedback:
+- Accessibility / Keyboard / Focus / Motion Alternative:
+
+## Screen State Variants
+
+Describe composition or responsibility changes, not one-off screenshots.
+
+- Initial / loading:
+- Empty / no results:
+- Partial / stale / degraded:
+- Error / unavailable:
+- Permission denied:
+- Disabled / saving / mutating:
+- Success / confirmation:
+- Offline / recovery when applicable:
+
+## Responsive, Mode And Content Variants
+
+- Viewport / size-class boundaries:
+- Orientation / window-resize behavior:
+- Theme / product-mode differences:
+- Text scaling / localization / long-content behavior:
+- Reduced motion / contrast / input-mode differences:
+- Other explicitly unsupported combinations:
+
+## Navigation And Interaction Contract
+
+- Forward navigation and committed state:
+- Back / system-back / predictive-back behavior:
+- Deep-link behavior:
+- Modal / sheet / popover lifecycle:
+- Gesture ownership and accessible alternative:
+- Cancellation, interruption and recovery:
+- Cross-surface state/version consistency:
+
+## Design Target References
+
+Reference project-native targets; do not embed binary content.
+
+| Target ID | Interpretation | Path / Immutable URI | Viewport / Platform | Theme / Mode | State / Content Coverage | Selection Basis |
+|---|---|---|---|---|---|---|
+| `<stable-target-id>` | `exact-target` / `constraint` / `inspiration` |  |  |  |  |  |
+
+An `exact-target` authorizes fidelity comparison only for its declared conditions. A `constraint` governs only its named rule. `inspiration` does not authorize reproduction. An implementation screenshot cannot register itself as its own target.
+
+## Verification
+
+- Semantic / information-hierarchy check:
+- Control behavior / state check:
+- Visual target / layout check:
+- Accessibility / focus / motion check:
+- Cross-surface shared-state check:
+- Target-runtime / native-device check:
+- Human or external confirmation boundary:
+- Known unproved combinations:
+
+## Stable Design Rationale
+
+- Decision:
+- Reason:
+- Rejected alternative when still decision-relevant:
+- Tradeoff that must guide future changes:
+
+Do not invent rationale from current implementation shape. Record a rejected alternative or tradeoff only when it is durable enough to constrain future screen decisions.
+
+## Registration Example
+
+Use an existing role. A screen owned by one domain normally uses `subdomain` (or the owning `area` file when small); use `contract` only when the screen itself is a cross-area interface.
+
+```toml
+[[context]]
+path = "project_context/areas/<area>/screens/<screen>.md"
+role = "subdomain"
+triggers = ["<surface-key>", "<route>", "<screen name>", "<material control key>"]
+read_policy = "on-demand"
+```
+
+Do not introduce `screen`, `design`, `surface-contract` or another custom role.
+
+## Maintenance Rules
+
+Update this Context when durable screen responsibility, hierarchy, region ownership, navigation/shared-state behavior, responsive/mode semantics or reusable material-control behavior changes.
+
+Do not update it for CSS-only fixes, one-off screenshot findings, generated diffs, temporary audit notes, test logs, command output, implementation summaries, PR notes or rationale inferred only from current code.

package/assets/skills/context_development_engineer/SKILL.md

@@ -66,6 +66,7 @@ sample provider / interface / page 证据不能替代 all-provider / all-interfa
 涉及 Web/移动/桌面/游戏 UI、CLI/TUI、表单、配置、输入、选择、搜索、筛选、调度、预算/配额/限流或状态反馈时：
 
 - 对照已有 Product Surface / Surface Contract、页面职责和控件任务，而不是只确认字段已暴露；
+- 对 material screen 同时读取 owning Screen/interaction Context（若存在），并用稳定 surface/control/target key 绑定真实 route/component、设计 target 和测试；产品方案只有粗粒度时，把缺失字段路由到 Context update、task-local Source 或 genuine decision，不能在代码里形成唯一隐藏事实源；
 - 内部保持 Surface Contract Hit、main allows/forbids、drilldown ownership、long-task state requirement、implementation drift 和 verification；
 - 缺失 durable surface responsibility 时设置 `Context Delta: required`，先用 `context_surface_contract` 或 owning Context 建立职责；
 - 收尾用简短 `Contract Conformance` 说明命中的 Context、实现满足方式、未满足项和验证入口。
@@ -81,9 +82,10 @@ For material production UI, first confirm Design Authority readiness; then carry
 - preserve approved semantic tokens and component APIs; do not bypass them with undeclared raw color, spacing, typography or motion values merely to match one screenshot;
 - implement the declared Visual Coverage Set across the applicable viewport, theme/mode, state, content-stress and accessibility/motion combinations, while avoiding an unrequested full Cartesian expansion;
 - run project-owned rendered/component/browser verification and report only the combinations actually checked. Static analysis, generated kits and screenshot artifacts are supporting review material rather than proof of every visual or behavioral claim.
+- For each applicable material control, preserve region/location, type/label, user task, visibility/availability, trigger/input/validation/default, interaction/navigation, loading/empty/success/failure/recovery/permission/feedback and accessibility semantics. An omitted field is not permission to invent durable product behavior; resolve it through UI Authority Closure.
 - never promote the implementation's own generated screenshot/diff into its target; exact targets and acceptance-affecting baselines are selected Source/verifier inputs before comparison.
 
-If an active Long-Task applies, express material visual expectations through its existing Requirement, Control, Assertion, Check and external-confirmation mechanisms. Do not introduce a second visual plan, acceptance document or lifecycle.
+If an active Long-Task applies, express material visual expectations through its existing Requirement, full Control projection, Assertion, Check, Stage, Binding and external-confirmation mechanisms. A design candidate or planned target cannot unlock fidelity implementation: selection must become real Source/registry authority and an adopted protected revision first. Do not introduce a second visual plan, acceptance document or lifecycle.
 
 ## Modularity Check
 

package/assets/skills/context_product_plan/SKILL.md

@@ -21,7 +21,8 @@ Project-specific product planning rules belong in a separate project-local Skill
 2. 和用户澄清或整理：目标用户、产品/页面定位、核心问题、用户需要什么、产品需要提供的内容/能力/反馈、主要流程、验收信号、非目标、约束、风险和受影响模块。
 3. 涉及 Product Surface（Web 页面、移动/桌面屏幕、游戏 UI/HUD/菜单、CLI/TUI 输出、扩展或设备界面）、前端布局、UI/UX、产品模块边界或信息放置时，把产品/页面定位检查作为前置动作：用户在这个 surface 要完成的判断、产品必须提供的信息/动作/反馈、不应常驻的信息、主层/下钻/运维/诊断/详情归属、布局和信息密度是否匹配任务。多 surface、多平台或多模块归属不清时，先读取相关 Context 并搜索入口，必要时使用 `context_surface_contract` 做 Surface Contract Audit，再收窄到具体实现。该检查是下一步变更分类的输入；只有形成长期产品归属、surface 职责、信息架构或模块边界结论时才更新 Context。
    - 若存在 Product Surface Contract，读取并对齐 primary user question、main allows/forbids、drilldown ownership、long-task state 和 verification。
-   - 若缺失且本任务改变 durable surface responsibility，输出 `Surface Contract Delta: required`，把具体答案写入 `project_context/**`，跨 surface 或跨 area 使用现有 `contract` role，不新增 surface-specific role。
+   - 若产品方案只到 surface/流程粒度而 material screen 的实现、验收需要更深事实，不要宣称已有控件级权威。使用稳定 surface/control key 将缺口分类为已有 Screen/interaction Context 覆盖、需要 Context 更新、task-local、out-of-scope 或 decision required；按需从 `screen-contract.md` 提炼 durable hierarchy/regions/navigation/variants/control semantics，视觉系统和 target 仍由 `DESIGN.md`/authored target 所有。
+   - 若缺失且本任务改变 durable surface responsibility，将唯一 `Context Delta` 设为 `required`，把具体答案写入 `project_context/**`，跨 surface 或跨 area 使用现有 `contract` role，不新增 surface-specific role。
 4. 涉及输入、选择、搜索、筛选、表单/配置、调度/时间窗口、预算/配额/限流或加载/空态/错误态等 UI 控件时，用“控件任务框架”重新理解用户任务和产品反馈；这只是通用判断框架，不是业务处方库。
 5. 当一个产品对象、能力或接口的增删改需要跨多个页面、模块、Context 或产品域同步调整时，将该影响范围视为产品边界复核信号；先判断它是否应沉淀为独立能力、subdomain 或 area，并明确对外契约、所有权和消费方边界，避免通过手工清单长期维护各消费面的重复映射。
 6. 产品意图、模块职责、边界和验收口径以 `project_context/**` 为准；代码和搜索结果只说明当前实现状态。Context 决定“应该是什么”，代码揭示“现在是什么”，代码不能静默重定义 Context。
@@ -42,7 +43,7 @@ Project-specific product planning rules belong in a separate project-local Skill
 ## 内部执行约束与 Conformance
 
 - `Context Delta` 只能是 `none` 或 `required`。`required` 先把足以指导实现的长期事实写入 owning Context；`none` 直接按现有 Context 工作，不制造 Context 噪音。
-- Agent 内部计划应保持目标、用户任务、信息 / 动作 / 状态 / 反馈、边界、非目标、验收信号和验证入口清晰。触及 Product Surface 时，同时保持 surface platform、primary user question、main allows/forbids、drilldown ownership 和 long-task state requirement 清晰。
+- Agent 内部计划应保持目标、用户任务、信息 / 动作 / 状态 / 反馈、边界、非目标、验收信号和验证入口清晰。触及 Product Surface 时，同时保持 surface platform、primary user question、main allows/forbids、drilldown ownership 和 long-task state requirement 清晰；material controls 还应覆盖 applicable 的 region/location、type/label、task、visibility/availability、trigger/input/validation/default、interaction/navigation、states/recovery/permission/feedback/accessibility，而不是由开发时临时猜测。
 - 外部来源的每项重要约束都在内部分类为 Context 已覆盖、Context 已更新、task-local、显式 out-of-scope 或需要用户决策；存在未处理项时不能声称全量完成。
 - 默认流程不要求或验证固定 `plan.md`、Task Contract 文件、Source-to-Context 表、Context-to-Implementation 表、matrix、verdict 或 evidence ledger；可选 scratch 没有固定名称或权威。
 - `Contract Conformance` 直接检查 controlling Context 是否到达正确产品域、surface、API、状态与验证路径并避开 forbidden shortcut。实现偏差修实现；缺少长期事实则返回 `Context Delta: required`，先更新 Context 再重新对齐。

package/assets/skills/context_surface_contract/SKILL.md

@@ -17,6 +17,8 @@ Help agents turn broad product/UI principles into concrete, project-owned Produc
 
 A Product Surface is any user-facing interface where users make judgments, take actions and receive feedback. Covered platforms include Web apps, dashboards, admin or operations UI, mobile screens, desktop windows, game UI/HUD/menu scenes, CLI/TUI output, browser extension or plugin UI, and embedded, kiosk or device UI.
 
+Use two depths without creating new roles: Product Surface Contract for cross-surface/main-versus-drilldown ownership, and an optional on-demand Screen Contract when one screen needs stable entry/exit/shared-state, information hierarchy, layout regions, navigation, variants or material-control semantics. Start from managed `product-surface-contract.md` or `screen-contract.md`; do not require both for every task.
+
 ## Context Roles
 
 Do not add a new `context_role`.
@@ -33,6 +35,8 @@ Forbidden roles include `surface-contract`, `product-surface`, `web-contract`, `
 
 Use `DESIGN.md` only for visual identity, visual tokens and visual rationale. Do not put surface responsibility, main/drilldown ownership or diagnostic placement into `DESIGN.md`.
 
+Keep one meaning owner: Surface Context owns cross-surface responsibility, Screen/interaction Context owns durable screen/control behavior, `DESIGN.md` owns visual-system semantics and target interpretations, authored targets own concrete declared composition, and verification Context owns repeatable proof paths. Link them with stable surface/control/target keys instead of copying facts.
+
 ## Mode Selection
 
 Use the narrowest mode that matches the request:
@@ -128,6 +132,16 @@ For each touched surface, answer only what is relevant:
 - What validation path can prove conformance?
 - If this came from an external plan/source, which source constraints are covered by existing Context, require new Context, are task-local only, are explicitly out of scope, need user decision or remain under-scoped?
 
+When screen depth is material, also answer only the applicable questions:
+
+- What stable surface/route key, entry context, exit outcome, inherited state and committed state identify the screen?
+- What is the semantic information order and which regions are fixed, scrolling or overlay-owned?
+- Which navigation, back/cancel, focus restoration, interruption and responsive/mode/state variants are durable?
+- For each material stable control key, what are its region/location, type/label, user task, visibility/availability, trigger/input/validation/default, interaction/navigation, loading/empty/success/failure/recovery/permission/feedback and accessibility semantics?
+- Which exact-target/constraint/inspiration IDs govern which declared conditions, and which verification path proves each independent claim?
+
+Before applying material UI facts, perform UI Authority Closure: classify each item as Context-covered, Context update, task-local, out of scope or decision-required. Conflicting controlling owners fail closed; current code, timestamps and Contract YAML do not silently win.
+
 ## Repo-Local Task Block Candidate
 
 When the user wants project-local enforcement, propose a separate project-local Skill block like this and tailor only the project-specific answers:
@@ -173,4 +187,5 @@ Conformance must internally confirm that every important external-source constra
 - Do not treat current backend fields, enums, JSON, screenshots or terminal output as product intent.
 - Do not invent rationale; rejected alternatives or tradeoffs belong in Context only when they are stable enough to affect future surface decisions.
 - Do not add a surface-specific validator, edit-order gate, plan-contract validator or package-level mandatory Surface Contract gate.
+- Do not create a `design`/`screen` Context role, per-surface readiness state, UI/UX Contract lifecycle or required Screen Contract for local fixes.
 - Do not include business-domain examples in this package-managed Skill.