@openrig/cli 0.4.4 → 0.4.7

package/daemon/specs/agents/shared/skills/core/session-source-fork/SKILL.md

@@ -0,0 +1,160 @@
+---
+name: session-source-fork
+description: |
+  Use when authoring a rig spec member or `rig expand` payload that needs to start a new managed seat from a prior runtime conversation source — `session_source: { mode: fork, ref: { kind, value } }`. v1 supports `mode: fork` with `ref.kind: native_id` for Claude and Codex. The new seat persists a NEW post-fork token; the parent token is NEVER written onto the new seat. NOT for restoring an existing seat or for artifact-backed mental-model rebuild.
+metadata:
+  openrig:
+    stage: factory-approved
+    sibling_skills:
+      - claude-compaction-restore
+      - mental-model-ha
+      - scope-recovery
+      - session-compaction-and-restore
+      - agent-startup-and-context-ingestion
+      - agent-starters
+      - composable-priming-packs
+      - seat-continuity-and-handover
+      - claude-compact-in-place
+      - pre-maintenance-agent-preservation
+---
+
+# session_source Fork
+
+`session_source` is a **member-level OpenRig field** that declares how a
+newly-launched managed seat should derive its initial conversation
+continuity from a prior runtime conversation source.
+
+v1 supports one mode: **`fork`** — start a *new* managed seat from a
+prior native runtime conversation source without claiming the original
+seat continued.
+
+The schema is runtime-neutral; implementation is runtime-specific (Claude
+and Codex have their own native fork commands).
+
+## Use this when
+
+- Authoring a rig spec member that should fork from a prior session
+- Authoring a `rig expand` payload with `session_source`
+- Reasoning about whether to use `fork` vs `rebuild` vs `resume` vs `fresh` for a new seat
+- Composing fork + handover (seat-handover-over-fork) — see `seat-continuity-and-handover` skill
+
+## Don't use this when
+
+- The seat is being **restored**, not created. Restore continues an existing managed seat. Fork creates a new seat.
+- The continuity is **artifact-backed mental-model rebuild** (packet-derived understanding, not native runtime continuity). Use `mode: rebuild` (see `seat-continuity-and-handover` for the rebuild surface) — do NOT collapse fork into artifact-backed reentry; the distinction is load-bearing.
+- The runtime is `terminal`. Terminal runtime rejects `session_source`.
+
+## The shape (canonical YAML)
+
+```yaml
+members:
+  - id: reviewer-2
+    runtime: claude-code        # or "codex"; not valid on terminal
+    agent_ref: specs/agents/reviewer.yaml
+    profile: reviewer
+    cwd: .
+    session_source:
+      mode: fork
+      ref:
+        kind: native_id          # v1 fork mode supports native_id only
+        value: "0b0165d7-cb4d-4650-90de-15c0a1ede9e6"
+```
+
+Rules:
+- `mode` v1 only valid value: `fork`.
+- `ref.kind` v1 supports `native_id` only. Schema rejects `artifact_path`, `name`, `last`, and `artifact_set` pre-launch with explicit deferred/weaker/wrong-mode error messages (see `packages/daemon/src/domain/rigspec-schema.ts` validateSessionSourceFork). Adapter-level refusal exists as defensive handling but should not be reachable in v1 because schema rejects first.
+- `value` required for `ref.kind: native_id` in v1 (the only schema-accepted kind). Future-state value semantics for `artifact_path` / `name` / `last` are not active in v1 because schema rejects those kinds pre-launch.
+- `rig expand` accepts the same shape so dynamically-added members can carry session-source attribution.
+
+The primitive does NOT introduce a new top-level command. It flows
+through existing rig spec and expansion pathways.
+
+## State model
+
+`session_source` is a **launch-time input**, not a long-lived stateful field:
+
+1. **Declared** — present in member config or expansion payload
+2. **Resolved** — at launch time, OpenRig resolves the `ref` against the runtime
+3. **Realized** — runtime fork succeeds; new managed seat receives a **NEW** native continuity token (Claude session id or Codex thread id). OpenRig persists that NEW token. **Parent token is NEVER written onto the new seat.**
+4. **Failed** — resolution or fork failed; seat not launched as a fork; clear error names the resolution step that failed
+
+Once realized, `session_source` is essentially history. Restoring the
+seat later is `restore` of the new seat, not re-fork-from-parent.
+
+## Failure modes (5)
+
+1. **Source session id not found** — runtime cannot resolve `native_id`. **Action**: emit error naming runtime + missing id; do NOT silently launch fresh. (Future-state note: when `artifact_path` is supported in a follow-up slice, it could become a candidate fallback for Claude; in v1 schema rejects `artifact_path` pre-launch so no fallback path exists.)
+2. **Source artifact path missing** *(out of v1 scope)* — would apply once `ref.kind: artifact_path` becomes schema-accepted. v1 schema rejects this kind pre-launch.
+3. **Unsupported runtime/kind combination** *(largely pre-empted in v1 by schema rejection)* — schema rejects all non-`native_id` kinds upfront. Adapter-level refusal exists as defensive handling but is not reached in v1.
+4. **Fork launch failed after source resolution** — runtime command (`claude --resume <parent> --fork-session` or `codex fork <id>`) returned non-zero or hung. Preserve runtime stderr; do not record new seat as launched; do not write parent token onto seat.
+5. **Persistence inconsistency** — fork succeeded but seat-token persistence cannot record new continuity token. **Internal failure**: seat is not considered launched until new token is durably written.
+
+## Honest UX rule (verbatim)
+
+The primitive must NOT report "restored the original agent" or "resumed
+the original seat" or "snapshot." The correct framing is **"forked from
+source session"** / **"started from prior conversation source."**
+
+Negative-grep over adapter source confirms ZERO `restored` / `resumed` /
+`snapshot` strings in fork code paths.
+
+## Hard boundaries (do-not list; verbatim)
+
+- **Do NOT introduce a new top-level command** (e.g., `rig fork`). The primitive flows through existing spec/expansion pathways.
+- **Do NOT report "restored" / "resumed the original seat" / "snapshot"** in any UX surface.
+- **Do NOT couple `session_source` to AgentSpec.** It's a member-level launch-time input.
+- **Do NOT change `restore` semantics.** `session_source` creates a seat; `restore` continues an existing managed seat.
+
+## Adapter command shape (shipped v1)
+
+| Runtime | Command shape |
+|---|---|
+| Claude (`mode: fork` + `ref.kind: native_id`) | `claude --resume <parent-id> --fork-session` |
+| Codex (`mode: fork` + `ref.kind: native_id`) | `codex... fork <parent-id>` |
+| Terminal | Rejected at schema level |
+
+Mutual exclusion between `resumeToken` (restore path) and `forkSource`
+(fork path) is enforced at three layers in the daemon.
+
+## Continuity outcome literals
+
+| Outcome | When |
+|---|---|
+| `forked` | Fork succeeded; new seat has new native token; parent never written onto new seat |
+| `fresh` | Fresh launch (no `session_source` declared) |
+| `resumed` | Restore of existing managed seat |
+| `failed` | Resolution or fork failed |
+
+For `seat handover over fork` composition, the binding outcome is
+independent (see `seat-continuity-and-handover` skill).
+
+## Active-daemon caveat (live-runtime gap)
+
+2026-04-30 live scale-out dogfood found: source checkout contained fork
+support, but active daemon was running from a pre-fork commit. **Verify
+the active daemon/runtime commit contains the fork path before live
+proof.** Isolated daemon proof at the target commit can prove the
+feature safely; live forked scale-out remains unproven until the active
+daemon parity is verified.
+
+## Currently shipped (v1) vs deferred
+
+Shipped at openrig `c7b6df1` (2026-04-30):
+- Schema accept/reject for full Honest Refusal Matrix
+- Codec roundtrip (serialize → parse → normalize preserves `session_source` faithfully)
+- Expansion path through `rig expand` member-input
+- Adapter command shape for Claude + Codex `native_id`
+- Persistence honesty (seat's `resume_token` is the NEW post-fork token; parent token NEVER written)
+- Honest UX literal contract (`continuityOutcome: forked`)
+
+Deferred:
+- Tier 2 real-runtime fork proof (disposable Tart VM cycle, human-gated)
+- Claude `artifact_path` mode (schema currently refuses with deferred message)
+- Provenance columns (`parent_native_id` / `created_via` for queryable RSI consumer)
+- Cross-host fork (source on host A, new seat on host B) — depends on `cross-host-rig-commands`
+
+## See also
+
+- `seat-continuity-and-handover` skill — sibling occupant-creation primitives (resume / fork / rebuild / fresh) + seat-binding (handover composes with fork)
+- `agent-starters` skill — composes session_source fork into named reusable starting points
+- `cross-host-rig-commands` skill — multi-host fork (deferred)

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

@@ -0,0 +1,103 @@
+---
+name: specification-system
+description: Use when authoring rig specs, agent specs, workflow specs, startup/context fragments, operating-mode declarations, or designing the user spec library. Covers the 4 failure modes (spec instantiates topology but not workflow/mode; spec depends on local paths and fails on another host; agents modify specs as one-off files instead of preserving reusable intent; validation proves YAML shape but not whether topology can run) and the validation-vs-runtime-realization distinction.
+metadata:
+  cli_surfaces_referenced:
+    - agent
+    - bundle
+    - spec
+    - specs
+  openrig:
+    stage: factory-approved
+    sibling_skills:
+      - rig-lifecycle
+      - topology-mutation-and-seat-management
+      - seat-scaling-and-specialization
+      - cross-host-rig-commands
+      - sidecar-operator
+      - rig-bundles-and-shareable-artifacts
+      - extension-and-user-workspace
+---
+
+# Specification System
+
+The declarative primitive family for OpenRig intent: **rig specs, agent
+specs, workflow specs, startup/context fragments, operating-mode
+declarations, and the user spec library that stores and reuses them.**
+
+Specs are how humans and agents describe **repeatable topology and
+behavior** without re-explaining it in chat. They are also shareable
+artifacts: a user should be able to publish a spec or spec family so
+another user can instantiate the same rig shape, role structure, or
+workflow pattern.
+
+**Without a dependable spec primitive, OpenRig depends on manual
+startup prompts and tribal memory.** That blocks repeatability, product
+demos, rig bundles, and autonomous rig construction.
+
+## Use this when
+
+- Authoring a RigSpec / AgentSpec / workflow spec
+- Designing a startup/context fragment
+- Reasoning about spec-library lifecycle (validation, sharing, upgrade semantics)
+- Auditing a spec for portability (does it run on another host?)
+- Distinguishing spec vs bundle vs extension cleanly
+
+## Don't use this when
+
+- The work is one-off and won't be reused. Manual rig assembly is fine for one-shot work.
+- The intent is to package a topology + workflow as a shareable artifact. That's `rig-bundles-and-shareable-artifacts`.
+- The intent is to add runtime behavior. That's `extension-and-user-workspace`.
+
+## Failure modes (4)
+
+1. **A spec can instantiate a topology but not the workflow or operating mode needed to use it.** Topology is necessary but not sufficient — workflow and operating mode must be declared too.
+2. **A shared spec depends on local paths or hidden startup fragments and fails on another host.** Specs must be self-describing for portability.
+3. **Agents modify specs as one-off files instead of preserving reusable user/library intent.** Specs are reusable; treating each instance as one-off destroys the primitive's value.
+4. **Validation proves YAML shape but not whether the declared topology can actually run.** Structural validation is not enough; runtime realization is the real proof.
+
+## Proof standard
+
+Proof should:
+
+1. Author a spec
+2. Validate it (structural)
+3. Install it (into spec library)
+4. Instantiate it on a **clean OpenRig environment**
+5. Show **both structural validation AND runtime realization**
+
+Validation alone is insufficient.
+
+## Spec / bundle / extension boundary
+
+| Concept | Declares | Example |
+|---|---|---|
+| **Spec** | Topology / role / workflow shape (declarative intent) | `rig.yaml`, `agent.yaml`, `workflow.yaml` |
+| **Bundle** | Spec(s) + supporting fragments packaged for shareable instantiation | A Velocity Team bundle |
+| **Extension** | Runtime behavior added to user workspace | RigX command, custom view |
+
+Don't conflate them. The contract should distinguish spec, bundle, and
+extension cleanly.
+
+## Currently shipped surfaces
+
+OpenRig already has:
+
+- RigSpec / AgentSpec authoring (`agent.yaml`, `rig.yaml` formats; see `openrig-architect` skill)
+- Workflow specs (markdown/YAML files, daemon read-through cache via `workflow_specs` table; see `workflow-runtime` skill)
+- Bundle/spec command surface (`rig bundle / spec / agent / specs ls/show/preview/add/sync/remove/rename`)
+- Spec library (filesystem-backed at `packages/daemon/specs/` + `~/.openrig/specs/` per cli-reference.md)
+
+Not yet shipped:
+- Spec library lifecycle (validation, sharing, upgrade) treated as a first-class primitive
+- Cross-host spec sharing
+- Marketplace / public registry
+
+## See also
+
+- `openrig-architect` skill — RigSpec / AgentSpec authoring discipline
+- `workflow-runtime` skill — workflow spec authoring + transactional-scribe contract
+- `rig-bundles-and-shareable-artifacts` skill — bundle is the packaged form of specs
+- `extension-and-user-workspace` skill — extensions add runtime behavior; specs declare intent
+- `openrig/docs/reference/rig-spec.md` (product reference doc) — RigSpec format specification
+- `openrig/docs/reference/agent-spec.md` (product reference doc) — AgentSpec format specification

package/daemon/specs/agents/shared/skills/core/topology-mutation-and-seat-management/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: topology-mutation-and-seat-management
+description: Use when changing a rig while it is alive — `rig expand` / `rig shrink` / `rig launch` / `rig remove` / `rig discover` / `rig bind` / `rig adopt` / `rig attach`. Covers the 4 failure modes (newly created seat lacks queue/startup/role; edges and permissions not updated; adopt/bind succeeds at tmux but not OpenRig identity; shrink/remove leaves stale topology references) and the rule that mutation must work while the rig is active, not just in clean fixtures.
+metadata:
+  cli_surfaces_referenced:
+    - adopt
+    - attach
+    - bind
+    - discover
+    - expand
+    - launch
+    - ps
+    - release
+    - remove
+    - shrink
+    - unclaim
+    - up
+    - whoami
+  openrig:
+    stage: factory-approved
+    sibling_skills:
+      - rig-lifecycle
+      - seat-scaling-and-specialization
+      - cross-host-rig-commands
+      - sidecar-operator
+      - rig-bundles-and-shareable-artifacts
+      - specification-system
+      - extension-and-user-workspace
+---
+
+# Topology Mutation and Seat Management
+
+The ability to change a rig **while it is alive**: expand, shrink,
+launch, remove, discover, bind, adopt, and attach seats or sessions.
+Seat management includes the **stable identifiers, edges, roles, and
+startup context** that make those mutations coherent.
+
+**OpenRig should be easy to reach for.** A user should be able to add
+capacity, retire capacity, adopt an existing session, or attach a
+terminal **without rebuilding the whole topology.** If mutation is
+rarely tested, users avoid it and the product collapses back into
+static launch scripts.
+
+## Use this when
+
+- Adding capacity to a running rig (`rig expand <rig> <pod-fragment-path>`)
+- Removing capacity (`rig shrink` / `rig remove`)
+- Launching/relaunching a node in a running rig (`rig launch`)
+- Binding a discovered session into an existing logical node (`rig bind`)
+- Adopting a topology + binding live sessions (`rig adopt`)
+- Attaching a shell or agent into a rig node (`rig attach --self`)
+
+## Don't use this when
+
+- The rig is being created fresh from scratch — use `rig up` (lifecycle, not mutation)
+- The intent is to scale specifically (add specialized capacity) — use `seat-scaling-and-specialization` skill
+- The intent is occupant replacement on a stable seat — use `seat-continuity-and-handover` skill
+
+## Failure modes (4)
+
+1. **A newly created seat lacks the queue, startup context, or role files it needs to operate.** Topology mutation creates the seat, but the seat needs more than a tmux session to be useful.
+2. **Edges and permissions are not updated when a seat is added or removed.** Topology references go stale; later workflows route to nonexistent seats.
+3. **Adopt/bind succeeds at the tmux/session layer but not at the OpenRig identity layer.** The session is attached but `rig whoami` doesn't know about it; downstream consumers see partial state.
+4. **Shrink/remove leaves stale topology references that later workflows route into.** Cleanup is part of the operation, not an afterthought.
+
+## Proof standard
+
+Proof must cover **mutation while a rig is active**, not just in a
+clean test fixture. The useful matrix:
+
+| Operation | What to verify |
+|---|---|
+| Add seat | New seat has queue, startup context, role; `rig whoami` resolves it |
+| Remove seat | Stale references cleaned; edges/permissions updated |
+| Adopt existing session | tmux session bound at OpenRig identity layer; `rig whoami` reports correctly |
+| Attach observer terminal | External CLI attachment recorded |
+| Verify topology projections after each move | `rig ps --nodes` reflects current truth, not pre-mutation cache |
+
+A clean-fixture proof is necessary but not sufficient. Live-rig proof
+catches the failure modes that fixture-mode misses.
+
+## Why important strategically
+
+The current coordination experiments repeatedly need new queues,
+watchdogs, humans, and test seats — which makes this family
+**strategically important.** Seat continuity work will eventually
+separate stable seat identity from runtime occupant identity (see
+`seat-continuity-and-handover`).
+
+## Currently shipped surfaces
+
+Per `cli-reference.md` v0.2.0:
+
+- `rig expand <rig-id> <pod-fragment-path>` (with optional `session_source`)
+- `rig shrink <rigId> <podRef>`
+- `rig launch <rigId> <nodeRef>`
+- `rig remove <rigId> <nodeRef>`
+- `rig discover [--draft]`
+- `rig bind <discoveredId> --rig <rigId> (--node <id> | --pod <ns> --member <name>)`
+- `rig adopt <path> --bind <logicalId=tmuxSessionOrDiscoveryId>`
+- `rig attach --self --rig <rigId> --node <logicalId>`
+- `rig unclaim <sessionRef>` / `rig release <rigId>`
+
+## Active proof gap (current)
+
+The 2026-04-30 topology mutation add-seat proof pass is **active**.
+Product Lab shaped it; planner authored `IMPLEMENTATION.md`; driver
+landed the smallest honest CLI retry-guidance patch for failed
+`rig expand` recovery. **Remaining proof is the Section B disposable-rig
+runtime matrix, blocked on operator posture** and owned by
+`orch-lead@your-rig`.
+
+## See also
+
+- `openrig-user` skill — CLI surface for `rig expand / shrink / launch / remove / bind / adopt / attach`
+- `seat-scaling-and-specialization` skill — when to add specialized capacity vs generic
+- `seat-continuity-and-handover` skill — replacing an occupant on a stable seat (different shape than topology mutation)
+- `cross-host-rig-commands` skill — cross-host topology mutation (deferred)

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

@@ -0,0 +1,125 @@
+---
+name: watchdog
+description: Use when configuring `rig watchdog` policies, authoring wake/refocus/alignment-checkpoint messages, or choosing the right intervention level for a stale-owner situation. The 3-level continuity-check stack (wake / refocus / alignment-checkpoint), the discipline that prevents cadence pollution and bureaucracy theater, and the artifact-pool loop-edge pattern for evidence-aware waking.
+metadata:
+  openrig:
+    stage: factory-approved
+    sibling_skills:
+      # Sibling sweep 2026-07-19 audit: superseded control-plane-* family
+      # dropped (control-plane-watchdog now redirects HERE); kept the
+      # genuinely adjacent set.
+      - queue-handoff
+      - workflow-runtime
+      - alignment-trace
+      - looping-workflows
+      - intake-routing
+      - human-in-the-loop
+      - status-not-chat-orchestrator
+---
+
+# Watchdog
+
+Continuity checks are timed or evidence-triggered interventions that
+keep an agent workflow from going idle, drifting, or entering needless
+bureaucracy. They operationalize the alignment-trace doctrine.
+
+## Use this when
+
+- **Authoring a watchdog policy** for a long-running rig (artifact-pool
+  edges, stale-owner detection, periodic reminders).
+- **Choosing the intervention level** for a stale-owner situation: is
+  this a wake, a refocus, or an alignment checkpoint?
+- **Drafting wake/refocus/alignment-checkpoint message text** that
+  prevents cadence pollution and bureaucracy theater.
+- **Deciding cadence** — scan vs wake intervals, conservative vs
+  aggressive nudging.
+
+## Don't use this when
+
+- The agent is actively working and closing artifacts. Prefer no-op.
+- The intervention is masking bad startup or workflow design — fix the
+  underlying cause, don't compensate via watchdog.
+- The work has a clear next-action handoff already in queue. Use queue
+  nudges instead of a watchdog policy.
+
+## The 3-level intervention stack
+
+| Level | Goal | When | What it does |
+|---|---|---|---|
+| **Wake** | Restart motion | Owner appears idle, stale, blocked, or missing a next handoff | Small liveness nudge — does NOT reframe the work |
+| **Refocus** | Correct drift | Output shows mode drift, approval regression, weak stop-condition reasoning | Medium alignment nudge — re-centers on role, north star, current approved workstream, coordination mode, stop conditions; does NOT interrupt valid work |
+| **Alignment checkpoint** | Rebuild shared map | Phase boundary, lifecycle mutation, product-intent decision, confusing contradiction | Larger deliberate pause — agent runs full alignment-trace before proceeding |
+
+`cron`, timers, and `rig watchdog` are scheduling substrates. They
+should NOT imply that every tick means the same semantic action. The
+intervention level is chosen by evidence, not cadence.
+
+## Current best practice for refocus message text
+
+A well-shaped refocus message:
+
+- Starts with: **finish current action first**.
+- Names the intervention kind: wake, refocus, or alignment checkpoint.
+- Names the current approved workstream or says none is known.
+- Says what continuity means: continue, verify, hand off, or explicitly park.
+- Names stop conditions: scope/risk/posture changes, failed gate, contradictory evidence, or no continuity chain naming a sensible next step.
+- Does NOT convert itself into a fresh approval gate.
+- Does NOT wake delivery seats unless an approved workflow exists and the owner is stale.
+
+## Failure modes (7; verbatim)
+
+1. Cadence is too frequent and pollutes the workstream.
+2. Watchdog wakes the wrong seat instead of the stale owner.
+3. Refocus text is too rule-shaped and creates brittle behavior.
+4. Watchdog compensates for bad startup or workflow design instead of revealing it.
+5. Refocus is misread as a new top-priority task and interrupts the current action.
+6. Refocus becomes bureaucracy theater: an already-approved workflow stops for re-approval.
+7. Repeated static nudges teach agents to answer the reminder instead of progressing the artifact.
+
+## Artifact-pool loop edges (the first evidence-aware pattern)
+
+The first evidence-aware watchdog use that should remain small and
+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.
+
+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) |
+
+Daemon `rig watchdog` is the active host coordination surface for new
+work. History records only loud evaluations (`sent` / `terminal`);
+quiet skip reasons are NOT recorded — POC parity so agents are not
+woken about scheduler polls.
+
+## Future shape (current limit)
+
+The mature primitive should be evidence-aware: inspect durable
+queue/workflow state, pane activity, transcript/context growth, and
+known workstream frontier; classify the intervention as no-op / wake /
+refocus / alignment-checkpoint; prefer no-op for active owners; render
+message text from the active orientation graph instead of hard-coding
+static policy.
+
+Until queue substrate, activity state, and lifecycle evidence are fully
+productized at this level of granularity: keep config-layer use small
+and explicit, prefer one workflow watchdog plus targeted exception
+handling over many per-seat nag loops.
+
+## See also
+
+- `alignment-trace` skill — the doctrine this primitive operationalizes; full and light trace templates
+- `queue-handoff` skill — durable handoff via queue items; watchdog is complementary (watchdog wakes; queue routes)
+- `looping-workflows` skill — operating discipline for self-driving rig-shaped loops; uses watchdog policies for loop edges

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

@@ -10,9 +10,9 @@ 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`. 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).
+1. Load `using-superpowers`, `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 -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.
+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.
 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` (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).
+- **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).
 - **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.
@@ -45,7 +45,7 @@ The orchestration pod is responsible for:
   - **Self-test:** "Does this read return more than the decision in front of me needs?" If yes, narrow it before running.
 - **A watchdog turn is small:** tiny queue/frontier check → make exactly the needed durable transition or wake → park. Not a fleet-wide scan per wake.
 
-**Close-monitoring — legitimate exception, deliberate + BOUNDED.** Some moments warrant tight/continuous attention — a seat doing something high-stakes, novel, or fragile where you may need to feed context, hand-hold, or intervene fast; a delicate gate; a recovery in flight. Switch in **on purpose** on a nameable trigger; **exit the instant the condition clears** (time- *and* event-bounded); don't let it bleed into steady-state. Worked example (slice-17): close through compaction-recovery / QA-runtime-proof / merge-gate; back off to queue+watchdog once the owner is active + the qitem in-progress. The anti-pattern is not tight monitoring — it's **unbounded** tight monitoring (an ambient sleep-loop with no nameable end-condition). That is what burns the shared account.
+**Close-monitoring — legitimate exception, deliberate + BOUNDED.** Some moments warrant tight/continuous attention — a seat doing something high-stakes, novel, or fragile where you may need to feed context, hand-hold, or intervene fast; a delicate gate; a recovery in flight. Switch in **on purpose** on a nameable trigger; **exit the instant the condition clears** (time- *and* event-bounded); don't let it bleed into steady-state. Worked example: close through compaction-recovery / QA-runtime-proof / merge-gate; back off to queue+watchdog once the owner is active + the qitem in-progress. The anti-pattern is not tight monitoring — it's **unbounded** tight monitoring (an ambient sleep-loop with no nameable end-condition). That is what burns the shared account.
 
 ### B. Intervention — correct + re-teach, don't silently substitute
 When you DO catch a dropped potato, your default is to **teach the agent the protocol, not do it for them.** Agents load the hot-potato / queue-handoff protocol and are supposed to hand off on their own; you are the **belt-and-suspenders** for when one doesn't (skill not loaded, fell out of context, or just got it wrong).

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

@@ -7,6 +7,9 @@ description: Complete operating manual for the review pod. Covers everyday revie
 
 You are part of the review pod. Your value is fresh scrutiny that implementation and QA do not have.
 
+## Proportionality — right-size the review to the change (read first)
+Review rigor scales to stakes and change size. A small, low-stakes diff gets a fast, focused pass; the full deep protocol (context proof, confidence scores, independent → cross-exam → convergence → roundtable) is for architecture / security / high-blast-radius changes. Don't run the heavy machinery on a one-line fix — that's ceremony, and it delays the ship it exists to protect. Catch what matters, then let good work through. The point of review is **better product shipped, not review performed.**
+
 ## Startup sequence
 
 Before you announce a review position:

package/daemon/specs/agents/shared/skills/process/brainstorming/OPENRIG.md

@@ -21,13 +21,13 @@ openrig-relationship: vendored-modified
 |---|---|---|
 | Visual Companion offer step | Standalone step #2 in the flow — "offer Visual Companion in its own message before clarifying questions" | **Removed.** OpenRig agents typically operate without a separate visual-companion mode; visual design work routes through dedicated design-pod seats. |
 | Spec self-review step | Step #7 — inline self-review for placeholders/contradictions/scope | **Removed.** Self-review is handled at the rig/orchestration layer (driver/guard pattern + review-lead). |
-| User reviews written spec | Step #8 — pause for user to review the spec file | **Removed.** OpenRig's founder-walk and orchestration gates already cover this checkpoint at a higher level. |
+| User reviews written spec | Step #8 — pause for user to review the spec file | **Removed.** OpenRig's the operator-walk and orchestration gates already cover this checkpoint at a higher level. |
 | Spec save path | `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` | `docs/plans/YYYY-MM-DD-<topic>-design.md` (matches OpenRig's `docs/plans/` convention) |
 | Process flow diagram | Includes Visual Companion + Spec self-review nodes | Simplified to remove those nodes; edges rewired |
 
 ## Why these modifications (inferred)
 
-- **Multi-platform / multi-step gates removed**: OpenRig's rig-level orchestration (driver → guard → qa, founder-walks) already provides the checkpoint structure that the upstream skill builds inline. Keeping those steps inside the skill double-gates the work.
+- **Multi-platform / multi-step gates removed**: OpenRig's rig-level orchestration (driver → guard → qa, the operator-walks) already provides the checkpoint structure that the upstream skill builds inline. Keeping those steps inside the skill double-gates the work.
 - **`docs/plans/` path**: OpenRig's project structure uses `docs/plans/` as the canonical home for design + implementation plan documents (matches `writing-plans` modification — both are co-ordinated).
 
 ## Companion files
@@ -44,5 +44,5 @@ Watch upstream for:
 When upstream changes:
 
 1. Pull non-conflicting changes into the OpenRig copy.
-2. Preserve the simplified 6-step flow and the `docs/plans/` save path unless founder direction reverses.
+2. Preserve the simplified 6-step flow and the `docs/plans/` save path unless operator direction reverses.
 3. Bump `last_upstream_check` in `SKILL.md` frontmatter.

package/daemon/specs/agents/shared/skills/process/executing-plans/OPENRIG.md

@@ -50,7 +50,7 @@ Watch for upstream changes to:
 When upstream changes:
 
 1. Pull non-conflicting changes into the OpenRig copy.
-2. Preserve the batch-with-checkpoint structure unless founder direction reverses.
+2. Preserve the batch-with-checkpoint structure unless operator direction reverses.
 3. Re-check that the subagent-alternative pointer hasn't crept back in.
 4. Bump `last_upstream_check` in `SKILL.md` frontmatter.
 5. Note any structural shape changes in `divergence_notes`.

package/daemon/specs/agents/shared/skills/process/frontend-design/SKILL.md

@@ -4,9 +4,12 @@ description: Create distinctive, production-grade frontend interfaces with high
 license: Complete terms in LICENSE.txt
 metadata:
   openrig:
-    vendored_from: "Anthropic skills (Apache 2.0; see LICENSE.txt sibling)"
-    vendoring_pattern: vendored-as-is
-    last_upstream_check: "2026-05-13 (diff against ~/.claude/skills/frontend-design = identical)"
+    stage: factory-approved
+    license_status: "see LICENSE.txt — vendor-derived; license terms apply"
+    vendored_from: "unknown vendor — LICENSE.txt present at copy time; quarterly license review"
+    sibling_skills:
+      - shadcn
+      - remotion-best-practices
 ---
 
 This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.

package/daemon/specs/agents/shared/skills/process/test-driven-development/SKILL.md

@@ -16,7 +16,7 @@ Write the test first. Watch it fail. Write minimal code to pass.
 
 **Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing.
 
-**Violating the letter of the rules is violating the spirit of the rules.**
+**A strong default in service of shipping — not a law that outranks it.** TDD earns its keep where a failing test pins down behavior you'd otherwise get wrong: core logic, contracts, tricky edge cases. Match it to stakes — reach for it where test-first genuinely de-risks the change; throwaway prototypes, one-line copy tweaks, and obvious glue don't need the ceremony. Don't dodge it with synonyms; equally, don't let it block you from shipping the working thing.
 
 ## When to Use
 

package/daemon/specs/agents/shared/skills/process/using-superpowers/OPENRIG.md

@@ -44,5 +44,5 @@ Watch upstream for:
 When upstream changes:
 
 1. Pull non-conflicting changes into the OpenRig copy.
-2. Do NOT re-introduce the multi-platform sections, SUBAGENT-STOP block, or Instruction Priority section unless founder direction reverses.
+2. Do NOT re-introduce the multi-platform sections, SUBAGENT-STOP block, or Instruction Priority section unless operator direction reverses.
 3. Bump `last_upstream_check` in `SKILL.md` frontmatter.