architect(ET): auto-commit from architect run_id=519

docs/architecture/README.md

@@ -585,6 +585,39 @@ sentinel-state, `write_post_deploy_log`.
 Подробнее: [adr-0010](adr/adr-0010-post-deploy-monitor.md), детально —
 `docs/work-items/ORCH-021/06-adr/ADR-001-post-deploy-monitor.md`.
 
+### Terminal-window-aware гард deploy-статусов: done-задача держит Done (ORCH-094 — design)
+Терминальная (`done`) задача в Plane **не держала `Done`**: непрерывный флапп
+`Awaiting Deploy ⟷ Monitoring after Deploy` (верифицировано на **ORCH-061**, task 47, done с 07.06 —
+273 активности, само не затихает). Причина: три code-писателя deploy-фазовых статусов
+(`stage_engine.py:404/1218/1316`) делегируют в тонкие сеттеры `plane_sync`, которые **БД-стадию не
+читают** ⇒ терминал-слепы; любой повторный/стейл вызов под бот-токеном орка перезаписывает `Done`
+обратно. Тонкость: `update_task_stage("done")` (стр. 369) пишет стадию **раньше** легитимного
+`set_issue_monitoring` (стр. 404) ⇒ пост-деплой-окно ORCH-021 by-design индицируется поверх уже-`done`
+задачи; наивный гард «stage==done → Done» затёр бы легитимный `Monitoring` (регресс).
+
+Решение — **единый terminal-window-aware гард на входе трёх deploy-фазовых сеттеров** (новый leaf
+`src/deploy_status_guard.py`, never-raise, config-gated; образец `serial_gate`/`labels`/`cancel`).
+- **Инвариант:** deploy-фазовый статус легитимен ⇔ задача **нетерминальна** ИЛИ (`done` И активно
+  пост-деплой-окно). `decide(work_item_id, target) → ALLOW | CONVERGE_DONE | SUPPRESS`: off / чужой
+  issue / не-self репо / нетерминал → ALLOW; `cancelled` → SUPPRESS; `done`+`monitoring`+`window_active`
+  → ALLOW; `done` иначе → CONVERGE_DONE (`set_issue_done`, идемпотентно); исключение → ALLOW+warning.
+- **Окно** — новый `post_deploy.window_active(repo,wi)` = `has_marker(ARMED) and not has_marker(DONE)`
+  (restart-safe). **Перенос арм-блока перед terminal-sync** в `advance_stage` блок `next_stage=="done"`
+  ⇒ на стр. 404 `ARMED` уже есть ⇒ легитимный первый `Monitoring` проходит; re-drive после закрытия
+  окна сходится к `Done`.
+- **Харднинг монитора:** страж `has_marker(...DONE)` (ранний return) + тик no-op при `cancelled`
+  мид-окно; тики привязаны к активному job'у (нет job → нет тика, нет статус-PATCH).
+- **Наблюдаемость:** каждый вердикт логируется (`work_item`/`caller`/`target`/`db_stage`/
+  `window_active`/вердикт); подавление — явно.
+- **Инварианты:** `STAGE_TRANSITIONS`/`QG_CHECKS`/`check_*`/machine-verdict ключи/схема БД — НЕ тронуты;
+  `main`/force-push/прод-контейнер/detached-деплой — НЕ тронуты; рабочий self-deploy-цикл 1:1; не-self
+  репо инертны. Kill-switch `ORCH_DEPLOY_STATUS_GUARD_ENABLED` (→ 1:1), область
+  `ORCH_DEPLOY_STATUS_GUARD_REPOS` (пусто → self-hosting). Ограничение: внешняя Plane-automation (если
+  таков актор) закрывается буфером сходимости, а не code-фиксом — локализация актора в задаче (BR-7).
+
+Подробнее: [adr-0028](adr/adr-0028-terminal-window-aware-deploy-status-guard.md), детально —
+`docs/work-items/ORCH-094/06-adr/ADR-001-terminal-window-aware-deploy-status-guard.md`.
+
 ### Свежесть артефакта BUILD-ONCE: провенанс staging-образа (ORCH-058 — реализовано)
 BUILD-ONCE retag (ORCH-36) промоутит `SOURCE_IMAGE=orchestrator-orchestrator-staging` в прод
 **без rebuild**, полагаясь на «staging-образ свеж и провалидирован». Этой гарантии нет: