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

SPEC-REVIEW-375-r2

Issue: #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), сверенным построчно:

-# ТЗ (лёгкий трек, редакция 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).