project-tiny-context-harness 0.8.2 → 0.8.4

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

@@ -1,120 +1,120 @@
-# Contract Authoring Reference
-
-Read this only while authoring or structurally revising the one `delivery-contract.yaml` Draft.
-
-## Source And Semantic Boundary
-
+# Contract Authoring Reference
+
+Read this only while authoring or structurally revising the one `delivery-contract.yaml` Draft.
+
+## Source And Semantic Boundary
+
 - Every declared Source file contains at least one Material Source Item. Mark items in original Markdown without rendering or changing meaning. Every other non-empty line belongs to the one schema-valid `design-resource-handoff-v1` formal block or a closed-grammar background block: `markdown-structure` permits only text-free anchors/horizontal rules and `provenance` permits only `ty-source-provenance` comments with fixed `input`, `mode`, conditional `source` and optional `sha256` fields. A text-bearing heading or free-form provenance field may carry authority and cannot be background. Arbitrary background prose and every other unclassified line fail closed.
-- Marker keys and `source_claim` keys are set-equal and globally unique. `statement` preserves marked text after line-ending normalization, surrounding blank-line removal and trailing-space cleanup.
-- Typed dispositions keep Result, Requirement, Control, Technical Obligation, Non-completing Claim, Acceptance, Global Constraint/Non-goal, Forbidden Shortcut, Risk, External Confirmation and Decision distinct.
-- Every non-decision Source item owns exactly one same-kind, text-identical canonical target; no target may collapse multiple Source items. `out_of_scope` is not a resolution.
+- Marker keys and `source_claim` keys are set-equal and globally unique. `statement` preserves marked text after line-ending normalization, surrounding blank-line removal and trailing-space cleanup.
+- Typed dispositions keep Result, Requirement, Control, Technical Obligation, Non-completing Claim, Acceptance, Global Constraint/Non-goal, Forbidden Shortcut, Risk, External Confirmation and Decision distinct.
+- Every non-decision Source item owns exactly one same-kind, text-identical canonical target; no target may collapse multiple Source items. `out_of_scope` is not a resolution.
 - A Source AC maps criterion-identically to one named Assertion and proves at least one independently Source-backed non-Result Claim.
 - At least one `technical_obligation` Source Item has `aspect=architecture`, maps text-identically to a named architecture obligation and is independently provable; a generic Result or unmarked architecture review cannot substitute.
-- Missing recommended legacy Source Plan headings or keys never blocks authoring. Raw/mixed inputs enter this Contract Draft immediately; apply `source-authoring.md` alongside mapping until real Source, provenance and markers converge. Missing mandatory Material Source Item markers still blocks Preflight/Compile.
-- A revised initial proposal and selected design resources are parallel Source inputs. Preserve their stable resource/surface/control/state/target keys, declared conditions, provider/project/run/entry provenance and immutable digest/snapshot; do not flatten visual meaning into an untraceable prose summary.
-- `delegated` in a Source Plan is provenance, not a Contract disposition or new Claim kind. An instruction to synthesize, refine, complete, implement or use judgment delegates plan-level authoring, but it does not invent material tradeoff preferences. Before comparative research or a material product, technical, architecture or provider selection, identify the criteria that could change the research scope, candidate set or recommendation. If such a preference is unknown or ambiguous, ask a concise targeted question before research or selection and keep the item `decision_required` until answered; do not impose a fixed questionnaire or re-ask preferences already supplied by the user, Source, Context or controlling constraints.
-- Once the material preference envelope is clear, use current authoritative or primary evidence for external capability, price, quota, license, compatibility, region, security posture or support claims. When one defensible recommendation exists, record the authoring instruction, preference/evidence or conservative-default basis and exact added meaning in real Source, then preserve that keyed item as ordinary Source of its semantic kind. If ordinary prose is the Source, append the delegated item without rewriting the user's original text; never place the choice only in Contract YAML.
-- A delegated plan choice is not action authorization. Payment, contracting, production deployment/publication, destructive production mutation, real permission grants, sensitive-data transmission and required legal/security/human approval remain named External Confirmations. Conflicting authority, an explicitly user-reserved choice, a missing material preference or the absence of a defensible recommendation remains `decision_required`; high impact or multiple options with known criteria alone does not.
-- A rolling implementation blocker is not an External Confirmation merely because work is difficult, delayed or unavailable through the current implementation path. Reclassify or remove machine-verifiable scope only through an explicit marked Source change and protected exact approval; otherwise keep the requirement and revise the implementation/evidence path.
-
-## Outcome Boundary
-
-Create an Outcome only when its result is independently observable, decidable, target-verifiable, dependency-expressible and localizable to its own Claims, Assertions, Checks and owner boundary. Requirement coupling, acceptance/verification-ready projection, targeted verification, precise failure localization, semantic resume and stale-result invalidation are valid reasons to decompose. Outcome boundaries never restrict implementation order. File count, implementation layer, context length, desired parallelism and Agent capacity are not.
-
-For every Outcome declare:
-
-- one complete observable result;
-- atomic requirements and actually applicable controls/states;
-- non-completing claims;
-- owner Context/surfaces and expected/support/forbidden path envelopes;
-- stable technical obligations, Bindings, forbidden shortcuts and recovery requirements;
-- risk facts;
-- executable Checks and named AC Assertions.
-
-Global non-goals, constraints and forbidden shortcuts remain Global authority and use Global Checks/Assertions when machine proof is required.
-
+- Missing recommended legacy Source Plan headings or keys never blocks authoring. Raw/mixed inputs enter this Contract Draft immediately; apply `source-authoring.md` alongside mapping until real Source, provenance and markers converge. Missing mandatory Material Source Item markers still blocks Preflight/Compile.
+- A revised initial proposal and selected design resources are parallel Source inputs. Preserve their stable resource/surface/control/state/target keys, declared conditions, provider/project/run/entry provenance and immutable digest/snapshot; do not flatten visual meaning into an untraceable prose summary.
+- `delegated` in a Source Plan is provenance, not a Contract disposition or new Claim kind. An instruction to synthesize, refine, complete, implement or use judgment delegates plan-level authoring, but it does not invent material tradeoff preferences. Before comparative research or a material product, technical, architecture or provider selection, identify the criteria that could change the research scope, candidate set or recommendation. If such a preference is unknown or ambiguous, ask a concise targeted question before research or selection and keep the item `decision_required` until answered; do not impose a fixed questionnaire or re-ask preferences already supplied by the user, Source, Context or controlling constraints.
+- Once the material preference envelope is clear, use current authoritative or primary evidence for external capability, price, quota, license, compatibility, region, security posture or support claims. When one defensible recommendation exists, record the authoring instruction, preference/evidence or conservative-default basis and exact added meaning in real Source, then preserve that keyed item as ordinary Source of its semantic kind. If ordinary prose is the Source, append the delegated item without rewriting the user's original text; never place the choice only in Contract YAML.
+- A delegated plan choice is not action authorization. Payment, contracting, production deployment/publication, destructive production mutation, real permission grants, sensitive-data transmission and required legal/security/human approval remain named External Confirmations. Conflicting authority, an explicitly user-reserved choice, a missing material preference or the absence of a defensible recommendation remains `decision_required`; high impact or multiple options with known criteria alone does not.
+- A rolling implementation blocker is not an External Confirmation merely because work is difficult, delayed or unavailable through the current implementation path. Reclassify or remove machine-verifiable scope only through an explicit marked Source change and protected exact approval; otherwise keep the requirement and revise the implementation/evidence path.
+
+## Outcome Boundary
+
+Create an Outcome only when its result is independently observable, decidable, target-verifiable, dependency-expressible and localizable to its own Claims, Assertions, Checks and owner boundary. Requirement coupling, acceptance/verification-ready projection, targeted verification, precise failure localization, semantic resume and stale-result invalidation are valid reasons to decompose. Outcome boundaries never restrict implementation order. File count, implementation layer, context length, desired parallelism and Agent capacity are not.
+
+For every Outcome declare:
+
+- one complete observable result;
+- atomic requirements and actually applicable controls/states;
+- non-completing claims;
+- owner Context/surfaces and expected/support/forbidden path envelopes;
+- stable technical obligations, Bindings, forbidden shortcuts and recovery requirements;
+- risk facts;
+- executable Checks and named AC Assertions.
+
+Global non-goals, constraints and forbidden shortcuts remain Global authority and use Global Checks/Assertions when machine proof is required.
+
 Declare only real applicability, not a blind Cartesian product. Each global or Outcome profile names one exact execution target, journey role, a non-empty duplicate-free set of atomic dimension assignments, keyed Given condition/input/state facts and ordered When actions. One profile cannot bundle phone/tablet, light/dark, default/loading or other multiple values of the same dimension. Every Claim-bearing fact lists all and only its applicable profile refs. Every Claim-bearing Assertion proves exactly one Claim in exactly one matching profile, and every required proof surface of every actual applicable cell has an attributable Assertion. Two cells may share one Check execution only when their individual Assertion failures remain distinguishable; risk-based, pairwise, representative or sampled coverage never substitutes for a declared applicable cell.
-
-## Feedback-cost boundary
-
-Declare each Check's `input_paths` and Binding carriers as the smallest sound causal envelope for that Check. Do not use a repository, application or platform root merely because it is convenient: a broad pattern is justified only when any matching change can actually invalidate the declared result. If independent capabilities have different invalidation surfaces or useful feedback boundaries, assign them to the owning Outcomes/Checks rather than making every early Stage gate stale.
-
-Every Counterfactual mutation path must be a current production carrier with a defensible route from the declared target root to the asserted behavior. Review `verify --explain` before an expensive first execution and repair obsolete routes, barrels, fixtures or duplicate Main/Counterfactual invocations. Preflight cannot claim language/runtime reachability from a path name alone; when repository evidence cannot establish that route, the current-execution Counterfactual remains the proof.
-
-Declare cheap machine-checkable prerequisites through existing environment requirements and verification inputs. Product/API readiness probes, incremental build caches, streaming phase output, timeout heartbeats and descendant-process cleanup belong to the project-owned runner when they depend on its runtime; do not encode them as Harness business logic.
-
-## 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.
+
+## Feedback-cost boundary
+
+Declare each Check's `input_paths` and Binding carriers as the smallest sound causal envelope for that Check. Do not use a repository, application or platform root merely because it is convenient: a broad pattern is justified only when any matching change can actually invalidate the declared result. If independent capabilities have different invalidation surfaces or useful feedback boundaries, assign them to the owning Outcomes/Checks rather than making every early Stage gate stale.
+
+Every Counterfactual mutation path must be a current production carrier with a defensible route from the declared target root to the asserted behavior. Review `verify --explain` before an expensive first execution and repair obsolete routes, barrels, fixtures or duplicate Main/Counterfactual invocations. Preflight cannot claim language/runtime reachability from a path name alone; when repository evidence cannot establish that route, the current-execution Counterfactual remains the proof.
+
+Declare cheap machine-checkable prerequisites through existing environment requirements and verification inputs. Product/API readiness probes, incremental build caches, streaming phase output, timeout heartbeats and descendant-process cleanup belong to the project-owned runner when they depend on its runtime; do not encode them as Harness business logic.
+
+## 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, root entrypoint and explicit capabilities. A required product target declares its family capability plus `cold-start` and `production-root`; 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 Deliberation And Closure
-
-Architecture Deliberation occurs once for every implementation delivery before formal Compile and the first implementation edit; risk changes depth, not occurrence. Surface concise conclusions and repository evidence rather than private chain-of-thought. A preservation result still names the concrete owner/extension point and explains why durable boundaries and debt do not worsen. Material work covers module ownership, unique source of truth, dependency direction, API/schema/data boundary, state lifecycle, persistence/recovery, security boundary, compatibility/migration, selected and rejected alternatives, one plausible future-change challenge, touched technical debt and forbidden bypasses.
-
-Represent every material falsifiable invariant with existing Contract fields:
-
-1. a Source-backed technical obligation, global constraint or forbidden shortcut;
-2. owner Context and expected/support/forbidden paths;
-3. a Binding to the implementation carrier when Counterfactual sensitivity is required;
-4. a project-owned executable architecture check, such as the repository's lint, AST, dependency or contract test;
-5. a separate Assertion when functional behavior could pass while the architecture invariant fails.
-
-New or worsened debt is unacceptable unless a project-owned bounded exception identifies owner, rationale, tracking and removal/expiry condition. Unrelated legacy debt does not automatically expand delivery scope, but debt touched, relied on or worsened by the implementation cannot remain hidden. Material changes to scope, owner, Context, dependency direction, selected design or debt disposition refresh the deliberation and, after Authority Lock, use protected revision.
-
-Do not encode subjective “clean architecture” or generic quality prose as machine authority. If no reliable observation can falsify it, keep it as durable Context/review judgment or return `decision_required`. Harness routes the repository's architecture check; it does not become a language-generic dependency analyzer. Final Gate is the only Long-Task Architecture Conformance carrier and reruns these declared Checks on its current snapshot; do not add a default-workflow closure, architecture field, second Gate or state.
-
-## 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 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; this assigns proof ownership and does not dictate implementation order.
-
-Use existing Contract semantics:
-
-1. require `runtime_behavior` or the other proof surface that matches the actual Claim;
-2. make the accepting runner exercise the target during the current Raw Execution and derive its asserted Observation from that same session;
-3. include the runtime-affecting entrypoints, dependency manifests/lockfiles, configuration and integration carriers in `input_paths` or Bindings as appropriate;
+- 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 Deliberation And Closure
+
+Architecture Deliberation occurs once for every implementation delivery before formal Compile and the first implementation edit; risk changes depth, not occurrence. Surface concise conclusions and repository evidence rather than private chain-of-thought. A preservation result still names the concrete owner/extension point and explains why durable boundaries and debt do not worsen. Material work covers module ownership, unique source of truth, dependency direction, API/schema/data boundary, state lifecycle, persistence/recovery, security boundary, compatibility/migration, selected and rejected alternatives, one plausible future-change challenge, touched technical debt and forbidden bypasses.
+
+Represent every material falsifiable invariant with existing Contract fields:
+
+1. a Source-backed technical obligation, global constraint or forbidden shortcut;
+2. owner Context and expected/support/forbidden paths;
+3. a Binding to the implementation carrier when Counterfactual sensitivity is required;
+4. a project-owned executable architecture check, such as the repository's lint, AST, dependency or contract test;
+5. a separate Assertion when functional behavior could pass while the architecture invariant fails.
+
+New or worsened debt is unacceptable unless a project-owned bounded exception identifies owner, rationale, tracking and removal/expiry condition. Unrelated legacy debt does not automatically expand delivery scope, but debt touched, relied on or worsened by the implementation cannot remain hidden. Material changes to scope, owner, Context, dependency direction, selected design or debt disposition refresh the deliberation and, after Authority Lock, use protected revision.
+
+Do not encode subjective “clean architecture” or generic quality prose as machine authority. If no reliable observation can falsify it, keep it as durable Context/review judgment or return `decision_required`. Harness routes the repository's architecture check; it does not become a language-generic dependency analyzer. Final Gate is the only Long-Task Architecture Conformance carrier and reruns these declared Checks on its current snapshot; do not add a default-workflow closure, architecture field, second Gate or state.
+
+## 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 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; this assigns proof ownership and does not dictate implementation order.
+
+Use existing Contract semantics:
+
+1. require `runtime_behavior` or the other proof surface that matches the actual Claim;
+2. make the accepting runner exercise the target during the current Raw Execution and derive its asserted Observation from that same session;
+3. include the runtime-affecting entrypoints, dependency manifests/lockfiles, configuration and integration carriers in `input_paths` or Bindings as appropriate;
 4. freeze runner helpers/configuration as `verification_inputs`; recursively freeze every statically resolvable local JS/TS import/re-export/require and JSON dependency, reject unresolved dynamic loaders, and permit a package-script runner only when its static Node entry closure is recoverable; 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. 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
-
-When the selected delivery includes a new/redesigned screen, primary layout/navigation/theme/component system, high-fidelity implementation or other material production UI, resolve Design Authority before Compile and author the result through existing Contract semantics:
-
-- when selected external resources are an implementation handoff, place one strict marked `design-resource-handoff-v1` Markdown file in `task.source_paths` and run `ty-context design-resource preflight <handoff.md>` before Contract Preflight. The handoff must close every applicable subject × target × condition cell across all eight UI/UX dimensions, resolve typed locators against immutable resources and bind covered cells to Source Items and verification methods. Web/App profiles require a canonical entry, exact declared dependency closure and complete acquisition; unresolved/stale/unsupported/partial input blocks. Treat candidates and unresolved decisions honestly; only a selected exact target with a valid selection basis, declared condition coverage and immutable identity can be proposed for fidelity authority, and downstream UI Authority Closure still owns adoption;
-- perform UI Authority Closure over stable surface/control/target keys: classify each material item as covered by owning Context/`DESIGN.md`, requiring an owner update, task-local Source, explicitly out of scope or genuinely `decision_required`. Product Surface Context owns cross-surface responsibility, Screen/interaction Context owns durable hierarchy/behavior, `DESIGN.md` owns visual-system/reference semantics and selected targets own concrete composition; Contract YAML must not duplicate or invent those owners;
-- inspect owning surface/interaction Context, `DESIGN.md`, its authored token source/generation direction and material design references. Classify every reference as `exact-target`, `constraint` or `inspiration`, with its surface/route/component, path/URI and covered viewport/theme/mode/state;
-- an unconfigured starter, style-only prose, inspiration-only set or conflicting target is not sufficient production authority. Resolve it by explicitly scoping Source to a prototype/non-fidelity result, recording an explicitly delegated and selected design target in real Source after material preferences are known, or keeping the unresolved/user-reserved direction `decision_required`;
-- never let implementation output authorize itself: a generated implementation screenshot/diff is an Artifact, not the target. An acceptance-affecting target or baseline must be selected Source/verifier input before fidelity implementation can be accepted;
-- derive the exact task-local Visual Coverage Set from declared Source, `project_context/**` and `DESIGN.md`: production surface/route/component, viewport, theme or product mode, interaction/state, content stress and accessibility/motion conditions. Do not invent an irrelevant Cartesian product, but cover every combination that is actually applicable;
-- never use risk-based, pairwise, representative or sampled combinations to waive an applicable cell. Equivalent execution may be shared only when each fact/method retains an independently attributable Assertion and any omitted applicable combination remains blocking;
-- encode each independently falsifiable visual expectation as an atomic Requirement, applicable Control field or named AC Assertion. Name the surface, viewport, theme/state/content condition and observable result when they matter to the claim;
-- close every real Control's canonical fields independently through `field_coverage`: `surface`, `region`, `location`, `control_type`, `label_content`, `user_task`, `visibility`, `availability`, `trigger`, `input`, `validation`, `default_value`, `interaction`, `navigation_result`, `loading_state`, `empty_state`, `success_state`, `failure_state`, `recovery`, `permission`, `feedback` and `accessibility`. `specified` names concrete meaning, `not_applicable` carries a falsifiable reason, and `unresolved` blocks Compile; specified and not-applicable entries create Claims for every declared applicability profile, so omission can never silently mean non-applicable;
+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. 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
+
+When the selected delivery includes a new/redesigned screen, primary layout/navigation/theme/component system, high-fidelity implementation or other material production UI, resolve Design Authority before Compile and author the result through existing Contract semantics:
+
+- when selected external resources are an implementation handoff, place one strict marked `design-resource-handoff-v1` Markdown file in `task.source_paths` and run `ty-context design-resource preflight <handoff.md>` before Contract Preflight. The handoff defaults to complete observable design fact granularity rather than Product Control granularity: it atomically indexes every supported in-scope element/primitive/layout/style/content/state/behavior fact, closes every resource as material-with-facts or honestly supporting-only, closes every applicable subject × target × condition cell across all eight UI/UX dimensions, resolves typed locators against immutable resources and binds covered cells to exact fact/Source/method sets. Web/App profiles require a canonical entry, exact declared dependency closure and complete acquisition; every exact target additionally requires full-target layout and pixel facts per condition. Unresolved/stale/unsupported/partial input blocks or remains a constraint. Treat candidates and unresolved decisions honestly; only a selected exact target with a valid selection basis, declared condition coverage and immutable identity can be proposed for fidelity authority, and downstream UI Authority Closure still owns adoption;
+- perform UI Authority Closure over stable surface/control/target keys: classify each material item as covered by owning Context/`DESIGN.md`, requiring an owner update, task-local Source, explicitly out of scope or genuinely `decision_required`. Product Surface Context owns cross-surface responsibility, Screen/interaction Context owns durable hierarchy/behavior, `DESIGN.md` owns visual-system/reference semantics and selected targets own concrete composition; Contract YAML must not duplicate or invent those owners;
+- inspect owning surface/interaction Context, `DESIGN.md`, its authored token source/generation direction and material design references. Classify every reference as `exact-target`, `constraint` or `inspiration`, with its surface/route/component, path/URI and covered viewport/theme/mode/state;
+- an unconfigured starter, style-only prose, inspiration-only set or conflicting target is not sufficient production authority. Resolve it by explicitly scoping Source to a prototype/non-fidelity result, recording an explicitly delegated and selected design target in real Source after material preferences are known, or keeping the unresolved/user-reserved direction `decision_required`;
+- never let implementation output authorize itself: a generated implementation screenshot/diff is an Artifact, not the target. An acceptance-affecting target or baseline must be selected Source/verifier input before fidelity implementation can be accepted;
+- derive the exact task-local Visual Coverage Set from declared Source, `project_context/**` and `DESIGN.md`: production surface/route/component, viewport, theme or product mode, interaction/state, content stress and accessibility/motion conditions. Do not invent an irrelevant Cartesian product, but cover every combination that is actually applicable;
+- never use risk-based, pairwise, representative or sampled combinations to waive an applicable cell. Equivalent execution may be shared only when each fact/method retains an independently attributable Assertion and any omitted applicable combination remains blocking;
+- encode each independently falsifiable visual expectation as an atomic Requirement, applicable Control field or named AC Assertion. Name the surface, viewport, theme/state/content condition and observable result when they matter to the claim;
+- close every real Control's canonical fields independently through `field_coverage`: `surface`, `region`, `location`, `control_type`, `label_content`, `user_task`, `visibility`, `availability`, `trigger`, `input`, `validation`, `default_value`, `interaction`, `navigation_result`, `loading_state`, `empty_state`, `success_state`, `failure_state`, `recovery`, `permission`, `feedback` and `accessibility`. `specified` names concrete meaning, `not_applicable` carries a falsifiable reason, and `unresolved` blocks Compile; specified and not-applicable entries create Claims for every declared applicability profile, so omission can never silently mean non-applicable;
 - close each Outcome's cross-Control/system meaning through `control_relation_closure` plus `control_relations`: shared state, dependency/order, mutual exclusion, navigation, permission, recovery, validation and feedback chains are explicit relations with Control refs, proof surfaces and applicability, while `state: not_applicable` is a negative Claim with exact applicability and an explicit assertion that no such relation applies; `unresolved` blocks;
-- when an Outcome declares Controls, add the minimum aggregated Product `surface_bindings`: one stable binding per owner surface and required product target, its Control refs, existing Technical route/component Binding refs, one root-entry success Check and its real entry action. Every Control must be bound, every Control Claim must have target-local proof on the runtime-appropriate surface, and the root journey must prove each Control's declared `navigation_result` or its `interaction`/`trigger`/`location` fallback with all-of `interaction_trace` and `target_runtime`;
-- bind the declared result to the owning Context/`DESIGN.md`, one authored token source and generation direction, selected target/constraint inputs, production component/route carriers, path envelopes and project-owned target checks. Freeze acceptance-affecting selected target files, token sources and fixed prototype fixtures in `verification_inputs`; bind production carriers through `input_paths`/Bindings and reserve `artifact_globs` for generated implementation renders, diffs and reports. Detached kits, deep links, mocks or marketing specimens may be references or supplemental checks but not substitute implementation carriers or the production root journey;
-- for each selected exact/constraint target inside a surface binding, use the exact handoff target key and interpretation; declare `source_paths` as exactly the handoff plus that target's immutable resource paths and `condition_keys` as exactly its handoff condition refs. Put the same files in Check `verification_inputs`; map every covered handoff Source Item through `source_claims` to method-specific Source Claims and separate single-Claim Assertions at the target's exact applicability; and bind every handoff acceptance blocker in the surface binding. Every handoff verification method binds its own Assertion and an exact set of per-condition `evidence_artifacts`; each cell declares both `path` for its method record and `observation_path` for its primary method-native observation. Both paths are covered by the Check, primary-observation paths and current digests are pairwise distinct across methods/conditions, and typed current-execution `design_method` evidence names both. A Playwright Assertion must attach `ty-context-design-method:<target>:<method>:<condition>:record` and `...:observation` in every project instance before the adapter emits that evidence. The target-local Assertions also cover bound Control Claims, distinct current actual/comparison artifact paths and all-of `design_conformance`, `interaction_trace` and `target_runtime` where applicable. `visual_render`, handoff preflight, file hashes, counts or registry presence remain input/resource integrity and cannot substitute for implementation conformance;
+- when an Outcome declares Controls, add the minimum aggregated Product `surface_bindings`: one stable binding per owner surface and required product target, its Control refs, existing Technical route/component Binding refs, one root-entry success Check and its real entry action. Every Control must be bound, every Control Claim must have target-local proof on the runtime-appropriate surface, and the root journey must prove each Control's declared `navigation_result` or its `interaction`/`trigger`/`location` fallback with all-of `interaction_trace` and `target_runtime`;
+- bind the declared result to the owning Context/`DESIGN.md`, one authored token source and generation direction, selected target/constraint inputs, production component/route carriers, path envelopes and project-owned target checks. Freeze acceptance-affecting selected target files, token sources and fixed prototype fixtures in `verification_inputs`; bind production carriers through `input_paths`/Bindings and reserve `artifact_globs` for generated implementation renders, diffs and reports. Detached kits, deep links, mocks or marketing specimens may be references or supplemental checks but not substitute implementation carriers or the production root journey;
+- for each selected exact/constraint target inside a surface binding, use the exact handoff target key and interpretation; declare `source_paths` as exactly the handoff plus that target's immutable resource paths and `condition_keys` as exactly its handoff condition refs. Put the same files in Check `verification_inputs`; map every covered handoff Source Item through `source_claims` to method-specific Source Claims and separate single-Claim Assertions at the target's exact applicability; and bind every handoff acceptance blocker in the surface binding. Every handoff verification method binds its own Assertion and an exact set of per-condition `evidence_artifacts`; each cell declares the exact handoff `fact_refs`, `path` for its method record and `observation_path` for its primary method-native observation. The cell fact sets are pairwise owned and their union equals the target's complete handoff fact set. Both paths are covered by the Check, primary-observation paths and current digests are pairwise distinct across methods/conditions, and typed current-execution `design_method` evidence names both paths plus the exact fact set. A Playwright Assertion must attach `ty-context-design-method:<target>:<method>:<condition>:record` and `...:observation` in every project instance before the adapter emits that evidence. The target-local Assertions also cover bound Control Claims, distinct current actual/comparison artifact paths and all-of `design_conformance`, `interaction_trace` and `target_runtime` where applicable. `visual_render`, handoff preflight, file hashes, counts or registry presence remain input/resource integrity and cannot substitute for implementation conformance or omitted fact proof;
 - explicitly inventory every declared design-acceptance blocker inside its surface binding. An empty array states that no blocker is declared; each declared entry preserves exactly the handoff's `source_item_refs`, `verification_methods` and non-empty `required_capabilities`. A `machine_claim` is valid only when the exact bound execution target declares every required capability and the referenced Claims have target-local proof; otherwise use a target-blocking External Confirmation whose impact includes the Outcome. There is no in-band not-applicable waiver: removing a blocker from scope first requires explicit revised Source and, after Authority Lock, protected Contract revision. Empty refs block Compile/Final Gate;
-- use `ui_browser` only for declared browser ACs. A browser or Expo-Web proxy cannot prove a native/mobile/desktop target that can fail independently; use a project-owned current-execution target Check when existing proof surfaces can truthfully represent the claim, otherwise retain named human/device confirmation as an external confirmation rather than inventing machine proof;
-- keep subjective visual direction, taste or approval outside false machine proof. Resolve an undecided direction as `decision_required`; represent required human design or new-baseline approval as an explicit external confirmation.
-- for combined design-and-implementation delivery, ordinary design Outcomes/Stages may author candidates before selection, but candidate/planned artifacts cannot authorize fidelity Claims. Append the selected result to real marked Context-reachable Source and its owning Context/`DESIGN.md` reference; after Authority Lock adopt it through Authority Revision before downstream fidelity implementation. This creates no target-selection state, second Contract or second Gate.
-
-External design resources authorize fidelity only when they become a selected exact target with a validated handoff; they remain ordinary upstream Source rather than a Contract Draft, verification result or alternate authority. The revised initial proposal plus selected immutable canonical resources and the residual `design-resource-handoff-v1` is the recommended implementation input; no standalone Source Plan handoff is required. Map each covered Source Item into the root conformance Assertion and each declared verification method to its own independently failing Assertion; carry blocker Source Items and methods unchanged into a target-local machine Claim or target-blocking External Confirmation. A legacy Source Plan remains valid ordinary Source if supplied. The single Product `surface_bindings` projection is an aggregated cross-reference over existing Source, Controls, Technical Bindings, targets, Checks, Assertions, verification inputs and External Confirmations; it creates no `uiux_delivery` authority block, Claim kind, risk level, lifecycle state, required design directory, per-Control screenshot matrix or Gate.
-
-## Compact Authoring
-
+- use `ui_browser` only for declared browser ACs. A browser or Expo-Web proxy cannot prove a native/mobile/desktop target that can fail independently; use a project-owned current-execution target Check when existing proof surfaces can truthfully represent the claim, otherwise retain named human/device confirmation as an external confirmation rather than inventing machine proof;
+- keep subjective visual direction, taste or approval outside false machine proof. Resolve an undecided direction as `decision_required`; represent required human design or new-baseline approval as an explicit external confirmation.
+- for combined design-and-implementation delivery, ordinary design Outcomes/Stages may author candidates before selection, but candidate/planned artifacts cannot authorize fidelity Claims. Append the selected result to real marked Context-reachable Source and its owning Context/`DESIGN.md` reference; after Authority Lock adopt it through Authority Revision before downstream fidelity implementation. This creates no target-selection state, second Contract or second Gate.
+
+External design resources authorize fidelity only when they become a selected exact target with a validated handoff; they remain ordinary upstream Source rather than a Contract Draft, verification result or alternate authority. The revised initial proposal plus selected immutable canonical resources and the residual `design-resource-handoff-v1` is the recommended implementation input; no standalone Source Plan handoff is required. Map each exact fact set into method/condition evidence, each covered Source Item into the root conformance Assertion and each declared verification method to its own independently failing Assertion; carry blocker Source Items and methods unchanged into a target-local machine Claim or target-blocking External Confirmation. A legacy Source Plan remains valid ordinary Source if supplied. The single Product `surface_bindings` projection is an aggregated cross-reference over existing Source, Controls, Technical Bindings, targets, Checks, Assertions, verification inputs and External Confirmations; it creates no `uiux_delivery` authority block, Claim kind, risk level, lifecycle state, required design directory, per-Control screenshot matrix or Gate, and it creates no copied style/value source.
+
+## Compact Authoring
+
 Compact V2 may omit only deterministic defaults: empty optional arrays/nulls, `requested_level: auto`, runner `argv: []`, `cwd: .`, `timeout_ms: 30000`, `retry_policy: none`, `idempotent: false`, and empty output/artifact/assertion/environment lists. `context_snapshot_mode: full` remains explicit and is the only accepted authority mode.
-
-Goal, target profile/required targets, ordered Stages, Source/Source Claims and non-authoritative background ownership, Context, observable results, exact applicability profiles, success/degradation requirements, owners/paths, REQ, all-field CTRL closure, Control relations and production `surface_bindings`, selected target conditions/conformance artifacts, design-blocker dispositions, OBL, proof surfaces, Given/When scenarios, journey roles, Evidence Capabilities, runner targets/effects, verification inputs, single-Claim Assertions, behavioral semantic witnesses and liveness 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.
+
+Goal, target profile/required targets, ordered Stages, Source/Source Claims and non-authoritative background ownership, Context, observable results, exact applicability profiles, success/degradation requirements, owners/paths, REQ, all-field CTRL closure, Control relations and production `surface_bindings`, selected target conditions/conformance artifacts, design-blocker dispositions, OBL, proof surfaces, Given/When scenarios, journey roles, Evidence Capabilities, runner targets/effects, verification inputs, single-Claim Assertions, behavioral semantic witnesses and liveness 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

@@ -1,79 +1,79 @@
-# Evidence Design Reference
-
-Read this only while designing or repairing Contract Checks and proof.
-
-## General Proof Rules
-
-- Every Outcome has at least one executable Check and one non-Result atomic Claim.
-- Required proof surfaces are non-empty, unique and all-of. Every Claim-bearing Assertion proves exactly one Claim at one exact applicability profile and uses explicit comparable Observations and expected values; every Claim/applicability/proof-surface cell must be covered.
-- `truthy`/`falsy` are diagnostic-only. `exists` proves only implementation-structure obligations. Missing or type-incomparable Observation never proves a Claim; negative proof uses an explicit value such as `equals: false`.
-- Claim and Population proof is emitted only after the entire Check passes. Exit failure, missing artifact, failed population, failed Assertion or invalid Counterfactual yields no Claim proof.
+# Evidence Design Reference
+
+Read this only while designing or repairing Contract Checks and proof.
+
+## General Proof Rules
+
+- Every Outcome has at least one executable Check and one non-Result atomic Claim.
+- Required proof surfaces are non-empty, unique and all-of. Every Claim-bearing Assertion proves exactly one Claim at one exact applicability profile and uses explicit comparable Observations and expected values; every Claim/applicability/proof-surface cell must be covered.
+- `truthy`/`falsy` are diagnostic-only. `exists` proves only implementation-structure obligations. Missing or type-incomparable Observation never proves a Claim; negative proof uses an explicit value such as `equals: false`.
+- Claim and Population proof is emitted only after the entire Check passes. Exit failure, missing artifact, failed population, failed Assertion or invalid Counterfactual yields no Claim proof.
 - Verification inputs include entrypoints, helpers, fixtures/config, package scripts and lockfiles and cannot overlap implementation carriers. The frozen runner identity recursively includes the supported direct-literal local verifier module/config/data graph; runtime-owned Check inputs/outputs/artifacts are explicitly excluded from Oracle identity, while non-literal loaders, `createRequire` and package scripts without a recoverable static Node entry fail closed. Other indirect Oracle access must be declared or treated as named TCB.
-- Runners receive the minimum environment whitelist plus only declared environment requirements. Never expose actual secret values in findings.
-
-## Runner And Observation Identity
-
+- Runners receive the minimum environment whitelist plus only declared environment requirements. Never expose actual secret values in findings.
+
+## Runner And Observation Identity
+
 Evidence adapter is derived from runner kind. Only Playwright may prove `ui_browser`; structured runners prove non-browser surfaces. Raw Execution identity binds the runner, its recursively frozen local dependency closure and canonical declared Environment Requirements, not actual values. Bare installed packages and the Harness/runtime remain named trusted-computing-boundary components rather than silently mutable project helpers.
-
-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
-
+
+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. A Claim-bearing Assertion's `applicability_ref` must match the Check target, journey role, duplicate-free atomic dimension assignments, all keyed Given refs and ordered When refs exactly.
-- 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; `design_conformance` binds one compiled selected target, exact required product target, declared condition set and distinct current actual/comparison artifact paths; `design_method` binds one handoff verification method, its exact condition, declared method-record path and declared primary-observation path. Primary observations are pairwise unique by current path and digest across method/condition cells; `target_runtime` binds exact target/root/current session and requires a cold start for a root journey whose execution target declares the matching family, `cold-start` and `production-root` capabilities; `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 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.
-- Bind every runtime-affecting implementation surface through `input_paths` and relevant Binding carriers; keep runner/helper/config files in `verification_inputs`. This lets existing Progress freshness identify when rolling feedback is stale without a new trigger registry.
-
-## Causal Boundary Review After Revision
-
-- When a rolling blocker causes a semantic or proof revision, review only the affected weak-observability or high-risk Outcomes before adoption. Ask whether a cheaper proxy, fixed response or self-reported success could pass while the declared result still fails at a farther independent boundary.
-- Evidence must reach the furthest independently failing boundary named by the Claim. A proxy may prove its own result, but it cannot prove a downstream state or effect merely by reporting success.
+- 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; `design_conformance` binds one compiled selected target, exact required product target, declared condition set and distinct current actual/comparison artifact paths; `design_method` binds one handoff verification method, its exact condition, exact handoff `fact_refs`, declared method-record path and declared primary-observation path. Runtime fact refs must be set-equal to the compiled cell, and all cells must conserve the complete target fact set. Primary observations are pairwise unique by current path and digest across method/condition cells; `target_runtime` binds exact target/root/current session and requires a cold start for a root journey whose execution target declares the matching family, `cold-start` and `production-root` capabilities; `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 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.
+- Bind every runtime-affecting implementation surface through `input_paths` and relevant Binding carriers; keep runner/helper/config files in `verification_inputs`. This lets existing Progress freshness identify when rolling feedback is stale without a new trigger registry.
+
+## Causal Boundary Review After Revision
+
+- When a rolling blocker causes a semantic or proof revision, review only the affected weak-observability or high-risk Outcomes before adoption. Ask whether a cheaper proxy, fixed response or self-reported success could pass while the declared result still fails at a farther independent boundary.
+- Evidence must reach the furthest independently failing boundary named by the Claim. A proxy may prove its own result, but it cannot prove a downstream state or effect merely by reporting success.
 - Every behavioral Claim-bearing Assertion requires a same-Check claim-local semantic Counterfactual. Use `replace_json_value` or `replace_text` to alter only the asserted semantic field/fragment while preserving the production carrier; the designated Assertion must fail and a claimless target-runtime liveness Assertion in `preserved_assertions` must keep passing. `replace_file` remains compatibility-only and cannot establish semantic binding; `remove_paths` remains for non-behavioral existence/structure claims.
 - Keep this risk-proportional and internal. Do not create an evidence matrix, product-effect taxonomy, universal restart/end-to-end suite 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.
-
-Missing, skipped, flaky, unexpected, timed-out, interrupted, failed, multi-AC and duplicate-within-project cases fail closed. The same AC across distinct projects aggregates all-of. Aggregate status/count fields are diagnostic-only.
-
-Standard frozen Playwright verifier content is trusted. Weak-observability Outcomes require same-Check AC/Claim sensitivity. A weak Playwright Counterfactual may accept exit one only when every unexpected instance is uniquely a designated executed AC failure and there are no root, unbound, extra, missing, skipped, flaky, timeout, interruption, artifact, population, environment or other evidence failures. Ordinary Baseline Checks require exit zero.
-
-## Visual UI Evidence
-
-- A selected implementation handoff must already pass `ty-context design-resource preflight`. For each covered row, turn its declared verification methods into project-owned, independently failing observations in the target conformance Check: geometry/pixel/token/content, component state/interaction trace, motion timeline, responsive reflow/input method, accessibility semantics and asset integrity are different obligations. Each method maps to its own Assertion and typed `design_method` evidence; every exact condition declares a method record plus a method-native primary observation whose current path and digest cannot be reused by another cell. Playwright requires explicit record/observation attachments from every project instance. The strict index proves that none was silently omitted; it does not prove that the project verifier is semantically sound.
-- Keep `design_resource_integrity` and `design_implementation_conformance` distinct. Stable paths/hashes, provider/export success, manifest/registry membership and expected counts prove resource integrity; `visual_render` proves a current artifact exists. Neither proves the production implementation matches a selected target.
-- When external design resources are Source, prove every selected exact-target/constraint condition that the Contract explicitly adopts. Candidate comparison, a mutable provider link, extraction success, metadata-only output, resource digest or an isolated prototype run is authoring/integrity material and cannot become product acceptance. Resolve each acceptance-affecting fact through a typed locator plus immutable path/hash and declared target/condition applicability before Compile. Include the handoff and every source-profile entry/dependency in `verification_inputs`; project-owned method-specific single-Claim design-conformance, interaction and target-runtime observations must still fail independently on the current production target.
-- A `design_conformance` record is accepted only for the compiled target/Assertion/current Check target, an equal declared condition-key set and both declared actual/comparison artifacts collected by the current Check. Its Assertion applicability must also equal the adopted target, conditions, journey and input/state facts. Missing or swapped targets, conditions or artifacts fail closed; the implementation render cannot also be the comparison authority.
-- Use Playwright for every declared `ui_browser` visual AC and bind each independently falsifiable AC to its own `[ac:<assertion-key>]` Test Instance. A broad screenshot or one passing page case does not silently prove separate viewport, theme, state, content-stress, layout or accessibility claims; representative, sampled or pairwise coverage cannot waive an actual applicable cell.
-- Make the test environment deterministic enough for its claim: freeze the relevant browser/project, viewport, theme/mode, locale/timezone, font loading, fixtures/data and animation/motion policy in declared verifier inputs or configuration.
-- Any reviewed screenshot baseline that affects pass/fail must exist for the accepting Compile and be included in `verification_inputs`. Generated screenshots, diffs and reports are Artifacts and review material; they are not editable acceptance authority. Creating or replacing a baseline after Authority Lock is verifier-material revision and must never be silently auto-updated to make a failure pass.
-- Confirm that each baseline is a selected `exact-target` for the named surface/viewport/theme/state or implements a named `constraint`; an inspiration reference cannot become a fidelity oracle merely because it is available. The implementation's current screenshot is never its own target.
-- Screenshot comparison proves only the named visual similarity claim. Pair it with explicit DOM/layout/accessibility/motion/responsive/input assertions whenever the handoff or Contract separately declares no overflow, action visibility, focus behavior, target size, semantic state, reduced motion or other observable behavior. One generic `design_conformance` record cannot erase distinct Source Claims or verification methods; every handoff method binds a separate Assertion and the trusted Check must fail if any asserted method fails.
-- Keep evidence aligned with stable surface/control/target keys. Visual similarity, interaction/navigation, validation/recovery, permission behavior, accessibility and target-runtime conformance are independently failing claims and need their own Assertions/capabilities when declared; one broad screenshot or UI pass cannot prove all Control fields.
-- Run checks against production components or real product routes. For each bound Control, the named root-entry journey must begin at the required product target root, execute the declared entry action and prove its navigation result—or interaction, trigger or location fallback—with `interaction_trace` plus `target_runtime`. A detached kit/mock/deep-link harness is acceptable only when the Contract explicitly makes that artifact the product surface; otherwise it cannot substitute for the production carrier or root journey.
+
+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.
+
+Missing, skipped, flaky, unexpected, timed-out, interrupted, failed, multi-AC and duplicate-within-project cases fail closed. The same AC across distinct projects aggregates all-of. Aggregate status/count fields are diagnostic-only.
+
+Standard frozen Playwright verifier content is trusted. Weak-observability Outcomes require same-Check AC/Claim sensitivity. A weak Playwright Counterfactual may accept exit one only when every unexpected instance is uniquely a designated executed AC failure and there are no root, unbound, extra, missing, skipped, flaky, timeout, interruption, artifact, population, environment or other evidence failures. Ordinary Baseline Checks require exit zero.
+
+## Visual UI Evidence
+
+- A selected implementation handoff must already pass `ty-context design-resource preflight`, including complete per-resource fact closure and exact-target layout/pixel defaults. For each covered row, turn its declared verification methods and exact facts into project-owned, independently failing observations in the target conformance Check: geometry/pixel/token/content, component state/interaction trace, motion timeline, responsive reflow/input method, accessibility semantics and asset integrity are different obligations. Each method maps to its own Assertion and typed `design_method` evidence; every exact condition declares its fact refs, a method record and a method-native primary observation whose current path and digest cannot be reused by another cell. Playwright requires explicit record/observation attachments from every project instance. The strict index proves conservation relative to the named resource inspector/oracle TCB; it does not prove that an unsupported format was read or that the project verifier is semantically sound.
+- Keep `design_resource_integrity` and `design_implementation_conformance` distinct. Stable paths/hashes, provider/export success, manifest/registry membership and expected counts prove resource integrity; `visual_render` proves a current artifact exists. Neither proves the production implementation matches a selected target.
+- When external design resources are Source, prove every selected exact-target/constraint condition that the Contract explicitly adopts. Candidate comparison, a mutable provider link, extraction success, metadata-only output, resource digest or an isolated prototype run is authoring/integrity material and cannot become product acceptance. Resolve each acceptance-affecting fact through a typed locator plus immutable path/hash and declared target/condition applicability before Compile. Include the handoff and every source-profile entry/dependency in `verification_inputs`; project-owned method-specific single-Claim design-conformance, interaction and target-runtime observations must still fail independently on the current production target.
+- A `design_conformance` record is accepted only for the compiled target/Assertion/current Check target, an equal declared condition-key set and both declared actual/comparison artifacts collected by the current Check. Its Assertion applicability must also equal the adopted target, conditions, journey and input/state facts. Missing or swapped targets, conditions or artifacts fail closed; the implementation render cannot also be the comparison authority.
+- Use Playwright for every declared `ui_browser` visual AC and bind each independently falsifiable AC to its own `[ac:<assertion-key>]` Test Instance. A broad screenshot or one passing page case does not silently prove separate viewport, theme, state, content-stress, layout or accessibility claims; representative, sampled or pairwise coverage cannot waive an actual applicable cell.
+- Make the test environment deterministic enough for its claim: freeze the relevant browser/project, viewport, theme/mode, locale/timezone, font loading, fixtures/data and animation/motion policy in declared verifier inputs or configuration.
+- Any reviewed screenshot baseline that affects pass/fail must exist for the accepting Compile and be included in `verification_inputs`. Generated screenshots, diffs and reports are Artifacts and review material; they are not editable acceptance authority. Creating or replacing a baseline after Authority Lock is verifier-material revision and must never be silently auto-updated to make a failure pass.
+- Confirm that each baseline is a selected `exact-target` for the named surface/viewport/theme/state or implements a named `constraint`; an inspiration reference cannot become a fidelity oracle merely because it is available. The implementation's current screenshot is never its own target.
+- Screenshot comparison proves only the named visual similarity claim. Pair it with explicit DOM/layout/accessibility/motion/responsive/input assertions whenever the handoff or Contract separately declares no overflow, action visibility, focus behavior, target size, semantic state, reduced motion or other observable behavior. One generic `design_conformance` record cannot erase distinct Source Claims or verification methods; every handoff method binds a separate Assertion and the trusted Check must fail if any asserted method fails.
+- Keep evidence aligned with stable surface/control/target keys. Visual similarity, interaction/navigation, validation/recovery, permission behavior, accessibility and target-runtime conformance are independently failing claims and need their own Assertions/capabilities when declared; one broad screenshot or UI pass cannot prove all Control fields.
+- Run checks against production components or real product routes. For each bound Control, the named root-entry journey must begin at the required product target root, execute the declared entry action and prove its navigation result—or interaction, trigger or location fallback—with `interaction_trace` plus `target_runtime`. A detached kit/mock/deep-link harness is acceptable only when the Contract explicitly makes that artifact the product surface; otherwise it cannot substitute for the production carrier or root journey.
 - Keep subjective visual quality and approval external. A new visual direction or baseline that needs human judgment remains an explicit external confirmation even when all machine checks pass.
 - `ui_browser` proves browser UI only. When a native/mobile/desktop UI can fail independently, browser output is proxy evidence; require a project-owned live target-runtime Check that truthfully fits an existing proof surface or keep the device/simulator review external.
 - Preserve each handoff blocker's non-empty `required_capabilities`. A machine Claim closes it only on the exact execution target that declares every capability; physical device, sensor, camera, orientation, haptic, screen-reader, pixel-density, safe-area or comparable observations cannot be borrowed from a proxy target. If that runtime observation is unavailable or the Oracle cannot consume the target-owned acceptance criteria, keep the blocker as a target-blocking External Confirmation.
-
-## Structured Evidence And Sensitivity
-
+
+## Structured Evidence And Sensitivity
+
 Every claim-bearing `structured_json_v2` Check needs same-Check Claim-related Counterfactual sensitivity. Population declares a real `universe_binding_key`; every universe carrier is an owning-Check `input_path`, and the current observation proves exact universe = eligible = observed plus valid exclusions by entity id. Population never substitutes for the claim-local narrow semantic witness and preserved target-runtime liveness required by a behavioral Claim. Artifacts and another Check never substitute for sensitivity.
-
+
 Outcome Counterfactual V2 names an Outcome `binding_key`; Global Counterfactual V2 resolves an Outcome-owned `binding_ref`. A Counterfactual mutates only a proven subset of implementation carriers, never Source, Context, runners or verification inputs, and accepts only designated `assertion_value_mismatch` findings. Behavioral witnesses use claim-local `replace_json_value` or `replace_text`, list their designated Claim-bearing failure Assertions, and list the claimless liveness Assertions that must remain passing.
-
+
 An `existing` mutation target must exist at Preflight/Compile and the JSON pointer/text fragment must resolve uniquely. A `planned` target may be absent until implementation but must exist at Final Gate; once created, its changes stale targeted Progress.
-
-Artifacts remain review material. They do not prove Claim sensitivity by themselves.
+
+Artifacts remain review material. They do not prove Claim sensitivity by themselves.