@simplysm/sd-claude 13.0.78 → 13.0.81

package/claude/skills/sd-api-name-review/SKILL.md

@@ -1,154 +0,0 @@
----
-name: sd-api-name-review
-description: "Public API naming review (explicit invocation only)"
-model: sonnet
----
-
-# sd-api-name-review
-
-## Overview
-
-Compare a library/module's public API names against industry standards and review internal consistency, producing a standardization report. Uses **sd-explore** to extract the API surface, then dispatches research agents for industry comparison.
-
-**Analysis only — no code modifications.**
-
-## Principles
-
-- **Breaking changes are irrelevant**: Do NOT dismiss findings because renaming would cause a breaking change.
-- **Internal consistency first**: Internal naming consistency takes priority over external standards.
-
-## Usage
-
-- `/sd-api-name-review packages/solid` — full naming review
-- `/sd-api-name-review packages/orm-common` — review specific package
-- `/sd-api-name-review` — if no argument, ask the user for the target path
-
-## Target Selection
-
-- With argument: review source code at the given path
-- Without argument: ask the user for the target path
-
-**Important:** Review ALL source files under the target path. Do not use git status or git diff to limit scope.
-
-## Workflow
-
-### Step 1: Prepare Context
-
-Read these files:
-- `CLAUDE.md` — project overview
-- `.claude/rules/sd-refs-linker.md` — reference guide
-- Target's `package.json` — version (v12/v13)
-
-Based on version and target, read all applicable reference files (e.g., `sd-code-conventions.md`, `sd-solid.md`).
-
-Keep the collected conventions in memory — they will inform the analysis in later steps.
-
-### Step 2: API Extraction (via sd-explore)
-
-Follow the **sd-explore** workflow to extract the target's public API surface.
-
-**sd-explore input:**
-
-- **Target path**: the review target directory
-- **Name**: `api-name-review`
-- **File patterns**: `**/*.ts`, `**/*.tsx` (exclude `node_modules`, `dist`)
-- **Analysis instructions**:
-
-"For each file, extract its public API surface:
-- All exported identifiers (functions, classes, types, constants, etc.)
-- Names and types of user-facing parameters/options/config
-- Naming pattern classification (prefixes, suffixes, verb/adjective/noun usage, abbreviations, etc.)
-
-Output format:
-```
-# API Surface: [directory names]
-
-## Exports
-- `path/to/file.ts` — `exportName`: type (function/class/type/const), signature summary
-
-## Naming Patterns
-- Pattern: description (e.g., 'create-' prefix for factory functions)
-- Examples: list of identifiers using this pattern
-```
-"
-
-### Step 3: Industry Standard Research
-
-Based on Step 2 results:
-
-1. Identify **recurring naming patterns** from the extracted API
-2. Determine the target's domain and tech stack to **select comparable libraries**
-3. Dispatch **parallel agents** to web-search/fetch official docs for each comparable library, investigating naming conventions for the same pattern categories
-
-Each research agent receives:
-
-```
-Research naming conventions in [library name] for these pattern categories:
-[list of patterns from Step 2]
-
-For each pattern, document:
-- What naming convention the library uses
-- Specific examples from the API
-- Any documented rationale for the convention
-
-Write results to: .tmp/api-name-review/research-{library_name}.md
-```
-
-### Step 4: Comparative Analysis & Verification
-
-Cross-compare Step 2 (API surface) and Step 3 (industry research) results.
-
-Classify each naming pattern:
-
-| Priority | Criteria                                               |
-| -------- | ------------------------------------------------------ |
-| **P0**   | Misaligned with majority of surveyed libraries         |
-| **P1**   | Internal inconsistency (same concept, different names) |
-| **P2**   | Better industry term exists (optional)                 |
-| **Keep** | Already aligned with standards                         |
-
-**MANDATORY: Read actual code for EVERY finding.** For each finding, `Read` the file at the referenced location before finalizing. Do NOT rely on explore descriptions alone — verify against the actual code.
-
-Each finding includes: current name, recommended change, rationale (usage patterns per library).
-
-### Step 5: Report & User Confirmation
-
-Present **Keep** items to the user as a summary.
-
-Then present each **P0/P1/P2** finding to the user **one at a time**, ordered by priority (P0 → P1 → P2).
-
-For each finding, explain:
-1. **What the problem is** — the current name and why it's misaligned or inconsistent
-2. **How it could be fixed** — recommended name(s) with rationale from surveyed libraries
-3. **Ask**: address this or skip?
-
-Collect only findings the user confirms. If the user skips all findings, report that and end.
-
-### Step 6: Brainstorm Handoff
-
-Invoke **sd-brainstorm** with all user-confirmed findings as context:
-
-_
-"Design naming changes for the following review findings.
-
-**For each finding, you MUST:**
-1. Review it thoroughly — examine the code, understand the context, assess the real impact
-2. If any aspect is unclear or ambiguous, ask the user (one question at a time, per brainstorm rules)
-3. If a finding has low cost-benefit (adds complexity for marginal gain, pure style preference, scope too small), drop it. After triage, briefly list all dropped findings with one-line reasons (no user confirmation needed).
-4. For findings worth fixing, explore approaches and design solutions
-
-Findings that survive your triage become the design scope. Apply your normal brainstorm process (gap review → approaches → design presentation) to the surviving findings as a group.
-
-<include all confirmed findings with their priority, file:line, current name, recommended name, and rationale>"
-
-sd-brainstorm then owns the full cycle: triage (with user input as needed) → design.
-
-## Common Mistakes
-
-| Mistake | Fix |
-|---------|-----|
-| Using git diff to limit scope | Review ALL source files under target |
-| Skipping context preparation | Always read conventions and refs before analysis |
-| Skipping verification | Always verify findings against actual code |
-| Dismissing findings due to breaking changes | Breaking changes are irrelevant — report the naming issue |
-| Not writing research results to files | Research agents MUST write to disk — prevents context bloat |

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