@openrig/cli 0.5.10 → 0.5.12

package/daemon/context-packs/skills/claude-compaction-restore/SKILL.md

@@ -3,7 +3,6 @@ name: claude-compaction-restore
 description: Use when a Claude Code session has just compacted, is about to compact, reached context limit, resumed after /compact, or needs to rebuild its working mental model from Claude JSONL transcripts and touched files.
 metadata:
   openrig:
-    stage: factory-approved
     sibling_skills:
       - mental-model-ha
       - scope-recovery
@@ -20,8 +19,9 @@ metadata:
 # Claude Compaction Restore
 
 Use this skill to preserve continuity before Claude Code compacts and to
-restore continuity after compaction. Do the work described here; do not merely
-explain the protocol.
+restore continuity after compaction. Follow the active restore request or
+configured continuity policy. A hook notice identifies available evidence; it
+does not by itself request a seat restoration.
 
 ## If You Are About To Compact
 
@@ -55,68 +55,60 @@ Prepare durable continuity before the context boundary.
 
 ## If You Just Compacted
 
-Treat your memory as unreliable until you restore from durable evidence.
-Restoration is your current task. Do not wait for a future user request or a
-new task assignment before reading the required files.
-
-1. Read any restore prompt, marker path, packet path, transcript path, restore
-   map, or extra instruction file named by the operator or OpenRig.
-2. Run the restore script from this skill:
-
-```bash
-node ~/.claude/skills/claude-compaction-restore/scripts/restore-from-jsonl.mjs --out /tmp/claude-compaction-restore
-```
-
-If the prompt names a specific Claude JSONL transcript, pass it explicitly:
+Restore from the evidence for this session before relying on remembered task state.
+
+1. Inspect the restore request and any named marker, packet, transcript, restore
+   map, or extra instruction file. Check recorded seat/session/transcript identity
+   against the current request, and verify that the referenced packet is readable.
+   A marker path alone does not prove a usable packet; do not substitute another
+   seat's packet or select one only because it is the newest.
+2. **Use the existing packet when usable.** Read its `restore-instructions.md`,
+   `touched-files.md`, and any named restore map. A packet already prepared for this
+   session does not need rebuilding merely because compaction occurred.
+3. **Fall back when the packet is absent or unusable.** Record what is missing or
+   mismatched. Resolve this skill's installed directory and run its
+   `scripts/restore-from-jsonl.mjs` with the matching Claude JSONL transcript and a
+   separate output directory. For a skill installed in the global Claude skill root:
 
 ```bash
 node ~/.claude/skills/claude-compaction-restore/scripts/restore-from-jsonl.mjs /path/to/session.jsonl --out /tmp/claude-compaction-restore
 ```
 
-3. Read the generated `restore-instructions.md`.
-4. Read the generated `touched-files.md`.
-5. Find and read the mental-model restore map if one exists. Treat it as the
-   highest-value guide to which memory files, mission files, source files, and
-   docs mattered before compaction.
-6. Identify the important files for the active task. The touched-file list is
-   a triage aid, not a complete inventory.
-7. Read every important file in full. Prioritize the restore map, Claude memory
-   files named in the map, Markdown state/planning files, queue/mission packets,
-   source files with active edits, root instruction files, and as-built or
-   codemap docs.
-8. After the required reads are complete, state:
+   If no transcript was named, identify the current session's transcript first.
+   The script can discover a transcript from a working directory, but inspect that
+   selection before relying on it. If the session cannot be identified, report
+   the missing input instead of reconstructing from an unrelated conversation.
+   Read the resulting `restore-instructions.md` and `touched-files.md`.
+4. Inspect the actual packet and transcript sizes before choosing how much to read.
+   The generated instructions report estimated token cost. State a read budget
+   and stopping rule that leave room for the task. For a large transcript, begin
+   with the most recent task-relevant unique narrative; read earlier material when
+   a specific missing decision or dependency requires it. Report ranges actually
+   read rather than treating a chosen budget as completed coverage.
+5. Use the restore map and touched-file list to identify current task files.
+   The list is a triage aid, not an exhaustive inventory. Prioritize the active
+   queue/mission packet, decisions and memory named in the map, files with active
+   edits, root instructions, and relevant as-built docs or codemaps. Read required
+   task files in full within the stated budget; record any remaining gaps.
+6. Re-establish the task's purpose and operating context from the current project,
+   mission and seat files. A transcript summary alone does not establish current
+   scope or obligations. Use the shipped `refocusing` skill for the path-only
+   topology/work trace when operating inside OpenRig.
+7. Report the read-depth audit below. Once the required context is restored, use
+   the packet's requested acknowledgment, normally:
 
 ```text
 restored from packet at <path>; resumed at step <X>
 ```
 
-Include the main files you read in full when you make that statement.
-
-9. **REFOCUS BEFORE YOU RESUME — the restore returns your TASK, not your BEARINGS.** Everything
-   above rebuilds *what you were doing*. None of it rebuilds *what the work is for* or *how this
-   rig operates* — those live in the chains, and nothing in steps 1–8 walks them. Invoke the
-   `refocus` skill and do its reads before your next substantive move.
-
-   **Measured 2026-08-13, and this step exists because of it:** a seat completed this protocol
-   faithfully — packet built, narrative read tail-first, read-depth audit reported honestly — and
-   resumed with a perfect picture of its atom and *zero* work-tree context. It had never opened
-   the mission or project nodes, and could only paraphrase the release's intent second-hand from
-   a peer's message. It then produced a technically-correct trace concluding *"I hold nothing"*
-   while holding 18 pending rows. **A restore that returns you to your task without your bearings
-   is how a confidently-wrong agent gets back to work.**
-
-**On the marker and the packet's size (measured across restores, 2026-08):** two realities the restore
-must handle honestly —
-
-- **The per-seat marker (`restore-pending/<session>.json`) is frequently absent** — in five observed
-  restores it was never present. Treat the JSONL rebuild via `restore-from-jsonl.mjs` as the **primary**
-  path, not a fallback: run it regardless of whether a marker exists. (When product-infra reliably writes
-  the marker for tmux-launched seats, it becomes a fast-path upgrade — not a prerequisite that keeps failing.)
-- **The generated transcript can be very large** (measured at ~346k tokens in one restore). Do **not**
-  read it front-to-back or claim to. `restore-instructions.md` declares its token cost up front; default
-  to the **most recent ~50k tokens of unique narrative first** (recency is what a restore needs — the
-  thread that produced the current frontier, not the boot handshake), and go earlier only if a specific
-  question requires it. A restore must leave room for the work it was restored to do.
+   Include the main files actually read in full. If essential context remains
+   missing, report partial restoration and the next recovery action instead of
+   claiming completion.
+
+The packaged PreCompact writer can prepare a packet and a per-seat pending marker;
+the restore bridge can deliver its pointer once for a matching session. Inspect
+those actual artifacts. Their creation or delivery is not proof that a provider
+restored its context, that the files were read, or that task understanding returned.
 
 ## Required Read-Depth Audit
 
@@ -125,8 +117,8 @@ After the first restore pass, audit yourself before continuing.
 1. List every file, packet, marker, restore map, instruction file, and source
    document you were asked to read during restore.
 2. Mark each item as `FULL`, `PARTIAL`, or `NOT_READ`.
-3. You will be given a task where all of these files are required reading in
-   order to understand the task.
+3. Distinguish essential current-task context from supplementary history, using
+   the actual restore request and active task.
 4. Read `PARTIAL`/`NOT_READ` items in full — but **to a declared budget with a stopping rule**, not
    unbounded. Prioritize by relevance to the active task; for a large transcript read the most recent
    unique narrative first (see *If You Just Compacted*), not front-to-back.
@@ -156,8 +148,8 @@ After the first restore pass, audit yourself before continuing.
 
 1. **Confidently-wrong restoration**: claiming restoration after reading only
    the touched-file list or summary.
-2. **Partial restore**: reading the first few files, then continuing before the
-   full reading list is complete.
+2. **Unreported partial restore**: continuing without essential task context or
+   claiming full coverage after a budget-limited read.
 3. **Skipping project instructions**: missing `AGENTS.md`, `CLAUDE.md`,
    `README.md`, as-built docs, or codemaps that govern the task.
 4. **Treating the packet as exhaustive**: ignoring mission or workspace files

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

@@ -1,7 +1,7 @@
 # GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
 # Package-time projection of a canonical skill; regenerated every build.
 name: "claude-compaction-restore"
-version: "0.5.10"
+version: "0.5.12"
 taxonomy: "skills"
 purpose: "Use when a Claude Code session has just compacted, is about to compact, reached context limit, resumed after /compact, or needs to rebuild its working mental model from Claude JSONL transcripts and touched files."
 files:

package/daemon/context-packs/skills/core/agent-starters/SKILL.md

@@ -23,9 +23,9 @@ A named, reusable per-seat starting point. Composes an agent role, startup
 context, optional native session source, and provenance into something a
 user or rig can choose when creating, refreshing, or packaging a seat.
 
-"Agent image" is the analogy. **Agent Starter is the cleaner product
-noun.** This is NOT a VM image — it is a managed starting point for an
-agent seat, with provenance you can inspect.
+This registry-backed startup context is distinct from the `rig agent-image`
+surface and from a VM image. See the current behavior below before treating
+optional session provenance as an executable native session source.
 
 ## Use this when
 
@@ -49,7 +49,7 @@ Capture the seat as it naturally is at a functional, proven point. Don't pad it
 
 Never compact, summarize, or shrink a seat in order to make or "lean" a starter. There is nothing valuable in "smaller," and compaction is lossy — you would trade away the exact capability the starter exists to preserve. (Compaction is a separate last-resort step for a seat genuinely near its context limit, with its own before/after plan — never part of capturing a starter.)
 
-## State model — 6 states
+## Authoring lifecycle — 6 conceptual states
 
 1. **Captured** — a useful seat/session/context pattern is identified.
 2. **Named** — it becomes an Agent Starter with stable id and owner.
@@ -66,30 +66,32 @@ Never compact, summarize, or shrink a seat in order to make or "lean" a starter.
 4. **Secret leakage** — starter packages or displays provider auth material. **Refuse.** Refer to session sources and context, never copy credentials.
 5. **Runtime mismatch** — starter used with unsupported runtime. **Refuse with a clear error.**
 
-## Manifest shape (v0+v1 shipped)
+## Registry entry and current behavior
+
+Save one entry as `<registry-root>/reviewer-v1.yaml`. The resolver selects an
+explicit root or `OPENRIG_AGENT_STARTER_ROOT`; absent those, it checks the home
+registry `~/.openrig/agent-starters` and a configured fallback.
 
 ```yaml
-agent_starters:
-  - id: velocity-reviewer-v1
-    runtime: claude-code
-    agent_ref: local:reviewer
-    context_refs:
-      - doctrine:advisor-orchestrator-mode-judgment
-      - convention:workstream-continuity
-    session_source:
-      mode: fork
-      ref:
-        kind: native_id
-        value: "<prior-native-session-id>"
+starter_id: reviewer-v1
+role: Review the assigned change against its stated outcome.
+context: Read the current task and the source needed to judge it.
 ```
 
+The current resolver checks the entry shape and credential boundary, then
+delivers this YAML itself as one required `guidance_merge` startup file on a
+fresh start. It does not interpret arbitrary context refs, load a native
+conversation from this example, or seal an image. A RigSpec member combining
+`starter_ref` with `session_source.mode: fork` is currently rejected; use a
+separate supported session-source path when native continuity is the outcome.
+
 Member usage:
 
 ```yaml
 members:
   - id: reviewer
     starter_ref:
-      name: velocity-reviewer-v1
+      name: reviewer-v1
 ```
 
 When a starter points at a primed session produced from a Composable
@@ -113,7 +115,7 @@ Priming Pack, record:
 
 ## Dependencies on other primitives
 
-- **Firm**: `session-source-fork` — native conversation-source continuity for fork-based starters
+- **Separate path**: `session-source-fork` — native conversation-source continuity; currently not composable with `starter_ref`
 - **Firm**: `specification-system` — declarative starter and member references
 - **Soft**: `rig-bundles-and-shareable-artifacts` — shareable starter packaging
 - **Soft**: `context-engineering-and-retrieval` — richer declarative context assembly

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

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

package/daemon/context-packs/skills/core/agent-startup-and-context-ingestion/SKILL.md

@@ -24,8 +24,7 @@ metadata:
 
 How an agent becomes useful after launch: **AGENTS.md overlays, role
 files, skills, rig specs, workflow specs, startup checklists, refocus
-messages**, and any future "rig context" command or skill-librarian
-surface.
+messages**, and the current `rig context` retrieval and profile surface.
 
 It is the current concrete startup path inside the broader
 context-engineering-and-retrieval primitive. Startup gets a seat into
@@ -91,14 +90,16 @@ reentry case, distinct from reusable Agent Starters / priming packs):
 
 ## Memory surfaces consumed at startup
 
-Per the externalized-memory-surfaces convention's 13-row inventory:
+Inventory the selected startup inputs: AGENTS/role/CULTURE overlays, replay
+context, and any declared restore packet or starter. Record where each comes
+from, whether it is current, and why this task needs it. An available skill or
+old packet does not select the work.
 
-- **Row 7** — AGENTS/role/CULTURE/startup overlays (primary)
-- **Row 3** — startup replay context (primary)
-- **Row 12** — restore/reentry packets and Agent Starters (cross-runtime startup path)
-
-The umbrella's authority-rank + permission-posture columns govern which
-surfaces a startup ingestion path can write vs only read.
+Use the task-scoped startup path above to resolve current authority. Permission
+to read an input is not permission to rewrite its source; writes follow the
+active project/rig policy and assignment. Load
+`skills/openrig-operating-model/SKILL.md` with `rig context get` when deciding
+where durable context belongs.
 
 ## Startup files vs skills (the distinction)
 
@@ -123,5 +124,5 @@ culture / pod / member / operator) handles the layering.
 - `session-compaction-and-restore` skill — restore-time startup ingestion
 - `agent-starters` skill — reusable starter manifests that compose startup context
 - `composable-priming-packs` skill — manifests that produce primed sessions
-- `externalized-memory-surfaces` skill — umbrella convention for memory surfaces this primitive consumes
+- `openrig-operating-model` skill — placement and authority of durable context
 - `openrig/docs/reference/agent-startup-guide.md` (product reference doc; not a skill) — the 7-layer additive startup model + delivery hints

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

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

package/daemon/context-packs/skills/core/cross-host-rig-commands/SKILL.md

@@ -1,12 +1,13 @@
 ---
 name: cross-host-rig-commands
-description: Use when issuing `rig` commands against a remote host via `--host <id>` flag (single-hop SSH to a host declared in `~/.openrig/hosts.yaml`). Covers the 4 structured failure modes (ssh-unreachable / permission-gate / remote-daemon-unreachable / remote-command-failed), the `--verify` honest pass-through (SSH success is NOT verify success), and the host-registry shape. v0 supports `rig send / capture / ps / whoami --host <id>`.
+description: Use when addressing a registered remote OpenRig host, choosing its transport, or interpreting a cross-host result.
 metadata:
   cli_surfaces_referenced:
     - capture
     - daemon start
     - host list
-    - host show
+    - host add
+    - host doctor
     - ps
     - send
     - whoami
@@ -22,167 +23,102 @@ metadata:
       - extension-and-user-workspace
 ---
 
-# Cross-Host Rig Commands
+# Cross-host rig commands
 
-A first-class OpenRig surface for issuing `rig` commands against a
-remote host via single-hop SSH. v0 productizes the existing SSH-envelope
-operator pattern (`ssh <host> rig <cmd>`) with declared host identity,
-explicit cross-host invocation path, preserved `--verify` semantics, and
-4 named failure modes.
+Use a registered host address and the entry's declared transport. SSH entries
+run a remote CLI through a single-hop shell; HTTP entries use the remote daemon.
+These paths have different prerequisites and command coverage. Check the exact
+command's help and the target installation before a consequential operation.
 
-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`.
+## Choose and inspect the destination
 
-**v0 is CLI-side shell-out only — `packages/daemon/` is NOT touched.**
-The remote host has its own managed `rig` available on `$PATH`.
-
-## Use this when
-
-- Driving a Tart VM from the host (the immediate cross-host consumer)
-- Operating Mac host A against Mac host B
-- Reading remote state via `rig ps --host` / `rig whoami --host`
-- Sending or capturing on a remote rig session (`rig send/capture --host <id>`)
-- Authoring a `~/.openrig/hosts.yaml` registry entry
-
-## Don't use this when
-
-- The target is local. Don't pass `--host` for local commands.
-- You need multi-hop SSH (host A → host B → host C). v0 is single-hop only.
-- You want reverse direction (remote initiates back to local). v0 is originator-pull only.
-- Cross-host **seat handover** (moving a durable owned seat across hosts) — deferred to higher-level primitives. (Cross-host **queue writes**, by contrast, now ship — see "Cross-host queue writes" below.)
-- The transport isn't SSH. v0 supports `transport: ssh` only.
-
-## Cross-host queue writes (updated 2026-07-21 vs main d37a08ad)
-
-Cross-host **queue writes** are no longer deferred — they ship — but the rule
-differs from the interactive verbs (`send`/`capture`/`ps`/`whoami`):
-
-- **Queue writes are EXPLICIT-only.** Address the target host explicitly with
-  `--host <id>` or the `member@rig@<host>` form. A queue write **never** follows a
-  persisted host selection.
-- **`host select` stickiness does NOT apply to queue.** `host select` affects the
-  `resolveEffectiveHost` verbs (`send`/`capture`/`ps`/`whoami`) — those follow the
-  selected host — but a queue write ignores it and requires explicit addressing.
-- **Host address parsing differs** between the interactive verbs and the queue
-  verbs; do not assume the interactive form carries over. When unsure, address the
-  host explicitly.
-
-## Host registry shape (`~/.openrig/hosts.yaml`)
-
-Host ids must be non-empty and unique. Choose stable, operator-meaningful ids
-that describe the destination without depending on transient network details.
+`rig host list` shows registered hosts. `rig host add --help` describes registry
+writes; `rig host doctor --help` describes reachability checks. Inspect the
+configured OpenRig home rather than assuming the default `~/.openrig/hosts.yaml`.
+Registry changes affect later routing, so make them within the requested scope.
 
 ```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: example-user                   # optional
-    notes: "Tart VM"                     # optional
-  - id: laptop-b
+  - id: test-vm
     transport: ssh
-    target: laptop-b.tail-scale-net
+    target: test-vm.local
     user: example-user
+  - id: remote-dev
+    transport: http
+    url: http://remote-dev.example:7433
+    bearer_env: REMOTE_RIG_TOKEN
 ```
 
-Validation rules:
+The registry requires a hosts array, unique non-empty ids and a supported
+transport. SSH needs a non-empty target; user and notes are optional. HTTP needs
+a URL and accepts at most one of bearer_env or bearer_file. Omitting both is
+valid for a tokenless target. A configured but unavailable bearer is a permission
+failure, not anonymous fallback. Host ids also have reserved-name validation;
+use the actual validator's error rather than inventing an alias that collides.
 
-- `hosts` required, non-null array
-- Each entry: `id` required (non-empty, unique), `transport` required (`ssh` only), `target` required
-- `user` and `notes` optional
-- Operator-managed file; v0 does NOT include any sub-command to add/remove/list hosts (operators edit YAML directly)
-- Missing or invalid file returns a clear error pointing at the canonical path
-
-## CLI surface (v0 shipped)
+## Address the intended operation
 
 ```bash
-rig send <session> "msg" --host <id> --verify
-rig capture <session> --host <id>
-rig ps --host <id> [--nodes] [...]
-rig whoami --host <id>
+rig send dev-worker@example-rig "check the assigned result" --host remote-dev --verify
+rig capture dev-worker@example-rig --host remote-dev
+rig ps --host remote-dev --nodes --json
+rig whoami --host remote-dev
 ```
 
-Forwards every shaping flag (`--nodes`, `--full`, `--limit`, `--fields`,
-`--summary`, `--filter`, `--json`) to the remote `rig` invocation. The
-remote rig's output is verbatim passthrough on success.
-
-## The 4 structured failure modes (load-bearing API contract)
-
-The CLI distinguishes 4 failure modes; operators get an actionable error
-per mode; JSON output preserves the `failedStep` enum:
-
-| Mode | Cause | Action |
-|---|---|---|
-| `ssh-unreachable` | SSH itself failed (connection refused, host key mismatch, DNS failure, timeout) | Verify SSH access and the registry entry |
-| `permission-gate` | SSH hit auth/permission gate (Permission denied, Keychain) | Error includes hint to keychain-over-SSH field note (L4-3 D6) |
-| `remote-daemon-unreachable` | SSH succeeded but remote `rig` reported the remote daemon was not reachable | `ssh <target> rig daemon start` |
-| `remote-command-failed` | SSH succeeded but remote `rig` exited non-zero for some other reason; remote stderr is surfaced | Read remote stderr; debug remote command |
-
-Each is distinct and routable. Don't conflate them.
-
-## `--verify` honest pass-through (load-bearing)
-
-`--verify` against a remote target must:
-
-- **Propagate** the verification request to the remote daemon (or remote `rig` invocation that talks to it)
-- **Bring back a structured verification result** (true/false + reason if false), NOT just SSH exit code 0
-- **Distinguish "SSH succeeded but verify returned false" from "SSH itself failed"** — these are different operator actions
-
-**SSH success is NOT verify success.** The remote rig is authoritative
-on `--verify`; its `Verified: yes/no` line is surfaced verbatim. Verified
-at 3 layers (executor unit, command integration, source impl).
-
-## Hard boundaries (do-not list)
-
-- **Do NOT collapse `--verify` honest result into SSH exit code.** Operators and agents rely on the distinction.
-- **Do NOT silently retry SSH failures inside the primitive.** Surface them; let the caller decide.
-- **Do NOT introduce non-SSH transports in v0.** Goal is productizing the existing shipped pattern, not replacing it.
-- **Do NOT touch host-side daemon code as part of v0.** Cross-host shape is on the originator side.
-
-## Cross-host annotation
-
-Every cross-host invocation is observable as cross-host:
-
-- **Operator output**: `[via host=<id> (<target>)]` annotation
-- **JSON output**: `cross_host: { host, target }` field
-
-Annotation is PRESENT when `--host` is set and ABSENT otherwise
-(compat regression).
-
-## Currently shipped (v0) vs deferred
-
-Shipped at openrig `cdce3a6` (2026-04-30):
-- `--host <id>` flag on `rig send / capture / ps / whoami` (initial 2 commands; promoted to 4 at `6b7043a` same day)
-- Read-only host registry validation
-- Single-hop SSH executor with 4-mode `failedStep` enum
-- `--verify` honest pass-through
-- Cross-host annotation (operator + JSON)
-- Daemon untouched
-
-Deferred:
-- Tier 2 real-runtime cross-host proof (disposable Tart VM cycle)
-- `rig host list / show` read-only sub-namespace (only if host count grows past comfortable manual editing)
-- Non-SSH transports
-- Multi-hop SSH
-- Reverse direction (remote initiates)
-- Connection pooling/caching
+These coordination commands select SSH or HTTP from the registry entry. They
+do not silently try another transport when one fails. A host-qualified target
+can be convenient, but confirm its parsing and any persisted host selection
+with the particular command. Explicit --host is preferable for consequential
+cross-host work.
+
+Queue destinations use explicit --host or a supported host-qualified destination;
+queue writes do not follow persisted host selection. The CLI separates the host
+from the canonical seat in the routing envelope. Different queue subcommands
+have different flags: check their help instead of copying a flag from send.
+A local success message alone does not establish remote persistence or pickup.
+
+## Read failures at the layer that failed
+
+| Signal | What to inspect |
+|---|---|
+| registry-load-failed / unknown-host | Registry path, entry and exact destination |
+| ssh-unreachable | SSH connection, target and transport diagnostics |
+| permission-gate | The configured SSH or HTTP credentials and target policy |
+| remote-daemon-unreachable | Target listener and actual running daemon identity |
+| remote-command-not-found | Remote CLI installation and executable lookup |
+| remote-command-failed | The remote operation's own status and error |
+
+The exact result taxonomy depends on the path. HTTP failures expose the remote
+status/error; SSH distinguishes the shell transport from the remote command.
+Do not start or replace a remote daemon merely because a diagnostic suggests it;
+first establish the target's state and the authority for that lifecycle action.
+A timed-out write may have reached its destination. Reconcile its durable effect
+before retrying.
+
+## Verification and attribution
+
+Transport success is not delivery verification or agent consumption. SSH forwards
+--verify and returns the remote CLI result. HTTP preserves the remote transport
+verdict and explicitly reports that the local pane-effect check did not run
+cross-host. Inspect that result and the destination effect required by the task;
+never replace it with “SSH exited zero” or “HTTP returned successfully.”
+
+Cross-host output names the host/target; JSON envelopes carry cross_host metadata.
+The precise envelope differs by command and transport. Preserve the underlying
+remote result when passing evidence onward.
+
+A target's host suffix selects a destination; a sender's origin identifies where
+a reply belongs. Use the rendered reply address and verify its host mapping.
+Current send derives the sender from the executing seat context, not a caller's
+--from assertion. It adds origin-host identity at cross-host forwarding; do not
+assume local sends have the same suffix. Unknown identity remains unknown.
+
+This guide describes the implemented command paths, not proof of a live remote
+journey on your installation. Forks, handovers and other lifecycle compositions
+need their own supported command and scoped authority; reading remote state
+does not authorize them.
 
 ## See also
 
-- `seat-continuity-and-handover` skill — host-aware seat-binding semantics for cross-host handover (deferred to v1 on top of this v0 baseline)
-- `openrig-user` skill — the local CLI surface that cross-host commands wrap
-
-## Sender identity carries the ORIGIN host (51-09, 2026-08-06)
-
-The `@host` sugar on a TARGET is **addressing** (`member@rig@<host>` routes to that host).
-The **From:** sender now ALWAYS carries the **origin** host: a cross-host (and local) message's
-signature is **`member@rig@<originHost>`** — the sender reflects the host it was sent from, so a
-received signature names the ORIGIN, and the `↩ Reply:` hint round-trips **verbatim** back to that
-origin (never a same-named local lookalike). This is the always-suffix rule — deterministic and
-collision-proof: a signature means one thing to every receiver. (This SUPERSEDES the pre-51-09
-asymmetry — "the sender carries no `@host` suffix" — that pm@your-rig flagged as a core gap on
-2026-07-25; 51-09 closed it.) Per BR-1 the host is NEVER folded into the session string on the
-wire: the CLI edge renders/strips it, the daemon refuses an in-band 3-part destination with a
-teaching hint, and a stale 2-part same-name destination is closed by `--host` + that teaching —
-not by any in-string magic.
+- openrig-user — exact command reference
+- seat-continuity-and-handover — stable seat and occupant outcomes

package/daemon/context-packs/skills/core/cross-host-rig-commands/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: "cross-host-rig-commands"
-version: "0.5.10"
+version: "0.5.12"
 taxonomy: "skills"
-purpose: "Use when issuing `rig` commands against a remote host via `--host <id>` flag (single-hop SSH to a host declared in `~/.openrig/hosts.yaml`). Covers the 4 structured failure modes (ssh-unreachable / permission-gate / remote-daemon-unreachable / remote-command-failed), the `--verify` honest pass-through (SSH success is NOT verify success), and the host-registry shape. v0 supports `rig send / capture / ps / whoami --host <id>`."
+purpose: "Use when addressing a registered remote OpenRig host, choosing its transport, or interpreting a cross-host result."
 files:
   - path: "SKILL.md"
     role: "instruction"
-    summary: "Use when issuing `rig` commands against a remote host via `--host <id>` flag (single-hop SSH to a host declared in `~/.openrig/hosts.yaml`). Covers the 4 structured failure modes (ssh-unreachable / permission-gate / remote-daemon-unreachable / remote-command-failed), the `--verify` honest pass-through (SSH success is NOT verify success), and the host-registry shape. v0 supports `rig send / capture / ps / whoami --host <id>`."
+    summary: "Use when addressing a registered remote OpenRig host, choosing its transport, or interpreting a cross-host result."

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

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

package/daemon/context-packs/skills/core/messaging-the-human/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.5.10"
+version: "0.5.12"
 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: