«Уведомить о поступлении»: что Friducha реально умеет сообщить сейчас

Когда товара нет в доступном остатке, полезный сервис начинается с точности. Запрос на поступление хранит интерес к той карточке, которую человек действительно выбрал, а не к абстрактной категории «похожие серьги». Если пользователь ждёт родиевые серьги-сердца, появление другой модели само по себе не закрывает его ожидание.

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

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

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

Когда аккаунтная подписка обрабатывается после реального изменения доступности, сервис может создать внутреннее уведомление. Оно остаётся частью «Моей Friducha» и не требует притворяться, что внешний email или push уже существует. Пользователь получает событие внутри системы, которую Friducha действительно контролирует.

Это же правило применимо к BILBAO или любой другой точной модели: сначала должен измениться авторитетный статус доступности, затем уже появляется основание для restock-сигнала. Ни календарное обещание, ни случайный похожий товар не должны запускать уведомление.

Внешний канал — отдельная интеграция со своей доставкой, ошибками и подтверждением. Пока такого рабочего пути для restock не подключено, честная формулировка проста: Friducha хранит и обрабатывает аккаунтное ожидание внутри платформы. Она не пишет «мы отправили письмо» только потому, что где-то сохранён email.

Это не ограничение ради ограничения, а обычное правило продуктовой правды. Лучше явно назвать действующий канал, чем обещать функцию, которая существует только наполовину. Когда внешний delivery-path действительно появится, его можно будет описать отдельно и проверить теми же критериями.