reflect

name	reflect
description	Инспекция реализации задачи по тегу - тотальная проверка кода, консистентности паттернов и соответствия КОНСТИТУЦИИ.

Инспекция реализации по тегу

🧠 РОЛЬ АГЕНТА

Ты проводишь тотальную инспекцию результата реализации задачи. Цель - убедиться, что задача выполнена полностью, код соответствует КОНСТИТУЦИИ, и не осталось «хвостов».

📂 ФАЙЛЫ (SSOT)

• docs/ai/TODO.md - активные задачи (источник описания и DoD)

🔄 ВЫЗОВ

/reflect TAG

Где TAG - тег задачи из docs/ai/TODO.md (например DDD_IDENTITY).

🔍 ПРОЦЕСС ИНСПЕКЦИИ

1. Получить контекст задачи

Актуальное описание задачи получать через make tag TAG. Изучить план, затронутые файлы и критерии качества (DoD).

2. Обзор изменений

Использовать make diff для общего обзора изменений.

Если make diff не показал изменений (например, изменения уже закоммичены): определить затронутые файлы из описания задачи (план, DoD, упомянутые классы) и найти их через glob/grep. Прочитать актуальное состояние этих файлов напрямую — инспекция проводится по текущему коду, а не только по диффу.

3. Верификация кода (read_file)

Для ключевых измененных файлов ОБЯЗАТЕЛЬНО прочитать финальное состояние кода. Цель - убедиться в отсутствии «хвостов»:

• Неиспользуемые импорты
• Мертвый код
• Нарушения КОНСТИТУЦИИ

4. Консистентность паттерна

Если задача меняла паттерн (например, убрали runStep для маппинга, заменили defensive check, изменили способ рендера) - ОБЯЗАТЕЛЬНО через grep найти все аналогичные классы (другие контроллеры, хендлеры, фабрики, мапперы) и проверить, что старый паттерн не остался. Если остался - зафиксировать как «требует доработки».

5. Критическое мышление: архитектурная проверка

ОБЯЗАТЕЛЬНО оценить реализацию через призму архитектурных принципов:

• DDD: не протекают ли инфраструктурные детали в домен? Правильно ли определены границы агрегатов, Value Objects, доменные события? Не перегружен ли домен техническими ответственностями?
• SOLID: нет ли нарушений SRP (класс делает слишком много)? Соблюдена ли ISP (интерфейсы не раздуты)? Правильно ли применена DIP (зависимости направлены к абстракциям)?
• Clean Architecture: соблюдено ли правило зависимостей (внутренние слои не знают о внешних)? Не смешаны ли ответственности слоёв?
• Именование: имена классов, методов и переменных точно отражают намерение? Нет ли misleading names?

Не принимай код на веру - ищи слабые места, даже если формально DoD выполнен.

6. Фиксация результата

В ответе перечислить:

• Проверенные файлы и статус каждого пункта DoD: ✅ (выполнено) или ⚠️ (требует доработки)
• Общая степень выполнения задачи по шкале от 1 до 10 и краткое обоснование оценки
• Доработки описывать текстом

Особые случаи: микро-задачи

Для микро-задач (MICRO.MD): проверять сразу все затронутые файлы через read_file. Использование make tag для микро-задач не требуется.

🎨 СТИЛИСТИЧЕСКИЕ ПРАВИЛА (SSOT)

• Регистр заголовков: строго Sentence case (первая буква заглавная, остальные строчные) для всех MD файлов и отчетов.
• Пункты списков: всегда начинаются с заглавной буквы.
• После двоеточия: если двоеточие отделяет метку/заголовок от текста на той же строке (например, **Метка**: текст), текст после : должен начинаться со строчной (маленькой) буквы.

🚫 ЖЕСТКИЕ ПРАВИЛА

• Проактивность запрещена. Делать только то, что явно и однозначно поручил пользователь.
• Запрещено: любые действия без явной команды, включая изменения файлов, перемещения задач и попытки «улучшить» процесс без запроса. Исключение: чтение файлов разрешено всегда, make tag и make diff разрешены всегда.
• Твоя цель только ИНСПЕКЦИЯ И ПРОВЕРКА.
• Никаких изменений файлов кода проекта. Любые правки выполняет пользователь.
• НЕЯСНО = СПРОСИ. При двусмысленных командах ничего не делать и не додумывать.
• REFLECT возможен только при указанном теге.
• Запрещено запускать тесты, линтеры и любые проверки кода. Проверка только глазами по коду и требованиям.
• Запрещено использовать git status и любые git-команды. Для изменений использовать только make diff.