@openrig/cli 0.6.7 → 0.6.9

package/daemon/docs/reference/refocus-channel.md

@@ -89,6 +89,39 @@ reports broken links as gaps rather than following pointers.
 This automatic hook path is additive to one-shot manual injection through
 `rig send --context`; neither mode substitutes for the other.
 
+## The work packet (switched off by default)
+
+Set `OPENRIG_REFOCUS_WORK_PACKET=1` in a seat's harness environment so its
+refocus carries the work it is actually doing as text rather than as pointers.
+With the switch on:
+
+- The hook asks `rig queue whoami --work-candidates` for labelled evidence.
+  That is each in-progress row's own `mission:` tag (a slice tag is optional),
+  or for an untagged row the nearest local handoff ancestor's mission, plus
+  blocked rows as held work and pending rows as possible next work. The
+  strict `currentWork` derivation is unchanged.
+- One direct, resolved tag is shown as the work, labelled with its source so
+  the agent can correct a stale tag. Anything less certain lists every
+  candidate's one-line intent and asks the agent to name its mission (or to say
+  it has no current work), giving the `--work-start` route that then shows
+  that mission's intent as text. The project-level chain appears only as
+  labelled orientation.
+- A tag that does not resolve on this host is named, never replaced. A
+  retargeted handoff or a remote ancestor gives no assumed mission. A mission
+  named only in body text is not evidence.
+- The seat's `LEARNED.md` contributes its `MY JOB HERE` and `STANDING DUTIES`
+  sections, and notes and each node's `PROGRESS.md` contribute their
+  `Current state` section. When a file has
+  no such heading, the packet says so and shows a bounded excerpt. No heading
+  is required.
+- A notes or `LEARNED.md` file older than
+  `OPENRIG_REFOCUS_NOTES_MAX_AGE_DAYS` (default 14) is named with its age, the
+  age's source (`updated:` frontmatter, else mtime) and the threshold: a cue
+  for judgment, not a staleness verdict.
+
+`trace-to-root.py --packet --work-candidates <path|->` renders the same packet
+by hand.
+
 ## Relation to chain files
 
 The chain files are the durable, altitude-addressed home of orientation

package/daemon/docs/reference/rig-spec.md

@@ -8,6 +8,9 @@ This is the canonical reference for the pod-aware RigSpec YAML format. Every fie
 
 ---
 
+For choosing IDs, see [naming rigs, pods and seats](topology-naming.md). Keep the same
+logical names in edges, startup instructions, workflow targets and runtime presets.
+
 ## Minimal Valid Example
 
 ```yaml
@@ -18,7 +21,7 @@ pods:
   - id: dev
     label: Development
     members:
-      - id: impl
+      - id: build
         agent_ref: "local:agents/impl"
         profile: default
         runtime: claude-code
@@ -105,7 +108,7 @@ pods:
           required: true
       actions: []
     members:
-      - id: impl
+      - id: build
         agent_ref: "local:agents/impl"
         profile: default
         runtime: claude-code
@@ -131,7 +134,7 @@ pods:
         cwd: "."
     edges:
       - kind: delegates_to
-        from: impl
+        from: build
         to: qa
 
   - id: rev
@@ -152,13 +155,13 @@ pods:
 edges:
   - kind: delegates_to
     from: orch.lead
-    to: dev.impl
+    to: dev.build
   - kind: delegates_to
     from: orch.peer
     to: dev.qa
   - kind: can_observe
     from: rev.r1
-    to: dev.impl
+    to: dev.build
   - kind: can_observe
     from: rev.r2
     to: dev.qa
@@ -453,7 +456,7 @@ The canonical session name is derived from the pod ID, member ID, and rig name:
 {podId}-{memberId}@{rigName}
 ```
 
-Example: pod `dev`, member `impl`, rig `my-team` → session `dev-impl@my-team`
+Example: pod `dev`, member `build`, rig `my-team` → session `dev-build@my-team`
 
 Pod and member IDs cannot contain `@` because the first `@` separates their portion
 of the session address from the rig name. Rig names may still contain `@`.
@@ -482,13 +485,13 @@ Edges within a pod use **unqualified member IDs** (just the member `id`, not `po
 pods:
   - id: dev
     members:
-      - id: impl
+      - id: build
         # ...
       - id: qa
         # ...
     edges:
       - kind: delegates_to
-        from: impl      # NOT dev.impl
+        from: build     # NOT dev.build
         to: qa          # NOT dev.qa
 ```
 
@@ -502,7 +505,7 @@ Edges between pods use **fully-qualified `pod.member` IDs**:
 edges:
   - kind: delegates_to
     from: orch.lead     # pod.member format
-    to: dev.impl        # pod.member format
+    to: dev.build       # pod.member format
 ```
 
 Cross-pod edges must reference different pods. An edge where both `from` and `to` are in the same pod is a validation error — use pod-local edges instead.

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

@@ -99,6 +99,16 @@ clicks arrive over the same socket, so no request URL is needed. An app created
 manifest has Interactivity off: turn it on under **Interactivity & Shortcuts**, or the buttons
 will do nothing. A typed reply in the thread still answers the decision either way.
 
+In the decision's `humanAnswers`, clicked answers remain option-id strings. A whole typed reply
+is stored as `{kind: "typed-reply", text: "…", placement: "first-unanswered", unansweredCount: N}`
+under the first unanswered question. That placement is automatic; it does not mean the person
+selected that question. `N` counts the other question slots still empty in `humanAnswers` after
+that placement. Earlier button answers are preserved; no other questions are filled in.
+Read `text` as the person's words,
+even when it equals an option id. The reply still closes the decision, so `done` is not approval.
+A file-only reply closes the decision without recording a typed answer. If all button answers were
+already recorded, they stay final and the typed reply remains in the correlated reply row.
+
 ## What the connector does with the tokens
 
 The tokens stay in the env file you created. The connector reads them from that file and uses them
@@ -140,8 +150,12 @@ rig slack channel-map remove pr@my-rig
   Without a map, OpenRig records nothing about a post's channel, so if the default channel
   changes while a post is being retried, the retry goes to the new default channel (as it always
   has); that also applies to a post first tried before the map was added.
+- **Rate limits on posts.** When Slack rate-limits a post and asks for a pause of 10 seconds or
+  less, OpenRig waits that long and retries the post once. A longer pause, or a second refusal,
+  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. A message the human starts (or a reply in a thread OpenRig does not know) goes to
+  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.
 
@@ -191,6 +205,9 @@ outside this recovery scope; global chronological order is not promised.
 snapshot: socket state/generation, last event, recovery interval/state/reason,
 retry time and accepted/dead-lettered recovery counts since the connector last
 started (they reset when it is enabled or disabled, and when the daemon restarts).
+It also reports the durable dead-letter backlog: the retained records for inbound messages,
+reactions and click answers that await retry, counted from both dead-letter files so the number
+survives a restart, and shown as unknown with a reason (and no count) when a file cannot be read.
 Human-readable coverage and pending bounds use ISO timestamps; JSON keeps Slack timestamps.
 The status read calls no Slack API and starts no scan. If the daemon cannot be
 observed, local configuration remains visible and live state is unknown. A

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

@@ -0,0 +1,74 @@
+# Naming rigs, pods and seats
+
+Names tell people and agents what a team does and who does each part. Use the
+team's purpose for the rig, a domain for each pod, and a role for each seat.
+These are authoring conventions, not additional parser restrictions.
+
+## What each name means
+
+| Level | Meaning | Example |
+| --- | --- | --- |
+| Fleet | A group of OpenRig instances | Your development fleet |
+| Instance | One daemon and its rigs; several instances can share a machine | The instance selected by a registered host route |
+| Rig | A team or project purpose | `starter`, `workshop`, `factory`, or your project's name |
+| Pod | A domain or shared context | `orch`, `dev`, `review`, `research`, `sre` |
+| Seat (member) | A role within that pod | `lead`, `advisor`, `build`, `qa`, `design`, `review` |
+
+The logical seat ID is `pod.member`: `dev.build`. Its session address is
+`pod-member@rig`: `dev-build@workshop`. A cross-instance command also selects the
+registered host route; a display label is not a route. Discover actual addresses
+with `rig ps --nodes` and host routes with `rig host list` before sending work.
+
+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.
+
+## How the software teams grow
+
+| Team | Logical seats |
+| --- | --- |
+| Starter | `dev.build`, `dev.review` |
+| Workshop | `orch.lead`, `dev.build`, `dev.qa`, `dev.review` |
+| Factory | `orch.lead`, `orch.advisor`, `dev.build`, `dev.qa`, `dev.design`, `review.r1`, `review.r2` |
+
+Starter and Factory are built-in teams. Workshop is a
+[bundle](https://github.com/mvschwarz/openrig-world/tree/main/rigs/workshop).
+The built-in specs live under `packages/daemon/specs/rigs/launch/` in the product
+source. Runtime presets keep these logical names.
+
+Workshop's one code reviewer is `dev.review`; Factory has an independent review
+pod with `review.r1` and `review.r2`. Both are intentional. A small team does not
+need every pod or role from a larger one.
+
+## Name a new team
+
+Start with the outcome, then group its work by domain. For a team studying a
+dataset, `research.analyst` and `research.synthesizer` describe useful roles.
+For operating a service, `sre.admin` describes the domain and responsibility.
+Use a project-specific rig name when that helps distinguish two teams.
+
+Avoid a generic operation such as `check` as the pod name: it does not say whether
+the team owns software quality, research validation or service health. Put the
+role in its domain, such as `dev.qa`. This is a rule for choosing new names, not a
+word blacklist or a demand that all teams share one roster.
+
+Use the same IDs in the rig spec, edges, workflow targets, configuration presets,
+startup instructions and terminal views. Validate those references together.
+See [RigSpec](rig-spec.md) and [publishing a bundle](publishing-a-rig-bundle.md).
+
+## Existing identities and retained references
+
+An existing team's address remains its actual address until it is deliberately
+migrated. Changing a label does not rename a seat or move its conversation, queue
+or work. Preserve those records and verify the new routes when doing a migration;
+do not edit a database or restart a team just to make a display match an example.
+
+`first-project` is the compatibility name for Starter; it is not a second team
+template. Existing-name safeguards still apply. See
+[getting started](getting-started.md) before using the alias.
+
+The `factory-rsi` bundle is a retained reference with original workflow-bound
+addresses, including `build.implementer` and `check.qa`. It is distinct from the
+current built-in Factory and is not the naming template for a new team. Old
+release notes, pinned bundles, run records and compatibility tests keep the
+identities they describe.

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

@@ -1,128 +1,85 @@
-# What changed in OpenRig 0.6.7
+# What changed in OpenRig 0.6.9
 
-This note is for an agent on an install that was just upgraded to 0.6.7. It lists only what behaves differently from
-0.6.6 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.9. It lists only what behaves differently from
+0.6.8 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
 after an upgrade it can still hold the previous version's note.
 
-## The OpenRig view is now the handoff
-
-- **Open the view as the step after install or start; don't wait to be asked.** Say you're opening it, run
-  `rig terminal open saved:kernel --window`, then tell the person where it opened. Don't ask "Open the OpenRig view
-  now?", don't wait for a phrase like "show me my agents", and don't finish by printing a command for them to copy. The
-  same command brings their agents back later.
-- **The layout follows the person's terminal width.** On a narrow terminal the operator gets the first tab. On a wide
-  one the dashboard and operator sit side by side and the advisor has its own tab. Inside herdr it opens a focused
-  `openrig kernel` space. A `kernel` view the person saved themselves still wins.
-- **It opens where the caller is.** Terminal gets a window and Ghostty a tab. From Claude Desktop, iTerm or VS Code on a
-  Mac it opens a new Ghostty or Terminal window, and macOS may ask to allow it: mention that clicking Allow is fine only
-  in that case. Over SSH, in CI or with no display, it returns a definite no-window result with the reason. Relay the
-  `run:` command it prints exactly, or give `env -u TMUX tmux attach-session -t '=<canonicalSessionName>'` for the
-  operator.
-- **`rig terminal open <view>` opens a window by default.** Pass `--provider herdr` or `--provider cmux` only to add
-  tiles to a workspace that's already visible. With `--json`, `reusedWorkspace` and `opened: []` mean an existing view
-  was reused, which is success.
-- **The TUI's action is now "Open terminals ▸"** (it was `term ▸`). It opens a desktop window through the same
-  launcher, so the TUI must run on the daemon's desktop.
-- **The `rigs` skill is installed for the person's own agent.** The daemon writes it to `~/.claude/skills/rigs` and
-  `~/.agents/skills/rigs` and refreshes it on every upgrade. It now triggers on any mention of OpenRig, rigs or a team
-  of coding agents. A copy added earlier with skills.sh is left alone and never refreshed.
-
-## Installing and setting up
-
-- **Show the install preview first.** The published install command has a `--dry-run` preview
-  (`rig context get reference/getting-started.md` has both forms). Run the install when the person agrees. If the only
-  failures left are provider sign-ins, have them sign in and continue at "Start the kernel".
-- **If your own harness refuses a tool call while installing,** say so and show the refusal: Claude Code's auto mode can
-  deny calls as well as approve them. Let the person review it in their harness or run that step themselves. A refused
-  call doesn't prove the OpenRig command failed.
-- **`rig setup` installs herdr by default** on macOS and Linux; `--no-herdr` declines it. On a Mac, ask once about
-  Ghostty and on yes rerun `rig setup --ghostty`, keeping `--no-herdr` if it was chosen. Setup no longer installs cmux,
-  and an existing cmux still works. In `--json` output the `cmux_install` step is gone and `herdr_install` and
-  `ghostty_install` appear.
-- **`rig doctor` checks Claude and Codex installs, and a login or configured provider credential,** the way setup does.
-  It exits 1 when either harness is missing or has neither, including one the person doesn't use, so ignore a failure
-  on an unused harness. A pass means a login or configured provider credential is available locally, not that a
-  provider accepts the credential or that an agent can work; no provider request or agent work is tested.
-- **When setting up permissions,** recommend keeping the team default and offer remembered allowances only if the
-  person wants fewer prompts. People slowed by prompts can be pointed to the workshop listing.
-- **Windows users go through WSL2.** For Pi seats there, offer either credential route; a global Pi login still isn't
-  shared with managed seats.
-
-## Fewer prompts
-
-- **In Claude team seats, help on lifecycle commands runs without a prompt.** `rig down --help` and `-h` forms run;
-  the lifecycle actions themselves still ask. Pipelines, command substitutions, redirects and heredocs aren't allowed
-  automatically.
-- **The kernel operator's Claude session runs routine inspection without prompts:** Python, command lookup, `cd`, text
-  helpers and WebFetch. Compound commands and redirects still go to Claude's own permission check.
-- **Managed Codex seats no longer stop at the update menu on start.** Updating Codex is the operator's job: if a Codex
-  seat says its model needs a newer Codex, offer to update Codex and restart that seat, without stopping the team. If a
-  Codex seat shows a model-switch menu near a rate limit, ask the person; don't change the team's model.
-
-## Messages, wakes and Slack
-
-- **A send or wake no longer answers a question that's waiting for a person.** It's refused with
-  `target_needs_input`, and the reason ends `; latest hook, pane unrecognized` when the screen can't be read, even if
-  the hook is minutes old. Read the seat with `rig capture` and get the question answered by whoever should answer it.
-  Don't retry the send.
-- **Slack can post to a channel per rig or seat:** `rig slack channel-map list`, `set <match> <channel>` and
-  `remove <match>`. After a change, invite the app to each channel, run `rig slack verify`, then `rig slack disable`
-  and `rig slack enable` (or restart the daemon). Thread replies still reach the seat in any channel.
-- **A reaction on any part of a Slack ask reaches the seat that asked,** as a task tagged `human-reaction`. Treat it as
-  a signal to interpret, not an answer; the ask stays open. An existing app needs the `reactions:read` scope, the
-  `reaction_added` event and a reinstall, and `rig slack verify` warns when the scope is missing.
-- **A long Slack ask is posted in parts.** If it still can't be posted, you get a task `<ask id>-undeliverable`, tagged
-  `slack-undeliverable`: shorten the ask or link a file for the long part, and send it as a new ask.
-- **Replies sent with "Also send to #channel" now arrive** at the seat that asked, like any other thread reply.
-
-## Running teams
-
-- **`rig down` prints what each agent seemed to be doing before it stops them,** on one stderr line, or "unknown". It's
-  a best-effort snapshot, not a record of what was interrupted. `rig down --host` now exits 2 when the remote teardown
-  reports errors.
-- **Before a handover or compaction, write the seat's recap** with
-  `rig context recap-write --rig <rig> --seat <seat> --file <draft.md>`, not a file tool, so earlier recaps are kept.
-  `rig seat handover <seat>` now works on the same seat again and again; a seat left half-handed-over recovers by
-  running it again.
-- **After a managed compaction, read the `refocusing` skill and consume the current topology and work traces
-  delivered with the restore.** Don't rerun them just to duplicate the delivery; name a missing trace. For a new trace
-  outside that context, use the skill's one-command form. The daemon now installs the skill globally.
-- **The built-in starter and factory leads publish their team's roster** at first start, so `rig roster list` and
-  `rig roster find <topic>` know those teams.
-- **Claiming a parked queue item clears its `blocked_on`.** To park it again on the same gate, run
-  `rig queue update <id> --state blocked` without `--blocked-on`: it reuses the previous gate. Add the usual wake when
-  one is required.
-- **A periodic reminder first fires one interval after you register it,** not immediately.
-- **Workflows:** `rig workflow run` and `rig workflow watch` exit 3 for an aborted instance. When a step that was sent
-  back completes again, the steps that depend on it run again too, including ones that had passed.
-- **Sharing teams:** `rig bundle create` and `rig up <link>` name the bundle after `rig.yaml`'s `name`, and
-  `rig bundle check` names the file in each finding. Submissions go to `mvschwarz/openrig-registry`. The bundle safety
-  check always runs, even with `--skip-version-check --force`.
-- **`rig context add <url> --git` retrieves shallowly by default:** the initial retrieval fetches only the current
-  commit, and a server that refuses shallow retrieval falls back to a full clone with a warning. Use
-  `rig context source update` for later revisions.
-- **Values that used to fail quietly are refused:** a bad `rig chatroom history --since` (fix the value; the room isn't
-  empty) and a `--wake-after` such as `7d` (use hours, for example `168h`).
-- **Pi seats print a `[pi-runner] seat …:` line at start** saying whether a credential was found and, if not, how to
-  fix it. A MiniMax model gets `MINIMAX_API_KEY` when that name is in `recovery.provider_auth_env_allowlist`.
-- **`agents.advisor_session` defaults to the kernel's advisor seat.**
+## Slack
+
+- **A typed reply to a decision with structured questions is kept.** It's recorded on the row in `humanAnswers` as a
+  tagged entry (`kind: "typed-reply"`), placed under the first unanswered question, with the count of questions still
+  unanswered. A clicked answer is still the option's ID. Typed text that matches an option's ID is never read as clicking
+  it. The decision still closes, and closing doesn't mean approval: read the reply and its placement before acting. The
+  `messaging-the-human` skill says how.
+- **`rig slack status` shows the inbound retry backlog:** how many retained records for inbound messages, reactions
+  and click answers are waiting to be retried, kept across restarts. This counts records, not distinct messages.
+  If the records can't be read, the line says the count is unknown and why; it never reads as an empty backlog.
+- **An alert retried after its row closed isn't posted.** A Slack post that failed is kept and retried when the gateway
+  next starts. If the row has left the active states by then, the alert is dropped and the row records
+  `slack-owner-notification-dropped … reason=row-not-active`. Alerts for rows still open, decision-resolved notices and
+  digests still post. `rig slack enable` says how many earlier undelivered posts wait to be retried.
+- **"Connected" is no longer the only word about the Slack connection.** OpenRig now notices a connection that stays
+  open while Slack stops delivering events to it, and replaces it: a new connection opens first, then the old one
+  closes. Two signals catch it, each counted only once the connection has shown it: Slack's server pings stopping for
+  30 seconds, and two of OpenRig's own posts not coming back as events within a minute. Automatic replacements are at
+  most one every 5 minutes; Slack's own refresh requests are exempt.
+- **Read delivery beside the socket state.** `rig slack status` adds a `Delivery:` line (`delivering`, `not yet
+  confirmed`, `events missing since …`, `no server pings since …`, or Socket Mode disabled), the last automatic
+  reconnect and why, a held-back reconnect and until when, and Slack's connection count when it's more than ours. The
+  connections view shows `connected; delivering` or `connected; delivery not yet confirmed`. Report "not yet
+  confirmed" as that, never as working.
+
+## Sends and waits
+
+- **A cross-host send that may have arrived reads as unconfirmed, not failed.** `rig send <session> --host <id>` to an
+  http-registered host now has a 30-second request budget, plus any `--wait-for-idle` time. When the answer doesn't come back, or the connection drops after the
+  request went out, the send exits 1 with `failedStep: "remote-outcome-unknown"` and "Delivery UNCONFIRMED". **Check the
+  target with `rig capture <session> --host <id>` before any resend**; a blind resend can deliver twice. Only a host
+  that was never reached reads as unreachable.
+- **`rig chatroom wait` keeps waiting through a slow or restarting daemon.** Poll timeouts, connection refusals, and
+  reset or closed connections are retried until your `--timeout`; the first failure in a run prints a line on stderr.
+  Other errors, including an error answer from the daemon such as a removed rig, still end the wait. If the last
+  recorded poll failure remains unresolved at the deadline, the timeout says new messages may have arrived unseen.
+
+## Kernel status
+
+- **A kernel that recovered from a failed start reads ready.** When every declared kernel seat reports ready, for
+  example after `rig seat continue`, `rig status` says so and adds an indented line naming the earlier failure and
+  when it happened. `GET /api/kernel/status` returns that as `last_boot_failure`. The kernel's agent list shows each
+  seat once, with its runtime.
+
+## Scope approval
+
+- **`rig scope <tier> approve --workspace <path>` stamps the work tree you named.** Before, it reported success while
+  the stamp landed in the daemon's own work tree. A named workspace with no `missions/` folder is now refused instead
+  of falling back to the configured one. The approval record names the root it wrote under.
+
+## Claude seats on NixOS
+
+- **A Claude Code installed from nixpkgs is recognised as the seat's runtime,** so its seats read `running` and sends
+  no longer warn that the runtime couldn't be established. A seat that still carries an attention marker from an
+  earlier failed launch keeps it: clear it with `rig seat clear-attention <seat>`.
+
+## A correction to the 0.6.8 note
+
+- **`rig launch` takes a rig ID, not a rig name.** The 0.6.8 note wrote `rig launch <rig> <seat> --plan`. Read the ID
+  from `rig ps --json`; a name gives `rig_not_found`.
 
 ## What to stop doing
 
-- **Stop asking whether to open the OpenRig view, or waiting for a phrase.** Open it after install or start.
-- **Stop using `--provider herdr` for the first view,** and stop pre-warning about macOS prompts from Terminal or
-  Ghostty.
-- **Stop suggesting `--skip-version-check --force` to get past a bundle pre-check failure.** The check always runs.
-- **Stop retrying a send refused with `target_needs_input`.** Get the question answered instead.
-- **Stop telling people to untick "Also send to #channel" when they answer in Slack.** Those replies now arrive.
+- **Stop resending a cross-host message after a timeout.** Check the target first; the first send may have arrived.
+- **Stop restarting a kernel whose status read `bootstrap_failed` after its seats recovered.** Read `rig status`
+  again on 0.6.9; a recovered kernel reads ready.
+- **Stop passing a rig's name to `rig launch`.** Pass its ID.
 
-## Known gaps in 0.6.7
+## Known gaps in 0.6.9
 
-- **Not yet checked on a real machine:** opening the view from Claude Desktop, and the plain-tmux layout without herdr.
-  The full first install from nothing and a Linux run come after this release.
+- **The latest first-install check used 0.6.8 on a fresh Mac account in Terminal,** with assistance to install the
+  candidate. It reached setup, the kernel window and a team plan; team launch and work weren't exercised.
+  Linux and Windows first installs remain unchecked in the evidence behind this note.
 - **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.
 - **Codex team seats aren't asked before lifecycle commands yet.**

package/daemon/specs/agents/shared/skills/core/cross-host-rig-commands/SKILL.md

@@ -85,6 +85,7 @@ A local success message alone does not establish remote persistence or pickup.
 | ssh-unreachable | SSH connection, target and transport diagnostics |
 | permission-gate | The configured SSH or HTTP credentials and target policy |
 | remote-daemon-unreachable | Target listener and actual running daemon identity |
+| remote-outcome-unknown | The request may have arrived (timeout, dropped connection, unreadable reply): check its effect, for a send the target pane, before any retry |
 | remote-command-not-found | Remote CLI installation and executable lookup |
 | remote-command-failed | The remote operation's own status and error |
 

package/daemon/specs/agents/shared/skills/core/messaging-the-human/SKILL.md

@@ -92,16 +92,30 @@ the human (a pending human decision, or a row parked on the human), since a
 reply in that thread would answer the decision. In every such case the
 `--verify` result says `threaded: false` with the reason.
 
+To answer a reply the human typed inside one of your threads, `--reply-to` the
+row their reply landed as. The update posts in that thread unless one of the
+cases above applies, and `--verify` reports it the same way. A message the
+human started at the top level of the channel has no thread yet, so the answer
+posts as a new message.
+
 A **decision** with a few clear choices can carry `--human-questions-file <path>`:
 a JSON array of 1–4 questions, each
 `{"id", "question", "options": [{"id", "label", "recommended"?}]}` with 2–4
 options (labels up to 75 characters, at most one recommended). Slack shows each
 question as a row of buttons. Each click records that answer on the item, and
 the decision resolves once every question has one. You then receive one reply
-row listing the answers, and the item's `humanAnswers` holds the option ids. The
-human may instead type a reply in the thread; that resolves the decision as
-usual, so read the reply rather than assuming an option was picked. Keep the
-brief complete: the questions add buttons, they do not replace the explanation.
+row listing the answers. In `humanAnswers`, clicked answers are option-id strings.
+A whole typed reply is an object:
+`{kind: "typed-reply", text: "…", placement: "first-unanswered", unansweredCount: N}`.
+It is placed automatically under the first unanswered question; the person did
+not select that question. `N` counts the other question slots still empty in
+`humanAnswers` after that placement.
+Earlier button answers stay intact. Read `text` as the person's words, never as
+an option id even if the strings match. The typed reply still closes the decision
+with the other questions unanswered; `done` is not approval. If every button
+answer was already recorded, that final answer set stays intact and the typed
+reply remains in its correlated reply row. Keep the brief complete: the questions
+add buttons, they do not replace the explanation.
 
 If an existing agent-owned row must wait for a **decision**, block it on the **new live qitem ID**
 (`rig queue block <work-id> --on <human-qitem-id> ...`), not on the human address.

package/daemon/specs/agents/shared/skills/core/openrig-architect/SKILL.md

@@ -39,6 +39,9 @@ the format you will author. Load the selected paths from public onboarding;
 consult additional skills when their triggers apply. A design task does not
 require reading the whole command library.
 
+- Read `topology-naming.md` before choosing new identities: rig = purpose, pod =
+  domain, member = role. Keep names stable across runtime choices and match every
+  edge, preset and workflow target to the declared IDs.
 - Read the relevant sections of `rig-spec.md` and `agent-spec.md` before writing
   those declarations. Consult `agent-startup-guide.md` for startup/loadout work
   and `edge-types.md` when selecting relationships. Resolve the installed

package/daemon/specs/agents/shared/skills/core/openrig-software-factory/references/worked-example.md

@@ -120,25 +120,26 @@ rig grow --help
 
 Set `RIG_ID` to the `rigId` for the running `starter`, and `PROJECT_ROOT`
 to the absolute code repository. Verify its existing `dev` pod and choose unused
-member names. When the user has authorized the added capacity and cost, run:
+member names. Here `parser` owns CSV parsing and `cli` owns the command interface.
+When the user has authorized the added capacity and cost, run:
 
 ```sh
-rig grow "$RIG_ID" a b --pod dev --runtime codex --cwd "$PROJECT_ROOT" --json
+rig grow "$RIG_ID" parser cli --pod dev --runtime codex --cwd "$PROJECT_ROOT" --json
 rig ps --nodes --rig starter --json
 ```
 
-For one builder, omit `b`. The expected new logical IDs are `dev.a` and `dev.b`,
-with addresses `dev-a@starter` and `dev-b@starter`; use the actual
+For one builder, omit `cli`. The expected new logical IDs are `dev.parser` and `dev.cli`,
+with addresses `dev-parser@starter` and `dev-cli@starter`; use the actual
 returned identities. The command adds and launches the named seats.
 
 To put those seats in a **new** pod instead, choose this alternative once, with an
-unused pod ID; do not run both examples for the same desired capacity:
+unused domain pod such as `data`; do not run both examples for the same desired capacity:
 
 ```sh
-rig grow "$RIG_ID" a b --new-pod build --runtime codex --cwd "$PROJECT_ROOT" --json
+rig grow "$RIG_ID" parser cli --new-pod data --runtime codex --cwd "$PROJECT_ROOT" --json
 ```
 
-That alternative produces `build.a`/`build.b` and corresponding `build-...`
+That alternative produces `data.parser`/`data.cli` and corresponding `data-...`
 addresses. `--pod` and `--new-pod` are mutually exclusive. With one existing pod,
 `--pod` can be inferred; select it explicitly when the intended target matters.
 The runtime defaults to `claude-code` and cwd defaults to the caller's current
@@ -153,7 +154,7 @@ agent specs, use the optional Architect path below and `rig expand --help`.
 Inspect each node's status/error and native pane. Confirm existing seats and work
 remain present; a created node is not readiness. Partial results can leave nodes
 persisted. After a timeout, reconcile topology before retrying. Fix the reported
-cause, then use `rig launch "$RIG_ID" dev.a` only for an already-created seat that
+cause, then use `rig launch "$RIG_ID" dev.parser` only for an already-created seat that
 failed to start. That command does not create a missing seat.
 
 New seats do not inherit the owner's conversation or task. Record the agreed
@@ -163,8 +164,8 @@ checks, next owner and stopping condition. Then deliver the context instruction,
 for example for the first builder:
 
 ```sh
-rig send dev-a@starter "Read $PROJECT_ROOT/SPEC.md and the addressed sources in $PROJECT_ROOT/.openrig/factory/TASK-A.md. Run rig whoami --json and rig queue list --owned --json in your own seat; report your identity, scope and any native readiness/permission blocker. Await the bounded queue assignment."
-rig capture dev-a@starter
+rig send dev-parser@starter "Read $PROJECT_ROOT/SPEC.md and the addressed sources in $PROJECT_ROOT/.openrig/factory/TASK-A.md. Run rig whoami --json and rig queue list --owned --json in your own seat; report your identity, scope and any native readiness/permission blocker. Await the bounded queue assignment."
+rig capture dev-parser@starter
 ```
 
 Read the actual reply and pane; resolve startup/login/permission prompts under the
@@ -174,7 +175,7 @@ the coordinator creates the distinct agreed task (or hands off an existing owned
 task instead of duplicating it):
 
 ```sh
-rig queue create --destination dev-a@starter \
+rig queue create --destination dev-parser@starter \
   --body-file "$PROJECT_ROOT/.openrig/factory/TASK-A.md" \
   --summary 'Implement the agreed independent change A' --json
 ```
@@ -191,7 +192,7 @@ working agreement and assigned work, not the seat's name or default agent label.
 | Seat in this example | Deliberately agreed responsibility |
 | --- | --- |
 | `dev-build@starter` | Initially implements and coordinates; can become the dedicated orchestrator, selecting outcomes, separating tasks, owning integration and retaining next-work custody. |
-| `dev-a@starter`, `dev-b@starter` | Implement distinct authorized tasks and return exact candidates/evidence. Neither silently edits the other's files or folds both candidates without integration ownership. |
+| `dev-parser@starter`, `dev-cli@starter` | Implement distinct authorized tasks and return exact candidates/evidence. Neither silently edits the other's files or folds both candidates without integration ownership. |
 | `dev-review@starter` | Retains independent judgment under the project's review policy. The implementer does not count its own check as independent review. |
 
 This is one progression, not a required four-seat layout. One extra builder may
@@ -240,8 +241,8 @@ YAML authoring is optional; ordinary growth uses the commands above.
 ### Remove capacity deliberately
 
 When a seat is no longer needed, preserve its work and next owner first.
-`rig remove "$RIG_ID" dev.a` removes that seat; `rig shrink "$RIG_ID" build`
-removes the whole optional build pod. These end the affected sessions. Removal
+`rig remove "$RIG_ID" dev.parser` removes that seat; `rig shrink "$RIG_ID" data`
+removes the whole optional data pod. These end the affected sessions. Removal
 refuses active work unless you explicitly select a live `--fallback <live-seat>`
 to receive it. Check the exact targets, handoff and returned outcomes; do not use
 fallback to discard an obligation or remove seats merely because they look idle.

package/dist/build-info.js

@@ -1,9 +1,9 @@
 // GENERATED by scripts/build-package.sh — the packaged build-identity stamp.
 export const BUILD_INFO = {
-  semver: "0.6.7",
-  commit: "b3c3c8575f2a646c07ecc49bbf07927473effc9d",
+  semver: "0.6.9",
+  commit: "4b48ca21a9bd072aa05a08b3da6d9c0708e093c5",
   dirty: false,
-  builtAt: "2026-10-08T11:56:22Z",
+  builtAt: "2026-10-09T08:59:39Z",
 };
 export function stampFields(info = BUILD_INFO) {
   if (!info.commit) return {};