houseplan-card/docs/reviews/SPEC-REVIEW-354-r1.md

# SPEC-REVIEW-354-r2

- **Issue:** https://github.com/Matysh/houseplan-card/issues/354
- **Этап:** ревью ТЗ (PROCESS.md §2.4), лёгкий трек (`small`)
- **Заход:** r2 · блокирующих циклов израсходовано 1 из 2 (лимит ТЗ на лёгком треке — 2; r1 был жёлтым и потратил 1 цикл — §4/#227)
- **ТЗ:** тело issue #354, «Ревизия 2» (файл в `docs/specs/` отсутствует — корректно для `small`)
- **SHA на момент ревью:** `149b2af7` (`dev`, рабочее дерево чистое; с момента r1 (`77302eaf`) в код не внесено ни одного продуктового коммита — единственный новый коммит `149b2af7` кладёт документ ревью r1, продуктового/тестового кода не касается)
- **Вердикт: зелёный**

## Примечание о нумерации захода

Стартовые данные этой сессии указывали «Заход: r1 · блокирующих циклов
израсходовано 0 из 2». Это не соответствует фактическому состоянию: в
`docs/reviews/SPEC-REVIEW-354-r1.md` (закоммичен `149b2af7`) и в комментариях
issue уже есть завершённый раунд r1 — жёлтый вердикт от `claude` (комментарий
`IC_kwDOTOcLQM8AAAABRRPAyw`, 2026-08-28T14:40:01Z, SHA `77302eaf`), за которым
последовала правка автора («Ревизия 2 ТЗ по r1», комментарий
`IC_kwDOTOcLQM8AAAABRRPa0g`) и возврат метки `S4-spec-review`. Раунд, который
разбирает эта сессия, — второй по факту (`r2`), а не первый; бюджет цикла к
этому моменту уже потратил 1 из 2 (жёлтый вердикт r1 расходует бюджет по §4).
Документ поэтому назван и пронумерован как `r2`, вопреки стартовым данным —
иначе он затёр бы уже существующий `SPEC-REVIEW-354-r1.md` или конфликтовал
бы с ним по номеру, ровно тот сценарий, от которого предостерегает сам номер
захода. Расхождение стартовых данных со стоянием репозитория — само по себе
не блокирует эту задачу, но стоит показать тому, кто обслуживает конвейер.

## Скоуп

Без изменений относительно r1: собрать продакшн-`LANGUAGE_RUNTIME` в
`src/i18n/registry.ts` как `new LanguageRuntime(...)` вместо рукописного
литерала (`germanDictionary`/`germanPending`/`germanFailed`/`settleGerman`),
чтобы существующий `test/i18n-runtime.test.mjs` действительно проверял код
продакшна, плюс попутный (N7) тост при отказе загрузки словаря локали.
Ревизия 2 не меняет предмет задачи и не расширяет её — правит формулировку
одного контракта (К2) и переименовывает один i18n-ключ. Конфликта со
`docs/SCOPE.md` по-прежнему нет (см. SPEC-REVIEW-354-r1.md, раздел «Скоуп» —
наследуется, ниже).

## Дельта r1 → r2

`git diff <SHA r1>..HEAD` не показателен: SHA r1 (`77302eaf`) и текущий
(`149b2af7`) отличаются только doc-коммитом ревью r1, продуктового кода нет
вообще (стадия ТЗ). Предмет дельты — правка тела issue #354, зафиксированная
автором как «Ревизия 2 ТЗ по r1» (комментарий `IC_kwDOTOcLQM8AAAABRRPa0g`).
Сверено построчно с текстом, процитированным в `SPEC-REVIEW-354-r1.md`:

1. **К2** — было (цит. по r1, находка M1): «Тост показывается ... Карточка
   подписывается при подключении... показывает тост» (без указания, какая из
   четырёх поверхностей рендер-гейта). Стало: «Тост показывается ТОЛЬКО в
   `houseplan-card` (View — единственная поверхность с тост-инфраструктурой
   `_showToast`)... Остальные три поверхности рантайма (`space-card`,
   GUI-редакторы обеих карточек) остаются при `console.warn`, как сейчас, —
   тост-инфраструктура там не заводится.»
2. **Ключ тоста** — было `i18n.load_failed` (находка L1). Стало
   `toast.locale_load_failed`, в К2 и в AC4.
3. Остальной текст (К1, К3, AC1–AC3, «Откат», трейлер `User-Visible: yes`)
   не изменился — сверено посимвольно с цитатами в `SPEC-REVIEW-354-r1.md`
   (разделы «Что проверено и корректно», «Скоуп»).

Дельта локальна (правка формулировки одного контракта плюс переименование
одного ключа), не задевает новую подсистему, не меняет контракт поведения
сверх уже согласованного в r1, по объёму несопоставима с исходной задачей —
условие «разбор остаётся полным» (PROCESS.md §2.10) не наступает. Разбор
этого раунда ограничен дельтой: заново проверялись только К2 (N7) и ключ
тоста — единственное, что дельта задевает.

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

1. Прочитано текущее тело issue #354 целиком, сверено с цитатами r1 —
   найдены ровно две правки (см. «Дельта» выше), больше отличий нет.
2. Прочитан комментарий владельца «Ревизия 2 ТЗ по r1» — подтверждает, что
   обе правки целенаправленно закрывают M1 и L1, а не что-то другое.
3. Перечитан текст К2 revision 2 на однозначность: названа ровно одна
   поверхность (`houseplan-card`/View), явно перечислены три поверхности,
   остающиеся при `console.warn`, явно сказано «тост-инфраструктура там не
   заводится» — двух прочтений эта формулировка больше не допускает.
4. `grep -n '"toast\.' src/i18n/en.json` — подтверждён неймспейс `toast.*`
   (40+ существующих ключей); `grep -rn "locale_load_failed\|i18n.load_failed"
   src/ test/ demo/` — пусто: новый ключ не конфликтует с существующим кодом
   и ещё не реализован (ожидаемо для стадии ТЗ).
5. `grep -n "6.3\|houseplan-space-card" docs/specs/348-german-localization.md`
   — подтверждён раздел «6.3. Render gate» и список из четырёх поверхностей,
   на который опирается формулировка К2 (та же ссылка, что использовал r1).
6. `git log 77302eaf..HEAD --oneline` — один коммит (`149b2af7`, doc r1),
   без изменений в `src/**`/`test/**`: код и его состояние идентичны
   зафиксированным в r1, повторная проверка К1/К3/AC1–AC3 по коду не нужна.

Гейты (`tsc`/`test`/`build`) не гонялись — стадия ревью ТЗ, кода по задаче ещё
нет; как и в r1, это не пропуск, а неприменимость этапа.

## Находки

Нет. High: 0, Medium: 0, Low: 0.

Обе находки r1 закрыты правкой текста, новых находок дельта не вносит.

## Закрытие раунда r1

| Находка r1 | Чем закрыта | Где это видно |
|---|---|---|
| **M1** (Medium, в скоупе) — К2 не называл, на какой из четырёх поверхностей рендер-гейта показывается тост N7; формулировка «Карточка» в единственном числе была совместима с двумя разными объёмами работы. | К2 переписан: «Тост показывается ТОЛЬКО в `houseplan-card` (View...)... Остальные три поверхности рантайма (`space-card`, GUI-редакторы обеих карточек) остаются при `console.warn`, как сейчас, — тост-инфраструктура там не заводится.» Формулировка совпадает с предложенным в r1 вариантом по умолчанию почти дословно. | Тело issue #354, раздел «Контракт», К2, первый и последний абзацы. |
| **L1** (Low, зафиксирована) — ключ `i18n.load_failed` был единственным вне пространства `toast.*`. | Ключ переименован в `toast.locale_load_failed` — и в К2, и в AC4. | Тело issue #354, К2 («новым ключом `toast.locale_load_failed`») и AC4 («текстом `toast.locale_load_failed`»). |

## Унаследовано из r1

Без повторной проверки в этом раунде — код и тесты с r1 не менялись
(единственный новый коммит — doc-коммит ревью, класс C), проверка велась
только над текстом ТЗ:

- **Скоуп задачи и соответствие `docs/SCOPE.md`** — принято по
  `SPEC-REVIEW-354-r1.md`, раздел «Скоуп» (SHA `77302eaf`).
- **К1 (замена литерала на `new LanguageRuntime(...)`) реализуема без
  побочных поломок** — все четыре вызывающих места используют только
  контракт `state/dictionary/ensure` — принято по `SPEC-REVIEW-354-r1.md`,
  раздел «Что проверено и корректно», пп. 1–2 (SHA `77302eaf`, строки кода
  `houseplan-card.ts:10713`, `editor.ts:118`, `space-card.ts:766`,
  `space-editor.ts:60`).
- **АС1–АС3 однозначны и механически проверяемы** (grep, instanceof-юнит,
  мутационный тест на К3) — принято по `SPEC-REVIEW-354-r1.md`, раздел «Что
  проверено и корректно» (SHA `77302eaf`); текст АС1–АС3 в ревизии 2 не
  менялся (сверено построчно, см. «Дельта» выше).
- **Паритет-тесты (`test/i18n.test.mjs`) действительно стерегут новый ключ
  независимо от его имени** — принято по `SPEC-REVIEW-354-r1.md`, пп. 7 и
  L1 (SHA `77302eaf`); вывод не зависит от конкретного имени ключа, поэтому
  переименование в `toast.locale_load_failed` его не меняет.
- **Существующий смок `demo/smoke_german_locale.mjs` уже содержит сценарий
  «оба ретрая упали → English»**, в который AC4 добавляет проверку тоста без
  новой инфраструктуры смоков — принято по `SPEC-REVIEW-354-r1.md`, п. 8
  (SHA `77302eaf`).
- **Подписка/отписка (К2) соответствует принятой конвенции
  `subscribeXxx(...)`** — принято по `SPEC-REVIEW-354-r1.md`, п. 9 (SHA
  `77302eaf`).
- **Открытый нефинирующий пункт для код-ревью**: не проверялось, как
  `subscribeLanguageLoadFailures`-колбэк получит код локали `de` из
  `warn(message, error)` (сигнатура класса передаёт только текст). Не
  находка (решаемо замыканием при единственном сегодня ленивом языке), но
  стоит явно проговорить на код-ревью, если добавится второй ленивый язык —
  перенесено из `SPEC-REVIEW-354-r1.md`, раздел «Чего не проверял».

## Что проверено и корректно (r2, по дельте)

- К2 revision 2 однозначен: ровно одна поверхность для тоста
  (`houseplan-card`), явно перечислены три поверхности без тоста, явно
  сказано, что новая тост-инфраструктура на них не заводится — двух
  прочтений формулировка не допускает, находка M1 закрыта по существу, а не
  косметически.
- Новый ключ `toast.locale_load_failed` следует существующей конвенции
  именования тостов (проверено grep по `src/i18n/en.json`, 40+ ключей в том
  же пространстве) и не конфликтует с уже существующим кодом (grep пуст).
- Правка не расширяет скоуп и не вводит новый UX-контракт: критерии лёгкого
  трека (§5 PROCESS.md) по-прежнему выполнены — ревизия 2 их не колеблет
  (одна поверхность тоста явно зафиксирована как единственная, а не
  расширена на четыре).
- АС4 (после ревизии) по-прежнему проверяем механически: юнит на
  `subscribeLanguageLoadFailures`, смок `smoke_german_locale` с проверкой
  `card._toast`, мутационный тест на «тост выброшен».

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

- Код по задаче ещё не написан (стадия ТЗ) — гейты `tsc`/`test`/`build` не
  запускались, как и в r1; на этой стадии они неприменимы.
- Не проверял заново K1/K3/AC1–AC3 по коду — код с момента r1 не менялся
  (см. «Дельта» и «Унаследовано из r1» выше), текст этих пунктов ТЗ тоже не
  менялся.
- Не проверял реальные тексты переводов для `toast.locale_load_failed`
  (en/ru/de) — их ещё нет; сверка с паритет-тестами и glossary
  `docs/specs/348-german-localization.md` — задача код-ревью.

## Итог

Вердикт **зелёный**: обе находки r1 (M1 Medium, L1 Low) закрыты точечной
правкой текста, дельта не вносит новых находок и не задевает то, что r1 уже
принял. Issue переходит в `S5-ready`.