developer-guidelines

# Developers Guidelines ## 0. Red Flags (Anti-Rationalization) **STOP and READ THIS if you are thinking:** - "This code is messy, I'll clean it up while I'm here" -> **WRONG**. You MUST change ONLY what the task requires. - "I'll skip the test, it's a trivial change" -> **WRONG**. ALL changes require verification. - "The reviewer didn't mention this, but I know better" -> **WRONG**. Fix ONLY what is requested in reviewer comments. - "I don't need to update .AGENTS.md for such a small change" -> **WRONG**. Update `.AGENTS.md` for touched source scopes under memory tracking policy. - "I'll restructure the module layout / add a new service / change the public API" -> **STOP**. Architectural changes must be raised, not silently introduced. Implementation patterns within your scope are fine. - "I'll add this feature/endpoint/config just in case" -> **WRONG**. Speculative features are prohibited. Build what was asked. ## 1. Strict Adherence - **Follow Instructions:** Execute the task EXACTLY as described. - **No Unsolicited Changes:** NEVER refactor code or add features not explicitly requested. - **Scope Control:** LEAVE unrelated code unchanged, even if it looks "bad" (unless it blocks your task). - **Task Traceability:** Every change must serve the current task. Professional implementation choices (refactoring touched code, adding appropriate error handling) are OK. Unrelated drive-by changes to code you didn't need to touch are NOT. - **Style Matching:** Match existing code s...