mumucc 0.4.4 → 0.4.10

package/defaults/plugin-seed/marketplaces/claude-code-workflows/plugins/agent-teams/commands/team-review.md

@@ -0,0 +1,78 @@
+---
+description: "Launch a multi-reviewer parallel code review with specialized review dimensions"
+argument-hint: "<target> [--reviewers security,performance,architecture,testing,accessibility] [--base-branch main]"
+---
+
+# Team Review
+
+Orchestrate a multi-reviewer parallel code review where each reviewer focuses on a specific quality dimension. Produces a consolidated, deduplicated report organized by severity.
+
+## Pre-flight Checks
+
+1. Verify `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` is set
+2. Parse `$ARGUMENTS`:
+   - `<target>`: file path, directory, git diff range (e.g., `main...HEAD`), or PR number (e.g., `#123`)
+   - `--reviewers`: comma-separated dimensions (default: `security,performance,architecture`)
+   - `--base-branch`: base branch for diff comparison (default: `main`)
+
+## Phase 1: Target Resolution
+
+1. Determine target type:
+   - **File/Directory**: Use as-is for review scope
+   - **Git diff range**: Use Bash to run `git diff {range} --name-only` to get changed files
+   - **PR number**: Use Bash to run `gh pr diff {number} --name-only` to get changed files
+2. Collect the full diff content for distribution to reviewers
+3. Display review scope to user: "{N} files to review across {M} dimensions"
+
+## Phase 2: Team Spawn
+
+1. Use `TeamCreate` tool to create the team with `team_name: "review-{timestamp}"` and `description`
+2. For each requested dimension, use `Agent` tool to spawn a teammate:
+   - `name`: `{dimension}-reviewer` (e.g., "security-reviewer")
+   - `subagent_type`: "agent-teams:team-reviewer"
+   - `prompt`: Include the dimension assignment, target files, and diff content
+3. Use `TaskCreate` for each reviewer's task:
+   - Subject: "Review {target} for {dimension} issues"
+   - Description: Include file list, diff content, and dimension-specific checklist
+
+## Phase 3: Monitor and Collect
+
+1. Wait for all review tasks to complete (check `TaskList` periodically)
+2. As each reviewer completes, collect their structured findings
+3. Track progress: "{completed}/{total} reviews complete"
+
+## Phase 4: Consolidation
+
+1. **Deduplicate**: Merge findings that reference the same file:line location
+2. **Resolve conflicts**: If reviewers disagree on severity, use the higher rating
+3. **Organize by severity**: Group findings as Critical, High, Medium, Low
+4. **Cross-reference**: Note findings that appear in multiple dimensions
+
+## Phase 5: Report and Cleanup
+
+1. Present consolidated report:
+
+   ```
+   ## Code Review Report: {target}
+
+   Reviewed by: {dimensions}
+   Files reviewed: {count}
+
+   ### Critical ({count})
+   [findings...]
+
+   ### High ({count})
+   [findings...]
+
+   ### Medium ({count})
+   [findings...]
+
+   ### Low ({count})
+   [findings...]
+
+   ### Summary
+   Total findings: {count} (Critical: N, High: N, Medium: N, Low: N)
+   ```
+
+2. Send `shutdown_request` to all reviewers
+3. Call `TeamDelete` to remove team resources

package/defaults/plugin-seed/marketplaces/claude-code-workflows/plugins/agent-teams/commands/team-shutdown.md

@@ -0,0 +1,50 @@
+---
+description: "Gracefully shut down an agent team, collect final results, and clean up resources"
+argument-hint: "[team-name] [--force] [--keep-tasks]"
+---
+
+# Team Shutdown
+
+Gracefully shut down an active agent team by sending shutdown requests to all teammates, collecting final results, and cleaning up team resources.
+
+## Phase 1: Pre-Shutdown
+
+1. Parse `$ARGUMENTS` for team name and flags:
+   - If no team name, check for active teams (same discovery as team-status)
+   - `--force`: skip waiting for graceful shutdown responses
+   - `--keep-tasks`: preserve task list after cleanup
+
+2. Read team config from `~/.claude/teams/{team-name}/config.json` using the Read tool
+3. Call `TaskList` to check for in-progress tasks
+
+4. If there are in-progress tasks and `--force` is not set:
+   - Display warning: "Warning: {N} tasks are still in progress"
+   - List the in-progress tasks
+   - Ask user: "Proceed with shutdown? In-progress work may be lost."
+
+## Phase 2: Graceful Shutdown
+
+For each teammate in the team:
+
+1. Use `SendMessage` with `type: "shutdown_request"` to request graceful shutdown
+   - Include content: "Team shutdown requested. Please finish current work and save state."
+2. Wait for shutdown responses
+   - If teammate approves: mark as shut down
+   - If teammate rejects: report to user with reason
+   - If `--force`: don't wait for responses
+
+## Phase 3: Cleanup
+
+1. Display shutdown summary:
+
+   ```
+   Team "{team-name}" shutdown complete.
+
+   Members shut down: {N}/{total}
+   Tasks completed: {completed}/{total}
+   Tasks remaining: {remaining}
+   ```
+
+2. Unless `--keep-tasks` is set, call `TeamDelete` to remove team and task directories
+
+3. If `--keep-tasks` is set, inform user: "Task list preserved at ~/.claude/tasks/{team-name}/"

package/defaults/plugin-seed/marketplaces/claude-code-workflows/plugins/agent-teams/commands/team-spawn.md

@@ -0,0 +1,105 @@
+---
+description: "Spawn an agent team using presets (review, debug, feature, fullstack, research, security, migration) or custom composition"
+argument-hint: "<preset|custom> [--name team-name] [--members N] [--delegate]"
+---
+
+# Team Spawn
+
+Spawn a multi-agent team using preset configurations or custom composition. Handles team creation, teammate spawning, and initial task setup.
+
+## Pre-flight Checks
+
+1. Verify that `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` is set:
+   - If not set, inform the user: "Agent Teams requires the experimental feature flag. Set `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` in your environment."
+   - Stop execution if not enabled
+
+2. Parse arguments from `$ARGUMENTS`:
+   - First positional arg: preset name or "custom"
+   - `--name`: team name (default: auto-generated from preset)
+   - `--members N`: override default member count
+   - `--delegate`: enter delegation mode after spawning
+
+## Phase 1: Team Configuration
+
+### Preset Teams
+
+If a preset is specified, use these configurations:
+
+**`review`** — Multi-dimensional code review (default: 3 members)
+
+- Spawn 3 `team-reviewer` agents with dimensions: security, performance, architecture
+- Team name default: `review-team`
+
+**`debug`** — Competing hypotheses debugging (default: 3 members)
+
+- Spawn 3 `team-debugger` agents, each assigned a different hypothesis
+- Team name default: `debug-team`
+
+**`feature`** — Parallel feature development (default: 3 members)
+
+- Spawn 1 `team-lead` agent + 2 `team-implementer` agents
+- Team name default: `feature-team`
+
+**`fullstack`** — Full-stack development (default: 4 members)
+
+- Spawn 1 `team-implementer` (frontend), 1 `team-implementer` (backend), 1 `team-implementer` (tests), 1 `team-lead`
+- Team name default: `fullstack-team`
+
+**`research`** — Parallel codebase, web, and documentation research (default: 3 members)
+
+- Spawn 3 `general-purpose` agents, each assigned a different research question or area
+- Agents have access to codebase search (Grep, Glob, Read) and web search (WebSearch, WebFetch)
+- Team name default: `research-team`
+
+**`security`** — Comprehensive security audit (default: 4 members)
+
+- Spawn 1 `team-reviewer` (OWASP/vulnerabilities), 1 `team-reviewer` (auth/access control), 1 `team-reviewer` (dependencies/supply chain), 1 `team-reviewer` (secrets/configuration)
+- Team name default: `security-team`
+
+**`migration`** — Codebase migration or large refactor (default: 4 members)
+
+- Spawn 1 `team-lead` (coordination + migration plan), 2 `team-implementer` (parallel migration streams), 1 `team-reviewer` (verify migration correctness)
+- Team name default: `migration-team`
+
+### Custom Composition
+
+If "custom" is specified:
+
+1. Use AskUserQuestion to prompt for team size (2-5 members)
+2. For each member, ask for role selection: team-lead, team-reviewer, team-debugger, team-implementer
+3. Ask for team name if not provided via `--name`
+
+## Phase 2: Team Creation
+
+1. Use the `TeamCreate` tool to create the team with `team_name` and `description`
+2. For each team member, use the `Agent` tool with:
+   - `team_name`: the team name
+   - `name`: descriptive member name (e.g., "security-reviewer", "hypothesis-1")
+   - `subagent_type`: "general-purpose" (teammates need full tool access)
+   - `prompt`: Role-specific instructions referencing the appropriate agent definition
+
+## Phase 3: Initial Setup
+
+1. Use `TaskCreate` to create initial placeholder tasks for each teammate
+2. Display team summary:
+   - Team name
+   - Member names and roles
+   - Display mode (tmux/iTerm2/in-process)
+3. If `--delegate` flag is set, transition to delegation mode
+
+## Output
+
+Display a formatted team summary:
+
+```
+Team "{team-name}" spawned successfully!
+
+Members:
+  - {member-1-name} ({role})
+  - {member-2-name} ({role})
+  - {member-3-name} ({role})
+
+Use /team-status to monitor progress
+Use /team-delegate to assign tasks
+Use /team-shutdown to clean up
+```

package/defaults/plugin-seed/marketplaces/claude-code-workflows/plugins/agent-teams/commands/team-status.md

@@ -0,0 +1,60 @@
+---
+description: "Display team members, task status, and progress for an active agent team"
+argument-hint: "[team-name] [--tasks] [--members] [--json]"
+---
+
+# Team Status
+
+Display the current state of an active agent team including members, tasks, and progress.
+
+## Phase 1: Team Discovery
+
+1. Parse `$ARGUMENTS` for team name and flags:
+   - If team name provided, use it directly
+   - If no team name, check `~/.claude/teams/` for active teams
+   - If multiple teams exist and no name specified, list all teams and ask user to choose
+   - `--tasks`: show only task details
+   - `--members`: show only member details
+   - `--json`: output raw JSON instead of formatted table
+
+2. Read team config from `~/.claude/teams/{team-name}/config.json` using the Read tool
+3. Call `TaskList` to get current task state
+
+## Phase 2: Status Display
+
+### Members Table
+
+Display each team member with their current state:
+
+```
+Team: {team-name}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Members:
+  Name              Role              Status
+  ─────────────────────────────────────────
+  security-rev      team-reviewer     working on task #2
+  perf-rev          team-reviewer     idle
+  arch-rev          team-reviewer     working on task #4
+```
+
+### Tasks Table
+
+Display tasks with status, assignee, and dependencies:
+
+```
+Tasks:
+  ID   Status        Owner           Subject
+  ─────────────────────────────────────────────────
+  #1   completed     security-rev    Review auth module
+  #2   in_progress   security-rev    Review API endpoints
+  #3   completed     perf-rev        Profile database queries
+  #4   in_progress   arch-rev        Analyze module structure
+  #5   pending       (unassigned)    Consolidate findings
+
+Progress: 40% (2/5 completed)
+```
+
+### JSON Output
+
+If `--json` flag is set, output the raw team config and task list as JSON.

package/defaults/plugin-seed/marketplaces/claude-code-workflows/plugins/agent-teams/skills/multi-reviewer-patterns/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: multi-reviewer-patterns
+description: Coordinate parallel code reviews across multiple quality dimensions with finding deduplication, severity calibration, and consolidated reporting. Use this skill when organizing multi-reviewer code reviews, calibrating finding severity, or consolidating review results.
+version: 1.0.2
+---
+
+# Multi-Reviewer Patterns
+
+Patterns for coordinating parallel code reviews across multiple quality dimensions, deduplicating findings, calibrating severity, and producing consolidated reports.
+
+## When to Use This Skill
+
+- Organizing a multi-dimensional code review
+- Deciding which review dimensions to assign
+- Deduplicating findings from multiple reviewers
+- Calibrating severity ratings consistently
+- Producing a consolidated review report
+
+## Review Dimension Allocation
+
+### Available Dimensions
+
+| Dimension         | Focus                                   | When to Include                             |
+| ----------------- | --------------------------------------- | ------------------------------------------- |
+| **Security**      | Vulnerabilities, auth, input validation | Always for code handling user input or auth |
+| **Performance**   | Query efficiency, memory, caching       | When changing data access or hot paths      |
+| **Architecture**  | SOLID, coupling, patterns               | For structural changes or new modules       |
+| **Testing**       | Coverage, quality, edge cases           | When adding new functionality               |
+| **Accessibility** | WCAG, ARIA, keyboard nav                | For UI/frontend changes                     |
+
+### Recommended Combinations
+
+| Scenario               | Dimensions                                   |
+| ---------------------- | -------------------------------------------- |
+| API endpoint changes   | Security, Performance, Architecture          |
+| Frontend component     | Architecture, Testing, Accessibility         |
+| Database migration     | Performance, Architecture                    |
+| Authentication changes | Security, Testing                            |
+| Full feature review    | Security, Performance, Architecture, Testing |
+
+## Finding Deduplication
+
+When multiple reviewers report issues at the same location:
+
+### Merge Rules
+
+1. **Same file:line, same issue** — Merge into one finding, credit all reviewers
+2. **Same file:line, different issues** — Keep as separate findings
+3. **Same issue, different locations** — Keep separate but cross-reference
+4. **Conflicting severity** — Use the higher severity rating
+5. **Conflicting recommendations** — Include both with reviewer attribution
+
+### Deduplication Process
+
+```
+For each finding in all reviewer reports:
+  1. Check if another finding references the same file:line
+  2. If yes, check if they describe the same issue
+  3. If same issue: merge, keeping the more detailed description
+  4. If different issue: keep both, tag as "co-located"
+  5. Use highest severity among merged findings
+```
+
+## Severity Calibration
+
+### Severity Criteria
+
+| Severity     | Impact                                        | Likelihood             | Examples                                     |
+| ------------ | --------------------------------------------- | ---------------------- | -------------------------------------------- |
+| **Critical** | Data loss, security breach, complete failure  | Certain or very likely | SQL injection, auth bypass, data corruption  |
+| **High**     | Significant functionality impact, degradation | Likely                 | Memory leak, missing validation, broken flow |
+| **Medium**   | Partial impact, workaround exists             | Possible               | N+1 query, missing edge case, unclear error  |
+| **Low**      | Minimal impact, cosmetic                      | Unlikely               | Style issue, minor optimization, naming      |
+
+### Calibration Rules
+
+- Security vulnerabilities exploitable by external users: always Critical or High
+- Performance issues in hot paths: at least Medium
+- Missing tests for critical paths: at least Medium
+- Accessibility violations for core functionality: at least Medium
+- Code style issues with no functional impact: Low
+
+## Consolidated Report Template
+
+```markdown
+## Code Review Report
+
+**Target**: {files/PR/directory}
+**Reviewers**: {dimension-1}, {dimension-2}, {dimension-3}
+**Date**: {date}
+**Files Reviewed**: {count}
+
+### Critical Findings ({count})
+
+#### [CR-001] {Title}
+
+**Location**: `{file}:{line}`
+**Dimension**: {Security/Performance/etc.}
+**Description**: {what was found}
+**Impact**: {what could happen}
+**Fix**: {recommended remediation}
+
+### High Findings ({count})
+
+...
+
+### Medium Findings ({count})
+
+...
+
+### Low Findings ({count})
+
+...
+
+### Summary
+
+| Dimension    | Critical | High  | Medium | Low   | Total  |
+| ------------ | -------- | ----- | ------ | ----- | ------ |
+| Security     | 1        | 2     | 3      | 0     | 6      |
+| Performance  | 0        | 1     | 4      | 2     | 7      |
+| Architecture | 0        | 0     | 2      | 3     | 5      |
+| **Total**    | **1**    | **3** | **9**  | **5** | **18** |
+
+### Recommendation
+
+{Overall assessment and prioritized action items}
+```

package/defaults/plugin-seed/marketplaces/claude-code-workflows/plugins/agent-teams/skills/multi-reviewer-patterns/references/review-dimensions.md

@@ -0,0 +1,127 @@
+# Review Dimension Checklists
+
+Detailed checklists for each review dimension that reviewers follow during parallel code review.
+
+## Security Review Checklist
+
+### Input Handling
+
+- [ ] All user inputs are validated and sanitized
+- [ ] SQL queries use parameterized statements (no string concatenation)
+- [ ] HTML output is properly escaped to prevent XSS
+- [ ] File paths are validated to prevent path traversal
+- [ ] Request size limits are enforced
+
+### Authentication & Authorization
+
+- [ ] Authentication is required for all protected endpoints
+- [ ] Authorization checks verify user has permission for the action
+- [ ] JWT tokens are validated (signature, expiry, issuer)
+- [ ] Password hashing uses bcrypt/argon2 (not MD5/SHA)
+- [ ] Session management follows best practices
+
+### Secrets & Configuration
+
+- [ ] No hardcoded secrets, API keys, or passwords
+- [ ] Secrets are loaded from environment variables or secret manager
+- [ ] .gitignore includes sensitive file patterns
+- [ ] Debug/development endpoints are disabled in production
+
+### Dependencies
+
+- [ ] No known CVEs in direct dependencies
+- [ ] Dependencies are pinned to specific versions
+- [ ] No unnecessary dependencies that increase attack surface
+
+## Performance Review Checklist
+
+### Database
+
+- [ ] No N+1 query patterns
+- [ ] Queries use appropriate indexes
+- [ ] No SELECT \* on large tables
+- [ ] Pagination is implemented for list endpoints
+- [ ] Connection pooling is configured
+
+### Memory & Resources
+
+- [ ] No memory leaks (event listeners cleaned up, streams closed)
+- [ ] Large data sets are streamed, not loaded entirely into memory
+- [ ] File handles and connections are properly closed
+- [ ] Caching is used for expensive operations
+
+### Computation
+
+- [ ] No unnecessary re-computation or redundant operations
+- [ ] Appropriate algorithm complexity for the data size
+- [ ] Async operations used where I/O bound
+- [ ] No blocking operations on the main thread
+
+## Architecture Review Checklist
+
+### Design Principles
+
+- [ ] Single Responsibility: each module/class has one reason to change
+- [ ] Open/Closed: extensible without modification
+- [ ] Dependency Inversion: depends on abstractions, not concretions
+- [ ] No circular dependencies between modules
+
+### Structure
+
+- [ ] Clear separation of concerns (UI, business logic, data)
+- [ ] Consistent error handling strategy across the codebase
+- [ ] Configuration is externalized, not hardcoded
+- [ ] API contracts are well-defined and versioned
+
+### Patterns
+
+- [ ] Consistent patterns used throughout (no pattern mixing)
+- [ ] Abstractions are at the right level (not over/under-engineered)
+- [ ] Module boundaries align with domain boundaries
+- [ ] Shared utilities are actually shared (no duplication)
+
+## Testing Review Checklist
+
+### Coverage
+
+- [ ] Critical paths have test coverage
+- [ ] Edge cases are tested (empty input, null, boundary values)
+- [ ] Error paths are tested (what happens when things fail)
+- [ ] Integration points have integration tests
+
+### Quality
+
+- [ ] Tests are deterministic (no flaky tests)
+- [ ] Tests are isolated (no shared state between tests)
+- [ ] Assertions are specific (not just "no error thrown")
+- [ ] Test names clearly describe what is being tested
+
+### Maintainability
+
+- [ ] Tests don't duplicate implementation logic
+- [ ] Mocks/stubs are minimal and accurate
+- [ ] Test data is clear and relevant
+- [ ] Tests are easy to understand without reading the implementation
+
+## Accessibility Review Checklist
+
+### Structure
+
+- [ ] Semantic HTML elements used (nav, main, article, button)
+- [ ] Heading hierarchy is logical (h1 → h2 → h3)
+- [ ] ARIA roles and properties used correctly
+- [ ] Landmarks identify page regions
+
+### Interaction
+
+- [ ] All functionality accessible via keyboard
+- [ ] Focus order is logical and visible
+- [ ] No keyboard traps
+- [ ] Touch targets are at least 44x44px
+
+### Content
+
+- [ ] Images have meaningful alt text
+- [ ] Color is not the only means of conveying information
+- [ ] Text has sufficient contrast ratio (4.5:1 for normal, 3:1 for large)
+- [ ] Content is readable at 200% zoom

package/defaults/plugin-seed/marketplaces/claude-code-workflows/plugins/agent-teams/skills/parallel-debugging/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: parallel-debugging
+description: Debug complex issues using competing hypotheses with parallel investigation, evidence collection, and root cause arbitration. Use this skill when debugging bugs with multiple potential causes, performing root cause analysis, or organizing parallel investigation workflows.
+version: 1.0.2
+---
+
+# Parallel Debugging
+
+Framework for debugging complex issues using the Analysis of Competing Hypotheses (ACH) methodology with parallel agent investigation.
+
+## When to Use This Skill
+
+- Bug has multiple plausible root causes
+- Initial debugging attempts haven't identified the issue
+- Issue spans multiple modules or components
+- Need systematic root cause analysis with evidence
+- Want to avoid confirmation bias in debugging
+
+## Hypothesis Generation Framework
+
+Generate hypotheses across 6 failure mode categories:
+
+### 1. Logic Error
+
+- Incorrect conditional logic (wrong operator, missing case)
+- Off-by-one errors in loops or array access
+- Missing edge case handling
+- Incorrect algorithm implementation
+
+### 2. Data Issue
+
+- Invalid or unexpected input data
+- Type mismatch or coercion error
+- Null/undefined/None where value expected
+- Encoding or serialization problem
+- Data truncation or overflow
+
+### 3. State Problem
+
+- Race condition between concurrent operations
+- Stale cache returning outdated data
+- Incorrect initialization or default values
+- Unintended mutation of shared state
+- State machine transition error
+
+### 4. Integration Failure
+
+- API contract violation (request/response mismatch)
+- Version incompatibility between components
+- Configuration mismatch between environments
+- Missing or incorrect environment variables
+- Network timeout or connection failure
+
+### 5. Resource Issue
+
+- Memory leak causing gradual degradation
+- Connection pool exhaustion
+- File descriptor or handle leak
+- Disk space or quota exceeded
+- CPU saturation from inefficient processing
+
+### 6. Environment
+
+- Missing runtime dependency
+- Wrong library or framework version
+- Platform-specific behavior difference
+- Permission or access control issue
+- Timezone or locale-related behavior
+
+## Evidence Collection Standards
+
+### What Constitutes Evidence
+
+| Evidence Type     | Strength | Example                                                         |
+| ----------------- | -------- | --------------------------------------------------------------- |
+| **Direct**        | Strong   | Code at `file.ts:42` shows `if (x > 0)` should be `if (x >= 0)` |
+| **Correlational** | Medium   | Error rate increased after commit `abc123`                      |
+| **Testimonial**   | Weak     | "It works on my machine"                                        |
+| **Absence**       | Variable | No null check found in the code path                            |
+
+### Citation Format
+
+Always cite evidence with file:line references:
+
+```
+**Evidence**: The validation function at `src/validators/user.ts:87`
+does not check for empty strings, only null/undefined. This allows
+empty email addresses to pass validation.
+```
+
+### Confidence Levels
+
+| Level               | Criteria                                                                            |
+| ------------------- | ----------------------------------------------------------------------------------- |
+| **High (>80%)**     | Multiple direct evidence pieces, clear causal chain, no contradicting evidence      |
+| **Medium (50-80%)** | Some direct evidence, plausible causal chain, minor ambiguities                     |
+| **Low (<50%)**      | Mostly correlational evidence, incomplete causal chain, some contradicting evidence |
+
+## Result Arbitration Protocol
+
+After all investigators report:
+
+### Step 1: Categorize Results
+
+- **Confirmed**: High confidence, strong evidence, clear causal chain
+- **Plausible**: Medium confidence, some evidence, reasonable causal chain
+- **Falsified**: Evidence contradicts the hypothesis
+- **Inconclusive**: Insufficient evidence to confirm or falsify
+
+### Step 2: Compare Confirmed Hypotheses
+
+If multiple hypotheses are confirmed, rank by:
+
+1. Confidence level
+2. Number of supporting evidence pieces
+3. Strength of causal chain
+4. Absence of contradicting evidence
+
+### Step 3: Determine Root Cause
+
+- If one hypothesis clearly dominates: declare as root cause
+- If multiple hypotheses are equally likely: may be compound issue (multiple contributing causes)
+- If no hypotheses confirmed: generate new hypotheses based on evidence gathered
+
+### Step 4: Validate Fix
+
+Before declaring the bug fixed:
+
+- [ ] Fix addresses the identified root cause
+- [ ] Fix doesn't introduce new issues
+- [ ] Original reproduction case no longer fails
+- [ ] Related edge cases are covered
+- [ ] Relevant tests are added or updated