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

57 lines
10 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.
## Документация сессии 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).