houseplan-card/legacy/docs/PRODUCT-IMPROVEMENT-PLAN.ru.md

House Plan — архивный снимок плана улучшений продукта

Архивировано 9 августа 2026 года. Все актуальные пункты этого снимка перенесены в GitHub Issues и Project v2. Этот файл больше не является backlog, не обновляется и хранится только для истории решений.

Срез: v1.60.3-beta.2, 9 августа 2026 года.

Этот документ — рабочий backlog, а не журнал истории. Здесь находятся только нерешённые задачи, которые подтверждаются текущим кодом, интерфейсом, пользовательским руководством или зафиксированным scope продукта. После реализации и проверки завершённый пункт удаляется из файла полностью; история пользовательских изменений остаётся в CHANGELOG, а архитектурные решения — в профильной документации и спецификациях.

1. Как читать и обновлять план

Приоритеты

Приоритет	Значение
P0	Подтверждённая потеря данных, нарушение модели доступа, опасное управление домом или блокировка основного сценария
P1	Регулярная пользовательская ловушка, недоступный основной сценарий, высокий риск регрессий или архитектурный долг, уже замедляющий развитие
P2	Существенное улучшение понятности, поддержки, производительности или качества, которое не блокирует текущую работу
P3	Условная продуктовая инициатива; начинать только после отдельного решения владельца и самостоятельного ТЗ

На текущем срезе подтверждённых P0 нет. Если такой дефект появляется, он имеет приоритет над этой очередью и после исправления не остаётся в документе как закрытый пункт.

Статусы открытых задач

Статус	Значение
Готово к ТЗ	Проблема и ожидаемый результат понятны; перед кодом достаточно детализировать реализацию
Нужно UX-решение	Перед реализацией требуется утвердить конкретное пользовательское поведение
Исследование	Сначала нужны измерения, инвентаризация данных или прототип без изменения модели
В работе	Инициатива выполняется небольшими самостоятельными этапами; следующий этап и критерии завершения явно зафиксированы
По запросу	Инициатива соответствует scope, но не должна вытеснять основной backlog без отдельного решения
ТЗ на согласовании	Полное ТЗ подготовлено, но продуктовые решения ещё не подтверждены владельцем
Готово к реализации	ТЗ прошло ревью, блокирующих вопросов нет; код ещё не изменён

Обязательные правила

1. View остаётся главным ежедневным режимом; редакторы обслуживают его и не добавляют взаимодействия в просмотр без понятной пользы для членов семьи.
2. Ни одна миграция, оптимизация или очистка не удаляет пользовательские файлы и данные по косвенному признаку.
3. Новое поле настройки не добавляется без runtime-потребителя, локализации, backend validation, документации и теста совместимости.
4. Сложная геометрия развивается через чистые функции и сценарные матрицы, а не через дополнительные ветки внутри корневого render.
5. Большой рефакторинг делится на небольшие поведенчески нейтральные этапы. Переписывание приложения целиком не планируется.
6. Touch, мышь и клавиатура являются равноправными вариантами режима просмотра. Редакторы desktop-first: полная поддержка гарантируется для компьютера с мышью/клавиатурой, а touch-редактирование выполняется по остаточному принципу согласно TOUCH-SUPPORT.md. Светлая/тёмная тема и prefers-reduced-motion остаются общими требованиями всех поддерживаемых поверхностей.
7. Golden-image и large-house performance являются постоянными блокирующими CI-инвариантами. Новая геометрическая/визуальная поверхность расширяет golden fixture, а изменение горячего пути — performance profile или обоснование неизменности нагрузки.

2. Текущий срез и главные риски

Область	Фактическое состояние	Главный оставшийся риск
Пользовательская ценность	Основные spatial-сценарии Home Assistant закрыты; продукт сочетает просмотр, редактирование, геометрию, свет, климат и быстрые действия	Дальнейшее добавление функций без упрощения существующего UI ухудшит осваиваемость
View на desktop	Информативен и визуально целостен	Часть контекста комнаты по-прежнему зависит от hover и маленькой иконки HA-зоны
View на touch	Устройства имеют tap/long-press сценарии	У комнаты нет полноценного tap-эквивалента hover-подсказки
Редакторы	Функционально глубокие, с сеткой, общей сессионной историей, стабильной основной панелью и отдельной context tray	Часть точных операций остаётся скрыта за жестами; полноценного клавиатурного управления холстом нет
Настройки	Все основные уровни наследования представлены	Диалоги пространства, устройства и общих настроек длинные и смешивают разные задачи
Состояния устройств	План, статическая карточка и live preview используют единый ResolvedDevicePresentation; preview показывает интеграцию, источники, состояние и fallback	Жизненный цикл найденных, скрытых, удалённых и повторно доступных привязок по-прежнему объясняется несколькими разными экранами
Данные и совместимость	Есть versioned migration и явная оптимизация	В модели остаются legacy-поля и внутренние ключи без публичного жизненного цикла
Frontend	37 TypeScript-файлов, 32 105 физических строк	После выделения context tray src/houseplan-card.ts содержит 14 626 строк — 45,6% всего TypeScript; корневой монолит остаётся главным архитектурным риском
Типизация	Строгий TypeScript включён	В src/ остаётся около 646 употреблений any, включая внутреннюю бизнес-логику, а не только границу HA
Проверки	Инвентаризация: 502 Node unit, 104 pure backend, 50 HA-harness и 118 browser smoke	Golden-image и base-vs-candidate large-house performance работают отдельными блокирующими CI gate; новые поверхности нужно последовательно добавлять в их fixtures
Документация	Подробное русское руководство, тематические документы и двуязычный changelog существуют	README/HACS-скриншоты и часть обзорного пути ещё не показывают unified Boundary, перегородки/колонны, context tray и device preview

Главная цель ближайших циклов: сделать уже существующую глубину понятной, доступной и дешёвой в сопровождении, не расширяя без необходимости поверхность настроек.

3. Реестр открытых инициатив

ID	Приоритет	Статус	Результат
HP-UX-01	P1	Нужно UX-решение	Карточка комнаты по tap/click с чистой площадью и доступными метриками
HP-UX-02	P1	Нужно UX-решение	Понятный inbox устройств: новые, размещённые, скрытые и доступные к повторному добавлению
HP-UX-04	P1	Готово к ТЗ	Разделение длинных диалогов по задачам и условное скрытие неприменимых полей
HP-UX-05	P3	По запросу	Помощь по жестам и недорогое улучшение touch-редакторов без требования паритета с desktop
HP-A11Y-01	P1	Исследование	Семантика плана для клавиатуры и screen reader; состояние читается не только цветом
HP-A11Y-02	P1	Готово к ТЗ	Единое кастомное подтверждение вместо оставшихся browser confirm()
HP-DATA-01	P1	В работе	Единый реестр схемы, миграций и срока жизни compatibility-полей
HP-ARCH-01	P1	В работе	Поэтапное разбиение корневого компонента и монолитных стилей
HP-DOC-01	P1	Готово к ТЗ	Актуальные скриншоты и единая пользовательская навигация по документации
HP-UX-06	P2	Нужно UX-решение	Явный room override для Glow
HP-UX-07	P2	Нужно UX-решение	Упрощённая и объяснимая система масштабов названия и карточки комнаты
HP-UX-08	P2	Нужно UX-решение	Визуальный конструктор правил иконок с advanced regex-режимом
HP-UX-09	P2	Исследование	Диагностика слишком больших подложек и безопасное уменьшение растров
HP-UX-10	P2	Нужно UX-решение	Более направляемое создание комнат на основе Floors/Areas Home Assistant
HP-A11Y-03	P2	Исследование	Клавиатурное редактирование выбранных объектов на сетке
HP-ENG-01	P2	Готово к ТЗ	Измеряемое backend coverage, строгая Python-типизация и quality-scale хвосты
HP-ENG-02	P2	Нужно UX-решение	Безопасный пользовательский support report из раздела обслуживания
HP-ENG-03	P2	Исследование	Явное решение по внутренним фильтрам и группировке устройств
HP-PROD-01	P3	По запросу	Пользовательские картинки как объекты декора
HP-PROD-02	P3	По запросу	Сводный security glance по дверям, окнам и замкам
HP-PROD-03	P3	По запросу	Пространственное отображение person/presence
HP-PROD-04	P3	По запросу	Пороговые цвета метрик карточки комнаты

4. P1 — ближайший продуктовый цикл

HP-UX-01 — карточка комнаты в режиме просмотра

Проблема. Чистая площадь и часть контекста комнаты доступны через hover. На touch hover отсутствует, а переход к HA area спрятан в маленькой иконке около названия. Нажатие по самому полу комнаты сейчас не даёт равнозначного результата.

Предлагаемое поведение. Обычный tap/click по свободной части комнаты в View открывает компактный hp-dialog:

• название комнаты;
• чистая площадь по той же геометрии, которая используется в hover и расчётах;
• только доступные метрики: температура, влажность, LQI и состояние света;
• явное действие «Открыть зону в Home Assistant», если у комнаты есть area;
• закрытие без навигации для комнаты без area.

Hover-подсказка на desktop остаётся быстрым просмотром. Клик по устройству, двери, окну, кнопке комнаты или другому интерактивному объекту не должен проваливаться в комнату.

Эдж-кейсы. Комната без area; вложенные комнаты; отверстия в чистом полу; толстые и скрытые стены; перегородки и колонны; Glow под курсором; pan до отпускания указателя; несколько комнат с общей стеной; выключенные метрики; пустое название.

Критерии приёмки. Площадь совпадает с hover и resize; сценарий работает мышью, touch и клавиатурой; один tap не открывает одновременно устройство и комнату; переход в HA существует только как подписанная кнопка.

HP-UX-02 — inbox и жизненный цикл устройств

Проблема. Текущие «Добавить» и «Показать скрытые» технически позволяют восстановить устройство, но не объясняют, почему оно не появилось на плане, было скрыто или снова стало доступно. Автоматический фильтр, ручное скрытие и удаление выглядят как похожие состояния.

Целевая структура. В редакторе устройств нужен единый список с фильтрами:

Раздел	Что показывает	Действия
Новые	Привязки HA, которых ещё нет на плане	Добавить, скрыть
На плане	Видимые маркеры	Найти на плане, редактировать
Скрытые	Маркеры с ручным hidden и первично отфильтрованные кандидаты	Показать, добавить, объяснить причину
Доступные снова	Удалённые привязки, которые можно добавить как новый маркер	Добавить заново

Причина должна быть пользовательской: «скрыто вручную», «служебная сущность», «исключённый тип», «уже представлено родительским устройством». Внутренние regex и id не показываются как основное объяснение.

Инварианты. Просмотр списка не изменяет конфигурацию; повторное добавление не создаёт дубликат binding; никакой раздел не удаляет файл или trail без явного подтверждённого действия; одна и та же привязка получает один жизненный цикл на всех клиентах.

HP-UX-04 — информационная архитектура диалогов

Проблема. Диалоги пространства, устройства и общих настроек содержат несколько независимых задач в одной длинной прокрутке. У виртуального или пассивного объекта видны поля, которые не могут дать полезный результат.

Целевая группировка. Это изменение интерфейса, а не модели данных.

Диалог	Разделы
Пространство	Основа; комнаты и подписи; внешний вид; окружение
Устройство	Привязка; действие; состояние и свет; внешний вид; информация и файлы
Общие настройки	Цвета; окружение; обслуживание; о продукте

На desktop допустимы вкладки или боковая навигация; на узком экране — последовательные секции/аккордеон. Выбранный вариант должен оставаться нативно понятным в HA и не создавать вложенный горизонтальный скролл.

Условность полей. Световые controls и радиус показываются только когда привязка может участвовать в on/off-свете; climate temperature — только при climate; vacuum — только при источнике координат; настройки состояния скрываются у полностью виртуального маркера; удаление и скрытие остаются видимыми действиями жизненного цикла.

Критерии приёмки. Переключение разделов не теряет несохранённые значения; ошибки ведут к конкретному полю; footer стабилен при любой высоте; весь сценарий проходит клавиатурой; существующие конфиги сохраняются без миграции.

HP-A11Y-01 — доступная семантика View

Проблема. Комнаты являются SVG-формами с hover, устройства — кликабельными div, а смысл working/open/alarm часто считывается прежде всего по цвету. Общий hp-dialog закрывает модальную часть, но сам план остаётся слабым для клавиатуры и screen reader.

Исследование и целевой контракт.

1. Определить компактное дерево доступности, которое не создаёт сотни tab-stop: roving tabindex либо отдельный список «Комнаты / Устройства / Проёмы».
2. Для интерактивного объекта сформировать единый aria-label: имя, тип, локализованное состояние, комната и доступное действие.
3. Добавить нецветовой визуальный признак для критических состояний: тревога, открыто/разблокировано, активная механика. Он не должен превращать каждый маркер в набор badge.
4. Room card из HP-UX-01 сделать основной доступной точкой комнаты.
5. Проверить порядок фокуса после смены пространства, режима и закрытия карточки.

Критерии приёмки. Основные View-сценарии доступны без мыши; axe-проверка не находит базовых нарушений name/role/value и modal boundaries; при отключённом цвете состояния остаются различимы текстом или формой.

HP-A11Y-02 — единое подтверждение опасных действий

Проблема. В коде остаются browser confirm() для удаления комнаты, пространства, плана, устройства, незавершённого контура/сегмента и для unlock. Они визуально и семантически отличаются от остальных диалогов, плохо объясняют объект операции и не дают контролировать начальный фокус.

Решение. Компонент hp-confirm поверх hp-dialog с promise API:

• заголовок операции, имя объекта и короткое описание последствий;
• destructive-кнопка визуально отделена от cancel;
• начальный фокус на безопасном действии;
• Esc, focus trap и restore focus наследуются от hp-dialog;
• unlock имеет отдельную предупреждающую семантику и никогда не переиспользует текст удаления;
• повторный вызов не накладывает два подтверждения и не применяет callback старого экземпляра.

Критерий приёмки. В runtime-коде нет прямых confirm(); каждый destructive path имеет browser smoke с cancel и accept; touch footer не обрезается.

HP-DATA-01 — единая схема и lifecycle compatibility-полей

Проблема. Типы TypeScript, формы, runtime и Voluptuous validation синхронизируются вручную. В текущей модели видны разные классы долга:

• устаревший карточечный tap_action;
• read-compatibility значение display ripple;
• временный settings.show_all;
• удалённый из логики солнечных лучей settings.weather_entity;
• vacuum.room_highlight и vacuum.segment_map, для которых нет найденного runtime-потребителя;
• settings.group_lights и settings.exclude_integrations, влияющие на runtime без поддерживаемого пользовательского интерфейса.

Первый этап — исследование без удаления. Сформировать registry полей с типом, default, уровнем наследования, UI-видимостью, runtime consumer, frontend/backend enum, версией появления, migration и сроком read-compatibility. Локальный анализатор конфига должен показать, какие legacy-поля реально встречаются, не отправляя телеметрию наружу.

Текущий этап. Машиночитаемый registry находится в scripts/config-field-registry.mjs, а read-only анализатор экспортированного JSON — в scripts/config-audit.mjs. Зарегистрированы 19 известных legacy, скрытых и compatibility-представлений, включая геометрию, декор и удалённую погодозависимость солнечных лучей. Это ещё не каноническая схема: открытым остаётся охват всех текущих публичных полей и автоматический frontend/backend parity-check.

Второй этап.

• parity-тест сравнивает frontend и backend enum/limits;
• «Оптимизировать планы» показывает конкретную миграцию до записи;
• unknown future fields сохраняются;
• deprecated поле удаляется из публичной модели только после явно заданного окна чтения;
• внутренний ключ либо получает поддерживаемый UI, либо становится фиксированным правилом и удаляется из хранимой конфигурации.

Критерии приёмки. Нет поля, одновременно публичного в типе/schema и не имеющего решения «используем / мигрируем / удаляем»; новый schema drift ломает CI; открытие и сохранение старого конфига не меняет визуал без явной миграции.

HP-ARCH-01 — декомпозиция frontend без big bang

Проблема. 45,6% TypeScript находится в одном houseplan-card.ts; там смешаны lifecycle Lit, server sync, pointer state machines, геометрические команды, все диалоги и render layers. После первого style-slice styles.ts содержит ещё 2 795 строк глобальных правил. Это главный множитель стоимости любых следующих функций.

Целевые границы.

src/
  app/
    houseplan-card.ts          # composition, HA lifecycle, top-level routing
    houseplan-store.ts         # normalized config/layout snapshot and revisions
    navigation-controller.ts   # space, mode, viewport, warm remount
  editors/
    plan/                      # tools, pointer state, commands, toolbar
    devices/                   # discovery, form state, marker commands
    decor/                     # tools, form state, render orchestration
  render/
    rooms.ts
    walls.ts
    openings.ts
    lighting.ts
    devices.ts
    vacuum.ts
  dialogs/
    room-dialog.ts
    space-dialog.ts
    device-dialog.ts
    settings-dialog.ts
  components/
    hp-dialog.ts
    hp-confirm.ts
    hp-color-opacity.ts

Это направление, а не требование создать все файлы заранее. Каждый этап переносит одну законченную ответственность вместе с типами и тестами.

Порядок безопасного разбиения.

1. Render-only слои с явным immutable input и callbacks.
2. Модели состояния диалогов и их validation/serialization.
3. Контроллеры Plan/Devices/Decor как конечные автоматы жестов.
4. Нормализованный store и серверные ревизии.
5. Scoped styles рядом с компонентами.

Ограничения. Никакой новой второй модели геометрии; чистые модули logic, wall-thickness, open-spans, resize, physical-geometry, sun и device-visual остаются источниками истины. В новой продуктовой логике используется unknown и type guards вместо any; HA adapter boundary может быть изолированным исключением.

Уже выделенные границы. Отдельно существуют hp-dialog, hp-color-opacity, цепочка device-visual → device-presentation → device-face/hp-device-preview, integration provenance и SVG-проекция тоннелей проёмов render/opening-tunnels.ts. Context tray также выделена в editor-secondary.ts: модуль владеет EditorSecondaryModel, EditorToolbarGroup, focus/animation/outside-dismiss lifecycle и стабильным light-DOM render; её 180 строк стилей находятся в editor-secondary.styles.ts. Конкретные Plan/Decor-действия остались в корневом контроллере как typed callbacks. Все эти границы используют прежние источники истины и не создают вторую модель состояния.

Следующий безопасный этап. Отдельным refactor-only slice вынести состояние, валидацию и сериализацию одного небольшого диалога свойств, начиная с перегородки/колонны. Не менять DOM-контракт hp-dialog, не смешивать перенос с новой информационной архитектурой HP-UX-04 и не переносить заодно геометрические команды. После подтверждения шаблона тем же способом по одному выносить более крупные room/opening dialogs.

Критерии приёмки. Корневой компонент становится композиционным, ориентир — менее 3 500 строк; feature-модуль обычно не превышает 800 строк; количество any монотонно снижается; один и тот же полный smoke-набор проходит до и после каждого этапа; визуальных изменений в refactor-only PR нет.

HP-DOC-01 — документация текущего пользовательского опыта

Проблема. User guide подробный, но обзорные README-скриншоты и часть формулировок отражают более ранний состав редакторов. Пользователь сначала видит именно README/HACS, поэтому несоответствие ухудшает onboarding.

Пакет.

• переснять на синтетическом доме View, создание пространства, комнату, Plan editor с context tray, Devices editor с preview, Background editor и карточку устройства;
• коротко объяснить различие «Контур комнаты / Перегородка / Колонна / Граница / Проём»;
• добавить таблицу жестов mouse/touch/keyboard;
• провести проверку внутренних ссылок и терминов RU/EN;
• README оставить обзорным, детали вести в USER-GUIDE.ru.md и тематические документы;
• для нескольких карточек с разными стартовыми пространствами явно зафиксировать поддерживаемый сценарий и ограничения.

Критерии приёмки. Ни один screenshot не показывает отсутствующую кнопку или старое название; основной путь от установки до первой комнаты читается без changelog; ссылки проверяются в CI.

5. P2 — следующий слой улучшений

HP-UX-06 — явный Glow на уровне комнаты

Сейчас пространство может выбрать Glow, а комната — наследовать его или переопределить на none/lqi/light/temp. Комната не может зафиксировать Glow, если пространство позднее переключат в другой режим.

Нужно добавить glow в room override без изменения семантики наследования. До кода требуется решить, участвует ли явно отключённая от Glow соседняя комната в физическом распространении света или только не рисует базовое затемнение. Решение фиксируется одной матрицей для fill, clip и переходов через виртуальные/дверные границы.

HP-UX-07 — одна объяснимая система масштабов комнаты

Сейчас итоговый размер образуют масштаб карточки пространства, отдельные name_scale/label_scale комнаты и сохранённый drag-scale карточки. Система мощная, но пользователь не видит итоговый коэффициент и способ сброса конкретного уровня.

Цель: оставить один default пространства и явные room overrides для названия и метрик. Визуальный resize либо редактирует те же числа, либо показывает фактическое значение и кнопку Reset. Legacy layout-scale читается без визуального скачка и преобразуется только явной оптимизацией.

HP-UX-08 — конструктор правил иконок

Обычный режим должен предлагать поля «домен», device_class, слова в имени/модели и итоговую иконку. Порядок правил остаётся видимым, тестовое устройство показывает первое сработавшее правило и причину. Regex сохраняется как advanced-режим с валидацией и предупреждением о приоритете; существующие regex не переписываются автоматически.

HP-UX-09 — большие подложки

Добавить локальную диагностику разрешения, decoded memory и ожидаемого размера перед загрузкой PNG/JPEG/WebP. Для больших растров предложить безопасную копию с уменьшением, сохраняя оригинал до подтверждения успешной загрузки. SVG не растеризуется автоматически. Порог определяется после тестов на типичных wall-tablet/desktop устройствах и документируется вместе с file-size limit.

HP-UX-10 — Floors/Areas как направляемый onboarding

При создании комнат список area должен учитывать выбранный/импортированный floor, первым показывать неиспользованные зоны этого этажа и предлагать их имя. Нужен небольшой progress «размечено N из M зон» и явный путь для комнаты без zone. Компонент по-прежнему не переименовывает и не переносит HA area — он только читает registry.

HP-A11Y-03 — клавиатурное редактирование выбранных объектов

Первый этап не обязан рисовать произвольный polygon только клавиатурой. Достаточно сделать выбор и точные операции:

• roving focus между объектами текущего слоя;
• Enter — свойства, Delete — только выбранный объект с подтверждением там, где оно требуется;
• стрелки — на один узел сетки, модификатор — на согласованный увеличенный шаг;
• Escape — отмена текущего жеста/выбора;
• доступное объявление координат, длины, угла и результата Undo.

До реализации нужен прототип конфликтов со scroll, pan и текстовыми полями.

HP-ENG-01 — измеряемое инженерное качество backend

• подключить pytest-cov и зафиксировать честное покрытие backend, затем довести его минимум до 95% по исполняемым строкам;
• настроить строгую Python-типизацию по модулям, начиная с validation/store/websocket boundaries;
• добавить lint/format gate без массового шумного rewrite;
• закрыть применимые пункты quality scale: troubleshooting и examples;
• пользовательские ошибки WebSocket, которые доходят до UI, должны иметь стабильный code и локализованное сообщение.

HP-ENG-02 — support report без персональных данных

В «Обслуживании» добавить действие «Скопировать отчёт для поддержки». Отчёт содержит версии card/integration/HA, модель данных, количества пространств/комнат/стен/устройств, состояние ревизий, результаты read-only validation и активные Repairs. По умолчанию исключаются имена, entity/device id, URLs, пути файлов, описания и координаты дома. Перед копированием пользователь видит полный текст.

HP-ENG-03 — фильтры и группировка как явное решение

Провести инвентаризацию exclude_integrations и group_lights на реальных локальных конфигах. Для каждого ключа выбрать одно из двух:

1. поддерживаемая advanced-настройка в inbox с понятным эффектом и default;
2. фиксированное продуктовой логикой поведение без хранимого ключа.

Нельзя оставлять третий вариант — скрытую настройку, которая влияет на результат, но не видна пользователю и не имеет migration policy.

6. P3 — инициативы только по отдельному решению

HP-UX-05 — помощь по жестам и best-effort touch-редакторы

Статус поддержки. Редакторы являются desktop-first инструментами администратора. Полный touch-паритет не является целью или критерием релиза. Пользователям рекомендуется редактировать планы на компьютере; неудобная, частичная или отсутствующая touch-операция допустима, если View и безопасность данных не страдают.

Проблема. Даже в эталонной desktop-среде скрытые жесты (double click, Ctrl/Cmd, Shift, конечные ручки и тонкие объекты) не всегда объясняются в момент работы. Некоторые touch-улучшения можно получить дёшево, не усложняя модель взаимодействия.

Что изменить.

• интерактивные ручки и icon-only кнопки получают увеличенную невидимую область там, где это не создаёт конфликтов геометрии или desktop-ввода; размер 44×44 является ориентиром, а не обязательным контрактом всех редакторов;
• линии, тонкие контуры и концы сегментов используют scale-independent hit area;
• активный инструмент показывает одну короткую контекстную подсказку, а не постоянную стену текста;
• Help overlay собирает Ctrl/Cmd-замыкание, Shift-углы, double click свойств, Undo/Redo, pan/zoom и Erase;
• подсказка различает keyboard modifier по платформе;
• overlay можно закрыть навсегда и повторно открыть из панели;
• дорогие precision-жесты не переносятся на touch только ради формального паритета; допустимо скрыть/отключить операцию и рекомендовать desktop;
• best effort не позволяет сохранять случайную геометрию после pinch, pointercancel или второго касания и не позволяет ломать выход обратно в View.

Эдж-кейсы. Пересекающиеся hit-зоны; две близкие ручки; pan/pinch над выбранным объектом; stylus; zoom 0.4× и крупный zoom; скрытая панель; prefers-reduced-motion; гибридный ноутбук; планшет с подключённой мышью.

Критерий. Desktop-подсказки и рабочие операции остаются понятными и полными. Touch-улучшения принимаются отдельно по конкретным сценариям; общая функциональная эквивалентность редакторов не проверяется.

HP-PROD-01 — картинки как объекты декора

До UI нужен отдельный lifecycle-дизайн: upload, reuse, copy-on-write, ссылки между пространствами, квоты, замена, экспорт, явное удаление и защита от файлов-сирот. Геометрический transform может использовать существующий контракт декора, но серверное хранение нельзя строить как побочный вариант вложений устройства.

HP-PROD-02 — security glance

Один компактный статус дома: закрыты ли двери/окна и заперты ли замки, с раскрытием списка проблемных точек. Это только просмотр и навигация; новый быстрый массовый unlock запрещён.

HP-PROD-03 — person/presence на плане

Нужно сначала выбрать модель приватности и источник: HA person area, device tracker или присутствие комнаты. Не смешивать длительное присутствие с коротким событием движения и не рисовать ложную точную позицию, если HA знает только area.

HP-PROD-04 — пороговые цвета метрик комнаты

Температура, влажность и LQI в карточке комнаты могут иметь настраиваемые диапазоны, но настройка не должна дублировать существующие fill thresholds. Сначала определить общую модель порогов и наследования.

7. Рекомендуемый порядок выполнения

Пакет	Состав	Почему так
A. Техническая основа следующего цикла	следующий slice HP-ARCH-01 и parity-этап HP-DATA-01	Golden/performance gates уже готовы; теперь уменьшаем стоимость изменений и риск schema drift без нового поведения
B. Понятный и доступный View	HP-UX-01, HP-A11Y-01, HP-A11Y-02	Максимальная ежедневная польза и обязательный desktop/touch/keyboard-паритет просмотра
C. Понятный жизненный цикл и настройка устройств	HP-UX-02, HP-UX-04	Live preview уже решает объяснение визуала; остаются discovery/inbox и структура длинного диалога
D. Документация текущего продукта	HP-DOC-01 параллельно пакетам B–C	README/HACS должны показывать уже существующий продукт, а не ждать следующего большого релиза
E. Desktop-редакторы без скрытых ловушек	HP-A11Y-03; HP-UX-05 только по запросу или когда улучшение дёшево	Полнота и точность редакторов гарантируются на desktop; touch-паритет не должен раздувать сложность
F. Второй приоритет	HP-UX-06…10, HP-ENG-01…03	Брать по одному после стабилизации соответствующего слоя

Архитектурное разбиение и schema registry — не отдельная «заморозка продукта». Каждый пользовательский пакет должен оставлять затронутый участок более модульным и лучше проверяемым, чем до него. Golden-image и performance уже являются постоянной инфраструктурой, а не открытыми инициативами.

8. Матрицы качества

Обязательные сценарные матрицы

Матрица	Измерения
Устройство	binding kind × domain × device class × state × availability × display × controls
Свет	auto/explicit/control source × hidden/removed × fill mode × opening × wall/partition/column
Комната	area/no area × nested/shared × thick wall × fill override × touch/hover/keyboard
Геометрия	real/virtual × thickness A/B × corner/T/X × opening × resize × Undo/Redo
Декор	kind × solid/dashed × fill/stroke × transform × erase/select × zoom
Ввод View	mouse × touch × stylus × keyboard × View/kiosk; touch является обязательной поддерживаемой поверхностью
Ввод редакторов	desktop mouse/keyboard × Plan/Devices/Background; touch/stylus — safety floor и только отдельно обещанные сценарии
Миграция	legacy field × open/save × optimize × undo optimize × future unknown field
Адаптивность	RU/EN × light/dark × narrow/medium/wide × reduced motion
Производительность	base SHA/candidate × first render/space switch/state update/resize/pan/dialog × Long Task/heap/cache growth

Метрики направления

Метрика	Цель
Обычное действие, теряющее данные без явного решения	0
Публичное поле без runtime consumer или migration policy	0
Ключевая информация, доступная только через hover	0
Опасное действие через native confirm()	0
Критический статус, различимый только цветом	0
Новый any вне изолированного HA adapter boundary	0
Расхождение frontend/backend enum и limits	0 в CI
Визуальная правка геометрии без соответствующего fixture	0
Изменение горячего пути без large-house comparison либо явного обоснования	0
Размер houseplan-card.ts после декомпозиции	Ориентир <3 500 физических строк
Backend coverage после HP-ENG-01	≥95% исполняемых строк

9. Release- и документационный процесс

Рабочий процесс владельца остаётся источником истины:

• обычные локальные правки вносятся без тестов и без коммитов;
• перед pre-release выполняются production build и минимально необходимые целевые unit/smoke проверки изменённых поверхностей;
• перед stable release выполняется полный frontend/backend/browser gate;
• текущие количества тестов берутся из npm run inventory, а не копируются навсегда в статусные документы;
• пользовательское изменение одновременно обновляет RU/EN changelog и соответствующую таблицу поведения/руководство;
• release body короткий: только значимые функции, остальное группируется как «Мелкие исправления и улучшения» / “Small fixes and improvements”, плюс ссылки на RU и EN changelog.

Сам этот файл обновляется иначе, чем changelog: завершённая инициатива удаляется, а не отмечается галочкой. Если задача утратила смысл из-за другого решения, она также удаляется с объяснением в ADR/spec или changelog соответствующего изменения.

10. Границы плана

В этот backlog не входят:

• 3D/isometric/фотореалистичное моделирование;
• редактор автоматизаций, сценариев и уведомлений;
• администрирование entity/device/area registry Home Assistant;
• история, графики, energy analytics, camera streams и медиапульт;
• общий dashboard framework;
• облачное хранение или телеметрия пользовательских планов.

Новая идея попадает сюда только если усиливает spatial glance, безопасное быстрое действие, создание/поддержку плана или качество реализации этих сценариев.