# Итерации и feedback

← [Раздел](README.md) · [Главная](../README.md)

## Цель

Освоить **цикл итераций** с агентом: как давать обратную связь, когда останавливать, как формулировать критерии «готово».

## Предварительно

- [Контекст и токены](kontekst-i-tokens.md)
- Один завершённый или проваленный Agent-запрос в памяти

## Время

**50–80 минут**

---

## Итерация — не «повтори», а «уточни»

**Плохой feedback:**

> «Не то. Сделай нормально.»

**Хороший feedback:**

> «Валидация сработала, но сообщение об ошибке должно быть на русском и под полем, не alert. См. @RegisterForm.tsx строки 40–55. Не меняй API.»

Хороший feedback содержит:

1. **Что уже ок** (закрепляет правильное).
2. **Что не так** (конкретно).
3. **Где смотреть** (@файл, строка).
4. **Ограничения** (что не трогать).

---

## Цикл RED → GREEN → REFINE

Адаптация TDD для работы с агентом:

| Фаза | Ваша роль | Действие |
|------|-----------|----------|
| **RED** | Постановка | Чёткий промпт + критерий провала |
| **GREEN** | Приёмка | Прогон тестов / ручная проверка |
| **REFINE** | Ревью | Стиль, edge cases, docs |

Не принимайте diff на фазе GREEN, если тесты красные — это фаза **ещё RED** для агента.

ECC skill `tdd-workflow` автоматизирует эту дисциплину для кода.

---

## Критерии готовности (Definition of Done)

Задавайте **до** первого запуска агента:

```markdown
Готово когда:
- [ ] `npm test` — все зелёные
- [ ] Нет новых eslint errors
- [ ] README обновлён, если менялся публичный API
- [ ] Нет TODO без номера issue
```

Агент с чеклистом реже «заканчивает» преждевременно.

---

## Когда остановить и начать заново

| Симптом | Действие |
|---------|----------|
| Агент ходит по кругу 3+ раза | Стоп → упростить задачу → новая сессия |
| Diff раздулся >500 строк | Откат → декомпозиция |
| Меняются несвязанные файлы | Стоп → явный список «только эти файлы» |
| Модель «забыла» ТЗ | Новая сессия + резюме |

`git stash` / `git checkout -- .` — ваш друг. Агент не обижается.

---

## Типы feedback

| Тип | Пример | Когда |
|-----|--------|-------|
| **Корректирующий** | «Используй errgroup, не голые goroutines» | После diff |
| **Направляющий** | «Сначала только интерфейс, без реализации» | До следующего шага |
| **Ограничивающий** | «Без новых зависимостей» | В любой момент |
| **Поощряющий** | «Паттерн в service.go верный, повтори в order.go» | Масштабирование |

---

## Диаграмма итерации

```mermaid
flowchart TD
  P[Промпт + DoD]
  P --> A[Ответ агента]
  A --> V{Проверка}
  V -->|ок| D[Accept / commit]
  V -->|не ок| F[Конкретный feedback]
  F --> A
  V -->|тупик| R[Откат + новая сессия]
  R --> P
```

---

## Параллельные гипотезы

Для спорных решений (два API-дизайна):

1. **Plan mode** — два плана без кода.
2. Вы выбираете ветку.
3. **Agent** — одна реализация.

Или две **короткие** сессии на ветках git — не смешивайте в одном чате.

---

## Feedback на уровне команды

Если работаете в паре:

- фиксируйте **повторяющиеся** замечания в rules;
- skill `code-reviewer` в ECC стандартизирует ревью;
- в PR пишите, что **приняли от агента**, а что переписали вручную — это обучает всех.

---

## Практика

1. Возьмите мелкую задачу: «добавить константу ERROR_CODE_X в errors.go».
2. Намеренно дайте расплывчатый первый промпт.
3. Дайте **два** уточнения по шаблону хорошего feedback.
4. Запишите, сколько итераций понадобилось.

---

## Связь с промптами

Шаблоны первого сообщения — [раздел 03](../03-prompts/shablony-promtov.md). Антипаттерны — [anti-patterny](../03-prompts/anti-patterny.md).

---

## Самопроверка

1. Перечислите четыре части хорошего feedback.
2. Чем RED→GREEN отличается от «просто попросить ещё раз»?
3. При каком симптоме вы делаете откат и новую сессию?
4. Зачем Definition of Done до первого промпта?

## Дальше

→ [Безопасность и приватность](bezopasnost-i-privatnost.md)