@tea-agent/loop-agent 0.1.0 → 0.2.1

package/skills/systematic-debugging/CREATION-LOG.md

@@ -1,76 +1,76 @@
 # Creation Log: Systematic Debugging Skill
 
-Reference example of extracting, structuring, and bulletproofing a critical skill.
+提取、结构化与 bulletproofing 关键 skill 的 reference example。
 
 ## Source Material
 
-Extracted debugging framework from `~/.claude/CLAUDE.md`:
-- 4-phase systematic process (Investigation → Pattern Analysis → Hypothesis → Implementation)
-- Core mandate: ALWAYS find root cause, NEVER fix symptoms
-- Rules designed to resist time pressure and rationalization
+从 `~/.claude/CLAUDE.md` 提取 debugging framework：
+- 4-phase systematic process（Investigation → Pattern Analysis → Hypothesis → Implementation）
+- Core mandate：ALWAYS find root cause，NEVER fix symptoms
+- 设计以 resist time pressure 与 rationalization 的规则
 
 ## Extraction Decisions
 
 **What to include:**
-- Complete 4-phase framework with all rules
-- Anti-shortcuts ("NEVER fix symptom", "STOP and re-analyze")
-- Pressure-resistant language ("even if faster", "even if I seem in a hurry")
-- Concrete steps for each phase
+- 完整 4-phase framework 及所有 rules
+- Anti-shortcuts（"NEVER fix symptom"、"STOP and re-analyze"）
+- Pressure-resistant language（"even if faster"、"even if I seem in a hurry"）
+- 各 phase 的 concrete steps
 
 **What to leave out:**
 - Project-specific context
-- Repetitive variations of same rule
-- Narrative explanations (condensed to principles)
+- 同一 rule 的 repetitive variations
+- Narrative explanations（condensed 为 principles）
 
 ## Structure Following skill-creation/SKILL.md
 
-1. **Rich when_to_use** - Included symptoms and anti-patterns
-2. **Type: technique** - Concrete process with steps
-3. **Keywords** - "root cause", "symptom", "workaround", "debugging", "investigation"
-4. **Flowchart** - Decision point for "fix failed" → re-analyze vs add more fixes
-5. **Phase-by-phase breakdown** - Scannable checklist format
-6. **Anti-patterns section** - What NOT to do (critical for this skill)
+1. **Rich when_to_use** — 含 symptoms 与 anti-patterns
+2. **Type: technique** — 带 steps 的 concrete process
+3. **Keywords** — "root cause"、"symptom"、"workaround"、"debugging"、"investigation"
+4. **Flowchart** — "fix failed" 决策点 → re-analyze vs add more fixes
+5. **Phase-by-phase breakdown** — Scannable checklist format
+6. **Anti-patterns section** — 什么 NOT to do（对本 skill 关键）
 
 ## Bulletproofing Elements
 
-Framework designed to resist rationalization under pressure:
+Framework 设计以 resist rationalization under pressure：
 
 ### Language Choices
-- "ALWAYS" / "NEVER" (not "should" / "try to")
+- "ALWAYS" / "NEVER"（非 "should" / "try to"）
 - "even if faster" / "even if I seem in a hurry"
-- "STOP and re-analyze" (explicit pause)
-- "Don't skip past" (catches the actual behavior)
+- "STOP and re-analyze"（explicit pause）
+- "Don't skip past"（捕获 actual behavior）
 
 ### Structural Defenses
-- **Phase 1 required** - Can't skip to implementation
-- **Single hypothesis rule** - Forces thinking, prevents shotgun fixes
-- **Explicit failure mode** - "IF your first fix doesn't work" with mandatory action
-- **Anti-patterns section** - Shows exactly what shortcuts look like
+- **Phase 1 required** — 不能 skip to implementation
+- **Single hypothesis rule** — 强制思考，防止 shotgun fixes
+- **Explicit failure mode** — "IF your first fix doesn't work" 及 mandatory action
+- **Anti-patterns section** — 展示 shortcuts 的确切样子
 
 ### Redundancy
-- Root cause mandate in overview + when_to_use + Phase 1 + implementation rules
-- "NEVER fix symptom" appears 4 times in different contexts
-- Each phase has explicit "don't skip" guidance
+- Root cause mandate 在 overview + when_to_use + Phase 1 + implementation rules
+- "NEVER fix symptom" 在不同 contexts 出现 4 次
+- 各 phase 有 explicit "don't skip" guidance
 
 ## Testing Approach
 
-Created 4 validation tests following skills/meta/testing-skills-with-subagents:
+按 skills/meta/testing-skills-with-subagents 创建 4 个 validation tests：
 
 ### Test 1: Academic Context (No Pressure)
-- Simple bug, no time pressure
-- **Result:** Perfect compliance, complete investigation
+- Simple bug，无 time pressure
+- **Result:** Perfect compliance，complete investigation
 
 ### Test 2: Time Pressure + Obvious Quick Fix
-- User "in a hurry", symptom fix looks easy
-- **Result:** Resisted shortcut, followed full process, found real root cause
+- User "in a hurry"，symptom fix 看起来 easy
+- **Result:** Resisted shortcut，followed full process，found real root cause
 
 ### Test 3: Complex System + Uncertainty
-- Multi-layer failure, unclear if can find root cause
-- **Result:** Systematic investigation, traced through all layers, found source
+- Multi-layer failure， unclear 能否 find root cause
+- **Result:** Systematic investigation，traced through all layers，found source
 
 ### Test 4: Failed First Fix
-- Hypothesis doesn't work, temptation to add more fixes
-- **Result:** Stopped, re-analyzed, formed new hypothesis (no shotgun)
+- Hypothesis 无效，temptation 加 more fixes
+- **Result:** Stopped，re-analyzed，formed new hypothesis（no shotgun）
 
 **All tests passed.** No rationalizations found.
 
@@ -99,16 +99,16 @@ Bulletproof skill that:
 
 ## Key Insight
 
-**Most important bulletproofing:** Anti-patterns section showing exact shortcuts that feel justified in the moment. When Claude thinks "I'll just add this one quick fix", seeing that exact pattern listed as wrong creates cognitive friction.
+**Most important bulletproofing：** Anti-patterns section 展示 moment 里 feel justified 的 exact shortcuts。当 Claude 想 "I'll just add this one quick fix"，看到 listed as wrong 的 exact pattern 产生 cognitive friction。
 
 ## Usage Example
 
-When encountering a bug:
+遇到 bug 时：
 1. Load skill: skills/debugging/systematic-debugging
-2. Read overview (10 sec) - reminded of mandate
-3. Follow Phase 1 checklist - forced investigation
-4. If tempted to skip - see anti-pattern, stop
-5. Complete all phases - root cause found
+2. Read overview (10 sec) — reminded of mandate
+3. Follow Phase 1 checklist — forced investigation
+4. If tempted to skip — see anti-pattern，stop
+5. Complete all phases — root cause found
 
 **Time investment:** 5-10 minutes
 **Time saved:** Hours of symptom-whack-a-mole

package/skills/systematic-debugging/SKILL.md

@@ -1,17 +1,17 @@
 ---
 name: systematic-debugging
-description: Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
+description: 遇到任何 bug、test failure 或 unexpected behavior 时使用，且在提出 fixes 之前
 ---
 
 # Systematic Debugging
 
 ## Overview
 
-Random fixes waste time and create new bugs. Quick patches mask underlying issues.
+Random fixes 浪费时间并制造新 bug。Quick patches 掩盖 underlying issues。
 
-**Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure.
+**Core principle：** ALWAYS 在尝试 fixes 之前找到 root cause。Symptom fixes 是 failure。
 
-**Violating the letter of this process is violating the spirit of debugging.**
+**违反本流程字面即违反 debugging 精神。**
 
 ## The Iron Law
 
@@ -19,61 +19,61 @@ Random fixes waste time and create new bugs. Quick patches mask underlying issue
 NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
 ```
 
-If you haven't completed Phase 1, you cannot propose fixes.
+若尚未完成 Phase 1，不得提出 fixes。
 
 ## When to Use
 
-Use for ANY technical issue:
+用于 ANY technical issue：
 - Test failures
-- Bugs in production
+- Production bugs
 - Unexpected behavior
 - Performance problems
 - Build failures
 - Integration issues
 
-**Use this ESPECIALLY when:**
-- Under time pressure (emergencies make guessing tempting)
-- "Just one quick fix" seems obvious
-- You've already tried multiple fixes
-- Previous fix didn't work
-- You don't fully understand the issue
+**ESPECIALLY 在以下情况使用：**
+- 时间压力下（emergencies 使 guessing 诱人）
+- "Just one quick fix" 看起来 obvious
+- 已尝试 multiple fixes
+- Previous fix 无效
+- 未完全理解 issue
 
-**Don't skip when:**
-- Issue seems simple (simple bugs have root causes too)
-- You're in a hurry (rushing guarantees rework)
-- Manager wants it fixed NOW (systematic is faster than thrashing)
+**Don't skip when：**
+- Issue 看起来 simple（simple bugs 也有 root causes）
+- 赶时间（rushing 保证 rework）
+- Manager 要求 NOW 修好（systematic 比 thrashing 更快）
 
 ## The Four Phases
 
-You MUST complete each phase before proceeding to the next.
+进入下一阶段前 MUST 完成每一 phase。
 
 ### Phase 1: Root Cause Investigation
 
-**BEFORE attempting ANY fix:**
+**在尝试 ANY fix 之前：**
 
 1. **Read Error Messages Carefully**
-   - Don't skip past errors or warnings
-   - They often contain the exact solution
-   - Read stack traces completely
-   - Note line numbers, file paths, error codes
+   - 不要跳过 errors 或 warnings
+   - 它们常含 exact solution
+   - 完整阅读 stack traces
+   - 记下 line numbers、file paths、error codes
 
 2. **Reproduce Consistently**
-   - Can you trigger it reliably?
-   - What are the exact steps?
-   - Does it happen every time?
-   - If not reproducible → gather more data, don't guess
+   - 能否可靠触发？
+   - Exact steps 是什么？
+   - 是否每次都发生？
+   - 若不可 reproduce → 收集更多 data，不要 guess
 
 3. **Check Recent Changes**
-   - What changed that could cause this?
-   - Git diff, recent commits
-   - New dependencies, config changes
+   - 什么变更可能导致此问题？
+   - Git diff、recent commits
+   - New dependencies、config changes
    - Environmental differences
 
 4. **Gather Evidence in Multi-Component Systems**
 
-   **WHEN system has multiple components (CI → build → signing, API → service → database):**
+   **WHEN system 有多个 components（CI → build → signing，API → service → database）：**
 
-   **BEFORE proposing fixes, add diagnostic instrumentation:**
+   **BEFORE proposing fixes，添加 diagnostic instrumentation：**
    ```
    For EACH component boundary:
      - Log what data enters component
@@ -109,112 +109,112 @@ You MUST complete each phase before proceeding to the next.
 
 5. **Trace Data Flow**
 
-   **WHEN error is deep in call stack:**
+   **WHEN error 在 call stack 深处：**
 
-   See `root-cause-tracing.md` in this directory for the complete backward tracing technique.
+   完整 backward tracing 见本目录 `root-cause-tracing.md`。
 
-   **Quick version:**
-   - Where does bad value originate?
-   - What called this with bad value?
-   - Keep tracing up until you find the source
-   - Fix at source, not at symptom
+   **Quick version：**
+   - Bad value 从哪 originate？
+   - 谁用 bad value 调用了 this？
+   - 一直向上 trace 直到 source
+   - 在 source 修复，而非 symptom
 
 ### Phase 2: Pattern Analysis
 
-**Find the pattern before fixing:**
+**Fix 前先找 pattern：**
 
 1. **Find Working Examples**
-   - Locate similar working code in same codebase
-   - What works that's similar to what's broken?
+   - 在同 codebase 找 similar working code
+   - 什么能 work、什么 broken？
 
 2. **Compare Against References**
-   - If implementing pattern, read reference implementation COMPLETELY
-   - Don't skim - read every line
-   - Understand the pattern fully before applying
+   - 若实现 pattern，COMPLETE 阅读 reference implementation
+   - 不要 skim — 读每一行
+   - 应用前 fully 理解 pattern
 
 3. **Identify Differences**
-   - What's different between working and broken?
-   - List every difference, however small
-   - Don't assume "that can't matter"
+   - Working 与 broken 有何不同？
+   - 列出 every difference，再小也要列
+   - 不要假设 "that can't matter"
 
 4. **Understand Dependencies**
-   - What other components does this need?
-   - What settings, config, environment?
-   - What assumptions does it make?
+   - 还需要哪些 other components？
+   - 哪些 settings、config、environment？
+   - 它作哪些 assumptions？
 
 ### Phase 3: Hypothesis and Testing
 
-**Scientific method:**
+**Scientific method：**
 
 1. **Form Single Hypothesis**
-   - State clearly: "I think X is the root cause because Y"
-   - Write it down
-   - Be specific, not vague
+   - 清楚陈述："I think X is the root cause because Y"
+   - 写下来
+   - 要 specific，不要 vague
 
 2. **Test Minimally**
-   - Make the SMALLEST possible change to test hypothesis
+   - 做 SMALLEST possible change 以 test hypothesis
    - One variable at a time
-   - Don't fix multiple things at once
+   - 不要一次 fix multiple things
 
 3. **Verify Before Continuing**
-   - Did it work? Yes → Phase 4
-   - Didn't work? Form NEW hypothesis
-   - DON'T add more fixes on top
+   - 有效？Yes → Phase 4
+   - 无效？Form NEW hypothesis
+   - DON'T 在其上叠加更多 fixes
 
 4. **When You Don't Know**
-   - Say "I don't understand X"
-   - Don't pretend to know
+   - 说 "I don't understand X"
+   - 不要假装知道
    - Ask for help
    - Research more
 
 ### Phase 4: Implementation
 
-**Fix the root cause, not the symptom:**
+**Fix root cause，不是 symptom：**
 
 1. **Create Failing Test Case**
    - Simplest possible reproduction
-   - Automated test if possible
-   - One-off test script if no framework
-   - MUST have before fixing
-   - Follow RED-GREEN-REFACTOR: write the failing test, watch it fail, then fix
+   - 可能的话用 automated test
+   - 无 framework 时用 one-off test script
+   - MUST 在 fix 之前有
+   - 遵循 RED-GREEN-REFACTOR：写 failing test，看它 fail，再 fix
 
 2. **Implement Single Fix**
-   - Address the root cause identified
+   - 针对已识别的 root cause
    - ONE change at a time
-   - No "while I'm here" improvements
-   - No bundled refactoring
+   - 无 "while I'm here" improvements
+   - 无 bundled refactoring
 
 3. **Verify Fix**
-   - Test passes now?
-   - No other tests broken?
-   - Issue actually resolved?
+   - Test 现在 pass？
+   - 无 other tests broken？
+   - Issue 真的 resolved？
 
 4. **If Fix Doesn't Work**
    - STOP
-   - Count: How many fixes have you tried?
-   - If < 3: Return to Phase 1, re-analyze with new information
-   - **If ≥ 3: STOP and question the architecture (step 5 below)**
-   - DON'T attempt Fix #4 without architectural discussion
+   - Count：已尝试多少 fixes？
+   - 若 < 3：Return to Phase 1，用 new information 再分析
+   - **若 ≥ 3：STOP 并质疑 architecture（见下方 step 5）**
+   - DON'T 在未做 architectural discussion 前尝试 Fix #4
 
 5. **If 3+ Fixes Failed: Question Architecture**
 
-   **Pattern indicating architectural problem:**
-   - Each fix reveals new shared state/coupling/problem in different place
-   - Fixes require "massive refactoring" to implement
-   - Each fix creates new symptoms elsewhere
+   **表明 architectural problem 的 pattern：**
+   - 每个 fix 在不同位置 reveal 新的 shared state/coupling/problem
+   - Fixes 需要 "massive refactoring" 才能实现
+   - 每个 fix 在其他地方制造新 symptoms
 
-   **STOP and question fundamentals:**
-   - Is this pattern fundamentally sound?
-   - Are we "sticking with it through sheer inertia"?
-   - Should we refactor architecture vs. continue fixing symptoms?
+   **STOP 并质疑 fundamentals：**
+   - 此 pattern fundamentally sound 吗？
+   - 是否 "sticking with it through sheer inertia"？
+   - 应 refactor architecture 还是继续 fix symptoms？
 
    **Discuss with your human partner before attempting more fixes**
 
-   This is NOT a failed hypothesis - this is a wrong architecture.
+   This is NOT a failed hypothesis — this is a wrong architecture.
 
 ## Red Flags - STOP and Follow Process
 
-If you catch yourself thinking:
+若发现自己想：
 - "Quick fix for now, investigate later"
 - "Just try changing X and see if it works"
 - "Add multiple changes, run tests"
@@ -234,11 +234,11 @@ If you catch yourself thinking:
 ## your human partner's Signals You're Doing It Wrong
 
 **Watch for these redirections:**
-- "Is that not happening?" - You assumed without verifying
-- "Will it show us...?" - You should have added evidence gathering
-- "Stop guessing" - You're proposing fixes without understanding
-- "Ultrathink this" - Question fundamentals, not just symptoms
-- "We're stuck?" (frustrated) - Your approach isn't working
+- "Is that not happening?" — You assumed without verifying
+- "Will it show us...?" — You should have added evidence gathering
+- "Stop guessing" — You're proposing fixes without understanding
+- "Ultrathink this" — Question fundamentals, not just symptoms
+- "We're stuck?" (frustrated) — Your approach isn't working
 
 **When you see these:** STOP. Return to Phase 1.
 
@@ -246,14 +246,14 @@ If you catch yourself thinking:
 
 | Excuse | Reality |
 |--------|---------|
-| "Issue is simple, don't need process" | Simple issues have root causes too. Process is fast for simple bugs. |
-| "Emergency, no time for process" | Systematic debugging is FASTER than guess-and-check thrashing. |
-| "Just try this first, then investigate" | First fix sets the pattern. Do it right from the start. |
-| "I'll write test after confirming fix works" | Untested fixes don't stick. Test first proves it. |
-| "Multiple fixes at once saves time" | Can't isolate what worked. Causes new bugs. |
-| "Reference too long, I'll adapt the pattern" | Partial understanding guarantees bugs. Read it completely. |
-| "I see the problem, let me fix it" | Seeing symptoms ≠ understanding root cause. |
-| "One more fix attempt" (after 2+ failures) | 3+ failures = architectural problem. Question pattern, don't fix again. |
+| "Issue is simple, don't need process" | Simple issues 也有 root causes。Process 对 simple bugs 很快。 |
+| "Emergency, no time for process" | Systematic debugging 比 guess-and-check thrashing 更快。 |
+| "Just try this first, then investigate" | First fix 定模式。从一开始就做对。 |
+| "I'll write test after confirming fix works" | Untested fixes 不 stick。Test first 证明它。 |
+| "Multiple fixes at once saves time" | 无法 isolate what worked。制造新 bugs。 |
+| "Reference too long, I'll adapt the pattern" | Partial understanding 保证 bugs。Complete 阅读。 |
+| "I see the problem, let me fix it" | Seeing symptoms ≠ understanding root cause。 |
+| "One more fix attempt" (after 2+ failures) | 3+ failures = architectural problem。质疑 pattern，不要再 fix。 |
 
 ## Quick Reference
 
@@ -266,31 +266,31 @@ If you catch yourself thinking:
 
 ## When Process Reveals "No Root Cause"
 
-If systematic investigation reveals issue is truly environmental, timing-dependent, or external:
+若 systematic investigation 表明 issue  truly environmental、timing-dependent 或 external：
 
 1. You've completed the process
 2. Document what you investigated
 3. Implement appropriate handling (retry, timeout, error message)
 4. Add monitoring/logging for future investigation
 
-**But:** 95% of "no root cause" cases are incomplete investigation.
+**But:** 95% 的 "no root cause" cases 是 incomplete investigation。
 
 ## Supporting Techniques
 
-These techniques are part of systematic debugging and available in this directory:
+本目录中属于 systematic debugging 的技术：
 
-- **`root-cause-tracing.md`** - Trace bugs backward through call stack to find original trigger
-- **`defense-in-depth.md`** - Add validation at multiple layers after finding root cause
-- **`condition-based-waiting.md`** - Replace arbitrary timeouts with condition polling
+- **`root-cause-tracing.md`** — Trace bugs backward through call stack 找 original trigger
+- **`defense-in-depth.md`** — 找到 root cause 后在 multiple layers 加 validation
+- **`condition-based-waiting.md`** — 用 condition polling 替代 arbitrary timeouts
 
 **Related principles:**
-- **RED-GREEN-REFACTOR** (see `docs/harness-methodology-tdd.md`) — For creating failing test case (Phase 4, Step 1)
-- **Verification discipline** — Verify fix worked before claiming success. Run the verification command, read the output, THEN claim the result.
+- **RED-GREEN-REFACTOR**（见 `docs/harness-methodology-tdd.md`）— 用于 creating failing test case（Phase 4, Step 1）
+- **Verification discipline** — 宣称 success 前 verify fix worked。Run verification command，读 output，THEN claim result。
 
 ## Real-World Impact
 
-From debugging sessions:
-- Systematic approach: 15-30 minutes to fix
-- Random fixes approach: 2-3 hours of thrashing
-- First-time fix rate: 95% vs 40%
-- New bugs introduced: Near zero vs common
+来自 debugging sessions：
+- Systematic approach：15-30 分钟 fix
+- Random fixes approach：2-3 小时 thrashing
+- First-time fix rate：95% vs 40%
+- New bugs introduced：Near zero vs common

package/skills/systematic-debugging/condition-based-waiting.md

@@ -2,9 +2,9 @@
 
 ## 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.
+Flaky tests 常用 arbitrary delays 猜 timing。这制造 race conditions：fast machines 上 pass，load 或 CI 下 fail。
 
-**Core principle:** Wait for the actual condition you care about, not a guess about how long it takes.
+**Core principle：** Wait for 你真正关心的 actual condition，不是猜需要多久。
 
 ## When to Use
 
@@ -21,15 +21,15 @@ digraph when_to_use {
 }
 ```
 
-**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
+**Use when：**
+- Tests 有 arbitrary delays（`setTimeout`、`sleep`、`time.sleep()`）
+- Tests flaky（有时 pass，load 下 fail）
+- Parallel 运行时 timeout
+- 等待 async operations 完成
 
-**Don't use when:**
-- Testing actual timing behavior (debounce, throttle intervals)
-- Always document WHY if using arbitrary timeout
+**Don't use when：**
+- 测试 actual timing behavior（debounce、throttle intervals）
+- 若用 arbitrary timeout，ALWAYS document WHY
 
 ## Core Pattern
 
@@ -79,18 +79,18 @@ async function waitFor<T>(
 }
 ```
 
-See `condition-based-waiting-example.ts` in this directory for complete implementation with domain-specific helpers (`waitForEvent`, `waitForEventCount`, `waitForEventMatch`) from actual debugging session.
+完整实现及 domain-specific helpers（`waitForEvent`、`waitForEventCount`、`waitForEventMatch`）见本目录 `condition-based-waiting-example.ts`，来自 actual debugging session。
 
 ## Common Mistakes
 
-**❌ Polling too fast:** `setTimeout(check, 1)` - wastes CPU
+**❌ Polling too fast:** `setTimeout(check, 1)` — wastes CPU
 **✅ Fix:** Poll every 10ms
 
-**❌ No timeout:** Loop forever if condition never met
+**❌ No timeout:** 条件永不满足则 loop forever
 **✅ Fix:** Always include timeout with clear error
 
-**❌ Stale data:** Cache state before loop
-**✅ Fix:** Call getter inside loop for fresh data
+**❌ Stale data:** Loop 前 cache state
+**✅ Fix:** Loop 内 call getter 取 fresh data
 
 ## When Arbitrary Timeout IS Correct
 
@@ -103,13 +103,13 @@ await new Promise(r => setTimeout(r, 200));   // Then: wait for timed behavior
 
 **Requirements:**
 1. First wait for triggering condition
-2. Based on known timing (not guessing)
+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
+来自 debugging session (2025-10-03)：
+- 修复 3 个文件中 15 个 flaky tests
+- Pass rate：60% → 100%
+- Execution time：40% faster
 - No more race conditions