auto-sync: 2026-06-05 09:50:01

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/<id>/members/` с телом `{"member": <user_id>, "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`

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/<wi>/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 — отдельным осознанным шагом.