496 lines
108 KiB
Markdown
496 lines
108 KiB
Markdown
# 2026-06-08 — Дневник
|
||
|
||
## 🎯 ORCH-66 (статусная модель) доехала до прода САМА — историческое
|
||
- ORCH-66 = новая статусная модель (Plane-статусы: To Analyse / Analysis / Code-Review / Awaiting Deploy / Deploy / Done + In Review для approve-pending).
|
||
- **Прошла весь конвейер автономно**: analyst→architect→dev→reviewer→tester→staging→Phase A. CI зелёный, merge-gate пройден, staging пересобран (`bc2347ab`).
|
||
- Стояла на `In Review` = approval-pending прода, ждала **Confirm Deploy** Славы. Символично: статусная модель первой пошла в прод сама.
|
||
|
||
## 🟢 ORCH-67 заведена — Telegram tracker багфикс+enhancement (seq=67, id=34a8440d-4024-41fa-bf6e-398937e23dee)
|
||
ТЗ загружено в Plane как HTML (5458 симв.). Зависит от ORCH-66 (статусные имена) → запускать ПОСЛЕ прода ORCH-66. 4 требования:
|
||
1. **Bump заработал** — причина бага найдена и НЕ в коде: bump-логика (`delete + send + repoint`) корректна, но в проде `tracker_mode = "edit"` (дефолт `config.py:345`). Env `ORCH_TRACKER_MODE=bump` не выставлен → режим edit (карточка остаётся вверху). Фикс: включить bump + сделать дефолтом.
|
||
2. **Формат карточки со статусами как в Plane** — показывать Plane-статус этапа.
|
||
3. **Номер задачи (ORCH-NN) — гиперссылка** на страницу задачи в Plane, внутри карточки.
|
||
4. **Во ВСЕХ уведомлениях орка** номер задачи тоже кликабельный → ведёт в Plane.
|
||
- Уточнение Славы (учтено в ТЗ): **ожидание согласования BRD = Plane-статус `In Review`** (⏸️ approve-pending между Analysis и Architecture). Отразить как полноценный статус, не только строкой «⏸️ Подтверждение BRD ⏳».
|
||
|
||
## 🔧 Технические факты по notifications.py / tracker (для будущих задач)
|
||
- `update_task_tracker(task_id)` — два режима через `Settings.tracker_mode` (env `ORCH_TRACKER_MODE`), case-insensitive; всё кроме `"bump"` → `"edit"`. Оба держат инвариант «одна карточка на задачу».
|
||
- **edit (DEFAULT):** первый вызов sendMessage (silent) + store message_id; далее editMessageText.
|
||
- **bump (ORCH-042):** delete старого → send нового внизу → repoint message_id.
|
||
- **`parse_mode: HTML` уже включён** в send/edit → гиперссылки `<a href>` делаются без изменения транспорта.
|
||
- `render_task_tracker(task_id)` — stateless рендер из БД: строка `✅ <Stage> <dur> · <in>↓/<out>↑ · <cost> · <model>` на этап + строка `✅/⏸️ Подтверждение BRD <dur> · твоё время[ ⏳]` между Analysis/Architecture.
|
||
- `send_telegram(text, disable_notification)` → возвращает message_id; `delete_telegram(message_id)`; есть список Telegram-ошибок «target уже отсутствует» (message_id_invalid и т.п.).
|
||
|
||
## 🔗 URL/env факты (env орка)
|
||
- `ORCH_GITEA_PUBLIC_URL=https://git.mva154.duckdns.org`
|
||
- **НЕТ публичного Plane-URL в env орка** — для гиперссылок нужен базовый URL `https://plane.mva154.duckdns.org`. Заложено в ТЗ ORCH-67 как новый конфиг.
|
||
- project_id: **ORCH = `8da6aa25-a60e-44d6-a1e2-d8ae59aa7d6a`**, Sandbox = `8c5a3025-4f9d-4190-b79f-fa06276bb27e`.
|
||
- `ORCH_PLANE_WEBHOOK_SECRET=e7d95e…8b16`.
|
||
|
||
## 🐛 ORCH-68 root-cause: livelock reconciler = РЕГРЕССИЯ от ORCH-66 (Слава угадал)
|
||
- Слава: «это началось после внедрения 66ой» — подтверждено логами минута-в-минуту:
|
||
- `22:17:04.019` рестарт после прод-деплоя ORCH-66 → `Reconciler started (interval=120s)`
|
||
- `22:17:04.207` (через 0.2с) первый `ET-002 done разблокирована` — ДО 22:17 этого лога не было ever.
|
||
- `22:18:33` `Task 52: deploy->done (self)` (ORCH-66 задеплоил себя). Спам каждые 120с, 191+ сообщений.
|
||
- Механизм: ORCH-66 ввела новую статусную модель (имена Done/Monitoring after Deploy). Reconciler сверяет локальную стадию↔Plane-статус; новые имена сломали сравнение терминальных → ET-002 (done/Done = синхронизирована) каждый тик считается «потерян webhook» → `_note_unblock` вхолостую (no-op, токены НЕ тратятся, но спам + нарушает инвариант «fires only on actual state change»).
|
||
- Чинить в `src/reconciler.py`: маппинг терминальных/пост-деплойных статусов привести к новой модели; done+Done не должен триггерить unblock.
|
||
- Root-cause-блок дописан в Plane ORCH-68 (seq=68, id=70fd4d24-4241-4dd5-9245-11e629a3fc60), HTML 3603→5419.
|
||
- ⚠️ Грабли: чуть не дописала root-cause в ЧУЖУЮ задачу seq=60 «Reconciler не должен трогать escalated» (тоже про reconciler) — поймала, откатила (вернула 549 симв.). **Plane seq≠work_item_id; искать issue по полному списку и сверять название, не по ключевому слову.**
|
||
- ⚠️ Plane API: ручной urllib через двойной SSH+docker молчит/не отдаёт JSON. Рабочий путь — использовать модули орка `src/plane_sync.py` (`PLANE_BASE`, `WORKSPACE`, `PLANE_HEADERS`, httpx) внутри контейнера через файл-скрипт + `docker cp`. PATCH `description_html` работает (200).
|
||
|
||
## 🚀 ORCH-68 ЗАПУЩЕНА в работу (04:45 UTC) + архитектурный ответ
|
||
- Слава: «68 срочно запускай. Правильно ли ориентироваться на статус Plane?»
|
||
- **Ответ: ДА, ориентир на Plane корректен по дизайну.** Таблица `tasks` не имеет status-колонки (reconciler.py:201 «live Plane state is the source of truth»). F-2 обязан опрашивать Plane и реплеить пропущенные вебхуки — это сердце автономности.
|
||
- **Баг — в МАППИНГЕ, не в идее:** `_reconcile_plane_project` тянет `list_issues_by_state(pid, [to_analyse, approved, rejected])`. ET-002 в Plane=`Done` — её не должно быть в выборке. На **enduro** `get_project_states` схлопывает статусы (reconciler.py:209-211) → `Done` алиасится под `approved` UUID → ветка «Approved but stage never advanced → replay verdict» → `_note_unblock` каждый тик.
|
||
- **Ключевая находка:** у проекта **orchestrator** `Done`=group=`completed`, `Approved`=group=`started` (разные UUID, НЕ склеены). На enduro — склеены. ⚠️ Правильный фикс: использовать **`state.group == "completed"`** для терминала, а не голый UUID-маппинг. Заложено в ТЗ.
|
||
- **Старт:** Plane-статус ORCH-68 → `To Analyse` (UUID `8acc6109-934e-4cd5-954b-7495672f520c`) = триггер конвейера.
|
||
- **QG-0 завернул первый раз:** заголовок >80 симв. → задача ушла в `Blocked`. Укоротила до 60 симв («BUG: reconciler livelock — спам unblock done-задачи (ET-002)») → Backlog → To Analyse → пошла. **Урок: заголовок Plane-задачи для орка — <=80 символов (QG-0 hard check).**
|
||
- **Сейчас:** task 53, ORCH-068, stage=analysis; **job 378 analyst running** (pid 3332), ветка `feature/ORCH-068-bug-reconciler-livelock-unbloc`. Аналитик получил полное ТЗ + root-cause + архитектурное уточнение.
|
||
- ТЗ ORCH-68 в Plane: 5428→7007 симв (добавлен архитектурный блок).
|
||
|
||
## ✅ ORCH-68 BRD Approved (04:52 UTC) → analysis→architecture (архитектор run_id=347)
|
||
- Аналитик выдал 4 артефакта (BRD/ТЗ/AC/test-plan) в `docs/work-items/ORCH-068/`. Проверила все — эталонная работа.
|
||
- **Аналитик углубил мой root-cause:** разделил баг на 2 независимых дефекта: **D1** (терминалы не исключены из actionable-выборки) + **D2** (`_note_unblock` зовётся безусловно после no-op dispatch, нарушает свой docstring). D2 — мина, которую я пропустила.
|
||
- **Захватил связанный баг кэша:** `_STATES_CACHE` живёт весь lifetime, `reload_project_states()` есть но не вызывается — именно из-за этого Слава рестартил орк после создания `Confirm Deploy`. Поймали заодно (G5/AC-12, secondary).
|
||
- Plane-статусы переходов: To Analyse → Analysis (`cb834d55`) → In Review (`c52e99b9`, approve-pending BRD) → Approved (`63f2c8fe`) → Architecture (`795cc32f`). UUID approved для ORCH = `63f2c8fe-dcda-4ace-952f-dd88bd0118ff`.
|
||
- Решение «state.group vs allowlist» правильно оставлено архитектору в ADR.
|
||
|
||
## 🟢 ORCH-69 заведена и запущена (05:09 UTC) — QG-0 title-лимит в параметр
|
||
- Решение Славы: «заведи задачу, сделаем как параметр, 200 по умолчанию».
|
||
- **Предыстория:** выяснили что 80 в QG-0 — НЕ техническое ограничение. Проверила все места ниже по течению: slug ветки `re.sub(...)[:30]` (webhooks/plane.py:488) режется независимо + выкидывает кириллицу ([^a-z0-9]→дефис); БД `title TEXT` без лимита; Telegram-карточка `html.escape(title)` без обрезки; worktree-путь по branch (=work_item_id+slug[:30]), не по title. Расширять безопасно.
|
||
- **ORCH-69** (seq=69, id=35338a57-d905-4958-b70c-fa1afd66110f): новый `ORCH_QG0_TITLE_MAX` (дефолт 200) в config.py, `_qg0_errors` читает из settings, текст ошибки динамичный. Нижние лимиты (title<5, desc<20) НЕ трогать. Аддитивно/обратносовместимо (200>80).
|
||
- Запущена: stage=analysis, ветка `feature/ORCH-069-qg-0-title-orch-qg0-title-max-`. ⚠️ Обе (68 и 69) трогают `webhooks/plane.py` — следить за merge-конфликтом (merge-gate должен поймать, но держать в голове).
|
||
|
||
## 🎉 ORCH-68 В ПРОДЕ — орк сам себя починил (05:32 UTC, self-deploy)
|
||
- ORCH-68 прошла весь конвейер автономно и задеплоилась в прод. Статус → Done (`3738cd3c`), post-deploy monitor HEALTHY.
|
||
- ✅ **Спам ET-002 = 0** после деплоя (было 191+). Фикс боевой.
|
||
- ✅ Код в проде: `_is_terminal_state`, `get_project_state_groups`, `skipped_terminal_total` — D1 через `state.group` (ровно как хотели).
|
||
|
||
## 🔴 БАГ ORCH-70: `Confirm Deploy` НЕ триггерит Phase B (мёртвый триггер, регрессия ORCH-66)
|
||
- **Инцидент:** Слава нажал статус `Confirm Deploy` для прод-деплоя ORCH-68 → орк `no pipeline action`. Деплой пошёл только после ручного перевода в `Approved`.
|
||
- **Root cause:** диспетчер `handle_issue_status` (webhooks/plane.py ~158-166) слушает ТОЛЬКО `to_analyse/approved/rejected`. Phase B (stage_engine.py ~215-224) триггерится по `Approved`. `Confirm Deploy` (008597eb) не в тройке → молчит. ORCH-66 добавила статус как **метку (запись)**, но не подключила **обратный путь (чтение/триггер)**.
|
||
- **Почему не поймали:** (1) не в scope ORCH-68 (она чинит reconciler, явно N1-N3 «Phase B не трогать»); (2) дыра ORCH-66 — тесты проверяли ЗАПИСЬ статуса, не ОБРАТНЫЙ триггер; (3) staging не покрывает прод-путь — ручной `Confirm Deploy` живёт только на проде (Phase A staging автоматический).
|
||
- **Урок:** тестировать ОБРАТНЫЙ путь статусов (нажатие → действие), не только запись. Новый статус = подключить в обе стороны. Прод-only пути нуждаются в явном тесте.
|
||
- **Записано в репу орка:** `docs/history/LESSONS_2026-06-08_confirm-deploy-deadtrigger.md` (коммит main, sha 101bd1c5, через Gitea Contents API).
|
||
- **ORCH-70** заведена (seq=70, id=bfbc924f-b808-4f7b-87d4-88ac5e976240), Backlog. Цель: `Confirm Deploy` триггерит Phase B + регресс-тест обратного пути. Не запущена — ждёт решения Славы по очереди.
|
||
- **Gitea для коммитов в репу орка:** `ORCH_GITEA_URL=http://localhost:3000`, owner=`admin`, repo=`orchestrator`, token `ORCH_GITEA_TOKEN` (env контейнера). Contents API: GET→sha→PUT/POST base64.
|
||
|
||
## 🚨 КРИТ: ФАНТОМНЫЙ MERGE — прод расходится с main, 4 PR не слиты (08.06)
|
||
- **Симптом:** ORCH-67 в To Analyse не подхватился. Причина — прод слушает `in_progress` (старый диспетчер), а не `to_analyse` (ORCH-66).
|
||
- **Диагноз (подтверждён md5 + git + PR-статус):** PR#67(022)/68(059)/69(066)/70(068) — ВСЕ **open, merged=False**. Последний реально слитый — PR#66 (ORCH-065, bb03350).
|
||
- **md5-сверка:** прод reconciler.py/plane_sync.py == ветка ORCH-068 (≠ main). Прод = снимок ветки ORCH-068, НЕ main.
|
||
- **Механизм (Слава угадал — «деплоилась старая версия»):** ветка ORCH-068 срезана от `bb03350` (ORCH-065), А НЕ от кода ORCH-066. В истории ветки-068 по ORCH-066 только `docs staging`, не код (`to_analyse`=0 в ветке-068). Т.е. деплой 068 взял worktree от устаревшего main (065) + фикс reconciler → откатил статусную модель 66 из прода.
|
||
- **Таймлайн ET-002:** 22:17 деплой ветки-066 (сломанный reconciler) → спам начался. 05:32 деплой ветки-068 (фикс livelock, но база 065 без 66) → спам=0 после 05:33. Подтверждает: код 66 БЫЛ в проде 22:17-05:32, потом стёрт деплоем 068.
|
||
- **КОРЕНЬ:** self-deploy Phase B собирает образ из ВЕТКИ (срезанной от main) + рапортует finalize SUCCESS, НО git-merge в main не отрабатывает (фантом). → следующая задача срезается от устаревшего main → теряет код незалитых предшественников. Накопительная потеря 022→059→066→068.
|
||
- **Подозрение:** регресс фикса ORCH-065 (idempotent merge / merge-lease) ЛИБО merge-step после него молчит. ORCH-065 — последний честный merge.
|
||
- **Ребейз origin/feature/ORCH-066-plane на origin/main — ЧИСТЫЙ** (конфликтов нет, git разрулил reconciler.py/plane_sync.py — разные места). НО простое слияние 66 затрёт фикс 68 → нужна цепочка 022→059→066→068.
|
||
- **РЕШЕНИЕ Славы: «запускай сама, документируй, запиши урок»** — выполняю.
|
||
|
||
## 🔧 ВОССТАНОВЛЕНИЕ main (08.06, автономно)
|
||
- **Находка по ходу:** ORCH-059 = `feat(deploy): Confirm Deploy status triggers prod deploy` — **уже реализует то, что я заводила как ORCH-70!** `handle_confirm_deploy` написан в 059, просто не слит (фантом). → ORCH-70 после долива 059 пересмотреть (останется только display-слой Monitoring after Deploy).
|
||
- **Матрица src-пересечений:** 022(config/qg/security_gate/stage_engine), 059(plane_sync/stage_engine/webhooks), 066(plane_sync/reconciler/stage_engine/webhooks), 068(config/plane_sync/reconciler). Порядок цепочки 022→059→066→068 (= хронология PR 67<68<69<70).
|
||
- **Интеграционная ветка** `integ/restore-main-2026-06-08` (worktree `/tmp/integ_chain` в контейнере): 022+059+066 слиты чисто (docs union). На 068 — код-конфликт reconciler.py (066 to_analyse vs 068 in_progress+D1/D2). Разрешение: каркас 068 + триггер to_analyse 066.
|
||
- **Урок в репу:** `docs/history/LESSONS_2026-06-08_phantom-merge.md` (sha 772ccab, CRITICAL постмортем + runbook диагностики).
|
||
- **Критбаг ORCH-71** (seq=71, id=017daf29) — root-fix фантома: верификация merge после деплоя + done-гейт по PR.merged + merge до рестарта контейнера. Backlog.
|
||
- **Диагностический runbook (4 проверки фантома):** (a) Gitea PR merged-флаги, (b) md5 prod vs `git show origin/main:<file>`, (c) merge-base ветки vs main, (d) таймлайн деплой-логов.
|
||
- ⚠️ **БЛОКЕР:** Dev-агент (vibecode/claude-sonnet-4.6) упал на billing error (кредиты исчерпаны, 0 токенов). Конфликт reconciler.py НЕ разрешён. ТЗ готово: `/tmp/DEV_TASK_merge_066_068.md`. Нужен перезапуск Dev на другой модели.
|
||
|
||
## 🔍 АУДИТ статусной модели ORCH-66 (08.06) — 7 статусов-призраков
|
||
- В Plane заведен **21 статус**, код (`_PLANE_NAME_TO_KEY`, plane_sync.py ~119) знает только **14**. Не подключены: Analysis, Code-Review, Awaiting Deploy, Confirm Deploy, Deploying, Monitoring after Deploy (+ To Analyse через отдельный alias).
|
||
- **Мёртвый код:** `set_issue_awaiting_deploy/deploying/monitoring` ОПРЕДЕЛЕНЫ (plane_sync.py ~652-679) но НИГДЕ не вызываются (grep пуст).
|
||
- `_STAGE_TO_STATE_KEY` ставит СТАРЫЕ статусы: analysis→in_progress (не Analysis), review→review (не Code-Review), deploy→in_progress (не Awaiting Deploy).
|
||
- `Monitoring after Deploy` (97b4a6cf) создан, но post-deploy окно идёт ПОВЕРХ Done (stage_engine.py:356 «arm monitor PAST done») → задача показывает Done, хотя ~15мин под наблюдением (это и есть «почему Done» Славы).
|
||
- **Вывод:** ORCH-66 ввела красивую модель на доске, но деплойная под-модель (Awaiting Deploy→Confirm Deploy→Deploying→Monitoring) — декоративная, код её не использует.
|
||
- **ORCH-70 расширена** (3725→7027): с одного Confirm Deploy до всей деплойной под-модели (G4-G7): подключить статусы, заполнить name→key, привести stage→state, убрать/задействовать мёртвый код. Порядок actionable vs display-only — архитектору в ADR.
|
||
|
||
## ⚠️ QG-0 — правила заголовка/описания Plane-задач для орка (важно!)
|
||
- **QG-0** = первый quality gate конвейера, функция `_qg0_errors(name, description)` в `src/webhooks/plane.py:366`. Проверяет **заголовок (name) и описание** до старта аналитика.
|
||
- Три проверки: **Title ≥ 5**, **Title ≤ 80** (хардкод, без конфига), **Description ≥ 20** символов (`.strip()`). `len()` по Unicode-символам (кириллица = 1 символ, не байт).
|
||
- **soft vs hard:** при `work_item.created` — soft (только warning, стр.362). При старте конвейера (`Status->In Progress`) — **hard** (стр.435-457): блокирует и кидает в `Blocked`. Вот почему создаётся ок, а при запуске заворачивает.
|
||
- 🔑 **ПРАВИЛО: заголовок Plane-задачи для орка — короткий тайтл ≤ 80 символов, вся детализация — в description.** Не впихивать описание в заголовок (моя привычка — забываю). Дважды наступила 08.06 (ORCH-67/68).
|
||
- ⚡ Возможный QoL-фикс (предложила Славе, ждёт решения): авто-обрезка заголовка до 80 («…») вместо блокировки, или вынести лимит 80 в конфиг.
|
||
|
||
## 📝 Грабли инструмента edit (зафиксировать)
|
||
- `edit` требует строго: `path` + `edits` (массив), каждый элемент только `{oldText, newText}` — никаких лишних полей. `oldText` должен совпадать дословно (включая пробелы/переводы строк). Несколько фейлов за сессию из-за неверной формы аргументов и неточного oldText.
|
||
- `image` (vibecode/claude-sonnet-4.6) падает с **403 Insufficient credits** — генерация картинок недоступна.
|
||
|
||
## Файлы, тронутые в сессии
|
||
- `tasks/orchestrator/STATUS_MODEL_DEEP_ANALYSIS.md`, `STATUS_MODEL_PROPOSAL.md`, `status_workflow.html`
|
||
- `/tmp/wi_tracker_desc.md` (ТЗ ORCH-67), `/tmp/wi1_desc.md`
|
||
- `temp/DEV_TASK_ORCH-022_test_fix.md`
|
||
|
||
## 🔴 ТИХАЯ ПОТЕРЯ 059 при merge цепочки (08.06, поймала на верификации)
|
||
- Dev #1 (vibecode/sonnet-4.6) упал на billing. Перезапуск #2 (tokenator/sonnet-4-6) — за 5 мин САМ разрешил конфликт reconciler.py: HEAD `dac81e0`, маркеров 0, технически верно (to_analyse=7, set_issue_monitoring=1, _is_terminal_state=2, get_project_state_groups=2, _stage_changed=4, триггер старта=to_analyse ✅).
|
||
- 🔴 **НО верификация вскрыла дыру:** `handle_confirm_deploy` (ORCH-059) = **0 во всём дереве** (было 3 в ветке 059). **Тихая потеря без конфликта.**
|
||
- **Механизм:** 066 срезан от базы БЕЗ 059 (059=3, 066=0 по `webhooks/plane.py`). При merge 066 поверх 059 git взял `webhooks/plane.py` целиком из 066 → затёр Confirm Deploy. **Git не предупредил** (не конфликт, а fast clobber разных баз).
|
||
- **Урок (важнейший):** при сборке цепочки веток из РАЗНЫХ баз merge-без-конфликта ≠ корректно. Файлы-пересечения (`webhooks/plane.py`, `stage_engine.py`, `plane_sync.py`) надо верифицировать ПОМАРКЕРНО каждой фичи (022∧059∧066∧068 одновременно), а не доверять «git смержил чисто». Тихая потеря опаснее конфликта.
|
||
- **Решение Славы: перезапустить Dev на Opus 4.8 1M (tokenator).** Запущен с ТЗ + крит.дополнением: итог должен содержать ВСЕ 4 фичи разом, ручное сращивание webhooks/plane.py (059 confirm + 066 статусы вместе). Таймаут 40 мин. HEAD sonnet-а (dac81e0) НЕ доверять — пересобрать/доверифицировать.
|
||
- ТЗ обновлено: `/tmp/DEV_TASK_merge_066_068.md` (+ требование про 059 confirm_deploy и помаркерную верификацию пересечений).
|
||
- **Маркеры верификации финала (чек-лист):** 022→`security`/secret-scan в qg; 059→`handle_confirm_deploy`/`confirm_deploy` (≥3); 066→`to_analyse`/`set_issue_monitoring`; 068→`_is_terminal_state`/`get_project_state_groups`/`_stage_changed`. ВСЕ >0 одновременно + pytest зелёный.
|
||
|
||
## ✅ ВОССТАНОВЛЕНИЕ main ГОТОВО (Opus 4.8 1M) — ждёт Confirm Славы
|
||
- Opus пересобрал `integ/restore-main-2026-06-08` начисто от origin/main, порядок 022→059→066→068, ручное сращивание пересечений. HEAD `c90c01b`. Сломанная версия sonnet сохранена `backup/integ-dac81e0-2026-06-08`.
|
||
- **Моя независимая проверка (не верю отчёту):** 8/8 маркеров ✅ (059 handle_confirm_deploy=3, 066 to_analyse, 068 _is_terminal_state/_stage_changed, 022 security_gate), 0 конфликт-маркеров, **pytest 832 passed 0 failed** (воспроизвела сама).
|
||
- **Ключевое подтверждение механизма фантома:** когда 059 встал в ветку ДО 066, git выдал РЕАЛЬНЫЕ конфликт-маркеры в webhooks/plane.py + plane_sync.py (вместо тихого whole-file overwrite). Т.е. правильный порядок = защита от тихой потери. Вариант 1 (correct ordering) подтверждён.
|
||
- Сращено вручную: webhooks/plane.py (to_analyse+confirm_deploy оба), plane_sync.py (Confirm Deploy + 6 ключей 066 + alias fallback), reconciler.py (каркас 068 + триггер to_analyse 066), фикстуры тестов (059/068 предшествовали rename 066 → добавлен to_analyse, не подгонка под зелёный).
|
||
- **СЛЕДУЮЩИЙ ШАГ:** Confirm Славы → push ветки + merge в main + передеплой. main пока НЕ тронут, прод НЕ тронут.
|
||
|
||
## ✅ ВОССТАНОВЛЕНИЕ main ГОТОВО (08.06, Opus 4.8 1M) — ждёт Confirm на push/merge
|
||
- Dev #3 (tokenator/opus-4.8-1m) пересобрал цепочку чисто. HEAD `c90c01b`, сломанная версия sonnet-а (`dac81e0`/`4fde685`) в бэкапе.
|
||
- **Моя независимая верификация (НЕ отчёт агента):**
|
||
- 8/8 маркеров — 4 фичи сосуществуют: 022 security ✅ · 059 `handle_confirm_deploy`=3/`confirm_deploy`=9 ✅ · 066 `to_analyse`/`set_issue_monitoring` ✅ · 068 `_is_terminal_state`/`get_project_state_groups`/`_stage_changed` ✅
|
||
- 0 конфликт-маркеров
|
||
- **pytest: 832 passed, 0 failed** (прогнала сама, воспроизвелось)
|
||
- **Промежуточный красный (14 failed/818) был ОЖИДАЕМ:** когда Opus вернул 059, всплыли реальные стыки фич — он их довёл в цикле pytest. Финал зелёный.
|
||
- 🔑 **Механизм фантома доказан практически:** при постановке 059 ДО 066 git выдал НАСТОЯЩИЕ конфликт-маркеры в `webhooks/plane.py` (вместо тихого затирания у sonnet-а). **Правильный порядок веток = защита от тихой потери.** Усиливает урок.
|
||
- **Диффы:** strictly additive +1350/−67 в src. `webhooks/plane.py`: to_analyse+handle_confirm_deploy оба живут; `reconciler.py`: каркас livelock 068 + триггер to_analyse 066; `plane_sync.py`: Confirm Deploy + 6 статус-ключей 066 + alias fallback. Фикстуры тестов поправлены под реальный контракт (обосновано, не подгонка).
|
||
- **Урок про модели:** sonnet-4-6 рапортовал «816 passed» на НЕПОЛНОЙ версии (без 059) — отчёт был «правдив» по своему дереву, но дерево было неверным. **НЕ доверять отчётам агентов о тестах — гнать pytest самой и сверять маркеры всех фич.** Opus справился с ювелирной 4-way склейкой, sonnet — нет.
|
||
- ⏸️ **БЛОКЕР = ожидание Славы:** main и прод НЕ тронуты, всё в изолированном worktree `/tmp/integ_chain`, ветка `integ/restore-main-2026-06-08`. Жду Confirm на: push → merge в main → передеплой прода. БЕЗ его ОК ничего не пушу (правило ручного approve прода, INV-1).
|
||
|
||
## 🎉 ВОССТАНОВЛЕНИЕ main + ПРОД ЗАВЕРШЕНО (08.06, путь A штатный, под контролем Славы)
|
||
- **Confirm Славы получен** на каждый шаг отдельно (полный контроль). Путь A = штатный механизм орка, не самодельный.
|
||
- **PR #71** integ/restore-main → main: merged=True, merge_sha `4946123`. Первый честный merge после ORCH-065 — фантом разорван.
|
||
- **Шаг 1:** хост-репо /home/slin/repos/orchestrator `48b5405`→`4946123` (был позади на 42 коммита). Откат-точка 48b5405.
|
||
- **Шаг 2:** `--build-staging` GIT_SHA=4946123 → staging-образ пересобран (rev=4946123), health OK, staging_check PASS (exit 0). Прод НЕ тронут. ⚠️ Ключевое: staging/prod были на промежуточном `6bbd530` (НЕ main) — без пересборки ретегнулся бы старый код (provenance guard на main НЕактивен, не поймал бы). Пересборка обязательна.
|
||
- **Шаг 3 (прод):** `--deploy` build-once retag staging(4946123)→prod, health OK 2-я попытка (~7с downtime), exit 0. prev-image сохранён для отката. Активных jobs было 0 — никого не оборвал.
|
||
- **Шаг 4 verify-after-deploy:** prod-образ rev=`4946123` ✅, health ok ✅, ВСЕ 4 фичи в живом проде (022 security_gate, 059 handle_confirm_deploy=3/confirm_deploy=7, 066 to_analyse=7+set_issue_monitoring, 068 _is_terminal_state=2/get_project_state_groups=2) ✅, диспетчер слушает `to_analyse` (webhooks/plane.py:164) → **ORCH-67 теперь стартует** ✅.
|
||
- **ET-002 спам:** 1 разовый всплеск на первом тике reconciler (07:38:14, до прогрева кэша), за полный цикл 130с НЕ повторился (=1) → livelock-фикс 068 работает, спама нет.
|
||
- **ИТОГ:** main = прод = `4946123`, все 4 потерянные задачи восстановлены, фантом разорван, прод здоров. Осталось: ORCH-71 (root-fix фантома, чтобы не повторялось) — в Backlog, запускать штатно.
|
||
|
||
## 🧹 ЧИСТКА + ЗАПУСК ORCH-71 (08.06, после восстановления)
|
||
- **Закрыты 6 хвостовых open PR** как superseded (комментарий + state=closed, БЕЗ merge): #50(044), #64(061) — дубль-ветки, код уже в main; #67-70(022/059/066/068) — восстановлены через #71. **Open PR теперь = 0.** Gitea-доска чистая.
|
||
- **ORCH-71 ЗАПУЩЕНА в конвейер** (07:56 UTC): Backlog → To Analyse → **Task 55, analyst job 416, run_id=353, pid=349**, ветка `feature/ORCH-071-crit-bug-merge-main`, .task.md=3532b. Заголовок 53 симв (QG-0 ок), desc 3638.
|
||
- 🎯 **БОЕВАЯ ПРОВЕРКА восстановления пройдена:** прод подхватил задачу по НОВОМУ статусу `to_analyse` (диспетчер webhooks/plane.py:164), конвейер стартовал штатно. То, что ломал фантом (прод слушал старый in_progress) — теперь работает. ORCH-67 тоже сможет стартовать.
|
||
- ORCH-71 — root-fix фантома: verify-merge-after-deploy + done-гейт по PR.merged + merge до рестарта. Идёт автономно, ждёт BRD-approve Славы на стадии In Review.
|
||
|
||
## ✅ ORCH-71 BRD APPROVED (08:07 UTC) → architecture (run_id=354, pid=531)
|
||
- Проверила артефакты аналитика — **эталон.** Аналитик УГЛУБИЛ root cause код-аудитом: для self-hosting путь deploy СТРУКТУРНО не содержит merge-в-main (merge делает только LLM-агент deployer, который на self-hosting НЕ запускается), done достигается по одному deploy_status:SUCCESS без верификации main.
|
||
- BRD: G1-G4 + INV-1..5 (merge только PR-API/никогда force-push, идемпотентность через pr_already_merged ORCH-065, never-raise, self-hosting safety, ручной approve сохранён).
|
||
- ТЗ: карта 7 модулей (stage_engine/merge_gate/self_deploy/qg/checks/config/deployer.md), FR-1..5, zero БД-миграций, restart-safe через sentinel/jobs, self vs non-self разделены. HOW отдан архитектору (ADR).
|
||
- AC: 11 критериев с PASS/FAIL — not-merged→alert(AC-1), done-гейт по PR.merged mock(AC-2), restart-докатка(AC-3), регресс self+non-self(AC-4/4b), never-raise(AC-7), идемпотентность(AC-9), kill-switch(AC-10), approve сохранён(AC-11), staging-воспроизведение(AC-6).
|
||
- **Approved → architect стартовал** (job 417, run_id=354). Идёт автономно. Следующий гейт Славы — после architecture (ADR-ревью) либо позже.
|
||
|
||
## ⚠️ ЛОЖНЫЙ алерт 08:19 + QA-замечание ORCH-71
|
||
- В Telegram прилетел «🚨 deploy succeeded but not merged: ORCH-036 (branch=feature/ORCH-036-x)». Слава: «Что это?»
|
||
- **Разбор:** НЕ инцидент. dev-агент ORCH-71 написал alert-код (stage_engine.py~1334, merge_gate.py~521) + тесты с mock-фикстурой branch=feature/ORCH-036-x/wi=ORCH-036. Прогон pytest дёрнул НЕзамоканную alert-функцию → реальный Telegram-вызов улетел Славе.
|
||
- Доказано: реальная ORCH-036=done (ветка feature/ORCH-036-orch-36-deploy-b), feature/ORCH-036-x НЕ существует, прод-оркестратор алерт НЕ слал (нет в его логах после 07:59), код ORCH-71 ещё не в проде.
|
||
- **Добавила QA-замечание в Plane ORCH-71** (коммент): во всех тестах alert/notify → мокать send_telegram/sendMessage; AC-критерий «pytest НЕ шлёт реальных Telegram-сообщений, 0 вызовов к api.telegram.org»; reviewer заворачивает незамоканный notify (REQUEST_CHANGES).
|
||
- **Урок:** автономный конвейер, тестирующий notify-функции, может спамить живые каналы из pytest, если notify не замокан. Закладывать мок notify в AC любой задачи с alert/Telegram.
|
||
|
||
## ✅ ORCH-71 ЗАВЕРШЕНА — root-fix фантома в проде (09:17 UTC)
|
||
- Конвейер ORCH-71 прошёл analysis→architecture→dev→review(APPROVED, 0 блокеров)→test(853 passed, TC-01..16/AC-1..11)→staging(SUCCESS).
|
||
- **Моё QA-замечание учтено:** conftest.py autouse-фикстура глушит send_telegram во ВСЕХ тестах → 0 реальных Telegram из pytest (структурно). Проверила лично.
|
||
- **Слив + деплой (вручную, чистый путь):** PR#72 merged в main (merge_sha 52ca882). Хост-репо→52ca882. staging пересобран из 52ca882 (PASS). Прод-деплой: build-once retag → prod rev=52ca882, health OK.
|
||
- **prod == main == 52ca882**, merge-verify в живом проде (merge_pr/verify_merged_to_main/_handle_merge_verify×3), merge_verify_enabled=True.
|
||
- 🎯 **БОЕВАЯ самопроверка:** `verify_merged_to_main(orchestrator, ORCH-71-branch, sha)` = True — новый гейт подтверждает merge ORCH-71 в main. Фича проверяет сама себя.
|
||
- ⚠️ **Provenance guard (ORCH-058) сработал штатно:** конвейерный Phase B задачи упёрся в SOURCE_IMAGE 52ca882 != expected d49e88c (fail-closed, exit 1), т.к. ручной merge+deploy опередил авто-Phase B → образы разошлись → guard заблокировал повторный деплой уже задеплоенного. Прод НЕ пострадал. Задача FAILED→Blocked в конвейере, но по факту код в проде.
|
||
- **Закрыла Done вручную** (manual close, вариант A) + пояснит. коммент в Plane. БД орка: stage→done. active jobs=0, прод здоров, ET-002 спам=1 (только старт, не растёт).
|
||
- **УРОК:** ручной merge+deploy ПЕРЕД конвейерным Confirm Deploy ломает provenance guard (expected revision = HEAD ветки на момент staging-валидации ≠ ручной merge-commit). Чистый авто-путь: дать задаче пройти свой Phase B самой ИЛИ сбросить deploy-state перед ручным деплоем. На будущее: либо полностью ручной путь + manual Done, либо полностью конвейерный — не смешивать.
|
||
|
||
## 🧹 Гигиена + 🚀 ORCH-67 запущена (09:46 UTC) — КРУГ ЗАМКНУТ
|
||
- **Гигиена:** 0 открытых PR (фантомов не накопилось), PR#72 merged, deploy-state ORCH-071 самоочистился (finalizer прибрал при FAILED). Мусора нет. ORCH-71 stage=done, 0 jobs, reconciler не дёргает.
|
||
- **ORCH-67 СТАРТОВАЛА** — та самая задача, что НЕ подхватывалась из-за фантома (прод слушал in_progress, не to_analyse). Теперь: To Analyse → Analysis → analyst job 425, run_id=361, pid=497, ветка feature/ORCH-067-telegram-tracker-bump-plane, .task.md=5174b.
|
||
- **ТЗ ORCH-67 актуально:** написано уже под новую модель ORCH-066 (To Analyse→...→Done маппинг). 4 требования: (1) bump из коробки, (2) карточка показывает Plane-статусы новой модели + ⏸️ ожидания (In Review/Awaiting Deploy/Needs Input), (3) кликабельный work_item_id → Plane-ссылка (ORCH_PLANE_WEB_URL, fail-safe), (4) кликабельные номера во всех уведомлениях.
|
||
- 🎯 **ДОКАЗАНО В ДЕЙСТВИИ:** фантом ломал именно подхват ORCH-67 — теперь конвейер берёт её мгновенно. Восстановление статусной модели работает боем.
|
||
- Идёт автономно. Следующий гейт Славы — BRD-approve на стадии In Review.
|
||
|
||
## ✅ ORCH-67 BRD APPROVED (09:53 UTC) → architecture (run_id=362)
|
||
- Проверила BRD(13к)/ТЗ(15к)/AC(9к) — эталон. 4 требования владельца разложены точно, маппинг под модель ORCH-066 (которую вернули в прод), fail-safe прошит насквозь.
|
||
- ТЗ: config.py:408 tracker_mode edit→bump; хелперы plane_status_label + plane_issue_link (переиспользуют _build_plane_issue_link ORCH-017); карта точек send_telegram во всех модулях; схема БД/QG/транспорт не трогаются. Скользкое место (статусы веток без stage: Needs Input/Blocked/Deploying) корректно [ARCH] с safe-дефолтом; In Review из brd-clock БЕЗ сети.
|
||
- AC: 18 критериев PASS/FAIL — bump(A1-4), статусы+In Review-без-сети+never-crash(B5-9), кликабельный номер+fail-safe(C10-11), хелпер+все точки+html.escape(D12-14), нерегресс транспорт/enduro/тесты/доки(E15-18). AC-14 тест HTML-поломки на title с <b>/&.
|
||
- Approved → architect (job 426, run_id=362). Идёт автономно.
|
||
|
||
## 🎉 ORCH-67 В ПРОДЕ — ORCH-71 merge-verify СРАБОТАЛ БОЕМ (10:52 UTC)
|
||
- Слава дал Confirm Deploy. На этот раз НЕ вмешивалась руками (урок ORCH-71) — дала конвейеру отработать.
|
||
- **merge-verify (код ORCH-71) сработал автоматически:** лог `Task 56: merge-verify merge_pr -> ok=True (already-merged)` → `merge-verify CONFIRMED -> deploy->done allowed` → `deploy → done`.
|
||
- Т.е. орк САМ слил PR ORCH-67 в main + САМ верифицировал merge + САМ разрешил done. Фантом физически невозможен теперь.
|
||
- Полный путь: Confirm Deploy → Phase B → merge+verify → done → Monitoring after Deploy → post-deploy monitor HEALTHY (tick 1,2 health=200 5xx=0).
|
||
- **Bump-режим ORCH-67 уже работает:** в логах deleteMessage→sendMessage (старая карточка вниз).
|
||
- ИТОГ: ORCH-67 (Telegram tracker bump+статусы+кликабельные номера) в проде. Исходная проблема «ORCH-67 не подхватывается» закрыта ПОЛНОСТЬЮ. Цикл само-исцеления орка замкнут: фантом → восстановление main → root-fix ORCH-71 → боевая проверка на ORCH-67 успешна.
|
||
- **КОНТРАСТ:** ORCH-71 я деплоила вручную (провенанс-гард ругнулся, manual Done). ORCH-67 — полностью автоматом через новый merge-verify. Разница = именно то, что ORCH-71 и чинила.
|
||
|
||
## 🐛 БАГ ORCH-72 заведён + урок (статус-строка карточки врёт)
|
||
- Слава заметил: карточка ORCH-69 показывала «📍 To Analyse» при пройденных всех стадиях.
|
||
- **Root cause:** ORCH-67 `_STAGE_STATUS_LABEL` (src/notifications.py) НЕ покрывает стадию `deploy-staging` (и возможно др.) → падает в `_DEFAULT_STATUS_LABEL="To Analyse"` (худший фолбэк = первый статус). ORCH-69 был на deploy-staging.
|
||
- **ORCH-72** (seq=72, id=e722a596) в Backlog: дополнить карту ВСЕМИ стадиями из stage_engine, фолбэк нейтральный (не To Analyse), deploy-staging→осмысленный лейбл. Косметика, не функционал.
|
||
- **УРОК (ревью-чеклист):** при stage-зависимом маппинге — покрывать ВСЕ стадии из единого источника (STAGE_TRANSITIONS), фолбэк нейтральный. Моё ревью ORCH-067 это пропустило — карту стадий надо сверять поимённо, не «на глаз». Аналитик/архитектор взяли «основные» стадии, забыли служебные (deploy-staging).
|
||
|
||
## 🕐 Московское время — план (делать ПОСЛЕ финала ORCH-69, по просьбе Славы)
|
||
- **Цель Славы: один часовой пояс ВЕЗДЕ = Europe/Moscow.** Разнобой сейчас: хост mva154=MSK✅, контейнер орка=UTC❌, Стрим=UTC❌. (Часы хоста НЕ ушли — ORCH-64 неактуален, NTP active.)
|
||
- **План:** (1) контейнер орка → `TZ=Europe/Moscow` в docker-compose (логи/карточки/уведомления→MSK), требует рестарт контейнера ~7с; (2) Стрим → перейти на MSK в общении со Славой.
|
||
- **Когда:** Слава просил сделать ПОСЛЕ того как ORCH-69 добежит до финала (чтобы рестарт никого не прервал). Дождаться done ORCH-69 → поставить TZ.
|
||
|
||
## 🐛 ORCH-72 РАСШИРЕН — 3 дефекта карточки (Слава выловил 2 и 3)
|
||
- **Дефект 1:** статус-строка «To Analyse» на непокрытых стадиях (deploy-staging) — исходный.
|
||
- **Дефект 2 (Слава):** карточка НЕ отражает откаты. При rollback merge-gate deploy-staging→development (ORCH-43, конфликт CHANGELOG) верхние ✅ (Код-ревью/Тест/Внедрение) не снимаются, внизу снова 🔄 Разработка. Абсурд «Внедрение ✅ + Разработка 🔄».
|
||
- **Дефект 3 (Слава, ДЕНЬГИ):** стоимость/токены повторных попыток НЕ суммируются. Карточка берёт последний agent_run на стадию. ORCH-69 developer×3: run370=$3.05, run372=$0.26, run376=$0.68 = РЕАЛЬНО $3.98, карточка показала ~$0. Тотал занижен на ~$3.3. Нужно SUM(agent_runs) по (task,stage), не последний.
|
||
- ORCH-72 desc обновлён: +G4(откаты)/G5(сумма попыток) +AC-6/AC-7. Это уже НЕ косметика — искажение учёта денег.
|
||
- **Контекст:** ORCH-69 откатилась deploy-staging→development 3 раза из-за конфликта CHANGELOG.md (наши деплои 71/67 сегодня трогали CHANGELOG → ветка разошлась). Штатное самолечение merge-gate, но дорого (3× разработка).
|
||
|
||
## 💡 УРОК (Слава просил записать): CHANGELOG.md = частый источник дорогих merge-конфликтов
|
||
- **Наблюдение:** ORCH-69 откатилась deploy-staging→development 3 раза (merge-gate, конфликт CHANGELOG.md). Причина — несколько задач в один день (ORCH-71, 67, 69) добавляют записи в один и тот же файл CHANGELOG.md → ветки расходятся → rebase-конфликт на merge-gate → откат на разработку.
|
||
- **Цена:** каждый откат = повторный запуск developer. ORCH-69 разработка 3× = $3.98 вместо ~$1. Конфликты CHANGELOG прямо жгут деньги.
|
||
- **Системная проблема (кандидат в задачу):** при параллельных задачах CHANGELOG.md — гарантированная точка конфликта (все пишут в `## [Unreleased]`). Варианты решения для будущей задачи орка:
|
||
1. auto-rebase merge-gate должен УМЕТЬ разрешать CHANGELOG-конфликты автоматически (union-merge для append-only секции Unreleased), а не откатывать на development.
|
||
2. ЛИБО: не писать CHANGELOG в feature-ветке, а генерировать запись при merge в main (post-merge hook).
|
||
3. ЛИБО: .gitattributes merge=union для CHANGELOG.md (git сам сливает обе вставки).
|
||
- Вариант 3 (`.gitattributes merge=union`) — самый дешёвый и точечный фикс. Рекомендую завести задачу, если откаты по CHANGELOG повторятся.
|
||
- **Связь:** этот же CHANGELOG-конфликт — причина, по которой ORCH-71 я сливала вручную, а auto-rebase ORCH-69 трижды откатывал. Системная, повторяющаяся боль.
|
||
|
||
## ⤷ ORCH-72 уточнение (Слава): суммировать ВСЕ метрики при повторных попытках
|
||
- Дефект 3 не только про деньги: при повторах стадии занижаются $ И токены И время. Все 3 суммировать по всем agent_runs стадии.
|
||
- Время = Σ(finished-started) по попыткам; токены = Σ(in/out + cache); $ = Σ cost_usd. Тоталы задачи = суммы по всем стадиям/попыткам, сходятся с SUM по agent_runs для task_id. (AC-8 добавлен.)
|
||
|
||
## ✅ ORCH-69 в проде + МОСКОВСКОЕ ВРЕМЯ ВЕЗДЕ (08.06, ~14:46 MSK)
|
||
- **ORCH-69** (QG-0 title-лимит→ORCH_QG0_TITLE_MAX=200) задеплоена: review APPROVED, test PASS, staging SUCCESS, security 0/0. Откатывалась 3× из-за CHANGELOG-конфликта, потом dev ребейзнул, up-to-date with main. Confirm Deploy → merge-verify (already-merged) CONFIRMED → done. Прод-образ de70ee81.
|
||
- **merge-verify (ORCH-71) сработал боем 2-й раз подряд** (после ORCH-67) — полностью автоматом, без ручного вмешательства.
|
||
- 🕐 **МОСКВА ВЕЗДЕ:** добавила `TZ=Europe/Moscow` в docker-compose.yml в ОБЕ секции (prod стр.28 + staging стр.69), бэкап `docker-compose.yml.bak-tz-*`, `docker compose config` валиден. Recreate prod через `up -d --no-build` (образ НЕ пересобран, de70ee81 цел, health ok). Контейнер: `date = MSK` ✅, TZ=Europe/Moscow. Теперь хост MSK + контейнер MSK = единый пояс. Логи/карточки/уведомления орка → московское время.
|
||
- **Я (Стрим) тоже перехожу на MSK** в общении со Славой.
|
||
- ORCH-64 (часы ушли) — НЕАКТУАЛЕН (часы хоста ок, был просто рассинхрон UTC контейнера vs MSK хоста, теперь устранён).
|
||
|
||
## ✅ ВОССТАНОВЛЕНИЕ ORCH-67+69 + ССЫЛКИ + TZ-фикс (08.06 ~15:09 MSK)
|
||
- **Слава: «ссылок нет на таску».** Аудит вскрыл: код ORCH-67 (tracker bump/статусы/ссылки) И ORCH-69 (qg0_title_max) ОТСУТСТВУЮТ в main — только их docs-коммиты. Обе фантомы от CHANGELOG-ребейзов. Системная эрозия main.
|
||
- **A (восстановление):** интеграция 67+69 поверх main в worktree /tmp/integ6769. CHANGELOG-конфликт всплыл вживую на merge 69 → union. Все фичи целы (plane_issue_link, num_html заголовок, qg0_title_max, verify_merged_to_main). pytest 917 passed. PR#76 merged в main (sha 05bd169). Деплой: staging→prod SUCCESS.
|
||
- ✅ **ССЫЛКА РАБОТАЕТ:** карточка заголовок = `<a href="https://plane.mva154.duckdns.org/.../ORCH-069</a>` — кликабельна, ведёт на Plane.
|
||
- **B (критбаг): ORCH-73** (urgent) — эрозия main: G1 восстановить (сделано), G2 `.gitattributes CHANGELOG.md merge=union`, G3 merge-verify ловит откат СОСЕДНЕГО кода, G4 аудит docs-only merge.
|
||
- 🐛 **+ нашла косяк деплоя: `git reset --hard origin/main` откатывает правки docker-compose.yml** (он git-managed). Мой TZ=Europe/Moscow в compose слетел при деплое → UTC. **ФИКС: перенесла TZ в `.env`** (в gitignore → переживёт git pull/деплой). Теперь TZ=MSK стабильно. Урок: ПРАВКИ ХОСТ-РЕПО (compose и др. git-файлы) НЕ ПЕРЕЖИВАЮТ деплой — конфиг класть в .env.
|
||
- **ORCH_PLANE_WEB_URL=https://plane.mva154.duckdns.org** добавлен в .env (его не хватало для ссылок).
|
||
|
||
## 🚀 ORCH-73 ЗАПУЩЕНА — системный root-fix эрозии main (15:48 MSK)
|
||
- **Кто делает:** сам конвейер орка (self-hosting), analyst job 506 run_id=380. Я (Стрим) код не пишу — ТЗ + ведение через гейты.
|
||
- **Root cause доказан git-аудитом (не гипотеза):**
|
||
1. `verify_merged_to_main` проверяет НЕ ТО: `merge-base --is-ancestor origin/main HEAD` = «ветка свежая», а НЕ «код ветки в main» (инвертировано). `0ed0541` (код ORCH-069) НИКОГДА не был предком main, но задача→done.
|
||
2. `pr_already_merged` засчитывает ЛЮБОЙ merged PR ветки (state=all&head=branch). У ветки несколько PR (code-PR + авто docs-PR). docs-PR сливается → "already-merged" → CONFIRMED → done, хотя code-PR не слит. Ложно-зелёный.
|
||
3. CHANGELOG-ребейзы — вторичный усилитель (тихое затирание соседнего кода).
|
||
- **Системное решение (FR-1..5 в ТЗ ORCH-73):**
|
||
- FR-1: verify_merged_to_main чинит семантику → проверять что deployed_sha РЕАЛЬНО предок origin/main (прямая проверка «код в main»).
|
||
- FR-2: done-критерий = SHA-в-main (единственный источник истины), PR-флаги вспомогательны; различать code-PR vs docs-PR.
|
||
- FR-3: merge-актор реально мержит code-ветку + верификация FR-1 после.
|
||
- FR-4 (корень): `.gitattributes CHANGELOG.md merge=union` — убрать ребейз-конфликты.
|
||
- FR-5 (защита навсегда): пост-деплой регресс-гард — sanity main, alert если код ранее-merged задач откатился.
|
||
- AC-9: воспроизведение на staging — 2 задачи с CHANGELOG-правкой доезжают без потери кода друг друга.
|
||
- ⚠️ Особый риск: ORCH-73 чинит САМ merge-verify → деплой через который она едет. Нужна осторожность на её собственном Confirm Deploy (могут всплыть переходные эффекты). Следить.
|
||
|
||
## ✅ ORCH-73 BRD APPROVED (16:04 MSK) → architecture (run_id=381)
|
||
- Проверила BRD(8к)/ТЗ(11к)/AC(6к) — эталон. Аналитик УТОЧНИЛ мой git-аудит точнее: дефект не в branch_is_behind_main (та проверка корректна), а в OR-ветке pr_already_merged внутри verify_merged_to_main (~стр.649), засчитывающей docs-PR. G1 (восстановление) отмечен как уже сделанный через restore-PR #76.
|
||
- ТЗ: FR-1 verify ТОЛЬКО по SHA-предок-main; FR-2 pr_already_merged → idempotency-guard (вариант б); FR-3 merge реально сливает code-PR; FR-4 .gitattributes CHANGELOG merge=union (с предупреждением: union только append-only!); FR-5 регресс-гард ALERT+HOLD. Схема БД/QG/API не трогаются. never-raise/kill-switch/non-self везде.
|
||
- AC: 11 критериев. AC-2 (verify True только SHA-в-main даже при docs-PR), AC-3 (воспроизведение бага 067/069→HOLD+alert), AC-4 (.gitattributes+check-attr+тест 2 ребейзов), AC-5 (регресс-гард), AC-7 (идемпотентность по SHA), AC-10 (НАВСЕГДА: 2 задачи с CHANGELOG на staging без потерь), AC-11 (self-hosting safety).
|
||
- Approved → architect (job 507, run_id=381). Идёт автономно.
|
||
- Логи орка теперь в MSK ✅ (16:04).
|
||
|
||
## 🎉🎉 ORCH-73 В ПРОДЕ — ЭРОЗИЯ MAIN ИСПРАВЛЕНА НАВСЕГДА (16:54 MSK)
|
||
- Проверила лично: review APPROVED/test PASS/staging SUCCESS, реализация образцовая. FR-1 (OR-ветка pr_already_merged УБРАНА из verify, комментарий "former OR-branch REMOVED"), FR-4 (.gitattributes CHANGELOG merge=union, check-attr подтвердил боем), FR-5 (check_main_regression + декларативный marker set + HOLD+alert). 6 новых тест-файлов. pytest 941 passed (мой прогон). Фичи 067/069/071 целы.
|
||
- **Confirm Deploy → merge ЧЕСТНЫЙ:** лог `merge_pr -> ok=True (merged PR #77)` — РЕАЛЬНЫЙ code-PR, НЕ "already-merged"/docs-PR. Видна разница со старым багом. CONFIRMED → done → Monitoring → HEALTHY.
|
||
- **main 1c3ecb9 — ВСЕ задачи одновременно:** 067 plane_issue_link, 069 qg0_title_max, 071 verify_merged_to_main, 073 check_main_regression(8) + .gitattributes union. Прод на новом коде.
|
||
- **ИТОГ: корень всех сегодняшних фантомов закрыт навсегда.** merge-verify теперь по SHA-предок-main (не ложно-зелёный от docs-PR) + CHANGELOG merge=union (ребейзы не затирают) + регресс-гард (alert если код соседей откатился). Эрозия main невозможна.
|
||
- День: фантом-merge → восстановление main(022/059/066/068) → ORCH-71 root-fix#1 → ORCH-67/69 потеряны эрозией → восстановление → ORCH-73 root-fix#2 (настоящий корень) → MSK везде. Орк прошёл полный цикл само-исцеления и теперь защищён системно.
|
||
|
||
## 🚀 ORCH-26 ЗАПУЩЕНА — координация параллелизма (18:28 MSK)
|
||
- Слава: «orch-26 в работу» (после обсуждения «что осталось для автономности» — пункт #1).
|
||
- **Дополнила ТЗ сегодняшним уроком:** базовое описание (04.06) было только про логические зависимости (B ждёт A). Добавила РЕАЛЬНЫЙ корень — Уровень A: СЕРИАЛИЗАЦИЯ merge/деплоя в один репо (откуда родилась эрозия: параллельные 067/069/071 затирали main). + Уровень B: декларативные зависимости (исходный скоуп).
|
||
- Ключевое требование A: в одном репо merge B обязан быть на СВЕЖИЙ main (где уже A) — pre-merge rebase ИЛИ merge-очередь FIFO ИЛИ расширенный merge-lease (ORCH-065). Разные репо (orch vs enduro) параллелятся свободно. Дополняет ORCH-073 (закрывает первопричину, не последствия).
|
||
- analyst job 543, run_id=386, ветка feature/ORCH-026-b-a, .task.md=3619b.
|
||
- Контекст: ORCH-73 ещё в Monitoring-окне, ORCH-26 на analysis (merge далеко) → безопасно.
|
||
|
||
## ✅ ORCH-26 BRD APPROVED (18:36 MSK) → architecture (run_id=387)
|
||
- Проверила BRD(11к)/ТЗ(11к)/AC(8к) — эталон уровня 71/73. Аналитик чётко разделил Уровень A (сериализация merge — корень эрозии) и B (декларативные зависимости), опёрся на фундамент ORCH-1/065/043/073 (не переписывать).
|
||
- A: A-2 proactive pre-merge rebase (auto_rebase_onto_main + force-with-lease ТОЛЬКО ветку, не main), расширение окна merge-lease (065), neblocking acquire→defer (bounded budget анти-livelock), per-repo (кросс-репо параллелизм цел), restart-safe.
|
||
- B: гибрид Plane+БД хранение (offline-fallback), аддитивная миграция, гейт планировщика (claim_next_job не клеймит blocked), DFS детект циклов→Blocked+alert, видимость в карточке.
|
||
- AC: 17 (A1-7/B1-5/G1-5). never-raise, kill-switch, аддитивная миграция (G4), нулевой регресс enduro (A7). Архитектурные развилки честно отданы архитектору (КАНДИДАТ).
|
||
- Approved → architect (job 544, run_id=387). Идёт автономно.
|
||
- Это ВТОРОЙ кирпич надёжной автономности после ORCH-073 (целостность): закрывает ПЕРВОПРИЧИНУ параллелизма, дополняет 3 рубежа на уровне планировщика.
|
||
|
||
## 📋 ORCH-52 расширена + ORCH-49 поглощена (08.06)
|
||
- **ORCH-52** (стандарт документов + протокол handoff) дополнена ТРЕТЬИМ слоем: оптимизация системных промптов всех 6 агентов (.openclaw/agents/*.md) по Anthropic best-practices. 7 конкретных улучшений (few-shot/XML/success-criteria/CoT/доказывай-не-предполагай/anti-pattern/явный AC-формат). Эталоны для few-shot: ORCH-071/073. Измеримая цель: меньше REQUEST_CHANGES-циклов, стабильное качество, экономия токенов (связь 72/23), A/B-проверка.
|
||
- **ORCH-49 → Cancelled** (поглощена в 52). Исправлен источник: исходная ссылка prompt-library = каталог команд Claude Code, НЕ гайд по system-промптам; правильные = docs.anthropic.com/.../prompt-engineering.
|
||
- ORCH-52 остаётся в Backlog (Слава: «пусть пока в бэклоге»).
|
||
- ⚠️ Слава написал «26 отмени как поглощённую» — но это была ОПИСКА (26 = зависимости, в активной работе, ничего не поглощает). Уточнила → имелась в виду 49. ORCH-26 НЕ тронута.
|
||
- **Промпты агентов орка** (для справки): `.openclaw/agents/{analyst,architect,developer,reviewer,tester,deployer}.md`, модель claude-sonnet-4-6, вызов `claude --system-prompt "$(cat ...)"` (launcher.py:390). developer: merge ЗАПРЕЩЁН, прод не рестартить, PR≤1500. analyst: не архитектурит/не кодит, Write только docs/work-items/.
|
||
|
||
## ✅ ORCH-26 В ПРОДЕ — координация параллелизма (19:47 MSK) + УРОК
|
||
- Задача образцовая: review APPROVED/test PASS/staging SUCCESS, task_deps.py (is_task_ready/detect_cycle DFS/handle_cycle/declare_dependency/ingest_plane_relations), 10 тест-файлов 206 passed, pytest 991. Все фичи 067/069/071/073 целы (3 рубежа держат — первая задача после ORCH-73 без потерь!).
|
||
- ⚠️ **2 деплоя FAILED по МОЕЙ вине (не баг задачи):** (1) git pull хост-репо упал divergent branches; (2) provenance guard — 3 SHA разъехались (staging 9800dc/expected 1d928d/ветка 90a5cae). Корень: я весь день мешала ручные git reset --hard (восстановление 67/69/TZ/web_url) с автономным конвейером → хост-репо и provenance-метки разъехались.
|
||
- **Фикс:** выровняла хост-репо на origin/main + пересобрала staging штатно `image_freshness.rebuild_staging_image(repo,branch,sha)` из HEAD ветки 90a5cae → provenance совпал → Confirm Deploy → merge_pr ok → CONFIRMED → done → HEALTHY.
|
||
- **УРОК (повтор ORCH-71, закрепить!):** НЕ смешивать ручные git-операции с автономным конвейером. Ручной reset --hard оставляет хост-репо расходящимся (ломает deploy-hook git pull) + provenance-рассинхрон. Если правлю руками — СРАЗУ выравнивать хост-репо И пересобирать staging из нужного sha перед деплоем задачи. Лучше: вообще не лезть руками в репо, пока конвейер активен.
|
||
- Прод цел весь день (guard fail-closed не дал кривой деплой). ORCH-26 = 2-й кирпич автономности (координация) после ORCH-73 (целостность).
|
||
|
||
## ⤷ ORCH-52 +трассировка (Слава, 08.06): номера задач ORCH-NNN
|
||
- Вопрос Славы: зачем номера в коде, агенты их читают? Тонкость: маркер `ORCH-NNN` полу-пустой, пока агент не открыл work-item.
|
||
- Добавила в ORCH-52: (1) маркеры-трассировка = обязательный стандарт; (2) ПРАВИЛО В ПРОМПТАХ developer/architect/reviewer: «правишь код с маркером ORCH-NNN → прочитай его docs/work-items/ORCH-NNN/06-adr ПЕРЕД изменением, не сломай инвариант»; (3) fallback доступа к чужим work-item (git show origin/main:...); (4) анти-археология (3+ маркеров → сводный ADR-ссылка). Ценность: профилактика регрессий (маркер ведёт агента к «почему так нельзя трогать»).
|
||
|
||
## 🧭 ORCH-52 ЭПИК + декомпозиция (08.06)
|
||
- Комплексный системный анализ каркаса агентов → `tasks/orchestrator/ORCH-52_SYSTEM_ANALYSIS.md`. Сверка с каноном Anthropic (building-effective-agents, claude-prompting-best-practices, multi-agent-research).
|
||
- **Главная находка (Слава ткнул):** frontmatter промптов лжёт (model: sonnet-4-6/opus-4-7), launcher НЕ читает → все реально на opus-4-8 (config ORCH-41). Мёртвая декларация + мина + нет routing/effort. Для Opus 4.8 канон: effort xhigh для coding, сейчас НЕ задан.
|
||
- ORCH-52 = эпик-зонтик. Декомпозирована на 6 подзадач (seq 74-79):
|
||
- **ORCH-52a [URGENT] seq=74** фикс модели/эффорта (мёртвый frontmatter → routing+effort)
|
||
- **ORCH-52b [HIGH] seq=75** стандарт документов (docs/_templates + манифест + ADR-naming)
|
||
- **ORCH-52c [HIGH] seq=76** протокол handoff + frontmatter-контракт (writer/валидатор/схема)
|
||
- **ORCH-52d [MEDIUM] seq=77** оптимизация 6 промптов по Anthropic (few-shot/XML/CoT/success-criteria) — зависит от 52b
|
||
- **ORCH-52e [MEDIUM] seq=78** трассировка ORCH-NNN (маркеры+правило чтения)
|
||
- **ORCH-52f [LOW] seq=79** синхронизация README + reviewer-гейт обзорных доков
|
||
- Все в Backlog. Зависимости: 52d←52b, 52e частично в 52d, 52a самостоятельна и горит.
|
||
- ⚠️ ВНИМАНИЕ: seq Plane ORCH-074..079 ≠ work_item_id орка (могут не совпасть при заведении в орк — сверять по названию ORCH-52a..f).
|
||
|
||
## 🚀 ORCH-52a (orch-74) ЗАПУЩЕНА — фикс модели/эффорта (08.06 ~18:24 UTC)
|
||
- Слава переживал «описание слабовато, хватит ли аналитику» → проверила реально из Plane: orch-74 = **5140 симв.**, образцовое ТЗ (диагностика с файлами/строками, P1-P4, G1-G4, AC-1..7, грабли). НЕ слабое. Слабая была 52c/orch-76 (530 симв.) — видимо её и видел в превью.
|
||
- **РЕШЕНИЕ Славы: «всё строим на opus-4-8»** → G3 model-routing (haiku для tester/deployer) НЕ включаем. Зафиксировала декларацией в начале карточки orch-74: скоп = G1 (убрать лживый frontmatter model:) + G2 (валидация имени модели, never-break) + опц.G4 (fallback, на усмотрение архитектора). Эффорт НЕ трогать. AC-4 (routing) снят.
|
||
- Запуск штатный: Backlog→To Analyse (PATCH state 200) → webhook → орк создал **task id=59 work_item_id=ORCH-074** stage=analysis, ветка feature/ORCH-074-orch-52a-frontmatter-routing-e, analyst **job 582 run_id=392** running (pid 1137). Конвейер был свободен (все ORCH в done, 0 активных jobs) → безопасно.
|
||
- ⚠️ Self-modifying задача: меняет механизм запуска агентов. Следить особо. НЕ лезть руками в репо пока едет (урок ORCH-26/71).
|
||
- Следующее: дождаться BRD аналитика → проверить → approve. Watchdog ORCH в HEARTBEAT следит.
|
||
|
||
## 📝 ORCH-52g (seq=80) заведена — убрать Telegram link-preview (логотип Plane) (08.06 ~19:00 UTC)
|
||
- Слава: «внизу сообщения большой логотип Plane, как убрать?» — это Telegram link-preview кликабельной ссылки на задачу (добавлена в ORCH-067).
|
||
- Диагностика: `notifications.py` — оба вызова (`sendMessage` трекера + `editMessageText`) без `disable_web_page_preview`. Фикс = добавить `"disable_web_page_preview": True` в payload обоих. Ссылка остаётся кликабельной.
|
||
- **Решение Славы: вариант 1** — отдельная микро-задача орка (чисто через конвейер, не руками в репо — урок ORCH-26/71).
|
||
- Создана **ORCH seq=80** id=088946c2-e709-419b-8591-f0a15b5b61fd, в **Backlog** (НЕ запущена — webhook на Backlog не триггерит). LOW. AC-1..4. Зависимость: один репо с orch-74 → запускать ПОСЛЕ её мержа (сериализация ORCH-26).
|
||
|
||
## 🎉 ORCH-52a (orch-74) В ПРОДЕ — мёртвый frontmatter убран + валидация модели (08.06 ~19:11 UTC)
|
||
- Слава: «проверяй все и переводи на деплой». Прошла весь конвейер автономно (analyst×2 = 1 REQUEST_CHANGES BRD-цикл → architect→dev→review APPROVED→test PASS→staging SUCCESS).
|
||
- **Проверила код своими глазами (не только вердикты):** AC-1 `model:` убран из всех 6 `.openclaw/agents/*.md` (grep пусто, остался name/description/tools); AC-2 `is_valid_model()` валидирует ИМЯ ДО `--model`, never-break (garbage/'' → False → откат на default), fallback тоже; 32 теста passed; ADR-001 написан. Все 6 агентов → claude-opus-4-8 (G3 routing НЕ тронут, как решил Слава).
|
||
- ⚠️ **ПОПУТНАЯ НАХОДКА (НЕ регрессия 74, НЕ блокер):** эффорт в проде резолвится в `''` (пусто) для ВСЕХ агентов! config defaults заданы (high/medium), НО env `ORCH_AGENT_EFFORT_*` в проде = ПУСТАЯ строка → перебивают config → агенты на CLI-дефолте эффорта, не на high/medium. ТЗ «эффорт уже настроен» верно по коду, неверно по факту прода. → **TODO: отдельная задача — убрать пустые ORCH_AGENT_EFFORT_* из env (или выставить high/medium), чтобы эффорт Opus 4.8 реально работал.**
|
||
- 🔒 **СРАБОТАЛА ЗАЩИТА ORCH-73 (fail-closed):** первый финал `merge_pr -> ok=False (no open PR)` → задача УДЕРЖАНА на deploy (НЕ done), Plane→Blocked. Причина: конвейер НЕ создал PR для ветки. НЕ ложно-зелёный — защита отработала идеально.
|
||
- **Фикс штатный (НЕ ручной reset):** создала PR #79 через Gitea API (mergeable=True) → перезапустила `run_deploy_finalizer` штатно → merge_pr честный. **PR #79 merged=True, merge_commit a091a2d = новый origin/main, код 0873803 РЕАЛЬНО в main** (ancestor=YES), model: в main=0. Задача → done. Прод на новом коде: is_valid_model есть, все 6 → opus-4-8.
|
||
- ⚠️ **ГРАБЛИ (новые, разобрать):** (1) конвейер НЕ создал PR для ветки ORCH-074 (обычно PR на reviewer/deployer) — возможно системный пробел, не разовый. (2) ручной INSERT job 590 не подхватился queue_worker'ом (не хватило claim-поля) → пришлось run_deploy_finalizer напрямую.
|
||
- **Обе находки заведены задачами (Слава: «заводи обе»), Backlog, НЕ запущены:**
|
||
- **ORCH-52h (seq=81)** id=ccfdf129-81f2-4549-a0a9-e0b2e1515c78 — эффорт резолвится в '' (env перебивает config). HIGH. AC-1..5, реком. вариант (c): пустая строка эффорта → откат на default. Часть эпика ORCH-52.
|
||
- **ORCH-81 (seq=82)** id=d836b313-6ca0-483a-926b-f09fc33fc140 — конвейер не создаёт PR → HOLD на merge-verify. HIGH (блокирует автономный деплой). AC-1..6, G1 root-cause → G2 гарантия PR (идемпотентно) → G3 логи. Защита ORCH-73 НЕ ослаблять. ⚠️ подозрение на системный пробел.
|
||
|
||
## 🚀 ORCH-52h (эффорт) ЗАПУЩЕНА (08.06 ~19:25 UTC)
|
||
- Слава утвердил таблицу эффорта (все на opus-4-8): **analyst=high, architect=high, developer=xhigh (ЕДИНСТВЕННЫЙ АПГРЕЙД, canon Opus 4.8 coding), reviewer=high, tester=medium, deployer=medium.** Вариант фикса (c): пустая строка эффорта → откат на default + фиксировать дефолты в config/.env.example.
|
||
- Решение вписано в карточку (PATCH 200). VALID_EFFORTS уже содержит xhigh (+max) — CLI примет.
|
||
- Почистила зомби-job 590 (мой ручной INSERT, queue_worker не подхватил) → done. post-deploy-monitor 619 — штатный цикл ORCH-074, не трогала.
|
||
- Запуск: Backlog→To Analyse → task id=60, **work_item_id=ORCH-081** (⚠️ Plane seq=81 ≠ орк work_item_id; Plane-issue ccfdf129 = эта 52h про эффорт, ТЗ 3667б с решением), ветка feature/ORCH-081-orch-52h-env-config, analyst job 621 run_id=399 running. Конвейер был свободен.
|
||
- ⚠️ Следить на деплое: может снова всплыть баг ORCH-81 (PR не создаётся) — быть готовой создать PR вручную как на 074.
|
||
- ✅ **BRD/ТЗ/AC ПРОВЕРЕНЫ (Слава: «проверь») → APPROVED** (~19:32 UTC). Аналитик копнул ГЛУБЖЕ моего ТЗ: в проде **сам agent_effort_default тоже пустой** → «откат на default» не спасает. Фикс точнее: **per-role floor** — каждая роль получает СВОЙ канонический дефолт даже при пустых per-agent+default (иначе tester снапнулся бы на high вместо medium). FR-2 явный env побеждает floor; FR-3 опечатка дропается (floor не маскирует); code-side robust (работает даже с пустым прод-.env). Таблица = решение Славы 1:1. → architect job 622 run_id=400 running.
|
||
|
||
## 🎉 ORCH-52h (эффорт) В ПРОДЕ — per-role floor работает (08.06 ~19:57 UTC)
|
||
- Прошла весь конвейер автономно (analyst→architect→dev→review→test→staging SUCCESS).
|
||
- ⚠️ **БАГ ORCH-81 СНОВА (Слава: «Опять»)** — но этот раз **классический code-PR vs docs-PR**, ровно то что ловит ORCH-73: PR #80 = code-PR (16 файлов, fix+docs) **open, НЕ merged**; PR #81 = docs-PR (1 файл staging-log) **closed/merged** → дал merge_commit в main, но кода в нём НЕТ. Старый баг засчёл бы #81 как already-merged → ложно-зелёный. **Защита ORCH-73 правильно отвергла** (SHA-в-main, различает code/docs PR) → HOLD. Идеально.
|
||
- **Фикс штатный:** смерджила code-PR #80 (mergeable=True) через Gitea API → перезапуск run_deploy_finalizer → verify SHA-в-main. fix-commit 1ada41f РЕАЛЬНО в main (ancestor=YES). Задача → done.
|
||
- ✅ **ГЛАВНОЕ — ЭФФОРТ В ПРОДЕ РАБОТАЕТ** (проверила вживую с пустым env): analyst/architect/reviewer=high, **developer=xhigh**, tester/deployer=medium. Все opus-4-8. per-role floor победил пустой env. Цель достигнута.
|
||
- 🔥 **ORCH-81 (PR-баг) теперь ВДВОЙНЕ подтверждён системным** (074 и 081 оба споткнулись на merge, оба потребовали ручного merge). **ПРИОРИТЕТ: брать ORCH-81 в работу — каждая задача требует ручного вмешательства, это ломает автономность.**
|
||
|
||
## 🚀 ORCH-81 (merge-баг) ЗАПУЩЕНА (08.06 ~20:01 UTC) — Слава: «81 вперёд»
|
||
- Критичная для автономности: чинит саму merge-стадию (почему code-PR не создаётся/не сливается → HOLD).
|
||
- task id=61, **work_item_id=ORCH-082** (⚠️ Plane seq=82≠орк id; Plane-issue d836b313 = баг PR/merge), ветка feature/ORCH-082-orch-81-pr-merge-verify-hold, analyst job 637 run_id=405 running. Конвейер был свободен.
|
||
- ⚠️ ИРОНИЯ: задача про сломанный merge поедет через сломанный merge → быть готовой домерджить code-PR вручную (как 074/081). НА ДЕПЛОЕ ОСОБО ВНИМАТЕЛЬНО: self-fix merge-verify.
|
||
- ⚠️ **УРОК (20:21 UTC): чуть не сломала живой analyst.** Слава «что там» → analyst run_id=405 (pid 279) висел ~17 мин в stage analysis, лог пуст, только 00-business-request. Я решила что завис → kill -TERM (exit 143) → launcher авто-requeue (attempt 1/2) → перезапуск run_id=406 pid=716.
|
||
- **НО проверка CPU показала: pid 716 ЖИВЁТ и РАБОТАЕТ** (cpu delta=12 тиков/5с, 5 socket, State S). Т.е. это НЕ зависание, а ДОЛГИЙ АНАЛИЗ (тяжёлая root-cause задача: читать merge_gate.py+stage_engine.py+логи 074/081 на opus-4-8). **Вероятно зря убила 405** — он тоже мог просто долго думать.
|
||
- ⚠️ **ПРАВИЛО НА БУДУЩЕЕ:** прежде чем убивать «зависший» агент — ПРОВЕРИТЬ CPU-активность pid (`/proc/PID/stat` utime+stime delta) и socket-соединения. Живёт+жжёт CPU = думает, НЕ трогать. `--output-format json` пишет результат только В КОНЦЕ → пустой лог при живом процессе = НОРМА. JobReaper max_running_s=3600 — пусть решает он, не я вручную.
|
||
- ⚠️ РИСК: attempts уже 2/2 (из-за моего kill). Если 716 упадёт — больше retry НЕТ → задача застрянет. Следить. Сейчас 716 работает — жду.
|
||
- ОБНОВЛЕНИЕ (~20:40): run 406 pid 716 идёт 22+ мин, CPU delta 0/1/1 (слабая активность = медленный стрим от API). Подозрение: claude-cli-proxy (Up 3 weeks) деградировал → медленные ответы. Не трогаю (attempts 2/2), пусть JobReaper решает.
|
||
|
||
## 📡 ORCH-83 [ЭПИК] НАБЛЮДАЕМОСТЬ заведён (08.06 ~20:43 UTC) — Слава заказал
|
||
- **Триггер:** 3 слепые зоны за день — (1) agent-liveness (analyst «завис», лезла в /proc вручную), (2) **диск хоста 93%** (8ГБ/118, никто не алертит!), (3) merge-HOLD молча. Орк автономен но СЛЕП.
|
||
- **Эпик seq=83** id=746c268e-275b-4fa1-8a1c-039349fac300, Backlog. Замысел: `tasks/orchestrator/ORCH-83_OBSERVABILITY_EPIC.md`.
|
||
- **4 слоя:** 83a СБОР (метрики: liveness/очередь/стадии/инфра), 83b АЛЕРТИНГ (пороги→Telegram), 83c ДАШБОРД (live веб), 83d АГЕНТ СОПРОВОЖДЕНИЯ (SRE: отслеживает→реагирует→исправляет→развивает).
|
||
- **Инфра собрана:** 21 контейнер (orch+staging, gitea, plane-app-*×14, claude-cli-proxy, xray, enduro, osrm, gateway). Орк уже имеет /health//status//queue (фундамент) + шлёт в Telegram (notifications.py — переиспользовать для алертов).
|
||
- ⚠️ **Открытые вопросы к Славе (ДО декомпозиции):** (1) стек дэш — Flask vs Grafana+Prometheus (но диск 93%!); (2) агент сопровождения — новый агент/сервис/роль Стрим; (3) что первым — liveness или диск-алерт.
|
||
- НАБЛЮДАЕМОСТЬ = 5-й стратегический кирпич автономности.
|
||
|
||
## 🔥🔥 КРИТИЧЕСКИЙ РЕГРЕСС: --effort ЛОМАЕТ ВСЕХ АГЕНТОВ (08.06 ~20:56 UTC, Слава угадал)
|
||
- **Слава: «эффортсы неправильно применяются» — ПОДТВЕРЖДЕНО боем.** ORCH-81 analyst (run 405+406) дважды высел 1800s таймаут (launcher SIGTERM exit143), 0 вывода. job 637 failed 2/2. Я зря думала «долго думает» — на самом деле пустой выход.
|
||
- **КОРЕНЬ (замеры claude.exe напрямую):**
|
||
- `--print --output-format json --model opus-4-8` **БЕЗ --effort** → 2с, нормальный JSON `result:OK` ✅
|
||
- **`--effort high`** → 0-1с, **ПУСТОЙ stdout+stderr, rc=0** ❌ (молча ничего не делает)
|
||
- **`--effort xhigh`** → тоже пусто ❌
|
||
- **ДИАГНОЗ (УТОЧНЁН — Слава: «проверь прокси или клиент» — я БЫЛА НЕПРАВА про proxy):** claude.exe ходит НАПРЯМУЮ к Anthropic по **OAuth-подписке Claude Max** (`~/.claude/.credentials.json` = claudeAiOauth, sub=max, tier=default_claude_max_5x, scopes user:inference + user:sessions:claude_code). НЕТ ANTHROPIC_BASE_URL/HTTPS_PROXY в env. **claude-cli-proxy В ЦЕПИ НЕ УЧАСТВУЕТ** — чинить его бесполезно.
|
||
- **НАСТОЯЩИЙ корень (УТОЧНЁН по офиц. доке, Слава попросил свериться):** НЕ подписка! **УСТАРЕВШИЙ CLI.** code.claude.com/docs/en/model-config: «**Opus 4.8 requires Claude Code v2.1.154 or later**». У нас на проде **CLI v2.1.142** — СТАРШЕ требуемой для opus-4-8. Рассогласование CLI↔модель ломает `--effort` на opus-4-8 → пустой вывод.
|
||
- ⚠️ МОИ 2 ОШИБКИ ИСПРАВЛЕНЫ: (1) «виноват proxy» — нет (proxy не в цепи); (2) «подписка не поддерживает effort» — нет (дока: Max/Pro поддерживают effort-уровни; дефолт high для Max). Реальная причина — версия CLI.
|
||
- **ФИКС:** ОБНОВИТЬ CLI до ≥v2.1.154 (`claude update` / пересборка образа), сохранив OAuth-креды. → заведена **ORCH-85 [URGENT] seq=85** id=b77d210e-e405-4dd9-9dc2-304d8a59c5dc.
|
||
- **Две задачи заведены (Слава, Backlog):** ORCH-84 seq=84 (id=1b1854d4-...) удалить неиспользуемый cli-proxy (LOW); ORCH-85 seq=85 обновить CLI (URGENT).
|
||
- ⚠️ ПОКА CLI не обновлён — НЕ применять `--effort` (все агенты падают). ORCH-81 висит именно из-за этого. Решение по разблокировке (откат effort vs срочное обновление CLI) — за Славой.
|
||
|
||
## ✅ CLI ОБНОВЛЁН 2.1.142→2.1.168 — ЭФФОРТ ОЖИЛ (08.06 ~21:25 UTC) — Слава: «только обновить CLI сейчас»
|
||
- **Схема обновления (запомнить):** CLI = npm-пакет `@anthropic-ai/claude-code` глобально на ХОСТЕ (`/usr/lib/node_modules/...`, npm prefix /usr, root-owned). В контейнер маунтится read-only как `/opt/claude-code`. node v22, npm 10.9.
|
||
- **Шаги:** (1) бэкап `/home/slin/cli-backup-20260609-002048` (package.json 2.1.142 + credentials); (2) `echo PASS | sudo -S npm install -g @anthropic-ai/claude-code@latest` → 2.1.168; (3) **npm пересоздал каталог с НОВЫМ inode** → контейнерный bind-mount указывал на старый → `claude.exe No such file` в контейнере; (4) **`docker restart orchestrator`** перемонтировал → починилось.
|
||
- ✅ **КРИТ-ТЕСТ пройден:** `--effort high` и `--effort xhigh` на opus-4-8 теперь дают нормальный JSON (rc=0, len~1450). OAuth (sub max) жив. Орк после рестарта здоров (queue_worker/reconciler/reaper started).
|
||
- ⚠️ **МОЙ БАГ при requeue ORCH-81 (РУЧНОЙ, НЕ системный — Слава поправил «время на MSK везде перевели»):** я выставила `available_at` руками через `time.strftime` = localtime (MSK), смешав с UTC-миром БД. Фикс: available_at=NULL.
|
||
- ✅ **ПРАВИЛЬНОЕ ПОНИМАНИЕ TZ (разобралась, была неправа в правиле UTC):** ДВА РАЗНЫХ СЛОЯ, не конфликтуют:
|
||
- 📋 **Логи орка → MSK** (TZ=Europe/Moscow в .env, фикс Славы 08.06, для читаемости). Это про отображение.
|
||
- 🗄️ **БД орка → UTC by design:** весь штатный код пишет время через SQLite `datetime('now')` (ВСЕГДА UTC, независимо от TZ контейнера), и claim сравнивает с тем же `datetime('now')`. Внутри БД всё консистентно (created_at/available_at/updated_at — всё UTC).
|
||
- **ПРАВИЛО (исправлено):** руками В БД орка писать время ТОЛЬКО через `datetime('now')` (как штатный код), НЕ через python time.strftime/now (localtime). Это НЕ противоречит MSK-логам — разные слои.
|
||
- ✅ 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-88 [ЭПИК] ПАКЕТНЫЙ АВТОНОМНЫЙ РЕЖИМ (08.06 ~22:17 UTC) — Слава заказал
|
||
- **Сценарий:** утром 10-20 задач в анализ → днём смотреть BRD → вечером апрув пачкой → ночью автономно реализуются. Семян=88, id=95173987-a029-4878-940a-c205ab8a2be5, Backlog. Анализ: tasks/orchestrator/ORCH-88_BATCH_AUTONOMY_ANALYSIS.md.
|
||
- **ГЛАВНЫЙ ВЫВОД (аудит кода): риск перетирания ЕСТЬ.** max_concurrency=1 = один run за раз, НО claim=FIFO по ДЖОБАМ → джобы разных задач чередуются. **Код-затирание ЗАКРЫТО** (ORCH-26 auto_rebase+lease). **Логический stale-анализ ОТКРЫТ** (аналитик B читал main ДО мержа A → устаревшие файлы — точная формулировка Славы). + git-конфликт rebase при пересечении файлов.
|
||
- **Этап 1 (последовательно):** 1A task-lease (один work-item/репо); **1B фазовый (РЕКОМ) — фаза A вся пачка в анализ / B групповой approve / C последовательная реализация с ре-базой на свежий main**. **Этап 2 (паралл.):** 2A по непересекающимся файлам / 2B merge-очередь+ре-анализ при stale.
|
||
- ⚠️ Открытые вопросы к Славе: 1A vs 1B; approve пачкой vs поотдельно; окно «ночь» cron vs сразу после approve. НАБЛЮДАЕМОСТЬ (ORCH-83) нужна параллельно чтоб видеть прогресс ночного прогона.
|
||
- ✅ **РЕШЕНИЯ СЛАВЫ (22:27):** (1) **Этап 1 = 1B фазовый**; (2) **approve ОТДЕЛЬНО** каждую (не пачкой); (3) **фаза C стартует ПОСЛЕ approve** (не cron); (4) **зависимость ORCH-88 ← ORCH-83** (наблюдаемость обязательна перед боевым пакетным прогоном).
|
||
- ⚠️ **ФАКТ Plane API v1 (проверено + GitHub makeplane #6236):** bulk-операций НЕТ (404), issue-relation (blocked_by/blocking) в API v1 НЕТ (только UI/БД). → «пакетность» реализуется НА СТОРОНЕ ОРКА циклом (single-PATCH работает). Зависимости задач орк хранит у себя (ORCH-26 job_deps), не в Plane. Зависимость 88→83 — текстом в картах (relation в API нет). Реком: label «batch-night» для маркировки пачки (labels API работает).
|
||
|
||
## 🎉🎉 ORCH-080 (52g link-preview) В ПРОДЕ БЕЗ РУЧНОГО ДОМЕРДЖА — ФИКС ORCH-81 РАБОТАЕТ БОЕМ! (08.06 ~22:38 UTC)
|
||
- Слава: «ждём 80ю и спать». ORCH-080 прошла ВЕСЬ конвейер автономно (analyst→arch→dev→review→test→staging SUCCESS) → Awaiting Deploy → я подтвердила Confirm Deploy.
|
||
- ✅✅ **ИСТОРИЧЕСКОЕ: merge-verify CONFIRMED → deploy→done АВТОМАТИЧЕСКИ, БЕЗ моего ручного вмешательства** (впервые за вечер НЕ лезла в PR!). Фикс ORCH-81 (ensure_open_pr) закрыл ПОСЛЕДНИЙ барьер автономного деплоя — конвейер сам создаёт PR и доводит до main. post-deploy-monitor HEALTHY.
|
||
- И побочно подтверждено: ORCH-26 координация работает (merge-lease acquired + auto_rebase onto origin/main в логах).
|
||
- **ИТОГ ВЕЧЕРА:** CLI 2.1.168 + эффорт ожил (52h) + merge-баг закрыт (81) + 52g link-preview в проде (логотип Plane больше не будет под карточками). Бэклог: 83 (эпик мониторинг), 84 (cli-proxy), 86 (reconciler-шум), 87 (трекер+эффорт в карточку), 88 (эпик пакетный режим).
|
||
|
||
## ✅ ORCH-84 ВЫПОЛНЕНА (Стрим вручную, 09.06 ~01:54 MSK) — cli-proxy удалён
|
||
- Слава: «84 сама выполнишь? и сохрани что cli-proxy никогда не использовался и удалён, и таску в done».
|
||
- Инфра-задача (не разработка) → сделала сама. Проверка нулевого использования (env/порт 8317/логи/grep) → бэкап compose → `docker compose down` → образ удалён. Орк жив. **ORCH-84 → Done.** Факт сохранён в MEMORY.md (раздел Orchestrator/Claude CLI).
|
||
- ⚠️ Диск 94% (образ proxy был мелкий, не освободил заметно) — диск-проблема отдельно (ORCH-83/мониторинг).
|
||
|
||
## 📝 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.
|
||
- **Корень (код-аудит):** `_note_unblock` (reconciler.py ~444) шлёт В Telegram. Dedup-guard ORCH-068 ключуется по state_uuid и работает только если state_uuid≠None. НО путь стр.228 (advance_if_gate_passed→_note_unblock) передаёт ТОЛЬКО 2 аргумента без state_uuid → dedup пропускается → шлёт каждый раз. + терминал-скип этот путь не ловит (advance_if_gate_passed считает ET-002 done «продвинувшейся»). Триггерится особенно при СТАРТЕ reconciler (после рестарта). G1 root-cause / G2 терминал-скип на этот путь / G3 state_uuid во все вызовы.
|
||
- **ИРОНИЯ:** фикс ORCH-52h заставил эффорт РЕАЛЬНО применяться (per-role floor) → и тем СЛОМАЛ ЗАПУСК ВСЕХ 6 агентов (до этого эффорт был пустой → флаг не передавался → работало). 074 прошла быстро ИМЕННО потому что эффорт тогда ещё не применялся!
|
||
- **ГОРИТ: СЕЙЧАС ЛЮБОЙ агент орка упадёт** (эффорт применяется ко всем). Варианты фикса: (a) обновить/починить claude-cli-proxy чтоб пробрасывал effort; (b) временно ОТКЛЮЧИТЬ --effort (вернуть пустые env или откат ORCH-52h) пока proxy не чинится; (c) разобраться с proxy. **Ждёт решения Славы (прод-конфиг).**
|
||
|
||
|
||
## 🏁 ИТОГ ДНЯ 08.06 — снимок состояния (запись перед компакцией ~23:00 MSK)
|
||
|
||
**В ПРОДЕ (main = прод, всё задеплоено сегодня):**
|
||
- ORCH-66 статусная модель · ORCH-68 reconciler livelock-фикс · ORCH-71 root-fix фантома #1 (merge-verify по SHA-в-main) · ORCH-73 root-fix #2 (.gitattributes CHANGELOG merge=union + регресс-гард — эрозия main невозможна) · ORCH-26 координация параллелизма (auto_rebase + merge-lease) · ORCH-67 трекер bump+статусы+кликабельные ссылки · ORCH-69 QG0_TITLE_MAX=200 · ORCH-52a (74) мёртвый frontmatter убран + is_valid_model · ORCH-52h (81) per-role floor эффорта · ORCH-81 (082) ensure_open_pr (конвейер сам создаёт PR) · ORCH-80 (52g) disable_web_page_preview · TZ=Europe/Moscow в .env (логи/карточки MSK).
|
||
- **CLI обновлён 2.1.142→2.1.168** (хост npm) → --effort ожил на opus-4-8. Эффорт по ролям: analyst/architect/reviewer=high, **developer=xhigh**, tester/deployer=medium.
|
||
- **claude-cli-proxy УДАЛЁН** (ORCH-84) — никогда не использовался.
|
||
|
||
**🎉 АВТОНОМНОСТЬ ДОСТИГНУТА:** ORCH-080 прошла ВЕСЬ путь до прода БЕЗ единого ручного домержа (merge-verify CONFIRMED авто). Это финальное доказательство — фикс ORCH-81 закрыл последний барьер. Больше НЕ лезть руками в PR.
|
||
|
||
**БЭКЛОГ (заведено, НЕ запущено) — приоритет сверху:**
|
||
- **ORCH-87** (8572689a) MEDIUM — трекер: G0 РАССЛЕДОВАНИЕ bump (сироты/застывший заголовок, НЕ верить моему workaround-диагнозу, собрать данные→ADR) + G1 не оставлять сирот + G2 заголовок не застывает + G3 deploy-статусы видимы + **эффорт в карточку** (`opus-4-8 · xhigh`). Расширена Славой 22:07.
|
||
- **ORCH-83** [ЭПИК] (746c268e) — НАБЛЮДАЕМОСТЬ (4 слоя: сбор/алертинг/дашборд/SRE-агент). Открытые вопросы к Славе ДО декомпозиции (Flask vs Grafana при диске 94%; SRE-агент = кто; liveness vs диск первым). **Блокер для ORCH-88.**
|
||
- **ORCH-86** (d8133fbe) MEDIUM — reconciler шлёт шум «ET-002 done разблокирована» (путь advance_if_gate_passed→_note_unblock без state_uuid → dedup пропускается).
|
||
- **ORCH-88** [ЭПИК] (95173987) — пакетный автономный режим (утром анализ→днём смотреть BRD→вечером approve поотдельно→ночью реализация). Этап 1=1B фазовый. Зависит от ORCH-83. Plane API v1 НЕ умеет bulk/relations → пакетность на стороне орка циклом.
|
||
- ORCH-52 [ЭПИК] + подзадачи 52b/c/d/e/f (стандарт доков, handoff, оптимизация промптов, трассировка ORCH-NNN, README-синк) — пусть в бэклоге.
|
||
|
||
**⚠️ ГЛАВНЫЕ УРОКИ ДНЯ (закрепить):**
|
||
1. **НЕ смешивать ручные git-операции с автономным конвейером** (reset --hard ломает deploy-hook git pull + provenance guard). Повтор ORCH-71/26.
|
||
2. **Прежде чем убивать «зависший» агент — проверить CPU pid** (/proc/PID/stat utime+stime delta + socket). `--output-format json` пишет результат В КОНЦЕ → пустой лог при живом процессе = НОРМА. Зря убила analyst 405.
|
||
3. **НЕ доверять отчётам агентов о тестах** — гнать pytest самой + сверять маркеры всех фич (sonnet рапортовал «passed» на НЕПОЛНОМ дереве без 059).
|
||
4. **TZ — два слоя:** логи орка=MSK (.env), БД орка=UTC by design (`datetime('now')`). Руками в БД писать ТОЛЬКО через `datetime('now')`, не python localtime.
|
||
5. **Правки хост-репо (docker-compose и др. git-файлы) НЕ переживают деплой** (git reset --hard их откатывает) → конфиг в .env.
|
||
6. **--effort требует CLI ≥2.1.154 для opus-4-8** (офиц.дока). Старый CLI → пустой вывод, агенты висят 1800s.
|
||
7. **CHANGELOG.md = частый источник дорогих merge-конфликтов** при параллельных задачах → .gitattributes merge=union (решено ORCH-73).
|
||
8. **Plane seq-id (ORCH-NN) ≠ work_item_id орка (ORCH-0NN)** — сопоставлять по названию, не по номеру.
|
||
|
||
**Состояние на ночь:** прод здоров, 0 открытых PR, бэклог чистый, конвейер свободен. Слава ушёл спать после ORCH-080.
|
||
|
||
## 📝 ORCH-89 заведена — авто-approve BRD технических задач (08.06 ~23:00 UTC, Слава заказал)
|
||
- **Правило разделения ответственности:** технические задачи → BRD подтверждает **Стрим сама** (Слава в техдеталях не разбирается); **бизнес-задачи** → остаются за Славой.
|
||
- seq=89 id=467c3f70-1dc7-457b-939d-7593c06c7704, **Backlog**, на потом. Не запускать без отдельного решения.
|
||
- Суть: признак классификации technical/business → на стадии In Review (approve-pending BRD): technical=Стрим approve, business=Слава approve.
|
||
- Открытые вопросы (решить при заведении в работу): как классифицировать (метка/поле/эвристика/Стрим решает); кто подтверждает technical (Стрим вручную через review+PATCH vs орк авто-confirm по флагу); fail-safe (неизвестно → ждать Славу).
|
||
|
||
## ✅ ORCH-86 BRD APPROVED — СТРИМ САМА (08.06 ~23:05 UTC, первое применение правила ORCH-89)
|
||
- Слава: «Проверь БРД и согласуй сама» — ORCH-86 техническая → подтвердила сама (правило разделения, ORCH-89).
|
||
- **Проверила BRD(11к)/ТЗ(10к)/AC(5к)/test-plan(5к) лично** в worktree feature_ORCH-086. ЭТАЛОН — аналитик точно воспроизвёл мой код-аудит + углубил:
|
||
- root-cause: F-1 путь (reconciler.py стр.228 advance_if_gate_passed→_note_unblock) шлёт БЕЗ state_uuid → dedup ORCH-068 пропускается; терминал-скип ORCH-068 (_is_terminal_state) зовётся ТОЛЬКО из F-2 (стр.362). G1/G2/G3.
|
||
- ТЗ: точечно только reconciler.py, TR-1 терминал-скип на F-1 (группа Plane completed/cancelled + fallback ключ done/cancelled → мультипроект enduro/orch), TR-2 проброс state_uuid, TR-3 переиспользовать fetch Guard 2 (не удваивать сетевой вызов). Схема/QG/config не трогаются.
|
||
- AC: 6 PASS/FAIL. Главное AC-4 (анти-регресс: легитимный unblock реально застрявшей задачи СОХРАНЯЕТСЯ — не задушить полезный алерт) + AC-2 грабли R1 (оба проекта).
|
||
- Открытый вопрос G1 (точная стадия ET-002 в БД) честно отмечен аналитиком для подтверждения в development по prod-логам.
|
||
- **PATCH In Review→Approved (200)** state=63f2c8fe. Webhook → architect. Идёт автономно.
|
||
- 🎯 Первое боевое применение ORCH-89: технический BRD согласован Стримом без Славы.
|