auto-sync: 2026-06-08 23:30:01

memory/2026-06-08.md

@@ -374,3 +374,7 @@
 - Критичная для автономности: чинит саму 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 работает — жду.