@simplysm/sd-claude 13.0.78 → 13.0.80

package/claude/skills/sd-brainstorm/SKILL.md

@@ -1,215 +0,0 @@
----
-name: sd-brainstorm
-description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
----
-
-# Brainstorming Ideas Into Designs
-
-## Overview
-
-Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
-
-Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design in small sections (200-300 words), checking after each section whether it looks right so far.
-
-## The Process
-
-**Understanding the idea:**
-- Check out the current project state first (files, docs, recent commits).
-- Ask questions one at a time to refine the idea
-- Prefer multiple choice questions when possible, but open-ended is fine too
-- Only one question per message - if a topic needs more exploration, break it into multiple questions
-- Focus on understanding: purpose, constraints, success criteria
-
-**When a main design document is provided as context:**
-
-```mermaid
-flowchart TD
-    A{"Main design with<br>section plan in context?"}
-    A -->|no| B[Normal brainstorm]
-    A -->|yes| C{Section specified?}
-    C -->|no| D["Show section progress<br>Ask which section<br>(suggest next incomplete)"]
-    C -->|yes| E{"Prerequisites<br>complete?"}
-    E -->|yes| F[Proceed with section]
-    E -->|no| G["Warn prerequisites incomplete<br>Ask: proceed anyway<br>or complete first?"]
-    G -->|"user: proceed"| F
-```
-
-When proceeding with a section:
-
-1. **Read the main design** — understand goals, overall structure, and the target section's scope
-2. **Read actual code** — check the current codebase state for what previous sections have built. Reference the **actual code**, NOT previous section design documents. Code may have diverged from earlier designs during implementation.
-3. **Scope the brainstorm** — limit questions, gap review, approaches, and design presentation to the target section only. Do not re-question decisions already established in the main design.
-4. **Conflict detection** — if the main design's direction conflicts with the actual code state, alert the user and ask for direction before proceeding.
-5. After the design is complete, save as `docs/plans/YYYY-MM-DD-<topic>-section-N-design.md`
-6. Update the main design document: mark the section `[ ]` → `[x]` in the section plan
-7. Commit both files, then proceed to the normal **Next Steps Guide** (Path A/B)
-
-**Gap review loop:**
-
-When you think you've asked enough, **STOP and run a gap review before moving on.**
-
-Tell the user you're running a gap review, then check ALL categories. For each ✅, you MUST **cite specific evidence** (which Q&A, code reference, or explicit user requirement). "I already know" is not evidence.
-
-| Category | Check for... |
-|----------|-------------|
-| Scope | What's in? What's explicitly out? |
-| User flows | All inputs, outputs, feedback, navigation |
-| Edge cases | Empty states, errors, limits, concurrency, undo |
-| Data | Shape, validation, persistence, migration, relationships |
-| Integration | How does this connect to existing code/systems? |
-| Non-functional | Performance, accessibility, security, i18n |
-| Assumptions | Anything you assumed but never confirmed |
-
-Output format — cite evidence for each:
-- `✅ Scope — [Q2: user confirmed X / code at file:line / requirement doc says Y]`
-- `❓ Edge cases — gap: [what's missing]`
-
-If evidence is vague ("obvious", "I already know", "common sense") → mark as ❓, not ✅.
-
-- If ANY ❓ exists → ask about it. After the user answers, **run the full checklist again from scratch**.
-- Only when ALL categories show ✅ with cited evidence → proceed to exploring approaches.
-
-**All-✅ on first run is PROHIBITED — not "suspicious", prohibited.**
-If your first gap review shows all ✅:
-1. You are rubber-stamping. Prior investigation ≠ complete design exploration.
-2. Pick the 2 weakest categories (thinnest evidence).
-3. Write one concrete unasked question per category.
-4. Ask those questions, then re-run the full checklist from scratch.
-
-| Excuse | Reality |
-|--------|---------|
-| "Requirements are already clear" | Clear requirements ≠ complete design. Edge cases, error states, integration points still need exploration. |
-| "I already investigated the code" | Code investigation reveals what IS. Design exploration asks what SHOULD BE. Different activities. |
-| "It's just a bug fix" | Bug fixes have edge cases: error states, concurrent access, timing changes, consumer compatibility. |
-| "User is frustrated/in a hurry" | Rushing causes exactly the mistakes brainstorming prevents. Slow down. |
-
-**Rules:**
-- You MUST show the checklist to the user every time you run it. No silent/internal-only checks.
-- Each run must re-examine ALL categories from zero — do not carry over previous results.
-- When in doubt, ask. One extra question costs less than a flawed design.
-
-**Exploring approaches:**
-- Propose 2-3 different approaches with trade-offs
-- Present options conversationally with your recommendation and reasoning
-- Lead with your recommended option and explain why
-
-**Scale assessment:**
-
-After the approach is selected, assess scale (file count, logic complexity, number of distinct subsystems, scope of impact):
-
-```mermaid
-flowchart TD
-    A{"Assess design scale"}
-    A -->|manageable| B["Proceed to<br>After the Design<br>(Path A/B)"]
-    A -->|large| C["Propose to user:<br>proceed as-is OR<br>split into sections"]
-    C --> D{"User choice?"}
-    D -->|"proceed as-is"| B
-    D -->|split| E["Propose 2-3 section<br>division approaches<br>(by feature/layer/dependency)"]
-    E -->|"user selects"| F["Append section plan<br>to design doc<br>Save + commit"]
-    F --> G["Show section guide<br>Brainstorm ENDS"]
-```
-
-**How to present the split proposal:**
-
-When proposing the split to the user, you MUST clearly explain what "section split" means:
-
-- **Section split** = the design document is divided into sections, and each section goes through its own **separate brainstorm → plan → plan-dev → check → commit cycle**.
-- This is NOT about implementation phasing (doing some changes before others). It's about breaking the design work itself into independently deliverable chunks.
-- Explain: "Splitting into sections means each section goes through its own brainstorm → plan → plan-dev cycle. Complete and commit one section before moving to the next."
-- Contrast with: "Proceeding as-is means this single design document goes straight to plan → plan-dev."
-
-**Section plan format** (append to existing design content as-is):
-
-```markdown
----
-
-## Section Plan
-
-- [ ] Section 1: <name> — <scope summary>
-- [ ] Section 2: <name> — <scope summary> (after section 1)
-- [ ] Section 3: <name> — <scope summary> (after section 1, 2)
-```
-
-**Section guide** (shown instead of Path A/B, in user's configured language):
-
-```
-Design has been split into sections.
-
-Main design: docs/plans/YYYY-MM-DD-<topic>-design.md
-
-Section progress:
-- [ ] Section 1: <name>
-- [ ] Section 2: <name> (after section 1)
-- [ ] Section 3: <name> (after section 1, 2)
-
-Run each section in order:
-  sd-brainstorm docs/plans/YYYY-MM-DD-<topic>-design.md section 1
-
-After each section's brainstorm completes, you can choose Path A/B
-to run plan → plan-dev → check → commit.
-```
-
-Do NOT auto-proceed to any section.
-
-## After the Design
-
-**Documentation:**
-- Write the validated design to `docs/plans/YYYY-MM-DD-<topic>-design.md`
-- Commit the design document to git
-
-**Next Steps Guide:**
-
-Present the following two workflow paths so the user can see the full process and choose.
-Display the guide in the **user's configured language** (follow the language settings from CLAUDE.md or system instructions).
-
-Before presenting, check git status for uncommitted changes. If there are any uncommitted changes (staged, unstaged, or untracked files), append the warning line (shown below) at the end of the guide block.
-
-```
-Design complete! Here's how to proceed:
-
---- Path A: With branch isolation (recommended for features/large changes) ---
-
-1. /sd-worktree add <name>  — Create a worktree branch
-2. /sd-plan                 — Break into detailed tasks
-3. /sd-plan-dev             — Execute tasks in parallel (includes TDD + review)
-4. /sd-check                — Verify (modified + dependents)
-5. /sd-commit               — Commit
-6. /sd-worktree merge       — Merge back to main
-7. /sd-worktree clean       — Remove worktree
-
---- Path B: Direct on current branch (quick fixes/small changes) ---
-
-1. /sd-plan                 — Break into detailed tasks
-2. /sd-plan-dev             — Execute tasks in parallel (includes TDD + review)
-3. /sd-check                — Verify (modified + dependents)
-4. /sd-commit               — Commit
-
-You can start from any step or skip steps as needed.
-
-💡 "Path A: yolo" or "Path B: yolo" to auto-run all steps
-
-⚠️ You have uncommitted changes. To use Path A, run `/sd-commit all` first.
-```
-
-- The last `⚠️` line is only shown when uncommitted changes exist. Omit it when working tree is clean.
-- If the design does NOT involve code modifications, omit the `/sd-check` step from both paths.
-
-- After presenting both paths, **recommend one** based on the design's scope:
-   - Path A recommended: new features, multi-file changes, architectural changes, anything that benefits from isolation
-   - Path B recommended: small bug fixes, single-file changes, config tweaks, minor adjustments
-   - Briefly explain why (1 sentence)
-- Do NOT auto-proceed to any step. Present the overview with recommendation and wait for the user's choice.
-- **Yolo mode**: If the user responds with "Path A: yolo" or "Path B: yolo" (or similar intent like "A yolo", "B auto"), execute all steps of the chosen path sequentially without stopping between steps.
-- **Yolo sd-check — include dependents**: NEVER check only modified packages. Also check all packages that depend on them:
-   1. Identify modified packages from `git diff --name-only`
-   2. Trace reverse dependencies (packages that import from modified packages) using `package.json` or project dependency graph
-   3. Include integration/e2e tests that cover the modified packages
-   4. Run `/sd-check` with all affected paths, or `/sd-check` without path (whole project) when changes are widespread
-
-## Key Principles
-
-- **One question at a time** - Don't overwhelm with multiple questions
-- **Multiple choice preferred** - Easier to answer than open-ended when possible
-- **YAGNI ruthlessly** - Remove unnecessary features from all designs
-- **Explore alternatives** - Always propose 2-3 approaches before settling
-- **Be flexible** - Go back and clarify when something doesn't make sense

package/claude/skills/sd-debug/condition-based-waiting-example.ts

@@ -1,158 +0,0 @@
-// Complete implementation of condition-based waiting utilities
-// From: Lace test infrastructure improvements (2025-10-03)
-// Context: Fixed 15 flaky tests by replacing arbitrary timeouts
-
-import type { ThreadManager } from "~/threads/thread-manager";
-import type { LaceEvent, LaceEventType } from "~/threads/types";
-
-/**
- * Wait for a specific event type to appear in thread
- *
- * @param threadManager - The thread manager to query
- * @param threadId - Thread to check for events
- * @param eventType - Type of event to wait for
- * @param timeoutMs - Maximum time to wait (default 5000ms)
- * @returns Promise resolving to the first matching event
- *
- * Example:
- *   await waitForEvent(threadManager, agentThreadId, 'TOOL_RESULT');
- */
-export function waitForEvent(
-  threadManager: ThreadManager,
-  threadId: string,
-  eventType: LaceEventType,
-  timeoutMs = 5000,
-): Promise<LaceEvent> {
-  return new Promise((resolve, reject) => {
-    const startTime = Date.now();
-
-    const check = () => {
-      const events = threadManager.getEvents(threadId);
-      const event = events.find((e) => e.type === eventType);
-
-      if (event) {
-        resolve(event);
-      } else if (Date.now() - startTime > timeoutMs) {
-        reject(new Error(`Timeout waiting for ${eventType} event after ${timeoutMs}ms`));
-      } else {
-        setTimeout(check, 10); // Poll every 10ms for efficiency
-      }
-    };
-
-    check();
-  });
-}
-
-/**
- * Wait for a specific number of events of a given type
- *
- * @param threadManager - The thread manager to query
- * @param threadId - Thread to check for events
- * @param eventType - Type of event to wait for
- * @param count - Number of events to wait for
- * @param timeoutMs - Maximum time to wait (default 5000ms)
- * @returns Promise resolving to all matching events once count is reached
- *
- * Example:
- *   // Wait for 2 AGENT_MESSAGE events (initial response + continuation)
- *   await waitForEventCount(threadManager, agentThreadId, 'AGENT_MESSAGE', 2);
- */
-export function waitForEventCount(
-  threadManager: ThreadManager,
-  threadId: string,
-  eventType: LaceEventType,
-  count: number,
-  timeoutMs = 5000,
-): Promise<LaceEvent[]> {
-  return new Promise((resolve, reject) => {
-    const startTime = Date.now();
-
-    const check = () => {
-      const events = threadManager.getEvents(threadId);
-      const matchingEvents = events.filter((e) => e.type === eventType);
-
-      if (matchingEvents.length >= count) {
-        resolve(matchingEvents);
-      } else if (Date.now() - startTime > timeoutMs) {
-        reject(
-          new Error(
-            `Timeout waiting for ${count} ${eventType} events after ${timeoutMs}ms (got ${matchingEvents.length})`,
-          ),
-        );
-      } else {
-        setTimeout(check, 10);
-      }
-    };
-
-    check();
-  });
-}
-
-/**
- * Wait for an event matching a custom predicate
- * Useful when you need to check event data, not just type
- *
- * @param threadManager - The thread manager to query
- * @param threadId - Thread to check for events
- * @param predicate - Function that returns true when event matches
- * @param description - Human-readable description for error messages
- * @param timeoutMs - Maximum time to wait (default 5000ms)
- * @returns Promise resolving to the first matching event
- *
- * Example:
- *   // Wait for TOOL_RESULT with specific ID
- *   await waitForEventMatch(
- *     threadManager,
- *     agentThreadId,
- *     (e) => e.type === 'TOOL_RESULT' && e.data.id === 'call_123',
- *     'TOOL_RESULT with id=call_123'
- *   );
- */
-export function waitForEventMatch(
-  threadManager: ThreadManager,
-  threadId: string,
-  predicate: (event: LaceEvent) => boolean,
-  description: string,
-  timeoutMs = 5000,
-): Promise<LaceEvent> {
-  return new Promise((resolve, reject) => {
-    const startTime = Date.now();
-
-    const check = () => {
-      const events = threadManager.getEvents(threadId);
-      const event = events.find(predicate);
-
-      if (event) {
-        resolve(event);
-      } else if (Date.now() - startTime > timeoutMs) {
-        reject(new Error(`Timeout waiting for ${description} after ${timeoutMs}ms`));
-      } else {
-        setTimeout(check, 10);
-      }
-    };
-
-    check();
-  });
-}
-
-// Usage example from actual debugging session:
-//
-// BEFORE (flaky):
-// ---------------
-// const messagePromise = agent.sendMessage('Execute tools');
-// await new Promise(r => setTimeout(r, 300)); // Hope tools start in 300ms
-// agent.abort();
-// await messagePromise;
-// await new Promise(r => setTimeout(r, 50));  // Hope results arrive in 50ms
-// expect(toolResults.length).toBe(2);         // Fails randomly
-//
-// AFTER (reliable):
-// ----------------
-// const messagePromise = agent.sendMessage('Execute tools');
-// await waitForEventCount(threadManager, threadId, 'TOOL_CALL', 2); // Wait for tools to start
-// agent.abort();
-// await messagePromise;
-// await waitForEventCount(threadManager, threadId, 'TOOL_RESULT', 2); // Wait for results
-// expect(toolResults.length).toBe(2); // Always succeeds
-//
-// Result: 60% pass rate → 100%, 40% faster execution

package/claude/skills/sd-debug/condition-based-waiting.md

@@ -1,114 +0,0 @@
-# Condition-Based Waiting
-
-## Overview
-
-Flaky tests often guess at timing with arbitrary delays. This creates race conditions where tests pass on fast machines but fail under load or in CI.
-
-**Core principle:** Wait for the actual condition you care about, not a guess about how long it takes.
-
-## When to Use
-
-```mermaid
-flowchart TD
-    A{"Test uses setTimeout/sleep?"} -->|yes| B{"Testing timing behavior?"}
-    B -->|yes| C[Document WHY timeout needed]
-    B -->|no| D[Use condition-based waiting]
-```
-
-**Use when:**
-
-- Tests have arbitrary delays (`setTimeout`, `sleep`, `time.sleep()`)
-- Tests are flaky (pass sometimes, fail under load)
-- Tests timeout when run in parallel
-- Waiting for async operations to complete
-
-**Don't use when:**
-
-- Testing actual timing behavior (debounce, throttle intervals)
-- Always document WHY if using arbitrary timeout
-
-## Core Pattern
-
-```typescript
-// ❌ BEFORE: Guessing at timing
-await new Promise((r) => setTimeout(r, 50));
-const result = getResult();
-expect(result).toBeDefined();
-
-// ✅ AFTER: Waiting for condition
-await waitFor(() => getResult() !== undefined);
-const result = getResult();
-expect(result).toBeDefined();
-```
-
-## Quick Patterns
-
-| Scenario          | Pattern                                              |
-| ----------------- | ---------------------------------------------------- |
-| Wait for event    | `waitFor(() => events.find(e => e.type === 'DONE'))` |
-| Wait for state    | `waitFor(() => machine.state === 'ready')`           |
-| Wait for count    | `waitFor(() => items.length >= 5)`                   |
-| Wait for file     | `waitFor(() => fs.existsSync(path))`                 |
-| Complex condition | `waitFor(() => obj.ready && obj.value > 10)`         |
-
-## Implementation
-
-Generic polling function:
-
-```typescript
-async function waitFor<T>(
-  condition: () => T | undefined | null | false,
-  description: string,
-  timeoutMs = 5000,
-): Promise<T> {
-  const startTime = Date.now();
-
-  while (true) {
-    const result = condition();
-    if (result) return result;
-
-    if (Date.now() - startTime > timeoutMs) {
-      throw new Error(`Timeout waiting for ${description} after ${timeoutMs}ms`);
-    }
-
-    await new Promise((r) => setTimeout(r, 10)); // Poll every 10ms
-  }
-}
-```
-
-See `condition-based-waiting-example.ts` in this directory for complete implementation with domain-specific helpers (`waitForEvent`, `waitForEventCount`, `waitForEventMatch`) from actual debugging session.
-
-## Common Mistakes
-
-**❌ Polling too fast:** `setTimeout(check, 1)` - wastes CPU
-**✅ Fix:** Poll every 10ms
-
-**❌ No timeout:** Loop forever if condition never met
-**✅ Fix:** Always include timeout with clear error
-
-**❌ Stale data:** Cache state before loop
-**✅ Fix:** Call getter inside loop for fresh data
-
-## When Arbitrary Timeout IS Correct
-
-```typescript
-// Tool ticks every 100ms - need 2 ticks to verify partial output
-await waitForEvent(manager, "TOOL_STARTED"); // First: wait for condition
-await new Promise((r) => setTimeout(r, 200)); // Then: wait for timed behavior
-// 200ms = 2 ticks at 100ms intervals - documented and justified
-```
-
-**Requirements:**
-
-1. First wait for triggering condition
-2. Based on known timing (not guessing)
-3. Comment explaining WHY
-
-## Real-World Impact
-
-From debugging session (2025-10-03):
-
-- Fixed 15 flaky tests across 3 files
-- Pass rate: 60% → 100%
-- Execution time: 40% faster
-- No more race conditions

package/claude/skills/sd-debug/defense-in-depth.md

@@ -1,128 +0,0 @@
-# Defense-in-Depth Validation
-
-## Overview
-
-When you fix a bug caused by invalid data, adding validation at one place feels sufficient. But that single check can be bypassed by different code paths, refactoring, or mocks.
-
-**Core principle:** Validate at EVERY layer data passes through. Make the bug structurally impossible.
-
-## Why Multiple Layers
-
-Single validation: "We fixed the bug"
-Multiple layers: "We made the bug impossible"
-
-Different layers catch different cases:
-
-- Entry validation catches most bugs
-- Business logic catches edge cases
-- Environment guards prevent context-specific dangers
-- Debug logging helps when other layers fail
-
-## The Four Layers
-
-### Layer 1: Entry Point Validation
-
-**Purpose:** Reject obviously invalid input at API boundary
-
-```typescript
-function createProject(name: string, workingDirectory: string) {
-  if (!workingDirectory || workingDirectory.trim() === "") {
-    throw new Error("workingDirectory cannot be empty");
-  }
-  if (!existsSync(workingDirectory)) {
-    throw new Error(`workingDirectory does not exist: ${workingDirectory}`);
-  }
-  if (!statSync(workingDirectory).isDirectory()) {
-    throw new Error(`workingDirectory is not a directory: ${workingDirectory}`);
-  }
-  // ... proceed
-}
-```
-
-### Layer 2: Business Logic Validation
-
-**Purpose:** Ensure data makes sense for this operation
-
-```typescript
-function initializeWorkspace(projectDir: string, sessionId: string) {
-  if (!projectDir) {
-    throw new Error("projectDir required for workspace initialization");
-  }
-  // ... proceed
-}
-```
-
-### Layer 3: Environment Guards
-
-**Purpose:** Prevent dangerous operations in specific contexts
-
-```typescript
-async function gitInit(directory: string) {
-  // In tests, refuse git init outside temp directories
-  if (process.env.NODE_ENV === "test") {
-    const normalized = normalize(resolve(directory));
-    const tmpDir = normalize(resolve(tmpdir()));
-
-    if (!normalized.startsWith(tmpDir)) {
-      throw new Error(`Refusing git init outside temp dir during tests: ${directory}`);
-    }
-  }
-  // ... proceed
-}
-```
-
-### Layer 4: Debug Instrumentation
-
-**Purpose:** Capture context for forensics
-
-```typescript
-async function gitInit(directory: string) {
-  const stack = new Error().stack;
-  logger.debug("About to git init", {
-    directory,
-    cwd: process.cwd(),
-    stack,
-  });
-  // ... proceed
-}
-```
-
-## Applying the Pattern
-
-When you find a bug:
-
-1. **Trace the data flow** - Where does bad value originate? Where used?
-2. **Map all checkpoints** - List every point data passes through
-3. **Add validation at each layer** - Entry, business, environment, debug
-4. **Test each layer** - Try to bypass layer 1, verify layer 2 catches it
-
-## Example from Session
-
-Bug: Empty `projectDir` caused `git init` in source code
-
-**Data flow:**
-
-1. Test setup → empty string
-2. `Project.create(name, '')`
-3. `WorkspaceManager.createWorkspace('')`
-4. `git init` runs in `process.cwd()`
-
-**Four layers added:**
-
-- Layer 1: `Project.create()` validates not empty/exists/writable
-- Layer 2: `WorkspaceManager` validates projectDir not empty
-- Layer 3: `WorktreeManager` refuses git init outside tmpdir in tests
-- Layer 4: Stack trace logging before git init
-
-**Result:** All 1847 tests passed, bug impossible to reproduce
-
-## Key Insight
-
-All four layers were necessary. During testing, each layer caught bugs the others missed:
-
-- Different code paths bypassed entry validation
-- Mocks bypassed business logic checks
-- Edge cases on different platforms needed environment guards
-- Debug logging identified structural misuse
-
-**Don't stop at one validation point.** Add checks at every layer.

package/claude/skills/sd-debug/find-polluter.sh

@@ -1,64 +0,0 @@
-#!/bin/bash
-# Bisection script for finding which test creates unwanted files/directories
-# Usage: ./find-polluter.sh <file_or_dir_to_check> <test_pattern>
-# Example: ./find-polluter.sh '.git' 'src/**/*.test.ts'
-
-set -e
-
-if [ "$#" -ne 2 ]; then
-    echo "Usage: $0 <file_or_dir_to_check> <test_pattern>"
-    echo "Example: $0 '.git' 'src/**/*.test.ts'"
-    exit 1
-fi
-
-CHECK_PATH="$1"
-TEST_PATTERN="$2"
-
-# Detect package manager: pnpm -> yarn -> npm (default)
-if [ -f "pnpm-lock.yaml" ]; then PM="pnpm"
-elif [ -f "yarn.lock" ]; then PM="yarn"
-else PM="npm"
-fi
-
-# Find all test files matching pattern
-readarray -t TEST_FILES < <(find . -path "$TEST_PATTERN" -type f)
-
-if [ ${#TEST_FILES[@]} -eq 0 ]; then
-    echo "No test files found matching pattern: $TEST_PATTERN"
-    exit 1
-fi
-
-echo "Found ${#TEST_FILES[@]} test files"
-echo "Checking for pollution: $CHECK_PATH"
-echo ""
-
-for test_file in "${TEST_FILES[@]}"; do
-    # Skip if pollution already exists
-    if [ -e "$CHECK_PATH" ]; then
-        echo "⚠️  Pollution already exists, skipping to avoid false positive"
-        echo "   Please remove $CHECK_PATH and re-run"
-        exit 1
-    fi
-
-    echo "Testing: $test_file"
-
-    # Run the test
-    $PM test "$test_file" > /dev/null 2>&1 || true
-
-    # Check if pollution appeared
-    if [ -e "$CHECK_PATH" ]; then
-        echo ""
-        echo "🔴 FOUND POLLUTER: $test_file"
-        echo ""
-        echo "This test created: $CHECK_PATH"
-        ls -la "$CHECK_PATH" 2>/dev/null || echo "(path exists but can't stat)"
-        echo ""
-        echo "Investigate with:"
-        echo "  $PM test '$test_file' -- --reporter=verbose"
-        echo "  git diff"
-        exit 0
-    fi
-done
-
-echo ""
-echo "✅ No polluter found - all ${#TEST_FILES[@]} tests are clean"