$ca-override — logged bypass

The sanctioned escape hatch. Bypass is permitted only with an audit log entry. Overrides are always logged, always visible, never silent. Single identity, single confirm.

Flow

1. Validate $ARGUMENTS — the reason names the gate being bypassed and a justification. Reject a vague reason ("just skip it") and ask for a specific one.

2. Detect the operator identity from git config user.email only. If it is unset, ask the user once to state their identity for the log. (No platform ladder, no second confirmation.)

3. Append one line to <project-root>/.codearbiter/overrides.log:

   [ISO-8601 timestamp] | BY: <email> | GATE: <gate bypassed> | REASON: <reason>
   

   The log is append-only — never edited or deleted, committed as a permanent audit artifact.

4. Proceed with the overridden action. Note in the response that the override is logged.

Security ceiling — heavier path for security-critical stops

A routine gate (lint, a style rule, a non-security review finding) takes the single-confirm path above. But a security-critical stop is NOT bypassable by a single confirm. The following require the heavier path below, never the one-line flow:

• a security CRITICAL finding;
• the crypto/secret commit gate (hook H-09b / H-10b — staged crypto/TLS or secret without a gate pass);
• an irreversible operation (data loss, a destructive migration, anything unrollbackable).

Heavier path (all required, in order):

1. Surface the specific finding verbatim — name the exact primitive/secret/operation and the concrete risk. A generic "security override" is rejected.

2. Explicit per-finding acknowledgement — the user must acknowledge that specific finding in their own words (a bare "yes"/"go ahead"/"I trust you" is declined — this mirrors decision-variance). Detect identity from git config user.email; if unset, ask once.

3. Heavier log entry — append a line tagged SECURITY-OVERRIDE that records the specific finding, not just the gate name:

   [ISO-8601] | BY: <email> | SECURITY-OVERRIDE | FINDING: <specific finding> | REASON: <reason>
   

4. Only then record the bypass. For the crypto/secret commit gate, that means resolving the interpreter once by presence — PY=python3; { command -v python3 >/dev/null 2>&1 && python3 --version >/dev/null 2>&1; } || PY=python — never python3 X || python X, which reruns X on any nonzero exit (#577), and running "$PY" "${PLUGIN_ROOT}/hooks/security-pass.py", which writes <project-root>/.codearbiter/.markers/security-gate-passed bound to the sensitive lines it approves, so hook H-09b/H-10b allows the commit — recorded only after steps 1–3, never to skip the gate proper.

Under $ca-sprint, a security-critical override is a hard-gate STOP: it surfaces to the user and is never auto-decided, even in autonomous mode (SPRINT.md hard gates).

Hard gate

MUST write the log line before proceeding — it is not optional. MUST capture an operator identity — "codeArbiter" or "automated" are not valid. MUST include a justification. The override is scoped to the immediate action only; it creates no standing exception. MUST NOT edit or delete an existing overrides.log entry. MUST route a security-critical / crypto-secret / irreversible stop through the Security ceiling path — never the single-confirm flow — and MUST NOT auto-decide such an override under $ca-sprint.

When NOT to use

• Routine work that passes all gates — never needed.
• Reconciling two conflicting sources → $ca-conflict.