@openrig/cli 0.5.5 → 0.5.7

package/daemon/specs/agents/shared/agent.yaml

@@ -6,30 +6,22 @@ resources:
   skills:
     - id: agent-browser
       path: skills/process/agent-browser
-    - id: brainstorming
-      path: skills/process/brainstorming
     - id: dogfood
       path: skills/process/dogfood
-    - id: executing-plans
-      path: skills/process/executing-plans
     - id: frontend-design
       path: skills/process/frontend-design
-    - id: using-superpowers
-      path: skills/process/using-superpowers
     - id: openrig-architect
       path: skills/core/openrig-architect
     - id: rig-lifecycle
       path: skills/core/rig-lifecycle
     - id: openrig-upgrade
       path: skills/core/openrig-upgrade
-    - id: systematic-debugging
-      path: skills/process/systematic-debugging
     - id: test-driven-development
       path: skills/process/test-driven-development
+    - id: systematic-debugging
+      path: skills/process/systematic-debugging
     - id: verification-before-completion
       path: skills/process/verification-before-completion
-    - id: writing-plans
-      path: skills/process/writing-plans
     - id: orchestration-team
       path: skills/pods/orchestration-team
     - id: development-team

package/daemon/specs/agents/shared/skills/core/cross-host-rig-commands/SKILL.md

@@ -30,11 +30,8 @@ operator pattern (`ssh <host> rig <cmd>`) with declared host identity,
 explicit cross-host invocation path, preserved `--verify` semantics, and
 4 named failure modes.
 
-**Current-host note (2026-07-14):** this skill still preserves the original
-SSH-v0 doctrine below, but the live host registry may also contain HTTP
-read-through/tunnel entries such as `your-vm` and `your-other-vm`. Use the
-host registry entry as ground truth for transport shape, and use
-`conventions/multi-host-naming/README.md` for host-id naming. HTTP entries
+The live host registry may contain SSH or HTTP read-through/tunnel entries.
+Use each registry entry as ground truth for transport shape. HTTP entries
 require `url` plus exactly one of `bearer_file` or `bearer_env`.
 
 **v0 is CLI-side shell-out only — `packages/daemon/` is NOT touched.**
@@ -73,24 +70,20 @@ differs from the interactive verbs (`send`/`capture`/`ps`/`whoami`):
 
 ## Host registry shape (`~/.openrig/hosts.yaml`)
 
-Host ids should follow the OpenRig-work multi-host naming convention:
-`conventions/multi-host-naming/README.md`. In this environment that means
-physical hosts such as `your-vm`, local OpenRig development VMs such as
-`your-vm`, persistent product VMs such as `your-other-vm`, and VPS hosts such
-as `your-vps`. Keep old aliases during migration until no live routing
-depends on them.
+Host ids must be non-empty and unique. Choose stable, operator-meaningful ids
+that describe the destination without depending on transient network details.
 
 ```yaml
 hosts:
   - id: a-test-vm
     transport: ssh                       # v0 supports "ssh" only
     target: a-test-vm.local         # DNS name, SSH config alias, or IP
-    user: wrandom                        # optional
+    user: example-user                   # optional
     notes: "Tart VM"                     # optional
   - id: laptop-b
     transport: ssh
     target: laptop-b.tail-scale-net
-    user: wrandom
+    user: example-user
 ```
 
 Validation rules:

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

@@ -0,0 +1,98 @@
+---
+name: messaging-the-human
+description: "Use when a human decision, access grant, external action, or escalation must survive the operator's absence, or when an orchestrator or PM has a judgment-worthy update for the operator."
+metadata:
+  cli_surfaces_referenced:
+    - gateway human add
+    - gateway human list
+    - queue block
+    - queue handoff
+    - queue transitions
+    - send
+  openrig:
+    stage: provisional
+    audience: all agents
+    sibling_skills:
+      - queue-handoff
+      - human-in-the-loop
+      - openrig-user
+---
+
+# Messaging the Human
+
+The human is an addressable participant, but their attention is scarce and they
+may not be at a terminal. Anything that must survive their absence needs a
+durable queue row; the gateway turns the human blocker on that row into the
+external notification.
+
+Any seat may contact the human directly for a real escalation. Orchestrators
+and product managers may also send updates they judge the human would want to
+know. Do not add a routing intermediary merely because of your role.
+
+## The supported route
+
+First discover the registered human identity. Never invent or remember an
+address:
+
+```bash
+rig gateway human list --json
+```
+
+Use `humans[].entityId` to derive the durable blocker as `<entityId>@host`.
+The entity id must use the human-seat prefix (`human` or `human-...`); if it
+does not, stop and repair the registration rather than guessing. The returned
+`humans[].address` is the gateway delivery address, not the `--on` value. If no
+unambiguous registered human is returned, stop: registration is lifecycle work
+(`rig gateway human add --help`), not an address to guess.
+
+Keep the work row owned by the agent who must resume it, then park that row on
+the registered human:
+
+```bash
+rig queue block <qitem-id> --on <entityId>@host \
+  --summary "<decision owed>" \
+  --evidence-ref "<durable artifact the human should judge>" \
+  --continuation "<what resumes after the answer>"
+```
+
+The gateway resolves the registered human to the configured connector, sends
+the Slack notification, and records its receipt on the same row. Confirm the
+effect from the append-only history:
+
+```bash
+rig queue transitions <qitem-id>
+```
+
+The row is the obligation and the audit trail. Slack is the attention leg. A
+reply resolves the durable blocker and wakes the row owner; it does not create
+a second private work stream.
+
+## When to use it
+
+Escalate directly when only the human can supply the missing capability:
+
+- a decision or irreversible judgment only they own;
+- access, credentials, authority, or capacity only they can grant;
+- an external action only they can perform;
+- a security-class or provider/model-fallback event they need to know about.
+
+Orchestrators and product managers may additionally send meaningful milestone,
+environment, or completion updates. Prefer signal over routine narration.
+
+## Boundaries
+
+- `rig send` sends text to an agent's terminal. It is not the Slack route and
+  does not create a durable human obligation.
+- An unregistered or ambiguous human identity must fail loudly. Register or
+  repair the identity; never downgrade it to an agent seat or a guessed
+  `@external` address.
+- Agent-to-agent work that needs closure uses `rig queue handoff`, not this
+  human-blocker path.
+- Deferred work that is not imminent belongs in the mission workspace, not on
+  the queue.
+
+## Writing the escalation
+
+Lead with what is blocked and the exact decision or action needed. Point at the
+durable evidence instead of pasting a second copy, and name the continuation so
+the system can resume the right work when the answer arrives.

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

@@ -0,0 +1,115 @@
+---
+name: openrig-skills
+description: "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."
+allowed-tools: Bash(rig:*)
+metadata:
+  openrig:
+    stage: shipped
+---
+
+# OpenRig skills — the index (start here)
+
+You're running inside OpenRig. OpenRig ships a set of **skills** — small documents that tell you *when* to do something and *how*. This file is the map: what ships, when to reach for each, and how to load it. If you don't know which skill applies, or nothing is projected into your context, **start here.**
+
+## How OpenRig context works (30 seconds)
+
+Skills are **progressive disclosure**: a skill's *name + description* sit in your context ambiently (the "hot tier"); its *body* loads only when you open it. So you don't pre-read everything — you pattern-match a skill's "when" to your moment, then open just that one. This file is the index over the whole shipped set. (For the full model of building/operating agent software, open `software-for-agents`.)
+
+Every row below names **how to reach the skill** — already-hot, or an exact load path. No row is a dead end.
+
+## Loading an entry on demand — `rig context get`
+
+Don't guess a file path or a name. Go **ask → ref → load** in three steps:
+
+1. **Discover** — run `rig context list` for every shipped entry's **ref** and name. The *when* for
+   each is the index below (or `rig context list --json`, which carries each entry's purpose) — match
+   your moment there.
+2. **Select** — match your moment to a row's *when* and take its **ref**. Refs are canonical full paths
+   that mirror the library layout — `skills/<namespace>/<name>` (e.g. `skills/core/rig-lifecycle`,
+   `skills/process/systematic-debugging`). A unique bare name (e.g. `watchdog`) also resolves; any
+   slash-bearing ref is an exact lookup and fails loud if it does not exist.
+3. **Load** — `rig context get skills/<namespace>/<name>`:
+
+```
+rig context get skills/core/rig-lifecycle
+```
+
+The router itself is available through both forms it teaches:
+`rig context get openrig-skills` and `rig context get skills/core/openrig-skills`.
+
+The content is served **from the installed CLI**, so what you load always matches your running version —
+no path-guessing, no frozen-fork drift. (The daemon assembles the same bundle `rig context preview`
+shows an operator — `get` is the agent-facing pull.)
+
+## The index
+
+> Membership rule (`layout.skills[*].edges.length > 0`): every public skill with at least one product edge in the generated edge layout appears exactly once in this index; no other skill appears.
+
+### Always loaded — the universal spine (open its body when its moment hits)
+These are auto-delivered to every rig; their name+description are already in your context. Open the body when the "when" matches.
+
+- **forming-an-openrig-mental-model** — first boot, or you're unsure how the pieces fit. The runtime mental model.
+- **openrig-operating-model** — you do not know where context or work belongs, or you are about to duplicate knowledge. The two-tree placement and trace-to-root model.
+- **openrig-user** — you need a `rig` CLI command (send / queue / ps / whoami / scope / broadcast). The daily CLI surface.
+- **applying-a-permission-policy** — a rig or seat has a permission policy attached, or you're setting one up: translate it into the live harness configuration.
+- **claude-compaction-restore** — you just compacted (Claude). Restore from durable evidence before resuming real work.
+- **delegating-work** — deciding who should do a task: you, a spawned subagent, or a durable peer seat that already holds the context.
+- **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.
+- **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.
+- **mission-slice-sop** — you're working a mission/slice (the SDLC: intent → mini-requirements + proof contract → build → QA → proof). The operating manual.
+- **messaging-the-human** — composing a message to the human. Plain language, no insider jargon.
+- **software-for-agents** — you want the full first-load model of how agent software is built and operated here.
+- **openrig-skills** — this index (you're reading it). Always loaded; the entry point to everything below.
+
+### Load when your role or task calls for it (repo-shipped, profile-selected)
+These ship in the OpenRig repo and reach a seat when its profile selects them. To use one, select it in your profile's `uses.skills`, or open it directly at `packages/daemon/specs/agents/shared/skills/core/<skill>/SKILL.md`.
+
+- **openrig-architect** — authoring a rig or topology (NOT for changing OpenRig itself — that's `openrig-builder`).
+- **openrig-cmux** — driving the `cmux` terminal provider.
+- **openrig-herdr** — opening/managing seat terminals via the default proof-gated provider.
+- **agent-startup-and-context-ingestion** — a seat is booting and ingesting its startup context.
+- **topology-mutation-and-seat-management** — adding, removing, renaming seats or otherwise mutating rig topology.
+- **rig-lifecycle** — rig up / down / pause / resume lifecycle operations.
+- **rig-bundles-and-shareable-artifacts** — packaging or installing a rig bundle / shareable artifact.
+- **cross-host-rig-commands** — reaching seats or queues on another host (`--host`).
+- **openrig-upgrade** — upgrading OpenRig or the daemon.
+- **agent-starters** — composing an agent's starter context / priming packs.
+- **specification-system** — authoring or reading AgentSpecs and rig specs.
+- **human-in-the-loop** — deciding when to involve the human vs. proceed on your own authority.
+- **watchdog** — monitoring or recovering a seat (health, restore, stuck state).
+- **session-source-fork** — forking a session's source/context.
+- **context-engineering** — designing context systems. Provisional and non-normative: current OpenRig skills, explicit rulings, and measured practice outrank it on any conflict.
+
+Pod handbooks (load when you're in that pod):
+- **orchestration-team** — you're orchestrating a rig: dispatching, monitoring, keeping the loop moving.
+- **development-team** — you're on the dev pod: building and shipping product changes.
+- **review-team** — you're reviewing: fresh scrutiny, anti-slop, empirical verification.
+- **oversight-team** — you're in an oversight pod: monitor boundaries and route findings without taking over the work.
+
+Product-management craft (load when shaping/reviewing work):
+- **requirements-writer** — turning intent into clear requirements.
+- **plan-review** — reviewing a plan before it's built.
+- **exec-summary** — writing a decision-ready summary for a human.
+- **office-hours** — running a structured advisory / decision session.
+- **context-builder** — assembling the context a task or seat needs.
+- **backlog-capture** — capturing and shaping backlog items.
+- **ui-mockup** — producing a UI mockup for a slice.
+
+### Vendored craft — load when you're coding (ships with upstream provenance)
+General engineering skills OpenRig ships as vendored copies. Open when the task matches; they carry "modified by OpenRig" provenance.
+
+- **test-driven-development** — implementing a feature or bugfix: write the failing test first.
+- **verification-before-completion** — about to claim done / passing / fixed: run the check and read the output first.
+- **systematic-debugging** — debugging: find the root cause before the fix.
+- **agent-browser** — driving a browser (screenshot / screencast) from an agent.
+- **frontend-design** — designing frontend / UI.
+- **dogfood** — web-QA / dogfooding a shipped UI.
+
+## Need more than what ships here?
+
+This index covers the **shipped** surface. A dev host carries far more (factory, architecture, PM-craft, studio skills) reached through the host's own routers/codemaps — if you're on a builder host and need something not listed above, that deeper routing is the next hop, not a wall. (Host-scale routing is the subject of the context-routing architecture doc; at product scale, this one file is the whole map.)

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

@@ -133,7 +133,7 @@ Observed result:
 - The old daemon was stopped without running `rig down`.
 - The new source-pinned daemon started against the same production DB.
 - `rig ps --nodes --json`, `rig capture`, and `rig restore-check` could inspect the
-  still-running Velocity seats after restart.
+  still-running continuity seats after restart.
 
 The simpler model is now preferred for tmux-backed continuity rigs: snapshot and
 back up state, stop only the daemon, start the new daemon, then verify that live
@@ -235,9 +235,7 @@ are tmux-backed and the operator wants non-disruptive daemon upgrade.
    blockers.
 
 10. **Align the default CLI with the new daemon.**
-    If `rig` is a wrapper, make sure it delegates to the new CLI. On the
-    2026-04-27 host this meant repointing the rigx real CLI via
-    `~/.openrig/bin/rig-real-17812d5`.
+    If `rig` is a wrapper, make sure it delegates to the new CLI.
 
 11. **Write evidence and hand back.**
     The sidecar writes a cutover evidence packet with daemon provenance,
@@ -245,73 +243,27 @@ are tmux-backed and the operator wants non-disruptive daemon upgrade.
     results, caveats, and rollback state. Then it notifies the original in-rig
     lifecycle/runtime-upgrade owner. Do not rely on chat as the only proof.
 
-## 2026-04-27 Proof Point
+## Proof Point: Daemon-Only Hot Cutover
 
-Continuity target:
+A clean source runtime on an LTS Node version replaced the old daemon while one
+tmux-backed continuity rig stayed live. The operator took a post-snapshot online
+database backup, verified its integrity, stopped only the daemon, started the
+new runtime against the same database, and confirmed that every protected seat
+remained running and ready with no red restore blockers.
 
-- `example-seat`
-
-Pinned daemon:
-
-- commit `17812d5d3bfe53dfdc5e202b1da3e8c91e2f4e54`
-- subject `feat(agents): make runtime config spec-driven`
-- committed `2026-04-26T18:30:08-07:00`
-- runtime worktree `~/code/projects/openrig-runtime-17812d5`
-
-Evidence:
-
-- Velocity snapshot `01KQ84D3AF9YW6FQCM9SVSM5EG`
-- post-snapshot DB backup
-  `db-backup/openrig-post-velocity-snapshot-20260427T185003Z.sqlite`
-- backup integrity `ok`
-- old daemon PID `62828`, Node 25 global npm install
-- new daemon PID `39708`, Node 22 source runtime
-- post-cutover `example-seat`: 4/4 seats `running` / `ready`
-- `rig restore-check --rig example-seat`: `RESTORABLE WITH CAVEATS`,
-  `20 green | 9 yellow | 0 red`, `RECOVERY: NOT NEEDED`
-
-Important caveat: this proves hot daemon cutover for tmux-backed Claude seats on
-this host and commit range. It does not prove that arbitrary migrations,
+Important caveat: this proves hot daemon cutover for the tested tmux-backed
+Claude runtime shape. It does not prove that arbitrary migrations,
 non-tmux runtimes, service-backed rigs, or dead sessions can be recovered without
 separate testing.
 
-## 2026-05-02 Proof Point
-
-Continuity targets:
-
-- `kernel`
-- `openrig-discovery`
-- `openrig-dogfood`
-- `openrig-lifecycle`
-- `openrig-maintenance`
-- `openrig-product-lab`
-- `example-rig`
-- `example-seat`
-
-Pinned daemon:
+## Proof Point: Out-of-Band Sidecar Cutover
 
-- commit `6af2754824a07291562622ac019b68615fc41abe`
-- runtime worktree `~/code/projects/openrig-runtime-6af2754`
-- wrapper `~/.openrig/bin/rig-real-6af2754`
-
-Pattern proven:
-
-- lifecycle/runtime-upgrade prepared the decision and preflight artifacts;
-- a host-local tmux sidecar (`host-upgrade-operator-6af2754`) was spawned
-  outside the managed topology with the current operator context;
-- the sidecar stopped only the daemon, using verified PID fallback after
-  `rig daemon stop` refused due to missing daemon state;
-- the sidecar started the target daemon on port `7433`, repointed the
-  config-layer wrapper default, verified protected topology, ran targeted
-  Agent Starter smoke/tests, wrote evidence, and unblocked Dogfood;
-- Velocity delivery continued working throughout the cutover.
-
-Evidence:
-
-- preflight:
-  (internal upgrade-preflight evidence, 2026-05-01)
-- live cutover:
-  (internal live-cutover evidence, 2026-05-02)
+A lifecycle owner prepared the decision and preflight artifacts, then spawned a
+host-local tmux sidecar outside the managed topology. The sidecar stopped only
+the daemon, used a verified graceful PID fallback when daemon state was stale,
+started the pinned runtime, aligned the default wrapper, verified the protected
+topology, ran targeted smoke checks, retained cutover evidence, and handed the
+result back while delivery continued.
 
 Important caveat: live `rig up --plan --json` accepted valid `starter_ref`
 specs and rejected forbidden compositions, but plan-mode output did not emit the
@@ -320,10 +272,6 @@ This is a product/dogfood caveat, not an upgrade failure.
 
 ## Brittle Edges Observed On 2026-04-27
 
-Detailed field note:
-
-(internal upgrade-brittleness field note, 2026-04-27)
-
 Operator lessons from the daemon upgrade:
 
 - `rig down` kills OpenRig-launched tmux sessions. Do not use it as a snapshot
@@ -340,15 +288,11 @@ Operator lessons from the daemon upgrade:
   verify the port is gone before starting the target daemon.
 - CLI and daemon provenance can drift. Repointing or verifying the default
   `rig` wrapper is part of the upgrade, not an afterthought.
-- Raw `rig ps` is too noisy on this host. Use filtered JSON until the product
+- Raw `rig ps` output can be noisy. Use filtered JSON until the product
   has compact first-class inventory views.
 - Snapshot and backup verification is too manual. The SOP currently depends on
   checking snapshot rows, resume tokens, SQLite backups, and integrity by hand.
 
-Separate follow-on note, not part of the daemon-upgrade SOP:
-
-(internal add-node-brittleness field note, 2026-04-27)
-
 ## Disruptive Restore Path
 
 Use disruptive restore when the goal is to test recovery from killed sessions, or
@@ -433,7 +377,7 @@ Needed product surfaces:
   `rig version --json` should report CLI path, daemon path, commit/package
   version, Node version, DB path, and started-at.
 - Wrapper alignment:
-  rigx/default `rig` should clearly show which real CLI it delegates to.
+  the default `rig` wrapper should clearly show which real CLI it delegates to.
 - Compact inventory:
   first-class `rig ps --rig <name> --nodes --compact` or equivalent, so
   operators do not need ad hoc `jq` for routine safety checks.

package/daemon/specs/agents/shared/skills/core/watchdog/SKILL.md

@@ -85,20 +85,14 @@ explicit:
 - **Consumer-pool wake**: if a ready artifact exists, wake the consumer loop head.
 - **Producer-edge repair**: if upstream completion exists but the downstream artifact is missing, wake the producer loop head.
 
-**Scan cadence and wake cadence are separate.** Worked example (from the
-RSI v2 mission, now archived — the numbers are era-specific, the
-scan-vs-wake separation is the durable rule): scan every 30 seconds, wake
-at most every 600 seconds while work remains actionable.
+**Scan cadence and wake cadence are separate.** Worked example (the numbers
+are illustrative; the scan-vs-wake separation is the durable rule): scan every
+30 seconds, wake at most every 600 seconds while work remains actionable.
 
 This is not a generic workflow engine. It's a guardrail against cold
 pools and missing edge artifacts.
 
-## Two surfaces: rigx watchdog (config-layer) and rig watchdog (daemon-shipped)
-
-| Surface | Status | Policies |
-|---|---|---|
-| `rigx watchdog` (config-layer dogfood) | Tmux-backed loops; coexists with daemon | Static periodic-reminder + artifact-pool-ready + edge-artifact-required (per-RSI-loop) |
-| `rig watchdog` (daemon-shipped, v0.2.0 Phase C) | SQLite-backed scheduler; survives daemon restart | `periodic-reminder` / `artifact-pool-ready` / `edge-artifact-required` / `workflow-keepalive` (Phase D — reads workflow_instances directly) |
+## Active surface
 
 Daemon `rig watchdog` is the active host coordination surface for new
 work. History records only loud evaluations (`sent` / `terminal`);

package/daemon/specs/agents/shared/skills/pods/orchestration-team/SKILL.md

@@ -10,7 +10,7 @@ You are part of the orchestration pod. Your job is to keep the team productive,
 ## Startup sequence
 
 Before you summarize the rig or assign real work:
-1. Load `using-superpowers`, `openrig-user`, `orchestration-team`, `systematic-debugging`, and `verification-before-completion`.
+1. Load `openrig-user`, `orchestration-team`, `systematic-debugging`, and `verification-before-completion`.
 2. Run `rig whoami --json` so you know your true identity and observation edges.
 3. Run `rig ps --nodes --json` and wait for the expected starter topology to settle.
 4. Check recent chatroom history or direct startup messages so you know who is actually online and what they already reported.

package/daemon/specs/agents/shared/skills/pods/review-team/SKILL.md

@@ -13,7 +13,7 @@ Review rigor scales to stakes and change size. A small, low-stakes diff gets a f
 ## Startup sequence
 
 Before you announce a review position:
-- load `using-superpowers`, `openrig-user`, `review-team`, `systematic-debugging`, and `verification-before-completion`
+- load `openrig-user`, `review-team`, `systematic-debugging`, and `verification-before-completion`
 - run `rig whoami --json`
 - inspect the current rig state so you know whether you are reviewing a diff, a working tree, verification output, or only startup behavior
 

package/daemon/specs/rigs/launch/kernel/agents/advisor/lead/agent.yaml

@@ -11,7 +11,7 @@ imports:
 profiles:
   default:
     uses:
-      skills: [openrig-architect, brainstorming, requirements-writer]
+      skills: [openrig-architect, requirements-writer]
       guidance: [role]
       subagents: []
       plugins: [shared:openrig-core]

package/daemon/specs/rigs/launch/kernel/agents/advisor/lead/guidance/role.md

@@ -9,9 +9,9 @@ hand off.
 ## You advise; you do not run things
 
 - Bringing rigs up / down / restarting / inspecting health is the
-  operator agent's job. Delegate to `operator.agent@kernel`.
+  operator agent's job. Delegate to `operator.agent`.
 - Classifying stream items into queue work is the queue worker's job.
-  Delegate to `queue.worker@kernel`.
+  Delegate to `queue.worker`.
 - Implementation work happens in project rigs that the operator
   spins up — you propose those, you do not host them.
 
@@ -19,9 +19,8 @@ hand off.
 
 - Start by listening. The user often arrives mid-thought; ask one
   clarifying question, not five.
-- Use the brainstorming skill on novel asks; use requirements-writer
-  to crisp up ambiguous intent into something an implementer rig can
-  pick up.
+- Use requirements-writer to crisp up ambiguous intent into something an
+  implementer rig can pick up.
 - When the user wants to look at their work, route them at the
   Mission Control / For You / project surfaces in the UI; you don't
   need to recite content the UI already shows.

package/daemon/specs/rigs/launch/kernel/agents/advisor/lead/startup/context.md

@@ -7,13 +7,13 @@ this through their terminal or through the Mission Control UI.
 
 Introduce yourself in one short paragraph. Tell the user:
 
-1. Who you are (`advisor.lead@kernel`) and what you can do for them
+1. Who you are (`advisor.lead`) and what you can do for them
    today (pilot intent → route to operator or queue worker, propose
    topology, capture requirements).
-2. That the operator agent is available at `operator.agent@kernel`
+2. That the operator agent is available at `operator.agent`
    for "bring my rigs back online" / install / topology mutation
    work.
-3. That the queue worker is available at `queue.worker@kernel` for
+3. That the queue worker is available at `queue.worker` for
    classification of stream items.
 
 Don't list every skill; the user can ask if they're curious.

package/daemon/specs/rigs/launch/kernel/agents/operator/agent/guidance/role.md

@@ -1,7 +1,7 @@
 # Operator Agent — Role
 
 You run OpenRig on behalf of the user. You are paired in the operator
-pod with `operator.human@kernel`, who IS the user; you collaborate
+pod with `operator.human`, who IS the user; you collaborate
 with them and escalate to them when ops decisions need human approval.
 
 ## What you do
@@ -28,7 +28,7 @@ with them and escalate to them when ops decisions need human approval.
   that you spin up on the user's behalf, not in the kernel.
 - Decisions with significant blast radius (destroying state,
   force-killing sessions with in-flight work) without human
-  approval. Escalate to `operator.human@kernel`.
+  approval. Escalate to `operator.human`.
 
 ## Failure modes to watch
 
@@ -42,6 +42,6 @@ with them and escalate to them when ops decisions need human approval.
 
 ## When you are uncertain
 
-Ask `operator.human@kernel` via `rig send` or via a qitem. The user
+Ask `operator.human` via `rig send` or via a qitem. The user
 has context you don't (recent reboots, mid-flight migrations, plans
 to scrap a particular rig).

package/daemon/specs/rigs/launch/kernel/agents/queue/worker/guidance/role.md

@@ -16,7 +16,7 @@ fleet can pick them up.
   the tag set (`<release> / <slice> / <surface>` shape).
 - Promote via `rig queue create --source <stream-item> --destination
   <seat> --body <text> --priority <p> --tier <t> --tags <csv>`.
-- When ambiguity is real, escalate to `advisor.lead@kernel` — don't
+- When ambiguity is real, escalate to `advisor.lead` — don't
   guess destinations.
 
 ## What you do NOT do

package/daemon/specs/rigs/launch/kernel/agents/queue/worker/startup/context.md

@@ -22,7 +22,7 @@ stream-item-arrived events, not on a poll loop.
 
 ## Coordination
 
-- New ambiguous stream items → escalate to `advisor.lead@kernel`.
+- New ambiguous stream items → escalate to `advisor.lead`.
 - Routing decisions where the destination clearly fits a documented
   pattern → execute and emit the qitem.
 - All qitem closures + handoffs follow the closure-reason discipline

package/daemon/substance-surfaces.json

@@ -0,0 +1,8 @@
+{
+  "schemaVersion": 1,
+  "roots": [
+    "daemon/assets",
+    "daemon/context-packs",
+    "daemon/specs"
+  ]
+}

package/dist/build-info.js

@@ -1,9 +1,9 @@
 // GENERATED by scripts/build-package.sh — the packaged build-identity stamp.
 export const BUILD_INFO = {
-  semver: "0.5.5",
-  commit: "42700c4be7473491fa5d11311873a94f1d330ce2",
+  semver: "0.5.7",
+  commit: "bda1bba537366cc33a8850812ec16ce001973e80",
   dirty: false,
-  builtAt: "2026-08-27T19:40:18Z",
+  builtAt: "2026-09-01T05:16:57Z",
 };
 export function stampFields(info = BUILD_INFO) {
   if (!info.commit) return {};

package/dist/commands/broadcast.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"broadcast.d.ts","sourceRoot":"","sources":["../../src/commands/broadcast.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAKpC,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,aAAa,CAAC;AAC9C,OAAO,EAAE,gBAAgB,EAAkC,MAAM,qBAAqB,CAAC;AAcvF,MAAM,WAAW,aAAc,SAAQ,UAAU;IAC/C,4EAA4E;IAC5E,kBAAkB,CAAC,EAAE,MAAM,UAAU,CAAC,OAAO,gBAAgB,CAAC,CAAC;CAChE;AAED,wBAAgB,gBAAgB,CAAC,YAAY,CAAC,EAAE,aAAa,GAAG,OAAO,CA8HtE"}
+{"version":3,"file":"broadcast.d.ts","sourceRoot":"","sources":["../../src/commands/broadcast.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAKpC,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,aAAa,CAAC;AAC9C,OAAO,EAAE,gBAAgB,EAAkC,MAAM,qBAAqB,CAAC;AAevF,MAAM,WAAW,aAAc,SAAQ,UAAU;IAC/C,4EAA4E;IAC5E,kBAAkB,CAAC,EAAE,MAAM,UAAU,CAAC,OAAO,gBAAgB,CAAC,CAAC;CAChE;AAED,wBAAgB,gBAAgB,CAAC,YAAY,CAAC,EAAE,aAAa,GAAG,OAAO,CAgItE"}

package/dist/commands/broadcast.js

@@ -8,6 +8,7 @@ import { emitCrossHostError, emitRemoteHttpFailure } from "../cross-host-cli-hel
 import { runRemoteHttpOp } from "../remote-host-ops.js";
 import { resolveContextRef, walkSizedWarning } from "../context-resolve.js";
 import { resolveSenderSession, SENDER_FALLBACK } from "../sender-identity.js";
+import { refuseEmptyMessage } from "./send.js";
 /**
  * OPR.0.4.6.MH4 C3 — the cross-host broadcast deadline, named at the call
  * site (arch delivery-lane note (a)): the remote route responds only after
@@ -61,11 +62,13 @@ selection, not the agent@rig@host sugar.`)
             process.exitCode = 1;
             return;
         }
-        if ((text === undefined || text.length === 0) && !opts.context) {
+        if (text === undefined && !opts.context) {
             console.error("Provide a message to broadcast (or --context <ref>).");
             process.exitCode = 1;
             return;
         }
+        if (!opts.context && refuseEmptyMessage(text, "broadcast", Boolean(opts.json)))
+            return;
         // P18 DELIVER-AND-LABEL — the seat boundary no longer refuses. Resolve the broadcasting seat from the
         // seat env; when it is unresolvable the broadcast STILL proceeds carrying the honest `<unknown sender>`
         // marker (so the anti-storm scale header is always present — no session-less storm), delivered-and-
@@ -104,6 +107,8 @@ selection, not the agent@rig@host sugar.`)
             if (warn && !opts.json)
                 console.log(`Advisory: ${warn}`);
         }
+        if (refuseEmptyMessage(payload, "broadcast", Boolean(opts.json)))
+            return;
         const body = { text: payload, force: opts.force };
         if (opts.rig)
             body.rig = opts.rig;