project-tiny-context-harness 0.7.9 → 0.8.1

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

@@ -85,7 +85,7 @@ For exploration, ask what remains uncertain inside the scope. For a handoff, ask
 - **visual direction:** composition, typography, color, density, imagery or brand character;
 - **platform/responsiveness:** safe areas, breakpoints, input methods or viewport behavior;
 - **system reuse:** tokens, component variants or cross-surface rules needed by more than the requested artifact;
-- **team editability:** a real need for collaborative editable frames/libraries or an organizational Figma handoff.
+- **team editability/native inspection:** a real need for collaborative editable frames/libraries, inspectable component/token facts or an organizational native-platform handoff.
 
 Do not manufacture a gap already resolved by selected Source.
 
@@ -100,7 +100,7 @@ Do not manufacture a gap already resolved by selected Source.
 | Flow/journey board | Multiple surfaces, branches or recovery paths must be compared together | The request is one isolated surface/control |
 | Design-system slice | Several requested artifacts need shared tokens/components or reuse rules | One exploratory candidate does not justify a system |
 | Component inventory/specification | Development handoff needs explicit reusable families, variants, state behavior or mappings for several control instances | Exploration is visual only, or selected component sources already cover every mapped instance |
-| Figma handoff | Editable collaborative frames/libraries are explicitly valuable and operational | A screenshot/HTML/project-native source is sufficient or connector/auth/export is unavailable |
+| Collaborative native design input | Existing team authority, editable collaboration, native component/library reuse or organizational handoff is explicitly valuable and the connector/auth/read/export path is operational | Open Design/project-native implementation source is sufficient or the native path would create a second synchronized representation |
 | Image/illustration/icon/media study | Bespoke content materially defines the selected direction | Generic placeholders answer the present decision |
 
 A prototype is often valuable for new Web/App flows, but it is never automatically required. Low- and high-fidelity resources may both be selected only when they answer independent questions. One comprehensive, inspectable artifact may cover page composition and several component families; a static frame cannot claim unseen interaction or state coverage merely because all controls appear in it.
@@ -155,9 +155,9 @@ This is an explanatory shape, not a required file or schema. Never paste or para
 
 - Keep each revision inside the original scope ceiling unless the user explicitly expands it.
 - Reuse the current Open Design project when that preserves context and provenance; preserve the prior artifact hash before overwriting a selected candidate.
-- Do not create low-fi, high-fi, component boards and Figma copies merely because a process diagram lists them.
+- Do not create low-fi, high-fi, component boards or native-platform copies merely because a process diagram lists them.
 - For exploration, stop as soon as the requested decision is supported.
-- For an implementation handoff, stop only when every material in-scope coverage item has an explicit disposition and the resource mapping leaves no material user-visible design decision for the implementer to invent. Honest `decision-required` or `unavailable` items may stop generation but remain visible blockers/limitations; this does not claim Design Authority or implementation acceptance.
+- For an implementation handoff, stop only when every material in-scope coverage item has an explicit disposition and the resource mapping leaves no material user-visible design decision for the implementer to invent. Honest `decision-required` or `unavailable` items may stop further generation, but the result is a blocked authoring outcome: it cannot pass shared preflight, be called a ready implementation handoff or authorize fidelity work. This does not claim Design Authority or implementation acceptance.
 
 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.
 

package/assets/skills/design-system-authoring/references/authority-adoption.md

@@ -26,9 +26,9 @@ Do not copy the same fact into several owners. Open Design metadata is provenanc
 1. Read the project's `DESIGN.md` format and lint expectations. Preserve valid project-specific content unless the user explicitly authorized replacement.
 2. Reconcile selected provider semantics against controlling Context. Provider-invented business, permission, data or algorithmic rules are excluded unless independently authorized by product Source.
 3. Write the selected visual system into `DESIGN.md` and declare exactly one authored exact-value token source or generation direction. Avoid style-only adjectives without implementation meaning.
-4. Record provider provenance in a normal `DESIGN.md` section unless the format explicitly permits metadata fields. Include provider name/version, design-system ID, selected revision when applicable, selection basis, source/snapshot locator and SHA-256 digest. State that project files are canonical.
-5. Update only relevant Context when durable surface/interaction/verification facts changed. Use stable surface/control/target keys to connect owners without duplicating the visual prose.
-6. Put concrete selected targets/tokens in project-native versioned paths selected by the user or existing project convention. Never silently choose a repository directory merely because Open Design has a mutable workspace.
+4. Record provider provenance in a normal `DESIGN.md` section unless the format explicitly permits metadata fields. Include provider name/version, design-system ID, selected revision when applicable, selection basis, immutable source/snapshot locator and SHA-256 digest, plus the editable upstream owner/locator/update/export route. State that project files are canonical.
+5. Update only relevant Context when durable surface/interaction/verification facts changed. Use stable surface/control/target keys to make every adopted decision-relevant target Context-reachable without duplicating the visual prose.
+6. Put concrete selected targets/tokens in project-native versioned paths selected by the user or existing project convention. Never silently choose a repository directory merely because Open Design has a mutable workspace. Never overwrite an adopted baseline in place; update upstream, create or approve a new immutable version/digest and update the owning reference.
 7. Accept the selected provider revision if one exists, then re-read the MCP design-system resource and compare its identity/body or digest with the adopted selection.
 8. Verify downstream project binding by creating or reading a provider project with the selected ID. Provider mismatch is a synchronization problem, not evidence that project Design Authority is absent.
 
@@ -39,6 +39,7 @@ Run the repository-owned Design Authority lint, Context validation and token gen
 - `DESIGN.md` is no longer an unconfigured starter;
 - exactly one authored token source/generation direction is declared and resolvable;
 - provenance points to the selected provider ID/revision/digest;
+- each adopted target has a readable immutable locator and a verified editable upstream/update route or an explicit manual/external-update boundary;
 - no competing design-system authority or duplicate token owner was introduced;
 - MCP can read the provider design system;
 - a downstream Open Design project reports the matching `designSystemId`;

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

@@ -17,15 +17,17 @@ The host and user own model selection and native-Goal lifecycle. The workflow ha
 
 Prevent false completion inside declared authority. Implementation may drift, fail or require rework, but every declared non-Result requirement and AC must remain traceable and every unsatisfied, unverifiable, insufficiently evidenced or stale item must block completion. In particular, a proxy target, presence text, degradation path, fixed input, self-reported boundary effect or internal entrypoint must never substitute for the declared target behavior. Findings should localize repair through Source Item, Stage, Outcome, Claim, Assertion, Check, Evidence Capability, execution target, Binding and owner boundary.
 
+For selected design resources, one design-specific objective is that Agent implementation, acceptance and testing fully conform to every material UI/UX fact explicitly expressed within declared scope and conditions. Open Design can produce source-rich, implementation-readable resources, but capability alone is not a guarantee: resource authoring must require a canonical entry, complete dependency acquisition and stable machine-resolvable facts. The validated `design-resource-handoff-v1` remains the residual scope/applicability/semantic adapter rather than a copy of CSS values. Preserve each fact through immutable inputs, typed locators, complete subject × target × condition × dimension cells, Context-reachable targets, Source/Control/Claim authority, one independent Assertion per verification method and current-snapshot project Checks to Final Gate. Never invent an unexpressed fact: refine the resource, retain `decision_required`/`unavailable`, or block fidelity work. Neither provider success, file hashes nor handoff integrity proves production conformance.
+
 Only fresh evidence from the complete current final snapshot may create machine acceptance. Otherwise report the task as unfinished or qualified. `machine_accepted_external_pending` means machine-verifiable authority passed while named external confirmation remains; it is not full delivery completion. Machine acceptance covers declared machine Authority and has no direct native-Goal effect. Never substitute prose, progress, historical tests, Receipts, one exit code or Agent judgment for the Final Gate.
 
 Prefer the lowest practical Authoring, Runtime, State, Recovery and verification cost that preserves the same false-completion interception. Add no mechanism whose distinct protection does not materially exceed its total cost.
 
 ## Progressive Reference Loading
 
-Read only the reference needed for the current phase; these files are guidance, not new artifacts or authority:
+Read only the reference needed for the current activity; these files are guidance, not new artifacts or authority:
 
-- When inputs are raw, mixed, attachment-heavy, incomplete or need synthesis/refinement before Contract mapping, read [`references/source-authoring.md`](references/source-authoring.md) and author the needed self-contained meaning directly inside this workflow.
+- When inputs are raw, mixed, attachment-heavy, incomplete or need synthesis/refinement while the Contract Draft is being mapped, read [`references/source-authoring.md`](references/source-authoring.md) alongside the Contract-authoring reference. Do not wait for a separate Source-authoring phase before opening the Draft.
 - Before creating or structurally revising Source markers, Outcomes, requirements, controls, obligations, architecture boundaries, paths, Bindings, Assertions or risk, read [`references/contract-authoring.md`](references/contract-authoring.md).
 - Before creating or repairing Checks, runners, Observations, proof surfaces, Playwright/structured evidence, Counterfactuals, Population or environment probes, read [`references/evidence-design.md`](references/evidence-design.md).
 - Before Preflight, Compile, protected revision, resume, targeted verify, Final Gate, Stop, close or abandon, read [`references/authority-lifecycle.md`](references/authority-lifecycle.md).
@@ -34,7 +36,7 @@ Do not copy reference detail into another plan or state file. The same `delivery
 
 ## Contract Draft And Outcome Decomposition
 
-Before the first successful formal Compile, continuously revise the same non-authoritative `delivery-contract.yaml` as the Contract Draft. It need not be completed in one response; keep reading Source, repository and relevant Context and feed Preflight findings back into that same Draft. Draft authoring, Preflight, Compile, rolling execution, targeted verification and Final Gate are one `long-task-workflow` lifecycle. Do not create a standalone Contract Draft Skill, Draft Receipt, Authoring State, draft schema/CLI/runtime state or second plan.
+Every input enters the same non-authoritative `delivery-contract.yaml` Draft immediately. Before the first successful formal Compile, continuously revise that Source-bound Draft while real Source inventory, provenance, refinement, markers, repository binding and mapping converge. It need not be completed in one response; keep reading Source, repository and relevant Context and feed Preflight findings back into that same Draft. Draft authoring, Preflight, Compile, rolling execution, targeted verification and Final Gate are one `long-task-workflow` lifecycle. Do not create a Source-authoring phase, standalone Contract Draft Skill, Draft Receipt, Authoring State, draft schema/CLI/runtime state or second plan.
 
 A Draft Outcome is an Outcome in that pre-Authority-Lock Draft, not a new schema field or runtime entity. Decompose only vertical, independently observable, decidable and target-verifiable results whose dependencies and owner boundary can be stated; one Outcome belongs to one declared Stage and does not span materially different success paths. Declare the ordered Stage DAG and one gate Outcome per Stage in the same Contract. Use those boundaries to keep a stage-constrained dependency-ready working set, target verification, localize failures, resume findings/next actions and stale local results precisely.
 
@@ -45,19 +47,18 @@ A Draft Outcome is an Outcome in that pre-Authority-Lock Draft, not a new schema
 ## Entry And Authoring Loop
 
 1. Read the user request or external initial proposal, selected design resources and minimum controlling Context. Collect the architecture owners, extension points and boundaries needed for the shared deliberation before deciding `Context Delta`.
-   - For material production UI, read the Contract-authoring visual guidance before Compile. Inspect any external design resources as ordinary Source, including selection basis, stable identity and declared surface/viewport/mode/state coverage. An unconfigured starter, candidate, style-only rule or inspiration-only reference is incomplete design authority unless Source explicitly scopes the result as prototype/non-fidelity or supplies a selected target before implementation.
+   - For material production UI, read the Contract-authoring visual guidance before Compile. When selected resources arrive as an implementation handoff, require one marked `design-resource-handoff-v1` in `task.source_paths` and run `ty-context design-resource preflight <handoff.md>`; incomplete applicable cells, unsupported evidence, unresolvable locators, partial implementation-source acquisition, unresolved meaning or stale resource identity is blocking. Traverse affected surface/control/target keys from owning Context through `DESIGN.md`, then open every affected selected `exact-target` or `constraint` as Context-reachable ordinary Source. Confirm selection basis, readable immutable identity/digest, declared surface/viewport/mode/state coverage and editable upstream owner/locator/update route. A registry or handoff index mention is not consumption. Missing, stale, unreadable, truncated or conflicting resources remain `decision_required`; if only the editable upstream is unavailable, the immutable target may guide implementation but requested resource edits remain a manual/external boundary. An unconfigured starter, candidate, style-only rule or inspiration-only reference is incomplete design authority unless Source explicitly scopes the result as prototype/non-fidelity or supplies a selected target before implementation. When Controls exist, bind them through Product `surface_bindings` to the required production target, existing route/component Bindings and a root-entry journey; each selected target's identity/conditions/files, covered Source Claims/root Assertion, per-method independent Assertions and blocker lineage must match the handoff before typed evidence can prove it.
    - If the user is asking to generate or iterate standalone design resources before Contract authoring rather than execute this delivery, use `design-resource-authoring` instead. Its result may later return as ordinary Source; it creates no Contract Draft or Authority.
 2. If a valid active binding exists, run `ty-context long-task resume <workdir>` and read the lifecycle reference.
-3. If the inputs are not yet self-contained, use the Source-authoring reference now. Inventory every proposal, selected design resource and attachment; preserve direct meaning; add only traceable derived/delegated meaning; enumerate material surfaces/controls/states and acceptance; and resolve or retain genuine decisions. Revise a supplied writable initial proposal when it is the delivery Source. If the request exists only in conversation, materialize exactly one project-native Markdown Source for this delivery. This is an internal authoring step in the same Goal, not a standalone Source Plan service, second plan, schema, gate or lifecycle.
-4. Otherwise author one complete Delivery Contract for the whole selected delivery. Declare the target profile, its non-empty required product target refs, each target's runtime family/root entrypoint, ordered Stages and vertical Outcomes. Do not create a second Contract plan, matrix or top-level Contract split.
-5. Preserve at least one real `source_path`. Wrap every material Source item in its original Markdown with non-rendering `ty-source-item:start/end` markers without rewriting direct text; marked Source Item keys and `source_claim` keys are exactly equal. Newly delegated meaning must first be written into that real Source with provenance before marking.
-6. An ordinary prose proposal, legacy Source Plan or externally authored design resource remains valid Source and does not need to match a recommended structure. Preserve stable semantic keys and Markdown anchors where practical. Selected resources retain their stable resource/surface/control/state/target keys, declared coverage, provider/project/run/entry provenance and immutable digest/snapshot; candidates authorize no fidelity Claim.
-7. Continue reading repository, Source and Context and revise the same Draft. A request to synthesize, refine, complete, implement or use judgment delegates plan-level authoring, but it does not invent the user's tradeoff priorities. Before comparative research or a material product, technical, architecture or provider selection, identify the criteria that could change the research scope, candidate set or recommendation. Infer them only from the user's words, Source, Context or controlling constraints. If quality versus cost, speed, reliability, privacy, lock-in, operational burden or another material priority is unknown or ambiguous, stop before that research or selection and ask one concise targeted clarification. Do not impose a questionnaire, re-ask known preferences or interrupt minor reversible choices whose recommendation would not change.
-8. Once the material preference envelope is clear, decide what research is needed. Use current authoritative or primary evidence for external capability, pricing, quota, license, compatibility, region, security posture or support claims. When one recommendation is then defensible, record it in real Source with the authoring instruction, preference/evidence basis and exact added meaning instead of pausing for approval. Append the delegated item without rewriting the user's original text when ordinary prose is the Source. Return only when authoritative requirements conflict, the user explicitly reserves the choice, a material preference remains unknown, critical semantics have no defensible recommendation or no falsifiable acceptance standard can be formed.
-9. Contract expansion remains limited to meaning-preserving structural decomposition, evidence-backed repository binding and choices first recorded as delegated real Source. Never place a new product rule, default, threshold, recovery behavior, permission or platform/data scope only in Contract YAML. Default plan delegation authorizes meaning, not action: payment, contracting, production deployment or publication, destructive production mutation, real permission grants, sensitive-data transmission and required legal/security/human approval remain named external confirmations. Any conflicting, user-reserved, missing-preference or unsupported semantic remains `decision_required`.
-10. Before formal Compile and the first implementation edit, complete the shared `Architecture Deliberation` once and surface concise repository-bound conclusions rather than private reasoning. Cover the current owner/extension point/source of truth, dependencies and lifecycle, selected and rejected alternatives, a plausible future-change challenge, touched debt and its disposition, forbidden shortcuts and project-owned Checks. Even a preservation result names concrete owners and why no new or worsened debt is introduced. Put durable conclusions in owning Context and material falsifiable delivery conclusions in real marked Source plus existing Contract fields, then decide `Context Delta: none|required`. A material scope, owner, Context or design change before implementation stales and refreshes the deliberation.
-11. Give every Check an atomic Given/When scenario and journey role; give every Assertion the minimum all-of Evidence Capabilities that can actually prove its Claim. Separate required success and degradation Checks. Type every external confirmation with impacted Claim refs and target-blocking effect. Run read-only `ty-context long-task preflight <workdir>`, repair every error and `decision_required` finding in the same Draft, then formally Compile only when ready.
-12. When the first Compile returns `execution_model_checkpoint.required: true`, stop before implementation and ask the user to choose `continue_current_model` or switch models and then resume the active Long-Task. A task-specific choice already stated explicitly satisfies the checkpoint. Later revisions return `required: false` and do not repeat it.
+3. Start one complete Delivery Contract Draft for the whole selected delivery immediately. If inputs are not self-contained, apply the Source-authoring reference inside this same Draft loop: inventory every proposal/resource/attachment, refine the writable real Source, preserve traceable provenance and resolve or retain genuine decisions while mapping target profile, Stages, Outcomes and repository evidence. Conversation-only material becomes exactly one project-native Markdown Source. Source completeness is a Preflight/Compile convergence requirement, not an earlier internal stage.
+4. Preserve at least one real `source_path`. Wrap every material Source item in its original Markdown with non-rendering `ty-source-item:start/end` markers without rewriting direct text; marked Source Item keys and `source_claim` keys are exactly equal. Newly delegated meaning must first be written into that real Source with provenance before its corresponding Draft meaning can pass Preflight/Compile.
+5. An ordinary prose proposal, legacy Source Plan or externally authored design resource remains valid Source and does not need to match a recommended structure. Preserve stable semantic keys and Markdown anchors where practical. Selected resources retain their stable resource/surface/control/state/target keys, declared applicability, source profile/entry/dependency set, provider/project/run provenance, typed locators, immutable digest/snapshot and editable upstream owner/locator/update route. Candidates authorize no fidelity Claim. Changing an adopted resource produces a new immutable version and updates the owning reference rather than overwriting the locked baseline.
+6. Continue reading repository, Source and Context and revise the same Draft. A request to synthesize, refine, complete, implement or use judgment delegates plan-level authoring, but it does not invent the user's tradeoff priorities. Before comparative research or a material product, technical, architecture or provider selection, identify the criteria that could change the research scope, candidate set or recommendation. Infer them only from the user's words, Source, Context or controlling constraints. If quality versus cost, speed, reliability, privacy, lock-in, operational burden or another material priority is unknown or ambiguous, stop before that research or selection and ask one concise targeted clarification. Do not impose a questionnaire, re-ask known preferences or interrupt minor reversible choices whose recommendation would not change.
+7. Once the material preference envelope is clear, decide what research is needed. Use current authoritative or primary evidence for external capability, pricing, quota, license, compatibility, region, security posture or support claims. When one recommendation is then defensible, record it in real Source with the authoring instruction, preference/evidence basis and exact added meaning instead of pausing for approval. Append the delegated item without rewriting the user's original text when ordinary prose is the Source. Return only when authoritative requirements conflict, the user explicitly reserves the choice, a material preference remains unknown, critical semantics have no defensible recommendation or no falsifiable acceptance standard can be formed.
+8. Contract expansion remains limited to meaning-preserving structural decomposition, evidence-backed repository binding and choices first recorded as delegated real Source. Never place a new product rule, default, threshold, recovery behavior, permission or platform/data scope only in Contract YAML. Default plan delegation authorizes meaning, not action: payment, contracting, production deployment or publication, destructive production mutation, real permission grants, sensitive-data transmission and required legal/security/human approval remain named external confirmations. Any conflicting, user-reserved, missing-preference or unsupported semantic remains `decision_required`.
+9. Before formal Compile and the first implementation edit, complete the shared `Architecture Deliberation` once and surface concise repository-bound conclusions rather than private reasoning. Cover the current owner/extension point/source of truth, dependencies and lifecycle, selected and rejected alternatives, a plausible future-change challenge, touched debt and its disposition, forbidden shortcuts and project-owned Checks. Even a preservation result names concrete owners and why no new or worsened debt is introduced. Put durable conclusions in owning Context and material falsifiable delivery conclusions in real marked Source plus existing Contract fields, then decide `Context Delta: none|required`. A material scope, owner, Context or design change before implementation stales and refreshes the deliberation.
+10. Give every Check an atomic Given/When scenario and journey role; give every Assertion the minimum all-of Evidence Capabilities that can actually prove its Claim. Separate required success and degradation Checks. Type every external confirmation with impacted Claim refs and target-blocking effect. For selected design targets, keep resource-integrity Checks distinct from root-bound implementation conformance, freeze the validated handoff and target resources, preserve exact condition equality, map every covered handoff Source Item into the conformance Assertion and declare current actual/comparison artifacts. Run read-only `ty-context long-task preflight <workdir>`, repair every handoff, Contract and `decision_required` error in the same Draft, then formally Compile only when ready.
+11. When the first Compile returns `execution_model_checkpoint.required: true`, obey its terminal-turn boundary. Unless an earlier user message explicitly states this task's current-model or switch-and-resume strategy, do no product implementation, file edit, build or test after that result; end the current turn and ask the user to choose `continue_current_model` or switch models and then resume the active Long-Task. Generic “continue”, “resume”, “finish” or “continue the Goal” language does not satisfy the checkpoint. Later revisions return `required: false` and do not repeat it.
 
 Architecture quality uses the existing authority model, not a new gate or field. The visible deliberation proves that architecture work occurred, not that subjective quality is machine-proven. Encode every material falsifiable invariant as a Source-backed technical obligation/global constraint/forbidden shortcut plus owner/path/Binding boundaries and a project-owned executable Check. Functional acceptance cannot substitute when the architecture claim can fail independently. An unverifiable design preference remains task-local, durable Context or `decision_required`; it must not be promoted into false proof.
 
@@ -65,21 +66,28 @@ Architecture quality uses the existing authority model, not a new gate or field.
 
 After Authority Lock and the one-time execution-model checkpoint are satisfied, implement only Outcomes in the derived current Stage frontier, plus prerequisite regression repairs and current Finding repairs, in the current workspace. A later Stage cannot substitute for an unpassed earlier gate. Small implementation plans and repair hypotheses are internal execution state and cannot silently change Product, Technical or Acceptance authority.
 
-Re-evaluate `Context Delta` whenever implementation or repair discovers a durable fact. Controlling Context changes use protected revision; graph-derived, non-explicit `implementation-index` and `archive` are Supporting Context in referenced mode and may auto-revise when only navigation/background changed. Full snapshot mode treats every selected Context file as controlling.
+Re-evaluate `Context Delta` whenever implementation or repair discovers a durable fact. Controlling Context changes always use Authority Revision; they require a user decision only when mapped Claims, targets, proof obligations or another decision boundary changes. Graph-derived, non-explicit `implementation-index` and `archive` are Supporting Context in referenced mode and may auto-revise when only navigation/background changed. Full snapshot mode treats every selected Context file as controlling.
 
 If rolling implementation materially changes scope, ownership, dependency direction, the selected design or a debt disposition, refresh the Architecture Deliberation and express any authority change through marked Source/Context plus protected revision before continuing. This is refinement of the same checkpoint, not a second workflow stage.
 
-Use targeted `verify --outcome/--check` only to drive repair. Progress is repair evidence only and never acceptance authority. Keep precise findings attached to the owning Source item, Claim, Assertion, Check, Binding and owner path. Do not add another model-switch pause or coordinate parallel subagents.
+Use `verify --explain [--outcome/--check]` when execution cost is unclear; it previews declared main and Counterfactual runner invocations without executing or writing Progress. Use targeted `verify --outcome/--check` only to drive repair. Progress is repair evidence only and never acceptance authority. Keep precise findings attached to the owning Source item, Claim, Assertion, Check, Binding and owner path. Do not add another model-switch pause or coordinate parallel subagents.
+
+When the Contract declares a target-runtime Check because a proxy can pass while the target fails independently, run it at the earliest owning Outcome's first runnable boundary. Every required target is proved separately from its root; Browser evidence requires Playwright and Native/Desktop evidence requires the project binary. For material UI, the first runnable vertical slice is inspected through the production shell/navigation entry, not only a deep link or detached route. `progress_stale` is a freshness fact, not an immediate execution instruction: after accumulated relevant changes, refresh the Check before dependent work relies on it or before Final Gate. Coalesce related edits and use the cheapest reliable target Check; do not mandate a full environment rebuild per Outcome or per edit. This is rolling feedback through existing targeted verify, not acceptance, a trigger queue or per-target progress state.
+
+When implementation discovers a blocker or missing Contract paths, first classify the revision. Difficulty or delay alone never reclassifies machine-verifiable scope as external and never removes Source; a real scope, Product, Acceptance or machine/external boundary change must first be explicit marked Source. Keep exact revision identity, old-Authority continuity, compare-and-swap adoption, evidence invalidation and the complete Final Gate for every path:
 
-When the Contract declares a target-runtime Check because a proxy can pass while the target fails independently, run it at the earliest owning Outcome's first runnable boundary. Every required target is proved separately from its root; Browser evidence requires Playwright and Native/Desktop evidence requires the project binary. After accumulated changes to declared `input_paths` or Binding carriers make the result stale, rerun before dependent work grows. Coalesce related edits and use the cheapest reliable target Check; do not mandate a full environment rebuild per Outcome or per edit. This is rolling feedback through existing targeted verify, not acceptance, a trigger queue or per-target progress state.
+1. machine-proven monotonic strengthening auto-adopts;
+2. locked-semantics-preserving Source/Context snapshot refresh, bounded runner/input/environment repair, repo-bound scope expansion, risk strengthening and machine-proven equivalent Counterfactual coverage auto-adopt as mechanically bounded repair;
+3. a scope-only candidate may additionally use `ty-context long-task diagnose-revision <workdir> [--outcome <key>] [--check <key>]` to exercise only existing active Check identities with unchanged runner/verifier authority;
+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 remain preview-only and require the exact user-decision identity; risk downgrade is rejected.
 
-When implementation discovers a blocker or missing Contract paths, first classify the revision. Difficulty or delay alone never reclassifies machine-verifiable scope as external and never removes Source; a real scope, Product, Acceptance or machine/external boundary change must first be explicit marked Source. Proven monotonic evidence strengthening may use ordinary `compile --revise` directly. If every protected reason is only owner/expected-change/allowed-support expansion, continue editing the same `delivery-contract.yaml` and use `ty-context long-task diagnose-revision <workdir> [--outcome <key>] [--check <key>]` to exercise only existing active Check identities with unchanged runner/verifier authority; safe monotonic strengthening may coexist. Candidate diagnostics are transient: they authorize no acceptance and write no pending/approval state, Active Authority, cache, Progress or Receipt. Semantic changes, proof weakening, runner or verifier-content changes, and risk-increase candidates are preview-only and must not run; risk downgrade is rejected. When the candidate is complete, run ordinary `compile --revise` once, present its exact material decision summary to the user, and never approve it yourself. Keep the previous Authority active until exact approval and atomic adoption. Adoption is not delivery completion: discard historical/candidate evidence, run `status` or `resume`, and return to rolling implementation or repair under the revised Authority before Final Gate.
+Candidate diagnostics are transient: they authorize no acceptance and write no pending/user-decision state, Active Authority, cache, Progress or Receipt. Keep related edits in the same `delivery-contract.yaml`; do not compile each intermediate candidate merely to obtain an identity. When the stable candidate is ready, run ordinary `compile --revise` once. If it needs a decision, first present the self-contained `pending_authority_revision.decision_brief`, which explains Authority Revision, separates `user_decision_reasons` from mechanically bounded changes, names material changes and affected Outcomes, and states reject/previous-Authority, adoption, no-completion and Final-Gate effects. If an explicit current-task instruction already covers every listed decision reason exactly, mechanically relay that existing decision through the exact approval command without asking again; generic continue/resume/finish, blanket authorization, recommendation, partial coverage or Agent inference never qualifies. Otherwise ask once for that stable exact identity. The executing Agent never originates its own weakening decision. Adoption is not delivery completion: discard invalidated evidence, run `status` or `resume`, and return to rolling implementation or repair under the revised Authority before Final Gate.
 
 ## Live Final Authority
 
 Complete Context, implementation and project tests, create a clean candidate commit, then run `ty-context long-task final-gate <workdir>`.
 
-Final Gate recompiles Source authority, validates active task/revision/compiled/worktree identity, creates one Git-tree snapshot, reruns every required Global and Outcome Check and rechecks active identity before acceptance. It derives Stage results and target qualification from that run; it does not trust targeted Progress as a Stage pass. A target-runtime Check must exercise its exact target in that current Gate execution; rerunning a reader for a historical or tracked status report is not live target proof. Final Gate, Stop and close never trust historical Progress, Receipt or compiled cache.
+Final Gate recompiles Source authority, validates active task/revision/compiled/worktree identity, creates one Git-tree snapshot, reruns every required Global and Outcome Check and rechecks active identity before acceptance. It derives Stage results and target qualification from that run; it does not trust targeted Progress as a Stage pass. A target-runtime Check must exercise its exact target in that current Gate execution; rerunning a reader for a historical or tracked status report is not live target proof. Design-resource integrity, an isolated route or `visual_render` cannot replace required root-bound `design_conformance`, and unresolved design blockers remain blocking. Final Gate, Stop and close never trust historical Progress, Receipt or compiled cache.
 
 Final Gate is the Long-Task path's sole `Architecture Conformance` carrier. It reruns the declared architecture obligations/constraints/forbidden shortcuts, owner/path/Binding boundaries and project-owned Checks on that same snapshot and blocks scope escape, bypass, duplicate authority, a second source of truth, wrong dependency direction, undeclared boundary change or new/worsened debt represented by those invariants. Do not also run the default Workflow's standalone Contract Conformance closure. Any later candidate or authority change invalidates the Gate and uses the existing freshness path again.
 
@@ -89,4 +97,4 @@ Before invoking platform-native Goal completion, perform one veto-only conforman
 
 ## Handoff
 
-Report implementation, effective risk, Architecture Deliberation/Conformance status, Claim Coverage, Stage frontier/results, declared target profile, exact `target_state`, Live Gate result, acceptance scope, every pending external confirmation, Context status and blockers. Use verifier terms exactly: `progress_passing` means targeted repair evidence, `progress_stale` is not a current pass, `final_workflow_status: null` means unfinished, `authority_revision_adopted` means return to rolling execution, and `machine_accepted_external_pending` must retain its named confirmations. Contract target states are only `implementation_complete`, `target_profile_usable` and `production_release_ready`; terminal failure uses `not_accepted` or `blocked_external`. Never shorten targeted progress to “Outcome complete” or invent per-platform progress/status. State the threat-model limits: the visible checkpoint cannot prove private reasoning or universal future-proofing, undeclared requirements cannot be discovered, installed verifier/Git metadata are trusted, native-Goal/model selection belongs to the host/user, and internal platform delegation is not observed.
+Report implementation, effective risk, Architecture Deliberation/Conformance status, Claim Coverage, Stage frontier/results, declared target profile, exact `target_state`, Live Gate result, acceptance scope, every pending external confirmation, Context status and blockers. Use verifier terms exactly: `progress_passing` means targeted repair evidence, `progress_stale` is a freshness fact rather than a current pass or immediate rerun command, `final_workflow_status: null` means unfinished, `authority_revision_adopted` means return to rolling execution, and `machine_accepted_external_pending` must retain its named confirmations. Contract target states are only `implementation_complete`, `target_profile_usable` and `production_release_ready`; terminal failure uses `not_accepted` or `blocked_external`. Never shorten targeted progress to “Outcome complete” or invent per-platform progress/status. State the threat-model limits: the visible checkpoint cannot prove private reasoning or universal future-proofing, undeclared requirements cannot be discovered, installed verifier/Git metadata are trusted, native-Goal/model selection belongs to the host/user, and internal platform delegation is not observed.

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

@@ -8,43 +8,60 @@ Run `ty-context long-task preflight <workdir>` before first formal Compile. Reso
 
 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`. 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.
+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 revision compares against active authority and follows one of three paths:
+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.
 
-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.
+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 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.
+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 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.
+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. 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`.
+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 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.
+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
 

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

@@ -9,7 +9,7 @@ Read this only while authoring or structurally revising the one `delivery-contra
 - 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.
+- 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.
@@ -32,6 +32,14 @@ For every Outcome declare:
 
 Global non-goals, constraints and forbidden shortcuts remain Global authority and use Global Checks/Assertions when machine proof is required.
 
+## 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.
@@ -80,7 +88,7 @@ A proxy check, static repository shape, tracked status report, prior screenshot,
 
 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;
+- 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`;
@@ -89,17 +97,20 @@ When the selected delivery includes a new/redesigned screen, primary layout/navi
 - 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;
+- 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 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.
+- 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 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.
+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, 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.
+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.

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

@@ -23,7 +23,7 @@ Across all Checks sharing a Raw Execution, one Claim-bearing Observation belongs
 - Every Assertion declares a non-empty all-of `evidence_capabilities` set. `presence` proves static existence only and cannot alone prove a behavioral Claim. Each other capability requires exactly one typed current-execution record bound to the declared Assertion key; missing, duplicate, unknown or undeclared records fail closed.
 - `interaction_trace` names the exact target plus the declared Given keys and ordered action keys. Playwright derives it only from an executed declared AC carrying matching `[given:<key>]` and `[action:<key>]` steps; `[ac:<assertion-key>]` remains the AC binding.
 - `state_delta` requires different before/after hashes and named changed fields. `durable_readback` requires independent write/read sessions with equal state hashes. `cross_surface_consistency` requires at least two distinct surface refs, known target refs and one state hash.
-- `boundary_invocation` and `external_side_effect` require the Check itself to execute on the named observer target. `failure_injection` requires an observed fault and recovery state; `visual_render` binds a declared artifact hash; `target_runtime` binds exact target/root/current session and requires a cold start for a root journey; `input_variation` requires at least two distinct inputs, differing propagated outputs and an observed failure case.
+- `boundary_invocation` and `external_side_effect` require the Check itself to execute on the named observer target. `failure_injection` requires an observed fault and recovery state; `visual_render` binds a declared artifact hash; `design_conformance` binds one compiled selected target, exact required product target, declared condition set and distinct current actual/comparison artifact paths; `target_runtime` binds exact target/root/current session and requires a cold start for a root journey; `input_variation` requires at least two distinct inputs, differing propagated outputs and an observed failure case.
 - Structured runners emit `long-task-check-result-v3` for capability records. V2 payloads remain decodable only for presence-only compatibility; they cannot satisfy a declared non-presence capability. Evidence records contain bounded hashes/ids/refs, not unrestricted raw payloads.
 
 ## Live Target Runtime Evidence
@@ -53,14 +53,17 @@ Standard frozen Playwright verifier content is trusted. Weak-observability Outco
 
 ## Visual UI Evidence
 
-- When external design resources are Source, prove only selected exact-target/constraint conditions that the Contract explicitly adopts. Candidate comparison, a Figma link or an isolated prototype run is authoring/review material and cannot become product acceptance. Resolve each acceptance-affecting resource through a stable locator plus immutable path/version/hash and declared condition coverage before Compile.
+- A selected implementation handoff must already pass `ty-context design-resource preflight`. For each covered row, turn its declared verification methods into project-owned, independently failing observations in the target conformance Check: geometry/pixel/token/content, component state/interaction trace, motion timeline, responsive reflow/input method, accessibility semantics and asset integrity are different obligations. The strict index proves that none was silently omitted; it does not prove that the project verifier implemented or passed them.
+- Keep `design_resource_integrity` and `design_implementation_conformance` distinct. Stable paths/hashes, provider/export success, manifest/registry membership and expected counts prove resource integrity; `visual_render` proves a current artifact exists. Neither proves the production implementation matches a selected target.
+- When external design resources are Source, prove only selected exact-target/constraint conditions that the Contract explicitly adopts. Candidate comparison, a mutable provider link, extraction success, metadata-only output, resource digest or an isolated prototype run is authoring/integrity material and cannot become product acceptance. Resolve each acceptance-affecting fact through a typed locator plus immutable path/hash and declared target/condition applicability before Compile. Include the handoff and every source-profile entry/dependency in `verification_inputs`; project-owned method-specific design-conformance, interaction and target-runtime observations must still fail independently on the current production target.
+- A `design_conformance` record is accepted only for the compiled target/Assertion/current Check target, an equal declared condition-key set and both declared actual/comparison artifacts collected by the current Check. Missing or swapped targets, conditions or artifacts fail closed; the implementation render cannot also be the comparison authority.
 - Use Playwright for every declared `ui_browser` visual AC and bind each independently falsifiable AC to its own `[ac:<assertion-key>]` Test Instance. A broad screenshot or one passing page case does not silently prove separate viewport, theme, state, content-stress, layout or accessibility claims.
 - Make the test environment deterministic enough for its claim: freeze the relevant browser/project, viewport, theme/mode, locale/timezone, font loading, fixtures/data and animation/motion policy in declared verifier inputs or configuration.
 - Any reviewed screenshot baseline that affects pass/fail must exist for the accepting Compile and be included in `verification_inputs`. Generated screenshots, diffs and reports are Artifacts and review material; they are not editable acceptance authority. Creating or replacing a baseline after Authority Lock is verifier-material revision and must never be silently auto-updated to make a failure pass.
 - Confirm that each baseline is a selected `exact-target` for the named surface/viewport/theme/state or implements a named `constraint`; an inspiration reference cannot become a fidelity oracle merely because it is available. The implementation's current screenshot is never its own target.
-- Screenshot comparison proves only the named visual similarity claim. Pair it with explicit DOM/layout/accessibility assertions when the Contract separately claims no overflow, action visibility, focus behavior, target size, semantic state, reduced motion or other observable behavior.
+- Screenshot comparison proves only the named visual similarity claim. Pair it with explicit DOM/layout/accessibility/motion/responsive/input assertions whenever the handoff or Contract separately declares no overflow, action visibility, focus behavior, target size, semantic state, reduced motion or other observable behavior. One generic `design_conformance` record cannot erase distinct Source Claims or verification methods; every handoff method binds a separate Assertion and the trusted Check must fail if any asserted method fails.
 - Keep evidence aligned with stable surface/control/target keys. Visual similarity, interaction/navigation, validation/recovery, permission behavior, accessibility and target-runtime conformance are independently failing claims and need their own Assertions/capabilities when declared; one broad screenshot or UI pass cannot prove all Control fields.
-- Run checks against production components or real product routes. A detached kit/mock harness is acceptable only when the Contract explicitly makes that artifact the product surface; otherwise it cannot substitute for the production carrier.
+- Run checks against production components or real product routes. For each bound Control, the named root-entry journey must begin at the required product target root, execute the declared entry action and prove its navigation result—or interaction, trigger or location fallback—with `interaction_trace` plus `target_runtime`. A detached kit/mock/deep-link harness is acceptable only when the Contract explicitly makes that artifact the product surface; otherwise it cannot substitute for the production carrier or root journey.
 - Keep subjective visual quality and approval external. A new visual direction or baseline that needs human judgment remains an explicit external confirmation even when all machine checks pass.
 - `ui_browser` proves browser UI only. When a native/mobile/desktop UI can fail independently, browser output is proxy evidence; require a project-owned live target-runtime Check that truthfully fits an existing proof surface or keep the device/simulator review external.
 

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

@@ -1,19 +1,19 @@
-# Integrated Source Authoring Reference
+# Source-Bound Draft Input Reference
 
-Read this when raw, mixed, attachment-heavy or incomplete inputs need to become self-contained delivery Source before Contract mapping. This work occurs inside the same `long-task-workflow` Goal and feeds the same Contract Draft; it is not a standalone Source Plan stage or second lifecycle.
+Read this alongside `contract-authoring.md` when raw, mixed, attachment-heavy or incomplete inputs need Source-quality repair while the same Contract Draft is being mapped. Inputs enter the Draft immediately; this reference is neither an earlier Source-authoring phase nor a standalone Source Plan stage or second lifecycle.
 
 ## Objective and boundary
 
-Preserve every material user, product, technical, visual and acceptance constraint from the initial/revised proposal and supplied resources. Add only traceable necessary derivations, defensible delegated choices and evidence-backed repository facts. Make the real Source understandable without the original conversation.
+Preserve every material user, product, technical, visual and acceptance constraint from the initial/revised proposal and supplied resources. Add only traceable necessary derivations, defensible delegated choices and evidence-backed repository facts. Make the real Source understandable without the original conversation before Preflight/Compile, while allowing Draft decomposition and repository binding to proceed incrementally.
 
-Do not create a Source Plan schema, CLI, Preflight, Compile, Receipt, cache, authority or state. Do not bind a choice only in Contract YAML. Do not let current implementation silently redefine intent. A pre-existing Source Plan is simply one possible input.
+Do not create a Source Plan schema, CLI, Preflight, Compile, Receipt, cache, authority, state or internal Source-authoring stage. Contract YAML cannot become the sole owner of a choice or missing semantic. Do not let current implementation silently redefine intent. A pre-existing Source Plan is simply one possible input.
 
 ## Input inventory
 
 1. Assign every proposal, selected design resource, screenshot, document, diagram, table and other attachment a stable input ID.
 2. Inspect all material pages/frames/screens/tables/visible states; never silently sample a multi-part artifact.
 3. Classify each input as user instruction, product requirement, technical constraint, existing proposal, selected target, repository/Context evidence, constraint, inspiration or background.
-4. For visual resources, preserve selection basis, classification (`exact-target`, `constraint` or `inspiration`), stable resource/surface/control/state/target keys, declared platform/viewport/mode/state/content coverage, provider/project/run/entry provenance and immutable digest/snapshot. Unselected candidates authorize no fidelity.
+4. For visual resources, preserve selection basis, classification (`exact-target`, `constraint` or `inspiration`), stable resource/surface/control/state/target keys, declared platform/viewport/mode/state/content applicability, source profile/canonical entry/dependency set, provider/project/run/entry provenance and immutable digest/snapshot, plus typed locators. A mutable link, metadata-only response, partial file set or prose locator is incomplete. Unselected candidates authorize no fidelity.
 5. Record incorporated meaning and every unreadable, conflicting or intentionally unused part. Higher authority and user-stated precedence win; unresolved conflicts remain decisions.
 
 ## Preference and research gate
@@ -24,9 +24,9 @@ Infer preferences only from user words, Source, Context or controlling constrain
 
 Use current primary/authoritative evidence for changing external facts. Record source, scope and retrieval date. Preference clarification authorizes plan meaning, not payment, contracting, deployment/publication, destructive production mutation, permission grants, sensitive-data transmission or required legal/security/human approval; those remain typed external confirmations.
 
-## Authoring modes
+## Working strategies, not phases
 
-Infer rather than ask the user to choose:
+Choose locally as needed while revising the same Draft; do not expose these as lifecycle stages or ask the user to choose:
 
 - **refinement:** preserve and complete a substantially developed proposal;
 - **synthesis:** build coherent Source from a goal plus mixed inputs;
@@ -74,15 +74,17 @@ For each in-scope surface, record purpose, entry/exit/navigation, regions/overla
 
 Do not invent controls for a non-interface delivery. A coarse frame or configured design system does not supply unshown states. Selected design resources and product/technical Source remain parallel: visuals cannot invent business/data/permission/algorithmic rules.
 
+For every selected exact/constraint target, preserve the declared platform/viewport/mode/state/content conditions and identify which surface and Control keys it governs. Separately record any design-resource acceptance blocker supplied by the Source. File identity, hashes, provider/export success, registry membership and resource counts are integrity facts only; they do not state that a production owner, real-user journey or rendered interaction conforms.
+
 ## Acceptance and risk
 
 Each AC has exactly one Given/When/Then scenario, names the REQ/CTRL/OBL/NCOMP meaning it accepts and introduces no undeclared product semantics. Keep representative/sample/framework checks distinct from full-population claims and partial delivery distinct from completion.
 
 Use the Runtime's exact risk Fact names when marking risk. Data migration is `data_migration`; a weakly observable critical path is separate `critical_user_path` and `weak_observability` facts; preserve `multi_repository_change` in Source so Contract compilation can reject unsupported delivery honestly.
 
-## Completeness audit
+## Preflight/Compile convergence audit
 
-Before Contract mapping confirm:
+Before Preflight/Compile confirm:
 
 1. Every material original statement and qualifier is preserved.
 2. Every supplied input is incorporated or has an explicit unreadable/unused/conflict disposition.
@@ -93,6 +95,7 @@ Before Contract mapping confirm:
 7. Non-goals, forbidden shortcuts, risks and recovery are concrete.
 8. No unsupported number, threshold, metric or external claim appears.
 9. Selected design resources retain stable identity and exact declared coverage; candidates remain non-authoritative.
-10. The Source is self-contained enough for Contract authoring and names every still-required external artifact.
+10. Every material UI surface/control can be mapped to a production target/owner, real-user entry journey and acceptance route, while every declared design blocker has an explicit machine or target-blocking external-confirmation disposition. Removing one from scope requires an explicit Source revision; Contract prose cannot waive it.
+11. The Source is self-contained enough to own every mapped Draft semantic and names every still-required external artifact.
 
-Then add non-rendering `ty-source-item:start/end` markers to the real Markdown Source without rewriting direct text, and proceed to `contract-authoring.md`. The markers and Contract mapping are part of this same Long-Task authoring loop.
+Complete non-rendering `ty-source-item:start/end` markers in the real Markdown Source without rewriting direct text, and finish the corresponding Contract mapping in the same loop. Neither markers nor this audit delay opening the Draft; all are fail-closed convergence requirements before Preflight/Compile.

package/assets/skills/source-plan-authoring/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: source-plan-authoring
-description: Retired compatibility pointer for users who explicitly invoke /source-plan-authoring or request the former standalone Source Plan stage. Direct long deliveries to /long-task-workflow, whose integrated Source authoring now consumes raw or revised proposals, selected design resources and mixed attachments before Contract Draft authoring. Do not create a legacy standalone Source Plan workflow, gate, schema, state or second plan.
+description: Retired compatibility pointer for users who explicitly invoke /source-plan-authoring or request the former standalone Source Plan stage. Direct long deliveries to /long-task-workflow, where raw or revised proposals, selected design resources and mixed attachments enter one Source-bound Contract Draft loop immediately. Do not create a legacy standalone Source Plan or internal Source-authoring stage, gate, schema, state or second plan.
 ---
 
 # Retired: Source Plan Authoring
 
 `/source-plan-authoring` no longer defines a separate handoff between the initial proposal and Long-Task execution.
 
-For an explicit long delivery, invoke `/long-task-workflow` with the initial/revised proposal, selected immutable design resources and other attachments. It now owns input inventory, Source-quality synthesis/refinement, stable semantic keys, control-level UI meaning, acceptance scenarios, research/delegation traceability, real Source marking, repository binding and the same `delivery-contract.yaml` Draft in one Goal.
+For an explicit long delivery, invoke `/long-task-workflow` with the initial/revised proposal, selected immutable design resources and other attachments. They enter the same `delivery-contract.yaml` Draft immediately; input inventory, Source-quality synthesis/refinement, stable semantic keys, control-level UI meaning, acceptance scenarios, research/delegation traceability, real Source marking, repository binding and Contract mapping converge in one Goal before Preflight/Compile.
 
 For non-long work, give the proposal and selected resources directly to the current native Goal under the default Workflow Contract. If the user only wants an initial product or technical proposal, use the applicable proposal-authoring capability rather than recreating this retired intermediary.
 

package/dist/commands/design-resource.d.ts

@@ -0,0 +1 @@
+export declare function designResource(args: string[]): Promise<void>;