tribunal

Deep, rarely-convened whole-codebase audit — eleven specialist lenses, a resumable on-disk audit log, findings filed as GitHub issues on approval. Expensive; estimates cost and STOPs before running. Never a required gate.

What it does

codeArbiter’s deepest, most expensive review, convened rarely and never as a required gate. Eleven specialist lenses judge the whole codebase in priority waves; each finding is written to its own file under .codearbiter/reports/<run-id>/, so an interrupted run resumes from disk instead of losing progress. Because this lane routinely costs millions of tokens on a large repo, Phase 0 always stops first: it sizes the codebase, prints the cost band, recommends the highest-reasoning model, and waits for you to say go. Critical and high findings are blocking-severity in the report: they are work that should block shipping the affected code. The tribunal run itself never halts a merge or commit.

The eleven lenses

Each lens judges one concern, in priority waves capped at five in flight. A lens is skipped when its concern is absent from scope: a repo with no migrations drops the migration lens.

1. tribunal-appsec-reviewer: injection, resource-level authz/IDOR, input validation, JWT, CORS, SSRF.
2. tribunal-architecture-reviewer: dead/orphan modules, pattern drift, cosmetic abstractions, god modules, monolith accretion. Distinct from architecture-drift-reviewer, which checks conformance to accepted ADRs; this lens judges structural health on its own terms.
3. tribunal-coverage-reviewer: risk-path coverage gaps, edge/property gaps, implementation-coupled tests.
4. tribunal-infra-reviewer: CI/CD correctness and security, container posture, IaC/deploy manifests, release automation.
5. tribunal-migration-reviewer: migration safety, data-classification tagging, immutability, schema-to-code drift.
6. tribunal-observability-reviewer: structured logging, tracing/correlation IDs, metrics on critical paths, audit gaps.
7. tribunal-performance-reviewer: N+1 queries, redundant hot-path work, query/index shape, caching, blocking IO.
8. tribunal-reliability-reviewer: async correctness, error propagation, races, resource lifecycle, boundary conditions, orphan state.
9. tribunal-secrets-supply-reviewer: hardcoded secrets, weak crypto, cleartext, secrets in logs, supply-chain hygiene.
10. tribunal-test-fidelity-reviewer: tests validating fiction, meaning mocks, stubs, or fixtures that drifted from a producer that’s since become real.
11. tribunal-typesafety-reviewer: footgun interfaces, weak typing, escape hatches, unhelpful errors, undocumented invariants.

On a large repo, two optional read-only mappers (map-structure and map-deps) build the codebase inventory ahead of the lenses, so that mapping work stays off the orchestrator’s own context.

On Codex, every lens runs inline in the current thread rather than through isolated Task-tool dispatch — see Claude Code + Codex → Intentional host differences.

A triage pass independently recalibrates every lens’s own severity call rather than trusting it as final; every critical or high finding must carry a counter-argument. report.md is always a projection of the append-only run.jsonl and triage.jsonl logs, never hand-authored.

Resuming an interrupted run is time-boxed: a run older than seven days STOPs and asks whether to resume anyway or start fresh, since the codebase may have drifted under the recorded findings.

Usage

/ca:tribunal "[scope-path] [--tag <label>]"

An optional scope-path narrows which subtree gets scrutiny (the full eleven-lens roster still runs); --tag <label> records a freeform label if you opt in to KPI telemetry at the end.

Example

> /ca:tribunal

Sizing codebase... 340 files, ~2.1M tokens estimated.
Recommended model: highest-reasoning available, high effort.
Estimated cost band: $180-$260.

Proceed with this model and cost? (y/n)
> y

RUN_ID: 2026-07-02-full
Phase 1: mapping... inventory.md written, 11 lenses active.
Phase 2: dispatching lenses (wave 1/3, ≤5 in flight)...
...
Phase 4: report.md regenerated — 3 CRITICAL, 9 HIGH, 21 MEDIUM findings.

Phase 5: file findings as GitHub issues? Select which, or "none".

When to reach for it

Rare, deliberate, whole-codebase depth, not the routine sweep (/ca:checkpoint), not a diff review (/ca:review), and never wired into a hot loop or schedule.

Gates

Gate	When	Effect
cost acknowledgement	before Phase 0 finishes, every run	the job is sized, a token-cost band and model recommendation are printed, and nothing dispatches until you explicitly acknowledge the estimate and confirm the model
approval before filing	after the report is generated	findings become GitHub issues only on your explicit selection, silence or “looks good” files nothing

Related

• checkpoint
• audit
• tribunal

Source

Source — plugins/ca/commands/tribunal.md (v2.9.1)

---
description: Deep, rarely-convened whole-codebase audit — eleven specialist lenses, a resumable on-disk audit log, findings filed as GitHub issues on approval. Expensive; estimates cost and STOPs before running. Never a required gate.
argument-hint: "[scope-path] [--tag <label>]"
---
# /ca:tribunal — deep codebase audit

The deepest, most expensive review codeArbiter offers, convened rarely and on demand. Routes to the tribunal skill. Eleven lenses judge the codebase; every finding persists to its own file (plus append-only triage/run logs) under `.codearbiter/reports/<run-id>/`, so an interrupted run resumes from disk. Never a required gate — critical/high are blocking-severity findings, not a pipeline halt.

Cost first — this lane routinely costs millions of tokens on a large repo. Phase 0 sizes the codebase, prints a token-cost band, recommends the highest-reasoning model, and STOPs for your acknowledgement before dispatching anything. Nothing runs unacknowledged.

## Flow

Load and follow the tribunal skill (`${CLAUDE_PLUGIN_ROOT}/skills/tribunal/SKILL.md`). In brief:

Phase 0 (STOP) — cost estimate, model recommendation, resume check.
Phase 1 (BLOCK) — map the codebase; risk-rank and mark trust boundaries; record AI-authorship markers and iteration depth.
Phase 2 (BLOCK) — dispatch the eleven tribunal-* lenses in priority waves (≤5 in flight); each writes one file per finding under its own `findings/<lens>/` dir.
Phase 3 (BLOCK) — triage per wave from disk: dedup, independent calibration, decision vocabulary.
Phase 4 (BLOCK) — project the human-readable report from the logs.
Phase 5 (BLOCK) — on explicit selection, file findings as GitHub issues; idempotent against the tracker.
Phase 6 (STOP) — optional, opt-in KPI telemetry to the public codeArbiter repo.

## Arguments

`"scope-path"` — focus the audit on a subtree (default: repository root). The full lens roster still runs; only the scope narrows.

`--tag <label>` — freeform run label recorded in telemetry (see `references/telemetry.md`).

## Routes to

`${CLAUDE_PLUGIN_ROOT}/skills/tribunal/SKILL.md` — dispatches the eleven tribunal-* reviewers (and, on a large repo, the optional map-structure / map-deps mappers).

## When NOT to use

- A review of the current diff → `/ca:review` (gate-blocking, fast).
- A lean periodic sweep → `/ca:checkpoint` (cheap, frequent; tribunal is its rare, deep counterpart).
- An adversarial STRIDE pass on one sensitive feature → `/ca:threat-model`.
- A governance packet for a window → `/ca:audit`.
- Anything on a schedule or in a hot loop — tribunal is a rare, deliberate, expensive convening, not a routine gate.

## Hard gate

MUST NOT dispatch any lens before you acknowledge the Phase 0 cost estimate. MUST NOT act as a required gate or block a merge/commit. MUST NOT file an issue or send telemetry without explicit authorization. Read-only on project code until the filing gate; findings file as GitHub issues, never the task board.

View in repo