diff --git a/tasks/orchestrator/STATUS_MODEL_PROPOSAL.md b/tasks/orchestrator/STATUS_MODEL_PROPOSAL.md
index 00f7bf0..8cb0538 100644
--- a/tasks/orchestrator/STATUS_MODEL_PROPOSAL.md
+++ b/tasks/orchestrator/STATUS_MODEL_PROPOSAL.md
@@ -45,36 +45,58 @@
    Предлагаю **`Deploying`** — орк ставит при старте Phase B (detached прод-деплой идёт),
    снимает в Done после health-OK финалайзера (или в Rejected/Blocked при фейле).
 
-## 3. Предлагаемая статусная модель (итог)
+## 3. Предлагаемая статусная модель (итог) — v2 с правками Славы
 
 ### A. Новые статусы (создать в Plane + замапить в резолвере)
 | Статус | Класс | Группа | Кто ставит/жмёт | Смысл |
 |---|---|---|---|---|
+| **Analysis** | 🔵 выход | started | орк | идёт анализ/BRD (1-я стадия) — СВОЙ статус вместо In Progress |
 | **Awaiting Deploy** | 🔵 выход | started | орк (Phase A) | staging зелёный, merge готов — жду Confirm Deploy на прод |
 | **Confirm Deploy** | 🟢 вход | started | человек | запустить Phase B прод-деплой (УЖЕ создан в ORCH-59 ✅) |
-| **Deploying** | 🔵 выход | started | орк (Phase B) | прод-деплой идёт (detached), health-check в процессе |
+| **Deploying** | 🔵 выход | started | орк (Phase B) | прод-деплой идёт (detached), health-check |
+| **Monitoring** | 🔵 выход | started | орк (post-deploy ORCH-21) | деплой встал, идёт пост-деплой окно (~15мин, 30 опросов) — ещё НЕ Done |
+
+(имена `Awaiting Deploy` / `Monitoring` — рабочие; финал — по ответам Славы, см. §5)
 
 ### B. Семантика `In Review` — РАЗГРУЗИТЬ
-- Оставить `In Review` ТОЛЬКО за approve-pending артефактов конвейера (BRD/ревью на ранних
-  стадиях) — это его исходный смысл.
+- Оставить `In Review` ТОЛЬКО за approve-pending артефактов конвейера (BRD/ревью) — исходный смысл.
 - Phase A перестаёт ставить `In Review` → ставит **`Awaiting Deploy`**.
 
-### C. Полный жизненный цикл задачи (целевой)
-```
-Backlog → Todo → In Progress(analysis) → [In Review → Approved] → Architecture →
-Development → Review → Testing → Awaiting Deploy → [Confirm Deploy] → Deploying → Done
-                                                         (человек)     (орк)
-```
-Ветки: Rejected (откат), Needs Input (нужен ввод), Blocked (затык), Cancelled.
+### B2. Вход в analysis — РАЗГРУЗИТЬ (пункт 3 Славы)
+- Сейчас: человек жмёт `In Progress` (вход-триггер) → но и стадия `analysis` маппится в
+  `in_progress` (`_STAGE_TO_STATE_KEY`), и `deploy` тоже → ТРОЙНАЯ перегрузка `In Progress`.
+- Проблема: задача в анализе висит как «In Progress», не видно ЧТО именно идёт (анализ).
+- Решение: ввести выходной статус **`Analysis`** (по аналогии с Architecture/Development/...).
+  `In Progress` остаётся ТОЛЬКО входным триггером «начать конвейер» (человек жмёт), а орк сразу
+  переводит в `Analysis`. После ввода Awaiting Deploy/Deploying/Monitoring статус `In Progress`
+  больше НЕ используется как индикация стадии — только как кнопка старта. Чисто.
 
-### D. Что УБРАТЬ / признать лишним (гигиена)
-Кандидаты на чистку (проверить, что нигде в коде не читаются как триггер):
-- **`Blocked`** — код его не выставляет и не читает как триггер (есть в маппинге, но не в
-  жизненном цикле). Либо начать использовать осмысленно (затык внешней зависимости), либо убрать.
-- **Дубль индикации:** `In Progress` используется и для analysis, и для deploy-стадии
-  (STAGE_TO_STATE). После ввода Awaiting Deploy/Deploying стадия deploy получит свои статусы —
-  In Progress останется только за analysis. Чище.
-- Проверить `Todo` vs `Backlog` — оба «не начато»; возможно один лишний (низкий приоритет).
+### B3. post-deploy monitor → статус `Monitoring` (пункт 1 Славы)
+- Сейчас: после health-OK задача СРАЗУ → Done, а монитор (ORCH-21) тикает «после Done» 15 мин.
+  `Done` означает «процесс стартовал», а не «доказанно здоров».
+- Решение: ввести **`Monitoring`** между Deploying и Done. Финалайзер при health-OK ставит
+  `Monitoring` (а не Done) → пост-деплой окно тикает → при чистом закрытии (HEALTHY, 30 опросов)
+  → `Done`; при деградации (5xx/UNHEALTHY) → `Blocked` + Telegram + сигнал к откату.
+  Тогда `Done` = «развёрнуто И доказанно стабильно 15 минут».
+
+### C. Полный жизненный цикл задачи (целевой v2)
+```
+Backlog → Todo → [In Progress*] → Analysis → [In Review → Approved] → Architecture →
+Development → Review → Testing → Awaiting Deploy → [Confirm Deploy] → Deploying →
+Monitoring → Done
+  (* In Progress = только кнопка старта, человек; дальше всё ставит орк)
+  [...] = действие человека (вход-триггер)
+```
+Ветки: Rejected (откат), Needs Input (нужен ввод), **Blocked (затык/поломка/фейл деплоя)**, Cancelled.
+
+### D. Гигиена — ИСПРАВЛЕНО по факту кода
+- **`Blocked` — НЕ убирать, он РАБОЧИЙ** (проверено grep'ом, был неправ ранее). Код ставит
+  `set_issue_blocked` в 9+ местах: фейл гейтов, retry-cap, бюджет исчерпан (anti-livelock),
+  БАГ-8 rollback (deploy→development), падение агента (launcher), reconciler Guard 2 пропускает
+  blocked-задачи. Именно его Слава видел при поломках. Несущий статус — ОСТАВИТЬ.
+  Доп.выгода новой модели: фейл деплоя `Deploying`/`Monitoring` → `Blocked` (консистентно).
+- **Разгрузка `In Progress`:** см. B2 — станет чисто входным триггером.
+- `Todo` vs `Backlog` — оба «не начато»; проверить, возможно один лишний (низкий приоритет).
 
 ## 4. Объём изменений (для будущего ТЗ Dev-агенту)
 - **Plane (инфра, делаю я через API):** создать `Awaiting Deploy`, `Deploying`
@@ -90,10 +112,16 @@ Development → Review → Testing → Awaiting Deploy → [Confirm Deploy] →
   - Тесты: Phase A ставит Awaiting Deploy (не In Review); Phase B ставит Deploying;
     fail-closed при отсутствии статусов.
 
-## 5. Открытые вопросы Славе
-1. Имя для approve-pending деплоя: **`Awaiting Deploy`** или **`Ready for Deploy`**? (склоняюсь
-   к `Awaiting Deploy` — подчёркивает «жду тебя», но `Ready for Deploy` тоже ок).
-2. При фейле прод-деплоя `Deploying` → куда? Предлагаю **`Rejected`** (откат на deploy, повторный
-   Confirm Deploy после фикса) — консистентно с текущим rollback. Или отдельный `Deploy Failed`?
-3. `Blocked` — начать использовать (внешний затык) или убрать как мёртвый?
-4. Оформить как work item эпика ORCH-54 (например ORCH-60-status-model)? Делать после ORCH-23?
+## 5. Открытые вопросы Славе (v2)
+1. **Имя approve-pending деплоя:** `Awaiting Deploy` или `Ready for Deploy`? (склоняюсь к
+   `Awaiting Deploy` — «жду тебя»; `Ready for Deploy` = «готово к деплою», тоже ясно).
+2. **Имя пост-деплой статуса:** `Monitoring` / `Monitoring after Deploy` / `Post-Deploy Watch` /
+   `Verifying`? (склоняюсь к `Monitoring` — коротко; `Verifying` подчёркивает «проверяю здоровье»).
+3. **Фейл деплоя `Deploying`/`Monitoring` → куда?** Предлагаю **`Blocked`** (консистентно с тем,
+   как код уже метит фейлы) + Telegram + сигнал к откату на rollback-снимок. Согласен?
+4. **`Analysis` статус** для 1-й стадии — вводим (как просил, п.3)? Да/нет.
+5. **Оформить как work item** эпика ORCH-54 (напр. `ORCH-XX-status-model`)? Сейчас или после ORCH-23?
+
+### Сводка новых статусов к созданию в Plane (после согласования имён):
+`Analysis`, `Awaiting Deploy`, `Deploying`, `Monitoring` (+ `Confirm Deploy` уже есть).
+`Blocked` — остаётся. `In Review` — разгружается (только артефакты). `In Progress` — только старт.