| 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.
