code-review

name	code-review
description	Код-ревью реализации задачи jira-helper. Используй после завершения coder-задачи для проверки качества кода, соответствия архитектуре и requirements.

Код-ревью (Code Review)

Назначение

Проверить код, написанный coder-агентом по конкретной TASK, и зафиксировать результат в файле-отчёте. Ревьюер не правит код — только находит проблемы и описывает их.

Вход

• TASK файл (.agents/tasks/<FEATURE-SLUG>/TASK-*.md) — что должно быть сделано.
• requirements.md — функциональные требования.
• target-design.md — целевая архитектура (если есть).
• docs/architecture_guideline.md — стандарты проекта.

Прочитай все файлы перед началом ревью. Найди изменённые/созданные файлы из секции «Файлы» в TASK.

Выход

Файл REVIEW-TASK-{N}.md в той же папке фичи (.agents/tasks/<FEATURE-SLUG>/).

---

Чек-лист ревью

1. Соответствие задаче

• Все пункты из «Что сделать» в TASK выполнены?
• Критерии приёмки из TASK закрыты?
• Нет лишнего кода, выходящего за scope задачи?

2. Архитектура

• Container / View разделение (если React-компоненты)?
• State в правильном слое (Model / Store, не в компоненте)?
• Зависимости через DI (constructor injection для Valtio, inject для Zustand)?
• DOM-работа через PageObject + DI (не прямые селекторы в логике)?
• Фича собрана в Module (class extends Module)? Токены через createModelToken()?
• Модуль зарегистрирован в content.ts (module.ensure(container)), а не в PageModification?
• Используются lazy() + modelEntry(), а не прямой proxy() / useSnapshot() в module.ts?
• В контейнерах: методы модели вызываются у entry.model, а не у результата entry.useModel() (снапшот read-only)?
• Для каждого *Container.tsx: проверены imports, useMemo, useEffect, callbacks и local state по docs/component-containers.md?
• Container не импортирует domain utilities ради бизнес-вычислений (compute*, parse*, resolve*, match*, apply*)?
• Container не фильтрует/сортирует/группирует domain collections, не вычисляет warning/recommendation lists, не объединяет built-in/custom сущности и не знает persisted storage/cascade shape?
• Если domain derivation осталась в Container — это Warning или Critical (в зависимости от влияния), с предложением перенести в Model / pure utils и покрыть unit-тестом.

3. Типы

• TypeScript strict: нет any, as unknown as, необоснованных type assertions?
• Интерфейсы с JSDoc для публичных API?
• Props types для React-компонентов?

4. Тесты

• Тест написан до реализации (TDD — если видно по коммитам/структуре)?
• AAA-паттерн (Arrange-Act-Assert)?
• Покрытие happy path + edge cases из TASK?
• Изоляция: reset() / getInitialState() в beforeEach?
• Cypress для DnD / visual feedback, Vitest для моделей?

5. Качество кода

• Именование файлов, переменных, компонентов — по конвенциям проекта?
• Нет дублирования логики?
• Нет утечек подписок / таймеров (cleanup в useEffect, unsubscribe)?
• CQS: queries без side effects?

6. Безопасность расширения

• Нет прямых eval, innerHTML с пользовательскими данными?
• API-ключи / токены не захардкожены?

---

Формат отчёта REVIEW-TASK-{N}.md

# Review: TASK-{N} — {название}

**Дата**: YYYY-MM-DD
**TASK**: [TASK-{N}](./TASK-{N}-*.md)
**Вердикт**: APPROVED | CHANGES_REQUESTED

## Findings

### Critical

{Блокирующие проблемы — код не может быть принят без исправления.}

- **[файл:строка]**: {описание проблемы}
  - Предложение: {как исправить}

### Warning

{Важные замечания — желательно исправить.}

### Nit

{Мелочи — на усмотрение.}

## Резюме

{1–3 предложения: общее впечатление, что хорошо, что нужно доработать.}

Если проблем нет — секции Critical / Warning / Nit содержат «Нет».

---

Правила

1. Не правь код — только описывай findings.
2. Указывай конкретный файл и строку для каждого finding.
3. Предлагай исправление, а не просто «плохо».
4. Вердикт CHANGES_REQUESTED — если есть хотя бы один Critical.
5. Вердикт APPROVED — если нет Critical (Warning и Nit не блокируют).