# Stay Within Task Scope - Don't Touch Unrelated Files

Change only what's necessary for the current task. Don't fix unrelated issues.

## The Problem with Scope Creep

**User asks:** "Fix the login button color"

**Bad response:** 
- Changes button color ✓
- Refactors entire auth module ✗
- Updates all form styles ✗
- Reorganizes folder structure ✗
- Adds new validation library ✗

## The Rule

Only modify files and code that are:
1. **Directly necessary** for the task
2. **Explicitly requested** by the user
3. **Unavoidable** dependencies

## Examples

### ✅ Good: Focused Changes

**Task:** Fix email validation bug

**Changes:**
- `utils/validation.ts` - Fix email regex
- `utils/validation.test.ts` - Add test for bug
- `auth/register.ts` - Update import (if validation file moved)

**Total:** 2-3 files directly related to email validation

### ❌ Bad: Scope Creep

**Task:** Fix email validation bug

**Changes:**
- `utils/validation.ts` - Fix email regex ✓
- `utils/validation.test.ts` - Add test ✓
- `utils/phone.ts` - "Also fixed phone validation" ✗
- `utils/date.ts` - "Noticed date parsing issue" ✗
- `utils/index.ts` - "Reorganized exports" ✗
- `auth/register.ts` - "Refactored while I was here" ✗

**Total:** 6 files, only 2 related to the task

## When You Notice Other Issues

### DO: Report Them
```markdown
"I fixed the login button color as requested.

Note: I noticed the registration form has similar styling 
issues. Should I address those in a separate PR?"
```

### DON'T: Fix Them Silently
```markdown
"I fixed the login button and also refactored the entire 
forms module to use a new design system."
```

## Dependency Changes

### ✅ Necessary Dependencies
If the task requires updating dependencies:

**Task:** Update API client

**OK to change:**
- API client code
- Types/interfaces used by API
- Tests for API client
- Code that directly calls the API client

### ❌ Unnecessary Dependencies
**NOT OK to change:**
- Other unrelated API clients
- UI components that use the API
- Utility functions that happen to be nearby
- Config files not related to API

## "While I'm Here" Syndrome

Common temptations to resist:

❌ "While refactoring X, I'll refactor Y too"
❌ "I noticed a typo, let me fix that"
❌ "This could be more efficient"
❌ "Let me reorganize these imports"
❌ "I'll update this to the new pattern"

### When It's OK

✅ Fix is in the same file you're already changing
✅ User explicitly said "and clean up anything else"
✅ Fix is critical (security issue, crash, data loss)

**Always ask first if unsure!**

## Ask Permission to Expand Scope

```markdown
"I can fix the login validation, but I noticed the 
registration form has the same issue. Would you like me to:

A) Fix only login (as requested)
B) Fix both login and registration  
C) Create a shared validation utility for both

Let me know your preference."
```

## Benefits of Focused Changes

- **Easier to review:** Small, focused PRs review faster
- **Safer to merge:** Less risk of unintended side effects
- **Easier to revert:** If something breaks, undo is simple
- **Better git history:** Clear what changed and why
- **Faster iteration:** Don't wait for large refactors

## Checklist Before Submitting

For each changed file, ask:
- [ ] Is this file directly needed for the task?
- [ ] Was this change explicitly or implicitly requested?
- [ ] Would the task fail without this change?

If you answer "no" to all three, don't include the file.

## Summary

- Do ONLY what was asked
- Report other issues separately
- Ask before expanding scope
- Keep PRs focused and reviewable
- Resist the urge to fix "just one more thing"

One focused task done well beats ten tasks done poorly.