@openrig/cli 0.6.4 → 0.6.6

package/daemon/context-packs/skills/core/topology-mutation-and-seat-management/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: topology-mutation-and-seat-management
-description: Use when changing a rig while it is alive — `rig expand` / `rig shrink` / `rig launch` / `rig remove` / `rig discover` / `rig bind` / `rig adopt` / `rig attach`. Covers the 4 failure modes (newly created seat lacks queue/startup/role; edges and permissions not updated; adopt/bind succeeds at tmux but not OpenRig identity; shrink/remove leaves stale topology references) and the rule that mutation must work while the rig is active, not just in clean fixtures.
+description: Use when changing a rig while it is alive — `rig grow` / `rig expand` / `rig shrink` / `rig launch` / `rig remove` / `rig discover` / `rig bind` / `rig adopt` / `rig attach`. Covers the 4 failure modes (newly created seat lacks queue/startup/role; edges and permissions not updated; adopt/bind succeeds at tmux but not OpenRig identity; shrink/remove leaves stale topology references) and the rule that mutation must work while the rig is active, not just in clean fixtures.
 metadata:
   cli_surfaces_referenced:
     - adopt
@@ -8,6 +8,7 @@ metadata:
     - bind
     - discover
     - expand
+    - grow
     - launch
     - ps
     - release
@@ -43,13 +44,32 @@ static launch scripts.
 
 ## Use this when
 
-- Adding capacity to a running rig (`rig expand <rig> <pod-fragment-path>`)
+- Adding seats to a running rig (`rig grow <rig-id> <member...>` for the simple case, a fragment with `rig expand` or `rig add` otherwise; see below)
 - Removing capacity (`rig shrink` / `rig remove`)
 - Launching/relaunching a node in a running rig (`rig launch`)
 - Binding a discovered session into an existing logical node (`rig bind`)
 - Adopting a topology + binding live sessions (`rig adopt`)
 - Attaching a shell or agent into a rig node (`rig attach --self`)
 
+## Adding seats: `rig grow` first, a fragment when you need more
+
+`rig grow <rig-id> <member...>` adds one or more seats to a running rig without
+writing YAML. Each seat gets the default agent spec and its `default` profile.
+Check `rig grow --help` on your installed version; at the time of writing:
+
+- `--pod <pod>`: the target pod; inferred when the rig has one pod
+- `--new-pod <pod>`: create a new pod for the seats (not together with `--pod`)
+- `--runtime <runtime>`: one runtime for every named seat (default `claude-code`)
+- `--cwd <path>`: one working directory for every named seat (default: the current directory)
+- `--json`: output for agents
+
+Write a fragment instead when a seat needs something `rig grow` does not set: an
+explicit model, a permission policy, a different agent spec or role profile, a
+per-seat runtime or working directory, or startup files. Use
+`rig expand <rig-id> <pod-fragment-path>` to add a pod, or
+`rig add <rig-id> <pod-namespace> <member-fragment-path>` to add one member to an
+existing pod.
+
 ## Don't use this when
 
 - The rig is being created fresh from scratch — use `rig up` (lifecycle, not mutation)
@@ -89,6 +109,7 @@ adding or removing a seat from replacing its occupant; use
 
 Per `cli-reference.md` v0.2.0:
 
+- `rig grow <rig-id> <member...> [--pod <pod> | --new-pod <pod>] [--runtime <runtime>] [--cwd <path>]` (added after v0.2.0; check `rig grow --help`)
 - `rig expand <rig-id> <pod-fragment-path>` (with optional `session_source`)
 - `rig shrink <rigId> <podRef>`
 - `rig launch <rigId> <nodeRef>`
@@ -114,7 +135,7 @@ unfinished proof obligation is implied by loading this skill.
 
 ## See also
 
-- `openrig-user` skill — CLI surface for `rig expand / shrink / launch / remove / bind / adopt / attach`
+- `openrig-user` skill — CLI surface for `rig grow / expand / shrink / launch / remove / bind / adopt / attach`
 - `seat-scaling-and-specialization` skill — when to add specialized capacity vs generic
 - `seat-continuity-and-handover` skill — replacing an occupant on a stable seat (different shape than topology mutation)
 - `cross-host-rig-commands` skill — cross-host topology mutation (deferred)

package/daemon/context-packs/skills/core/topology-mutation-and-seat-management/manifest.yaml

@@ -1,10 +1,10 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "topology-mutation-and-seat-management"
-version: "0.6.4"
+version: "0.6.6"
 taxonomy: "skills"
-purpose: "Use when changing a rig while it is alive — `rig expand` / `rig shrink` / `rig launch` / `rig remove` / `rig discover` / `rig bind` / `rig adopt` / `rig attach`. Covers the 4 failure modes (newly created seat lacks queue/startup/role; edges and permissions not updated; adopt/bind succeeds at tmux but not OpenRig identity; shrink/remove leaves stale topology references) and the rule that mutation must work while the rig is active, not just in clean fixtures."
+purpose: "Use when changing a rig while it is alive — `rig grow` / `rig expand` / `rig shrink` / `rig launch` / `rig remove` / `rig discover` / `rig bind` / `rig adopt` / `rig attach`. Covers the 4 failure modes (newly created seat lacks queue/startup/role; edges and permissions not updated; adopt/bind succeeds at tmux but not OpenRig identity; shrink/remove leaves stale topology references) and the rule that mutation must work while the rig is active, not just in clean fixtures."
 files:
   - path: "SKILL.md"
     role: "instruction"
-    summary: "Use when changing a rig while it is alive — `rig expand` / `rig shrink` / `rig launch` / `rig remove` / `rig discover` / `rig bind` / `rig adopt` / `rig attach`. Covers the 4 failure modes (newly created seat lacks queue/startup/role; edges and permissions not updated; adopt/bind succeeds at tmux but not OpenRig identity; shrink/remove leaves stale topology references) and the rule that mutation must work while the rig is active, not just in clean fixtures."
+    summary: "Use when changing a rig while it is alive — `rig grow` / `rig expand` / `rig shrink` / `rig launch` / `rig remove` / `rig discover` / `rig bind` / `rig adopt` / `rig attach`. Covers the 4 failure modes (newly created seat lacks queue/startup/role; edges and permissions not updated; adopt/bind succeeds at tmux but not OpenRig identity; shrink/remove leaves stale topology references) and the rule that mutation must work while the rig is active, not just in clean fixtures."

package/daemon/context-packs/skills/core/watchdog/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: "watchdog"
-version: "0.6.4"
+version: "0.6.6"
 taxonomy: "skills"
 purpose: "Use when configuring `rig watchdog` policies, authoring wake/refocus/alignment-checkpoint messages, or choosing the right intervention level for a stale-owner situation. The 3-level continuity-check stack (wake / refocus / alignment-checkpoint), the discipline that prevents cadence pollution and bureaucracy theater, and the artifact-pool loop-edge pattern for evidence-aware waking."
 files:

package/daemon/context-packs/skills/delegating-work/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: "delegating-work"
-version: "0.6.4"
+version: "0.6.6"
 taxonomy: "skills"
 purpose: "Use when you have a task and must decide WHO does it — yourself, a spawned subagent, or another agent in the topology that already holds the context. The rule: how much would a blank slate have to read in to do this correctly? A lot → route to a context-holding agent; a little → subagent; unsure → a real agent or yourself. NOT the mechanics of fanning out (that's dispatching-parallel-agents / subagent-driven-development) — this is the who/whether decision, and the failure mode that makes teams a"
 files:

package/daemon/context-packs/skills/forming-an-openrig-mental-model/SKILL.md

@@ -20,8 +20,6 @@ metadata:
     stage: factory-approved
     sibling_skills:
       - openrig-user
-      - openrig-operator
-      - openrig-builder
       - openrig-architect
       - openrig-upgrade
       - agent-operated-workflows
@@ -91,7 +89,10 @@ you should know which pillar you're operating in:
 OpenRig manages topology and exposes public context through `rig context`.
 Project-authored sources supply project-specific knowledge; transcripts retain
 recorded work. These sources already coexist. Discover the configured library
-and selected task context rather than assuming a particular private corpus.
+and selected task context rather than assuming a particular private corpus:
+`rig context list` shows the configured packs, and `rig context work-install`
+lists what the current project declares (intent, context files, skills), so you
+read only the pieces a task needs.
 
 ---
 
@@ -175,7 +176,7 @@ cost when you reach for one.
 |---|---|
 | `<rig-cwd>/.claude/skills/`, `<rig-cwd>/.agents/skills/` | Where the harness actually loads from. Populated by `rig up`. |
 | `~/.claude/skills/`, `~/.agents/skills/` | User-level harness skill directories. Inspect the current projection and harness configuration to determine which skills are installed and where they came from. |
-| `openrig/packages/daemon/{specs/agents/shared/skills,assets/plugins/*/skills}/` | Product skills that ship with OpenRig — the spec pool + the bundled plugin assets (openrig-user, openrig-operator, openrig-architect, forming-an-openrig-mental-model, queue-handoff, claude-compaction-restore, …). |
+| `packages/daemon/{specs/agents/shared/skills,assets/plugins/*/skills}/` (source checkout) | Product skills that ship with OpenRig — the spec pool + the bundled plugin assets (openrig-user, openrig-architect, forming-an-openrig-mental-model, queue-handoff, claude-compaction-restore, …). |
 | the skills authoring workspace | Skill authoring source (not runtime-loaded). |
 
 The product already discovers its installed shared skill pool and serves
@@ -195,7 +196,7 @@ rig whoami --json         # know who you are
 rig send <session> "msg"  # talk to a peer
 rig capture <session>     # see a peer's terminal
 rig transcript <session>  # read a peer's history
-rig down <rigId>          # snapshot and tear down
+rig down <rigId>          # snapshot and stop every agent; check rig ps first, only when asked
 rig up <rig-name>         # restore from snapshot
 ```
 
@@ -258,12 +259,12 @@ For real depth, these are the load-bearing canonical docs:
 
 | Reference | What it covers |
 |---|---|
-| `openrig/docs/as-built/README.md` | As-built map of territory — daemon architecture, system overview, package boundaries; routes to the 13 `architecture/` + 4 `ui/` modules via `codemap.md` |
-| `openrig/docs/as-built/cli-reference.md` | The full `rig` CLI surface with all subcommands and flags |
-| `openrig/docs/reference/rig-spec.md` | The RigSpec YAML format — pods, members, edges, all fields |
-| `openrig/docs/reference/agent-spec.md` | The AgentSpec YAML format — resources, profiles, imports |
-| `openrig/docs/reference/agent-startup-guide.md` | The 7-layer startup layering model; delivery hints |
-| the product taxonomy | Canonical vocabulary (read literally) |
+| `docs/as-built/README.md` (source checkout) | As-built map of territory — daemon architecture, system overview, package boundaries; routes to architecture and UI modules via `codemap.md` |
+| `rig --help`, then `rig <command> --help` | The installed CLI surface, subcommands and flags |
+| `rig context get reference/rig-spec.md` | The RigSpec YAML format — pods, members, edges, all fields |
+| `docs/reference/agent-spec.md` (source checkout) | The AgentSpec YAML format — resources, profiles, imports |
+| `docs/reference/agent-startup-guide.md` (source checkout) | The 7-layer startup layering model; delivery hints |
+| [Core vocabulary above](#the-core-vocabulary-read-these-terms-literally) | Vocabulary used in this skill (read literally) |
 | `openrig-operating-model` skill | Placement and operating-model guidance — topology and work trees, context altitude |
 | `openrig-architect` skill | Rig and topology authoring |
 | `https://agentskills.io/specification` | The cross-runtime skill standard |
@@ -281,7 +282,6 @@ touching YAML.
   CULTURE.md. Read those.
 - **Authoring a new rig.** Use the `openrig-architect` skill for that.
 - **Day-to-day OpenRig operation.** Use `openrig-user` for that.
-- **Administering an OpenRig install.** Use `openrig-operator`.
 
 This skill exists to **form your initial mental model of OpenRig as a
 system**. Once oriented, reach for the role-specific or task-specific skills

package/daemon/context-packs/skills/forming-an-openrig-mental-model/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: "forming-an-openrig-mental-model"
-version: "0.6.4"
+version: "0.6.6"
 taxonomy: "skills"
 purpose: "Use when the system around you does not make sense yet: you just booted into a seat and do not know how the pieces fit; someone said rig, pod, seat, fleet, topology, or slice and you are not certain what they mean here; you are unsure what kind of rig you are in or what it is for; you do not know how skills reach you or where context comes from; or you are about to act on a guess about how OpenRig works. Gives the runtime mental model fast, so you stop guessing."
 files:

package/daemon/context-packs/skills/loading-addressable-markdown/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: "loading-addressable-markdown"
-version: "0.6.4"
+version: "0.6.6"
 taxonomy: "skills"
 purpose: "Use when a mission, slice, dashboard, or task references Markdown as path#h2-slug or path#h2-slug/h3-slug outside the OpenRig context-pack library."
 files:

package/daemon/context-packs/skills/loading-addressable-markdown/scripts/resolve-markdown.mjs

@@ -54,7 +54,8 @@ function scanHeaders(lines) {
       const marker = fenceMatch[1][0];
       const length = fenceMatch[1].length;
       if (!fence) fence = { marker, length };
-      else if (fence.marker === marker && length >= fence.length) fence = null;
+      else if (fence.marker === marker && length >= fence.length
+        && /^[ \t\r]*$/.test(line.slice(fenceMatch[0].length))) fence = null;
       continue;
     }
     if (fence) continue;

package/daemon/context-packs/skills/mission-slice-sop/SKILL.md

@@ -64,9 +64,9 @@ These three are a division of labour, not a chain of gates. One agent may hold a
 - **HOW:** a slice carries `intent:` in frontmatter and opens with `## Intent`, `## Mini-requirements`, and `## Proof contract`. A mission carries its intent and mission-level specification in the same authored node file. Keep depth proportional to the work.
 
 ### PROGRESS.md
-- **WHO:** the orchestrator owns `§1` (current state); every agent logs its own outcomes.
+- **WHO:** the orchestrator owns the current state; every agent logs its own outcomes.
 - **WHEN:** on material delivery-state changes and at acceptance.
-- **HOW:** one line per outcome (checkbox), link down for detail; keep frontmatter `stage`/`verified` honest.
+- **HOW:** keep current delivery state in `## Current state`; append material outcomes with links to proof under `## Outcomes`. Retain historical entries and existing checkboxes without treating them as current acceptance authority. For a selected proof policy, use `rig proof show <slice>` for current readiness; keep frontmatter `stage`/`verified` honest.
 
 ### PROOF.md + proof/
 - **WHO:** the impl/QA pair that worked the slice.

package/daemon/context-packs/skills/mission-slice-sop/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: "mission-slice-sop"
-version: "0.6.4"
+version: "0.6.6"
 taxonomy: "skills"
 purpose: "Use when starting, building, handing off, restoring, or closing a mission or slice under the default lightweight SDLC."
 files:

package/daemon/context-packs/skills/openrig-operating-model/SKILL.md

@@ -343,6 +343,23 @@ mission carries its intent and mission-level specification in the same authored
 `mission-slice-sop` and any explicit mode overlay; mission specification is not a
 requirement to repeat every slice detail.
 
+### Project knowledge: three kinds, three homes
+
+Before you write down something you learned about a project, decide which kind it is.
+
+- **Product facts** say what is true of the software at a version: commands, behaviour, formats. They live in the
+  product's own documentation, versioned with the code and checked against source. Anywhere else, link to them
+  rather than copying them; a copy stops following releases.
+- **Project judgment** says how to work on the project now: intent, workflow, priorities, routes, who decides what.
+  It lives in the project's world pack and its work tree, and it can change without a release.
+- **Machine-local state** is true of one instance only: paths, hosts, live rosters, counts, credentials. It belongs
+  in configuration, in a seat's `LEARNED.md`, or as the command that derives it. It never goes into shipped content
+  or a shared world.
+
+Agents find a project's declared context with `rig context work-install`, which lists what the project declares:
+its intent, the context files in its `project.yaml` `install` block, and its skills. When project knowledge should
+reach every agent working on the project, add it to that declaration rather than starting a second index.
+
 ### The other axis: AUDIENCE is not MATURITY
 
 These are independent, and merging them is seductive because the merged version is prettier.

package/daemon/context-packs/skills/openrig-operating-model/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-operating-model"
-version: "0.6.4"
+version: "0.6.6"
 taxonomy: "skills"
 purpose: "Use when you do not know WHERE something belongs: you learned a lesson and are unsure which file takes it; you are about to create a new doc, folder, or convention; you are asking \"should this be a skill, a note, or a chain file?\"; you inherited a seat and want to know what SHOULD exist; or you are about to duplicate knowledge that already has a home. Also the trace-to-root: how a seat orients by reading one filename at each level from where it stands up to the fleet."
 files:

package/daemon/context-packs/skills/openrig-operating-model/scripts/compose.py

@@ -285,7 +285,7 @@ def resolve_roots():
     out = {}
     out["work_root"] = os.environ.get("OPENRIG_WORKSPACE_ROOT") or rig_config("workspace.root")
 
-    t = os.environ.get("OPENRIG_TOPOLOGY_ROOT") or rig_config("workspace.topology_root")
+    t = os.environ.get("OPENRIG_TOPOLOGY_ROOT") or rig_config("topology.root")
     if not t:
         # Resolve symlinks before walking upward; otherwise a projection ascends
         # its own tree rather than the shared-docs source.
@@ -559,7 +559,7 @@ if __name__ == "__main__":
             if v:
                 print(f"{k}={v}")
             else:
-                key = "workspace.root" if k == "work_root" else "workspace.topology_root"
+                key = "workspace.root" if k == "work_root" else "topology.root"
                 print(f"# {k} UNRESOLVED — set it: rig config set {key} <path>", file=sys.stderr)
         sys.exit(0 if all(r.values()) else 3)
     if not a.name:

package/daemon/context-packs/skills/openrig-user/SKILL.md

@@ -301,7 +301,10 @@ OpenRig v0.3.0 adds `rig agent-image`, `rig context-pack`, `rig workspace`, and
 `rig config init-workspace`. *(0.5.0: the `rig context-pack` alias is retired — the store + compose library is the single `rig context` noun; see "Context packs and paced delivery (0.5.0)".)* It also shifts fresh-user starter guidance toward
 `product-team` for human-directed work and `conveyor` for workflow-oriented
 work. Treat `demo` as legacy/test content unless a task specifically asks for
-the old demo spec.
+the old demo spec. *(0.6.6: the built-in teams are `starter` and `factory`, plus the
+specialist teams `code-review`, `research` and `pm`. `product-team`, `conveyor` and
+`demo` are gone, and `first-project` is starter's old name. `workshop` is a rig
+bundle.)*
 
 OpenRig v0.3.1 adds public package/source surfaces for Plugin Primitive v0,
 Claude Auto-Compaction Policy, migration `040_workflow_specs_diagnostic`,
@@ -327,7 +330,9 @@ before relying on a policy or its default.
 
 Compatibility checks:
 - `rig down` accepts a rig name or id. An ambiguous name matching more than one
-  active rig is refused with matching ids; use the intended id.
+  active rig is refused with matching ids; use the intended id. It ends every
+  agent's session and any work in progress, so check `rig ps --nodes --rig <rig>`
+  and that the person asked; `rig up <rig> --existing` restores it.
 - For queue/view JSON or limit differences, compare the installed command's help,
   the running daemon version and the actual response. A wrapper mismatch is not
   by itself a daemon-health failure, and historical workarounds are not current
@@ -357,8 +362,8 @@ rig start --json             # JSON output for agents
 ```
 
 Framing: `rig start` is the RECOVERY entry point, not the getting-started
-hero. The fresh-user boot hero remains `rig up <starter>` (typically
-`rig up product-team`). Reach for `rig start` after a host reboot, daemon
+hero. The fresh-user boot hero remains `rig up <team>` (typically
+`rig up starter` for a first change, or `rig up factory`). Reach for `rig start` after a host reboot, daemon
 restart, or any "bring my rigs back" moment.
 
 ### `rig reconcile-session` — no-launch adopt of a hand-resumed session
@@ -410,8 +415,23 @@ rig seat clear-attention <session> --reason "operator attested: the operator re-
 rig seat clear-attention <session> --json
 ```
 
-`--reason <text>` is the operator-attestation override path; without it the
-command runs the evidence gate. Either way the action is audited.
+`--reason <text>` can acknowledge startup-status and subset-restore attention.
+It does not bypass full-restore continuity checks or an active pane-identity
+mismatch/missing-pane check; those run first. Successful identity re-verification
+can also clear coexisting startup or subset-restore attention. If neither earlier
+path clears attention, omitting `--reason` requires activity or send evidence.
+Startup and restore clears write their corresponding audit events; an identity-only
+clear updates the current binding and identity verdict without a clear event.
+Acknowledgment or responsiveness alone does not prove that the original
+conversation resumed.
+
+A 422 response names the uncleared class and its failed check. If the recorded
+native token needs correction and you know the actual token, use
+`rig seat set-resume-token <session> --token-stdin --reason <explanation>`, then
+rerun `rig seat clear-attention <session>` to check the live evidence. The token
+update records operator provenance; it does not itself prove continuity.
+Stopping/relaunching a working seat is a separate disruptive operation, not a
+required cleanup or proof of resumed lineage.
 
 ### Periodic snapshots — crash-insurance floor
 
@@ -541,7 +561,7 @@ rig scope mission progress <mission> --add "<line>"   # append a progress line;
 rig scope slice progress <slice-path> --add "<line>"  # same flags: --add / --set, --section <heading>, --status active|done|blocked
 ```
 
-Replaces hand-editing `PROGRESS.md` with markdown. Writes the canonical structure the OpenRig PROGRESS UI page reads. `rig scope mission create` + `rig scope slice create` now scaffold `PROGRESS.md` automatically per `conventions/scope-and-versioning/README.md`.
+Replaces hand-editing `PROGRESS.md` with markdown. Writes the canonical structure the OpenRig PROGRESS UI page reads. `rig scope mission create` + `rig scope slice create` now scaffold `PROGRESS.md` automatically.
 
 ### `rig scope mission|slice stage / verified / repair` — deterministic maturity vocabulary
 
@@ -560,7 +580,7 @@ rig scope slice show <slice>                          # derives read-time effect
                                                       # — stale-`verified` `canonical` reported as effectively `provisional`
 ```
 
-Composes with the `progress` command + scaffolding to make `rig scope` the **deterministic enforcer** of `conventions/scope-and-versioning` §1 (dot-IDs) + §2 (maturity vocabulary). Agents update `stage` / `verified` / `id` through commands rather than hand-editing markdown and drifting. The `--against` MANDATORY rule on `verified` is the anti-stale keystone: bare timestamps are rejected because a bare timestamp is exactly what lets stale trackers lie while looking fresh. **STOP hand-editing the `stage` / `verified` / `id` fields in scope frontmatter; use the new verbs.** Existing missions / slices with `id:null` ghosts or missing `PROGRESS.md` are repaired idempotently via `repair`.
+Composes with the `progress` command + scaffolding to update scope IDs and maturity vocabulary through `rig scope`. Agents update `stage` / `verified` / `id` through commands rather than hand-editing markdown and drifting. The `--against` MANDATORY rule on `verified` is the anti-stale keystone: bare timestamps are rejected because a bare timestamp is exactly what lets stale trackers lie while looking fresh. **STOP hand-editing the `stage` / `verified` / `id` fields in scope frontmatter; use the new verbs.** Existing missions / slices with `id:null` ghosts or missing `PROGRESS.md` are repaired idempotently via `repair`.
 
 ### `rig skill audit` — skill cascade provenance
 
@@ -575,7 +595,17 @@ Read-only audit of the skill cascade. Detects `missing` / `stale` / `self-refere
 
 ### `rig seat clear-attention` — extended to derived projection staleness
 
-v0.3.4 shipped `clear-attention` gating on `session.startupStatus` only. v0.4.0 extends the verb to also reach **restoreOutcome-derived** attention (seat is `startupStatus=ready` + `sessionStatus=running` but carries `restoreOutcome=failed` / `continuityOutcome=failed`). Same evidence-gated audit row applies; the `--reason <text>` operator-attestation override carries the runtime / cwd-uncertainty disclosure honestly.
+`clear-attention` also reaches restore-derived attention even when
+`startupStatus=ready` and `sessionStatus=running`. Full-restore attention requires
+the restore reconciler's exact native-token and usable-pane checks; `--reason`
+cannot replace them. Subset-restore attention can reach the attestation path
+when no active pane-identity class takes precedence. That path records
+`operator_recovered` with `runtimeCwdVerified:false`; it is an acknowledgment,
+not proof of resumed lineage. Without an explicit stored continuity outcome,
+inventory leaves continuity null (`unverified` in `rig seat status`) unless the
+same restore attempt has a matching receipt and reconciliation with strict
+native-token and usable-pane proof. Explicit stored outcomes remain historical
+facts; acknowledgment or responsiveness alone cannot infer `resumed`.
 
 ### Native Codex session id capture
 
@@ -877,8 +907,6 @@ narration — a good observation beats ten noisy ones. It's a passing thought yo
 6. Monitor: `rig chatroom wait my-rig --timeout 120`
 7. Close: `rig chatroom topic my-rig "ROUND CLOSED"`
 
-See `docs/planning/roadmaps/chatroom-roundtable-protocol.md` for the full protocol.
-
 ### `rig ask`
 
 ```bash
@@ -918,7 +946,7 @@ rig auth seats … --runtime codex         # seat -> profile registry (metadata
 
 ### `rig context` — the store + compose library (never delivers)
 
-Manage and compose context (any text/markdown) into reusable **packs**. Every piece and pack has a stable, **path-like ref** — you address context the way you address files (`packs/compaction-restore`, `as-built/queue-internals`).
+Manage and compose context (any text/markdown) into reusable **packs**. Every piece and pack has a stable, **path-like ref** — you address context the way you address files (`skills/claude-compaction-restore`, `reference/rig-spec.md`).
 
 ```bash
 rig context list                     # what's in the library
@@ -955,12 +983,12 @@ Walk a seat *through* a pack: each piece is sent into the pane, spaced by `--pac
 - **`--body-context` snapshot rule:** a qitem built from a ref stores the **resolved content** in its body **plus the ref for provenance** — the handoff carries what was actually sent, and a later library edit never silently rewrites a past handoff's history.
 - **The orchestrator habit — assign work *with* its context attached:**
   ```bash
-  rig context compose --out packs/qitem-brief --from as-built/queue.md conventions/c1-proof.md
+  rig context compose --out packs/qitem-brief --from <brief-file> <proof-file>
   rig queue create --destination dev-driver@build --body-context packs/qitem-brief --summary "…"
   ```
-  The assignee never greps for the as-built; the curated context rides the durable handoff, survives compaction, and is auditable.
+  Replace `<brief-file>` and `<proof-file>` with your existing local files. The curated context rides the durable handoff, survives compaction, and is auditable.
 
-**Skills tier vs context tier:** skills are the HOT tier (ambient, finite, always-visible front-matter); context packs are the COLD tier (unbounded, fetched on instruction — "walk yourself through `packs/tui-onboarding`"). Don't overrun the skill layer by using skills as context packs — that's what this primitive is for.
+**Skills tier vs context tier:** skills are the HOT tier (ambient, finite, always-visible front-matter); context packs are the COLD tier (unbounded, fetched on instruction — "read `rig context get onboarding-width`"). Don't overrun the skill layer by using skills as context packs — that's what this primitive is for.
 
 ## Lifecycle
 
@@ -1250,6 +1278,7 @@ This lets ordinary agents ask the manager for OpenRig help instead of every agen
 ### Add/remove running topology parts
 
 ```bash
+rig grow <rig-id> <member...> [--pod <pod> | --new-pod <pod>] [--runtime <runtime>] [--cwd <path>] [--json]
 rig expand <rig-id> <pod-fragment-path> [--rig-root <path>] [--json]
 rig launch <rigId> <nodeRef> [--json]
 rig launch <rigId> --seats <a,b,c> [--hold-reason <text>] [--json]
@@ -1258,6 +1287,12 @@ rig shrink <rigId> <podRef> [--json]
 rig unclaim <sessionRef> [--json]
 ```
 
+`rig grow` is the simplest way to add seats: no YAML, the default agent spec, and one
+runtime and working directory for the named seats (`--new-pod` creates a pod for them).
+Check `rig grow --help` on your installed version. Use a fragment with `rig expand` (a pod)
+or `rig add` (one member) when a seat needs an explicit model, a permission policy, a
+different agent spec or role profile, per-seat runtime or cwd, or startup files.
+
 Node-granular managed partial restore (v0.3.4+):
 - `rig launch <rigId> <nodeRef>` relaunches a single seat by logical id or node id through orchestration.
 - `rig launch <rigId> --seats <a,b,c>` relaunches a comma-separated subset of seats.
@@ -1267,14 +1302,12 @@ Node-granular managed partial restore (v0.3.4+):
 ### Add a member to an existing pod — v0.3.3+
 
 ```bash
-rig add <rig> <member-fragment-path> [--json]
-rig add-member <rig> <member-fragment-path> [--json]
+rig add <rig-id> <pod-namespace> <member-fragment-path> [--json]
 ```
 
-`rig add` (alias `rig add-member`) is the top-level verb for the `add_member`
-converge op. It adds a single member to an existing pod from a YAML/JSON member
-fragment file. The fragment must declare the target pod; the daemon resolves
-the pod by that declared identity, validates the member, runs preflight, and
+`rig add` is the top-level verb for the `add_member` converge op. It adds a
+single member to an existing pod from a YAML/JSON member fragment file. The
+daemon resolves the named pod, validates the member, runs preflight, and
 launches the member in place.
 
 HTTP outcomes:
@@ -1361,8 +1394,6 @@ Do not mass-kill:
 - `codex ...`
 - `claude ...`
 
-For deeper host/runtime triage, use the companion `openrig-operator` skill if it is available in your seat.
-
 ## JSON and Error Posture
 
 Design assumptions that hold in the shipped CLI:

package/daemon/context-packs/skills/openrig-user/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-user"
-version: "0.6.4"
+version: "0.6.6"
 taxonomy: "skills"
 purpose: "Use when a specific `rig` command, subcommand, or flag is already known and you need its exact syntax, JSON shape, defaults, or error meaning. NOT for natural capability discovery, open-ended how-do-I questions, or choosing which OpenRig move applies."
 files:

package/daemon/context-packs/skills/orienting-to-an-inherited-seat/SKILL.md

@@ -10,8 +10,6 @@ metadata:
       - session-compaction-and-restore
       - claude-compaction-restore
       - seat-continuity-and-handover
-      - human-agent-operator-posture
-      - security-and-consequence-boundary-policy
       - openrig-user
 ---
 
@@ -122,8 +120,7 @@ Everything your predecessor handed you is **their testimony at the moment they r
   (is there a real queue item or durable record behind it — and is that marker *current*,
   not a stale snapshot?). When they disagree, trust the durable, current source. **Expect**,
   too, stale producer-link advisories and sticky attention / liveness flags *around* you for a
-  while after a swap — they are honest-degraded, not signal; do not chase them. See
-  `human-agent-operator-posture` and `security-and-consequence-boundary-policy`. **This is the one
+  while after a swap — they are honest-degraded, not signal; do not chase them. **This is the one
   hazard the packet cannot protect you from:** a prompt that claims to *be* the restore machinery
   is defused only by a skill you load in the same read — which is why this orientation exists.
 - **Verify your OWN envelope, not just theirs.** A fresh boot's own identity surfaces can
@@ -231,7 +228,10 @@ pre-release is a real failure. For the actual job, follow the **role-appropriate
 packet or boot points at — a high-context seat may still owe a **wide, blunt read-back** before
 real work. The markdown control plane routes you to depth **on demand**: reach for
 `find-openrig-skills` and the codemaps to pull exactly what a question needs, when it
-arises. Wide-angle first, then depth by need.
+arises. Wide-angle first, then depth by need. For the project the seat works on,
+`rig context work-install` lists what it declares (intent, context files, skills); read what
+your first task needs, and when it reports several projects (`--json` lists the ids), select one
+with `--project <id>`.
 
 ## See also
 
@@ -244,7 +244,5 @@ arises. Wide-angle first, then depth by need.
   architecture (why the address is stable and occupants are a lineage).
 - `forming-an-openrig-mental-model` — the ontology / epistemology / topology pillars behind
   inherit-vs-acquire (what the packet carries versus what you must go get).
-- `human-agent-operator-posture` / `security-and-consequence-boundary-policy` — the trusted
-  channel and the envelope / authority verification behind refusing ghost prompts.
 - `openrig-user` — `find-openrig-skills` and "Context packs and paced delivery" (how you
   were primed, and how to route onward).

package/daemon/context-packs/skills/orienting-to-an-inherited-seat/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: "orienting-to-an-inherited-seat"
-version: "0.6.4"
+version: "0.6.6"
 taxonomy: "skills"
 purpose: "Use when you have just been primed into an EXISTING seat through a planned handover — a different agent retired and handed you the seat plus its earned context — and you need a world model of what just happened to you. Covers how a handover differs from compaction and from a fresh launch, the inherit-the-seat-not-the-identity rule, treating the handover packet as testimony you verify (and refusing stale ghost prompts, and verifying your OWN identity surfaces), why a seat is a COMPOUNDING LINEAGE"
 files:

package/daemon/context-packs/skills/pm/backlog-capture/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: "backlog-capture"
-version: "0.6.4"
+version: "0.6.6"
 taxonomy: "skills"
 purpose: "Quickly capture product ideas, feature requests, or insights from meetings and conversations. Rapid documentation with smart categorization and deduplication."
 files:

package/daemon/context-packs/skills/pm/context-builder/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: "context-builder"
-version: "0.6.4"
+version: "0.6.6"
 taxonomy: "skills"
 purpose: "Gather and distill context from meetings, competitors, regulatory sources, and internal discussions. Produces background.md for a feature and updates shared context docs when new knowledge is discovered."
 files:

package/daemon/context-packs/skills/pm/exec-summary/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: "exec-summary"
-version: "0.6.4"
+version: "0.6.6"
 taxonomy: "skills"
 purpose: "Generate a 1-2 page executive summary for a feature — orients sales, leadership, and engineering from a single document."
 files:

package/daemon/context-packs/skills/pm/office-hours/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: "office-hours"
-version: "0.6.4"
+version: "0.6.6"
 taxonomy: "skills"
 purpose: "YC-style product validation using six forcing questions. Pressure-tests a feature idea before it becomes a requirement — ensuring real demand, a clear wedge, and evidence behind assumptions."
 files:

package/daemon/context-packs/skills/pm/plan-review/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: "plan-review"
-version: "0.6.4"
+version: "0.6.6"
 taxonomy: "skills"
 purpose: "Multi-perspective review of a feature plan or requirements doc before development begins. Evaluates from strategy, design/UX, and engineering angles to catch gaps early."
 files:

package/daemon/context-packs/skills/pm/requirements-writer/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: "requirements-writer"
-version: "0.6.4"
+version: "0.6.6"
 taxonomy: "skills"
 purpose: "Use when converting PM intake into a slice SPEC.md with observable acceptance outcomes, explicit scope, and advisory sibling build dependencies."
 files:

package/daemon/context-packs/skills/pm/ui-mockup/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: "ui-mockup"
-version: "0.6.4"
+version: "0.6.6"
 taxonomy: "skills"
 purpose: "Create UI mockups at three fidelity levels — ASCII wireframes for quick iteration, standalone HTML mockups for delivery with requirements, and live prototypes for interaction testing."
 files:

package/daemon/context-packs/skills/pods/development-team/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: "development-team"
-version: "0.6.4"
+version: "0.6.6"
 taxonomy: "skills"
 purpose: "Use when a development pod begins or hands off implementation, QA, or design work."
 files:

package/daemon/context-packs/skills/pods/orchestration-team/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: "orchestration-team"
-version: "0.6.4"
+version: "0.6.6"
 taxonomy: "skills"
 purpose: "Use when coordinating assignments, selected review boundaries, or blocked work across a rig."
 files: