project-tiny-context-harness 0.8.4 → 0.8.5

package/assets/agents/.gitkeep

@@ -1 +1 @@
-
+

package/assets/agents/AGENTS_CORE.md

@@ -1,62 +1,81 @@
 # 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.
+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 automatically applicable default Workflow Contract and the explicitly selected 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.
+Before the first implementation edit, every delivery surfaces one externally observable, repository-bound `Architecture Deliberation`. Depth is risk-proportional, but the checkpoint always names affected owners, 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 record preservation, but it still names the concrete owner/extension point and why no new or worsened debt is introduced. Refresh the checkpoint when scope, ownership or 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.
+After implementation and project verification, perform one current-candidate `Architecture Conformance`. Default work embeds it in Contract Conformance; an active Long-Task embeds it only in Final Gate. Never schedule both, and recheck after any candidate change. New/worsened debt, a duplicate source of truth, wrong dependency direction, owner bypass, scope escape or a forbidden shortcut blocks handoff unless a bounded project-owned exception records owner, rationale, tracking and removal condition. This creates no architecture artifact, second Authority, workflow state or generic analyzer.
 
 ## Default Workflow Contract
 
-Unless an active Long-Task binding exists:
+Unless a valid Long-Task binding is active, this prompt-level protocol applies automatically. It guides Agent execution but creates no validator result, Receipt, persisted phase state or machine-completion authority.
 
 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.
+2. Before deciding `Context Delta`, run one bounded text search over `project_context/**` using a small high-signal set: explicit area/module names plus relevant API/schema/state/security/verification/deployment terms. Merge matches with manifest candidates and read only relevant Context; search supplements rather than replaces semantic judgment.
+3. For every material non-UI product or technical change, complete the task-local semantic obligation below before implementation: inventory all material inputs, atomize every applicable semantic Fact and condition, extend the standard catalog for domain-specific meaning, and bind every Fact to an owner and attributable proof. Missing authority stays decision-required rather than becoming an implementation default.
+4. 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.
+5. Complete `Architecture Deliberation`, then decide exactly one `Context Delta: none|required`. Update owning Context before code for durable product ownership, architecture, API/schema/data, state/recovery, dependency, security, product-surface responsibility or repeatable verification/deployment change. Local fixes preserving durable semantics are `none`.
+6. 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 questions, not artifacts or extra deltas.
+7. Implement precisely, run project-owned verification, perform Contract Conformance including `Architecture Conformance`, the non-UI semantic closure 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, use the first useful independently runnable production slice as a recommended real-entry feedback point when its expected early-localization value exceeds the run cost; it is not a prerequisite for expanding implementation. Always rerun the affected cold-start journey on the final candidate. Detached routes, specimens and deep links remain supplemental.
 
-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.
+The default workflow never requires a plan artifact, matrix, verdict, evidence ledger or result document. Optional scratch is not Context or proof. Bounded Context search creates no index, cache, state or second authority.
+
+## Shared Non-UI Semantic Completeness Obligation
+
+For every delivery-significant non-UI input, “complete and accurate Source” means the finest independently decidable semantic Fact granularity supported by the expressed, logically entailed, explicitly delegated and evidence-backed scope—not paragraph, Requirement, Product Control, status-catalog or current-code granularity. Inventory every material request fragment, attachment, controlling Context unit, canonical specification, selected external constraint, repository-preservation fact and delegated instruction. Classify each as non-UI material, UI design owned by the independent selected-design closure, honestly supporting-only or explicitly excluded with exact basis; an ordinary Material Source Item cannot be hidden as supporting-only.
+
+The standard semantic catalog is a mandatory floor and custom domain families/properties/axes extend it. Explicitly disposition product goals/scope/glossary; actors/roles/tenants/entitlements; business rules/calculations; entities/fields/relations; commands/queries/workflows/state machines/time; validation/output/error/API/protocol/event/job; persistence/cache/search/transactions/consistency/concurrency/idempotency; faults/retry/degradation/recovery/backup; configuration/flags/secrets; compatibility/migration/rollout; performance/capacity/cost/reliability/SLO; security/privacy/safety/compliance; observability/deployment/operations; external integrations; notification/file/media/localization; commercial/billing; hardware; AI/ML; and architecture ownership/boundaries/debt. Every applicable subject, typed relation and static/dynamic population has a stable identity. Every applicable actor/role/tenant/version/environment/state/input/boundary/locale/time/concurrency/dependency/failure/migration/rollout/threat or custom condition value is first-class; exact combinations are enumerated or explicitly excluded with basis. Aggregate strings, default paths, representative/pairwise samples and ungrounded N/A do not close atomic cells.
+
+One semantic Fact binds `Outcome × subject/relation/population × exact condition combination × atomic property × typed expected predicate`, owner, Source locator/digest, provenance, sensitivity and quantifier. Fact identity is distinct from proof obligation: expand every Fact to all required methods and the furthest independently failing observation boundary, with frozen comparator/parameters/tolerance/mask, Oracle identity/capability, environment and protected-value policy. The closure is exact:
+
+`Expected Semantic Facts = Source Indexed Facts = implementation/acceptance accounted Facts`
+
+`Fact × required-method obligations = attributable current-candidate result rows`
+
+Default work keeps this accounting ephemerally and creates no manifest, matrix, Claim set, state or Gate. Contract Conformance records for every obligation the actual observation/environment, frozen comparison authority, Oracle and pass/fail verdict from project-owned current-candidate checks. Missing, extra, duplicate, unresolved, unreadable, unmapped, unimplemented, unexecuted, stale, failed, proxy-only, reused or indistinguishable rows block a complete claim. An active Long-Task instead persists one Source-embedded `semantic-fact-manifest-v1`, projects exact Fact/obligation identities into its existing Claims/Assertions/Checks/bindings and requires set-equal typed `semantic_fact` results in its sole Final Gate; never run both carriers.
+
+Durable product, API/schema/data/state/security/privacy/architecture/verification/deployment meaning still belongs in its existing owning Context; exact task facts and provenance remain Source, code remains implementation truth and Contract stores bindings rather than copied semantic values. Genuine user/product/legal/security/commercial/safety/external decisions remain blocking or typed External Confirmations. This mechanism cannot discover unexpressed intent or prove an arbitrary Inspector/Oracle semantically sound; unsupported meaning fails closed and custom extensions remain mandatory when the standard catalog is insufficient.
 
 ## 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.
+This obligation activates only for a selected implementation handoff. Run `ty-context design-resource preflight <handoff.md>` before UI Authority Closure. A formal Web/App target needs one completely acquired machine-readable canonical entry, its exact dependency closure and one frozen-Inspector observable-Fact manifest. Authoring derives the complete scoped `subject × target × condition × variation × atomic property` Expected Fact Universe before generation; complete Census, axis/combination/property expansion, explicit N/A/exclusions and non-sampling/non-truncation must prove `Expected Fact Universe = Canonical Resource Facts = Handoff Indexed Facts`. Product Control and eight-dimension roll-ups are not the Fact ceiling. Preserve exact located values and design-system lineage in canonical resources, every property-required Fact × method obligation, comparator/tolerance/mask, Oracle/environment and sensitive-observation policy; an exact target also needs full-target layout and pixel Facts for every condition. Deliberately partial input remains a constraint or blocking unresolved. Incomplete acquisition, aggregate labels, unreadable Census/locators, missing/extra Fact Cells or proofs, unresolved conflicts/blockers, unsupported evidence or stale digests fail closed. Preflight proves input completeness/integrity relative to the named Inspector/Oracle TCB, 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. It owns interpretation, selection basis, immutable locator/digest, conditions and editable-upstream update route; other layers keep only a stable key, owner/anchor and local applicability. Use the on-demand UI/UX Skill for Design Source Projection. Never overwrite an adopted baseline; create a new immutable version and update its canonical record.
 
-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.
+Externally authored resources remain ordinary Source. Authoring Skills do not change Context, code or Contract and do not claim acceptance.
 
-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.
+For every external product, architecture, technical or acceptance constraint, internally classify it as Context-covered, requiring a Context update, task-local, out of scope or decision-required. Conformance confirms it reached the correct owner and verification.
 
-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.
+Default work keeps one ephemeral exact accounting of Fact Cells, Facts, property-required proof methods, Source Items, blockers, targets and conditions. Route every item to its production owner, cold-start journey and an attributable final-candidate project check; retain per-Fact actual observation/environment, declared comparison authority and pass/fail verdict. Any unresolved, unmapped, unexecuted, stale, failed or indistinguishable item blocks a complete claim and is reported as a gap. This creates no file, matrix, Claim set, state or Gate. An active Long-Task projects the same obligation into existing Source/Claims/Assertions/bindings, `fact_expectations`, `fact_results` and Final Gate and never also runs the default closure.
 
 ## 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. Otherwise remain on the default Workflow Contract, even when work appears long.
+1. A valid Git common-dir active record plus matching worktree Git-config marker resumes with `ty-context long-task resume <workdir>` in the currently selected host execution Goal; directly load and follow the installed package-managed `long-task-workflow` Skill. This recovery path does not depend on implicit invocation.
+2. An explicit selection of the logical `long-task-workflow` Skill authors or resumes exactly one complete `long-task-delivery-v2` Contract. In Codex, select it with `$long-task-workflow` or through `/skills`.
+3. Otherwise remain on the default Workflow Contract.
 
-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.
+“One native Goal” is selected and owned by the host/user and means the currently selected host execution Goal for this delivery and workspace. Harness does not create, persist or reconnect a Goal identifier. Compaction may continue inside the Goal; a later physical Goal/session restores semantic workflow state through `resume` rather than reconnecting a prior Turn.
 
-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 loaded Skill and its progressive references own Source/Contract authoring, Control/applicability closure, selected-design projection, evidence design, protected revision, rolling repair and lifecycle commands. Do not duplicate those low-frequency rules in this startup router. During Draft/proof/lifecycle work, read the applicable Skill reference and use `ty-context long-task help` for CLI syntax.
 
-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, `execution_model_checkpoint.required: true` is a terminal-turn boundary. Unless the user already stated an explicit task-specific current-model or switch-and-resume strategy, stop before product implementation, 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 it; later revisions do not repeat it and Harness records no model route or checkpoint acknowledgement 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.
+Long-Task Final Gate is the sole `Architecture Conformance` and selected-design closure owner. It source-recompiles and reruns every declared Check on one current snapshot; targeted Progress, prose, historical tests, Receipts, compiled cache or Agent judgment never create acceptance. Exactly fresh `machine_accepted` with no pending External Confirmation is the complete declared-machine terminal; qualified/external-pending results never complete the platform-native Goal.
 
-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.
+The `F = Implementation Freedom Boundary` keeps implementation order, methods, local feedback cadence and optional platform-native one-agent/multi-agent execution Goal-owned within Source/Contract, architecture, safety, forbidden-shortcut and external-action boundaries. Harness creates no development method Gate, per-edit mandate, agent scheduler/delegation state or proof from delegated reports; all proof-bearing output converges into the selected verification workspace.
 
-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.
+Long-Task Anti-Degradation Assurance requires mechanism changes to preserve or strengthen coverage, false-negative resistance, fail-closed Authority and final-snapshot proof before positive net ROI matters. Replacing the controlling purpose requires an explicit project-owner design-purpose decision plus replacement proof.
 
-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.
+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. `design-system-authoring` is explicit-only.
 
 ## 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.
+- Long-term facts live only in `project_context/**` or `DESIGN.md`. Selected targets remain Context-reachable Source/verifier inputs; generated screenshots/diffs/logs/raw evidence/runtime state/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.
 

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 a stable safe re-entry rule for a fresh agent, including when Context must be updated before code. Do not store task-local progress or a one-off next edit here.
+
+## Context Index
+
+- [main](areas/main.md)
+- [main verification](areas/main/verification.md)