# SPEC-REVIEW-375-r2 Issue: [#375](https://github.com/Matysh/houseplan-card/issues/375) — «Glow в space-card: static-путь потерял кэш-иерархию полной карты» Этап: spec (ревью ТЗ, PROCESS.md §2.4) · трек: `small` (лёгкий, ТЗ в теле issue) Заход: r2 · блокирующих циклов израсходовано 1 из 2 (лимит лёгкого трека — 2, §4) ## 1. Скоуп проверки Раунд r1 (см. ниже) уже прочитал ТЗ целиком и построчно перепроверил все четыре диагноза (К1–К4/V6a–V6d) и AC1–AC6 чтением `dev` на момент r1. Единственная блокирующая находка r1 — отсутствие обязательного раздела «Откат» (Medium, в скоупе) плюс два Low-примечания DoR (миграция/compatibility, touch). Автор ответил правкой тела issue (комментарий Matysh, 2026-08-29T17:46:02Z, «Редакция 2», возврат в `S4-spec-review`). Дельта r1→r2 **полностью локальна**: это единственная правка тела issue между вердиктом r1 и текущим моментом (см. §2 ниже) — не ребейз, не смена контракта, не новая подсистема. По правилу §2.10 разбор в r2 сужен до дельты; AC1–AC6, продуктовая рамка (сценарий, объём К1–К4) и анализ поверхностей унаследованы из r1 без повторной проверки (раздел 4). ## 2. Метод: как восстановлена дельта Вердикт r1 (комментарий `claude`, 2026-08-29T17:43:11Z) **не называет SHA/ревизию тела issue**, на которой он получен — это ровно та находка, которую фиксирует PROCESS.md §2.10 п.1 («SHA в вердикте не назван — это находка»). Для issue-body ТЗ прямого эквивалента git SHA нет, поэтому состояние восстановлено через историю редактирования тела issue (GitHub GraphQL `userContentEdits`, 3 записи правок): - edit `2026-08-29T17:25:45Z` — первая редакция ТЗ (аналитика → ТЗ); - edit `2026-08-29T17:32:37Z` — «редакция 1», ровно то состояние, которое получило вердикт r1 (комментарий вердикта идёт сразу за этой правкой, до следующей); - edit `2026-08-29T17:46:01Z` — «редакция 2», правка **сразу после** вердикта r1 и **до** комментария автора «Возвращаю S4» (17:46:02Z) — это и есть материал r2. `diff` между снимком 17:32:37Z (r1) и снимком 17:46:01Z (r2), сверенным построчно: ```diff -# ТЗ (лёгкий трек, редакция 1) +# ТЗ (лёгкий трек, редакция 2) ... -## 7. Принятые предположения +## 7. Откат + +Обычный `git revert` одного коммита: фича-флагов нет, миграций нет, персистентных +данных нет (все четыре правки — кэши в памяти страницы и non-enumerable свойство +на объекте в памяти). Откат возвращает прежнюю (медленную, но корректную) +картину; parity сцен не зависит от направления. + +**DoR-примечания:** миграция/compatibility — нет (ни одного изменения хранимых +форматов или WS-контрактов); touch — не влияет (`docs/TOUCH-SUPPORT.md` не +задет: правки не касаются ввода). + +## 8. Принятые предположения ... ``` Других расхождений нет (сверено дифф-инструментом построчно; единственная дополнительная разница — завершающий перевод строки, не содержательна). Живое тело issue (`gh issue view 375 --json body`) на момент этого ревью побайтово совпадает со снимком правки 17:46:01Z — после «редакции 2» issue больше не редактировался. ## 3. Закрытие раунда r1 | Находка r1 | Чем закрыта | Где видно | |---|---|---| | Medium (в скоупе): отсутствует обязательный раздел «Откат» (`AGENTS.md`/`PROCESS.md` §5, DoR §2.5) | Добавлен раздел `## 7. Откат` с описанием отката (`git revert`, нет флагов/миграций/персистентных данных) | Тело issue, между «## 6. i18n / Release-артефакты» и (переномерованным) «## 8. Принятые предположения»; правка тела issue 2026-08-29T17:46:01Z | | Low: DoR-пункт «миграция/compatibility» не закрыт явным «нет» | Строка «миграция/compatibility — нет (ни одного изменения хранимых форматов или WS-контрактов)» | Тот же раздел «## 7. Откат», подпункт «DoR-примечания» | | Low: DoR-пункт «влияние на touch» не закрыт явным «нет» | Строка «touch — не влияет (`docs/TOUCH-SUPPORT.md` не задет: правки не касаются ввода)» | Там же | Обе Low-находки и Medium-находка закрыты текстом, а не заявлением: раздел присутствует в теле issue дословно, как процитировано выше. Проверка правдивости добавленных утверждений (не принимается на слово, т.к. это новый текст, ранее не читанный ни одним раундом): - «миграция/compatibility — нет»: сверено с `docs/CONFIG-COMPATIBILITY.md` — реестр посвящён персистентным полям конфига (`space.wall_segments[]`, `expected_rev` и т.д.); ни один из четырёх пунктов К1–К4 (кэш light-графа, `sourceFingerprint` на geometry-объекте, LRU барьерной сцены, кэш `enabledClip`) не касается хранимого формата конфига или WS-контракта записи — это внутримодульные in-memory кэши. Утверждение верно. - «touch — не влияет»: сверено с `docs/TOUCH-SUPPORT.md` — документ описывает политику указателя/hover и editor-vs-View контракт; ни один из К1–К4 не меняет обработку ввода или рендер, видимый пользователю (ТЗ прямо заявляет «видимых изменений нет — только скорость»). Утверждение верно. ## 4. Унаследовано из r1 Без повторной проверки в r2 приняты (документ и ревизия, на которой получен вывод — см. §2 выше, снимок правки issue `2026-08-29T17:32:37Z`; отдельного файла `docs/reviews/SPEC-REVIEW-375-r1.md` в рабочем дереве на момент этого раунда нет — по механике этого конвейера публикующий шаг кладёт его в `docs/reviews/` уже после вердикта, из `REVIEW_DOC` предыдущего раунда; текст вердикта процитирован по комментарию issue): - Все четыре диагноза К1–К4 (V6a–V6d) — не догадка, каждая строка/тест/бюджет подтверждён чтением `dev` на строках `glow-scene.ts:177,319`, `space-render.ts:113-129,501-510,654-671`, `houseplan-card.ts:8455-8461,1815,10267,10296,9383-9393`, `devices.ts:426,602-606`. Дельта r2 не касается этих строк и не меняет ни один из диагнозов — переверять нечего. - AC1–AC6 пронумерованы, проверяемы, доказательства названы (`unit`/мутанты), AC6 корректно привязан к AC1/AC3. Дельта r2 не трогает раздел «3. AC» — ни одной строки в диффе выше. - Продуктовая рамка (раздел «1. Сценарий», «2. Объём») и анализ поверхностей (комментарий аналитики 2026-08-29T17:31:53Z) — не задеты диффом. - Раздел «4. План тестов» и «5. Риски» — не задеты диффом. ## 5. Проверка обязательных разделов (§7.1) — после правки Полный набор для лёгкого трека (issue-тело): проблема · контракт · AC1…ACn с доказательством · откат. Все на месте после «редакции 2»: - проблема — «## Суть» + «## 1. Сценарий»; - контракт — «## 2. Объём» (К1–К4) + «## 1. Сценарий», последняя фраза («видимых изменений нет... parity сохраняется байт-в-байт»); - AC1…AC6 с доказательством — «## 3. AC»; - откат — «## 7. Откат» (новое). DoR-чеклист (§2.5) теперь закрыт полностью явными «нет»/значениями по каждому пункту: миграция/compatibility, touch, i18n (§6: «не задето»), перф (AC5 + план тестов: «бюджет дельта ≈ 0»), release-артефакты (§6: changelog RU+EN), риски (§5), открытых продуктовых вопросов нет (раздел «8. Принятые предположения» — верно оформлен как предположения, а не как замаскированный продуктовый вопрос: обе позиции — технические решения по конкретике реализации, ревьюер вправе их оспорить и не оспаривает, см. ниже). Проверка «Принятые предположения» (§8, ранее §7) на «догадка выдана за решение»: обе позиции — LRU-ёмкость 8 (зеркалит существующий `_lightBarrierPool` полной карты, значение не придумано, а взято из уже работающего кода) и включение К4 в этот же issue (соседняя дешёвая правка, без продуктового компонента) — корректно оформлены как технические допущения. Продуктовых вопросов, которые должны были уйти владельцу, в тексте нет. ## 6. Находки этого раунда Блокирующих (High) находок нет. Medium в скоупе — нет: обе находки r1 закрыты текстом, а не декларацией (§3). Новых находок делта не вносит. Единственное наблюдение процесса (не находка задачи, не блокирует): вердикт r1 не назвал явный якорь ревизии тела issue, на которой он получен (§2.10 п.1, формально применимо и к этапу spec). Дельта тем не менее восстановлена однозначно через историю правок GitHub (`userContentEdits`) — три последовательные правки с точными таймстемпами и полными снимками текста, зазор между вердиктом r1 (17:43:11Z) и следующей правкой (17:46:01Z) не оставляет неоднозначности, какое состояние ревьюер r1 оценивал. Дальнейшего действия не требует; фиксирую как процессное наблюдение на будущее для ревьюеров spec-этапа. ## 7. Что проверено и корректно - Раздел «Откат» присутствует, содержателен, соответствует факту (нет флагов, нет миграций, нет персистентных данных — все четыре правки К1–К4 действительно ограничены in-memory кэшами и non-enumerable свойством, что подтверждено ещё в r1 построчным чтением кода). - Оба DoR-примечания (migration/compatibility, touch) фактически верны — сверено с `docs/CONFIG-COMPATIBILITY.md` и `docs/TOUCH-SUPPORT.md` в этом раунде. - Дельта r1→r2 локальна, не касается AC, объёма, рисков, плана тестов — дальнейшая проверка этих разделов из r1 наследуется законно. - Issue сохраняет метку `small`, критерии лёгкого трека (§5 PROCESS.md) не нарушены правкой (правка добавляет только процессный раздел, не меняет поверхность/риск/сложность). ## 8. Чего не проверял и почему - Код (`src/glow-scene.ts`, `src/space-render.ts` и т.д.) — не применимо на этапе spec: реализация ещё не начата, issue не покидал `S3/S4`, кода по этому issue в `dev` нет. Гейты `tsc`/`test`/`build`/смоки/инварианты модели относятся к этапу code-review (§2.7, §8 PROCESS.md) и будут прогнаны там. - Повторное построчное чтение `dev` под K1–K4 — не требовалось: дельта r1→r2 не касается этих строк, диагнозы уже перепроверены в r1 (§4). - Содержательный технический спор с ревьюером r1 по поводу самих AC — предмета для спора нет, дельта его не вносит. ## 9. Вердикт Зелёный. Обе находки r1 закрыты текстом по месту, дельта локальна и не вносит новых находок, обязательные разделы ТЗ (§7.1) и DoR-чеклист (§2.5) закрыты полностью. Issue готово к переходу в «Готово к разработке» (`S5-ready`).