01ДЕФЕКТ
Бот падает или отвечает неправильно в одном сценарии
Сначала воспроизводим симптом на безопасных данных, затем ограничиваем изменение конкретным обработчиком и его зависимостями.
Existing bot · Python / aiogram
Подхватим работающего бота — без слепого переписывания
Принимаем существующий репозиторий, воспроизводим один дефект или ограничиваем одну приоритетную функцию, добавляем тесты и готовим контролируемое Docker-обновление с backup и rollback.
Для первого разбора не нужны токены, приватные ключи, production-доступы, дампы баз и реальные пользовательские данные.
Цель первого этапа
Не «разобраться во всём проекте», а получить воспроизводимый baseline, ограниченное изменение, тест и безопасный способ обновления.Когда подходит
Работающий бот требует точечного вмешательства
Берём задачу, когда есть репозиторий или доступный исходный код, понятный приоритет и возможность проверить один сценарий без раскрытия клиентских данных.
02ФУНКЦИЯ
Нужна одна приоритетная доработка
Фиксируем вход, ожидаемый ответ, изменения PostgreSQL/Redis при наличии и критерии, которые подтверждают готовность функции.
03ОБНОВЛЕНИЕ
Изменение уже готово, но страшно выкладывать
Проверяем сборку, миграции, health/smoke, backup и команду rollback до контролируемого Docker-обновления через SSH.
04ПЕРЕДАЧА
Нужно сделать поддержку воспроизводимой
Дополняем runbook, команды тестов и запуска, changelog и минимальный порядок диагностики следующего сбоя.
Safe intake
Что подготовить без секретов
Материалы должны описывать версию и сценарий, но не открывать лишние production-данные. Передачу доступов согласуем отдельно после определения scope.
Ветка или commit
Ссылка на репозиторий и точная версия, которая соответствует текущей рабочей сборке.
Команды запуска
README, compose-файлы, список сервисов и порядок локального или staging-запуска.
Безопасный пример
Обезличенный update, traceback или шаги, которые воспроизводят один выбранный дефект.
Ожидаемое поведение
Что должно произойти, какие данные меняются и что пользователь или администратор увидит в итоге.
Схема окружения
Названия переменных и зависимостей без токенов, паролей, приватных ключей и production-дампов.
Текущий порядок обновления
Dockerfile/compose, health-check, миграции, расположение backup и известный способ rollback.
Самопроверка перед стартом
Готов ли бот к безопасной доработке?
Отметьте только то, что уже подготовлено. Чек-лист не оценивает весь проект — он помогает выбрать следующий ограниченный шаг.
План первого этапа
Начните с границы, которую можно проверить
Выберите только категорию симптома, срочность и доступный способ проверки. Поля не принимают свободный текст, секреты или данные пользователей.
После первого этапа
Разовый ремонт или сопровождение?
Три несекретных выбора помогают отделить единичное восстановление от очереди изменений и регулярного контроля. Это ориентир для брифа, а не обещание объёма или времени реакции.
Итоговый handoff
Один бриф из трёх проверок
Итог собирается из отметок выше: без повторного ввода, сохранения на сервере и передачи выбранных значений. Скопируйте его перед переходом в технический бриф.
Клиентский брифнужно заполнить 2 блока
Завершите два выбора выше
После этого здесь появятся недостающие предпосылки, первый этап, приёмка, ответственность и формат поддержки.
- Недостающие предпосылки
- Уточняются по чек-листу
- Первый этап
- —
- Критерий приёмки
- —
- Граница ответственности
- —
- Формат поддержки
- —
Итог формируется только в этой вкладке. Значения не сохраняются, не добавляются в URL и не отправляются на сервер. Не добавляйте в скопированный текст пароли, токены, приватные ключи, персональные, платёжные данные или production-доступы.
Рабочий контур
Стек проверяется как единый путь
Изменение handler без проверки состояния, базы, контейнера и теста может оставить скрытую ошибку. Поэтому принимаем путь целиком, но только в согласованной границе.
PYTHON / AIOGRAM
Handlers, middleware, FSM, фоновые задачи и интеграции разбираем от входного update до наблюдаемого результата.
POSTGRESQL / REDIS
Проверяем запросы, миграции, транзакционные границы, кэш, состояния и совместимость изменённого пути.
DOCKER / SSH
Собираем и проверяем контейнер, фиксируем образ или сборку и выполняем только согласованные команды обновления.
PYTEST
Добавляем тесты на изменённый сценарий и сохраняем команду, которой заказчик может повторить проверку.
Этапы
От intake до контролируемого обновления
Первичная квалификация бесплатна и ограничена. Разворачивание проекта, диагностика, прототип, доработка и production update — платные этапы после письменного согласования.
- 01БЕСПЛАТНАЯ КВАЛИФИКАЦИЯ
Понимаем границу задачи
Уточняем стек, наличие репозитория/runbook, симптом или функцию и способ безопасно проверить результат.
Результат этапаОдин ограниченный платный этап и список материалов без секретов.
- 02ПЛАТНЫЙ INTAKE И ВОСПРОИЗВЕДЕНИЕ
Получаем управляемую точку отсчёта
Разворачиваем согласованную версию локально или на staging, проверяем зависимости и воспроизводим один выбранный сценарий.
Результат этапаЗафиксированный baseline, причина или техническая граница функции, план изменения и rollback.
- 03ПЛАТНАЯ ДОРАБОТКА
Меняем только согласованный путь
Реализуем исправление или функцию, добавляем pytest на изменённое поведение и выполняем ограниченную регрессию связанных компонентов.
Результат этапаPatch с тестами, воспроизводимое демо и список известных границ.
- 04КОНТРОЛИРУЕМОЕ ОБНОВЛЕНИЕ
Сначала backup, потом контейнер
Проверяем сборку и миграции, сохраняем применимые данные и конфигурацию, обновляем контейнер и выполняем health/smoke.
Результат этапаРабочая версия или выполненный rollback без импровизации на production.
- 05ПЕРЕДАЧА
Оставляем проверяемый след
Передаём изменённый код, тесты, changelog, команды сборки/запуска и обновлённый runbook в пределах согласованного этапа.
Результат этапаПонятно, что изменено, как повторить тест и как запустить или откатить версию.
Контрольные точки, оплата и передача
Отдельно описали, как фиксируем границы, показываем демо и передаём артефакты после согласованной оплаты.
Приёмка
Шесть проверок изменённого пути
Проверяем только согласованный scope и явно фиксируем, что осталось за его пределами.
- 01
Baseline воспроизводится
До изменения зафиксирован один дефект или контрольный сценарий функции на согласованной версии кода.
- 02
Изменённый путь проходит тесты
Новый pytest и относящиеся к компоненту тесты выполняются одной сохранённой командой.
- 03
Данные меняются по правилу
Для PostgreSQL/Redis проверены затронутые записи, миграции или состояния без обещания полного аудита базы.
- 04
Контейнер запускается предсказуемо
Сборка завершается, сервис проходит согласованный health/smoke, а ошибка остаётся в техническом журнале.
- 05
Rollback понятен до обновления
Известны предыдущая версия, backup, команда возврата и проверка состояния после отката.
- 06
Changelog совпадает с фактом
Перечислены изменённые файлы, поведение, тесты, миграции, команды и оставшиеся ограничения.
Честный scope
Техническая доработка без чужих денег и аккаунтов
Работаем с кодом и инфраструктурой только в разрешённых границах. Секреты и доступы не становятся частью публичного брифа или changelog.
- Существующий Telegram-бот на Python/aiogram и его согласованные зависимости.
- Один воспроизводимый дефект или одна приоритетная функция в первом этапе.
- Тесты изменённого пути, ограниченный smoke и понятный changelog.
- Backup/rollback и контейнерное обновление, когда они прямо входят в scope.
- Custody, хранение или переводы денежных средств и платёжных реквизитов.
- Управление чужими аккаунтами, сессиями или действиями от имени их владельцев.
- Обход ограничений платформ, скрытый доступ или получение чужих секретов.
- Массовый спам, фальшивые отзывы и автоматизация вводящих в заблуждение действий.
FAQ
До передачи репозитория
Можно принять бот без документации?
Можно начать с платного intake: зафиксировать версию, восстановить минимальный запуск и составить короткий runbook. До этого нельзя честно оценить доработку и безопасный production update.
Нужен ли сразу доступ к production?
Нет. Первичный разбор и большая часть воспроизведения должны проходить без production-секретов. Доступ через SSH запрашивается только для согласованного обновления, с минимальными правами, backup и готовым rollback.
Почему не переписать бот сразу?
Переписывание — отдельное архитектурное решение. В первом этапе безопаснее проверить один важный путь, оценить качество зависимостей и сравнить стоимость точечной доработки с постепенной заменой.
Какие тесты добавляются?
Минимум — pytest на изменённое поведение и необходимые фикстуры или моки. Дополнительно запускаем относящиеся тесты и ограниченный smoke; полный аудит и покрытие всего проекта оцениваются отдельно.
Как проходит Docker-обновление?
Фиксируем исходную версию, проверяем сборку и миграции, готовим backup и rollback, затем обновляем контейнер и выполняем health/smoke. При отклонении возвращаем предыдущую согласованную версию.
Что передаётся после работы?
В пределах согласованного этапа — изменённый исходный код, тесты, changelog и актуальные команды runbook. Гарантийное исправление дефектов и последующая поддержка действуют только если согласованы отдельно.
Следующий шаг
Опишите один дефект или одну функцию
Укажите версию Python/aiogram, состав PostgreSQL/Redis/Docker без секретов, наблюдаемое поведение и желаемый результат. Этого достаточно для бесплатной первичной квалификации.