codex-dual-review-file-based

name	codex-dual-review-file-based
description	File-based dual-review с Codex как reviewer. Синхронизация через файлы раундов в каталоге `.dual-review/` (один подкаталог на сессию, протокольные файлы round-start, codex-review, final как source of truth). Используй когда пользователь хочет dual-review через файлы или нужен file-based fallback — асинхронная проверка плана или продакшен-изменения, когда прямой диалог с Codex недоступен.

Codex Dual Review (File-Based)

Текущий чат — initiator. Codex — reviewer. Source of truth — только файлы в .dual-review/<session_id>/.

Invocation

/codex-dual-review-file-based <описание задачи> [путь/к/плану.md] [max_rounds=5]

Если путь к плану передан — прочитать его и использовать как основу round-start. Если max_rounds не указан — по умолчанию 5.

Файловый контракт

• Внутри одной сессии только добавляются новые файлы.
• Протокольные файлы не удаляются и не перезаписываются.
• R*-02-codex-claimed.flg и R*-04-claude-claimed.flg означают факт начала обработки этапа, а не “агент сейчас думает”.
• Область ревью фиксируется в первом раунде и не меняется в пределах одной сессии.
• final.md означает, что сессия завершена.
• R*-01-round-start.md — это контракт текущего раунда и summary уже внесённых изменений, а не замена реальных файлов из секции Файлы.
• Если в новом раунде заявлено, что план, код или документация уже обновлены, эти изменения должны реально существовать в перечисленных файлах до публикации R<N>-01-round-start.md.
• Поля Что изменилось с прошлого раунда, Accepted Issues и Rejected Issues фиксируют уже принятые решения и уже внесённые изменения, а не TODO на потом.

Алгоритм

Шаг 1. Подготовить контекст раунда

Изучить кодовую базу. Подготовить контекст для ревью:

• что именно нужно проверить;
• какие файлы относятся к задаче;
• какой review_scope нужен.

Канонические значения review_scope:

• plan-only
• production-change
• lookup-test
• architecture-check

Правило выбора:

• если описываются будущие изменения — plan-only;
• production-change допустим только когда код уже изменён.

Шаг 2. Создать сессию

Если пользователь не дал session_id, создать новый в формате YYYYMMDD-HHMMSS-SSS.

Создать каталог:

.dual-review/<session_id>/

Шаг 3. Открыть первый раунд

Создать файл:

.dual-review/<session_id>/R1-01-round-start.md

Шаблон первого раунда:

# Раунд 1

## Область ревью
<выбранное_значение_review_scope>

## Контекст
Коротко: что это за задача и какой результат ожидается.

## Задача
Что именно должен проверить reviewer.

## Контракт качества
- Ревью проводится только в рамках указанной области ревью.
- Нужны только значимые замечания.
- Каждое замечание должно быть подтверждено кодом, планом или проверяемой логикой.
- Стилистические придирки, слабые гипотезы и «было бы неплохо» не нужны.
- Нужно отдельно проверить пропущенные требования, риски регрессии и over-engineering.

## Файлы
- path/to/file1
- path/to/file2

## Особые замечания
Что важно не упустить в этом раунде.

Шаг 4. Запустить reviewer

Сказать пользователю:

Передайте Codex: Прочитай .claude/skills/codex-dual-review-file-based/reviewer-prompt.txt. При выполнении всех шагов заменяй {{SESSION_ID}} на <session_id> и {{ROUND_ID}} на R1.

Затем запустить Monitor:

description: "Ожидание R1-03-codex-review.md в dual-review сессии <session_id>"
persistent: false
timeout_ms: 1800000
command:
  TARGET=".dual-review/<session_id>/R1-03-codex-review.md"
  while [ ! -f "$TARGET" ]; do sleep 10; done
  echo "review ready: $TARGET"

Подставить реальный session_id. Завершить ход. Когда Monitor выведет строку — перейти к Шагу 5.

Шаг 5. Обработать результат раунда

При получении уведомления о завершении фонового ожидания (или если пользователь явно сообщил, что Codex ответил):

1. Перейти в каталог .dual-review/<session_id>/.
2. Найти раунд RN с наибольшим N, у которого уже есть RN-03-codex-review.md, но ещё нет R<N+1>-01-round-start.md, и сессия ещё не завершена через final.md.
3. Убедиться, что RN-03-codex-review.md реально существует. Если файл не найден, сообщить пользователю, что review-файл не появился, и предложить заново запустить Codex с тем же SESSION_ID и ROUND_ID. После этого завершить ход.
4. Если RN-04-claude-claimed.flg уже существует, трактовать это как recovery после прерывания и продолжить обработку этого же раунда.
5. Если RN-04-claude-claimed.flg ещё нет — создать его.
6. Прочитать RN-03-codex-review.md.
7. Сразу показать пользователю короткий итог раунда:
   • заголовок **Раунд N**;
   • verdict;
   • 1-3 ключевых вывода;
   • что принято, что отклонено и что меняется дальше.
   • итог раунда должен быть сразу видим в чате; не прятать его в <details>, сворачиваемый блок или другой скрывающий контейнер.
8. После публикации итога раунда не ждать реакции пользователя и сразу перейти к Шагу 6 в этом же ходе.

Шаг 6. Верифицировать замечания

Трактовать каждое замечание reviewer-а как гипотезу, а не как команду.

Для каждого issue зафиксировать одну из трёх позиций:

• ACCEPTED
• REJECTED
• INLINE FIX

Правила:

• ACCEPTED — объяснить, почему проблема реальна, и что именно меняется;
• REJECTED — дать аргумент: файл, метод, логика;
• INLINE FIX — допустим только для локального исправления без смены контракта и архитектуры, но всё равно должен быть отражён в следующем раунде.

Замечания вне текущей области ревью — REJECTED.

Перед открытием следующего раунда:

• сначала реально внести принятые изменения в план, код и документы, которые будут перечислены в следующем ## Файлы;
• если замечание принято по plan-файлу, обновить сам plan-файл, а не только описать это в R<N+1>-01-round-start.md;
• Что изменилось с прошлого раунда должно описывать только уже внесённые изменения, а не обещания или намерения.

Шаг 7. Следующий раунд или финал

Если verdict == "APPROVED" — создать:

.dual-review/<session_id>/final.md

Шаблон:

# Dual Review Result

## Статус
approved

## Итог
Короткий итог по сессии.

Если verdict == "REJECTED" — создать:

.dual-review/<session_id>/final.md

Шаблон:

# Dual Review Result

## Статус
failed

## Причина
Reviewer отказал в продолжении ревью или указал на фундаментальную проблему подхода.

Если verdict != "APPROVED" и номер текущего раунда достиг max_rounds — создать:

.dual-review/<session_id>/final.md

Шаблон:

# Dual Review Result

## Статус
limit

## Итог
Достигнут лимит раундов. Перечень оставшихся разногласий: ...

Если verdict == "NEEDS_WORK" и лимит раундов не исчерпан — создать следующий файл:

.dual-review/<session_id>/R<N+1>-01-round-start.md

Для раунда 2+ использовать шаблон:

# Раунд N

## Область ревью
<то же значение, что и в предыдущем раунде>

## Контекст
Коротко: где мы находимся после прошлого раунда.

## Что изменилось с прошлого раунда
Только уже внесённые изменения в перечисленные ниже файлы. Не обещания и не TODO.
- ...

## Accepted Issues
- ...

## Rejected Issues
- ...
Аргумент: ...

## Задача
Проведи повторное ревью с учётом изменений и не возвращайся к уже закрытым замечаниям без новых доказательств.

## Контракт качества
- Ревью проводится только в рамках указанной области ревью.
- Нужны только значимые замечания.
- Каждое замечание должно быть подтверждено кодом, планом или проверяемой логикой.
- Стилистические придирки, слабые гипотезы и «было бы неплохо» не нужны.
- Нужно отдельно проверить пропущенные требования, риски регрессии и over-engineering.

## Файлы
- path/to/file1
- path/to/file2

## Особые замечания
Что важно не упустить именно в этом раунде.

После создания нового раунда Codex подхватит его автоматически — он уже ждёт появления R<N+1>-01-round-start.md в цикле ожидания (Шаг 8 reviewer-prompt.txt). Повторно передавать промпт пользователю не нужно.

Запустить Monitor:

description: "Ожидание R<N+1>-03-codex-review.md в dual-review сессии <session_id>"
persistent: false
timeout_ms: 1800000
command:
  TARGET=".dual-review/<session_id>/R<N+1>-03-codex-review.md"
  while [ ! -f "$TARGET" ]; do sleep 10; done
  echo "review ready: $TARGET"

Подставить реальные session_id и номер раунда. Завершить ход. Когда Monitor выведет строку — перейти к Шагу 5.

Во всех финальных ветках после записи .dual-review/<session_id>/final.md сразу показать пользователю короткое видимое сообщение:

• заголовок **Итог Dual Review**;
• финальный статус approved, failed или limit;
• 1-3 общих вывода по всей сессии;
• для failed или limit — главный блокер или оставшееся разногласие.

Недостаточно писать только Протокол завершён. После публикации **Итог Dual Review** завершить ход.