tdd-bugfixlisted

# TDD Bugfix: Red → Yellow → Green Дисциплина для исправления багов через тесты, а не "на глазок". Цель — никогда не патчить код, не имея сначала теста, который доказывает существование бага, и не считать баг исправленным, пока весь набор тестов не зелёный. Три обязательные стадии идут строго по порядку. Пропускать стадии нельзя, даже если фикс кажется тривиальным. ## Стадия 1 — RED (красный тест) Цель: доказать, что баг существует, через тест, который сейчас падает. 1. Пойми баг: воспроизведи проблему из отчёта пользователя, стектрейса или описания. 2. Найди/создай подходящий тестовый файл рядом с существующими тестами проекта (тот же фреймворк, те же конвенции именования и структуры — посмотри соседние тесты перед тем как писать). 3. Напиши **один** тест, который: - Воспроизводит именно этот баг (конкретный инпут/сценарий из отчёта), а не абстрактную его версию. - Проверяет ожидаемое (правильное) поведение, а не текущее (сломанное). - Максимально простой и читаемый — один assert / одна проверяемая идея на тест, если возможно. 4. Запусти тест и убедись, что он **падает**. Обязательно проверь *причину* падения: - Если тест падает не по той причине (например, синтаксическая ошибка, а не логика бага) — это ложный красный, его нужно исправить до продолжения. - Зафиксируй фактический вывод падения (сообщение об ошибке/diff) — он пригодится, чтобы потом убедиться, что зелёный тест действительно чинит то же самое. 5. Не трогай код исправления на этом шаге. Единс