project-tiny-context-harness 0.8.0 → 0.8.1

package/assets/agents/.gitkeep

@@ -1 +1 @@
-
+

package/assets/agents/AGENTS_CORE.md

@@ -1,66 +1,70 @@
-# Minimal Context Harness Protocol
-
-This project uses Tiny Context. The Harness maintains durable Context and workflow authority; project tests, CI, runtime evidence and human acceptance prove product quality.
-
-Tiny Context has three capabilities: Minimal Context, the default Workflow Contract, and the explicitly enabled Single-Goal Long-Task Workflow.
-
-## Shared Architecture Quality Obligation
-
-Every implementation delivery performs one externally observable, repository-bound `Architecture Deliberation` before the first implementation edit. Its depth is risk-proportional, but the occurrence is universal: identify affected owners and the current extension point/source of truth, dependency and state/lifecycle boundaries, the selected design and material alternatives, one plausible future-change challenge, touched technical debt and its disposition, forbidden shortcuts, and project-owned checks. A small change may conclude that existing architecture is preserved, but must name the concrete owner/extension point and why no new or worsened debt is introduced. Surface conclusions and repository evidence, not private chain-of-thought, and refresh the checkpoint if scope, ownership or the selected design materially changes.
-
-After implementation and project verification, perform one `Architecture Conformance` closure on the current candidate snapshot. The default path embeds it in Contract Conformance; an active Long-Task embeds it only in Final Gate. Never schedule both. A changed candidate invalidates the closure and must be rechecked. New or worsened debt, an undeclared second source of truth, wrong dependency direction, owner bypass, scope escape or a forbidden shortcut blocks handoff unless an explicit project-owned bounded exception records owner, rationale, tracking and removal condition. This obligation creates no plan artifact, architecture document, second Authority, workflow state or generic architecture analyzer.
-
-## Default Workflow Contract
-
-Unless an active Long-Task binding exists:
-
-1. Read `project_context/global.md`, `project_context/architecture.md`, `project_context/context.toml` and the default area root, then collect graph/trigger candidates.
-2. Before deciding `Context Delta`, run one bounded text search over `project_context/**` using a small set of high-signal task terms such as explicit area/module names and API/schema/state/security/verification/deployment terms. Merge matching Context with manifest candidates and read only relevant files; search supplements rather than replaces semantic judgment.
-3. For UI/product-surface work, confirm information/action/feedback ownership and use `context_surface_contract` when durable responsibility is unclear or changes; Product Surface Contracts own cross-surface interfaces and optional on-demand Screen Contracts use existing area/subdomain/contract/verification roles for deeper screen/control facts. When a selected implementation handoff from `design-resource-authoring` exists, run `ty-context design-resource preflight <handoff.md>` before UI Authority Closure; incomplete source/dependency closure, an unresolved typed locator, uncovered applicable subject × target × condition × dimension cells, unsupported evidence, unresolved meaning or stale resource digests fail closed. An implementation Web/App target must identify one canonical machine-readable entry, its exact dependency closure and `acquisition: complete`; PNG may supplement but cannot be the only implementation source. The residual provider-neutral handoff uses typed locators to close every applicable subject × target × condition × dimension cell and owns scope, applicability, missing meaning, blockers and downstream bindings while canonical resources retain exact code-expressible facts. Before a material product, design, implementation or acceptance decision, reconcile each affected stable surface/control/target key as Context-covered, requiring a Context update, task-local, out of scope or decision-required, traverse owning Context through `DESIGN.md`, and open every affected selected `exact-target` or `constraint`. Its record must expose a readable immutable adopted locator/digest, declared coverage and an editable upstream owner/locator/update route; a registry mention alone is not consumption, and neither is a handoff index mention. Only a selected exact/constraint target with adequate declared coverage authorizes fidelity. For every selected target, route each covered handoff Source Item and verification method through its declared conditions to the production route/component owner, the cold-start real-user entry journey and rendered/interactive checks that can independently fail. Design handoff preflight and file hashes prove semantic-input completeness/resource integrity only; they never prove implementation conformance. Missing, stale, unreadable or conflicting targets fail closed for the affected claim. If only the editable upstream is unavailable, the immutable target may still be read, but requested resource changes remain a named manual/external boundary. Never overwrite an adopted baseline: update upstream, create/approve a new immutable version and update the owning reference. An unconfigured starter, candidate, style-only guidance or inspiration does not authorize invented production layout. `design-system-authoring` is an explicit-only cold-start/repair capability that uses Open Design to generate/select/adopt project Design Authority; never infer or auto-run it. For an explicit standalone request to generate or iterate resources, `design-resource-authoring` keeps the requested output/development content as the hard ceiling. Style-bearing work stops on unconfigured Design Authority and points to the explicit design-system Skill; non-fidelity work remains lightweight. Configured style-bearing Open Design projects bind and verify the adopted provider design-system ID. After final selection, design-resource authoring may reconcile accepted decisions into the initial proposal exactly once; for a selected implementation handoff it emits one strict marked `design-resource-handoff-v1` Source and runs shared preflight, but it never changes Context, `DESIGN.md`, a Source Plan, code or Contract. Its resources remain ordinary Source until the consuming workflow adopts durable meaning and makes decision-relevant selections Context-reachable.
-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`, then run the separate Context drift check and report implementation, verification, architecture conformance, Context status and blockers. For material UI, inspect the real production entry after the first runnable vertical slice and rerun the affected cold-start journey on the final candidate; a detached route, specimen or deep link is supplemental evidence only.
-
-The default workflow never requires a plan artifact, matrix, verdict, evidence ledger or result document. Optional scratch is not Context or completion proof. The bounded Context search creates no index, cache, state or second authority.
-
-Externally authored design resources such as Figma frames, images, prototypes and component specifications are ordinary Source. Exploration remains schema-free. A selected implementation handoff uses one provider-neutral `design-resource-handoff-v1` residual adapter over completely acquired canonical resources and closes every applicable subject/target/condition across surface/flow, visual/content, component/control, state/interaction, motion, adaptation/input, accessibility and assets. Resource authoring runs shared preflight and may reconcile a selected direction into the initial proposal once, but it does not update `project_context/**` or `DESIGN.md`, edit a Source Plan/Contract/production implementation or claim acceptance. Explicit `design-system-authoring` separately adopts a selected Open Design system into canonical `DESIGN.md`, one token source/direction and owning Context. The consuming development workflow still owns UI Authority Closure, implementation and verification; candidates authorize no fidelity. Figma, Penpot and OpenPencil remain optional upstream/sidecar choices and add no provider-specific authority or default conversion.
-
-For external product, architecture, technical or acceptance sources, internally classify every material constraint as covered by Context, requiring a Context update, task-local, explicitly out of scope or requiring a genuine user decision. Conformance must confirm controlling Context reached the correct modules, surfaces, APIs, state machines and verification paths without forbidden shortcuts or duplicate authority.
-
-## Long-Task Routing
-
-Do not infer long-task mode from duration, complexity, file count or agent preference.
-
-1. A valid Git common-dir active record plus matching worktree Git-config marker resumes through `ty-context long-task resume <workdir>` and `/long-task-workflow` in the current native Goal.
-2. Explicit `/long-task-workflow` authors or resumes exactly one complete `long-task-delivery-v2` Contract for the selected delivery.
-3. `/normal-long-task` is a retirement pointer. Otherwise remain on the default Workflow Contract, even when work is long.
-
+# Minimal Context Harness Protocol
+
+This project uses Tiny Context. The Harness maintains durable Context and workflow authority; project tests, CI, runtime evidence and human acceptance prove product quality. Its three capabilities are Minimal Context, the default Workflow Contract and the explicitly enabled Single-Goal Long-Task Workflow.
+
+## Shared Architecture Quality Obligation
+
+Every implementation delivery performs one externally observable, repository-bound `Architecture Deliberation` before the first implementation edit. Its depth is risk-proportional, but the occurrence is universal: identify affected owners and the current extension point/source of truth, dependency and state/lifecycle boundaries, the selected design and material alternatives, one plausible future-change challenge, touched technical debt and its disposition, forbidden shortcuts, and project-owned checks. A small change may conclude that existing architecture is preserved, but must name the concrete owner/extension point and why no new or worsened debt is introduced. Surface conclusions and repository evidence, not private chain-of-thought, and refresh the checkpoint if scope, ownership or the selected design materially changes.
+
+After implementation and project verification, perform one `Architecture Conformance` closure on the current candidate snapshot. The default path embeds it in Contract Conformance; an active Long-Task embeds it only in Final Gate. Never schedule both. A changed candidate invalidates the closure and must be rechecked. New or worsened debt, an undeclared second source of truth, wrong dependency direction, owner bypass, scope escape or a forbidden shortcut blocks handoff unless an explicit project-owned bounded exception records owner, rationale, tracking and removal condition. This obligation creates no plan artifact, architecture document, second Authority, workflow state or generic architecture analyzer.
+
+## Default Workflow Contract
+
+Unless an active Long-Task binding exists:
+
+1. Read `project_context/global.md`, `project_context/architecture.md`, `project_context/context.toml` and the default area root, then collect graph/trigger candidates.
+2. Before deciding `Context Delta`, run one bounded text search over `project_context/**` using a small set of high-signal task terms such as explicit area/module names and API/schema/state/security/verification/deployment terms. Merge matching Context with manifest candidates and read only relevant files; search supplements rather than replaces semantic judgment.
+3. For UI/product-surface work, confirm information/action/feedback ownership and use `context_surface_contract` when durable responsibility is unclear or changes. For material UI, reconcile affected stable surface/control/target keys as Context-covered, requiring a Context update, task-local, out of scope or decision-required; traverse owning Context and `DESIGN.md`; and open every affected selected `exact-target` or `constraint`. Missing, stale, unreadable or conflicting authority fails closed for the affected claim. Local fixes and explicit non-fidelity prototypes stay lightweight.
+4. Complete the shared `Architecture Deliberation`, then decide exactly one `Context Delta: none|required`. Update owning Context before code when durable product ownership, architecture, API/schema/data, state/recovery, dependency, security, product-surface responsibility or repeatable verification/deployment changes. Local fixes preserving durable semantics are `none`.
+5. Use the agent/platform internal plan. Keep `Architecture Context Hit`, `Decision Rationale Hit: existing|required|none` and `Modularity Check: none|required|exception` as internal routing and maintenance questions, not artifacts or extra deltas.
+6. Implement precisely, run project-owned verification, perform Contract Conformance including the shared `Architecture Conformance` and any selected-design closure below, then run the separate Context drift check. Report implementation, verification, architecture conformance, Context status and blockers. For material UI, inspect the real production entry after the first runnable vertical slice and rerun the affected cold-start journey on the final candidate; a detached route, specimen or deep link is supplemental evidence only.
+
+The default workflow never requires a plan artifact, matrix, verdict, evidence ledger or result document. Optional scratch is not Context or completion proof. The bounded Context search creates no index, cache, state or second authority.
+
+## Selected-Design Conformance Obligation
+
+This shared obligation activates only for a selected implementation handoff. Run `ty-context design-resource preflight <handoff.md>` before UI Authority Closure. A Web/App target needs one completely acquired machine-readable canonical entry and its exact dependency closure; unresolved locators/cells/meaning, unsupported evidence or stale digests fail closed. Preflight and hashes prove input completeness/integrity, never production conformance.
+
+Every adopted target has exactly one canonical record: `DESIGN.md` for project/system/component-family scope or the owning Screen Contract for one-screen/interaction scope. That record owns interpretation, selection basis, immutable locator/digest, condition coverage and editable-upstream update route; other layers keep only the stable key, owner/anchor and local applicability. Use the on-demand UIUX Skill for deterministic Design Source Projection. Never overwrite an adopted baseline; update upstream, approve a new immutable version and update the canonical record.
+
+Default work keeps one ephemeral exact accounting of covered Source Items, declared verification methods, blockers, targets and conditions. Route every applicable item to the production owner, cold-start journey and an executed final-candidate project check whose failure remains attributable; one check may cover several methods only when each method/fact can fail distinctly. A selected-target, implementation or declared check-input change stales closure. Any unresolved, unmapped, unexecuted, stale or indistinguishable item blocks a complete-conformance claim and must be reported as a gap. This creates no file, matrix, Claim set, state or Gate.
+
+Externally authored resources remain ordinary Source and exploration remains schema-free. `design-system-authoring` is explicit-only; `design-resource-authoring` keeps the requested scope ceiling and may reconcile final accepted decisions into the initial proposal once, but neither authoring path changes Context/code/Contract or claims acceptance. An active Long-Task projects this same obligation into its existing Claims, Assertions, bindings and Final Gate and never also runs the default closure. For every external product, architecture, technical or acceptance constraint, internally classify it as covered by Context, requiring a Context update, task-local, out of scope or decision-required; Conformance confirms it reached the correct owner and verification without shortcuts or duplicate authority.
+
+## Long-Task Routing
+
+Do not infer long-task mode from duration, complexity, file count or agent preference.
+
+1. A valid Git common-dir active record plus matching worktree Git-config marker resumes through `ty-context long-task resume <workdir>` and `/long-task-workflow` in the current native Goal.
+2. Explicit `/long-task-workflow` authors or resumes exactly one complete `long-task-delivery-v2` Contract for the selected delivery.
+3. `/normal-long-task` is a retirement pointer. Otherwise remain on the default Workflow Contract, even when work is long.
+
 Raw/revised proposals, selected design resources and mixed attachments enter one Source-bound Contract Draft loop immediately. Source inventory, refinement, provenance, markers and Contract mapping converge in the same non-authoritative `delivery-contract.yaml` until Preflight is ready and formal Compile creates Authority Lock; there is no prior or internal Source-authoring stage. A legacy Source Plan remains ordinary input. Candidate resources authorize no fidelity Claim. A selected implementation handoff must pass the shared design-resource preflight; its marked residual handoff enters `task.source_paths`, its handoff and source-profile entry/dependencies enter target Check `verification_inputs`, and Long-Task Preflight/Compile requires exact target/condition/file equality, covered Source Claims, one independent positive Assertion per declared verification method and blocker Source-item/method lineage before Authority Lock. After lock, resource changes use Authority Revision.
-
+
 When an Outcome declares Controls, 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. 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 with relevant Source Claims and required evidence capabilities. Every declared design-acceptance blocker preserves exact Source-item/method provenance and resolves to target-local machine proof or a target-blocking external confirmation; it cannot be dismissed in-band, and scope removal requires revised Source/Contract authority. These are protected Contract semantics, not a UI registry, second Gate or per-surface state.
-
-The workflow uses one native Goal, one selected workspace, one Contract and one Final Gate. New authoring uses inline vertical Outcomes grouped by ordered Stages; existing `outcome_files` are physical compatibility only. Target profiles name required product targets and root runtimes; Checks declare Given/When journeys and all-of Evidence Capabilities. Stage/frontier state is derived from ordinary Progress and creates no second Gate, Receipt, scheduler or completion authority.
-
-After the first Authority Lock, treat `execution_model_checkpoint.required: true` as a terminal-turn boundary. Unless the user already stated an explicit task-specific choice naming current-model continuation or a model switch, end the current turn before product implementation, file edits, builds or tests and ask the user to choose `continue_current_model` or switch models and then resume. Generic continue/resume/finish/continue-goal language does not satisfy the checkpoint; later revisions do not repeat it. Harness records no model route or checkpoint acknowledgement state.
-
-During Draft authoring, proof design or authority lifecycle work, read the applicable references in the package-managed `long-task-workflow` Skill. Use `ty-context long-task help` for CLI syntax instead of treating this startup router as a command reference. Before first Authority Lock, Preflight and Compile classify current HEAD-relative workspace changes against protected paths and declared expected/support ownership; after lock, Verify and Final Gate apply the same fail-closed categories against the immutable baseline. During first enable, protection covers only exact files present in the current package asset tree for configured managed destinations plus the exact harness config/hook files; managed directory roots and broad `.codex/**` are never exempt.
-
-Final Gate, Stop and close recompile the source Contract and rerun every declared Check on one clean current snapshot. Final Gate is the Long-Task path's sole `Architecture Conformance` owner; do not run a second default-workflow closure. Required targets cannot substitute for one another; presence cannot prove behavior; resource integrity or `visual_render` cannot substitute for selected-target `design_conformance`; success and degradation remain distinct; typed boundary effects require an observer; unresolved design blockers remain blocking. `verify --explain` is a read-only declared-execution preview and creates no proof or Progress. Targeted verify is repair evidence only; `progress_stale` is a freshness fact, not a per-edit rerun instruction, so coalesce related edits and refresh the cheapest reliable owning Check before dependent reliance or Final Gate. 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; machine acceptance reports target/stage qualification but cannot by itself authorize completing the platform-native Goal, CI, deployment or human acceptance.
-
-Tiny Context does not create or restore platform Goals, invoke models, spawn agents, call an App Server, create branches/worktrees, merge, push, open PRs, deploy or manage process trees. `ty-context enable long-task` installs the Long-Task Workflow Skill, the retired Source Plan compatibility pointer and package-owned completion Hook.
-
-## Durable Facts And Generated Surfaces
-
-- Context is intended ownership/boundary/contract truth; code is current implementation truth. Treat disagreement as drift, missing work or stale Context.
-- Long-term facts live only in `project_context/**` or `DESIGN.md`; adopted decision-relevant design targets remain Context-reachable project Source/verifier inputs through stable keys, immutable identities and editable upstream/update records rather than becoming Context themselves. Generated implementation screenshots/diffs, logs, raw evidence, secrets, runtime state and receipts do not become Context.
-- Managed `AGENTS.md` blocks, `<harnessRoot>/ty-context-managed/**` and package-managed Skills are generated and sync-overwritten.
-- Explicit upgrades use `context_harness_upgrade`; package sync never imports retired Campaign or development-period authority state.
-
-## Verification
-
-- `make validate-context`: Context recoverability.
-- `make validate-harness`: Context plus touched-source modularity.
-- `ty-context doctor`: installation health plus advisory default Context footprint and Design Authority status.
-- `node packages/ty-context/dist/cli.js package check-source`: managed-source/package parity in this source workspace.
-
-Every handoff reports exactly one of `Context: updated ...` or `Context: no durable fact change`. Never claim tests, deployment or acceptance from Context alone.
+
+The workflow uses one native Goal, one selected workspace, one Contract and one Final Gate. New authoring uses inline vertical Outcomes grouped by ordered Stages; existing `outcome_files` are physical compatibility only. Target profiles name required product targets and root runtimes; Checks declare Given/When journeys and all-of Evidence Capabilities. Stage/frontier state is derived from ordinary Progress and creates no second Gate, Receipt, scheduler or completion authority.
+
+After the first Authority Lock, treat `execution_model_checkpoint.required: true` as a terminal-turn boundary. Unless the user already stated an explicit task-specific choice naming current-model continuation or a model switch, end the current turn before product implementation, file edits, builds or tests and ask the user to choose `continue_current_model` or switch models and then resume. Generic continue/resume/finish/continue-goal language does not satisfy the checkpoint; later revisions do not repeat it. Harness records no model route or checkpoint acknowledgement state.
+
+During Draft authoring, proof design or authority lifecycle work, read the applicable references in the package-managed `long-task-workflow` Skill. Use `ty-context long-task help` for CLI syntax instead of treating this startup router as a command reference. Before first Authority Lock, Preflight and Compile classify current HEAD-relative workspace changes against protected paths and declared expected/support ownership; after lock, Verify and Final Gate apply the same fail-closed categories against the immutable baseline. During first enable, protection covers only exact files present in the current package asset tree for configured managed destinations plus the exact harness config/hook files; managed directory roots and broad `.codex/**` are never exempt.
+
+Final Gate, Stop and close recompile the source Contract and rerun every declared Check on one clean current snapshot. Final Gate is the Long-Task path's sole `Architecture Conformance` and selected-design closure owner; do not run either default-workflow closure. Required targets cannot substitute for one another; presence cannot prove behavior; resource integrity or `visual_render` cannot substitute for selected-target `design_conformance`; success and degradation remain distinct; typed boundary effects require an observer; unresolved design blockers remain blocking. `verify --explain` is a read-only declared-execution preview and creates no proof or Progress. Targeted verify is repair evidence only; `progress_stale` is a freshness fact, not a per-edit rerun instruction, so coalesce related edits and refresh the cheapest reliable owning Check before dependent reliance or Final Gate. 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; machine acceptance reports target/stage qualification but cannot by itself authorize completing the platform-native Goal, CI, deployment or human acceptance.
+
+Tiny Context does not create or restore platform Goals, invoke models, spawn agents, call an App Server, create branches/worktrees, merge, push, open PRs, deploy or manage process trees. `ty-context enable long-task` installs the Long-Task Workflow Skill, the retired Source Plan compatibility pointer and package-owned completion Hook.
+
+## Durable Facts And Generated Surfaces
+
+- Context is intended ownership/boundary/contract truth; code is current implementation truth. Treat disagreement as drift, missing work or stale Context.
+- Long-term facts live only in `project_context/**` or `DESIGN.md`; adopted decision-relevant design targets remain Context-reachable project Source/verifier inputs through stable keys and exactly one canonical adoption record rather than becoming Context themselves. Generated implementation screenshots/diffs, logs, raw evidence, secrets, runtime state and receipts do not become Context.
+- Managed `AGENTS.md` blocks, `<harnessRoot>/ty-context-managed/**` and package-managed Skills are generated and sync-overwritten.
+- Explicit upgrades use `context_harness_upgrade`; package sync never imports retired Campaign or development-period authority state.
+
+## Verification
+
+- `make validate-context`: Context recoverability.
+- `make validate-harness`: Context plus touched-source modularity.
+- `ty-context doctor`: installation health plus advisory default Context footprint and Design Authority status.
+- `node packages/ty-context/dist/cli.js package check-source`: managed-source/package parity in this source workspace.
+
+Every handoff reports exactly one of `Context: updated ...` or `Context: no durable fact change`. Never claim tests, deployment or acceptance from Context alone.

package/assets/context_templates/architecture.md

@@ -1,33 +1,33 @@
-# Architecture Context
-
-This is the restrained architecture context. Keep only facts that help a fresh agent recover system shape, boundaries and durable constraints quickly.
-
-## System Boundary
-
-- Describe what is inside this project and what external systems, providers or runtime assumptions sit outside it.
-
-## Component Map
-
-- List the smallest useful set of components, areas or context units and how they relate.
-
-## Data / Control Flow
-
-- Summarize only the durable request, event, state or data flow that is hard to infer from code alone.
-
-## 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.
+# 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.

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

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.
-
+# 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)
+
+## 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)