# Комплексный промпт для аудита репозитория и устранения проблем ## Цель Проведи тщательный анализ всего репозитория, чтобы выявить, приоритизировать, исправить и задокументировать ВСЕ подтверждаемые ошибки, уязвимости безопасности и критические проблемы независимо от языка программирования, фреймворка или технологического стека. ## Этап 1: Первичная оценка репозитория ### 1.1 Карта архитектуры - Опиши полную структуру проекта (src/, lib/, tests/, docs/, config/, scripts/ и т. д.) - Определи технологический стек и зависимости (package.json, requirements.txt, go.mod, pom.xml, Gemfile и т. д.) - Задокументируй основные точки входа, критические пути и границы системы - Проанализируй конфигурации сборки и конвейеры CI/CD - Изучи существующую документацию (README, документацию API, архитектурные схемы) ### 1.2 Анализ среды разработки - Определи фреймворки тестирования (Jest, pytest, PHPUnit, Go test, JUnit, RSpec и т. д.) - Изучи настройки линтинга/форматирования (ESLint, Prettier, Black, RuboCop и т. д.) - Проверь существующий учёт проблем (GitHub Issues, комментарии TODO/FIXME/HACK/XXX) - Проанализируй историю коммитов, чтобы выявить недавние проблемные области - Изучи имеющиеся отчёты о покрытии тестами, если они доступны ## Этап 2: Систематический поиск ошибок ### 2.1 Категории ошибок для выявления **Критические ошибки:** - Уязвимости безопасности (SQL-инъекции, XSS, CSRF, обход авторизации и т. д.) - Риски повреждения или потери данных - Сбои системы или взаимные блокировки - Утечки памяти или исчерпание ресурсов **Функциональные ошибки:** - Логические ошибки (неверные условия, ошибочные вычисления, ошибки на единицу) - Проблемы управления состоянием (гонки, несогласованное состояние, некорректные изменения) - Неверные контракты API или сопоставления данных - Отсутствующие или неправильные проверки - Нарушенные бизнес-правила или рабочие процессы **Ошибки интеграции:** - Неправильное использование внешних API - Ошибки или неэффективность запросов к базе данных - Проблемы обработки очередей сообщений - Проблемы операций с файловой системой - Ошибки сетевого взаимодействия **Граничные случаи и обработка ошибок:** - Обработка null/undefined/nil - Пустые коллекции или граничные случаи с нулевыми значениями - Граничные условия и превышение ограничений - Отсутствующая передача ошибок или подавление исключений - Проблемы логики тайм-аутов и повторных попыток **Проблемы качества кода:** - Несоответствия типов или небезопасные приведения - Использование устаревших API - Мёртвый код или недостижимые ветви - Циклические зависимости - Узкие места производительности (запросы N+1, неэффективные алгоритмы) ### 2.2 Методы обнаружения - Статический анализ кода инструментами для соответствующего языка - Поиск распространённых антипаттернов по шаблонам - Сканирование уязвимостей зависимостей - Анализ путей выполнения для поиска недостижимого или непроверенного тестами кода - Проверка конфигурации - Сопоставление документации с реализацией ## Этап 3: Документирование и приоритизация ошибок ### 3.1 Шаблон отчёта об ошибке Для каждой выявленной ошибки задокументируй: ``` BUG-ID: [Sequential identifier] Severity: [CRITICAL | HIGH | MEDIUM | LOW] Category: [Security | Functional | Performance | Integration | Code Quality] File(s): [Complete file path(s) and line numbers] Component: [Module/Service/Feature affected] Описание: - Текущее поведение (что не так) - Ожидаемое поведение (что должно происходить) - Анализ первопричины Оценка влияния: - На пользователей (ухудшение UX, потеря данных, риски безопасности) - На систему (производительность, стабильность, масштабируемость) - На бизнес (соответствие требованиям, выручка, репутация) Шаги воспроизведения: 1. [Step-by-step instructions] 2. [Include test data/conditions if needed] 3. [Expected vs actual results] Метод проверки: - [Code snippet or test that demonstrates the bug] - [Metrics or logs showing the issue] Зависимости: - Связанные ошибки: [List of related BUG-IDs] - Блокирующие проблемы: [What needs to be fixed first] ``` ### 3.2 Матрица приоритетов Ранжируй ошибки по следующим критериям: - **Серьёзность**: критическая > высокая > средняя > низкая - **Влияние на пользователей**: количество затронутых пользователей/функций - **Сложность исправления**: простая < средняя < сложная - **Риск регрессии**: низкий < средний < высокий ## Этап 4: Реализация исправлений ### 4.1 Стратегия исправления **Для каждой ошибки:** 1. Создай отдельную ветку исправления (при использовании контроля версий) 2. СНАЧАЛА напиши падающий тест (подход TDD) 3. Реализуй минимальное целевое исправление 4. Убедись, что тест проходит 5. Запусти регрессионные тесты 6. При необходимости обнови документацию ### 4.2 Рекомендации по исправлению - **Принцип минимальных изменений**: вноси наименьшее изменение, которое корректно устраняет проблему - **Без расширения объёма работ**: избегай несвязанного рефакторинга и улучшений - **Сохраняй обратную совместимость**: кроме случаев, когда сама ошибка представляет собой несовместимость API - **Следуй стандартам проекта**: используй существующие стиль кода и подходы - **Добавляй защитное программирование**: предотвращай подобные ошибки в будущем ### 4.3 Чек-лист проверки кода - [ ] Исправление устраняет первопричину, а не только симптомы - [ ] Обработаны все граничные случаи - [ ] Сообщения об ошибках понятны и помогают действовать - [ ] Влияние на производительность приемлемо - [ ] Учтены последствия для безопасности - [ ] Не добавлены новые предупреждения или ошибки линтинга ## Этап 5: Тестирование и проверка ### 5.1 Требования к тестам **Для КАЖДОЙ исправленной ошибки предоставь:** 1. **Модульный тест**: изолированная проверка конкретного исправления 2. **Интеграционный тест**: если ошибка затрагивает несколько компонентов 3. **Регрессионный тест**: подтверждение, что исправление не нарушает существующую функциональность 4. **Тесты граничных случаев**: покрытие связанных граничных условий ### 5.2 Структура теста ```[language-specific] describe('BUG-[ID]: [Bug description]', () => { test('should fail with original bug', () => { // This test would fail before the fix // Demonstrates the bug }); test('should pass after fix', () => { // This test passes after the fix // Verifies correct behavior }); test('should handle edge cases', () => { // Additional edge case coverage }); }); ``` ### 5.3 Шаги проверки 1. Запусти полный набор тестов: `[npm test | pytest | go test ./... | mvn test | etc.]` 2. Проверь изменения покрытия кода 3. Запусти инструменты статического анализа 4. Проверь показатели производительности (если применимо) 5. Протестируй в разных средах (по возможности) ## Этап 6: Документация и отчётность ### 6.1 Документирование исправлений Для каждой исправленной ошибки: - Обнови комментарии в коде, объясняющие исправление - Добавь/обнови документацию API, если поведение изменилось - Создай/обнови руководства по устранению неполадок - Задокументируй обходные решения для неисправленных проблем ### 6.2 Краткий отчёт для руководства ```markdown # Отчёт об исправлении ошибок — [Repository Name] Дата: [YYYY-MM-DD] Анализатор: [Tool/Person Name] ## Обзор - Всего найдено ошибок: [X] - Всего исправлено ошибок: [Y] - Не исправлено/отложено: [Z] - Изменение покрытия тестами: [Before]% → [After]% ## Критические находки [List top 3-5 most critical bugs found and fixed] ## Сводка исправлений по категориям - Безопасность: [X bugs fixed] - Функциональность: [Y bugs fixed] - Производительность: [Z bugs fixed] - Интеграция: [W bugs fixed] - Качество кода: [V bugs fixed] ## Подробный список исправлений [Organized table with columns: BUG-ID | File | Description | Status | Test Added] ## Оценка рисков - Оставшиеся высокоприоритетные проблемы: [List] - Рекомендуемые следующие шаги: [Actions] - Выявленный технический долг: [Summary] ## Результаты тестирования - Команда тестирования: [exact command used] - Пройдено тестов: [X/Y] - Добавлено новых тестов: [Count] - Влияние на покрытие: [Details] ``` ### 6.3 Чек-лист результатов - [ ] Все ошибки задокументированы в стандартном формате - [ ] Исправления реализованы и протестированы - [ ] Набор тестов обновлён и проходит - [ ] Документация обновлена - [ ] Проверка кода завершена - [ ] Оценено влияние на производительность - [ ] Проведена проверка безопасности (для соответствующих исправлений) - [ ] Подготовлены примечания к развёртыванию ## Этап 7: Непрерывное улучшение ### 7.1 Анализ закономерностей - Выяви распространённые типы ошибок - Предложи профилактические меры - Порекомендуй улучшения инструментов - Предложи архитектурные изменения для предотвращения подобных проблем ### 7.2 Рекомендации по мониторингу - Предложи метрики для отслеживания - Порекомендуй правила оповещений - Предложи улучшения журналирования - Выяви области, которым нужно лучшее покрытие тестами ## Ограничения и лучшие практики 1. **Никогда не жертвуй безопасностью** ради простоты 2. **Веди журнал аудита** всех изменений 3. **Соблюдай семантическое версионирование**, если исправления изменяют API 4. **Соблюдай ограничения частоты запросов** при тестировании внешних сервисов 5. **Используй флаги функций** для исправлений с высоким риском (если применимо) 6. **Продумывай стратегию отката** для каждого исправления 7. **Документируй допущения**, сделанные при анализе ## Формат результата Предоставь результаты в обоих форматах: - Markdown для удобного чтения человеком - JSON/YAML для автоматизированной обработки - CSV для импорта в системы учёта ошибок ## Особые случаи - Для монорепозиториев: анализируй каждый пакет отдельно - Для микросервисов: учитывай зависимости между сервисами - Для устаревшего кода: сопоставляй риск исправления с пользой - Для сторонних зависимостей: при необходимости сообщай об ошибках разработчикам исходного проекта --- Источник: prompts.chat. Текст: CC0 1.0 Universal. Русская версия: Kvantora.