@openrig/cli 0.5.9 → 0.5.11

package/daemon/context-packs/skills/mission-slice-sop/SKILL.md

@@ -17,11 +17,25 @@ Use this skill to actually **do** mission/slice work: track on the canonical fil
 
 **Full convention SSOT:** repo `docs/reference/sdlc-conventions.md`; installed `$OPENRIG_HOME/reference/sdlc-conventions.md`. This skill is the concise Part-A teaching surface and does not replace the full convention.
 
-## THIS IS THE LIGHT DEFAULT — read this before anything else
-
-**The default for any slice is the inner loop:** ground yourself → build → **test with your own eyes** → iterate → **ONE** full-breadth review at the end. That is the whole process. It is not a reduced form of a better process; it IS the process.
-
-**Part B is defined in the SSOT above and applies only when the human operator — or an orchestrator explicitly relaying that decision — assigns it to a named piece of work.** You may not select it yourself. If you believe something earns it, say so in one sentence and **continue on Part A** until told otherwise.
+## Resolve the work first
+
+Run `rig whoami --json`, then resolve `project.yaml -> mission.yaml -> active
+slice.yaml -> selected component or wave map -> addressed context`. The complete
+lookup and precedence rule is `docs/reference/product-journey-sdlc.md#resolve-the-selected-path`
+(installed: `$OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path`).
+Read the selected addresses and source needed for this task; skills available in
+your profile are capabilities, not a mandatory reading list. No composition means
+light Part A. Role names and idle seats add no gates. Explicit rigor and authored
+wave boundaries retain their named checks.
+
+The light inner loop is ground yourself → build → test with your own eyes →
+iterate → record and return the whole outcome. The builder may hold this check
+on a tiny change. Independent review runs only when selected, and once at an
+authored wave boundary rather than once per slice.
+
+Part B is defined in the conventions SSOT and runs only when explicitly assigned
+to named work. If you believe it is needed, state the reason to the owner and
+continue on the selected path until that choice changes.
 
 ## Proportionality — this SOP serves shipping; it is not the work itself
 

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.5.9"
+version: "0.5.11"
 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/SKILL.md

@@ -9,7 +9,7 @@ description: >-
 metadata:
   openrig:
     stage: draft
-    author: OpenRig product team (sole-context authorship)
+    author: OpenRig product team
 ---
 
 # The OpenRig Operating Model
@@ -20,10 +20,9 @@ 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.
 
-**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 +42,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
@@ -99,18 +98,17 @@ generated or projected.** It is the work tree's lived file, the way `LEARNED.md`
 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 |
+| mission | `intent:` and proportional mission-level specification; organizes slices | authored checklist marks; roll-up derived | the mission's PM |
+| slice | `intent:` and the concrete slice specification | 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 checklists:** 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.
@@ -134,13 +132,10 @@ 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.
+file**: the checkbox is the stored acceptance mark;
+`scripts/compose.py progress` derives the roll-up tree at render time. Keep legacy
+embedded roll-ups as historical records when needed, but derive the current view
+from its marks rather than maintaining another copy by hand.
 
 **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 +147,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 +179,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 +206,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 +236,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 +326,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 +354,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 +374,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/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.5.9"
+version: "0.5.11"
 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-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/context-packs/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/context-packs/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/context-packs/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/context-packs/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
@@ -717,6 +708,31 @@ rig env logs <rig>
 rig env down <rig>
 ```
 
+### Bounded agent self-scout
+
+Use the typed health projection before reading raw coordination history. The
+default query is the current seat; widen deliberately when the evidence points
+beyond it:
+
+```bash
+rig health --json
+rig health --rig <rig-id> --json
+rig health --instance --json
+rig health explain <finding-id> --json
+```
+
+Follow the returned stable finding ID and `suggestedInspection`. Use `explain`
+when the summary matters: it returns the same canonical record with its bounded
+window, freshness, literal detector rule, evidence references, and next
+inspection. Human output projects those same fields; it does not calculate a
+second score.
+
+An empty result means only that no records matched the bounded query. It is
+**not a healthy assertion**. Stale, unavailable, contradictory, and
+indeterminate evidence stays explicit. Never read raw SQLite for a self-scout,
+and never turn a finding into an acknowledgement, notification, queue row, or
+remediation automatically: `rig health` is strictly read-only.
+
 ## Transcript and Communication
 
 ### Transcript access
@@ -739,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.
@@ -898,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)