11. Работа с ИИ-агентом¶

Это не «ручной режим». Распространённое заблуждение: раз RENAR требует утверждений человеком, значит всё делается вручную. На деле наоборот — основную работу (черновики BR/SR/SPEC/TC, первичную интерпретацию ТЗ, поиск противоречий) выполняет агент. Человек не печатает артефакты, а утверждает их в нескольких фиксированных точках. Эта глава показывает, как загрузить стандарт в агента, какие команды давать и что вы получите на выходе.

Нормативная модель делегирования — standard/05 Роли и точки утверждения ADAPT — standard/07 §7. Самодостаточная редакция для агента — RENAR-AGENT-RU.md (в корне репозитория и на renar.tech).

1. Кто что делает: карта делегирования¶

Агент — исполнитель: он производит и ведёт артефакты, но не владеет ими и не ставит подписей. Человек — владелец и тот, кто утверждает. Граница проходит по фиксированным точкам:

Шаг	Делает агент	Утверждает человек
Импорт ТЗ	Регистрирует ТЗ как неизменяемый документ, фиксирует подпись клиента	— (подпись ставит клиент при сдаче ТЗ)
Состязательный обзор	Агент-критик на другой модели выносит вердикт «есть находки» / «находок нет»	Архитектор фиксирует вердикт как свидетельство
ADAPT	Готовит черновик: прямая интерпретация + обратные находки	Подпись Архитектора — и только его: ADAPT клиенту не выносится
ACTZ	Готовит проект протокола уточнения ТЗ по находкам	Двусторонняя подпись: клиент + исполнитель. Вопросы перед выносом агрегирует и переформулирует Архитектор
Декомпозиция	Создаёт `BR` → `SR` → `SPEC` → `TR` с провенансом	Архитектор одобряет переход в `approved` (QG-0)
Тесты	Пишет пары `TC` (позитивный + негативный) — до реализации и не тем агентом, который её пишет	Автоматический прогон фиксирует результат (QG-2)
Приёмочные тесты	Изолированный агент на другой модели выводит `AT` только из итогового ТЗ	Релизный гейт: все `AT` зелёные
Сдача	Предъявляет бизнес-результат	Заинтересованная сторона принимает его (QG-4)

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

Граница двух контуров. Всё, что показано клиенту и подписано, — обязательство (ACTZ). Всё, что не показано, — интерпретация (ADAPT). Агент обязан различать: вопрос, требующий решения клиента, идёт в проект ACTZ, а не «додумывается» в прямой интерпретации (standard/07 §7.13).

2. Как загрузить стандарт в агента¶

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

Скачайте RENAR-AGENT-RU.md — самодостаточную операционную редакцию (≈400 строк): карта артефактов, рабочий процесс, ADAPT, закрытые списки, жёсткие правила, формы записи (frontmatter + тела разделов).
Положите файл рядом с агентом — в контекст проекта, в системный промпт или как вложение сессии (зависит от вашего инструмента).
Дайте установочную команду: «Изучи этот файл — это стандарт RENAR. Дальше веди инженерию требований строго по нему».
По желанию добавьте проектный контекст: реестр систем и подсистем, ссылку на ваш носитель артефактов, конвенцию именования.

Полный корпус (standard/, reference/) подключайте только когда возник формальный спор о точной формулировке нормы — для большинства задач хватает операционной редакции.

3. Как давать команды¶

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

Импорт и обзор ТЗ:

Вот ТЗ клиента (файл TZ-2026-001). Зарегистрируй его как неизменяемый документ.
Затем проведи состязательный обзор: вынеси вердикт «есть находки» или «находок нет»,
с обоснованием по 7 категориям (противоречие, пропуск, скрытое предположение,
реализуемость, регуляторика, терминология, граница работ).

Создание ADAPT (если есть находки):

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

Протокол уточнения ТЗ (ACTZ):

Собери находки, требующие решения клиента, в проект ACTZ — «Протокол уточнения ТЗ № 1».
Каждый пункт формулируй на языке обязательств («домен сравнивается без учёта регистра»),
а не толкования, и добавь предложение исполнителя. Статус — draft: выносить клиенту
и подписывать буду я.

Декомпозиция:

ACTZ-001 подписан обеими сторонами, ADAPT утверждён. Проставь decided-in на пункты
протокола во всех закрытых находках. Выведи из ADAPT BR (бизнес-цель), затем SR
(поведение системы), затем SPEC нужных типов. У каждого артефакта проставь source
и parent. Покажи граф связей перед тем, как фиксировать.

Тесты:

Для каждого нормативного утверждения в SR-03 напиши пару TC: позитивный и негативный.
Pass-критерий — бинарный и наблюдаемый. Реализации ещё нет и быть не должно: сначала
заморозим тесты, потом код — и писать код будет другой агент.

Приёмочные тесты (отдельная сессия, другая модель):

Вот итоговое ТЗ: TZ-2026-001 плюс подписанные ACTZ-001 и ACTZ-002. Больше у тебя
ничего нет и не будет — ни требований, ни спецификаций, ни тестов, ни кода.
Выведи AT: приёмочные тесты по пунктам контракта, с дословной цитатой пункта
рядом с шагами проверки, пары позитивный/негативный.

Хорошая команда называет вход (какой артефакт), действие (что вывести) и ожидание (что проверить). Агент сам решает рутину; вмешивайтесь там, где нужно ваше решение.

4. Что получается на выходе¶

Агент возвращает не текст в чате, а готовые артефакты носителя — с машиночитаемым frontmatter и телом по фиксированным разделам:

BR — бизнес-потребность: кто, что, зачем; критерии успеха; контекст со ссылкой на ADAPT.
SR — поведение системы: одно требование, поведение, ограничения, связь со SPEC.
SPEC-<ТИП> — спецификация одного из одиннадцати типов, связанная с SR через constrained-by[].
TC — пары позитивный/негативный с verifies[] на проверяемый артефакт.
ACTZ — проект протокола уточнения ТЗ: пункты решений на языке обязательств, status: draft до выноса клиенту.
AT — приёмочные тесты со ссылками только на ТЗ и ACTZ, с дословной цитатой пункта контракта и провенансом изолированного генератора.

У каждого артефакта проставлен source (происхождение от ТЗ или ADAPT) и, для AI-сгенерированных, блок ai-provenance (модель, шаблон промпта, факт человеческой правки). Готовые copy-paste заготовки всех форм — в reference/12 Шаблоны документов.

Признак хорошего выхода: по любому артефакту прослеживается цепочка вверх — до SR, до BR, до раздела ТЗ. Если цепочка рвётся, артефакт не готов.

5. Точки человеческого утверждения¶

Делегирование агенту широкое, но у него есть жёсткие границы. Человек обязателен в пяти местах (нормативно — standard/10 Жизненный цикл и контрольные точки):

Подпись ТЗ — клиент подписывает договорной вход; агент только регистрирует.
Двусторонняя подпись ACTZ — клиент и исполнитель подписывают протокол уточнения ТЗ. Это единственное место, где возникает обязательство перед клиентом (§7.13).
Подпись Архитектора на ADAPT (QG-3) — Архитектор подтверждает, что все находки отработаны (каждая несёт decided-in на пункт подписанного ACTZ) и что интерпретация реализуема. Клиент ADAPT не подписывает: он его не видел (§7.5).
Одобрение QG-0 — Архитектор переводит BR/SR/SPEC из draft в approved. Только после этого разрешена декомпозиция дальше.
Приёмка — релизный гейт по AT (все зелёные) и, опционально, QG-4 по бизнес-результату.

Между этими точками агент действует сам. Попытка заставить агента подписать или объявить его ответственным (Accountable) — нарушение модели ролей.

6. Кто пишет тест и почему он обязан быть красным¶

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

Изоляция авторства (standard/09 §9.18). Тест, написанный тем же агентом, который пишет код, — и особенно написанный после кода, — честно проверяет то, что написано. Но проверять он должен не код, а требование. Поэтому изоляция держится на трёх осях:

Ось	Что означает на практике
Время	`TC` заморожен в `ready` до старта задачи. Носитель не даёт открыть TR, пока тесты не заморожены
Автор	Агент, пишущий `TC`, — не тот, что пишет реализацию: другая сессия или другая модель
Изменение	Правку Pass/Fail-критериев замороженного теста утверждает инженер; молча «подправить тест под код» нельзя

Красная история (§9.18.2). Тест, ни разу не наблюдавшийся красным, доказательством не является. Фиксирующий прогон делается до реализации, и тест обязан упасть: проверяемой функциональности ещё нет. Зелёный на фиксирующем прогоне — не успех, а сигнал разбора: либо тест ничего не проверяет, либо функциональность уже есть.

Исключение одно — тесты класса implementation-originated (standard/06 §6.13): внутренняя техническая деталь, добавленная агентом при реализации (защитная проверка, журналирование), не наблюдаемая клиентом. Такой тест пишется после кода и рождается зелёным — красной истории у него не бывает по построению. Компенсация обязательна: его зубастость доказывается убитым мутантом. И граница класса жёсткая: наблюдаемое клиентом поведение через него не легализуется — обязательство перед клиентом не может возникнуть из кода.

Изоляция генератора AT (§9.19.2). Приёмочные тесты выводит отдельный агент на другой модели, которому на вход подаётся только итоговое ТЗ. Доступ к ADAPT, BR/SR/SPEC, TC и коду запрещён — не из гигиены, а потому что AT есть симуляция взгляда заказчика. Агент, увидевший ADAPT, воспроизведёт ту же интерпретацию, и AT начнёт подтверждать её вместо контракта: уровень приёмки схлопнется в уровень верификации.

7. Типичный сеанс целиком¶

Чтобы снять ощущение «магии», вот сквозной сценарий — что делает агент и где вступает человек:

Вы передаёте агенту ТЗ и RENAR-AGENT-RU.md. Агент регистрирует ТЗ.
Агент-критик (другая модель) проводит состязательный обзор → вердикт «есть находки».
Агент готовит черновик ADAPT с находками и проект ACTZ. Архитектор доводит протокол до вида, понятного клиенту, выносит его, подписывает вместе с клиентом → ACTZ подписан; находки получают decided-in; Архитектор утверждает ADAPT своей подписью.
Агент выводит BR → SR → SPEC, показывает граф связей. Архитектор одобряет QG-0.
Агент-тестировщик пишет пары TC; фиксирующий прогон — красный; тесты замораживаются.
Другой агент пишет реализацию, пока тесты не позеленеют; runner фиксирует результат (QG-2).
Изолированный агент перед испытаниями выводит AT из итогового ТЗ и прогоняет их. Все зелёные → продукт можно предъявлять.
Агент собирает бизнес-результат. Заинтересованная сторона принимает (QG-4).

Человек включается для утверждения, не для печати артефактов, — но включается обязательно, и подпись под обязательством ставит только он.

8. Частые ошибки¶

Ошибка	Почему плохо	Как правильно
Просить агента «просто написать код» по ТЗ	Теряется источник истины — код без требований	Сначала требования, потом реализация из них
Пропустить состязательный обзор	«ADAPT не нужен» становится молчаливым допущением	Обзор обязателен всегда; «находок нет» — это зафиксированный вердикт другой модели
Позволить агенту подписать ADAPT или ACTZ	Агент не владелец и не подписант	Подпись — всегда человек: ADAPT подписывает Архитектор, ACTZ — клиент и исполнитель
Считать находку закрытой без подписанного ACTZ	Интерпретация опирается на решение, которого клиент не принимал	`resolved` только с `decided-in` на пункт подписанного протокола
Отправить клиенту сырой вывод агента как протокол	Клиент подписывает то, чего не понимает	Вопросы агрегирует и переформулирует Архитектор — на языке обязательств
Реконструировать `SR` из готового кода	Инверсия источника истины	Менять требование → затем код; исключение — обоснованный bug-fix
Дать одной модели и генерировать, и проверять	Нет независимости обзора	Критик — на другой модели, чем генератор
Один агент пишет и код, и тест к нему	Тест проверяет код, а не требование	Разные агенты; тест заморожен до реализации и хоть раз был красным
Дать генератору AT «для контекста» посмотреть SR или ADAPT	AT начнёт подтверждать интерпретацию вместо контракта	На вход — только итоговое ТЗ; другая модель; никакого внутреннего контура
Прогонять на испытаниях AT, выведенные полгода назад	Система предъявляется против контракта, которого уже нет	AT перегенерируются перед каждыми испытаниями

← К обзору руководства