project-tiny-context-harness 0.2.57 → 0.2.59

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,53 +1,53 @@
-# 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 the minimum background a fresh agent needs before changing code.
-
-## Design Rationale
-
-- Record durable choices that are hard to infer from code or tests. 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.
-
-## Verification Entry Points
-
-- Point to the default verification context for repeatable test, smoke, CI or validation paths.
-- Project-level cross-domain verification may live here only as a short index; execution details belong in `verification` role Context.
-
-## Current State
-
-- Summarize what is implemented, blocked or risky right now.
-
-## Next Safe Action
-
-- State the safest next step for a fresh agent, including whether the next change should update Context before code.
-
-## Context Index
-
-- [main](areas/main.md)
-- [main verification](areas/main/verification.md)
+# Project / Delivery Context
+
+## Project Goal
+
+- Describe the user-visible goal this project is trying to achieve.
+
+## Non-goals / Boundaries
+
+- List what this project intentionally does not do.
+
+## Background
+
+- Capture the minimum background a fresh agent needs before changing code.
+
+## Design Rationale
+
+- Record durable choices that are hard to infer from code or tests. 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.
+
+## 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)

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

@@ -1,60 +1,60 @@
-# 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:
-- Empty / Loading / Stale / Unavailable:
-- Security / Redaction:
-- Verification:
-
-## Cross-Surface Rules
-
-- `<durable project-specific rule>`
-
-## 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 repeated UI/product rule becomes reusable.
-- A platform-specific interaction rule becomes stable.
-
-Do not update this Context for:
-
-- CSS-only fixes.
-- One-off screenshot observations.
-- Temporary audit notes.
-- Test logs.
-- Local implementation summaries.
+# 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:
+- Empty / Loading / Stale / Unavailable:
+- Security / Redaction:
+- Verification:
+
+## Cross-Surface Rules
+
+- `<durable project-specific rule>`
+
+## 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 repeated UI/product rule becomes reusable.
+- A platform-specific interaction rule becomes stable.
+
+Do not update this Context for:
+
+- CSS-only fixes.
+- One-off screenshot observations.
+- Temporary audit notes.
+- Test logs.
+- Local implementation summaries.

package/assets/context_templates/verification.md

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

package/assets/github/harness.yml

@@ -1,41 +1,41 @@
-# 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@v6
-        with:
-          fetch-depth: 0
-      - uses: actions/setup-node@v6
-        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
+# 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@v6
+        with:
+          fetch-depth: 0
+      - uses: actions/setup-node@v6
+        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 +1 @@
-
+

package/assets/make/ty-context.mk

@@ -1,48 +1,48 @@
-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."
+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."