(see attached image)

## 2026-06-15 — ORCH / watchdog / deploy notes

- ORCH-109 («timeout budgets + launch-time model telemetry») доведена до `done`, PR #129 merged. Реально проверено:
  - agent timeouts in prod: developer=3600s, reviewer=3000s, default/others=1800s.
  - отдельный merge-gate re-test timeout остаётся 600s (10 минут) — это НЕ часть ORCH-109, заведено отдельно.
  - ORCH-109 сначала залипла в `development` после `CI pending after 120s`: developer job done, CI стал green позже, но stage не был повторно продвинут.
  - Пнула штатно через `advance_if_gate_passed`: задача пошла в review/testing/deploy и после чистки старых pytest-хвостов смержилась.
- Watchdog:
  - `orchestrator-watchdog` был не запущен; после старта сразу увидел `stage_stuck ORCH-109`.
  - heartbeat-watchdog Стрим фактически не работал: `/tmp/orch_watch.py` в контейнере отсутствовал, `memory/heartbeat-state.json` был старый.
  - Watchdog следит за стадиями/контейнерами/health, но не видел старые отдельные pytest-процессы.
- Старые зависшие процессы:
  - Найдены и прибиты 5 старых `python3 -m pytest tests/test_install_lite_script.py ...`, жившие >2 суток и грузившие CPU.
  - Это были хвосты ORCH-104 (Lite installer), не ORCH-109.
  - Они мешали merge-gate local re-test и привели к timeout despite green CI.
- Plane bugs created:
  - ORCH-110 — `BUG: merge-gate local re-test timeout causes false rollback after green CI` (Backlog, high). Без описания решения, только факты/симптомы.
  - ORCH-111 — `BUG: watchdog must alert on long-lived pytest/child processes that block the pipeline` (Backlog, high). По просьбе Славы: мониторинг таких процессов обязателен, иначе автономности нет.
  - ORCH-112 — `BUG: failed/cancelled task artifacts must be cleaned from shared checkout` (Backlog, urgent). Про cleanup/rollback мусора после failed/cancelled задач.
- ORCH-111:
  - Аналитик эскалировал багу в полный цикл: `track=full`, не fast-track.
  - ORCH-111 проходила full pipeline, но self-deploy упал на dirty checkout.
  - После очистки checkout и prod deploy задача была пнута заново; последний известный статус: стадия `Testing`, reviewer прошёл, tester run_id=682 / job=1913 активен.
- Dirty checkout incident:
  - Прод-деплой ORCH-111 упал на `git pull origin main` из-за локальных незакоммиченных изменений в `/home/slin/repos/orchestrator/src/config.py`.
  - Грязь относилась к ORCH-104/Lite installer: `src/config.py`, `docs/deployment/LITE_SETUP.md`, `scripts/install_lite.py`, `tests/test_install_lite.py`, `docs/deployment/lite-install.example.yaml`.
  - Причина: старый запуск орка оставил файлы в общем checkout main, нарушив изоляцию. Сохранён backup `/home/slin/orchestrator-dirty-backup-20260615-082102`, checkout очищен до `origin/main`, prod deploy затем прошёл успешно.
- Self-deploy notes:
  - Deploy hook по умолчанию деплоит staging; для prod нужно явно задавать `TARGET_SERVICE=orchestrator`, `TARGET_PORT=8500`, `PREV_IMAGE_FILE=.deploy-prev-image-prod`.
  - После prod deploy `/health → ok`, контейнер `orchestrator` жив на свежем main.
- Tokenator / Opus 4-8:
  - `claude-opus-4-8` есть в Tokenator `/models`, правильный id именно `claude-opus-4-8`.
  - Прямой completion падает HTTP 402 `Insufficient balance` / balance_rub=0.
  - `gpt-5.5` через тот же ключ отвечает, значит API/key живы; проблема именно баланс для Opus.
- Plane availability:
  - Plane сам был жив: сайт и API отвечали 200, контейнеры Up.
  - Если у одного провайдера не открывается, а у другого открывается — вероятная причина DNS/маршрут/IPv6/фильтрация у провайдера, не Plane.


## 2026-06-15 — ORCH-111 / reaper гонка / ORCH-113

- Разобран инцидент повторной обработки `deploy-staging` у ORCH-111:
  - `deployer` успешно завершил агентскую часть (`exit_code=0`, staging log SUCCESS), но job ещё оставался `running`, потому что live-monitor/finalizer продолжал тяжёлую послеагентную финализацию: комментарии, stage transition, security-gate, merge-gate, re-test, prod-deploy.
  - `job-reaper` через grace ~300s решил, что это «exit0 but finalizer died», и повторно запустил финализацию deploy-staging.
  - Из-за этого параллельно пошли повторные security/merge-gate/re-test; повторный local re-test стал красным и откатил задачу `deploy-staging → development`, пока оригинальная финализация уже доводила prod-deploy до SUCCESS.
  - Ключевой вывод: 300s grace недостаточен для тяжёлых deploy-staging финализаций; reaper не должен повторно дёргать stage finalization, пока оригинальный monitor/finalizer ещё жив или есть активный lease/heartbeat финализации.
- ORCH-111 в итоге стала `done`:
  - prod deploy был уже выполнен успешно; последующий developer run после отката не внёс кодовых изменений/коммита.
  - finalizer увидел, что нужные post-deploy/prod артефакты уже успешны, и задача дозавершилась.
  - В БД: task ORCH-111 `stage=done`, updated_at `2026-06-15 06:14:26`; был создан/queued post-deploy-monitor job.
- По просьбе Славы заведена новая urgent bug-task:
  - **ORCH-113** — `BUG: job-reaper must not re-run deploy-staging finalization while original finalizer is alive`
  - Plane/work item id: `ORCH-113`, UUID `b9fcbeef-00cd-47fc-9874-2ace9b70b7e9`, state `Backlog`, priority `urgent`.
  - Суть: запретить ситуацию, где reaper считает job потерянной и повторно запускает deploy-staging/merge-gate, пока оригинальная финализация всё ещё выполняется и может успешно довести задачу до prod/done.

## 2026-06-15 — systemic audit ORCH-110/112/113 → ORCH-114

- По просьбе Славы проведён системный разбор класса отказов вокруг ORCH-111:
  - **ORCH-110** закрывает только merge-gate re-test infra-timeout: tree-kill pytest, классификация timeout как infra, bounded retry, пропуск no-op re-test. Это снижает шанс ложного rollback, но не даёт ownership на stage transition.
  - **ORCH-112** закрывает dirty shared checkout/artifacts после failed/cancelled задач и перед self-deploy. Это предотвращает `git pull origin main` failure, но не чинит конкурирующие finalizer/reaper/reconciler/webhook входы.
  - **ORCH-113** закрывает immediate bug: job-reaper не должен повторно запускать живую deploy-staging финализацию. Но формально это только reaper-vs-monitor.
- Найден незакрытый системный gap: нет единого ownership lease/heartbeat на side-effectful `advance_stage` transition. Потенциальные re-entry источники: live monitor, job-reaper, startup `requeue_running_jobs`, reconciler F-1, webhook advance path. Последствия: двойные security/merge/coverage/image-freshness/prod-deploy side effects и противоречивые rollback/done outcomes.
- Создана urgent Plane-задача:
  - **ORCH-114** — `BUG: pipeline stage transitions need ownership lease and smart startup recovery`
  - UUID `dd57ad23-7902-4d94-8ac4-c2a07b453781`, state Backlog, priority urgent.
  - Scope: explicit transition/finalization ownership lease или heartbeat; job-reaper/startup requeue aware of live/stale finalization; CAS/transition epoch для side-effectful transitions; reconciler/webhook skip при active transition lease; observability + regression tests для deploy-staging/deploy-finalizer/restart recovery.
- В Plane добавлены scope comments к ORCH-110/112/113, чтобы разграничить ответственность и не потерять gap.
- Онтология обновлена: `task_orch_114_transition_lease` linked to `proj_orchestrator`.