@openrig/cli 0.5.10 → 0.5.12

package/daemon/assets/plugins/openrig-core/skills/openrig-operating-model/SKILL.md

@@ -9,21 +9,19 @@ description: >-
 metadata:
   openrig:
     stage: draft
-    author: OpenRig product team (sole-context authorship)
+    author: OpenRig product team
 ---
 
 # The OpenRig Operating Model
 
 **Canonical term: the Operating Model.** How an OpenRig topology organizes every
 kind of context so that any agent — cold, fresh, or five generations in — can
-find what it needs and knows where to write what it learns. Everything below
-runs on **markdown files, scripts, and conventions only**; the `rig` verbs that
-formalize pieces of it are conveniences, never dependencies.
+find what it needs and knows where to write what it learns. Authored context stays in addressed Markdown and manifests. Supported writers
+record semantic judgments; their read models remain rebuildable from those artifacts.
 
-**Boundary (2026-08-11):** this skill owns the STRUCTURE (trees, chains, trace,
-write protocol). The SUPPLY layer — how canon content flows into the chains:
-addresses, maps, renders, EMM maturity, census — is `openrig-corpus-canon`,
-the deliberate drain mechanism the dual-home interim anticipated.
+This skill owns the structure: trees, chains, tracing, and placement of authored
+knowledge. Resolve installed context through its current library addresses and
+the project's selected loadout; a private corpus is not a required public dependency.
 
 Companion implementation assets in this skill's folder:
 - `templates/` and `scripts/` — starters and working tools, described in §8.
@@ -43,7 +41,7 @@ An **instance** is one OpenRig daemon and the rigs it manages; a **fleet** is al
 a daemon runs is a deployment fact, not an altitude — say the instance's name when you mean a
 particular one.
 
-**The one-parent law (design-ruled 2026-08-10):** the trace follows the
+**The one-parent law:** the trace follows the
 directory path and NOTHING else — no pointer fields, no link-following, no
 branching, ever. The trace is the instrument confused agents reach for, so it
 must be simpler than anything it corrects: path-only ascent fails only in
@@ -92,28 +90,45 @@ its body. Alongside it sit three files with different jobs and different writers
 | `SPEC.md` | the node — `intent:` composes, body specifies | the node's owner |
 | `NOTES.md` | **LIVED** — what actually happened doing it, in the doer's own words | whoever is doing it |
 | `PROOF.md` | evidence the thing does what was intended | the prover |
-| `PROGRESS.md` | authored acceptance checklist — each checkbox is a stored mark; roll-ups above those marks are derived | the scope's owner and provers |
+| `PROGRESS.md` | authored narrative and historical checklist marks; current proof readiness is derived from attributed judgments | the scope's owner and provers |
+| `proof/judgments/` | retained item judgment receipts written by `rig proof judge` | judges selected by the owning proof policy |
 
 **A scaffold may create `NOTES.md` and its starter instructions; its lived entries are never
 generated or projected.** It is the work tree's lived file, the way `LEARNED.md` is the topology
 tree's — the field-notes rung, where raw observation goes before anything has earned a place in the
 node itself. Keeping lived files out of the render path is what makes them safe to write freely in.
 
-**Legacy name:** the adopted spelling is `MISSION_NOTES.md` (35 at mission root). It stays
-resolvable, but the chain name is `NOTES.md` — `MISSION_` is altitude-specific and a chain uses one
-name at every altitude.
+**Legacy name:** older workspaces may use `MISSION_NOTES.md`. Keep legacy
+content addressable; use `NOTES.md` for the chain because its name works at every altitude.
 
 | Level | `SPEC.md` — frontmatter `intent:` (why) + body (what must be built) | progress | kept true by |
 |---|---|---|---|
 | project | `intent:` only — stable, changes at real pivots | derived roll-up | the project's PM |
-| mission | `intent:` only — a mission ORGANISES slices; it specifies nothing | authored checklist marks; roll-up derived | the mission's PM |
-| slice | `intent:` **and** a body — the only altitude that specifies | authored checklist marks; roll-up derived | the slice's owner |
-| proof item | *(inherits)* | **the checkbox — the stored acceptance mark** | the prover |
-
-**PROGRESS reconciliation (2026-08-26):** Checkbox items stored in a mission or slice
-`PROGRESS.md` are authored acceptance marks. In-process task tracking stays in the agent's own todo
-tool. Everything that rolls those marks up above the managed checklist is derived at render time,
-so authored checklists and the never-author-a-derived-roll-up rule are the same model.
+| mission | `intent:` and proportional mission-level specification; organizes slices | derived child readiness; distinct outcome judgment | the mission's PM |
+| slice | `intent:` and the concrete slice specification | derived proof readiness | the slice's owner |
+| proof item | authored promise in the proof contract | attributed evidence-backed judgment on that revision | the selected judge |
+
+**Current acceptance:** Scope relationships and policy are authored in manifests; an item
+judgment is recorded once against its promise, evidence and policy revision. Slice, mission
+and project readiness derive upward. A distinct outcome or publication decision remains its
+own authority. Queue ownership and generic `done` are custody facts, not proof acceptance.
+Historical checkbox marks stay readable without acquiring current item authority.
+
+Use `rig proof --help` for the supported write/read path. The project owner selects
+`proofPolicy.judges` in `project.yaml`, `mission.yaml` or `slice.yaml` (nearest wins),
+using exact actor addresses. There is no implicit fixed-role review conveyor.
+`rig proof judge mission/slices/slice#1 --verdict accept --reason 'Observed the outcome' --evidence proof/result.md`
+resolves the item identity, revision, evidence digests and retry identity. Evidence may be
+an existing legacy artifact or a non-code outcome. A patch-equivalent subject also names
+its actual comparison/adoption receipt with `--comparison`; the agent owns that judgment.
+`rig proof show` returns the current basis and retained receipt; it does not publish anything.
+
+Correct with `reject`, or `withdraw` when prior acceptance no longer stands. History stays
+in the addressed proof home. A repeated request returns its original receipt and current
+readiness; `--replace` deliberately reaffirms an old identical judgment after a correction.
+Changed promises, policy or evidence require a current judgment. Explicit optional
+`<!-- proof-item: stable-id -->` markers preserve identity across wording edits; the
+product otherwise derives identity from the full promise and reports ambiguity.
 
 **Intent composes; the body does not.** The trace reads the `intent:` FIELD at every altitude, so
 four levels unfurl as four sentences rather than four documents. The body is read only when you
@@ -127,20 +142,11 @@ real information, never silently skipped.
 **Legacy `README.md` nodes stay valid indefinitely** — the resolver prefers `SPEC.md` and falls
 back, so nothing is forced to migrate and dormant missions need no attention.
 
-**PROGRESS stays separate.** Its checklist items are authored stored marks; everything above those
-marks renders from them. Folding a derived roll-up into an authored file is how a stored derivation
-becomes a confident lie.
-
-Two directions on the same trees: intent/values/practice **compose downward**
-(you trace UP to read them); progress **aggregates upward** (never hand-written
-above the stored marks). **And PROGRESS above the managed checklist is a RENDER, not a
-file** (design-ruled 2026-08-10): the checkbox is the stored acceptance mark;
-`scripts/compose.py progress` derives the roll-up tree at render time. The
-old PROGRESS.md files that embedded a hand-rendered tree were the right idea
-in the wrong home — a stored derivation drifts into a confident lie (the same
-law that retired `serves:`). Existing legacy PROGRESS.md files with embedded
-trees stay per rule zero and are read as testimony; nobody authors a progress
-tree by hand again.
+**PROGRESS stays separate.** Narrative and legacy marks are retained testimony. For a
+project with selected proof policy, current readiness comes from `rig proof show` and the
+shared existing views, not hand-maintained parent checkboxes or copied status prose.
+`scripts/compose.py progress` remains a legacy checklist renderer; it does not certify
+attributed acceptance. Intent composes downward; proof readiness aggregates upward.
 
 **The axis behind the columns:** every context kind has a *template* half
 (what ships — SOP, the default culture) and a *learned* half (what living
@@ -152,16 +158,13 @@ constitution.
 
 ## 3. Why this exists (the failure it fixes)
 
-*How this seat does its job, learned over time* had no durable home. It lived
-in one runtime's private memory (invisible to the other runtime, the operator,
-and every successor), in handover documents (where day-to-day duties drown
-under urgent state), and in skills nobody opened at the right moment. Measured
-result: several consecutive generations of critical seats each started with a
-fraction of their predecessor's ability, without knowing it. The structural fix
-is the pair: `openrig-core`'s operating-model skill (the job, by type — shared,
-versioned, shipped) + `LEARNED.md` on the chain (the job, as lived — per-instance,
-occupant-written) — **read at every boot before any handover document**, written
-by every generation. A bad handover now costs recent state, not the job itself.
+Seat knowledge needs a durable home that successors and other runtimes can read.
+A private runtime memory or an urgent handover packet alone can omit standing
+duties and the reasons behind a practice. Keep general operating craft in the
+shared skill and position-specific knowledge in the seat's `LEARNED.md` chain.
+At a handover, read the current chain alongside the packet and record any missing
+job context before claiming readiness. Each occupant maintains what the seat has
+learned; the handover packet carries the current transition.
 
 ## 4. LEARNED.md — the living file (all altitudes; seat shown)
 
@@ -187,15 +190,14 @@ Sections, in order — see `templates/LEARNED.md`:
 **Size: soft guidance, not a rule.** Keep it as small as honestly covers the
 job — attention is the budget, and every reader pays it. Some seats genuinely
 need more; write what the job needs. The failure mode to watch for is the
-rulebook that only ever grows — hundreds of accumulated edicts nobody can hold
-(the Deuteronomy pattern, which this fleet has lived through once at population
-scale). The antidote is the distillation habit in §8 above, not a line count.
+rulebook that only ever grows. Distill lessons into practices with reasons at
+deposit boundaries (before clear or handover); use that habit, not a line count.
 
 ## 5. The trace — deliberate reorientation
 
 A trace is walking your chains **with your own file reads** and writing down
 where you stand: what am I doing (queue/NOTES) → under what contract (SPEC) →
-toward what intent (INTENT chain, leaf to root) → by what practice (LEARNED +
+toward what intent (`SPEC.md` intent field, leaf to root) → by what practice (LEARNED +
 SOP) → within what values (CULTURE). A few written lines at the end.
 `scripts/compose.py up` assembles any chain for you.
 
@@ -215,7 +217,7 @@ picture of where you stand may be stale* — after a large stretch of work, at a
 boundary (boot, handover, new mission, confusion), or when someone asks you to
 reorient. Why not simply "every N hours": identical scheduled prompts fade
 from an agent's attention with repetition, and idle seats accumulate ritual
-traces that crowd out real context — both failures observed here, at cost.
+traces that crowd out real context.
 Where a schedule fits your context anyway, use one — but prefer gating the
 *action* on evidence of change: `scripts/trace-due.sh` decides "has enough
 happened since my last trace?" deterministically and stays silent when the
@@ -245,17 +247,14 @@ exist and both are chains in that sense:
 delivery regardless of content. That is why `rig walk` elapses `--pace` between pieces, and why a
 composed render is meant to be read as a sequence rather than skimmed as a wall.
 
-**NAMING, RULED 2026-08-14 — the two ends have two words and neither is shared.**
+Use distinct names for the two directions:
 
-- **TRACE** — the pull ascent. `compose.py up` renders a node's chain to the root. This is what
-  `refocus` means by *run a trace*, and it is what the render itself now prints.
-- **`rig walk`** — the push verb, paced delivery into a seat's pane. It ships in the CLI, so treat
-  renaming it as a product change.
+- **TRACE** — the pull ascent. `compose.py up` renders a node's chain to the root.
+- **`rig walk`** — the push verb for paced delivery into a seat's pane.
 
-**"Walk" no longer means the ascent.** It drifted in through the render's own header and started
-competing with `trace`, which was already the word in `refocus` and in this file. **The fix is the
-name, not a sentence explaining the name** — a disambiguation you have to maintain is a defect you
-decided to live with.
+Use `refocusing` for the current trace workflow. A delivery receipt and an
+agent's read-depth report answer different questions; pacing alone does not
+establish understanding.
 
 ## 6. Writing — two principles
 
@@ -338,8 +337,11 @@ further setup. **A script that only works for its author is not shippable, howev
 tree (`LEARNED.md`). What is being built is the *work* tree (`SPEC.md`). One rig owns both; they
 still do not mix.
 
-**Project and mission bodies are short or absent** — `intent:` is the whole job at those altitudes.
-The slice is the only altitude that specifies.
+**Keep specification depth proportional.** A project carries stable intent; a
+mission carries its intent and mission-level specification in the same authored
+`SPEC.md`. Slices provide their concrete implementation scope. Follow the selected
+`mission-slice-sop` and any explicit mode overlay; mission specification is not a
+requirement to repeat every slice detail.
 
 ### The other axis: AUDIENCE is not MATURITY
 
@@ -363,8 +365,7 @@ practice must accrue** (*never broadcast to a large rig* took an incident).
 
 **LEARNED.md is not a staged item — it is the bed everything lies in.** Its gradient is
 positional: the dated append-log at the bottom is raw observation, the concise sections at the top
-are what survived. What is missing is a **trigger**, not structure — "periodically distill" has
-meant *never*. The answer: distil at deposit boundaries (pre-clear, pre-handover) where a write is
+are what survived. Attach distillation to a **trigger**: distil at deposit boundaries (pre-clear, pre-handover) where a write is
 already required and the author still remembers why each line exists; refocus merely *notices*
 when the log has outgrown the distilled part.
 
@@ -384,10 +385,9 @@ and how you discover which seats cannot yet describe their own job.
   at the next render, silently.
 - "Improving" the trace with pointer-following, serves-resolution, or any
   branching — the trace's entire value is that path-only ascent cannot fail
-  subtly; a smarter trace is a worse trace (design-ruled 2026-08-10).
+  subtly; keep the trace path-only.
 - Summarizing this model for another agent instead of pointing them here —
-  secondhand operating models are how operating models die; this skill was
-  authored precisely because a chain of summaries destroyed the last one.
+  a summary becomes another copy that can drift from its source.
 - Scripts in `scripts/` are macOS-flavored in places (`stat -f`); verify
   platform compatibility before trusting them on another OS.
 

package/daemon/assets/plugins/openrig-core/skills/openrig-operating-model/scripts/trunk-diff.sh

@@ -6,7 +6,7 @@
 set -euo pipefail
 ROOT="${1:?usage: trunk-diff.sh <root-dir> <state-file> [--name FILE ...]}"
 STATE="${2:?state-file required}"; shift 2
-NAMES=("$@"); [[ ${#NAMES[@]} -eq 0 ]] && NAMES=(--name CULTURE.md --name PLAYBOOK.md --name LEARNED.md --name INTENT.md)
+NAMES=("$@"); [[ ${#NAMES[@]} -eq 0 ]] && NAMES=(--name CULTURE.md --name SOP.md --name LEARNED.md --name SPEC.md --name PLAYBOOK.md --name INTENT.md)
 HERE="$(cd "$(dirname "$0")" && pwd)"
 NEW="$(mktemp)"
 python3 "$HERE/compose.py" down "$ROOT" "${NAMES[@]}" | grep -v '^<!-- GENERATED' > "$NEW"

package/daemon/assets/plugins/openrig-core/skills/openrig-operating-model/templates/LEARNED.md

@@ -1,14 +1,15 @@
 ---
 seat: <pod>-<member>@<rig>            # or rig/pod/fleet coords at higher altitudes
-template: <path-or-name of PLAYBOOK.md this diffs against> @ <version/sha>
+template: <path-or-name of SOP.md this refines> @ <version/sha>
 owners: self (sole direct writer) · <orchestrator/PM> (by proposal) · hierarchy (boundaries only, marked)
 updated: <YYYY-MM-DD from the clock command — never mental math>
 status: UNSEEDED  # the first real occupant replaces this line with: seeded-by-self <date>
 ---
 # LEARNED — <instance coords>
-<!-- HARD CAP ~150 lines. At the cap: distill LESSONS into HOW I WORK, or expire them. -->
+<!-- Size is soft guidance: keep the file as small as honestly covers the job.
+     Before handover or clear, distill LESSONS into HOW I WORK and retain needed context. -->
 
-## MY JOB HERE (≤10 lines)
+## MY JOB HERE
 <!-- This instance's actual function, in operational terms. If you cannot write
      this section yourself, say so to your orchestrator — that discovery is the
      audit working, not a failure. -->
@@ -35,6 +36,7 @@ status: UNSEEDED  # the first real occupant replaces this line with: seeded-by-s
 <!-- situation → read this. Attach pointers to MOMENTS, not to boot. -->
 - 
 
-## LESSONS (append-only, dated, capped)
-<!-- newest first. At cap: distill upward or expire. -->
+## LESSONS (dated, newest first)
+<!-- Distill into HOW I WORK at deposit boundaries; preserve necessary reasons
+     and archive superseded material. Attention is the budget, not a hard line cap. -->
 - 

package/daemon/assets/plugins/openrig-core/skills/openrig-operating-model/templates/PLAYBOOK.md

@@ -1,5 +1,4 @@
-# MOVED — this file is now SOP.md
+# Legacy pointer — use SOP.md
 
-Renamed PLAYBOOK.md -> SOP.md per owner naming ruling 2026-08-11 (names are
-prompts; SOP is the stronger consult-and-follow trigger and the factory-native
-term). Read ./SOP.md. One-transition-period pointer; do not edit here.
+The procedure template is [SOP.md](SOP.md). Use it for new chain files; this
+PLAYBOOK.md pointer preserves the old address. Edit the current template.

package/daemon/assets/plugins/openrig-core/skills/openrig-operating-model/templates/SPEC.md

@@ -15,9 +15,10 @@ status: UNSEEDED
      checkbox items are stored marks; every roll-up above them is derived, never hand-authored.
      Legacy README.md nodes stay valid indefinitely; nothing is forced to migrate.
 
-     PROJECT and MISSION nodes: the frontmatter `intent:` IS the whole job. A mission
-     ORGANISES slices and carries the context they need; it specifies nothing. Keep the
-     body short or delete it — everything below this line is for SLICES.
+     PROJECT nodes carry stable intent. MISSION nodes carry intent and proportional
+     mission-level specification in this same authored file, organizing slices and
+     giving them shared scope. SLICE nodes carry concrete implementation scope.
+     Keep body depth proportional; do not repeat all slice details at mission level.
 
      WHATEVER BODY YOU DO WRITE, two tests per sentence:
        PORTABILITY — if it would read correctly on a stranger's machine it is knowledge
@@ -27,10 +28,9 @@ status: UNSEEDED
      And check the tree: traps and how-we-work live in LEARNED.md on the topology tree,
      not here. This file is what is being BUILT.
 
-     SLICE nodes are the ONLY altitude that specifies. Keep the sections you need and
-     delete the rest; this is a starting shape, not a contract. Under the FACTORY operating
-     model this node also carries mini-requirements and a proof contract — see that mode's
-     plugin. Under the LAB it does not. -->
+     Follow the selected mission-slice-sop and any explicit operating-mode overlay.
+     Use the required sections for that work; the generic body below is a starting
+     shape, not an additional gate or a requirement for every mission. -->
 
 # <name>
 

package/daemon/assets/plugins/openrig-core/skills/openrig-user/SKILL.md

@@ -45,10 +45,10 @@ the receipt and move on.
 Example:
 
 ```bash
-rig send guard@your-rig "Heads up — filing per-commit handoff on the rig-up paper-cut fix at tip 6b8673b6." --verify
+rig send dev-reviewer@example-project "The import report is ready; the durable handoff names its evidence." --verify
 ```
 
-### `rig queue create --source <X> --destination <Y> --tags <...> --body "<...>"` — durable work item
+### `rig queue create --destination <Y> --tags <...> --body-file <path>` — durable work item
 
 Use for any substantive work that must not fall through chat — slice handoffs,
 guard verdicts, QA results, full-tip reviews, multi-item batches. Survives agent
@@ -65,10 +65,9 @@ Example:
 
 ```bash
 rig queue create \
-  --source driver-2@your-rig \
-  --destination redo-guard-2@your-rig \
-  --tags "mission:release,slice:rig-up-paper-cut-fix,gate:guard,handoff:per-commit,checkpoint:bug-1-bonus" \
-  --body-file /tmp/per-commit-body.txt
+  --destination dev-reviewer@example-project \
+  --tags "mission:data-import,slice:import-report" \
+  --body-file /tmp/import-report-handoff.md
 ```
 
 ### `rig queue handoff <qitem-id> --to <next> ...` — hot-potato handoff
@@ -76,22 +75,26 @@ rig queue create \
 Use when you have completed your turn on a qitem and the work moves to the next
 owner. **This is forward momentum.** The ball passes to the destination seat;
 chain-of-record (the prior qitem id) is preserved so the verdict trail is intact;
-tags carry the phase boundary forward (e.g. `gate:guard` → `gate:qa`).
+tags carry the selected work context forward. Gate tags describe checks actually
+selected for that work; they do not require a fixed sequence of roles.
 
 Example:
 
 ```bash
-rig queue handoff qitem-20260601012431-d78aa805 \
-  --to velocity-qa@your-rig \
-  --tags "mission:release,slice:rig-up-paper-cut-fix,gate:qa,handoff:adversarial-dogfood"
+rig queue handoff <qitem-id> \
+  --to dev-reviewer@example-project \
+  --tags "mission:data-import,slice:import-report" \
+  --body-file /tmp/import-report-handoff.md
 ```
 
 ### §1b doctrine — turn ends by passing the ball
 
 **A turn ends by passing the ball, never by going idle holding the slice waiting
-on a confirmation the process does not include.** If the work was authorized, the
-per-commit guard + adversarial QA + orch heavy-verify are the guardrails — not an
-operator pre-commit gate. Do the authorized work and pass the ball.
+on a confirmation the selected process does not include.** Follow the current
+`mission-slice-sop`: proportional owner checks are the default; independent review
+runs when selected, at the authored work boundary. Role names do not add per-commit
+guard, QA, or orchestration gates. Do the authorized work, run its selected checks,
+and return the outcome through durable custody.
 
 Valid pauses are only:
 
@@ -134,13 +137,9 @@ Default posture:
 
 - Treat daemon `rig queue`, `rig stream`, `rig project`, `rig view`, `rig watchdog`, and
   `rig workflow` as the product coordination surfaces when the active daemon is v0.2.0 or newer.
-- **CANONICAL SURFACE NOTE (2026-05-11)**: `rig queue` (daemon-backed SQLite) became
-  the canonical queue-routing surface when the 2026-05-11 host-CLI fix landed. The
-  coordination model is now load-bearing at the top of this skill — see
-  "Coordination primitives — when to use which" above for the send / queue /
-  queue-handoff usage model and the §1b doctrine. Auxiliary queue verbs:
-  `rig queue update / show / list` complement `rig queue create / handoff`
-  for in-flight inspection and state mutation.
+- Use daemon-backed `rig queue` for durable routing. `update / show / list`
+  complement `create / handoff` for inspection and state changes; records in an
+  unrelated store are not evidence that this daemon owns the work.
 - If a daemon-backed coordination command fails, debug the command/runtime/schema edge directly;
   do not assume the right workaround is to drop back to a config-layer primitive.
 - Do not perform daemon stop/start, production DB copy/mutation, release, publish, or other
@@ -287,7 +286,7 @@ OpenRig sets only a **minimal usability floor** on your harness permissions and
 
 - **POLICY MODE** — pick a built-in policy and have it applied:
   - **Locked** — deny-by-default whitelist; untrusted rigs/work.
-  - **Standard** ⭐ (recommended) — the normal software-factory posture; dev incl. push + PR, destructive actions ask.
+  - **Standard** ⭐ (recommended) — routine development including push is allowed; PR creation, publication, merge/release, force-push and destructive actions ask.
   - **Open** — allow-by-default; everything except explicitly-destructive, which ask.
 
   The built-in definitions ship as read-only policy spec files (Locked / Standard / Open); applying your pick is the job of the **`applying-a-permission-policy`** skill — it translates the chosen spec into your live harness config (Claude `settings.json` / Codex `config.toml`), interactively, showing the diff before it writes.
@@ -321,25 +320,20 @@ rig plugin validate <path>
 There is no `rig plugin install` verb in v0.3.1. Plugin installation remains
 explicit operator copy/symlink to `$OPENRIG_HOME/plugins/<plugin-id>/`.
 
-Claude auto-compaction policy is opt-in default-off. The v0.3.1 package and
-this host's active daemon ship `policies.claude_compaction.*` ConfigStore keys,
-but no behavior changes unless the operator enables the policy.
-
-Known v0.3.0/v0.3.1 caveats:
-- `rig down` now accepts a rig name or id (symmetric with `rig up`): the earlier
-  name-to-404 caveat (the D1 path) is resolved in v0.3.3. An ambiguous name
-  matching more than one active rig is refused with the matching ids; re-run
-  with `rig down <id>`.
-- `rig queue` / `rig view` JSON and limit compatibility drift is an open
-  follow-up from host-adoption proof; treat it as a compatibility caveat, not a
-  daemon-health failure.
-- Queue/view JSON/limit drift is now refined as a wrapper-layer routing issue,
-  not a daemon-layer issue; use human-readable output for affected wrapper
-  commands until v0.3.2.
-- First v0.3.1 daemon start hit a plugin-vendor fallback health-probe timeout;
-  controlled retry succeeded. Manual retry is the current workaround.
-- Topology mobile drawer restoration and plugin source-label taxonomy are
-  v0.3.2 carry-forwards.
+The v0.3.1 package introduced opt-in Claude auto-compaction policy through
+`policies.claude_compaction.*` ConfigStore keys. A package version alone says
+nothing about a running daemon's configuration; inspect the selected instance
+before relying on a policy or its default.
+
+Compatibility checks:
+- `rig down` accepts a rig name or id. An ambiguous name matching more than one
+  active rig is refused with matching ids; use the intended id.
+- For queue/view JSON or limit differences, compare the installed command's help,
+  the running daemon version and the actual response. A wrapper mismatch is not
+  by itself a daemon-health failure, and historical workarounds are not current
+  behavior guarantees.
+- After a startup timeout, inspect status and logs before retrying; a timeout
+  does not establish whether the underlying operation completed.
 
 ## Recovery and Resilience (v0.3.4+)
 
@@ -479,14 +473,14 @@ rig ps --active             # opt-in active-state filter (does NOT change the al
 - **All-states stays default** (different from `rig queue list` which defaults to active-only) — for `ps`, non-running states ARE often the actionable signal.
 - **Resume-token security**: `--full` JSON emits `resumeTokenPresent` (boolean) — the actual `resumeToken` value also remains in `--full` for downstream consumers that legitimately need it, but the compact default never carries it (an orch glance never accidentally leaks token material).
 
-**⚠ SCOPE-AWARENESS — the one that bites:** `rig ps --nodes` (and `--nodes --json`) show ONLY your current rig's seats, by design — the narrow default protects your context window. **Narrow output is not the whole world.** Never conclude "my rig is the only rig on the host" from a `--nodes` read — run bare `rig ps` FIRST (cheap; it lists every rig), then `rig ps --nodes --rig <name>` for the one you need. (`-A` = the expensive whole-host node read; use sparingly. The ~77k-token status-glance incident is closed by compact + scope.)
+**⚠ SCOPE-AWARENESS — the one that bites:** `rig ps --nodes` (and `--nodes --json`) show ONLY your current rig's seats, by design — the narrow default protects your context window. **Narrow output is not the whole world.** Never conclude "my rig is the only rig on the host" from a `--nodes` read — run bare `rig ps` FIRST (cheap; it lists every rig), then `rig ps --nodes --rig <name>` for the one you need. (`-A` widens to the whole-host node view; choose it when that breadth is needed.)
 
 ### `rig whoami` — compact-by-default + `--full` (`--verbose` alias)
 
 ```bash
 rig whoami                  # compact: identity + peers names + edges + transcript path
-rig whoami --json           # compact JSON (~192 tokens)
-rig whoami --full           # complete payload (~909 tokens; v0.3.4 default shape)
+rig whoami --json           # compact JSON
+rig whoami --full           # complete payload (v0.3.4 default shape)
 rig whoami --verbose        # alias of --full
 ```
 
@@ -504,10 +498,11 @@ rig queue list --full -o json        # full JSON
 rig queue list --mine                # just the caller's items
 rig queue list --destination <s>     # destined to <s>
 rig queue list --source <s>          # sourced by <s>
-rig queue show <qitemId>             # full single item (kubectl describe)
+rig queue show <qitemId>             # bounded single-item body preview
+rig queue show <qitemId> --full      # complete body and chain fields
 ```
 
-Four orthogonal axes (scope × history × field-breadth × encoding), all composable. **STOP using bare `rig queue list` as the cross-rig firehose.** Default is now active + compact + current-rig. The cross-rig + history + full-body firehose (the ~64,000-token payload spike) is opt-in via `-A -a --full`.
+Four orthogonal axes (scope × history × field-breadth × encoding), all composable. **STOP using bare `rig queue list` as the cross-rig firehose.** Default is now active + compact + current-rig. Cross-rig history with full bodies is opt-in via `-A -a --full`; request only the breadth and fields needed for the question.
 
 ### `rig restore-check` — summary + not-ready-only default + `--full`
 
@@ -518,7 +513,7 @@ rig restore-check --rig <name>  # narrow
 rig restore-check --as <session>  # narrow to one seat
 ```
 
-Closes the largest measured bomb (~79,000 → low thousands). Summary correctly identifies EVERY not-ready seat (no false-ready omission); detail is dropped only for ready seats.
+The summary retains not-ready seats and their reasons; `--full` adds ready-seat detail when needed. Scope the query before expanding its payload.
 
 ### `rig context` — context-window usage viewer (0.4.x; REMOVED in 0.5.0)
 
@@ -531,13 +526,13 @@ rig context --threshold 80 # filter to seats at/above 80%
 
 Lower leverage than the others; keeps the read-command surface compact-by-default after the 0.4.0 upgrade. **⚠ 0.5.0: this usage viewer is removed entirely and the `rig context` name is reassigned to the context library (store + compose) — see "Context packs and paced delivery (0.5.0)" below. On a 0.5.0 host, bare `rig context` is the library, not this viewer.**
 
-### Why this matters
+### Keep routine reads bounded
 
-This release closes the host-version-aged token-burn class: on this host the read-commands accumulated to ~225,000 tokens of context-window cost over a typical orchestrator session, almost all of it firehose-when-a-glance-was-wanted. Compact defaults restore the lean-monitoring doctrine: a narrow status check must be cheap. The full payloads remain one flag away when actually needed.
-
-### Token-efficiency-boot-guardrail pack (interim) — CLI-prohibitions RETIRE at host-upgrade
-
-The interim `token-efficiency-boot-guardrail` pack (the CLI-command prohibitions on `rig queue list` unfiltered, `rig ps --nodes --json` unfiltered, `rig restore-check`, `rig context`, `rig whoami --json`) is a host-version workaround for the bloated defaults this release closes. **The CLI-command-prohibitions half retires when 0.4.0 lands on the host.** The pack's bounded-local-search rule + scope / over-flag discipline GRADUATE to a standing convention (`conventions/bounded-local-search-and-flag-scope`) and continue to apply host-independently.
+Choose scope, active/history breadth and fields before expanding a result. A
+status question usually needs identifiers, owner, state and reason; open the full
+body or artifact when it is relevant. Preserve full evidence on disk instead of
+repeatedly loading unchanged output. Compact defaults reduce reading cost; they
+do not remove the full-detail path or prove that nothing exists outside the scope.
 
 ### `rig scope mission|slice progress` — deterministic progress updates
 
@@ -585,14 +580,10 @@ v0.3.4 shipped `clear-attention` gating on `session.startupStatus` only. v0.4.0
 ### Native Codex session id capture
 
 Codex seats can now record the real native session id from the Codex
-`SessionStart` hook instead of relying on scrape-shaped identity. The proof
-lane for v0.4.0 matched the same id across the hook payload, rollout log, and
-SQLite. Treat hook-sourced ids as stronger resume/identity evidence than
-terminal scraping when present.
-
-Managed-seat hook trust is a 0.4.1 carry: the v0.4.0 surface proves native
-capture and hook-trust constraints, but do not assume every managed Codex seat
-has already migrated from scrape-backed to hook-sourced ids.
+`SessionStart` hook instead of relying on scrape-shaped identity. Corroborate the id across the current hook payload, provider history and
+managed record before relying on it. A release introducing native capture does
+not prove that every existing seat uses it; retain any unavailable or conflicting
+identity evidence explicitly.
 
 ### Codex resume preserves approval posture
 
@@ -696,7 +687,7 @@ rig ps --nodes --full       # complete per-node record (the firehose — opt-in)
 rig ps --nodes --json       # compact JSON node inventory (add --full for the full record)
 ```
 
-**v0.4.0 flipped these to compact-by-default — see the `rig ps` compact-defaults section above; STOP using bare `rig ps --nodes --json` as a fleet-wide firehose (the ~77k-token status-glance incident).** The compact `rig ps --nodes` node inventory (add `--full` only when you need the complete record, `-A` for cross-rig breadth) carries, per node:
+**v0.4.0 flipped these to compact-by-default — see the `rig ps` compact-defaults section above; STOP using bare `rig ps --nodes --json` as a fleet-wide firehose (scope and detail are separate choices).** The compact `rig ps --nodes` node inventory (add `--full` only when you need the complete record, `-A` for cross-rig breadth) carries, per node:
 - session name
 - runtime
 - session/startup status
@@ -764,14 +755,14 @@ rig send <session> "message" --host <id>
 rig send <session> "message" --json
 ```
 
-**The send-guard (v0.4.0) — the default is SAFE.** A default `rig send` is guarded: it will NOT submit into an interactive prompt / permission block on the target pane (the footgun that prematurely shipped 0.4.0). Flags:
+**The send-guard (v0.4.0) — the default is SAFE.** A default `rig send` is guarded: it will NOT submit into an interactive prompt / permission block on the target pane. Flags:
 - `--verify` — delivery evidence.
 - `--force` — **a back-compat no-op on the send DECISION**: it never bypasses the interactive-prompt/permission guard and never changes whether a message is delivered (a mid-task/busy pane already sends-with-advisory by default). *(It does NOT "bypass activity-risk checks" — that earlier teaching is retired.)* It is **not fully inert**, though — it is still parsed solely to be **rejected in combination with `--wait-for-idle`**: `rig send … --force --wait-for-idle <n>` prints `--wait-for-idle cannot be combined with --force`, exits 1, and sends nothing. So do not read "no-op" as "`--force --wait-for-idle` is harmless"; that pairing errors. *(Verified against current product main `d37a08ad`: the guard-bypass no-op is declared at `send.ts` and confirmed by runtime capture — a plain `--force` send delivers through the ordinary path; the `--wait-for-idle` rejection is enforced at `send.ts`, `routes/transport.ts`, and `session-transport.ts`, and confirmed by runtime capture — exit 1, nothing sent.)*
 - `--wait-for-idle <seconds>` — wait until the target is explicitly idle before sending. **Cannot be combined with `--force`** (that pairing is rejected: exit 1, nothing sent).
 - `--raw` — send exact text/keystrokes without the From/To messaging envelope (still guarded against interactive prompts).
 - `--dangerously-interact --reason "<why>"` — the ONLY override of the prompt/permission guard: deliberately drive an interactive prompt/permission block (implies `--raw`, requires `--reason`, audit-logged).
 - `--host <id>` — send on a remote host declared in `~/.openrig/hosts.yaml` (ssh hosts shell out; http hosts go CLI-direct to the remote daemon).
-- `--from <session>` — originating session for the envelope sender/actor (provenance; defaults to `$OPENRIG_SESSION_NAME`, and is plumbed through cross-host sends so the remote envelope names the origin, not the relay).
+- `--from <session>` — deprecated and ignored; it does not select the sender. Sender identity comes from the current seat and transport provenance; cross-host envelopes use the durable local origin, not the supplied flag or a relay identity.
 - `--context <ref>` **(0.5.0)** — attach a composed context pack/piece by ref (see "Context packs and paced delivery"). Small piece → `send --context`; a real pack → `rig walk`. The noun `rig context` composes the ref; the verb delivers it.
 
 > **Durable work goes to the QUEUE, not `send`.** `rig send` is an *ephemeral* message to a pane — it can be missed, and its delivery status is pane-render, not receipt. If you are **assigning work, or the message is important enough that losing it would be a real bummer**, use `rig queue` (below): it's durable, owned, tracked, and survives compaction and restart. Reach for `send` for a quick conversational nudge; reach for the **queue** for anything that must not get lost. Do not default to `send` for work — that's the most common mistake.
@@ -923,7 +914,7 @@ rig auth seats … --runtime codex         # seat -> profile registry (metadata
 
 **Compose context once, hand it to a seat cleanly.** A library primitive plus a set of delivery flags. The rule that keeps the grammar coherent — internalize this one: **the noun stores and composes; the verbs deliver.** `rig context` never sends anything; delivery is only ever `rig send` / `rig broadcast` / `rig walk` / `rig queue`.
 
-> Version note: this is the 0.5.0 surface, pinned to the team-locked spec — not yet on lagging hosts. In 0.4.x, bare `rig context` was a context-window usage viewer (above); in 0.5.0 that viewer is removed and the `rig context` name belongs to the library here.
+> Version note: this describes the library surface introduced in 0.5.0. Check the installed command and serving daemon before relying on it. In 0.4.x, bare `rig context` was a context-window usage viewer (above); in 0.5.0 that viewer is removed and the `rig context` name belongs to the library here.
 
 ### `rig context` — the store + compose library (never delivers)