houseplan-card/docs/specs/402-confirm-outside-main-branch.md

# ТЗ #402 — Подтверждение опасного действия живёт вне зависимости от ветки render()

- Issue: https://github.com/Matysh/houseplan-card/issues/402
- Приоритет: P1, bug (регресс против поведения до #32); полный трек — класс A
- Ревизия: 2 (2026-08-31) — по SPEC-REVIEW-402-r1 (H1: touch/kiosk; M1: причина
  исключения соседних подтверждений)

## Сценарий

Хозяин ставит карточку в первый раз: пространств ещё нет, идёт онбординг. В
списке сохранённых на сервере планов лежит чужой, ошибочно загруженный файл —
он жмёт корзину. Ничего не происходит. Ни диалога, ни удаления, ни сообщения:
кнопка мертва, и понять почему нельзя. До #32 здесь спрашивал браузерный
`confirm()`, и удаление работало.

## Что человек увидит до и после

**До**: в состоянии «нет ни одного пространства» (а также при недоступном
`fixed_floor` и при потерянном пространстве) любое опасное действие молча не
делает ничего; если подтверждение было открыто до перехода в такое состояние —
диалог исчезает сам, а действие остаётся ни выполненным, ни отменённым.
**После**: подтверждение спрашивается и в этих состояниях; если карточка вообще
ничего не рисует, действие отклоняется явно, а не подвисает.

## Проблема и контракт

`HpConfirmController` (`src/danger-confirm.ts:36`) корректен: `cancel()`
резолвит промис `false`, `resolve()` сверяет токен, новый запрос отменяет
предыдущий. Промис виснет не потому, что контроллер теряет решение, а потому
что решение неоткуда взяться: оно приходит событием `hp-confirm-decision` от
элемента `<hp-confirm>`, а элемента в DOM нет.

`render()` (`src/houseplan-card.ts:11165`) — цепочка ранних `return`, и
`hp-confirm` стоит только в её конце (`:11872`):

| Строка | Ветка | Рисует |
|---|---|---|
| `:11166` | нет `_config`/`hass` | `nothing` |
| `:11170` | языковой гейт `cold` | загрузчик языка |
| `:11171` | языковой гейт `warm` | `noChange` |
| `:11192` | `fixed_floor` pending | своя карточка |
| `:11203` | `fixed_floor` invalid | своя карточка |
| `:11216` | `!model.length` (онбординг) | своя карточка |
| `:11247` | `!space` | `nothing` |
| `:11872` | основная | **единственное место с `hp-confirm`** |

Удаление сохранённого плана вызывается из онбординга
(`src/houseplan-onboarding-runtime.ts:273` → `_deleteServerPlan`, который
ждёт `_confirmDanger`), то есть буквальный сценарий issue лежит в ветке
`:11216`.

**Воспроизведено исполнением** (браузер, реальная карточка): очищаю `spaces`,
вызываю `_confirmDanger({...})` →

```
controllerHasRequest:        true
confirmDialogInDom:          false
promiseSettledOrDialogShown: false   (ожидание 200 мс)
```

**Вторая половина того же дефекта** (в issue не описана, найдена при разборе):
уже открытое подтверждение исчезает, если карточка переходит в любую раннюю
ветку — потеряла пространство, ушла в `fixed_floor` pending. Пользователь
видит, как диалог пропал сам; вызывающий остаётся с неразрешённым промисом.
Поэтому «добавить рендер в ветку онбординга» — недостаточное решение: оно
чинит один вход и оставляет класс.

**Контракт**: `hp-confirm` не принадлежит ни одной ветке `render()`. Он
рендерится всегда, когда карточка рисует хоть что-то, и переживает смену
ветки. Разделение ответственности прежнее: контроллер владеет состоянием и
токеном, вызывающий — ревалидацией после `await` (введена #32 и не меняется).

**Граница**: две ветки рисуют «ничего» осознанно — `noChange` языкового гейта
(`:11171`, Lit-сигнал «не трогай DOM», его нельзя обернуть в шаблон) и
`nothing` до инициализации (`:11166`). В них подтверждение показать
невозможно, и правильное поведение — **отклонить запрос сразу** (промис
резолвится `false`), а не оставить его висеть. Пользователь в этот момент
ничего не нажимал: карточка ещё не готова.

## Скоуп / не-скоуп

**В скоупе**: структура `render()` в `src/houseplan-card.ts` (вынос
подтверждения из цепочки), поведение `_confirmDanger` в неготовых состояниях,
смоки и мутанты.

**Не в скоупе**: содержимое и оформление диалога (#32), ревалидация после
`await` у вызывающих (#32), роль `alertdialog` и `aria-describedby` (#406).

**`_tapConfirm` и `_vacCalConfirm` — не в скоупе, и причина не та, что я
написал в ревизии 1.** Они рендерятся в той же финальной ветке `render()`
(`:11802-11878`), что и `_dangerConfirm`, — «свои ветки» было неверным
утверждением. Настоящих причин две, и обе по существу:

1. У них **нет промиса**: `_tapConfirm` хранит синхронный `exec()`, который
   вызывается прямо из обработчика кнопки, а `_vacCalConfirm` — это
   информационный диалог с закрытием по `hp-close`. Ни один вызывающий не
   ждёт разрешения, поэтому «висящего промиса» — самого дефекта этой задачи —
   у них не бывает.
2. Их точки входа недостижимы из ранних веток: тап по маркеру и калибровка
   пылесоса требуют отрисованного плана, то есть той самой основной ветки.

Из этого следует практическое требование к реализации: при выносе
`hp-confirm` из цепочки **соседние два блока остаются на месте**. Утащить их
за компанию — значит без нужды поменять поведение диалогов, для которых эта
задача ничего не обещает.

## UX

Видимых изменений в оформлении нет. Меняется только то, что подтверждение
появляется там, где раньше действие молча не работало.

## Touch и kiosk

`docs/TOUCH-SUPPORT.md` § Safety floor запрещает «best effort» в трёх вещах,
и одна из них — обход подтверждения разрушающего действия. Сейчас на touch
этот пол пробит ровно так же, как на мыши: в ветке онбординга подтверждения
нет вовсе, то есть действие либо не работает, либо (если бы работало) шло бы
без спроса. Задача поднимает пол обратно на всех вводах сразу.

Поведение по вводам после правки одинаково и специальной работы не требует:
переносится **место рендера** одного и того же компонента `hp-confirm`,
разметка, размеры целей нажатия, поведение scrim и футера (#32 §6.2) не
меняются ни на строку. Kiosk отдельного пути не имеет — он рисуется той же
основной веткой, где подтверждение и так работало.

Доказательство — AC8: смок из плана прогоняется в touch-эмуляции, то есть
проверяет ветку онбординга не только мышью.

## Модель данных и миграция

Не применимо.

## i18n

Новых строк нет.

## Критерии приёмки

- **AC1**. В состоянии «нет ни одного пространства» запрос подтверждения
  показывает диалог; «Отмена» резолвит промис `false`, подтверждение — `true`.
  Доказательство: браузерный смок на реальной карточке.
- **AC2**. Тот же инвариант в ветках `fixed_floor` pending и invalid и в ветке
  `!space`. Доказательство: тот же смок, три ветки.
- **AC3**. Удаление сохранённого плана из онбординга доходит до конца:
  подтверждение показано, после согласия план удалён. Доказательство: смок на
  буквальном сценарии issue (`_deleteServerPlan`).
- **AC4**. Открытое подтверждение переживает смену ветки: карточка уходит в
  `fixed_floor` pending при открытом диалоге — диалог остаётся, решение
  по-прежнему резолвит промис. Доказательство: смок.
- **AC5**. В неготовых состояниях (`!_config || !hass`, языковой гейт `warm`)
  запрос отклоняется немедленно: промис резолвится `false`, DOM не трогается.
  Доказательство: юнит/смок с проверкой, что `noChange` из гейта не подменён
  шаблоном.
- **AC6**. Существующее поведение основной ветки не изменилось: начальный фокус
  на «Отмена», Esc отменяет, замена запроса отменяет предыдущий, вложенный
  диалог не ломается. Доказательство: `demo/smoke_danger_confirmation.mjs`
  остаётся зелёным без правок его утверждений.
- **AC7**. Бюджет initial не растёт (правка структурная). Доказательство:
  `npm run bundle:budget` до и после.
- **AC8**. На touch подтверждение в ветке онбординга работает так же, как
  мышью: диалог появляется, тап по «Отмена» резолвит промис `false`, тап по
  scrim не проваливается в план. Доказательство: тот же смок в
  touch-эмуляции (`hasTouch`), как это делают существующие touch-смоки.
- **AC9**. `_tapConfirm` и `_vacCalConfirm` остались в основной ветке и их
  поведение не изменилось. Доказательство: существующие смоки тапа и
  калибровки зелёные без правок их утверждений.

## План автотестов

**Browser smoke** (`demo/smoke_danger_confirmation.mjs` — дополнение):

1. Пустая модель → `_confirmDanger` показывает диалог, «Отмена» → `false`
   (AC1).
2. `fixed_floor` pending / invalid / `!space` → то же (AC2).
3. Онбординг: клик по корзине плана → диалог → согласие → план удалён (AC3).
4. Диалог открыт → карточка уходит в `fixed_floor` pending → диалог на месте,
   решение резолвит промис (AC4).
5. Языковой гейт `warm` → запрос резолвится `false` сразу, `render()`
   по-прежнему возвращает `noChange` (AC5).
6. Тот же сценарий (1) в touch-эмуляции: диалог появляется, тап по «Отмена»
   резолвит `false`, тап по scrim не доходит до плана (AC8).
7. Один `hp-confirm` в DOM — не два (риск двойного рендера ниже).

**Мутант** (`scripts/mutation-gate.mjs`):

- `danger-confirm-back-into-the-branch`: вернуть `hp-confirm` внутрь основной
  ветки → смок AC1 красный.

## Риски

- **`noChange` нельзя оборачивать.** Оборачивание сигнала в шаблон сломает
  оптимизацию Lit и, вероятно, вызовет лишние перерисовки. Смягчение: ветки
  `noChange`/`nothing` остаются нетронутыми, для них — явный отказ запроса;
  AC5 это фиксирует.
- **Двойной рендер диалога.** Если подтверждение окажется и в общей обёртке, и
  в основной ветке, получится два элемента и два источника событий. Смягчение:
  смок проверяет ровно один `hp-confirm` в DOM.
- **Отказ в неготовом состоянии может удивить вызывающего.** Действие
  отклоняется без участия пользователя. Смягчение: это состояние наступает до
  того, как карточка вообще отрисована, то есть нажать было физически нельзя;
  вызывающие уже обрабатывают `false` как «пользователь отказался».

## Откат

Возврат `hp-confirm` в основную ветку — одно перемещение блока. Данные
пользователя не затрагиваются.

## Release-артефакты

- `docs/CHANGELOG.md` / `docs/CHANGELOG.ru.md`: пункт о том, что подтверждения
  работают и до создания первого пространства (User-Visible: yes).
- Скриншоты не меняются: в статике диалог не открыт.