# Debug Skill

Систематическая 4-фазная отладка. Никаких фиксов без исследования причины.

## Когда использовать автоматически
- Даня говорит «не работает», «баг», «ошибка», «debug», «почему падает», «что не так»
- После неудачной верификации (`/verify` нашёл FAIL)
- Когда тест падает неожиданно во время `/tdd`

## Когда НЕ использовать
- Очевидная опечатка или синтаксическая ошибка — просто починить
- Проблема уже диагностирована и нужна только реализация фикса
- Даня явно говорит «просто почини»

## Алгоритм

### Фаза 1: Исследование причины (Root Cause)

**Цель:** понять ЧТО происходит, прежде чем думать ПОЧЕМУ.

1. **Прочитай ошибку целиком** — весь стектрейс, не только последнюю строку
2. **Воспроизведи** — найди точные шаги. Воспроизводится 100%? Периодически? При определённых условиях?
3. **Проверь недавние изменения** — `git diff`, `git log --oneline -10`. Что менялось? Когда сломалось?
4. **Трассировка данных** — проследи поток данных от входа к ошибке:
   - Что приходит на вход?
   - Где данные трансформируются?
   - В какой точке данные становятся неправильными?
5. **Диагностическое логирование** — если система многокомпонентная, добавь логи на границах ПЕРЕД попыткой фикса

Результат фазы:
```
Причина: [конкретное описание]
Воспроизведение: [шаги]
Точка отказа: файл:строка
```

### Фаза 2: Анализ паттернов

1. **Найди рабочие примеры** — есть ли в кодовой базе похожий код который работает?
2. **Сравни** — составь список различий между рабочим и сломанным
3. **Проверь зависимости** — версии, конфигурация, окружение

### Фаза 3: Проверка гипотез

1. **Сформулируй гипотезу**: «Я думаю причина в X, потому что Y»
2. **Проверь минимальным изменением** — одна переменная за раз
3. **Подтвердилось?**
   - Да → Фаза 4
   - Нет → Новая гипотеза. НЕ накладывать фиксы друг на друга

### Фаза 4: Реализация фикса

1. **RED** — напиши тест воспроизводящий баг (используй `/tdd`)
2. **GREEN** — реализуй единственный фикс устраняющий корневую причину
3. **Верификация** — тест проходит, регрессий нет, проблема решена

## Автоматический выключатель (Circuit Breaker)

Считай попытки фикса. Если **3 попытки не решили проблему**:

```
⚠️ 3 попытки исправления не привели к результату.
Это может указывать на архитектурную проблему, а не локальный баг.

Варианты:
1. Продолжить отладку (новый подход)
2. Пересмотреть архитектуру компонента
3. Спросить Даню / эскалировать

Что выбираешь?
```

**НЕ пытаться фикс #4 без явного решения Даня.**

## Красные флаги (если ловлю себя на этом — СТОП)

| Мысль | Что делать |
|-------|-----------|
| «Быстро починю, потом разберусь» | СТОП. Сначала Фаза 1 |
| «Попробую поменять X, вдруг поможет» | СТОП. Это не гипотеза, а гадание |
| «Не до конца понимаю, но это может сработать» | СТОП. Вернись к трассировке данных |
| «Добавлю try/catch и проблема уйдёт» | СТОП. Это маскировка, не фикс |

## Формат ответа

### После Фазы 1:
```
Диагностика: [название проблемы]

Симптом: [что видит пользователь]
Причина: [что на самом деле происходит]
Точка отказа: файл:строка
Воспроизведение: [шаги]

Гипотеза: [что нужно исправить и почему]
```

### После Фазы 4:
```
Исправлено: [название проблемы]

Причина: [root cause]
Фикс: файл:строка — [что изменено]
Тест: [название теста] — воспроизводит и проверяет фикс
Регрессии: нет (все тесты проходят)
```

## Правила
- НИКОГДА не чинить без диагностики. Фаза 1 обязательна
- Одна переменная за раз в Фазе 3
- Circuit breaker на 3 попытках — не игнорировать
- Диагностические логи — удалить после решения проблемы
- Если баг в чужом коде (зависимость) — сообщить Дане, не патчить

## Запрос: $ARGUMENTS