Files
houseplan-card/docs/reviews/SPEC-REVIEW-231-r2.md
T
2026-08-22 15:24:00 +00:00

14 KiB

SPEC-REVIEW-231-r2

  • Issue: #231 — декоративный слой виден поверх заливок комнат
  • ТЗ: docs/specs/231-decor-layer-order.md
  • r1 ревьюировано на: commit e023adb (см. docs/reviews/SPEC-REVIEW-231-r1.md, зафиксирован в заголовке документа; дополнительно подтверждён комментарием автора «Предыдущий reviewed SHA ТЗ: e023adb»)
  • Дельта r1→r2: commit 9410be6 («docs(spec): prove decor above room hover»)
  • Заход: r2 · блокирующих циклов израсходовано 1 из 4
  • Вердикт: зелёный · High: 0 · Medium: 0

Скоуп ревью

Второй заход, разбор по дельте (PROCESS.md §2.10). r1 вернул ровно одну находку — Medium M1 (пробел в доказательстве позиции decor относительно room hover fill). Дельта git diff e023adb..9410be6 -- docs/specs/231-decor-layer-order.md — единственный файл, 13 строк, два хунка: правка AC2 (§14) и добавление в план автотестов (§15.1, §15.2). Никакого ребейза на ушедший вперёд dev, смены контракта поведения или новой подсистемы: git show --stat 9410be6 подтверждает ровно один изменённый файл. Дельта локальна и несопоставима по объёму с исходным ТЗ (352 строки) → по правилу §2.10 полный повторный разбор не требуется, кроме AC2 и того, что дельта задевает.

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

  1. Найден вердикт r1 в комментариях issue (2026-08-22T15:18:46Z, жёлтый, заход r1, блокирующих циклов 0/4, High 0, Medium 1) и приложенный документ docs/reviews/SPEC-REVIEW-231-r1.md (коммит d2e7626), где reviewed SHA назван явно в заголовке — e023adb. Разночтения между комментарием-вердиктом (SHA не упомянут в тексте самого комментария) и документом (SHA назван) нет практического значения: документ — канонический артефакт ревью, комментарий — его краткое резюме; процесс не требует дублировать SHA в самом комментарии.
  2. Объявлена дельта: git diff e023adb..9410be6 -- docs/specs/231-decor-layer-order.md и git show --stat 9410be6 — единственный файл, только §14/AC2 и §15.1/§15.2.
  3. Прочитан комментарий автора о правке (2026-08-22T15:20:09Z): заявлено закрытие M1 через правку AC2, добавление DOM-order + raster проверки и включение smoke_glow.mjs в целевой список гейтов. Проверено построчно ниже, а не принято на слово.
  4. Сверены реальные имена классов/методов, на которые ссылается новая формулировка AC2/§15.2, с фактическим кодом:
    • .room-hover-fill-layer — существует (src/houseplan-card.ts:11865, <g class="room-hover room-hover-fill-layer" ...>);
    • .decorlayer — существует (src/houseplan-card.ts:10094);
    • compareDocumentPosition между hover-fill-layer и другим слоем — уже реальный работающий паттерн в demo/smoke_glow.mjs:245-261 (hoverFillLayer.compareDocumentPosition(glowLayer) & Node.DOCUMENT_POSITION_FOLLOWING), то есть предложенное расширение того же ассерта на .decorlayer технически осуществимо, а не гипотетическая заявка.
  5. Проверено соответствие новой формулировки AC2 нормативному §8.1, который сам не менялся дельтой и уже требовал этот порядок в r1 (сама находка M1 была о разрыве между §8.1 и AC, а не о неверном §8.1) — теперь AC2 текстуально покрывает то же, что §8.1: room hover fill → обычный тоннель → Glow-base комнаты → Glow-base тоннеля → decor.
  6. Проверено, что доказательство в §15.2 не сводится к одному compareDocumentPosition — явно требуется дополнительный raster sample «decor внутри подсвеченной комнаты», что соответствует общему правилу того же раздела («один compareDocumentPosition без пиксельного/поведенческого assert не считается доказательством AC1–AC3») и снимает риск M1-сценария (decor вставлен раньше hover fill, но формально после тоннелей — тест теперь ловит именно эту перестановку и по DOM, и по пикселю).
  7. Проверено AC5 (documented mutant, «краснеет по AC1/AC2») — не менялся текстом, но теперь корректно покрывает и новую часть AC2 (hover), так как ссылается на AC2 целиком, а не на прежнюю более узкую формулировку.
  8. Проверено, что правка не расширяет и не сужает скоуп: §6/§7 (входит/не входит), §8.2 (Glow blend, открытый технический риск), §8.3/§19.1 (решение владельца по Q1), §9 (hide/editor/backdrop parity), §10 (touch/UX), §11 (данные/i18n), §16 (риски), §17 (откат), §18 (release-артефакты) — во всех этих разделах дельта не тронула ни строки; в них нет ссылок на изменённый текст AC2/§15, которые дельта могла бы сделать противоречивыми.
  9. Гейты кода не прогонялись — продуктовый код не менялся ни в дельте, ни в исходном ТЗ; на этапе ТЗ это не относится к предмету ревью (см. также §10 Чего не проверял r1, неизменное основание). git diff --check и node scripts/check-docs.mjs --external, упомянутые автором, — гигиена коммита ТЗ, не предмет спецификационного ревью.

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

Находка r1 Чем закрыта Где это видно
M1 — §8.1 требует decor после room hover fill, но ни AC1, ни AC2, ни AC3 это не проверяли; smoke_glow.mjs умел сравнивать DOM-порядок hover-fill-layer, но не упоминал .decorlayer AC2 (§14 п.2) переписан: явно требует «decor следует в DOM и визуально лежит после room hover fill, обычного тоннеля, Glow-base комнаты и Glow-base тоннеля; hover-подсветка не тонирует decor». План автотестов (§15.1) добавляет node demo/smoke_glow.mjs в целевой список гейтов. Обязательная fixture (§15.2) добавляет «активный room hover с существующей .room-hover-fill-layer; целевой assert проверяет compareDocumentPosition от неё к .decorlayer и raster sample на decor внутри подсвеченной комнаты» docs/specs/231-decor-layer-order.md §14 AC2 (строки 225-229) и §15.1/§15.2 (строки 266, 284-286); дельта git diff e023adb..9410be6

Закрытие проверено не на слово автора: имена классов и метод сравнения DOM-позиции существуют в реальном коде и в уже работающем аналогичном ассерте (см. «Как проверялось», пп. 4). Формальный сценарий обхода из M1 («decor вставлен до hover fill, но AC2 всё равно зелёный, потому что тоннели/Glow-base идут после него») теперь не проходит: новый DOM-order assert проверяет позицию .decorlayer непосредственно относительно .room-hover-fill-layer, а не только относительно тоннелей.

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

Принято без повторной проверки, по docs/reviews/SPEC-REVIEW-231-r1.md @ SHA e023adb — дельта r2 не касается ни одного из этих разделов:

  • продуктовая рамка (сценарий, персона, «что человек увидит до/после», привязка к J1 из docs/SCOPE.md) — §1, §2;
  • подтверждённая по коду причина дефекта (§3) и приоритет нормативных источников (§4);
  • цели и scope/не-scope (§5, §6, §7), включая явное исключение per-object флага «под планом»;
  • нормативный порядок слоёв §8.1 (сама граница, а не её покрытие тестами), Glow-риск §8.2 с корректной эскалацией вместо молчаливого решения, компат старого decor и решение владельца по Q1 §8.3;
  • hide/editor/backdrop parity §9, touch/UX §10, данные/миграция/i18n §11, архитектура и зоны изменений §12, performance/security §13;
  • AC1, AC3, AC4, AC6, AC7, AC8 (§14) — их текст и доказательства дельта не меняла;
  • golden-план §15.3, риски §16, откат §17, release-артефакты §18, принятые предположения §19.

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

  • AC2 больше не расходится с §8.1: нормативное требование и критерий приёмки теперь говорят об одном и том же порядке.
  • Доказательство AC2 — не голословное «DOM-order», а конкретный метод (compareDocumentPosition между двумя названными, существующими в коде классами) плюс обязательный пиксельный/поведенческий assert, как требует общее правило §15.2 для AC1–AC3.
  • smoke_glow.mjs включён в целевой список гейтов реализации (§15.1) — устраняет ровно тот пробел, который отметил r1 (существующий тест умел сравнивать hover-позицию, но не был назван обязательным для этой задачи).
  • Дельта не вводит новых догадок: формулировка AC2 не утверждает ничего, что не вытекало бы уже из §8.1 и решения владельца в теле issue.
  • Дельта не расширяет и не сужает скоуп, не меняет контракт поведения сверх того, что было согласовано в r1 и владельцем.

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

  • Не проверял разделы, не тронутые дельтой и перечисленные выше как «Унаследовано из r1» — они разобраны r1 по коду и issue, повторная верификация не требуется по PROCESS.md §2.10.
  • Не прогонял typecheck/test/build/golden/smoke — продуктовый код не менялся ни в исходном ТЗ, ни в дельте r2; эти гейты относятся к будущему код-ревью, а не к ревью ТЗ.
  • Не проверял фактическое визуальное поведение Glow-blend на decor в браузере — на этапе ТЗ нет кода для запуска; это остаётся открытым техническим риском §8.2, корректно вынесенным в реализацию с явным запретом молчаливого решения.

Резюме

Единственная находка r1 (M1, Medium, в скоупе) закрыта точным и проверяемым изменением AC2 и плана автотестов, без догадок и без расширения скоупа. Новых находок в дельте r2 нет. Остальной контракт наследуется из r1 без повторной проверки, так как дельта его не касается. Вердикт: зелёный, ТЗ переходит в S5-ready.