@openrig/cli 0.5.10 → 0.5.12

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/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