Adversarial review via grok (Grok Build)

The value of this leg is a sixth accounting family: Grok (xAI) is none of GPT/Gemini/Claude/DeepSeek/Nemotron, so it can satisfy the cross-family rule when the other paid families are already spent on authorship. It is a paid weekly pool — schedule it like the codex leg's quota, never like the free pool's best-effort capacity.

Before the first run of a session

Read references/grok-runtime.md (same directory). It holds the family-level mechanics — the always-approve config trap, the three read-only layers and which one is actually load-bearing, the old-kernel sandbox no-op, the prompt-file rule, the measured quota fingerprint — plus the UNVERIFIED list this young family still carries. This adapter has zero calibration-journal rows of its own (the Grok family's rows so far were all served through cursor -- cursor-grok-4.6-*, grok-4.7-* in cursor-runtime.md -- and say nothing about this CLI's permission and sandbox behaviour): until the first verified hit rates land here, treat its verdicts as one more pair of eyes, not the gate leg, and record every run.

Establish an immutable review target

One frozen directory per reviewer, at the exact commit, that nothing else touches — no lead activity inside it. Not "whenever possible": a reviewer reads the WORKING TREE, not your commit. Measured — a round ran mutation testing in the same worktree mid-review and the reviewer opened a CRITICAL on a mutated, non-compiling file it was never meant to see.

Freeze it with the suite's tested helpers instead of hand-rolling the shell; every bug ever found in this step was in a hand-rolled copy. The suite-root resolver and both calls — freeze-target.sh to create it, verify-target.sh before AND after the run — are in dev-lead Phase 2, and the reasoning is in methodology.md §7. Everything below assumes $REVIEW_TARGET_DIR is that frozen directory and $REVIEW_HEAD is the SHA it was frozen at.

Launch one machine-bounded read-only run

The boundary is the headless built-in tool allowlist plus explicit MCP denial, not trust: no shell tool, no edit tools, no MCP calls, no subagents. The diff is embedded in the prompt because a delegate without a shell cannot run git (and must not need to).

Pre-launch guard:

BASE=$(git -C "$REVIEW_TARGET_DIR" merge-base origin/main "$REVIEW_HEAD")   # the branch point, never a branch name
git diff --stat "$BASE" "$REVIEW_HEAD"  # file list must match the change under review

RUN_DIR=$(mktemp -d "${TMPDIR:-/tmp}/grok-review.XXXXXX")
# Write the focus prompt to "$RUN_DIR/prompt.md" in its own FOREGROUND step,
# with the pinned unified diff (BASE → REVIEW_HEAD) embedded in a fence —
# same pattern as the agy leg, same reason: the reviewer reads files but
# cannot and must not derive the span itself.

cd "$REVIEW_TARGET_DIR" && \
  [ "$(git rev-parse HEAD)" = "$REVIEW_HEAD" ] && \
  grok --prompt-file "$RUN_DIR/prompt.md" \
    -m grok-4.6 \
    --effort high \
    --sandbox read-only \
    --tools "read_file,grep,list_dir" \
    --disallowed-tools "Agent" \
    --deny 'MCPTool(*)' \
    --no-memory --disable-web-search --verbatim \
    --max-turns 40 \
    --output-format plain > "$RUN_DIR/review.out" 2>&1

Launch under the host's background mechanism with output redirected to a file. Role-specific choices:

• --tools "read_file,grep,list_dir" is the load-bearing read-only layer (headless-only allowlist; runtime file explains why plan mode is not). --sandbox read-only rides along for free on kernels that can enforce it and warns-and-continues on ones that cannot — check which happened before trusting it (runtime, UNVERIFIED 1).
• --disallowed-tools "Agent" is mandatory: subagents are documented as exempt from edit gates and inherit the account's always-approve default. It is also the suite's only machine-enforced no-recursive-delegation.
• --deny 'MCPTool(*)' is mandatory: --tools limits built-in tools, but MCP tools remain separately available. Grok matches their names as server__tool (not mcp__server__tool), and a deny rule wins over any account allow rule or always-approve setting; see the runtime reference.
• -m grok-4.6 explicitly — never inherit the catalogue default silently; grok models before the run, and verify the served model from the output once UNVERIFIED 5 is captured.
• Quota failure is loud and immediate (measured; fingerprint in the runtime file). On hitting it, re-route the round to another family — do not retry into a weekly budget.

Running this leg as a subagent? You are a leaf — block, do not "wait". Nothing will wake you when grok --prompt-file returns; ending your turn on "waiting for the notification" abandons the review. Poll to terminal inside a single tool call, and issue another such call immediately if it times out (dev-lead Phase 2).

Verify the target again after the run:

git -C "$REVIEW_TARGET_DIR" rev-parse HEAD        # must equal $REVIEW_HEAD
git -C "$REVIEW_TARGET_DIR" status --porcelain=v1 # must be empty

• Materializing evidence the frozen tree does not contain — another revision's copy, a merge-base baseline — has cross-family rules on where it goes and what guarantees it carries: docs/materializing-evidence.md. Never write scratch files into the frozen target; a leg that genuinely cannot keep them elsewhere declares those exact paths to verify-target.sh instead.

Writing the focus prompt

Same red-team discipline as every family — first-party pre-merge framing, numbered claimed properties with boundaries, falsify-don't-confirm, trigger + observable consequence + severity + file:line per finding, state fixes already made, ask what the tests do not enumerate, forbid praise. The gate, then two grok-specific lines:

• Evidence gate with unguessable anchors (per file: line count + verbatim last line; per claim: quoted code; NOT REACHED acceptable, HOLDS-without-quote not). The no-shell posture below does not excuse it: a line count and a last line are READ, not executed.
• Tell it that it has no shell: evidence is quoted file content at file:line, and if confirming a finding would require running something, it must name the exact command and expected result for the lead to run.
• Tell it not to call MCP or web tools; the tree, the embedded diff, and the prompt are the complete context (web search is disabled at the flag level too).

Verify and report

Treat output as hypotheses; verify every finding against the frozen tree before relaying it, and separate host-verified evidence from the reviewer's claims. Pairing rule across the suite: the reviewer must come from a different model family than whatever implemented the change — Grok reviewing Grok-implemented work satisfies nothing, exactly as with every other family. This skill is review-only: do not apply fixes unless the user asks. Append the run's verified hit rate to the runtime file's calibration journal — this family's first rows are the whole reason its early runs exist.