mvschwarz/openrig
1
0 Fork 0
mirror of https://github.com/mvschwarz/openrig.git synced 2026-11-07 05:56:21 -10:00
Code Issues Packages Projects Releases 1 Wiki Activity

docs: say the new team names in shipped text (#866)

Browse Source 
Shipped docs, skills, help and onboarding text now name the new built-in teams: starter, workshop and factory, plus the code-review, research and pm shelf. first-project is mentioned only as starter's old name, Codex-only readers are pointed to the kernel operator to adapt a team, and secrets-manager stays listed as built in. Skill mirrors and edge digests are regenerated.
This commit is contained in:
Mike Schwarz authored and GitHub committed 2026-10-06 01:47:57 -07:00
1 parent 44e47baacb
commit 200606a514
19 files changed
+216 -204
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

README.md
+34 -37
View File
@@ -40,38 +40,42 @@ Check `tmux -V` and only your selected CLI/login: `claude --version` plus
sign in once with `claude auth login` or `codex login`; do not install or log in
to an unused provider.
| Team | Starter | Models |
| --- | --- | --- |
| Two Codex agents | `first-project` | Both `gpt-6-astra` (unchanged) |
| Two Claude agents | `first-project-claude` | Configured native Claude default |
| Claude owner + Codex checker | `first-project-mixed` | Claude default + `gpt-6-astra` |
The kernel's operator helps you pick a first team. It asks what you want to build,
recommends one of three, and fits it to the providers you have.
All three use the same owner/checker roles and task. Show the selected runtime,
configured model and command before launch; confirm the account supports the
model instead of silently falling back. The kernel starts automatically and
selects from available authenticated providers independently of these two project
agents. A missing unused provider is not a setup requirement.
| Team | Agents | For |
| --- | --- | --- |
| `starter` | A builder (`dev-build`, Claude Code) and a reviewer (`dev-review`, Codex) | One bounded change |
| `workshop` | A lead, a builder, QA and a reviewer | Ongoing work in one repository; a rig bundle the operator installs from its pinned listing |
| `factory` | Seven: a lead, an advisor, build, QA, design and two independent reviewers | Sustained product work |
As shipped, `starter` uses both Claude Code and Codex. With only one of them, ask
the kernel operator to adapt it: it writes a copy of the team for your providers
under the same name. `first-project` is starter's old name and still starts it.
Show the selected runtime, configured model and command before launch; confirm the
account supports the model instead of silently falling back. The kernel starts
automatically and selects from available authenticated providers independently of
these teams. A missing unused provider is not a setup requirement.
```bash
cd /path/to/your/repository
starter=first-project # or first-project-claude or first-project-mixed
rig specs preview "$starter" --kind rig
rig up "$starter" --cwd . --plan
rig up "$starter" --cwd .
rig specs preview starter --kind rig
rig up starter --cwd . --plan
rig up starter --cwd .
```
After installation, your agent should [open a **new kernel conversation space**](docs/reference/getting-started.md#open-the-kernel-conversations): `rig terminal open saved:kernel --provider herdr`, then cmux or a plain terminal if unavailable. The default view needs no YAML edit. The agent tells you before opening it and keeps its own terminal and your existing spaces intact. The guide also gives the manual and SSH commands.
The kernel provides separate operational support and the shared dashboard. To detach without stopping the dashboard, press Ctrl-b then d; `rig tui --shared` returns to that view. Plain `rig tui` opens an independent view. Closing a viewing terminal does not mean you should relaunch the team.
Check project-seat readiness with `rig ps --nodes --rig "$starter"` and resolve any authentication, trust or permission prompt before assigning work. If a seat stopped at such a prompt before its startup context arrived, `rig ps` shows the `rig seat continue <seat>` command that delivers it once the prompt is answered. Then give the owner one bounded outcome from your repository:
Check project-seat readiness with `rig ps --nodes --rig starter` and resolve any authentication, trust or permission prompt before assigning work. If a seat stopped at such a prompt before its startup context arrived, `rig ps` shows the `rig seat continue <seat>` command that delivers it once the prompt is answered. Then give the builder one bounded outcome from your repository:
```bash
rig send "dev-owner@$starter" 'Implement <one useful change>. Track the task in the queue and return its ID. Keep it local, verify the behavior, ask dev-check in this rig to check the exact candidate, and record the result and how I can try it.'
rig queue list --destination "dev-owner@$starter" --limit 1000
rig send dev-build@starter 'Implement <one useful change>. Track the task in the queue and return its ID. Keep it local, verify the behavior, ask dev-review in this rig to check the exact candidate, and record the result and how I can try it.'
rig queue list --destination dev-build@starter --limit 1000
```
Sending a message does not itself create a queue item; the owner records the task. Read the final artifact and the review of its exact candidate, then return to the same owner for the next change. [The guided first-use path](docs/reference/getting-started.md) covers readiness, a useful task, a reviewed result, Herdr/cmux terminals and recovery.
Sending a message does not itself create a queue item; the builder records the task. Read the final artifact and the review of its exact candidate, then return to the same builder for the next change. [The guided first-use path](docs/reference/getting-started.md) covers readiness, a useful task, a reviewed result, Herdr/cmux terminals and recovery.
Not setting this up today? Get the next walkthrough and occasional OpenRig updates → https://openrig.dev/follow
@@ -201,29 +205,22 @@ OpenRig is a multi-agent harness — it manages the system that coding agents fo
Every agent runs in a tmux session you can attach to, inspect, and work with directly.
## Starter Rigs
## Teams
Use `first-project`, `first-project-claude`, or `first-project-mixed` for the
same focused first-use path on your selected providers. `product-team` is an optional
larger product-development example:
Three teams grow with you, and the kernel operator helps you pick one:
- **`starter`**: a builder and a reviewer for one bounded change.
- **`workshop`**: a lead, a builder, QA and a reviewer for ongoing work in one repository. It's a rig bundle, installed from its pinned listing.
- **`factory`**: seven agents (a lead, an advisor, build, QA, design and two independent reviewers) for sustained product work. You bring ideas to the advisor, and the lead runs the team.
```bash
rig specs preview product-team --kind rig
rig up product-team
rig specs preview factory --kind rig
rig up factory
```
Use it when you want a larger product squad: two orchestrators, implementation, QA, design, and two independent reviewers.
Specialist teams: `code-review` (two independent reviews), `research` (an analyst and a synthesizer) and `pm` (a product lead, a researcher and a builder for prototypes).
For a smaller starter, use `conveyor`:
```bash
rig specs preview conveyor --kind rig
rig up conveyor
```
`conveyor` is a four-seat starter mixing Claude Code and Codex. It shows a handoff path through intake, planning, build, and review; `first-project` remains the smaller two-seat starting point.
Also ships: `implementation-pair`, `adversarial-review`, `research-team`, and `secrets-manager` (HashiCorp Vault managed by a specialist agent).
Also built in: `secrets-manager`, a HashiCorp Vault instance run by a specialist agent.
Browse the library:
@@ -261,7 +258,7 @@ The TUI shows the team's coordination state; herdr and cmux show the actual agen
With herdr installed and connected, open the starter's terminals together:
```bash
rig terminal open first-project --provider herdr
rig terminal open starter --provider herdr
```
For cmux, use `--provider cmux`. In the TUI, a rig's detail view has a `term ▸ rig <name>` link that opens every running seat of that rig in the default terminal provider; with herdr that is up to 16 seats per tab, in a workspace named after the rig. The underlying sessions remain accessible through tmux. See the [terminal workspace guide](docs/reference/getting-started.md#share-the-dashboard-and-return-to-it) for setup and returning to an existing view.
@@ -270,7 +267,7 @@ For cmux, use `--provider cmux`. In the TUI, a rig's detail view has a `term ▸
- **RigSpec**: Declarative multi-agent harness definition in YAML. Pods, members, edges, continuity policies, culture file.
- **AgentSpec**: Reusable agent blueprint with skills, guidance, hooks, profiles, and startup contracts.
- **Seat**: A stable role and address in a rig, such as `dev-owner@first-project`. The conversation occupying it can change while its identity and authored context remain.
- **Seat**: A stable role and address in a rig, such as `dev-build@starter`. The conversation occupying it can change while its identity and authored context remain.
- **Pod**: A group of related seats with shared guidance and context. Each agent still has its own context window.
- **Discovery**: `rig discover` fingerprints existing tmux sessions. `rig adopt` brings them under management.
- **Snapshot/Restore**: `rig down --snapshot` captures full state. `rig up <name>` restores from latest snapshot. Restore reports per-node outcomes: resumed, fresh-primed, awaiting-decision (the original conversation can't resume; choose `--fresh`), attention_required, or failed.
context7.json
+1 -1
View File
@@ -18,7 +18,7 @@
],
"excludeFiles": [],
"rules": [
"Install with npm install -g @openrig/cli. OpenRig requires Node.js 22 or 24 and tmux; the first-project starter also requires an authenticated Codex CLI.",
"Install with npm install -g @openrig/cli. OpenRig requires Node.js 22 or 24, tmux, and Claude Code or Codex signed in. The starter team uses both, and the kernel operator adapts it when you have only one.",
"Preview before launching: rig specs preview <spec>, then rig up <spec> --cwd . --plan, then rig up <spec> --cwd .",
"Check seat readiness with rig ps --nodes --rig <rig>, not only daemon health from rig status.",
"Inside a rig, an agent runs rig whoami --json first and treats its output as its identity.",
docs/reference/chain-file-convention.md
+1 -1
View File
@@ -103,7 +103,7 @@ reproduces the drift it was meant to catch. Run it; do not recall it.
## Shipped defaults and the curation path
Included rigs ship sensible-default chain files under a `topology/` folder,
installed under `topology.root` at rig-up. Today only `product-team` ships one,
installed under `topology.root` at rig-up. Today only `factory` ships one,
with instance, rig and seat defaults; the installer also supports pod defaults.
A shipped default is a **starting point** the occupying team appends to — it
is never overwritten by a later rig-up (existing files win).
docs/reference/getting-started.md
+50 -49
View File
@@ -256,38 +256,39 @@ inventing them. No new account or credential provisioning is part of this
handoff. Report which provider or fallback ran, which conversations and TUI
were visible, and any headless or unverified branch.
## Choose your first project team
## Choose your first team
Tell the kernel operator what you want to do. It helps you pick a first team;
review that choice before launching it. The shipped first-project recipes each
have an outcome owner and an independent checker. Reuse your selected working
accounts; a second provider is optional.
Tell the kernel operator what you want to do. It asks about your goal, presents
three teams with one recommendation, and fits the team to the providers you have.
Review that choice before launching it.
| Choice | Starter name | Owner / checker runtime and model |
| Team | Agents and runtimes | For |
| --- | --- | --- |
| Two Codex agents (existing route) | `first-project` | Both `codex`, pinned `gpt-6-astra` |
| Two Claude agents | `first-project-claude` | Both `claude-code`, configured native default model |
| One of each | `first-project-mixed` | Claude owner (native default); Codex checker (`gpt-6-astra`) |
| `starter` | `dev-build` (Claude Code) and `dev-review` (Codex, pinned `gpt-6-astra`) | One bounded change |
| `workshop` | A lead, a builder, QA and a reviewer | Ongoing work in one repository. It's a rig bundle, not built in: the operator installs it from its pinned listing |
| `factory` | Seven: a lead, an advisor, build, QA, design and two independent reviewers | Sustained product work. It uses the most concurrent capacity |
Claude uses the same unpinned model convention as the existing Claude kernel and
implementation-pair recipes: OpenRig does not pass a model override. Read the
selected harness's configured model and show it alongside the recipe and launch
command before proceeding. Confirm account access to any pin; if unavailable,
As shipped, `starter` needs both Claude Code and Codex. With only one of them, the
operator writes an adapted copy of the team for your providers and keeps its name;
there are no per-provider variants. `first-project` is starter's old name and
still starts it, so an old `rig up first-project` now starts a Claude builder and a
Codex reviewer.
Claude seats use the native default model, as the Claude kernel does: OpenRig
does not pass a model override. Read the selected harness's configured model and
show it alongside the team and launch command before proceeding. Confirm account access to any pin; if unavailable,
ask for a supported model choice rather than silently substituting a model or
provider. After launch, confirm the actual native model before assigning work.
### Launch the two project seats
Set `starter` to the chosen name from the table; the existing Codex route remains:
### Launch the starter team
```sh
cd <your-repository>
starter=first-project # or first-project-claude or first-project-mixed
rig specs preview "$starter" --kind rig
rig up "$starter" --cwd . --plan
rig up "$starter" --cwd .
rig specs preview starter --kind rig
rig up starter --cwd . --plan
rig up starter --cwd .
rig status
rig ps --nodes --rig "$starter"
rig ps --nodes --rig starter
```
Preview the selected seats, models and resources. Plan checks resolution and
@@ -317,34 +318,34 @@ not progress. If startup is still waiting for context delivery, use **c** (or
command times out, check `rig seat status <seat>` before trying again. Do not
start another seat to clear a prompt.
These starters are deliberately small starting points, not universal teams.
For a different installed runtime or team shape, inspect `rig specs ls --kind
rig` and `rig specs preview <name>` before selecting it. A seven-seat showcase
is optional and consumes more concurrent capacity. A team published on GitHub
installs from its folder link with `rig up <link>` (see
Starter is a deliberately small starting point. For a bigger team, `factory` is
built in (seven agents, using more concurrent capacity), and so are the specialist
teams `code-review`, `research` and `pm`. Inspect `rig specs ls --kind rig` and
`rig specs preview <name>` before selecting one. A team published on GitHub, such
as workshop, installs from its folder link with `rig up <link>` (see
[publishing a rig bundle](publishing-a-rig-bundle.md)).
## Give the owner an outcome
## Give the builder an outcome
For example, in a project that imports CSV files:
```sh
rig send "dev-owner@$starter" 'Improve the CSV import error when a required column is missing: name the column and leave the existing data unchanged. Add a regression check, ask dev-check for an independent check of the exact candidate, and record the result and how I can try it. Keep the change local; do not publish.'
rig send dev-build@starter 'Improve the CSV import error when a required column is missing: name the column and leave the existing data unchanged. Add a regression check, ask dev-review for an independent check of the exact candidate, and record the result and how I can try it. Keep the change local; do not publish.'
```
Replace the example with a real problem in your repository. Include what the
user should observe, a boundary and how success can be checked. The owner
user should observe, a boundary and how success can be checked. The builder
creates and claims a durable task, implements it, and routes the selected
independent check. You should not have to relay the review between terminals.
`rig send` is the initial conversation; the queue and repository artifacts
retain the work. An unbound shell does not need to impersonate a queue owner.
Use the chosen rig name in its seat addresses (for example,
`dev-owner@first-project-claude`). From an actual project seat, follow the work with
Seat addresses carry the rig name (for example, `dev-build@starter`). From an
actual project seat, follow the work with
`rig queue list --limit 1000`: its default scope is the caller's current rig.
`queue list` has no `--rig` option. From an observer shell or another rig, use
`rig queue list --destination "dev-owner@$starter" --limit 1000` and the same
command for `"dev-check@$starter"`, after verifying those live addresses.
`rig queue list --destination dev-build@starter --limit 1000` and the same
command for `dev-review@starter`, after verifying those live addresses.
These show each destination's obligations, not a whole-rig view. An unbound shell
must not pretend to be a seat to change scope; use `--all-rigs` only when that
broader view is intended. Then read `rig queue show <id> --full` and
@@ -370,7 +371,7 @@ start or replace a terminal, so a missing binding is reported with recovery
guidance rather than creating a second kernel.
Herdr users follow the same launch and task path. To place the managed team in
Herdr, use `rig terminal open "$starter" --provider herdr`; for the shared
Herdr, use `rig terminal open starter --provider herdr`; for the shared
dashboard together with the kernel conversations, use the
[saved first view](#open-the-kernel-conversations). The equivalent
cmux provider is also available. Read the opened/absent/degraded result: a
@@ -555,18 +556,18 @@ another confirmation. Use it only for work and an environment you deliberately
trust; it does not supply missing credentials or override organization policy.
Make changes in a **user-owned spec before its first launch**. To customize the
starter, run `rig specs show first-project --kind rig` and find its `Path`, ending
in `specs/rigs/launch/first-project/rig.yaml`. Copy that whole `specs` directory to
starter, run `rig specs show starter --kind rig` and find its `Path`, ending
in `specs/rigs/launch/starter/rig.yaml`. Copy that whole `specs` directory to
`./openrig-specs` in your repository, keeping its layout: copying only `rig.yaml`
breaks its relative agent and culture references. Leave the installed copy alone.
The examples below use `./openrig-specs/rigs/launch/first-project/rig.yaml`. If you
already have a running `first-project`, follow the existing-session advice below
The examples below use `./openrig-specs/rigs/launch/starter/rig.yaml`. If you
already have a running `starter`, follow the existing-session advice below
before changing it; this is not a live permission switch.
### Codex: select sandbox and approvals together
For Codex versions supporting named `.config.toml` profiles, create
`~/.codex/first-project-permissive.config.toml` (under `CODEX_HOME` instead if you
`~/.codex/starter-permissive.config.toml` (under `CODEX_HOME` instead if you
set it for the daemon's launch environment):
```toml
@@ -574,23 +575,23 @@ sandbox_mode = "danger-full-access"
approval_policy = "never"
```
In the copied rig, add this field to **each Codex member** that should use it;
keep the member's existing `profile: default`:
In the copied rig, add this field to **each Codex member** that should use it (in
starter, that's `dev.review`); keep the member's existing `profile: default`:
```yaml
codex_config_profile: first-project-permissive
codex_config_profile: starter-permissive
```
Leave `permission_policy` absent or set it to `none`, with no member-level YOLO
override. OpenRig then passes `-p first-project-permissive` instead of its default
override. OpenRig then passes `-p starter-permissive` instead of its default
`-s workspace-write`, so the native profile supplies both settings. Higher-priority
native project configuration or managed requirements can still change/refuse the
result. Inspect native `/status` before assigning work.
```sh
rig policy current --spec ./openrig-specs/rigs/launch/first-project/rig.yaml
rig up ./openrig-specs/rigs/launch/first-project/rig.yaml --cwd . --plan
rig up ./openrig-specs/rigs/launch/first-project/rig.yaml --cwd .
rig policy current --spec ./openrig-specs/rigs/launch/starter/rig.yaml
rig up ./openrig-specs/rigs/launch/starter/rig.yaml --cwd . --plan
rig up ./openrig-specs/rigs/launch/starter/rig.yaml --cwd .
```
OpenRig's `permission_policy: builtin:yolo` setting selects
@@ -622,8 +623,8 @@ Permission mode is the native execution choice; work posture is project guidance
For an existing managed seat, select future-launch permissions explicitly:
```sh
rig seat set-permissions dev-owner@first-project --mode full_bypass --reason "Operator selected broader access"
rig seat status dev-owner@first-project --json
rig seat set-permissions dev-build@starter --mode full_bypass --reason "Operator selected broader access"
rig seat status dev-build@starter --json
```
This records the actor, reason and old/new choice on that seat. It does not
@@ -669,7 +670,7 @@ typing guard are separate controls.
### Claude Code: a different launch flag
The shipped `first-project` uses Codex. For a user-owned **Claude Code** rig,
In the shipped `starter`, `dev-build` runs Claude Code. For a **Claude Code** seat,
OpenRig normally passes `--permission-mode acceptEdits`: edits can proceed, while
other actions follow native rules and prompts. It does not add a global
`Bash(rig:*)` allowance. To explicitly select the bypass launch flag for that rig:
docs/reference/rig-spec.md
+9 -8
View File
@@ -121,7 +121,7 @@ pods:
applies_on: [fresh_start]
actions:
- type: send_text
value: "Load the implementation-pair skill and begin."
value: "Read your guidance and begin."
phase: after_ready
idempotent: true
- id: qa
@@ -683,12 +683,13 @@ These are the built-in specs shipped with OpenRig. Read them as worked examples.
| Spec | Location | Pods | Members | Services |
|------|----------|------|---------|----------|
| `product-team` | `packages/daemon/specs/rigs/preview/product-team/rig.yaml` | orch1, dev1, rev1 | 7 (lead, peer, impl, qa, design, r1, r2) | no |
| `implementation-pair` | `packages/daemon/specs/rigs/launch/implementation-pair/rig.yaml` | dev | 2 (impl, qa) | no |
| `adversarial-review` | `packages/daemon/specs/rigs/focused/adversarial-review/rig.yaml` | orch, review | 3 (lead, r1, r2) | no |
| `research-team` | `packages/daemon/specs/rigs/focused/research-team/rig.yaml` | orch, research | 3 (lead, analyst, synthesizer) | no |
| `starter` | `packages/daemon/specs/rigs/launch/starter/rig.yaml` | dev | 2 (build, review) | no |
| `factory` | `packages/daemon/specs/rigs/launch/factory/rig.yaml` | orch, dev, review | 7 (lead, advisor, build, qa, design, r1, r2) | no |
| `code-review` | `packages/daemon/specs/rigs/focused/code-review/rig.yaml` | orch, review | 3 (lead, r1, r2) | no |
| `research` | `packages/daemon/specs/rigs/focused/research/rig.yaml` | orch, research | 3 (lead, analyst, synthesizer) | no |
| `pm` | `packages/daemon/specs/rigs/focused/pm/rig.yaml` | pm, dev | 3 (lead, researcher, build) | no |
| `secrets-manager` | `packages/daemon/specs/rigs/launch/secrets-manager/rig.yaml` | vault | 1 (specialist) | yes (Vault) |
Also shipped, in the same tree: `focused/pm-team`, `launch/conveyor`, `launch/demo`, `launch/factory-rsi`,
`launch/first-project`, `launch/first-project-claude`, `launch/first-project-mixed` and `launch/kernel`. List them with
`rig specs ls --kind rig`.
Also shipped, in the same tree: `launch/kernel`, OpenRig's own team, which starts automatically. `first-project` is
starter's old name and still resolves to it. `workshop`, the four-agent middle team, is a rig bundle rather than a
built-in. List the built-ins with `rig specs ls --kind rig`.
docs/reference/sdlc-conventions.md
+1 -1
View File
@@ -234,7 +234,7 @@ reported as unknown, not failure.
seam rather than teaching core a mode.
- **Skill**: `mission-slice-sop` teaches **Part A**, the light default. **Part B**
is defined below and applies only when assigned — never self-selected.
- **Bootstrap**: the shipped pm-team rig culture points its seats at the skill
- **Bootstrap**: the shipped `pm` rig culture points its seats at the skill
and this document; the generic `openrig-start.md` overlay no longer does.
# PART B — THE RIGOROUS OVERLAY (assigned only)
packages/cli/src/commands/context.ts
+2 -2
View File
@@ -251,8 +251,8 @@ Examples:
rig context sync
rig context profile world-public --situation fresh --runtime claude-code
rig context work-install --runtime claude-code
rig context trace --rig product-team --seat orch1-lead --name LEARNED.md
rig context trace --rig product-team --pod delivery --seat dev1-qa --name LEARNED.md
rig context trace --rig factory --seat orch-lead --name LEARNED.md
rig context trace --rig factory --pod dev --seat dev-qa --name LEARNED.md
`);
const getDeps = (): StatusDeps => depsOverride ?? {
packages/cli/src/commands/setup.ts
+6 -5
View File
@@ -794,11 +794,12 @@ export function goldenPathNextSteps(): string[] {
" Keep the current terminal and existing spaces intact; opening this view needs no new provider install",
" rig tui --shared joins the existing kernel TUI from a new terminal; plain rig tui opens an independent view",
" 5. Tell the operator your goal and pick a first team, then cd <your-repository>",
" Choose first-project (two Codex), first-project-claude (two Claude), or first-project-mixed",
" Preview rig up <starter> --cwd . --plan; with your yes, rig up <starter> --cwd .",
" rig ps --nodes --rig <starter> checks the project seats before giving them work",
" 6. rig send dev-owner@<starter> '<one useful change, boundaries, and how to check it>'",
" Next: rig queue list --destination dev-owner@<starter>; rig workspace doctor; rig scope ...; rig workflow specs",
" Teams: starter (a Claude builder and a Codex reviewer), workshop (a rig bundle) or factory (seven agents)",
" With one provider, the operator adapts the team for you; first-project is starter's old name",
" Preview rig up <team> --cwd . --plan; with your yes, rig up <team> --cwd .",
" rig ps --nodes --rig <team> checks the project seats before giving them work",
" 6. rig send dev-build@starter '<one useful change, boundaries, and how to check it>' (workshop, factory: orch-lead@<team>)",
" Next: rig queue list --destination dev-build@starter; rig workspace doctor; rig scope ...; rig workflow specs",
];
}
packages/cli/test/setup.test.ts
+6 -4
View File
@@ -250,14 +250,16 @@ describe("rig setup", () => {
expect(wsIdx).toBeGreaterThan(statusIdx);
expect(wfIdx).toBeGreaterThan(wsIdx);
expect(scopeIdx).toBeGreaterThan(wsIdx);
expect(out).toContain("rig up <starter> --cwd . --plan");
for (const name of ["first-project", "first-project-claude", "first-project-mixed"]) expect(out).toContain(name);
expect(out).toContain("rig up <team> --cwd . --plan");
for (const name of ["starter", "workshop", "factory"]) expect(out).toContain(name);
expect(out).not.toContain("first-project-claude");
expect(out).not.toContain("first-project-mixed");
expect(out).toContain("Check only selected logins");
expect(out).toContain("Started is not ready");
expect(out).toContain("No: give the command to open it later");
expect(out).toContain("Over SSH: give the exact connection/attach command");
expect(out).toContain("rig send dev-owner@<starter>");
expect(out).toContain("rig queue list --destination dev-owner@<starter>");
expect(out).toContain("rig send dev-build@starter");
expect(out).toContain("rig queue list --destination dev-build@starter");
expect(out).not.toContain("rig queue list --rig");
expect(out).toContain("rig tui --shared");
expect(out).toContain("docs/reference/getting-started.md");
packages/daemon/assets/plugins/openrig-core/skills/openrig-user/SKILL.md
+6 -3
View File
@@ -301,7 +301,10 @@ OpenRig v0.3.0 adds `rig agent-image`, `rig context-pack`, `rig workspace`, and
`rig config init-workspace`. *(0.5.0: the `rig context-pack` alias is retired — the store + compose library is the single `rig context` noun; see "Context packs and paced delivery (0.5.0)".)* It also shifts fresh-user starter guidance toward
`product-team` for human-directed work and `conveyor` for workflow-oriented
work. Treat `demo` as legacy/test content unless a task specifically asks for
the old demo spec.
the old demo spec. *(0.6.6: the built-in teams are `starter` and `factory`, plus the
specialist teams `code-review`, `research` and `pm`. `product-team`, `conveyor` and
`demo` are gone, and `first-project` is starter's old name. `workshop` is a rig
bundle.)*
OpenRig v0.3.1 adds public package/source surfaces for Plugin Primitive v0,
Claude Auto-Compaction Policy, migration `040_workflow_specs_diagnostic`,
@@ -357,8 +360,8 @@ rig start --json # JSON output for agents
```
Framing: `rig start` is the RECOVERY entry point, not the getting-started
hero. The fresh-user boot hero remains `rig up <starter>` (typically
`rig up product-team`). Reach for `rig start` after a host reboot, daemon
hero. The fresh-user boot hero remains `rig up <team>` (typically
`rig up starter` for a first change, or `rig up factory`). Reach for `rig start` after a host reboot, daemon
restart, or any "bring my rigs back" moment.
### `rig reconcile-session` — no-launch adopt of a hand-resumed session
packages/daemon/context-packs-src/onboarding-width/public-what-you-can-do.md
+6 -5
View File
@@ -240,11 +240,12 @@ relay is a reason to inspect the available routing, not to surrender judgment to
## Bringing things into and out of existence
**For a first useful repository change**, pick the first-project recipe that matches the
accounts you have: `first-project` (two Codex seats), `first-project-claude` (two Claude Code
seats) or `first-project-mixed` (a Claude Code owner and a Codex checker). Preview it, inspect
`rig up <recipe> --cwd . --plan`, and follow `docs/reference/getting-started.md`. Each is the same
owner/checker team; verify prerequisites and actual runtime readiness before work. Existing Herdr/cmux terminals can present the managed team
**For a first useful repository change**, tell the kernel operator your goal. It recommends one
of three teams, `starter` (a Claude Code builder and a Codex reviewer), `workshop` (a rig bundle:
a lead, a builder, QA and a reviewer) or `factory` (seven agents), and adapts the team to the
accounts you have. `first-project` is starter's old name. Preview the team, inspect
`rig up <team> --cwd . --plan`, and follow `docs/reference/getting-started.md`. Verify
prerequisites and actual runtime readiness before work. Existing Herdr/cmux terminals can present the managed team
through `rig terminal open`.
**Need a small team now, without authoring YAML?** Start with `rig create`, then use `rig grow`
packages/daemon/specs/agents/shared/skills/core/openrig-architect/SKILL.md
+3 -3
View File
@@ -92,7 +92,7 @@ Every rig is organized into pods — bounded context groups where members share
**Sizing principles:**
- **Solo agent:** Only when the task is genuinely single-person (quick script, simple question). No rig needed.
- **Pair (2 agents):** The minimum effective unit for quality work. One does, one verifies. The `implementation-pair` pattern.
- **Pair (2 agents):** The minimum effective unit for quality work. One does, one verifies. The built-in `starter` team's shape.
- **Small team (3-5 agents):** Orchestrator + one or two working pods. Good starting point for focused projects.
- **Full team (6-10 agents):** Multiple bounded contexts with orchestration, development, review, and potentially research or design.
- **Large team (10-40+ agents):** Complex projects with many concerns. Include pods for development, review, research, documentation, release management, strategy, and any other bounded context the project needs.
@@ -178,7 +178,7 @@ This is where most rigs succeed or fail. The topology is mechanical; the startup
**For serious rigs, also include:**
4. `startup/context.md` per agent — boot-time grounding (project info, environment details)
5. Pod SOP skills — how each pod operates (implementation-pair SOP, review-pair SOP, etc.)
5. Pod SOP skills — how each pod operates (build-pair SOP, review-pair SOP, etc.)
6. Project-specific documentation in rig-level startup files
**The key principle:** An agent that boots without knowing its role, its team's culture, and its project context will produce generic, unhelpful work. The startup content IS the product value. Invest in it.
@@ -356,7 +356,7 @@ pods:
**Use when:** The work involves operating software, not just writing code.
### The Full Product Team
**7 agents, 3 pods.** The kitchen-sink topology: orchestration pair, development pod (impl + qa + design), review pair. See the `product-team` starter spec for the complete worked example.
**7 agents, 3 pods.** The kitchen-sink topology: orchestration pair, development pod (impl + qa + design), review pair. See the built-in `factory` spec for the complete worked example.
**Use when:** Full product development with design, implementation, QA, and independent review. Requires strong culture and SOP content to keep all agents engaged.
packages/daemon/specs/agents/shared/skills/core/openrig-software-factory/SKILL.md
+11 -8
View File
@@ -37,13 +37,16 @@ read [references/worked-example.md](references/worked-example.md). Installed cop
`rig context get skills/core/openrig-software-factory/references/worked-example.md`.
A roadmap, YAML file or wake does not execute work or authorize a new outcome.
## Choose the first project's providers
## Choose the first team and its providers
Ask which working account(s) the user wants: Claude Code, Codex, or both. Reuse
an explicit choice and recommend the account they already have working. Use
`first-project-claude` (two Claude), `first-project` (two Codex), or
`first-project-mixed` (Claude owner, Codex checker). All share the same task and
owner/checker culture. Check only selected CLIs/logins; request `claude auth login`
Ask what the user wants to build and which working account(s) they have: Claude
Code, Codex, or both. Recommend one of three teams: `starter` (a Claude builder
and a Codex reviewer, for one bounded change), `workshop` (a lead, a builder, QA
and a reviewer; a rig bundle installed from its pinned listing) or `factory` (seven
agents for sustained product work). When the user lacks a provider a team needs,
write an adapted copy of the team under the same name, as the kernel operator's
guidance describes; never offer per-provider variants. `first-project` is
starter's old name. Check only the CLIs/logins the team needs; request `claude auth login`
or `codex login` once when that selected login is missing. No credential copying,
unused provider prerequisite or silent model/provider fallback.
@@ -55,8 +58,8 @@ Do not add an unused-provider login gate or manual kernel setup to this path.
An instance-wide provider restriction is a separate request. Preserve an
existing kernel and working user rigs.
Show the chosen recipe, resolved runtimes/models and exact
`rig up <starter> --cwd . --plan` / `rig up <starter> --cwd .` commands. Codex seats
Show the chosen team, resolved runtimes/models and exact
`rig up <team> --cwd . --plan` / `rig up <team> --cwd .` commands. Codex seats
retain `gpt-6-astra`; Claude seats use the configured native default without an
OpenRig model override. Confirm that model with the user and its availability;
verify the native session's actual model before consequential work. Use the
packages/daemon/specs/agents/shared/skills/core/openrig-software-factory/references/worked-example.md
+29 -29
View File
@@ -4,7 +4,7 @@ Use this example to adapt reviewed work to a repository with CSV handling. Choos
This is a concrete CSV-validation example for adaptation, not a requirement that an arbitrary repository become a CSV project or every outcome be split into two slices. This example uses two genuinely dependent slices. Select a real, authorized repository and record its starting commit and existing CSV behavior. If it has no relevant CSV code, choose two dependent changes appropriate to that repository and rewrite the example objectives before execution; ordinary user tasks retain their appropriate size.
For the example only, repository root and work root are the same absolute directory, called `PROJECT_ROOT`. The selected project ID is `csv-tool`, mission is `csv-validation`, and rig is the shipped `first-project`. These are authored example identities, not live discoveries. Resolve existing catalog/config/intent first. Never overwrite a real `project.yaml`, `workspace.yaml`, `SPEC.md`, `AGENTS.md`, or existing mission to install a template. Merge compatible fields deliberately or choose an unused work directory and preserve the existing catalog entries. If using a separate work root, launch seats in the code repository and record both roots in intent/context. Keep `project.yaml` two directories above the mission directory for this compiler path; arbitrary custom mission-root layouts are not established here.
For the example only, repository root and work root are the same absolute directory, called `PROJECT_ROOT`. The selected project ID is `csv-tool`, mission is `csv-validation`, and rig is the shipped `starter`. These are authored example identities, not live discoveries. Resolve existing catalog/config/intent first. Never overwrite a real `project.yaml`, `workspace.yaml`, `SPEC.md`, `AGENTS.md`, or existing mission to install a template. Merge compatible fields deliberately or choose an unused work directory and preserve the existing catalog entries. If using a separate work root, launch seats in the code repository and record both roots in intent/context. Keep `project.yaml` two directories above the mission directory for this compiler path; arbitrary custom mission-root layouts are not established here.
## Manual work and the queue loop
@@ -16,12 +16,12 @@ in the project's existing files.
When work should outlive a turn, the actual owner verifies its identity and uses
the queue. In this example, owner/checker addresses are synthetic until verified
against the real `first-project` team. The task file contains the real outcome,
against the real `starter` team. The task file contains the real outcome,
boundary, acceptance and evidence pointers; create it before sending:
```sh
rig whoami --json
rig queue create --destination dev-owner@first-project \
rig queue create --destination dev-build@starter \
--body-file ./TASK.md --summary 'Implement the agreed CSV inspection' --json
rig queue claim <returned-qitem-id> --json
```
@@ -29,7 +29,7 @@ rig queue claim <returned-qitem-id> --json
After implementing and checking the cumulative candidate, the current owner uses:
```sh
rig queue handoff <owned-qitem-id> --to dev-check@first-project \
rig queue handoff <owned-qitem-id> --to dev-review@starter \
--body-file ./REVIEW-REQUEST.md --json
```
@@ -100,7 +100,7 @@ work unattended.
## Grow the running team
Keep `first-project`'s owner and checker when they are enough. When there is useful
Keep `starter`'s builder and reviewer when they are enough. When there is useful
independent work, add one or two seats to that running rig. The example below adds
two builders; it does not require a larger starter, new Workflow or replacement
sessions. Use the actual rig name if yours differs.
@@ -112,23 +112,23 @@ general-purpose agent:
```sh
rig ps --json
rig ps --nodes --rig first-project --json
rig queue list --destination dev-owner@first-project --json
rig ps --nodes --rig starter --json
rig queue list --destination dev-build@starter --json
rig specs show orchestrator --kind agent --json
rig grow --help
```
Set `RIG_ID` to the `rigId` for the running `first-project`, and `PROJECT_ROOT`
Set `RIG_ID` to the `rigId` for the running `starter`, and `PROJECT_ROOT`
to the absolute code repository. Verify its existing `dev` pod and choose unused
member names. When the user has authorized the added capacity and cost, run:
```sh
rig grow "$RIG_ID" a b --pod dev --runtime codex --cwd "$PROJECT_ROOT" --json
rig ps --nodes --rig first-project --json
rig ps --nodes --rig starter --json
```
For one builder, omit `b`. The expected new logical IDs are `dev.a` and `dev.b`,
with addresses `dev-a@first-project` and `dev-b@first-project`; use the actual
with addresses `dev-a@starter` and `dev-b@starter`; use the actual
returned identities. The command adds and launches the named seats.
To put those seats in a **new** pod instead, choose this alternative once, with an
@@ -163,8 +163,8 @@ checks, next owner and stopping condition. Then deliver the context instruction,
for example for the first builder:
```sh
rig send dev-a@first-project "Read $PROJECT_ROOT/SPEC.md and the addressed sources in $PROJECT_ROOT/.openrig/factory/TASK-A.md. Run rig whoami --json and rig queue list --owned --json in your own seat; report your identity, scope and any native readiness/permission blocker. Await the bounded queue assignment."
rig capture dev-a@first-project
rig send dev-a@starter "Read $PROJECT_ROOT/SPEC.md and the addressed sources in $PROJECT_ROOT/.openrig/factory/TASK-A.md. Run rig whoami --json and rig queue list --owned --json in your own seat; report your identity, scope and any native readiness/permission blocker. Await the bounded queue assignment."
rig capture dev-a@starter
```
Read the actual reply and pane; resolve startup/login/permission prompts under the
@@ -174,7 +174,7 @@ the coordinator creates the distinct agreed task (or hands off an existing owned
task instead of duplicating it):
```sh
rig queue create --destination dev-a@first-project \
rig queue create --destination dev-a@starter \
--body-file "$PROJECT_ROOT/.openrig/factory/TASK-A.md" \
--summary 'Implement the agreed independent change A' --json
```
@@ -190,9 +190,9 @@ working agreement and assigned work, not the seat's name or default agent label.
| Seat in this example | Deliberately agreed responsibility |
| --- | --- |
| `dev-owner@first-project` | Initially implements and coordinates; can become the dedicated orchestrator, selecting outcomes, separating tasks, owning integration and retaining next-work custody. |
| `dev-a@first-project`, `dev-b@first-project` | Implement distinct authorized tasks and return exact candidates/evidence. Neither silently edits the other's files or folds both candidates without integration ownership. |
| `dev-check@first-project` | Retains independent judgment under the project's review policy. The implementer does not count its own check as independent review. |
| `dev-build@starter` | Initially implements and coordinates; can become the dedicated orchestrator, selecting outcomes, separating tasks, owning integration and retaining next-work custody. |
| `dev-a@starter`, `dev-b@starter` | Implement distinct authorized tasks and return exact candidates/evidence. Neither silently edits the other's files or folds both candidates without integration ownership. |
| `dev-review@starter` | Retains independent judgment under the project's review policy. The implementer does not count its own check as independent review. |
This is one progression, not a required four-seat layout. One extra builder may
be enough; a different workload may justify a specialist or additional independent
@@ -213,7 +213,7 @@ rewrite the starter or your original authored `rig.yaml`. Save a
separate live export to an unused user-owned path:
```sh
rig export "$RIG_ID" -o "$PROJECT_ROOT/.openrig/factory/first-project-expanded.yaml"
rig export "$RIG_ID" -o "$PROJECT_ROOT/.openrig/factory/starter-expanded.yaml"
```
Inspect the export and reconcile it with your user-owned authored RigSpec, retaining
@@ -326,14 +326,14 @@ lifecycle:
workflow:
objective: Add reviewed CSV validation without modifying input data
target:
rig: first-project
rig: starter
entry:
role: owner
roles:
owner:
preferred_targets: [dev-owner@first-project]
preferred_targets: [dev-build@starter]
checker:
preferred_targets: [dev-check@first-project]
preferred_targets: [dev-review@starter]
context_refs:
- SPEC.md#intent
- SPEC.md#acceptance
@@ -457,12 +457,12 @@ Complete initial Markdown bodies are specified below, after those frontmatter bl
| File relative to `PROJECT_ROOT` | Initial headings and bodies |
| --- | --- |
| `SPEC.md` | `# CSV tool`; `## Purpose`: “Help a person detect invalid CSV input before an import changes data.” `## Working agreement`: “Preserve existing repository rules, data and unrelated edits. The first-project owner coordinates implementation and continuity; dev-check independently checks the exact cumulative candidate. The user decides unresolved product behavior. Agreed local implementation, regression checks and review need no repeated approval; publication, destructive data changes and new external effects remain outside this task. Read the current queue and mission before acting; record evidence and unresolved facts, not invented completion.” |
| `SPEC.md` | `# CSV tool`; `## Purpose`: “Help a person detect invalid CSV input before an import changes data.” `## Working agreement`: “Preserve existing repository rules, data and unrelated edits. The starter builder coordinates implementation and continuity; dev-review independently checks the exact cumulative candidate. The user decides unresolved product behavior. Agreed local implementation, regression checks and review need no repeated approval; publication, destructive data changes and new external effects remain outside this task. Read the current queue and mission before acting; record evidence and unresolved facts, not invented completion.” |
| `missions/csv-validation/SPEC.md` | `# CSV validation`; `## Intent`: “A user can inspect a CSV and receive a useful validation result without changing the input file or imported data. First implement a pure inspection result; then expose it in the existing CLI.” `## Acceptance`: “Missing required headers name every missing column. Valid input passes. The CLI uses the inspection result and its chosen blank-cell rule, returns the repository's documented success/failure status and preserves input bytes. Tests exercise both slices. One independent checker records the exact candidate, commands, results and limits. The owner explains how to try it and preserves next-work custody. No publication.” |
| `missions/csv-validation/NOTES.md` | `# Decisions`; `## Blank required cells`: “PENDING — the user must decide whether a present required column containing blank cells is rejected or accepted. Slice 01 can report those cells without choosing policy; slice 02 must not guess the CLI rule. Record the user's decision, timestamp and source here.” |
| `missions/csv-validation/PROGRESS.md` | `# Progress`; `## Current position`: “Planned; no implementation, runtime instance or review result yet. Record the operation key, instance/frontier IDs, current owner, candidate and next action when observed.” |
| `missions/csv-validation/slices/01-inspect/SPEC.md` | `# Inspect CSV`; `## Intent`: “Add or adapt a pure inspection function using the repository's CSV handling. Return missing required headers and blank required cells with row/column locations; do not modify input or choose the pending CLI blank-cell policy.” `## Acceptance`: “Missing-header, valid-input, quoted-field and blank-cell cases produce the documented result. Input bytes and existing import behavior remain unchanged. Record actual commands and candidate for the cumulative checker.” |
| `missions/csv-validation/slices/02-cli/SPEC.md` | `# CLI validation`; `## Intent`: “Expose slice 01's inspection result through the existing CLI. Reuse its result rather than implementing a second parser. Resolve `../../NOTES.md#blank-required-cells` with the user before choosing the CLI outcome.” `## Acceptance`: “The CLI names missing columns, applies the recorded blank-cell rule, uses documented exit statuses and preserves input bytes. Focused valid/invalid cases and the existing relevant regression checks pass on the candidate supplied to dev-check.” |
| `missions/csv-validation/slices/02-cli/SPEC.md` | `# CLI validation`; `## Intent`: “Expose slice 01's inspection result through the existing CLI. Reuse its result rather than implementing a second parser. Resolve `../../NOTES.md#blank-required-cells` with the user before choosing the CLI outcome.” `## Acceptance`: “The CLI names missing columns, applies the recorded blank-cell rule, uses documented exit statuses and preserves input bytes. Focused valid/invalid cases and the existing relevant regression checks pass on the candidate supplied to dev-review.” |
| Both slices' `PROGRESS.md` | `# Progress`; `## Current position`: “Planned; no implementation or proof claimed. Record the exact candidate, completed checks, open dependency and current queue packet as work proceeds.” |
| Both slices' `PROOF.md` | `# Proof`; `## Evidence`: “No evidence yet. For each executed check record candidate, command, result, evidence path and limits. The independent checker attributes its own judgment separately from author checks.” |
@@ -471,15 +471,15 @@ The CLI implementation interface and check commands are repository-derived facts
## Bootstrap, context and refocus
1. **Current agent:** inspect the selected installation, repository instructions and existing project catalog. Use `rig --help`, `rig config get workspace.root`, `rig config get workspace.catalog_path`, `rig config get workspace.slices_root` and `rig workspace doctor` as appropriate. Preview an additive `rig config init-workspace --root <chosen-root> --dry-run` if no work tree exists. That scaffolder does not bind the roots or supply the metadata/lifecycle graph above. When setting up the intended instance, use ordinary config help to bind only the intended instance to the selected workspace/catalog/slices root; preserve other catalog entries. Do not silently point a shared daemon at a different project. Scope creation helpers may write the skeleton, but inspect and complete the actual manifests before compiling.
2. **Current agent, with the user's existing authority:** follow the public guide's prerequisite and permission choice once, preview `first-project`, plan it with the real code cwd, then deliberately launch it. Derive both live addresses and native readiness. Reuse existing appropriate seats; do not start duplicates just to clear prompts. Daemon/kernel readiness and each native seat's readiness are separate facts.
3. **Owner and checker:** read the repository instructions and relevant intent; derive their own identity and queue. For example, the owner can run `rig context work-install --project csv-tool --mission csv-validation --slice 01-inspect --deliver --runtime codex --cwd <actual-code-root> --json`; use `02-cli` for the dependent work and give the checker both exact slice addresses. `--deliver` returns composed bytes to its caller: it is not a transport acknowledgment. Do not use `--apply-skills` merely to make this example work. `install.skills: []` adds no private or invented skill requirement; discover applicable public skills normally.
2. **Current agent, with the user's existing authority:** follow the public guide's prerequisite and permission choice once, preview `starter`, plan it with the real code cwd, then deliberately launch it. Derive both live addresses and native readiness. Reuse existing appropriate seats; do not start duplicates just to clear prompts. Daemon/kernel readiness and each native seat's readiness are separate facts.
3. **Owner and checker:** read the repository instructions and relevant intent; derive their own identity and queue. For example, the builder can run `rig context work-install --project csv-tool --mission csv-validation --slice 01-inspect --deliver --runtime claude-code --cwd <actual-code-root> --json`; use `02-cli` for the dependent work and give the checker both exact slice addresses. `--deliver` returns composed bytes to its caller: it is not a transport acknowledgment. Do not use `--apply-skills` merely to make this example work. `install.skills: []` adds no private or invented skill requirement; discover applicable public skills normally.
4. **Bootstrap context delivery:** send the two seats a short instruction naming the exact work root and addressed files to retrieve; obtain their scope/role reaction before assigning implementation. A registered context pack can be sent with `rig send --context <discovered-ref>`; an arbitrary filesystem address is not automatically a context-pack ref. Deliver the actual composed bytes when a receiver cannot retrieve them. Keep instruction delivery separate from queue ownership.
5. **Minimal durable topology context:** derive `topology.root`, then preserve existing chain files. In a new dedicated example instance, put purpose/root pointers in `LEARNED.md`, the two-seat relationship in `rigs/first-project/LEARNED.md`, and short duties in `rigs/first-project/seats/dev-owner/LEARNED.md` and `.../dev-check/LEARNED.md`. Owner text: “Own the user's bounded outcome, implementation, exact check handoff, result and next-work custody; derive the current packet.” Checker text: “Independently judge the supplied candidate against project/mission/slice acceptance, record evidence and limits, and return judgment without self-assigning broader work.” Rig text points to the user's `SPEC.md#working-agreement` and active mission; instance text points to the configured work root. Do not copy a status roster into these files. Optional pod files and eight-region trees are unnecessary.
5. **Minimal durable topology context:** derive `topology.root`, then preserve existing chain files. In a new dedicated example instance, put purpose/root pointers in `LEARNED.md`, the two-seat relationship in `rigs/starter/LEARNED.md`, and short duties in `rigs/starter/seats/dev-build/LEARNED.md` and `.../dev-review/LEARNED.md`. Owner text: “Own the user's bounded outcome, implementation, exact check handoff, result and next-work custody; derive the current packet.” Checker text: “Independently judge the supplied candidate against project/mission/slice acceptance, record evidence and limits, and return judgment without self-assigning broader work.” Rig text points to the user's `SPEC.md#working-agreement` and active mission; instance text points to the configured work root. Do not copy a status roster into these files. Optional pod files and eight-region trees are unnecessary.
6. **Refocus delivery:** use the public `refocus-channel.md` and `chain-file-convention.md`, discovered under the selected instance reference directory. The ordinary hook derives roots and emits pointers at its supported prompt/compaction boundaries; it does not mean an edited file has been read. Ask each seat to run the discovered public refocusing procedure and read the relevant named sources once as part of bootstrap, recording any trace gap. Existing running seats do not inherit shell environment edits. Any explicit `OPENRIG_REFOCUS_WORK_NODE` or content override belongs in an intentionally configured launch context, not a claim that setting it in the sender changed another seat.
## Deliberate runtime creation and truthful continuation
The **actual owner seat**, after choosing the Workflow path, runs the following commands after context and address checks. The example addresses below are used only after its own `rig whoami --json` confirms `dev-owner@first-project`; an unbound bootstrap shell must not pretend to be that seat. `PROJECT_ROOT` is an ordinary task variable holding the selected absolute work root. Pick and record a unique operation key once, then reuse it after a timeout. Use the following commands for the selected graph:
The **actual owner seat**, after choosing the Workflow path, runs the following commands after context and address checks. The example addresses below are used only after its own `rig whoami --json` confirms `dev-build@starter`; an unbound bootstrap shell must not pretend to be that seat. `PROJECT_ROOT` is an ordinary task variable holding the selected absolute work root. Pick and record a unique operation key once, then reuse it after a timeout. Use the following commands for the selected graph:
```sh
rig workflow compile "$PROJECT_ROOT/missions/csv-validation/mission.yaml" \
@@ -488,7 +488,7 @@ rig workflow compile "$PROJECT_ROOT/missions/csv-validation/mission.yaml" \
rig workflow instantiate-lifecycle "$PROJECT_ROOT/missions/csv-validation/mission.yaml" \
--operation-key csv-tool-csv-validation-run-1 \
--root-objective 'Reviewed CSV validation without changing input data' \
--created-by dev-owner@first-project --rig first-project --json
--created-by dev-build@starter --rig starter --json
rig workflow operation csv-tool-csv-validation-run-1 --json
rig workflow continue <returned-instance-id> --json
@@ -500,7 +500,7 @@ At each completed step, the **current packet owner** projects its own result. Ex
```sh
rig workflow project --instance <instance-id> --current-packet <inspect-packet> \
--exit handoff --actor-session dev-owner@first-project \
--exit handoff --actor-session dev-build@starter \
--result-note 'Inspection contract implemented; exact candidate and checks recorded' \
--evidence-ref <absolute-slice-01-proof-path> --json
```
@@ -511,7 +511,7 @@ For a **real unresolved blank-cell product choice**, ask the user the concrete q
```sh
rig workflow project --instance <instance-id> --current-packet <cli-packet> \
--exit waiting --actor-session dev-owner@first-project \
--exit waiting --actor-session dev-build@starter \
--blocked-on external:user/blank-required-cells \
--result-note 'Need the user decision recorded in mission NOTES before selecting CLI behavior' \
--evidence-ref <absolute-mission-notes-path> --json
scripts/skill-edge-digests.generated.json
+7 -7
View File
@@ -7,12 +7,12 @@
"core/cross-host-rig-commands/SKILL.md": "844a578d0f51cf8f02f8bfd7ffb3bbd6a37d511f721266c0d758c49157c1447a",
"core/human-in-the-loop/SKILL.md": "14cf0c4a0dc89179121465d4b8d81d40406427351adcdc34f875097d1e6e9ab2",
"core/messaging-the-human/SKILL.md": "581372434f27b1994d516e144be1324c7c5981cacf64fef6f09d1a57017faa08",
"core/openrig-architect/SKILL.md": "c95f5f2bf1132402ded14d85e5c31d48e9b1e847aaf6c5218ce51dad175bdb5d",
"core/openrig-architect/SKILL.md": "84ca449328573e34953d1f6c2f1f359d1e79eda87516ac5ee8d3fcf98dff68da",
"core/openrig-cmux/SKILL.md": "73a86eac45d68b16a38fc0a4438713c634d86061073dac96a4d9e656ea5d34dc",
"core/openrig-herdr/SKILL.md": "37508a02f50bb69ee97c22c37ccf70aa8e37dc0784061eb2a5ad813571eebd1a",
"core/openrig-skills/SKILL.md": "3a55d25cacaef4700f8cd8bbc62f96aadba591057c065b3b453972727e9ef823",
"core/openrig-software-factory/SKILL.md": "33930e72341661eaaa9d3c5ac945297926f430d643b6f279fcb7f693ac30b7f7",
"core/openrig-software-factory/references/worked-example.md": "ff5485a0e84de43188cf791cc96258abe038d035d439997f21865e33a1916bc5",
"core/openrig-software-factory/SKILL.md": "647f0537d794c0de8f8130e54b3c9cb3ef44176850695ac1dd0b21cb8c62480e",
"core/openrig-software-factory/references/worked-example.md": "48aa57a473ac39ec623fe0c01e1ffd7594e5ece78f07d9ce444f361bae4dab7e",
"core/openrig-upgrade/SKILL.md": "c3555c66abe0426e2990aec024849f644cf43320a65b8f1211e96d3b234f6e83",
"core/openrig-upgrade/scripts/backup-sqlite.mjs": "52fe3015a0399986b586b6603e0664f61136d2210611b1638110a7b6b06e38b4",
"core/openrig-upgrade/scripts/inspect-upgrade.mjs": "0f9239f3f8ad75885e985433576ffba9cf155dd8616801dd73d60bf3e9990a2a",
@@ -82,7 +82,7 @@
"openrig-operating-model/templates/SOP.md": "1eaf0daf4f9bbf0715e6a5aaf0f29f030af5fe8b8a10232488ee97c507afa6dc",
"openrig-operating-model/templates/SPEC.md": "f126536daa59cea3f1cfb0898d83c7cdf99f6392f6f155ea64fe55187dd0f5f1",
"openrig-skills/SKILL.md": "3a55d25cacaef4700f8cd8bbc62f96aadba591057c065b3b453972727e9ef823",
"openrig-user/SKILL.md": "b866b2f7fbff98089aeeac33868566b9c8a49f0de0a1d414a8cc73222085a6fd",
"openrig-user/SKILL.md": "f7b91d3c45f3a18bc58f50f5ccbf63615d4f8db30bc95e208c787326a02ba7b0",
"orienting-to-an-inherited-seat/CHANGELOG.md": "4d0970e75e5c15b00a48d6a7150376d646257777264fd1b9a191165a8d5a6e84",
"orienting-to-an-inherited-seat/SKILL.md": "65300ce0e299cce0148a8bacd51b0475ac1b59cd77a51a9bb2db9d43bda6e208",
"queue-handoff/SKILL.md": "d4d7e3e8772886b3771daffd60523b5f79040309b892c8be1afd47d1f7287f7b",
@@ -104,12 +104,12 @@
"core/cross-host-rig-commands/SKILL.md": "844a578d0f51cf8f02f8bfd7ffb3bbd6a37d511f721266c0d758c49157c1447a",
"core/human-in-the-loop/SKILL.md": "14cf0c4a0dc89179121465d4b8d81d40406427351adcdc34f875097d1e6e9ab2",
"core/messaging-the-human/SKILL.md": "581372434f27b1994d516e144be1324c7c5981cacf64fef6f09d1a57017faa08",
"core/openrig-architect/SKILL.md": "c95f5f2bf1132402ded14d85e5c31d48e9b1e847aaf6c5218ce51dad175bdb5d",
"core/openrig-architect/SKILL.md": "84ca449328573e34953d1f6c2f1f359d1e79eda87516ac5ee8d3fcf98dff68da",
"core/openrig-cmux/SKILL.md": "73a86eac45d68b16a38fc0a4438713c634d86061073dac96a4d9e656ea5d34dc",
"core/openrig-herdr/SKILL.md": "37508a02f50bb69ee97c22c37ccf70aa8e37dc0784061eb2a5ad813571eebd1a",
"core/openrig-skills/SKILL.md": "3a55d25cacaef4700f8cd8bbc62f96aadba591057c065b3b453972727e9ef823",
"core/openrig-software-factory/SKILL.md": "33930e72341661eaaa9d3c5ac945297926f430d643b6f279fcb7f693ac30b7f7",
"core/openrig-software-factory/references/worked-example.md": "ff5485a0e84de43188cf791cc96258abe038d035d439997f21865e33a1916bc5",
"core/openrig-software-factory/SKILL.md": "647f0537d794c0de8f8130e54b3c9cb3ef44176850695ac1dd0b21cb8c62480e",
"core/openrig-software-factory/references/worked-example.md": "48aa57a473ac39ec623fe0c01e1ffd7594e5ece78f07d9ce444f361bae4dab7e",
"core/openrig-upgrade/SKILL.md": "c3555c66abe0426e2990aec024849f644cf43320a65b8f1211e96d3b234f6e83",
"core/openrig-upgrade/scripts/backup-sqlite.mjs": "52fe3015a0399986b586b6603e0664f61136d2210611b1638110a7b6b06e38b4",
"core/openrig-upgrade/scripts/inspect-upgrade.mjs": "0f9239f3f8ad75885e985433576ffba9cf155dd8616801dd73d60bf3e9990a2a",
scripts/vm-bootstrap/two-daemon-start.sh
+1 -1
View File
@@ -86,7 +86,7 @@ start_daemon_or_explain_reset "populated" "$POPULATED_HOME" "$POPULATED_PORT"
echo
echo "==> Both daemons up. Seed the populated daemon with sample data:"
echo " OPENRIG_HOME=$POPULATED_HOME OPENRIG_PORT=$POPULATED_PORT \\"
echo " rig up product-team # instantiate a sample rig"
echo " rig up factory # instantiate a sample rig"
echo
echo " Copy workflow fixtures to operator workspace specs dir:"
echo " cp $FIXTURE_DIR/workflows/*.yaml \\"
skills/_canonical/core/openrig-architect/SKILL.md
+3 -3
View File
@@ -92,7 +92,7 @@ Every rig is organized into pods — bounded context groups where members share
**Sizing principles:**
- **Solo agent:** Only when the task is genuinely single-person (quick script, simple question). No rig needed.
- **Pair (2 agents):** The minimum effective unit for quality work. One does, one verifies. The `implementation-pair` pattern.
- **Pair (2 agents):** The minimum effective unit for quality work. One does, one verifies. The built-in `starter` team's shape.
- **Small team (3-5 agents):** Orchestrator + one or two working pods. Good starting point for focused projects.
- **Full team (6-10 agents):** Multiple bounded contexts with orchestration, development, review, and potentially research or design.
- **Large team (10-40+ agents):** Complex projects with many concerns. Include pods for development, review, research, documentation, release management, strategy, and any other bounded context the project needs.
@@ -178,7 +178,7 @@ This is where most rigs succeed or fail. The topology is mechanical; the startup
**For serious rigs, also include:**
4. `startup/context.md` per agent — boot-time grounding (project info, environment details)
5. Pod SOP skills — how each pod operates (implementation-pair SOP, review-pair SOP, etc.)
5. Pod SOP skills — how each pod operates (build-pair SOP, review-pair SOP, etc.)
6. Project-specific documentation in rig-level startup files
**The key principle:** An agent that boots without knowing its role, its team's culture, and its project context will produce generic, unhelpful work. The startup content IS the product value. Invest in it.
@@ -356,7 +356,7 @@ pods:
**Use when:** The work involves operating software, not just writing code.
### The Full Product Team
**7 agents, 3 pods.** The kitchen-sink topology: orchestration pair, development pod (impl + qa + design), review pair. See the `product-team` starter spec for the complete worked example.
**7 agents, 3 pods.** The kitchen-sink topology: orchestration pair, development pod (impl + qa + design), review pair. See the built-in `factory` spec for the complete worked example.
**Use when:** Full product development with design, implementation, QA, and independent review. Requires strong culture and SOP content to keep all agents engaged.
skills/_canonical/core/openrig-software-factory/SKILL.md
+11 -8
View File
@@ -37,13 +37,16 @@ read [references/worked-example.md](references/worked-example.md). Installed cop
`rig context get skills/core/openrig-software-factory/references/worked-example.md`.
A roadmap, YAML file or wake does not execute work or authorize a new outcome.
## Choose the first project's providers
## Choose the first team and its providers
Ask which working account(s) the user wants: Claude Code, Codex, or both. Reuse
an explicit choice and recommend the account they already have working. Use
`first-project-claude` (two Claude), `first-project` (two Codex), or
`first-project-mixed` (Claude owner, Codex checker). All share the same task and
owner/checker culture. Check only selected CLIs/logins; request `claude auth login`
Ask what the user wants to build and which working account(s) they have: Claude
Code, Codex, or both. Recommend one of three teams: `starter` (a Claude builder
and a Codex reviewer, for one bounded change), `workshop` (a lead, a builder, QA
and a reviewer; a rig bundle installed from its pinned listing) or `factory` (seven
agents for sustained product work). When the user lacks a provider a team needs,
write an adapted copy of the team under the same name, as the kernel operator's
guidance describes; never offer per-provider variants. `first-project` is
starter's old name. Check only the CLIs/logins the team needs; request `claude auth login`
or `codex login` once when that selected login is missing. No credential copying,
unused provider prerequisite or silent model/provider fallback.
@@ -55,8 +58,8 @@ Do not add an unused-provider login gate or manual kernel setup to this path.
An instance-wide provider restriction is a separate request. Preserve an
existing kernel and working user rigs.
Show the chosen recipe, resolved runtimes/models and exact
`rig up <starter> --cwd . --plan` / `rig up <starter> --cwd .` commands. Codex seats
Show the chosen team, resolved runtimes/models and exact
`rig up <team> --cwd . --plan` / `rig up <team> --cwd .` commands. Codex seats
retain `gpt-6-astra`; Claude seats use the configured native default without an
OpenRig model override. Confirm that model with the user and its availability;
verify the native session's actual model before consequential work. Use the
skills/_canonical/core/openrig-software-factory/references/worked-example.md
+29 -29
View File
@@ -4,7 +4,7 @@ Use this example to adapt reviewed work to a repository with CSV handling. Choos
This is a concrete CSV-validation example for adaptation, not a requirement that an arbitrary repository become a CSV project or every outcome be split into two slices. This example uses two genuinely dependent slices. Select a real, authorized repository and record its starting commit and existing CSV behavior. If it has no relevant CSV code, choose two dependent changes appropriate to that repository and rewrite the example objectives before execution; ordinary user tasks retain their appropriate size.
For the example only, repository root and work root are the same absolute directory, called `PROJECT_ROOT`. The selected project ID is `csv-tool`, mission is `csv-validation`, and rig is the shipped `first-project`. These are authored example identities, not live discoveries. Resolve existing catalog/config/intent first. Never overwrite a real `project.yaml`, `workspace.yaml`, `SPEC.md`, `AGENTS.md`, or existing mission to install a template. Merge compatible fields deliberately or choose an unused work directory and preserve the existing catalog entries. If using a separate work root, launch seats in the code repository and record both roots in intent/context. Keep `project.yaml` two directories above the mission directory for this compiler path; arbitrary custom mission-root layouts are not established here.
For the example only, repository root and work root are the same absolute directory, called `PROJECT_ROOT`. The selected project ID is `csv-tool`, mission is `csv-validation`, and rig is the shipped `starter`. These are authored example identities, not live discoveries. Resolve existing catalog/config/intent first. Never overwrite a real `project.yaml`, `workspace.yaml`, `SPEC.md`, `AGENTS.md`, or existing mission to install a template. Merge compatible fields deliberately or choose an unused work directory and preserve the existing catalog entries. If using a separate work root, launch seats in the code repository and record both roots in intent/context. Keep `project.yaml` two directories above the mission directory for this compiler path; arbitrary custom mission-root layouts are not established here.
## Manual work and the queue loop
@@ -16,12 +16,12 @@ in the project's existing files.
When work should outlive a turn, the actual owner verifies its identity and uses
the queue. In this example, owner/checker addresses are synthetic until verified
against the real `first-project` team. The task file contains the real outcome,
against the real `starter` team. The task file contains the real outcome,
boundary, acceptance and evidence pointers; create it before sending:
```sh
rig whoami --json
rig queue create --destination dev-owner@first-project \
rig queue create --destination dev-build@starter \
--body-file ./TASK.md --summary 'Implement the agreed CSV inspection' --json
rig queue claim <returned-qitem-id> --json
```
@@ -29,7 +29,7 @@ rig queue claim <returned-qitem-id> --json
After implementing and checking the cumulative candidate, the current owner uses:
```sh
rig queue handoff <owned-qitem-id> --to dev-check@first-project \
rig queue handoff <owned-qitem-id> --to dev-review@starter \
--body-file ./REVIEW-REQUEST.md --json
```
@@ -100,7 +100,7 @@ work unattended.
## Grow the running team
Keep `first-project`'s owner and checker when they are enough. When there is useful
Keep `starter`'s builder and reviewer when they are enough. When there is useful
independent work, add one or two seats to that running rig. The example below adds
two builders; it does not require a larger starter, new Workflow or replacement
sessions. Use the actual rig name if yours differs.
@@ -112,23 +112,23 @@ general-purpose agent:
```sh
rig ps --json
rig ps --nodes --rig first-project --json
rig queue list --destination dev-owner@first-project --json
rig ps --nodes --rig starter --json
rig queue list --destination dev-build@starter --json
rig specs show orchestrator --kind agent --json
rig grow --help
```
Set `RIG_ID` to the `rigId` for the running `first-project`, and `PROJECT_ROOT`
Set `RIG_ID` to the `rigId` for the running `starter`, and `PROJECT_ROOT`
to the absolute code repository. Verify its existing `dev` pod and choose unused
member names. When the user has authorized the added capacity and cost, run:
```sh
rig grow "$RIG_ID" a b --pod dev --runtime codex --cwd "$PROJECT_ROOT" --json
rig ps --nodes --rig first-project --json
rig ps --nodes --rig starter --json
```
For one builder, omit `b`. The expected new logical IDs are `dev.a` and `dev.b`,
with addresses `dev-a@first-project` and `dev-b@first-project`; use the actual
with addresses `dev-a@starter` and `dev-b@starter`; use the actual
returned identities. The command adds and launches the named seats.
To put those seats in a **new** pod instead, choose this alternative once, with an
@@ -163,8 +163,8 @@ checks, next owner and stopping condition. Then deliver the context instruction,
for example for the first builder:
```sh
rig send dev-a@first-project "Read $PROJECT_ROOT/SPEC.md and the addressed sources in $PROJECT_ROOT/.openrig/factory/TASK-A.md. Run rig whoami --json and rig queue list --owned --json in your own seat; report your identity, scope and any native readiness/permission blocker. Await the bounded queue assignment."
rig capture dev-a@first-project
rig send dev-a@starter "Read $PROJECT_ROOT/SPEC.md and the addressed sources in $PROJECT_ROOT/.openrig/factory/TASK-A.md. Run rig whoami --json and rig queue list --owned --json in your own seat; report your identity, scope and any native readiness/permission blocker. Await the bounded queue assignment."
rig capture dev-a@starter
```
Read the actual reply and pane; resolve startup/login/permission prompts under the
@@ -174,7 +174,7 @@ the coordinator creates the distinct agreed task (or hands off an existing owned
task instead of duplicating it):
```sh
rig queue create --destination dev-a@first-project \
rig queue create --destination dev-a@starter \
--body-file "$PROJECT_ROOT/.openrig/factory/TASK-A.md" \
--summary 'Implement the agreed independent change A' --json
```
@@ -190,9 +190,9 @@ working agreement and assigned work, not the seat's name or default agent label.
| Seat in this example | Deliberately agreed responsibility |
| --- | --- |
| `dev-owner@first-project` | Initially implements and coordinates; can become the dedicated orchestrator, selecting outcomes, separating tasks, owning integration and retaining next-work custody. |
| `dev-a@first-project`, `dev-b@first-project` | Implement distinct authorized tasks and return exact candidates/evidence. Neither silently edits the other's files or folds both candidates without integration ownership. |
| `dev-check@first-project` | Retains independent judgment under the project's review policy. The implementer does not count its own check as independent review. |
| `dev-build@starter` | Initially implements and coordinates; can become the dedicated orchestrator, selecting outcomes, separating tasks, owning integration and retaining next-work custody. |
| `dev-a@starter`, `dev-b@starter` | Implement distinct authorized tasks and return exact candidates/evidence. Neither silently edits the other's files or folds both candidates without integration ownership. |
| `dev-review@starter` | Retains independent judgment under the project's review policy. The implementer does not count its own check as independent review. |
This is one progression, not a required four-seat layout. One extra builder may
be enough; a different workload may justify a specialist or additional independent
@@ -213,7 +213,7 @@ rewrite the starter or your original authored `rig.yaml`. Save a
separate live export to an unused user-owned path:
```sh
rig export "$RIG_ID" -o "$PROJECT_ROOT/.openrig/factory/first-project-expanded.yaml"
rig export "$RIG_ID" -o "$PROJECT_ROOT/.openrig/factory/starter-expanded.yaml"
```
Inspect the export and reconcile it with your user-owned authored RigSpec, retaining
@@ -326,14 +326,14 @@ lifecycle:
workflow:
objective: Add reviewed CSV validation without modifying input data
target:
rig: first-project
rig: starter
entry:
role: owner
roles:
owner:
preferred_targets: [dev-owner@first-project]
preferred_targets: [dev-build@starter]
checker:
preferred_targets: [dev-check@first-project]
preferred_targets: [dev-review@starter]
context_refs:
- SPEC.md#intent
- SPEC.md#acceptance
@@ -457,12 +457,12 @@ Complete initial Markdown bodies are specified below, after those frontmatter bl
| File relative to `PROJECT_ROOT` | Initial headings and bodies |
| --- | --- |
| `SPEC.md` | `# CSV tool`; `## Purpose`: “Help a person detect invalid CSV input before an import changes data.” `## Working agreement`: “Preserve existing repository rules, data and unrelated edits. The first-project owner coordinates implementation and continuity; dev-check independently checks the exact cumulative candidate. The user decides unresolved product behavior. Agreed local implementation, regression checks and review need no repeated approval; publication, destructive data changes and new external effects remain outside this task. Read the current queue and mission before acting; record evidence and unresolved facts, not invented completion.” |
| `SPEC.md` | `# CSV tool`; `## Purpose`: “Help a person detect invalid CSV input before an import changes data.” `## Working agreement`: “Preserve existing repository rules, data and unrelated edits. The starter builder coordinates implementation and continuity; dev-review independently checks the exact cumulative candidate. The user decides unresolved product behavior. Agreed local implementation, regression checks and review need no repeated approval; publication, destructive data changes and new external effects remain outside this task. Read the current queue and mission before acting; record evidence and unresolved facts, not invented completion.” |
| `missions/csv-validation/SPEC.md` | `# CSV validation`; `## Intent`: “A user can inspect a CSV and receive a useful validation result without changing the input file or imported data. First implement a pure inspection result; then expose it in the existing CLI.” `## Acceptance`: “Missing required headers name every missing column. Valid input passes. The CLI uses the inspection result and its chosen blank-cell rule, returns the repository's documented success/failure status and preserves input bytes. Tests exercise both slices. One independent checker records the exact candidate, commands, results and limits. The owner explains how to try it and preserves next-work custody. No publication.” |
| `missions/csv-validation/NOTES.md` | `# Decisions`; `## Blank required cells`: “PENDING — the user must decide whether a present required column containing blank cells is rejected or accepted. Slice 01 can report those cells without choosing policy; slice 02 must not guess the CLI rule. Record the user's decision, timestamp and source here.” |
| `missions/csv-validation/PROGRESS.md` | `# Progress`; `## Current position`: “Planned; no implementation, runtime instance or review result yet. Record the operation key, instance/frontier IDs, current owner, candidate and next action when observed.” |
| `missions/csv-validation/slices/01-inspect/SPEC.md` | `# Inspect CSV`; `## Intent`: “Add or adapt a pure inspection function using the repository's CSV handling. Return missing required headers and blank required cells with row/column locations; do not modify input or choose the pending CLI blank-cell policy.” `## Acceptance`: “Missing-header, valid-input, quoted-field and blank-cell cases produce the documented result. Input bytes and existing import behavior remain unchanged. Record actual commands and candidate for the cumulative checker.” |
| `missions/csv-validation/slices/02-cli/SPEC.md` | `# CLI validation`; `## Intent`: “Expose slice 01's inspection result through the existing CLI. Reuse its result rather than implementing a second parser. Resolve `../../NOTES.md#blank-required-cells` with the user before choosing the CLI outcome.” `## Acceptance`: “The CLI names missing columns, applies the recorded blank-cell rule, uses documented exit statuses and preserves input bytes. Focused valid/invalid cases and the existing relevant regression checks pass on the candidate supplied to dev-check.” |
| `missions/csv-validation/slices/02-cli/SPEC.md` | `# CLI validation`; `## Intent`: “Expose slice 01's inspection result through the existing CLI. Reuse its result rather than implementing a second parser. Resolve `../../NOTES.md#blank-required-cells` with the user before choosing the CLI outcome.” `## Acceptance`: “The CLI names missing columns, applies the recorded blank-cell rule, uses documented exit statuses and preserves input bytes. Focused valid/invalid cases and the existing relevant regression checks pass on the candidate supplied to dev-review.” |
| Both slices' `PROGRESS.md` | `# Progress`; `## Current position`: “Planned; no implementation or proof claimed. Record the exact candidate, completed checks, open dependency and current queue packet as work proceeds.” |
| Both slices' `PROOF.md` | `# Proof`; `## Evidence`: “No evidence yet. For each executed check record candidate, command, result, evidence path and limits. The independent checker attributes its own judgment separately from author checks.” |
@@ -471,15 +471,15 @@ The CLI implementation interface and check commands are repository-derived facts
## Bootstrap, context and refocus
1. **Current agent:** inspect the selected installation, repository instructions and existing project catalog. Use `rig --help`, `rig config get workspace.root`, `rig config get workspace.catalog_path`, `rig config get workspace.slices_root` and `rig workspace doctor` as appropriate. Preview an additive `rig config init-workspace --root <chosen-root> --dry-run` if no work tree exists. That scaffolder does not bind the roots or supply the metadata/lifecycle graph above. When setting up the intended instance, use ordinary config help to bind only the intended instance to the selected workspace/catalog/slices root; preserve other catalog entries. Do not silently point a shared daemon at a different project. Scope creation helpers may write the skeleton, but inspect and complete the actual manifests before compiling.
2. **Current agent, with the user's existing authority:** follow the public guide's prerequisite and permission choice once, preview `first-project`, plan it with the real code cwd, then deliberately launch it. Derive both live addresses and native readiness. Reuse existing appropriate seats; do not start duplicates just to clear prompts. Daemon/kernel readiness and each native seat's readiness are separate facts.
3. **Owner and checker:** read the repository instructions and relevant intent; derive their own identity and queue. For example, the owner can run `rig context work-install --project csv-tool --mission csv-validation --slice 01-inspect --deliver --runtime codex --cwd <actual-code-root> --json`; use `02-cli` for the dependent work and give the checker both exact slice addresses. `--deliver` returns composed bytes to its caller: it is not a transport acknowledgment. Do not use `--apply-skills` merely to make this example work. `install.skills: []` adds no private or invented skill requirement; discover applicable public skills normally.
2. **Current agent, with the user's existing authority:** follow the public guide's prerequisite and permission choice once, preview `starter`, plan it with the real code cwd, then deliberately launch it. Derive both live addresses and native readiness. Reuse existing appropriate seats; do not start duplicates just to clear prompts. Daemon/kernel readiness and each native seat's readiness are separate facts.
3. **Owner and checker:** read the repository instructions and relevant intent; derive their own identity and queue. For example, the builder can run `rig context work-install --project csv-tool --mission csv-validation --slice 01-inspect --deliver --runtime claude-code --cwd <actual-code-root> --json`; use `02-cli` for the dependent work and give the checker both exact slice addresses. `--deliver` returns composed bytes to its caller: it is not a transport acknowledgment. Do not use `--apply-skills` merely to make this example work. `install.skills: []` adds no private or invented skill requirement; discover applicable public skills normally.
4. **Bootstrap context delivery:** send the two seats a short instruction naming the exact work root and addressed files to retrieve; obtain their scope/role reaction before assigning implementation. A registered context pack can be sent with `rig send --context <discovered-ref>`; an arbitrary filesystem address is not automatically a context-pack ref. Deliver the actual composed bytes when a receiver cannot retrieve them. Keep instruction delivery separate from queue ownership.
5. **Minimal durable topology context:** derive `topology.root`, then preserve existing chain files. In a new dedicated example instance, put purpose/root pointers in `LEARNED.md`, the two-seat relationship in `rigs/first-project/LEARNED.md`, and short duties in `rigs/first-project/seats/dev-owner/LEARNED.md` and `.../dev-check/LEARNED.md`. Owner text: “Own the user's bounded outcome, implementation, exact check handoff, result and next-work custody; derive the current packet.” Checker text: “Independently judge the supplied candidate against project/mission/slice acceptance, record evidence and limits, and return judgment without self-assigning broader work.” Rig text points to the user's `SPEC.md#working-agreement` and active mission; instance text points to the configured work root. Do not copy a status roster into these files. Optional pod files and eight-region trees are unnecessary.
5. **Minimal durable topology context:** derive `topology.root`, then preserve existing chain files. In a new dedicated example instance, put purpose/root pointers in `LEARNED.md`, the two-seat relationship in `rigs/starter/LEARNED.md`, and short duties in `rigs/starter/seats/dev-build/LEARNED.md` and `.../dev-review/LEARNED.md`. Owner text: “Own the user's bounded outcome, implementation, exact check handoff, result and next-work custody; derive the current packet.” Checker text: “Independently judge the supplied candidate against project/mission/slice acceptance, record evidence and limits, and return judgment without self-assigning broader work.” Rig text points to the user's `SPEC.md#working-agreement` and active mission; instance text points to the configured work root. Do not copy a status roster into these files. Optional pod files and eight-region trees are unnecessary.
6. **Refocus delivery:** use the public `refocus-channel.md` and `chain-file-convention.md`, discovered under the selected instance reference directory. The ordinary hook derives roots and emits pointers at its supported prompt/compaction boundaries; it does not mean an edited file has been read. Ask each seat to run the discovered public refocusing procedure and read the relevant named sources once as part of bootstrap, recording any trace gap. Existing running seats do not inherit shell environment edits. Any explicit `OPENRIG_REFOCUS_WORK_NODE` or content override belongs in an intentionally configured launch context, not a claim that setting it in the sender changed another seat.
## Deliberate runtime creation and truthful continuation
The **actual owner seat**, after choosing the Workflow path, runs the following commands after context and address checks. The example addresses below are used only after its own `rig whoami --json` confirms `dev-owner@first-project`; an unbound bootstrap shell must not pretend to be that seat. `PROJECT_ROOT` is an ordinary task variable holding the selected absolute work root. Pick and record a unique operation key once, then reuse it after a timeout. Use the following commands for the selected graph:
The **actual owner seat**, after choosing the Workflow path, runs the following commands after context and address checks. The example addresses below are used only after its own `rig whoami --json` confirms `dev-build@starter`; an unbound bootstrap shell must not pretend to be that seat. `PROJECT_ROOT` is an ordinary task variable holding the selected absolute work root. Pick and record a unique operation key once, then reuse it after a timeout. Use the following commands for the selected graph:
```sh
rig workflow compile "$PROJECT_ROOT/missions/csv-validation/mission.yaml" \
@@ -488,7 +488,7 @@ rig workflow compile "$PROJECT_ROOT/missions/csv-validation/mission.yaml" \
rig workflow instantiate-lifecycle "$PROJECT_ROOT/missions/csv-validation/mission.yaml" \
--operation-key csv-tool-csv-validation-run-1 \
--root-objective 'Reviewed CSV validation without changing input data' \
--created-by dev-owner@first-project --rig first-project --json
--created-by dev-build@starter --rig starter --json
rig workflow operation csv-tool-csv-validation-run-1 --json
rig workflow continue <returned-instance-id> --json
@@ -500,7 +500,7 @@ At each completed step, the **current packet owner** projects its own result. Ex
```sh
rig workflow project --instance <instance-id> --current-packet <inspect-packet> \
--exit handoff --actor-session dev-owner@first-project \
--exit handoff --actor-session dev-build@starter \
--result-note 'Inspection contract implemented; exact candidate and checks recorded' \
--evidence-ref <absolute-slice-01-proof-path> --json
```
@@ -511,7 +511,7 @@ For a **real unresolved blank-cell product choice**, ask the user the concrete q
```sh
rig workflow project --instance <instance-id> --current-packet <cli-packet> \
--exit waiting --actor-session dev-owner@first-project \
--exit waiting --actor-session dev-build@starter \
--blocked-on external:user/blank-required-cells \
--result-note 'Need the user decision recorded in mission NOTES before selecting CLI behavior' \
--evidence-ref <absolute-mission-notes-path> --json