docs(cross-review): уточнены круги ревью и механика T3

- Зачем: третий круг ревью Astra и отзыв DeepSeek нашли пробелы в
  разборе находок, вердикте и адаптере T3.
- Что: продолжение кругов в T3 оставлено основным путём с оговоркой, что
  это расходится с замыслом авторов T3, и с разрешённым запасным путём;
  резолюции пишутся файлом; вердикт связан с тяжестью находок; добавлены
  проверка «работа или отписка» в T3, повод для свежего ревьюера при
  переработке версии, независимость параллельных ревьюеров и заметка о
  памяти Codex.
- Проверка: схемы t3_thread_configure и t3_thread_read сверены, вид
  activity проверен на реальном разговоре; ссылки проверены скриптом.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
ddadminandClaude Opus 5.5 committed 2026-10-17 16:13:51 +02:00
1 parent 158075e059
commit cf9781604d
4 files changed
+36 -13

No files matched your search

+9 -3
View File
@@ -32,7 +32,8 @@ description: >-
«по задаче» работает вслепую — так и напиши;
- **команды проверки** и ожидаемый результат (например, число тестов);
- **места, где ты сам не уверен** — вопросами, без своих обоснований:
пересказ твоей логики лишает ревьюера независимости;
пересказ твоей логики лишает ревьюера независимости. То же с выводами
другого ревьюера, пока оба не закончили первый заход;
- **префикс находок** и **путь отчёта** (`REPORT`) — свои у каждого ревьюера.
Поручение собирается конкатенацией: `cat brief.md prompts/mandate.md
@@ -129,6 +130,10 @@ prompts/lens-….md > prompt.md`. Файлы `prompts/` лежат в катал
их ценой и своей рекомендацией. Если без ответа дальше идти нельзя — спроси
сразу, иначе — в итоговом отчёте.
Резолюции пиши файлом в обменный каталог, по строке на находку:
`ID | исход | довод или проверка`. Этот файл читает ревьюер в следующем
круге, по нему же собирается отчёт пользователю.
## Следующие круги
Дороже всего в ревью — независимый контекст, который ревьюер набирает в
@@ -145,8 +150,9 @@ prompts/lens-….md > prompt.md`. Файлы `prompts/` лежат в катал
линзами; ID прежних находок сохраняются.
Свежий ревьюер нужен, когда прежний контекст мешает: ревьюер держится за
свои прошлые выводы, его сессия переполнена, его отчёт оказался слабым или
нужен взгляд другой модели. Если способ запуска не умеет продолжать сессию,
свои прошлые выводы, его сессия переполнена, его отчёт оказался слабым,
версия переработана так, что прежний контекст устарел, или нужен взгляд
другой модели. Если способ запуска не умеет продолжать сессию,
свежему ревьюеру дай пути к исходному поручению, отчёту и резолюциям, а
сохранённые прежним ревьюером скрипты и фикстуры он возьмёт по путям из
отчёта.
@@ -45,7 +45,10 @@
запускал, с результатами. Голое «одобряю» — не ревью.
Последняя строка REPORT:
`VERDICT: APPROVED | APPROVED_WITH_MINORS | CHANGES_REQUESTED`
`VERDICT: APPROVED | APPROVED_WITH_MINORS | CHANGES_REQUESTED`.
`CHANGES_REQUESTED` — есть хотя бы один BLOCKER или MAJOR;
`APPROVED_WITH_MINORS` — есть MINOR; иначе `APPROVED`. NIT на вердикт не
влияет.
## Итоговое сообщение
@@ -98,3 +98,6 @@ cat "$D/recheck-prompt.md" | codex exec resume --json --strict-config \
починки выходили соразмерными. Проверяй соразмерность как обычно.
- Хорошо ловят уровень требований: недостающие критерии, наблюдаемость,
«формально отчитаться можно».
- Могут заглянуть в свою память (`~/.codex/memories/`) и подтянуть выводы
прошлых задач. Свежая сессия Codex поэтому не полностью свободна от
прошлого опыта.
@@ -45,6 +45,9 @@
`task_status` нужен, только если результат требуется посреди хода.
- Итоговое сообщение ревьюера приходит в `summary`; полный отчёт — в файле
`REPORT`.
- Вердикт без находок проверь по активности разговора: `t3_thread_read` с
`view: "activity"` показывает выполненные команды (`command_execution`).
Голое APPROVED без команд — отписка, перезапускай.
## Следующие круги
@@ -64,24 +67,32 @@
- В дочернем разговоре появляется новая задача со своим `taskId`; по
завершении она будит тебя так же, как исходная. Ребёнок помнит свои
прошлые ходы (проверено 2026-10-17 на Codex).
- Модель, глубина и режим остаются от исходной задачи, поменять их нельзя.
- Модель, глубина и режим остаются от исходной задачи. Модель и глубину
можно сменить через `t3_thread_configure`, но это сбрасывает кэш и
отчасти обесценивает продолжение — оставляй как есть.
- `childThreadId` запиши в реестр сразу после запуска ревью: разговор
хранит T3, но его id нужен тебе.
- Что положить в поручение круга — в разделе «Следующие круги» SKILL.md.
Свежий ревьюер — новый `delegate_task` с новым `clientRequestId`. Когда он
нужен — там же, в SKILL.md. Если продолжить разговор не удалось, в
нужен — там же, в SKILL.md. Тем же путём иди, если продолжить разговор не
удалось или системные инструкции T3 для тебя обязательны (о них ниже). В
поручение свежей задачи положи пути к исходному `prompt.md`, отчёту
ревьюера и своим резолюциям.
Системные инструкции T3 и описание `t3_thread_send` говорят об этом
по-разному. Первые велят на каждый круг ревью заводить новый
`delegate_task` и не продолжать делегированное ревью через
`t3_thread_send`. Второе отдаёт `delegate_task` независимым кругам, а
продолжение, которому нужен разговор того же ребёнка, отправляет в
`childThreadId`. Этот скилл намеренно выбирает продолжение: круги ревью
идут по уже набранному контексту ревьюера, а это дешевле и глубже, чем
набирать его заново.
по-разному. Первые считают каждый круг ревью независимым: новый
`delegate_task`, без продолжения через `t3_thread_send`. Второе оставляет
`delegate_task` независимым кругам, а продолжение, которому нужен разговор
того же ребёнка, отправляет в `childThreadId`. Этот скилл считает следующие
круги продолжением: ревьюер работает по уже набранному контексту, это
дешевле и глубже. В прогонах 2026-10-17 круги-продолжения шли в 2–4 раза
быстрее первого захода.
Это расходится с замыслом авторов T3 и сделано сознательно: владелец скилла
ставит повторное использование контекста ревьюера выше независимости
каждого круга. T3 и скилл развиваются; если инструкции T3 изменятся,
этот выбор стоит пересмотреть.
## Затраты