@openrig/cli 0.6.6 → 0.6.8

package/daemon/context-packs/reference/instance-layout.md

@@ -79,6 +79,11 @@ Missing or malformed selections fail; absence is never inferred as disablement.
 `rig context work-install --json` reports the effective state, source, manifest,
 context selectors, and skills. With `--runtime`, its managed skill loadout then
 combines System World, topology, and Project World selectors with provenance.
+The catalog is a Git checkout. A skill folder with uncommitted or untracked content is
+skipped by itself and named. With `--runtime`, work-install reports selected skips with
+exit 1. It inspects by default; `--apply-skills` projects the remaining clean skills while
+keeping any previously projected copy of the skipped skill. An uncommitted change directly
+in the catalog root, such as `catalog.yaml`, still makes the whole catalog unavailable.
 
 For a pre-0.5.9 home, use the `openrig-upgrade` skill's
 `migrate-telemetry-state-0.5.9.mjs` helper as an Agent-Operated Migration. Its

package/daemon/context-packs/reference/manifest.yaml

@@ -1,7 +1,7 @@
 # Reference guides the help pack links to, loaded one file or section at a time by address
 # (rig context get reference/<file>#<section>). Each file is a symlink to docs/reference/.
 name: reference
-version: "0.6.6"
+version: "0.6.8"
 taxonomy: world
 purpose: "Version-matched reference guides the help guide links to. Load a single file or section by address; don't load the whole pack."
 files:
@@ -14,3 +14,6 @@ files:
   - path: rig-spec.md
     role: reference
     summary: "The rig specification format."
+  - path: whats-new.md
+    role: reference
+    summary: "What changed in the installed version, for an agent on an upgraded install."

package/daemon/context-packs/reference/rig-spec.md

@@ -1,13 +1,16 @@
 # RigSpec Reference
 
 Version: 0.2 (pod-aware)
-Last validated against code: 2026-10-05, at main `fcaf1f8e`
-Source of truth: `packages/daemon/src/domain/rigspec-schema.ts`, `packages/daemon/src/domain/types.ts`, `packages/daemon/src/domain/startup-validation.ts`, `packages/daemon/src/domain/permission-policy/policy-ref.ts`, `packages/daemon/src/domain/profile-resolver.ts`, `packages/daemon/src/domain/rigspec-preflight.ts`
+Last validated against code: 2026-10-07, at the 0.6.6 cut `2620dea8` (whole document at `fcaf1f8e`; changes to its sources since then checked)
+Source of truth: `packages/daemon/src/domain/rigspec-schema.ts`, `packages/daemon/src/domain/types.ts`, `packages/daemon/src/domain/startup-validation.ts`, `packages/daemon/src/domain/permission-policy/policy-ref.ts`, `packages/daemon/src/domain/profile-resolver.ts`, `packages/daemon/src/domain/rigspec-preflight.ts`, `packages/daemon/src/adapters/kernel-authority.ts`, `packages/daemon/src/domain/native-permission-store.ts`, `packages/daemon/src/domain/codex-team-workspace.ts`
 
 This is the canonical reference for the pod-aware RigSpec YAML format. Every field, validation rule, and default documented here was traced from the actual parser and validator code, not from prior documentation.
 
 ---
 
+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
@@ -226,12 +229,35 @@ Claude keeps `acceptEdits` and receives inline session settings allowing ordinar
 `rig` commands, project reads and common project test commands (for example,
 `npm test`, `pnpm test`, `pytest`, `go test` and `cargo test`). Lifecycle commands
 such as `rig up`, `rig down`, `rig restore`, `rig bundle install` and seat stop or
-handover are listed as **ask** rules. Native deny and ask rules take precedence
-over allow rules. These are native command-matching rules, not filesystem
-containment: a project's test command can execute code. Flags before the verb
-(for example, `rig --host vps up`) or wrapper commands may not match the lifecycle
-prefixes. OpenRig does not write these settings into a personal or project
-permission file.
+handover ask through a session `PreToolUse` hook. Their literal help forms, such
+as `rig down --help`, `rig bundle install -h` and `rig help down`, run without
+that lifecycle prompt. Native personal, project and managed deny/ask rules still
+apply; OpenRig does not remove or override them.
+
+For allowances, the hook recognizes literal command words (including quoted or absolute paths),
+leading environment assignments that do not change executable lookup or startup,
+and `env`, `command` and `exec` wrappers without options other than `--`.
+Relative executable paths and assignments such as `PATH` or `NODE_OPTIONS` stay
+with native checks. The same existing team allowances apply after spelling
+normalization; project `node_modules/.bin/vitest` and `jest` paths match their
+existing `npx` allowances. It does not automatically allow pipelines, command
+substitutions, redirects, heredocs, shell functions or other unrecognized syntax.
+Lifecycle prefixes are checked at every word position, including after wrappers,
+control-flow words and CLI argument separators. A `--` separator before or after
+the subcommand ends option parsing, so a later `--help` is an operand and still
+asks. Ask detection also scans with comment text retained, so a `#` inside a
+substitution does not hide a later lifecycle command. Unquoted prose or comments
+containing a lifecycle command may also ask; ordinary trailing comments do not
+change allowance matching. Quoted messages and quoted heredoc bodies remain data.
+Arithmetic shifts are not treated as heredoc operators. These are command
+allowances, not containment: a project's test command can execute code. The
+hook and allowances are passed with `--settings` at launch, including resume
+and fork; nothing is written to personal or project permission files.
+
+If the helper asset is missing at launch, OpenRig falls back to the native lifecycle
+ask rules; help can prompt in that fallback. A helper that disappears or times out
+after launch cannot supply a decision, leaving Claude's remaining native rules
+in effect. The hook is a convenience policy, not a containment boundary.
 
 Codex keeps `workspace-write` with its existing approval policy and receives the
 configured OpenRig workspace root plus its pod's shared state directory as
@@ -267,7 +293,8 @@ The destructive class is `delete_everything`, `drop_persistent_store` and
 **At launch.** `builtin:yolo` selects Claude `--dangerously-skip-permissions`, Codex
 `-s danger-full-access -a never`, and Pi `--approve`. `builtin:auto` selects Claude
 `--permission-mode auto`, while Codex and Pi do not have an auto mode and launch at the floor.
-Every other seat launches at the floor:
+Every other seat launches at the floor (a non-kernel seat with no policy also gets the
+[team launch default](#team-launch-defaults) above):
 - Claude `--permission-mode acceptEdits`;
 - Codex `-s workspace-write`, or `-p <profile>` when the member sets
   `codex_config_profile`, in which case the profile governs its own sandbox;
@@ -276,7 +303,8 @@ Every other seat launches at the floor:
 Seats of the rig named `kernel` are the exception. With no member or rig policy, no
 per-seat choice and (for Codex) no named profile, Claude launches in `acceptEdits` with a
 per-launch `--settings` allow list for its file tools and operational commands, and Codex
-launches with `-s danger-full-access -a never`.
+launches with `-s danger-full-access -a never`, plus per-launch `-c` overrides that hide its
+full-access and GPT-5.1 migration notices, whatever the rig's non-interruptive choice.
 
 **Config-surface policies are recorded, not applied at launch.** The seat still starts at
 the floor. The `allow`, `ask` and `deny` rules take effect once they are translated into the
@@ -388,7 +416,7 @@ directory's `CLAUDE.md`, including blocks written by other rigs.
 
 - **State:** Each seat uses `$OPENRIG_HOME/state/pi/<session>/agent` as its Pi agent directory, with `sessions/` beside it, instead of your default `~/.pi/agent`. The runner sets `PI_CODING_AGENT_DIR` to that directory. `<session>` is the seat's session name, unchanged; for a pod member it is `{podId}-{memberId}@{rigName}`. `$OPENRIG_HOME` defaults to `~/.openrig`. OpenRig creates these directories at launch and does not copy anything from `~/.pi/agent`.
 - **Custom models:** Pi reads `models.json` from its agent directory, so a seat reads `$OPENRIG_HOME/state/pi/<session>/agent/models.json`, not `~/.pi/agent/models.json`. Custom provider and model definitions for a seat go in that file. A seat that uses only providers Pi already includes does not need one. OpenRig does not create or write `models.json`.
-- **Credentials:** The Pi process receives only `PATH`, `HOME`, `USER`, `LOGNAME`, `TERM`, `LANG`, `LC_ALL`, `SHELL`, `TMPDIR`, a fixed set of OpenRig seat and instance variables, `PI_CODING_AGENT_DIR`, `PI_CODING_AGENT_SESSION_DIR`, and at most one provider key. That key is `OPENROUTER_API_KEY`, `ZAI_API_KEY` or `KIMI_API_KEY`, passed only when it is set in the seat's environment and the seat's `model` is written as `openrouter/<id>`, `zai/<id>` or `kimi-coding/<id>`. Naming that variable in `recovery.provider_auth_env_allowlist` (empty by default) makes the daemon add it, when set in the daemon's environment, to the seat's launch environment. No other variable reaches Pi, including other providers' keys and a custom provider's own key variable.
+- **Credentials:** The Pi process receives only `PATH`, `HOME`, `USER`, `LOGNAME`, `TERM`, `LANG`, `LC_ALL`, `SHELL`, `TMPDIR`, a fixed set of OpenRig seat and instance variables, `PI_CODING_AGENT_DIR`, `PI_CODING_AGENT_SESSION_DIR`, and at most one provider key. That key is `OPENROUTER_API_KEY`, `ZAI_API_KEY`, `KIMI_API_KEY` or `MINIMAX_API_KEY`, passed only when it is set in the seat's environment and the seat's `model` is written as `openrouter/<id>`, `zai/<id>`, `kimi-coding/<id>` or `minimax/<id>`. Naming that variable in `recovery.provider_auth_env_allowlist` (empty by default) makes the daemon add it, when set in the daemon's environment, to the seat's launch environment. No other variable reaches Pi, including other providers' keys and a custom provider's own key variable.
 
 ### Oh My Pi (`runtime: omp`)
 
@@ -428,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 `@`.
@@ -457,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
 ```
 
@@ -477,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

@@ -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/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.6"
+version: "0.6.8"
 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.6"
+version: "0.6.8"
 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.6"
+version: "0.6.8"
 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/SKILL.md

@@ -92,8 +92,10 @@ You are about to lose every connection you have built. Spend this turn making th
    What were the threads? What did you work out about how the pieces fit? What is unfinished? What did you
    decide, and why? What were you about to be wrong about?
 2. **Write the restore map at the exact path named in OpenRig's preparation request.** Follow that
-   request's completion marker and atomic publication instructions: the daemon waits for that specific
-   file. Do not substitute the seat folder or another map. Managed preparation normally uses
+   request's completion instructions: use your ordinary file-edit tool to write the named `.tmp` file,
+   with the exact completion marker as its last line, then finish and close it. The daemon publishes
+   the completed map atomically; do not run a shell rename or write the final file incrementally.
+   Do not substitute the seat folder or another map. Managed preparation normally publishes
    `<launch cwd>/.openrig/compaction/preparation/<session>/<attempt>/RESTORE-MAP.md`; its parent
    compaction folder ignores itself in Git because maps hold private working context. Unknown or
    unwritable launch directories retain the instance-home fallback named in the request; it may need
@@ -149,6 +151,15 @@ already leaves you. The edges are the point.
 
 You have facts without connections. Rebuild the connections before you act on anything.
 
+Use the native read tool for file reads throughout restoration. Load `refocusing`
+and consume the current topology and work trace that actually arrived with the
+restore request; do not rerun Python merely to duplicate it. If no current trace
+arrived, name that delivery gap. A packet pointer, compact summary or truncated
+extract is not a full source read. Read required notes and full sources separately
+and complete the restore steps and read-depth audit below; partial reading does
+not establish completed restoration. The earlier acknowledgement-only boundary
+is not a restore request.
+
 1. **Check for a hold first.** Read the restore request, the per-seat instruction file
    (`<OPENRIG_HOME>/compaction/post-compact-extra/<session>.md`, named by your full session such as
    `dev-impl@my-rig.md`) when it exists, the newest row or message from whoever routes your work, and any hold

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.6"
+version: "0.6.8"
 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/claude-compaction-restore/scripts/precompact-hook.mjs

@@ -125,6 +125,8 @@ function writeExpectedSentinel(input) {
   fs.mkdirSync(path.dirname(p), { recursive: true });
   fs.writeFileSync(p, `${JSON.stringify({
     version: 1,
+    managedRefocusPending: typeof input.custom_instructions === "string"
+      && input.custom_instructions.trimStart().startsWith("OpenRig managed compaction; wait for the restore request."),
     sessionName: process.env.OPENRIG_SESSION_NAME || process.env.RIGGED_SESSION_NAME || null,
     sessionId: input.session_id || input.sessionId || null,
     transcriptPath: input.transcript_path || null,
@@ -137,6 +139,8 @@ function writePendingRestoreMarker(input, parsed, restoreInstruction, customMess
   fs.mkdirSync(path.dirname(markerPath), { recursive: true });
   const payload = {
     version: 1,
+    managedRefocusPending: typeof input.custom_instructions === "string"
+      && input.custom_instructions.trimStart().startsWith("OpenRig managed compaction; wait for the restore request."),
     createdAt: nowIso(),
     sessionName: process.env.OPENRIG_SESSION_NAME || process.env.RIGGED_SESSION_NAME || null,
     sessionId: input.session_id || input.sessionId || null,

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.6"
+version: "0.6.8"
 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.6"
+version: "0.6.8"
 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/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.6"
+version: "0.6.8"
 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.6"
+version: "0.6.8"
 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,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/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.6"
+version: "0.6.8"
 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.6"
+version: "0.6.8"
 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.6"
+version: "0.6.8"
 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.6"
+version: "0.6.8"
 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/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/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.6"
+version: "0.6.8"
 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/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/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.6"
+version: "0.6.8"
 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: