docs: review document for #806

Issue: #806
User-Visible: no
This commit is contained in:
claude[bot]
2026-10-06 15:38:58 +00:00
parent e12c04568a
commit 705889cc37
2 changed files with 179 additions and 1 deletions
+2 -1
View File
@@ -1,6 +1,6 @@
# Индекс ревью
Генерируется `node scripts/reviews-index.mjs` (#635) — не редактировать руками. Документов: 317, issue: 158. Вердикт: 🟢 зелёный · 🟡 жёлтый · 🔴 красный · ⚪ не распознан (свободная форма старых документов). H/M — число High/Medium по строке вердикта или заголовкам находок. Файлы — пути, названные в находках; ищите по имени файла: `grep form-kit INDEX.md`.
Генерируется `node scripts/reviews-index.mjs` (#635) — не редактировать руками. Документов: 318, issue: 158. Вердикт: 🟢 зелёный · 🟡 жёлтый · 🔴 красный · ⚪ не распознан (свободная форма старых документов). H/M — число High/Medium по строке вердикта или заголовкам находок. Файлы — пути, названные в находках; ищите по имени файла: `grep form-kit INDEX.md`.
| Issue | Документ | Этап · раунд | Вердикт | H | M | Находки | Файлы |
|---|---|---|---|---:|---:|---|---|
@@ -8,6 +8,7 @@
| бета v1.79.0-beta.2 | [SHIP-REVIEW-v1.79.0-beta.2.md](SHIP-REVIEW-v1.79.0-beta.2.md) | пакетное ревью ship · — | ⚪ — | 0 | 0 | — | — |
| бета v1.79.0-beta.1 | [SHIP-REVIEW-v1.79.0-beta.1.md](SHIP-REVIEW-v1.79.0-beta.1.md) | пакетное ревью ship · — | ⚪ — | 0 | 0 | — | — |
| #806 | [SPEC-REVIEW-806-r1.md](SPEC-REVIEW-806-r1.md) | spec · r1 | 🟡 жёлтый | 0 | 1 | Влияние на производительность не названо (DoR §2.5 нарушен). Обязательный пункт «Готово… | `src/styles/devices.styles.ts` `CODE-REVIEW-792-r1.md` `CODE-REVIEW-792-r2.md` `docs/SCOPE.md` `SPEC-REVIEW-802-r1.md` `SPEC-REVIEW-804-r1.md` |
| #806 | [SPEC-REVIEW-806-r2.md](SPEC-REVIEW-806-r2.md) | spec · r2 | 🟢 зелёный | 0 | 0 | — | — |
| #804 | [SPEC-REVIEW-804-r1.md](SPEC-REVIEW-804-r1.md) | spec · r1 | 🟢 зелёный | 0 | 0 | — | — |
| #804 | [CODE-REVIEW-804-r1.md](CODE-REVIEW-804-r1.md) | code · r1 | 🟢 зелёный | 0 | 0 | — | — |
| #802 | [SPEC-REVIEW-802-r1.md](SPEC-REVIEW-802-r1.md) | spec · r1 | 🟢 зелёный | 0 | 0 | — | — |
+177
View File
@@ -0,0 +1,177 @@
# SPEC-REVIEW-806-r2
Issue: #806 — «Индикатор заряда: мягкая тень и скрытие для отдельного устройства»
Этап: spec (PROCESS.md §2.4) · Трек: ask (§5) · Заход: r2 · блокирующих
циклов 1/4 (бюджет не меняется — зелёный вердикт цикла не образует, §4)
Материал: тело issue #806, раздел `## ТЗ` (текущая редакция,
sha256 тела `47c103eacc64bfce98c7b897b1fac128386e36ab8e388b606e0904c1c99a60ae`)
плюс комментарий владельца от 2026-10-06T15:33:49Z, закрывающий находку r1.
Продуктовый код в этой задаче ещё не писался — этап его не требует.
Route: fix (зафиксирован промптом конвейера, #726).
## Скоуп
Без изменений относительно r1: утверждённая мягкая тень четырёх
battery-иконок #792, непрерывно масштабируемая между 19 и 56 px, плюс новое
необязательное поле маркера `hide_battery?: boolean` и локальный тумблер
«Скрыть отображение заряда на плане» в диалоге устройства поверх глобального
`show_device_battery`. Служит J1 (`docs/SCOPE.md`). Не-скоуп — тот же список
(раздел 6 ТЗ). Полное обоснование скоупа и трека — в
`docs/reviews/SPEC-REVIEW-806-r1.md`, раздел «Скоуп»; не повторяю его здесь,
см. раздел «Унаследовано из r1» ниже.
## Как проверялось
Ревью ТЗ не включает выполнение гейтов: продуктового кода ещё нет,
`node_modules` в рабочей копии отсутствует (зависимости на этапе spec не
ставились, #696) — это ожидаемо и не находка.
Это повторный раунд — разбор по дельте (PROCESS.md §2.10,
`docs/process/REVIEWER.md` «Повторный раунд»). Нашёл вердикт и материал
предыдущего раунда: `docs/reviews/SPEC-REVIEW-806-r1.md`, блок «Материал
раунда» → якорь тела issue
`54ffdf1f80d65b08e2e9164e6b41a5f67396a033ead90cf02d15a9d25a5ae59e`. Текущий
sha256 тела (`47c103ea…`) отличается от якоря r1 — тело редактировалось.
Прямого построчного диффа тела issue GitHub не предоставляет (issue — не
git-blob), поэтому дельта установлена сопоставлением: (а) r1 цитирует текст
всех разделов 1–9 построчно в разделах «Находки» и «Что проверено и
корректно» — этот текст посимвольно совпадает с текущим телом везде, кроме
раздела 8; (б) комментарий владельца от 15:33:49Z прямо называет правку:
«в §8 явно зафиксировано ненулевое влияние `filter: drop-shadow` на
композитинг, отсутствие новых registry scan/polling/observer/DOM-узлов и
обязательный browser-smoke плотной сцены с 200 батарейными маркерами в
static/pan/zoom в рамках действующих performance-бюджетов»; (в) это дословно
совпадает с первым абзацем текущего раздела 8 ТЗ. Три независимых источника
сходятся на одной и той же правке — дельта локальна и это весь объём
повторной проверки.
Перед разбором подсистемы проверены её строки в `docs/reviews/INDEX.md`:
строка `#806 | SPEC-REVIEW-806-r1.md | spec · r1 | 🟡 жёлтый | 0 | 1` и
соседние `#792` (spec r1 🟢, code r1 🟡→r2 🟢) — совпадают с тем, что описано
в r1 и что видно в теле issue сейчас; расхождений нет.
Дополнительно перечитан раздел «Батарея (#792)» `docs/DEVICE-PRESENTATION.md`
и существующая инфраструктура performance-бюджетов `demo/performance/`
(`README.md`, `budgets*.json`) — убедиться, что фраза ТЗ «действующих
performance-бюджетов» ссылается на реально существующий, воспроизводимый
механизм (не на абстракцию): `demo/performance/README.md` документирует
ровно такой прецедент — каждая новая поверхность рендера (#89, #160, #137)
добавляет свой `budgets-*.json` профиль без изменения существующих, точное
имя файла — решение автора, а не продуктовая развилка. Расхождений не
найдено.
## Находки
### High
Нет.
### Medium
Нет.
## Закрытие раунда r1
| Находка r1 | Чем закрыта | Где это видно |
| --- | --- | --- |
| **M1.** Влияние на производительность не названо (DoR §2.5 нарушен) — ни слова о perf ни в ТЗ, ни в «Аналитике» | Раздел 8 ТЗ получил абзац, явно называющий (а) что не добавляется — registry scan, polling, observer, лишний DOM-узел, локальный предикат O(1); (б) что добавляется и почему — `filter: drop-shadow` на уже существующем `ha-icon` увеличивает стоимость композитинга относительно текущего изображения без тени, «влияние не объявляется нулевым»; (в) способ доказательства — целевой browser-smoke, сравнивающий frame/long-task показатели на плотной сцене со 200 батарейными маркерами в режимах static/pan/zoom, без ухудшения действующих бюджетов | Тело issue #806, раздел 8 «Проверки и релиз», первый пункт списка (начинается «Производительность: …»); подтверждающий комментарий владельца 2026-10-06T15:33:49Z: «Исправлено по SPEC-REVIEW r1: …» |
Фикс в точности соответствует предложенному в r1 второму варианту («если
авторы считают `drop-shadow` заметно дороже — явный пункт плана проверок»):
автор не стал писать «нулевое влияние», а признал ненулевое и дал измеримый
критерий приёмки (browser-smoke, 200 маркеров, три режима взаимодействия, не
хуже текущих бюджетов) — это закрывает DoR §2.5 по существу, а не формальной
отпиской.
## Унаследовано из r1
Весь остальной разбор ТЗ принят без повторной проверки — дельта его не
касается (раздел 8 вне AC1–AC3, остальные восемь разделов текста не
менялись побайтово, см. «Как проверялось»):
- Обязательные разделы §7.1 присутствуют по существу; сценарий, скоуп/
не-скоуп, контракт поведения (4 условия показа), UX тумблера, модель данных
и совместимость, i18n (en+ru дословно, de/fr по паттерну), план автотестов
по AC1–AC3, откат, release-артефакты — `SPEC-REVIEW-806-r1.md`, раздел «Что
проверено и корректно».
- Три риска из комментария «Аналитика» (потеря поля, расхождение preview/
View, читаемость тени) прямо покрыты требованиями ТЗ — там же.
- Модель данных (`hide_battery?: boolean`, отсутствие/`false` эквивалентны,
без миграции) последовательна с прецедентом `settings.show_room_tooltip`
(`docs/CONFIG-COMPATIBILITY.md`) — там же.
- Политика показа (раздел 4, 4 условия) сверена построчно с
`docs/DEVICE-PRESENTATION.md:48,52–54`, расхождений не найдено — там же.
- Touch закрыт содержательно (десктопный диалог, тень не меняет хитбокс) без
отдельной строки — низкая находка не заводилась и не заводится сейчас —
там же.
- Открытых продуктовых вопросов нет; единственное место, похожее на вопрос
(способ интерполяции тени 19↔56 px), владелец заранее закрыл допуском
«около .75» — там же.
- Трек `ask` и метка `ci:golden` обоснованы (новое персистентное
поле + новый UX-контрол + изменение планового рендера) — там же.
Документ и материал предыдущего раунда: `docs/reviews/SPEC-REVIEW-806-r1.md`,
тело issue на момент r1 — sha256
`54ffdf1f80d65b08e2e9164e6b41a5f67396a033ead90cf02d15a9d25a5ae59e`.
## Что проверено и корректно
- Делта r1→r2 (абзац «Производительность» в разделе 8) — текст однозначен,
называет источник ненулевого влияния (`filter: drop-shadow` поверх
существующего `ha-icon`), явно исключает дорогие механизмы (registry scan,
polling, observer, лишний DOM-узел) и даёт измеримый критерий приёмки
(browser-smoke, 200 маркеров, static/pan/zoom, без ухудшения действующих
бюджетов) — DoR §2.5 закрыт по существу.
- «Действующие performance-бюджеты», на которые ссылается ТЗ, — не
абстракция: `demo/performance/README.md` и соседние `budgets-*.json`
документируют ровно такой механизм добавления нового профиля под новую
поверхность рендера без изменения существующих (прецеденты #89, #160,
#137) — формулировка ТЗ исполнима без домысливания.
- Остальной текст issue побайтово не изменился с r1 — полный повторный разбор
не требуется (см. «Как проверялось»).
- Новых продуктовых вопросов владельцу правка не породила.
## Чего не проверял
- Исполнение гейтов (`tsc`, `npm test`, `npm run build`, golden, performance
smoke, backend pytest) — кода ещё нет, этап spec их не требует; `node_modules`
отсутствует в рабочей копии.
- Фактическую стоимость `filter: drop-shadow` в целевых браузерах/GPU и
результат предложенного browser-smoke — это измеримо только на
реализации; здесь проверено только то, что вопрос теперь назван и снабжён
методом доказательства (находка M1 закрыта), а не что smoke уже прогнан или
что будущий результат уложится в бюджет.
- Точную формулу непрерывной интерполяции тени между 19 и 56 px и точное имя
будущего `budgets-*.json`/smoke-скрипта для battery-сцены — инженерное
решение автора, не предмет спецификации; проверит код-ревью чтением
реализации.
- Состояние любого локального черновика кода — по правилу §2.4 ревью ТЗ
черновик не читает и доводом не считает.
- Реальные DE/FR-переводы тумблера — делегированы «текущему паттерну»,
предмет код-ревью/обычного процесса перевода, не DoR.
## Вердикт
Зелёный. Единственная находка r1 (DoR §2.5 — влияние на производительность не
названо) закрыта по существу: раздел 8 ТЗ теперь явно признаёт ненулевое
влияние `filter: drop-shadow`, называет источник стоимости и даёт измеримый
browser-smoke как метод доказательства, не ослабляя действующие бюджеты.
Остальной текст ТЗ не менялся и принят из r1 без повторной проверки (раздел
«Унаследовано из r1»). High: 0, Medium: 0, новых находок нет.
Вердикт: зелёный · заход r2 · блокирующих циклов 1/4 · High: 0 · Medium: 0
---
<!-- material-anchors: сгенерировано конвейером (#414) -->
## Материал раунда
- Ветка: `dev`, коммит `e12c04568af5` — ребейз его осиротит, и это нормально: ниже якоря, которые ребейз не меняет.
- Дерево материала: `164b1a75cd811cd4f8d8fabb872b96e19faada30`
```
git log --all --format='%H %T' | grep 164b1a75cd81
```
- Тело issue: `78874c4b29e42011cd8d9fc46caaa3ae6df2365f98da3f9b058b1420d2a240de`
- Вердикт конвейера: `green` · High 0 · маршрут `fix`
<!-- hp:usage input_tokens=3855 output_tokens=15558 cache_creation_input_tokens=63425 cache_read_input_tokens=1119211 num_turns=23 -->