Промпты для вайбкода

1. План перед кодом

Прежде чем писать код — остановись и составь план. Код не трогай, пока я не подтвержу.

В плане дай:

1. Понимание задачи — переформулируй своими словами, что нужно сделать.
   Если в задаче есть неоднозначность — назови её и предложи безопасное допущение.
2. Список файлов, которые затронешь, с пометкой создать / изменить / удалить
   и одной строкой — что именно меняется в каждом.
3. Порядок действий — пронумерованные шаги в той последовательности,
   в которой будешь их выполнять.
4. Риски — где может сломаться: затронутые зависимости, обратная совместимость,
   побочные эффекты, граничные случаи.
5. Что НЕ входит в работу — чего ты сознательно не будешь трогать, чтобы не выйти за рамки.

Не пиши код, псевдокод и диффы на этом шаге — только план.
Жди моего «ОК», и только потом приступай к реализации.

2. Ревью и баги

Сделай детальное ревью указанного кода. Ничего не исправляй — только находи и объясняй.
(Что ревьюим: <вставь файл / функцию / диапазон строк или приложи блок>)

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

• Где — файл и строка (или фрагмент кода).
• Категория — логическая ошибка / необработанный край (null, пустой ввод, ошибка сети) /
  гонка или порядок выполнения / утечка ресурса / неверная обработка ошибок / типобезопасность.
• Серьёзность — критично / важно / мелочь.
• В чём суть — почему это баг и при каких входных данных он проявится (конкретный сценарий).
• Как починить — короткое предложение или фрагмент исправленного кода.

Отдельно проверь: что происходит при неожиданном вводе (пустое, null, очень большое,
некорректный формат, дубли, конкурентные вызовы).

Отсортируй находки от самой критичной к самой мелкой.
Если серьёзных проблем нет — скажи прямо, не выдумывай замечания ради объёма.

3. Тесты на бизнес-логику

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

Сначала (до написания тестов) дай короткий список кандидатов:

• какие функции/модули считаешь критическими и почему
  (поломка ломает приложение, содержит нетривиальную логику или правила безопасности);
• что сознательно НЕ покрываешь (тривиальные прокладки, геттеры, баррелы, конфиг) — одной строкой.
  Жди моего «ОК» по списку, потом пиши тесты.

Требования к тестам:

• Используй тестовый стек проекта (Vitest), файл рядом с кодом (*.test.ts).
• Внешние зависимости и env — мокать, реальные ключи не нужны.
• Покрывай: happy path + граничные случаи + пути ошибок (ветвления, лимиты, классификация ошибок).
• Каждый тест — с понятным названием, описывающим проверяемое поведение.

Для каждого покрытого модуля одной строкой объясни: что проверяет тест и почему это важно.
В конце убедись, что npm test зелёный.

4. Аудит безопасности

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

Проверь как минимум:

• Эндпоинты: какие открыты без авторизации, где отсутствует или неверна проверка доступа,
  есть ли утечка чужих данных (нарушение скоупа по user_id).
• Инъекции: SQL/NoSQL, командные инъекции (особенно вызовы внешних утилит), path traversal.
• Валидация и санитизация входных данных на границе системы (API, формы).
• Секреты: хардкод ключей/токенов в коде вместо env.
• Зависимости с известными уязвимостями.
• Обработка ошибок: не утекают ли в ответ стектрейсы, внутренние пути, детали окружения.
• (Если есть веб-вывод) XSS и небезопасный рендер пользовательских данных.

Для каждой находки:

• Критичность — Critical / High / Medium / Low (по влиянию + простоте эксплуатации).
• Где — файл и строка.
• Сценарий атаки — как именно это можно проэксплуатировать.
• Как исправить — конкретно, с фрагментом кода или указанием подхода.

В начале дай сводку: число находок по уровням и топ-3, что чинить первым.
Если категория чистая — отметь это явно. Не раздувай отчёт ложными срабатываниями.

5. Нагрузочный тест (анализ масштабируемости)

Проанализируй поведение проекта под нагрузкой при 100, 500 и 1000 одновременных пользователях.
Это аналитический разбор по коду и архитектуре, а не запуск реального нагрузочного теста
(если хочешь предложить сценарий/скрипт для k6/autocannon — предложи отдельно).

Сначала зафиксируй вводные:

• Какой путь нагружаем — основной эндпоинт/флоу и что он делает по шагам.
• Где в этом флоу синхронные блокирующие или долгие операции
  (внешние API, скачивание, транскрипция, запросы к БД, работа с файлами/диском).

Для каждого уровня (100 / 500 / 1000) опиши:

• Что произойдёт — где копятся очереди, растёт latency, исчерпываются ресурсы
  (CPU, память, пул соединений к БД, файловые дескрипторы, лимиты внешних API, диск).
• Узкое место — что упрётся в потолок первым и при каком примерно числе пользователей.

Затем:

• Назови компонент, который ляжет первым, и почему.
• Для каждого слабого места дай конкретное решение
  (очередь/воркеры, кэш, пул соединений, rate limiting, бэкпрешер,
  горизонтальное масштабирование, перевод синхронного флоу в асинхронный)
  с оценкой эффекта и сложности внедрения.

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