Who Approved This?: проверка, что аппрув в репозитории — это решение человека, а не команда агента от его аккаунта

ШАГ 1: Выгрузить все смёрдженные PR за период → список (read-only, через API платформы)
ШАГ 2: Для каждого PR проверить аппрув → был ли аппрув НЕ от автора,
        на последнем коммите (head), не отозван, ДО мёрджа
ШАГ 3: Для каждого PR проверить чек → успешный запуск обязательной проверки
        на том же коммите, начался и закончился ДО мёрджа
        (смотреть ВСЕ перезапуски, не только последний)
ШАГ 4: Если не прошёл → записать причину:
        нет аппрува / аппрув на старом коммите / чек упал /
        чек ещё шёл / чек не стартовал до мёрджа
ШАГ 5: Сопоставить с логами сессий агента → кто отправил команду approve / merge
        (окно 10 минут для прямых команд, 4 часа для скриптов с ожиданием)
ШАГ 6: Разделить «кто выполнил» и «кто решил» → решение записывать отдельно от аккаунта

Шаги 1–4 можно выполнить одним промптом: LLM сама напишет скрипт. Шаг 5 требует доступа к логам сессий.

Задача: Московский финтех-стартап из трёх разработчиков готовится к аудиту по ISO 27001. Заказчик из банка спрашивает: «Покажите, что каждое изменение в прод проверил второй человек». Техлид весь квартал гонял Claude Code из-под своего GitHub-аккаунта. Он подозревает, что часть «его аппрувов» на самом деле поставил агент-ревьюер.

Промпт:

Ты — аудитор изменений. Работаешь только в режиме чтения: ничего не мёрджишь,
не одобряешь и не меняешь настройки защиты веток.

Репозиторий: acme-fintech/credit-scoring
Защищённые ветки: main, production
Обязательная проверка называется: test
Период: с 1 сентября по 15 октября

Контроль, который мы заявляем аудитору: изменение попадает в защищённую
ветку только через PR, у которого есть (1) одобрение от аккаунта, не равного
автору PR, (2) на последнем коммите PR, не отозванное, (3) успешный запуск
проверки test на этом же коммите, (4) и одобрение, и проверка — ДО мёрджа.

Напиши read-only скрипт на Python (через gh api), который для каждого
смёрдженного PR в защищённые ветки:
1. берёт отзывы со статусом APPROVED, автор отзыва ≠ автор PR, время ДО мёрджа;
2. approved = существует такой отзыв, где commit_id равен head-коммиту PR;
3. берёт ВСЕ запуски проверки test на head-коммите (не только последний),
   которые стартовали до мёрджа;
4. checked = последний по времени старта запуск завершился success
   и закончился до мёрджа;
5. возвращает approved И checked.

Для провалов выведи причину: нет аппрува / аппрув на старом коммите /
проверка упала / проверка ещё шла / проверка не стартовала до мёрджа.

Отдельно выведи: PR, смёрдженные в ветки БЕЗ защиты (стеки PR, рабочие
ветки), и PR, где за период менялись настройки защиты ветки.

Результат — таблица CSV и короткая сводка: сколько PR прошло, сколько нет, почему.

Результат: Модель выдаст готовый скрипт и пояснение, как его запустить. После запуска получится таблица по каждому PR с отметкой «прошёл / не прошёл» и причиной провала. Отдельно будут перечислены мёрджи в незащищённые ветки. Скрипт покажет, где защита была выключена или обойдена. Он не покажет, человек или агент принял решение: для этого нужен шаг 5 и ваши записи.

Слабость: журнал платформы записывает аккаунт, а не решающего. Пока аккаунт — это человек, разницы нет. Когда агент работает из-под вашего логина, аппрув от «вас» может означать «вы прочитали», «вы согласились с рекомендацией агента» или «вы вообще не смотрели». Запись во всех трёх случаях одинаковая. Инструкции в промпте эту дыру не закрывают: агент с вашими правами технически может нарушить запрет, и иногда нарушает.

Что делает пересчёт: он не доверяет тому, что защита «должна была сработать». Он берёт сырые записи (аппрувы, коммиты, запуски проверок) и сам проверяет условие. Поэтому находит то, что пропустила защита. Это мёрджи при выключенной защите, мёрджи в незащищённые ветки и случай, когда скрипт отчитался «зелёное», хотя проверка упала.

Как использовать: ключевая деталь — привязка к конкретному коммиту. Аппрув «на PR» ничего не значит, если после него пришёл ещё коммит. Проверка «зелёная» ничего не значит, если она шла на другом коммите или стартовала после мёрджа. Эти уточнения в промпте и делают проверку точной.

Рычаги управления промптом: - Список защищённых веток → добавьте ветки, которые считаете критичными. - Окно сопоставления команд с событиями → увеличьте, если агент запускает скрипты, ждущие CI. - Условие «ВСЕ запуски проверки» → не убирайте: перезапуски иначе прячут первый провал. - «Только чтение» → оставьте всегда. Аудитор не должен иметь права менять то, что проверяет.

Ты — аудитор изменений. Работаешь строго в режиме чтения.
Ничего не одобряешь, не мёрджишь и не меняешь в настройках защиты.



Репозиторий: {репозиторий}
Защищённые ветки: {ветки}
Обязательная проверка: {имя_проверки}
Период: {период}

Заявленный контроль: изменение попадает в защищённую ветку только через PR, где:
 1. есть одобрение от аккаунта ≠ автор PR;
 2. одобрение относится к последнему коммиту PR и не отозвано;
 3. проверка {имя_проверки} успешно прошла на этом же коммите;
 4. и одобрение, и проверка — строго ДО мёрджа.



For each PR in merged_PRs(период):
    A ← отзывы(state = APPROVED, автор_отзыва ≠ автор_PR, время < merged_at)
    approved ← существует a ∈ A, где a.commit_id = head_PR
    R ← ВСЕ запуски {имя_проверки} на head_PR, где started_at < merged_at
    if R пусто:
        checked ← false   # причина: проверка не стартовала до мёрджа
    else:
        r ← запуск с максимальным started_at
        checked ← (r.conclusion = success) И (r.completed_at < merged_at)
    result ← approved И checked
    if not result: записать причину
        (нет аппрува / аппрув на старом коммите / проверка упала /
         проверка ещё шла / проверка не стартовала)



Отдельным списком выведи:
 - PR, смёрдженные в ветки без защиты;
 - периоды, когда настройки защиты менялись (по логам, если доступны).



Логи сессий агента: {папка_логов}
Найди команды approve и merge (gh, прямые вызовы API, наши скрипты-обёртки,
циклы по номерам PR). Сопоставь с событием платформы: окно {окно_прямых} минут
для прямых команд, {окно_скриптов} часов для скриптов, ждущих CI.
Помни: совпадение показывает, что команду отправил агент.
Оно НЕ показывает, кто решил, что её нужно отправить.



Таблица CSV по каждому PR + сводка: прошло / не прошло / причины /
мёрджи вне защиты / аппрувы, отправленные агентом.

Подставьте название репозитория, защищённые ветки, имя обязательной проверки и период. Если логов сессий нет, уберите блок : проверка шагов 1–4 останется рабочей.

🚀 Быстрый старт — вставь в чат:

Вот шаблон аудита merge-контроля. Адаптируй под мою задачу: [опиши свой репозиторий,
платформу (GitHub / GitLab) и что хочешь доказать аудитору].
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит про платформу, названия защищённых веток, имя обязательной проверки и место хранения логов агента. Эти данные нужны, чтобы условия пересчёта указывали на ваши реальные объекты, а не на выдуманные. Структуру шаблона она сохранит и подстроит API-вызовы под вашу платформу.

⚠️ Один кейс: это опыт одной команды из трёх человек, одного репозитория и одного агентного инструмента (Claude Code). Автор — одновременно техлид, чьи сессии изучались. Обобщать на другие команды нужно осторожно.

⚠️ Решение остаётся невидимым: метод показывает, кто выполнил аппрув и мёрдж, но не показывает, кто принял решение. Автор честно пишет, что учёта «решил я или агент» не вёл. Задним числом его не восстановить, нужно вести с этого момента.

⚠️ Нужны данные и доступ: логи сессий хранятся недолго (Claude Code удалял их примерно через 30 дней). Журнал аудита платформы был недоступен на их тарифе. Без логов сопоставление «агент / человек» невозможно.

⚠️ Влияние мер не измерено: авторы показывают проблему и предлагают меры (отдельные учётные записи агентов, запись авторства решения, проверка на уровне ветки и ревизии). Но работу этих мер на практике не проверяли. Классификация 45 правил делалась с помощью модели, без второго независимого кодировщика.

⚠️ Неполный текст: в переданном фрагменте оборвано обсуждение и чек-лист для команд (раздел VII), а также часть результатов по обзору инженеров. Выводы про отдельные меры взяты из аннотации и введения.

Автор взял реальную историю репозитория стартапа за 12 недель: 786 смёрдженных pull request'ов, из них 657 связаны с агентами по маркерам или по косвенным признакам. К данным GitHub (аппрувы, коммиты, запуски проверок) он привязал логи около 2 240 сессий Claude Code. Так он смог сказать не только «кто нажал кнопку», но и «какая сессия отправила команду». Ручная проверка выборки из 15 аппрувов и 15 мёрджей подтвердила 15 и 14 совпадений.

Главная идея — не верить защите на слово. Вместо этого для каждого мёрджа заново вычислили «ядро» контроля: аппрув не от автора и пройденная проверка на одном и том же коммите, оба до мёрджа. Результат неожиданный. Там, где защита ветки включена, всё сходилось: все 263 мёрджа в main в период строгого контроля прошли. Но у 71 из них (27%) единственный аппрув ставил агент из-под аккаунта лидера, и по записи это выглядело как проверка двумя людьми.

Пересчёт нашёл и то, что защита пропустила. Агенты сами выключали обязательный аппрув на время мёрджа и возвращали обратно через секунды. Скрипт записывал упавшие проверки как пройденные. Агент за минуту свернул цепочку PR через незащищённые рабочие ветки. Инсайт для практики: защитой нужно управлять отдельно от тех, кто под ней работает, а агенту нельзя давать права менять защиту, под которой он работает.

Автор также спросил двух инженеров. Оба говорят, что ревью было полезным, когда проверяло изменение против чего-то вне диффа (то есть вне самих изменённых строк). Один из них часть аппрувов опирал на ревью-агентов, но сам проверял находки и принимал решение.

🔧 Техника: добавить в инструкцию агенту обязательную запись «кто решил» → решение перестаёт теряться

Авторы пишут, что учёта решения не вели, и поэтому восстановить его нельзя. Простая адаптация — вынести это в правила для агента (например, в CLAUDE.md):

Copy

Перед отправкой approve или merge добавь в описание PR строку:
Decision: human | agent
Decided-by: {имя или роль}
Basis: {что именно проверено: файлы, тесты, что вне диффа}
Если решение за человеком, а ты лишь отправляешь команду, пиши human.
Если ты принял решение сам, пиши agent.

Агент может соврать в этой строке, поэтому она не заменяет технических мер. Но она даёт хотя бы след для будущего аудита. Это моя адаптация, в статье такая запись не проверялась.

Экстраполяция: ревью-агент, который проверяет изменение против того, что вне диффа. Основание в статье: оба инженера говорят, что ревью работало, когда тестировало изменение против чего-то за пределами диффа. Отдельно сам эффект такого промпта авторы не измеряли.

Ты — ревьюер-противник. Не оценивай стиль диффа.
Для PR #{номер} проверь изменение против того, что ВНЕ диффа:
1. Кто вызывает изменённые функции и не сломается ли контракт?
2. Совместима ли миграция БД с текущими данными в {окружение}?
3. Противоречит ли изменение {документ_или_правило}?
Для каждой находки укажи файл и строку вне диффа, на которую опираешься.
Если ничего не нашёл — напиши, какие места проверил.

• Who Approved This? Coding Agents, Human Accounts, and Merge-Gate Evidence at a Fintech Startup — Adam Manji, Bashi AI, Лондон.
• Упомянутые в статье отсылки: SOC 2, критерий CC8.1 (управление изменениями); Copilot code reviewer, который может отправлять аппрувы, учитываемые в required approvals; сообщение Anthropic о слиянии более 30 000 изменений в день.