@openrig/cli 0.6.4 → 0.6.6

package/daemon/docs/reference/health-diagnosis.md

@@ -115,9 +115,12 @@ outcome list affirms zero outcomes, not failed discovery. `false-positive`
 clears the suspicion without inventing a denominator when no missing facts remain.
 A false-positive assessment that still names missing facts stays indeterminate
 and does not close the episode interval. `indeterminate` supplies
-no outcomes and names the missing fact in `missingFacts`. Required references
-must resolve inside the workspace; extra evidence beyond the initial packet is
-allowed. The receipt retains the actual actor, timestamp, identity provenance,
+no outcomes and names the missing fact in `missingFacts`. `established` needs
+`boundedAuthority` set to true or false (not null) and no missing facts; while an
+established census still confirms the signal, a `false positive`, `insufficient
+evidence` or `resolved` verdict is refused. Required references must resolve
+inside the finding's resolved project folder (the configured workspace when no
+project resolves); extra evidence beyond the initial packet is allowed. The receipt retains the actual actor, timestamp, identity provenance,
 source basis, and evidence hashes. A changed basis refuses a stale submission.
 Later evidence changes make confirmation indeterminate rather than preserving
 a false ratio. Outcome meaning remains attributed agent judgment.
@@ -131,10 +134,15 @@ traffic in the same family starts a new episode. Repeated reads never advance
 these boundaries. One occurrence and the existing owner cooldown apply to each
 episode; a disposition stops repeated requests.
 
-This bounded source covers explicitly linked project or mission work: at most 2,000 touched
-qitems, 200 roots, 1,000 members / 10,000 transitions per family, 200 workflow
+This bounded source reads every handoff family touched in the window; only
+explicitly linked project or mission work resolves a scope. Its bounds: at most 2,000 touched
+qitems, 1,000 members / 10,000 transitions per family, 200 workflow
 receipts, 200 declared slices, and 100 proof files per selected slice. Overflow
-refuses visibly. Context files are bounded to 64 KiB. A lineage beginning before
+refuses visibly. When more than 200 families (roots) were touched, it evaluates the
+200 with the most transitions in the window, then by lineage ID, and reports the
+result as partial coverage with the total and omitted counts. Omitted families
+were not evaluated, so having no finding for them is not a healthy verdict.
+Context files are bounded to 64 KiB. A lineage beginning before
 the retained window remains indeterminate, with the missing interval named.
 Project planning does not require a successor mission: an explicit project identity
 resolves its current context, with mission and phase absent unless evidenced.
@@ -370,7 +378,12 @@ A consumer such as a later Herder plugin reads `GET /api/health` and
 `GET /api/health/:findingId`, or the identical `rig health --json` and
 `rig health explain <finding-id> --json` records. The record schema is
 `openrig.health/v0alpha1`; list metadata is `openrig.health-list/v0alpha1`.
-Preserve ID, status, policy version, time window, freshness, evidence and
+For a source that bounds its input, list metadata also carries `coverage`
+(`source`, `evaluatedAt`, `unit`, `total`, `evaluated`, `omitted`, `limit`,
+`order`, `partial`). A source that failed or hit a limit appears instead as
+`status: "unavailable"` with its `reason`, and its findings are left out.
+`rig health policy` reports the scheduled evaluation's coverage under
+`engine.lastEvaluation.coverage`. Preserve ID, status, policy version, time window, freshness, evidence and
 threshold together. There is no health score or implicit remediation authority.
 The default list excludes cleared records; explicit cleared queries and exact
 ID reads retain them while the source can still project them. A recurrence after
@@ -392,7 +405,9 @@ Behavioral and epistemic categories intentionally have no detector. Review
 carousel, redundant wakes, stale directives and scope admission have typed
 evaluators and replay controls, but the live source does not infer their missing
 candidate-change, rescue, directive-conflict or admission-authority facts.
-Untagged work and undeclared relationships remain outside passive ceremony
+Untagged work is still read: a family whose scope can't be resolved shows as an
+indeterminate instance-scope finding that names the unresolved scope and can't
+start a diagnosis. Undeclared relationships remain outside passive ceremony
 coverage; normal tagged work no longer requires a special outcome census. A small lineage below the configured threshold may still deserve an
 agent's inspection; the threshold is a conservative admission rule, not a
 definition of good process.

package/daemon/docs/reference/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/docs/reference/host-resources.md

@@ -0,0 +1,61 @@
+# Host load and transcript capture
+
+Use `rig ps --resources` to inspect the serving host, or add `--host <id>`
+for one registered HTTP/SSH host. `--json` returns the same measurements for
+operators and monitoring tools. This view is host-scoped; rig/node filters and
+multi-host fan-out do not apply. Ordinary `rig ps` output is unchanged.
+
+The view reports available CPU count, host load averages (1/5/15 minutes),
+load divided by CPU count, running seats, the number of rotating seats and how
+many of them are backed off, and transcript capture attempts, failures, UTF8
+bytes and elapsed capture time for currently rotating seats.
+Load is not CPU utilization; capture elapsed time includes waiting for tmux,
+and is not daemon CPU time. Load averages are unavailable on Windows, rather
+than reported as zero. Counters reset when a rotation is restarted/stopped or
+the daemon restarts, so they are observations rather than a durable billing log.
+When no seat is capturing, the active interval, idle ceiling and line count are
+unavailable (`null` in JSON), not zero.
+
+## Reduce idle capture cost
+
+Transcript rotation still captures the bounded trailing buffer. When successive
+captures are unchanged and tmux exposes an unchanged current-window activity
+hint, capture backs off exponentially to a derived ceiling. With the default
+2-second active interval and 1-second settings timer, the effective ceiling is
+3 seconds: the 10-second freshness window minus the 1-second activity-hint
+deadline, 5-second capture-result deadline and 1-second timer spacing. The
+ceiling is capped at 6 seconds but never below the configured active interval.
+This scheduling budget is not a CPU or child-process lifetime bound; the result
+deadline does not cancel an unfinished capture. One shared tmux
+activity read wakes idle rotations; a changed hint restores the active cadence.
+Missing/failed hints retain the configured full-capture cadence. A hint read
+that takes longer than one second becomes unknown without starting additional
+metadata probes while its underlying call is still pending. Periodic full
+capture reconciles output even when a hint fails to change (tmux timestamps have
+one-second resolution). Longer configured active intervals retain that interval
+instead of silently increasing capture frequency.
+
+This does not change provider readiness, delivery guards, seat activity or queue
+state. Capture activity is not proof an agent is healthy or finished. As before,
+transcripts are bounded trailing snapshots, not lossless terminal archives: an
+output burst larger than retained tmux scrollback or the configured line limit
+can exceed the saved trail. Interactive terminal streaming is unchanged.
+
+## Change capture settings without restarting
+
+```bash
+rig config set transcripts.poll_interval_seconds 3
+rig config set transcripts.lines 2000
+rig ps --resources
+rig config reset transcripts.poll_interval_seconds
+```
+
+Running rotations reread shared settings at most once per second and adopt the
+next valid policy without starting overlapping captures. Intervals accept whole
+seconds from 1 to 3600; trailing lines accept integers from 1 to 1000000. The
+existing environment variables take precedence over file settings. Malformed
+intermediate JSON retains the last usable policy, is shown in the resource view,
+and is retried; normal config
+writes reject invalid values. Changing `transcripts.enabled` or
+`transcripts.path` still requires a daemon restart. This feature does not impose
+CPU quotas or allocate build slots.

package/daemon/docs/reference/instance-layout.md

@@ -104,3 +104,14 @@ runtime reads for compatibility. Treat the two-home state as an explicit
 limitation: use the live spec-library commands to determine where a spec is
 served from, and do not infer convergence merely because the canonical
 directory exists.
+
+Config updates publish a complete replacement file atomically where directory
+permissions and the filesystem allow it. On POSIX systems, replacement preserves
+the existing owner, group, and read/write/execute permission bits. If creating or
+preparing the replacement, or renaming it, fails with `EACCES`, `EPERM`, or `EBUSY`,
+the stores write the writable target in place, preserving compatibility with
+unwritable directories and single-file bind mounts. This fallback is not atomic
+and retains the previous partial-write risk. Read-only config files are refused.
+Other errors, including `ENOSPC`, leave the original file intact on the atomic
+path. Atomic replacement does not carry extended ACLs or other inode metadata;
+a hard-linked second name continues to refer to the previous file.

package/daemon/docs/reference/inventory-request-diagnostics.md

@@ -0,0 +1,75 @@
+# Inventory request diagnostics
+
+The private slow-operation log can correlate explicitly marked inventory reads.
+This diagnoses future observations; it does not repair a timeout or establish the
+cause of an earlier uncorrelated request.
+
+Send exactly one `X-OpenRig-Diagnostic-Attempt` header containing a fresh lowercase
+UUIDv4 on a `GET /api/rigs` or `GET /api/rigs/:id/nodes` request. The token is only a
+correlation hint. It grants no authority, triggers no retry, and changes neither
+the response nor its timeout. Invalid or duplicate tokens are ignored by the
+observer. Do not copy the token to incidental identity or health checks.
+
+Records use `schema: openrig.request-phase/v1` in the existing
+`logs/slow-operations.jsonl`. Each process has an observation `epoch` and sequence
+`seq`. An activation record carries the installed build stamp (`semver`,
+`commit`, `dirty`, `builtAt`; each is null in an unstamped development build).
+Each admitted request gets a distinct
+`serverRequestId`, even if a caller reuses an `attemptId`. Routes are recorded as
+`rigs_list` or `rig_nodes`, never a rig name or full URL.
+
+The phases are:
+
+- `node_arrival`: the existing Node HTTP request listener ran. This is after HTTP
+  parsing and JavaScript scheduling, not a socket-arrival timestamp.
+- `hono_enter` / `hono_exit`: application middleware started/finished.
+- `handler_enter` / `handler_exit`: the actual inventory handler started/finished.
+  Gate rejection or read-through may have no local handler entry.
+- `sql_begin` / `sql_end`: the root list's SQLite prepare/read, excluding row mapping.
+  Other node-inventory queries are not individually traced.
+- `response_finish`: Node completed its server-side response writes; this does not
+  prove that the client consumed the body.
+- `response_close`: records `headersSent`, `writableFinished` and status. A normal
+  close after finish is not failure. A premature close does not identify its cause.
+- `request_aborted`: only when Node emits that incoming-request event. A GET client
+  timeout often appears as response close instead. Handler work can finish later.
+- `trace_expired`: diagnostic state expired; the request was not canceled.
+
+`elapsedMs` is process-local monotonic time since observation activation;
+`requestElapsedMs` is since the request event. `utc` is a dated anchor. Never
+subtract monotonic times across processes. A client's useful counterparts are its
+logical start, actual fetch invocation, headers received, body completion, signal
+abort and final outcome. Fetch invocation does not prove a socket write.
+
+The existing 250 ms event-loop tick provides bounded recent timing context and
+`event_loop_gap` records for tick intervals of at least 500 ms. The gap is reported
+when the loop resumes. An indefinite stall or killed process cannot report its
+end. This does not change the existing lifetime histogram or health verdict.
+
+Diagnostic limits: 128 admitted requests per monotonic minute, 128 active traces,
+16 distinct phases per trace, 60-second observation lifetime, 40 recent ticks,
+1 KiB per record and 1024 outstanding diagnostic writes. Overflow drops diagnostic
+observations, never requests. The existing 1 MiB log plus three rotated files and
+0600 file modes apply. The worker writes asynchronously; HTTP observation never
+waits for fsync or the synchronous slow-operation BEGIN barrier.
+
+Records carry cumulative `rejected` (admission refused), `expired` and
+`observerErrors` counters and writer
+`coverage` counters (`offered`, `enqueued`, `dropped`, `acknowledged`, `failed`,
+`pending`, `recorderHealthy`). Writer counters describe the state sampled for that
+record, not an acknowledgment of that record itself. Retained epoch/sequence
+ranges can be read from the current and rotated logs; the log is not an archive.
+A missing activation/tail, sequence loss, recorder failure, overflow, expiry or
+rotated-away interval makes the corresponding coverage incomplete. Source tests
+without the Node raw-request binding cannot establish Node arrival.
+
+Missing arrival is unknown by default. Even a complete covered interval only
+establishes that no matching JavaScript request event was observed there; it does
+not distinguish a client that never sent from network, parser or event-loop delay.
+HTTP status at handler exit is a prepared response, and status at finish/close is
+server-side state. Neither replaces the client's header/body receipt.
+
+The new format contains no payloads, auth or raw identity headers, URL parameters,
+SQL text, bind values, native identifiers or raw exception messages. Legacy
+slow-operation records keep their existing format: their `outcome: ok` indicates
+completion of the observed operation and is not an HTTP-success assertion.

package/daemon/docs/reference/knowledge-maturity.md

@@ -91,7 +91,9 @@ shipped vocabulary (four rungs plus two exits):
 `wip | provisional | established | canonical | superseded | retired`
 
 `superseded` must name its successor; `retired` means do-not-use. These are the ONLY
-valid values — invented stages (shape, shaped, draft) are rejected. Items minted under
+valid values — `rig scope slice stage` and `rig scope mission stage` reject invented stages
+(shape, shaped, draft) and a `superseded` without a successor; context-pack manifests and
+lore frontmatter aren't checked. Items minted under
 new conventions carry a stage from birth: labeling from day one is free, retrofitting
 is archaeology.
 

package/daemon/docs/reference/legacy-topology-migration.md

@@ -3,8 +3,10 @@
 For rigs whose hand-authored context predates the chain-file convention and
 lives at the legacy location (`~/.openrig/shared-docs/rigs/<rig>/`, or
 `$OPENRIG_SHARED_DOCS_ROOT/rigs/<rig>/`). Nothing here is destructive: the
-legacy tree is left in place, reads keep working throughout (the walker's
-advisory-emitting fallback), and every copy is no-clobber.
+legacy tree is left in place, `rig context trace` keeps reading it at the rig and
+seat levels throughout (with an advisory), and every copy is no-clobber. The refocus
+trace, `seat:` profile atoms and handover priming read only `topology.root`, so
+they see these files only after migration.
 
 ## The path, with exact commands
 

package/daemon/docs/reference/lore-routing.md

@@ -84,7 +84,9 @@ line so attribution remains visible when the resolver returns only that section.
 
 ## Addressing and composition
 
-Lore uses the existing `seat:` grammar and an explicit rig-and-seat read grant.
+Lore uses the existing `seat:` grammar and an explicit rig-and-seat read grant
+(`rig context profile <pack> --situation <fresh|handover|post-compaction> --rig <rig> --seat <seat>`,
+where the grant needs both `--rig` and `--seat`).
 The address says which file or section to read; the grant says whose seat tree
 the address is relative to. No grant means no read.
 

package/daemon/docs/reference/mission-install.md

@@ -196,7 +196,9 @@ The layers compose from surfaces that already exist; no new mechanism is require
   retains `claude-code`. Profile defaults from `OPENRIG_RUNTIME`, otherwise
   Claude; work-install requires the flag to inspect or apply skills.
 - Delivery: `rig walk <seat> --through-profile world-public --profile <profile>
-  --situation <situation> ...` applies the already-inspected profile;
+  --situation <situation> ...` applies the already-inspected profile (walk's
+  seat grant is `--seat-grant`, and its `--runtime` takes `claude` or `codex`,
+  defaulting to `claude`, so a Codex profile needs `--runtime codex`);
   `--through <files> --pace <interval>` remains the raw byte-walk path. Paced
   sends naming addressed reads serve pointer-walks.
 - The delta: a dated markdown file beside the seat's recap; verified by reading it.

package/daemon/docs/reference/non-interruptive-mode.md

@@ -0,0 +1,60 @@
+# Non-interruptive mode
+
+Use `rig up <source> --non-interruptive` or `rig bundle install <archive-or-link> --non-interruptive`
+to accept supported harness first-launch warnings for this rig. Sessions remain interactive.
+This does not sign in to a provider or change any seat's permission policy.
+
+The option applies only to seats whose resolved launch posture is `full_bypass`.
+This must be declared through `builtin:yolo`, a `full_bypass` flag policy, or an explicit `full_bypass` selection;
+ambient `OPENRIG_YOLO` alone without an attached policy is not covered.
+
+- Claude Code receives `--settings '{"skipDangerousModePermissionPrompt":true}'`, accepting its bypass-permissions warning.
+  A seat with an explicitly selected native permission mode other than `bypassPermissions` doesn't get it.
+- Codex receives per-launch `-c notice.…=true` overrides for the full-access and GPT-5.1 migration notices.
+  The separate GPT-5.1-Codex-Max migration notice is not suppressed.
+- Pi's existing launch flags are unchanged.
+
+OpenRig saves the choice on the rig. Later launches, restores, forks and handovers keep it, including
+when the option is omitted. To turn it off, first stop the rig with `rig down <rig-name>`, then run
+`rig up <rig-name> --existing --no-non-interruptive`. The choice is cleared for this and subsequent
+launches. If the rig is still running, the command is refused before the choice changes. `--plan`
+changes nothing. Disabling the mode does not erase acceptance that a person previously saved in the harness.
+Turning it on for an existing rig works the same way: `rig down <rig-name>`, then
+`rig up <rig-name> --existing --non-interruptive`. Rigs created before this option existed start with it off.
+
+For an operator default on **new rigs**, use `rig config set launch.non_interruptive true`, or set
+`OPENRIG_LAUNCH_NON_INTERRUPTIVE` in the daemon's environment (it overrides the config file).
+The default is false; an explicit positive or negative command-line flag overrides it. Existing rigs
+keep their saved choice when the operator default changes. On a remote install the receiving daemon's
+default applies.
+
+`rig up` and `rig bundle install` print what happened as warnings: "Non-interruptive mode is saved for this rig…"
+when it is on (also on each restore), "Non-interruptive mode is off for this rig's launches…" when you turn it off,
+and, for each affected seat, "Non-interruptive: OpenRig accepted Claude's bypass-permissions warning" or "…hid
+Codex's full-access and GPT-5.1 migration notices… no warning-acceptance settings were written."
+
+A bundle's before-install view (`rig bundle inspect`) says when this option is available for its full-bypass
+Claude and Codex seats, and that Claude Code asks once to accept its warning otherwise. See
+[bundle formats](bundle-formats.md).
+
+This feature writes no warning-acceptance settings to Claude or Codex files. It uses the launch-flag
+surfaces checked in Claude Code 2.1.282 and Codex 0.153.4. Other notices introduced by later harness
+versions, sign-in, and harness preconditions can still require attention. Ordinary launches without
+an opt-in keep their existing behaviour.
+
+## Bundle or rig default
+
+A pod-aware `rig.yaml` may declare `non_interruptive: true` alongside its
+permission policy. This saves the choice on the installed rig without requiring
+a CLI flag. Explicit `--non-interruptive` or `--no-non-interruptive` wins over
+the spec; a declared boolean wins over the machine's `launch.non_interruptive`
+default. A declaration of `false` is distinct from omission. Exports include
+`non_interruptive: true` when enabled; disabled or unset choices omit the key
+because saved state does not distinguish their origin. Restores of the existing
+rig retain its saved choice.
+
+The before-install view reports this declaration as
+`posture[].nonInterruptiveDefault` for full-bypass Claude/Codex seats, separately
+from `nonInterruptive: available`. It leaves `nativeEffect: unknown`: explicit
+launch choices, sign-in and unsupported harness notices still apply. This field
+does not broaden the rig's permission policy or add warning flags to Pi.

package/daemon/docs/reference/planning-dial.md

@@ -50,4 +50,5 @@ Scope research to the unknown that could change the plan; scope an adversarial
 pass to the failure modes the author may miss. Record the questions resolved and
 the resulting design changes so the owner can judge the value of the selected
 rung. Run planned research before build dispatch, while its answers can still
-shape the spec.
+shape the spec. Record the chosen rung in the slice's frontmatter as
+`approved-spec-dial:`; `rig view show execution` shows it as `planning_dial`.

package/daemon/docs/reference/product-journey-sdlc.md

@@ -1,8 +1,8 @@
 # Product-journey SDLC components
 
 This is a reusable menu for building the smallest complete user outcome. A
-mission or slice selects only the components its work needs and records their
-order in mission/slice YAML. This is **not a mode, pipeline, topology, rig
+mission or slice selects only the components its work needs and records them,
+with any explicit edges between them, in mission/slice YAML. This is **not a mode, pipeline, topology, rig
 shape, or mandatory gate set**. If no composition is present, use the light
 Part A flow in `sdlc-conventions.md`.
 
@@ -215,7 +215,8 @@ possible explanation.
 ## Composition rules
 
 1. `project.yaml` may declare project defaults; `mission.yaml` may select the
-   catalog and override those defaults for the mission.
+   catalog and override those defaults for the mission. Some file in that chain
+   must name the catalog: there is no default catalog.
 2. `slice.yaml` selects or overrides the components for that slice.
 3. Edges are explicit data. Array order is presentation, not dependency.
 4. Select the fewest components that honestly fit the work.
@@ -305,15 +306,19 @@ On a fresh start, restore, or new assignment:
    Do not choose a mission from an old onboarding packet or a folder's recency.
 3. Resolve SDLC selection in order: project defaults, mission defaults, then the
    active slice's explicit selection/override. A narrower explicit selection
-   replaces the broader component list; it does not append every ancestor's
-   gates. Follow an addressed wave map for its membership, review model and
+   replaces the broader component list and its edges; it does not append every
+   ancestor's gates. Follow an addressed wave map for its membership, review model and
    boundary; an explicit named-slice exception applies only to that slice.
 4. Read only the selected components and additional addressed context. Repository
-   references resolve from the code repository root; installed references from
+   references resolve from the Git root of the repository that holds the YAML
+   declaring the catalog, which may not be the code checkout; installed references from
    `$OPENRIG_HOME/reference`; context-pack refs use `rig context get`. For a
    Markdown `#section` address, use `loading-addressable-markdown` rather than
    loading an entire unrelated manual. Expand the investigation when the task's
    evidence requires it: the address map is a starting point, not a search limit.
+   For work running as a workflow instance, `rig workflow guidance <instance>`
+   reads the effective selection, the selected catalog sections and the original
+   intent; add `--component <id>` or `--full` to expand.
 5. State briefly the user outcome, current role, candidate, selected path and
    next completion boundary. No composition means the light Part A flow in
    `sdlc-conventions.md#a1-the-flow-in-one-pass`. Do not author a

package/daemon/docs/reference/product-management-pass.md

@@ -31,7 +31,9 @@ measuring stick:
 3. **PRESENT DECISIONS DECISION-READY.** One at a time, lettered, recommendation
    first, records cited. The owner's ruling gates everything downstream —
    mechanically where possible (a blocked-on anchor), never by memory.
-4. **MINT SLICES AT PLAN TIME** with real one-paragraph intents.
+4. **MINT SLICES AT PLAN TIME** with real one-paragraph intents
+   (`rig scope slice create <mission> <slug> --intent "..."`; without `--intent`
+   the SPEC.md intent defaults to the title).
 5. **DEPOSIT THE DESIGN — the fidelity law.** Every design-bearing slice's SPEC.md
    carries the full design contract INLINE: the owner's words verbatim, the settled
    do-not-reopen decisions, the live evidence, the shape of done, the anti-goals. A

package/daemon/docs/reference/project-workspace.md

@@ -31,6 +31,23 @@ is the project-location catalog. The project manifest exposes empty
 addresses and stable managed-catalog skill IDs, but neither skill source nor a
 System World belongs in this tree.
 
+Installing a bundle that carries a project (`rig bundle create --project-dir`)
+copies the project folder to `<workspace.projects_root>/<id>/`, adds its catalog
+entry, and lists the bundle's rig under that entry's `rigs` (see "Work-install
+project selection"), before any seat launches. Every byte already in the
+catalog stays: the entry is appended in the file's own indentation and line
+endings, and a later rig joins it by a one-line edit of its `rigs: [...]`.
+Reinstalling changes nothing. If the file's shape doesn't allow that (for
+example a flow-style list), if the id is already taken by another root, if the
+folder is registered under a different id, or if the rig is already listed
+under another project, install writes nothing to the catalog and prints what to
+change, and the folder isn't copied either. An existing folder at
+`<workspace.projects_root>/<id>/` is never overwritten: if its files differ from
+the bundle's, install keeps it and says so. Without a catalog, the one it writes
+keeps an entry for the workspace root beside the bundle's, under the id from the
+workspace's own `project.yaml` (`default` when it declares none); if that id is the
+bundle's project id, install reports a conflict and writes no catalog.
+
 ## Project-world install
 
 `project.yaml` may select project context and managed skills together:
@@ -46,6 +63,24 @@ install:
     - repository-maintenance
 ```
 
+A project can also name world packs to read after the System World, in order:
+
+```yaml
+install:
+  worlds:
+    - ref: openrig-world
+    - ref: project-world
+      profiles: { claude: guided }
+```
+
+Each `install.worlds` entry has the same `{ ref, profiles }` shape as a System
+World `context` entry. `work-install` lists them as `context world <ref>` lines
+and `worlds` in `--json`; it never delivers their content, so read each with
+`rig context get <ref>`. An invalid entry, or a ref the System World or an
+earlier entry already lists, is ignored with a warning. Without the key, the
+output is unchanged. The list holds pack names only, resolved from the local
+library when read, so naming a world copies none of its content.
+
 `install.context` contains project-relative Markdown addresses. `install.skills`
 contains stable skill identities only. Skill source bytes live in the single
 configured managed catalog (`skills.root`, default `$OPENRIG_HOME/skills`),
@@ -73,6 +108,43 @@ ownership receipt. A later seat start with no project-world input preserves it;
 an explicit install whose `install.skills` is empty clears it. This keeps
 "project not supplied" distinct from "project deliberately selects no skills."
 
+## Work-install project selection
+
+`rig context work-install` picks one project from the catalog at
+`workspace.catalog_path` (default `workspace.yaml`), in the order below. Without a
+catalog, the workspace root itself is the project (`selectedBy: workspace`, or
+`explicit` with a matching `--project`), and `--project` must match its
+`project.yaml` id. Operating posture uses steps 3-5
+the same way when a queue row names no project (see
+[scoped operating posture](scoped-operating-posture.md)).
+
+1. `--project <id>`;
+2. the only declared project;
+3. the project whose entry lists the calling seat's rig under `rigs`;
+4. the deepest declared project root that contains the working directory
+   (`--cwd`, else the current directory);
+5. the only project whose entry lists no `rigs`, so a rig that isn't listed
+   anywhere keeps its project after a claimed project is added beside it;
+6. otherwise it stops with `project_required` and prints each candidate's exact
+   command.
+
+```yaml
+schema: openrig.workspace/v0alpha1
+projects:
+  - id: default
+    root: .
+  - id: contributor
+    root: projects/contributor
+    rigs: [openrig-dev]
+```
+
+`rigs` is optional. A `rigs` value that isn't a list of rig names is ignored
+with a warning; the entry can still be chosen by `--project`, as the only entry
+or by working directory, but never counts as unclaimed in step 5. A rig listed under two projects, or two projects sharing the
+deepest root, leave the choice to `--project`. Step 3 reads the seat's
+`OPENRIG_SESSION_NAME`, so a plain shell skips it. `--json` reports the step
+that chose the project as `position.selectedBy`.
+
 ## TUI project selection
 
 Open **PROJECTS** (or enter `projects`) to choose an ID and root from the
@@ -116,14 +188,19 @@ ambiguity.
 
 ## Queue Mapping
 
-Queue items attach to a slice when their body or tags mention one of:
+A `slice:<id>` tag is the authoritative way to attach a queue item to a slice;
+with a project selected, typed rows also need the `project:<id>` tag. As a
+fallback, for slices with no typed rows, items attach when their body or tags
+mention one of:
 
 - the slice id;
 - the mission id;
 - the legacy `rail-item` value in slice frontmatter.
 
-For new work, include both mission and slice ids in the queue item body or
-tags. Example:
+Once any slice in a mission has typed rows, the fallback stops matching on the
+mission id (and on a `rail-item` defaulted from it) for that mission's other
+slices too. For new work, tag rows with `slice:<id>` (and `project:<id>`), and
+include the mission and slice ids in the body as well. Example:
 
 ```text
 Mission: idea-ledger