chore(reviewer): dispatch codex on gpt-6-astra

[kevin-agrology]

TL;DR: The codex reviewer now runs on gpt-6-astra — the top model in codex's own catalog —
instead of gpt-5.6-terra. The one-line registry change is the easy part; most of this PR is
recording the two ways the swap can silently fail, both of which I hit while making it.

What and why

gpt-6-astra is priority 1 in codex's catalog, "our most capable model for complex, demanding
work", above the whole gpt-5.6 family it replaces here. Read out of codex debug models rather
than guessed: codex -m takes a free-form string, so a wrong id is accepted by the CLI and fails at
dispatch — and a codex turn that goes wrong returns [no-findings], which is indistinguishable at
the gate from a real clean review. That failure mode is why this arm gets checked rather than
trusted.

Two ways the swap fails silently, both hit here

1. The CLI gates the catalog. The model list is fetched server-side and filtered by client
version. On one account, at one moment:

client	sees gpt-6-astra
0.147.0	✗
0.154.0	✓

Confirmed the hard way: after the new client had refreshed the shared cache so it contained
astra, the old client re-fetched and still omitted it. The companion dispatches spawn("codex")
from PATH, so pinning a model the PATH codex predates breaks the arm every round.

2. Updating the binary is not enough. The companion keeps a long-lived codex app-server per
session and it does not re-exec. A broker from two days earlier was still answering as 0.147.0
after the CLI was already 0.154.0 — so the first gpt-6-astra dispatch would have gone through a
client with no such model, and the arm would have been "verified" against exactly the wrong thing.
SIGTERM the broker (never -9; it unlinks its socket and pid file on the way out) and let the next
dispatch respawn it.

Both are now in the registry comment, with the diagnosis commands, because neither is discoverable
from the symptom.

Vendor mapping, pinned rather than assumed

verify-vendor keys on the model's self-report, which for codex is already unstable —
gpt-5.6, gpt-5.6-terra and gpt-5 observed from one requested id (#20). An unmappable
disclosure is die 1 → the reviewer's whole round is quarantined, every round, for a reviewer that
answered correctly.

gpt-* already covers the gpt-6 family, but nothing asserted it. Now tested (gpt-6,
gpt-6-astra, GPT-6-Astra, gpt-6-codex, gpt-7, …) with its own mutation entry. The existing
reviewer/vendor-openai-family entry only narrows the o-series and leaves gpt-* intact, so that
line's two properties now have an entry each.

Docs

• README's documented MULTI_REVIEW_REVIEWER_MODEL default.
• The command doc's --effort paragraph: gpt-6-astra defaults to low effort, not none.
  Still far below what the turn needs to read the document it was pointed at, so the --effort high
  rule is unchanged — the observation is now dated to the model it was made on.

Verification evidence

• reviewer.test.sh pins the exact default row, so the model bump surfaced as a red suite
  rather than drifting in — the assertion doing its job. Updated deliberately, in its own commit.
• Local gate green: both suite legs (bash 5 and /bin/bash 3.2), shellcheck incl. .githooks/pre-push,
  version check 1.36.0 → 1.37.0, --verify-table (397 entries), and --only on all three vendor
  entries — each with baseline green first, all caught.
• Both accounts on this machine verified end to end: binary 0.154.0, stale broker restarted,
  gpt-6-astra visible to the PATH binary.

The real review on the new model — done, and what it showed

The multi-review gate on this PR was the first gpt-6-astra dispatch, and the check your notes
require before trusting a model swap.

The swap took effect. The turn disclosed gpt-6 — a spelling never produced by
gpt-5.6-terra — and verify-vendor mapped it to openai and admitted the copy. That is the
gpt-* pin above proving itself in a live dispatch rather than only in a test.

It read the document: five commands — the skill, the protocol, cat of the review doc, the
marker check, then the append. Unlike the documented failure, where three of four dispatches
referenced the doc in zero commands.

	duration	verdict
gpt-5.6-terra baseline	~75s	—
gpt-6-astra	36.1s	[no-findings]

Two caveats, stated rather than buried. 36s sits inside the old 32–49s failure band, and codex
has now returned [no-findings] three turns running. The distinguishing fact is that those turns
never opened the document and this one did — so this reads as a fast clean review, not the old
failure. Watch it; do not yet treat a codex clean verdict as strong evidence.

--effort high cannot be confirmed from the job record — the companion does not persist model or
effort. Verified that two earlier known-good gpt-5.6-terra dispatches also omit them, so the
absence is normal and carries no signal either way.

What this PR's own gate caught

Three low findings, all from fable, all agreed, all defects in this PR's documentation — the
first being a claim I made without evidence:

• r1 — the --effort paragraph asserted gpt-6-astra at low does not read the document, when
  only gpt-5.6-terra at none had ever been observed doing that. An unverified claim in the
  sentence carrying that rule's whole justification, in a PR that itself listed the check as
  outstanding. Now states the general fact and dates the observation to the model it was made on.
  A doubled "observed … : observed" splice artefact went with it.
• r2 — the registry NB named one self-report spelling while the test comment added on this same
  PR named three others. Rewritten to the general fact both rely on, listing every spelling seen —
  now including gpt-6.
• r3 — two mirrors of the same rationale still named the old model, one of them inside a bad
  message a reader meets while it is red. Editing that message touched a mutation entry's expect,
  which --verify-table does not check, so command/codex-dispatch-effort was re-probed
  explicitly: still caught.

🤖 Generated with Claude Code

https://claude.ai/code/session_019vdNEXiS6JU1dRzvzXYS2n