project-tiny-context-harness 0.7.1 → 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.1.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
 
@@ -235,7 +237,7 @@ Before product implementation, the Agent asks the user to continue with the curr
 
 Harness cannot switch the host-selected model. It creates no checkpoint file, acknowledgement state, model route, model-tier scheduler or automatic model switch. The choice is a one-time execution-cost affordance enabled by locked Authority and Final Gate protection; it is not acceptance evidence.
 
-Post-lock revisions use three fail-closed paths. Proven monotonic/mechanical strengthening auto-adopts. A candidate whose only protected reasons are owner/change/support expansion may run existing active Check identities with unchanged runner/verifier authority through stateless `diagnose-revision`; safe monotonic strengthening may coexist, but those transient results write no authority, pending decision, Progress, cache or Receipt and cannot accept. Semantic changes, proof weakening, runner or verifier-content changes, and risk increases are preview-only; risk downgrade is rejected. Related edits remain in the same `delivery-contract.yaml` until one ordinary `compile --revise` emits an exact hash-bound approval summary; `status` and `resume` project that same pending decision. Exact adoption invalidates derived evidence and never replaces the complete current-snapshot Final Gate.
+Post-lock revisions use three fail-closed paths. Proven monotonic/mechanical strengthening auto-adopts. A candidate whose only protected reasons are owner/change/support expansion may run existing active Check identities with unchanged runner/verifier authority through stateless `diagnose-revision`; safe monotonic strengthening may coexist, but those transient results write no authority, pending decision, Progress, cache or Receipt and cannot accept. Semantic changes, proof weakening, runner or verifier-content changes, and risk increases are preview-only; risk downgrade is rejected. A rolling blocker alone cannot reclassify or remove machine-verifiable scope; a real scope change first becomes marked Source. Related edits remain in the same `delivery-contract.yaml` until one ordinary `compile --revise` emits an exact hash-bound approval summary containing changed semantic fields, Source/Product Claim reductions, proof reductions and external-confirmation keys; `status` and `resume` project that same pending decision. Exact adoption reports `delivery_completed_by_this_event: false`, invalidates affected evidence, returns to rolling implementation or repair and never replaces the complete current-snapshot Final Gate.
 
 ```text
 ty-context long-task init <workdir>
@@ -255,13 +257,13 @@ ty-context long-task close <workdir>
 ty-context long-task abandon <workdir> [--force-corrupt-state]
 ```
 
-Compact authoring omits only deterministic defaults and normalizes identically to the expanded form. `preflight` is a read-only aggregated Source/REQ/CTRL/OBL/AC and repository check that creates no authority, state, Receipt or runner execution. Compile generates Global plus Outcome Result/Requirement/Control-field/Non-completing/Technical Claims, rejects uncovered Claims and makes the first successful formal Compile the Authority Lock. The first Compile result emits `execution_model_checkpoint.required: true`; later Compile revisions emit `required: false`. Every later authority change still compares with active authority regardless of progress, Receipt/cache deletion or implementation restoration. Source/Context/Product/Acceptance/Global/verifier content, resolved runners and verification inputs are frozen in the common-dir Active Authority V3 record.
+Compact authoring omits only deterministic defaults and normalizes identically to the expanded form. `preflight` is a read-only aggregated Source/REQ/CTRL/OBL/AC and repository check that creates no authority, state, Receipt or runner execution. Compile generates Global plus Outcome Result/Requirement/Control-field/Non-completing/Technical Claims, rejects uncovered Claims and makes the first successful formal Compile the Authority Lock. Every Compile result includes a lifecycle event, `delivery_completed_by_this_event: false`, `native_goal_effect: none` and a next action. The first Compile result emits `execution_model_checkpoint.required: true`; later Compile revisions emit `required: false`. Every later authority change still compares with active authority regardless of progress, Receipt/cache deletion or implementation restoration. Source/Context/Product/Acceptance/Global/verifier content, resolved runners and verification inputs are frozen in the common-dir Active Authority V3 record.
 
-`diagnose-revision` performs a side-effect-free candidate Compile and only exercises existing active Check identities whose runner/verifier authority is unchanged. Its output explicitly denies acceptance, Progress and pending-state writes. Protected `compile --revise` emits `authority_revision_pending`, the exact decision id and a deterministic concise summary before failing closed; approving a different or stale id is rejected.
+`diagnose-revision` performs a side-effect-free candidate Compile and only exercises existing active Check identities whose runner/verifier authority is unchanged. Its output explicitly denies acceptance, Progress and pending-state writes. Protected `compile --revise` emits `authority_revision_pending`, the exact decision id and a deterministic material summary before failing closed; approving a different or stale id is rejected. Adoption emits `authority_revision_adopted` and returns to rolling execution rather than completion.
 
 Targeted verify rechecks active task/revision/compiled/worktree identity before writing scoped Progress. Counterfactual Findings first enter the owning Check Result, invalidate an otherwise passed Check, clear Claim Proofs and remain visible in status/resume; Global Checks reuse the same Progress type without a Global Outcome state. Final Gate repeats the identity check after all Checks; Stop/close clear only the accepted identity through CAS. Commit, migration, clear and abandon share one active-state lock. `abandon --force-corrupt-state` is reserved for corrupt continuity or stale lock cleanup and preserves Contract, Source, Context and Git content.
 
-`status` and read-only `resume` report the current fresh Final Receipt as `final_workflow_status` (or `null` after drift) plus the active Contract's complete `external_confirmations`. `progress_passing` is targeted repair evidence rather than “Outcome complete”; `progress_stale` is not a current pass, and `final_workflow_status: null` means unfinished. When machine scope passes with external delivery pending, the package-owned Stop Hook allows stopping and emits a non-blocking `systemMessage`; `close` preserves the accepted `workflow_status` and confirmations in its JSON result. `status: closed` means only that machine Authority was cleared, not that external delivery completed.
+`status` and read-only `resume` report the current fresh Final Receipt as `final_workflow_status` (or `null` after drift) plus the active Contract's complete `external_confirmations`. `progress_passing` is targeted repair evidence rather than “Outcome complete”; `progress_stale` is not a current pass, and `final_workflow_status: null` means unfinished. Every accepted Stop emits one non-blocking terminal-scope `systemMessage`; external-pending results also name every confirmation. Final/Stop/close report `acceptance_scope: declared_machine_authority` and `native_goal_effect: none`; close also reports `closed_scope: machine_authority`. Before platform-native Goal completion, the Agent performs a veto-only Goal/user-to-Source conformance review that cannot create proof. `status: closed` means only that machine Authority was cleared, not that the native Goal or external delivery completed.
 
 New authoring uses inline Outcomes. Existing `outcome_files` remains physical compatibility only and creates no semantic or completion boundary. A Long Task requires real Source, and every declared Source file contains at least one Material Item; background-only references remain outside Source Authority. Every Material Source Item is wrapped in the original Markdown with a non-rendering, uniquely keyed `ty-source-item:start/end` marker; `control` is a first-class kind, marker keys and `source_claim` keys are set-equal, and statements are text-exact after limited whitespace normalization. Every non-decision Source item owns one same-kind, same-text canonical target and duplicate ownership fails. Outcome Source Acceptance maps to criterion-identical `<outcome>.<check>.<assertion>` with an independently Source-backed non-Result Claim; Global Source Acceptance maps to criterion-identical `GLOBAL.<check>.<assertion>`, proves no Outcome Claim and needs an independently Source-backed Global Claim. Typed dispositions keep Requirements, Controls, Acceptance, Results, Fact/Affected-Outcome Risk, Non-goals, External Confirmations and Decisions distinct; `out_of_scope` is retired. Ordinary prose remains valid after marker-only enumeration.
 
@@ -271,6 +273,8 @@ Supported runners: `package_script`, `project_binary`, `node_oracle`, `playwrigh
 
 Supported proof surfaces: `ui_browser`, `runtime_behavior`, `api_contract`, `data_state`, `security_boundary`, `population_coverage`, `implementation_structure`.
 
+After a blocker-driven semantic or proof revision, only affected weak-observability or high-risk behavioral Claims receive a causal-boundary review. Evidence must reach the furthest independently failing declared boundary; when carrier existence can diverge from the claimed capability, use a capability-disrupting Counterfactual. This adds no product taxonomy, universal runtime suite, mutation type or persistent review state.
+
 ## Risk And Evidence
 
 L0 local work stays on the default workflow. L1 standard long work uses the Delivery Contract. L2 strict is the minimum for public API/schema, persistent data, migration, security/permission boundaries, irreversible effects, full-population operations, or a critical path with weak observability. Strict proof binds to the affected Outcome; multi-repository delivery is rejected.
@@ -316,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.1.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.1.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
 
@@ -258,15 +260,15 @@ Before the first successful formal Compile, `delivery-contract.yaml` is one non-
 
 The first successful Compile creates Authority Lock and returns `execution_model_checkpoint.required: true`. Before implementation, the Agent asks the user to `continue_current_model` or switch models and then resume the active Long-Task. A task-specific model strategy already stated explicitly satisfies the checkpoint. Later Compile revisions return `required: false`; Harness does not switch models, persist acknowledgement/model-route state or repeat the pause.
 
-Later revisions are classified into three paths. Formally monotonic evidence strengthening and other proven mechanical-safe changes auto-adopt. A candidate whose only protected reasons are owner, expected-change or allowed-support expansion may be exercised through `diagnose-revision` using existing active Check identities whose runner and verifier are unchanged; safe monotonic strengthening may coexist, and the results remain transient repair diagnostics rather than Progress or acceptance. Product/Source/Acceptance semantic changes, proof weakening, verifier-content or runner changes, and risk increases are preview-only and require the exact revision identity; risk downgrade remains rejected outright. Diagnosis never changes the active Authority or writes pending/approval state, cache, Progress or Receipt, so related edits can accumulate in the same `delivery-contract.yaml` before one `compile --revise` approval request. The pending decision contains a concise hash-bound summary and is projected by `status`/`resume`; adoption invalidates derived evidence and the complete Final Gate remains mandatory.
+Later revisions are classified into three paths. Formally monotonic evidence strengthening and other proven mechanical-safe changes auto-adopt. A candidate whose only protected reasons are owner, expected-change or allowed-support expansion may be exercised through `diagnose-revision` using existing active Check identities whose runner and verifier are unchanged; safe monotonic strengthening may coexist, and the results remain transient repair diagnostics rather than Progress or acceptance. Product/Source/Acceptance semantic changes, proof weakening, verifier-content or runner changes, and risk increases are preview-only and require the exact revision identity; risk downgrade remains rejected outright. A rolling blocker is not itself an External Confirmation or permission to remove machine-verifiable scope. A real scope change first becomes marked Source. Diagnosis never changes the active Authority or writes pending/approval state, cache, Progress or Receipt, so related edits can accumulate in the same `delivery-contract.yaml` before one `compile --revise` approval request. The pending decision contains a concise hash-bound summary with exact changed semantic fields, Source/Product Claim reductions, proof reductions and external-confirmation keys and is projected by `status`/`resume`. Adoption reports `delivery_completed_by_this_event: false`, invalidates affected evidence and returns to rolling implementation or repair; the complete Final Gate remains mandatory.
 
 The package-managed Long-Task Skill uses progressive disclosure: its main `SKILL.md` keeps the objective, boundaries and phase routing; one-level references are read only for Contract authoring, evidence design or authority lifecycle. This reduces routine instruction load without moving any rule into a second authority. When Source or controlling Context declares an architecture invariant, the Contract uses existing technical obligations/global constraints/forbidden shortcuts, owner/path/Binding boundaries and a project-owned executable Check. Functional acceptance cannot substitute when the architecture invariant can fail independently.
 
 A Draft Outcome is simply an Outcome before Authority Lock. Outcomes split independently observable, decidable and target-verifiable results so the current Goal can keep a smaller dependency-ready working set, target verification, localize failures, resume findings and invalidate stale local results. `depends_on` expresses acceptance readiness; the Rolling Frontier is temporary. An Outcome is not a Worker, scheduler task, queue or parallelism unit. Outcome decomposes execution and diagnosis, not completion authority: targeted passes never replace the one complete Final Gate on the current final snapshot.
 
-When a declared result can pass on a proxy surface while failing in its target runtime, the earliest owning Outcome declares a project-owned Check that exercises the target during the current Check execution. A tracked report, screenshot, binary, log or historical run cannot be the sole runtime proof. The Goal runs that Check after the first runnable slice and, after coalescing related edits, before dependent work grows when declared `input_paths` or Binding carriers make Progress stale. This uses existing targeted verification and Final Gate semantics: it adds no `platform_impact` flags or completion state, requires no full rebuild per Outcome/edit, never accepts early and is rerun by Final Gate.
+When a declared result can pass on a proxy surface while failing in its target runtime, the earliest owning Outcome declares a project-owned Check that exercises the target during the current Check execution. A tracked report, screenshot, binary, log or historical run cannot be the sole runtime proof. After a blocker-driven semantic/proof revision, only affected weak-observability or high-risk behavioral Claims pay a causal review: evidence reaches the furthest independently failing declared boundary, and a Counterfactual disrupts the claimed capability when carrier presence alone can diverge. The Goal runs the live Check after the first runnable slice and, after coalescing related edits, before dependent work grows when declared `input_paths` or Binding carriers make Progress stale. This uses existing targeted verification and Final Gate semantics: it adds no product taxonomy, `platform_impact` flags, universal runtime suite or completion state, requires no full rebuild per Outcome/edit, never accepts early and is rerun by Final Gate.
 
-The platform owns physical Goal/session lifecycle. A later session runs `resume` to reconstruct semantic state; Tiny Context does not recreate the prior physical Turn.
+The platform owns physical Goal/session lifecycle. A later session runs `resume` to reconstruct semantic state; Tiny Context does not recreate the prior physical Turn. Machine acceptance covers only `declared_machine_authority` and reports `native_goal_effect: none`. Before completing the platform-native Goal, the Agent performs a veto-only comparison of current Goal/user meaning against accepted marked Source and checks for pending revisions, unresolved blockers or omissions; this guard may block and repair, but it never supplies acceptance proof.
 
 ### CLI
 
@@ -290,14 +292,14 @@ ty-context long-task abandon <workdir> [--force-corrupt-state]
 
 - `init` creates one Compact inline-Outcome Contract template.
 - `preflight` applies Compact defaults and reports all discoverable Source/REQ/CTRL/OBL/AC, Context, risk, path/binding, runner/input and proof diagnostics. Exact duplicate diagnostics are merged with `occurrences`; known problems may include stable `refs` and a safe `repair_hint` that never weakens authority or invents product semantics. It is read-only: no Authority Lock, marker, cache, progress, Receipt, pending revision, state lock or project Check.
-- `compile` generates Global plus Outcome Result/Requirement/Control-field/Non-completing/Technical Claims, rejects uncovered Claims, preserves an immutable first baseline and makes the first successful formal Compile the Authority Lock. The first result also includes `execution_model_checkpoint.required: true`; later Compile results return `required: false`. Every revision compares against active authority regardless of progress, Receipt/cache deletion or implementation restoration. Source/Context/Product/Acceptance/Global/verifier materials, owner/binding authority, resolved runners and verification inputs are frozen in the common-dir Active Authority V3 snapshot; the model-choice result is not stored as Authority state.
+- `compile` generates Global plus Outcome Result/Requirement/Control-field/Non-completing/Technical Claims, rejects uncovered Claims, preserves an immutable first baseline and makes the first successful formal Compile the Authority Lock. Every result includes a lifecycle event, `delivery_completed_by_this_event: false`, `native_goal_effect: none` and a next action. The first result also includes `execution_model_checkpoint.required: true`; later Compile results return `required: false`. Every revision compares against active authority regardless of progress, Receipt/cache deletion or implementation restoration. Source/Context/Product/Acceptance/Global/verifier materials, owner/binding authority, resolved runners and verification inputs are frozen in the common-dir Active Authority V3 snapshot; the model-choice result is not stored as Authority state.
 - `diagnose-revision` performs a side-effect-free candidate Compile. Only a scope-only candidate may run existing active Check identities with unchanged runner/verifier authority; semantic changes, proof weakening, runner or verifier-content changes, and risk increases are summarized without runner execution, while risk downgrade is rejected. Output always has `acceptance_authorized: false`, `progress_written: false` and `pending_revision_written: false`.
-- `compile --revise` auto-adopts proven-safe revisions. Protected revisions return `authority_revision_pending` on stdout plus the exact decision id and deterministic approval summary, then fail closed until `approve-authority-revision` approves that exact id. Candidate edits produce a new id and invalidate the old approval.
+- `compile --revise` auto-adopts proven-safe revisions. Protected revisions return `authority_revision_pending` on stdout plus the exact decision id and deterministic material approval summary, then fail closed until `approve-authority-revision` approves that exact id. Candidate edits produce a new id and invalidate the old approval. Adoption emits `authority_revision_adopted` and returns to rolling execution; it never means delivery completion.
 - `verify` writes scoped per-Check Progress Records only after rechecking active task/revision/compiled/worktree identity. A concurrent revision returns `active_authority_changed_during_verify` and writes no stale progress.
 - `status` reports each Outcome as `unverified`, `progress_passing`, `progress_failing`, `progress_stale` or `blocked_external`. It also reports the fresh Final Receipt as `final_workflow_status` (or `null` after drift), the active Contract's complete `external_confirmations` and the single `pending_authority_revision` decision when present. `progress_passing` is targeted repair evidence rather than “Outcome complete”; `progress_stale` is not a current pass, and `final_workflow_status: null` means unfinished. It reads the common-dir authority snapshot and reports a missing or mismatched workdir cache as a repairable diagnostic.
 - `resume` is read-only and reports task identity, risk, relevant Context, Git state, the same Final/external/pending decision surfaces, ready Outcomes, findings and the next safe action from the common-dir authority snapshot.
 - `final-gate` requires a clean candidate commit, recompiles source authority, reruns every required Check on one Git-tree snapshot and rechecks active identity before acceptance.
-- `stop-check` and `close` run that Live Final Gate themselves. They never trust status, progress, a Receipt or compiled cache for acceptance; success clears only the accepted identity through CAS. When machine scope passes with external work pending, the Stop Hook allows stopping but shows a non-blocking `systemMessage`; `close` returns `workflow_status` plus all `external_confirmations`. `status: closed` means only that machine Authority was cleared, not that complete external delivery finished.
+- `stop-check` and `close` run that Live Final Gate themselves. They never trust status, progress, a Receipt or compiled cache for acceptance; success clears only the accepted identity through CAS. Every accepted Stop emits one non-blocking terminal-scope `systemMessage`; external-pending results additionally name all confirmations. Final/Stop/close report `acceptance_scope: declared_machine_authority` and `native_goal_effect: none`; close also reports `closed_scope: machine_authority`. `status: closed` means only that machine Authority was cleared, not that the native Goal or complete external delivery finished.
 - `abandon` is explicit non-success cleanup. `--force-corrupt-state` is reserved for invalid/mismatched/legacy-unrecoverable state or a stale active lock and removes only deterministic local active state plus `<workdir>/.ty-context/**`; Contract, Source, Context and Git content are preserved.
 
 ### Delivery Contract
@@ -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.1.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
 
@@ -163,15 +165,15 @@ Long-Task Contract Authoring 会尽量保留 Source 中已有的稳定 Key 与 A
 
 Agent 此时在实现前只暂停一次，请用户选择：继续当前模型，或切换模型后恢复同一 active Long-Task。如果用户已明确给出本任务的模型策略，则视为已完成选择。后续 `compile --revise` 返回 `required: false`，不会重复暂停。Harness 不会自动切换模型，也不持久化 acknowledgement、model route 或 checkpoint state；模型选择不是验收证据。
 
-锁定后的修订分三类：机器可证明的单调证据增强和机械安全变化自动采用；如果唯一的受保护原因只是扩大 owner、expected-change 或 allowed-support path（可以同时带有安全的单调增强），就能用 `diagnose-revision` 在不切换 Authority 的前提下运行原 Active Authority 已有且未更换的 Check；产品/Source/Acceptance 语义变化、证明弱化、verifier 内容或 runner 变化、风险上升只给摘要，不运行候选，风险降级则直接拒绝。诊断结果不是 Progress 或 acceptance，也不会写 pending/approval、cache、Receipt 或 marker。相关修改只在同一份 `delivery-contract.yaml` 中累计，最终由一次 `compile --revise` 生成带短摘要的精确 hash；`status`/`resume` 投影同一个待批决策。批准并原子采用后旧证据失效，完整 Final Gate 仍必须重跑。
+锁定后的修订分三类：机器可证明的单调证据增强和机械安全变化自动采用；如果唯一的受保护原因只是扩大 owner、expected-change 或 allowed-support path（可以同时带有安全的单调增强），就能用 `diagnose-revision` 在不切换 Authority 的前提下运行原 Active Authority 已有且未更换的 Check；产品/Source/Acceptance 语义变化、证明弱化、verifier 内容或 runner 变化、风险上升只给摘要，不运行候选，风险降级则直接拒绝。滚动实现遇阻本身不是 External Confirmation，也不允许删除机器可验证范围；真正的范围变化必须先成为 marked Source。诊断结果不是 Progress 或 acceptance，也不会写 pending/approval、cache、Receipt 或 marker。相关修改只在同一份 `delivery-contract.yaml` 中累计，最终由一次 `compile --revise` 生成精确 hash 与包含语义字段、Source/Product Claim 缩减、proof 缩减和 external-confirmation key 的短摘要；`status`/`resume` 投影同一个待批决策。批准并原子采用后返回 `delivery_completed_by_this_event: false`，旧证据失效并回到滚动实现或修复，完整 Final Gate 仍必须重跑。
 
 Long-Task Skill 采用渐进读取：主 `SKILL.md` 只保留目标、硬边界和阶段路由，Contract Authoring、Evidence Design 与 Authority Lifecycle 细节只在对应阶段读取一层 reference。这只是指令组织，不产生第二权威。
 
 Draft Outcome 只是 Authority Lock 前的 Outcome。Outcome 按可独立观察、判断和定向验证的结果拆分，使当前 Goal 能缩小 dependency-ready 工作集、定向验证、定位失败、恢复 finding 并精确失效旧局部结果。`depends_on` 只表示 acceptance readiness，Rolling Frontier 只是临时工作状态；Outcome 不是 Worker、scheduler task、queue 或并行单元。Outcome 拆分执行和诊断，不拆分完成权威，因此最终仍必须在当前最终快照运行一次完整 Final Gate。
 
-如果一个声明结果可能在代理表面通过、却在目标运行时独立失败，最早拥有可运行边界的 Outcome 必须声明项目自有的真实运行 Check，并在当前 Check 执行中启动或触达目标、从同一会话产生结构化 Observation。仓库内状态报告、截图、二进制、日志或历史运行不能单独证明目标运行时。当前 Goal 在第一个可运行切片后执行一次；后续相关修改先合并，在声明的 `input_paths` 或 Binding carrier 使 Progress stale 后、扩大依赖工作前再运行。它复用 targeted verify 与 Final Gate，不增加 `platform_impact` 字段或完成状态，不要求每个 Outcome/每次编辑完整重建，也不提前取得接受权；Final Gate 仍会重跑。
+如果一个声明结果可能在代理表面通过、却在目标运行时独立失败，最早拥有可运行边界的 Outcome 必须声明项目自有的真实运行 Check，并在当前 Check 执行中启动或触达目标、从同一会话产生结构化 Observation。仓库内状态报告、截图、二进制、日志或历史运行不能单独证明目标运行时。阻塞驱动的语义或 proof 修订只让受影响的 weak-observability/high-risk 行为 Claim 支付因果审查成本：证据必须到达 Claim 声明的最远独立失败边界；当 carrier 存在不等于能力成立时，Counterfactual 应破坏被声明的能力。当前 Goal 在第一个可运行切片后执行一次；后续相关修改先合并，在声明的 `input_paths` 或 Binding carrier 使 Progress stale 后、扩大依赖工作前再运行。它复用 targeted verify 与 Final Gate，不增加产品 taxonomy、`platform_impact` 字段、全局 runtime 套件或完成状态，不要求每个 Outcome/每次编辑完整重建，也不提前取得接受权；Final Gate 仍会重跑。
 
-平台负责物理 Goal/会话生命周期。新会话通过 `resume` 恢复语义状态；Tiny Context 不会重建此前的物理 Turn。
+平台负责物理 Goal/会话生命周期。新会话通过 `resume` 恢复语义状态；Tiny Context 不会重建此前的物理 Turn。机器接受只覆盖 `declared_machine_authority`，并报告 `native_goal_effect: none`。完成平台原生 Goal 前，Agent 只做一次否决型核对：当前 Goal/用户语义是否全部进入 accepted marked Source，且没有 pending revision、未解 blocker 或遗漏；它只能阻止并触发修复，不能增加验收证据。
 
 ### CLI
 
@@ -195,14 +197,14 @@ ty-context long-task abandon <workdir> [--force-corrupt-state]
 
 - `init` 创建单文件 inline Outcome 的 Compact Contract 模板。
 - `preflight` 应用 Compact 默认值并一次输出 Source/REQ/CTRL/OBL/AC、Context、风险、路径/Binding、Runner/Input 与 Proof 诊断；它完全只读，不创建 Authority Lock、marker、cache、progress、Receipt、pending revision、状态锁，也不运行项目 Check。
-- `compile` 生成 Global 与 Outcome Result/Requirement/Control-field/Non-completing/Technical Claim，拒绝未覆盖 Claim，并让第一次正式成功 Compile 成为 Authority Lock。第一次结果附带 `execution_model_checkpoint.required: true`，后续 Compile 返回 `false`；该字段不进入 Authority state。
+- `compile` 生成 Global 与 Outcome Result/Requirement/Control-field/Non-completing/Technical Claim，拒绝未覆盖 Claim，并让第一次正式成功 Compile 成为 Authority Lock。每次结果都包含 lifecycle event、`delivery_completed_by_this_event: false`、`native_goal_effect: none` 和 next action。第一次结果附带 `execution_model_checkpoint.required: true`，后续 Compile 返回 `false`；这些字段不进入 Authority state。
 - `diagnose-revision` 只做无副作用候选 Compile；仅 scope-only 候选能运行 Active Authority 已有且未更换的 Check，输出固定为非验收、非 Progress、非 pending。
-- `compile --revise` 自动采用可证明安全的修订；受保护修订在 stdout 返回 `authority_revision_pending`、精确 decision id 与确定性短摘要，并继续 fail closed，直到用户批准完全相同的 id。候选内容再变会生成新 id，并使旧批准失效。
+- `compile --revise` 自动采用可证明安全的修订；受保护修订在 stdout 返回 `authority_revision_pending`、精确 decision id 与确定性 material 摘要，并继续 fail closed，直到用户批准完全相同的 id。候选内容再变会生成新 id，并使旧批准失效。采用后输出 `authority_revision_adopted` 并回到滚动执行，不表示交付完成。
 - `verify` 在重查 active task/revision/compiled/worktree identity 后写 scoped Progress；targeted verify 始终只是修复证据。
 - `status` 输出 `unverified`、`progress_passing`、`progress_failing`、`progress_stale` 或 `blocked_external`，并报告 fresh `final_workflow_status`、完整 `external_confirmations` 与唯一的 `pending_authority_revision`。`progress_passing` 只能表述为定向修复证据，不能简称“Outcome 完成”；`progress_stale` 不是当前通过，`final_workflow_status: null` 表示 Goal 尚未完成。
 - `resume` 完全只读，恢复 task/contract identity、风险、相关 Context、Git 状态、同一待批决策、ready Outcome、findings 和 next safe action。
 - `final-gate` 在完整 Check 后再次验证 active identity；并发 revision 不能产生 accepted。
-- `stop-check` 与 `close` 自己运行 Live Final Gate，并只用 accepted identity 做 CAS clear。`status: closed` 只表示机器 Authority 已清理，不表示完整外部交付完成。
+- `stop-check` 与 `close` 自己运行 Live Final Gate，并只用 accepted identity 做 CAS clear。每次机器接受的 Stop 都给一个非阻塞 terminal-scope `systemMessage`；外部待确认时同时列出全部确认项。Final/Stop/close 输出 `acceptance_scope: declared_machine_authority` 与 `native_goal_effect: none`，close 另输出 `closed_scope: machine_authority`。`status: closed` 只表示机器 Authority 已清理，不表示原生 Goal 或完整外部交付完成。
 - `abandon --force-corrupt-state` 仅用于损坏/mismatch/legacy-unrecoverable 状态或遗留锁，只删除确定性 active state 与 `<workdir>/.ty-context/**`。
 
 ### Delivery Contract

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.
@@ -35,14 +35,14 @@ After the first Authority Lock, stop once before implementation and ask the user
 
 Before authoring, proof design or authority lifecycle work, read the phase-specific references in the package-managed `long-task-workflow` Skill. Use `ty-context long-task help` for CLI syntax instead of treating this startup router as a command reference.
 
-Final Gate, Stop and close recompile the source Contract and rerun every declared Check on one clean current snapshot. Targeted verify is repair evidence only. Status, progress, receipts and compiled cache are audit/recovery surfaces only; prose, historical tests or Agent judgment never create acceptance. External confirmations remain explicit and machine acceptance never implies CI, deployment or human acceptance.
+Final Gate, Stop and close recompile the source Contract and rerun every declared Check on one clean current snapshot. Targeted verify is repair evidence only. Status, progress, receipts and compiled cache are audit/recovery surfaces only; prose, historical tests or Agent judgment never create acceptance. An adopted Authority Revision returns to rolling execution and is never delivery completion. External confirmations remain explicit; machine acceptance covers declared machine Authority and cannot by itself authorize completing the platform-native Goal, CI, deployment or human acceptance.
 
 Tiny Context does not create or restore platform Goals, invoke models, spawn agents, call an App Server, create branches/worktrees, merge, push, open PRs, deploy or manage process trees. `ty-context enable long-task` installs the Source Plan Authoring Skill, Long-Task Workflow Skill and package-owned completion Hook.
 
 ## 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

@@ -9,7 +9,7 @@ description: Author, preflight, execute, resume, verify, or close one complete S
 
 Use one current native Goal, one repository, one selected workspace, one complete Contract and one Final Gate. Never create a scheduler, model worker, agent runtime, App Server, branch, worktree, merge, push, PR, deployment, Campaign/SFC/Packet/Wave chain, matrix, verdict or second Contract plan. Never activate from task size alone.
 
-The host and user own model selection. The workflow has exactly one user-choice checkpoint after the first Authority Lock and before implementation; Harness neither switches the model nor persists model-routing/checkpoint state. No checkpoint file, acknowledgement state, model route, model-tier scheduler or automatic model switch is created. Outside that boundary, do not pause a healthy Goal solely to change or downgrade the model. Do not create a separate approval checkpoint for a defensible recommended plan choice. A targeted pre-Authority clarification is still required when a missing user preference could materially change research or selection; genuine Source conflicts or choices the user explicitly reserves may likewise require a decision before Authority Lock. Capability-related drift is handled by targeted repair plus the Final Gate. Never proactively spawn, assign or coordinate parallel subagents. Platform-native internal delegation, if it occurs, is opaque and non-authoritative and must converge into the unified current workspace snapshot before verification can count.
+The host and user own model selection and native-Goal lifecycle. The workflow has exactly one user-choice checkpoint after the first Authority Lock and before implementation; Harness neither switches the model nor persists model-routing/checkpoint state. No checkpoint file, acknowledgement state, model route, model-tier scheduler, automatic model switch, `authority_revision_in_progress` state or native-Goal completion state is created. Outside that boundary, do not pause a healthy Goal solely to change or downgrade the model. Do not create a separate approval checkpoint for a defensible recommended plan choice. A targeted pre-Authority clarification is still required when a missing user preference could materially change research or selection; genuine Source conflicts or choices the user explicitly reserves may likewise require a decision before Authority Lock. Capability-related drift is handled by targeted repair plus the Final Gate. Never proactively spawn, assign or coordinate parallel subagents. Platform-native internal delegation, if it occurs, is opaque and non-authoritative and must converge into the unified current workspace snapshot before verification can count.
 
 `long-task-delivery-v2` is the only active Contract schema. `delivery-contract.yaml` is the root authoring file. New authoring uses inline Outcomes; existing `outcome_files` are physical compatibility only. `delivery-set` is retired and non-executing.
 
@@ -17,7 +17,7 @@ The host and user own model selection. The workflow has exactly one user-choice
 
 Prevent false completion inside declared authority. Implementation may drift, fail or require rework, but every declared non-Result requirement and AC must remain traceable and every unsatisfied, unverifiable, insufficiently evidenced or stale item must block completion. Findings should localize repair through Source Item, Outcome, Claim, Assertion, Check, Proof Surface, Binding and owner boundary.
 
-Only fresh evidence from the complete current final snapshot may create machine acceptance. Otherwise report the task as unfinished or qualified. `machine_accepted_external_pending` means machine-verifiable authority passed while named external confirmation remains; it is not full delivery completion. Never substitute prose, progress, historical tests, Receipts, one exit code or Agent judgment for the Final Gate.
+Only fresh evidence from the complete current final snapshot may create machine acceptance. Otherwise report the task as unfinished or qualified. `machine_accepted_external_pending` means machine-verifiable authority passed while named external confirmation remains; it is not full delivery completion. Machine acceptance covers declared machine Authority and has no direct native-Goal effect. Never substitute prose, progress, historical tests, Receipts, one exit code or Agent judgment for the Final Gate.
 
 Prefer the lowest practical Authoring, Runtime, State, Recovery and verification cost that preserves the same false-completion interception. Add no mechanism whose distinct protection does not materially exceed its total cost.
 
@@ -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.
@@ -66,7 +67,7 @@ Use targeted `verify --outcome/--check` only to drive repair. Progress is repair
 
 When the Contract declares a target-runtime Check because a proxy can pass while the target fails independently, run it at the earliest owning Outcome's first runnable boundary. After accumulated changes to its declared `input_paths` or Binding carriers make the result stale, rerun it before dependent work grows. Coalesce related edits and use the cheapest reliable target Check; do not mandate a full environment rebuild per Outcome or per edit. This is rolling feedback through existing targeted verify, not acceptance, a trigger queue, platform taxonomy or new state.
 
-When implementation discovers missing Contract paths, first classify the revision. Proven monotonic evidence strengthening may use ordinary `compile --revise` directly. If every protected reason is only owner/expected-change/allowed-support expansion, continue editing the same `delivery-contract.yaml` and use `ty-context long-task diagnose-revision <workdir> [--outcome <key>] [--check <key>]` to exercise only existing active Check identities with unchanged runner/verifier authority; safe monotonic strengthening may coexist. Candidate diagnostics are transient: they authorize no acceptance and write no pending/approval state, Active Authority, cache, Progress or Receipt. Semantic changes, proof weakening, runner or verifier-content changes, and risk-increase candidates are preview-only and must not run; risk downgrade is rejected. When the candidate is complete, run ordinary `compile --revise` once, present its exact concise decision summary to the user, and never approve it yourself. Keep the previous Authority active until exact approval and atomic adoption; after adoption, discard historical/candidate evidence and require the complete Final Gate.
+When implementation discovers a blocker or missing Contract paths, first classify the revision. Difficulty or delay alone never reclassifies machine-verifiable scope as external and never removes Source; a real scope, Product, Acceptance or machine/external boundary change must first be explicit marked Source. Proven monotonic evidence strengthening may use ordinary `compile --revise` directly. If every protected reason is only owner/expected-change/allowed-support expansion, continue editing the same `delivery-contract.yaml` and use `ty-context long-task diagnose-revision <workdir> [--outcome <key>] [--check <key>]` to exercise only existing active Check identities with unchanged runner/verifier authority; safe monotonic strengthening may coexist. Candidate diagnostics are transient: they authorize no acceptance and write no pending/approval state, Active Authority, cache, Progress or Receipt. Semantic changes, proof weakening, runner or verifier-content changes, and risk-increase candidates are preview-only and must not run; risk downgrade is rejected. When the candidate is complete, run ordinary `compile --revise` once, present its exact material decision summary to the user, and never approve it yourself. Keep the previous Authority active until exact approval and atomic adoption. Adoption is not delivery completion: discard historical/candidate evidence, run `status` or `resume`, and return to rolling implementation or repair under the revised Authority before Final Gate.
 
 ## Live Final Authority
 
@@ -74,8 +75,10 @@ Complete Context, implementation and project tests, create a clean candidate com
 
 Final Gate recompiles Source authority, validates active task/revision/compiled/worktree identity, creates one Git-tree snapshot, reruns every required Global and Outcome Check and rechecks active identity before acceptance. A target-runtime Check must exercise its target in that current Gate execution; rerunning a reader for a historical or tracked status report is not live target proof. Final Gate, Stop and close never trust historical Progress, Receipt or compiled cache.
 
-Machine acceptance covers only declared machine authority. Preserve every pending external confirmation through `final-gate`, `status`, `resume`, `stop-check`, the package-owned Stop Hook and `close`; `closed` means only machine Authority cleanup. Do not invent external-confirmation tracking state.
+Machine acceptance covers only declared machine authority. Preserve every pending external confirmation through `final-gate`, `status`, `resume`, `stop-check`, the package-owned Stop Hook and `close`; accepted output identifies `acceptance_scope: declared_machine_authority` and `native_goal_effect: none`, while `closed_scope: machine_authority` means only Authority cleanup. Do not invent external-confirmation or native-Goal tracking state.
+
+Before invoking platform-native Goal completion, perform one veto-only conformance review: compare the current Goal and user instructions with accepted marked Source, and check for pending revisions, unresolved blockers or omitted requirements. Any mismatch keeps the Goal active and returns to Source/Contract repair. A clean review does not add acceptance proof and never lets Agent judgment replace Final Gate.
 
 ## Handoff
 
-Report implementation, effective risk, Claim Coverage, Live Gate result, every pending external confirmation, Context status and blockers. Use verifier terms exactly: `progress_passing` means targeted repair evidence, `progress_stale` is not a current pass, `final_workflow_status: null` means unfinished, and `machine_accepted_external_pending` must retain its named confirmations. Never shorten implementation or targeted progress to “Outcome complete” or invent `implementation_complete`, `platform_smoke_verified` or another persistent status. State the threat-model limits: undeclared requirements cannot be discovered, installed verifier/Git metadata are trusted, model selection belongs to the host/user, and internal platform delegation is not observed.
+Report implementation, effective risk, Claim Coverage, Live Gate result, acceptance scope, every pending external confirmation, Context status and blockers. Use verifier terms exactly: `progress_passing` means targeted repair evidence, `progress_stale` is not a current pass, `final_workflow_status: null` means unfinished, `authority_revision_adopted` means return to rolling execution, and `machine_accepted_external_pending` must retain its named confirmations. Never shorten implementation or targeted progress to “Outcome complete” or invent `implementation_complete`, `platform_smoke_verified` or another persistent status. State the threat-model limits: undeclared requirements cannot be discovered, installed verifier/Git metadata are trusted, native-Goal/model selection belongs to the host/user, and internal platform delegation is not observed.

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

@@ -24,7 +24,7 @@ After Authority Lock, every revision compares against active authority and follo
 
 `diagnose-revision` recompiles the same `delivery-contract.yaml` in memory, creates only a disposable workspace snapshot when class 2 is proven, and returns transient repair results with `acceptance_authorized: false`. It writes no pending/approval state, authority/marker, cache, Progress or Receipt. Repeated edits therefore accumulate only in the one existing Contract authoring file, not a pending Draft authority or candidate state plane.
 
-Ordinary `compile --revise` is the only operation that may create the one pending decision. It binds a deterministic concise change summary into the revision identity. `status` and `resume` expose that same decision so the host can deduplicate the user prompt without a Harness-owned waiting state. The executing Agent never approves its own pending revision; earlier blanket authorization cannot approve a later exact identity. If the candidate changes, the identity changes and old approval is rejected. The previous Authority remains active until approved compare-and-swap adoption, which invalidates derived evidence and leaves the complete source-recompiled Final Gate mandatory.
+Ordinary `compile --revise` is the only operation that may create the one pending decision. It binds a deterministic concise change summary into the revision identity and enumerates changed semantic fields, Source/Product Claim reductions, proof reductions and external-confirmation keys. `status` and `resume` expose that same decision so the host can deduplicate the user prompt without a Harness-owned waiting state. The executing Agent never approves its own pending revision; earlier blanket authorization cannot approve a later exact identity. If the candidate changes, the identity changes and old approval is rejected. The previous Authority remains active until approved compare-and-swap adoption. Adoption reports `delivery_completed_by_this_event: false`, invalidates affected evidence and returns to rolling implementation or repair under the revised Authority; the complete source-recompiled Final Gate remains mandatory.
 
 Every path-bearing field uses canonical grammar. Internal `.`/`..`, control characters, empty segments, absolute/drive/UNC paths and unsupported glob syntax fail closed.
 
@@ -48,6 +48,8 @@ Report their exact meaning: `progress_passing` is current targeted repair eviden
 
 Before Final Gate, complete Context/code/tests and create a clean candidate commit. Final Gate captures active identity, recompiles Source authority, reads complete current Context, validates common-dir record/marker, creates a Git-tree snapshot, reruns all Checks and sensitivity controls and rechecks identity before acceptance. A target-runtime Check must exercise its target again in that Final Gate execution; rereading historical status does not become live proof merely because the reader reran. A concurrent revision returns `active_authority_changed_during_final_gate`.
 
-Commit, verifier migration, clear and abandon share one active-state lock. Stop/close clear only the identity actually accepted through CAS and preserve `machine_accepted_external_pending` plus every named external confirmation in output. A stale Receipt exposes no accepted workflow status.
+Commit, verifier migration, clear and abandon share one active-state lock. Stop/close clear only the identity actually accepted through CAS and preserve `machine_accepted_external_pending` plus every named external confirmation in output. Final Gate/Stop/close identify `acceptance_scope: declared_machine_authority` and `native_goal_effect: none`; close additionally identifies `closed_scope: machine_authority`. The Stop Hook emits the same scope as one non-blocking message for either accepted machine status. A stale Receipt exposes no accepted workflow status.
+
+Before platform-native Goal completion, compare current Goal/user meaning with accepted marked Source and check for a pending revision, unresolved blocker or omitted requirement. This review may only veto completion and direct Source/Contract repair; it is not a second acceptance Gate and cannot create proof.
 
 For invalid, mismatched, unrecoverable or stale-lock continuity, use only `ty-context long-task abandon <workdir> --force-corrupt-state`; it preserves authored Contract, Source, Context and Git content.

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

@@ -13,6 +13,7 @@ Read this only while authoring or structurally revising the one `delivery-contra
 - `delegated` in a Source Plan is provenance, not a Contract disposition or new Claim kind. An instruction to synthesize, refine, complete, implement or use judgment delegates plan-level authoring, but it does not invent material tradeoff preferences. Before comparative research or a material product, technical, architecture or provider selection, identify the criteria that could change the research scope, candidate set or recommendation. If such a preference is unknown or ambiguous, ask a concise targeted question before research or selection and keep the item `decision_required` until answered; do not impose a fixed questionnaire or re-ask preferences already supplied by the user, Source, Context or controlling constraints.
 - Once the material preference envelope is clear, use current authoritative or primary evidence for external capability, price, quota, license, compatibility, region, security posture or support claims. When one defensible recommendation exists, record the authoring instruction, preference/evidence or conservative-default basis and exact added meaning in real Source, then preserve that keyed item as ordinary Source of its semantic kind. If ordinary prose is the Source, append the delegated item without rewriting the user's original text; never place the choice only in Contract YAML.
 - A delegated plan choice is not action authorization. Payment, contracting, production deployment/publication, destructive production mutation, real permission grants, sensitive-data transmission and required legal/security/human approval remain named External Confirmations. Conflicting authority, an explicitly user-reserved choice, a missing material preference or the absence of a defensible recommendation remains `decision_required`; high impact or multiple options with known criteria alone does not.
+- A rolling implementation blocker is not an External Confirmation merely because work is difficult, delayed or unavailable through the current implementation path. Reclassify or remove machine-verifiable scope only through an explicit marked Source change and protected exact approval; otherwise keep the requirement and revise the implementation/evidence path.
 
 ## Outcome Boundary
 
@@ -60,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

@@ -25,6 +25,13 @@ Across all Checks sharing a Raw Execution, one Claim-bearing Observation belongs
 - Historical reports, screenshots, binaries and logs are review material. Current-run screenshots/logs may accompany a Check as Artifacts, but the accepting Observation must come from the live runner execution and cannot be imported from historical state.
 - Bind every runtime-affecting implementation surface through `input_paths` and relevant Binding carriers; keep runner/helper/config files in `verification_inputs`. This lets existing Progress freshness identify when rolling feedback is stale without a new trigger registry.
 
+## Causal Boundary Review After Revision
+
+- When a rolling blocker causes a semantic or proof revision, review only the affected weak-observability or high-risk Outcomes before adoption. Ask whether a cheaper proxy, fixed response or self-reported success could pass while the declared result still fails at a farther independent boundary.
+- Evidence must reach the furthest independently failing boundary named by the Claim. A proxy may prove its own result, but it cannot prove a downstream state or effect merely by reporting success.
+- For a behavioral Claim, prefer a Counterfactual that disrupts the claimed causal capability when removing a carrier would prove only file dependence. `replace_file` may supply a declared inert/failing implementation fixture; `remove_paths` remains valid when carrier existence is itself the claimed boundary.
+- Keep this risk-proportional and internal. Do not create an evidence matrix, product-effect taxonomy, universal restart/end-to-end suite, new mutation type or persistent review state.
+
 ## Playwright
 
 Claim-bearing Playwright proof is only `playwright.case.<ac-key>.passed equals true`. `[ac:<assertion-key>]` binds one declared AC per Test Instance; ordinary tags are ignored and legacy `[<key>]` binds only a declared key.
@@ -38,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/commands/long-task-revision.js

@@ -63,8 +63,21 @@ async function compile(workdir, args) {
         await clearFinalReceipt(compiled.repository_root, workdir);
     }
     await clearAuthorityRevision(workdir);
+    printCompileResult(compiled, previous, preserveProgress, revisionCapture.proposal);
+}
+function printCompileResult(compiled, previous, preserveProgress, revisionProposal) {
+    const firstAuthorityLock = previous === null;
+    const authorityChanged = previous !== null &&
+        previous.compiled_identity !== compiled.compiled_identity;
     console.log(JSON.stringify({
         status: "compiled",
+        lifecycle_event: firstAuthorityLock
+            ? "authority_locked"
+            : authorityChanged
+                ? "authority_revision_adopted"
+                : "authority_recompiled_unchanged",
+        delivery_completed_by_this_event: false,
+        native_goal_effect: "none",
         task_id: compiled.task.id,
         compiled_identity: compiled.compiled_identity,
         authority_revision: compiled.authority_revision,
@@ -72,10 +85,15 @@ async function compile(workdir, args) {
         outcomes: compiled.outcomes.map((outcome) => outcome.key),
         claim_coverage: compiled.claim_coverage,
         progress_preserved: preserveProgress,
-        authority_revision_change: revisionCapture.proposal
-            ? projectAuthorityRevisionDecision(revisionCapture.proposal)
+        authority_revision_change: revisionProposal
+            ? projectAuthorityRevisionDecision(revisionProposal)
             : null,
-        execution_model_checkpoint: executionModelCheckpoint(previous === null),
+        next_action: firstAuthorityLock
+            ? "Complete the one-time model choice, then begin rolling implementation."
+            : authorityChanged
+                ? "Run status or resume, then continue rolling implementation or repair under the adopted Authority Revision."
+                : "Continue rolling implementation or repair under the active Authority.",
+        execution_model_checkpoint: executionModelCheckpoint(firstAuthorityLock),
     }));
 }
 async function compileForCommand(workdir, revise, previous, capture) {
@@ -101,8 +119,11 @@ async function printPendingDecision(workdir, previous) {
     console.log(JSON.stringify({
         status: "authority_revision_pending",
         acceptance_authorized: false,
+        delivery_completed_by_this_event: false,
+        native_goal_effect: "none",
         active_compiled_identity: previous?.compiled_identity ?? null,
         pending_authority_revision: projectAuthorityRevisionDecision(pending),
+        next_action: "Ask the user to approve or reject this exact material revision; keep the previous Authority active.",
     }));
 }
 async function diagnoseRevision(workdir, args) {
@@ -120,7 +141,13 @@ async function approveRevision(workdir, args) {
     if (!revision)
         throw new Error("--revision requires a value");
     await approvePendingAuthorityRevision(workdir, revision);
-    console.log(JSON.stringify({ status: "authority_revision_approved", revision }));
+    console.log(JSON.stringify({
+        status: "authority_revision_approved",
+        revision,
+        delivery_completed_by_this_event: false,
+        native_goal_effect: "none",
+        next_action: "Run compile --revise to atomically adopt the approved revision, then return to rolling implementation or repair.",
+    }));
 }
 function executionModelCheckpoint(firstAuthorityLock) {
     if (!firstAuthorityLock)

package/dist/commands/long-task.js

@@ -68,6 +68,9 @@ export async function longTask(args) {
             workdir,
             workflow_status: result.workflow_status,
             external_confirmations: result.external_confirmations,
+            acceptance_scope: result.acceptance_scope,
+            closed_scope: result.closed_scope,
+            native_goal_effect: result.native_goal_effect,
         }));
         return;
     }
@@ -101,7 +104,11 @@ async function verify(workdir, args) {
 async function finalGate(workdir, args) {
     rejectUnknown(args, []);
     const result = await runDeliveryFinalGate(workdir);
-    console.log(JSON.stringify(result));
+    console.log(JSON.stringify({
+        ...result,
+        acceptance_scope: "declared_machine_authority",
+        native_goal_effect: "none",
+    }));
     if (result.workflow_status !== "machine_accepted" &&
         result.workflow_status !== "machine_accepted_external_pending")
         process.exitCode = 1;

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/dist/lib/long-task-authority-revision-summary.js

@@ -57,6 +57,21 @@ export function summarizeAuthorityRevision(diff, outcomeKeys) {
         write_scope_expanded: diff.owner_or_path_boundary_changed,
         risk_changed: diff.risk_changed,
         external_confirmations_changed: diff.external_confirmations_changed,
+        semantic_fields_changed: uniqueSorted([
+            ...diff.product_semantics_changed,
+            ...diff.global_semantics_changed,
+        ]),
+        source_claim_changes: uniqueSorted([
+            ...diff.source_claims_added,
+            ...diff.source_claims_removed_or_changed,
+        ]),
+        product_claim_changes: uniqueSorted([
+            ...diff.product_claims_added.map((claim) => `${claim}:added`),
+            ...diff.product_claims_removed.map((claim) => `${claim}:removed`),
+            ...diff.product_claims_changed.map((claim) => `${claim}:changed`),
+        ]),
+        proof_reductions: uniqueSorted(diff.reduction_reasons.filter((reason) => PROOF_REDUCTION_REASONS.has(reason))),
+        external_confirmation_changes: uniqueSorted(diff.external_confirmation_changes),
         added_verification_dependencies: uniqueSorted([
             ...diff.verification_inputs_added,
             ...diff.input_paths_added,
@@ -76,13 +91,29 @@ export function projectAuthorityRevisionDecision(value) {
         verification_inputs_added: value.revision_diff.verification_inputs_added ?? [],
         input_paths_added: value.revision_diff.input_paths_added ?? [],
         external_confirmations_changed: value.revision_diff.external_confirmations_changed ?? false,
+        external_confirmation_changes: value.revision_diff.external_confirmation_changes ?? [],
     };
+    const computedSummary = summarizeAuthorityRevision(diff, value.affected_outcomes_or_contracts);
+    const storedSummary = value.approval_summary;
     return {
         revision_identity: value.revision_identity,
         change_class: value.change_class ?? classifyAuthorityRevision(diff),
         approval_required: value.approval_required ?? true,
-        approval_summary: value.approval_summary ??
-            summarizeAuthorityRevision(diff, value.affected_outcomes_or_contracts),
+        approval_summary: storedSummary
+            ? {
+                ...computedSummary,
+                ...storedSummary,
+                semantic_fields_changed: storedSummary.semantic_fields_changed ??
+                    computedSummary.semantic_fields_changed,
+                source_claim_changes: storedSummary.source_claim_changes ??
+                    computedSummary.source_claim_changes,
+                product_claim_changes: storedSummary.product_claim_changes ??
+                    computedSummary.product_claim_changes,
+                proof_reductions: storedSummary.proof_reductions ?? computedSummary.proof_reductions,
+                external_confirmation_changes: storedSummary.external_confirmation_changes ??
+                    computedSummary.external_confirmation_changes,
+            }
+            : computedSummary,
     };
 }
 function scopeAffectedOutcomes(diff) {

package/dist/lib/long-task-authority-revision-types.d.ts

@@ -10,6 +10,11 @@ export interface AuthorityRevisionApprovalSummaryV2 {
     write_scope_expanded: boolean;
     risk_changed: boolean;
     external_confirmations_changed: boolean;
+    semantic_fields_changed: string[];
+    source_claim_changes: string[];
+    product_claim_changes: string[];
+    proof_reductions: string[];
+    external_confirmation_changes: string[];
     added_verification_dependencies: string[];
     expanded_owner_paths: string[];
     expanded_expected_change_paths: string[];
@@ -79,6 +84,7 @@ export interface AuthorityRevisionDiffV2 {
     counterfactuals_removed: string[];
     population_weakened: string[];
     external_confirmations_changed: boolean;
+    external_confirmation_changes: string[];
     verifier_content_changed: boolean;
     verifier_runtime_locator_changed: boolean;
     verifier_files_changed: string[];

package/dist/lib/long-task-authority-revision.js

@@ -80,7 +80,8 @@ export function authorityRevisionDiff(previous, next, nextHashes, nextMaterials,
     const riskChanged = previous.authority_hashes.risk_authority_hash !==
         nextHashes.risk_authority_hash;
     const acceptanceChanged = acceptanceSemanticsChanged(previous, next);
-    const externalConfirmationsChanged = !same(previous.global.acceptance.external_confirmations, next.global.acceptance.external_confirmations);
+    const externalConfirmationChanges = keyedAuthorityChanges(previous.global.acceptance.external_confirmations, next.global.acceptance.external_confirmations);
+    const externalConfirmationsChanged = externalConfirmationChanges.length > 0;
     const monotonic = isMonotonicAcceptanceStrengthening(previous, next);
     const reductionReasons = [
         ...(productClaimsAdded.length ? ["product_claim_added"] : []),
@@ -175,6 +176,7 @@ export function authorityRevisionDiff(previous, next, nextHashes, nextMaterials,
         counterfactuals_removed: counterfactualsRemoved,
         population_weakened: populationWeakened,
         external_confirmations_changed: externalConfirmationsChanged,
+        external_confirmation_changes: externalConfirmationChanges,
         ...verifierDiff,
         source_claims_changed: previous.authority_hashes.source_authority_hash !==
             nextHashes.source_authority_hash,
@@ -194,3 +196,21 @@ export function authorityRevisionDiff(previous, next, nextHashes, nextMaterials,
         reduction_reasons: [...new Set(reductionReasons)],
     };
 }
+function keyedAuthorityChanges(before, after) {
+    const beforeByKey = new Map(before.map((item) => [item.key, item]));
+    const afterByKey = new Map(after.map((item) => [item.key, item]));
+    return [
+        ...before
+            .filter((item) => !afterByKey.has(item.key))
+            .map((item) => `${item.key}:removed`),
+        ...after
+            .filter((item) => !beforeByKey.has(item.key))
+            .map((item) => `${item.key}:added`),
+        ...before
+            .filter((item) => {
+            const candidate = afterByKey.get(item.key);
+            return candidate !== undefined && !same(item, candidate);
+        })
+            .map((item) => `${item.key}:changed`),
+    ].sort();
+}

package/dist/lib/long-task-status-v2.d.ts

@@ -8,6 +8,8 @@ export interface DeliveryStatusV2 {
     effective_risk: "standard" | "strict";
     workspace_snapshot_sha256: string;
     acceptance_authority: "live_final_gate_required";
+    acceptance_scope: "declared_machine_authority";
+    native_goal_effect: "none";
     final_result: AuditGateStatusV2;
     final_workflow_status: FinalReceiptV2["workflow_status"] | null;
     external_confirmations: ExternalConfirmationV2[];
@@ -29,11 +31,16 @@ export interface StopCheckDeliveryResultV2 {
     reason: string;
     workflow_status?: FinalReceiptV2["workflow_status"];
     external_confirmations?: ExternalConfirmationV2[];
+    acceptance_scope?: "declared_machine_authority";
+    native_goal_effect?: "none";
     message?: string;
 }
 export interface CloseDeliveryResultV2 {
     status: "closed";
     workflow_status: Extract<FinalReceiptV2["workflow_status"], "machine_accepted" | "machine_accepted_external_pending">;
     external_confirmations: ExternalConfirmationV2[];
+    acceptance_scope: "declared_machine_authority";
+    closed_scope: "machine_authority";
+    native_goal_effect: "none";
 }
 export declare function closeDeliveryTask(workdir: string): Promise<CloseDeliveryResultV2>;

package/dist/lib/long-task-status-v2.js

@@ -48,6 +48,8 @@ async function readDeliveryStatusForAuthority(active) {
         effective_risk: compiled.effective_risk,
         workspace_snapshot_sha256: current.snapshot_sha256,
         acceptance_authority: "live_final_gate_required",
+        acceptance_scope: "declared_machine_authority",
+        native_goal_effect: "none",
         final_result: projection.finalResult,
         final_workflow_status: projection.finalWorkflowStatus,
         external_confirmations: compiled.global.acceptance.external_confirmations,
@@ -94,6 +96,8 @@ export async function resumeDeliveryTask(workdir) {
         context_refs: compiled.task.context_refs,
         git,
         acceptance_authority: "live_final_gate_required",
+        acceptance_scope: "declared_machine_authority",
+        native_goal_effect: "none",
         last_gate: status.final_result,
         final_workflow_status: status.final_workflow_status,
         external_confirmations: status.external_confirmations,
@@ -221,11 +225,9 @@ export async function stopCheckDeliveryTask(workdirInput, messageText = "") {
                 reason: result.workflow_status,
                 workflow_status: result.workflow_status,
                 external_confirmations: result.external_confirmations,
-                ...(result.workflow_status === "machine_accepted_external_pending"
-                    ? {
-                        message: externalPendingMessage(result.external_confirmations),
-                    }
-                    : {}),
+                acceptance_scope: "declared_machine_authority",
+                native_goal_effect: "none",
+                message: acceptedScopeMessage(result.workflow_status, result.external_confirmations),
             };
         }
         return {
@@ -272,13 +274,19 @@ export async function closeDeliveryTask(workdir) {
         status: "closed",
         workflow_status: result.workflow_status,
         external_confirmations: result.external_confirmations,
+        acceptance_scope: "declared_machine_authority",
+        closed_scope: "machine_authority",
+        native_goal_effect: "none",
     };
 }
-function externalPendingMessage(confirmations) {
+function acceptedScopeMessage(workflowStatus, confirmations) {
+    const scope = "Declared machine Authority accepted and cleared. This result has no direct effect on the platform-native Goal; before completing it, confirm current Goal/user meaning is fully represented by accepted Source and no revision, blocker, or omitted requirement remains.";
+    if (workflowStatus === "machine_accepted")
+        return scope;
     const pending = confirmations
         .map((confirmation) => `${confirmation.key} (${confirmation.owner})`)
         .join(", ");
-    return `Machine-verifiable scope accepted. Complete external delivery remains pending: ${pending}. Do not report complete external delivery.`;
+    return `${scope} Complete external delivery remains pending: ${pending}. Do not report complete external delivery.`;
 }
 function nextAction(status) {
     if (status.pending_authority_revision)

package/package.json

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