project-tiny-context-harness 0.7.2 → 0.7.3

package/README.md

@@ -137,7 +137,7 @@ npm ci
 npm run smoke:quickstart
 npm run preview:pack
 cd /path/to/your/test-repo
-npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.7.2.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.7.3.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -148,7 +148,7 @@ Use this tarball path for source-preview testing, private review or package deve
 
 The default read path is `project_context/global.md`, `project_context/architecture.md`, `project_context/context.toml`, the default area root, then minimum graph-relevant role Context.
 
-Only near-universal recovery facts should use `read_policy = "default"`; specialized detail should be task-triggered `on-demand`. `ty-context doctor` reports the deterministic default Context footprint, soft-budget overages and byte-identical default files as advisory maintenance signals, not a new gate.
+Only near-universal recovery facts should use `read_policy = "default"`; specialized detail should be task-triggered `on-demand`. `ty-context doctor` reports the deterministic default Context footprint, soft-budget overages, byte-identical default files and `DESIGN.md` authority status as advisory maintenance signals, not a new gate.
 
 ### Bounded Context discovery
 
@@ -191,9 +191,11 @@ Newly generated Harness configs default to `strict_except_generated`. Generated/
 
 ### Visual Delivery Guidance
 
-For material design-system, redesign, high-fidelity or visual-polish 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. It is internal planning, not a required matrix or authority. Durable surface/interaction facts remain in `project_context/**`; durable visual-system semantics and rationale remain in `DESIGN.md`; the project names one authored exact token source and generation direction. `context_development_engineer` binds that intent to production components/routes and reports only combinations actually rendered and checked.
+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.
 
-An explicit Long-Task uses its existing Requirement, Control, Assertion, `ui_browser`, verification-input and `external_confirmation` mechanisms for material visual expectations. Acceptance-affecting screenshot baselines are frozen verifier inputs, generated screenshots/diffs remain review artifacts, and subjective design or new-baseline approval remains external. No visual Schema, risk level, lifecycle state, Gate or required artifact is added.
+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.
 
 ### Optional Source Plan Authoring
 
@@ -318,7 +320,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.2.tgz`.
+The synchronized local preview tarball is named `project-tiny-context-harness-0.7.3.tgz`.
 
 ## Community And Further Reading
 

package/assets/README.md

@@ -137,7 +137,7 @@ The smoke packs the local workspace, installs it into a disposable repo and vali
 
 ```sh
 cd /path/to/your/test-repo
-npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.7.2.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.7.3.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -166,7 +166,7 @@ minimum graph-relevant area/role Context
 
 Only near-universal recovery facts should use `read_policy = "default"`; specialized architecture, contract, deployment and historical detail should be task-triggered `on-demand` Context. Before deciding `Context Delta`, the Agent also runs 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 language. Matching files are merged with manifest candidates and filtered by semantic relevance. This is not a vector or persistent retrieval system and creates no index, cache, registry, search state or authority.
 
-`ty-context doctor` reports the deterministic default read footprint, per-file/total soft-budget overages and byte-identical default files. These are advisory maintenance signals, not a new validation gate or workflow state.
+`ty-context doctor` reports the deterministic default read footprint, per-file/total soft-budget overages, byte-identical default files and `DESIGN.md` authority status. These are advisory maintenance signals, not a new validation gate or workflow state.
 
 Typical roles are area/domain, contract, foundation, decision-rationale, implementation-index, verification and deployment. Context owns durable intended boundaries; code owns current implementation; tests, CI, browser/runtime evidence and people own behavior and product acceptance.
 
@@ -212,9 +212,11 @@ Newly generated Harness configs default to `strict_except_generated`. Generated/
 
 ### Visual Delivery Guidance
 
-For material design-system, redesign, high-fidelity or visual-polish 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. It is internal planning, not a required matrix or authority. Durable surface/interaction facts remain in `project_context/**`; durable visual-system semantics and rationale remain in `DESIGN.md`; the project names one authored exact token source and generation direction. `context_development_engineer` binds that intent to production components/routes and reports only combinations actually rendered and checked, so a detached static kit or mock cannot substitute for product UI evidence.
+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.
 
-An explicit Long-Task expresses material visual expectations through the existing Requirement, Control, Assertion, `ui_browser`, verification-input and `external_confirmation` mechanisms. Acceptance-affecting screenshot baselines are frozen verifier inputs, generated screenshots/diffs are review artifacts, and subjective design or new-baseline approval remains external. This guidance adds no visual Schema, risk level, lifecycle state, Gate or required artifact and does not change the default Workflow Contract.
+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.
 
 ### Optional Source Plan Authoring
 
@@ -463,7 +465,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.2.tgz` under the preview output directory.
+`npm run preview:pack` produces a local preview named `project-tiny-context-harness-0.7.3.tgz` under the preview output directory.
 
 ## Community And Further Reading
 

package/assets/README.zh-CN.md

@@ -71,7 +71,7 @@ manifest/trigger 命中的少量 area/role Context
 
 这次搜索只补充语义判断，不会把所有关键词命中都当成 Authority，也不会创建向量/持久索引、缓存、Registry、search state 或第二权威。它仍可能漏掉完全不同的同义词或间接依赖，因此高风险任务还需要 Architecture Context Hit 与收尾 Conformance。
 
-`ty-context doctor` 会报告确定性的默认 Context 文件/字节规模、单文件与总量软预算超限，以及字节完全相同的默认文件。这些只是维护提示，不是新验证 Gate 或运行时状态。
+`ty-context doctor` 会报告确定性的默认 Context 文件/字节规模、单文件与总量软预算超限、字节完全相同的默认文件，以及 `DESIGN.md` 权威状态。这些只是维护提示，不是新验证 Gate 或运行时状态。
 
 Context 负责耐久的意图和边界，代码负责当前实现，测试/CI/浏览器或运行时证据/人工负责行为与产品验收。
 
@@ -105,9 +105,11 @@ Harness 只路由仓库原生 lint/AST/dependency/contract check，不实现跨
 
 ### 视觉交付指导
 
-对设计系统、重设计、高保真实现或 visual polish，`context_uiux_design` 在任务内部维护一个风险比例化的 Visual Coverage Set，覆盖生产 surface/component、viewport、theme/mode、state、content stress 与 accessibility/motion 条件。它只是内部计划，不是必需 matrix 或新权威。耐久 surface/interaction 事实仍属于 `project_context/**`，耐久视觉语义与理由属于 `DESIGN.md`；项目只声明一个精确 token 手工事实源和一个生成方向。`context_development_engineer` 把这些意图绑定到生产组件/真实 route，只报告真正渲染和检查过的组合，静态 kit 或 mock 不能替代产品 UI 证据。
+默认 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 仍保持轻量。
 
-显式 Long-Task 仍通过现有 Requirement、Control、Assertion、`ui_browser`、verification input 与 `external_confirmation` 表达视觉要求。影响验收的截图 baseline 是冻结的 verifier input，生成截图/diff 只是 review artifact，主观设计或新 baseline 批准保持外部确认。这项指导不新增视觉 Schema、risk level、lifecycle state、Gate 或必需 artifact，也不修改默认 Workflow Contract。
+对 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、必需设计目录或通用像素阈值。
 
 ### 可选 Source Plan Authoring
 

package/assets/agents/AGENTS_CORE.md

@@ -10,7 +10,7 @@ Unless an active Long-Task binding exists:
 
 1. Read `project_context/global.md`, `project_context/architecture.md`, `project_context/context.toml` and the default area root, then collect graph/trigger candidates.
 2. Before deciding `Context Delta`, run one bounded text search over `project_context/**` using a small set of high-signal task terms such as explicit area/module names and API/schema/state/security/verification/deployment terms. Merge matching Context with manifest candidates and read only relevant files; search supplements rather than replaces semantic judgment.
-3. For UI/product-surface work, confirm information/action/feedback ownership and use `context_surface_contract` when durable responsibility is unclear or changes; contract owns interfaces and existing area/subdomain/verification roles own the project facts.
+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.
 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.
@@ -42,7 +42,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`; logs, raw evidence, secrets, runtime state and receipts do not.
+- 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.
 - 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.
 
@@ -50,7 +50,7 @@ Tiny Context does not create or restore platform Goals, invoke models, spawn age
 
 - `make validate-context`: Context recoverability.
 - `make validate-harness`: Context plus touched-source modularity.
-- `ty-context doctor`: installation health plus advisory default Context footprint.
+- `ty-context doctor`: installation health plus advisory default Context footprint and Design Authority status.
 - `node packages/ty-context/dist/cli.js package check-source`: managed-source/package parity in this source workspace.
 
 Every handoff reports exactly one of `Context: updated ...` or `Context: no durable fact change`. Never claim tests, deployment or acceptance from Context alone.

package/assets/context_templates/global.md

@@ -35,6 +35,7 @@
 
 - Capture durable screen, flow, interaction, responsive and accessibility facts. Use `DESIGN.md` for visual identity and design tokens when needed.
 - For web/front-end surfaces, record durable page responsibilities, core user judgments, persistent information boundaries and cross-page or cross-layer ownership when they guide future changes.
+- Reference durable versioned design targets at their project-native path or URI and classify them as `exact-target`, `constraint` or `inspiration`; do not paste generated implementation screenshots, diffs or review logs into Context.
 
 ## Verification Entry Points
 

package/assets/skills/context_development_engineer/SKILL.md

@@ -72,13 +72,16 @@ sample provider / interface / page 证据不能替代 all-provider / all-interfa
 
 ## Visual Delivery Implementation / 视觉交付实现
 
-When controlling Context, `DESIGN.md` or explicit Source declares material visual work, carry that intent into the real implementation without creating another workflow:
+For material production UI, first confirm Design Authority readiness; then carry declared Context, `DESIGN.md` and Source intent into the real implementation without creating another workflow:
 
+- treat an unconfigured starter, style-only guidance, inspiration-only references or conflicting targets as insufficient authority for invented production layout; route explicit design authoring through `context_uiux_design` or return for a genuine material decision;
+- classify referenced targets as `exact-target`, `constraint` or `inspiration` and bind fidelity claims only to the named target/constraint conditions;
 - identify the production token source, its generation direction, the owning components/routes and any project-local UI/UX Skill before choosing implementation values;
 - reuse production components and real product routes for states/specimens instead of building a detached static imitation as the acceptance target;
 - 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.
+- 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.
 

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 in a Minimal Context Harness project. Do not trigger for ordinary UI implementation, CSS tweaks, bug fixes, or generic mentions of 设计, design, or user experience.
+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.
 ---
 
 # Context UIUX Design
@@ -18,13 +18,13 @@ Project-specific UI/UX and visual design rules belong in a separate project-loca
 ## 工作方式
 
 1. 先读取 `project_context/global.md` 和 `project_context/context.toml`，按 default area、triggers、read_when 选择相关 context。
-2. 如果项目存在 `DESIGN.md`，先读取它；如果用户要求视觉体系、设计稿或界面风格，按 Google `@google/design.md` 的 DESIGN.md 格式创建或更新根目录 `DESIGN.md`。
-3. 整理或生成：用户流程、页面/组件清单、关键状态、交互反馈、响应式边界、a11y 要求、视觉约束和设计 token。
+2. 如果项目存在 `DESIGN.md`，先读取其 Design Authority 状态、唯一 token 源/生成方向和设计引用；如果用户要求视觉体系、设计稿或界面风格，按 Google `@google/design.md` 的 DESIGN.md 格式创建或更新根目录 `DESIGN.md`。
+3. 整理或生成：用户流程、页面/组件清单、关键状态、交互反馈、响应式边界、a11y 要求、视觉约束、设计 token，以及需要长期复用的 design reference registry。
 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`。
 5. 涉及输入、选择、搜索、筛选、表单/配置、调度/时间窗口、预算/配额/限流或加载/空态/错误态等 UI 控件时，用“控件交互框架”检查控件语义、反馈状态、校验、错误预防、可供性和信息密度；这只是通用判断框架，不是固定控件处方。
-6. 界面职责、流程归属和长期交互契约以 `project_context/**` 为准；`DESIGN.md` 负责视觉 token 和视觉 rationale；代码、截图和搜索结果只说明当前实现状态。Context 决定“应该是什么”，代码和截图揭示“现在是什么”，代码不能静默重定义 Context。
+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 映射表。
 8. 普通 UI bug、局部样式或 CSS 修复、测试修复或探索性 spike 不更新 Context，可先改代码；一旦形成长期交互或视觉结论，继续对齐或交付前必须回写 Context 或 `DESIGN.md`。不要把 Context 机械补成代码改动摘要。
 9. 如果二者冲突，显式标记为实现漂移、缺失工作或 Context 过期。
@@ -82,6 +82,17 @@ Project-specific UI/UX and visual design rules belong in a separate project-loca
 - 视觉审查时先分清问题类型：a11y / responsive / theming / interaction / copy / performance / anti-pattern。把真正影响用户理解、操作或品牌信任的问题列为高优先级；少量纯审美偏好不要淹没关键问题。
 - Harness 默认携带 Impeccable CLI 能力；做设计稿、重做设计、视觉设计方案、设计系统方案、frontend redesign、visual polish 或既有 UI 视觉审查时，默认尝试运行 `npx impeccable detect <target>` 作为辅助证据，不必等待用户点名。其输出只能作为设计缺陷线索，不是 Harness gate，也不能替代人工截图检查、项目测试或 `validate-context`。
 
+## Design Authority Readiness / 设计权威就绪
+
+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.
+
+- 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.
+- 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.
@@ -89,6 +100,7 @@ For material design-system, redesign, high-fidelity implementation or visual-pol
 - 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.
 - Keep the authority split explicit: `project_context/**` owns durable surface/interaction responsibility and `DESIGN.md` owns durable visual-system semantics and rationale. Record one authored exact-value token source and one generation direction; generated CSS/theme/export files are implementation outputs, not competing authored truth. If `DESIGN.md` is not the machine-token source, name the project-native source it governs instead of hand-maintaining the same exact values twice.
+- Map every claimed fidelity combination to its selected `exact-target` or named `constraint`; do not let the Visual Coverage Set turn inspiration or missing authority into an implicit target.
 - Inspect production components or real product routes. A detached static kit, mock, poster, marketing specimen or generated showcase may guide design review, but it cannot be the only evidence for product UI behavior or fidelity.
 - Render and inspect the declared coverage with project-owned browser/component tests plus screenshots or manual review as appropriate. Report the combinations actually checked and any omitted or external review explicitly. A screenshot baseline may be updated only through deliberate review; replacing it merely to erase a diff is not verification.
 
@@ -98,12 +110,13 @@ For material design-system, redesign, high-fidelity implementation or visual-pol
 - 不要求 lifecycle phase、plan task、phase gate 或阶段 Skill。
 - 如果用户明确要求独立设计稿、mock 或页面说明，可以临时生成；长期事实仍要提炼回 `project_context/**` 和 `DESIGN.md`。
 - `DESIGN.md` 是视觉设计系统事实源；项目流程、模块契约和下一步动作仍以 `project_context/**` 为准。
-- 如果用户只是要求实现页面、修复 UI bug、局部改 CSS、换颜色，或只是泛泛提到“设计 / design / user experience”，不需要触发本 Skill；只有明确角色名或强相关产物名指向设计方向、界面方案、视觉体系、交互规则或长期设计事实沉淀时才使用。
+- 如果普通页面实现已经有充分 Design Authority，或用户只要求修复 UI bug、局部改 CSS、换颜色、明确的 throwaway prototype，或只是泛泛提到“设计 / design / user experience”，不需要触发本 Skill；明确角色/产物、视觉体系工作，或 material production UI 缺失/冲突的 Design Authority 才使用。
 
 ## DESIGN.md 使用规则
 
 - 使用 Google `@google/design.md` 格式：YAML front matter 存 tokens，Markdown body 存设计理由。
 - 优先包含 `name`、`colors`、`typography`、`spacing`、`rounded` 和必要 `components` token。
+- 在 `Overview` 内维护 Design Authority 状态、唯一 authored token source/generation direction 和 design reference registry；每个 durable reference 记录稳定 id、surface/route/component、path/URI、`exact-target` / `constraint` / `inspiration` 解释及覆盖条件。不要添加 Google schema 不支持的 front-matter keys。
 - Markdown section 顺序优先为：`Overview`、`Colors`、`Typography`、`Layout`、`Elevation & Depth`、`Shapes`、`Components`、`Do's and Don'ts`。
 - 写入或修改后，如本地可用，运行 `npx @google/design.md lint DESIGN.md` 检查结构；不要把 lint 结果写成“已通过”除非本轮真实执行。
 - 需要给工程消费 token 时，可用 `npx @google/design.md export --format css-tailwind DESIGN.md` 或 `json-tailwind` 生成临时输出。
@@ -118,6 +131,6 @@ For material design-system, redesign, high-fidelity implementation or visual-pol
 - `areas/*/verification.md` 或 role=`verification` Context：UI smoke、截图验收、可访问性检查或项目自己的关键验证重复执行路径。
 - `areas/*/deployment.md` 或 role=`deployment` Context：前端部署、预览环境、运行拓扑或健康检查重复执行路径。
 - `project_context/context.toml`：复杂项目的产品域 area/context_unit、role、触发词、按需读取策略和可选边界规则。
-- `DESIGN.md`：视觉 identity、design tokens、组件视觉规则、do/don't 和视觉 rationale。
+- `DESIGN.md`：视觉 identity、design tokens、组件视觉规则、do/don't、视觉 rationale、唯一 token source/generation direction 和 design reference registry。
 
 不要编造 rationale；仅由当前代码或截图形态反推的理由、实现摘要、PR notes、命令输出、测试通过声明、截图审查、debug 过程和 agent reasoning 不进入 Context 或 `DESIGN.md`。

package/assets/skills/long-task-workflow/SKILL.md

@@ -44,6 +44,7 @@ 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.
 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. 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.

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

@@ -61,15 +61,19 @@ A proxy check, static repository shape, tracked status report, prior screenshot,
 
 ## Visual Delivery Authoring
 
-When Source or controlling Context declares a design system, redesign, high-fidelity UI or other material visual result, author it through existing Contract semantics:
+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:
 
+- 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, production component/route carriers, path envelopes and project-owned browser checks. Detached kits, mocks or marketing specimens may be references but not substitute implementation carriers;
+- 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;
+- 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.
 
-This guidance adds no visual Schema, Claim kind, risk level, lifecycle state, coverage artifact or Gate. It only makes visual meaning explicit enough for the existing Requirement/Control/Assertion and `ui_browser` mechanisms to verify what was actually declared.
+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.
 
 ## Compact Authoring
 

package/assets/skills/long-task-workflow/references/evidence-design.md

@@ -45,9 +45,11 @@ Standard frozen Playwright verifier content is trusted. Weak-observability Outco
 - Use Playwright for every declared `ui_browser` visual AC and bind each independently falsifiable AC to its own `[ac:<assertion-key>]` Test Instance. A broad screenshot or one passing page case does not silently prove separate viewport, theme, state, content-stress, layout or accessibility claims.
 - Make the test environment deterministic enough for its claim: freeze the relevant browser/project, viewport, theme/mode, locale/timezone, font loading, fixtures/data and animation/motion policy in declared verifier inputs or configuration.
 - Any reviewed screenshot baseline that affects pass/fail must exist for the accepting Compile and be included in `verification_inputs`. Generated screenshots, diffs and reports are Artifacts and review material; they are not editable acceptance authority. Creating or replacing a baseline after Authority Lock is verifier-material revision and must never be silently auto-updated to make a failure pass.
+- Confirm that each baseline is a selected `exact-target` for the named surface/viewport/theme/state or implements a named `constraint`; an inspiration reference cannot become a fidelity oracle merely because it is available. The implementation's current screenshot is never its own target.
 - Screenshot comparison proves only the named visual similarity claim. Pair it with explicit DOM/layout/accessibility assertions when the Contract separately claims no overflow, action visibility, focus behavior, target size, semantic state, reduced motion or other observable behavior.
 - Run checks against production components or real product routes. A detached kit/mock harness is acceptable only when the Contract explicitly makes that artifact the product surface; otherwise it cannot substitute for the production carrier.
 - Keep subjective visual quality and approval external. A new visual direction or baseline that needs human judgment remains an explicit external confirmation even when all machine checks pass.
+- `ui_browser` proves browser UI only. When a native/mobile/desktop UI can fail independently, browser output is proxy evidence; require a project-owned live target-runtime Check that truthfully fits an existing proof surface or keep the device/simulator review external.
 
 ## Structured Evidence And Sensitivity
 

package/assets/skills/source-plan-authoring/SKILL.md

@@ -46,7 +46,7 @@ Before authoring:
 
 1. Assign every supplied artifact a stable input ID and inspect it with format-appropriate capabilities. Cover all pages, frames, screens, tables, diagrams, annotations and visible states that can carry material meaning; never silently sample a multi-part artifact.
 2. Classify each input as user instruction, authoritative product requirement, authoritative technical constraint, existing plan, repository/Context evidence, reference or inspiration. User-stated precedence wins; otherwise report material conflicts as `DEC` instead of merging them silently.
-3. For screenshots or visual references, inventory visible surfaces, regions, controls, content hierarchy, navigation cues and represented states. Treat them as inspiration rather than an exact reproduction target unless the user says otherwise; do not import unrelated branding, sample data or product scope.
+3. For screenshots or visual references, inventory visible surfaces, regions, controls, content hierarchy, navigation cues and represented states, then classify the interpretation as `exact-target`, `constraint` or `inspiration`. Treat it as inspiration unless the user or a higher-authority input makes exact/constraint scope explicit; do not import unrelated branding, sample data or product scope.
 4. Record an Input Inventory in the Source Plan with each input ID, role, authority, material content incorporated and any unreadable or intentionally unused portion. The inventory is traceability, not a new semantic type or authority.
 5. Make the resulting plan self-contained: incorporate every material requirement or constraint into a keyed item. Keep an external artifact reference only when the artifact itself remains necessary for exact visual, legal or other non-textual comparison.
 
@@ -206,7 +206,7 @@ Include a `CTRL` when:
 
 For each included control, state every independently decided field separately: `Surface`, `Region`, `Control type`, `Label/content`, `Location`, `User task`, `Visibility`, `Availability`, `Trigger`, `Input`, `Validation`, `Default`, `Interaction`, `Navigation/result`, `Loading`, `Empty`, `Success`, `Failure`, `Recovery`, `Permission`, `Feedback` and `Accessibility`. Use `not applicable` when a field was considered and genuinely does not apply; do not hide an undecided product choice behind that phrase.
 
-Give every decided Control field its own stable semantic meaning. Do not compress placement, behavior, state or feedback into one broad sentence when more than one field has been decided; later repository-aware authoring must be able to map each field independently. Do not claim exact visual styling, animation, copy or responsive behavior unless it is direct, evidence-backed or within recorded delegation.
+Give every decided Control field its own stable semantic meaning. Do not compress placement, behavior, state or feedback into one broad sentence when more than one field has been decided; later repository-aware authoring must be able to map each field independently. Do not claim exact visual styling, animation, copy or responsive behavior unless it is direct, evidence-backed or within recorded delegation. When exact non-textual comparison remains necessary, preserve the selected reference id/path/URI and its covered viewport/theme/state instead of replacing it with prose.
 
 ## Acceptance Scenarios
 

package/dist/lib/design-md.d.ts

@@ -1,2 +1,5 @@
 export declare const DESIGN_MD_PATH = "DESIGN.md";
+export declare const UNCONFIGURED_DESIGN_AUTHORITY_MARKER = "Design authority status: `unconfigured`";
+export type DesignAuthorityStatus = "missing" | "unconfigured" | "configured";
 export declare function createDesignMdIfMissing(projectRoot: string): Promise<boolean>;
+export declare function inspectDesignAuthorityStatus(projectRoot: string): Promise<DesignAuthorityStatus>;

package/dist/lib/design-md.js

@@ -1,6 +1,7 @@
 import path from "node:path";
-import { pathExists, writeTextIfChanged } from "./fs.js";
+import { pathExists, readText, writeTextIfChanged } from "./fs.js";
 export const DESIGN_MD_PATH = "DESIGN.md";
+export const UNCONFIGURED_DESIGN_AUTHORITY_MARKER = "Design authority status: `unconfigured`";
 export async function createDesignMdIfMissing(projectRoot) {
     const target = path.join(projectRoot, DESIGN_MD_PATH);
     if (await pathExists(target)) {
@@ -8,12 +9,24 @@ export async function createDesignMdIfMissing(projectRoot) {
     }
     return writeTextIfChanged(target, designMdTemplate());
 }
+export async function inspectDesignAuthorityStatus(projectRoot) {
+    const target = path.join(projectRoot, DESIGN_MD_PATH);
+    if (!(await pathExists(target)))
+        return "missing";
+    const content = await readText(target);
+    if (content.includes(UNCONFIGURED_DESIGN_AUTHORITY_MARKER)) {
+        return "unconfigured";
+    }
+    const legacyStarter = content.includes('name: "Starter Design System"') &&
+        content.includes('description: "Neutral baseline design guidance for projects that have not defined their own visual system."');
+    return legacyStarter ? "unconfigured" : "configured";
+}
 function designMdTemplate() {
     return [
         "---",
         'version: "alpha"',
-        'name: "Starter Design System"',
-        'description: "Neutral baseline design guidance for projects that have not defined their own visual system."',
+        'name: "Unconfigured Project Design"',
+        'description: "Starter tokens for explicit prototypes only; not an approved production visual system or page-layout target."',
         "colors:",
         '  canvas: "#F8FAFC"',
         '  surface: "#FFFFFF"',
@@ -25,22 +38,22 @@ function designMdTemplate() {
         '  on-primary: "#FFFFFF"',
         "typography:",
         "  display:",
-        '    fontFamily: "Public Sans"',
+        '    fontFamily: "system-ui"',
         '    fontSize: "2.5rem"',
         "    fontWeight: 700",
         "    lineHeight: 1.1",
         "  title:",
-        '    fontFamily: "Public Sans"',
+        '    fontFamily: "system-ui"',
         '    fontSize: "1.5rem"',
         "    fontWeight: 700",
         "    lineHeight: 1.25",
         "  body:",
-        '    fontFamily: "Public Sans"',
+        '    fontFamily: "system-ui"',
         '    fontSize: "1rem"',
         "    fontWeight: 400",
         "    lineHeight: 1.6",
         "  label:",
-        '    fontFamily: "Public Sans"',
+        '    fontFamily: "system-ui"',
         '    fontSize: "0.875rem"',
         "    fontWeight: 600",
         "    lineHeight: 1.3",
@@ -54,79 +67,59 @@ function designMdTemplate() {
         "  md: 16px",
         "  lg: 24px",
         "  xl: 32px",
-        "components:",
-        "  app-shell:",
-        '    backgroundColor: "{colors.canvas}"',
-        '    textColor: "{colors.text}"',
-        "  surface-card:",
-        '    backgroundColor: "{colors.surface}"',
-        '    textColor: "{colors.text}"',
-        '    rounded: "{rounded.md}"',
-        "    padding: 16px",
-        "  quiet-control:",
-        '    backgroundColor: "{colors.surface-muted}"',
-        '    textColor: "{colors.text-muted}"',
-        '    rounded: "{rounded.sm}"',
-        "    padding: 8px",
-        "  primary-action:",
-        '    backgroundColor: "{colors.primary}"',
-        '    textColor: "{colors.on-primary}"',
-        '    typography: "{typography.label}"',
-        '    rounded: "{rounded.md}"',
-        "    padding: 12px",
-        "  primary-action-hover:",
-        '    backgroundColor: "{colors.primary-hover}"',
-        '    textColor: "{colors.on-primary}"',
-        '    typography: "{typography.label}"',
-        '    rounded: "{rounded.md}"',
-        "    padding: 12px",
+        "components: {}",
         "---",
         "",
-        "# Design System",
+        "# Design Authority",
         "",
         "## Overview",
         "",
-        "- This is a starter visual system for projects that have not defined their own design rules yet.",
-        "- User-authored tokens, brand rules and later product decisions take precedence over this starter baseline.",
-        "- Keep durable color, typography, spacing, radius, component and interaction choices here so future UI work does not drift.",
+        `- ${UNCONFIGURED_DESIGN_AUTHORITY_MARKER}.`,
+        "- This file is a non-authoritative scaffold, not an approved brand, component system or page-layout target.",
+        "- Material production UI must not use these starter tokens as permission to invent information hierarchy, layout or visual language.",
+        "- Replace this status and the provisional tokens only after project-specific visual decisions stabilize.",
+        "",
+        "### Design Authority Index",
+        "",
+        "- Authored exact-value token source: not selected.",
+        "- Generation direction and generated token targets: not selected.",
+        "- Durable design references: none selected.",
+        "- For each selected reference, record a stable id, surface/route/component, project path or URI, `exact-target` / `constraint` / `inspiration` interpretation, and the viewport/theme/state conditions it covers.",
         "",
         "## Colors",
         "",
-        "- Use `canvas` for the page background, `surface` for panels and `surface-muted` for quiet controls or secondary regions.",
-        "- Keep primary actions on `primary` with `on-primary` text; use `primary-hover` for hover and active emphasis.",
-        "- Avoid introducing decorative gradients, random accent colors or single-hue palettes unless the product brand explicitly calls for them.",
+        "- These colors are provisional accessibility-oriented prototype values only; they are not a project palette or brand decision.",
+        "- Replace them from one authored token source before material production styling.",
         "",
         "## Typography",
         "",
-        "- Use `display` only for true page-level emphasis, `title` for section and panel headings, `body` for readable content and `label` for controls.",
-        "- Preserve hierarchy through size, weight and spacing before adding extra colors or decoration.",
+        "- The system-font typography is provisional prototype scaffolding only.",
+        "- Record the selected type family, hierarchy and loading behavior before fidelity implementation.",
         "",
         "## Layout",
         "",
-        "- Start with clear page structure: canvas, surfaces, primary action, secondary controls and readable content regions.",
-        "- Use the spacing scale consistently; dense operational screens can reduce vertical whitespace, while marketing or editorial surfaces can breathe more.",
-        "- On small screens, stack content in priority order and keep primary actions reachable without overlapping other UI.",
+        "- This scaffold declares no production page composition, information hierarchy or responsive layout.",
+        "- Put durable screen responsibility and interaction structure in `project_context/**`; reference selected visual targets in the Design Authority Index.",
         "",
         "## Components",
         "",
-        "- Buttons, inputs, cards, navigation and dialogs need default, hover, active, focus, disabled, loading and error states when they are user-facing.",
-        "- Use `surface-card` for contained groups, `quiet-control` for low-emphasis controls and `primary-action` for the main command.",
-        "- Prefer clear affordances, visible focus states and stable dimensions so labels, icons and dynamic text do not resize the layout.",
+        "- No production component visual language is selected yet.",
+        "- When components are selected, record their visual tokens and relevant default, hover, active, focus, disabled, loading and error states without duplicating an authored code token source.",
         "",
         "## Do's and Don'ts",
         "",
-        "- Do use this file as the first design fact source before generating mockups, Figma screens or frontend UI.",
-        "- Do replace or extend this starter when the project has a real brand, product category or design system.",
-        "- Do keep accessibility, responsive behavior and interaction states explicit.",
-        "- Don't treat this starter as a user brand decision once project-specific rules exist.",
-        "- Don't add generic AI-looking hero gradients, oversized cards or decorative blobs unless the product direction asks for them.",
+        "- Do treat `unconfigured` as a stop/routing signal for material production UI, not as visual permission.",
+        "- Do classify selected references as `exact-target`, `constraint` or `inspiration` before implementation.",
+        "- Do use these tokens only for an explicitly throwaway prototype while authority remains unconfigured.",
+        "- Don't promote an implementation screenshot or diff into its own target baseline.",
+        "- Don't add generic AI-looking gradients, oversized cards, excessive rounding or decorative blobs without selected design authority.",
         "",
         "## Design Change Workflow",
         "",
-        "- Read this file before creating design drafts, redesigning UI, changing visual systems or polishing frontend styling.",
+        "- Read this file before creating design drafts, redesigning UI, changing visual systems or implementing material production UI.",
         "- When there is a scan target such as UI source, page files, build output or a local/remote URL, run `npx impeccable detect <target>` before finalizing design changes.",
         "- Treat Impeccable findings as design-review signals: fix issues that affect clarity, consistency, accessibility or trust, and note when there is no suitable scan target.",
-        "- After design decisions stabilize, update this file with durable tokens, component rules and do/don't guidance so later UI work stays aligned.",
+        "- After design decisions stabilize, replace the unconfigured marker, index the selected targets and authored token source/generation direction, and record durable tokens, component rules and do/don't guidance.",
         "",
     ].join("\n");
 }

package/dist/lib/doctor.js

@@ -4,6 +4,7 @@ import os from "node:os";
 import { readdir } from "node:fs/promises";
 import { DEFAULT_CONTEXT_FILE_SOFT_BUDGET_BYTES, DEFAULT_CONTEXT_TOTAL_SOFT_BUDGET_BYTES, inspectDefaultContextFootprint, } from "./context-default-footprint.js";
 import { readConfig } from "./config.js";
+import { inspectDesignAuthorityStatus } from "./design-md.js";
 import { harnessConfigPath, harnessRoot } from "./harness-root.js";
 import { pathExists } from "./fs.js";
 import { unsupportedSchemaMessage } from "./schema-guard.js";
@@ -62,6 +63,13 @@ export async function runDoctor(projectRoot) {
     catch (error) {
         report.warnings.push(`default Context footprint unavailable: ${error instanceof Error ? error.message : String(error)}`);
     }
+    const designAuthority = await inspectDesignAuthorityStatus(projectRoot);
+    if (designAuthority === "unconfigured") {
+        report.info.push("design authority: unconfigured; DESIGN.md is a starter scaffold and does not authorize material production UI until project-specific tokens and exact-target/constraint/inspiration references are selected");
+    }
+    else {
+        report.info.push(`design authority: ${designAuthority}`);
+    }
     for (const location of await findUserSuperpowersSkills()) {
         report.warnings.push(`user-level using-superpowers Skill detected at ${location}. Tiny Context workflows do not depend on it and doctor will not modify global configuration. To disable it explicitly for Codex, remove/disable that plugin or add a matching [[skills.config]] entry with enabled = false in ${path.join(os.homedir(), ".codex", "config.toml")}.`);
     }

package/package.json

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