tdd-bug-fix

# Test-Driven Bug Fixing

When fixing bugs, you MUST follow Kent Beck's TDD discipline: write a failing test
first, then make it pass. There is no world in which production code changes
without a corresponding test change.

## When to Activate

- "Let me fix that" / "Let me fix this" / "I'll fix..."
- "Same [issue/problem/bug] as..."
- "The problem is..." followed by editing code
- "This isn't working because..." then editing code
- After identifying broken behavior and before editing production code
- When correcting any bug, defect, or incorrect behavior

## The Rule

**NEVER edit production code to fix a bug without first touching tests.**

The sequence is always:

1. **Reproduce** - Write a failing test that demonstrates the bug
2. **Verify red** - Confirm the test fails for the right reason
3. **Fix** - Make the minimal change to pass the test
4. **Verify green** - Confirm the test passes

## Workflow

### Step 1: Find Existing Tests

Before fixing anything, locate the test file:

```
spec/          # RSpec
test/          # Minitest, Jest, etc.
__tests__/     # Jest convention
*.test.ts      # Test file patterns
*.spec.rb
```

If no tests exist for the code being fixed, create them.

### Step 2: Write a Failing Test

Write a test that:
- Reproduces the exact bug scenario
- Fails with the current (broken) behavior
- Will pass once the bug is fixed

```ruby
# Example: Bug where API client uses wrong encoding
context 'when sending data to the API' do
  it 'sends JSON-encoded body, not form-encoded' do
    # This test will FAIL with current code (form encoding)
    # and PASS after the fix (JSON encoding)
    expect(request.content_type).to eq('application/json')
  end
end
```

### Step 3: Verify the Test Fails

Run the test and confirm it fails. This proves:
- The test is actually testing the bug
- The bug is real and reproducible

### Step 4: Fix the Production Code

Now, and only now, edit the production code to fix the bug.

### Step 5: Verify the Test Passes