houseplan-card/docs/reviews/SPEC-REVIEW-577-r2.md

# SPEC-REVIEW-577-r2

Issue: #577 «Солнечные лучи: выбирать внутренние или внешние углы окон»
Этап: ТЗ на ревью (PROCESS.md §2.4), трек: полный (аналитика #577 явно называет
провал критериев `small`: новый UX-контракт + новое compatibility-поле).
Заход: r2 · блокирующих циклов израсходовано (до этого вердикта) 1 из 4
(зелёный вердикт бюджет не тратит, #227).

## Материал ревью

Тело issue #577, раздел `## ТЗ`, на момент разбора. Метка на issue —
`S4-spec-review`, `P3`, `feature`. Разбор ведётся по дельте (PROCESS.md §2.10):
предыдущий раунд — `docs/reviews/SPEC-REVIEW-577-r1.md`, вердикт жёлтый,
материал зафиксирован в его блоке «Материал раунда» (тело issue,
sha256 `3263b8c8be2272a314f407b5fa5713fa93150e3c1d59cf2de100dd640f46915a`).

## Объявление дельты

Правки в тело issue вносятся напрямую через GitHub (не через git), поэтому
дельта восстановлена не диффом файла, а сверкой текста, процитированного в
r1, с текущим телом issue, плюс авторский комментарий-хендофф между раундами:

> «Исправлено по SPEC-REVIEW r1: в обязательные release-артефакты #577
> добавлены `docs/WALL-THICKNESS.md` §5 и `docs/CONFIG-COMPATIBILITY.md`...
> Остальной контракт и AC не менялись.» (Matysh, 2026-09-14T20:39:37Z)

Единственное текстовое изменение — раздел `### Release-артефакты`. Было (по
цитате из r1, находка Medium):

```
- docs/CHANGELOG.md/.ru.md, docs/SUN.md, docs/USER-GUIDE.ru.md, docs/TESTING.md, i18n, golden, docs screenshots
```

Стало (текущее тело issue):

```
- `docs/CHANGELOG.md` и `docs/CHANGELOG.ru.md` со ссылкой на #577;
- `docs/SUN.md`, `docs/WALL-THICKNESS.md` §5, `docs/CONFIG-COMPATIBILITY.md`, `docs/USER-GUIDE.ru.md`, `docs/TESTING.md`;
- i18n en/ru/de/fr;
- golden baseline/manifest — только через полный Linux-артефакт и reviewed acceptance, если добавляется новый кадр;
- docs screenshots manifest/кадры — по результату штатной проверки freshness;
- отдельные security-материалы не требуются.
```

Дельта локальна: два названия документов дописаны в один существующий
маркированный пункт списка. Контракт поведения (пп. 1–10), UX, модель данных
и совместимость, i18n, AC1–AC9, план автотестов, риски, откат, «Принятые
предположения» — весь остальной текст ТЗ, процитированный в r1 построчно (см.
раздел ниже), совпадает с текущим телом issue дословно. Дельта не меняет
контракт поведения, не задевает новую подсистему и по объёму несопоставима с
исходной задачей — полный повторный разбор не требуется, разбор по AC ведётся
по границе, которую дельта фактически задевает (только состав раздела
Release-артефактов).

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

| Находка r1 | Чем закрыта | Где это видно |
|---|---|---|
| Medium (в скоупе): раздел «Release-артефакты» не называет `docs/WALL-THICKNESS.md` §5 и `docs/CONFIG-COMPATIBILITY.md`, хотя оба документа прямо и безусловно описывают поведение, которое режим `outer` меняет | Оба документа дописаны в список release-артефактов тела issue | Тело issue #577, раздел `### Release-артефакты`, вторая строка: «`docs/SUN.md`, `docs/WALL-THICKNESS.md` §5, `docs/CONFIG-COMPATIBILITY.md`, `docs/USER-GUIDE.ru.md`, `docs/TESTING.md`» + комментарий автора 2026-09-14T20:39:37Z, явно называющий содержание правки для каждого из двух документов (что именно будет обновлено в WALL-THICKNESS.md §5 и что зарегистрировано в CONFIG-COMPATIBILITY.md) |

Проверено не заявлением автора, а прямым чтением текущего тела issue: оба
названия документа присутствуют в списке, оба реально существуют в дереве
репозитория (`docs/WALL-THICKNESS.md` содержит раздел `## 5. Sun`,
`docs/CONFIG-COMPATIBILITY.md` — существующий реестр additive-полей), то есть
ссылки не битые и указывают на верный раздел.

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

Без повторной проверки в r2 принято всё, что r1 (`docs/reviews/SPEC-REVIEW-577-r1.md`,
материал — тело issue с sha256 `3263b8c8be2272a314f407b5fa5713fa93150e3c1d59cf2de100dd640f46915a`)
разобрал построчно и признал корректным, поскольку дельта этого раунда текст
не затрагивает:

- обязательные разделы §7.1 присутствуют все, продуктовая рамка (сценарий +
  «что человек увидит») отвечает на оба обязательных вопроса без терминов
  реализации;
- default/fail-closed контракта (п. 2) согласован с прецедентом `bg_mode`;
- геометрия `inner` (п. 3) дословно совпадает с каноном `docs/WALL-THICKNESS.md`
  §5 и `docs/SUN.md`;
- терминология UX-раздела («Солнце в окнах», «оконный тоннель») сверена с
  живым i18n-ключом и `docs/USER-GUIDE.ru.md`, а не изобретена;
- технический риск наружного источника назван автором и покрыт AC4 через уже
  существующий примитив `opening-tunnel`;
- «Принятые предположения» корректно ловят единственную реальную продуктовую
  неоднозначность (укорочение видимой длины луча внутри комнаты у толстой
  стены в `outer`);
- не-скоуп не размыт;
- AC1–AC9 пронумерованы, у каждого указан способ доказательства, формулировки
  проверяемы;
- уровень детализации i18n соответствует принятой практике архива.

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

## Находки

Нет. Дельта — точечная правка одного маркированного пункта, добавляющая два
корректных названия существующих канонических документов; текст правки не
вносит новой двусмысленности, не меняет контракт, AC или скоуп и не создаёт
нового расхождения документации с кодом.

## Что проверено и корректно (в рамках дельты этого раунда)

- Оба добавленных названия документов существуют в репозитории и указывают на
  реальный раздел (`docs/WALL-THICKNESS.md` содержит `## 5. Sun`).
- Формулировка правки не переносит фактическое обновление канона на более
  позднюю задачу без следа: авторский комментарий явно называет, что именно
  изменится в каждом документе после реализации AC4 и модели данных, поэтому
  требование r1 «эти два документа обязаны быть обновлены этой же задачей», а
  не просто упомянуты, выполнено по существу, а не формально.
- Остальной текст ТЗ (контракт, AC, риски, откат, i18n, план автотестов)
  не изменился — сверено построчно с цитатами r1, дельта их не задевает.

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

- Не проверял `scripts/config-field-registry.mjs` построчно и не запускал
  `npm run audit:config` — на этапе ревью ТЗ кода нет, гонять нечего; это
  унаследовано из r1 без изменений.
- Не проверял историю правок тела issue через GitHub API: `timeline`
  (`gh api repos/Matysh/houseplan-card/issues/577/timeline`) не вернул
  событие `edited` для этой правки (GitHub не всегда экспонирует такие
  события через этот эндпоинт для ботов/API-редактирования), поэтому дельта
  восстановлена сверкой цитат r1 с текущим текстом плюс авторский
  комментарий-хендофф, а не третьей стороной подтверждённым диффом. Это не
  ослабляет вывод: сам факт добавления двух названий документов виден прямым
  чтением текущего тела issue и совпадает с тем, что описал автор.
- Не запускал никаких гейтов (typecheck/test/build/golden) — кода ещё нет.
- Английские/немецкие/французские i18n-тексты не сформулированы — ожидаемый
  на этом этапе уровень детализации, унаследовано из r1.

## Вердикт

Зелёный. Единственная находка r1 (Medium, в скоупе) закрыта точным
добавлением двух названных документов в раздел release-артефактов; остальной
текст ТЗ не изменился и остаётся тем, что r1 признал корректным. Новых
находок дельта не вносит.

`Вердикт: зелёный · заход r2 · блокирующих циклов 1/4 · High: 0 · Medium: 0`

---

<!-- material-anchors: сгенерировано конвейером (#414) -->

## Материал раунда

- Ветка: `issue/577-sun-ray-window-corners`, коммит `2ba13cf34dba` — ребейз его осиротит, и это нормально: ниже якоря, которые ребейз не меняет.
- Дерево материала: `4c64cd0314fa64ff8b1e44dac70b22b4d4a694ff`
  ```
  git log --all --format='%H %T' | grep 4c64cd0314fa
  ```
- Тело issue: `ebb1c05540c7191db0b4a76841f19b1371239caa0d41798ba82ec319116b32fc`
- Вердикт конвейера: `green` · High 0