Ultra-Audit

---
name: Ultra-Audit
description: Exhaustive bug audit of a codebase followed by fully autonomous fixing. Use when the user asks to audit a project for bugs, hunt down workarounds and half-finished work in recent commits, find SSOT violations or architectural drift, or requests a deep/full/"ultra" audit that also fixes what it finds. Also triggers on /ultraaudit.
---

# Ultra-Audit

Не ври и не подгоняй. Каждое число в отчёте — это то, что ты действительно посмотрел.
Работа идёт в три фазы: обход → отчёт → починка. Ни одна не заменяет другую, ни одну
не сокращай.

Если при вызове указана область (путь, модуль, пакет) — ограничь обход ею. Правила
ниже при этом не смягчаются: те же три обхода и та же таблица покрытия, только внутри
заданной области. Без аргумента область работы — весь проект.

## 0. Перед началом
Нужна точка отката. Дерево грязное — закоммить только свои файлы или сделай ветку;
чужие незакоммиченные правки не трогай и назови их в конце. Начинать починку без точки
отката нельзя.
Прочитай, что уже известно: прошлые BUGSAUDIT-*, DEBT/TODO/FIXME, открытые задачи.
Уже закрытое не выдавай за находку; известное, но не починенное — помечай так.

## 1. Три обхода, все три обязательны
(1) **История.** `git log -p -40`: костыли, временные обходы, недоведённые
переименования и миграции, добавленное но нигде не вызванное, поведение изменённое в
одном месте из двух, TODO вместо реализации.
(2) **Структура.** Карта кода — модули, точки входа, границы — и проход по областям
со списком «область → просмотрено / частично / не смотрел».
(3) **Функции продукта.** Выпиши основные пользовательские сценарии и пройди каждый от
входа до результата. Отдельно — стыки: что ломается, когда две функции работают
вместе, делят состояние или спорят за один ресурс. Это не то же самое, что обход по
файлам, и пропускать его нельзя.
Область работы: только файлы проекта — без node_modules, dist/build, .git, вендорных
и сторонних конфигов.

## 2. Классы дефектов — пройди каждый явно по каждой области
- контракты и границы: отправитель и получатель разошлись в схеме/формате;
  необязательное читается как обязательное; версия API без совместимости
- состояние и гонки: параллельные записи, нет идемпотентности, порядок событий,
  отмена и таймаут, повторная доставка
- ошибки: пустой catch, ошибка превращённая в успех, fallback скрывающий причину,
  неразличимые сообщения, ошибка без владельца
- ресурсы: незакрытые подписки/сокеты/файлы, рост без границы (кэш, лог, таблица),
  «лимит», который никто не проверяет
- данные: миграция без обратной совместимости, дефолт расходится со схемой,
  время/часовые пояса/кодировки/локаль
- безопасность: проверка прав на клиенте вместо сервера, секреты в коде, логах и URL,
  непроверенный ввод в SQL/shell/путь/HTML
- SSOT: одна константа, тип, список или правило в двух местах; генерируемое, правленное
  руками; два кодовых пути для одного решения; документация, противоречащая коду
- уровень инженерии: слои протекают друг в друга, бизнес-логика в UI или в обработчике
  запроса, конкретная зависимость вместо интерфейса, конфигурация зашита в код, ошибки
  без общего контракта, поведение без наблюдаемости
- производительность: N+1, работа в цикле отрисовки, синхронное на горячем пути,
  запрос без индекса, повторная работа вместо кэша
- тесты: тест без ассерта, тест сам себе поставляет условие, замокано именно то, что
  проверяется, покрытие есть — проверки нет
- мёртвое: экспорт без импортёров, флаг без читателя, ветка недостижимая по типам
- UX/UI: состояние без обратной связи, необратимое действие без подтверждения, ошибка,
  которую пользователь не может понять и исправить

## 3. Что считается находкой и когда область закрыта
Записывай только то, что видно в коде. Прежде чем записать — проверь, что путь до
дефекта достижим и выше по стеку нет защиты. Каждая находка помечена: **подтверждено**
(назови путь: вход → место дефекта) или **гипотеза**. Гипотезы считаются отдельно и не
смешиваются в итогах.
Число находок себе заранее не назначай — и не добивай фантазией: нашлось 67, пиши 67.
Но и не сбегай: область закрыта, когда ты назвал в ней и подтверждённые находки, и
места, где их точно нет. Если по всему проекту вышло меньше нескольких десятков
находок — ты искал по верхам: вернись и пройди классы §2 поимённо по каждой области.
«Ничего не нашёл» — результат, который надо доказать, а не заявить.

## 4. Severity
- **P0** — потеря или порча данных, дыра в безопасности, падение/зависание на обычном
  пути, сломанная сборка или релиз.
- **P1** — функция работает неверно или наполовину; два источника правды разошлись;
  деградация при обычной нагрузке; ошибка проглатывается молча.
- **P2** — всё остальное: UX/UI, мелкие недочёты, стиль, мёртвый код.
Внутри одной severity: архитектура → работоспособность → функционал →
производительность → SSOT → UX → UI → совместимость → мелочи.

## 5. Формат каждого бага
ID · файл:строка **и имя символа** (строки протухают) · суть одной фразой · как это
заметить или воспроизвести · последствие · severity + подтверждено/гипотеза · текущий
код · исправленный код · объяснение · почему это баг, а не намеренное решение.

## 6. Отчёт — подробно, семью разделами
`BUGSAUDIT-<сегодняшняя дата ГГГГ-ММ-ДД>.md` в корне (дату подставь реальную). Есть за
сегодня — дописывай и меняй статусы, сохраняя ID. Подробности живут только здесь; в
чат — короткие сводки. Скелет файла: `reference/report-template.md`.
1. **Шапка** — дата, ревизия (`git rev-parse HEAD`), чем и как проверял.
2. **Покрытие** — «область → просмотрено/частично/не смотрел → чем → почему не смотрел».
   Без таблицы отчёт недействителен. Пустая колонка причин лучше, чем отговорка в ней.
3. **Находки** — каждая полным блоком по §5, ничего не сворачивая в «и т. п.».
   Один и тот же баг в разных местах — перечисли все места поимённо.
4. **Журнал решений** — каждая развилка §7: что выбрал, почему, что отверг и чем
   отвергнутое хуже. Сюда же всё, где ты был не уверен.
5. **Журнал правок** — коммит → ID багов → файлы → проверка, которая падала до и
   проходит после (команда и вывод дословно).
6. **Не сделано** — поимённо, с причиной по каждому пункту.
7. **Подготовлено, но не выполнено** — §8: что нужно, каким файлом или командой готово,
   чего ждёт.

## 7. Починка — автономно, без единого вопроса
Сразу после отчёта чини сам: все P0, потом P1, потом P2. **Вопросов по ходу не
задавай — ни одного.** Не жди подтверждений, не предлагай варианты, не проси выбрать.
Внутри репозитория ты свободен полностью: удалять и создавать файлы, менять структуру,
править схемы и конфиги, добавлять зависимости, переписывать модуль целиком — если это
чинит реальный баг. Развилку решаешь сам, решение пишешь в журнал решений, идёшь дальше.
Дефолты:
- два поведения расходятся → правда там, где тест, схема или контракт; остальное
  подгоняется под неё
- нет источника правды → сделай его в одном месте и переведи на него всех читателей
- фикс шире бага → делай; вышел за модуль — отдельным коммитом
- нужна миграция схемы → напиши файлом, применяй только к локальным данным
- не уверен, баг ли → чини, если фикс не меняет наблюдаемого поведения; иначе оставь
  гипотезой и опиши
Каждый фикс — с проверкой: тест или команда, которая падала до и проходит после; нет
проверки — так и напиши. Запрещённые «починки»: ослабить или удалить тест, заглушить
catch'ем, подставить fallback вместо причины, править генерируемый файл руками,
переименовать симптом.
После каждой группы — три строки в чат: что починил, какие файлы, чем проверил. Одна
группа — один коммит с объяснением, почему это было багом.

## 8. Что подготовить, но не выполнять
Единственное исключение из автономии — действия вне репозитория, которые git не
откатит: запись в реальную БД, миграция по живым данным, вызовы во внешние сервисы,
деплой, публикация, push с перезаписью истории, удаление веток, действия с деньгами,
доступами и секретами.
По каждому: доведи до готовности (файл миграции, скрипт, точная команда), не запускай,
положи в §6.7 и в финальный список. Не останавливайся — следующий баг.

## 9. Готово когда
Все три обхода §1 пройдены; все P0 починены и проверены; не меньше 80% P1 починены;
SSOT-нарушения устранены или поимённо перечислены с причиной; каждый фикс имеет
проверку; отчёт содержит все семь разделов; несделанное названо поимённо.
Финальный summary в чате, и только в нём — раздел **«Требует твоего решения»**: каждый
пункт одной строкой, с моим предложением, с тем что уже готово и что я сделал пока.
Решать нечего — так и напиши.