orchestrator/docs/work-items/ORCH-016/14-deploy-log.md

deploy_status, timestamp, work_item, branch, commit, target_service, target_port, deploy_mode, prod_container_restarted

deploy_status	timestamp	work_item	branch	commit	target_service	target_port	deploy_mode	prod_container_restarted
SUCCESS	2026-06-05T12:51:07Z	ORCH-016	feature/ORCH-016-plane	d4b02ef728	orchestrator	8500	artifact-only	false

Deploy Log — ORCH-016

Verdict

deploy_status: SUCCESS — артефактный (artifact-only) деплой-вердикт. Реальный pull / docker-restart прод-контейнера orchestrator (8500) НЕ выполняется в рамках этой стадии: он делегирован хуку scripts/orchestrator-deploy-hook.sh (ORCH-36), который запускается после мерджа PR ветки feature/ORCH-016-plane в main.

Pre-conditions (все ✓)

Артефакт	Поле	Значение
12-review.md	verdict	APPROVED
13-test-report.md	verdict	PASS
15-staging-log.md	staging_status	SUCCESS (10/10 staging-checks)
04-test-plan.yaml	—	покрывает AC-1…AC-14
ADR	06-adr/ADR-001-*	заведён
CHANGELOG.md	Added/Changed	обновлён в коммите 0663da6

Self-hosting policy

ORCH-016 правит код инструмента, который СЕЙЧАС обслуживает все проекты (orchestrator + enduro-trails) из одного прод-инстанса (orchestrator:8500) с общей БД и общей очередью.

Поэтому:

1. Прод-контейнер orchestrator (8500) в этой стадии НЕ перезапускался — prod_container_restarted: false в frontmatter. Это прямое требование CLAUDE.md (раздел "Self-hosting") и docs/operations/INFRA.md.
2. Перезапуск прод-контейнера произойдёт ПОЗЖЕ, после мерджа ветки в main и срабатывания CI → scripts/orchestrator-deploy-hook.sh.
3. Staging-стенд (8501) уже принял изменения и прошёл регресс (15-staging-log.md, 10/10 checks) — это и есть страховка перед прод-деплоем self.

Что войдёт в прод после мерджа PR

Изменения ORCH-016 (коммит 0663da6 + reviewer/tester auto-commits):

Файл	Тип изменения
src/usage.py	расширен build_status_comment(...): длительность, defensive формат, HTML-фрагменты artifact_links
src/agents/launcher.py	пробрасывает duration_s из _monitor_agent в _post_usage_comments
src/stage_engine.py	для analyst-стадии — DB-fallback usage.get_agent_duration(task_id, agent)
src/frontmatter.py	defensive read_frontmatter_value(...)
tests/test_status_comment_*.py и др.	60 новых тестов TC-01…TC-23 (PASS)
docs/architecture/README.md	раздел "Plane Sync: единый status-коммент агентов"
docs/work-items/ORCH-016/06-adr/ADR-001-*.md	ADR ORCH-016
CHANGELOG.md	Added + Changed

Поведение, видимое в Plane после прод-деплоя: единый формат финального status-комментария у всех ролей (analyst…deployer), с явной строкой Длительность: … и HTML-форматом артефактных ссылок.

Deploy-handoff (что будет дальше, вне этой стадии)

После того как PR с веткой feature/ORCH-016-plane будет смерджен в main, цепочка такая (см. scripts/orchestrator-deploy-hook.sh):

PR merge to main
   └─► Gitea Actions (CI)
        └─► orchestrator-deploy-hook.sh --deploy
             ├─ git pull origin main
             ├─ docker compose up -d --no-build orchestrator   (TARGET_SERVICE=orchestrator, TARGET_PORT=8500)
             ├─ health-check 10× × 6s  (max 60s)
             └─ at failure → AUTO ROLLBACK to previous image

Параметры прод-деплоя, которые должны быть выставлены в окружении hook’а (env vars из INFRA.md):

TARGET_SERVICE=orchestrator
TARGET_PORT=8500
TARGET_IMAGE=orchestrator-orchestrator
COMPOSE_PROFILE=""           # пустой → без --profile, дефолтный сервис
PREV_IMAGE_FILE=$REPO/.deploy-prev-image-prod

(Дефолты в скрипте — STAGING-safe; прод-параметры выставляет внешний caller, не агент.)

Auto-rollback hook’а гарантирует, что в случае нездорового deploy контейнер вернётся на предыдущий образ, а строка deploy_status в этом логе НЕ задним числом меняется — финальный прод-вердикт фиксируется отдельным запуском стадии deploy после ORCH-36 GA.

Команды (только read-only проверки, ничего не запускалось)

# 1. Подтвердить, что прод-инстанс живой (не трогаем, только смотрим):
#    выполнялось окружением (curl недоступен в worktree-sandbox),
#    последний подтверждённый /health=ok — в 13-test-report.md.

# 2. Подтвердить вердикт staging:
grep '^staging_status:' docs/work-items/ORCH-016/15-staging-log.md
# → staging_status: SUCCESS

# 3. Подтвердить вердикты review/test:
grep -E '^(verdict|result):' docs/work-items/ORCH-016/{12-review.md,13-test-report.md}
# → 12-review.md:verdict: APPROVED
# → 13-test-report.md:verdict: PASS
# → 13-test-report.md:result:  PASS

Rollback plan (если по факту прод-деплоя что-то сломается)

1. Hook сам делает auto-rollback (см. do_rollback() в orchestrator-deploy-hook.sh).
2. Ручной откат — вызвать:

   TARGET_SERVICE=orchestrator TARGET_PORT=8500 \
   TARGET_IMAGE=orchestrator-orchestrator COMPOSE_PROFILE="" \
   PREV_IMAGE_FILE=/home/slin/repos/orchestrator/.deploy-prev-image-prod \
   /home/slin/repos/orchestrator/scripts/orchestrator-deploy-hook.sh --rollback
   

3. Точка отката: предыдущий running image, сохранённый в .deploy-prev-image-prod ДО docker compose up.

Quality Gate

Поле deploy_status: SUCCESS (uppercase) в YAML-frontmatter этого файла — машинно-читаемый вердикт, который парсит quality gate check_deploy_status. Никакая проза в теле логa не учитывается.

---

Stage: deploy. Финальная стадия конвейера. Следующий шаг — done (закрывается CI / финальной стадией, не агентом). Self-hosting: prod-контейнер orchestrator:8500 в рамках этой стадии не трогался — это прямое требование CLAUDE.md.