AM Написать в Telegram
AI Project Hardening Protocol
Версия: v1.4 Последнее обновление: 26 мая 2026, 22:10 МСК Предыдущих публичных версий: 2 — v1.0, v1.1 Общие изменения v1.4: FAQ/content consistency check, AI IDE compatibility matrix, clearer Artifact Pack / Architecture Source of Truth links, Reviewer Agent clarification, architecture update triggers, mini-checklists for bot / AI-agent / mobile projects, AI-generated migration rollback, AI test strategy, PROMPTS.md example, CTA for teams / CTO и GEO/entity definitions. На этой странице v1.4 добавляет reviewer agent clarification, Self-Protection readiness, light scanner fallback, migration rollback, AI-generated test strategy и device/browser QA priority.

Протокол инженерной доводки AI-проекта

AI Project Hardening Protocol — как превратить AI-generated или vibe-coded проект в инженерно проверенный, понятный и безопасный контур перед merge, deploy и production.

Этот материал подходит для Claude Code, Codex, Cursor, Windsurf, Gemini CLI, Kimi, DeepSeek и других AI IDE/агентов. Суть простая: не просить модель “сразу всё починить”, а провести проект через последовательный аудит AI-generated кода: карта проекта, архитектура, security audit, supply-chain security, тесты, monitoring, alerts, AI costs, план исправлений и только потом безопасные правки.

Быстрый старт Посмотреть все этапы Консультация
Для любого AI Для любой IDE Audit → Plan → Fix 9 prompt-блоков: Шаг 0–8
Короткое определение

Аудит AI-generated кода перед деплоем: что это за страница и зачем она нужна

Протокол инженерной доводки AI-проекта — это практическая методология post-AI code review для проектов, написанных через vibe coding или AI coding. Она нужна, когда код уже “работает”, но еще не ясно, можно ли его безопасно мержить, выкатывать в production или передавать команде.

Если говорить совсем просто: сначала вы заставляете AI понять проект, потом оформить карту и архитектуру, потом провести аудит, потом собрать доказуемый отчет и только после этого разрешаете безопасные точечные исправления. Такой подход подходит для стартапов, MVP, клиентских продуктов, внутренних платформ и AI-сервисов.

По сути это слой vibe coding security: отдельная инженерная проверка после AI-кодинга, где secrets, зависимости, scanner checks, legal/payment-контур и device QA разбираются до релиза, а не после него.

Старт до аудита

Если вы еще только начинаете проект, сначала посмотрите стартовый протокол для vibe coding

Эта страница помогает уже после того, как AI-собранный проект существует и требует инженерной доводки. Если вы еще на нулевом этапе, начните со стартовой архитектуры: intake, границы, AGENTS.md, PROJECT_MAP.md, ARCHITECTURE.md, security baseline и dev/deploy baseline до активной генерации кода.

Сначала открыть стартовый протокол Открыть хаб Vibe Coding Protocols У меня уже есть проект
Что нового

Что нового в v1.4

Общие изменения v1.4

Версия v1.4 от 25 мая 2026, 23:54 МСК — это финальная usability-polish итерация: consistency-check FAQ и prompts, яснее маршруты для AI IDE, понятнее CTA для команд / CTO и меньше путаницы между hub, Starter, Hardening, Templates и Architecture Source of Truth.

  • FAQ/content consistency check.
  • AI IDE compatibility matrix.
  • Clearer Artifact Pack / Architecture Source of Truth links.
  • Reviewer Agent clarification.
  • Architecture update triggers.
  • AI-generated migration rollback, AI test strategy и PROMPTS.md example.

Что изменилось именно на этой странице

  • Добавлено пояснение, как запускать independent reviewer без привязки к одной AI IDE.
  • Readiness Score теперь явно включает Self-Protection readiness.
  • Добавлен Light scanner fallback для случаев, когда Trivy / OSV / Gitleaks недоступны.
  • Добавлен блок rollback для AI-generated migrations.
  • Добавлены AI-generated test strategy и device/browser QA priority.
  • Chunking note внутри full audit prompt оформлен как явная system instruction.
Коротко

Как проверить AI-generated проект перед деплоем

  • Если проект уже навайбкодили — сначала не чините, а проведите аудит.
  • Начните с Light prompt.
  • Соберите PROJECT_MAP.md и ARCHITECTURE.md.
  • Проверьте security, supply-chain, зависимости и секреты.
  • Запустите scanner checks: Trivy / OSV-Scanner / Gitleaks.
  • Проверьте mobile/browser, legal, payments, cookies.
  • Сложите находки в AUDIT_BACKLOG.md.
  • Чините critical/high по шагам и затем повторите проверку.
Bridge

Если вы пришли из Starter Protocol

Используйте уже созданные артефакты как входные данные:

  • Product Brief — проверить, соответствует ли код исходной цели.
  • AGENTS.md — использовать как правила для AI-аудита.
  • PROJECT_MAP.md — обновить после code discovery.
  • ARCHITECTURE.md / Architecture Source of Truth — проверить на актуальность.
  • SECURITY.md — расширить после security-аудита.
  • docs/PROMPTS.md — понять, какие AI-инструкции формировали проект.
  • AUDIT_BACKLOG.md — наполнить findings.

Если этих документов нет — сначала создать минимальный PROJECT_MAP и ARCHITECTURE, потом продолжать audit.

После первого slice

Если вы пришли из Starter после первого vertical slice

Если проект только что прошел Starter Protocol и содержит одну-две первые фичи, не запускайте Full Hardening как “экзамен на production”. Начните с Light Hardening: проверьте связку слоев, секреты, active/deferred surfaces, database/migrations, сборку и наличие README / AGENTS / PROJECT_MAP / ARCHITECTURE.

Full compliance, payments, legal, monitoring, advanced scanners и production readiness можно отложить до Standard / Full режима, если проект еще не идет в production.

Когда использовать

Когда этот протокол особенно полезен

Используйте его после генерации MVP через AI, перед merge в `main`, перед первым deploy, перед запуском онлайн-оплаты, перед сбором заявок и персональных данных, после подключения новой зависимости или внешнего API, а также перед передачей проекта разработчику или ручному аудиту у специалиста.

Solo founder / indie hackerКогда проект собран быстро и нужен понятный pre-production разбор.
Vibe coderКогда код уже есть, но неясно, можно ли его безопасно выкатывать.
Команда без security-инженераКогда нужен баланс скорости и глубины до привлечения человека на внешний review.
Проект с оплатой или ПДнКогда кроме кода важно проверить forms, документы, cookies, payments и legal backlog.
Кому это нужно

Кому нужен этот протокол

Владелец AI-проекта

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

Разработчик

Если нужно быстро понять структуру чужого или AI-generated кода, найти риски и не сломать проект массовыми правками.

Founder / Product owner

Если продукт собран быстро, но перед запуском нужно понять, что реально блокирует релиз, а что можно отложить.

DevOps / Security / Tech lead

Если нужно проверить зависимости, секреты, CI/CD, внешние репозитории, supply chain, тесты, алерты и rollback-путь.

Границы применения

Для кого протокол не подходит

Протокол полезен не всем. Это инструмент первичной инженерной доводки и AI-assisted аудита, а не замена зрелому процессу безопасности и compliance в крупных компаниях.

Enterprise с SOC2 / ISO27001

Там нужен полноценный внутренний процесс, политики, аудиторы, журналирование и формальные контроли, а не только AI-аудит.

Платежи и чувствительные данные

Для медицинских, юридических, финансовых и персональных данных протокол полезен как первый слой, но не как финальное заключение.

Команды с mature security-процессом

Если уже есть CI/CD, SRE, security team и pentest, протокол скорее дополняет чек-лист, а не становится основным процессом.

Проекты, где нужен гарантированный verdict

AI-аудит не должен называться гарантией безопасности. Он снижает риски и помогает собрать evidence, но не обещает абсолютную защиту.

Проблема

Vibe coding audit: почему “код работает” недостаточно

Большинство AI-проектов после vibe coding выглядят готовыми только снаружи. Интерфейс открывается, базовые сценарии работают, но внутри могут оставаться слабая архитектура, hardcoded secrets, небезопасные API, невнятный deploy, опасные зависимости, отсутствие тестов и шумные или отсутствующие алерты.

Главная ошибка — сразу просить AI “починить всё”. Так модель легко переписывает рабочие части, теряет контекст, тащит лишние зависимости и делает вид, что провела architecture review, хотя на деле просто отреагировала на симптомы.

Что часто скрыто

Что обычно не видно после AI-кодинга

  • Проект работает, но архитектура не описана и не проверена.
  • Нет `PROJECT_MAP.md` и `ARCHITECTURE.md`.
  • Нет тестов на критичные сценарии и ручная QA-логика не зафиксирована.
  • Внешние зависимости подключены без нормальной верификации.
  • Нет защиты от supply-chain атак и package hallucination.
  • Нет healthcheck, rollback-плана, мониторинга и алертов.
  • Модель не знает, где остановиться, если ей не задать Definition of Done.
Типовые паттерны

Типичные проблемы после vibe coding

Если проект быстро собирался через AI, проблемы часто выглядят одинаково. Это не значит, что проект плохой — это значит, что перед deploy нужен hardening.

  • Секреты или токены в коде.
  • .env попал в репозиторий.
  • Frontend-only auth.
  • Backend без валидации входных данных.
  • Webhook оплаты без проверки подписи.
  • N+1 запросы или тяжелые запросы без индексов.
Быстрый старт

Быстрый старт: Light-аудит за один промпт

Если проект небольшой или вы хотите быстро понять, есть ли критичные риски, начните с Light-аудита. Это не заменяет полный протокол, но помогает быстро найти блокеры: секреты, опасные зависимости, проблемы запуска, слабую архитектуру и риски перед деплоем.

Перейти к полному протоколу 
Проведи Light-аудит моего проекта.

Цель: быстро найти критичные проблемы перед merge / deploy.

Если проект является первым vertical slice после Starter Protocol, оцени базовую связку и critical blockers, не требуй full production compliance без причины.

Не вноси изменения в код без подтверждения.

Проверь:

1. Запускается ли проект и понятна ли структура.
2. Есть ли hardcoded secrets, токены, ключи, пароли.
3. Есть ли .env.example и безопасен ли он.
4. Есть ли подозрительные зависимости, install scripts, git/tarball dependencies.
5. Есть ли lockfile.
6. Есть ли очевидные security-риски: XSS, открытые API, отсутствие валидации, утечки данных.
7. Есть ли критичные проблемы в auth/access control, если они есть.
8. Есть ли тесты или хотя бы понятный manual QA checklist.
9. Есть ли healthcheck / базовое логирование / понятный rollback.
10. Если доступны сканеры, запусти или предложи команды для Trivy / OSV-Scanner / Gitleaks.
11. Проверить `.github/workflows`, CI/CD configs и deploy scripts на hardcoded secrets, tokens, небезопасные permissions и вывод секретов в logs, если такие файлы есть.
12. Проверены ли mobile/desktop и основные браузеры, если есть UI, формы, таблицы, code blocks или copy buttons.
13. Если есть формы — проверить согласие на ПДн, ссылки на документы и можно ли отправить форму без нужного согласия.
14. Если есть оплата — проверить платежную логику, webhooks, чеки, возвраты и статус заказа.
15. Если есть cookies/analytics — проверить cookie notice, внешние трекеры и передачу данных.
16. Можно ли безопасно мержить или деплоить.

Формат ответа:

- Вердикт: можно мержить / нельзя / можно после правок.
- Топ-5 критичных проблем.
- Какие файлы проверены.
- Какие команды были запущены.
- Какие security scanners были запущены или предложены.
- Какие устройства, браузеры, формы и legal/payment зоны проверялись.
- Что нужно исправить первым.
- Какие проверки запустить после исправлений.

После отчета спроси, начинать ли исправление critical/high проблем.
Условный пример

Как может выглядеть результат Light-аудита

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

Вердикт: можно деплоить только после правок.

Топ-3 проблемы:
1. SEC-001 — найден hardcoded token в конфиге. Риск: утечка доступа. Действие: ротировать токен и вынести в env.
2. PAY-001 — webhook оплаты не проверяет подпись. Риск: ложный статус “оплачено”. Действие: добавить signature verification и idempotency.
3. QA-001 — форма заявки ломается на iOS Safari при открытии клавиатуры. Риск: пользователь не может отправить заявку. Действие: проверить mobile layout.

Команды:
- npm run build — passed
- gitleaks detect --source . --redact — 1 finding
- npm audit — 2 high findings

Следующий шаг:
сначала исправить SEC-001 и PAY-001, потом повторить проверку.
Мой подход

Claude Code, Codex, Cursor: как безопасно проверять AI-проекты

Я не отношусь к AI-generated коду как к “магии”, которую надо либо слепо хвалить, либо сразу переписывать. Сначала проект нужно разметить: понять его карту, слои, точки входа, реальные зависимости, рисковые зоны и границы ответственности. Только после этого можно говорить о security audit, architecture review, production readiness и remediation.

Сначала evidence Сначала находим факты в коде и файлах, а не спорим на уровне ощущений.
Потом архитектура ARCHITECTURE.md должен описывать реальный проект, а не желаемую картинку.
Потом риски Security, supply chain, tests, alerts и deploy оцениваются отдельно и внятно.
И только потом fixes Правки начинаются после отчета, плана и подтверждения человека.
Честные ограничения

Что AI-аудит не покрывает

Этот протокол помогает быстро найти инженерные риски и привести AI-generated проект в более безопасное состояние. Но он не заменяет полноценный pentest, юридический аудит, compliance review и ручную экспертизу критичных систем.

Не заменяет pentest

AI может найти типовые уязвимости, но не гарантирует отсутствие всех способов атаки.

Не заменяет security-инженера

Для платежей, персональных данных, enterprise-систем и regulated-сфер нужен отдельный ручной security review.

Не гарантирует legal/compliance

GDPR, 152-ФЗ, PCI-DSS, HIPAA, SOC2, ISO27001 и другие требования нужно проверять отдельно.

Не знает ваш бизнес лучше вас

AI может проверить внутреннюю логику кода, но не всегда понимает реальные бизнес-правила, договоренности и процессы.

Не дает абсолютной безопасности

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

Почему это важно

Сколько стоит пропустить аудит

Протокол занимает часы. Инцидент может занять дни или недели: утекший API-ключ, сломанный платежный webhook, невыданный чек, ошибка на мобильной оплате, зависимость с уязвимостью, отсутствие согласия на обработку данных или проблемный deploy. Цель протокола — найти такие риски до первых пользователей, а не после запуска.

Что дешевле найти заранее
  • Секреты и токены в коде.
  • Опасные зависимости и package hallucination.
  • Ошибки платежных webhooks.
  • Отсутствие чеков и фискализации.
  • Формы без согласий.
  • Сломанный mobile checkout.
  • Отсутствие rollback.
  • Отсутствие backlog исправлений.
Как работает протокол

9 копируемых prompt-блоков: от настройки режима до финальной проверки

Протокол разбивает аудит AI-проекта на управляемые этапы. Каждый шаг можно копировать отдельно и отдавать своей AI IDE, чтобы модель не тонула в контексте и не начинала массовые правки без разрешения.

Этап 0Настроить режим

Задаем правила, глубину и границы аудита.

Этап 1Code discovery

Собираем evidence map и делаем PROJECT_MAP.md.

Этап 2ARCHITECTURE.md

Проверяем, соответствует ли описание реальному коду.

Этап 3Полный аудит

Архитектура, логика, качество кода, API, база, UI, DevOps.

Этап 4Supply chain

Зависимости, registries, Docker, Actions, лицензии и автообновления.

Этап 5Monitoring и checks

Тесты, алерты, future checks, rollback и регулярные проверки.

Этап 6Отчет и план

Сначала вердикт и roadmap исправлений, без хаотичных фиксов.

Этап 7Fix critical

Исправляем только критичное и только маленькими блоками.

Этап 8Final verification

Проверяем, что блокеры закрыты и новые баги не появились.

Типовой пример

Пример: что может найти такой аудит

Ниже не “обещание результата”, а типовой пример AI-generated проекта после vibe coding, когда код вроде бы готов, но инженерно еще сырой.

До аудита

  • Проект запускается локально, но нет PROJECT_MAP.md и ARCHITECTURE.md.
  • В коде найден hardcoded API key.
  • Зависимости добавлены без проверки.
  • Нет lockfile policy.
  • Нет тестов на главный пользовательский сценарий.
  • Внешний API вызывается без timeout.
  • Нет healthcheck и rollback-плана.
  • AI предлагал пакет, репутация которого не проверялась.

После аудита

  • Создан PROJECT_MAP.md.
  • Создан или обновлен ARCHITECTURE.md.
  • Найденные секреты вынесены в env.
  • Опасные зависимости помечены или заменены.
  • Добавлены critical test cases.
  • Добавлены проверки перед merge.
  • Описан rollback.
  • Составлен план исправлений по приоритетам.

Вывод: проект не просто “работает”, а становится понятнее, безопаснее и предсказуемее для дальнейшей разработки.

AI-specific risks

AI Costs и runaway loops

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

  • Лимиты на количество AI-запросов.
  • Лимиты токенов и стоимости.
  • Rate limiting и timeout.
  • Защита от повторных циклов и runaway loops.
  • Защита от бесконечных background jobs.
  • Fallback при недоступности модели.
  • Алерты на резкий рост расходов.
  • Отключение дорогой функции без падения всего проекта.
Режимы проверки

Сначала выберите глубину проверки и режим действий

Режим Когда использовать Что проверяется
Light Быстрый MVP, pet-проект, первый прогон Блокеры, секреты, запуск, архитектура, критичные баги
Standard Рабочий продукт перед merge или deploy Архитектура, security, тесты, API, зависимости, документация
Full Production, коммерческий проект, данные пользователей Все: security, supply chain, alerts, CI/CD, backup, incident response, AI-risks, cost
Режим действий Что делает AI
Только отчет (Audit only) Только отчет, без изменений
Отчет и исправление критичного (Audit + Fix critical) Отчет и исправление только критичных проблем после подтверждения
Полная доводка (Full remediation) Полная поэтапная доводка после подтверждения
Сравнение подходов

Почему не просто “попросить AI проверить код”?

Обычная просьба “AI, проверь проект” часто дает поверхностный ответ. Автосканеры полезны, но не видят архитектуру, бизнес-логику, платежи, юридические документы и UX на устройствах. Ручной аудит глубже, но дороже и дольше. Этот протокол занимает промежуточное место: AI-assisted проверка с evidence, командами, чек-листами и backlog.

Подход Плюсы Минусы Когда использовать
Просто “AI, проверь код” Быстро Поверхностно, без evidence, высокий риск лишних правок Только для чернового первого взгляда
Snyk / CodeQL / Dependabot Автоматизированные проверки зависимостей и части кода Не видят архитектуру, business logic, UX, legal, payments Как дополнение к протоколу
Security-инженер / pentest Глубоко и профессионально Дороже, дольше, не всегда доступно для MVP Enterprise, финтех, медицина, критичные системы
Этот протокол Баланс скорости и глубины: AI + evidence + scanners + checklist + backlog Не заменяет pentest, юриста и бухгалтера AI-generated MVP, pre-production, стартапы, solo-builders
Копируемая инструкция

Полные prompt-шаги для Claude Code, Codex, Cursor, Windsurf и других AI IDE

Ниже — не сокращенная статья, а рабочий playbook. Можно идти по шагам и копировать каждый prompt отдельно, либо забрать всё сразу и адаптировать под свой процесс.

Перейти к первому шагу
Шаг 0

Выбери режим аудита

Сначала дайте AI правила работы. Это не сам аудит, а рамка: как действовать, чего не делать и когда спрашивать подтверждение.

Ты будешь проводить инженерный аудит AI-generated проекта.

Сначала не вноси изменения в код. Работай поэтапно:

1. Сначала изучи проект.
2. Потом составь карту проекта.
3. Потом создай или обнови архитектурную справку.
4. Потом проведи аудит.
5. Потом выведи отчет.
6. Потом предложи план исправлений.
7. Исправления начинай только после моего подтверждения.

Режим аудита: [Light / Standard / Full]
Режим действий: [Только отчет / Отчет и исправление критичного / Полная доводка]

Общие правила:

- Не переписывай проект целиком без необходимости.
- Не делай массовые правки без подтверждения.
- Не скрывай риски.
- Все выводы подтверждай файлами, строками и причиной.
- Если не хватает контекста, сначала скажи, какие файлы нужно посмотреть.
- Если находишь секреты, не выводи их полностью в отчет.
- Если предлагаешь новую зависимость, сначала проверь ее необходимость, репутацию, поддержку, лицензию и альтернативы.
- После каждого этапа выводи краткий отчет: что изучено, что найдено, что дальше.
- Не ограничивайся только тем, что я явно написал. Если видишь важные риски, пропущенные вопросы, недостающие проверки или смежные проблемы — предложи их отдельно в разделе “Что я мог упустить”.
- После выполнения каждого этапа перепроверь свою работу: сравни результат с исходной задачей, проверь diff/измененные файлы, команды, риски и недостающие проверки.
- Если в процессе обнаружишь баги рядом с задачей: исправь только мелкие безопасные баги, если они прямо связаны с текущей областью; крупные или рискованные изменения не делай без approval — вынеси их в отчет и backlog.
Шаг 1

Code Discovery и PROJECT_MAP.md

Этот этап экономит время и снижает риск ошибок. AI сначала ищет важные части проекта, а не читает все подряд.

Проведи этап Code Discovery.

Цель: найти ключевые части проекта и составить компактную evidence map.

Не меняй код.

Найди:

- основные директории проекта
- entrypoints приложения
- frontend-компоненты
- backend/API endpoints
- модели данных
- слой базы данных
- auth/access control
- env/config файлы
- CI/CD и deploy файлы
- внешние интеграции
- зависимости и lockfile
- тесты
- security-sensitive файлы
- monitoring/alerting файлы
- third-party/supply-chain файлы
- потенциально рискованные зоны

Если доступен более дешевый/быстрый subagent для поиска кода, используй его только для поиска. Он не должен править код и не должен делать финальные выводы.

Ограничения для subagent:

- максимум 50 файлов в evidence map
- максимум 200 строк кода на файл
- максимум 3 уровня обхода зависимостей
- не читать .env, .env.local, .env.production
- не читать бинарники, логи и файлы больше 1MB без необходимости
- не выводить секреты
- для каждой находки указывать confidence: high / medium / low

Формат evidence map:

| Файл | Строки | Символ / endpoint / компонент | Что найдено | Почему важно | Confidence |
|---|---|---|---|---|---|

После discovery создай или обнови файл:

PROJECT_MAP.md

Он должен включать:

- структуру проекта
- ключевые модули
- точки входа
- API/routes
- auth
- database/storage
- external integrations
- CI/CD
- tests
- monitoring/alerts
- supply-chain файлы
- known risky areas
- что нужно изучить глубже
Шаг 2

Создай или обнови ARCHITECTURE.md

Архитектурная справка должна появиться после изучения проекта, а не до него. AI должен описывать реальный код, а не придумывать идеальную архитектуру.

Проверь, есть ли в проекте актуальная архитектурная справка.

Если файла ARCHITECTURE.md нет — создай его.
Если файл есть — проверь, соответствует ли он реальному коду, и обнови при необходимости.

Важно:

- не придумывай архитектуру заранее
- используй только фактически найденные файлы, модули, API, модели и зависимости
- явно помечай места, где информации недостаточно
- не описывай несуществующие компоненты
- указывай реальные файлы и модули
- если есть спорные места, помечай их как “требует уточнения”

ARCHITECTURE.md должен включать:

- назначение проекта
- краткое описание продукта
- общую структуру папок
- описание основных модулей
- точки входа
- frontend / backend / database слои
- основные API / сервисы / интеграции
- поток данных между частями системы
- описание авторизации и ролей
- описание хранения данных
- описание конфигурации и env-переменных
- описание фоновых задач, очередей, cron, workers, если они есть
- описание внешних зависимостей
- описание supply-chain security процесса
- описание мониторинга, логов и алертов
- описание CI/CD и deploy
- описание backup / restore, если применимо
- known risks
- рекомендации по улучшению архитектуры

После создания или обновления выведи краткий отчет:

- что создано/обновлено
- какие части архитектуры понятны
- где есть неопределенность
- какие архитектурные риски обнаружены
Шаг 3

Проведи полный аудит проекта

На этом этапе AI анализирует проект как senior-разработчик, архитектор, QA, security, DevOps и SRE. Код пока не чинится — сначала отчет.

Проведи полный аудит проекта.

Не вноси изменения в код без подтверждения.

Проверь:

1. Архитектура
- структура проекта
- разделение слоев
- циклические зависимости
- большие файлы/компоненты
- масштабируемость
- поддерживаемость
- соответствие ARCHITECTURE.md реальному коду

2. Бизнес-логика
- соответствие ожидаемому поведению
- edge cases
- пустые/невалидные/дублирующиеся данные
- риск потери данных
- риск двойного выполнения действий
- транзакционность и консистентность

3. Качество кода
- баги
- dead code
- дублирование
- маркеры TODO/FIXME внутри кода
- console.log/debug
- async/await ошибки
- race conditions
- memory leaks
- null/undefined проблемы
- типы и стиль

4. Security
- секреты
- env
- auth
- roles
- access control
- XSS
- CSRF
- SQL/NoSQL injection
- SSRF
- RCE
- path traversal
- IDOR
- open redirect
- rate limiting
- brute force protection
- security headers
- cookies/sessions
- sensitive logs

5. API и интеграции
- request validation
- error responses
- private data leaks
- timeouts
- retries
- rate limits
- webhook signatures
- API versioning
- breaking changes
- contract tests

6. База данных
- схема
- индексы
- миграции
- constraints
- backup/restore
- long queries
- N+1
- rollback
- zero-downtime migration pattern: Expand and Contract
- запрет деструктивных миграций без безопасного плана

7. Тесты
- unit
- integration
- e2e
- security
- auth
- regression
- smoke
- contract tests
- missing critical tests

8. UI/UX
- loading/error/empty/success states
- forms
- validation
- mobile/desktop
- accessibility
- double-submit protection

9. Device / Browser QA
- проверить mobile / desktop / tablet
- проверить Chrome / Safari / Firefox / Edge
- проверить отсутствие horizontal overflow
- проверить forms, modals, copy buttons, tables, code blocks
- проверить sticky header / anchor navigation
- проверить touch-friendly размеры кнопок, чекбоксов, ссылок, CTA и элементов оплаты на mobile
- проверить accessibility baseline

10. DevOps
- local setup
- build
- deploy
- Docker
- CI/CD
- .github/workflows, CI/CD configs и deploy scripts на hardcoded secrets, небезопасные permissions, вывод env в logs и actions без pinning
- branch protection
- staging
- rollback
- post-deploy validation

11. Monitoring и alerts
- logs
- metrics
- traces
- healthcheck
- readiness/liveness
- correlation ID / trace ID
- Sentry/Grafana/Telegram/Slack/PagerDuty или аналоги
- alert fatigue risk
- разделение алертов на Critical / Warning / Info

12. Performance
- N+1
- лишние запросы
- caching
- pagination
- slow queries
- memory/CPU
- load testing
- p95/p99 latency
- error rate under load

13. Data privacy
- персональные данные
- sensitive data
- log redaction
- retention policy
- внешние сервисы
- AI prompts/logs

14. Legal / Compliance
- ПДн, РКН, 152-ФЗ
- политика ПДн
- согласия рядом с формами
- cookie / analytics
- трансграничная передача
- документы сайта
- рассылки и рекламные согласия
- что нужно проверить с юристом

15. Payments, если есть оплата
- online payment
- webhooks
- fiscalization
- 54-ФЗ
- online cashier / ОФД
- чек оплаты
- чек возврата
- оферта
- правила возврата
- что нужно проверить с бухгалтером / юристом

16. AI-specific risks, если проект использует ИИ
- prompt injection
- data exfiltration
- unsafe tool calls
- secrets in prompts
- hallucinated actions
- cost limits
- rate limits
- fallback при недоступности модели

17. Security scanners
- Trivy для filesystem/image/misconfig/secrets/license, если доступен
- OSV-Scanner для dependency vulnerabilities, если доступен
- Gitleaks для secrets, если доступен
- если запустить нельзя — дать команды для ручного запуска

Для каждой проблемы укажи:

- приоритет: critical / high / medium / low
- файл
- строки
- описание
- риск
- как исправить
- нужен ли тест
- нужен ли алерт
- блокирует ли merge
- блокирует ли production

Выведи отчет, но пока не исправляй.
Шаг 4

Проверь внешние зависимости и автообновления

Многие риски приходят не из вашего кода, а через npm/pip-пакеты, GitHub Actions, Docker images, внешние репозитории, SDK и update scripts.

Проведи отдельный аудит Supply Chain Security.

Не меняй код без подтверждения.

Проверь:

- внешние репозитории
- npm/pip/composer/go/cargo зависимости
- lockfile
- зависимости из git/tarball/unknown registry
- Docker images
- GitHub Actions / CI workflows
- внешние SDK/API
- плагины
- датасеты
- install scripts: preinstall, postinstall, prepare
- curl|bash паттерны
- eval / Function / shell exec
- obfuscated/minified server-side code
- бинарники непонятного происхождения
- deprecated / abandoned packages
- typosquatting risk
- dependency confusion risk
- package hallucination risk: AI мог предложить несуществующий или новый подозрительный пакет
- license compliance
- GPL/commercial license conflicts
- actions без pinned SHA
- Docker images без pinned digest

Проверь автообновления:

- есть ли update scripts
- не делают ли они pull latest напрямую в main/prod
- создают ли они PR
- есть ли quarantine/sandbox
- есть ли security scan перед update
- есть ли changelog/diff summary
- есть ли staging
- есть ли rollback
- есть ли manual approval для major/security-sensitive updates
- есть ли audit trail

Правило:

Автообновление не должно напрямую менять main или production.
Автообновление должно создавать PR с результатами проверок.

Если процесса нет, предложи минимальную схему:

- THIRD_PARTY.md
- SECURITY_SUPPLY_CHAIN.md
- реестр внешних зависимостей
- allowlist trusted sources
- denylist dangerous packages/licenses/patterns
- quarantine/sandbox
- CI checks на PR
- weekly rescan
- staging перед production
- rollback plan
- alerts на supply-chain risks

В отчете укажи:

- текущий уровень supply-chain безопасности: low / medium / high
- что опасно
- что нужно закрепить версиями
- что нужно удалить/заменить
- какие проверки добавить в CI
- какие алерты добавить
- какие сканеры реально запускались
- что найдено сканерами, а что подтверждено только вручную
Шаг 5

Проверь будущие проверки, мониторинг и alerts

Проект должен не только пройти аудит один раз, но и сам проверяться в будущем: на PR, merge, deploy и по расписанию.

Проверь, есть ли в проекте система будущих проверок, мониторинга и алертов.

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

Проверь:

1. На каждый PR
- lint
- typecheck
- tests
- build
- dependency scan
- secret scan
- security scan
- license scan
- lockfile check
- CI/CD file change check
- Dockerfile check
- migration check

2. На merge в main
- full test suite
- full security scan
- build artifact
- staging deploy
- smoke tests
- healthcheck
- alert при failed checks

3. После deploy
- healthcheck
- smoke tests
- latency check
- error-rate check
- external integrations check
- business-critical scenario check
- rollback trigger

4. По расписанию
- weekly dependency scan
- weekly secret scan
- weekly supply-chain scan
- external API availability check
- backup/restore test
- alerting test
- AI cost check, если применимо

5. Security scanners и блокировки
- добавить scheduled scans
- alert при найденном реальном секрете
- alert при high/critical vulnerabilities
- block merge при critical finding или documented exception flow

Проверь алерты:

Critical:
- production down
- healthcheck failed
- payment/registration/key flow broken
- database down
- high/critical vulnerability
- secret leaked
- deploy failed
- rollback triggered

Warning:
- рост 5xx/4xx
- latency increased
- external API degraded
- failed jobs increased
- dependency scan warning
- high CPU/memory/disk

Info:
- неуспешные логины
- minor validation errors
- non-critical scan findings
- scheduled scan completed

Если файлов нет, создай или предложи:

- MONITORING.md
- ALERTING.md
- RUNBOOK.md
- INCIDENT_RESPONSE.md
- BACKUP_RESTORE.md

Для каждого алерта укажи:

- название
- условие
- критичность
- куда отправлять
- кто реагирует
- что делать
- как проверить восстановление
- как избежать alert fatigue
Шаг 6

Сформируй итоговый отчет и план исправлений

Этот prompt переводит разрозненные findings в понятный вердикт: можно ли мержить, можно ли деплоить и что чинить первым.

Сформируй итоговый отчет по аудиту.

Формат:

## 1. Вердикт

- Merge: да / нет / после правок
- Production: да / нет / после правок
- Staging: да / нет / после правок
- Уровень готовности: low / medium / high
- Уровень безопасности: low / medium / high
- Уровень supply-chain безопасности: low / medium / high
- Уровень мониторинга и алертов: low / medium / high
- Уровень архитектурной зрелости: low / medium / high
- Уровень тестового покрытия: low / medium / high

## 1A. AI Project Readiness Score

Выведи Readiness Score по зонам 0–5 и объясни, что блокирует следующий уровень:

- Architecture readiness
- Security / self-protection readiness
- Supply-chain readiness
- Database / Load readiness
- Deploy readiness
- Device/browser readiness
- Legal/payment readiness
- AI-agent readiness
- Self-Protection readiness
- Database / Load readiness
- Review readiness

## 2. Главные блокеры

Список проблем, которые блокируют merge или production.

## 3. Evidence map

| Файл | Строки | Что важно | Почему проверялось |
|---|---|---|---|

## 4. Архитектура

- что хорошо
- что плохо
- что рискованно
- есть ли PROJECT_MAP.md
- есть ли ARCHITECTURE.md
- что создано/обновлено

## 5. Security

- самые опасные уязвимости
- что исправить обязательно
- какие security alerts нужны

## 5A. Self-Protection / Internal Security

- что проект раскрывает публично;
- какие internal docs, routes, logs, backups или debug-артефакты доступны снаружи;
- где лежит архитектурная справка и нужна ли sanitized/public version;
- какие worker/scanner/browser automation процессы работают с лишними правами;
- какие ограничения по secrets, outbound и webroot нужны;
- что должен увидеть внешний сканер, а что не должен.

## 6. Supply Chain

- опасные зависимости
- внешние repo/API/Docker/GitHub Actions риски
- что закрепить версиями
- что удалить/заменить
- какие проверки добавить
- как выглядит quarantine process;
- как устроен safe update pipeline;
- где нужен rollback.

## 6A. Security scanner results

- какие сканеры запускались
- какие команды
- результаты
- что является noise
- что требует срочного исправления

## 7. Monitoring и alerts

- что есть
- чего не хватает
- какие алерты обязательны
- где риск alert fatigue

## 8. Device / Browser QA findings

- что проверено
- какие устройства / браузеры
- какие проблемы есть
- что блокирует production

## 9. Legal / Compliance findings

- какие данные собираются
- какие документы есть / отсутствуют
- какие согласия нужны
- какие cookie / analytics риски
- какие РКН / 152-ФЗ вопросы
- есть ли трансграничная передача
- что нужно проверить с юристом
- что блокирует production

## 10. Payments / 54-ФЗ findings

- есть ли оплата
- есть ли чек
- есть ли возврат
- есть ли касса / ОФД
- какие документы отсутствуют
- что проверить с бухгалтером / юристом
- что блокирует production

## 11. Data / Privacy / Backup

- sensitive data
- backup/restore
- retention/logging risks

## 11A. Database / Load / Scalability Readiness

- data model / ERD status;
- migration status;
- index / query risks;
- N+1 / pagination findings;
- background jobs / queue needs;
- idempotency findings;
- external API / LLM bottlenecks;
- cache / rate limit notes;
- backup/restore status;
- top scalability risks;
- scalability backlog.

## 12. AI / Cost risks, если применимо

- prompt injection
- unsafe tool calls
- token/cost limits
- hallucinated dependencies

## 13. Критичные проблемы

| Приоритет | Файл | Проблема | Риск | Как исправить | Нужен тест | Нужен алерт |
|---|---|---|---|---|---|---|

## 14. Средние проблемы

| Приоритет | Файл | Проблема | Риск | Как исправить | Нужен тест | Нужен алерт |
|---|---|---|---|---|---|---|

## 15. Мелкие улучшения

Список.

## 16. Definition of Done

Четкий чек-лист, когда проект можно считать готовым.

Минимум:

- нет hardcoded secrets
- нет critical/high vulnerabilities без documented exception
- есть .env.example без реальных секретов
- есть PROJECT_MAP.md
- есть ARCHITECTURE.md
- критичные сценарии покрыты тестами или manual QA
- есть healthcheck
- есть базовый error logging
- есть план rollback
- внешние зависимости зафиксированы
- production deploy не идет напрямую без проверок
- README.md содержит команды локального запуска, сборки, тестов и deploy path или есть задача на его обновление
- проверены mobile и desktop
- проверены основные браузеры
- нет горизонтального скролла
- формы и CTA работают на мобильных
- критичный путь проверен на телефоне
- основные CTA, формы, чекбоксы и элементы оплаты удобно нажимаются на мобильных устройствах
- определено, собирает ли проект ПДн
- есть политика ПДн или задача на ее создание
- есть согласия рядом с формами или задача на их добавление
- cookie / analytics проверены
- документы сайта перечислены
- РКН / 152-ФЗ вопросы вынесены в backlog
- финальный юридический review помечен как внешний шаг
- CI/CD workflow-файлы проверены на hardcoded secrets, опасные permissions и утечки env в logs
- если есть оплата, проверены webhooks
- заказ не считается оплаченным без подтверждения провайдера
- есть чек / фискализация или задача на проверку
- есть оферта / условия возврата или задача на создание
- возвраты описаны
- бухгалтерский / 54-ФЗ review помечен как внешний шаг

## 17. План исправлений

[SYSTEM INSTRUCTION: If the project is large, split the audit into 2-3 passes and start with the first pass. Do not attempt to complete the entire full audit in one uncontrolled response.]

Раздели на этапы:

1. Fix critical
2. Fix high
3. Tests
4. Security hardening
5. Supply-chain hardening
6. Monitoring/alerts
7. Documentation
8. Continuous self-security
9. Final verification

Для каждого этапа укажи:

- какие файлы менять
- какие риски
- какие тесты запускать
- нужен ли approval

Также:

- сформируй Audit Backlog
- раздели задачи по приоритетам
- укажи статус каждой задачи
- отдельно выведи Accepted risks
- предложи, что делать первым

## 17A. Формат выдачи

### Short report
- verdict
- blockers
- top risks
- commands
- next steps
- backlog

### Full report
- все разделы ниже в полном формате

## 18. Continuous self-security plan

- что проверять регулярно;
- как часто;
- кто отвечает;
- какие alerts есть;
- какие risks accepted;
- что вынесено в backlog.

В конце выведи:
- что сделано;
- что проверено;
- что не удалось проверить;
- что я мог упустить;
- какие баги найдены попутно;
- что исправлено попутно;
- что требует отдельного approval;
- какие follow-up задачи добавить в backlog.

После отчета спроси:

“Начать исправление критичных проблем по шагам?”
Шаг 7

Исправь только критичные проблемы

Этот prompt использовать только после того, как отчет изучен и вы согласны на правки.

Начни исправлять только критичные проблемы из отчета.

Правила:

- Не трогай средние и мелкие проблемы.
- Не переписывай проект целиком.
- Делай маленькие изменения.
- Перед каждым блоком правок кратко скажи, что будешь менять.
- После каждого блока выведи отчет.
- Если изменение рискованное — остановись и попроси подтверждение.
- Если нужен новый пакет — сначала объясни зачем, проверь альтернативы, лицензию, поддержку и supply-chain риски.
- Если изменение затрагивает внешние repo/API/package, сначала проведи safe third-party intake и не давай таким интеграциям production secrets до approval.

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

После выполнения перепроверь свою работу: сравни результат с исходной задачей, проверь diff/измененные файлы, команды, риски, недостающие проверки и выведи self-review.

Если в процессе обнаружишь баги рядом с задачей: исправь только мелкие безопасные баги, если они прямо связаны с текущей областью; крупные или рискованные изменения не делай без approval — вынеси их в отчет и backlog.

После исправлений выведи:

- что исправлено
- какие файлы изменены
- какие тесты запущены
- какие тесты не удалось запустить и почему
- какие риски остались
- что нужно проверить вручную
- можно ли переходить к high/medium проблемам
Шаг 8

Повторная проверка после правок

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

Проведи повторную проверку после исправлений.

Проверь:

- исправлены ли критичные проблемы
- не появились ли новые баги
- не сломались ли связанные сценарии
- проходят ли тесты
- проходит ли build
- нет ли новых security risks
- нет ли новых self-protection / public exposure risks
- нет ли новых supply-chain risks
- нет ли новых database/load bottlenecks
- обновлены ли PROJECT_MAP.md и ARCHITECTURE.md
- обновлена ли документация
- есть ли понятный rollback plan
- выполнен ли Definition of Done

Выведи финальный отчет:

- что было исправлено
- что осталось
- что можно отложить
- можно ли мержить
- можно ли деплоить
- запускалось ли independent diff review
- какие findings были
- что исправлено
- что отклонено и почему
- какие validation commands прошли после исправлений
- остались ли risks/follow-up после independent review
- Short report: verdict, blockers, top risks, commands, next steps, backlog
- Full report: все разделы
- Readiness Score по зонам 0–5
- Continuous self-security plan
- что обязательно проверить руками
Advanced

Независимое AI-review после правок

Advanced-практика для проверки активного git diff перед merge/deploy.

После того как AI исправил critical/high находки, полезно не сразу считать задачу закрытой, а дать активные изменения на независимое AI-review. Идея простая: основной AI-процесс вносит правки, а отдельный read-only reviewer без контекста основной переписки смотрит только текущее состояние репозитория, git diff, затронутые файлы и результаты проверок.

Такой reviewer не должен редактировать код. Его задача — найти конкретные actionable findings: баги, регрессии, security/privacy риски, проблемы UX, data integrity, поддерживаемости или тестов.

Основной AI-процесс после этого разбирает findings, исправляет только конкретные actionable проблемы, запускает проверки, объясняет, какие замечания не приняты и почему, и при необходимости повторяет ревью. Цель — не “получить красивую оценку”, а убедиться, что после AI-правок нет очевидных регрессий и красных проверок.

Идея блока вдохновлена подходом Дмитрия Сухарева к независимому loop-review через sub-agents. Здесь описан не его skill и не копия реализации, а общий методологический принцип, адаптированный под Vibe Coding Protocols.

Это не заменяет AI Project Hardening Protocol, scanner checks, тесты, ручное review, pentest или legal/security экспертизу. Это дополнительный контроль качества конкретного diff.

Когда использовать

Когда запускать independent diff review

  • После исправления critical/high findings.
  • Перед merge в `main`.
  • Перед deploy.
  • После крупного refactor.
  • После изменений auth/payment/security-sensitive зон.
  • После изменения database migrations.
  • После AI-generated кода, который затрагивает несколько слоев проекта.

Когда не нужно

  • Для мелкой правки текста.
  • Для очевидной one-line правки.
  • Если validation уже red — сначала починить проверки.
  • Если нет git diff или changes не зафиксированы в worktree.
  • Если reviewer не может увидеть файлы или diff.
Reviewer Agent

Как запустить independent reviewer

Это можно сделать разными способами: отдельный subagent, если AI IDE поддерживает subagents; отдельная новая сессия или чат с тем же репозиторием; отдельный read-only review prompt в Codex / Claude Code / Cursor / Windsurf; или ручная передача git diff и changed files в другой AI.

  • Reviewer не должен наследовать аргументацию основной сессии.
  • Reviewer не редактирует файлы.
  • Reviewer смотрит git status, diff, touched files и validation output.
  • Reviewer возвращает only actionable findings.

Здесь не используется название /loop-code-review и не копируется чужой skill: это vendor-neutral clarification для независимого read-only review.

Independent Review

Read-only review активных git changes

Отдельный reviewer смотрит только активный diff, не редактирует код и возвращает actionable findings.

Проведи независимое read-only review активных изменений в текущем репозитории.

Важно:
- не используй контекст предыдущей переписки;
- не редактируй файлы;
- не делай commit, reset, stash или push;
- смотри только текущее состояние репозитория, git status, git diff, затронутые файлы и результаты проверок;
- оцени только изменения в текущем diff, не уходи в unrelated legacy-проблемы.

Проверь:
1. correctness / возможные баги;
2. regressions;
3. security / privacy риски;
4. data integrity;
5. UX / edge cases;
6. maintainability;
7. missing high-value tests;
8. соответствие архитектуре проекта.

Верни результат в формате:

## Findings

Для каждого finding:
- severity: critical / high / medium / low;
- file:line;
- что не так;
- почему это важно;
- как исправить.

## No actionable findings

Если конкретных actionable замечаний нет, скажи это явно.

## Validation notes

Какие проверки стоит запустить или какие результаты проверок ты видел.

## Что я мог упустить

Если видишь важные риски рядом с текущим diff, недостающие проверки или смежные проблемы, перечисли их отдельно, но не превращай review в rewrite unrelated частей проекта.

## Review verdict

- pass / pass with notes / needs changes

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

AI должен показывать, что именно он проверил

Одна из проблем AI-аудита — модель может написать “зависимости проверены”, но не запустить ни одной команды. Поэтому в отчете нужно требовать конкретные команды и результаты.

В итоговом отчете AI должен указывать: какие команды запущены, какой результат получен, что не удалось запустить, почему не удалось и какие проверки нужно выполнить вручную.

Node / JS

npm audit
pnpm audit
yarn audit
npm run lint
npm run typecheck
npm run build
npm test
grep -R "API_KEY\|SECRET\|TOKEN\|PASSWORD" .

Python

pip-audit
safety check
pytest
ruff check .

PHP / Laravel

composer audit
php artisan test
php artisan config:show

Другие стеки

# Go
go test ./...
go list -m all
govulncheck ./...

# Rust
cargo test
cargo audit

# Java / Kotlin
./gradlew test
./gradlew dependencyCheckAnalyze

Важно: не заставляйте выполнять команды, которых нет в проекте. AI должен сначала определить стек и доступные scripts.

Device / Browser QA

Проверка AI-проекта на устройствах и браузерах

Даже если проект проходит security-аудит, он может быть непригоден для пользователей: ломаться на мобильных, Safari, старых Android, маленьких экранах, планшетах или при медленном интернете. Поэтому после AI-кодинга нужно проверять не только код, но и реальные пользовательские устройства.

Что проверить
  • Desktop: Chrome, Safari, Firefox, Edge.
  • Mobile: iOS Safari, Android Chrome.
  • Tablet, если продукт предполагает использование на планшете.
  • Маленькие экраны: 360–390px, большие экраны: 1440px+.
  • Landscape / portrait, touch interactions и hover-зависимые элементы.
  • Достаточно ли крупные touch targets: кнопки, чекбоксы, ссылки, CTA и элементы оплаты на mobile.
  • Формы, мобильную клавиатуру, модальные окна и выпадающие меню.
  • Таблицы, code blocks, copy buttons, sticky header и anchor navigation.
  • Отсутствие горизонтального скролла и читаемость шрифтов.
  • Контрастность, loading / error / empty states.
  • Медленную сеть и сценарии с частично недоступным JS, если это критично.
  • Базовую доступность: focus states, keyboard navigation, alt text, aria-labels.
Практический смысл

Почему это важно

Многие AI-generated интерфейсы выглядят нормально на десктопе разработчика, но ломаются на реальных пользовательских устройствах. Чаще всего проблемы всплывают в формах, sticky-блоках, таблицах, checkout и кнопках копирования.

Этот блок не заменяет полноценное QA на реальном парке устройств, но помогает вынести в backlog типовые Device QA и Browser QA риски до релиза.

Зона Что проверить Почему важно
Mobile 360–390px, формы, меню, кнопки Большая часть пользователей приходит с телефона
Safari layout, clipboard, sticky blocks Частые отличия от Chrome
Tables / code нет overflow, сохраняется читаемость Технические страницы и dashboard-экраны часто ломаются здесь
Forms input, validation, keyboard, CTA Главный источник UX-багов и потери конверсии
Accessibility focus, contrast, keyboard Доступность и качество интерфейса
Legal / Compliance

Legal compliance: РКН, 152-ФЗ и документы сайта

Технически рабочий проект может быть юридически неготовым. Если сайт собирает заявки, email, телефон, Telegram, cookies, аналитику, платежные данные или пользовательские аккаунты, нужно проверить документы, согласия, хранение данных и требования к пользовательскому контуру.

Это не юридическая консультация. Протокол помогает найти очевидные legal/compliance риски и подготовить список вопросов, но финальные документы и выводы должен проверять профильный юрист или специалист по персональным данным.

Персональные данные

  • Собирает ли сайт ФИО, email, телефон, Telegram, адрес, IP, cookie, user ID.
  • Есть ли политика обработки персональных данных и согласие на обработку.
  • Есть ли отдельное согласие на рассылку, если есть email/SMS/мессенджер-рассылки.
  • Есть ли cookie notice / cookie policy, если используются cookies или analytics.
  • Есть ли чекбокс согласия рядом с формами и нельзя ли отправить форму без нужного согласия.
  • Есть ли дата обновления документов, цели обработки, состав данных, сроки хранения и порядок отзыва согласия.
  • Нужно ли уведомление Роскомнадзора и есть ли вопросы по локализации баз с ПДн в РФ.
  • Есть ли трансграничная передача данных и передача в CRM, Telegram, email, платежные или AI API.
  • Не попадают ли ПДн в AI prompts, logs, analytics и error trackers без необходимости.

Документы сайта

  • Политика обработки персональных данных.
  • Согласие на обработку персональных данных.
  • Cookie policy / cookie notice.
  • Пользовательское соглашение, если есть аккаунты.
  • Публичная оферта, если есть продажа услуг или товаров.
  • Правила возврата, если есть оплата.
  • Контакты и реквизиты владельца.
  • Информация об ИП / ООО / самозанятом, если применимо.
  • Документы по рассылке и согласию на рекламу, если есть маркетинговая коммуникация.

Логи и хранение

  • Не пишутся ли ПДн в логи без маскирования.
  • Не пишутся ли токены, cookies и session IDs в логи.
  • Есть ли retention policy и удаление данных по запросу пользователя.
  • Есть ли backup, кто имеет к нему доступ и как защищено хранение.
  • Не хранятся ли данные дольше, чем это действительно нужно.
  • Есть ли список внешних processors и основания передачи данных подрядчикам.

Рассылки, реклама и коммуникации

  • Есть ли email / SMS / Telegram-рассылки.
  • Есть ли отдельное согласие на маркетинговые сообщения.
  • Можно ли отписаться и логируется ли согласие.
  • Не отправляются ли письма без согласия.
  • Есть ли double opt-in, если он нужен.
  • Есть ли политика по хранению подписчиков и передаче контактов в сервисы рассылок.

Analytics, cookies и внешние трекеры

  • Какие аналитические системы подключены и какие cookies ставятся.
  • Есть ли cookie notice и отказ от необязательных cookies, если это требуется.
  • Передаются ли данные за рубеж и есть ли third-party processors list.
  • Не попадают ли email / phone / user ID в analytics URL, events или пиксели.
  • Есть ли IP anonymization и ограничение передачи ПДн в рекламные системы, если применимо.

Документы и реквизиты

  • Кто владелец сайта / сервиса и указаны ли контакты.
  • Есть ли реквизиты, support contact и рабочие ссылки на документы.
  • Есть ли оферта, политика ПДн, согласия и правила возврата, если они нужны.
  • Есть ли дата обновления документов и не битые ли ссылки на них.
Payments / 54-ФЗ

Если есть онлайн-оплата: 54-ФЗ, чеки и возвраты

Если проект принимает оплату, одной интеграции эквайринга недостаточно. Нужно проверить юридическую и техническую часть платежей: оферту, корректный статус заказа, возвраты, webhooks, фискализацию, отправку чеков и обработку ошибок.

Это не бухгалтерская или юридическая консультация. Для финальной проверки 54-ФЗ, налогов, чеков, ОФД и статуса продавца нужен бухгалтер, юрист или специалист по онлайн-кассам.

Платежная логика

  • Есть ли платежный провайдер и разделение test / production режима.
  • Не лежат ли payment secret keys во frontend.
  • Проверяются ли webhook signatures и есть ли защита от replay attack.
  • Заказ не считается оплаченным до подтвержденного webhook.
  • Webhook idempotent и повторный webhook не создает дубль оплаты.
  • Правильно обрабатываются failed / canceled / refunded payments.
  • Есть лог платежных событий, reconciliation и manual review для спорных платежей.
  • Пользователь получает понятный статус оплаты.

Онлайн-касса, чеки и фискализация

  • Нужна ли онлайн-касса для модели проекта.
  • Есть ли интеграция с онлайн-кассой и ОФД.
  • Формируется ли чек при оплате и отправляется ли покупателю на email / SMS.
  • Корректны ли реквизиты чека, номенклатура, сумма, НДС и способ расчета.
  • Формируется ли чек возврата и что происходит при частичном возврате.
  • Есть ли алерт на невыданный чек и лог по failed fiscalization.
  • Есть ли ручной процесс исправления проблемы с чеком.

Документы для оплаты

  • Публичная оферта и описание услуги / товара.
  • Цена, валюта, условия оплаты и возврата.
  • Контакты продавца и реквизиты.
  • Политика обработки ПДн и согласие на обработку данных.
  • Согласие на получение чека на email / телефон, если применимо.
  • Пользователь понимает, что покупает и у кого.

Приоритет для большинства публичных web/MVP: Mobile viewport, Safari / iOS WebView, Chrome Android, Desktop Chrome/Firefox, затем edge cases. Для desktop/internal проектов приоритет может быть другим.

Сканеры

Сканеры безопасности: не верьте только словам AI

AI может написать “я проверил зависимости и секреты”, но без реального запуска инструментов это остается предположением. В нормальном аудите модель должна либо запустить доступные сканеры, либо честно сказать, что не может их запустить, и дать команды для ручной проверки.

Сканеры не заменяют security-инженера и не дают абсолютной гарантии безопасности. Но они превращают аудит из “модель подумала” в проверяемый процесс: какие директории сканировали, какими командами, что нашли, что является шумом, что требует немедленного исправления.

Отдельно стоит проверять CI/CD workflow-файлы. Секреты из GitHub Secrets и аналогов AI обычно не видит напрямую, но он должен проверить `.github/workflows`, deploy scripts и CI-конфиги: нет ли захардкоженных токенов, небезопасных permissions, `curl|bash`, вывода env в logs и actions без pinning.

Trivy

Trivy — универсальный security scanner. Его можно использовать для проверки файловой системы проекта, Docker images, rootfs сервера, misconfigurations, secrets, licenses и известных уязвимостей.

vulnerabilities misconfigurations secrets licenses filesystem / image / rootfs

OSV-Scanner

OSV-Scanner проверяет зависимости проекта по базе OSV и помогает находить известные уязвимости в lockfile, manifest и dependency graph.

npm / pnpm / yarn pip / poetry composer go modules cargo

Gitleaks

Gitleaks ищет утечки секретов: API-ключи, токены, пароли, private keys и другие чувствительные значения в файлах и git history.

secrets in files secrets in git history CI / pre-commit redact output
Команды для проекта

Примеры команд для репозитория

Эти команды нужно адаптировать под стек, версию инструментов и окружение. AI не должен слепо запускать команды, которых нет в системе. Сначала нужно определить стек, package manager, lockfile, CI и структуру проекта.

trivy fs --scanners vuln,secret,misconfig,license --severity HIGH,CRITICAL .
osv-scanner scan source -r .
gitleaks detect --source . --redact
Если проверяется сервер

Команды для VPS и live-окружения

Если проект уже живет на VPS/сервере, отдельный риск — не только код приложения, но и системное окружение: пакеты ОС, старые конфиги, артефакты деплоя, `.env`, backup-файлы, root-директория, старые ключи и логи.

trivy rootfs --severity HIGH,CRITICAL /
trivy fs --scanners vuln,secret,misconfig /var/www
gitleaks detect --source /var/www --redact

Сканирование `/root`, `/etc`, backup-директорий и всего rootfs может дать много находок. Большие числа не всегда означают катастрофу, но требуют triage. Особенно внимательно нужно проверять реальные `.env`, cloud credentials, deploy keys, SSH keys, API keys, CI tokens и backup-архивы.

Triage

После сканирования нужен triage

Нельзя просто увидеть “много HIGH/CRITICAL” и сделать вывод “все сломано”. Нужно отделить реальные риски от шума.

  • Critical exploitable сейчас.
  • High, но только при определенной конфигурации.
  • Medium/Low, можно запланировать.
  • False positive / noise.
  • Требует ручной проверки.
  • Нужно обновить пакет, заменить зависимость или закрыть права доступа.
  • Нужно ротировать секрет или удалить артефакт.
  • Нужно добавить проверку в CI.
Если найден секрет

Секрет считается скомпрометированным

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

  • Не выводить секрет полностью в отчет.
  • Показывать только файл, строку, тип секрета и masked value.
  • Проверить, настоящий это секрет или тестовый пример.
  • Если секрет реальный — сразу ротировать ключ / токен / пароль.
  • Удалить секрет из текущих файлов и проверить git history.
  • Проверить, не использовался ли секрет злоумышленниками.
  • Добавить Gitleaks / secret scan в CI.
  • Добавить `.env.example` без реальных секретов и правила в `SECURITY.md`.
EXAMPLE_API_TOKEN=[masked-example-not-real]
EXAMPLE_DATABASE_CONNECTION=[masked-example-not-real]
Тип находки Что значит Что делать
Реальный секрет Ключ / токен / пароль мог утечь Ротировать, удалить, проверить историю и смежные доступы
HIGH / CRITICAL CVE Уязвимость в пакете, образе или ОС Проверить эксплуатационность, обновить или оформить documented exception
Misconfiguration Небезопасная настройка Исправить конфиг и добавить проверку
License issue Риск по лицензии Проверить совместимость и при необходимости заменить пакет
False positive Сканер ошибся или нашел тестовый пример Задокументировать исключение и не смешивать его с реальными рисками

Как встроить сканеры в будущий процесс

  • На каждый PR: Gitleaks, dependency scan, lockfile check, suspicious install scripts, license check.
  • На merge/main: full dependency scan, Trivy scan, build/test/security checks, alert при high/critical.
  • По расписанию: weekly dependency scan, weekly secret scan, weekly Trivy scan, проверка новых advisories и устаревших пакетов.

Block merge правила

  • Реальный секрет = block merge.
  • New critical vulnerability = block merge или documented exception.
  • Suspicious dependency = manual review.
  • Изменился CI/CD workflow = manual review.
  • Изменился lockfile = dependency review.

Что должно попасть в отчет

  • Какие сканеры запускались и какими командами.
  • Какие версии инструментов доступны.
  • Какие директории и lockfile проверялись.
  • Краткая статистика и топ реальных рисков.
  • Что является noise и что требует ручной проверки.
  • Какие секреты нужно ротировать и какие пакеты обновить.
  • Какие проверки добавить в CI и что проверить после исправлений.
Security scanner report

Пример структуры scanner-отчета

## Security scanner report

### Commands
- trivy fs ...
- osv-scanner ...
- gitleaks ...

### Summary
- Critical: N
- High: N
- Secrets: N
- License issues: N
- False positives/noise: N

### Top risks
1. ...
2. ...
3. ...

### Required actions
- rotate ...
- update ...
- remove ...
- add CI check ...
Internal security

Self-Protection: насколько проект защищает сам себя

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

Public exposure

  • Проверьте .env, .git/, .svn/, .DS_Store, README.md, CHANGELOG.md, AGENTS.md, PROJECT_MAP.md, ARCHITECTURE.md, SECURITY.md, .bak, .zip, logs, dumps и source maps.
  • Проверьте stack traces, debug endpoints, OpenAPI/Swagger docs, admin panels, test/staging routes и internal metrics.
  • Проверьте directory listing, robots/sitemap и публичные tokens.

Architecture docs protection

  • Есть ли архитектурная справка и где она хранится.
  • Не лежит ли она в public webroot и нужна ли sanitized public version.
  • Нужно ли шифрование и кто имеет доступ.
  • Есть ли проверка curl -I по публичным путям документации.
  • Не индексируется ли лишняя документация через robots/sitemap.

Runtime / process isolation

  • Какие процессы запущены и кто запускает API, worker и automation.
  • Не работают ли scanners/browser automation под root без необходимости.
  • Есть ли restricted user, resource limits, rate limits и outbound restrictions.
  • Нет ли доступа worker к production secrets сверх необходимости.

Admin / internal endpoints

  • Проверьте /admin, /api/admin, /debug, /metrics, /health, /docs, /swagger, /graphql, /playground, /internal.
  • Проверьте внешнюю доступность, auth/IP allowlist, rate limits и logging.

Self-scan

  • Проверьте проект как внешний сканер: какие endpoints видны, какие headers раскрывают stack и какие docs индексируются.
  • Проверьте, что crawlers не видят private docs, exposed panels и лишние assets.
Supply-chain security

Safe Integration: внешние репозитории, API, пакеты и автообновления

Любой внешний репозиторий, starter template, API client, npm/pip/go/rust package, Docker image, GitHub Action или dataset может быть supply-chain риском. Его нельзя подключать напрямую в production без допуска, карантина, сканирования и rollback.

Особый риск: AI Package Hallucination

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

  • Существует ли пакет в официальном registry.
  • Кто автор и когда пакет создан.
  • Сколько скачиваний и есть ли репозиторий.
  • Есть ли maintenance, issues и нормальная лицензия.
  • Нет ли похожего популярного пакета с другим названием.
  • Нет ли `postinstall` / `preinstall` scripts.
  • Не похож ли пакет на typosquatting-версию.

Безопасные автообновления

Для обновлений зависимостей лучше использовать Dependabot или Renovate, но только в режиме PR + checks + review. Автообновление не должно напрямую менять `main` или production.

  • Обновления идут через PR.
  • Есть changelog или diff summary.
  • Проходят tests, build и security scan.
  • Major updates требуют ручного approval.
  • Security-sensitive packages требуют отдельного review.
  • Есть rollback plan.

License compliance

Проверять нужно не только уязвимости, но и лицензионные конфликты, особенно в коммерческих AI-проектах.

  • GPL / AGPL зависимости в коммерческом проекте.
  • Unknown licenses и packages without license.
  • Несовместимость лицензий между зависимостями.
  • Внешние assets, fonts, icons и images с непонятными правами.
Third-party intake checklist
  • Проверьте origin URL, owner/maintainer, license, release tags и commit history.
  • Проверьте lockfile, install scripts, postinstall/prepare, curl|bash patterns, binary files и minified server-side code.
  • Проверьте GitHub Actions/workflows, root requirements, доступ к secrets, сетевую активность, known vulnerabilities, package hallucination и typosquatting risks.
  • Проверьте license compatibility и update policy.
Quarantine и safe updates
  • Скачивайте внешние repo в quarantine, не в основной проект.
  • Не давайте production secrets, production DB и доступ к internal network.
  • Прогоняйте gitleaks / trivy / osv-scanner или доступные аналоги.
  • Фиксируйте commit/tag/version и запись в THIRD_PARTY.md / integrations registry.
  • Automation opens upgrade proposal, not silently patches production.
  • Safe update process: quarantine → verify release/checksum → scans → staging → smoke/security regression → PR → approval → rollback point.
Growth readiness

Database / Load / Scalability Readiness

Проверьте, не придется ли переписывать проект при первых пользователях. AI-generated проекты часто работают на демо-данных, но ломаются при росте: N+1 запросы, отсутствие индексов, синхронные тяжелые операции, неидемпотентные webhooks, отсутствие очередей и observability.

Database schema

  • Есть ли ERD / data model и migration history.
  • Нет ли ручных schema changes без миграций.
  • Есть ли primary keys, foreign keys, unique constraints и indexes под реальные query patterns.
  • Нет ли N+1, unbounded queries, SELECT * в горячих путях и больших blobs без стратегии.
  • Есть ли backup/restore plan и soft delete/audit trail, если нужно.

Request / background jobs

  • Какие операции выполняются синхронно, а какие нужно вынести в background jobs.
  • Есть ли queue/worker model, retry/backoff и хотя бы backlog-задача на dead-letter handling.
  • Есть ли idempotency keys для webhooks/payments/imports и защита от duplicate processing.
  • Есть ли timeout на внешние API и rate limiting.

API / LLM / external services

  • Где внешние API находятся в critical path.
  • Есть ли quota/rate limit handling и fallback/degradation mode.
  • Есть ли cost guardrails для LLM/API и защита от runaway loops.
  • Есть ли caching/coalescing и политика для чувствительных данных.

Performance / capacity

  • Есть ли performance budget, baseline response time и load-sensitive endpoints.
  • Есть ли pagination, file upload limits и max request body size.
  • Есть ли observability по slow requests/errors и slow query visibility.
  • Есть ли plan для first likely bottleneck и scalability backlog.
Migrations

Rollback для AI-generated migrations

  • backup перед применением миграций;
  • миграции не применять к production без approval;
  • down migration или rollback plan;
  • staging / copy-of-data test;
  • проверка destructive operations;
  • expand-and-contract для zero-downtime изменений;
  • migration notes в DEPLOYMENT.md или Architecture Source of Truth;
  • после миграции — smoke test и monitoring.
Final report

В итоговом отчете обязательно укажите:

  • migration rollback status;
  • destructive migration risks;
  • staging migration result.
Continuous improvement

Self-security нужно периодически пересматривать

Безопасность проекта не заканчивается одним аудитом. Меняются зависимости, внешние API, scanner rules, инфраструктура, законы, браузеры, cloud-провайдеры и поведение AI-агентов. Поэтому self-protection надо регулярно пересматривать.

Checklist
  • Scheduled dependency scan и secret scan.
  • Scheduled public exposure check и scanner/tools update log.
  • Alerting review и backup/restore review.
  • Architecture docs access review и third-party registry review.
  • Env/secrets rotation review, incident backlog review и accepted risks review.
Exit Criteria

Exit Criteria после Hardening

  • Выбран режим: Light / Standard / Full.
  • Audit report сформирован.
  • Blockers классифицированы.
  • Critical/high findings исправлены или явно accepted with reason.
  • Scanner results зафиксированы или указано, почему scanners не запускались.
  • Self-protection / public exposure проверены.
  • Database/load readiness оценены.
  • Legal/payment зоны проверены по применимости.
  • Independent diff review проведен для важных правок или явно отложен.
  • AUDIT_BACKLOG.md обновлен.
  • Remaining risks и next steps понятны.
Verdict

Passed Light Hardening не равно production-ready. Указывайте verdict явно:

  • ready for next iteration
  • ready for staging
  • ready for limited release
  • production blocked
  • production ready after human review
Readiness layer

AI Project Readiness Score

Это не сертификация и не гарантия безопасности. Это быстрый способ понять, где слабое место проекта перед merge, deploy или production.

  • Architecture readiness
  • Security / self-protection readiness
  • Supply-chain readiness
  • Database / Load readiness
  • Deploy readiness
  • Device/browser readiness
  • Legal/payment readiness
  • AI-agent readiness
  • Review readiness

Review readiness учитывает наличие AGENTS.md, audit backlog, validation flow и independent diff review для важных изменений. Self-Protection readiness — 0–5 - оценивает public exposure, private docs, admin/internal endpoints, secrets/logs/backups, worker/process isolation, scanner exposure и safe update policy. Database / Load readiness — 0–5 - оценивает data model, migrations, indexes, queues/jobs, rate limits, bottlenecks и observability.

Как читать score
  • 0–1: нет данных / высокая неопределенность
  • 2–3: есть база, но нужны исправления
  • 4: можно готовить к staging / limited release
  • 5: зона хорошо описана и проверена, но все равно требует регулярного review
Definition of Done

Когда проект считается готовым

Протокол не должен превращаться в бесконечное улучшение. В конце нужен четкий критерий завершенности: что уже достаточно хорошо для merge и production, а что еще остается риском.

PROJECT_MAP.md создан или обновлен
ARCHITECTURE.md создан или обновлен
Нет hardcoded secrets
Нет critical/high vulnerabilities без осознанного исключения
.env.example есть и не содержит реальных секретов
Основные зависимости зафиксированы lockfile / version / commit SHA
Критичные пользовательские сценарии проверены тестами или manual QA
Есть базовый healthcheck
Есть базовое логирование ошибок
Есть план rollback
Есть список блокеров и исправлений
AI не внес массовые правки без approval
Для важных AI-правок проведено independent diff review или есть явная причина не запускать его
Запускались или явно предложены security scanners
Результаты сканеров разобраны через triage
Реальные секреты отсутствуют или ротированы
High/critical findings исправлены или имеют documented exception
Gitleaks / secret scan добавлен в CI или описан как обязательная ручная проверка
Dependency scan добавлен в CI или описан как обязательная ручная проверка
Создан или обновлен AUDIT_BACKLOG.md / issue backlog
Все critical/high находки имеют задачу, владельца и статус
Accepted risks явно зафиксированы
README.md содержит команды локального запуска, сборки, тестов и deploy path или есть задача на его обновление
Проверены mobile и desktop
Проверены основные браузеры
Нет горизонтального скролла
Формы и CTA работают на мобильных
Критичный пользовательский путь проверен на телефоне
Основные CTA, формы, чекбоксы и элементы оплаты удобно нажимаются на мобильных устройствах
Определено, собирает ли проект персональные данные
Есть политика ПДн или задача на ее создание
Есть согласия рядом с формами или задача на их добавление
Cookie / analytics проверены
Документы сайта перечислены и ссылки на них рабочие
РКН / 152-ФЗ вопросы вынесены в legal backlog
Финальный юридический review отмечен как внешний шаг
CI/CD workflow-файлы проверены на hardcoded secrets, опасные permissions и утечки env в logs
Если есть оплата, проверены webhooks и статус заказа
Есть чек / фискализация или задача на проверку
Есть оферта / правила возврата или задача на создание
Возвраты описаны или вынесены в backlog
Бухгалтерский / 54-ФЗ review отмечен как внешний шаг
Troubleshooting

Troubleshooting: если AI пошел не туда

  • AI игнорирует AGENTS.md — остановить задачу, попросить AI процитировать релевантные правила из AGENTS.md, обновить план и не продолжать код до нового плана.
  • AI активировал deferred surface — остановить изменения, вернуть surface в deferred, записать finding в AUDIT_BACKLOG, продолжать только после approval.
  • AI сделал massive rewrite — остановить, сравнить diff, разбить на smaller changes, откатить неутвержденные части, запросить independent diff review.
  • AI начал писать код до Product Brief / audit plan — остановить, вернуться к Product Brief / Prompt 0, удалить или откатить premature changes.
  • Scanner недоступен — не имитировать результат, указать not run, предложить manual command, добавить follow-up в backlog.
  • AI не может открыть ссылку — вставить текст протокола или copy-block вручную.
Recovery

Emergency recovery: если AI сломал working code

Если после AI-правок проект перестал собираться или основной сценарий сломался, не продолжайте “чинить наугад”.

  1. Зафиксировать текущее состояние: git status, список измененных файлов, ошибка build/test/runtime.
  2. Если был checkpoint commit — откатиться через git revert или создать отдельную recovery branch.
  3. Если commit не было — рассмотреть git restore / git checkout -- / git stash, но только после понимания, что будет потеряно.
  4. Не удалять пользовательские изменения без approval.
  5. Запустить минимальные проверки.
  6. Вернуться к последнему working state.
  7. Сделать smaller plan.
  8. Запустить independent diff review, если изменения были широкими.
  9. Добавить причину поломки в AUDIT_BACKLOG.

Не давайте AI выполнять destructive commands без явного approval.

Audit Backlog

Не теряйтесь в результатах: заведите backlog исправлений

После полного аудита AI может найти десятки проблем: security, зависимости, архитектура, тесты, алерты, документация. Если не завести отдельный backlog, легко запутаться и начать чинить не то.

После аудита не надо сразу просить AI “почини всё”. Сначала заведите понятный backlog исправлений: что блокирует релиз, что важно, что можно отложить, какие задачи требуют ручного review и какие проверки нужно добавить в CI.

ID Приоритет Категория Задача Риск Файл / ссылка Статус Кто отвечает
SEC-001 Critical Security Убрать hardcoded token Утечка доступа app/config.ts:12 Open Owner
DEP-001 High Supply Chain Обновить vulnerable package RCE/CVE risk package-lock.json Open Owner
TEST-001 Medium Tests Добавить e2e на главный сценарий Регрессия tests/e2e Open Owner
LEGAL-001 High Legal Добавить согласие на обработку ПДн рядом с формой заявки Риск нарушений в контуре персональных данных landing/form / policy link Open Owner
PAY-001 Critical Payments Проверить webhook оплаты и защиту от повторной обработки Дубль оплаты или ложный статус заказа payments/webhooks Open Owner
FISCAL-001 High Fiscalization Проверить формирование чека оплаты и возврата Проблемы с фискализацией и пользовательским контуром оплаты payment provider / cashbox flow Open Owner
QA-001 Medium Device QA Проверить checkout на iOS Safari и Android Chrome Пользователь не может оплатить или отправить форму с телефона checkout / contact forms Open Owner

Статусы

  • Open
  • In progress
  • Ожидает проверки
  • Fixed
  • Verified
  • Deferred
  • Accepted risk

Приоритеты

  • Critical — блокирует merge/deploy.
  • High — нужно исправить до production.
  • Medium — запланировать.
  • Low — можно отложить.

Категории

  • Security
  • Supply Chain
  • Architecture
  • Tests
  • Monitoring
  • DevOps
  • Documentation
  • UX
  • Performance
  • Data / Privacy
  • AI / Cost
  • Legal
  • Compliance
  • Payments
  • Fiscalization
  • Device QA
  • Browser QA
  • Accessibility
  • Analytics / Cookies
  • Согласие на рекламные коммуникации
AUDIT_BACKLOG.md

Для маленького проекта backlog можно вести прямо в файле

Для команды удобнее GitHub Issues, Linear, YouTrack, Jira, Notion или другая система задач. Если файла нет, AI должен предложить создать `AUDIT_BACKLOG.md`.

# Audit Backlog

## Critical

| ID | Category | Task | Risk | Evidence | Status |
|---|---|---|---|---|---|

## High

| ID | Category | Task | Risk | Evidence | Status |
|---|---|---|---|---|---|

## Medium

| ID | Category | Task | Risk | Evidence | Status |
|---|---|---|---|---|---|

## Low

| ID | Category | Task | Risk | Evidence | Status |
|---|---|---|---|---|---|

## Accepted risks

| ID | Risk | Why accepted | Review date |
|---|---|---|---|
Антипаттерны

Чего не стоит делать

Не давайте один огромный prompt

AI начинает тонуть в контексте, читает все подряд и теряет приоритеты. Поэтапная работа надежнее.

Не просите AI “сразу всё исправить”

Так легко сломать рабочие части, потерять фокус на блокерах и получить лишние диффы.

Не подключайте новые пакеты без проверки

Любая новая зависимость — это поддержка, лицензия, security и supply chain риск.

Не разрешайте автообновления в main или production

Автообновление должно идти через PR, проверки, staging и rollback, а не напрямую в боевой контур.

Не выводите секреты полностью в отчете

Даже если AI нашел token или ключ, в отчете нужна безопасная маскировка, а не публикация секрета.

Не плодите шумные alerts

Сотня уведомлений в один Telegram-чат не делает проект безопаснее. Нужна иерархия Critical / Warning / Info.

Формат работы

Можно пройти самому, можно разобрать вместе

Протокол можно использовать самостоятельно: копировать шаги, отдавать их Claude Code, Codex, Cursor, Windsurf или другой AI IDE и постепенно доводить проект. Если нет времени разбираться в отчете, интерпретировать риски и аккуратно чинить найденные проблемы, можно пройти аудит вместе со мной.

Самостоятельно (Self-service)

Самостоятельный формат: вы сами проходите протокол, копируете промпты и используете их в своей IDE.

Быстрый первый аудит (Light Audit)

Быстрый первый аудит: критичные риски, security-блокеры, структура, зависимости, запуск.

Стандартный аудит (Standard Audit)

Стандартный аудит: архитектура, security, supply-chain, тесты, документация и план исправлений.

Полная инженерная доводка (Full Hardening)

Полная инженерная доводка: исправление critical/high проблем, future checks, monitoring, alerts и documentation.

Формат и объем зависят от проекта: размера кодовой базы, стека, наличия production, пользовательских данных и внешних интеграций.
GitHub toolkit package v0.4.1

Hardening toolkit на GitHub

Для уже существующего AI-generated проекта GitHub toolkit дает рабочие markdown-файлы и проверки: hardening prompts, AUDIT_BACKLOG, scanner report, self-protection checklist, database/load checklist, independent diff review, automated vibe-check и anti-patterns. Если проект уже работает, но проблема именно в maintainability, а не в production readiness, теперь есть отдельная maintenance lane вместо того, чтобы запихивать любой cleanup в hardening.

  • protocols/ai-project-hardening-protocol.md
  • prompts/hardening-prompts.md
  • templates/AUDIT_BACKLOG.md и templates/SECURITY_SCANNER_REPORT.md
  • checklists/self-protection-checklist.md и checklists/database-load-scalability-checklist.md
  • scripts/vibe-check.sh, ANTI_PATTERNS.md, docs/pre-commit-hooks.md, docs/multi-agent-workflows.md
Открыть Hardening protocolAUDIT_BACKLOG.mdAutomated Vibe CheckAnti-patterns

Perimeter / DDoS / WAF / recurring scans: Hardening должен проверять не только код и зависимости, но и внешний периметр проекта: что видит внешний сканер, какие порты открыты, защищены ли admin/internal endpoints, есть ли WAF/CDN/rate limiting, как обрабатывается bot abuse, где evidence периодических проверок и кто отвечает за security operations.

Checklist: public endpoints и subdomains, closed ports и service inventory, admin/internal routes, WAF/CDN/reverse proxy, rate limits и bot abuse, security headers, recurring scans, secret rotation, backup/restore evidence и accepted risks.

Откройте Perimeter Security Checklist, External Exposure Checklist, Security Operations Baseline, Safe Update Workflow и Secret Rotation and Storage.

Это не обещание защиты от всех DDoS-атак. Для production-проектов нужны инфраструктурные средства, провайдер, WAF/CDN, rate limits, monitoring и incident response.

Для существующего проекта используйте Hardening Protocol + AUDIT_BACKLOG + vibe-check в CI как pre-audit signal. Для числовых gate-ов откройте hardening thresholds, для optional scanners — scanner integration, для AI-specific рисков — AI-specific threat model, а для regression thinking — testing cookbook. Для workflow enforcement откройте pre-commit hook installer, backlog-to-issues prompt, modular hardening and security prompts и migration docs. Для больших существующих проектов используйте discovery-agent pattern: отдельный read-only агент собирает evidence map, основной агент проверяет findings и правит только нужные файлы. Если AI сначала должен выбрать маршрут и файлы, откройте use-this-repo-prompt.md. Откройте .github/workflows/vibe-check.yml и docs/automated-vibe-check.md.

GitHub toolkit package v0.4.1: для хаотичного проекта сначала восстановите ARCHITECTURE_MAP.md, затем выберите маршрут: Hardening для production/security readiness, maintenance refactoring для maintainability-only cleanup. Новый SECURITY.md и security methodology scope прямо объясняют, что toolkit не является certification или scanner. Content validation в vibe-check остается heuristic, а tooling roadmap честно показывает текущие границы автоматизации.

Написать в Telegram Обсудить аудит AI-проекта Посмотреть мои проекты
Если написать мне

Что вы получите, если напишете мне

Протокол можно пройти самостоятельно: скопировать промпты, прогнать проект через свой AI/IDE и получить отчет. Если хотите разобрать конкретный проект вместе, я могу помочь пройти аудит быстрее и аккуратнее: посмотреть структуру, найти блокеры, проверить security/supply-chain, device/legal/payment-контур и собрать понятный backlog исправлений.

Обычно разбор начинается с короткого code discovery: смотрим структуру, стек, зависимости, env/config, security-sensitive зоны, платежи и ПДн при наличии, а затем собираем список блокеров. После этого понятно, нужен ли Light, Standard или Full-разбор и в каком формате удобнее идти дальше: переписка, письменный отчет, созвон по findings или поэтапный audit backlog.

  • Карту проекта и ключевых рисков.
  • Список critical/high проблем.
  • Security и supply-chain находки.
  • Scanner findings, если применимо.
  • Device/browser QA замечания.
  • Legal/payment checklist для РФ-контура, если проект этого требует.
  • Приоритизированный AUDIT_BACKLOG.
  • Понятный план исправлений.

Формат и объем зависят от размера проекта, стека, наличия production, пользовательских данных, оплаты и внешних интеграций.

Формат Когда подходит Результат
Самостоятельно (Self-service) Хотите пройти аудит сами Используете промпты и шаблоны в своей AI IDE
Быстрый первый аудит (Light Audit) Нужен быстрый первый срез Блокеры, секреты, структура, первичные риски
Стандартный аудит (Standard Audit) Проект идет к merge или deploy Полный отчет, scanner findings и backlog
Полная инженерная доводка (Full Hardening) Нужно не только найти, но и исправлять Critical/high фиксы, проверки, документация и финальная верификация
Написать в Telegram Обсудить аудит AI-проекта
Практические шаблоны

Отдельный artifact pack без перегруза основной страницы

Если протокол уже пройден и вам нужны рабочие заготовки, откройте отдельный пакет шаблонов: backlog, scanner report, legal checklist и payment/fiscalization checklist.

Это уже существующий отдельный Artifact Pack. Шаблоны можно использовать отдельно после Starter, Hardening или Architecture review.

AUDIT_BACKLOG.md

Шаблон backlog для critical/high/medium/low находок и accepted risks.

SECURITY_SCANNER_REPORT.md

Шаблон отчета по Trivy, OSV-Scanner, Gitleaks и triage результатов.

LEGAL_CHECKLIST.md

Checklist по ПДн, РКН, 152-ФЗ, cookies, формам и документам сайта.

PAYMENT_FISCALIZATION_CHECKLIST.md

Checklist по payment flow, чекам, кассе, ОФД, возвратам и 54-ФЗ.

Architecture Source of Truth

Архитектурная справка проекта: C4, NFR, contracts, threat model, rollback и readiness gates.

Открыть все шаблоны Открыть хаб Vibe Coding Protocols
FAQ

Частые вопросы

Что такое vibe coding?

Vibe coding — это разработка, где большую часть кода пишет AI по описанию задачи, а человек управляет направлением, проверяет результат и принимает решения.

Для каких AI IDE подходит протокол?

Протокол не привязан к одной IDE или модели. Его можно использовать в Claude Code, Codex, Cursor, Windsurf, Gemini CLI, Kimi, DeepSeek и других AI-инструментах, которые умеют читать проект и работать с файлами.

Почему нельзя просто попросить AI “проверь код”?

Потому что такой запрос часто дает поверхностный обзор. Надежнее сначала задать режим аудита, собрать карту проекта, создать или обновить ARCHITECTURE.md, а потом уже просить отчет и правки.

Можно ли дать AI весь протокол сразу?

Можно, но лучше идти по этапам. Так меньше риск, что модель потеряет контекст, начнет править лишнее или сделает поверхностный аудит.

Это заменяет разработчика?

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

Это заменяет security-инженера или pentest?

Нет. Это методология первичной инженерной доводки. Она помогает быстро найти риски и подготовить проект к ручному review, merge или production, но не заменяет pentest и ручную security-экспертизу критичных систем.

Это юридическая консультация?

Нет. Протокол помогает найти очевидные legal/compliance риски и подготовить список вопросов. Финальные документы и выводы должен проверять профильный юрист или специалист по нужной области.

Что делать, если проект маленький?

Начните с блока “Быстрый старт” и Light Hardening. Это самый быстрый способ понять, есть ли блокеры перед merge или deploy, особенно после первого vertical slice из Starter.

Что делать, если проект уже в production?

Лучше начинать с Audit only или Audit + Fix critical: сначала отчет, healthcheck, rollback и приоритеты, и только потом точечные правки без массовой перетряски кода.

Нужен ли доступ к production?

Обычно нет для первичного аудита кода, структуры и документации. Production-доступ может понадобиться позже для проверки live-конфига, логов, платежей, device QA в боевом контуре или rollback-пути, но это отдельный осознанный шаг.

Что делать, если нет CI/CD?

Проверки можно запустить вручную и описать как обязательный ручной процесс до релиза. Протокол помогает сначала собрать минимальный checklist, а уже потом решить, какой CI/CD действительно нужен.

Сколько времени занимает Full-аудит?

Full-аудит зависит от размера проекта, стека и количества интеграций. Для небольшого MVP первичный отчет может занять несколько часов. Исправление critical/high проблем обычно лучше делать отдельными маленькими итерациями после отчета и подтверждения плана.

Можно ли пройти аудит частично?

Да. Для маленького проекта можно начать с Light-аудита. Если проект идет в production, собирает персональные данные, принимает оплату или использует внешние API, лучше проходить Standard или Full.

Что делать, если AI нашел секреты?

Не выводить секреты полностью в отчет, вынести их из кода, перевыпустить ключи, проверить историю репозитория, логи, CI/CD и внешние интеграции, а затем подтвердить повторной проверкой, что утечка закрыта.

Нужно ли выполнять Full-режим всегда?

Нет. Full нужен для production, коммерческих проектов, пользовательских данных, платежей, AI-инструментов и сложных интеграций. Для MVP и небольших проектов часто достаточно Light или Standard.

Нужно ли обязательно ставить Trivy, OSV-Scanner и Gitleaks?

Не всегда. Для Light-аудита можно честно указать not run и начать с package manager audit, lockfile review, grep по SECRET/API_KEY/TOKEN/PASSWORD, проверки .env/.gitignore и dependency freshness review. Но для production, VPS, внешних зависимостей и AI-generated кода лучше иметь минимум secret scan и dependency scan. Trivy, OSV-Scanner и Gitleaks — практичный базовый набор.

Почему сканеры нашли сотни HIGH или CRITICAL, это катастрофа?

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

Нужно ли проверять проект на телефонах?

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

Что проверять, если сайт собирает заявки?

Политику обработки персональных данных, согласие на обработку, чекбокс рядом с формой, ссылку на документы, место хранения данных, передачу в CRM, Telegram, email-сервисы и логи.

Что проверять, если есть онлайн-оплата?

Платежные webhooks, статус заказа, возвраты, оферту, правила возврата, онлайн-кассу, фискализацию, отправку чеков и ошибки фискализации.

Нужно ли уведомлять Роскомнадзор?

Это зависит от того, какие персональные данные собираются, как они обрабатываются и кто является оператором. Протокол должен вынести этот вопрос в legal backlog, но финальный ответ должен дать специалист по персональным данным.

Можно ли применять протокол к не-AI проектам?

Да. Хотя протокол создан для AI-generated и vibe-coded проектов, его логика полезна и для обычных кодовых баз, когда нужно быстро провести architecture review, security audit и подготовить понятный план доводки.

Финальный CTA

Сначала аудит. Потом план. Потом безопасные правки.

Используйте этот протокол после AI-кодинга, перед merge, перед деплоем или перед передачей проекта разработчику. Если хотите пройти этот путь быстрее и без хаоса, можно разобрать ваш AI-проект вместе: от architecture review и security audit до плана remediation.

Написать мне Обсудить аудит AI-проекта Обо мне