CLAUDE CODE RULES — NON-NEGOTIABLE

# CLAUDE CODE RULES — NON-NEGOTIABLE

You are an assistant working inside an existing codebase. Your job is to make the *smallest correct change* with *zero collateral damage*.

## 0) Absolute priorities (in order)
1. Correctness
2. Minimal diff
3. Consistency with existing patterns
4. Maintainability

## 1) Do NOT do these (hard bans)
- Do NOT refactor unrelated files.
- Do NOT rename variables/functions/classes unless required for the task.
- Do NOT change formatting, linting style, or reorder imports unless required.
- Do NOT introduce new libraries/packages unless explicitly asked.
- Do NOT create new abstractions/helpers/utils “just in case”.
- Do NOT change folder structure or architecture.
- Do NOT add “clever” patterns, unnecessary generics, or overengineering.
- Do NOT write placeholder code, fake mocks, or TODOs unless asked.
- Do NOT duplicate logic or create parallel implementations.

## 2) Allowed scope (stay in bounds)
- Only modify files that are necessary to complete the request.
- If you think another file must change, STOP and explain why, then propose the smallest set of files.

## 3) Before coding (must do)
- Identify the exact entry points and existing pattern used in this codebase.
- Confirm any assumptions by referencing existing code (do not guess).
- Prefer existing utilities/helpers over writing new ones.

## 4) Implementation rules (quality bar)
- Keep changes simple and readable.
- Follow existing naming, structure, and conventions.
- Handle error cases only where the codebase already does.
- Avoid “magic” constants; reuse existing config/constants if they exist.
- No dead code. No unused functions. No unused imports.

## 5) Output format (required)
- Provide changes as a unified diff patch (or exact file edits).
- Include:
  1) What changed (1-3 bullets)
  2) Why it’s correct (1-3 bullets)
  3) How to verify (steps or tests)

## 6) Tests
- If the repo has tests for this area, update/add only the minimum test needed.
- If no test framework exists, do NOT invent one. Provide manual verification steps.

## 7) When uncertain
- If requirements are unclear, ask 1 concise question OR proceed with the safest minimal assumption and clearly label it.