auto-sync: 2026-06-15 19:50:01

memory/2026-06-15.md

@@ -1,96 +1,7 @@
-(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`.
-
-## 2026-06-15 — ORCH-115 deterministic deploy runner
-
-- По обсуждению со Славой заведена задача **ORCH-115**: `ORCH: replace LLM deployer with deterministic deploy runner`.
-- Plane UUID: `d3bf021f-a862-4ed3-88cb-5acd40b407f8`, sequence_id `115`, priority `high`, state `Backlog`.
-- Мотивация: LLM-deployer в happy path деплоя почти не нужен — staging/deploy должны быть детерминированными: команда → exit code → machine verdict artifact → healthcheck.
-- Scope:
-  - Phase 1: для `orchestrator` заменить LLM `deployer` на `deploy-staging` детерминированным runner: staging_check + `15-staging-log.md` writer.
-  - Phase 2: project deploy contract для non-self repos (`enduro-trails` и похожие): deploy/rollback/healthcheck/artifact paths/service metadata.
-  - LLM оставить только как fallback/debug analyst после deterministic failure, не как основной исполнитель deploy.
-- Boundaries: не смешивать с ORCH-112 cleanup и ORCH-114 transition lease/smart recovery.
-
-## 2026-06-15 — ORCH-116 deterministic test runner
-
-- По обсуждению со Славой заведена задача **ORCH-116**: `ORCH: replace LLM tester with deterministic test runner`.
-- Plane UUID: `ee4eab7e-8f28-46fc-9ca7-1ac3eadb6733`, sequence_id `116`, priority `high`, state `Backlog`.
-- Мотивация: LLM-tester в happy path частично избыточен — pytest/smoke/contract checks должны быть детерминированными: команда → exit code → `13-test-report.md` с `result: PASS|FAIL`.
-- Scope:
-  - deterministic test runner + test contract;
-  - запуск pytest/smoke/contract checks в task worktree;
-  - byte-compatible `13-test-report.md`;
-  - LLM tester только optional fallback для failure analysis, AC coverage gaps и human-readable diagnostics.
-- Boundaries: не смешивать с ORCH-115 deploy runner; developer/reviewer LLM роли не трогать; сохранить `check_tests_passed` contract и backward compatibility для реп без test contract.
-
-## 2026-06-15 — pre-compaction note
-- Probed ORCH-114 work-item docs at `tasks/orchestrator/docs/work-items/ORCH-114/*`; those paths were missing in workspace at the time of check. Before any follow-up edits, re-locate the canonical ORCH-114 docs in the repo tree instead of assuming the work-item folder layout.
+## 2026-06-15 — ORCH-114 RCA note
+- Root cause of the false ORCH-114 `Done`: the worktree test run executed a live `src.plane_sync.notify_stage_change('ORCH-114', 'deploy', 'done')` path against the real Plane API.
+- Evidence: Plane API logs at 16:22 UTC show `PATCH /issues/dd57ad23.../` to state UUID `3738cd3c...` (`Done`) followed by `POST /comments/` with `Stage: deploy → done` and branch `feature/orch114`.
+- Runtime config check: both `orchestrator` and `orchestrator-staging` containers currently point at the same Plane workspace slug `ag_proj` and share the live `ORCH_PLANE_API_TOKEN`; no separate sandbox Plane project is wired into the live env.
+- Code registry check: `src/projects.py` currently maps only the ET and ORCH production Plane project IDs; no sandbox project mapping is active in runtime.
+- Fix direction: enforce hard Plane-write isolation for test/staging runs (mock or sandbox-only token/project), so any ORCH-114 test cannot mutate the live ORCH project.