diff --git a/memory/2026-06-05.md b/memory/2026-06-05.md
index 8aad084..e03cc68 100644
--- a/memory/2026-06-05.md
+++ b/memory/2026-06-05.md
@@ -254,3 +254,56 @@
 ### Этап 5 (ORCH-35) = Вариант A (решение по объёму ждёт Славу: только A или A+B)
 - Вариант A: стадия `deploy-staging` МЕЖДУ testing и deploy, QG `check_staging_status` (образец `check_deploy_status`), deployer гоняет `staging_check.py` против 8501. Прод-деплой недостижим пока staging не зелёный. Off-limits: не ломать существующие QG/rollback.
 - Полный план разведки — в `tasks/orchestrator/DESIGN_STAGING_ENV.md` (раздел "РАЗВЕДКА КОДА ДЛЯ ЭТАПА 5").
+
+
+---
+
+## Этап 5 (ORCH-35) — staging-гейт встроен ✅, проверено лично + найден архитектурный нюанс (05.06 ~07:30 UTC)
+
+### Что сделано Dev (PR #31, ветка `feature/ORCH-35-staging-gate`, коммит `e0b6e92`, НЕ мержен)
+Вставлена стадия `deploy-staging` МЕЖДУ `testing` и `deploy`. Новая цепочка: `testing → deploy-staging → deploy → done`.
+- `src/stages.py` — `STAGE_TRANSITIONS`: `testing→deploy-staging` (agent=deployer, qg=check_tests_passed), `deploy-staging→deploy` (agent=deployer, qg=check_staging_status), `deploy→done` без изменений
+- `src/qg/checks.py` — новый `check_staging_status` + `_parse_staging_status` (парсит `staging_status: SUCCESS|FAILED` из `15-staging-log.md`), зарегистрирован в `QG_CHECKS`
+- `src/stage_engine.py` — rollback-ветка: FAILED на deploy-staging → откат на `development` (по образцу БАГ-8 deploy)
+- `.openclaw/agents/deployer.md` — НОВЫЙ файл (в репо его не было), инструкция для обеих стадий deployer
+- `tests/test_qg.py`, `tests/test_stage_engine.py` — обновлены + 18 новых staging-тестов
+
+### Проверено МНОЙ лично на проде (не со слов Dev)
+- **312 passed, 0 failed** — прогнала весь набор сама. Способ: прод-образ орка (там все зависимости) + примонтировала исходники ветки поверх → честный прогон в реальном окружении. (В прод-контейнере `tests/` нет — образ собран без них; чистый python-образ не имеет зависимостей — поэтому монтирование в прод-образ.)
+- Цепочка вживую: `get_next_stage("testing")=="deploy-staging"`, `("deploy-staging")=="deploy"`, `("deploy")=="done"`; `get_qg_for_stage("deploy-staging")=="check_staging_status"` ✓
+- QG-логика вживую: SUCCESS→(True), FAILED→(False), missing→(False) ✓
+- Rollback staging-провала → `development` (3 теста) ✓
+- git diff: только код (`.openclaw/agents/deployer.md`, `src/qg/checks.py`, `src/stage_engine.py`, `src/stages.py`, `tests/*`). off-limits (.env/compose/staging_check.py/deploy-hook.sh) не тронуты. Прод 8500 не задет.
+
+### ⚠️ АРХИТЕКТУРНЫЙ НЮАНС (раскопала сама, ЖДЁТ решения Славы перед мержем)
+**Промпты агентов (`deployer.md` и пр.) живут В КАЖДОМ репозитории задач, а не в репо orchestrator.**
+- `launcher.py` делает `cat {system_prompt}` ВНУТРИ `work_path` (= клон ЦЕЛЕВОГО репо задачи). Путь `.openclaw/agents/deployer.md`.
+- **enduro-trails-репо** имеет полный набор промптов (analyst/architect/deployer/developer/reviewer/tester.md от 04.06), но deployer.md там СТАРЫЙ — про staging-гейт не знает.
+- **orchestrator-репо** — Dev положил новый deployer.md с staging-инструкцией (правильно для self-hosting: орк деплоит сам себя, work_path=клон orchestrator).
+
+**Проблема:** стадия `deploy-staging` ГЛОБАЛЬНАЯ (в STAGE_TRANSITIONS) → применяется ко ВСЕМ проектам конвейера. Но:
+1. У enduro deployer-промпт не знает про staging → не напишет `15-staging-log.md` → гейт FAIL → enduro-задачи откатятся на `development` и застрянут
+2. `staging_check.py --base-url localhost:8501` = staging ОРКА. У enduro своего staging нет. Гейт концептуально orchestrator-специфичный.
+
+**Варианты (предложены Славе):**
+- 🅰️ (моя рекомендация) `deploy-staging` УСЛОВНЫЙ — гейт только для self-hosting (проект orchestrator), для остальных стадия пропускается/пустой pass. Правильная инкапсуляция.
+- 🅱️ оставить как есть + обновить enduro deployer.md + поднять enduro-staging (большой объём, выходит за рамки)
+- 🅲️ заморозить мерж как known-issue (активных enduro-задач нет), мержить после A
+
+**СТАТУС: жду решение Славы. PR #31 НЕ мержен. ORCH-35 НЕ закрыт.**
+
+### Identifiers Этапа 5
+- PR `#31` в Gitea (admin/orchestrator), ветка `feature/ORCH-35-staging-gate`, коммит `e0b6e92`, НЕ merged
+- ORCH-35 issue id: `4ead9be7-e1bf-4a28-8c76-88bda1c1fc2c`
+- Done state id: `3738cd3c-7610-4907-ba5e-26b9a248d9c0`
+- Новый артефакт стадии: `docs/work-items/<wi>/15-staging-log.md`, машинное поле `staging_status:`
+- Прогон тестов: образ прод-орка + монтирование исходников ветки → 312 passed
+
+## Вариант B вынесен в ORCH-36 (Backlog) — исполняемый самодеплой
+Создан ORCH-36 «Исполняемый самодеплой — стадия deploy дёргает хост-хук (Вариант B)» в Backlog с детальным описанием. Внутри зашиты 5 метрик «доверия к автоматике» для переключения флага manual approve → авто:
+1. ≥10 успешных промоутов подряд (откат не понадобился)
+2. Zero false-negative — staging-гейт ни разу не пропустил битый деплой (критично)
+3. Авто-rollback в бою ≥2-3 раза (recovery 100%, MTTR <60с)
+4. Ни одного «молчаливого» деплоя (каждый → Plane + Telegram)
+5. Период ≥10 деплоев ИЛИ ≥2 недели без инцидентов
+Связи: ORCH-7/21/34/35. Ждёт когда вернёмся.