@openrig/cli 0.6.4 → 0.6.6

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

@@ -1,13 +1,14 @@
 # Help your user get unstuck
 
 This page is for an agent whose user says OpenRig isn't working. It is the one place OpenRig keeps this guidance. The
-copy installed with OpenRig matches that installed version. Read it with `rig context get help`. If `rig` won't run,
-open `daemon/docs/reference/help.md` inside the installed `@openrig/cli` package (under `npm root -g`); in the source
+copy installed with OpenRig matches that installed version. Read it with `rig context get help`, which needs a running
+daemon. If `rig` won't run or the daemon is down, open `daemon/docs/reference/help.md` inside the installed
+`@openrig/cli` package (under `npm root -g`); in the source
 repository the same file is `docs/reference/help.md`. The same text is online at
 [openrig.dev/help/agents](https://www.openrig.dev/help/agents), next to the ways people can contact OpenRig support.
 
 Each guide this page links to is installed too. Load one only when you need it, with the `rig context get` address
-shown beside its link; the same files sit beside this one in `daemon/docs/reference/`.
+shown beside its link where there is one; every linked file also sits beside this one in `daemon/docs/reference/`.
 
 Start with what your user was trying to do. Try the next useful step, check the result, and if you can't finish,
 prepare a message to OpenRig support at **hello@openrig.dev**. Your user doesn't need a GitHub account.
@@ -23,7 +24,8 @@ 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.
+instructions to reset the machine. 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
 command and error. Leave unknown values unknown. A working daemon or a passing diagnostic is not required to ask for
@@ -33,8 +35,9 @@ help.
 
 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
-`https://github.com/mvschwarz/openrig/blob/v<version>/docs/releases/v<version>.md`, using the version from
-`rig --version`. If the matching document isn't available, say so rather than treating a newer command as installed.
+`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
+rather than treating a newer command as installed.
 
 ## Find your next step
 
@@ -44,6 +47,22 @@ Supported platforms are macOS and Linux. Native Windows is not supported yet, an
 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.
 
+### 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.
+
 ### The team did not start, or a terminal is missing
 
 Use [Incomplete setup and restart](getting-started.md#incomplete-setup-and-restart)
@@ -67,6 +86,14 @@ and `rig ps --nodes --rig <rig-name>`, then compare the reported state with what
 A waiting prompt, a failed launch and an agent working behind a stale status need different next steps. Repeatedly
 clearing attention doesn't fix an underlying readiness problem.
 
+A fresh seat stopped at a native prompt (Claude's bypass-permissions warning, a login or a folder-trust question)
+keeps its startup context. `rig up`, `rig bundle install` and `rig ps --nodes` print "Startup attention" or "Startup
+details" for it, ending with the command to run. Once your user has answered the prompt in that seat's terminal,
+`rig seat continue <seat>` delivers the context in the same conversation, without relaunching. If it reports an
+unknown outcome, check `rig seat status <seat>` before trying again. For a rig whose seats bypass permissions,
+`--non-interruptive` on `rig up` or `rig bundle install` avoids Claude's warning and Codex's notices in the first
+place; see `non-interruptive-mode.md` beside this file.
+
 ### You can't tell which instance or configuration is involved
 
 Read [instance layout](instance-layout.md) (`rig context get reference/instance-layout.md`) and
@@ -78,12 +105,15 @@ involved before proposing changes.
 Compare the harness version and what you actually observe before attributing a failure to one of these. Check the
 issue's current status; a similar symptom alone is not a diagnosis.
 
-- Claude seats reported as needing attention after a restore: [#86](https://github.com/mvschwarz/openrig/issues/86).
-- Claude usage limits are not detected: [#98](https://github.com/mvschwarz/openrig/issues/98),
-  [#99](https://github.com/mvschwarz/openrig/issues/99).
-- Codex prompt variants not recognised as ready: [#79](https://github.com/mvschwarz/openrig/issues/79).
+- Claude seats reported as needing attention after a restore: [#86](https://github.com/mvschwarz/openrig/issues/86),
+  [#273](https://github.com/mvschwarz/openrig/issues/273).
+- Claude usage limits may not be detected: [#99](https://github.com/mvschwarz/openrig/issues/99).
+- Codex prompt variants not recognised as idle: [#79](https://github.com/mvschwarz/openrig/issues/79).
 - Codex asks about hook trust at first launch: [#17](https://github.com/mvschwarz/openrig/issues/17), not reproduced
   by the team.
+- 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).
 
 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.4"
+version: "0.6.6"
 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.4"
+version: "0.6.6"
 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

@@ -40,7 +40,8 @@ one command away. Your memory of the fleet is a claim about the past.
 - **`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 and current authored planning guidance with its
-  source. Mission and wave inspection shows admission and exit guidance; wave/slice details
+  source (`--project <name> --mission <id>` reads a mission in another catalogued project, not
+  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
@@ -239,10 +240,12 @@ 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**, 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
+**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`.
 
 **Need a small team now, without authoring YAML?** Start with `rig create`, then use `rig grow`
@@ -354,6 +357,14 @@ version, from checking the environment to a useful report to the OpenRig team.
   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
   divergence.
+- **`rig seat set-permissions <seat> --mode <mode> --reason <text>`** — select one seat's native
+  permission mode for its future managed launches; it relaunches nothing, and `inherit` clears the
+  selection. `rig seat status` reports the selection, but a status read does not prove the
+  running process enforces it.
+- **`rig seat set-typing-guard <seat> --enabled true|false --reason <text>`** — protect a human's
+  draft in that seat: automatic input is retained instead of typed while the guard is on.
+  **`rig seat held-messages`** lists what was retained and **`rig seat retire-held-message`**
+  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.**
 - **Know what compaction costs before you reach for it.** On some runtimes what comes back has
@@ -481,7 +492,8 @@ working arrangement becomes something someone else can instantiate.
 - **`rig spec validate` → `preflight` → `audit`** — three different questions, in order: is the
   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.
+  with their path instead of being normalized away. Use `rig spec validate --help` for its current
+  behavior and options.
 - **`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,
@@ -547,9 +559,10 @@ your circumstances is configuration, and the ones that are not, another agent ca
   and put it back exactly as it was, or additively lay down the canonical project scaffold on a
   box that has none. Instance startup uses the same additive initializer for the surrounding
   `state`, `context`, `skills`, `topology`, and operational roots.
-- **`rig policy list` / `show` / `current`** *(v0.5.2)* — what permission policy is actually in
-  effect: discovers custom policy specs, validates refs (malformed can never read as valid OR
-  absent), shows what would apply.
+- **`rig policy permissions list` / `show` / `current` / `apply`** — what permission policy is
+  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.
 - **`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
@@ -606,9 +619,10 @@ your circumstances is configuration, and the ones that are not, another agent ca
   services and human routes. Dated verification does not prove delivery. `timezone` gives
   persistent local-time guidance.
   **?** opens full-screen Help with command grammar and examples; Escape returns to the caller.
-  **`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 tui commands`** lists everything it can do without launching it. The web UI is off by
+  default; `rig config set ui.enabled true` plus a daemon stop and start turns it on. **`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.