Source Map отвечает на вопрос, который легко потерять при работе с AI-агентом: откуда мы это знаем?

Допустим, один документ требует OAuth 2.0, старый прототип использует API key, а письмо поставщика вводит дополнительное ограничение по сроку жизни токена. Если сразу писать спецификацию, агенту придётся выбрать одну связную версию. Но у него нет полномочия решать, какой источник задаёт норму.

В Source Map каждый материал получает отдельную запись. Минимально в ней нужны:

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

Полезно отделять качество самого документа от его авторитетности. Подробная страница может быть устаревшей. Короткий approved decision может иметь больший нормативный вес, хотя объясняет меньше. Новый файл не всегда главнее старого: дата ничего не говорит о владельце, области действия и праве отменять предыдущее решение.

Конфликт в Source Map стоит хранить как отдельный объект, а не как комментарий внутри одной строки:

text
Conflict: AUTH-03
Source A: API contract v3; OAuth 2.0 required
Source B: prototype README; API key
Scope: production authentication
Owner needed: integration owner
Status: unresolved


Такая запись не разрешает конфликт. Она не даёт агенту выбрать OAuth только потому, что контракт новее, или API key только потому, что прототип уже работает. Она показывает, какое решение отсутствует и кто должен его принять.

После решения Source Map тоже не исчезает. В неё добавляют ссылку на decision record, дату вступления решения в силу и перечень источников, которые оно заменило. Это позволяет позже объяснить, почему спецификация опиралась именно на эту версию.

Для агента карта задаёт дисциплину чтения. Он может найти расхождение, сгруппировать свидетельства и подготовить вопрос владельцу. Он не должен превращать статистическую правдоподобность в организационное полномочие.

Source Map полезна не потому, что создаёт единую истину. Она делает видимым, где истина подтверждена, где ограничена областью действия, а где команда пока живёт с несколькими несовместимыми версиями.

Source Map и Context Map решают разные задачи.

Source Map показывает происхождение знания: какие материалы существуют, кто ими владеет, каков их статус и где они противоречат друг другу.

Context Map в этой серии — рабочее название карты границ задачи. Она показывает, в какой системе действует требование, какие акторы участвуют в процессе, какие интеграции пересекают границу и кто отвечает за решение. Это пока не отдельный канонический артефакт метода, а полезный способ не потерять устройство задачи.

Возьмём требование: «после ошибки платёж можно повторить». Source Map поможет найти контракт API, правила идемпотентности, описание пользовательского пути и решение о статусах заказа. Но она не ответит, где начинается и заканчивается рассматриваемый процесс.

Context Map добавляет другую оптику:

text
Акторы: покупатель, продавец, оператор поддержки
Системы: checkout, платёжный шлюз, ledger, уведомления
Граница: от подтверждения заказа до финального статуса платежа
Интеграции: gateway API, webhook, email
Ответственность: кто решает судьбу зависшего платежа
Вне scope: расчёт доставки и возврат товара


Теперь видно, что слово «повторить» затрагивает не только кнопку. Нужно определить судьбу первого запроса, защиту от двойного списания, обработку позднего webhook и состояние, которое пользователь увидит после восстановления.

Context Map нельзя подменять System Context Pack. Карта сохраняет топологию задачи: границы, связи, участников и зоны ответственности. System Context Pack появится позже и соберёт компактные проверяемые утверждения, необходимые конкретному исполнителю или агенту.

Если сразу перейти к SCP, команда рискует хорошо сжать плохо очерченную задачу. В пакет попадут факты об отдельных компонентах, но исчезнет вопрос, какие системы вообще участвуют в сценарии и кто имеет право принять спорное решение.

Рабочая последовательность выглядит так:

Source Map → Context Map → System Context Pack

Сначала устанавливаем происхождение знаний. Затем очерчиваем границы и связи. Только после этого решаем, какие утверждения нужны агенту для конкретной работы.

Карта источников защищает от неподтверждённых знаний. Карта контекста защищает от неверного масштаба задачи. Смешивание этих функций создаёт либо каталог без системы, либо красивую схему без доказательств.

System Context Pack нужен не для того, чтобы пересказать агенту все документы проекта. Он собирает минимальный набор проверяемых утверждений для конкретной задачи.

После Source Map уже понятно, откуда пришли знания и какие источники конфликтуют. После карты границ видно, какие акторы, системы и интеграции входят в scope. Теперь можно сжать контекст, не потеряв происхождение каждого существенного правила.

Полезная единица SCP выглядит не как абзац справочного текста, а как запись с опорой:

text
Rule: повтор платежа использует новый request_id
Source: API contract v3, section 4.2
Scope: production checkout
Status: approved
Depends on: decision PAY-17
Open conflict: поведение позднего webhook не определено


Такая структура заставляет отделять четыре состояния.

Первое — подтверждённое правило. Источник имеет право определять эту часть системы, а область действия понятна.

Второе — рабочее предположение. Команда разрешила использовать его в ограниченном scope, но не выдала за постоянную норму.

Третье — неизвестное. Нужного источника нет или доступ к нему закрыт.

Четвёртое — конфликт. Несколько авторитетных материалов дают несовместимые ответы, и владелец решения пока не выбрал действующую версию.

Обычный summary устраняет шероховатости. Хороший SCP сохраняет их, если они влияют на результат. Фраза «система поддерживает повтор платежа» звучит компактно, но скрывает request_id, судьбу первой операции, позднее подтверждение и право на отмену.

Команда может проверить сжатие обратным ходом. Для каждого утверждения она задаёт вопросы:

1. Какой источник подтверждает утверждение?
2. Почему этот источник авторитетен в данном scope?
3. Какую версию правила использует пакет?
4. Какие конфликты и пробелы остались открытыми?
5. Какие сценарии или решения зависят от утверждения?

Если ответ нельзя восстановить, пакет потерял проверяемость. Если SCP содержит весь архив проекта, он потерял назначение и снова превратился в папку файлов.

Сила System Context Pack находится между этими крайностями. Он достаточно мал, чтобы агент удерживал рабочую задачу, и достаточно точен, чтобы человек мог проверить каждое существенное основание.

Prompt debt возникает, когда команда добавляет инструкции для агента быстрее, чем проверяет их необходимость.

В проект команда добавляет AGENTS.md, правила для конкретной модели, обходы старых ошибок, советы по инструментам и дублирующиеся запреты. Через несколько обновлений никто уже не знает, какая строка влияет на результат, а какая только увеличивает контекст.

Удалять такой долг полезно, но сначала инструкции нужно разделить по роли.

Адаптер среды объясняет конкретному агенту, где лежат команды, как запускать проверки и в каком формате возвращать результат. После смены инструмента этот слой можно заменить.

Workflow-инструкция задаёт порядок работы: прочитать контекст, зафиксировать решение, выполнить тест, сохранить доказательство. Её можно упрощать, если эксперимент показывает, что шаг не влияет на безопасность и воспроизводимость.

Product truth описывает поведение, которое нужно пользователю: границы сценария, бизнес-правила, состояния ошибки и восстановления. Это не настройка модели.

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

Для чистки подходит абляция: убрать одну инструкцию, повторить зафиксированные сценарии и сравнить не красоту ответа, а наблюдаемое поведение. Проверка должна показать, сохранил ли агент обязательные артефакты, ссылки на источники, ограничения доступа и границу UAT.

Если удаление фразы не меняет эти свойства в серии прогонов, у команды появляется основание сократить инструкцию. Если после удаления агент пропускает конфликт источников или сам принимает результат, строка защищала важный контракт, даже если выглядела как техническая деталь.

Есть и обратная ошибка: хранить product truth только внутри prompt-файла конкретного агента. Тогда смена модели требует миграции требований, а несколько адаптеров начинают описывать продукт по-разному.

Более устойчивое разделение выглядит так:

источники и решения → сценарии и критерии → общий workflow → адаптер конкретного агента

Prompt debt можно удалять. Продуктовую правду, permissions, evidence contract и UAT нужно переносить в независимые артефакты и проверять отдельно. Иначе оптимизация контекста незаметно меняет сам объект, который агент должен построить.

Изменение авторитетного источника не заканчивается обновлением одного файла.

Представим, что действующий контракт меняет правило повтора операции. Раньше клиент повторял запрос с прежним идентификатором, теперь должен создавать новый. Команда обновила API-документ, но спецификация, сценарии и тесты всё ещё описывают старое поведение.

AI-агент может обнаружить расхождение. Для этого ему нужны версия источника, дата вступления правила в силу и трасса зависимостей:

источник → правило спецификации → пользовательский сценарий → тест → реализация → UAT

После изменения агент строит impact set: перечень артефактов, которые могут устареть. В него попадут правило повторной отправки, сценарий восстановления, проверка идемпотентности, обработка позднего ответа и инструкция поддержки.

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

Поэтому запись изменения должна отвечать на вопросы:

1. Какое утверждение изменилось?
2. Кто утвердил новую версию?
3. Когда она вступает в силу?
4. Какие системы и сценарии используют новую версию?
5. Какие производные артефакты требуют пересмотра?
6. Как поступить с ранее принятыми результатами?

Агент способен собрать ссылки, сравнить формулировки и пометить зависимые элементы как STALE. Он может предложить порядок повторной проверки. Право разрешить конфликт остаётся у владельца решения, потому что выбор версии меняет обязательства системы, а не только текст документа.

Прошлый Green тоже нельзя переносить автоматически. Тест доказал соответствие прежнему сценарию и прежнему baseline. После изменения существенного источника сначала определяют самый ранний затронутый гейт, затем обновляют сценарий и только потом запускают проверку снова.

Трассируемость полезна именно в момент изменения. Пока документы согласованы, команда может считать цепочку лишней. Когда источник меняется, она показывает границу повторной работы и не позволяет агенту тихо переписать историю решения.

Связный ответ агента и зелёный тест не равны принятому результату.

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

Представим функцию повторного платежа. Автоматические тесты подтверждают новый request_id, защиту от дубля и корректный статус после успешного ответа. Все проверки зелёные. При этом спецификация ничего не говорит о позднем webhook после отмены пользователем.

Команда может принять результат в ограниченном scope, отклонить его или остановить выпуск до решения. Ни один из этих вариантов не следует из цвета теста автоматически.

Для UAT полезно хранить отдельную запись:

text
Result: retry-payment revision 4
Evidence: E2E-12, E2E-13, E2E-18 passed
Context baseline: CB-09
Residual uncertainty: late webhook after user cancellation
Decision: accepted with limitation
Owner: payment product owner
Follow-up: scenario E2E-21 before partner rollout


Такая запись показывает, что человек принял не абстрактное «всё работает», а конкретный результат с известной границей и остаточной неопределённостью.

Приёмка не требует ручного повторения всех автоматических проверок. Человек проверяет другой слой:

• соответствует ли результат исходной пользовательской ситуации;
• достаточно ли доказательств для ставки и риска;
• не потерялся ли конфликт при сжатии контекста;
• понятны ли ограничения и последствия выпуска;
• имеет ли принимающий право сделать это решение.

Если тот же агент сформулировал критерий, реализовал изменение, поправил тест и объявил результат готовым, система получила замкнутый контур самооценки. Независимая граница приёмки разрывает этот контур.

Остаточная неопределённость неизбежна. Задача UAT не удалить её красивой формулировкой, а сделать видимой и принять осознанное решение: выпускать, ограничить scope, вернуть на доработку или остановить.

Контекст, сценарии и тесты подготавливают решение. Ответственность за принятый исход остаётся у человека.

Бизнес-запрос часто приходит в виде пожелания: «ускорить согласование», «снизить число ошибок», «сделать отчёт понятнее». Это ещё не требование. В нём нет наблюдаемого исхода, по которому можно проверить, что изменение помогло.

Я начинаю с вопроса: что должен увидеть пользователь после изменения и в какой ситуации? Например, не «ускорить оплату», а «покупатель получает подтверждение заказа не позднее чем через минуту после успешной авторизации». Такой исход можно связать со сценарием, источником и проверкой.

Дальше фиксирую границу: что входит в задачу, а что остаётся за её пределами. Если этого не сделать, агент заполнит пробелы правдоподобными деталями. Формально получится полный текст или код, но он будет отвечать на другую проблему.

Полезно записать пять полей: исходная проблема, наблюдаемый результат, затронутый пользователь, ограничение и способ проверки. Это не бюрократия. Такая запись задаёт направление для требований, сценариев и тестов.

Такая карточка нужна и при изменении требования. Если владелец меняет ожидаемый результат или ограничение, команда сразу видит, какие сценарии и проверки потеряли основание. Без этой связи старый тест может оставаться зелёным для уже неактуальной задачи.

AI-агент может помочь разложить расплывчатый запрос на варианты исхода и найти противоречия в материалах. Но выбрать, какой исход важен для бизнеса, должен человек. Иначе система начнёт оптимизировать удобный для неё показатель.

Если исход нельзя наблюдать или проверить, требование ещё не готово к реализации. Сначала превращаем запрос в проверяемое изменение поведения, затем обсуждаем решение.

Перед передачей задачи агенту я показываю эту формулировку человеку, который отвечает за результат. Если он не может назвать наблюдаемый исход и способ его проверить, мы уточняем запрос до начала работы. Это экономит время не за счёт скорости генерации, а за счёт меньшего числа неверных итераций.

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

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

Представим интеграцию, где новая спецификация требует OAuth, архивная страница описывает API key, а письмо поддержки уточняет лимит запросов для отдельного тарифа. Все три записи могут быть полезны, но у них разный вес. Контракт задаёт правило, письмо — ограничение для конкретного случая, архив нужен лишь для объяснения происхождения.

Source Map помогает показать эту иерархию до того, как документы попадут в контекст агента. Если два источника равноправны и расходятся, конфликт нужно оставить видимым и вернуть владельцу решения. Автоматическое «усреднение» создаёт новую, никем не принятую норму.

Агент способен извлечь версии, найти расхождения и построить список кандидатов. Он не может сам наделить документ полномочием. Это решение связано с ответственностью и областью применения.

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

В спорном случае я не удаляю старый источник. Помечаю его область и срок действия, сохраняю связь с новым решением и явно записываю, какой конфликт остался открытым. Так агент видит историю, но не принимает её за действующую норму.

Требование становится рабочим, когда у него есть сценарий, в котором можно увидеть изменение поведения. Фраза «агент должен корректно обработать заказ» слишком общая: непонятно, какой вход, какой результат и что считать ошибкой.

Я связываю требование с предусловиями, шагами пользователя, ожидаемым артефактом и проверкой. Для платёжного сценария это может быть: авторизация фиксирует курс, повторный запрос не создаёт второй заказ, подтверждение содержит тот же идентификатор. Такие связи позволяют агенту реализовать конкретное поведение, а проверяющему — воспроизвести его.

Важно различать сценарий и реализацию. Сценарий описывает наблюдаемую границу системы, а не название функции или конкретный промпт. Если поменялась модель или способ интеграции, сценарий остаётся ориентиром, пока бизнес-исход не изменился.

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

Полезная проверка простая: можно ли по одному сценарию понять, что произошло, какой артефакт появился и почему результат принят? Если нет, связь требования с исходом ещё не проведена.

Трассировка здесь — не таблица ради таблицы. Это способ удержать одну линию от бизнес-проблемы до наблюдаемого действия системы.

Хороший сценарий можно выполнить без доступа к внутреннему коду: по входу и наблюдаемому результату другой человек понимает, что именно должно произойти. Это делает проверку независимой от конкретного агента и снижает риск, что тест лишь повторит его интерпретацию.

Happy path показывает, что система умеет пройти удачный маршрут. Он почти ничего не говорит о том, что произойдёт при тайм-ауте, повторном запросе или частично созданном артефакте.

В интеграции заказа я отдельно описываю отказ авторизации, задержку письма, повторный checkout и восстановление после сбоя CRM. Для каждой ветки нужен ожидаемый результат: что увидит пользователь, какой статус сохранится и кто принимает решение о повторной попытке.

Если в требованиях есть только успешный сценарий, агент обычно реализует именно его. Код может пройти зелёный тест, а в эксплуатации оставить дубли, потерянные уведомления или зависшие заказы. Это не «редкая крайность», а отсутствие покрытия.

Связь с ошибкой должна вести назад к источнику и решению. Тогда при изменении ограничения можно найти не только основной тест, но и ветки восстановления, логи и инструкции оператора.

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

Минимальный вопрос к каждому требованию: что произойдёт, если следующий шаг не случится, случится дважды или вернёт неполный результат? Ответ превращает счастливый маршрут в проверяемую систему.

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

Нефункциональное требование часто звучит как пожелание: «быстро», «надёжно», «безопасно». Пока не определены наблюдаемый критерий и способ измерения, принять его нельзя.

«Быстро» превращается в проверку времени ответа для конкретного сценария и нагрузки. «Надёжно» — в допустимую долю повторных ошибок, восстановление и отсутствие потери данных. «Безопасно» — в список разрешений, запретов и проверяемых событий. Формулировка должна указывать субъект, границу и свидетельство.

Критерий связывается с артефактом: метрикой, логом, трассировкой, снимком состояния или результатом теста. Если внешний код исправил формат ответа, это нужно сохранить как часть evidence, иначе отчёт создаст ложное впечатление о качестве.

AI-агент может собрать измерения, сопоставить их с порогами и показать пропуски. Он не должен подменять отсутствие данных зелёным статусом. Нельзя принять NFR, если измерение не охватывает заявленную область.

Перед реализацией я проверяю: кто измеряет, каким инструментом, на каком наборе входов и что происходит при нехватке свидетельств. Эти ответы связывают качество с ответственностью, а не с красивым числом в дашборде.

Нефункциональный критерий становится частью требования только тогда, когда его можно воспроизвести и предъявить владельцу решения для приёмки.

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

Изменение источника редко ограничивается одной строкой в документе. Новое правило может сделать устаревшими требование, сценарий, тест, решение в журнале и уже написанную реализацию.

После смены авторитетной версии я сначала строю impact trace: какие записи ссылаются на источник, какие артефакты были из него выведены и где зафиксировано принятое решение. Агент способен найти широкий список кандидатов, но не должен молча переписывать его.

Для каждого кандидата фиксирую причину: изменился вход, критерий, разрешение, срок действия или только пояснение. Затем владелец решает, что инвалидировать, что оставить для истории и какие проверки запустить заново.

Например, если контракт меняет момент фиксации курса, устаревают не только пункт спецификации, но и сценарий оплаты, тест расчёта, отчёт сверки и инструкция поддержки. Decision Log хранит основание изменения и помогает определить границу повторной приёмки.

Полезно разделять состояния «реализовано», «проверено» и «принято». Технически зелёный тест показывает, что текущая версия прошла проверку; он не подтверждает, что проверялось ещё действующее требование.

Impact trace нужен не для тотального контроля, а чтобы изменение не оставляло за собой тихий хвост старых решений.

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

Зелёный результат завершает техническую проверку, но не принимает остаточный риск. Тест может подтвердить схему, наличие файла и прохождение сценария, а пользовательский исход всё равно оказаться не тем.

В конце цепочки я фиксирую, что именно проверено, какие ограничения остались и кто имеет право сказать «этого достаточно». Именованный владелец видит evidence, нерешённые конфликты и последствия альтернатив. Только после этого результат становится принятым.

Это особенно важно для AI-агента. Он может собрать артефакт, прогнать тесты, показать ссылки на источники и вернуть список неопределённостей. Но тот же исполнитель не должен единолично объявлять свою работу соответствующей потребности пользователя.

Приёмка — не формальность после зелёного CI. Это решение о том, что конкретный исход подходит в заданной области, при известных ограничениях и цене ошибки. Иногда правильный результат — вернуть задачу на уточнение, а не закрыть её.

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

Так трассировка заканчивается не статусом «green», а понятной человеческой ответственностью за то, что система действительно готова к использованию.

Имя принимающего важно не для поиска виноватого. Оно показывает, где заканчивается механическая проверка и начинается решение о допустимости. Если такого имени нет, статус лучше оставить «проверено», а не превращать его в обещание готовности.

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

Завершение отвечает на вопрос: «Среда закончила работу?» Приёмка отвечает на другой вопрос: «Получен ли тот результат, которым команда готова пользоваться и за который владелец готов отвечать?»

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

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

Поэтому до запуска полезно разделить контур на четыре записи.

Первая запись — условие завершения работы. Какие файлы созданы, какие команды выполнились, какие технические ошибки устранены.

Вторая — наблюдаемый результат. Что именно увидит пользователь или соседняя система в согласованном сценарии: например, повторный запрос с тем же ключом не создаёт второй платёж.

Третья — свидетельство проверки. Ссылка на тест, журнал или другой артефакт, который может открыть и повторить независимый проверяющий.

Четвёртая — решение о приёмке. Именованный человек подтверждает, что сценарий выражает потребность, ограничения приемлемы, а остаточный риск принят.

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

Практический протокол прост: сначала запишите пользовательский исход и границы допустимого, затем определите технический признак завершения и независимое свидетельство. После работы сравните результат с исходным сценарием, а не только с тем, что получилось реализовать.

Завершённая работа — это состояние процесса. Принятый результат — решение владельца по наблюдаемому исходу. Пока эти записи не разделены, команда легко путает аккуратно сделанное с нужным.

У завершённой задачи есть простой соблазн: считать её принятой, когда агент закончил работу и показал зелёные проверки. Но техническое завершение и решение о достаточности принадлежат разным уровням.

Завершение описывает состояние процесса. Команды отработали, файлы записались, формат ответа выдержан, проверяющий может открыть журнал. Это необходимая часть результата, но она не отвечает на вопрос, решена ли исходная задача.

Приёмка описывает ответственность. Кто-то должен подтвердить, что выбранный сценарий соответствует потребности, ограничения не нарушены, а оставшийся риск можно принять. Такой человек не просто читает отчёт. Он имеет право сказать: «Этого достаточно» или «Нужно вернуться к постановке».

Представьте агента, который обновляет платёжную интеграцию. Он выполнил миграцию, прогнал тесты и приложил логи. Все технические условия зелёные. Но владелец сценария имел в виду повторный запрос после тайм-аута: покупатель не должен получить второй платёж. Если это условие не попало в критерий заранее, агент может завершить работу без принятого результата.

Здесь полезно различать три роли.

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

Иногда все три роли выполняет один человек. Это не отменяет различия функций. Если исполнитель сам объявляет свою работу принятой, команде сложнее заметить, что критерий был неполным или выбранный компромисс никем не принят.

Практический протокол начинается до запуска. Сначала назовите владельца решения и запишите наблюдаемое поведение в конкретном сценарии. Затем отдельно зафиксируйте техническое условие завершения и способ получить независимое свидетельство. После выполнения проверяющий сверяет результат с исходным сценарием, а владелец решает, достаточно ли этого для дальнейшего шага.

Зелёная проверка говорит: «заданный тест прошёл». Приёмка говорит: «команда готова считать этот исход своим». Первое можно автоматизировать. Второе требует явно названного права решения.

Перед запуском работы с AI-агентом полезно проверить не сам запрос, а то, что вы собираетесь считать результатом.

В требованиях часто описывают действие: «собери документы», «проверь интеграцию», «подготовь вывод». Но действие ещё не задаёт границу приёмки. Если заранее не определить, какой артефакт должен появиться, проверка начнётся слишком поздно: команда увидит красивый ответ и будет спорить уже о деталях реализации.

Представим интеграционный проект. Перед стартом нужно зафиксировать четыре вещи:

1. Какой результат существует физически: документ, запись в системе, изменение схемы или решение с указанным владельцем.
2. Какие свойства можно проверить автоматически: обязательные разделы, ссылки на источники, формат данных, наличие всех файлов.
3. Что считается неполным результатом: путь к будущему файлу, заглушка, фраза «уточняется», конфликт источников без вынесенного решения.
4. Кто принимает остаточный риск, если все технические проверки зелёные, а бизнес-ситуация всё ещё допускает несколько трактовок.

Без этого агент легко превращает неизвестное в уверенный текст. Например, в контракте указана одна версия API, в переписке с поставщиком — другая. Агент может выбрать одну и продолжить, хотя правильным исходом запуска было бы зафиксировать конфликт и вернуть его владельцу решения.

Поэтому evidence нужно собирать до запуска, а не после. Сначала записываем источники, их даты, владельцев и область действия. Затем формулируем критерий: что должно быть доказано и каким наблюдением это подтверждается. Только потом запускаем агента и проверяем, что он создал полный артефакт.

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

Практический минимум перед стартом:

— назовите будущий артефакт и место, где он должен появиться;
— выпишите обязательные свойства результата;
— перечислите известные отрицательные сценарии;
— укажите источники и владельцев спорных решений;
— назначьте человека, который имеет право принять остаточную неопределённость.

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

Зелёная проверка отвечает только на тот вопрос, который в неё заложили.

Если чекер подтвердил схему JSON, это ещё не значит, что найден нужный артефакт. Если артефакт на месте, это ещё не значит, что он решает задачу пользователя. А если критерии выполнены, всё равно остаётся вопрос: кто принимает остаточный риск?

Поэтому перед передачей результата я фиксирую не только pass, но и границу проверки: что именно она покрывает, чего не покрывает и кто должен принять следующий шаг.

Результат полезен только тогда, когда другой человек может пройти тот же путь проверки.

Поэтому к выводу нужно приложить не красивый пересказ, а исходный артефакт, точную ссылку на источник, версию критерия и описание того, что именно было проверено. Если шаг нельзя повторить, это наблюдение, а не evidence для приёмки.

Воспроизводимость важнее уверенного тона.

Хороший gate должен уметь не только пропускать результат, но и вовремя сказать «нет».

Самый опасный сценарий — не падение агента. Это зелёный ответ, который выглядит завершённым, но не содержит того, что обещал.

Например, агент вернул все обязательные поля, но внутри лежат пути к будущим файлам. Или документ заполнен заглушками. Или полный артефакт собран, но в нём применено старое правило, которое уже не действует.

Поэтому отрицательный путь нужно описывать заранее:

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

Gate, который умеет только ставить зелёную галочку, проверяет happy path. Gate, который сохраняет причину отказа и границу проверки, помогает понять, что именно чинить.

Отказ — не провал процесса. Иногда это единственное честное свидетельство, что система не выдала результат за готовый.

Зелёный тест отвечает только на тот вопрос, который в него заложили.

Можно проверить JSON, обязательные поля и схему — и всё равно не получить результата для пользователя. В поле окажется путь к будущему файлу, заглушка или старое правило.

Поэтому перед приёмкой я задаю пять вопросов:

1. Запрос завершился без технического обрыва?
2. Все обещанные артефакты существуют и непусты?
3. Источники и решения относятся к актуальной версии задачи?
4. Проверка действительно покрывает пользовательский сценарий?
5. Кто по имени принимает остаточный риск?

Если на последний вопрос нет ответа, «готово» означает только конец работы агента. Не принятие результата.

Руководитель просит оставить сотруднице старый доступ до пятницы: ей нужно передать незакрытые обращения. В учебном сценарии перевода в другую команду это сообщение лежит рядом с HR-заявкой, действующей политикой безопасности и каталогом ролей. Если собрать из них одну гладкую постановку, просьба легко превращается в якобы согласованное исключение.

У каждого источника своя роль. HR-заявка подтверждает перевод. Каталог показывает старую и новую роли. Политика запрещает их одновременное назначение. Сообщение руководителя объясняет рабочую потребность, но не меняет правило.

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

Здесь аналитику важно не потерять ни потребность, ни ограничение. Команде действительно нужно передать дела. При этом выдача новой роли со старым доступом нарушит действующее правило, пока уполномоченный владелец не оформит допустимое исключение. В карте источников это конфликт; в постановке — открытое решение с владельцем; в приёмке — отдельные проверяемые пути.

Без исключения старая роль снимается до выдачи новой, пересечение ролей не допускается. Если исключение будет одобрено, проверка должна увидеть само решение, ответственного и срок действия. Пока решения нет, второй путь остаётся закрытым. Даже если система технически умеет назначить обе роли, это не доказывает, что так разрешено поступить.

Когда аналитик пишет «сохранить доступ до пятницы», он уже сделал выбор за ответственного по безопасности. Точная запись пока другая: «руководитель просит время на передачу дел; текущее правило запрещает пересечение ролей; допустимость и срок исключения требуют отдельного решения». Так разработка видит, что реализовать сейчас, а какой вопрос нельзя спрятать в формулировке требования.