Aiogram architecture refactor

aiogram architecture refactor

improve structure without changing public telegram behavior. do not invoke for normal feature work unless structure blocks the requested change.

workflow

1. use aiogram-project-orientation unless the repository is already mapped.
2. define the boundary: behavior that must remain invariant, files and layers in scope, explicit exclusions, and tests that protect the behavior.
3. add focused characterization tests before a non-trivial move when existing coverage is missing.
4. move one responsibility at a time through existing architecture: handler logic to a service, data access to a repository, markup to a keyboard builder, text to localization, callback assembly to a factory, or a large router to domain routers.
5. preserve commands, callback payload compatibility, persisted FSM state names, user-facing text, keyboard layout, permissions, and polling or webhook behavior unless the request explicitly changes them.
6. preserve the installed aiogram major-version style and existing dependency wiring. do not introduce a parallel architecture for a single function.
7. keep imports safe: no startup on import, global Bot instance in feature modules, circular imports, handler config loading, or live network access in tests.
8. use aiogram-bot-verify after each meaningful slice and resolve failures before the next move.

completion requires a bounded responsibility move, protected invariant behavior, preserved compatibility, and verification for every slice. report what moved, what stayed stable, checks run, and remaining gaps.

guardrails

do not mix feature changes, aiogram migration, deployment changes, or unrelated cleanup into the refactor. never rename persisted callbacks or FSM states casually.