Уведомление о поступлении товара агенты добавляют с проверкой варианта и повторов

Начать стоит с проверки возможностей вашей платформы. Webasyst уже предлагает модуль «Уведомление о поступлении»: запрос можно оставить на товар или конкретный артикул. Это указано в описании, проверенном 8 октября 2026.

Срок ожидания тоже есть в готовом модуле. Покупатель задаёт, как долго ему нужно уведомление, администратор видит заявки. Заказывать эти возможности с нуля стоит после проверки того, что уже установлено.

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

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

Физическое поступление на склад ещё не означает возможность купить. Shopify различает доступный к продаже остаток, резерв и ожидаемую поставку. В документации, проверенной 8 октября 2026, зарезервированные единицы не входят в доступные.

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

Отправку запускает изменение состояния выбранного варианта. В нашем контрольном примере доступный остаток вырос с 0 до 3 единиц. Следующее обновление с 3 до 7 не создаёт ещё одного уведомления по той же подписке.

Повтор входящего события входит в приёмку. Документация Shopify, проверенная 8 октября 2026, допускает повтор доставки события после тайм-аута. Поэтому система узнаёт обработанный повтор и сохраняет прежний результат.

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

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

Неизвестный исход требует отдельного решения. Сервис мог принять письмо, а ответ потерялся по дороге. До повтора нужно сверить его идентификатор и статус. Возможность отправить без дубля зависит и от почтового сервиса.

В журнале различаются принятие письма сервисом и доставка покупателю. Отказы должны попадать тому, кто разбирает ошибки. Как устроена ответственность за ошибки агента, разобрано отдельно. Здесь проверяется след конкретной отправки.

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

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

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

Руководитель принимает поведение, а не снимок кнопки. В подтверждении подписки видны вариант и срок ожидания. Ссылка из письма открывает карточку с нужным вариантом. После отправки та же подписка не запускает новую.

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

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

Для одной стандартной кнопки сначала проверяют модуль. Подписка на разработку подходит магазину с очередью изменений: уведомления, фильтры, оформление заказа. Эти задачи выполняют последовательно, с отдельной приёмкой.

Разработка магазина по подписке в тарифе «Один проект» стоит 250 000 ₽ в месяц по странице, проверенной 8 октября 2026. Инженер ведёт машину агентов, в работе одна задача. Код идёт в ваш репозиторий, пауза доступна в любой месяц.

Цена месяца не является сметой уведомления. Объём первой задачи зависит от платформы, источника остатков и почтового канала. Для следующего шага можно обсудить задачу магазина с этим списком сценариев.

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

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

Такая петля связывает поведение функции с новой задачей разработки. Владелец видит, где теряется обращение, инженер исправляет правило и повторяет приёмку. Обещать рост продаж до этого замера было бы выдумкой.

1. Сначала проверить готовый модуль на своих сценариях.
2. Подписывать на конкретный вариант и доступность для покупки.
3. Принимать первое появление доступности вместе с повтором события.
4. Различать ошибку, неизвестный исход и подтверждённую отправку.
5. Считать покупки после уведомлений, причины неудач превращать в проверки.