reflection-qa

name	reflection-qa
description	Reflection + Self-Correction + Quality Assurance протокол. Stop-Reflect-Correct-Verify-Deliver перед ответом на сложные задачи. Основан на Reflection Agent Pattern (Anthropic) + Self-Correction Protocol (Self-Refine).
tags	["reflection","qa","self-correction","reliability"]

Reflection & QA Protocol

Активировать когда: задача сложная (>3 шагов), результат сомнительный, код затрагивает внешние системы, или произошла ошибка, которую пришлось чинить.

НЕ активировать: простые вопросы, однофайловые правки, творческие задачи, ответы "по памяти".

---

5-Шаговый Reflection Loop

[OUTPUT] -> STOP -> REFLECT -> CORRECT -> VERIFY -> DELIVER
                                     ^                |
                                     |____ NO _________|
                                               YES

Шаг 1: STOP

Моментальная пауза. Прерви исполнение и задай себе вопрос: "Уверен ли я на 100%, что этот результат корректен?"

• Если ответ ДА (и задача простая) → пропусти reflection
• Если НЕТ или сомневаешься → продолжай

Признаки, что нужен reflection:

• "Кажется работает, но.."
• "Наверное так"
• "Должно быть правильно"
• "Я не проверял граничные случаи"

Шаг 2: REFLECT (самопроверка)

Ответь себе на 5 вопросов в уме (не вслух пользователю):

1. Логика: Есть ли ошибки в логике? Не пропустил ли шаг?
2. Границы: Проверены ли пустые/нулевые/крайние значения?
3. Инструменты: Правильный ли инструмент выбран? Может, нужен delegate_task вместо последовательных вызовов?
4. Токены: Не тащу ли лишний контекст? Можно ли ответить короче?
5. Пользователь: Это то, о чём он просил? Или я сделал "как понял"?

Шаг 3: CORRECT (самокоррекция)

Если нашёл проблему:

• Ошибка в коде → используй patch или execute_code для фикса
• Ошибка в логике → перепланируй подход, перепиши affected части
• Неполный результат → дополни недостающие куски
• Неверный инструмент → переделай с правильным

Шаг 4: VERIFY AGAIN

Перепроверь:

• Запусти тесты, если есть
• Выполни curl/stat/ls для проверки побочных эффектов
• Прочитай изменённые файлы, чтобы убедиться
• Если использовал delegate_task — проверь результат сам

🚨 Subagent Reflection (критическая вставка)

Subagent может наврать. Всегда. Даже если отчёт выглядит безупречно.

Типы subagent-лжи:

1. Правдоподобные цифры — назвал конкретную цену/дату/версию, которой нет
2. Успешный статус при провале — "задача выполнена", но файл не создан
3. Плагиат контекста — перефразировал твой же промпт как "результат поиска"
4. Вымышленные источники — процитировал статью/сайт, которых не существует

Когда subagent под подозрением:

• Вернул конкретные цифры, которые ты не можешь проверить → не передавай пользователю без оговорки
• Утверждает что-то противоречащее здравому смыслу или твоим знаниям → проверь
• Слишком быстро "нагуглил" идеальный ответ → вероятно сгененрировал

Золотое правило: subagent даёт направление и ссылки. Факты дёргаешь сам.

Шаг 5: DELIVER

Только когда все 5 вопросов REFLECT прошли зелёными.

---

Self-Refine (многошаговая итерация)

Для задач, где качество критично (production-код, финансы, безопасность):

1. Сделай черновик решения
2. Проведи reflection
3. Улучши (refine)
4. Снова reflection
5. Отдай

Максимум 3 итерации. Если за 3 не получилось — смени подход или спроси пользователя.

---

QA Checklist по типу задачи

Тип	Что проверить
Код	Компилируется/запускается? Тесты проходят? Краевые случаи?
Данные	Структура корректна? Все поля есть? Типы совпадают?
Команды	Не пейджится (git → cat)? Не зависнет без pty?
Файлы	Записан? Прочитай и проверь
Веб	Статус ответа? JSON валидный?
subagent	Я проверил статус? (не верь subagent-у на слово)

---

Провальные паттерны (check yourself)

• ❌ "Звучит правильно" → проверь
• ❌ "Subagent сказал что всё ок" → проверь сам (файл существует? ответ 200?)
• ❌ "Я уверен, тесты пройдут" → запусти их
• ❌ "Должно работать, это же очевидно" → проверь граничный случай