@openrig/cli 0.6.14 → 0.7.0

package/daemon/docs/reference/whats-new.md

@@ -1,87 +1,142 @@
-# What changed in OpenRig 0.6.14
+# What changed in OpenRig 0.7.0
 
-This note is for an agent on an install that was just upgraded to 0.6.14. It lists only what behaves differently from
-0.6.13 and what to do about it. For everything OpenRig can do, read the capability map:
+This note is for an agent on an install that was just upgraded to 0.7.0. It lists only what behaves differently from
+0.6.14 and what to do about it. For everything OpenRig can do, read the capability map:
 `rig context get onboarding-width/public-what-you-can-do.md`. Each release replaces this file, so
 `rig context get reference/whats-new.md` describes the installed version once the upgraded daemon is running. Without
 a running daemon, read `$OPENRIG_HOME/reference/whats-new.md`. The daemon refreshes that copy when it starts, so right
-after an upgrade it can still hold the previous version's note. Coming from 0.6.12 or earlier, also read 0.6.13's
-release notes: its changes and migration `117` arrive with this upgrade.
+after an upgrade it can still hold the previous version's note.
 
 ## After the upgrade
 
-- **Restart the daemon** (`rig daemon stop`, then `rig daemon start`). No migration runs. One setting is added,
-  `transport.local_user_guard`, off by default (see below).
-- **The bundled openrig-core plugin goes from 0.1.14 to 0.1.15.** Installed copies are replaced and carry refocus's own
-  notes lookup.
+- **Restart the daemon** (`rig daemon stop`, then `rig daemon start`). Six migrations run on the first start (116, 118,
+  119, 121, 122 and 123). Two settings are added, `terminal.history_limit` (default 10000) and
+  `terminal.inherit_tmux_environment` (default false), and `provider.subscription_moves` is removed.
+- **The bundled openrig-core plugin goes from 0.1.15 to 0.1.17.** Startup replaces installed copies of managed plugins and
+  marked global skills. It first copies every file it replaces under `$OPENRIG_HOME/backups/managed-refresh/<id>/`,
+  whether or not anyone edited it, and logs `[plugin-vendor] preserved previous contents of <file> at <copy> before
+  managed refresh` for each one. A stock upgrade from 0.6.14 copies about 22 files (about 250 KB), and a later start with
+  no new version copies none. The copies matter only for files someone changed: the copy keeps the bytes, but the change
+  may no longer be active after the refresh. Keep the log line, because it names the original file and the copy's folder
+  doesn't. If a copy fails, that plugin or skill isn't refreshed, its files are kept, and the log says so. Copies aren't
+  cleaned up.
+- **If you gave new agents accounts or API keys through tmux's global environment** (`tmux set-environment -g …`), new
+  agents no longer inherit it (below). Put the values in the seat's `env`, pass `rig up --env KEY=VALUE`, or keep the old
+  behaviour with `rig config set terminal.inherit_tmux_environment true`. Running agents aren't affected.
+- **If you write queue rows to another machine by its self-id** (`member@rig@<self-id>`), run `rig host doctor <alias>`
+  once per host: bindings learned before 0.7.0 have no address.
 
-## Output that changed shape
-
-- **`rig ask --wake`** on a seat whose runtime isn't Claude or Codex prints `Wake runtime '<runtime>' … is not
-  supported. Supported runtimes are claude and codex.` A `member@rig` target exits 2 (the daemon refuses it); a raw-id
-  `--runtime` value exits 1 (the CLI refuses it). No wake starts.
-- **`/healthz`** gains `euid`, the daemon's effective user ID, beside `pid`, whether or not the Mac check is on.
-- **`rig compact`** (manual) waits up to 240 seconds for its result, up from 180, because preparation now has 180
-  seconds, up from 120.
+## New things you can do
 
-## Seats and restore
+- **Hold a person's routine asks while they're away:** `rig gateway human quiet set <id> --daily HH:MM-HH:MM` or
+  `--until <time>` (`--tz`), and `end`, `clear` or `show`. A held ask posts once, without a mention, when quiet ends.
+  Asks tagged `escalation` or `wake-escalation` are not held.
+- **Apply a person's mode** ("asleep", "out of office"): `rig gateway human mode save <id> <name>` (with
+  `--availability`, `--expected-back`, `--decision-room "<their words>"`, `--exclude`, `--quiet`), then `apply <id>
+  <name> [--until …]`, `current`, `end` and `account`. Never tell the person "back to normal" while the account shows an
+  effect `kept`, `pending` or `failed`.
+- **Decide an ask inside a person's decision room:** check `rig gateway human mode room <id>`, then `rig gateway human
+  mode decide <qitemId> --application <id> --reason "…" --reversible|--irreversible`. It's recorded as delegated, never
+  as their answer, and only the agent that asked can decide. Permission prompts are refused (`permission-prompt`).
+- **Pass a rig's name instead of its id** to `archive`, `unarchive`, `release`, `shrink`, `expand`, `snapshot`,
+  `export` and `restore --rig`. A name two rigs share is refused and the matching ids are named: with `--json`,
+  `archive`, `unarchive`, `release`, `shrink`, `expand` and `restore status --rig` return `rig_ambiguous`.
+- **Stop a managed compaction's follow-up after `/compact` was sent:** `rig compact --cancel` now also disarms the
+  restore and audit prompts that would follow. It sends no input and can't undo the `/compact`.
+- **See your work candidates:** `rig queue whoami` adds `currentWorkChoice` when current work isn't settled.
+- **See why a wake didn't land:** `rig queue show --json` adds `lastNudgeInputBox`.
+- **See each seat's configured effort:** the TUI agent table's `CFG EFF` column, and `effort` and `effortSource` in
+  `rig ps --nodes --full --json`. It's the configured level, not what the model ran.
 
-- **A seat that refuses every send with "Managed pane identity unavailable or changed; no input written."** because an
-  older OpenRig never recorded its tmux pane can be repaired in place: `rig reconcile-session <seat>
-  --repair-missing-pane --no-launch`. It fills only the missing pane and keeps the session, resume token and occupant
-  generation; the result names the same session, with continuity unverified. It refuses, writing nothing, with
-  `repair_not_applicable` (the binding already has a pane), `pane_ambiguous` (more than one pane or window),
-  `pane_missing` (no PID), `guard_target_changed`, `guard_operation_in_progress`, `typing_guard_enabled` or
-  `repair_timed_out`. Against an older daemon it reads `repair_missing_pane_unsupported` and never adopts. It records no
-  event.
-- **A manual `rig compact` whose preparation stops at an ordinary approval** keeps waiting within its deadline instead
-  of giving up. OpenRig never answers the approval: the person, or an agent allowed to, answers it.
-- **Refocus resolves each ancestor's notes file itself** (`NOTES.md`, then `MISSION_NOTES.md`) instead of starting `rig
-  scope resolve-notes` per ancestor. Its output, budgets and settings are unchanged.
+## Behaviour that changed
 
-## New things you can do
+- **New agents start from a clean environment, not tmux's global one.** A new seat or handover successor gets:
+  - the launch environment: `PATH`, `HOME`, `USER`, `LOGNAME`, `CODEX_HOME`, `OPENRIG_HOME`, `OPENRIG_URL`,
+    `OPENRIG_PORT`, `OPENRIG_HOST`, the seat's own identity values (such as `OPENRIG_SESSION_NAME`) and the allowed
+    provider sign-in variables. Not `OPENRIG_DB` or `TMUX_TMPDIR` (see Known gaps);
+  - the daemon's `LANG`, `LC_ALL`, `LC_CTYPE`, `TZ`, `TMPDIR`, `XDG_CONFIG_HOME`, `XDG_DATA_HOME`, `XDG_CACHE_HOME` and
+    `CLAUDE_CONFIG_DIR`;
+  - the values named in tmux's `update-environment`;
+  - its own `env`.
 
-- **Repair a missing pane without adopting:** `rig reconcile-session <seat> --repair-missing-pane --no-launch`.
-- **Point a person at a page written for them:** `docs/reference/quickstart.md` ("Getting started") is the first-use
-  page, with a glossary. `docs/reference/getting-started.md` is now titled "OpenRig setup reference" and opens with what
-  the agent doing the setup needs; its sections and anchors are unchanged, so `rig context get
-  reference/getting-started.md#…` lookups still work.
+  Shell startup still runs. `rig setup` warns when it sees a custom tmux configuration.
+- **After a reboot, the daemon restores a kernel whose seats are all detached** (and still bound to their sessions), in
+  the background, as `rig up kernel --existing` would. `OPENRIG_NO_KERNEL=1` still skips it, and `rig start --json` reports `kernelRestore`.
+- **A seat missing a required startup file no longer blocks its rig's restore:** `rig up <rig> --existing` holds that
+  seat and restores the others (`partially_restored`).
+- **Seats added to a running rig** with `rig expand`, `rig grow` or add-member get its culture file and rig-level
+  startup, for rigs created on 0.7.0 or later. Older rigs get no backfill.
+- **A busy daemon gets the real request.** The CLI refuses only when the daemon is stopped or stale, the connection is
+  refused or blocked, or the daemon answering belongs to another OpenRig home. A slow daemon is no longer read as down.
+- **A new seat's first startup message** says it's OpenRig's identity context, not a task. A seat whose startup sends
+  nothing else is asked to run `rig whoami --json` and say it's ready for an assignment.
+- **A new Claude seat's first startup text** waits briefly (about five seconds) for Claude's input box before it's
+  sent.
+- **Codex seats that select openrig-core get the plugin installed into Codex.** While Codex hooks are on
+  (`runtime.codex.hooks_enabled`, default on), OpenRig installs it with Codex's own marketplace and plugin commands at
+  daemon start and at a fresh launch, unless the person's Codex configuration disables it.
+  - **A first install only** (no earlier install or plugin cache): OpenRig checks the installed hook files against its own
+    copy, then trusts the plugin's six shipped hooks by their exact definitions, so the seat starts without Codex's hook
+    review.
+    The file check happens only when trust is granted: a later edit to the cached hook scripts keeps that trust, as with any hook trusted in Codex.
+  - **An existing install keeps the person's choices.** A plugin or hook they disabled stays disabled. One they left
+    untrusted stays under Codex's review: Codex records nothing for "continue without trusting", so OpenRig doesn't read a
+    missing trust record as permission.
+  - **What it adds:** the four managed inline hooks stay the only activity reporters; the plugin adds refocus and its
+    skills.
+- **Watchdog delivery is recorded as it happened:** `rig watchdog status` outcomes are `sent`, `refused`, `failed`,
+  `skipped` or `terminal` (0.6.14 had `sent`, `skipped` or `terminal`). Every reminder carries "Delivery may repeat after
+  an unconfirmed attempt." under its header line, and two refusals in a row at one seat's prompt raise that seat's prompt
+  alert. A park wake shows the continuation its park recorded (`Recorded continuation: …`), so record one when you park.
+- **Slack:** a thread reply answers a parked question only if it was written after the question posted, and a message
+  Slack rejects as `invalid_blocks` isn't posted again.
+- **Claude Code team agents are asked for permission less often.** Housekeeping commands such as `archive`, `attach`,
+  `bind`, `release`, `reconcile-session`, `config set` and `seat continue` no longer prompt. `seat restart` and `policy
+  permissions apply` now do.
+- **`rig up --plan` waits as long as an apply** (120 seconds). An unanswered plan exits 1 and is safe to run again.
+- **`rig setup` keeps 10,000 rows of tmux history**, down from 50,000 (`terminal.history_limit`, 2000 to 1000000).
 
-## Off by default
+## Output that changed shape
 
-- **A Mac local-user check.** On a Mac shared by several accounts, `rig config set transport.local_user_guard true` (or
-  `OPENRIG_TRANSPORT_LOCAL_USER_GUARD=true` in the CLI's environment) makes the CLI refuse a local daemon another account
-  runs. It compares the PID and effective UID the daemon reports in `/healthz` with two `ps` readings and a second
-  health response, and refuses only when they agree on another account; the refusal names `rig daemon start --port
-  <unused-port>`. Missing, disagreeing or timed-out evidence, and an older daemon without `euid`, keep today's
-  behaviour. No daemon restart is needed. Explicit `OPENRIG_URL` targets and registered remote hosts keep their routing,
-  later browser or TUI connections aren't checked, and with it on `sudo rig …` against a user-owned daemon refuses. It
-  isn't authentication: it trusts the daemon's own report. Details: `rig context get
-  reference/getting-started.md#optional-mac-local-user-check`.
+- **`rig gateway human list`** shows each person's availability (`available`, `focus`, `away` or `off`) where it showed
+  `away` or `available`, plus a `quiet:` line; JSON adds `availability` and `quiet`.
+- **`rig attach`** prints `Sender:` (and `Tmux:` when the names differ), and `rig whoami` adds `identity.senderAddress`.
+  A clashing member name is refused with `address_conflict`.
+- **Send results** carry `managedCompaction`, and the CLI prints a `Notice:` line.
+- **`rig ps --rig <unknown>`** exits 1, and `--host H --rig X` filters by rig.
 
 ## What to stop doing
 
-- **Don't use plain `rig reconcile-session` to fix a launched seat's missing pane.** It adopts the seat into a new
-  session with no resume token; use `--repair-missing-pane --no-launch`.
-- **Don't abandon a manual `rig compact` because preparation hit an approval.** Answer it, or ask the person to, within
-  the 180 seconds.
-- **Don't try `rig ask --wake` on a Pi or custom seat.** Use `rig ask` without `--wake` to search what it said, or send
-  to the live seat.
+- **Don't use `rig provider moves`:** it's gone with its setting. Report a subscription move as a queue item to whoever
+  asked.
+- **Don't steer a new seat's account or keys through tmux globals.** Use the seat's `env` or `rig up --env`.
+- **Don't close a row `done` with `--closure-reason blocked_on`.** It's refused with `invalid_closure_reason`; use `rig
+  queue block <id> --on <child>`.
+- **Don't treat "daemon did not respond" as down.** Check the effect before any retry or restart.
+- **Don't look up a rig id first** for the commands above; pass the name.
+- **Don't restart the daemon to stop a managed compaction's follow-up prompts.** Use `rig compact --cancel`.
+- **Don't run `rig up kernel --existing` by hand after a reboot** before checking `rig status`.
+- **Don't reuse a `deliveryId` to deduplicate a send,** and don't pass `--reason` or `--actor` to `rig slack verify`.
+
+## Known gaps in 0.7.0
 
-## Known gaps in 0.6.14
+- **A new seat doesn't get the daemon's `OPENRIG_DB` or `TMUX_TMPDIR`.** A tool in the seat that reads `OPENRIG_DB`
+  directly can fall back to the default database. If you rely on either, pass it in the seat's `env` or with `rig up
+  --env`.
+- **A launch that warns "Scoped tmux environment unavailable; retaining the previous environment"** didn't give that seat
+  the clean environment, and the seat may lack OpenRig's variables. Check `env` in the seat before relying on them.
+- **A Slack channel-mapping change needs a daemon restart** (`rig daemon stop`, then `rig daemon start`). Don't use `rig
+  slack disable` then `enable` for it: enabling marks any alerts waiting to post to Slack as already seen, so open
+  exchanges miss them.
 
-- **The compaction and refocus fixes** are tested without a native compaction or a loaded machine: confirm a
-  compaction by its restore request or the drop in context, and check that a restored seat is really working.
-- **The pane repair refuses while typing protection is on.** The compaction refusal for a protected seat whose pane
-  isn't recorded still suggests plain `rig reconcile-session <seat> --no-launch`, which adopts. For a running launched
-  seat whose pane was never recorded, use `rig reconcile-session <seat> --repair-missing-pane --no-launch` instead;
-  it needs typing protection off, so turn protection off only if the person agrees. A delivery held from before the
-  repair can still refuse.
-- **`rig context get reference/quickstart.md` doesn't resolve:** the page isn't in the reference context pack. Read it
-  from the package's `docs/reference/` or the repository.
-- **On a Mac with more than one user account,** a second user's `rig` commands can reach the first user's daemon on
-  its default port (7433) unless `transport.local_user_guard` is on. The check trusts the daemon's own report, identity
-  can change between the check and the connection, and direct HTTP clients aren't covered.
-- **0.6.13's other known gaps still apply:** a fresh in-place Claude handover can report ready early when the screen,
-  pane or process can't be read or proven; one Slack app across machines hasn't run on two real machines, and Slack
-  recovery doesn't catch up older open threads; `rig seat set-cwd` checks the new folder once.
+- **A new Claude seat's startup text can stay in its input box unsent.** If a fresh Claude seat sits idle with text at
+  its prompt, press Enter in its pane, or ask the person to.
+- **The TUI's terminal button refuses inside a Herdr pane reached over SSH.** Start the TUI with `env -u SSH_CONNECTION
+  -u SSH_CLIENT -u SSH_TTY rig tui`, or run `rig terminal open '<view>' --provider herdr`.
+- **Claude seats on a macOS native install can read as needing attention after a restore.** Check the pane before
+  acting on it.
+- **Ubuntu 22.04's stock tmux 3.2a can crash its whole server** when OpenRig checks a pane that has just closed. Avoid
+  tmux 3.2a for OpenRig (`tmux -V`).
+- **Delegated decisions:** the ask is created before the decision, so without quiet hours it can post to the person
+  first. Pair a decision room with quiet hours, or decide before asking.
+- **`restore-check` still treats a missing startup file as rig-wide.** Trust `rig up --existing`'s per-seat result.

package/daemon/specs/agents/shared/skills/core/messaging-the-human/SKILL.md

@@ -5,6 +5,8 @@ metadata:
   cli_surfaces_referenced:
     - gateway human list
     - gateway human show
+    - gateway human mode room
+    - gateway human mode decide
     - queue create
     - queue transitions
     - queue block
@@ -69,6 +71,28 @@ rig queue create --destination <entityId>@external \
   --evidence-ref <durable-evidence> --verify --json
 ```
 
+Before asking a **decision**, check whether the person has a mode on with a
+decision room: what they said the team may decide for them meanwhile.
+
+```bash
+rig gateway human mode room <entityId>
+```
+
+If it names a room and your decision is plainly inside their words (and none of
+their exclusions), decide instead of waiting. Create the ask as above, then
+record your choice on it straight away:
+
+```bash
+rig gateway human mode decide <qitem-id> --application <applicationId> \
+  --choose <question>=<option> --reason "<why>" --reversible   # or --irreversible
+```
+
+It's recorded as decided on their behalf, never as their answer, the ask
+closes, and it's in their account when they're back. Say honestly whether it
+can be undone. A permission prompt or an approval is never decided this way.
+With no room, a room that doesn't plainly cover it, or any doubt, ask and wait;
+a recommended option is not a decision.
+
 An optional `--human-detail-file <path>` supplies one coherent supplemental
 reply in the same thread. Announce its purpose in the brief; the product also
 marks that a detail reply follows. The primary must already contain the complete

package/daemon/specs/agents/shared/skills/core/openrig-skills/SKILL.md

@@ -91,7 +91,7 @@ These ship in the OpenRig repo and reach a seat when its profile selects them. T
 Pod handbooks (load when you're in that pod):
 - **orchestration-team** — you're orchestrating a rig: dispatching, monitoring, keeping the loop moving.
 - **development-team** — you're on the dev pod: building and shipping product changes.
-- **review-team** — you're reviewing: fresh scrutiny, anti-slop, empirical verification.
+- **review-team** — you're reviewing: fresh scrutiny, anti-slop, grounded findings.
 - **oversight-team** — you're in an oversight pod: monitor boundaries and route findings without taking over the work.
 
 Product-management craft (load when shaping/reviewing work):
@@ -106,7 +106,7 @@ Product-management craft (load when shaping/reviewing work):
 ### Vendored craft — load when you're coding (ships with upstream provenance)
 General engineering skills OpenRig ships as vendored copies. Open when the task matches; they carry "modified by OpenRig" provenance.
 
-- **verification-before-completion** — about to claim done / passing / fixed: run the check and read the output first.
+- **verification-before-completion** — about to claim done / passing / fixed: have evidence that applies to the candidate you name first.
 - **systematic-debugging** — debugging: find the root cause before the fix.
 - **agent-browser** — driving a browser (screenshot / screencast) from an agent.
 - **frontend-design** — designing frontend / UI.

package/daemon/specs/agents/shared/skills/core/openrig-upgrade/SKILL.md

@@ -225,11 +225,17 @@ host in front of you.
    process are gone. If the command returns while either remains, stop: inspect
    identity and use the host's authorized recovery procedure. Do not blindly
    signal a PID.
-7. Start the target with `rig daemon start` or the host's known wrapper. Verify
-   daemon status, process path, listener, version, and database integrity.
-8. Run the plugin refresh helper in plan mode. Apply safe writes only after the
-   three roots and classifications make sense; resolve preserved paths one at a
-   time when required.
+7. Before starting the target, account for its startup refresh of managed plugins
+   and marked global skills. This runtime preserves differing replaced files under
+   `$OPENRIG_HOME/backups/managed-refresh/` and reports each recovery path; if the
+   target lacks that preservation, copy those trees first. Start it with
+   `rig daemon start` or the host's known wrapper. Verify daemon status, process
+   path, listener, version, and database integrity. Recovery copies retain bytes;
+   they do not promise custom behaviour remains active after refresh.
+8. Run the plugin refresh helper in plan mode. Its plan governs only the helper's
+   later writes, not startup writes that already happened. Apply safe writes only
+   after the three roots and classifications make sense; resolve preserved paths
+   one at a time when required.
 9. Verify protected seats with `rig ps --nodes -A --json`, representative
    `rig capture`, and `rig restore-check` where applicable. `-A` is required:
    without it the node read is your CURRENT rig only, and a daemon upgrade

package/daemon/specs/agents/shared/skills/pods/development-team/SKILL.md

@@ -26,6 +26,8 @@ Clarify consequential uncertainty, inspect the existing seam, then complete one
 coherent outcome. Reproduce a defect before repairing it; use tests that distinguish
 the failure and verify through the public surface. Keep chunks as large as the
 outcome and file territory permit. TDD is a feedback loop, not a two-seat protocol.
+When the work consolidates or refactors existing behavior, read
+[references/refactoring.md](references/refactoring.md).
 
 The builder reports the exact candidate, changed behavior, commands and observed
 results, with remaining uncertainty. No universal pre-edit proposal, QA approval

package/daemon/specs/agents/shared/skills/pods/development-team/references/refactoring.md

@@ -0,0 +1,11 @@
+# Refactoring and consolidation
+
+Read this when a change consolidates duplicated logic or refactors existing behavior.
+
+- Trace the callers before you consolidate.
+- Tell shared policy apart from capture, parsing and harness adapters. Code that looks the same can serve different harnesses with different semantics.
+- Name the observable behavior you preserve, and name any change you're making on purpose, separately.
+- Reuse suitable checks, or add the smallest comparison that would detect a consequential difference.
+- Keep compatibility where callers or persisted state need it. Remove an obsolete path once that's established.
+
+Adapted from the blast-radius tracing method in Cursor's pstack plugin (https://github.com/cursor/plugins/tree/190d28736eff128ec94f502a22c7fe0c4b56cd37/pstack).

package/daemon/specs/agents/shared/skills/pods/review-team/SKILL.md

@@ -25,7 +25,7 @@ named slice's explicit exception. Authors do not perform their own selected
 independent review.
 
 Match the selected review to the consequence. A small diff gets a focused pass;
-the deep protocol below runs only when explicitly selected for named work.
+the deep review method below runs only when explicitly selected for named work.
 Importance, size or a prior finding alone cannot self-select it. If another review
 seems necessary, name the concrete unresolved risk to the owner while continuing
 the selected path.
@@ -36,32 +36,26 @@ Derive the selection before forming a review position. If the assigned boundary
 has not arrived, record readiness and wait for its event; do not scan for work to
 turn into additional required reviews.
 
-## Context priming — always do this first
+## Context
 
-Before reviewing ANY code, you must understand the codebase context. Never review cold.
+Read the context this change needs before forming a position. Don't review cold.
 
-1. Read the project's `CLAUDE.md` or equivalent conventions doc
-2. Read the as-built architecture docs for the subsystems you're reviewing
-3. Read the relevant planning/spec docs if they exist
-4. Understand the domain vocabulary and key invariants
+1. The project's `CLAUDE.md` or equivalent conventions doc
+2. The as-built architecture docs for the subsystems the change touches
+3. The relevant planning or spec docs, if they exist
+4. The domain vocabulary and the invariants the change could break
 
-If you have blanks — areas you don't understand — say so explicitly and fill them before forming opinions. A review built on misunderstood context is worse than no review.
-
-For deep reviews, write a **context proof** before proceeding:
-- Subsystem purpose summary
-- Key invariants (must-not-break rules)
-- Architecture boundaries and constraints
-- PR/range intent and expected behavior
-- Unknowns / missing context
-- Confidence scores (0-100) per section
+Preparing context is part of the review, not a gate before it. Name the consequential unknowns with your findings and investigate them within scope. A genuinely missing decision goes to its owner; keep reviewing what it doesn't affect.
 
 ## Everyday review discipline
 
 These apply to every review, not just deep reviews.
 
+Does the change solve the user's problem with a maintainable design? Check affected contracts, invalid input, state transitions, recovery, consumers and unnecessary duplication.
+
 ### Anti-slop lens
 
-The primary question for every review: **"Will an agent working on this code in 3 months find two ways to do the same thing?"**
+Then, for every review: **"Will an agent working on this code in 3 months find two ways to do the same thing?"**
 
 Check for:
 - Code duplication across files or subsystems
@@ -70,27 +64,33 @@ Check for:
 - Parallel implementations where one should extend the other
 - Abstractions that don't earn their complexity
 
-### Empirical verification
+### Grounding findings
 
-Every claim you make must be verified against actual code. Not plausible inference. Not file-tree reasoning.
+Ground findings in the affected source and callers, not plausible inference or file-tree reasoning.
 
-- Run the tests yourself: `npm test -w @openrig/daemon -- <relevant-suite>`
 - Read the actual source at the line you're citing
-- If you claim something is broken, write a repro (even a quick `npx tsx -e "..."`)
+- Reproduce a consequential behavior claim through the permitted validation path where needed; reuse relevant run evidence with its limits
 - If you claim a test is missing, explain what input would break the code
 - If you claim duplication exists, cite both locations
+- Label source-only reasoning and untested concerns, and say what would confirm or falsify them
+
+Don't run code where the assignment forbids it, and don't hide an uncertainty because you can't run it here.
 
-A finding you haven't verified is a finding you shouldn't report.
+### What a finding says
 
-### Severity rating
+For a material finding, explain the user consequence, the affected path and how you know. Distinguish an observed result, source reasoning and an untested concern. Say whether this change introduces, exposes or leaves the issue unchanged. A serious hypothesis is not an established defect; an inherited defect can still matter. Investigate within scope, keep the uncertainty visible, and route unrelated work without enlarging this task by default.
 
-Rate every finding clearly:
-- **MUST-FIX** — blocks merge. Broken behavior, security issue, or test suite failure.
-- **HIGH** — contract violation or honesty failure. Should fix before calling the range clean.
-- **MEDIUM** — real concern that affects maintenance or agent UX. Should fix soon.
-- **LOW** — polish, robustness, or minor inconsistency. Fix when convenient.
+### Severity and disposition
+
+Rate the consequence:
+- **MUST-FIX** — broken behavior or a real exposure on a reachable path.
+- **HIGH** — contract violation or honesty failure.
+- **MEDIUM** — real concern that affects maintenance or agent UX.
+- **LOW** — polish, robustness, or minor inconsistency.
 - **INFO** — observation worth noting. Not a defect.
 
+Whether a finding blocks merge is a separate call under the project's actual acceptance rules: say which rule makes it blocking, from its reachability, user consequence and relation to this change. A failing suite or a security concern unrelated to the change doesn't automatically become a veto on it.
+
 ### Reporting findings
 
 Write review artifacts to disk so they survive compaction:
@@ -101,8 +101,8 @@ docs/review/<review-name>/01-review-<your-id>.md
 Also report to the orchestrator or chatroom:
 ```bash
 rig send <orchestrator-session> "REVIEW: <title>
-HIGH :: <file:line> :: <issue>
-MEDIUM :: <file:line> :: <issue>
+HIGH :: <file:line> :: <user consequence> :: <how you know> :: introduces|exposes|leaves
+MEDIUM :: <file:line> :: <user consequence> :: <how you know> :: introduces|exposes|leaves
 ..." --verify
 ```
 
@@ -126,89 +126,39 @@ When reviewing work that was implemented without a pre-existing spec (ad hoc, do
 - Ask: "Does this code deliver what it appears to intend? Are the contracts honest?"
 - This is called a **hindsight review** — you review forward from the code, not backward from a spec
 
-## Deep review protocol
+## Deep review method
 
-Only when the owner or composition explicitly selects this protocol for named work, the orchestrator coordinates these phases. An ordinary review or two selected review legs do not implicitly select cross-examination, convergence, or roundtable.
+Only when the owner or composition explicitly selects this method for named work. An ordinary review, or two selected review legs, is not a deep review. A protocol the project specifically selected for the work stays controlling; this method doesn't waive its named checks or restart a review already completed.
 
-### Phase 1: Context priming gate
+### 1. Independent first views
 
-Each reviewer independently reads context docs and writes a context proof (see above). The orchestrator reads both proofs and decides GO or NO-GO. No code review starts until the gate passes.
-
-### Phase 2: Independent reviews
-
-Each reviewer reads the full diff/range independently and writes findings to disk:
+Each reviewer inspects the relevant context, source and exact target before reading anyone else's findings, and writes findings to disk in the format above, with consequential unknowns:
 ```
 docs/review/<review-name>/01-review-<your-id>.md
 ```
 
-Do NOT read the other reviewer's work during this phase. Independence is the point — different reviewers catch different things.
-
-Your independent review should cover:
-- Test posture (does the suite pass? are there regressions?)
-- Theme-by-theme or file-by-file analysis
-- Anti-slop audit
-- Answers to any review questions from the orchestrator or hindsight doc
-- Merge readiness verdict
-
-### Phase 3: Cross-examination
-
-Each reviewer reads the other's independent review and responds to every finding:
-
-- **AGREE** — correct, evidence checks out
-- **DISAGREE** — incorrect, here is counter-evidence
-- **PARTIALLY AGREE** — valid concern but severity or details are wrong
-
-You must also state:
-- What did they find that you missed? (Be honest about your blind spots)
-- What did you find that they missed?
-- Do their findings change any of your severity assessments?
-- Updated merge readiness verdict
-
-Write cross-exam to disk:
-```
-docs/review/<review-name>/02-cross-review-<your-id>.md
-```
-
-### Phase 4: Convergence and roundtable
-
-The orchestration pod reads all reviews and cross-exams and writes a convergence synthesis classifying each finding as:
-- **CONFIRMED** — all reviewers agree
-- **DISPUTED** — disagreement exists with evidence on both sides
-- **WITHDRAWN** — originator retracted
+Independence is the point: different reviewers catch different things. Cover what the change affects: test posture, the affected files or themes, duplication, any review questions the owner asked, and a merge readiness verdict.
 
-Then a roundtable in the chatroom where all participants (reviewers + orchestrators) post positions, respond to each other, and converge on final findings and action items.
+### 2. Compare, then challenge what could change the disposition
 
-Culture for the roundtable:
-- Truth-seeking. Not contrarian for theater. Not agreeable to be nice.
-- Every participant posts an initial position
-- Every participant responds to at least one other's position
-- Every participant posts a final concur or amend
-- The host does not synthesize early — real back-and-forth first
+The decision owner compares the independent findings. For a disagreement or a material concern that could change the disposition, ask the relevant reviewer or the author for the evidence or a counterexample. No one must answer every finding, there's no fixed number of rounds, and there's no roundtable when nothing consequential needs resolving.
 
-### Phase 5: Final output
+### 3. One disposition
 
-The host writes the final roundtable document with:
-- Confirmed findings with severity
-- Final priority stack (P0 / P1 / P2)
-- Action items with owner
-- What the implementation team should NOT reopen
+The decision owner records one disposition:
+- findings with severity, and the blocking rationale under the project's acceptance rules, kept separate
+- evidence limits and any material dissent, still visible
+- action items with owner, and what the implementation team should not reopen
 
-## Reviewer behavioral awareness
+Agreement alone doesn't prove a finding. Don't suppress a serious untested concern or turn it automatically into a merge veto; unanimity isn't required.
 
-### If you are Claude (R1)
-- You tend to be strongest on architecture and weakest on edge-case honesty
-- You verify the happy path thoroughly but may miss failure-mode gaps
-- You should deliberately check: "What happens when this fails? What happens with bad input? What about the release-then-remove sequence?"
+## Choosing reviewers
 
-### If you are Codex (R2)
-- You catch edge cases that Claude misses
-- You are thorough at empirical verification
-- You may over-weight severity on issues that are real but minor
-- You should deliberately check: "Is this actually a shipped defect or just a robustness wish?"
+Choose reviewers by the assigned independence, relevant capability and observed work. A model name does not establish which failures it will catch.
 
 ### When reviewers disagree
 
-Disagreement is useful. Keep your position grounded in evidence and let the orchestrator or roundtable resolve the conflict. Do not collapse your view just to create false consensus. If you're right, defend it. If you're wrong, retract it honestly.
+Disagreement is useful. Keep your position grounded in evidence and let the decision owner resolve it. Do not collapse your view just to create false consensus. If you're right, defend it. If you're wrong, retract it honestly.
 
 ## When there is no assigned review