Runtime Modes

The γ server lifecycle exposes a small, fixed set of runtime modes. Each mode is a contract about which tool classes admit traffic and which databases accept writes. There is no “admin mode” and no mode selected by the caller at request time: the mode is chosen at boot by the operator and is immutable for the life of the process.

The four Phase 0 modes

Only these four modes ship in Phase 0. Any other mode name that appears in old donor documentation is heritage and has no Phase 0 meaning.

Mode	Tools admitted	Writes	Use
`FULL`	all 14 shipped Phase 0 tools	yes	production runtime
`READONLY`	read-side tools only	no	inspection, CI assertions against a frozen DB
`TEST`	all 14 shipped tools	yes (test DB)	integration tests against an ephemeral `data/*.test.db`
`MINIMAL`	`server_ping`, `server_health` only	no	smoke tests, uptime probes

The mode is set at startup via the COLIBRI_MODE environment variable. No tool may change it.

What “admitted” means

The tool-lock stage of the α chain (stage 1 of tool-lock → schema-validate → audit-enter → dispatch → audit-exit) consults the active mode. A request whose tool is not in the admitted set is rejected with a typed ToolNotAdmittedError at the lock stage, before schema validation, dispatch, or auditing run. The rejection itself is audited as a denied event but is not counted as an executed call.

Boot sequence

γ runs a two-phase boot. See boot.md for the full order.

Phase 1 — transport up: listen for JSON-RPC over the configured transport (stdio in Phase 0) so a probing client never times out. Only server_ping is admitted at this point.
Phase 2 — runtime up: database opens, schema migrations run, α chain assembles, all Phase 0 tools register per the active mode, then the server flips to the declared mode.

If Phase 2 fails, the server stays in MINIMAL and reports the failure via server_health. It does not silently drop to FULL.

What is not a mode

WATCH — donor AMS construct for a filesystem-watch dispatch loop. Not a Phase 0 mode.
OPERATIONAL, MAINTENANCE, SAFE_MODE, DIAGNOSE, BOOT — names from pre-R53 donor documents. Not Phase 0 modes.
HOT_RELOAD — the Phase 0 runtime does not support live config reload. Restart the process.

If a future phase needs one of these, it will be an ADR, not a silent extension.

Tool surface per mode

The shipped Phase 0 tool count is 14 tools per ADR-004 R75 Wave H amendment: 5 β Task tools, 4 ζ Audit tools, 2 η Proof tools, 1 ε tool (skill_list), and 2 System tools (server_ping, server_health). The R74.5 plan listed server_info and server_shutdown; neither shipped.

Mode	β Task	ζ Audit	η Proof	ε Skills	System
FULL	5	4	2	1	2
READONLY	read-subset (e.g. `task_list`, `task_get`, `thought_record_list`, `audit_verify_chain`, `merkle_root`)	read-subset	read-subset	1	2
TEST	5	4	2	1	2
MINIMAL	0	0	0	0	2 (`server_ping`, `server_health`)

Process-level shutdown (SIGTERM/SIGINT) is the Phase 0 signal for clean teardown — there is no MCP-exposed shutdown tool.

Health and the mode

server_health returns the declared mode, the database path, the admitted tool count, and the outcome of the last α chain warm-up. A health probe that returns MINIMAL when an operator requested FULL is a boot-failure signal, not a runtime-degradation one.