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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Организации ОБЯЗАНЫ поддерживать базовые значения стоимости по уровням сложности задач.

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

Организации ОБЯЗАНЫ установить и отслеживать целевой показатель Knowledge Capture Rate.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AI-сгенерированный код ОБЯЗАН проходить верификацию качества перед коммитом. Определены три уровня верификации:

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

Ревью 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 ко всем результатам делегированных агентов.

10.16 Сводка

NOTE: Для начального уровня внедрения см. Основы SENAR, определяющие 8 базовых правил.