@openrig/cli 0.1.12 → 0.3.0

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

@@ -0,0 +1,153 @@
+---
+name: openrig-user-settings
+description: Use when the user asks an OpenRig agent to read or change OpenRig configuration settings — workspace paths, file allowlists, progress scan roots, daemon port/host, transcripts, or anything stored in ~/.openrig/config.json
+---
+
+# OpenRig User Settings
+
+OpenRig settings live in `~/.openrig/config.json` and are managed via the
+`rig config` CLI family. The agent-editable surface is **CLI shell-out**;
+do NOT write the JSON file directly unless the operator specifically asks
+for raw-text editing (which is handled by the UI Files browser, not by you).
+
+## Read
+
+```bash
+rig config                                # all keys, value + source
+rig config --json                         # JSON: full RiggedConfig
+rig config --json --with-source           # JSON: {key: {value, source, default}}
+rig config get <key>                      # single value
+rig config get <key> --show-source        # value + source on one line
+rig config get <key> --json               # {value, source, default}
+```
+
+Resolution order: **env var > config file > default**. Always use
+`--show-source` (or `--json`) when reporting back to the operator so they
+see *where* the value came from.
+
+## Write
+
+```bash
+rig config set <key> <value>              # set a key
+rig config reset <key>                    # clear one override (revert to default)
+rig config reset                          # delete the whole file
+```
+
+## Initialize a default workspace
+
+```bash
+rig config init-workspace                 # scaffold ~/.openrig/workspace/ with missions + slices
+rig config init-workspace --dry-run       # show what would be created
+rig config init-workspace --root /path    # use a custom root
+rig config init-workspace --force         # overwrite scaffolded files (NOT operator content)
+```
+
+This creates a file-backed Project workspace under the workspace root:
+
+```text
+README.md
+STEERING.md
+missions/<mission-id>/README.md
+missions/<mission-id>/PROGRESS.md
+missions/<mission-id>/slices/<slice-id>/README.md
+progress/
+field-notes/
+specs/
+```
+
+It seeds two starter missions with multiple slices so the Project UI has a
+real mission/slice map out of the box. It is operator-explicit; do NOT run it
+on your own initiative unless the operator asks for workspace initialization
+or repair.
+
+## Common keys
+
+| Key | Type | Purpose |
+|---|---|---|
+| `daemon.port` | number | OpenRig daemon HTTP port (default 7433) |
+| `daemon.host` | string | Daemon bind host (default 127.0.0.1) |
+| `db.path` | string | SQLite DB path (default ~/.openrig/openrig.sqlite) |
+| `transcripts.enabled` | boolean | Whether the daemon writes transcripts |
+| `transcripts.path` | string | Transcripts dir (default ~/.openrig/transcripts) |
+| `workspace.root` | string | Single-root override (default ~/.openrig/workspace) |
+| `workspace.slices_root` | string | Slice discovery root; default `<root>/missions` |
+| `workspace.steering_path` | string | STEERING.md path; default `<root>/STEERING.md` |
+| `workspace.field_notes_root` | string | Field notes dir; default `<root>/field-notes` |
+| `workspace.specs_root` | string | Specs dir; default `<root>/specs` |
+| `files.allowlist` | string | `name:/abs/path,name:/abs/path` — UI Files browser roots |
+| `progress.scan_roots` | string | `name:/abs/path,name:/abs/path` — Progress browse roots |
+
+Resolution order for workspace per-subdir keys: per-subdir override >
+`workspace.root` cascade > built-in default.
+
+## Common operator requests → canonical commands
+
+> **"Make the UI work against an existing workspace layout"**:
+> set the per-subdir workspace overrides explicitly:
+>
+> ```bash
+> rig config set workspace.slices_root /Users/me/code/substrate/.../missions
+> rig config set workspace.steering_path /Users/me/code/substrate/openrig-work/STEERING.md
+> rig config set workspace.progress_scan_roots 'work:/Users/me/code/substrate/openrig-work,missions:/Users/me/code/substrate/openrig-work/missions'
+> rig config set workspace.field_notes_root /Users/me/code/substrate/openrig-work/field-notes
+> ```
+>
+> No restart needed for the CLI; for the daemon's reads to pick up
+> changes affecting startup-time wiring (`files.allowlist`,
+> `progress.scan_roots`), restart with `rig daemon restart`.
+
+> **"Initialize a default workspace"**:
+>
+> ```bash
+> rig config init-workspace
+> ```
+
+After initialization, the Project UI expects this mapping:
+
+- `workspace.root` maps to the Project workspace.
+- `workspace.root/missions/<mission-id>` maps to a Project mission.
+- `workspace.root/missions/<mission-id>/slices/<slice-id>` maps to a Project slice.
+
+Queue item bodies or tags should mention the mission id and slice id when the
+work belongs to a slice. That lets the Project Story, Queue, Tests, and
+Topology tabs attach runtime work to the filesystem slice.
+
+> **"Allow the file browser to see X directory"**:
+>
+> ```bash
+> # Append to existing list (operator decides the name token):
+> rig config get files.allowlist --show-source       # check current
+> rig config set files.allowlist 'workspace:/path/to/ws,docs:/path/to/docs'
+> rig daemon restart                                # picks up new roots
+> ```
+
+> **"What's my current setting for X and where does it come from?"**:
+>
+> ```bash
+> rig config get <key> --show-source
+> ```
+
+## When NOT to use this skill
+
+- **Per-rig config** — settings are host-global at v0; per-rig is v0+1.
+- **Secrets / credentials** — the `vault.specialist` managed-app handles
+  secrets. Don't put API keys or tokens in `~/.openrig/config.json`.
+- **Settings sync across hosts** — out of scope at v0.
+
+## Errors you might see
+
+- `Unknown config key "<x>". Valid keys: …` — the key name is wrong.
+  Check the table above; suggest the correct key.
+- `Config file at <path> is malformed. Fix the JSON or reset with: rig config reset` —
+  hand-edit broke the JSON. Operator can `rig config reset` (deletes the
+  whole file) or fix the syntax in the Files browser.
+- `Invalid value for <key>: expected a number/true-false, got "<x>"` —
+  wrong type for a typed key. Reach for the key's type in the table.
+
+## Provenance + safety
+
+- Never write to `~/.openrig/config.json` directly. Use `rig config set`.
+- Don't run `rig config init-workspace` on your own initiative — wait for
+  an operator request.
+- Always cite the resolved source (env / file / default) when reporting
+  values back, so the operator knows whether their change actually took.

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

@@ -183,6 +183,7 @@ For destructive operations (git push, rm, daemon stop, npm publish): DO NOT auto
 - After being told to slow down, over-corrects to "wait for permission for everything"
 - Compaction is catastrophic — full context loss, needs preparation
 - After compaction: must re-read ALL skills from disk (skill names survive in system reminders but content is truncated)
+- For Claude compact-in-place, use `claude-compact-in-place` and require marshal acceptance before treating a `RESTORED` claim as real
 
 ### Codex agents (QA, peer, R2)
 - Self-manages its own context window — do NOT intervene based on context percentage
@@ -221,6 +222,8 @@ Before any destructive operation: "If this goes wrong, can I undo it?" If no, co
 4. Read your restore file and session log if available
 5. Ask your peer for a quiz to verify your mental model
 
+For Claude Code seats in OpenRig, marshals/orchestrators should use `claude-compact-in-place` for the asked-vs-read-depth audit before accepting recovery. Preserve the Codex boundary: do not intervene on Codex context percentage or apply Claude compact-in-place by default.
+
 ## What you do not do
 
 - write production code just because it would be faster

package/daemon/specs/agents/shared/skills/rig-architect/SKILL.md

@@ -33,11 +33,21 @@ Load these before starting any design work. The quality of your output depends o
    - `implementation-pair` — the smallest effective development unit (2 agents)
    - `secrets-manager` — a managed-app rig with services integration and a specialist agent
 
+**Read if present on this host:**
+
+4. **Host-level doctrine** at `~/code/substrate/shared-docs/HOST-TOPOLOGY.md` (or wherever substrate lives on this host). If this file exists, it supersedes the baseline process below for complex or high-stakes rigs. Specifically:
+   - §3 defines the canonical rig classes (kernel, project, ephemeral, infra-build, managed-app). Classify before designing.
+   - §4 defines context-sharing patterns (pods as context domains, pair pattern, continuity via seat handoff records and substrate session logs, terminal nodes as common-room, chatroom/substrate/transcripts/Corpus).
+   - **§7 is the canonical 12-step rig-spec authoring SOP for high-stakes rigs — use it instead of the baseline "Design Process" below when the rig is ≥4 members, uses HA, is a managed-app, or will be shared/copied.** The baseline below still applies to small/focused rigs.
+   - §10 contains the host's bootstrap sequence so you know where your new rig fits.
+   - §12 has the naming canon and vocabulary mapping to shipped terms.
+5. **Building-agent-software skill** at `~/code/substrate/shared-docs/skills/building-agent-software/` if present. Design principles for agent-facing tools and surfaces. Relevant when your rig ships a new CLI, service, or managed app.
+
 **Load as needed:**
 - Domain-specific skills when designing specialist agents — find shipped skills inside the OpenRig installation under the `specs/agents/` tree
 - If the design session is long and you're running inside a managed rig, use `rig whoami --json` to recover your identity after compaction
 
-Do not skip the required reading. A rig architect who doesn't know the spec format will produce specs that don't validate. An architect who doesn't know the startup layering model will produce agents that boot without knowing their role.
+Do not skip the required reading. A rig architect who doesn't know the spec format will produce specs that don't validate. An architect who doesn't know the startup layering model will produce agents that boot without knowing their role. An architect who doesn't check for host-level doctrine will reinvent conventions the host has already established.
 
 ## The Design Process
 

package/daemon/specs/rigs/launch/conveyor/CULTURE.md

@@ -0,0 +1,34 @@
+# Conveyor Culture
+
+Conveyor is the small public starter for learning OpenRig workflow motion.
+It is intentionally ordinary: one intake lead, one planner, one builder, and
+one reviewer moving queued work through a clear handoff path.
+
+## Responsibilities
+
+- Keep every handoff explicit in the queue.
+- Treat queue depth as the backpressure signal.
+- Prefer small packets that can move from intake to review without extra
+  coordination ceremony.
+- Use review feedback to improve the next build packet instead of hiding
+  defects in chat.
+- Close terminal work with honest closure evidence.
+
+## Principles
+
+- The workflow is a teaching rig, not a private release factory.
+- Runtime primitives stay generic: queue, workflow, watchdog, project, proof,
+  and topology surfaces should all make sense without special background.
+- A user should be able to run multiple conveyor packets at once and understand
+  why one station has a deeper queue than another.
+- If a packet is blocked, the owner records the blocker and target instead of
+  silently waiting.
+
+## Operating Notes
+
+- The `conveyor` workflow is the default station pipeline.
+- The `basic-loop` workflow is a slower walkthrough for watching one packet
+  move end to end.
+- The review seat may route follow-up work back to the build seat by ordinary
+  queue handoff when rework is needed. The default workflow pass path moves
+  review to close.

package/daemon/specs/rigs/launch/conveyor/README.md

@@ -0,0 +1,33 @@
+# Conveyor Starter
+
+Conveyor is the OpenRig 0.3.0 starter rig for learning queue handoffs and
+workflow instances.
+
+## Run
+
+```bash
+rig up conveyor
+```
+
+## Workflows
+
+- `conveyor`: station pipeline. Multiple packets can be active at once.
+- `basic-loop`: single-work-item walkthrough for watching one packet move
+  through the same seats.
+
+## Sample Objective
+
+Use this as a first packet:
+
+```text
+Draft a tiny release-readiness checklist for a command-line tool. Keep it to
+five checks and include one verification command.
+```
+
+Expected motion:
+
+1. `intake-lead@conveyor` clarifies the packet and hands it to planning.
+2. `plan-planner@conveyor` turns it into a small plan.
+3. `build-builder@conveyor` drafts the checklist.
+4. `review-reviewer@conveyor` checks the result.
+5. `intake-lead@conveyor` closes the packet with evidence.

package/daemon/specs/rigs/launch/conveyor/rig.yaml

@@ -0,0 +1,72 @@
+version: "0.2"
+name: conveyor
+summary: >
+  Launch-grade starter for OpenRig 0.3.0: a compact station pipeline with
+  intake, planning, build, and review seats. Use it to watch queued work move
+  through handoffs without inheriting any internal release coupling.
+
+culture_file: CULTURE.md
+
+pods:
+  - id: intake
+    label: Intake
+    members:
+      - id: lead
+        agent_ref: "local:../../../agents/conveyor/lead"
+        runtime: claude-code
+        profile: default
+        cwd: "."
+    edges: []
+
+  - id: plan
+    label: Planning
+    members:
+      - id: planner
+        agent_ref: "local:../../../agents/conveyor/planner"
+        runtime: codex
+        profile: default
+        cwd: "."
+    edges: []
+
+  - id: build
+    label: Build
+    members:
+      - id: builder
+        agent_ref: "local:../../../agents/conveyor/builder"
+        runtime: claude-code
+        profile: default
+        cwd: "."
+    edges: []
+
+  - id: review
+    label: Review
+    members:
+      - id: reviewer
+        agent_ref: "local:../../../agents/conveyor/reviewer"
+        runtime: codex
+        profile: default
+        cwd: "."
+    edges: []
+
+edges:
+  - kind: delegates_to
+    from: intake.lead
+    to: plan.planner
+  - kind: delegates_to
+    from: plan.planner
+    to: build.builder
+  - kind: delegates_to
+    from: build.builder
+    to: review.reviewer
+  - kind: delegates_to
+    from: review.reviewer
+    to: build.builder
+  - kind: can_observe
+    from: review.reviewer
+    to: intake.lead
+  - kind: can_observe
+    from: intake.lead
+    to: build.builder
+  - kind: can_observe
+    from: intake.lead
+    to: review.reviewer

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

@@ -1,6 +1,6 @@
 # Product Team — Team Culture
 
-This is the advanced-preview sibling of `demo`. Right now it uses the same core topology: two orchestrators, a development pod with implementation, QA, and design, plus two reviewers.
+This is the human-operated product-development starter. It uses a full product-team topology: two orchestrators, a development pod with implementation, QA, and design, plus two reviewers.
 
 ## Team shape
 
@@ -134,4 +134,4 @@ Follow patterns agents already know: docker, git, kubectl, npm.
 
 ## What this rig is for
 
-This is the advanced preview lane for the full product-team experience. Use it to explore richer coordination patterns and future capabilities without treating it as the ship gate. The human sets direction; the team plans, implements, reviews, and surfaces gaps honestly.
+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.

package/daemon/specs/rigs/preview/product-team/rig.yaml

@@ -2,10 +2,9 @@ version: "0.2"
 name: product-team
 culture_file: CULTURE.md
 summary: >
-  Advanced preview: the experimental sibling of demo, with the same full
-  product-squad topology: two orchestrators, implementation, QA, design,
-  and two independent reviewers. Use this when you want the richer lane,
-  not the release gate.
+  Advanced product-development starter: a human-operated product squad with
+  two orchestrators, implementation, QA, design, and two independent reviewers.
+  Use this when you want richer coordination than the conveyor training rig.
 
 pods:
   - id: orch1

package/dist/commands/agent-image.d.ts

@@ -0,0 +1,4 @@
+import { Command } from "commander";
+import type { StatusDeps } from "./status.js";
+export declare function agentImageCommand(depsOverride?: StatusDeps): Command;
+//# sourceMappingURL=agent-image.d.ts.map

package/dist/commands/agent-image.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"agent-image.d.ts","sourceRoot":"","sources":["../../src/commands/agent-image.ts"],"names":[],"mappings":"AAcA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAC;AAIpC,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,aAAa,CAAC;AA4E9C,wBAAgB,iBAAiB,CAAC,YAAY,CAAC,EAAE,UAAU,GAAG,OAAO,CAkTpE"}