project-tiny-context-harness 0.11.0 → 0.12.1

package/assets/agents/AGENTS_CORE.md

@@ -1,90 +1,15 @@
-# Minimal Context Harness Protocol
+# Tiny Context development contract
 
-This project uses Tiny Context. The Harness maintains durable Context and workflow authority; project tests, CI, runtime evidence and human acceptance prove product quality. Its three capabilities are Minimal Context, the automatically applicable model-led default Workflow Contract for work of any complexity and the explicitly selected Single-Goal Long-Task Workflow for machine completion authority, recoverability and auditability. Complexity determines execution and verification depth; required completion authority and recoverability determine the workflow route; Long-Task-internal risk determines proof strength.
+Tiny Context preserves durable project facts and this short development contract. It does not manage tasks or certify product completion.
 
-## Shared Engineering Quality Obligation
+- Understand the user's requirements, default Context and relevant owners. Use clear source material directly; clarify real gaps without manufacturing plans, design documents or handoffs.
+- Start with `project_context/global.md` and project-declared defaults. `ty-context context list --default` is optional. Without the CLI, read the manifest directly: default Areas, `read_policy = "default"` nodes and their transitive `default_children`; `default_files` selects files without traversing their children. Pre-schema-5 projects also default to architecture.md. Do not install a CLI over the network merely to read files, or repeat unchanged reads. A failed query is not an empty set: resolve uncertainties material to the current change and report the remainder.
+- Identify relevant owners from the affected implementation and follow their dependencies and current controlling sources, without waiting for a trigger keyword. Reading other workspaces does not authorize editing them. Stay within the user's scope, preserve unrelated changes and respect project business, technical and safety constraints. Distinguish requirements from current implementation; do not rewrite requirements to conceal conflicts.
+- Choose implementation order, tools, decomposition and parallelism as appropriate. Before adding or materially extending a capability, inspect its owners, consumers, state/data responsibility and dependency direction. Reuse suitable capabilities from the project and target platform. Extract a shared unit when consumers must evolve together in the same responsibility, including a shared role already required on first implementation; migrate affected consumers within scope. Avoid speculative abstraction and unification based only on appearance, size or repetition. Complete the required change.
+- Before adopting a new dependency or building substantial custom machinery, consider suitable mature alternatives. Reuse decisions whose conditions still hold; bound investigation to material gaps in target support, behavior, customization, maintenance, license and integration cost. Use a small runtime trial when needed to resolve uncertainty. Suitability, not popularity, decides; justified custom implementation remains valid. Local fixes do not trigger a new selection exercise.
+- UI may be implemented and iterated directly from conversation, references and code; an independent design system or formal handoff is not a prerequisite. Reuse confirmed direction and shared components. For affected UI with adopted resources, follow the owner's current reference and scope, actually view current visual references and inspect relevant prototypes or source and behavior descriptions. Adopted resources are requirements within their declared scope. Implement faithfully in the target runtime, compare actual results under relevant comparable conditions and repair deviations. Resolve and report inaccessible inputs, conflicts or platform limits; continue independent work. Do not silently replace confirmed designs. Ordinary repairs reuse current resources without regeneration or renewed adoption; authorized design changes update affected resources and owners.
+- Choose checks based on requirements, risk and project rules, including changed boundaries, affected consumers and relevant lifecycle/failure behavior. Reuse existing tests, add meaningful regressions when needed and observe actual outputs. Derive expectations from requirements rather than copying implementation. Repair failures and rerun affected checks after relevant input changes; do not repeatedly broaden checks without a new change, failure or specific concern.
+- Update the owning Context only when durable project facts change. Keep project-specific goals, boundaries, confirmed decisions (including adopted/rejected choices), reasons, material reassessment conditions and useful entrypoints; reference exact values rather than duplicating code. Keep current resource references and scope with their owner, resources outside Context, and indices as navigation; repair relevant stale references. Optional cross-session handoff information and temporary investigation records stay task-local, outside durable Context.
+- Report implementation, decisive tradeoffs, actual checks and material unresolved items honestly. Explain unverified scope and necessary human action. Installed instructions, structural validation, design adoption, static previews, historical results, tool success and subagent summaries do not establish current product correctness or agent compliance.
 
-Before the first implementation edit, every delivery surfaces one externally observable, repository-bound `Architecture Deliberation`. Depth is risk-proportional, but the checkpoint always names affected owners, the current extension point/source of truth, dependency and state/lifecycle boundaries, the selected design and material alternatives, one plausible future-change challenge, touched technical debt and its disposition, forbidden shortcuts, project-owned checks and triggered engineering-quality attributes or their concrete preservation basis. Correctness/invariants and maintainability/changeability always receive at least a preservation judgment; reliability/resource lifecycle, concurrency/consistency, performance/capacity/cost, security/privacy/safety, compatibility/migration/rollout and operability/observability/testability activate only when the change or an explicit claim makes them material. Exact product/technical predicates remain owned by Semantic Facts and exact selected UI/UX values by selected-design closure. Refresh the checkpoint when scope, ownership, selected design, quality applicability or debt disposition materially changes.
-
-When foundational machinery, a mature protocol/security boundary, a dependency/shared abstraction or a nearby extension point makes sourcing material, include a risk-triggered `Build / Reuse / Buy` judgment. Record an allowed solution set, prohibited failure modes and required rationale/evidence; do not prescribe one library or abstraction. Reusing an owner, the standard library, an installed dependency, a mature compatible external library, a bounded self-implementation and intentional non-abstraction may all be valid. Enumerate every materially supported member before selection; choosing one never removes another supported member from the allowed set or turns it into a prohibited failure. Judge the task's viable set, not one rejected proposal: when at least one supported allowed choice exists, allow and select one; block only when no supported allowed choice exists, and reserve decision-required for a genuine external choice. Reject duplicate owner-held rules, extension-point bypass, unjustified heavy dependencies, plainly incomplete security-sensitive reinvention, license/platform incompatibility, forced abstraction over merely similar semantics and a second source of truth. This adds no mandatory open-source/DRY rule, quality score, stage or Gate.
-
-Implementation order, method and feedback cadence remain Goal-owned. Reuse the owning service/facade/adapter and one source of truth, keep the change minimal but complete, preserve explicit failure and resource-lifecycle semantics, and add abstraction only for a stable concept or evidenced change axis. These are guardrails, not a phase, per-edit mandate or proof that code is globally clean.
-
-After implementation and project verification, perform one current-candidate `Engineering Quality Conformance` that includes `Architecture Conformance` and every triggered falsifiable invariant. Default work embeds it in Contract Conformance; an active Long-Task embeds it only in Final Gate through existing Source-backed obligations/constraints/forbidden shortcuts, owner/path/Bindings, executable Checks and independent Assertions when functional behavior could pass separately. Never schedule both carriers, and recheck after any candidate or controlling-input change. Final Gate proves only that declared project-check-bound set, not overall code quality. A performance claim additionally requires a workload, metric, baseline or budget, environment, comparator/tolerance and project-owned measurement; static shape is not runtime proof. New/worsened debt, duplicate truth, wrong dependency direction, owner bypass, silent failure, resource-lifecycle defect, scope escape, unsupported quality claim or forbidden shortcut blocks handoff unless a bounded project-owned exception records owner, rationale, tracking and removal condition. This creates no quality artifact, matrix, second Authority, Contract field/aspect/Claim/risk type, Gate, workflow state or generic analyzer.
-
-## Default Workflow Contract
-
-Unless a valid Long-Task binding is active or the user explicitly selects Long-Task, this prompt-level protocol applies automatically regardless of duration, complexity or file count. It guides model-led Agent execution but creates no validator result, exact Fact/Obligation ledger, Receipt, persisted phase state or machine-completion authority.
-
-1. Read `project_context/global.md`, `project_context/architecture.md`, `project_context/context.toml` and the default area root, then collect graph/trigger candidates.
-2. Before deciding `Context Delta`, run one bounded text search over `project_context/**` using a small high-signal set: explicit area/module names plus relevant API/schema/state/security/verification/deployment terms. Merge matches with manifest candidates, read relevant Context and widen whenever another Area/shared dependency becomes relevant; search supplements rather than replaces semantic judgment.
-3. In a monorepo or otherwise multi-target repository, separate the expandable read scope from the task-local intended workspace(s). An optional sparse `project_context/workspaces/<workspace-id>/**` directory maps each represented Context workspace to one code root through existing manifest `root/context`; workspace-local Areas own semantic responsibilities inside it, cross-workspace Areas stay top-level, and code workspaces without durable Context need no empty mirror. Keep the monorepo default Area small and repository-common; workspace-local Context stays `on-demand` unless genuinely near-universal. This structure/default/read policy is neither a read ACL nor edit authorization. Resolve intended workspaces from explicit user/product/path/repository facts; if materially different siblings remain ambiguous, ask one concise target question before product edits. Enumerate intentional multi-workspace targets and supporting/shared scope.
-4. For every material non-UI product or technical change, understand all explicit user, Context, specification and selected-constraint requirements at risk-proportional depth. Identify affected owners, material conditions, failure boundaries and real acceptance entries; do not let current code redefine Source or turn missing authority into an implementation default. This is task reasoning, not an Expected Fact Universe or proof ledger.
-5. For UI/product-surface work, confirm information/action/feedback ownership and use `context_surface_contract` when durable responsibility is unclear or changes. Root `DESIGN.md` remains the current shared project Design Authority; Context workspace placement does not create independent design systems. For material UI, reconcile affected stable surface/control/target keys as Context-covered, requiring a Context update, task-local, out of scope or decision-required; traverse owning Context and `DESIGN.md`; and open every affected selected `exact-target` or `constraint`. Missing, stale, unreadable or conflicting authority fails closed for the affected claim. Local fixes and explicit non-fidelity prototypes stay lightweight.
-6. Complete `Architecture Deliberation`, including applicable-quality routing or a concrete preservation basis, then decide exactly one `Context Delta: none|required`. Update owning Context before code for durable product ownership, architecture, API/schema/data, state/recovery, dependency, security, product-surface responsibility or repeatable verification/deployment change. Local fixes preserving durable semantics are `none`.
-7. Use the agent/platform internal plan. Keep `Architecture Context Hit`, `Decision Rationale Hit: existing|required|none` and `Modularity Check: none|required|exception` as internal routing questions, not artifacts or extra deltas.
-8. Implement precisely under the Goal-owned quality guardrails and run project-owned verification. When a check fails or exposes a missed requirement, wrong owner, design mismatch, scope escape, Context drift, stale evidence or new debt, localize it to the requirement/owner/module/check, repair it and rerun affected checks. After the last relevant code, configuration, Source or controlling-Context change, rerun every affected check on the current candidate; historical CI, pre-fix results, delegated reports and prose inspection are not current evidence. When the repository exposes a changed-path/target-scope check, run it against the intended/supporting targets and exact task-attributable paths; otherwise review the final diff against durable owners during Conformance. Do not attribute unrelated pre-existing dirty paths to the task without provenance. Perform evidence-bounded Contract Conformance including `Engineering Quality Conformance`, its `Architecture Conformance` subset and any applicable source/design checks below, then run the separate Context drift check. Report `Implemented`, `Verified`, `Unverified`, `Blocked / decision required`, engineering/architecture conformance and Context status; never fold unverified or externally pending scope into a complete claim. For material UI, use the first useful independently runnable production slice as a recommended real-entry feedback point when its expected early-localization value exceeds the run cost; it is not a prerequisite for expanding implementation. Always rerun the affected cold-start journey on the final candidate. Detached routes, specimens and deep links remain supplemental.
-
-The default workflow never requires a plan artifact, target declaration, matrix, verdict, evidence ledger or result document. Optional scratch is not Context or proof. Bounded Context search creates no index, cache, state or second authority; it also creates no read isolation. Missing, stale, unreadable or conflicting controlling Source, a materially ambiguous target, an unsupported observation boundary or a failed/stale check blocks an unqualified handoff for the affected scope: widen reading or verification only as discovered dependencies and risk require, then report any remaining qualification. Do not make the full Context graph the default or add a required Context directory for every package-manager workspace, workspace/applicability schema, automatic topology scan, migration, target registry, generic path/import/runtime scanner or duplicate Long-Task scope classifier.
-
-## Non-UI Source And Assurance Boundary
-
-Both routes preserve Source authority: explicit product, business, API, data, state, failure, security, privacy, compatibility, performance, operational and architecture requirements cannot be silently omitted or redefined from current code. Genuine user/product/legal/security/commercial/safety/external choices remain decision-required. Default work identifies material requirements, conditions, owners and acceptance boundaries at risk-proportional depth, implements them through their real owners, uses attributable current-candidate project checks and reports anything not established. It does not maintain stable Fact/Obligation identities, exact set equality, a universal condition expansion, frozen Oracle/environment rows or a complete result ledger.
-
-An active Long-Task owns the exact non-UI semantic carrier instead. Its package-managed Skill and progressive references preserve the complete Source inventory/Census, standard plus custom semantic families, atomic Fact and condition identities, Fact×required-method obligations, comparison authority, current typed results and sole Final-Gate equality. Never run a nested default semantic closure. Durable meaning still belongs in its existing owning Context; Source remains task authority, code remains implementation truth and Contract stores bindings rather than copied values. Neither route can discover unexpressed intent or prove an arbitrary Oracle semantically sound.
-
-Every machine-closing Long-Task Claim or Fact×method obligation must compile to a package-admitted current-Actual channel. The first bounded slice is plain exact JSON only: either a static implementation/configuration carrier that existed in the pre-run snapshot and is byte/identity unchanged after the runner, or a `process` product root directly spawned and observed by Harness through one temporary `ty-context-product-observation-v1` envelope. Harness owns comparison/result identity/verdict and process-runtime derivation. Custom/named project Oracles, wrappers, project actual/pass/verdict/runtime/interaction/state rows, historical sessions, browser/native/device/layout/pixel/accessibility/motion, protected values, tolerance/mask and custom locators cannot machine-close the obligation and require blocking External Confirmation. A machine Counterfactual without admitted baseline/mutated actual fails; static structure never proves runtime reachability. Public project results remain v3, and this compiled projection adds no Contract Authority, Gate, state or Observer registry.
-
-## Selected-Design Conformance Obligation
-
-This obligation activates only for a selected implementation handoff. Run `ty-context design-resource preflight <handoff.md>` before UI Authority Closure. A formal Web/App target needs one completely acquired machine-readable canonical entry, its exact dependency closure and one frozen-Inspector observable-Fact manifest. Authoring derives the complete scoped `subject × target × condition × variation × atomic property` Expected Fact Universe before generation; complete Census, axis/combination/property expansion, explicit N/A/exclusions and non-sampling/non-truncation must prove `Expected Fact Universe = Canonical Resource Facts = Handoff Indexed Facts`. Product Control and eight-dimension roll-ups are not the Fact ceiling. Preserve exact located values and design-system lineage in canonical resources, every property-required Fact × method obligation, comparator/tolerance/mask, Oracle/environment and sensitive-observation policy; an exact target also needs full-target layout and pixel Facts for every condition. Deliberately partial input remains a constraint or blocking unresolved. Incomplete acquisition, aggregate labels, unreadable Census/locators, missing/extra Fact Cells or proofs, unresolved conflicts/blockers, unsupported evidence or stale digests fail closed. Preflight proves input completeness/integrity relative to the named Inspector/Oracle TCB, never production conformance.
-
-UI symbolic V2 is explicit opt-in; V1 remains the default. A V2 target must preserve the complete extensional `subject/relation × target × reachable condition/variation × applicable atomic property × population/quantifier` denotation, with constant located Rule values, mutually exclusive exhaustive regions and distinct Fact Rule, proof-obligation and set-valued certificate identities. Applicability may retain exact physical remainder partitions or use package-owned subject property profiles plus frozen Inspector custom-property closure and explicit unique instance exceptions; every logical subject-property point still has exactly one disposition. An omitted axis requires both Source-side and production-side proof through frozen closed-world static dependency closure, restricted-IR exact equivalence or finite complete-domain exhaustive equivalence; dynamic/reflected/unfrozen/external or sampled dependencies block. One Contract may mix V1 and V2 targets; bind V1 to exact Fact results and V2 to exact Rule-method-region plus freshly recomputed certificate results in the existing sole Final Gate. V1 admission uses stat/bounded-prefix capacity checks and fails rather than truncating or silently switching. Purpose-fulfillment efficiency non-degradation is a package mechanism-change admission property, not an AcceptedDeliveryTerminal condition. Non-UI symbolic admission remains out of scope; machine-observer and verifier/runner trust-boundary closure is mandatory rather than deferred Provider/P0 work.
-
-Every non-interference proof needs a digest-identified frozen executable Oracle with the exact `symbolic_noninterference.<side>.<method>` capability. Source proof uses one canonical package-owned restricted Source IR in the complete current Inspector inputs; the package binds its current bytes to target/certificate/Rule scope and derives the DAG, predicate or complete finite-domain evaluation itself. Submitted graph/predicate/evaluation/pass fields and the immutable artifact are cache/bindings only: preflight requires current recomputation, artifact bytes and proof cache to agree, while excluding the artifact from semantic inputs. Executable/CSS/implicit-DOM/template/dynamic/reflected/computed/unfrozen/external Source blocks. Production remains limited to the package-parsed static HTML plus inert JSON subset. Both sides bind implementation closure/version/capability, environment, exact current inputs, side snapshot, scopes, omitted axes, method result, artifact and witness; their proof digests bind the existing current Final-Gate certificate result. Extraction outside admitted representations remains an explicit TCB boundary.
-
-Every adopted target has exactly one canonical record: `DESIGN.md` for project/system/component-family scope or the owning Screen Contract for one-screen/interaction scope. It owns interpretation, selection basis, immutable locator/digest, conditions and editable-upstream update route; other layers keep only a stable key, owner/anchor and local applicability. Use the on-demand UI/UX Skill for Design Source Projection. Never overwrite an adopted baseline; create a new immutable version and update its canonical record.
-
-Externally authored resources remain ordinary Source. Authoring Skills do not change Context, code or Contract and do not claim acceptance.
-
-For every external product, architecture, technical or acceptance constraint, internally classify it as Context-covered, requiring a Context update, task-local, out of scope or decision-required. Conformance confirms it reached the correct owner and verification.
-
-Default work opens every affected selected `exact-target` or `constraint` and its declared conditions, routes it to the real production owner and cold-start journey, and runs applicable project-native visual, interaction, accessibility or runtime checks on the final candidate. It reports conditions those checks did not establish and does not claim that preflight input integrity proves production conformance. It does not rebuild the complete Fact Cell universe or retain per-Fact-by-method result rows. An active Long-Task instead projects the exact obligation into existing Source/Claims/Assertions/bindings, `fact_expectations`, `fact_results` and Final Gate and never also runs a default closure.
-
-## Long-Task Routing
-
-Route by required assurance, not task size. Select Long-Task when stable machine obligations, current-snapshot machine completion authority, cross-compaction/session recovery or auditability are explicitly required; its extra authoring and verification cost is not a promise of lower time or token use. A small consequential rule may use it and a complex cross-module change may remain default. Do not infer long-task mode from duration, complexity, file count or agent preference.
-
-1. A valid Git common-dir active record plus matching worktree Git-config marker resumes with `ty-context long-task resume <workdir>` in the currently selected host execution Goal; directly load and follow the installed package-managed `long-task-workflow` Skill. This recovery path does not depend on implicit invocation.
-2. An explicit selection of the logical `long-task-workflow` Skill authors or resumes exactly one complete `long-task-delivery-v2` Contract. In Codex, select it with `$long-task-workflow` or through `/skills`.
-3. Otherwise remain on the default Workflow Contract.
-
-“One native Goal” is selected and owned by the host/user and means the currently selected host execution Goal for this delivery and workspace. Harness does not create, persist or reconnect a Goal identifier. Compaction may continue inside the Goal; a later physical Goal/session restores semantic workflow state through `resume` rather than reconnecting a prior Turn.
-
-The loaded Skill and its progressive references own Source/Contract authoring, Control/applicability closure, selected-design projection, evidence design, protected revision, rolling repair and lifecycle commands. Do not duplicate those low-frequency rules in this startup router. During Draft/proof/lifecycle work, read the applicable Skill reference and use `ty-context long-task help` for CLI syntax.
-
-After the first Authority Lock, `execution_model_checkpoint.required: true` is an unconditional terminal-turn boundary. Stop before product implementation, edits, builds or tests even when an earlier message stated a model strategy. Tell a Chinese-speaking user exactly `处理好模型更换后，请仅回复：模型切换卡点解除，继续`; use `After handling the model change, reply exactly: model checkpoint cleared, continue` in English. A generic continuation does not satisfy the package-managed prompt protocol. Harness cannot observe the next host message or verify the host model change; later revisions do not repeat the pause and no acknowledgement, model route or checkpoint state is recorded.
-
-Long-Task Final Gate is the sole `Engineering Quality Conformance`, `Architecture Conformance` and selected-design closure owner. It source-recompiles and reruns every declared Check on one current snapshot, and revalidates every exact external-fulfillment record against the same candidate and Authority; targeted Progress, prose, historical tests, Receipts, compiled cache, external records by themselves or Agent judgment never create acceptance. It proves the declared falsifiable project-check-bound invariants, not overall code quality. `AcceptedDeliveryTerminal` is exactly a fresh `machine_accepted` when no blocking external fulfillment is required or a fresh `delivery_accepted` when every blocking external obligation is also freshly and exactly fulfilled. `blocked_external`, `needs_work` and legacy `machine_accepted_external_pending` never complete the platform-native Goal.
-
-The `F = Implementation Freedom Boundary` keeps implementation order, methods, local feedback cadence, concrete packet decomposition and dynamic worker count Goal-owned within Source/Contract, architecture, safety, forbidden-shortcut and external-action boundaries. After the checkpoint, follow the loaded Skill's packet-first positive-default policy: a qualifying packet set requires actual calls for multiple exact fixed-profile workers; zero-start and partial-delegation outcomes use its admitted reason and integration rules. Harness creates no development method Gate, per-edit mandate, fixed agent allocation, scheduler/delegation state or proof from delegated reports; all proof-bearing output converges into the selected verification workspace.
-
-Long-Task Anti-Degradation Assurance requires mechanism changes to preserve or strengthen coverage, false-negative resistance, fail-closed Authority and final-snapshot proof before total-cost ROI matters. Admission targets evidenced high ROI and high efficiency with a significant stable margin, not a global/local optimum; the complete formal cost theorem is unchanged and `observed_lifecycle_*` facts have no admission meaning. Once validity, relative non-degradation, must-allow behavior, structural-cost limits and applicable measured total-cost thresholds close, construction stops unless a new real counterexample, repeated material cost hot spot or significant additional-benefit evidence appears. Replacing the controlling purpose requires an explicit project-owner design-purpose decision plus replacement proof.
-
-Tiny Context does not create or restore platform Goals, invoke models, spawn agents, call an App Server, create branches/worktrees, merge, push, open PRs, deploy or manage process trees. `ty-context enable long-task` installs the sole Long-Task Workflow Skill and package-owned lifecycle Hooks; an exact `.codex` root may also receive the optional fixed Codex worker profile. Retired standalone authoring pointers are not installed. `design-system-authoring` is explicit-only.
-
-## Durable Facts And Generated Surfaces
-
-- Context is intended ownership/boundary/contract truth; code is current implementation truth. Treat disagreement as drift, missing work or stale Context.
-- Long-term facts live only in `project_context/**` or `DESIGN.md`. Selected targets remain Context-reachable Source/verifier inputs; generated screenshots/diffs/logs/raw evidence/runtime state/Receipts do not become Context.
-- Managed `AGENTS.md` blocks, `<harnessRoot>/ty-context-managed/**` and package-managed Skills are generated and sync-overwritten.
-- Explicit upgrades use `context_harness_upgrade`; package sync never imports retired orchestration 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/all-Context diagnostics 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.
+This contract applies to authorized implementation, including code, configuration, tests, documents and resources. Reading, discussion and audit do not themselves authorize edits. User scope, host safety requirements and more specific valid project constraints take precedence. No role workflow, mandatory intermediate artifact, model checkpoint or machine acceptance Gate is required.

package/assets/skills/design-resource/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: design-resource
+description: Create and revise design resources with Stitch, preserve editable sources, and package or adopt scoped project references. Use for resource work; implementing or repairing an already adopted design does not require invoking this skill.
+---
+
+# Design resources
+
+Deliver resources that people and agents can inspect and continue editing. Use Stitch for visual generation and design revisions, following the user's design direction and project constraints. This capability selects the tool; project Context supplies design rules, style and business meaning. It adds no fixed target platform or task workflow.
+
+## Project extensions
+
+This capability can be used directly or composed into an existing project resource Skill. Apply relevant project-declared target-platform, reference, export and integration methods alongside it; reuse an already loaded extension without creating a circular read. Keep Stitch as the generator and visual editor; a wrapper must not silently substitute another provider. A project Skill may reference this installed entry and then supply its own methods instead of copying the generic instructions. Resolve this entry's relative references from its own directory. This is instruction composition, not an automatic extension loader.
+
+Project Context owns confirmed style, design principles, business and interaction rules, scope and decisions with reasons. Tool operations, design methods and repeatable procedures belong in the project's Skill. Keep exact tokens, component definitions and resource entities in their actual source files or design tools, with Context pointing to those owners. Project-specific constraints refine this general capability; handle a material conflict explicitly under the user's requirements rather than silently replacing either source.
+
+## Create or revise resources
+
+Read the user input, default Context, affected owners, existing design rules and necessary implementation. Separate constraints to preserve, confirmed choices, requested changes and open exploration. Follow owners from the affected page, component or capability even when the request does not mention design resources. Existing project organization is sufficient; no new design document is a prerequisite.
+
+Continue a selected direction. Choose the number of alternatives, iterations and covered pages or states from the task; a selection is not necessarily formal adoption. Do not manufacture another revision when none is requested.
+
+For generation or visual revision, read [Stitch MCP operations](references/stitch.md). Discover and use the official Stitch MCP first, verifying current tool schemas and project/screen identifiers. When a required operation is unavailable there, use the authenticated official Stitch website if available. If neither route works, report the specific missing capability and preserve a usable input bundle; do not silently switch generators. Existing-resource inspection, packaging and adoption can continue without making a generation connection a prerequisite.
+
+Verify actual editing and export support. Preserve available editable sources, stable project links and supported exports. Other tools may inspect, package or perform a requested downstream conversion; they do not replace Stitch generation or disguise later repairs as Stitch originals. A screenshot, HTML prototype and native design nodes have different capabilities; label them accurately and verify any requested conversion by opening its result.
+
+Keep key inputs, reference origins and intended use, original outputs and necessary before/after versions with the resource or task material. Distinguish generated originals from later human or agent revisions. Inspect the current rendered result; an older preview does not represent a changed source. Keep prompts and detailed run records outside durable Context, with model, usage or hashes only when the task needs them.
+
+## Make the result usable
+
+Check what the task requires: files and links open, available sources can be edited, exports render, and the delivered content covers the stated scope. Actually view relevant visual outputs; inspect adopted motion or interaction through an available prototype, or its source and behavior notes as appropriate. Report inaccessible inputs and missing assets, fonts, permissions, states or runnable prototypes with their affected scope. Continue independent work when possible. Do not invent an editable source for a screenshot-only result or claim an unperformed check.
+
+Use the project's existing resource location; `docs/design-resources/` is an optional default. Keep resource entities outside Context. A useful entry links the available source, current visual references, assets and their origins, necessary behavior notes, coverage, limitations and comparison conditions. Create only the directories and records needed for that handover; an external design file can remain a stable link, with obtainable local exports when useful for continued access.
+
+Record comparison conditions that materially affect the result, such as viewport, fonts, data state, theme, safe areas and dynamic state. Identify which illustrative data, backgrounds, system chrome or decorative simulations are outside the implementation scope. Project adaptation rules determine responsive behavior; do not assume that different screens should be scaled into one reference image.
+
+## Adopt within the authorized scope
+
+For adoption or changes to current resource references, read [adoption and Context ownership](references/adoption.md). Preserve the distinction between a candidate, a preferred direction and an adopted requirement. Existing explicit authorization is sufficient to apply adoption; clarify only unresolved decisions or scope that matter to the change.
+
+Hand over a current entry that lets development find the relevant materials without replaying exploration history. Implementers follow the project's startup contract and affected owners; they do not need to run this generation skill again for ordinary repairs. Resource adoption and structural checks establish neither aesthetic approval nor verified production implementation.

package/assets/skills/design-resource/agents/openai.yaml

@@ -0,0 +1,7 @@
+dependencies:
+  tools:
+    - type: "mcp"
+      value: "stitch"
+      description: "Google Stitch for design generation and visual revision"
+      transport: "streamable_http"
+      url: "https://stitch.googleapis.com/mcp"

package/assets/skills/design-resource/references/adoption.md

@@ -0,0 +1,56 @@
+# Adoption and Context ownership
+
+Use the existing owner and manifest mechanisms. Adoption changes the project's implementation requirements only within its confirmed scope; it is not a new registry, approval workflow or task state machine.
+
+## Current basis and scope
+
+A candidate is an exploration. A preferred direction guides further work. An adopted resource is a current requirement within its declared scope. A newer file, generation success or attractive preview cannot make that decision. Use the user's existing authorization; do not ask again for an already approved adoption. If adoption is undecided, retain the current basis and report the candidate without silently changing requirements.
+
+The affected Context owner keeps the current entry, object and applicable platform, component or region, state and theme, as needed to distinguish it from other requirements. One scope has one current basis; an entry may map several nonconflicting scopes to different resources. Partial adoption replaces only the affected scope and preserves the remaining valid references. Shared component resources belong to the shared owner; page owners link there instead of repeating its rules.
+
+Resolve affected authority conflicts as part of authorized adoption. Business meaning, shared design rules, accessibility and platform constraints retain their respective owners. Update superseded decisions and stale navigation within scope; neither an image nor an old rule silently overrides the others. Distinguish an approved requirement from an implementation that has not yet caught up. If the decision needed to resolve a conflict is not authorized or clear, explain that conflict and preserve the unresolved requirement rather than fabricating agreement.
+
+## Resource location and entry
+
+Use an existing equivalent layout when present. This is an example, not required scaffolding:
+
+```text
+project_context/areas/<area>/<owner>.md
+docs/design-resources/<surface>/<component>/
+  ADOPTED.md                  # Current entry mapping resources to scopes
+  adopted/<resource>/
+    README.md                 # Opening, coverage, behavior, comparison conditions
+    source/                   # Available editable sources or prototype
+    reference/                # Current visual or motion references
+    assets/                   # Necessary assets and origins
+  candidates/<run>/           # Exploration and revision material when needed
+```
+
+The names, folders and local-file layout are optional. Stable external project links are valid resources; preserve available exports when needed to reduce access or remote-change risk. Do not imply a local export is editable or that it matches the current remote version without checking.
+
+Context holds durable adoption references, scope, confirmed decisions, reasons and authority boundaries. Source files, images, videos, asset lists, prompts, generation history and comparison evidence stay with resources or task material. Task progress and implementation migration notes stay task-local. Global Context needs only useful brief navigation; resource directories do not become default Context because an owner links to them.
+
+## Reuse the existing source declaration
+
+An existing component or feature owner may include this declaration and prose, adapted to the project's actual scope:
+
+```markdown
+<!-- ty-context-controlling-source domain="design" path="docs/design-resources/web/results/ADOPTED.md" -->
+
+The current result-list composition and assets are requirements for desktop,
+light theme and populated results, through the entry above. This owner retains
+business and state meaning; shared visual rules belong to the existing shared
+design owner. Other regions, themes and states retain their current requirements.
+```
+
+The path is repository-relative and names a local UTF-8 entry, not an image or design binary. Register the owner only as needed using the existing manifest. Declare a shared entry once in its owning Context; other owners link that owner, since duplicate declarations of the same target are diagnosed even within the same domain. Ordinary historical or candidate links are not controlling declarations. A required local text dependency can be explicitly declared from Context; links or declarations inside a resource entry outside Context are not recursively validated. Media files and remote resources require the appropriate explicit checks when the task needs them.
+
+Development follows defaults and affected owners to the current entry, then reads relevant sources and behavior notes and actually views the current visuals. Scope does not depend on the user saying a trigger keyword. Missing current inputs are reported as specific missing constraints, never reinterpreted as an unconstrained design. Access limitations can leave a portion unverified while independent work continues.
+
+## Implementation and evidence boundary
+
+Within the adopted scope, implement faithfully in the target runtime and compare the actual UI and relevant behavior under the entry's material comparison conditions. Check owned layout, typography, colors, icons, assets and interaction as relevant. Report and resolve platform limitations and conflicts. Ordinary fixes follow existing adopted resources; authorized design changes update resources and their owners. Never revise design requirements just to make current code pass a comparison.
+
+`validate-context` checks declared local paths, canonical identities, safety, UTF-8 readability and supported ownership conflicts. It does not recursively load images or prototypes, check remote access, run design tools, infer natural-language scope collisions or establish resource-bundle completeness. Overlapping design scopes need review; existing duplicate/domain diagnostics concern declarations of the same target, not semantic design agreement.
+
+Neither these files nor a successful check prove user approval, agent viewing, a preview's correspondence to current code, aesthetic quality, working interaction or production completion. Report the actual resource and implementation checks separately. Do not add a design preflight, fixed handoff document, hash gate or completion certificate.

package/assets/skills/design-resource/references/stitch.md

@@ -0,0 +1,54 @@
+# Stitch MCP operations
+
+Use this reference when generating or visually revising design resources. Stitch is the selected provider: prefer its official MCP connection, with its authenticated official website as a fallback for a needed operation. Keep project style, business and interaction requirements in their existing Context owners. Reading or adopting existing resources does not require a new Stitch submission.
+
+## Connect and discover
+
+Discover the host's available Stitch tools and read their descriptions and input schemas before calling them. Tool prefixes vary by host; the operation names below are discovery targets, not a promise that a particular prefixed function exists. If the host offers deferred tool discovery, use it before concluding that the connection is absent. With an existing MCP client, use its normal initialization and `tools/list`; do not build a new adapter or install another agent CLI just for this capability.
+
+The endpoint is `https://stitch.googleapis.com/mcp` over Streamable HTTP. The official extension supports a Stitch API key through `X-Goog-Api-Key`, or Google credentials with a quota project. Reuse an authorized connection and the host's supported secret storage; do not copy keys, tokens or authentication headers into prompts, resource records, code or terminal output. `agents/openai.yaml` provides a dependency hint for supporting hosts; copying this Skill does not authenticate a connection or modify host configuration. See [API-key connection](https://github.com/gemini-cli-extensions/stitch/blob/e22b3aac9a43bce2d740c5172844e9a2eebba37f/gemini-extension-apikey.json), [Google-credentials connection](https://github.com/gemini-cli-extensions/stitch/blob/e22b3aac9a43bce2d740c5172844e9a2eebba37f/gemini-extension-adc.json) and [current setup](https://stitch.withgoogle.com/docs/mcp/setup).
+
+Verify the needed connection through a relevant read, such as the known project or its screens, before submitting generation. A listed tool is not evidence of account access. If connection setup is needed, follow the current official instructions and task authorization. If a missing login or permission cannot be resolved, explain the exact prerequisite and continue independent work. Do not silently use a different generator.
+
+## Choose the operation and target
+
+The Google Labs published SDK manifest provides the following call shapes. It is a reference snapshot, not a guaranteed live service schema; use the connected tool's current schema and supported values. Do not hardcode a model list or create a design system merely because an optional parameter exists. [Published tool manifest](https://github.com/google-labs-code/stitch-sdk/blob/575a9fb6319bd9d1ce8175e4a89e5958e024bbfd/packages/sdk/generated/tools-manifest.json)
+
+| Intent | Operation and arguments to verify |
+| --- | --- |
+| Find the intended existing project | `list_projects` with optional `filter`; `get_project` with `name: projects/{projectId}` |
+| Create a project when the task needs one | `create_project` with optional `title`; retain its returned identity |
+| Find and read selected screens | `list_screens` with `projectId`; `get_screen` with `name: projects/{projectId}/screens/{screenId}` |
+| Generate an initial screen | `generate_screen_from_text` with `projectId`, `prompt`; optional `deviceType`, `modelId`, `designSystem` only when appropriate and supported |
+| Revise the chosen screen | `edit_screens` with `projectId`, `selectedScreenIds`, `prompt`; optional supported device/model settings |
+| Explore requested alternatives of selected screens | `generate_variants` with `projectId`, `selectedScreenIds`, `prompt`, `variantOptions` |
+
+Use returned identities and the user's selected scope. Names are resource paths; project and selected-screen IDs are bare IDs where the live schema requests them. The published `get_screen` schema also requires deprecated `projectId` and `screenId` alongside `name`; if the live schema does too, supply consistent values for all three. Never guess an ID or use the most recent unrelated screen as the target. Inspect selected screens before editing and retain the before version.
+
+For a new design, reuse the intended project or create a task-appropriate one. For continuation, edit the selected screen instead of restarting generation. Variants are an explicit exploration choice: choose any `variantCount`, `creativeRange` and `aspects` from the user's requested scope and live schema, not a fixed comparison ritual. Preserve additional returned candidates without silently adopting or expanding work to them. [Stitch generation and revision examples](https://github.com/google-labs-code/stitch-skills/blob/0337446dadde6f8c94210444e2aa9d546126480f/plugins/stitch-design/skills/generate-design/SKILL.md)
+
+## Submit useful inputs
+
+Separate content/actions that must remain, confirmed visual direction, requested changes, disliked problems and still-open exploration. Identify a reference's relevant region and purpose; liking one region does not approve the whole candidate. Label agent inferences and technical findings separately from user preferences. Send these focused inputs to Stitch, preserving confirmed design values without inventing a full typography/spacing system as a prerequisite. Do not include unrelated task history or another tool's commands.
+
+A path written into a text prompt does not upload an image. When image input is required, inspect the actual upload or attachment capability. Use a supported Stitch upload and its returned asset/screen identity, or the official website's real upload/paste flow. Confirm the correct reference reached the target. Do not add invented local-file or image-data parameters to text-generation/edit tools. If the operation cannot be automated, retain a ready-to-submit prompt, reference files and their intended use; report what was not submitted. [Upstream image-import route](https://github.com/google-labs-code/stitch-skills/blob/0337446dadde6f8c94210444e2aa9d546126480f/plugins/stitch-design/skills/upload-to-stitch/SKILL.md)
+
+Use the request's page/state count and budget. Keep already selected directions and unchanged requirements. A user's selection without a requested modification does not require another generation or revision. Tool choice itself grants no additional publication, purchase or production-edit authority.
+
+## Observe writes and recover uncertain outcomes
+
+Before a write, retain the target project, selected screen identities, submitted input and known before state. Read the tool result, including MCP `isError`, service messages and available structured content. Transport success is not design success. Preserve returned project/session/screen identifiers, relevant progress and every produced design; suggestions in a response are not authorization to launch more work.
+
+Generation and visual-edit calls may keep running after a timeout or connection loss. Do not automatically resubmit an uncertain write. Retain and follow any live host operation handle. When an output screen is known, refresh it; when none was returned, inspect the target project's screens to locate the actual output. An empty or unchanged read alone does not prove the write never ran. Use the current tool's recovery instructions: the published generation/variant guidance describes reads at 30-second intervals, bounded to ten checks. If that bound ends without a resolved outcome, report it as unresolved, retain the recovery identifiers and continue independent work. Do not turn a monitoring timeout into a new generation. [Tool recovery descriptions](https://github.com/google-labs-code/stitch-sdk/blob/575a9fb6319bd9d1ce8175e4a89e5958e024bbfd/packages/sdk/generated/tools-manifest.json)
+
+For a confirmed rejection before submission, fix the specific cause and retry only if safe, within the task budget and allowed by the live tool. Keep technical recovery distinct from a requested visual revision; stop repeating a failed technical attempt. A retry allowance does not override Stitch's no-resubmission guidance for uncertain generation/edit outcomes.
+
+## Retrieve, inspect and preserve real outputs
+
+Refresh edited screens before judging the result. Some clients cache screen data; an old URL or success message does not prove that the requested change persisted. The published result shape can contain `outputComponents[].design.screens[]`; `get_screen` returns screen data directly. Inspect the actual result shape, preserve every returned design and use returned `htmlCode.downloadUrl` and `screenshot.downloadUrl` when present. These are URLs, not already saved files. Use available download capabilities to materialize the exact files and verify the saved content. [Screen result handling](https://github.com/google-labs-code/stitch-sdk/blob/575a9fb6319bd9d1ce8175e4a89e5958e024bbfd/packages/sdk/generated/src/screen.ts), [SDK resource access](https://github.com/google-labs-code/stitch-sdk/blob/575a9fb6319bd9d1ce8175e4a89e5958e024bbfd/README.md)
+
+Keep original Stitch files, actual submitted prompts, reference origins/purpose and needed before/after versions. Record stable project links when actually available; do not manufacture share links or publish a project to obtain one. Use transient download credentials only for retrieval and redact them from saved transport records. Preserve original generation dimensions and explain any difference from the requested comparison conditions. View current screenshots and render current HTML when relevant; inspect completeness, clipping, readability, assets, hit regions and supported interaction against the task's requirements. Do not remove information or shrink an entire design merely to make a comparison look cleaner.
+
+For an edit, verify both the requested change and the features that should have stayed. Save subsequent manual or agent code repairs as distinct revisions, not as untouched Stitch output. HTML can be editable without being a native design-node document. Report screenshot-only delivery or missing exports honestly. A requested downstream conversion is separate work: preserve the Stitch original and open/check the converted result before claiming that format. Another design tool is not a prerequisite or substitute for Stitch generation.
+
+Keep optional model/mode and usage observations task-local when they help. The host model and Stitch service model are different; do not infer the latter from the former. Unknown usage remains unknown, and an account-wide quota change is not evidence of the cost of one screen. Product defects, user preference, source editability, adoption and production verification remain separate conclusions. Use [adoption and Context ownership](adoption.md) when applying an authorized adoption.

package/assets/tools/context_rules.json

@@ -1,5 +1,5 @@
 {
-  "context_schema_version": 4,
+  "context_schema_version": 5,
   "roles": [
     "global",
     "architecture",
@@ -31,6 +31,7 @@
     "never-default"
   ],
   "top_level_fields": [
+    "default_files",
     "areas",
     "context"
   ],

package/dist/commands/context-inspect.js

@@ -1,98 +1,28 @@
-import { CLI_EXIT_CODES, CliCommandError } from "../lib/cli-exit.js";
 import { inspectContext } from "../lib/context-inspect/context-inspect.js";
 import { renderContextInspectText } from "../lib/context-inspect/context-inspect-render.js";
+import { CliCommandError, CLI_EXIT_CODES } from "../lib/cli-exit.js";
 export async function contextInspect(args) {
-    const options = parseInspectArgs(args);
-    if (options.help) {
-        console.log(contextInspectHelp());
+    if (args.includes("--help") || args.includes("-h")) {
+        console.log("context inspect <project_context/file.md> [--format text|json]");
         return;
     }
-    if (!options.target)
-        throw new CliCommandError(CLI_EXIT_CODES.arguments, "context inspect requires <project_context/file.md>");
-    let result;
-    try {
-        result = await inspectContext({
-            project_root: process.cwd(),
-            context_path: options.target,
-            route_task: options.task,
-            route_paths: options.route_paths,
-            route_terms: options.terms,
-            route_case_sensitive: options.case_sensitive,
-        });
-    }
-    catch (error) {
-        if (error instanceof CliCommandError)
-            throw error;
-        throw new CliCommandError(CLI_EXIT_CODES.internal, `context inspect failed internally: ${message(error)}`, { cause: error });
-    }
-    if (options.format === "json")
-        process.stdout.write(`${JSON.stringify(result, null, 2)}\n`);
+    const [target, ...rest] = args;
+    const json = rest.length === 1 && rest[0] === "--json";
+    if (!target ||
+        (!json &&
+            rest.length &&
+            (rest.length !== 2 ||
+                rest[0] !== "--format" ||
+                !["text", "json"].includes(rest[1]))))
+        throw new CliCommandError(CLI_EXIT_CODES.arguments, "Usage: context inspect <path> [--format text|json] [--json]. Ranking/route options have retired.");
+    const result = await inspectContext({
+        project_root: process.cwd(),
+        context_path: target,
+    });
+    if (json || rest[1] === "json")
+        console.log(JSON.stringify(result, null, 2));
     else
-        process.stdout.write(renderContextInspectText(result));
+        console.log(renderContextInspectText(result));
     if (result.diagnostics.some((entry) => entry.severity === "error"))
         process.exitCode = CLI_EXIT_CODES.catalog;
-    else if (result.route && !result.route.complete)
-        process.exitCode = CLI_EXIT_CODES.incomplete;
-}
-function parseInspectArgs(args) {
-    const options = {
-        route_paths: [],
-        terms: [],
-        case_sensitive: false,
-        format: "text",
-        help: false,
-    };
-    for (let index = 0; index < args.length; index += 1) {
-        const argument = args[index];
-        if (argument === "--help" || argument === "-h")
-            options.help = true;
-        else if (argument === "--json")
-            options.format = "json";
-        else if (argument === "--case-sensitive")
-            options.case_sensitive = true;
-        else if (argument === "--task")
-            index = readValue(args, index, argument, (value) => {
-                options.task = value;
-            });
-        else if (argument === "--route-path")
-            index = readValue(args, index, argument, (value) => {
-                options.route_paths.push(value);
-            });
-        else if (argument === "--term")
-            index = readValue(args, index, argument, (value) => {
-                options.terms.push(value);
-            });
-        else if (argument === "--format")
-            index = readValue(args, index, argument, (value) => {
-                if (value !== "text" && value !== "json")
-                    throw new CliCommandError(CLI_EXIT_CODES.arguments, "context inspect --format must be text or json");
-                options.format = value;
-            });
-        else if (argument.startsWith("--"))
-            throw new CliCommandError(CLI_EXIT_CODES.arguments, `unknown context inspect argument: ${argument}`);
-        else if (options.target)
-            throw new CliCommandError(CLI_EXIT_CODES.arguments, "context inspect accepts exactly one Context path");
-        else
-            options.target = argument;
-    }
-    return options;
-}
-function readValue(args, index, flag, apply) {
-    const value = args[index + 1];
-    if (value === undefined || value.startsWith("--") || value.length === 0)
-        throw new CliCommandError(CLI_EXIT_CODES.arguments, `context inspect ${flag} requires a value`);
-    apply(value);
-    return index + 1;
-}
-function contextInspectHelp() {
-    return `ty-context context inspect <project_context/file.md>
-  [--task <text>] [--route-path <repo-path>] [--term <literal>]
-  [--case-sensitive] [--format text|json]
-
-Reports ownership metadata, default-footprint membership, explicit Markdown
-references, opt-in stable-key declarations and an optional experimental Router
-explanation without modifying Context or Manifest files.`;
-}
-function message(error) {
-    return error instanceof Error ? error.message : String(error);
 }

package/dist/commands/context-list.d.ts

@@ -0,0 +1 @@
+export declare function contextList(args: string[]): Promise<void>;

package/dist/commands/context-list.js

@@ -0,0 +1,24 @@
+import { loadContextCatalog } from "../lib/context-catalog/catalog-load.js";
+import { CLI_EXIT_CODES, CliCommandError } from "../lib/cli-exit.js";
+export async function contextList(args) {
+    if (!args.includes("--default") ||
+        args.some((arg) => !["--default", "--json"].includes(arg)))
+        throw new Error("Usage: ty-context context list --default [--json]");
+    const catalog = await loadContextCatalog(process.cwd());
+    const complete = !catalog.diagnostics.some((entry) => entry.severity === "error");
+    const files = [...catalog.default_footprint].map(([path, reasons]) => ({
+        path,
+        reasons: [...reasons],
+    }));
+    if (args.includes("--json"))
+        console.log(JSON.stringify({ complete, files, diagnostics: catalog.diagnostics }, null, 2));
+    else {
+        console.log(complete ? "Default body files:" : "Incomplete default body selection:");
+        for (const file of files)
+            console.log(`${file.path} (${file.reasons.join(", ")})`);
+        for (const entry of catalog.diagnostics)
+            console.log(`${entry.severity}: ${entry.message}`);
+    }
+    if (!complete)
+        throw new CliCommandError(CLI_EXIT_CODES.catalog, "Default Context selection is incomplete; resolve relevant diagnostics. Failure does not mean there are no other defaults.");
+}

package/dist/commands/context.js

@@ -4,6 +4,7 @@ import { contextInspect } from "./context-inspect.js";
 import { contextMove } from "./context-move.js";
 import { contextRegister } from "./context-register.js";
 import { contextTransaction } from "./context-transaction.js";
+import { contextList } from "./context-list.js";
 export async function context(args) {
     const [subcommand = "help", ...rest] = args;
     if (subcommand === "help" || subcommand === "--help" || subcommand === "-h") {
@@ -12,6 +13,8 @@ export async function context(args) {
     }
     if (subcommand === "create")
         return contextCreate(rest);
+    if (subcommand === "list")
+        return contextList(rest);
     if (subcommand === "inspect")
         return contextInspect(rest);
     if (subcommand === "move")
@@ -24,6 +27,7 @@ export async function context(args) {
 }
 function contextHelp() {
     return `ty-context context commands:
+  context list --default [--json]
   context create --path <project_context/file.md> --role <role> [--format text|json]
   context inspect <project_context/file.md> [options]
   context move --from <project_context/file.md> --to <project_context/file.md> [--apply]

package/dist/commands/doctor.js

@@ -26,8 +26,6 @@ function parseDoctorArgs(args) {
         strict: false,
         help: false,
         context_file_soft_budget_bytes: CONTEXT_DOCTOR_DEFAULTS.context_file_soft_budget_bytes,
-        long_line_code_points: CONTEXT_DOCTOR_DEFAULTS.long_line_code_points,
-        trigger_fanout_contexts: CONTEXT_DOCTOR_DEFAULTS.trigger_fanout_contexts,
     };
     for (let index = 0; index < args.length; index += 1) {
         const argument = args[index];
@@ -35,18 +33,10 @@ function parseDoctorArgs(args) {
             options.strict = true;
         else if (argument === "--help" || argument === "-h")
             options.help = true;
-        else if (argument === "--max-line-length")
-            index = readPositiveInteger(args, index, argument, (value) => {
-                options.long_line_code_points = value;
-            });
         else if (argument === "--context-file-soft-budget")
             index = readPositiveInteger(args, index, argument, (value) => {
                 options.context_file_soft_budget_bytes = value;
             });
-        else if (argument === "--trigger-fanout-threshold")
-            index = readPositiveInteger(args, index, argument, (value) => {
-                options.trigger_fanout_contexts = value;
-            });
         else
             throw new Error(`unknown doctor argument: ${argument}`);
     }
@@ -63,12 +53,5 @@ function readPositiveInteger(args, index, flag, apply) {
     return index + 1;
 }
 function doctorHelp() {
-    return `ty-context doctor [--strict]
-  [--max-line-length <code-points>]
-  [--context-file-soft-budget <bytes>]
-  [--trigger-fanout-threshold <contexts>]
-
-All new size, line, fan-out, unregistered-file, explicit-link and stable-key
-findings are advisory by default. --strict is opt-in and exits nonzero when a
-warning exists; projects must adopt it explicitly before using it in CI.`;
+    return "ty-context doctor [--strict] [--context-file-soft-budget <bytes>]\nChecks installation, structural Context, default body sizes and observable root startup overrides. Size findings are advisory unless --strict is selected; this does not verify factual or product correctness.";
 }