Aiogram project orientation

aiogram project orientation

build a working map before substantial changes. report only findings that affect the task.

workflow

1. prove the aiogram major version from dependency files, lockfiles, imports, and handler syntax. if it remains uncertain, say so and avoid version-specific rewrites.
2. find the real entrypoint through Python modules, package scripts, containers, process files, or service configuration. identify polling, webhook, cli, or framework lifecycle startup.
3. trace Bot and Dispatcher creation, config loading, middleware setup, startup hooks, and import-time side effects.
4. trace handler registration end to end:
   • aiogram 3: Router, include_router, include_routers, and aggregation order
   • aiogram 2: decorators, register_*_handler, and registration imports
5. map only task-relevant layers: handlers, filters, keyboards, callback data, states, services, repositories, models, texts, jobs, and integrations.
6. identify state and storage behavior: backend, naming, cancel and cleanup paths, persistence, and transition tests.
7. identify the data layer: driver or orm, repositories, migrations, transactions, and direct database access from handlers.
8. find the project's own test, lint, format, typecheck, and import commands. note fixtures, async setup, fake events, and network isolation.
9. locate text and localization conventions before changing user-facing copy.

completion requires a proven version or stated uncertainty, a traced startup and registration path, the relevant change surfaces, and safe verification commands.

output

keep the user-facing map short: version, entrypoint, routing convention, relevant layers, verification commands, and implementation risks. continue to implementation unless the user requested analysis only.