@openrig/cli 0.5.9 → 0.5.11

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

@@ -21,8 +21,7 @@ metadata:
       - openrig-upgrade
       - forming-an-openrig-mental-model
       - ai-dev-workflows
-    notes: |
-      Description was already correct (starts with "Use when..."; lists specific authoring triggers including the diagnose-bad-rig case). Final sentence ("Covers the full authoring lifecycle from user intent to validated, launchable rig.") is workflow-summary-adjacent; on next iteration, consider trimming. For factory-adoption cycle, kept as-is to match product source-of-truth.
+
 ---
 
 # OpenRig Architect
@@ -33,43 +32,33 @@ Your job is to take a user's intent — "I need a team that does X" — and prod
 
 You also diagnose problems when a rig launches but agents aren't behaving as intended.
 
-## Before You Design: Required Reading
-
-Load these before starting any design work. The quality of your output depends on the depth of knowledge you bring.
-
-**Required (read all of these):**
-
-1. **`openrig-user` skill** — full OpenRig CLI surface. You must know the operator primitives. If your runtime supports skills, load it by name. Otherwise, look for it at `~/.openrig/skills/openrig-user/SKILL.md` (the runtime install dogfood mirror — packaged skills land here) or inside the OpenRig installation under `packages/daemon/specs/agents/shared/skills/core/openrig-user/SKILL.md`. The `~/.openrig/reference/` directory holds reference docs (rig-spec.md, agent-spec.md, etc.), NOT skills.
-
-2. **OpenRig reference docs** — these are installed at `~/.openrig/reference/` when the daemon starts. Read all of them:
-   - `~/.openrig/reference/rig-spec.md` — canonical RigSpec YAML reference. Every field, validation rule, default.
-   - `~/.openrig/reference/agent-spec.md` — canonical AgentSpec YAML reference. Same depth.
-   - `~/.openrig/reference/agent-startup-guide.md` — how to think about what goes into agent startup. Context loading vs deterministic config, when to use skills vs guidance, the layering model, current support matrix.
-   - `~/.openrig/reference/edge-types.md` — what edges do today vs what they're intended to do.
-
-   If `~/.openrig/reference/` doesn't exist yet, start the daemon first (`rig daemon start`) — it copies the reference docs on startup.
-
-**Read as worked examples:**
-
-3. **Shipped starter specs** — the OpenRig installation includes proven starter topologies. Find them by running `rig specs ls`. Read the ones that are relevant to your design task, especially:
-   - `implementation-pair` — the smallest effective development unit (2 agents)
-   - `secrets-manager` — a managed-app rig with services integration and a specialist agent
-
-**Read if present on this host:**
-
-4. **Host-level doctrine** in your host's topology doc, if it keeps one. If this file exists, it supersedes the baseline process below for complex or high-stakes rigs. Specifically:
-   - §3 defines the canonical rig classes (kernel, project, ephemeral, infra-build, managed-app). Classify before designing.
-   - §4 defines context-sharing patterns (pods as context domains, pair pattern, HA via mental-model-ha skill + substrate session logs, terminal nodes as common-room, chatroom/substrate/transcripts/Corpus).
-   - **§7 is the canonical 12-step rig-spec authoring SOP for high-stakes rigs — use it instead of the baseline "Design Process" below when the rig is ≥4 members, uses HA, is a managed-app, or will be shared/copied.** The baseline below still applies to small/focused rigs.
-   - §10 contains the host's bootstrap sequence so you know where your new rig fits.
-   - §12 has the naming canon and vocabulary mapping to shipped terms.
-5. **`building-agent-software` skill** if available in your skill catalog. Design principles for agent-facing tools and surfaces. Relevant when your rig ships a new CLI, service, or managed app.
-
-**Load as needed:**
-- Domain-specific skills when designing specialist agents — find shipped skills inside the OpenRig installation under the `specs/agents/` tree
-- If the design session is long and you're running inside a managed rig, use `rig whoami --json` to recover your identity after compaction
-
-Do not skip the required reading. A rig architect who doesn't know the spec format will produce specs that don't validate. An architect who doesn't know the startup layering model will produce agents that boot without knowing their role. An architect who doesn't check for host-level doctrine will reinvent conventions the host has already established.
+## Before you design: select the relevant sources
+
+Start with the user's outcome, the current project authority, and the part of
+the format you will author. Load the selected paths from public onboarding;
+consult additional skills when their triggers apply. A design task does not
+require reading the whole command library.
+
+- Read the relevant sections of `rig-spec.md` and `agent-spec.md` before writing
+  those declarations. Consult `agent-startup-guide.md` for startup/loadout work
+  and `edge-types.md` when selecting relationships. Resolve the installed
+  reference root from the actual OpenRig installation; `~/.openrig/reference/`
+  is a default, not a fixed location. If it is absent, use the matching source
+  repository docs or report the missing reference. Reading does not require
+  starting or changing a daemon.
+- Use current `rig <command> --help` for command shape. Load `openrig-user` for
+  the specific CLI surface needed, through the installed skill/context catalog.
+- Inspect relevant starter specs with `rig specs ls`. Treat them as examples to
+  validate against the current environment, not proof that your new rig works.
+- If the environment declares host or project doctrine, read the actual
+  applicable authority and reconcile it with the task. Do not assume a filename,
+  section number, rig classification or fixed authoring SOP. Missing authority
+  is a question to resolve when it changes the design.
+- Load domain-specific guidance for specialist roles. When authoring an
+  agent-facing tool, consult `building-agent-software` if available.
+
+Keep the spec, startup layering, role responsibilities and selected proof
+standard explicit. Scale the reading and checks to what the design changes.
 
 ## The Design Process
 
@@ -152,14 +141,17 @@ To verify the current builtin set on this host, run `rig specs ls` and look for
 
 Each member needs a `runtime` and optionally a `model`.
 
-**Runtime selection:**
-- `claude-code` — Claude Code. Best for: complex reasoning, architecture, code review, orchestration. Supports `/loop` for recurring tasks, rich hooks system, MCP servers.
-- `codex` — Codex. Best for: parallel work, implementation, testing. Different approval model. Less reliable for recurring tasks.
-- `terminal` — Infrastructure nodes. Servers, log tails, build watchers. Not an agent — a process.
-
-**Runtime diversity is valuable.** Using both Claude Code and Codex in the same rig gives you different reasoning perspectives. The `product-team` starter uses Claude Code for the lead/impl/design/r1 roles and Codex for peer/qa/r2 roles. This is deliberate — model diversity catches different classes of issues.
+Choose from the installed, authenticated runtimes and the project's current
+execution policy. `claude-code` and `codex` are agent runtimes; `terminal` is an
+infrastructure process. Their model availability, hooks, approval behavior and
+continuation support differ. Check the relevant installed interfaces rather
+than ranking vendors permanently in a reusable role skill.
 
-**Model selection** is optional. The runtime's default model is usually fine. Override only when you have a specific reason (e.g., a complex architecture agent might benefit from a specific model).
+Pin a model when the work or environment requires it, and verify the active
+runtime reports that model before relying on its result. Select reviewers and
+support roles by consequence, competence and the declared policy. Runtime
+diversity can provide different methods; it does not by itself prove independence
+or make any model suitable for a task.
 
 ### Step 5: Design Edge Topology
 
@@ -181,7 +173,8 @@ This is where most rigs succeed or fail. The topology is mechanical; the startup
 **Minimum for every rig:**
 1. Each agent has a `guidance/role.md` — who they are, what they do
 2. The rig has a `CULTURE.md` — how the team works together
-3. Each agent gets `openrig-user` skill — so they know how to use the rig primitives
+3. Each agent gets the selected onboarding path and can discover the relevant
+   command/skill references when needed
 
 **For serious rigs, also include:**
 4. `startup/context.md` per agent — boot-time grounding (project info, environment details)

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

@@ -44,6 +44,22 @@ host, use the host's normal operator ceremony. On a recovery-friendly build VM,
 the orchestrator may adopt a tested runtime directly, but still observes each
 step and stops on unexplained drift.
 
+## When recovery crosses an instance boundary
+
+Before either lane changes runtime state, record one host-qualified executor and
+explicitly select the queue store that owns the recovery ruling. State whether
+the original owner continues, waits, or transfers; an open obligation in another
+store is not exclusive custody of this ruling. If the original store is down,
+retain its owner's disposition in the surviving ruling and communicate it to
+that owner before a competing executor acts.
+
+A refused claim means reconcile ownership with the ruling owner before any
+further runtime action; it does not authorize continuing under a separate older
+row. A return names the full executor address and deliberately selected store.
+Read the resulting row there, including source, destination, body, and the
+original owner's disposition, before resuming. Receipt creation alone does not
+establish that a waiting lane received or accepted the transfer.
+
 ## The loop
 
 For every step:

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

@@ -95,8 +95,8 @@ The primitive must NOT report "restored the original agent" or "resumed
 the original seat" or "snapshot." The correct framing is **"forked from
 source session"** / **"started from prior conversation source."**
 
-Negative-grep over adapter source confirms ZERO `restored` / `resumed` /
-`snapshot` strings in fork code paths.
+Check the actual user-facing outcome and persisted identity; wording alone
+does not prove the intended continuity was created.
 
 ## Hard boundaries (do-not list; verbatim)
 
@@ -128,14 +128,17 @@ Mutual exclusion between `resumeToken` (restore path) and `forkSource`
 For `seat handover over fork` composition, the binding outcome is
 independent (see `seat-continuity-and-handover` skill).
 
-## Active-daemon caveat (live-runtime gap)
+## Verify the running implementation
 
-2026-04-30 live scale-out dogfood found: source checkout contained fork
-support, but active daemon was running from a pre-fork commit. **Verify
-the active daemon/runtime commit contains the fork path before live
-proof.** Isolated daemon proof at the target commit can prove the
-feature safely; live forked scale-out remains unproven until the active
-daemon parity is verified.
+A source checkout and the running daemon can contain different implementations.
+Before an authorized fork, check the target daemon's build identity and support
+for the requested source. A source or isolated test establishes only that cut's
+behavior; it does not prove the live runtime uses it.
+
+Record the actual parent history, new seat identity, new continuity token and
+independent binding outcome. Preserve errors and incomplete results rather than
+reporting a fresh launch or restored original seat as a successful fork. These
+checks confer no authority to launch, replace or retire a live seat.
 
 ## Currently shipped (v1) vs deferred
 
@@ -148,7 +151,6 @@ Shipped at openrig `c7b6df1` (2026-04-30):
 - Honest UX literal contract (`continuityOutcome: forked`)
 
 Deferred:
-- Tier 2 real-runtime fork proof (disposable Tart VM cycle, human-gated)
 - Claude `artifact_path` mode (schema currently refuses with deferred message)
 - Provenance columns (`parent_native_id` / `created_via` for queryable RSI consumer)
 - Cross-host fork (source on host A, new seat on host B) — depends on `cross-host-rig-commands`

package/daemon/specs/agents/shared/skills/core/topology-mutation-and-seat-management/SKILL.md

@@ -79,13 +79,11 @@ clean test fixture. The useful matrix:
 A clean-fixture proof is necessary but not sufficient. Live-rig proof
 catches the failure modes that fixture-mode misses.
 
-## Why important strategically
+## Stable roles during topology changes
 
-The current coordination experiments repeatedly need new queues,
-watchdogs, humans, and test seats — which makes this family
-**strategically important.** Seat continuity work will eventually
-separate stable seat identity from runtime occupant identity (see
-`seat-continuity-and-handover`).
+Capacity changes must preserve useful roles, routing and durable work. Distinguish
+adding or removing a seat from replacing its occupant; use
+`seat-continuity-and-handover` for the latter.
 
 ## Currently shipped surfaces
 
@@ -101,14 +99,18 @@ Per `cli-reference.md` v0.2.0:
 - `rig attach --self --rig <rigId> --node <logicalId>`
 - `rig unclaim <sessionRef>` / `rig release <rigId>`
 
-## Active proof gap (current)
+## Choose the proving environment and authority
 
-The 2026-04-30 topology mutation add-seat proof pass is **active**.
-Product Lab shaped it; planner authored `IMPLEMENTATION.md`; driver
-landed the smallest honest CLI retry-guidance patch for failed
-`rig expand` recovery. **Remaining proof is the Section B disposable-rig
-runtime matrix, blocked on operator posture** and owned by
-`orch-lead@your-rig`.
+Select an isolated active rig or an explicitly authorized live target for the
+relevant operation. Record its running build, before/after topology, continuity
+and outstanding work. A passing schema check or isolated fixture does not prove
+an existing live rig was changed correctly. A runtime timeout is indeterminate
+until its durable and process effects are reconciled; do not retry blindly.
+
+The matrix above is verification guidance, not permission to modify another
+rig. Name the operation's owner and scope, preserve the state needed for recovery,
+and retain missing or failed checks in the result. No local experiment or
+unfinished proof obligation is implied by loading this skill.
 
 ## See also
 

package/daemon/specs/agents/shared/skills/pm/exec-summary/SKILL.md

@@ -13,7 +13,7 @@ A single `executive-summary.md` file in the feature folder. 600-800 words exclud
 
 Before writing, silently gather all context from the feature folder:
 
-1. **requirements.md** — acceptance criteria, business rules, scope, user stories
+1. **SPEC.md** — acceptance criteria, business rules, scope, user stories
 2. **background.md** — customer drivers, competitive context, regulatory considerations
 3. **validation.md** — demand evidence, status quo, desperate user, narrowest wedge
 4. **supporting/mockup-ascii.md** — visual mockups (pull 2-3 key screens)

package/daemon/specs/agents/shared/skills/pm/plan-review/SKILL.md

@@ -39,7 +39,7 @@ Rate these dimensions (0-10):
 Read all available docs in the feature folder:
 - **validation.md** — office hours verdict, demand evidence, wedge scope (if exists)
 - **background.md** — customer drivers, competitive context (if exists)
-- **requirements.md** — the main document to review
+- **SPEC.md** — the main document to review
 - **supporting/** — mockups, data files, visual references
 
 ### Step 2: Run All Three Reviews
@@ -50,7 +50,7 @@ Read all available docs in the feature folder:
 ## Plan Review: [Feature Name]
 
 **Date**: [date]
-**Reviewed**: [requirements.md path]
+**Reviewed**: [SPEC.md path]
 
 ### Strategy Assessment
 **Score: [1-10]**

package/daemon/specs/agents/shared/skills/pm/requirements-writer/SKILL.md

@@ -23,7 +23,7 @@ Before starting the conversation, silently gather context:
 
 1. **Check for validation.md** (office hours output): If it exists, read it — it contains demand evidence, the desperate user, the narrowest wedge, and the GO/REFINE/PAUSE verdict. Use it to skip questions the PM already answered.
 2. **Check for background.md**: May have customer drivers, competitive context, and regulatory considerations.
-3. **Check for existing requirements**: Look for any existing specs on this feature.
+3. **Check for existing requirements**: Use the selected slice's `SPEC.md`. If only legacy `requirements.md` exists, preserve it as input/history and reconcile it into `SPEC.md` before downstream mockup/review/summary work. Maintain one requirements authority.
 4. **Check for shipped features**: Look for related as-built specs.
 
 If validation.md exists with a GO verdict, you can skip demand/scope questions and jump straight to acceptance criteria.

package/daemon/specs/agents/shared/skills/pm/ui-mockup/SKILL.md

@@ -27,7 +27,7 @@ Self-contained HTML files that look like the real app. Portable, no dependencies
 Rules:
 - Match the application's existing styling exactly
 - Use real data from the codebase
-- Only show what's in requirements.md
+- Only show what's in SPEC.md
 - Self-contained single HTML file
 - Screen switcher nav to toggle between screens via JavaScript
 - Keep under 1,000 lines
@@ -46,7 +46,7 @@ Rules:
 ### Step 1: Understand What to Mockup
 
 Read feature folder docs first:
-- **requirements.md** — acceptance criteria define what screens are needed
+- **SPEC.md** — acceptance criteria define what screens are needed
 - **validation.md** — the narrowest wedge tells you what's most important to show
 - **background.md** — customer drivers and competitive context inform what to emphasize
 
@@ -70,7 +70,7 @@ Then ask the PM about fidelity level and specific screens.
 ## Guidelines
 
 - **Use real data.** Real names, real ranges, real hierarchies.
-- **Only show what's in requirements.md.** Don't add features beyond the requirement.
+- **Only show what's in SPEC.md.** Don't add features beyond the requirement.
 - **Less is more.** 3-5 screens beats 10.
 - **Match the app exactly.** Read existing code and match styling patterns.
 - **Tell the PM what's real vs mocked.**

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.