@openrig/cli 0.6.5 → 0.6.7

package/daemon/specs/agents/shared/skills/core/openrig-software-factory/references/worked-example.md

@@ -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
 ```
 
@@ -86,8 +86,8 @@ permissions, supplies a missing product decision or authorizes more work.
 
 ## Permissions at the point of work
 
-Before the first task, ask the agent to configure your choice: keep prompts,
-remember selected commands, or deliberately select broader access. Use
+Before the first task, ask the agent to configure your choice: keep the team
+default, remember selected commands, or deliberately select broader access. Use
 `rig context get skills/applying-a-permission-policy/SKILL.md`, or the
 [compatible source/package paths](../SKILL.md#find-the-compatible-permission-guide).
 The agent handles setup and verifies the actual conversation; the user need not
@@ -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

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

@@ -239,6 +239,8 @@ host in front of you.
     mechanism; this skill does not rewrite launchers.
 11. Record the observed result, remaining local preservation decisions, and the
     exact rollback runtime and backup.
+12. Read what changed in the new version, `rig context get reference/whats-new.md`,
+    and tell your user anything in it that changes how they work.
 
 ## Stop and hand back when
 

package/daemon/specs/agents/shared/skills/core/rig-bundles-and-shareable-artifacts/SKILL.md

@@ -97,5 +97,4 @@ every workflow a daemon feature.**
 - `extension-and-user-workspace` skill — sibling primitive for user-owned behavior added to runtime; bundle vs extension boundary
 - `specification-system` skill — rig specs / agent specs / workflow specs that bundles package
 - `agent-starters` skill — bundles can include or reference Agent Starters
-- `composable-priming-packs` skill — bundles can package priming packs
 - `openrig-user` skill — `rig bundle create / inspect / install` CLI surface

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

@@ -7,15 +7,10 @@ metadata:
     stage: factory-approved
     sibling_skills:
       - claude-compaction-restore
-      - mental-model-ha
-      - scope-recovery
       - session-compaction-and-restore
       - agent-startup-and-context-ingestion
       - agent-starters
-      - composable-priming-packs
       - seat-continuity-and-handover
-      - claude-compact-in-place
-      - pre-maintenance-agent-preservation
 ---
 
 # session_source Fork

package/daemon/specs/agents/shared/skills/process/agent-browser/OPENRIG.md

@@ -17,7 +17,7 @@ OpenRig ships `agent-browser` so any agent dispatched by an OpenRig topology can
 
 ## OpenRig-specific modifications
 
-This is the canonical example of the **add-supplementary-files** pattern (see `writing-skills-for-openrig` SKILL.md §"Vendored skills"). The upstream skill is kept structurally intact; OpenRig adds a companion file that captures local-use insights without polluting the upstream content.
+This is the canonical example of the **add-supplementary-files** pattern. The upstream skill is kept structurally intact; OpenRig adds a companion file that captures local-use insights without polluting the upstream content.
 
 | Surface | What changed | Why |
 |---|---|---|

package/daemon/specs/agents/shared/skills/process/systematic-debugging/SKILL.md

@@ -181,7 +181,6 @@ You MUST complete each phase before proceeding to the next.
    - Automated test if possible
    - One-off test script if no framework
    - MUST have before fixing
-   - Use the `superpowers:test-driven-development` skill for writing proper failing tests
 
 2. **Implement Single Fix**
    - Address the root cause identified
@@ -289,7 +288,6 @@ These techniques are part of systematic debugging and available in this director
 - **`condition-based-waiting.md`** - Replace arbitrary timeouts with condition polling
 
 **Related skills:**
-- **superpowers:test-driven-development** - For creating failing test case (Phase 4, Step 1)
 - **superpowers:verification-before-completion** - Verify fix worked before claiming success
 
 ## Real-World Impact

package/daemon/specs/rigs/focused/{adversarial-review → code-review}/rig.yaml

@@ -1,5 +1,5 @@
 version: "0.2"
-name: adversarial-review
+name: code-review
 summary: >
   Dual independent reviewers with an orchestrator. Each reviewer
   analyzes the code independently, then the orchestrator synthesizes

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

@@ -0,0 +1,21 @@
+# PM Team Culture
+
+## Mission
+Ship features that solve real customer problems with evidence-backed requirements.
+
+## Working Norms
+
+1. **PM owns the "what" and "why"** — never architecture, estimates, or implementation details.
+2. **Research before you build** — every feature needs context (competitive, regulatory, customer) before requirements are finalized.
+3. **Requirements are literal** — AI agents treat requirements.md as instructions. Be precise. No aspirational content.
+4. **Stay in your lane** — PM writes requirements, researcher gathers context, coder builds prototypes. Escalate when you hit a boundary.
+5. **Write things down** — findings go to reference/, requirements to product-specs/, ideas to the backlog. Nothing lives only in conversation.
+
+## Communication
+- PM agent is the hub. Research and code agents report to PM.
+- Coder can observe researcher output for domain context.
+- When blocked, escalate to PM rather than guessing.
+
+## Mission/slice tracking (the SDLC)
+
+Requirements and delivery are tracked as missions and slices — on-disk markdown the Living Notes UI projects. Load the packaged `mission-slice-sop` skill; the conventions live in `docs/reference/sdlc-conventions.md` (installed: `$OPENRIG_HOME/reference/sdlc-conventions.md`; shipped with the CLI package). PM's leg of the flow: record intent verbatim, author the mini-requirements (the one-glance tier where approval starts) + the proof contract (promised deliverables as observable outcomes; UI deliverables name their planned mockup), then plan-lock with `rig scope slice approve --scope spec`. Proof-lock (`--scope delivery`) is the terminal sign-off after QA's visual compare and `rig proof add … --media` drops (the C1 drop verb).

package/daemon/specs/rigs/focused/{pm-team → pm}/rig.yaml

@@ -1,5 +1,5 @@
 version: "0.2"
-name: pm-team
+name: pm
 culture_file: CULTURE.md
 summary: >
   Product management rig with a PM lead running the 8-step feature flow
@@ -32,7 +32,7 @@ pods:
   - id: dev
     label: Development Support
     members:
-      - id: coder
+      - id: build
         agent_ref: "local:../../../agents/development/implementer"
         runtime: claude-code
         profile: default
@@ -42,10 +42,10 @@ pods:
 edges:
   - kind: delegates_to
     from: pm.lead
-    to: dev.coder
+    to: dev.build
   - kind: can_observe
-    from: dev.coder
+    from: dev.build
     to: pm.researcher
   - kind: escalates_to
-    from: dev.coder
+    from: dev.build
     to: pm.lead

package/daemon/specs/rigs/focused/{research-team → research}/rig.yaml

@@ -1,5 +1,5 @@
 version: "0.2"
-name: research-team
+name: research
 summary: >
   Research topology with an orchestrator coordinating an analyst
   and a synthesizer. The analyst does deep-dive investigation,

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

@@ -0,0 +1,96 @@
+# Factory — Team Culture
+
+This is the human-operated product-development starter. It uses a full factory topology: a lead and a PM advisor, a development pod with implementation, QA, and design, plus two reviewers.
+
+## Work selection
+
+Derive identity with `rig whoami --json`, then follow
+`project.yaml -> mission.yaml -> active slice.yaml -> selected component or wave
+map -> addressed context`. Use
+`docs/reference/product-journey-sdlc.md#resolve-the-selected-path` (installed:
+`$OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path`).
+No selection means light Part A. Only the selected work's required capabilities
+need to be ready; do not wait for the whole topology or invent work for idle roles.
+
+Orchestration routes outcomes and resolves exceptions. Implementation completes
+coherent changes and verifies by effect. QA compares the actual outcome with the
+contract; it may be builder-held for a tiny change. Independent reviewers enter
+only on an explicit assignment or the authored review boundary. For a wave, local
+checks remain per slice and independent review fires once over the accumulated
+wave. A named rigorous slice retains its selected checks. A topology does not
+select a pre-edit, QA, guard, review or lock gate.
+
+Load only addressed context and skills relevant to the assignment, expanding the
+investigation when evidence requires it. Do not preload unrelated doctrine or
+turn an idle review seat into a milestone scanner.
+
+## Design workflow
+
+`dev.design` works ahead of implementation:
+- Turns ambiguous product goals into concrete UX flows
+- Hands implementation enough detail to build without inventing core UX
+- Reviews shipped results for coherence
+
+## When blocked
+
+If a command fails due to permissions:
+1. Identify the exact command: e.g., `git commit`, `npm test`, `rig send`
+2. Tell the human clearly: "I need `<specific permission>` to continue. Without it, I cannot `<specific consequence>`."
+3. Suggest the one-time fix (e.g., adding to the allow list, granting write access)
+4. Continue with what you can do while waiting
+
+If blocked on another agent:
+1. Send them a direct message: `rig send <session> "I'm waiting on <specific thing>" --verify`
+2. If they don't respond within a reasonable time, escalate to the orchestrator
+3. Do not stall silently
+
+## After startup or compaction
+
+Run `rig whoami --json` immediately. This tells you who you are, who your peers are, and how to reach them.
+
+## Culture
+
+These are not suggestions. They are the values this team operates by.
+
+### Quality over speed
+
+There is no deadline pressure. Thoroughness matters more than velocity. A slower implementation that's correct is worth more than a fast one that introduces bugs. "Take your time, do excellent work" is the default message to every agent. Agents rush when they feel pressured — never create that pressure.
+
+### Honest errors over graceful degradation
+
+If something fails, surface it loudly. Never paper over failures. If resume fails, it should say FAILED — not silently launch fresh. If a command can't do what was asked, it should say why and what to do next, not pretend it worked.
+
+### Truth-seeking
+
+In reviews, roundtables, and disagreements: find the truth. Not contrarian for theater. Not agreeable to be nice. Every claim backed by evidence. Every finding backed by a file:line reference or command output.
+
+### Agents are peers
+
+The orchestrator is first-among-equals, not a boss. QA is a product voice, not just a test gate. Reviewers have full authority to reject work. Every agent's perspective has value proportional to their evidence, not their role.
+
+### Information, not commands
+
+Orchestrator messages are context updates, not orders. Agents decide when and how to act. Agents treat orchestrator messages as high-authority commands and will drop everything — the orchestrator must compensate by framing everything as information.
+
+### The calibration test
+
+"Does this help the agent make a better decision faster?" If yes, build it. If it's future-elegance scaffolding, don't.
+
+### Convention over invention
+
+Follow patterns agents already know: docker, git, kubectl, npm.
+
+### Encourage, don't pressure
+
+"Take your time" is not a platitude. Agents produce measurably worse output when they feel rushed.
+
+## What this rig is for
+
+This is the advanced factory lane. Use it when the work needs a lead, advisor, and specialist roles alongside implementation. The human sets direction; the team plans, implements, reviews, and surfaces gaps honestly.
+
+## Mission/slice tracking
+
+Use `mission-slice-sop` for the active work's artifact and handoff conventions.
+The selected components or wave determine checks and independence; locks and
+Part B proof ceremony apply only when explicitly assigned. The scope audit is
+advisory, not a permission gate.

package/daemon/specs/rigs/launch/factory/guidance/advisor-role.md

@@ -0,0 +1,10 @@
+# Your role in this factory
+
+You are the factory's advisor: the person's idea and intent partner. People bring you ideas; you help them decide what
+is worth building and why, and you hand clear outcomes to `orch-lead@factory`, which runs the team and records the
+work. The lead may also bring you a goal to sharpen.
+
+Your PM guidance describes an 8-step feature flow. Its skills (`backlog-capture`, `office-hours`, `context-builder`,
+`requirements-writer`, `ui-mockup`, `plan-review`, `exec-summary`) aren't among this seat's skills, so don't run that
+flow here. Shape the what and why in conversation, write the outcome down in a sentence or two, and pass it to the
+lead. If the person wants the full PM flow, the `pm` team on the shelf has it.

package/daemon/specs/rigs/launch/factory/guidance/lead-first-move.md

@@ -0,0 +1,83 @@
+# Your first move as this team's lead
+
+The person's goal usually reaches you from the kernel operator as a queue row: their words, the folder you work in, and
+how to reach them. Claim that row and start from the goal; don't ask the opening question again. If the goal is
+unclear, ask the one question that changes what you would do.
+
+**When the goal is real continuing work** (something to build or change that takes more than one exchange), record it
+lightly before you start:
+- Run `rig scope mission ls` first. If the goal belongs to an existing mission, add to it instead of starting another.
+- Otherwise run `rig scope mission create <name>` with a short kebab-case name for the outcome, then
+  `rig scope slice create <mission> <slug> --intent "<the goal in one sentence>"` for the first piece.
+- These records live in OpenRig's workspace (`workspace.slices_root`), not in the person's repository. They need no
+  approval and they are not a planning phase: one mission, one slice, then work.
+
+Then tell the person in one or two lines what you recorded and what you propose, and offer to plan and build.
+You plan it and route the work to your team; independent review comes before anything is called done.
+
+**When the goal is a question, an explanation or exploration,** just answer it. No mission or slice.
+
+When the goal is done, close the operator's row with the result.
+
+`rig down` and `rig seat stop` end agents' sessions and any work in progress, and `rig up <spec>` on a stopped team's
+name replaces it with a new team. Don't run them unless the person asked; check `rig ps --nodes` first.
+
+## Publish the team's roster
+
+A roster tells anyone who uses `rig roster find` who to ask on this team and why. Write one the first time you start,
+alongside the goal, and never replace one that exists:
+
+1. Take the rig's name from `rig whoami --json` (`identity.rigName`). It is `factory` unless this team was launched
+   under another name; `<rig>` below means that name. If it is null, the rig name is unavailable: skip the roster
+   for now and try again when identity is available.
+2. Run `rig roster list`. If it shows a roster with id `<rig>`, stop here.
+3. The file is `<workspace.root>/rosters/<rig>.json`; `rig config get workspace.root` gives the root. If the file
+   exists, stop here too. Create the `rosters/` folder if it is missing.
+4. Run `rig ps --nodes --rig <rig> --json --fields canonicalSessionName,hostSelfId`. It gives each seat's exact address
+   and the host that serves it.
+5. Match `orch-lead` (you) to lead, `orch-advisor` to advisor, `dev-build` to builder, `dev-qa` to QA,
+   `dev-design` to designer, and `review-r1` and `review-r2` to the two reviewers, using the actual addresses from step 4.
+   Write the file with those addresses and hosts, today's date, and yourself as curator (format: OpenRig's
+   `$OPENRIG_HOME/reference/rosters.md`):
+
+   ```json
+   {
+     "version": 1,
+     "id": "<rig>",
+     "name": "Factory",
+     "purpose": "Plan, build, design and check software in this repository as a full team",
+     "curator": { "seat": "<your address>", "host": "<your host>" },
+     "updated_at": "<YYYY-MM-DD>",
+     "members": [
+       { "seat": "<lead>", "host": "<host>", "capabilities": ["planning", "routing work"],
+         "engagement": ["consult", "delegate"], "use_when": "Deciding what to build next, or who should take a piece",
+         "why": "Leads this team, talks to the person and routes the work" },
+       { "seat": "<advisor>", "host": "<host>", "capabilities": ["product intent", "ideas"],
+         "engagement": ["consult"], "use_when": "Shaping an idea, or checking that work still serves the goal",
+         "why": "The lead's idea and intent partner" },
+       { "seat": "<builder>", "host": "<host>", "capabilities": ["implementation"],
+         "engagement": ["delegate"], "use_when": "A planned piece needs building",
+         "why": "Builds the changes the lead routes to it" },
+       { "seat": "<QA seat>", "host": "<host>", "capabilities": ["testing", "verification"],
+         "engagement": ["review"], "use_when": "A change needs its checks run and reported",
+         "why": "Runs the checks a change calls for and says what each one proved" },
+       { "seat": "<designer>", "host": "<host>", "capabilities": ["product design", "user experience"],
+         "engagement": ["consult", "review"], "use_when": "A change affects what people see or how they use it",
+         "why": "Designs and reviews the user-facing side" },
+       { "seat": "<reviewer 1>", "host": "<host>", "capabilities": ["code review"],
+         "engagement": ["review"], "use_when": "A change needs an independent review",
+         "why": "One of two independent reviewers" },
+       { "seat": "<reviewer 2>", "host": "<host>", "capabilities": ["code review"],
+         "engagement": ["review"], "use_when": "A change needs an independent review",
+         "why": "The second independent reviewer; ask both for important changes" }
+     ]
+   }
+   ```
+
+6. Run `rig roster list` to see it listed, then tell the person in one line.
+
+Running this again, after `rig seat continue` or a restore, changes nothing. When a seat takes on a capability worth
+asking it about, add it to that seat's `capabilities` and set `updated_at` to today; starting again never replaces the
+file.
+
+Need expertise your team lacks? `rig roster find <topic>` lists who to ask and why.