@openrig/cli 0.6.7 → 0.6.9

package/daemon/context-packs/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/context-packs/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/context-packs/skills/agent-operated-software/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "agent-operated-software"
-version: "0.6.7"
+version: "0.6.9"
 taxonomy: "skills"
 purpose: "Use when designing, building, operating, or diagnosing an ongoing application whose live backend or control loop includes OpenRig agents, including applications with a Markdown, YAML, or JSON agent control plane or a thin surface over specialist agent roles."
 files:

package/daemon/context-packs/skills/agent-operated-workflows/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "agent-operated-workflows"
-version: "0.6.7"
+version: "0.6.9"
 taxonomy: "skills"
 purpose: "Use when a bounded real-world procedure has a deterministic happy path but brownfield, variable, or partially knowable state; when an operation must resume from verified evidence; or when deciding whether agent judgment or ordinary code should own a procedure's control loop."
 files:

package/daemon/context-packs/skills/applying-a-permission-policy/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "applying-a-permission-policy"
-version: "0.6.7"
+version: "0.6.9"
 taxonomy: "skills"
 purpose: "Use before launching a team during agent-guided setup, or when a user asks to configure OpenRig command permissions, reduce repeated native approval prompts, or apply a selected rig/seat permission policy."
 files:

package/daemon/context-packs/skills/claude-compaction-restore/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "claude-compaction-restore"
-version: "0.6.7"
+version: "0.6.9"
 taxonomy: "skills"
 purpose: "Use when a Claude Code session is about to compact, has just compacted, reached its context limit, resumed after /compact, or must rebuild its working picture of a long-running seat from its own restore map, its JSONL transcript and the files it touched."
 files:

package/daemon/context-packs/skills/core/agent-starters/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "agent-starters"
-version: "0.6.7"
+version: "0.6.9"
 taxonomy: "skills"
 purpose: "Use when creating, refreshing, packaging, inspecting, promoting, or deprecating a named per-seat starting point — Agent Starter manifest authoring, the 6-state lifecycle (captured → named → inspectable → used → promoted → deprecated), provenance honesty, and refusal rules. NOT a VM image; a managed starting point composed from agent role + startup context + optional native session source + provenance."
 files:

package/daemon/context-packs/skills/core/agent-startup-and-context-ingestion/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "agent-startup-and-context-ingestion"
-version: "0.6.7"
+version: "0.6.9"
 taxonomy: "skills"
 purpose: "Use when designing or auditing how an agent becomes useful after launch — AGENTS.md overlays, role files, skills, rig specs, workflow specs, startup checklists, refocus messages, \"rig context\" surface. Covers the 4 failure modes that make startup context fail (old rig spec misses current operating mode; current agents never told about new guidance; startup file as dumping ground; orchestrator transmits implementation without preserving product intent)."
 files:

package/daemon/context-packs/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/context-packs/skills/core/cross-host-rig-commands/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "cross-host-rig-commands"
-version: "0.6.7"
+version: "0.6.9"
 taxonomy: "skills"
 purpose: "Use when addressing a registered remote OpenRig host, choosing its transport, or interpreting a cross-host result."
 files:

package/daemon/context-packs/skills/core/human-in-the-loop/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "human-in-the-loop"
-version: "0.6.7"
+version: "0.6.9"
 taxonomy: "skills"
 purpose: "Use when classifying a slice closeout (auto-continue / human gate / park), routing a real decision to a human, or designing a human queue/dashboard surface. Treats humans as durable network participants with attention surfaces, queues, and decision records — escalation lands as a durable attention item, not a chat message. Approval is NOT required for every clean closeout; the default RSI conveyor continues unless an explicit human gate is reached."
 files:

package/daemon/context-packs/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/context-packs/skills/core/messaging-the-human/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "messaging-the-human"
-version: "0.6.7"
+version: "0.6.9"
 taxonomy: "skills"
 purpose: "Use when project policy calls for a human decision or update, a human delivery is pending or failed, or a reply must resume the right work."
 files:

package/daemon/context-packs/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/context-packs/skills/core/openrig-architect/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-architect"
-version: "0.6.7"
+version: "0.6.9"
 taxonomy: "skills"
 purpose: "Use when designing multi-agent topologies that run ON OpenRig — authoring RigSpec and AgentSpec files for new rigs, creating agent startup content (guidance / skills / culture), or diagnosing why a launched rig's agents aren't behaving as intended. NOT for changing OpenRig itself (use developing-openrig); NOT for ordinary CLI operation of an existing rig (use openrig-user). Covers the full authoring lifecycle from user intent to validated, launchable rig."
 files:

package/daemon/context-packs/skills/core/openrig-cmux/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-cmux"
-version: "0.6.7"
+version: "0.6.9"
 taxonomy: "skills"
 purpose: "Use when opening OpenRig fleet terminals into cmux — turning a rig, pod, mission, slice, or saved view into live agent tiles via `rig terminal --provider cmux`, or driving cmux on an agent's request. Same OpenRig view semantics as openrig-herdr (the verbs, honest-partial/degrade, read-only cross-rig, scroll/copy, same-size-only duplicates); cmux is the **best-effort** provider (herdr is the default and the proof-gated one). Prefer openrig-herdr unless cmux is specifically wanted."
 files:

package/daemon/context-packs/skills/core/openrig-herdr/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-herdr"
-version: "0.6.7"
+version: "0.6.9"
 taxonomy: "skills"
 purpose: "Use when opening OpenRig fleet terminals as a herdr wall — turning a rig, pod, mission, slice, or saved view into live interactive agent tiles via `rig terminal`, watching another rig read-only, or driving herdr on an agent's request (\"open all my rigs + a mission as views\"). Covers the `rig terminal open|views|status` verbs, the honest-partial/degrade reading of the result, the read-only-by-construction rail for cross-rig views, scroll/copy out of the box, and the same-size-only duplicate-pane "
 files:

package/daemon/context-packs/skills/core/openrig-skills/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-skills"
-version: "0.6.7"
+version: "0.6.9"
 taxonomy: "skills"
 purpose: "Use when you're operating OpenRig and need the right skill or context for fleet recovery, seat handover, new-seat orientation, a watchdog wake, cross-host reach to an agent on another machine, rig packaging, an OpenRig upgrade, systematic debugging, queue triage, or implementation planning; also use when you don't know what applies or nothing is projected on cold boot."
 files:

package/daemon/context-packs/skills/core/openrig-software-factory/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-software-factory"
-version: "0.6.7"
+version: "0.6.9"
 taxonomy: "skills"
 purpose: "Use when a user wants a continuing software team for a real repository, or has a first OpenRig team and needs a repeatable path for reviewed work and later tasks."
 files:

package/daemon/context-packs/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/daemon/context-packs/skills/core/openrig-upgrade/manifest.yaml

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "openrig-upgrade"
-version: "0.6.7"
+version: "0.6.9"
 taxonomy: "skills"
 purpose: "Use when an agent is preparing or performing an OpenRig CLI/daemon upgrade and must preserve live seats, verify each mutation, or reconcile managed plugin and skill files without overwriting local work."
 files: