implementation-discipline

name	implementation-discipline
description	Дисциплинированная реализация: код, API, schemas, configs, tests, naming, errors, reuse, sync. Используй для: реализация, доработка, рефакторинг, нейминг, реюз, контракты, интеграционная синхронизация. EN triggers: implementation discipline, refactor cleanup, naming convention, code reuse, integration sync, contract change, error handling pattern.

Implementation Discipline

Purpose

Make every change precise, synchronized, maintainable, and consistent with the system around it.

Workflow

• Understand the current implementation before editing. Use Serena semantic tools first when available (get_symbols_overview -> find_symbol(body=false) -> find_symbol(body=true) -> find_referencing_symbols).
• Trace all affected integration points before finalizing: routes, clients, schemas, DTOs, migrations, generated types, config, docs, and tests.
• Preserve existing public contracts unless the task explicitly requires a breaking change.
• Keep changes atomic and readable. Separate mechanical refactors from behavior changes.
• Keep git history logical: separate implementation, tests/validators, docs/instructions, license/metadata, generated artifacts, and Serena memory sync when they are independently reviewable.
• Prefer clear names over comments. Use comments only for why, constraints, non-obvious algorithms, or external contract reasons.
• Remove obsolete code, stale branches, stale docs, dead feature flags, and outdated tests when they are in scope.
• Keep generated files synchronized with their source commands or state why generation is unavailable.

Reuse And Abstraction

• Reuse existing stable utilities, primitives, domain types, and patterns.
• Extract common code when there is real duplication or a stable concept, not just because two lines look similar.
• Do not introduce a broad abstraction for a single speculative future case.
• If two areas solve the same problem differently, choose the project-consistent pattern or ask before normalizing wider scope.

Read references/rules-policy.md for the full implementation discipline checklist.

Anti-patterns

• Edit without understanding existing implementation (use Serena first).
• Mix mechanical refactors with behavior changes in one commit.
• Dump unrelated implementation, docs, validator, license/metadata, generated, and Serena memory sync changes into one commit.
• Premature abstraction for single speculative future case.
• Skip integration tracing - forget about clients, schemas, generated types.
• Comments explaining WHAT (names should do that), not WHY.
• Leave dead code / stale flags / outdated tests in touched scope.