3. Термины и определения

Полный глоссарий см. в Справочнике SENAR.

Нотация конфигураций: Когда нормативные требования различаются в зависимости от конфигурации, в стандарте используется нотация [Team+: ОБЯЗАТЕЛЬНО]. «Team+» означает Командную и всякую конфигурацию выше неё. Там, где требование входит в набор Начальной, нотация указывает, что оно РЕКОМЕНДУЕТСЯ на Начальной и ОБЯЗАТЕЛЬНО на Командной и Корпоративной. Определения конфигураций см. в Section 11. Для начального уровня внедрения см. Основы SENAR.

Входит ли требование в набор Начальной, решает Section 11, а не настоящая нотация. Требование, которого §11.1 не содержит, — QG-1 и QG-3, Правило 10.10, Синхронизация федерации, выделенные носители ролей — на Начальной не причитается ни на каком уровне: оно там отсутствует, а не присутствует как РЕКОМЕНДУЕТСЯ, и 13.1(c) не требует документировать его как неисполненное РЕКОМЕНДУЕТСЯ. Нотация задаёт уровень применимого требования; набор применимых требований она не расширяет.

3.1 AI-агент

Программная система на основе большой языковой модели, генерирующая инженерные артефакты под управлением человека. AI-агент поставляется Провайдером модели AI (3.25) и работает на конкретной версии модели.

AI-агенты — не стабильные детерминированные инструменты. Версии моделей различаются по возможностям, профилям галлюцинаций и качеству следования инструкциям. Смена версии модели рассматривается как изменение конфигурации (нормативные требования см. в Section 10.13).

3.2 Супервайзер

Инженер-человек, который направляет AI-агентов, верифицирует результаты, принимает архитектурные решения и обеспечивает соблюдение шлюзов качества. Производство артефактов является AI-направляемым; прямое изменение артефакта Супервайзером — это зафиксированный Обход шлюза, а не молчаливая практика (Section 4.1, Section 8.6).

3.3 Пара Супервайзер+AI

Фундаментальная производственная единица: один Супервайзер, работающий с одним или несколькими AI-агентами.

3.4 Контекст

Информация, предоставляемая AI-агенту для получения корректного результата: цель, критерии приёмки, ограничения, знания и связи прослеживаемости.

3.5 Задача

Атомарная единица отслеживаемой работы. Содержит цель, критерии приёмки и связь с требованием.

3.5.1 Область Задачи

Множество инженерных артефактов (3.5.2), которые Задаче разрешено изменять. Область ОБЯЗАНА фиксироваться до начала работы и НЕ ДОЛЖНА сужаться после изменения ради того, чтобы вывести это изменение за её пределы. Там, где область не зафиксирована, областью Задачи является всякий артефакт, который Задача фактически изменила: Задача без зафиксированной области не получает тем самым область малую. Фиксация исполняется как обязательный атрибут Задачи (6.2) и как критерий QG-0 (8.1); настоящий подраздел закрепляет, что именно фиксируется и как читается термин, когда фиксации нет.

3.5.2 Инженерный артефакт

Всякий файл, содержимое которого определяет, что система делает или как она собирается, верифицируется, разворачивается или эксплуатируется. Сюда входят исходный код, тесты, манифесты зависимостей, описания сборки и конвейеров, инфраструктурные и деплойные дескрипторы, миграции баз данных, конфигурация, влияющая на поведение во время выполнения, Операционные скрипты и файлы инструкций агента (Section 5.3), а также документация, служащая контекстом AI-агенту (3.23).

Организация НЕ ДОЛЖНА сужать этот термин перечислением ради того, чтобы вывести класс файлов за пределы объявленного шлюзом эффекта. Там, где неясно, является ли файл инженерным артефактом, проверка такова: способно ли изменение в нём изменить то, что система делает, то, как она проверяется, или то, как ведёт себя агент. Если способно — является.

NOTE: Термин входит в эффект, объявленный QG-0 (8.1), и тем самым задаёт охват этого шлюза. Он определён здесь потому, что объявленный эффект, сформулированный в неопределённых терминах, настраивается той стороной, которую он обязывает, — а 8.6(a) требует, чтобы объявление позволяло для любого предлагаемого действия установить, предотвращает ли его шлюз.

3.6 Исследование

Изучение вопроса без полной формальности Задачи. Исследованиям РЕКОМЕНДУЕТСЯ быть ограниченными по времени (Section 6.1). Если исследование приводит к реализации, создаётся Задача.

3.7 Сессия

Ограниченный по времени период супервизируемой работы с AI, с определёнными началом и окончанием.

3.8 Инкремент

Пакет работ с определённой областью, целями и запланированным бюджетом.

3.9 Шлюз качества

Точка контроля, предотвращающая наступление объявленного эффекта, пока её вердикт не положителен. Критерии специфичны для каждого шлюза (Section 8.1–8.5); свойства, которыми проверка ОБЯЗАНА обладать, чтобы вообще быть Шлюзом качества, нормированы в Section 8.6, и выполнения критериев без них недостаточно. Шлюзы ОБЯЗАНЫ быть автоматизированы везде, где это осуществимо (8.6(f)); автоматизация есть требование к их работе, а не часть настоящего определения — критерии, требующие человеческого суждения, предусмотрены в 8.6(f) и присутствуют в QG-2 и QG-4.

3.10 Запись знаний

Задокументированное решение, паттерн, известная проблема или тупиковый подход, хранящиеся в поисковой базе знаний.

3.11 Тупиковый подход

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

3.12 Контрольная точка

Сохранение контекста в ходе Сессии для предотвращения потери работы.

3.13 Обход шлюза

Задокументированное исключение, позволяющее провести работу через Шлюз качества. Требует обоснования, признания рисков, плана устранения и одобрения ролью, старшей по отношению к инициатору (8.6(h)). Допуск объявленного шлюзом эффекта без положительного вердикта является обходом независимо от намерения и фиксируется как обход (8.6(h), 8.6(j)): именно запись делает его тем задокументированным исключением, которое называет настоящий термин, а не условием, выполненным заранее.

3.14 Федерация

Механизм координации нескольких пар Супервайзер+AI в рамках одного или нескольких проектов: отслеживание зависимостей, общие знания, межпроектные оповещения. Требования к федерации при управлении несколькими проектами см. в Section 5.8.

3.15 Время цикла

Время от начала Задачи до её завершения (started_at → completed_at). Отличается от Lead Time тем, что не включает время ожидания в очереди (сравните с Lead Time: created_at → completed_at).

3.16 История

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

3.17 Требование

Задокументированное, верифицируемое утверждение о потребности, возможности или ограничении системы. SENAR определяет три уровня требований: Бизнес-требование (3.18), Системное требование (3.19) и Требование к задаче (3.20). Цель Задачи и критерии приёмки образуют требования на уровне ТЗ.

3.18 Бизнес-требование (БТ)

Потребность заинтересованных сторон, выраженная в бизнес-терминах. Источник всех нижестоящих требований. Обычно соответствует цели Инкремента или Эпика.

3.19 Системное требование (СТ)

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

3.20 Требование к задаче (ТЗ)

Требование на уровне реализации, декомпозированное из Бизнес- или Системного требования. Соответствует цели и критериям приёмки Задачи. Самый низкий уровень формального управления требованиями; тест-кейсы — артефакты верификации, производные от ТЗ, а не отдельный уровень требований.

3.21 Иерархия требований

Цепочка декомпозиции от бизнес-потребности к единице реализации: БТ → СТ → ТЗ. Не для каждой работы нужны все уровни; глубину определяет Контекстный архитектор исходя из сложности и регуляторного контекста (см. Section 8.2).

3.22 Тестовая модель (ТМ)

Артефакт верификации, производный от Требований к задаче. Определяет способ проверки каждого ТЗ: тест-кейсы, тестовые данные, ожидаемые результаты и метод верификации (автоматический тест, ручная демонстрация, измерение). Тестовая модель — не уровень требований, а мост между требованиями и верификацией. В AI-нативной разработке AI обычно генерирует тесты из ТЗ; Супервайзер проверяет, что сгенерированные тесты действительно покрывают заявленные критерии приёмки.

Уровень формализации Тестовой модели зависит от конфигурации — см. Section 11 и QG-2 (Section 8.3) для нормативных требований.

3.23 Документация кода

Документация уровня модулей, API и архитектуры, служащая постоянным контекстом для AI-агентов. В AI-нативной разработке документация кода имеет двойную аудиторию: Супервайзеров-людей и AI-агентов. Самодостаточная, машиночитаемая документация снижает затраты на контекст для каждой Задачи и повышает качество вывода AI.

3.24 Прослеживаемость

Возможность проследить каждый инженерный артефакт до породившего его требования через цепочку связанных ссылок. Двунаправленная: каждое ТЗ прослеживается вверх до БТ; каждое БТ декомпозируется хотя бы в одно ТЗ. Полная цепочка прослеживаемости: БТ → СТ → ТЗ → ТМ → Код.

3.25 Провайдер модели AI

Внешний сервис, предоставляющий возможности инференса AI-моделей (облачные API, локальные серверы моделей). Провайдеры моделей AI — де-факто поставщики: модель AI является основным производственным инструментом, эквивалентным компилятору. Возможности, ограничения и ценообразование модели меняются по решению провайдера, вне контроля организации.

3.26 Версия модели AI

Конкретный релиз модели AI, идентифицируемый обозначением провайдера. Смена версии может повлиять на качество вывода, стоимость и поведение модели. Версии различаются по возможностям, профилям галлюцинаций, стоимости и качеству следования инструкциям. Базовые значения метрик (FPSR, стоимость/задача) зависят от версии — требования к рекалибровке см. в Section 10.13.

3.27 Расползание области

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

3.28 Галлюцинация (AI)

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

3.29 WSJF (Weighted Shortest Job First)

Метод приоритизации: отношение Стоимости задержки к Размеру работы. Применяется при Планировании инкремента (Section 7.1) для упорядочивания пула задач. Заимствован из SAFe без изменений.

3.30 Поток создания ценности

Сквозной поток от запроса заинтересованной стороны до поставленного, верифицированного программного обеспечения. В Корпоративной конфигурации (Enterprise) Инкременты группируются по потокам создания ценности с едиными бюджетами (Section 11.3).

3.31 Состязательное ревью

Независимая проверка результатов AI агентом, не имеющим доступа к контексту сессии или ходу рассуждений генерирующего агента. См. Section 10.15, L3.

3.32 Диспетчеризация агента

Делегирование Задачи или подзадачи отдельному экземпляру AI-агента, обычно работающему в изолированной среде. См. Section 5.7.

3.33 Профиль агента

Именованный набор скриптов, разрешений и контекста, определяющий возможности и границы AI-агента для конкретной функции. См. Section 5.2.

3.34 Структурированный протокол инструментов

Протокол структурированного взаимодействия AI-агентов с сервисами платформы: самоописывающиеся схемы инструментов, атомарные операции и журналирование аудита. См. Section 5.6.

NOTE: Примеры подходящих протоколов: Model Context Protocol (MCP), вызов функций OpenAI, пользовательские API.

3.35 Операционный скрипт

Структурированная инструкция на естественном языке: как AI-агент выполняет конкретное действие. Содержит триггер, предусловия, алгоритм, постусловия и выходные данные. См. Section 5.3.

3.36 Adversarial Detection Rate (ADR)

Число критических находок состязательного ревью на одну задачу, прошедшую ревью L3. Формула: adversarial_critical_findings / L3_reviewed_tasks. См. Section 9.2.

3.37 Стандарты кода

Документ с обязательными правилами качества кода, загружаемый в контекст AI-агента. Охватывает безопасность, архитектуру, базы данных, API, конкурентность и паттерны тестирования. См. Section 10.15, L2.

3.38 Скрытый дефект

AI-сгенерированный код, который выглядит корректным — проходит автоматические проверки, валидацию типов и самопроверку — но содержит скрытые дефекты (обход защиты, логические ошибки, архитектурные нарушения), обнаруживаемые только при независимом состязательном ревью. Скрытые дефекты возникают, когда AI генерирует код по паттернам, а не на основе семантического понимания. См. Section 10.15.

3.39 FPSR (First-Pass Success Rate)

Процент Задач, прошедших верификацию с первой попытки — без возврата на доработку. Определение и требования к измерению см. в Section 9.1.

3.40 Обзор качества

Периодический аудит кодовой базы и базы знаний: метрики, открытые дефекты, покрытие базы знаний, архитектурная согласованность, полнота прослеживаемости, — проводимый с каденцией, которую документирует организация. К концу Инкремента он не привязан: 7.4 задаёт его частоту как определяемую организацией, а 8.6(g) читает этот интервал как пол хранения записей шлюзов там, где Ретроспектива инкремента не проводится (13.6). Нормативные требования см. в Section 7.4.

3.41 Менеджер потока

Роль Супервайзера: межкомандная координация, отслеживание зависимостей и эффективность потока в рамках Федерации. Определение и обязанности см. в Section 4.4.

3.42 Контекстный архитектор

Роль Супервайзера: проектирование и поддержание архитектуры знаний, стратегий загрузки контекста и стандартов документации для эффективной AI-направляемой работы. Определение и обязанности см. в Section 4.2.

3.43 Инженер знаний

Роль Супервайзера: фиксация, структурирование и поддержание Записей знаний, тупиковых подходов и повторно используемых паттернов организации. Определение и обязанности см. в Section 4.3.

3.44 Инженер верификации

Роль Супервайзера: проектирование Тестовой модели, проведение состязательных ревью, контроль соблюдения Шлюзов качества. Определение и обязанности см. в Section 4.5.