10. Операционные правила

NOTE: Настоящий раздел определяет каждое правило; какие из них причитаются конфигурации, он не заявляет. Это задаёт Section 11, а для Начальной — 11.1. Прочитанный отдельно, ОБЯЗАТЕЛЬНО каждого подраздела даёт читателю с Начальной пятнадцать обязанностей там, где 11.1 даёт ему правила Основ SENAR плюс шесть здешних: 10.2, 10.4 и 10.9 поимённо; 10.5 через церемонию Quality Sweep; 10.6 через 6.4(e), который излагает три его обязанности без конфигурационного квалификатора; и 10.15 на уровнях L1 и L2, к которым сам 10.15 добавляет L3 для изменений высокого риска и для всего вывода диспетчеризованных агентов — и то и другое вне зависимости от конфигурации. Набор здесь не повторяется: набор, напечатанный дважды, есть набор, способный разойтись сам с собой, и настоящий Стандарт однажды за это уже заплатил (8.6).

10.1 Задача до реализации (ОБЯЗАТЕЛЬНО)

Реализация НЕ ДОЛЖНА начинаться без Задачи. Исследования освобождены; если они порождают код, Задача ОБЯЗАНА быть создана до коммита.

10.2 Длительность сессии (ОБЯЗАТЕЛЬНО)

Организации ОБЯЗАНЫ установить, задокументировать и контролировать максимальную длительность Сессии. Основание, по которому максимум установлен, фиксируется по 9.4(c), где эта обязанность записана один раз для всякого числа, которое настоящий Стандарт оставляет организации. Максимум РЕКОМЕНДУЕТСЯ основывать на эмпирических данных сессий. Ориентир: сессии длиннее 180 минут дают убывающую отдачу в большинстве рабочих процессов с AI.

10.3 Каденция контрольных точек (ОБЯЗАТЕЛЬНО)

Контрольные точки ОБЯЗАНЫ выполняться с интервалами, не превышающими задокументированный организацией лимит. Интервал РЕКОМЕНДУЕТСЯ устанавливать не превышающим допустимый объём потери контекста при внезапном прерывании сессии.

10.4 Документирование тупиковых подходов (ОБЯЗАТЕЛЬНО)

Неудачные подходы ОБЯЗАНЫ фиксироваться как записи знаний типа «Тупиковый подход» (подход, причина, альтернатива). Тупиковым считается исследование, занявшее более 15 минут и не давшее пригодного результата. При достижении этого порога Супервайзер ОБЯЗАН остановиться, зафиксировать подход и причину неудачи и перейти к альтернативному пути.

10.5 Периодический аудит (ОБЯЗАТЕЛЬНО)

Обзоры качества ОБЯЗАНЫ проводиться с каденцией, определённой организацией, и пересматриваться на каждой Ретроспективе инкремента или, там, где эта церемония не проводится — Начальная её опускает (11.1), — на самом Обзоре качества. Каденцию РЕКОМЕНДУЕТСЯ устанавливать не реже одного раза за 3 Инкремента. Для Начальной конфигурации рекомендуемая каденция — ежемесячно (Section 11.1), что покрывает данное требование при Инкрементах длительностью до 2 недель.

10.6 Контроль версий (ОБЯЗАТЕЛЬНО)

a) коммиты ОБЯЗАНЫ быть атомарными; b) обнаружение секретов ОБЯЗАНО быть автоматизировано; c) изменения ОБЯЗАНЫ проверяться на расползание области.

NOTE: пункт (c) не квалифицирует, чем произведено изменение. Квалификация — «изменения AI ОБЯЗАНЫ проверяться» — по умолчанию выводила бы из-под требования изменения иного происхождения, а такого прочтения смешанного процесса настоящий стандарт больше не делает. Расползание области есть свойство изменения, а не его автора.

10.7 Лимит параллельных агентов (ОБЯЗАТЕЛЬНО)

Супервайзеры НЕ ДОЛЖНЫ превышать установленный организацией лимит параллельных агентов. Типичный стартовый лимит — 3 одновременных агента на Супервайзера; организациям РЕКОМЕНДУЕТСЯ калибровать его с учётом сложности задач и ресурсов Супервайзера.

10.8 Калибровка сложность-стоимость (ОБЯЗАТЕЛЬНО)

Организации ОБЯЗАНЫ поддерживать базовые значения стоимости по уровням сложности задач. Основание каждой базовой линии и период, который покрывают её данные, фиксируются по 9.4(c). До 1.5 это было единственное самостоятельно устанавливаемое число раздела без какого-либо заявленного основания, то есть единственное, которое оценщик не мог оспорить.

10.9 Фиксация знаний (ОБЯЗАТЕЛЬНО)

Организации ОБЯЗАНЫ установить и отслеживать целевой показатель Knowledge Capture Rate. Обоснование этой цели документируется по Section 9.2, где даны и ориентиры калибровки; обязанность установлена там и названа здесь потому, что читатель, ставящий цель по настоящему правилу, иначе её не встретит.

10.10 Прослеживаемость требований (ОБЯЗАТЕЛЬНО Командная+)

Организации ОБЯЗАНЫ поддерживать прослеживаемость от Бизнес-требований через Системные требования до Требований к задачам. Каждая Задача ОБЯЗАНА ссылаться хотя бы на одно требование или Историю. Требования ОБЯЗАНЫ храниться в версионируемой, поисковой системе.

10.11 Документация кода как контекст (ОБЯЗАТЕЛЬНО)

Документация кода (docstrings, doc-комментарии, описания API, архитектурная документация) — не артефакт «постфактум», а активный контекст для AI-агентов. Хорошо документированный код снижает объём контекста, который Супервайзер предоставляет на каждую Задачу, и позволяет AI генерировать корректный вывод с меньшим количеством явных инструкций.

Организации ОБЯЗАНЫ поддерживать документацию кода: (a) назначение модуля/пакета, (b) контракты публичного API с типами параметров и возвращаемых значений, (c) архитектурные границы с зависимостями и точками интеграции. Документация ОБЯЗАНА быть машиночитаемой (структурированные комментарии, форматы описания API и т.п.). Документацию РЕКОМЕНДУЕТСЯ обновлять в рамках той же Задачи, которая изменяет код; 8.3 излагает это как критерий уровня РЕКОМЕНДУЕТСЯ для QG-2 («документация обновлена»).

В AI-нативной разработке у документации двойная аудитория: Супервайзеры и AI-агенты. Документация, полезная только людям (например, «уточните у Ивана»), бесполезна для AI. Документация ОБЯЗАНА быть самодостаточной и машиночитаемой.

10.12 Гигиена контекста (ОБЯЗАТЕЛЬНО)

Супервайзеры НЕ ДОЛЖНЫ включать в контекст AI-агента продакшен-учётные данные, API-ключи, персональные данные (PII) или регулируемые данные (финансовые, медицинские) — за исключением случаев, когда у провайдера модели AI есть действующее соглашение об обработке данных и классификация данных это допускает. Организации ОБЯЗАНЫ вести политику классификации контекста, определяющую запрещённые категории данных. Заполнители или синтетические данные РЕКОМЕНДУЕТСЯ использовать, когда помощь AI нужна для задач, связанных с чувствительными доменами.

10.13 Управление моделью AI (ОБЯЗАТЕЛЬНО)

Провайдеры моделей AI — внешние поставщики. Модель AI — основной производственный инструмент, эквивалентный компилятору. Организации ОБЯЗАНЫ:

a) фиксировать идентификатор и версию модели AI, использованной для каждой Сессии; b) рекалибровать базовые значения метрик (FPSR, стоимость на задачу, пропускная способность) при существенном изменении активной версии модели — смена поколения модели является существенным изменением; c) в Командная+: оценивать новые версии модели до внедрения — сравнивать FPSR и стоимость на задачу на репрезентативном наборе задач; d) в Корпоративной: поддерживать формальный процесс утверждения модели — новые модели ОБЯЗАНЫ тестироваться на критерии приёмки для предметной области организации до продуктивного использования; e) документировать известные ограничения модели и паттерны галлюцинаций как записи знаний.

Организациям РЕКОМЕНДУЕТСЯ пересматривать зависящие от возможностей положения настоящего Стандарта и его Гида — те, что опираются на поведение AI: эвристики обнаружения галлюцинаций, рекомендации по длительности сессий, лимиты параллельных агентов — при существенной смене поколений модели и фиксировать итог такого пересмотра. До 1.5 эта обязанность излагалась только примечаниями, здесь и в Разделе 0, а примечание требования не заявляет; положение, написанное под одно поколение моделей и ни разу не перечитанное, в течение года описывает предыдущее.

10.14 Управление изменениями скриптов (ОБЯЗАТЕЛЬНО)

Изменения операционных скриптов ОБЯЗАНЫ рассматриваться как изменения производственного процесса:

• под контролем версий (Section 10.6)
• проверяются перед развёртыванием
• решение фиксируется в базе знаний (применяется Section 10.9)

Конфигурации Командная+ ОБЯЗАНЫ дополнительно:

• тестировать изменения скриптов на изолированном окружении перед распространением
• поддерживать реестр версий активных скриптов по проектам
• обеспечивать возможность отката для любого изменения скрипта

Полное определение Операционных скриптов и их управление см. в Section 5.3.

10.15 Верификация качества AI-вывода (ОБЯЗАТЕЛЬНО)

Код, произведённый для Задачи, ОБЯЗАН проходить верификацию качества перед коммитом — чем бы он ни был произведён. Определены три уровня верификации:

NOTE: Требование не квалифицирует производителя по той же причине, что изложена в 10.6(c) и в 8.1: правило, написанное только про AI-сгенерированный код, оставило бы тот же файл, изменённый тем же образом, непроверенным всякий раз, когда изменение пришло другим путём. Там, где уровень определён через порождающего агента — L3 требует рецензента без доступа к контексту порождающего агента, — требование читается как независимость от того, кто или что произвело код; для кода, написанного Супервайзером напрямую, оно означает, что Супервайзер не является рецензентом.

Требования к Состязательному ревью L3: a) рецензент НЕ ДОЛЖЕН иметь доступа к контексту сессии или ходу рассуждений генерирующего агента и НЕ ДОЛЖЕН быть той стороной, которая направляла рецензируемую работу. Это относится к человеку и к AI-рецензенту равно: Супервайзер, проводивший порождающую сессию, обладает этим контекстом в силу того, что сам его создал, — он удовлетворяет букве требования «рецензент-человек» и уничтожает независимость, ради которой уровень существует; b) хотя бы одному проверяющему РЕКОМЕНДУЕТСЯ быть «холодным» ревьюером — агентом с нулевым предварительным контекстом задачи; c) находки ОБЯЗАНЫ классифицироваться по серьёзности (CRITICAL, HIGH, MEDIUM) и фиксироваться; d) находки CRITICAL ОБЯЗАНЫ блокировать коммит до устранения; e) организации ОБЯЗАНЫ отслеживать Adversarial Detection Rate (ADR) — см. Section 9. f) шкала серьёзности ОБЯЗАНА быть задокументирована: что в контексте организации покрывают CRITICAL, HIGH и MEDIUM и кто их присваивает. Присвоение CRITICAL ОБЯЗАНО фиксироваться вместе с его основанием. Настоящая шкала есть та же шкала серьёзности, по которой (c) требует классифицировать находки. Эта классификация не ярлык: по (d) она блокирует коммит, а по 9.2 она есть числитель Adversarial Detection Rate, — и незадокументированная шкала делает неразрешимыми оба. Там, где классификацию предлагает AI-рецензент, за неё отвечает Супервайзер, принявший находку, — а для находки ревью L3 таким Супервайзером является тот, кого допускает (a), а не сторона, направлявшая проверяемую работу. Серьёзность классифицирует НАХОДКУ. Это не уровень риска изменения (8.7), который выбирает глубину ревью, и не уровень чеклиста Основ SENAR, который выбирает, сколько пунктов чеклиста пройдено. Шкалы делят слова — High есть во всех трёх, Critical в двух из них и отсутствует среди уровней риска 8.7, — поэтому организация, документирующая шкалу по настоящей клаузе, указывает, какую из трёх она задаёт.

Ревью L3 ОБЯЗАНО применяться на основе уровня риска (см. Section 8.7):

• Высокий риск (безопасность, аутентификация, платежи, миграция данных, архитектура): для изменений высокого риска (Section 8.7) ревью L3 ОБЯЗАНО применяться вне зависимости от уровня конфигурации; хотя бы один проверяющий ОБЯЗАН быть Супервайзером-человеком, а не AI-агентом; ОБЯЗАНА выполняться проверка безопасности (см. Section 8.7);
• Стандартный риск (функциональность, UI, бизнес-логика): L3 ОБЯЗАНО применяться (Командная+);
• Низкий риск (документация, конфигурация, тривиальные исправления): L3 МОЖЕТ быть пропущено с задокументированным обоснованием.

NOTE: Заявление L2 покрывает дефекты качества (логические ошибки, нарушения стиля, покрытие критериев приёмки), но не является контролем безопасности — для этого минимальный эффективный уровень верификации — L3. Заявление L2 — структурированная запись о том, что было проверено; это не ревью независимой стороной. Исполнитель (человек или агент) фиксирует, какие критерии приёмки верифицированы и каким способом.

NOTE: Скрытые дефекты в AI-сгенерированном коде особенно трудно обнаружить — они проходят автоматические проверки, но содержат тонкие логические, архитектурные или проблемы безопасности. Типичные паттерны: возврат True без валидации, обход через сравнение с null, доверие HTTP-заголовкам без проверки, пустые конфигурационные значения, молча отключающие защиту, и недостижимый «защитный» код, маскирующий неполное понимание потока управления.

Диспетчеризация агентов (делегирование подагенту) — сценарий с наивысшим риском скрытых дефектов: делегированный агент работает с ограниченным контекстом. Организации, использующие диспетчеризацию, ОБЯЗАНЫ применять ревью L3 ко всем результатам делегированных агентов.

Против этого требования определена ровно одна замена — в 5.7(3), — и её границы в обоих местах одни и те же: она доступна только на Начальной конфигурации; она применима только там, где независимый доступ к агенту недоступен; она не достаёт до изменений высокого риска (8.7), для которых по правилу уровней риска выше применение L3 ОБЯЗАТЕЛЬНО вне зависимости от конфигурации; и организация фиксирует замену вместе с основанием для неё. За этими границами требование безусловно на всех конфигурациях настоящего Стандарта. Граница существенна потому, что заменитель — не более слабое ревью, а акт другого рода: L2 пишет та сторона, которая выполнила работу (таблица выше и следующее за ней примечание), поэтому там, где он встаёт вместо L3, независимость, ради которой L3 существует, не уменьшается — её нет.

10.16 Сводка

NOTE: Таблица перечисляет Командную и Корпоративную, потому что эти конфигурации несут все пятнадцать. Что несёт Начальная, сказано в 11.1 и здесь не повторяется — по причине, изложенной в начале настоящего раздела. Для начального уровня внедрения см. Основы SENAR, определяющие 8 базовых правил.