project-tiny-context-harness: Instructions file for Codex

Repository maintenance

This repository maintains Tiny Context's package, canonical managed sources and maintenance commands. Use .codex/skills/authoring/harness_package_design/SKILL.md for those changes. Read relevant project Context; edit canonical owners and synchronize generated package assets.

Work directly on main unless the user selects isolation. Preserve unrelated changes. Do not create branches/worktrees or publish as a Harness workflow. Clean up only task-owned, verified-merged branches when applicable.

The approved product has two responsibilities: durable project memory and a short development contract. Historical Long-Task/DSA/DRA proof and role rules are retired; do not use them to bootstrap package development.

Tiny Context development contract

Tiny Context preserves durable project facts and this short development contract. It does not manage tasks or certify product completion.

• 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.