specs/openspec/changes/archive/2026-10-09-versioned-deployment-bundle/tasks.md

1. Самодостаточный комплект

• 1.1 [deploy] Создать production Compose, release.env и пример server env, переиспользовав существующие images/migration/healthchecks и сохранив read-only CA mount и постоянные абсолютные пути.

  • Covers: deployment-bundle — Релиз определяет полную пару компонентов; deployment-bundle — Существующая установка сохраняет состояние
  • Verification: docker compose --env-file <disposable-server.env> --env-file release.env -f compose.yaml config --quiet; inspect подтверждает выбранную пару, один backend, общий data mount migration/backend, отсутствие host port API и read-only сертификат; exported image variables не подменяют релиз через entrypoint.

• 1.2 [deploy] Реализовать получение выбранного тега, выполнение snapshot его commit, preflight, flock и минимальные записи состояния в одном deploy.sh согласно Solution Assessment.

  • Covers: deployment-bundle — Релиз определяет полную пару компонентов; deployment-bundle — Проверки предшествуют изменению установки; deployment-bundle — Повтор и конкуренция не нарушают порядок обновления
  • Verification: bash -n deploy.sh; сценарная проверка отсутствующего/переназначенного тега, недоступного image/CA/data, отказа второго запуска и отсутствия изменений runtime при preflight failure; snapshot использует deploy-логику выбранного commit.

2. Безопасный lifecycle и его доказательство

• 2.1 [deploy] Реализовать first install/adoption, выбор изменённых сервисов, stop/backup/migration/readiness и остановку последовательности при ошибке без автоматического rollback.

  • Covers: deployment-bundle — Проверки предшествуют изменению установки; deployment-bundle — Существующая установка сохраняет состояние; deployment-bundle — Обновление затрагивает только изменённые компоненты; deployment-bundle — Обновление API сохраняет согласованную копию; deployment-bundle — Неудачное обновление не скрывает риск для данных; deployment-bundle — Повтор и конкуренция не нарушают порядок обновления
  • Verification: На disposable Compose project проверить явный --init, adoption существующей тестовой БД, обновление обоих компонентов и API отдельно, неизменность container ID API при frontend-only update, отсутствие повторного backup при healthy no-op; изменение backend config включает backup даже с прежним image.

• 2.2 [deploy] Добавить одну исполняемую проверку tests/deploy.sh без нового test framework и закрепить локальный gate для shell и сценариев обновления.

  • Covers: deployment-bundle — Релиз определяет полную пару компонентов; deployment-bundle — Проверки предшествуют изменению установки; deployment-bundle — Существующая установка сохраняет состояние; deployment-bundle — Обновление затрагивает только изменённые компоненты; deployment-bundle — Обновление API сохраняет согласованную копию; deployment-bundle — Неудачное обновление не скрывает риск для данных; deployment-bundle — Повтор и конкуренция не нарушают порядок обновления
  • Verification: bash -n deploy.sh tests/deploy.sh, bash tests/deploy.sh, git diff --check; fault injection доказывает отсутствие migration после failed copy, отсутствие backend start после failed migration, stop после backend readiness failure, сохранение backend после frontend failure, неизменность данных/старых backups, блокировку конкуренции и незавершённой операции. Проверка использует временные данные; production paths недопустимы.

3. Эксплуатация и документация

• 3.1 [deploy] Описать в README подготовку сервера, сохранение старых ключей и Compose project, install/update, выпуск тега с проверенной парой, диагностику, ручной rollback/restore и очистку backups; закрепить реально опубликованную первую пару перед выпуском.

  • Covers: deployment-bundle — Оператор располагает полным порядком эксплуатации; deployment-bundle — Релиз определяет полную пару компонентов
  • Verification: Пройти инструкцию на изолированной установке с тестовыми данными; проверить login/refresh через HTTPS, сохранение записей и расшифровку тестового подключения прежним ключом, PRAGMA integrity_check на копии и explicit restore; сравнить actual images с release.env. Первый тег не публиковать до проверки пары.

• 3.2 [docs] Завершить ADR 016 и glossary, обновить production-раздел контейнерной поставки под deploy с сохранением development-инструкции и границ ручного recovery.

  • Covers: N/A — docs объясняет поставленный механизм из Design и направляет оператора к единственному README комплекта; самостоятельного runtime behavior не добавляет.
  • Verification: После nvm use --silent выполнить npm run verify в docs; проверить маршрут README → deployment → ADR и отсутствие обещаний ещё не реализованных операций или дублирующего production runbook.

• 3.3 [root] Направить production-раздел root README к комплекту deploy, сохранив существующие development-команды.

  • Covers: N/A — workspace-навигация должна вести к владельцу production lifecycle из Design; поведение приложения и root tooling не меняются.
  • Verification: git diff --check в root; просмотр маршрута root README → deploy README и docs/architecture/deployment.md, проверка неизменности development-команд.

4. Сверка поставки

• 4.1 [specs] Сверить артефакты с фактической реализацией, сохранить coverage всех требований и проверить canonical change без изменения чужого containerized-application-delivery.

  • Covers: N/A — requirements и checklist должны оставаться контрактом реализованного комплекта; задача поддерживает точность SDD, а не вводит новое поведение приложения.
  • Verification: После nvm use --silent: openspec schema validate wealth-ledger-sdd --verbose; openspec validate versioned-deployment-bundle --type change --strict --store wealth-ledger-specs; openspec validate --specs --strict --store wealth-ledger-specs; npm run verify; вручную проверить task coverage и соответствие дополнительному owner deploy из Delivery Map.

• 4.2 [workspace] Выполнить итоговую сверку сценариев установки, ошибок и восстановления с готовыми образами и результатами локальных gates затронутых репозиториев.

  • Covers: N/A — объединяет доказательства deploy/specs/docs для согласованной пары, не владеет реализацией какого-либо репозитория и не заменяет independent review.
  • Verification: На disposable данных сверить успешный update, frontend-only, interrupted update и recovery с Delta Specs; зафиксировать фактические версии и результаты gates. Проверки реального сервера не подменять локальным smoke; production rollout не входит в эту задачу.

5. Implementation checkpoint

2026-09-20: implementation-owned задачи выполнены; готово к независимой Validation. Change остаётся active. Первый тег deploy не опубликован, рабочий сервер не изменялся.

• Deploy: bash -n deploy.sh tests/deploy.sh, bash tests/deploy.sh — PASS. Проверены selective update/no-op, config drift, сохранение ключей, symlink guard, ошибки pull/preflight/copy/migration/backend/frontend, concurrent lock и pending.
• DOCKER_DEFAULT_PLATFORM=linux/amd64 bash tests/deploy.sh --docker-restore — PASS: заменённый bind-каталог читается после force-recreate. Без пересоздания исходный live repro читал старые данные; README recovery исправлен по этому результату.
• Disposable smoke с реальными Nexus images 0.2.3 — PASS: init, no-op по native Compose hash, frontend-only/backend-only config update, stopped backup, PRAGMA integrity_check, HTTPS deep link, registration, Secure-cookie и refresh.
• Explicit restore на синтетических данных — PASS: login, карта и её баланс, отсутствие более новой карты и расшифровка тестового токена штатным TbankCrypto. Оба тестовых Compose projects удалены; настоящие пользовательские данные и реальное подключение к T-Bank не использовались.
• OCI revisions совпали с Git tags компонентов: frontend f486ae4fb2d06e71779901bde283950542f27ed2, backend 0862d56c4e4d9dd554556c3992cc073193020ff1.
• Среда интеграционной проверки: Docker Desktop, Linux amd64 images через эмуляцию на arm64 Mac, Compose 5.5.1; host flock в smoke заменён stdlib fcntl. Это не проверка конфигурации целевого Linux-сервера или его registry login.