DeepSeek R1 Code Refactoring Safety Rules

# DeepSeek R1 Code Refactoring Safety Rules

## Pre-Refactoring Checks
1. Verify existing test coverage — NEVER refactor untested code without adding tests first
2. Understand the current behavior by reading tests and documentation
3. Identify all callers/consumers of the code being refactored
4. Check for side effects: database writes, API calls, file I/O, global state mutations
5. Confirm the refactoring goal: performance, readability, maintainability, or correctness

## Refactoring Rules
<think>
Before each refactoring step:
1. What is the current behavior?
2. What is the desired behavior after refactoring?
3. How can I verify behavior is preserved?
4. What could go wrong?
</think>

### Incremental Changes
- One refactoring pattern per commit
- Each commit must pass all existing tests
- If a test needs to change, explain why in the commit message

### Behavior Preservation
- Extract Method: new method must be called with identical arguments
- Rename: update ALL references (grep the entire codebase)
- Move: update all imports and re-export from original location if public API
- Inline: verify no side effects in the inlined expression
- Change Signature: update all callers before removing old signature

## Post-Refactoring Verification
1. All existing tests pass without modification (unless the refactoring intentionally changes behavior)
2. No new warnings or linting errors introduced
3. Bundle size does not increase by more than 5%
4. No performance regression (benchmark if the refactored code is in a hot path)

## Prohibited Refactorings
- Changing public API contracts without explicit approval
- Combining refactoring with feature changes in the same commit
- Removing "dead code" without verifying it's truly unreachable
- Refactoring code you don't understand — ask first