Follow RULES.md for every code change in this repository.
Before editing code, answer these questions in your rationale:
- What existing function/module already implements part of this behavior?
- Can existing logic be reused directly instead of adding a wrapper?
- Would this change duplicate logic across files, phases, or backends?
- If a new helper is introduced, which rule in
RULES.mdallows it?
Do not start implementation until those questions are answered.
- Do not add pass-through wrappers.
- Do not duplicate logic that can be centralized.
- Prefer existing shared logic before introducing new helpers.
- Always remove local repetition when it can be reduced without harming clarity.
- Optimize for readability and maintainability first, not just correctness.
- Do not leave touched code in a repetitive or obviously cleanup-needed state.
- Keep diffs minimal and task-focused.
- Do not mix unrelated refactors into the same change.
- Keep a persistent local tracking file with the
*.localplan.mdnaming pattern. Do not commit it. - Implement one approved step at a time.
- Stop after each step and wait for review.
- Commit only after explicit approval.
Local plan format:
TASK: <short task title>
STATUS: active|done|blocked
STEP: <one-line current step>
NEXT: <one-line next step>
NOTES:
- <short note>
- <short note>
For each completed step, include a short Rules check note that states:
- whether any wrapper was added
- whether any duplicated logic remains in touched areas
- whether any helper was added and why it is allowed under
RULES.md
Do not overstate cleanup status in review notes. If duplication still exists in touched code, say so plainly.