@openrig/cli 0.7.0 → 0.7.1

package/daemon/context-packs/skills/core/messaging-the-human/SKILL.md

@@ -71,6 +71,20 @@ rig queue create --destination <entityId>@external \
   --evidence-ref <durable-evidence> --verify --json
 ```
 
+An ask is on Steering and the TUI, where the person can answer it, choosing an
+option or typing a reply; it comes back to you exactly as a Slack answer does.
+Whether it also posts to Slack is the person's Slack subscription (`rig gateway
+human show <id>`, `slack-subscription`): by default (`every-ask`) every ask
+posts, and with `urgent-only` only an ask marked `--alert` does. So forgetting
+`--alert` never hides an ask from someone who reads Slack.
+
+Add `--alert` when the ask is urgent: something only they can do, or an approval
+whose wait costs now. A sign-in, a credential or an approval that expires needs
+it; a question that can wait for their next look doesn't. An alerted ask stands
+out in Slack (an interrupt with a mention, within their quiet hours and
+availability), and it's the only kind that reaches someone on `urgent-only`.
+An update (`--human-intent update`) posts as before and takes no `--alert`.
+
 Before asking a **decision**, check whether the person has a mode on with a
 decision room: what they said the team may decide for them meanwhile.
 
@@ -125,8 +139,8 @@ 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
+options (labels up to 75 characters, at most one recommended). The TUI lists
+each question with its options, and Slack (when alerted) shows each 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. In `humanAnswers`, clicked answers are option-id strings.
 A whole typed reply is an object:
@@ -148,8 +162,9 @@ well would issue another notification for the same decision.
 
 The row persists before bounded delivery verification. Read its qitem ID and
 verification result; `posted` proves connector posting, **not human readership**.
-`transport-failed`, `never-posted`, or a pending/indeterminate result leaves the
-row intact. Inspect that same row and its next action; never create a second row
+`not-alerted` means the person's Slack subscription is `urgent-only`, so the ask is
+on Steering and the TUI without a Slack post, as they chose; it isn't a failure. `transport-failed`, `never-posted`, or a pending/indeterminate result
+leaves the row intact. Inspect that same row and its next action; never create a second row
 or blindly resend because verification timed out.
 
 ```bash

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.7.0"
+version: "0.7.1"
 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/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.7.0"
+version: "0.7.1"
 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.7.0"
+version: "0.7.1"
 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/SKILL.md

@@ -111,6 +111,9 @@ system-clipboard copy works immediately (it's server-wide).
 - **Inner tmux status bar** is hidden by default (herdr provides the chrome); one config key
   (`terminal.status_bar`) flips it back on for raw-tmux / no-provider surfaces, and the flip applies
   to **future launches only**.
+- **After a Herdr server restart or update** (without `--handoff`), Herdr restores the layout and
+  labels but not the processes, so OpenRig's tiles come back as empty shells while the seats keep
+  running. Reopen the view: `rig terminal open <view> --provider herdr`.
 
 ## Saved views — the library (`terminal-views.yaml`)
 

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.7.0"
+version: "0.7.1"
 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.7.0"
+version: "0.7.1"
 taxonomy: "skills"
 purpose: "Use when an agent running inside OpenRig needs 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 when the agent doesn't know what applies or nothing is projected on cold boot. Installing, starting or updating OpenRig, getting back to a team or bringing a stopped one back from a person's own sess"
 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.7.0"
+version: "0.7.1"
 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

@@ -504,7 +504,7 @@ At each completed step, the **current packet owner** projects its own result. Ex
 
 ```sh
 rig workflow project --instance <instance-id> --current-packet <inspect-packet> \
-  --exit handoff --actor-session dev-build@starter \
+  --exit handoff \
   --result-note 'Inspection contract implemented; exact candidate and checks recorded' \
   --evidence-ref <absolute-slice-01-proof-path> --json
 ```
@@ -515,7 +515,7 @@ For a **real unresolved blank-cell product choice**, ask the user the concrete q
 
 ```sh
 rig workflow project --instance <instance-id> --current-packet <cli-packet> \
-  --exit waiting --actor-session dev-build@starter \
+  --exit waiting \
   --blocked-on external:user/blank-required-cells \
   --result-note 'Need the user decision recorded in mission NOTES before selecting CLI behavior' \
   --evidence-ref <absolute-mission-notes-path> --json

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.7.0"
+version: "0.7.1"
 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:

package/daemon/context-packs/skills/core/rig-bundles-and-shareable-artifacts/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: "rig-bundles-and-shareable-artifacts"
-version: "0.7.0"
+version: "0.7.1"
 taxonomy: "skills"
 purpose: "Use when authoring or installing a rig bundle (packaged, shareable artifact that instantiates an opinionated OpenRig topology + workflow), reasoning about the bundle vs extension boundary, or auditing a bundle for portability. Covers the 4 failure modes that prevent bundles from working anywhere but the operator's machine, and the inspect-before-install discipline."
 files:

package/daemon/context-packs/skills/core/rig-lifecycle/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: "rig-lifecycle"
-version: "0.7.0"
+version: "0.7.1"
 taxonomy: "skills"
 purpose: "Use when reasoning about the rig lifecycle operations family (create / start / stop / resume / restore / snapshot / release / unclaim / destroy), reading or trusting `rig ps` / lifecycle projections after recovery, or designing proof for a lifecycle scenario. Covers the 4 failure modes (auto-restore creates partial rig; projections report healthier than reality; provider auth treated as impl work; resume succeeds for one runtime fails another) plus the restore-honesty rule (failed resume is FAIL"
 files:

package/daemon/context-packs/skills/core/session-source-fork/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: "session-source-fork"
-version: "0.7.0"
+version: "0.7.1"
 taxonomy: "skills"
 purpose: "Use when authoring a rig spec member or `rig expand` payload that needs to start a new managed seat from a prior runtime conversation source — `session_source: { mode: fork, ref: { kind, value } }`. v1 supports `mode: fork` with `ref.kind: native_id` for Claude and Codex. The new seat persists a NEW post-fork token; the parent token is NEVER written onto the new seat. NOT for restoring an existing seat or for artifact-backed mental-model rebuild."
 files:

package/daemon/context-packs/skills/core/specification-system/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: "specification-system"
-version: "0.7.0"
+version: "0.7.1"
 taxonomy: "skills"
 purpose: "Use when authoring rig specs, agent specs, workflow specs, startup/context fragments, operating-mode declarations, or designing the user spec library. Covers the 4 failure modes (spec instantiates topology but not workflow/mode; spec depends on local paths and fails on another host; agents modify specs as one-off files instead of preserving reusable intent; validation proves YAML shape but not whether topology can run) and the validation-vs-runtime-realization distinction."
 files:

package/daemon/context-packs/skills/core/topology-mutation-and-seat-management/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: "topology-mutation-and-seat-management"
-version: "0.7.0"
+version: "0.7.1"
 taxonomy: "skills"
 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:

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.7.0"
+version: "0.7.1"
 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.7.0"
+version: "0.7.1"
 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 — or how to brief the agent you hand it to, which depends on the model it runs. 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-developme"
 files:

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

@@ -163,9 +163,12 @@ cost when you reach for one.
 ### Where skills come from in OpenRig
 
 - **Per-agent loadout:** your AgentSpec's `profile.uses.skills: [...]`
-  determines what skills get projected into your runtime skill folder
-  (`.claude/skills/` or `.agents/skills/`) before your harness boots. This
-  is the **structural composition** layer.
+  determines what skills get projected into your seat's own skill storage
+  before your harness boots. A Claude seat gets them through OpenRig's
+  generated plugin, named `openrig:<id>`; a Codex seat through its skill
+  catalog. A seat without that storage gets them in the project's
+  `.claude/skills/` or `.agents/skills/`. This is the **structural
+  composition** layer.
 - **Cross-pod sharing:** AgentSpecs can `imports: [shared]` to access a
   shared skill pool. Built-in agents commonly do this.
 - **Belt-and-suspenders:** the spec projects skill files; startup guidance
@@ -176,7 +179,8 @@ cost when you reach for one.
 
 | Home | Purpose |
 |---|---|
-| `<rig-cwd>/.claude/skills/`, `<rig-cwd>/.agents/skills/` | Where the harness actually loads from. Populated by `rig up`. |
+| `<OpenRig home>/state/seats/<rig id>/<logical seat>/<runtime>/` | A team seat's own skills, outside the project. Claude loads them through the generated plugin (`plugin/skills/`); Codex reads them by path from the seat's `catalog.md` (`skills/`). Populated at launch. |
+| `<rig-cwd>/.claude/skills/`, `<rig-cwd>/.agents/skills/` | The project's own skills, which the harness also loads. A seat without its own storage gets its skills here. |
 | `~/.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. |
 | `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). |
@@ -239,9 +243,10 @@ If you're booting into a new seat in an OpenRig rig:
    `guidance/role.md` for your specific seat.
 3. **Read the rig's `CULTURE.md`** if it has one — the team operating
    manual.
-4. **Check what skills you have** — list `.claude/skills/` or
-   `.agents/skills/` in your cwd. Each skill has a frontmatter description
-   that tells you when to reach for it.
+4. **Check what skills you have** — `rig skill loadout --seat self` shows
+   your seat's own skills; `.claude/skills/` or `.agents/skills/` in your
+   cwd hold the project's. Each skill has a frontmatter description that
+   tells you when to reach for it.
 5. **Check your peers** — `rig ps --nodes` and the queue first (who is up,
    who holds what). Capture a peer (`rig capture <peer-session>`) only when
    you actually need to see its screen.
@@ -302,7 +307,7 @@ that fit your actual work.
 | "I should manage Codex's compaction the way I manage Claude's" | No. Codex auto-compacts cleanly; Claude doesn't. Different runtimes, different lifecycles. |
 | "MEMORY.md auto-loads, so I don't need to read it" | Maybe. Sometimes MEMORY.md auto-loads via system reminders; sometimes not. Don't assume. If your work touches the topics it covers, read it explicitly. |
 | "Skills inherit from a parent or compose like classes" | No. Skills are flat artifacts; composition happens via AgentSpec `profile.uses.skills` (structural) or soft cross-references in skill bodies (advisory). Not via OO-style inheritance. |
-| "The substrate `shared-docs/skills/` folder is the canonical runtime path" | No. The harness doesn't read there. It's an authoring workspace. Runtime loads from `.claude/skills/`, `.agents/skills/`, and product built-in. |
+| "The substrate `shared-docs/skills/` folder is the canonical runtime path" | No. The harness doesn't read there. It's an authoring workspace. Runtime loads from the seat's own skill storage, `.claude/skills/`, `.agents/skills/`, and product built-in. |
 
 ---
 

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.7.0"
+version: "0.7.1"
 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.7.0"
+version: "0.7.1"
 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/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.7.0"
+version: "0.7.1"
 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/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.7.0"
+version: "0.7.1"
 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: