raddue/temper

Temper

<!-- CANONICAL: shared/dispatch-convention.md -->

All subagent dispatches use disk-mediated dispatch. See shared/dispatch-convention.md for the full protocol.

<!-- CANONICAL: shared/delve-engine.md -->

The finder angles, the verify gate, the effort tiers, the cap semantics, and the eight-field output schema are NOT redefined here — they live in shared/delve-engine.md. /temper drives that engine: Round 1 dispatches it (bug-angle subset, high effort) to enumerate the tracked set T, and each later round drives it again over the fixed regions to hunt new gating findings (Track A, Step 4).

<!-- CANONICAL: shared/severity-verdict-contract.md -->

The severity and verdict vocabularies, and the gating rule T = {CONFIRMED, PLAUSIBLE} × {Critical, Important}, are the contract's — not temper's (I11). See shared/severity-verdict-contract.md; temper consumes that gating rule to build T and defines no scale or verdict of its own.

Like tempering steel after forging — iterative heat-and-quench cycles that set final hardness and elasticity — /temper runs successive fresh-eyes review rounds until the change converges. Round 1 drives the delve-engine fan-out (bug-angle subset) to enumerate a tracked set T of gating findings; each later round re-verifies whether every member of T is resolved against the fixed code and admits any new gating finding the fix introduced. The loop exits when T is fully resolved and no new gating finding entered.

Core principle: Review early, review often. Fresh eyes every round — but the per-round instrument is the engine's parallel finder fan-out + verify gate (plus a per-member re-verification pass), not one holistic reviewer. Convergence is the resolution status of an enumerated finding set, never a cross-round count comparison. (Distinct from /audit: temper drives delve-engine's instance-bug fan-out — one-reproduction defects; /audit runs systemic lenses — different machines.)

Renamed from /code-review (2026-05-17) to avoid collision with Claude Code's built-in /review command. Same iteration behavior; the argument shape and platform-agnostic PR support are new.

Non-Goals

Temper reviews code diffs only. Use a different skill for:

• Design docs / plans / concepts — use /audit or /red-team.
• Systemic multi-site pattern review — subsystem-wide patterns, absences, or structural drift with no single reproduction — use /audit. (temper itself drives delve-engine's parallel fan-out for instance-bug enumeration — one-reproduction defects; it does not defer that wholesale to /audit. The boundary is the reproduction discriminator: one concrete reproduction is temper/delve's; a no-single-repro pattern is /audit's.)
• Executable cross-component bug-hunting (adversarial tests against assembled features) — use /inquisitor.
• Security-specific review with attacker-perspective coverage — use Claude Code's built-in /security-review or /siege for a deep multi-agent security audit.
• Iterative red-team of any artifact (not just code diffs) — use /quality-gate.

Relationship to /quality-gate

Temper and quality-gate share a loop shape (fresh reviewer each round, stagnation detection, escalate on architectural concerns). They differ in scope and caller:

• /quality-gate is the generic iterative red-team loop over any artifact (design, plan, code, hypothesis, mockup). It is invoked by artifact-producing skills as their terminal gate.
• /temper is the code-diff-specific instance — same loop shape, plus forge integration (PR metadata, optional post-back), plus the fix-verification convergence model. It is user-facing for ad-hoc review and is called by build / debugging / finish on diffs.

temper drives shared/delve-engine.md for its finding enumeration — it is the engine's fix-verification loop driver, in contrast to /delve, which runs the same engine once and never loops or emits a merge verdict.

When in doubt: if the artifact is a code diff, use temper. If it is anything else (or you are inside an artifact-producing skill writing the gate), use quality-gate.

When to Request Review

Mandatory:

• After each task in subagent-driven development
• After completing major feature
• Before merge to main

Optional but valuable:

• When stuck (fresh perspective)
• Before refactoring (baseline check)
• After fixing complex bug

Dependencies

| Component | Required? | Purpose | Fallback if missing | |---|---|---|---| | git | Required | Diff resolution, SHA range, default-branch detection, per-round working-tree snapshots (git stash create, §3.8) | None — abort with clear error | | shared/delve-engine.md | Required | The parallel finder fan-out + verify gate temper drives to enumerate T (R1) and hunt new gating findings (R2+ Track A) | None — abort; temper has no engine of its own | | shared/severity-verdict-contract.md | Required | The T = {CONFIRMED, PLAUSIBLE} × {Critical, Important} gating rule and the severity/verdict vocabulary (I11 — temper defines none of its own) | None — abort; temper coins no scale or verdict | | Forge CLI (gh / glab / bb) | Optional | PR metadata fetch + optional Step 5 post-back | Probe in order; if all missing, fall through to git-plumbing and ask user for description | | crucible-consensus MCP server | Optional | External-model candidate feed via external_review (R1-only external_candidates, see External Model Review) | Skip silently — gather no external candidates (≡ external_review=skip) | | crucible:test-coverage | Optional | Test-alignment audit when behavioral changes are made | Skip; recommend manually | | crucible:checkpoint | Optional | Fallback per-round working-tree snapshot mechanism for the uncommitted-mode fix-delta derivation (§3.8); the primary mechanism is git stash create (no dependency), so checkpoint stays optional. Also a pre-fix rollback target when build wraps temper. | Skip silently — git stash create is the primary path |

Invocation

/temper                          # auto-detect (see Step 1 case 3)
/temper 259                      # PR identifier on the current forge
/temper https://...              # PR URL on any forge
/temper main..HEAD               # explicit SHA range
/temper a1b2c3..d4e5f6           # explicit SHA range
/temper 259 max_rounds=8         # override default 5-round circuit breaker
/temper 259 max_rounds=8 external_review=skip  # skip redundant external_review on re-invocation

Argument shape: [PR-id-or-URL | <base>..<head>] [max_rounds=<N>] [external_review=skip]. No argument means auto-detect.

How to Request

Step 1: Resolve the review scope (forge-agnostic)

Determine what to review based on the argument:

Case 1 — PR number or URL. Fetch metadata (title, body, base ref, head ref). Forge detection is CLI-probe order, not hostname-literal (covers GitHub Enterprise Server and any other GH-flavored host). When the argument is a URL, parse the forge from the URL host first and use only the matching CLI (handles fork workflows where origin and upstream live on different forges). When the argument is a bare PR number, probe CLIs in order against the current origin.

If the argument is a URL, parse the forge from the URL host and try only the matching CLI:

• github.com or any host gh authenticates against (GHE) → gh pr view <id> --json title,body,baseRefName,headRefName,author --repo <owner/repo-from-URL>
• gitlab.com or any GitLab host → glab mr view <id> --repo <project-from-URL>
• bitbucket.org or any Bitbucket host → bb pr view <id> --repo <slug-from-URL>
• Unknown host → fall back to git plumbing (git fetch <remote> <head-ref>); ask the user to paste the description.

If the argument is a bare PR number, try CLIs in order against the current origin:

1. gh pr view <id> --json title,body,baseRefName,headRefName,author — covers GitHub and GitHub Enterprise (any host gh is authenticated against; verify with gh auth status --hostname <host> if needed).
2. glab mr view <id> — covers GitLab and self-hosted GitLab.
3. bb pr view <id> (or REST) — covers Bitbucket.
4. None of the above succeeded → fall back to git plumbing: git fetch <remote> pull/<id>/head (GitHub-style ref) or git fetch <remote> merge-requests/<id>/head (GitLab-style); ask the user to paste the description if they want it factored in.

Distinguish CLI errors from missing CLIs. A CLI that exits non-zero with "404 / PR not found / authentication required" is not a missing-CLI fallback path. Surface the error to the user (e.g., "gh found the PR but auth failed — re-authenticate or paste the diff manually") and pause for instruction. Falling through silently on a CLI error would dispatch a review against the wrong scope.

Map the fetched metadata to <base>..<head> SHA range using git rev-parse <baseRef> and git rev-parse <headRef>.

Case 2 — SHA range (argument contains ..). Use as-is. Metadata is empty: no PR description, just the diff.

Case 3 — No argument (auto-detect). Precedence (first match wins):

1. If HEAD is detached (git symbolic-ref -q HEAD returns non-zero), require an explicit argument — auto-detect is ambiguous in detached state. Abort with a one-line instruction telling the user to pass a SHA range.
2. Try forge-CLI detection of the current branch's PR. If found, treat as Case 1. If the CLI is present but errors (auth-fail, 403, rate-limit, network), surface the error and pause per Case 1's distinguish-error-from-missing rule. Only the unambiguous "no PR for this branch" result advances to step 3.
3. Resolve the upstream default branch via git symbolic-ref refs/remotes/origin/HEAD (handles main, master, trunk, or anything else the remote uses). Use <that-ref>..HEAD as the SHA range.
4. If no origin/HEAD is set (rare; usually means the remote was never properly cloned), check which of origin/main, origin/master, origin/trunk exist. If exactly one exists, use its merge base with HEAD and narrate the fallback ("[temper] origin/HEAD unset; fell back to origin/<name> as the only main-like ref present"). If more than one exists (legacy repos with both origin/main and origin/master), abort with: "Multiple main-like refs found (origin/main, origin/master). Pass an explicit <base>..<head> range — the model has no signal which one this branch was cut from." If none exist, abort with the existing "Cannot determine default branch" message.

Anti-rationalization: don't hardcode gh calls in the dispatch path. The skill is forge-agnostic — the CLI used is whichever the environment makes available. Skip metadata gracefully on missing CLIs; surface explicit errors on present-but-failing CLIs.

Step 1.5: Diff preflight (mandatory — runs before dispatch)

Classify the resolved diff before spending an engine dispatch on it. Empty / binary / submodule-only diffs are recognized and handled explicitly so they cannot produce silent false-Clean verdicts. (This preflight runs ahead of the R1 delve-engine dispatch — see Step 2's short-circuit ordering — so no engine cost is spent on a non-substantive diff.)

Run git diff --numstat <base>..<head> and inspect:

• Empty diff (no entries): short-circuit. Return Clean — no changes to review immediately. Do not dispatch the engine. Callers (build, finish) see this as "Clean" but with Reason: empty-diff distinguishable from a substantive Clean.
• Binary-only diff (every entry has -\t-\t<path> indicating binary): note in the engine scope description / round metadata that the diff is binary-only and content cannot be inspected. Do not produce a Clean verdict against unreviewable content; surface Architectural — binary-only diff requires human review.
• Submodule pointer-only diff (changes are entirely in .gitmodules or submodule SHA pointers): note it in the round metadata and flag a Suggestion to inspect the submodule contents separately. Do not produce a spurious Clean.
• Mixed text + binary: pass the text portion normally as the engine scope; note the binary files in the round metadata so they are not treated as reviewed.
• Diff too large (>5,000 added+deleted lines per numstat): warn the user and offer to split per-commit or per-file. If the user proceeds anyway, note the over-cap in the round metadata and dispatch with a context-window degradation warning. This is a soft cap, not a hard block. Non-interactive callers (build / debugging / finish dispatching /temper): on >5,000-line diffs, proceed automatically with the over-cap note and emit a degraded-context flag in the round metadata. Interactive (standalone) callers retain the offer-to-split flow above.

Empty-diff caller contract. Pipeline callers (build / debugging / finish) MUST treat Reason: empty-diff as a soft-warn — surface to the user ("temper found no changes between BASE and HEAD; confirm this is intended") before proceeding past the gate. The most common cause is uncommitted work, a wrong base, or detached-HEAD post-rebase. Ad-hoc / standalone callers may proceed silently (the user invoked /temper knowing the state).

Step 2: Round 1 — drive delve-engine, enumerate the tracked set T

Round 1 is a recall pass + enumeration. Drive shared/delve-engine.md to find all gating defects in the diff, then build the tracked set T from its kept records.

Short-circuit ordering (two distinct short-circuits at two stages — the order is load-bearing):

1. Step 1.5 preflight runs FIRST, AHEAD of the R1 engine dispatch. The empty / whitespace-only / binary-only / submodule-pointer-only diff short-circuit (Step 1.5) fires before any engine call — so no engine cost is ever spent on a non-substantive diff. The Reason: empty-diff Clean (no reviewer dispatched) is preserved exactly. The R1 engine dispatch happens only after the preflight admits a substantive, reviewable diff.
2. The empty-T short-circuit is a DISTINCT, LATER condition — reached only when the preflight already admitted a real diff AND the R1 engine ran successfully and enumerated nothing gating. It is not the empty-diff case (empty-diff = "nothing to review, no engine call"; empty-T = "the engine reviewed a real diff and found no Critical/Important CONFIRMED/PLAUSIBLE finding"). The guarded check below applies to this second condition only.

The R1 engine drive. Dispatch shared/delve-engine.md once with:

• scope = the full diff (<base>..<head> from Step 1).
• angles = the bug-finding subset only: line-by-line, removed-behavior, cross-file. (The four quality angles are excluded — they are capped non-gating per the contract and never enter T.)
• effort = high (recall-biased; the tier delve-engine §3 pins for a gating hunt).
• cap = set explicitly HIGH, well above the expected |T|. delve-engine §6: cap truncates the ranked output and does not guarantee a gating finding is preserved, so a Critical/Important above the cap would be silently dropped. Do not leave it at the default 10.

The fan-out and the per-candidate verify gate run through the harness-adapter dispatch mechanism — temper issues no harness-specific call inline (I1). On a harness with no parallel-subagent primitive, the adapter's sequential fallback runs the angles one pass per angle (it warns once that recall may drop).

Build T from the kept records. From the engine's kept eight-field records, T = the gating 2×2 of the contract (§3): every kept record whose verdict is CONFIRMED or PLAUSIBLE and whose severity is Critical or Important. PLAUSIBLE@C/I gates even without a runnable repro — that is the recall hole this model closes. (Reference shared/severity-verdict-contract.md for the gating rule; temper copies no table.)

Identity key vs. adjudication payload (distinct). Each member of T has:

• A five-field identity / dedup key — {file, line, summary, severity, verdict} — used to dedup T and carry a member forward across rounds. (A subset of the engine's eight-field record; failure_scenario, scope, effort are not needed to distinguish one member from another.)
• The full originating eight-field delve-engine record (delve-engine §6 — {file, line, summary, failure_scenario, severity, verdict, scope, effort}), retained per member keyed by that identity. This is the adjudication input the R2+ per-member re-verifier (Track B, Step 4) receives — it needs failure_scenario to re-derive REFUTED-after-fix / a code-based downgrade against the fixed code. The identity key is the carry-forward handle; the eight-field record is the adjudication payload.

Each member also carries a transient readjudicated boolean — per-round auxiliary state, NOT part of the identity key (two members with identical identity tuples are the same member regardless of readjudicated). Initialize a newly-enumerated R1 member to readjudicated = false.

Empty-T-at-R1 short-circuit (guarded — two-part sanity check). If the R1 engine drive (reached only past the Step 1.5 preflight) yields an empty T, short-circuit to Clean only after both:

1. The engine actually executed (non-error). Confirm a well-formed result (a list of kept records, possibly empty) — not a dispatch error, timeout, empty-string output, or a degraded "no subagent primitive" abort. An error result is not an empty T: do not short-circuit; surface it as a dispatch failure / re-attempt, never as Clean.
2. cap did not truncate the GATING subset. Key on the Critical/Important kept-record count, not the total kept count: short-circuit only if the C/I kept-record count is strictly below cap AND T is empty. (A non-gating Minor/Suggestion tail filling cap is harmless — a gating finding is lost to truncation only when the C/I subset alone reaches cap.) If the C/I kept-record count equals or exceeds cap, treat it as gating-subset truncation — do not short-circuit.

Scope of this guard — empty-T only. This C/I-saturation guard decides solely whether a genuinely-empty T may short-circuit to Clean. When T is non-empty, a cap-saturated C/I set means "proceed to fix a (large) T," never "re-run R1": the enumerated members are already a valid gating T and the loop proceeds to Step 3; R2+'s changed-region fan-out + cheap full-diff sweep (Step 4 Track A) re-hunts the whole range each round and admits any gating finding the R1 cap dropped.

Bounded re-run (no unbounded loop). When T is empty AND the C/I subset is cap-saturated, re-run R1 exactly once at a doubled cap:

• Non-empty T → proceed to fix T (Issues-Found path); no further re-run.
• Empty T with C/I subset now strictly below the doubled cap → genuine empty-T, short-circuit to Clean.
• Empty T but C/I subset still at/above the doubled cap → do NOT re-run again. Proceed with the (empty) T and emit a cap-saturation signal in the round metadata (analogous to degraded-context, Step 1.5) so the caller sees "the gating set could not be bounded under cap" — surfaced as a degraded/indeterminate verdict requiring human attention, never a clean Clean and never a runaway re-run loop. At most ONE doubled-cap re-run ever occurs.

If the C/I count is strictly below cap on the first run, no gating finding was truncated, so an empty T is genuine even if the non-gating tail consumed the rest of cap — short-circuit to Clean directly, no re-run.

Per-invocation dispatch-id (concurrency isolation). Every /temper invocation generates a unique dispatch-id at Step 1: temper-YYYYMMDDTHHmmss-<6-char-nonce>. Generate via a cryptographic RNG (e.g., python -c 'import secrets; print(secrets.token_hex(3))' for 6 hex chars). If a dispatch file path already exists on disk, regenerate the nonce and retry — never overwrite. The dispatch file path and the metadata.dispatch_id field both include this id, so concurrent invocations (e.g., user-initiated overlapping with build's Phase 4) cannot collide. Round numbering remains per-invocation; the dispatch-id disambiguates (skill, round) traceability tuples in the external_review MCP and in any session-log consumers. (The R2+ Track-B per-member dispatches extend this stem with a -m<NN> member suffix — see Step 4.) Dispatches are disk-mediated per shared/dispatch-convention.md: write the filled prompt/inputs to a dispatch file (one file per dispatch-id), then dispatch a Task subagent that reads that file — never paste inputs directly into the Task tool prompt.

Freshness Boundary

Temper's core principle ("fresh agent every round, no anchoring beyond the enumerated T") is convention-plus-mechanism. Each round uses a fresh agent — no reviewer reuse — with one deliberate, documented exception: the R2+ per-member re-verifier (Track B) must receive T (the enumerated tracked set is its input — that is fix-verification). The exception is scoped to T only.

The R2+ Track-B verifier receives, across the boundary, only these inputs and nothing else:

• The fixed code range to adjudicate against (the whole fixed tree per §3.8 — {FIXED_BASE_SHA} / {FIXED_HEAD_SHA}, see Step 4).
• Per member of T: its full originating eight-field delve-engine record keyed by the 5-field identity, plus the transient readjudicated flag.

It must not receive:

• Any prior-round prose reports, round narratives, or fixer rationale narrative (only the enumerated T records cross the boundary — not "everything the last round said").
• PR review comments (only PR title + body are pulled via the forge CLI; comments are out of scope).
• Commit messages / fixup-commit subjects — the verifier is instructed (in temper-reviewer.md) to read diff/code content only, not git log. The no-git log anchoring guard still holds; this shifts the boundary from orchestrator-side redaction (unenforceable, since the verifier runs its own git) to verifier-side discipline.
• Any out-of-band notes from the user "for the reviewer's awareness."

This boundary is what keeps round-N independent of round-N-1 apart from the sanctioned T carry. Step 5's optional post-to-PR happens after a round completes; on subsequent rounds the fresh agent is dispatched against the fixed code, and PR comments (which now contain prior findings) are excluded from the metadata fetch.

Step 3: Act on feedback and iterate

• Record T membership, NOT a count. For each member persist its five-field identity ({file, line, summary, severity, verdict}), its full eight-field record, and its readjudicated flag. Convergence keys on the resolution status of these enumerated members — never on a Critical+Important count compared across rounds.
• Fix every member of T. A PLAUSIBLE@C/I member gets the same fix priority as a CONFIRMED one — it is a real regression the verifier could only call PLAUSIBLE for lack of a runnable repro, not a doubtful finding (per the contract / delve-engine). Fix priority follows severity, not verdict.
• Note Minor and Suggestion findings for later (non-gating — they never enter T; see Severity / Verdict Vocabulary below).
• Push back if a finding is wrong (with reasoning). Note that a repro-less PLAUSIBLE@C/I is not discharged by fixer prose — it discharges only via the §3.3 paths re-derived against the fixed code (Step 4).

Step 4: Rounds 2+ — fix-verification loop

After fixing the members of T, each round R ≥ 2 runs two SEPARATE dispatch tracks against the FIXED code. They are not the same dispatch and not the same gate. Both use fresh agents (no reviewer reuse); the only prior-round input that crosses the freshness boundary is the enumerated T (§3.7, Freshness Boundary above).

Fixed-region derivation (the scope Track A receives). Per round R, compute the incremental changed-region set = the regions the fixer touched since the prior round's verification pass, PLUS a cheap full-diff regression backstop:

• Committed mode (HEAD advanced since R-1, HEAD@R != HEAD@R-1): fix delta = diff(HEAD@R-1 .. HEAD@R).
• Uncommitted mode (fixes applied to the working tree, HEAD@R == HEAD@R-1): snapshot the working tree at each round boundary via git stash create (it builds a tree/commit object capturing tracked working-tree modifications and prints its SHA without touching HEAD, the index, or the working tree — the fixer is never disturbed; crucible:checkpoint is the documented fallback). Fix delta = diff(snapshot@R-1 .. working-tree@R). Record each round's snapshot SHA in the per-invocation round metadata keyed by (dispatch_id, round) (the same structure carrying readjudicated flags and round verdicts); the snapshot is a dangling object addressed by SHA, kept out of refs/. Mode is selected per round boundary by checking whether HEAD advanced, so a run may switch modes round-to-round.
• PLUS a cheap full-diff regression backstop — a sweep over the whole base..head range, kept cheap (it is a backstop), to catch a regression outside the touched hunks that a narrow fix-delta scope would miss (the exact hole the old count-delta model had).
• Cleanup: snapshot objects are transient — at the END of the gate run (any terminal verdict) temper drops the recorded SHAs from its metadata; the dangling objects are then reclaimed by normal git gc. No snapshot survives past the invocation.

Track A — hunt NEW gating findings (delve-engine fan-out)

Drive shared/delve-engine.md over the round-R changed-region set above (incremental fix delta + cheap full-diff sweep) as scope, bug-angle subset, with cap set explicitly HIGH — well above the expected count of new gating findings a single round's fix can introduce (mirror R1's cap reasoning; the default cap=10 is insufficient for a gating hunt). The fan-out proposes new candidates; each passes through delve-engine's own verify gate (one verifier per deduped candidate). This is delve-engine's only R2+ job: hunting NEW findings — the engine has no per-member re-verification input, so re-verification of T does not route through it.

A new candidate the gate assigns CONFIRMED/PLAUSIBLE @ Critical/Important is admitted to T with readjudicated = false (the new-member admission gate). Raw fan-out output is never admitted directly; an unverified, REFUTED, or below-C/I candidate stays out of T.

Track-A cap-saturation signal. Apply the same gating-subset truncation check Step 2 applies at R1: if the Track-A Critical/Important kept-record count reaches cap (equals or exceeds it), the admitted new-finding set may be truncated — a new gating finding the fix introduced could sit above the cap. In that case the round is not read as a clean "no new gating finding entered"; surface a cap-saturation signal in the round metadata. The Clean condition's "no new gating finding entered" (Done When) is satisfiable only when Track-A's C/I kept-record count is strictly below cap (gating set provably un-truncated). (Key on the C/I subset, not the total kept count — a non-gating tail filling cap is harmless.)

Track B — re-verify each t ∈ T (temper-owned per-member dispatch)

Re-verification is temper-owned, separate from the engine fan-out. For each member t ∈ T, dispatch one fresh temper-reviewer.md adjudicator (one per member) to adjudicate that single member against the WHOLE round-R fixed tree. temper-reviewer.md re-applies the contract's verdicts/severity (CONFIRMED / PLAUSIBLE / REFUTED + severity, per shared/severity-verdict-contract.md §2) to the fixed code — it defines no verdict vocabulary of its own (I11) and needs no delve-engine input. It is a temper template, dispatched through the harness-adapter subagent mechanism, fed the member's full eight-field record — not a delve-engine verify-gate adjudicator.

Track-B adjudication range = the WHOLE FIXED TREE, never the incremental delta (the most important Track-A-vs-Track-B distinction). For each member the adjudicator re-checks t.failure_scenario against original base .. round-R fixed-tree:

• Uncommitted mode: original base .. working-tree-snapshot@R (the git stash create snapshot SHA), NOT diff(snapshot@R-1 .. working-tree@R).
• Committed mode: original base .. HEAD@R.

A member's failure_scenario may live in code the fixer did not touch this round; if Track-B re-verified against only the incremental delta, that member's code would be absent from the diff and the adjudicator would falsely conclude RESOLVED-by-absence, re-opening the recall hole. Re-verifying against the whole fixed tree guarantees a member whose defect persists in unchanged code is correctly re-affirmed STILL-GATING.

Per-member dispatch contract (Track-B slots — see §5 of the plan / temper-reviewer.md):

• {MEMBER_RECORD} — the full eight-field delve-engine record for the single member being adjudicated, JSON-serialized, keyed by its 5-field identity. failure_scenario is the construct re-checked against the fixed code.
• {FIXED_BASE_SHA} = the original base (the same base R1 enumerated against — NOT the prior round's HEAD/snapshot).
• {FIXED_HEAD_SHA} = the round-R fixed-tree ref — the git stash create snapshot SHA (uncommitted mode) or HEAD@R (committed mode).
• {READJUDICATED} — the member's transient readjudicated flag carried across the boundary; the adjudicator sets the flag on emitting its per-member outcome (feeds the §3.5 defer-once-only bookkeeping).

One-dispatch-file-per-member rule. N members in a round ⇒ N per-member dispatch files, each adjudicating exactly one member — there is no aggregate "review all of T in one dispatch." This preserves fresh-eyes isolation per member.

Per-member dispatch-id scheme. Each per-member dispatch extends the per-invocation stem (temper-YYYYMMDDTHHmmss-<6hex>, Step 2) with a zero-padded member-index suffix -m<NN> (e.g. temper-20260603T101500-a7f3c2-m01, …-m02). Sharing the round stem but differing in -m<NN> means N concurrent per-member dispatch files cannot collide on disk; if a generated path already exists, regenerate-and-retry / never-overwrite as for the base id. Each per-member metadata.dispatch_id carries the full …-<6hex>-m<NN> id.

(R1 dispatches no temper-reviewer.md — it is pure delve-engine enumeration. Track A never uses temper-reviewer.md; temper-reviewer.md is the Track-B per-member re-verifier only.)

Per-member outcomes (no temper-owned vocabulary, I11)

temper-reviewer.md re-applies the contract verdicts/severity to the fixed code and emits, per member, one of:

• RESOLVED — re-applying the contract verdict no longer establishes the defect (it would now be REFUTED, or the construct/path is gone). Member leaves T.
• REFUTED-after-fix (repro-less PLAUSIBLE@C/I only) — the adjudicator actively re-derives the contract's REFUTED verdict against the fixed code (the suspect construct is provably gone). A DISCHARGE — member leaves T. (Same REFUTED verdict from the contract, re-applied; temper coins no new verdict.)
• DOWNGRADED (code-based) — the adjudicator re-assigns severity per the contract's scale to a tier below C/I against the fixed code → it leaves the gating 2×2 (folds to Minor/Suggestion, reported verbatim). A DISCHARGE — member leaves T.
• STILL-GATING — re-applying the contract re-affirms CONFIRMED/PLAUSIBLE @ C/I against the fixed code → stays in T.
• ESCALATE (repro-less PLAUSIBLE@C/I only) — the adjudicator can neither re-derive REFUTED nor downgrade → the member is escalation-eligible (architectural / human-ack path, §3.3).

Discharge path for repro-less PLAUSIBLE@C/I members (§3.3)

A repro-less PLAUSIBLE@C/I could otherwise trap T non-empty forever. Each round the adjudicator RE-ADJUDICATES it against the fixed code. It discharges ONLY by becoming REFUTED-after-fix or by a code-based severity downgrade below C/I. It NEVER discharges on fixer rationale alone — prose-discharge of a repro-less PLAUSIBLE is the exact recall hole this redesign closes.

A member the adjudicator can neither re-derive-REFUTED nor downgrade is escalation-eligible. Escalation is NOT a DISCHARGE: such a member is neither RESOLVED nor DISCHARGED, so it stays LIVE in T and BLOCKS Clean. It does not silently leave T to permit a Clean in the same run — instead the loop routes to the terminal Architectural verdict (handing it to human-ack) once the previously-seen unresolved subset is solely escalation-eligible (branch table below). It leaves the loop by escalating, never by silent accept. (The fixer-rationale-the-verifier-accepts path remains available only for genuinely-CONFIRMED findings the fixer argues are false positives — the verifier still adjudicates the rationale — and does not apply to repro-less PLAUSIBLE@C/I.)

Verdict logic (§3.4 / §3.5)

New-member admission gate. A new gating finding enters T in round R only after Track A's verify gate assigns it CONFIRMED/PLAUSIBLE @ C/I; it initializes readjudicated = false.

"Previously-seen" boundary. A member is previously-seen in round R iff it was in T at the END of round R-1. A member admitted in round R is NOT previously-seen until R+1 — so in its admitting round it cannot trip Stagnation. R1's enumerated T is the end-of-R1 set; members survive into R2 as previously-seen. R1 has no prior round, so Stagnation can never fire on R1.

Evaluate the round (the Stagnation / branch-table logic is subordinate to escalation):

• Clean = every member of T is RESOLVED or DISCHARGED (RESOLVED, or DISCHARGED via §3.3 — REFUTED-after-fix or a code-based downgrade-below-C/I only) AND no new gating finding entered this round. An escalation-eligible unresolved member is neither RESOLVED nor DISCHARGED, stays live in T, and BLOCKS Clean — temper never emits Clean while a live escalation-eligible member is in T (I6). Such a member leaves the gate by the loop routing to Architectural, never by silent removal so a Clean can be emitted.
  • A new-admit round is NEVER Clean (→ Issues-Found). Any round in which Track A admits ≥ 1 new gating member is non-Clean and resolves to Issues-Found (loop continues) — regardless of how the carried T resolved that round. Even if every previously-seen member RESOLVED/DISCHARGED, the "no new gating finding entered" condition fails. The new member enters with readjudicated = false and becomes Clean-blocking and Stagnation-eligible only from R+1. Clean is reachable only in a round that both resolves/discharges all carried members and admits no new gating finding.
• Issues Found = T has unresolved members; loop continues. (Reported into the round report, but loop-continuing — not a terminal verdict.)
• Stagnation = the previously-seen unresolved subset of T does NOT shrink across two consecutive (non-deferred) rounds — no previously-seen member became resolved/discharged. Judged only on the previously-seen unresolved subset; fires regardless of newly-admitted members (resolving one old member while admitting one new is progress; resolving zero old members while admitting new ones trips Stagnation). The earliest evaluation is R2-vs-(end-of-R1). Termination is guaranteed by the round cap (Max-Rounds), NOT by Stagnation — Stagnation is an early-exit optimization. A Defer round does NOT count in the consecutive-round sequence (it is skipped; the next non-deferred round compares against the last non-deferred prior evaluation). Earliest a member whose only prior round was its defer can FIRE Stagnation is R+2 (eligible to contribute a non-shrink observation at R+1; two consecutive non-deferred non-shrinking evaluations are required to fire).
• Defer one round (TRANSIENT continuation outcome) — continues the loop (like Issues-Found), suppresses Stagnation this round (the branch fired instead of declaring Stagnation), and consumes one round against Max-Rounds. Once-only per member, keyed on readjudicated: deferring sets the flag; a member whose flag is already set does NOT defer again. Not a merge verdict the user sees.

Before declaring Stagnation, branch on WHY the non-shrinking previously-seen unresolved subset did not shrink (these rows are EXHAUSTIVE over composition of a non-empty, non-shrinking subset — the empty case is Clean / Issues-Found, not here; the verdict is total, no silent fall-through to Max-Rounds):

| Subset composition (non-empty, non-shrinking) | Verdict | |---|---| | SOLELY escalation-eligible members (repro-less PLAUSIBLE@C/I the adjudicator can neither re-derive-REFUTED nor downgrade) | Architectural (needs human adjudication — not wheel-spinning) | | SOLELY members not yet re-adjudicated this round (readjudicated == false) | Defer one round (give each its re-adjudication pass) | | MIXED escalation-eligible + not-yet-re-adjudicated, with NO genuinely-stuck member | Defer one round (next round reduces to SOLELY escalation-eligible → Architectural, or shrinks normally) | | Any subset containing ≥1 genuinely-stuck member (readjudicated == true AND not escalation-eligible AND still unresolved), regardless of what else it contains | Stagnation (real churn: a member that could resolve via fix but the fixer keeps failing) |

• Stagnation is SUBORDINATE to escalation. When the previously-seen unresolved subset is SOLELY escalation-eligible, the loop routes to Architectural immediately — it does NOT wait for the 2-round Stagnation antecedent.
• "Genuinely stuck" = readjudicated == true && !escalation-eligible && unresolved — it has had its re-verification pass against the fixed code and is still gating, and is not escalation-eligible. Fully observable (no counterfactual). A member still readjudicated == false is awaiting its first re-verification pass (→ Defer), not genuinely stuck.
• Defer is regrounded on a RE-VERIFICATION event, not a fix event — a member defers iff it has not yet had a Track-B re-verification pass against the fixed code since its admitting round (exactly readjudicated == false). "Fix-attempted" cannot distinguish a defer-eligible member from a stuck one (Step 3 fixes all unresolved C/I every round, so a carried member was already fix-attempted in its admitting round).
• This table operates over the previously-seen unresolved subset only; a member admitted this round contributes nothing to any row, so the "SOLELY not-yet-re-adjudicated" row is populated by previously-seen members carried in still readjudicated == false, never by freshly-admitted ones.
• Drip caveat: under continuous new-member admission (each round Track A admits a fresh finding that defers once), Stagnation may never fire — Max-Rounds is then the operative terminator. Correctness-safe (the loop still halts at the cap, no false Clean); confirms Stagnation is an optimization, not the termination guarantee.

Max-round circuit breaker

The loop is bounded by 5 rounds by default — the termination guarantee (Stagnation is only an early-exit optimization). At round max_rounds without a terminal verdict, escalate to the user with T's unresolved members:

"Temper reached the {max_rounds}-round cap without resolving every member of the tracked set T. Unresolved members: [{file:line — summary — severity/verdict} for each live member of T]. To extend, re-invoke /temper <scope> max_rounds=N — this starts a fresh review loop with a higher cap (the new loop re-enumerates T from scratch; round counting restarts at 1, and the fresh agents have no anchoring from prior rounds beyond a re-enumerated T). If the remaining members appear structural rather than fixable in another loop, escalate to design / plan instead."

Callers (build Phase 4) treat the cap escalation as a soft block: the diff is not approved; the user decides whether to extend, refactor, or accept the remaining members. Overridable via trailing max_rounds=<N>; defaults to 5 to keep runaway protection on by default.

Done When

The outcomes split into four terminal merge verdicts (the loop settles on exactly one and STOPS) and two non-terminal loop-continuation outcomes (the loop CONTINUES). Do not call this "five terminal verdicts."

Terminal merge verdicts (loop STOPS):

• Clean — every member of T is RESOLVED or DISCHARGED (§3.3 only), AND no new gating finding entered this round. Caller may proceed.
• Stagnation — the previously-seen unresolved subset did not shrink across two consecutive non-deferred rounds AND the subset contains ≥1 genuinely-stuck member (branch table). Caller escalates to user.
• Architectural — the previously-seen unresolved subset is solely escalation-eligible (repro-less PLAUSIBLE@C/I the adjudicator can neither re-derive-REFUTED nor downgrade), or any round emits an architectural concern. Caller escalates immediately, regardless of round number (subordinate-to-escalation: this pre-empts the Stagnation antecedent).
• Max-Rounds — max_rounds reached without a terminal verdict. The termination guarantee. Caller escalates with T's unresolved members.

Non-terminal loop-continuation outcomes (loop CONTINUES):

• Issues-Found — T has unresolved members (or a new gating finding was admitted this round). Reported into the round report but loop-continuing — it is emitted (so it appears in the caller-visible verdict set) yet does not terminate the loop.
• Defer-one-round — the sanctioned one-round grace (once-only per member, keyed on readjudicated). An internal continuation state the user does not see as a merge verdict; it suppresses Stagnation that round and consumes one round against Max-Rounds.

Step 5 (optional) — Post findings to the PR

This step is an output convenience, not part of the review contract — findings are complete after Step 4 regardless of whether they're posted. It exists for users who want the local review surfaced on the PR for asynchronous collaborators.

If the user explicitly asks ("post this to the PR", "leave a review comment"), publish using whichever CLI fits the forge:

• GitHub → gh pr review <id> --comment --body-file <findings.md>
• GitLab → glab mr note <id> -m "$(cat findings.md)"
• Bitbucket → bb pr comment <id> --file findings.md (or REST)
• Unavailable / unknown forge → output the formatted body for the user to paste

Confirm success explicitly. Check the CLI's exit code. On non-zero exit, classify the failure mode and respond per the table below — do not silently skip:

| Failure mode | Response | |---|---| | Auth-fail (gh auth status failure / token expired) / rate-limit (403) / network error | Paste-mode with retry guidance: "Posting failed with <error> — re-authenticate / wait and retry, or paste the body manually below." | | PR closed-without-merge | Paste-mode with conditional guidance: "PR is closed; if you intend to reopen, paste the body. Otherwise the findings remain in your session." | | PR merged or deleted | Do not offer paste-mode. Surface the findings locally: "The PR is no longer postable (merged / deleted). Findings remain in your session for reference." |

Never post without an explicit user instruction. Findings live in the user's session by default.

Dispatch

temper drives shared/delve-engine.md through the harness-adapter fan-out mechanism (shared/harness-adapter.md §4, §7), disk-mediated per shared/dispatch-convention.md — never a harness-specific call inline (I1). Round 1 drives the engine (high effort, bug-angle subset) to enumerate the tracked set T; Rounds 2+ re-hunt the changed range the same way. Where a harness has no parallel-subagent primitive, the adapter's sequential fallback (§5) runs the angles as multiple sequential passes, warning once that recall may drop.

temper is one of the exactly two files that dispatch delve-engine directly (the other is delve). The canonical engine-dispatch marker line follows; the I2 allowlist test keys on it with the anchored pattern grep -rn '^dispatch: delve-engine':

dispatch: delve-engine

Severity / Verdict Vocabulary

temper defines no severity scale and no verdict vocabulary of its own (I11). The four-tier severity scale (Critical / Important / Minor / Suggestion), the verify-gate verdicts (CONFIRMED / PLAUSIBLE / REFUTED), and the gating rule are the contract's — see shared/severity-verdict-contract.md (canonical-included in the header; this section references it, it does not copy its tables).

The gating rule (tracked set T)

Convergence keys on the tracked set T, computed by temper from the engine's {severity, verdict} kept records per the contract §3:

T = { CONFIRMED, PLAUSIBLE } × { Critical, Important }

A kept finding enters T iff its verdict is CONFIRMED or PLAUSIBLE and its severity is Critical or Important. A PLAUSIBLE@C/I gates even without a runnable repro (the recall hole this model closes). Minor and Suggestion are both non-gating — they never enter T (reported verbatim, never dropped). See the contract's full verdict × severity matrix; temper adds nothing to it. There is no count-delta mapping and no Suggestion-folding-into-Minor: convergence is the resolution status of T's enumerated members, never a count.

Verdict synonyms

Two parallel vocabularies for temper's merge verdict exist for historical reasons; temper recognizes both as synonyms:

| Canonical | Accepted synonym | |---|---| | Clean | Approved | | Issues Found | Needs Fixes | | Architectural | Architectural Concern ≡ Escalate |

The left column is canonical; the right-column synonyms remain accepted to avoid breaking older callers.

temper merge-verdict set (Done When taxonomy)

These are temper's loop outcomes — distinct from the contract's per-finding verify-gate verdicts above. Four terminal merge verdicts: Clean, Stagnation, Architectural, Max-Rounds. Two non-terminal loop-continuation outcomes: Issues-Found (reported but loop-continuing) and Defer-one-round (internal continuation state). Each is defined in Done When (Step 4).

External Model Review (Optional)

When enabled, external_review is a candidate source for the R1 verify gate, not a parallel scored reviewer. External findings inject into delve-engine's external_candidates input on Round 1 only; the same verify gate adjudicates them (CONFIRMED / PLAUSIBLE / REFUTED + severity) before any can enter T. They never bypass the gate and never run as a separate scored pass.

• external_review=skip (default-on stays): no external candidates; delve's fan-out is the only candidate source.
• enabled: external findings inject into the R1 external_candidates feed; the verify gate adjudicates them cross-origin with the internal fan-out candidates. R1-only.

Prose → external_candidates DRAFT transform (the wiring step). temper's external_review step emits free-form prose findings; delve-engine's external_candidates input (delve-engine §2) takes a list of DRAFT records, each {file, line, summary, severity} with NO verdict. So temper converts each external prose finding into one draft record: extract file/line from its location, summary from its one-line what-and-where, and a severity DRAFT hint from its stated severity. Per delve-engine §2/§5: any inbound verdict is discarded (the verify gate is the sole verdict authority) and the inbound severity is a draft hint only that the gate re-assigns per the contract — so a malformed/over-stated external severity cannot inject an authoritative Critical. The drafts merge into delve-engine's pre-dedup candidate pool and are adjudicated alongside the internal fan-out candidates.

Cadence (R1-only) + documented limitation. External candidates are gathered once per /temper invocation, on Round 1 only — to second-opinion the initial finding set without multiplying external-API cost across the fix loop. R2+ do not re-run external_review: an external candidate REFUTED on R1 cannot re-enter T; fix-introduced regressions are caught by delve's own R2+ fan-out (changed-region scan + cheap full-diff sweep, Step 4 Track A), not by re-running external_review.

Re-invocation skip rule: Re-invoking /temper via max_rounds=N after a stagnated run normally triggers another R1 external candidate gather. To avoid redundant external API spend on essentially-the-same diff, pass external_review=skip. (No automatic same-diff detection — skip is explicit-only.)

Gather external candidates by calling external_review with:

• prompt: contents of skills/shared/external-review-prompt.md
• context: the same diff and requirements context the R1 engine drive receives
• skill: "temper" (top-level argument for per-skill toggle enforcement)
• metadata: {"skill": "temper", "round": 1, "dispatch_id": "<from Step 2>"} (traceability)

Per-skill toggle: The server checks the skill argument against skills.temper in the external review config. If false, the server returns unavailable and temper gathers no external candidates. Server hyphen-normalization: mcp-servers/crucible-consensus/server.py normalizes hyphens to underscores in the skill name before lookup, so a hyphenated skill name (red-team) and its underscored form (red_team) resolve to the same toggle. Today temper has no hyphen — the contract works trivially — but the rule is documented here for future renames.

Config-rename note for opt-out users. The toggle key was renamed from code_review to temper on 2026-05-17. If you previously set skills.code_review: false to opt out, rename the key to skills.temper: false to preserve your opt-out. Otherwise the toggle inherits the default True.

Graceful degradation → skip (gather no external candidates, ≡ external_review=skip). When the external source is degraded, temper silently gathers no external candidates and the engine run proceeds on its own fan-out:

• external_review tool not available (MCP server not running): gather none.
• Response status is "unavailable" (no config or disabled): gather none.
• Response status is "partial" (some models failed): feed the available external findings as drafts; note which models failed.

Either way the R1 engine drive proceeds — the external feed never blocks or delays it; on external failure the fan-out stands alone.

Cross-Reference to Deep Cloud Review

For GitHub PRs only, Claude Code's built-in /ultrareview <PR> runs a deeper multi-agent review in a cloud sandbox. After a local /temper round, suggest /ultrareview to the user when either of these holds:

• The round's findings span ≥2 distinct delve-engine finder angles (e.g. a line-by-line defect and a cross-file mismatch, or a removed-behavior regression and a quality concern — angles defined in shared/delve-engine.md §4), OR
• The user explicitly wants a second opinion before merge on a high-stakes change.

"Distinct angles" means the engine's finder angles, not severity tiers — the trigger is breadth of issue surface, not depth of any single issue.

/ultrareview is GitHub-specific; do not suggest it for GitLab / Bitbucket / other-forge PRs.

Example

[Just completed Task 2: Add verification function]

You: Let me request review before proceeding.

[Step 1: Resolve scope]
- No argument given; HEAD is on branch `feat/verify`
- gh pr view (current branch) → no PR yet
- origin/HEAD → main; resolved range: origin/main..HEAD
- BASE_SHA=$(git rev-parse origin/main)
- HEAD_SHA=$(git rev-parse HEAD)

[Step 1.5: Preflight]
- numstat: 4 files changed, 87 added, 12 deleted — text diff, in-cap, proceed

[Step 2: Round 1 — drive delve-engine (bug-angle subset, effort=high, cap=20), dispatch-id temper-20260603T150500-a7f3c2]
  Engine ran non-error; C/I kept-count (2) < cap → T genuine, not truncated.
  Enumerate T (2 members):
    t1  verify.py:40  CONFIRMED / Important  — no error handling for empty input
    t2  verify.py:55  PLAUSIBLE / Important  — progress callback may fire after cancellation (no runnable repro)
  Minor: 1 (magic number) — non-gating, not in T.
  Each member: readjudicated=false.

You: [Fix both members of T — t2 (PLAUSIBLE@Important) gets the same fix priority as t1 (CONFIRMED)]

[Step 4: Round 2 — Track A (delve-engine over fix delta + cheap full-diff sweep, cap=20) + Track B (one temper-reviewer per member, against the WHOLE fixed tree)]
  Track B — re-verify carried members:
    t1 → RESOLVED (empty-input guard now present)
    t2 → REFUTED-after-fix (DISCHARGE: the post-cancellation callback path is provably gone) — leaves T
  Track A — NEW gating finding admitted to T (readjudicated=false):
    t3  verify.py:48  CONFIRMED / Important  — the new guard swallows a real I/O error
  All carried members resolved/discharged, BUT a new gating finding entered this round.
  → Verdict: Issues-Found (NOT Clean — a new-admit round is never Clean). Loop continues.

You: [Fix t3]

[Step 4: Round 3 — Track A + Track B]
  Track B — re-verify carried member:
    t3 → RESOLVED (I/O error now re-raised)
  Track A — no new gating finding admitted; C/I kept-count (0) < cap (un-truncated).
  Every member of T resolved/discharged AND no new gating finding entered.
  → Verdict: Clean. Proceed to Task 3.

The Round-2 verdict is Issues-Found, not Clean, even though both carried members resolved — Track A admitted a new gating finding (t3), and a new-admit round is never Clean. Clean is reached only in Round 3, which resolves the carried member and admits no new gating finding.

Test Alignment

When behavioral changes were made, consider dispatching crucible:test-coverage after temper completes. This catches stale tests, missing coverage, or assertion drift introduced by the fixes.

Caller context determines who runs it:

• Pipelines (build / debugging / finish): the pipeline orchestrator dispatches crucible:test-coverage automatically — temper does not.
• Standalone / ad-hoc: the user (or whoever invoked /temper directly) is responsible for the hand-off. Recommend crucible:test-coverage when the review noted behavioral changes that might affect existing tests, when the diff modified functions with dedicated test files, or when the reviewer said "tests should be updated" without specifics.

This is the single canonical statement of the rule; the workflow sections below cross-link rather than restate.

Integration with Workflows

Build pipeline (Phase 4): Temper runs after each task. Build dispatches crucible:test-coverage automatically (see Test Alignment).

Standalone plan execution: Temper after each batch (3 tasks). The user dispatches crucible:test-coverage afterward if behavioral changes were made.

Ad-hoc development: Temper before merge, when stuck, after a complex bug fix. The user dispatches crucible:test-coverage afterward if behavioral changes were made.

Migration note — pre-rename retrospectives. crucible:forge retrospectives written before 2026-05-17 are tagged with code_review. Forge's consult-past-lessons step does not auto-alias; if you want the old lessons to surface for temper, query both keys. (Out of temper's scope to fix; flagged here so users know.)

Red Flags

Never:

• Skip temper because "it's simple"
• Ignore Critical issues
• Proceed with unfixed Important issues
• Argue with valid technical feedback
• Skip re-review after fixes ("the fixes look fine")
• Reuse the same reviewer subagent across rounds
• Pass prior-round prose / commit messages / fixer rationale to the next agent — only the enumerated T records cross the freshness boundary (see Freshness Boundary)
• Compare Critical+Important counts across rounds — convergence is the resolution status of T's enumerated members, never a count delta
• Discharge a repro-less PLAUSIBLE@C/I member on fixer prose — it discharges only via REFUTED-after-fix or a code-based downgrade re-derived against the fixed code (§3.3)
• Defer a member twice — Defer-one-round is once-only per member (keyed on readjudicated)
• Emit Clean in a round that admitted a new gating finding, even if every carried member resolved — that round is Issues-Found
• Hardcode gh (or any single forge's CLI) in the dispatch path — temper is forge-agnostic
• Silently fall through on a CLI error (vs missing-CLI) — surface the failure to the user
• Run past the 5-round circuit breaker without explicit user instruction
• Post to a PR without explicit user instruction
• Silently skip Step 5 on auth-fail / closed-PR / rate-limit — fall through to paste-mode

If the reviewer is wrong:

• Push back with technical reasoning
• Show code/tests that prove it works
• Request clarification

See template at: temper/temper-reviewer.md