mayatnikovandClaude Opus 5
383e374f0f
Отзыв с iPhone после первого живого прогона. Масштабирование запрещено (ADR-066): viewport как в соседнем sixlines плюс viewport-fit=cover, мета-теги установленного приложения, touch-action против двойного тапа и страховка на JS — гашение жестов iOS, потому что мета-строку Safari вправе проигнорировать. Размеры шрифтов не тронуты: 14 px из брифа остаются, поднимать поля до 16 px владелец отклонил. Цена — доступность для тех, кому зум нужен — записана в ADR и в ui.md честно. Версия в подвале (ADR-065, 067): GET /api/config отдаёт короткую ревизию и время коммита. Именно коммита, а не сборки: штамп компиляции в бинаре means каждая пересборка даёт новый хеш, и обещание ADR-022 «бинарь собирается из тега байт в байт» перестаёт проверяться. Самообновление PWA (ADR-068, 070): в режиме приложения на iPhone перезагрузки нет, и старая версия жила бы вечно. Проверка при возврате в приложение, включение ждущей оболочки, перезагрузка — но не тогда, когда в строке набран текст. Замок от петли сравнивает версию оболочки, а не считает перезагрузки: счётчик отменял саму фичу, долгоживущая вкладка переставала обновляться. Замерено: было 30, 60, 120, 240 секунд между релизами, стало ровно 30. Строка ввода — редактируемый блок (ADR-069): iOS рисует над клавиатурой полосу со стрелками и «готово» для полей формы, и убрать её со страницы нельзя. Для contenteditable не рисует. Режим plaintext-only с проверкой, что он применился, и запасным путём с разбором вставки: невалидное значение атрибута в части браузеров делает блок нередактируемым вовсе. Чтение и запись только через textContent, innerHTML в клиенте по-прежнему нет. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015DbCjVfTFq4ZFG8juD45YJ
3.3 KiB
3.3 KiB
ADR-023: Правила пушей и service worker
Кому уходит пуш и тексты уведомления — ADR-045. Адрес перехода, состояния настроек и жизнь подписки на клиенте — ADR-046.
Изменён ADR-068: установленная версия оболочки больше не ждёт закрытия всех вкладок — её включает страница, и она же перезагружается.
Контекст
ADR-011 задаёт принцип «пуш — сигнал». Не определено, когда именно слать пуш, как он привязан к устройству и что кэширует service worker.
Решение
- Push-подписка принадлежит устройству (
devices.push_subscription). СтавитсяPUT /api/devices/{id}/push, снимаетсяDELETE. - Пуш отправляется при постановке сообщения в очередь устройства, если выполняются оба условия: устройство не подключено по SSE и у устройства не висит неотработанный пуш (
push_pending = 0). После отправкиpush_pending = 1; сбрасывается при подключении SSE. Одно молчащее устройство получает один пуш, не ленту. - Полезная нагрузка:
{title, body: "новое сообщение", chat}—titleэто@nickили#имя комнаты,chat— идентификатор для перехода.TTL24 часа, urgencynormal. Ответы 404/410 от push-сервиса удаляют подписку. - Service worker:
push→showNotificationсtag = chat(новое уведомление заменяет старое в том же чате);notificationclick→ фокус открытого окна или открытие/#/<chat>. - Кэш: stale-while-revalidate для оболочки (
/,/app.css,/manifest.json,/js/*,/icons/*), никогда — для/api/*. Имя кэша содержит версию, версия задаётся константой вsw.jsи меняется при релизе. Сервер отдаёт статику сETagиCache-Control: no-cache. - Разрешение на уведомления запрашивается после первого отправленного сообщения (ADR-011). На iOS вне установленного PWA вместо запроса показывается баннер установки.
Следствия
- Сервер знает только, что у устройства есть что забрать; содержимое в пуше не появляется.
- Пользователь с пятью непрочитанными чатами получает один пуш про первый. Остальное — при открытии. Осознанно.
- Релиз без смены версии в
sw.jsобновит статику только по ETag при следующем revalidate, не мгновенно.