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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тесты:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Из шести шагов человек включается на трёх — и только для утверждения, не для печати артефактов.

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

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

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