station: Instructions file for Codex

Agent Guidance

For repository-wide architecture or boundary decisions, read docs/architecture.md. For Observer ports, adapters, use cases, policies, composition, or dependency direction, also read docs/observer-architecture.md and docs/architecture-documentation.md.

For configuration — the runtime config.toml (all sections, including [workspace] and [tui]), the project-local .station/config.toml, and environment variables — read docs/configuration.md.

For contributor setup and documentation workflow, read docs/development.md. For test layout, isolation, and gate selection, read tests/README.md. For release operations, read docs/releasing.md.

When creating plans, name the governing documents and other sources of truth, enumerate every file and test expected to change, and identify every JSDoc addition or update required for backend or connector changes.

For harness status, attention, and event semantics, read docs/harness-signals.md. For adding or upgrading a harness integration, read docs/harness-authoring.md.

For runtime trace IDs, command IDs, diagnostic IDs, or live debugging, read docs/debugging.md. For diagnosis, start with the debugging, diagnostics, and observability tools documented there before reading source code.

When finishing a change and summarizing it, include a minimal line or section naming the specific UX implication and how to manually verify it when possible.

PR titles should be semantic and reviewer-oriented, using a type/domain shape like refactor(protocol): centralize observer command completion waits; do not add agent tags.

PR descriptions must be reviewer-oriented and understandable without prior knowledge of Station's implementation history.

Every substantive PR should answer, in this order:

• ## What this fixes: briefly explain the affected Station responsibility, the concrete problem, and why it matters.
• ## What changed: summarize the resulting behavior and important design decisions using concise, outcome-oriented bullets.
• ## Testing: name the meaningful validation performed.

Add ## Safety and scope or ## User-visible behavior only when they provide decision-relevant context.

Assume the reviewer is technically capable but may not know Station's internal architecture. Define unfamiliar subsystem responsibilities on first mention, but do not include project history, a file-by-file walkthrough, implementation details already clear from the diff, or exhaustive test output. Prefer one short context paragraph and 3-7 change bullets; smaller PRs should be shorter.

STATION is terminal/TUI-first. Ignore generic web, frontend, site, image, and browser guidance unless the task explicitly targets a web frontend or browser-rendered UI.