project-tiny-context-harness 0.8.12 → 0.8.13

package/assets/skills/design-resource-authoring/references/recovery-and-writeback.md

@@ -0,0 +1,199 @@
+# DRA Semantic Replay, Recovery And Proposal Writeback
+
+Load this reference only for a material generation/revision loop which needs complete semantic replay, a selected-Proposal writeback, current bidirectional audit or real recovery across interruption. It strengthens upstream Source quality and does not become Design Authority, implementation acceptance or Long-Task proof.
+
+## Simple path and admission
+
+A simple scoped preview creates zero recovery files and persisted recovery bytes, adds no user pause or Provider generation beyond the one requested commission, runs no formal handoff/preflight, performs no Proposal writeback and opens no helper write transaction. Its ordinary requested preview is the commission itself; recovery adds and reports zero tool actions. Keep its temporary reasoning in the current turn.
+
+Use a recovery checkpoint only when interruption would otherwise lose material accepted/rejected/unresolved semantics, immutable Provider identity or a pending CAS writeback. It is versioned, ignored, task-local, non-authoritative and deletable. It is not Source, Context, a Contract, Authority, Evidence, Receipt, Gate, Provider registry, scheduler, acceptance state or completion conclusion. There is no global session registry, event log, heartbeat, polling loop or state-machine service.
+
+For deterministic classification, apply four fail-closed invariants before details: validate every semantic key independently; retain every valid accepted/rejected/unresolved decision and its authority row even when a later patch, audit or owner fails; reject deterministic checkpoint input whose claimed Source authority is invalid; and report a requested or pending unsafe reconciliation/writeback as blocked rather than as no action. Provider/resource selection never fills a missing authority row, and one key's authority never covers another key.
+
+## Base and replayable Delta
+
+Freeze one current Base with:
+
+```yaml
+locator: repository/relative/file
+raw_byte_digest: sha256
+encoding: detected-by-helper
+eol_policy: detected-by-helper
+scope_ceiling: bounded-scope-key
+in_scope_keys: []
+explicitly_excluded_keys: []
+```
+
+The Base must be repository-readable and raw-digest verifiable: ordinary project Source, a materialized project-native Proposal, or an explicitly authorized disclosure-reviewed recovery snapshot. A Provider resource is recoverable only when its immutable identity can be fetched again and checked. Conversation-only input, expiring external documents, unavailable attachments and sensitive inputs are not recovered from locators. Materialize only with explicit user authorization. Never persist credentials, tokens, secrets, protected raw values or sensitive originals. Otherwise report exactly `cross-session deterministic recovery unavailable`; when no checkpoint exists, its checkpoint disposition is `none`, not rejection of a nonexistent file.
+
+Every Delta stores actual replay semantics, never only an ID:
+
+```yaml
+delta_id: stable-key
+sequence: 1
+supersedes: []
+proposes_replacement_of: []
+operation: add | replace | remove | preserve
+semantic_kind: exact-visual | product | business | permission | data | algorithm | commercial | safety-security | technical
+target_keys: []
+before_semantics: complete-value-or-null
+after_semantics: complete-value-or-null
+origin: user-direct | necessary-derived | repository-evidence-backed | provider-suggested
+decision_authority: explicit-user | delegated:<bounded-scope-key> | none
+evidence_refs: []
+source_refs: []
+explicitly_unchanged_keys: []
+status: accepted | rejected | unresolved
+```
+
+Retain all statuses, exact ordering, one-way supersession and explicit unchanged keys. Only an accepted Delta may supersede an earlier active accepted Delta, and it must replace the same target set, semantic kind and exact prior `after_semantics`; a rejected or unresolved Delta never deactivates accepted meaning. Use `proposes_replacement_of` for a rejected/unresolved proposal which may be decided later. Cross-target or semantic mismatch fails closed.
+
+After legal supersession, every stable semantic target key has at most one active accepted Delta owner. Two active accepted Deltas for one target without a legal replacement relationship fail closed. This version deliberately has no generic merge or composition DSL; a future need to compose one semantic key from several Deltas requires a separately admitted mechanism.
+
+Derive the complete inactive universe as rejected plus unresolved plus superseded accepted Delta IDs. The current audit supplies exactly one leakage row for every inactive ID with the matching reason and `leaked: false`; missing, extra, duplicate or active-ID rows fail closed. If an inactive meaning remains in the Proposal, selected-resource projection or resulting writeback, reconciliation is blocked.
+
+Status inventories contain stable target-key identities, never `key=value` strings; semantic values stay in the Delta rows. The same key can therefore remain in the accepted inventory while a later rejected or unresolved proposal for that key remains visible in its own inventory. A blocked audit or illegal final owner does not rewrite an independently authorized accepted Delta as unresolved.
+
+Each `source_ref` resolves through `authority_sources` to one repository-contained Source document, its current raw-byte digest, one actual marked Source item, the item kind and item-text digest. An arbitrary string or conversation-only locator cannot create authority or enter deterministic recovery. For deterministic accepted authority, that same marked Source Item also contains one strict, non-rendered, package-owned single-line `ty-dra-authority-v1` JSON projection covered by the Item text digest. Free text without this projection can continue through ordinary conversational DRA, but it cannot machine-close deterministic recovery authority or enter a checkpoint as accepted authority.
+
+An explicit projection uses `mode: explicit-user` and enumerates exact target keys, semantic kinds, allowed origins and the canonical `after_semantics` SHA-256. Its `target_keys` set must equal the bound Delta target set; a coupled `[A, B]` decision cannot be rebound as an independently authorized `[A]` meaning. A delegation projection uses `mode: delegation` and enumerates its stable delegation key plus exact allowed target keys, semantic kinds and origins. `delegated:<id>` names the matching task-local delegation row, and the accepted Delta binds that same decision Source. Delegation is deliberately a bounded superset: every Delta target must be a member of the delegation's allowed targets. Do not substitute an incidental target path for delegation identity. A hierarchical-looking key such as `checkout.confirmation` does not implicitly authorize `checkout.confirmation.fade_duration`, a sibling or a broader target.
+
+`origin` records where the meaning arose, not where its Source item happens to be stored. Materializing a direct user choice in the repository leaves it `user-direct`; use `repository-evidence-backed` only when repository evidence itself supplies the meaning. A separate decision Source can authorize a meaning without changing that meaning's origin.
+
+A selected resource is evidence and never authorizes itself. An accepted Provider suggestion requires explicit user authority or a delegation which covers its origin, semantic kind and every target. Delegation authorizes bounded choice; it is not automatically the Source for the chosen non-visual meaning. Product capability, business, permission, data, algorithm, commercial and safety/security meaning additionally binds an independent authoritative Source Item, separate from the delegation item, whose own projection simultaneously matches the exact target set, semantic kind, origin and canonical `after_semantics` digest. An unrelated requirement kind cannot fill that slot. A specific explicit-user decision item may carry both meaning and acceptance, but a general bounded-delegation decision alone is not the meaning. Exact visual values may remain exclusively resource-owned, but their adoption authority remains independently Source-bound. A visual-color delegation therefore cannot be rebound to product, business or permission meaning. Provider-added meaning lacking authority remains `unresolved` unless an authoritative decision explicitly rejects it. Rejected/unresolved meaning never enters accepted requirements or writeback.
+
+The helper proves consistency between Source-owned structured scope and Delta fields. Interpreting the higher-level semantics of arbitrary free text remains part of the Authoring TCB; the helper does not implement general natural-language entailment.
+
+Reconstruct each round only from:
+
+```text
+current Base@raw digest
++ ordered active accepted Delta semantics
++ current unresolved decisions
++ current scope/exclusions
++ current Design Authority identity
+```
+
+Never use a prior Agent summary or generated resource as the next Base. Missing semantics, stale Base, invalid sequence/supersession/delegation or an out-of-scope/excluded target fails closed.
+
+## Conditional checkpoint and helper
+
+Prepare one disclosure-reviewed JSON input using schema `design-resource-recovery-input-v4`, including session identity, Base, `authority_sources`, delegations/Deltas, exact accepted/rejected/unresolved sets, current Design Authority identity, immutable Provider project/run/resource references, `selected_resource_bindings`, one frozen `audit_expectations` catalog and optional writeback. The catalog owns the exact changed, unchanged, resource-decision, blast-radius and inactive-leakage row expectations, including Delta/resource/condition/basis/binding identities. Every resource-decision binding freezes one and only one `final_disposition`: `proposal-written` with its exact operation ID, `resource-owned-exact-visual` with its selected resource/conditions/structured owner, `not-adopted` for rejected or superseded meaning, or `unresolved` for unresolved meaning. Audit observes and verifies this owner; it never selects it. Changing an owner requires checkpoint `update` with digest CAS. The catalog is the only checkpoint audit-universe/owner owner; current audit rows must be set-equal to it rather than merely non-empty. Selected resource bindings declare one unique resource key, generic `repository-snapshot` or `external-immutable` identity, locator, raw-byte digest and exact condition identities. Arbitrary condition strings and duplicate identities fail closed.
+
+Create/retain a checkpoint for a real interruption or pending CAS writeback; use `none` when neither exists, and `reject` when a requested new checkpoint, input, destination or existing checkpoint cannot be admitted. Never turn an invalid authority request into `none` merely because no file was written. Then explicitly create it when required:
+
+```text
+ty-context design-resource recovery create <session> --input <state.json>
+```
+
+When a real recovered loop changes Delta, resource or pending writeback inputs, replace the existing checkpoint only through digest CAS:
+
+```text
+ty-context design-resource recovery update <session> --input <state.json> --expected-sha256 <current-checkpoint-sha256>
+```
+
+The helper writes the next canonical checkpoint to an exclusive same-directory temporary file, rechecks the current digest, atomically replaces and rereads it. A mismatch retains the old checkpoint and fails closed. Repeated identical input is an idempotent no-write. This creates no session registry.
+
+The helper writes only:
+
+```text
+tmp/ty-context/design-resource-recovery/<session>/checkpoint.json
+```
+
+and requires the path to be ignored and untracked. It validates strict schema/version, canonical bytes, Base identity, complete Delta/delegation semantics, repository containment/no-follow parents, symlink/junction/hardlink and user collision boundaries. The checkpoint adds detected Base encoding/EOL and, when applicable, detected target encoding/EOL. It stores no current activity, live Provider execution, Artifact readiness, Design suitability, next action, readiness/completion or acceptance.
+
+Use `inspect` after interruption. It re-reads Base and repository Design Authority, validates raw identities, reconstructs ordered active accepted/rejected/unresolved semantics and derives writeback state. External Provider/resource and external Design Authority identities remain explicitly listed for current revalidation; the helper does not contact or manage Providers.
+
+```text
+ty-context design-resource recovery inspect <session> [--json]
+```
+
+Unknown schema, corrupt JSON, stale Base/authority or unavailable semantics fails closed. In particular, v3 input/checkpoint/audit and exact-patch-v3 are never silently interpreted as v4/exact-patch-v4; reconstruct current state from Source, Provider identities and Proposal instead of inferring missing bindings or establishing a migration registry. The helper's deterministic boundary is supported repository files and exact bytes; a locator alone is not proof of recoverability.
+
+## Current audits and status card
+
+Before selection/writeback and after every material revision, re-read current resources and perform three upstream audits:
+
+1. **Requirements → Resource:** every frozen active accepted changed key has the catalog's exact Delta, selected immutable resource and condition bindings. Every frozen explicit-unchanged key has exactly the catalog's resource, condition and authority-basis Source bindings. A referenced condition must belong to the selected resource's declared conditions. Missing, extra, duplicate, unresolved, distorted or falsely claimed coverage fails closed.
+2. **Resource → Requirements:** freeze every material resource-decision row and its one final disposition per binding in the checkpoint catalog. Each row binds exact Delta IDs and a separate stable binding ID plus requirement-key/Delta/origin/decision-authority/Source tuple for every key; authorization of one key never covers another. The global `(resource_ref, requirement_key, delta_id)` and `(delta_id, target_key)` identities are unique across all rows; duplicate arrays or cross-row bindings fail before any Map/Set normalization. Every active non-preserve `Delta × target` has exactly one final disposition. `proposal-written` binds one real patch operation ID. `resource-owned-exact-visual` is limited to exact visual meaning and binds one immutable selected resource, exact declared conditions and a structured `selected-source-record` or `external-immutable` owner. Rejected/superseded uses `not-adopted`; unresolved uses `unresolved` and blocks readiness. Provider success, audit choice or a selected file cannot create authority.
+3. **Unexpected Blast Radius and inactive leakage:** the catalog freezes the complete blast-radius universe, including every explicit Base exclusion, and every inactive Delta leakage row. Inspect every blast row for out-of-scope pages, controls, copy, layout, tokens and states, and every leakage row for reappearance of rejected, unresolved or superseded meaning. Missing, extra, duplicate, unexpected or unresolved rows fail closed.
+
+Provider execution, Artifact readiness and Design suitability are independent. Provider success, complete fields or repeated values never prove suitability; a valid shared Token or inherited component variant must not be rejected merely because a value repeats. Block direct/Design-Authority conflict, wrong target/condition, missing material state, placeholder-final content, unsupported added meaning, unresolved promotion, stale identity and incomplete formal closure.
+
+Derive—not restore—a status card containing Base identity; accepted/rejected/unresolved Delta; current changed and explicitly unchanged keys; Provider run identity; current live Provider execution; current Artifact readiness; freshly audited Design suitability; all three audit findings; current digest-derived writeback CAS state; and next action. A requested status card re-runs the current audits: an executing run or incomplete current resource is `blocked`, not a restored or `not-applicable` audit conclusion. The checkpoint contains none of those live conclusions.
+
+Derive status fields with one meaning each:
+
+- checkpoint: `none` when no checkpoint exists or is needed, `create` for a real interruption/pending CAS writeback, `retain` for an existing valid checkpoint, and `reject` for a proposed or existing invalid/unsupported checkpoint, input or unsafe destination;
+- write action: `none` when no Proposal writeback/promotion is pending or requested (including a recovery-availability inquiry), `preview` for a safe pending patch not yet approved for apply, `apply` only for pre-digest plus balanced audit, `idempotent-no-write` for expected-post bytes, and `block` when a requested/pending writeback is unauthorized, stale, conflicting or audit-blocked;
+- audit: `not-applicable` only when no current selected/resource surface is available to audit, `blocked` when any current audit cannot balance, and `balanced` only after all three current audits and leakage checks pass.
+
+An unauthorized meaning in a selected resource therefore blocks its Proposal promotion/writeback even if the file remains valid visual evidence; an unavailable conversation-only Base with no writeback request reports no write action.
+
+Project the decision inventory before projecting the action result. An independently Source-valid accepted Delta stays in the accepted inventory and keeps its authority row when a later patch, resource identity, condition/basis binding, audit row or final owner is invalid; those later defects block reconciliation, readiness and writeback but do not demote or erase the accepted meaning. When balanced reconciliation, promotion, handoff or writeback is requested or imminent, any duplicate identity/cross-row binding, condition/basis mismatch, illegal/multiple/unreadable final owner, inactive leakage or patch mismatch means a blocked result, blocked current audit and blocked write action—not `none` or `unavailable`—with every affected audit direction reported. If the authority Source/projection itself fails target, semantic kind, origin, meaning digest or repository identity, reject the deterministic input/checkpoint and do not accept that meaning. For a deterministic create/update input, this is checkpoint `reject` even when no prior checkpoint exists; normalizing the invalid claimed acceptance into rejected or unresolved meaning does not turn the invalid input into checkpoint `none`. Retain an existing valid checkpoint when an update/cleanup conflict or partial cleanup prevents the requested operation.
+
+Apply the table to imminent work, not only completed commands: a valid authorized Delta plus an immutable resource and a real interruption expected before writeback requires checkpoint `create` and write action `preview`; a handoff-ready request with any current audit/authority gap requires write action `block`; and frozen pre/post digests plus a balanced current audit are a pending CAS writeback requiring checkpoint `create` or `retain` and write action `apply`.
+
+## Safe writeback and reconciliation
+
+Create a writeback only when at least one frozen active binding is `proposal-written`. Freeze target locator, pre-write raw digest, exact `design-resource-exact-patch-v4`, canonical patch digest, expected post bytes/digest, selected resource identities and `proposal_written_delta_ids`. The immutable replay Base and mutable writeback target must be distinct locators; if the current Proposal itself must be updated, first use an explicitly authorized immutable Source/snapshot as Base. The exact patch universe is only the active accepted `Delta × target` bindings frozen as `proposal-written`; resource-owned exact values remain in effective requirements and audit but never enter or get copied into Proposal.
+
+Every patch operation has one unique ID, exactly one Delta, one target, one semantic binding and one `source_span` in `utf16-code-unit-v1` coordinates over the original decoded pre-write Proposal. Every non-null before/after semantics has exactly one JSON scalar leaf, and the declared local text projection must cover that leaf. Ordinary string scalars containing CR, LF, NUL or another control character are unsupported; never permit a value such as `red\npermission.admin: true` to escape its scalar carrier.
+
+For `replace`, split each local before/after text at its projected scalar. The complete prefix before the scalar and suffix after it must be character-for-character equal; only the projected scalar may change. Adding a permission line, renaming a label or deleting nearby prose inside the same operation is blocked and requires a separately authorized Delta rather than piggybacking on the scalar replacement.
+
+Free-text add/remove cannot establish non-interference. `add` requires null before semantics, preserves one exact nonempty insertion anchor and adds exactly one package-canonical single-line `ty-dra-proposal-scalar-v1` carrier plus the current uniform EOL. That carrier contains only `target_key`, `semantic_path` and the canonical JSON scalar value. `remove` projects one before leaf to null, requires empty `after_text` and deletes exactly one already canonical carrier whose target/path/value match the Delta; it cannot widen over an adjacent heading, requirement, explanation or other target. `disabled`, `removed`, `deprecated` or another non-empty substitute is new meaning requiring a separate Delta. If the current Proposal has no supported anchor/carrier, report exactly `deterministic Proposal writeback unavailable`; return a complete revised Proposal for user confirmation or retain the exact value as resource-owned instead of falling back to generic string replacement.
+
+Fail closed from the actual patch-v4 operation and Proposal bytes, not from omitted detail in a concise audit summary. A statement that an operation exactly projects its one leaf and that its anchor/carrier, preimage and expected post bytes are current is a positive claim of those named invariants unless another fact contradicts it; do not invent a missing carrier, malformed carrier or free-text fallback merely because the summary does not repeat the serialized carrier. Conversely, a claimed valid operation never overrides an observed parser, target/path/value, anchor, scaffold or span mismatch.
+
+For a decision-only review whose supplied facts are an invariant summary rather than the serialized operation, treat these as sufficient positive patch-v4 claims unless another supplied fact names a mismatch: an add with null before semantics, exactly one after scalar, `before_text` used only as a preserved structural anchor, exact after projection and current pre/post bytes; or a remove with exactly one before scalar, null after semantics, empty `after_text`, exact before projection and current post bytes in which the old `before_text` is absent. Such a positive summary is `allow`/balanced and does not itself reveal missing carrier bytes. This interpretation never relaxes create/update: when actual operation bytes are available, the helper must parse and verify the canonical carrier, anchor and source span and fail closed on any mismatch.
+
+A carrier, scaffold, projection or source-span defect is a downstream patch defect, not a new authority decision. When the Delta's Source and decision authority remain valid, preserve that Delta in `accepted_keys` and preserve its authority row while returning a blocked disposition/audit/write action and rejecting the invalid checkpoint input. Never erase or demote already accepted meaning merely to express that its proposed patch cannot be applied; only an actual Source/authority failure changes the accepted inventory.
+
+Checkpoint create/update resolves every source span against the same original Proposal before mutation. The frozen interval must equal `before_text` and both text digests, and all spans must be pairwise disjoint and non-nested; operations cannot share a character or insertion anchor. Apply sorts original spans by descending offset and replaces only those intervals, so a later operation cannot consume output generated by an earlier operation. Readback calculates each final interval from original offsets and length deltas, checks its exact output plus the whole-file expected digest and thereby conserves untouched prefix, suffix and inter-operation gaps. A source span cannot represent two independent meanings. Inactive, unknown or resource-owned bindings cannot enter the patch, and changing red semantics to purple text without changing the Delta is rejected during create/update. For an active superseder, the declared prior `before_text` projection must also be absent from the computed and reread post-write Proposal; its survival is inactive-meaning leakage. This is a bounded scalar-carrier projection proof, not general NLP entailment or arbitrary text-diff semantics. Preview before mutation:
+
+```text
+ty-context design-resource recovery preview <session> [--json]
+```
+
+Current target digest determines state:
+
+```text
+current == pre-write digest       => unapplied
+current == expected post digest   => already applied/idempotent
+otherwise                         => concurrent conflict; fail closed
+```
+
+Produce a fresh `design-resource-reconciliation-audit-v4` bound to the same Base, Design Authority, Provider run, selected resource digests, optional expected target digest, current decision sets and the checkpoint's complete audit-expectations catalog. Include Requirements→Resource, per-key Resource→Requirements, blast-radius and inactive-leakage rows. For a Proposal writeback, apply:
+
+```text
+ty-context design-resource recovery apply <session> --audit <audit.json>
+```
+
+The helper first requires a balanced fresh audit, validates checkpoint-frozen structured downstream owners and CAS, reapplies the exact patch from the frozen original spans in memory, preserves supported UTF-8/BOM or UTF-16 encoding and the existing non-mixed EOL policy, writes a same-directory exclusive temporary file, syncs it, rechecks the target, atomically renames, rereads expected bytes, verifies every operation's calculated final interval—or removed canonical carrier—plus whole-file digest, and reconciles again. An already-post state performs no write. A `selected-source-record` owner must be repository-readable at its bound digest; an external-only Provider locator stays revalidation-pending.
+
+When no binding is `proposal-written`, omit writeback and do not invent an empty patch or transaction. Re-read Source, selected resources and downstream owners and reconcile the complete catalog read-only:
+
+```text
+ty-context design-resource recovery reconcile <session> --audit <audit.json>
+```
+
+Recovery uses only generic repository snapshot/source-record identity. It does not accept a `formal-handoff-target` label or duplicate the formal handoff parser; formal Web/App handoff readiness remains owned by `ty-context design-resource preflight`.
+
+A valid resource-owned-only case may be `allow` plus `reconciliation-balanced` with `write_action: none`, but the helper-level `handoff_ready` projection remains false. Any later readiness claim waits for the Skill-owned composition of current Provider/resource revalidation, durable final ownership and applicable formal preflight; never infer readiness merely from a balanced read-only reconcile.
+
+The helper reports only `reconciliation-balanced`, `writeback-applied`, `writeback-idempotent`, `blocked` or `external-resource-revalidation-pending`. It does not report `handoff-ready`. Missing/extra/duplicate/unresolved/distorted/unsupported coverage, per-key authority mismatch, ambiguous/illegal final ownership, inactive leakage, changed explicit-unchanged meaning, unexpected blast radius or any identity mismatch returns `blocked`. A selected external resource which the helper cannot currently reread keeps external revalidation pending even after a valid Proposal writeback.
+
+Same-directory rename, filesystem durability and the remaining same-user pre-rename race are the named Windows/macOS filesystem TCB. This is not hostile-writer linearizability or crash-proof storage. Cleanup failure is explicit. The helper removes only an exact digest-matched valid checkpoint and its now-empty session directory:
+
+```text
+ty-context design-resource recovery remove <session> --expected-sha256 <sha256>
+```
+
+Before removal it inventories the session directory. It removes the checkpoint and directory only when the directory contains exactly the helper-owned digest-matched checkpoint. Any other entry returns an explicit `partial` result and preserves both the checkpoint and unowned content; a race after checkpoint removal also returns `partial` with the retained entries. It never scans or deletes unrelated `tmp`, `.work_products`, `artifacts` or reports.
+
+## Downstream boundary
+
+Proposal–Resource reconciliation is upstream diagnostic information. It never replaces the Proposal, selected immutable resources, formal handoff, downstream UI Authority Closure or project implementation checks. A later Long-Task can prove only final Source/Contract bindings, current implementation and current Evidence. Its sole Final Gate cannot prove historical Provider execution, and the checkpoint/audits/status card never enter Long-Task Source, Contract, Authority, Evidence or completion.
+
+Only the DRA Skill may derive final `handoff-ready`, and only from helper reconciliation balance plus current Provider/resource revalidation, one durable final owner per active binding, every applicable formal handoff/preflight and no unresolved blocker. This composition is not a new Gate and says nothing about Provider history, subjective optimality, arbitrary natural-language truth or completed product implementation.

package/assets/skills/design-resource-authoring/references/resource-selection.md

@@ -42,7 +42,7 @@ Preserve each supplied item's actual role:
 - `current-implementation-evidence`: evidence of current behavior, not desired behavior by default;
 - `background`: product/technical context that informs but does not expand generation scope.
 
-An optional Source Plan is one possible input. Raw notes or an initial proposal are equally valid. Never require one merely to make the other usable.
+An optional pre-existing planning document is one possible input. Raw notes or an initial proposal are equally valid. Never require a special intermediary format merely to make another input usable.
 
 ## 4. Derive development-corresponding coverage
 
@@ -164,7 +164,7 @@ This is an explanatory shape, not a required file or schema. Never paste or para
 - For exploration, stop as soon as the requested decision is supported.
 - For a final-selected formal Web/App implementation handoff, apply the dedicated formal reference's exact stop conditions. Honest `decision_required`, `unavailable` or capability gaps remain blocking; they cannot be called ready or authorize fidelity work.
 
-During iteration, keep accepted, rejected and unresolved implications in a task-local delta buffer. Do not require or emit an interim delta after every iteration and never continuously synchronize the initial proposal. After explicit human selection or explicitly delegated selection, consolidate the buffer once and reconcile only accepted decisions into the initial proposal. If it is a writable file, update it in place while preserving original intent/provenance; otherwise return one complete revised proposal. The operation must be idempotent, name selected artifact locators/hashes and affected stable keys, and exclude rejected/unresolved choices. Never write a Source Plan, Context, `DESIGN.md`, code, tests or Contract.
+During simple iteration, keep accepted, rejected and unresolved implications in a task-local delta buffer. Do not require or emit an interim delta after every iteration and never continuously synchronize the initial proposal. If the loop requires durable semantic replay, a selected-Proposal file writeback or cross-interruption recovery, load [recovery-and-writeback.md](recovery-and-writeback.md) and use its independent origin/decision-authority/evidence/status model plus package helper; prompt prose alone cannot establish CAS or deterministic recovery. After explicit human selection or explicitly delegated selection, consolidate the buffer once and reconcile only accepted decisions into the initial proposal. If it exists only in conversation and safe materialization was not explicitly authorized, return one complete revised proposal and report cross-session deterministic recovery unavailable. Never create another intermediary planning document or mutate Context, `DESIGN.md`, code, tests or Contract.
 
 ## Worked scope examples
 

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

@@ -7,7 +7,7 @@ description: Author, preflight, execute, resume, verify, or close one complete S
 
 ## Boundaries
 
-Use one currently selected host execution Goal, one repository, one selected verification workspace, one complete Contract and one Final Gate. This workflow never creates, invokes or manages a scheduler, agent runtime, App Server, branch/worktree fan-out, merge, push, PR, deployment, Campaign/SFC/Packet/Wave chain, matrix, verdict or second Contract plan. The parent Goal owns Source, Contract, Authority, architecture, Context writeback, integration, current-candidate checks, formal verification, Final Gate, close and completion. Harness never allocates, schedules, retries or recovers delegated workers; their reports are not Progress, Evidence or proof, and every result must converge into the selected verification workspace before verification counts. Never activate from task size alone.
+Use one currently selected host execution Goal, one repository, one selected verification workspace, one complete Contract and one Final Gate. This workflow never creates, invokes or manages a scheduler, agent runtime, App Server, branch/worktree fan-out, merge, push, PR, deployment, legacy orchestration chain, matrix, verdict or second Contract plan. The parent Goal owns Source, Contract, Authority, architecture, Context writeback, integration, current-candidate checks, formal verification, Final Gate, close and completion. Harness never allocates, schedules, retries or recovers delegated workers; their reports are not Progress, Evidence or proof, and every result must converge into the selected verification workspace before verification counts. Never activate from task size alone.
 
 That Goal is host/user-selected; Harness does not create, persist or reconnect a Goal identifier. Compaction may continue inside it; a later physical Goal/session restores semantic state through `resume`, not a prior Turn. With a valid binding, run `ty-context long-task resume <workdir>`, then directly load the installed `long-task-workflow` Skill; recovery needs no implicit invocation.
 
@@ -15,13 +15,13 @@ The host/user owns model selection. Exactly one unconditional terminal-turn chec
 
 A Codex-root `long-task` install may expose optional fixed package-owned `long_task_implementation` with child multi-agent disabled. It is static, stateless, non-Authority and post-checkpoint—not a checkpoint option, model route or runtime. Install proves no discovery or selection. If unavailable/invalid/colliding or not exactly selectable, the parent implements; never substitute a generic child or add dynamic tiers, retry or scheduling.
 
-`long-task-delivery-v2` is the only active Contract schema. `delivery-contract.yaml` is the one root authoring file. New authoring uses inline Outcomes; existing `outcome_files` are physical compatibility only. `delivery-set` is retired and non-executing.
+`long-task-delivery-v2` is the only active Contract schema. `delivery-contract.yaml` is the one root authoring file. New authoring uses inline Outcomes; existing `outcome_files` are physical compatibility only. Legacy split-delivery commands are non-executing.
 
 ## Controlling Objective
 
-Prevent false completion inside declared authority. Given complete and accurate Source at the declared observable granularity, a meaning-preserving Source-to-Contract projection, complete applicability expansion and a sound named verifier/runner trust boundary, `AcceptedDeliveryTerminal` must imply that no declared observable drift remains. Implementation may drift, fail or require rework, but every declared requirement, semantic Fact, selected-design Fact, proof obligation and independently falsifiable AC must remain traceable; every unsatisfied, unverifiable, stale, failed, externally pending or otherwise unproved item must block or explicitly qualify completion.
+Prevent false completion inside declared authority. Given complete and accurate Source, a meaning-preserving Contract projection, complete applicability and the admitted-observer boundary, `AcceptedDeliveryTerminal` implies no declared machine-observable drift remains. Machine completion requires package-admitted Actual and Harness-owned comparison; unsupported proof remains blocking External Confirmation. Implementation may drift or require rework, but every declared requirement, Fact, proof obligation and independently falsifiable AC stays traceable, and every unproved item blocks or qualifies completion.
 
-Complete Source is not a prose or current-code ceiling. Material non-UI meaning uses the finest independently decidable standard and custom semantic Facts plus every required proof method. For selected design resources, Agent implementation, acceptance and testing fully conform to every material Fact in declared scope and conditions; formal input therefore uses complete canonical acquisition, Census, atomic Fact/proof closure and exact production-target evidence. Deliberately partial design input remains an explicitly scoped constraint or blocking unresolved input; incomplete implementation-source acquisition is blocking, and an exact target requires layout and pixel Facts for every declared condition. `UI symbolic V2 is explicit opt-in; V1 remains the default.` `Non-UI symbolic admission and Provider/P0 trust-boundary work remain out of scope.` Read the Source, Contract and Evidence references for the exact V1/V2 authoring and proof rules.
+Complete Source is not a prose or current-code ceiling. Material non-UI meaning uses the finest independently decidable standard and custom semantic Facts plus every required proof method. For selected design resources, Agent implementation, acceptance and testing fully conform to every material Fact in declared scope and conditions; formal input therefore uses complete canonical acquisition, Census, atomic Fact/proof closure and exact production-target evidence. Deliberately partial design input remains an explicitly scoped constraint or blocking unresolved input; incomplete implementation-source acquisition is blocking, and an exact target requires layout and pixel Facts for every declared condition. `UI symbolic V2 is explicit opt-in; V1 remains the default.` Non-UI symbolic admission remains out of scope; machine-observer and verifier/runner trust-boundary closure is mandatory rather than deferred Provider/P0 work. Read the Source, Contract and Evidence references for the exact V1/V2 authoring and proof rules.
 
 Only fresh evidence from the complete current final snapshot may create machine acceptance. Exactly fresh `machine_accepted` with no pending External Confirmation is `AcceptedDeliveryTerminal`; `machine_accepted_external_pending` proves only declared machine scope. Progress is repair evidence only and never acceptance authority. Final Gate is the sole Long-Task Engineering Quality Conformance and Architecture Conformance carrier, and it proves only the declared, falsifiable, project-check-bound set—not overall code quality. This adds no quality Boolean, matrix, Source aspect, Claim/risk kind, Contract field, second Gate, state or Receipt, and no separate default Contract Conformance closure runs.
 
@@ -42,7 +42,7 @@ Do not copy reference detail into another Skill, plan or state file. The same `d
 
 ## Contract Draft And Outcome Decomposition
 
-Every external initial proposal, selected design resource, ordinary prose proposal, legacy Source Plan or other material input enters the same non-authoritative `delivery-contract.yaml` Draft immediately. Inventory, Source-quality synthesis/refinement, provenance, markers, repository binding and Contract mapping converge in one `long-task-workflow` lifecycle and need not be completed in one response. Conversation-only material becomes exactly one project-native Markdown Source. Do not create a Source-authoring phase, standalone Contract Draft Skill, Draft Receipt, Authoring State, draft schema/CLI/runtime state, handoff or second plan.
+Every external initial proposal, selected design resource, ordinary planning document or other material input enters the same non-authoritative `delivery-contract.yaml` Draft immediately. Inventory, Source-quality synthesis/refinement, provenance, markers, repository binding and Contract mapping converge in one `long-task-workflow` lifecycle and need not be completed in one response. Conversation-only material becomes exactly one project-native Markdown Source. Do not create a Source-authoring phase, standalone Contract Draft Skill, Draft Receipt, Authoring State, draft schema/CLI/runtime state, handoff or second plan.
 
 A Draft Outcome is an Outcome before Authority Lock, not a new schema field or runtime entity. Decompose only vertical, independently observable, decidable and target-verifiable results whose dependencies and owner boundary can be stated. `depends_on` and Stage gates express acceptance and intermediate-proof readiness, never implementation permission. Do not split for response/YAML/file length, implementation layer, module/file count, Agent capacity, Worker assignment or desired parallelism.
 
@@ -70,4 +70,4 @@ When implementation discovers a blocker, classify it under the existing protecte
 
 Final Gate recompiles Source authority, freezes and rechecks the complete protected current snapshot, reruns every declared Check and sensitivity control and rejects any protected-input, workspace/tree or Active Authority drift. It never trusts historical Progress, Receipt, compiled cache, delegated report or Agent judgment. Before invoking native Goal completion, perform the required veto-only comparison of current user/Goal meaning with accepted marked Source; mismatch returns to Source/Contract repair and creates no second Gate or proof.
 
-Report implementation, effective risk, Architecture Deliberation and Engineering Quality/Architecture Conformance status, Claim Coverage, Stage frontier/results, declared target profile and exact `target_state`, Live Gate result, acceptance scope, pending External Confirmations, Context status and blockers. Use verifier terms exactly and state the theorem boundary honestly: undeclared or inaccurate Source and unsound project Oracles cannot be repaired mechanically; Final Gate proves only declared machine authority and its declared project-check-bound quality set; native Goal/model selection belongs to the host/user; official worker-start boundary injection and advisory reports do not make delegation an observed or persisted acceptance input.
+Report implementation/risk, Architecture and Engineering Quality Conformance, Claim Coverage, Stage/target/Gate results, acceptance scope, pending External Confirmations, Context and blockers. Use verifier terms and state boundaries honestly: undeclared/inaccurate Source and unsound project Oracles are not mechanically repaired; Final Gate proves only declared machine authority and its project-check-bound quality set; the host/user owns the native Goal/model; worker injection and reports are not acceptance inputs. The observer remains Level 3; `observed_lifecycle_*` facts cannot replace complete total-cost ROI or the independent audit required for Level 4.

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

@@ -10,9 +10,9 @@ Read this only while authoring or structurally revising the one `delivery-contra
 - 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.
+- Missing headings or keys from a pre-existing planning document 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.
+- `delegated` in an input proposal 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.
@@ -26,8 +26,8 @@ For every Outcome:
 
 - `semantic_fact_bindings.manifest_ref` equals the root manifest key;
 - `semantic_fact_bindings.facts` is set-equal to that Outcome's manifest Facts. Each row binds one `fact_ref` to exactly the generated `semantic_fact.<fact_ref>` Claim and one matching atomic applicability profile;
-- `semantic_fact_bindings.proofs` is set-equal to that Outcome's Fact × required-method obligations. A machine row preserves method, proof surface and all evidence capabilities, binds one owning Check and one single-Claim Assertion at the same applicability, and requires typed `semantic_fact` evidence. An external row binds one typed External Confirmation whose impacts include the full Fact Claim;
-- every declared observer resolves to an execution target capable of observing the furthest independently failing boundary; a product/self-reporting proxy cannot impersonate an independent observer;
+- `semantic_fact_bindings.proofs` is set-equal to that Outcome's Fact × required-method obligations. A machine row preserves method, proof surface and all evidence capabilities, binds one owning Check and one single-Claim Assertion at the same applicability, and is legal only when Compile can project it to one package-admitted current-Actual authority. An external row binds one typed External Confirmation whose impacts include the full Fact Claim;
+- every declared observer resolves to an execution target and admitted package adapter capable of observing the furthest independently failing boundary; a project-authored Oracle, product/self-reporting proxy, wrapper or submitted capability record cannot impersonate that observer;
 - the Claim/Assertion/Check projection must be bijective. Missing, extra, duplicate, reused, narrowed or orphan Fact/proof identities block Authority Lock.
 
 The exact invariants are:
@@ -38,6 +38,8 @@ The exact invariants are:
 
 Do not copy raw semantic values into Contract, merge multiple atomic facts into one Claim, use one Assertion for several Fact obligations, turn a machine-verifiable Fact external because implementation is difficult, or accept a default/sample/aggregate path. A protected Fact uses digest-only expected authority and a policy-bound redacted/digest observation with no raw persistence. Genuine decision/external authority remains explicit and target-blocking as required.
 
+Compile derives one internal observation-authority row for each machine proof. Current admission has only two choices: `package_static_json_exact` for plain `exact_value + exact` static implementation/configuration content in a pre-run-frozen UTF-8 JSON production carrier, and `package_process_json_exact` for plain exact output observed while Harness directly spawns the declared `process` product root. Every other proof—including custom/`named_external_tcb` Oracles, project wrappers, protected data, tolerance/mask, custom locators and browser/native/device/layout/pixel/accessibility/motion observations—must be authored as a blocking External Confirmation. This projection is not a new Contract field, Authority, state or registry, and unsupported machine rows fail Compile rather than auto-migrating.
+
 ## 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.
@@ -60,16 +62,16 @@ Declare only real applicability, not a blind Cartesian product. Each global or O
 
 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.
+Every Counterfactual mutation path must be a current production carrier with a defensible route from the declared target root to the asserted behavior. A Binding or `input_paths` declaration is not reachability proof. A static-structure proof mutates and observes the frozen structure object itself and cannot be promoted to runtime behavior; a runtime proof requires Harness mutation of the declared carrier, direct execution of the same process product root and package-observed actual change. Declare the expected affected Facts, preserved Facts and allowed fan-out Facts; baseline and mutation must retain the same obligation universe, all expected Facts must change, preserved/liveness Facts must not change and every other change must be listed fan-out. A machine-closing Check with no admitted baseline or mutated observation fails rather than skipping. Review `verify --explain` before an expensive first execution and repair obsolete routes, barrels, fixtures or duplicate Main/Counterfactual invocations.
 
-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.
+Declare cheap machine-checkable prerequisites through existing environment requirements and verification inputs. Product/API readiness probes, incremental build caches, streaming phase output and timeout heartbeats belong to the project-owned runner when they depend on its runtime. The admitted direct-process observer is the narrow exception: Harness owns bounded stdout capture plus process-tree inspection and cleanup because those are part of its host execution TCB; this remains containment rather than an absolute hostile-code sandbox.
 
 ## 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.
+- A multi-Outcome Stage Gate declares `cross_surface_consistency`. Its diagnostic runtime record names at least two distinct `surface_ref` values, may use the same runtime target for several pages and reports one matching state version. Because the current slice has no package derivation for that capability, the owning machine obligation remains a blocking External Confirmation.
+- `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, complete `root_argv` and explicit capabilities. Give every required target one Source technical obligation whose canonical target is `execution_target.<key>` and whose exact normalized statement preserves key, role, family, root, complete argv and capabilities; the Source Claim disposition, execution target and production Binding must agree. A required process root and every argv path admitted by the finite production-Binding match belong to the production owner and a Binding, not merely to the runner, a fixture, verification input or `input_paths`. The match examines a standalone argument or explicit `--key=value`, resolves a safe repository-relative value from declared `cwd`, and accepts exact or pattern Binding coverage, including glob-owned and extensionless files. Unmatched safe relative values are labels/outputs rather than inferred dependencies and are not copied. Absolute paths, repository escapes, `file:` URLs and network URLs fail closed unless explicitly routed to the external TCB/External Confirmation boundary. An exact planned root, matched argv file or process carrier may be absent through Preflight/Compile, but Final Gate requires it to exist; materializing the already-declared path does not revise Authority. Do not guess from file extensions, substrings, output flags or a language dependency graph. Root/family/role/argv/capability declaration change is a protected Source/Contract and Authority Revision. Current machine `target_runtime` proof exists only for a Harness-direct Source-backed `process` product root; required browser/native/desktop/device targets and other unsupported families retain target-blocking External Confirmation. Every Stage Gate and every `critical_user_path` Outcome accounts for every required ref through admitted root proof or that External Confirmation. 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.
 
 ## Engineering Quality Deliberation And Closure
@@ -92,27 +94,30 @@ Do not encode subjective “clean architecture”, `quality == true`, a function
 
 ## 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.
+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 it 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. Under the current admitted slice, machine runtime proof is available only through Harness direct-process observation; all other runtime families remain target-blocking External Confirmation.
 
 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.
+2. for machine proof, use a `project_binary` runner whose target exactly equals the declared `runtime_family: process`, `role: product` root entrypoint, has no wrapper and permits read-only or test-sandbox execution;
+3. let Harness own the process handle and capture exactly one bounded `ty-context-product-observation-v1` envelope from product stdout. It proves only exact values that the root itself emits on that declared JSON output surface; project-authored instrumentation/mapping cannot reclassify arbitrary internal/UI facts as package-observed, and any Claim that cannot bind directly to the surface requires External Confirmation. Do not declare or consume an observation-path, challenge or protocol environment variable; the execution nonce is internal host-attestation data. Project-submitted v3 actual/comparison/verdict and capability records remain diagnostic only;
+4. declare runtime-affecting entrypoints, modules/configuration and Claim/Counterfactual carriers through the production owner and Binding. For argv, use a standalone argument or explicit `--key=value`; Harness resolves a safe repository-relative value from declared `cwd` and includes it only when an exact or pattern production Binding covers the result. Glob-owned and extensionless files are valid, an unmatched safe relative value is not copied, and absolute/escaping/file-URL/network values fail closed unless explicitly external. `input_paths` still describes Check scope/freshness but is neither broadly role-scanned nor promoted into the process snapshot. Compile rejects any actual closure member that overlaps Source/Context/Contract/canonical expected, verification, expected-output/artifact, evidence/status/report/comparison/Receipt/Long-Task or historical-session roles. Global closure records keep `<outcome>.<binding>` logical identity while physical files deduplicate by path; authored Contract Bindings remain local and unchanged. Harness copies only this compiled closure, and a dependency that cannot be explicitly production-bound remains External Confirmation rather than triggering extension, substring, output-flag or language dependency guessing; and
+5. otherwise bind the Claim to a blocking External Confirmation instead of inventing a project-verifier proof.
+
+This process path relies on the host OS/filesystem/process APIs, Node runtime, snapshot copy/digest checks, stdout decoder and process-tree inspection/cleanup. It is not a security sandbox and does not claim containment against a malicious executable using ambient filesystem/network resources or evading every process-tree mechanism. If the Contract requires that threat boundary, use an independently controlled sandbox and keep its acceptance external until a package adapter is separately admitted.
 
-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.
+A proxy check, project-verifier payload, static repository shape, tracked status report, prior screenshot, binary, historical run or new `session_id` cannot be the sole proof of a Claim that can fail independently in the target. The required target family must equal the admitted observer family. 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.
+- External Confirmation coverage is exact for ordinary/global Claims and Semantic Fact Claims; it creates no machine Assertion or result. For a fully unsupported Outcome, set `success_path_required: false`, omit machine Checks, include every affected Claim in `impact_claims` and keep each Semantic Fact proof explicitly bound to that confirmation. A Stage Gate may omit its machine Check only when a `blocks_target: true` confirmation impacts that gate's `result` Claim. A non-blocking confirmation or one missing the result impact cannot substitute, and `success_path_required: true` still requires a real success Check. The final status is `blocked_external`, never machine accepted.
+- `boundary_invocation` and `external_side_effect` still require a declared independent `observer` target, but the current slice has no package derivation for either capability. Their project records are diagnostic and their obligations remain External Confirmation; 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 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. The complete design Fact universe remains mandatory Source authority, but the current machine observer does not admit browser/native/device/layout/pixel/accessibility/motion or protected/tolerance/mask observations; those Fact × method obligations must be blocking External Confirmations rather than project-verifier machine rows:
 
 - 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. A formal Web/App profile requires a canonical entry, exact dependency closure, complete acquisition and one frozen-Inspector Fact manifest proving `Expected Fact Universe = Canonical Resource Facts = Handoff Indexed Facts`. The atomic unit is an explicit `subject × target × condition × variation × property` Fact Cell: stable component instances/Anatomy Parts/relations and dynamic populations; all standard/custom target-condition and subject-variation axes/combinations; the complete standard/custom atomic property catalog; explicit N/A/exclusion basis; one Fact per covered cell; and every property-required Fact × method proof. Product Controls and eight UI/UX dimensions are semantic/roll-up owners, not the Fact ceiling. Incomplete acquisition/Census, aggregate labels, initial default-page inference, sampling/truncation, unresolved locators/lineage/conflicts/blockers, unsupported evidence and stale identities block. Canonical resources own exact values; the residual handoff projects located digests, value/design-system lineage, sensitivity, evidence, comparator/tolerance/mask, Oracle/environment and asset bindings without becoming a CSS copy. Every exact target additionally requires full-target layout and pixel Facts per condition. Deliberately partial input remains an explicitly scoped constraint or blocking unresolved and never an exact target. Treat candidates and unresolved decisions honestly; only a selected exact target with a valid selection basis, complete declared Fact universe 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;
@@ -124,19 +129,19 @@ When the selected delivery includes a new/redesigned screen, primary layout/navi
 - 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`;
+- 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 and every Control Claim must have target-local disposition. The admitted direct-process observer can derive host `target_runtime` for the real process root, but it does not currently derive `interaction_trace`; interaction plus browser/native/device journeys remain blocking External Confirmations;
 - 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 exact per-condition `evidence_artifacts`. Each cell declares the exact proof-owned `fact_refs`, `path` for its method record, `observation_path` for its primary method-native observation and a canonical `fact_expectations` row for every Fact. That row freezes subject, variation, property, `plain|protected` sensitivity, expected canonical located digest, comparator, exact/tolerance mode, parameter/tolerance/narrow-mask located digests, Oracle key/trust/identity/version/digest and environment key/identity/definition located digest. Contract stores these references and digests, never a duplicate CSS value source. Cell Fact sets close every property-required Fact × method obligation; their exact union equals the target 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 and one exact `fact_results` row per Fact. Each result binds subject/variation/property; attributable actual observation and actual environment paths/digests/typed locators/value digests; the frozen comparison fields and comparison artifact; explicit pass/fail verdict; and exact Oracle/environment identities. Protected observations require digest-only or redacted structured representation, a policy ref and `raw_persisted: false`; plain observations reject unexpected redaction. Missing/extra/duplicate/stale/failed rows, sensitivity or authority drift, mismatched environment, widened mask/tolerance, result reuse or indistinguishable observation fails the Assertion. 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, Inspector counts, file hashes 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;
+- 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 exact per-condition `evidence_artifacts`. Each cell declares the exact proof-owned `fact_refs`, `path` for its method record, `observation_path` for its primary method-native observation and a canonical `fact_expectations` row for every Fact. That row freezes subject, variation, property, `plain|protected` sensitivity, expected canonical located digest, comparator, exact/tolerance mode, parameter/tolerance/narrow-mask located digests, Oracle key/trust/identity/version/digest and environment key/identity/definition located digest. Contract stores these references and digests, never a duplicate CSS value source. Cell Fact sets close every property-required Fact × method obligation; their exact union equals the target Fact set. Current package derivation supplies only admitted plain exact/presence results and host `target_runtime`; project or Playwright `design_method`, `fact_results`, `design_conformance` and `interaction_trace` rows remain diagnostic and cannot provide authority. Because the current slice does not admit design conformance, interaction, layout, pixel, accessibility, motion, browser/native/device, protected or tolerance/mask observation, those obligations retain their exact expectations but bind blocking External Confirmations instead of fabricated machine results. Missing/extra/duplicate/stale/failed rows, authority drift, mismatched environment, widened mask/tolerance, result reuse or indistinguishable observation still fail every admitted exact Assertion. `visual_render`, handoff preflight, Inspector counts, file hashes 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 obligation compiles to a package-admitted static or direct-process exact observation and the referenced Claims have matching 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;
+- retain `ui_browser` assertions only as project diagnostics during this first observer slice. Browser, Expo-Web, native, mobile and desktop UI conformance cannot machine-close a Claim; bind the affected Claim or blocker to target-blocking External Confirmation rather than treating Playwright, a project binary, screenshot or device/session payload as observer authority;
 - 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.
+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 intermediary authoring 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. Any pre-existing planning document 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.
 
 ## Symbolic Selected-Design Authoring
 
-UI symbolic V2 is explicit opt-in; V1 remains the default. Accept `design-resource-handoff-v2` only when the target explicitly declares `representation: symbolic_rules_v2`. Require equal extensional disposition, located expected semantics and complete proof-obligation denotation across every subject/relation, target, reachable condition/variation, applicable atomic property and population/quantifier point; physical V1 ground-row identity is irrelevant. V2 Rules use constant located expected values and mutually exclusive exhaustive canonical regions. Applicability may retain legacy exact remainder partitions or use package-owned subject property profiles plus frozen Inspector custom-property closure and explicit unique instance exceptions; every logical subject-property point still needs exactly one disposition. Project every required method to typed current Rule-region evidence and each set-valued Rule/omitted-axis certificate to a separate fresh recomputed result without materializing Rule × axis edges. An omitted axis requires both Source-side and production-side proof through frozen closed-world static dependency closure, restricted-IR exact equivalence or finite complete-domain exhaustive equivalence; dynamic/reflected/unfrozen/external or sampled dependencies block. A Contract may mix V1 and V2 targets, but records cannot cross-substitute and all converge only in the existing Final Gate. V1 over-capacity diagnostics may guide an explicit V2 decision but never switch automatically. Purpose-efficiency is package admission, not terminal safety or a new Gate. Non-UI symbolic admission and Provider/P0 trust-boundary work remain out of scope.
+UI symbolic V2 is explicit opt-in; V1 remains the default. Accept `design-resource-handoff-v2` only when the target explicitly declares `representation: symbolic_rules_v2`. Require equal extensional disposition, located expected semantics and complete proof-obligation denotation across every subject/relation, target, reachable condition/variation, applicable atomic property and population/quantifier point; physical V1 ground-row identity is irrelevant. V2 Rules use constant located expected values and mutually exclusive exhaustive canonical regions. Applicability may retain legacy exact remainder partitions or use package-owned subject property profiles plus frozen Inspector custom-property closure and explicit unique instance exceptions; every logical subject-property point still needs exactly one disposition. Project every required method to typed current Rule-region evidence only when its Actual comes through the admitted package observer; otherwise bind the obligation to External Confirmation. Each set-valued Rule/omitted-axis certificate remains a separate fresh package-recomputed result without materializing Rule × axis edges. An omitted axis requires both Source-side and production-side proof through frozen closed-world static dependency closure, restricted-IR exact equivalence or finite complete-domain exhaustive equivalence; dynamic/reflected/unfrozen/external or sampled dependencies block. A Contract may mix V1 and V2 targets, but records cannot cross-substitute and all converge only in the existing Final Gate. V1 over-capacity diagnostics may guide an explicit V2 decision but never switch automatically. Purpose-efficiency is package admission, not terminal safety or a new Gate. Non-UI symbolic admission remains out of scope; verifier/runner observation authority is covered by the mandatory admitted-observer boundary above.
 
 ## Compact Authoring