Compare commits

..

34 Commits

Author SHA1 Message Date
1c89ac9df9 tester(ET): auto-commit from tester run_id=313
All checks were successful
CI / test (push) Successful in 19s
CI / test (pull_request) Successful in 17s
2026-06-07 14:40:06 +00:00
03d899812c reviewer(ET): auto-commit from reviewer run_id=312 2026-06-07 14:40:06 +00:00
b9bcdc1545 fix(deploy): drop COPY data/ from Dockerfile so worktree-context staging build succeeds
The ORCH-058 staging rebuild (check_staging_image_fresh) builds the image with
the task git-worktree as the docker build context. A fresh worktree holds only
tracked files, but the Dockerfile did `COPY data/ ./data/` — and `data/` (the
SQLite dir) is gitignored, so it is absent from that context: `docker build`
failed with exit 1 ("BUILD-STAGING: docker build failed - aborting"), bouncing
the task off deploy-staging back to development in a loop.

The COPY was dead weight regardless: `data/` is always supplied at runtime as a
bind-mount volume (./data:/app/data, see docker-compose.yml) which shadows
anything baked into the image. Replace it with `RUN mkdir -p /app/data` so the
mountpoint exists without depending on the build context.

Regression guard: test_tc08b_dockerfile_does_not_copy_gitignored_data_dir
forbids COPY of any gitignored path (the worktree-context invariant).

Refs: ORCH-021

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-06-07 14:40:06 +00:00
b04fae748e tester(ET): auto-commit from tester run_id=309 2026-06-07 14:40:06 +00:00
fbfcd84b16 reviewer(ET): auto-commit from reviewer run_id=308 2026-06-07 14:40:06 +00:00
2f4c553fd8 feat(post-deploy): post-deploy prod monitoring + degradation reaction (ORCH-021)
Extend pipeline responsibility past deploy->done: after the terminal
transition for an applicable repo, arm a ~15min observation window that
probes prod and reacts to a degradation the restart-time health-check
missed ("green deploy, red prod").

- src/post_deploy.py: new leaf module (config + lazy qg/db only).
  Sentinel-file restart-safe state (.post-deploy-state-<repo>/<wi>/),
  no DB migration. probe_signals/classify/decide_action/run_rollback,
  all never-raise.
- Reserved-agent job `post-deploy-monitor` (no-LLM, Variant B, calque of
  deploy-finalizer): self-requeues each tick via enqueue_job.
- Deterministic classify: DEGRADED iff >= fail_threshold consecutive
  health failures OR window 5xx ratio > 5xx_threshold; fail-safe HEALTHY.
- Self-hosting invariant (BR-5/AC-8): a tick NEVER restarts the prod
  orchestrator container -> orchestrator is ALWAYS ALERT_ONLY.
- Conditionality (ORCH-35/36/43/58): kill-switch + CSV repos, empty ->
  self-hosting only.
- QG_CHECKS / STAGE_TRANSITIONS / schema unchanged (AC-12).
- Docs: CHANGELOG, CLAUDE artefact list (16-post-deploy-log.md),
  architecture README, .env.example (ORCH_POST_DEPLOY_*).

Refs: ORCH-021

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-06-07 14:40:06 +00:00
2bdba532d5 architect(ET): auto-commit from architect run_id=306 2026-06-07 14:40:06 +00:00
db83b89467 analyst(ET): auto-commit from analyst run_id=305 2026-06-07 14:40:06 +00:00
961c5e9eee docs: init ORCH-021 business request 2026-06-07 14:40:06 +00:00
84a6f61ba8 docs(ORCH-021): staging gate SUCCESS — refresh 15-staging-log timestamp
Re-ran staging_check inside orchestrator-staging (exit 0); all REAL checks
green, C9a/C9b waived per ORCH-061.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-06-07 14:39:48 +00:00
1af356a343 docs(ORCH-021): staging gate SUCCESS — REAL green, C9a/C9b infra-waived
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-06-07 14:25:00 +00:00
e18947d2d9 Merge pull request 'fix(staging): tolerate sandbox-infra-only FAILs (C9a/C9b) in deploy-staging verdict (ORCH-061)' (#62) from feature/ORCH-061-bug-deploy-staging-development into main
Some checks failed
CI / test (push) Has been cancelled
2026-06-07 16:30:07 +03:00
0ec34d10fc Merge pull request 'docs(ORCH-061): staging gate SUCCESS — C9a/C9b infra-waived' (#63) from docs/ORCH-061-staging-log into main 2026-06-07 16:29:55 +03:00
bf6a0c095a docs(ORCH-061): staging gate SUCCESS — REAL green, C9a/C9b infra-waived
All checks were successful
CI / test (pull_request) Successful in 16s
Validated ORCH-061 infra-tolerance against live staging (8501): all REAL
checks pass, only sandbox-infra C9a/C9b fail and are waived → exit 0.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-06-07 13:29:33 +00:00
39769bdf23 tester(ET): auto-commit from tester run_id=300
All checks were successful
CI / test (push) Successful in 17s
CI / test (pull_request) Successful in 17s
2026-06-07 13:21:17 +00:00
de47737f4f reviewer(ET): auto-commit from reviewer run_id=299
All checks were successful
CI / test (push) Successful in 16s
CI / test (pull_request) Successful in 15s
2026-06-07 13:18:47 +00:00
stream
e3f7c1c272 ci: re-trigger after gitea restart (ORCH-061)
All checks were successful
CI / test (push) Successful in 16s
CI / test (pull_request) Successful in 17s
2026-06-07 13:14:14 +00:00
stream
32a7aa8c6b ci: trigger re-run after host disk cleanup (ORCH-061) 2026-06-07 13:08:38 +00:00
stream
fe8586ed78 ci: re-run after host disk cleanup (ORCH-061) 2026-06-07 13:04:38 +00:00
9070489968 fix(staging): tolerate sandbox-infra-only FAILs (C9a/C9b) in deploy-staging verdict
Some checks failed
CI / test (push) Failing after 39s
CI / test (pull_request) Failing after 35s
The self-hosting orchestrator looped on deploy-staging -> development because
scripts/staging_check.py exited 1 on ANY failed check, so two infra-only checks
(C9a sandbox branch / C9b analyst-job — caused by SANDBOX bot accounts not being
members of the sandbox Plane project, NOT a pipeline regress) forced
staging_status: FAILED -> rollback -> loop, burning developer retries and tokens.

Direction (б) per ADR-001: classify staging checks as REAL (all pipeline checks,
fail-closed) vs SANDBOX_INFRA (narrow allowlist {C9a, C9b}, waivable). New leaf
module src/staging_verdict.py (stdlib-only, never-raise): classify_check +
compute_staging_verdict fold per-check results into a tolerant-but-fail-closed
verdict — any REAL failure -> FAILED/exit1 (safety net holds under any flag);
only C9a/C9b failed & tolerant -> SUCCESS/exit0 with waived list; only infra &
strict -> FAILED/exit1; any internal error -> FAILED/exit1 (never a false green).

staging_check.py now auto-classifies each check (public 3-tuple _items shape kept
as an ORCH-048 b6 regression guard), exposes categorized_items(), prints
INFRA-WAIVED/VERDICT lines, and exits via the verdict; new --strict flag forces
legacy strictness per-run. Kill-switch ORCH_STAGING_INFRA_TOLERANCE_ENABLED
(default true) restores legacy strict mode globally. launcher gains
action_stage_no_changes_note so "no changes to commit" on action stages is logged
as expected, not treated as under-delivery.

Contracts unchanged: STAGE_TRANSITIONS, QG_CHECKS registry, staging_status:/
deploy_status: frontmatter, hook exit-code (0/1/2), check_staging_status; no DB
migration. Docs: README, STAGING_CHECK.md, deployer.md, .env.example, CHANGELOG.

Refs: ORCH-061

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-06-07 12:39:00 +00:00
1d1208c136 architect(ET): auto-commit from architect run_id=297
All checks were successful
CI / test (push) Successful in 18s
2026-06-07 12:22:46 +00:00
3ab2690a68 analyst(ET): auto-commit from analyst run_id=296
All checks were successful
CI / test (push) Successful in 16s
2026-06-07 12:10:46 +00:00
3806522041 docs: init ORCH-061 business request
All checks were successful
CI / test (push) Successful in 17s
2026-06-07 15:05:55 +03:00
d4c6cc0f61 Merge pull request 'fix(reconciler): skip escalated / Blocked / Needs-Input tasks in F-1 (ORCH-060)' (#60) from feature/ORCH-060-reconciler-escalated-max-retri into main
Some checks failed
CI / test (push) Has been cancelled
2026-06-07 15:01:11 +03:00
210aef6954 deployer(ET): auto-commit from deployer run_id=293
All checks were successful
CI / test (push) Successful in 17s
CI / test (pull_request) Successful in 16s
2026-06-07 11:59:00 +00:00
1820b0244e Merge pull request 'docs(ORCH-060): staging gate FAILED (8/10) — C9a/C9b E2E' (#61) from docs/ORCH-060-staging-log into main 2026-06-07 14:58:44 +03:00
2f898ede7b docs(ORCH-060): staging gate FAILED (8/10) — C9a/C9b E2E
All checks were successful
CI / test (pull_request) Successful in 17s
Canonical staging_check run inside orchestrator-staging container
(ORCH-048). Exit code 1: branch never appeared in sandbox (C9a) and
analyst job never enqueued (C9b). staging_status: FAILED → rollback
to development per ORCH-35.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-06-07 11:58:29 +00:00
829b914ff7 tester(ET): auto-commit from tester run_id=292
All checks were successful
CI / test (push) Successful in 17s
CI / test (pull_request) Successful in 16s
2026-06-07 11:54:59 +00:00
55e5e968ae reviewer(ET): auto-commit from reviewer run_id=291
All checks were successful
CI / test (push) Successful in 16s
CI / test (pull_request) Successful in 22s
2026-06-07 11:53:34 +00:00
4db8276f98 fix(reconciler): skip escalated / Blocked / Needs-Input tasks in F-1
All checks were successful
CI / test (push) Successful in 16s
CI / test (pull_request) Successful in 16s
Reconciler F-1 could not tell "stuck by a lost webhook" from "escalated:
max developer retries reached, waiting for a human". With CI green and a
reviewer that kept sending REQUEST_CHANGES up to the cap, every tick
re-unblocked development -> review -> rollback -> re-unblock (incident
ET-013, infinite bounce: wasted agent runs, Telegram spam, parasitic load
on the shared self-hosting instance).

Add two pre-gate guards in Reconciler._reconcile_gate_task (after the
existing analysis/no-gate/active-job/grace guards, before the gate
pre-evaluation), each an early silent return (no advance, no unblocked_total
increment, no notifications):
- Guard 1 (escalated, deterministic, no network, checked first):
  developer_retry_count(task_id) >= MAX_DEVELOPER_RETRIES. Promote
  stage_engine._developer_retry_count to public developer_retry_count
  (single source of truth; private alias kept). Limit from the constant,
  not a literal 3.
- Guard 2 (explicit human Plane gate, Variant A, no DB migration): new
  never-raise plane_sync.fetch_issue_state + Reconciler._is_blocked_or_needs_input;
  any error/None/unresolved project -> conservative skip. New sub-flag
  ORCH_RECONCILE_SKIP_BLOCKED_ENABLED mutes only the networked Guard 2.

F-2 unchanged: Blocked/Needs Input are outside {in_progress, approved,
rejected} so they are never replayed (regression test added). DB schema,
STAGE_TRANSITIONS, QG_CHECKS, never-raise, analysis carve-out and
kill-switches untouched.

Refs: ORCH-060

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-06-07 11:50:02 +00:00
efe437a4aa architect(ET): auto-commit from architect run_id=289
All checks were successful
CI / test (push) Successful in 16s
2026-06-07 11:41:02 +00:00
365c67f45d analyst(ET): auto-commit from analyst run_id=288
All checks were successful
CI / test (push) Successful in 17s
2026-06-07 11:28:57 +00:00
d6e0df3550 docs: init ORCH-060 business request
All checks were successful
CI / test (push) Successful in 17s
2026-06-07 14:24:00 +03:00
4d4f542b71 Merge pull request '#59 staging gate FAILED — corrected root cause' into main
Some checks failed
CI / test (push) Has been cancelled
2026-06-07 14:05:59 +03:00
69 changed files with 5772 additions and 16 deletions

View File

@@ -85,6 +85,16 @@ ORCH_DEPLOY_PROD_PREV_IMAGE_FILE=.deploy-prev-image-prod
ORCH_IMAGE_FRESHNESS_ENABLED=true
ORCH_IMAGE_FRESHNESS_REPOS=
# ORCH-061: staging-verdict tolerance to sandbox-infra-only FAILs. The self-hosting
# orchestrator looped on deploy-staging because staging_check.py exited 1 on ANY FAIL,
# so two infra-only checks (C9a sandbox branch / C9b analyst-job — caused by SANDBOX
# bot accounts not being members of the sandbox Plane project, NOT a pipeline regress)
# forced staging_status: FAILED -> rollback -> loop. With this ON, C9a/C9b are WAIVED
# to SUCCESS when every REAL check is green; any REAL failure still fails closed.
# true (default) -> tolerant; false -> legacy strict (1:1 pre-ORCH-061, any FAIL rolls back).
# Lives in .env.staging (the staging instance). CLI --strict overrides this per-run.
ORCH_STAGING_INFRA_TOLERANCE_ENABLED=true
# ORCH-053: stuck-task reconciler (sweeper for lost webhooks). A background daemon
# replays a missed stage transition through the SAME gates/handlers a webhook would,
# fixing tasks that got stuck on a dropped event (502 on rebuild, no Plane/Gitea
@@ -95,9 +105,38 @@ ORCH_IMAGE_FRESHNESS_REPOS=
# GRACE_DEFAULT_S -> default "stuck" threshold on tasks.updated_at (seconds).
# GRACE_OVERRIDES_JSON -> per-stage thresholds, e.g. {"development":300}; bad JSON -> default.
# NOTIFY_UNBLOCK -> send a Telegram message when a stuck task is unblocked.
# SKIP_BLOCKED_ENABLED -> ORCH-060 F-1 Guard 2: skip reconciling issues a human moved
# to Blocked / Needs Input (per-candidate Plane state lookup).
# false mutes ONLY the networked Guard 2; Guard 1 (escalated by
# developer retries, local+deterministic) is always active.
ORCH_RECONCILE_ENABLED=true
ORCH_RECONCILE_PLANE_ENABLED=true
ORCH_RECONCILE_INTERVAL_S=120
ORCH_RECONCILE_GRACE_DEFAULT_S=600
ORCH_RECONCILE_GRACE_OVERRIDES_JSON=
ORCH_RECONCILE_NOTIFY_UNBLOCK=true
ORCH_RECONCILE_SKIP_BLOCKED_ENABLED=true
# ORCH-021: post-deploy production monitoring + degradation reaction. After the
# terminal deploy->done transition for an applicable repo, a reserved-agent job
# `post-deploy-monitor` (no LLM, modelled on deploy-finalizer) probes prod over a
# window and reacts to a degradation the restart-time health-check missed (class
# "green deploy, red prod", precedent ET-8). State is in sentinel files
# (.post-deploy-state-<repo>/<wi>/), no DB migration.
# MONITOR_ENABLED -> global kill-switch; false -> pipeline is 1:1 as before ORCH-021.
# REPOS -> CSV of repos where monitoring is REAL; empty -> only self-hosting.
# WINDOW_S -> observation window length (~15 min).
# INTERVAL_S -> seconds between probe ticks.
# FAIL_THRESHOLD -> N CONSECUTIVE health failures -> DEGRADED.
# 5XX_THRESHOLD -> window 5xx ratio above this -> DEGRADED.
# AUTO_ROLLBACK -> allow auto-rollback; acts ONLY for non-self repos. Self-hosting
# is ALWAYS ALERT_ONLY (a tick NEVER restarts the prod container).
# BASE_URL -> base URL of the observed prod instance.
ORCH_POST_DEPLOY_MONITOR_ENABLED=true
ORCH_POST_DEPLOY_REPOS=
ORCH_POST_DEPLOY_WINDOW_S=900
ORCH_POST_DEPLOY_INTERVAL_S=30
ORCH_POST_DEPLOY_FAIL_THRESHOLD=3
ORCH_POST_DEPLOY_5XX_THRESHOLD=0.5
ORCH_POST_DEPLOY_AUTO_ROLLBACK=false
ORCH_POST_DEPLOY_BASE_URL=http://localhost:8500

View File

@@ -37,8 +37,19 @@ On stage `deploy-staging` your job is to run the staging test suite and write a
not exist. Details: `docs/operations/STAGING_CHECK.md`.
2. Check the exit code:
- Exit code **0** = all tests PASS → `staging_status: SUCCESS`
- Exit code **non-zero** = tests FAILED → `staging_status: FAILED`
- Exit code **0** = advance → `staging_status: SUCCESS`
- Exit code **non-zero** = rollback → `staging_status: FAILED`
> **ORCH-061**: exit 0 may now include *waived* sandbox-infra failures. The two
> infra-only checks **C9a/C9b** (sandbox branch / analyst-job, which depend on
> SANDBOX bot accounts being project members — not on the pipeline) are tolerated
> when every REAL check is green; the script prints an `INFRA-WAIVED:` line and a
> `VERDICT:` line, and still exits 0. Any REAL check failing still yields exit 1
> (fail-closed). If you see `INFRA-WAIVED:` in the output, copy that line into the
> `15-staging-log.md` body for observability. The exit-code → `staging_status`
> mapping above is unchanged: trust the exit code, do NOT re-judge waived checks.
> Kill-switch: `ORCH_STAGING_INFRA_TOLERANCE_ENABLED=false` (or `--strict`) restores
> legacy strictness. Details: `docs/operations/STAGING_CHECK.md`.
3. Write the verdict to `docs/work-items/<work_item_id>/15-staging-log.md` with YAML frontmatter:
```markdown

4
.task-arch.md Normal file
View File

@@ -0,0 +1,4 @@
Work item: ORCH-061
Repo: orchestrator
Branch: feature/ORCH-061-bug-deploy-staging-development
Stage: architecture

4
.task-dev.md Normal file
View File

@@ -0,0 +1,4 @@
Work item: ORCH-061
Repo: orchestrator
Branch: feature/ORCH-061-bug-deploy-staging-development
Stage: development

8
.task.md Normal file
View File

@@ -0,0 +1,8 @@
Work item: ORCH-061
Repo: orchestrator
Branch: feature/ORCH-061-bug-deploy-staging-development
Stage: analysis
Title: BUG: deploy-staging петля — откат на development (self-deploy)
Description:
Симптом: на стадии deploy-staging для self-hosting orchestrator задача откатывается deploy-staging -> development и крутится по кругу.ДВЕ подтверждённые причины (ORCH-58 + ORCH-60):1. check_staging_status FAILED (ложный). deployer гоняет staging_check.py, тот падает на C9a/C9b (sandbox e2e: branch not found + analyst job in queue) с пометкой «Plane comment check skipped: bot-tokens not added to SANDBOX project». 8/10 PASS, 2 ложных FAIL из-за ненастроенных bot-токенов SANDBOX-проекта. QG check_staging_status -> FAILED -> rollback deploy-staging->development. Это НЕ регресс кода, а отсутствие sandbox-настроек.2. no changes to commit. для action-стадий (деплой = рестарт/retag, не правка кода) deployer exit0 + «no changes» тоже трактуется stage_engine как недовыполнение -> откат.Последствие: прод-деплой self-hosting репо НЕВОЗМОЖЕН автономно — ORCH-58 и ORCH-60 доводились ВРУЧНУЮ (merge PR + build-once retag + --deploy). Прямой блокер автономного внедрения (эпик ORCH-54).Fix-направления (одно или оба):(а) Настроить sandbox bot-токены в SANDBOX Plane-проект, чтобы staging_check C9a/C9b проходили честно (10/10). Тогда check_staging_status не будет ложно падать.(б) Отвязать advance deploy-стадии от git-changes для self-deploy репо: успех = exit0 + health PASS (+ опц. staging_check), а не наличие коммита.Acceptance: ORCH-задача для self-hosting orchestrator проходит deploy-staging -> deploy -> Done БЕЗ ручного вмешательства и без петли. Priority P0.

File diff suppressed because one or more lines are too long

View File

@@ -47,7 +47,7 @@ created → analysis → architecture → development → review → testing →
- Машинные вердикты Quality Gate — строго YAML-frontmatter (`verdict:`, `deploy_status:`, `staging_status:`), никогда проза
## Артефакты задачи (`docs/work-items/<plane-id>/`)
`00-business-request.md`, `01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`, `04-test-plan.yaml`, `06-adr/ADR-NNN-slug.md`, `07-infra-requirements.md`, `08-data-requirements.md`, `10-tech-risks.md`, `12-review.md`, `13-test-report.md`, `14-deploy-log.md`, `15-staging-log.md`.
`00-business-request.md`, `01-brd.md`, `02-trz.md`, `03-acceptance-criteria.md`, `04-test-plan.yaml`, `06-adr/ADR-NNN-slug.md`, `07-infra-requirements.md`, `08-data-requirements.md`, `10-tech-risks.md`, `12-review.md`, `13-test-report.md`, `14-deploy-log.md`, `15-staging-log.md`, `16-post-deploy-log.md` (post-deploy наблюдение, ORCH-021).
## Правила для агентов
1. Перед любым действием прочесть этот файл и `docs/architecture/README.md`.

View File

@@ -20,6 +20,13 @@ RUN groupadd -g 1000 app && useradd -u 1000 -g 1000 -m -d /home/slin -s /bin/bas
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY src/ ./src/
COPY data/ ./data/
# ORCH-021: do NOT `COPY data/ ./data/`. `data/` is gitignored (SQLite DB dir) and
# is provided at runtime as a bind-mount volume (`./data:/app/data`, see
# docker-compose.yml) which shadows anything baked into the image — so the COPY was
# dead weight. Worse, the ORCH-058 staging rebuild (`check_staging_image_fresh`)
# builds with the task *worktree* as the docker build context; a fresh worktree never
# contains the untracked `data/`, so `COPY data/` failed `docker build` with exit 1
# and bounced the task off `deploy-staging`. We just ensure the mountpoint exists.
RUN mkdir -p /app/data
ENV PYTHONPATH=/app
CMD ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8500"]

View File

@@ -135,6 +135,7 @@ uvicorn src.main:app --reload --port 8500
| `ORCH_RECONCILE_GRACE_DEFAULT_S` | Порог «застряла» по `tasks.updated_at`, сек | `600` |
| `ORCH_RECONCILE_GRACE_OVERRIDES_JSON` | Per-stage пороги, напр. `{"development":300}` | `""` |
| `ORCH_RECONCILE_NOTIFY_UNBLOCK` | Telegram при разблокировке застрявшей задачи | `true` |
| `ORCH_RECONCILE_SKIP_BLOCKED_ENABLED` | F-1 Guard 2 (ORCH-060): пропуск задач в Plane-статусе Blocked / Needs Input; `false` глушит только сетевой Guard 2 (Guard 1 escalated всегда активен) | `true` |
## Очередь задач (ORCH-1 / F-2b)

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.
- **Queue** (`src/queue_worker.py`, ORCH-1) — персистентная очередь задач (SQLite `jobs`), atomic claim, max_concurrency, ретраи, restart-safe.
- **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 не трогает (человеческий гейт). Наблюдаемость — блок `reconcile` в `GET /queue`.
- **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`.
- **Project Registry** (`src/projects.py`, ORCH-6) — Plane project id → repo + prefix; фильтрация вебхуков по проекту.
- **Plane Sync** (`src/plane_sync.py`) — синхронизация статусов/комментариев в Plane.
@@ -42,6 +42,16 @@ created → analysis → architecture → development → review → testing →
### Условный staging-гейт (ORCH-35)
`check_staging_status` реален только для self-hosting (`is_self_hosting_repo(repo)``orchestrator`); для остальных проектов → no-op `(True, "Staging gate N/A")`. Для orchestrator парсит `staging_status:` из `15-staging-log.md`; FAILED → откат на `development`. Подробнее: [ADR-0003](adr/adr-0003-staging-gate.md).
### Толерантность staging-вердикта к инфра-FAIL (ORCH-061 — design)
Self-hosting зацикливался на `deploy-staging`: `scripts/staging_check.py` давал ложный FAILED на C9a/C9b (ветка в sandbox / analyst-job в очереди), вызванный **отсутствием sandbox-настроек** (bot-аккаунты не члены SANDBOX-проекта), а не регрессом кода → откат `deploy-staging → development` → петля. ORCH-061 классифицирует проверки suite на **REAL** (pipeline) и **SANDBOX_INFRA** (узкий allowlist `{C9a, C9b}`) и делает вердикт толерантным к инфра-FAIL, сохраняя fail-closed для реальных проверок:
- Чистая логика — leaf-модуль `src/staging_verdict.py` (`classify_check`, `compute_staging_verdict`, never-raise). Упала хоть одна REAL → FAILED/exit1; упали ТОЛЬКО SANDBOX_INFRA и толерантность вкл → SUCCESS/exit0 (waived); waiver применяется только когда все REAL (вкл. C7/C8) зелёные.
- `scripts/staging_check.py` помечает проверки категориями, считает вердикт через `staging_verdict`, печатает `INFRA-WAIVED` (наблюдаемость).
- Kill-switch `staging_infra_tolerance_enabled` (env `ORCH_STAGING_INFRA_TOLERANCE_ENABLED`, дефолт `true`, в `.env.staging`); `false` → 1:1 прежнее строгое поведение.
- `check_staging_status` / `_parse_staging_status` / `STAGE_TRANSITIONS` / реестр `QG_CHECKS`**без изменений** (новый QG-чек не вводится); условность ORCH-35 и схема БД сохранены.
- Инвариант: «no changes to commit» на action-стадиях (`deploy-staging`/`deploy`) не есть недовыполнение — продвижение определяется exit0 + гейт-вердиктом (launcher не откатывает; добавлена observability-строка).
Подробнее: [adr-0009](adr/adr-0009-staging-infra-tolerance.md), детально — `docs/work-items/ORCH-061/06-adr/ADR-001-staging-infra-tolerance.md`.
### Merge-gate: догон `main` + re-test + сериализация слияний (ORCH-043)
Детерминированный под-гейт (`check_branch_mergeable`, без LLM) на ребре **`deploy-staging → deploy`**: исполняется ПОСЛЕ `check_staging_status` и ДО запуска deployer'а, который вливает PR в `main` (deployer мержит в начале стадии `deploy`). Стадии (`STAGE_TRANSITIONS`) НЕ меняются — это «под-гейт» ребра, а не отдельная стадия (триггер — то же событие «staging-deployer завершился»).
@@ -81,6 +91,42 @@ 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`.
### Post-deploy наблюдение прода + реакция на деградацию (ORCH-021 — реализовано)
Конвейер заканчивался на `deploy → done` и **забывал про прод**: «успех» = health-check
в момент рестарта (~60с). Класс «зелёный деплой, красный прод» (прецедент ET-8 —
деградация через минуты под трафиком, health `200 ok`, фича сломана). ORCH-021 продлевает
ответственность **ЗА** `done`: для применимого репо после терминального перехода армится
наблюдение окна `post_deploy_window_s` (~15 мин) с интервалом `post_deploy_interval_s`;
деградация фиксируется по детерминированным порогам, при подтверждении — реакция.
Механизм — **reserved-agent job `post-deploy-monitor`** (калька `deploy-finalizer`, НЕ
стадия и НЕ daemon): арм в `advance_stage` в блоке `next_stage == "done"`
(`post_deploy.arm_monitor`, sentinel `armed` = идемпотентность); тик перехватывается в
`launcher.launch_job` ДО `_spawn``stage_engine.run_post_deploy_monitor` (один опрос →
append в `series` → классификация → перепостановка с задержкой ИЛИ реакция+артефакт+`done`).
Чистая логика — новый leaf-модуль `src/post_deploy.py` (never-raise): `post_deploy_applies`,
`probe_signals` (`/health` 200+`{"status":"ok"}` + доля 5xx на `/status`,`/queue`),
`classify` (HEALTHY|DEGRADED — главный предмет юнит-тестов), `decide_action`,
sentinel-state, `write_post_deploy_log`.
- **Пороги (BR-3):** `DEGRADED``≥ post_deploy_fail_threshold` ПОСЛЕДОВАТЕЛЬНЫХ провалов
health ИЛИ доля 5xx `> post_deploy_5xx_threshold`; одиночный глюк → HEALTHY (нет ложных
откатов).
- **Реакция:** self-hosting (`orchestrator`) — ВСЕГДА `ALERT_ONLY` (Telegram+Plane, ручной
approve; тик НИКОГДА не откатывает/рестартит прод-контейнер); не-self +
`post_deploy_auto_rollback=true` → хук `--rollback` (`0→ROLLBACK_OK`,
`1/2→ROLLBACK_FAILED`+алерт); дефолт → `ALERT_ONLY`.
- **Артефакт** `16-post-deploy-log.md` (YAML-frontmatter `post_deploy_status`/
`action_taken`/…) — машиночитаемо для петли уроков ORCH-8; best-effort.
- **Наблюдаемость** — блок `post_deploy` в `GET /queue` (образец `reconcile`).
- **Инварианты:** `STAGE_TRANSITIONS`, `QG_CHECKS`, `check_deploy_status`, terminal-sync,
merge-gate, exit-коды хука (0/1/2), схема БД — НЕ меняются. Restart-safe (sentinel
`.post-deploy-state-<repo>/<wi>/` + jobs-очередь). Kill-switch
`post_deploy_monitor_enabled`, область `post_deploy_repos` (пусто → self-hosting).
Условность как ORCH-35/36/43/58.
Подробнее: [adr-0010](adr/adr-0010-post-deploy-monitor.md), детально —
`docs/work-items/ORCH-021/06-adr/ADR-001-post-deploy-monitor.md`.
### Свежесть артефакта BUILD-ONCE: провенанс staging-образа (ORCH-058 — реализовано)
BUILD-ONCE retag (ORCH-36) промоутит `SOURCE_IMAGE=orchestrator-orchestrator-staging` в прод
**без rebuild**, полагаясь на «staging-образ свеж и провалидирован». Этой гарантии нет:
@@ -118,6 +164,13 @@ helper `validated_revision` питает и штамп A, и `EXPECTED_REVISION`
`age(updated_at) ≥ grace_for_stage(stage)` — read-only пред-оценка канонического QG;
зелёный → `stage_engine.advance_stage(..., finished_agent=None)`; красный →
тишина (спам нотификаций структурно невозможен). `analysis` не реконсилируется.
**Skip escalated / Blocked / Needs-Input (ORCH-060):** ДО оценки гейта F-1
пропускает (молча, без advance/нотификаций) задачи, которые ждут человека —
(1) исчерпавшие лимит developer-ретраев (`developer_retry_count(task_id) >=
MAX_DEVELOPER_RETRIES`, детерминированно, без сети — закрывает bounce-петлю
ET-013) и (2) в явном Plane-статусе **Blocked** / **Needs Input** (Вариант A —
запрос Plane API, без миграции БД; never-raise → консервативный skip). Гард
retry-count проверяется первым (дёшево, локальный SQL).
- **F-2 plane-side:** опрос Plane API per-project → `handle_status_start` /
`handle_verdict` из `webhooks/plane.py` (логика не дублируется).
- **F-3:** усиление `sha→branch` в `handle_ci_status` (БД-fallback по единственной
@@ -180,7 +233,7 @@ never-raise на единицу работы; тишина при синхрон
|--------|------|----------|
| GET | `/health` | health check |
| GET | `/status` | активные задачи (stage != done) |
| GET | `/queue` | очередь: counts + max_concurrency + resilience + reconcile (ORCH-053) + последние jobs |
| GET | `/queue` | очередь: counts + max_concurrency + resilience + reconcile (ORCH-053) + post_deploy (ORCH-021) + последние jobs |
| POST | `/webhook/plane` | Plane webhook |
| POST | `/webhook/gitea` | Gitea webhook (push, PR, CI status) |
@@ -194,4 +247,4 @@ never-raise на единицу работы; тишина при синхрон
Схема БД, потоки данных, resilience-слой, детали Dockerfile — [internals.md](internals.md).
---
*Актуально на 2026-06-07. Обновлять при изменении src/stages.py, src/qg/checks.py, src/main.py. Статусы доработок: ORCH-036 (исполняемый самодеплой `deploy`, adr-0007) — реализовано; ORCH-043 (merge-gate, adr-0006) — design, ветка feature/ORCH-043; ORCH-053 (reconciler, adr-0007, src/reconciler.py) — реализовано; ORCH-058 (провенанс staging-образа: check_staging_image_fresh + staging_check свежего образа + хук-guard, adr-0008) — реализовано в ветке feature/ORCH-058 (обновлять также при изменении src/image_freshness.py, scripts/orchestrator-deploy-hook.sh, Dockerfile).*
*Актуально на 2026-06-07. Обновлять при изменении src/stages.py, src/qg/checks.py, src/main.py. Статусы доработок: ORCH-036 (исполняемый самодеплой `deploy`, adr-0007) — реализовано; ORCH-043 (merge-gate, adr-0006) — design, ветка feature/ORCH-043; ORCH-053 (reconciler, adr-0007, src/reconciler.py) — реализовано; ORCH-060 (F-1 skip escalated/Blocked/Needs-Input, `docs/work-items/ORCH-060/06-adr/ADR-001`) — реализовано в ветке feature/ORCH-060 (Guard 1 `developer_retry_count>=MAX_DEVELOPER_RETRIES` + Guard 2 `plane_sync.fetch_issue_state` Blocked/Needs-Input, флаг `ORCH_RECONCILE_SKIP_BLOCKED_ENABLED`); ORCH-058 (провенанс staging-образа: check_staging_image_fresh + staging_check свежего образа + хук-guard, adr-0008) — реализовано в ветке feature/ORCH-058 (обновлять также при изменении src/image_freshness.py, scripts/orchestrator-deploy-hook.sh, Dockerfile); ORCH-061 (толерантность staging-вердикта к инфра-FAIL C9a/C9b, adr-0009, `docs/work-items/ORCH-061/06-adr/ADR-001`) — реализовано в ветке feature/ORCH-061 (обновлять также при изменении src/staging_verdict.py, scripts/staging_check.py, флаг staging_infra_tolerance_enabled); ORCH-021 (post-deploy наблюдение прода + реакция на деградацию, adr-0010, `docs/work-items/ORCH-021/06-adr/ADR-001`) — реализовано в ветке feature/ORCH-021-post-deploy-rollback (reserved-agent job `post-deploy-monitor`: арм в src/stage_engine.py блок `next_stage == "done"`, тик `run_post_deploy_monitor` + перехват в src/agents/launcher.py ДО _spawn; чистая логика src/post_deploy.py never-raise; флаги `post_deploy_*` в src/config.py; блок `post_deploy` в `/queue`; артефакт 16-post-deploy-log.md; self-hosting всегда ALERT_ONLY — тик не рестартит прод; обновлять также при изменении src/post_deploy.py / арм-блока / launcher-перехвата).*

View File

@@ -12,6 +12,15 @@ Per-work-item решения живут в `docs/work-items/<id>/06-adr/ADR-NNN-
| adr-0005 | Контейнеры бегут под uid:gid хоста (1000:1000) | accepted | 2026-06-06 | ORCH-040 |
| adr-0006 | Merge-gate (догон main + re-test + сериализация слияний) | proposed | 2026-06-06 | ORCH-043 |
| adr-0007 | Reconciler застрявших стадий (sweeper потерянных webhook) | accepted | 2026-06-06 | ORCH-053 |
| adr-0007 | Исполняемый самодеплой стадии `deploy` (файл adr-0007-executable-self-deploy) | accepted | 2026-06-06 | ORCH-036 |
| adr-0008 | Провенанс staging-образа перед BUILD-ONCE retag | accepted | 2026-06-06 | ORCH-058 |
| adr-0009 | Толерантность staging-вердикта к инфраструктурным FAIL | accepted | 2026-06-07 | ORCH-061 |
| adr-0010 | Post-deploy мониторинг прода + реакция на деградацию | proposed | 2026-06-07 | ORCH-021 |
> ⚠️ Историческая коллизия: номер `0007` занят двумя файлами —
> `adr-0007-reconciler.md` (ORCH-053) и `adr-0007-executable-self-deploy.md`
> (ORCH-036). Оба accepted; для новых сквозных ADR использовать следующий
> свободный номер (текущий максимум — `0010`).
## Формат
**Контекст → Решение → Альтернативы → Последствия → Связи.** Статус: proposed / accepted / superseded.

View File

@@ -61,6 +61,14 @@ grace + `max_concurrency=1`); never-raise на единицу работы; ти
(`reconcile_plane_enabled` гасит только F-2); reconciler не рестартит/не роняет
прод-контейнер. БД-схема и реестры (`STAGE_TRANSITIONS`/`QG_CHECKS`) не меняются.
## Уточнения
- **ORCH-060** (`docs/work-items/ORCH-060/06-adr/ADR-001-reconciler-skip-escalated.md`):
F-1 (`_reconcile_gate_task`) приобретает два пред-гарда ДО оценки гейта —
пропускает escalated (`developer_retry_count ≥ MAX_DEVELOPER_RETRIES`,
детерминированно) и Blocked/Needs-Input (Вариант A, Plane API, без миграции)
задачи. Инварианты adr-0007 сохранены (схема/реестры не меняются, never-raise,
тишина при пропуске).
## Связи
adr-0002 (очередь / `available_at`, single-process-singleton), adr-0003 (условный
гейт — образец условности/флагов раската), adr-0006 (merge-gate как под-гейт ребра

View File

@@ -0,0 +1,56 @@
# adr-0009: Толерантность staging-вердикта к заведомо инфраструктурным FAIL
- **Статус:** accepted
- **Дата:** 2026-06-07
- **Задача:** ORCH-061
- **Детально:** `docs/work-items/ORCH-061/06-adr/ADR-001-staging-infra-tolerance.md`
## Контекст
Self-hosting `orchestrator` зацикливался на `deploy-staging`: `staging_check.py`
давал 2 ложных FAIL (C9a — ветка в sandbox, C9b — analyst-job в очереди), вызванных
отсутствием sandbox-настроек (bot-аккаунты не члены SANDBOX-проекта), а не регрессом
кода. `staging_check.py` делал `sys.exit(1)` при любом FAIL → deployer писал
`staging_status: FAILED``check_staging_status` FAILED → откат `deploy-staging →
development` → петля (жгла developer-ретраи и кредиты). Прод-деплой орка приходилось
доводить вручную — блокер автономного внедрения (ORCH-54).
## Решение
Классифицировать проверки staging-suite на **REAL** (pipeline) и **SANDBOX_INFRA**
(заведомо инфраструктурные, узкий allowlist `{C9a, C9b}`) и сделать вердикт
толерантным к инфра-FAIL, сохранив fail-closed для реальных проверок:
- Новый leaf-модуль `src/staging_verdict.py` (pure, never-raise, stdlib):
`classify_check(label)` + `compute_staging_verdict(items, infra_tolerant)`.
Правило: упала хоть одна REAL → FAILED/exit1; упали ТОЛЬКО SANDBOX_INFRA и
толерантность вкл → SUCCESS/exit0 (waived); толерантность выкл → legacy strict
(любой FAIL → FAILED).
- `scripts/staging_check.py` помечает проверки категориями, считает вердикт через
`staging_verdict`, печатает `INFRA-WAIVED` при вайвере (наблюдаемость).
- Kill-switch `staging_infra_tolerance_enabled` (env
`ORCH_STAGING_INFRA_TOLERANCE_ENABLED`, дефолт `True`; в `.env.staging`).
- `check_staging_status` / `_parse_staging_status` / `STAGE_TRANSITIONS` / реестр
`QG_CHECKS`**без изменений**; новый QG-чек не вводится. Условность ORCH-35
сохранена (не-self → no-op N/A).
- Инвариант FR-3: «no changes to commit» на action-стадиях (`deploy-staging`/`deploy`)
не есть недовыполнение — продвижение определяется exit0 + гейт-вердиктом
(launcher уже не откатывает; добавлена observability-строка).
## Альтернативы
- Только починить sandbox-инфру (направление а) — хрупко, не структурно, вне
автономной досягаемости таска; оставлено как опциональное hardening.
- «Зелёный по умолчанию» при недоступности проверок — запрещён (fail-closed).
- Новый QG-чек / структурный артефакт `15-staging-log.md` — избыточно, меняло бы
контракты/реестр; толерантность размещена в suite до артефакта.
## Последствия
- Петля устранена; страховка цела (реальный регресс → FAILED → откат).
- Чистая вердикт-логика юнит-тестируема без live staging/docker.
- Контракты гейтов/стадий/вердиктов/реестра и схема БД неизменны.
- Риск: узкое окно — реальный регресс именно в создании ветки/постановке
analyst-job может быть заваивен; митигировано allowlist'ом `{C9a,C9b}` + условием
«все REAL (вкл. C7/C8) зелёные» + INFRA-WAIVED-логом. Разблокирует ORCH-54.
## Связи
adr-0003 (условный staging-гейт — база `is_self_hosting_repo` / `check_staging_status`),
adr-0006 (merge-gate), adr-0007 (исполняемый self-deploy), adr-0008 (провенанс
staging-образа). Блокирует ORCH-54.

View File

@@ -0,0 +1,85 @@
# adr-0010: Post-deploy мониторинг прода + реакция на деградацию
- **Статус:** proposed (design) — реализация в ветке `feature/ORCH-021-post-deploy-rollback`
- **Дата:** 2026-06-07
- **Задача:** ORCH-021
- **Метка:** `arch:major-change` (новая под-компонента + новый reserved-agent job-kind)
- **Детальный ADR:** `docs/work-items/ORCH-021/06-adr/ADR-001-post-deploy-monitor.md`
## Контекст
Конвейер заканчивается на `deploy → done`: `check_deploy_status` видит
`deploy_status: SUCCESS` → terminal-sync (Plane → Done, release merge-lease), и
оркестратор **забывает про прод**. «Успех» сегодня = health-check в момент рестарта
(~60с окно в `orchestrator-deploy-hook.sh`). Класс инцидентов «зелёный деплой, красный
прод» (прецедент **ET-8**): деградация проявляется через минуты под боевым трафиком,
health отвечает `200 ok`, фича сломана. Для self-hosting опасно вдвойне — сломанный
прод-орк (8500) обслуживает ВСЕ проекты из общего инстанса.
## Решение
Продлить ответственность конвейера **ЗА** `done`: после терминального перехода для
применимого репо армится пост-деплой наблюдение окна `post_deploy_window_s` (дефолт
~15 мин) с интервалом `post_deploy_interval_s`; деградация фиксируется по
**детерминированным порогам**, при подтверждении выполняется реакция.
**Механизм — reserved-agent job `post-deploy-monitor`** (калька `deploy-finalizer`,
ORCH-36), НЕ отдельная стадия и НЕ daemon-поток:
- **Арм:** в `stage_engine.advance_stage`, в блоке `next_stage == "done"`, при
`post_deploy.post_deploy_applies(repo)``post_deploy.arm_monitor(...)` (sentinel
`armed` = идемпотентность, первый job через `enqueue_job(available_at_delay_s=...)`).
- **Тик:** `launcher.launch_job` перехватывает `agent == "post-deploy-monitor"` ДО
`_spawn``stage_engine.run_post_deploy_monitor(job)`: один опрос сигналов, append в
персистентный `series`, классификация; HEALTHY и окно не истекло → перепостановка с
задержкой; иначе → реакция + артефакт + `mark_done`.
- **Чистая логика — новый leaf-модуль `src/post_deploy.py`** (never-raise, по образцу
`self_deploy.py`/`staging_verdict.py`): `post_deploy_applies`, `probe_signals`
(опрос `/health` + доля 5xx на `/status`,`/queue`), `classify` (HEALTHY|DEGRADED —
главный предмет юнит-тестов), `decide_action` (NONE|ROLLBACK|ALERT_ONLY с учётом
self-hosting), sentinel-state хелперы, `write_post_deploy_log`.
**Сигналы и пороги (детерминированно, AC-3…AC-6):** `DEGRADED``≥
post_deploy_fail_threshold` ПОСЛЕДОВАТЕЛЬНЫХ провалов health ИЛИ доля 5xx на окне `>
post_deploy_5xx_threshold`. Одиночный глюк < порога → HEALTHY (нет ложных откатов).
**Реакция (BR-4/BR-5):**
- **Self-hosting (`orchestrator`) — ВСЕГДА `ALERT_ONLY`:** громкий Telegram + Plane,
запрос ручного approve отката. Тик НИКОГДА не откатывает/рестартит прод-контейнер
(структурный инвариант). Откат прод-орка, если оператор решит, — только detached
host-процесс (`self_deploy.initiate_deploy`), вне тика (MVP).
- **Не-self + `post_deploy_auto_rollback=True`:** хук `--rollback` с прод-env; exit
`0 → ROLLBACK_OK`, `1/2 → ROLLBACK_FAILED` + громкий алерт.
- Дефолт (`auto_rollback=False`) → `ALERT_ONLY`.
**Артефакт `16-post-deploy-log.md`** (новый) с YAML-frontmatter (`post_deploy_status`,
`action_taken`, `window_s`, `checks_total/failed`) — машиночитаемо для петли уроков
ORCH-8; best-effort. **Наблюдаемость** — блок `post_deploy` в `GET /queue` (образец
`reconcile.status()`).
## Альтернативы
- **Daemon-watchdog (как reconciler)** — отклонён: per-task серия опросов в памяти не
restart-safe (а деплой орка = рестарт); restart-safe-вариант требует тех же sentinel,
reserved-agent проще и уже имеет проверенную jobs+sentinel машинерию.
- **Отдельная пост-deploy стадия + QG** — отклонён: меняет `STAGE_TRANSITIONS`/
`QG_CHECKS`, ломает семантику терминального `done`; наблюдение принципиально ПОСЛЕ
`done`.
- **Авто-rollback прод-орка из тика** — отклонён (self-hosting safety): групповой риск;
контейнер не откатит себя надёжно. Self → alert + ручной approve (как ORCH-54).
- **Колонка в `tasks`** — отклонён: миграция на проде; sentinel-файлы restart-safe
(как ORCH-36/53/58).
## Последствия
- Класс «зелёный деплой, красный прод» закрыт измеримыми порогами; деградация =
сигнал для ORCH-8.
- Реестры (`STAGE_TRANSITIONS`/`QG_CHECKS`), контракт `check_deploy_status`,
terminal-sync, merge-gate, exit-code-контракт хука, схема БД — **не меняются**.
- Дефолты безопасны: kill-switch on, auto-rollback off, self только alert.
- Ограничение: монитор self бежит внутри наблюдаемого прода — полностью wedged
контейнер = пропущенный тик/алерт (known MVP gap; внешний watchdog — follow-up).
- Self-hosting: тик не рестартит/не роняет прод-контейнер; kill-switch
`post_deploy_monitor_enabled` обязателен; поэтапный раскат через `post_deploy_repos`.
## Связи
adr-0007-executable-self-deploy (ORCH-36 — sentinel/detached-host/finalizer образец,
`map_exit_code_to_status`), adr-0007-reconciler (ORCH-53 — daemon/`status()` образец,
отклонён как основной механизм), adr-0006 (merge-gate — условность/флаги раската),
adr-0003 (staging-gate — образец условности), adr-0008 (provenance — `.deploy-prev-image`/
хук-откат). Прецедент ET-8. Будущее: ORCH-8 (петля уроков), ORCH-54 (полный авто).

View File

@@ -12,7 +12,9 @@
| B | ACCESS | Plane sandbox (R), Gitea sandbox (R+push), реестр проектов |
| C | E2E | Создать задачу → триггер конвейера → ветка + коммент → cleanup |
Exit code: **0** = все PASS, **non-zero** = есть FAIL.
Exit code: **0** = advance (все REAL-проверки PASS), **1** = rollback (есть REAL-FAIL).
С ORCH-061 exit 0 может включать *waived* sandbox-infra FAIL (C9a/C9b) — см.
[«Толерантность к sandbox-infra (ORCH-061)»](#толерантность-к-sandbox-infra-orch-061).
---
@@ -85,6 +87,56 @@ B6 «Registry: sandbox present, prod ET/ORCH absent» подтверждает
---
## Толерантность к sandbox-infra (ORCH-061)
**Проблема.** Self-hosting `orchestrator` зацикливался на `deploy-staging → development`:
прежде скрипт давал exit 1 при **любом** FAIL, поэтому две чисто инфраструктурные
проверки — **C9a** (ветка не появилась в `orchestrator-sandbox`) и **C9b** (job
аналитика не встал в очередь staging) — приводили к `staging_status: FAILED`
откат → цикл. Корень: SANDBOX-бот-аккаунты не состоят в sandbox-проекте Plane,
поэтому шаги 6+ конвейера в песочнице недостижимы. Это **не** регресс конвейера.
**Решение.** Проверки классифицируются на две категории (`src/staging_verdict.py`):
| Категория | Что входит | Поведение |
|-----------|-----------|-----------|
| `REAL` | все проверки конвейера (A*, B*, C7, C8) | **fail-closed** — любой FAIL = rollback |
| `SANDBOX_INFRA` | строго allowlist `{C9a, C9b}` | **waivable** — FAIL терпится, если все REAL зелёные |
Вердикт сворачивается в `compute_staging_verdict(items, infra_tolerant)`:
- любой REAL-FAIL → `FAILED` / exit 1 (страховка сохраняется при ЛЮБОМ значении флага);
- упали **только** C9a/C9b и толерантность включена → `SUCCESS` / exit 0,
упавшие метки попадают в `waived` (наблюдаемость, печатается строкой `INFRA-WAIVED:`);
- упали только C9a/C9b, толерантность выключена → `FAILED` / exit 1 (legacy-строгий);
- любая внутренняя ошибка вердикта → `FAILED` / exit 1 (никогда не ложный green).
Blast-radius waiver-а ровно две allowlist-метки; всё неизвестное классифицируется
как `REAL` (fail-closed).
### Kill-switch и `--strict`
| Управление | Эффект |
|-----------|--------|
| env `ORCH_STAGING_INFRA_TOLERANCE_ENABLED` (default `true`) | глобальный флаг; `false` → строгий режим (1:1 до ORCH-061) |
| CLI `--strict` | форсит строгий режим для одного запуска, игнорируя env |
Флаг живёт в `.env.staging` (staging-инстанс). `--strict` имеет приоритет над env.
### Что печатает скрипт
В конце прогона `summary()` показывает разбивку REAL/SANDBOX_INFRA, затем:
```
INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox; C9b Analyst job enqueued ...
VERDICT: SUCCESS (infra-waived): ['C9a …', 'C9b …'] are known sandbox-infra checks; all real checks green
```
Контракт `staging_status: SUCCESS|FAILED` во frontmatter **не меняется**
толерантность применяется в скрипте ДО записи артефакта деплоером.
---
## Режимы (`--mode`)
| Режим | Описание | Скорость |

View File

@@ -0,0 +1,7 @@
# Business Request: [★ высокий] Post-deploy мониторинг прода + авто-rollback при деградации
Work Item ID: ORCH-021
## Description
TBD

View File

@@ -0,0 +1,88 @@
# BRD — ORCH-021: Post-deploy мониторинг прода + авто-rollback при деградации
Work Item: ORCH-021
Приоритет: высокий (★)
Источник: предложение Стрим, одобрено Славой (2026-06-04)
Стадия: analysis
## 1. Проблема (Why)
Сейчас конвейер заканчивается на `deploy → done`: как только `check_deploy_status`
видит `deploy_status: SUCCESS`, задача закрывается и оркестратор **забывает про прод**.
«Успех» деплоя сегодня означает только то, что health-check в момент рестарта
прошёл (10×6с в `scripts/orchestrator-deploy-hook.sh`) — узкое окно ~60 секунд.
**Прямой урок ET-8:** деплой отрапортовал SUCCESS, а на проде фича не работала.
Класс инцидентов — «зелёный деплой, красный прод»:
- деградация проявляется через минуты, а не в первые 60с (прогрев кэшей, фоновые
миграции, отложенные запросы, утечки, рост 5xx под реальным трафиком);
- health-эндпоинт отвечает `200 ok`, но ключевая функциональность сломана;
- регресс виден только под боевым трафиком, которого нет в момент рестарта.
После закрытия задачи никакого пригляда за продом нет — деградацию замечает человек
постфактум. Для self-hosting это особенно опасно: сломанный прод-орк (8500) обслуживает
ВСЕ проекты (enduro-trails) из общего инстанса.
## 2. Цель (What)
Продлить ответственность конвейера за прод **после** `deploy → done`: в течение
заданного окна наблюдать ключевые сигналы здоровья прода и при доказанной деградации
выполнить реакцию (откат на предыдущий образ или громкий алерт с запросом ручного
отката). Закрыть класс «зелёный деплой, красный прод».
Механизм частичного отката уже есть: `do_rollback()` и режим `--rollback` в
`scripts/orchestrator-deploy-hook.sh` умеют вернуть предыдущий образ из
`PREV_IMAGE_FILE` (`.deploy-prev-image-prod`), который сохраняется при каждом деплое.
Задача — построить **наблюдение поверх** этого и привязать решение к измеримым порогам.
## 3. Заинтересованные стороны
- **Owner (Слава)** — принимает риск авто-отката прода; получает алерты.
- **Стрим** — инициатор; потребитель сигнала деградации для петли уроков (ORCH-8).
- **Другие проекты (enduro-trails)** — косвенно: устойчивость общего инстанса.
## 4. Бизнес-требования
| # | Требование | Приоритет |
|---|------------|-----------|
| BR-1 | После `deploy → done` прод наблюдается в течение конфигурируемого окна (дефолт ~15 мин), а не забывается. | Must |
| BR-2 | Деградация определяется по **детерминированным измеримым сигналам**: периодический `/health` (HTTP 200 + `{"status":"ok"}`) и доля HTTP 5xx на ключевых эндпоинтах (`/status`, `/queue`). | Must |
| BR-3 | Деградация фиксируется только по **порогам** (N последовательных провалов / окно), а не по разовому сетевому глюку — чтобы не было ложных откатов. | Must |
| BR-4 | При подтверждённой деградации система выполняет реакцию: **авто-rollback** на `.deploy-prev-image-prod` (через существующий хук `--rollback`) **либо** громкий алерт с запросом ручного отката — в зависимости от политики репозитория. | Must |
| BR-5 | **Self-hosting safety:** для самого `orchestrator` авто-откат прода = рестарт инструмента, обслуживающего все проекты. По умолчанию для self-hosting реакция — **алерт + ручной approve отката** (по образцу deploy Phase A/B), НЕ автоматический откат. Для не-self репозиториев допустим авто-откат. | Must |
| BR-6 | Любой исход (наблюдение начато, деградация, откат, откат-провал, окно завершилось чисто) уведомляется в Telegram и комментарием в Plane; результат наблюдения фиксируется артефактом. | Must |
| BR-7 | Мониторинг — **restart-safe**: рестарт оркестратора (в т.ч. сам деплой) не теряет и не задваивает наблюдение. Идемпотентность по образцу reconciler / deploy-finalizer. | Must |
| BR-8 | Глобальный kill-switch (env-флаг) и список репозиториев, на которые распространяется фича (по образцу `merge_gate_enabled` / `image_freshness_enabled` / `self_deploy_repos`). Выключенный флаг = прежнее поведение (наблюдения нет). | Must |
| BR-9 | Наблюдаемость: текущее состояние пост-деплой наблюдения отражается в `GET /queue` (по образцу блока `reconcile`). | Should |
| BR-10 | Сигнал деградации пригоден для будущей петли уроков (ORCH-8): фиксируется в артефакте/логе в машиночитаемом виде. | Should |
| BR-11 | Доменный smoke результата фичи (проверка, что конкретная фича реально работает) — желателен, но выносится в follow-up; MVP ограничивается health + 5xx. | Could |
## 5. Вне рамок (Out of scope)
- Полноценная система метрик/APM (Prometheus, дашборды) — фича опирается на уже
существующие HTTP-эндпоинты, не вводит сбор метрик.
- Универсальный доменный smoke для произвольной фичи (BR-11 — follow-up).
- Полностью автоматический откат прод-орка без участия человека (противоречит
self-hosting safety; отдельная задача при наборе доверия, аналогично ORCH-54 для deploy).
- Изменение момента вердикта `deploy_status` / контракта `check_deploy_status`
(наблюдение происходит ПОСЛЕ `done`, не заменяет deploy-gate).
## 6. Связи
- **ET-8** — прецедент «deploy SUCCESS, прод не работает». Обоснование задачи.
- **ORCH-36** (`docs/architecture/adr/adr-0007-executable-self-deploy.md`) — Phase A/B/C
исполняемого самодеплоя; пост-деплой наблюдение продлевает ответственность ЗА `done`,
переиспользует sentinel-паттерн и detached-host-процесс для self-rollback.
- **ORCH-53** (`src/reconciler.py`) — каноничный паттерн фонового daemon-потока
(watchdog), запускаемого в `main.lifespan`; образец для пост-деплой наблюдателя.
- **ORCH-58** — `.deploy-prev-image` и хук-механика отката, на которые опирается реакция.
- **ORCH-8** — деградация прода = сигнал для петли уроков (BR-10).
- **ORCH-12** — фича может оформиться как пост-deploy стадия ИЛИ как watchdog (решение
архитектора, см. §7).
## 7. Открытые архитектурные вопросы (для архитектора, НЕ решаются в анализе)
1. **Где живёт наблюдение:** отдельная пост-deploy стадия конвейера vs фоновый
watchdog-daemon (по образцу `reconciler`) vs reserved-agent job (по образцу
`deploy-finalizer`). Анализ задаёт требования (BR-1, BR-7), выбор механизма — за архитектором.
2. **Механизм self-rollback для self-hosting:** откат прод-орка требует detached
host-процесса (контейнер не может надёжно откатить себя, умирая) — переиспользовать
ли `self_deploy.initiate_deploy` / хук `--rollback`.
3. Точные пороги и веса сигналов (BR-3) — анализ предлагает дефолты (см. AC), архитектор
фиксирует реализацию.

View File

@@ -0,0 +1,165 @@
# ТЗ — ORCH-021: Post-deploy мониторинг прода + авто-rollback
Work Item: ORCH-021
Стадия: analysis → (architecture)
> Документ описывает ТРЕБОВАНИЯ к изменениям и НАЗЫВАЕТ задействованные модули.
> Выбор механизма (стадия vs watchdog vs reserved-agent) и точная реализация —
> зона архитектора (см. BRD §7). Здесь фиксируется, ЧТО должно измениться и КАКИЕ
> контракты НЕЛЬЗЯ ломать.
## 1. Контекст в коде (как есть сейчас)
- Конвейер заканчивается в `src/stages.py`: `deploy → done`, gate `check_deploy_status`.
Терминальный переход `deploy → done` исполняется в `src/stage_engine.py::advance_stage`
(блок «Terminal sync», `set_issue_done`, release merge-lease). После этого ничего
не наблюдает за продом.
- `scripts/orchestrator-deploy-hook.sh` уже умеет:
- `health_check(max_attempts, sleep, label)` — опрос `http://localhost:$TARGET_PORT/health`
с проверкой `"status":"ok"`;
- `do_rollback()` — retag `PREV_IMAGE_FILE``TARGET_IMAGE` + рестарт + пост-rollback
health-check; коды возврата 0 (ок) / 1 (нет prev-образа) / 2 (rollback тоже упал);
- режим `--rollback` (ручной откат);
- при обычном деплое сохраняет `PREV_IMG` в `PREV_IMAGE_FILE`
(`.deploy-prev-image-prod` для прода, см. `settings.deploy_prod_prev_image_file`).
- Self-deploy прода идёт через detached host-процесс: `src/self_deploy.py`
(`build_deploy_command`, `initiate_deploy`, sentinel-маркеры под
`.deploy-state-<repo>/<wi>/`, `read_result`, `map_exit_code_to_status`).
- Фоновый daemon-паттерн: `src/reconciler.py` (`threading.Thread(daemon=True)` +
`threading.Event`, старт/стоп в `src/main.py::lifespan` после `worker.start()` /
перед `worker.stop()`, `status()` в `GET /queue`).
- Reserved-agent (детерминированный no-LLM job) паттерн: `deploy-finalizer`
перехват в `src/agents/launcher.py::launch_job` ДО `_spawn`, исполнение
`stage_engine.run_deploy_finalizer`, отложенная постановка через
`enqueue_job(..., available_at_delay_s=...)`.
- Условность self-hosting: `src/qg/checks.py::is_self_hosting_repo`,
`src/self_deploy.py::self_deploy_applies` (флаг + CSV-репо; пусто → только `orchestrator`).
- Наблюдаемые эндпоинты прода (`src/main.py`): `GET /health`, `GET /status`, `GET /queue`.
- API БД: `src/db.py::enqueue_job` (с `available_at_delay_s`), `get_db`,
`update_task_stage`, `get_active_tasks_for_reconcile`.
## 2. Требуемые изменения
### 2.1. Новый leaf-модуль чистой логики наблюдения — `src/post_deploy.py` (новый)
Контракт **never-raise** (по образцу `self_deploy.py` / `staging_verdict.py`).
Чистые, юнит-тестируемые функции:
- **Опрос сигналов:** функция, опрашивающая `/health` и ключевые эндпоинты
(`/status`, `/queue`) прод-инстанса (base-url из config), возвращающая структуру
с результатами (код ответа, ok-флаг, доля 5xx). Сеть/таймаут → консервативный
результат, не исключение.
- **Классификация деградации** (чистая, без сети): на вход — серия результатов
опросов; на выход — вердикт `HEALTHY | DEGRADED` по порогам (BR-3):
`≥ post_deploy_fail_threshold` последовательных провалов health ИЛИ доля 5xx
выше `post_deploy_5xx_threshold` на окне. Эта функция — основной предмет
юнит-тестов (детерминированная, как `compute_staging_verdict` в ORCH-061).
- **Решение о реакции** (чистая): по `(repo, вердикт, политика)` → одно из
`NONE | ROLLBACK | ALERT_ONLY`, с учётом self-hosting (BR-5).
- **Запись артефакта** результата наблюдения (см. §2.5), best-effort.
- Условность: хелпер `post_deploy_applies(repo)` (флаг + CSV-репо, пусто →
только self-hosting), по образцу `self_deploy_applies` / `_merge_gate_applies`.
### 2.2. Оркестрация наблюдения (механизм — выбор архитектора)
Требования к механизму (независимо от выбора стадия/watchdog/reserved-agent):
- запускается ПОСЛЕ перехода `deploy → done` для применимого репозитория (BR-1);
- наблюдает окно `post_deploy_window_s` с интервалом `post_deploy_interval_s`;
- **restart-safe и идемпотентен** (BR-7): состояние наблюдения — в sentinel-файлах
(по образцу `.deploy-state-<repo>/<wi>/`, напр. маркеры `monitor-started` /
`monitor-done`) ИЛИ через отложенные `enqueue_job(available_at_delay_s=...)`;
повторный старт не задваивает наблюдение и не теряет его при рестарте;
- по итогу вызывает «Решение о реакции» из `src/post_deploy.py` и исполняет реакцию (§2.3).
Кандидатные точки интеграции (на выбор архитектора, см. BRD §7):
- хук в `stage_engine.advance_stage` в блоке `next_stage == "done"` — арм наблюдения;
- reserved-agent `post-deploy-monitor` (расширение `launcher.launch_job` ДО `_spawn`,
как `deploy-finalizer`), с само-перепостановкой через `available_at_delay_s`;
- отдельный daemon-поток `PostDeployWatcher` (как `Reconciler`), старт/стоп в `main.lifespan`.
### 2.3. Реакция на деградацию
- **Не-self репозитории / политика auto:** вызвать существующий хук в режиме отката
(`scripts/orchestrator-deploy-hook.sh --rollback` с прод-параметрами окружения,
как в `self_deploy.build_deploy_command`, но action=`--rollback`). Маппинг
exit-code хука (0/1/2) в исход переиспользует логику `self_deploy.map_exit_code_to_status`
по смыслу (0 → откат успешен; 1/2 → откат не выполнен/провалился → громкий алерт).
- **Self-hosting (`orchestrator`) по умолчанию (BR-5):** НЕ откатывать автоматически.
Сформировать громкий алерт (Telegram + Plane-коммент) и запросить ручной approve
отката (по образцу deploy Phase A — статус Plane / Telegram CTA). Откат самого
прод-орка, если выполняется, — только через detached host-процесс (нельзя надёжно
откатить контейнер, который при этом умирает; переиспользовать механику
`self_deploy.initiate_deploy`).
- Команда отката для self НЕ должна ронять прод-контейнер в рамках обычного тика
наблюдения (CLAUDE.md: не ронять/не рестартить прод-контейнер вне явного действия).
### 2.4. Конфигурация — `src/config.py` (расширение `Settings`)
Добавить (env-префикс `ORCH_`, дефолты безопасные):
- `post_deploy_monitor_enabled: bool = True` — глобальный kill-switch (BR-8).
- `post_deploy_repos: str = ""` — CSV применимых репо; пусто → только self-hosting
(по образцу `self_deploy_repos` / `merge_gate_repos` / `image_freshness_repos`).
- `post_deploy_window_s: int = 900` — длина окна наблюдения (дефолт ~15 мин, BR-1).
- `post_deploy_interval_s: int = 30` — интервал между опросами.
- `post_deploy_fail_threshold: int = 3` — N последовательных провалов health → DEGRADED.
- `post_deploy_5xx_threshold: float = 0.5` — порог доли 5xx на окне → DEGRADED.
- `post_deploy_auto_rollback: bool = False` — глобально разрешён ли авто-откат;
при `True` действует для не-self репо; для self всегда требует approve (BR-5).
- `post_deploy_base_url: str = "http://localhost:8500"` — base-url наблюдаемого прода.
- `post_deploy_target` параметры отката — переиспользовать существующие
`deploy_prod_*` (service/port/image/prev_image_file), новых дублей не вводить.
### 2.5. Артефакт задачи — `16-post-deploy-log.md` (новый)
В `docs/work-items/<plane-id>/`. YAML-frontmatter (машиночитаемо, канон гейтов;
для будущей петли уроков BR-10):
```
---
post_deploy_status: HEALTHY | DEGRADED
action_taken: NONE | ROLLBACK_OK | ROLLBACK_FAILED | ALERT_ONLY
work_item: <plane-id>
window_s: <int>
checks_total: <int>
checks_failed: <int>
---
```
Тело — человекочитаемая сводка опросов. Записывается best-effort (по образцу
`self_deploy.write_deploy_log`); отсутствие файла не должно ничего ронять.
> Артефакт `16-post-deploy-log.md` добавить в перечень артефактов в `CLAUDE.md`
> и таблицу/описание в `docs/architecture/README.md` (golden-source, в том же PR).
### 2.6. Наблюдаемость — `GET /queue` (`src/main.py`) (BR-9)
Добавить блок `post_deploy` со снимком состояния (enabled, window, активные
наблюдения, последний исход) — по образцу блока `reconcile` (метод `status()`).
### 2.7. Изменения схемы БД
**Не требуются.** Состояние наблюдения — sentinel-файлы (restart-safe, без миграции,
по образцу ORCH-36) и/или отложенные jobs. Если архитектор выберет колонку в `tasks`
для отметки наблюдения — потребуется миграция; предпочтительно избежать (как ORCH-36/53/58).
### 2.8. Новые QG checks
**Не требуются.** Наблюдение происходит ПОСЛЕ `done` и не является gate'ом стадии;
реестр `QG_CHECKS` и `STAGE_TRANSITIONS` не меняются (если архитектор НЕ выберет
вариант «отдельная пост-deploy стадия» — тогда потребуется новая стадия+gate, что
надо явно отразить в ADR; по умолчанию предпочтителен вариант без изменения реестров).
## 3. Инварианты (НЕ ломать)
- `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, контракт `check_deploy_status` /
`_parse_deploy_status`, момент вердикта `deploy_status`, БАГ-8 откат, terminal-sync
`deploy → done`, merge-gate, exit-code-контракт хука (0/1/2) — без изменений.
- Контракт хука: дефолты STAGING-безопасны; прод-параметры приходят только через env.
- Условность как ORCH-35/36/43/58: реально для `orchestrator`/listed-repos, прочие — no-op.
- Never-raise: ошибка в наблюдении не роняет worker / lifespan / конвейер других проектов.
- Self-hosting: тик наблюдения НИКОГДА не рестартит прод-контейнер сам по себе (BR-5).
## 4. Задействованные модули (сводка)
| Модуль | Изменение |
|--------|-----------|
| `src/post_deploy.py` | **новый** — чистая логика опроса/классификации/решения/артефакта, never-raise |
| `src/config.py` | +параметры `post_deploy_*` (kill-switch, окно, пороги, политика) |
| `src/stage_engine.py` и/или `src/agents/launcher.py` и/или `src/main.py` | арм/исполнение наблюдения (точка — за архитектором) |
| `scripts/orchestrator-deploy-hook.sh` | переиспользуется (`--rollback`); правки — только если откат self требует отдельной ветки (за архитектором) |
| `src/main.py` | блок `post_deploy` в `GET /queue` (BR-9); возможный старт daemon в `lifespan` |
| `docs/work-items/<id>/16-post-deploy-log.md` | **новый** артефакт |
| `CLAUDE.md`, `docs/architecture/README.md`, `CHANGELOG.md` | обновить (golden-source, в том же PR) |
| ADR | `docs/work-items/ORCH-021/06-adr/ADR-001-*.md` (+ возможный сквозной `adr/adr-00NN`) |
## 5. Артефакты по pipeline, которые должны появиться/обновиться
- `16-post-deploy-log.md` (новый, машиночитаемый frontmatter).
- Обновлённые `CLAUDE.md` (перечень артефактов), `docs/architecture/README.md`
(описание пост-деплой наблюдения), `CHANGELOG.md`.
- ADR work-item (`06-adr/`) с зафиксированным выбором механизма и порогов.

View File

@@ -0,0 +1,106 @@
# Критерии приёмки — ORCH-021
Work Item: ORCH-021
Формат: каждый критерий имеет чёткое условие PASS/FAIL и проверяется тестом
из `04-test-plan.yaml`.
## Наблюдение и сигналы
### AC-1 — наблюдение армится после deploy→done
- **PASS:** для применимого репозитория после терминального перехода `deploy → done`
пост-деплой наблюдение инициируется (создаётся sentinel/отложенный job/запись в watcher).
- **FAIL:** переход `deploy → done` не приводит к старту наблюдения.
### AC-2 — наблюдение НЕ армится для неприменимых репо
- **PASS:** для репозитория вне области (не self-hosting и не в `post_deploy_repos`)
`post_deploy_applies(repo)` → False; наблюдение не стартует; конвейер не меняется.
- **FAIL:** наблюдение стартует для неприменимого репо.
### AC-3 — классификация HEALTHY
- **PASS:** серия опросов без провалов (или провалов меньше `post_deploy_fail_threshold`
и доля 5xx ниже `post_deploy_5xx_threshold`) → вердикт `HEALTHY`.
- **FAIL:** при здоровых сигналах возвращается `DEGRADED`.
### AC-4 — классификация DEGRADED по порогу провалов health
- **PASS:** `≥ post_deploy_fail_threshold` ПОСЛЕДОВАТЕЛЬНЫХ провалов health → `DEGRADED`.
- **FAIL:** порог достигнут, но вердикт не `DEGRADED`.
### AC-5 — классификация DEGRADED по доле 5xx
- **PASS:** доля 5xx на окне выше `post_deploy_5xx_threshold``DEGRADED`,
даже если `/health` отвечает 200.
- **FAIL:** превышение порога 5xx не даёт `DEGRADED`.
### AC-6 — устойчивость к разовому глюку (нет ложного срабатывания)
- **PASS:** одиночный провал (1 < `post_deploy_fail_threshold`) с последующим
восстановлением → итог `HEALTHY`, реакции нет.
- **FAIL:** одиночный разовый провал приводит к `DEGRADED`/откату.
## Реакция
### AC-7 — авто-rollback для не-self репо при политике auto
- **PASS:** при `post_deploy_auto_rollback=True` и НЕ-self репо вердикт `DEGRADED`
приводит к вызову отката (хук `--rollback` с прод-параметрами); `action_taken`
фиксируется как `ROLLBACK_OK`/`ROLLBACK_FAILED` по exit-code.
- **FAIL:** откат не вызывается, либо вызывается с staging-дефолтами, либо роняет прод напрямую.
### AC-8 — self-hosting НЕ откатывается автоматически (safety)
- **PASS:** для `orchestrator` вердикт `DEGRADED` НЕ приводит к автоматическому
откату/рестарту прод-контейнера в тике наблюдения; вместо этого формируется
громкий алерт + запрос ручного approve (`action_taken: ALERT_ONLY`).
- **FAIL:** тик наблюдения автоматически откатывает/рестартит прод-орк.
### AC-9 — откат-провал эскалируется
- **PASS:** если откат вызван и вернул код 1/2 (нет prev-образа / откат тоже упал) →
`action_taken: ROLLBACK_FAILED` + громкий Telegram-алерт о необходимости ручного вмешательства.
- **FAIL:** провал отката проглатывается тихо.
## Конфигурация и совместимость
### AC-10 — kill-switch выключает фичу
- **PASS:** `post_deploy_monitor_enabled=False` → наблюдение не армится ни для кого;
поведение конвейера 1:1 как до ORCH-021.
- **FAIL:** при выключенном флаге наблюдение всё равно работает.
### AC-11 — пороги/окно конфигурируемы через env
- **PASS:** `post_deploy_window_s`, `post_deploy_interval_s`, `post_deploy_fail_threshold`,
`post_deploy_5xx_threshold` читаются из `Settings` (env `ORCH_*`) и влияют на поведение.
- **FAIL:** значения захардкожены.
### AC-12 — реестры и схема БД не изменены
- **PASS:** `STAGE_TRANSITIONS`, `QG_CHECKS`, контракт `check_deploy_status` и схема
таблиц БД не изменены (если архитектор не вводит явно новую стадию — тогда это
отражено в ADR и тестах). Существующие тесты deploy/staging/merge-gate зелёные.
- **FAIL:** молча сломан какой-либо существующий контракт/тест.
## Наблюдаемость, артефакт, идемпотентность
### AC-13 — артефакт 16-post-deploy-log.md с машиночитаемым frontmatter
- **PASS:** по итогу наблюдения пишется `16-post-deploy-log.md` с валидным YAML-frontmatter
(`post_deploy_status`, `action_taken`); запись best-effort (её отсутствие ничего не роняет).
- **FAIL:** артефакт не пишется или frontmatter невалиден/непарсится.
### AC-14 — наблюдаемость в /queue
- **PASS:** `GET /queue` содержит блок `post_deploy` со снимком состояния (enabled,
window, активные/последний исход).
- **FAIL:** состояние наблюдения нигде не видно.
### AC-15 — идемпотентность / restart-safe
- **PASS:** повторный арм для той же задачи (двойной webhook / рестарт оркестратора)
не создаёт второе параллельное наблюдение и не теряет уже идущее.
- **FAIL:** дублируется наблюдение или теряется при рестарте.
### AC-16 — never-raise
- **PASS:** любая ошибка опроса/сети/файлов/классификации логируется и НЕ роняет
worker / lifespan / конвейер других проектов.
- **FAIL:** исключение из наблюдения всплывает и ломает обслуживание других проектов.
### AC-17 — уведомления
- **PASS:** ключевые события (наблюдение начато, DEGRADED, откат/алерт, чистое
завершение окна) уведомляются в Telegram и/или Plane-комментарием.
- **FAIL:** деградация/откат происходят молча.
### AC-18 — документация обновлена (golden-source)
- **PASS:** в том же PR обновлены `CLAUDE.md` (артефакт `16-post-deploy-log.md`),
`docs/architecture/README.md` (описание пост-деплой наблюдения), `CHANGELOG.md`,
и заведён ADR work-item.
- **FAIL:** функционал есть, документация не обновлена (reviewer → REQUEST_CHANGES).

View File

@@ -0,0 +1,163 @@
work_item: ORCH-021
description: >
Тест-план пост-деплой мониторинга прода + авто-rollback. Упор на детерминированную
чистую логику классификации/решения (юнит, без сети/LLM) и на интеграцию
армирования наблюдения после deploy->done. Сетевые опросы и хук-вызовы мокируются.
Имена модулей/функций — целевые (src/post_deploy.py); архитектор уточняет точную
сигнатуру, тесты адаптируются под ADR.
tests:
# --- Классификация деградации (чистая логика, ядро) ---
- id: TC-01
type: unit
description: "HEALTHY: серия опросов без провалов (< порога) -> вердикт HEALTHY"
module: tests/test_post_deploy.py
covers: [AC-3]
expected: PASS
- id: TC-02
type: unit
description: "DEGRADED: N последовательных провалов health (== fail_threshold) -> DEGRADED"
module: tests/test_post_deploy.py
covers: [AC-4]
expected: PASS
- id: TC-03
type: unit
description: "DEGRADED по 5xx: доля 5xx выше порога при health=200 -> DEGRADED"
module: tests/test_post_deploy.py
covers: [AC-5]
expected: PASS
- id: TC-04
type: unit
description: "Нет ложного срабатывания: одиночный провал (1 < threshold) + восстановление -> HEALTHY"
module: tests/test_post_deploy.py
covers: [AC-6]
expected: PASS
- id: TC-05
type: unit
description: "Пороги читаются из Settings (env ORCH_*), изменение порога меняет вердикт на тех же данных"
module: tests/test_post_deploy.py
covers: [AC-11]
expected: PASS
# --- Решение о реакции (чистая логика + self-hosting safety) ---
- id: TC-06
type: unit
description: "Решение: не-self репо + auto_rollback=True + DEGRADED -> ROLLBACK"
module: tests/test_post_deploy.py
covers: [AC-7]
expected: PASS
- id: TC-07
type: unit
description: "Решение self-hosting: orchestrator + DEGRADED -> ALERT_ONLY (НИКОГДА не авто-rollback)"
module: tests/test_post_deploy.py
covers: [AC-8]
expected: PASS
- id: TC-08
type: unit
description: "Решение: HEALTHY -> NONE (реакции нет) для любого репо"
module: tests/test_post_deploy.py
covers: [AC-3]
expected: PASS
# --- Условность / kill-switch ---
- id: TC-09
type: unit
description: "post_deploy_applies: пусто в repos -> True только для orchestrator, False для enduro-trails"
module: tests/test_post_deploy.py
covers: [AC-2]
expected: PASS
- id: TC-10
type: unit
description: "kill-switch: post_deploy_monitor_enabled=False -> applies()=False для всех; наблюдение не армится"
module: tests/test_post_deploy.py
covers: [AC-10]
expected: PASS
# --- Маппинг exit-code отката -> исход ---
- id: TC-11
type: unit
description: "Откат exit 0 -> action_taken=ROLLBACK_OK"
module: tests/test_post_deploy.py
covers: [AC-7]
expected: PASS
- id: TC-12
type: unit
description: "Откат exit 1/2 (нет prev-образа / откат упал) -> ROLLBACK_FAILED + эскалация-алерт"
module: tests/test_post_deploy.py
covers: [AC-9]
expected: PASS
# --- Артефакт ---
- id: TC-13
type: unit
description: "16-post-deploy-log.md пишется с валидным YAML-frontmatter (post_deploy_status/action_taken), парсится yaml.safe_load"
module: tests/test_post_deploy.py
covers: [AC-13]
expected: PASS
# --- never-raise ---
- id: TC-14
type: unit
description: "Опрос при сетевой ошибке/таймауте -> консервативный результат (провал-как-down), исключение НЕ всплывает"
module: tests/test_post_deploy.py
covers: [AC-16]
expected: PASS
- id: TC-15
type: unit
description: "Ошибка записи артефакта (нет каталога/IO) -> логируется, функция возвращает False, не raise"
module: tests/test_post_deploy.py
covers: [AC-16, AC-13]
expected: PASS
# --- Интеграция: армирование после deploy->done ---
- id: TC-16
type: integration
description: "advance_stage deploy->done для orchestrator армит наблюдение (sentinel/job создан); для enduro-trails — нет"
module: tests/test_post_deploy_integration.py
covers: [AC-1, AC-2]
expected: PASS
- id: TC-17
type: integration
description: "Идемпотентность: повторный арм той же задачи (двойной webhook) не создаёт второе наблюдение"
module: tests/test_post_deploy_integration.py
covers: [AC-15]
expected: PASS
- id: TC-18
type: integration
description: "Полный цикл DEGRADED -> для не-self вызывается откат (хук замокан), пишется лог, шлётся уведомление"
module: tests/test_post_deploy_integration.py
covers: [AC-7, AC-13, AC-17]
expected: PASS
- id: TC-19
type: integration
description: "Self-hosting DEGRADED: тик НЕ вызывает рестарт/откат прод-контейнера, формирует алерт+approve-запрос"
module: tests/test_post_deploy_integration.py
covers: [AC-8, AC-17]
expected: PASS
# --- Наблюдаемость и обратная совместимость ---
- id: TC-20
type: integration
description: "GET /queue содержит блок post_deploy со снимком состояния"
module: tests/test_post_deploy_integration.py
covers: [AC-14]
expected: PASS
- id: TC-21
type: integration
description: "Регресс: существующие тесты deploy/staging/merge-gate/reconciler зелёные; STAGE_TRANSITIONS и QG_CHECKS не изменены"
module: tests/test_stages.py
covers: [AC-12]
expected: PASS

View File

@@ -0,0 +1,212 @@
# ADR-001 (ORCH-021): Post-deploy мониторинг прода + реакция на деградацию
## Статус
Proposed (design) — реализация в ветке `feature/ORCH-021-post-deploy-rollback`.
Сквозной индексный ADR: `docs/architecture/adr/adr-0010-post-deploy-monitor.md`.
Помечено `arch:major-change` (новая под-компонента + новый reserved-agent job-kind).
## Контекст
Конвейер заканчивается на `deploy → done` (`check_deploy_status` видит
`deploy_status: SUCCESS` → terminal-sync, Plane → Done, release merge-lease). После
этого оркестратор **забывает про прод**. «Успех» сегодня = прохождение health-check
в момент рестарта (10×6с в `scripts/orchestrator-deploy-hook.sh`) — узкое окно ~60с.
Класс инцидентов «зелёный деплой, красный прод» (прецедент **ET-8**): деградация
проявляется через минуты под боевым трафиком (прогрев кэшей, фоновые миграции,
утечки, рост 5xx), health отвечает `200 ok`, но фича сломана. Для self-hosting это
критично: сломанный прод-орк (8500) обслуживает ВСЕ проекты из общего инстанса.
BRD/ТЗ задают требования (BR-1…BR-11, AC-1…AC-18) и оставляют архитектору **три
открытых вопроса** (BRD §7): (1) где живёт наблюдение — стадия / watchdog-daemon /
reserved-agent job; (2) механизм self-rollback; (3) пороги/веса сигналов.
Существующие переиспользуемые механики:
- **deploy-finalizer** (ORCH-36, `stage_engine.run_deploy_finalizer` + перехват в
`launcher.launch_job` ДО `_spawn`) — детерминированный no-LLM reserved-agent job,
само-перепостановка через `enqueue_job(available_at_delay_s=...)`, defer-budget,
restart-safe (jobs-очередь + sentinel-файлы `.deploy-state-<repo>/<wi>/`).
- **self_deploy.py** — sentinel-state хелперы (`write_marker`/`has_marker`/
`read_result`/`clear_state`), detached host-процесс (`build_deploy_command`/
`initiate_deploy`: ssh + setsid), `map_exit_code_to_status`, `self_deploy_applies`.
- **reconciler.py** — daemon-поток + `status()` в `GET /queue`.
- **хук `--rollback`** (`do_rollback`): retag `PREV_IMAGE_FILE``TARGET_IMAGE` +
рестарт + health, коды 0 / 1 (нет prev-образа) / 2 (rollback тоже упал).
- **Условность** ORCH-35/36/43/58: `is_self_hosting_repo`, флаг + CSV-репо.
## Решение
### 1. Механизм наблюдения — reserved-agent job `post-deploy-monitor` (Вариант B)
Наблюдение реализуется как **детерминированный no-LLM reserved-agent job**, точная
калька **deploy-finalizer**. Один «тик» наблюдения = один job: он делает ОДИН опрос
сигналов, обновляет персистентные счётчики в sentinel-файлах, классифицирует и либо
**перепостанавливает себя** с задержкой `post_deploy_interval_s` (окно не истекло и
ещё не DEGRADED), либо завершает наблюдение (DEGRADED → реакция; либо окно истекло →
HEALTHY). Это «watchdog поверх очереди»: между тиками job не выполняется (он
запланирован в будущем через `available_at_delay_s`), worker свободен для других
проектов — ровно как defer у finalizer.
**Почему НЕ daemon-watchdog (Вариант A, как reconciler):** daemon тикает глобально, а
не per-task; серию опросов (последовательные провалы health, доля 5xx на окне) пришлось
бы держать в памяти → теряется/двоится при рестарте (а сам деплой орка = рестарт). Чтобы
сделать daemon restart-safe, всё равно нужны персистентные per-task счётчики в sentinel —
тогда reserved-agent проще и уже имеет проверенную restart-safe машинерию (jobs-очередь
+ `requeue_running_jobs` + sentinels). Per-task жизненный цикл естественно ложится на
job-цепочку, а не на глобальный sweep.
**Почему НЕ отдельная пост-deploy стадия (Вариант C):** меняет `STAGE_TRANSITIONS` +
реестр `QG_CHECKS` (нарушает AC-12, ТЗ §2.8 — явно непредпочтительно); ломает семантику
`deploy → done` как терминального перехода (Plane уже Done). Наблюдение происходит
**ПОСЛЕ** `done` — «продление ответственности ЗА done», а не новая стадия конвейера.
### 2. Арм наблюдения — хук в terminal-блоке `advance_stage`
В `stage_engine.advance_stage`, в существующем блоке `next_stage == "done"` (после
`set_issue_done` и `release_merge_lease`), добавляется арм:
```
if next_stage == "done" and post_deploy.post_deploy_applies(repo):
post_deploy.arm_monitor(repo, work_item_id, branch, task_id)
```
`arm_monitor` (never-raise): если sentinel `armed` отсутствует → создаёт state-dir,
пишет `armed` (идемпотентность, по образцу `INITIATED`), инициализирует `series`-файл,
ставит первый `post-deploy-monitor` job через `enqueue_job(available_at_delay_s=
post_deploy_interval_s)`. Если `armed` уже есть → no-op (двойной webhook / reconciler
F-1 / finalizer Phase C могут довести `done` повторно — AC-15). Выключенный
kill-switch / неприменимый репо → `post_deploy_applies` False → арма нет (AC-2/AC-10).
### 3. Чистая логика — новый leaf-модуль `src/post_deploy.py` (never-raise)
По образцу `self_deploy.py` / `staging_verdict.py`. Импортирует только config (+lazy
`qg.checks.is_self_hosting_repo`), НЕ импортирует `stage_engine`/`launcher`. Функции:
- **`post_deploy_applies(repo) -> bool`** — флаг `post_deploy_monitor_enabled` +
CSV `post_deploy_repos` (пусто → только self-hosting). Калька `self_deploy_applies`.
- **`probe_signals(base_url) -> ProbeResult`** — один опрос: `GET /health` (HTTP 200 +
`{"status":"ok"}`) и ключевые эндпоинты `/status`, `/queue` (учёт доли 5xx).
Сеть/таймаут → консервативный «провал»-результат, не исключение.
- **`classify(series, fail_threshold, 5xx_threshold) -> "HEALTHY"|"DEGRADED"`** —
чистая, без сети, **главный предмет юнит-тестов** (детерминированная, как
`compute_staging_verdict`): `DEGRADED` если `≥ fail_threshold` ПОСЛЕДОВАТЕЛЬНЫХ
провалов health (AC-4) ИЛИ доля 5xx на окне `> 5xx_threshold` (AC-5). Иначе
`HEALTHY` (одиночный провал < порога с восстановлением → HEALTHY, AC-3/AC-6).
- **`decide_action(repo, verdict) -> "NONE"|"ROLLBACK"|"ALERT_ONLY"`** — чистая:
`HEALTHY → NONE`; `DEGRADED` + self-hosting → `ALERT_ONLY` (BR-5/AC-8, ВСЕГДА);
`DEGRADED` + не-self + `post_deploy_auto_rollback=True``ROLLBACK`; иначе →
`ALERT_ONLY`.
- **Sentinel-state хелперы** (state-dir `.post-deploy-state-<repo>/<wi>/`, по образцу
`self_deploy._state_dir`): `armed`, `series` (JSON-список результатов опросов,
append каждый тик — restart-safe счётчики), `done`. `read_series`/`append_probe`/
`mark_done`/`has_marker` — never-raise.
- **`write_post_deploy_log(...)`** — артефакт `16-post-deploy-log.md`, best-effort
(по образцу `self_deploy.write_deploy_log`).
- **`build_rollback_command(repo)`** — argv хука `--rollback` с прод-env (как
`build_deploy_command`, но action=`--rollback`; переиспользует `deploy_prod_*`).
### 4. Исполнение тика — `stage_engine.run_post_deploy_monitor(job)` + перехват в launcher
По образцу `run_deploy_finalizer` / `_run_deploy_finalizer_job`:
`launcher.launch_job` перехватывает `agent == "post-deploy-monitor"` ДО `_spawn`
`stage_engine.run_post_deploy_monitor(job)`. Алгоритм тика (never-raise):
1. `mark_done` уже стоит → no-op (AC-15, защита от дубля).
2. `probe = post_deploy.probe_signals(base_url)`; `append_probe(series, probe)`.
3. `verdict = classify(series, ...)`.
4. **Если `HEALTHY` и окно не истекло** (число тиков < `window_s/interval_s`) →
перепостановка `post-deploy-monitor` через `available_at_delay_s=interval_s`
(как finalizer defer; счётчик тиков — из jobs-очереди/`series`, restart-safe).
5. **Если `HEALTHY` и окно истекло** → исход `NONE`, `write_post_deploy_log(HEALTHY,
NONE)`, `mark_done`, нотификация «окно завершилось чисто» (BR-6/AC-17).
6. **Если `DEGRADED`** → `action = decide_action(...)`; исполнить реакцию (§5),
`write_post_deploy_log`, `mark_done`, нотификации.
`mark_done` + sentinel `armed` дают идемпотентность; jobs-очередь +
`requeue_running_jobs` + `series` дают restart-safe (AC-15). Бюджет тиков bounded
(`window_s/interval_s`) — анти-livelock, как `deploy_finalize_max_attempts`.
### 5. Реакция на деградацию
- **Self-hosting (`orchestrator`), всегда (BR-5/AC-8):** `ALERT_ONLY`. НЕ откатывать
и НЕ рестартить прод-контейнер в тике. Громкий Telegram + Plane-коммент с запросом
ручного approve отката (по образцу deploy Phase A CTA). `action_taken: ALERT_ONLY`.
Откат самого прод-орка (если оператор решит) — ТОЛЬКО через detached host-процесс
(контейнер не откатит себя, умирая); переиспользуется механика
`self_deploy.initiate_deploy`, но в MVP она вне тика наблюдения (ручной approve →
отдельный путь, как ORCH-54 для авто-deploy). Тик self НИКОГДА не запускает хук
`--rollback` (структурный инвариант).
- **Не-self + `post_deploy_auto_rollback=True` (AC-7):** вызвать хук `--rollback` с
прод-env (`build_rollback_command`). Маппинг exit-code по смыслу
`map_exit_code_to_status`: `0 → ROLLBACK_OK`; `1/2 → ROLLBACK_FAILED` + громкий
Telegram о необходимости ручного вмешательства (AC-9). Целевой контейнер не есть
orchestrator → его рестарт безопасен для конвейера.
- **Не-self + auto_rollback=False (дефолт):** `ALERT_ONLY`.
### 6. Артефакт `16-post-deploy-log.md` (новый, машиночитаемый)
YAML-frontmatter (канон гейтов; для петли уроков ORCH-8, BR-10):
```
---
post_deploy_status: HEALTHY | DEGRADED
action_taken: NONE | ROLLBACK_OK | ROLLBACK_FAILED | ALERT_ONLY
work_item: <plane-id>
window_s: <int>
checks_total: <int>
checks_failed: <int>
---
```
Тело — человекочитаемая сводка опросов. Best-effort (отсутствие файла ничего не роняет,
AC-13). **Не** читается ни одним гейтом — наблюдение происходит после `done`.
### 7. Конфигурация — `src/config.py` (env-префикс `ORCH_`)
- `post_deploy_monitor_enabled: bool = True` — глобальный kill-switch (BR-8/AC-10).
- `post_deploy_repos: str = ""` — CSV применимых репо; пусто → только self-hosting.
- `post_deploy_window_s: int = 900` — окно наблюдения (~15 мин, BR-1).
- `post_deploy_interval_s: int = 30` — интервал опросов.
- `post_deploy_fail_threshold: int = 3` — N послед. провалов health → DEGRADED.
- `post_deploy_5xx_threshold: float = 0.5` — порог доли 5xx → DEGRADED.
- `post_deploy_auto_rollback: bool = False` — глоб. разрешение авто-отката (для self
всегда требует approve, BR-5).
- `post_deploy_base_url: str = "http://localhost:8500"` — наблюдаемый прод.
- Параметры отката — переиспользовать существующие `deploy_prod_*` (новых дублей нет).
### 8. Наблюдаемость — блок `post_deploy` в `GET /queue` (BR-9/AC-14)
По образцу блока `reconcile` (метод `status()`): `enabled`, `window_s`, `interval_s`,
активные наблюдения (по sentinel `armed` без `done`), последний исход
(`post_deploy_status`/`action_taken`). Best-effort, never-raise.
### Инварианты (НЕ меняются)
`STAGE_TRANSITIONS`, реестр `QG_CHECKS`, `check_deploy_status`/`_parse_deploy_status`,
момент вердикта `deploy_status`, БАГ-8 откат, terminal-sync `deploy → done`, merge-gate,
exit-code-контракт хука (0/1/2), схема БД. Условность как ORCH-35/36/43/58. Never-raise
во всём наблюдении (AC-16). Тик self НИКОГДА не рестартит прод-контейнер (AC-8).
## Альтернативы
- **Daemon-watchdog (как reconciler)** — отклонён: per-task серия в памяти не
restart-safe; restart-safe-вариант требует тех же sentinel-счётчиков → reserved-agent
проще и уже проверен.
- **Отдельная пост-deploy стадия + QG** — отклонён: меняет реестры (AC-12), ломает
семантику терминального `done`; наблюдение принципиально ПОСЛЕ `done`.
- **Авто-rollback прод-орка из тика** — отклонён (BR-5): контейнер не откатит себя
надёжно; групповой риск для всех проектов. Self → только ALERT + ручной approve.
- **Новая колонка в `tasks` для отметки наблюдения** — отклонён: миграция на проде
(риск, как в adr-0007); sentinel-файлы достаточны и restart-safe (как ORCH-36/53/58).
- **Прометей/APM** — вне рамок (BR out-of-scope): опираемся на существующие
HTTP-эндпоинты, не вводим сбор метрик.
## Последствия
- Класс «зелёный деплой, красный прод» закрыт измеримыми порогами; деградация —
машиночитаемый сигнал для петли уроков (ORCH-8).
- Плюс: максимальное переиспользование проверенной finalizer/sentinel/hook-машинерии;
нулевая миграция БД; реестры не тронуты; дефолты безопасны (auto-rollback off, self
только alert).
- Минус/ограничение: монитор self бежит ВНУТРИ наблюдаемого прод-контейнера — если
контейнер полностью wedged, worker может не выполнить тик и алерта не будет (gap).
Это known limitation MVP; внешний независимый watchdog — follow-up (вне рамок).
- Минус: каждый тик на короткое время занимает single-worker (`max_concurrency=1`);
митигируется коротким опросом (~секунды) и `interval_s` между тиками (defer не держит
worker), как finalizer.
- Доменный smoke результата фичи (BR-11) — follow-up; MVP = health + 5xx.
## Связи
- **ET-8** — обоснование (deploy SUCCESS, прод не работает).
- **adr-0007-executable-self-deploy** (ORCH-36) — sentinel-паттерн, detached
host-процесс, `map_exit_code_to_status`, deploy-finalizer reserved-agent (образец).
- **adr-0007-reconciler** (ORCH-53) — daemon/`status()` образец (рассмотрен и отклонён
как основной механизм; `status()`-снимок в `/queue` переиспользуется).
- **adr-0006-merge-gate** / **adr-0003-staging-gate** — образец условности и флагов
раската (`*_enabled` + `*_repos`).
- **adr-0008-staging-image-provenance** — `.deploy-prev-image` / хук-механика отката.
- **ORCH-8** — петля уроков (потребитель `16-post-deploy-log.md`).
- **ORCH-54** — будущий полный авто (включая авто-approve отката self), по аналогии
с авто-deploy.

View File

@@ -0,0 +1,56 @@
# 07 — Инфраструктурные требования (ORCH-021)
> Топология НЕ меняется. Фича опирается на уже существующие HTTP-эндпоинты прода и
> существующий деплой-хук. Этот документ фиксирует, какие инфра-предпосылки должны
> выполняться, чтобы наблюдение и реакция работали.
## 1. Топология — без изменений
- Прод `orchestrator` (8500), staging `orchestrator-staging` (8501), один сервер
mva154 (см. `docs/operations/INFRA.md`). Новых контейнеров/портов/сервисов нет.
- Наблюдение — внутрипроцессный reserved-agent job в worker'е прод-контейнера.
Daemon-потоков не добавляется (в отличие от reconciler).
## 2. Наблюдаемый прод — HTTP-эндпоинты
- Монитор опрашивает `post_deploy_base_url` (дефолт `http://localhost:8500`):
- `GET /health` → ожидается HTTP 200 + тело `{"status":"ok"}` (BR-2);
- `GET /status`, `GET /queue` → учёт доли HTTP 5xx (BR-2).
- Эндпоинты уже существуют (`src/main.py`). Новых эндпоинтов фича НЕ вводит
(out-of-scope APM/метрики).
- Для self-hosting `base_url=localhost:8500` означает: монитор бьёт по собственному
контейнеру. Это допустимо для MVP (см. риск R-1 в `10-tech-risks.md`).
## 3. Деплой-хук `--rollback` — предпосылки реакции
- Реакция ROLLBACK (только не-self + `post_deploy_auto_rollback=True`) вызывает
`scripts/orchestrator-deploy-hook.sh --rollback` с прод-env (переиспользуются
`deploy_prod_*`: `TARGET_SERVICE`/`TARGET_PORT`/`TARGET_IMAGE`/`COMPOSE_PROFILE`/
`PREV_IMAGE_FILE`), по образцу `self_deploy.build_deploy_command`.
- Предпосылка: при штатном деплое хук сохраняет предыдущий образ в
`PREV_IMAGE_FILE` (`.deploy-prev-image-prod`). Без снимка → хук вернёт exit 1
(«нет prev-образа») → `ROLLBACK_FAILED` + алерт (AC-9). Контракт exit-кодов хука
(0/1/2) НЕ меняется.
- **Self-hosting:** откат прод-орка хуком в тике ЗАПРЕЩЁН (контейнер не откатит себя,
умирая). Если оператор по алерту решит откатить — только detached host-процесс
(ssh + setsid, механика `self_deploy.initiate_deploy`), как у Phase B самодеплоя.
Предпосылки для detached-пути (ssh-доступ host, shared-mount state-dir) уже
выполнены для ORCH-36; в MVP detached-откат self вне тика наблюдения.
## 4. Restart-safe состояние — shared mount
- Состояние наблюдения — sentinel-файлы под `.post-deploy-state-<repo>/<wi>/`
(`armed`, `series`, `done`) на том же mount `settings.repos_dir`, что и
`.deploy-state-*` (ORCH-36). Миграции БД нет (см. `08-data-requirements.md`).
- `requeue_running_jobs` (ORCH-1) восстанавливает claimed `post-deploy-monitor` job
после рестарта; `series` хранит счётчики опросов → наблюдение продолжается
с того же места (BR-7/AC-15).
## 5. Конфигурация окружения (env `ORCH_*`)
Новые ключи (дефолты безопасны, в `.env`/`.env.staging` по необходимости):
`post_deploy_monitor_enabled` (kill-switch, дефолт true), `post_deploy_repos` (CSV,
пусто → self-hosting), `post_deploy_window_s` (900), `post_deploy_interval_s` (30),
`post_deploy_fail_threshold` (3), `post_deploy_5xx_threshold` (0.5),
`post_deploy_auto_rollback` (false), `post_deploy_base_url` (localhost:8500).
Параметры отката — существующие `deploy_prod_*`, новых дублей не вводить.
## 6. Чего НЕ требуется
- Новых контейнеров, портов, сетевых правил, секретов.
- Prometheus / Grafana / APM (out-of-scope).
- Изменений compose-топологии или деплой-пути не-self репо.

View File

@@ -0,0 +1,40 @@
# 08 — Требования к данным / схеме БД (ORCH-021)
## Вывод: миграция БД НЕ требуется
Состояние наблюдения хранится в **sentinel-файлах** (restart-safe, без миграции —
по образцу ORCH-36/53/58), а не в таблицах. Реестры и схема не меняются (AC-12).
## 1. Существующие таблицы — без изменений
- `events`, `tasks`, `agent_runs`, `jobs` — структура не меняется.
- В `tasks` НЕ вводится колонка статуса/окна наблюдения (намеренно — миграция на
проде = риск, как обосновано в adr-0007; альтернатива отклонена в ADR-001 §Альтернативы).
## 2. Очередь `jobs` — переиспользование, без схемы
- `post-deploy-monitor` — новый **job-kind** (значение в существующей колонке
`agent`/`task_content`), НЕ новая колонка. Ставится через существующий
`enqueue_job(..., available_at_delay_s=...)` (ORCH-1).
- Счётчик тиков/деферов восстанавливается из jobs-очереди (как
`_deploy_finalize_defer_count` считает по `task_content LIKE`), restart-safe.
## 3. Sentinel-состояние (файлы, не БД)
State-dir `.post-deploy-state-<repo>/<work_item_id>/` на `settings.repos_dir`
(по образцу `.deploy-state-*`):
| Файл | Назначение |
|------|------------|
| `armed` | наблюдение заармлено (идемпотентность арма; калька `INITIATED`) |
| `series` | JSON-список результатов опросов (счётчики health-fail / 5xx; restart-safe) |
| `done` | наблюдение завершено (защита от повторной обработки) |
Все обращения — never-raise (по образцу `self_deploy.has_marker`/`write_marker`/
`read_result`). Отсутствие/битость файла → консервативный фоллбэк, не исключение.
## 4. Артефакт `16-post-deploy-log.md` — файл репозитория, не БД
Машиночитаемый YAML-frontmatter (`post_deploy_status`, `action_taken`, `window_s`,
`checks_total`, `checks_failed`) пишется best-effort в `docs/work-items/<id>/`; в БД
не реплицируется. Источник для петли уроков ORCH-8 (BR-10).
## 5. Очистка состояния
По завершении окна / реакции `done`-маркер ставится; state-dir можно чистить
best-effort (по образцу `self_deploy.clear_state`) — необязательно для корректности,
но желательно для гигиены. Stale-`armed` без `done` после краха → виден в `/queue`
как «активное наблюдение» и доигрывается восстановленным job'ом.

View File

@@ -0,0 +1,20 @@
# 10 — Технические риски (ORCH-021)
| # | Риск | Вероятн. | Влияние | Митигация |
|---|------|----------|---------|-----------|
| R-1 | **Монитор self бежит внутри наблюдаемого прода.** Полностью wedged прод-контейнер → worker не выполнит тик → деградация не замечена, алерта нет. | Сред. | Высок. | Known MVP limitation (зафиксировано в ADR-001 §Последствия). Health в момент рестарта (хук) + reconciler ловят часть случаев. Внешний независимый watchdog — follow-up (вне рамок). |
| R-2 | **Ложный авто-rollback** по сетевому глюку. | Низк. | Высок. | Пороги по N ПОСЛЕДОВАТЕЛЬНЫХ провалов + доля 5xx на окне (BR-3/AC-6), а не разовый провал. Self ВСЕГДА `ALERT_ONLY` (BR-5). `auto_rollback=False` по умолчанию. |
| R-3 | **Авто-rollback прод-орка убивает инструмент всех проектов.** | Низк. | Критич. | Структурный инвариант: тик self НИКОГДА не откатывает/рестартит прод-контейнер (AC-8). Self → только alert + ручной approve. Откат self — только detached host-процесс вне тика. |
| R-4 | **Нет prev-образа** при ROLLBACK → откат невозможен. | Сред. | Сред. | Хук возвращает exit 1 → `ROLLBACK_FAILED` + громкий алерт (AC-9), деградация не проглатывается тихо. |
| R-5 | **Дубль/потеря наблюдения** при двойном webhook / рестарте. | Сред. | Сред. | Идемпотентность: sentinel `armed` (арм-гард) + `done` (защита от повторной обработки) + restart-safe jobs-очередь + `series` (AC-15). По образцу finalizer. |
| R-6 | **Исключение в наблюдении роняет worker / конвейер других проектов.** | Низк. | Высок. | Контракт never-raise во всём `post_deploy.py` и `run_post_deploy_monitor` (AC-16), по образцу `self_deploy`/`staging_verdict`. |
| R-7 | **Тик занимает single-worker** (`max_concurrency=1`) → задержка других задач. | Низк. | Низк. | Опрос короткий (~секунды), между тиками job не выполняется (defer через `available_at_delay_s`) — worker свободен, как у finalizer. Окно bounded (`window_s/interval_s`). |
| R-8 | **Скрытое изменение контракта** (реестры/гейты/exit-коды/схема). | Низк. | Высок. | Инвариант: `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_deploy_status`/terminal-sync/merge-gate/exit-коды/схема БД НЕ меняются (AC-12). Существующие тесты deploy/staging/merge-gate должны остаться зелёными. |
| R-9 | **5xx на `/queue`/`/status` из-за самого монитора** (рекурсивная нагрузка). | Низк. | Низк. | Интервал `post_deploy_interval_s` (30с) — низкая частота; опрос лёгкий GET. |
| R-10 | **Артефакт `16-post-deploy-log.md` не пишется / невалиден** → петля уроков без данных. | Низк. | Низк. | Best-effort запись с валидным frontmatter (AC-13); отсутствие файла ничего не роняет. Парсинг — defensive. |
## Эскалация
- Изменение помечено `arch:major-change` (новая под-компонента `src/post_deploy.py`
+ новый reserved-agent job-kind `post-deploy-monitor`).
- R-1 (gap наблюдения для wedged self-контейнера) — кандидат на отдельную задачу
(внешний watchdog), вне рамок ORCH-021.

View File

@@ -0,0 +1,99 @@
---
type: review
work_item_id: ORCH-021
verdict: APPROVED
version: 2
---
# Review ORCH-021 — Post-deploy мониторинг прода + реакция на деградацию
## Summary
Реализация продлевает ответственность конвейера ЗА терминальный переход
`deploy → done`, закрывая класс инцидентов «зелёный деплой, красный прод» (ET-8).
Механизм — детерминированный reserved-agent job `post-deploy-monitor` (вариант B
из ADR-001, точная калька `deploy-finalizer`): арм в `stage_engine.advance_stage`
(блок `next_stage == "done"`), один тик = один job (перехват в
`launcher.launch_job` ДО `_spawn``stage_engine.run_post_deploy_monitor`),
чистая логика в новом leaf-модуле `src/post_deploy.py` (never-raise).
Проверены все четыре оси. Реализация соответствует ТЗ (`02-trz.md`), ADR-001 и
глобальному adr-0010, удовлетворяет всем критериям приёмки AC-1…AC-18.
Документация (golden-source) обновлена в том же PR. Регрессов нет.
## Соответствие ТЗ
- §2.1 `src/post_deploy.py` (leaf, never-raise): `post_deploy_applies`,
`probe_signals`, `classify`, `decide_action`, sentinel-state, артефакт,
`build_rollback_command` — все на месте. ✅
- §2.2 Оркестрация: арм в terminal-блоке + reserved-agent тик с
само-перепостановкой через `available_at_delay_s`; restart-safe (sentinel
`armed`/`series`/`done` + jobs-очередь). ✅
- §2.3 Реакция: non-self+auto → хук `--rollback` (синхронно, целевой ≠ orch);
self-hosting → ВСЕГДА `ALERT_ONLY`. ✅
- §2.4 Конфигурация: все `post_deploy_*` в `src/config.py`, дефолты безопасны
(kill-switch on, auto-rollback off), параметры отката переиспользуют
`deploy_prod_*`. ✅
- §2.5 Артефакт `16-post-deploy-log.md` с машиночитаемым frontmatter,
best-effort. ✅
- §2.6 Блок `post_deploy` в `GET /queue`. ✅
- §2.7/§2.8/§3 Инварианты: `STAGE_TRANSITIONS`, `QG_CHECKS`,
`check_deploy_status`, terminal-sync, merge-gate, exit-code-контракт хука,
схема БД — не тронуты (подтверждено зелёным полным прогоном). ✅
## Соответствие ADR
Реализация 1:1 повторяет ADR-001: механизм (reserved-agent, не стадия/не daemon),
точки интеграции, пороги BR-3, политика реакции BR-5 (self never auto-rollback —
структурный инвариант в `decide_action` + отсутствие вызова `run_rollback` на
ALERT_ONLY). Нарушений глобальных ADR не выявлено.
## Качество кода
- Контракт never-raise выдержан во всех публичных функциях и в каждой ветке
`run_post_deploy_monitor`; launcher оборачивает тик в доп. guard (AC-16).
- `classify` fail-safe → HEALTHY на мусорном входе (ложный DEGRADED опаснее).
- Docstrings содержательные, со ссылками на AC/BR.
- Условность раската по образцу ORCH-35/36/43/58 (флаг + CSV-репо).
## Тесты
30 тестов ORCH-021 (`tests/test_post_deploy.py`,
`tests/test_post_deploy_integration.py`) — содержательные, покрывают
классификацию (AC-3..6), self-hosting safety (TC-19 явно проверяет, что хук
`--rollback` НЕ вызывается для self — AC-8), idempotency двойного арма (AC-15),
kill-switch/условность (AC-2/10/11), exit-code маппинг (AC-9), frontmatter
артефакта (AC-13), never-raise (AC-16), `/queue` (AC-14). Полный прогон
`pytest tests/`**701 passed** (регрессов нет, AC-12).
## Findings
### P0 — Blocker
- нет
### P1 — Must fix
- нет
### P2 — Should fix
- нет
### P3 — Nice to have
- [ ] `run_post_deploy_monitor`: в ветке `ALERT_ONLY` для **не-self** репо при
`post_deploy_auto_rollback=false` текст алерта упоминает «авто-rollback для
self-hosting запрещён (BR-5)», что для не-self случая формулировка не совсем
точна (косметика сообщения; на поведение не влияет).
- [ ] `write_post_deploy_log` коммитит/пушит артефакт в ветку задачи, которая к
моменту наблюдения уже слита/может быть удалена — артефакт может не попасть в
`main`. Контракт best-effort соблюдён (never-raise, ничего не роняет); как
улучшение наблюдаемости — рассмотреть запись лог-артефакта отдельным путём.
## Документация
Обновлено в том же PR (golden-source, AC-18 — PASS):
- `CLAUDE.md``16-post-deploy-log.md` добавлен в перечень артефактов;
- `docs/architecture/README.md` — раздел «Post-deploy наблюдение прода» + блок
`post_deploy` в таблице API `/queue`;
- `docs/architecture/adr/adr-0010-post-deploy-monitor.md` — новый сквозной ADR;
- `docs/work-items/ORCH-021/06-adr/ADR-001-post-deploy-monitor.md` — детальный ADR;
- `CHANGELOG.md` — запись в `Added` (+ fix Dockerfile `COPY data/`);
- `README.md` / `.env.example` — все `ORCH_POST_DEPLOY_*` env задокументированы.
Изменение `src/` сопровождено обновлением документации — правило CLAUDE.md №2/№6
выполнено.
## Вердикт
Только P3 (nice-to-have) findings, блокеров и must-fix нет → **APPROVED**.

View File

@@ -0,0 +1,82 @@
---
type: test-report
work_item_id: ORCH-021
result: PASS
---
# Test Report — ORCH-021
Post-deploy наблюдение прода + реакция на деградацию (reserved-agent job
`post-deploy-monitor`, leaf-модуль `src/post_deploy.py`).
## Окружение
- Python: 3.12.13
- pytest: 8.3.3 (asyncio mode=AUTO, anyio 4.13.0)
- Ветка: feature/ORCH-021-post-deploy-rollback
- Дата: 2026-06-07
## Прогон
- `pytest tests/ -v --tb=short`**701 passed, 1 warning** (Pydantic V2 deprecation, не относится к задаче).
- Целевые модули `tests/test_post_deploy.py` + `tests/test_post_deploy_integration.py`**30 passed**.
## Smoke-test (read-only, прод 8500)
`curl` в окружении недоступен — опрос через `python urllib` (read-only, прод-контейнер не трогается).
| Эндпоинт | Результат |
|----------|-----------|
| `GET /health` | 200 `{"status":"ok","service":"orchestrator"}` |
| `GET /status` | 200, активная задача ORCH-021 на стадии `testing` |
| `GET /queue` | 200, counts/resilience/reconcile присутствуют |
> Примечание: блок `post_deploy` в **живом** `/queue` отсутствует — это ожидаемо: прод
> сейчас работает на коде ДО ORCH-021 (задача ещё не задеплоена, стадия testing).
> Наличие блока (AC-14) проверяется интеграционным тестом TC-20 против кода ветки → PASS.
> Smoke-проверка подтверждает живость окружения, не версию ветки.
## Результаты по тест-плану (04-test-plan.yaml)
| TC ID | Описание | Покрывает AC | Тест-функция | Результат |
|-------|----------|--------------|--------------|-----------|
| TC-01 | HEALTHY: серия без провалов < порога | AC-3 | test_tc01_healthy_no_failures | PASS |
| TC-02 | DEGRADED: N посл. провалов health == threshold | AC-4 | test_tc02_degraded_consecutive_health_failures | PASS |
| TC-03 | DEGRADED по 5xx при health=200 | AC-5 | test_tc03_degraded_by_5xx_ratio_even_when_health_200 | PASS |
| TC-04 | Нет ложного срабатывания: одиночный глюк + восстановление | AC-6 | test_tc04_no_false_trip_single_glitch_then_recovery | PASS |
| TC-05 | Пороги из Settings меняют вердикт на тех же данных | AC-11 | test_tc05_thresholds_change_verdict_on_same_data, test_classify_uses_settings_thresholds | PASS |
| TC-06 | не-self + auto_rollback=True + DEGRADED → ROLLBACK | AC-7 | test_tc06_nonself_auto_rollback_degraded_rolls_back | PASS |
| TC-07 | self-hosting + DEGRADED → ALERT_ONLY (никогда не авто-rollback) | AC-8 | test_tc07_self_hosting_degraded_never_rolls_back | PASS |
| TC-08 | HEALTHY → NONE для любого репо | AC-3 | test_tc08_healthy_means_none_for_any_repo, test_nonself_default_policy_alert_only | PASS |
| TC-09 | post_deploy_applies: пусто → только orchestrator | AC-2 | test_tc09_applies_empty_repos_only_self_hosting, test_tc09_applies_explicit_repos_csv | PASS |
| TC-10 | kill-switch: monitor_enabled=False → applies()=False для всех | AC-10 | test_tc10_kill_switch_disables_for_everyone | PASS |
| TC-11 | Откат exit 0 → ROLLBACK_OK | AC-7 | test_tc11_rollback_exit0_is_ok | PASS |
| TC-12 | Откат exit 1/2 → ROLLBACK_FAILED + эскалация | AC-9 | test_tc12_rollback_exit_nonzero_is_failed | PASS |
| TC-13 | 16-post-deploy-log.md: валидный YAML-frontmatter | AC-13 | test_tc13_log_frontmatter_parses | PASS |
| TC-14 | Опрос при сетевой ошибке → консервативный, не raise | AC-16 | test_tc14_probe_network_error_is_conservative_not_raise, test_tc14_classify_junk_input_swallowed | PASS |
| TC-15 | Ошибка записи артефакта → False, не raise | AC-16, AC-13 | test_tc15_write_log_no_worktree_returns_false | PASS |
| TC-16 | advance_stage deploy→done армит наблюдение (self), не армит (non-self) | AC-1, AC-2 | test_tc16_arm_for_self_hosting, test_tc16_no_arm_for_nonself, test_tc16_no_arm_when_kill_switch_off | PASS |
| TC-17 | Идемпотентность: повторный арм не задваивает | AC-15 | test_tc17_double_arm_is_noop | PASS |
| TC-18 | Полный цикл DEGRADED → не-self откат + лог + уведомление | AC-7, AC-13, AC-17 | test_tc18_degraded_nonself_rolls_back | PASS |
| TC-19 | Self-hosting DEGRADED → НЕ рестарт/откат, алерт+approve | AC-8, AC-17 | test_tc19_degraded_self_hosting_alert_only | PASS |
| TC-20 | GET /queue содержит блок post_deploy | AC-14 | test_tc20_queue_block_present | PASS |
| TC-21 | Регресс: deploy/staging/merge-gate/reconciler зелёные; STAGE_TRANSITIONS/QG_CHECKS не изменены | AC-12 | tests/test_stages.py (+ полный прогон 701) | PASS |
Доп. тесты ветки (не из плана, подтверждают контракты): `test_series_append_and_read_roundtrip`,
`test_mark_done_idempotency_marker`, `test_healthy_tick_requeues_without_finishing`,
`test_finished_window_tick_is_noop` — все PASS.
## Покрытие критериев приёмки
AC-1…AC-18 — все покрыты прошедшими тестами (см. таблицу). AC-12 (реестры/схема БД
не изменены) дополнительно подтверждён зелёным полным регрессом 701 теста, включая
deploy/staging/merge-gate/reconciler. AC-18 (документация) — вне scope прогона тестов,
подтверждён ревью (12-review.md, verdict APPROVED).
## Вывод pytest (хвост)
```
======================= 701 passed, 1 warning in 12.71s ========================
```
```
======================== 30 passed, 1 warning in 0.58s =========================
```
## Итог
**PASS.** Все 21 тест-кейс плана зелёные, полный регресс (701) зелёный, smoke прод-эндпоинтов
OK (окружение живо). Существующие контракты не сломаны. Задача готова к стадии deploy-staging.

View File

@@ -0,0 +1,42 @@
---
staging_status: SUCCESS
timestamp: 2026-06-07T14:37:33Z
base_url: http://localhost:8501
---
# Staging Gate Log
Staging test suite completed. Verdict: **SUCCESS** (exit 0).
Run canonically inside the `orchestrator-staging` container (ORCH-048, ADR-001)
via the Docker Engine API over the mounted socket (`docker` CLI is not installed
in the prod-agent container; `network_mode: host` + group `999` allow direct
socket access):
```
python3 /repos/orchestrator/scripts/staging_check.py \
--base-url http://localhost:8501 --mode stub
```
## Result
```
RESULT: 8/10 checks PASS
REAL failed : none
SANDBOX_INFRA failed: ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue']
tolerance: staging_infra_tolerance_enabled=True
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 ok, A2 `/queue` 200, A3 `ORCH_STAGING=true` — all PASS.
- **Block B (ACCESS):** B4 Plane sandbox, B5 Gitea `orchestrator-sandbox` (push=true),
B6 registry isolation (sandbox present, prod ET/ORCH absent) — all PASS.
- **Block C (E2E, stub):** C7 create issue in SANDBOX, C8 trigger pipeline via
`/webhook/plane` — PASS. C9a/C9b FAILED but are sandbox-infra checks (bot accounts
not members of the SANDBOX Plane project) — **waived** per ORCH-061; not a pipeline
regression. Cleanup deleted the test Plane issue (HTTP 204).
All REAL pipeline checks are green; the only failures are the two known
sandbox-infra checks, which the verdict tolerates (`staging_infra_tolerance_enabled=true`).
The script exited 0 → advance.

View File

@@ -0,0 +1,7 @@
# Business Request: Reconciler не должен трогать escalated / max-retries задачи
Work Item ID: ORCH-060
## Description
TBD

View File

@@ -0,0 +1,90 @@
# BRD: Reconciler не должен трогать escalated / max-retries задачи
Work Item ID: ORCH-060
Стадия: analysis → architecture
Связано: ORCH-053 (reconciler), ORCH-046 (retry-счётчик), ORCH-047 (BLOCKED-вердикт)
## 1. Контекст и проблема
ORCH-053 ввёл фоновый reconciler (`src/reconciler.py`) — sweeper, доигрывающий
пропущенные webhook-переходы. Слой F-1 (`reconcile_gate_once`
`_reconcile_gate_task`) для каждой не-терминальной задачи (`stage != 'done'`) без
активного job и старше grace делает read-only пред-оценку канонического QG; если
гейт зелёный → `advance_if_gate_passed``advance_stage(..., finished_agent=None)`.
**Дефект.** Задача, исчерпавшая лимит developer-ретраев
(`_developer_retry_count(task_id) >= MAX_DEVELOPER_RETRIES = 3`), **escalated**
но эскалация в обработчиках Gitea (`src/webhooks/gitea.py:280` для CI-failure,
`:371` для review REQUEST_CHANGES) выполняет ТОЛЬКО `notify_error(...)`:
- стадия НЕ меняется (остаётся `development`);
- терминального маркера в БД нет (нет `blocked`-флага в таблице `tasks`);
- активного job нет.
Для reconciler такая задача неотличима от «застрявшей из-за потерянного webhook».
Если CI к этому моменту зелёный (типичный кейс: разработчик починил CI, но reviewer
продолжал слать REQUEST_CHANGES → ушли в лимит), F-1 каждые `reconcile_interval_s`
(120 с) видит зелёный `check_ci_green` и **разблокирует** задачу `development → review`.
Reviewer снова REQUEST_CHANGES → откат на `development` → снова эскалация (стадия
не меняется). Следующий тик — снова разблокировка. Бесконечный цикл.
**Реальный инцидент (наблюдение 0607.06.2026).** ET-013 разблокирована
reconciler'ом **10 раз за ночь**, в итоге всё равно escalated — бесполезный поллинг
каждые 2 минуты, лишние запуски агентов (токены, деньги), шум в Telegram
(`reconcile_notify_unblock`), нагрузка на конвейер общего инстанса (self-hosting:
один инстанс обслуживает ORCH + enduro-trails).
Симметричный риск: задача, которую человек/агент явно перевёл в Plane-статус
**Blocked** или **Needs Input** (ручной гейт), не должна автоматически
разблокироваться reconciler'ом до вмешательства человека.
## 2. Бизнес-цель
Reconciler (F-1) обязан **пропускать** (не трогать) задачи, которые:
1. исчерпали лимит developer-ретраев (`_developer_retry_count >= MAX_DEVELOPER_RETRIES`), и/или
2. находятся в явном «человеческом»/терминальном Plane-статусе **Blocked** / **Needs Input**.
Такие задачи ждут ручного вмешательства; автоматический sweeper их игнорирует.
## 3. Заинтересованные стороны
- **Owner проекта** — прекращение «фантомной» активности и шума по escalated-задачам.
- **Другие проекты на инстансе (enduro-trails)** — снижение паразитной нагрузки общей очереди.
- **Агенты-разработчики оркестратора** — корректная семантика терминального состояния.
## 4. Объём (Scope)
### Входит
- Гард в F-1 (`_reconcile_gate_task` / `advance_if_gate_passed`), который ДО
оценки гейта и вызова `advance_stage` пропускает escalated-задачи
(retry-count >= лимит) — детерминированно, без сети.
- Гард, пропускающий задачи в Plane-статусе Blocked / Needs Input.
- Тесты (unit) на оба условия + регресс happy-path и отсутствия спама/нотификаций.
- Обновление документации: `docs/architecture/README.md` (описание F-1),
per-work-item ADR, `CHANGELOG.md`.
### Не входит
- Изменение порога `MAX_DEVELOPER_RETRIES` или логики самой эскалации в `gitea.py`.
- Изменение F-2 plane-side по существу (F-2 уже реагирует только на
in_progress/approved/rejected, то есть Blocked/Needs Input им не доигрываются —
достаточно регресс-теста, фиксирующего это поведение).
- Реестры `STAGE_TRANSITIONS` / `QG_CHECKS`, схема прочих стадий.
## 5. Допущения и ограничения
- **Инвариант reconciler (ORCH-053):** схема БД и реестры не меняются. Решение
должно либо обойтись без миграции, либо архитектор обязан явно обосновать
необходимость нового столбца как терминального маркера.
- **Never-raise:** гард не должен ломать тик; любая ошибка вычисления условия →
безопасный фоллбэк (не трогать задачу — консервативно).
- **self-hosting:** нельзя ронять/рестартить прод-контейнер; изменение — чисто
логика sweeper'а, деплой через staging (8501) по канону.
- Источник истины по retry — `agent_runs` (как у `_developer_retry_count`).
## 6. Критерий успеха (бизнес)
После выката на конкретной escalated-задаче (как ET-013): за ночь — **0**
строк `reconciler: <wi> ... разблокирована`, **0** повторных запусков агентов,
**0** Telegram-нотификаций разблокировки; задача спокойно ждёт человека в
`development`/Blocked. При этом штатные «честно застрявшие» задачи
(retry < лимита, не Blocked) reconciler по-прежнему доигрывает.

View File

@@ -0,0 +1,113 @@
# ТЗ: Reconciler пропускает escalated / max-retries / blocked-needs-input задачи
Work Item ID: ORCH-060
Стадия: analysis → architecture (архитектор фиксирует механику в ADR)
## 1. Задействованные модули `src/`
| Модуль | Роль в задаче |
|--------|---------------|
| `src/reconciler.py` | **Основное изменение.** F-1: `Reconciler._reconcile_gate_task` — добавить пред-проверки (escalated / blocked / needs-input) ДО `advance_if_gate_passed`. |
| `src/stage_engine.py` | Источник `MAX_DEVELOPER_RETRIES` (=3) и `_developer_retry_count(task_id)`. Кандидат на промоут приватного хелпера в переиспользуемый (решает архитектор). |
| `src/db.py` | Чтение состояния задачи (`get_active_tasks_for_reconcile` уже отдаёт строки `tasks`); возможный новый read-helper для retry-count, если решено не импортировать приватный из stage_engine. |
| `src/plane_sync.py` | Маппинг Plane-статусов (`PLANE_STATES`, `get_project_states`): `blocked`, `needs_input`. Источник для проверки «человеческого» статуса, если архитектор выберет проверку через Plane API. |
| `src/webhooks/gitea.py` | НЕ меняется (только справочно: точки эскалации `:280`, `:371`). |
## 2. Требуемое поведение (контракт F-1)
`Reconciler._reconcile_gate_task(task)` ДО вызова `advance_if_gate_passed(...)`
обязан вернуться (пропустить задачу, ничего не делая, не инкрементируя
`unblocked_total`, не слать нотификации), если выполнено ЛЮБОЕ из условий:
1. **Escalated по ретраям (обязательно, детерминированно, без сети):**
`developer_retry_count(task_id) >= MAX_DEVELOPER_RETRIES`.
- `MAX_DEVELOPER_RETRIES` импортируется из `stage_engine` (НЕ хардкодить число).
- Источник счётчика — тот же запрос, что в `_developer_retry_count`:
`SELECT COUNT(*) FROM agent_runs WHERE task_id=? AND agent='developer'`.
2. **Явный человеческий/терминальный Plane-статус:** issue в состоянии
**Blocked** или **Needs Input**.
Порядок: проверки добавляются в `_reconcile_gate_task` ПОСЛЕ существующих гардов
(`stage=='analysis'` carve-out, `get_qg_for_stage is None`, `has_active_job_for_task`,
grace) и ДО `advance_if_gate_passed`. Условие (1) — дешёвое (локальный SQL) —
проверять раньше условия (2), если (2) требует сети.
## 3. Механика проверки blocked/needs-input (выбор — за архитектором, ADR)
В таблице `tasks` НЕТ столбца статуса (`stage` всегда `development` у escalated).
Архитектор выбирает и обосновывает один из вариантов; требования к каждому:
- **Вариант A — проверка через Plane API (без миграции, предпочтительно по
инварианту ORCH-053 «схема не меняется»):** для кандидата F-1 запросить текущее
состояние issue (per-project `get_project_states` → сверка с `blocked`/`needs_input`).
Допустимо, т.к. F-1 уже делает сетевой вызов в гейте (`check_ci_green`), а
кандидатов после grace+no-active-job немного. Обязателен never-raise: ошибка
запроса → консервативно НЕ трогать задачу (skip), либо явно обоснованный фоллбэк.
- **Вариант B — локальный терминальный маркер в БД:** идемпотентная миграция
(`tasks.blocked`/`tasks.reconcile_skip`), выставляется в точках `set_issue_blocked`/
`set_issue_needs_input` и в точках эскалации `gitea.py`. Требует обоснования
нарушения инварианта «схема reconciler не меняется» и затрагивает больше точек.
> Рекомендация аналитика: условие (1) полностью закрывает зафиксированный инцидент
> (ET-013 = escalated = max retries) детерминированно и без сети — оно
> обязательно к реализации. Условие (2) — защита от автоперекрытия ручного гейта;
> минимально-инвазивный путь — Вариант A. Архитектор вправе ограничить (2)
> Вариантом A либо обосновать B.
## 4. Изменения API
Нет. Эндпоинты не добавляются и не меняются. Снимок `GET /queue` (блок `reconcile`)
по содержимому не меняется; опционально архитектор может добавить best-effort
счётчик `skipped_escalated` (необязательно, вне scope AC).
## 5. Изменения схемы БД
По умолчанию — **нет** (Вариант A). При выборе Варианта B — идемпотентная
ALTER-миграция через `_ensure_column` (как остальные в `db.init_db`),
restart-safe, безопасная на живой прод-БД; обязательна явная мотивация в ADR.
## 6. Требования к QG checks
Нет новых QG. Реестр `QG_CHECKS` и `STAGE_TRANSITIONS` не меняются. Гард —
ВНЕ гейта: он решает, ЗАПУСКАТЬ ли пред-оценку гейта вообще, а не меняет вердикт
гейта.
## 7. Инварианты, которые нельзя нарушить
- **Never-raise** на единицу работы (per-task `try/except` в `reconcile_gate_once`
сохраняется; новая логика не должна бросать наружу).
- **Тишина при пропуске:** пропущенная задача не инкрементирует `unblocked_total`,
не пишет лог `разблокирована`, не шлёт Telegram.
- **Регресс F-1 happy-path:** задача с retry < лимита и не-Blocked/Needs-Input при
зелёном гейте по-прежнему доигрывается (`advance_stage` вызывается).
- **F-2** по существу не меняется: Blocked/Needs Input не входят в
{in_progress, approved, rejected} → не доигрываются (зафиксировать регресс-тестом).
- `analysis` carve-out F-1 сохраняется.
- Kill-switch'и (`reconcile_enabled`, `reconcile_plane_enabled`) работают как прежде.
## 8. Артефакты pipeline, которые должны быть созданы/обновлены
- `docs/work-items/ORCH-060/06-adr/ADR-001-*.md` — решение по механике (2) (A vs B).
- `docs/architecture/README.md` — дополнить описание F-1 («skip escalated /
blocked / needs-input»).
- `CHANGELOG.md` — запись `fix(reconciler): ...`.
- Тесты — `tests/test_reconciler.py` (расширение).
- Обновить footer `docs/architecture/README.md` (статус ORCH-060).
## 9. Точки изменения кода (конкретно)
1. `src/reconciler.py`, `_reconcile_gate_task`: после grace-проверки и до
`advance_if_gate_passed` вставить:
```python
# ORCH-060: escalated tasks (max developer retries reached) are terminal —
# they wait for a human, not the sweeper. Skip deterministically (no network).
if developer_retry_count(task_id) >= MAX_DEVELOPER_RETRIES:
return
# ORCH-060: respect an explicit human gate (Blocked / Needs Input).
if self._is_blocked_or_needs_input(task): # mechanism per ADR (Variant A/B)
return
```
2. `src/reconciler.py`: импорт `MAX_DEVELOPER_RETRIES` (и retry-count хелпера) из
`stage_engine` (или новый read-helper в `db.py`).
3. Хелпер проверки Plane-статуса (`_is_blocked_or_needs_input`) — never-raise.

View File

@@ -0,0 +1,124 @@
# Критерии приёмки: ORCH-060
Work Item ID: ORCH-060
Формат: каждый критерий — Дано / Когда / Тогда, с однозначным PASS/FAIL.
---
## AC-1 — Escalated-задача (retry == лимит) не разблокируется (главный кейс ET-013)
- **Дано:** задача на `stage='development'`, без активного job, `age >= grace`,
`check_ci_green` зелёный; в `agent_runs` ровно `MAX_DEVELOPER_RETRIES` (=3)
записей `agent='developer'`.
- **Когда:** выполняется `Reconciler.reconcile_gate_once()`.
- **Тогда:** стадия остаётся `development`; `advance_stage`/`advance_if_gate_passed`
не приводит к смене стадии; `unblocked_total == 0`; новый developer/reviewer job
не создаётся.
- **PASS:** стадия не изменилась И `unblocked_total == 0` И нет новых job.
- **FAIL:** стадия стала `review` / появился новый job / `unblocked_total > 0`.
## AC-2 — Граница: retry > лимита тоже пропускается
- **Дано:** то же, но developer-записей `> MAX_DEVELOPER_RETRIES` (например 45).
- **Когда:** `reconcile_gate_once()`.
- **Тогда:** задача пропущена (как AC-1).
- **PASS / FAIL:** как AC-1.
## AC-3 — Регресс happy-path: retry < лимита по-прежнему доигрывается
- **Дано:** `development`, без активного job, `age >= grace`, `check_ci_green`
зелёный; developer-записей `< MAX_DEVELOPER_RETRIES` (например 0, 1 или 2).
- **Когда:** `reconcile_gate_once()`.
- **Тогда:** задача доигрывается `development → review`; `unblocked_total == 1`;
enqueue следующего агента происходит как раньше.
- **PASS:** стадия стала `review` И `unblocked_total == 1`.
- **FAIL:** задача пропущена / стадия не изменилась.
## AC-4 — Граница ровно на лимите (==3) → skip, на (лимит1) → advance
- **Дано:** две задачи-близнеца, идентичные кроме числа developer-записей:
одна с `MAX_DEVELOPER_RETRIES`, другая с `MAX_DEVELOPER_RETRIES 1`.
- **Когда:** `reconcile_gate_once()`.
- **Тогда:** первая пропущена (skip), вторая доиграна (advance).
- **PASS:** ровно одна из двух доиграна (та, что `1`).
- **FAIL:** обе доиграны / обе пропущены / доиграна задача на лимите.
## AC-5 — Plane-статус Blocked → пропуск
- **Дано:** задача-кандидат F-1 (stage не-терминальный, без активного job,
`age >= grace`, гейт зелёный), у которой текущий Plane-статус issue = **Blocked**;
retry < лимита (чтобы изолировать именно этот гард).
- **Когда:** `reconcile_gate_once()`.
- **Тогда:** задача пропущена; стадия не меняется; `unblocked_total == 0`.
- **PASS:** стадия не изменилась И `unblocked_total == 0`.
- **FAIL:** задача доиграна.
## AC-6 — Plane-статус Needs Input → пропуск
- **Дано:** как AC-5, но Plane-статус = **Needs Input**.
- **Когда:** `reconcile_gate_once()`.
- **Тогда:** задача пропущена (как AC-5).
- **PASS / FAIL:** как AC-5.
## AC-7 — Тишина при пропуске (no spam)
- **Дано:** escalated-задача (как AC-1).
- **Когда:** `reconcile_gate_once()` (один или несколько тиков).
- **Тогда:** НЕ вызывается `_note_unblock`; нет лог-строки `... разблокирована`;
нет `send_telegram`; нет `notify_qg_failure` (пропуск — раньше оценки гейта).
- **PASS:** ни одна из перечисленных нотификаций не вызвана.
- **FAIL:** вызвана любая нотификация.
## AC-8 — Никакого сетевого вызова гейта на escalated-задаче
- **Дано:** escalated-задача (как AC-1) с замоканным `check_ci_green`.
- **Когда:** `reconcile_gate_once()`.
- **Тогда:** `check_ci_green` (через `advance_if_gate_passed`/`_run_qg`) НЕ
вызывается для этой задачи — пропуск происходит раньше.
- **PASS:** мок гейта не вызван.
- **FAIL:** мок гейта вызван.
## AC-9 — F-2 не доигрывает Blocked/Needs Input (регресс)
- **Дано:** issue в Plane-статусе Blocked или Needs Input (не входит в
{in_progress, approved, rejected}).
- **Когда:** `reconcile_plane_once()`.
- **Тогда:** ни `handle_status_start`, ни `handle_verdict` не вызываются для
этого issue; `unblocked_total == 0`.
- **PASS:** обработчики не вызваны.
- **FAIL:** вызван любой обработчик.
## AC-10 — Never-raise: ошибка проверки статуса не ломает тик
- **Дано:** проверка blocked/needs-input (Plane API в Варианте A) бросает
исключение для одной задачи; в выборке есть ещё одна валидная задача.
- **Когда:** `reconcile_gate_once()`.
- **Тогда:** тик не падает; сбойная задача консервативно НЕ трогается (skip);
остальные обрабатываются.
- **PASS:** исключение изолировано, остальные задачи обработаны.
- **FAIL:** исключение всплыло из `reconcile_gate_once`.
## AC-11 — Лимит не хардкодится
- **Дано:** код F-1-гарда.
- **Тогда:** используется `stage_engine.MAX_DEVELOPER_RETRIES`, а не литерал `3`.
- **PASS:** граница берётся из константы.
- **FAIL:** в reconciler.py появился магический `3`.
## AC-12 — Документация обновлена (golden source)
- **Дано:** PR задачи.
- **Тогда:** обновлены `docs/architecture/README.md` (описание F-1 с новым skip),
`CHANGELOG.md`, создан `06-adr/ADR-001-*.md`.
- **PASS:** все три артефакта обновлены/созданы в этом же PR.
- **FAIL:** любой отсутствует (reviewer → REQUEST_CHANGES).
## AC-13 — Регресс существующих тестов reconciler
- **Дано:** существующий `tests/test_reconciler.py` (ORCH-053).
- **Когда:** `pytest tests/test_reconciler.py -q`.
- **Тогда:** все прежние тесты зелёные (поведение happy-path/analysis/kill-switch
не сломано).
- **PASS:** 0 регрессий.
- **FAIL:** любой ранее зелёный тест упал.

View File

@@ -0,0 +1,82 @@
work_item: ORCH-060
description: >
Reconciler F-1 пропускает escalated (retry >= MAX_DEVELOPER_RETRIES) и
явно-blocked / needs-input задачи; happy-path и no-spam сохранены.
Конвенции test-фикстур — как в существующем tests/test_reconciler.py
(изолированная sqlite-БД, моки Plane/Telegram/gate). Хелпер _make_task
вставляет задачу; developer-ретраи моделируются вставкой N строк в agent_runs
(agent='developer'); зелёный CI — через _green_ci(monkeypatch).
tests:
- id: TC-01
type: unit
description: "AC-1: escalated dev-задача (ровно MAX_DEVELOPER_RETRIES developer-ранов) при зелёном CI НЕ разблокируется — стадия остаётся development, unblocked_total==0, новых job нет"
module: tests/test_reconciler.py
setup: "_make_task('development', age_s=grace+60); insert MAX_DEVELOPER_RETRIES rows agent_runs(agent='developer'); _green_ci()"
expected: PASS
- id: TC-02
type: unit
description: "AC-2: developer-ранов > MAX_DEVELOPER_RETRIES (45) → также skip"
module: tests/test_reconciler.py
expected: PASS
- id: TC-03
type: unit
description: "AC-3 (регресс happy-path): developer-ранов < MAX (0/1/2) при зелёном CI → задача доигрывается development->review, unblocked_total==1"
module: tests/test_reconciler.py
expected: PASS
- id: TC-04
type: unit
description: "AC-4: граница — задача с ровно MAX пропущена, задача с MAX-1 доиграна (ровно одна advance)"
module: tests/test_reconciler.py
expected: PASS
- id: TC-05
type: unit
description: "AC-5: задача в Plane-статусе Blocked (retry<лимита) пропущена — стадия не меняется, unblocked_total==0 (мок проверки статуса возвращает Blocked)"
module: tests/test_reconciler.py
expected: PASS
- id: TC-06
type: unit
description: "AC-6: задача в Plane-статусе Needs Input (retry<лимита) пропущена"
module: tests/test_reconciler.py
expected: PASS
- id: TC-07
type: unit
description: "AC-7 (no spam): на escalated-задаче не вызваны _note_unblock / send_telegram / notify_qg_failure; нет лог-строки 'разблокирована'"
module: tests/test_reconciler.py
expected: PASS
- id: TC-08
type: unit
description: "AC-8: на escalated-задаче мок check_ci_green НЕ вызван (skip раньше пред-оценки гейта)"
module: tests/test_reconciler.py
expected: PASS
- id: TC-09
type: unit
description: "AC-9 (регресс F-2): issue в Blocked/Needs Input не передаётся ни в handle_status_start, ни в handle_verdict при reconcile_plane_once; unblocked_total==0"
module: tests/test_reconciler.py
expected: PASS
- id: TC-10
type: unit
description: "AC-10 (never-raise): проверка blocked/needs-input бросает исключение на одной задаче → тик не падает, сбойная skip, валидная соседняя обработана"
module: tests/test_reconciler.py
expected: PASS
- id: TC-11
type: unit
description: "AC-11: граница берётся из stage_engine.MAX_DEVELOPER_RETRIES — тест с monkeypatch значения константы меняет точку отсечения (нет хардкода 3)"
module: tests/test_reconciler.py
expected: PASS
- id: TC-12
type: integration
description: "AC-13 (регресс): полный прогон tests/test_reconciler.py (ORCH-053 кейсы) — все прежние тесты зелёные"
module: tests/test_reconciler.py
expected: PASS

View File

@@ -0,0 +1,161 @@
# ADR-001: Reconciler (F-1) пропускает escalated / Blocked / Needs-Input задачи
- **Статус:** Accepted
- **Дата:** 2026-06-07
- **Задача:** ORCH-060
- **Стадия:** architecture
- **Связано:** adr-0007 (reconciler, ORCH-053) — уточняет контракт F-1;
ORCH-046 (retry-счётчик), ORCH-047 (BLOCKED-вердикт)
## Контекст
ORCH-053 ввёл F-1 (`Reconciler._reconcile_gate_task`): для каждой не-терминальной
задачи без активного job и старше grace делается read-only пред-оценка
канонического QG; зелёный → `advance_if_gate_passed`
`advance_stage(..., finished_agent=None)`.
**Дефект (инцидент ET-013, 0607.06.2026).** Задача, исчерпавшая лимит
developer-ретраев (`_developer_retry_count(task_id) >= MAX_DEVELOPER_RETRIES = 3`),
**escalated** в обработчиках `gitea.py` (`:280` CI-failure, `:371` review
REQUEST_CHANGES) выполняет ТОЛЬКО `notify_error(...)`:
- стадия НЕ меняется (остаётся `development`);
- терминального маркера в БД нет (нет столбца статуса в `tasks`);
- активного job нет.
Для F-1 такая задача **неотличима** от «застрявшей из-за потерянного webhook».
Если CI зелёный (типовой кейс: dev починил CI, но reviewer слал REQUEST_CHANGES
до лимита), каждые `reconcile_interval_s` (120с) F-1 видит зелёный `check_ci_green`
и разблокирует `development → review` → reviewer снова REQUEST_CHANGES → откат →
снова эскалация (стадия не меняется) → следующий тик снова разблокирует.
**Бесконечный цикл:** ET-013 разблокирована 10 раз за ночь, лишние запуски агентов
(токены/деньги), спам в Telegram, паразитная нагрузка общего self-hosting-инстанса.
Симметричный риск: задачу, которую человек явно перевёл в Plane-статус **Blocked**
/ **Needs Input** (ручной гейт), sweeper не должен авторазблокировать до
вмешательства человека.
## Решение
В `_reconcile_gate_task` ПОСЛЕ существующих гардов (`stage=='analysis'` carve-out,
`get_qg_for_stage is None`, `has_active_job_for_task`, grace) и ДО
`advance_if_gate_passed` добавляются два пред-гарда. Любой срабатывает → ранний
`return`: задача пропущена, гейт НЕ оценивается, `unblocked_total` не растёт,
нотификаций нет.
### Гард 1 — escalated по ретраям (детерминированный, без сети) — **обязателен**
```python
# ORCH-060: escalated tasks (max developer retries reached) are terminal —
# they wait for a human, not the sweeper. Deterministic, no network.
if developer_retry_count(task_id) >= MAX_DEVELOPER_RETRIES:
return
```
- Источник истины по retry — `agent_runs` (как у `_developer_retry_count`):
`SELECT COUNT(*) FROM agent_runs WHERE task_id=? AND agent='developer'`.
- `MAX_DEVELOPER_RETRIES` импортируется из `stage_engine`**не хардкодить `3`**
(AC-11).
- Граница `>=` (на лимите — skip, на `лимит1` — advance; AC-4).
**Промоут хелпера.** `stage_engine._developer_retry_count` повышается до публичного
`developer_retry_count` (приватное имя сохраняется как алиас для существующих
внутренних call-sites). Reconciler импортирует
`MAX_DEVELOPER_RETRIES, developer_retry_count` из `stage_engine`. SQL **не
дублируется** в `db.py` — единый источник истины по подсчёту ретраев.
### Гард 2 — явный человеческий Plane-статус (Blocked / Needs Input) — **Вариант A**
```python
# ORCH-060: respect an explicit human gate (Blocked / Needs Input).
if self._is_blocked_or_needs_input(task):
return
```
Механика — **Вариант A (запрос Plane API, без миграции схемы):**
1. Новый never-raise хелпер `plane_sync.fetch_issue_state(issue_id, project_id)
-> str | None` — GET issue-detail (тот же endpoint/headers, что
`fetch_issue_sequence_id` / `fetch_issue_fields`), возвращает uuid текущего
`state`; любая ошибка/отсутствие поля → `None`.
2. `Reconciler._is_blocked_or_needs_input(task)`:
- `repo → ProjectConfig` через `projects.get_project_by_repo(task['repo'])`;
- `pid = proj.plane_project_id`; `states = get_project_states(pid)` (кэш per-project);
- `cur = fetch_issue_state(task['plane_id' | 'plane_issue_id'], pid)`;
- вернуть `cur in {states['blocked'], states['needs_input']}`.
- **Never-raise → консервативный фоллбэк:** любая ошибка/`None`/нерезолвленный
проект → трактуем как «возможно заблокировано» → возвращаем `True` (skip).
Не-разблокировать безопаснее, чем разблокировать (AC-10).
**Порядок гардов:** Гард 1 (локальный SQL, дёшево) — ПЕРВЫМ; Гард 2 (сеть) —
вторым. Для зафиксированного инцидента (ET-013 = escalated) Гард 1 закрывает кейс
**без единого сетевого вызова**.
### Что НЕ меняется (инварианты ORCH-053)
- Схема БД — **без миграции** (Вариант A). `STAGE_TRANSITIONS` / `QG_CHECKS` —
без изменений. Гард — ВНЕ гейта: решает, ЗАПУСКАТЬ ли пред-оценку, а не меняет
вердикт.
- Never-raise на единицу работы (`reconcile_gate_once` per-task `try/except`
сохраняется; новая логика не бросает наружу).
- `analysis` carve-out, kill-switch'и (`reconcile_enabled`,
`reconcile_plane_enabled`) — как прежде.
- F-2 по существу не меняется: Blocked/Needs Input не входят в
`{in_progress, approved, rejected}` → не доигрываются (фиксируется
регресс-тестом AC-9).
### Опционально (вне scope AC, рекомендации)
- Под-флаг `reconcile_skip_blocked_enabled` (default `true`) для независимого
отключения только Гарда 2 (сетевого), по аналогии с `reconcile_plane_enabled`.
Гард 1 (локальный, безопасный) — всегда активен.
- Best-effort счётчик `skipped_escalated` в снимке `GET /queue` (наблюдаемость).
## Альтернативы
- **Вариант B — локальный терминальный маркер в БД** (`tasks.blocked` /
`tasks.reconcile_skip`, идемпотентный ALTER, выставляется в `set_issue_blocked`
/ `set_issue_needs_input` и точках эскалации `gitea.py`). **Отклонён как
primary:**
- нарушает инвариант ORCH-053 «схема reconciler не меняется» (миграция на живой
прод-БД = self-hosting-риск);
- затрагивает больше точек записи (4+: две эскалации gitea + два set_issue_*) —
выше риск рассинхрона маркера и факта;
- для зафиксированного инцидента **не нужен**: Гард 1 (retry-count) закрывает
ET-013 детерминированно и без сети.
Вариант B остаётся задокументированным будущим упрочнением, если Plane-coupling
Гарда 2 окажется болезненным (см. Последствия).
- **Подавление в самом `advance_stage` / новый терминальный вердикт гейта** —
отклонён: меняет общий критический путь; ORCH-053 уже постановил «не вызывать
advance на красном», тот же принцип «не вызывать advance на escalated».
- **Гард только по retry (без Гарда 2)** — недостаточно: не покрывает ручной
Blocked при retry<лимита; AC-5/AC-6 требуют пропуск.
## Последствия
- **Плюсы:** ET-013-петля устранена детерминированно; 0 фантомных разблокировок,
0 лишних запусков агентов, 0 спама по escalated-задачам; ручной Blocked/Needs
Input уважается; без миграции БД и без изменения реестров → минимальный
self-hosting-риск; единый источник истины по retry (промоут хелпера).
- **Минусы / плата:**
- Гард 2 вводит **per-candidate сетевой вызов** Plane на тике. Митигировано:
кандидатов после grace+no-active-job немного; `get_project_states` кэшируется;
Гард 1 отсекает escalated до сети.
- **Plane-coupling F-1:** при недоступности Plane Гард 2 фоллбэкает в skip →
F-1 во время Plane-outage не доигрывает кандидатов с retry<лимита (консерва-
тивно «не навреди»). Приемлемо: outage редок/транзиентен; escalated-кейс
(Гард 1) от Plane не зависит и продолжает работать; альтернатива
(proceed-on-error) рискует вернуть bounce при реальном Blocked. Под-флаг
`reconcile_skip_blocked_enabled` даёт ручной обход на время инцидента.
- **Self-hosting:** изменение — чистая логика sweeper'а; прод-контейнер не
рестартится/не роняется; деплой через staging (8501) по канону.
## Связи
- **adr-0007 (reconciler, ORCH-053)** — данный ADR уточняет контракт F-1
(`_reconcile_gate_task` приобретает два пред-гарда; инварианты сохранены).
- **adr-0003 (условный staging-гейт)** — образец never-raise + флага раската
(Гард 2 / `reconcile_skip_blocked_enabled`).
- **adr-0001 (реестр проектов)** — `get_project_by_repo` → `plane_project_id`
для резолва per-project статусов (Вариант A).
- ORCH-046 (retry-счётчик `agent_runs`), ORCH-047 (BLOCKED-вердикт).

View File

@@ -0,0 +1,20 @@
# Технические риски: ORCH-060
Work Item ID: ORCH-060
Стадия: architecture
| # | Риск | Вероятность | Влияние | Митигация |
|---|------|-------------|---------|-----------|
| R-1 | **Plane-coupling F-1.** Гард 2 (Вариант A) делает сетевой вызов на тике; при недоступности Plane все кандидаты с retry<лимита фоллбэкают в skip → F-1 временно не доигрывает. | Низкая (outage редок) | Среднее | Консервативный фоллбэк («не навреди»); escalated-кейс закрыт Гардом 1 без сети; под-флаг `reconcile_skip_blocked_enabled` для ручного обхода; `get_project_states` кэшируется. |
| R-2 | **Стоимость поллинга.** Per-candidate GET issue-detail каждые 120с при большом числе stuck-задач. | Низкая | Низкое | Кандидатов после grace+no-active-job мало; Гард 1 (локальный SQL) отсекает escalated до сети; вызов только для переживших Гард 1. |
| R-3 | **Промоут хелпера ломает call-sites.** `_developer_retry_count → developer_retry_count`. | Низкая | Среднее | Сохранить приватный алиас `_developer_retry_count = developer_retry_count`; grep всех вызовов перед мержем; покрыто существующими тестами stage_engine. |
| R-4 | **Неверный фоллбэк-знак Гарда 2.** Если ошибку трактовать как «не заблокировано» → возврат ET-013-bounce при реальном Blocked. | Средняя (ошибка реализации) | Высокое | ADR явно фиксирует: ошибка/None/нерезолвленный проект → `True` (skip); AC-10 проверяет never-raise+skip. |
| R-5 | **Резолв plane-issue-id из task.** В `tasks` два поля (`plane_id` / `plane_issue_id`); неверный выбор → пустой запрос. | Низкая | Низкое | Использовать тот же приоритет, что `get_task_by_plane_id` (оба поля); пустой id → фоллбэк skip. |
| R-6 | **Регресс happy-path.** Слишком широкий гард пропустит честно-застрявшие задачи (retry<лимита, не Blocked). | Низкая | Высокое | AC-3/AC-4 (граница ровно на лимите); регресс существующих тестов AC-13. |
| R-7 | **Self-hosting деплой.** Изменение работающего в проде sweeper'а. | Низкая | Высокое | Чистая логика, без миграции/рестарт-контрактов; обязательный прогон через staging (8501) перед прод-деплоем; kill-switch `reconcile_enabled`. |
## Вывод
Все риски — низкие/средние по вероятности и митигируемы в рамках выбранной
архитектуры (Вариант A, без миграции). Критичен корректный знак never-raise
фоллбэка Гарда 2 (R-4) — выделен в AC-10. Схема БД и реестры не меняются →
self-hosting-риск минимален.

View File

@@ -0,0 +1,63 @@
---
type: review
work_item_id: ORCH-060
verdict: APPROVED
version: 1
---
# Review ORCH-060
## Summary
Reviewer-проверка PR `feature/ORCH-060-reconciler-escalated-max-retri` (commit `4db8276`,
`fix(reconciler): skip escalated / Blocked / Needs-Input tasks in F-1`).
Задача — устранить инцидент ET-013 (бесконечная разблокировка escalated-задачи F-1-реконсайлером).
Реализованы два пред-гарда в `Reconciler._reconcile_gate_task` строго ПОСЛЕ существующих гардов
(`analysis` carve-out → нет гейта → активный job → grace) и ДО `advance_if_gate_passed`:
- **Guard 1** (детерминированный, без сети, проверяется первым): `developer_retry_count(task_id) >= MAX_DEVELOPER_RETRIES`;
- **Guard 2** (Вариант A — Plane API, never-raise → консервативный skip): `_is_blocked_or_needs_input(task)`.
Реализация **полностью соответствует** ТЗ (`02-trz.md`), критериям приёмки (`03-acceptance-criteria.md`)
и ADR-001. Все 13 AC покрыты тестами (TC-01…TC-11 + sub-flag + F-2-регресс). `pytest tests/ -q`
**644 passed, 0 регрессий**; `tests/test_reconciler.py` — 27 passed.
## Соответствие ТЗ / ADR
- **Guard 1** — точка вставки, граница `>=`, источник счётчика (`agent_runs`) совпадают с ТЗ §9 и ADR §«Гард 1». ✓
- Промоут `stage_engine._developer_retry_count` → публичный `developer_retry_count`, приватный алиас сохранён, все 4 внутренних call-site (`stage_engine.py:565/613/874/950`) работают через алиас — единый источник истины, SQL не дублируется. ✓
- `MAX_DEVELOPER_RETRIES` импортируется из `stage_engine`, **хардкода `3` в `reconciler.py` нет** (grep подтверждает). ✓ (AC-11)
- **Guard 2 — Вариант A** без миграции БД: новый never-raise `plane_sync.fetch_issue_state` (тот же endpoint/headers, что `fetch_issue_sequence_id`), консервативный фоллбэк (`True`→skip) при любой ошибке/`None`/нерезолвленном проекте. Соответствует ADR §«Гард 2» и обоснованию выбора A над B. ✓
- Под-флаг `reconcile_skip_blocked_enabled` (default `true`) гасит ТОЛЬКО сетевой Guard 2; Guard 1 всегда активен. ✓
- Инварианты ORCH-053 сохранены: схема БД / `STAGE_TRANSITIONS` / `QG_CHECKS` не тронуты; never-raise на единицу работы (`reconcile_gate_once` per-task `try/except` + `_is_blocked_or_needs_input` внутренний `try/except`); тишина при пропуске (ранний `return` до `advance`, без `unblocked_total++`/лога/Telegram); `analysis` carve-out и kill-switch'и не изменены. ✓
- API не изменён (`GET /queue` без изменений по содержимому) — соответствует ТЗ §4. ✓
## Качество кода
- Docstrings на новых публичных/значимых функциях (`fetch_issue_state`, `developer_retry_count`, `_is_blocked_or_needs_input`) — содержательные, объясняют контракт never-raise и мотивацию. ✓
- Обработка Plane-формата `state` (bare uuid и `{"id": ...}`-вложение) — defensive. ✓
- Тесты содержательные (не тривиальные): граница ровно на лимите (TC-04), изоляция исключения с проверкой соседа (TC-10), отсутствие сетевого вызова гейта на escalated (TC-08), регресс F-2 (TC-09). ✓
- Self-hosting: чистая логика sweeper'а, прод-контейнер не рестартится/не роняется. ✓
## Findings
### P0 — Blocker
- нет
### P1 — Must fix
- нет
### P2 — Should fix
- нет
> Замечание (P3 / информационно, не блокирует): Guard 2 делает per-candidate сетевой вызов Plane
> для ВСЕХ репо (включая не-self-hosting), а не только для `orchestrator`. Это осознанное решение
> Варианта A, явно зафиксировано в ADR §«Последствия» (митигировано: кандидатов после grace мало,
> `get_project_states` кэшируется, Guard 1 отсекает escalated до сети). Соответствует ADR — не finding.
## Документация
Обновлено в этом же PR (AC-12 — PASS):
- `docs/work-items/ORCH-060/06-adr/ADR-001-reconciler-skip-escalated.md` — создан, Accepted, полное обоснование A vs B. ✓
- `docs/architecture/README.md` — описание F-1 дополнено skip escalated/Blocked/Needs-Input; footer ORCH-060 переведён в статус «реализовано» с деталями. ✓
- `CHANGELOG.md` — запись в `### Fixed` (`fix(reconciler): ...`). ✓
- `README.md` — таблица env дополнена `ORCH_RECONCILE_SKIP_BLOCKED_ENABLED`. ✓
- `.env.example` — канонический ключ + дескриптор добавлены (правило CLAUDE.md №8). ✓
Документация = golden source: код и доку обновлены синхронно. Нарушений нет.

View File

@@ -0,0 +1,72 @@
---
type: test-report
work_item_id: ORCH-060
result: PASS
---
# Test Report — ORCH-060
Reconciler F-1 пропускает escalated (retry ≥ MAX_DEVELOPER_RETRIES) и явно
Blocked / Needs-Input задачи; happy-path и no-spam сохранены.
## Окружение
- Python: 3.12.13
- pytest: 8.3.3 (plugins: anyio-4.13.0, asyncio-0.23.8)
- Ветка: `feature/ORCH-060-reconciler-escalated-max-retri` @ `55e5e96`
(фикс: `4db8276 fix(reconciler): skip escalated / Blocked / Needs-Input tasks in F-1`)
- Дата: 2026-06-07
- Review verdict: APPROVED (`12-review.md`)
## Smoke test API (прод 8500, read-only)
> `curl` отсутствует в окружении тестера — проверка выполнена через `python urllib`.
> Прод-контейнер НЕ перезапускался / не ронялся (self-hosting, CLAUDE.md §⚠️).
| Endpoint | HTTP | Ответ |
|----------|------|-------|
| `GET /health` | 200 | `{"status":"ok","service":"orchestrator"}` |
| `GET /status` | 200 | активные задачи отданы (в т.ч. ORCH-060 stage=testing) |
| `GET /queue` | 200 | counts/resilience/reconcile-блок отданы |
## Результаты (test-plan 04-test-plan.yaml → AC)
| TC ID | AC | Описание | Тест | Результат |
|-------|-----|----------|------|-----------|
| TC-01 | AC-1 | escalated == MAX_DEVELOPER_RETRIES при зелёном CI → skip | `test_tc060_01_escalated_at_limit_skipped` | PASS |
| TC-02 | AC-2 | dev-ранов > MAX → skip | `test_tc060_02_over_limit_skipped` | PASS |
| TC-03 | AC-3 | регресс happy-path: retry < MAX → advance dev→review | `test_tc060_03_under_limit_still_advances` | PASS |
| TC-04 | AC-4 | граница: ровно MAX skip, MAX1 advance (ровно одна) | `test_tc060_04_boundary_exactly_one_advances` | PASS |
| TC-05 | AC-5 | Plane-статус Blocked → skip | `test_tc060_05_blocked_skipped` | PASS |
| TC-06 | AC-6 | Plane-статус Needs Input → skip | `test_tc060_06_needs_input_skipped` | PASS |
| TC-07 | AC-7 | no spam на escalated (нет _note_unblock/telegram/qg-fail) | `test_tc060_07_escalated_no_spam` | PASS |
| TC-08 | AC-8 | escalated → мок check_ci_green НЕ вызван (skip раньше гейта) | `test_tc060_08_no_gate_call_on_escalated` | PASS |
| TC-09 | AC-9 | регресс F-2: Blocked/Needs Input не доигрывается | `test_tc060_09_f2_does_not_replay_blocked` | PASS |
| TC-10 | AC-10 | never-raise: ошибка guard2 изолирована, сосед обработан | `test_tc060_10_guard2_never_raise` | PASS |
| TC-11 | AC-11 | граница из stage_engine.MAX_DEVELOPER_RETRIES (нет хардкода 3) | `test_tc060_11_limit_from_constant` | PASS |
| — | — | под-флаг `reconcile_skip_blocked_enabled` гасит только guard2 | `test_tc060_subflag_disables_only_guard2` | PASS |
| TC-12 | AC-13 | регресс: полный прогон test_reconciler.py (ORCH-053 кейсы) | `tests/test_reconciler.py` (27 passed) | PASS |
| — | AC-12 | документация (README/ADR/CHANGELOG) — проверено reviewer'ом | — | PASS |
## Вывод pytest
Полный регресс:
```
$ python -m pytest tests/ -q
........................................................................ [ 11%]
... (644 dots) ...
.................................................................... [100%]
644 passed, 1 warning in 15.65s
```
Целевой модуль:
```
$ python -m pytest tests/test_reconciler.py -v
...
27 passed, 1 warning in 1.23s
```
(1 warning — PydanticDeprecatedSince20 в `src/config.py:4`, не связано с ORCH-060,
существующий технический долг.)
## Итог
**PASS** — все 13 критериев приёмки покрыты и зелёные, полный регресс 644/644,
целевой модуль 27/27, smoke API 3/3. Регрессий нет. Задача готова к стадии
deploy-staging.

View File

@@ -0,0 +1,80 @@
---
staging_status: FAILED
timestamp: 2026-06-07T11:57:34Z
base_url: http://localhost:8501
mode: stub
result: 8/10
work_item: ORCH-060
---
# Staging Gate Log
Staging test suite **FAILED** (exit code 1, 8/10 checks PASS).
Canonical run (ORCH-048, ADR-001) — executed INSIDE the `orchestrator-staging`
container against the live staging instance:
```
python3 /repos/orchestrator/scripts/staging_check.py --base-url http://localhost:8501 --mode stub
```
## Failing checks
- **C9a — Branch appears in `orchestrator-sandbox`** → FAIL (`branch=not found`).
After triggering the pipeline via `POST /webhook/plane`, no feature branch was
created in the sandbox repo within the 60s poll window.
- **C9b — Analyst job enqueued in staging queue** → FAIL. No analyst job appeared
in the staging job queue within the 30s window.
Both failures are in the E2E block (Block C): the webhook was accepted
(C8 → HTTP 200 `{'status': 'accepted'}`) and the Plane issue was created (C7 →
HTTP 201), but the pipeline did not materialise a branch or enqueue the analyst
job — the staging instance did not actually process the triggered task end-to-end.
## Passing checks (8/10)
- Block A (SMOKE): A1 /health 200, A2 /queue shape, A3 ORCH_STAGING=true.
- Block B (ACCESS): B4 Plane sandbox reachable, B5 Gitea sandbox push=true,
B6 registry isolation (sandbox present, prod ET/ORCH absent — confirms the
canonical in-container run; B6 would false-FAIL from the host).
## Verdict
Machine verdict is authoritative: exit code 1 → `staging_status: FAILED`.
Per the conditional staging gate (ORCH-35), a FAILED staging gate for the
self-hosting repo rolls the task back to `development`.
## Raw output
```
============================================================
ORCH-33 Staging Check Suite
base_url : http://localhost:8501
mode : stub
utc_time : 2026-06-07T11:55:50.247315+00:00
============================================================
[Block A] SMOKE
✓ PASS A1 GET /health → 200 status=ok [HTTP 200, body={'status': 'ok', 'service': 'orchestrator'}]
✓ PASS A2 GET /queue → 200 with counts/max_concurrency/resilience [HTTP 200, keys=['counts', 'max_concurrency', 'poll_interval', 'resilience', 'reconcile', 'recent']]
✓ PASS A3 ORCH_STAGING=true (not prod) [ORCH_STAGING=true]
[Block B] ACCESS
✓ PASS B4 Plane: sandbox project accessible [HTTP 200, found 5 project(s), sandbox=YES]
✓ PASS B5 Gitea: orchestrator-sandbox accessible, push=true [HTTP 200, permissions={'admin': True, 'push': True, 'pull': True}]
✓ PASS B6 Registry: sandbox present, prod ET/ORCH absent [sandbox=YES, prod-ET=NO(good), prod-ORCH=NO(good)]
[Block C] E2E (mode=stub)
C7 Create issue in Plane SANDBOX [HTTP 201, issue_id=a05995d1-4e3c-44f7-af6f-8bd28fa6367d]
C8 Trigger pipeline via /webhook/plane [HTTP 200, resp={'status': 'accepted'}]
✗ FAIL C9a Branch appears in orchestrator-sandbox [branch=not found]
✗ FAIL C9b Analyst job enqueued in staging queue
[CLEANUP]
✓ PASS CLEANUP: deleted Plane issue a05995d1-4e3c-44f7-af6f-8bd28fa6367d (HTTP 204)
============================================================
RESULT: 8/10 checks PASS
============================================================
__EXIT_CODE__=1
```

View File

@@ -0,0 +1,7 @@
# Business Request: BUG: deploy-staging петля — откат на development (self-deploy)
Work Item ID: ORCH-061
## Description
TBD

View File

@@ -0,0 +1,117 @@
# 01 — BRD: BUG — deploy-staging петля (откат deploy-staging → development) для self-deploy
Work Item: **ORCH-061**
Тип: **BUG**
Приоритет: **P0**
Репозиторий: `orchestrator` (self-hosting)
Эпик-контекст: блокер **ORCH-54** (автономное внедрение self-hosting)
---
## 1. Резюме (Executive summary)
На стадии `deploy-staging` для self-hosting репозитория `orchestrator` задача
зацикливается: гейт ребра `deploy-staging → deploy` даёт FAILED, `stage_engine`
откатывает задачу `deploy-staging → development`, developer-агент перезапускается,
проходит конвейер заново, снова упирается в `deploy-staging`, снова откат — и так
по кругу (с расходом developer-ретраев и кредитов LLM), либо до исчерпания лимита
ретраев и блокировки.
Следствие: **прод-деплой self-hosting репо невозможен автономно**. Последние
ORCH-задачи (ORCH-58, ORCH-60) доводились до прода **вручную** (ручной merge PR +
ручной build-once retag + ручной `--deploy`). Это прямой блокер автономного
внедрения (эпик ORCH-54).
## 2. Бизнес-контекст и проблема
Оркестратор дорабатывает сам себя (self-hosting). Стадия `deploy-staging`
(порт 8501) — обязательная страховка перед прод-деплоем орка (ORCH-35, ADR-0003).
На этой стадии deployer гоняет `scripts/staging_check.py` против живого
staging-стенда и пишет машинный вердикт `staging_status: SUCCESS|FAILED` в
`15-staging-log.md`. Гейт `check_staging_status` читает этот вердикт; `FAILED`
→ откат на `development` (ORCH-35, `_handle_qg_failure_rollbacks`).
Подтверждены **две независимые причины** зацикливания.
### Причина №1 — ложный FAILED `check_staging_status` (контекст ORCH-58)
`staging_check.py` в sandbox-прогоне даёт **8/10 PASS, 2 ложных FAIL** на e2e-блоке
Block C:
- **C9a** — ветка не появляется в `orchestrator-sandbox` (branch not found);
- **C9b** — analyst-job не появляется в staging-очереди (`/queue → recent`).
Сопутствующая пометка suite: «Plane comment check skipped: bot-tokens not added to
SANDBOX project» — bot-аккаунты агентов (`ORCH_PLANE_BOT_*`) не добавлены членами
SANDBOX-проекта Plane (проект создан после провижининга ботов). Это **отсутствие
sandbox-настроек инфраструктуры, а не регресс кода**. Тем не менее `staging_check.py`
возвращает ненулевой exit-code → deployer пишет `staging_status: FAILED` → гейт
FAILED → откат `deploy-staging → development`.
### Причина №2 — «no changes to commit» на action-стадии (контекст ORCH-60)
Стадии деплоя по своей природе **действие, а не правка кода** (рестарт/retag), и
закономерно не порождают git-изменений в `src/`/`tests/`. Сигнал «no changes»
для action-стадии не должен трактоваться как недовыполнение работы; критерий успеха
action-стадии — успешное выполнение действия (exit0 + доказанный health/staging),
а не наличие нового коммита. Сейчас отсутствие изменений на стадии деплоя приводит
к недопродвижению задачи и откату.
### Совокупный эффект
Любая из причин по отдельности достаточна, чтобы зациклить self-deploy. Обе
проявились на реальных задачах ORCH-58 и ORCH-60, которые пришлось доводить вручную.
## 3. Цели (Goals)
- **G1.** ORCH-задача для self-hosting `orchestrator` проходит
`deploy-staging → deploy → done` **без ручного вмешательства** и **без петли**.
- **G2.** Ложный (инфраструктурный) FAIL `staging_check` в sandbox **не вызывает**
откат `deploy-staging → development`.
- **G3.** Отсутствие git-изменений на стадиях деплоя (`deploy-staging` / `deploy`)
**не трактуется** как недовыполнение и не приводит к откату.
- **G4.** Реальный регресс (настоящий провал staging-проверки или прод-деплоя)
**по-прежнему** приводит к откату `→ development` (страховка не ослабляется).
## 4. Вне области (Non-goals)
- Полная автоматизация ручного approve прод-деплоя (это ORCH-54).
- Изменение конвейера стадий (`STAGE_TRANSITIONS`), реестра гейтов как структуры,
контрактов `check_deploy_status` / `check_staging_status` frontmatter-вердиктов.
- Изменение поведения для **не**-self-hosting репозиториев (enduro-trails и пр.):
для них staging-гейт и self-deploy остаются no-op / прежними.
- Изменение схемы БД.
## 5. Заинтересованные стороны
| Роль | Интерес |
|------|---------|
| Owner / оператор оркестратора | Автономный self-deploy без ручных шагов и без ночных петель. |
| Другие проекты (enduro-trails) | Их конвейер не должен быть затронут (общий инстанс, общая очередь). |
| Агенты (deployer) | Чёткий, не ложно-срабатывающий контракт стадии деплоя. |
## 6. Кандидатные направления решения (из бизнес-запроса)
Бизнес-запрос называет два направления (одно или оба); **выбор и механизм —
за архитектором (ADR)**, BRD требует лишь достижения G1G4:
- **(а)** Сделать sandbox-прогон `staging_check` честным (например, настроить
bot-токены SANDBOX Plane-проекта / починить sandbox e2e), чтобы C9a/C9b
проходили честно (10/10) и `check_staging_status` не падал ложно.
- **(б)** Отвязать продвижение стадий деплоя от git-changes для self-deploy:
успех action-стадии = exit0 + health/staging PASS, а не наличие коммита.
## 7. Бизнес-эффект / риски бездействия
- **Эффект:** разблокировка автономного внедрения self-hosting (ORCH-54);
устранение ручного труда (merge + retag + deploy) и риска ошибки при ручных шагах.
- **Риск бездействия:** каждая ORCH-задача требует ручного дотягивания до прода;
петли жгут кредиты LLM и developer-ретраи, задачи блокируются.
## 8. Допущения
- Прод-контейнер `orchestrator` (8500) обслуживает все проекты из общего инстанса —
его **нельзя** ронять/перезапускать в рамках задачи (см. CLAUDE.md, INFRA.md).
- Изменения касаются self-hosting пути (`is_self_hosting_repo` / `self_deploy_applies`);
для прочих репо поведение не меняется.
- Документация — golden source: затронутые `docs/architecture/README.md`,
`docs/operations/STAGING_CHECK.md`, `CHANGELOG.md` обновляются в том же PR.

View File

@@ -0,0 +1,145 @@
# 02 — ТЗ: устранение петли deploy-staging → development при self-deploy
Work Item: **ORCH-061** · Тип: **BUG** · Приоритет: **P0** · Репо: `orchestrator`
> Это ТЗ фиксирует **требования и контракты**, которые должна удовлетворить
> реализация. Конкретный архитектурный механизм (направление (а), (б) или оба;
> где именно разместить логику) выбирает архитектор в ADR (`06-adr/`).
> ТЗ намеренно не предписывает дизайн, но задаёт инварианты и границы изменений.
---
## 1. Затронутые модули `src/` и артефакты
Прямо относящиеся к дефекту (для контекста; точечный набор правок — за архитектором):
| Файл | Роль в дефекте |
|------|----------------|
| `scripts/staging_check.py` | e2e-suite; C9a (branch) / C9b (analyst job) дают ложный FAIL в sandbox; exit-code управляет вердиктом deployer. |
| `src/qg/checks.py``check_staging_status`, `_parse_staging_status` | гейт ребра `deploy-staging→deploy`; читает `staging_status:` из `15-staging-log.md`. |
| `src/stage_engine.py``advance_stage`, `_handle_qg_failure_rollbacks` | откат `deploy-staging→development` при FAILED (ветка `agent=="deployer" and qg=="check_staging_status"`). |
| `src/agents/launcher.py``_handle_completion`/`_try_advance_stage` | пост-ран git-commit; лог «no changes to commit»; обработка deployer-стадий. |
| `src/self_deploy.py` | Phase A/B/C исполняемого self-deploy (контекст продвижения `deploy`). |
| `src/config.py` | место для kill-switch/настроек нового поведения (если потребуется). |
| `.openclaw/agents/deployer.md` | инструкция deployer о написании вердикта; обновить при смене контракта. |
| `docs/operations/STAGING_CHECK.md`, `docs/architecture/README.md`, `CHANGELOG.md` | golden-source документация (обновить в том же PR). |
## 2. Функциональные требования
### FR-1 — Нет петли на корректном self-deploy
Для self-hosting `orchestrator`, при корректном состоянии (реальный pipeline в
порядке, staging-стенд здоров), задача проходит `deploy-staging → deploy → done`
**без отката** `deploy-staging → development` и **без ручного вмешательства**.
### FR-2 — Ложный (инфраструктурный) FAIL не вызывает откат
Ложное падение `staging_check` в sandbox, вызванное **исключительно** отсутствием
sandbox-настроек (например, C9a/C9b при ненастроенных bot-токенах SANDBOX), не
приводит к `staging_status: FAILED` → откату. Должно быть реализовано одним из
способов (выбор — ADR):
- **(а)** sandbox-инфраструктура приведена в состояние, при котором C9a/C9b
проходят честно (10/10); и/или
- **(б)** вердикт staging-гейта перестаёт зависеть от заведомо инфраструктурных
(не пайплайновых) проверок — например, осознанный allowlist/threshold
«известных sandbox-инфра» проверок, отделённый от реальных pipeline-проверок.
> Любой механизм по FR-2 **обязан** сохранить FR-4 (реальный провал ловится).
### FR-3 — «no changes» на action-стадии не есть недовыполнение
На стадиях деплоя (`deploy-staging`, `deploy`) для self-deploy отсутствие
git-изменений (`no changes to commit`) **не** трактуется как недовыполнение и
**не** приводит к откату/блокировке. Критерий успеха action-стадии = успешный
exit агента/хука + доказанный health/staging-вердикт, а **не** наличие нового
коммита.
### FR-4 — Реальный регресс по-прежнему откатывается (страховка цела)
- Настоящий провал реальных pipeline-проверок staging → `staging_status: FAILED`
→ откат `deploy-staging → development` (как сейчас).
- Настоящий провал прод-деплоя (`deploy_status: FAILED`, БАГ-8) → откат
`deploy → development` (как сейчас).
- Ослабления страховки быть не должно: «зелёный по умолчанию» при недоступности
проверок запрещён (fail-closed для реальных проверок сохраняется).
### FR-5 — Условность self-hosting сохранена
Изменения активны **только** для self-hosting пути
(`is_self_hosting_repo` / `self_deploy_applies`). Для прочих репозиториев
поведение `check_staging_status` (no-op N/A) и стадии деплоя — **без изменений**.
### FR-6 — Управляемость (kill-switch)
Любое новое поведение (толерантность к инфра-FAIL и/или отвязка от git-changes)
закрыто отдельным флагом конфигурации (по образцу `merge_gate_enabled`,
`image_freshness_enabled`, `self_deploy_enabled`), с безопасным дефолтом и
возможностью мгновенно вернуть прежнее поведение без передеплоя кода-логики.
### FR-7 — Наблюдаемость
Срабатывание нового поведения (например, «staging_check: проигнорирован
инфра-FAIL C9a/C9b» или «action-стадия: no-changes ожидаемо») логируется явной
строкой и при необходимости отражается в Plane-комментарии/Telegram, чтобы
оператор отличал «реальный зелёный» от «зелёного с допущением».
## 3. Изменения API
API эндпоинты (`/health`, `/status`, `/queue`, `/webhook/*`) — **без изменений**.
Допускается расширение снапшота `GET /queue` диагностическим полем (опционально,
по решению архитектора) — без удаления/переименования существующих ключей.
## 4. Изменения схемы БД
**Нет.** Схема (`events`, `tasks`, `agent_runs`, `jobs`) не меняется. Любое
restart-safe состояние (если потребуется) — через существующие паттерны
(sentinel-файлы / поля `jobs.task_content`), без миграций.
## 5. Контракты, которые НЕЛЬЗЯ менять
- `STAGE_TRANSITIONS` (порядок и состав стадий) и `get_previous_stage`.
- Состав/семантика `QG_CHECKS` как реестра; frontmatter-контракты
`staging_status:` (`15-staging-log.md`) и `deploy_status:` (`14-deploy-log.md`) —
читаются ТОЛЬКО из YAML-frontmatter, значения `SUCCESS|FAILED`.
- Откатные контракты БАГ-8 (`deploy→development`) и ORCH-35
(`deploy-staging→development`) для **реальных** провалов.
- Контракт exit-code хука деплоя (`0/1/2`) и `map_exit_code_to_status`.
- Поведение для не-self-hosting репозиториев.
## 6. Требования к новым/изменённым QG checks
- Если выбран механизм толерантности (FR-2 вариант б), он реализуется **внутри**
существующего пути `check_staging_status` / staging-вердикта (не новая стадия),
по образцу условности ORCH-35; контракт «never-raise» сохраняется.
- Любая новая проверка/под-чек регистрируется в `QG_CHECKS` и покрывается
снапшот-тестом реестра (`tests/test_qg_registry_snapshot.py`).
## 7. Требования к staging_check.py (если затрагивается)
- Если выбран механизм классификации проверок (FR-2 вариант б через suite),
e2e-проверки, заведомо зависящие от sandbox-инфраструктуры (C9a/C9b и связанные),
должны быть **отличимы** (по метке/категории) от реальных pipeline-проверок,
чтобы вердикт и/или exit-code мог их учитывать осознанно. Прежний дефолтный
режим (`stub`/`full-real`) и существующие проверки A/B сохраняются.
- Никакого «всегда 0»: реальный провал реальных проверок обязан давать ненулевой
exit-code / FAIL-категорию.
## 8. Требования к pipeline-артефактам
- Стадия деплоя по-прежнему производит машинный вердикт-артефакт
(`15-staging-log.md` / `14-deploy-log.md`) с корректным frontmatter.
- Артефакты, обновляемые по pipeline в этом PR: `docs/architecture/README.md`
(раздел про staging-гейт/self-deploy — отметить ORCH-061),
`docs/operations/STAGING_CHECK.md` (поведение C9a/C9b и/или sandbox-настройка),
`CHANGELOG.md`, при изменении контракта — `.openclaw/agents/deployer.md`.
- ADR: `docs/work-items/ORCH-061/06-adr/ADR-001-*.md` (решение по направлению/механизму).
## 9. Нефункциональные требования
- **Безопасность self-hosting:** реализация НЕ перезапускает/не роняет прод 8500
в рамках задачи; сборки/recreate — только staging (8501).
- **Идемпотентность / restart-safe:** новое поведение переживает рестарт инстанса.
- **never-raise:** дефект-исправляющая логика не должна пробрасывать исключения в
`advance_stage` (по образцу merge-gate / image-freshness).
- **Обратная совместимость:** при выключенном флаге (FR-6) — прежнее поведение 1:1.
- **Тестируемость:** «чистая» вердикт-логика выделяется так, чтобы покрываться
unit-тестами без live staging/docker.
## 10. Зависимости и связанные задачи
- ORCH-35 (условный staging-гейт, ADR-0003), ORCH-36 (исполняемый self-deploy,
ADR-0007), ORCH-58 (провенанс staging-образа), ORCH-60 (skip escalated/Blocked).
- Блокирует: ORCH-54 (автономное внедрение).

View File

@@ -0,0 +1,90 @@
# 03 — Критерии приёмки: ORCH-061
Work Item: **ORCH-061** · Тип: **BUG** · Приоритет: **P0**
Формат: каждый критерий имеет чёткое условие **PASS/FAIL**. Критерии outcome-ориентированы
(не предписывают механизм); реализация может удовлетворить FR-2 направлением (а), (б) или обоими.
---
## AC-1 — Автономный проход self-deploy без петли (главный критерий)
- **PASS:** для self-hosting `orchestrator` задача в состоянии `deploy-staging`
при здоровом стенде и корректном pipeline продвигается `deploy-staging → deploy`
(далее по штатному approve → `done`) **без** отката на `development` и **без**
ручного вмешательства в шаги staging/merge/retag/deploy.
- **FAIL:** наблюдается хотя бы один автоматический откат `deploy-staging → development`
при отсутствии реального регресса, либо для прохода требуется ручной шаг.
## AC-2 — Ложный инфраструктурный FAIL не откатывает
- **PASS:** прогон, где **единственные** падения — заведомо sandbox-инфраструктурные
(C9a branch-not-found / C9b analyst-job-not-in-queue при ненастроенных bot-токенах
SANDBOX), а все реальные pipeline-проверки зелёные, приводит к
`staging_status: SUCCESS` (или эквивалентному «не-FAILED») → **нет** отката.
- **FAIL:** такой прогон даёт `staging_status: FAILED` → откат `deploy-staging → development`.
## AC-3 — Реальный провал staging по-прежнему откатывает (страховка цела)
- **PASS:** прогон с провалом **реальной** pipeline-проверки (не инфра-исключение)
даёт `staging_status: FAILED` → откат `deploy-staging → development` +
`set_issue_blocked`/нотификации (как сейчас, ORCH-35).
- **FAIL:** реальный провал staging проходит как успех / задача доходит до `deploy`.
## AC-4 — «no changes to commit» на action-стадии не есть недовыполнение
- **PASS:** на стадиях `deploy-staging`/`deploy` для self-deploy отсутствие
git-изменений не вызывает откат/блокировку; продвижение определяется успешным
exit + health/staging-вердиктом.
- **FAIL:** отсутствие коммита на стадии деплоя приводит к откату/недопродвижению.
## AC-5 — Реальный провал прод-деплоя по-прежнему откатывает (БАГ-8 цел)
- **PASS:** `deploy_status: FAILED` (exit-code хука ≠ 0) → откат `deploy → development`
+ `set_issue_blocked` + release merge-lease + clear deploy-state (как сейчас).
- **FAIL:** провал прод-деплоя проходит как `done`.
## AC-6 — Условность self-hosting сохранена
- **PASS:** для не-self-hosting репо (`is_self_hosting_repo == False`)
`check_staging_status` остаётся `(True, "Staging gate N/A …")`, стадия деплоя
работает как прежде; поведение этих репо байт-в-байт не изменилось.
- **FAIL:** изменилось поведение для не-self-hosting репозиториев.
## AC-7 — Kill-switch возвращает прежнее поведение
- **PASS:** при выключенном флаге нового поведения (FR-6) система ведёт себя 1:1
как до ORCH-061 (включая прежний откат на инфра-FAIL, если флаг выключен).
- **FAIL:** новое поведение невозможно отключить / выключение не восстанавливает старое.
## AC-8 — Контракты не сломаны
- **PASS:** `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, frontmatter-контракты
`staging_status:`/`deploy_status:` (только YAML, `SUCCESS|FAILED`), exit-code хука
(0/1/2) и `map_exit_code_to_status` — без регресса; снапшот-тест реестра гейтов зелёный.
- **FAIL:** изменены контракты стадий/гейтов/вердиктов или сломан снапшот реестра.
## AC-9 — Схема БД не меняется
- **PASS:** нет миграций; `events`/`tasks`/`agent_runs`/`jobs` без изменений схемы.
- **FAIL:** добавлена/изменена колонка/таблица.
## AC-10 — never-raise
- **PASS:** новая логика в пути `advance_stage`/staging-вердикта при любой внутренней
ошибке (docker/ssh/io/парсинг) даёт безопасный детерминированный вердикт и не
пробрасывает исключение в `advance_stage`.
- **FAIL:** исключение из новой логики всплывает в `advance_stage`/останавливает конвейер.
## AC-11 — Наблюдаемость
- **PASS:** срабатывание нового поведения (игнор инфра-FAIL / ожидаемые no-changes)
даёт явную лог-строку (и при необходимости коммент/Telegram), позволяющую отличить
«честно зелёный» от «зелёного с допущением».
- **FAIL:** новое поведение срабатывает молча, неотличимо от честного зелёного.
## AC-12 — Безопасность self-hosting
- **PASS:** реализация не перезапускает/не роняет прод-контейнер 8500 в рамках
задачи; любые сборки/recreate — только staging (8501).
- **FAIL:** код пути задачи рестартит/собирает прод 8500.
## AC-13 — Документация обновлена (golden source)
- **PASS:** в том же PR обновлены `docs/architecture/README.md`,
`docs/operations/STAGING_CHECK.md` (поведение C9a/C9b и/или sandbox-настройка),
`CHANGELOG.md`, и (при смене контракта) `.openclaw/agents/deployer.md`; заведён
ADR `docs/work-items/ORCH-061/06-adr/ADR-001-*.md`.
- **FAIL:** функционал изменён без обновления документации/ADR.
## AC-14 — Регрессионные тесты зелёные
- **PASS:** `pytest tests/ -q` проходит полностью; новые тесты из `04-test-plan.yaml`
присутствуют и зелёные; существующие staging/deploy/qg/stage_engine тесты не упали.
- **FAIL:** любой тест из плана отсутствует или красный.

View File

@@ -0,0 +1,147 @@
work_item: ORCH-061
title: "BUG: deploy-staging петля — откат на development (self-deploy)"
description: >
План тестов на устранение зацикливания deploy-staging -> development для
self-hosting orchestrator. Покрывает обе подтверждённые причины: (1) ложный
FAILED check_staging_status из-за заведомо инфраструктурных C9a/C9b в sandbox;
(2) трактовку "no changes to commit" на action-стадии как недовыполнения.
Тесты outcome-ориентированы и не предписывают механизм: часть кейсов помечена
как mechanism-dependent (а=sandbox-инфра честно, б=толерантность/отвязка) —
финальный набор подтверждает архитектор в ADR; реализуются тесты под выбранный
механизм. Инвариант страховки (реальный регресс откатывает) и условность
self-hosting проверяются ВСЕГДА.
tests:
# --- Главный сценарий: нет петли ----------------------------------------
- id: TC-01
type: unit
description: >
Корректный self-deploy: при staging_status SUCCESS и пройденном merge/freshness
sub-gate advance_stage(deploy-staging, finished_agent=deployer) продвигает к
deploy (Phase A approval-pending), НЕ откатывает на development. (AC-1)
module: tests/test_stage_engine.py
expected: PASS
- id: TC-02
type: unit
description: >
Регресс-страховка ORCH-35: реальный провал реальной pipeline-проверки ->
staging_status FAILED -> advance_stage откатывает deploy-staging -> development
+ set_issue_blocked. (AC-3)
module: tests/test_stage_engine.py
expected: PASS
# --- Причина №1: ложный инфраструктурный FAIL ---------------------------
- id: TC-03
type: unit
description: >
Классификация проверок staging_check: проверки, заведомо зависящие от
sandbox-инфраструктуры (C9a/C9b), отличимы (метка/категория) от реальных
pipeline-проверок. Чистая логика классификации/вердикта тестируется без
live staging/docker. (AC-2, mechanism-dependent: вариант б)
module: tests/test_staging_check_b6.py
expected: PASS
- id: TC-04
type: unit
description: >
Вердикт-логика: все реальные проверки PASS, падают ТОЛЬКО известные
sandbox-инфра проверки (C9a/C9b) -> итог не-FAILED (нет ложного отката).
(AC-2)
module: tests/test_qg_checks.py
expected: PASS
- id: TC-05
type: unit
description: >
Вердикт-логика: падает хотя бы одна РЕАЛЬНАЯ pipeline-проверка (помимо инфра)
-> итог FAILED (страховка не ослаблена, fail-closed). (AC-3)
module: tests/test_qg_checks.py
expected: PASS
# --- Причина №2: no changes на action-стадии ----------------------------
- id: TC-06
type: unit
description: >
На action-стадии (deploy-staging/deploy) для self-deploy отсутствие
git-изменений ("no changes to commit") НЕ приводит к откату/недопродвижению;
продвижение определяется exit + вердиктом, а не наличием коммита. (AC-4)
module: tests/test_launcher.py
expected: PASS
- id: TC-07
type: unit
description: >
На code-стадии (development) отсутствие изменений всё ещё обрабатывается
прежним образом (нет ложного "успеха" там, где код должен был измениться) —
изменение FR-3 не протекает на не-action стадии. (AC-4, regression-guard)
module: tests/test_launcher.py
expected: PASS
# --- Условность self-hosting --------------------------------------------
- id: TC-08
type: unit
description: >
Для не-self-hosting репо check_staging_status остаётся (True, "Staging gate
N/A …") и новое поведение НЕ активируется; поведение этих репо неизменно.
(AC-6, FR-5)
module: tests/test_qg.py
expected: PASS
# --- Kill-switch / обратная совместимость -------------------------------
- id: TC-09
type: unit
description: >
При выключенном флаге нового поведения (FR-6) система ведёт себя 1:1 как до
ORCH-061: инфра-FAIL снова приводит к FAILED/откату. Дефолт флага безопасен.
(AC-7)
module: tests/test_config.py
expected: PASS
# --- БАГ-8: реальный провал прод-деплоя ----------------------------------
- id: TC-10
type: unit
description: >
deploy_status FAILED (exit-code хука != 0) -> откат deploy -> development +
set_issue_blocked + release merge-lease + clear deploy-state (БАГ-8 не сломан).
(AC-5)
module: tests/test_deploy_rollback.py
expected: PASS
# --- Контракты / реестр / never-raise -----------------------------------
- id: TC-11
type: unit
description: >
Снапшот реестра QG_CHECKS и STAGE_TRANSITIONS не изменён неожиданно;
frontmatter-контракты staging_status/deploy_status (SUCCESS|FAILED, только
YAML) сохранены. (AC-8)
module: tests/test_qg_registry_snapshot.py
expected: PASS
- id: TC-12
type: unit
description: >
never-raise: новая логика staging-вердикта/advance при внутренней ошибке
(io/парсинг/docker/ssh) возвращает безопасный детерминированный вердикт и не
пробрасывает исключение в advance_stage. (AC-10)
module: tests/test_stage_engine.py
expected: PASS
# --- Интеграционный сквозной сценарий ------------------------------------
- id: TC-13
type: integration
description: >
Сквозной self-deploy на тестовой БД: задача deploy-staging при здоровом
стенде с инфра-only недочётами проходит deploy-staging -> deploy (Phase A) ->
(approve) -> deploy финализация SUCCESS -> done, БЕЗ единого отката на
development в логе переходов. (AC-1, AC-4)
module: tests/test_stage_engine.py
expected: PASS
- id: TC-14
type: integration
description: >
Наблюдаемость: при срабатывании нового поведения (игнор инфра-FAIL /
ожидаемые no-changes) присутствует явная лог-строка/диагностика, отличающая
"честно зелёный" от "зелёного с допущением". (AC-11)
module: tests/test_stage_engine.py
expected: PASS

View File

@@ -0,0 +1,222 @@
# ADR-001 — Толерантность staging-вердикта к инфра-FAIL + инвариант «no-changes на action-стадии»
- **Статус:** Accepted
- **Дата:** 2026-06-07
- **Задача:** ORCH-061 (BUG, P0) · Репо: `orchestrator` (self-hosting)
- **Связи:** ORCH-35/adr-0003 (условный staging-гейт), ORCH-36/adr-0007 (исполняемый self-deploy), ORCH-58/adr-0008 (провенанс staging-образа), ORCH-43/adr-0006 (merge-gate); блокирует ORCH-54.
- **Сквозной ADR:** [adr-0009-staging-infra-tolerance](../../../architecture/adr/adr-0009-staging-infra-tolerance.md)
---
## Контекст
На стадии `deploy-staging` self-hosting `orchestrator` зацикливается:
`check_staging_status` даёт FAILED → `_handle_qg_failure_rollbacks` откатывает
`deploy-staging → development` → developer перезапускается → конвейер заново →
снова `deploy-staging` → снова FAILED. Петля жжёт developer-ретраи и LLM-кредиты,
а прод-деплой орка приходится доводить вручную (ORCH-58, ORCH-60). Это прямой
блокер автономного внедрения (ORCH-54).
Подтверждены две независимые причины (BRD §2):
**Причина №1 — ложный FAILED.** `scripts/staging_check.py` в sandbox даёт
8/10 PASS, 2 ложных FAIL на e2e-блоке C:
- **C9a** — ветка не появляется в `orchestrator-sandbox`;
- **C9b** — analyst-job не появляется в staging-очереди.
Оба завязаны на отсутствие sandbox-настроек (bot-аккаунты `ORCH_PLANE_BOT_*` не
добавлены членами SANDBOX-проекта — проект создан после провижининга ботов). Это
**отсутствие инфраструктуры sandbox, а не регресс кода**. Но `staging_check.py`
суммирует `all_ok = passed == total` и делает `sys.exit(1)` при любом FAIL →
deployer пишет `staging_status: FAILED` → откат.
**Причина №2 — «no changes to commit» на action-стадии.** Стадии деплоя по природе
действие (рестарт/retag), а не правка `src/`. Отсутствие git-изменений не должно
трактоваться как недовыполнение; критерий успеха action-стадии — exit0 +
health/staging-вердикт, а не наличие коммита.
### Что есть сейчас в коде (точки дефекта)
- `scripts/staging_check.py`: `Results.summary()``all_ok = passed == total`;
`main()``sys.exit(0 if all_ok else 1)`. Все проверки равнозначны — инфра-FAIL
неотличим от регресса.
- `src/qg/checks.py``check_staging_status` / `_parse_staging_status`: читает
`staging_status:` (SUCCESS|FAILED) из `15-staging-log.md`. Условный (ORCH-35):
для не-self репо → `(True, "Staging gate N/A …")`.
- `src/stage_engine.py``_handle_qg_failure_rollbacks`: ветка
`agent=="deployer" and qg=="check_staging_status"` → откат на `development`.
- `src/agents/launcher.py``_monitor_agent`: ветка «no changes to commit» (строка
~583) **уже** просто логирует и идёт в `_try_advance_stage` (НЕ откатывает).
## Рассмотренные направления (BRD §6)
- **(а) Починить sandbox-инфру** — добавить bot-токены SANDBOX, чтобы C9a/C9b
проходили честно (10/10).
- *Минусы:* хрупко (зависит от членства ботов в Plane-проекте, поддерживается
руками вне кода); не предотвращает структурно будущие инфра-only FAIL;
автономный self-deploy-таск не может надёжно выполнить Plane-admin действия сам.
Не закрывает Причину №1 на уровне инварианта.
- **(б) Отвязать вердикт от заведомо инфраструктурных проверок** — классифицировать
проверки suite и сделать вердикт толерантным к инфра-FAIL, сохранив fail-closed
для реальных проверок.
- *Плюсы:* структурно, юнит-тестируемо (чистая вердикт-логика), управляемо
(kill-switch), наблюдаемо (FR-7); сохраняет страховку (FR-4) по построению.
## Решение
Выбран механизм **(б)** как основной, с явной фиксацией инварианта по Причине №2.
Направление (а) переведено в **необязательное hardening** (см. `07-infra-requirements.md`):
с (б) оно перестаёт быть блокером.
### 1. Классификация проверок + толерантный вердикт (Причина №1, FR-2/FR-4)
Новый **leaf-модуль `src/staging_verdict.py`** — чистая логика, без I/O, контракт
**never-raise**, только stdlib (импортируем и из orchestrator, и из
`staging_check.py`, который уже импортирует `src.*` внутри контейнера — паттерн B6/ORCH-048):
```
REAL = "real" # реальная pipeline-проверка
SANDBOX_INFRA = "sandbox_infra" # заведомо зависит от sandbox-инфры
# Узкий allowlist известных инфра-проверок (по префиксу метки):
SANDBOX_INFRA_CHECKS = frozenset({"C9a", "C9b"})
def classify_check(label: str) -> str:
"""SANDBOX_INFRA если метка начинается с известного инфра-префикса, иначе REAL.
Never-raise: на любом непонятном вводе → REAL (консервативно, fail-closed)."""
def compute_staging_verdict(items, infra_tolerant: bool) -> StagingVerdict:
"""items: список (label, passed: bool, category: str).
real_failed = [REAL-проверки с passed=False]
infra_failed = [SANDBOX_INFRA-проверки с passed=False]
- real_failed непусто -> FAILED, exit 1 (страховка)
- infra_failed непусто и infra_tolerant -> SUCCESS, exit 0 (waived)
- infra_failed непусто и НЕ infra_tolerant -> FAILED, exit 1 (legacy strict)
- иначе -> SUCCESS, exit 0
Never-raise: на битом вводе → консервативный FAILED."""
```
`StagingVerdict` несёт `status` (`"SUCCESS"|"FAILED"`), `exit_code` (`0|1`),
`waived` (список заваиверенных меток) и `summary` (человекочитаемая строка).
**Ключевой инвариант страховки (FR-4):** любая упавшая REAL-проверка ⇒ exit 1 ⇒
FAILED ⇒ откат. В частности C7 (создать issue) и C8 (триггер `/webhook/plane`) —
REAL. Waiver применяется к C9a/C9b **только** когда все REAL-проверки (включая
C7/C8) зелёные. Вход в конвейер по-прежнему валидируется C7/C8; C9a/C9b проверяют
лишь downstream-артефакты, которым нужна sandbox-инфра. Так blast-radius waiver'а
сведён к двум именованным проверкам.
### 2. Правки `scripts/staging_check.py`
- `Results.add(label, passed, detail="", category=None)` — при `category is None`
авто-классификация через `staging_verdict.classify_check(label)`; хранит категорию
в элементе.
- `Results.summary()` печатает разбивку по категориям (REAL / SANDBOX_INFRA).
- `main()`:
- резолвит флаг толерантности `_resolve_tolerance()` (см. ниже);
- `verdict = compute_staging_verdict(results.items, infra_tolerant)`;
- при `verdict.waived` печатает явную строку
`INFRA-WAIVED: <labels> (known sandbox-infra; real checks green)` (FR-7);
- `sys.exit(verdict.exit_code)`.
- `_resolve_tolerance()`: читает `settings.staging_infra_tolerance_enabled` (через
`from src.config import settings` — тот же паттерн, что B6). На ошибке импорта →
**strict (False)** (fail-safe: не вайвить при нечитаемом конфиге) + warning.
Опциональный CLI-флаг `--strict` принудительно выключает толерантность для ручных
«честных» прогонов.
Прежние режимы (`--mode stub|full-real`) и проверки A/B/C7/C8 — без изменений.
«Всегда 0» исключено: упавшая REAL-проверка всегда даёт exit 1 (TRZ §7).
### 3. Kill-switch (FR-6, AC-7)
`src/config.py`:
```python
# ORCH-061: толерантность staging-вердикта к заведомо инфраструктурным FAIL
# (C9a/C9b) в sandbox. True -> упавшие ТОЛЬКО sandbox-инфра проверки вайверятся
# (real-проверки fail-closed). False -> 1:1 прежнее строгое поведение (любой FAIL
# -> staging_status FAILED -> откат). Env ORCH_STAGING_INFRA_TOLERANCE_ENABLED.
staging_infra_tolerance_enabled: bool = True
```
Дефолт **True** (как `merge_gate_enabled` / `image_freshness_enabled` /
`self_deploy_enabled`): инвариант страховки (FR-4) держится независимо от флага —
реальные провалы всё равно fail-closed; флаг существует, чтобы мгновенно вернуть
legacy-строгость без передеплоя кода. Флаг живёт в `.env.staging` контейнера
(`ORCH_` prefix), поэтому достижим скриптом внутри `orchestrator-staging`.
`False` → suite строгий → 1:1 поведение до ORCH-061 (AC-7).
### 4. Что НЕ меняется (контракты, AC-8)
- `check_staging_status` / `_parse_staging_status`**без изменений**: читают
`staging_status:` (только YAML, `SUCCESS|FAILED`). Толерантность реализована
ДО артефакта (в exit-code suite → вердикт deployer), внутри существующего пути
staging-вердикта, не отдельной стадией (TRZ §6).
- **Новый QG-чек НЕ добавляется** → реестр `QG_CHECKS` и снапшот-тест
(`tests/test_qg_registry_snapshot.py`) неизменны (AC-8 / TC-11).
- `STAGE_TRANSITIONS`, `get_previous_stage`, exit-code хука деплоя (0/1/2),
`map_exit_code_to_status`, `check_deploy_status`, БАГ-8 — без изменений.
- Условность self-hosting (AC-6): `staging_check.py` канонически бежит только для
`orchestrator`; `check_staging_status` для не-self репо остаётся
`(True, "Staging gate N/A …")`. Поведение прочих репо байт-в-байт неизменно.
### 5. Инвариант «no-changes на action-стадии» (Причина №2, FR-3/AC-4)
`launcher._monitor_agent` **уже** не откатывает на «no changes to commit» (просто
логирует и идёт в `_try_advance_stage`; продвижение определяется гейтом). ORCH-061:
- **Фиксируем инвариант** как покрытый тестами контракт: на `deploy-staging`/`deploy`
для self-deploy продвижение определяется exit0 + гейт-вердиктом, НИКОГДА наличием
коммита (TC-06).
- **Наблюдаемость (FR-7/AC-11):** в ветке «no changes» логировать явную строку,
отличающую action-стадию (ожидаемо: артефакт-вердикт, не обязательно код) от
code-стадии. Резолв стадии задачи по `(repo, branch)`; при
`stage ∈ {deploy-staging, deploy}` и `self_deploy.self_deploy_applies(repo)`
`staging/deploy: no code changes (expected on action stage)`.
- **Regression-guard (TC-07):** на `development` (code-стадия) поведение «no changes»
неизменно — изменение FR-3 не протекает на не-action стадию.
Изменение минимальное (self-hosting safety, AC-12): не трогает прод-контейнер 8500,
сборки/recreate — только staging (8501).
## Затронутые файлы (для developer)
| Файл | Изменение |
|------|-----------|
| `src/staging_verdict.py` | **новый** leaf-модуль: `classify_check`, `compute_staging_verdict`, `StagingVerdict` (pure, never-raise). |
| `scripts/staging_check.py` | категории в `Results`, вердикт через `staging_verdict`, INFRA-WAIVED-лог, `--strict`. |
| `src/config.py` | флаг `staging_infra_tolerance_enabled` (env `ORCH_STAGING_INFRA_TOLERANCE_ENABLED`). |
| `src/agents/launcher.py` | observability-лог action-stage no-changes (без смены логики продвижения). |
| `.openclaw/agents/deployer.md` | уточнение: exit0 может включать «infra-waived»; контракт `staging_status:` SUCCESS\|FAILED неизменен. |
| `docs/operations/STAGING_CHECK.md` | поведение C9a/C9b, флаг, INFRA-WAIVED, `--strict`. |
| `docs/architecture/README.md` | пометка ORCH-061 в разделе staging-гейта (уже внесена архитектором). |
| `CHANGELOG.md` | запись ORCH-061. |
| `tests/` | TC-01…TC-14 (см. `04-test-plan.yaml`). |
## Последствия
**Плюсы**
- Петля устранена структурно: ложный инфра-FAIL → SUCCESS (waived) → нет отката (G1/G2).
- Страховка цела: любая реальная pipeline-проверка fail-closed → FAILED → откат (G4/FR-4).
- Чистая вердикт-логика юнит-тестируема без live staging/docker (NFR-тестируемость).
- Контракты гейтов/стадий/вердиктов/реестра не тронуты (AC-8); схема БД не меняется (AC-9).
- Мгновенный откат к legacy через kill-switch (AC-7).
- Разблокирует автономный self-deploy (ORCH-54).
**Минусы / ограничения**
- C9a/C9b теперь могут заваиверить **реальный** даунстрим-регресс именно в создании
ветки / постановке analyst-job (узкий риск). Митигировано: waiver только когда C7/C8
и все прочие REAL зелёные; allowlist жёстко = {C9a, C9b}; INFRA-WAIVED логируется и
виден оператору. См. `10-tech-risks.md` (R-1).
- Толерантность скрывает «нездоровье sandbox» как зелёное-с-допущением; отличимо
только по INFRA-WAIVED-логу/комментарию (наблюдаемость обязательна, FR-7).
- Honest 10/10 в sandbox (направление а) остаётся желательным hardening, но не блокером.
## Альтернативы (отклонены)
- **Только (а) — починить sandbox-инфру:** хрупко, не структурно, вне автономной
досягаемости таска. Оставлено как опциональное hardening.
- **«Зелёный по умолчанию» при недоступности проверок:** запрещён FR-4 (fail-closed).
- **Новый QG-чек `check_staging_infra_tolerant`:** избыточно — менял бы реестр
`QG_CHECKS` и снапшот; толерантность лучше живёт в suite/вердикте до артефакта.
- **Толерантность внутри `check_staging_status` через структурный артефакт:**
потребовал бы сменить контракт `15-staging-log.md` и научить deployer писать
per-check категории — больше движущихся частей; отклонено в пользу решения в suite.

View File

@@ -0,0 +1,37 @@
# 07 — Требования к инфраструктуре: ORCH-061
Work Item: **ORCH-061** · Репо: `orchestrator`
Топология/контейнеры/порты **не меняются** (TRZ §3, §9). Self-hosting-безопасность
сохранена: прод-контейнер `orchestrator` (8500) не перезапускается/не роняется в
рамках задачи; любые сборки/recreate — только staging (8501). См.
`docs/operations/INFRA.md`.
## IR-1 — Конфиг-флаг (kill-switch)
Новый флаг `staging_infra_tolerance_enabled` (env
`ORCH_STAGING_INFRA_TOLERANCE_ENABLED`, дефолт `true`).
- Должен присутствовать в окружении контейнера **`orchestrator-staging`**
(`.env.staging`), т.к. `scripts/staging_check.py` читает его через
`src.config.settings` при каноническом запуске `docker exec` внутри стенда.
- Для прод-инстанса (`.env`) флаг безвреден (на прод-пути staging-suite не
исполняется), но рекомендуется держать значения консистентными.
- `false` → мгновенный возврат к строгому (legacy) поведению без передеплоя кода.
- Канон секретов/env: значения в `.env`/`.env.staging` на хосте, в гит НЕ
коммитятся; задокументировать ключ в `.env.example` (канон ORCH-9).
## IR-2 — Опциональное hardening sandbox (направление «а», НЕ блокер)
Первопричина ложных C9a/C9b — bot-аккаунты агентов (`ORCH_PLANE_BOT_*`) не добавлены
членами Plane-проекта **SANDBOX** (`8c5a3025-…`), созданного после провижининга
ботов. С выбранным механизмом (б) это перестаёт блокировать конвейер, но честный
10/10 в sandbox желателен:
- Добавить bot-аккаунты агентов членами SANDBOX-проекта в Plane (даст честный
C9b: коммент analyst'а перестанет получать 403; и устранит инфра-причину C9a/C9b).
- Действие — ручное (Plane-admin), вне автоматической досягаемости таска; выполняется
оператором при возможности. После него C9a/C9b проходят честно и waiver не нужен.
- Это hardening, а не требование приёмки ORCH-061 (приёмка — на механизме «б»).
## IR-3 — Без новой инфраструктуры
Новые сервисы/порты/тома/сетевые правила/cron — **не требуются**. Никаких
изменений в `docker-compose.yml`, образах, реестре проектов.

View File

@@ -0,0 +1,20 @@
# 08 — Требования к данным / схеме БД: ORCH-061
Work Item: **ORCH-061** · Репо: `orchestrator`
## DR-1 — Схема БД не меняется (AC-9)
Никаких миграций. Таблицы `events`, `tasks`, `agent_runs`, `jobs` — без изменений
колонок/индексов/таблиц.
## DR-2 — Никакого нового персистентного состояния
Решение (ADR-001) — чистая вердикт-логика (`src/staging_verdict.py`) + конфиг-флаг +
правка exit-code suite. Состояние конвейера не вводится:
- толерантность вычисляется на лету при прогоне `staging_check.py`;
- restart-safe-состояние не требуется (вердикт фиксируется в существующем артефакте
`15-staging-log.md` через прежний контракт `staging_status: SUCCESS|FAILED`).
## DR-3 — Артефакт-контракт неизменен
`15-staging-log.md` по-прежнему несёт frontmatter `staging_status: SUCCESS|FAILED`
(только YAML). `14-deploy-log.md` (`deploy_status:`) — без изменений. Гейты читают
ТОЛЬКО frontmatter. Толерантность реализована ДО записи артефакта (на уровне
exit-code suite → вердикт deployer), поэтому формат и парсинг артефактов не трогаются.

View File

@@ -0,0 +1,25 @@
# 10 — Технические риски: ORCH-061
Work Item: **ORCH-061** · Репо: `orchestrator` (self-hosting)
| # | Риск | Вероятн. | Влияние | Митигация |
|---|------|----------|---------|-----------|
| **R-1** | Waiver C9a/C9b маскирует **реальный** регресс именно в создании ветки / постановке analyst-job (ложно-зелёный staging). | Низкая | Высокое | Allowlist жёстко `{C9a, C9b}`; waiver применяется ТОЛЬКО когда ВСЕ REAL-проверки зелёные, включая C7 (создать issue) и C8 (триггер `/webhook/plane`) — вход в конвейер всегда валидируется реально. `INFRA-WAIVED`-строка в логе/комменте делает допущение видимым (FR-7). Honest 10/10 (IR-2) убирает риск совсем. |
| **R-2** | Ослабление страховки: реальный pipeline-FAIL пройдёт как SUCCESS. | Низкая | Критич. | Инвариант `compute_staging_verdict`: любая упавшая REAL → exit1 → FAILED → откат (FR-4/AC-3/TC-05). Покрыто юнит-тестом отдельным кейсом. |
| **R-3** | Флаг не достигает скрипта (читается не из того env) → толерантность «молча» не работает или, наоборот, не выключается. | Средняя | Среднее | Скрипт читает `settings.staging_infra_tolerance_enabled` через `from src.config import settings` — тот же канал, что B6/ORCH-048 (внутри `orchestrator-staging`, env `.env.staging`). На ошибке импорта — fail-safe в strict (False) + warning. Документировать ключ в `.env.staging`/`.env.example` (IR-1). Тест kill-switch (TC-09). |
| **R-4** | Классификатор ошибочно пометит REAL-проверку как SANDBOX_INFRA (расширение allowlist в будущем). | Низкая | Высокое | `classify_check` — узкий префиксный allowlist; добавление новой инфра-метки требует осознанного PR + теста (TC-03). По умолчанию неизвестная метка → REAL (консервативно). |
| **R-5** | Регресс совместимости: изменение exit-code suite ломает другие потребители (deploy-хук, ручные прогоны). | Низкая | Среднее | Exit-code семантика сохранена для honest-прогонов (всё PASS → 0; реальный FAIL → 1). Меняется лишь трактовка «только инфра-FAIL» (теперь 0 при толерантности). Deployer-маппинг exit0→SUCCESS/≠0→FAILED не меняется; deployer.md уточняется. `--strict` даёт ручной honest-режим. |
| **R-6** | never-raise нарушен: исключение из `staging_verdict`/классификатора. | Низкая | Среднее | `src/staging_verdict.py` — pure, без I/O; контракт never-raise (на битом вводе → консервативный FAILED). Логика вне пути `advance_stage` (исполняется в subprocess suite), поэтому в конвейер исключение структурно не попадает (AC-10). |
| **R-7** | FR-3: правка no-changes протекает на code-стадию (`development`) и маскирует «developer ничего не сделал». | Низкая | Среднее | Observability-строка ограничена `stage ∈ {deploy-staging, deploy}` и `self_deploy_applies(repo)`; логика продвижения launcher не меняется. Regression-guard TC-07. |
| **R-8** | Self-hosting: правки случайно затронут прод 8500 / не-self репо. | Низкая | Критич. | Изменения только на self-deploy-пути и в suite (бежит лишь для `orchestrator`-staging). `check_staging_status` для не-self репо неизменно `(True, N/A)` (AC-6/TC-08). Сборки/recreate — только 8501. Прод 8500 не трогается (AC-12). |
## Контрактные инварианты (не нарушать)
- `STAGE_TRANSITIONS`, `get_previous_stage` — без изменений.
- Реестр `QG_CHECKS` — без изменений; новый QG-чек НЕ вводится (снапшот-тест зелёный, TC-11).
- Frontmatter `staging_status:` / `deploy_status:` — только YAML, `SUCCESS|FAILED`.
- Exit-code хука деплоя (0/1/2) и `map_exit_code_to_status` — без изменений.
- БАГ-8 (`deploy → development`) и ORCH-35 (`deploy-staging → development`) для
**реальных** провалов — сохранены.
- Схема БД — без миграций.
# ci-rerun 2026-06-07T13:08:38Z after disk cleanup
# ci-rerun gitea-restarted 2026-06-07T13:14:14Z

View File

@@ -0,0 +1,88 @@
---
type: review
work_item_id: ORCH-061
verdict: APPROVED
version: 1
---
# Review ORCH-061
## Summary
Исправление петли `deploy-staging → development` при self-hosting self-deploy.
Реализовано Direction (б) из ADR-001: классификация staging-проверок на `REAL`
(fail-closed) и `SANDBOX_INFRA` (узкий allowlist `{C9a, C9b}`, waivable) +
толерантный-но-fail-closed вердикт.
Реализация **полностью соответствует ТЗ (02-trz.md), критериям приёмки
(03-acceptance-criteria.md) и ADR-001**. Все контракты сохранены, документация
обновлена в том же PR, тесты зелёные.
Проверено по осям:
- **Соответствие ТЗ:** FR-1…FR-7 закрыты. Новый leaf-модуль
`src/staging_verdict.py` (stdlib-only, never-raise), флаг
`staging_infra_tolerance_enabled` (kill-switch, default True), observability
через `INFRA-WAIVED:`/`VERDICT:` и `action_stage_no_changes_note`.
- **Соответствие ADR-001:** механизм, allowlist `{C9a, C9b}`, fail-closed для
REAL, waiver только когда все REAL (вкл. C7/C8) зелёные, `--strict`,
`_resolve_tolerance` (fail-safe → strict при нечитаемом конфиге) — реализовано
ровно как в «Решении» ADR. Затронутые файлы совпадают с таблицей ADR.
- **Контракты (AC-8):** `src/qg/checks.py` (`check_staging_status`/
`_parse_staging_status`), `src/stages.py` (`STAGE_TRANSITIONS`, `QG_CHECKS`)
**не изменены** (подтверждено `git diff`). Толерантность живёт в suite ДО
записи артефакта; новый QG-чек не вводится; реестр-снапшот цел.
- **Схема БД (AC-9):** миграций нет, флаг — только конфиг.
- **never-raise (AC-10):** `compute_staging_verdict`/`classify_check`/
`_coerce_item`/`action_stage_no_changes_note` ловят всё и деградируют в
консервативный FAILED/None. Покрыто TC-12.
- **Условность self-hosting / страховка (AC-3/AC-5/AC-6):** rollback на реальном
FAIL сохранён (`tests/test_stage_engine.py` TestStaging*), поведение не-self
репо неизменно.
- **Тесты (AC-14):** `pytest tests/ -q`**670 passed**. ORCH-061 покрытие:
TC-04 (infra waived → SUCCESS), TC-05 (REAL fail → FAILED), TC-09 (strict),
TC-12 (garbage never-raise), TC-06/TC-07 (action-stage no-changes note),
non-self репо.
- **Безопасность self-hosting (AC-12):** код задачи не трогает прод 8500;
сборки/recreate — вне пути этой логики.
Примечание по диффу: при просмотре `git diff main...HEAD` появлялись файлы
ORCH-060 (reconciler, plane_sync, config reconcile-флаги). Это артефакт
**устаревшего локального ref `main`**`origin/main` уже содержит ORCH-060
(merge `d4c6cc0`, PR #60). Истинный `git diff origin/main...HEAD` — чистый
ORCH-061. Бандлинга чужого work-item нет.
## Findings
### P0 — Blocker
- нет
### P1 — Must fix
- нет
### P2 — Should fix
- [ ] **Стрэй-файлы агентного скрэтча закоммичены в репо:** `.task.md`,
`.task-arch.md`, `.task-dev.md` (хэндофф-файлы стадий analysis/architecture/
development) попали в коммит и не покрыты `.gitignore`. Это засоряет репо и
будет повторяться каждый прогон. Рекомендация: удалить из индекса и добавить
`.task*.md` в `.gitignore`. Не функциональный дефект — на корректность
ORCH-061 не влияет.
## Документация
Обновлена в том же PR (golden source, AC-13) — соответствует требованию CLAUDE.md:
- `docs/architecture/README.md` — раздел staging-гейта помечен ORCH-061 +
статус в футере.
- `docs/architecture/adr/adr-0009-staging-infra-tolerance.md` — сквозной ADR
заведён; `adr/README.md` обновлён.
- `docs/operations/STAGING_CHECK.md` — поведение C9a/C9b, флаг, INFRA-WAIVED,
`--strict`.
- `.openclaw/agents/deployer.md` — уточнён контракт exit0/INFRA-WAIVED (контракт
`staging_status: SUCCESS|FAILED` неизменён).
- `.env.example``ORCH_STAGING_INFRA_TOLERANCE_ENABLED` (канон, секреты не
коммитятся).
- `CHANGELOG.md` — запись ORCH-061.
- ADR per-work-item `docs/work-items/ORCH-061/06-adr/ADR-001-*.md` — присутствует.
Документация полная и точная; расхождений с кодом не выявлено.

View File

@@ -0,0 +1,85 @@
---
type: test-report
work_item_id: ORCH-061
result: PASS
---
# Test Report — ORCH-061
BUG: устранение петли `deploy-staging → development` при self-hosting self-deploy.
Реализован Direction (б) из ADR-001: классификация staging-проверок на `REAL`
(fail-closed) и `SANDBOX_INFRA` (allowlist `{C9a, C9b}`, waivable) + толерантный,
но fail-closed вердикт (`src/staging_verdict.py`), kill-switch
`staging_infra_tolerance_enabled` (env `ORCH_STAGING_INFRA_TOLERANCE_ENABLED`).
## Окружение
- Python: 3.12.13
- pytest: 8.3.3
- Дата: 2026-06-07T13:19Z
- Ветка: `feature/ORCH-061-bug-deploy-staging-development`
- Review verdict: APPROVED (12-review.md)
## Smoke test API (prod 8500, read-only)
| Endpoint | Результат |
|----------|-----------|
| GET /health | HTTP 200 `{"status":"ok","service":"orchestrator"}` |
| GET /status | HTTP 200 (ORCH-061 в стадии `testing`) |
| GET /queue | HTTP 200 (counts/resilience/reconcile present) |
> Прод-контейнер 8500 не перезапускался и не трогался (self-hosting safety, AC-12).
## Результаты по тест-плану (04-test-plan.yaml)
| TC ID | Описание | Тест | Результат |
|-------|----------|------|-----------|
| TC-01 | Корректный self-deploy: staging SUCCESS → advance к deploy, без отката | `test_stage_engine.py::test_tc01_healthy_self_deploy_advances_no_rollback` | PASS |
| TC-02 | Страховка ORCH-35: реальный FAIL → откат deploy-staging→development | `test_stage_engine.py::test_tc02_real_staging_failed_rolls_back` | PASS |
| TC-03 | Классификация REAL vs SANDBOX_INFRA (C9a/C9b отличимы) | `test_staging_check_b6.py::test_tc03_classify_infra_checks` (+ records/override/strict) | PASS |
| TC-04 | Падают только C9a/C9b → итог не-FAILED (нет ложного отката) | `test_qg_checks.py::test_tc04_only_infra_failures_waived_to_success` | PASS |
| TC-05 | Падает реальная pipeline-проверка → FAILED (fail-closed) | `test_qg_checks.py::test_tc05_any_real_failure_fails_closed` (+ `_even_alone`) | PASS |
| TC-06 | no-changes на action-стадии (deploy-staging/deploy) не есть недовыполнение | `test_launcher.py::test_tc06_deploy_staging_self_deploy_returns_note` / `test_tc06_deploy_self_deploy_returns_note` | PASS |
| TC-07 | regression-guard: на code-стадии (development) поведение прежнее | `test_launcher.py::test_tc07_development_stage_returns_none` | PASS |
| TC-08 | Не-self-hosting репо: check_staging_status остаётся (True, "N/A …") | `test_qg.py` (no-op N/A) | PASS |
| TC-09 | Kill-switch выкл → 1:1 прежнее строгое поведение, безопасный дефолт | `test_qg_checks.py::test_tc09_infra_failure_strict_mode_fails_closed` + `test_config.py::test_staging_infra_tolerance_*` | PASS |
| TC-10 | БАГ-8: deploy_status FAILED → откат deploy→development | `test_deploy_rollback.py` | PASS |
| TC-11 | Снапшот QG_CHECKS / STAGE_TRANSITIONS не изменён; frontmatter-контракты целы | `test_qg_registry_snapshot.py` | PASS |
| TC-12 | never-raise: вердикт-логика при мусоре → безопасный детерминированный FAILED | `test_qg_checks.py::test_tc12_compute_verdict_never_raises_on_garbage` + `test_stage_engine.py::test_tc12_retry_and_rollback_behavior_unchanged` | PASS |
| TC-13 | Сквозной self-deploy: deploy-staging→deploy→done без единого отката | `test_stage_engine.py::test_tc13_end_to_end_self_deploy_no_single_rollback` | PASS |
| TC-14 | Наблюдаемость: «зелёный с допущением» отличим от честного зелёного | `test_stage_engine.py::test_tc14_waived_green_distinguishable_from_honest_green` | PASS |
Все 14 TC присутствуют и зелёные.
## Сопоставление с критериями приёмки (03-acceptance-criteria.md)
| AC | Критерий | Покрытие | Статус |
|----|----------|----------|--------|
| AC-1 | Проход self-deploy без петли | TC-01, TC-13 | PASS |
| AC-2 | Инфра-FAIL (C9a/C9b) не откатывает | TC-03, TC-04 | PASS |
| AC-3 | Реальный провал staging откатывает | TC-02, TC-05 | PASS |
| AC-4 | no-changes на action-стадии ≠ недовыполнение | TC-06, TC-07 | PASS |
| AC-5 | БАГ-8: провал прод-деплоя откатывает | TC-10 | PASS |
| AC-6 | Условность self-hosting сохранена | TC-08 | PASS |
| AC-7 | Kill-switch возвращает прежнее поведение | TC-09 | PASS |
| AC-8 | Контракты не сломаны (реестр/frontmatter/exit-code) | TC-11 | PASS |
| AC-9 | Схема БД не меняется | миграций нет (флаг — конфиг) | PASS |
| AC-10 | never-raise | TC-12 | PASS |
| AC-11 | Наблюдаемость (INFRA-WAIVED / waived list) | TC-14 | PASS |
| AC-12 | Безопасность self-hosting (прод 8500 не трогается) | smoke + код пути | PASS |
| AC-13 | Документация обновлена (golden source) | подтверждено в 12-review.md | PASS |
| AC-14 | Регрессионные тесты зелёные | `pytest tests/ -q` → 670 passed | PASS |
## Вывод pytest
```
$ python -m pytest tests/ -v --tb=short
...
======================= 670 passed, 1 warning in 12.15s ========================
```
Единственный warning — PydanticDeprecatedSince20 (class-based Config в `src/config.py`),
не относится к ORCH-061, существовал ранее.
## Итог
**PASS** — полный регресс зелёный (670 passed, 0 failed), все 14 TC из плана и все 14
критериев приёмки выполнены. Страховка цела (реальный регресс staging и БАГ-8
откатывают), условность self-hosting сохранена, kill-switch работает, never-raise
покрыт. Smoke API prod — 200, прод-контейнер не затронут.
Задача готова к переходу на стадию **deploy-staging**.

View File

@@ -0,0 +1,68 @@
---
staging_status: SUCCESS
timestamp: 2026-06-07T13:27:06+00:00
base_url: http://localhost:8501
---
# Staging Gate Log — ORCH-061
Staging test suite completed against the live `orchestrator-staging` stand (8501).
**Verdict: SUCCESS (exit 0)** — all REAL pipeline checks green; the two known
sandbox-infra checks (C9a/C9b) were FAILED-but-**waived** by the ORCH-061
infra-tolerance logic. This is exactly the behaviour this work item ships.
## Observability — INFRA-WAIVED
```
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
```
## Result breakdown
```
RESULT: 8/10 checks PASS
REAL failed : none
SANDBOX_INFRA failed: ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue']
tolerance: staging_infra_tolerance_enabled=True
```
| Check | Category | Result |
|-------|----------|--------|
| A1 GET /health → 200 status=ok | REAL | PASS |
| A2 GET /queue → 200 counts/max_concurrency/resilience | REAL | PASS |
| A3 ORCH_STAGING=true (not prod) | REAL | PASS |
| B4 Plane: sandbox project accessible | REAL | PASS |
| B5 Gitea: orchestrator-sandbox accessible, push=true | REAL | PASS |
| B6 Registry: sandbox present, prod ET/ORCH absent | REAL | PASS |
| C7 Create issue in Plane SANDBOX | REAL | PASS |
| C8 Trigger pipeline via /webhook/plane | REAL | PASS |
| C9a Branch appears in orchestrator-sandbox | SANDBOX_INFRA | FAIL (waived) |
| C9b Analyst job enqueued in staging queue | SANDBOX_INFRA | FAIL (waived) |
C9a/C9b fail because the SANDBOX bot accounts are not yet members of the Plane
sandbox project, so steps 6+ of the pipeline are unreachable **in the sandbox**
an infrastructure limitation, not a pipeline regression (see
`docs/operations/STAGING_CHECK.md`). All REAL checks (incl. C7/C8) are green, so
the waiver applies and the gate advances.
## Run note (self-hosting bootstrap)
The canonical bind-mounted script path (`/repos/orchestrator/scripts/staging_check.py`)
and the running `orchestrator-staging` image both predate ORCH-061 (no
`src/staging_verdict.py`, tolerance flag absent), because ORCH-061 modifies the
staging gate itself. To produce a faithful verdict for the **validated commit**,
the gate was executed from the validated worktree inside the staging container:
```
docker exec orchestrator-staging \
env PYTHONPATH=<worktree>:/app \
python3 <worktree>/scripts/staging_check.py \
--base-url http://localhost:8501 --mode stub
```
`PYTHONPATH=<worktree>:/app` keeps B6's registry read sourced from the running
staging instance's own env (sandbox-only registry — ORCH-048/ADR-001), while
loading the shipped `staging_verdict` logic and `staging_infra_tolerance_enabled`
config. This exercises the live staging endpoints AND the exact verdict logic
being shipped. EXEC EXIT CODE: 0.

View File

@@ -51,6 +51,46 @@ import datetime
import urllib.request
import urllib.error
import urllib.parse
from collections import namedtuple
# ---------------------------------------------------------------------------
# ORCH-061: pure staging-verdict logic (classification + infra-tolerant verdict).
# Imported from src.staging_verdict — a stdlib-only leaf, safe to import inside
# the orchestrator-staging container (PYTHONPATH=/app, pattern B6 / ORCH-048).
# Guarded so the suite still runs (in strict mode) if src is somehow unimportable
# from a host invocation; the fallback NEVER yields a silent green (fail-closed).
# ---------------------------------------------------------------------------
try:
from src.staging_verdict import ( # type: ignore
classify_check as _classify_check,
compute_staging_verdict as _compute_staging_verdict,
REAL as _REAL,
SANDBOX_INFRA as _SANDBOX_INFRA,
)
except Exception: # pragma: no cover - exercised only on a broken host import
_classify_check = None
_compute_staging_verdict = None
_REAL = "real"
_SANDBOX_INFRA = "sandbox_infra"
_FallbackVerdict = namedtuple("StagingVerdict", "status exit_code waived summary")
def _classify(label: str) -> str:
"""Classify a check label via staging_verdict; fail-closed to REAL if absent."""
if _classify_check is not None:
return _classify_check(label)
return _REAL
def _verdict(items, infra_tolerant: bool):
"""Compute the suite verdict via staging_verdict; strict fail-closed fallback."""
if _compute_staging_verdict is not None:
return _compute_staging_verdict(items, infra_tolerant)
failed = [lbl for (lbl, ok, _cat) in items if not ok]
if failed:
return _FallbackVerdict("FAILED", 1, [], f"FAILED (strict fallback): {failed}")
return _FallbackVerdict("SUCCESS", 0, [], "SUCCESS (strict fallback): all green")
# ---------------------------------------------------------------------------
# Colour helpers
@@ -152,23 +192,47 @@ def _sign_payload(secret: str, body: bytes) -> str:
class Results:
def __init__(self):
# _items keeps the (label, passed, detail) 3-tuple shape that existing
# ORCH-048 B6 tests unpack — categories live in a PARALLEL list so the
# public tuple contract is unchanged.
self._items: list[tuple[str, bool, str]] = [] # (label, passed, detail)
self._categories: list[str] = [] # ORCH-061: REAL | SANDBOX_INFRA
def add(self, label: str, passed: bool, detail: str = ""):
def add(self, label: str, passed: bool, detail: str = "", category: str | None = None):
# ORCH-061: every check carries a category. None -> auto-classify by label
# (C9a/C9b -> SANDBOX_INFRA, everything else -> REAL). Fail-closed: an
# unknown label is REAL, so it still counts toward the safety net.
if category is None:
category = _classify(label)
self._items.append((label, passed, detail))
self._categories.append(category)
line = _ok(label) if passed else _fail(label)
if detail:
line += f" [{detail}]"
print(line)
def categorized_items(self) -> list[tuple[str, bool, str]]:
"""Rows as ``(label, passed, category)`` for ``compute_staging_verdict``."""
return [
(label, passed, cat)
for (label, passed, _detail), cat in zip(self._items, self._categories)
]
def summary(self) -> bool:
passed = sum(1 for _, ok, _ in self._items if ok)
total = len(self._items)
all_ok = passed == total
colour = _GREEN if all_ok else _RED
# ORCH-061: per-category breakdown so an operator can tell a REAL failure
# (regression — fail-closed) from a SANDBOX_INFRA one (waivable).
rows = self.categorized_items()
real_fail = [lbl for lbl, ok, cat in rows if not ok and cat == _REAL]
infra_fail = [lbl for lbl, ok, cat in rows if not ok and cat == _SANDBOX_INFRA]
print()
print(f"{_BOLD}{'='*60}{_RESET}")
print(f"{colour}{_BOLD} RESULT: {passed}/{total} checks PASS{_RESET}")
print(f" REAL failed : {real_fail or 'none'}")
print(f" SANDBOX_INFRA failed: {infra_fail or 'none'}")
print(f"{_BOLD}{'='*60}{_RESET}")
return all_ok
@@ -637,6 +701,28 @@ def _cleanup(plane_base, workspace, gitea_base, plane_headers, gitea_headers,
# Main
# ---------------------------------------------------------------------------
def _resolve_tolerance(cli_strict: bool) -> bool:
"""Resolve whether the infra-FAIL waiver is active (ORCH-061).
Precedence: an explicit ``--strict`` CLI flag forces it OFF (for honest manual
runs). Otherwise read ``settings.staging_infra_tolerance_enabled`` from the
running instance's own config (same pattern as B6's src.* import inside the
container). On ANY import/read error -> STRICT (False): we never waive when the
config is unreadable (fail-safe), and we say so.
"""
if cli_strict:
print(_info("tolerance: DISABLED via --strict (honest run)"))
return False
try:
from src.config import settings # noqa: WPS433 - lazy, mirrors B6
enabled = bool(settings.staging_infra_tolerance_enabled)
print(_info(f"tolerance: staging_infra_tolerance_enabled={enabled}"))
return enabled
except Exception as e:
print(_info(f"tolerance: config unavailable, defaulting to STRICT: {e}"))
return False
def main():
parser = argparse.ArgumentParser(
description="Live staging-stand check suite (ORCH-33)"
@@ -656,6 +742,15 @@ def main():
"full-real: also wait for the analyst agent (slow, costs credits)."
),
)
parser.add_argument(
"--strict",
action="store_true",
help=(
"ORCH-061: force strict suite — disable the sandbox-infra (C9a/C9b) "
"FAIL waiver even if staging_infra_tolerance_enabled=True. Use for an "
"honest 10/10 run once the sandbox bot accounts are provisioned."
),
)
args = parser.parse_args()
base = args.base_url.rstrip("/")
@@ -673,8 +768,23 @@ def main():
block_b(results)
block_c(base, results, args.mode)
all_ok = results.summary()
sys.exit(0 if all_ok else 1)
results.summary()
# ORCH-061: the EXIT CODE (which drives the deployer's staging_status verdict)
# comes from the infra-tolerant verdict, NOT a raw passed==total count. A run
# whose only failures are known sandbox-infra checks (C9a/C9b) is waived to
# exit 0 when tolerance is on; ANY real check failure still exits 1 (FR-4).
infra_tolerant = _resolve_tolerance(args.strict)
verdict = _verdict(results.categorized_items(), infra_tolerant)
if verdict.waived:
# FR-7 observability: make "green with an allowance" distinguishable from
# an honest green in the logs / captured deployer output.
print(f"{_YELLOW}{_BOLD}INFRA-WAIVED:{_RESET} "
f"{', '.join(verdict.waived)} "
f"(known sandbox-infra; real checks green)")
print(f"{_BOLD}VERDICT:{_RESET} {verdict.status} "
f"(exit {verdict.exit_code}) — {verdict.summary}")
sys.exit(verdict.exit_code)
if __name__ == "__main__":

View File

@@ -20,6 +20,33 @@ logger = logging.getLogger("orchestrator.launcher")
# never passed through to the CLI.
VALID_EFFORTS = frozenset({"low", "medium", "high", "xhigh", "max"})
# ORCH-061: action stages whose success is an ACTION (restart/retag), not a src
# edit — so "no changes to commit" is EXPECTED there, not under-delivery (FR-3).
_ACTION_STAGES = frozenset({"deploy-staging", "deploy"})
def action_stage_no_changes_note(stage, repo) -> str | None:
"""ORCH-061 (FR-3 / FR-7): observability for an empty diff on an action stage.
The ``deploy-staging`` / ``deploy`` stages are actions (restart / retag), not
code edits, so the post-run "no changes to commit" is the NORMAL case there —
advancement is decided by the agent exit-code + the staging/deploy gate verdict,
NEVER by the presence of a commit (FR-3 / AC-4). This is a PURE decision used
only to emit an explicit log line distinguishing an expected action-stage no-op
from a code-stage no-op; it has no effect on stage advancement.
Returns an explicit note string when the empty diff is expected (an action
stage of a self-deploy repo), else ``None``. Never raises.
"""
try:
if stage in _ACTION_STAGES:
from ..self_deploy import self_deploy_applies
if self_deploy_applies(repo):
return f"{stage}: no code changes (expected on action stage)"
return None
except Exception: # noqa: BLE001 - observability only, never raise
return None
def _resolve_agent_attr(agent, project_id, project_map_attr, env_attr_prefix,
default_attr):
@@ -222,6 +249,11 @@ class AgentLauncher:
"""
if job.get("agent") == "deploy-finalizer":
return self._run_deploy_finalizer_job(job)
# ORCH-021: the reserved-agent `post-deploy-monitor` is also a
# DETERMINISTIC (no-LLM) tick — intercept it BEFORE _spawn and run one
# observation tick synchronously. Returns None (no agent_run row).
if job.get("agent") == "post-deploy-monitor":
return self._run_post_deploy_monitor_job(job)
return self._spawn(
job["agent"],
job["repo"],
@@ -251,6 +283,27 @@ class AgentLauncher:
pass
return None
def _run_post_deploy_monitor_job(self, job: dict):
"""ORCH-021: run one deterministic post-deploy monitor tick for a job.
Not an LLM spawn — there is no subprocess/monitor, so we mark the jobs row
done/failed here. The tick never-raises, but we guard anyway so a monitor
fault can never wedge the worker / starve other projects (AC-16).
"""
from ..db import mark_job
from .. import stage_engine
try:
stage_engine.run_post_deploy_monitor(job)
mark_job(job["id"], "done")
logger.info(f"post-deploy-monitor job {job['id']} done")
except Exception as e:
logger.error(f"post-deploy-monitor job {job['id']} failed: {e}")
try:
mark_job(job["id"], "failed", error=f"post-deploy-monitor error: {e}")
except Exception:
pass
return None
def _spawn(self, agent: str, repo: str, task_content: str = None,
task_id: int = None, job_id: int = None) -> int:
"""Shared spawn implementation for launch() and launch_job().
@@ -582,6 +635,22 @@ class AgentLauncher:
logger.warning(f"Agent run_id={run_id}: commit failed: {commit_result.stderr}")
else:
logger.info(f"Agent run_id={run_id}: no changes to commit")
# ORCH-061: on a self-deploy action stage (deploy-staging/deploy)
# an empty diff is EXPECTED (action, not a src edit). Emit an
# explicit observability line so an operator can tell this apart
# from a code-stage no-op. Does NOT affect advancement (decided by
# exit-code + gate verdict, never by a commit existing).
try:
_t = get_task_by_repo_branch(repo, branch)
_stage = _t["stage"] if _t else None
_note = action_stage_no_changes_note(_stage, repo)
if _note:
logger.info(f"Agent run_id={run_id}: {_note}")
except Exception as _e:
logger.debug(
f"Agent run_id={run_id}: action-stage no-changes note "
f"skipped: {_e}"
)
except Exception as e:
logger.error(f"Agent run_id={run_id}: post-run git failed: {e}")

View File

@@ -219,6 +219,22 @@ class Settings(BaseSettings):
image_freshness_enabled: bool = True
image_freshness_repos: str = ""
# ORCH-061: tolerate KNOWN sandbox-infra FAILs (C9a/C9b) in the staging suite.
# The self-hosting deploy-staging stage looped because scripts/staging_check.py
# exited non-zero on ANY failed check, so two infra-only failures (sandbox bot
# accounts not members of the sandbox Plane project) produced staging_status:
# FAILED -> rollback deploy-staging -> development -> loop.
# True -> a run whose ONLY failures are allowlisted sandbox-infra checks
# (C9a/C9b) is waived to SUCCESS; ANY real pipeline check that fails
# still fails closed -> FAILED -> rollback (safety net intact, FR-4).
# False -> 1:1 pre-ORCH-061 strict behaviour: any FAIL -> FAILED -> rollback.
# Default True (mirrors merge_gate_enabled / image_freshness_enabled /
# self_deploy_enabled): the safety net holds regardless of the flag; the flag
# exists to instantly restore legacy strictness without a code redeploy. Lives
# in .env.staging (ORCH_ prefix) so it is reachable inside orchestrator-staging.
# Env ORCH_STAGING_INFRA_TOLERANCE_ENABLED.
staging_infra_tolerance_enabled: bool = True
# ORCH-053: stuck-task reconciler (sweeper for lost webhooks). A background
# daemon thread reconciles the "source of truth (gate / Plane) != task stage"
# drift left behind by a dropped webhook (502 on rebuild, no Plane/Gitea
@@ -234,12 +250,51 @@ class Settings(BaseSettings):
# JSON -> default (mirrors agent_timeout_overrides_json).
# reconcile_notify_unblock -> send a Telegram message when a stuck task is
# unblocked (F-4 observability).
# reconcile_skip_blocked_enabled -> ORCH-060 Guard 2: skip F-1 reconciliation of
# issues a human moved to Blocked / Needs Input
# (per-candidate Plane state lookup). Disabling it
# mutes ONLY the networked Guard 2; Guard 1
# (escalated-by-retries, local + deterministic) is
# always active. Manual escape hatch during a Plane
# outage.
reconcile_enabled: bool = True
reconcile_interval_s: int = 120
reconcile_plane_enabled: bool = True
reconcile_grace_default_s: int = 600
reconcile_grace_overrides_json: str = ""
reconcile_notify_unblock: bool = True
reconcile_skip_blocked_enabled: bool = True
# ORCH-021: post-deploy production monitoring + degradation reaction. After
# the terminal deploy->done transition for an applicable repo, a reserved-agent
# `post-deploy-monitor` job (no LLM, modelled on deploy-finalizer) probes prod
# over a window and reacts to a degradation the restart-time health-check
# missed (class "green deploy, red prod", precedent ET-8). State is in sentinel
# files (.post-deploy-state-<repo>/<wi>/), no DB migration. See
# docs/architecture/adr/adr-0010-post-deploy-monitor.md.
# post_deploy_monitor_enabled -> global kill-switch (BR-8); False -> the
# pipeline is 1:1 as before ORCH-021 (no arm).
# post_deploy_repos -> CSV of repos where monitoring is REAL; empty
# -> only the self-hosting repo (orchestrator).
# Mirrors self_deploy_repos / merge_gate_repos.
# post_deploy_window_s -> observation window length (~15 min, BR-1).
# post_deploy_interval_s -> seconds between probe ticks.
# post_deploy_fail_threshold -> N CONSECUTIVE health failures -> DEGRADED.
# post_deploy_5xx_threshold -> window 5xx ratio above this -> DEGRADED.
# post_deploy_auto_rollback -> globally allow auto-rollback; True acts ONLY
# for non-self repos. For self-hosting the
# reaction is ALWAYS ALERT_ONLY (BR-5) — a tick
# NEVER restarts the prod orchestrator container.
# post_deploy_base_url -> base URL of the observed prod instance.
# Rollback target params reuse the existing deploy_prod_* settings (no dupes).
post_deploy_monitor_enabled: bool = True
post_deploy_repos: str = ""
post_deploy_window_s: int = 900
post_deploy_interval_s: int = 30
post_deploy_fail_threshold: int = 3
post_deploy_5xx_threshold: float = 0.5
post_deploy_auto_rollback: bool = False
post_deploy_base_url: str = "http://localhost:8500"
# Telegram notifications
telegram_bot_token: str = ""

View File

@@ -123,11 +123,13 @@ async def queue():
from .db import job_status_counts, recent_jobs
from .queue_worker import worker
from .reconciler import reconciler
from . import post_deploy
return {
"counts": job_status_counts(),
"max_concurrency": worker.max_concurrency,
"poll_interval": worker.poll_interval,
"resilience": worker.status(),
"reconcile": reconciler.status(),
"post_deploy": post_deploy.status(),
"recent": recent_jobs(10),
}

View File

@@ -278,6 +278,33 @@ def fetch_issue_sequence_id(issue_id: str, project_id: str) -> int | None:
return None
def fetch_issue_state(issue_id: str, project_id: str) -> str | None:
"""ORCH-060 (F-1 Guard 2): GET the Plane issue and return its current state uuid.
Used by the reconciler to honour an explicit human gate: an issue a person
moved to **Blocked** / **Needs Input** must not be auto-unblocked by the
sweeper. Reuses the exact GET issue-detail endpoint / shared token already
used by ``fetch_issue_sequence_id`` / ``fetch_issue_fields``.
Plane returns ``state`` as a bare uuid string; older shapes may nest it as a
``{"id": ...}`` dict — both are handled.
Returns None on network error, non-2xx, or a missing field — never raises, so
the caller can apply its conservative fallback (treat as "possibly blocked").
"""
url = f"{PLANE_BASE}/workspaces/{WORKSPACE}/projects/{project_id}/issues/{issue_id}/"
try:
resp = httpx.get(url, headers=PLANE_HEADERS, timeout=10)
resp.raise_for_status()
state = resp.json().get("state")
if isinstance(state, dict):
state = state.get("id")
return str(state) if state else None
except Exception as e:
logger.warning(f"fetch_issue_state failed for {issue_id}: {e}")
return None
import re as _re

614
src/post_deploy.py Normal file
View File

@@ -0,0 +1,614 @@
"""Post-deploy production monitoring + degradation reaction (ORCH-021).
The pipeline used to end at ``deploy -> done`` and then **forget about prod**:
"success" meant the health-check passed at restart (~60s window in
``scripts/orchestrator-deploy-hook.sh``). The class of incidents "green deploy,
red prod" (precedent ET-8 — degradation appears minutes later under real
traffic; ``/health`` answers ``200 ok`` while the feature is broken) was never
caught. ORCH-021 extends responsibility **PAST** ``done``: after the terminal
transition for an applicable repo we arm an observation window
(``post_deploy_window_s`` ~15 min, interval ``post_deploy_interval_s``);
degradation is detected by deterministic thresholds and, when confirmed,
triggers a reaction.
The observation mechanism (ADR-001 §1, Variant B) is a **reserved-agent job**
``post-deploy-monitor`` — a deterministic, no-LLM job modelled exactly on
``deploy-finalizer``. One "tick" == one job: it does ONE probe, appends to a
persisted ``series`` file, classifies, and either re-queues itself with a delay
(``available_at_delay_s``) or finishes (DEGRADED -> reaction; or window expired
-> HEALTHY). Between ticks no job runs (it is scheduled in the future), so the
single worker stays free for other projects — exactly like the finalizer defer.
This module is a **leaf** (mirrors ``self_deploy.py`` / ``staging_verdict.py``):
it imports only config (and lazily ``qg.checks.is_self_hosting_repo``), never
``stage_engine`` / ``launcher`` — the orchestration that needs those lives in
``stage_engine.run_post_deploy_monitor``. Every public helper honours a
**never-raise** contract so a monitoring hiccup can never crash the worker /
lifespan / the pipeline of other projects (AC-16).
Restart-safe state lives in sentinel files under
``<repos_dir>/.post-deploy-state-<repo>/<work_item_id>/`` (mirrors the
deploy-state pattern, no DB migration — ТЗ §2.7):
* ``armed`` — monitoring armed for this work item (idempotency-guard, AC-15);
* ``series`` — JSON list of probe results (restart-safe streak/5xx counters);
* ``done`` — monitoring finished (anti-dupe, AC-15).
Self-hosting safety (BR-5 / AC-8): a monitor tick NEVER auto-rolls-back or
restarts the prod ``orchestrator`` container — for ``orchestrator`` the reaction
is ALWAYS ``ALERT_ONLY`` (loud Telegram + Plane, manual approve).
"""
from __future__ import annotations
import glob
import json
import logging
import os
import shlex
import subprocess
import urllib.error
import urllib.request
from dataclasses import dataclass
from .config import settings
logger = logging.getLogger("orchestrator.post_deploy")
# Sentinel marker filenames (see module docstring).
ARMED = "armed"
SERIES = "series"
DONE = "done"
# Verdicts (classify).
HEALTHY = "HEALTHY"
DEGRADED = "DEGRADED"
# Reaction decisions (decide_action).
NONE = "NONE"
ROLLBACK = "ROLLBACK"
ALERT_ONLY = "ALERT_ONLY"
# action_taken values written to the artefact frontmatter.
ROLLBACK_OK = "ROLLBACK_OK"
ROLLBACK_FAILED = "ROLLBACK_FAILED"
# The 5xx-monitored endpoints (besides /health, whose 200+ok is its own signal).
_FIVEXX_ENDPOINTS = ("/status", "/queue")
_PROBE_TIMEOUT = 5
_SSH_TIMEOUT = 60
_GIT_TIMEOUT = 60
# ---------------------------------------------------------------------------
# Conditionality (mirrors self_deploy_applies / _merge_gate_applies)
# ---------------------------------------------------------------------------
def post_deploy_applies(repo: str) -> bool:
"""Whether post-deploy monitoring is REAL for this repo (AC-2 / AC-10).
Mirrors the ORCH-35/36/43/58 conditional rollout:
* ``post_deploy_monitor_enabled=False`` -> always False (global
kill-switch); the pipeline is 1:1 as before ORCH-021 (AC-10).
* ``post_deploy_repos`` (CSV) non-empty -> real only for listed repos.
* empty CSV -> real ONLY for the self-hosting repo (``orchestrator``).
Never raises.
"""
try:
if not settings.post_deploy_monitor_enabled:
return False
raw = (settings.post_deploy_repos or "").strip()
if raw:
allowed = {r.strip().lower() for r in raw.split(",") if r.strip()}
return (repo or "").strip().lower() in allowed
# Lazy import keeps this module a leaf (avoid importing qg at load time).
from .qg.checks import is_self_hosting_repo
return is_self_hosting_repo(repo)
except Exception as e: # noqa: BLE001 - never-raise contract
logger.warning("post_deploy_applies error for %s: %s", repo, e)
return False
# ---------------------------------------------------------------------------
# Signal probe (one tick)
# ---------------------------------------------------------------------------
@dataclass
class ProbeResult:
"""Outcome of ONE probe tick (JSON-serialisable via ``as_dict``).
``health_ok`` — ``/health`` answered HTTP 200 with ``{"status": "ok"}``.
``total`` — number of 5xx-monitored endpoints probed (``/status``,
``/queue``) — the denominator of the window 5xx ratio.
``fivexx`` — how many of those returned 5xx (or were unreachable, which
is conservatively counted as a server failure).
``detail`` — human-readable note (logs / artefact body).
"""
health_ok: bool
total: int
fivexx: int
detail: str = ""
def as_dict(self) -> dict:
return {
"health_ok": bool(self.health_ok),
"total": int(self.total),
"fivexx": int(self.fivexx),
"detail": str(self.detail),
}
def _http_status(url: str) -> tuple[int, str]:
"""GET ``url`` -> (http_code, body). Network/timeout -> (0, "").
Never raises. ``urllib`` raises ``HTTPError`` for >=400 responses; we treat
that as a real status code (so a 5xx is observed, not swallowed).
"""
try:
with urllib.request.urlopen(url, timeout=_PROBE_TIMEOUT) as resp: # noqa: S310
body = resp.read(4096).decode("utf-8", "replace")
return int(getattr(resp, "status", resp.getcode())), body
except urllib.error.HTTPError as e:
try:
body = e.read(4096).decode("utf-8", "replace")
except Exception:
body = ""
return int(e.code), body
except Exception as e: # noqa: BLE001 - URLError / socket timeout / anything
logger.warning("post_deploy probe error for %s: %s", url, e)
return 0, ""
def probe_signals(base_url: str) -> ProbeResult:
"""Probe ``/health`` + the key endpoints of the prod instance ONCE (AC-16).
``/health`` is healthy iff HTTP 200 AND the body parses to
``{"status": "ok"}``. ``/status`` and ``/queue`` contribute to the window
5xx ratio: an HTTP 5xx OR an unreachable endpoint (network error / timeout,
code 0) is counted as a failure (conservative — a down server is bad). A
network failure yields a conservative "failed" probe, NEVER an exception
(TC-14).
"""
base = (base_url or "").rstrip("/")
# --- /health: the primary liveness signal ---
code, body = _http_status(base + "/health")
health_ok = False
if code == 200:
try:
health_ok = json.loads(body).get("status") == "ok"
except Exception:
health_ok = False
# --- /status, /queue: 5xx ratio over the window ---
total = 0
fivexx = 0
for ep in _FIVEXX_ENDPOINTS:
total += 1
ep_code, _ = _http_status(base + ep)
if ep_code == 0 or 500 <= ep_code <= 599:
fivexx += 1
detail = f"health={code}({'ok' if health_ok else 'bad'}) 5xx={fivexx}/{total}"
return ProbeResult(health_ok=health_ok, total=total, fivexx=fivexx, detail=detail)
# ---------------------------------------------------------------------------
# Classification (pure, no I/O — the MAIN unit-test subject, like
# compute_staging_verdict in ORCH-061)
# ---------------------------------------------------------------------------
def classify(series, fail_threshold: int, fivexx_threshold: float) -> str:
"""Fold a probe series into ``HEALTHY`` | ``DEGRADED`` (deterministic, pure).
``series`` — iterable of probe dicts (``{"health_ok", "total", "fivexx"}``),
as persisted by :func:`append_probe`.
Decision (BR-3 / AC-3..AC-6):
* ``>= fail_threshold`` CONSECUTIVE health failures -> ``DEGRADED`` (AC-4);
* window 5xx ratio ``sum(fivexx)/sum(total)`` strictly ``> fivexx_threshold``
-> ``DEGRADED`` even if ``/health`` answers 200 (AC-5);
* otherwise ``HEALTHY`` — a single glitch below the threshold that recovers
does NOT trip (AC-3 / AC-6, no false rollback).
Never raises: on malformed input it returns ``HEALTHY`` (fail-SAFE — a false
``DEGRADED`` would trigger an unwanted rollback, the worse outcome).
"""
try:
# Non-list input is malformed -> fail-safe HEALTHY (never a false rollback).
if not isinstance(series, (list, tuple)):
return HEALTHY
# Longest run of consecutive health failures.
streak = 0
best = 0
total = 0
fivexx = 0
for row in series:
# A non-dict row is malformed: skip it (do NOT count it as a failure,
# which could fabricate a DEGRADED streak from garbage).
if not isinstance(row, dict):
continue
ok = bool(row.get("health_ok"))
total += int(row.get("total") or 0)
fivexx += int(row.get("fivexx") or 0)
if ok:
streak = 0
else:
streak += 1
if streak > best:
best = streak
if best >= int(fail_threshold):
return DEGRADED
if total > 0 and (fivexx / total) > float(fivexx_threshold):
return DEGRADED
return HEALTHY
except Exception as e: # noqa: BLE001 - never-raise; fail-safe to HEALTHY
logger.warning("post_deploy classify error: %s", e)
return HEALTHY
def decide_action(repo: str, verdict: str) -> str:
"""Decide the reaction for ``(repo, verdict)`` (pure, BR-5 / AC-7 / AC-8).
* ``HEALTHY`` -> ``NONE`` (no reaction, any repo);
* ``DEGRADED`` + self-hosting -> ``ALERT_ONLY`` (ALWAYS — the tick
NEVER auto-rolls-back / restarts the prod orchestrator container, AC-8);
* ``DEGRADED`` + non-self + ``post_deploy_auto_rollback=True`` -> ``ROLLBACK``;
* ``DEGRADED`` + non-self + auto_rollback False (default) -> ``ALERT_ONLY``.
Never raises: on doubt returns ``ALERT_ONLY`` (never an unexpected rollback).
"""
try:
if verdict != DEGRADED:
return NONE
from .qg.checks import is_self_hosting_repo
if is_self_hosting_repo(repo):
return ALERT_ONLY # BR-5: self-hosting is NEVER auto-rolled-back
if settings.post_deploy_auto_rollback:
return ROLLBACK
return ALERT_ONLY
except Exception as e: # noqa: BLE001 - never-raise; safe default
logger.warning("post_deploy decide_action error for %s: %s", repo, e)
return ALERT_ONLY
def map_rollback_exit_code(exit_code) -> str:
"""Map a ``--rollback`` hook exit-code to an ``action_taken`` (pure, AC-9).
Hook exit-code contract (unchanged, 0/1/2):
* ``0`` -> ``ROLLBACK_OK`` (rollback proven healthy);
* ``1`` (no prev image), ``2`` (rollback also failed), anything else, or a
non-int/None -> ``ROLLBACK_FAILED`` (fail-closed -> loud escalation).
"""
try:
code = int(exit_code)
except (TypeError, ValueError):
return ROLLBACK_FAILED
return ROLLBACK_OK if code == 0 else ROLLBACK_FAILED
# ---------------------------------------------------------------------------
# Sentinel state (restart-safe, no DB migration — ТЗ §2.7)
# ---------------------------------------------------------------------------
def _state_dir(base: str, repo: str, work_item_id: str | None) -> str:
return os.path.join(base, f".post-deploy-state-{repo}", (work_item_id or "_"))
def state_dir(repo: str, work_item_id: str | None) -> str:
"""State dir as seen from the container (``settings.repos_dir`` mount)."""
return _state_dir(settings.repos_dir, repo, work_item_id)
def host_state_dir(repo: str, work_item_id: str | None) -> str:
"""State dir as seen from the HOST (``settings.host_repos_dir``).
Same physical directory as :func:`state_dir` via the shared mount; the host
path is what we embed in an ssh command if a host-side helper needs it.
"""
return _state_dir(settings.host_repos_dir, repo, work_item_id)
def marker_path(repo: str, work_item_id: str | None, name: str) -> str:
return os.path.join(state_dir(repo, work_item_id), name)
def has_marker(repo: str, work_item_id: str | None, name: str) -> bool:
"""True iff the named sentinel exists. Never raises."""
try:
return os.path.isfile(marker_path(repo, work_item_id, name))
except Exception as e: # noqa: BLE001 - never-raise
logger.warning("has_marker error for %s/%s/%s: %s", repo, work_item_id, name, e)
return False
def write_marker(repo: str, work_item_id: str | None, name: str, content: str = "") -> bool:
"""Create/overwrite a sentinel (best-effort). Returns True on success."""
try:
d = state_dir(repo, work_item_id)
os.makedirs(d, exist_ok=True)
with open(os.path.join(d, name), "w", encoding="utf-8") as f:
f.write(str(content))
return True
except OSError as e:
logger.warning("write_marker error for %s/%s/%s: %s", repo, work_item_id, name, e)
return False
def mark_done(repo: str, work_item_id: str | None) -> bool:
"""Mark monitoring finished for this work item (anti-dupe, AC-15)."""
return write_marker(repo, work_item_id, DONE, "done")
def read_series(repo: str, work_item_id: str | None) -> list:
"""Read the persisted probe series (JSON list). Missing/corrupt -> ``[]``.
Never raises — restart-safe streak/5xx counters survive a container restart.
"""
p = marker_path(repo, work_item_id, SERIES)
try:
with open(p, "r", encoding="utf-8") as f:
data = json.load(f)
return data if isinstance(data, list) else []
except FileNotFoundError:
return []
except Exception as e: # noqa: BLE001 - never-raise; corrupt -> empty
logger.warning("read_series error for %s/%s: %s", repo, work_item_id, e)
return []
def append_probe(repo: str, work_item_id: str | None, probe: ProbeResult) -> list:
"""Append a probe to the persisted series and return the new list.
Best-effort (a write error logs and returns the in-memory list so the tick
still classifies). Never raises.
"""
series = read_series(repo, work_item_id)
try:
series.append(probe.as_dict() if isinstance(probe, ProbeResult) else dict(probe))
except Exception as e: # noqa: BLE001
logger.warning("append_probe coerce error for %s/%s: %s", repo, work_item_id, e)
return series
try:
d = state_dir(repo, work_item_id)
os.makedirs(d, exist_ok=True)
with open(os.path.join(d, SERIES), "w", encoding="utf-8") as f:
json.dump(series, f)
except OSError as e:
logger.warning("append_probe write error for %s/%s: %s", repo, work_item_id, e)
return series
def arm_monitor(repo: str, work_item_id: str | None, branch: str, task_id: int) -> bool:
"""Arm post-deploy monitoring after ``deploy -> done`` (AC-1 / AC-15).
Idempotent: if the ``armed`` sentinel already exists this is a no-op (a double
webhook / reconciler F-1 / finalizer Phase C can drive ``done`` more than once,
AC-15). Otherwise creates the state dir, writes ``armed`` + an empty ``series``,
and enqueues the FIRST ``post-deploy-monitor`` job with a delay of one interval
(so the prod has settled before the first probe). Returns True iff it armed a
NEW monitor. Never raises — the caller (terminal block of ``advance_stage``)
must never be crashed by a monitoring hiccup.
"""
try:
if has_marker(repo, work_item_id, ARMED):
logger.info("arm_monitor: already armed for %s/%s (no-op)", repo, work_item_id)
return False
write_marker(repo, work_item_id, ARMED, "armed")
# Initialise an empty series so read_series is well-defined from tick 1.
try:
d = state_dir(repo, work_item_id)
os.makedirs(d, exist_ok=True)
with open(os.path.join(d, SERIES), "w", encoding="utf-8") as f:
json.dump([], f)
except OSError as e:
logger.warning("arm_monitor: series init error for %s/%s: %s", repo, work_item_id, e)
# Lazy import keeps this module a leaf (db is a low-level dependency).
from .db import enqueue_job
task_desc = (
f"Work item: {work_item_id}\nRepo: {repo}\nBranch: {branch}\n"
f"Stage: post-deploy\nNote: post-deploy monitor tick 1 "
f"(window {settings.post_deploy_window_s}s, interval "
f"{settings.post_deploy_interval_s}s)."
)
job_id = enqueue_job(
"post-deploy-monitor", repo, task_desc, task_id=task_id,
available_at_delay_s=settings.post_deploy_interval_s,
)
logger.info(
"arm_monitor: armed post-deploy monitor for %s/%s (job_id=%s)",
repo, work_item_id, job_id,
)
return True
except Exception as e: # noqa: BLE001 - never-raise contract
logger.error("arm_monitor error for %s/%s: %s", repo, work_item_id, e)
return False
def max_ticks() -> int:
"""Bounded tick budget for the window (anti-livelock, like
``deploy_finalize_max_attempts``): ``window_s // interval_s`` (>= 1)."""
try:
interval = max(1, int(settings.post_deploy_interval_s))
return max(1, int(settings.post_deploy_window_s) // interval)
except Exception: # noqa: BLE001 - never-raise
return 1
# ---------------------------------------------------------------------------
# Rollback command (non-self repos only; reuses deploy_prod_* env — ТЗ §2.4)
# ---------------------------------------------------------------------------
def build_rollback_command(repo: str) -> list[str]:
"""Build the ssh argv that runs the deploy hook in ``--rollback`` mode.
Mirrors ``self_deploy.build_deploy_command`` (same prod-env, INFRA P-2 ssh
target) but the action is ``--rollback`` and the call is SYNCHRONOUS (the
target container is NOT the orchestrator, so it is safe to wait for the hook
exit-code directly — no detached setsid wrapper, no ``result`` sentinel).
Reuses the existing ``deploy_prod_*`` settings; no new duplicate config.
"""
env_assignments = (
f"TARGET_SERVICE={shlex.quote(settings.deploy_prod_target_service)} "
f"TARGET_PORT={int(settings.deploy_prod_target_port)} "
f"TARGET_IMAGE={shlex.quote(settings.deploy_prod_target_image)} "
f"COMPOSE_PROFILE={shlex.quote(settings.deploy_prod_compose_profile)} "
f"PREV_IMAGE_FILE={shlex.quote(settings.deploy_prod_prev_image_file)}"
)
inner = (
f"cd {shlex.quote(settings.deploy_host_repo_path)} && "
f"{env_assignments} "
f"bash {shlex.quote(settings.deploy_hook_script)} --rollback"
)
user = (settings.deploy_ssh_user or "").strip()
host = (settings.deploy_ssh_host or "").strip()
target = f"{user}@{host}" if user else host
return ["ssh", "-o", "StrictHostKeyChecking=no", target, inner]
def run_rollback(repo: str) -> tuple[int, str]:
"""Run the ``--rollback`` hook synchronously. Returns ``(exit_code, detail)``.
Never raises: an ssh launch error / timeout maps to a non-zero exit-code so
the caller records ``ROLLBACK_FAILED`` and escalates (AC-9). NEVER used for
the self-hosting repo (``decide_action`` returns ``ALERT_ONLY`` there) — the
structural guard against a tick restarting the prod orchestrator (AC-8).
"""
cmd = build_rollback_command(repo)
try:
r = subprocess.run(cmd, capture_output=True, text=True, timeout=_SSH_TIMEOUT)
except subprocess.TimeoutExpired:
return 2, "rollback ssh timeout"
except (subprocess.SubprocessError, OSError) as e:
return 2, f"rollback ssh error: {e}"
detail = ((r.stderr or "") + (r.stdout or "")).strip()[:200]
return int(r.returncode), detail
# ---------------------------------------------------------------------------
# Artefact 16-post-deploy-log.md (machine-readable frontmatter — ТЗ §2.5)
# ---------------------------------------------------------------------------
def build_post_deploy_log(
work_item_id: str,
status: str,
action_taken: str,
window_s: int,
checks_total: int,
checks_failed: int,
body_extra: str = "",
) -> str:
"""Render a 16-post-deploy-log.md body. Only the YAML-frontmatter is machine
read (canon of gates; the loop-of-lessons ORCH-8 consumes it, BR-10). The
body is informational. Parseable by ``yaml.safe_load`` (AC-13).
"""
return (
"---\n"
f"post_deploy_status: {status}\n"
f"action_taken: {action_taken}\n"
f"work_item: {work_item_id}\n"
f"window_s: {int(window_s)}\n"
f"checks_total: {int(checks_total)}\n"
f"checks_failed: {int(checks_failed)}\n"
"---\n\n"
"# Post-deploy log — ORCH-021 post-deploy monitor\n\n"
f"Наблюдение прода завершено: `post_deploy_status: {status}`, "
f"`action_taken: {action_taken}`.\n\n"
f"Окно наблюдения: {int(window_s)}s; опросов всего: {int(checks_total)}, "
f"из них с провалом: {int(checks_failed)}.\n"
f"{body_extra}"
)
def write_post_deploy_log(
repo: str,
work_item_id: str,
branch: str,
status: str,
action_taken: str,
window_s: int,
checks_total: int,
checks_failed: int,
body_extra: str = "",
) -> bool:
"""Write 16-post-deploy-log.md into the task worktree and best-effort
commit+push it. Returns True iff the file was written. Never raises — the
artefact is best-effort, its absence rolls nothing back (AC-13 / TC-15).
"""
from .git_worktree import get_worktree_path
rel = f"docs/work-items/{work_item_id}/16-post-deploy-log.md"
try:
wt = get_worktree_path(repo, branch)
except Exception as e: # noqa: BLE001 - never-raise
logger.error("write_post_deploy_log: worktree error for %s/%s: %s", repo, branch, e)
return False
path = os.path.join(wt, rel)
content = build_post_deploy_log(
work_item_id, status, action_taken, window_s, checks_total, checks_failed, body_extra
)
try:
os.makedirs(os.path.dirname(path), exist_ok=True)
with open(path, "w", encoding="utf-8") as f:
f.write(content)
except OSError as e:
logger.error("write_post_deploy_log: write error at %s: %s", path, e)
return False
git_env = {
**os.environ,
"HOME": "/home/slin",
"GIT_AUTHOR_NAME": "post-deploy-monitor",
"GIT_AUTHOR_EMAIL": "post-deploy-monitor@mva154.local",
"GIT_COMMITTER_NAME": "post-deploy-monitor",
"GIT_COMMITTER_EMAIL": "post-deploy-monitor@mva154.local",
}
try:
subprocess.run(["git", "-C", wt, "add", rel],
capture_output=True, timeout=_GIT_TIMEOUT, env=git_env)
commit = subprocess.run(
["git", "-C", wt, "commit", "-m",
f"docs(ORCH-021): post-deploy {status}/{action_taken} for {work_item_id}"],
capture_output=True, text=True, timeout=_GIT_TIMEOUT, env=git_env,
)
if commit.returncode == 0:
subprocess.run(["git", "-C", wt, "push", "origin", branch],
capture_output=True, timeout=_GIT_TIMEOUT, env=git_env)
except (subprocess.SubprocessError, OSError) as e:
logger.warning("write_post_deploy_log: git commit/push best-effort failed: %s", e)
return True
# ---------------------------------------------------------------------------
# Observability snapshot for GET /queue (BR-9 / AC-14)
# ---------------------------------------------------------------------------
def status() -> dict:
"""Post-deploy snapshot for /queue observability. Never raises.
``active`` — work items with an ``armed`` sentinel but no ``done`` yet (a
monitoring window in flight). ``last_outcome`` — best-effort last finished
window read from the most-recent ``done`` state dir's series length.
"""
snap = {
"enabled": False,
"window_s": None,
"interval_s": None,
"repos": "",
"active": [],
"active_count": 0,
}
try:
snap["enabled"] = bool(settings.post_deploy_monitor_enabled)
snap["window_s"] = int(settings.post_deploy_window_s)
snap["interval_s"] = int(settings.post_deploy_interval_s)
snap["repos"] = settings.post_deploy_repos or ""
pattern = os.path.join(settings.repos_dir, ".post-deploy-state-*", "*")
active: list[str] = []
for d in glob.glob(pattern):
try:
if not os.path.isdir(d):
continue
if os.path.isfile(os.path.join(d, ARMED)) and not os.path.isfile(
os.path.join(d, DONE)
):
active.append(os.path.basename(d))
except Exception: # noqa: BLE001 - skip one dir
continue
snap["active"] = sorted(active)
snap["active_count"] = len(active)
except Exception as e: # noqa: BLE001 - never-raise
logger.warning("post_deploy status snapshot error: %s", e)
return snap

View File

@@ -19,7 +19,12 @@ handlers a webhook would use:
canonical quality gate; green -> advance through the unchanged
``stage_engine.advance_stage(..., finished_agent=None)``; red -> silence
(no advance, no notification). ``analysis`` is NOT reconciled here (human
gate; owned by F-2).
gate; owned by F-2). **ORCH-060:** before the gate is even evaluated, F-1
skips (silently) tasks that are waiting for a human — Guard 1: escalated by
developer retries (``developer_retry_count >= MAX_DEVELOPER_RETRIES``,
deterministic, local; closes the ET-013 bounce loop) checked first, then
Guard 2: an explicit Plane ``Blocked`` / ``Needs Input`` state (Variant A —
networked, never-raise -> conservative skip).
* **F-2 plane-side** (``reconcile_plane_once``): poll the Plane API per
project (``list_issues_by_state``) and replay In Progress / Approved /
@@ -49,9 +54,13 @@ from .db import (
get_task_by_plane_id,
has_active_job_for_task,
)
from .stage_engine import advance_if_gate_passed
from .stage_engine import (
advance_if_gate_passed,
developer_retry_count,
MAX_DEVELOPER_RETRIES,
)
from .stages import get_qg_for_stage
from .plane_sync import get_project_states, list_issues_by_state
from .plane_sync import fetch_issue_state, get_project_states, list_issues_by_state
from .webhooks.plane import handle_status_start, handle_verdict
from .notifications import send_telegram
from . import projects
@@ -162,6 +171,17 @@ class Reconciler:
age_s = task.get("age_s") or 0
if age_s < grace_for_stage(stage):
return
# ORCH-060 Guard 1: escalated tasks (developer retries reached the cap) are
# terminal — they wait for a human, not the sweeper. Without this, a task
# whose CI is green but whose reviewer kept sending REQUEST_CHANGES until the
# cap would be re-unblocked every tick (incident ET-013, infinite bounce).
# Deterministic, local SQL, no network — and checked FIRST (cheapest).
if developer_retry_count(task_id) >= MAX_DEVELOPER_RETRIES:
return
# ORCH-060 Guard 2: respect an explicit human gate (Blocked / Needs Input).
# Networked; runs after Guard 1 so escalated tasks never hit Plane.
if self._is_blocked_or_needs_input(task):
return
result = advance_if_gate_passed(
task_id,
stage,
@@ -172,6 +192,41 @@ class Reconciler:
if result is not None and getattr(result, "advanced", False):
self._note_unblock(task.get("work_item_id") or str(task_id), stage)
def _is_blocked_or_needs_input(self, task: dict) -> bool:
"""ORCH-060 Guard 2: is this issue in an explicit human Plane gate?
Variant A (no schema migration): resolve the task's Plane project, fetch
the issue's current state uuid and compare against the project's
``blocked`` / ``needs_input`` states. ``tasks`` has no status column, so
the live Plane state is the source of truth.
**Never-raise, conservative fallback.** Any error / unresolved project /
missing state -> return ``True`` (treat as "possibly blocked" -> skip):
NOT unblocking a task is always safe, whereas wrongly unblocking a
human-gated task re-introduces the bounce we are trying to kill. The
sub-flag ``reconcile_skip_blocked_enabled`` disables ONLY this networked
guard (escape hatch for a Plane outage); Guard 1 stays active.
"""
if not settings.reconcile_skip_blocked_enabled:
return False
try:
proj = projects.get_project_by_repo(task.get("repo") or "")
if proj is None:
return True # cannot resolve the project -> conservative skip
pid = proj.plane_project_id
states = get_project_states(pid)
issue_id = task.get("plane_id") or task.get("plane_issue_id") or ""
cur = fetch_issue_state(issue_id, pid)
if cur is None:
return True # Plane unreachable / no state -> conservative skip
return cur in {states.get("blocked"), states.get("needs_input")}
except Exception as e: # noqa: BLE001 - never break the tick
logger.warning(
f"reconciler Guard 2: blocked-check failed for task "
f"{task.get('id')}, skipping conservatively: {e}"
)
return True
# -- F-2: plane-side ---------------------------------------------------
def reconcile_plane_once(self) -> None:
"""One F-2 pass: poll Plane per project and replay missed transitions."""

View File

@@ -37,6 +37,7 @@ from .review_parse import extract_review_findings, extract_test_failures
from .qg.checks import QG_CHECKS
from . import merge_gate
from . import self_deploy
from . import post_deploy
from .notifications import (
notify_stage_change,
notify_qg_failure,
@@ -142,8 +143,14 @@ def _check_review_approved_by_branch(check_fn, repo: str, work_item_id: str, bra
return False, f"Error finding PR: {e}"
def _developer_retry_count(task_id: int) -> int:
"""How many developer runs have already happened for this task."""
def developer_retry_count(task_id: int) -> int:
"""How many developer runs have already happened for this task.
Single source of truth for the developer-retry count: the rollback path
(REQUEST_CHANGES / test-fail / merge-gate) and the ORCH-060 reconciler guard
both read the cap from here, so the SQL is never duplicated. ``task`` is
considered *escalated* once this reaches ``MAX_DEVELOPER_RETRIES``.
"""
conn = get_db()
n = conn.execute(
"SELECT COUNT(*) FROM agent_runs WHERE task_id=? AND agent='developer'",
@@ -153,6 +160,10 @@ def _developer_retry_count(task_id: int) -> int:
return n
# Backward-compat private alias — existing internal call sites keep working.
_developer_retry_count = developer_retry_count
def advance_stage(
task_id: int,
current_stage: str,
@@ -342,6 +353,17 @@ def advance_stage(
except Exception as e: # noqa: BLE001 - defensive
logger.warning(f"Task {task_id}: merge-lease release on done failed: {e}")
# ORCH-021: arm post-deploy monitoring PAST `done`. Responsibility extends
# beyond the restart-time health-check to catch the "green deploy, red prod"
# class (ET-8). Idempotent (sentinel `armed`) + conditional (applies()), so a
# double webhook / reconciler / finalizer re-driving `done` never doubles it
# and non-applicable repos are untouched. never-raise (arm_monitor + guard).
if next_stage == "done" and post_deploy.post_deploy_applies(repo):
try:
post_deploy.arm_monitor(repo, work_item_id, branch, task_id)
except Exception as e: # noqa: BLE001 - monitoring must never crash done
logger.warning(f"Task {task_id}: post-deploy arm failed: {e}")
# --- Launch the next agent (ORCH-4 fix: current_stage, not next) -----
next_agent = get_agent_for_stage(current_stage)
if next_agent:
@@ -1166,3 +1188,139 @@ def run_deploy_finalizer(job: dict):
branch=branch,
finished_agent="deployer",
)
def run_post_deploy_monitor(job: dict):
"""ORCH-021 — one post-deploy monitor tick (reserved-agent, no LLM).
A deterministic tick modelled on ``run_deploy_finalizer``: it does ONE probe
of the prod instance, appends to the persisted ``series`` (restart-safe
streak/5xx counters), classifies, and then either RE-QUEUES itself with a
delay (window not over and still HEALTHY) or FINISHES the window (DEGRADED ->
reaction; window expired -> HEALTHY). Observation happens entirely AFTER the
terminal ``done`` — it never touches ``STAGE_TRANSITIONS`` / ``QG_CHECKS`` and
never restarts the prod orchestrator container itself (AC-8 / AC-12).
never-raise into the caller (the launcher marks the job done/failed); each
branch is individually defensive.
"""
task_id = job.get("task_id")
repo = job.get("repo")
try:
conn = get_db()
row = conn.execute(
"SELECT work_item_id, branch FROM tasks WHERE id=?", (task_id,)
).fetchone()
conn.close()
except Exception as e: # noqa: BLE001 - never-raise
logger.error(f"post-deploy-monitor: db error for task_id={task_id}: {e}")
return
if not row:
logger.error(f"post-deploy-monitor: no task row for task_id={task_id}")
return
work_item_id, branch = row[0], row[1]
# AC-15: a finished window is a no-op (defends against a duplicate job).
if post_deploy.has_marker(repo, work_item_id, post_deploy.DONE):
logger.info(f"post-deploy-monitor: {work_item_id} already done (no-op)")
return
# One probe -> append -> classify (restart-safe via the persisted series).
probe = post_deploy.probe_signals(settings.post_deploy_base_url)
series = post_deploy.append_probe(repo, work_item_id, probe)
verdict = post_deploy.classify(
series,
settings.post_deploy_fail_threshold,
settings.post_deploy_5xx_threshold,
)
ticks = len(series)
budget = post_deploy.max_ticks()
logger.info(
f"post-deploy-monitor: {work_item_id} tick {ticks}/{budget} "
f"probe=[{probe.detail}] verdict={verdict}"
)
# HEALTHY and window not exhausted -> defer the next tick (worker stays free).
if verdict == post_deploy.HEALTHY and ticks < budget:
task_desc = (
f"Work item: {work_item_id}\nRepo: {repo}\nBranch: {branch}\n"
f"Stage: post-deploy\nNote: post-deploy monitor tick {ticks + 1} "
f"(healthy so far; re-poll after {settings.post_deploy_interval_s}s)."
)
enqueue_job(
"post-deploy-monitor", repo, task_desc, task_id=task_id,
available_at_delay_s=settings.post_deploy_interval_s,
)
return
checks_total = ticks
checks_failed = sum(1 for r in series if not r.get("health_ok"))
# HEALTHY and window exhausted -> clean finish (BR-6 / AC-17).
if verdict == post_deploy.HEALTHY:
post_deploy.write_post_deploy_log(
repo, work_item_id, branch, post_deploy.HEALTHY, post_deploy.NONE,
settings.post_deploy_window_s, checks_total, checks_failed,
)
post_deploy.mark_done(repo, work_item_id)
_notify_post_deploy(
work_item_id,
f"{work_item_id}: пост-деплой окно завершено чисто "
f"(HEALTHY, {checks_total} опросов).",
)
return
# DEGRADED -> decide + execute the reaction (§5), write artefact, finish.
action = post_deploy.decide_action(repo, verdict)
action_taken = post_deploy.ALERT_ONLY
if action == post_deploy.ROLLBACK:
# Non-self repo + auto policy: run the --rollback hook synchronously (the
# target is NOT the orchestrator, so its restart is safe for the pipeline).
exit_code, detail = post_deploy.run_rollback(repo)
action_taken = post_deploy.map_rollback_exit_code(exit_code)
if action_taken == post_deploy.ROLLBACK_OK:
_notify_post_deploy(
work_item_id,
f"⚠️ {work_item_id}: пост-деплой DEGRADED -> авто-rollback выполнен "
f"(exit {exit_code}).",
)
else:
# AC-9: a failed rollback escalates loudly for manual intervention.
_notify_post_deploy(
work_item_id,
f"🚨 {work_item_id}: пост-деплой DEGRADED -> авто-rollback ПРОВАЛИЛСЯ "
f"(exit {exit_code}: {detail}). Нужно ручное вмешательство.",
)
else:
# ALERT_ONLY: self-hosting ALWAYS lands here — the tick NEVER auto-rolls-back
# or restarts the prod orchestrator container (BR-5 / AC-8). Loud alert +
# manual-approve request (mirrors deploy Phase A CTA).
action_taken = post_deploy.ALERT_ONLY
_notify_post_deploy(
work_item_id,
f"🚨 {work_item_id}: пост-деплой DEGRADED ({checks_failed}/{checks_total} "
f"провалов). Требуется ручной approve отката — авто-rollback для "
f"self-hosting запрещён (BR-5).",
)
post_deploy.write_post_deploy_log(
repo, work_item_id, branch, post_deploy.DEGRADED, action_taken,
settings.post_deploy_window_s, checks_total, checks_failed,
)
post_deploy.mark_done(repo, work_item_id)
def _notify_post_deploy(work_item_id: str, message: str) -> None:
"""Best-effort Telegram + Plane notification for a post-deploy event (AC-17).
Never raises — a notification failure must not wedge the monitor tick.
"""
try:
send_telegram(message)
except Exception as e: # noqa: BLE001 - never break the tick
logger.warning(f"post-deploy notify telegram failed for {work_item_id}: {e}")
if work_item_id:
try:
plane_add_comment(work_item_id, message, author="deployer")
except Exception as e: # noqa: BLE001 - never break the tick
logger.warning(f"post-deploy notify plane failed for {work_item_id}: {e}")

173
src/staging_verdict.py Normal file
View File

@@ -0,0 +1,173 @@
"""ORCH-061: pure staging-verdict logic (classification + tolerant verdict).
The self-hosting ``orchestrator`` looped on ``deploy-staging`` because
``scripts/staging_check.py`` summed ``all_ok = passed == total`` and exited
non-zero on ANY failed check — so two *infrastructure-only* failures (C9a branch
not found / C9b analyst-job not in queue, both caused by the SANDBOX bot accounts
not being members of the sandbox Plane project) produced ``staging_status:
FAILED`` → rollback ``deploy-staging → development`` → loop (ADR-001 §Context).
This module isolates the **pure verdict logic** so both outcomes are unit-testable
without a live staging stand or docker (TRZ §9):
* ``classify_check(label)`` — label → ``REAL`` | ``SANDBOX_INFRA`` (narrow,
allowlist-driven, fail-closed to ``REAL`` on anything unrecognised);
* ``compute_staging_verdict(items, infra_tolerant)`` — fold the per-check
pass/fail + category into a single ``StagingVerdict``.
It is a **leaf**: stdlib only, no I/O, no project imports — so it is safe to import
both from the orchestrator process and from ``scripts/staging_check.py`` (which
runs inside the ``orchestrator-staging`` container, pattern B6 / ORCH-048). Every
public function honours a **never-raise** contract: on any malformed input it
returns the *conservative* (fail-closed) result, never an exception.
Safety invariant (FR-4 / AC-3): a failed REAL check ALWAYS yields ``FAILED`` /
exit 1 regardless of ``infra_tolerant``. The waiver applies ONLY to the named
``SANDBOX_INFRA`` checks and ONLY when every REAL check (incl. C7/C8) is green —
so the blast-radius of the tolerance is exactly the two allowlisted checks.
"""
from __future__ import annotations
from dataclasses import dataclass, field
# Category constants ---------------------------------------------------------
REAL = "real" # a real pipeline check — fail-closed, always counts
SANDBOX_INFRA = "sandbox_infra" # known to depend on sandbox infra (waivable)
# Narrow allowlist of checks known to depend on sandbox infrastructure rather
# than the pipeline itself (ADR-001 §1). Matched by the check's leading label
# token, e.g. "C9a Branch appears in orchestrator-sandbox" -> token "C9a".
# Keep this set MINIMAL — every entry is a hole in the staging safety-net.
SANDBOX_INFRA_CHECKS = frozenset({"C9a", "C9b"})
def classify_check(label) -> str:
"""Classify a staging-check label as ``REAL`` or ``SANDBOX_INFRA``.
A label is ``SANDBOX_INFRA`` iff its leading whitespace-delimited token is one
of :data:`SANDBOX_INFRA_CHECKS` (exact match or prefix, e.g. ``"C9a"`` from
``"C9a Branch appears…"``). Everything else — and anything unrecognised /
malformed — is ``REAL`` (conservative / fail-closed: an unknown check counts
toward the safety net). Never raises.
"""
try:
text = str(label).strip()
if not text:
return REAL
token = text.split()[0]
for prefix in SANDBOX_INFRA_CHECKS:
if token == prefix or token.startswith(prefix):
return SANDBOX_INFRA
return REAL
except Exception:
return REAL
@dataclass
class StagingVerdict:
"""Outcome of folding the staging-check suite into a single verdict.
``status`` — ``"SUCCESS"`` | ``"FAILED"`` (mirrors the ``staging_status:``
frontmatter contract the deployer writes; unchanged).
``exit_code`` — ``0`` (advance) | ``1`` (rollback). Drives ``sys.exit`` in
``staging_check.py``.
``waived`` — labels of SANDBOX_INFRA checks that failed but were tolerated
(empty unless the waiver actually fired — observability, FR-7).
``summary`` — human-readable one-liner for logs.
"""
status: str
exit_code: int
waived: list = field(default_factory=list)
summary: str = ""
def _coerce_item(item) -> tuple[str, bool, str]:
"""Normalise an input row into ``(label, passed, category)``.
Accepts ``(label, passed)`` or ``(label, passed, category)``. A missing/None
category is resolved via :func:`classify_check`. Never raises — a malformed
row degrades to a failed REAL check (fail-closed) so it cannot silently pass.
"""
try:
label = str(item[0])
passed = bool(item[1])
category = item[2] if len(item) > 2 and item[2] else None
except Exception:
return ("<malformed>", False, REAL)
if category not in (REAL, SANDBOX_INFRA):
category = classify_check(label)
return (label, passed, category)
def compute_staging_verdict(items, infra_tolerant: bool) -> StagingVerdict:
"""Fold per-check results into a tolerant-but-fail-closed staging verdict.
``items`` — iterable of ``(label, passed: bool[, category: str])``.
Decision table (ADR-001 §1):
* any REAL check failed -> FAILED / exit 1 (safety net)
* only SANDBOX_INFRA failed & infra_tolerant -> SUCCESS / exit 0 (waived)
* only SANDBOX_INFRA failed & !infra_tolerant -> FAILED / exit 1 (legacy strict)
* nothing failed -> SUCCESS / exit 0
Never raises: on any internal error the verdict degrades to a conservative
``FAILED`` / exit 1 (never a false green) — AC-10.
"""
try:
real_failed: list[str] = []
infra_failed: list[str] = []
for raw in items:
label, passed, category = _coerce_item(raw)
if passed:
continue
if category == SANDBOX_INFRA:
infra_failed.append(label)
else:
real_failed.append(label)
if real_failed:
# Safety net (FR-4): a real pipeline regression always fails closed,
# regardless of tolerance. Infra failures (if any) are noted but the
# verdict is dominated by the real failure.
extra = f"; infra-fail {infra_failed}" if infra_failed else ""
return StagingVerdict(
status="FAILED",
exit_code=1,
waived=[],
summary=f"FAILED: real checks failed {real_failed}{extra}",
)
if infra_failed and infra_tolerant:
# Waiver fires ONLY here: every REAL check is green and the only
# failures are allowlisted sandbox-infra checks (FR-2).
return StagingVerdict(
status="SUCCESS",
exit_code=0,
waived=list(infra_failed),
summary=(
f"SUCCESS (infra-waived): {infra_failed} are known sandbox-infra "
"checks; all real checks green"
),
)
if infra_failed and not infra_tolerant:
# Legacy strict (kill-switch off): any failure fails closed (1:1 pre-061).
return StagingVerdict(
status="FAILED",
exit_code=1,
waived=[],
summary=f"FAILED (strict): {infra_failed} failed and tolerance disabled",
)
return StagingVerdict(
status="SUCCESS",
exit_code=0,
waived=[],
summary="SUCCESS: all checks green",
)
except Exception as e: # noqa: BLE001 - never-raise; fail closed on doubt
return StagingVerdict(
status="FAILED",
exit_code=1,
waived=[],
summary=f"FAILED (verdict error, fail-closed): {e}",
)

View File

@@ -142,3 +142,26 @@ def test_image_freshness_settings_env_override(monkeypatch):
s = Settings()
assert s.image_freshness_enabled is False
assert s.image_freshness_repos == "orchestrator,enduro-trails"
# ---------------------------------------------------------------------------
# ORCH-061 / TC-09: staging_infra_tolerance_enabled kill-switch (AC-7).
# ---------------------------------------------------------------------------
def test_staging_infra_tolerance_defaults_true(monkeypatch):
"""TC-09 / AC-7: the kill-switch defaults ON (safe default — the safety net
holds regardless; the flag exists to restore legacy strictness instantly)."""
monkeypatch.delenv("ORCH_STAGING_INFRA_TOLERANCE_ENABLED", raising=False)
assert Settings().staging_infra_tolerance_enabled is True
def test_staging_infra_tolerance_env_override_false(monkeypatch):
"""TC-09 / AC-7: ORCH_STAGING_INFRA_TOLERANCE_ENABLED=false -> strict (1:1
pre-ORCH-061: infra-only FAIL again rolls back)."""
monkeypatch.setenv("ORCH_STAGING_INFRA_TOLERANCE_ENABLED", "false")
assert Settings().staging_infra_tolerance_enabled is False
def test_staging_infra_tolerance_env_override_true(monkeypatch):
"""The field is read verbatim from its ORCH_* env var."""
monkeypatch.setenv("ORCH_STAGING_INFRA_TOLERANCE_ENABLED", "true")
assert Settings().staging_infra_tolerance_enabled is True

View File

@@ -102,6 +102,31 @@ def test_tc08_dockerfile_stamps_revision_label():
assert "LABEL org.opencontainers.image.revision=$GIT_SHA" in text
# ---------------------------------------------------------------------------
# TC-08b (ORCH-021 regression): the Dockerfile must not COPY a gitignored path.
# The ORCH-058 staging rebuild builds with the task *worktree* as the docker build
# context. A fresh worktree contains only tracked files, so any `COPY <gitignored>`
# (notably `data/`, the SQLite dir) makes `docker build` fail with exit 1 and bounces
# the task off `deploy-staging`. `data/` is a runtime bind-mount volume anyway, so it
# must never be a COPY source.
# ---------------------------------------------------------------------------
def test_tc08b_dockerfile_does_not_copy_gitignored_data_dir():
text = _DOCKERFILE.read_text(encoding="utf-8")
gitignore = (_ROOT / ".gitignore").read_text(encoding="utf-8").splitlines()
# Precondition: `data/` really is gitignored (the build context will not have it).
assert "data/" in [ln.strip() for ln in gitignore]
# The Dockerfile must not COPY it (would break the worktree-context staging build).
copy_sources = [
line.split()[1]
for line in text.splitlines()
if line.strip().upper().startswith("COPY") and len(line.split()) >= 3
]
assert "data/" not in copy_sources, (
"Dockerfile must not `COPY data/` — it's gitignored and absent from the "
"worktree build context used by the ORCH-058 staging rebuild (exit 1)."
)
# ---------------------------------------------------------------------------
# TC-09: caller↔hook contract — rebuild_staging_image builds the right command
# ---------------------------------------------------------------------------

View File

@@ -90,6 +90,10 @@ def test_tc17_success_deploy_syncs_terminal_done(monkeypatch):
# Spy the merge-lease release to confirm the terminal-sync still frees it.
release = MagicMock()
monkeypatch.setattr(stage_engine.merge_gate, "release_merge_lease", release)
# ORCH-021 arms an orthogonal post-deploy-monitor reserved job at deploy->done
# for the self-hosting repo; disable it here so this test stays focused on the
# ORCH-036 terminal-sync contract (no PIPELINE agent launched leaving deploy).
monkeypatch.setattr(stage_engine.post_deploy.settings, "post_deploy_monitor_enabled", False)
task_id = _make_task("deploy")
stage_engine.run_deploy_finalizer(

View File

@@ -278,3 +278,48 @@ class TestWatchdogGracefulKill:
assert signal.SIGKILL not in sent
assert recorded["called"] is False
# ---------------------------------------------------------------------------
# ORCH-061 / TC-06 + TC-07: "no changes to commit" on an action stage is EXPECTED,
# not under-delivery (FR-3 / AC-4). action_stage_no_changes_note is the PURE
# observability decision used by the post-run no-changes branch: it returns an
# explicit note for self-deploy action stages (deploy-staging/deploy) and None
# everywhere else. It NEVER signals a rollback — advancement is decided by the
# exit-code + gate verdict, never by a commit existing.
# ---------------------------------------------------------------------------
from src.agents.launcher import action_stage_no_changes_note # noqa: E402
class TestActionStageNoChangesNote:
def test_tc06_deploy_staging_self_deploy_returns_note(self):
"""TC-06 / AC-4: on deploy-staging for the self-hosting repo, an empty diff
yields an explicit "expected on action stage" note (no rollback signal)."""
note = action_stage_no_changes_note("deploy-staging", "orchestrator")
assert note is not None
assert "deploy-staging" in note
assert "expected on action stage" in note
def test_tc06_deploy_self_deploy_returns_note(self):
"""The `deploy` stage is equally an action stage for self-deploy."""
note = action_stage_no_changes_note("deploy", "orchestrator")
assert note is not None
assert "deploy: no code changes" in note
def test_tc07_development_stage_returns_none(self):
"""TC-07 / AC-4 regression-guard: on a CODE stage (development) the new
action-stage allowance does NOT apply — no note, behaviour unchanged."""
assert action_stage_no_changes_note("development", "orchestrator") is None
def test_tc06_non_self_repo_returns_none(self):
"""Conditionality (FR-5): the action-stage allowance is self-deploy only;
a non-self repo on deploy-staging gets no special note."""
assert action_stage_no_changes_note("deploy-staging", "enduro-trails") is None
def test_review_stage_returns_none(self):
"""Any non-action stage -> None (defensive: only deploy stages qualify)."""
assert action_stage_no_changes_note("review", "orchestrator") is None
def test_never_raises_on_bad_input(self):
"""never-raise: odd inputs (None stage / None repo) degrade to None."""
assert action_stage_no_changes_note(None, None) is None

210
tests/test_post_deploy.py Normal file
View File

@@ -0,0 +1,210 @@
"""ORCH-021 unit tests — post-deploy monitor pure logic (TC-01..TC-15).
The deterministic, network-free core (classification + reaction decision +
exit-code mapping + artefact frontmatter + never-raise) of ``src/post_deploy.py``.
Network probes and the rollback hook are exercised via mocks; the classifier is
the main subject (mirrors compute_staging_verdict in ORCH-061).
"""
import os
import tempfile
import pytest
import yaml
# Isolate the settings singleton onto a tmp repos_dir BEFORE importing the module.
os.environ.setdefault("ORCH_GITEA_TOKEN", "test-token")
os.environ.setdefault("ORCH_PLANE_API_TOKEN", "test-token")
from src import post_deploy # noqa: E402
# ---------------------------------------------------------------------------
# Helpers
# ---------------------------------------------------------------------------
def _probe(health_ok=True, total=2, fivexx=0):
return {"health_ok": health_ok, "total": total, "fivexx": fivexx}
@pytest.fixture(autouse=True)
def _tmp_state(monkeypatch, tmp_path):
monkeypatch.setattr(post_deploy.settings, "repos_dir", str(tmp_path))
monkeypatch.setattr(post_deploy.settings, "host_repos_dir", str(tmp_path))
yield
# ---------------------------------------------------------------------------
# TC-01..TC-05 — classification (the core)
# ---------------------------------------------------------------------------
def test_tc01_healthy_no_failures():
series = [_probe() for _ in range(5)]
assert post_deploy.classify(series, fail_threshold=3, fivexx_threshold=0.5) == "HEALTHY"
def test_tc02_degraded_consecutive_health_failures():
# Exactly fail_threshold consecutive failures -> DEGRADED (>= contract).
series = [_probe(health_ok=False) for _ in range(3)]
assert post_deploy.classify(series, fail_threshold=3, fivexx_threshold=0.5) == "DEGRADED"
def test_tc03_degraded_by_5xx_ratio_even_when_health_200():
# /health stays 200 (health_ok True) but the 5xx ratio is above threshold.
series = [_probe(health_ok=True, total=2, fivexx=2) for _ in range(3)]
assert post_deploy.classify(series, fail_threshold=10, fivexx_threshold=0.5) == "DEGRADED"
def test_tc04_no_false_trip_single_glitch_then_recovery():
# One isolated failure (1 < threshold) surrounded by healthy probes -> HEALTHY.
series = [_probe(), _probe(health_ok=False), _probe(), _probe()]
assert post_deploy.classify(series, fail_threshold=3, fivexx_threshold=0.5) == "HEALTHY"
def test_tc05_thresholds_change_verdict_on_same_data():
# Same data, different threshold flips the verdict (AC-11): two consecutive fails.
series = [_probe(health_ok=False), _probe(health_ok=False)]
assert post_deploy.classify(series, fail_threshold=3, fivexx_threshold=0.5) == "HEALTHY"
assert post_deploy.classify(series, fail_threshold=2, fivexx_threshold=0.5) == "DEGRADED"
def test_classify_uses_settings_thresholds(monkeypatch):
# The tick reads thresholds from Settings (env ORCH_*) — verify the wiring point.
monkeypatch.setattr(post_deploy.settings, "post_deploy_fail_threshold", 2)
series = [_probe(health_ok=False), _probe(health_ok=False)]
assert post_deploy.classify(
series,
post_deploy.settings.post_deploy_fail_threshold,
post_deploy.settings.post_deploy_5xx_threshold,
) == "DEGRADED"
# ---------------------------------------------------------------------------
# TC-06..TC-08 — reaction decision (self-hosting safety)
# ---------------------------------------------------------------------------
def test_tc06_nonself_auto_rollback_degraded_rolls_back(monkeypatch):
monkeypatch.setattr(post_deploy.settings, "post_deploy_auto_rollback", True)
assert post_deploy.decide_action("enduro-trails", "DEGRADED") == "ROLLBACK"
def test_tc07_self_hosting_degraded_never_rolls_back(monkeypatch):
# orchestrator (self-hosting) is ALWAYS ALERT_ONLY, even with auto_rollback on.
monkeypatch.setattr(post_deploy.settings, "post_deploy_auto_rollback", True)
assert post_deploy.decide_action("orchestrator", "DEGRADED") == "ALERT_ONLY"
def test_tc08_healthy_means_none_for_any_repo():
assert post_deploy.decide_action("orchestrator", "HEALTHY") == "NONE"
assert post_deploy.decide_action("enduro-trails", "HEALTHY") == "NONE"
def test_nonself_default_policy_alert_only(monkeypatch):
monkeypatch.setattr(post_deploy.settings, "post_deploy_auto_rollback", False)
assert post_deploy.decide_action("enduro-trails", "DEGRADED") == "ALERT_ONLY"
# ---------------------------------------------------------------------------
# TC-09..TC-10 — conditionality / kill-switch
# ---------------------------------------------------------------------------
def test_tc09_applies_empty_repos_only_self_hosting(monkeypatch):
monkeypatch.setattr(post_deploy.settings, "post_deploy_monitor_enabled", True)
monkeypatch.setattr(post_deploy.settings, "post_deploy_repos", "")
assert post_deploy.post_deploy_applies("orchestrator") is True
assert post_deploy.post_deploy_applies("enduro-trails") is False
def test_tc09_applies_explicit_repos_csv(monkeypatch):
monkeypatch.setattr(post_deploy.settings, "post_deploy_monitor_enabled", True)
monkeypatch.setattr(post_deploy.settings, "post_deploy_repos", "enduro-trails")
assert post_deploy.post_deploy_applies("enduro-trails") is True
assert post_deploy.post_deploy_applies("orchestrator") is False
def test_tc10_kill_switch_disables_for_everyone(monkeypatch):
monkeypatch.setattr(post_deploy.settings, "post_deploy_monitor_enabled", False)
assert post_deploy.post_deploy_applies("orchestrator") is False
assert post_deploy.post_deploy_applies("enduro-trails") is False
# ---------------------------------------------------------------------------
# TC-11..TC-12 — rollback exit-code mapping
# ---------------------------------------------------------------------------
def test_tc11_rollback_exit0_is_ok():
assert post_deploy.map_rollback_exit_code(0) == "ROLLBACK_OK"
def test_tc12_rollback_exit_nonzero_is_failed():
assert post_deploy.map_rollback_exit_code(1) == "ROLLBACK_FAILED"
assert post_deploy.map_rollback_exit_code(2) == "ROLLBACK_FAILED"
assert post_deploy.map_rollback_exit_code(None) == "ROLLBACK_FAILED"
assert post_deploy.map_rollback_exit_code("garbage") == "ROLLBACK_FAILED"
# ---------------------------------------------------------------------------
# TC-13 — artefact frontmatter
# ---------------------------------------------------------------------------
def test_tc13_log_frontmatter_parses():
body = post_deploy.build_post_deploy_log(
"ORCH-021", "DEGRADED", "ALERT_ONLY", 900, 12, 4
)
assert body.startswith("---\n")
fm = body.split("---", 2)[1]
data = yaml.safe_load(fm)
assert data["post_deploy_status"] == "DEGRADED"
assert data["action_taken"] == "ALERT_ONLY"
assert data["work_item"] == "ORCH-021"
assert data["window_s"] == 900
assert data["checks_total"] == 12
assert data["checks_failed"] == 4
# ---------------------------------------------------------------------------
# TC-14..TC-15 — never-raise
# ---------------------------------------------------------------------------
def test_tc14_probe_network_error_is_conservative_not_raise(monkeypatch):
# urlopen raises on every call -> health bad + monitored endpoints counted as
# 5xx, but NO exception propagates (the helper swallows and reports code 0).
def boom(*a, **k):
raise OSError("network down")
monkeypatch.setattr(post_deploy.urllib.request, "urlopen", boom)
res = post_deploy.probe_signals("http://localhost:8500")
assert res.health_ok is False
assert res.total == 2
assert res.fivexx == 2 # unreachable endpoints counted as failures
def test_tc14_classify_junk_input_swallowed():
# If classify gets junk it must not raise (fail-safe to HEALTHY).
assert post_deploy.classify("not-a-list", 3, 0.5) == "HEALTHY"
assert post_deploy.classify([{"bad": "row"}], 3, 0.5) == "HEALTHY"
assert post_deploy.classify(None, 3, 0.5) == "HEALTHY"
def test_tc15_write_log_no_worktree_returns_false(monkeypatch):
# get_worktree_path raises -> write returns False, no exception (best-effort).
def boom(repo, branch):
raise FileNotFoundError("no worktree")
monkeypatch.setattr("src.git_worktree.get_worktree_path", boom)
ok = post_deploy.write_post_deploy_log(
"nope-repo", "ORCH-021", "feature/x", "HEALTHY", "NONE", 900, 3, 0
)
assert ok is False
# ---------------------------------------------------------------------------
# Sentinel state restart-safe counters
# ---------------------------------------------------------------------------
def test_series_append_and_read_roundtrip():
post_deploy.write_marker("orchestrator", "ORCH-021", post_deploy.ARMED, "armed")
post_deploy.append_probe("orchestrator", "ORCH-021", post_deploy.ProbeResult(False, 2, 1, "x"))
post_deploy.append_probe("orchestrator", "ORCH-021", post_deploy.ProbeResult(True, 2, 0, "y"))
series = post_deploy.read_series("orchestrator", "ORCH-021")
assert len(series) == 2
assert series[0]["health_ok"] is False
assert series[1]["health_ok"] is True
def test_mark_done_idempotency_marker():
assert post_deploy.has_marker("orchestrator", "ORCH-021", post_deploy.DONE) is False
post_deploy.mark_done("orchestrator", "ORCH-021")
assert post_deploy.has_marker("orchestrator", "ORCH-021", post_deploy.DONE) is True

View File

@@ -0,0 +1,259 @@
"""ORCH-021 integration tests — arming + tick orchestration (TC-16..TC-20).
Exercises the wiring in ``stage_engine`` (arm on deploy->done,
``run_post_deploy_monitor`` tick + reaction) and the ``/queue`` observability
block, with the network probe and the rollback hook mocked. Mirrors the
test_deploy_terminal_sync.py harness.
"""
import os
import tempfile
import pytest
_test_db = os.path.join(tempfile.gettempdir(), "test_orch_post_deploy.db")
os.environ["ORCH_DB_PATH"] = _test_db
os.environ["ORCH_REPOS_DIR"] = tempfile.gettempdir()
os.environ.setdefault("ORCH_GITEA_TOKEN", "test-token")
os.environ.setdefault("ORCH_PLANE_API_TOKEN", "test-token")
from unittest.mock import MagicMock # noqa: E402
import src.db as _db # noqa: E402
from src.db import init_db, get_db # noqa: E402
from src import stage_engine # noqa: E402
from src import post_deploy # noqa: E402
@pytest.fixture(autouse=True)
def fresh_db(monkeypatch, tmp_path):
monkeypatch.setattr(_db.settings, "db_path", _test_db)
if os.path.exists(_test_db):
os.unlink(_test_db)
init_db()
# State sentinels live under the tmp repos_dir (container view).
monkeypatch.setattr(post_deploy.settings, "repos_dir", str(tmp_path))
monkeypatch.setattr(post_deploy.settings, "host_repos_dir", str(tmp_path))
monkeypatch.setattr(stage_engine.settings, "repos_dir", str(tmp_path))
# The artefact write is best-effort; stub it so no worktree is needed.
monkeypatch.setattr(post_deploy, "write_post_deploy_log", MagicMock(return_value=True))
yield
@pytest.fixture(autouse=True)
def silence_side_effects(monkeypatch):
for name in (
"notify_stage_change", "notify_qg_failure", "notify_approve_requested",
"send_telegram", "plane_notify_stage", "plane_notify_qg", "plane_add_comment",
"set_issue_in_review", "set_issue_needs_input", "set_issue_in_progress",
"set_issue_blocked", "set_issue_done",
):
monkeypatch.setattr(stage_engine, name, MagicMock())
def _make_task(stage, repo="orchestrator", branch="feature/ORCH-021-x", wi="ORCH-021"):
conn = get_db()
cur = conn.execute(
"INSERT INTO tasks (plane_id, work_item_id, repo, branch, stage) "
"VALUES (?, ?, ?, ?, ?)",
(f"plane-{wi}", wi, repo, branch, stage),
)
task_id = cur.lastrowid
conn.commit()
conn.close()
return task_id
def _jobs(agent=None):
conn = get_db()
if agent:
rows = conn.execute(
"SELECT agent FROM jobs WHERE agent=? ORDER BY id", (agent,)
).fetchall()
else:
rows = conn.execute("SELECT agent FROM jobs ORDER BY id").fetchall()
conn.close()
return [r[0] for r in rows]
def _pass(*a, **k):
return (True, "ok")
def _drive_deploy_to_done(monkeypatch, task_id, repo="orchestrator",
branch="feature/ORCH-021-x", wi="ORCH-021"):
"""Advance a deploy-stage task to done through the real terminal block."""
monkeypatch.setattr(
stage_engine, "QG_CHECKS",
{**stage_engine.QG_CHECKS, "check_deploy_status": _pass},
)
monkeypatch.setattr(stage_engine.merge_gate, "release_merge_lease", MagicMock())
return stage_engine.advance_stage(
task_id=task_id, current_stage="deploy", repo=repo,
work_item_id=wi, branch=branch, finished_agent="deployer",
)
# ---------------------------------------------------------------------------
# TC-16 — arm on deploy->done (applicable repo only)
# ---------------------------------------------------------------------------
def test_tc16_arm_for_self_hosting(monkeypatch):
monkeypatch.setattr(post_deploy.settings, "post_deploy_monitor_enabled", True)
monkeypatch.setattr(post_deploy.settings, "post_deploy_repos", "")
task_id = _make_task("deploy")
_drive_deploy_to_done(monkeypatch, task_id)
assert post_deploy.has_marker("orchestrator", "ORCH-021", post_deploy.ARMED)
assert "post-deploy-monitor" in _jobs("post-deploy-monitor")
def test_tc16_no_arm_for_nonself(monkeypatch):
monkeypatch.setattr(post_deploy.settings, "post_deploy_monitor_enabled", True)
monkeypatch.setattr(post_deploy.settings, "post_deploy_repos", "")
task_id = _make_task("deploy", repo="enduro-trails", branch="feature/ET-9", wi="ET-9")
_drive_deploy_to_done(monkeypatch, task_id, repo="enduro-trails",
branch="feature/ET-9", wi="ET-9")
assert not post_deploy.has_marker("enduro-trails", "ET-9", post_deploy.ARMED)
assert _jobs("post-deploy-monitor") == []
def test_tc16_no_arm_when_kill_switch_off(monkeypatch):
monkeypatch.setattr(post_deploy.settings, "post_deploy_monitor_enabled", False)
task_id = _make_task("deploy")
_drive_deploy_to_done(monkeypatch, task_id)
assert not post_deploy.has_marker("orchestrator", "ORCH-021", post_deploy.ARMED)
assert _jobs("post-deploy-monitor") == []
# ---------------------------------------------------------------------------
# TC-17 — idempotent arm (double webhook)
# ---------------------------------------------------------------------------
def test_tc17_double_arm_is_noop(monkeypatch):
monkeypatch.setattr(post_deploy.settings, "post_deploy_monitor_enabled", True)
armed1 = post_deploy.arm_monitor("orchestrator", "ORCH-021", "feature/ORCH-021-x", 1)
armed2 = post_deploy.arm_monitor("orchestrator", "ORCH-021", "feature/ORCH-021-x", 1)
assert armed1 is True
assert armed2 is False
# Exactly ONE monitor job enqueued despite two arm calls.
assert _jobs("post-deploy-monitor") == ["post-deploy-monitor"]
# ---------------------------------------------------------------------------
# TC-18 — DEGRADED -> non-self auto-rollback (hook mocked)
# ---------------------------------------------------------------------------
def test_tc18_degraded_nonself_rolls_back(monkeypatch):
monkeypatch.setattr(post_deploy.settings, "post_deploy_monitor_enabled", True)
monkeypatch.setattr(post_deploy.settings, "post_deploy_repos", "enduro-trails")
monkeypatch.setattr(post_deploy.settings, "post_deploy_auto_rollback", True)
monkeypatch.setattr(post_deploy.settings, "post_deploy_fail_threshold", 1)
monkeypatch.setattr(post_deploy.settings, "post_deploy_window_s", 30)
monkeypatch.setattr(post_deploy.settings, "post_deploy_interval_s", 30) # budget=1 tick
# Probe reports unhealthy.
monkeypatch.setattr(
post_deploy, "probe_signals",
lambda url: post_deploy.ProbeResult(False, 2, 2, "down"),
)
rollback = MagicMock(return_value=(0, "ok"))
monkeypatch.setattr(post_deploy, "run_rollback", rollback)
notify = MagicMock()
monkeypatch.setattr(stage_engine, "_notify_post_deploy", notify)
logspy = MagicMock(return_value=True)
monkeypatch.setattr(post_deploy, "write_post_deploy_log", logspy)
task_id = _make_task("done", repo="enduro-trails", branch="feature/ET-9", wi="ET-9")
post_deploy.write_marker("enduro-trails", "ET-9", post_deploy.ARMED, "armed")
stage_engine.run_post_deploy_monitor(
{"task_id": task_id, "repo": "enduro-trails", "id": 1, "agent": "post-deploy-monitor"}
)
rollback.assert_called_once_with("enduro-trails")
assert post_deploy.has_marker("enduro-trails", "ET-9", post_deploy.DONE)
# Artefact written with ROLLBACK_OK; a notification was sent.
args = logspy.call_args[0]
assert "DEGRADED" in args
assert "ROLLBACK_OK" in args
assert notify.called
# ---------------------------------------------------------------------------
# TC-19 — self-hosting DEGRADED never rolls back, alerts instead
# ---------------------------------------------------------------------------
def test_tc19_degraded_self_hosting_alert_only(monkeypatch):
monkeypatch.setattr(post_deploy.settings, "post_deploy_monitor_enabled", True)
monkeypatch.setattr(post_deploy.settings, "post_deploy_auto_rollback", True)
monkeypatch.setattr(post_deploy.settings, "post_deploy_fail_threshold", 1)
monkeypatch.setattr(post_deploy.settings, "post_deploy_window_s", 30)
monkeypatch.setattr(post_deploy.settings, "post_deploy_interval_s", 30)
monkeypatch.setattr(
post_deploy, "probe_signals",
lambda url: post_deploy.ProbeResult(False, 2, 2, "down"),
)
# Rollback hook MUST NOT be called for self-hosting (AC-8 structural invariant).
rollback = MagicMock(return_value=(0, "ok"))
monkeypatch.setattr(post_deploy, "run_rollback", rollback)
notify = MagicMock()
monkeypatch.setattr(stage_engine, "_notify_post_deploy", notify)
logspy = MagicMock(return_value=True)
monkeypatch.setattr(post_deploy, "write_post_deploy_log", logspy)
task_id = _make_task("done")
post_deploy.write_marker("orchestrator", "ORCH-021", post_deploy.ARMED, "armed")
stage_engine.run_post_deploy_monitor(
{"task_id": task_id, "repo": "orchestrator", "id": 1, "agent": "post-deploy-monitor"}
)
rollback.assert_not_called()
assert post_deploy.has_marker("orchestrator", "ORCH-021", post_deploy.DONE)
args = logspy.call_args[0]
assert "DEGRADED" in args
assert "ALERT_ONLY" in args
assert notify.called
def test_healthy_tick_requeues_without_finishing(monkeypatch):
# HEALTHY and window not exhausted -> re-queue, do NOT mark done.
monkeypatch.setattr(post_deploy.settings, "post_deploy_monitor_enabled", True)
monkeypatch.setattr(post_deploy.settings, "post_deploy_window_s", 90)
monkeypatch.setattr(post_deploy.settings, "post_deploy_interval_s", 30) # budget=3
monkeypatch.setattr(
post_deploy, "probe_signals",
lambda url: post_deploy.ProbeResult(True, 2, 0, "ok"),
)
task_id = _make_task("done")
post_deploy.write_marker("orchestrator", "ORCH-021", post_deploy.ARMED, "armed")
stage_engine.run_post_deploy_monitor(
{"task_id": task_id, "repo": "orchestrator", "id": 1, "agent": "post-deploy-monitor"}
)
assert not post_deploy.has_marker("orchestrator", "ORCH-021", post_deploy.DONE)
# A follow-up tick job was enqueued.
assert _jobs("post-deploy-monitor") == ["post-deploy-monitor"]
def test_finished_window_tick_is_noop(monkeypatch):
# AC-15: a tick after the window is done is a no-op (no new job, no re-probe).
probe = MagicMock()
monkeypatch.setattr(post_deploy, "probe_signals", probe)
task_id = _make_task("done")
post_deploy.mark_done("orchestrator", "ORCH-021")
stage_engine.run_post_deploy_monitor(
{"task_id": task_id, "repo": "orchestrator", "id": 9, "agent": "post-deploy-monitor"}
)
probe.assert_not_called()
# ---------------------------------------------------------------------------
# TC-20 — /queue observability block
# ---------------------------------------------------------------------------
def test_tc20_queue_block_present(monkeypatch):
monkeypatch.setattr(post_deploy.settings, "post_deploy_monitor_enabled", True)
post_deploy.write_marker("orchestrator", "ORCH-021", post_deploy.ARMED, "armed")
snap = post_deploy.status()
assert snap["enabled"] is True
assert snap["window_s"] == post_deploy.settings.post_deploy_window_s
assert "ORCH-021" in snap["active"]
assert snap["active_count"] >= 1
# A finished window drops out of "active".
post_deploy.mark_done("orchestrator", "ORCH-021")
snap2 = post_deploy.status()
assert "ORCH-021" not in snap2["active"]

View File

@@ -689,6 +689,27 @@ class TestCheckStagingStatus:
assert passed is True
assert "N/A" in reason
# ------------------------------------------------------------------
# ORCH-061 / TC-08: the conditional staging gate is unchanged for
# non-self-hosting repos AND independent of the new tolerance flag (FR-5/AC-6).
# ------------------------------------------------------------------
def test_tc08_non_self_na_independent_of_tolerance_flag(self, tmp_path, monkeypatch):
"""TC-08 / AC-6: for a non-self-hosting repo check_staging_status is the
byte-identical (True, "Staging gate N/A …") regardless of whether the
ORCH-061 infra-tolerance flag is on or off — the new behaviour never
activates off the self-hosting path."""
monkeypatch.setattr("src.qg.checks.settings.repos_dir", str(tmp_path))
from src.qg.checks import check_staging_status
for flag in (True, False):
monkeypatch.setattr(
"src.config.settings.staging_infra_tolerance_enabled", flag,
raising=False,
)
passed, reason = check_staging_status("enduro-trails", "ET-035")
assert passed is True
assert reason == "Staging gate N/A for enduro-trails"
# ------------------------------------------------------------------
# is_self_hosting_repo helper
# ------------------------------------------------------------------

View File

@@ -51,3 +51,100 @@ def test_tc15_finalizer_log_roundtrips_through_parser():
ok_f, _ = _parse_deploy_status(build_deploy_log("ORCH-036", 2, "FAILED"))
assert ok_s is True
assert ok_f is False
# ---------------------------------------------------------------------------
# ORCH-061 / TC-04 + TC-05: infra-tolerant staging verdict (pure logic, AC-2/AC-3).
#
# compute_staging_verdict folds the staging-check suite into a single
# SUCCESS/FAILED verdict that is TOLERANT to known sandbox-infra failures
# (C9a/C9b) but stays fail-closed for any REAL pipeline check. These tests
# exercise the verdict directly — no live staging stand / docker (02-trz §9).
# ---------------------------------------------------------------------------
from src.staging_verdict import ( # noqa: E402
REAL,
SANDBOX_INFRA,
compute_staging_verdict,
)
def _rows(*specs):
"""Helper: build (label, passed, category) rows."""
return [(label, passed, cat) for label, passed, cat in specs]
def test_tc04_only_infra_failures_waived_to_success():
"""TC-04 / AC-2: every REAL check PASS, only known sandbox-infra checks
(C9a/C9b) FAIL, tolerance ON -> SUCCESS / exit 0 (no false rollback)."""
rows = _rows(
("C7 Create issue in Plane SANDBOX", True, REAL),
("C8 Trigger pipeline via /webhook/plane", True, REAL),
("C9a Branch appears in orchestrator-sandbox", False, SANDBOX_INFRA),
("C9b Analyst job enqueued in staging queue", False, SANDBOX_INFRA),
)
v = compute_staging_verdict(rows, infra_tolerant=True)
assert v.status == "SUCCESS"
assert v.exit_code == 0
# Both infra checks are surfaced as waived (observability, FR-7).
assert set(v.waived) == {
"C9a Branch appears in orchestrator-sandbox",
"C9b Analyst job enqueued in staging queue",
}
def test_tc05_any_real_failure_fails_closed():
"""TC-05 / AC-3: at least one REAL pipeline check FAILS (alongside the infra
ones) -> FAILED / exit 1 even with tolerance ON (safety net not weakened)."""
rows = _rows(
("C7 Create issue in Plane SANDBOX", False, REAL), # real regression
("C8 Trigger pipeline via /webhook/plane", True, REAL),
("C9a Branch appears in orchestrator-sandbox", False, SANDBOX_INFRA),
)
v = compute_staging_verdict(rows, infra_tolerant=True)
assert v.status == "FAILED"
assert v.exit_code == 1
assert v.waived == [] # nothing waived when a real check failed
def test_tc05_real_failure_fails_closed_even_alone():
"""A single REAL failure (no infra failures) is still FAILED (fail-closed)."""
rows = _rows(("C7 Create issue in Plane SANDBOX", False, REAL))
v = compute_staging_verdict(rows, infra_tolerant=True)
assert v.status == "FAILED"
assert v.exit_code == 1
def test_tc09_infra_failure_strict_mode_fails_closed():
"""TC-09 / AC-7: with tolerance OFF, an infra-only FAIL again -> FAILED
(1:1 pre-ORCH-061 strict behaviour)."""
rows = _rows(
("C7 Create issue in Plane SANDBOX", True, REAL),
("C9a Branch appears in orchestrator-sandbox", False, SANDBOX_INFRA),
)
v = compute_staging_verdict(rows, infra_tolerant=False)
assert v.status == "FAILED"
assert v.exit_code == 1
def test_all_green_is_success_regardless_of_tolerance():
rows = _rows(
("C7 Create issue in Plane SANDBOX", True, REAL),
("C9a Branch appears in orchestrator-sandbox", True, SANDBOX_INFRA),
)
for tol in (True, False):
v = compute_staging_verdict(rows, infra_tolerant=tol)
assert v.status == "SUCCESS"
assert v.exit_code == 0
assert v.waived == []
def test_tc12_compute_verdict_never_raises_on_garbage():
"""AC-10 never-raise: malformed rows degrade to a conservative FAILED, never
an exception."""
v = compute_staging_verdict([("only-one-element",)], infra_tolerant=True)
assert v.status == "FAILED"
assert v.exit_code == 1
# A completely broken iterable also fails closed without raising.
v2 = compute_staging_verdict(None, infra_tolerant=True)
assert v2.status == "FAILED"
assert v2.exit_code == 1

View File

@@ -114,6 +114,47 @@ def _green_ci(monkeypatch, value=(True, "CI green")):
return m
# --- ORCH-060 fixtures / helpers -------------------------------------------
# State uuids the default "not blocked" fixture maps Blocked / Needs Input to.
_BLOCKED_UUID = "blocked-state-uuid"
_NEEDS_INPUT_UUID = "needs-input-state-uuid"
@pytest.fixture(autouse=True)
def plane_state_not_blocked(monkeypatch):
"""ORCH-060 Guard 2 boundary: by default Plane says the issue is NOT in a
human gate, so the F-1 happy path runs deterministically offline (no real
httpx call). Tests that exercise Guard 2 override ``fetch_issue_state`` to
return ``_BLOCKED_UUID`` / ``_NEEDS_INPUT_UUID`` (or raise)."""
monkeypatch.setattr(
reconciler_mod, "fetch_issue_state",
MagicMock(return_value="some-non-gated-state"),
)
monkeypatch.setattr(
reconciler_mod, "get_project_states",
MagicMock(return_value={
"blocked": _BLOCKED_UUID,
"needs_input": _NEEDS_INPUT_UUID,
}),
)
monkeypatch.setattr(
reconciler_mod.projects, "get_project_by_repo",
MagicMock(return_value=MagicMock(plane_project_id="proj-test")),
)
def _add_dev_runs(task_id, n, agent="developer"):
"""Model N developer retries by inserting N agent_runs rows (ORCH-060)."""
conn = get_db()
for _ in range(n):
conn.execute(
"INSERT INTO agent_runs (task_id, agent) VALUES (?, ?)",
(task_id, agent),
)
conn.commit()
conn.close()
# ---------------------------------------------------------------------------
# TC-01: happy path — stuck development task is advanced to review
# ---------------------------------------------------------------------------
@@ -377,3 +418,265 @@ def test_tc21_daemon_thread_lifecycle(monkeypatch):
rec.stop(timeout=5.0)
assert not first_thread.is_alive()
# ===========================================================================
# ORCH-060: F-1 skips escalated (max developer retries) / Blocked / Needs Input
# ===========================================================================
# ---------------------------------------------------------------------------
# TC-01 (AC-1): escalated dev task (exactly MAX_DEVELOPER_RETRIES dev runs) at a
# green gate is NOT unblocked — stays development, no job, count 0.
# ---------------------------------------------------------------------------
def test_tc060_01_escalated_at_limit_skipped(monkeypatch):
_green_ci(monkeypatch)
task_id = _make_task("development", age_s=3600)
_add_dev_runs(task_id, stage_engine.MAX_DEVELOPER_RETRIES)
rec = Reconciler()
rec.reconcile_gate_once()
assert _stage_of(task_id) == "development"
assert rec.unblocked_total == 0
assert _jobs_for(task_id, "reviewer") == []
# ---------------------------------------------------------------------------
# TC-02 (AC-2): more dev runs than the cap (45) -> also skipped (>= boundary).
# ---------------------------------------------------------------------------
def test_tc060_02_over_limit_skipped(monkeypatch):
_green_ci(monkeypatch)
task_id = _make_task("development", age_s=3600)
_add_dev_runs(task_id, stage_engine.MAX_DEVELOPER_RETRIES + 2)
rec = Reconciler()
rec.reconcile_gate_once()
assert _stage_of(task_id) == "development"
assert rec.unblocked_total == 0
# ---------------------------------------------------------------------------
# TC-03 (AC-3): regression — retry < cap (here 2) still advances to review.
# ---------------------------------------------------------------------------
def test_tc060_03_under_limit_still_advances(monkeypatch):
_green_ci(monkeypatch)
task_id = _make_task("development", age_s=3600)
_add_dev_runs(task_id, stage_engine.MAX_DEVELOPER_RETRIES - 1)
rec = Reconciler()
rec.reconcile_gate_once()
assert _stage_of(task_id) == "review"
assert rec.unblocked_total == 1
# ---------------------------------------------------------------------------
# TC-04 (AC-4): twins — one at the cap (skip), one at cap-1 (advance). Exactly
# one advances.
# ---------------------------------------------------------------------------
def test_tc060_04_boundary_exactly_one_advances(monkeypatch):
_green_ci(monkeypatch)
at_limit = _make_task("development", branch="feature/ET-200-a",
wi="ET-200", age_s=3600)
below = _make_task("development", branch="feature/ET-201-b",
wi="ET-201", age_s=3600)
_add_dev_runs(at_limit, stage_engine.MAX_DEVELOPER_RETRIES)
_add_dev_runs(below, stage_engine.MAX_DEVELOPER_RETRIES - 1)
rec = Reconciler()
rec.reconcile_gate_once()
assert _stage_of(at_limit) == "development" # skipped
assert _stage_of(below) == "review" # advanced
assert rec.unblocked_total == 1
# ---------------------------------------------------------------------------
# TC-05 (AC-5): explicit Plane Blocked (retry < cap) -> skipped.
# ---------------------------------------------------------------------------
def test_tc060_05_blocked_skipped(monkeypatch):
_green_ci(monkeypatch)
monkeypatch.setattr(
reconciler_mod, "fetch_issue_state",
MagicMock(return_value=_BLOCKED_UUID),
)
task_id = _make_task("development", age_s=3600)
rec = Reconciler()
rec.reconcile_gate_once()
assert _stage_of(task_id) == "development"
assert rec.unblocked_total == 0
# ---------------------------------------------------------------------------
# TC-06 (AC-6): explicit Plane Needs Input (retry < cap) -> skipped.
# ---------------------------------------------------------------------------
def test_tc060_06_needs_input_skipped(monkeypatch):
_green_ci(monkeypatch)
monkeypatch.setattr(
reconciler_mod, "fetch_issue_state",
MagicMock(return_value=_NEEDS_INPUT_UUID),
)
task_id = _make_task("development", age_s=3600)
rec = Reconciler()
rec.reconcile_gate_once()
assert _stage_of(task_id) == "development"
assert rec.unblocked_total == 0
# ---------------------------------------------------------------------------
# TC-07 (AC-7): no spam — escalated task triggers no unblock log / telegram /
# QG-failure notification, across several ticks.
# ---------------------------------------------------------------------------
def test_tc060_07_escalated_no_spam(monkeypatch, caplog):
_green_ci(monkeypatch)
monkeypatch.setattr(reconciler_mod.settings, "reconcile_notify_unblock", True)
tg = MagicMock()
monkeypatch.setattr(reconciler_mod, "send_telegram", tg)
task_id = _make_task("development", wi="ET-210", age_s=3600)
_add_dev_runs(task_id, stage_engine.MAX_DEVELOPER_RETRIES)
rec = Reconciler()
with caplog.at_level("INFO", logger="orchestrator.reconciler"):
for _ in range(3):
rec.reconcile_gate_once()
assert "разблокирована" not in caplog.text
tg.assert_not_called()
stage_engine.notify_qg_failure.assert_not_called()
assert rec.unblocked_total == 0
# ---------------------------------------------------------------------------
# TC-08 (AC-8): the gate (check_ci_green) is NOT even evaluated for an escalated
# task — Guard 1 skips before the pre-evaluation.
# ---------------------------------------------------------------------------
def test_tc060_08_no_gate_call_on_escalated(monkeypatch):
ci = _green_ci(monkeypatch)
task_id = _make_task("development", age_s=3600)
_add_dev_runs(task_id, stage_engine.MAX_DEVELOPER_RETRIES)
Reconciler().reconcile_gate_once()
ci.assert_not_called()
# ---------------------------------------------------------------------------
# TC-09 (AC-9): F-2 never replays Blocked / Needs Input — those states are not
# in the polled set, so the handlers are never invoked.
# ---------------------------------------------------------------------------
def test_tc060_09_f2_does_not_replay_blocked(monkeypatch):
states = {
"in_progress": "IP", "approved": "AP", "rejected": "RJ",
"blocked": "BL", "needs_input": "NI",
}
monkeypatch.setattr(
reconciler_mod, "get_project_states", MagicMock(return_value=states)
)
captured = {}
def fake_list(pid, state_uuids):
captured["states"] = list(state_uuids)
# Plane filters client-side to the requested states, so a Blocked /
# Needs Input issue is structurally excluded from the result.
return []
monkeypatch.setattr(reconciler_mod, "list_issues_by_state", fake_list)
hss = MagicMock()
hv = MagicMock()
monkeypatch.setattr(reconciler_mod, "handle_status_start", hss)
monkeypatch.setattr(reconciler_mod, "handle_verdict", hv)
monkeypatch.setattr(
reconciler_mod.projects, "PROJECTS",
[MagicMock(repo="enduro-trails", plane_project_id="P")],
)
rec = Reconciler()
rec.reconcile_plane_once()
assert "BL" not in captured["states"]
assert "NI" not in captured["states"]
hss.assert_not_called()
hv.assert_not_called()
assert rec.unblocked_total == 0
# ---------------------------------------------------------------------------
# TC-10 (AC-10): never-raise — a Guard 2 lookup that raises for one task is
# isolated (that task is conservatively skipped); a neighbour
# still advances and the tick does not blow up.
# ---------------------------------------------------------------------------
def test_tc060_10_guard2_never_raise(monkeypatch):
_green_ci(monkeypatch)
bad = _make_task("development", branch="feature/ET-220-bad",
wi="ET-220", age_s=3600)
ok = _make_task("development", branch="feature/ET-221-ok",
wi="ET-221", age_s=3600)
def flaky(issue_id, project_id):
if issue_id == "plane-ET-220":
raise RuntimeError("plane boom")
return "some-non-gated-state"
monkeypatch.setattr(
reconciler_mod, "fetch_issue_state", MagicMock(side_effect=flaky)
)
rec = Reconciler()
rec.reconcile_gate_once() # must not raise
assert _stage_of(bad) == "development" # conservative skip
assert _stage_of(ok) == "review" # neighbour advanced
assert rec.unblocked_total == 1
# ---------------------------------------------------------------------------
# TC-11 (AC-11): the cutoff comes from MAX_DEVELOPER_RETRIES, not a literal 3.
# Patching the constant to 2 makes a 2-run task escalate (it would
# have advanced under a hardcoded 3).
# ---------------------------------------------------------------------------
def test_tc060_11_limit_from_constant(monkeypatch):
_green_ci(monkeypatch)
monkeypatch.setattr(reconciler_mod, "MAX_DEVELOPER_RETRIES", 2)
task_id = _make_task("development", age_s=3600)
_add_dev_runs(task_id, 2) # == patched cap -> skip
rec = Reconciler()
rec.reconcile_gate_once()
assert _stage_of(task_id) == "development"
assert rec.unblocked_total == 0
# ---------------------------------------------------------------------------
# AC-10 extra: the sub-flag reconcile_skip_blocked_enabled=False mutes ONLY
# Guard 2 (a Blocked task would then be reconciled), while Guard 1
# (escalated) stays active.
# ---------------------------------------------------------------------------
def test_tc060_subflag_disables_only_guard2(monkeypatch):
_green_ci(monkeypatch)
monkeypatch.setattr(
reconciler_mod.settings, "reconcile_skip_blocked_enabled", False
)
monkeypatch.setattr(
reconciler_mod, "fetch_issue_state",
MagicMock(return_value=_BLOCKED_UUID),
)
# Guard 2 disabled -> a Blocked task with retry < cap advances again.
blocked = _make_task("development", branch="feature/ET-230-a",
wi="ET-230", age_s=3600)
# Guard 1 stays active regardless of the sub-flag.
escalated = _make_task("development", branch="feature/ET-231-b",
wi="ET-231", age_s=3600)
_add_dev_runs(escalated, stage_engine.MAX_DEVELOPER_RETRIES)
rec = Reconciler()
rec.reconcile_gate_once()
assert _stage_of(blocked) == "review" # Guard 2 muted
assert _stage_of(escalated) == "development" # Guard 1 still skips

View File

@@ -1132,3 +1132,158 @@ class TestDelegation:
assert args[0] == 5
assert args[1] == "analysis"
assert args[-1] is None
# ---------------------------------------------------------------------------
# ORCH-061: no deploy-staging loop on a healthy self-deploy; the ORCH-35 safety
# net (real staging FAIL -> rollback) stays intact; the new logic never raises
# into advance_stage; and "green with an infra allowance" is distinguishable from
# an honest green (observability).
# ---------------------------------------------------------------------------
class TestStagingInfraTolerance:
"""The verdict that produces ``staging_status:`` is computed in the suite
BEFORE the gate (ORCH-061 ADR-001 §4: check_staging_status is unchanged). At
the engine level we therefore assert the REACTION to the resulting verdict:
SUCCESS advances (no loop), a REAL FAILED rolls back (safety net)."""
def _patch_self_deploy_state(self, monkeypatch, tmp_path):
# Phase A writes restart-safe markers under repos_dir — keep them in tmp.
monkeypatch.setattr(stage_engine.self_deploy.settings, "repos_dir", str(tmp_path))
monkeypatch.setattr(stage_engine.self_deploy.settings, "host_repos_dir", str(tmp_path))
def test_tc01_healthy_self_deploy_advances_no_rollback(self, monkeypatch, tmp_path):
"""TC-01 / AC-1: staging SUCCESS (infra-FAIL already waived in the suite)
+ green merge/freshness sub-gates -> deploy-staging advances to `deploy`
(Phase A approval-pending). NO rollback to development (loop is gone)."""
self._patch_self_deploy_state(monkeypatch, tmp_path)
monkeypatch.setattr(
stage_engine, "QG_CHECKS",
{**stage_engine.QG_CHECKS,
"check_staging_status": _pass,
"check_branch_mergeable": _pass,
"check_staging_image_fresh": _pass},
)
task_id = _make_task("deploy-staging", repo="orchestrator", wi="ORCH-061",
branch="feature/ORCH-061-x")
res = advance_stage(
task_id, "deploy-staging", "orchestrator", "ORCH-061",
"feature/ORCH-061-x", finished_agent="deployer",
)
assert res.advanced is True
assert res.to_stage == "deploy"
assert _stage(task_id) == "deploy" # Phase A advanced the stage
assert res.rolled_back_to is None # NO loop back to development
assert res.note == "self-deploy-approval-pending"
def test_tc02_real_staging_failed_rolls_back(self, monkeypatch, tmp_path):
"""TC-02 / AC-3: a REAL staging failure (verdict FAILED) still rolls
deploy-staging back to development + set_issue_blocked + alert — the
ORCH-35 safety net is NOT weakened by the infra tolerance (FR-4)."""
self._patch_self_deploy_state(monkeypatch, tmp_path)
monkeypatch.setattr(
stage_engine, "QG_CHECKS",
{**stage_engine.QG_CHECKS,
"check_staging_status": _fail("Staging status: FAILED")},
)
task_id = _make_task("deploy-staging", repo="orchestrator", wi="ORCH-061",
branch="feature/ORCH-061-x")
res = advance_stage(
task_id, "deploy-staging", "orchestrator", "ORCH-061",
"feature/ORCH-061-x", finished_agent="deployer",
)
assert res.advanced is False
assert res.rolled_back_to == "development"
assert _stage(task_id) == "development"
assert res.alerted is True
assert stage_engine.set_issue_blocked.called
assert stage_engine.send_telegram.called
def test_tc12_gate_exception_never_crashes_advance(self, monkeypatch, tmp_path):
"""TC-12 / AC-10 never-raise: if the staging gate raises (io/parse/docker
hiccup), advance_stage catches it deterministically — no exception escapes,
the task does NOT advance and is NOT falsely rolled back to development."""
self._patch_self_deploy_state(monkeypatch, tmp_path)
def _boom(*a, **k):
raise RuntimeError("staging gate blew up")
monkeypatch.setattr(
stage_engine, "QG_CHECKS",
{**stage_engine.QG_CHECKS, "check_staging_status": _boom},
)
task_id = _make_task("deploy-staging", repo="orchestrator", wi="ORCH-061",
branch="feature/ORCH-061-x")
# Must NOT raise.
res = advance_stage(
task_id, "deploy-staging", "orchestrator", "ORCH-061",
"feature/ORCH-061-x", finished_agent="deployer",
)
assert res.advanced is False
assert res.rolled_back_to is None # exception != gate FAILED
assert _stage(task_id) == "deploy-staging" # stays put, no loop
assert res.note and "error" in res.note
def test_tc13_end_to_end_self_deploy_no_single_rollback(self, monkeypatch, tmp_path):
"""TC-13 / AC-1+AC-4 integration: a healthy self-deploy goes
deploy-staging -> deploy (Phase A) -> (approve/finalize SUCCESS) -> done
WITHOUT a single rollback to development in the transition log."""
self._patch_self_deploy_state(monkeypatch, tmp_path)
monkeypatch.setattr(
stage_engine, "QG_CHECKS",
{**stage_engine.QG_CHECKS,
"check_staging_status": _pass,
"check_branch_mergeable": _pass,
"check_staging_image_fresh": _pass,
"check_deploy_status": _pass},
)
task_id = _make_task("deploy-staging", repo="orchestrator", wi="ORCH-061",
branch="feature/ORCH-061-x")
seen_stages = []
# 1) deploy-staging -> deploy (Phase A approval-pending).
r1 = advance_stage(
task_id, "deploy-staging", "orchestrator", "ORCH-061",
"feature/ORCH-061-x", finished_agent="deployer",
)
seen_stages.append(_stage(task_id))
assert r1.advanced is True
assert _stage(task_id) == "deploy"
# 2) finalizer (Phase C): deploy verdict SUCCESS -> done.
r2 = advance_stage(
task_id, "deploy", "orchestrator", "ORCH-061",
"feature/ORCH-061-x", finished_agent="deployer",
)
seen_stages.append(_stage(task_id))
assert r2.advanced is True
assert _stage(task_id) == "done"
# Not a single rollback to development anywhere in the path.
assert "development" not in seen_stages
assert r1.rolled_back_to is None and r2.rolled_back_to is None
def test_tc14_waived_green_distinguishable_from_honest_green(self):
"""TC-14 / AC-11 observability: the staging verdict makes "green with an
infra allowance" distinguishable from an honest green — the waived list is
populated and the summary says so, vs an empty waived list + plain summary
for an all-green run."""
from src.staging_verdict import REAL, SANDBOX_INFRA, compute_staging_verdict
waived = compute_staging_verdict(
[("C7", True, REAL),
("C9a", False, SANDBOX_INFRA)],
infra_tolerant=True,
)
honest = compute_staging_verdict(
[("C7", True, REAL),
("C9a", True, SANDBOX_INFRA)],
infra_tolerant=True,
)
# Both advance...
assert waived.status == honest.status == "SUCCESS"
# ...but only the waived one carries the explicit allowance marker.
assert waived.waived == ["C9a"]
assert "infra-waived" in waived.summary.lower()
assert honest.waived == []
assert "infra-waived" not in honest.summary.lower()

View File

@@ -149,3 +149,70 @@ def test_run_b6_records_pass_for_clean_registry(monkeypatch):
_label, passed, detail = results._items[0]
assert passed is True
assert "sandbox=YES" in detail
# ---------------------------------------------------------------------------
# ORCH-061 / TC-03: the suite classifies checks as REAL vs SANDBOX_INFRA so the
# verdict (and exit-code) can tolerate KNOWN sandbox-infra FAILs (C9a/C9b) while
# staying fail-closed for real pipeline checks. Tested without a live stand.
# ---------------------------------------------------------------------------
from src.staging_verdict import REAL, SANDBOX_INFRA # noqa: E402
def test_tc03_classify_infra_checks():
"""C9a/C9b classify as SANDBOX_INFRA; pipeline checks (A/B/C7/C8) as REAL."""
assert sc._classify("C9a Branch appears in orchestrator-sandbox") == SANDBOX_INFRA
assert sc._classify("C9b Analyst job enqueued in staging queue") == SANDBOX_INFRA
assert sc._classify("C7 Create issue in Plane SANDBOX") == REAL
assert sc._classify("C8 Trigger pipeline via /webhook/plane") == REAL
assert sc._classify("A1 GET /health") == REAL
assert sc._classify("B6 Registry: sandbox present") == REAL
def test_tc03_results_records_categories_and_keeps_tuple_shape():
"""Results.add auto-classifies each check; categorized_items() exposes the
category WITHOUT changing the public 3-tuple shape of _items (ORCH-048 b6
tests still unpack (label, passed, detail))."""
results = sc.Results()
results.add("C7 Create issue in Plane SANDBOX", True)
results.add("C9a Branch appears in orchestrator-sandbox", False)
# Public _items shape unchanged (regression guard for ORCH-048 tests).
for item in results._items:
assert len(item) == 3
cats = {label: cat for label, _passed, cat in results.categorized_items()}
assert cats["C7 Create issue in Plane SANDBOX"] == REAL
assert cats["C9a Branch appears in orchestrator-sandbox"] == SANDBOX_INFRA
def test_tc03_explicit_category_overrides_autoclassify():
"""An explicit category arg is honoured (caller can force REAL)."""
results = sc.Results()
results.add("C9a Branch appears in orchestrator-sandbox", False, category=REAL)
label, _passed, cat = results.categorized_items()[0]
assert cat == REAL
def test_tc03_suite_verdict_waives_infra_only_failure():
"""End-to-end through the suite helpers: a run whose only failures are C9a/C9b
-> exit 0 (waived) under tolerance; the waiver is surfaced for observability."""
results = sc.Results()
results.add("C7 Create issue in Plane SANDBOX", True)
results.add("C8 Trigger pipeline via /webhook/plane", True)
results.add("C9a Branch appears in orchestrator-sandbox", False)
results.add("C9b Analyst job enqueued in staging queue", False)
verdict = sc._verdict(results.categorized_items(), infra_tolerant=True)
assert verdict.status == "SUCCESS"
assert verdict.exit_code == 0
assert len(verdict.waived) == 2
# Strict mode (kill-switch off) re-fails the same run.
strict = sc._verdict(results.categorized_items(), infra_tolerant=False)
assert strict.exit_code == 1
def test_tc03_resolve_tolerance_strict_flag_forces_off():
"""--strict forces tolerance OFF regardless of the config default."""
assert sc._resolve_tolerance(cli_strict=True) is False