Maintaining Jazz

Use these pages to answer two questions: where does a change belong, and which invariant must it preserve?

Read in this order

Architecture: package ownership and dependency direction.
Run lifecycle: input to final answer and persistence.
Goal lifecycle: inferred intent, durable multi-run work, completion evidence, budgets, and recovery.
Context lifecycle: pressure, trimming, compaction, and working state.
Tool lifecycle: registration, selection, disclosure, approval, and execution.
Plugin lifecycle: trusted code, artifacts, per-run sessions, and advisory hooks.
Security threat model: trust boundaries and non-goals.
Testing and evals: proving correctness and harness lift.
Design decisions: why each choice is the way it is, and what it gives up.
Documentation quality: writing code-backed concepts, lookup pages, and tutorials without filler or false completeness.

Interface design: the terminal’s visual language, and the rules for any case it does not cover.
Conversation presentation: source facts, renderer projections, stream identity, and history migration.
Fullscreen ownership: navigation, content anchors, bounded layout, and disposal.
Terminal rendering tests: native ANSI output checked against an independent terminal grid.
Terminal runtime: output capabilities, demand frames, cleanup, and fallback.
UI performance qualification: matched fresh-process latency and memory reproduction, complete observations, and unchanged gates.
Remote handoff snapshot: what a detached conversation carries to another host, and the ownership fence around it.

Add a service
Add a model provider
Use the architecture map to decide whether a capability is a tool, skill, MCP server, adapter, command, or surface before writing code.

Every maintainer page should link to current source and nearby tests. Historical implementation plans are not runtime documentation.