project-tiny-context-harness 0.8.10 → 0.8.12

package/assets/agents/.gitkeep

@@ -1 +1 @@
-
+

package/assets/agents/AGENTS_CORE.md

@@ -1,6 +1,6 @@
 # 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 automatically applicable default Workflow Contract and the explicitly selected 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 model-led default Workflow Contract for work of any complexity and the explicitly selected Single-Goal Long-Task Workflow for machine completion authority, recoverability and auditability. Complexity determines execution and verification depth; required completion authority and recoverability determine the workflow route; Long-Task-internal risk determines proof strength.
 
 ## Shared Engineering Quality Obligation
 
@@ -12,50 +12,44 @@ After implementation and project verification, perform one current-candidate `En
 
 ## Default Workflow Contract
 
-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.
+Unless a valid Long-Task binding is active or the user explicitly selects Long-Task, this prompt-level protocol applies automatically regardless of duration, complexity or file count. It guides model-led Agent execution but creates no validator result, exact Fact/Obligation ledger, 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 high-signal set: explicit area/module names plus relevant API/schema/state/security/verification/deployment terms. Merge matches with manifest candidates, read relevant Context and widen whenever another Area/shared dependency becomes relevant; search supplements rather than replaces semantic judgment.
 3. In a monorepo or otherwise multi-target repository, separate the expandable read scope from the task-local intended workspace(s). An optional sparse `project_context/workspaces/<workspace-id>/**` directory maps each represented Context workspace to one code root through existing manifest `root/context`; workspace-local Areas own semantic responsibilities inside it, cross-workspace Areas stay top-level, and code workspaces without durable Context need no empty mirror. Keep the monorepo default Area small and repository-common; workspace-local Context stays `on-demand` unless genuinely near-universal. This structure/default/read policy is neither a read ACL nor edit authorization. Resolve intended workspaces from explicit user/product/path/repository facts; if materially different siblings remain ambiguous, ask one concise target question before product edits. Enumerate intentional multi-workspace targets and supporting/shared scope.
-4. 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 every material non-UI product or technical change, understand all explicit user, Context, specification and selected-constraint requirements at risk-proportional depth. Identify affected owners, material conditions, failure boundaries and real acceptance entries; do not let current code redefine Source or turn missing authority into an implementation default. This is task reasoning, not an Expected Fact Universe or proof ledger.
 5. For UI/product-surface work, confirm information/action/feedback ownership and use `context_surface_contract` when durable responsibility is unclear or changes. Root `DESIGN.md` remains the current shared project Design Authority; Context workspace placement does not create independent design systems. 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.
 6. Complete `Architecture Deliberation`, including applicable-quality routing or a concrete preservation basis, 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`.
 7. 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.
-8. Implement precisely under the Goal-owned quality guardrails and run project-owned verification. When the repository exposes a changed-path/target-scope check, run it against the intended/supporting targets and exact task-attributable paths; otherwise review the final diff against durable owners during Conformance. Do not attribute unrelated pre-existing dirty paths to the task without provenance. Perform Contract Conformance including `Engineering Quality Conformance`, its `Architecture Conformance` subset, the non-UI semantic closure and any selected-design closure below, then run the separate Context drift check. Report implementation, verification, engineering/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.
+8. Implement precisely under the Goal-owned quality guardrails and run project-owned verification. When a check fails or exposes a missed requirement, wrong owner, design mismatch, scope escape, Context drift, stale evidence or new debt, localize it to the requirement/owner/module/check, repair it and rerun affected checks. After the last relevant code, configuration, Source or controlling-Context change, rerun every affected check on the current candidate; historical CI, pre-fix results, delegated reports and prose inspection are not current evidence. When the repository exposes a changed-path/target-scope check, run it against the intended/supporting targets and exact task-attributable paths; otherwise review the final diff against durable owners during Conformance. Do not attribute unrelated pre-existing dirty paths to the task without provenance. Perform evidence-bounded Contract Conformance including `Engineering Quality Conformance`, its `Architecture Conformance` subset and any applicable source/design checks below, then run the separate Context drift check. Report `Implemented`, `Verified`, `Unverified`, `Blocked / decision required`, engineering/architecture conformance and Context status; never fold unverified or externally pending scope into a complete claim. 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, target declaration, 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; it also creates no read isolation. Do not make the full Context graph the ordinary default or add a required Context directory for every package-manager workspace, workspace/applicability schema, automatic topology scan, migration, target registry, generic path/import/runtime scanner or duplicate Long-Task scope classifier.
+The default workflow never requires a plan artifact, target declaration, 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; it also creates no read isolation. Missing, stale, unreadable or conflicting controlling Source, a materially ambiguous target, an unsupported observation boundary or a failed/stale check blocks an unqualified handoff for the affected scope: widen reading or verification only as discovered dependencies and risk require, then report any remaining qualification. Do not make the full Context graph the default or add a required Context directory for every package-manager workspace, workspace/applicability schema, automatic topology scan, migration, target registry, generic path/import/runtime scanner or duplicate Long-Task scope classifier.
 
-## Shared Non-UI Semantic Completeness Obligation
+## Non-UI Source And Assurance Boundary
 
-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.
+Both routes preserve Source authority: explicit product, business, API, data, state, failure, security, privacy, compatibility, performance, operational and architecture requirements cannot be silently omitted or redefined from current code. Genuine user/product/legal/security/commercial/safety/external choices remain decision-required. Default work identifies material requirements, conditions, owners and acceptance boundaries at risk-proportional depth, implements them through their real owners, uses attributable current-candidate project checks and reports anything not established. It does not maintain stable Fact/Obligation identities, exact set equality, a universal condition expansion, frozen Oracle/environment rows or a complete result ledger.
 
-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.
+An active Long-Task owns the exact non-UI semantic carrier instead. Its package-managed Skill and progressive references preserve the complete Source inventory/Census, standard plus custom semantic families, atomic Fact and condition identities, Fact×required-method obligations, comparison authority, current typed results and sole Final-Gate equality. Never run a nested default semantic closure. Durable meaning still belongs in its existing owning Context; Source remains task authority, code remains implementation truth and Contract stores bindings rather than copied values. Neither route can discover unexpressed intent or prove an arbitrary Oracle semantically sound.
 
 ## Selected-Design Conformance Obligation
 
 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.
 
+UI symbolic V2 is explicit opt-in; V1 remains the default. A V2 target must preserve the complete extensional `subject/relation × target × reachable condition/variation × applicable atomic property × population/quantifier` denotation, with constant located Rule values, mutually exclusive exhaustive regions and distinct Fact Rule, proof-obligation and set-valued certificate identities. Applicability may retain exact physical remainder partitions or use package-owned subject property profiles plus frozen Inspector custom-property closure and explicit unique instance exceptions; every logical subject-property point still has exactly one disposition. An omitted axis requires both Source-side and production-side proof through frozen closed-world static dependency closure, restricted-IR exact equivalence or finite complete-domain exhaustive equivalence; dynamic/reflected/unfrozen/external or sampled dependencies block. One Contract may mix V1 and V2 targets; bind V1 to exact Fact results and V2 to exact Rule-method-region plus freshly recomputed certificate results in the existing sole Final Gate. V1 admission uses stat/bounded-prefix capacity checks and fails rather than truncating or silently switching. Purpose-fulfillment efficiency non-degradation is a package mechanism-change admission property, not an AcceptedDeliveryTerminal condition. Non-UI symbolic admission and Provider/P0 trust-boundary work remain out of scope.
+
+Every non-interference proof needs a digest-identified frozen executable Oracle with the exact `symbolic_noninterference.<side>.<method>` capability. Source proof uses one canonical package-owned restricted Source IR in the complete current Inspector inputs; the package binds its current bytes to target/certificate/Rule scope and derives the DAG, predicate or complete finite-domain evaluation itself. Submitted graph/predicate/evaluation/pass fields and the immutable artifact are cache/bindings only: preflight requires current recomputation, artifact bytes and proof cache to agree, while excluding the artifact from semantic inputs. Executable/CSS/implicit-DOM/template/dynamic/reflected/computed/unfrozen/external Source blocks. Production remains limited to the package-parsed static HTML plus inert JSON subset. Both sides bind implementation closure/version/capability, environment, exact current inputs, side snapshot, scopes, omitted axes, method result, artifact and witness; their proof digests bind the existing current Final-Gate certificate result. Extraction outside admitted representations remains an explicit TCB boundary.
+
 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.
 
 Externally authored resources remain ordinary Source. Authoring Skills do not change Context, code or Contract and do not claim acceptance.
 
 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.
 
-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.
+Default work opens every affected selected `exact-target` or `constraint` and its declared conditions, routes it to the real production owner and cold-start journey, and runs applicable project-native visual, interaction, accessibility or runtime checks on the final candidate. It reports conditions those checks did not establish and does not claim that preflight input integrity proves production conformance. It does not rebuild the complete Fact Cell universe or retain per-Fact-by-method result rows. An active Long-Task instead projects the exact obligation into existing Source/Claims/Assertions/bindings, `fact_expectations`, `fact_results` and Final Gate and never also runs a default closure.
 
 ## Long-Task Routing
 
-Do not infer long-task mode from duration, complexity, file count or agent preference.
+Route by required assurance, not task size. Select Long-Task when stable machine obligations, current-snapshot machine completion authority, cross-compaction/session recovery or auditability are explicitly required; its extra authoring and verification cost is not a promise of lower time or token use. A small consequential rule may use it and a complex cross-module change may remain default. 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 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`.
@@ -65,15 +59,15 @@ Do not infer long-task mode from duration, complexity, file count or agent prefe
 
 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.
 
-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, `execution_model_checkpoint.required: true` is an unconditional terminal-turn boundary. Stop before product implementation, edits, builds or tests even when an earlier message stated a model strategy. Tell a Chinese-speaking user exactly `处理好模型更换之后，请发送【继续】。`; use `After handling the model change, send [continue].` in English. Harness cannot observe or verify the host model change; later revisions do not repeat the pause and no acknowledgement, model route or checkpoint state is recorded.
 
 Long-Task Final Gate is the sole `Engineering Quality Conformance`, `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. It proves the declared falsifiable project-check-bound invariants, not overall code quality. 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.
 
-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.
+The `F = Implementation Freedom Boundary` keeps implementation order, methods and local feedback cadence Goal-owned within Source/Contract, architecture, safety, forbidden-shortcut and external-action boundaries. After the checkpoint, follow the loaded Skill's parent-owned Delegation Suitability policy for optional fixed-profile workers. Harness creates no development method Gate, per-edit mandate, fixed agent allocation, scheduler/delegation state or proof from delegated reports; all proof-bearing output converges into the selected verification workspace.
 
 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. `design-system-authoring` is explicit-only.
+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 sole Long-Task Workflow Skill and package-owned lifecycle Hooks; an exact `.codex` root may also receive the optional fixed Codex worker profile. The retired Source Plan pointer is not installed. `design-system-authoring` is explicit-only.
 
 ## Durable Facts And Generated Surfaces
 

package/assets/agents/long-task-implementation.toml

@@ -0,0 +1,15 @@
+# ty-context:managed:long-task-implementation-worker
+name = "long_task_implementation"
+description = "Optional implementation worker for bounded Long-Task rolling code and repair after the parent Goal satisfies the execution-model checkpoint."
+model = "gpt-5.6-luna"
+model_reasoning_effort = "max"
+developer_instructions = """
+Work only on the bounded rolling implementation or repair packet delegated by the parent Goal after the first-Authority-Lock terminal-turn checkpoint.
+
+Read only the named Source, Contract, Context, owner code, and local instructions needed for the packet. Implement only within its delegated paths and boundaries, preserve existing architecture and failure semantics, and run only relevant project-owned implementation checks. Do not author or revise Source, Contract, Authority, or Context writeback. Do not create Progress, Evidence, Receipt, or Final Gate output. Do not run long-task resume, Preflight, Compile, Authority Revision, formal verify, Final Gate, Stop/close, abandon, or completion commands.
+
+Use the current selected workspace. Do not create or switch branches or worktrees. Do not choose models, spawn or retry agents, schedule work, start an Agent Server/App Server/MCP dispatcher, create a queue, registry, or Worker DAG, or persist delegation/routing state. Do not claim acceptance or completion authority. Return changed paths, checks, findings, and unresolved risks as an advisory report to the parent Goal, which alone owns architecture, Context writeback, integration, current-candidate checks, formal verification, Final Gate, close, and completion.
+"""
+
+[agents]
+enabled = false

package/assets/context_templates/architecture.md

@@ -1,26 +1,26 @@
-# 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.
-
+# 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.
 - In a monorepo, record each represented `project_context/workspaces/<workspace-id>/**` to one code-root mapping, workspace-local Area responsibilities and cross-workspace/shared dependency direction. Do not list code workspaces that have no durable Context merely to complete a mirror, and do not turn the map into a read/edit ACL.
-
-## Data / Control Flow
-
-- Summarize only the durable request, event, state or data flow that is hard to infer from code alone.
-
+
+## 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 only durable engineering-quality constraints and tradeoffs that materially shape future work: failure/recovery or resource lifecycle, concurrency/consistency, performance/capacity/cost, security/privacy/safety, compatibility/migration/rollout, integration/deployment/operability or maintainability/changeability.
@@ -31,7 +31,7 @@ This is the restrained architecture context. Keep only facts that help a fresh a
 - List the project-native type/compiler/lint/architecture/contract/behavior/benchmark/probe entry points that can falsify durable boundaries or quality constraints; state only what each path is capable of proving.
 - For a durable performance constraint, preserve workload, metric, environment, baseline or budget and comparator/tolerance ownership here or in the narrower owning Context. Static shape checks are not runtime-performance proof.
 - Do not record one-off results or claim that checks already passed.
-
-## Open Risks
-
-- List unresolved architectural risks or unknowns.
+
+## Open Risks
+
+- List unresolved architectural risks or unknowns.

package/assets/context_templates/area.md

@@ -1,40 +1,40 @@
-# 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.
-
+
+## 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.
 - In a monorepo, a workspace-local Area belongs under `project_context/workspaces/<workspace-id>/areas/**`; its manifest entry maps that Context workspace to one code root. Name this Area's semantic responsibility within that root and any shared/supporting owners commonly needed. Cross-workspace Areas stay under top-level `project_context/areas/**`. This documents ownership and discovery, not read isolation or edit permission.
-
-## Related Role Context
-
+
+## Related Role Context
+
 - Verification paths live in this area's `verification` role Context, such as `project_context/areas/main/verification.md` or `project_context/workspaces/mobile/areas/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.
+- 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

@@ -15,27 +15,27 @@
 # This optional sparse mirror adds no workspace schema or read/edit ACL. Use
 # project-owned scope checks for task-local intended/supporting changed paths.
 # `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"]
+# 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
-
+# 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)
+
+## Context Index
+
+- [main](areas/main.md)
+- [main verification](areas/main/verification.md)