Как проверять промокоды и восстанавливать лучший результат

ShopTools AI сравнивает сумму до и после проверки промокода на поддерживаемой странице. Проверенная реализация различает снижение и принятие кода без измеренной экономии. Инженеру нужно также сохранить корректное состояние корзины.

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

Снимите исходное состояние до изменения

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

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

Запишите переходы и критерий кандидата

1. Найдите безопасное поле и снимите baseline. Подготовьте ограниченную очередь; запуск возможен только по команде пользователя.
2. Перед отправкой сохраните состояние ожидания ответа. Затем введите код, выполните допустимое применение и дождитесь устойчивого результата.
3. Запишите before, after, currency, причину и позицию кандидата. Измеренное снижение отделите от ответа без измерения.
4. Сравнивайте только сопоставимые результаты. При равной сумме используйте заданный порядок очереди, а не случайное время получения ответа.

Reset является условием следующей попытки

Перед следующим кодом удалите текущий купон безопасным действием и подтвердите возвращение сопоставимого baseline. Очистка поля сама по себе не доказывает, что магазин отменил акцию. Повторно считайте итог после пересчёта.

Если исходное состояние не восстановлено, переходите в safe_stop. Не продолжайте складывать неизвестные эффекты. Удерживать найденный результат можно только пока он подтверждается текущей корзиной; иначе нужен ручной контроль.

Reload не разрешает повторный submit

До возможной навигации сохраните очередь, индекс, baseline, evidence перед попыткой, awaiting_result и идентификатор операции. Ограничьте срок хранения. Не включайте в технический журнал содержимое форм и платёжные данные.

После загрузки проверьте срок, host и контекст checkout. Сначала оцените результат прерванной попытки и только затем решайте, продолжать ли очередь. Один hostname не отличает две независимые корзины на одном магазине.

Предусмотрите идемпотентное завершение: повторная загрузка не должна заново отправлять уже обработанный код. Чужая вкладка, переход на login или истёкшая запись не дают разрешения возобновить изменения. Завершённый pending удаляйте.

Победителя нужно подтвердить повторно

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

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

Минимальный воспроизводимый набор тестов

• Два кода снижают сумму, но победитель не последний; после завершения активен именно подтверждённый победитель.
• Код принят без снижения, валюта меняется или итог позднее возвращается назад: денежный успех не фиксируется.
• Нет кнопки удаления или reset не вернул baseline: следующего применения нет.
• Reload после submit, две вкладки, истёкший pending и повторный запуск: нет двойной отправки или чужого восстановления.
• Повторное применение победителя отклонено: итоговый статус отражает отказ восстановления, а не прошлую экономию.