Compare commits

..

21 Commits

Author SHA1 Message Date
post-deploy-monitor
d10004f04d docs(ORCH-021): post-deploy HEALTHY/NONE for ORCH-112
All checks were successful
CI / test (push) Successful in 1m6s
2026-06-15 15:57:56 +03:00
deploy-finalizer
285f5f05dc deploy(ORCH-036): finalize SUCCESS for ORCH-112
All checks were successful
CI / test (push) Successful in 3m9s
CI / test (pull_request) Successful in 3m11s
2026-06-15 15:33:15 +03:00
344ab72f37 tester(ET): auto-commit from tester run_id=706
All checks were successful
CI / test (push) Successful in 3m59s
CI / test (pull_request) Successful in 3m9s
2026-06-15 15:15:56 +03:00
7f673a45f7 reviewer(ET): auto-commit from reviewer run_id=705 2026-06-15 15:15:56 +03:00
a1f3b7588a fix(deploy): resilient-pull hygiene for dirty shared deploy-base (ORCH-112)
Self-deploy git pull blocked on a dirty shared main checkout (manual/abandoned
WIP from a failed/cancelled task) — incident ORCH-111: "Your local changes to
src/config.py would be overwritten by merge" wedged the prod deploy and required
manual intervention (a group risk on self-hosting).

The deploy hook (--deploy) now converges the deploy-base to a clean, current
origin/main BEFORE the pull (git fetch + reset --hard origin/main + a SCOPED
`git clean -fd`, NEVER -x), strictly preserving the rollback/log artefacts
(.deploy-prev-image-* / deploy-hook.log via -e), gitignored .env/data/*.db/build
(no -x), and sibling/.git state (out of clean scope). Gated by CHECKOUT_HYGIENE
env injected by self_deploy.build_deploy_command only when the new pure never-raise
leaf src/checkout_hygiene.py says applies(repo) (kill-switch + self-hosting scope).
Convergence after failed/cancelled is this same deploy-time self-heal — cancel_task
is NOT extended and no background janitor is introduced. Observability: the hook
writes a `hygiene` sentinel, the Phase-C finalizer reads it and sends a best-effort
Telegram alert.

Additive, under kill-switch (ORCH_CHECKOUT_HYGIENE_ENABLED, default true; off ->
bare `git pull origin main` 1:1 before ORCH-112), never-raise, self-hosting scope.
STAGE_TRANSITIONS / QG_CHECKS / check_* / machine-verdict keys / DB schema / the
hook exit-code contract (0/1/2, ORCH-036) are byte-for-byte untouched.

Coverage: tests/test_deploy_checkout_hygiene.py (TC-01..TC-10; real-hook shell
simulation in a temp git repo, no network/prod/ssh, + unit). TC-01 is the
mandatory ORCH-111 regression (RED before the fix, GREEN after). Docs golden
source updated in the same PR (CLAUDE.md, CHANGELOG.md, .env.example; INFRA.md /
architecture/README.md / adr-0044 written at the architecture stage).

Refs: ORCH-112

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 15:15:56 +03:00
31b4f3fd1d architect(ET): auto-commit from architect run_id=703 2026-06-15 15:15:56 +03:00
96b653d11c architect(ET): auto-commit from architect run_id=702 2026-06-15 15:15:56 +03:00
860de5b0a5 analyst(ET): auto-commit from analyst run_id=701 2026-06-15 15:15:56 +03:00
c086921aa1 docs: init ORCH-112 business request 2026-06-15 15:15:56 +03:00
0af5d7563c Merge pull request 'docs(ORCH-112): staging gate log artifact — SUCCESS' (#137) from deployer/ORCH-112-staging-log into main 2026-06-15 15:14:51 +03:00
eb1b7aa056 docs(ORCH-112): staging gate log artifact — SUCCESS
All checks were successful
CI / test (pull_request) Successful in 3m52s
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 15:14:32 +03:00
a1544f4677 Merge pull request 'ORCH-113: reaper must not re-run deploy-staging finalization while the finalizer is alive' (#134) from feature/ORCH-113-bug-job-reaper-must-not-re-run into main
Some checks failed
CI / test (push) Has been cancelled
2026-06-15 13:51:54 +03:00
deploy-finalizer
c8faa1ec23 deploy(ORCH-036): finalize SUCCESS for ORCH-113
All checks were successful
CI / test (push) Successful in 3m9s
CI / test (pull_request) Successful in 3m5s
2026-06-15 13:51:44 +03:00
b62e196710 developer(ET): auto-commit from developer run_id=699
All checks were successful
CI / test (push) Successful in 3m22s
CI / test (pull_request) Successful in 3m43s
2026-06-15 13:43:22 +03:00
7523b843a5 tester(ET): auto-commit from tester run_id=696
All checks were successful
CI / test (push) Successful in 4m41s
CI / test (pull_request) Successful in 4m1s
2026-06-15 13:08:41 +03:00
adeffbb39a reviewer(ET): auto-commit from reviewer run_id=695 2026-06-15 13:08:41 +03:00
7cb1f83f6c fix(reaper): do not re-run deploy-staging finalization while finalizer is alive
On the deploy-staging -> deploy edge the live monitor stamps
agent_runs.finished_at FIRST, then runs the heavy edge sub-gates
(security/merge-gate re-test/coverage/image-freshness) in-thread for MINUTES
and only THEN _finalize_job. Reaper Tier-2 measures finished_age_s from
finished_at, so past reaper_finalize_grace_s it treated the live, long
finalizer as dead and independently re-ran the advance -> a second re-test
went red -> false rollback deploy-staging -> development while the original
finalizer concurrently merged the PR (incident ORCH-111, job 1914).

Add a process-local finalizer-ownership registry (src/finalizer_liveness.py,
never-raise): the monitor mark()s ownership right after the exit_code stamp and
clear()s it in a try/finally around the (verbatim-extracted) finalization tail,
so an exception in the monitor thread still releases ownership and a genuinely
dead finalizer is reaped. The reaper Tier-2 consults the marker only when the
kill-switch is on AND the task stage == deploy-staging AND ownership is active
-> DEFER (no second advance) and fall through to the Tier-3 backstop, which
ignores the marker (a stuck/dead finalizer is still reaped in bounded time).
In-memory is authoritative (monitor + reaper are daemon threads of one uvicorn
process); restart is covered by the startup requeue_running_jobs.

Additive, global kill-switch reaper_finalizer_liveness_enabled (default True;
false -> reaper byte-for-byte prior). STAGE_TRANSITIONS / QG_CHECKS / every
check_* / machine-verdict keys / DB schema unchanged; grace/ceiling and the
ORCH-065/109/110 budget invariant untouched; never restarts prod, never pushes
main. Observability: finalizer_defers_total + finalizer_owned in GET /queue.
Tests: tests/test_orch113_reaper_finalizer_liveness.py (TC-01..TC-08, incl. the
mandatory ORCH-111 regression: red before the fix, green after).

Refs: ORCH-113

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-15 13:08:41 +03:00
1e74b9d042 architect(ET): auto-commit from architect run_id=693 2026-06-15 13:08:41 +03:00
425ecb7585 analyst(ET): auto-commit from analyst run_id=692 2026-06-15 13:08:41 +03:00
55e9483fb8 docs: init ORCH-113 business request 2026-06-15 13:08:41 +03:00
ae75b1650b Merge pull request 'docs(ORCH-113): staging gate log — SUCCESS (8/10, C9a/C9b infra-waived)' (#135) from docs/ORCH-113-staging-log into main 2026-06-15 13:07:50 +03:00
47 changed files with 3759 additions and 18 deletions

View File

@@ -340,6 +340,15 @@ ORCH_DEPLOY_PROD_TARGET_IMAGE=orchestrator-orchestrator
ORCH_DEPLOY_PROD_COMPOSE_PROFILE=
ORCH_DEPLOY_PROD_PREV_IMAGE_FILE=.deploy-prev-image-prod
# ORCH-112: deploy-base checkout-hygiene (resilient-pull). The self-deploy hook
# converges a DIRTY shared deploy-base to a clean, current origin/main BEFORE the
# `git pull` (git fetch + reset --hard + a SCOPED `git clean -fd`, NEVER `-x`), so
# manual/abandoned WIP left by a failed/cancelled task never blocks the deploy
# (incident ORCH-111). False -> bare `git pull origin main` 1:1 as before ORCH-112.
# Empty REPOS -> only the self-hosting repo (orchestrator).
ORCH_CHECKOUT_HYGIENE_ENABLED=true
ORCH_CHECKOUT_HYGIENE_REPOS=
# ORCH-058: staging-image provenance before the BUILD-ONCE prod retag (INV-FRESH).
# Guarantees the staging image promoted to prod is the EXACT artefact rebuilt from the
# validated commit — two layers, self-hosting only:

View File

@@ -1,4 +1,4 @@
Work item: ORCH-110
Work item: ORCH-112
Repo: orchestrator
Branch: feature/ORCH-110-bug-merge-gate-local-re-test-t
Branch: feature/ORCH-112-bug-failed-cancelled-task-arti
Stage: development

View File

@@ -3,6 +3,16 @@
Формат: [Keep a Changelog](https://keepachangelog.com/). Записи — на смысловой PR/задачу.
## [Unreleased]
- **Гигиена shared deploy-базы: устойчивый self-deploy `git pull` к грязному дереву** (ORCH-112, `fix`, bug→escalate full-cycle): устранён инцидент ORCH-111 — self-deploy падал на шаге `git pull origin main` хост-хука с `error: Your local changes to the following files would be overwritten by merge: src/config.py` (грязь от неуспешной/отменённой/брошенной задачи ORCH-104 в общем main checkout) → деплой вставал → ручное вмешательство (на self-hosting — групповой риск). Решение — **resilient-pull, встроенный в прод-deploy-хук** (`--deploy`): перед `git pull` хук при обнаружении грязи приводит deploy-базу к чистому актуальному `origin/main` (`git fetch` + `git reset --hard origin/main` + **скоупленный** `git clean -fd`). Аддитивно, под kill-switch, never-raise, скоуп self-hosting; `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` / machine-verdict-ключи / схема БД / exit-code-контракт хука (0/1/2, ORCH-036) — **байт-в-байт не тронуты** (это устойчивость deploy-пути, **не** Quality Gate и **не** стадия). ADR: `docs/work-items/ORCH-112/06-adr/ADR-001-deploy-base-checkout-hygiene.md`, сквозной `docs/architecture/adr/adr-0044-deploy-base-checkout-hygiene.md`.
- **Leaf `src/checkout_hygiene.py` (новый, чистый never-raise):** по образцу `serial_gate`/`cancel`/`self_deploy` (импортирует только `config`, лениво `self_deploy`/`qg.checks`/`notifications`) — `applies(repo)` (kill-switch `checkout_hygiene_enabled` + скоуп `checkout_hygiene_repos`, пусто → self-hosting only, локально и ПЕРВЫМ), `hook_env(repo, work_item_id)` (env-префикс `CHECKOUT_HYGIENE=1 HYGIENE_REPORT=<host-path>`, инжектится в detached-команду хука только при `applies==True`, иначе `""` → голый pull 1:1), `read_report`/`alert_dirty` (наблюдаемость), `snapshot()` (read-only блок `GET /queue`).
- **Хук-блок «2a. Resilient pull» (`scripts/orchestrator-deploy-hook.sh`):** между шагом «1. Capture PREV_IMG» и «2. Pull», под `if [[ "${CHECKOUT_HYGIENE:-0}" == "1" ]]`. **Сохранность (NFR-2, жёсткий контракт):** `git clean`**только `-fd`, НИКОГДА `-x`** (иначе удалил бы gitignored `.env`/прод-секреты, `data/*.db`/БД, `build/`); явные `-e '.deploy-prev-image-*'` и `-e 'deploy-hook.log'` (untracked-но-НЕ-ignored — иначе сломался бы rollback `do_rollback`); sibling `<repos_dir>/.deploy-state-*`/`.merge-lease-*.json` (под родителем `$REPO`) и `.git/worktrees/*` (внутри `.git/`) — вне области `git clean` в `$REPO`. Каждый git-шаг — `|| log "...continuing"` (never-break): сбой гигиены не ухудшает исход относительно текущего голого pull; на чистой базе блок — no-op (happy-path и exit-коды байт-в-байт). `--build-staging` (build из worktree, без pull) не затронут.
- **Сходимость после failed/cancelled (FR-2)** — этим же deploy-time self-heal (база сходится на следующем же self-deploy); `cancel_task` (ORCH-090) **не расширяется**, фоновый janitor **не вводится**. **Наблюдаемость (FR-4)** — хук пишет sentinel `hygiene` в deploy-state каталог; Phase-C finalizer (`stage_engine.run_deploy_finalizer`) читает (`read_report`) и шлёт Telegram-алерт (`alert_dirty`, кликабельный номер, best-effort, never-raise — сбой алерта не валит деплой).
- **Флаги** (`config.py`, дефолт = боевое): `checkout_hygiene_enabled` (env `ORCH_CHECKOUT_HYGIENE_ENABLED`), `checkout_hygiene_repos` (env `ORCH_CHECKOUT_HYGIENE_REPOS`). Откат = `ORCH_CHECKOUT_HYGIENE_ENABLED=false` → деплой байт-в-байт до ORCH-112. Покрытие — `tests/test_deploy_checkout_hygiene.py` (TC-01…TC-10: шелл-симуляция реального хука во временном git-репо без сети/прода/ssh + unit; TC-01 — обязательный регресс ORCH-111: КРАСНЫЙ до фикса, ЗЕЛЁНЫЙ после).
- **Job-reaper не реапит живой долго финализирующий монитор `deploy-staging`** (ORCH-113, `fix`, bug→escalate full-cycle): устранено расхождение состояния из инцидента ORCH-111 (deployer job 1914 / run_id 683). На ребре `deploy-staging → deploy` живой монитор (`launcher._monitor_agent`) штампит `agent_runs.finished_at`/`exit_code` **первым**, затем синхронно в своём потоке прогоняет тяжёлые edge-под-гейты (`security → merge-gate re-test → coverage → image-freshness`) — **минуты** — и лишь потом `_finalize_job`. Reaper Tier-2 меряет `finished_age_s` от `finished_at` (= начала финализации), поэтому по истечении `reaper_finalize_grace_s=300` трактовал живого долго финализирующего монитора как мёртвого и **независимо** повторял тот же тяжёлый advance: повторный re-test стал красным → ложный откат `deploy-staging → development` (+ ложный developer-retry) **параллельно** с тем, что исходный finalizer довёл deploy до SUCCESS и смержил PR — состояние раздвоилось. Аддитивно, под глобальным kill-switch, never-raise; `STAGE_TRANSITIONS`/`QG_CHECKS`/каждый `check_*`/machine-verdict ключи/схема БД — **байт-в-байт не тронуты**; `reaper_finalize_grace_s`/`reaper_max_running_s` и сквозной бюджет ORCH-065/109/110 (`5400 > Σ(gate-work)+grace`) сохранены; фикс не рестартит прод и не пушит `main`. ADR: `docs/work-items/ORCH-113/06-adr/ADR-001-reaper-finalizer-liveness-ownership.md`, сквозной `docs/architecture/adr/adr-0043-reaper-finalizer-liveness-ownership.md`.
- **Leaf `src/finalizer_liveness.py` (новый, процесс-локальный реестр владения):** чистый never-raise модуль (паттерн `serial_gate`/`coverage_gate`, без сети/БД) — `mark(job_id, run_id, stage)` / `clear(job_id)` / `is_active(job_id)` / `snapshot()`; состояние `{job_id: {...}}` под `threading.Lock`. Авторитетно in-memory, т.к. монитор и reaper — daemon-**потоки одного** uvicorn-процесса (CMD без `--workers`) с общей SQLite-БД. Собственного TTL нет — ограничение по времени даёт Tier-3 backstop. `is_active` при ошибке → `False` (консервативно: не блокировать добивание).
- **Эмиссия владения (`launcher._monitor_agent`):** `mark()` вызывается **сразу после** штампа `exit_code` (самый ранний момент Tier-2), хвост финализации вынесен в `_run_monitor_finalization` и обёрнут в `try/finally` с `clear()` в `finally` → исключение в потоке монитора гарантированно снимает владение, и реально мёртвый finalizer добивается. Маркер пишется **безусловно** (kill-switch гейтит только консультацию reaper, поэтому выключенный путь — байт-в-байт прежний). Хвост перенесён **дословно** (проверяется `git diff -w`: +49/0, нулевое изменение логики).
- **Консультация reaper (`job_reaper._reap_job` Tier-2):** при `reaper_finalizer_liveness_enabled` **И** стадии задачи `== "deploy-staging"` **И** активном владении → **defer** (счётчик + лог, не повторять advance), провал к Tier-3. **Tier-3 (`age >= reaper_max_running_s`) маркер игнорирует** — застрявший/мёртвый finalizer добивается в ограниченное время. Скоуп — только глобальный kill-switch `reaper_finalizer_liveness_enabled` (env `ORCH_REAPER_FINALIZER_LIVENESS_ENABLED`, дефолт `True`; `False` → reaper байт-в-байт прежний), **без** per-repo разреза (баг общий для всех репо со стадией `deploy-staging`).
- **Наблюдаемость:** аддитивные ключи `finalizer_liveness_enabled`/`finalizer_defers_total`/`finalizer_owned` в блоке `reaper` ответа `GET /queue` (существующие ключи не тронуты). Покрытие — `tests/test_orch113_reaper_finalizer_liveness.py` (TC-01…TC-08, включая обязательный регресс ORCH-111: КРАСНЫЙ до фикса, ЗЕЛЁНЫЙ после).
- **Merge-gate re-test: толерантность к инфра-таймауту + tree-kill спавненных pytest + контракт необходимости re-test** (ORCH-110, `fix`, bug→escalate full-cycle): устранён ложный откат `deploy-staging → development`, возникавший когда локальный re-test merge-gate падал по **таймауту** (инфра/ресурс) при зелёных CI + tester + staging (инцидент ORCH-109/PR #129: сюит 516.7s упёрся в бюджет 600s под CPU-голоданием от осиротевших pytest-процессов → `(False, "re-test timeout after 600s")``_handle_merge_gate_rollback` → каждый из 3 developer-retry падал так же → «Merge-gate still failing after 3 developer retries» → ручное вмешательство). Аддитивно, под 5 независимыми kill-switch, never-raise, скоуп self-hosting; `STAGE_TRANSITIONS`/реестр `QG_CHECKS`/семантика `check_*`/machine-verdict-ключи/схема БД — **байт-в-байт не тронуты**; INV-4 (никогда push/force-push `main`) и запрет рестарта прод-контейнера — соблюдены. ADR: `docs/work-items/ORCH-110/06-adr/ADR-001-merge-gate-retest-infra-tolerance-and-tree-kill.md`, сквозной `docs/architecture/adr/adr-0042-merge-gate-retest-infra-tolerance-and-tree-kill.md`.
- **D1 — process-group tree-kill (`src/proc_group.py`, новый stdlib-only leaf):** `merge_gate.retest_branch` и `coverage_gate.measure_coverage` теперь спавнят pytest в **отдельной группе процессов** (`start_new_session`) и при таймауте убивают **всё дерево** (`os.killpg`, каскад SIGTERM→grace→SIGKILL по образцу `launcher.stop_process`), а не только прямого потомка — осиротевшие внуки-pytest больше не переживают бюджет и не грузят CPU. Контракты возврата сохранены (меняется лишь побочный эффект — нет утечки). Грейс реюзит `agent_kill_grace_seconds`. Fallback never-break: `subprocess_tree_kill_enabled=False` или не-POSIX → прежний `subprocess.run(timeout=)`.
- **D2/D3 — классификация + маршрутизация инфра-таймаута:** чистый предикат `merge_gate.classify_retest_failure(reason)` различает `timeout`/`red`/`lock-busy`/`other` (scope-guard: `auto_rebase_onto_main`'s «rebase timeout» — НЕ инфра-таймаут re-test, остаётся на rollback-пути). Инфра-таймаут → новый `_handle_merge_gate_infra_retry` (ограниченный повтор по образцу `_handle_merge_gate_defer`: задача **остаётся на deploy-staging**, staging-deployer перезапускается с задержкой, **БЕЗ** отката на `development` и **БЕЗ** расхода developer-retry). Анти-над-толерантность (BR-6): детерминированно **красный** re-test / конфликт по-прежнему → `_handle_merge_gate_rollback`. Anti-loop: исчерпание бюджета → один **инфра-alert** (явно инфраструктурная формулировка «НЕ дефект кода» с кликабельным номером), задача НЕ уходит в `development`.

View File

@@ -283,6 +283,46 @@ INV-4 (никогда push/force-push `main`) и запрет рестарта
`docs/work-items/ORCH-110/06-adr/ADR-001-merge-gate-retest-infra-tolerance-and-tree-kill.md`, сквозной
`docs/architecture/adr/adr-0042-merge-gate-retest-infra-tolerance-and-tree-kill.md`.
## Гигиена shared deploy-базы: устойчивый self-deploy `git pull` (ORCH-112)
Багфикс инцидента **ORCH-111** (bug → escalate full-cycle): прод-self-deploy падал на шаге
`git pull origin main` хост-хука (`scripts/orchestrator-deploy-hook.sh`) с `error: Your local changes
to the following files would be overwritten by merge: src/config.py` — грязь, оставленная
неуспешной/отменённой/брошенной задачей ORCH-104 в **общем** main checkout (`settings.deploy_host_repo_path`).
Деплой вставал → ручное вмешательство; на self-hosting (один прод-инстанс на все проекты) — групповой
риск. **Инвариант (нормативно):** shared main checkout `<host_repos_dir>/<repo>` — **deploy/worktree-management
база, НЕ редактируемый workspace** (агенты — worktree `git_worktree`, build — worktree-контекст, fallback'и
гейтов — read-only `git show origin/main`); локальных правок там быть не должно. Решение — **resilient-pull,
встроенный в хук** (`--deploy`): перед `git pull` хук при грязи приводит базу к чистому актуальному
`origin/main` (`git fetch` + `git reset --hard origin/main` + **скоупленный** `git clean -fd`). Аддитивно,
под kill-switch, never-raise, скоуп self-hosting; `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и
имена `check_*` / machine-verdict-ключи / схема БД / exit-code-контракт хука (0/1/2, ORCH-036) — **байт-в-байт
не тронуты** (это устойчивость deploy-пути, **не** Quality Gate и **не** стадия).
- **Leaf `src/checkout_hygiene.py` (чистый never-raise):** по образцу `serial_gate`/`cancel`/`self_deploy`
(импортирует только `config`, лениво `self_deploy`/`qg.checks`/`notifications`) — `applies(repo)`
(kill-switch `checkout_hygiene_enabled` + скоуп `checkout_hygiene_repos`, **пусто → self-hosting only**,
локально и ПЕРВЫМ), `hook_env(repo, work_item_id)` (env-префикс `CHECKOUT_HYGIENE=1 HYGIENE_REPORT=<host-path>`,
инжектится в detached-команду `self_deploy.build_deploy_command` только при `applies==True`, иначе `""` →
хук видит `CHECKOUT_HYGIENE` неустановленным → голый `git pull` 1:1 до ORCH-112), `read_report`/`alert_dirty`
(наблюдаемость), `snapshot()` (read-only блок `GET /queue`).
- **Хук-блок «2a. Resilient pull»:** между шагом «1. Capture PREV_IMG» и «2. Pull», под
`if [[ "${CHECKOUT_HYGIENE:-0}" == "1" ]]`. **Сохранность (NFR-2, жёсткий контракт):** `git clean` —
**только `-fd`, НИКОГДА `-x`** (иначе удалил бы gitignored `.env`/прод-секреты, `data/*.db`/БД, `build/`);
явные `-e '.deploy-prev-image-*'` и `-e 'deploy-hook.log'` (untracked-но-НЕ-ignored — иначе сломался бы
rollback `do_rollback`); sibling `<repos_dir>/.deploy-state-*`/`.merge-lease-*.json` и `.git/worktrees/*` —
вне области `git clean` в `$REPO`. Каждый git-шаг — `|| log "...continuing"` (never-break): сбой гигиены не
ухудшает исход относительно голого pull; чистая база → no-op (happy-path/exit-коды байт-в-байт);
`--build-staging` (build из worktree, без pull) не затронут.
- **Сходимость после failed/cancelled (FR-2)** — этим же deploy-time self-heal (база сходится на следующем же
self-deploy); `cancel_task` (ORCH-090) **не расширяется**, фоновый janitor **не вводится**.
**Наблюдаемость (FR-4)** — хук пишет sentinel `hygiene`; Phase-C finalizer (`stage_engine.run_deploy_finalizer`)
читает (`read_report`) и шлёт Telegram-алерт (`alert_dirty`, кликабельный номер, best-effort, never-raise).
- **Флаги** (`config.py`, дефолт = боевое): `checkout_hygiene_enabled` (env `ORCH_CHECKOUT_HYGIENE_ENABLED`),
`checkout_hygiene_repos` (env `ORCH_CHECKOUT_HYGIENE_REPOS`). Откат = `ORCH_CHECKOUT_HYGIENE_ENABLED=false` →
деплой байт-в-байт до ORCH-112. Покрытие — `tests/test_deploy_checkout_hygiene.py` (шелл-симуляция реального
хука во временном git-репо без сети/прода/ssh + unit; TC-01 — обязательный регресс ORCH-111: красный до
фикса, зелёный после). Детали — `docs/work-items/ORCH-112/06-adr/ADR-001-deploy-base-checkout-hygiene.md`,
сквозной `docs/architecture/adr/adr-0044-deploy-base-checkout-hygiene.md`.
## Машинный журнал уроков (ORCH-098)
Шаг 1 («Фундамент», F2) эпика саморазвития: формализует свободнотекстовые «уроки» из `memory/` в
**машинную структурированную таблицу отклонений конвейера** `lessons`, фундамент для будущих

View File

@@ -11,7 +11,7 @@
- **Quality Gates** (`src/qg/checks.py`) — проверки выхода со стадии, реестр `QG_CHECKS`.
- **Agent Launcher** (`src/agents/launcher.py`) — запуск Claude CLI агентов в изолированном git worktree, мониторинг, auto-advance. Модель/эффорт каждого агента резолвятся из config (`resolve_agent_model`/`resolve_agent_effort`, ORCH-41), а не из frontmatter промпта. **ORCH-74:** имя модели валидируется форматом `^claude-…$` (`is_valid_model`) перед `--model`; невалидное → лог + откат на следующий уровень/CLI-дефолт (never-break, как `VALID_EFFORTS` для эффорта). Тот же предикат гардит inline-чтение `--fallback-model`. **ORCH-109 ([adr-0040](adr/adr-0040-agent-timeout-budgets-and-launch-model-stamp.md)):** (1) резолвенная **модель стампится в `agent_runs.model` в момент launch** (`_spawn`, объединённый `UPDATE … SET model=?, effort=?` рядом со стампом эффорта ORCH-087; пустой резолв → `NULL`; never-raise) → модель видна не-`null` при любом исходе прогона, включая timeout-kill (`exit_code=-9`), и in-flight в `GET /metrics`/`GET /queue` (`get_running_agents` уже отдаёт `model`); постфактум `record_usage` (`model=COALESCE(?, model)`) остаётся **обогащением**, не единственным источником истины. (2) **Per-role wall-clock бюджеты** через выделенные ключи `agent_timeout_developer_s=3600`/`agent_timeout_reviewer_s=3000` (лестница `_resolve_timeout`: `agent_timeout_overrides_json` → выделенный ключ роли → `agent_timeout_seconds=1800`; прочие роли — байт-в-байт; малформный/вне-диапазонный конфиг → дефолт + WARNING). Инвариант reaper ORCH-065 сохранён синхронным поднятием `reaper_max_running_s` 3600→**5400** (`5400 > max(timeout)3600 + grace20`). FR-5 анти-salvage — структурно: продвижение гейтится `if exit_code==0`, timeout-kill → `_finalize_job` (retry/fail), не advance. `STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД не тронуты.
- **Queue** (`src/queue_worker.py`, ORCH-1) — персистентная очередь задач (SQLite `jobs`), atomic claim, max_concurrency, ретраи, restart-safe. **ORCH-026:** `claim_next_job` гейтит задачи с незавершёнными зависимостями (`job_deps`, `NOT EXISTS`) без занятия слота; декларации/циклы — leaf `src/task_deps.py`.
- **Job-reaper** (`src/job_reaper.py`, ORCH-065 — [adr-0011](adr/adr-0011-job-reaper-lease-reclaim.md)) — фоновый daemon-поток (каркас `reconciler`), стартует/останавливается в `main.lifespan` (после `reconciler.start()` / перед `worker.stop()`). Детектирует «мёртвый» `running`-job **без рестарта** процесса (Tier-1 мёртвый `jobs.pid` после `reaper_dead_ticks` тиков; Tier-2 `agent_runs.exit_code` записан, а job ещё `running`; Tier-3 backstop `reaper_max_running_s`) и приводит строку к корректному статусу через те же контракты (`_try_advance_stage`/`_finalize_job`, gate-driven; exit≠0/неизвестно → `attempts<max``queued`, иначе `failed`+Telegram). Атомарный reap-claim (guard `status='running'`) совместим со стартовым `requeue_running_jobs`. Тот же поток периодически делает проактивный реклейм stale/dead merge-lease (см. ниже). never-raise; kill-switch `ORCH_REAPER_ENABLED`; снимок в `GET /queue` (блок `reaper`).
- **Job-reaper** (`src/job_reaper.py`, ORCH-065 — [adr-0011](adr/adr-0011-job-reaper-lease-reclaim.md)) — фоновый daemon-поток (каркас `reconciler`), стартует/останавливается в `main.lifespan` (после `reconciler.start()` / перед `worker.stop()`). Детектирует «мёртвый» `running`-job **без рестарта** процесса (Tier-1 мёртвый `jobs.pid` после `reaper_dead_ticks` тиков; Tier-2 `agent_runs.exit_code` записан, а job ещё `running`; Tier-3 backstop `reaper_max_running_s`) и приводит строку к корректному статусу через те же контракты (`_try_advance_stage`/`_finalize_job`, gate-driven; exit≠0/неизвестно → `attempts<max``queued`, иначе `failed`+Telegram). Атомарный reap-claim (guard `status='running'`) совместим со стартовым `requeue_running_jobs`. Тот же поток периодически делает проактивный реклейм stale/dead merge-lease (см. ниже). never-raise; kill-switch `ORCH_REAPER_ENABLED`; снимок в `GET /queue` (блок `reaper`). **ORCH-113 ([adr-0043](adr/adr-0043-reaper-finalizer-liveness-ownership.md)):** на ребре `deploy-staging → deploy` тяжёлые edge-под-гейты (security/merge-gate re-test/coverage/image-freshness) исполняются в потоке монитора **после** штампа `finished_at` и **до** `_finalize_job` — минуты, а Tier-2 `finished_age_s` меряется от `finished_at`, поэтому живой долго финализирующий монитор ошибочно реапился (инцидент ORCH-111: повторный re-test → ложный откат `deploy-staging → development` параллельно успешному deploy). Фикс — процесс-локальный реестр владения финализацией (leaf `src/finalizer_liveness.py`, never-raise): монитор `mark()`/`clear()` (try/finally), reaper в Tier-2 при `stage=="deploy-staging"` И активном владении делает **defer** (не повторяет advance); Tier-3 backstop маркер игнорирует (мёртвый/застрявший finalizer добивается в ограниченное время). In-memory restart-safe через `requeue_running_jobs` (вызов до старта reaper); схема БД, `reaper_finalize_grace_s`/`reaper_max_running_s` и сквозной бюджет не тронуты. Kill-switch `ORCH_REAPER_FINALIZER_LIVENESS_ENABLED`.
- **Reconciler** (`src/reconciler.py`, ORCH-053 — реализовано, [adr-0007](adr/adr-0007-reconciler.md)) — фоновый daemon-поток (паттерн `queue_worker`), стартует/останавливается в `main.lifespan` (после `worker.start()` / перед `worker.stop()`). Реконсилирует рассинхрон «источник истины ≠ стадия задачи» при потерянном webhook. F-1 gate-side (продвигает застрявшую стадию по локальной БД через штатный `advance_stage(..., finished_agent=None)`), F-2 plane-side (опрос Plane API → `handle_*` из `plane.py`), F-3 (БД-fallback `sha→branch` в `handle_ci_status`). Источник истины — гейт/Plane, не событие; идемпотентность (active-job guard + atomic-claim + grace); kill-switch `ORCH_RECONCILE_ENABLED`. `analysis` F-1 не трогает (человеческий гейт). F-1 также пропускает escalated (retry≥лимита) и Blocked/Needs-Input задачи (ORCH-060). Наблюдаемость — блок `reconcile` в `GET /queue`.
- **Disk-watchdog** (`src/disk_watchdog.py`, ORCH-063 — [adr-0024](adr/adr-0024-disk-watchdog.md)) — фоновый daemon-поток (каркас `reconciler`/`job_reaper`), стартует/останавливается в `main.lifespan` (старт последним — после `reaper.start()`; стоп первым в reverse-порядке; гард `disk_monitor_enabled`). Каждые `disk_monitor_interval_s` (дефолт 300с) меряет заполнение **хост-ФС** по смонтированным bind-путям (`/repos`, `/app/data`) через stdlib `shutil.disk_usage` (не overlay `/` контейнера, не субпроцесс `df`; дедуп путей по `st_dev`). Решение об алерте — pure-функция `decide_action(used_pct, threshold, prev_state, now, realert_s)`: алерт на пересечении порога (дефолт **85%**), cooldown-повтор `disk_monitor_realert_s` (анти-спам, не на каждом тике), однократный recovery при возврате ниже порога. Алерт — `send_telegram` (notifying, best-effort). Состояние анти-спама — in-memory (без миграции БД). never-raise (per-path/per-tick/per-send); только читает и уведомляет — не трогает диск/контейнер, не рестартит прод (self-hosting безопасность). Kill-switch `ORCH_DISK_MONITOR_ENABLED`; снимок — блок `disk_monitor` в `GET /queue` (`enabled`/`threshold_pct`/`interval_s`/`realert_s`/`paths`[`used_pct`/`free_gb`/`alerting`/`last_alert_at`]). `STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД — не тронуты. Детали — `docs/work-items/ORCH-063/06-adr/ADR-001-disk-watchdog.md`.
- **Build-cache-pruner** (`src/build_cache_pruner.py`, ORCH-062 — [adr-0025](adr/adr-0025-build-cache-pruner.md)) — фоновый daemon-поток (каркас `disk_watchdog`), стартует/останавливается в `main.lifespan` (старт последним — после `disk_watchdog.start()`; стоп первым в reverse; гард `build_cache_prune_enabled`). «Вторая половина» disk-watchdog: **watchdog сигналит — pruner убирает**. Каждые `build_cache_prune_interval_s` (дефолт 21600с = 6ч) выполняет **строго `docker builder prune -f --filter until=<until>`** (BuildKit GC; дефолт `until=24h` — удаляет build cache старше суток, тёплый кэш сохраняет; `-a` опционально, только в паре с фильтром). Затрагивает **только** build cache — НЕ образы/контейнеры; рестарт docker daemon/прода не выполняется (self-hosting безопасность). В контейнере нет `docker` CLI (`Dockerfile:11`), поэтому уборка идёт **на хосте через ssh** каналом `deploy_ssh_user@deploy_ssh_host` (как `image_freshness`/`self_deploy`); пустой `deploy_ssh_host` → тик no-op (скоуп на self-host). never-raise (per-команда/per-tick); учёт результата in-memory (без миграции БД). Kill-switch `ORCH_BUILD_CACHE_PRUNE_ENABLED`; снимок — блок `build_cache_prune` в `GET /queue` (`enabled`/`interval_s`/`until`/`last_run_ts`/`last_reclaimed`/`last_error`). `STAGE_TRANSITIONS`/`QG_CHECKS`/схема БД — не тронуты. Детали — `docs/work-items/ORCH-062/06-adr/ADR-001-build-cache-pruner.md`.
@@ -742,6 +742,40 @@ sentinel-файлы (`<repos_dir>/.deploy-state-<repo>/<wi>/`), без мигр
Подробнее: [adr-0007](adr/adr-0007-executable-self-deploy.md), детально —
`docs/work-items/ORCH-036/06-adr/ADR-001-executable-self-deploy.md`.
#### Гигиена shared deploy-базы: устойчивый self-deploy `git pull` (ORCH-112 — design)
**Инвариант (нормативно):** shared main checkout `<host_repos_dir>/<repo>`
(= `settings.deploy_host_repo_path` = `/home/slin/repos/orchestrator`) — это
**deploy/worktree-management база, НЕ редактируемый workspace.** Рабочие изменения туда
**не пишутся** конвейером/агентами: агенты работают в worktree'ах `/repos/_wt/<repo>/<branch>`
(`git_worktree.ensure_worktree`), `docker build` берёт контекст worktree
(`image_freshness._host_worktree_path`), fallback'и гейтов на main clone — только чтение
(`git show origin/main:...`). Локальные правки в deploy-базе по определению существовать не должны.
**Проблема (инцидент ORCH-111 от грязи ORCH-104):** хук `scripts/orchestrator-deploy-hook.sh`
делал **голый** `git pull origin main` в `$REPO` без гигиены рабочего дерева → любая локальная правка
tracked-файла (`src/config.py`) блокировала merge → деплой падал → ручное вмешательство (групповой риск
self-hosting). **Решение** — **resilient-pull, встроенный в хук** (`--deploy`): перед `git pull` хук
при обнаружении грязи приводит базу к чистому актуальному `origin/main`
(`git fetch` + `git reset --hard origin/main` + **скоупленный** `git clean -fd`). Гейт — env
`CHECKOUT_HYGIENE`, инжектится `self_deploy.build_deploy_command` когда новый чистый never-raise leaf
`src/checkout_hygiene.py`-`applies(repo)` истинен (kill-switch `checkout_hygiene_enabled` + скоуп
`checkout_hygiene_repos`, пусто → self-hosting only).
- **Сохранность (NFR-2, жёсткий контракт):** `git clean` — **только `-fd`, НИКОГДА `-x`** (иначе
удалит gitignored `.env`/прод-секреты, `data/*.db`/БД, `build/`); явные `-e '.deploy-prev-image-*'`
и `-e 'deploy-hook.log'` (untracked-но-НЕ-ignored — иначе сломается rollback `do_rollback`).
Sibling `<repos_dir>/.deploy-state-*` / `.merge-lease-*.json` (под родителем `$REPO`) и
`.git/worktrees/*` (внутри `.git/`) — вне области `git clean` в `$REPO`.
- **Сходимость после failed/cancelled** — этим же deploy-time self-heal (база сходится на следующем
деплое); `cancel_task` (ORCH-090) **не расширяется**, фоновый janitor **не вводится**.
- **Наблюдаемость** — хук пишет sentinel `hygiene` в deploy-state каталог; Phase-C finalizer читает и
шлёт Telegram-алерт (кликабельный номер, best-effort, never-raise).
- **Чистая база / kill-switch off** — голый fast-forward `git pull` байт-в-байт (happy-path без
регресса); `--build-staging` (build из worktree, без pull) не затронут. `STAGE_TRANSITIONS` / реестр
`QG_CHECKS` / `check_*` / machine-verdict / схема БД / exit-code-контракт хука (0/1/2) — не тронуты.
Детально — `docs/work-items/ORCH-112/06-adr/ADR-001-deploy-base-checkout-hygiene.md`, сквозной
[adr-0044](adr/adr-0044-deploy-base-checkout-hygiene.md).
#### Выделенный статус-триггер прод-деплоя «Confirm Deploy» (ORCH-059 — реализовано)
Перегрузка: один Plane-статус `Approved` служил И человеческим гейтом BRD на
`analysis` (`check_analysis_approved`), И триггером Фазы B прод-деплоя на `deploy`
@@ -1171,7 +1205,15 @@ ORCH-065 вводит фоновый watchdog, чтобы смерть проц
затем git push/PR/Plane-комментарии), поэтому Tier-2 реапит только после
finalization-grace `reaper_finalize_grace_s` (живой финализирующий monitor НЕ
реапится); Tier-3 backstop по потолку `reaper_max_running_s` (> max
agent_timeout+grace). Действие переиспользует контракты по принципу
agent_timeout+grace). **ORCH-113 (adr-0043):** на ребре `deploy-staging → deploy`
финализация в потоке монитора длится **минуты** (тяжёлые edge-под-гейты
security/merge-gate re-test/coverage/image-freshness идут после штампа
`finished_at` и до `_finalize_job`), а grace=300 это не покрывал → живой долгий
finalizer ошибочно реапился и независимо повторял advance (ложный откат,
инцидент ORCH-111). Tier-2 теперь консультирует процесс-локальный реестр владения
(`src/finalizer_liveness.py`): при `stage=="deploy-staging"` И активном владении —
**defer** (не повторяет advance), Tier-3 backstop маркер игнорирует. In-memory,
restart-safe через `requeue_running_jobs`; grace/потолок и бюджет не меняются. Действие переиспользует контракты по принципу
**claim-before-act**: для exit0 канонический QG оценивается read-only ПЕРЕД
атомарным claim, затем claim `done` ПЕРВЫМ и только победитель claim делает
`_try_advance_stage` (advance+enqueue) — проигравший claim (поздний monitor /
@@ -1203,11 +1245,15 @@ ORCH-065 вводит фоновый watchdog, чтобы смерть проц
`logger.warning`; reap→`failed` и lease-reclaim → Telegram.
- **Kill-switch'и:** `ORCH_REAPER_ENABLED`, `ORCH_REAPER_INTERVAL_S`,
`ORCH_REAPER_DEAD_TICKS`, `ORCH_REAPER_MAX_RUNNING_S`,
`ORCH_REAPER_FINALIZE_GRACE_S`, `ORCH_LEASE_RECLAIM_ENABLED`; `false` → строго
прежнее поведение.
`ORCH_REAPER_FINALIZE_GRACE_S`, `ORCH_LEASE_RECLAIM_ENABLED`,
`ORCH_REAPER_FINALIZER_LIVENESS_ENABLED` (ORCH-113); `false` → строго прежнее
поведение.
Подробнее: [adr-0011](adr/adr-0011-job-reaper-lease-reclaim.md), детально —
`docs/work-items/ORCH-065/06-adr/ADR-001-job-reaper-and-lease-reclaim.md`.
Подробнее: [adr-0011](adr/adr-0011-job-reaper-lease-reclaim.md) +
[adr-0043](adr/adr-0043-reaper-finalizer-liveness-ownership.md) (ORCH-113,
finalizer-liveness ownership); детально —
`docs/work-items/ORCH-065/06-adr/ADR-001-job-reaper-and-lease-reclaim.md`,
`docs/work-items/ORCH-113/06-adr/ADR-001-reaper-finalizer-liveness-ownership.md`.
### Осмысленная статусная модель Plane (ORCH-066 — реализовано)
Plane-доска была семантически перегружена: `In Progress` означал «человек запускает

View File

@@ -0,0 +1,95 @@
---
work_item: ORCH-113
stage: architecture
author_agent: architect
status: proposed
created_at: 2026-06-15
model_used: claude-opus-4-8
---
# adr-0043: Reaper Tier-2 — in-memory ownership-маркер финализации `deploy-staging` (живой finalizer не реапится)
- **Статус:** proposed
- **Дата:** 2026-06-15
- **Задача:** ORCH-113 (bug → escalate full-cycle; кластер инцидента ORCH-111)
- **Детальный ADR:** `docs/work-items/ORCH-113/06-adr/ADR-001-reaper-finalizer-liveness-ownership.md`
- **Уточняет:** `adr-0011` (job-reaper/lease-reclaim ORCH-065), `adr-0040` (timeout-бюджеты ORCH-109),
`adr-0042` (merge-gate re-test infra-tolerance + tree-kill ORCH-110), `adr-0041`
(ORCH-111 `proc_blocking` — комплементарный наблюдатель того же инцидента)
## Контекст
На ребре `deploy-staging → deploy` живой монитор (`launcher._monitor_agent`) штампит
`agent_runs.finished_at`/`exit_code` **первым**, затем синхронно, в своём потоке, прогоняет тяжёлый
набор edge-под-гейтов через `_try_advance_stage → advance_stage` (`stage_engine.py:327368`):
`security``merge-gate` (полный локальный re-test, `merge_retest_timeout_s=900`) → `coverage`
(`pytest --cov`) → `image-freshness` (docker-rebuild + пересоздание staging) — **минуты**, — и лишь
потом `_finalize_job`. Reaper Tier-2 (`job_reaper.py:197209`) меряет `finished_age_s` от
`finished_at` = **начала** финализации и по `reaper_finalize_grace_s=300` считает живого, долго
финализирующего монитора мёртвым → независимо повторяет тот же тяжёлый advance. Атомарный
claim-before-act защищает лишь **флип строки** job, но не **side-effectful исполнение edge-гейтов**
(монитор не claim'ит строку перед `advance_stage`) → две `advance_stage` параллельно.
Инцидент ORCH-111 (job 1914): повторный re-test красный, ложный откат `deploy-staging → development`
(+ ложный developer-retry), **параллельно** исходный finalizer довёл deploy до SUCCESS и смержил
PR #130 — состояние раздвоилось. Реального сигнала «жив ли finalizer» нет (pid агента в Tier-2 мёртв в
обоих случаях). Per-stage grace, покрывающая Σ финализации (≈4160с), невозможна без нарушения сквозного
бюджета ORCH-065/109/110 `reaper_max_running_s (5400) > Σ(deploy-staging gate-work) + grace (≈4460)`.
**Решающий факт (проверен):** монитор и reaper — daemon-**потоки одного** uvicorn-процесса (CMD без
`--workers`), общая SQLite-БД → живость finalizer'а определяется **in-memory**. Рестарт покрыт
существующим `requeue_running_jobs()` (running→queued), вызываемым в `main.lifespan` **до** старта reaper.
## Решение
1. **Leaf `src/finalizer_liveness.py`** — чистый процесс-локальный реестр владения финализацией
(паттерн `serial_gate`/`coverage_gate`: never-raise, без сети/БД): `mark(job_id, run_id, stage)` /
`clear(job_id)` / `is_active(job_id) -> bool` / `snapshot()`; `{job_id: {...}}` + `threading.Lock`;
собственного TTL нет (ограничение по времени даёт Tier-3).
2. **Эмиссия владения**`launcher._monitor_agent`: `mark(...)` сразу после штампа `exit_code`
(самый ранний момент Tier-2), `clear(...)` в `try/finally` вокруг хвоста финализации → исключение
в потоке монитора гарантированно снимает владение (reaper добивает). Гибель процесса → рестарт →
`requeue_running_jobs` → реестр пуст (restart-safe без durable-хранения).
3. **Консультация reaper**`_reap_job` Tier-2 (`exit_code` записан, `finished_age >= grace`): если
`reaper_finalizer_liveness_enabled` **И** стадия `== "deploy-staging"` **И** `is_active(job_id)`
**defer** (лог + счётчик), не реапить через Tier-2, провалиться к Tier-3. Иначе — прежний путь.
**Tier-3 (`age >= reaper_max_running_s`) маркер игнорирует** — добивает всегда в ограниченное время.
4. **Скоуп/флаг** — только глобальный kill-switch `reaper_finalizer_liveness_enabled`
(env `ORCH_REAPER_FINALIZER_LIVENESS_ENABLED`, дефолт `True`); **без** per-repo разреза (баг общий
для всех репо со стадией `deploy-staging`; per-repo оставил бы баг активным для части репо).
`False` → reaper байт-в-байт прежний; стадии `!= deploy-staging` не консультируются.
5. **Наблюдаемость** — счётчик `finalizer_defers_total` + размер `snapshot()` в блоке `reaper`
`GET /queue`; существующие ключи ответа не меняются; новых эндпоинтов нет.
**Инварианты:** `STAGE_TRANSITIONS` / `QG_CHECKS` / каждый `check_*` / machine-verdict ключи / схема
существующих таблиц — **байт-в-байт**; **нулевое** изменение схемы БД; reaper остаётся never-raise
наблюдателем; `reaper_finalize_grace_s` и `reaper_max_running_s` **не меняются** (сквозной бюджет цел);
фикс не рестартит прод и не пушит `main`.
## Альтернативы
- Per-stage grace, покрывающая Σ — отвергнуто (нарушает бюджет `5400 > Σ+grace`; таймер = источник бага).
- Durable-колонка (heartbeat/owner-токен) — отвергнуто (один процесс → in-memory авторитетно; рестарт
покрыт requeue; блокирующий re-test не может бить heartbeat).
- Sub-state `finalizing` в `jobs.status` — отвергнуто (меняет семантику статуса для
claim/requeue/reconciler/reaper — нарушение NFR-2).
- Lease-файл на `(job, stage)` — отвергнуто (тяжелее, дублирует merge-lease, TTL = таймер-проблема).
- Флип job из `running` до тяжёлых гейтов — отвергнуто (ломает `get_running_jobs`/метрики и
restart-requeue).
## Последствия
- (+) Устранены повторный прогон edge-гейтов, ложный откат и расхождение состояния при живом долгом
finalizer'е `deploy-staging`; идемпотентность исполнения edge-гейтов через владение.
- (+) Реально мёртвый/застрявший finalizer добивается (finally-clear → Tier-2; иначе Tier-3); функция
reaper ORCH-065 сохранена.
- (+) Нулевое изменение схемы и контрактов; сквозной бюджет ORCH-065/109/110 не тронут; откат — один
env-флаг.
- () Гарантия владения валидна при **одном процессе/одной БД** (проверено: один uvicorn-воркер); ввод
`--workers>1` потребует durable-сигнала (риск в work-item 10-tech-risks).
- () Окно «штамп `finished_at``mark()`» (git push) маркером не покрыто — закрыто прежним grace=300.
## Связи
- Базируется/уточняет: `adr-0011`, `adr-0040`, `adr-0042`, `adr-0041`.
- Союзные задачи кластера инцидента ORCH-111: `ORCH-110` (инфра-толерантность merge-gate — отдельный
объём, не дублировать), `ORCH-109` (бюджеты).
- Детально: `docs/work-items/ORCH-113/06-adr/ADR-001-reaper-finalizer-liveness-ownership.md`.
</content>

View File

@@ -0,0 +1,66 @@
---
work_item: ORCH-112
stage: architecture
author_agent: architect
status: proposed
created_at: 2026-06-15
model_used: claude-opus-4-8
---
# adr-0044: Гигиена shared deploy-базы — устойчивый self-deploy `git pull`
Сквозное (cross-cutting) решение. Детальный per-work-item ADR —
`docs/work-items/ORCH-112/06-adr/ADR-001-deploy-base-checkout-hygiene.md`.
## Статус
Proposed (ORCH-112)
## Контекст (сквозной)
Глобальный путь прод-деплоя self-hosting (`deploy`-стадия, ORCH-036) исполняет хост-хук
`scripts/orchestrator-deploy-hook.sh`, чей шаг «2. Pull latest code» — **голый** `git pull origin main`
в shared main clone (`settings.deploy_host_repo_path`). Любая грязь рабочего дерева (модифицированный
tracked-файл и/или untracked-остатки failed/cancelled/брошенной задачи) **блокирует** merge → деплой
встаёт → ручное вмешательство. На self-hosting (один прод-инстанс на все проекты с общей БД/очередью)
это **групповой риск**: залипший self-deploy орка останавливает обслуживание всех проектов
(инцидент ORCH-111, грязь от ORCH-104).
## Решение (сквозное)
Вводится **resilient-pull, встроенный в прод-deploy-хук** (`--deploy`), + новый чистый never-raise
leaf-компонент `src/checkout_hygiene.py`:
- **Хук** перед `git pull origin main` приводит грязную deploy-базу к чистому актуальному `origin/main`
(`git fetch` + `git reset --hard origin/main` + **скоупленный** `git clean -fd`), **строго сохраняя**
rollback/лог-артефакты. Гейт — env `CHECKOUT_HYGIENE`, инжектится `self_deploy.build_deploy_command`.
- **Leaf** `checkout_hygiene` решает условность (`applies(repo)`: kill-switch `checkout_hygiene_enabled`
+ скоуп `checkout_hygiene_repos`, пусто → self-hosting only), строит env-префикс, читает sentinel
отчёта, шлёт Telegram-алерт. Образец `serial_gate`/`cancel`/`self_deploy`.
- **Сходимость** базы после failed/cancelled (FR-2) — этим же deploy-time self-heal; `cancel_task`
(ORCH-090) **не расширяется**, фоновый janitor **не вводится**.
- **Наблюдаемость** — хук пишет sentinel `hygiene`, Phase-C finalizer читает и шлёт Telegram-алерт
(best-effort, never-raise).
- **Инвариант** «main checkout — deploy/worktree-management база, НЕ workspace» документируется
(INFRA.md + architecture/README.md); de-facto энфорс — сам resilient-pull.
## Кросс-каттинг-инварианты (обязательны к соблюдению будущими задачами)
- **INV-HYGIENE-1 (никогда `-x`):** hygiene-`git clean` — только `git clean -fd`. `-x` удалил бы
gitignored `.env` (прод-секреты) / `data/*.db` (БД прода) / `build/`. Анти-регресс — статический тест.
- **INV-HYGIENE-2 (явные excludes):** `.deploy-prev-image-*` (rollback, `deploy_prod_prev_image_file`)
и `deploy-hook.log` — untracked-но-НЕ-ignored → обязательны `-e`-исключения; их удаление сломало бы
rollback.
- **INV-HYGIENE-3 (скоуп = `$REPO`):** гигиена оперирует только рабочим деревом deploy-базы;
sibling `<repos_dir>/.deploy-state-*` / `.merge-lease-*.json` и `.git/worktrees/*` — вне области.
- **Self-hosting safety (NFR-1):** никогда не трогать `main` на remote, не force-push, не рестартить
прод вне штатного гейта, не сносить worktree/ветки других активных задач.
- **Нулевая регрессия (NFR-5):** `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` /
machine-verdict ключи / схема БД / exit-code-контракт хука (0/1/2, ORCH-036) — байт-в-байт. Это
устойчивость deploy-пути, **не** Quality Gate и **не** стадия.
## Связи
- Дополняет: adr-0007 (executable self-deploy, ORCH-036), adr-0008 (image-freshness, ORCH-058).
- Не нарушает: adr-0026 (STOP/cancel, ORCH-090) — каскад cancel не трогается.
## Откат
`ORCH_CHECKOUT_HYGIENE_ENABLED=false` → прод-деплой байт-в-байт до ORCH-112 (голый `git pull origin main`).

View File

@@ -385,7 +385,16 @@ daemon-поток `src/job_reaper.py` (каркас `reconciler`) периоди
git push/PR/Plane-комментарии (секунды-десятки секунд) и лишь потом
`_finalize_job`; pid агента к этому моменту мёртв в обоих случаях. Поэтому
Tier-2 реапит только после finalization-grace `reaper_finalize_grace_s`
(`finished_age_s >= grace`) — живой финализирующий monitor НЕ реапится;
(`finished_age_s >= grace`) — живой финализирующий monitor НЕ реапится.
**ORCH-113 (adr-0043):** на ребре `deploy-staging → deploy` финализация длится
**минуты** (тяжёлые edge-под-гейты после штампа `finished_at`, до `_finalize_job`),
grace=300 это не покрывал → живой долгий finalizer ошибочно реапился и повторял
advance (ложный откат, инцидент ORCH-111). Tier-2 консультирует процесс-локальный
реестр владения `src/finalizer_liveness.py` (`mark`/`clear` в потоке монитора через
try/finally): при `stage=="deploy-staging"` И активном владении → **defer**;
Tier-3 backstop маркер игнорирует (мёртвый/застрявший finalizer добивается).
Kill-switch `ORCH_REAPER_FINALIZER_LIVENESS_ENABLED`; in-memory, restart-safe через
`requeue_running_jobs` (до старта reaper); схема БД и сквозной бюджет не тронуты;
- **Tier-3** — backstop: job висит `running` дольше `reaper_max_running_s`.
Реап атомарен (`UPDATE jobs SET ... WHERE id=? AND status='running'` + `rowcount`,

View File

@@ -21,6 +21,14 @@
/repos/<project> ← общий каталог репозиториев (host: /home/slin/repos)
```
> **Инвариант deploy-базы (ORCH-112, нормативно).** Shared main checkout
> `<host_repos_dir>/<repo>` (= `/home/slin/repos/orchestrator` == `/repos/orchestrator` в контейнере
> через bind-mount == `settings.deploy_host_repo_path`) — это **deploy/worktree-management база, НЕ
> редактируемый workspace.** Рабочие изменения туда **не пишутся** конвейером/агентами: агенты —
> worktree `/repos/_wt/<repo>/<branch>` (`git_worktree`), `docker build` — worktree-контекст,
> fallback'и гейтов — read-only `git show origin/main`. Self-deploy `git pull` устойчив к грязной
> базе (resilient-pull, см. self-hosting-страховки ниже).
## Контейнеры
| Контейнер | Роль | Порт | env_file | БД (хост) | Старт |
@@ -220,6 +228,7 @@ watchdog'а: **watchdog сигналит, pruner убирает**.
**Страховки:**
- Стадия `deploy-staging` (порт 8501) — обязательный гейт перед прод-деплоем орка. Прод-деплой недостижим, пока staging-гейт не зелёный (см. `STAGING.md`, ORCH-35). Гейт условный: реален только для self-hosting (repo=orchestrator), для остальных проектов — no-op.
- **Свежесть staging-образа (ORCH-058):** на ребре `deploy-staging → deploy` (ПОСЛЕ merge-gate, ДО Phase A) QG-под-чек `check_staging_image_fresh` пересобирает staging-образ из валидированного коммита и пересоздаёт 8501 (Strategy A), а хук перед build-once retag fail-closed сверяет OCI-лейбл `revision` с `EXPECTED_REVISION` (Strategy B). Гарантирует: в прод промоутится РОВНО провалидированный артефакт (инцидент LESSONS_ORCH-036 п.4 — тихий промоут устаревшего образа). Сборки/recreate — ТОЛЬКО staging (8501); FAIL → откат на `development`. Условный: реален только для self-hosting.
- **Гигиена shared deploy-базы (ORCH-112):** self-deploy `git pull origin main` устойчив к грязному рабочему дереву deploy-базы (модифицированные tracked + untracked-остатки failed/cancelled/брошенных задач). Хук `--deploy` перед pull приводит базу к чистому `origin/main` (resilient-pull: `git fetch` + `git reset --hard origin/main` + `git clean -fd`), **строго сохраняя** rollback-снимки `.deploy-prev-image-*`, `deploy-hook.log`, gitignored `.env`/`data/`/`*.db` (НИКОГДА `-x`!), sibling `.deploy-state-*`/`.merge-lease-*.json`, `.git/worktrees/*`. Гейт — kill-switch `ORCH_CHECKOUT_HYGIENE_ENABLED` (дефолт `True`; off → голый pull 1:1); скоуп `ORCH_CHECKOUT_HYGIENE_REPOS` (пусто → self-hosting only). Грязь базы детектируется → лог + Telegram-алерт (Phase-C finalizer). Решает инцидент ORCH-111 (грязь ORCH-104 заблокировала `git pull`). Детально — `docs/work-items/ORCH-112/06-adr/ADR-001`, сквозной adr-0044.
**Правила для агентов при задачах ORCH:**
1. НЕ перезапускать / не ронять прод-контейнер `orchestrator` в рамках задачи.

View File

@@ -0,0 +1,7 @@
# Business Request: BUG: failed/cancelled task artifacts must be cleaned from shared checkout
Work Item ID: ORCH-112
## Description
TBD

View File

@@ -0,0 +1,169 @@
---
work_item: ORCH-112
stage: analysis
author_agent: analyst
status: ready-for-review
created_at: 2026-06-15
model_used: claude-opus-4-8
escalate: full-cycle
---
# 01 — BRD / Bug-report: ORCH-112 — failed/cancelled task artifacts must be cleaned from shared checkout
Work Item: **ORCH-112** · Repo: **orchestrator** · Стадия: analysis · Трек: **Bug → эскалация в full-cycle**
> ⚠️ **`escalate: full-cycle` (ADR-001 D5 ORCH-019).** Баг помечен `Bug`, но по сути это
> **архитектурный + safety-critical (self-hosting)** дефект: правка лежит в самом опасном пути
> прод-деплоя (хост-хук, прямо перед рестартом прод-контейнера) и требует **решения о политике
> жизненного цикла** shared checkout (ADR). Поэтому выпускается **полный** analysis-пакет, а не
> облегчённый bug-пакет. Оператор снимает багфикс-трек: `POST /bug-fast-track/escalate?work_item=ORCH-112`
> → задача пойдёт через стадию `architecture` (architect выпустит ADR для политики cleanup/изоляции).
---
## 1. Бизнес-контекст и проблема
### Симптом (наблюдаемое)
Self-deploy задачи **ORCH-111** упал на шаге `git pull origin main` хост-хука деплоя с ошибкой:
```
error: Your local changes to the following files would be overwritten by merge:
src/config.py
Please commit your changes or stash them before you merge.
```
Деплой прерван, конвейер потребовал **ручного вмешательства оператора** (на self-hosting это
групповой риск — встаёт деплой и всех других проектов).
### Причина симптома (установленный факт)
В **общем (shared) checkout** `/home/slin/repos/orchestrator` оставались грязные файлы от
ранее **неуспешной/отменённой/перезапущенной задачи ORCH-104** (тема Lite installer):
- модифицированный tracked-файл: `src/config.py`;
- модифицированный/untracked: `docs/deployment/LITE_SETUP.md`;
- untracked: `scripts/install_lite.py`, `tests/test_install_lite.py`,
`docs/deployment/lite-install.example.yaml`.
Через несколько дней эти остатки **заблокировали** `git pull` другой задачи (ORCH-111).
### Локализация (анализ — куда смотреть архитектору/разработчику)
**Установленный факт о топологии (CLAUDE.md / `docs/architecture/README.md`):**
`/home/slin/repos/orchestrator` (хост) == `/repos/orchestrator` (контейнер, bind-mount) ==
**main clone** (`settings.repos_dir/<repo>` = `settings.deploy_host_repo_path`). Это **deploy-база
и база управления worktree'ами**, а НЕ рабочая копия агента.
1. **Первичный дефект — нерезистентный `git pull`.**
`scripts/orchestrator-deploy-hook.sh:224-226` делает `cd "$REPO"` (= deploy-база) и
**голый** `git pull origin main` **без гигиены рабочего дерева**. Любая локальная правка
tracked-файла блокирует merge → деплой падает. Проверено: во всём `src/`+`scripts/` **нет ни
одного** `git reset --hard` / `git clean` / `git stash` для приведения базы к чистому состоянию.
Shared checkout трактуется как «всегда чистый», что не гарантировано.
2. **Невыполненный/неэнфорснутый инвариант + отсутствие «дворника».**
Нормальный конвейер **не пишет** в рабочее дерево main clone: агенты работают в изолированных
worktree'ах `/repos/_wt/<repo>/<branch>` (`git_worktree.ensure_worktree`); `docker build`
использует контекст **worktree** (`image_freshness._host_worktree_path`), не main clone;
fallback'и гейтов на main clone — **только чтение** (`git show origin/main:...`,
`qg/checks.py:451`, `coverage_gate.py:297`, `stage_engine.py:145`). Поэтому грязь ORCH-104
почти наверняка — **ручной/брошенный WIP** в shared checkout во время инцидента ORCH-104
(косвенное подтверждение: файлы `install_lite.py`/`test_install_lite.py`/`lite-install.example.yaml`
**никогда не существовали в git-истории** — закоммиченный артефакт ORCH-104 это
`scripts/setup_lite.py`, commit `e2cf883`). Вне зависимости от источника: **нет механизма**,
который детектирует/чистит грязную базу и **нет задокументированного/энфорснутого инварианта**
«main checkout — неизменяемая deploy-база, не workspace».
3. **`cancel_task` чистит worktree + remote-ветку, но НЕ shared checkout.**
`stage_engine.cancel_task` (шаг 3d, строки ~2330-2343): `remove_worktree(repo, branch)` +
`gitea.delete_remote_branch(repo, branch)`. Это корректно (конвейер в main clone не пишет), но
означает **нулевое покрытие** случая «грязная deploy-база» в каскадах failed/cancelled.
**Вывод:** даже если первопричина грязи — ручное действие, устойчивость должна быть на стороне
системы: deploy-база обязана **самовосстанавливаться** в чистый `origin/main` перед pull, а
политика жизненного цикла — гарантировать, что остатки failed/cancelled задач не клинят будущие
операции.
## 2. Объём (scope)
### В объёме
- Сделать self-deploy `git pull origin main` (shared deploy-база) **устойчивым к грязному рабочему
дереву** — приведение базы к чистому `origin/main` **автономно**, без ручного вмешательства.
- Гарантировать, что после **failed / cancelled / брошенной** задачи в shared checkout не остаётся
рабочих остатков, способных заблокировать будущий деплой/операцию (сходимость базы к чистому
`origin/main`).
- Задокументировать (и где осуществимо — мягко энфорснуть/гардить) инвариант
«shared main checkout — deploy/worktree-management база, НЕ редактируемый workspace».
- Наблюдаемость: лог + Telegram-алерт, когда deploy-база найдена грязной и автоочищена (или отказ).
### Вне объёма
- ❌ Запрет/контроль ручных операций оператора в shared checkout (вне технической власти системы;
закрываем устойчивостью, а не запретом).
- ❌ Изменение модели worktree per-task (`git_worktree`, ORCH-2) — она корректна и не трогается.
- ❌ Любое изменение `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` / machine-verdict ключей / схемы БД.
- ❌ Изменение поведения деплоя на чистой базе (happy-path должен остаться байт-в-байт).
- ❌ Выбор конкретного механизма (reset --hard vs janitor vs guard) — это **зона архитектора** (ADR).
## 3. Заинтересованные стороны
- **Заказчик/оператор (Слава)** — страдает от ручного разруливания залипших деплоев; принимает результат.
- **Self-hosting конвейер orchestrator** — прямой потребитель (надёжность прод-деплоя).
- **Все проекты на общем инстансе (enduro-trails)** — косвенно: залипший self-deploy орка
останавливает обслуживание их задач.
## 4. Бизнес-требования (BR)
- **BR-1** — Грязное рабочее дерево shared deploy-базы (модифицированные tracked-файлы и/или
untracked-файлы) **НЕ должно блокировать** self-deploy `git pull origin main`: деплой обязан
привести базу к чистому, актуальному `origin/main` **без ручного вмешательства**.
- **BR-2** — После failed / cancelled / брошенной задачи в shared checkout **не должно оставаться**
рабочих остатков этой задачи, способных заблокировать будущий деплой/git-операцию; база
**сходится** к чистому `origin/main`.
- **BR-3** — Инвариант «shared main checkout (`<host_repos_dir>/<repo>`) — deploy/worktree-management
база, НЕ workspace» должен быть **задокументирован** (`docs/operations/INFRA.md` +
`docs/architecture/README.md`) и, где осуществимо, **энфорснут/гардирован**; конвейер/агенты
**никогда** не пишут рабочие изменения в main clone (верифицировать, что это так).
- **BR-4** — **Наблюдаемость:** обнаружение грязной базы и факт автоочистки (или отказ) должны
логироваться и алертиться (Telegram, кликабельный номер) — оператор видит, что гигиена сработала.
- **BR-5** — На **чистой** базе поведение деплоя — **байт-в-байт прежнее** (обычный fast-forward
`git pull`); никакого регресса happy-path.
## 5. Нефункциональные требования (NFR)
- **NFR-1 (self-hosting safety)** — гигиена **никогда** не трогает ветку `main` на remote, не делает
force-push, не рестартит прод-контейнер вне штатного гейта, не удаляет worktree/ветки **других
активных** задач. Оперирует **только** настроенным путём deploy-базы.
- **NFR-2 (сохранность deploy-состояния)** — автоочистка **не должна** удалять артефакты, легитимно
живущие под `$REPO`/рядом: rollback-снимки `$REPO/.deploy-prev-image-*`
(`deploy_prod_prev_image_file`), `deploy-hook.log`, sibling-состояния
`<repos_dir>/.deploy-state-*` / `.merge-lease-*.json`, и админ-записи worktree в `.git/worktrees`.
(Наивный `git clean -xfd` в `$REPO` уничтожил бы `.deploy-prev-image-*` и сломал rollback — это
**жёсткое ограничение** для архитектора/разработчика.)
- **NFR-3 (обратимость / kill-switch)** — новое поведение под флагом; выключенный флаг → деплой
байт-в-байт как до ORCH-112 (голый `git pull origin main`).
- **NFR-4 (надёжность)** — never-raise / fail-safe (по образцу leaf'ов `serial_gate`/`cancel`);
идемпотентность; restart-safe; сбой гигиены не должен маскировать или ухудшать исход деплоя сверх
текущего.
- **NFR-5 (нулевая регрессия конвейера)** — `STAGE_TRANSITIONS` / `QG_CHECKS` / `check_*` /
machine-verdict ключи / схема БД / exit-code-контракт хука (0/1/2, ORCH-036) — **байт-в-байт**.
- **NFR-6 (область)** — изменение скоупится на self-hosting (`orchestrator`); поведение для прочих
репо/синхронного деплоя агентом — не ухудшается.
## 6. Допущения и ограничения
- Shared checkout и хост-хук физически разделяют один путь с контейнером через bind-mount
(`repos_dir``host_repos_dir`); хук исполняется на **хосте** по ssh (ORCH-036, detached).
- Build-once путь (`SOURCE_IMAGE` retag) **не** зависит от содержимого рабочего дерева main clone —
прод получает ровно staging-валидированный образ; значит дискард рабочего дерева base перед pull
**безопасен для деплоимого артефакта**. (`--build-staging` собирается из **worktree**, не из main —
отдельный контур.)
- Источник истины кода — `origin/main`; локальные правки в deploy-базе **по определению** не должны
существовать (это deploy-база, а не место работы).
- Конкретный механизм (resilient pull через reset+clean со скоуп-исключениями / активный janitor /
guard инварианта / комбинация) — **открытый вопрос для архитектуры**, решается в `06-adr/`.
## 7. Критерии успеха
Self-deploy успешно выполняет `git pull` на ранее грязной shared-базе **без ручного вмешательства**;
deploy-база сходится к чистому `origin/main`; rollback-состояние и sibling-артефакты сохранены;
happy-path и весь конвейер — без регресса; обязательный регресс-тест **красный до фикса, зелёный
после**. Детальные PASS/FAIL — `03-acceptance-criteria.md`.
## 8. Риски
- Деструктивная гигиена (`reset --hard`/`clean`) в **прод-deploy-базе** рядом с рестартом прода —
ошибка скоупа может удалить rollback-state/логи (см. NFR-2) → ADR обязателен.
- Маскировка реальной первопричины: если в будущем какой-то код **начнёт** писать в main clone,
«тихая автоочистка» это скроет → нужна наблюдаемость (BR-4).
- Кросс-каттинг с ORCH-036 (self-deploy), ORCH-058 (image-freshness/provenance), ORCH-090 (cancel),
ORCH-2 (worktree-модель). Детали/митигации — `10-tech-risks.md` (заполняет архитектор).

View File

@@ -0,0 +1,110 @@
---
work_item: ORCH-112
stage: analysis
author_agent: analyst
status: ready-for-review
created_at: 2026-06-15
model_used: claude-opus-4-8
---
# 02 — ТЗ (TRZ): ORCH-112 — failed/cancelled task artifacts must be cleaned from shared checkout
Work Item: **ORCH-112** · Repo: **orchestrator** · Стадия: analysis
> ТЗ описывает **требования и ограничения к реализации**, выведенные из BRD и фактического кода.
> Архитектурное **решение** (какой механизм гигиены/изоляции выбрать) — задача архитектора (`06-adr/`),
> т.к. задача эскалирована в full-cycle (`01-brd.md` → `escalate: full-cycle`).
## 1. Сводка изменения
Сделать self-deploy устойчивым к **грязной shared deploy-базе** и гарантировать сходимость базы к
чистому `origin/main` после failed/cancelled/брошенных задач. Корень симптома — голый
`git pull origin main` в `scripts/orchestrator-deploy-hook.sh` (строка 226), исполняемый в
`$REPO` (= `settings.deploy_host_repo_path` = main clone), который падает при любой локальной правке
tracked-файла. Требуется: (а) приведение deploy-базы к чистому `origin/main` перед/в момент pull
**без ручного вмешательства**, со строгим сохранением deploy-rollback-состояния; (б) документирование
+ (по возможности) энфорс инварианта «main checkout — deploy-база, не workspace»; (в) наблюдаемость.
## 2. Задействованные модули / пути
| Путь | Действие | Примечание |
|------|----------|-----------|
| `scripts/orchestrator-deploy-hook.sh` | изменить | строки 224-226: голый `git pull origin main` в `$REPO` — точка отказа (FR-1) |
| `src/self_deploy.py` | возможно изменить | `build_deploy_command` / `initiate_deploy` / `rebuild_staging_image` строят инвокацию хука — возможная точка передачи гигиены/флага (решает архитектор) |
| `src/stage_engine.py` | возможно изменить | `cancel_task` (шаг 3d, ~2330-2343) — каскад cancel; расширение гигиены на shared-базу (FR-2, если выбран этот путь) |
| `src/git_worktree.py` | возможно изменить | модель main clone ↔ worktree; возможный helper приведения базы к чистоте / верификация инварианта (BR-3) |
| `src/config.py` | изменить | новый kill-switch + флаги области (FR-5) |
| `src/<new_leaf>.py` (напр. `checkout_hygiene.py`) | возможно создать | чистый never-raise leaf политики гигиены (по образцу `serial_gate`/`cancel`) — **создавать ли** решает архитектор |
| `docs/operations/INFRA.md` | изменить | инвариант «shared checkout — deploy-база, не workspace» (BR-3) |
| `docs/architecture/README.md` | изменить | описать политику гигиены/жизненного цикла deploy-базы |
| `CHANGELOG.md`, `CLAUDE.md` | изменить | правило «docs = golden source» (CLAUDE.md §2) |
| `tests/test_<...>.py` | создать | регресс + покрытие (см. `04-test-plan.yaml`) |
## 3. Функциональные требования
### FR-1 — Устойчивый self-deploy `git pull` (BR-1, BR-5)
- На пути self-deploy (`scripts/orchestrator-deploy-hook.sh`, шаг «2. Pull latest code»)
`git pull origin main` **не должен падать** из-за грязного рабочего дерева `$REPO`.
- Перед обновлением база приводится к чистому, актуальному `origin/main` (приведение tracked- и
untracked-изменений к состоянию `origin/main`), **с сохранением** артефактов из NFR-2.
- На **уже чистой** базе результат — обычный fast-forward; наблюдаемое поведение и exit-коды
(0/1/2, ORCH-036) — **байт-в-байт прежние** (BR-5).
- Контракт: never-break — сбой шага гигиены не должен ухудшать исход относительно текущего голого
pull (fail-safe).
### FR-2 — Сходимость shared-базы после failed/cancelled/брошенной задачи (BR-2)
- После терминации задачи (`failed` job-исход / `cancelled` через STOP / брошенный WIP) в shared
checkout **не остаётся** рабочих остатков, способных заблокировать будущий деплой/git-операцию.
- Допустимая трактовка «сходимости» (на выбор архитектора, **не** прескриптивно здесь): автоочистка
непосредственно в self-deploy перед pull (FR-1) **и/или** активный «дворник», приводящий
`<host_repos_dir>/<repo>` к чистому `origin/main`.
- Каскад `cancel_task` (ORCH-090) уже чистит **worktree + remote-ветку**; расширение на shared-базу
(если выбрано) делается тем же never-raise best-effort способом.
### FR-3 — Инвариант deploy-базы (BR-3)
- Задокументировать: `<host_repos_dir>/<repo>` — deploy/worktree-management база; рабочие изменения
туда **не пишутся** конвейером/агентами (агенты — worktree `git_worktree`; build — worktree-контекст;
fallback'и гейтов — read-only `git show origin/main`).
- Верифицировать, что текущий код этот инвариант соблюдает (анализ ORCH-112: соблюдает; единственные
обращения к main clone — read-only/fetch/worktree-управление). Где осуществимо — добавить
лёгкий guard/проверку (решает архитектор), **без** изменения горячих путей.
### FR-4 — Наблюдаемость (BR-4)
- Обнаружение грязной deploy-базы и факт автоочистки (число/имена сброшенных путей) или **отказ**
гигиены — лог (структурная запись) + Telegram-алерт (`send_telegram`, кликабельный номер задачи,
best-effort, never-raise). Опционально — read-only снапшот в `GET /queue` (решает архитектор).
### FR-5 — Условность / kill-switch (BR-5, NFR-3, NFR-6)
- Новое поведение под **kill-switch** (env `ORCH_*`, по образцу `serial_gate_enabled`/`stop_status_enabled`);
выключенный флаг → деплой байт-в-байт прежний (голый `git pull origin main`).
- Область — self-hosting (`orchestrator`); прочие репо/синхронный деплой агентом — не ухудшаются.
- `applies(repo)` (локальный, без сети) проверяется первым.
## 4. Изменения API
**Нет** обязательных. Опционально (на усмотрение архитектора) — read-only блок (напр. `checkout_hygiene`)
в существующем `GET /queue` для наблюдаемости. Новых управляющих эндпоинтов не требуется.
## 5. Изменения схемы БД
**Нет.** Состояние гигиены, если нужно, — in-memory / sentinel-файлы (паттерн `self_deploy`/`merge_gate`),
без миграции БД. Аддитивная таблица не требуется.
## 6. Требования к новым/изменённым QG checks
**Нет.** Это **не** Quality Gate и не стадия — это устойчивость deploy-пути и политика гигиены.
`STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` / machine-verdict ключи
(`deploy_status:`/`staging_status:`/…) — **байт-в-байт не тронуты** (NFR-5).
## 7. Совместимость / регресс
- **Обратная совместимость:** kill-switch off → голый `git pull origin main` (1:1 до ORCH-112);
чистая база → fast-forward без изменений (BR-5).
- **Область раската:** self-hosting `orchestrator`; enduro/прочие — нулевая регрессия.
- **Обратимость:** выключение флага мгновенно возвращает прежнее поведение.
- **Сохранность (жёсткое ограничение, NFR-2):** гигиена **не удаляет** `$REPO/.deploy-prev-image-*`
(rollback), `deploy-hook.log`, sibling `<repos_dir>/.deploy-state-*` / `.merge-lease-*.json`,
админ-записи `.git/worktrees`. Любой `clean`-скоуп обязан их исключать.
- **Self-hosting инварианты (NFR-1):** никогда не трогать `main` на remote, не force-push, не
рестартить прод вне гейта, не сносить worktree/ветки других активных задач, оперировать только
настроенным путём deploy-базы. Exit-code-контракт хука (0/1/2) сохранён.
- **Артефакты pipeline:** создаются/обновляются обычные docs work item (`01..04` этой задачи,
`06-adr/` на стадии architecture после эскалации, `14-deploy-log.md` при деплое). Новых
pipeline-артефактов задача не вводит.
- **Трассировка (CLAUDE.md §9 / ORCH-078):** правки маркированных блоков (ORCH-036 self-deploy,
ORCH-058 image-freshness, ORCH-090 cancel) — сверять с их `06-adr/` перед изменением, инварианты
не ломать.

View File

@@ -0,0 +1,128 @@
---
work_item: ORCH-112
stage: analysis
author_agent: analyst
status: ready-for-review
created_at: 2026-06-15
model_used: claude-opus-4-8
---
# 03 — Критерии приёмки (Acceptance Criteria): ORCH-112 — failed/cancelled task artifacts must be cleaned from shared checkout
Work Item: **ORCH-112** · Repo: **orchestrator** · Стадия: analysis
Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL**
(что считается провалом). Reviewer/CI проверяют их буквально по файлам репозитория и тестам.
---
## AC-1 — Грязная tracked-правка не блокирует self-deploy pull (регресс ORCH-104/ORCH-111)
**Условие:** shared deploy-база имеет локальную модификацию tracked-файла (напр. `src/config.py`),
self-deploy выполняет шаг pull.
- **PASS:** база приводится к чистому актуальному `origin/main` без ручного вмешательства; шаг pull
не возвращает «local changes would be overwritten by merge»; деплой продолжается; есть тест,
воспроизводящий точный сценарий ORCH-111 (**красный до фикса, зелёный после**).
- **FAIL:** pull/деплой падает на грязной tracked-правке; или сценарий не покрыт тестом.
---
## AC-2 — Untracked WIP-файлы не блокируют и не «протекают» в деплой
**Условие:** в shared-базе лежат untracked-файлы failed/брошенной задачи (напр.
`scripts/install_lite.py`, `tests/test_install_lite.py`, `docs/deployment/lite-install.example.yaml`).
- **PASS:** база сходится к чистому `origin/main`; untracked-остатки не блокируют операцию и не
попадают в деплоимый/собираемый артефакт.
- **FAIL:** untracked-остатки блокируют операцию либо остаются и клинят будущий деплой.
---
## AC-3 — Сохранность deploy-rollback-состояния и sibling-артефактов (жёсткое ограничение)
**Условие:** в `$REPO`/рядом присутствуют `.deploy-prev-image-*` (rollback), `deploy-hook.log`,
`<repos_dir>/.deploy-state-*`, `.merge-lease-*.json`, `.git/worktrees/*`.
- **PASS:** после гигиены **все** перечисленные артефакты на месте; rollback по
`.deploy-prev-image-*` остаётся работоспособным; есть тест, доказывающий их неудаление.
- **FAIL:** гигиена удаляет хотя бы один из этих артефактов (особенно `.deploy-prev-image-*`).
---
## AC-4 — Happy-path без регресса (чистая база)
**Условие:** shared-база чистая, self-deploy выполняет pull.
- **PASS:** поведение и exit-коды (0/1/2, ORCH-036) — байт-в-байт прежние (обычный fast-forward);
полный `pytest tests/ -q` зелёный.
- **FAIL:** изменилось наблюдаемое поведение/exit-код на чистой базе, либо красный регресс.
---
## AC-5 — Self-hosting safety
**Условие:** исполнение пути гигиены/деплоя.
- **PASS:** нет операций над веткой `main` на remote, нет force-push, нет рестарта прод-контейнера
вне штатного гейта, нет удаления worktree/веток других активных задач; операции строго в пределах
настроенного пути deploy-базы; тест/анализ это подтверждает.
- **FAIL:** любое из перечисленных нарушений присутствует или возможно.
---
## AC-6 — Kill-switch и обратимость
**Условие:** новый флаг выключен.
- **PASS:** деплой ведёт себя байт-в-байт как до ORCH-112 (голый `git pull origin main`); включение
флага активирует устойчивое поведение; область скоупится на self-hosting (прочие репо не затронуты).
- **FAIL:** выключенный флаг меняет поведение, либо нет kill-switch, либо затронуты прочие репо.
---
## AC-7 — Сходимость после cancel/failed
**Условие:** задача отменена (STOP/ORCH-090) или job завершился `failed`, оставив остатки в
рабочем дереве deploy-базы.
- **PASS:** shared-база сходится к чистому `origin/main` (через автоочистку в деплое и/или дворник),
и последующий self-deploy проходит без ручного вмешательства; покрыто интеграционным тестом.
- **FAIL:** остатки сохраняются и блокируют последующий деплой/git-операцию.
---
## AC-8 — Наблюдаемость
**Условие:** обнаружена грязная deploy-база.
- **PASS:** факт обнаружения и автоочистки (или отказ) — в логах (структурно) и в Telegram-алерте
(кликабельный номер); алерт best-effort, never-raise (его сбой не валит деплой).
- **FAIL:** тихая очистка без следа в логах/уведомлениях, либо сбой алерта роняет деплой.
---
## AC-9 — Инвариант конвейера и БД не тронуты
**Условие:** диф задачи.
- **PASS:** `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` / machine-verdict
ключи / схема БД / exit-code-контракт хука — байт-в-байт; структурные тесты конвейера зелёные.
- **FAIL:** любой из перечисленных контрактов изменён.
---
## AC-10 — Документация (golden source)
**Условие:** изменён функционал deploy-базы/гигиены.
- **PASS:** обновлены `docs/operations/INFRA.md` (инвариант deploy-база ≠ workspace) и
`docs/architecture/README.md`; `CHANGELOG.md`/`CLAUDE.md` отражают изменение; ADR заведён на
стадии `architecture` (после эскалации `escalate: full-cycle`).
- **FAIL:** функционал изменён, доки/ADR не обновлены (reviewer → finding ≥P1, CLAUDE.md §6).
---
## Сводная матрица AC ↔ FR/BR
| AC | Покрывает |
|----|-----------|
| AC-1 | BR-1 / FR-1 |
| AC-2 | BR-1, BR-2 / FR-1, FR-2 |
| AC-3 | NFR-2 / FR-1 (ограничение) |
| AC-4 | BR-5 / FR-1 |
| AC-5 | NFR-1 / FR-1, FR-2 |
| AC-6 | NFR-3, NFR-6 / FR-5 |
| AC-7 | BR-2 / FR-2 |
| AC-8 | BR-4 / FR-4 |
| AC-9 | NFR-5 / FR-1…FR-5 |
| AC-10 | BR-3 / FR-3 |

View File

@@ -0,0 +1,83 @@
work_item: ORCH-112
stage: analysis
author_agent: analyst
status: ready-for-review
created_at: 2026-06-15
model_used: claude-opus-4-8
title: "Гигиена shared deploy-базы: устойчивость self-deploy git pull к грязному дереву"
framework: pytest
scope: >
Покрывается: устойчивость self-deploy `git pull origin main` к грязной shared deploy-базе
(модифицированные tracked + untracked файлы), сходимость базы к чистому origin/main после
failed/cancelled задач, сохранность deploy-rollback-состояния, kill-switch/область, наблюдаемость,
self-hosting safety. Вне покрытия: модель worktree per-task (ORCH-2, не трогается), запрет ручных
операций оператора, изменения STAGE_TRANSITIONS/QG_CHECKS/схемы БД (их нет).
notes: >
TC-01 — ОБЯЗАТЕЛЬНЫЙ регресс-тест воспроизведения инцидента ORCH-111: КРАСНЫЙ до фикса, ЗЕЛЁНЫЙ
после. Шелл-симуляции хука моделировать по образцу tests/test_deploy_hook_rollback_sim.py
(временный git-репо во временной директории, без сети/прода/ssh). Полный регресс `pytest tests/ -q`
обязан оставаться зелёным (NFR-5). Точные имена тест-модулей/функций уточнит разработчик; тип
гигиены (resilient-pull / janitor / guard) выберет архитектор — тесты сформулированы так, чтобы
проверять ТРЕБУЕМЫЙ ИНВАРИАНТ (база сходится к чистому origin/main, артефакты сохранены), а не
конкретный механизм.
tests:
- id: TC-01
type: integration
description: "РЕГРЕСС (обязательный, red→green): shared deploy-база с локальной модификацией tracked-файла src/config.py + untracked файлами — симуляция шага git pull хука приводит базу к чистому origin/main и НЕ падает с 'local changes would be overwritten by merge' (воспроизводит ORCH-111; красный до фикса)."
module: tests/test_deploy_checkout_hygiene.py
expected: PASS
- id: TC-02
type: integration
description: "Untracked WIP-файлы (install_lite.py / test_install_lite.py / lite-install.example.yaml) в shared-базе не блокируют операцию и база сходится к чистому origin/main."
module: tests/test_deploy_checkout_hygiene.py
expected: PASS
- id: TC-03
type: integration
description: "Сохранность (NFR-2): после гигиены файлы $REPO/.deploy-prev-image-* , deploy-hook.log, sibling .deploy-state-* / .merge-lease-*.json и .git/worktrees/* НЕ удалены; rollback по .deploy-prev-image-* остаётся работоспособным."
module: tests/test_deploy_checkout_hygiene.py
expected: PASS
- id: TC-04
type: integration
description: "Happy-path без регресса: на ЧИСТОЙ shared-базе шаг pull — обычный fast-forward; наблюдаемое поведение и exit-коды (0/1/2, ORCH-036) байт-в-байт прежние."
module: tests/test_deploy_checkout_hygiene.py
expected: PASS
- id: TC-05
type: unit
description: "Self-hosting safety: путь гигиены никогда не оперирует веткой main на remote, не делает force-push, не рестартит прод и не сносит worktree/ветки других задач; операции ограничены настроенным путём deploy-базы (статический/поведенческий ассерт)."
module: tests/test_deploy_checkout_hygiene.py
expected: PASS
- id: TC-06
type: unit
description: "Kill-switch off → деплой/pull байт-в-байт прежний (голый git pull origin main); on → активна устойчивая гигиена. Область applies(repo): self-hosting orchestrator real, прочие репо — no-op."
module: tests/test_deploy_checkout_hygiene.py
expected: PASS
- id: TC-07
type: integration
description: "Сходимость после cancel/failed: cancel_task (ORCH-090) / failed-исход не оставляет рабочих остатков в shared-базе, блокирующих будущий деплой; последующий self-deploy проходит без ручного вмешательства."
module: tests/test_deploy_checkout_hygiene.py
expected: PASS
- id: TC-08
type: unit
description: "Наблюдаемость: обнаружение грязной базы и факт автоочистки (или отказ) попадают в лог; Telegram-алерт best-effort/never-raise (его сбой не валит деплой), номер задачи кликабельный."
module: tests/test_deploy_checkout_hygiene.py
expected: PASS
- id: TC-09
type: unit
description: "Инвариант конвейера: STAGE_TRANSITIONS / реестр QG_CHECKS / имена и семантика check_* / machine-verdict ключи / exit-code-контракт хука — не изменены (структурный анти-регресс)."
module: tests/test_deploy_checkout_hygiene.py
expected: PASS
- id: TC-10
type: unit
description: "Документация-инвариант: docs/operations/INFRA.md и docs/architecture/README.md содержат правило «shared main checkout — deploy/worktree-management база, не workspace» (структурная сверка)."
module: tests/test_deploy_checkout_hygiene.py
expected: PASS

View File

@@ -0,0 +1,244 @@
---
work_item: ORCH-112
stage: architecture
author_agent: architect
status: proposed
created_at: 2026-06-15
model_used: claude-opus-4-8
---
# ADR-001: Гигиена shared deploy-базы — устойчивый self-deploy `git pull` через resilient-pull в хуке
Work Item: **ORCH-112** — failed/cancelled task artifacts must be cleaned from shared checkout
Стадия: **architecture**
Сквозная регистрация: **`docs/architecture/adr/adr-0044-deploy-base-checkout-hygiene.md`** (решение
кросс-каттинговое: новый leaf-компонент на глобальном пути прод-деплоя + изменение прод-deploy-хука).
## Статус
Proposed
## Контекст
Self-deploy задачи **ORCH-111** упал на шаге `git pull origin main` хост-хука с
`error: Your local changes to the following files would be overwritten by merge: src/config.py`.
Деплой прерван → потребовал ручного вмешательства (на self-hosting это групповой риск — встаёт
деплой всех проектов). Грязь оставлена ранее **неуспешной/отменённой/перезапущенной** задачей
ORCH-104 в общем (shared) checkout.
Факты, сверенные с кодом:
1. **Точка отказа — голый pull.** `scripts/orchestrator-deploy-hook.sh:223-226` делает `cd "$REPO"`
(= `settings.deploy_host_repo_path` = main clone, строка 73) и **голый** `git pull origin main`
**без гигиены рабочего дерева**. Любая локальная правка tracked-файла блокирует merge. Во всём
`src/`+`scripts/` нет ни одного `git reset --hard` / `git clean` / `git stash` для приведения базы
к чистому состоянию.
2. **Инвариант «main clone ≠ workspace» соблюдён, но не задокументирован и не энфорснут.** Агенты
работают в worktree'ах `/repos/_wt/<repo>/<branch>` (`git_worktree.ensure_worktree`); `docker build`
берёт контекст **worktree** (`image_freshness._host_worktree_path`); fallback'и гейтов на main clone —
**только чтение** (`git show origin/main:...`). Значит грязь — почти наверняка ручной/брошенный WIP.
Но **нет механизма**, детектирующего/чистящего грязную базу, и **нет задокументированного
инварианта**.
3. **`cancel_task` чистит worktree + remote-ветку, но не shared checkout.** `stage_engine.cancel_task`
(строки 2333-2342): `remove_worktree(repo, branch)` + `gitea.delete_remote_branch(repo, branch)`
нулевое покрытие случая «грязная deploy-база».
4. **NFR-2 (сохранность) — жёсткое ограничение.** Сверено `.gitignore` + `src/config.py`:
- `.env`, `data/`, `*.db`, `.venv/`, `__pycache__/`, `build/`, `.env.staging`, `.env.watchdog`,
`deploy/bundled/repos/`**gitignored** → переживают `git clean -fd` (без `-x`) автоматически.
**Прод-секреты `.env` и БД `data/*.db` пропадут только при ошибочном `-x`.**
- `.deploy-prev-image-prod` (`deploy_prod_prev_image_file`) / `.deploy-prev-image-staging`,
а также `deploy-hook.log` (fallback-локация лога, хук строки 60-65) — **untracked, НЕ gitignored**
→ голый `git clean -fd` их **удалит** → сломает rollback (`do_rollback`, хук строки 107-139).
- Sibling-состояния `<repos_dir>/.deploy-state-<repo>/...` (`self_deploy._state_dir`) и
`<repos_dir>/.merge-lease-<repo>.json` (`merge_gate`, строка 315) лежат под **родителем** `$REPO`
(`settings.repos_dir`, не `$REPO`) → `git clean` в `$REPO` их физически не достаёт.
- `.git/worktrees/*` (админ-записи worktree) — внутри `.git/`, `git clean` его **никогда** не трогает.
«Как есть» не годится: deploy-база трактуется как «всегда чистая», что не гарантировано; устойчивость
должна быть на стороне системы — база обязана **самовосстанавливаться** в чистый `origin/main` перед pull.
## Решение
### Сводка
Сделать self-deploy `git pull` **устойчивым к грязной shared deploy-базе** через **resilient-pull,
встроенный в хук** (`--deploy`): перед `git pull origin main` добавляется детерминированный
hygiene-блок, который при обнаружении грязного дерева приводит базу к чистому актуальному `origin/main`
(`git fetch` + `git reset --hard origin/main` + **скоупленный** `git clean -fd`), **строго сохраняя**
rollback/лог-артефакты (NFR-2). Блок гейтится env-переменной `CHECKOUT_HYGIENE`, которую инжектит
`self_deploy.build_deploy_command` **только** когда новый leaf `src/checkout_hygiene.py`-`applies(repo)`
истинен (kill-switch + self-hosting-скоуп). Сходимость базы после failed/cancelled (FR-2) достигается
этим же deploy-time self-heal — **без** расширения `cancel_task` и **без** фонового «дворника».
Наблюдаемость — sentinel-файл от хука, который читает Phase-C finalizer и шлёт Telegram-алерт.
**Инвариант (NFR-5):** `STAGE_TRANSITIONS` / реестр `QG_CHECKS` / семантика и имена `check_*` /
machine-verdict ключи (`deploy_status:`/`staging_status:`/`security_status:`) / схема БД /
exit-code-контракт хука (0/1/2, ORCH-036) — **байт-в-байт не тронуты**. Это устойчивость deploy-пути
и политика гигиены, **не** Quality Gate и **не** стадия.
### D1 — Механизм: resilient-pull в хуке (а не janitor / не container-side clean) — FR-1, AC-1/AC-2
Падающий `git pull` исполняется **на хосте** внутри detached-хука (`self_deploy.build_deploy_command`
→ ssh + setsid). Поэтому гигиена обязана выполняться **в самом хуке, на хосте, непосредственно перед
pull** — это исключает TOCTOU-гонку, которая возникла бы при чистке shared-mount из контейнера
параллельно бегущему detached-хуку.
Новый блок «2a. Resilient pull» в `scripts/orchestrator-deploy-hook.sh` **между** шагом «1. Capture
PREV_IMG» и шагом «2. Pull latest code», под `if [[ "${CHECKOUT_HYGIENE:-0}" == "1" ]]`:
```bash
# 2a. ORCH-112: resilient pull — converge the shared deploy-base to a clean
# origin/main BEFORE the pull, so a dirty working tree (manual/abandoned WIP)
# never blocks the deploy. Gated by CHECKOUT_HYGIENE (Python kill-switch +
# self-hosting scope). NEVER `-x` (would delete .env/data/*.db); EXCLUDES the
# rollback/log artefacts (NFR-2). Best-effort: any failure is logged and the
# bare `git pull` below still runs (never-break).
if [[ "${CHECKOUT_HYGIENE:-0}" == "1" ]]; then
dirty="$(git status --porcelain 2>/dev/null || true)"
if [[ -n "$dirty" ]]; then
log "HYGIENE: dirty deploy-base detected, converging to origin/main:"
log "$dirty"
git fetch origin main >> "$LOG" 2>&1 || log "HYGIENE: fetch failed (continuing)"
git reset --hard origin/main >> "$LOG" 2>&1 || log "HYGIENE: reset failed (continuing)"
git clean -fd \
-e '.deploy-prev-image-*' \
-e 'deploy-hook.log' \
>> "$LOG" 2>&1 || log "HYGIENE: clean failed (continuing)"
if [[ -n "${HYGIENE_REPORT:-}" ]]; then
{ printf 'dirty=1\n'; printf '%s\n' "$dirty"; } > "$HYGIENE_REPORT" 2>/dev/null || true
fi
else
log "HYGIENE: deploy-base already clean (no-op)"
fi
fi
```
- `git status --porcelain` детектирует грязь; **чистая база → блок no-op** (порожний вывод) → дальше
обычный `git pull` (AC-4, happy-path байт-в-байт).
- `git fetch origin main` обновляет `origin/main`-ref, чтобы `reset --hard origin/main` сходился к
**актуальному** источнику истины; tracked-правки (`src/config.py`) дискардятся (AC-1).
- `git clean -fd` снимает untracked-остатки (AC-2). **`-x` запрещён** (см. D2). Последующий
`git pull origin main` (строка 226, **не изменяется**) становится no-op fast-forward.
- Шаг 1 хука пишет `.deploy-prev-image-prod` **до** hygiene → exclude `-e '.deploy-prev-image-*'`
сохраняет rollback-снимок **этого** деплоя (AC-3).
### D2 — Сохранность deploy-состояния: NFR-2 как жёсткий контракт — AC-3
**INV-HYGIENE-1 (никогда `-x`).** Hygiene-`git clean` исполняется **только** как `git clean -fd`
(без `-x`). `-x` удалил бы gitignored `.env` (прод-секреты), `data/*.db` (БД прода), `build/` — что
катастрофично. Анти-регресс: статический тест ассертит, что hygiene-блок хука **не содержит** токена
`-x` (TC-05/TC-09).
**INV-HYGIENE-2 (явные excludes).** `.deploy-prev-image-*` и `deploy-hook.log` untracked-но-НЕ-ignored
→ обязательны `-e '.deploy-prev-image-*'` и `-e 'deploy-hook.log'`. TC-03 доказывает их неудаление и
работоспособность rollback после гигиены.
**INV-HYGIENE-3 (скоуп = `$REPO`).** Hygiene оперирует **только** рабочим деревом `$REPO`. Sibling
`.deploy-state-*` / `.merge-lease-*.json` (под `<repos_dir>`, родитель `$REPO`) и `.git/worktrees/*`
(внутри `.git/`) **вне** области `git clean` в `$REPO` — подтверждено топологией; гигиена их не достаёт.
### D3 — Гейтинг: leaf `src/checkout_hygiene.py` + инжекция env в `build_deploy_command` — FR-5, AC-6
Новый чистый never-raise leaf `src/checkout_hygiene.py` (по образцу `serial_gate`/`cancel`/`self_deploy`;
импортирует только `config`, лениво — `qg.checks.is_self_hosting_repo`):
- `applies(repo) -> bool``checkout_hygiene_enabled=False``False` (kill-switch, голый pull 1:1 до
ORCH-112); `checkout_hygiene_repos` (CSV) непуст → только перечисленные репо; **пусто →
self-hosting only** (`is_self_hosting_repo`, как `self_deploy_repos`). Локальный, без сети, **первым**.
- `hook_env(repo, work_item_id) -> str` — возвращает префикс `CHECKOUT_HYGIENE=1 HYGIENE_REPORT=<path>`
(через `shlex.quote`) **только** при `applies==True`; иначе `""`. `HYGIENE_REPORT` =
`os.path.join(self_deploy.host_state_dir(repo, work_item_id), "hygiene")` — в том же deploy-state
каталоге, что и `result` (shared mount, читается контейнером).
- `read_report(repo, work_item_id) -> dict | None` — читает sentinel `hygiene` через
`self_deploy.container_state_dir`; never-raise.
- `alert_dirty(...)` — best-effort `send_telegram` (кликабельный номер), never-raise (D5).
- `snapshot() -> dict` — read-only блок для `GET /queue` (флаг/скоуп; опционально).
`self_deploy.build_deploy_command` (строки 253-261) добавляет `checkout_hygiene.hook_env(repo, wi)` в
`env_assignments` (одна строка-присваивание в префиксе detached-команды; точно как ORCH-058
`EXPECTED_REVISION`). Когда `applies==False` → префикс пуст → хук видит `CHECKOUT_HYGIENE` неустановленным
→ блок 2a — no-op → **голый `git pull` (1:1 до ORCH-112)**.
Флаги в `src/config.py` (дефолт = боевое):
- `checkout_hygiene_enabled: bool = True` (env `ORCH_CHECKOUT_HYGIENE_ENABLED`);
- `checkout_hygiene_repos: str = ""` (env `ORCH_CHECKOUT_HYGIENE_REPOS`; пусто → self-hosting only).
### D4 — Сходимость после failed/cancelled: deploy-time self-heal достаточен; `cancel_task` НЕ расширяется — FR-2, AC-7
Нормальный конвейер **не пишет** в main clone (факт 2 контекста) → грязь — ручной/брошенный WIP.
Resilient-pull (D1) приводит базу к чистому `origin/main` **на следующем же self-deploy** → база
**сходится** независимо от источника остатков → FR-2/AC-7 удовлетворены deploy-time self-heal.
`stage_engine.cancel_task` (ORCH-090) **намеренно не расширяется** на shared-базу:
- избегаем касания критично-оконного каскада ORCH-090 (`cancel.in_critical_window`, adr-0026);
- избегаем container-side мутации deploy-базы (гонка с возможным параллельным деплоем);
- расширение было бы избыточным — self-heal в D1 уже гарантирует сходимость.
**Отвергнут активный «дворник» (janitor)** (фоновый актор, приводящий базу к чистоте по таймеру/событию):
новый background-поток + дополнительная гонка с detached-деплоем и держателем merge-lease, без выигрыша
сверх deploy-time self-heal.
### D5 — Наблюдаемость: sentinel хука → Telegram-алерт finalizer'а — FR-4, AC-8
Detached-хук (bash) не шлёт Telegram сам. Он пишет sentinel `hygiene` (`HYGIENE_REPORT`) в deploy-state
каталог. Phase-C finalizer (`stage_engine`, уже читает `result` через `self_deploy.read_result`) после
маппинга exit-code вызывает `checkout_hygiene.read_report` + `alert_dirty` (best-effort):
структурный лог + Telegram (`send_telegram`, кликабельный `ORCH-112` через `plane_issue_link`,
`disable_web_page_preview`). Сбой алерта **не валит** деплой (never-raise, AC-8). Опционально — блок
`checkout_hygiene` в `GET /queue`.
### D6 — Инвариант deploy-базы: документирование + de-facto энфорс — FR-3, AC-10
Инвариант «`<host_repos_dir>/<repo>` (main checkout) — deploy/worktree-management база, **НЕ**
редактируемый workspace; рабочие изменения туда не пишутся конвейером/агентами» документируется в
`docs/operations/INFRA.md` (топология + self-hosting) и `docs/architecture/README.md` (раздел ORCH-36).
**De-facto энфорс** — сам resilient-pull (D1): любая локальная правка дискардится при следующем деплое.
**Отвергнут** тяжёлый рантайм-guard на горячих путях (FR-3 «где осуществимо, без изменения горячих
путей») — он не нужен: self-heal уже обеспечивает сходимость, а guard добавил бы риск/латентность.
### D7 — Скоуп пути: только `--deploy` pull, не `--build-staging`
Hygiene врезается **только** в режим `--deploy` (где есть падающий `git pull`). Режим `--build-staging`
(хук строки 166-204) собирает образ из `BUILD_CONTEXT` = **worktree** и **не делает** `git pull`
hygiene там не нужна и не добавляется.
## Альтернативы
- **`git stash` вместо `reset --hard`** — отвергнуто: накапливает stash-записи в deploy-базе, не
«сходится к чистому origin/main», прячет источник грязи; сложнее и менее детерминирован.
- **Container-side Python clean перед ssh-dispatch** — отвергнуто (D1): TOCTOU-гонка с detached-хуком,
дублирование пути deploy-базы.
- **Активный фоновый janitor** — отвергнуто (D4): новый актор + гонки, нулевой выигрыш над self-heal.
- **Расширить `cancel_task` на shared-базу** — отвергнуто (D4): касание критично-оконного каскада
ORCH-090 + container-side мутация; избыточно.
- **Тяжёлый рантайм-guard инварианта** — отвергнуто (D6): не нужен при self-heal, риск на горячем пути.
- **`git clean -xfd`** — **категорически** отвергнуто (D2/INV-HYGIENE-1): удалит `.env`/`data/*.db`.
## Последствия
- **+** Self-deploy `git pull` устойчив к грязной shared-базе → нет ручного разруливания (BR-1, AC-1/2).
- **+** База **сходится** к чистому `origin/main` после failed/cancelled/брошенных задач (BR-2, AC-7).
- **+** Happy-path и kill-switch-off — байт-в-байт (BR-5, AC-4/AC-6); конвейер/БД/exit-коды не тронуты.
- **+** Наблюдаемость: оператор видит факт автоочистки (BR-4, AC-8); инвариант задокументирован (AC-10).
- **** `reset --hard` **дискардит** локальные правки deploy-базы безвозвратно. Митигейшн: это **ровно**
инвариант (база = `origin/main`, источник истины — remote; deploy лишь fast-forward'ит); скоуп —
self-hosting; наблюдаемость показывает, что именно сброшено.
- **** Новый leaf + хук-блок + флаги = площадь сопровождения. Митигейшн: leaf минимальный, образец
существующих leaf'ов; never-raise; полный набор анти-регресс-тестов (`04-test-plan.yaml`).
- **Откат:** `ORCH_CHECKOUT_HYGIENE_ENABLED=false` → деплой байт-в-байт до ORCH-112 (голый
`git pull origin main`); полный откат — revert leaf + хук-блок + флагов.
## Ссылки
- BRD: `docs/work-items/ORCH-112/01-brd.md`
- TRZ: `docs/work-items/ORCH-112/02-trz.md`
- Acceptance: `docs/work-items/ORCH-112/03-acceptance-criteria.md`
- Test-plan: `docs/work-items/ORCH-112/04-test-plan.yaml`
- Infra-requirements: `docs/work-items/ORCH-112/07-infra-requirements.md`
- Tech-risks: `docs/work-items/ORCH-112/10-tech-risks.md`
- Сквозной ADR: `docs/architecture/adr/adr-0044-deploy-base-checkout-hygiene.md`
- Сверено по коду: `scripts/orchestrator-deploy-hook.sh:73,107-139,223-226`, `src/self_deploy.py:119-135,
220-278`, `src/merge_gate.py:315`, `src/config.py:285-291`, `.gitignore`, `src/stage_engine.py:2333-2342`
- Трассировка (CLAUDE.md §9 / ORCH-078): ORCH-036 (self-deploy, adr-0007), ORCH-058 (image-freshness,
adr-0008), ORCH-090 (cancel, adr-0026) — инварианты не нарушаются.

View File

@@ -0,0 +1,59 @@
---
work_item: ORCH-112
stage: architecture
author_agent: architect
status: proposed
created_at: 2026-06-15
model_used: claude-opus-4-8
---
# 07 — Инфра-требования: ORCH-112 — гигиена shared deploy-базы
Work Item: **ORCH-112** · Repo: **orchestrator** · Стадия: architecture
> When-applicable. Затрагивается **жизненный цикл shared deploy-базы** (`<host_repos_dir>/<repo>`),
> а не топология контейнеров/портов/томов. Контейнеры/сеть/тома — `N/A`.
## I-1. Топология / окружения
**Без изменений в составе.** Контейнеры (`orchestrator` 8500 / `orchestrator-staging` 8501), сеть
(`network_mode: host`), порты, тома — прежние.
Затрагивается **deploy-база** `<host_repos_dir>/<repo>` (= `/home/slin/repos/orchestrator` ==
`/repos/orchestrator` в контейнере через bind-mount == `settings.deploy_host_repo_path`). **Нормативно
закрепляется инвариант:** deploy-база — **deploy/worktree-management база, НЕ редактируемый workspace**.
Рабочие изменения туда не пишутся конвейером/агентами (агенты — worktree `/repos/_wt/<repo>/<branch>`,
build — worktree-контекст, fallback'и гейтов — read-only `git show origin/main`). Документируется в
`docs/operations/INFRA.md` (топология + self-hosting) и `docs/architecture/README.md` (раздел ORCH-36).
**Контракт сохранности рабочего дерева deploy-базы (NFR-2, жёсткий):** автоочистка hygiene
(`git clean -fd`, **без** `-x`) **обязана сохранять**:
| Артефакт | Расположение | Почему сохраняется |
|----------|--------------|--------------------|
| `.deploy-prev-image-prod` / `.deploy-prev-image-staging` | `$REPO/` (untracked, НЕ ignored) | rollback-снимок → `-e '.deploy-prev-image-*'` |
| `deploy-hook.log` | `$REPO/` (fallback-лог) | аудит → `-e 'deploy-hook.log'` |
| `.env`, `data/`, `*.db`, `build/` | `$REPO/` (gitignored) | прод-секреты/БД → переживают `git clean` **без** `-x` |
| `.deploy-state-<repo>/*`, `.merge-lease-<repo>.json` | `<repos_dir>/` (sibling, родитель `$REPO`) | вне области `git clean` в `$REPO` |
| `.git/worktrees/*` | `$REPO/.git/` | `git clean` никогда не трогает `.git/` |
## I-2. Переменные окружения / секреты
Две новые env-переменные (`src/config.py`, дефолт = боевое; **обновить `.env.example`**):
| Ключ | Env | Дефолт | Назначение |
|------|-----|--------|-----------|
| `checkout_hygiene_enabled` | `ORCH_CHECKOUT_HYGIENE_ENABLED` | `True` | kill-switch resilient-pull; `False` → голый `git pull` (1:1 до ORCH-112) |
| `checkout_hygiene_repos` | `ORCH_CHECKOUT_HYGIENE_REPOS` | `""` | CSV-скоуп; пусто → self-hosting only (`orchestrator`) |
Внутренние env, инжектируемые в detached-хук `self_deploy.build_deploy_command` (не операторские):
`CHECKOUT_HYGIENE=1`, `HYGIENE_REPORT=<host_state_dir>/hygiene`. Новых секретов нет.
## I-3. Деплой / рестарт
**Рестарт прод-контейнера задачей ORCH-112 — НЕ требуется и ЗАПРЕЩЁН** (self-hosting инвариант,
CLAUDE.md). Изменение активируется штатно: новый промпт/хук/код `cat`-ается/деплоится в обычном
self-deploy-цикле через **staging-гейт (8501)** сначала, затем `Confirm Deploy` (ORCH-059). Хук-блок
hygiene исполняется **только** в `--deploy` режиме (где есть `git pull`); `--build-staging` собирает из
worktree и не пуллит → не затронут. Exit-code-контракт хука (0/1/2, ORCH-036) — байт-в-байт.
## I-4. CI/CD
**Без изменений** `.gitea/workflows/`. Новый тест-модуль `tests/test_deploy_checkout_hygiene.py`
(шелл-симуляция хука во временном git-репо, без сети/прода/ssh — образец
`tests/test_deploy_hook_rollback_sim.py`) исполняется обычным `pytest tests/ -q`. Полный регресс обязан
оставаться зелёным (NFR-5).

View File

@@ -0,0 +1,42 @@
---
work_item: ORCH-112
stage: architecture
author_agent: architect
status: proposed
created_at: 2026-06-15
model_used: claude-opus-4-8
---
# 10 — Технические риски: ORCH-112 — гигиена shared deploy-базы
Work Item: **ORCH-112** · Repo: **orchestrator** · Стадия: architecture
> Информационный (гейтом не парсится). Риски реализации resilient-pull и их митигейшн.
## Реестр рисков
| ID | Риск | Вер. | Влия. | Митигейшн |
|----|------|------|-------|-----------|
| TR-1 | **`git clean -x`** ошибочно добавлен → удалит gitignored `.env` (прод-секреты) / `data/*.db` (БД прода) / `build/` — катастрофа на прод-deploy-базе | Низ. | **Выс.** | INV-HYGIENE-1 (ADR D2): только `git clean -fd`, **никогда** `-x`. Статический анти-регресс-тест ассертит отсутствие `-x` в hygiene-блоке хука (TC-05/TC-09); явная рамка в ADR + INFRA |
| TR-2 | Неверный/отсутствующий `-e` exclude → `git clean -fd` удалит `.deploy-prev-image-*` → сломан rollback (`do_rollback`) | Сред. | **Выс.** | INV-HYGIENE-2: обязательные `-e '.deploy-prev-image-*'` + `-e 'deploy-hook.log'`; TC-03 доказывает неудаление и работоспособность rollback; шаг 1 хука пишет prev-image **до** hygiene |
| TR-3 | Сбой шага hygiene (fetch/reset/clean) маскирует/ухудшает исход деплоя | Низ. | Сред. | never-break (ADR D1): каждая git-операция `\|\| log "...continuing"`; деплой продолжается к голому `git pull`; sentinel-отчёт фиксирует факт; fail-safe, исход не хуже текущего |
| TR-4 | `reset --hard origin/main` безвозвратно дискардит локальные правки deploy-базы, которые кто-то «нужными» считал | Низ. | Сред. | Это **ровно** инвариант: deploy-база = `origin/main` (источник истины — remote); deploy лишь fast-forward'ит. Наблюдаемость (D5) показывает сброшенное; скоуп — self-hosting; документировано (INFRA/README) |
| TR-5 | Гонка: hygiene на хосте чистит mount, пока контейнер читает deploy-базу | Низ. | Низ. | Деплой сериализован (serial-gate ORCH-088, один деплой за раз); hygiene в detached-хуке непосредственно перед pull; нормальный конвейер deploy-базу не читает в этот момент (worktree-изоляция). TOCTOU между `status` и `reset` пренебрежимо (один процесс) |
| TR-6 | Скоуп-leak: hygiene затронет прочие репо / синхронный деплой агентом | Низ. | Сред. | `applies(repo)` (локально, первым): пусто → self-hosting only; инжекция env только на self-deploy-пути (сам self-hosting-скоупленный, `self_deploy_applies`); TC-06 |
| TR-7 | Стейл `origin/main` (fetch не выполнился) → `reset --hard` сходится к устаревшему коммиту | Низ. | Низ. | `git fetch origin main` перед reset; при сбое fetch — `\|\| log` + продолжение; последующий `git pull origin main` (строка 226, не тронута) до-тянет недостающее; deploy промоутит build-once `SOURCE_IMAGE` (артефакт не зависит от дерева main clone) |
| TR-8 | Расширение объёма (касание `cancel_task`/`STAGE_TRANSITIONS`/QG) при реализации | Низ. | Сред. | ADR D4 явно запрещает расширение `cancel_task`; NFR-5 байт-в-байт; TC-09 структурно ассертит неизменность контрактов; трассировка ORCH-036/058/090 |
## Сводный вывод
Доминирующий класс — **деструктивная гигиена рядом с прод-rollback-состоянием** (TR-1/TR-2): низкая
вероятность, высокое влияние, **полностью** снимается контрактом сохранности (INV-HYGIENE-1/2) + явными
тестами (TC-03/TC-05/TC-09). Изменение аддитивно, под kill-switch (`checkout_hygiene_enabled`, дефолт
`True`; off → байт-в-байт до ORCH-112), never-raise, self-hosting-скоупленное, **не трогает**
`STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/схему БД/exit-code-контракт хука.
**Эскалация:** вводится новый leaf-компонент (`src/checkout_hygiene.py`) на глобальном пути прод-деплоя
+ правка прод-deploy-хука + сквозной ADR adr-0044 → рекомендуется лейбл **`arch:major-change`** для
reviewer-внимания (изменение safety-critical, в прод-deploy-пути). Возврат в анализ **не** требуется:
ТЗ удовлетворяется без нарушения принципов архитектуры (всё в Docker на одном сервере, без новых
зависимостей/очередей/k8s, без рестарта прода вне staging-гейта). Остаточный риск для прод-конвейера —
**низкий** при соблюдении INV-HYGIENE-1/2/3.

View File

@@ -0,0 +1,123 @@
---
verdict: APPROVED # APPROVED | REQUEST_CHANGES — строго одно из двух, UPPERCASE
work_item: ORCH-112
stage: review
author_agent: reviewer
status: approved
created_at: 2026-06-15
model_used: claude-opus-4-8
type: review
work_item_id: ORCH-112
version: 1
---
# Review ORCH-112 — deploy-base checkout-hygiene (resilient-pull)
## Summary
Багфикс инцидента **ORCH-111** (bug → escalate full-cycle): прод-self-deploy падал на голом
`git pull origin main` хост-хука из-за грязного shared main checkout (остатки ORCH-104 от ORCH-104).
Реализован **resilient-pull в хуке** (`--deploy`): перед pull при обнаружении грязи база сводится к
чистому `origin/main` (`git fetch` + `git reset --hard origin/main` + скоупленный `git clean -fd`),
под kill-switch, never-raise, скоуп self-hosting.
Проверены все 4 оси. Реализация **точно соответствует** ADR-001 (D1D7) и сквозному adr-0044, все
10 критериев приёмки (AC-1…AC-10) покрыты содержательными тестами, документация (golden source)
обновлена в том же PR, инварианты конвейера/БД/exit-code-контракт хука — байт-в-байт не тронуты.
**Вердикт: APPROVED.** P0/P1/P2 findings отсутствуют.
### Что сверено (доказательная база)
**Ось 1 — соответствие ТЗ (02-trz) / критериям (03-acceptance-criteria):**
- FR-1 (устойчивый pull) / AC-1 — ✅ хук-блок «2a. Resilient pull» + регресс **TC-01** (зелёный после
фикса) и **TC-01b** (тот же грязный base без гигиены → `would be overwritten by merge`, репро инцидента).
- FR-1 / AC-2 (untracked WIP) — ✅ **TC-02** (остатки сняты, не протекают в деплой).
- NFR-2 / AC-3 (сохранность) — ✅ **TC-03** (`.deploy-prev-image-*`, `deploy-hook.log`, gitignored
`.env`/`data/*.db`, sibling `.deploy-state-*`/`.merge-lease-*.json`, `.git/worktrees/*` — на месте) +
**TC-05** статический контракт (`git clean -fd`, **никогда `-x`**, явные excludes).
- BR-5 / AC-4 (happy-path) — ✅ **TC-04** (чистая база → no-op + fast-forward, exit-коды байт-в-байт).
- NFR-1 / AC-5 (self-hosting safety) — ✅ скоуп `$REPO`, `reset --hard origin/main` (не локальная
догадка), нет push/force-push (TC-05 ассерт).
- FR-5 / AC-6 (kill-switch + обратимость) — ✅ **TC-06** (off → инертно; пустой CSV → self-hosting only;
enduro не затронут).
- FR-2 / AC-7 (сходимость после cancel/failed) — ✅ **TC-07** (deploy-time self-heal; `cancel_task`
корректно НЕ расширён — D4).
- FR-4 / AC-8 (наблюдаемость) — ✅ **TC-08** (`read_report`/`alert_dirty` never-raise) + врезка в
`run_deploy_finalizer` (sentinel → Telegram, best-effort).
- NFR-5 / AC-9 (инвариант конвейера/БД) — ✅ **TC-09** + проверка дифа: `STAGE_TRANSITIONS`/`QG_CHECKS`/
`check_*`/machine-verdict/схема БД/exit-code-контракт хука (0/1/2) не тронуты.
- BR-3 / AC-10 (документация) — ✅ см. ось 4.
**Ось 2 — соответствие ADR:**
- ADR-001 D1D7 реализованы дословно: resilient-pull в хуке (не janitor/не container-side, D1),
NEVER `-x` + excludes (D2), leaf `checkout_hygiene.py` + инжекция env в `build_deploy_command` (D3),
`cancel_task` не расширяется / janitor не вводится (D4), sentinel → finalizer-alert (D5), docs (D6),
только `--deploy` не `--build-staging` (D7, подтверждено размещением блока между шагами 1 и 2 пути
`--deploy`).
- Трассировка (ORCH-078): правка `build_deploy_command` (маркеры ORCH-101/ORCH-058) — чисто аддитивна
(одно env-присваивание после `EXPECTED_REVISION`), инвариант image-freshness не сломан; ORCH-036
exit-code-контракт и ORCH-090 cancel-каскад не нарушены; INV-4 (никогда push/force-push `main`)
соблюдён.
**Ось 3 — качество кода:**
- Leaf чистый, never-raise, ленивые импорты (`self_deploy`/`qg.checks`/`notifications`) — leaf-инвариант
доказан **TC-05** (`leaf_is_a_pure_leaf`). Docstrings на всех публичных функциях. `shlex.quote` на
инжектируемом пути. Env-проводка консистентна с существующим паттерном `result`-sentinel
(`initiate_deploy` пред-создаёт `container_state_dir` → запись `hygiene` гарантированно проходит).
- **Багфикс-трек регресс-тест (ORCH-019 / BR-4):** присутствует — **TC-01** (фиксатор дефекта,
зелёный после фикса) в паре с **TC-01b** (репродукция инцидента: голый pull аборт без гигиены).
- Все ссылки на API существуют (`notifications.link_for`/`send_telegram`, `self_deploy.host_state_dir`/
`container_state_dir`, `qg.checks.is_self_hosting_repo`). `repo`/`work_item_id`/`task_id` в скоупе
финализатора.
- Тесты содержательные: 17 TC (шелл-симуляция реального хука в герметичном git-репо без сети/прода/ssh
+ unit). Прогон: **17/17 зелёные**; смежные deploy/config/stage_engine/frontmatter — **200/200 зелёные**;
docs/hardcode/canon — **101/101 зелёные**.
**Ось 4 — документация (golden source):**
- `src/` изменён → документация обновлена **в том же PR**: `docs/operations/INFRA.md` (инвариант
deploy-база ≠ workspace), `docs/architecture/README.md` (раздел ORCH-112 design), `CHANGELOG.md`,
`CLAUDE.md` (паспортный блок), `.env.example` (новые ключи), ADR-001 + сквозной
`docs/architecture/adr/adr-0044`. Консистентны между собой и с кодом.
- Обзорные доки (ORCH-079): открытые пункты `README.md` «Известные ограничения» (Telegram 48h /
intra-repo deps / batch-автоном) этим PR **не закрываются** → обновление не требуется. ✅
- Витрина системы (ORCH-011): фикс — внутренняя устойчивость deploy-пути, **не** новая
стадия/гейт/агент/интеграция/способность → витрина `docs/overview/` не затронута;
`tests/test_system_docs.py` зелёный. ✅
## Findings
### P0 — Blocker
- Нет.
### P1 — Must fix
- Нет.
### P2 — Should fix
- Нет.
### P3 — Nice-to-have (не блокирует, на усмотрение)
- `tests/test_deploy_checkout_hygiene.py::test_tc05_hook_clean_is_never_destructive` ассертит
`assert "-x" not in code` по **всем** исполняемым строкам хука. Текущий хук токена `-x` не содержит
(тест зелёный), но будущая легитимная конструкция (`set -x`, `[ -x file ]`, `chmod +x`) ложно уронит
ассерт. Можно сузить проверку до строки(ок) `git clean` — но это страховка критичного инварианта
INV-HYGIENE-1, поэтому строгость намеренна и допустима. Не блокирует.
## Документация
**Статус: обновлена полностью, в том же PR (golden source соблюдён).**
| Документ | Статус |
|----------|--------|
| `docs/work-items/ORCH-112/06-adr/ADR-001-deploy-base-checkout-hygiene.md` | ✅ заведён (architecture, после escalate full-cycle) |
| `docs/architecture/adr/adr-0044-deploy-base-checkout-hygiene.md` | ✅ сквозной ADR заведён |
| `docs/operations/INFRA.md` | ✅ инвариант deploy-база ≠ workspace + страховка resilient-pull |
| `docs/architecture/README.md` | ✅ раздел ORCH-112 (design) |
| `CHANGELOG.md` | ✅ запись [Unreleased] |
| `CLAUDE.md` | ✅ паспортный блок |
| `.env.example` | ✅ `ORCH_CHECKOUT_HYGIENE_ENABLED` / `_REPOS` |
| `docs/overview/` (витрина, ORCH-011) | не требуется (внутренний deploy-fix, не новая способность) |
| `README.md` «Известные ограничения» (ORCH-079) | не требуется (открытые пункты не закрываются) |
Необновлённой документации при изменённом `src/` **нет** → ось 4 пройдена, P0 по документации
отсутствует.

View File

@@ -0,0 +1,71 @@
---
result: PASS # PASS | FAIL — машинный вердикт, UPPERCASE
work_item: ORCH-112
stage: testing
author_agent: tester
status: pass
created_at: 2026-06-15
model_used: claude-opus-4-8
type: test-report
work_item_id: ORCH-112
---
# Test Report — ORCH-112
Гигиена shared deploy-базы: устойчивость self-deploy `git pull` к грязному дереву
(багфикс инцидента ORCH-111). Review-вердикт: **APPROVED** (`12-review.md`).
## Окружение
- Python: 3.12.13
- pytest: 8.3.3 (plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8)
- Worktree: `/repos/_wt/orchestrator/feature_ORCH-112-bug-failed-cancelled-task-arti/`
- Ветка: `feature/ORCH-112-bug-failed-cancelled-task-arti`
- Дата: 2026-06-15
## Smoke API (read-only)
| Endpoint | Результат |
|----------|-----------|
| `GET /health` | PASS — `{"status":"ok","service":"orchestrator"}` |
| `GET /status` | PASS — задача 102 ORCH-112 на стадии `testing`, ветка совпадает |
| `GET /queue` | PASS — блок `serial_gate` присутствует (ORCH-088); `auto_labels` присутствует |
Блок `checkout_hygiene`/`serial_gate`/`auto_labels` — все на месте в полезной нагрузке `/queue`,
регресса смока нет.
## Покрытие ТЗ (TC из 04-test-plan.yaml ↔ 03-acceptance-criteria)
| TC ID | Описание | AC | Тест | Результат |
|-------|----------|----|------|-----------|
| TC-01 | Регресс ORCH-111: грязный tracked `src/config.py` + untracked → база сходится к чистому `origin/main`, pull не падает (red→green) | AC-1 | `test_tc01_dirty_tracked_edit_converges_and_deploys` (+ `test_tc01b_bare_pull_aborts_without_hygiene_documents_incident`) | PASS |
| TC-02 | Untracked WIP-файлы не блокируют и не протекают в деплой | AC-2 | `test_tc02_untracked_wip_does_not_block` | PASS |
| TC-03 | Сохранность `.deploy-prev-image-*`/`deploy-hook.log`/sibling `.deploy-state-*`/`.merge-lease-*.json`/`.git/worktrees/*` (NFR-2) | AC-3 | `test_tc03_preserves_rollback_and_sibling_artifacts` | PASS |
| TC-04 | Happy-path: чистая база → fast-forward, exit-коды байт-в-байт | AC-4 | `test_tc04_clean_base_fast_forwards_no_op_hygiene` | PASS |
| TC-05 | Self-hosting safety: нет операций над `main`/force-push/рестарта прода; `git clean -fd` (никогда `-x`); leaf чист | AC-5 | `test_tc05_hook_clean_is_never_destructive`, `test_tc05_leaf_is_a_pure_leaf` | PASS |
| TC-06 | Kill-switch off → инертно; пустой CSV → self-hosting only; скоуп репо | AC-6 | `test_tc06_kill_switch_off_is_inert`, `test_tc06_empty_csv_is_self_hosting_only`, `test_tc06_csv_scope_limits_repos` | PASS |
| TC-07 | Сходимость после cancel/failed → следующий self-deploy чист | AC-7 | `test_tc07_convergence_then_next_deploy_is_clean` | PASS |
| TC-08 | Наблюдаемость: `read_report`/`alert_dirty`, Telegram best-effort/never-raise | AC-8 | `test_tc08_read_report_none_when_absent`, `test_tc08_read_report_parses_dirty_sentinel`, `test_tc08_alert_dirty_never_raises_on_send_failure` | PASS |
| TC-09 | Инвариант конвейера: `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict/exit-code-контракт хука не тронуты | AC-9 | `test_tc09_pipeline_contracts_untouched`, `test_tc09_hook_exit_code_contract_intact` | PASS |
| TC-10 | Документация-инвариант: INFRA.md и architecture/README.md содержат правило «main checkout — deploy-база, не workspace» | AC-10 | `test_tc10_docs_state_deploy_base_invariant` | PASS |
Каждый TC из `04-test-plan.yaml` выполнен и сопоставлен с критерием приёмки `03-acceptance-criteria.md`.
TC-01 (обязательный red→green регресс инцидента ORCH-111) — зелёный; парный TC-01b документирует
аборт голого pull без гигиены.
## Вывод pytest
### Целевой модуль `tests/test_deploy_checkout_hygiene.py`
```
collected 17 items
... 17 passed, 1 warning in 7.51s
```
### Полный регресс `pytest tests/ -q`
```
2018 passed, 1 warning in 342.01s (0:05:42)
```
(единственный warning — Pydantic V2 deprecation в `src/config.py:8`, существующий, не связан с задачей)
## Итог
PASS — все 10 TC (17 тест-функций) зелёные, полный регресс 2018/2018 зелёный, smoke API OK
(`/health`, `/status`, `/queue` с блоками `serial_gate` и `auto_labels`). Задача готова к переходу
на `deploy-staging`.

View File

@@ -0,0 +1,12 @@
---
deploy_status: SUCCESS
work_item: ORCH-112
hook_exit_code: 0
deployed_by: deploy-finalizer
---
# Deploy log — ORCH-036 executable self-deploy
Прод-деплой завершён хост-хуком с exit-code `0` -> `deploy_status: SUCCESS`.
Вердикт зафиксирован детерминированным finalizer'ом (Фаза C), не LLM.

View File

@@ -0,0 +1,38 @@
---
staging_status: SUCCESS
work_item: ORCH-112
stage: deploy-staging
author_agent: deployer
status: success
created_at: 2026-06-15
model_used: claude-opus-4-8
timestamp: 2026-06-15T12:11:26Z
base_url: http://localhost:8501
---
# Staging Gate Log
Staging test suite completed against the live staging environment (`orchestrator-staging`,
port 8501), executed inside the container via the canonical path
`/repos/orchestrator/scripts/staging_check.py --base-url http://localhost:8501 --mode stub`
(ORCH-048: B6 registry-isolation reads `.env.staging` from the running instance's own process-env).
**Result: 8/10 checks PASS — exit code 0 → SUCCESS.**
- REAL failed: none
- SANDBOX_INFRA failed (waived, ORCH-061): C9a, C9b
The two failing checks (C9a "Branch appears in orchestrator-sandbox", C9b "Analyst job enqueued in
staging queue") are the known sandbox-infra checks that depend on SANDBOX bot accounts being project
members — not on the pipeline. With every REAL check green, the suite waives them and exits 0.
```
INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green)
VERDICT: SUCCESS (exit 0) — SUCCESS (infra-waived): ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue'] are known sandbox-infra checks; all real checks green
```
Block A (SMOKE): A1 /health 200, A2 /queue 200, A3 ORCH_STAGING=true — all PASS.
Block B (ACCESS): B4 Plane sandbox, B5 Gitea push, B6 registry isolation — all PASS.
Block C (E2E, stub): C7 create issue PASS, C8 trigger pipeline PASS, C9a/C9b waived sandbox-infra.
Staging gate passed. Task may advance to the `deploy` stage.

View File

@@ -0,0 +1,14 @@
---
post_deploy_status: HEALTHY
action_taken: NONE
work_item: ORCH-112
window_s: 900
checks_total: 30
checks_failed: 0
---
# Post-deploy log — ORCH-021 post-deploy monitor
Наблюдение прода завершено: `post_deploy_status: HEALTHY`, `action_taken: NONE`.
Окно наблюдения: 900s; опросов всего: 30, из них с провалом: 0.

View File

@@ -0,0 +1,7 @@
# Business Request: BUG: job-reaper must not re-run deploy-staging finalization while original finalizer is alive
Work Item ID: ORCH-113
## Description
TBD

View File

@@ -0,0 +1,167 @@
---
work_item: ORCH-113
stage: analysis
author_agent: analyst
status: ready-for-review
created_at: 2026-06-15
model_used: claude-opus-4-8
escalate: full-cycle
---
# 01 — BRD (бизнес-требования): ORCH-113 — BUG: job-reaper не должен повторно запускать финализацию `deploy-staging`, пока жив исходный finalizer
Work Item: **ORCH-113** · Repo: **orchestrator** · Стадия: analysis
> **Багфикс-трек → эскалация в полный цикл (`escalate: full-cycle`).** Задача помечена `Bug`, но
> сама баг-карточка явно требует «анализ контракта reaper, статуса `running/finalizing`, длительности
> grace и идемпотентности edge-гейтов» (см. «Ограничение» в бизнес-запросе) — это решение с
> несколькими проектными альтернативами (liveness-heartbeat finalizer'а / явный sub-state
> `finalizing` / per-stage grace / ownership-lease на edge-гейты) и нетривиальными инвариантами
> self-hosting, затрагивающее **задокументированный сквозной инвариант ORCH-065** (контракт
> живости reaper, `adr-0011`). По правилу ORCH-019 (ADR-001 D5) выпускается **полный** analysis-пакет,
> а трек эскалируется (`POST /bug-fast-track/escalate?work_item=ORCH-113`) → задача проходит стадию
> `architecture`. Прецедент — родственные задачи того же инцидент-кластера: ORCH-110 / ORCH-111
> («bug → escalate full-cycle»).
---
## 1. Бизнес-контекст и проблема
Оркестратор — self-hosting инструмент: его прод-контейнер обслуживает конвейер **всех** проектов из
одного инстанса с общей БД и общей очередью и дорабатывает сам себя. Фоновый демон **job-reaper**
(`src/job_reaper.py`, ORCH-065) — страховочный слой: он добивает «зомби»-job'ы, чей монитор умер,
не записав терминальный статус. Его Tier-2-ветка (процесс агента завершился — `agent_runs.exit_code`
записан, — но job всё ещё `running`) **неоднозначна**: это одновременно «монитор умер посреди
финализации» И «живой монитор ещё финализирует». Reaper разрешает неоднозначность таймером —
**finalization grace** `reaper_finalize_grace_s = 300` (db.py:1345-1348, job_reaper.py:36-44): если
`exit_code` записан дольше grace — трактует ситуацию как **мёртвый монитор** и сам до-водит стадию.
**Корневая ошибка контракта:** grace=300с построен на задокументированном допущении, что после записи
`finished_at` монитор делает лишь «git commit/push (+PR), БАГ-8-проверку и сетевые Plane-комментарии —
**секунды…десятки секунд**, и ТОЛЬКО ПОТОМ `_try_advance_stage`». Для ребра `deploy-staging → deploy`
это **неверно**: `_try_advance_stage` (`launcher._monitor_agent`, строка 998) синхронно, в потоке
монитора, прогоняет **весь набор тяжёлых детерминированных edge-под-гейтов**
`security``merge-gate` (полный локальный re-test, бюджет `merge_retest_timeout_s = 900`) →
`coverage` (ещё один полный `pytest --cov`) → `image-freshness` (docker-rebuild + пересоздание
staging). Это **минуты**, и весь этот объём идёт **ПОСЛЕ** штампа `finished_at` (launcher:861) и
**ДО** `_finalize_job` (launcher:1003). `finished_age_s` reaper меряет именно от `finished_at`
(db.py:1360) — то есть от **начала** финализации. Итог: пока живой монитор ещё внутри edge-гейтов,
reaper по истечении 300с считает его мёртвым и **независимо запускает тот же тяжёлый набор edge-гейтов
повторно**.
**Установленные факты инцидента (ORCH-111, deployer job `1914`, run_id `683`):**
- deployer завершился `exit_code=0` и записал `15-staging-log.md` со `staging_status: SUCCESS`;
- после выхода агента job `1914` оставалась `running`, т.к. монитор ещё финализировал стадию;
- финализация `deploy-staging` заняла **дольше 300с** (полный локальный re-test + coverage);
- reaper после `reaper_finalize_grace_s=300` трактовал это как умерший monitor и повторно вызвал
gate-driven advance (`_reap_exit0``_gate_driven_advance``_try_advance_stage``advance_stage`);
- edge-гейты `deploy-staging` исполнились **повторно**: `security-gate`, `merge-gate`, rebase, полный
локальный re-test;
- один из повторных re-test стал **красным**: `3 failed, 1916 passed, 1 warning, 14 errors in 444.79s`;
- задача была откатана `deploy-staging → development` (+ ложный developer-retry), хотя **параллельно**
исходный prod-deploy/finalizer дошёл до `deploy_status: SUCCESS`, **PR #130 был смержен**, задача
перешла `deploy → done`.
**Симптом:** две ветки системы расходятся по состоянию **одной** задачи — одна повторно откатывает
`deploy-staging`, другая успешно завершает deploy. Гонка + ложный rollback + ложный developer-retry +
шумные алерты + несогласованное состояние Plane/БД.
**Почему существующие гарды reaper не спасли:** атомарный claim-before-act
(`reap_running_job(... WHERE status='running')`, job_reaper.py:280) защищает **строку job** от
двойного терминального флипа, но **не защищает побочное исполнение edge-гейтов**: reaper вызывает
`_gate_driven_advance → advance_stage`, который и прогоняет тяжёлые под-гейты, **до/независимо** от
монитора. Гонка — в **side-effectful исполнении edge-гейтов**, а не в флипе строки. Дешёвая
read-only пред-проверка `_gate_is_green('deploy-staging')` читает лишь `check_staging_status`
(frontmatter `15-staging-log.md` = `SUCCESS`, зелёный) → reaper уверенно идёт в тяжёлый advance.
Tier-3 backstop (`reaper_max_running_s = 5400`) при этом не срабатывает — баг чисто в Tier-2 grace.
## 2. Объём (scope)
### В объёме
- Reaper **не должен** повторно исполнять тяжёлую финализацию `deploy-staging`/merge-gate (security /
merge-gate / локальный re-test / coverage / image-freshness), пока исходный monitor/finalizer ещё
**жив** или пока edge-гейты для этого job/stage **уже исполняются**.
- Повторная обработка завершившегося-но-ещё-`running` job на `deploy-staging` должна быть
**идемпотентной**: без второго локального re-test/merge-gate для того же job/stage без **строгого
владения состоянием**.
- Согласование Tier-2 grace (`reaper_finalize_grace_s`) с **фактической** wall-clock-длительностью
финализации `deploy-staging` ИЛИ замена таймерного критерия живости на сигнал, переживающий
«долгую, но живую» финализацию.
- Сохранение основной функции reaper (ORCH-065): реально **мёртвый** finalizer на `deploy-staging`
по-прежнему добивается за ограниченное время.
### Вне объёма
- Изменение `STAGE_TRANSITIONS` / `QG_CHECKS` / семантики любого `check_*` / machine-verdict ключей /
схемы существующих таблиц (правки — только аддитивные).
- Инфра-толерантность merge-gate к таймауту re-test и tree-kill осиротевших pytest-процессов — это
**ORCH-110** (союзная задача того же инцидента; не дублировать).
- Починка конкретных «мигающих» тестов, давших `3 failed … 14 errors`.
- Полный редизайн reaper или модели финализации монитора.
- **Выбор механизма** решения (heartbeat / sub-state `finalizing` / per-stage grace / ownership-lease)
— это **архитектурное решение** (06-adr), не зона аналитика.
## 3. Заинтересованные стороны
- **Owner / Слава** — заказчик исправления, держатель инвариантов self-hosting.
- **Конвейер всех проектов** (orchestrator self-hosting + enduro-trails) — общий инстанс/БД/очередь:
ложный rollback и гонка состояния касаются стабильности платформы в целом.
- **Операторы** — получатели алертов; именно их будят ложные «merge-gate FAILED / rolled back».
- **Архитектор** — принимает решение по механизму владения/живости (06-adr) после эскалации.
## 4. Бизнес-требования (BR)
- **BR-1** — Reaper **не должен** запускать второй прогон edge-гейтов ребра `deploy-staging → deploy`
(security / merge-gate / re-test / coverage / image-freshness) для job, чей исходный
monitor/finalizer **ещё жив**.
- **BR-2** — Повторная обработка завершившегося-но-`running` job на `deploy-staging` **идемпотентна**:
не более **одного** локального re-test/merge-gate на пару (job, stage) без строгого владения
состоянием; второй актор, не владеющий состоянием, **не исполняет** побочных шагов.
- **BR-3** — Критерий живости Tier-2 должен учитывать **реальную** wall-clock-длительность
финализации `deploy-staging` (включающую полный набор edge-гейтов), ИЛИ живость должна определяться
сигналом, который **переживает** долгую-но-живую финализацию (не одним `finished_age_s`).
- **BR-4** — Реально **мёртвый** монитор (краш посреди финализации `deploy-staging`) по-прежнему
должен добиваться reaper'ом за ограниченное время — основная функция ORCH-065 **сохраняется**;
фикс не превращает reaper в no-op для `deploy-staging`.
- **BR-5** — После согласования у задачи — **единственное** консистентное состояние: **никакого**
ложного отката `deploy-staging → development` и **никакого** ложного developer-retry после
фактически успешного deploy; ветки системы сходятся, не расходятся.
## 5. Нефункциональные требования (NFR)
- **NFR-1** — Контракт reaper сохранён: **never-raise** на единицу работы, **kill-switch**,
fail-safe; reaper остаётся наблюдателем-страховкой, не Quality Gate'ом.
- **NFR-2** — `STAGE_TRANSITIONS` / `QG_CHECKS` / каждый `check_*` / machine-verdict ключи / схема
существующих таблиц — **байт-в-байт**; любые БД-правки — только **аддитивные** (`_ensure_column` /
`CREATE TABLE IF NOT EXISTS`).
- **NFR-3** — Self-hosting-безопасно: фикс **никогда** не рестартит/не роняет прод-контейнер и
**никогда** не пушит/force-push'ит `main`.
- **NFR-4** — Обратная совместимость и обратимость: поведение reaper для **не-`deploy-staging`** стадий
и путь добивания **мёртвого** монитора сохранены; выключенный kill-switch → строго прежнее
поведение; раскат обратим.
- **NFR-5** — Restart-safe: in-memory состояние reaper сбрасывается при рестарте (это покрыто
стартовым `requeue_running_jobs`); любой **новый** маркер владения/живости должен быть либо durable,
либо безопасно восстановимым после рестарта.
- **NFR-6** — Сквозной инвариант ORCH-065/109/110 сохранён: `reaper_max_running_s (5400) >
Σ(deploy-staging gate-work) + grace` (Tier-3 backstop). Любая правка grace/таймаутов не должна его
нарушить.
## 6. Допущения и ограничения
- Задача помечена `Bug`; ввиду архитектурной природы — **эскалация в полный цикл** (нужен ADR +
анализ тех-рисков архитектором: 06-adr / 07 / 08 / 10).
- Инстанс общий для всех проектов (общая БД/очередь) — фикс не должен вносить регрессию для
enduro-trails и не-self репо.
- Выбор конкретного механизма владения/живости — за архитектором; настоящий BRD фиксирует **требования
и инварианты**, а не реализацию.
- Источник истины о «жив ли finalizer» сегодня отсутствует: pid агента в Tier-2 **уже мёртв** в обоих
случаях (`proc.wait()` вернулся), а живости **потока-монитора/финализатора** система не наблюдает —
это и есть пробел, который закрывает фикс.
## 7. Критерии успеха
Reaper при живом finalizer'е `deploy-staging` не запускает второй прогон edge-гейтов и не откатывает
задачу; повторная обработка идемпотентна; мёртвый finalizer по-прежнему добивается; после фикса нет
ложного rollback/developer-retry и расхождения состояния; инварианты ORCH-065/NFR-2 целы; полный
регресс `tests/` зелёный. Детальные PASS/FAIL — `03-acceptance-criteria.md`.
## 8. Риски
- **Гонка/расхождение состояния** (наблюдалось): повторный откат после успешного deploy. **Высокий.**
- **Над-толерантность**: слишком «доверять живости» → реально мёртвый finalizer не добивается (регресс
ORCH-065). Сдерживается BR-4 + Tier-3 backstop.
- **Нарушение сквозного бюджета** при правке grace/таймаутов (NFR-6).
Детальная проработка и контрмеры — `10-tech-risks.md` (заполняет архитектор).

View File

@@ -0,0 +1,106 @@
---
work_item: ORCH-113
stage: analysis
author_agent: analyst
status: ready-for-review
created_at: 2026-06-15
model_used: claude-opus-4-8
escalate: full-cycle
---
# 02 — ТЗ (TRZ): ORCH-113 — BUG: job-reaper не должен повторно запускать финализацию `deploy-staging`, пока жив исходный finalizer
Work Item: **ORCH-113** · Repo: **orchestrator** · Стадия: analysis
> ТЗ описывает **требования к изменению**, выведенные из BRD и фактического кода. Конкретный
> механизм (heartbeat живости / sub-state `finalizing` / per-stage grace / ownership-lease на
> edge-гейты), точные имена символов/колонок/флагов и порядок врезок — **архитектурное решение**
> (06-adr), не зона аналитика. Модули-плейсхолдеры ниже выровнены под манифест `PIPELINE_DOCS.md`.
## 1. Сводка изменения
Сделать повторную обработку reaper'ом завершившегося-но-ещё-`running` job на стадии `deploy-staging`
**идемпотентной и владеющей состоянием**: пока исходный monitor/finalizer **жив** (или edge-гейты для
пары `(job, stage)` уже исполняются), reaper **не должен** независимо запускать второй прогон edge-
под-гейтов ребра `deploy-staging → deploy` (security / merge-gate / локальный re-test / coverage /
image-freshness) и **не должен** на этом основании откатывать задачу. Корень — ошибочное допущение
Tier-2 finalization-grace (`reaper_finalize_grace_s=300`), что финализация после штампа `finished_at`
длится «секунды…десятки секунд»; для `deploy-staging` она длится **минуты** (полный re-test + coverage
+ rebuild), потому что `_try_advance_stage` (тяжёлые edge-гейты) выполняется **после** штампа
`finished_at` и **до** `_finalize_job`. Фикс должен дать reaper'у способ отличить «живой, долго
финализирующий монитор» от «мёртвого монитора» и обеспечить строгое владение исполнением edge-гейтов.
## 2. Задействованные модули / пути
| Путь | Действие |
|------|----------|
| `src/job_reaper.py` | изменить — Tier-2-ветка `_reap_job` (строки ~197-209), `_reap_known_outcome` / `_reap_exit0` / `_gate_driven_advance`: ввести проверку живости/владения перед side-effectful re-drive `advance_stage` для `deploy-staging`; при живом finalizer'е**defer**, не reap |
| `src/agents/launcher.py` | изменить (вероятно) — `_monitor_agent`: место/порядок штампа `finished_at` (строка ~861) относительно `_try_advance_stage` (строка ~998) и/или эмиссия durable-сигнала «finalizer жив/финализирует» перед запуском тяжёлых edge-гейтов |
| `src/db.py` | изменить (вероятно) — `get_running_jobs` (строки ~1337-1367, источник `finished_age_s`) и/или аддитивная колонка владения/живости (`_ensure_column`, паттерн `tasks.cancelled_at`); `reap_running_job` — без изменения контракта атомарного флипа |
| `src/config.py` | изменить (вероятно) — kill-switch фикса и/или per-stage/finalize-aware grace; сохранить сквозной инвариант `reaper_max_running_s > Σ gate-work + grace` (NFR-6) |
| `src/stage_engine.py` | **только чтение/ссылка**`advance_stage` ребро `deploy-staging` (строки ~321-383): эталон того, какие edge-гейты дублируются. Изменение нежелательно; идемпотентность предпочтительно решать на стороне reaper/launcher |
> Точный набор затронутых модулей и распределение логики (reaper-only vs launcher-сигнал vs db-колонка)
> архитектор фиксирует в 06-adr. Аналитик фиксирует, что центр тяжести правки — `src/job_reaper.py`.
## 3. Функциональные требования
### FR-1 — Распознавание живости финализирующего монитора (BR-1, BR-3)
Reaper в Tier-2 для стадии `deploy-staging` должен распознавать ситуацию «процесс агента завершён,
но monitor/finalizer ещё **жив** и исполняет edge-гейты» и **не** трактовать её как мёртвый монитор по
одному лишь `finished_age_s >= reaper_finalize_grace_s`. Сигнал живости должен переживать долгую
(минуты) финализацию `deploy-staging`. **Инвариант:** живой finalizer **никогда** не reap'ается.
### FR-2 — Идемпотентность и строгое владение edge-гейтами (BR-2)
Для пары `(job, stage)` на `deploy-staging` тяжёлый прогон edge-гейтов (security / merge-gate /
локальный re-test / coverage / image-freshness) исполняется **не более одного раза одновременно**:
актор, не владеющий состоянием, **не** запускает второй `advance_stage`/re-test/merge-gate. Текущий
атомарный claim-before-act (`reap_running_job ... WHERE status='running'`) защищает только флип строки
job — требование расширяет защиту на **side-effectful исполнение edge-гейтов**.
### FR-3 — Согласование grace/бюджета (BR-3, NFR-6)
Длительность finalization-grace (или заменяющий её сигнал живости) должна покрывать фактический
wall-clock финализации `deploy-staging` = Σ(security + merge re-test `merge_retest_timeout_s=900` +
coverage + image rebuild). Любая правка grace/таймаутов сохраняет сквозной инвариант ORCH-065/109/110:
`reaper_max_running_s (5400) > Σ(deploy-staging gate-work) + grace`.
### FR-4 — Сохранение добивания мёртвого finalizer'а (BR-4)
Реально **мёртвый** monitor/finalizer на `deploy-staging` (краш посреди финализации, сигнал живости
отсутствует/протух) по-прежнему добивается reaper'ом за ограниченное время по существующему контракту
(retry в пределах бюджета, иначе `failed` + Telegram; Tier-3 backstop как крайний предохранитель).
Reaper не становится no-op для `deploy-staging`.
### FR-5 — Отсутствие расхождения состояния (BR-5)
Исключить одновременный ложный откат `deploy-staging → development` и успешное завершение
`deploy → done` для одной задачи. После согласования у задачи — единственное консистентное
терминальное/стадийное состояние; ложный developer-retry не инкрементируется. Под-гейт merge-verify
(`deploy → done`, ORCH-071) остаётся единственным choke-point'ом в `done` — он **не** ослабляется.
## 4. Изменения API
Новых публичных эндпоинтов **не требуется**. Допустима **аддитивная read-only** наблюдаемость в
`GET /queue` (например, отметка «deploy-staging finalize in-progress / deferred-by-liveness» в блоке
`reaper`) — без изменения существующих ключей ответа.
## 5. Изменения схемы БД
Возможна **аддитивная** колонка владения/живости finalizer'а (например, durable-таймштамп
«finalizing heartbeat» или owner-токен на job/agent_run), вводимая идемпотентно через `_ensure_column`
(паттерн `tasks.cancelled_at` / `tasks.track`). Существующие таблицы/колонки/индексы и их семантика —
**без изменений**. Точная необходимость и форма — за архитектором (06-adr / 08-data-requirements).
## 6. Требования к новым/изменённым QG checks
**Нет.** `QG_CHECKS` и любой `check_*` (включая `check_staging_status`, `check_branch_mergeable`,
`check_coverage_gate`, `check_security_gate`, `check_staging_image_fresh`, `check_deploy_status`) — не
трогаются ни по составу, ни по семантике, ни по machine-verdict ключам. Багфикс — свойство страховочного
демона/финализатора, **не** Quality Gate.
## 7. Совместимость / регресс
- **Kill-switch:** фикс под выделенным флагом; `False` → строго прежнее поведение reaper (нулевая
регрессия).
- **Область:** поведение для **не-`deploy-staging`** стадий и путь добивания мёртвого монитора —
сохранены; self-hosting-only/скоуп репо согласовать с существующими leaf-паттернами (если вводится
per-repo разрез).
- **Обратимость:** раскат обратим выключением флага (+ откатом значений grace/таймаутов к дефолтам).
- **Never-raise / restart-safe / self-hosting (NFR-1/3/5):** любой сбой нового пути живости/владения
деградирует безопасно (reaper-тик продолжается); новый durable-маркер восстановим после рестарта;
фикс не рестартит прод и не пушит `main`.
- **Сквозной инвариант (NFR-6):** `reaper_max_running_s > Σ gate-work + grace` сохранён.
- **Анти-регресс:** структурный тест-гард (см. `04-test-plan.yaml`), полный `tests/` остаётся зелёным.

View File

@@ -0,0 +1,98 @@
---
work_item: ORCH-113
stage: analysis
author_agent: analyst
status: ready-for-review
created_at: 2026-06-15
model_used: claude-opus-4-8
escalate: full-cycle
---
# 03 — Критерии приёмки (Acceptance Criteria): ORCH-113 — BUG: job-reaper не должен повторно запускать финализацию `deploy-staging`, пока жив исходный finalizer
Work Item: **ORCH-113** · Repo: **orchestrator** · Стадия: analysis
Формат: каждый критерий имеет **PASS** (что должно быть истинно для приёмки) и **FAIL** (что считается
провалом). Любой машинный/ручной reviewer проверяет их буквально по файлам репозитория и тестам.
---
## AC-1 — Нет второго прогона edge-гейтов при живом finalizer'е
**Условие:** job на `deploy-staging` с `exit_code=0`, `finished_age_s >= reaper_finalize_grace_s`, но
исходный monitor/finalizer ещё **жив** (сигнал живости присутствует).
- **PASS:** reaper **не** вызывает `_gate_driven_advance`/`advance_stage` для этого job; второй прогон
security / merge-gate / локального re-test / coverage / image-freshness **не** запускается; reaper
логирует defer.
- **FAIL:** reaper запускает повторный `advance_stage` / любой edge-под-гейт, пока finalizer жив.
---
## AC-2 — Идемпотентность и строгое владение состоянием
**Условие:** монитор финализирует `deploy-staging` и параллельно срабатывает reaper-тик для того же
job/stage.
- **PASS:** тяжёлый прогон edge-гейтов (merge-gate / локальный re-test) исполняется **ровно один раз**
для пары `(job, stage)`; актор без владения состоянием не выполняет побочных шагов (мерж/re-test/
rollback).
- **FAIL:** второй локальный re-test/merge-gate запускается для того же job/stage без владения
состоянием (двойное исполнение edge-гейтов).
---
## AC-3 — Мёртвый finalizer по-прежнему добивается
**Условие:** monitor/finalizer на `deploy-staging` реально **умер** посреди финализации (сигнал
живости отсутствует/протух), job завис в `running`.
- **PASS:** reaper за ограниченное время добивает job по существующему контракту (retry в пределах
бюджета, иначе `failed` + Telegram; Tier-3 backstop как предохранитель); reaper для `deploy-staging`
**не** превращён в no-op.
- **FAIL:** мёртвый finalizer на `deploy-staging` не добивается reaper'ом (зомби-job блокирует очередь).
---
## AC-4 — Нет ложного отката и расхождения состояния после успешного deploy
**Условие:** сценарий инцидента ORCH-111 — долгая (> grace) финализация `deploy-staging` при зелёном
`staging_status: SUCCESS`, deploy/finalizer параллельно доходит до `deploy_status: SUCCESS` / merge PR.
- **PASS:** задача **не** откатывается `deploy-staging → development` параллельной reaper-веткой;
developer-retry **не** инкрементируется ложно; у задачи единственное консистентное
терминальное/стадийное состояние (сходимость, не расхождение).
- **FAIL:** задача откатана `deploy-staging → development` и/или начислен ложный developer-retry, в то
время как deploy фактически успешен; ветки состояния расходятся.
---
## AC-5 — Инварианты и контракт reaper сохранены
**Условие:** аудит диффа и поведения при выключенном kill-switch.
- **PASS:** `STAGE_TRANSITIONS` / `QG_CHECKS` / каждый `check_*` / machine-verdict ключи / схема
существующих таблиц — **байт-в-байт**; БД-правки только аддитивные (`_ensure_column` /
`CREATE TABLE IF NOT EXISTS`); reaper остаётся never-raise per unit; выключенный флаг → прежнее
поведение; правки не рестартят прод и не пушат `main`; сквозной инвариант
`reaper_max_running_s > Σ gate-work + grace` (ORCH-065/109/110) сохранён.
- **FAIL:** изменены `STAGE_TRANSITIONS`/`QG_CHECKS`/семантика `check_*`/machine-verdict ключи или
схема существующих таблиц; reaper может бросить исключение из тика; флаг `False` меняет поведение;
нарушен сквозной бюджетный инвариант.
---
## AC-6 — Обязательный регресс-тест и зелёный полный прогон
**Условие:** запуск тест-сюита репозитория.
- **PASS:** добавлен регресс-тест инцидента ORCH-111 (TC-05 в `04-test-plan.yaml`), **красный** на
коде до фикса и **зелёный** после; полный `pytest tests/ -q` зелёный.
- **FAIL:** регресс-теста нет, либо он зелёный и до фикса (не воспроизводит баг), либо полный регресс
`tests/` красный.
---
## Сводная матрица AC ↔ FR/BR
| AC | Покрывает |
|----|-----------|
| AC-1 | BR-1 / BR-3 / FR-1 |
| AC-2 | BR-2 / FR-2 |
| AC-3 | BR-4 / FR-4 |
| AC-4 | BR-5 / FR-5 |
| AC-5 | NFR-1 / NFR-2 / NFR-3 / NFR-6 / FR-3 |
| AC-6 | BR-1…BR-5 (регресс-доказательство) |

View File

@@ -0,0 +1,76 @@
work_item: ORCH-113
stage: analysis
author_agent: analyst
status: ready-for-review
created_at: 2026-06-15
model_used: claude-opus-4-8
escalate: full-cycle
title: "job-reaper не повторяет финализацию deploy-staging при живом finalizer'е: живость + идемпотентность + строгое владение"
framework: pytest
scope: >
Покрывает: распознавание живого финализирующего монитора в Tier-2 reaper на стадии deploy-staging
(не reap по одному finished_age_s); идемпотентность и строгое владение исполнением edge-гейтов
(не более одного локального re-test/merge-gate на (job, stage)); сохранение добивания РЕАЛЬНО
мёртвого finalizer'а; отсутствие ложного отката deploy-staging -> development и расхождения состояния
после успешного deploy; сохранение инвариантов (STAGE_TRANSITIONS/QG_CHECKS/check_*/machine-verdict/
схема существующих таблиц байт-в-байт; never-raise; kill-switch; сквозной бюджет ORCH-065/109/110).
Вне покрытия: инфра-толерантность merge-gate к таймауту re-test и tree-kill осиротевших процессов
(ORCH-110); починка конкретных мигающих тестов; поведение enduro/не-self репо (только проверяется
отсутствие регрессии / no-op).
notes: >
TC-05 — ОБЯЗАТЕЛЬНЫЙ регресс-тест инцидента ORCH-111 (deployer job 1914 / run_id 683): КРАСНЫЙ на
коде до фикса (reaper при живом долгом finalizer'е deploy-staging независимо запускает второй прогон
edge-гейтов и откатывает задачу), ЗЕЛЁНЫЙ после фикса. Подпроцессы (pytest re-test / coverage /
docker), сеть, Plane и Gitea — мокаются; «живой/мёртвый finalizer» и «долгая финализация > grace»
моделируются управляемо, без обращения наружу. Полный регресс tests/ должен оставаться зелёным.
Точные имена символов/колонок/флагов уточняет архитектор (06-adr); модули-плейсхолдеры выровнены под
манифест PIPELINE_DOCS.
tests:
- id: TC-01
type: unit
description: "Tier-2 reaper на deploy-staging: exit_code=0 и finished_age_s >= grace, но finalizer ЖИВ (сигнал живости присутствует) -> reaper НЕ вызывает _gate_driven_advance/advance_stage; второй прогон edge-гейтов не запускается; логируется defer (AC-1/FR-1)."
module: tests/test_orch113_reaper_finalizer_liveness.py
expected: PASS
- id: TC-02
type: unit
description: "Строгое владение: при попытке повторной обработки того же (job, stage) актор без владения состоянием НЕ исполняет merge-gate/локальный re-test/advance (claim/ownership проигран -> ноль побочных эффектов), AC-2/FR-2."
module: tests/test_orch113_reaper_finalizer_liveness.py
expected: PASS
- id: TC-03
type: unit
description: "Мёртвый finalizer на deploy-staging (сигнал живости отсутствует/протух) -> reaper по-прежнему добивает job за ограниченное время по существующему контракту (retry в пределах бюджета, иначе failed+Telegram; Tier-3 backstop срабатывает) — reaper не no-op для deploy-staging (AC-3/FR-4)."
module: tests/test_orch113_reaper_finalizer_liveness.py
expected: PASS
- id: TC-04
type: integration
description: "Идемпотентность под гонкой: монитор финализирует deploy-staging и параллельно срабатывает reaper-тик -> тяжёлый прогон edge-гейтов (merge-gate/re-test) исполняется РОВНО ОДИН раз для (job, stage); нет второго re-test и нет ложного rollback (AC-2/AC-4/FR-2/FR-5)."
module: tests/test_orch113_reaper_finalizer_liveness.py
expected: PASS
- id: TC-05
type: integration
description: "ОБЯЗАТЕЛЬНЫЙ регресс ORCH-111: долгая (> grace) финализация deploy-staging при staging_status=SUCCESS, deploy/finalizer параллельно доходит до успеха/merge PR -> reaper НЕ откатывает deploy-staging -> development и НЕ инкрементирует developer-retry; у задачи единственное консистентное состояние. КРАСНЫЙ до фикса, ЗЕЛЁНЫЙ после (AC-4/FR-5)."
module: tests/test_orch113_reaper_finalizer_liveness.py
expected: PASS
- id: TC-06
type: unit
description: "Регресс-гард совместимости: kill-switch выключен ИЛИ стадия не deploy-staging -> поведение reaper байт-в-байт прежнее (Tier-2 grace, claim-before-act, dead-pid/Tier-3 пути неизменны), NFR-4/AC-5."
module: tests/test_orch113_reaper_finalizer_liveness.py
expected: PASS
- id: TC-07
type: unit
description: "Сквозной инвариант бюджета (ORCH-065/109/110): при дефолтном конфиге reaper_max_running_s (5400) > Σ(deploy-staging gate-work) + grace; любая правка grace/таймаутов фикса инвариант не нарушает (NFR-6/AC-5)."
module: tests/test_orch113_reaper_finalizer_liveness.py
expected: PASS
- id: TC-08
type: unit
description: "never-raise: сбой/исключение в новом пути распознавания живости/владения деградирует безопасно — reaper-тик не падает, прочие job обрабатываются, прод не трогается, main не пушится (NFR-1/NFR-3/AC-5)."
module: tests/test_orch113_reaper_finalizer_liveness.py
expected: PASS

View File

@@ -0,0 +1,158 @@
---
work_item: ORCH-113
stage: architecture
author_agent: architect
status: proposed
created_at: 2026-06-15
model_used: claude-opus-4-8
---
# ADR-001: Reaper Tier-2 — in-memory ownership-маркер финализации `deploy-staging` (живой finalizer не реапится)
Work Item: **ORCH-113** — BUG: job-reaper повторно запускает финализацию `deploy-staging`, пока жив исходный finalizer
Стадия: **architecture**
Сквозная регистрация: **`docs/architecture/adr/adr-0043-reaper-finalizer-liveness-ownership.md`** (решение кросс-каттинговое — уточняет контракт reaper ORCH-065/adr-0011).
## Статус
Proposed
## Контекст
Оркестратор self-hosting: один инстанс, общая БД/очередь, `max_concurrency=1`. Финальный статус job
(`done`/`queued`/`failed`/`cancelled`) пишется **только** в живом процессе
(`launcher._monitor_agent → _finalize_job`). Сверено по коду:
- `_monitor_agent` штампит `agent_runs.finished_at`/`exit_code` **ПЕРВЫМ** (`launcher.py:861`), затем
делает git commit/push (+PR), usage-комментарии Plane (секунды…десятки секунд), затем
`_try_advance_stage` (`launcher.py:998`) и лишь потом `_finalize_job` (`launcher.py:1003`).
- На ребре `deploy-staging → deploy` `_try_advance_stage → advance_stage` синхронно, **в потоке
монитора**, прогоняет тяжёлый набор edge-под-гейтов (`stage_engine.py:327368`):
`security``merge-gate` (полный локальный re-test, бюджет `merge_retest_timeout_s=900`) →
`coverage` (`pytest --cov`) → `image-freshness` (docker-rebuild + пересоздание staging) — это
**минуты**, и весь объём идёт **после** штампа `finished_at` и **до** `_finalize_job`.
- Reaper Tier-2 (`job_reaper._reap_job`, `job_reaper.py:197209`) меряет `finished_age_s` от
`agent_runs.finished_at` (`db.get_running_jobs`, `db.py:1360`) = **от начала** финализации. По
истечении `reaper_finalize_grace_s=300` он трактует живого, долго финализирующего монитора как
мёртвого и независимо запускает тот же тяжёлый advance (`_reap_exit0 → _gate_driven_advance →
_try_advance_stage → advance_stage`).
Дешёвая read-only пред-проверка `_gate_is_green('deploy-staging')` читает лишь `check_staging_status`
(frontmatter `15-staging-log.md` = `SUCCESS`) → reaper уверенно идёт в тяжёлый advance. Атомарный
claim-before-act (`reap_running_job ... WHERE status='running'`) защищает **флип строки** job, но **не
side-effectful исполнение edge-гейтов**: монитор не claim'ит строку перед `advance_stage`, поэтому
монитор и reaper выполняют `advance_stage` **параллельно**.
**Инцидент ORCH-111 (deployer job 1914, run_id 683):** финализация `deploy-staging` заняла >300с;
reaper повторил edge-гейты; один повторный re-test стал красным (`3 failed … 14 errors in 444.79s`);
задача ложно откатана `deploy-staging → development` (+ ложный developer-retry), **параллельно**
исходный finalizer довёл deploy до `SUCCESS` и смержил PR #130 (`deploy → done`). Состояние раздвоилось.
Источника истины «жив ли finalizer» сегодня нет: pid агента в Tier-2 уже мёртв в **обоих** случаях
(`proc.wait()` вернулся), а живость **потока-монитора** система не наблюдает. Per-stage grace,
покрывающая Σ финализации (`Σ ≈ 4160с`), невозможна без нарушения сквозного бюджета ORCH-065/109/110
`reaper_max_running_s (5400) > Σ(deploy-staging gate-work) + grace (≈4460)`.
**Решающий факт (проверен):** монитор и reaper — daemon-**потоки одного** uvicorn-процесса (CMD без
`--workers`; `_monitor_agent` стартует `threading.Thread`, `launcher.py:661`; reaper — daemon-поток,
`main.py:144`), разделяющие одну SQLite-БД. Значит, живость finalizer'а можно определить **in-memory**.
Рестарт покрыт существующим `requeue_running_jobs()` (`running → queued`), который в `main.lifespan`
вызывается (`main.py:59`) **до** старта reaper (`main.py:144`).
## Решение
### Сводка
Ввести **процесс-локальный реестр владения финализацией**: живой монитор регистрирует «я финализирую
job X», а reaper в Tier-2 на стадии `deploy-staging` **не реапит** job, чьё владение активно, и
переходит к Tier-3 backstop. Реестр in-memory — авторитетен в рамках одного процесса/БД; рестарт
покрыт `requeue_running_jobs`. Grace и `reaper_max_running_s` не меняются → сквозной бюджет цел. Под
глобальным kill-switch; **нулевое** изменение схемы БД и контрактов.
### D1 — Leaf `src/finalizer_liveness.py` (владение, FR-2)
Новый чистый процесс-локальный модуль (паттерн `serial_gate`/`coverage_gate`: never-raise, без сети/БД):
- `mark(job_id, run_id, stage)` — зарегистрировать активную финализацию;
- `clear(job_id)` — снять;
- `is_active(job_id) -> bool` — есть ли живое владение;
- `snapshot() -> dict` — read-only для наблюдаемости.
Состояние — `{job_id: {"run_id", "stage", "started_ts"}}` + `threading.Lock`. Собственного TTL нет —
ограничение по времени даёт Tier-3 (см. D3). Все функции изолированы `try/except` → дефолт
(`is_active` при ошибке → `False`, консервативно: не блокировать добивание).
### D2 — Эмиссия владения в `launcher._monitor_agent` (FR-1)
`mark(job_id, run_id, stage)` вызывается **сразу после** штампа `exit_code` (`launcher.py:864`, самый
ранний момент, когда reaper переходит в Tier-2; до этого pid агента жив → Tier-1 защищает). Хвост
финализации (git push … `_try_advance_stage``_finalize_job`) оборачивается в `try/finally`, в
`finally``clear(job_id)`. Так исключение **в потоке монитора** гарантированно снимает владение →
reaper добивает (FR-4). Только при `job_id is not None` (legacy `launch()` с `job_id=None` не в
`get_running_jobs`). Гибель **всего процесса** → рестарт → `requeue_running_jobs` → реестр пуст
(restart-safe без durable, NFR-5).
### D3 — Консультация reaper, scoped + Tier-3 backstop (FR-3, FR-4)
В `job_reaper._reap_job`, Tier-2-ветка (`exit_code` записан, `finished_age >= grace`): **перед**
`_reap_known_outcome` — если `settings.reaper_finalizer_liveness_enabled` **И** стадия задачи
(`_task_meta`) `== "deploy-staging"` **И** `finalizer_liveness.is_active(job_id)`**defer** (лог +
счётчик), **не** реапить через Tier-2, провалиться к Tier-3. Иначе — прежний путь
(`_reap_known_outcome; return`), байт-в-байт. **Tier-3** (`age >= reaper_max_running_s`) маркер
**игнорирует** — добивает всегда (ограниченное время; бюджет `5400 > Σ+grace ≈ 4460` гарантирует, что
легитимная финализация завершится до 5400 → ложного Tier-3-реапа живого finalizer'а нет).
### D4 — Скоуп и kill-switch (NFR-4)
Только глобальный `reaper_finalizer_liveness_enabled` (`config.py`, env
`ORCH_REAPER_FINALIZER_LIVENESS_ENABLED`, дефолт `True`). **Без** per-repo разреза: баг общий для
любого репо со стадией `deploy-staging` (enduro тоже); per-repo оставил бы баг активным для части
репо. Это сознательный отход от leaf-паттерна `*_repos` (он для **гейтов, действующих на репо**; здесь
— наблюдатель-безопасность глобального демона). `False` → reaper никогда не консультирует маркер →
поведение байт-в-байт прежнее; стадии `!= deploy-staging` не консультируются → не тронуты.
### D5 — Наблюдаемость (TZ §4)
Счётчик `finalizer_defers_total` + размер `finalizer_liveness.snapshot()` в блоке `reaper`
`GET /queue`. Существующие ключи ответа не меняются; новых эндпоинтов нет.
### Инварианты
`STAGE_TRANSITIONS` / `QG_CHECKS` / каждый `check_*` / machine-verdict ключи / схема существующих
таблиц — **байт-в-байт**; **нулевое** изменение схемы БД; reaper остаётся never-raise per-unit;
`reaper_finalize_grace_s` и `reaper_max_running_s` **не меняются** (NFR-6 цел); фикс не рестартит прод
и не пушит `main` (NFR-3). Merge-verify (`deploy → done`, ORCH-071) — единственный choke-point в
`done`, не ослабляется (FR-5).
## Альтернативы
- **Per-stage grace, покрывающая Σ** — отвергнуто: нарушает бюджет `5400 > Σ+grace` (Σ≈4160 ⇒ grace
пришлось бы <1240, не покрывает Σ); таймер — это и есть источник бага.
- **Durable-колонка (finalizing-heartbeat / owner-токен)** — отвергнуто: один процесс/одна БД →
in-memory авторитетно; рестарт покрыт requeue; блокирующий re-test (900с) не может бить периодический
heartbeat из того же потока; durable добавляет миграцию и запись ради нулевой выгоды.
- **Sub-state `finalizing` в `jobs.status`** — отвергнуто: меняет семантику статуса, который читают
`claim_next_job`/`requeue_running_jobs`/`reconciler`/`reaper` (`WHERE status='running'`) — нарушение
NFR-2 и высокий радиус поражения.
- **Lease-файл на `(job, stage)` (как merge-lease)** — отвергнуто: тяжелее (файловый I/O, TTL,
reclaim), дублирует merge-lease; in-memory достаточно при одном процессе; TTL возвращает таймер-проблему.
- **Флип job из `running` до тяжёлых гейтов** — отвергнуто: ломает `get_running_jobs`/метрики и
restart-requeue (краш мид-гейт оставит job non-running и нереквью'имым).
## Последствия
- **+** Устранены повторный прогон edge-гейтов, ложный откат `deploy-staging → development` и
расхождение состояния при живом долгом finalizer'е; идемпотентность edge-гейтов через владение
(AC-1/AC-2/AC-4).
- **+** Реально мёртвый/застрявший finalizer добивается (finally-clear → Tier-2; иначе Tier-3);
основная функция reaper ORCH-065 сохранена (AC-3).
- **+** Нулевое изменение схемы и контрактов; сквозной бюджет ORCH-065/109/110 не тронут (AC-5).
- **** Гарантия владения валидна при **одном процессе/одной БД** (проверено: один uvicorn-воркер);
ввод `--workers>1` потребует durable-сигнала — зафиксировано в `10-tech-risks.md` (TR-3).
- **** Окно «штамп `finished_at``mark()`» (git push) маркером не покрыто — закрыто прежним
grace=300 (окно ≪ grace), TR-2.
- **Откат:** `ORCH_REAPER_FINALIZER_LIVENESS_ENABLED=false` → reaper байт-в-байт прежний (маркер
по-прежнему пишется монитором, но не консультируется — инертен). Полный откат — удаление leaf +
двух врезок.
## Ссылки
- BRD: `docs/work-items/ORCH-113/01-brd.md`
- TRZ: `docs/work-items/ORCH-113/02-trz.md`
- Acceptance: `docs/work-items/ORCH-113/03-acceptance-criteria.md`
- Test-plan: `docs/work-items/ORCH-113/04-test-plan.yaml`
- Сквозной ADR: `docs/architecture/adr/adr-0043-reaper-finalizer-liveness-ownership.md`
- Базовые ADR: `adr-0011` (reaper/lease ORCH-065), `adr-0040` (timeout-бюджеты ORCH-109),
`adr-0042` (merge-gate re-test ORCH-110)
- Сверено по коду: `src/job_reaper.py`, `src/agents/launcher.py` (`_monitor_agent`/`_try_advance_stage`),
`src/db.py` (`get_running_jobs`/`requeue_running_jobs`), `src/stage_engine.py` (`advance_stage` ребро
`deploy-staging`), `src/config.py` (`reaper_*`), `src/main.py` (`lifespan`)
</content>

View File

@@ -0,0 +1,40 @@
---
work_item: ORCH-113
stage: architecture
author_agent: architect
status: proposed
created_at: 2026-06-15
model_used: claude-opus-4-8
---
# 07 — Инфра-требования: ORCH-113 — reaper finalizer-liveness ownership
Work Item: **ORCH-113** · Repo: **orchestrator** · Стадия: architecture
> When-applicable / информационный. Топология **не меняется**; ниже — только конфиг и операционные
> инварианты, которые сопровождающий обязан удержать.
## Изменения топологии
**N/A.** Ни новых сервисов/контейнеров, ни портов, ни томов, ни сетевых правил. Решение целиком внутри
процесса `orchestrator` (новый leaf + две врезки в существующие потоки monitor/reaper).
## Новый конфиг (env)
| Ключ | Дефолт | Назначение |
|------|--------|-----------|
| `ORCH_REAPER_FINALIZER_LIVENESS_ENABLED` | `true` | Kill-switch. `false` → reaper байт-в-байт прежний (маркер пишется, но не консультируется). Откат фикса = установить `false`. |
Существующие `reaper_finalize_grace_s` (300) и `reaper_max_running_s` (5400) — **не меняются**.
`.env.example` пополнить новым ключом (дефолт = боевое значение, паттерн ORCH-101: пустой `.env`
прежнее поведение).
## Операционные инварианты (сопровождение)
- **Одно-процессная модель — несущий инвариант.** Авторитетность in-memory реестра владения держится
на том, что монитор и reaper — потоки **одного** uvicorn-процесса. CMD/команда compose **не должны**
получать `uvicorn --workers>1` без перевода сигнала в durable (см. `10-tech-risks.md` TR-3, ADR-001).
Сверено: `Dockerfile:65`, `docker-compose.yml:36` (prod), `docker-compose.yml:123` (staging) — без
`--workers`.
- **Сквозной бюджет ORCH-065/109/110** `reaper_max_running_s (5400) > Σ(deploy-staging gate-work)+grace
(≈4460)` остаётся в силе и фиксом не затрагивается (TR-4).
- **Self-hosting-страховка:** обкатка — на staging (8501, изолированная БД) до прод-деплоя; деплой
орка — только через статус «Confirm Deploy». Фикс не рестартит прод и не пушит `main`.
</content>

View File

@@ -0,0 +1,43 @@
---
work_item: ORCH-113
stage: architecture
author_agent: architect
status: proposed
created_at: 2026-06-15
model_used: claude-opus-4-8
---
# 08 — Требования к данным: ORCH-113 — reaper finalizer-liveness ownership
Work Item: **ORCH-113** · Repo: **orchestrator** · Стадия: architecture
> When-applicable / информационный (гейтом не парсится).
## Изменения схемы БД
**N/A — нулевое изменение схемы.** Сознательное архитектурное решение (ADR-001 / adr-0043): сигнал
владения финализацией — **in-memory** (leaf `src/finalizer_liveness.py`), а не durable-колонка. Ни
новых таблиц, ни новых колонок, ни индексов; `init_db()` / `_ensure_column` не трогаются. Схема
существующих таблиц (`jobs`, `agent_runs`, `tasks`, …) и их семантика — **байт-в-байт** (NFR-2/AC-5).
## Новые/изменённые сущности
**Процесс-локальный реестр владения** (не БД): `finalizer_liveness` хранит
`{job_id: {"run_id", "stage", "started_ts"}}` под `threading.Lock`. Запись/снятие — живой
монитор-поток (`launcher._monitor_agent`); чтение — reaper-поток (`job_reaper`). Ключ — `jobs.id`
(существующая сущность). Никаких новых персистентных данных.
## Совместимость данных / миграции
- **Миграций нет** — нечего мигрировать (нет схемных изменений); общая прод-БД (self-hosting +
enduro-trails) не затрагивается.
- **Restart-safe без durable (NFR-5):** in-memory реестр сбрасывается при рестарте процесса, что
**безопасно** по существующему контракту: `main.lifespan` вызывает `requeue_running_jobs()`
(`running → queued`, `main.py:59`) **до** старта reaper (`main.py:144`). После рестарта нет ни одного
`running`-job, ссылающегося на потерянный маркер → отсутствие маркера корректно (нет живых
finalizer'ов). Гибель **потока** монитора (не процесса) покрыта `try/finally`-снятием маркера; гибель
**процесса** → рестарт → requeue.
- **Авторитетность in-memory** опирается на одно-процессную модель (один uvicorn-воркер, общая
SQLite-БД; проверено: CMD без `--workers`). Условие задокументировано как инвариант сопровождения —
при вводе `--workers>1` сигнал должен стать durable (см. `10-tech-risks.md` TR-3).
</content>

View File

@@ -0,0 +1,37 @@
---
work_item: ORCH-113
stage: architecture
author_agent: architect
status: proposed
created_at: 2026-06-15
model_used: claude-opus-4-8
---
# 10 — Технические риски: ORCH-113 — reaper finalizer-liveness ownership
Work Item: **ORCH-113** · Repo: **orchestrator** · Стадия: architecture
> Информационный (гейтом не парсится). Риски реализации и их митигейшн.
## Реестр рисков
| ID | Риск | Вер. | Влия. | Митигейшн |
|----|------|------|-------|-----------|
| TR-1 | **Над-толерантность:** маркер «жив» застрял (не снят) → реально мёртвый finalizer не добивается, зомби клинит очередь (регресс ORCH-065). | Низ. | Выс. | `try/finally`-снятие в `_monitor_agent` (исключение потока снимает владение); гибель процесса → рестарт → `requeue_running_jobs`. **Tier-3 backstop игнорирует маркер** и добивает при `age >= reaper_max_running_s=5400` → ограниченное время гарантировано (FR-4/AC-3). Покрытие — TC-03. |
| TR-2 | **Окно без владения** между штампом `finished_at` (launcher:861) и `mark()` (после exit_code, launcher:864): reaper мог бы реапнуть в этом окне. | Низ. | Сред. | Окно = git push/PR/Plane-комментарии (секунды…десятки секунд) ≪ `reaper_finalize_grace_s=300` → прежний grace покрывает его; маркер ставится самым ранним возможным моментом Tier-2 (до этого pid агента жив → Tier-1 защищает). |
| TR-3 | **Многопроцессность:** при `uvicorn --workers>1` монитор и reaper окажутся в разных процессах → in-memory реестр не разделяется → возможна двойная финализация. | Низ. | Выс. | Сейчас CMD без `--workers` (проверено: `Dockerfile:65`, `docker-compose.yml:36`). Инвариант сопровождения зафиксирован в ADR-001/adr-0043 и 08-data-requirements: ввод `--workers>1` ⇒ перевести сигнал в durable (heartbeat-колонка) — отдельная задача. Анти-дрейф можно усилить структурным тестом (нет `--workers` в CMD). |
| TR-4 | **Нарушение сквозного бюджета** ORCH-065/109/110 при правке grace/таймаутов. | Оч. низ. | Выс. | Решение **не меняет** `reaper_finalize_grace_s` (300) и `reaper_max_running_s` (5400) — инвариант `5400 > Σ(deploy-staging gate-work)+grace ≈ 4460` тривиально цел; покрытие — TC-07/AC-5. |
| TR-5 | **Гонка чтения/записи** реестра (монитор пишет, reaper читает). | Низ. | Сред. | `threading.Lock` вокруг операций реестра; `is_active`/`snapshot` атомарны под локом; never-raise → ошибка чтения = `False` (консервативно, не блокирует добивание). Покрытие — TC-02/TC-04/TC-08. |
| TR-6 | **Регресс не-deploy-staging / выключенного флага** (NFR-4): фикс случайно меняет прежние пути reaper. | Низ. | Сред. | Консультация маркера gated `enabled AND stage=="deploy-staging"`; Tier-1/Tier-3/exit≠0/claim-before-act не трогаются; `False` → reaper байт-в-байт прежний. Покрытие — TC-06. |
| TR-7 | **Ложный regression-тест** TC-05: зелёный и до фикса (не воспроизводит баг). | Сред. | Сред. | TC-05 моделирует «живой долгий finalizer > grace» управляемо (моки подпроцессов/сети); обязан быть **красным до** фикса и **зелёным после** (AC-6). Reviewer/tester проверяют красноту на базе. |
## Сводный вывод
Доминирующий класс — **над-толерантность** (TR-1) и **многопроцессная авторитетность** (TR-3); оба
имеют низкую вероятность и закрыты соответственно Tier-3 backstop'ом (без правки бюджета) и
зафиксированным инвариантом одно-процессной модели. Решение аддитивно, под kill-switch, без изменения
схемы/контрактов и без правки сквозного бюджета. Эскалация `arch:major-change` **не требуется**
(нет новой стадии/QG, нет изменения схемы БД, центр тяжести — один leaf + две точечные врезки).
Остаточный риск для прод-конвейера (self-hosting) — **низкий**; полностью обратим выключением
`ORCH_REAPER_FINALIZER_LIVENESS_ENABLED`.
</content>

View File

@@ -0,0 +1,86 @@
---
verdict: APPROVED
work_item: ORCH-113
stage: review
author_agent: reviewer
status: approved
created_at: 2026-06-15
model_used: claude-opus-4-8
type: review
work_item_id: ORCH-113
version: 1
---
# Review ORCH-113 — BUG: job-reaper не должен повторно запускать финализацию `deploy-staging`, пока жив исходный finalizer
## Summary
Фикс инцидента ORCH-111 реализован чисто и полно. Введён процесс-локальный реестр владения
финализацией (`src/finalizer_liveness.py`, never-raise leaf по паттерну `serial_gate`/`coverage_gate`):
монитор `mark()`-ит владение сразу после штампа `exit_code` и `clear()`-ит его в `finally` хвоста
финализации; reaper в Tier-2 при `stage=="deploy-staging"` И активном владении делает **defer** вместо
повторного `advance_stage`, проваливаясь к Tier-3 backstop (который маркер игнорирует → застрявший
finalizer всё равно добивается).
Проверено по всем 4 осям; блокирующих findings нет.
- **ТЗ:** FR-1…FR-5 реализованы; AC-1…AC-6 покрыты тестами `tests/test_orch113_reaper_finalizer_liveness.py`
(TC-01…TC-08). Схема БД — **нулевое** изменение (выбран in-memory реестр), что строже допущенной ТЗ §5
«аддитивная колонка». API §4 (read-only ключи в `GET /queue`) и QG §6 (не трогать) — соблюдены.
- **ADR:** реализация байт-в-байт соответствует ADR-001 / сквозному adr-0043 (D1D5). Трассировка
сохранена: авторитет Tier-3 (adr-0011/ORCH-065) и сквозной бюджет `reaper_max_running_s (5400) >
Σ(gate-work)+grace` (ORCH-109/110) не нарушены — зафиксировано регресс-тестом TC-07. Ни один
маркированный инвариант не сломан.
- **Качество кода:** хвост `_monitor_agent` вынесен в `_run_monitor_finalization` **дословно**
подтверждено `git diff -w` (+49/0, нулевое изменение логики); все переменные, на которые ссылается
извлечённое тело, — параметры/локальные/модульные (нет риска `NameError`, проверено вручную).
never-raise во всех публичных функциях и врезках. Обязательный регресс-тест багфикс-трека (ORCH-019
BR-4 / coverage ORCH-027) присутствует: TC-05 по построению КРАСНЫЙ до фикса (assert `calls == []`,
который pre-fix reaper нарушил бы вызовом `_try_advance_stage`) и ЗЕЛЁНЫЙ после.
- **Документация:** обновлены в том же PR — `docs/architecture/README.md` (описание Job-reaper +
раздел Tier-2 + список kill-switch + ссылки на ADR), `docs/architecture/internals.md` (детализация
Tier-2), `CHANGELOG.md`, ADR-001 (work-item) и сквозной adr-0043; все номерные доки задачи (0004,
06-adr, 07, 08, 10) на месте.
**Проверка прогона:** `pytest tests/ -q`**2001 passed**, 0 failures (AC-6); целевой файл — 13 passed.
## Findings
### P0 — Blocker
-ет_
### P1 — Must fix
-ет_
### P2 — Should fix
-ет_
### P3 — Nice-to-have (не блокирует приёмку)
- [ ] Frontmatter обоих ADR (`ADR-001` и `adr-0043`) держит `status: proposed`. По мере мержа фикса
статус естественно становится принятым решением — стоит при следующем касании обновить на `accepted`
(косметика трассировки, не влияет на гейт).
- [ ] В врезке `mark()` (`launcher._monitor_agent`, стр. ~884) делается отдельный
`get_task_by_repo_branch(repo, branch)` ради `stage`-контекста, хотя тот же lookup повторяется ниже в
хвосте финализации (стр. ~984). Дублирование на пути, и так делающем БД-работу, обёрнуто never-raise;
`stage` здесь — best-effort контекст для `snapshot()` (reaper резолвит стадию независимо через
`_task_meta`), так что корректность не зависит от него. Можно при желании переиспользовать один lookup.
## Документация
**Статус: полностью обновлена в том же PR (golden source соблюдён).**
| Артефакт | Изменение | Оценка |
|----------|-----------|--------|
| `docs/architecture/README.md` | Job-reaper компонент + раздел Tier-2 + список kill-switch (`ORCH_REAPER_FINALIZER_LIVENESS_ENABLED`) + ссылки на adr-0043 | ✅ |
| `docs/architecture/internals.md` | Детализация Tier-2 deploy-staging defer | ✅ |
| `CHANGELOG.md` | Развёрнутая запись `[Unreleased]` с подпунктами (leaf / эмиссия / консультация / наблюдаемость) | ✅ |
| `docs/work-items/ORCH-113/06-adr/ADR-001-…` | Детальный ADR (D1D5, альтернативы, последствия) | ✅ |
| `docs/architecture/adr/adr-0043-…` | Сквозной ADR (уточняет adr-0011/0040/0042/0041) | ✅ |
| `docs/work-items/ORCH-113/{00..04,07,08,10}` | Полный пакет номерных доков | ✅ |
**Обзорные доки / витрина:** правка внутренняя для job-reaper; высокоуровневые описания в
`docs/overview/tech-architecture.md` («job-reaper возвращает в очередь job'ы, чей исполнитель умер») и
`README.md` остаются корректными — обновления не требуют (ORCH-079/ORCH-011 не задеты). Раздел README
«Известные ограничения» не содержит пункта, закрываемого этим PR (баг был инцидентом, не значился
ограничением) — обновление не требуется. Известное ограничение `--workers>1` (TR-3) — системное
пред-допущение, документировано в `10-tech-risks.md` и обоих ADR; вынос в README не обязателен.

View File

@@ -0,0 +1,66 @@
---
result: PASS # PASS | FAIL — машинный вердикт, UPPERCASE
work_item: ORCH-113
stage: testing
author_agent: tester
status: pass
created_at: 2026-06-15
model_used: claude-opus-4-8
type: test-report
work_item_id: ORCH-113
---
# Test Report — ORCH-113
BUG: job-reaper не должен повторно запускать финализацию `deploy-staging`, пока жив исходный finalizer.
## Окружение
- Worktree: `/repos/_wt/orchestrator/feature_ORCH-113-bug-job-reaper-must-not-re-run` (ветка `feature/ORCH-113-bug-job-reaper-must-not-re-run`)
- Python: 3.12.13
- pytest: 8.3.3 (plugins: cov-5.0.0, anyio-4.13.0, asyncio-0.23.8)
- Дата: 2026-06-15
- Review verdict (12-review.md): `APPROVED`
## Smoke API (read-only)
| Endpoint | Результат |
|----------|-----------|
| `GET /health` | `{"status":"ok","service":"orchestrator"}` — PASS |
| `GET /status` | Отвечает; ORCH-113 (task 101) виден на стадии `testing` — PASS |
| `GET /queue` | Блоки `serial_gate` (ORCH-088) **и** `auto_labels` (ORCH-089) присутствуют — PASS |
## Результаты — покрытие тест-плана (04-test-plan.yaml)
Все TC реализованы в `tests/test_orch113_reaper_finalizer_liveness.py` (13 тест-функций на 8 TC).
| TC ID | Описание | AC / FR | Тест-функция | Результат |
|-------|----------|---------|--------------|-----------|
| TC-01 | Живой finalizer на `deploy-staging` (exit=0, age≥grace) → reaper НЕ вызывает `_gate_driven_advance`/`advance_stage`, логирует defer | AC-1/FR-1 | `test_tc01_live_finalizer_deploy_staging_not_reaped` | PASS |
| TC-02 | Строгое владение: актор без владения НЕ исполняет merge-gate/re-test/advance (ноль побочных эффектов) | AC-2/FR-2 | `test_tc02_non_owner_runs_no_edge_gates` | PASS |
| TC-03 | Мёртвый finalizer → reaper по-прежнему добивает job (Tier-2 retry + Tier-3 backstop игнорирует маркер); reaper не no-op | AC-3/FR-4 | `test_tc03_dead_finalizer_still_reaped_tier2`, `test_tc03_tier3_backstop_ignores_marker` | PASS |
| TC-04 | Идемпотентность под гонкой: тяжёлый прогон edge-гейтов исполняется ровно один раз для `(job, stage)`, нет второго re-test/ложного rollback | AC-2/AC-4/FR-2/FR-5 | `test_tc04_idempotent_no_second_advance_under_race` | PASS |
| TC-05 | **ОБЯЗАТЕЛЬНЫЙ регресс ORCH-111:** долгая (>grace) финализация при `staging_status=SUCCESS` → нет отката `deploy-staging → development`, нет ложного developer-retry; единственное консистентное состояние (красный до фикса, зелёный после) | AC-4/FR-5 | `test_tc05_orch111_no_false_rollback_no_retry_increment` | PASS |
| TC-06 | Регресс-гард совместимости: kill-switch off ИЛИ не-`deploy-staging` → поведение reaper байт-в-байт прежнее | NFR-4/AC-5 | `test_tc06_killswitch_off_byte_for_byte_prior`, `test_tc06_non_deploy_staging_stage_not_consulted`, `test_tc06_within_grace_unchanged` | PASS |
| TC-07 | Сквозной инвариант бюджета: `reaper_max_running_s (5400) > Σ(deploy-staging gate-work) + grace` (ORCH-065/109/110) | NFR-6/AC-5 | `test_tc07_budget_invariant_preserved` | PASS |
| TC-08 | never-raise: сбой пути живости/владения деградирует безопасно — reaper-тик не падает, прочие job обрабатываются | NFR-1/NFR-3/AC-5 | `test_tc08_liveness_error_never_breaks_tick`, `test_tc08_reap_once_isolates_and_never_raises`, `test_tc08_finalizer_liveness_leaf_never_raises` | PASS |
**Сопоставление с 03-acceptance-criteria.md:** AC-1…AC-6 покрыты (AC-1→TC-01, AC-2→TC-02/TC-04, AC-3→TC-03, AC-4→TC-04/TC-05, AC-5→TC-06/TC-07/TC-08, AC-6→полный зелёный прогон + TC-05 как регресс-доказательство). Каждый TC из тест-плана выполнен и сопоставлен.
## Вывод pytest
Целевой файл:
```
tests/test_orch113_reaper_finalizer_liveness.py ... 13 passed, 1 warning in 3.60s
```
Полный регресс:
```
$ python -m pytest tests/ -q
........................................................................ [ 39%]
... (snip) ...
......................................................... [100%]
2001 passed, 1 warning in 316.72s (0:05:16)
```
(единственный warning — `PydanticDeprecatedSince20` в `src/config.py:8`, не относится к задаче, присутствует исторически)
## Итог
**PASS** — целевой файл 13/13 PASS, полный регресс `tests/` 2001 passed / 0 failed, smoke API (`/health`, `/status`, `/queue` с блоками `serial_gate` + `auto_labels`) зелёный, каждый TC тест-плана выполнен и сопоставлен с критериями приёмки. Задача переходит на `deploy-staging`.

View File

@@ -0,0 +1,12 @@
---
deploy_status: SUCCESS
work_item: ORCH-113
hook_exit_code: 0
deployed_by: deploy-finalizer
---
# Deploy log — ORCH-036 executable self-deploy
Прод-деплой завершён хост-хуком с exit-code `0` -> `deploy_status: SUCCESS`.
Вердикт зафиксирован детерминированным finalizer'ом (Фаза C), не LLM.

View File

@@ -0,0 +1,25 @@
---
security_status: PASS
secrets_found: 0
deps_blocking: 0
deps_warning: 4
deps_audit_degraded: false
---
# Security Report — ORCH-113
Детерминированный security-гейт (ORCH-022): secret-scanning (gitleaks, offline) + dependency audit (pip-audit). Машинный вердикт читается ТОЛЬКО из frontmatter выше.
## Verdict
clean: 0 secrets, 0 blocking CVE(s)
## Secrets
- None
## Dependencies (blocking)
- None
## Dependencies (warning)
- `pytest==8.3.3` — GHSA-6w46-j5rx-g56g severity=UNKNOWN fix=9.0.3
- `starlette==0.38.6` — PYSEC-2026-161 severity=UNKNOWN fix=1.0.1
- `starlette==0.38.6` — GHSA-f96h-pmfr-66vw severity=UNKNOWN fix=0.40.0
- `starlette==0.38.6` — GHSA-2c2j-9gv5-cj73 severity=UNKNOWN fix=0.47.2

View File

@@ -0,0 +1,22 @@
---
coverage_status: PASS
work_item: ORCH-113
measured_coverage: 80.02
baseline: 79.95
floor: 0.00
policy: both
epsilon: 0.50
delta: 0.07
---
# Coverage Report — ORCH-113
Детерминированный гейт покрытия (ORCH-027) — под-гейт ребра `deploy-staging→deploy` (ПОСЛЕ merge-gate, ДО image-freshness). Машинный вердикт читается ТОЛЬКО из `coverage_status:` frontmatter выше.
## Verdict
measured=80.02% policy=both eps=0.50: absolute 80.02% >= floor 0.00%-eps0.50 -> PASS; baseline 80.02% >= base 79.95%-eps0.50 -> PASS
## Measurement
pytest --cov=src: line coverage src/ = 80.02%
## Policy
policy=both, floor=0.0%, baseline=79.95%, epsilon=0.5%

View File

@@ -220,6 +220,35 @@ else
log "No previous image captured (first deploy or service not running?)"
fi
# 2a. ORCH-112: resilient pull — converge the shared deploy-base to a clean, current
# origin/main BEFORE the pull, so a dirty working tree (manual/abandoned WIP left
# by a failed/cancelled task) never blocks the deploy (incident ORCH-111, dirt from
# ORCH-104). Gated by CHECKOUT_HYGIENE (Python kill-switch + self-hosting scope,
# injected by self_deploy.build_deploy_command). NEVER `-x` (would delete gitignored
# .env / data/*.db / build/); EXCLUDES the untracked-but-not-ignored rollback/log
# artefacts .deploy-prev-image-* and deploy-hook.log (NFR-2). Best-effort: every git
# step is `|| log "...continuing"` and the bare `git pull` below still runs
# (never-break). On a CLEAN base the whole block is a no-op -> the happy-path
# behaviour and exit-codes (0/1/2, ORCH-036) are byte-for-byte unchanged.
if [[ "${CHECKOUT_HYGIENE:-0}" == "1" ]]; then
dirty="$(git status --porcelain 2>/dev/null || true)"
if [[ -n "$dirty" ]]; then
log "HYGIENE: dirty deploy-base detected, converging to origin/main:"
log "$dirty"
git fetch origin main >> "$LOG" 2>&1 || log "HYGIENE: fetch failed (continuing)"
git reset --hard origin/main >> "$LOG" 2>&1 || log "HYGIENE: reset failed (continuing)"
git clean -fd \
-e '.deploy-prev-image-*' \
-e 'deploy-hook.log' \
>> "$LOG" 2>&1 || log "HYGIENE: clean failed (continuing)"
if [[ -n "${HYGIENE_REPORT:-}" ]]; then
{ printf 'dirty=1\n'; printf '%s\n' "$dirty"; } > "$HYGIENE_REPORT" 2>/dev/null || true
fi
else
log "HYGIENE: deploy-base already clean (no-op)"
fi
fi
# 2. Pull latest code (keeps the host working tree current for future builds;
# the DEPLOYED artefact is the retagged SOURCE_IMAGE below when build-once).
log "git pull origin main"

View File

@@ -868,6 +868,55 @@ class AgentLauncher:
_task_id = _row[0] if _row else None
conn.close()
# ORCH-113 (adr-0043 / D2): register finalizer ownership at the EARLIEST
# moment the reaper can enter Tier-2 — exit_code is now stamped, so the agent
# pid is dead and Tier-1 no longer protects this row. On the
# deploy-staging -> deploy edge the rest of the finalization (git push, the
# heavy edge sub-gates via _try_advance_stage, _finalize_job) runs IN THIS
# THREAD for MINUTES; without ownership the reaper would treat the live
# finalizer as dead and re-run the advance (false rollback, incident
# ORCH-111). The marker is written unconditionally (kill-switch only gates the
# reaper's CONSULTATION, so the disabled path is byte-for-byte prior). Only
# queue-launched jobs (job_id is not None) are in get_running_jobs / reapable.
if job_id is not None:
try:
from .. import finalizer_liveness
_t_mark = get_task_by_repo_branch(repo, branch)
finalizer_liveness.mark(
job_id, run_id, _t_mark["stage"] if _t_mark else None
)
except Exception: # noqa: BLE001 - never-raise: marker is best-effort
pass
# The finalization tail runs under try/finally so ownership is ALWAYS
# released — including on ANY exception in this thread, which lets the reaper
# finish a genuinely dead finalizer (FR-4).
try:
self._run_monitor_finalization(
run_id, agent, repo, branch, exit_code, output_path,
job_id, _task_id, _duration_s,
)
finally:
if job_id is not None:
try:
from .. import finalizer_liveness
finalizer_liveness.clear(job_id)
except Exception: # noqa: BLE001 - never-raise
pass
def _run_monitor_finalization(
self, run_id, agent, repo, branch, exit_code, output_path,
job_id, _task_id, _duration_s,
):
"""ORCH-113 (adr-0043): finalization tail of ``_monitor_agent``.
Extracted VERBATIM from ``_monitor_agent`` (no logic change — verify with
``git diff -w``) so the caller can wrap it in a single ``try/finally`` that
releases the finalizer-ownership marker (``finalizer_liveness.clear``) on any
outcome. Runs in the monitor thread: notify, usage accounting, git
commit/push (+PR), failure handling, usage comments, the gate-driven
``_try_advance_stage`` and finally ``_finalize_job`` for queue-launched jobs.
"""
notify_agent_finished(run_id, agent, exit_code, task_id=_task_id, duration_s=_duration_s)
# Feature 4: parse token usage / cost from the (json) run log and record

214
src/checkout_hygiene.py Normal file
View File

@@ -0,0 +1,214 @@
"""ORCH-112 (ADR-001 / adr-0044): deploy-base checkout-hygiene leaf — pure policy.
Leaf module mirroring ``src/serial_gate.py`` / ``src/cancel.py`` / ``src/self_deploy.py``:
pure, unit-testable, never-raise functions over ``config`` + the deploy-state sentinels.
Module-level imports are limited to ``config`` (and stdlib); ``self_deploy``,
``qg.checks.is_self_hosting_repo`` and ``notifications`` are imported LAZILY so this
stays a leaf and an import cycle can never form.
What it answers / does (the MECHANISM — git fetch/reset/clean — lives in the host
deploy hook ``scripts/orchestrator-deploy-hook.sh`` block "2a. Resilient pull"; this
leaf only decides conditionality, builds the env gate, reads the report and alerts):
* ``applies(repo)`` — is resilient-pull hygiene REAL here?
* ``hook_env(repo, work_item_id)`` — the ``CHECKOUT_HYGIENE=1 HYGIENE_REPORT=…``
env prefix injected into the detached
deploy-hook command ("" when not applies).
* ``read_report(repo, work_item_id)`` — read the ``hygiene`` sentinel the hook wrote.
* ``alert_dirty(repo, work_item_id, report)``— best-effort Telegram + structured log.
* ``snapshot()`` — read-only block for ``GET /queue``.
never-raise contract (self-hosting safety): every public function degrades
conservatively. ``applies`` -> False on error (hygiene inert == kill-switch off, the
safe default that keeps the bare ``git pull`` 1:1 as before ORCH-112). ``hook_env`` ->
"" on error (no env -> the hook's ``${CHECKOUT_HYGIENE:-0}`` guard stays 0). The report
reader / alert swallow every error so a deploy is NEVER crashed by an observability
hiccup (D5 / AC-8).
"""
from __future__ import annotations
import logging
import os
import re
import shlex
from .config import settings
logger = logging.getLogger("orchestrator.checkout_hygiene")
# Sentinel filename the hook writes (HYGIENE_REPORT points at it) and read_report
# reads back. Lives in the SAME deploy-state dir as self_deploy's ``result`` (shared
# mount visible to both host and container).
REPORT_NAME = "hygiene"
# Repo tokens in the CSV scope must match this (mirrors serial_gate._REPO_TOKEN). The
# CSV is operator config, not user input, but the guard is mandatory; an invalid token
# is dropped.
_REPO_TOKEN = re.compile(r"^[A-Za-z0-9._-]+$")
# ---------------------------------------------------------------------------
# Conditionality (mirrors self_deploy_applies / serial_gate_applies)
# ---------------------------------------------------------------------------
def _scope_repos() -> set[str]:
"""Sanitised set of in-scope repo tokens from ``checkout_hygiene_repos`` (CSV).
Empty/blank CSV -> empty set, meaning "self-hosting only" (resolved in ``applies``).
Invalid tokens (regex miss) are dropped. Never raises.
"""
try:
raw = (settings.checkout_hygiene_repos or "").strip()
except Exception: # noqa: BLE001
return set()
if not raw:
return set()
out: set[str] = set()
for tok in raw.split(","):
t = tok.strip()
if t and _REPO_TOKEN.match(t):
out.add(t)
elif t:
logger.warning("checkout_hygiene: dropping invalid repo token %r from CSV", t)
return out
def applies(repo: str) -> bool:
"""Whether resilient-pull hygiene is REAL for this repo (D3 / AC-6).
* ``checkout_hygiene_enabled=False`` -> always False (kill-switch; the hook sees
no CHECKOUT_HYGIENE env -> bare ``git pull origin main`` 1:1 as before ORCH-112).
* ``checkout_hygiene_repos`` (CSV) non-empty -> real only for listed repos.
* empty CSV -> real ONLY for the self-hosting repo (``orchestrator``), mirroring
``self_deploy_repos`` — this is a self-hosting prod-deploy-path feature, so it
must NOT touch enduro / other repos' synchronous deploy.
Local-only (no network), meant to be checked FIRST. Never raises -> False on error.
"""
try:
if not getattr(settings, "checkout_hygiene_enabled", False):
return False
scope = _scope_repos()
if scope:
return (repo or "").strip() in scope
# Lazy import keeps this module a leaf (no qg import at module load).
from .qg.checks import is_self_hosting_repo
return is_self_hosting_repo(repo)
except Exception as e: # noqa: BLE001 - never-raise
logger.warning("checkout_hygiene.applies error for %s: %s", repo, e)
return False
# ---------------------------------------------------------------------------
# Env gate injected into the detached deploy-hook command (Phase B wiring)
# ---------------------------------------------------------------------------
def report_path_host(repo: str, work_item_id: str | None) -> str:
"""HOST view of the ``hygiene`` sentinel path (the wrapper writes it there)."""
from . import self_deploy
return os.path.join(self_deploy.host_state_dir(repo, work_item_id), REPORT_NAME)
def hook_env(repo: str, work_item_id: str | None) -> str:
"""Build the env-assignment prefix injected into the detached deploy-hook command.
Returns ``CHECKOUT_HYGIENE=1 HYGIENE_REPORT=<host-path>`` (shlex-quoted) ONLY when
``applies(repo)`` is True; otherwise ``""`` so the hook's ``${CHECKOUT_HYGIENE:-0}``
guard stays 0 and the bare ``git pull`` runs (1:1 before ORCH-112). The
``HYGIENE_REPORT`` path is the HOST view of the deploy-state dir (the host wrapper
writes the sentinel there; the container reads it back via ``read_report``). Never
raises -> "" (no hygiene env, the safe default).
"""
try:
if not applies(repo):
return ""
report = report_path_host(repo, work_item_id)
return f"CHECKOUT_HYGIENE=1 HYGIENE_REPORT={shlex.quote(report)}"
except Exception as e: # noqa: BLE001 - never-raise -> no hygiene env
logger.warning("checkout_hygiene.hook_env error for %s/%s: %s", repo, work_item_id, e)
return ""
# ---------------------------------------------------------------------------
# Report sentinel reader (Phase C observability)
# ---------------------------------------------------------------------------
def read_report(repo: str, work_item_id: str | None) -> dict | None:
"""Read the ``hygiene`` sentinel the hook wrote (container view of deploy-state).
The hook writes the sentinel ONLY when it detected a dirty base, body::
dirty=1
<git status --porcelain lines...>
Returns ``{"dirty": True, "paths": [...]}`` when the sentinel exists and reports a
dirty base; ``None`` when there is no sentinel (clean base / hygiene disabled / not
written yet). Never raises -> None on error.
"""
try:
from . import self_deploy
p = os.path.join(self_deploy.container_state_dir(repo, work_item_id), REPORT_NAME)
with open(p, "r", encoding="utf-8") as f:
raw = f.read()
except FileNotFoundError:
return None
except Exception as e: # noqa: BLE001 - never-raise
logger.warning("checkout_hygiene.read_report error for %s/%s: %s", repo, work_item_id, e)
return None
lines = raw.splitlines()
if not any(ln.strip() == "dirty=1" for ln in lines):
return None
paths = [
ln.strip() for ln in lines
if ln.strip() and not ln.strip().startswith("dirty=")
]
return {"dirty": True, "paths": paths}
# ---------------------------------------------------------------------------
# Best-effort Telegram alert (Phase C observability) — D5 / AC-8
# ---------------------------------------------------------------------------
def alert_dirty(repo: str, work_item_id: str | None, report: dict | None) -> bool:
"""Structured log + best-effort Telegram that the deploy-base was dirty and was
converged to ``origin/main`` before the pull (D5 / AC-8). Returns True iff an alert
was sent. Its failure NEVER crashes the finalizer (never-raise) — observability is
best-effort and must not block the conveyor (AC-8 FAIL is "alert crashes deploy").
"""
try:
if not report or not report.get("dirty"):
return False
paths = report.get("paths") or []
n = len(paths)
logger.warning(
"checkout_hygiene: dirty deploy-base converged to origin/main for %s/%s "
"(%d path(s)): %s", repo, work_item_id, n, paths[:20],
)
from .notifications import link_for, send_telegram
send_telegram(
f"\U0001f9f9 {link_for(work_item_id)}: грязная deploy-база сведена к "
f"origin/main перед прод-деплоем ({n} путь(ей) сброшено)."
)
return True
except Exception as e: # noqa: BLE001 - never-raise: alert is best-effort
logger.warning("checkout_hygiene.alert_dirty error for %s/%s: %s", repo, work_item_id, e)
return False
# ---------------------------------------------------------------------------
# Observability snapshot for GET /queue (D3, optional)
# ---------------------------------------------------------------------------
def snapshot() -> dict:
"""Read-only checkout-hygiene summary for GET /queue.
Additive block; existing /queue keys are untouched. never-raise -> a minimal dict
with the flags on error.
"""
try:
enabled = bool(getattr(settings, "checkout_hygiene_enabled", False))
except Exception: # noqa: BLE001
enabled = False
try:
repos_cfg = getattr(settings, "checkout_hygiene_repos", "") or ""
except Exception: # noqa: BLE001
repos_cfg = ""
return {
"enabled": enabled,
"repos": repos_cfg,
"scope": "csv" if (repos_cfg or "").strip() else "self-hosting-only",
}

View File

@@ -290,6 +290,25 @@ class Settings(BaseSettings):
deploy_prod_compose_profile: str = ""
deploy_prod_prev_image_file: str = ".deploy-prev-image-prod"
# ORCH-112: deploy-base checkout-hygiene (resilient-pull). The self-deploy hook's
# bare `git pull origin main` in the shared main clone blocked on a dirty working
# tree (manual/abandoned WIP left by a failed/cancelled task — incident ORCH-111
# from ORCH-104). The fix converges the deploy-base to a clean, current origin/main
# (git fetch + reset --hard + a SCOPED `git clean -fd`, NEVER `-x`) BEFORE the pull,
# gated by the CHECKOUT_HYGIENE env injected by self_deploy.build_deploy_command.
# Pure leaf: src/checkout_hygiene.py (never-raise). Not a Quality Gate / not a stage
# — STAGE_TRANSITIONS / QG_CHECKS / check_* / machine-verdict / DB schema / the
# hook's exit-code contract (0/1/2, ORCH-036) are byte-for-byte untouched.
#
# checkout_hygiene_enabled -> kill-switch (env ORCH_CHECKOUT_HYGIENE_ENABLED).
# False -> the hook gets no CHECKOUT_HYGIENE env ->
# bare `git pull origin main` 1:1 as before ORCH-112.
# checkout_hygiene_repos -> CSV scope (env ORCH_CHECKOUT_HYGIENE_REPOS). Empty
# -> only the self-hosting repo (orchestrator). Mirrors
# self_deploy_repos (a self-hosting prod-deploy feature).
checkout_hygiene_enabled: bool = True
checkout_hygiene_repos: str = ""
# ORCH-058: staging-image provenance before the BUILD-ONCE retag to prod.
# Closes the INV-FRESH gap (ADR-001): the BUILD-ONCE retag (ORCH-36) promotes
# the staging image to prod WITHOUT a rebuild, assuming the staging image is
@@ -544,12 +563,32 @@ class Settings(BaseSettings):
# lease_reclaim_enabled -> kill-switch for the proactive stale/dead lease reclaim
# (false -> only the legacy lazy TTL reclaim in acquire).
# (reuse) merge_lock_timeout_s -> lease TTL; merge_gate_repos -> reclaim scope.
# reaper_finalizer_liveness_enabled -> ORCH-113 (adr-0043): consult the
# process-local finalizer-ownership registry
# (src/finalizer_liveness.py) in the Tier-2 branch. On the
# deploy-staging -> deploy edge the monitor runs the heavy
# edge sub-gates (security/merge-gate re-test/coverage/
# image-freshness) in-thread AFTER the finished_at stamp and
# BEFORE _finalize_job — MINUTES — which finished_age_s grace
# does NOT cover, so a live long finalizer was wrongly reaped
# and re-ran the advance (false rollback, incident ORCH-111).
# When true AND the task stage == 'deploy-staging' AND a live
# monitor owns the finalization, the reaper DEFERS (no second
# advance) and falls through to the Tier-3 backstop (which
# ignores the marker -> a stuck/dead finalizer is still reaped
# in bounded time). false -> reaper byte-for-byte as before
# (the marker is still written by the monitor but never
# consulted -> inert). Global only, NO per-repo split (the bug
# is common to every repo with a deploy-staging stage). Does
# NOT touch grace/ceiling -> the cross-cutting budget
# reaper_max_running_s > Σ(gate-work) + grace stays intact.
reaper_enabled: bool = True
reaper_interval_s: int = 60
reaper_dead_ticks: int = 2
reaper_max_running_s: int = 5400
reaper_finalize_grace_s: int = 300
lease_reclaim_enabled: bool = True
reaper_finalizer_liveness_enabled: bool = True
# ORCH-063: disk-watchdog — background heartbeat that measures host-FS fill via
# the mounted bind-paths and Telegram-alerts the operator at >= threshold. On

120
src/finalizer_liveness.py Normal file
View File

@@ -0,0 +1,120 @@
"""ORCH-113 (adr-0043): process-local finalizer-ownership registry.
Leaf module — pure, process-local, never-raise (pattern of ``serial_gate`` /
``coverage_gate``: imports nothing from ``stage_engine`` / ``launcher`` / the DB,
talks to no network). It records "a LIVE monitor thread is currently finalizing
job X" so the job-reaper can tell a long-running-but-alive finalizer apart from a
genuinely dead one.
Why in-memory is authoritative (ADR-001 / adr-0043): the monitor
(``launcher._monitor_agent``) and the reaper (``job_reaper``) are daemon THREADS
of the SAME single uvicorn process (CMD has no ``--workers``), sharing one SQLite
DB. So liveness of the finalizing thread can be observed in-process. A whole-process
death is covered by the startup ``requeue_running_jobs()`` (``running -> queued``),
which ``main.lifespan`` runs BEFORE the reaper starts — so a restart leaves this
registry empty and the requeued jobs are re-driven cleanly (restart-safe, no durable
state needed).
The bug this closes (incident ORCH-111, deployer job 1914): on the
``deploy-staging -> deploy`` edge the monitor stamps ``agent_runs.finished_at``
FIRST, then runs the heavy edge sub-gates (security -> merge-gate re-test ->
coverage -> image-freshness) synchronously in its own thread — MINUTES — and only
THEN ``_finalize_job``. Reaper Tier-2 measures ``finished_age_s`` from
``finished_at`` (= the START of finalization), so once it exceeds
``reaper_finalize_grace_s`` (300s) it treated the live, long-finalizing monitor as
dead and independently re-ran the same heavy advance -> a second re-test went red ->
false rollback ``deploy-staging -> development`` while the original finalizer
concurrently merged the PR. State diverged.
No own TTL: time-bounding is the reaper's Tier-3 backstop (``reaper_max_running_s``),
which deliberately IGNORES this marker so a truly stuck finalizer is still reaped in
bounded time. Every public function is isolated (``try/except`` -> safe default);
``is_active`` defaults to ``False`` on error (conservative: never block the reaping
of a possibly-dead finalizer).
See docs/work-items/ORCH-113/06-adr/ADR-001-reaper-finalizer-liveness-ownership.md
and the cross-cutting docs/architecture/adr/adr-0043-reaper-finalizer-liveness-ownership.md.
"""
from __future__ import annotations
import logging
import threading
import time
logger = logging.getLogger("orchestrator.finalizer_liveness")
# Process-local ownership registry: {job_id: {"run_id", "stage", "started_ts"}}.
# Guarded by a Lock because the monitor thread writes (mark/clear) while the reaper
# thread reads (is_active/snapshot). All state resets on process restart, which is
# safe (the startup requeue_running_jobs covers the restart path).
_LOCK = threading.Lock()
_OWNED: dict[int, dict] = {}
def mark(job_id: int | None, run_id: int | None, stage: str | None) -> None:
"""Register that a live monitor thread is finalizing ``job_id``.
Called by ``launcher._monitor_agent`` right after the ``exit_code`` stamp (the
earliest moment the reaper can enter Tier-2). ``stage`` is best-effort context
for the snapshot only — the reaper decides the actual stage from ``tasks`` via
its own ``_task_meta`` lookup. No-op when ``job_id is None`` (legacy direct
``launch()`` jobs are not in ``get_running_jobs`` and are unreapable). Never
raises.
"""
if job_id is None:
return
try:
with _LOCK:
_OWNED[job_id] = {
"run_id": run_id,
"stage": stage,
"started_ts": time.time(),
}
except Exception as e: # noqa: BLE001 - never-raise contract
logger.warning("finalizer_liveness.mark failed for job %s: %s", job_id, e)
def clear(job_id: int | None) -> None:
"""Release ownership of ``job_id`` (idempotent).
Called from the ``finally`` of the monitor's finalization tail, so ANY exception
in the monitor thread still releases ownership -> a genuinely dead finalizer is
reaped (FR-4). Never raises.
"""
if job_id is None:
return
try:
with _LOCK:
_OWNED.pop(job_id, None)
except Exception as e: # noqa: BLE001 - never-raise contract
logger.warning("finalizer_liveness.clear failed for job %s: %s", job_id, e)
def is_active(job_id: int | None) -> bool:
"""True iff a live monitor currently owns the finalization of ``job_id``.
Consulted by the reaper Tier-2 branch. Defaults to ``False`` on any error or
when ``job_id is None`` (conservative: never block the reaping of a possibly
dead finalizer). Never raises.
"""
if job_id is None:
return False
try:
with _LOCK:
return job_id in _OWNED
except Exception as e: # noqa: BLE001 - never-raise contract
logger.warning("finalizer_liveness.is_active failed for job %s: %s", job_id, e)
return False
def snapshot() -> dict:
"""Read-only view of current ownership for ``GET /queue`` observability.
Returns ``{"active": <count>, "jobs": [job_id, ...]}``. Never raises.
"""
try:
with _LOCK:
return {"active": len(_OWNED), "jobs": sorted(_OWNED.keys())}
except Exception as e: # noqa: BLE001 - never-raise contract
logger.warning("finalizer_liveness.snapshot failed: %s", e)
return {"active": 0, "jobs": []}

View File

@@ -38,7 +38,15 @@ Liveness (defense in depth, ADR-001 Р-1):
reaper therefore treats it as a dead monitor (KNOWN outcome) only after a
finalization grace: ``exit_code`` recorded for >= ``reaper_finalize_grace_s``
(a live finalizing monitor is NEVER reaped, FR-1.3/AC-3). Within the grace the
row is left untouched.
row is left untouched. **ORCH-113 (adr-0043):** on the ``deploy-staging ->
deploy`` edge the in-thread finalization runs the heavy edge sub-gates
(security/merge-gate re-test/coverage/image-freshness) for MINUTES AFTER the
``finished_at`` stamp, so even past the grace the monitor may be alive. Tier-2
now consults a process-local ownership marker (``finalizer_liveness``): a job
on ``deploy-staging`` still owned by a live finalizer is DEFERRED (not reaped via
Tier-2 — re-running the advance caused the false rollback in incident ORCH-111)
and falls through to the Tier-3 backstop, which IGNORES the marker. Kill-switch
``reaper_finalizer_liveness_enabled``.
* **Tier-3 (backstop): age ceiling.** A job ``running`` longer than
``reaper_max_running_s`` (deliberately > max ``agent_timeout`` + grace) is
reaped even when liveness cannot be determined (pid reused / unknown).
@@ -142,6 +150,10 @@ class JobReaper:
self.reaped_total: int = 0
self.last_reaped: dict | None = None
self.lease_reclaimed_total: int = 0
# ORCH-113 (adr-0043 / D5): count of Tier-2 reaps deferred because a live
# monitor still owns a deploy-staging finalization. Reset on restart (safe:
# startup requeue_running_jobs covers the restart path).
self.finalizer_defers_total: int = 0
# -- A: zombie-job reaping --------------------------------------------
def reap_once(self) -> None:
@@ -199,13 +211,34 @@ class JobReaper:
finished_age = job.get("finished_age_s")
grace = int(settings.reaper_finalize_grace_s)
if finished_age is not None and int(finished_age) >= grace:
self._reap_known_outcome(job, int(exit_code))
return
logger.info(
"reaper: job %s exit_code=%s recorded %ss ago (< grace %ss) — "
"deferring (monitor may still be finalizing)",
job_id, exit_code, finished_age, grace,
)
# ORCH-113 (adr-0043 / D3): even past the grace, a LIVE monitor may
# still be running the minutes-long deploy-staging edge sub-gates
# in-thread — finished_age is measured from the START of finalization
# (the finished_at stamp), and on deploy-staging the heavy advance
# (security/merge-gate re-test/coverage/image-freshness) runs AFTER
# that stamp and BEFORE _finalize_job. If a live finalizer still owns
# this job, DEFER the Tier-2 reap (re-running the advance caused the
# false rollback in incident ORCH-111) and fall through to the Tier-3
# backstop, which IGNORES the marker so a stuck/dead finalizer is
# still reaped in bounded time.
if self._finalizer_owns(job):
self.finalizer_defers_total += 1
logger.info(
"reaper: job %s (deploy-staging) still owned by a live "
"finalizer %ss past grace — deferring Tier-2 (Tier-3 backstop "
"at %ss still applies)",
job_id, finished_age, settings.reaper_max_running_s,
)
# fall through to the Tier-3 backstop guard below.
else:
self._reap_known_outcome(job, int(exit_code))
return
else:
logger.info(
"reaper: job %s exit_code=%s recorded %ss ago (< grace %ss) — "
"deferring (monitor may still be finalizing)",
job_id, exit_code, finished_age, grace,
)
# fall through to the Tier-3 backstop guard below.
else:
# Tier-1: dead pid, only after `reaper_dead_ticks` consecutive dead ticks.
@@ -400,6 +433,33 @@ class JobReaper:
job.get("id"), e)
return None, None, None
def _finalizer_owns(self, job: dict) -> bool:
"""ORCH-113 (adr-0043 / D3): True iff a LIVE monitor still owns this job's
``deploy-staging`` finalization, so the Tier-2 reap must be deferred.
Order matters for the zero-regression contract: the kill-switch is checked
FIRST (disabled -> ``False`` with no DB lookup, so the path is byte-for-byte
prior); then the stage is scoped to ``deploy-staging`` only (the sole edge
whose in-thread finalization runs for minutes — every other stage is left
untouched); only then is the process-local ownership marker consulted. Never
raises -> ``False`` on any error (conservative: never block reaping when
ownership is unknowable, so the Tier-3 backstop is never neutered).
"""
try:
if not settings.reaper_finalizer_liveness_enabled:
return False
_branch, stage, _wid = self._task_meta(job)
if stage != "deploy-staging":
return False
from . import finalizer_liveness
return finalizer_liveness.is_active(job.get("id"))
except Exception as e: # noqa: BLE001 - never break the reap tick
logger.warning(
"reaper: finalizer-liveness check failed for job %s: %s",
job.get("id"), e,
)
return False
def _notify_failed(self, job: dict, reason: str) -> None:
try:
from .notifications import send_telegram
@@ -463,6 +523,14 @@ class JobReaper:
def status(self) -> dict:
"""Reaper snapshot for /queue observability (Р-6)."""
# ORCH-113 (adr-0043 / D5): expose the defer counter + the current finalizer
# ownership set (read-only, never-raise). Additive keys only — existing keys
# are unchanged.
try:
from . import finalizer_liveness
_owned = finalizer_liveness.snapshot()
except Exception: # noqa: BLE001 - observability must never break /queue
_owned = {"active": 0, "jobs": []}
return {
"enabled": settings.reaper_enabled,
"interval": self.interval_s,
@@ -470,6 +538,9 @@ class JobReaper:
"reaped_total": self.reaped_total,
"last_reaped": self.last_reaped,
"lease_reclaimed_total": self.lease_reclaimed_total,
"finalizer_liveness_enabled": settings.reaper_finalizer_liveness_enabled,
"finalizer_defers_total": self.finalizer_defers_total,
"finalizer_owned": _owned,
}

View File

@@ -214,6 +214,7 @@ async def queue():
from . import cancel
from . import bug_fast_track
from . import lessons
from . import checkout_hygiene
from .disk_watchdog import disk_watchdog
from .build_cache_pruner import build_cache_pruner
return {
@@ -254,6 +255,9 @@ async def queue():
# kill-switch, label, scope, bug-task counts + the structural savings metric
# (architecture stages skipped). Additive block; never-raise.
"bug_fast_track": bug_fast_track.snapshot(),
# ORCH-112 (D3): deploy-base checkout-hygiene observability (read-only) —
# kill-switch + scope. Additive block; never-raise.
"checkout_hygiene": checkout_hygiene.snapshot(),
# ORCH-098 (FR-4 / AC-4): lessons-journal observability (read-only) —
# kill-switch + counts by type/status + last N lessons. Additive block;
# never-raise (snapshot() returns {"enabled": ...} minimum on error).

View File

@@ -239,7 +239,7 @@ def build_deploy_command(repo: str, work_item_id: str | None, branch: str) -> li
``expected_revision`` returns ``""`` and the env is omitted, keeping the hook's
backward-compatible "no provenance check" behaviour (AC-5 / AC-7).
"""
from . import image_freshness
from . import checkout_hygiene, image_freshness
host_dir = host_state_dir(repo, work_item_id)
result_sentinel = os.path.join(host_dir, RESULT)
@@ -262,6 +262,12 @@ def build_deploy_command(repo: str, work_item_id: str | None, branch: str) -> li
expected_rev = image_freshness.expected_revision(repo, branch)
if expected_rev:
env_assignments += f" EXPECTED_REVISION={shlex.quote(expected_rev)}"
# ORCH-112: inject CHECKOUT_HYGIENE=1 HYGIENE_REPORT=<path> only when the leaf says
# hygiene applies (kill-switch + self-hosting scope). Empty -> the hook's
# ${CHECKOUT_HYGIENE:-0} guard stays 0 -> bare `git pull` 1:1 as before ORCH-112.
hygiene_env = checkout_hygiene.hook_env(repo, work_item_id)
if hygiene_env:
env_assignments += f" {hygiene_env}"
inner = (
f"cd {shlex.quote(settings.deploy_host_repo_path)} && "
f"{env_assignments} "

View File

@@ -1957,6 +1957,17 @@ def run_deploy_finalizer(job: dict):
logger.info(
f"Task {task_id}: deploy finalized, hook exit={code} -> deploy_status={status}"
)
# ORCH-112 (D5 / AC-8): if the host hook converged a DIRTY deploy-base to
# origin/main before the pull, surface it (structured log + best-effort Telegram).
# never-raise — observability must never crash the finalizer.
try:
from . import checkout_hygiene
report = checkout_hygiene.read_report(repo, work_item_id)
if report:
checkout_hygiene.alert_dirty(repo, work_item_id, report)
except Exception as e: # noqa: BLE001 - never break the finalizer
logger.warning("Task %s: checkout-hygiene report read failed: %s", task_id, e)
if status == "SUCCESS" and work_item_id:
plane_add_comment(
work_item_id,

View File

@@ -0,0 +1,485 @@
"""ORCH-112: deploy-base checkout-hygiene (resilient-pull) — TC-01…TC-10.
Two test layers:
* SHELL simulation (TC-01..TC-04, TC-07) — drives the REAL
``scripts/orchestrator-deploy-hook.sh`` in a hermetic sandbox. ``git`` is REAL
(against a LOCAL bare "origin" — no network), while ``docker`` / ``curl`` /
``sleep`` are PATH-shimmed stubs so no real infra is touched and prod is never
restarted (INFRA safety). Models tests/test_deploy_hook_rollback_sim.py.
* UNIT (TC-05, TC-06, TC-08, TC-09, TC-10) — the ``checkout_hygiene`` leaf, the
static safety contract of the hook (never ``-x`` / explicit excludes), the
pipeline-invariant guard and the documentation invariant.
TC-01 is the MANDATORY incident-reproduction regression (ORCH-111): a dirty tracked
edit to ``src/config.py`` over an advanced ``origin/main`` makes the bare ``git pull``
abort with "local changes would be overwritten by merge" (RED before the fix); the
resilient-pull hygiene converges the base and the deploy proceeds (GREEN after).
"""
import os
import shutil
import stat
import subprocess
import pytest
from src import checkout_hygiene
ROOT = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
HOOK = os.path.join(ROOT, "scripts", "orchestrator-deploy-hook.sh")
pytestmark = pytest.mark.skipif(
shutil.which("bash") is None or shutil.which("git") is None,
reason="bash + git required for the deploy-hook hygiene simulation",
)
# Distinctive file bodies so assertions prove WHICH version won.
_V1 = "ORIGIN-V1\n"
_V2 = "ORIGIN-V2-ADVANCED\n"
_DIRTY = "DIRTY-LOCAL-WIP\n"
# Isolate git from any host/global config (hermetic).
_GIT_ENV = {
"GIT_AUTHOR_NAME": "t",
"GIT_AUTHOR_EMAIL": "t@example.com",
"GIT_COMMITTER_NAME": "t",
"GIT_COMMITTER_EMAIL": "t@example.com",
"GIT_CONFIG_GLOBAL": os.devnull,
"GIT_CONFIG_SYSTEM": os.devnull,
}
def _git(cwd, *args):
r = subprocess.run(
["git", "-C", str(cwd), *args],
capture_output=True, text=True, env={**os.environ, **_GIT_ENV},
)
assert r.returncode == 0, f"git {args} failed: {r.stdout}\n{r.stderr}"
return r
def _write(path, content):
os.makedirs(os.path.dirname(path), exist_ok=True)
with open(path, "w", encoding="utf-8") as f:
f.write(content)
def _write_exec(path, content):
_write(path, content)
os.chmod(path, os.stat(path).st_mode | stat.S_IEXEC | stat.S_IXGRP | stat.S_IXOTH)
def _make_stubs(binx, prev_running=True):
"""Healthy docker/curl/sleep stubs (no real infra; deploy always succeeds).
``prev_running`` controls whether ``docker compose ps -q`` returns a container id:
True -> step 1 captures a previous image and writes PREV_IMAGE_FILE (the normal
case); False -> no previous image is recorded (first-deploy / service-down), so the
deploy-base stays genuinely clean at the hygiene step (exercises the no-op branch).
"""
ps_id = "fakecid" if prev_running else ""
_write_exec(str(binx / "docker"), f"""#!/bin/bash
case "$1" in
compose)
for a in "$@"; do [ "$a" = "ps" ] && {{ echo "{ps_id}"; exit 0; }}; done
exit 0;;
inspect) echo "sha256:previmage"; exit 0;;
image) exit 0;;
tag) exit 0;;
*) exit 0;;
esac
""")
# curl: ALWAYS healthy -> deploy health-check passes immediately -> exit 0.
_write_exec(str(binx / "curl"), """#!/bin/bash
iscode=""
for a in "$@"; do [ "$a" = "-w" ] && iscode=1; done
[ -n "$iscode" ] && echo "200" || echo '{"status":"ok"}'
exit 0
""")
_write_exec(str(binx / "sleep"), "#!/bin/bash\nexit 0\n")
def _seed_origin_and_clone(tmp_path):
"""Build a local bare origin (at V2) + a deploy-base clone (at V1).
Returns ``repo`` (the deploy-base path). The clone is one commit BEHIND origin so
that, with a conflicting dirty edit to src/config.py, a bare ``git pull`` would
abort (the exact ORCH-111 incident), while hygiene's reset --hard converges it.
"""
work = tmp_path / "work"
work.mkdir()
_write(str(work / "src" / "config.py"), _V1)
_write(str(work / ".gitignore"), ".env\ndata/\n*.db\nbuild/\n")
_git(work, "init", "-q")
_git(work, "add", "-A")
_git(work, "commit", "-q", "-m", "v1")
_git(work, "branch", "-M", "main")
origin = tmp_path / "origin.git"
_git(tmp_path, "init", "-q", "--bare", str(origin))
_git(work, "remote", "add", "origin", str(origin))
_git(work, "push", "-q", "-u", "origin", "main")
repo = tmp_path / "repo"
_git(tmp_path, "clone", "-q", str(origin), str(repo))
# Advance origin/main to V2 (touches the SAME file we will dirty locally).
_write(str(work / "src" / "config.py"), _V2)
_git(work, "commit", "-q", "-am", "v2")
_git(work, "push", "-q", "origin", "main")
# Make repo's remote-tracking ref aware of V2's existence is the hook's job
# (it runs `git fetch`); leave repo at V1 deliberately.
return repo
def _run_hook(repo, tmp_path, hygiene="1", extra_env=None, prev_running=True):
"""Run the real hook in --deploy mode against ``repo`` with stubbed infra."""
binx = tmp_path / "bin"
if not binx.exists():
binx.mkdir()
_make_stubs(binx, prev_running=prev_running)
state = tmp_path / "state"
state.mkdir(exist_ok=True)
env = {
**os.environ,
**_GIT_ENV,
"PATH": f"{binx}:{os.environ['PATH']}",
"REPO": str(repo),
"LOG": str(state / "hook.log"),
"PREV_IMAGE_FILE": str(repo / ".deploy-prev-image-prod"),
"COMPOSE_PROFILE": "",
"TARGET_SERVICE": "orchestrator",
"TARGET_PORT": "8500",
}
if hygiene is not None:
env["CHECKOUT_HYGIENE"] = hygiene
env["HYGIENE_REPORT"] = str(state / "hygiene")
if extra_env:
env.update(extra_env)
return subprocess.run(
["bash", HOOK, "--deploy"], env=env, capture_output=True, text=True, timeout=60,
)
def _porcelain(repo):
r = subprocess.run(
["git", "-C", str(repo), "status", "--porcelain"],
capture_output=True, text=True, env={**os.environ, **_GIT_ENV},
)
return r.stdout.strip()
def _wip_dirt(repo):
"""Porcelain output MINUS the intentionally-preserved deploy artefacts.
After hygiene, the deploy-base is converged to origin/main but the rollback/log
artefacts (.deploy-prev-image-* / deploy-hook.log) are legitimately untracked-and-
preserved (NFR-2). This returns ONLY the *real* residual dirt (a non-empty result
means a tracked edit survived or WIP was not cleaned)."""
lines = []
for ln in _porcelain(repo).splitlines():
name = ln[3:] if len(ln) > 3 else ""
if name.startswith(".deploy-prev-image-") or name == "deploy-hook.log":
continue
lines.append(ln)
return "\n".join(lines).strip()
def _head_config(repo):
with open(repo / "src" / "config.py", encoding="utf-8") as f:
return f.read()
# ===========================================================================
# TC-01 — MANDATORY regression (red->green): dirty tracked edit + advanced origin
# ===========================================================================
def test_tc01_dirty_tracked_edit_converges_and_deploys(tmp_path):
repo = _seed_origin_and_clone(tmp_path)
# Dirty the SAME tracked file origin advanced -> a bare `git pull` would abort.
_write(str(repo / "src" / "config.py"), _DIRTY)
# Untracked WIP left behind too (failed/cancelled task residue).
_write(str(repo / "scripts" / "install_lite.py"), "# wip\n")
proc = _run_hook(repo, tmp_path, hygiene="1")
assert proc.returncode == 0, (
"resilient-pull must converge a dirty base and let the deploy proceed "
f"(stdout={proc.stdout}\nstderr={proc.stderr})"
)
# Base converged to the ADVANCED origin/main (dirty local edit discarded).
assert _head_config(repo) == _V2
# No real WIP remains (tracked edit reset, untracked WIP cleaned); the rollback
# snapshot .deploy-prev-image-prod is legitimately preserved (NFR-2), so we check
# the residual dirt MINUS the preserved artefacts.
assert _wip_dirt(repo) == ""
assert not (repo / "scripts" / "install_lite.py").exists()
out = proc.stdout + proc.stderr
assert "HYGIENE" in out
def test_tc01b_bare_pull_aborts_without_hygiene_documents_incident(tmp_path):
"""ORCH-111 reproduction: WITHOUT hygiene the same dirty base aborts the pull."""
repo = _seed_origin_and_clone(tmp_path)
_write(str(repo / "src" / "config.py"), _DIRTY)
proc = _run_hook(repo, tmp_path, hygiene=None) # CHECKOUT_HYGIENE unset
assert proc.returncode != 0, "bare `git pull` must abort on the conflicting dirty edit"
log = (tmp_path / "state" / "hook.log").read_text(encoding="utf-8")
assert "would be overwritten by merge" in (log + proc.stdout + proc.stderr)
# ===========================================================================
# TC-02 — untracked WIP files do not block and do not leak into the deploy
# ===========================================================================
def test_tc02_untracked_wip_does_not_block(tmp_path):
repo = _seed_origin_and_clone(tmp_path)
for rel in (
"scripts/install_lite.py",
"tests/test_install_lite.py",
"docs/deployment/lite-install.example.yaml",
):
_write(str(repo / rel), "# abandoned WIP\n")
proc = _run_hook(repo, tmp_path, hygiene="1")
assert proc.returncode == 0, f"{proc.stdout}\n{proc.stderr}"
assert _wip_dirt(repo) == ""
for rel in (
"scripts/install_lite.py",
"tests/test_install_lite.py",
"docs/deployment/lite-install.example.yaml",
):
assert not (repo / rel).exists(), f"{rel} must be cleaned, not leaked into deploy"
# ===========================================================================
# TC-03 — preservation of rollback/log/gitignored/sibling artefacts (NFR-2)
# ===========================================================================
def test_tc03_preserves_rollback_and_sibling_artifacts(tmp_path):
repo = _seed_origin_and_clone(tmp_path)
_write(str(repo / "src" / "config.py"), _DIRTY) # force the hygiene path
# In-$REPO artefacts that MUST survive (untracked, NOT gitignored).
_write(str(repo / ".deploy-prev-image-staging"), "sha256:stagingprev\n")
_write(str(repo / "deploy-hook.log"), "audit line\n")
# gitignored prod secrets / DB — must survive `git clean -fd` (NO -x).
_write(str(repo / ".env"), "ORCH_SECRET=keepme\n")
_write(str(repo / "data" / "orchestrator.db"), "sqlite-bytes\n")
# .git internal worktree admin record — git clean never touches .git/.
_write(str(repo / ".git" / "worktrees" / "wt1" / "HEAD"), "ref: refs/heads/x\n")
# Sibling state under the PARENT of $REPO — outside the clean scope.
_write(str(tmp_path / ".deploy-state-orchestrator" / "ORCH-112" / "result"), "0\n")
_write(str(tmp_path / ".merge-lease-orchestrator.json"), '{"branch":"x"}\n')
proc = _run_hook(repo, tmp_path, hygiene="1")
assert proc.returncode == 0, f"{proc.stdout}\n{proc.stderr}"
# Rollback snapshot freshly written by step 1 (PREV_IMAGE_FILE) survived hygiene.
assert (repo / ".deploy-prev-image-prod").is_file()
assert (repo / ".deploy-prev-image-prod").read_text().strip() != ""
# Wildcard-excluded sibling prev-image + log survived.
assert (repo / ".deploy-prev-image-staging").read_text() == "sha256:stagingprev\n"
assert (repo / "deploy-hook.log").read_text() == "audit line\n"
# gitignored secrets/DB survived (proves NO -x at runtime).
assert (repo / ".env").read_text() == "ORCH_SECRET=keepme\n"
assert (repo / "data" / "orchestrator.db").read_text() == "sqlite-bytes\n"
# .git internal + sibling state untouched.
assert (repo / ".git" / "worktrees" / "wt1" / "HEAD").is_file()
assert (tmp_path / ".deploy-state-orchestrator" / "ORCH-112" / "result").is_file()
assert (tmp_path / ".merge-lease-orchestrator.json").is_file()
# ===========================================================================
# TC-04 — happy-path: genuinely clean base -> hygiene no-op + plain fast-forward.
# Uses prev_running=False so step 1 records NO prev-image, leaving the base clean at
# the hygiene step (no untracked artefact) — the no-op `else` branch is exercised and
# the deploy reduces to the plain `git pull` fast-forward (exit-codes byte-for-byte).
# ===========================================================================
def test_tc04_clean_base_fast_forwards_no_op_hygiene(tmp_path):
repo = _seed_origin_and_clone(tmp_path) # repo is CLEAN, just behind origin
proc = _run_hook(repo, tmp_path, hygiene="1", prev_running=False)
assert proc.returncode == 0, f"{proc.stdout}\n{proc.stderr}"
log = (tmp_path / "state" / "hook.log").read_text(encoding="utf-8")
assert "deploy-base already clean (no-op)" in log
assert "dirty deploy-base detected" not in log
# Plain fast-forward brought origin/main's V2.
assert _head_config(repo) == _V2
# ===========================================================================
# TC-07 — convergence after cancel/failed: leftovers cleared, next deploy clean
# ===========================================================================
def test_tc07_convergence_then_next_deploy_is_clean(tmp_path):
repo = _seed_origin_and_clone(tmp_path)
# Leftovers from a failed/cancelled task: dirty tracked + untracked WIP.
_write(str(repo / "src" / "config.py"), _DIRTY)
_write(str(repo / "tests" / "test_install_lite.py"), "# wip\n")
first = _run_hook(repo, tmp_path, hygiene="1")
assert first.returncode == 0, f"{first.stdout}\n{first.stderr}"
assert _wip_dirt(repo) == "" # base converged, no WIP residue
assert _head_config(repo) == _V2
# A subsequent self-deploy proceeds without manual intervention (no WIP to block it).
second = _run_hook(repo, tmp_path, hygiene="1")
assert second.returncode == 0, f"{second.stdout}\n{second.stderr}"
assert _wip_dirt(repo) == ""
# ===========================================================================
# TC-05 — self-hosting safety + static hook safety contract (never -x / excludes)
# ===========================================================================
def _hook_code_lines():
"""Non-comment, non-blank lines of the hook (so a comment mentioning `-x` or
`exit` for documentation does not trip the static safety asserts)."""
out = []
for ln in open(HOOK, encoding="utf-8").read().splitlines():
s = ln.strip()
if not s or s.startswith("#"):
continue
out.append(ln)
return out
def test_tc05_hook_clean_is_never_destructive():
text = open(HOOK, encoding="utf-8").read()
code = "\n".join(_hook_code_lines())
assert "CHECKOUT_HYGIENE" in text, "hygiene block must exist in the hook"
# INV-HYGIENE-1: the hook's only `git clean` is `-fd`, NEVER `-x` (which would
# delete gitignored .env / data/*.db / build/). Checked against CODE only.
assert "git clean -fd" in code
assert "-x" not in code # no -x / -xfd / -fdx in any executable line
# INV-HYGIENE-2: explicit excludes for the untracked-but-not-ignored artefacts.
assert "-e '.deploy-prev-image-*'" in code
assert "-e 'deploy-hook.log'" in code
# Converge to the authoritative remote, never a local guess.
assert "git reset --hard origin/main" in code
# Self-hosting safety: the hygiene path never pushes/force-pushes the remote.
assert "push --force" not in code and "push -f " not in code
def test_tc05_leaf_is_a_pure_leaf():
"""checkout_hygiene must not import stage_engine / launcher at module load."""
src = open(os.path.join(ROOT, "src", "checkout_hygiene.py"), encoding="utf-8").read()
import_lines = [
ln for ln in src.splitlines()
if ln.startswith("import ") or ln.startswith("from ")
]
joined = "\n".join(import_lines)
assert "stage_engine" not in joined
assert "launcher" not in joined
# ===========================================================================
# TC-06 — kill-switch + repo scope (applies / hook_env)
# ===========================================================================
def test_tc06_kill_switch_off_is_inert(monkeypatch):
from src.config import settings
monkeypatch.setattr(settings, "checkout_hygiene_enabled", False)
assert checkout_hygiene.applies("orchestrator") is False
assert checkout_hygiene.hook_env("orchestrator", "ORCH-112") == ""
def test_tc06_empty_csv_is_self_hosting_only(monkeypatch):
from src.config import settings
monkeypatch.setattr(settings, "checkout_hygiene_enabled", True)
monkeypatch.setattr(settings, "checkout_hygiene_repos", "")
assert checkout_hygiene.applies("orchestrator") is True
assert checkout_hygiene.applies("enduro-trails") is False
env = checkout_hygiene.hook_env("orchestrator", "ORCH-112")
assert env.startswith("CHECKOUT_HYGIENE=1 ")
assert "HYGIENE_REPORT=" in env
# A non-self repo gets no hygiene env (other repos unaffected).
assert checkout_hygiene.hook_env("enduro-trails", "ET-1") == ""
def test_tc06_csv_scope_limits_repos(monkeypatch):
from src.config import settings
monkeypatch.setattr(settings, "checkout_hygiene_enabled", True)
monkeypatch.setattr(settings, "checkout_hygiene_repos", "alpha, beta")
assert checkout_hygiene.applies("alpha") is True
assert checkout_hygiene.applies("beta") is True
assert checkout_hygiene.applies("orchestrator") is False
# ===========================================================================
# TC-08 — observability: read_report / alert_dirty never-raise
# ===========================================================================
def test_tc08_read_report_none_when_absent(monkeypatch, tmp_path):
from src.config import settings
monkeypatch.setattr(settings, "repos_dir", str(tmp_path))
assert checkout_hygiene.read_report("orchestrator", "ORCH-112") is None
def test_tc08_read_report_parses_dirty_sentinel(monkeypatch, tmp_path):
from src import self_deploy
from src.config import settings
monkeypatch.setattr(settings, "repos_dir", str(tmp_path))
d = self_deploy.container_state_dir("orchestrator", "ORCH-112")
os.makedirs(d, exist_ok=True)
_write(os.path.join(d, "hygiene"), "dirty=1\n M src/config.py\n?? scripts/x.py\n")
rep = checkout_hygiene.read_report("orchestrator", "ORCH-112")
assert rep == {"dirty": True, "paths": ["M src/config.py", "?? scripts/x.py"]}
def test_tc08_alert_dirty_never_raises_on_send_failure(monkeypatch):
import src.notifications as notifications
def boom(*a, **k):
raise RuntimeError("telegram down")
monkeypatch.setattr(notifications, "send_telegram", boom)
# Must swallow the error (best-effort) and NOT crash the finalizer.
assert checkout_hygiene.alert_dirty(
"orchestrator", "ORCH-112", {"dirty": True, "paths": ["x"]}
) is False
# No report / not dirty -> no alert, no raise.
assert checkout_hygiene.alert_dirty("orchestrator", "ORCH-112", None) is False
# ===========================================================================
# TC-09 — pipeline invariant: STAGE_TRANSITIONS / QG_CHECKS / exit-codes untouched
# ===========================================================================
def test_tc09_pipeline_contracts_untouched():
from src import stages
from src.qg import checks
# The hygiene feature is NOT a stage and NOT a QG check.
assert "checkout_hygiene" not in {
k for tr in stages.STAGE_TRANSITIONS.values() for k in (tr if isinstance(tr, dict) else {})
}
assert not any("hygiene" in name for name in checks.QG_CHECKS)
def test_tc09_hook_exit_code_contract_intact():
text = open(HOOK, encoding="utf-8").read()
# The hook still maps to the 0/1/2 contract (ORCH-036).
assert "exit 0" in text and "exit 1" in text and "exit 2" in text
# The hygiene block itself never emits an `exit` statement (best-effort,
# never-break). Inspect only the CODE lines of the 2a block (a comment that
# mentions "exit-codes" must not trip this).
block = text.split("# 2a.", 1)[1].split("# 2.", 1)[0]
code_lines = [
ln for ln in block.splitlines()
if ln.strip() and not ln.strip().startswith("#")
]
for ln in code_lines:
assert not ln.strip().startswith("exit"), (
f"hygiene block must never change the hook exit-code: {ln!r}"
)
# ===========================================================================
# TC-10 — documentation invariant (golden source)
# ===========================================================================
def test_tc10_docs_state_deploy_base_invariant():
infra = open(os.path.join(ROOT, "docs", "operations", "INFRA.md"), encoding="utf-8").read()
readme = open(os.path.join(ROOT, "docs", "architecture", "README.md"), encoding="utf-8").read()
for doc in (infra, readme):
assert "ORCH-112" in doc
assert "deploy/worktree-management база" in doc
assert "workspace" in doc

View File

@@ -0,0 +1,386 @@
"""ORCH-113 (adr-0043): reaper must not re-run deploy-staging finalization while
the original finalizer is alive — finalizer-liveness ownership tests (TC-01..TC-08).
Covers the bug from incident ORCH-111 (deployer job 1914): on the
``deploy-staging -> deploy`` edge the live monitor runs the heavy edge sub-gates
(security/merge-gate re-test/coverage/image-freshness) in-thread for MINUTES AFTER
stamping ``agent_runs.finished_at`` and BEFORE ``_finalize_job``. Reaper Tier-2
measures ``finished_age_s`` from ``finished_at``, so past ``reaper_finalize_grace_s``
it treated the live, long-finalizing monitor as dead and independently re-ran the
advance -> a second re-test went red -> false rollback ``deploy-staging ->
development`` while the original finalizer concurrently merged the PR. State diverged.
The reaper never spawns claude / pytest / docker; we drive the DB directly (a
'running' jobs row + a linked agent_runs exit_code) and the process-local
``finalizer_liveness`` marker, then assert the reaper's terminal flip / deferral.
No network, no subprocess — every external is mocked.
"""
import os
import tempfile
import pytest
# Override env before importing app modules (same convention as test_job_reaper.py).
os.environ["ORCH_DB_PATH"] = os.path.join(
tempfile.gettempdir(), "test_orch113_reaper.db"
)
os.environ["ORCH_REPOS_DIR"] = tempfile.gettempdir()
os.environ["ORCH_GITEA_TOKEN"] = "test-token"
os.environ["ORCH_PLANE_API_TOKEN"] = "test-token"
import src.db as db
from src.db import init_db, get_db, get_job
import src.finalizer_liveness as fl
import src.job_reaper as jr
from src.job_reaper import JobReaper
@pytest.fixture(autouse=True)
def fresh_db(tmp_path, monkeypatch):
dbfile = tmp_path / "reaper113.db"
monkeypatch.setattr(db.settings, "db_path", str(dbfile))
init_db()
# Each test starts with a clean ownership registry (process-local module state).
with fl._LOCK:
fl._OWNED.clear()
# Default: kill-switch ON (the fix is active) unless a test flips it.
monkeypatch.setattr(db.settings, "reaper_finalizer_liveness_enabled", True)
yield
with fl._LOCK:
fl._OWNED.clear()
# --- helpers ----------------------------------------------------------------
def _make_task(repo="orchestrator", branch="feature/orch113",
stage="deploy-staging", work_item_id="ORCH-113"):
conn = get_db()
cur = conn.execute(
"INSERT INTO tasks (plane_id, work_item_id, repo, branch, stage) "
"VALUES (?, ?, ?, ?, ?)",
(work_item_id, work_item_id, repo, branch, stage),
)
tid = cur.lastrowid
conn.commit()
conn.close()
return tid
def _make_running_job(agent="deployer", repo="orchestrator", task_id=None,
pid=None, age_s=0, attempts=0, max_attempts=2,
run_id=None, exit_code=0, finished_age_s=600):
"""Insert a job already in 'running' with a linked agent_runs row.
``finished_at`` is back-dated by ``finished_age_s`` so the Tier-2 grace
(default 300) is satisfied by default; pass a small value to stay within grace.
"""
conn = get_db()
if run_id is None and exit_code is not None:
cur = conn.execute(
"INSERT INTO agent_runs (task_id, agent, finished_at, exit_code) "
"VALUES (?, ?, datetime('now', ?), ?)",
(task_id, agent, f"-{int(finished_age_s)} seconds", exit_code),
)
run_id = cur.lastrowid
cur = conn.execute(
"INSERT INTO jobs (agent, repo, task_id, status, attempts, max_attempts, "
"run_id, pid, started_at) "
"VALUES (?, ?, ?, 'running', ?, ?, ?, ?, datetime('now', ?))",
(agent, repo, task_id, attempts, max_attempts, run_id, pid,
f"-{int(age_s)} seconds"),
)
job_id = cur.lastrowid
conn.commit()
conn.close()
return job_id
def _spy_advance(monkeypatch, side_effect=None):
"""Patch launcher._try_advance_stage with a call recorder.
Returns a mutable ``calls`` list. ``side_effect(run_id, agent, repo, branch)``
runs on each call (e.g. to simulate the false rollback to development).
"""
import src.agents.launcher as L
calls: list = []
def _fake(run_id, agent, repo, branch):
calls.append((run_id, agent, repo, branch))
if side_effect is not None:
side_effect(run_id, agent, repo, branch)
monkeypatch.setattr(L.launcher, "_try_advance_stage", _fake)
return calls
def _green_gate(monkeypatch):
"""Force the read-only canonical-QG pre-eval green (staging SUCCESS)."""
monkeypatch.setattr(JobReaper, "_gate_is_green",
lambda self, stage, job, branch, wid: True)
# --- TC-01: live finalizer on deploy-staging is NOT reaped (AC-1/FR-1) ------
def test_tc01_live_finalizer_deploy_staging_not_reaped(monkeypatch):
"""exit_code=0 and finished_age_s >= grace, but the finalizer is ALIVE (marked)
-> reaper does NOT call _try_advance_stage; the row stays running; defer logged."""
_green_gate(monkeypatch)
calls = _spy_advance(monkeypatch)
tid = _make_task(stage="deploy-staging")
jid = _make_running_job(task_id=tid, exit_code=0, finished_age_s=600)
# A live monitor owns this finalization.
fl.mark(jid, run_id=1, stage="deploy-staging")
r = JobReaper()
r.reap_once()
assert get_job(jid)["status"] == "running" # not reaped
assert calls == [] # no second advance
assert r.finalizer_defers_total == 1
assert r.reaped_total == 0
# --- TC-02: strict ownership — non-owner runs zero side effects (AC-2/FR-2) --
def test_tc02_non_owner_runs_no_edge_gates(monkeypatch):
"""While a live finalizer owns the (job, stage), a racing reaper tick performs
NO side-effectful advance/merge-gate/re-test (zero side effects)."""
_green_gate(monkeypatch)
calls = _spy_advance(monkeypatch)
tid = _make_task(stage="deploy-staging")
jid = _make_running_job(task_id=tid, exit_code=0, finished_age_s=900)
fl.mark(jid, run_id=7, stage="deploy-staging")
r = JobReaper()
# Several ticks while ownership is held — still zero advances, still running.
for _ in range(3):
r.reap_once()
assert calls == []
assert get_job(jid)["status"] == "running"
assert r.finalizer_defers_total == 3
# --- TC-03: a genuinely dead finalizer is still reaped (AC-3/FR-4) ----------
def test_tc03_dead_finalizer_still_reaped_tier2(monkeypatch):
"""No ownership marker (finalizer dead) -> reaper reaps via Tier-2 as before."""
_green_gate(monkeypatch)
calls = _spy_advance(monkeypatch)
tid = _make_task(stage="deploy-staging")
jid = _make_running_job(task_id=tid, exit_code=0, finished_age_s=600)
# No fl.mark() -> ownership absent (finalizer dead).
r = JobReaper()
r.reap_once()
assert get_job(jid)["status"] == "done" # reaped to done (gate green)
assert len(calls) == 1 # advance driven exactly once
assert r.finalizer_defers_total == 0
def test_tc03_tier3_backstop_ignores_marker(monkeypatch):
"""Even with an active ownership marker, a job past reaper_max_running_s is
reaped by the Tier-3 backstop (a stuck finalizer is never immortal)."""
monkeypatch.setattr(db.settings, "reaper_max_running_s", 1000)
tid = _make_task(stage="deploy-staging")
# age beyond the backstop ceiling; exit_code=0 within grace so Tier-2 defers,
# but Tier-3 must still fire.
jid = _make_running_job(task_id=tid, exit_code=0, finished_age_s=10,
age_s=2000, attempts=0, max_attempts=2)
fl.mark(jid, run_id=3, stage="deploy-staging")
r = JobReaper()
r.reap_once()
# Backstop reaps to a retry (attempts<max) -> queued, regardless of the marker.
assert get_job(jid)["status"] == "queued"
assert r.reaped_total == 1
# --- TC-04: idempotency under race — exactly-once advance (AC-2/AC-4/FR-2) ---
def test_tc04_idempotent_no_second_advance_under_race(monkeypatch):
"""Monitor finalizing (owns the job) + concurrent reaper ticks -> the heavy
edge-gate advance is NEVER duplicated by the reaper; no false rollback."""
rolled_back = {"hit": False}
def _rollback(run_id, agent, repo, branch):
# Simulate the incident: a second advance rolls back to development.
conn = get_db()
conn.execute("UPDATE tasks SET stage='development' WHERE branch=?", (branch,))
conn.commit()
conn.close()
rolled_back["hit"] = True
_green_gate(monkeypatch)
calls = _spy_advance(monkeypatch, side_effect=_rollback)
tid = _make_task(stage="deploy-staging")
jid = _make_running_job(task_id=tid, exit_code=0, finished_age_s=1200)
fl.mark(jid, run_id=9, stage="deploy-staging")
r = JobReaper()
for _ in range(5):
r.reap_once()
assert calls == [] # reaper never re-ran the advance
assert rolled_back["hit"] is False
# The task is NOT rolled back; the live finalizer remains the sole driver.
conn = get_db()
stage = conn.execute("SELECT stage FROM tasks WHERE id=?", (tid,)).fetchone()[0]
conn.close()
assert stage == "deploy-staging"
# --- TC-05: MANDATORY regression for incident ORCH-111 (AC-4/FR-5) ----------
def test_tc05_orch111_no_false_rollback_no_retry_increment(monkeypatch):
"""Long (> grace) deploy-staging finalization at staging_status=SUCCESS while
the deploy finalizer concurrently reaches success/merge -> reaper does NOT roll
back deploy-staging -> development and does NOT increment developer-retry; the
task keeps a single consistent state. RED before the fix, GREEN after."""
def _rollback(run_id, agent, repo, branch):
# Simulate the incident: a second advance rolls the task back to development
# and spawns a fresh developer run (the developer-retry count is derived from
# agent_runs — stage_engine.developer_retry_count).
conn = get_db()
conn.execute("UPDATE tasks SET stage='development' WHERE branch=?", (branch,))
_t = conn.execute("SELECT id FROM tasks WHERE branch=?", (branch,)).fetchone()
conn.execute(
"INSERT INTO agent_runs (task_id, agent) VALUES (?, 'developer')",
(_t[0],),
)
conn.commit()
conn.close()
from src.stage_engine import developer_retry_count
_green_gate(monkeypatch) # staging_status SUCCESS
calls = _spy_advance(monkeypatch, side_effect=_rollback)
tid = _make_task(stage="deploy-staging")
jid = _make_running_job(task_id=tid, exit_code=0, finished_age_s=1500)
# The original finalizer is still alive (running the heavy edge sub-gates).
fl.mark(jid, run_id=11, stage="deploy-staging")
r = JobReaper()
r.reap_once()
# No second advance => no false rollback, no developer-retry increment.
assert calls == []
conn = get_db()
stage = conn.execute("SELECT stage FROM tasks WHERE id=?", (tid,)).fetchone()[0]
conn.close()
assert stage == "deploy-staging" # NOT rolled back to development
assert developer_retry_count(tid) == 0 # developer-retry NOT incremented
assert get_job(jid)["status"] == "running"
assert r.finalizer_defers_total == 1
# --- TC-06: compatibility guard — kill-switch / non-deploy-staging (AC-5) ----
def test_tc06_killswitch_off_byte_for_byte_prior(monkeypatch):
"""Kill-switch OFF -> the marker is ignored; a deploy-staging exit0/past-grace
job is reaped exactly as before the fix (advance driven once)."""
monkeypatch.setattr(db.settings, "reaper_finalizer_liveness_enabled", False)
_green_gate(monkeypatch)
calls = _spy_advance(monkeypatch)
tid = _make_task(stage="deploy-staging")
jid = _make_running_job(task_id=tid, exit_code=0, finished_age_s=600)
fl.mark(jid, run_id=5, stage="deploy-staging") # marked, but ignored
r = JobReaper()
r.reap_once()
assert get_job(jid)["status"] == "done"
assert len(calls) == 1
assert r.finalizer_defers_total == 0
def test_tc06_non_deploy_staging_stage_not_consulted(monkeypatch):
"""A non-deploy-staging stage is never consulted -> reaped as before even when
an (irrelevant) marker happens to be present."""
_green_gate(monkeypatch)
calls = _spy_advance(monkeypatch)
tid = _make_task(stage="testing") # deployer also owns 'testing'
jid = _make_running_job(task_id=tid, agent="deployer", exit_code=0,
finished_age_s=600)
fl.mark(jid, run_id=6, stage="testing")
r = JobReaper()
r.reap_once()
assert get_job(jid)["status"] == "done"
assert len(calls) == 1
assert r.finalizer_defers_total == 0
def test_tc06_within_grace_unchanged(monkeypatch):
"""Within the finalization grace the Tier-2 path is unchanged (deferred, not
reaped) regardless of the marker — the fix only acts PAST the grace."""
monkeypatch.setattr(db.settings, "reaper_finalize_grace_s", 300)
_green_gate(monkeypatch)
calls = _spy_advance(monkeypatch)
tid = _make_task(stage="deploy-staging")
jid = _make_running_job(task_id=tid, exit_code=0, finished_age_s=5) # < grace
r = JobReaper()
r.reap_once()
assert get_job(jid)["status"] == "running"
assert calls == []
# Within-grace deferral is the legacy path, not a finalizer-liveness defer.
assert r.finalizer_defers_total == 0
# --- TC-07: cross-cutting budget invariant (NFR-6/AC-5) ---------------------
def test_tc07_budget_invariant_preserved():
"""reaper_max_running_s (5400) > Σ(deploy-staging gate-work) + grace; the fix
changed neither the grace nor the ceiling (ORCH-065/109/110 invariant)."""
s = jr.settings
# The fix did not touch these (zero schema/budget change).
assert s.reaper_finalize_grace_s == 300
assert s.reaper_max_running_s == 5400
# Conservative Σ of the heavy deploy-staging gate-work + grace must fit.
sigma = s.merge_retest_timeout_s + s.coverage_run_timeout_s
assert s.reaper_max_running_s > sigma + s.reaper_finalize_grace_s
# --- TC-08: never-raise — a fault in the liveness path degrades safely -------
def test_tc08_liveness_error_never_breaks_tick(monkeypatch):
"""An exception inside the ownership consultation must not crash the tick; the
job is still processed (conservatively reaped, never blocked)."""
def _boom(job_id):
raise RuntimeError("registry exploded")
monkeypatch.setattr(fl, "is_active", _boom)
_green_gate(monkeypatch)
calls = _spy_advance(monkeypatch)
tid = _make_task(stage="deploy-staging")
jid = _make_running_job(task_id=tid, exit_code=0, finished_age_s=600)
fl.mark(jid, run_id=2, stage="deploy-staging")
r = JobReaper()
r.reap_once() # must not raise
# is_active raised -> _finalizer_owns conservatively returns False -> reaped.
assert get_job(jid)["status"] == "done"
assert len(calls) == 1
def test_tc08_reap_once_isolates_and_never_raises(monkeypatch):
"""A fault while resolving one job's metadata is isolated; reap_once never
raises and other jobs are still processed."""
def _boom(self, job):
raise RuntimeError("meta exploded")
monkeypatch.setattr(JobReaper, "_task_meta", _boom)
tid = _make_task(stage="deploy-staging")
_make_running_job(task_id=tid, exit_code=0, finished_age_s=600)
r = JobReaper()
r.reap_once() # outer + per-job never-raise -> no exception propagates
def test_tc08_finalizer_liveness_leaf_never_raises():
"""The leaf degrades safely on bad input / None job_id."""
fl.mark(None, None, None) # no-op, no raise
fl.clear(None) # no-op, no raise
assert fl.is_active(None) is False
fl.mark(1234, 1, "deploy-staging")
assert fl.is_active(1234) is True
snap = fl.snapshot()
assert snap["active"] >= 1 and 1234 in snap["jobs"]
fl.clear(1234)
assert fl.is_active(1234) is False