Definition of Done (DoD)

Definition of Done (DoD) — проект целиком + по категориям (Backend, Flutter, Admin, CI/CD, QA) Это набор критериев, при выполнении которых задача/стори/эпик считается “готовым” и безопасным для релиза. Делится на общий DoD (для любой задачи) и специализированные DoD по типу работ. Общий DoD (для любой задачи / user story)

1.0. Жизненный цикл задачи (Jira)

Начало работы:

• Найти или создать задачу в Jira (AF-XX)
• Перевести в «В работе» (transition id=21)
• Добавить комментарий «Начата работа»

Завершение задачи (строгий порядок):

1. Тесты зелёные (pytest / flutter test)
2. Линтеры пройдены (ruff / dart analyze + dart format)
3. /write-docs — обновить docs/ (development-log, architecture, api-contract, getting-started)
4. /update-docs — обновить CLAUDE.md затронутых директорий
5. Коммит (включить docs-изменения)
6. /sync-jira done — закрыть задачу (transition id=31) + комментарий с результатами

Обязательно

Jira открыта в начале, закрыта в конце. Шаги 3–6 нельзя пропускать или менять местами.

1.1. Функционально

Реализовано согласно описанию сторисы и acceptance criteria. Нет известных блокирующих багов (Severity 1–2) по этой функциональности. Поведение задокументировано (минимум: README/ADR/Notion page/внутренняя дока) и ссылка приложена в задаче. /write-docs выполнен: development-log обновлён, затронутые документы актуализированы.

1.2. Качество кода

Код проходит линтеры/форматтер: Backend: black/isort/ruff (или выбранный стек) Flutter: dart format + analyzer Нет “dead code”, отладочных логов и временных фич-флагов без владельца/даты удаления. Нет hardcode секретов и приватных ключей в репозитории.

1.3. Тесты

Добавлены/обновлены автотесты соответствующего уровня (unit/integration/widget). Все тесты в CI зелёные. Для задач, влияющих на контракты: обновлён OpenAPI/схемы и добавлены contract tests.

1.4. Наблюдаемость

Есть логирование ключевых веток (успех/ошибка) с request_id/корреляцией (где применимо). Для критичных потоков добавлены метрики/события аналитики (минимум: start/success/fail).

1.5. Review и безопасность

Есть code review (минимум 1 апрув). Учитываются базовые security практики: валидация входов, ограничения прав, защита от повторов (идемпотентность), rate limiting (для публичных endpoints, если уместно).

1.6. Совместимость и миграции

При наличии изменений БД/контента: миграции подготовлены и протестированы (upgrade + downgrade где возможно). Нет поломки обратной совместимости API/данных без версионирования и плана rollout.

1.7. Релизность

Фича behind flag / remote config, если есть риск (по согласованию). Готова короткая “Release note” для команды: что изменилось, риски, что проверить вручную. DoD — Backend API (Django/DRF)

2.1. Контракты и схемы

Endpoint описан в OpenAPI (request/response schemas, status codes, errors). Реализован единый формат ошибок (ErrorEnvelope). Валидируются все входные поля (DRF serializer validation), нет “silent ignore”.

2.2. Идемпотентность и повторные запросы

Для write endpoints, где нужно: поддержан X-Idempotency-Key или client_event_id дедупликация. Повтор одного и того же запроса не приводит к двойной записи (progress, analytics, purchases, webhooks).

2.3. Производительность

Для списочных/тяжёлых endpoints есть индексы и ограничения (limit, cursor). Нагрузочная оценка: хотя бы локальный профилинг/EXPLAIN для самых важных запросов (/bootstrap, /manifest). P95 latency не деградирует >20% без причины (фиксируется в задаче, если меняется).

2.4. Безопасность

Auth на всех приватных endpoints. Авторизация по ролям на admin endpoints (release_manager и т.п.). Webhooks защищены (подпись/secret header + replay protection). Rate limiting включён для публичных endpoints (минимум: /auth, /analytics bulk).

2.5. Тесты (минимум)

Unit tests: валидация сериализаторов, правила day unlock, quiz selection, entitlement transitions (если затронуто). Integration tests: happy path + 1–2 негативных сценария на endpoint. Contract tests: проверка что response соответствует схеме (можно snapshot JSON schema). DoD — Flutter App (Core + Offline + UX)

3.1. UX/Flow

Флоу полностью проходим: onboarding → today → content → completion → back. Состояния корректны: locked/available/completed и отображаются без визуальных артефактов. Ошибки сети не ломают UI: есть fallback (кэш), повтор, сообщения.

3.2. Offline-first

Данные/контент сохраняются в локальную БД, и приложение работоспособно без сети после sync. Sync engine: не делает лишних запросов (manifest diff) умеет recover после падения/kill app дедуплицирует задачи загрузки Медиа: checksum проверка для “required” ассетов политика очистки кэша работает

3.3. Архитектура и качество

Нет бизнес-логики в виджетах (вынесено в services/repositories/notifiers). Все публичные модели сериализации покрыты тестами. Нет зависимостей, которые конфликтуют по лицензиям/поддержке без решения.

3.4. Тесты (минимум)

Unit: daily logic, time offset, sync apply diff. Widget: Today screen states, Quiz swipe gestures (если затронуто), Paywall gating (если затронуто). Integration smoke: запуск + bootstrap + открыть контент без крэша.

3.5. Мониторинг

Crash reporting включён, ключевые ошибки отправляются с контекстом (build, app_variant_id). Аналитика событий: минимум start/success/fail по новым потокам. DoD — Admin (кастомная админка)

4.1. Роли и права

Страницы и действия доступны только нужным ролям. Любая “опасная” операция (publish, bulk edit, rebuild all) требует подтверждения и логируется.

4.2. UX и предотвращение ошибок

Видно состояние сущностей (draft/scheduled/published). Есть валидация на уровне формы (например, day_index uniqueness). Есть предпросмотр для BrandConfig и ContentItem (хотя бы JSON/preview rendering).

4.3. Тесты

Unit/Integration: permissions, основные CRUD, критические bulk операции. Smoke: создать AppVariant, привязать курс, добавить item, опубликовать, проверить /bootstrap выдачу. DoD — CI/CD + Build Automation + Auto Publish

5.1. Сборка и воспроизводимость

CI workflow полностью воспроизводим из чистого runner (без ручных шагов). Сборка flavor’ов проходит на Android и iOS. Подпись (keystore/profiles) берётся из secrets/vault, нигде не хранится в репо. Версионирование: build number и version name повышаются корректно.

5.2. Автопубликация

Android: загрузка в нужный track (internal/alpha/beta/production) подтверждена. iOS: загрузка в TestFlight подтверждена (production submit — отдельным флагом). Логи fastlane доступны (ссылки/артефакты). При падении одного бренда остальные не блокируются (или чётко определено правило).

5.3. Оркестрация из Django

BuildJob статусы корректно обновляются (queued/running/succeeded/failed/published). Webhook idempotent: повторный webhook не ломает state. Есть защита webhook (secret + timestamp).

5.4. Тестирование CI/CD

Dry-run pipeline на 1–2 брендах. Smoke “rebuild all” на staging окружении. DoD — Monetization / Purchases

6.1. Клиент

Покупка и restore работают в sandbox (iOS/Android) минимум в smoke. Переход entitlement происходит корректно, UI обновляется без перезапуска. Ошибки покупки обрабатываются (cancel, fail, pending).

6.2. Сервер

Валидация receipt/token реализована или интегрирована через выбранный провайдер. Защита от повторной обработки транзакций (idempotency по transaction_id/order_id). Entitlements endpoint всегда отражает актуальное состояние.

6.3. Тесты

Unit на state machine, replay protection. Integration с моками внешних сервисов. DoD — Контент и версионирование Любое изменение “структурное” (day_index reorder, delete) имеет прописанную политику миграции. Контент версии/хэши обновляются, manifest корректно показывает изменения. Клиент при обновлении не теряет прогресс и не “прыгает назад”. DoD — QA и релизный контроль

8.1. Регрессия

Пройден обязательный ручной regression checklist: install → onboarding → day complete offline open + playback quiz session flow paywall gating + restore (если включено) notifications (минимум: настройка времени) Нет blocker багов.

8.2. Релизная документация

Release notes: что изменилось, что проверить, known issues. Rollback plan: server-side kill-switch (remote config) для критических фич инструкция как откатить публикацию/rollout DoD — Эпик (Epic Done) Эпик считается завершённым, если: Все сторисы эпика закрыты по DoD. Есть интеграционные тесты, покрывающие end-to-end сценарий эпика. В staging окружении прогоняется сквозной сценарий без ручных “костылей”. Метрики/логирование добавлены для ключевых точек эпика. Документация процесса для команды готова (как пользоваться, как дебажить).