Протоколы безопасного vibe coding

Memory Bank: единый контекст проекта

В этой методологии Memory Bank — это не обязательно отдельная папка. Это набор файлов, которые сохраняют устойчивый контекст проекта между AI-сессиями и людьми.

• README.md — что это за проект и как его запускать.
• AGENTS.md — правила работы AI-агентов.
• PROJECT_MAP.md — карта файлов, entrypoints, routes/endpoints и компонентов.
• ARCHITECTURE.md или Architecture Source of Truth — архитектура и границы.
• SECURITY.md — security baseline.
• AUDIT_BACKLOG.md — findings, risks, accepted risks, follow-up.
• docs/PROMPTS.md — использованные prompts и версия протокола, если проект ведется через AI.

Публичные шаблоны на сайте — это только templates. Реальные документы проекта могут содержать sensitive details и должны храниться private / sanitized / encrypted.

Таймлайн: где я нахожусь сейчас?

1. Идея — Product Brief / ТЗ → Starter.
2. Первая папка — Starter Protocol, active/deferred surfaces, first vertical slice.
3. Первый working slice — Light Hardening и базовые critical blockers.
4. Код перед deploy — Standard / Full Hardening: scanners, self-protection, database/load, legal/payment.
5. Findings — Templates / AUDIT_BACKLOG.
6. Передача / рост — Architecture Source of Truth.

Нумерация prompt-шагов независима внутри каждого протокола: Starter использует Шаг -1 и Prompt 0–7, Hardening — Prompt 0–8.

Проект должен защищать не только пользователей, но и сам себя

Vibe coding часто фокусируется на том, “работает ли продукт”. Но перед запуском важно проверить и саму систему: что могут увидеть внешние сканеры, не торчат ли внутренние документы, не доступны ли admin/API/docs, не раскрываются ли env/logs/backups, не запускаются ли worker/scanner процессы с лишними правами, не тянутся ли небезопасные внешние репозитории и обновления.

• private docs: архитектура, интеграции, AGENTS.md, PROJECT_MAP.md и internal runbooks не должны быть публичными;
• scanner exposure: проверьте, что внешний сканер не видит лишнее;
• worker/process isolation: фоновые задачи и browser/scanner automation не должны работать с лишними правами;
• safe integration: внешние repo/API/package проходят quarantine/review;
• safe updates: автообновление должно создавать PR, а не молча менять production;
• continuous improvement: self-protection нужно периодически пересматривать.

Если проект только начинается — учтите это в Starter. Если код уже есть — проверьте это через Hardening.

Проект должен выдерживать не только запуск, но и рост

AI может быстро собрать MVP, но при росте пользователей чаще всего ломаются не кнопки, а база данных, очереди, фоновые задачи, API limits, кэш, rate limits и миграции. Поэтому уже на старте и при hardening нужно проверять не только “работает ли сейчас”, но и “есть ли архитектурный тупик, который заставит переписывать проект при первой нагрузке”.

• database schema and indexes;
• migrations and rollback;
• queues / background jobs;
• rate limits и API quotas;
• caching boundaries и idempotency;
• observability, backup/restore, performance budget и scalability backlog.

Для нового проекта — Starter. Для существующего — Hardening. Для документации — Architecture Source of Truth.

Можно пройти самому — или дать ссылку своему AI

Можно вручную пройти разделы и скопировать нужные prompt-блоки. А можно дать своему AI ссылку на эту страницу и попросить сначала оценить методологию, а потом применить ее к вашему проекту.

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

Изучи эту страницу: https://anmalishev.ru/expert/vibe-coding/

Оцени, на какой стадии мой проект, какие части методологии нам полезны, задай недостающие вопросы и предложи маршрут: Starter, Hardening, Templates или Architecture Source of Truth.

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

Код пока не пиши.

Я нашел методологию для безопасного vibe coding и AI-assisted разработки:

https://anmalishev.ru/expert/vibe-coding/

Изучи эту страницу и связанные материалы.

Сначала не пиши код.

Сделай следующее:

1. Кратко оцени, насколько эта методология применима к нашему проекту.
2. Объясни, какие части нам точно полезны:
   - Starter Protocol;
   - Hardening Protocol;
   - Templates / Artifact Pack;
   - Architecture Source of Truth.
3. Определи, на какой стадии наш проект:
   - есть только идея;
   - есть Product Brief / ТЗ;
   - проект только начинается;
   - код уже есть;
   - проект готовится к deploy;
   - проект уже в production;
   - нужно передать проект другому разработчику.
4. Скажи, какой маршрут нам выбрать:
   - Product Brief → Starter;
   - Starter → first safe implementation;
   - Hardening;
   - Templates;
   - Architecture Source of Truth.
5. Сначала задай мне недостающие вопросы.
6. После вопросов составь пошаговый план применения этой методологии к нашему проекту.
7. Не ограничивайся только тем, что я явно написал. Если видишь важные риски, пропущенные направления проверки или смежные проблемы — выведи их отдельно в разделе “Что я мог упустить”.
8. После выполнения перепроверь свой план: маршрут, риски, validation и follow-up.
9. Если найдешь баги рядом с задачей — исправь мелкие безопасные, а крупные вынеси в отчет и backlog.
10. В конце выведи: что сделано, что проверено, что не удалось проверить, что я мог упустить, какие баги найдены попутно, что исправлено попутно, что требует отдельного approval и какие follow-up задачи добавить в backlog.
11. Не пиши код до моего подтверждения маршрута и плана.

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

Не все AI IDE умеют читать внешние ссылки. Если ваш инструмент не может открыть URL, скопируйте нужные prompt-блоки вручную или используйте кнопки “Скопировать” на страницах протоколов.

Что дать AI вместе со ссылкой

Ссылка на протокол — это playbook. Но хороший результат зависит от контекста проекта. Чем больше исходных данных вы дадите AI, тем точнее будет маршрут.

• Краткое описание идеи или Product Brief.
• Стадия проекта: идея / пустая папка / код уже есть / production.
• Ссылка на репозиторий или архив проекта, если код уже есть.
• Стек, если он уже выбран.
• Package manager и lockfile.
• Команды запуска, сборки и тестов.
• Есть ли персональные данные.
• Есть ли онлайн-оплата.
• Есть ли внешние API.
• Где планируется deploy.
• Какие части нельзя трогать.
• Что считается успехом первой итерации.

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

AI IDE Compatibility Matrix

Протокол vendor-neutral, но разные AI IDE работают по-разному. Если инструмент не умеет читать ссылки или запускать subagents, копируйте prompt-блоки вручную и адаптируйте workflow.

Если AI не может открыть ссылку — скопируйте short/full prompt или нужный prompt-block вручную.

Короткие определения

Vibe Coding Protocols — это методология управления AI-assisted разработкой: от Product Brief и первого vertical slice до hardening-аудита, архитектурной справки, шаблонов и readiness checks.

Memory Bank для AI-проекта — это набор файлов, которые сохраняют контекст между AI-сессиями: README.md, AGENTS.md, PROJECT_MAP.md, ARCHITECTURE.md, SECURITY.md, AUDIT_BACKLOG.md, docs/PROMPTS.md.

AI Project Hardening — это проверка AI-generated проекта перед merge/deploy/production: архитектура, security, supply-chain, scanners, self-protection, database/load readiness, legal/payment и backlog исправлений.

Artifact Pack: https://anmalishev.ru/expert/templates/
Architecture Source of Truth: https://anmalishev.ru/expert/templates/architecture-source-of-truth.html
Это отдельные страницы, а не скрытые разделы внутри Starter или Hardening.