@openrig/cli 0.6.6 → 0.6.8

package/daemon/docs/reference/sdlc-conventions.md

@@ -76,8 +76,10 @@ The authority lookup is `product-journey-sdlc.md#resolve-the-selected-path`.
 Bring work with evidence that its promised user outcome actually works.
 
 For a release mission, `mission.yaml` also names the Git strategy before build
-work starts: the branch/ref that is cumulative integration truth, its base, and
-when that truth is reconciled to main. Continuous integration to main and a
+work starts: the branch/ref that is cumulative integration truth
+(`arrangement.source.integration_ref`, the ref `rig view show execution` tests
+a candidate's folding against; `main` when unset), its base, and when that
+truth is reconciled to main. Continuous integration to main and a
 release-line fold followed by one explicit merge are both valid; leaving the
 choice implicit is not.
 

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

@@ -63,9 +63,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), and `app_mentions:read` (receive @-mentions of the app). `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 or mentions will work.
+  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.
 
 If a feature scope was not granted, the effect differs by feature:
 
@@ -75,12 +76,22 @@ If a feature scope was not granted, the effect differs by feature:
   the failure appears only in the daemon log (`rig daemon logs`).
 - **Mentions** (`app_mentions:read`): Slack does not deliver `app_mention` events to the app.
   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.
 
-So after installing, compare the granted scopes Slack shows for the app with all six scopes that
+So after installing, compare the granted scopes Slack shows for the app with all seven scopes that
 `rig slack manifest --json` lists.
 
-The app subscribes to messages in public channels it is a member of (`message.channels`) and to
-mentions of the app (`app_mention`). It does not request direct-message or private-channel access.
+The app subscribes to messages in public channels it is a member of (`message.channels`), to
+mentions of the app (`app_mention`), and to emoji reactions (`reaction_added`). It does not request
+direct-message or private-channel access.
+
+A reaction added to an ask reaches the agent that asked, as a note naming who reacted and with
+which emoji; the agent decides what it means. Every message OpenRig posted for the ask counts:
+its first message, a long ask's numbered parts, and an ask posted as a reply in a thread. A
+reaction on any other message, including a person's reply in the thread, is ignored. An app created from an older manifest has neither the `reactions:read` scope nor the
+`reaction_added` event: add both under **OAuth & Permissions** and **Event Subscriptions**, then
+reinstall the app to the workspace.
 
 The manifest also turns on **Interactivity**, so the human can answer a decision's structured
 questions by clicking a button (`rig queue create --human-questions-file`). In Socket Mode the
@@ -101,11 +112,59 @@ part of OpenRig.
 - `rig slack status` shows what is still missing, without contacting Slack.
 - `rig slack verify` checks the granted baseline scopes and channel membership with Slack.
 
+## One channel per rig or seat (optional)
+
+By default every human-bound item posts to the one channel from `rig slack setup --channel`.
+To follow each rig separately, post a rig's items, or a single seat's, to its own channel:
+
+```bash
+rig slack channel-map set my-rig C0EXAMPLE1
+rig slack channel-map set pr@my-rig C0EXAMPLE2
+rig slack channel-map list
+rig slack channel-map remove pr@my-rig
+```
+
+- **Which channel an item posts to.** The item's seat is matched exactly first (`pr@my-rig`),
+  then its rig (`my-rig`). Anything unmapped posts to the default channel, so a config
+  without a map behaves exactly as before. Aggregate delivery digests have no single seat and
+  always post to the default channel.
+- **Threads.** Updates, `--reply-to` and later notifications for an item stay in its thread.
+  With a map configured, if a seat's channel has changed since the thread was opened, the
+  next post opens a new thread in the seat's current channel, and `--reply-to` records the
+  fallback as `root-other-channel`. With no map, threads behave exactly as before: an item's
+  next notification reuses its open thread in whatever channel that thread was posted in.
+- **Changing the map.** A change applies to new posts. A post already in flight (one being
+  retried after a failure or an unconfirmed send) finishes in the channel and thread it started
+  in, and its retry checks that channel first so it is not posted twice. This includes adding
+  the first map: a post first tried before any map existed finishes in the default channel.
+  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. 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.
+
+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.
+
+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
+connector reads the file, and `rig slack status` names it. Private channels and direct messages
+are not supported targets.
+
 ## Reconnect recovery and status
 
 The daemon scans available top-level messages in the configured channel after a
 Socket Mode connection and on its existing five-minute retry cadence. Recovered
-queue rows say **Recovered after a gap** and show the original Slack posting time.
+tasks say **Recovered after a gap** and show the original Slack posting time.
 They use the same sender admission, routing, attachment handling, fixed identity
 and dead-letter path as live messages. A durable dead letter is custody of a
 failed delivery, not successful delivery.
@@ -121,8 +180,9 @@ not covered by that margin. A corrupt or unreadable checkpoint leaves recovery u
 and preserves the existing file; live inbound continues.
 
 Each pass admits at most four pages, 100 entries and 15 seconds of work, with a
-five-second history-request ceiling. An already admitted attachment/landing keeps
-its owner until it settles. Rate limits retain Slack's Retry-After across restart.
+five-second history-request ceiling. Work already started on a message, such as
+an attachment transfer, is not cancelled by these limits or by a stop, and a new
+pass waits for it to finish. Rate limits retain Slack's Retry-After across restart.
 Transport and server failures use a five-second backoff unless Slack supplies Retry-After.
 When Slack reports a plan history limit, recovery still lands the available page
 and advances normally, retaining an older-history limitation in status across restarts.

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

@@ -0,0 +1,96 @@
+# What changed in OpenRig 0.6.8
+
+This note is for an agent on an install that was just upgraded to 0.6.8. It lists only what behaves differently from
+0.6.7 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.
+
+## Skills from the managed catalog
+
+- **A skill with uncommitted changes in the catalog now blocks only itself.** Before, one edited skill made the whole
+  catalog unavailable to work-install, launch and restore preflight. Now that skill is skipped and named, and the
+  remaining clean skills stay available for projection.
+- **Read the warning, don't retry.** `catalog_skill_skipped` names a skill nobody selected; `selected_skill_skipped`
+  names the selector and the folder. The fix is to commit or restore that folder's content in the catalog, then run the
+  projection again.
+- **A selected skipped skill makes the inspection commands exit 1.** `rig context work-install --runtime <runtime>`
+  and `rig skill loadout --runtime <runtime>` inspect by default. Use `--apply-skills` with work-install or `--apply`
+  with skill loadout to project the remaining clean skills. Read the warnings and projection result; exit 1 alone does
+  not say whether files were changed. With `--json`, skipped skills are in `skillLoadout.skipped` or
+  `loadout.skipped`, respectively.
+- **A seat keeps the copy it already has** of a skipped skill, unchanged. After the catalog change is committed or
+  restored, the next applied projection can refresh it. No seat receives the skipped skill's uncommitted files, and
+  launch only warns about the skip.
+- **An uncommitted `catalog.yaml` still makes the whole catalog unavailable,** because it changes every selection.
+
+## Launch plans
+
+- **`rig launch <rig> <seat> --plan` previews one seat's launch** without launching it, locally or with `--host`. Use
+  it before starting a single seat, as `--seats … --plan` already allowed for several.
+- **A plan is never sent to a daemon older than 0.5.9,** which would ignore the flag and launch. If `rig launch --plan`
+  refuses for that reason, restart or upgrade that daemon. If it exits non-zero saying the daemon may have acted, check
+  `rig ps --nodes -A` before retrying.
+
+## Slack
+
+- **Answer a person's thread reply in that thread.** When someone replies inside a thread OpenRig opened, answer with
+  `rig queue create --human-intent update --reply-to <the inbound reply's row>`, and the answer posts in that thread.
+  A top-level message is still answered top-level.
+- **A short rate limit is waited out.** When Slack asks for a pause of 10 seconds or less, OpenRig waits and retries the
+  post once. A longer pause is still left to the usual retry of retained messages.
+
+## Managed compaction
+
+- **A quiet seat is restored after `/compact`.** The turn boundary, the restore request and the read-depth
+  audit now reach a Claude seat that takes no turn after compacting. Before, they waited for the seat's next turn,
+  so a seat with nothing to do could sit unrestored. Each stage still waits until the seat's screen shows it idle.
+
+## Workflows
+
+- **Validate before you run.** `rig workflow validate` reports `step_cannot_finish` when no allowed exit can finish a
+  step or route onward, and such a workflow cannot be instantiated. Allow `done` or an exit with a route onward. In a
+  dependency graph, `handoff` can also finish a sink without a next step. A spec that validated on 0.6.7 may need a
+  correction.
+
+## The TUI
+
+- **Type whole commands on an empty command line.** The footer toggle is now `F`, and in a selected Scopes view the
+  mini-requirements and narrative keys are `M` and `N`, so `find`, `feed`, `mission`, `narrative` and `needs` reach the
+  command line intact.
+- **`j` and `k` move the selection down and up** when the command line is empty. With text on the line they're ordinary
+  letters.
+
+## Smaller changes
+
+- **A Claude seat launched with `--remote-control`** confirms its identity instead of staying "identity not confirmed".
+- **`rig down` still saves its recovery snapshot** when finding one seat's resume details fails.
+- **A wake for a handed-off task shows its summary** on one line, so read it to see what the task is for.
+- **`rig scope audit` accepts slice folders numbered 100 and above.** `rig proof add --file` keeps a leading UTF-8
+  byte-order mark.
+- **Building from source no longer needs POSIX shell tools** for the CLI and TUI output. It hasn't been run on Windows
+  yet; WSL2 is still the way to run OpenRig there.
+- **A topology naming reference** explains how to name a team's pods and seats: `rig context get
+  reference/topology-naming.md`.
+
+## What to stop doing
+
+- **Stop treating a non-zero work-install exit as proof that nothing changed.** Read the skipped-skill warnings and
+  projection result. Inspection alone changes no skill files; an applied projection can update clean skills while
+  reporting a skipped one.
+- **Stop scripting around the TUI's single-letter keys.** Type the command whole.
+- **Stop assuming a workflow that validated on 0.6.7 can finish.** Validate it again on 0.6.8.
+
+## Known gaps in 0.6.8
+
+- **Not yet checked on a real machine:** the full first install from nothing, on Mac, Linux and Windows.
+- **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.**
+- **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".**
+- **A launched team still writes its skills into its working folder.**
+- **After a restart, `rig status` shows `Kernel: skipped` whatever the kernel seats' state.** Read them with
+  `rig ps --nodes --rig kernel --full`.

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

@@ -92,6 +92,12 @@ 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

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-skills/SKILL.md

@@ -57,7 +57,7 @@ These are auto-delivered to every rig; their name+description are already in you
 - **loading-addressable-markdown** — a task names Markdown as `path#h2-slug` or `path#h2-slug/h3-slug` outside the context-pack library.
 - **session-compaction-and-restore** — preparing for, or recovering from, compaction (any runtime). The write- and read-side protocol.
 - **queue-handoff** — you're passing durable work to another seat or ending your turn. The queue is the work ledger, not chat.
-- **refocusing** — a long-running seat may have lost the product outcome, crossed a major boundary, or compacted and needs a fresh path-based trace.
+- **refocusing** — invoke as `refocusing` when a long-running seat may have lost the product outcome, crossed a major boundary, or compacted and needs a fresh path-based trace.
 - **seat-continuity-and-handover** — handing your seat's work across a restart or to another owner.
 - **orienting-to-an-inherited-seat** — you just inherited an existing seat through a planned handover and need to verify its identity, state, and testimony.
 - **retiring-and-inheriting-a-seat** — you're planning a seat transition and need to retire the current occupant into a fresh successor without losing continuity.

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

@@ -51,7 +51,7 @@ or `codex login` once when that selected login is missing. No credential copying
 unused provider prerequisite or silent model/provider fallback.
 
 Read the compatible getting-started guide's **Choose your providers** and
-**Kernel startup stays automatic** sections before launch. The choice selects
+**Start the kernel and check its state** sections before launch. The choice selects
 the two project agents. Kernel auto-boot independently uses available
 authenticated accounts, so it may use both even when the project uses one.
 Do not add an unused-provider login gate or manual kernel setup to this path.
@@ -63,7 +63,8 @@ Show the chosen team, resolved runtimes/models and exact
 retain `gpt-6-astra`; Claude seats use the configured native default without an
 OpenRig model override. Confirm that model with the user and its availability;
 verify the native session's actual model before consequential work. Use the
-chosen rig name in owner/checker addresses throughout the same task and return.
+chosen rig name in owner/checker addresses (in the starter, `dev-build@<rig>` and
+`dev-review@<rig>`) throughout the same task and return.
 
 ## Establish the working agreement
 
@@ -79,16 +80,21 @@ model turns, but delivered wakes and resumed work **can spend tokens**. Prefer
 an event-driven wait to frequent empty reminders. Wakes cannot answer a user
 question, clear a permission prompt or guarantee progress.
 
-**Ask once before launching or assigning work:** “Allow your agents to run
-OpenRig commands without repeated permission prompts?” **Yes — recommended** /
-**No — keep prompts**. Reuse an existing explicit choice for this scope. Explain
-that this covers all `rig` verbs, including starting/stopping agents and changing
-configuration, at personal project scope unless the user explicitly chooses
-user-wide sessions. It is not global YOLO or permission to invent work.
+**Ask once before launching or assigning work.** For a team with no permission
+policy, seat choice or named Codex profile, recommend keeping the team default:
+Claude team seats run ordinary `rig` commands, project reads and common tests
+without prompts, and lifecycle commands such as `rig up` and `rig down` still
+ask. Only if they want more, offer: “Remember these selected OpenRig commands in
+your native settings for this project?” **Yes** / **No — keep the team default**.
+Reuse an existing explicit choice for this scope.
+Explain that a remembered allowance can cover all `rig` verbs, but Claude team
+seats still ask before lifecycle commands, at personal project scope unless the
+user explicitly chooses user-wide sessions. It is not global YOLO or permission
+to invent work.
 On an actual Yes, follow [Applying a permission policy](#find-the-compatible-permission-guide)
 to add existing native rules, preserve stricter/unrelated settings, and verify
-the target conversation. No or no answer leaves settings alone and continues
-with existing prompts. Remember the explicit choice and exact additions in the
+the target conversation. No or no answer leaves settings alone and keeps the
+team default. Remember the explicit choice and exact additions in the
 existing onboarding context; “Undo the OpenRig command allowances added by this
 setup” removes only those additions. Broader access remains a separate opt-in.
 
@@ -102,8 +108,9 @@ or explicitly reports none. Preserve work and custody before a supported stop.
 
 Choose the team size separately from the coordination method above:
 
-1. **Use the two-agent starter.** Keep the existing owner and independent checker
-   while that pair meets the workload. The owner can implement and coordinate.
+1. **Use the two-agent starter.** Keep its builder (the owner) and independent
+   reviewer (the checker) while that pair meets the workload. The builder can
+   implement and coordinate.
 2. **Add one or two seats to the running rig.** This is the usual next step.
    Follow [Grow the running team](references/worked-example.md#grow-the-running-team)
    for `rig grow` commands, readiness/context/work

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

@@ -86,8 +86,8 @@ permissions, supplies a missing product decision or authorizes more work.
 
 ## Permissions at the point of work
 
-Before the first task, ask the agent to configure your choice: keep prompts,
-remember selected commands, or deliberately select broader access. Use
+Before the first task, ask the agent to configure your choice: keep the team
+default, remember selected commands, or deliberately select broader access. Use
 `rig context get skills/applying-a-permission-policy/SKILL.md`, or the
 [compatible source/package paths](../SKILL.md#find-the-compatible-permission-guide).
 The agent handles setup and verifies the actual conversation; the user need not
@@ -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/daemon/specs/agents/shared/skills/core/openrig-upgrade/SKILL.md

@@ -239,6 +239,8 @@ host in front of you.
     mechanism; this skill does not rewrite launchers.
 11. Record the observed result, remaining local preservation decisions, and the
     exact rollback runtime and backup.
+12. Read what changed in the new version, `rig context get reference/whats-new.md`,
+    and tell your user anything in it that changes how they work.
 
 ## Stop and hand back when
 

package/daemon/specs/rigs/launch/factory/guidance/lead-first-move.md

@@ -21,3 +21,63 @@ When the goal is done, close the operator's row with the result.
 
 `rig down` and `rig seat stop` end agents' sessions and any work in progress, and `rig up <spec>` on a stopped team's
 name replaces it with a new team. Don't run them unless the person asked; check `rig ps --nodes` first.
+
+## Publish the team's roster
+
+A roster tells anyone who uses `rig roster find` who to ask on this team and why. Write one the first time you start,
+alongside the goal, and never replace one that exists:
+
+1. Take the rig's name from `rig whoami --json` (`identity.rigName`). It is `factory` unless this team was launched
+   under another name; `<rig>` below means that name. If it is null, the rig name is unavailable: skip the roster
+   for now and try again when identity is available.
+2. Run `rig roster list`. If it shows a roster with id `<rig>`, stop here.
+3. The file is `<workspace.root>/rosters/<rig>.json`; `rig config get workspace.root` gives the root. If the file
+   exists, stop here too. Create the `rosters/` folder if it is missing.
+4. Run `rig ps --nodes --rig <rig> --json --fields canonicalSessionName,hostSelfId`. It gives each seat's exact address
+   and the host that serves it.
+5. Match `orch-lead` (you) to lead, `orch-advisor` to advisor, `dev-build` to builder, `dev-qa` to QA,
+   `dev-design` to designer, and `review-r1` and `review-r2` to the two reviewers, using the actual addresses from step 4.
+   Write the file with those addresses and hosts, today's date, and yourself as curator (format: OpenRig's
+   `$OPENRIG_HOME/reference/rosters.md`):
+
+   ```json
+   {
+     "version": 1,
+     "id": "<rig>",
+     "name": "Factory",
+     "purpose": "Plan, build, design and check software in this repository as a full team",
+     "curator": { "seat": "<your address>", "host": "<your host>" },
+     "updated_at": "<YYYY-MM-DD>",
+     "members": [
+       { "seat": "<lead>", "host": "<host>", "capabilities": ["planning", "routing work"],
+         "engagement": ["consult", "delegate"], "use_when": "Deciding what to build next, or who should take a piece",
+         "why": "Leads this team, talks to the person and routes the work" },
+       { "seat": "<advisor>", "host": "<host>", "capabilities": ["product intent", "ideas"],
+         "engagement": ["consult"], "use_when": "Shaping an idea, or checking that work still serves the goal",
+         "why": "The lead's idea and intent partner" },
+       { "seat": "<builder>", "host": "<host>", "capabilities": ["implementation"],
+         "engagement": ["delegate"], "use_when": "A planned piece needs building",
+         "why": "Builds the changes the lead routes to it" },
+       { "seat": "<QA seat>", "host": "<host>", "capabilities": ["testing", "verification"],
+         "engagement": ["review"], "use_when": "A change needs its checks run and reported",
+         "why": "Runs the checks a change calls for and says what each one proved" },
+       { "seat": "<designer>", "host": "<host>", "capabilities": ["product design", "user experience"],
+         "engagement": ["consult", "review"], "use_when": "A change affects what people see or how they use it",
+         "why": "Designs and reviews the user-facing side" },
+       { "seat": "<reviewer 1>", "host": "<host>", "capabilities": ["code review"],
+         "engagement": ["review"], "use_when": "A change needs an independent review",
+         "why": "One of two independent reviewers" },
+       { "seat": "<reviewer 2>", "host": "<host>", "capabilities": ["code review"],
+         "engagement": ["review"], "use_when": "A change needs an independent review",
+         "why": "The second independent reviewer; ask both for important changes" }
+     ]
+   }
+   ```
+
+6. Run `rig roster list` to see it listed, then tell the person in one line.
+
+Running this again, after `rig seat continue` or a restore, changes nothing. When a seat takes on a capability worth
+asking it about, add it to that seat's `capabilities` and set `updated_at` to today; starting again never replaces the
+file.
+
+Need expertise your team lacks? `rig roster find <topic>` lists who to ask and why.