project-tiny-context-harness 0.8.11 → 0.8.13

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

@@ -1,108 +1,73 @@
----
+---
 name: long-task-workflow
 description: Author, preflight, execute, resume, verify, or close one complete Single-Goal Delivery Contract in the currently selected host execution Goal and workspace. Use only when explicitly invoked or a valid common-dir active authority binding exists.
----
-
-# Single-Goal Long-Task Workflow
-
-## Boundaries
-
-Use one currently selected host execution Goal, one repository, one selected verification workspace, one complete Contract and one Final Gate. This workflow never creates or manages a scheduler, model worker, agent runtime, App Server, branch/worktree fan-out, merge, push, PR, deployment, Campaign/SFC/Packet/Wave chain, matrix, verdict or second Contract plan. The current Goal may optionally use one or multiple platform-native agents/subagents or user-authorized Git parallelism as implementation means. Harness never allocates, schedules, retries or recovers them; their reports are not Progress or proof, and every result must converge into the selected verification workspace before verification counts. Never activate from task size alone.
-
-That Goal is selected and owned by the host/user. Harness does not create, persist or reconnect a Goal identifier. Compaction may continue inside it; a later physical Goal/session restores semantic workflow state through `resume` rather than reconnecting a prior Turn.
-
-The host and user also own model selection. The workflow has exactly one user-choice checkpoint after the first Authority Lock and before implementation; Harness neither switches the model nor persists model-routing/checkpoint state. No checkpoint file, acknowledgement state, model route, model-tier scheduler, automatic model switch, `authority_revision_in_progress` state or native-Goal completion state is created. Outside that boundary, do not pause a healthy Goal solely to change or downgrade the model. Do not create a separate approval checkpoint for a defensible recommended plan choice. A targeted pre-Authority clarification is still required when a missing user preference could materially change research or selection; genuine Source conflicts or choices the user explicitly reserves may likewise require a decision before Authority Lock. Capability-related drift is handled by targeted repair plus the Final Gate. The current Goal may choose platform-native internal delegation, but Harness owns no subagent dispatch/retry/recovery state, delegated reports are not Progress or proof, and all outputs must converge into the selected verification workspace before verification can count.
-
-`long-task-delivery-v2` is the only active Contract schema. `delivery-contract.yaml` is the root authoring file. New authoring uses inline Outcomes; existing `outcome_files` are physical compatibility only. `delivery-set` is retired and non-executing.
-
-## Controlling Objective
-
-Prevent false completion inside declared authority. Given complete and accurate Source at the declared observable granularity, a meaning-preserving Source-to-Contract projection, complete applicability expansion and a sound named verifier/runner trust boundary, `AcceptedDeliveryTerminal` must imply that no declared observable drift remains. Implementation may drift, fail or require rework, but every declared non-Result requirement, exact applicability cell and AC must remain traceable and every unsatisfied, unverifiable, insufficiently evidenced, stale or externally pending item must block or explicitly qualify complete delivery. In particular, unclassified Source, an omitted architecture obligation, Control field/relation, population-universe member, wrong target/condition/input/state/journey, proxy target, presence text, degradation path, fixed input, self-reported boundary effect, weak semantic oracle or internal entrypoint must never substitute for declared behavior. Findings should localize repair through Source Item, Stage, Outcome, Claim, applicability, 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: formal Web/App authoring must derive the complete scoped Expected Fact Universe before generation; acquire a canonical entry and exact dependency closure; and freeze an Inspector manifest proving `Expected Fact Universe = Canonical Resource Facts = Handoff Indexed Facts`. The atomic identity is `subject × target × condition × variation × property`, including component instances/Anatomy Parts/relations, all applicable condition and variation axes, exact standard/custom properties, explicit N/A/exclusions, design-system lineage, dynamic populations and assets. Product Control and eight-dimension roll-ups are not the Fact ceiling; sampling, truncation, broad labels and default-page inference cannot close it. The validated `design-resource-handoff-v1` remains the residual scope/applicability/semantic adapter rather than a copy of CSS values: canonical resources own exact values, while immutable located digests, Fact Cells, Fact × required-method proof obligations, comparator/tolerance/mask, Oracle/environment and sensitivity policy project downstream. Preserve each Fact through Context-reachable targets, Source/Control/Claim authority, one independent Assertion per method, exact per-condition `fact_expectations`, and one current-snapshot `fact_results` row with attributable actual observation/environment/comparison/verdict. An exact target requires full-target layout and pixel Facts per condition. Deliberately partial input remains a constraint or blocking unresolved; incomplete acquisition/Census, missing or mismatched Facts/proofs, unsupported evidence, blockers or stale identities remain blocking. Neither provider success, file hashes nor handoff preflight proves production conformance.
-
-For non-UI meaning, complete and accurate Source defaults to the finest independently decidable semantic Fact granularity expressed, logically entailed, explicitly delegated or preserved by authoritative repository evidence. This covers product/business semantics and technical/backend/architecture semantics: goals and scope; actors, roles, tenants and entitlements; business rules and calculations; entities, fields and relations; commands, queries, workflows, state machines and time; validation, outputs/errors, APIs/protocols/events/jobs; persistence, transactions, consistency, concurrency and idempotency; faults, retries, degradation, recovery and backup; configuration, compatibility, migration and rollout; performance, capacity, reliability and cost; security, privacy, safety and compliance; observability, deployment and operations; integrations, localization, commercial rules, hardware, AI/ML and custom domains. A paragraph, Requirement, Product Control, broad state label or current implementation is never the semantic ceiling. Inventory every material input and give every applicable subject/relation/population, condition value/combination and atomic property a stable identity, typed expected predicate, owner, Source locator/digest, provenance and sensitivity. The standard catalog is a floor; discovered domain-specific families, properties, axes and proof methods extend it.
-
-One Source-embedded `semantic-fact-manifest-v1` is the task-local canonical index; durable meaning remains in its existing owning Context and exact values remain Source, never copied into Contract. It freezes a complete Inspector Census, explicit N/A/exclusion basis, non-sampling/non-truncation counts/digests, Fact Cells/Facts, dynamic populations, every Fact × required-method obligation, comparator/parameters/tolerance/mask, Oracle/environment and blockers. Require exact conservation: `Expected Semantic Facts = Source Indexed Facts = Contract Indexed Facts`, and `Fact × required-method obligations = Contract proof bindings = current Final-Gate semantic_fact results`. Every current result carries attributable actual observation/environment, frozen comparison authority, Oracle and pass/fail verdict; proof reaches the furthest independently failing boundary. Aggregate strings, representative/pairwise samples, default paths, implementation-generated expectations, ungrounded N/A, proxy-only/self-reported results and one broad pass Boolean cannot close atomic rows. Any material Source hidden as supporting-only, or any missing, extra, duplicate, unresolved, unreadable, unmapped, unimplemented, unexecuted, stale, failed, authority-drifted, reused or indistinguishable identity blocks Authority Lock or Final Gate. Genuine external authority stays a typed External Confirmation. This adds no second plan, value authority, Gate, state or implementation-order rule.
-
-Shared Engineering Quality stays thin around those semantic authorities. Before implementation, the universal Architecture Deliberation also routes triggered quality attributes or records a concrete preservation basis; during implementation, owner/boundary/failure/resource guardrails constrain correctness without prescribing order or feedback cadence; Final Gate is the sole Long-Task Engineering Quality Conformance carrier. Every material independently falsifiable invariant uses existing Source-backed technical obligations/global constraints/forbidden shortcuts, owner/path/Bindings, project-owned Checks and an independent Assertion when functional behavior could pass separately. A performance claim requires a workload, metric, baseline or budget, environment, comparator/tolerance and real benchmark/probe. Final Gate proves exactly that declared project-check-bound set—not overall code quality. Exact expected semantics remain in Semantic Facts or selected design, and no quality Boolean, matrix, Source aspect, Claim/risk kind, Contract field, second Gate, state or Receipt is added.
-
-Only fresh evidence from the complete current final snapshot may create machine acceptance. Exactly fresh `machine_accepted` with no pending External Confirmation is `AcceptedDeliveryTerminal` and may support the full declared-observable no-drift conclusion. Otherwise report the task as unfinished or qualified. `machine_accepted_external_pending` means machine-verifiable authority passed while named external confirmation remains; it proves only the declared machine scope and is not full delivery completion. Machine acceptance has no direct native-Goal effect. Never substitute prose, progress, historical tests, Receipts, one exit code or Agent judgment for the Final Gate.
-
-Anti-Degradation Assurance requires current-implementation Context to match the indexed code/runtime and protects the controlling purpose, enabling key logic, two jointly necessary implementation responsibilities, theorem boundary and adjacent `F = Implementation Freedom Boundary` from implicit weakening. `F` is an efficiency/anti-process-bloat invariant, not a third responsibility or no-drift theorem premise: within declared Source/Contract, architecture, security, forbidden-shortcut, irreversible-effect and external-action boundaries, the current Goal owns implementation order, methods, local feedback cadence and optional one-agent or multi-agent/subagent execution. Harness must not add a development phase/method permission Gate, per-edit verification mandate, agent allocator/scheduler, delegation proof or persistent delegation state. Replacing any protected invariant requires an explicit project-owner design-purpose decision and replacement proof; a new development-stage constraint must additionally identify a distinct path that final proof or a lighter project-owned check cannot cover and have positive net ROI. Agent inference, coordinated edits or cost alone do not authorize it. Mechanism changes use a two-stage hard gate. First prove `Coverage_new ⊇ Coverage_old`, `FalseNegative_new ⊆ FalseNegative_old`, and that Authority, fail-closed behavior and complete-current-final-snapshot proof cannot be bypassed. If non-degradation cannot be proved, preserve the current formal acceptance path. Only after that gate passes may positive net ROI compare incremental anti-degradation or purpose benefit with every incremental Authoring, Runtime, State, Recovery, maintenance, test, process, introduction and migration cost. No cost reduction compensates for weaker drift interception; positive net ROI permits consideration but never overrides the first gate. This creates no second Authority, Gate or state.
-
-## Progressive Reference Loading
-
-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 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).
-
-Do not copy reference detail into another plan or state file. The same `delivery-contract.yaml`, active authority and current workspace remain the only lifecycle surfaces.
-
-## Contract Draft And Outcome Decomposition
-
-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 project an acceptance/verification-ready working set, bind target verification, localize failures, resume findings/next actions and stale local results precisely; never use them to restrict which in-scope implementation edit may happen next.
-
-`depends_on` means acceptance and intermediate-proof readiness, not implementation permission. The gate Outcome transitively depends on the rest of its Stage, later Stage Outcomes depend on prerequisite gate Outcomes, and every multi-Outcome gate proves cross-surface consistency. The current Goal derives a temporary advisory Rolling Frontier from Stage and Outcome status, but may implement, inspect or repair any in-scope Outcome in the order current code reality favors. Do not persist a Stage Receipt, scheduler, Worker queue, mandatory implementation DAG, model route or process tree. Never split for response/YAML/file length, implementation layer, module/file count, Agent capacity, Worker assignment or desired parallelism.
-
-> Outcome decomposes execution and diagnosis, not completion authority.
-
-## 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, boundaries and risk-triggered engineering-quality attributes needed for the shared deliberation before deciding `Context Delta`.
-   - 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>`. Require its canonical Fact manifest, frozen Inspector Census, complete standard/custom axes and property catalog, exact `subject × target × condition × variation × property` Fact Cells, all property-required proofs and exact manifest↔handoff equality; incomplete resource/dependency/Census closure, aggregate state labels, sampling/truncation, ambiguous condition profiles, unsupported evidence, unresolvable located digests, unresolved lineage/conflicts/blockers, missing exact-target layout/pixel Facts or stale identities are 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/condition/variation/property 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, complete Fact/proof set, canonical per-Fact expectations, 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>`, directly load the installed package-managed `long-task-workflow` Skill and read the lifecycle reference. This recovery path does not depend on implicit invocation.
-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. For non-UI scope, expand the exact semantic universe before implementation: classify every material input; disposition every standard and discovered custom family; enumerate stable subjects, relations, populations, axes, atomic values/combinations and properties; and derive every Fact and required proof obligation without sampling or aggregation.
-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. Every delivery declares at least one `technical_obligation` Source Item with `aspect=architecture` and maps it to an independently provable architecture obligation. Embed exactly one schema-valid `semantic-fact-manifest-v1` across declared Source and point root `semantic_fact_manifest` to its immutable identity; every Outcome projects exactly its Facts and proof obligations through `semantic_fact_bindings`. Ordinary Material Source Items must be `non_ui_material` and contribute Fact lineage unless a validated design handoff independently owns them as `ui_design`; supporting/excluded inputs require exact basis and cannot hide delivery meaning. `ty-source-background:start/end` is restricted to text-free Markdown anchors/horizontal rules (`reason=markdown-structure`) or fixed-field `ty-source-provenance` comments (`reason=provenance`); text-bearing headings, free-form provenance and arbitrary explanatory prose are material or unclassified, never background. Leave the strict formal blocks to their parsers. Every other non-empty line is unclassified and blocking. Never label requirement, acceptance, technical, risk or decision meaning as background. Newly delegated meaning must first be written into real Material 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, project-owned Checks and each triggered quality attribute or concrete preservation basis. Correctness/invariants and maintainability/changeability always receive at least preservation; reliability/resource lifecycle, concurrency/consistency, performance/capacity/cost, security/privacy/safety, compatibility/migration/rollout and operability/observability/testability activate only when material. 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, design, quality-applicability or debt-disposition change before implementation stales and refreshes the deliberation.
-10. Close every real Control's 22 canonical fields through `field_coverage` and its Outcome's cross-Control meaning through `control_relation_closure`; use `specified`, explicit `not_applicable` or blocking `unresolved`, and give the closure exact applicability refs even when no Controls apply. Independently close the semantic manifest: exact Source/context input inventory and digests; all standard/custom family, unit, relation, population, axis/value/combination, property, Fact Cell, Fact, proof, Oracle, environment and blocker Census identities; complete generation counts/digests; and exact Source→Fact→Claim/applicability→proof binding equality. Each machine proof maps to one single-Fact Assertion and typed `semantic_fact` capability; each external proof maps to an impact-complete External Confirmation. Declare only actual applicability profiles, each with an atomic, duplicate-free dimension assignment plus exact target, journey, Given condition/input/state refs and ordered When refs. Every Claim lists all applicable profiles; every Claim-bearing Assertion proves one Claim in one matching profile and all required proof surfaces. Declare each execution target's runtime capabilities and require the production family, cold-start and production-root capabilities where applicable. Give every Assertion the minimum all-of Evidence Capabilities that can actually prove its Claim. Every behavioral Claim-bearing Assertion also needs a same-Check claim-local `replace_json_value` or `replace_text` wrong-semantic witness and a claimless target-runtime liveness Assertion that remains passing; whole-file replacement is compatibility-only and cannot prove semantic binding. Population declares a universe Binding whose carriers are Check inputs and proves exact universe = eligible = observed plus valid exclusions. 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 separate attributable Assertions, bind each verification method to its own `design_method` evidence with exact per-condition `fact_refs`, distinct record and primary-observation paths plus a unique current primary digest for every condition, require the cell union to equal the complete target fact set, and declare current actual/comparison artifacts. Preserve every blocker's required target capabilities; use a machine Claim only on the exact capability-qualified target, otherwise keep a target-blocking External Confirmation. Playwright must attach both declared cell artifacts in every project instance. Use `context_snapshot_mode: full`. Run read-only `ty-context long-task preflight <workdir>`, repair every semantic manifest, 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.
-
-Engineering quality uses the existing authority model, not a new stage, Gate or field. The visible deliberation makes the checkpoint reviewable but does not machine-prove subjective quality. Encode every material falsifiable architecture or quality invariant as a Source-backed technical obligation/global constraint/forbidden shortcut plus owner/path/Binding boundaries, a project-owned executable Check and a separate Assertion when functional acceptance could pass independently. Never substitute a broad quality Boolean, functional pass or prose review. An unverifiable preference remains task-local, durable Context or `decision_required`; it must not be promoted into false proof.
-
-## Rolling Execution
-
-After Authority Lock and the one-time execution-model checkpoint are satisfied, the current Goal chooses implementation order, local planning, tools, repair hypotheses and whether one or multiple platform-native agents/subagents are useful. It may work across Outcome or Stage boundaries when that is the most efficient implementation path. Multiple-agent execution is optional, never a Harness allocation rule: agent reports are non-authoritative and Harness stores no delegation state. The derived Frontier is only an acceptance/verification and diagnosis projection: work in a later Stage cannot make an unpassed earlier gate accepted, and no implementation choice may silently change Product, Technical or Acceptance authority. All proof-bearing changes converge into the selected verification workspace.
-
-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, quality-attribute applicability 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 `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` for optional feedback and repair when its expected localization value exceeds its cost. 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 turn delegation into a Harness scheduler, state or proof source.
-
-When the Contract declares a target-runtime Check because a proxy can pass while the target fails independently, bind it to the earliest owning Outcome and exact target even if implementation happens in another order. Every required target is proved separately from its root; Browser evidence requires Playwright and Native/Desktop evidence requires the project binary. For material UI, a useful early feedback run inspects a runnable vertical slice through the production shell/navigation entry, not only a deep link or detached route. The first useful runnable boundary and later coalesced changes are recommended, not mandatory, targeted-feedback points. `progress_stale` is a freshness fact: refresh the Check only before an intermediate decision relies on that Progress. Continuing implementation or entering Final Gate needs no targeted refresh because Final Gate ignores Progress and reruns all Checks. Use the cheapest reliable target Check and do not mandate a full environment rebuild per Outcome or per edit. This is optional rolling feedback, not acceptance, an implementation gate, 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:
-
-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.
-
-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, captures semantic and raw Contract protected-input identity, validates active task/revision/compiled/worktree identity, creates one Git-tree snapshot and reruns every required Global and Outcome Check. It requires exactly one current typed semantic result for every and only every compiled Fact × machine-method obligation, preserving actual observation/environment, frozen expected/comparison/tolerance/mask/Oracle authority and passing verdict; external obligations remain named confirmations. It then recompiles again and requires unchanged Contract/fragments, Source semantic manifest, Controlling Context, verifier, runner and verification/workdir inputs, plus unchanged workspace/tree and Active Authority, 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 semantic or 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 `Engineering Quality Conformance` and `Architecture Conformance` carrier. It reruns the declared architecture/quality obligations, constraints and forbidden shortcuts, owner/path/Binding boundaries, independent Assertions and project-owned Checks on that same snapshot. It blocks the represented scope escape, bypass, duplicate authority, second source of truth, wrong dependency direction, undeclared boundary/lifecycle change, silent failure, unsupported performance claim or new/worsened debt. It proves only those declared falsifiable invariants, never overall code quality. Do not also run the default Workflow's Contract Conformance closure. Any later candidate or authority change invalidates the Gate and uses the existing freshness path again.
-
-Machine acceptance covers only declared machine authority. Preserve every pending external confirmation through `final-gate`, `status`, `resume`, `stop-check`, the package-owned Stop Hook and `close`; accepted output identifies `acceptance_scope: declared_machine_authority` and `native_goal_effect: none`, while `closed_scope: machine_authority` means only Authority cleanup. Do not invent external-confirmation or native-Goal tracking state.
-
-Before invoking platform-native Goal completion, perform one veto-only conformance review: compare the current Goal and user instructions with accepted marked Source, and check for pending revisions, unresolved blockers or omitted requirements. Any mismatch keeps the Goal active and returns to Source/Contract repair. A clean review does not add acceptance proof and never lets Agent judgment replace Final Gate.
-
-## Handoff
-
-Report implementation, effective risk, Architecture Deliberation and Engineering Quality/Architecture 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 and never be summarized as `AcceptedDeliveryTerminal` or full no-drift delivery. 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 theorem boundary honestly: undeclared or inaccurate Source cannot be discovered mechanically; the named project oracle must be semantically sound; the supported direct-literal verifier dependency graph is frozen while other declared verification inputs, indirect runtime access, installed package/runtime behavior, Harness verifier and Git metadata form the trusted computing boundary; Final Gate proves only its declared project-check-bound quality set; the visible checkpoint cannot prove private reasoning or universal future-proofing; native-Goal/model selection belongs to the host/user; and internal platform delegation is not observed.
+---
+
+# Single-Goal Long-Task Workflow
+
+## Boundaries
+
+Use one currently selected host execution Goal, one repository, one selected verification workspace, one complete Contract and one Final Gate. This workflow never creates, invokes or manages a scheduler, agent runtime, App Server, branch/worktree fan-out, merge, push, PR, deployment, legacy orchestration chain, matrix, verdict or second Contract plan. The parent Goal owns Source, Contract, Authority, architecture, Context writeback, integration, current-candidate checks, formal verification, Final Gate, close and completion. Harness never allocates, schedules, retries or recovers delegated workers; their reports are not Progress, Evidence or proof, and every result must converge into the selected verification workspace before verification counts. Never activate from task size alone.
+
+That Goal is host/user-selected; Harness does not create, persist or reconnect a Goal identifier. Compaction may continue inside it; a later physical Goal/session restores semantic state through `resume`, not a prior Turn. With a valid binding, run `ty-context long-task resume <workdir>`, then directly load the installed `long-task-workflow` Skill; recovery needs no implicit invocation.
+
+The host/user owns model selection. Exactly one unconditional terminal-turn checkpoint follows the first Authority Lock before implementation. Harness neither switches nor verifies the model, persists checkpoint/acknowledgement/route state, nor creates a model scheduler, automatic switch or native-Goal completion state. Do not otherwise pause a healthy Goal solely to change models.
+
+A Codex-root `long-task` install may expose optional fixed package-owned `long_task_implementation` with child multi-agent disabled. It is static, stateless, non-Authority and post-checkpoint—not a checkpoint option, model route or runtime. Install proves no discovery or selection. If unavailable/invalid/colliding or not exactly selectable, the parent implements; never substitute a generic child or add dynamic tiers, retry or scheduling.
+
+`long-task-delivery-v2` is the only active Contract schema. `delivery-contract.yaml` is the one root authoring file. New authoring uses inline Outcomes; existing `outcome_files` are physical compatibility only. Legacy split-delivery commands are non-executing.
+
+## Controlling Objective
+
+Prevent false completion inside declared authority. Given complete and accurate Source, a meaning-preserving Contract projection, complete applicability and the admitted-observer boundary, `AcceptedDeliveryTerminal` implies no declared machine-observable drift remains. Machine completion requires package-admitted Actual and Harness-owned comparison; unsupported proof remains blocking External Confirmation. Implementation may drift or require rework, but every declared requirement, Fact, proof obligation and independently falsifiable AC stays traceable, and every unproved item blocks or qualifies completion.
+
+Complete Source is not a prose or current-code ceiling. Material non-UI meaning uses the finest independently decidable standard and custom semantic Facts plus every required proof method. For selected design resources, Agent implementation, acceptance and testing fully conform to every material Fact in declared scope and conditions; formal input therefore uses complete canonical acquisition, Census, atomic Fact/proof closure and exact production-target evidence. Deliberately partial design input remains an explicitly scoped constraint or blocking unresolved input; incomplete implementation-source acquisition is blocking, and an exact target requires layout and pixel Facts for every declared condition. `UI symbolic V2 is explicit opt-in; V1 remains the default.` Non-UI symbolic admission remains out of scope; machine-observer and verifier/runner trust-boundary closure is mandatory rather than deferred Provider/P0 work. Read the Source, Contract and Evidence references for the exact V1/V2 authoring and proof rules.
+
+Only fresh evidence from the complete current final snapshot may create machine acceptance. Exactly fresh `machine_accepted` with no pending External Confirmation is `AcceptedDeliveryTerminal`; `machine_accepted_external_pending` proves only declared machine scope. Progress is repair evidence only and never acceptance authority. Final Gate is the sole Long-Task Engineering Quality Conformance and Architecture Conformance carrier, and it proves only the declared, falsifiable, project-check-bound set—not overall code quality. This adds no quality Boolean, matrix, Source aspect, Claim/risk kind, Contract field, second Gate, state or Receipt, and no separate default Contract Conformance closure runs.
+
+Anti-Degradation Assurance preserves coverage, false-negative resistance, fail-closed Authority and final-snapshot proof before cost. Purpose/invariant replacement requires project-owner design-purpose decision and replacement proof. `F = Implementation Freedom Boundary` keeps order, methods and feedback Goal-owned within Source/Contract, architecture, safety, forbidden shortcuts and external actions. After the checkpoint, one ephemeral Delegation Suitability judgment may use one or more `long_task_implementation` instances only when the host explicitly selects that exact custom agent and independent benefit exceeds coordination cost. Generic/built-in/null/unknown roles, task names, prompt imitation and model-only selection never qualify. If unavailable or an exposed spawned type differs, never rely on/retry a generic child; the parent executes or independently redoes the packet. Prefer read-heavy exploration/entrypoint location, independent diagnosis and log/test analysis, disjoint-path implementation/targeted verification and bounded repetitive work. Parallel writes require disjoint owner/path/source-of-truth scope; shared Contract/Context/configuration and coupled work stays in the parent. Add no development phase/method Gate, fixed count/Outcome mapping, agent allocator/scheduler, retry, queue, DAG, registry, delegation proof or persistent delegation state.
+
+Each worker receives only its bounded packet. It may inspect named Source/Contract/Context and implement/check locally, but never author/revise Source, Contract, Authority or Context; create Progress/Evidence/Receipt/Final Gate; run lifecycle commands; choose models; spawn/retry/schedule; create branches/worktrees; or claim acceptance/completion. Active `PreToolUse` denies non-exact creation; exact `SubagentStart` reinforces it without proving trust or acceptance. The parent reviews and integrates every report (advisory only), resolves overlaps, writes Context and runs current-candidate/formal verification.
+
+## Progressive Reference Loading
+
+Read the reference for the current activity completely. These four one-level references are detailed guidance, not new artifacts, stages or authority:
+
+- For raw, mixed, attachment-heavy, incomplete or conversation-only inputs, read [`references/source-authoring.md`](references/source-authoring.md) alongside Contract authoring. It owns Source inventory, synthesis/refinement, provenance, preference/research decisions, complete semantic input expansion, selected-resource intake and marker convergence inside the same Draft loop.
+- Before creating or structurally revising Source markers, Outcomes, requirements, Controls, obligations, applicability, architecture boundaries, paths, Bindings, Assertions or risk, read [`references/contract-authoring.md`](references/contract-authoring.md). It owns the exact Contract projection and structural closure rules, including selected-design V1/V2 authoring.
+- Before creating or repairing Checks, runners, Observations, proof surfaces, Counterfactuals, Population/environment probes or selected-design evidence, read [`references/evidence-design.md`](references/evidence-design.md). It owns exact execution evidence, sensitivity and Oracle boundaries.
+- Before Preflight, Compile, the one-time model checkpoint, protected revision, resume, targeted verify, Final Gate, Stop, close or abandon, read [`references/authority-lifecycle.md`](references/authority-lifecycle.md). It owns command and lifecycle detail.
+
+Do not copy reference detail into another Skill, plan or state file. The same `delivery-contract.yaml`, active authority and current workspace remain the only lifecycle surfaces.
+
+## Contract Draft And Outcome Decomposition
+
+Every external initial proposal, selected design resource, ordinary planning document or other material input enters the same non-authoritative `delivery-contract.yaml` Draft immediately. Inventory, Source-quality synthesis/refinement, provenance, markers, repository binding and Contract mapping converge in one `long-task-workflow` lifecycle and need not be completed in one response. Conversation-only material becomes exactly one project-native Markdown Source. Do not create a Source-authoring phase, standalone Contract Draft Skill, Draft Receipt, Authoring State, draft schema/CLI/runtime state, handoff or second plan.
+
+A Draft Outcome is an Outcome before Authority Lock, not a new schema field or runtime entity. Decompose only vertical, independently observable, decidable and target-verifiable results whose dependencies and owner boundary can be stated. `depends_on` and Stage gates express acceptance and intermediate-proof readiness, never implementation permission. Do not split for response/YAML/file length, implementation layer, module/file count, Agent capacity, Worker assignment or desired parallelism.
+
+> Outcome decomposes execution and diagnosis, not completion authority.
+
+## Lifecycle Summary
+
+1. Read the request, real Source, relevant Context, repository owners and selected design resources. Before formal Compile and the first implementation edit, surface one repository-bound `Architecture Deliberation`: owner/extension point/source of truth, dependencies and lifecycle, selected and rejected alternatives, future-change challenge, debt disposition, forbidden shortcuts, project-owned Checks and triggered quality attributes or concrete preservation. Put durable conclusions in owning Context and material falsifiable delivery conclusions in real marked Source plus existing Contract fields. Decide `Context Delta: none|required`.
+2. Open the one Contract Draft immediately. When inputs need Source repair, read Source authoring and Contract authoring together; preserve at least one real `source_path`, complete all required semantic/design closure and repair every `decision_required` item without inventing product meaning.
+3. Run read-only `ty-context long-task preflight <workdir>`, repair the same Draft, then run formal Compile only when Source, Context, Contract, repository scope and proof bindings are ready. Compile creates the first Authority Lock; Preflight creates no Authority, Progress, Receipt or state.
+4. When the first Compile returns `execution_model_checkpoint.required: true`, always obey its terminal-turn boundary. Do no product implementation, file edit, build or test after that result, regardless of any earlier textual model strategy. End the turn and tell a Chinese-speaking user exactly `处理好模型更换之后，请发送【继续】。`; use `After handling the model change, send [continue].` in English. Harness cannot observe or verify the model change. A later Compile returns `required: false` and never repeats the pause.
+5. After continuation, apply the Delegation Suitability judgment above and begin Goal-owned rolling implementation. Delegate independent bounded packets only through explicit exact `long_task_implementation`; otherwise the parent executes without a generic substitute or retry. Keep non-independent work in the parent. Re-evaluate Context Delta and Architecture Deliberation when durable facts, scope, ownership, dependency direction, selected design, quality applicability or debt disposition materially changes.
+6. Use targeted verification only when its expected localization value exceeds cost. If authority changes, keep the same Draft and follow protected revision; mechanically bounded repairs may auto-adopt, while semantic weakening or unknown change requires the exact user decision. Adoption returns to rolling implementation and is never completion.
+7. Complete Context, implementation and project tests, create the clean candidate required by the lifecycle reference, then run the one source-recompiled current-snapshot Final Gate. Stop/close and any native Goal completion remain subject to the exact lifecycle and veto rules in the Authority reference.
+
+## Rolling Execution
+
+After Authority Lock and the one-time terminal-turn checkpoint, the parent Goal chooses implementation order, local planning, tools and repair hypotheses, then applies the bounded independence/benefit/coordination test above. Qualifying disjoint packets should be delegated proactively; a packet may cross Outcome or Stage boundaries when its code owner remains coherent, because those boundaries control acceptance readiness rather than edit permission. The profile is optional and can be absent. The parent retains every authority, architecture, Context, integration and formal-verification owner. Delegated reports are advisory, Harness stores no delegation state and all proof-bearing changes converge into the selected verification workspace.
+
+The derived Frontier is only an acceptance/verification and diagnosis projection. Use `verify --explain [--outcome/--check]` for a read-only cost preview and targeted `verify --outcome/--check` for optional feedback. `progress_stale` is a freshness fact; refresh only before an intermediate decision relies on that Progress. Continuing implementation and entering Final Gate need no targeted refresh because Final Gate ignores Progress and reruns all required Checks. Do not add another model-switch pause, trigger queue, implementation gate, per-edit rebuild rule or per-platform progress state.
+
+When implementation discovers a blocker, classify it under the existing protected-revision rules. Difficulty or delay never makes machine-verifiable scope external and never removes Source. Keep exact revision identity, old-Authority continuity, compare-and-swap adoption, evidence invalidation and the complete Final Gate; use the lifecycle reference for diagnosis, decision transport, approval and adoption.
+
+## Final Authority And Handoff
+
+Final Gate recompiles Source authority, freezes and rechecks the complete protected current snapshot, reruns every declared Check and sensitivity control and rejects any protected-input, workspace/tree or Active Authority drift. It never trusts historical Progress, Receipt, compiled cache, delegated report or Agent judgment. Before invoking native Goal completion, perform the required veto-only comparison of current user/Goal meaning with accepted marked Source; mismatch returns to Source/Contract repair and creates no second Gate or proof.
+
+Report implementation/risk, Architecture and Engineering Quality Conformance, Claim Coverage, Stage/target/Gate results, acceptance scope, pending External Confirmations, Context and blockers. Use verifier terms and state boundaries honestly: undeclared/inaccurate Source and unsound project Oracles are not mechanically repaired; Final Gate proves only declared machine authority and its project-check-bound quality set; the host/user owns the native Goal/model; worker injection and reports are not acceptance inputs. The observer remains Level 3; `observed_lifecycle_*` facts cannot replace complete total-cost ROI or the independent audit required for Level 4.

package/assets/skills/long-task-workflow/agents/openai.yaml

@@ -1,6 +1,6 @@
 interface:
   display_name: "Long-Task Workflow"
   short_description: "Run one Delivery Contract in the current native Goal"
-  default_prompt: "Use $long-task-workflow to prepare, execute, resume, verify, or close one Canonical Delivery Contract in the current workspace."
+  default_prompt: "Use $long-task-workflow for one Canonical Delivery Contract. After the first-Authority-Lock checkpoint, proactively delegate independent bounded packets only to the exact custom agent long_task_implementation, using multiple instances for disjoint workstreams when beneficial. If the host cannot explicitly select that custom agent, do not spawn a generic substitute; execute in the parent. Keep Source, Contract, Authority, Context, integration and formal verification in the parent Goal."
 policy:
   allow_implicit_invocation: false

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

@@ -1,78 +1,80 @@
-# Authority Lifecycle Reference
-
-Read this before Preflight, Compile, revision, resume, targeted verify, Final Gate, Stop, close or abandon.
-
-## Preflight And Compile
-
-Run `ty-context long-task preflight <workdir>` before first formal Compile. Resolve every `error` and `decision_required` diagnostic and review warnings. Preflight is read-only: it creates no Active Authority, initial base, marker, cache, Progress, Receipt or pending revision, runs no project Check and persists no success record.
-
+# Authority Lifecycle Reference
+
+Read this before Preflight, Compile, revision, resume, targeted verify, Final Gate, Stop, close or abandon.
+
+## Preflight And Compile
+
+Run `ty-context long-task preflight <workdir>` before first formal Compile. Resolve every `error` and `decision_required` diagnostic and review warnings. Preflight is read-only: it creates no Active Authority, initial base, marker, cache, Progress, Receipt or pending revision, runs no project Check and persists no success record.
+
 Preflight and Compile call the same activation-safety validator. Skipping Preflight bypasses no closed-grammar Source/background continuity, semantic-manifest input/Census/family/unit/relation/population/condition/property/Fact/proof set closure, architecture Source obligation, Control field/relation closure, atomic applicability dimensions, criterion, Claim/all-of-surface, Population universe binding, Stage closure/cross-surface gate, required-target/root/capability/runner binding, scenario/journey separation, capability adequacy, typed external impact, per-Fact semantic proof binding, per-method selected-design artifact binding, bounded Product Conformance, adapter/Observation, risk, owner/path/Binding, recursively frozen verifier dependencies, narrow semantic Counterfactual/liveness or sensitivity rule.
-
-The same workspace classifier also runs before activation and during verification. Before first lock it classifies `HEAD`-relative current paths; later it classifies immutable-`initial_task_base` changes. Protected authority, declared expected change and allowed support remain distinct from forbidden or unclassified paths, which block activation. During first enable, protection covers only exact files present in the current package asset tree for configured managed destinations plus the exact harness config/hook files; managed directory roots and broad `.codex/**` are never implicitly allowed.
-
-Preflight keeps every independently discovered diagnostic. When a structural duplicate makes the same Claim ambiguous or repeated, only that pair receives stable `diagnostic_id`, `repair_group`, `repair_priority` and `blocked_by` metadata so the structural blocker is repaired first. Independent findings keep their compact existing shape; no finding is hidden, reclassified or treated as resolved, and no repair state or authority is created.
-
-The first successful `ty-context long-task compile <workdir>` is Authority Lock and freezes the immutable initial base and complete compiled authority snapshot in Git common-dir, bound to the worktree marker by task id, revision and compiled identity.
-
-Its JSON result includes `execution_model_checkpoint.required: true`, `turn_boundary: end_current_turn`, the blocked implementation actions and explicit-choice semantics. Unless the user already stated an explicit task-specific current-model or switch-and-resume strategy, do no product implementation, file edit, build or test after that result; end the turn and ask for the choice. Generic continue/resume/finish/continue-goal language does not satisfy the checkpoint. Later Compile revisions return `required: false`; no checkpoint file, acknowledgement state, model route or automatic model switch is created.
-
-## Protected Revision
-
-After Authority Lock, every candidate compares against active authority. `authority_changed` does not by itself mean `user_decision_required`:
-
-1. proven monotonic evidence strengthening—including added capabilities while preserving every existing Assertion meaning—and proven tightening auto-revise;
-2. mechanically bounded repair may auto-revise when compiled user-facing meaning and proof obligations stay fixed: raw Source/Context snapshot updates with unchanged Claims/targets, operational Runner or verification-input repair, risk strengthening and machine-proven equivalent Counterfactual Claim/assertion-failure coverage;
-3. repo-bound owner/expected-change/allowed-support or Binding-carrier expansion may auto-revise; `diagnose-revision` may exercise existing active Check identities without creating state before final Compile; or
-4. Product/Source Claim/target/external-confirmation change, lost scenario/Claim/Evidence Capability/failure interception, forbidden or owner-Context removal, runner type/effect change, verifier-kernel change and every unknown reason fails closed for the exact revision identity and is never candidate-executed.
-
-Automatic adoption never means “unprotected”: exact identity, active-Authority compare-and-swap, affected-evidence invalidation and the complete source-recompiled Final Gate remain mandatory. Risk downgrade is still rejected.
-
-`diagnose-revision` recompiles the same `delivery-contract.yaml` in memory, creates only a disposable workspace snapshot when class 2 is proven, and returns transient repair results with `acceptance_authorized: false`. It writes no pending/approval state, authority/marker, cache, Progress or Receipt. Repeated edits therefore accumulate only in the one existing Contract authoring file, not a pending Draft authority or candidate state plane.
-
-Ordinary `compile --revise` is the only operation that may create the one pending decision. It binds a deterministic concise change summary into the revision identity and distinguishes `user_decision_reasons` from `mechanically_bounded_reasons`. Compile/status/resume derive the same self-contained `decision_brief` from that canonical summary. The brief explains what Authority Revision is, why this one needs a decision, material changes, affected Outcomes, previous-Authority/reject behavior, the no-completion effect and mandatory Final Gate.
-
-Present that brief before asking for the exact identity. First compare every listed decision reason with explicit instructions in the current task: if one task-specific instruction already covers all of them exactly, mechanically relay that existing user decision through the exact approval command without asking again. This is decision transport, not Agent approval. A generic continue/resume/finish, blanket “approve later revisions”, recommendation, partial coverage or Agent inference never qualifies. The executing Agent never originates its own weakening decision.
-
-During repair, use stateless diagnosis and ordinary edits; do not invoke decision-producing Compile for intermediate candidates. Withdrawn or replaced identities therefore generate no question. When the final blocking candidate is stable, ask at most once. If it later changes, its identity changes and any old approval is rejected. No instruction ledger, standing approval or candidate state is created.
-
-The previous Authority remains active until exact approval and compare-and-swap adoption. Adoption reports `delivery_completed_by_this_event: false`, invalidates affected evidence and returns to rolling implementation or repair under the revised Authority; the complete source-recompiled Final Gate remains mandatory.
-
-Every path-bearing field uses canonical grammar. Internal `.`/`..`, control characters, empty segments, absolute/drive/UNC paths and unsupported glob syntax fail closed.
-
+
+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`, `action: change_model_in_host_then_continue`, `resume_token: continue`, `turn_boundary: end_current_turn`, the blocked implementation actions and explicit model non-observability. Always do no product implementation, file edit, build or test after that result, even when an earlier message stated a model strategy. End the turn and tell a Chinese-speaking user exactly `处理好模型更换之后，请发送【继续】。`; use `After handling the model change, send [continue].` in English. Harness cannot observe or verify the host model change, and the continuation is not an acknowledgement record. Later Compile revisions return `required: false`; no checkpoint file, acknowledgement state, model route or automatic model switch is created.
+
+The optional Codex `long_task_implementation` custom agent is available only as a post-checkpoint rolling implementation affordance. Its fixed package-owned configuration is not a checkpoint option and cannot acknowledge, satisfy or replace the host boundary. It writes no workflow state and owns no Source, Contract, Authority, Context writeback, Progress, Evidence, Receipt or Final Gate; if the exact profile selector or Codex custom-agent support is unavailable, the parent Goal continues directly without a generic substitute and formal acceptance is unchanged. The main Skill owns the complete Delegation Suitability and parent/worker policy.
+
+## Protected Revision
+
+After Authority Lock, every candidate compares against active authority. `authority_changed` does not by itself mean `user_decision_required`:
+
+1. proven monotonic evidence strengthening—including added capabilities while preserving every existing Assertion meaning—and proven tightening auto-revise;
+2. mechanically bounded repair may auto-revise when compiled user-facing meaning and proof obligations stay fixed: raw Source/Context snapshot updates with unchanged Claims/targets, operational Runner or verification-input repair, risk strengthening and machine-proven equivalent Counterfactual Claim/assertion-failure coverage;
+3. repo-bound owner/expected-change/allowed-support or Binding-carrier expansion may auto-revise; `diagnose-revision` may exercise existing active Check identities without creating state before final Compile; or
+4. Product/Source Claim/target/external-confirmation change, lost scenario/Claim/Evidence Capability/failure interception, forbidden or owner-Context removal, runner type/effect change, verifier-kernel change and every unknown reason fails closed for the exact revision identity and is never candidate-executed.
+
+Automatic adoption never means “unprotected”: exact identity, active-Authority compare-and-swap, affected-evidence invalidation and the complete source-recompiled Final Gate remain mandatory. Risk downgrade is still rejected.
+
+`diagnose-revision` recompiles the same `delivery-contract.yaml` in memory, creates only a disposable workspace snapshot when class 2 is proven, and returns transient repair results with `acceptance_authorized: false`. It writes no pending/approval state, authority/marker, cache, Progress or Receipt. Repeated edits therefore accumulate only in the one existing Contract authoring file, not a pending Draft authority or candidate state plane.
+
+Ordinary `compile --revise` is the only operation that may create the one pending decision. It binds a deterministic concise change summary into the revision identity and distinguishes `user_decision_reasons` from `mechanically_bounded_reasons`. Compile/status/resume derive the same self-contained `decision_brief` from that canonical summary. The brief explains what Authority Revision is, why this one needs a decision, material changes, affected Outcomes, previous-Authority/reject behavior, the no-completion effect and mandatory Final Gate.
+
+Present that brief before asking for the exact identity. First compare every listed decision reason with explicit instructions in the current task: if one task-specific instruction already covers all of them exactly, mechanically relay that existing user decision through the exact approval command without asking again. This is decision transport, not Agent approval. A generic continue/resume/finish, blanket “approve later revisions”, recommendation, partial coverage or Agent inference never qualifies. The executing Agent never originates its own weakening decision.
+
+During repair, use stateless diagnosis and ordinary edits; do not invoke decision-producing Compile for intermediate candidates. Withdrawn or replaced identities therefore generate no question. When the final blocking candidate is stable, ask at most once. If it later changes, its identity changes and any old approval is rejected. No instruction ledger, standing approval or candidate state is created.
+
+The previous Authority remains active until exact approval and compare-and-swap adoption. Adoption reports `delivery_completed_by_this_event: false`, invalidates affected evidence and returns to rolling implementation or repair under the revised Authority; the complete source-recompiled Final Gate remains mandatory.
+
+Every path-bearing field uses canonical grammar. Internal `.`/`..`, control characters, empty segments, absolute/drive/UNC paths and unsupported glob syntax fail closed.
+
 Controlling Context includes core Context, explicit `context_refs`, verification/deployment Context and every selected Context file. `context_snapshot_mode: full` is mandatory; legacy referenced-mode Contracts require semantic migration rather than silently retaining a partial authority snapshot.
-
+
 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 Fact universe, 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/variation/property/Fact/proof universe, expected located digest, comparator/tolerance/mask, Oracle/environment, sensitivity policy 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.
-
+
+`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
 
-Implementation remains Goal-owned throughout rolling execution. The Goal may use one agent or multiple platform-native agents/subagents when their expected benefit exceeds coordination cost, but Harness allocates and records none of them. Delegated reports are not Progress or proof, and every proof-bearing result must converge into the selected verification workspace. Stage/Outcome readiness, `progress_stale` and targeted feedback never become agent allocation, edit permission, a method Gate or a scheduler.
+Implementation remains parent-Goal-owned throughout rolling execution. Apply the complete suitability and worker policy in the main Skill; Harness allocates and records no worker. Delegated reports are not Progress, Evidence or proof, and every proof-bearing result must converge into the selected verification workspace. Stage/Outcome readiness, `progress_stale` and targeted feedback never become agent allocation, edit permission, a method Gate or a scheduler.
 
 `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, the earliest useful runnable boundary and later coalesced relevant changes are recommended targeted-feedback points only when their expected localization value exceeds cost. The owning Outcome binds proof; it does not gate implementation order. `progress_stale` is a fact about evidence freshness, not an immediate execution instruction. Refresh the declared Check only before an intermediate decision relies on its Progress. Continuing implementation and entering Final Gate require no targeted refresh because Final Gate ignores Progress and reruns all Checks. Do not create a per-edit/per-Outcome rebuild rule, implementation gate, 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, applicability, runner, verification inputs, Controlling Context and implementation inputs. Retry defaults to none; one retry is allowed only for explicit `transient_once`, idempotent, read-only/test-sandbox work.
-
-Status, Progress, Receipts and workdir compiled output are audit/recovery projections only. Development-period authority state is `manual_required` and never migrated.
-
-Report their exact meaning: `progress_passing` is current targeted repair evidence rather than “Outcome complete”; `progress_stale` is a freshness fact rather than a current pass or immediate rerun command; `final_workflow_status: null` means the Goal is unfinished. `status`/`resume` derive `ready_stages`, `ready_outcomes` and Stage status from current Progress; they do not persist a Stage pass. `target_state` remains `not_accepted` until a fresh Final Gate accepts, becomes `blocked_external` for a target blocker, or names the Contract's `implementation_complete`, `target_profile_usable` or `production_release_ready` state after machine acceptance. Do not invent per-platform progress/status.
-
-## Final Gate And Terminal Paths
-
+
+Before 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, the earliest useful runnable boundary and later coalesced relevant changes are recommended targeted-feedback points only when their expected localization value exceeds cost. The owning Outcome binds proof; it does not gate implementation order. `progress_stale` is a fact about evidence freshness, not an immediate execution instruction. Refresh the declared Check only before an intermediate decision relies on its Progress. Continuing implementation and entering Final Gate require no targeted refresh because Final Gate ignores Progress and reruns all Checks. Do not create a per-edit/per-Outcome rebuild rule, implementation gate, 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, applicability, runner, verification inputs, Controlling Context and implementation inputs. Retry defaults to none; one retry is allowed only for explicit `transient_once`, idempotent, read-only/test-sandbox work.
+
+Status, Progress, Receipts and workdir compiled output are audit/recovery projections only. Development-period authority state is `manual_required` and never migrated.
+
+Report their exact meaning: `progress_passing` is current targeted repair evidence rather than “Outcome complete”; `progress_stale` is a freshness fact rather than a current pass or immediate rerun command; `final_workflow_status: null` means the Goal is unfinished. `status`/`resume` derive `ready_stages`, `ready_outcomes` and Stage status from current Progress; they do not persist a Stage pass. `target_state` remains `not_accepted` until a fresh Final Gate accepts, becomes `blocked_external` for a target blocker, or names the Contract's `implementation_complete`, `target_profile_usable` or `production_release_ready` state after machine acceptance. Do not invent per-platform progress/status.
+
+## Final Gate And Terminal Paths
+
 Before Final Gate, complete Context/code/tests and create a clean candidate commit. Final Gate first verifies the accepted compiled authority is still fresh, then recompiles Source authority and records semantic plus raw protected-input identity for the Contract and fragments, the Source-embedded semantic manifest, every Source file, full Controlling Context, verifier/runner, recursively frozen local verifier dependencies, `verification_inputs` and workdir inputs. It validates the common-dir record/marker, creates one Git-tree snapshot and reruns every Check and sensitivity control. Non-UI semantic evidence must reproduce exactly every compiled machine Fact × method expectation with one attributable actual observation/environment/comparison/verdict under frozen expected/tolerance/mask/Oracle authority; selected-design method evidence must reproduce its exact compiled `fact_results` universe; every verdict passes, while named external obligations remain pending rather than fabricated. After execution it recompiles and re-hashes the same full protected set; any change returns `protected_inputs_changed_during_final_gate`, while an Active Authority race returns `active_authority_changed_during_final_gate`. Only unchanged protected inputs, workspace/tree and Authority may be accepted. It is the sole Long-Task `Engineering Quality Conformance`/`Architecture Conformance` carrier and the sole non-UI semantic and selected-design closure carrier: material independently falsifiable deliberation conclusions must already be declared through existing Source-backed obligations/constraints/forbidden shortcuts, owners/paths/Bindings, project-owned Checks and separate Assertions when functional behavior can pass independently. It proves exactly that declared project-check-bound engineering-quality set, not overall code quality, and no separate default Contract Conformance closure runs. A target-runtime Check must exercise its exact target again in that Final Gate execution; rereading historical status does not become live proof merely because the reader reran. The Receipt reports the target profile/state and every Stage as `passed`, `failed`, `blocked_external` or `blocked_dependency`.
-
-Commit, verifier migration, clear and abandon share one active-state lock. Stop/close clear only the identity actually accepted through CAS and preserve `machine_accepted_external_pending` plus every named external confirmation in output. Final Gate/Stop/close identify `acceptance_scope: declared_machine_authority` and `native_goal_effect: none`; close additionally identifies `closed_scope: machine_authority`. The Stop Hook emits the same scope as one non-blocking message for either accepted machine status. A stale Receipt exposes no accepted workflow status.
-
-Before platform-native Goal completion, compare current Goal/user meaning with accepted marked Source and check for a pending revision, unresolved blocker or omitted requirement. This review may only veto completion and direct Source/Contract repair; it is not a second acceptance Gate and cannot create proof.
-
-For invalid, mismatched, unrecoverable or stale-lock continuity, use only `ty-context long-task abandon <workdir> --force-corrupt-state`; it preserves authored Contract, Source, Context and Git content.
-
+
+Commit, verifier migration, clear and abandon share one active-state lock. Stop/close clear only the identity actually accepted through CAS and preserve `machine_accepted_external_pending` plus every named external confirmation in output. Final Gate/Stop/close identify `acceptance_scope: declared_machine_authority` and `native_goal_effect: none`; close additionally identifies `closed_scope: machine_authority`. The Stop Hook emits the same scope as one non-blocking message for either accepted machine status. A stale Receipt exposes no accepted workflow status.
+
+Before platform-native Goal completion, compare current Goal/user meaning with accepted marked Source and check for a pending revision, unresolved blocker or omitted requirement. This review may only veto completion and direct Source/Contract repair; it is not a second acceptance Gate and cannot create proof.
+
+For invalid, mismatched, unrecoverable or stale-lock continuity, use only `ty-context long-task abandon <workdir> --force-corrupt-state`; it preserves authored Contract, Source, Context and Git content.
+
 An older `long-task-delivery-v2` Contract that lacks the Source `semantic-fact-manifest-v1`, root manifest identity, exact Outcome Fact/proof bindings, typed per-Fact results, Stage, required-target capabilities, full Context mode, atomic applicability dimensions, scenario, journey, success/degradation, Population universe binding, Control-relation applicability, per-method design record/primary-observation artifacts, canonical design `fact_expectations`, blocker-required capabilities, narrow semantic witnesses or typed external-impact fields is a manual migration. `upgrade --check` reports `long-task-v2-semantic-drift-authority`, and parsing lists missing field paths. Re-author the semantic universe and those meanings from Source, controlling Context and any current validated handoff; never infer them from old Progress/Receipts or import historical passing evidence as acceptance. Reclassify every Check path explicitly: implementation/runtime material belongs in `input_paths`, `expected_output_paths` or `artifact_globs`; Oracle/config/data inputs belong in `verification_inputs`. Supported direct-literal local Oracle dependencies are frozen recursively, while non-literal loaders fail closed and indirect runtime access remains declared Oracle TCB.