20 октября 2026 года Telegram-канал «Вайб-кодинг» опубликовал 23 рекомендации для проверки приложения перед приёмом первого платежа. Список подсказывает, какие сценарии обсудить с ИИ-агентом, но не подтверждает готовность конкретного приложения к запуску: публикация не сообщает о проведённом аудите. Оригинальный пост в Telegram.
Платежи: подпись, повторы и тестовые сценарии
В платёжной части пост предлагает проверять подпись входящих вебхуков и исключить повторный учёт одного уведомления. Также перечислены возвраты, отмены и неудачные списания: автор советует проверять их в тестовом режиме и убеждаться, что каждый сценарий приводит к правильному статусу. Повторная отправка уведомления не должна создавать второй заказ.
Эти пункты помогают сформировать план проверки до включения реальных платежей. Сам факт, что агент составил таблицу с отметками, не показывает, какие события он действительно смог вызвать и проверить; стоит отдельно запросить результаты и непроверенные пункты.
Безопасность и состояние приложения
Среди рекомендаций — хранить приватные ключи только на сервере, проверить файлы фронтенда и историю Git на утечки, а раскрытые ключи заменить. Пост также предлагает проверить серверную авторизацию и права доступа для каждого API-эндпоинта и включённую в базе данных RLS.
Для интерфейса перечислены единая дизайн-система и отдельные состояния загрузки, отсутствия данных и ошибки. Для внешних сервисов с оплатой по факту использования — например, ИИ, SMS и электронной почты — автор советует настроить лимиты расходов или уведомления. Это пункты списка для проверки, а не сообщения о состоянии какого-либо конкретного приложения.
Данные и восстановление
Пост включает резервное копирование и проверку восстановления в новой базе, SQL-откат для миграций, соответствие политики конфиденциальности фактической работе приложения, производительность на реальных объёмах данных и мониторинг ошибок. Эти проверки затрагивают разные риски: от восстановления после потери данных до обнаружения замедлений и сбоев.
В той же публикации утверждается, что на бесплатном тарифе Supabase нет автоматического резервного копирования, и предлагается перейти на Pro или настроить собственные дампы. Это заявление поста, а не независимо подтверждённое здесь описание текущих условий тарифа; перед выбором способа резервирования следует сверить его с действующей документацией и настройками сервиса.
Какие действия агенту ограничить
В шаблоне запроса автор предлагает распределить аудит между пятью направлениями: дизайн и производительность, безопасность, платежи, данные и работа приложения после запуска. Агенту предлагается сначала выдать таблицу результатов и ничего не исправлять без разрешения. Если для проверки нужен доступ к панели сервиса, пункт следует отметить как требующий подтверждения владельца и дать инструкцию для самостоятельной проверки.
Пост отдельно задаёт безопасные границы: платежи проверять только в тестовом режиме, резервное копирование и восстановление — на тестовой базе, продакшен-данные не менять. Эти ограничения важны, когда агенту поручают аудит: чтение и отчёт не следует автоматически превращать в право изменять рабочие настройки или данные.
Список советов — не результат аудита
Публикация содержит рекомендации и шаблон запроса агенту, но не приводит результатов проверки конкретного приложения. Автор поста не указан. Поэтому список можно использовать как перечень тем для планирования аудита, но он сам по себе не доказывает, что приложение безопасно или готово принимать платежи.
