project-tiny-context-harness 0.7.9 → 0.8.0

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

@@ -1,59 +1,76 @@
-# Authority Lifecycle Reference
-
-Read this before Preflight, Compile, revision, resume, targeted verify, Final Gate, Stop, close or abandon.
-
-## Preflight And Compile
-
-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, 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.
-
-The first successful `ty-context long-task compile <workdir>` is Authority Lock and freezes the immutable initial base and complete compiled authority snapshot in Git common-dir, bound to the worktree marker by task id, revision and compiled identity.
-
-Its JSON result includes `execution_model_checkpoint.required: true`. Before product implementation, stop once and ask the user to continue with the current model or switch models and then resume the active Long-Task. A task-specific model choice already stated explicitly satisfies the checkpoint. Later Compile revisions return `required: false`; no checkpoint file, acknowledgement state, model route or automatic model switch is created.
-
-## Protected Revision
-
-After Authority Lock, every revision compares against active authority and follows one of three paths:
-
-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 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.
-
-Ordinary `compile --revise` is the only operation that may create the one pending decision. It binds a deterministic concise change summary into the revision identity and enumerates changed semantic fields, Source/Product Claim reductions, proof reductions and external-confirmation keys. `status` and `resume` expose that same decision so the host can deduplicate the user prompt without a Harness-owned waiting state. The executing Agent never approves its own pending revision; earlier blanket authorization cannot approve a later exact identity. If the candidate changes, the identity changes and old approval is rejected. The previous Authority remains active until approved compare-and-swap adoption. Adoption reports `delivery_completed_by_this_event: false`, invalidates affected evidence and returns to rolling implementation or repair under the revised Authority; the complete source-recompiled Final Gate remains mandatory.
-
-Every path-bearing field uses canonical grammar. Internal `.`/`..`, control characters, empty segments, absolute/drive/UNC paths and unsupported glob syntax fail closed.
-
-Controlling Context includes core Context, explicit `context_refs`, verification/deployment Context and every file in full snapshot mode. In referenced mode only graph-derived, non-explicit `implementation-index` and `archive` files are Supporting Context; a supporting-only `compile --revise` may preserve otherwise-fresh targeted Progress.
-
-A selected design target, its exact/constraint interpretation, an authored token source or any applicable Control semantic is product/verification authority, not generated evidence. External design resources are ordinary Source: a candidate or unresolved selection cannot authorize fidelity work, while a selected exact target still requires downstream UI Authority Closure and Contract adoption. Adding or changing its selected resource, selection basis, immutable identity, condition coverage or acceptance-affecting token/prototype fixture after Authority Lock follows the existing protected revision path and returns to rolling implementation; a candidate/planned target, implementation screenshot or historical diff cannot authorize fidelity work or preserve affected Progress by itself.
-
-`context.toml` retrieval guidance (`triggers`, `read_when`, `read_policy`, default selection and unselected nodes) is excluded from the selected delivery-authority projection. Selected area ownership, role/dependency structure and selected Context contents remain protected revision material. Retrieval-only edits may preserve scoped Progress, but a changed final Git tree still invalidates historical final acceptance and must pass the Live Final Gate again.
-
-## Targeted Verification And Recovery
-
-`verify --outcome/--check` runs scoped current-snapshot checks for repair and rechecks active identity before writing Progress. A Counterfactual finding is projected into the owning Main Check, changes an otherwise passed Check to `invalid_evidence`, clears Claim proofs and remains recoverable through `status`/`resume`. Global Checks use the same record without a new Global Outcome state.
-
-For a declared target-runtime Check, run targeted verify once when its earliest owning Outcome reaches the first runnable boundary. After accumulated changes to its declared `input_paths` or Binding carriers make Progress stale, rerun before dependent work grows. Coalesce related edits and use the cheapest reliable Check; do not create a per-edit/per-Outcome rebuild rule, trigger queue or platform state. These runs remain `acceptance_authorized: false`.
-
-Progress freshness binds Outcome authority, runner, verification inputs, Controlling Context and implementation inputs. Retry defaults to none; one retry is allowed only for explicit `transient_once`, idempotent, read-only/test-sandbox work.
-
-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. `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. This is the sole Long-Task `Architecture Conformance` carrier: material deliberation conclusions must already be declared through existing obligations/constraints/forbidden shortcuts, owners/paths/Bindings and project-owned Checks, and no separate default Contract Conformance closure runs. 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.
+# Authority Lifecycle Reference
+
+Read this before Preflight, Compile, revision, resume, targeted verify, Final Gate, Stop, close or abandon.
+
+## Preflight And Compile
+
+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, 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.
+
+The same workspace classifier also runs before activation and during verification. Before first lock it classifies `HEAD`-relative current paths; later it classifies immutable-`initial_task_base` changes. Protected authority, declared expected change and allowed support remain distinct from forbidden or unclassified paths, which block activation. During first enable, protection covers only exact files present in the current package asset tree for configured managed destinations plus the exact harness config/hook files; managed directory roots and broad `.codex/**` are never implicitly allowed.
+
+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.
+
+The first successful `ty-context long-task compile <workdir>` is Authority Lock and freezes the immutable initial base and complete compiled authority snapshot in Git common-dir, bound to the worktree marker by task id, revision and compiled identity.
+
+Its JSON result includes `execution_model_checkpoint.required: true`, `turn_boundary: end_current_turn`, the blocked implementation actions and explicit-choice semantics. Unless the user already stated an explicit task-specific current-model or switch-and-resume strategy, do no product implementation, file edit, build or test after that result; end the turn and ask for the choice. Generic continue/resume/finish/continue-goal language does not satisfy the checkpoint. Later Compile revisions return `required: false`; no checkpoint file, acknowledgement state, model route or automatic model switch is created.
+
+## Protected Revision
+
+After Authority Lock, every candidate compares against active authority. `authority_changed` does not by itself mean `user_decision_required`:
+
+1. proven monotonic evidence strengthening—including added capabilities while preserving every existing Assertion meaning—and proven tightening auto-revise;
+2. mechanically bounded repair may auto-revise when compiled user-facing meaning and proof obligations stay fixed: raw Source/Context snapshot updates with unchanged Claims/targets, operational Runner or verification-input repair, risk strengthening and machine-proven equivalent Counterfactual Claim/assertion-failure coverage;
+3. repo-bound owner/expected-change/allowed-support or Binding-carrier expansion may auto-revise; `diagnose-revision` may exercise existing active Check identities without creating state before final Compile; or
+4. Product/Source Claim/target/external-confirmation change, lost scenario/Claim/Evidence Capability/failure interception, forbidden or owner-Context removal, runner type/effect change, verifier-kernel change and every unknown reason fails closed for the exact revision identity and is never candidate-executed.
+
+Automatic adoption never means “unprotected”: exact identity, active-Authority compare-and-swap, affected-evidence invalidation and the complete source-recompiled Final Gate remain mandatory. Risk downgrade is still rejected.
+
+`diagnose-revision` recompiles the same `delivery-contract.yaml` in memory, creates only a disposable workspace snapshot when class 2 is proven, and returns transient repair results with `acceptance_authorized: false`. It writes no pending/approval state, authority/marker, cache, Progress or Receipt. Repeated edits therefore accumulate only in the one existing Contract authoring file, not a pending Draft authority or candidate state plane.
+
+Ordinary `compile --revise` is the only operation that may create the one pending decision. It binds a deterministic concise change summary into the revision identity and distinguishes `user_decision_reasons` from `mechanically_bounded_reasons`. Compile/status/resume derive the same self-contained `decision_brief` from that canonical summary. The brief explains what Authority Revision is, why this one needs a decision, material changes, affected Outcomes, previous-Authority/reject behavior, the no-completion effect and mandatory Final Gate.
+
+Present that brief before asking for the exact identity. First compare every listed decision reason with explicit instructions in the current task: if one task-specific instruction already covers all of them exactly, mechanically relay that existing user decision through the exact approval command without asking again. This is decision transport, not Agent approval. A generic continue/resume/finish, blanket “approve later revisions”, recommendation, partial coverage or Agent inference never qualifies. The executing Agent never originates its own weakening decision.
+
+During repair, use stateless diagnosis and ordinary edits; do not invoke decision-producing Compile for intermediate candidates. Withdrawn or replaced identities therefore generate no question. When the final blocking candidate is stable, ask at most once. If it later changes, its identity changes and any old approval is rejected. No instruction ledger, standing approval or candidate state is created.
+
+The previous Authority remains active until exact approval and compare-and-swap adoption. Adoption reports `delivery_completed_by_this_event: false`, invalidates affected evidence and returns to rolling implementation or repair under the revised Authority; the complete source-recompiled Final Gate remains mandatory.
+
+Every path-bearing field uses canonical grammar. Internal `.`/`..`, control characters, empty segments, absolute/drive/UNC paths and unsupported glob syntax fail closed.
+
+Controlling Context includes core Context, explicit `context_refs`, verification/deployment Context and every file in full snapshot mode. In referenced mode only graph-derived, non-explicit `implementation-index` and `archive` files are Supporting Context; a supporting-only `compile --revise` may preserve otherwise-fresh targeted Progress.
+
+A selected design target, its exact/constraint interpretation, an authored token source or any applicable Control semantic is product/verification authority, not generated evidence. External design resources are ordinary Context-reachable Source: a candidate or unresolved selection cannot authorize fidelity work, while a selected exact target still requires downstream UI Authority Closure, stable key, readable immutable identity/digest, declared coverage, editable upstream/update route and Contract adoption. Open every affected exact target/constraint during authoring and repair; a registry mention alone is not consumption. Adding or changing its selected resource, selection basis, immutable identity, condition coverage or acceptance-affecting token/prototype fixture after Authority Lock follows Authority Revision and returns to rolling implementation. Never silently overwrite an adopted baseline; a candidate/planned target, implementation screenshot or historical diff cannot authorize fidelity work or preserve affected Progress by itself.
+
+`context.toml` retrieval guidance (`triggers`, `read_when`, `read_policy`, default selection and unselected nodes) is excluded from the selected delivery-authority projection. Selected area ownership, role/dependency structure and selected Context contents remain protected revision material. Retrieval-only edits may preserve scoped Progress, but a changed final Git tree still invalidates historical final acceptance and must pass the Live Final Gate again.
+
+## Targeted Verification And Recovery
+
+`verify --explain [--outcome/--check]` is a read-only execution preview. It groups declared Main Raw Executions, lists applicable Counterfactual runner invocations and bounded declared retry-attempt counts, but runs no command, writes no Progress, predicts no duration/internal subprocess count and creates no proof.
+
+Before an expensive first targeted run, use the preview to review selected Check count, deduplicated Main executions, Counterfactual mutations and retry bounds. If the expanded plan reveals an obsolete carrier, unnecessarily broad invalidation surface or repeated expensive runner, repair the same Contract Draft/Authority through the normal revision path. The preview cannot see build systems or subprocesses hidden inside a project runner.
+
+`verify --outcome/--check` runs scoped current-snapshot checks for repair and rechecks active identity before writing Progress. A Counterfactual finding is projected into the owning Main Check, changes an otherwise passed Check to `invalid_evidence`, clears Claim proofs and remains recoverable through `status`/`resume`. Global Checks use the same record without a new Global Outcome state.
+
+For a declared target-runtime Check, run targeted verify once when its earliest owning Outcome reaches the first runnable boundary. `progress_stale` is a fact about evidence freshness, not an immediate execution instruction. Coalesce related edits and use the cheapest reliable project-owned feedback, then refresh the declared Check before dependent work relies on that Outcome or before Final Gate. Do not create a per-edit/per-Outcome rebuild rule, trigger queue or platform state. These runs remain `acceptance_authorized: false`.
+
+Do not add a second executing `diagnose-check` mode merely to avoid Progress: it would still pay the project runner's cost and create a competing execution path. Use project-owned fast feedback while editing, the read-only preview for declared cost shape, targeted verify at a useful stability boundary and the complete Final Gate for acceptance.
+
+Progress freshness binds Outcome authority, runner, verification inputs, Controlling Context and implementation inputs. Retry defaults to none; one retry is allowed only for explicit `transient_once`, idempotent, read-only/test-sandbox work.
+
+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 a freshness fact rather than a current pass or immediate rerun command; `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. This is the sole Long-Task `Architecture Conformance` carrier: material deliberation conclusions must already be declared through existing obligations/constraints/forbidden shortcuts, owners/paths/Bindings and project-owned Checks, and no separate default Contract Conformance closure runs. 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

@@ -1,105 +1,116 @@
-# 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.
-- 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.
-- Missing recommended legacy Source Plan headings or keys never blocks authoring. When raw/mixed inputs are not self-contained, use `source-authoring.md` inside this workflow before Contract mapping. Missing mandatory Material Source Item markers does block activation.
-- 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, dependency-ready work, targeted verification, precise failure localization, semantic resume and stale-result invalidation are valid reasons to decompose. 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.
-
-## 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 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.
-
-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` 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. 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 external design resources are material Source, place stable authored files or an accompanying controlling brief/index in `source_paths`, enumerate material statements with ordinary Source markers and preserve stable surface/state/control/target keys where available. 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 a task-local, risk-proportional Visual Coverage Set from declared Source, `project_context/**` and `DESIGN.md`: production surface/route/component, viewport, theme or product mode, interaction/state, content stress and accessibility/motion conditions;
-- select representative combinations rather than silently creating a full Cartesian requirement; an omitted combination remains unproven, while Source that explicitly requires full coverage must retain that scope;
-- encode each independently falsifiable visual expectation as an atomic Requirement, applicable Control field or named AC Assertion. Name the surface, viewport, theme/state/content condition and observable result when they matter to the claim;
-- preserve every applicable material Control field independently: `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`. Empty/non-applicable fields create no Claim; do not collapse decided fields into broad prose that loses Source-to-Control traceability;
-- 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, mocks or marketing specimens may be references but not substitute implementation carriers;
-- use `ui_browser` only for declared browser ACs. A browser or Expo-Web proxy cannot prove a native/mobile/desktop target that can fail independently; use a project-owned current-execution target Check when existing proof surfaces can truthfully represent the claim, otherwise retain named human/device confirmation as an external confirmation rather than inventing machine proof;
-- keep subjective visual direction, taste or approval outside false machine proof. Resolve an undecided direction as `decision_required`; represent required human design or new-baseline approval as an explicit external confirmation.
-- 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 Source and the owning registry/target input; after Authority Lock adopt it through the existing protected revision before downstream fidelity implementation. This creates no target-selection state, second Contract or second Gate.
-
-External authored design resources remain ordinary upstream Source rather than a Contract Draft, verification result or alternate authority. The revised initial proposal plus selected immutable resources is the recommended upstream input; no standalone Source Plan handoff is required. A legacy Source Plan remains valid ordinary Source if supplied. This guidance adds no UI-specific Contract block, Claim kind, risk level, lifecycle state, required design package, design directory or Gate. The additive generic Control fields only preserve Source meaning through existing Source, Requirement/Control/Assertion, Stage, Binding, proof-surface, verification-input, revision and external-confirmation mechanisms.
-
-## Compact Authoring
-
-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, 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.
+# 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.
+- 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.
+- 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, dependency-ready work, targeted verification, precise failure localization, semantic resume and stale-result invalidation are valid reasons to decompose. 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.
+
+## 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 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 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.
+
+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` 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. 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 a task-local, risk-proportional Visual Coverage Set from declared Source, `project_context/**` and `DESIGN.md`: production surface/route/component, viewport, theme or product mode, interaction/state, content stress and accessibility/motion conditions;
+- select representative combinations rather than silently creating a full Cartesian requirement; an omitted combination remains unproven, while Source that explicitly requires full coverage must retain that scope;
+- encode each independently falsifiable visual expectation as an atomic Requirement, applicable Control field or named AC Assertion. Name the surface, viewport, theme/state/content condition and observable result when they matter to the claim;
+- preserve every applicable material Control field independently: `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`. Empty/non-applicable fields create no Claim; do not collapse decided fields into broad prose that loses Source-to-Control traceability;
+- 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 Claims included by the one root conformance Assertion; and bind every handoff acceptance blocker in the surface binding. The Assertion also names bound Control Claim refs, distinct current actual/comparison artifact paths and all-of `design_conformance`, `interaction_trace` and `target_runtime`, and current proof emits a typed `design_conformance` record; `visual_render`, handoff preflight, file hashes, counts or registry presence remain input/resource integrity and cannot substitute for implementation conformance;
+- explicitly inventory every declared design-acceptance blocker inside its surface binding. An empty array states that no blocker is declared; each declared entry references target-local Claims with valid proof or 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
+
+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, target profile/required targets, ordered Stages, Source/Source Claims, Context, observable results, success/degradation requirements, owners/paths, REQ, applicable CTRL states and their 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, 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.