Files
wiki/memory/2026-06-06.md
2026-06-06 10:50:01 +03:00

82 lines
16 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 2026-06-06
## ORCH-46 запущен конвейером (вариант A) — 04:06 UTC
- Слава выбрал **вариант A** («вклеить findings», минимальный), велел сделать **автономно** (вести до конца как ORCH-47, дёргать только если упрётся в его решение).
- ТЗ: `tasks/orchestrator/DEV_TASK_ORCH-046.md` (3 варианта дизайна, выбран A). Описание варианта A залито в Plane ORCH-46 (заголовок укорочен 120→77 символов под QG-0).
- **Суть A:** в `src/stage_engine.py` встраивать ТЕКСТ замечаний в task_desc деву (не только ссылку):
- reviewer REQUEST_CHANGES (~стр.419): парсить `## Findings` из 12-review.md → вынуть P0/P1 дословно
- tester FAIL (~стр.455): вынуть reason + фрагмент 13-test-report.md
- новый хелпер-парсер (graceful, never raise, fallback на ссылку)
- НЕ трогать: гейты check_* (ORCH-45/47), QG-реестр, retry/rollback-логику, webhook-пути.
- **task 37**, ветка `feature/ORCH-046-stage-engine-pass-reviewer-tes`, analyst run 139.
- **ПЛАН (автономно):** дать конвейеру пройти analyst→arch→dev→review→testing→deploy-staging.
- Это правка ЯДРА → следить внимательнее. На BRD-апруве задача встанет ждать Approved Славы (by design) — НЕ забыть, что на BRD нужен человек.
- Возможные затыки: (1) BRD-апрув ждёт Славу; (2) staging B6 isolation FAIL (как у ORCH-47 — не блокер кода, но даст FAILED на deploy-staging); (3) если петля dev↔review — теперь должна быть короче, т.к. фикс про передачу findings.
- Финал: ручной merge + ребилд прода (build образа + рестарт + claude-auth check) — по накатанному из LESSONS_2026-06-05.md.
## ✅ ORCH-46 ЗАКРЫТА (вариант A, автономно по доверию Славы) — 04:50 UTC
- Слава дал «вариант В» = вести совсем без остановок, апрув BRD за него.
- **Прошёл конвейером БЕЗ ЕДИНОЙ ПЕТЛИ** (иронично — задача про устранение петель): analysis→architecture→development→review (APPROVED с 1 раза)→testing (check_tests_passed принял result:PASS)→deploy-staging. Дев=1 заход.
- **BRD-апрув не понадобился:** задача стартовала через In Progress (а не Backlog) → это и есть Approved-эквивалент входа, BRD-гейт не застопорил (analysis→architecture auto-advance).
- **Реализация (проверила лично):** новый `src/review_parse.py` (extract_review_findings/extract_test_failures, never raise, graceful fallback на ссылку), `stage_engine.py` +37/-6 — вклеивает `Findings (P0/P1):` дословно деву + `Причина: {reason}` для tester. Критичная логика (retry/rollback/QG-реестр/гейты) НЕ тронута. ADR-001 «embed-findings-in-task-desc». 50 тестов passed.
- **Merge PR #43** (`0bc23984`), деплой (chown+reset+build+up+health+auth-check) — review_parse активен в /app, claude-auth жив.
- **Staging FAIL = тот же B6/ORCH-48** (sandbox=NO, prod-ET/ORCH=YES) — деплоер сам в triage-note указал: `ORCH_PROJECTS_JSON` staging смотрит на прод. К коду ORCH-46 отношения НЕТ (9/10 PASS). Решение как с ORCH-47: код в прод, B6 отдельно.
- ✅ Plane ORCH-046 → Done; task37 → done в БД.
## Состояние прод-гейтов/ядра после ORCH-46:
- ✅ check_ci_green — поллинг (ORCH-45)
- ✅ check_tests_passed — читает result: (ORCH-47)
- ✅ stage_engine — передаёт деву ТЕКСТ findings, не только ссылку (ORCH-46)
- Бэклог high: **ORCH-48/B6** (staging registry isolation — теперь стоит поднять приоритет: блокирует автономный deploy-staging у ВСЕХ ORCH-задач!), ORCH-44 (надёжность запуска агента)
## ORCH-48 / B6 — ROOT CAUSE найден (05:00 UTC) — баг в ТЕСТЕ, не в инфре
- Деплоер думал: misconfig staging-контейнера (ORCH_PROJECTS_JSON смотрит на прод). **НЕВЕРНО.**
- **Факт (проверено прямым запуском в orchestrator-staging):** `known_plane_project_ids()` отдаёт count=1, sandbox=True, ET=False, ORCH=False. `.env.staging` УЖЕ правильно задаёт ORCH_PROJECTS_JSON=только sandbox. **Изоляция реестра в staging работает идеально.**
- **Баг — в самом B6-чеке** `scripts/staging_check.py` (стр.263+): делает `sys.path.insert(0,"/repos/orchestrator")` + import `src.projects` из ХОСТ-worktree (где env НЕ staging) → `importlib.reload` подхватывает env процесса harness, а не staging-контейнера → читается built-in _DEFAULT_PROJECTS (ET+ORCH) → ложный FAIL.
- **Решение ORCH-48:** B6 должен проверять реестр ВНУТРИ staging-контейнера (его env), а не импортить из host-worktree. Правка кода `scripts/staging_check.py` → подходит для конвейера.
- Built-in default registry (`src/projects.py` _DEFAULT_PROJECTS) = ET+ORCH — он и подхватывался при пустом env у harness.
## Приоритизация ORCH-46 vs ORCH-48 (утро 06.06) — для контекста
- Слава утром спросил «что первым: ORCH-46 или ORCH-48». Рекомендовала ORCH-46 первой (корень ручного пинания задач: «испорченный телефон» dev↔review, нет передачи текста findings, нет памяти между кругами). → Взяли ORCH-46, закрыли (см. выше).
- **Следующая по логике — ORCH-48/B6** (root cause уже найден, см. блок выше): правка `scripts/staging_check.py`, чтобы B6 проверял реестр ВНУТРИ staging-контейнера, а не импортил `src.projects` из host-worktree. Это разблокирует автономный deploy-staging для ВСЕХ ORCH-задач (сейчас у всех ложный FAIL на B6).
- Прочий бэклог high: ORCH-44 (надёжность запуска агента).
## ORCH-48 переигран на вариант (в) (06:56 UTC) — по решению Славы
- Первый прогон: архитектор выбрал **вариант (а)** (HTTP-эндпоинт `GET /projects`), дев написал код, конвейер прошёл БЕЗ петель (analyst→…→deployer все exit 0) → **deploy-staging FAILED** → откат на development.
- Причина FAIL = **курица-яйцо варианта (а):** B6 ходит на `/projects` работающего staging-инстанса, а эндпоинт запечён в образ → в текущем образе его НЕТ (404 на 8501 и 8500 проверено) → ложный FAIL. Требует ручного bootstrap-деплоя. Это класс поломки автономности.
- **Слава выбрал вариант (в)** («запуск suite ВНУТРИ контейнера, без HTTP-эндпоинта») — принципиально без курицы-яйца ни сейчас, ни в будущем.
- **Переигровка (сделала):** (1) `git reset --hard 8b5b1f0` ветки до analyst-артефактов (стёрла ADR(а) `f77825b` + код(а) `2cf873a` + reviewer/tester auto-commits), force-push; (2) встроила в `02-trz.md §4` блок «РЕШЕНИЕ ПРИНЯТО ВЛАДЕЛЬЦЕМ: вариант (в)» с обоснованием + что обязан зафиксировать архитектор (убрать host-path хак, запуск через `docker exec`, синхронно править `deployer.md`+`STAGING_CHECK.md`, чистая `_evaluate_b6`, НЕ трогать прод-main/projects/.env), коммит `7a6c7a0`; (3) `update_task_stage(38,"architecture")` + `enqueue_job(architect)` через `/tmp/replay_arch.py` с guard'ами (agent_running=None, нет активных jobs). job 91, run 151 architect стартовал 06:56.
- ⚠️ Существует PR #45 на эту ветку (открыт при работе под (а)) — после переигровки указывает на пересобранную ветку. Не мержить раньше прохождения staging.
- **Топология (для архитектора в ADR):** Dockerfile НЕ копирует `scripts/` в образ → `staging_check.py` только через mount `/repos/orchestrator/scripts/...`, путь запуска внутри контейнера учесть.
- **План автономно:** довести arch→dev→review→testing→deploy-staging. Теперь staging должен пройти САМ (в варианте (в) bootstrap не нужен). Финал — merge PR + ребилд прода по LESSONS_2026-06-05.
## ✅ ORCH-48 ЗАКРЫТА на варианте (в) (07:12 UTC) — идеально, без петель, без касания прода
- Переигровка прошла arch→dev→review→tester (runs 151-154, все exit 0) БЕЗ петель.
- **Архитектор зафиксировал (в)** (ADR `ADR-001-b6-registry-via-in-container-run.md`): host-path хак убран, чистая `_evaluate_b6(known)->(bool,str)`, запуск suite через `docker exec orchestrator-staging`, `/projects`-эндпоинт НЕ добавлен, прод-`src/main.py` НЕ тронут.
- **deploy-staging: `staging_status: SUCCESS, 10/10 PASS`** — ГЛАВНОЕ: **B6 ✓ PASS** `[sandbox=YES, prod-ET=NO, prod-ORCH=NO]` САМ, без bootstrap. Деплоер запускал suite ВНУТРИ контейнера через docker.sock (CLI в env агента нет) → B6 читает реестр из env staging-инстанса.
- **Стадия deploy:** деплоер `deploy_status: SUCCESS`, restart/rebuild **не требовался и НЕ делался** (изменения только в bind-mounted `scripts/`+`deployer.md`+доки, `src/` и Dockerfile не тронуты). Прод-контейнер 8500 НЕ тронут (zero group-risk для ET).
- **Финальный merge (сделала вручную):** орк сам смержил только логи (PR #47/#48), а сам фикс-код остался в feature-ветке (by design — фичу мержит владелец). Смержила **PR #45** (`2a36ed80`) feature→main.
- **Rollout:** `git pull` host-репо `/home/slin/repos/orchestrator` (владелец slin, sudo НЕ нужен — репо чистое) → HEAD `2a36ed8`. Проверено в живом bind-mount: `_evaluate_b6`=3, host-path хак=0, `deployer.md` docker exec=1.
- ✅ Plane ORCH-048 → Done; task38 → done; prod-8500 health=200, staging-8501 health=200.
- **УРОК:** орк закрывает задачу в done и мержит ТОЛЬКО логи (15-staging/14-deploy) — **сам фикс-код в main НЕ вливается автоматически**. Финальный merge feature-PR в main + host `git pull` — ручной шаг владельца. Проверять `git log origin/main..feature` ПЕРЕД тем как считать задачу закрытой.
## Состояние прод-гейтов/ядра после ORCH-48 (обновлено):
- ✅ check_ci_green — поллинг (ORCH-45)
- ✅ check_tests_passed — читает result: (ORCH-47)
- ✅ stage_engine — передаёт деву ТЕКСТ findings (ORCH-46)
- ✅ B6 staging-чек — читает реестр ВНУТРИ staging-контейнера, больше НЕ ложный FAIL (ORCH-48) → deploy-staging разблокирован для ВСЕХ ORCH-задач!
- Бэклог: ORCH-44 (надёжность запуска агента)
## ORCH-44 запущен конвейером (07:39 UTC) — надёжность запуска агента
- **Три проблемы** (инцидент ORCH-17 05.06, застряла ~30мин): П1 preflight слеп к auth (`claude --version` отвечает даже при Not logged in); П2 `--effort`+`--print`+json → пустой stdout; П3 пустой лог трактуется как успех/висит.
- **Разведка (сделала перед запуском):** `preflight.py` — только exists+`--version` (явный коммент «deliberately no prompt ping»). Бинарь `AgentLauncher.CLAUDE_BIN=/opt/claude-code/bin/claude.exe`. Реальные креды `/home/slin/.claude/.credentials.json` (`claudeAiOauth.expiresAt`). cmd сборка launcher.py стр.305-307 (`--print --output-format json {effort_flag}`), `_monitor_agent` стр.460 (ключ по exit_code, не по содержимому). queue claim-gating стр.154-164.
- **РЕШЕНИЕ СЛАВЫ:** П1 = ОБА (🅾): preflight упреждающе читает cred-файл (exists+читаемо+expiresAt в будущем) + `_monitor_agent` постфактум ловит 'Not logged in' → breaker+failed. П3 = делать (пустой лог/нет result-JSON → job failed, не вечный running). **П2 ВНЕ SCOPE** — effort НУЖЕН и работает, НЕ убирать как unsupported; хотфикс `ORCH_AGENT_EFFORT_*=\"\"` оставить, полный возврат → отдельная задача.
- **Создана ORCH-50** (Backlog, не автостарт): «Эффорт агентов: заставить --effort работать с --print/json» — разведка комбинаций флагов, вернуть effort в прод без потери result-JSON.
- **Запуск:** описание ORCH-44 дополнено блоком «РЕШЕНИЕ ВЛАДЕЛЬЦА» → In Progress (e331bfb3) → webhook `handle_status_start``start_pipeline`. **task 39 ORCH-044**, ветка `feature/ORCH-044-preflight-auth-effort`, analyst run 157.
- **Веду автономно** (как 46/48). Грабли на радаре: это правка КРИТИЧНОЙ launcher/preflight-логики — следить внимательно; staging B6 теперь должен пройти (ORCH-48). Финал: merge feature-PR (НЕ только логи! урок ORCH-48) + host git pull; если тронет `src/` → ребилд прода только с ОК Славы (общий ET+ORCH).
## Документация сессии 05.06 — финал (подтверждено)
- `docs/history/LESSONS_2026-06-05.md` в main орка через **PR #42** (`615a778d`), подтверждено `OK-IN-MAIN`.
- Внутри: постмортем ORCH-17/45/47, уловка-22 ORCH-47 (гейт чинит сам себя), памятка деплоя прода (`/app` запечён в образ → нужен `build`; порты 8500/8501; полная последовательность chown+reset+build+up+health+auth-check), грабли с root-owned файлами (рассинхрон git).