Glossary
Short definitions for terms used across these docs. Each entry links to the page that explains the concept in full. This page is a lookup, not a tutorial.
An Architecture Decision Record: a numbered, dated, user-attributed file under
.codearbiter/decisions/ that records one architectural decision. Authored only via /ca:adr;
never invented by a routine finding. See ADRs and the Decision Log.
Advisory
Section titled “Advisory”A non-blocking reminder that surfaces right after a write (e.g. a crypto pattern or a CI file change) so the blocking gate at commit time is not a surprise. Advisories never stop a tool call. See Enforcement & Security.
A focused author or reviewer role dispatched by a skill. An agent is not a public command and not a second orchestrator; it receives only the tools and context its role needs. Claude Code dispatches packaged plugin agents. Current Codex releases load the equivalent charter into host-provided agent threads, with inline execution only as an older-host fallback; Pi uses hardened child dispatch. See the Agents reference.
Arbiter (enabled flag)
Section titled “Arbiter (enabled flag)”The arbiter: enabled line in .codearbiter/CONTEXT.md’s frontmatter: the single activation
flag that turns on the orchestrator persona and every enforcement hook for a repository. A repo
without it loads nothing and blocks nothing. See
The .codearbiter/ Directory Reference.
Blocking gate
Section titled “Blocking gate”A gate whose failure stops the tool call outright: the call never happens. Most blocks are resolved
by fixing the issue or, when the gate permits it, a logged /ca:override; H-18 activation
protection deliberately has no in-session override path. Contrast with an advisory.
See Enforcement & Security.
.codearbiter/open-tasks.md, the project’s task list. Every task holds one of three states
(queued, in-progress, done); the only sanctioned writer is /ca:task. See
The .codearbiter/ Directory Reference.
Checkpoint
Section titled “Checkpoint”A periodic, read-only sweep of the whole codebase by the reviewer fleet, consolidated into a
dated report under .codearbiter/checkpoints/. Catches drift between feature work without
blocking any single change. See Checkpoints.
Command
Section titled “Command”A public entry point the user invokes for an outcome, using the current host’s syntax:
/ca:name in Claude Code, $ca-name in Codex, or /ca-name in Pi. The orchestrator routes that
command to its owning skill. See the Commands reference.
CONFIRM-NN
Section titled “CONFIRM-NN”The placeholder for an unresolved question only the user can answer, numbered and recorded in
.codearbiter/open-questions.md. It blocks stage promotion until resolved and is never guessed
at. See The .codearbiter/ Directory Reference.
Decision log
Section titled “Decision log”.codearbiter/decisions/decision-log.md, the append-only ledger mirroring every ADR file: one
entry per recorded decision, never edited after the fact. A superseding decision appends a new
entry rather than rewriting the old one. See ADRs and the Decision Log.
Feature Forge / Preview Features
Section titled “Feature Forge / Preview Features”The two-axis system that separates a payload’s SemVer maturity from whether an individual feature is still a preview. In reader-facing copy this is labeled “Preview Features”; “Feature Forge” is the internal name. See What Is the Feature Forge.
A phase exit condition (STOP or BLOCK) that a change must clear before it proceeds. Not a “checkpoint” and not a “guardrail”: those are different mechanisms. See The Gated-Lane Model.
A Claude Code hook: a script that runs at a tool-call boundary (PreToolUse, PostToolUse,
SessionStart, …) and can block, remind, or inject context. codeArbiter’s hooks are Python,
stdlib-only, and fail loud. See Hooks reference.
A sanctioned path through the system, with gates scaled to the work’s risk: implementation, commit & ship, decisions, or project & meta. Not a “workflow” and not a “track.” See The Gated-Lane Model.
A level in the greenfield decomposition interview. “Layer” describes how /ca:decompose structures
discovery; it is not a project maturity stage, skill phase, or enforcement gate. See the
decompose skill reference.
Marker
Section titled “Marker”A small file under .codearbiter/.markers/ that records a gate’s pass state, for example
security-gate-passed, which a commit-time gate checks for freshness and content coverage
before allowing a commit through. See
The .codearbiter/ Directory Reference.
NEEDS-TRIAGE
Section titled “NEEDS-TRIAGE”The placeholder for an out-of-scope finding set aside inline during review: recorded, never
acted on in place. It typically lands as a queued item on the board. See
The .codearbiter/ Directory Reference.
Orchestrator
Section titled “Orchestrator”The always-on persona injected at SessionStart in an arbiter-enabled
repo. It routes every request to the skill or agent that owns it and holds the gates; it never
freelances. See The Persona-Register Split.
Override
Section titled “Override”The sanctioned, logged bypass for a gate that allows bypass, invoked as /ca:override "reason".
It appends one permanent line to .codearbiter/overrides.log before the immediate action proceeds.
H-18 is intentionally non-overridable from the governed session. Never call an override a
“workaround” or a “skip.” See Override a Gate Safely.
Persona
Section titled “Persona”A named voice codeArbiter speaks with: the terse orchestrator, or a focused author/reviewer agent, each scoped to its own job and context footprint. See The Persona-Register Split.
One named step inside a skill, with an entry purpose and often a gate at its exit. A phase is not a project stage or a decomposition layer. See The Gated-Lane Model.
Provenance
Section titled “Provenance”The per-doc evidence trail that backs a derived .codearbiter/ document (which source lines
justified which claim), used to detect when that source has since drifted. See
Provenance and Context Drift.
SMARTS
Section titled “SMARTS”The named framework an autonomous /ca:sprint uses to decide “as the user” on non-hard-gate
points, scoring each auto-decision and logging it with a confidence flag. See
SMARTS.
Severity
Section titled “Severity”A finding classification (CRITICAL, HIGH, MEDIUM, or LOW) that expresses impact. Severity does not itself say whether a phase must STOP or BLOCK; gate action is a separate decision. See Checkpoints.
An orchestrator routine with named phases. The orchestrator routes to a skill from a command, and the skill may dispatch agents; users do not invoke internal skill files as an alternate command surface. See the Skills reference.
A time-boxed exploration on a disposable spike/* branch that answers one named question. It
never merges and never becomes the implementation. Only its written findings survive. See the
/ca:spike reference.
Sprint
Section titled “Sprint”An autonomous, multi-task run via /ca:sprint: one interactive spec gate, then execution to a
shipped PR with every auto-decision SMARTS-scored and logged to sprint-log.md. Hard gates
remain true stops even under autonomy. See
Run an Autonomous Sprint.
A single project-maturity number in .codearbiter/CONTEXT.md’s frontmatter. It records where the
project is in its maturity progression and is surfaced by /ca:status and the statusline; it is not
a skill phase, decomposition layer, gate action, or finding severity. See
The .codearbiter/ Directory Reference.
Statusline
Section titled “Statusline”codeArbiter’s Claude Code statusline: usage segments in every session, plus a project-state row (stage, tasks, open questions, overrides) in an arbiter-enabled repo. See Set Up the Statusline.
Tribunal
Section titled “Tribunal”The deep, rarely-convened whole-codebase audit (/ca:tribunal): eleven specialist lenses over a
resumable on-disk run, filing approved findings as GitHub issues. Never a required gate, and not
a synonym for the routine checkpoint sweep. See Checkpoints.