ddadmin
51f65b2471
- Зачем: - Скилл поддерживает выбранную пользователем модель координатора, включая Sol. - Что: - Вступление и описание интерфейса адресованы ответственному координатору. - Sol и Terra указаны как обычные исполнители с выбором глубины по сложности. - Приведены в соответствие роли, шаблон поручения и текущие вопросы журнала. - Проверка: - Проверены YAML, явное включение скилла, 60 относительных ссылок и якоря. - Пройден git diff --check; сверены полномочия координатора и исполнителя.
169 lines
14 KiB
Markdown
169 lines
14 KiB
Markdown
# Ревью и триаж
|
|
|
|
Читай этот файл целиком после выбора независимого ревью постановки или
|
|
реализации. Это единственный подробный договор обзора, разбора находок и
|
|
перепроверки.
|
|
|
|
- [Выбор обзора](#выбор-обзора)
|
|
- [Мандат и независимость](#мандат-и-независимость)
|
|
- [Отчет ревьюера](#отчет-ревьюера)
|
|
- [Разбор находок](#разбор-находок)
|
|
- [Перепроверка](#перепроверка)
|
|
- [Когда работа не сходится](#когда-работа-не-сходится)
|
|
- [Доказательства для координатора](#доказательства-для-координатора)
|
|
|
|
## Выбор обзора
|
|
|
|
Подбирай ревью по неопределенности и цене ошибки. Нативный ревьюер, Claude и
|
|
свежая Astra - доступные линии. Обязательного набора нет. Отдельные основания:
|
|
свежий контекст ловит предположения автора, другое семейство моделей замечает
|
|
иные слепые зоны, Astra судит об устройстве и соразмерности. Одного обзора
|
|
достаточно, если он закрывает существенный риск. Две сфокусированные линии
|
|
оправданы, когда их независимый вклад стоит цены.
|
|
|
|
Для двух линий заранее раздели фокус, например:
|
|
|
|
- соответствие задаче, границам и наблюдаемому результату;
|
|
- корректность, межмодульные инварианты, регрессии и честность проверок.
|
|
|
|
Перед первым обзором каждой линии зафиксируй проверяемую версию артефакта.
|
|
Одна линия делает один общий обзор этой версии. Не запускай новый общий обзор
|
|
той же линии без изменения версии или нового основания; точечные исправления
|
|
проверяются узко.
|
|
|
|
## Мандат и независимость
|
|
|
|
Исходный обзор запускается в свежем контексте без истории исполнителя и других
|
|
ревьюеров. Ревьюер получает постановку, точные границы версии, свой фокус,
|
|
доступные проверки и уникальный путь отчета. Он самостоятельно сверяет факты,
|
|
а утверждения других агентов считает гипотезами до подтверждения.
|
|
|
|
Ревьюеру разрешены чтение, тесты, доступная сеть, документация и временные
|
|
файлы, нужные для проверки. Его мандат запрещает менять исходники, Git,
|
|
службы, данные и другое постоянное состояние. Результат обзора - назначенный
|
|
отчет; временные кэши и выводы инструментов допустимы.
|
|
Координатор остается владельцем общего дерева и стенда и при необходимости
|
|
сверяет их состояние до и после обзора.
|
|
|
|
Полный отчет пишет сам ревьюер в место, доступное владельцу триажа. Координатор
|
|
не пересказывает и не восстанавливает доказательства по краткой сводке. Если
|
|
общий файл недоступен, используй доступный канал и точно назови ограничение
|
|
передачи: где остался полный отчет и какие доказательства не переживут сессию.
|
|
Готовые английские блоки мандата и языка лежат в
|
|
[шаблоне ревьюера](prompts/review-boilerplate.md) и
|
|
[правиле обмена](prompts/runtime-language.md).
|
|
|
|
## Отчет ревьюера
|
|
|
|
Ревью возвращает проверяемые утверждения. Каждая находка получает
|
|
устойчивый идентификатор с уникальным префиксом линии. Сохраняй идентификатор
|
|
во всех следующих разборах и перепроверках. Полная запись содержит:
|
|
|
|
```text
|
|
PREFIX-N | location | violated criterion | failure scenario | evidence |
|
|
minimal verification
|
|
```
|
|
|
|
Существенный риск безопасно отложенного решения можно записать как
|
|
неблокирующее соображение без идентификатора, тяжести и влияния на вердикт.
|
|
Если проект или линия уже задает шкалу, добавь в запись тяжесть и считай ее.
|
|
Замечание о стиле без проверяемого ущерба остается соображением и не требует
|
|
исправления.
|
|
`CHANGES_REQUESTED` означает, что версия содержит хотя бы один дефект, который
|
|
нужно исправить на ее собственном уровне. `APPROVED` означает отсутствие
|
|
такого дефекта.
|
|
|
|
Даже при нуле находок отчет называет просмотренный объем, проверенные гипотезы,
|
|
запущенные команды и их результаты. Голый вердикт без свидетельств не
|
|
засчитывается. Сообщение координатору может содержать только вердикт, доступные
|
|
счетчики, по одной строке на идентификатор и на каждое существенное
|
|
неблокирующее соображение, а также путь к подробному отчету.
|
|
|
|
## Разбор находок
|
|
|
|
Каждую находку сначала проверяют на трех осях: фактическая верность,
|
|
применимость сценария к этому проекту и соразмерность исправления. Предложение
|
|
ревьюера - один из вариантов. Исполнитель может закрыть дефект более подходящим
|
|
путем. Аргументированное отклонение имеет тот же статус, что и подтвержденное
|
|
исправление; квота отклонений не нужна.
|
|
|
|
Находки о постановке разбирает координатор. Он сохраняет цель и границы,
|
|
проверяет технические утверждения доступным способом и выносит владельцу
|
|
продуктовый выбор или существенный риск.
|
|
|
|
Находки реализации разбирает исполнитель с контекстом кода. Он получает
|
|
подробные отчеты напрямую. Координатор добавляет только решения уровня задачи,
|
|
совпадения или противоречия линий. Каждый идентификатор получает один исход:
|
|
|
|
- `FIXED` - дефект подтвержден и исправлен; названы способ и проверка;
|
|
- `REJECTED` - утверждение не подтвердилось, неприменимо к проекту или не
|
|
описывает дефект по действующему договору; приведены контракт и доказательство;
|
|
- `OUT_OF_SCOPE` - решение меняет согласованные границы;
|
|
- `NEEDS_DECISION` - требуется выбор цели, устройства или остаточного риска.
|
|
|
|
`OUT_OF_SCOPE` и `NEEDS_DECISION` поднимаются координатору с вариантами,
|
|
последствиями, стоимостью и рекомендацией исполнителя. Координатор не заменяет
|
|
этот разбор молчаливым решением. Подробный файл резолюций сохраняет связь
|
|
между исходной находкой, ее исходом и проверкой.
|
|
|
|
Отклонение предложенного способа починки само по себе не закрывает
|
|
подтвержденный применимый дефект. Такой дефект получает соразмерное
|
|
`FIXED`, либо решение владельца через `OUT_OF_SCOPE` или
|
|
`NEEDS_DECISION`.
|
|
|
|
## Перепроверка
|
|
|
|
Точечные исправления и отклонения проверяет тот же ревьюер в продолжении
|
|
исходного контекста. Он читает собственный отчет, резолюции и измененную
|
|
версию, затем проверяет исходные идентификаторы и только соседние изменения.
|
|
Для каждого `FIXED` или `REJECTED` он возвращает `CLOSED`, `NOT_CLOSED`,
|
|
`REJECTION_VALID` или `REJECTION_INVALID` с кратким доказательством.
|
|
`OUT_OF_SCOPE` и `NEEDS_DECISION` переносятся в индекс без изменения:
|
|
ревьюер их не пересматривает и не включает в свой вердикт. Они остаются
|
|
открытыми до решения владельца.
|
|
|
|
Для `FIXED` ревьюер отдельно оценивает соразмерность починки:
|
|
`PROPORTIONATE` либо `OVERREACH` с объяснением лишнего охвата. Для
|
|
`REJECTED` он судит по аргументу и проверке; совпадение со вкусом не требуется.
|
|
Узкая область не требует скрывать замеченный рядом новый дефект: такой дефект
|
|
получает новый устойчивый идентификатор и возвращается владельцу триажа.
|
|
|
|
Выбранная линия ревью закрывается после начального `APPROVED` без открытых
|
|
вопросов либо после успешных нужных перепроверок и разрешения владельцем всех
|
|
вынесенных вопросов. Полномочный владелец также может явно записать принятие
|
|
оставшегося риска. Вердикт одной линии не закрывает открытые идентификаторы
|
|
другой.
|
|
|
|
Изменения шире прежней версии, слабый исходный отчет или новая независимая
|
|
неопределенность могут оправдать свежий общий обзор. Сам номер круга такого
|
|
основания не создает.
|
|
|
|
## Когда работа не сходится
|
|
|
|
Сигналы несходимости: тот же спор повторяется без новых доказательств,
|
|
исправления разрастаются дальше исходного риска, новые общие обзоры мало что
|
|
добавляют или стороны проверяют разные версии и контракты. Координатор сначала
|
|
останавливает петлю и устанавливает общий предмет спора. Затем он может
|
|
уточнить постановку, сузить проверку, сменить исполнителя или ревьюера,
|
|
повысить доступную модель или глубину, разделить задачу либо принять риск в
|
|
пределах полномочий.
|
|
|
|
Третий круг - практическое напоминание явно объяснить пользователю или
|
|
полномочному владельцу, почему работа не сходится, сколько стоит продолжение и
|
|
какой подход меняется. Пятый круг - напоминание не начинать еще один повтор
|
|
без явного решения. Это ориентиры наблюдения; обязательных этапов и
|
|
автоматических запросов разрешения здесь нет.
|
|
|
|
## Доказательства для координатора
|
|
|
|
Координатор обычно получает вердикт, счетчики, компактные строки находок и
|
|
пути. Он раскрывает подробный отчет, когда находка меняет границы или риск,
|
|
линии противоречат друг другу, возник спор, сводка не дает основания для
|
|
решения либо это нужно для собственной приемки. Для спорного утверждения он
|
|
читает соответствующее доказательство. Весь diff или журнал нужен лишь когда
|
|
узкого фрагмента недостаточно.
|
|
|
|
Так защита контекста остается ступенчатой: подробности доходят до владельца
|
|
триажа напрямую, а координатор читает ровно тот уровень, который нужен для
|
|
самостоятельного решения.
|