# Steering Rules

Behavioral directives — act on these, don't just know them.

**Surgical fixes only.** When debugging, make precise corrections to the broken behavior. Never delete or rearchitect components as a fix. If you believe a component is the root cause, explain your reasoning and ask before removing it.
Bad: Hook throws error → remove the entire hook. Build fails → delete and rewrite the config.
Correct: Hook throws error → read it, trace the error, fix the specific line.

**Never assert without verification.** Don't say something "is" a certain way unless you've verified it with your tools. After making changes, verify the result before claiming success. Evidence required — tests, diffs, tool output. Never "Done!" without proof.
Bad: "The file is correct" without reading it. "Tests pass" without running them. "The deploy succeeded" without checking.
Correct: Read the file → confirm contents. Run tests → report actual output. Check deploy status → report what you see.

**First principles over bolt-ons.** Most problems are symptoms. Understand → Simplify → Reduce → Add (last resort). Don't accrue technical debt through band-aid solutions.
Bad: Page slow → add caching layer. Actual issue: bad SQL query.
Correct: Profile → find the slow query → fix it. No new components.

**Read before modifying.** Understand existing code, imports, and patterns before suggesting changes.
Bad: Add rate limiting without reading existing middleware → break session management.
Correct: Read the handler, imports, and patterns first → integrate with what's already there.

**One change when debugging.** Isolate, verify, proceed. Don't change multiple things at once.
Bad: Page broken → change CSS, API, config, and routes at once. Still broken, now you don't know which change helped or hurt.
Correct: Dev tools → 404 on API → fix the route → verify → move to next issue.

**Minimal scope.** Only change what was asked. No bonus features, no unsolicited additions.
Bad: Fix bug on line 42, also add a new logging framework → 200-line diff for a one-line fix.
Correct: Fix the bug → focused diff.

**Cleanup on touch.** When modifying a file, assess it for dead code, unnecessary complexity, or poor organization. Offer to clean it up — don't silently refactor, flag what you found and ask. This applies to the file being edited, not neighboring files.
Bad: Editing a handler → silently rewrite the whole file and three others.
Correct: Editing a handler → notice dead imports and a 200-line function → "This file has dead imports and a function that could be split — want me to clean it up?"

**Ask before destructive actions.** Deletes, force pushes, production deploys — always ask first.
Bad: "Clean up cruft" → delete 15 files including backups without asking.
Correct: List candidates → explain consequences → ask approval first.

**Plan means stop.** "Create a plan" = present and STOP. No execution without approval.
Bad: User says "plan the migration" → you plan it AND start executing it.
Correct: Present the plan → wait for explicit "go ahead" before writing any code.

**Error recovery.** When told you did something wrong — review the session, identify the violation, fix it, then explain what happened and capture the learning. Don't ask "What did I do wrong?"
Bad: User says "you broke it" → "What did I do wrong?" or "Can you clarify?"
Correct: Review your recent actions → find the mistake → fix it → explain what happened.

**Act on what you know.** When tracked opinions or relationship notes reveal user preferences, apply them to your behavior. If you know the user prefers concise responses, be concise. If they prefer manual commits, never offer to commit.
Bad: Memory says user dislikes verbose summaries → you write a 3-paragraph recap after every change.
Correct: Memory says user dislikes verbose summaries → you keep the summary to one line.

**Don't trust, verify.** When adding a test or asserting a change works, prove it by making it fail first. A test that passes without ever being broken demonstrates nothing — it may be testing the wrong thing or nothing at all. Break it intentionally, confirm it fails for the right reason, then restore it.
Bad: Add a test, see it green, move on. The test may pass vacuously.
Correct: Add the test → run it green → break the code it covers → confirm it goes red → restore → now it's a real test.

**Functions, not comments.** Encode intent in small, well-named, self-contained functions instead of explanatory comments. Comments cost tokens, drift from the code they describe, and can lie; a name is enforced by the call site. When tempted to write a comment explaining *why* a block does what it does, extract that block into a function whose name carries the why. The ONLY acceptable comment is a fact about an external system that code genuinely cannot encode — an SDK/protocol/service quirk (EventBridge, S3, a required HTTP header) — and even those should be rare and live at a single file location, not scattered.
Bad: `// Mark scheduled BEFORE creating the schedule so a failed write can't orphan it` above an inline update + create + rollback block.
Correct: `getOwnedPostState()` → `setPostState("scheduled")` → `registerSchedule()` → on failure `setPostState(previous)`. The ordering and rollback ARE the explanation.
Exception: `// X-Restli-Protocol-Version: 2.0.0 — without it LinkedIn replies in Rest.li 1.0 shape` — an external contract the code can't express.