Bugfix

Новый баг в активной сессии: НЕ создавать новую сессию — добавить раздел в report/check, строку в dashboard. В check вставлять ПЕРЕД ## Инварианты.

Приоритизация: если несколько багов без указания порядка — выбрать самостоятельно (блокирующие → связанные → простые), сообщить пользователю.

2. Анализ бага

• Прочитать все релевантные файлы кода ПЕРЕД предложением фикса
• Не предлагать фикс пока не понятна корневая причина
• После анализа: резюмировать находки + подсказка следующего шага

3. Формулировка гипотез

• Сформулировать несколько гипотез с вероятностью (ВЫСОКАЯ / СРЕДНЯЯ / НИЗКАЯ)
• Проверка инвариантов: для каждой гипотезы проверить инварианты из check-файла. Нарушает → ОТКЛОНЕНА
• Конфигурационная гипотеза: если поведение зависит от данных из JSON/GameConfig и код выглядит корректно — включить гипотезу о некорректной конфигурации
• Pre-mortem: для каждой гипотезы записать "Если не поможет:" — одно предложение с вероятной причиной неудачи
• Записать ВСЕ гипотезы в check-файл сразу. Отвергнутые — со статусом ОТВЕРГНУТА и причиной
• Проверять по одной, начиная с самой вероятной
• Quick-fix: если причина однозначна, фикс 1-3 строки, нет альтернатив — можно пропустить диагностику. Пометить [Quick-fix] в заголовке Attempt

4. Диагностика (если причина неочевидна)

• Добавить таргетированные Console.WriteLine логи ДО фикса. Тег: [КраткоеИмя:HN]
• Предпочитать условные логи (только при аномалии)
• Показать пользователю таблицу ожиданий и план воспроизведения:

**План воспроизведения:**
1. `dotnet run` (логи уже добавлены)
2. <конкретные шаги в игре>
3. Скопируйте вывод консоли или напишите `готово`

• Проанализировать логи, записать результаты в check-файл
• Если логов нет — проверить достижимость кода, уточнить у пользователя воспроизвёлся ли баг

5. Реализация фикса

• Дождаться явного запроса — "применяй" / "фикси"
• Трассировка (обязательно): записать в Attempt порядок тика затронутых систем, на каком этапе фикс вступает в силу:

  Frame N: System1.Tick() → читает X → System2.Tick() → пишет X
  Фикс вступает в силу: System2, виден в том же кадре
  

• Побочные эффекты (обязательно): перечислить все пути выполнения через изменённый код + системы, читающие/пишущие те же данные
• Реализовать фикс, удалить диагностические логи, проверить dotnet build
• Обновить статус в check-файле → ФИКС НУЖДАЕТСЯ В ПРОВЕРКЕ
• Тест-план: показать конкретные шаги проверки:

  **Тест-план:**
  1. <действие> → <ожидаемый результат>
  **Проверка регрессий:** <что ещё проверить>
  

6. Обработка feedback

• Обновить статус попытки, Summary гипотезы, dashboard
• ФИКС ОТКАЧЕН:
  • Проверить pre-mortem — совпало ли предсказание
  • Частично помог → новый Attempt той же гипотезы
  • Не помог совсем → следующая гипотеза
  • После 3 неудачных Attempt'ов — пауза, переоценка гипотезы
• ФИКС ПРИМЕНЕН:
  • Проверить связанные баги на регрессию
  • Обновить dashboard → ПОФИКШЕН, показать dashboard

7. Обновление инвариантов (при ПОФИКШЕН)

• Извлечь правила из всех гипотез/попыток бага (включая неудачные)
• Ревизия существующих инвариантов — обновить/удалить устаревшие
• Добавить в ## Инварианты check-файла: категория, правило, ссылка на баг, объяснение

8. Архивация (при >5 багов в check)

Перенести все ПОФИКШЕН баги в archive-файл. Инварианты ВСЕГДА остаются в check-файле.

Правила

Контекст: ВСЕГДА держать полное содержимое всех файлов сессии. При потере контекста — перечитать.

Инварианты: перед любой гипотезой/фиксом проверить ## Инварианты в check-файле. Явно записать результат проверки.

Обновление заметок: любое изменение состояния бага отражать в файлах сразу (dashboard, report, check).

Без запроса не фиксить: фиксы только по "применяй"/"фикси". Перед фиксом кратко описать что будет сделано.

Dashboard: показывать в консоли при: подключении к сессии, завершении бага, завершении сессии.

Подсказка следующего шага: после каждого шага показать контекстный блок:

> **Следующий шаг:** что дальше
> **Что от вас нужно:** действие пользователя
> **Примеры промтов:** `пример 1` · `пример 2`

Связи между багами: при обнаружении связи записать в report: → причина / → следствие / → общая причина / → затрагивает. После фикса — напомнить проверить связанные.

Производительность: рабочий фикс > быстрый. Оценку стоимости записывать в Attempt.

Шаблоны файлов

dashboard

# Dashboard: Название сессии

| # | Баг | Статус | Гипотез | Попыток | Связи |
|---|-----|--------|---------|---------|-------|
| 1 | Имя | ИССЛЕДОВАНИЕ / ПРИЧИНА НАЙДЕНА / ПОФИКШЕН | 2 (1 отвергнута) | 3 | → следствие: #3 |

**Итого:** X пофикшено / Y в работе / Z всего
**Изменённые файлы:** список файлов

report

# Bug Report: Название сессии

## Имя бага
**Статус: ИССЛЕДОВАНИЕ / ПРИЧИНА НАЙДЕНА / ПОФИКШЕН**
**Связан с:** Другой баг `→ тип_связи` (если есть)

### Симптомы
- Что наблюдает пользователь

### Причины
Выжимка из Summary гипотез в check-файле.

check

Нумерация гипотез сбрасывается для каждого бага. ## Инварианты — ВСЕГДА последний раздел.

# Bug Check: Название сессии

## Имя бага

### Hypothesis 1: Описание
**Что предполагаем:** Что менять. **Почему:** Обоснование.
**Проверка инвариантов:** Инвариант N: не нарушен / нарушает → ОТКЛОНЕНА
**Если не поможет:** Причина неудачи.

#### Attempt 1: Что пробовали
**Трассировка:** System1.Tick() → System2.Tick() ...
**Затронутые пути:** | Тип | Влияние | Риск |
**Затронутые системы:** Какие системы читают/пишут те же данные.
**Описание:** Что поменяли.
**Результат:** Что увидел пользователь.
**Статус:** ФИКС НУЖДАЕТСЯ В ПРОВЕРКЕ / ФИКС ПРИМЕНЕН / ЧАСТИЧНО ПРИМЕНЕН / ПРИМЕНЕН С ПОБОЧНЫМ ЭФФЕКТОМ / ФИКС ОТКАЧЕН
**Стоимость:** Оценка.
**Изменения:** Код: `File.cs` — метод: описание. Конфиг: параметр: описание.

#### Summary
Итог гипотезы.

### Hypothesis 2: Описание (ОТВЕРГНУТА)
**Причина отклонения:** Почему.

---

## Инварианты

### Категория: Подсистема
1. **Правило** (из бага "Имя"): Почему нарушение ломает.

archive

Та же структура что check, но без ## Инварианты. Содержит полные разделы завершённых багов.