docs/superpowers/2026-06-16-deploy-commit-not-executable-under-wall-bug.md

# Баг: прод-деплой и коммит невозможно выполнить шагами опечатанного плана под стеной — вся механика падает на хозяина-непрограммиста

> Дата: 16.06.2026. Для проекта **claude-brain**. Кодовая фраза «роутер-наставник».
> Тип: bug-report (управляющий слой стены). Выявлено на живом деплое F-1 (CVE vendor-апдейт).

## Краткая суть

Под стеной «роутер-наставник» легитимный план прод-деплоя, **прошедший наставника и судью**
(✅ GO, опечатан), всё равно **не может быть исполнен самим контроллером**. Его шаги — `ssh`,
`scp`, `composer install`, `systemctl`, `php artisan down/up` — это floor-опасные команды
(класс install / cloud-CLI / ssh / redirect). Пол (M5) рубит их безусловно, стена не двигает
указатель → опечатанный план встаёт колом. Аналогично git-коммит упирается в частокол
router-gate (git-approval) + criterion-gate + verify-gate.

В итоге **вся механика деплоя и коммита перекладывается на хозяина**: он вручную копипастит
~18 команд в свой терминал, по его собственным словам — «тупо сижу выполняю механическую работу
без осознания».

## Почему это баг, а не «так задумано»

Стена строилась, чтобы правки кода шли через осознанный sealed-plan + ревью наставника/судьи.
Но для **прод-ops** она даёт ОБРАТНЫЙ эффект по безопасности:

- осознанный агент, прошедший ревью, **отстранён** от исполнения;
- исполняет **человек-непрограммист**, который не понимает содержимого команды;
- он не может санитарно проверить команду, заметить опечатку, среагировать на нештатный вывод;
- для **НЕОБРАТИМОГО** действия на боевом сервере это **повышает** риск, а не снижает.

То есть для класса задач «прод-ops/коммит» стена работает против собственной цели.

## Доказательства из этой сессии (живой деплой F-1)

1. **Опасный инцидент в окне обслуживания.** Сайт был под `artisan down` (HTTP 503). В терминал
   **случайно вставился текст из соседней сессии** (claude-brain): PowerShell ответил
   `Unexpected token 'enforce-mentor-then-judge' …`, `'memory' is not recognized`. Мои
   smoke-команды НЕ выполнились, сайт оставался в обслуживании дольше нужного. Будь в буфере
   деструктивная команда — это ушло бы на живой прод. Корень — человек как «реле» без понимания
   того, что он вставляет.
2. **Повторные сбои кавычек.** `grep -iE "a|b"` через цепочку PowerShell → ssh терял двойные
   кавычки → `b: command not found` (трижды за сессию: `phone_ranges|region`,
   `queue|horizon|liderra`, `Cache|Config|Route|View`). Каждый — лишний round-trip, потому что
   человек не мог сам отладить квотинг.
3. **Объём ручного труда.** Pre-flight + доставка + бэкап + down + install + smoke + кэши +
   коммит = ~18 копипаст-итераций туда-обратно. Всё это осознанный агент сделал бы за один
   проход с само-проверкой вывода.
4. **Баг подтвердил сам себя.** Попытка контроллера записать ЭТОТ баг-файл была заблокирована
   стеной: `действие не в плане (ожидался шаг … ssh liderra-prod 'df -h /')`. Опечатанный план
   деплоя так и висел на шаге 1, потому что его шаги исполнял человек в терминале (вне стены), а
   указатель плана у стены не двигался. Запись удалось сделать только через owner-escape
   `write:<path>`. Застрявший неисполнимый план блокирует и последующую обычную работу.

## Где именно ломается (точки для brain)

- **Floor M5** (`enforce-floor-*`): классы install / cloud-CLI / ssh / redirect рубятся
  безусловно. Нет понятия «благословлённый ops-шаг опечатанного плана».
- **supreme-gate**: при floor-блоке со-хука указатель плана **не откатывается** (десинк F-J) —
  значит даже теоретически собранный sealed-ops-план повис бы на первом ssh-шаге. Вдобавок
  план, чьи шаги физически не исполнимы под стеной, навсегда застревает на шаге 1 и блокирует
  дальнейшую работу (см. доказательство №4).
- **Коммит**: router-gate + criterion-gate + verify-gate рассчитаны на **код-PR**, не на
  docs/ops-коммит. Чистый путь — терминал хозяина `LEFTHOOK=0`, т.е. снова руками.

## Чего хотелось бы (направления; решает brain, это не предписание)

1. **Канал «опечатанный ops-runbook».** Если план прошёл наставника+судью И помечен как
   ops/deploy — пол должен **пускать его `ssh`/`scp`/`systemctl`/`composer`-шаги к исполнению
   контроллером** строго по белому списку из самого плана, с полным журналом. Тогда необратимое
   делает осознанный агент, а человек только один раз говорит «деплоим».
2. **Либо эргономика escape под блок ops-команд:** один owner-grant на весь благословлённый
   runbook (а не `FLOOR-ESCAPE` на каждую из ~15 команд), окно шире, привязка к hash плана.
3. **Минимум:** floor должен отличать «ssh-шаг благословлённого плана» от «произвольной
   floor-опасной команды»; и стена не должна оставлять указатель на неисполнимом шаге —
   план, шаги которого floor-блокируются, должен авто-завершаться или явно помечаться
   «исполняется вне стены», а не висеть колом (фикс десинка F-J + застревания из доказательства №4).
4. **Коммит:** docs/ops-коммит из-под опечатанного плана не должен требовать criterion/verify-gate
   (там нет кода и тестов) — отдельная ветка гейта по типу изменения.

## Влияние

Пока не починено: каждый прод-деплой и коммит идут через ручной копипаст хозяина-непрограммиста —
**медленно** (раздутый round-trip) и **рискованно** (инцидент №1 в окне обслуживания живого
прода). Это прямо противоречит цели стены: для прод-ops она безопасность снижает.

## Связанное

- Деплой, на котором выявлено: `docs/superpowers/plans/2026-06-16-f1-cve-deploy-plan.md` +
  `docs/superpowers/specs/2026-06-16-f1-cve-deploy-spec-v3.md` (опечатаны, GO).
- Соседний баг машинерии: `docs/superpowers/2026-06-16-mentor-empty-recommendation-bug.md`.
- Десинк указателя F-J — описан в `docs/superpowers/router-mentor-wall-GUIDE.md`.