project-tiny-context-harness 0.7.3 → 0.7.4

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.3.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.7.4.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -320,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.3.tgz`.
+The synchronized local preview tarball is named `project-tiny-context-harness-0.7.4.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.3.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.7.4.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -264,9 +264,13 @@ Later revisions are classified into three paths. Formally monotonic evidence str
 
 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.
+A Draft Outcome is simply an Outcome before Authority Lock. Outcomes split independently observable, decidable, vertical 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. Every Outcome belongs to one ordered Stage; its Stage gate transitively depends on the other Outcomes in that Stage, and later Stages depend on earlier gates. The Rolling Frontier and Stage status are derived from ordinary Outcome Progress and are temporary. An Outcome is not a Worker, scheduler task, queue or parallelism unit, and a Stage owns no Receipt or second Gate. 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. 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 Contract declares one bounded target profile, its non-empty required product target refs and each target's runtime family/root entrypoint. A Web/process proxy cannot satisfy an independently required Native/desktop target. Browser target proof uses Playwright; Native/desktop target proof uses a project binary. Every `critical_user_path` Outcome and Stage gate proves `target_runtime` from every required target's root entrypoint; a multi-Outcome Stage gate also proves at least two distinct surfaces share one runtime state.
+
+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. Checks declare keyed Given/When scenarios and journey roles; Assertions declare all-of Evidence Capabilities backed by typed current-execution records. Static `presence` cannot prove behavior, degradation cannot replace required success, fixed-input output cannot prove variation and a producer cannot self-attest its own boundary/external effect. After a blocker-driven semantic/proof revision, only affected weak-observability or high-risk behavioral Claims pay causal review. The Goal runs the live Check after the first runnable slice and, after coalescing related edits, before dependent work grows when declared inputs make Progress stale. This reuses targeted verification and Final Gate: it adds no open-ended `platform_impact` flags, per-platform progress state or alternate Gate, requires no full rebuild per Outcome/edit, never accepts early and is rerun by Final Gate.
+
+A separate read-only Global Product Conformance Check is required only for weak-observability work that also has multiple Stages or multiple required product runtime families. It starts at a required root product target, has independent Raw Execution and runs within the existing Final Gate. Single-Stage, single-family work retains the existing same-Check sensitivity path and pays no extra conformance run.
 
 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.
 
@@ -291,14 +295,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.
+- `preflight` applies Compact defaults and reports all discoverable Source/REQ/CTRL/OBL/AC, Stage closure, required-target/root/runner, scenario/journey, capability, external-impact, Product Conformance, 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. 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 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.
+- `status` reports each Outcome as `unverified`, `progress_passing`, `progress_failing`, `progress_stale` or `blocked_external`. It derives `stages`, `ready_stages` and the stage-constrained Outcome frontier from current Progress without persisting Stage completion. It also reports the fresh Final Receipt as `final_workflow_status` (or `null` after drift), target profile/state, 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/target/Stage/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. Its Receipt derives each Stage as `passed`, `failed`, `blocked_external` or `blocked_dependency`, and derives `target_state` as `not_accepted`, `blocked_external` or the Contract's exact `implementation_complete`, `target_profile_usable` or `production_release_ready` qualification.
 - `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.
 
@@ -313,6 +317,17 @@ task:
   id: example-task
   title: Example task
   goal: Complete observable delivery goal
+  target_profile:
+    key: personal-trial
+    description: The example is usable from its declared runtime root.
+    required_state: target_profile_usable
+    required_target_refs: [example-runtime]
+  execution_targets:
+    - key: example-runtime
+      description: Example product runtime
+      role: product
+      runtime_family: process
+      root_entrypoint: tests/runtime.mjs
   source_paths: [plans/example.md]
   context_refs: [project_context/areas/main.md]
 source_claims:
@@ -322,14 +337,22 @@ source_claims:
     disposition:
       type: claim
       refs: [observable-outcome.requirement.observable]
+stages:
+  - key: delivery
+    title: Delivery
+    depends_on: []
+    gate_outcome: observable-outcome
 risk:
   facts: {}
 global: {}
 outcomes:
   - key: observable-outcome
     title: Observable outcome
+    stage: delivery
     product:
       observable_result: What a user or system can observe
+      success_path_required: true
+      degradation_path_required: false
       owner:
         label: Owning product or module boundary
         context_refs: [project_context/areas/main.md]
@@ -349,6 +372,11 @@ outcomes:
     acceptance:
       checks:
         - key: runtime
+          journey_roles: [success, stage_gate]
+          execution_target: {target_ref: example-runtime, entrypoint: root}
+          scenario:
+            given: [{key: source-ready, statement: The planned source carrier is available.}]
+            when: [{key: inspect-result, statement: Inspect the result through the declared runtime.}]
           proof_surface: runtime_behavior
           runner:
             type: node_oracle
@@ -362,6 +390,7 @@ outcomes:
               criterion: The declared requirement is observable.
               claims: [result, requirement.observable]
               observation: result
+              evidence_capabilities: [state_delta, target_runtime]
               operator: equals
               expected: true
       counterfactual_controls:
@@ -382,7 +411,7 @@ Global non-goals, constraints and forbidden shortcuts generate `GLOBAL.non_goal.
 
 Claim-bearing structured Global Checks also declare `global.acceptance.counterfactual_controls`. Each control uses `binding_ref: <outcome-key>.<binding-key>` to reuse an Outcome-owned implementation carrier; no separate Global Binding layer exists. An `existing` mutation target must exist at Preflight/Compile, while a `planned` target may be absent until implementation but must exist at Final Gate and participates in Progress freshness.
 
-Supported runners are `package_script`, `project_binary`, `node_oracle` and `playwright_test`. Supported proof surfaces are `ui_browser`, `runtime_behavior`, `api_contract`, `data_state`, `security_boundary`, `population_coverage` and `implementation_structure`.
+Supported runners are `package_script`, `project_binary`, `node_oracle` and `playwright_test`. Supported proof surfaces are `ui_browser`, `runtime_behavior`, `api_contract`, `data_state`, `security_boundary`, `population_coverage` and `implementation_structure`. Execution-target runtime families are the bounded `browser`, `native`, `desktop`, `service`, `process` and `external` set; target roles are `product`, `support` and `observer`. Required target refs resolve only to product targets. Browser target proof requires `playwright_test`; Native/desktop target proof requires `project_binary`.
 
 ### One Contract And Source Claims
 
@@ -416,11 +445,13 @@ An explicit user request can raise the level to strict. Explicit `standard` belo
 
 ### Evidence And Authority
 
-Final acceptance is computed from executable current evidence, not agent prose. Evidence adapters derive from runner kind: `playwright_test` produces `playwright_json_v1` and is the only adapter allowed for `ui_browser`; package scripts, project binaries and Node oracles produce `structured_json_v2` for all non-browser surfaces. The adapter is part of acceptance, raw-execution, compiled, progress and Receipt identity.
+Final acceptance is computed from executable current evidence, not agent prose. Evidence adapters derive from runner kind: `playwright_test` produces `playwright_json_v1` and is the only adapter allowed for `ui_browser`; package scripts, project binaries and Node oracles use the `structured_json_v2` adapter for non-browser surfaces and emit the additive `long-task-check-result-v3` payload when capability records are required. V2 payloads remain decodable only for compatibility and cannot satisfy non-presence capabilities. The adapter is part of acceptance, raw-execution, compiled, progress and Receipt identity.
+
+Every Check declares non-empty keyed `scenario.given` and `scenario.when` steps plus one or more roles from `success`, `degradation`, `recovery`, `stage_gate` and `conformance`. Every Assertion declares an all-of set from `presence`, `interaction_trace`, `state_delta`, `cross_surface_consistency`, `durable_readback`, `boundary_invocation`, `external_side_effect`, `failure_injection`, `visual_render`, `target_runtime` and `input_variation`. Except for static `presence`, each capability requires exactly one typed current-execution record bound to that Assertion. Missing, duplicate, unknown or undeclared records fail closed. Result Claims use success Checks only; success and degradation cannot share one Check. External-boundary evidence runs on an observer target. Input variation proves at least two distinct inputs, two output hashes and a failure case.
 
 Every Outcome has at least one non-Result atomic Claim, and a Claim is covered only when all `required_proof_surfaces` are covered. Claim-bearing assertions use explicit expected-value comparisons; unary `truthy`/`falsy` are forbidden, and `exists` is limited to `implementation_structure` obligations. Across all Checks sharing one Raw Execution identity, one claim-bearing Observation belongs to one Assertion. Playwright Claim proof has one canonical form: `playwright.case.<ac-key>.passed equals true`. Missing, skipped, flaky, unexpected, failed or duplicate-within-project ACs fail closed; the same AC across distinct Playwright projects aggregates only when every instance passes. Decoder diagnostic fields such as aggregate pass, executed, skipped, status and counts cannot prove Claims.
 
-Outcome Counterfactuals bind a local Binding; Global Counterfactuals bind an Outcome-owned `binding_ref`. Both may mutate only a proven subset of carriers. `structured_json_v2` requires completed exit-zero execution with exactly the expected `assertion_value_mismatch` set. A weak `playwright_json_v1` Counterfactual may accept exit one only under exact, complete unexpected-instance accounting; ordinary Playwright Baseline Checks still require exit zero. Standard frozen Playwright content is trusted verifier input. For a `weak_observability` Outcome, every claim-bearing Playwright AC and related Claim needs same-Check sensitivity. Claim and Population proofs are emitted only after the complete Check status is `passed`.
+Outcome Counterfactuals bind a local Binding; Global Counterfactuals bind an Outcome-owned `binding_ref`. Both may mutate only a proven subset of carriers. `structured_json_v2` adapter executions require completed exit-zero execution with exactly the expected `assertion_value_mismatch` set. A weak `playwright_json_v1` Counterfactual may accept exit one only under exact, complete unexpected-instance accounting; ordinary Playwright Baseline Checks still require exit zero. Standard frozen Playwright content is trusted verifier input. For a `weak_observability` Outcome, every claim-bearing Playwright AC and related Claim needs same-Check sensitivity. Claim and Population proofs are emitted only after the complete Check status is `passed`.
 
 Raw Execution identity binds frozen runner identity plus canonical declared Environment Requirements, never actual environment values. A Playwright Test uses `[ac:<assertion-key>]`; one Test may bind at most one declared AC. Every Claim-bearing structured Check needs same-Check, Claim-related Counterfactual sensitivity; unrelated Artifacts or another Check do not count. Counterfactual Findings are projected into their owning Check Result before Progress is written, so status/resume recover the Finding without a new Global Outcome state. Explain traces Source Item → canonical target → Claim or Assertion → required surfaces → Check → adapter → Observation.
 
@@ -434,6 +465,8 @@ Version 0.6.0 retires the V1 schema/runtime and repo-local Hook. Enable, disable
 
 Version 0.6.0 defines the first public V2 semantics while retaining the `long-task-delivery-v2` schema name and physical `outcome_files` parser form. Optional Source Plan authoring adds no Schema, CLI, Preflight, Compile, Validator, Receipt, Authority or state. Preflight and direct Compile use one activation-safety kernel.
 
+Version 0.7.2 strengthens that same V2 authority with ordered Stages, bounded required targets/root entrypoints, explicit success/degradation journeys and scenarios, typed Evidence Capabilities, typed external impact, risk-proportional Product Conformance and terminal target/Stage projections. An older V2 Contract missing those fields reports the indexed manual migration `long-task-v2-semantic-drift-authority`; re-author the missing meaning from Source. Upgrade never infers those semantics or imports old Progress/Receipts as passing evidence.
+
 `/normal-long-task` is also a retirement pointer to `/long-task-workflow`; it creates no checklist, prompt, audit, matrix, verdict or second authority.
 
 ### Package update modes
@@ -465,7 +498,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.3.tgz` under the preview output directory.
+`npm run preview:pack` produces a local preview named `project-tiny-context-harness-0.7.4.tgz` under the preview output directory.
 
 ## Community And Further Reading
 

package/assets/README.zh-CN.md

@@ -169,9 +169,13 @@ Agent 此时在实现前只暂停一次，请用户选择：继续当前模型
 
 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。
+Draft Outcome 只是 Authority Lock 前的 Outcome。Outcome 按可独立观察、判断、纵向闭环和定向验证的结果拆分，使当前 Goal 能缩小 dependency-ready 工作集、定向验证、定位失败、恢复 finding 并精确失效旧局部结果。`depends_on` 只表示 acceptance readiness。每个 Outcome 属于一个有序 Stage；Stage gate 传递依赖同 Stage 其余 Outcome，后续 Stage 依赖前置 gate。Rolling Frontier 和 Stage 状态都由普通 Outcome Progress 临时派生；Outcome 不是 Worker、scheduler task、queue 或并行单元，Stage 也没有 Receipt 或第二个 Gate。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 仍会重跑。
+Contract 声明一个有界 target profile、非空 required product target refs，以及每个 target 的 runtime family/root entrypoint。Web/process 代理不能代替单独要求的 Native/desktop 目标；browser 目标由 Playwright 证明，Native/desktop 目标由 project binary 证明。每个 `critical_user_path` Outcome 和 Stage gate 都必须从每个 required target 的 root 证明 `target_runtime`；多 Outcome Stage gate 还必须证明至少两个不同 surface 对应同一运行时状态。
+
+如果一个声明结果可能在代理表面通过、却在目标运行时独立失败，最早拥有可运行边界的 Outcome 必须声明项目自有的真实运行 Check，并在当前 Check 执行中启动或触达目标、从同一会话产生结构化 Observation。仓库内状态报告、截图、二进制、日志或历史运行不能单独证明目标运行时。Check 显式声明带 Key 的 Given/When 场景与 journey role；Assertion 声明 all-of Evidence Capability，并由类型化的当前执行记录证明。静态 `presence` 不能证明行为，降级路径不能替代要求的成功路径，固定输入不能证明输入变化，产生 side effect 的组件也不能自行证明其边界效果。当前 Goal 在第一个可运行切片后执行一次；后续相关修改先合并，在声明输入使 Progress stale 后、扩大依赖工作前再运行。它复用 targeted verify 与 Final Gate，不增加开放式 `platform_impact` 字段、逐平台 Progress 或替代 Gate，不要求每个 Outcome/每次编辑完整重建，也不提前取得接受权；Final Gate 仍会重跑。
+
+只有 `weak_observability` 同时遇到多 Stage 或多个 required product runtime family 时，才额外要求一个只读 Global Product Conformance Check。它从 required root product target 启动，使用独立 Raw Execution，并在既有 Final Gate 内运行。单 Stage、单 family 继续使用原有 same-Check sensitivity，不支付额外 conformance 执行成本。
 
 平台负责物理 Goal/会话生命周期。新会话通过 `resume` 恢复语义状态；Tiny Context 不会重建此前的物理 Turn。机器接受只覆盖 `declared_machine_authority`，并报告 `native_goal_effect: none`。完成平台原生 Goal 前，Agent 只做一次否决型核对：当前 Goal/用户语义是否全部进入 accepted marked Source，且没有 pending revision、未解 blocker 或遗漏；它只能阻止并触发修复，不能增加验收证据。
 
@@ -196,14 +200,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。
+- `preflight` 应用 Compact 默认值并一次输出 Source/REQ/CTRL/OBL/AC、Stage closure、required-target/root/runner、scenario/journey、capability、external impact、Product Conformance、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。每次结果都包含 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 与确定性 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。
+- `status` 输出 `unverified`、`progress_passing`、`progress_failing`、`progress_stale` 或 `blocked_external`，由当前 Progress 派生 `stages`、`ready_stages` 和受 Stage 约束的 Outcome frontier，不持久化 Stage 完成。它同时报告 fresh `final_workflow_status`、target profile/state、完整 `external_confirmations` 与唯一的 `pending_authority_revision`。`progress_passing` 只能表述为定向修复证据，不能简称“Outcome 完成”；`progress_stale` 不是当前通过，`final_workflow_status: null` 表示 Goal 尚未完成。
+- `resume` 完全只读，恢复 task/contract identity、风险、相关 Context、Git 状态、相同的 Final/target/Stage/external/pending surface、ready Outcome、findings 和 next safe action。
+- `final-gate` 在完整 Check 后再次验证 active identity；并发 revision 不能产生 accepted。Receipt 把每个 Stage 派生为 `passed`、`failed`、`blocked_external` 或 `blocked_dependency`，把 `target_state` 派生为 `not_accepted`、`blocked_external` 或 Contract 精确声明的 `implementation_complete`、`target_profile_usable`、`production_release_ready`。
 - `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/**`。
 
@@ -213,12 +217,13 @@ ty-context long-task abandon <workdir> [--force-corrupt-state]
 
 Contract 顶层包含：
 
-- `task`：完整目标、Source 路径、相关 Context 与 snapshot 模式；
+- `task`：完整目标、target profile、required target refs、execution target/runtime family/root entrypoint、Source 路径、相关 Context 与 snapshot 模式；
+- `stages`：有序 Stage DAG 与每个 Stage 的 gate Outcome；
 - `risk`：`auto | standard | strict` 与明确 risk facts；
 - `global`：非目标、owner boundary、技术约束、禁止路径/捷径和全局 Check；
-- `outcomes`：可独立判断并可定向验证的结果、依赖、REQ、产品/控件状态与位置、稳定技术义务和命名 AC。
+- `outcomes`：可独立判断并可定向验证的纵向结果、所属 Stage、依赖、明确 success/degradation 要求、REQ、产品/控件状态与位置、稳定技术义务和命名 AC。
 
-Runner 支持 `package_script`、`project_binary`、`node_oracle`、`playwright_test`。Proof surface 支持 `ui_browser`、`runtime_behavior`、`api_contract`、`data_state`、`security_boundary`、`population_coverage`、`implementation_structure`。
+Runner 支持 `package_script`、`project_binary`、`node_oracle`、`playwright_test`。Proof surface 支持 `ui_browser`、`runtime_behavior`、`api_contract`、`data_state`、`security_boundary`、`population_coverage`、`implementation_structure`。Execution target family 是有界的 `browser`、`native`、`desktop`、`service`、`process`、`external`，role 是 `product`、`support`、`observer`；required ref 只能指向 product target。Browser target 只能由 `playwright_test` 证明，Native/desktop target 只能由 `project_binary` 证明。
 
 ### 一个 Contract 与 Source Claim
 
@@ -240,12 +245,18 @@ V2 强制至少一个真实 `source_path` 与一个 `source_claim`，且每个
 
 ## Evidence 与完成权威
 
-最终接受来自当前可执行证据，不来自 Agent 文本。Evidence Adapter 由 Runner 派生：只有 `playwright_test → playwright_json_v1` 可以证明 `ui_browser`，其余 Runner 均为 `structured_json_v2`，只能证明非浏览器 Surface。
+最终接受来自当前可执行证据，不来自 Agent 文本。Evidence Adapter 由 Runner 派生：只有 `playwright_test → playwright_json_v1` 可以证明 `ui_browser`，其余 Runner 使用 `structured_json_v2` Adapter 证明非浏览器 Surface，并在需要 capability record 时输出增量 `long-task-check-result-v3` payload。V2 payload 只保留解码兼容，不能满足非 `presence` 能力。
+
+每个 Check 声明非空、带 Key 的 `scenario.given`/`scenario.when`，并使用 `success`、`degradation`、`recovery`、`stage_gate`、`conformance` journey role。每个 Assertion 声明 `presence`、`interaction_trace`、`state_delta`、`cross_surface_consistency`、`durable_readback`、`boundary_invocation`、`external_side_effect`、`failure_injection`、`visual_render`、`target_runtime`、`input_variation` 中所需的 all-of 集合。除了静态 `presence`，每种能力恰好需要一条绑定该 Assertion 的当前执行记录；缺失、重复、未知或未声明记录全部 fail closed。Result 只能由 success Check 证明；success 与 degradation 不能共用一个 Check；外部边界从 observer target 观察；input variation 至少证明两个不同输入、两个输出 hash 和一个失败样例。
 
 每个 Outcome 至少有一个非 Result 原子 Claim，且 `required_proof_surfaces` 必须 all-of 全覆盖。Claim-bearing Assertion 使用显式 Expected 比较；`truthy/falsy` 禁止，`exists` 仅允许证明 `implementation_structure` Obligation。
 
 Targeted verify、Progress、status、Receipt 与 compiled cache 都不是完成权威。Final Gate 要求 clean candidate commit，从 Source 重新 Compile，在同一 Git-tree snapshot 上运行全部 Global/Outcome Check，并在结束时再次校验 active identity。只有它可以生成 `machine_accepted` 或 `machine_accepted_external_pending`；后者仍必须明确列出外部确认项。
 
+## 兼容与迁移
+
+0.7.2 在同一个 `long-task-delivery-v2` 权威中增加 ordered Stage、required target/root entrypoint、显式 success/degradation journey 与 scenario、类型化 Evidence Capability、类型化 external impact、按风险触发的 Product Conformance，以及 terminal target/Stage projection。缺少这些字段的旧 V2 Contract 会报告可索引的人工迁移 `long-task-v2-semantic-drift-authority`；必须依据 Source 重新表达缺失语义。Upgrade 不会猜测这些含义，也不会把旧 Progress/Receipt 当作通过证据。
+
 ## 开发与验证
 
 ```powershell

package/assets/agents/AGENTS_CORE.md

@@ -29,13 +29,13 @@ Do not infer long-task mode from duration, complexity, file count or agent prefe
 
 Contract Draft authoring belongs inside `long-task-workflow`: continuously revise the same non-authoritative `delivery-contract.yaml` until the first successful formal Compile creates Authority Lock. An optional Source Plan is ordinary upstream Source guidance, not a Contract Draft or required input protocol.
 
-The workflow uses one native Goal, one selected workspace, one Contract and one Final Gate. New authoring uses inline Outcomes; existing `outcome_files` are physical compatibility only. Outcomes decompose dependency-ready execution, targeted repair and diagnosis, not completion authority, workers, branches or model sessions.
+The workflow uses one native Goal, one selected workspace, one Contract and one Final Gate. New authoring uses inline vertical Outcomes grouped by ordered Stages; existing `outcome_files` are physical compatibility only. Target profiles name required product targets and root runtimes; Checks declare Given/When journeys and all-of Evidence Capabilities. Stage/frontier state is derived from ordinary Progress and creates no second Gate, Receipt, scheduler or completion authority.
 
 After the first Authority Lock, stop once before implementation and ask the user to continue with the current model or switch models and then resume the active Long-Task. A model choice already stated explicitly for this task satisfies the checkpoint; later revisions do not repeat it. Harness records no model route or checkpoint state.
 
 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. 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.
+Final Gate, Stop and close recompile the source Contract and rerun every declared Check on one clean current snapshot. Required targets cannot substitute for one another; presence cannot prove behavior; success and degradation remain distinct; typed boundary effects require an observer. Targeted verify is repair evidence only. Status, progress, Stage/frontier projections, 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 typed and explicit; machine acceptance reports target/stage qualification but 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.
 

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

@@ -15,7 +15,7 @@ The host and user own model selection and native-Goal lifecycle. The workflow ha
 
 ## Controlling Objective
 
-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.
+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. In particular, a proxy target, presence text, degradation path, fixed input, self-reported boundary effect or internal entrypoint must never substitute for the declared target behavior. Findings should localize repair through Source Item, Stage, Outcome, Claim, Assertion, Check, Evidence Capability, execution target, 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. 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.
 
@@ -35,9 +35,9 @@ Do not copy reference detail into another plan or state file. The same `delivery
 
 Before the first successful formal Compile, continuously revise the same non-authoritative `delivery-contract.yaml` as the Contract Draft. It need not be completed in one response; keep reading Source, repository and relevant Context and feed Preflight findings back into that same Draft. Draft authoring, Preflight, Compile, rolling execution, targeted verification and Final Gate are one `long-task-workflow` lifecycle. Do not create a standalone Contract Draft Skill, Draft Receipt, Authoring State, draft schema/CLI/runtime state or second plan.
 
-A Draft Outcome is an Outcome in that pre-Authority-Lock Draft, not a new schema field or runtime entity. Decompose only independently observable, decidable and target-verifiable results whose dependencies and owner boundary can be stated. Use those boundaries to keep a dependency-ready working set, target verification, localize failures, resume findings/next actions and stale local results precisely.
+A Draft Outcome is an Outcome in that pre-Authority-Lock Draft, not a new schema field or runtime entity. Decompose only vertical, independently observable, decidable and target-verifiable results whose dependencies and owner boundary can be stated; one Outcome belongs to one declared Stage and does not span materially different success paths. Declare the ordered Stage DAG and one gate Outcome per Stage in the same Contract. Use those boundaries to keep a stage-constrained dependency-ready working set, target verification, localize failures, resume findings/next actions and stale local results precisely.
 
-`depends_on` means acceptance readiness. The current Goal may form a temporary Rolling Frontier from ready Outcomes and findings, but must not persist a scheduler, Worker queue, mandatory implementation DAG, model route or process tree. Never split for response/YAML/file length, implementation layer, module/file count, Agent capacity, Worker assignment or desired parallelism.
+`depends_on` means acceptance readiness. The gate Outcome transitively depends on the rest of its Stage, later Stage Outcomes depend on prerequisite gate Outcomes, and every multi-Outcome gate proves cross-surface consistency. The current Goal derives a temporary Rolling Frontier from Stage and Outcome status, but must not persist a Stage Receipt, scheduler, Worker queue, mandatory implementation DAG, model route or process tree. Never split for response/YAML/file length, implementation layer, module/file count, Agent capacity, Worker assignment or desired parallelism.
 
 > Outcome decomposes execution and diagnosis, not completion authority.
 
@@ -46,26 +46,26 @@ A Draft Outcome is an Outcome in that pre-Authority-Lock Draft, not a new schema
 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.
+3. Otherwise author one complete Delivery Contract for the whole selected delivery. Declare the target profile, its non-empty required product target refs, each target's runtime family/root entrypoint, ordered Stages and vertical Outcomes. Do not create a second Contract plan, matrix or top-level Contract split.
 4. Preserve at least one real `source_path`. Wrap every material Source item in its original Markdown with non-rendering `ty-source-item:start/end` markers without rewriting the text; marked Source Item keys and `source_claim` keys are exactly equal.
 5. An ordinary prose plan or optional Source Plan remains valid Source after marker-only enumeration and does not need to match the recommended Source Plan structure. Preserve stable semantic keys and Markdown anchors where practical.
 6. Continue reading repository, Source and Context and revise the same Draft. A request to synthesize, refine, complete, implement or use judgment delegates plan-level authoring, but it does not invent the user's tradeoff priorities. Before comparative research or a material product, technical, architecture or provider selection, identify the criteria that could change the research scope, candidate set or recommendation. Infer them only from the user's words, Source, Context or controlling constraints. If quality versus cost, speed, reliability, privacy, lock-in, operational burden or another material priority is unknown or ambiguous, stop before that research or selection and ask one concise targeted clarification. Do not impose a questionnaire, re-ask known preferences or interrupt minor reversible choices whose recommendation would not change.
 7. Once the material preference envelope is clear, decide what research is needed. Use current authoritative or primary evidence for external capability, pricing, quota, license, compatibility, region, security posture or support claims. When one recommendation is then defensible, record it in real Source with the authoring instruction, preference/evidence basis and exact added meaning instead of pausing for approval. Append the delegated item without rewriting the user's original text when ordinary prose is the Source. Return only when authoritative requirements conflict, the user explicitly reserves the choice, a material preference remains unknown, critical semantics have no defensible recommendation or no falsifiable acceptance standard can be formed.
 8. Contract expansion remains limited to meaning-preserving structural decomposition, evidence-backed repository binding and choices first recorded as delegated real Source. Never place a new product rule, default, threshold, recovery behavior, permission or platform/data scope only in Contract YAML. Default plan delegation authorizes meaning, not action: payment, contracting, production deployment or publication, destructive production mutation, real permission grants, sensitive-data transmission and required legal/security/human approval remain named external confirmations. Any conflicting, user-reserved, missing-preference or unsupported semantic remains `decision_required`.
-9. Run read-only `ty-context long-task preflight <workdir>`, repair every error and `decision_required` finding in the same Draft, then formally Compile only when ready.
+9. Give every Check an atomic Given/When scenario and journey role; give every Assertion the minimum all-of Evidence Capabilities that can actually prove its Claim. Separate required success and degradation Checks. Type every external confirmation with impacted Claim refs and target-blocking effect. Run read-only `ty-context long-task preflight <workdir>`, repair every error and `decision_required` finding in the same Draft, then formally Compile only when ready.
 10. When the first Compile returns `execution_model_checkpoint.required: true`, stop before implementation and ask the user to choose `continue_current_model` or switch models and then resume the active Long-Task. A task-specific choice already stated explicitly satisfies the checkpoint. Later revisions return `required: false` and do not repeat it.
 
 Architecture quality uses the existing authority model, not a new gate: when Source or controlling Context declares an architecture invariant, encode it as a Source-backed technical obligation/global constraint/forbidden shortcut plus owner/path/Binding boundaries and a project-owned executable Check. Functional acceptance cannot substitute when the architecture claim can fail independently. An unverifiable design preference remains task-local, durable Context or `decision_required`; it must not be promoted into false proof.
 
 ## Rolling Execution
 
-After Authority Lock and the one-time execution-model checkpoint are satisfied, implement dependency-ready Outcomes in the current workspace. Small implementation plans and repair hypotheses are internal execution state and cannot silently change Product, Technical or Acceptance authority.
+After Authority Lock and the one-time execution-model checkpoint are satisfied, implement only Outcomes in the derived current Stage frontier, plus prerequisite regression repairs and current Finding repairs, in the current workspace. A later Stage cannot substitute for an unpassed earlier gate. Small implementation plans and repair hypotheses are internal execution state and cannot silently change Product, Technical or Acceptance authority.
 
 Re-evaluate `Context Delta` whenever implementation or repair discovers a durable fact. Controlling Context changes use protected revision; graph-derived, non-explicit `implementation-index` and `archive` are Supporting Context in referenced mode and may auto-revise when only navigation/background changed. Full snapshot mode treats every selected Context file as controlling.
 
 Use targeted `verify --outcome/--check` only to drive repair. Progress is repair evidence only and never acceptance authority. Keep precise findings attached to the owning Source item, Claim, Assertion, Check, Binding and owner path. Do not add another model-switch pause or coordinate parallel subagents.
 
-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 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. Every required target is proved separately from its root; Browser evidence requires Playwright and Native/Desktop evidence requires the project binary. After accumulated changes to declared `input_paths` or Binding carriers make the result stale, rerun 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 or per-target progress state.
 
 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.
 
@@ -73,7 +73,7 @@ When implementation discovers a blocker or missing Contract paths, first classif
 
 Complete Context, implementation and project tests, create a clean candidate commit, then run `ty-context long-task final-gate <workdir>`.
 
-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.
+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. It derives Stage results and target qualification from that run; it does not trust targeted Progress as a Stage pass. A target-runtime Check must exercise its exact 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`; 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.
 
@@ -81,4 +81,4 @@ Before invoking platform-native Goal completion, perform one veto-only conforman
 
 ## Handoff
 
-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.
+Report implementation, effective risk, Claim Coverage, Stage frontier/results, declared target profile, exact `target_state`, 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. Contract target states are only `implementation_complete`, `target_profile_usable` and `production_release_ready`; terminal failure uses `not_accepted` or `blocked_external`. Never shorten targeted progress to “Outcome complete” or invent per-platform progress/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

@@ -6,7 +6,7 @@ Read this before Preflight, Compile, revision, resume, targeted verify, Final Ga
 
 Run `ty-context long-task preflight <workdir>` before first formal Compile. Resolve every `error` and `decision_required` diagnostic and review warnings. Preflight is read-only: it creates no Active Authority, initial base, marker, cache, Progress, Receipt or pending revision, runs no project Check and persists no success record.
 
-Preflight and Compile call the same activation-safety validator. Skipping Preflight bypasses no Source continuity, criterion, Claim/all-of-surface, adapter/Observation, risk, owner/path/Binding, runner/input, Counterfactual or sensitivity rule.
+Preflight and Compile call the same activation-safety validator. Skipping Preflight bypasses no Source continuity, criterion, Claim/all-of-surface, Stage closure/cross-surface gate, required-target/root/runner binding, scenario/journey separation, capability adequacy, typed external impact, bounded Product Conformance, adapter/Observation, risk, owner/path/Binding, runner/input, Counterfactual or sensitivity rule.
 
 Preflight keeps every independently discovered diagnostic. When a structural duplicate makes the same Claim ambiguous or repeated, only that pair receives stable `diagnostic_id`, `repair_group`, `repair_priority` and `blocked_by` metadata so the structural blocker is repaired first. Independent findings keep their compact existing shape; no finding is hidden, reclassified or treated as resolved, and no repair state or authority is created.
 
@@ -18,9 +18,9 @@ Its JSON result includes `execution_model_checkpoint.required: true`. Before pro
 
 After Authority Lock, every revision compares against active authority and follows one of three paths:
 
-1. proven monotonic evidence strengthening, pure verifier relocation, proven tightening and supporting-only Context revision may auto-revise;
+1. proven monotonic evidence strengthening—including adding capabilities while preserving every existing Assertion meaning—pure verifier relocation, proven tightening and supporting-only Context revision may auto-revise;
 2. a candidate whose only protected reasons are owner, expected-change or allowed-support expansion remains inactive but may be exercised with `diagnose-revision` through existing active Check identities whose runner/verifier authority is unchanged; safe monotonic strengthening may coexist; or
-3. every semantic change, proof weakening, runner or verifier-content change, risk change or other protected reason requires the exact revision identity and is never candidate-executed.
+3. every Source/Product/target profile/required-target/Stage/success-degradation/external-impact semantic change, removed capability or scenario step, root-to-internal move, proof weakening, runner or verifier-content change, risk change or other protected reason requires the exact revision identity and is never candidate-executed.
 
 `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.
 
@@ -42,14 +42,16 @@ Progress freshness binds Outcome authority, runner, verification inputs, Control
 
 Status, Progress, Receipts and workdir compiled output are audit/recovery projections only. Development-period authority state is `manual_required` and never migrated.
 
-Report their exact meaning: `progress_passing` is current targeted repair evidence rather than “Outcome complete”; `progress_stale` is not a current pass; `final_workflow_status: null` means the Goal is unfinished. Do not invent `implementation_complete`, `platform_smoke_verified` or another persistent completion vocabulary.
+Report their exact meaning: `progress_passing` is current targeted repair evidence rather than “Outcome complete”; `progress_stale` is not a current pass; `final_workflow_status: null` means the Goal is unfinished. `status`/`resume` derive `ready_stages`, `ready_outcomes` and Stage status from current Progress; they do not persist a Stage pass. `target_state` remains `not_accepted` until a fresh Final Gate accepts, becomes `blocked_external` for a target blocker, or names the Contract's `implementation_complete`, `target_profile_usable` or `production_release_ready` state after machine acceptance. Do not invent per-platform progress/status.
 
 ## Final Gate And Terminal Paths
 
-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`.
+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 exact target again in that Final Gate execution; rereading historical status does not become live proof merely because the reader reran. The Receipt reports the target profile/state and every Stage as `passed`, `failed`, `blocked_external` or `blocked_dependency`. 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. 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.
+
+An older `long-task-delivery-v2` Contract that lacks Stage, required-target, scenario, journey, success/degradation, capability or typed external-impact fields is a manual migration. `upgrade --check` reports `long-task-v2-semantic-drift-authority`, and parsing lists missing field paths. Re-author those meanings from Source; never infer them from old Progress/Receipts or import historical passing evidence as acceptance.

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

@@ -31,6 +31,14 @@ For every Outcome declare:
 
 Global non-goals, constraints and forbidden shortcuts remain Global authority and use Global Checks/Assertions when machine proof is required.
 
+## Stage And Target Profile
+
+- Declare one ordered `stages` DAG in the same Contract. Every Outcome belongs to exactly one Stage; every Stage names one gate Outcome; the gate transitively depends on every other Outcome in that Stage; and every later Stage Outcome transitively depends on every prerequisite gate.
+- A Stage Gate is not a second Final Gate or Receipt. It is one or more `stage_gate` Checks owned by the gate Outcome, and its status/frontier is derived from ordinary Outcome Progress.
+- A multi-Outcome Stage Gate declares `cross_surface_consistency`. Its runtime record names at least two distinct `surface_ref` values, may use the same runtime target for several pages, and proves one matching state version.
+- `task.target_profile` declares `required_state` plus a non-empty, duplicate-free `required_target_refs`. Each ref resolves to a `product` execution target with one bounded runtime family and root entrypoint. Every Stage Gate and every `critical_user_path` Outcome provides root `target_runtime` proof for every required ref; optional support/observer targets never substitute.
+- Use `implementation_complete` only when code-level implementation is the selected target, `target_profile_usable` when the declared required targets must be usable, and `production_release_ready` only when release gates are part of the selected target. These are terminal target qualifications, not Outcome progress states.
+
 ## Architecture Closure
 
 Architecture protection is risk-triggered and project-specific. Use it when the delivery declares module ownership, unique source of truth, dependency direction, API/schema/data boundary, state lifecycle, persistence/recovery, security boundary, compatibility/migration or a forbidden bypass.
@@ -47,7 +55,7 @@ Do not encode subjective “clean architecture” or generic quality prose as ma
 
 ## Proxy And Target Runtime Independence
 
-When a declared result can pass on a proxy surface while failing in its target runtime, author independent target-runtime proof. Put the project-owned live Check in the earliest Outcome that owns the first runnable target boundary rather than postponing it to a terminal release/quality Outcome.
+When a declared result can pass on a proxy surface while failing in its target runtime, author independent target-runtime proof for the exact required target ref. Put the project-owned live Check in the earliest Outcome that owns the first runnable target boundary rather than postponing it to a terminal release/quality Outcome.
 
 Use existing Contract semantics:
 
@@ -57,7 +65,13 @@ Use existing Contract semantics:
 4. freeze runner helpers/configuration as `verification_inputs` and declare only genuine environment requirements; and
 5. add capability-specific probes only for Claims that actually require them.
 
-A proxy check, static repository shape, tracked status report, prior screenshot, binary or historical run cannot be the sole proof of a Claim that can fail independently in the target. Do not add `platform_impact` flags, a platform taxonomy or per-platform completion state: Check ownership, proof surfaces, declared inputs, Bindings and risk already express the necessary boundary.
+A proxy check, static repository shape, tracked status report, prior screenshot, binary or historical run cannot be the sole proof of a Claim that can fail independently in the target. Use only the bounded execution-target runtime families and required refs in the Contract; do not add open-ended `platform_impact` flags or per-platform Progress state.
+
+## Success, Degradation And External Boundaries
+
+- Set `success_path_required` and `degradation_path_required` explicitly. A Result Claim is proved only by a `success` Check; the same Check cannot be both success and degradation, and an honest unavailable/pending/recovery state cannot replace required success.
+- External confirmations declare `kind`, exact `impact_claims` and `blocks_target`. A `functional_prerequisite` blocks the selected target; a `production_release_gate` blocks a production-release target but may remain non-blocking for a lower target. Reclassification or impact changes are protected authority.
+- `boundary_invocation` and `external_side_effect` are machine evidence only when their Check executes on a declared independent `observer` target. Product self-report never proves the downstream effect.
 
 ## Visual Delivery Authoring
 
@@ -79,6 +93,6 @@ This guidance adds no visual Schema, Claim kind, risk level, lifecycle state, co
 
 Compact V2 may omit only deterministic defaults: empty optional arrays/nulls, `context_snapshot_mode: referenced`, `requested_level: auto`, runner `argv: []`, `cwd: .`, `timeout_ms: 30000`, `retry_policy: none`, `idempotent: false`, and empty output/artifact/assertion/environment lists.
 
-Goal, Source/Source Claims, Context, observable results, owners/paths, REQ, applicable CTRL states, OBL, proof surfaces, runner targets/effects, verification inputs, Assertions, risk, forbidden shortcuts and external confirmations remain explicit.
+Goal, target profile/required targets, ordered Stages, Source/Source Claims, Context, observable results, success/degradation requirements, owners/paths, REQ, applicable CTRL states, OBL, proof surfaces, Given/When scenarios, journey roles, Evidence Capabilities, runner targets/effects, verification inputs, Assertions, risk, forbidden shortcuts and typed external confirmations remain explicit.
 
 Compiler-generated Outcome/Check/Claim identities replace handwritten mechanical cross-entity references. This does not authorize compiler inference of product meaning, owners, architecture, proof or risk.

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

@@ -17,9 +17,18 @@ Evidence adapter is derived from runner kind. Only Playwright may prove `ui_brow
 
 Across all Checks sharing a Raw Execution, one Claim-bearing Observation belongs to one Assertion. Shared setup may execute once only when independent per-Check observations and artifacts remain unambiguous.
 
+## Scenario And Evidence Capabilities
+
+- Every Check declares non-empty keyed `scenario.given` and `scenario.when` steps. One Check covers one materially coherent journey; a different success path belongs in another Check or vertical Outcome.
+- Every Assertion declares a non-empty all-of `evidence_capabilities` set. `presence` proves static existence only and cannot alone prove a behavioral Claim. Each other capability requires exactly one typed current-execution record bound to the declared Assertion key; missing, duplicate, unknown or undeclared records fail closed.
+- `interaction_trace` names the exact target plus the declared Given keys and ordered action keys. Playwright derives it only from an executed declared AC carrying matching `[given:<key>]` and `[action:<key>]` steps; `[ac:<assertion-key>]` remains the AC binding.
+- `state_delta` requires different before/after hashes and named changed fields. `durable_readback` requires independent write/read sessions with equal state hashes. `cross_surface_consistency` requires at least two distinct surface refs, known target refs and one state hash.
+- `boundary_invocation` and `external_side_effect` require the Check itself to execute on the named observer target. `failure_injection` requires an observed fault and recovery state; `visual_render` binds a declared artifact hash; `target_runtime` binds exact target/root/current session and requires a cold start for a root journey; `input_variation` requires at least two distinct inputs, differing propagated outputs and an observed failure case.
+- Structured runners emit `long-task-check-result-v3` for capability records. V2 payloads remain decodable only for presence-only compatibility; they cannot satisfy a declared non-presence capability. Evidence records contain bounded hashes/ids/refs, not unrestricted raw payloads.
+
 ## Live Target Runtime Evidence
 
-- For a target-runtime Claim, the accepting Check must exercise that target during the current runner invocation and derive structured Observations from the same runtime session. Rerunning a parser for a tracked or generated status report reruns the parser, not the target.
+- For a target-runtime Claim, the accepting Check must exercise the exact declared required target during the current runner invocation and derive structured Observations from the same runtime session. Browser target runtime is proved only by Playwright; Native/Desktop target runtime is proved only by the project binary. Rerunning a parser for a tracked or generated status report reruns the parser, not the target.
 - A proxy surface may prove its own Claim but cannot substitute when proxy and target can fail independently. Static source/config shape proves structure only. The existence of a build, installation, started process or clean fatal-error scan proves only those exact assertions.
 - If the declared result includes a runnable product surface or interaction, observe a stable product-owned sentinel or the declared interaction in the target session. A generic process/activity/window, development shell or absence of errors is insufficient for that broader Claim.
 - 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.
@@ -32,6 +41,8 @@ Across all Checks sharing a Raw Execution, one Claim-bearing Observation belongs
 - 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.
 
+For semantic Product Conformance, require one separate read-only Global `conformance` Check only when `weak_observability` combines with multiple Stages or multiple required product runtime families. It starts from a required root product target, includes `target_runtime`, uses a Raw Execution identity independent of Outcome Checks and runs inside the existing Final Gate. Single-Stage/single-family weak work keeps the existing same-Check sensitivity path and does not pay this extra runtime cost.
+
 ## 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.

package/dist/commands/long-task-authoring.js

@@ -28,6 +28,17 @@ task:
   id: replace-me
   title: Replace me
   goal: Describe the complete observable delivery goal.
+  target_profile:
+    key: replace-target
+    description: The declared product target is usable from its root entrypoint.
+    required_state: target_profile_usable
+    required_target_refs: [replace-runtime]
+  execution_targets:
+    - key: replace-runtime
+      description: The product runtime used by the acceptance oracle.
+      role: product
+      runtime_family: process
+      root_entrypoint: tests/replace-oracle.mjs
   source_paths: [plans/replace-me.md]
   context_refs: [project_context/areas/replace-me.md]
 source_claims:
@@ -37,14 +48,22 @@ source_claims:
     disposition:
       type: claim
       refs: [replace-outcome.requirement.replace-requirement]
+stages:
+  - key: delivery
+    title: Delivery
+    depends_on: []
+    gate_outcome: replace-outcome
 risk:
   facts: {}
 global: {}
 outcomes:
   - key: replace-outcome
     title: Replace outcome
+    stage: delivery
     product:
       observable_result: Describe what a user or system can observe.
+      success_path_required: true
+      degradation_path_required: false
       owner:
         label: replace-owner
         context_refs: [project_context/areas/replace-me.md]
@@ -64,6 +83,11 @@ outcomes:
     acceptance:
       checks:
         - key: replace-check
+          journey_roles: [success, stage_gate]
+          execution_target: {target_ref: replace-runtime, entrypoint: root}
+          scenario:
+            given: [{key: source-ready, statement: The planned source carrier is available.}]
+            when: [{key: inspect-result, statement: Inspect the product result through the declared runtime.}]
           proof_surface: runtime_behavior
           runner:
             type: node_oracle
@@ -77,6 +101,7 @@ outcomes:
               criterion: The declared outcome and requirement are observable.
               claims: [result, requirement.replace-requirement]
               observation: result
+              evidence_capabilities: [state_delta, target_runtime]
               operator: equals
               expected: true
       counterfactual_controls:

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,
+            target_profile: result.target_profile,
+            target_state: result.target_state,
+            stage_results: result.stage_results,
             acceptance_scope: result.acceptance_scope,
             closed_scope: result.closed_scope,
             native_goal_effect: result.native_goal_effect,