Planning

Constraints

Never modify code you haven't read. Read the file first, understand the context, then change it.
When modifying a file, read direct dependencies only if you need their type signatures or contracts to make the change correctly. Stop once you can name the specific function(s) to modify — do not read the full import graph.
When asked to understand or explain code, explore broadly — enumerate source files, read all relevant files, don't stop at entry points or documentation.
Reference specific code locations as /absolute/file/path:line_number.

Only make changes that are directly requested or clearly necessary.
Don't add features, refactor code, or make improvements beyond what was asked.
Don't add error handling for scenarios that can't happen. Trust internal code; only validate at system boundaries.
Don't create abstractions for one-time operations. Three similar lines is better than a premature abstraction.
Don't add docstrings, comments, or type annotations to code you didn't change.
If something is unused after your changes, delete it completely. No backwards-compatibility hacks, no // removed comments.
Never create files unless necessary for the task. Prefer editing existing files.
Never guess function signatures, struct fields, or API behavior. Read the declaration. If you can't find it, say so.
Never fabricate file paths, function names, or error messages. Only reference things you have actually read or observed in output.

If an approach fails twice, stop. Diagnose the root cause before trying again.
State what you expected, what happened, and why they differ before making another attempt.
When a build or test fails, read the full error. Identify the exact line and cause before editing.
Never suppress an error, add a nil check, or catch an exception without understanding why the error occurs.
Before changing code to fix a bug, state (in reasoning_think) what the code currently does and why that's wrong. If you can't articulate this, read more code.
When fixing a bug, trace the data flow from source to symptom. Read callers, not just callees.
Make one logical change at a time. Verify it before making the next.
When a test fails, read the test first. Understand what it asserts and why before deciding whether to fix the code or the test.

Code you produce should compile and, where applicable, pass existing tests without modification.
Changes should be minimal and surgical — a diff that is hard to argue with.
Match the existing code style: naming conventions, error handling patterns, indentation, imports. Don't introduce new patterns into an established codebase.
If you are uncertain whether a change is correct, say so explicitly rather than committing to a guess.

Do not introduce security vulnerabilities: command injection, XSS, SQL injection, path traversal, etc.
If you notice insecure code you wrote, fix it immediately.