wiki/memory/2026-06-09.md

2026-06-09 — Дневник

🔍 ORCH-087 БЫЛА ЗАСТРЯВШЕЙ 6.5ч — разморозила (05:27 MSK, Слава заметил «статусы неактуальны»)

• Слава: «посмотри что висит в deploying/monitoring, статусы неактуальные».
• ⚠️ Ложная тревога #1 снята: Plane API v1 запрос ?state=<uuid> НЕ фильтрует — вернул ВСЕ 89 issue в каждом deploy-статусе. Это артефакт API, не реальное состояние. Реальный статус — только прямым GET issue.
• ⚠️ Ложная тревога #2 снята: коммиты analyst(ET) у ВСЕХ ORCH-задач (082/086) — безобидный хардкод-префикс commit-helper, repo=orchestrator правильный. Не баг.
• 🎯 РЕАЛЬНЫЙ баг — ORCH-087 (task 64) застряла: история состояний Plane:
  • 22:49:44 Backlog→To Analyse→Analysis
  • 22:54:25 Analysis→In Review (analyst job 718/run 420 отработал успешно, BRD/ТЗ/AC эталон, $1.24)
  • 22:56:49 In Review→Backlog ❗ — задачу ОТКАТИЛО в Backlog через 2.5 мин (вероятно мой PATCH/гонка при создании ORCH-89 в то же время ИЛИ sweeper)
  • Итог: Plane=Backlog, БД орка=analysis с НЕзакрытым brd_review_ended_at=None, 0 активных jobs → мёртвая задача 6.5ч
• Фикс (правило ORCH-89, техническая → согласовала сама): проверила BRD/ТЗ/AC в worktree (эталон, оба требования учтены: G0-расследование bump + эффорт в карточку) → закрыла BRD-clock (brd_review_ended_at=datetime('now')) → Plane Backlog→Approved (PATCH 200) → webhook подхватил → architect job 770/run 426 running, stage=architecture. Разморожена.
• ⚠️ УРОК: одновременные ручные PATCH-операции в Plane (я создавала ORCH-89 + патчила статусы) могут откатить задачу с In Review в Backlog (гонка/случайное наложение). Когда задача на In Review ждёт approve — НЕ трогать соседние операции в Plane, либо проверять что approve-pending не сбросился. Застрявшую In Review→Backlog ловить по brd_review_ended_at IS NULL + stage=analysis + 0 jobs.

⤷ ORCH-087 расширена 2 замечаниями Славы (09.06 ~05:33 MSK) — оба верны

• Слава (reply на карточку 087): «(1) мы же нотифай меняли в 86, 87 должна использовать свежий; (2) в карточке время итоговое неправильно считается».
• G6 — пересечение 86↔87 (Слава ПРАВ, риск эрозии): ORCH-86 СЛИТА в main (PR #86, merge 493b9be: F-1 terminal-skip + state_uuid в reconciler.py). НО ветка 087 срезана от 9281788 (ДО 86), отстала на 9 коммитов, трогает src/reconciler.py+tests/test_reconciler.py — ТЕ ЖЕ файлы что 86. Domerge как есть → затрёт 86 (эрозия, .gitattributes union спасает только CHANGELOG не reconciler.py).
  • Решение: ORCH-26 auto_rebase_onto_main сработает на merge-gate (merge_gate.py:113, rebase+force-with-lease ТОЛЬКО ветку). При конфликте reconciler.py → откат на development, dev переделает на свежей базе. Штатно, НЕ лезть руками под работающий конвейер (урок ORCH-26/71). G6 вписан в ТЗ 087.
• G5 — итоговое время в карточке врёт (Слава ПРАВ, код-аудит notifications.py): финальная строка ⏱️ Всего <wall> · агенты <agent_seconds> · твоё <review>:
  • agent_seconds=Σ(finished−started) agent_runs — КОРРЕКТНО.
  • review_seconds=brd_review_ended−started — РАЗДУВАЕТСЯ при застое (087 показал «Подтверждение BRD 392м» = мой 6.5ч застой In Review→Backlog, не реальное обдумывание).
  • wall=updated_at−created_at — включает ВСЁ ожидание/простой/queue-wait → не сходится с agent+review.
  • G5: честно разделить рабочее (Σ agent_runs) / ожидание человека (только фактическое, без аномалий застоя) / wall (помечать «с ожиданием», не выдавать за работу); итог должен сходиться. AC: задача с искусств. застоем 6ч → «твоё время» НЕ показывает 6ч.
• PATCH ORCH-087 desc 200 (16767 симв). Задача идёт: analyst→architect(done, ADR корень=гонка update_task_tracker из ≥5 потоков без замка)→developer running (job 771).
• ⚠️ Следить: на merge-gate 087 ОБЯЗАН отребейзиться на main с 86. Проверить что reconciler.py 86 НЕ затёрт после merge 087 (регресс-гард ORCH-73 check_main_regression должен поймать).