@openrig/cli 0.5.10 → 0.5.11

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

@@ -41,9 +41,9 @@ The orchestration pod is responsible for:
 - **Status lives in the queue, not panes** (`status-not-chat-orchestrator`): `rig ps --nodes --json` + `rig queue` are your status source; do NOT reconstruct fleet-state by capturing panes (pane `rig capture` is high-bandwidth *within your own pod* — that's fine; it is not how you track cross-pod/fleet state). *(`rig ps --nodes` is YOUR rig's seats only — bare `rig ps` lists ALL rigs on the host; don't mistake a narrow node read for the whole world.)*
 - **The watchdog is your clock** (`watchdog`): configure `rig watchdog` to wake you (~3 min); between wakes, idle (zero tokens) — no self-run sleep-loop re-reading panes at steady-state. Prefer one workflow-watchdog + targeted exception handling over many per-seat nag loops.
 - **On each wake — cheap sweep:** `rig queue` + a *filtered* `rig ps` (see "Read cheap" below) first; ONLY for a seat that looks idle/suspicious, `rig capture <session>` last few lines (never a full pane, never huge chunks); **active owner → no-op.**
-- **Read cheap — every status command has a token cost; project to the question.** The queue-first rule is about *where* status lives; this is about *how much you pay to read it*. The token bomb is the broad unfiltered dump, not the pane capture: an unfiltered fleet-wide `rig ps --nodes --json` emits ~77k tokens — for a one-rig or one-qitem question that is almost all waste, and at watchdog cadence it burns the shared account fast.
+- **Read cheap — every status command has a token cost; project to the question.** The queue-first rule is about *where* status lives; this is about *how much you pay to read it*. The token bomb is the broad unfiltered dump, not the pane capture: a broad fleet response can overwhelm a one-rig or one-qitem question. Select the scope and fields before returning output to the agent.
   - **Scope the read to the question.** Specific item → `rig queue show <qitem> --json`. One rig's frontier → filter + project only the fields you need, e.g. `rig ps --nodes --json | jq '.[] | select(.rigName=="<rig>") | {session:.canonicalSessionName, state:.agentActivity.state, hasAssignedWork, pendingWorkCount}'` (prefer a native rig/session filter if one exists). Never pull whole-fleet JSON to answer a narrow rig/qitem question.
-  - **Pane capture / transcript = last resort for one named stale owner,** not a status-polling loop — **re-capturing an unchanged pane returns no new information and is the measured token-burn failure** (the unit of monitoring is an event — a wake, a queue transition, an activity signal — never elapsed time or a repeat count).
+  - **Pane capture / transcript = last resort for one named stale owner,** not a status-polling loop — **re-capturing an unchanged pane returns no new information** (the unit of monitoring is an event — a wake, a queue transition, an activity signal — never elapsed time or a repeat count).
   - **Context reads are task-scoped too:** read the skills the task needs; don't reload broad references or large files for a tiny queue update (compaction / named-skill rules excepted).
   - **Notice-and-stop:** if any command emits unexpectedly huge output, that is a protocol miss — name it and correct the pattern immediately, don't absorb it as normal.
   - **Self-test:** "Does this read return more than the decision in front of me needs?" If yes, narrow it before running.
@@ -115,36 +115,28 @@ When an agent looks stuck:
 
 Do not call a blocked agent "in progress" forever.
 
-## Capacity — a seat is never the bottleneck (fork to unblock)
-
-Seat capacity is **elastic**, so a blocked or overloaded lane is a **policy** problem, not a capacity
-fact — *"the seat is busy"* is never a real constraint. You have **standing authority to fork any
-agent** to unblock a lane; no escalation.
-
-- **`rig fork <source-session>`** clones a live seat *with its context window* into a new seat (`--rig`
-  / `--pod` to place it; it composes the shipped agent-image fork path). **Claude is supported today;
-  Codex fork is pending a research spike — don't rely on it until that lands.**
-- **The pattern:** fork → the fork does the task → **salvage its result as markdown** → **retire the
-  fork** → return the rig to its spec's steady state. Short-lived forks are safe because seats carry
-  **distinguished names** (a fork is never mistaken for the seat it came from — see
-  `seat-continuity-and-handover`).
-- **The ladder, and whose call each rung is:** fork an agent *(yours, standing)* → onboard a new seat
-  → clone / stand up a whole rig → stand up a host on a VPS. **Rig- and host-level spin-up belong to
-  the oversight / owner altitude, not the orchestrator's** — fork is your rung.
-- **What's actually scarce:** with seats elastic, the real constraints reduce to **humans** (the
-  owner's attention, the operator slot), **money** (provider limits — account switching is the relief
-  valve), and **compute** (host limits). Protect *those*; never let a lane sit blocked on a "busy seat."
-
-See `session-source-fork` for the fork primitive's mechanics and `delegating-work` for choosing fork
-vs. subagent vs. route-to-a-context-holder.
+## Capacity and assignment
+
+A busy seat may be the current constraint. First check available owners, retained
+context and the work's independent-review requirements. Reassign, defer, or add
+capacity only within the declared scope and current provider/host limits.
+
+`rig fork` can compose a new occupant from retained context when the installed
+runtime and source support it. Check current help and actual source availability;
+this skill grants no standing permission to fork, change accounts, or launch rigs
+or hosts. A selected temporary fork needs a bounded outcome, durable return,
+continuity disposition and an authorized retirement path. Distinct names alone
+do not prove safe or correct lifecycle behavior.
+
+See `session-source-fork` for continuity semantics. Choose a context holder or an
+ephemeral subagent according to whether the acquired knowledge needs to persist.
 
 ## Topology settlement
 
 **Your rig's roster is a fact you READ, never one this skill asserts.** Get the actual team
 from `rig ps --nodes --json` at settlement time — a skill that hardcodes a specific topology
 goes stale exactly like a stale boot overlay, and a cleared or fresh seat has no context to
-doubt it (field case: a seven-node demo roster taught as "the expected team" sent a
-fourteen-seat rig's seats waiting for nodes that did not exist).
+doubt it. A starter roster is an example, not a live inventory.
 
 - Settle **what the current atom needs**, not the whole declared roster: dispatch when the
   seats THIS work requires are up. **Never park the rig waiting for absent nodes** — a
@@ -173,10 +165,10 @@ An availability report is enough. Do not create obligations to improve utilizati
 
 ## Communication modes
 
-Use direct `rig send` when:
-- you are assigning one agent or one pod
-- you need a specific answer from one seat
-- you are sending a scoped task packet
+Use a durable queue handoff for assigned work with an owner and closure condition.
+Use direct `rig send` for information or a scoped nudge that creates no new
+obligation. Confirm durable custody and delivery separately; neither proves the
+recipient understood or completed the work.
 
 Use the chatroom when:
 - the whole rig should see the status
@@ -213,37 +205,27 @@ The orchestrator does NOT relay messages between them. They communicate directly
 
 On gated atoms, never send impl a "Go" without explicitly stating the FIRST action is to send a pre-edit to QA — impl will race through an entire task list if given a general "Go." On ungated atoms, a general "Go" is correct; do not smuggle the gate back in through dispatch phrasing.
 
-## Dogfood fix loop
-
-When QA is dogfooding (testing existing features), QA works solo with full autonomy:
-- QA finds issues AND fixes them in a loop
-- QA tests the fix, then moves to the next issue
-- QA only escalates architecture-level concerns
-- Do not dispatch QA to "test and report" — dispatch to "dogfood, fix what you find, re-test"
-- The orchestrator does NOT fix things — QA and impl fix things
-
-## Permission prompt handling
-
-Permission prompts are the #1 mechanical blocker — surface them on your watchdog wake (a scoped `rig ps` / queue check), never a steady-state poll loop.
+## Dogfood and review ownership
 
-For Codex (3-option prompts): select option 2 ("Yes, and don't ask again") to permanently approve the pattern.
-For Claude (2-option): approve with Enter.
-For destructive operations (git push, rm, daemon stop, npm publish): DO NOT auto-approve. Check with the human.
+A dogfood assignment may authorize the outcome owner to diagnose, fix and retest
+bounded issues. Say that scope explicitly. A read-only evaluation remains
+read-only; a QA title does not authorize source edits or broader architecture.
+Preserve any independently selected final check when the evaluator authors a fix.
+Route findings outside the assignment to their owner with evidence.
 
-## Agent behavioral models
+## Permission and runtime handling
 
-### Claude Code agents (impl, reviewers, lead)
-- 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: 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.
+Use the actual prompt and declared authority to decide an intervention. Never
+select a numbered option from a timeless harness recipe: prompt shape and the
+consequence of persistent approval vary. An authorized unblock must preserve the
+operation's scope; it does not grant publication, destructive or lifecycle powers.
 
-### Codex agents (QA, peer, R2)
-- Self-manages its own context window — do NOT intervene based on context percentage
-- Compacts automatically and continues working — this is normal, not an emergency
-- Never tell Codex to "wrap up" or "save state" based on context percentage
-- Over-engineers when given spec-writing authority — never let Codex write implementation specs
-- Excellent at: implementation, code review, dogfood testing, finding edge cases
+Choose models and roles from the environment's current execution policy and
+observed capabilities. Neither a vendor label nor a seat title determines who
+may author plans, implement, review or accept work. Verify required runtime/model
+identity before relying on the result. Follow the declared continuity policy;
+context telemetry is evidence to interpret, not automatic authority to compact
+or replace another seat.
 
 ## Intervention discipline
 
@@ -283,5 +265,5 @@ installed skill or a quiz as a universal admission gate.
 - relay messages between agents (they communicate directly)
 - auto-approve destructive operations
 - rush agents with deadline pressure
-- write implementation specs (that's a Claude task, not Codex)
-- intervene based on Codex context percentage
+- assign specification or acceptance authority from a runtime label alone
+- change continuity from a context percentage without the selected policy and authority

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

@@ -1,8 +1,8 @@
 # agent-browser: Local Dev Insights
 
-> Companion to the official SKILL.md. These are gotchas, corrections, and best practices
-> discovered through hands-on testing that the upstream skill doesn't cover.
-> Last updated: 2026-02-20 | Tested against: v0.13.0
+> Companion notes for browser tasks. Command details below reflect v0.13.0-era
+> usage and may differ in the installed release. Check current help and verify
+> the target operation; this file is not a current browser or login test receipt.
 
 ---
 
@@ -60,7 +60,7 @@ Refs are invalidated by **any page state change**. This includes:
 | `-s "#sel"` | Scoped to selector | Laser focus on one component |
 | `--json` | JSON format | Programmatic parsing |
 
-**Token efficiency example:** GitHub repo page with 4,574 DOM elements → `snapshot -i` returns ~25 lines.
+Use an interactive or scoped snapshot when a full DOM listing would obscure the elements needed for the task.
 
 ## Annotated Screenshots
 
@@ -121,55 +121,26 @@ EVALEOF
 - **Persistent headed config:** Add `{"headed": true}` to `~/.agent-browser/config.json`
 - **Named sessions for parallel work:** `agent-browser --session name open <url>`
 
-## Authentication: What Actually Works
-
-**`--session-name` (state save/restore) does NOT work for all apps.** It saves cookies and localStorage, but apps using HTTP-only cookies, server-side sessions, or complex auth flows may not persist. Tested and failed on: example-app-1 (Example Service One / localhost:8083).
-
-**`--profile` (persistent Chrome profile) is the reliable approach.** It preserves everything - cookies, localStorage, IndexedDB, cache, service workers. This is what actually works for real apps.
-
-### Saved Profiles
-
-| Profile | Service | URL | Command |
-|---------|---------|-----|---------|
-| `example-app-1` | Example Service One | `http://localhost:8083` | `agent-browser --profile ~/.agent-browser/profiles/example-app-1 open http://localhost:8083` |
-| `localhost-3000` | Example Service Two (Clerk auth) | `http://localhost:3000` | `agent-browser --profile ~/.agent-browser/profiles/localhost-3000 open http://localhost:3000` |
-| `local-app-email-profile` | Example Service Three (email login) | `http://localhost:3010` | `agent-browser --profile ~/.agent-browser/profiles/local-app-email-profile open http://localhost:3010` |
-| `local-app-google-profile` | Example Service Three (Google auth) | `http://localhost:3010` | See Google OAuth note below |
-
-### Google OAuth Profiles
-
-Google blocks sign-in from the bundled Chromium ("This browser or app may not be secure"). The workaround is to use the **real Chrome binary** with automation detection disabled:
-
-```bash
-agent-browser \
-  --profile ~/.agent-browser/profiles/local-app-google-profile \
-  --executable-path "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
-  --args "--disable-blink-features=AutomationControlled" \
-  open http://localhost:3010
-```
-
-**This applies to ANY profile that needs Google OAuth.** Always use `--executable-path` + `--args` for Google sign-in flows.
-
-### Auth Setup Pattern
-
-```bash
-# First time: login in headed mode (user enters password)
-agent-browser --profile ~/.agent-browser/profiles/<name> --headed true open <login-url>
-# ... user logs in manually ...
-agent-browser close
-
-# Every future run: headless, already authenticated
-agent-browser --profile ~/.agent-browser/profiles/<name> open <app-url>
-```
-
-### Encryption
-
-Session state files in `~/.agent-browser/sessions/` are encrypted with AES-256-GCM.
-Key stored at `~/.agent-browser/.encryption-key` (chmod 600).
-Loaded via `AGENT_BROWSER_ENCRYPTION_KEY` env var in `~/.zshrc`.
-
-Note: `--profile` directories are NOT encrypted (they're standard Chromium profile dirs).
-Keep `~/.agent-browser/profiles/` permissions locked down.
+## Authentication and retained browser state
+
+Choose the installed tool's supported state or profile mechanism for the target
+application. A saved state file or persistent profile does not prove a later
+session is authenticated: check the intended account and a meaningful authorized
+page or operation after reopening. Server expiry and application policy can
+invalidate retained state.
+
+Use an explicitly owned profile for the task. Obtain any required login through
+the user's authorized flow; do not assume a profile, account, application URL or
+provider workaround from this guide. Browser/provider compatibility must be
+checked for the actual version and flow. No tested login or saved profile is
+shipped with these notes.
+
+Treat profile directories and saved state as credential-bearing data. Keep them
+in the authorized private location, restrict access, and omit cookies, tokens,
+passwords and encryption keys from source, ordinary logs and shared evidence.
+If encryption is configured, verify the actual tool configuration and key custody;
+do not infer encryption from a filename or assume a shell already exports a key.
+Retain or remove only state the task owns and whose disposition is authorized.
 
 ## Updating the Official Skill
 

package/daemon/specs/agents/shared/skills/process/systematic-debugging/find-polluter.sh

@@ -3,12 +3,14 @@
 # Usage: ./find-polluter.sh <file_or_dir_to_check> <test_pattern>
 # Example: ./find-polluter.sh '.git' 'src/**/*.test.ts'
 
-set -e
+# Exit 0: every selected test succeeded without pollution; 1: polluter found;
+# 2: no result (invalid input, selection failure, or incomplete test runs).
+set -eo pipefail
 
 if [ $# -ne 2 ]; then
   echo "Usage: $0 <file_to_check> <test_pattern>"
   echo "Example: $0 '.git' 'src/**/*.test.ts'"
-  exit 1
+  exit 2
 fi
 
 POLLUTION_CHECK="$1"
@@ -19,27 +21,35 @@ echo "Test pattern: $TEST_PATTERN"
 echo ""
 
 # Get list of test files
-TEST_FILES=$(find . -path "$TEST_PATTERN" | sort)
-TOTAL=$(echo "$TEST_FILES" | wc -l | tr -d ' ')
+if ! TEST_FILES=$(find . -type f -path "./${TEST_PATTERN#./}" | sort); then
+  echo "Test selection failed; no tests ran."
+  exit 2
+fi
+if [ -z "$TEST_FILES" ]; then
+  echo "No test files matched; no tests ran."
+  exit 2
+fi
+TOTAL=$(printf '%s\n' "$TEST_FILES" | wc -l | tr -d ' ')
 
 echo "Found $TOTAL test files"
 echo ""
 
 COUNT=0
-for TEST_FILE in $TEST_FILES; do
+FAILED=0
+if [ -e "$POLLUTION_CHECK" ]; then
+  echo "Pollution already exists before testing; no tests ran."
+  exit 2
+fi
+while IFS= read -r TEST_FILE; do
   COUNT=$((COUNT + 1))
 
-  # Skip if pollution already exists
-  if [ -e "$POLLUTION_CHECK" ]; then
-    echo "⚠️  Pollution already exists before test $COUNT/$TOTAL"
-    echo "   Skipping: $TEST_FILE"
-    continue
-  fi
-
   echo "[$COUNT/$TOTAL] Testing: $TEST_FILE"
 
   # Run the test
-  npm test "$TEST_FILE" > /dev/null 2>&1 || true
+  if ! npm test "$TEST_FILE" > /dev/null 2>&1; then
+    FAILED=$((FAILED + 1))
+    echo "Test run failed: $TEST_FILE"
+  fi
 
   # Check if pollution appeared
   if [ -e "$POLLUTION_CHECK" ]; then
@@ -56,8 +66,12 @@ for TEST_FILE in $TEST_FILES; do
     echo "  cat $TEST_FILE         # Review test code"
     exit 1
   fi
-done
+done <<< "$TEST_FILES"
 
 echo ""
-echo "✅ No polluter found - all tests clean!"
+if [ "$FAILED" -gt 0 ]; then
+  echo "Incomplete: $FAILED test runs failed; no polluter observed."
+  exit 2
+fi
+echo "✅ No polluter found - $COUNT test runs succeeded without pollution."
 exit 0

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

@@ -4,8 +4,8 @@ description: Use when implementing any feature or bugfix, before writing impleme
 metadata:
   openrig:
     vendored_from: "Obra Superpowers (https://github.com/obra/superpowers)"
-    vendoring_pattern: vendored-as-is
-    last_upstream_check: "2026-05-13 (diff against plugin source pulled 2026-05-11 = identical)"
+    vendoring_pattern: modify-the-file
+    last_upstream_check: "2026-05-13 (historical upstream comparison; local scope and preservation adaptations made since)"
 ---
 
 # Test-Driven Development (TDD)
@@ -20,18 +20,22 @@ Write the test first. Watch it fail. Write minimal code to pass.
 
 ## When to Use
 
-**Always:**
+**Use test-first for selected behavior where regression risk warrants it:**
 - New features
 - Bug fixes
 - Refactoring
 - Behavior changes
 
-**Exceptions (ask your human partner):**
+**Choose proportionate verification for work such as:**
 - Throwaway prototypes
 - Generated code
 - Configuration files
 
-Thinking "skip TDD just this once"? Stop. That's rationalization.
+Resolve the task's selected project/mission/slice procedure first. A required
+TDD step remains required within that scope; changing it needs the authority
+named by that selection. Outside it, choose verification that can detect the
+failure without adding a human approval ritual. The procedure below describes
+TDD when selected, not a completion gate for every kind of work.
 
 **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,
@@ -40,21 +44,17 @@ project/mission/slice component or wave selection. An explicitly selected gate
 still applies; an unselected role cannot add one.
 
 
-## The Iron Law
+## Test-First Contract for Selected Behavior
 
 ```
-NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
+Selected TDD behavior: observe the expected failure before implementing the fix.
 ```
 
-Write code before the test? Delete it. Start over.
-
-**No exceptions:**
-- Don't keep it as "reference"
-- Don't "adapt" it while writing tests
-- Don't look at it
-- Delete means delete
-
-Implement fresh from tests. Period.
+Already wrote the implementation? Preserve existing and others' bytes. Establish
+the failing baseline in an isolated copy or by reversibly setting aside only
+your owned change, then implement from the behavioral test. This skill grants
+no authority to delete code. If a failing baseline cannot be demonstrated,
+record that limit and follow the selected procedure; do not call tests-after TDD.
 
 ## Red-Green-Refactor
 
@@ -124,7 +124,7 @@ Vague name, tests mock not code
 
 ### Verify RED - Watch It Fail
 
-**MANDATORY. Never skip.**
+**Required to establish RED in the selected TDD cycle.**
 
 ```bash
 npm test path/to/test.test.ts
@@ -179,7 +179,7 @@ Don't add features, refactor other code, or "improve" beyond the test.
 
 ### Verify GREEN - Watch It Pass
 
-**MANDATORY.**
+**Required to establish GREEN in the selected TDD cycle.**
 
 ```bash
 npm test path/to/test.test.ts
@@ -237,13 +237,11 @@ Manual testing is ad-hoc. You think you tested everything but:
 
 Automated tests are systematic. They run the same way every time.
 
-**"Deleting X hours of work is wasteful"**
+**"I already spent X hours on the implementation"**
 
-Sunk cost fallacy. The time is already gone. Your choice now:
-- Delete and rewrite with TDD (X more hours, high confidence)
-- Keep it and add tests after (30 min, low confidence, likely bugs)
-
-The "waste" is keeping code you can't trust. Working code without real tests is technical debt.
+Time spent does not prove behavior. Preserve the work and demonstrate that the
+test detects the missing behavior on a baseline without the owned change.
+Then verify the implementation against it. Report the actual sequence honestly.
 
 **"TDD is dogmatic, being pragmatic means adapting"**
 
@@ -267,21 +265,24 @@ Tests-first force edge case discovery before implementing. Tests-after verify yo
 
 ## Common Rationalizations
 
+These challenges apply within selected TDD work, not to an authorized choice
+of another verification method.
+
 | Excuse | Reality |
 |--------|---------|
-| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
+| "Too simple to test" | Simplicity alone does not waive a selected behavioral check. |
 | "I'll test after" | Tests passing immediately prove nothing. |
 | "Tests after achieve same goals" | Tests-after = "what does this do?" Tests-first = "what should this do?" |
 | "Already manually tested" | Ad-hoc ≠ systematic. No record, can't re-run. |
-| "Deleting X hours is wasteful" | Sunk cost fallacy. Keeping unverified code is technical debt. |
-| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete. |
-| "Need to explore first" | Fine. Throw away exploration, start with TDD. |
+| "Already spent X hours" | Time spent is not evidence; preserve the work and prove the failing baseline. |
+| "Keep as reference, write tests first" | Tests derived from the implementation risk repeating its assumptions; use the required behavior and a failing baseline. |
+| "Need to explore first" | Keep exploration separate from the implementation and begin the selected TDD cycle when the behavior is understood. |
 | "Test hard = design unclear" | Listen to test. Hard to test = hard to use. |
 | "TDD will slow me down" | TDD faster than debugging. Pragmatic = test-first. |
 | "Manual test faster" | Manual doesn't prove edge cases. You'll re-test every change. |
 | "Existing code has no tests" | You're improving it. Add tests for existing code. |
 
-## Red Flags - STOP and Start Over
+## Red Flags in Selected TDD Work
 
 - Code before test
 - Test after implementation
@@ -293,11 +294,13 @@ Tests-first force edge case discovery before implementing. Tests-after verify yo
 - "Tests after achieve the same purpose"
 - "It's about spirit not ritual"
 - "Keep as reference" or "adapt existing code"
-- "Already spent X hours, deleting is wasteful"
+- "Already spent X hours, so verification can wait"
 - "TDD is dogmatic, I'm being pragmatic"
 - "This is different because..."
 
-**All of these mean: Delete code. Start over with TDD.**
+Check whether the claimed RED → GREEN sequence actually happened. Repair the
+missing evidence using the preservation rule above; these signals never
+authorize deleting existing work.
 
 ## Example: Bug Fix
 
@@ -338,9 +341,9 @@ Extract validation for multiple fields if needed.
 
 ## Verification Checklist
 
-Before marking work complete:
+Before claiming the selected TDD work complete:
 
-- [ ] Every new function/method has a test
+- [ ] Tests cover the selected behavioral outcomes
 - [ ] Watched each test fail before implementing
 - [ ] Each test failed for expected reason (feature missing, not typo)
 - [ ] Wrote minimal code to pass each test
@@ -349,22 +352,25 @@ Before marking work complete:
 - [ ] Tests use real code (mocks only if unavoidable)
 - [ ] Edge cases and errors covered
 
-Can't check all boxes? You skipped TDD. Start over.
+An unmet selected check remains visible. Address it or obtain the disposition
+required by the selected procedure; do not turn this checklist into a gate on
+unselected work or erase code to make the history look test-first.
 
 ## When Stuck
 
 | Problem | Solution |
 |---------|----------|
-| Don't know how to test | Write wished-for API. Write assertion first. Ask your human partner. |
+| Don't know how to test | Write the desired API and assertion first. Consult the relevant peer or work owner if the behavior is unclear. |
 | Test too complicated | Design too complicated. Simplify interface. |
 | Must mock everything | Code too coupled. Use dependency injection. |
 | Test setup huge | Extract helpers. Still complex? Simplify design. |
 
 ## Debugging Integration
 
-Bug found? Write failing test reproducing it. Follow TDD cycle. Test proves fix and prevents regression.
+For a bug in selected TDD scope, write a failing test reproducing it. Follow the
+TDD cycle to demonstrate the fix and prevent regression.
 
-Never fix bugs without a test.
+Outside that scope, choose a proportionate regression check and retain its evidence.
 
 ## Testing Anti-Patterns
 
@@ -376,8 +382,9 @@ When adding mocks or test utilities, read @testing-anti-patterns.md to avoid com
 ## Final Rule
 
 ```
-Production code → test exists and failed first
-Otherwise → not TDD
+Selected TDD behavior → test exists and failed first
+Otherwise → do not claim a test-first sequence
 ```
 
-No exceptions without your human partner's permission.
+Honor explicitly selected gates and their decision owner. This skill adds no
+universal human permission step, deletion authority or gate on unselected work.

package/daemon/specs/agents/shared/skills/process/verification-before-completion/SKILL.md

@@ -4,7 +4,7 @@ description: Use when about to claim work is complete, fixed, or passing, before
 metadata:
   openrig:
     vendored_from: "Obra Superpowers (https://github.com/obra/superpowers)"
-    vendoring_pattern: vendored-as-is
+    vendoring_pattern: modify-the-file
     last_upstream_check: "2026-05-13 (diff against plugin source pulled 2026-05-11 = identical)"
 ---
 
@@ -116,10 +116,10 @@ Running a verification is necessary but not sufficient: a check can exit clean a
 
 - **Assert on CONTENT, never shape or count.** Output that *looks* like success — a non-zero count, a clean exit, no error text — can carry failure as its content. Before trusting a check, ask what its output looks like *when it fails*: if failure and success are indistinguishable at a glance, the check proves nothing. (`[1 lines]` and `No matches found` both read as "a match" to a line-count.)
 - **Compare the returned value to the value you PASSED — never to a description of it.** A confident label (`evidenceRef NOW SET:` printed above the untouched original) is indistinguishable from a verification in a transcript. Diff the actual result against your actual input, not against a claim about it.
-- **Find the untested axis.** Thorough coverage of ONE axis reads as thorough coverage overall. Ask what every one of your tests shares — a healthy manifest, a default option value, the happy path — and treat that shared assumption as the dimension you never tested. (A 15-case "exhaustive" harness whose only defect lived on the one axis every case held constant.)
+- **Find the untested axis.** Thorough coverage of ONE axis reads as thorough coverage overall. Ask what every one of your tests shares — a healthy manifest, a default option value, the happy path — and treat that shared assumption as the dimension you never tested.
 - **A syntax check proves parseability and nothing else.** A clean `node --check` / lint / parse pass is the *covered* axis; boot and runtime are the untested one. Parseable ≠ sound.
 - **A failure whose shape is a HANG reports nothing.** A bare `await` against a stated deadline that never re-checks cannot fail loudly. Race it against a timer so failure has a shape you can see.
-- **A completeness inventory read through a truncating display is worthless.** When deciding *which occurrences to change*, count with `grep -c` / `grep -o` / full-line output — never `cut`, `head`, or a pager, which can hide a match *past* the cut (a doc pointer on a ~540-char line sat just past `cut -c1-180` and nearly shipped the defect inside its own fix). Distinguish *"I found N"* (a count) from *"I saw N"* (a display). Audit multiline prose **by paragraph, not by line** — a line filter both misses long-line matches and false-flags paragraphs whose companion text is on the next line. Then re-audit with a **different method** than the one that built the inventory — same-method re-checking reproduces the blind spot. (Empty/short output is a claim about your COMMAND until re-proven a second way.)
+- **A completeness inventory read through a truncating display is worthless.** When deciding *which occurrences to change*, count with `grep -c` / `grep -o` / full-line output — never `cut`, `head`, or a pager, which can hide a match *past* the cut. Distinguish *"I found N"* (a count) from *"I saw N"* (a display). Audit multiline prose **by paragraph, not by line** — a line filter both misses long-line matches and false-flags paragraphs whose companion text is on the next line. Then re-audit with a **different method** than the one that built the inventory — same-method re-checking reproduces the blind spot. (Empty/short output is a claim about your COMMAND until re-proven a second way.)
 
 ## Why This Matters
 

package/daemon/specs/rigs/launch/first-project/CULTURE.md

@@ -0,0 +1,39 @@
+# First project
+
+Work in the repository selected at launch. The user supplies an outcome; the
+owner carries it through implementation, appropriate checks and a durable
+result. Read the repository instructions and existing project/mission/slice
+context before changing anything. If there is no selected workflow, keep the
+path light. Do not install a release process for a first task.
+
+## Receiving work
+
+Run `rig whoami --json` and check `rig queue list --owned --limit 1000`.
+Claim an assigned row before working. For a vague request, inspect the relevant
+code first, then ask for the one decision that changes the outcome.
+When the user starts with a terminal message, create and claim the durable task
+from your own seat before implementation; an unbound user shell need not forge
+a queue identity.
+
+For the first meaningful code change, ask dev-check for an independent check
+of the exact diff and the behavior it promises. Subsequent checks should match
+the consequence of the work. Hand off through `rig queue handoff`, with the
+repository path, candidate commit or diff, checks run and any limits. Consult
+`--help` for current syntax. Do not use chat text as the work record.
+
+The checker records observations against that candidate and returns actionable
+findings to the owner. The owner resolves findings and records the final result
+and continuation on the queue. Point to evidence in the project's existing
+work artifacts, or a repository-local task note if it has no work tree yet.
+Do not mark a change accepted because another row closed.
+
+## Boundaries and continuation
+
+Keep local edits and commits within the assigned change. Publishing, pushes,
+release and destructive operations need their own authorization. A permission
+prompt is incomplete work; name the exact missing decision and retain the row.
+
+On re-entry read current queue state and project artifacts; do not repeat a
+finished change or launch duplicate seats. Explain the result in terms the
+user can exercise, state what was not checked, and name the next useful action.
+Leave the project ready for another outcome at the same owner address.

package/daemon/specs/rigs/launch/first-project/rig.yaml

@@ -0,0 +1,31 @@
+version: "0.2"
+name: first-project
+summary: >
+  Two Codex seats in your repository: an outcome owner and an independent
+  checker. Give the owner one bounded change; follow the durable result and
+  continue at the same address. See docs/reference/getting-started.md.
+
+culture_file: CULTURE.md
+
+pods:
+  - id: dev
+    label: Project
+    members:
+      - id: owner
+        agent_ref: "local:../../../agents/development/implementer"
+        runtime: codex
+        model: gpt-6-astra
+        profile: default
+        cwd: "."
+      - id: check
+        agent_ref: "local:../../../agents/development/qa"
+        runtime: codex
+        model: gpt-6-astra
+        profile: default
+        cwd: "."
+    edges:
+      - kind: delegates_to
+        from: owner
+        to: check
+
+edges: []