project-tiny-context-harness 0.6.1 → 0.7.0

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.6.1.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.7.0.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -199,7 +199,7 @@ An explicit Long-Task uses its existing Requirement, Control, Assertion, `ui_bro
 
 Use `/source-plan-authoring` for an explicitly requested initial plan, Source Plan, source draft, or synthesis/refinement/audit of later implementation or Contract-authoring Source. It accepts either one substantially complete plan or a sparse goal plus mixed notes, product/technical documents, screenshots, diagrams and other attachments; a short instruction identifying their roles, the goal, reference authority and desired elaboration is sufficient.
 
-It produces one self-contained Markdown document with a complete input inventory, preserved direct requirements, traceable necessary derivations and explicitly delegated low-impact/reversible product choices. Unsupported high-impact choices remain `DEC`/`decision_required`. Interactive products are expanded through every in-scope surface to material control level, including placement, behavior, validation, navigation, loading/empty/success/failure/recovery/permission feedback and accessibility. The plan retains semantic Outcome boundaries, stable keys/anchors, Runtime-exact Fact/Affected-Outcome `RISK` items, distinct `OBL`/`HINT` items and one observable scenario per `AC` with explicit accepted `REQ`/`CTRL`/`OBL`/`NCOMP` keys. Risk names are the ten Contract facts: use `data_migration`, split critical-path weak observability into `critical_user_path` plus `weak_observability`, and preserve `multi_repository_change` for Compiler rejection.
+It produces one self-contained Markdown document with a complete input inventory, preserved direct requirements and traceable necessary derivations. Before comparative research or a material product, technical, architecture or provider selection, it asks a concise targeted question when an unknown user priority such as quality versus cost, speed, reliability, privacy, lock-in or operational burden could change the research scope, candidate set or recommendation; there is no fixed questionnaire and known preferences are not re-asked. Once that preference envelope is clear, it decides what research is needed and uses current authoritative or primary sources for external capability, price, quota, license, compatibility, region, security or support claims. A request to synthesize, refine, complete or use judgment then delegates plan-level authoring: each supported recommendation is recorded as `delegated` with its instruction, preference/evidence basis and exact meaning instead of triggering approval, including high-impact plan semantics. Real payment, contracting, production release, destructive production mutation, permission grants, sensitive-data transmission and required legal/security/human approval remain `EXT`; only conflicts, user-reserved choices, missing material preferences or cases with no defensible recommendation remain `DEC`/`decision_required`. Interactive products are expanded through every in-scope surface to material control level, including placement, behavior, validation, navigation, loading/empty/success/failure/recovery/permission feedback and accessibility. The plan retains semantic Outcome boundaries, stable keys/anchors, Runtime-exact Fact/Affected-Outcome `RISK` items, distinct `OBL`/`HINT` items and one observable scenario per `AC` with explicit accepted `REQ`/`CTRL`/`OBL`/`NCOMP` keys. Risk names are the ten Contract facts: use `data_migration`, split critical-path weak observability into `critical_user_path` plus `weak_observability`, and preserve `multi_repository_change` for Compiler rejection.
 
 It does not update Context, bind a repository, generate Delivery Contract YAML, execute implementation, create workflow state or claim completion. `HINT` is not a Material Source Item, and the Skill emits no `ty-source-item` markers. A Source Plan is Source, not a Contract Draft. The structure is optional; ordinary prose remains valid Long-Task Source.
 
@@ -207,7 +207,7 @@ It does not update Context, bind a repository, generate Delivery Contract YAML,
 
 The explicit Long-Task Workflow uses one platform-native Goal, one user-selected repository/workspace, one complete `long-task-delivery-v2` Contract and one Final Gate. Outcomes are independently decidable acceptance units; Delivery Set orchestration and top-level Contract splitting inside one selected delivery are retired.
 
-Contract authoring preserves stable Source keys/anchors where practical. A product choice already recorded in Source under explicit user delegation remains ordinary Source meaning, but Contract authoring cannot extend that delegation. Meaning-preserving structural decomposition and evidence-backed repository binding may continue, while any other new product semantics require `decision_required`. Missing recommended Source Plan structure alone never blocks authoring.
+Contract authoring preserves stable Source keys/anchors where practical. If an unknown preference could materially change comparative research or selection, it asks before proceeding. Once the decision criteria are clear, a defensible recommended plan choice is recorded in real Source with its delegation, preference/evidence basis and exact meaning before Contract mapping; it is never added only in YAML. Plan delegation does not authorize a real high-risk external action, which remains an explicit external confirmation. Meaning-preserving structural decomposition and evidence-backed repository binding may continue, while conflicting, user-reserved, missing-preference or unsupported new product semantics require `decision_required`. Missing recommended Source Plan structure alone never blocks authoring.
 
 Before the first successful formal Compile, `delivery-contract.yaml` is one non-authoritative Contract Draft. `/long-task-workflow` revises the same Draft across repository/Context reads and Preflight repairs; a complete Contract need not fit one response. Integrated authoring keeps repository evidence and findings attached to the same object and avoids a second handoff, plan, authority or Receipt. There is no standalone Contract Draft Skill or Authoring State.
 
@@ -229,16 +229,19 @@ The first successful Compile creates Authority Lock and returns:
 }
 ```
 
-Before product implementation, the Agent asks the user to continue with the current model or switch models and then resume the active Long-Task. A task-specific model choice already stated explicitly satisfies the checkpoint. Later Compile revisions return `{ "required": false }` and do not repeat it.
-
-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.
+Before product implementation, the Agent asks the user to continue with the current model or switch models and then resume the active Long-Task. A task-specific model choice already stated explicitly satisfies the checkpoint. Later Compile revisions return `{ "required": false }` and do not repeat it.
+
+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.
 
 ```text
 ty-context long-task init <workdir>
 ty-context long-task preflight <workdir>
-ty-context long-task compile <workdir>
-ty-context long-task compile <workdir> --revise
-ty-context long-task approve-authority-revision <workdir> --revision <sha>
+ty-context long-task compile <workdir>
+ty-context long-task compile <workdir> --revise
+ty-context long-task diagnose-revision <workdir> [--outcome <key>] [--check <key>]
+ty-context long-task approve-authority-revision <workdir> --revision <sha>
 ty-context long-task explain <workdir>
 ty-context long-task verify <workdir> [--outcome <key>] [--check <key>]
 ty-context long-task status <workdir>
@@ -250,7 +253,9 @@ 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. 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.
 
 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.
 
@@ -290,24 +295,26 @@ Release metadata declares one update mode: `sync-only`, `upgrade-required` or `m
 ## Verification
 
 ```powershell
-npm run format:check
-npm run typecheck --workspace project-tiny-context-harness
-npm run build --workspace project-tiny-context-harness
-node --test --test-concurrency=1 tests/ty-context/source-plan-authoring-skill.test.mjs tests/ty-context/sync-init-doctor.test.mjs tests/ty-context/workflow-contract-routing.test.mjs tests/ty-context/long-task-model-choice-checkpoint.test.mjs
-npm run test:delivery-contract --workspace project-tiny-context-harness
-npm run test:long-task-workflow --workspace project-tiny-context-harness
-npm run test:long-task-performance --workspace project-tiny-context-harness
-npm test
+npm run format:check
+npm run typecheck --workspace project-tiny-context-harness
+npm run build --workspace project-tiny-context-harness
+npm run test:affected:list
+npm run test:affected
+npm run test:long-task:trust
+npm run test:long-task-performance --workspace project-tiny-context-harness
+npm test
 npm run smoke:quickstart
 npm run preview:pack
 npm run launch:check
 node packages/ty-context/dist/cli.js package check-source
 make validate-harness
-```
-
-The modularity gate is `ty-context check-modularity`. Scoped waivers require `owner`, `introduced_at`, `reason`, `tracking_issue` and `expiry_condition`.
+```
+
+`test:affected` is the edit/fix loop. `test:long-task:trust` is the frozen-candidate high-impact boundary gate used by pull-request CI. `npm test` is the complete release regression retained on `main` and publish; do not rerun it after every small repair. Explicit delivery-contract and complete Long-Task gates remain available as package workspace scripts.
+
+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.6.1.tgz`.
+The synchronized local preview tarball is named `project-tiny-context-harness-0.7.0.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.6.1.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.7.0.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -218,14 +218,15 @@ An explicit Long-Task expresses material visual expectations through the existin
 
 ### Optional Source Plan Authoring
 
-Use `/source-plan-authoring` when explicitly asking for an initial plan, Source Plan, source draft, or synthesis/refinement/audit of later implementation or Contract-authoring Source. The input may be one substantially complete plan or a sparse goal plus mixed notes, product/technical documents, screenshots, diagrams and other attachments. A short request that identifies the artifact roles, product goal, reference authority and desired elaboration is enough; no intake questionnaire or pre-normalized outline is required.
+Use `/source-plan-authoring` when explicitly asking for an initial plan, Source Plan, source draft, or synthesis/refinement/audit of later implementation or Contract-authoring Source. The input may be one substantially complete plan or a sparse goal plus mixed notes, product/technical documents, screenshots, diagrams and other attachments. A short request that identifies the artifact roles, product goal, reference authority and desired elaboration is enough; no fixed intake questionnaire or pre-normalized outline is required.
 
 It outputs one self-contained Markdown Source Plan that:
 
 - inventories every supplied artifact, inspects all material pages/frames/screens and records coverage gaps instead of silently sampling;
 - preserves direct requirements and their qualifiers;
 - marks necessary derivations and cites what they derive from;
-- when the user delegates synthesis or elaboration, makes traceable low-impact, reversible product choices marked `delegated`, while keeping permissions, destructive behavior, pricing, retention, security policy and other high-impact choices as `DEC`/`decision_required`;
+- before comparative research or a material product, technical, architecture or provider selection, asks a concise targeted question when an unknown user priority such as quality versus cost, speed, reliability, privacy, lock-in or operational burden could change the research scope, candidate set or recommendation; it does not re-ask known preferences or interrupt minor reversible choices;
+- after the preference envelope is clear, decides what research is needed, uses current authoritative or primary sources for external capability/pricing/quota/license/compatibility/region/security/support claims, and treats a request to synthesize, refine, complete or use judgment as plan-level delegation: one supported recommendation is recorded as `delegated` with its instruction, preference/evidence basis and exact meaning instead of asking for approval, including high-impact plan semantics; real payment, contracting, production release, destructive production mutation, permission grants, sensitive-data transmission and required legal/security/human approval remain `EXT`, while only conflicts, user-reserved choices, missing material preferences or cases with no defensible recommendation remain `DEC`/`decision_required`;
 - splits Outcomes only by independently decidable observable results;
 - uses stable semantic keys and explicit anchors for important Source items;
 - separates mandatory `OBL` obligations from advisory `HINT` suggestions;
@@ -246,15 +247,18 @@ Use `/long-task-workflow` only when explicitly requested or when the current wor
 - Outcome dependencies as acceptance readiness, not worker scheduling;
 - one user model-choice checkpoint after first Authority Lock and before implementation;
 - a rolling internal implementation Frontier;
-- targeted repair checks that never accept;
+- targeted repair checks that never accept;
+- stateless scope-only revision diagnosis before one exact approval;
 - a complete Final Gate on one current snapshot;
 - a Stop Hook that rejects stale completion.
 
-Long-Task Contract authoring preserves stable Source keys and anchors where practical. A product choice already recorded in Source under explicit user delegation remains ordinary Source meaning, but Contract authoring cannot extend that delegation. Meaning-preserving structural decomposition and evidence-backed repository binding may continue; any other new business rule, default, recovery behavior, permission or scope becomes `decision_required` instead of being silently added. Missing recommended Source Plan structure never blocks authoring, but the marker-only Material Source Item enumeration required for activation does.
+Long-Task Contract authoring preserves stable Source keys and anchors where practical. If an unknown preference could materially change comparative research or selection, it asks before proceeding. Once the decision criteria are clear, a defensible recommended plan choice is written into real Source with its delegation, preference/evidence basis and exact meaning before Contract mapping; it is never hidden only in YAML. That plan delegation does not authorize a real high-risk external action, which remains an explicit external confirmation. Meaning-preserving structural decomposition and evidence-backed repository binding may continue; conflicting, user-reserved, missing-preference or unsupported new product semantics remain `decision_required`. Missing recommended Source Plan structure never blocks authoring, but the marker-only Material Source Item enumeration required for activation does.
 
 Before the first successful formal Compile, `delivery-contract.yaml` is one non-authoritative Contract Draft. `/long-task-workflow` keeps revising that same Draft across repository/Context reads and Preflight repair rounds; it does not require one response to produce a complete Contract. Draft authoring is integrated because repository bindings and verification inputs need real evidence, Preflight findings must feed back into the same object, and a separate handoff would risk lost meaning or a second plan/authority. No standalone Contract Draft Skill, Draft Receipt or Authoring State exists.
 
-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.
+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.
 
 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.
 
@@ -267,9 +271,10 @@ The platform owns physical Goal/session lifecycle. A later session runs `resume`
 ```text
 ty-context long-task init <workdir>
 ty-context long-task preflight <workdir>
-ty-context long-task compile <workdir>
-ty-context long-task compile <workdir> --revise
-ty-context long-task approve-authority-revision <workdir> --revision <sha>
+ty-context long-task compile <workdir>
+ty-context long-task compile <workdir> --revise
+ty-context long-task diagnose-revision <workdir> [--outcome <key>] [--check <key>]
+ty-context long-task approve-authority-revision <workdir> --revision <sha>
 ty-context long-task explain <workdir>
 ty-context long-task verify <workdir> [--outcome <key>] [--check <key>]
 ty-context long-task status <workdir>
@@ -283,10 +288,12 @@ 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. 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.
 - `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) and the active Contract's complete `external_confirmations`. 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_workflow_status` and external confirmations, ready Outcomes, findings and the next safe action from the common-dir authority snapshot.
+- `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. 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.
 - `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.
@@ -435,24 +442,26 @@ Release metadata declares one update mode: `sync-only`, `upgrade-required` or `m
 
 ```powershell
 npm install
-npm run format:check
-npm run typecheck --workspace project-tiny-context-harness
-npm run build --workspace project-tiny-context-harness
-node --test --test-concurrency=1 tests/ty-context/source-plan-authoring-skill.test.mjs tests/ty-context/sync-init-doctor.test.mjs tests/ty-context/workflow-contract-routing.test.mjs tests/ty-context/long-task-model-choice-checkpoint.test.mjs
-npm run test:delivery-contract --workspace project-tiny-context-harness
-npm run test:long-task-workflow --workspace project-tiny-context-harness
-npm run test:long-task-performance --workspace project-tiny-context-harness
-npm test
+npm run format:check
+npm run typecheck --workspace project-tiny-context-harness
+npm run build --workspace project-tiny-context-harness
+npm run test:affected:list
+npm run test:affected
+npm run test:long-task:trust
+npm run test:long-task-performance --workspace project-tiny-context-harness
+npm test
 npm run smoke:quickstart
 npm run preview:pack
 npm run launch:check
 node packages/ty-context/dist/cli.js package check-source
 make validate-harness
-```
-
-The modularity gate is `ty-context check-modularity`. Scoped waivers require `owner`, `introduced_at`, `reason`, `tracking_issue` and `expiry_condition`.
+```
+
+`test:affected` is the edit/fix loop. `test:long-task:trust` is the frozen-candidate high-impact boundary gate used by pull-request CI. `npm test` is the complete release regression retained on `main` and publish; do not rerun it after every small repair. Explicit delivery-contract and complete Long-Task gates remain available as package workspace scripts.
+
+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.6.1.tgz` under the preview output directory.
+`npm run preview:pack` produces a local preview named `project-tiny-context-harness-0.7.0.tgz` under the preview output directory.
 
 ## Community And Further Reading
 

package/assets/README.zh-CN.md

@@ -101,31 +101,32 @@ Context: no durable fact change
 
 只有新长期模块/能力、公共 API/Schema/data/persistence、source of truth/state ownership、dependency direction、跨 area、migration/security/recovery 或可复用抽象才触发架构 Gate；小修复不支付这项成本。Gate 要明确 owner、唯一事实源、依赖方向、接口/状态生命周期、失败/恢复/兼容、禁止绕过路径和项目自己的可执行架构检查。
 
-Harness 只路由仓库原生 lint/AST/dependency/contract check，不实现跨语言通用架构分析器。`check-modularity` 的语句数/分支风险会定位到最高风险函数和行号。
-
-### 视觉交付指导
-
-对设计系统、重设计、高保真实现或 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 证据。
-
-显式 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。
-
-### 可选 Source Plan Authoring
-
-用户明确要求初版方案、源方案、方案源稿、Source Plan，或要求综合、细化、审计后续实现与 Contract Authoring 的 Source 时，使用 `/source-plan-authoring`。输入既可以是一份接近完成的方案，也可以只是目标，加上零散笔记、产品/技术文档、截图、图表等混合附件。用户只需说明附件角色、产品目标、参考资料是精确目标还是灵感，以及希望 Skill 细化即可；不需要先填问卷或整理统一大纲。
+Harness 只路由仓库原生 lint/AST/dependency/contract check，不实现跨语言通用架构分析器。`check-modularity` 的语句数/分支风险会定位到最高风险函数和行号。
+
+### 视觉交付指导
+
+对设计系统、重设计、高保真实现或 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 证据。
+
+显式 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。
+
+### 可选 Source Plan Authoring
+
+用户明确要求初版方案、源方案、方案源稿、Source Plan，或要求综合、细化、审计后续实现与 Contract Authoring 的 Source 时，使用 `/source-plan-authoring`。输入既可以是一份接近完成的方案，也可以只是目标，加上零散笔记、产品/技术文档、截图、图表等混合附件。用户只需说明附件角色、产品目标、参考资料是精确目标还是灵感，以及希望 Skill 细化即可；不需要先填固定问卷或整理统一大纲。
 
 它输出一份自包含 Markdown Source Plan：
 
-- 为每份附件建立 Input Inventory，完整检查有实质含义的页面、画面与屏幕，未读内容或覆盖缺口必须显式报告，不能静默抽样；
-- 保留直接要求及其限定条件；
-- 必要推导必须标记并写明 `Derived From`；
-- 用户明确委托综合或细化时，可以自主作出低影响、可逆的产品选择，但必须标记为 `delegated` 并记录委托语句与依据；权限、破坏性行为、付费、数据保留、安全策略等高影响选择仍进入 `DEC`/`decision_required`；
+- 为每份附件建立 Input Inventory，完整检查有实质含义的页面、画面与屏幕，未读内容或覆盖缺口必须显式报告，不能静默抽样；
+- 保留直接要求及其限定条件；
+- 必要推导必须标记并写明 `Derived From`；
+- 在对比调研或实质性的产品、技术、架构、供应商选型前，先判断哪些用户取舍会改变调研范围、候选集或推荐；如果质量与性价比、交付速度、可靠性、隐私、供应商锁定、运维成本等关键偏好不明确，就先用简短、有针对性的问题询问用户，不重复询问已有偏好，也不打断推荐不会改变的局部可逆选择；
+- 偏好边界明确后，再决定是否以及如何调研；外部能力、价格、额度、许可、兼容性、区域、安全与支持等时效性事实使用当前权威或一手来源。用户要求综合、细化、补全或自行判断时，默认委托方案层决策：形成有依据的合理推荐后，直接标记为 `delegated` 并记录委托语句、偏好/证据依据和准确含义，高影响方案语义本身不再触发批准；真实付款/签约、生产发布、生产数据破坏性修改、实际授权、敏感数据外发及必要法务/安全/人工审批仍保留为 `EXT`，只有输入冲突、用户明确保留、关键偏好仍缺失或无法形成可靠推荐时才进入 `DEC`/`decision_required`；
 - Outcome 只按可独立判断的可观察结果拆分；
 - 重要 Source 项使用稳定语义 Key 与显式 Anchor；
 - 强制技术义务使用 `OBL`，非强制实现建议使用 `HINT`；
-- 对交互产品，先穷举范围内的 surface，再细化到每个实质控件，分别记录页面/区域/类型/文案、位置、任务、可见与可用条件、触发/输入/校验/默认值、交互/跳转，以及 Loading、Empty、Success、Failure、Recovery、Permission、Feedback 和 Accessibility；
+- 对交互产品，先穷举范围内的 surface，再细化到每个实质控件，分别记录页面/区域/类型/文案、位置、任务、可见与可用条件、触发/输入/校验/默认值、交互/跳转，以及 Loading、Empty、Success、Failure、Recovery、Permission、Feedback 和 Accessibility；
 - 明确“不算完成”的 Source 含义使用 `NCOMP`；
 - 每个 `RISK` 明确 Fact、单个 Affected Outcome、Basis 与 Consequence，无法确定时进入 `DEC`；Fact 精确使用 Runtime 的十个名称：`public_api_or_schema_change`、`persistent_data_change`、`data_migration`、`security_boundary_change`、`permission_boundary_change`、`irreversible_external_effect`、`critical_user_path`、`full_population_operation`、`multi_repository_change`、`weak_observability`；
-- 每个 AC 只代表一个 Given/When/Then 可观察场景，显式列出对应 `REQ`/`CTRL`/`OBL`/`NCOMP` Key，不能首次偷渡新需求，并在文末报告是否已可交给 Contract Authoring。
+- 每个 AC 只代表一个 Given/When/Then 可观察场景，显式列出对应 `REQ`/`CTRL`/`OBL`/`NCOMP` Key，不能首次偷渡新需求，并在文末报告是否已可交给 Contract Authoring。
 
 它不更新项目 Context，不绑定真实仓库 owner/path/runner，不生成 Delivery Contract YAML，不执行实现，不创建工作流状态，也不声明完成。`HINT` 不是 Material Source Item；Source Plan Skill 不输出 `ty-source-item` Marker，Marker 由后续 repository-aware Long-Task Authoring 插入。Source Plan 是 Source，不是 Contract Draft。推荐结构只是 Authoring Fast Path；普通 prose/Source Plan 或普通文本方案仍可直接作为 Long-Task Source。
 
@@ -139,11 +140,12 @@ Harness 只路由仓库原生 lint/AST/dependency/contract check，不实现跨
 - Outcome 依赖只表示验收就绪关系，不表示 Worker 调度；
 - 第一次 Authority Lock 后、正式实现前有一次用户模型选择；
 - 当前 Goal 内部滚动展开实现 Frontier；
-- targeted verify 只用于修复，永远不能 accepted；
+- targeted verify 只用于修复，永远不能 accepted；
+- scope-only revision 可先做无状态候选诊断，再只发起一次精确审批；
 - Final Gate 在一个当前快照上重跑全部 Check；
 - Stop Hook 在结果 stale 时阻止完成。
 
-Long-Task Contract Authoring 会尽量保留 Source 中已有的稳定 Key 与 Anchor。已经在 Source Plan 中依据用户显式委托记录的产品选择属于普通 Source 含义，但 Contract Authoring 不能扩大这份委托。保持产品含义的结构分解和有真实证据的仓库绑定可以继续；除此之外新增业务规则、默认值、恢复行为、权限或范围必须进入 `decision_required`，不能静默加入。缺少推荐 Source Plan 结构不构成阻塞，但激活前必须完成只插入标记、不改写原文的 Material Source Item 枚举。
+Long-Task Contract Authoring 会尽量保留 Source 中已有的稳定 Key 与 Anchor。若未知偏好会实质改变对比调研或选型，必须先询问用户；决策标准明确后，有依据的推荐方案再把委托、偏好/证据依据和准确含义写入真实 Source，然后映射到 Contract，不能只藏在 YAML 中。这份方案委托不授权任何真实高危外部动作，高危动作继续作为显式 external confirmation。保持产品含义的结构分解和有真实证据的仓库绑定可以继续；输入冲突、用户明确保留、关键偏好缺失或没有可靠推荐的新产品语义仍进入 `decision_required`。缺少推荐 Source Plan 结构不构成阻塞，但激活前必须完成只插入标记、不改写原文的 Material Source Item 枚举。
 
 第一次正式 Compile 成功前，`delivery-contract.yaml` 是同一份非权威 Contract Draft。`/long-task-workflow` 可以跨多轮仓库/Context 读取和 Preflight 修复持续修改它，不要求一次响应生成完整 Contract。不存在单独 Contract Draft Skill、Draft Receipt 或 Authoring State。
 
@@ -159,7 +161,9 @@ Long-Task Contract Authoring 会尽量保留 Source 中已有的稳定 Key 与 A
 }
 ```
 
-Agent 此时在实现前只暂停一次，请用户选择：继续当前模型，或切换模型后恢复同一 active Long-Task。如果用户已明确给出本任务的模型策略，则视为已完成选择。后续 `compile --revise` 返回 `required: false`，不会重复暂停。Harness 不会自动切换模型，也不持久化 acknowledgement、model route 或 checkpoint state；模型选择不是验收证据。
+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 仍必须重跑。
 
 Long-Task Skill 采用渐进读取：主 `SKILL.md` 只保留目标、硬边界和阶段路由，Contract Authoring、Evidence Design 与 Authority Lifecycle 细节只在对应阶段读取一层 reference。这只是指令组织，不产生第二权威。
 
@@ -172,9 +176,10 @@ Draft Outcome 只是 Authority Lock 前的 Outcome。Outcome 按可独立观察
 ```text
 ty-context long-task init <workdir>
 ty-context long-task preflight <workdir>
-ty-context long-task compile <workdir>
-ty-context long-task compile <workdir> --revise
-ty-context long-task approve-authority-revision <workdir> --revision <sha>
+ty-context long-task compile <workdir>
+ty-context long-task compile <workdir> --revise
+ty-context long-task diagnose-revision <workdir> [--outcome <key>] [--check <key>]
+ty-context long-task approve-authority-revision <workdir> --revision <sha>
 ty-context long-task explain <workdir>
 ty-context long-task verify <workdir> [--outcome <key>] [--check <key>]
 ty-context long-task status <workdir>
@@ -188,10 +193,12 @@ 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。第一次结果附带 `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，并使旧批准失效。
 - `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`。
-- `resume` 完全只读，恢复 task/contract identity、风险、相关 Context、Git 状态、ready Outcome、findings 和 next safe action。
+- `status` 输出 `unverified`、`progress_passing`、`progress_failing`、`progress_stale` 或 `blocked_external`，并报告 fresh `final_workflow_status`、完整 `external_confirmations` 与唯一的 `pending_authority_revision`。
+- `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 已清理，不表示完整外部交付完成。
 - `abandon --force-corrupt-state` 仅用于损坏/mismatch/legacy-unrecoverable 状态或遗留锁，只删除确定性 active state 与 `<workdir>/.ty-context/**`。
@@ -239,22 +246,24 @@ Targeted verify、Progress、status、Receipt 与 compiled cache 都不是完成
 
 ```powershell
 npm install
-npm run format:check
-npm run typecheck --workspace project-tiny-context-harness
-npm run build --workspace project-tiny-context-harness
-node --test --test-concurrency=1 tests/ty-context/source-plan-authoring-skill.test.mjs tests/ty-context/sync-init-doctor.test.mjs tests/ty-context/workflow-contract-routing.test.mjs tests/ty-context/long-task-model-choice-checkpoint.test.mjs
-npm run test:delivery-contract --workspace project-tiny-context-harness
-npm run test:long-task-workflow --workspace project-tiny-context-harness
-npm run test:long-task-performance --workspace project-tiny-context-harness
-npm test
+npm run format:check
+npm run typecheck --workspace project-tiny-context-harness
+npm run build --workspace project-tiny-context-harness
+npm run test:affected:list
+npm run test:affected
+npm run test:long-task:trust
+npm run test:long-task-performance --workspace project-tiny-context-harness
+npm test
 npm run smoke:quickstart
 npm run preview:pack
 npm run launch:check
 node packages/ty-context/dist/cli.js package check-source
 make validate-harness
-```
-
-模块化门禁是 `ty-context check-modularity`；例外必须包含 `owner`、`introduced_at`、`reason`、`tracking_issue` 和 `expiry_condition`。
+```
+
+`test:affected` 用于日常修改和修复循环；`test:long-task:trust` 是冻结候选版本后的高风险边界门，也是 PR CI 使用的层级；`npm test` 是 `main` 和发布保留的完整发布回归，不应在每次小修复后重跑。Delivery Contract 和完整 Long-Task 门仍可通过 package workspace scripts 显式执行。
+
+模块化门禁是 `ty-context check-modularity`；例外必须包含 `owner`、`introduced_at`、`reason`、`tracking_issue` 和 `expiry_condition`。
 
 ## 诚实限制
 

package/assets/context_templates/architecture.md

@@ -14,11 +14,11 @@ This is the restrained architecture context. Keep only facts that help a fresh a
 
 - Summarize only the durable request, event, state or data flow that is hard to infer from code alone.
 
-## Design Rationale
-
-- Record architecture-level choices, rejected alternatives and tradeoffs that still constrain future work; leave this empty when no stable architecture reason exists.
-- Do not invent rationale or store implementation summaries, PR notes, command output, test result claims, debug history, agent reasoning or reasons inferred only from current code shape.
-- Architecture boundary changes should be captured here before implementation alignment.
+## Design Rationale
+
+- Record architecture-level choices, rejected alternatives and tradeoffs that still constrain future work; leave this empty when no stable architecture reason exists.
+- Do not invent rationale or store implementation summaries, PR notes, command output, test result claims, debug history, agent reasoning or reasons inferred only from current code shape.
+- Architecture boundary changes should be captured here before implementation alignment.
 
 ## Constraints And Tradeoffs
 

package/assets/context_templates/area.md

@@ -15,11 +15,11 @@
 
 ## Module Design Capsule
 
-- Principles: stable execution constraints that should affect future module work.
-- Design Logic: the minimum logic for choosing, rejecting, degrading or composing module behavior.
-- Design Rationale: only durable reasons, rejected alternatives and tradeoffs that change later implementation or verification decisions; leave it empty when no stable reason exists.
-- Do not invent rationale or store implementation summaries, PR notes, command output, test result claims, screenshot review notes, debug history, agent reasoning or reasons inferred only from current code shape.
-- Current standards, thresholds and commands belong in the relevant contract or verification Context, not as permanent principles.
+- Principles: stable execution constraints that should affect future module work.
+- Design Logic: the minimum logic for choosing, rejecting, degrading or composing module behavior.
+- Design Rationale: only durable reasons, rejected alternatives and tradeoffs that change later implementation or verification decisions; leave it empty when no stable reason exists.
+- Do not invent rationale or store implementation summaries, PR notes, command output, test result claims, screenshot review notes, debug history, agent reasoning or reasons inferred only from current code shape.
+- Current standards, thresholds and commands belong in the relevant contract or verification Context, not as permanent principles.
 
 ## Key Constraints
 

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

@@ -18,9 +18,9 @@ Write only project-specific facts that should guide future implementation. Do no
 - Main Surface Allows:
 - Main Surface Forbids:
 - Drilldown Ownership:
-- Long Task State Requirement:
-- Design Rationale:
-- Empty / Loading / Stale / Unavailable:
+- Long Task State Requirement:
+- Design Rationale:
+- Empty / Loading / Stale / Unavailable:
 - Security / Redaction:
 - Verification:
 
@@ -48,16 +48,16 @@ Update this Context when:
 
 - A surface responsibility changes.
 - Main/drilldown ownership changes.
-- A durable long-task state contract is introduced.
-- A durable main/drilldown/diagnostic ownership rationale, rejected alternative or tradeoff will guide future changes.
-- A repeated UI/product rule becomes reusable.
-- A platform-specific interaction rule becomes stable.
+- A durable long-task state contract is introduced.
+- A durable main/drilldown/diagnostic ownership rationale, rejected alternative or tradeoff will guide future changes.
+- A repeated UI/product rule becomes reusable.
+- A platform-specific interaction rule becomes stable.
 
 Do not update this Context for:
 
 - CSS-only fixes.
 - One-off screenshot observations.
-- Temporary audit notes.
-- Test logs.
-- Local implementation summaries.
-- PR notes, command output, screenshot review notes, debug history, agent reasoning or rationale inferred only from current code shape.
+- Temporary audit notes.
+- Test logs.
+- Local implementation summaries.
+- PR notes, command output, screenshot review notes, debug history, agent reasoning or rationale inferred only from current code shape.

package/assets/github/harness.yml

@@ -22,10 +22,10 @@ jobs:
   harness:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
+      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
         with:
           fetch-depth: 0
-      - uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6.4.0
+      - uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6.4.0
         with:
           node-version: "24"
       - name: Prepare source workspace CLI

package/assets/skills/context_development_engineer/SKILL.md

@@ -61,28 +61,28 @@ When an active `/long-task-workflow` binding exists, that Skill owns lifecycle,
 
 sample provider / interface / page 证据不能替代 all-provider / all-interface / all-platform 或全量完成。来源要求全量而当前只能交付框架/样本时标记 `scope_conflict_requires_decision`；权威范围未收窄前不得声称完成。
 
-## Product Surface
+## Product Surface
 
 涉及 Web/移动/桌面/游戏 UI、CLI/TUI、表单、配置、输入、选择、搜索、筛选、调度、预算/配额/限流或状态反馈时：
 
 - 对照已有 Product Surface / Surface Contract、页面职责和控件任务，而不是只确认字段已暴露；
 - 内部保持 Surface Contract Hit、main allows/forbids、drilldown ownership、long-task state requirement、implementation drift 和 verification；
-- 缺失 durable surface responsibility 时设置 `Context Delta: required`，先用 `context_surface_contract` 或 owning Context 建立职责；
-- 收尾用简短 `Contract Conformance` 说明命中的 Context、实现满足方式、未满足项和验证入口。
-
-## 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:
-
-- 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.
-
-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.
-
-## Modularity Check
+- 缺失 durable surface responsibility 时设置 `Context Delta: required`，先用 `context_surface_contract` 或 owning Context 建立职责；
+- 收尾用简短 `Contract Conformance` 说明命中的 Context、实现满足方式、未满足项和验证入口。
+
+## 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:
+
+- 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.
+
+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.
+
+## Modularity Check
 
 新实现、重构、重复逻辑、模块边界或影响面控制需要内部记录 `Modularity Check: none|required|exception`。