@openrig/cli 0.6.13 → 0.7.0

package/daemon/context-packs/skills/forming-an-openrig-mental-model/SKILL.md

@@ -242,8 +242,9 @@ If you're booting into a new seat in an OpenRig rig:
 4. **Check what skills you have** — list `.claude/skills/` or
    `.agents/skills/` in your cwd. Each skill has a frontmatter description
    that tells you when to reach for it.
-5. **Check your peers** — `rig capture <peer-session>` to see what they're
-   doing.
+5. **Check your peers** — `rig ps --nodes` and the queue first (who is up,
+   who holds what). Capture a peer (`rig capture <peer-session>`) only when
+   you actually need to see its screen.
 6. **Check the transcripts** if you're returning to an in-flight workstream
    — `rig transcript <session> --tail 100` for recent context.
 7. **Ask `rig ask <rig> "<question>"`** if you need cross-cutting evidence

package/daemon/context-packs/skills/forming-an-openrig-mental-model/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "forming-an-openrig-mental-model"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Use when the system around you does not make sense yet: you just booted into a seat and do not know how the pieces fit; someone said rig, pod, seat, fleet, topology, or slice and you are not certain what they mean here; you are unsure what kind of rig you are in or what it is for; you do not know how skills reach you or where context comes from; or you are about to act on a guess about how OpenRig works. Gives the runtime mental model fast, so you stop guessing."
 files:

package/daemon/context-packs/skills/loading-addressable-markdown/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "loading-addressable-markdown"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Use when a mission, slice, dashboard, or task references Markdown as path#h2-slug or path#h2-slug/h3-slug outside the OpenRig context-pack library."
 files:

package/daemon/context-packs/skills/mission-slice-sop/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "mission-slice-sop"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Use when starting, building, handing off, restoring, or closing a mission or slice under the default lightweight SDLC."
 files:

package/daemon/context-packs/skills/openrig-operating-model/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-operating-model"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Use when you do not know WHERE something belongs: you learned a lesson and are unsure which file takes it; you are about to create a new doc, folder, or convention; you are asking \"should this be a skill, a note, or a chain file?\"; you inherited a seat and want to know what SHOULD exist; or you are about to duplicate knowledge that already has a home. Also the trace-to-root: how a seat orients by reading one filename at each level from where it stands up to the fleet."
 files:

package/daemon/context-packs/skills/openrig-user/SKILL.md

@@ -90,6 +90,23 @@ rig queue handoff <qitem-id> \
   --body-file /tmp/import-report-handoff.md
 ```
 
+### After a queue write — use the response; read back only when it doesn't show what you need
+
+A queue write (`create`, `claim`, `update`, `handoff`, `handoff-and-complete`) answers with the row it wrote; a
+handoff answers with the closed row and its successor. When that answer shows what you need to establish, use it.
+Read back (`rig queue show <id> --full --json`, or `rig queue transitions <id>`) when it doesn't, for example:
+
+- the outcome was INDETERMINATE (a transport failure, or a 502 `remote_queue_write_failed`), or the write warned
+  `qitem_body_not_saved` (an existing row came back). Reconcile by the original ID before any retry;
+- the output was compact or truncated and the field you need isn't in it (the compact receipt shows `bodyBytes`, not
+  the body, and its footer names what it left out);
+- you need a transition note, a closure or blocker detail, or a successor that the output you saw omits;
+- you need evidence from downstream of the write: the recipient's wake (`create --verify` waits for it), or its
+  pickup or claim (a later read);
+- your team's custody rule asks for a separate read-back.
+
+Don't read back only to see again a field the response already showed you.
+
 ### §1b doctrine — turn ends by passing the ball
 
 **A turn ends by passing the ball, never by going idle holding the slice waiting
@@ -384,11 +401,19 @@ rig reconcile-session <session>
 rig reconcile-session <session> --rig <rigId> --node <logicalId>
 rig reconcile-session <session> --no-launch
 rig reconcile-session <session> --json
+rig reconcile-session <session> --repair-missing-pane --no-launch
 ```
 
-This is a no-launch, no-input adopt. `--rig`/`--node` disambiguate when the
-canonical session name does not uniquely resolve. `--no-launch` is accepted
-for explicitness (it is the only mode this command has).
+This is a no-launch, no-input adopt: it records a new claimed session row for
+the seat (any running row is superseded); it re-captures the resume token if
+it can, and conversation continuity stays unverified. `--rig`/`--node`
+disambiguate when the canonical session name does not uniquely resolve.
+`--no-launch` is accepted for explicitness.
+
+`--repair-missing-pane --no-launch` is different: for a running launched seat
+whose tmux pane was never recorded, it fills in the pane and keeps the
+session, resume token and generation. It never adopts. Both forms refuse
+while the seat's typing protection is on.
 
 ### Five-term restore status vocabulary
 
@@ -948,12 +973,7 @@ rig auth seats … --runtime codex         # seat -> profile registry (metadata
 
 ### Manage subscriptions across a fleet (when the person asks you to)
 
-**This applies only when both hold:**
-- the daemon's `provider.subscription_moves` setting is on. It's off by default; the person turns it on with
-  `rig config set provider.subscription_moves true`;
-- the person has asked you to manage their subscriptions.
-
-Otherwise, don't take this job on. Installing or upgrading OpenRig appoints no agent, launches no bundle and starts no
+**This applies only when the person has asked you to manage their subscriptions.** Otherwise, don't take this job on. Installing or upgrading OpenRig appoints no agent, launches no bundle and starts no
 rotation.
 
 When a person runs several Claude and Codex subscriptions across machines, the fleet studio bundle's one agent is meant
@@ -961,19 +981,19 @@ to keep work running, through the Fleet app. Until that bundle is available, the
 subscriptions can use this section. If that's you, you decide which subscription or home moves, and when. You decide
 from:
 - the usage and assignment readings, and their freshness;
-- the move record;
+- your earlier move reports;
 - the person's standing preferences.
 
 You say why, and you see the outcome through. OpenRig gives you the facts and the tools; it never decides for you,
 and there's no threshold to obey.
 
 **Who decides:**
-- **The person's operator agent** can ask you for a move, or look at the record. It doesn't make competing moves of
+- **The person's operator agent** can ask you for a move, or ask what you've moved. It doesn't make competing moves of
   its own.
 - **One agent manages subscriptions:** the one the person asked, or the fleet studio's agent once that bundle is
   available. There's no other fleet-manager role and no automatic manager. Use the commands below directly; no extra
   hand-off is needed.
-- **The Observatory is optional:** it can show your moves and readings, but you don't need it to rotate.
+- **The Observatory is optional:** it can show readings, but you don't need it to rotate.
 
 **The unit is a Codex home, with every seat on it.** Moving some seats on a shared home to a different account, and
 moving Claude seats, aren't supported moves yet: say so instead of improvising.
@@ -1005,8 +1025,7 @@ moving Claude seats, aren't supported moves yet: say so instead of improvising.
      --expect-account <the target's Account line>`. `--verify` only checks; it never restarts. Only that check
      reports `moved`, and anything less is unconfirmed.
    - **A slow reply isn't a failure:** never restart a seat a second time. Follow up at your next look.
-5. **Record every move, partial or unconfirmed included,** with `rig provider moves record --file <move.json>`
-   (`--help` shows the shape):
+5. **Report every move, partial or unconfirmed included,** to whoever asked for it (a queue item to their seat):
    - the home and machine;
    - from and to, as labels;
    - your reason;
@@ -1014,10 +1033,8 @@ moving Claude seats, aren't supported moves yet: say so instead of improvising.
    - each seat's result (`moved`, `unconfirmed` or `unknown`) with its evidence or what's missing;
    - the peers, for example "not restarted; account unverified".
 
-   A seat marked `moved` needs its `evidence`, and an `unconfirmed` or `unknown` one needs what's `missing`. A home
-   switched with every seat left as a peer is still a move to record, with `seats: []`. A follow-up that confirms an
-   earlier unconfirmed seat records a new move with `supersedes`. Asked "why did this
-   seat move?", answer from `rig provider moves --seat <seat>`. Never put credentials in a record.
+   A home switched with every seat left as a peer is still a move to report. A follow-up that confirms an earlier
+   unconfirmed seat says which report it follows. Never put credentials in a report.
 6. **When a sign-in is needed:**
    - Ask the person once, durably: a queue item to their seat, naming the machine and the subscription.
    - Move nothing onto that subscription until it's done.
@@ -1385,9 +1402,10 @@ or `rig add` (one member) when a seat needs an explicit model, a permission poli
 different agent spec or role profile, per-seat runtime or cwd, or startup files.
 
 Node-granular managed partial restore (v0.3.4+):
-- `rig launch <rig> <nodeRef>` relaunches a single seat by logical id or node id through orchestration. `<rig>` is the
-  rig's name or ID; a name shared by more than one active rig stops with the candidate IDs.
-- `rig launch <rig> --seats <a,b,c>` relaunches a comma-separated subset of seats.
+- `rig launch <rig> <nodeRef>` launches a single seat that isn't running, by logical id or node id, through orchestration.
+  `<rig>` is the rig's name or ID; a name shared by more than one active rig stops with the candidate IDs. A seat that's
+  already running is left as it is; for a fresh occupant there, use `rig seat launch <seat> --fresh --stop --reason <why>`.
+- `rig launch <rig> --seats <a,b,c>` launches a comma-separated subset of seats.
 - `--hold-reason <text>` records a reason for holding non-target seats during the partial launch.
 - This is a SUPPORTED managed path. The prior `pod_aware_launch_unsupported` dead-end is retired; pod-aware narrow launch now goes through this surface rather than ad-hoc rebuilds.
 

package/daemon/context-packs/skills/openrig-user/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-user"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Use when a specific `rig` command, subcommand, or flag is already known and you need its exact syntax, JSON shape, defaults, or error meaning. NOT for natural capability discovery, open-ended how-do-I questions, or choosing which OpenRig move applies."
 files:

package/daemon/context-packs/skills/orienting-to-an-inherited-seat/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "orienting-to-an-inherited-seat"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Use when you have just been primed into an EXISTING seat through a planned handover — a different agent retired and handed you the seat plus its earned context — and you need a world model of what just happened to you. Covers how a handover differs from compaction and from a fresh launch, the inherit-the-seat-not-the-identity rule, treating the handover packet as testimony you verify (and refusing stale ghost prompts, and verifying your OWN identity surfaces), why a seat is a COMPOUNDING LINEAGE"
 files:

package/daemon/context-packs/skills/pm/backlog-capture/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "backlog-capture"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Quickly capture product ideas, feature requests, or insights from meetings and conversations. Rapid documentation with smart categorization and deduplication."
 files:

package/daemon/context-packs/skills/pm/context-builder/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "context-builder"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Gather and distill context from meetings, competitors, regulatory sources, and internal discussions. Produces background.md for a feature and updates shared context docs when new knowledge is discovered."
 files:

package/daemon/context-packs/skills/pm/exec-summary/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "exec-summary"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Generate a 1-2 page executive summary for a feature — orients sales, leadership, and engineering from a single document."
 files:

package/daemon/context-packs/skills/pm/office-hours/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "office-hours"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "YC-style product validation using six forcing questions. Pressure-tests a feature idea before it becomes a requirement — ensuring real demand, a clear wedge, and evidence behind assumptions."
 files:

package/daemon/context-packs/skills/pm/plan-review/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "plan-review"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Multi-perspective review of a feature plan or requirements doc before development begins. Evaluates from strategy, design/UX, and engineering angles to catch gaps early."
 files:

package/daemon/context-packs/skills/pm/requirements-writer/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "requirements-writer"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Use when converting PM intake into a slice SPEC.md with observable acceptance outcomes, explicit scope, and advisory sibling build dependencies."
 files:

package/daemon/context-packs/skills/pm/ui-mockup/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "ui-mockup"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Create UI mockups at three fidelity levels — ASCII wireframes for quick iteration, standalone HTML mockups for delivery with requirements, and live prototypes for interaction testing."
 files:

package/daemon/context-packs/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/context-packs/skills/pods/development-team/manifest.yaml

@@ -1,10 +1,12 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "development-team"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Use when a development pod begins or hands off implementation, QA, or design work."
 files:
   - path: "SKILL.md"
     role: "instruction"
     summary: "Use when a development pod begins or hands off implementation, QA, or design work."
+  - path: "references/refactoring.md"
+    role: "reference"

package/daemon/context-packs/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/context-packs/skills/pods/orchestration-team/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "orchestration-team"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Use when coordinating assignments, selected review boundaries, or blocked work across a rig."
 files:

package/daemon/context-packs/skills/pods/oversight-team/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "oversight-team"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Use when you are a seat on the oversight pod (a standing monitor-mode rig that keeps OTHER rigs healthy), configuring or running the drift detectors, or choosing whether to intervene vs escalate. Covers the pull-not-poll posture, the v0 detectors (premature-park, process-drift, off-task, token-burn), the intervention ladder (orchestrator-ping -> refocus -> human escalation), and the cheap+deep model economics. NOT for orchestrating your OWN rig (orchestration-team) and NOT the intervention primi"
 files:

package/daemon/context-packs/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
 

package/daemon/context-packs/skills/pods/review-team/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "review-team"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Use when assigned a review or when an authored review boundary is reached."
 files:

package/daemon/context-packs/skills/process/agent-browser/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "agent-browser"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to \"open a website\", \"fill out a form\", \"click a button\", \"take a screenshot\", \"scrape data from a page\", \"test this web app\", \"login to a site\", \"automate browser actions\", or any task requiring programmatic web interaction."
 files:

package/daemon/context-packs/skills/process/context-engineering/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "context-engineering"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Use when designing, reviewing, or debugging how an agent's context window gets filled, pruned, or shared — choosing what loads at boot versus on demand, sizing an install or an always-loaded file, fixing an agent that drifts, repeats itself, or forgets constraints mid-task, planning compaction or summarization, deciding single-agent versus subagents, engineering handoffs between agents, or picking a tool loadout. NOT for rewording a prompt's tone, choosing which model to pin, or debugging busine"
 files:

package/daemon/context-packs/skills/process/dogfood/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "dogfood"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Systematically explore and test a web application to find bugs, UX issues, and other problems. Use when asked to \"dogfood\", \"QA\", \"exploratory test\", \"find issues\", \"bug hunt\", \"test this app/site/platform\", or review the quality of a web application. Produces a structured report with full reproduction evidence -- step-by-step screenshots, repro videos, and detailed repro steps for every issue -- so findings can be handed directly to the responsible teams."
 files:

package/daemon/context-packs/skills/process/frontend-design/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "frontend-design"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics."
 files:

package/daemon/context-packs/skills/process/systematic-debugging/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "systematic-debugging"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes"
 files:

package/daemon/context-packs/skills/process/test-driven-development/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "test-driven-development"
-version: "0.6.13"
+version: "0.7.0"
 taxonomy: "skills"
 purpose: "Use when implementing any feature or bugfix, before writing implementation code"
 files: