diff --git a/memory/2026-06-15.md b/memory/2026-06-15.md
new file mode 100644
index 0000000..96f0e39
--- /dev/null
+++ b/memory/2026-06-15.md
@@ -0,0 +1,40 @@
+(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.
+