hunting-bugs

You are hunting for bugs in a codebase by searching for known problematic patterns. Follow these steps:

Progress Checklist

Copy this checklist to track your progress:

Bug Hunt Progress:
- [ ] Step 1: Parsed arguments and determined scope
- [ ] Step 2: Loaded bug patterns from reference
- [ ] Step 3: Searched codebase for each pattern
- [ ] Step 4: Analyzed findings and confirmed bugs
- [ ] Step 5: Generated report with fixes

Step 1: Parse Arguments and Determine Scope

User input format:

Users invoke with: /bug-hunt [options]

Supported arguments:

• •--category <name> - Focus on specific category (timezone, null-safety, type-coercion, async, state, performance)
• •--severity <level> - Only show bugs of this severity or higher (high, medium, low)
• •--path <pattern> - Limit search to specific path (e.g., src/**/*.ts)
• •No arguments - Scan entire codebase for all patterns

Determine search scope:

# Default scope
search_path="."
categories="all"
min_severity="low"

# Parse user arguments
# Set search_path if --path provided
# Set categories if --category provided
# Set min_severity if --severity provided

Step 2: Load Bug Patterns

Read the appropriate bug pattern library based on the codebase:

Primary (always check):

• •typescript-javascript.md - TypeScript/JavaScript patterns including:
  • •Timezone/date handling bugs (toISOString issues)
  • •TypeScript type safety (any usage, type assertions, non-null assertions)
  • •Null/undefined safety
  • •Async/promise handling

Framework-specific (check if applicable):

• •react.md - React-specific patterns (hooks, state, performance)
• •vue.md - Vue-specific patterns (reactivity, lifecycle, composition API)

Each pattern includes:

• •Search pattern (regex or string)
• •Why it's problematic
• •How to fix it
• •Severity level
• •Code examples

Step 3: Search Codebase Systematically

For each pattern in the loaded reference files, search the codebase.

Search Strategy

Use Grep with file type filters:

# Example: Search for toISOString date formatting bug
grep -r "toISOString().split" --include="*.ts" --include="*.tsx" --exclude-dir="node_modules"

Focus on high-impact patterns first:

1. •TypeScript type safety - any, unsafe casts, non-null assertions
2. •Timezone bugs - .toISOString().split() in date formatting
3. •Async errors - Missing await, no try/catch
4. •Null safety - Deep property access without optional chaining

For each pattern match:

• •Note file path and line numbers
• •Capture code snippet showing the issue
• •Read surrounding context to understand intent

Step 4: Analyze Findings and Confirm Bugs

Important: Not every pattern match is a bug. Analyze each finding:

Confirmation Criteria

Read the code context:

• •What is this code trying to accomplish?
• •Is this pattern actually problematic in this context?
• •Is there existing handling that makes this safe?

Filter out false positives:

• •Code in comments or strings
• •Test/mock code that intentionally uses patterns
• •Code with compensating controls
• •Patterns used correctly in specific contexts

Confirm real bugs:

• •Pattern causes incorrect behavior
• •Missing error handling leads to crashes
• •Performance impact is measurable
• •User experience is negatively affected

Severity Assessment

High Severity:

• •Causes data loss or corruption
• •Breaks core functionality
• •Affects all users
• •Security vulnerability

Medium Severity:

• •Affects subset of users (e.g., specific timezones)
• •Causes incorrect behavior in edge cases
• •Performance degradation
• •Poor user experience

Low Severity:

• •Minor inconsistencies
• •Potential future issues
• •Code quality concerns
• •Could be problematic if code evolves

Step 5: Generate Report with Fixes

Create a comprehensive bug report:

Report Structure

# Bug Hunt Report

**Date:** {date}
**Scope:** {search scope}
**Patterns Checked:** {number} patterns across {categories}
**Bugs Found:** {total count}

---

## Summary

Found {count} bugs across {categories}:
- High severity: {count}
- Medium severity: {count}
- Low severity: {count}

---

## High Severity Issues

### 1. {Bug Title} - {Category}

**Location:** `{file}:{lines}`

**Severity:** High

**Description:**
{What the bug is and why it's problematic}

**Current Code:**
```{language}
{problematic code snippet}

Issue: {Specific problem - e.g., "Converts local date to UTC, causing date to shift for users in positive UTC offset timezones"}

Impact: {Who/what is affected - e.g., "Users in CET/CEST see dates off by 1 day"}

Fix:

{corrected code snippet}

Explanation: {Why this fix works}

Testing: {How to verify the fix}

Medium Severity Issues

{Repeat structure for each medium severity bug}

Low Severity Issues

{Repeat structure for each low severity bug}

Prevention

{Suggestions for preventing these bugs in the future:}

• •Add linting rules
• •Add unit tests for edge cases
• •Document patterns to avoid
• •Add type guards
• •Use stricter TypeScript settings

Statistics by Category

## Example Report Entry

Here's how to document a finding (using the real timezone bug example):

```markdown
### Date Filter Timezone Bug - Timezone/Date Handling

**Location:** `stores/searchStore.ts:356-369`

**Severity:** High

**Description:**
Date filters use `toISOString().split('T')[0]` to format dates, which converts local dates to UTC before formatting. This causes dates to shift to the previous day for users in positive UTC offset timezones.

**Current Code:**
```typescript
const startDate = filters.startDate?.toISOString().split('T')[0];
const endDate = filters.endDate?.toISOString().split('T')[0];

Issue: When a user in a positive UTC offset timezone (e.g., CET UTC+1) selects February 1st, the date is converted to UTC (January 31st 23:00) before formatting, resulting in "2024-01-31" being sent to the API instead of "2024-02-01".

Impact: Users in timezones with positive UTC offsets see and send incorrect dates to the API, receiving data for the wrong day.

Fix:

const formatLocalDate = (date: Date) => {
  const year = date.getFullYear();
  const month = String(date.getMonth() + 1).padStart(2, '0');
  const day = String(date.getDate()).padStart(2, '0');
  return `${year}-${month}-${day}`;
};

const startDate = filters.startDate ? formatLocalDate(filters.startDate) : undefined;
const endDate = filters.endDate ? formatLocalDate(filters.endDate) : undefined;

Explanation: Uses local timezone methods (getFullYear(), getMonth(), getDate()) instead of UTC conversion. The date stays in the user's local timezone throughout the formatting process.

Testing:

1. •Set system timezone to CET (UTC+1)
2. •Select February 1st in date picker
3. •Verify API receives "2024-02-01" not "2024-01-31"
4. •Check browser console for formatted date string

## Tips for Effective Bug Hunting

1. **Start with high-impact patterns** - Focus on bugs that affect all users first
2. **Read the context** - Don't just flag patterns, understand what the code does
3. **Provide actionable fixes** - Show exactly how to fix it, not just what's wrong
4. **Explain the impact** - Help developers prioritize by explaining consequences
5. **Suggest tests** - Include test cases that would catch these bugs
6. **Be specific** - Reference exact files, lines, and code snippets
7. **Group similar issues** - If the same pattern appears multiple times, note it
8. **Check for existing fixes** - Some bugs might already have workarounds

## When to Skip Patterns

Don't report issues in:
- Test files (unless the test itself is buggy)
- Mock/stub code
- Third-party dependencies (node_modules)
- Generated code
- Code with compensating controls already in place
- Intentional patterns (e.g., `==` for null/undefined check)

## Reference Materials

**Pattern libraries:**
- [typescript-javascript.md](references/typescript-javascript.md) - Core TypeScript/JS patterns (always use)
- [react.md](references/react.md) - React-specific patterns (if React codebase)
- [vue.md](references/vue.md) - Vue-specific patterns (if Vue codebase)