@openrig/cli 0.2.0 → 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/rig-architect/SKILL.md

@@ -37,7 +37,7 @@ Load these before starting any design work. The quality of your output depends o
 
 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, HA via mental-model-ha skill + substrate session logs, terminal nodes as common-room, chatroom/substrate/transcripts/Corpus).
+   - §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.

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"}