@openrig/cli 0.4.4 → 0.4.7

package/daemon/docs/reference/product-factory-vps-runbook.md

@@ -1,132 +0,0 @@
-# Product-Factory VPS Runbook (product-factory-vps)
-
-OPR.0.4.4.13 — the productized form of the 2026-06-23 OVH smoke test: a fresh
-Ubuntu VPS becomes an OpenRig product factory managed from a home base, with
-the proven security posture as the encoded default. The bootstrap is a
-SCRIPT + THIS RUNBOOK by design — host verbs are capped at `add`/`list`/
-`doctor`, and the acceptance anchor is the observable end state: home-base
-`rig host doctor <id>` all green.
-
-## 1. Prerequisites
-
-- A fresh Ubuntu 22.04/24.04 VPS (any provider; the lived reference was OVH).
-- A Tailscale tailnet you administer; the home base already on it.
-- A home-base SSH keypair for the factory (`ssh-keygen -t ed25519 -f ~/.ssh/openrig-factory`).
-- The published OpenRig artifact (`@openrig/cli@<version>`) or the packaged
-  tarball a release branch builds (`npm pack` output) for pre-release proof.
-- Dedicated Claude/Codex accounts for THIS factory. Never copy home-base
-  credentials (`~/.claude`, `~/.codex`, `~/.openrig`) onto a VPS.
-
-## 2. Tailscale tag + ACL (one-time per tailnet)
-
-In the Tailscale admin console (the UI's words, mapped):
-- **tag name**: `openrig-vps` (enter as `tag:openrig-vps` in ACL JSON).
-- **tag owner**: your tailnet admin group/user (`"tagOwners": {"tag:openrig-vps": ["autogroup:admin"]}`).
-- ACL: home base may reach `tag:openrig-vps` on 22/7433 over the tailnet;
-  `tag:openrig-vps` gets NO grants toward the home base (the reverse path is
-  the explicit recipe in §6, never standing policy).
-- Auth keys for `tailscale up` must be EPHEMERAL or revoked after use.
-
-## 3. Bootstrap (fresh VPS → factory-ready)
-
-On the VPS, as root:
-
-```bash
-curl -fsSLO <your-copy-of>/scripts/bootstrap-product-factory-vps.sh
-chmod +x bootstrap-product-factory-vps.sh
-./bootstrap-product-factory-vps.sh \
-  --artifact @openrig/cli@<version> \
-  --authorized-key "$(cat ~/.ssh/openrig-factory.pub)" \
-  --ts-authkey tskey-...   # ephemeral
-```
-
-The script is stepwise and loud: non-root `openrig` user (key-only) → sshd
-hardening drop-in (`PermitRootLogin no`, `PasswordAuthentication no`,
-`KbdInteractiveAuthentication no`, `X11Forwarding no`) → UFW default-deny +
-tailnet ingress (public SSH stays open as a BOOTSTRAP ESCAPE HATCH only) →
-Tailscale with `tag:openrig-vps`, no routes/exit-node/Tailscale SSH → Node 22 →
-`npm install -g` of the artifact (must succeed with NO manual package
-patching) → daemon + kernel.
-
-On the home base:
-
-```bash
-rig host add --id ovh-01 --transport ssh --target <tailnet-alias> --user openrig
-rig host doctor ovh-01                                   # expect 4/4 green
-rig host doctor ovh-01 --posture product-factory-vps --public-addr <public-ip>
-```
-
-Then close the escape hatch on the VPS: `sudo ufw delete allow OpenSSH` and
-make sure Tailscale SSH is off: `tailscale set --ssh=false`. Re-run the
-posture check. UNKNOWN posture items are NOT passes — each carries the command
-that verifies it from the right vantage.
-
-## 4. Transport posture (the decided partition)
-
-See the per-command transport table in `docs/as-built/cli-reference.md`
-(§Cross-host execution). The partition IS the intended posture: ssh carries
-interactive pane ops (`send`/`capture`); http-bearer carries daemon REST ops
-(`up`/`down`/`launch`); `ps`/`whoami` follow the host's DECLARED transport;
-fan-out (`--all-hosts`) is http-only. There is NO cross-transport fallback and
-NO http parity for send/capture in 0.4.4 (parity = new attack surface with no
-scope-locked need).
-
-## 5. Safe UI access (recipe, not a verb)
-
-The daemon binds loopback/tailnet — never public. View the factory UI through
-a local tunnel (the smoke test's exact form):
-
-```bash
-ssh -N -L 127.0.0.1:17433:127.0.0.1:7433 <tailnet-alias>
-# then open http://127.0.0.1:17433
-```
-
-Tear the tunnel down when done. Do not add public allow rules for :7433.
-
-## 6. Restricted reverse path (supported recipe — NOT always-on)
-
-Boundary first: home-base-initiated ONLY; no broad VPS→home SSH; the tunnel is
-torn down after use. The factory cannot freely reach into the home base.
-
-1. On the home base, create a dedicated key the FACTORY will use through the
-   reverse tunnel, and gate it with a forced command in
-   `~/.ssh/authorized_keys`:
-
-```text
-command="$HOME/.openrig/bin/openrig-reverse-gate",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-ed25519 AAAA...factory-reverse-key
-```
-
-2. The gate script (generatable template — allowlists EXACTLY the four verbs
-   the smoke test proved; everything else is refused, fail-closed):
-
-```bash
-#!/usr/bin/env bash
-# openrig-reverse-gate — forced-command allowlist for the reverse path.
-set -euo pipefail
-case "${SSH_ORIGINAL_COMMAND:-}" in
-  "rig send "*|"rig capture "*|"rig ps"*|"rig whoami"*)
-    exec $SSH_ORIGINAL_COMMAND ;;
-  *)
-    echo "refused: only rig send/capture/ps/whoami are allowed on this key" >&2
-    exit 77 ;;
-esac
-```
-
-3. Open the reverse tunnel FROM the home base when you want the channel:
-
-```bash
-ssh -N -R 127.0.0.1:2222:127.0.0.1:22 <tailnet-alias>   # home-base initiated
-```
-
-4. On the factory, agents reach home through it:
-   `ssh -p 2222 -i <factory-reverse-key> operator@127.0.0.1 rig send <session> "..."`.
-5. Kill the tunnel after use. The REFUSAL of any out-of-allowlist verb is the
-   proof artifact that the gate works — test it on purpose.
-
-## 7. Credential + teardown discipline
-
-- Runtime credentials (Claude/Codex) live ON the VPS, provisioned for it —
-  never copied from the home host.
-- Snapshot/backup expectations and clean teardown follow the provider's
-  tooling; `rig down --snapshot` before destroying a factory.
-- Revoke the Tailscale node + one-time keys when a factory is retired.

package/daemon/specs/agents/shared/skills/core/mission-slice-sop/SKILL.md

@@ -1,115 +0,0 @@
----
-name: mission-slice-sop
-description: Use when working a mission or slice — the full SDLC flow (intent → mini-requirements + proof contract → mockups → plan-lock → build → QA visual compare → `rig proof` drops → proof-lock) plus how to track, prove, hand off, and carry state across agents and compaction via the canonical files (PROGRESS.md / PROOF.md / MISSION_NOTES.md / MISSION_BRIEF.md / README.md / IMPLEMENTATION-PRD.md). Covers the convention sections the Living Notes UI projects, the two locks, the three role contracts, per-file WHO/WHEN/HOW rules, the four-legs lifecycle, hot-potato queue handoffs, the moment-of-truth checklist, the deterministic `rig scope audit` backstop, and the ghost-text capture gotcha.
-metadata:
-  openrig:
-    stage: shipped
-    last_verified: "2026-07-06"
-    distribution_scope: product-bound
-    source_evidence: |
-      Authored + embedded in release-0.4.3 slice 32 (mission-slice-sop);
-      moved into the canonical product skill source and updated in
-      release-0.4.4 slice 23 (operationalize the SDLC control plane) to
-      teach the full SDLC flow the Living Notes UI projects: the convention
-      sections, the proof-contract pairing, the two staged-approval locks,
-      C1 proof drops, and the three role contracts. Conventions SSOT:
-      docs/reference/sdlc-conventions.md (shipped with the CLI package).
-      The deterministic backstop is the `rig scope audit` classifier.
-    sibling_skills:
-      - queue-handoff
-      - seat-continuity-and-handover
-      - claude-compaction-restore
----
-
-# Mission/Slice SOP — how you work a mission & slice
-
-Use this skill to actually **do** mission/slice work the way OpenRig expects: author the convention sections, track on the canonical files, prove on them, hand off through them, and survive compaction on them. **Do the work described here; do not merely explain the protocol.** The deterministic backstop is `rig scope audit` — the audit classifier is the source of truth for adherence. The conventions themselves live in ONE place: **`docs/reference/sdlc-conventions.md`** (shipped with the CLI package) — this skill teaches the flow; the SSOT defines the formats.
-
-## The SDLC flow (intent → proof)
-
-```
-intent → mini-requirements + proof contract → (UI slices: mockups)
-      → plan-lock (rig scope slice approve --scope spec)
-      → build the LOCKED set
-      → QA: mockup ↔ delivered VISUAL compare
-      → proof drops (rig proof add <slice> …)
-      → proof-lock (rig scope slice approve --scope delivery)
-```
-
-1. **Record intent** verbatim in the slice's `## Intent` section (`rig scope slice create` scaffolds it — every template kind).
-2. **Author the mini-requirements + proof contract**: `## Mini-requirements` is the concise one-glance tier (approval starts there); `## Proof contract` is a checkbox list of promised deliverables, each written as an observable outcome. UI deliverables name their planned mockup. The IMPLEMENTATION-PRD opens with the mini-requirements; everything between intent and proof is **elastic** — for a small slice the mini-requirements may BE the whole PRD.
-3. **Plan-lock**: `rig scope slice approve <slice> --scope spec` — "the PRD matches the intent; THIS artifact set is what gets built." One daemon-side write: frontmatter stamp + append-only audit row.
-4. **Build the locked set** — look at the mockups, not just the spec text.
-5. **QA visual compare**: for each deliverable, load the planned mockup, produce the real artifact in a test/demo environment, visually compare, and record the verdict.
-6. **Drop proof**: `rig proof add <slice> --artifact-type qa --verdict PASS --candidate-sha <tip> --money-evidence "…" --evidences "1,3" --media "walk.webm,panel.png" --self-check "…"` — the C1 header's closed sets validate at drop time; `--evidences` joins the drop to its proof-contract items and `--media` names the curated proof/-relative media the drop stands behind (that pairing + media set is what the UI's DELIVERED section renders).
-7. **Proof-lock**: `rig scope slice approve <slice> --scope delivery` — the terminal sign-off. Approval is freeze/sign-off, **never** proven-green: proven-green requires the recorded C1 verdicts.
-
-## The three role contracts
-
-- **Planning agent:** authors intent + mini-requirements + the proof contract; produces mockups for UI deliverables and attaches them to the locked set (a UI slice with no mockup is an incomplete plan; non-UI slices have none — not a gate); locks the plan.
-- **Build agent:** builds against the LOCKED set only; looks at the mockups.
-- **QA agent (owns the compare):** visually compares planned vs delivered per deliverable, records verdict + note via proof drops, and **curates** the canonical proof set (bounded, mapped to deliverables; the fix-loop pile stays in `proof/`, one drill-in down). On mismatch: fix-and-re-review or kick back with the reason — never escalate a raw mismatch to the human.
-
-## The canonical files (the operating surface)
-
-> The canonical files below are the **operating surface of the work** — you track on them, prove on them, hand off through them, and survive compaction on them. They are NOT side-artifacts to "maintain"; keeping them current *is* the work.
-
-- **README.md** (mission + slice) — the overview, OPENING with the convention sections (`## Intent` / `## Mini-requirements` / `## Proof contract`). The **mission README carries this SOP at its bottom.**
-- **IMPLEMENTATION-PRD.md** — the full PRD; opens with the mini-requirements; the `## Proof contract` here is what the UI's DELIVERED pairing joins proof against.
-- **PROGRESS.md** — the live delivery state. One line per outcome; links down for detail.
-- **MISSION_NOTES.md** — the accruing handoff + tribal-knowledge doc. Blank-slate onboarding + **compaction-restore** read it. `§1` top-of-mind + per-seat `§A–§X`.
-- **MISSION_BRIEF.md** — the steering doc (the UI "Steering" tab). The 7-section schema.
-- **PROOF.md** (+ `proof/`) — acceptance evidence. **A slice is not done until every proof-contract item has evidence.**
-
-## Per-file rules — WHO / WHEN / HOW
-
-### PROGRESS.md
-- **WHO:** the orchestrator owns `§1` (current state); every agent logs its own outcomes.
-- **WHEN:** after every slice-done **AND every commit**; on any material state change.
-- **HOW:** one line per outcome (checkbox), link down for detail (workstream-continuity format); keep frontmatter `stage`/`verified` honest.
-
-### PROOF.md + proof/
-- **WHO:** the impl/QA pair that worked the slice.
-- **WHEN:** a slice is **NOT "done"** until every proof-contract item has evidence.
-- **HOW:** proof maps **1:1 to the proof contract's deliverables** — put media under `proof/`, then ATTACH it with `rig proof add <slice> … --evidences <item> --media <files>` (the drop writes the C1 header the DELIVERED pairing joins on) + a line in PROOF.md stating what it proves. **Hand-placing files in `proof/` without a drop is the anti-pattern** — the deliverable stays unpaired and `unverified`. No proof → not done.
-
-### MISSION_NOTES.md
-- **WHO:** any agent updates `§1` (top-of-mind); each seat owns + appends to its own `§A–§X` section.
-- **WHEN:** on any material change; a compacting agent **files its state here BEFORE compaction and reads it on restore.**
-- **HOW:** accruing tribal knowledge — `§1` ≤ 5–15 lines (gates, open decisions, surprises); per-seat continuation entries (latest = truth; other seats read-only). Pointer-first; don't duplicate.
-
-### MISSION_BRIEF.md
-- **WHO:** product/design (steering owner).
-- **WHEN:** when steering changes.
-- **HOW:** the 7-section steering schema (the UI "Steering" tab reads it).
-
-### README.md
-- **WHO:** the author at creation; refreshed on rescope.
-- **WHEN:** at mission/slice creation + when scope/theme changes.
-- **HOW:** overview + honest frontmatter (`id`/`stage`/`verified`) + the convention sections up top; the mission README carries this SOP at its bottom.
-
-## The lifecycle (4 legs)
-
-**SCAFFOLD** (`rig scope` creates the files from templates — every slice kind emits the convention sections + `proof/` + the IMPLEMENTATION-PRD skeleton) → **POPULATE** (agents fill them as work happens, per the rules above) → **PROJECT** (the Living Notes UI reads them into INTENT → PLAN → DELIVERED) → **VERIFY** (`rig scope audit` checks adherence). "Loose freeform write + deterministic verify."
-
-## Hot-potato (handoffs)
-
-End every turn by passing the ball — a `rig queue` handoff to the next agent (close the qitem with a `closure_reason`). The **durable ball-pass is the queue close, not a chat message.** Never go idle without a handoff.
-
-## Verify (deterministic backstop)
-
-Run `rig scope audit` at slice-close. It flags: committed-without-touching-PROGRESS; slice-marked-done-without-PROOF; active-mission-without-MISSION_NOTES; MISSION_BRIEF off-schema; proof artifacts violating the C1 header; missing IMPLEMENTATION-PRD on a building slice; missing convention sections (`## Intent`, a well-formed `## Proof contract`, the UI-slice mockup ref). Every convention check is **advisory / fail-open** — it records and advises, never blocks a write. **Fix the flag, don't suppress it.**
-
-## Reading terminal captures — KNOWN GOTCHA: ghost-text autocomplete is NOT real
-
-When you `rig capture` a pane, **greyed / ghost autocomplete suggestions are NOT real content** — they are autocomplete *previews* (shell autosuggestion, the input-box ghost-text completion), not typed, staged, or committed input. **This is known, expected, and has been faking agents out a lot** — reading a ghost suggestion in a peer's input box as "staged text they're about to send," or as a real prompt, and then reasoning/acting on a string that was never actually there.
-
-**Rule:** ignore ghost/autosuggest text entirely. Only *committed/rendered* pane output is real. If a `❯` input line shows text, treat it as an autocomplete artifact unless you have independent evidence it was actually entered. Do not build decisions (or worry about "colliding with staged text") on ghost text. When it matters, verify at source (git, the queue, the actual event) — never off a capture's ghost line.
-
-## Moment-of-truth checklist
-
-- **Starting a slice?** → intent recorded verbatim? mini-requirements + proof contract authored? mockups attached (UI slices)? plan locked (`--scope spec`)?
-- **Finishing a slice?** → every proof-contract item has curated evidence via `rig proof add … --evidences --media` (C1 drops — never only hand-placed files)? PROGRESS updated? MISSION_NOTES `§1` refreshed? proof locked (`--scope delivery`)? Handed off via queue?
-- **Committing?** → PROGRESS updated?
-- **Compacting?** → filed your state in MISSION_NOTES?
-- **Starting on a mission?** → read the mission README (incl. this SOP) + MISSION_NOTES + `docs/reference/sdlc-conventions.md`?

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

@@ -1,142 +0,0 @@
----
-name: openrig-installer
-description: Use when installing or upgrading OpenRig on a host, especially the V0.3.1 upgrade flow which includes the substrate-kernel → daemon-managed-kernel migration ceremony. Covers npm install, rig setup, rig daemon start (auto-boots kernel), and the canonical verification commands. NOT for ordinary kernel operation post-install — use openrig-operator skill for that.
-metadata:
-  openrig:
-    maturity: L2
-    distribution_scope: shipped
-    source_evidence: V0.3.1 slice 05-kernel-rig-as-default IMPLEMENTATION-PRD §8 + OQ-A=B migration-ceremony decision
----
-
-# OpenRig Installer
-
-This skill teaches the operator agent how to install + upgrade
-OpenRig cleanly. The V0.3.1 upgrade is the one with the migration
-ceremony (substrate kernel → daemon-managed kernel); other upgrades
-follow the same install / setup / start shape with no migration.
-
-## Fresh install
-
-```bash
-npm install -g @openrig/cli
-rig setup
-```
-
-`rig setup` is idempotent — safe to re-run if a step fails. It probes
-host prereqs (tmux present, Node version, writable state path,
-optional cmux), then invokes `rig daemon start` per the L2 factoring
-(OQ-B). The daemon's start path auto-boots the kernel rig per the
-V0.3.1 slice 05 kernel-rig-as-default logic.
-
-## Verification after install
-
-```bash
-rig ps --nodes --rig kernel --json
-```
-
-Should report 4 members (advisor.lead + operator.agent +
-operator.human + queue.worker) all ready. If a runtime is unavailable
-the daemon picks the matching variant (`rig-claude-only.yaml` or
-`rig-codex-only.yaml`); the topology stays the same shape with the
-unavailable runtime omitted from the agent membership.
-
-Entry point for chatting with the rig:
-
-```bash
-rig capture advisor-lead@kernel
-```
-
-Or click the CMUX button on the topology graph in the UI at
-`/topology`.
-
-## V0.3.1 upgrade ceremony (one-time migration)
-
-Operators with a kernel spec stored outside the daemon-managed
-location (any pre-V0.3.1 layout, typically wherever you kept your
-own `rigs/kernel/` directory) must migrate to
-`~/.openrig/specs/rigs/kernel/` as a one-time step during the V0.3.1
-upgrade. The V0.3.1 upgrade IS the migration moment; it's not a
-separate ceremony.
-
-### Migration steps
-
-1. **Snapshot first.** Take a snapshot of the running substrate
-   kernel so the migration is reversible:
-
-   ```bash
-   rig snapshot kernel
-   ```
-
-2. **Stop the substrate kernel** (so the migration doesn't race a
-   running rig):
-
-   ```bash
-   rig down kernel --snapshot
-   ```
-
-3. **Copy your existing kernel spec** into the daemon-managed
-   location:
-
-   ```bash
-   mkdir -p ~/.openrig/specs/rigs/kernel
-   cp -r /path/to/old/kernel-spec/* ~/.openrig/specs/rigs/kernel/
-   ```
-
-4. **Upgrade the CLI + daemon**:
-
-   ```bash
-   npm install -g @openrig/cli@0.3.1
-   rig daemon stop
-   rig daemon start
-   ```
-
-   At this point the new daemon detects `~/.openrig/specs/rigs/kernel.yaml`
-   exists and skips the V0.3.1 builtin-kernel boot (the
-   already-managed-rig branch). The substrate-rooted topology
-   continues to run under daemon management.
-
-5. **Verify** the migrated kernel matches expectations:
-
-   ```bash
-   rig ps --nodes --rig kernel --json
-   ```
-
-6. **Decommission the old copy** (only after verifying the
-   daemon-managed copy works):
-
-   ```bash
-   rm -rf /path/to/old/kernel-spec
-   ```
-
-### If migration fails
-
-The pre-step snapshot is the rollback. `rig restore <snapshot-id>
---rig kernel` revives the prior topology. Then `npm install -g
-@openrig/cli@0.3.0` rolls the CLI back and you can retry later.
-
-## Operator agent's role in install + upgrade
-
-The operator agent shepherds operators through these steps when the
-user asks "how do I upgrade?" or "what's the V0.3.1 ceremony?". The
-agent reads this skill on demand via `find-skills` — it does not
-need to memorize the steps; it consults the canonical reference
-(this file) and walks the operator through.
-
-## 3-part error remediation
-
-| What failed | Why it matters | Fix |
-|---|---|---|
-| `npm install -g @openrig/cli` permission denied | Global install needs writable npm prefix; macOS Homebrew default is usually writable; some custom Node installs aren't | Either fix the npm prefix permissions or use `sudo npm install -g`; check `npm config get prefix` |
-| `rig setup` host prereq fail | tmux, Node version, or writable state path missing | `rig doctor` lists each missing piece + the install command; run those, retry `rig setup` |
-| `rig daemon start` auth-block error | Neither Claude Code nor Codex authenticated; kernel rig requires at least one | Run `claude auth login` OR `codex login`; then retry `rig daemon start` |
-| `rig daemon start` "kernel already managed" | An existing managed rig named `kernel` exists; the daemon skips builtin-boot per design | This is the expected path after migration — no action needed |
-| `rig ps --rig kernel --json` returns empty | Daemon healthy but no kernel rig managed; likely the migration step copied content but did not boot | `rig up kernel` from inside `~/.openrig/specs/rigs/kernel/`; or invoke the daemon's cold-boot path explicitly |
-
-## What this skill is NOT
-
-- Not the canonical OpenRig command surface; that lives in the
-  `openrig-user` skill.
-- Not the kernel-operating-procedure for post-install daily use;
-  that's `openrig-operator`.
-- Not for project rigs; project rigs install themselves via `rig
-  up <spec>` after the kernel is in place.

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

@@ -1,110 +0,0 @@
----
-name: openrig-operator
-description: Use when operating or debugging host-side OpenRig runtime issues including daemon reachability, partial identity, unified-exec warnings, stale helper-process cleanup, or when distinguishing harness/process issues from live topology health.
----
-
-# OpenRig Operator
-
-## Overview
-
-This skill covers host/runtime/operator triage around OpenRig itself.
-Use it when the problem may be the daemon, the shell/runtime surface, or stale helper processes rather than the product workflow you are trying to run.
-
-## When to Use
-
-Use this skill when you see:
-- `rig whoami --json` returning partial identity
-- `rig ps --nodes -A --json` failing while some other `rig` commands still work
-- `Sent to ...` plus `Verified: no`
-- repeated unified-exec-process warnings
-- suspicion that stale helper processes are accumulating
-
-Do not use this skill for normal product workflow routing, queue handling, or ordinary peer communication. Use `openrig-user` for that.
-
-## First Checks
-
-Start with the minimum truthful operator read:
-
-```bash
-rig whoami --json
-rig daemon status
-rig ps --nodes -A --json
-```
-
-Interpret them together, not in isolation:
-- partial `whoami` can mean identity is inferable while daemon-backed surfaces are degraded
-- `daemon status` tells you whether the host daemon is up, not whether every seat can reach it cleanly
-- `ps --nodes -A --json` is the best machine-readable fleet topology check when it works (v0.4.4: `--nodes` needs an explicit scope outside a managed session — `-A` for fleet, `--rig <name>` for one rig; the bare `rig ps` map is the cheap first glance)
-
-## Verification Drift Vs Send Failure
-
-For `rig send`:
-- `Sent to ...` + `Verified: yes` = strong positive delivery evidence
-- `Sent to ...` + `Verified: no` = ambiguous delivery, not automatic failure
-- no `Sent to ...` line or a hard error = send failure
-
-When verification is ambiguous, check:
-- direct reply
-- `rig capture <session>`
-- transcript evidence
-- queue/outbox state if the message asked for a durable handoff
-
-Do not blindly retry until you have checked one of those.
-
-## Unified Exec Warning
-
-If you see:
-
-- `Warning: The maximum number of unified exec processes you can keep open is 60 ...`
-
-treat it first as a host/tooling-layer warning, not as automatic proof that the OpenRig topology is unhealthy.
-
-This warning can coexist with a healthy live topology.
-
-## Safe Process Triage
-
-Inspect the process surface first:
-
-```bash
-ps -axo pid,ppid,command | rg 'tmux send-keys|rig queue create|tmux attach|codex|claude'
-```
-
-Think in layers:
-- host/tooling layer: stale one-shot wrappers, session bookkeeping, helper shells
-- topology layer: live `tmux attach` seats, live `codex` / `claude` runtimes, daemon health
-
-Do not diagnose topology failure from tooling-layer warnings alone.
-
-## Safe Cleanup Boundary
-
-Usually safe to reap when clearly orphaned / one-shot:
-- `tmux send-keys ...`
-- short-lived shell wrappers created only to enqueue or send one message
-
-Do not mass-kill:
-- `tmux attach ...`
-- `codex ...`
-- `claude ...`
-- other long-lived daemon/runtime processes
-
-The point is to remove garbage, not workers.
-
-## Common Mistakes
-
-- treating `Verified: no` as if it proves the message did not land
-- treating the unified-exec warning as if it proves the rig is overloaded
-- killing live seats when only stale helper wrappers needed cleanup
-- concluding "daemon down" from one seat's failure without checking host-level daemon status
-
-## Practical Rule
-
-Clean the smallest safe surface that matches the evidence.
-
-If the warning or failure remains after stale-wrapper cleanup, re-check:
-
-```bash
-rig daemon status
-rig ps --nodes -A --json
-```
-
-If those remain healthy, the residual issue may still be in the host/tool/session layer rather than in OpenRig topology state.