@openrig/cli 0.6.5 → 0.6.7

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,7 +134,8 @@ 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
+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. When more than 200 families (roots) were touched, it evaluates the
@@ -375,7 +379,9 @@ A consumer such as a later Herder plugin reads `GET /api/health` and
 `rig health explain <finding-id> --json` records. The record schema is
 `openrig.health/v0alpha1`; list metadata is `openrig.health-list/v0alpha1`.
 For a source that bounds its input, list metadata also carries `coverage`
-(`source`, `total`, `evaluated`, `omitted`, `limit`, `order`, `partial`), and
+(`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.
@@ -399,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,10 @@ 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. `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
 command and error. Leave unknown values unknown. A working daemon or a passing diagnostic is not required to ask for
@@ -32,17 +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
-`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.
+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). 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
+
+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
 
@@ -67,6 +112,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
@@ -87,8 +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).
-- Stopping the daemon can report a timeout while closing connections:
-  [#166](https://github.com/mvschwarz/openrig/issues/166).
+- 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/docs/reference/host-resources.md

@@ -6,8 +6,9 @@ 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, and transcript capture attempts,
-failures, UTF8 bytes and elapsed capture time for currently rotating seats.
+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

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,63 @@
+# 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. One exception: kernel Codex seats on the
+kernel's operational default always get the Codex notice overrides below, without this option.
+
+- 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; a rig spec's `non_interruptive` overrides it (see below), and an explicit positive or
+negative command-line flag overrides both. 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. When the bundle's `rig.yaml`
+declares `non_interruptive: true`, it says instead that the bundle's launches are non-interruptive by default, and
+leaves out the asks-once note. 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 task 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
@@ -88,7 +160,7 @@ existing file-reader allowlist. Catalog membership does not grant file-read or
 execution permission. These views only read; they do not select a lifecycle
 operation or activate a mission. Execution and slice queue membership require
 an exact `project:<id>` tag; lifecycle instances use their authored project
-identity. Unscoped historical queue rows and global review artifacts without
+identity. Unscoped historical tasks and global review artifacts without
 project binding are excluded from project-specific claims.
 
 The read API adds `GET /api/scopes/projects` and optional `project` and
@@ -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