@openrig/cli 0.5.10 → 0.5.12

package/daemon/context-packs/onboarding-width/public-reference-material.md

@@ -9,20 +9,20 @@ You do not need to read any of it now. You need to know it is there.
 
 ## The command surface — `docs/as-built/` in the source repo
 
-Eight documents sit directly in `docs/as-built/` in the source repo, and
-twenty-four files across `docs/` carry the same `kind: as-built` marker. Two of them are entry
-points and were written to be entered from:
+Use the source repository's `docs/as-built/` index and documents marked
+`kind: as-built`. Start with the entry point that matches your question:
 
 - **`README.md` — "Map of Territory + Module Index."** Start here when you do not know which
   document you want.
 - **`codemap.md` — "Navigation Index / Map of Territory."** Start here when you are about to go
   into the code and do not know which module owns the thing.
-- **`cli-reference.md` — the full `rig` command surface, ~106 KB.** Every group, subcommand, flag,
+- **`cli-reference.md` — the `rig` command reference.** Every group, subcommand, flag,
   JSON shape. **This is the authority on how a command works**, and the capabilities piece
   (`public-what-you-can-do.md`) is only the map to it.
 
-**These are maintained, not archaeology.** `cli-reference.md` alone has forty-nine commits against
-it. Treat them as current.
+Check the document's verification marker against the source you are using. A
+maintained document can still lag a changed command; its history is not proof
+of current behavior.
 
 ### The field that tells you how much to trust one
 
@@ -42,11 +42,11 @@ binary wins** — and the disagreement is worth reporting, not just working arou
 
 ## The living answer — `--help`
 
-**The binary is always more current than anything written about it.** `rig <verb> --help` and
+**Ask the binary you will actually run.** `rig <verb> --help` and
 `rig <verb> <subcommand> --help` are authoritative for shape, flags and defaults. This costs
 seconds and it is the single cheapest habit on this list.
 
-**And use it as a search, not just a lookup.** `rig --help` lists eighty-one top-level verbs. If
+**And use it as a search, not just a lookup.** `rig --help` lists the installed top-level commands. If
 you are about to build something, read that list first — the most expensive failure here is
 building a parallel solution out of primitives that already compose into the answer.
 
@@ -61,16 +61,12 @@ does not know the external sources below exist invents instead of looking. An ag
 **answers from its training snapshot and states it as current** — and an invented answer and a
 known one look identical once you have stated one.
 
-- **`context7`** — official documentation for a library, framework, SDK, API, CLI tool or cloud
-  service. **The moment: you are about to answer a question about any of those from memory.**
-  Reach for it even when you are confident, because confidence is exactly what a stale training
-  snapshot feels like. `resolve-library-id` first, then `query-docs`; it returns versioned library
-  IDs with a source-reputation and benchmark score, so you can see how good the coverage is before
-  you trust it.
-- **`exa` web search** — the general web. Describe the ideal *page*, not keywords: *"blog post
-  comparing X and Y performance"* beats *"X vs Y"*. It has an agent mode that does multi-step
-  research when one query will not do. `WebSearch` / `WebFetch` ship in the harness and do the
-  simpler version of the same job.
+Use the tools actually available in your harness. If a documentation connector
+such as `context7` is installed, use its current lookup interface to find the
+relevant library and version. If a web-search or fetch tool such as `exa` is
+available, use it to locate current primary sources. These tool names are
+examples, not a promise that your installation includes them. State any access
+or version limitation that affects the answer.
 
 ### The trust rule, and it is not the one these tools invite
 
@@ -78,18 +74,17 @@ known one look identical once you have stated one.
 to FIND; go to the primary source to CONFIRM anything load-bearing — the registry, the API, the
 repository, the running binary's `--help`.
 
-**Measured here 2026-08-18, and it inverts the intuition.** Asked for the current published version
-of a package, web search returned one page saying `0.5.0` (stamped "updated" two weeks earlier) and
-another saying `0.4.0`. The registry itself said `latest: 0.5.1` — and a four-day-old line in an
-agent's own memory index had been right all along. **The live-looking source was the stale one.**
-Web caches lag by an unknown and unstated amount, and nothing on the page tells you how much.
+Search indexes and caches can lag the source they describe. For a published
+package version, query the package registry; for an API contract, inspect the
+versioned provider documentation or implementation. An “updated” timestamp on
+a secondary page does not establish which source revision it reflects.
 
 So these extend your reach; they do not outrank a primary source, and *newer-looking* is not
 *newer*.
 
 ## The one you read rather than consult
 
-**`openrig-operating-model`** — a skill, ~23 KB. Everything else on this page you visit with a
+**`openrig-operating-model`** — the skill for context placement and chain walking. Everything else on this page you visit with a
 question already in hand. **That one you read through once**, because it is the shape the rest
 hangs on: the two trees, how context is arranged by altitude, and how a cold agent finds what it
 needs. Reading it is what stops you inventing an arrangement that already exists.

package/daemon/context-packs/onboarding-width/public-what-you-can-do.md

@@ -11,7 +11,7 @@ not know exists.** So the point of what follows is not skill. It is recognition:
 lands, something rhymes, and you go check instead of building.
 
 Eighty-one-plus top-level verbs ship (capability canon refreshed through
-`capability-delta-v0.5.10`). Read this once for shape, and let it make you suspicious that a thing
+`capability-delta-v0.5.12`). Read this once for shape, and let it make you suspicious that a thing
 already exists. Model-divergence proclamations are live product (trust them; pins use canonical
 model IDs).
 
@@ -38,7 +38,10 @@ one command away. Your memory of the fleet is a claim about the past.
   and whether the thing you did an hour ago actually landed.
 - **`rig view list` / `rig view show <lens>`** — named lenses over coordination state: use
   `view show escalations` for owner attention, `view show pickup` for claimed-row state, and
-  `view show execution` for done/now/next. An `INDETERMINATE` cell stays unknown rather than
+  `view show execution` for done/now/next and current authored planning guidance with its
+  source. Mission and wave inspection shows admission and exit guidance; wave/slice details
+  include review decisions. Accepted-core guidance stays separate from full-contract proof,
+  live custody and executable dependencies. An `INDETERMINATE` cell stays unknown rather than
   being filled from memory. **`rig view register`** turns a query you keep re-running into a
   first-class view.
 - **`rig config`** — bare, with no arguments: every key, every current value, and where each came
@@ -63,9 +66,10 @@ unseen — which makes messages the one delivery channel that never gets skipped
   consequential delivery gets an effect check at the far end rather than a blind retry. A
   producer-link advisory reading `no_activity_signal` means activity could not be determined;
   confirm by effect, never relaunch on it.
-- **`rig send --raw`** / **`--dangerously-interact --reason "<why>"`** — a seat is frozen on an
-  interactive prompt or a permission block. Normal `send` *refuses* to answer a prompt on purpose;
-  this is the deliberate override, and it is how you unblock a peer who cannot unblock itself.
+- **`rig send --raw`** — send exact text or keystrokes without the From/To envelope;
+  the interactive-prompt guard still applies. To deliberately drive an interactive prompt,
+  **`--dangerously-interact --reason "<why>"`** is the explicit override and implies raw text.
+  Inspect the prompt and establish authority for its effect before using that override.
 - **`rig broadcast`** — one fact to everyone at once, rather than relaying it N times and getting
   the wording wrong on the fourth. **Blast radius is real** — on a large rig this lands in every
   seat's turn.
@@ -88,11 +92,12 @@ unseen — which makes messages the one delivery channel that never gets skipped
   someone lists the stream before starting.
 - **`rig terminal open <view>`** — bring every live agent in a rig, mission or slice up as real
   typeable tiles at once.
-- **`rig walk <seat> --through <files> --pace <n>`** — deliver a *sequence* of context into a seat
-  one piece at a time, with a gap between pieces. **This is how you hand somebody a large amount of
-  material without dumping it**: absorption between pieces is the whole mechanism, and sending
-  faster than the receiver thinks merges everything into one turn and destroys it. It is also how
-  you were onboarded, and how you would onboard someone else.
+- **`rig walk <seat> --through <files> --pace <n>`** — deliver context pieces through
+  file-backed terminal paste. When the current native generation record resolves, the complete
+  piece and its matching Claude/Codex turn closure must arrive before pacing onward, including
+  the last piece. Initial missing evidence is explicitly unverified; a record lost or replaced
+  during verification stops the walk. Use `rig walk --help` for those receipts and bounds.
+  Delivery and turn completion do not prove comprehension.
 - **`rig slack`** — inspect and manage one connector implementation. Use registered-human
   readiness for the delivery decision and `queue create --verify` for its receipt; connector
   setup or verification is not an outbound human message.
@@ -150,10 +155,10 @@ you that is still running.
 
 ## Running a pipeline without relaying every step
 
-**Work does not only move because you move it.** A configured workflow routes each step to the next
-owner and wakes them. Where one exists, **you are exception handling, not the engine** — and if you
-find yourself hand-relaying every step, the loop has not been built yet, and building it is usually
-cheaper than being it.
+**A workflow remembers the plan and routes the next action; agents judge the outcome.** Its
+conditions, packets and waits carry decisions across returns. Inspect and revise the selected
+graph when reality changes, preserving completed work and current ownership. Repeated manual
+relay is a reason to inspect the available routing, not to surrender judgment to a fixed pipeline.
 
 - **`rig workflow specs`** — what can be started here, and which are shipped versus authored by
   this rig.
@@ -162,23 +167,71 @@ cheaper than being it.
   from `project.yaml` → `mission.yaml` → `slice.yaml`, inspect it without writing, then start an
   eligible graph with an opaque replay key. Typed acceptance candidate, verdict, and evidence
   travel through `workflow project`; workflow completion alone is never release acceptance.
+  A project-owned release profile carries required obligations across missions; explicit
+  extensions/overrides preserve them. Reach for `docs/reference/project-release-profile.yaml`
+  when release graphs keep being copied or losing stages. The release ceremony and post-release
+  boundary remain distinct; no successor is required to finish. Agents judge the evidence.
 - **`rig workflow instantiate`** — start a multi-step, multi-seat run as one governed instance with
   an entry packet that lands on a real owner.
-- **`rig workflow status`** — **which instances need *you*, right now**, with the reason and next
-  action. This is the "what is waiting on me" surface.
+- **`rig workflow status`** — which instances need attention, with reason and next action.
+  Inspect the exact exception occurrence and packet: resolved overdue work is reconciled without
+  closing an overdue sibling. Registered-human fallback reports missing or ambiguous selection
+  instead of inventing a recipient. Follow the state/error and `workflow show`/`trace` before retrying.
+- **Exception ownership before failure:** `workflow compile` and `workflow validate`
+  expose `exceptionReadiness`; `workflow show` renders it alongside existing exception
+  obligations and their queue/evidence pointers. Defining an ordinary role does not select
+  an exception owner. Follow `selection.source` to the owning `exception_routing.orchestrator_role`
+  field; project profiles own it unless the mission explicitly overrides the graph.
+  Selection, registered identity, genuine capability no-match, intended registered-human
+  fallback, ambiguous human selection and unavailable reads remain distinct. An advisory
+  before failure is not a requirement to keep every future role/model live. A failed read
+  cannot establish no-match or silently route to a human. If human selection is needed,
+  inspect `rig gateway human list --json`; select `workspace.operator_seat_name` when ambiguous.
 - **`rig workflow show` / `trace`** — what this instance is, and every step, actor and exit that
   got it here.
+- **`rig workflow revise <instance>`** — compare the bound graph with current authored
+  inputs before changing a progressed run. Ordinary show and TUI inspection distinguish
+  source-only edits (such as a catalog address) from executable changes. Preview names
+  changed steps, incompatibilities and an exact apply command. Supported revisions preserve
+  completed/live steps, receipts, required obligations and child custody; new work must
+  depend on unfinished work. A changed completed/live contract needs explicit reconsideration:
+  restore it and revise unstarted successors. Revision does not guess a migration or replay
+  accepted consequences. Exception-routing corrections can be adopted for future occurrences;
+  existing exception obligations retain custody. Editing source alone does not change the
+  running owner. Inspect `workflow show` after adoption and inspect each admitted queue row's
+  evidence. Authoritative workflow recovery/completion clears obsolete overdue occurrences;
+  an unresolved sibling stays visible. Closing a queue row alone is not semantic acceptance.
+- **`rig workflow operation <key>`** — recover the committed creation/revision effect after
+  a timeout or disconnected response, even if authored files have since changed. Retain the
+  operation key and repeat only the identical decision. The original receipt and current
+  instance are distinct; a terminal packet is not acceptance.
+  Project profiles and mission extension/override define outer steps; bound slice manifests
+  are not automatically nested execution. Waves are agent planning groups. The current
+  plan's admission, review and integration guidance returns in lifecycle packets and their
+  continuation, alongside the small revision move. Scope creation/move maintains manifest
+  membership; `--depends-on` is advisory build order, while `execution.depends_on` defines
+  executable prerequisites.
 - **`rig workflow continue`** — where you are in a run you have been handed. **It is read-only. It
   does not continue anything**, despite the name — `project` is the advance verb.
 - **`rig workflow route`** — the owner of the current step is gone; move *that step* to a live seat
   without pretending it completed.
-- **`rig workflow resume`** — the instance failed, you fixed the cause, redrive from the broken
-  step rather than re-running what already succeeded.
+- **`rig workflow resume`** — after correcting a failure, redrive its step while retaining
+  completed work. A dependency branch can fail while siblings remain live. Use
+  `--occurrence <failed-qitem-id>` to select that failure (required when several are
+  unresolved); its obsolete exception obligation closes in the redrive transaction,
+  while unresolved siblings stay visible. An identical occurrence/decision retry returns
+  the existing redrive without duplicating work.
 - **`rig workflow run` / `watch` / `list`** — run to completion with an exit code you can act on,
   watch it happen, or see what exists.
 
 ## Bringing things into and out of existence
 
+**For a first useful repository change**, preview `first-project`, inspect
+`rig up first-project --cwd . --plan`, and follow `docs/reference/getting-started.md`.
+Its native Codex owner/checker team is the focused starting point; verify prerequisites and
+actual runtime readiness before work. Existing Herdr/cmux terminals can present the managed team
+through `rig terminal open`.
+
 **Need a small team now, without authoring YAML?** Start with `rig create`, then use `rig grow`
 (including `--new-pod`) while it runs. A working topology can become a reusable spec later; you do
 not have to tear one down to change it, and you rarely have to start from nothing.
@@ -223,16 +276,23 @@ because someone lost work once.
 - **`rig start`** — the box rebooted and everything is gone: bring the whole topology back in one
   move, rather than hand-restoring rig by rig. Selected-rig recovery now demands positive runtime
   evidence and refuses stale identity by name rather than substituting an occupant.
-- **`rig daemon start` / `stop` / `status` / `logs`** — bounce the control plane, or read what it
-  actually tried and refused, in its own voice.
+- **`rig daemon start` / `stop` / `status` / `logs`** — startup reserves the local instance and
+  verifies its own child on required listeners. Inspect a retained reservation before retrying.
+  Stop distinguishes process/listener exit from a clean asynchronous drain: inspect the matching
+  `daemon-shutdown.json` and log when completion is incomplete or unverified. No target is a
+  distinct no-op, and a timeout never proves down. Use command help for exact limits and recovery.
 - **`rig doctor`** — is the *installation* wired up correctly, or are you chasing a bug that is
   really a broken install. **`rig preflight`** asks whether this machine can run OpenRig at all.
-- **`rig crash-cart`** — the daemon is down or not answering: what was running before it died, and
-  where did the work stop. **NEW in v0.5.2: bare `rig` on a dead daemon opens the crash-cart
-  cockpit, and one Enter restores the whole fleet** — kernel-first, surviving panes ADOPTED live
-  (never clobbered), dead rigs restored from snapshots, non-resumable seats on a scrollable triage
-  list with their exact remediation, mid-run cancel with `c`. It only offers RESTORE on POSITIVE
-  down-evidence (confirmed-down vs cannot-verify are distinct screens).
+- **Bare `rig`** — the same TUI for first setup, daemon-down startup and ordinary work.
+  Enter starts only the selected daemon; then choose rigs and individual seats, with kernel
+  recommended first. Previously occupied seats default to their authoritative conversation.
+  Missing history, ambiguous identity and unavailable authentication have distinct explanations;
+  a fresh conversation requires a separate named confirmation. Declining launches nothing.
+  **o** opens the existing native terminal here to handle its prompts; detach to return.
+  If a fresh start paused before context delivery, **c** finishes that same occupant’s context.
+  **r** refreshes actual state and **d** expands diagnostics. **S** returns to startup from work.
+- **`rig crash-cart`** — the read-only daemon verdict and saved-state discovery used by that UI.
+  An unavailable runtime, unauthorized endpoint or unreadable state is not an empty instance.
 - **`rig snapshot`** — take a restore point **before** the risky thing. `snapshot list` shows what
   you actually have and how old the newest is; `--intended-seats` records the topology roster the
   later restore must judge rather than treating every historical node as current.
@@ -251,9 +311,9 @@ because someone lost work once.
   managed seat with the `context-usage-threshold` watchdog above so continuity is arranged while
   the seat can still act.
 - **`rig handover <seat>`** — replace the **occupant** of a seat while the seat, its name, its
-  edges and its inbound work stay exactly where they are. **`rig seat handover` is the PLANNING
-  half** — it shows you what would happen; the top-level verb performs it. Two commands, similar
-  names, different blast radius.
+  edges and its inbound work stay exactly where they are. **`rig seat handover` uses the same
+  effectful handover path.** Both forms perform the operation by default; pass `--dry-run`
+  to plan without changing the seat. Check the selected source and continuity evidence first.
 - **`rig seat clear-attention` / `set-resume-token`** — clear a stale attention flag, or repair a
   lost resume handle so restore works next time.
 - **`rig seat set-model` / `stop` / `clean`** — persist the model for later managed resumes, stop
@@ -310,6 +370,13 @@ scheme, and nothing downstream can see it.
   from the authored SPEC with a named advisory, and `contractSource` in the echo records which
   source actually bound. When someone later asks where the contract items came from, the drop's
   own echo is the answer — not a re-read of the files.
+- **`rig proof judge` / `rig proof show`** — record an attributed judgment on a contract item once,
+  then read derived proof, slice, mission and project readiness. The owning scope selects
+  `proofPolicy.judges` (nearest slice, mission or project policy wins); consult `rig proof --help`
+  for that setup and the item/evidence selectors. Accept, reject or withdraw against readable
+  evidence; corrections preserve history and unrelated judgments without ancestor status edits.
+  Non-code work can name its actual artifact instead of inventing a commit. Evidence capture,
+  policy acceptance, higher outcome judgment and publication remain separate decisions.
 - **`rig workspace doctor` / `validate`** — does the daemon agree with you about where the work
   tree is, and which files are missing the frontmatter their kind requires.
 - **`rig context work-install --project … --mission … --slice … [--deliver]`** — resolves the ordered
@@ -317,6 +384,9 @@ scheme, and nothing downstream can see it.
   loadout, `--apply-skills` to reconcile its owned harness projection, or `--deliver` to emit the
   exact extant files in order while marking absent pieces visibly. Without the flags it remains
   plan-only.
+  `context profile` and `context work-install` both accept `--runtime claude-code` (alias
+  `claude`) or `codex`; explicit invalid values refuse before projection. This does not rename
+  every other command's runtime vocabulary.
 - **`rig context show` / `sync` / `rm`** — what is inside a context pack before you prime a seat
   with it, and how to make the library catch up when you edit one.
 - **`rig context get <name-or-ref>`** — pull exact context by address instead of reading files:
@@ -397,6 +467,9 @@ reaching them is ordinary work rather than an escalation.
   to the external participant, not a separate outbound route.
 - **`rig gateway human add`** — register a person and their connector binding. Registration or
   connector changes do not themselves authorize a message.
+- **During local-daemon outage, remote HTTP sender attribution still uses the originating
+  instance's durable identity.** A selected remote or forwarded endpoint never becomes the origin.
+  Missing local identity remains explicitly unknown; transport success is not operation success.
 - **Across a host boundary, "it didn't work" has four distinct shapes** — unreachable machine,
   permission gate, remote runtime down, or the remote command itself failed. Collapsing them throws
   away a diagnosis you already had. **And a transport that succeeded says nothing about whether the
@@ -435,12 +508,24 @@ your circumstances is configuration, and the ones that are not, another agent ca
 - **`rig setup`** — what OpenRig would change about this machine, shown before it touches anything.
 - **`rig usage series`** — what a seat's token curve has looked like over time: climbing steadily,
   reset, or stopped reporting entirely. The last one is a signal, not a gap.
-- **`rig tui`** — the interactive view over rigs, pods, seats and specs. **`rig tui commands`**
-  lists everything it can do without launching it. Open the instance row for one continuous
-  cross-rig agent table with pod separators and material `RECENT` transitions; drill into a rig,
-  mission, slice, or agent without losing the owning identity. **`rig ui open`** is unmaintained,
-  best-effort, and replaced by the TUI, so never diagnose product behaviour from the web UI. The
-  TUI plus Slack are the human surface; the CLI plus terminal are the agent surface.
+- **`rig tui`** — the interactive view over rigs, pods, seats and specs. `rig tui --shared`
+  attaches to the existing kernel terminal; Ctrl-b then d detaches, and no missing seat or
+  terminal is implicitly launched. Plain `rig tui` remains a separate view.
+  Open the instance row for one continuous cross-rig agent table with pod separators and material
+  `RECENT` transitions; drill into a rig, mission, slice, or agent without losing the owning
+  identity. Use the mission's workflow/packet view and Specs purpose/source to understand work.
+  Tab completes commands and snapshot arguments; Recent opens original events. **CONFIG**
+  browses instance/work roots, context, display, waiting, recovery, activity and advanced settings;
+  Slack and people are one category. Select a category, use right/left to change panes,
+  Enter for full value/default/source/scope, `/` to search labels and keys, and Escape or `back`
+  to return. Long detail scrolls; `v` enables terminal text selection. `refresh` reads the current
+  view again without changing settings or verifying delivery. Sources & coverage names exclusions,
+  daemon/CLI identity and the client timezone separately. Resolved settings do not prove runtime
+  adoption. The legacy `connections` command still inspects gateway services and human routes;
+  dated verification does not prove delivery. `timezone` gives persistent local-time guidance.
+  **`rig tui commands`** lists everything it can do without launching it. **`rig ui open`** is
+  unmaintained, best-effort, and replaced by the TUI, so never diagnose product behaviour from
+  the web UI. The TUI plus Slack are the human surface; the CLI plus terminal are the agent surface.
 - **`rig mcp serve`** — how an agent that speaks MCP rather than shell drives OpenRig, and which
   operations are exposed that way. Relevant the moment a tool you are integrating cannot run a
   shell command.
@@ -448,8 +533,10 @@ your circumstances is configuration, and the ones that are not, another agent ca
   selectors, target, and current/missing/shadowed/conflicting state for one working directory.
   `--apply` writes only the managed ownership set, is idempotent, and refuses local edits or
   unowned collisions.
-- **`rig startup-proof submit`** — prove you actually oriented at boot, rather than claiming you
-  read the prompt.
+- **`rig startup-proof submit`** — answer an explicitly selected authenticated startup challenge.
+  Startup adds no proof exercise by default. Declare `startup_proof` with `authenticated` or
+  `none` in the applicable startup layers; see `docs/reference/rig-spec.md#startup-block/startup-proof-selection`.
+  Terminal nodes never challenge, and resume/adoption does not create a new challenge.
 
 ---
 
@@ -467,7 +554,7 @@ database. It is one more set of primitives on a machine full of them.
   moving* falls out — which is the actual question behind every "is the rig stuck."
 - **"Is that seat stuck or thinking?"** — the row face answers this now (S04 pickup receipts):
   every list/show projection carries a derived `pickup` state — `working`, `stalled-after-claim`
-  (with its evidence named: claimed N min ago, zero substantive transitions since), `parked`, or
+  (with its evidence named: time since meaningful queue change and current activity confidence), `parked`, or
   `unclaimed` — and `rig view show pickup` lists every claimed row with it. The old by-hand join
   (capture + `claimedAt` arithmetic + `queue transitions`) is RETIRED as a first move; `rig
   capture` remains the second question (is the pane alive), never the state derivation.
@@ -475,9 +562,24 @@ database. It is one more set of primitives on a machine full of them.
   whether or not it has a wake; a strand reads `stalled-after-claim` with named evidence. Wake
   health and fired-but-unconsumed diagnosis come from `rig parked`, not the pickup projection.
   `queue transitions` remains the audit trail for WHAT happened, not the tool for deriving pickup.
-- **"Did that actually land?"** — `queue show` truncates the body and `queue list` can report
-  `bodyBytes=0`; neither means empty. **`sqlite3 "$OPENRIG_DB" "select length(body) …"` is the
-  only answer.** The CLI is a projection; the database is the thing.
+- **"Did that actually land?"** — `rig queue show <qitemId>` gives a bounded preview,
+  original byte size and the exact expansion command. Read the complete original record with
+  `rig queue show <qitemId> --full --json`; a preview or a compact list is not the whole body.
+  Delivery status is separate from content: inspect its receipt before claiming it was consumed.
+- **"What am I waiting on?"** — the queue row's `waiting` view derives its owner, exact blocker
+  and blocker owner, last meaningful change, activity confidence and next backstop from live
+  domain facts. A failed handoff names the delivery ladder before the later unclaimed safety
+  net; its due time is earliest eligibility, with suspension or current recovery disposition
+  shown explicitly. The executing scheduler still checks live state at that time. A working activity observation is not proof of task progress; unknown stays
+  unknown. A repeating wait sends one compact notice per blocker transition, with the existing
+  stuck sweep owning a failed or unconsumed notice after the pickup grace. Real changes use the
+  event path; scheduler reconciliation repairs missed events. A returned result and its dependent
+  resumes share one delivery while retaining their separate rows and receipts.
+  For a workflow waiting on a slice outcome, add `--wait-for-proof <slice-scope>` to
+  `rig workflow project --exit waiting`: it binds the current proof `attention` revision.
+  Proof events invalidate that observation; the authored wait timer repairs a missed event
+  by reading the same current proof source. Inspect `rig workflow project --help` for the
+  required instance, packet and actor arguments; this opt-in does not accept a slice.
 - **"What does this whole corpus say about X?"** — bigger than your window, so do not read it.
   **Fan out**: one region per subagent, N in parallel, each returning a structured report, and you
   read reports rather than sources. **This is the move that beats your own context limit** — it

package/daemon/context-packs/skills/agent-operated-software/SKILL.md

@@ -72,10 +72,13 @@ Consumers fail closed on the shared proof. A filename or exit code is not conten
 
 ## Build with an agent SDLC
 
-Map work onto **intent -> plan -> spec -> build -> verify -> review -> QA -> done**. The human supplies
-steering, judgment, taste, and the call on irreversible ambiguity; agents perform and coordinate the
-technical work. Locks freeze the agreed spec and accepted delivery so multiple seats can work without
-guessing whether the target moved.
+Select the rigor required by the outcome and the project's policy. Scope relationships,
+attributed evidence-backed item judgment, and genuinely distinct higher judgment have separate
+owners. One item judgment derives its upstream readiness; agents do not synchronize parent
+checkboxes, queue tags, or status prose. Capture alone is not acceptance, and readiness does not
+publish or advance a workflow. Use `openrig-operating-model` and `rig proof --help` for the
+supported judgment, correction, and read path. Keep historical locks and evidence addressable.
+The human supplies steering, taste, and decisions the project's authority reserves for them.
 
 For studio applications, the running product is usually the best iteration surface. A separate mockup
 earns its cost only when it resolves a real design uncertainty that the running app cannot expose as

package/daemon/context-packs/skills/agent-operated-software/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-operated-software"
-version: "0.5.10"
+version: "0.5.12"
 taxonomy: "skills"
 purpose: "Use when designing, building, operating, or diagnosing an ongoing application whose live backend or control loop includes OpenRig agents, including applications with a Markdown, YAML, or JSON agent control plane or a thin surface over specialist agent roles."
 files:

package/daemon/context-packs/skills/agent-operated-workflows/SKILL.md

@@ -75,5 +75,7 @@ knowledge.
 A capability composition is a reusable recipe; this is the execution architecture that operates
 capabilities toward an outcome. Promote a proven workflow to the composition shelf only after use.
 
-**Reference implementation:** Release 0.5.9 Slice 05 is the first **Agent-Operated Migration**. Its
-runbook and helpers remain there; this skill carries the reusable contract, not a duplicate procedure.
+**Public example:** load `skills/core/openrig-upgrade/SKILL.md` with
+`rig context get` for the upgrade runbook. Its adjacent `scripts/` directory
+contains the bounded inspection, backup, plugin-refresh and migration helpers.
+Follow that runbook for the procedure; this skill carries the reusable contract.

package/daemon/context-packs/skills/agent-operated-workflows/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-operated-workflows"
-version: "0.5.10"
+version: "0.5.12"
 taxonomy: "skills"
 purpose: "Use when a bounded real-world procedure has a deterministic happy path but brownfield, variable, or partially knowable state; when an operation must resume from verified evidence; or when deciding whether agent judgment or ordinary code should own a procedure's control loop."
 files:

package/daemon/context-packs/skills/applying-a-permission-policy/SKILL.md

@@ -3,12 +3,12 @@ name: applying-a-permission-policy
 description: "Use when a permission policy is attached to a rig/seat (rig.yaml permission_policy:), or a user asks you to apply one, and you must translate that harness-neutral policy into the target harness's LIVE permission config — Claude settings.json / Codex config.toml / Pi run flags. Agent-driven and interactive: you read the policy, ground yourself in YOUR harness version, show the diff, and ask before writing. NOT for defining policies (that's the policy spec) and NOT a set-and-forget updater."
 metadata:
   openrig:
-    stage: established             # config cells VM-verified + cold-transfer PASSING (rerun #2) + built-in SPEC FILES landed → skill translates FROM the spec (POINT-not-COPY). The two established criteria met 2026-08-04. Reviewed at push.
+    stage: established
     tested_against:                # VERSION STAMP — the whole point; re-verify at every harness bump
       claude_code: "2.1.220 — VM-CONFIRMED 2026-08-03 (all cells)"
       codex: "0.120.0 — VM-CONFIRMED 2026-08-03 (sandbox_mode/approval_policy; on-failure deprecated-but-accepted)"
       pi: "0.83.0 — VM-CONFIRMED 2026-08-03: --approve/--no-approve govern PROJECT-RESOURCE TRUST, NOT tool permissions; Pi has NO permission surface (see Pi leg)"
-    verification_status: "Live-verified 2026-08-03/04. Claude 2.1.220 + Codex 0.120.0 config cells CONFIRMED live. Pi 0.83.0 divergence folded (flags = project-resource trust, not a permission gate). Cold-transfer rerun #1 blocked on the force_push/push_to_remote prefix collision → added the PREFIX-COLLISION rule. Cold-transfer rerun #2: TRANSFERS — all 5 gate checks pass (collision resolved deterministically without asking; single ordinary write confirmation; defaultMode floor written; Codex workspace-write/on-request; Pi compute-nothing). Blocking collision/floor defect CLOSED → gate cleared, 4.8-shippable (provisional-with-passing-cold-transfer). Non-blocking seam closed: the built-in SPEC FILES landed (arch-accepted, source:builtin) → skill translates FROM the spec, interim in-skill pinned summary retired (POINT-not-COPY). stage:ESTABLISHED 2026-08-04 — both criteria met."
+    verification_status: "Historical compatibility checks on the versions and dates in tested_against. These observations do not establish behavior on a later harness; verify its current format before applying the mapping."
 ---
 
 # Applying a permission policy
@@ -30,17 +30,17 @@ Harness permission formats are a **moving target**. The exact fact this skill is
 - NOT for authoring policies (that's the policy spec) and NOT for daemon-level enforcement (OpenRig is agnostic — it injects nothing).
 
 ## What you're translating (the boundary)
-INPUT = a **harness-neutral policy spec** (arch's schema): `default_posture`, `floor`, `allow`/`ask`/`deny` as **semantic actions** (`push_to_remote`, `delete_files`, …), `destructive_class`, `source: builtin|custom`. You TRANSLATE that intent → the harness's live config. You never invent policy; you never pre-bake harness config into the spec.
+INPUT = a **harness-neutral policy spec** (semantic action schema): `default_posture`, `floor`, `allow`/`ask`/`deny` as **semantic actions** (`push_to_remote`, `delete_files`, …), `destructive_class`, `source: builtin|custom`. You TRANSLATE that intent → the harness's live config. You never invent policy; you never pre-bake harness config into the spec.
 
 ## The apply flow (interactive — the interactive-ask IS the product)
 1. **Read the policy spec** + its `source:` marker (built-in read-only from the package = copy-to-customize before editing; custom = user space).
 2. **PREFLIGHT (mandatory) — ground yourself in THIS environment:**
-   - **daemon-HOME must equal seat-HOME**, or a user-level Claude write never reaches the seat (assessment iv). Check; if they differ, **stop and ask** — do not write into the wrong HOME.
+   - **daemon-HOME must equal seat-HOME**, or a user-level Claude write never reaches the seat. Check; if they differ, **stop and ask** — do not write into the wrong HOME.
    - Read the harness's **actual current config file** + confirm its schema against your installed version (`claude --version`, the live settings.json shape, codex/pi versions). If the format differs from this skill's `tested_against`, trust the LIVE format and flag the drift.
 3. **Derive the per-harness config** from the semantic actions (see the three legs below). Compute the Codex posture-collapse + Pi bit.
 4. **Show the concrete DIFF before writing** (old → new, per file). Never a blind write.
-5. **Resolve best-effort actions by the built-in's rule FIRST, then ask only on genuine ambiguity.** Best-effort destructive actions (`force_push`, `delete_files`, `delete_everything`, `read_secrets`) default to **`ask`** (never a `deny` that can't be enforced) — apply that default rather than stopping to question-back. Surface a question only when the policy is genuinely ambiguous or the seat is interactive. **For a same-prefix collision (`push_to_remote` vs `force_push`, both `Bash(git push:*)`), NEVER ask — apply the deterministic PREFIX-COLLISION rule in the Claude leg.** (Live cold-transfers caught fresh agents *question-backing* — first on the `force_push` default, then on the prefix collision — instead of applying the fixed rule; both freeze an autonomous seat.) On a Claude-only fleet, if the policy denies `network_egress`, **say so explicitly**: it is NOT enforceable — Claude has no network gate, a `Bash(curl:*)`/`Bash(wget:*)` deny is best-effort, and `python`/`node` fetch bypasses it (live-verified: `urllib` reached HTTPS 200 under a curl/wget deny). Route real egress-gating to the Codex sandbox, or record it as advisory on Claude.
-6. **Back up the current config**, then write. Prefer the **user-level** file (`~/.claude/settings.json`) for durable policy — it's the clobber-resistant tier (deny wins across the union). **ALWAYS include `defaultMode: "acceptEdits"` in the Claude settings.json you write** — the floor key must be PRESENT in the file, or the config policy strips the floor. (This is the exact gap a live cold-transfer test FAILED on: the fresh agent wrote allow/deny lists but omitted `defaultMode`, leaving the seat below the floor.)
+5. **Resolve best-effort actions by the built-in's rule FIRST, then ask only on genuine ambiguity.** Best-effort destructive actions (`force_push`, `delete_files`, `delete_everything`, `read_secrets`) default to **`ask`** (never a `deny` that can't be enforced) — apply that default rather than stopping to question-back. Surface a question only when the policy is genuinely ambiguous or the seat is interactive. **For a same-prefix collision (`push_to_remote` vs `force_push`, both `Bash(git push:*)`), NEVER ask — apply the deterministic PREFIX-COLLISION rule in the Claude leg.** On a Claude-only fleet, if the policy denies `network_egress`, **say so explicitly**: it is NOT enforceable — Claude has no network gate, a `Bash(curl:*)`/`Bash(wget:*)` deny is best-effort, and `python`/`node` fetch bypasses it (live-verified: `urllib` reached HTTPS 200 under a curl/wget deny). Route real egress-gating to the Codex sandbox, or record it as advisory on Claude.
+6. **Back up the current config**, then write. Prefer the **user-level** file (`~/.claude/settings.json`) for durable policy — it's the clobber-resistant tier (deny wins across the union). **ALWAYS include `defaultMode: "acceptEdits"` in the Claude settings.json you write** — the floor key must be PRESENT in the file, or the config policy strips the floor.
 7. **Verify** the write landed and the seat can see it (re-read; confirm `defaultMode: "acceptEdits"` is present; for an autonomous seat, confirm no `ask` will freeze it).
 
 ## Two surfaces — and this skill writes only ONE of them
@@ -48,7 +48,7 @@ Permissions live on two surfaces with opposite stability — which is the whole
 - **LAUNCH-FLAG surface — STABLE (>1yr) → OpenRig sets it DETERMINISTICALLY, NOT this skill.** The flags OpenRig passes at boot: Claude `--permission-mode` / `--dangerously-skip-permissions`; Codex sandbox/bypass flags; Pi `--approve`/`--no-approve`. **Two things live here, both OpenRig-owned: the FLOOR (minimum, by default) and YOLO (full bypass, opt-in).**
 - **CONFIG-FILE surface — CHAOTIC → NEVER deterministic → THIS SKILL'S DOMAIN.** Claude `settings.json` allow/ask/deny + defaultMode; Codex `config.toml` approval rules. This is where the Locked / Standard / Open policies get applied — agent-driven, version-stamped, caveated. (Pi has **no permission surface at all** — its `--approve`/`--no-approve` flags govern project-resource trust, not tool permissions (VM-confirmed Pi 0.83.0); a permission policy does not translate to Pi. See the Pi leg.)
 
-**THE FLOOR (launch-flag, OpenRig-set — this skill KNOWS it, never WRITES it):** Claude `--permission-mode acceptEdits` (keep it); **Codex workspace-only** (stop forcing `danger-full-access` — ≈ Codex's own default ≈ setting-nothing = agnostic); Pi `--no-approve` (a project-resource-trust floor — Pi has no permission gate; see the Pi leg). **One consistent unconditional minimum** (no by-context switching — that mode idea is parked 5.0). A chosen config-file policy layers ON TOP of the floor.
+**THE FLOOR (launch-flag, OpenRig-set — this skill KNOWS it, never WRITES it):** Claude `--permission-mode acceptEdits` (keep it); **Codex workspace-only** (stop forcing `danger-full-access` — ≈ Codex's own default ≈ setting-nothing = agnostic); Pi `--no-approve` (a project-resource-trust floor — Pi has no permission gate; see the Pi leg). **One consistent unconditional minimum**. A chosen config-file policy layers ON TOP of the floor.
 
 **YOLO MODE (launch-flag, OpenRig-set, opt-in — for people done with permissions):** OpenRig boots every seat with the full-bypass flag (Claude `--dangerously-skip-permissions`; Codex full-bypass). **When YOLO is on, CONFIG-FILE POLICY IS MOOT** — this skill does NOT apply a config policy (or explicitly notes it's overridden by the flag); don't fight the bypass. YOLO is OpenRig's deterministic job, not this skill's. (**Operator = YOLO mode** — subsumed.)
 
@@ -79,10 +79,10 @@ Permissions live on two surfaces with opposite stability — which is the whole
 - **PREFIX-COLLISION resolution (deterministic — resolve it, NEVER ask).** When two actions collapse to the SAME base prefix with different dispositions — the canonical case is `push_to_remote`=allow + `force_push`=ask, both basing to `Bash(git push:*)` — you cannot put that base prefix in both `allow` and `ask`. Resolve without a question-back:
   - **Push allowed + force asked (Standard / Open):** put the base `Bash(git push:*)` per push's disposition (`allow`), AND add the flag-first force forms to `ask` (`Bash(git push --force:*)`, `Bash(git push -f:*)`, `Bash(git push --force-with-lease:*)`). RECORD in your diff that this is best-effort — flag-LAST force (`git push origin main --force`) leaks past the flag-first ask rules and runs under the allow. Don't block on it.
   - **Push denied (Locked):** `Bash(git push:*)` in `deny` already covers force — no conflict.
-  This is a FIXED rule, not a user decision — apply it and note the leak. (A live cold-transfer FAILED because a fresh agent *blocked asking* "how to resolve the force_push/push_to_remote collision" instead of applying this default.)
-- **`defaultMode: "acceptEdits"` is the FLOOR and MUST be written into every Claude settings.json you produce.** It is not a knob you tune, but it IS a key you must always include — a config policy that omits it strips the floor (the cold-transfer failure). Live-confirmed schema: `{"permissions":{"allow":[],"ask":[],"deny":[],"defaultMode":"acceptEdits"}}`.
+  This is a FIXED rule, not a user decision — apply it and note the leak.
+- **`defaultMode: "acceptEdits"` is the FLOOR and MUST be written into every Claude settings.json you produce.** It is not a knob you tune, but it IS a key you must always include — a config policy that omits it strips the floor. Live-confirmed schema: `{"permissions":{"allow":[],"ask":[],"deny":[],"defaultMode":"acceptEdits"}}`.
 
-### Codex — `~/.codex/config.toml` (via the existing X10 `codex_config_fragment` splice path — reuse, don't invent)
+### Codex — `~/.codex/config.toml` (via the existing `codex_config_fragment` splice path — reuse, don't invent)
 - Codex is **per-posture, not per-action**: the whole action set **collapses** to the nearest `{sandbox_mode, approval_policy}` pair. **Built-in → posture** (VM-CONFIRMED @ Codex 0.120.0, 2026-08-03 — each posture applied to a real seat: read-only blocked writes+egress, workspace-write allowed writes/blocked egress, danger-full-access allowed both):
 
   | Built-in | `sandbox_mode` | `approval_policy` | Collapse note (surface this to the user) |
@@ -107,7 +107,7 @@ Permissions live on two surfaces with opposite stability — which is the whole
 - **daemon-HOME ≠ seat-HOME** silently voids user-level writes — always the preflight check above.
 
 ## The built-ins — DEFINED by the shipped policy spec files (translate FROM the spec; POINT, don't COPY)
-The four built-in policies ship as read-only spec files (`source: builtin`, `policy_schema_version: 1`) — they are the AUTHORITATIVE definitions. **Do NOT restate their action-sets here.** An earlier in-skill copy drifted (it under-asked `publish_package`/`merge_or_release`, which the spec ASKs) — the exact reason POINT-don't-COPY is the rule. Read the attached/selected spec and translate its semantic-action sets (`default_posture` / `allow` / `ask` / `deny` / `destructive_class`) per the three legs above.
+The four built-in policies ship as read-only spec files (`source: builtin`, `policy_schema_version: 1`) — they are the AUTHORITATIVE definitions. **Do NOT restate their action-sets here.** The selected spec supplies the action sets; a second copy in this skill can diverge. Read the attached/selected spec and translate its semantic-action sets (`default_posture` / `allow` / `ask` / `deny` / `destructive_class`) per the three legs above.
 - **Locked / Standard ⭐ / Open** — `surface: config`. Translate to the Claude / Codex config surface. **Standard ⭐** is the recommended default: routine dev incl. push allowed, the outward/release/history-rewriting acts (`create_pr`, `publish_package`, `merge_or_release`, `force_push`) ASK, destructive_class ASKs. Standard has live `ask` gates → not for a headless-autonomous Claude seat (use Open or YOLO). Locked = deny-default whitelist; Open = allow-default, destructive_class asks only.
 - **YOLO** — `surface: flag`, `launch_posture: full_bypass`. This skill does **NOT** translate it — it points at OpenRig's deterministic flag-surface opt-in (the rip-out YOLO setting). When YOLO is on, any config-surface policy is MOOT (the bypass overrides it). (Subsumes the former "Operator".)
 
@@ -115,6 +115,3 @@ Built-ins ship read-only in the package (canonical names); copy-to-customize int
 
 ## Boundary (keeps this the only maintained piece)
 This skill TRANSLATES + APPLIES only. It does **not** define policies (the policy spec does) and does **not** enforce at the daemon (OpenRig is agnostic). Spec = *what* (neutral intent); this skill = *how, on this harness version* (the caveated, version-stamped translation).
-
----
-*Stage: ESTABLISHED (2026-08-04) — both criteria met: (1) cold-transfer PASSING (rerun #2, all 5 gate checks TRANSFER); (2) the built-in policy SPEC FILES landed (`source: builtin`, arch-accepted) as the authoritative source — the skill now translates FROM the spec and the interim in-skill pinned summary is retired (POINT-not-COPY). Config cells VM-CONFIRMED (Claude 2.1.220 / Codex 0.120.0); Pi has no permission surface (compute-nothing). Reviewed at push. feedback.md maintained.*

package/daemon/context-packs/skills/applying-a-permission-policy/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: "applying-a-permission-policy"
-version: "0.5.10"
+version: "0.5.12"
 taxonomy: "skills"
 purpose: "Use when a permission policy is attached to a rig/seat (rig.yaml permission_policy:), or a user asks you to apply one, and you must translate that harness-neutral policy into the target harness's LIVE permission config — Claude settings.json / Codex config.toml / Pi run flags. Agent-driven and interactive: you read the policy, ground yourself in YOUR harness version, show the diff, and ask before writing. NOT for defining policies (that's the policy spec) and NOT a set-and-forget updater."
 files: