From 504bac2e25a9da83b2c650a491e80d2331f7cb73 Mon Sep 17 00:00:00 2001 From: Stream Date: Fri, 5 Jun 2026 09:50:01 +0300 Subject: [PATCH] auto-sync: 2026-06-05 09:50:01 --- memory/2026-06-05.md | 39 ++++++++++++++++++++++++ tasks/orchestrator/DESIGN_STAGING_ENV.md | 14 +++++++++ 2 files changed, 53 insertions(+) diff --git a/memory/2026-06-05.md b/memory/2026-06-05.md index f725f64..fd97305 100644 --- a/memory/2026-06-05.md +++ b/memory/2026-06-05.md @@ -193,3 +193,42 @@ ### Дальше Этап 4 (ORCH-34): хост-деплой-хук `orchestrator-deploy-hook.sh` (промоут staging→prod, health 10×6с=60с, auto-rollback по PREV_IMG). Образец `/home/slin/bin/enduro-deploy-hook.sh`. + + +--- + +## Этап 4 (ORCH-34) деплой-хук — ГОТОВО ✅ + чистка Plane (05.06, продолжение) + +### Закрыты в Plane (Backlog → Done НАПРЯМУЮ, минуя In Progress) +- ✅ ORCH-30, ORCH-31, ORCH-32, ORCH-33 → Done (верифицированы). +- ⚠️ **Важная тонкость безопасности:** боевой webhook ORCH-проекта идёт на прод (8500). Переход задачи **В In Progress запустил бы конвейер** по ней! Поэтому выполненные задачи двигать **Backlog → Done напрямую, минуя In Progress**. Прод не дёрнулся. +- **State id Done** в проекте ORCH: `3738cd3c-7610-4907-ba5e-26b9a248d9c0`. +- ⚠️ **In Progress id ПЛАВАЕТ** — был `b873d9eb...` (в памяти), стал `e331bfb3...`. ВСЕГДА запрашивать states свежим API-вызовом, НЕ по памяти. +- ОстаютсяBacklog: ORCH-34 (закрою после мержа), ORCH-35 (не начат). + +### Бот-аккаунты добавлены в SANDBOX (нюанс Этапа 3 закрыт) +- 403 при коммите бот-токеном был НЕ из-за доступа к проекту (GET 200 у всех 7 ботов), а из-за **членства**: чтобы постить комменты, владелец бот-токена должен быть **member** проекта. +- **Plane API формат добавления члена:** `POST /projects//members/` с телом `{"member": , "role": 15}` — ПООДИНОЧКЕ (не массивом), поле `member` (НЕ `member_id`!), role 15 = member. +- Добавила всех 7 владельцев бот-токенов в SANDBOX → коммент бот-токеном теперь 201 (было 403). Проверено воспроизведением. +- user-id ботов узнаются через workspace-members API. + +### Этап 4 — деплой-хук (проверено мной на проде, оба сценария) +- Dev: `scripts/orchestrator-deploy-hook.sh` (176 строк) + `docs/DEPLOY_HOOK.md`. Ветка `feature/ORCH-34-deploy-hook`, коммит `a6cbacb`. **PR #30 open.** +- **Happy-path ✅:** deploy → health ok за 1 попытку → exit 0. +- **Авто-rollback ✅ (главное):** Я сама подсунула битый образ (busybox `exit 1`, перетегла как staging-образ) → хук прождал 10×6с=60с (HTTP 000) → САМ откатился на PREV_IMG → рестарт → post-health 5×3с → поднялся → staging снова ok. **Реальный exit-code хука = 1** при фейле (проверила без пайпа `| tail`, который съедал rc). +- **Heredoc-грабля Dev:** при передаче скрипта через heredoc терялись кавычки в `grep`/`curl -w` → health давал «not ready» при HTTP 200. Фикс Dev: `cat > файл` из локального файла, не heredoc. ЗАПОМНИТЬ для будущих shell-скриптов через heredoc. +- **Прод цел:** StartedAt `2026-06-04T13:08:13Z` не менялся (Up 17h), 8500 ok. Файлы только новые, staging восстановлен, временные теги убраны. +- **Параметризация:** дефолт БЕЗОПАСНЫЙ (TARGET_SERVICE=orchestrator-staging, PORT=8501, profile staging). Прод поддержан через override env, но НЕ дефолт. Отдельный PREV_IMAGE_FILE для staging. + +### Этап 5 (ORCH-35) — последний, ПЛАН (ещё не спущен Dev) +- Цель: встроить стадию **`deploy-staging` ПЕРЕД `deploy-prod`** в конвейер (`src/stages.py`), тестер привязать к staging-эндпоинту 8501. +- ⚠️ **Самый рискованный этап:** трогает боевой конвейер деплоя, часть `src/` в off-limits. Перед спуском Dev — ЖИВАЯ разведка по коду стадий (как устроены deploy-стадии, точки встройки), показать план Славе. +- Из дизайна §4/§7: промоут с **ручным approve на старте** (`DEPLOY_REQUIRE_MANUAL_APPROVE=true`) — хук тормозит после зелёного staging, ждёт «go» Славы. Полный авто — позже. +- Из дизайна §6: агенты на staging — **гибрид C** (заглушки по умолчанию + full-real по флагу). Режима заглушек в коде ПОКА НЕТ (выяснено на Этапе 3) — возможно, понадобится на Этапе 5 или отдельной задачей. + +### Идентификаторы (обновление) +- main HEAD после Этапа 3 (PR #29 merged): `93169f1` +- PR #30 (Этап 4) — open, коммит `a6cbacb` +- Done state id (ORCH project): `3738cd3c-7610-4907-ba5e-26b9a248d9c0` +- ТЗ Этап 4: `tasks/orchestrator/DEV_TASK_ORCH34_DEPLOY_HOOK.md`; отчёт `tasks/orchestrator/reports/dev-2026-06-05-orch34-deploy-hook.md` +- Деплой-хук: `scripts/orchestrator-deploy-hook.sh`, образец enduro: `/home/slin/bin/enduro-deploy-hook.sh` diff --git a/tasks/orchestrator/DESIGN_STAGING_ENV.md b/tasks/orchestrator/DESIGN_STAGING_ENV.md index 1217f2d..73b566f 100644 --- a/tasks/orchestrator/DESIGN_STAGING_ENV.md +++ b/tasks/orchestrator/DESIGN_STAGING_ENV.md @@ -80,3 +80,17 @@ ## Открытые мелочи (уточнить по ходу, не блокеры) - N retry и timeout health-check прода (предлагаю 10 попыток × 6 сек = 60с). - Ресурсы хоста под постоянный staging-контейнер (лёгкий, но 24/7). + +## РАЗВЕДКА КОДА ДЛЯ ЭТАПА 5 (05.06, разведано Стрим) +**Архитектура стадий деплоя (как есть сейчас):** +- `stages.py` (54 стр, чистая декларация): `STAGE_TRANSITIONS` — цепочка `created→analysis→architecture→development→review→testing→deploy→done`. Стадия `deploy`: `{"next":"done","agent":"deployer","qg":"check_deploy_status"}`. +- `stage_engine.py` (24KB) — движок переходов. Строка ~525: БАГ-8 фикс — при `deployer` вердикте FAILED откат `deploy→development`. Строка ~260: terminal sync deploy→done форсит Plane в Done. +- `qg/checks.py:350` `_parse_deploy_status` — читает ТОЛЬКО `deploy_status:` из YAML-frontmatter `14-deploy-log.md` (SUCCESS→pass, FAILED→fail, нет поля→fail). `_deploy_log_from_main` (:374) — достаёт файл из `origin/main` (deployer мержит артефакты отдельным PR). +- **deployer-агент** (LLM) пишет вердикт в `docs/work-items//14-deploy-log.md`. Промпты deployer — в `src/agents/launcher.py` (НЕ отдельные файлы). +- ⚠️ **Реального docker-деплоя через хост-хук в коде НЕТ** — deployer-вердикт сейчас «бумажный» (LLM пишет SUCCESS/FAILED, но docker не дёргается). Хук ORCH-34 существует, но конвейер его пока не вызывает. + +**ПЛАН ЭТАПА 5 (ORCH-35) — встройка `deploy-staging`:** +- Вариант A (минимальный, безопасный, ПРЕДЛАГАЕМЫЙ): добавить стадию `deploy-staging` в `STAGE_TRANSITIONS` МЕЖДУ `testing` и `deploy` (`testing→deploy-staging→deploy→done`), со своим QG `check_staging_status` (по образцу `check_deploy_status`: парсит `staging_status:` из нового `XX-staging-log.md`). deployer-агент на этой стадии гоняет `staging_check.py` (из ORCH-33) против 8501 и пишет вердикт. При FAILED — откат на `development` (как deploy). Это «ворота»: прод-деплой (`deploy`) недостижим, пока staging-гейт не зелёный. +- Вариант B (полный, позже): стадия `deploy` реально дёргает хост-хук `orchestrator-deploy-hook.sh` через ssh с `DEPLOY_REQUIRE_MANUAL_APPROVE=true` (хук тормозит, ждёт «go» Славы). Это уже исполняемый самодеплой — отдельная осторожная задача после A. +- **off-limits Этапа 5:** НЕ ломать существующие QG (`check_deploy_status`, БАГ-8 rollback), `_parse_deploy_status`, terminal-sync deploy→done. Только ДОБАВИТЬ стадию+QG, не переписывать существующие. tests/ обновить под новую цепочку. +- **Решение по объёму Этапа 5 — за Славой:** делать сразу A+B (полный самодеплой с хуком) или только A (staging-гейт как ворота, без авто-дёрганья хука)? Рекомендация Стрим: **сначала A** (ворота-гейт, безопасно, тестируемо в песочнице), B — отдельным осознанным шагом.