@openrig/cli 0.4.3 → 0.4.6

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

@@ -14,7 +14,7 @@ Use it when the problem may be the daemon, the shell/runtime surface, or stale h
 
 Use this skill when you see:
 - `rig whoami --json` returning partial identity
-- `rig ps --nodes --json` failing while some other `rig` commands still work
+- `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
@@ -28,13 +28,13 @@ Start with the minimum truthful operator read:
 ```bash
 rig whoami --json
 rig daemon status
-rig ps --nodes --json
+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 --json` is the best machine-readable topology check when it works
+- `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
 
@@ -104,7 +104,7 @@ If the warning or failure remains after stale-wrapper cleanup, re-check:
 
 ```bash
 rig daemon status
-rig ps --nodes --json
+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.

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

@@ -28,7 +28,7 @@ the receipt and move on.
 Example:
 
 ```bash
-rig send velocity-guard@openrig-velocity "Heads up — filing per-commit handoff on slice-22 Bug 1 BONUS at tip 6b8673b6." --verify
+rig send reviewer@acme-web "Heads up — filing the per-commit handoff on the search-filters slice at the current tip." --verify
 ```
 
 ### `rig queue create --source <X> --destination <Y> --tags <...> --body "<...>"` — durable work item
@@ -47,9 +47,9 @@ Example:
 
 ```bash
 rig queue create \
-  --source redo-driver-2@openrig-velocity \
-  --destination redo-guard-2@openrig-velocity \
-  --tags "mission:release-0.3.2,slice:22-rig-up-paper-cut-fix-round,gate:guard,handoff:per-commit,checkpoint:bug-1-bonus" \
+  --source builder@acme-web \
+  --destination reviewer@acme-web \
+  --tags "mission:site-relaunch,slice:02-search-filters,gate:guard,handoff:per-commit,checkpoint:bug-1" \
   --body "$(cat /tmp/per-commit-body.txt)"
 ```
 
@@ -64,8 +64,8 @@ Example:
 
 ```bash
 rig queue handoff qitem-20260601012431-d78aa805 \
-  --to velocity-qa@openrig-velocity \
-  --tags "mission:release-0.3.2,slice:22-rig-up-paper-cut-fix-round,gate:qa,handoff:adversarial-dogfood"
+  --to qa@acme-web \
+  --tags "mission:site-relaunch,slice:02-search-filters,gate:qa,handoff:adversarial-dogfood"
 ```
 
 ### §1b doctrine — turn ends by passing the ball
@@ -435,27 +435,47 @@ honestly and the UI exposes a one-click open-missing affordance.
 
 v0.4.0 flips the five most frequently invoked read-commands from firehose-by-default to compact-by-default, and `rig queue list` adopts the docker / kubectl read-command grammar. **All defaults preserve breadth and capability — the firehose is one explicit flag away.**
 
-### `rig ps` — current-rig default + compact-by-default + `-A`/`--all-rigs` + `--full`
+### `rig ps` — consolidated all-rigs default + the disclosure ladder (v0.4.4)
 
 ```bash
-rig ps                      # CURRENT-RIG, all-states, compact rig summaries (default)
-rig ps --json               # compact JSON array (TL;DR per node: session, rig, activity, assigned/pending, resumeTokenPresent boolean)
-rig ps -A                   # all-rigs (fleet breadth; was the v0.3.4 default)
-rig ps --rig <name>         # explicit-rig (overrides current-rig default)
-rig ps --nodes              # compact node inventory (current rig)
-rig ps --nodes -A           # cross-rig node inventory (was v0.3.4 default)
-rig ps --nodes --full       # complete record (the v0.3.4 per-node default shape; resumeToken VALUE retained here for downstream consumers)
+rig ps                      # ALL ACTIVE RIGS, one compact row each + rollup line + count line + ladder footer (default)
+rig ps --json               # bare array of ALL non-archived rigs (incl. stopped; existing keys + additive attentionCount)
+rig ps --rig <name>         # one rig's detail
+rig ps --nodes              # compact node inventory (current rig — session default, LOCAL only)
+rig ps --nodes --rig <name> # compact node inventory, named rig
+rig ps --nodes -A           # fleet node inventory, projected rows
+rig ps --nodes -A --full    # complete per-node records (the ONLY full fan-out; resumeToken VALUE retained here for downstream consumers)
 rig ps --nodes --session <sess>  # narrow to one canonical session
+rig ps --include-archived   # archived history as rows (otherwise ONE count line)
 rig ps --active             # opt-in active-state filter (does NOT change the all-states default — ps surfaces topology/readiness, where stopped/recoverable/attention IS the actionable signal)
 ```
 
-**v0.4.0 breadth + projection changes**:
-- **Slice 34**: default breadth is CURRENT-RIG (derived from `OPENRIG_SESSION_NAME`'s `@<rig>` suffix), not all-rigs. `-A` / `--all-rigs` widens to fleet. Matches the `rig queue list -A` pattern.
-- **Slice 25 + 26**: per-node TL;DR projection (compact) is the default; `--full` returns the raw byte-equivalent passthrough. Daemon-side `recoveryGuidance` relocated to a guidance-by-reference map (no longer duplicated per-node) — even `--full` benefits.
-- **All-states stays default** (different from `rig queue list` which defaults to active-only) — for `ps`, non-running states ARE often the actionable signal.
-- **Resume-token security (slice 34)**: `--full` JSON emits `resumeTokenPresent` (boolean) — the actual `resumeToken` value also remains in `--full` for downstream consumers that legitimately need it, but the compact default never carries it (an orch glance never accidentally leaks token material).
+**v0.4.4 consolidated default + disclosure ladder (OPR.0.4.4.21)**:
+- **The default is the fleet MAP**: every active rig as one O(rigs) compact row, with the host rollup ("N rigs · M seats · K need attention"), the archived/stopped count line, and the drill-ladder footer. The v0.4.0 current-rig default is RETIRED — it hid running rigs from the operator's field of view.
+- **`-A` has exactly ONE meaning**: the `--nodes` fleet widener. Bare `rig ps -A` errors (all-rigs IS the default; archived history stays behind `--include-archived`).
+- **The session-rig default applies ONLY to `--nodes`, and only locally.** Implicit scope defaults don't cross host boundaries: `rig ps --host <id> --nodes` requires an explicit `--rig` or `-A`; multi-host fan-out is rollup-only by default; the full explicit ladder (`--all-hosts --nodes -A`, `--full` for complete records) fans out per-node with hostId-stamped projected rows.
+- **STATED JSON contract**: default `--json` = bare array of ALL non-archived rigs INCLUDING stopped ones (scope-not-shape: existing keys preserved, additive `attentionCount`); only the human table folds stopped rigs into the count line.
+- **Resume-token security unchanged**: compact output never carries token material; `--full` retains it for consumers that legitimately need it.
 
-**STOP using `rig ps --nodes --json` as a fleet-wide casual status check assuming the v0.3.4 shape.** The v0.4.0 default is CURRENT-RIG + compact; explicit `-A --full` is the fleet firehose. The ~77,000-token status-glance incident is closed twice over (compact + scope).
+**The casual status glance is just `rig ps`.** The old fleet firehose is the explicit last rung: `rig ps --nodes -A --full`. The ~77,000-token incident class stays closed (compact + O(rigs) default + explicit ladder).
+
+### `rig host` — the multi-host registry verbs (v0.4.4)
+
+```bash
+rig host add --id <id> --transport ssh --target <tailnet-alias> --user openrig
+rig host add --id <id> --transport http --url http://100.x.y.z:7433 --bearer-env MY_TOKEN
+rig host list                       # pointers only — never secret values
+rig host doctor <id>                # stepwise: transport -> rig binary -> daemon -> identity
+rig host doctor <id> --posture product-factory-vps [--public-addr <ip>]
+```
+
+Exactly three verbs (capped); the VPS factory bootstrap is script + runbook
+(`docs/reference/product-factory-vps-runbook.md`). **Transport posture is
+DECIDED and documented** (cli-reference §Cross-host execution): ssh = pane ops
+(`send`/`capture`), http = daemon REST (`up`/`down`/`launch`), `ps`/`whoami`
+follow the DECLARED transport; fan-out is http-only; no cross-transport
+fallback; no http parity for send/capture in 0.4.4. Posture/doctor UNKNOWN is
+never pass — each unknown carries the command that verifies it.
 
 ### `rig whoami` — compact-by-default + `--full` (`--verbose` alias)
 
@@ -543,6 +563,30 @@ rig scope slice show <slice>                          # derives read-time effect
 
 Composes with slice 33's `progress` + scaffolding to make `rig scope` the **deterministic enforcer** of `conventions/scope-and-versioning` §1 (dot-IDs) + §2 (maturity vocabulary). Agents update `stage` / `verified` / `id` through commands rather than hand-editing markdown and drifting. The `--against` MANDATORY rule on `verified` is the anti-stale keystone: bare timestamps are rejected because a bare timestamp is exactly what lets stale trackers lie while looking fresh. **STOP hand-editing the `stage` / `verified` / `id` fields in scope frontmatter; use the new verbs.** Existing missions / slices with `id:null` ghosts or missing `PROGRESS.md` are repaired idempotently via `reconcile`.
 
+### The SDLC control plane — convention sections, the two locks, `rig proof` (v0.4.4)
+
+The Living Notes UI is a plain projection of well-formed on-disk markdown. The conventions live in ONE shipped document — **`docs/reference/sdlc-conventions.md`** (in the CLI package) — and the operating procedure is the **`mission-slice-sop`** skill. The command surface:
+
+```bash
+rig scope slice create <mission> <slug> [--template <kind>]   # scaffolds ## Intent / ## Mini-requirements / ## Proof contract
+                                                              # + proof/ + PROOF.md + IMPLEMENTATION-PRD.md — EVERY template kind
+
+rig scope slice approve <slice> --scope spec                  # PLAN-LOCK: "the PRD matches my intent; this set gets built"
+rig scope slice approve <slice> --scope delivery              # PROOF-LOCK: the terminal sign-off (default scope; fires the freeze)
+
+rig proof add <slice> --artifact-type qa --verdict PASS \
+  --candidate-sha <tip> --money-evidence "<one line>" \
+  --evidences "1,3" --media "walk.webm" \
+  --self-check "<looked at it>"                               # C1 proof drop into proof/; --evidences joins the drop to its
+                                                              # proof-contract items and --media names the curated proof/-relative
+                                                              # media it stands behind (what the DELIVERED section pairs + renders)
+
+rig scope audit <mission>                                     # deterministic backstop — flags missing sections / malformed
+                                                              # proof contract / invalid C1 headers; ADVISORY, never blocks
+```
+
+The flow: intent → mini-requirements + proof contract (→ mockups for UI slices) → plan-lock → build the locked set → QA visual compare → `rig proof` drops → proof-lock. Approval is freeze/sign-off, **never** proven-green — proven-green requires recorded C1 verdicts.
+
 ### `rig skill audit` — skill cascade provenance (slice 10)
 
 ```bash
@@ -584,7 +628,7 @@ Typical operator loop:
 
 ```bash
 rig up secrets-manager --cwd /path/to/project
-rig ps --nodes --json
+rig ps --nodes --rig secrets-manager --json
 rig send vault-specialist@secrets-manager "Check Vault health and report back." --verify
 rig env status secrets-manager
 rig env logs secrets-manager
@@ -634,10 +678,12 @@ JSON form exposes `peersNote` directly for programmatic consumers.
 rig ps
 rig ps --json
 rig ps --nodes
-rig ps --nodes --json
+rig ps --nodes --rig <name> --json
+rig ps --nodes -A --json
+rig ps --nodes -A --full --json
 ```
 
-Use `rig ps --nodes --json` for the current node inventory across rigs. It is the best machine-readable operator surface for:
+Use `rig ps --nodes --rig <name> --json` for one rig's node inventory, or `rig ps --nodes -A --json` for fleet-wide projected node inventory. Use `--full` only when a downstream consumer truly needs complete per-node records. The node inventory surface carries:
 - session name
 - runtime
 - session/startup status
@@ -964,7 +1010,7 @@ rig whoami --json
 
 Notes:
 - for tmux-backed self-attach, `rig whoami --json` is the right verification
-- for raw/external self-attach, `rig ps --nodes --json` is currently the more reliable verification surface
+- for raw/external self-attach, `rig ps --nodes --rig <rigId-or-name> --json` is currently the more reliable verification surface
 - if the current shell is outside tmux, pass `--display-name <name>` when you want a stable human session label recorded
 
 ### Adopt a topology and bind live sessions
@@ -1031,13 +1077,13 @@ Verification loop:
 ```bash
 rig discover --json
 rig adopt <fragment.yaml> --bindings-file <bindings.yaml> --target-rig <rigId>
-rig ps --nodes --json
+rig ps --nodes --rig <target-rig-name> --json
 rig export <rigId> -o rig.yaml
 ```
 
 Success looks like:
 - the new sessions stop appearing in `rig discover`
-- the new logical IDs appear in `rig ps --nodes --json`
+- the new logical IDs appear in `rig ps --nodes --rig <target-rig-name> --json`
 - `rig export` includes the new pod
 
 ### Mixed-origin rigs are allowed
@@ -1055,7 +1101,7 @@ Current safety rule:
 The proven operator pattern is:
 - keep one OpenRig manager session outside the rig it manages
 - address the target by rig name, not cached rig ID
-- resolve the current owner from fresh `rig ps --nodes --json`
+- resolve the current owner from fresh `rig ps --nodes -A --json`
 - send the manager the spec path, bindings path, and verification steps with `rig send`
 
 This lets ordinary agents ask the manager for OpenRig help instead of every agent needing to be an OpenRig expert.
@@ -1152,7 +1198,7 @@ When the CLI behaves strangely, use the smallest truthful check first:
 ```bash
 rig whoami --json
 rig daemon status
-rig ps --nodes --json
+rig ps --nodes
 ```
 
 Specific operator rules:
@@ -1188,7 +1234,7 @@ Design assumptions that hold in the shipped CLI:
 
 1. `rig whoami --json`
 2. `rig transcript <your-session> --tail 100`
-3. `rig ps --nodes --json`
+3. `rig ps --nodes`
 4. `rig chatroom history <rig> --limit 50`
 
 ## Commands That Do Not Exist

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

@@ -12,7 +12,7 @@ You are part of the orchestration pod. Your job is to keep the team productive,
 Before you summarize the rig or assign real work:
 1. Load `using-superpowers`, `openrig-user`, `orchestration-team`, `systematic-debugging`, and `verification-before-completion`. Also load `mission-slice-sop` — the operating procedure for the canonical mission/slice files (you own PROGRESS.md `§1`; run `rig scope audit` at slice-close/mission-wrap).
 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.
+3. Run `rig ps --nodes -A --json` (v0.4.4: `--nodes` scopes to the current rig by default; `-A` for the fleet) 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.
 5. Only then announce readiness or assign work.
 
@@ -34,7 +34,7 @@ The orchestration pod is responsible for:
 **Principle:** monitoring intensity tracks **stakes × how likely you are to need to intervene, bounded to the window where that's true.** Spend tight attention only where it changes what you do, only as long as the risk lasts, then return to default. (Same evidence-not-cadence rule the `watchdog` skill applies to intervention *level*, applied to *intensity*.) **Self-test: "Can I name the stakes AND the condition that ends this close-watch?"** If not, you're hyper-monitoring.
 
 **Default (almost always) — token-efficient.** Steady-state your job is the **idle-without-handoff exception**: the queue handles normal handoff; you catch the agent who finished + went idle without closing/handing off.
-- **Status lives in the queue, not panes** (`status-not-chat-orchestrator`): `rig ps --nodes --json` + `rig queue` are your status source; do NOT reconstruct fleet-state by capturing panes (pane `rig capture` is high-bandwidth *within your own pod* — that's fine; it is not how you track cross-pod/fleet state).
+- **Status lives in the queue, not panes** (`status-not-chat-orchestrator`): `rig ps` (the consolidated map) / `rig ps --nodes -A --json` + `rig queue` are your status source; do NOT reconstruct fleet-state by capturing panes (pane `rig capture` is high-bandwidth *within your own pod* — that's fine; it is not how you track cross-pod/fleet state).
 - **The watchdog is your clock** (`watchdog`): configure `rig watchdog` to wake you (~3 min); between wakes, idle (zero tokens) — no self-run sleep-loop re-reading panes at steady-state. Prefer one workflow-watchdog + targeted exception handling over many per-seat nag loops.
 - **On each wake — cheap sweep:** `rig queue` + a *filtered* `rig ps` (see "Read cheap" below) first; ONLY for a seat that looks idle/suspicious, `rig capture <session>` last few lines (never a full pane, never huge chunks); **active owner → no-op.**
 - **Read cheap — every status command has a token cost; project to the question.** The queue-first rule is about *where* status lives; this is about *how much you pay to read it*. The token bomb is the broad unfiltered dump, not the pane capture: an unfiltered fleet-wide `rig ps --nodes --json` emits ~77k tokens — for a one-rig or one-qitem question that is almost all waste, and at watchdog cadence it burns the shared account fast.

package/daemon/specs/rigs/focused/pm-team/CULTURE.md

@@ -15,3 +15,7 @@ Ship features that solve real customer problems with evidence-backed requirement
 - PM agent is the hub. Research and code agents report to PM.
 - Coder can observe researcher output for domain context.
 - When blocked, escalate to PM rather than guessing.
+
+## Mission/slice tracking (the SDLC)
+
+Requirements and delivery are tracked as missions and slices — on-disk markdown the Living Notes UI projects. Load the packaged `mission-slice-sop` skill; the conventions live in `docs/reference/sdlc-conventions.md` (shipped with the CLI package). PM's leg of the flow: record intent verbatim, author the mini-requirements (the one-glance tier where approval starts) + the proof contract (promised deliverables as observable outcomes; UI deliverables name their planned mockup), then plan-lock with `rig scope slice approve --scope spec`. Proof-lock (`--scope delivery`) is the terminal sign-off after QA's visual compare and `rig proof add … --media` drops (the C1 drop verb).

package/daemon/specs/rigs/launch/factory-rsi/CULTURE.md

@@ -0,0 +1,47 @@
+# factory-rsi — the single-rig RSI factory MVP
+
+This rig IS a recursive-self-improvement loop. One workflow (`factory-rsi`)
+moves one slice through the inner loop **plan → implement → check → review →
+release**. Dogfood is decoupled from that gated loop: it continuously uses the
+**shipped** product out-of-band and feeds its findings into the **next** plan
+cycle. That feedback edge is the whole point — and it needs no human in the loop.
+
+## How the loop runs
+
+- The **engine routes the inner loop**, not the orchestrator. A failing check or
+  review routes back to build for bounded remediation; a clean review proceeds
+  to release prep. Nobody hand-relays a packet around the loop.
+- **Dogfood is out-of-band.** It runs continuously against the SHIPPED product —
+  not a second QA on the pre-release build artifact — and records findings that
+  become the next plan's input. The RSI recursion stays ungated: dogfood findings
+  feed the next plan with no human gate (a human MAY steer via the roadmap but is
+  never required; there is no loop-stop in the MVP).
+- **Findings are recorded state, not memory.** The next plan builds from the
+  recorded dogfood findings — never a seat's chat history.
+- **Exceptions go orchestrator-first** (the WF-5 dial); the human knows at
+  altitude. A `max_hops` trip is an exception, and a resume grants exactly one
+  more bounded window — the loop never runs away.
+- **Publishing is a human act.** The release seat PREPARES notes/docs/PR and
+  holds the ship decision at a human gate. No seat pushes, tags, or publishes.
+
+## The seats
+
+| Seat | Runtime | Does |
+|---|---|---|
+| `plan-planner` | claude-code | turns the corpus / previous findings into ONE buildable slice spec |
+| `build-implementer` | claude-code | builds the slice, produces proof |
+| `check-qa` | codex | checks the artifact; a failing check loops back to build |
+| `review-reviewer` | codex | reviews (cross-runtime vs the builder) |
+| `dogfood-tester` | codex | continuously USES the shipped product out-of-band; records findings that feed the next plan |
+| `release-manager` | claude-code | prepares the release, holds the human gate |
+| `orch-lead` | claude-code | the exception dial target — exceptions only |
+
+Seats inherit their runtime's default model (no per-seat model pin): plan,
+build, release, and orchestration run on claude-code; check, review, and dogfood
+run on codex for cross-runtime diversity against the builder.
+
+## Deployment
+
+As a shipped starter this rig is workspace-agnostic — point
+`rig up factory-rsi --cwd <repo>` at whatever real repository the loop should
+improve, and the planner's product-intent corpus is that repo's real specs.

package/daemon/specs/rigs/launch/factory-rsi/rig.yaml

@@ -0,0 +1,115 @@
+version: "0.2"
+name: factory-rsi
+culture_file: CULTURE.md
+summary: >
+  The single-rig RSI factory MVP (OPR.0.4.6.FAC2): ONE rig whose seats map 1:1
+  to the `factory-rsi` workflow — the inner loop plans, builds, checks, and
+  reviews one slice, then prepares its release. Dogfood is decoupled: it
+  continuously uses the SHIPPED product out-of-band and feeds findings back into
+  the next plan — the recursive-self-improvement edge, with no human required in
+  the loop. Run it with `rig up factory-rsi`, then instantiate the `factory-rsi`
+  workflow and watch the loop close. Seats inherit their runtime's default
+  model; qa, review, and dogfood run on the alternate runtime for cross-runtime
+  diversity against the builder.
+
+# Seven pods, one member each, so every canonical session name is
+# `<pod>-<member>@factory-rsi` and matches the workflow's preferred_targets 1:1.
+pods:
+  - id: plan
+    label: Planning
+    members:
+      - id: planner
+        agent_ref: "local:../../../agents/conveyor/planner"
+        runtime: claude-code
+        profile: default
+        cwd: "."
+    edges: []
+
+  - id: build
+    label: Build
+    members:
+      - id: implementer
+        agent_ref: "local:../../../agents/development/implementer"
+        runtime: claude-code
+        profile: default
+        cwd: "."
+    edges: []
+
+  - id: check
+    label: Check
+    members:
+      - id: qa
+        agent_ref: "local:../../../agents/development/qa"
+        runtime: codex
+        profile: default
+        cwd: "."
+    edges: []
+
+  - id: review
+    label: Review
+    members:
+      - id: reviewer
+        agent_ref: "local:../../../agents/review/independent-reviewer"
+        runtime: codex
+        profile: default
+        cwd: "."
+    edges: []
+
+  - id: dogfood
+    label: Dogfood
+    members:
+      - id: tester
+        agent_ref: "local:../../../agents/factory-rsi/dogfood"
+        runtime: codex
+        profile: default
+        cwd: "."
+    edges: []
+
+  - id: release
+    label: Release
+    members:
+      - id: manager
+        agent_ref: "local:../../../agents/factory-rsi/release-manager"
+        runtime: claude-code
+        profile: default
+        cwd: "."
+    edges: []
+
+  - id: orch
+    label: Orchestration
+    members:
+      - id: lead
+        agent_ref: "local:../../../agents/orchestration/orchestrator"
+        runtime: claude-code
+        profile: default
+        cwd: "."
+    edges: []
+
+# The orchestrator delegates across the pipeline; review and check can observe
+# the build. Workflow ROUTING is the `factory-rsi` spec's job (the engine
+# routes the loop-close); these edges are topology hints, not the routing.
+edges:
+  - kind: delegates_to
+    from: orch.lead
+    to: plan.planner
+  - kind: delegates_to
+    from: orch.lead
+    to: build.implementer
+  - kind: delegates_to
+    from: orch.lead
+    to: check.qa
+  - kind: delegates_to
+    from: orch.lead
+    to: review.reviewer
+  - kind: delegates_to
+    from: orch.lead
+    to: dogfood.tester
+  - kind: delegates_to
+    from: orch.lead
+    to: release.manager
+  - kind: can_observe
+    from: check.qa
+    to: build.implementer
+  - kind: can_observe
+    from: review.reviewer
+    to: build.implementer

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

@@ -11,7 +11,7 @@ with them and escalate to them when ops decisions need human approval.
   rig**; other rigs require explicit operator-initiated restart.
   When the user says "bring my rigs back online":
   1. List rigs that were running pre-reboot using daemon persisted
-     state (`rig ps --json --all`) and any operator-saved roster.
+     state (`rig ps --json`) and any operator-saved roster.
   2. Confirm with the user which subset to restart.
   3. Restart each via `rig up <spec>` (or `rig restore <snapshot>`
      if a snapshot exists).

package/daemon/specs/rigs/launch/kernel/agents/operator/agent/startup/context.md

@@ -34,7 +34,7 @@ tmux sessions are gone. You own the agent-restart workflow:
 Other rigs (project rigs the user spun up) are NEVER auto-instantiated
 by the daemon. If the user asks you to bring those back:
 
-1. `rig ps --json --all` shows which rigs are persisted but with
+1. `rig ps --json` shows which rigs are persisted but with
    detached sessions.
 2. Confirm with the user which subset to restart.
 3. `rig up <spec>` for cold-start; `rig restore <snapshot> --rig

package/daemon/specs/rigs/preview/product-team/CULTURE.md

@@ -135,3 +135,7 @@ Follow patterns agents already know: docker, git, kubectl, npm.
 ## What this rig is for
 
 This is the advanced product-team lane. Use it when the work needs richer coordination than the conveyor starter. The human sets direction; the team plans, implements, reviews, and surfaces gaps honestly.
+
+## Mission/slice tracking (the SDLC)
+
+Work is tracked as missions and slices — on-disk markdown the Living Notes UI projects. Load the packaged `mission-slice-sop` skill before authoring or building a slice; the conventions (section names, proof contract, the two locks, C1 proof headers) live in `docs/reference/sdlc-conventions.md` (shipped with the CLI package). The short form: record intent → author mini-requirements + a proof contract (→ mockups for UI slices) → plan-lock (`rig scope slice approve --scope spec`) → build the locked set → QA visually compares planned vs delivered → `rig proof add … --evidences --media` drops (the C1 drop verb — never hand-place evidence) → proof-lock (`--scope delivery`). `rig scope audit` is the advisory backstop — fix the flag, don't suppress it.

package/dist/build-info.d.ts

@@ -0,0 +1,8 @@
+export interface BuildInfo {
+    semver: string | null;
+    commit: string | null;
+    dirty: boolean | null;
+    builtAt: string | null;
+}
+export declare const BUILD_INFO: BuildInfo;
+//# sourceMappingURL=build-info.d.ts.map

package/dist/build-info.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"build-info.d.ts","sourceRoot":"","sources":["../src/build-info.ts"],"names":[],"mappings":"AAQA,MAAM,WAAW,SAAS;IACxB,MAAM,EAAE,MAAM,GAAG,IAAI,CAAC;IACtB,MAAM,EAAE,MAAM,GAAG,IAAI,CAAC;IACtB,KAAK,EAAE,OAAO,GAAG,IAAI,CAAC;IACtB,OAAO,EAAE,MAAM,GAAG,IAAI,CAAC;CACxB;AAED,eAAO,MAAM,UAAU,EAAE,SAKxB,CAAC"}

package/dist/build-info.js

@@ -0,0 +1,11 @@
+// GENERATED by scripts/build-package.sh — the packaged build-identity stamp.
+export const BUILD_INFO = {
+  semver: "0.4.6",
+  commit: "8250d702a27aa24bb9acf0b4bef12f58fd83df12",
+  dirty: false,
+  builtAt: "2026-07-09T22:59:04Z",
+};
+export function stampFields(info = BUILD_INFO) {
+  if (!info.commit) return {};
+  return { semver: info.semver, commit: info.commit, dirty: info.dirty, builtAt: info.builtAt };
+}

package/dist/build-info.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"build-info.js","sourceRoot":"","sources":["../src/build-info.ts"],"names":[],"mappings":"AAAA,uDAAuD;AACvD,EAAE;AACF,uEAAuE;AACvE,qEAAqE;AACrE,4EAA4E;AAC5E,6EAA6E;AAC7E,yDAAyD;AASzD,MAAM,CAAC,MAAM,UAAU,GAAc;IACnC,MAAM,EAAE,IAAI;IACZ,MAAM,EAAE,IAAI;IACZ,KAAK,EAAE,IAAI;IACX,OAAO,EAAE,IAAI;CACd,CAAC"}

package/dist/commands/broadcast.d.ts

@@ -1,4 +1,9 @@
 import { Command } from "commander";
 import type { StatusDeps } from "./status.js";
-export declare function broadcastCommand(depsOverride?: StatusDeps): Command;
+import { loadHostRegistry } from "../host-registry.js";
+export interface BroadcastDeps extends StatusDeps {
+    /** Test seam: inject a registry loader so no real ~/.openrig is touched. */
+    hostRegistryLoader?: () => ReturnType<typeof loadHostRegistry>;
+}
+export declare function broadcastCommand(depsOverride?: BroadcastDeps): Command;
 //# sourceMappingURL=broadcast.d.ts.map

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;AAIpC,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,aAAa,CAAC;AAE9C,wBAAgB,gBAAgB,CAAC,YAAY,CAAC,EAAE,UAAU,GAAG,OAAO,CAsEnE"}
+{"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;AAYvF,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,CAiFtE"}