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

SPEC-REVIEW-360-r2

Issue: #360 · этап: spec (S4-spec-review) · трек: small (лёгкий) · заход: r2 · блокирующих циклов израсходовано: 1 из 2 (лимит лёгкого трека, §4 — r1 был жёлтым и потратил цикл, зелёный r1 бюджет бы не тратил, но r1 был жёлтым)

Ревьюер: Claude (роль «ревьюер ТЗ»), отдельная сессия от r1 и от автора. ТЗ по-прежнему живёт в теле issue #360 (revision 2), файл docs/specs/ не создаётся — верно для small. Кода нет: issue в S4-spec-review, Rule #1 не разрешает трогать src/** раньше S5-ready, и на dev (HEAD 6ce42b33) изменений класса A по #360 нет.

Разбор по дельте (PROCESS.md §2.10)

Второй заход — разбор ограничен дельтой revision 1 → revision 2, а не ТЗ целиком. Дельта локальна: ни ребейза, ни смены контракта поведения, ни новой подсистемы, объём дельты (два добавленных предложения) несопоставимо меньше исходной задачи. Полный повторный разбор не требуется.

Как найдена дельта. Тело issue не версionируется в git, поэтому вместо git diff <SHA>..HEAD использован эквивалент для spec-этапа: GitHub userContentEdits (GraphQL) с историей правок тела issue. Ревизия 1 (та, что читал r1) — снимок тела issue непосредственно перед правкой в 08:00:23Z, без слов «Touch editor» и без _decorSaveShape; это дословно совпадает с тем, что процитировано в docs/reviews/SPEC-REVIEW-360-r1.md. Текущее тело (revision 2, правка в 08:08:24Z) сверено с этим снимком построчным diff.

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

Находка r1	Чем закрыта	Где это видно
M1 — не названа обязательная формула туча из docs/TOUCH-SUPPORT.md («New editor feature specifications... must state one of: Touch editor: supported / best effort / intentionally degraded / not exposed»)	Пункт 8 контракта поведения дополнен буквальной формулой	Тело issue, п.8: «Touch editor: best effort / intentionally degraded. Background editor сохраняет действующий desktop-first контракт; на touch View/kiosk нет изменений и регрессий.» — точное совпадение одного из трёх канонических вариантов docs/TOUCH-SUPPORT.md:165-167
M2 — не описано, что сохранение properties-диалога существующего line/rect/ellipse/furniture перезаписывает тот же _decorStyle, который задача делает постоянно видимым	Новый п.9 контракта плюс расширение AC5 и шага 4 плана тестов	Тело issue, п.9: «Сохранение properties-диалога уже существующего line/rect/ellipse/furniture сохраняет текущую семантику _decorSaveShape: его color/opacity становятся новым _decorStyle... Это не ретроактивная перекраска других объектов и не новая побочная связь.»; AC5 добавлена фраза «сохранение нового цвета/opacity в properties-диалоге существующего line/rect/ellipse/furniture обновляет main picker по текущему контракту _decorSaveShape, и следующий объект получает последнее значение»; план тестов, шаг 4, добавлено «Затем сохранить новый цвет/opacity через properties-dialog уже существующих line, rect, ellipse и furniture и проверить main picker и стиль следующего объекта»

Обе находки закрыты добавлением текста без изменения архитектуры контракта или номеров AC — ровно так, как r1 и предписывал. Других правок в теле issue между ревизиями 1 и 2 нет: построчный diff (см. ниже) вне пп. 8, 9, AC5 и шага 4 плана тестов состоит только из переноса строк markdown (тот же текст, другая раскладка по ширине), без содержательных изменений.

Проверка дельты по коду (не только по формулировке)

Обе добавленные фразы — не пересказ, а утверждения о поведении текущего кода, которые обязаны быть сверены (это ровно тот класс, где ТЗ может выдать догадку за решение):

• М1-текст. Формула Touch editor: best effort / intentionally degraded сверена дословно с docs/TOUCH-SUPPORT.md:163-167 («Documentation rule») — совпадает буква в букву, это один из трёх легальных вариантов, а не собственная формулировка автора.
• М2-текст. Утверждение «сохранение properties-диалога существующего line/rect/ellipse/furniture пишет color/opacity в общий _decorStyle» сверено чтением src/houseplan-editor-runtime.ts:4422-4485 (_decorSaveShape): строки 4476–4480 действительно присваивают this.host._decorStyle = { ...style, fill/fillColor/fillOpacity сохраняются из предыдущего _decorStyle кроме rect/ellipse } — подтверждено. Функция правит только элемент с shape.id === d.id (строка 4434), других размещённых объектов не касается — подтверждает фразу «не ретроактивная перекраска других объектов».
• Также проверено чтением, что _decorSaveText (houseplan-editor-runtime.ts:4381-4419, диалог текста) не пишет в _decorStyle — то есть ограничение п.9 списком «line/rect/ellipse/furniture» без text точное, а не случайно узкое.

Обе фразы дельты — не догадка, а корректно сформулированный факт кода.

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

Без повторной проверки в этом раунде приняты все выводы docs/reviews/SPEC-REVIEW-360-r1.md (заход r1, снимок тела issue на 08:00:23Z, т.е. revision 1) — дельта их не затрагивает:

• обязательные разделы §7.1 присутствуют (сценарий, «что человек увидит», проблема, скоуп/не-скоуп, контракт, данные/i18n/совместимость, файлы, AC1–AC8, план тестов, риски/откат, release-артефакты, принятые предположения);
• сверка утверждений ТЗ с деревом на SHA 0decce8d: единый _decorStyle как source для line/rect/ellipse/text/furniture, структура .decorbar/.editbar-tools/.editbar-end, flex-wrap вместо скролла, хрупкие тесты demo/smoke_decor.mjs:132-134 и test/color-picker.test.mjs:57-62, независимость fillColor/fillOpacity, отсутствие новых i18n-ключей — все подтверждены и делтой не задеты; _decorStyle со времени SHA 0decce8d в этом файле не менялся (единственные изменения на пути к 6ce42b33 — сам документ ревью и предыдущий golden/фикс furniture-обводки, не относящиеся к decor-style contract), поэтому вывод остаётся в силе и на текущем HEAD;
• product-question gate соблюдён, блокирующих продуктовых вопросов у автора нет;
• трек small подтверждён верно (одна поверхность, риск/сложность ≤3, нет миграции, нет нового UX-контракта, лимит ревью ТЗ — 2 цикла);
• откат описан и достаточен;
• Low-находок сверх M1/M2 не было и не появилось.

Что проверено заново в этом раунде

• Текст п.8 и п.9 (весь текст, добавленный дельтой);
• AC5 в новой редакции — единственный AC, чьё доказательство дельта расширяет;
• шаг 4 плана тестов в новой редакции;
• код _decorSaveShape и _decorSaveText (чтением, не исполнением — на этапе spec кода задачи нет, поэтому запуск невозможен и не требуется).

Гейты

Этап — spec, не code. src/** по issue #360 не изменялся (Rule #1: код разрешён только из S5-ready), поэтому typecheck/test/build/ check-docs/model-invariants/смоки к этому раунду неприменимы — гейты кода запускаются на этапе код-ревью. Единственная проверка этого раунда — чтение кода _decorSaveShape/_decorSaveText в текущем дереве dev (см. выше), выполненное вручную.

Находки

Новых High/Medium/Low находок в дельте revision 1 → revision 2 нет. Обе Medium-находки r1 закрыты полностью и точно.

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

• Реальную браузерную/визуальную проверку (кода нет, применимо к код-ревью после реализации) — без изменений относительно r1;
• demo/golden и фактический рендер light/dark — неприменимо к ТЗ;
• соответствие итогового кода контракту — предмет отдельного код-ревью.

Вердикт

Зелёный. High: 0. Medium: 0 (обе находки r1 закрыты, новых нет). Issue готов к переходу в S5-ready.