Files
evening_detective_screen/docs/SCREEN-001_ACCEPTANCE.md
T
2026-10-17 18:14:31 +07:00

12 KiB
Raw Blame History

SCREEN-001 — сборки и аппаратная проверка

Статус: аппаратная приёмка открыта. Сборка не доказывает звук, первый кадр, совместимость с проектором или выполнение порога задержки.

Сборки

На каждой целевой ОС установите Node.js 24.15+ и ffmpeg с libx264, выполните команды запуска из README. Зависимости зафиксированы package-lock.json; используйте npm ci. Electron загружается отдельной командой install-electron. Генерация медиа обязательна до упаковки. Пакеты без доверенной подписи/notarization, публикации и автообновления нет.

Среда сборки Команда после подготовки Артефакт
macOS Intel npm run dist -- --mac --x64 release/*.zip
macOS Apple Silicon npm run dist -- --mac --arm64 release/*.zip
Windows x64 npm run dist -- --win --x64 release/*.zip
Windows ARM64 npm run dist -- --win --arm64 release/*.zip
Linux x64 npm run dist -- --linux --x64 release/*.tar.gz
Linux ARM64 npm run dist -- --linux --arm64 release/*.tar.gz

Сборки macOS выполняйте на Mac. На Windows ARM используйте ARM-версию Node.js. Linux tar.gz распаковать с сохранением прав файлов; запуск — исполняемый файл в распакованном каталоге. Архивы Windows распаковать целиком, macOS .app перенести в Applications. Gatekeeper и SmartScreen могут предупреждать о неподписанном приложении; следуйте политике своего компьютера, не отключайте защиту ОС глобально.

Ручной GitHub Actions workflow builds.yml подготавливает шесть вариантов на соответствующих runners и публикует только workflow-артефакты. Агент workflow не запускает, не коммитит и не отправляет в remote. Labels runners сверены с документацией GitHub. CI не заменяет проверку macOS 13, Windows 11 и обоих дистрибутивов Linux.

Windows-стенд собирается с signAndEditExecutable=false: без редактирования иконки/метаданных EXE и без подписи. Брендинг и подписание относятся к SCREEN-008. В workflow выбран ELECTRON_BUILDER_COMPRESSION_LEVEL=1 для быстрой упаковки. Локально при необходимости задайте ту же переменную окружения перед командой сборки (bash: export ELECTRON_BUILDER_COMPRESSION_LEVEL=1; PowerShell: $env:ELECTRON_BUILDER_COMPRESSION_LEVEL='1'). Она меняет степень сжатия архива, содержимое приложения остаётся тем же.

Имена архивов включают ОС и архитектуру; release/ и тестовые медиа игнорируются Git.

Результат программного этапа 17.10.2026

Собраны evening-detective-screen-0.1.0-linux-{x64,arm64}.tar.gz и Windows-архивы evening-detective-screen-0.1.0-win-{x64,arm64}.zip в release/. Контрольные суммы — release/SHA256SUMS. Содержимое app.asar всех четырёх вариантов сверено с проверенным кодом; оба медиафайла присутствуют, тестовые модули исключены. Готовый Linux x64-бинарник проверен на Manjaro: запуск UI/preload и Range — PASS. Сборки macOS не выполнялись, workflow не запускался. Совместимость с целевыми ОС, внешним оборудованием и мобильными браузерами остаётся открытой.

Автоматический smoke

После генерации медиа выполните npm run smoke в графической сессии. Проверка использует синтетический второй дисплей и отдельное браузерное окно вместо телефона: IPC, Range, запуск/пауза/стоп/seek, запрет IPC из окна показа, сопряжение через UI, команды обоих пультов, отзыв доступа и отсутствие автоповтора при открытии окна. Для тестового браузера используется прямое LAN-соединение без системного прокси. Это не проверка реального проектора или мобильного браузера.

В ограниченной среде агента запуск выполнен с тестовыми флагами --no-sandbox --mute-audio --disable-gpu. В обычном запуске npm run dev этих флагов нет. Headless-запуск в данной среде зависал/завершался SIGSEGV; GUI smoke прошёл.

Тестовые файлы

npm run media:generate использует ffmpeg:

  • audio.wav: 60 с, PCM s16le, mono, 48 кГц, синус 1000 Гц с фильтром volume=0.1.
  • video.mp4: 60 с, H.264/libx264, yuv420p, 1280×720, 30 fps; AAC mono 48 кГц, синус 1000 Гц с фильтром volume=0.1; faststart.

Окно показа устанавливает громкость элемента 35%. Начинайте с умеренной системной громкости. Фиксируйте ffmpeg -version, размеры и SHA-256 фактических файлов: битовый результат зависит от версии кодировщика.

Сценарий

  1. До запуска назначить экран компьютера основным в настройках ОС. Записать ОС/версию, архитектуру, CPU/RAM, версию приложения/Electron, размеры медиа, дисплей, разрешение, масштаб, переходник, тип кабеля и аудиовыход.
  2. Включить расширенный рабочий стол, выбрать внешний дисплей, открыть показ. Проверить, что пульт и технические сообщения не видны игрокам. На macOS проверить fullscreen/Spaces и перемещение фокуса между пультом и показом.
  3. После холодного старта запустить аудио без клика в окне показа. Повторить для видео. Проверить физический звук/изображение и отсутствие дублирования звука в пульте.
  4. Для каждого формата выполнить минимум 30 запусков подготовленного медиа отдельно для кабеля/USB и HDMI. Записать медиану/p95 из пульта для выбранного формата. Холодный старт учитывать отдельно. Замеры последних 400 запусков хранятся в RAM и разделены по формату и источнику команды. После перезапуска они сбрасываются.
  5. Проверить pause/stop и seek на 10, 30, 59 с как во время воспроизведения, так и на паузе. Несколько раз быстро чередовать аудио/видео, пуск/паузу/стоп: звук не должен дублироваться; итоговый статус соответствует проигрывателю.
  6. Отключить интернет; локальное воспроизведение и пульт остаются работоспособными.
  7. В своей Wi-Fi/LAN или точке доступа открыть адрес с компьютера на iPhone/Safari и Android/Chrome. Проверить неверный код, ожидание подтверждения, управление с обоих пультов, блокировку телефона, обрыв и восстановление Wi-Fi, отзыв доступа. После восстановления не должна повторяться последняя команда. Снять отдельные замеры телефона; отображаемая задержка НЕ включает путь телефон → компьютер.
  8. Отключить дисплей: окно показа закрывается, пульт остаётся доступен. Подключить снова, открыть показ явно: старое воспроизведение не должно возобновиться.

Сценарий выполнить для macOS x64/ARM64 и Windows 11 x64/ARM64; для Linux x64/ARM64 проверить Ubuntu 24.04 LTS и Debian 13. Bluetooth в матрицу не входит.

Физическая задержка

Числа в UI измеряют только приём команды основным процессом → завершение play(), а не нажатие → звук/кадр. Для физического измерения снимите пульт и фактический проектор камерой не менее 240 fps со звуком, отмечая момент нажатия и начало тестового сигнала/движения изображения (не уже подготовленного неподвижного кадра). Запишите метод, частоту съёмки и погрешность; при неоднозначном моменте нажатия используйте внешний регистратор кнопки/звука/кадра. Для 30 отсортированных значений медиана — среднее 15-го и 16-го, p95 — 29-е. На M1 16 ГБ целевой p95 от нажатия пульта компьютера до физического вывода ≤150 мс. На остальных конфигурациях фиксируем медиану/p95 и стабильность без этого порога.

Протокол результата

Для каждой конфигурации приложить:

  • дата; ОС/архитектура; CPU/RAM; версия приложения/Electron;
  • дисплей/переходник/разрешение; аудиовыход; версии ffmpeg и параметры файлов;
  • холодный старт; 30 исходных значений каждого формата/выхода; медиана/p95;
  • отдельно программная и физическая задержка, способ измерения и погрешность;
  • результаты pause/seek/fullscreen/offline/LAN/reconnect/отзыва;
  • ошибки, ограничения и итог PASS/FAIL.

Пока не пройдена вся матрица и не получены физические измерения M1, SCREEN-001 остаётся IN_PROGRESS, SCREEN-002 не начинается. Результаты владельца фиксируются в TASKS.md; неподтверждённые пункты не объявляются успешными.