Push-уведомление должно открывать нужный экран приложения и учитывать уже выполненное действие

У сценария есть разные результаты: событие возникло, сообщение приняли, уведомление показали, человек нажал, приложение открыло заказ. Отчёт об отправке подтверждает только часть пути. Зелёная строка в кабинете провайдера не отвечает на вопрос CTO: «Клиент видит то, ради чего мы его позвали?»

FCM прямо разделяет принятие сообщения и доставку устройству. Телефон может быть без сети, сообщение может ждать подключения и прийти позже. В фоновом режиме обычное notification-сообщение на Android показывает система; проверка заказа в коде приложения не обязательно выполняется перед этим показом.

Поэтому начните приёмку с конкретного заказа. Плохая демонстрация: push пришёл, приложение открылось. Полезная демонстрация: уведомление про этот заказ, нажатие открывает его, состояние соответствует серверу, кнопка ведёт к допустимому действию. Даже правильный текст уведомления не исправляет неверный экран.

План напоминания хранит намерение отправить сообщение позже. Он не хранит истину о заказе навсегда. Когда наступает время отправки, нужно заново проверить оплату, отмену и адресата. Условие «на момент планирования не оплачен» для приёмки недостаточно.

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

Повторная доставка события тоже не должна создавать новую задачу напоминания без причины. Для дедупликации нужен ключ бизнес-сценария, например заказ и назначение напоминания. Ключ схлопывания у провайдера решает другую задачу: заменяет ожидающее сообщение. Он не запрещает приложению дважды решить, что заказ надо оплатить.

Ссылка из уведомления должна называть конкретный объект. Сообщения «заказ ждёт оплаты» недостаточно, чтобы восстановить маршрут. Но идентификатор заказа в сообщении ещё не даёт права его читать: сервер проверяет текущего пользователя и доступ к объекту.

Если человек вышел из аккаунта, приложение сохраняет цель перехода, предлагает вход и после него заново проверяет доступ. Переход на главный экран с потерянным заказом не проходит приёмку. Вход в другой аккаунт тоже не должен раскрывать чужой заказ.

После нажатия приложение получает актуальное состояние. В нашем учебном сценарии заказ уже оплачен: экран показывает результат, повторная оплата недоступна. Сервер тоже проверяет допустимость действия. Если сеть пропала, нужны сообщение об ошибке обновления и повтор загрузки, а не прежняя просьба оплатить как подтверждённый статус.

Для каждой поддерживаемой платформы проверьте переход из активного приложения, из фона и после холодного запуска. На Android официальная рекомендация для обычного экрана включает ожидаемую навигацию назад. Deep link, то есть ссылка на нужный экран, полезен лишь вместе с правильным восстановлением этого пути.

Эта граница уже встречалась у нас в веб-сценариях. В публичном журнале машины виден ход разработки vibecoding.ru; для этой статьи мы дополнительно перечитали записи проверок писем и доступа. Ни одна из этих историй не является мобильным push-кейсом.

Пауза между письмами защищает от частого повтора. Она не отвечает на вопрос, завершилось ли нужное действие. Если доступ уже выдан, но письмо с ним не отправлено, запретить любой повтор означает оставить доставку незавершённой. Состояние бизнеса и состояние уведомления требуют разных записей.

Для приложения отсюда следует критерий: повтор события не создаёт второй заказ или вторую оплату, а повтор доставки не превращает выполненное действие в невыполненное. Если ответ транспорта потерян, команда должна видеть неопределённость и заранее выбранное правило повторной попытки, а не обещание «дубликатов никогда не будет».

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

Отдельно запишите правила для ИИ-агентов: не менять условия оплаты, не ослаблять проверку доступа, не считать подтверждение провайдера подтверждением клиентского результата. Инженер ведёт машину агентов, а CTO принимает решения об устройстве системы и допустимых последствиях повторов.

Если правила оплаты и перехода уже расходятся между модулями, это работа с техническим долгом. Правку нужно довести до всех входов одного сценария: отложенная задача, повтор события, открытие по уведомлению, обычное открытие заказа. Иначе агент починит нажатие, а старое напоминание продолжит приходить из другого места.

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

Автоматические проверки полезны для переходов состояний и повторов. Приёмка на реальном устройстве нужна для поведения ОС, разрешений и запуска приложения. Попросите подтверждение на каждой поддерживаемой платформе и версии, включая отказ от уведомлений: заказ всё равно должен оставаться доступным внутри приложения.

У записи прогона должны быть условие, время события, состояние заказа, версия приложения и ожидаемый результат. Затем видны фактический экран и связанная попытка доставки. Фраза «на моём телефоне работает» без условий не помогает повторить сбой на телефоне клиента.

После выпуска собирайте результат по рубежам. Падение числа переходов может означать проблему маршрута, входа или чтения заказа; его нельзя автоматически объявлять проблемой текста push. Сначала найдите место обрыва, затем верните воспроизводимый сценарий в задачу и проверку.

Назначьте владельца разбора. Ответственность за ошибки ИИ не заканчивается на авторе кода: кто принимает изменение, кто сопоставляет сигнал со сценарием и кто возвращает исправление на проверку? Замкнутый путь заканчивается новым правилом, которое ловит тот же сбой при следующей правке.

Если некому вести такую работу, подписка «Один проект» стоит 250 000 ₽ в месяц на 08.10.2026. Инженер ведёт машину агентов и может работать над связкой события, отправки и экрана в вашем проекте. Возможность работы и границы задачи обсуждаются по вашему приложению.

Для следующего шага откройте адрес теста для руководителя. Сейчас он ведёт на страницу услуг: тест снят. К разговору полезно подготовить одно ошибочное уведомление, состояние заказа и экран после нажатия. Этого хватит, чтобы начать разбор границ задачи.

1. Перед отправкой заново проверяйте, осталось ли действие невыполненным.

2. После нажатия открывайте конкретный объект, проверяйте доступ и читайте свежий статус.

3. Разделяйте повторы бизнес-события и попытки доставки; неизвестный ответ учитывайте отдельно.

4. Принимайте сценарий с оплатой между отправкой и нажатием, входом, отсутствием сети и холодным запуском.

5. Возвращайте обнаруженный сбой в правило и воспроизводимую проверку.