# SPEC-REVIEW-204-r1

- Issue: [#204](https://github.com/Matysh/houseplan-card/issues/204)
- ТЗ: [docs/specs/204-space-create-display-defaults.md](../specs/204-space-create-display-defaults.md)
- Ветка: `issue/204-space-create-display-defaults`, коммит `f703242`
- Трек: обычный (метка `small` не выставлена — файл ТЗ обязателен и присутствует)
- Вердикт: **зелёный**

## Скоуп ревью

Этап `spec` по PROCESS.md §2.4: проверяется ТЗ на выполнимость, однозначность
AC и отсутствие догадок, выданных за решения. Продуктовый код не менялся —
диапазон `origin/dev..HEAD` содержит один docs-коммит (`204-*.md` +
запись в `docs/specs/README.md`), что соответствует стадии `S4-spec-review`.

## Как проверялось

1. Прочитаны в порядке: `docs/SCOPE.md`, `AGENTS.md`, `PROCESS.md` (§2.4, §7.1,
   §7.2), тело issue #204 и оба комментария (аналитика+вопросы, ТЗ готово),
   timeline issue (`gh api .../timeline`) — подтверждено, что `blocked` снят
   владельцем (17:08:25) до публикации ТЗ (17:12:03), т.е. Q1/Q2 закрыты не
   умолчанием, а явным действием с правом записи.
2. Сверены обязательные разделы §7.1 (сценарий, что человек увидит, проблема,
   скоуп/не-скоуп, контракт, UX, данные/миграция, i18n, AC, тест-план, риски,
   откат, release-артефакты) — все присутствуют и в правильном порядке.
3. Корневая причина ТЗ (§3) сверена построчно с кодом на ветке:
   - `src/houseplan-card.ts:13232-13251` (`_openSpaceDialog('create')`) —
     `showBorders:false, showNames:false` подтверждено;
   - `src/houseplan-card.ts:13605-13625` (`_openNextImport`) — тот же дефолт
     подтверждён;
   - `src/houseplan-card.ts:19521,19548` — радиокнопки File/Draw меняют только
     `source`, переключатели не трогают;
   - `src/houseplan-card.ts:13476-13477` — скрытая ветка
     `show_borders: draw && d.mode === 'create' ? true : d.showBorders` (и
     аналогично `show_names`) подтверждена буквально;
   - `src/logic.ts:1238-1244` (`spaceDisplayOf`) — реальный runtime-дефолт
     `s.show_borders ?? noPlan` подтверждает, зачем скрытая ветка вообще
     появилась (сохранить видимый план без фона с включённой разметкой), и
     объясняет, почему File-create с `false/false` не деградирует: `plan_url`
     на этот момент уже отличен от null, `noPlan` не участвует.
   Причина не является догадкой — она voспроизведена по коду, а не
   предположена.
4. Терминология переключателей сверена с `src/i18n/ru.json:353-354`
   (`"Всегда отображать границы комнат"`, `"Отображать названия комнат
   (перетаскиваются)"`) — совпадает буквально с телом issue и с ТЗ.
   `docs/UX-MODES.md` (таблица «Display section», строки 119-147) не
   противоречит: она описывает общий backend-дефолт (`?? noPlan`), ТЗ трогает
   только create-dialog UX и Save, а не резолвер — это explicitно вынесено в
   «Non-scope» (§5) и совпадает с уже закрытым #203 (тот же резолвер, другое
   поле, не пересекается).
5. Проверено, что #203 закрыт (`state: CLOSED`) и правда не про создание
   пространства — исключает риск дублирования и конфликта non-scope.
6. Проверены трейлеры коммита `f703242`: `Issue: #204`, `User-Visible: no` —
   корректно для docs-only коммита на этапе spec.
7. Проверена запись в `docs/specs/README.md` — индекс обновлён, ссылка на
   правильный файл, порядок строк в таблице уже был не отсортирован до этого
   коммита (не новая проблема, см. «Не находки»).

## Находки

Нет ни High, ни Medium, ни Low.

## Что проверено и корректно

- **Персона и сценарий (§1)**: администратор, создание пространства / шаг
  Floors-Areas onboarding — соответствует J4/J6 `docs/SCOPE.md`, скоуп по
  размеру задачи (одна поверхность — create-dialog) корректен для полного
  трека без метки `small` (сложность 4/10 по аналитике, что уже выше порога
  `small` ≤3 — трек выбран верно).
- **До/после (§2)** сформулировано в пользовательских терминах, без деталей
  реализации.
- **Контракт (§6)** описывает конечный автомат `displayTouched` без
  противоречий: 6 пунктов покрывают init, source-switch до/после touch,
  Save, Cancel — не осталось необозначенных переходов (File→Draw→File с
  touched, повторный File→Draw и т.д. выводятся из п.2 и п.4 однозначно).
- **AC1–AC10 (§9)** пронумерованы, каждый привязан к способу доказательства
  (smoke/unit/mutation/regression), формулировки проверяемы без домысливания
  — включая мутационный гейт AC9, что соответствует существующей практике
  проекта (`scripts/mutation-gate.mjs`, см. `docs/TESTING.md`), а не новой
  выдумке.
- **Non-scope (§5)** явно исключает резолвер #203, миграцию, i18n, дизайн
  диалога — предотвращает расширение скоупа при реализации.
- **Предположения (§13)** отделены от решений: имя `displayTouched`, выбор
  smoke-файла и общий helper прямо помечены «технически, менять свободно»,
  продуктовые Q1/Q2 закрыты явным ответом владельца (снятие `blocked`) до
  публикации ТЗ.
- **Release-артефакты (§12)**: `User-Visible: yes` для будущей реализации
  корректно предполагает оба changelog, `USER-GUIDE.ru.md`, `TESTING.md`,
  `STATUS.md` — соответствует DoD §2.5.
- **Откат (§12)**: явно описан (revert коммита возвращает скрытую подмену) —
  пункт DoR «откат» закрыт.

## Чего не проверял

- Не проверялась реализация — её ещё нет (стадия spec, диапазон дальше
  докс-коммита пуст). Гейты `typecheck`/`test`/`build` не запускались:
  предмета для них на этой стадии нет (класс A/B файлы не менялись).
- Не проверялся сам механизм существующего смока
  `demo/smoke_space_settings.mjs` на предмет того, легко ли он расширяется
  под AC1–AC8 — это техническое решение автора кода (§13 п.3 ТЗ), не предмет
  ревью ТЗ.
- Не запрашивался `docs/specs/040-floor-area-onboarding.md` на полноту вне
  грепа по `show_borders/show_names/default` — грепом подтверждено отсутствие
  конфликтующих утверждений про defaults, дальше документ не читался целиком.

## Не находки (сознательно не заведены)

- Таблица `docs/specs/README.md` уже была не отсортирована по номеру issue до
  этого коммита (`150` после `157`, `201/203/186` в произвольном порядке) —
  вставка `#204` между `#197` и `#201` не создаёт новую проблему, это
  косметика существующего файла, не relevant к ТЗ #204.