Adds packages/daemon/assets/plugins/openrig beside openrig-core, shipped in the npm package. Its Claude Code manifest runs rig mcp serve --front-door with OPENRIG_SESSION_NAME from the plugin's seat setting, the app's address on the person's team as a hosted member; there is no root .mcp.json and no hooks. A marketplace manifest named openrig-app installs it from the package already on the machine, and a Codex manifest connects it with one command. One new skill, working-with-an-openrig-team, describes the loop around the existing MCP tools; its home is the spec copy, and mirror-skills generates the canonical and plugin copies and routes it in the skills index. rig mcp serve --front-door gives the plugin's seat front-door instructions (the person's questions and words, with no member work-loop authority), and rig_whoami answers a declared hosted seat with no session when its rig exists; the default instruction modes and tool exposure are unchanged.
A timed-out or unreadable rig stream emit can still land late. Its error now names the retry that can't add a second item: with --id, repeat the same emit with that --id (the daemon keeps one item per stream item ID) or check first with rig stream show <id>; without --id, check with rig stream list --source <recorded seat> --since <five minutes before the send>, using the seat the daemon records, and pass a stable --id on later emits. queue create is unchanged; its existing --id already makes a retry safe, and the openrig-user skill now says so for both in one paragraph (skill digest updated). No new refusal, error code or setting.
The openrig-core refocus hook marks a `rig queue whoami` lookup that ended in ETIMEDOUT and passes `--work-unknown-timed-out` with `--work-unknown`. With `--unresolved-work-advisory` (passed since #2582), trace-to-root.py prints "TRACE GAP — current work node UNKNOWN: queue whoami failed: spawnSync rig ETIMEDOUT" plus the project-level chain, labelled a broad orientation and not evidence of a current mission, and doesn't fail `--check`, so the timeout no longer counts toward "Refocus failed on N consecutive attempts". Non-zero exits, other spawn errors, unreadable answers, no remaining budget and a run without the advisory flag stay strict. A timed-out refocus now clears the pending post-compaction retry, as #2582's advisory does, so a slow daemon isn't queried again on every prompt. The skill digest is regenerated. Refs #2581: the part #2582 left open.
The openrig-core refocus hook passes a new --unresolved-work-advisory flag to the refocusing trace script. With that flag, when the work basis says typed work did not resolve (no matching node, or a mission or slice that resolves to more than one directory), the trace prints "TRACE GAP — no single current work node" with the reason, then the project-level chain labelled as broad orientation, not evidence of a current mission. The hook can then tell that advisory from an operational trace failure. Without the flag, and for conflicting tags, several fully resolved nodes, or an unreadable queue response, the script stays strict and exits nonzero as before. The skill's edge digest is regenerated. Refs #2581; the separate queue whoami timeout case is unchanged.
Step 4 of the openrig-upgrade skill now works on a host without the sqlite3 CLI when the running Node provides node:sqlite. backup-sqlite.mjs still uses the sqlite3 CLI's .backup first (OPENRIG_SQLITE_BIN, or sqlite3 on PATH); when the CLI isn't there, it uses Node's built-in node:sqlite online backup() for a page-for-page copy, and VACUUM INTO only when backup() isn't available, then checks the copy with PRAGMA integrity_check. With neither the CLI nor node:sqlite, it stops with a message naming both remedies. It needs no extra dependency. A focused test runs the helper with an empty PATH, confirms sqlite3 can't be found, and checks the copied database. Reported in #2391 by @ziadeh. Contributed by @mohitdixit02.
A rebuild handover's receipt now says what happened. sideEffects.provenanceRecordWritten is measured: commit() reads the node's occupant tenure before and after recording the handover in its own transaction, and reports true when a new handover-kind tenure exists for the reserved generation; a swallowed mint failure reads false. A new sideEffects.departingProcess reports ended-graceful, ended-forced or not-touched, from the in-place termination the successor launch already performs. departingSessionKilled stays false, which is accurate: the tmux session is kept and the pane respawns. The CLI's human lines and the seat-continuity-and-handover skill now say whether the lineage record was written, how the old process ended, and that a bound seat whose record is missing shouldn't be handed over again.
7 files, +125/-20, most of it tests.
rig seat handover's help, guidance, skill and lifecycle doc now say --source fork:<seat>, which is what the command resolves; they said fork:<id>. A --dry-run now checks a fork source the same way the real run does (the session exists, has a native conversation id and runs the seat's runtime) and returns the same refusal, instead of accepting a source the real run would refuse. The real run's checks are unchanged, moved into one shared helper; the dry run writes nothing.
The README, getting-started and quickstart now install and add skills from the current release, v0.7.4, instead of v0.7.3. docs/releases/README.md says it holds the per-release notes for v0.1.12 through v0.6.3 plus v0.6.12, points to CHANGELOG.md and GitHub Releases for later ones, and its release steps match how releases are published now. Shipped skills and the kernel culture no longer route to a skill that isn't shipped: rig-lifecycle points to rig context get help, the kernel culture's restart case points to getting-started's "Incomplete setup and restart", and the dead sibling entries are dropped. Both skill copies stay identical and their digests are updated.
12 files, +28 -56: docs, skill text and the digest file only; no code change.
Someone submitting a team to openrig.dev/rigs now learns before they submit that the registry's check runs rig bundle check on their folder at the submitted ref with the latest published OpenRig, and that any finding fails it. An exported team has no README of its own, so the publishing guide's submit section and the rig-bundles-and-shareable-artifacts skill now say to add one, declare it in rig.yaml docs, and run rig bundle check at the commit being submitted. The skill gains a short section from an exported team to a submission; its mirror and edge digests are regenerated.
4 files, +29 -2 (docs and skill text only). No behaviour, flag or check changes.
The queue-handoff skill now says how to wait on something outside the queue, such as CI or a long job: park the row with rig queue block <id> --on external:<what> --wake-after <duration> --continuation "<what resumes>". The row stays yours, reads parked rather than stalled, and the timer wakes you. Text only, with the skill digest regenerated.
2 files, +6 -2.
The queue-handoff skill's writing paragraph is followed by its qualification: it's writing guidance, not a delivery filter or length limit. Uncertainty and limits that affect the action stay in. Early references, acknowledgements, requested progress updates and completion returns remain fine, and the sender judges how much context is useful. The skill's digest is regenerated. Text only; no behaviour change.
2 files, +3 -1.
The shipped `queue-handoff` skill gains one paragraph on writing a handoff the receiver can act on after one read: open with the request or change that affects their next step, use full words, keep the limits that change that step, put reference IDs after the action, and put the complete request near the start of the task body. The skill's digest is regenerated. Text only; no behaviour change.
2 files, +3 -1.
Source comments in the daemon, TUI and UI packages drop internal tracking references, and the regenerated skill and context-pack mirrors follow. Comment and text changes only; no behaviour change. The scope classifier files are unchanged here, so their CLI and daemon copies stay byte-identical.
54 files, +114 -114.
A workflow whose done or handoff advances past a declared human park that nobody answered now says so in the existing advisory output and in the same transition note, on both the serial and dependency-graph paths. Nothing is refused: the step still proceeds.
The shipped `messaging-the-human` skill (all three copies) and the resolve nudge say that a response is not consent or authority, and show `--exit waiting --blocked-on <person>` for waiting on a person. Refs #1710.
A registered shared channel lets people who aren't registered, such as a customer, talk to a seat without registering each of them.
- In: an unregistered Slack sender is admitted only in a registered shared channel's own Slack channel, as that channel participant (`acme-customers@external`), including with no registered person at all. The seat's row carries a labelled block, last after the message: the channel, its organization and groups, who actually wrote (marked as not a registered person), and the channel's effective policy. It's tagged `participant:<id>`, `shared-channel` and `slack-sender:<user>`. A registered person writing there stays themselves.
- Correspondence by construction: a message admitted as a channel never becomes an answer, never closes or resumes an ask (even one addressed to the channel), and a click there records nothing.
- Back: a registered shared channel is a valid queue destination. A row to it posts as a notice, whatever its intent. An update with `--reply-to` lands in the customer's thread, and so does a later one; posts to a channel mention nobody. An ask to a channel is accepted with an advisory that nothing there will answer or close it, and its questions show as a list without buttons.
One participant per vetted channel, from #1992's participant file; no customer is registered and no second store is added. Admission fails closed: an unreadable participant file admits no channel senders, and a broken person registry still refuses everyone. Policy is readable context in the row; nothing enforces it.
Tests cover admission, channel-only setups, never settling anything, and the way back through the real Slack wire with a fake transport.
* feat(gateway): several people, shared channels, organizations, groups, readable policy and a default person
The gateway can now register several people and shared-channel participants
(one vetted Slack channel is one participant at <id>@external), group them into
organizations and groups, give each readable policy text, and name a default
person.
Storage keeps rollback safe. Person fragments keep the closed key set a v0.7.0
daemon reads, so an older daemon still loads every person. Everything new lives
in gateway/participants.yaml, which v0.7.0 and v0.7.1 never read. A broken side
file never disables the person registry; a person removed by hand leaves a
warning, not a broken file.
Policy is text agents read, shown organization first, then each group, then the
participant's own, each labelled with its source. Nothing enforces it or derives
it from names.
The default person serves needs that name nobody: escalations, the notice
digest, Mission Control's my-queue, the workflow fallback and pairing approval.
It's the chosen person, else the only one, else none with the reason, never the
first file by id. workspace.operator_seat_name keeps its existing meaning.
Verbs: `human add` accepts several people and takes --organization, --group,
--policy/--policy-file and --default; `human show` adds the placement; `human
set` takes organization, groups and policy; `human remove` also clears the
person's placement. New: `channel add|remove`, `org set`, `group set`,
`participants` and `default`.
A second registered person's Slack reply, typed or clicked, never answers,
closes or resumes another person's pending or parked ask. Main already guarded
this at two independent places; the new test pins both.
docs/reference/gateway-participants.md covers the commands, the default, upgrade
(nothing to do) and what a rollback to 0.7.1 or 0.7.0 changes. The
messaging-the-human skill points agents at `rig gateway participants`.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
* fix(gateway): a person can't take a shared channel's id; upgrade note for several people
People and shared channels share one address space (<id>@external). Adding a
channel already refused a person's id; adding a person now refuses a shared
channel's id too, in the registry's own add path and before any write, so the
participant file, its default and the channel stay intact. Before, the add
succeeded and the participant file stopped reading: the chosen default, every
placement and policy were lost, and every repair refused.
`human remove` now deletes only a person's entry from the participant file, and
`channel remove` only a channel's, so neither can remove the other kind.
The upgrade note now covers installs that already had several people: choose a
default with `rig gateway default <id>`; until then escalations report
undeliverable:no-default-person and the notice digest waits.
The ordering tests now expect the list sorted by id, people and channels
together, and pick the person by id.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
---------
Co-authored-by: review50-r3 <review50-r3@openrig-build>
Co-authored-by: Claude Opus 5.5 <[email protected]>
Clarify when Herdr may show a waiting seat as idle: a wrapped Claude footer or a visible inner tmux status line. Keep OpenRig's view and Feed as the route to find waiting seats.
Documentation only; matching mirrored skills and generated digests. The supporting evidence uses replay and screenshot-derived frames. No native runtime fix, historical causal proof, or live settings change is claimed.
Coming back to a Herdr view with `rig terminal open <view> --provider herdr` always adds a new numbered workspace; reusing an open one is the `--window` path from inside Herdr. The shipped `openrig-herdr` skill told agents to reopen with the explicit form, so people got a duplicate workspace. The skill, the getting-started guide and the capability map now say to focus the open space, or from inside Herdr run `rig terminal open <view> --window`, which reuses a matching space, and that `--provider herdr` adds a workspace each time. The `--provider` help text says the same.
A known-issue line: Herdr's own status for a seat can read idle or unknown while OpenRig shows it waiting (`needs-input`), because OpenRig doesn't feed Herdr a state. Use OpenRig's view or the Feed to find waiting seats.
Text only; the skill's mirrors and digests are updated together.
Agents asked how far to trust a delegated result didn't reach the delegating-work skill, although its body already covers that. The skill's description now ends with one trigger sentence: "Also use it to decide how far to trust a delegated result." The body and every other byte are unchanged; the shipped copies and digests match.
In a lab measurement (Sonnet 5.5, Claude Code 2.1.310, one skill listed), the skill activated on 5 of 5 runs for each of two target prompts and on 0 of 36 near-miss runs. There's no claim for other harnesses or models.
Thanks to skills-sme@lab, and to Matt Pocock's writing-for-agents and Lauren Tan's pstack Eval, which shaped the method.
`rig provider switch --seat <seat> --token-file <path>` moves one Claude seat onto a prepared subscription token, on the same conversation, the same config directory and the same pane. `--stored-login` moves it back to the config directory's stored login.
- OpenRig stores a reference to the token file (a label and path), never the value. The launch reads the file as Claude starts and exports it only into Claude's process, so the value never reaches OpenRig's database, rows, argv or logs.
- The seat keeps its pane: Claude ends in place, a shell respawns in the same pane with its scrollback, and restore's own resume step brings the conversation back.
- The report names the source the seat actually bills. The token survives the managed environment reduction. Variables that would outrank it are unset for that one process, which also hides them from Claude's tools and hooks. With `--stored-login`, an inherited `CLAUDE_CODE_OAUTH_TOKEN` is reported rather than silently used, and a launch-time fallback warning reaches the report.
- Outcomes are honest. Only a refusal before Claude is touched reads as unchanged. A pane that was ended but not resumed, or a thrown step, reads `unknown` with the snapshot's recovery command, and nothing is retried.
- The whole switch runs in the seat's existing lifecycle lease, so a second switch waits and rechecks. A failed registration never kills a kept session. The printed way back quotes the token path.
One nullable column (migration 138) and one event type. No account registry, vault or new route. Native validation on prepared homes is next.
Contributors now get the correct vercel-labs/agent-browser source link and an accurate description of our retained copy, rather than an unsupported "tracks upstream" claim. Its upstream Apache-2.0 license travels beside it and beside dogfood; the three shipped obra/superpowers derivatives (systematic-debugging, test-driven-development, verification-before-completion) also include their upstream MIT license. Check dates name the compared upstream revisions and say no content sync occurred.
Skill bodies, triggers and companion workflow files are unchanged. Mirrors, edge digests, the docs guard and the exact upstream license bytes are verified. Metadata, notices and regenerated hashes only.
Thanks to the authors of vercel-labs/agent-browser and obra/superpowers.
An agent can move one Codex seat to another subscription login with one command, and the seat keeps its conversation: `rig provider precheck --seat <seat> --to-account <name>` shows the Codex home the running seat uses, what the seat is doing and every peer on that home, and `rig provider switch --seat <seat> --to-account <name>` performs the move. Before this, `rig provider switch` always answered `failed_safely` with `switch_execution_not_yet_wired`.
How it works: the switch composes `rig auth`'s file operations, now in the daemon (`@openrig/daemon/codex-auth`, with the CLI path a re-export), and the in-place `rig seat restart --keep-conversation`. It plans the restart first, which stops nothing, and checks that the login is saved in that home. It then saves the outgoing login as a unique `before-switch-<time>` copy, never replacing an earlier one; a save that fails for any reason other than "no active login" stops the switch before anything changes. It activates the chosen login and restarts the seat in place. The report reads `rebind_in_progress` with the verify step, `failed_safely` with the way back, or `unknown` with the restart's recovery command, never retried. Switches on one Codex home run one at a time inside the daemon, and a switch that waited behind another rechecks its seat before it changes the login. Every same-home peer is listed with what will happen to it, from Codex 0.164.0's own source: it keeps its old login in memory until its next token refresh, then stops with "signed in to another account". Each peer gets a pasteable `rig seat restart <peer> --keep-conversation --reason ...` step, and the person is told not to sign in again in that home. After a CLI timeout, the message says the switch may still be running or queued behind another.
Limits: Codex seats only (a Claude seat is refused with `rebind_unsupported_for_runtime`), Linux only (the restart reads `/proc`), and the login must already be saved in the seat's own home. A restart that never settles holds its home's queue; switches there wait, and their CLIs report unknown after 120 s. Auth contents never enter returned metadata, logs or argv: files are copied by descriptor through a scrubbed buffer.
Validation: the new tests fail on main and pass now, including a failed outgoing save, two switches in one second, overlapping switches on one home, and a switch whose seat became ineligible or moved home while it waited. The provider-switch and route suites and the CLI tests pass, and the independent security review's real-file controls pass. Native proof with two logins in one home and a control seat is Quality's.
An agent that reaches OpenRig through MCP (a desktop app, or an assistant on `rig mcp serve --http`) could claim and close an item but couldn't hand it on, so passing work along meant close-and-create, which loses the link a delegator follows. Two work tools now call the daemon's existing routes, the same ones `rig queue handoff` and `rig queue unclaim` use. `rig_queue_handoff` closes the item as handed off and opens its successor in one transaction, with lineage in `chainOfRecord`; the task's text, tags and priority carry over unless given, and a note, summary and person-route `evidenceRef` are optional. `rig_queue_unclaim` returns an in-progress claim to pending for the same seat with its reason recorded. Both are annotated destructive.
Scope for an authenticated caller matches `rig_queue_update`: the item's owner must be in scope, and a handoff's next seat too, so it never reaches a seat outside the grant or a person. A timeout says the outcome is unknown and to check `rig_queue_show` before retrying; a repeat after it landed answers `qitem_already_terminal` and creates nothing. The server instructions gain one sentence, and the openrig-user skill, its digest and the capability map's MCP sentence are updated (36 tools, 19 work tools). Not included: cross-host handoff, `targetRepo`/`gate`, `fallback`, hosted grants, the 2026-07-28 protocol and principal attribution.
Cost: source +58/-1, tests +92/-10 in 3 files (about 1.6 test lines per source line), docs +15/-9. No new refusal, error code, route, setting or dependency. Validation: 70/70 across the four MCP queue/HTTP/server/operations files and 9/9 in the other server-building MCP files; 8 of the new cases fail against main's `mcp-server.ts`. The independent security review ran 74/74, including real HTTP grants whose owner and destination scope checks each fail when removed. HTTP fixtures use in-memory SQLite and inert delivery, not native desktop-client or remote deployment proof.
Follows #1937 and closes two of the gaps it listed as still daemon-scoped.
## What a user gets
- **A one-off `rig up --env CLAUDE_CONFIG_DIR=…` or `CODEX_HOME=…` isn't applied, and the CLI says so.** That value used to put the first
launch on a home that a restore, a handover and `rig seat status` didn't know about: the seat ran on one login while status reported
another, and the next restore moved it back. The note says to declare the home in `env:` in the rig spec. Other `--env` values work as
before.
- **For a Claude seat with its own config dir, activity and continuity read that dir.**
- Activity: the self-report rung finds the seat's `pid.json`.
- Continuity: a policy that watches the seat's transcript, such as a size threshold, finds the file.
Before, both looked only in the daemon's dir and found nothing for such a seat.
## Changes
- **CLI** `up.ts`: leaves `CLAUDE_CONFIG_DIR` and `CODEX_HOME` out of `--env`, with a note.
- **Daemon** `node-launcher.ts`: drops both from any one-off env it receives (`withoutRuntimeHomes`), so an API caller gets the same result.
- **Daemon** `startup.ts`: the Claude self-report reader and the continuity transcript lookup resolve through `claudeConfigRootFor`, in this
order:
1. the seat's declared home;
2. the daemon's `CLAUDE_CONFIG_DIR`;
3. `~/.claude`.
A seat that declares no home reads exactly what it read before.
- **Docs:**
- `rig-spec.md`: the `--env` exception, and "name the home in `env:`";
- the `openrig-user` recipe step 2 says the same, with its edge digest updated.
## Still daemon-scoped, on purpose
Live usage refresh (`rig provider status --refresh`) still reads only the daemon's own logins. Its readers are built once with the daemon's
homes, and reading each seat's home would need a native reader per home. `rig-spec.md` now says so.
## Tests
- `seat-runtime-home.test.ts`:
- `withoutRuntimeHomes` drops both names and keeps the rest;
- `claudeConfigRootFor` returns the seat's home, else the daemon's, else `~/.claude`.
- `seat-env-journey.test.ts`: a one-off home reaches neither the seat's terminal nor its forwarded names; other one-off values still do.
- CLI `up.test.ts`: `--env` with both homes and `DEBUG=1` sends only `DEBUG`, and prints the note for each home.
GREEN at `cceedfb1` (run 40131620044): all 8 jobs pass. RED, the tests alone on main (`e9eb005d`, run 40131618183): still queued; I'll add
its result here when it lands.
A seat can now run on its own Claude or Codex account. Each runtime keeps its login in its home: Claude Code in `CLAUDE_CONFIG_DIR`, Codex in `CODEX_HOME`. A seat whose member or rig `env:` declares an absolute one runs on that home for the launch and lifecycle paths below, instead of the daemon's:
```yaml
pods:
- id: dev
members:
- id: impl
runtime: codex
env:
CODEX_HOME: /Users/me/.codex-second-account
```
The home is prepared once, natively (`CODEX_HOME=<home> codex login`, or `CLAUDE_CONFIG_DIR=<home> claude` then `/login`). OpenRig copies no credentials or history between homes.
## How
`packages/daemon/src/domain/seat-runtime-home.ts` resolves a seat's home from its stored `env:` (member over rig). A value that isn't an absolute path is reported and ignored. It doesn't reach the runtime: `getEffectiveSeatEnv`, the one source for launch, restore, handover and runtime switch, leaves it out. So the seat resolves as it did before, and nothing is refused.
| Runtime | What follows the seat's home |
|---|---|
| Claude | the managed launch's exported `CLAUDE_CONFIG_DIR`; the first-run bootstrap (`.claude.json`, onboarding and trust); resume capture (`<home>/sessions/<pid>.json`); the fallback resume probe, which runs with the seat's config dir only when one is declared |
| Codex | the launch, resume and fork commands; OpenRig's managed `config.toml`, hooks, feature flag and core plugin; the profile, daemon-support and network-default probes; thread capture, including on adoption and discovered handover (by node); the resume proof, including `rig seat restart --keep-conversation`'s |
| Codex, legacy paths | the legacy resume and restore pass the home only when one is declared, so other seats' calls are unchanged |
| Readers | context usage and the model reader also search declared homes (thread ids are unique across homes) |
| Usage limits | Claude seats with their own home pool apart (`claude:home:<dir>`) from `claude:local`, and the reactive tap skips a Codex seat with its own home, so one account's exhaustion isn't charged to another |
| Status | `rig seat status` shows the runtime home and where it comes from (member, rig, daemon or native default), and any ignored value |
| Provider | `rig provider status` lists the seat's own home as its configured account (`homeFrom`, `ignoredHome`); the daemon home's auth registry no longer binds a seat that has its own home |
Codex homes are passed as a parameter, not adapter state, so concurrent launches for different seats can't cross.
**Still daemon-scoped (not every reader follows the seat yet):** startup's Claude self-report evidence and its continuity transcript lookup still read the daemon's root, and native usage refresh stays daemon-scoped. A one-off `rig up --env CODEX_HOME=…` value still reaches the panes without this resolution.
**A correction to how this worked before:** `CLAUDE_CONFIG_DIR` is one of the managed Claude launch's own keys, so a seat's declared value was never forwarded to Claude, even when the daemon set none. `rig-spec.md` is updated, along with the Codex line.
**Compatibility:** the provider record's new fields are optional, so an older daemon still accepts this one's seat accounts across hosts.
**What doesn't change:** seats that declare no home; shared homes (several seats may name one); a running seat, which keeps its home until its next launch.
**A known limit:** a conversation saved under a seat's earlier home isn't in its new one, so it can't be resumed there. OpenRig doesn't copy it between homes.
## Tests
- **First round:** RED on main `7e69abc1` fails the 21 new tests ([run 40118004305](https://github.com/mvschwarz/openrig/actions/runs/40118004305)). GREEN at `2524764f` passes all 8 jobs ([run 40118018519](https://github.com/mvschwarz/openrig/actions/runs/40118018519)).
- **Review fixes:** RED, with the tests alone on `7b2065f3`, fails exactly the 9 round-1 tests ([run 40125339648](https://github.com/mvschwarz/openrig/actions/runs/40125339648)). GREEN at `77f70a2e` passes all 8 jobs, with 21,151 daemon tests ([run 40127630330](https://github.com/mvschwarz/openrig/actions/runs/40127630330)).
- **Covered:**
- the resolver: member over rig, ignored relative values, nothing declared;
- the Claude launch, bootstrap, resume capture and fallback probe;
- the Codex fresh, resume and fork launches with managed config in the seat's home;
- thread capture on adoption and handover;
- the resume proof and in-place restart;
- legacy resume;
- context usage;
- usage pools by home;
- status and provider accounts;
- unchanged seats.
These tests use fixture executables only and never sign in. Real logins in distinct homes, and the same conversation across resume, restore and handover, still need a native run.
Rex as a terminal provider, by @vanducng. Thank you. The scope is in #1934.
## What a user gets
From a [Rex](https://www.superlogical.com/rex/docs) pane, `rig terminal open <view> --window` and the TUI open the team's view as a new Rex session, one window per page with the same 16-tile grid as Herdr, and switch the Rex app to it. `--provider rex` selects it explicitly. Outside Rex nothing changes: the default order stays Herdr, then cmux.
## The change
- **The provider:** `rex-adapter.ts`, `rex-transport.ts` and `rex-layout.ts` implement the existing `TerminalProvider` seam over Rex's JSON CLI, passing `-S` because this Rex build ignores `REX_SERVER`. Herdr's grid builder moves into a shared `tile-layout.ts`, with Herdr's layout output unchanged.
- **Selection:** the CLI (`terminal-window.ts`, `terminal-window-rex.ts`) and the TUI (`open-window.ts`) pick Rex when called from inside Rex. Inside a Herdr pane, Herdr keeps the view even when `TERM_PROGRAM=rex`, and the CLI and TUI now agree on that. A window opened from inside Rex is refused unless this terminal and the daemon use the same Rex server.
- **Status stays fast:** discovery gives each of Rex's version and status calls 1 s (the pair races a 1.25 s deadline), shares one probe per status report, and the service probes Herdr, cmux and Rex side by side. A stalled Rex reads "did not answer within 1000 ms" while the other providers report normally. Mutations keep their 30 s budget.
- **Uncertain outcomes stay uncertain:** a Rex call that times out, is killed, or returns an unreadable reply is `unknown`, not `failed`. A create whose reply is lost, or names no session, returns `rex_outcome_unknown` and says to check Rex before retrying. A lost window reply keeps the session, names the unconfirmed pages, and never calls `session.destroy`. The session is closed, as before, only when every window definitely failed.
- **Docs and skills:** `terminal-sessions.md`, `getting-started.md`, the as-built adapters page, and the `rigs` and `openrig-herdr` skills.
## Proof
- **CI at this head:** all jobs pass, tested merged with current main. The daemon's terminal-service, rex-adapter and rex-transport suites include a never-settling Rex beside a healthy Herdr (the report returns in under 5 s, using one probe's two 1 s calls), lost create, lost first-page and lost later-page replies (no destroy), and the Herdr-inside-Rex precedence on both the CLI and TUI paths.
- **The author's native runs** (Rex `0.0.1792787366`, API revision 7, two Macs): status, a 4-seat open on each Mac, `--window` switching the app, the TUI preview and open over HTTP, a 17-seat two-page view, and a stalled-Rex measurement at an earlier revision. These are the author's evidence. Our review read the source and CI only.
## Limits
- Not run on Linux.
- Rex counts a block's login-shell startup toward its quick-exit window, so tiles set a 10 s threshold and the adapter checks for exited tiles once, about 2 s after opening. A tile that fails between 2 s and 10 s keeps its error on screen, but the result lists that seat as opened.
- `rig terminal status` with no provider also probes Rex, bounded as above.
## Cost
Source +721/-111, tests +993/-13, docs and skills +82/-20. One new result code (`rex_outcome_unknown`), no new setting.
## What this changes
The openrig-user skill's "After a queue write" section, and the regenerated skill digest. No code changes.
- **The request ID.** `rig queue create` prints `Queue create request ID: <id> (not proof of persistence)` on stderr *before* it sends the write, so an interrupted create can be reconciled. The section now says:
- that ID names a request, not a row;
- the row is the `qitemId` in the answer on stdout, and a non-zero exit means no row was confirmed;
- don't merge stderr into stdout and keep the first `qitem-…`.
- **Proven refusals.** The section listed every 502 `remote_queue_write_failed` as indeterminate. A 502 whose `failureClass` is `unknown-host`, `unsupported-transport` or `registry` is refused before any host is contacted and writes nothing, which is what the CLI already reports ("No row was created"). `unsupported-transport` means the host entry is SSH-declared; `rig host list` shows its http entry.
## Why
Queue writes to another host go through the selected daemon, which forwards them only to an http-transport registry entry. For an SSH-declared entry it answers 502 `unsupported-transport` before contacting the host, and nothing is written anywhere (`queue-cross-host-create.test.ts`, "ssh host: unsupported-transport (502), NOTHING written locally").
The CLI reports that honestly: the refusal, exit 2 and "No row was created". But a caller that runs `… 2>&1 | grep -oE 'qitem-[0-9a-z-]+' | head -1` keeps the request ID, which is printed first. It drops the refusal, and the pipeline's exit status hides exit 2. The caller then holds an ID for a row that doesn't exist. The skill is where agents learn how to read a queue write, so this is the place to say it.
## Checks
- `node scripts/mirror-skills.mjs --check`, `node scripts/generate-context-packs.mjs --check`, `node scripts/check-docs-guard.mjs` and `node --import tsx scripts/check-first-run-references.mjs`: pass.
- `node --test scripts/mirror-skills.test.mjs`: 34 passed.
- Vitest, `--maxWorkers=2`:
- daemon `openrig-core-plugin`, `queue-cross-host-create` and `queue-cross-host-handoff`: 117 passed;
- CLI `queue-host-refusal-hint`: 26 passed.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
An explicit rig send --dangerously-interact no longer types over text a person has already typed. Before pasting, it reads the target's composer under the existing lease and final target check, on every override path, including a broadcast that waits for idle. Typed or pasted text stops the send, and the caller is shown that text, apart from any suggestion (override_input_present). Input that can't be read stops with its reason (override_input_unknown) and is never treated as empty. An empty box, or one holding only a suggestion, types as before, and a recognised native prompt is still driven.
--type-without-checking skips the read for one send, says so, and clears nothing. To clear on purpose, use the native or tmux controls and send again; that clear happens outside OpenRig's checks and isn't recorded. Reading and pasting aren't atomic: a keystroke can land in between. The shown text goes only to the caller, never to the receipt, outbox, held messages, capture observer or audit.
Ordinary sends, notices, wakes and the guard-off default are unchanged. The openrig-user skill now teaches the stop and the deliberate clear.
Docs only. cli-reference.md and openrig-user's SKILL.md now describe what 0.7.1 adds or changes, as the code does it:
- gateway human slack-subscription: set every-ask, urgent-only or unset; show prints the value and whether it's authored or the default.
- ps --nodes --json: the compact projection keeps the served needsAttention; arbitratedNeedsInput and needsInputEvidence come with --full or --fields.
- compact-plan: its flags are the plan's own thresholds, and the output shows policies.claude_compaction separately.
- The send guard at a complete, current Claude MCP approval menu: the send refuses with target_needs_input, and --dangerously-interact --reason is the only override.
- Startup attention: after a refused Claude startup turn, later inputs are held and counted; Cursor and other community-harness assisted startup is reported honestly.
The skill's MCP section also stops overstating three things: a missing or unreadable grant file is read again on every request and recovers without a restart; --owner offers every tool, not only --workspace; and several tools beyond the queue tools and rig_whoami return structured results.
Three files, +26/-5, including the skill's one digest entry. The PR body cites each change to source at the base and lists what was left unchanged and why.
Every ask to a person is on Steering and the TUI. Whether it also posts to Slack is the person's Slack subscription, the first attention subscription: a saved filter plus a destination on their gateway record (subscriptions: [{ destination: { connector: slack }, filter: { preset } }]).
- every-ask, the default: every ask posts to Slack, as on 0.7.0. Nothing changes on upgrade.
- urgent-only: only an ask marked --alert posts; the rest wait on Steering and the TUI (#1868's behaviour).
Set it with rig gateway human set <id> slack-subscription every-ask|urgent-only|unset; rig gateway human show prints it and whether it's authored or the default. --alert decides per item: a handoff doesn't inherit another ask's alert, and rig workflow route keeps a person's alert-worthy failed-step approval alert-worthy. The record's keys are closed and the preset must be a plain string, so a malformed entry is refused instead of silently quieting Slack. The skill, --alert help, the MCP text, --verify's not-alerted wording, the Feed and the Slack setup page use the subscription framing. A filter language, channel destinations and UI come later from the same record.
An ordinary question, approval or request to a person lands on Steering and the TUI's Feed, where they can see and answer it, and nothing pings them on Slack. rig queue create --alert (and rig queue handoff --alert) marks an ask alert-worthy: something only they can do, or an approval whose wait costs now. That ask is the same item, still on Steering, and Slack posts it once. An answer closes the ask wherever it arrives.
- Classification at create: human-required at RECORD for an ask on Steering, at ALERT with humanAlert: true. Nothing re-decides the level later.
- Slack posts a human-required ask only at ALERT, whatever its posting dial says; the dial still governs updates and notices.
- One attention membership for every reader (the Feed, ?attention=1 and the attention aggregate), independent of delivery, with rerouted asks leaving all of them. The Feed lists an ask's questions and answers, and its Slack line shows the actual receipt.
- The TUI answers an ask the way its asker framed it: Approve for a plain ask; each question with its options, with no Approve while a question is open; or reply <text>. The answer is recorded once on the same row through the existing answer path and returned to the asking seat, as a Slack answer is. A completed answer set whose return was interrupted resumes that return; a retry in different words never closes on words that weren't returned.
- The stuck sweep, wake ladder and waiting view treat a quiet ask as waiting on the person; a quiet handoff isn't escalated to Slack. rig queue create --verify reports not-alerted at once.
- Callers that need an alert set it: host pairing, the health notify path, workflow exceptions routed to a person, and MCP rig_queue_create's optional alert. The messaging-the-human skill teaches both routes.
Limits: per-person preferences beyond quiet hours aren't built, and where a mission-control bearer is configured that differs from the TUI's terminal token, the TUI's answers get the existing refusal.
The openrig-user skill's MCP section listed the old 23 tools and rig mcp serve [--port], so agents learning the MCP surface from the skill didn't know most of it existed. It now matches the shipped server:
- all 34 tools, grouped by access, including whoami, restore status, team, slices, mission, context, artifact read, the decision room and decide, and revises, alongside the queue tools;
- rig mcp serve over stdio, and rig mcp serve --http with scoped tokens (rig mcp token add --seat);
- what an agent with no shell can and can't do, and that nothing wakes an MCP-only agent.
Text only. The skill's entry in scripts/skill-edge-digests.generated.json is regenerated for the new bytes.
An agent managing a person's subscriptions across two machines can move a Codex home on the other machine from where it runs: check the home, switch its saved profile, restart its seats and verify them.
- --host <id> on rig auth status, rig auth list, rig auth switch and rig seat restart (with --plan and --verify) runs the same command on that registered machine over its SSH entry, through the existing cross-host executor, as this seat. The remote command's own stdout, stderr and exit status come back, so --json stays that command's JSON; a [via host=...] line goes to stderr. An HTTP-only entry is refused with the fix (name the machine's SSH entry, or run it there).
- --codex-home <dir> on rig auth status|list|switch names the home to act on, here or there; a remote switch requires it.
- A lost SSH connection during a remote switch or restart reads as remote-outcome-unknown with the check to run, never as failed, so a restart isn't repeated blindly. The origin carries this machine's persisted host id, as rig send --host does, and known remote results pass through verbatim.
- A remote restart's audit names the calling seat as its operator unless --operator does.
- The openrig-user skill's "Move the home" step uses --codex-home, --host and the SSH entry.
What crosses: only each command's argv (runtime, profile name, home path, seat, reason, operator) and the origin seat out, and that command's non-secret output back. No credential moves, and there is no generic remote runner.
Cost: source about +200 in three CLI files plus the skill step and its digest; tests in move-commands-host.test.ts; no new daemon route, dependency or migration.
A Fleet agent that moves a Codex home to another subscription can file one report that it, after its own restart, and the Fleet app can read back.
- rig provider moves report / POST /api/provider/moves files the report as a queue item to whoever asked, tagged subscription-move: host, home, from, to, reason, policy version, readings (observed, expected with its reset basis, or unavailable), each seat's result with its evidence, and peers.
- rig provider moves / GET /api/provider/moves reads them back, newest first, with followedBy, unreadable rows and an honest bounded window.
- Checks before anything is stored: a moved seat needs matched account evidence and an observed tool turn; unconfirmed or unknown needs what's missing, and that honest form always passes; recognized credential formats are refused anywhere in the input, keys included, and never echoed. A refusal records nothing and says the move is unchanged. Nothing here switches or restarts.
- openrig-user gains the account-policy lifecycle, observed versus expected room, unknown sign-in, balancing, and the report command.
This is slice 18's first increment, part A. The Fleet page and the two-host native journey are still to come.
Agents sometimes printed the activity-hook token while looking for a seat's identity. This tells them where to look instead.
- rig attach --json's help says its output includes the activity env the attached app needs, that the token is a credential, and to use rig whoami for identity.
- The openrig-user skill's self-attach notes and both copies of the rigs skill say to use rig whoami or rig seat status for identity or state, not the attach JSON or a file holding a seat's environment, and not to print OPENRIG_ACTIVITY_* values.
Text only (+7/-3), plus the regenerated skill digest. rig attach's human output and --print-env never carried the token and are unchanged. The plugin skill text reaches existing installs when the plugin version next advances.
Upgrading OpenRig could silently discard someone's edits to a managed plugin or global skill file: the daemon's startup refresh overwrote the file with the new version and kept no copy.
Now, before a version-advancing refresh writes over a file that differs, the old bytes are copied exactly to a fresh directory under $OPENRIG_HOME/backups/managed-refresh/, and startup logs where. A retry never overwrites an earlier copy. If a copy fails, that plugin or skill is left exactly as it was, with a warning, and startup carries on. Equal or newer installed versions and unversioned external skills are untouched. The upgrade guide now says startup may already refresh files and that a later plan doesn't protect them.
Recovery keeps the old bytes; the custom behaviour may no longer be active after the refresh.
Cost: source +29/-6, tests +88/-0, upgrade skill and its mirror +22/-10, digest +2/-2 (7 files). Backups accumulate without cleanup. No new refusal.
After a Herdr server restart or update, Herdr restores its layout, but OpenRig's tiles come back as empty shells while the seats keep running, and the openrig-herdr skill didn't say what to do.
Now the skill says it: reopen the view with `rig terminal open <view> --provider herdr`, which places the tiles in a fresh workspace. That's the stopgap while the real fix, reporting each tile's reattach command to Herdr so its own restore reruns it, waits on a live check. Both copies of the skill change together, with the pinned edge digest.
Cost: docs +6 (two copies of +3), generated digest +2/-2. No code change.
An agent in an app with no shell, reaching OpenRig only through `rig mcp serve`, couldn't follow the daemon's event log.
Now the MCP server has a 24th tool, `rig_telemetry_events`, over the existing bounded read (`GET /api/telemetry/v1/events`, which `rig telemetry events` uses). It takes the CLI's parameters (`cursor`, `start` latest or retained, `rigId`, `nodeId`, `limit` 1 to 128) and returns the same envelope: event metadata only, never payloads, with `coverage.gaps` naming history it couldn't read, a daemon restart included. `rigId` takes a rig name or id, resolved as the other MCP rig tools resolve it, and a handle no rig matches is an error rather than an empty page that would read as a quiet rig. The daemon's 400 and 503 answers come back as tool errors with its body. The `openrig-user` skill and the telemetry reference name the tool. No daemon route, SSE, event-store or queue behaviour changes.
Cost: source +34 (1 file), tests +83/-4 (2 files), docs and skill +8/-4, generated digest +1/-1. No new setting or migration; the unknown-rig error is in the new tool only.
Since #1008, a team seat's skills live in its own storage, `<OpenRig home>/state/seats/<rig id>/<logical seat>/<runtime>/`, not in the project's `.claude/skills` or `.agents/skills`. Several pages still taught the old folders, so an agent orienting from them looked in the wrong place.
Now they say where each runtime's skills go: Claude's into the seat's generated plugin (`plugin/skills/<id>`, shown as `openrig:<id>`), Codex's into `skills/<id>` beside its catalog, and the project folders only for a seat without that storage. `rig skill loadout --seat <session|self>` is named as the way to see a seat's own skills. Changed: the agent spec's skills, plugins and discovery lines, two architecture pages, the test-layers note, the shipped `forming-an-openrig-mental-model` skill (with its digest pin), and the public capability map. Stale source citations in the adapters page are refreshed, and three code comments that named a nonexistent `seat_material: seat` key now describe the seat's own skill folder.
Cost: text +47/-29 (docs +25/-14, shipped skill +13/-8, capability map +5/-3, digest +1/-1, code comments +3/-3). No behaviour change.
Refs #1008
#1727 let the openrig-core plugin's Claude hooks start without Node on the PATH, but two of the commands they start still ran `node` or `rig` from the PATH: the pre-compaction hook's restore-packet step and refocus's `rig` lookups. On a seat whose PATH has no Node, compaction left only manual-recovery text instead of a restore packet, and refocus fell back without its content, work and configuration lookups.
Now the pre-compaction hook runs its restore-packet generator with the hook's own Node (`process.execPath`) and the same arguments, so the packet and its pending marker are written. Refocus gives its four `rig` calls and its Python trace a PATH with the running Node's directory appended after the seat's own, so a `rig` that starts through `#!/usr/bin/env node` works, and any `rig`, Python or Node the seat's PATH already finds still wins.
Limits: `rig` and Python must still be installed. Refocus's report of repeated failures (`refocus-health.cjs`), and the refocusing and operating-model skill scripts when run directly from a minimal shell, still need Node on the PATH; that's a follow-up. Nothing is refused, and there's no new setting or step. Native Claude hook loading wasn't run.
+43/-10 in 5 files: source and plugin assets +9/-6, tests +33/-3 (3.67 test lines per added source line), regenerated skill digest +1/-1.
When an agent advances a workflow step (`rig workflow project`, `route`, `resume` or `abort`), the record now names the agent that made the call. Until now it recorded whatever `--actor-session` the command carried, and the commands OpenRig generates for a step filled in the packet's owner, so a step's history could name an agent that never touched it.
The four routes take the caller from the transport identity the CLI already stamps, through the same helper other routes use. The caller's identity supersedes a declared actor; a caller with no identity is recorded under its declared actor, labelled as claimed; a relayed caller is recorded no stronger than the relay carried it. The closing transition, the next packet and the wake intent carry that provenance, with no new field. When a known caller projects a packet another seat owns, `project`'s response says so in one line; nothing is refused and nothing extra goes to the owner. Generated commands no longer name an actor, and `--actor-session` is now optional.
Two results change. A request with neither an identity nor an actor is still a 400, but its body is now the shared `actor_required` error instead of `{"error": "actorSession is required"}`, so a client matching the old string sees a different body. A request with no identity whose declared actor is only whitespace is now refused. A non-blank declared actor without an identity still works.
The recorded agent is who projected the step, not proof of who built, reviewed, tested or approved the work.
Refs #1710.
+233/-65 in 14 files: source +83/-47, tests +136/-8 (a new five-case route-to-store test), docs 8 lines, and the regenerated skill digests.
A mode applied with `--until` recorded its end time but nothing ended it, and there was no account of what happened while a person's mode was on.
Now, when a mode ends, by "I'm back" or at the end time they chose, the operator can give the person an account built from the records: the mode and its settings, which of their own newer choices still stand, what's pending or failed, the mode they're in now, each decision made for them and which can't be undone, and what's waiting for them. What no record supports, such as work done or failures elsewhere, is listed as not tracked. A late click on an ask that was already decided says who decided it and what. The operator explains a mode before its first use, and agents that would ask the person read the decision room first.
The account is read-only (`rig gateway human mode account <person> <applicationId>`) and reuses the existing mode, decision and hold reads. It shows only what was that person's: an ask that has since moved to someone else is listed as stale without its current summary or state, and an ask that was delivered to them and handled afterwards isn't listed. The scheduled end is a `mode-scheduled-end` policy on the existing watchdog engine, armed with the application and ending only that application. It creates at most one notice row (`qitem-mode-end-<applicationId>`): to the kernel operator, otherwise the seat that applied the mode if the queue accepts it, otherwise the person's own address as an update. If the person registry can't be read, the notice waits and is sent once it can; if no one can receive it, the job ends and records why. The queue's destination check moved from `startup.ts` into its own module, unchanged, so the timer can use it. The late-click reply goes through the same Slack escaping and redaction as the other replies. `mode apply --until` without `--tz` uses this machine's zone and says so. The guidance is in the kernel operator's `role.md` and `messaging-the-human`, mirrored, with the skill digests regenerated.
Limits: a mode applied with `--until` on main before this change has no timer and still ends only by hand (no published release had `mode apply --until`). The scheduled end runs on the 60-second cadence, and after downtime it ends on the first pass with both times in the account. Without quiet hours, an ask can still be posted between being created and decided; a late click then names the decision. Nothing that works today is refused; the account route's three errors (`application_not_found`, `still_on`, `modes_unavailable`) are its own. Native, real-Slack and operator journeys weren't run.
+948/-44 in 23 files: source +452/-38 (+37/-25 of it the destination check's move), tests +376/-3, guidance, docs and digests +120/-3.
The queue accepted `state=done` with `closureReason=blocked_on` and silently dropped the work it was meant to wait on.
That request is now rejected with HTTP 400 `invalid_closure_reason` before anything changes: no update, transition, nudge or completion effect. The message says `done` is final and shows the command to use instead, `rig queue block <id> --on <child>` (or `rig queue update <id> --state blocked --blocked-on <child>`). The same correction is returned for a row that's already done. Ordinary completions, the other closure reasons, handoffs and `blocked` records with `blocked_on` are unchanged, and existing rows aren't rewritten. The `queue-handoff` skill and the coordination doc now teach the block command for waiting on another item.
An agent could write a record after moving a Codex home's seats between subscriptions (rig provider moves record) and read it back (rig provider moves, rig provider moves show), behind the off-by-default provider.subscription_moves setting. Nothing acted on a record: no projection, health check, scheduler, launch or restore path read the event it wrote. Its only readers were its own read-back commands, the event-type union and the setting's declarations.
The module, its three routes, the three CLI commands, the setting (daemon, CLI and TUI) and the event type are removed, along with the CLI reference rows and the what-you-can-do sentence. Subscription moves themselves are untouched: rig provider status, rig provider precheck and rig provider switch, where the daemon runs a precheck-gated switch.
The openrig-user skill changes in two places. Its reporting step now has the agent report the same facts (home and machine, from and to, the reason, the readings, each seat's result with evidence, and the peers) to whoever asked for the move, as a queue item, instead of writing them to the removed record. Its "Manage subscriptions across a fleet" section applied only when the removed setting was on and the person had asked; it now applies when the person has asked, which remains the opt-in. The skill digests are regenerated.
The review-team skill opened proportionately, then demanded that every claim be verified and that unverified findings go unreported, and its deep method added a context-confidence admission step, every-finding cross-examination and a roundtable everyone had to post to. That turned reviews into rounds.
A material finding now says the user consequence, the affected path and how the reviewer knows (an observed result, source reasoning or an untested concern), and whether this change introduces, exposes or leaves the issue. Severity is kept separate from whether it blocks under the project's own acceptance rules, and a serious untested concern is labelled rather than dropped or turned into an automatic veto. Everyday review opens with two questions: does the change solve the user's problem with a maintainable design, and what about affected contracts, invalid input, state transitions, recovery, consumers and unnecessary duplication. Confidence scores and provider stereotypes are replaced by choosing reviewers for independence, capability and observed work.
For the explicitly selected deep method: reviewers form independent first views from the context and source, the decision owner then asks for evidence or a counterexample only on disagreements that could change the disposition, and the result is one disposition with severity, blocking rationale, evidence limits and any dissent kept visible. There is no fixed number of rounds, no requirement that everyone answer every finding, and preparing context is part of the review, not a gate before it. A protocol the project specifically selected stays controlling. Entry rules and explicit deep-review selection are unchanged; canonical and daemon copies are byte-identical, and the skill digests are regenerated.
The verification skill opened proportionately, then demanded fresh evidence in the current message for any claim, mandatory self-execution and a gate before every status, which turned ordinary progress into reruns. It now has one rule: before claiming a verifiable result, inspect evidence that supports that result for the candidate and environment you name; reuse an existing result while its inputs still hold, and rerun the check when they change or are uncertain; say whether you ran it or inspected another owner's evidence. Required project checks still apply, "tests pass" still needs output for the named candidate, and an agent's success message or a diff alone is still not evidence. The rationalization table and the fear paragraph are removed rather than answered with another layer.
The skills router's one-line summary of this skill now says the same, and its line for the review team names grounded findings. Two short cold references are added: refactoring, linked at the development team's build-and-verify step, and performance claims, linked from verification. They adapt methods from Cursor's pstack plugin, with attribution, and set no run count. Canonical and daemon copies are byte-identical, and the skill digests are regenerated.
The compaction-restore skill told a restored agent when it may resume (after the read-depth table and the reconnect note exist) but not how. It now ends with a short "Then resume" section: resume the outcome the current instructions, standing duties and assigned work select; use existing records and the recap to recover the next action and the evidence already earned; check uncertain effects before replaying work; don't let available skills or historical suggestions widen scope or create required stages; use authorized help within your remit; and route a missing decision to its owner while continuing unaffected work.
It replaces a guardrail that repeated the skill's own hold check, its post-read check for a new hold, and its reconnect step's "if a hold stands, the next step is waiting". Those three still say a hold binds. The skill digest is regenerated.
Three openrig-core skills now say when an agent can rely on what a queue write already returned, and when it should look at a peer's screen, so agents make fewer redundant calls without dropping a check that matters.
- **After a queue write** (`openrig-user`, with a pointer in `queue-handoff`): use the write's response when it shows what you need; create, claim and update return the row, and handoff returns both rows. Read the row back when the response doesn't show it: an INDETERMINATE outcome or `qitem_body_not_saved` (reconcile by the original ID before any retry), compact or truncated output, a transition note or successor the output omits, or downstream evidence such as the recipient's wake or a later claim. A team rule that asks for a read-back still applies.
- **Checking peers** (`forming-an-openrig-mental-model`): start from `rig ps --nodes` and the queue, and capture a peer only when you need to see its screen.
Unchanged: the check before resending after an ambiguous result, identity checks after restore, handover and boot, held-row checks, the operator-relay capture, the capture before answering a prompt, and outcome and consumption verification. The skill digest file is regenerated by `mirror-skills`. Guidance only; no runtime or permission change.
`rig launch`'s description said "Launch or relaunch a node in a running rig", but a node that's already running is left alone ("already running … (not relaunched)"). The help now says what it does, and points a person who wants a fresh occupant for a running seat to the command that exists.
- **The description:** "Launch a node in a running rig, unless it's already running". The help after the options names `rig seat launch <seat> --fresh --stop --reason <why>`, with `--plan` to preview it.
- **The already-running message** adds one line with a command that runs as printed: `rig seat launch <logicalId>@<rig name>` when the rig was named, else the bare logical id. `--json` output is unchanged.
- **The `openrig-user` skill:** its two `rig launch` lines said "relaunches"; they now say it launches a seat that isn't running and name the same route. The skill's recorded digest in `scripts/skill-edge-digests.generated.json` is updated to match.
Text only; no behaviour changes.
The missing-pane repair (`rig reconcile-session --repair-missing-pane`) is named where people meet the problem:
- **The compaction refusal** for a protected seat with no recorded pane says both fixes refuse while typing protection is on, how to turn it off and back on with the person's agreement, that the repair keeps the session and resume token, and that plain reconcile adopts into a new session row and re-captures the resume token when it can, with conversation continuity unverified.
- **The send refusal** for an unavailable or changed pane names the repair.
- **The as-built CLI reference and the `openrig-user` skill** list `--repair-missing-pane`; the skill's recorded digest is regenerated.
- **`rig config --help`** lists `transport.local_user_guard`, and **`rig ask --help`**'s exit codes cover the `--wake` refusals.
Text and help only; no behaviour change.
Mike Schwarz