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

38 lines
5.9 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.