@openrig/cli 0.6.6 → 0.6.8

package/daemon/context-packs/help/help.md

@@ -24,7 +24,9 @@ rig doctor --json
 ```
 
 Use the installed command's `--help` if an option is unavailable. Read the diagnostic findings; don't treat them as
-instructions to reset the machine. If the daemon is involved, `rig daemon status` and `rig daemon logs` show its state
+instructions to reset the machine. `rig doctor` checks Claude and Codex authentication using the same local checks
+as setup, including a configured Codex provider credential variable. A set variable does not prove that the provider accepts it or that managed
+seats receive it. Doctor does not run an agent task: also inspect `rig ps --nodes --rig <rig>`. If the daemon is involved, `rig daemon status` and `rig daemon logs` show its state
 and recent output.
 
 **If OpenRig won't install or `rig` won't run, start here anyway.** Record the attempted package version, install
@@ -34,34 +36,58 @@ help.
 ## Match the guidance to the installed version
 
 The reference documents beside this file describe the version they were installed with. GitHub's default branch can
-contain changes that haven't reached your user's version. For release notes and known limitations, open
+contain changes that haven't reached your user's version. After an upgrade, start with the short note on what changed
+in the installed version: `rig context get reference/whats-new.md`. For full release notes and known limitations, open
 `https://github.com/mvschwarz/openrig/blob/v<version>/docs/releases/v<version>.md`, using the version number from
-`rig --version` (without the commit it may show in parentheses). If the matching document isn't available, say so
+`rig --version` (without the commit it may show in parentheses). When that file doesn't exist, use the version's
+section of `https://github.com/mvschwarz/openrig/blob/v<version>/CHANGELOG.md`. If neither is available, say so
 rather than treating a newer command as installed.
 
 ## Find your next step
 
 ### Installation or platform problems
 
-Supported platforms are macOS and Linux. Native Windows is not supported yet, and WSL2 has not been tested. OpenRig needs
-Node.js 22 or 24 and tmux. A WSL error needs its actual versions, commands and error text; don't assume a
-Windows-related pull request fixes it.
+Supported platforms are macOS and Linux, and WSL2 on Windows; native Windows isn't supported. OpenRig's automated tests
+don't run on WSL2 yet; one user's [reported working setup](getting-started.md#wsl2-a-reported-working-setup) lists what
+mattered. OpenRig needs
+Node.js 22 or 24 and tmux. A Linux distribution's own Node.js can be older; check `node --version`. With npm 11 or
+later, an `npm warn install-scripts` line for `@openrig/cli` means only the postinstall Node.js and SQLite check was
+skipped; `node "$(npm root -g)/@openrig/cli/scripts/check-abi.mjs"` runs it. A WSL error needs its actual versions,
+commands and error text; don't assume a Windows-related pull request fixes it.
+
+The one-command install ([getting-started](getting-started.md#install-and-sign-in)) prints its plan with
+`--dry-run` and changes nothing. When a step fails it prints `FAILED [n/4] <command or check> (exit <code>)` and
+stops. Read its diagnostic: if it names a runnable command, run that command by hand for the full error and record it
+in a report; otherwise follow the accompanying diagnostic. If the only remaining failures are provider sign-ins under
+"Some steps need attention", the install steps finished: sign in to each selected provider and continue.
 
 ### Installation finished, but there is nobody to talk to
 
-Follow [Open the kernel conversations](getting-started.md#open-the-kernel-conversations)
-(`rig context get reference/getting-started.md#open-the-kernel-conversations`). The default
-`rig terminal open saved:kernel --provider herdr` needs no saved-view YAML or starter team. After the selected login
-works, start the daemon if stopped, then read `rig status` and `rig ps --nodes --rig kernel`. Started is not ready;
-the view can open while the agents finish starting, with that state reported honestly.
-Ask **“Open the OpenRig view now?”** Yes opens a new space using installed herdr, else cmux, else the guide's exact
-new-terminal command. No gives the command to open it later. Over SSH or without a display, give the exact
-connection/attach command. Keep your own terminal and existing user spaces intact; no new view provider is needed.
-No, SSH and headless use are valid background outcomes. For herdr, open or attach the actual session and check the
-visible view; a created workspace or a CLI running in a new OS window is not visual proof.
-Show TUI | advisor | operator for Claude-only, Codex-only and mixed kernels; the queue worker stays accessible through
-the TUI. Talk to the operator about your goal before choosing and launching a first project team.
-Use the existing recovery routes for unavailable seats; opening a view does not create another kernel or new accounts.
+Load the `rigs` skill and follow its step 2: it opens the OpenRig view (`rig terminal open saved:kernel --window`),
+gives the attach commands when the window can't open or over SSH, and hands the person's goal to the operator.
+[Install and sign in](getting-started.md#install-and-sign-in) says how to load it. The reference for the view, manual
+attachment and the table of what can interrupt it is
+[Open the kernel conversations](getting-started.md#open-the-kernel-conversations)
+(`rig context get reference/getting-started.md#open-the-kernel-conversations`). Started is not ready: the view can
+open while the kernel's agents finish starting, and opening it creates no other kernel or account.
+
+### A step interrupted setup or the OpenRig view
+
+Name the exact command and result, the reason it stopped and the next useful step. A harness's permission rules,
+sandbox or automatic permission decision can refuse an installing agent's tool call before OpenRig runs.
+Claude Code's [auto mode can deny calls](https://code.claude.com/docs/en/auto-mode-config); explain the reported
+refusal and let the person review that step in their harness controls or run it themselves, within their chosen
+permissions. Do not silently claim installation failed or completed from a refused call.
+
+For missing tools, downloads or selected logins, use the specific setup hint. A Herdr install warning leaves plain
+tmux available. A requested Ghostty install can fail setup; resolve it or decline with `--no-ghostty` and keep the
+earlier choices. Terminal.app remains available; required tools and logins still matter. macOS may ask for
+Automation permission; a missing display or remote daemon needs the documented headless/manual route.
+Herdr may show an intro (Return to continue) and an agent-integration panel (Esc to close); the view does not
+require installing those integrations. Enlarge a cramped 80×24 window. Use authorized desktop tools to inspect the
+window contents, or state that visibility is unconfirmed and ask the person to check. A successful command or
+window listing alone is not visual proof. The [OpenRig view guide and friction table](getting-started.md#open-the-kernel-conversations)
+connects each observation to its next step. Preserve existing conversations while resolving it.
 
 ### The team did not start, or a terminal is missing
 
@@ -114,6 +140,9 @@ issue's current status; a similar symptom alone is not a diagnosis.
 - A Codex seat on the default `workspace-write` sandbox starts without network access, so it can't reach the local
   daemon, when its Codex configuration sets network access off, a managed requirement could restrict it, or Codex
   doesn't answer OpenRig's configuration read in time: [#275](https://github.com/mvschwarz/openrig/issues/275).
+- Kernel seats fail within a second of the first start on a distribution tmux whose server exits on `capture-pane`
+  (`tmux -V` prints `next-3.4`): [#980](https://github.com/mvschwarz/openrig/issues/980). The check and recovery
+  are in [Incomplete setup and restart](getting-started.md#incomplete-setup-and-restart).
 
 For everything else, search [open issues](https://github.com/mvschwarz/openrig/issues).
 

package/daemon/context-packs/help/manifest.yaml

@@ -1,6 +1,6 @@
 # Agent help: the single troubleshooting and escalation guide (docs/reference/help.md).
 name: help
-version: "0.6.6"
+version: "0.6.8"
 taxonomy: world
 purpose: "What an agent does when its user says OpenRig isn't working: diagnose, fix within permissions, verify, and escalate to OpenRig support."
 files:

package/daemon/context-packs/onboarding-width/manifest.yaml

@@ -1,6 +1,6 @@
 # Public capability and source-map width for the default onboarding walk.
 name: onboarding-width
-version: "0.6.6"
+version: "0.6.8"
 taxonomy: world
 purpose: "The public capability map and source map referenced by the default onboarding walk."
 files:

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

@@ -10,8 +10,8 @@ already does it, or two verbs crossed already answer it. **You cannot look up a
 not know exists.** So the point of what follows is not skill. It is recognition: that when a task
 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.14-r6`). This marker describes the pack's teaching, not publication or live
+Eighty-seven top-level verbs ship (capability canon refreshed through
+`capability-delta-v0.6.8`). This marker describes the pack's teaching, not publication or live
 adoption. 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).
@@ -28,7 +28,8 @@ one command away. Your memory of the fleet is a claim about the past.
 - **`rig ps`** — what rigs exist. **`rig ps --nodes -A`** — the state of every seat everywhere,
   *including the broken ones*. **The bare form is the question you usually want:** `--active`
   filters to running and **hides detached, exited and attention states** — which are exactly the
-  cells you were scanning for.
+  cells you were scanning for. **`rig ps --resources`** shows this host's load and transcript
+  capture cost.
 - **`rig ps --all-hosts --nodes -A`** — the same across every registered machine. Rollup-only
   unless you ask for nodes.
 - **`rig discover`** — what is running on this box that OpenRig is *not* managing.
@@ -44,8 +45,10 @@ one command away. Your memory of the fleet is a claim about the past.
   only the default workspace). 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.
+  being filled from memory. A project that integrates somewhere other than `main` declares
+  `arrangement.source.integration_ref` in `mission.yaml`, and the folded rung checks landed work
+  against it; a ref that is invalid or can't be resolved reads INDETERMINATE.
+  **`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
   from. Most agents assume compaction thresholds, snapshot cadence and scan intervals are hardcoded
   daemon behaviour. They are configuration. **Watch one thing:** `source: default` does not mean
@@ -63,6 +66,15 @@ one command away. Your memory of the fleet is a claim about the past.
   the authored selection and correction record. Authority, current applicability, an assessment,
   an action taken and a later observed effect are separate facts. Recording a correction or
   replaying a case does not establish improved behavior or authorize unrelated work.
+- **`rig roster list` / `show` / `find`** — who across your rigs and hosts is recommended for a
+  kind of work, from JSON rosters in `<workspace.root>/rosters`. Read-only: it dispatches nothing
+  and does not claim anyone is available. The built-in starter and factory leads publish their
+  team's roster at first start.
+- **`rig telemetry events` / `transitions` / `tenures <node-id>`** — past events, queue
+  transitions and a seat's occupants, one bounded page at a time with gaps reported. Reach for it
+  before querying the database yourself.
+- **Check the exit code.** Many commands used to print nothing and exit 0 when a daemon read
+  failed; now they exit 1 or 2. Empty output from a failed read is not empty state.
 
 ## Reaching another agent
 
@@ -74,7 +86,9 @@ unseen — which makes messages the one delivery channel that never gets skipped
   on it. Alternate-screen and queued-command cases can still yield false negatives, so
   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.
+  confirm by effect, never relaunch on it. A send or wake to a seat whose latest hook is a
+  question waiting for a person is refused with `target_needs_input`, even when its screen
+  can't be read: read it with `rig capture` and get the question answered instead of retrying.
 - **`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.
@@ -96,16 +110,34 @@ unseen — which makes messages the one delivery channel that never gets skipped
   runtime tokens.
 - **`rig chatroom wait`** — block until a peer actually says something, instead of polling
   `capture` in a loop. Also `history`, `watch`, `topic` for a named thread that stays retrievable.
+  Its `--timeout` is in seconds and ignores a suffix, so `2m` means 2 seconds.
 - **`rig stream emit` / `list` / `watch` / `archive`** — drop an observation somewhere the *next*
   agent will find it. Emitting costs nothing and does not interrupt anyone; the value appears when
   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 terminal open <view>`** — open a desktop terminal with live agent tiles; a window is the
+  default. **Opening `rig terminal open saved:kernel --window` is the step after install or start**:
+  say you're opening it, run it on the daemon's desktop, then tell the person where it opened. Don't
+  wait for a phrase like “show me my agents”; the same command brings their agents back later. No
+  YAML, herdr when installed or plain tmux. The layout follows the terminal's width: on a narrow
+  one the operator gets the first tab; on a wide one the dashboard and operator sit side by side
+  and the advisor gets its own tab. A `kernel` view the person saved still wins. Inside herdr it
+  opens a focused `openrig kernel` space. It opens where the caller is: Terminal gets a window and
+  Ghostty a tab; from Claude Desktop, iTerm or VS Code on a Mac it opens a new Ghostty or Terminal
+  window, and only then say that clicking macOS's Allow is fine. Herdr is visible only in a
+  terminal the person can see; switching the shared TUI to `:terminals` does not open one. Over
+  SSH, in CI or with no display, the command returns a definite no-window result with the reason
+  and an attach command: relay that command exactly. Inspect the result and visible content, or
+  say what cannot be verified. On a desktop, do not finish by printing a command for the person to
+  type. Only if the window cannot open, `rig tui --shared` is the dashboard-only fallback; explain
+  the failure. `--provider herdr` or `--provider cmux` adds tiles inside a workspace that is
+  already visible, without opening a window; in `--json` output, `reusedWorkspace` with no new
+  tiles means an existing view was reused, which is success.
   In the TUI, **TERMINALS** keeps Saved views prominent and Derived groups collapsed until
   expanded. Names load before detailed readiness. Select a view to inspect its members,
   layout and pages; preview is passive. Saved membership requires deliberate setup.
-  **Open in Herdr** deliberately opens the inspected plan
-  and reports opened, absent or degraded members. Help or a side trip returns to the same preview.
+  **Open terminals ▸** opens the inspected plan through the same desktop launcher, herdr or plain
+  tmux, so the TUI must run on the daemon's desktop; when no window was attempted it shows the
+  preview and attach commands. Help or a side trip returns to the same preview.
 - **`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
@@ -114,14 +146,30 @@ unseen — which makes messages the one delivery channel that never gets skipped
   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.
+  setup or verification is not an outbound human message. After a connection gap the daemon
+  catches up on missed channel messages and marks them late; `rig slack status` shows the
+  connection and the catch-up state. **`rig slack channel-map list` / `set <match> <channel>` /
+  `remove <match>`** sends a rig's or seat's human-bound posts to its own channel (a seat match
+  beats a rig match; the rest use the default channel). After a change, invite the app to each
+  channel, run `rig slack verify`, and rewire the connector (`rig slack disable` then `enable`, or
+  restart the daemon). An emoji reaction on any message posted for an ask reaches the asking seat
+  as a task tagged `human-reaction`: a signal to interpret, not an answer, and the ask stays open.
+  It needs the `reactions:read` scope and the `reaction_added` event (reinstall the app);
+  `rig slack verify` warns when the scope is missing. A long ask is posted in numbered thread parts; one that
+  still can't be posted comes back to the asking seat as a `slack-undeliverable` task. Replies
+  sent with “Also send to #channel” reach the seat like any other thread reply. A person's reply
+  inside a thread OpenRig opened is answered in that thread: answer with `rig queue create
+  --human-intent update --reply-to <the inbound reply's row>`; a top-level message is answered
+  top-level.
 
 ## Making work outlive you
 
 **Your terminal buffer is not a record and your turn is not a container.** A durable row survives
 your context, your compaction and your replacement — and it is the only thing that does.
 
-- **`rig queue create`** — a row with an owner, a body and a transition history.
+- **`rig queue create`** — a row with an owner, a body and a transition history. Its reply, like
+  `handoff`'s, confirms the row was saved; the owner is woken after that. Before you say they were
+  told, read the row's transitions (or use `--verify` for a person's request).
 - **`rig queue show`** — what a row *actually says*. The header is not the body.
 - **`rig queue claim` / `unclaim`** — is this mine and running, or still pending where two agents
   might double-work it. Put it down honestly when it is not yours.
@@ -129,7 +177,9 @@ your context, your compaction and your replacement — and it is the only thing
   `--note` does not reopen a terminal row; terminal-to-active repair requires explicit `--reopen`
   with both `--state` and `--note`.
 - **`rig queue handoff`** — pass work so the close and the create are **one transaction**, instead
-  of closing yours, failing to create theirs, and stranding the work in between.
+  of closing yours, failing to create theirs, and stranding the work in between. A standing sweep
+  checks recently closed rows (a 24-hour lookback) and flags a `handed_off_to` closure whose
+  successor it can't verify; use `handoff` instead.
 - **`rig queue block` / `resolve`** — park a row on a real blocker so it stays **yours and
   visible**, with a plain-language summary and a pointer to what a human must judge; `resolve`
   writes their decision onto the durable record and wakes the owner. **Closing it would be a lie
@@ -176,7 +226,10 @@ relay is a reason to inspect the available routing, not to surrender judgment to
 
 - **`rig workflow specs`** — what can be started here, and which are shipped versus authored by
   this rig.
-- **`rig workflow validate`** — will this spec instantiate at all, before a run finds out for you.
+- **`rig workflow validate`** — will this spec instantiate at all, before a run finds out for you. A
+  step with no allowed exit that can finish it or route onward is reported as `step_cannot_finish`.
+  An allowed mapped exit is valid; in a dependency graph, `handoff` can finish a sink without a next
+  step.
 - **`rig workflow compile <mission>`** / **`instantiate-lifecycle`** — derive one executable graph
   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
@@ -240,23 +293,56 @@ relay is a reason to inspect the available routing, not to surrender judgment to
 
 ## Bringing things into and out of existence
 
-**For a first useful repository change**, tell the kernel operator your goal. It recommends one
-of three teams, `starter` (a Claude Code builder and a Codex reviewer), `workshop` (a rig bundle:
-a lead, a builder, QA and a reviewer) or `factory` (seven agents), and adapts the team to the
-accounts you have. `first-project` is starter's old name. Preview the team, inspect
-`rig up <team> --cwd . --plan`, and follow `docs/reference/getting-started.md`. Verify
-prerequisites and actual runtime readiness before work. Existing Herdr/cmux terminals can present the managed team
-through `rig terminal open`.
+**For a first useful repository change**, tell the kernel operator your goal. After install the
+operator greets the person, asks the goal once and recommends one of three teams: `starter` (a
+Claude Code builder and a Codex reviewer), `workshop` (a rig bundle: a lead, a builder, QA and a
+reviewer) or `factory` (seven agents). It fits the team to the providers on the machine, launches
+on a yes and hands the goal to the team's lead, which makes one light mission and slice for
+continuing work. While explaining the choices it shows each team's graph in the shared TUI. After
+a launch it gives each seat's attach command, names the dashboard as the overview and the lead as
+the place to talk, and asks whether the person can see the team. **If you are the agent installing
+OpenRig for someone**, show them the one-command install's `--dry-run` preview first
+(`docs/reference/getting-started.md` has both forms) and run it on their yes. Then open the OpenRig
+view as the handoff (`rig terminal open` above), keep the kernel running and pass the person's goal
+and folder to the operator; don't build their project yourself. `rig setup` prints that handoff
+even after an incomplete or dry-run result. The `rigs` skill takes an agent outside OpenRig from
+install to a team doing the work. The daemon installs it for the person's own agent
+(`~/.claude/skills/rigs` and `~/.agents/skills/rigs`) and refreshes it on every upgrade; a copy
+added with skills.sh is left alone and never refreshed.
+
+`starter` and `factory` are built in: preview the team, inspect `rig up <team> --cwd . --plan`,
+and follow `docs/reference/getting-started.md`. `first-project` is starter's old name and still
+works. **`workshop` is not built in**, so `rig up workshop` does not resolve. Install it from its
+pinned openrig-world link, `rig up https://github.com/mvschwarz/openrig-world/tree/<commit>/rigs/workshop
+--target ~/rigs/workshop`, taking the commit from
+`https://raw.githubusercontent.com/mvschwarz/openrig-registry/main/registry/workshop.yaml`; fetch it
+fresh, since a web tool's cached copy can be older. The built-in shelf also holds `code-review`,
+`research`, `pm`, `secrets-manager` and `kernel`. Older names are gone: `adversarial-review`,
+`research-team` and `pm-team` became `code-review`, `research` and `pm` with no alias, and
+`first-project-claude`, `first-project-mixed`, `conveyor`, `demo`, `implementation-pair` and
+`product-team` were removed. When authoring a new team, read
+`docs/reference/topology-naming.md`: name the rig for its purpose, pods for domains,
+and members for their roles. Verify prerequisites (Node 22 or 24) and actual runtime readiness
+before work. The starter's Codex model `gpt-6-astra` needs a Codex newer than 0.145; when a Codex
+seat reports that, the operator offers to update Codex and restart that seat. 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.
 
 - **`rig up <source>`** — make a whole rig exist and run: from a spec you wrote, a shipped starter
-  by name, a bundle someone handed you, or a stopped rig.
-- **`rig down`** — stop a rig's seats and take it out of the running set.
+  by name, a bundle someone handed you, a GitHub folder link (pinned to one commit), or a stopped
+  rig. `rig up` with a pod-aware spec on a stopped team's name replaces that team (the earlier one
+  is archived), so check `rig ps --nodes` first. Launch-created `AGENTS.md` or `CLAUDE` files now show in `git status`.
+- **`rig down`** — stop a rig's seats and take it out of the running set. It ends the agents'
+  sessions and any work in progress; don't run it on a live team unless the person asked. In
+  human mode it first prints one line with each agent's last known activity, or “unknown”: a
+  best-effort snapshot, not a record of what was interrupted. With `--host`, a remote teardown
+  that reports errors exits 2.
 - **`rig launch <rig> [seat]`** — one seat is down; start just that one, without disturbing the
-  rest.
+  rest. Add `--plan` to preview it first, locally or with `--host`; a plan is never sent to a
+  daemon older than 0.5.9, which would ignore it and launch.
 - **`rig seat launch <seat> --fresh --reason <why>`** — deliberately create a blank occupant for
   exactly one existing seat. It uses no resume, fork, rebuild, snapshot, or restore packet;
   siblings and durable work stay put, and unmanaged ambiguity refuses.
@@ -301,10 +387,14 @@ version, from checking the environment to a useful report to the OpenRig team.
   `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.
+  really a broken install. It checks Claude and Codex installs, and a login or configured provider
+  credential, the way setup does; it fails for a harness the person doesn't use, which they can
+  ignore. A pass is not "ready": local credential availability is not proof that a provider accepts
+  the credential or that an agent can work.
+  **`rig preflight`** asks whether this machine can run OpenRig at all.
 - **Bare `rig`** — the same TUI for first setup, daemon-down startup and ordinary work.
-  A positive observation of a running rig enters ordinary work without a repeated Startup choice.
-  With no running rig, the chooser remains; slow or unverified detection does not mean stopped.
+  After a successful daemon read it opens the ordinary work views, even when no rig is running;
+  press **S** for Startup. Slow or unverified detection does not mean stopped.
   A late observation never takes navigation away after you have chosen another route.
   **?** Help, **w** Skip and **L** Local reading remain usable during slow probes or loading,
   and when the daemon is down or unverified. Local reading shows selected disk intent with
@@ -335,24 +425,34 @@ version, from checking the environment to a useful report to the OpenRig team.
   actually come back, and for everything that would not, which check fails and what the fix is.
   Use `rig launch ... --snapshot-id <id>` when selection must be exact, and `rig restore status
   <attempt> --rig <rig>` for the derived intended-set receipt after an asynchronous restore.
+  restore-check's per-seat `seat.<s>.queue-file` check is now `seat.<s>.queue-store`.
 - **`rig restore-packet write` / `read` / `validate`** — a seat is about to die or must move
   runtimes; capture what it knows into a portable artifact instead of losing it with the process.
 - **Upgrading is agent-led** — load the shipped `openrig-upgrade` skill for the bounded inspect,
   backup, plugin-refresh, and 0.5.9 instance-migration helpers. The migration is an
   Agent-Operated Workflow: inspect, take one bounded reversible action, verify its effect, and
   continue from the receipt. There is no `rig upgrade` verb, and `rig down` is not part of a
-  continuity-preserving upgrade.
+  continuity-preserving upgrade. After an upgrade, `rig context get reference/whats-new.md` says
+  what behaves differently for an agent; the skill's last step reads it and tells the person.
 - **A seat's `compaction_strategy` is declared, not improvised at the wall.** Pair a threshold-
   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` 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.
+  to plan without changing the seat. Check the selected source and continuity evidence first. A
+  seat can be handed over again into its own pane, so a seat left half-handed-over recovers by
+  running the handover again.
 - **`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 continue <seat>`** — a launch stopped on Claude's bypass-permissions consent dialog.
+  After the person accepts it in the pane, this delivers the pending startup text into the same
+  conversation without relaunching; `rig up` and `rig bundle install` name it when startup pauses.
+  Managed Codex launches turn off Codex's startup update check, so no update notice stops them;
+  updating Codex is the operator's job.
 - **`rig seat set-model` / `stop` / `clean`** — persist the model for later managed resumes, stop
-  exactly one live seat, or clear a dead seat's stale binding. When the topology is right and only
+  exactly one live seat (ending its session and any work in progress), or clear a dead seat's
+  stale binding. When the topology is right and only
   the occupant is wrong, use these seat lifecycle verbs or `rig handover`, not a rig down/up cycle.
   Effective-model detection follows the identity-verified current occupant, not a retained
   predecessor; a `<synthetic>` transcript record is skipped, so a PENDING model check is not a
@@ -367,6 +467,13 @@ version, from checking the environment to a useful report to the OpenRig team.
   retires one; disabling the guard does not replay held messages.
 - **`rig compact-plan`** → **`rig compact`** — who is near the context wall, then act on it.
   **Ordering matters: running `compact` without the plan is guessing which seat needed it.**
+  Managed compaction waits for the seat's restore map before compacting; `rig compact --state`,
+  `--cancel` and `--skip-map` inspect, stop or skip that wait. The `claude-compaction-restore`
+  skill covers writing and reading the map; `claude-compact-in-place` no longer ships. After a
+  managed compaction, refocus waits for the restore request, which names the `refocusing` skill
+  (the daemon installs it globally); three failed refocus attempts in a row for one occupant post
+  one issue to the stream. The turn boundary, restore request and read-depth audit reach a seat
+  that stays quiet after `/compact`; they don't wait for its next turn.
 - **Know what compaction costs before you reach for it.** On some runtimes what comes back has
   enough context left to believe it knows everything and not enough to actually know anything — and
   **the compacted agent is the only one who knows it happened**, while every other seat keeps
@@ -445,14 +552,27 @@ scheme, and nothing downstream can see it.
   System World, topology, and Project World plan. Add `--runtime` to see the composed managed skill
   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.
+  plan-only. Without `--project` it picks the project itself, in order: the only project, the
+  project whose `rigs:` lists the seat's rig, the deepest project root containing the working
+  folder, then the only unclaimed project. It reports `position.selectedBy`. If a step is
+  ambiguous (two projects list the rig, or two roots tie), it stops there and asks for
+  `--project` rather than falling through to a weaker signal. Several projects alone no longer
+  require `--project`. World packs named in `project.yaml`'s `install.worlds`
+  are listed after the System World; read each with `rig context get <ref>`.
   `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.
+  `claude`) or `codex`; explicit invalid values refuse before projection. This does not rename every
+  other command's runtime vocabulary. A catalog skill with uncommitted content blocks only itself:
+  it is skipped and named (`catalog_skill_skipped`, or `selected_skill_skipped` with its selector).
+  With `--runtime`, work-install reports selected skips with exit 1. It inspects by default;
+  `--apply-skills` projects the remaining clean skills while keeping any previously projected copy
+  of the skipped skill. Commit or restore that skill's folder, then apply the projection again.
 - **`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.
+  with it, and how to make the library catch up when you edit one. `sync` also finds a workspace
+  pack created after the daemon started; a daemon restart is no longer needed.
 - **`rig context add <repository-path-or-URL> --git`** — select a pack while retaining its Git
-  source and checkout; `--pack <path>` chooses a repository-relative pack. Inspect that relationship
+  source and checkout; `--pack <path>` chooses a repository-relative pack. It starts a stopped
+  local daemon itself. Initial retrieval is shallow by default; a server that refuses shallow
+  retrieval falls back to a full clone with a warning. Inspect that relationship
   with **`rig context source inspect <ref>`**; it does not fetch or prove agent consumption.
   **`rig context source update <ref>`** explicitly fetches and merges, preserving committed local
   authorship before selecting clean content. Dirty work, conflicts, unavailable upstreams and
@@ -481,6 +601,7 @@ scheme, and nothing downstream can see it.
 - **`rig context recap-write`** — a durable, seat-scoped RECAP beside LEARNED with a
   collision-safe superseded chain, written at the handover or compaction boundary; restore
   packets carry the pointer, so a successor reads decisions-with-rationale instead of scrollback.
+  Write it with this command, not a file tool, so earlier recaps are kept.
 - **`rig project classify` / `list` / `show`** — turn a raw observation into a routed, typed,
   deduped record instead of hand-creating a row from a hunch.
 
@@ -493,7 +614,10 @@ working arrangement becomes something someone else can instantiate.
   file well-formed, would it boot *on this host*, and **will the agents it launches actually know
   anything when they arrive**. The third is the one people skip. Unknown structural keys refuse
   with their path instead of being normalized away. Use `rig spec validate --help` for its current
-  behavior and options.
+  behavior and options. For Pi seats, preflight reports the Pi version against the tested
+  baseline, and at launch the runner says whether the seat has a stored sign-in or provider key
+  (advisory; launch continues). A provider key reaches a Pi seat only when its name is in
+  `recovery.provider_auth_env_allowlist`; `MINIMAX_API_KEY` serves `minimax/<id>` models.
 - **`rig context trace --pod <pod>`** — walk the context chain through instance → rig → pod → seat
   when the pod altitude matters.
 - **`rig specs show` / `preview` / `add` / `sync` / `rename` / `remove`** — where a spec lives,
@@ -505,7 +629,29 @@ working arrangement becomes something someone else can instantiate.
   workspace declaration to an existing rig without changing topology; `rig export` preserves it.
 - **`rig bundle create` / `inspect` / `install` / `history`** — one file that rebuilds a rig on a
   machine with none of its content, what is inside one before you trust it, and what has actually
-  been installed here.
+  been installed here. `create`, `inspect` and `install` also take a GitHub folder link and pin it
+  to one commit, as `rig up <link>` does. `inspect`, and the view shown before `install` or `rig up`, list the
+  permission posture, startup actions, writes, outside domains and the author's preconditions
+  (shown, never run). A bundle can declare configurations: `rig bundle configurations <spec>`
+  lists them, and `--preset <name>` or `--seat pod.member=runtime` picks one. A bundle from a link
+  installs into `--target` (default: the current folder); a local archive needs `--target`.
+  `--cwd <dir>` sets every seat's working folder, separately from the install folder. For a
+  pod-aware (schema 2) bundle, skills, plugins and context packs are routed before any seat
+  launches, with failures listed in `routingFailures`, so there is no sync step after the install;
+  a legacy (schema 1) bundle still routes them after a completed install. Re-installing a team that
+  is already installed says what is installed and offers to use it, stop and replace it, or
+  cancel. For a pod-aware bundle, a running team with the same name is refused before target files
+  are written, and a stopped one is replaced: the earlier team is archived, and reinstalling into its
+  own install folder first copies each differing file to a backup. A legacy bundle doesn't replace
+  a stopped team, and with `--force` it can run its approved install steps before its name check
+  fails. Read those choices before reaching for `--force`. The manifest safety check always runs,
+  even with `--skip-version-check --force`.
+- **`rig bundle check <folder>`** — a local, advisory check of a team you are authoring; each
+  finding names its file. `rig bundle create` and `rig up <link>` name the bundle after
+  `rig.yaml`'s `name`.
+  `rig bundle create --context-pack <dir>` and `--project-dir <dir>` carry a context pack or a
+  project with it, and `docs/reference/publishing-a-rig-bundle.md` explains how to share it on
+  openrig.dev/rigs.
 - **`rig bootstrap`** — spec file to running rig in one command. **`rig requirements`** — what this
   spec needs installed first.
 - **`rig plugin show` / `used-by` / `validate`** — what a plugin actually gives an agent, and
@@ -533,6 +679,7 @@ reaching them is ordinary work rather than an escalation.
   request, then boundedly inspect its transport receipt. Posted means posted, not read;
   pending, failed, or indeterminate delivery leaves the row intact. Inspect the same row's
   transitions before retrying. `rig send` remains agent-terminal delivery only.
+  `--human-questions-file` adds clickable decision questions.
 - **When project policy calls for human judgment or an update, load `messaging-the-human`.**
   Use `rig context get skills/core/messaging-the-human/SKILL.md` for a complete decision brief,
   related supplemental detail and explicit quiet-update intent. An FYI creates no approval
@@ -563,6 +710,39 @@ your circumstances is configuration, and the ones that are not, another agent ca
   actually in effect: discovers custom policy specs, validates refs (malformed can never read as
   valid OR absent), shows what would apply. The older `rig policy list|show|current|apply` forms
   remain as aliases with the same output.
+- **What a team seat may do without asking.** Claude seats in a team that OpenRig launches run
+  `rig` commands, project reads and common test commands without a prompt; lifecycle commands
+  (`rig up`, `rig down`, `rig seat stop`, `rig daemon stop` and similar) ask. Routine `rig`
+  commands used to prompt, so don't widen permissions to avoid prompts. Codex team seats run
+  `workspace-write` with the workspace root and their pod's state folder writable. When Codex's
+  own config check shows a default-sandbox seat is eligible, OpenRig turns its network access on
+  (`network_access = false` keeps it off); if that check can't be read, the launch is left
+  unchanged. So full bypass is usually not needed just to reach the daemon; this was not checked
+  with real logins or on Linux. Explicit author or person policies, explicit seat selections and
+  named Codex profiles turn these team defaults off, and native ask and deny rules still apply.
+  When setting up a team, the operator recommends keeping this default. It offers to remember
+  extra OpenRig commands in your native settings, for this project or user-wide, only when you
+  want that, and stricter rules and Claude's lifecycle asks remain. The `openrig-core` plugin's
+  `applying-a-permission-policy` skill has the procedure. In a Claude team seat, help on lifecycle
+  commands (`rig down --help`, `-h`) and equivalent spellings of allowed commands run without a
+  prompt; the lifecycle actions still ask, and pipelines, command substitutions, redirects and
+  heredocs are left to Claude's own check. The kernel operator's Claude session also runs routine
+  inspection (Python, command lookup, `cd`, text helpers) and WebFetch without prompts. Known
+  limit: Codex team seats are not yet asked before lifecycle commands.
+- **`permission_policy: builtin:auto`**, and a fixed order for a seat's first launch:
+  `rig seat set-permissions`, then the member policy, then the rig policy, then the system floor.
+  See `docs/reference/rig-spec.md#built-in-permission-policies`.
+- **`--non-interruptive`** on `rig up` or `rig bundle install` accepts Claude's bypass-permissions
+  warning and hides Codex's full-access notices for seats that already launch with full bypass. It
+  does not select bypass or change permission policy or native settings, so other seats ask as
+  before. The choice is saved for that team and carries through restores and handovers;
+  `--no-non-interruptive`, with the team down, clears it. A rig spec can declare `non_interruptive: true` beside its
+  permission policy: an explicit flag wins over it, and it wins over the operator default
+  `launch.non_interruptive`. The before-install view shows it as
+  `posture[].nonInterruptiveDefault`.
+- **Smaller settings worth knowing:** per-seat `effort`, passed to Claude as `--effort` and to
+  Codex as `model_reasoning_effort`; and `runtime.readiness_timeout_seconds` for seats that start
+  slowly.
 - **`rig policy cite` / `defaults`** — what posture the operator is in: how autonomous to be, how
   loudly to report, whether to batch permission questions or block on them. **This declares a
   posture; it does not grant or deny permissions** — the harness's own settings are the control
@@ -590,16 +770,30 @@ your circumstances is configuration, and the ones that are not, another agent ca
 - **`rig env`** — the real services behind a rig: are they up, what are they saying, how do you
   stop them without killing the rig.
 - **`rig setup`** — what OpenRig would change about this machine, shown before it touches anything.
+  It installs herdr by default on macOS and Linux (`--no-herdr` declines; if the install fails,
+  views fall back to plain tmux) and on a Mac offers Ghostty once (`--ghostty` / `--no-ghostty`).
+  It no longer installs cmux; an existing cmux still works.
 - **`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 --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.
+- **`rig tui`** — the interactive view over rigs, pods, seats and specs. `rig` and `rig tui` open
+  the status dashboard, not a conversation with an agent: talk to the operator through
+  `rig terminal open saved:kernel --window`, which opens the dashboard and conversations together.
+  Open it as the step after install or start, and whenever the person wants their agents back
+  (see `rig terminal open` above); do not finish by showing a table or suggesting a command for
+  the person to type.
+  Only if the window cannot open, `rig tui --shared` is the dashboard-only fallback:
+  it attaches to the existing kernel terminal; Ctrl-b then d detaches, and no missing
+  seat or terminal is implicitly launched. Explain the failure and help with the
+  chosen fallback. Plain `rig tui` remains a separate dashboard.
+  On an empty command line every typed command reaches the line whole and `j`/`k` move the
+  selection; the footer toggle is `F`, and a selected Scopes view's mini-requirements and
+  narrative keys are `M` and `N`.
   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.
   In **Specs**, kind groups start collapsed and expand explicitly. Selection previews purpose,
-  contents and provenance; Enter opens details.
+  contents and provenance; Enter opens details. A rig spec opens as a graph with **Launch**, which
+  asks for a working folder and then runs the real `rig up`.
   **View current source** reads disk within the explicitly configured readable roots. Relative
   Markdown links resolve against that source; headings open with a labelled starting point.
   Escape or `back` restores the caller's selection and scroll. Detail uses the full width on
@@ -629,7 +823,9 @@ your circumstances is configuration, and the ones that are not, another agent ca
 - **`rig skill loadout --runtime <claude-code|codex>`** — inspect the exact catalog revision,
   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.
+  unowned collisions. Launch now delivers a selected plugin's skills into `.claude/skills/` or
+  `.agents/skills/`, so don't copy them by hand; read the `plugin_skill_*` warnings if one is
+  missing. TDD is no longer a default skill.
 - **`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`.
@@ -699,6 +895,6 @@ deliberate writing.
 
 **`rig --help`**, then `rig <verb> --help`.
 
-Eighty-one verbs ship, and this page named most of them once. **You will not remember which — you
+Eighty-seven verbs ship, and this page named most of them once. **You will not remember which — you
 are meant to remember only that the list is long enough to be worth reading before you build
 anything.** The question is never *how do I write this*; it is **does this already exist**.