52 lines
2.7 KiB
Markdown
52 lines
2.7 KiB
Markdown
# Scope Discipline Rules
|
|
|
|
These rules override any general instinct to "improve while I'm in there." Follow them on every task, no exceptions.
|
|
|
|
## Before touching any code
|
|
|
|
1. Restate the task in one sentence: what behavior must change, and what the expected outcome is.
|
|
2. Identify the smallest set of files/functions responsible for that behavior. This is your **allowed scope**. Everything else is **protected**.
|
|
3. Read the relevant code before editing it. Do not edit based on assumptions about how it probably works.
|
|
|
|
## The hard rule: ask before expanding scope
|
|
|
|
If, while working, you find that:
|
|
- a file outside your allowed scope needs to change,
|
|
- a dependency needs to be added/updated,
|
|
- a test needs modification,
|
|
- an unrelated bug is blocking you,
|
|
- or a "cleaner" implementation would touch more than the minimum,
|
|
|
|
**stop and ask me before making that change.** Explain:
|
|
- what you were trying to do,
|
|
- why the fix requires going outside the original scope,
|
|
- exactly what you want to change and where.
|
|
|
|
Wait for my answer. Do not proceed on your own judgment, even if you're confident it's correct or trivial.
|
|
|
|
This applies even to small things (renaming a variable for clarity, fixing a typo in an unrelated comment, reformatting a block you had to scroll past). If it's not required to satisfy the request, ask first.
|
|
|
|
## While editing
|
|
|
|
- Make the fewest-line, fewest-file change that correctly satisfies the request.
|
|
- Preserve existing naming, structure, patterns, and formatting. Match the codebase's existing style, don't impose your own.
|
|
- Never run project-wide formatters/linters-with-autofix/import-organizers as a side effect of a small change.
|
|
- Never touch tests except to add new ones that validate the requested behavior — and only after confirming that's in scope.
|
|
- Treat any uncommitted/staged changes already in the working tree as off-limits. Don't revert, reset, or absorb them into your edit.
|
|
|
|
## Before reporting done
|
|
|
|
Review your own diff, file by file, line by line. For anything you can't justify with "this was required by the explicit request," revert it.
|
|
|
|
Then report:
|
|
- **Files changed** — list, with a one-line reason each tied directly to the request.
|
|
- **Scope confirmation** — explicitly state: "No files, dependencies, tests, or config outside this list were modified."
|
|
- **Anything you noticed but didn't touch** — unrelated bugs, tech debt, cleanup opportunities. Mention them, don't fix them.
|
|
|
|
## If the task genuinely can't be done without expanding scope
|
|
|
|
Say so plainly, explain what would need to change and why, and wait for confirmation. Don't silently do the bigger version, and don't pretend a partial/incorrect fix is complete.
|
|
|
|
---
|
|
|
|
**Default when uncertain: don't make the change, ask instead.** |