Агент Peer Reviewer — второй взгляд без общей истории

Та же модель, которая написала документ, — худший рецензент для него. Она знает принятые решения, отвергнутые альтернативы, обоснования, казавшиеся убедительными в тот момент. Весь этот контекст затрудняет видение того, что реально написано на странице. Агент Peer Reviewer построен на противоположном условии: он стартует без общей истории.

Это не проход для полировки. Установка агента — состязательная: его задача — найти слабые места, а не подтвердить, что работа выглядит разумно. Агент обязан выявить не менее двух существенных проблем — или предоставить явные grep-доказательства для каждой проверки, которая вернулась чистой.

Что он делает

Агент получает пути к артефактам — PRD, план, QA-отчёт или код — вместе со списком критериев приёмки и набором подсказок таксономии дрейфа. Затем он проверяет шесть конкретных областей.

Команды верификации критериев приёмки проверяются на семантическую корректность, а не только на синтаксис. Команда вроде grep -c X file подтверждает присутствие строки — но не то, что базовый контракт соблюдён. Заявления DoD без приложенного вывода тестов помечаются как непроверенные. Документы reflection, повествующие об успехе без диагностики того, что пошло не так с первого раза, отмечаются как упустившие урок. Любой высокосерьёзный пробел, тихо перемещённый в бэклог без явного одобрения оператора, фиксируется как несанкционированное понижение приоритета. Агент также проверяет, могут ли шаги верификации быть воспроизведены конца в конец новым оператором без предварительного контекста, и не вышел ли масштаб реализации за пределы того, что реально указано в PRD.

Один конкретный пример

QA-отчёт утверждает, что API-эндпоинт защищён, поскольку существует тест со словом «auth» в названии. Peer Reviewer читает файл теста, находит тест, затем читает тело теста — и замечает, что тест проверяет возврат 200, но заголовок авторизации в тесте захардкожен на валидный токен. Тест проходит независимо от того, требует ли эндпоинт аутентификации для неаутентифицированных запросов. Этот пробел фиксируется как находка; оператор решает, действовать ли до архивирования.

Где он в процессе

Peer Reviewer работает на /dr-verify, конкретно в Layer 2 и Layer 3 трёхслойной архитектуры этой команды. Его изоляция — механизм: он работает на другом чекпоинте модели, чем сессия, создавшая проверяемый артефакт, именно это делает межсемейную проверку содержательной. Инструменты только для чтения — Read, Grep, Glob — изменить что-либо найденное невозможно.

Полный список агентов — на карточке агента Peer Reviewer, а общую картину даёт пост что такое Datarim.