project-tiny-context-harness 0.8.2 → 0.8.3

package/assets/agents/.gitkeep

@@ -1 +1 @@
-
+

package/assets/agents/AGENTS_CORE.md

@@ -1,70 +1,70 @@
-# Minimal Context Harness Protocol
-
-This project uses Tiny Context. The Harness maintains durable Context and workflow authority; project tests, CI, runtime evidence and human acceptance prove product quality. Its three capabilities are Minimal Context, the default Workflow Contract and the explicitly enabled Single-Goal Long-Task Workflow.
-
-## Shared Architecture Quality Obligation
-
-Every implementation delivery performs one externally observable, repository-bound `Architecture Deliberation` before the first implementation edit. Its depth is risk-proportional, but the occurrence is universal: identify affected owners and the current extension point/source of truth, dependency and state/lifecycle boundaries, the selected design and material alternatives, one plausible future-change challenge, touched technical debt and its disposition, forbidden shortcuts, and project-owned checks. A small change may conclude that existing architecture is preserved, but must name the concrete owner/extension point and why no new or worsened debt is introduced. Surface conclusions and repository evidence, not private chain-of-thought, and refresh the checkpoint if scope, ownership or the selected design materially changes.
-
-After implementation and project verification, perform one `Architecture Conformance` closure on the current candidate snapshot. The default path embeds it in Contract Conformance; an active Long-Task embeds it only in Final Gate. Never schedule both. A changed candidate invalidates the closure and must be rechecked. New or worsened debt, an undeclared second source of truth, wrong dependency direction, owner bypass, scope escape or a forbidden shortcut blocks handoff unless an explicit project-owned bounded exception records owner, rationale, tracking and removal condition. This obligation creates no plan artifact, architecture document, second Authority, workflow state or generic architecture analyzer.
-
-## Default Workflow Contract
-
-Unless an active Long-Task binding exists:
-
-1. Read `project_context/global.md`, `project_context/architecture.md`, `project_context/context.toml` and the default area root, then collect graph/trigger candidates.
-2. Before deciding `Context Delta`, run one bounded text search over `project_context/**` using a small set of high-signal task terms such as explicit area/module names and API/schema/state/security/verification/deployment terms. Merge matching Context with manifest candidates and read only relevant files; search supplements rather than replaces semantic judgment.
-3. For UI/product-surface work, confirm information/action/feedback ownership and use `context_surface_contract` when durable responsibility is unclear or changes. For material UI, reconcile affected stable surface/control/target keys as Context-covered, requiring a Context update, task-local, out of scope or decision-required; traverse owning Context and `DESIGN.md`; and open every affected selected `exact-target` or `constraint`. Missing, stale, unreadable or conflicting authority fails closed for the affected claim. Local fixes and explicit non-fidelity prototypes stay lightweight.
-4. Complete the shared `Architecture Deliberation`, then decide exactly one `Context Delta: none|required`. Update owning Context before code when durable product ownership, architecture, API/schema/data, state/recovery, dependency, security, product-surface responsibility or repeatable verification/deployment changes. Local fixes preserving durable semantics are `none`.
-5. Use the agent/platform internal plan. Keep `Architecture Context Hit`, `Decision Rationale Hit: existing|required|none` and `Modularity Check: none|required|exception` as internal routing and maintenance questions, not artifacts or extra deltas.
-6. Implement precisely, run project-owned verification, perform Contract Conformance including the shared `Architecture Conformance` and any selected-design closure below, then run the separate Context drift check. Report implementation, verification, architecture conformance, Context status and blockers. For material UI, inspect the real production entry after the first runnable vertical slice and rerun the affected cold-start journey on the final candidate; a detached route, specimen or deep link is supplemental evidence only.
-
-The default workflow never requires a plan artifact, matrix, verdict, evidence ledger or result document. Optional scratch is not Context or completion proof. The bounded Context search creates no index, cache, state or second authority.
-
-## Selected-Design Conformance Obligation
-
-This shared obligation activates only for a selected implementation handoff. Run `ty-context design-resource preflight <handoff.md>` before UI Authority Closure. A Web/App target needs one completely acquired machine-readable canonical entry and its exact dependency closure; unresolved locators/cells/meaning, unsupported evidence or stale digests fail closed. Preflight and hashes prove input completeness/integrity, never production conformance.
-
-Every adopted target has exactly one canonical record: `DESIGN.md` for project/system/component-family scope or the owning Screen Contract for one-screen/interaction scope. That record owns interpretation, selection basis, immutable locator/digest, condition coverage and editable-upstream update route; other layers keep only the stable key, owner/anchor and local applicability. Use the on-demand UIUX Skill for deterministic Design Source Projection. Never overwrite an adopted baseline; update upstream, approve a new immutable version and update the canonical record.
-
-Default work keeps one ephemeral exact accounting of covered Source Items, declared verification methods, blockers, targets and conditions. Route every applicable item to the production owner, cold-start journey and an executed final-candidate project check whose failure remains attributable; one check may cover several methods only when each method/fact can fail distinctly. A selected-target, implementation or declared check-input change stales closure. Any unresolved, unmapped, unexecuted, stale or indistinguishable item blocks a complete-conformance claim and must be reported as a gap. This creates no file, matrix, Claim set, state or Gate.
-
-Externally authored resources remain ordinary Source and exploration remains schema-free. `design-system-authoring` is explicit-only; `design-resource-authoring` keeps the requested scope ceiling and may reconcile final accepted decisions into the initial proposal once, but neither authoring path changes Context/code/Contract or claims acceptance. An active Long-Task projects this same obligation into its existing Claims, Assertions, bindings and Final Gate and never also runs the default closure. For every external product, architecture, technical or acceptance constraint, internally classify it as covered by Context, requiring a Context update, task-local, out of scope or decision-required; Conformance confirms it reached the correct owner and verification without shortcuts or duplicate authority.
-
-## Long-Task Routing
-
-Do not infer long-task mode from duration, complexity, file count or agent preference.
-
-1. A valid Git common-dir active record plus matching worktree Git-config marker resumes through `ty-context long-task resume <workdir>` and `/long-task-workflow` in the current native Goal.
-2. Explicit `/long-task-workflow` authors or resumes exactly one complete `long-task-delivery-v2` Contract for the selected delivery.
-3. `/normal-long-task` is a retirement pointer. Otherwise remain on the default Workflow Contract, even when work is long.
-
-Raw/revised proposals, selected design resources and mixed attachments enter one Source-bound Contract Draft loop immediately. Source inventory, refinement, provenance, markers and Contract mapping converge in the same non-authoritative `delivery-contract.yaml` until Preflight is ready and formal Compile creates Authority Lock; there is no prior or internal Source-authoring stage. Every non-empty line in declared Markdown Source belongs to one Material Item, the one validated formal handoff block or a closed-grammar background block containing only text-free anchors/horizontal rules or fixed-field `ty-source-provenance` comments; text-bearing headings, free-form provenance, arbitrary background prose and unclassified text fail closed unless classified as Material. At least one technical-obligation Source Item has `aspect=architecture` and maps to an independently provable architecture obligation. A legacy Source Plan remains ordinary input. Candidate resources authorize no fidelity Claim. A selected implementation handoff must pass the shared design-resource preflight; its marked residual handoff enters `task.source_paths`, its handoff and source-profile entry/dependencies enter target Check `verification_inputs`, and Long-Task Preflight/Compile requires exact target/condition/file equality, covered Source Claims, one independent positive Assertion plus typed `design_method` evidence, a distinct record path and primary-observation path/current digest for every method × condition cell, and blocker Source-item/method/capability lineage before Authority Lock. Playwright emits method evidence only when every project instance explicitly attaches both cell artifacts. After lock, resource changes use Authority Revision.
-
-When an Outcome declares Controls, all 22 canonical fields close through `field_coverage` as concrete `specified`, justified `not_applicable` or blocking `unresolved`; cross-Control/shared-state/navigation/permission/recovery meaning closes through applicability-bound `control_relation_closure` and `control_relations`, including a negative Claim when relations are not applicable. Its Product `surface_bindings` bind every Control to an owner surface, required product target, existing route/component Bindings and a root-entry success journey. Each bound Control's navigation result—or interaction, trigger or location fallback—must be proved on that target with interaction plus target-runtime evidence. Global and Outcome applicability profiles bind every Claim to its exact target, journey, atomic duplicate-free dimension assignments, Given condition/input/state refs and ordered When refs; every Claim-bearing Assertion proves one Claim in one matching profile, and every actual applicable proof-surface cell is covered without representative/pairwise sampling. Required product targets declare their family, cold-start and production-root capabilities. Selected exact/constraint targets additionally bind declared conditions and frozen inputs to current actual/comparison artifacts through `design_conformance`; `verification_method_bindings` map every handoff method to a separate positive Assertion, typed method record and distinct record/primary-observation artifacts whose current primary identities cannot be reused across cells. Every behavioral Claim-bearing Assertion has a same-Check claim-local `replace_json_value` or `replace_text` Counterfactual and a claimless target-runtime liveness Assertion that must remain passing; whole-file replacement cannot prove semantic binding. Population binds its universe carrier into the owning Check input snapshot and proves universe = eligible = observed plus valid exclusions. Every declared design-acceptance blocker preserves exact Source-item/method/required-capability provenance and resolves to a machine Claim proved on the exact capability-qualified target or a target-blocking External Confirmation; it cannot be dismissed in-band, and scope removal requires revised Source/Contract authority. These are protected Contract semantics, not a UI registry, second Gate or per-surface state.
-
+# Minimal Context Harness Protocol
+
+This project uses Tiny Context. The Harness maintains durable Context and workflow authority; project tests, CI, runtime evidence and human acceptance prove product quality. Its three capabilities are Minimal Context, the default Workflow Contract and the explicitly enabled Single-Goal Long-Task Workflow.
+
+## Shared Architecture Quality Obligation
+
+Every implementation delivery performs one externally observable, repository-bound `Architecture Deliberation` before the first implementation edit. Its depth is risk-proportional, but the occurrence is universal: identify affected owners and the current extension point/source of truth, dependency and state/lifecycle boundaries, the selected design and material alternatives, one plausible future-change challenge, touched technical debt and its disposition, forbidden shortcuts, and project-owned checks. A small change may conclude that existing architecture is preserved, but must name the concrete owner/extension point and why no new or worsened debt is introduced. Surface conclusions and repository evidence, not private chain-of-thought, and refresh the checkpoint if scope, ownership or the selected design materially changes.
+
+After implementation and project verification, perform one `Architecture Conformance` closure on the current candidate snapshot. The default path embeds it in Contract Conformance; an active Long-Task embeds it only in Final Gate. Never schedule both. A changed candidate invalidates the closure and must be rechecked. New or worsened debt, an undeclared second source of truth, wrong dependency direction, owner bypass, scope escape or a forbidden shortcut blocks handoff unless an explicit project-owned bounded exception records owner, rationale, tracking and removal condition. This obligation creates no plan artifact, architecture document, second Authority, workflow state or generic architecture analyzer.
+
+## Default Workflow Contract
+
+Unless an active Long-Task binding exists:
+
+1. Read `project_context/global.md`, `project_context/architecture.md`, `project_context/context.toml` and the default area root, then collect graph/trigger candidates.
+2. Before deciding `Context Delta`, run one bounded text search over `project_context/**` using a small set of high-signal task terms such as explicit area/module names and API/schema/state/security/verification/deployment terms. Merge matching Context with manifest candidates and read only relevant files; search supplements rather than replaces semantic judgment.
+3. For UI/product-surface work, confirm information/action/feedback ownership and use `context_surface_contract` when durable responsibility is unclear or changes. For material UI, reconcile affected stable surface/control/target keys as Context-covered, requiring a Context update, task-local, out of scope or decision-required; traverse owning Context and `DESIGN.md`; and open every affected selected `exact-target` or `constraint`. Missing, stale, unreadable or conflicting authority fails closed for the affected claim. Local fixes and explicit non-fidelity prototypes stay lightweight.
+4. Complete the shared `Architecture Deliberation`, then decide exactly one `Context Delta: none|required`. Update owning Context before code when durable product ownership, architecture, API/schema/data, state/recovery, dependency, security, product-surface responsibility or repeatable verification/deployment changes. Local fixes preserving durable semantics are `none`.
+5. Use the agent/platform internal plan. Keep `Architecture Context Hit`, `Decision Rationale Hit: existing|required|none` and `Modularity Check: none|required|exception` as internal routing and maintenance questions, not artifacts or extra deltas.
+6. Implement precisely, run project-owned verification, perform Contract Conformance including the shared `Architecture Conformance` and any selected-design closure below, then run the separate Context drift check. Report implementation, verification, architecture conformance, Context status and blockers. For material UI, inspect the real production entry after the first runnable vertical slice and rerun the affected cold-start journey on the final candidate; a detached route, specimen or deep link is supplemental evidence only.
+
+The default workflow never requires a plan artifact, matrix, verdict, evidence ledger or result document. Optional scratch is not Context or completion proof. The bounded Context search creates no index, cache, state or second authority.
+
+## Selected-Design Conformance Obligation
+
+This shared obligation activates only for a selected implementation handoff. Run `ty-context design-resource preflight <handoff.md>` before UI Authority Closure. A Web/App target needs one completely acquired machine-readable canonical entry and its exact dependency closure. The handoff must inventory every in-scope observable fact exposed by the acquired resources and declared inspector/oracle capability, close every resource as material-with-facts or honestly supporting-only, and bind every coverage row to the exact fact/evidence/Source/method sets. Product Control granularity is not the design-fact ceiling. An exact target additionally needs full-target layout and pixel facts for every condition; partial input remains a constraint or blocking unresolved. Unresolved locators/cells/facts/meaning, unsupported evidence or stale digests fail closed. Preflight and hashes prove input completeness/integrity, never production conformance.
+
+Every adopted target has exactly one canonical record: `DESIGN.md` for project/system/component-family scope or the owning Screen Contract for one-screen/interaction scope. That record owns interpretation, selection basis, immutable locator/digest, condition coverage and editable-upstream update route; other layers keep only the stable key, owner/anchor and local applicability. Use the on-demand UIUX Skill for deterministic Design Source Projection. Never overwrite an adopted baseline; update upstream, approve a new immutable version and update the canonical record.
+
+Default work keeps one ephemeral exact accounting of covered facts, Source Items, declared verification methods, blockers, targets and conditions. Route every applicable item to the production owner, cold-start journey and an executed final-candidate project check whose failure remains attributable; one check may cover several methods only when each method/fact can fail distinctly. A selected-target, fact inventory, implementation or declared check-input change stales closure. Any unresolved, unmapped, unexecuted, stale or indistinguishable item blocks a complete-conformance claim and must be reported as a gap; this explicitly includes every unread, unsupported or unimplemented applicable design fact. This creates no file, matrix, Claim set, state or Gate.
+
+Externally authored resources remain ordinary Source and exploration remains schema-free. `design-system-authoring` is explicit-only; `design-resource-authoring` keeps the requested scope ceiling and may reconcile final accepted decisions into the initial proposal once, but neither authoring path changes Context/code/Contract or claims acceptance. An active Long-Task projects this same obligation into its existing Claims, Assertions, bindings and Final Gate and never also runs the default closure. For every external product, architecture, technical or acceptance constraint, internally classify it as covered by Context, requiring a Context update, task-local, out of scope or decision-required; Conformance confirms it reached the correct owner and verification without shortcuts or duplicate authority.
+
+## Long-Task Routing
+
+Do not infer long-task mode from duration, complexity, file count or agent preference.
+
+1. A valid Git common-dir active record plus matching worktree Git-config marker resumes through `ty-context long-task resume <workdir>` and `/long-task-workflow` in the current native Goal.
+2. Explicit `/long-task-workflow` authors or resumes exactly one complete `long-task-delivery-v2` Contract for the selected delivery.
+3. `/normal-long-task` is a retirement pointer. Otherwise remain on the default Workflow Contract, even when work is long.
+
+Raw/revised proposals, selected design resources and mixed attachments enter one Source-bound Contract Draft loop immediately. Source inventory, refinement, provenance, markers and Contract mapping converge in the same non-authoritative `delivery-contract.yaml` until Preflight is ready and formal Compile creates Authority Lock; there is no prior or internal Source-authoring stage. Every non-empty line in declared Markdown Source belongs to one Material Item, the one validated formal handoff block or a closed-grammar background block containing only text-free anchors/horizontal rules or fixed-field `ty-source-provenance` comments; text-bearing headings, free-form provenance, arbitrary background prose and unclassified text fail closed unless classified as Material. At least one technical-obligation Source Item has `aspect=architecture` and maps to an independently provable architecture obligation. A legacy Source Plan remains ordinary input. Candidate resources authorize no fidelity Claim. A selected implementation handoff must pass the shared design-resource preflight; its marked residual handoff enters `task.source_paths`, its handoff and source-profile entry/dependencies enter target Check `verification_inputs`, and Long-Task Preflight/Compile requires exact target/condition/file equality, complete fact/resource closure, covered Source Claims, one independent positive Assertion plus typed `design_method` evidence, exact `fact_refs`, a distinct record path and primary-observation path/current digest for every method × condition cell, and blocker Source-item/method/capability lineage before Authority Lock. Playwright emits method evidence only when every project instance explicitly attaches both cell artifacts, and runtime fact refs must equal the compiled cell. After lock, resource changes use Authority Revision.
+
+When an Outcome declares Controls, all 22 canonical fields close through `field_coverage` as concrete `specified`, justified `not_applicable` or blocking `unresolved`; cross-Control/shared-state/navigation/permission/recovery meaning closes through applicability-bound `control_relation_closure` and `control_relations`, including a negative Claim when relations are not applicable. Its Product `surface_bindings` bind every Control to an owner surface, required product target, existing route/component Bindings and a root-entry success journey. Each bound Control's navigation result—or interaction, trigger or location fallback—must be proved on that target with interaction plus target-runtime evidence. Global and Outcome applicability profiles bind every Claim to its exact target, journey, atomic duplicate-free dimension assignments, Given condition/input/state refs and ordered When refs; every Claim-bearing Assertion proves one Claim in one matching profile, and every actual applicable proof-surface cell is covered without representative/pairwise sampling. Required product targets declare their family, cold-start and production-root capabilities. Selected exact/constraint targets additionally bind declared conditions and frozen inputs to current actual/comparison artifacts through `design_conformance`; `verification_method_bindings` map every handoff method to a separate positive Assertion, the exact facts for each method × condition cell, typed method record and distinct record/primary-observation artifacts whose current primary identities cannot be reused across cells. The union of compiled cells equals the target's complete handoff fact set; runtime `design_method` records repeat the exact `fact_refs`. Every behavioral Claim-bearing Assertion has a same-Check claim-local `replace_json_value` or `replace_text` Counterfactual and a claimless target-runtime liveness Assertion that must remain passing; whole-file replacement cannot prove semantic binding. Population binds its universe carrier into the owning Check input snapshot and proves universe = eligible = observed plus valid exclusions. Every declared design-acceptance blocker preserves exact Source-item/method/required-capability provenance and resolves to a machine Claim proved on the exact capability-qualified target or a target-blocking External Confirmation; it cannot be dismissed in-band, and scope removal requires revised Source/Contract authority. These are protected Contract semantics, not a UI registry, second Gate or per-surface state.
+
 The workflow uses one native Goal, one selected verification workspace, one Contract and one Final Gate. New authoring uses inline vertical Outcomes grouped by ordered Stages; existing `outcome_files` are physical compatibility only. New authority uses explicit `context_snapshot_mode: full`. Target profiles name required product targets, root runtimes and capabilities; Checks declare Given/When journeys and all-of Evidence Capabilities. Compile freezes declared verification inputs plus the supported direct-literal local verifier module/config/data graph; Check inputs/outputs/artifacts remain explicitly classified runtime material, non-literal loaders fail closed, and other indirect runtime access belongs in `verification_inputs` or the named project Oracle TCB. Stage/frontier state is derived from ordinary Progress and creates no implementation gate, second Gate, Receipt, scheduler or completion authority. `F = Implementation Freedom Boundary` keeps implementation order, local planning, methods, repair/feedback cadence and optional use of one or multiple platform-native agents/subagents Goal-owned within Source/Contract, architecture, safety, forbidden-shortcut and irreversible/external-action boundaries. Harness creates no development phase/method Gate, per-edit mandate, agent allocator/scheduler, delegation state or proof; agent reports are non-authoritative and all outputs converge into the selected workspace. Anti-Degradation Assurance requires current-implementation Context to match indexed code/runtime and keeps the controlling purpose, enabling key logic, two necessary implementation responsibilities, theorem boundary and adjacent `F` protected from implicit weakening. Replacing one requires an explicit project-owner design-purpose decision and replacement proof; a new development-stage constraint must additionally close a distinct path that final proof or a lighter project check cannot cover and have positive net ROI. Mechanism changes first prove `Coverage_new ⊇ Coverage_old`, `FalseNegative_new ⊆ FalseNegative_old` and non-bypassable Authority/fail-closed/final-snapshot proof; otherwise preserve the current formal acceptance path. Only after that hard gate may positive net ROI compare anti-degradation or purpose benefit with all incremental authoring/runtime/state/recovery/maintenance/test/process/introduction/migration cost, and cost never compensates for weaker drift interception. This is project governance and verification, not another Authority, Gate or state.
-
-After the first Authority Lock, treat `execution_model_checkpoint.required: true` as a terminal-turn boundary. Unless the user already stated an explicit task-specific choice naming current-model continuation or a model switch, end the current turn before product implementation, file edits, builds or tests and ask the user to choose `continue_current_model` or switch models and then resume. Generic continue/resume/finish/continue-goal language does not satisfy the checkpoint; later revisions do not repeat it. Harness records no model route or checkpoint acknowledgement state.
-
-During Draft authoring, proof design or authority lifecycle work, read the applicable references in the package-managed `long-task-workflow` Skill. Use `ty-context long-task help` for CLI syntax instead of treating this startup router as a command reference. Before first Authority Lock, Preflight and Compile classify current HEAD-relative workspace changes against protected paths and declared expected/support ownership; after lock, Verify and Final Gate apply the same fail-closed categories against the immutable baseline. 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 exempt.
-
-Final Gate, Stop and close first reject stale accepted authority inputs, recompile the source Contract and rerun every declared Check on one clean current snapshot. Final Gate records the semantic and raw identity of the Contract/fragments, Source, full Controlling Context, verifier/runner, recursively frozen local verifier dependencies, verification inputs and workdir inputs before execution, then recompiles and re-hashes that full protected set afterward; any race fails closed. Final Gate is the Long-Task path's sole `Architecture Conformance` and selected-design closure owner; do not run either default-workflow closure. Required targets cannot substitute for one another; presence cannot prove behavior; resource integrity or `visual_render` cannot substitute for selected-target `design_conformance`; success and degradation remain distinct; typed boundary effects require an observer; unresolved design blockers remain blocking. `verify --explain` is a read-only declared-execution preview and creates no proof or Progress. Targeted verify is optional repair feedback only; `progress_stale` is a freshness fact, not a per-edit rerun instruction. Coalesce related edits and refresh the cheapest reliable owning Check only before intermediate reliance; implementation and Final Gate may proceed because Final Gate ignores Progress and reruns all Checks. Status, progress, Stage/frontier projections, receipts and compiled cache are audit/recovery surfaces only; prose, historical tests or Agent judgment never create acceptance. Authority Revision separates authority change from user decision: mechanically bounded revisions may auto-adopt but still invalidate affected evidence; semantic/proof/forbidden-boundary/verifier-kernel changes and unknown reasons require one exact decision. Present the self-contained brief first. If an explicit current task instruction exactly covers every listed reason, mechanically relay it without a second question; generic continuation, blanket authorization, recommendation or Agent inference never qualifies. Coalesce withdrawn candidates and ask only for the final blocking identity. An adopted revision returns to rolling execution and is never delivery completion. External confirmations remain typed and explicit: exactly fresh `machine_accepted` with no pending confirmation is the complete-delivery accepted terminal covered by the full no-drift implication; `machine_accepted_external_pending` proves only the declared machine scope and cannot authorize completing the platform-native Goal, CI, deployment or human acceptance. The theorem remains conditional on complete/accurate declared Source and a semantically sound named project oracle; Harness/runtime packages and Git metadata are explicit trusted-computing-boundary components.
-
-Tiny Context does not create or restore platform Goals, invoke models, spawn agents, call an App Server, create branches/worktrees, merge, push, open PRs, deploy or manage process trees. `ty-context enable long-task` installs the Long-Task Workflow Skill, the retired Source Plan compatibility pointer and package-owned completion Hook.
-
-## Durable Facts And Generated Surfaces
-
-- Context is intended ownership/boundary/contract truth; code is current implementation truth. Treat disagreement as drift, missing work or stale Context.
-- Long-term facts live only in `project_context/**` or `DESIGN.md`; adopted decision-relevant design targets remain Context-reachable project Source/verifier inputs through stable keys and exactly one canonical adoption record rather than becoming Context themselves. Generated implementation screenshots/diffs, logs, raw evidence, secrets, runtime state and receipts do not become Context.
-- Managed `AGENTS.md` blocks, `<harnessRoot>/ty-context-managed/**` and package-managed Skills are generated and sync-overwritten.
-- Explicit upgrades use `context_harness_upgrade`; package sync never imports retired Campaign or development-period authority state.
-
-## Verification
-
-- `make validate-context`: Context recoverability.
-- `make validate-harness`: Context plus touched-source modularity.
-- `ty-context doctor`: installation health plus advisory default Context footprint and Design Authority status.
-- `node packages/ty-context/dist/cli.js package check-source`: managed-source/package parity in this source workspace.
-
-Every handoff reports exactly one of `Context: updated ...` or `Context: no durable fact change`. Never claim tests, deployment or acceptance from Context alone.
+
+After the first Authority Lock, treat `execution_model_checkpoint.required: true` as a terminal-turn boundary. Unless the user already stated an explicit task-specific choice naming current-model continuation or a model switch, end the current turn before product implementation, file edits, builds or tests and ask the user to choose `continue_current_model` or switch models and then resume. Generic continue/resume/finish/continue-goal language does not satisfy the checkpoint; later revisions do not repeat it. Harness records no model route or checkpoint acknowledgement state.
+
+During Draft authoring, proof design or authority lifecycle work, read the applicable references in the package-managed `long-task-workflow` Skill. Use `ty-context long-task help` for CLI syntax instead of treating this startup router as a command reference. Before first Authority Lock, Preflight and Compile classify current HEAD-relative workspace changes against protected paths and declared expected/support ownership; after lock, Verify and Final Gate apply the same fail-closed categories against the immutable baseline. 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 exempt.
+
+Final Gate, Stop and close first reject stale accepted authority inputs, recompile the source Contract and rerun every declared Check on one clean current snapshot. Final Gate records the semantic and raw identity of the Contract/fragments, Source, full Controlling Context, verifier/runner, recursively frozen local verifier dependencies, verification inputs and workdir inputs before execution, then recompiles and re-hashes that full protected set afterward; any race fails closed. Final Gate is the Long-Task path's sole `Architecture Conformance` and selected-design closure owner; do not run either default-workflow closure. Required targets cannot substitute for one another; presence cannot prove behavior; resource integrity or `visual_render` cannot substitute for selected-target `design_conformance`; omitted/substituted design `fact_refs` cannot be hidden by passing artifacts; success and degradation remain distinct; typed boundary effects require an observer; unresolved design blockers remain blocking. `verify --explain` is a read-only declared-execution preview and creates no proof or Progress. Targeted verify is optional repair feedback only; `progress_stale` is a freshness fact, not a per-edit rerun instruction. Coalesce related edits and refresh the cheapest reliable owning Check only before intermediate reliance; implementation and Final Gate may proceed because Final Gate ignores Progress and reruns all Checks. Status, progress, Stage/frontier projections, receipts and compiled cache are audit/recovery surfaces only; prose, historical tests or Agent judgment never create acceptance. Authority Revision separates authority change from user decision: mechanically bounded revisions may auto-adopt but still invalidate affected evidence; semantic/proof/forbidden-boundary/verifier-kernel changes and unknown reasons require one exact decision. Present the self-contained brief first. If an explicit current task instruction exactly covers every listed reason, mechanically relay it without a second question; generic continuation, blanket authorization, recommendation or Agent inference never qualifies. Coalesce withdrawn candidates and ask only for the final blocking identity. An adopted revision returns to rolling execution and is never delivery completion. External confirmations remain typed and explicit: exactly fresh `machine_accepted` with no pending confirmation is the complete-delivery accepted terminal covered by the full no-drift implication; `machine_accepted_external_pending` proves only the declared machine scope and cannot authorize completing the platform-native Goal, CI, deployment or human acceptance. The theorem remains conditional on complete/accurate declared Source and a semantically sound named project oracle; unsupported resource extraction remains blocking, and Harness/runtime packages and Git metadata are explicit trusted-computing-boundary components.
+
+Tiny Context does not create or restore platform Goals, invoke models, spawn agents, call an App Server, create branches/worktrees, merge, push, open PRs, deploy or manage process trees. `ty-context enable long-task` installs the Long-Task Workflow Skill, the retired Source Plan compatibility pointer and package-owned completion Hook.
+
+## Durable Facts And Generated Surfaces
+
+- Context is intended ownership/boundary/contract truth; code is current implementation truth. Treat disagreement as drift, missing work or stale Context.
+- Long-term facts live only in `project_context/**` or `DESIGN.md`; adopted decision-relevant design targets remain Context-reachable project Source/verifier inputs through stable keys and exactly one canonical adoption record rather than becoming Context themselves. Generated implementation screenshots/diffs, logs, raw evidence, secrets, runtime state and receipts do not become Context.
+- Managed `AGENTS.md` blocks, `<harnessRoot>/ty-context-managed/**` and package-managed Skills are generated and sync-overwritten.
+- Explicit upgrades use `context_harness_upgrade`; package sync never imports retired Campaign or development-period authority state.
+
+## Verification
+
+- `make validate-context`: Context recoverability.
+- `make validate-harness`: Context plus touched-source modularity.
+- `ty-context doctor`: installation health plus advisory default Context footprint and Design Authority status.
+- `node packages/ty-context/dist/cli.js package check-source`: managed-source/package parity in this source workspace.
+
+Every handoff reports exactly one of `Context: updated ...` or `Context: no durable fact change`. Never claim tests, deployment or acceptance from Context alone.

package/assets/context_templates/architecture.md

@@ -1,33 +1,33 @@
-# Architecture Context
-
-This is the restrained architecture context. Keep only facts that help a fresh agent recover system shape, boundaries and durable constraints quickly.
-
-## System Boundary
-
-- Describe what is inside this project and what external systems, providers or runtime assumptions sit outside it.
-
-## Component Map
-
-- List the smallest useful set of components, areas or context units and how they relate.
-
-## Data / Control Flow
-
-- Summarize only the durable request, event, state or data flow that is hard to infer from code alone.
-
+# Architecture Context
+
+This is the restrained architecture context. Keep only facts that help a fresh agent recover system shape, boundaries and durable constraints quickly.
+
+## System Boundary
+
+- Describe what is inside this project and what external systems, providers or runtime assumptions sit outside it.
+
+## Component Map
+
+- List the smallest useful set of components, areas or context units and how they relate.
+
+## Data / Control Flow
+
+- Summarize only the durable request, event, state or data flow that is hard to infer from code alone.
+
 ## Design Rationale
 
 - Record architecture-level choices, rejected alternatives and tradeoffs that still constrain future work; leave this empty when no stable architecture reason exists.
 - Do not invent rationale or store implementation summaries, PR notes, command output, test result claims, debug history, agent reasoning or reasons inferred only from current code shape.
 - Architecture boundary changes should be captured here before implementation alignment.
-
-## Constraints And Tradeoffs
-
-- Capture performance, safety, integration, deployment or maintainability constraints that matter for future changes.
-
-## Verification Implications
-
-- List project-specific verification entry points affected by architectural changes; do not claim tests already passed.
-
-## Open Risks
-
-- List unresolved architectural risks or unknowns.
+
+## Constraints And Tradeoffs
+
+- Capture performance, safety, integration, deployment or maintainability constraints that matter for future changes.
+
+## Verification Implications
+
+- List project-specific verification entry points affected by architectural changes; do not claim tests already passed.
+
+## Open Risks
+
+- List unresolved architectural risks or unknowns.

package/assets/context_templates/area.md

@@ -1,39 +1,39 @@
-# Area Context: main
-
-## Responsibility
-
-- Describe this product/domain area or context unit's responsibility.
-
-## User / System Contract
-
-- Describe the external behavior, API, CLI, UI, screen state, interaction or data contract. Contract changes should be captured here before implementation alignment.
-- For UI/page areas, name the page responsibility, core user judgment, persistent information/actions/feedback, non-persistent information, and what belongs in downstream consumption, ops, detail or other surfaces when those facts are durable.
-
-## Core Data / API / State
-
-- Summarize important data structures, APIs, state transitions or rules.
-
-## Module Design Capsule
-
+# Area Context: main
+
+## Responsibility
+
+- Describe this product/domain area or context unit's responsibility.
+
+## User / System Contract
+
+- Describe the external behavior, API, CLI, UI, screen state, interaction or data contract. Contract changes should be captured here before implementation alignment.
+- For UI/page areas, name the page responsibility, core user judgment, persistent information/actions/feedback, non-persistent information, and what belongs in downstream consumption, ops, detail or other surfaces when those facts are durable.
+
+## Core Data / API / State
+
+- Summarize important data structures, APIs, state transitions or rules.
+
+## Module Design Capsule
+
 - Principles: stable execution constraints that should affect future module work.
 - Design Logic: the minimum logic for choosing, rejecting, degrading or composing module behavior.
 - Design Rationale: only durable reasons, rejected alternatives and tradeoffs that change later implementation or verification decisions; leave it empty when no stable reason exists.
 - Do not invent rationale or store implementation summaries, PR notes, command output, test result claims, screenshot review notes, debug history, agent reasoning or reasons inferred only from current code shape.
 - Current standards, thresholds and commands belong in the relevant contract or verification Context, not as permanent principles.
-
-## Key Constraints
-
-- List constraints that are not obvious from code alone, including product rules, responsive/a11y needs or visual boundaries.
-
-## Code Entry Points
-
-- `src/` or the concrete file/function entry points.
-
-## Related Role Context
-
-- Verification paths live in this area's `verification` role Context, such as `project_context/areas/main/verification.md`.
-- Deployment/runtime/bootstrap paths live in this area's optional `deployment` role Context when those facts exist.
-
-## Open Risks
-
-- List unresolved risks or blockers.
+
+## Key Constraints
+
+- List constraints that are not obvious from code alone, including product rules, responsive/a11y needs or visual boundaries.
+
+## Code Entry Points
+
+- `src/` or the concrete file/function entry points.
+
+## Related Role Context
+
+- Verification paths live in this area's `verification` role Context, such as `project_context/areas/main/verification.md`.
+- Deployment/runtime/bootstrap paths live in this area's optional `deployment` role Context when those facts exist.
+
+## Open Risks
+
+- List unresolved risks or blockers.

package/assets/context_templates/context.toml

@@ -1,30 +1,30 @@
-# Schema v4 Minimal Context graph manifest.
-# Keep the default product/domain area for ordinary projects. Role context nodes
-# are read-purpose slices owned by an area or, only when cross-domain, by the project root.
-# Use read_policy = "default" only for near-universal recovery facts; prefer
-# "on-demand" for specialized architecture, contract, deployment or history detail.
-# `ty-context doctor` reports the deterministic default read footprint and exact duplicates.
-# When migrating deep files under project_context/areas/**, refine obvious
-# contract/foundation/subdomain/verification/deployment/implementation-index/
-# decision-rationale/archive files into [[context]] entries instead of keeping
-# every Markdown file as an [[areas]] product owner.
-
-[[areas]]
-id = "main"
-root = "."
-context = "project_context/areas/main.md"
-kind = "app"
-default = true
-
-[[context]]
-path = "project_context/areas/main/verification.md"
-role = "verification"
-read_policy = "default"
-triggers = ["test", "verify", "verification", "smoke", "ci"]
-
-# Example optional node:
-# [[context]]
-# path = "project_context/areas/main/deployment.md"
-# role = "deployment"
-# read_policy = "on-demand"
-# triggers = ["deploy", "deployment", "runtime", "cloud", "docker"]
+# Schema v4 Minimal Context graph manifest.
+# Keep the default product/domain area for ordinary projects. Role context nodes
+# are read-purpose slices owned by an area or, only when cross-domain, by the project root.
+# Use read_policy = "default" only for near-universal recovery facts; prefer
+# "on-demand" for specialized architecture, contract, deployment or history detail.
+# `ty-context doctor` reports the deterministic default read footprint and exact duplicates.
+# When migrating deep files under project_context/areas/**, refine obvious
+# contract/foundation/subdomain/verification/deployment/implementation-index/
+# decision-rationale/archive files into [[context]] entries instead of keeping
+# every Markdown file as an [[areas]] product owner.
+
+[[areas]]
+id = "main"
+root = "."
+context = "project_context/areas/main.md"
+kind = "app"
+default = true
+
+[[context]]
+path = "project_context/areas/main/verification.md"
+role = "verification"
+read_policy = "default"
+triggers = ["test", "verify", "verification", "smoke", "ci"]
+
+# Example optional node:
+# [[context]]
+# path = "project_context/areas/main/deployment.md"
+# role = "deployment"
+# read_policy = "on-demand"
+# triggers = ["deploy", "deployment", "runtime", "cloud", "docker"]

package/assets/context_templates/deployment.md

@@ -1,35 +1,35 @@
-# Deployment Context: main
-
-This optional role Context records critical repeat-execution paths for deploy, runtime bootstrap, cloud initialization and operational recovery. Keep it minimal and durable.
-
-## Owner
-
-- Owning area: `main`.
-
-## Runtime Topology
-
-- List durable service distribution only when it matters for rerunning deploy or bootstrap, such as Web/API/worker/Redis/DB/Docker/cloud instance boundaries.
-
-## Deployment Paths
-
-- List the shortest deploy, CI/CD, bootstrap, migration, health-check or rollback/degradation command/path.
-
-## Required Preparation
-
-- List only durable setup such as cloud resources, env files, compose profiles, secret mounting names or database initialization steps. Do not store secret values.
-
-## Expected Signals
-
-- Name health checks, status transitions, URLs, queues, containers or logs-at-a-glance that show the path reached the intended stage.
-
-## Acceptable Warnings
-
-- List known benign warnings or slow-start states.
-
-## Excluded Dead Ends
-
-- List previously ruled-out deploy/bootstrap paths only when remembering them prevents repeated wasted work.
-
-## Forbidden Content
-
-- Do not record one-off logs, full command output, CI artifacts, release ledgers, secrets, tokens, cookies, device ids, raw payloads or claims that deployment already succeeded.
+# Deployment Context: main
+
+This optional role Context records critical repeat-execution paths for deploy, runtime bootstrap, cloud initialization and operational recovery. Keep it minimal and durable.
+
+## Owner
+
+- Owning area: `main`.
+
+## Runtime Topology
+
+- List durable service distribution only when it matters for rerunning deploy or bootstrap, such as Web/API/worker/Redis/DB/Docker/cloud instance boundaries.
+
+## Deployment Paths
+
+- List the shortest deploy, CI/CD, bootstrap, migration, health-check or rollback/degradation command/path.
+
+## Required Preparation
+
+- List only durable setup such as cloud resources, env files, compose profiles, secret mounting names or database initialization steps. Do not store secret values.
+
+## Expected Signals
+
+- Name health checks, status transitions, URLs, queues, containers or logs-at-a-glance that show the path reached the intended stage.
+
+## Acceptable Warnings
+
+- List known benign warnings or slow-start states.
+
+## Excluded Dead Ends
+
+- List previously ruled-out deploy/bootstrap paths only when remembering them prevents repeated wasted work.
+
+## Forbidden Content
+
+- Do not record one-off logs, full command output, CI artifacts, release ledgers, secrets, tokens, cookies, device ids, raw payloads or claims that deployment already succeeded.

package/assets/context_templates/global.md

@@ -1,57 +1,57 @@
-# Project / Delivery Context
-
-## Project Goal
-
-- Describe the user-visible goal this project is trying to achieve.
-
-## Non-goals / Boundaries
-
-- List what this project intentionally does not do.
-
-## Background
-
-- Capture only near-universal background a fresh agent needs before changing code. Route specialized facts through on-demand role Context instead of copying them here.
-
-## Design Rationale
-
-- Record only project-wide durable choices, rejected alternatives and tradeoffs that are hard to infer from code or tests and likely to affect future work. Leave this sparse when no stable reason exists.
-- Do not invent rationale or store implementation summaries, PR notes, command output, test result claims, screenshot review notes, debug history, agent reasoning or reasons inferred only from current code shape.
-- Classify changes before implementation; if a change alters product ownership/plans, module responsibilities, information architecture, API/Schema, state/scheduler semantics, cross-area boundaries, verification role paths or deployment role paths, update Context before code with enough durable context to guide implementation.
-
-## Architecture Context
-
-- Link to `project_context/architecture.md`; keep architecture notes minimal and focused on boundaries, components and constraints that are not obvious from code.
-
-## Context Graph
-
-- Link to `project_context/context.toml` and keep its default area, role, trigger, read policy and boundary metadata aligned with this Context.
-- When adding or reorganizing files under `project_context/areas/**`, run a soft role placement scan before registering every Markdown file as an area: product ownership stays in `area` / `domain` / `subdomain`; contracts, foundations, verification, deployment, implementation indexes, decision rationale and archives should use role Context when that better fits the reading purpose.
-
-## Product / Delivery Brief
-
-- Capture durable product goals, users, core flows, acceptance signals and non-goals.
-
-## UX / Screen Brief
-
-- Capture durable screen, flow, interaction, responsive and accessibility facts. Use `DESIGN.md` for visual identity and design tokens when needed.
-- For web/front-end surfaces, record durable page responsibilities, core user judgments, persistent information boundaries and cross-page or cross-layer ownership when they guide future changes.
-- Reference durable versioned design targets at their project-native path or URI and classify them as `exact-target`, `constraint` or `inspiration`; do not paste generated implementation screenshots, diffs or review logs into Context.
-- When selected resources arrive through a validated `design-resource-handoff-v1`, keep only durable surface/control/target ownership and a route to its immutable Source here. Do not copy the handoff's condition/evidence/coverage index into Context; future work must open the handoff and affected exact/constraint resources and rerun shared preflight before fidelity implementation.
-
-## Verification Entry Points
-
-- Point to the default verification context for repeatable test, smoke, CI or validation paths.
-- Project-level cross-domain verification may live here only as a short index; execution details belong in `verification` role Context.
-
-## Current State
-
-- Summarize what is implemented, blocked or risky right now.
-
-## Next Safe Action
-
-- State the safest next step for a fresh agent, including whether the next change should update Context before code.
-
-## Context Index
-
-- [main](areas/main.md)
-- [main verification](areas/main/verification.md)
+# Project / Delivery Context
+
+## Project Goal
+
+- Describe the user-visible goal this project is trying to achieve.
+
+## Non-goals / Boundaries
+
+- List what this project intentionally does not do.
+
+## Background
+
+- Capture only near-universal background a fresh agent needs before changing code. Route specialized facts through on-demand role Context instead of copying them here.
+
+## Design Rationale
+
+- Record only project-wide durable choices, rejected alternatives and tradeoffs that are hard to infer from code or tests and likely to affect future work. Leave this sparse when no stable reason exists.
+- Do not invent rationale or store implementation summaries, PR notes, command output, test result claims, screenshot review notes, debug history, agent reasoning or reasons inferred only from current code shape.
+- Classify changes before implementation; if a change alters product ownership/plans, module responsibilities, information architecture, API/Schema, state/scheduler semantics, cross-area boundaries, verification role paths or deployment role paths, update Context before code with enough durable context to guide implementation.
+
+## Architecture Context
+
+- Link to `project_context/architecture.md`; keep architecture notes minimal and focused on boundaries, components and constraints that are not obvious from code.
+
+## Context Graph
+
+- Link to `project_context/context.toml` and keep its default area, role, trigger, read policy and boundary metadata aligned with this Context.
+- When adding or reorganizing files under `project_context/areas/**`, run a soft role placement scan before registering every Markdown file as an area: product ownership stays in `area` / `domain` / `subdomain`; contracts, foundations, verification, deployment, implementation indexes, decision rationale and archives should use role Context when that better fits the reading purpose.
+
+## Product / Delivery Brief
+
+- Capture durable product goals, users, core flows, acceptance signals and non-goals.
+
+## UX / Screen Brief
+
+- Capture durable screen, flow, interaction, responsive and accessibility facts. Use `DESIGN.md` for visual identity and design tokens when needed.
+- For web/front-end surfaces, record durable page responsibilities, core user judgments, persistent information boundaries and cross-page or cross-layer ownership when they guide future changes.
+- Reference durable versioned design targets at their project-native path or URI and classify them as `exact-target`, `constraint` or `inspiration`; do not paste generated implementation screenshots, diffs or review logs into Context.
+- When selected resources arrive through a validated `design-resource-handoff-v1`, keep only durable surface/control/target ownership and a route to its immutable Source here. Do not copy the handoff's condition/evidence/coverage index into Context; future work must open the handoff and affected exact/constraint resources and rerun shared preflight before fidelity implementation.
+
+## Verification Entry Points
+
+- Point to the default verification context for repeatable test, smoke, CI or validation paths.
+- Project-level cross-domain verification may live here only as a short index; execution details belong in `verification` role Context.
+
+## Current State
+
+- Summarize what is implemented, blocked or risky right now.
+
+## Next Safe Action
+
+- State the safest next step for a fresh agent, including whether the next change should update Context before code.
+
+## Context Index
+
+- [main](areas/main.md)
+- [main verification](areas/main/verification.md)