project-tiny-context-harness 0.11.0 → 0.12.1

package/assets/agents/.gitkeep

@@ -1 +0,0 @@
-

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

@@ -1,15 +0,0 @@
-# ty-context:managed:long-task-implementation-worker
-name = "long_task_implementation"
-description = "Package-owned 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,37 +0,0 @@
-# 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.
-
-## 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.
-- Name the stable owner and extension point, one plausible future-change/load/failure/threat scenario when it explains the constraint, and any bounded debt/exception lifecycle. Do not create a generic quality checklist or duplicate exact product/technical values owned by a contract or other Context.
-
-## Verification Implications
-
-- 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.

package/assets/context_templates/area.md

@@ -1,40 +0,0 @@
-# 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.
-- 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
-
-- 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.

package/assets/context_templates/context.toml

@@ -1,46 +0,0 @@
-# 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.
-# A monorepo may place only Context-bearing implementation workspaces under
-# project_context/workspaces/<workspace-id>/**. Each represented Context workspace
-# maps one code root through existing area root/context fields and may contain several Areas.
-# Keep cross-workspace Areas under project_context/areas/**; do not create empty
-# Context directories for code workspaces with no durable facts.
-# Prefer a small top-level repository-common default Area; keep workspace-local
-# Context on-demand unless its facts are genuinely near-universal.
-# Use read_policy = "default" only for near-universal recovery facts; prefer
-# "on-demand" for specialized architecture, contract, deployment or history detail.
-# Default/on-demand selection defines the starting read set, not a maximum:
-# widen to any relevant area/shared Context when task dependencies require it.
-# This optional sparse mirror adds no workspace schema or read/edit ACL. Use
-# project-owned scope checks for task-local intended/supporting changed paths.
-# Schema v4 also accepts legacy always/optional/never-default values without
-# reinterpreting them. Doctor warns, but migration is explicit: only default is
-# directly selected and every registered default_children target is selected.
-# `ty-context doctor` reports default and all-Context advisory diagnostics.
-# Experimental `ty-context route` is read-only and does not replace the
-# Workflow-required bounded Context search.
-# 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 +0,0 @@
-# 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 +0,0 @@
-# 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)

package/assets/context_templates/product-surface-contract.md

@@ -1,70 +0,0 @@
-# Product Surface Contract
-
-## Purpose
-
-This Context records durable responsibilities for user-facing Product Surfaces in this project or product domain.
-
-Write only project-specific facts that should guide future implementation. Do not copy generic platform rules, one-off audit notes, screenshots, test logs, implementation summaries, visual tokens or secrets into this file.
-
-## Surfaces
-
-### `<surface name>`
-
-- Surface:
-- Surface Platform:
-- Owning Product Domain:
-- Primary User Question:
-- Surface Type:
-- Main Surface Allows:
-- Main Surface Forbids:
-- Drilldown Ownership:
-- Long Task State Requirement:
-- Design Rationale:
-- Empty / Loading / Stale / Unavailable:
-- Security / Redaction:
-- Verification:
-
-## Cross-Surface Rules
-
-- `<durable project-specific rule>`
-
-## Screen Contract Routing
-
-Keep this file at cross-surface responsibility depth. When one material screen needs durable entry/exit/shared-state, information hierarchy, semantic region order, fixed/scroll/overlay ownership, navigation, variants, material controls or design-target references, create an on-demand Screen Contract from `screen-contract.md` using an existing area/subdomain role (or `contract` only for a true cross-area interface).
-
-Link by stable surface/control/target keys. Do not duplicate the Screen Contract here, copy exact visual tokens from `DESIGN.md`, or embed authored target binaries and test evidence.
-
-## Registration Example
-
-Use the existing `contract` role for cross-surface or cross-area contracts:
-
-```toml
-[[context]]
-path = "project_context/areas/product-surface-contracts.md"
-role = "contract"
-triggers = ["surface", "screen", "ui", "ux", "web", "app", "mobile", "desktop", "game", "cli", "tui", "页面", "界面", "屏幕", "产品接触面", "信息架构", "页面职责", "界面职责", "product surface"]
-read_policy = "on-demand"
-```
-
-If using front matter in a Context Markdown file, use `context_role: contract`; do not use `role = "contract"` in Markdown front matter.
-
-## Maintenance Rules
-
-Update this Context when:
-
-- A surface responsibility changes.
-- Main/drilldown ownership changes.
-- A durable long-task state contract is introduced.
-- A durable main/drilldown/diagnostic ownership rationale, rejected alternative or tradeoff will guide future changes.
-- A repeated UI/product rule becomes reusable.
-- A platform-specific interaction rule becomes stable.
-- Cross-surface ownership changes which Screen Contract owns a detail.
-
-Do not update this Context for:
-
-- CSS-only fixes.
-- One-off screenshot observations.
-- Temporary audit notes.
-- Test logs.
-- Local implementation summaries.
-- PR notes, command output, screenshot review notes, debug history, agent reasoning or rationale inferred only from current code shape.

package/assets/context_templates/screen-contract.md

@@ -1,205 +0,0 @@
-# Screen Contract
-
-## Purpose
-
-This optional on-demand Context records durable responsibility, information hierarchy and interaction semantics for one user-facing screen/surface when a Product Surface Contract is too coarse for future implementation and verification.
-
-A screen may be a Web route, mobile screen, desktop window, game HUD/menu scene, CLI/TUI view, extension panel, kiosk or embedded-device interface. Use only the relevant sections. Do not create a Screen Contract for a semantics-preserving CSS/style fix, one-off UI bug or explicit throwaway prototype.
-
-Write project-specific facts only. Do not copy visual token values, binary targets, implementation screenshots, test logs, raw payloads, implementation summaries or secrets into this file.
-
-## Authority Boundary
-
-- Product Surface Contract owns cross-surface responsibility, main/drilldown placement and shared invariants.
-- This Screen Contract owns stable screen hierarchy, regions, state/navigation behavior, durable material-control semantics and canonical adoption records for one-screen/interaction-specific targets.
-- `DESIGN.md` owns visual-system semantics, the authored token source/generation direction and canonical adoption records for project/system/component-family targets.
-- Versioned authored design targets own their declared concrete composition for named viewport/mode/state/content conditions.
-- Verification Context owns repeatable proof paths. Code is current implementation evidence, not silent design authority.
-
-If these owners conflict, update the stale owner or retain a genuine decision. Do not resolve a conflict from file order, current code shape or an implementation-generated screenshot.
-
-## Screen Identity
-
-- Surface Key:
-- Surface / Route / Command:
-- Platform:
-- Owning Product Domain:
-- Target User / Usage Context Reference:
-- Primary User Question:
-- Primary Task Outcome:
-- Primary Work Object:
-- Primary Task Loop:
-- In-Scope User Tasks:
-- Explicit Non-Goals:
-
-## Entry, Exit And Shared State
-
-- Entry Context / Preconditions:
-- Entry Points / Deep Links:
-- Inherited Shared State:
-- Locally Editable State:
-- Committed State Changes:
-- Exit Outcomes / Destinations:
-- Back / Cancel / Interruption Behavior:
-- Focus / Selection Restoration:
-
-## Information Hierarchy
-
-Record semantic order and responsibility, not pixel coordinates.
-
-1. Primary judgment:
-2. Primary action:
-3. Supporting information:
-4. Secondary actions:
-5. Drilldown / evidence / diagnostics:
-6. Information forbidden from permanent main-surface placement:
-7. Critical context that must remain visible while acting:
-
-## Layout Contract
-
-### Regions
-
-| Region Key | Order | Responsibility | Fixed / Scroll / Overlay | Visibility Conditions |
-|---|---:|---|---|---|
-| `<region-key>` | 1 |  |  |  |
-
-### Spatial And Container Ownership
-
-- Safe-area / system-chrome ownership:
-- Fixed or sticky elements:
-- Scroll owner and restoration:
-- Overlay / modal / sheet owner:
-- Map / canvas / media visible-area contract:
-- Keyboard / input-method behavior:
-- Gesture competition / pointer ownership:
-- Repeated-scroll / navigation / context-switch boundary:
-- Client / host constraints:
-
-## Task Loop And Feedback
-
-- Primary operation sequence:
-- Operation–affected-object relationship:
-- Progress / success / failure feedback relationship:
-- Commit / cancel / retry / undo / recovery:
-- Work-object visibility and focus/selection restoration:
-
-## Control Inventory
-
-Each material control has a stable semantic key. Fill only applicable fields; do not add generic filler for non-applicable states.
-
-### `<control-key>`
-
-- Surface:
-- Region:
-- Location:
-- Control Type:
-- Label / Content:
-- User Task:
-- Visibility:
-- Availability:
-- Trigger:
-- Input:
-- Validation:
-- Default Value / Restored State:
-- Interaction / Commit / Cancel:
-- Navigation / Result:
-- Loading State:
-- Empty / No-Result State:
-- Success State:
-- Failure / Degraded State:
-- Recovery / Retry / Interruption:
-- Permission / Denial Path:
-- Feedback:
-- Accessibility / Keyboard / Focus / Motion Alternative:
-
-## Screen State Variants
-
-Describe composition or responsibility changes, not one-off screenshots.
-
-- Initial / loading:
-- Empty / no results:
-- Partial / stale / degraded:
-- Error / unavailable:
-- Permission denied:
-- Disabled / saving / mutating:
-- Success / confirmation:
-- Offline / recovery when applicable:
-
-## Responsive, Mode And Content Variants
-
-- Viewport / size-class boundaries:
-- Size-class interaction topology (remain / reflow / collapse / sheet / sidebar / modal / separate surface):
-- Orientation / window-resize behavior:
-- Theme / product-mode differences:
-- Text scaling / localization / long-content behavior:
-- Reduced motion / contrast / input-mode differences:
-- Other explicitly unsupported combinations:
-
-## Navigation And Interaction Contract
-
-- Forward navigation and committed state:
-- Back / system-back / predictive-back behavior:
-- Deep-link behavior:
-- Modal / sheet / popover lifecycle:
-- Gesture ownership and accessible alternative:
-- Cancellation, interruption and recovery:
-- Cross-surface state/version consistency:
-
-## Design Target References
-
-Reference project-native targets; do not embed binary content. Every adopted target has exactly one canonical adoption record. Use this Screen Contract as the canonical owner only for a one-screen/interaction-specific target. For a project/system/component-family target owned by `DESIGN.md`, fill only its stable ID, `DESIGN.md` anchor and this screen's local applicability; do not repeat the full record.
-
-| Target ID | Canonical Owner / Anchor | Interpretation | Immutable Adopted Path / URI + Digest | Editable Upstream / Owner / Update Route | Declared Condition Coverage | Selection Basis | Local Applicability |
-|---|---|---|---|---|---|---|---|
-| `<stable-target-id>` | `this Screen Contract#...` / `DESIGN.md#...` | `exact-target` / `constraint` / `inspiration` |  |  |  |  |  |
-
-The canonical record owns interpretation, selection basis, immutable locator/digest, declared condition coverage and editable upstream/update route. Leave those fields pointer-only when this Screen Contract is not the canonical owner. An `exact-target` authorizes fidelity comparison only for its declared conditions. A `constraint` governs only its named rule. `inspiration` does not authorize reproduction. For an adopted exact target/constraint, the immutable locator must be readable and the editable upstream/update route must be verified or explicitly marked as a manual/external boundary. Relevant work opens the resource rather than treating this row as consumption. Update upstream and register a new immutable version/digest in the canonical record; never overwrite the adopted baseline. An implementation screenshot cannot register itself as its own target.
-
-### Selected Implementation Handoff
-
-- Handoff Source Path:
-- Handoff Scope Key:
-- Affected Subject / Target Keys:
-- Durable Owner / Update Boundary:
-
-Fill this pointer only when selected implementation resources use a validated `design-resource-handoff-v1`. The handoff remains ordinary Source and owns its strict subject-by-eight-dimension condition/evidence/verification index; do not duplicate that changing index into Context. This Screen Contract owns durable screen/control meaning and makes the handoff/targets reachable. Consumers must rerun shared preflight and open affected exact/constraint resources; neither this pointer nor a successful digest proves implementation conformance.
-
-## Verification
-
-- Semantic / information-hierarchy check:
-- Control behavior / state check:
-- Visual target / layout check:
-- Accessibility / focus / motion check:
-- Cross-surface shared-state check:
-- Target-runtime / native-device check:
-- Human or external confirmation boundary:
-- Known unproved combinations:
-
-## Stable Design Rationale
-
-- Decision:
-- Reason:
-- Rejected alternative when still decision-relevant:
-- Tradeoff that must guide future changes:
-
-Do not invent rationale from current implementation shape. Record a rejected alternative or tradeoff only when it is durable enough to constrain future screen decisions.
-
-## Registration Example
-
-Use an existing role. A screen owned by one domain normally uses `subdomain` (or the owning `area` file when small); use `contract` only when the screen itself is a cross-area interface.
-
-```toml
-[[context]]
-path = "project_context/areas/<area>/screens/<screen>.md"
-role = "subdomain"
-triggers = ["<surface-key>", "<route>", "<screen name>", "<material control key>"]
-read_policy = "on-demand"
-```
-
-Do not introduce `screen`, `design`, `surface-contract` or another custom role.
-
-## Maintenance Rules
-
-Update this Context when durable screen responsibility, hierarchy, region ownership, navigation/shared-state behavior, responsive/mode semantics or reusable material-control behavior changes.
-
-Do not update it for CSS-only fixes, one-off screenshot findings, generated diffs, temporary audit notes, test logs, command output, implementation summaries, PR notes or rationale inferred only from current code.

package/assets/context_templates/verification.md

@@ -1,35 +0,0 @@
-# Verification Context: main
-
-This role Context records critical repeat-execution paths for the owning area. Keep it minimal: enough for a future agent to rerun verification without rediscovering setup, not a test report.
-
-## Owner
-
-- Owning area: `main`.
-
-## Verification Paths
-
-- `npm test` or the shortest project-specific test, smoke, CI, probe or validation command.
-- Verification paths are reusable execution instances, not independent definitions of the verification target. For capability, metric or acceptance claims, first use the owning module's design Context to decide what claim should be proven, then choose the command or probe.
-- Prefer project-native type/compiler/lint/architecture/contract/behavior/benchmark/probe paths. Name what each path can and cannot falsify; a broad pass, Harness heuristic or static shape signal must not be presented as overall code quality or runtime-performance proof.
-- For a multi-workspace repository with a project-owned changed-path/target-scope verifier, record its stable command and inputs here. It validates intended workspace(s) plus allowed supporting changes for task-attributable paths; it does not restrict which Context or code may be read.
-
-## Required Preparation
-
-- List only durable setup such as services, env files, fixtures, local runtimes or external dependencies needed before rerun.
-
-## Expected Signals
-
-- Name the stage, health check, status, artifact shape or observable signal that means the path reached the intended point.
-- For repeatable performance/capacity checks, record the stable workload/fixture, metric, environment or environment class, baseline or budget, comparator/tolerance and result location. Keep one-off measured values and pass/fail claims out of Context.
-
-## Acceptable Warnings
-
-- List warnings that are expected and should not trigger repeated investigation.
-
-## Excluded Dead Ends
-
-- List previously ruled-out commands, providers, endpoints or setup paths only when remembering them prevents repeated wasted work.
-
-## Forbidden Content
-
-- Do not record one-off logs, full command output, temporary JSON, CI artifacts, test reports, secrets, tokens, cookies, device ids, raw payloads or pass/fail claims.

package/assets/github/.gitkeep

@@ -1 +0,0 @@
-

package/assets/github/harness.yml

@@ -1,41 +0,0 @@
-# ty-context:github-workflow:begin
-name: Harness Gates
-
-on:
-  pull_request:
-  push:
-    branches:
-      - main
-  workflow_dispatch:
-    inputs:
-      gate:
-        description: "Make target to run"
-        required: true
-        default: "validate-context"
-        type: choice
-        options:
-          - validate-context
-          - validate-code-modularity
-          - validate-harness
-
-jobs:
-  harness:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
-        with:
-          fetch-depth: 0
-      - uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6.4.0
-        with:
-          node-version: "24"
-      - name: Prepare source workspace CLI
-        if: ${{ hashFiles('packages/ty-context/package.json') != '' }}
-        run: |
-          npm ci
-          npm run build --workspace project-tiny-context-harness
-      - name: Run harness gate
-        run: make "${HARNESS_GATE}"
-        env:
-          HARNESS_GATE: ${{ github.event.inputs.gate || 'validate-harness' }}
-          TY_CONTEXT_MODULARITY_BASE: ${{ github.event_name == 'pull_request' && format('origin/{0}', github.base_ref) || github.event.before || '' }}
-# ty-context:github-workflow:end

package/assets/make/.gitkeep

@@ -1 +0,0 @@
-

package/assets/make/ty-context.mk

@@ -1,48 +0,0 @@
-PYTHON ?= python3
-TY_CONTEXT ?= $(if $(wildcard packages/ty-context/dist/cli.js),node packages/ty-context/dist/cli.js,npx --yes --package project-tiny-context-harness@latest ty-context)
-TY_CONTEXT_MODULARITY_SCOPE = $(if $(TY_CONTEXT_MODULARITY_BASE),--base $(TY_CONTEXT_MODULARITY_BASE),--touched)
-
-.PHONY: help ty-context-doctor ty-context-sync ty-context-upgrade ty-context-check-modularity validate-context validate-code-modularity validate-harness lint test-current-domain test-all build
-
-help:
-	@echo "Minimal Context Harness commands"
-	@echo "  make ty-context-doctor         Diagnose Harness root, core package and schema version"
-	@echo "  make ty-context-sync           Refresh managed assets; does not run migrations"
-	@echo "  make ty-context-upgrade        Run safe upgrade migrations, sync managed assets and doctor"
-	@echo "  make ty-context-check-modularity  Warn on oversized touched handwritten source files"
-	@echo "  make validate-context    Check whether project_context/** supports context recovery"
-	@echo "  make validate-code-modularity  Fail on oversized touched handwritten source files"
-	@echo "  make validate-harness    Run validate-context and validate-code-modularity"
-	@echo "  make test-all            Run the project regression suite after replacing this placeholder"
-
-ty-context-doctor:
-	$(TY_CONTEXT) doctor
-
-ty-context-sync:
-	$(TY_CONTEXT) sync
-
-ty-context-upgrade:
-	$(TY_CONTEXT) upgrade
-
-ty-context-check-modularity:
-	$(TY_CONTEXT) check-modularity $(TY_CONTEXT_MODULARITY_SCOPE)
-
-validate-context:
-	$(TY_CONTEXT) validate-context
-
-validate-code-modularity:
-	$(TY_CONTEXT) check-modularity $(TY_CONTEXT_MODULARITY_SCOPE) --fail-on-warning
-
-validate-harness: validate-context validate-code-modularity
-
-lint:
-	@echo "No project lint command configured yet. Replace this target with your stack-specific lint command."
-
-test-current-domain:
-	@echo "No domain test command configured yet. Replace this target with focused tests for the current change."
-
-test-all:
-	@echo "No full test command configured yet. Replace this target with the project regression suite."
-
-build:
-	@echo "No build command configured yet. Replace this target with the project build/package command."