project-tiny-context-harness 0.11.0 → 0.12.0

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

@@ -1,58 +0,0 @@
-# Design-System Authority Adoption
-
-Adopt one explicitly selected Open Design result through existing Minimal Context owners. This is a reconciliation step, not a new authority lifecycle.
-
-## Preconditions
-
-- Selection is explicit, or the user explicitly delegated selection and the stated criteria support one defensible choice.
-- After seeing the selected candidate's exact project diff and migration impact, the user separately and explicitly confirmed Authority adoption. Page/resource approval and system-candidate selection are insufficient.
-- The current complete project Authority closure identity is readable and still matches the candidate base. A stale `reconcile` packet returns to DRA assessment.
-- The exact provider design-system ID and selected revision/body are readable.
-- `DESIGN.md`, optional sparse manifest/subordinate owners, generated token artifacts and relevant preview/workspace files have been inspected.
-- The selected content has a stable digest or user-approved snapshot.
-- Conflicts with product/surface Context are resolved or remain an explicit decision; provider output never silently overrides product meaning.
-
-## Single-owner writeback
-
-Use these owners:
-
-- `project_context/**`: durable surface responsibility, information hierarchy, navigation, stable interaction/state, product accessibility requirements and repeatable verification entrypoints;
-- root `DESIGN.md`: unique Authority entry/revision owner, visual principles, supported front-matter exact Token authority and the canonical body-leading `<!-- ty-context-design-authority-format: bundle-v1 -->` bundle declaration;
-- sparse `design_system/**` subordinate owners: only real reusable component/pattern/motion/platform rules, indexed from the entry;
-- `design_system/tokens.json`: deterministic generated DTCG output from `DESIGN.md`, never independently authored;
-- `design_system/authority.manifest.json`: complete closure membership and digest only, never revision, direction or Token values;
-- selected authored targets: concrete composition/condition coverage, kept as ordinary versioned project Source.
-
-Do not copy the same fact into several owners. Open Design metadata is provenance only.
-
-## Adoption procedure
-
-1. Inspect the complete current closure and preserve its identity as the adoption CAS base. Read the project's `DESIGN.md` format and lint expectations. Preserve valid project-specific content unless the user explicitly authorized replacement.
-2. Reconcile selected provider semantics against controlling Context. Provider-invented business, permission, data or algorithmic rules are excluded unless independently authorized by product Source.
-3. Write selected system semantics and exact Token values into root `DESIGN.md`. When adopting or retaining bundle format, place the exact `<!-- ty-context-design-authority-format: bundle-v1 -->` declaration on the first non-empty Markdown body line after supported YAML front matter. Add or revise a subordinate owner only for an actual reusable durable rule; do not scaffold an empty taxonomy. Avoid style-only adjectives without implementation meaning.
-4. Record provider provenance in a normal `DESIGN.md` section unless the format explicitly permits metadata fields. Include provider name/version, design-system ID, selected revision when applicable, selection basis, immutable source/snapshot locator and SHA-256 digest, plus the editable upstream owner/locator/update/export route. State that project files are canonical.
-5. Update only relevant Context when durable surface/interaction/verification facts changed. Use stable surface/control/target keys to make every adopted decision-relevant target Context-reachable without duplicating the visual prose.
-6. Deterministically project DTCG `design_system/tokens.json` from the adopted `DESIGN.md`; never hand-edit generated Token values. The read-only `ty-context design-authority tokens --from-entry` command may project while the old bundle digest is intentionally stale. Create/update the sparse manifest together with the canonical marker, without revision or Token semantics, calculate the canonical complete-closure digest and make a second current-base check immediately before writeback. A deliberate bundle-to-one-file adoption removes both marker and manifest in the same explicit Authority Revision; never leave either half orphaned.
-7. Put concrete selected targets in project-native versioned paths selected by the user or existing convention. Never silently choose a repository directory merely because Open Design has a mutable workspace. Never overwrite an adopted selected-resource baseline in place; create a new immutable version/digest and update its owner.
-8. Inspect the new closure and require its claimed digest, generated Tokens, links, file identities and extra-file policy to validate. Rebind affected DRA handoffs/resources to the new identity and rerun their affected preflight/representative verification.
-9. Accept the selected provider revision if one exists, then re-read the MCP resource and compare identity/body or digest with the adopted selection.
-10. Verify downstream project binding by creating or reading a provider project with the selected ID. Provider mismatch is synchronization drift, not evidence that project Authority is absent.
-
-## Validation
-
-Run the repository-owned Design Authority lint, Context validation and token generation/check paths. At minimum confirm:
-
-- `DESIGN.md` is no longer an unconfigured starter;
-- root `DESIGN.md` is the sole revision and editable exact-Token owner;
-- the exact bundle marker is the first non-empty Markdown body line and exists if and only if the sparse manifest exists;
-- generated `tokens.json` exactly matches deterministic projection;
-- the sparse manifest contains only complete closure membership/digest and the claimed closure validates;
-- provenance points to the selected provider ID/revision/digest;
-- each adopted target has a readable immutable locator and a verified editable upstream/update route or an explicit manual/external-update boundary;
-- no competing design-system authority or duplicate token owner was introduced;
-- MCP can read the provider design system;
-- a downstream Open Design project reports the matching `designSystemId`;
-- candidate resources remain candidates unless independently selected.
-- affected DRA handoffs bind the new closure identity and their current validation was rerun.
-
-Report changed owners and validation results. Do not claim production visual acceptance from these checks.

package/assets/skills/design-system-authoring/references/open-design-design-system-provider.md

@@ -1,114 +0,0 @@
-# Open Design Design-System Provider
-
-Use Open Design's live structured surface. Do not assume the installed version matches this compatibility note; discover first and branch on actual tool/resource schemas.
-
-## Capability order
-
-1. Open Design MCP resources/tools.
-2. The same installed Open Design daemon's structured HTTP API when MCP lacks the required design-system lifecycle operation.
-3. Open Design UI/CLI only for bootstrap, preview inspection or a capability unavailable through structured paths.
-
-Never call a copied prompt or local imitation a provider result. Persistent MCP registration, plugin/auth changes and new disclosure paths require separate authorization.
-
-The package-local `@google/design.md` adapter performs deterministic lint, parse/validate, export and diff only. It is not Open Design, does not generate candidates and owns no provider authentication, polling, selection or adoption.
-
-## Current verified MCP contract
-
-Open Design 0.15.1 exposed MCP server 0.2.0 using protocol `2025-06-18`. A live read-only smoke observed 152 concrete design-system resources through `resources/list`; `resources/read` returned their Markdown bodies. The URI families are:
-
-- `od://design-systems/<id>/DESIGN.md` for current design-system bodies;
-- `od://skills/<id>/SKILL.md` for functional skills;
-- `od://focus/active` for current focus.
-
-This version returns `-32601` for `resources/templates/list`. Treat template enumeration as optional protocol capability: use concrete `resources/list` results when present and never reject a readable design-system catalogue merely because the template-list method is absent.
-
-Its 18 observed tools included `list_projects`, `get_project`, `create_project`, `start_run`, `get_run`, file/artifact operations and capability discovery. `create_project` accepts optional `designSystem`; verify the result through `get_project.designSystemId`. This version exposes design systems as resources but no create/update design-system MCP tool.
-
-Feature-detect future structured methods before using the fallback. A tool name alone is insufficient: inspect its input schema and result.
-
-## Generation fallback for Open Design 0.15.1
-
-When MCP cannot create a design system, discover the running daemon and use its official API. Prefer install metadata supplied by Open Design rather than hardcoded paths. Confirm `/api/health` and the version first.
-
-Start generation:
-
-```http
-POST /api/design-systems/generation-jobs
-Content-Type: application/json
-```
-
-The body is the provider's current design-system input. Supported 0.15.1 fields observed in the installed provider include:
-
-```json
-{
-  "title": "Product design system",
-  "category": "Custom",
-  "surface": "web",
-  "summary": "Product and brand intent",
-  "sourceNotes": "Bounded design brief",
-  "provenance": {
-    "companyBlurb": "Product context",
-    "sourceUrls": [],
-    "githubUrls": [],
-    "localCodeFiles": [],
-    "figFiles": [],
-    "assetFiles": [],
-    "notes": "Selection constraints"
-  }
-}
-```
-
-Send only relevant, user-authorized sources. Do not transmit secrets or unrelated repository content. `surface` is provider-defined; validate the live accepted value. A supplied `body` creates a direct draft and must not be misrepresented as model generation.
-
-Poll `GET /api/design-systems/generation-jobs/<jobId>` at a bounded cadence until a terminal state. Preserve the job ID, step diagnostics and returned `designSystemId`. The observed pipeline explores resources, creates a draft, generates `DESIGN.md`/README/SKILL/tokens/previews/context files, registers files and prepares review.
-
-## Review and revision
-
-Read the system and inspect its assets through:
-
-- `GET /api/design-systems/<id>`;
-- `GET /api/design-systems/<id>/files` and `/file?path=<path>`;
-- `GET /api/design-systems/<id>/preview` or `/showcase`;
-- `POST /api/design-systems/<id>/workspace` when an editable review project is required.
-
-Create scoped feedback with:
-
-```http
-POST /api/design-systems/<id>/revision-jobs
-Content-Type: application/json
-
-{"feedback":"...","sectionTitle":"optional section"}
-```
-
-Poll the returned job through the generation-job endpoint. A succeeded revision job creates a pending revision; it does not alter project authority and must not be called accepted. Inspect revisions with `GET /api/design-systems/<id>/revisions`. After explicit selection, set exactly that revision to accepted:
-
-```http
-PATCH /api/design-systems/<id>/revisions/<revisionId>
-Content-Type: application/json
-
-{"status":"accepted"}
-```
-
-Reject explicitly discarded revisions when useful. Accepting a provider revision updates the provider copy only; the authority-adoption step still owns the project writeback.
-
-The provider also exposes `POST /api/design-systems/<id>/token-contract/rebuild-jobs`. Use it only when the live token-quality decision says a rebuild is available or the user explicitly requests a forced rebuild. A generated token contract still needs selection and project adoption.
-
-## Provider binding for downstream resources
-
-For a new Open Design resource project, call MCP `create_project` with the adopted provider ID in `designSystem`. Immediately call `get_project` and require `designSystemId` to match.
-
-For an existing project, inspect `get_project` first. When it is missing or mismatched, prefer a new bounded project with the correct binding if MCP offers no safe update. Use a live structured provider update only after feature-detecting it and preserving project identity. Never proceed with a style-bearing run while silently bound to another system.
-
-In DSA `reconcile` mode, send only the current Authority material needed for the proposed Token/component/pattern/motion/platform delta, the user-promoted non-authoritative assessment, immutable constraints, affected platforms, supporting resources and representative scenarios. Provider output remains a system candidate. It cannot emit an effective `selected`, `adopted` or `authority_updated` decision.
-
-## Failure semantics
-
-Keep these states separate:
-
-- daemon/MCP execution: queued, running, succeeded, failed, cancelled or unknown;
-- candidate artifacts: missing, partial, retrievable, rendered or corrupt;
-- selection: unreviewed, selected, rejected or decision-required;
-- project adoption: unchanged, partially adopted, adopted or inconsistent;
-- provider binding: unverified, matched or mismatched.
-
-Preserve exact errors and stop bounded polling. Do not mark a candidate selected because generation succeeded, and do not mark project authority adopted because a provider revision was accepted.

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

@@ -1,75 +0,0 @@
----
-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, 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 fixed package-owned `long_task_implementation` with child agents disabled. It is static, stateless, non-Authority and post-checkpoint; install proves neither selection nor effective model/reasoning/tier. Profile and spawn never set `service_tier`. Exact-call or capability failure returns a packet to the parent; never infer it, use a generic child, or add tiers/retry/scheduling.
-
-`long-task-delivery-v2` is the active Contract schema. `delivery-contract.yaml` is the root authoring file. New authoring uses inline Outcomes; existing `outcome_files` are compatibility only. Legacy split-delivery commands are non-executing.
-
-## Controlling Objective
-
-Prevent false completion inside declared authority. Given complete Source, a meaning-preserving Contract projection, complete applicability and admitted machine/external authority boundaries, `AcceptedDeliveryTerminal` implies every declared obligation is fulfilled. Machine proof needs package-admitted Actual and Harness-owned comparison; unsupported proof needs a complete declared external route. Every requirement, Fact, proof obligation and independently falsifiable AC stays traceable, and every unproved item blocks.
-
-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 current-final-snapshot evidence may accept. `AcceptedDeliveryTerminal` is fresh `machine_accepted` with no blocking external fulfillment or fresh `delivery_accepted` after exact current fulfillment; every other or legacy status is non-closeable. Progress is repair evidence only and never acceptance authority; external records alone never accept. Final Gate alone carries Long-Task Engineering Quality Conformance, Architecture Conformance and terminal status for the declared 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.
-
-Anti-Degradation Assurance protects coverage, false-negative resistance, fail-closed Authority and final-snapshot proof before cost. Purpose replacement requires a project-owner design-purpose decision and replacement proof. `F = Implementation Freedom Boundary` leaves methods, feedback, packet decomposition and dynamic count Goal-owned within Source/Contract/safety. After the checkpoint, identify packets before profile/capacity. Each is `independently_safe`, has `positive_expected_parallel_benefit` and `bounded_input_and_output`, is `parent_integratable`, and the set is pairwise `owner_disjoint`, `path_disjoint` and `source_of_truth_disjoint`. Unless explicit user/host policy prohibits agents, make actual host calls for multiple exact workers with `agent_type: long_task_implementation`; intent is not delegation and only call or explicit capability results establish profile/capacity. Count stays dynamic.
-
-Select one zero-start reason by the Workflow Contract's ordered first-match rule: policy prohibition -> insufficient base candidates -> disjointness conflict -> coordination cost -> actual exact-spawn capacity failure -> other exact-worker unavailability. Unknown capacity is not insufficiency. Once any exact worker starts, later profile/capacity failure is partial delegation rather than a parent-only reason: keep that worker, return the rest to the parent and report the cause; use no generic substitute or retry. A type mismatch returns its packet. Never override `service_tier` or claim unobservable inheritance. Add no development phase/method Gate, fixed count/Outcome mapping, allocator/scheduler, queue/DAG/registry/proof or persistent delegation state.
-
-Each worker gets one self-contained packet containing its goal, allowed owners and paths, forbidden paths, relevant Source, Contract and Context references, implementation entrypoints, checks, expected return format and known dependency/integration risk. Before dispatch, the parent reads `git status --short` and `git diff --name-only` non-persistently. Workers only implement/check; truth, Authority, spawning, worktrees and acceptance remain parent-owned. `PreToolUse` denies non-exact creation and freshly checks visible profile parity; `SubagentStart` reinforces type without proving trust, effective execution or load atomicity. After return, the parent inspects the actual diff and integrates results only after comparing actual changed paths and the final working-tree diff with the union of packet envelopes. This proves path-envelope conformance, not per-line actor attribution; unexplained/overlapping/out-of-envelope/shared-owner changes block integration and Final Gate.
-
-## 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. Preflight classifies every blocking obligation as `machine_admitted`, `external_fulfillable` or `unreachable`; any unreachable row blocks before implementation. Compile creates the first Authority Lock; Preflight creates no Authority, Progress, Receipt or state.
-4. On the first Compile result with `execution_model_checkpoint.required: true`, do no product implementation, edit, build or test; end the turn. Tell a Chinese-speaking user exactly `处理好模型更换后，请仅回复：模型切换卡点解除，继续`; in English use `After handling the model change, reply exactly: model checkpoint cleared, continue`. Generic continuation does not satisfy this managed prompt protocol. Harness observes neither the next host message nor the model change, so this is no machine unlock or attestation. Later Compile returns `required: false` without repeating the pause.
-5. After continuation, begin Goal-owned rolling implementation and apply Delegation Suitability above. Qualifying work gets actual multiple exact `long_task_implementation` calls; otherwise record one admitted solo reason. Keep coupled work in the parent. Refresh Context Delta and Architecture Deliberation when durable scope, ownership, dependency, design, quality or debt 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
-
-Apply packet-first above. Outcomes/Stages govern acceptance, not edits; coherent-owner packets may cross them. Parent retains Authority, packet selection, Context, integration and verification; proof-bearing changes converge into the selected verification workspace.
-
-Status/resume frontiers and the Finding-derived Repair Frontier are non-persisted diagnostic projections only; they never accept, schedule or authorize protected semantic changes. 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 it. Final Gate ignores Progress and reruns all required Checks. Add no 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, rechecks the complete protected current snapshot, reruns every declared Check/control, revalidates exact current external records and rejects protected-input, workspace/tree or Active Authority drift. It trusts no historical result, cache, record, delegated report or Agent judgment. Use external commands only through the lifecycle reference. Before native Goal completion, perform its veto-only user/Goal-to-Source comparison; mismatch returns to Source/Contract repair without creating proof.
-
-Report implementation/risk, conformance, Claim/Stage/target/Gate results, exact terminal status, acceptance scope, external evaluations, Context and blockers. Keep verifier boundaries honest: incomplete Source and unsound Oracles are not mechanically repaired; local actor checks are not authentication; the host owns Goal/model; worker reports never accept. The observer remains Level 3; `observed_lifecycle_*` cannot replace complete total-cost ROI or the independent Level 4 audit.

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

@@ -1,6 +0,0 @@
-interface:
-  display_name: "Long-Task Workflow"
-  short_description: "Run one Delivery Contract in the current native Goal"
-  default_prompt: "Use $long-task-workflow for one Canonical Delivery Contract. After the first-Authority-Lock checkpoint, identify qualifying bounded packets before profile/capacity; absent an explicit policy prohibition, make actual calls for multiple exact long_task_implementation workers and let host results determine zero-start or partial fallback. Never infer unavailability, use a generic substitute or fix the count. Keep Source, Contract, Authority, architecture, Context, packet selection, integration and formal verification in the parent Goal."
-policy:
-  allow_implicit_invocation: false

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

@@ -1,86 +0,0 @@
-# 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`, Stage status, live external-record evaluations and a non-persisted diagnostic Repair Frontier from current findings/bindings/Progress; they do not persist a Stage pass, repair queue or scheduler state. `target_state` remains `not_accepted` until a fresh Final Gate accepts, becomes `blocked_external` for a pending target blocker, or names the Contract's `implementation_complete`, `target_profile_usable` or `production_release_ready` state after `machine_accepted` or `delivery_accepted`. Do not invent per-platform progress/status.
-
-## Final Gate And Terminal Paths
-
-Final Gate is the sole Long-Task `Engineering Quality Conformance`/`Architecture Conformance` carrier; no parallel default conformance carrier runs for an active Long-Task.
-
-Before Final Gate, complete Context/code/tests and create a clean candidate commit. Final Gate first verifies the accepted compiled authority is still fresh, recompiles Source authority and records semantic plus raw protected-input identity for the Contract/fragments, Source-embedded semantic manifest, every Source file, full Controlling Context, verifier/runner, recursively frozen local verifier dependencies, `verification_inputs`, workdir inputs and external state. It validates the common-dir record/marker, creates one Git-tree snapshot and runs every Check and sensitivity control exactly once. Non-UI semantic evidence reproduces every compiled machine Fact × method expectation; selected-design evidence reproduces its exact admitted result universe. Blocking External Record v2 validation includes schema/content hash, protected Source-bound Ed25519 identity, current challenge and signature, exact actor/target/environment/applicability/obligation/result-kind sets, whole-candidate identity, immutable artifact snapshots, objective comparator or Source-backed judgment and passed per-obligation results. Ed25519 proves possession of the bound key, not real-world identity beyond that binding.
-
-After the long execution phase, Final Gate enters one short `withActiveAuthorityLock("finalize")` phase and does not rerun machine Checks. It re-reads Active Authority and CAS identity, candidate HEAD/tree/workspace fingerprint, compiled/verifier freshness, every external record/challenge/signature/artifact/evaluation and the complete `FinalizationIdentityV1`. `finalizeDeliveryGateCas` compares that identity, binds `finalization_identity_sha256` into Receipt v3 and publishes atomically. `final-gate` uses `close_on_accept=false`; Stop/close use `true`, so an accepted Receipt and Authority cleanup commit together, while a blocked/failed result keeps Authority. Any candidate, Authority, record, challenge, signature or artifact race is non-accepted, preserves Authority and cannot leave a fresh accepted Receipt. Final Gate remains the sole Engineering Quality/Architecture Conformance, semantic, selected-design and terminal carrier; it proves only its declared project-check-bound set, not overall code quality. Receipt v3 reports `machine_accepted`, `delivery_accepted`, `blocked_external` or `needs_work`; historical v3 Receipts without the Finalization Identity are audit-readable and stale.
-
-Use exactly `ty-context long-task external prepare <workdir> [--confirmation <key>]`, `external submit <workdir> --confirmation <key> --record <path>`, `external status <workdir>`, `external rotate <workdir> --confirmation <key>` and `external revoke <workdir> --confirmation <key>`. Preparation creates or reuses the current challenge, emits the exact whole-candidate signable packet and may batch only compatible actor/target/environment/journey/evidence rows without merging logical obligation identity. Submit validates Authority/freshness, v2 schema, candidate, challenge, actor, detached Ed25519 signature, exact obligation/result-kind set, immutable artifact snapshots and comparator before atomic storage. Status re-evaluates identity/signature/challenge/artifact integrity; rotate changes the challenge; revoke removes the named record and rotates its challenge. None runs a Gate or accepts a delivery, and Harness never reads the actor's private key or signs v2 records.
-
-Authority commit/migration, external submit/rotate/revoke, finalization, clear and abandon share the applicable active-state integrity/lock boundary. Stop/close rerun the Live Final Gate and clear only the identity accepted in that same Finalization CAS as `machine_accepted` or `delivery_accepted`. `blocked_external`, `needs_work`, Record v1, declared-only identity and legacy `machine_accepted_external_pending` never clear or close. Final Gate/Stop/close identify `acceptance_scope: declared_delivery_authority` and `native_goal_effect: none`; close additionally identifies `closed_scope: complete_long_task_authority`. The Stop Hook emits the same scope as one non-blocking message for either accepted terminal. 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. A missing `completion_authority` alone deterministically defaults to `machine_only`; migration never infers `declared_authorities`. Exact unchanged Fragment projections may be preserved, but changed or missing projections receive current refs/digests plus `decision_required`, no inferred Fact/support/polarity/supersession/exclusion, and stale anchors/provenance are removed. Every blocking external route must be re-authored from Source with actor Ed25519 identity assurance/public-key authority, exact target/environment/scenario/evidence/obligations and Source-backed judgment basis where applicable; migration never generates a signature. Record v1, Receipt v2 and Receipt v3 without `finalization_identity_sha256` remain audit-readable only and cannot be upgraded into acceptance. Run `upgrade --check`, repair every `manual_required` item, recompile and rerun the current Final Gate. 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.