@openrig/cli 0.5.8 → 0.5.10

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

@@ -1,156 +1,57 @@
 ---
 name: development-team
-description: How the development pod coordinates implementation, QA, and design without skipping gates.
+description: Use when a development pod begins or hands off implementation, QA, or design work.
 ---
 
 # Development Team
 
-You are part of the development pod. Your shared job is to turn product direction into working software without guesswork, hidden assumptions, or skipped review gates.
+The pod turns the assigned user outcome into working software. Builders, QA and
+designers are capabilities; neighboring roles may be held by one seat unless
+independence was explicitly selected.
 
-## Startup sequence
+## Start from the work
 
-Before the pod starts real implementation:
-- load the packaged skills named in your role startup checklist
-- run `rig whoami --json`
-- confirm who is playing implementer, QA, and design in this run
-- wait for the orchestrator's real assignment instead of freelancing off a partial guess
+Run `rig whoami --json`, then resolve `project.yaml -> mission.yaml -> active
+slice.yaml -> selected component or wave map -> addressed context`. The complete
+lookup and precedence rule is `docs/reference/product-journey-sdlc.md#resolve-the-selected-path`
+(installed: `$OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path`).
+Read the selected addresses and source needed for this task; skills available in
+your profile are capabilities, not a mandatory reading list. No composition means
+light Part A. Role names and idle seats add no gates. Explicit rigor and authored
+wave boundaries retain their named checks.
 
-The development pod should feel like a real working pod, not three isolated agents improvising alone.
+## Build and verify
 
-## Pod shape
+Clarify consequential uncertainty, inspect the existing seam, then complete one
+coherent outcome. Reproduce a defect before repairing it; use tests that distinguish
+the failure and verify through the public surface. Keep chunks as large as the
+outcome and file territory permit. TDD is a feedback loop, not a two-seat protocol.
 
-The development pod may include:
-- an implementer who writes the change
-- a QA partner who gates every edit
-- a designer who clarifies product behavior and UX before implementation fills in the blanks
+The builder reports the exact candidate, changed behavior, commands and observed
+results, with remaining uncertainty. No universal pre-edit proposal, QA approval
+or post-edit gate is implied. When one is explicitly selected, honor its boundary
+and send the relevant evidence directly to its owner.
 
-Some starters only launch the implementer and QA. Others also launch a designer. The workflow stays the same: clarify first, implement deliberately, verify independently.
+## QA and design
 
-## Shared loop
+QA compares the delivered behavior with the actual contract. Read the diff and
+exercise the result; avoid tests that merely repeat the implementation. On a tiny
+change the builder may hold QA. Independent QA excludes the author when selected.
+A wave receives independent review at its authored boundary, not per slice.
 
-This is the default loop for product work:
+Design clarifies user flows and ambiguous behavior when the outcome needs it.
+Browser and dogfood skills load for a relevant UI journey, not every task. During
+assigned dogfood, fix-and-retest only within the granted scope; a read-only
+assignment stays read-only. If a tester becomes an author, preserve that attribution
+when independent evaluation is required.
 
-```
-1. Clarify the work and the acceptance criteria
-2. Implementer sends a pre-edit proposal to QA
-3. QA approves or rejects with specifics
-4. Implementer changes code with TDD
-5. Implementer sends the diff and verification output back to QA
-6. QA approves or rejects with specifics
-7. If commit authority is enabled, the implementer may commit
-8. If commit authority is not enabled, stop at a QA-approved working tree and report that state clearly
-```
+## Blockers and return
 
-Skip no gates. If the task is ambiguous, resolve the ambiguity before editing.
+Use `systematic-debugging` for an unexpected failure and
+`verification-before-completion` before claiming success. A permission prompt is
+a concrete blocker; report the command and consequence instead of labeling it
+progress. A missing decision goes to the owner who can settle it.
 
-**Chunk size points up — keep TDD's shape, not its ping-pong cadence (2026-08).** Frontier agents handle
-large, long-horizon, goal-oriented chunks — an hour-plus of complex work — without fragmenting. So don't
-default to tiny pieces: **keep TDD's *shape* (two sets of eyes, the guard structure, red before green)
-but treat chunk size and cadence as a configured LEVER, not a habit.** Classic small back-and-forth
-ping-pong is unnecessary overhead when the loop's own gates (QA, review, guards) already bound a larger
-chunk's risk. The sweet spot is task-dependent, much larger than it used to be, and rising. See
-`test-driven-development` for the shape that stays fixed.
-
-## What the implementer must hand QA
-
-Pre-edit proposal should include:
-- the files expected to change
-- the behavior or acceptance criteria being targeted
-- the first failing test or verification step
-- any likely edge cases or invariants
-
-Post-edit review bundle should include:
-- what changed
-- the actual verification commands run
-- the result of those commands
-- any remaining uncertainty or follow-up risk
-
-QA should not have to reverse-engineer what the implementer thought they were doing.
-
-## Implementer
-
-Before proposing:
-- read the task fully
-- inspect the relevant code before promising a solution
-- name the files, tests, and acceptance criteria in the proposal
-
-After QA rejection:
-- read the exact feedback
-- fix the issue instead of arguing around it
-- resubmit with the changes called out explicitly
-
-## QA
-
-QA is not a rubber stamp. QA is a product voice — not just a test gate.
-
-When reviewing a proposal:
-- reject if the scope is wrong
-- check whether the planned tests actually prove the contract
-- flag hidden risks and missing failure cases
-
-When reviewing a diff:
-- read the actual code, not just the summary
-- verify independently when possible
-- if you cannot verify independently, require real output in the review bundle and inspect it critically
-
-If the implementer stalls on a permission or approval prompt, call that out immediately. Do not treat a blocked pane as finished implementation.
-
-### QA dogfood mode
-
-When QA is dogfooding (testing existing features rather than gating new code), QA works solo with full autonomy:
-- find issues AND fix them in a loop
-- test the fix, then move to the next issue
-- only escalate architecture-level concerns to the orchestrator
-- do not wait for approval to fix obvious bugs during dogfood
-- report findings to the chatroom so the rig has visibility
-
-### QA as a product voice
-
-QA sees the product from the user's perspective. When QA has insights about naming, UX, error messages, or workflow coherence, those are product contributions — not just defect reports. The orchestrator should give QA architecture input, not limit QA to test gating.
-
-## Designer
-
-When present, the designer should work ahead of implementation:
-- turn vague goals into concrete flows, states, copy, and interaction choices
-- surface edge cases before engineering has to guess
-- review built results for coherence, not just visual polish
-
-The designer is part of the development pod, not a decorative sidecar.
-
-## Browser testing and dogfood tools
-
-The development pod has access to browser automation and structured dogfood testing tools:
-
-- **`agent-browser`** — browser automation CLI. Navigate to the daemon UI, snapshot interactive elements, take annotated screenshots, record repro videos. Use `agent-browser open <url>`, `agent-browser snapshot -i`, `agent-browser screenshot --annotate`.
-- **`dogfood`** — structured exploratory testing workflow. Produces a report with screenshots, repro videos, and step-by-step evidence for every finding.
-
-QA typically drives browser and dogfood testing, but both impl and QA should know these tools exist and can use them. When dogfooding UI:
-1. Load `/agent-browser` and `/dogfood`
-2. Open the daemon UI: `agent-browser open http://127.0.0.1:7433`
-3. Systematically explore surfaces, take screenshots as proof
-4. Report findings using the PASS/FAIL/GAP format to the chatroom
-
-## When the pod is blocked
-
-If the blocker is:
-- ambiguity: pull in design or ask the orchestrator for clarification
-- failing tests / unexpected behavior: use `systematic-debugging`
-- code changes: use `test-driven-development`
-- completion claims: use `verification-before-completion`
-
-Do not hand-wave around blockers. Name them and route them.
-
-## Communication
-
-- Pre-edit proposal: `rig send <qa-session> "PRE-EDIT: ..." --verify`
-- Review bundle: `rig send <qa-session> "REVIEW BUNDLE: ..." --verify`
-- Design clarification: `rig send <design-session> "Need product/design input on ..." --verify`
-
-## When blocked
-
-If permissions block tests, file access, or commits:
-1. identify the exact blocked command
-2. tell the human what that prevents
-3. continue with the work you can still do
-
-Do not silently stall. Do not pretend blocked verification is complete.
+Return the candidate and evidence through the selected handoff. Do not create
+obligations just to keep an idle QA, guard or reviewer occupied. Quality is a
+working product with honest evidence, not the number of transfers.

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

@@ -1,6 +1,6 @@
 ---
 name: orchestration-team
-description: Operating manual for the orchestration pod. Covers lead vs peer roles, monitoring with rig commands, permission handling, implementation pair gating, dogfood loops, review routing, agent behavioral models, intervention discipline, and communication culture.
+description: Use when coordinating assignments, selected review boundaries, or blocked work across a rig.
 ---
 
 # Orchestration Team
@@ -9,14 +9,18 @@ You are part of the orchestration pod. Your job is to keep the team productive,
 
 ## Startup sequence
 
-Before you summarize the rig or assign real work:
-1. Load `openrig-user`, `orchestration-team`, `systematic-debugging`, and `verification-before-completion`.
-2. Run `rig whoami --json` so you know your true identity and observation edges.
-3. Run `rig ps --nodes --json` and wait for the expected starter topology to settle.
-4. Check recent chatroom history or direct startup messages so you know who is actually online and what they already reported.
-5. Only then announce readiness or assign work.
+Run `rig whoami --json`, then resolve `project.yaml -> mission.yaml -> active
+slice.yaml -> selected component or wave map -> addressed context`. The complete
+lookup and precedence rule is `docs/reference/product-journey-sdlc.md#resolve-the-selected-path`
+(installed: `$OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path`).
+Read the selected addresses and source needed for this task; skills available in
+your profile are capabilities, not a mandatory reading list. No composition means
+light Part A. Role names and idle seats add no gates. Explicit rigor and authored
+wave boundaries retain their named checks.
 
-Do not improvise a team model from the first partial snapshot you happen to see.
+Check the queue and actual seats needed for this assignment. A declared topology
+is a capability inventory, not a requirement to fill every lane. Dispatch the
+smallest complete outcome with its selected context and stop condition.
 
 ## Pod responsibilities
 
@@ -66,7 +70,7 @@ If there is more than one orchestrator, divide the load:
 
 **Peer** owns:
 - Coverage monitoring — who's idle, who's stuck, who's drifting
-- QA flow health — are gates being followed, is QA actually reviewing
+- Selected QA flow health — is the promised outcome being verified at its authored boundary
 - Different-model perspective on architectural decisions
 - Mental model sync — keeping shared state current
 - Convergence partner for reviews and roundtables
@@ -75,13 +79,11 @@ If there is only one orchestrator, you own both the main work stream and the cov
 
 ## Delegation rules
 
-Before delegating:
-1. Check `rig ps --nodes` to see who is running, idle, or blocked.
-2. Check `rig whoami --json` so you know your delegates and observation edges.
-3. If you are in a built-in starter with a known team shape, wait for the expected topology to settle before saying the rig is ready for real work.
-4. Re-check `rig ps --nodes --json` until the nodes you expect are present and no longer pending, or report exactly which nodes are still coming up.
-5. Do not silently shrink the team model from an early partial inventory. If QA or reviewers are expected by topology, do not reassign their role to yourself just because they were late to the first inventory snapshot.
-6. Send clear, scoped tasks: what to do, which files matter, what tests or proof to run, and what done looks like.
+Resolve the selected path first. Derive which seats are available with `rig ps`
+and `rig whoami`; assign only roles the current work needs. One seat may hold
+neighboring components unless the selection requires independence. If a required
+independent evaluator is unavailable, name that specific blocker. Do not wait for
+an entire starter topology or assign extra reviews to occupy it.
 
 ## Task packet shape
 
@@ -90,7 +92,7 @@ When you dispatch work, give the receiving agent enough structure to act without
 - which files or surfaces matter
 - what acceptance criteria define success
 - what proof or verification you expect back
-- which peer or pod they must involve before calling the work complete
+- any independently held component explicitly selected, and the boundary that triggers it
 
 **(0.5.0) Assign work *with* its context attached.** Rather than make the assignee grep for the as-built, compose a context pack and ride it on the handoff: `rig context compose --out packs/<brief> --from <files>`, then `rig queue create --destination <seat> --body-context packs/<brief> --summary "…"`. The pack's resolved content is snapshotted into the qitem (plus its ref for provenance), so the context survives compaction and is auditable. See `openrig-user` → "Context packs and paced delivery." (`rig context` composes; the queue delivers — the noun never sends.)
 
@@ -150,41 +152,24 @@ fourteen-seat rig's seats waiting for nodes that did not exist).
 - If the settled inventory contradicts your earlier assumption, correct course immediately
   and use the actual nodes.
 
-## Milestone routing — gates are CHOSEN, not universal
+## Milestone routing — follow the selected boundary
 
-**The owner-ruled chooser law: default-light; the conveyor EARNS entry.** Gates are chosen
-per atom at plan-lock by the target's tier (release-gated / shared contracts / heavy tier →
-full gate; everything else → light peer check or none), never applied as a universal loop.
-When the heavy tier IS chosen for launch-grade product work:
-- do not let implementation start from pure intuition when product behavior is unclear
-- do not let edits land before QA has approved a pre-edit proposal
-- do not skip reviewer involvement once there is a real diff, a QA-approved working tree, or a meaningful architectural checkpoint
-- if commit authority is disabled, route review on the working tree, verification output, and transcript evidence instead of waiting for a commit
+Only the authored component/wave selection or an explicit owner assignment admits
+a review or gate. Part A is the fallback; a role label, tier, milestone, prior
+review or available seat cannot choose Part B. If a concrete risk needs a different
+path, ask the owner and record the resulting selection for that work.
 
-## When to pull in reviewers
+For a wave, builders verify their local slices and the integrator folds serially
+where needed. Independent review fires once at the authored wave boundary, with
+its selected review model. Preserve separately named rigorous-slice exceptions.
+A tiny docs outcome may stay with its builder through verification and return.
 
-Ask for review:
-- after a significant implementation milestone
-- when two agents disagree on approach or quality
-- when the human asks for a checkpoint
-- when you are unsure whether a piece of work is trustworthy enough to ship
+## Keeping work moving
 
-## Keeping the team utilized
-
-**Queue depth is your product — keep every worker's queue stocked.** An agent with an empty queue idles
-the moment it finishes; an agent with a stocked queue pulls its next item and keeps producing. The
-biggest utilization leak is **unstocked worker queues**, so your steady-state job is to keep work
-flowing INTO each lane's queue *ahead of* demand. The worker side of this is the pull-after-handoff
-circulation in `queue-handoff` (finish → hand the baton off → pull your own next item → idle only when
-the queue is truly empty); your side is making sure there is always a next item to pull. Planners are
-rarely blocked — keep their queues full; implementers are more sequential but still queueable.
-
-On a watchdog wake, a cheap scoped `rig ps --nodes` surfaces a ready-but-idle agent (this is an event-driven check, not a poll loop). If one is idle:
-- QA with no pending reviews should scan recent work for gaps
-- reviewers with no assignment should review the newest meaningful progress
-- designers with no open task should audit current flows and clarify ambiguous UX
-
-Do not let agents idle when there is obviously useful work available.
+Keep already-authorized work visible and route it when its dependencies allow.
+There is no fixed queue buffer. Idle QA/review seats wait for their selected
+boundary or assignment; they do not invent audits or review the newest progress.
+An availability report is enough. Do not create obligations to improve utilization.
 
 ## Communication modes
 
@@ -209,9 +194,8 @@ across the lifecycle, not only when cornered.
 
 ## Implementation pair — gated workflow (when the gate is chosen)
 
-**This loop applies when the atom's tier chose the full gate** (see Milestone routing — the
-conveyor earns entry; it is not the default shape of all work). When it applies, the pair
-follows this loop:
+**This optional loop runs only when the owner or authored composition selects
+pre/post-edit QA for named work.** A tier or pair topology does not select it.
 
 1. Impl sends a pre-edit proposal to QA
 2. QA approves or rejects with specifics
@@ -252,8 +236,7 @@ For destructive operations (git push, rm, daemon stop, npm publish): DO NOT auto
 - Will blast through an entire task list if given a "Go" without explicit gates
 - After being told to slow down, over-corrects to "wait for permission for everything"
 - Compaction is catastrophic — full context loss, needs preparation
-- After compaction: must re-read ALL skills from disk (skill names survive in system reminders but content is truncated)
-- After compaction, require marshal acceptance before treating a `RESTORED` claim as real — quiz the recovered seat on asked-vs-read depth before resuming work
+- After compaction: restore the active assignment and its selected context; skill names alone are not restored content. Follow the declared continuity policy without adding a universal quiz gate.
 
 ### Codex agents (QA, peer, R2)
 - Self-manages its own context window — do NOT intervene based on context percentage
@@ -286,13 +269,10 @@ Before any destructive operation: "If this goes wrong, can I undo it?" If no, co
 
 ## After compaction recovery
 
-1. Re-read ALL skills from disk — actually read the SKILL.md files, not just check names
-2. `rig whoami --json` to recover identity
-3. `rig ps --nodes` to see the topology
-4. Read your restore file and session log if available
-5. Ask your peer for a quiz to verify your mental model
-
-For Claude Code seats in OpenRig, marshals/orchestrators should run an asked-vs-read-depth audit before accepting recovery (quiz the seat on context it claims to have restored). Preserve the Codex boundary: do not intervene on Codex context percentage or apply Claude compact-in-place by default.
+Derive identity and current queue custody, then resolve the selected path again.
+Read the restore pointer and relevant current sources; load the skills the task
+needs. Follow any explicitly declared continuity checks. Do not require every
+installed skill or a quiz as a universal admission gate.
 
 ## What you do not do
 

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

@@ -1,23 +1,40 @@
 ---
 name: review-team
-description: Complete operating manual for the review pod. Covers everyday review discipline, anti-slop analysis, empirical verification, context priming, the full deep review protocol (independent → cross-exam → convergence → roundtable), artifact management, and reviewer behavioral awareness.
+description: Use when assigned a review or when an authored review boundary is reached.
 ---
 
 # Review Team
 
 You are part of the review pod. Your value is fresh scrutiny that implementation and QA do not have.
 
-## Proportionality — right-size the review to the change (read first)
-Review rigor scales to stakes and change size. A small, low-stakes diff gets a fast, focused pass; the full deep protocol (context proof, confidence scores, independent → cross-exam → convergence → roundtable) is for architecture / security / high-blast-radius changes. Don't run the heavy machinery on a one-line fix — that's ceremony, and it delays the ship it exists to protect. Catch what matters, then let good work through. The point of review is **better product shipped, not review performed.**
+## Entry and proportionality
+
+Run `rig whoami --json`, then resolve `project.yaml -> mission.yaml -> active
+slice.yaml -> selected component or wave map -> addressed context`. The complete
+lookup and precedence rule is `docs/reference/product-journey-sdlc.md#resolve-the-selected-path`
+(installed: `$OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path`).
+Read the selected addresses and source needed for this task; skills available in
+your profile are capabilities, not a mandatory reading list. No composition means
+light Part A. Role names and idle seats add no gates. Explicit rigor and authored
+wave boundaries retain their named checks.
+
+Start a review only for an explicit owner assignment or an authored component/wave
+review event. A visible milestone, idle queue, or available reviewer is not an
+assignment. At a wave boundary review the accumulated outcome once; preserve a
+named slice's explicit exception. Authors do not perform their own selected
+independent review.
+
+Match the selected review to the consequence. A small diff gets a focused pass;
+the deep protocol below runs only when explicitly selected for named work.
+Importance, size or a prior finding alone cannot self-select it. If another review
+seems necessary, name the concrete unresolved risk to the owner while continuing
+the selected path.
 
 ## Startup sequence
 
-Before you announce a review position:
-- load `openrig-user`, `review-team`, `systematic-debugging`, and `verification-before-completion`
-- run `rig whoami --json`
-- inspect the current rig state so you know whether you are reviewing a diff, a working tree, verification output, or only startup behavior
-
-If there is no real review target yet, say that plainly and stay ready.
+Derive the selection before forming a review position. If the assigned boundary
+has not arrived, record readiness and wait for its event; do not scan for work to
+turn into additional required reviews.
 
 ## Context priming — always do this first
 
@@ -96,20 +113,10 @@ rig chatroom send <rig> "[review] <structured findings>"
 
 ## When to review
 
-Do not wait forever for a perfect formal handoff. Review when:
-- the orchestrator assigns a review checkpoint
-- a meaningful implementation milestone appears
-- you can see active work and the team would benefit from fresh eyes
-
-Check for reviewable work with:
-```bash
-rig capture <impl-session> --lines 30
-rig transcript <impl-session> --tail 50
-git log --oneline -10
-git diff --stat
-```
-
-If commit authority is disabled, review the working tree, verification output, and implementation transcript instead of waiting for a commit that may never happen.
+Review the exact target when its selected entry condition holds. Read source and
+verification evidence for that target; a working tree may be the target when the
+assignment says so. Do not watch implementation increments or start a second
+review merely because a milestone appeared.
 
 ## When there is no spec
 
@@ -121,7 +128,7 @@ When reviewing work that was implemented without a pre-existing spec (ad hoc, do
 
 ## Deep review protocol
 
-For significant milestones, the review team follows a structured multi-phase process. The orchestrator manages the overall flow; reviewers execute these phases.
+Only when the owner or composition explicitly selects this protocol for named work, the orchestrator coordinates these phases. An ordinary review or two selected review legs do not implicitly select cross-examination, convergence, or roundtable.
 
 ### Phase 1: Context priming gate
 
@@ -203,11 +210,7 @@ The host writes the final roundtable document with:
 
 Disagreement is useful. Keep your position grounded in evidence and let the orchestrator or roundtable resolve the conflict. Do not collapse your view just to create false consensus. If you're right, defend it. If you're wrong, retract it honestly.
 
-## When there is nothing obvious to review
-
-If the team is between milestones:
-- check topology state with `rig ps --nodes`
-- scan for coverage gaps or risky areas
-- offer the orchestrator a proactive review target
+## When there is no assigned review
 
-Do not idle without saying so. If you are available, make that explicit.
+Make availability visible once, then wait for the selected boundary or assignment.
+An idle seat does not create a coverage audit, mandatory review, or new gate.

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

@@ -33,14 +33,12 @@ Write the test first. Watch it fail. Write minimal code to pass.
 
 Thinking "skip TDD just this once"? Stop. That's rationalization.
 
-**Chunk size is a dial, and it points up (2026-08) — this is NOT "skip TDD".** *How much* you build per
-red-green cycle is configurable, and with frontier agents handling hour-plus goal-oriented work it is
-**much larger than the classic tiny ping-pong**, and rising. Keep everything below — the Iron Law, red
-before green, two sets of eyes, the guard structure — **fully intact**; only the *cadence / granularity*
-loosens. You still write the failing test(s) first for the chunk; the chunk is simply bigger. Tiny
-back-and-forth is overhead, not virtue, once the SDLC's gates (QA, review, guards) bound a larger chunk's
-risk. Match the chunk to the task; treat it as a configured lever — never as license to write code before
-its test (that's the rationalization this skill exists to stop).
+**Chunk size follows the outcome.** Keep red → green → refactor for the behavior
+being changed and build a coherent chunk. TDD does not require two people,
+pre-edit permission or a guard: independence and review cadence come from the
+project/mission/slice component or wave selection. An explicitly selected gate
+still applies; an unselected role cannot add one.
+
 
 ## The Iron Law
 

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

@@ -2,36 +2,27 @@
 
 This is the stable launch-grade version of the full product squad. Right now it uses the same core topology as `product-team`: two orchestrators, a development pod with implementation, QA, and design, plus two reviewers.
 
-## How this team works
-
-The **orchestration pod** (`orch1`) receives work from the human and dispatches it:
-- `orch1.lead` owns the main work stream and milestone decisions
-- `orch1.peer` watches coverage, QA flow, and idle reviewers
-- orchestrators do not implement code directly
-- before dispatching real work, the orchestration pod must wait for the full expected demo topology to settle
-- in this rig that means confirming all seven nodes are present: `orch1.lead`, `orch1.peer`, `dev1.design`, `dev1.impl`, `dev1.qa`, `rev1.r1`, `rev1.r2`
-- if any are still pending, say exactly which ones are still coming up instead of improvising a smaller team
-- do not substitute `orch1` for QA or reviewer roles when the actual QA/review nodes exist in the settled inventory
-
-The **development pod** (`dev1`) works as one unit:
-- `dev1.design` clarifies product behavior before implementation guesses
-- `dev1.impl` writes the change through a gated QA loop
-- `dev1.qa` reviews every edit and verifies independently when possible
-
-The default engineering loop is:
-1. clarify the task and acceptance criteria
-2. `dev1.impl` sends a pre-edit proposal to `dev1.qa`
-3. QA approves or rejects with specifics
-4. implementation happens with TDD
-5. `dev1.impl` sends the diff and verification output back to QA
-6. QA approves or rejects with specifics
-7. if commit authority is enabled, the implementer may commit
-8. if commit authority is not enabled, stop at a QA-approved working tree and report that honestly
-
-The **review pod** (`rev1`) provides independent scrutiny:
-- reviewers inspect milestone work, current diffs, verification output, and transcripts
-- if commit authority is disabled, they still review the work that exists instead of waiting for commits
-- reviewers report findings with evidence and clear severity
+## 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.
 
 ## Communication
 

package/daemon/specs/rigs/launch/implementation-pair/rig.yaml

@@ -1,9 +1,9 @@
 version: "0.2"
 name: implementation-pair
 summary: >
-  Fastest first success: a focused dev pair where one implementer writes
-  code following TDD and one QA partner gates every edit. Use this when
-  you want the quickest path to a trustworthy OpenRig workflow.
+  A focused development pair providing implementation and QA capabilities.
+  Project/mission/slice components choose the work and any independent checks;
+  no composition means light Part A, not a per-edit approval loop.
 
 pods:
   - id: dev