From ed668d40840bb13c0a3a968d433386b4e20ef134 Mon Sep 17 00:00:00 2001 From: Stream Date: Tue, 9 Jun 2026 01:10:01 +0300 Subject: [PATCH] auto-sync: 2026-06-09 01:10:01 --- memory/2026-06-08.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/memory/2026-06-08.md b/memory/2026-06-08.md index f2649b6..01b5520 100644 --- a/memory/2026-06-08.md +++ b/memory/2026-06-08.md @@ -413,6 +413,16 @@ - ✅ ORCH-81 разблокирована: analyst run_id=407 pid=241 запущен НА CLI 2.1.168 (первый запуск после фикса). Если CLI был корнем — отработает нормально (не зависнет). ORCH-85 можно закрывать (сделано вручную). - ✅✅ **ПОДТВЕРЖДЕНО: CLI был корнем.** analyst run 407 НА НОВОМ CLI отработал ЧИСТО: started 21:25 → finished 21:29, **exit_code=0, 4 мин** (не завис на 1800s как 405/406 на старом). BRD/ТЗ/AC эталонные. - **ORCH-082 BRD APPROVED (~00:36 MSK) → architect run_id=408.** Аналитик нашёл ТОЧНЫЙ root-cause (AC-1): PR создаётся ТОЛЬКО в `launcher._ensure_pr`, ТОЛЬКО при agent==developer + свежий коммит + push. developer-run без нового коммита (R-A) / тихий сбой (R-B) / разъехавшаяся ветка (R-C) → PR никогда не создаётся. Решение: `merge_gate.ensure_open_pr` (идемпотентно, base==main фильтр) врезан в _handle_merge_verify ПЕРЕД merge_pr + kill-switch + защита ORCH-073 ЦЕЛА (AC-4). 11 AC. +- **ORCH-082 ПРОШЛА В ПРОД (~22:03 UTC)** — баг ORCH-81 ИСПРАВЛЕН. 😂 ИРОНИЯ ДНЯ: задача про фикс merge-бага сама споткнулась о этот баг на своём деплое (PR #82 code open / PR #83 docs merged → защита ORCH-73 HOLD). Фикс ещё не был в main → ехал через старый баг. Смерджила code-PR #82 вручную (ПОСЛЕДНИЙ раз!) → finalizer → fix-commit 0ab6a33 IN_MAIN → done. Прод на новом коде (ensure_open_pr в контейнере =1). +- ✅ **ТЕПЕРЬ КОНВЕЙЕР СОЗДАЁТ PR САМ** — следующие задачи НЕ должны требовать ручного домерджа. Больше не лезть руками в PR. Карточка обновлена (18238, done). +- ⚠️ ПРОВЕРИТЬ НА СЛЕДУЮЩЕЙ ЗАДАЧЕ: деплой должен пройти БЕЗ ручного PR (ensure_open_pr создаст code-PR автоматически). Это финальная проверка фикса. + +## 🐛 ORCH-87 заведена — трекер-карточка застревает на To Analyse + сироты (08.06 ~22:00 UTC) +- Слава (скриншот): карточка ORCH-082 с заголовком «📍 To Analyse» при пройденном конвейере (все ✅ до Внедрения); статусы деплоя не отражены. +- **Корень:** режим bump (delete+send+repoint). render СЕЙЧАС правильный (Deploying/все стадии) — баг не в рендере. Карточка со скрина (18204) — ОСИРОТЕВШАЯ, застряла на первом рендере. bump хранит ТОЛЬКО последний message_id → при рассинхроне указателя (сбой send / рестарт орка / CLI-фикс) старые карточки осиротевают. Бот МОЖЕТ удалять (deleteMessage ok:true) — дело не в правах, а в потере ссылки. +- **Workaround:** удалила сирот 18204+18227, пересоздала свежую 18233 (верный заголовок Awaiting Deploy). +- seq=87 id=8572689a-7f16-493a-98d0-8f00269e3b68, Backlog, MEDIUM. G1 не оставлять сирот / G2 заголовок не застывает (edit vs bump?) / G3 deploy-статусы видимы. 5 AC. +- ⚡ **РАСШИРЕНА (Слава, 22:07): +2 требования.** (1) **G0 — СНАЧАЛА РАССЛЕДОВАНИЕ** (не фикс вслепую, НЕ принимать мой workaround-диагноз на веру): сколько реально сирот висело, в какие моменты tracker_message_id рассинхронится (send=None / рестарт / гонка / delete-fail), почему заголовок застывает, bump vs edit с ДАННЫМИ → ADR. (2) **ЭФФОРТ В КАРТОЧКУ:** сейчас строка стадии показывает модель, НО НЕ эффорт → добавить (напр. `opus-4-8 · xhigh`), источник — resolve_agent_effort или колонка agent_runs.effort (фактически применённый). PATCH 200. ## 📝 ORCH-86 заведена — reconciler шлёт шум «ET-002 done разблокирована» в Telegram (08.06 ~21:24 UTC, Слава: «приходит периодически, заводи исправление») - **Продолжение ORCH-068** (тот livelock-фикс done, но НЕ закрыл этот путь). seq=86 id=d8133fbe-d16f-4787-85a4-3cabec4338c2, Backlog, MEDIUM.