ai-shipcheck

AI Shipcheck — это локальный сканер готовности к продакшену, ориентированный на приложения, в значительной степени написанные инструментами ИИ-кодинга. Его посылка: ИИ-ассистенты хорошо создают код, который запускается, но хуже создают код, который выживает в продакшене, и в любом случае сообщают о работе как о завершённой. Shipcheck ищет повторяющиеся, скучные пробелы — таблицу Supabase без row-level security, обработчик маршрута, который пишет без проверки вызывающего, переменную NEXT_PUBLIC_, содержащую секрет, конечную точку LLM без ограничения скорости или лимита токенов. Использование — одна команда: npx ai-shipcheck . Без регистрации, без API-ключа, без загрузки исходников. Требуется Node.js 22 или новее. Опции включают --fail-on (например, critical), --min-score, --format (json, markdown, sarif) и подкоманду explain, которая документирует, почему существует правило и как его исправить. Находки сами по себе никогда не приводят к провалу команды; пороги включаются по желанию, поэтому добавление в существующий конвейер обратимо. Коды выхода различают пороги достигнуты, не достигнуты, ошибки использования и внутренние ошибки. Что проверяется Девять категорий оцениваются независимо, на основе 63 правил, каждое с документацией, уязвимой фикстурой, безопасной фикстурой и тестами: - Безопасность: жёстко закодированные учётные данные, секреты за NEXT_PUBLIC_, eval, инъекция оболочки, открытые перенаправления, разрешающий CORS, отключённая проверка TLS, слабая криптография. - Аутентификация: маршруты записи без проверок авторизации, неаутентифицированные серверные действия, проверки привилегий только в браузере, непроверенные вебхуки, неподписанные JWT, раскрытые ключи service-role. - База данных: таблицы без row-level security, политики USING (true), SQL, построенный интерполяцией, нефильтрованные удаления, деструктивные миграции. - Надёжность: проглоченные ошибки, отсутствующие таймауты в путях запросов, необработанные отклонения, повторные попытки без backoff, сборки, игнорирующие ошибки типов. - Тестирование: отсутствие тестов, CI без test/build/typecheck, закоммиченный .only, серверный код без ссылающегося теста. - Наблюдаемость: отсутствие мониторинга ошибок, серверное логирование только в console, отсутствие React error boundary. - Производительность: неограниченные запросы, синхронный ввод-вывод в обработчиках, формы N+1, тяжёлые клиентские импорты. - Доступность: отсутствующий alt-текст, обработчики кликов на неинтерактивных элементах, неразмеченные элементы форм, положительный tabIndex. - Затраты на ИИ: конечные точки LLM без аутентификации или ограничения скорости, без лимита токенов, выбор модели, управляемый запросом, ключи провайдера в браузере. Обнаруживаемые стеки включают Next.js (оба роутера), React, Vite, Express, Fastify, Hono, NestJS, Remix, Astro, SvelteKit, Nuxt, Supabase, Firebase, Prisma, Drizzle, Mongoose, Stripe, OpenAI, Anthropic, Vercel AI SDK, LangChain, tRPC и распространённые тестовые раннеры. Правила, специфичные для фреймворка, выполняются только при обнаружении фреймворка, включая монорепозитории. Вывод и интеграция Отчёт показывает оценку, вердикт, полосы по категориям и находки с файлом, строкой, правилом, серьёзностью и уверенностью. Блокер принудительно устанавливает NOT READY независимо от оценки. Категории, которые невозможно оценить, исключаются, а не получают бесплатные 100. GitHub Action аннотирует находки прямо в diff, записывает Markdown-отчёт в сводку задания, создаёт SARIF для сканирования кода и выводит score, verdict, critical-count и high-count; он включён в один закоммиченный файл, поэтому workflow, закреплённый по тегу, запускает именно этот код. Доверие и охват Инструмент не делает сетевых вызовов и не отправляет телеметрию; ничего в сканируемом репозитории не выполняется — файлы читаются как байты и анализируются лексически. Секреты маскируются везде, где они могли бы быть напечатаны, сканирования ограничены и сообщают об этом при усечении, и есть одна зависимость времени выполнения. Заявленные ограничения явны: только JavaScript и TypeScript; анализ лексический, а не семантический, без межфайловых рассуждений или информации о типах и с отслеживанием taint, которое следует за значением на один переход, поэтому пользовательская обёртка аутентификации, которую он не распознаёт, может дать ложное срабатывание. Маршруты Express и Fastify не покрываются правилами аутентификации, что описывается как крупнейший известный пробел. Инфраструктура для него невидима, поэтому таблица с включённым RLS в панели, но отсутствующая в миграциях, сообщается как неоценённая, а не безопасная. Чистый отчёт означает, что проверки, которые он умеет делать, ничего не нашли, а не что код корректен. Правила были проверены на 20 публичных репозиториях, закреплённых по SHA коммита; триаж их вывода, как сообщается, сократил находки с 5 710 до 2 819 и выявил ошибку лексера, влияющую на номера строк в файлах с многострочными комментариями. Документация охватывает правила, контракт CLI, конфигурацию, оценку, модель доверия, ограничения, модель угроз, архитектуру, добавление правила, выпуск и управление. Лицензия MIT.