admin/wiki
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

auto-sync: 2026-06-07 12:30:01

Browse Source
This commit is contained in:
Stream
2026-06-07 12:30:01 +03:00
parent c864c74e57
commit 81bd820b32
1 changed files with 32 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
memory/2026-06-07.md
View File

@@ -149,3 +149,35 @@ Progress = relaunch developer-агента, а не просто re-check gate.*
**УРОК про Dev-агента:** конвейерный developer склонен к недожиму (написал тесты, не
дописал реализацию — TDD без доводки). Прямой Dev-агент с УЗКИМ ТЗ (точные строки, готовые
тесты как спека) надёжнее для доводки. Но финал мержа/деплоя — всё равно через конвейер с гейтами.
## ORCH-58 — раунд 3 (вариант А, staging_check) ДОЖАТ
**Развилка из ревью:** reviewer 3× дал REQUEST_CHANGES. P0 (deadlock AC-6, host-маппинг,
build из валид. worktree) исправлены в раунде 2 (commit `2ee06ae`). Осталось одно P1:
код↔ADR расхождение — режим `--build-staging` делал только `/health`-смок, а ADR/AC-4
требуют прогон `staging_check.py --mode stub` против СВЕЖЕГО 8501 (тот же артефакт, что
уезжает в прод). ADR явно относил health-only к «отклонённой оптимизации» → dev внедрил
молча отклонённую альтернативу. Reviewer честно сказал — это Owner-решение, не его.
**Слава выбрал Вариант (а)** — строго по ADR (страховка self-deploy прода дороже тихого
регресса). ТЗ: `temp/DEV_TASK_ORCH-058_staging_check.md`. Прямой Dev opus 4.8 (конвейерный
reviewer↔dev буксовал на этом, сам решение принять не мог).
**Dev внёс (commit `c53d625`, ветка feature/ORCH-058-...):** в блок `--build-staging` после
health, перед финальным exit — прогон `staging_check.py --mode stub` против 8501, fail-closed
(провал → exit 1, артефакт НЕ промоутится в прод). Умный момент: запускает **внутри
контейнера** (`docker exec orchestrator-staging`), т.к. с хоста `ORCH_PROJECTS_JSON` не
выставлен → был бы ложный FAIL. staging_check бьёт ТОЛЬКО 8501, никогда 8500 (AC-9).
**Проверка независимая:** CI зелёный (`c53d625`), 630 passed (provenance 7 passed). Реально.
Вернула ORCH-58 в конвейер на re-review — единственное P1-замечание ревьюера закрыто строго
по ADR → должен дать approve.
**УРОК:** конвейерный reviewer↔dev НЕ умеет принимать Owner/архитектурные решения (код vs
ADR-развилка) — крутит REQUEST_CHANGES по кругу, пока человек не выберет. На таких развилках
— вытащить решение у Славы → прямой Dev с узким ТЗ → вернуть в конвейер. Не ждать, что
конвейер «сам додумается».
**Статус конца сессии:** ORCH-58 в конвейере на re-review (после c53d625). Дальше: reviewer
approve → Testing → merge-gate → deploy. На deploy-стадии — апрув Славы (как ORCH-36).