@openrig/cli 0.6.11 → 0.6.12

package/daemon/docs/reference/slack-app-setup.md

@@ -30,8 +30,13 @@ been confirmed against a real creation run. Slack's form may ask for something t
 not fill in; if so, follow the form.
 
 1. Open the link from `rig slack manifest --url` in a browser.
+   > **Note on Slack's manifest dialog:** If opening the link results in an empty manifest `{}`
+   > or Slack reports an error translating the manifest, copy the output of `rig slack manifest`
+   > (run without flags) and paste it directly into the **YAML** tab in Slack's "Create an app from
+   > an app manifest" dialog.
 2. Sign in to Slack if asked, pick the workspace, review the prefilled manifest, and click
-   **Create**.
+   **Next**, then **Create**. (If **Create** stays disabled, go **Back** and check that a
+   development workspace is selected and the manifest step shows no error).
 3. Under **Socket Mode**, confirm it is enabled. Enable it if it is not.
 4. Under **Basic Information → App-Level Tokens**, generate a token with the
    `connections:write` scope and copy it (it starts with `xapp-`).
@@ -63,10 +68,10 @@ groups:
   a member of, and reading channel details.
   `rig slack verify` checks these.
 - **Feature scopes**: `files:read` (download attachments people send), `files:write` (upload
-  attachments to Slack), `app_mentions:read` (receive @-mentions of the app), and `reactions:read`
-  (receive emoji reactions). `rig slack verify` warns when one of these is missing (if Slack returns
-  the granted scopes) but does not require them, so a READY from verify does not prove attachments,
-  mentions or reactions will work.
+  attachments to Slack), `app_mentions:read` (receive @-mentions of the app), `reactions:read`
+  (receive emoji reactions), and `users:read` (identify a named bot, below). `rig slack verify` warns
+  when one of these is missing (if Slack returns the granted scopes) but does not require them, so a
+  READY from verify does not prove attachments, mentions, reactions or named bots will work.
 
 If a feature scope was not granted, the effect differs by feature:
 
@@ -78,8 +83,10 @@ If a feature scope was not granted, the effect differs by feature:
   Only `rig slack verify` warns that the scope is missing; nothing reports the missing events.
 - **Reactions** (`reactions:read`): Slack does not deliver `reaction_added` events, so a reaction
   on an ask doesn't reach the asking agent. A reply in the ask's thread still does.
+- **Named bots** (`users:read`): Slack refuses the bot lookup, so a named bot's posts are not
+  delivered, and the daemon log names the refusal. Nothing else changes.
 
-So after installing, compare the granted scopes Slack shows for the app with all seven scopes that
+So after installing, compare the granted scopes Slack shows for the app with all eight scopes that
 `rig slack manifest --json` lists.
 
 The app subscribes to messages in public channels it is a member of (`message.channels`), to
@@ -161,21 +168,142 @@ rig slack channel-map remove pr@my-rig
   is left to the retry of retained posts.
 - **Replies and new messages.** A reply in an item's thread reaches that item's seat, in any
   channel. To answer it in the same thread, the seat sends `rig queue create --human-intent update
-  --reply-to <the inbound reply's row>`. A message the human starts (or a reply in a thread OpenRig does not know) goes to
-  the connector's inbound destination, whichever channel it is in. Missed-message recovery
-  (below) covers the default channel only.
+  --summary "<subject>" --reply-to <the inbound reply's row>`.
+  - **A new message a person starts in a rig's channel** goes to that rig's representative, the
+    seat the rest of its rig reports to (its one `delegates_to` root). To send it to another seat,
+    name it: `rig slack channel-map set my-rig C0EXAMPLE1 --inbound lead@my-rig`. A rig entry on the
+    connector's default channel only sends that rig's posts there: new messages in the default
+    channel still go to the inbound destination, unless the entry names `--inbound`.
+  - **Every other new message,** in the default channel or a seat's channel, goes to the
+    connector's inbound destination, as does a reply in a thread OpenRig doesn't know, or a rig's
+    channel whose representative can't be found.
+  - **Answers come back to where the person asked.** A person's new message is the root of its
+    answer: when the seat it reached replies with `--reply-to` that message's row, the answer and
+    later updates land in the person's thread, in the channel they used.
+  - Missed-message recovery (below) covers the default channel only.
 
 Invite the app to every mapped channel (`/invite @OpenRig`). `rig slack verify` checks
 membership in the default channel and every mapped channel, and reports NOT ready until the
-app is in all of them. A saved change reaches a running connector when it next rewires:
-`rig slack disable` then `rig slack enable`, or a daemon restart. The TUI's Connections page
-says whether the running configuration matches the file.
+app is in all of them. A saved change reaches a running connector when it next rewires, which a
+daemon restart does (`rig daemon stop`, then `rig daemon start`). `rig slack disable --reason
+"<why>"` then `rig slack enable` rewires too, but alerts still waiting to be posted when it's
+re-enabled are treated as already seen and aren't posted. Only an earlier post that failed or
+didn't finish still posts: an alert whose row is still open, a decision-resolved notice, or a digest. The TUI's Connections page says whether the running
+configuration matches the file.
 
 The map is stored as `channelMap` in `slack-connector.json`, as a list of `{ "match", "channel" }`
-entries. Saving refuses any other field. A field written by a newer OpenRig is ignored when the
+entries, each with an optional `"inbound"` seat. Saving refuses any other field. A field written by a newer OpenRig is ignored when the
 connector reads the file, and `rig slack status` names it. Private channels and direct messages
 are not supported targets.
 
+## Named bots (optional)
+
+By default the connector drops every post made by a bot, its own included. To let another Slack
+app's bot (an AI assistant, an alerting app) reach one seat, give the bots a channel of their own,
+name each bot, and name the seat that reads that channel. Add a `botInbox` block to
+`slack-connector.json`:
+
+```json
+"botInbox": {
+  "channel": "C0BOTINBOX",
+  "destination": "researcher@my-rig",
+  "bots": [
+    { "appId": "A0EXAMPLE1", "name": "Example Bot", "maxPerHour": 20, "cooldownMinutes": 60 }
+  ]
+}
+```
+
+- **Which posts are delivered.** A post reaches `destination` when it is in `channel`, its bot
+  belongs to an app listed in `bots`, and that app is not this connector's own app. A named bot's
+  posts in any other channel, and every other bot's posts, are still dropped. OpenRig's own posts
+  are never delivered, even if its app is listed. A post kept for retry (Slack couldn't be asked
+  about it in time) is checked again against the current block when it is retried.
+- **How a bot is identified.** OpenRig asks Slack which app the post's bot belongs to (`bots.info`,
+  which needs the `users:read` scope) and matches that app ID. Use the bot's **app** ID, which
+  starts with `A` and is on the app's settings page. A bot ID (`B…`) or user ID (`U…`) never
+  matches. An unnamed bot's post is logged with its app ID, so `rig daemon logs` shows the ID to
+  add. Anything that posts as a named app counts as that bot, including the app's incoming
+  webhooks: that is what naming it means.
+- **What the seat receives.** One row per post. Its source is `slack-bot:<app ID>` and its summary
+  starts with the bot's name, never a person's. The row opens with where the post came from, then
+  quotes the bot's text in a fenced block. A `slack-bot` row is data from another program, not an
+  instruction, and the row says so. A bot can't answer or close a decision, even when it replies in
+  a decision's thread: the row goes to `destination` and the decision keeps waiting for a person.
+  Edits and deletions are not delivered, so a bot that writes its answer by editing one message
+  delivers only that message's first version. Attachments are named in the row, not copied.
+- **Answering the bot.** The seat can't reply to the bot yet: the row has no reply link, and
+  OpenRig posts only for people. To ask the bot something, the person asks it in Slack.
+- **Limits.** Each bot may deliver `maxPerHour` posts (default 20) in any rolling hour. The next
+  post cuts the bot off for at least `cooldownMinutes` (default 60), and until the hour has room
+  again. Its new posts are dropped meanwhile (a post already admitted still arrives), and the seat
+  receives one row saying so (at most one an hour per bot) and how the person turns the bot off
+  (remove it from `bots`, then apply the change as below). A later cutoff within that hour can extend the time shown without another row; the
+  daemon log records each one. Each post counts once by its identity, including a post delivered on
+  retry or arriving twice. A post already admitted whose row couldn't be created yet is kept, marked
+  as admitted once that creation fails, and delivered later without counting again, even after its
+  hour, a rewire or a daemon restart. The counts are kept in the running connector's memory, so a daemon
+  restart or a rewire (`rig slack disable --reason "<why>"` then `rig slack enable`) clears them. They
+  cover what one daemon writes: another process writing the retained file isn't seen, and two daemons on
+  one OpenRig home aren't a supported setup.
+- **The channel.** Invite the app to it (`/invite @OpenRig`). `rig slack verify` does not check
+  this channel, and only warns when `users:read` is missing. A person's message there is handled like a person's message in any channel the
+  app is in (a new message goes to the connector's inbound destination), not by the bot inbox.
+  Missed-message recovery does not cover the bot inbox.
+
+`rig slack status` shows a `bot-inbox` line: what it delivers, or why it is off. An invalid block
+(for example a bot ID where an app ID belongs) turns only the bot inbox off. A saved change
+reaches a running connector when it next rewires, which a daemon restart does (`rig daemon stop`,
+then `rig daemon start`). `rig slack disable --reason "<why>"` then `rig slack enable` rewires too,
+but alerts still waiting to be posted when it's re-enabled are treated as already seen and aren't
+posted. Only an earlier post that failed or didn't finish still posts: an alert whose row is still
+open, a decision-resolved notice, or a digest.
+
+## One app across machines (optional)
+
+Slack delivers each event of an app to one of its connections, so one app can serve several
+OpenRig machines only if one machine, the hub, holds the connection and relays each other machine's
+channels to it. Each machine still decides who its messages reach, keeps its own threads and
+decisions, and posts its own replies.
+
+- **On the hub:** the bot token and the app-level token, as usual, plus `forwardChannels` in
+  `slack-connector.json`, one entry per channel another machine owns:
+
+  ```json
+  "forwardChannels": [
+    { "channel": "C0EXAMPLE3", "host": "vps04" },
+    { "channel": "C0EXAMPLE4", "host": "vps04" }
+  ]
+  ```
+
+  `host` is that machine's id in the hub's host registry (`rig host list`). It needs an http
+  entry, which `rig host pair` writes with that machine's token; the hub sends it with each relay,
+  and the machine checks it when it has `OPENRIG_AUTH_BEARER_TOKEN` set.
+- **What the receiving machine trusts:** a relayed event comes from whoever holds that machine's
+  daemon token (or, with no token set, anything that can reach its daemon), not from Slack directly, and nothing checks Slack's own signature on it. The
+  machine still looks up the sender in its own list of people, but on a relayed event that's no
+  proof a person just typed or clicked it in Slack: it trusts the caller for where the event came
+  from.
+- **On every other machine:** the same app's bot token only, with no app-level token, so it opens
+  no connection of its own. Set its default `channel` to its own channel and, for a rig's channel,
+  a channel map entry. Its connector is enabled as usual. Its `rig slack status` reports
+  `relayedInbound`: that it can take relayed events, and how many have arrived since it started.
+  It also retries its own kept events every five minutes, including any it kept before it stopped
+  holding a connection of its own, so those still land.
+- **What happens to a message:** the hub relays the event, a reaction or a button click untouched
+  to the machine that owns the channel. That machine handles it exactly as if it had received it:
+  who may send, where it goes, its thread and its decisions. If the relay fails (the machine is
+  down or its registry entry is wrong), the hub keeps it and retries every five minutes, after its
+  own kept events and clicks; `rig slack status` counts it in the dead-letter backlog. A machine
+  that's down costs one attempt per retry: its other relays wait for the next one. A relay the
+  machine keeps refusing is kept and retried with no limit, because dropping it would lose a
+  person's message.
+- **Who answered:** every post ends `from <seat> on <machine>`, using the machine's host id (set
+  it with `host.name`).
+- **The hub's own channels** are handled on the hub, as before. A channel can be relayed to one
+  machine only, and never the hub's own default channel.
+- **Not covered yet:** `rig slack verify` on the hub doesn't check the app's membership in relayed
+  channels, and missed-message recovery covers the hub's default channel only.
+
 ## Reconnect recovery and status
 
 The daemon scans available top-level messages and replies broadcast with **Also send to

package/daemon/docs/reference/topology-naming.md

@@ -23,6 +23,15 @@ Runtime, model and account belong in configuration. Changing a provider does not
 change the role's name. Keep machine and instance identifiers stable rather than
 renaming them whenever their workload changes.
 
+What a seat runs has its own words:
+
+| Term | Meaning | Example |
+| --- | --- | --- |
+| Runtime | What a seat runs: a harness, a terminal, or the stub (a scripted stand-in used in tests). It's the rig spec's `runtime` field and the TUI's runtime column | `claude-code`, `codex`, `terminal` |
+| Harness | The agent software around a model | Claude Code, Codex, Pi |
+| Community harness | A harness an outside contributor maintains. It's installed as a preset under `$OPENRIG_HOME/community-harnesses/`, listed by `rig community-harness list`, and OpenRig doesn't test it | A preset's name in a member's `runtime` |
+| Terminal | A seat with no agent: a shell for infrastructure processes | `runtime: terminal` |
+
 ## How the software teams grow
 
 | Team | Logical seats |

package/daemon/docs/reference/whats-new.md

@@ -1,7 +1,7 @@
-# What changed in OpenRig 0.6.11
+# What changed in OpenRig 0.6.12
 
-This note is for an agent on an install that was just upgraded to 0.6.11. It lists only what behaves differently from
-0.6.10 and what to do about it. For everything OpenRig can do, read the capability map:
+This note is for an agent on an install that was just upgraded to 0.6.12. It lists only what behaves differently from
+0.6.11 and what to do about it. For everything OpenRig can do, read the capability map:
 `rig context get onboarding-width/public-what-you-can-do.md`. Each release replaces this file, so
 `rig context get reference/whats-new.md` describes the installed version once the upgraded daemon is running. Without
 a running daemon, read `$OPENRIG_HOME/reference/whats-new.md`. The daemon refreshes that copy when it starts, so right
@@ -9,160 +9,181 @@ after an upgrade it can still hold the previous version's note.
 
 ## After the upgrade
 
-- **Restart the daemon** (`rig daemon stop`, then `rig daemon start`). One migration runs on the first start: `103`
-  adds one column to `sessions`, `intentionally_stopped`, which is 0 for every existing row. There are no migrations
-  `100` or `102`. The bundled openrig-core plugin stays at 0.1.9; two of its files changed.
-- **Two new switches, both off by default:**
-  - `output.compact` (or `OPENRIG_OUTPUT_COMPACT`): the seven queue write commands (`rig queue create`, `claim`,
-    `unclaim`, `update`, `block`, `handoff` and `handoff-and-complete`) print a short receipt instead of the whole
-    row, and `--full` prints the whole row. While it's off their output is unchanged, `--full` is accepted, and
-    `rig config` lists the key.
-  - `provider.usage_windows` (or `OPENRIG_PROVIDER_USAGE_WINDOWS` in the daemon's environment): `rig provider status
-    --refresh` reads a Codex login's usage windows once. While it's off, `--refresh` says how to turn it on and exits 1.
+- **Restart the daemon** (`rig daemon stop`, then `rig daemon start`). Twelve migrations run on the first start,
+  whatever you use: `100`, `104`, `105`, `107` to `115`. They add columns and tables for the typing guard's modes, a
+  seat's saved effort, Claude's cost estimate, Pi usage, mode and posture categories, workflow scope, seat environment
+  values, the Codex `--no-daemon` record and `sessions.agent_app`; build two indexes for recent queue activity (about
+  10 to 12 MB on a long-running install); and rebuild the Slack thread map. There are no migrations `102` or `106`.
+- **Claude seats now run the openrig-core plugin's hooks.** The bundled plugin goes from 0.1.9 to 0.1.13. A Claude
+  seat whose plugins include `openrig-core` (every shipped agent spec selects it) starts with `CLAUDE_CODE_PLUGIN_DIRS`
+  pointing at OpenRig's copy, so the activity relay, the compaction save and restore hooks and refocus actually run. It
+  needs Claude Code 2.1.280 or later, which nothing checks. A running seat picks it up at its next launch, restore or
+  handover. The refocus hook may take up to 60 seconds, so a hung refocus can hold a prompt that long.
+- **Six new settings, all off except one:** `output.whoami_peers` (8, used only while `output.compact` is on),
+  `bundle.services_enabled`, `provider.subscription_moves`, `usage.pi_cost_facts`, `usage.pi_openrouter_charge` and
+  `transport.verify_input_box`. See "Off by default" below.
 
 ## Output that changed shape
 
-- **`rig queue create --verify` reports `outcome: "claimed"`** for a claimed row whose wake wasn't confirmed, instead
-  of `indeterminate`. A claim is pickup, not proof the body was read.
-- **`rig queue create --verify` to a registered person who is also a seat with a pane reports the Slack side too.**
-  Beside the terminal wake it adds a `gateway` object: `posted` (`connectorAccepted: true`), `transport-failed` or
-  `never-posted` (`connectorAccepted: false`, with the detail), or `still-pending` (`connectorAccepted: null`). The
-  wait is still bounded by the existing 30-second default, and it can use all of it even when Slack isn't set up or the
-  row won't be posted; the Slack side then reads `still-pending`. Posted isn't read, and "This is not a failed handoff"
-  isn't shown when Slack reports a failed delivery. `GET /api/queue/:qitemId` returns `ownerNotificationLevel`, or
-  `null`.
-- **`rig queue whoami --work-candidates` returns up to 50 held and 50 next rows,** with `heldTruncated` and
-  `nextTruncated`. `heldAndNextTruncated` now means either list was cut. With `OPENRIG_REFOCUS_WORK_PACKET` on (off by
-  default, as in 0.6.10), the refocus work packet lists held and next work separately, up to 50 each.
-- **`rig ps --nodes --json` carries `intentionallyStopped`,** and `rig ps --nodes` shows `usage_limit` under REASON for a
-  Codex seat at its usage limit.
+- **Exit codes:** eleven client-fixable `rig queue update` refusals now answer HTTP 400 and exit 1 instead of 500 and
+  exit 2 (`blocker_not_found`, `blocker_not_live` and `blocker_malformed` still exit 2). `rig ask` exits 1 for an
+  unknown or ambiguous rig. `rig compact` exits 1 (was 2) for `pane_unknown_protected`, and its route answers 409 (was
+  502). Over the shared transport, a write that throws without a code makes `rig send` exit 1 with HTTP 409 instead of 2
+  with 500, and a guarded send whose text was written returns `sent: true` with `inputPhase: "written"`.
+- **`rig compact` and `rig compact --state` add a `compact` result:** `submitted_unconfirmed` (shown as "submitted,
+  unconfirmed"), `uncertain` or `not_sent`. "Submitted" means `/compact` and Enter reached the seat, not that compaction
+  ran.
+- **`rig capture --lines N --json`** adds `activity: "unknown"` and `activityNote` when lines were cut.
+- **`rig start --last --json`** carries `keptDown` (always) and `warnings` (`seat_status_unreadable`).
+- **`rig queue show <id> --full`** on a closed row adds `closingTransition`; plain `rig queue show` on such a row reads
+  `readView.complete: false` and lists it in `omittedFields`. `rig queue show` returns `resolution` when a close stored
+  one.
+- **After `rig down`,** `rig ps`, the TUI and the rig summary read the rig `stopped`, not recoverable, and
+  `hasLiveAgents` can read `false`.
+- **`rig seat status`** reads `Typing guard: on (hold)` for hold, and its JSON's `desired` and `effective` mean hold only;
+  `desiredMode` and `effectiveMode` give the mode.
+- **`rig usage top`** measures tokens and rates within one conversation and one window, so figures can drop and more
+  seats read `insufficient_samples`.
+- **The execution view** binds a row to a mission by its exact `mission:` tag first; `q1_lanes[].waiting` and
+  `folded.merge_report` are new.
+- **Smaller:** `rig create --json` carries `detail` on failure; `rig status --json` is new; `rig mcp serve` lists 23 tools
+  (five queue tools added); a JSON body of `null` gets 400 `invalid_json`; `GET /api/events` takes `?replay=`; a Slack
+  seat post's sender line ends `on <host id>`; `rig ps --nodes` `resumeCommand` can carry `--no-daemon`.
 
 ## Seats and restore
 
-- **A restore no longer starts a seat fresh when an earlier occupant left a resume token.** If a seat wasn't running
-  when the snapshot was taken, but an earlier session recorded a resume token, `rig up --existing` and `rig launch`
-  stop that seat at `awaiting-decision` and start nothing, because the token doesn't prove that conversation can still
-  resume. `rig launch` of such a seat exits 1 where it used to start it fresh. The message names the command that
-  starts it fresh on purpose. See the known gap below for how this shows in the rig status API.
-- **In a restore of a rig whose seats are in pods, a seat is rolled back as unresumable only when its runtime reports
-  the conversation missing.** When Claude, Codex or Pi reports that, the seat goes back to `awaiting-decision` and
-  nothing starts, instead of a failed launch that left the new pane behind. A rig where every seat ends this way reads
-  `partially_restored` instead of `failed`; the exit code is 1 either way. A Claude that exits to its shell for another
-  reason keeps 0.6.10's result: the seat is reported failed and its pane is kept, so you can read what happened. Restores
-  of rigs without pods keep their earlier handling.
-- **`rig seat launch --fresh --stop` checks before it stops anything.** A seat with a still-live older session is
-  refused before the current agent is stopped; 0.6.10 stopped it first. `--plan` previews a fresh launch without
-  changing anything and exits 0 even when it would be blocked. `--reason` is required only to execute; leaving it out
-  reports `missing_reason`.
-- **A seat you stop on purpose no longer makes its rig read `degraded`.** `rig seat stop` records the stop, and `rig ps`
-  and the TUI leave that seat out of the rig's state; running counts still exclude it. A rig whose seats were all
-  stopped this way reads `stopped`.
-- **Restart one Codex seat in place, on Linux:** `rig seat restart <seat> --keep-conversation --reason "<why>"`
-  restarts it in its own pane on the same conversation, so it starts again on whatever account its Codex home now
-  holds. It doesn't switch accounts itself. Before it stops anything, it checks that the seat is a Codex seat OpenRig
-  launched, in a single pane, with a conversation it can prove, and that relaunching wouldn't change the running
-  settings; any doubt refuses with nothing stopped. `--plan` runs every check and stops nothing.
-  `--verify --expect-account <account>` reports `moved` only when a tool turn has completed in the same conversation
-  since the restart and Codex's status names that account.
-  On macOS, a request that gets as far as reading the running process refuses before stopping the seat, because that
-  reading depends on `/proc`.
-- **A forked Claude seat launches with its own session ID** (`rig fork`, or `session_source: fork`), so strict restore
-  and clear-attention can verify it as its own conversation. Forking a Claude seat needs Claude Code 2.0.73 or later,
-  which OpenRig doesn't check. Forks launched before this keep reading `mismatch` until they're relaunched.
-- **Seats no longer inherit the launching Claude Code or Herdr session's identity variables,** such as `CLAUDECODE`.
-  If removing them fails, the launch goes ahead with a warning.
-- **A member's `cwd` in a rig spec can be `~`, start with `~/`, or use `$VAR` or `${VAR}`,** expanded from the daemon's
-  environment, when the path as written doesn't exist. `rig up` warns on stderr when it chose `/` as the launch folder
-  itself.
-- **A late readiness result no longer overwrites a newer launch attempt.**
-
-## Sends and wakes
-
-- **`rig send --wait-for-idle N` waits before it takes the seat's delivery lease,** so other sends and queue wakes to
-  that seat aren't held behind a long wait. N is now a deadline from the start of the wait, including any time spent
-  waiting for the lease. A timeout names the wait you asked for.
-- **A parked seat whose occupant is known isn't woken again for the same rows after a wake was delivered,** until it
-  updates one of them or one changes state. A failed, refused or unrecorded wake still repeats at the next park, and a
-  new occupant gets its first wake. "Delivered" means the wake was typed into the seat's terminal, not that the agent
-  read it.
-- **`rig send --verify` confirms enveloped multi-line messages that the agent's screen indents,** and queue wakes use
-  the same check.
-- **A Claude footer in auto, bypass or plan mode on the last line reads idle** when no activity hook is reporting.
-- **A failed Pi or OMP turn shows the provider's own reason** when it gives one.
-- **A `handed-off` closure with no visible successor** gets the same custody advisory and stuck-sweep finding as a
-  `done` closure.
-
-## Status
-
-- **A Codex seat at its usage limit stays `unknown` with reason `usage_limit`** while its screen redraws, instead of
-  reading `running`. It clears when a readable screen shows no banner, or when Codex shows it's working again. See the
-  known gap below.
-- **`rig ps` takes a rig's running count and status from the same set of sessions as `rig ps --nodes`.**
-- **`rig whoami --full --json` shows a Codex seat's `runtimeContext.threadId`** when its stored conversation ID was
-  verified resumable.
-- **The TUI says when a queue sample hit its cap or failed to load:** counts read `N+`, a seat missing from the sample
-  shows `?`, and Pulse no longer lists a NEEDS YOU item a second time. The caps count the whole host, so a quiet rig can
-  read `?` while another rig is busy.
-- **The TUI Topology table's Q, WORK and NOW columns fill again** on drilled views and on a seat's page.
-
-## Smaller fixes
-
-- A Slack reply sent with "Also send to channel" in the default channel is recovered after a connection gap.
-- `rig config set daemon.port` refuses a port outside 0–65535, and a port like that from the environment or
-  `config.json` falls back to the file or default with a warning. `rig daemon start --port` refuses one too, with exit 1.
-- Parallel `rig scope slice create` calls get different slice numbers. A number is never reused, and each create leaves
-  a hidden `slices/.nn-NN` claim file.
-- `rig proof show` and `rig proof judge` take `--project <id>` or a `<project>:` scope prefix. Scope readiness for a
-  project selected in the TUI uses that project's own root.
-- The chat send and topic routes return 400 before storing anything for payloads that used to fail with 500;
-  `/api/wake-resolve` answers a fractional or non-numeric generation with its usual "does not exist" reply; watchdog
-  registration refuses a `scan_interval_seconds` that can't be turned into a number (non-numeric text, a boolean, an
-  empty array); and unmanaged-pane discovery matches agent
-  process names exactly, plus `claude.exe` and names cut to 15 or 16 characters.
-- The `rigs` and `openrig-skills` skill descriptions split by who is asking: a person in their own session, or an agent
-  inside a rig.
-- A new reference page covers keeping a watch for a person with today's queue commands, installed at
-  `$OPENRIG_HOME/reference/keeping-a-watch.md`. See the known gap below.
+- **`rig start --last` leaves down a rig stopped on purpose** (`rig down` or `rig seat stop`) and prints how to bring it
+  back: `rig start --rigs <rig>`, or `rig up '<name>' --existing`.
+- **An ordinary terminal seat relaunches fresh on restore** and re-runs its startup actions; don't answer `--fresh` for
+  it. A missing required startup file for such a seat blocks the whole restore before anything launches.
+- **Restore stops a seat whose current runtime differs from its snapshot's,** before launching it; `--fresh` doesn't
+  bypass it. Restore from a snapshot taken with the seat's current runtime.
+- **A slow Claude restore ends `attention_required`, not failed:** "Claude resume did not finish within Ns; Claude may
+  still be starting, so the launch was kept". Look at the pane, and once Claude is up run `rig seat clear-attention`.
+  Each such seat can add up to about the readiness timeout, one after another, so `rig up` can pass its 120-second
+  wait while the daemon keeps working: check `rig ps` before running it again.
+- **"Returned to a shell" now means the process tree shows an idle shell.** "The pane shows a shell that is not a proven
+  idle shell; a launch script may still be starting …" means the seat may still be coming up. A Pi or OMP seat at a
+  bare shell reads `attention_required`.
+- **A Codex fork whose new conversation ID arrives late** stops at `attention_required` with its startup context kept;
+  let it finish starting, then run `rig seat continue <seat>`. A handover to a Codex fork can complete with `Fork id:
+  PENDING`.
+- **A seat whose startup failed for a recoverable reason** becomes ready after a successful send or capture.
+- **`rig launch` takes a rig's name as well as its ID;** a name two active rigs share stops with `rig_ambiguous`.
+- **`rig add`, single-seat `rig launch` and `rig launch --seats` wait up to 120 seconds.** A timeout still isn't a
+  rollback.
+- **A runtime `--version` check gives up after 30 seconds.** `rig bootstrap` blocks on a runtime that's installed but
+  fails its check, reported apart from one that's missing; `rig up`'s preflight fails a Claude, Codex or OMP check that
+  doesn't answer (a warning for Pi).
+- **Claude login detection:** only a current refusal reads `login_required`, not the "Not logged in" footer alone.
+- **Model pins:** `fable` now names `claude-fable-5-1`, a trailing `[1m]` is set aside, and pinned Pi seats are checked
+  (a `:high`-style thinking suffix is accepted).
+- **A custom permission policy saved with CRLF line endings** now takes effect at the next launch or restore, instead
+  of the advisory floor.
+- **`rig scope mission create`** writes `status: planned`; set it `active` to count it in `rig proof show --project`.
+  With `--workspace <project>`, missions go under the project's declared `missions.root`.
+
+## Sends, wakes and the queue
+
+- **A send to a pane in tmux copy or view mode** leaves the mode and delivers; `pane_in_mode` means the pane couldn't
+  leave its mode. Leave it in that pane, then send again.
+- **`rig send --dangerously-interact` types exactly what you give it.** Enter is added only for a complete answer
+  staged in a recognised Claude Code or Codex input box; anywhere else, put CR in the payload. With `--verify` it reads
+  unchecked.
+- **A Codex seat reads "needs you" only when a real prompt is visible;** a pending permission request reads
+  `permission_request_pending` first, and an unreadable pane gets `permission_request_unverified` after a grace.
+  Codex's `»` prompt is recognised.
+- **Managed `/compact` is short enough to run and is sent only to an idle seat.** Confirm compaction by effect: the
+  restore request, or the drop in context.
+- **A held-back (`retained`) wake doesn't use up a one-shot park timer;** it's tried again at the interval. You don't
+  need to re-arm after one.
+- **A retired watchdog doesn't deliver a late wake.** A row parked on its owner's own repeating reminder reads
+  `servedByOwnReminder` in `rig parked` and draws no extra parked-owner wake.
+- **`rig queue update <id> --summary "<text>"`** alone corrects a row's subject. Close with **`--resolution
+  "<outcome>"`** to store the outcome on the row.
+- **`rig remove` and `rig shrink`** keep a seat that gets work while stopping (409, `retained: true`) unless
+  `--fallback` takes it. A stale `rig unclaim` is refused with `session_not_current`.
+
+## New things you can do
+
+- **Set one seat's reasoning effort:** `rig seat set-effort <seat> --effort <level> --reason "<why>"` (or `--clear`); it
+  applies at the next managed launch, not to the running process. Check it with `rig seat effort <seat>`.
+- **Change a seat's stored permission policy:** `rig policy apply <policy> --seat <seat> --reason "<why>"`. `rig policy
+  current` and plain `rig ps` don't show it; `rig seat status` does.
+- **Give seats environment values:** `env:` on the rig or a member in `rig.yaml`, or `rig up <spec> --env KEY=VALUE` for
+  one launch. Never put secrets there.
+- **Scope a workflow run:** `--project`, `--mission`, `--slice` and `--tags` on `rig workflow instantiate` and `run`;
+  write a target as `member@{rig}` to follow the bound rig.
+- **Read cost:** `rig usage cost [--seat <session>] [--json]`. A missing figure is never $0, and Claude's figure is an
+  estimate, not an invoice.
+- **Hand work over without a shell:** `rig mcp serve` with `OPENRIG_SESSION_NAME` set gives `rig_queue_create`,
+  `rig_queue_show`, `rig_queue_list`, `rig_queue_claim` and `rig_queue_update`. Nothing wakes that agent.
+- **`rig status --json`:** treat `daemon.reachable: null` as unconfirmed, not down.
+- OpenRig 0.6.12 adds `rig community-harness list` for installed community-harness presets, showing their maintainer
+  and declared limits. These harnesses are not tested by OpenRig. Support is launch-only: no resume or fork, no
+  resource projection or startup-file delivery, and identity remains unconfirmed. A quiet screen is not proof that the
+  seat is idle. (#1392, #1518)
+- **Guidance:** the `rigs` skill offers to join the team before the first operator message, and offers Codex users one
+  removable rules file; `delegating-work` says to brief a peer by the model `rig ps --nodes --json` shows; the operator
+  reads `$OPENRIG_HOME/reference/keeping-a-watch.md` when asked to watch or remind, including a low-allowance warning.
+- User-visible text says "harness" for the agent software around a model, and "community harness" for one an outside
+  contributor maintains; `docs/reference/topology-naming.md` defines the terms. (#1506)
+
+## Off by default
+
+- **`output.compact`** now also shortens `rig queue show` and `rig queue transitions` (`--full` for everything) and
+  bounds `rig whoami --json` peers to `output.whoami_peers` (`--all-peers` lists all).
+- **`provider.usage_windows`** now also shows Claude's windows, each seat's configured account and, with
+  `--all-hosts` or `--hosts`, every registered machine's windows. A Claude account's current availability always reads
+  `unknown`: don't tell a person an account has room from a seat's reading.
+- **`usage.pi_cost_facts`** and **`usage.pi_openrouter_charge`** take effect when a Pi seat next launches or resumes, not
+  at once; what was recorded stays visible after they're turned off.
+- **`provider.subscription_moves`** enables `rig provider moves`. The `openrig-user` skill's section for it mentions apps
+  that don't ship in this release.
+- **`bundle.services_enabled`**, **`transport.verify_input_box`**, the per-seat draft-aware typing guard (`rig seat
+  set-typing-guard <seat> --mode draft-aware`), `rig bundle create --include-login-files`, `OPENRIG_TMUX_CONTROL=1`
+  and `OPENRIG_REFOCUS_BUDGET_MS` (4500 to 52000) each act only when chosen.
+- **The daemon runs tmux without `/bin/sh`** on Linux and macOS; `OPENRIG_TMUX_SHELL=1` at daemon start keeps the old
+  path.
 
 ## What to stop doing
 
-- **Stop expecting a restore to start a seat fresh** when an earlier session left a resume token; decide at
-  `awaiting-decision`, or use the command the message names.
-- **Stop reading `indeterminate` as the answer for a claimed row** from `rig queue create --verify`; 0.6.11 says
-  `claimed`.
-- **Stop treating `degraded` as a stopped seat's doing** after `rig seat stop`; the rig leaves that seat out.
-- **Stop counting a long `--wait-for-idle` as extra time after the lease;** N is a deadline from the start of the wait.
-
-## Known gaps in 0.6.11
-
-- **`rig seat restart --keep-conversation` supports Linux only.** Its automated tests are hermetic: they don't restart a
-  real Codex seat.
-- **The rig status API can call a running rig `blocked` because of one seat that isn't running.** It happens when the
-  latest snapshot recorded no occupant for that seat, an earlier session of the seat left a resume token, and its newest
-  session's restore policy is `resume_if_possible`. A restore from that snapshot would stop at the seat for a decision,
-  and `GET /api/rigs/:id/status` folds that forecast into the rig's status, so it mixes current status with restore
-  readiness: no seat is halted. `rig status` and the TUI's rig list don't show it for a running rig.
-- **A Codex seat can keep reading as at its usage limit** when an old usage-limit banner is followed by a submitted
-  prompt and the agent's reply, with no Codex working line and no input line below. It's recorded again every five
-  minutes, where 0.6.10 let it age out. The case was constructed from the source and hasn't been seen in a real
-  session.
-- **The keeping-a-watch page says a timer fires once; a held-back wake uses up that fire.** When the typing guard holds
-  a one-shot `--wake-after` wake back (it shows as `retained`), that held-back attempt is recorded as the timer's one
-  fire and later wakes aren't, so the timer isn't retired: it can wake the owner again at each interval while the row
-  stays set aside. A row sharing the timer through `--wake-watchdog`, after the original row was handed off or stopped,
-  loses its one wake if that wake is held back. Read the row's transitions after each wake.
+- **Stop looking up a rig's ID before `rig launch`;** the name works.
+- **Stop expecting `rig start --last` to bring back a rig taken down on purpose;** use `rig start --rigs <rig>` or `rig
+  up '<name>' --existing`.
+- **Stop counting on `--dangerously-interact` to press Enter;** put CR in the payload.
+- **Stop taking the preparation prompt's delivery as the compaction's result;** read the `compact` result and confirm by
+  effect.
+- **Stop answering `--fresh` for an ordinary terminal seat on every restore.**
+- **Stop branching on exit 2 for a fixable `rig queue update` refusal;** it's exit 1.
+- **Stop recreating a seat, or editing the database, to change its permission policy;** use `rig policy apply --seat`.
+
+## Known gaps in 0.6.12
+
+- **Managed compaction's 600-character budget** rests on one comparison on Claude Code 2.1.282, and nothing confirms
+  compaction ran.
+- **The plugin hooks haven't run through this path in a real session,** and two hook runs for one seat aren't
+  serialized: a post-compaction record can be lost or a refocus delivered twice.
+- **One Slack app across machines was simulated in one process,** never run on two real machines. Relayed events are
+  trusted from the calling daemon, and `rig slack verify` on the hub doesn't check relayed channels.
+- **`env:` values aren't secret,** and members added with `rig grow` can't carry a member-level `env:`.
+- **`rig up --env` is not forwarded for flat-node specs or v1 bundles,** although the launch may succeed. Do not rely on
+  the flag for those formats in this release.
+- **The draft-aware guard waits for idle inside the seat's delivery lease,** which can delay other work for that seat.
+- **With `bundle.services_enabled` on, `rig up <file>.rigbundle` installs into the current folder** when no `--target` is
+  given.
+- **`rig seat restart --keep-conversation` supports Linux only,** and hasn't been re-run on 0.6.12.
+- **The rig status API can call a running rig `blocked`** because of one seat that isn't running: it folds a restore
+  forecast into current status.
+- **A Codex seat can keep reading as at its usage limit** in a constructed screen case not seen in a real session.
 - **After `rig scope slice create` says it couldn't verify membership, the slice was kept.** Check `mission.yaml` before
-  creating it again: creating it again makes a second slice with the same name.
-- **The latest first-install check before this release used 0.6.10 on Linux only.** macOS was last checked with 0.6.8,
-  and native Windows hasn't been checked.
-- **Only one selected lifecycle-help command has been checked in a live Claude session;** source and parser coverage
-  is broader. If a help command still asks, report it.
+  creating it again.
+- **A Claude Code seat whose permission request was approved automatically can still read "needs input";** the Codex
+  case is fixed.
 - **Codex team seats aren't asked before lifecycle commands yet.**
-- **The send gate trusts the most recently recorded hook.** If hooks are recorded out of order, it can hold a send for
-  a question that's already answered, or miss one that's waiting. `rig capture` shows the real screen.
-- **A Codex seat whose permission request was approved automatically can still read "needs input".**
+- **The send gate trusts the most recently recorded hook;** `rig capture` shows the real screen.
 - **A launched team still writes into its working folder;** the operator says what changes before you agree.
 - **After a restart, `rig status` shows `Kernel: skipped` whatever the kernel seats' state.** Read them with
   `rig ps --nodes --rig kernel --full`.
-- **`rig tui --shared` still attaches on the default tmux server,** so it can't find the dashboard when the daemon runs
-  on a non-default tmux socket. Use `rig tui` there instead.
+- **`rig tui --shared` still attaches on the default tmux server,** so use `rig tui` when the daemon runs on a non-default
+  tmux socket.