# 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`, `action: change_model_in_host_then_continue`, `resume_token: model checkpoint cleared, continue`, `generic_continue_satisfies: false`, `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, reply exactly: model checkpoint cleared, continue` in English. Do not accept a generic continuation under this package-managed prompt protocol. Harness cannot observe the next host message or verify the host model change, and the continuation is neither a machine-enforced unlock nor 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.

## Targeted Verification And Recovery

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 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.

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.