8. Шлюзы качества

Автоматизированные точки контроля. Реализуются как код, а не чеклисты. Чеклист проверки AI-вывода см. в Гиде SENAR.

8.1 QG-0: Контекстный шлюз (начало Задачи)

Качество закладывается на входе. QG-0 гарантирует, что у Задачи есть достаточный и хорошо структурированный контекст до начала работы над ней.

Предотвращаемый эффект (8.6(a)): изменение инженерных артефактов в области Задачи, чем бы это изменение ни было произведено.

NOTE: Эффект сформулирован без квалификации того, что производит изменение. Шлюз, определённый только против AI-направляемой работы, оставлял бы тот же артефакт, изменённый тем же образом, вне собственного объявления всякий раз, когда изменение пришло другим путём, — а 8.6(a) требует, чтобы для любого предлагаемого действия можно было установить, предотвращает ли его шлюз. Область ограничена Задачей: изменения вне области Задачи предметом этого шлюза не являются.

Точка допуска (8.6(a)): открытие Задачи для изменений — переход, с которого работа в области Задачи может начаться. Эффект допускается один раз на Задачу. Изменение, произведённое под этим вердиктом и в пределах области, для которой вердикт вынесен, входит в уже зафиксированный допуск: отдельным допуском оно не является и не требует ни отдельного вердикта, ни отдельной записи, ни отдельного сличения дайджеста. Там, где область Задачи изменена после вердикта, вердикт стоит для состояния, которое более не имеет места, и 8.6(c) требует нового вердикта прежде, чем работа продолжится в изменённой области.

Вердикт QG-0 вынесен о записи Задачи, которую шлюз исследовал, — о цели, критериях приёмки, связи с требованием, типе работы и зафиксированной области (3.5.1), — и не о содержимом ни одного инженерного артефакта. Дайджест, требуемый в 8.6(d), измеряется по этой записи. QG-0 допускает изменение артефактов; он их не исследует.

Критерии ОБЯЗАТЕЛЬНЫ: цель определена, критерии приёмки верифицируемы, связь с требованием или историей установлена (ОБЯЗАТЕЛЬНО), тип работы назначен, Область Задачи зафиксирована (3.5.1) — артефакты, которые Задаче разрешено изменять, зафиксированы до начала работы.

Критерии ОБЯЗАТЕЛЬНЫ (Командная+): критерии приёмки являются независимо верифицируемыми (каждый может быть протестирован или измерен отдельно); в критерии приёмки включён хотя бы один негативный сценарий (ошибочный случай, некорректный ввод или граничное условие).

Критерии ОБЯЗАТЕЛЬНЫ (все конфигурации, задачи безопасности): задачи, затрагивающие аутентификацию, пользовательский ввод, хранение данных, платежи или внешние API, ОБЯЗАНЫ декларировать поверхность угроз и включать хотя бы один критерий приёмки по безопасности. См. Основы SENAR (Стартовый шлюз, критерий 5) и Section 8.7.

РЕКОМЕНДУЕТСЯ: план, оценка сложности, выявленные релевантные знания.

NOTE: Область Задачи является критерием ОБЯЗАТЕЛЬНО на всех конфигурациях, она перечислена выше, и Базовая требует её тоже (Стартовый шлюз, пункт 4). Начальная сверх того наследует требование негативного сценария из Базовой (Стартовый шлюз, пункт 3), хотя выше оно перечислено как критерий ОБЯЗАТЕЛЬНО уровня «Командная+». На Начальном уровне QG-0 = проверки Стартового шлюза Базовой + структура QG-0 Стандарта. Критерии «Командная+» (независимо верифицируемые КП, негативный сценарий) уже практикуются на Базовом уровне; Начальная формализует их как критерии шлюза.

8.2 QG-1: Шлюз требований (уровень Истории/Инкремента)

Гарантирует, что требования определены, утверждены, декомпозированы и обладают достаточным качеством до начала реализации.

Предотвращаемый эффект (8.6(a)): создание Задач реализации из требований, которые не утверждены, не декомпозированы на достаточную глубину или не верифицируемы.

Критерии ОБЯЗАТЕЛЬНЫ [Командная+]: Бизнес-требование (БТ) существует и утверждено; декомпозиция до Требований к задаче (ТЗ) выполнена на нужную глубину; все ТЗ имеют верифицируемые критерии приёмки; нет осиротевших требований (без Задач реализации).

Критерии РЕКОМЕНДУЕТСЯ (Командная+: ОБЯЗАТЕЛЬНО): требования удовлетворяют согласованности (нет противоречий между ТЗ в рамках Истории); требования удовлетворяют достаточности (покрыты нормальные, граничные и ошибочные сценарии); нефункциональные требования специфицированы, где применимо (производительность, безопасность, доступность).

Глубина декомпозиции

Контекстный архитектор ОБЯЗАН определять глубину декомпозиции [Командная+] с учётом сложности и регуляторного контекста:

NOTE: Для простых функций (БТ → ТЗ, 2 уровня) см. Основы SENAR.

Свойства качества требований

Требования, подаваемые на QG-1, ОБЯЗАНЫ быть верифицируемыми (каждое можно протестировать, измерить или продемонстрировать). Требованиям РЕКОМЕНДУЕТСЯ (Командная+: ОБЯЗАТЕЛЬНО) удовлетворять:

a) Согласованность — отсутствие противоречий с существующими требованиями того же или более высокого уровня; b) Достаточность — набор ТЗ полностью покрывает родительское требование (СТ или БТ); c) Неизбыточность — отсутствие дублирующих требований между Историями; d) Прослеживаемость — каждое ТЗ прослеживается вверх до БТ; каждое БТ декомпозируется хотя бы в одно ТЗ.

Управление изменениями требований

NOTE: Управление изменениями требований применяется в конфигурации Командная+.

Когда утверждённое БТ или СТ изменяется после начала реализации:

a) изменение ОБЯЗАНО быть задокументировано с обоснованием и указанием лица, утвердившего его; b) анализ воздействия ОБЯЗАН выявить все нижестоящие требования и Задачи, затронутые изменением; c) затронутые Задачи, уже находящиеся в состоянии done, ОБЯЗАНЫ быть помечены для повторной верификации — их одобрение QG-2 аннулируется; d) изменённое требование ОБЯЗАНО повторно пройти QG-1 до начала новой реализации; e) Супервайзеры затронутых Задач ОБЯЗАНЫ быть уведомлены об изменении.

Масштабирование: на Командном уровне анализ воздействия ОБЯЗАН поддерживаться инструментарием (связи «родитель/потомок» требований). На Корпоративном уровне изменения требований ОБЯЗАНЫ быть под контролем версий и подчиняться ревью изменений (см. Section 11.3, Требования-как-код).

8.3 QG-2: Шлюз реализации (Задача завершена)

Предотвращаемый эффект (8.6(a)): закрытие Задачи и распространение её результата — момент, начиная с которого результат становится доступен другой работе как завершённый.

Критерии ОБЯЗАТЕЛЬНЫ: CI проходит, тесты проходят, статический анализ проходит (включая проверку типов, где применимо), нет новых нарушений линтера, критерии приёмки верифицированы Супервайзером, уязвимости безопасности не обнаружены инструментами сканирования.

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

Свидетельство и состояние, о котором оно

Вердикт ОБЯЗАН быть высказыванием об артефактах Задачи в том виде, в каком они находятся в момент перехода Задачи в состояние done (8.6(c)), и ОБЯЗАН опираться на дайджест, измеренный по этим артефактам (8.6(d)). Вердикт, заработанный на одном состоянии, не является вердиктом о более позднем: если артефакты изменились после прогона проверок, проверки либо зарабатываются заново против изменённого состояния, либо вердикт отрицателен.

Что свидетельство доказывает и чего не доказывает

Привязанное свидетельство доказывает две вещи, и организации НЕ ДОЛЖНЫ предъявлять пройденный QG-2 как доказательство большего:

a) что названный набор проверок отработал против этого состояния; b) что вердикт не перенесён с другого состояния.

Оно не доказывает добросовестности стороны, уполномоченной фиксировать одобрение. Участник, обладающий таким полномочием и намеренный ввести в заблуждение, может подобрать проверки, которые пройдут, либо зафиксировать одобрение работы, которую не рассматривал, — и привязка при этом останется целой: свидетельство будет соответствовать состоянию ровно так, как требуется, и всё равно будет ничего не стоить. Привязка есть контроль против расхождения свидетельства с тем, что оно описывает: подмена, устаревание, повторное предъявление. Аттестацией против целеустремлённого участника изнутри она не является.

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

РЕКОМЕНДУЕТСЯ (Командная+: ОБЯЗАТЕЛЬНО): манифесты зависимостей, изменённые AI (package.json, requirements.txt, go.mod, Cargo.toml и т.п.), проверяются на галлюцинированные пакеты — несуществующие в официальном реестре или ведущие к неожиданному мейнтейнеру, с опечатками в именах (близкие по написанию к легитимным) и путаницу зависимостей (коллизии внутренних и публичных пространств имён).

8.4 QG-3: Шлюз верификации (слияние — конфигурации Командная+)

Предотвращаемый эффект (8.6(a)): включение изменения в общую линию разработки.

Критерии ОБЯЗАТЕЛЬНЫ: приёмочные тесты проходят, сканирование безопасности чистое, регрессий нет, код проверен (по уровню риска — см. 8.7).

РЕКОМЕНДУЕТСЯ: производительность в рамках SLA, соответствие требованиям доступности, межсервисная интеграция верифицирована.

Минимальные критерии проверки AI-вывода

На QG-3 ОБЯЗАНЫ выполняться следующие AI-специфичные проверки:

a) сгенерированный код не вызывает несуществующие API, методы или флаги CLI (проверка на галлюцинации); b) все импортируемые пакеты существуют в манифесте зависимостей проекта (валидация зависимостей); c) сгенерированный код следует архитектурным паттернам и конвенциям проекта (соответствие паттернам); d) сгенерированные тесты покрывают заявленные критерии приёмки, а не просто достигают покрытия (валидность тестов); e) в сгенерированном коде отсутствуют захардкоженные учётные данные, API-ключи или секреты (проверка секретов).

Эти критерии заменяют зависимость от информационного Чеклиста проверки AI-вывода в Гиде SENAR нормативными минимальными требованиями.

8.5 QG-4: Шлюз приёмки (релиз)

Предотвращаемый эффект (8.6(a)): выпуск — поставка инкремента его пользователям.

Критерии ОБЯЗАТЕЛЬНЫ: проведён Обзор поставки ИЛИ зафиксировано одобрение заинтересованной стороны; QG-3 по-прежнему проходит; стейджинг-окружение (среда, эквивалентная продакшену) верифицировано; приёмка заинтересованной стороной зафиксирована.

8.6 Свойства шлюза

Section 8.1–8.5 говорят, что каждый шлюз проверяет. Настоящий раздел говорит, чем проверка ОБЯЗАНА быть, чтобы считаться Шлюзом качества.

Одни лишь критерии не определяют, где проверка действует, о чём именно высказывается её вердикт и что происходит, когда вердикт не может быть получен. Две реализации могут удовлетворять каждому критерию из Section 8.1–8.5 и при этом предотвращать разное — или не предотвращать ничего. Критерии говорят, что именно рассматривает конкретный шлюз; свойства ниже говорят, чем обязан быть любой шлюз.

Проверка, которая удовлетворяет критериям шлюза из Section 8.1–8.5, но не обладает свойством, обязательным на применимой конфигурации (см. «Шкала по конфигурациям» ниже), не является Шлюзом качества в смысле настоящего стандарта и НЕ ДОЛЖНА фиксироваться как шлюз.

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

a) Объявленный предотвращаемый эффект. Шлюз ОБЯЗАН объявлять эффект, который он предотвращает: конкретное изменение системы или записи о работе, которое не происходит, пока вердикт шлюза отрицателен. Объявление ОБЯЗАНО быть настолько конкретным, чтобы для любого предлагаемого действия можно было установить, относится ли оно к тем, которые шлюз предотвращает. «Обеспечивает качество» и «проверяет работу» объявленными эффектами не являются: ни одно предлагаемое действие невозможно к ним приложить.

Объявление фиксирует точку допуска: точку, в которой шлюз перестаёт предотвращать объявленный эффект. Там, где эффект есть единичный акт, точкой допуска является этот акт, и отдельного указания не требуется. Там, где эффект есть класс актов, повторяющийся внутри одной единицы работы, объявление ОБЯЗАНО дополнительно называть точку, в которой этот класс открывается, — иначе каждый акт класса оказывается отдельным допуском. Свойства (c), (d) и (g) относятся к точке допуска в том виде, в каком она зафиксирована. QG-0 — единственный шлюз настоящего Стандарта, чей объявленный эффект относится ко второму роду; его точка допуска названа в 8.1.

b) Превентивное размещение. Шлюз ОБЯЗАН действовать до эффекта, объявленного в (a), — он ОБЯЗАН быть превентивным контролем, а не детективным. Проверка, устанавливающая то же условие после того, как эффект уже произошёл, является детективным контролем. Детективный контроль этому свойству не удовлетворяет, и его наличие не снижает требования к превентивному; он МОЖЕТ выполняться дополнительно, а там, где превентивный контроль зависит от компонента, способного отказать без сигнала, дополнительный детективный контроль РЕКОМЕНДУЕТСЯ.

NOTE: «Превентивный» и «детективный» употреблены здесь в их установившемся значении из практики внутреннего контроля. Превентивный контроль устраняет возможность наступления нежелательного эффекта; детективный контроль устанавливает постфактум, что эффект наступил. Различие — в положении относительно эффекта, а не в строгости: детективный контроль может проверять больше и при этом не предотвращать ничего.

c) Соответствие вердикта состоянию. Вердикт ОБЯЗАН быть высказыванием о том состоянии, которое шлюз исследовал, в том виде, в каком это состояние находится в точке допуска. Там, где шлюз исследует артефакты, на которые действует объявленный эффект, это состояние тех артефактов; там, где он исследует входные данные, существующие до эффекта, это состояние исследованных записей — для QG-0 они названы в 8.1. Вердикт, вынесенный для одного состояния, НЕ ДОЛЖЕН применяться к другому состоянию.

Это свойство вердикта, а не способа его получения. Оно удовлетворено, когда свидетельство предъявляется вместе с предлагаемым действием, и равным образом удовлетворено, когда шлюз сам выводит вердикт из допускаемого состояния. Оно не удовлетворено, когда шлюз принимает свидетельство, которое он не может соотнести с этим состоянием, — как бы свидетельство ни было доставлено и насколько бы тщательной ни была породившая его проверка.

d) Привязка к измеренному дайджесту. Соответствие, требуемое в (c), ОБЯЗАНО опираться на дайджест, измеренный по тем артефактам, о которых вынесен вердикт. Зафиксированный идентификатор состояния — идентификатор ревизии, тег версии, номер сборки — является привязкой только тогда, когда сторона, полагающаяся на него, сама измерила дайджест названных артефактов и сравнила его с зафиксированным значением; идентификатор, обязательный к фиксации, но никогда не сверяемый с тем, что он называет, привязкой не является, и шлюз, выдающий его за привязку, стандарту не соответствует. Требование предъявляется к измерению, а не к наличию поля.

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

Сказанное относится к случаю, когда вердикт вынесен о состоянии тех артефактов, на которые действует эффект. Там, где вердикт шлюза вынесен вместо этого о входных данных, существующих до эффекта, и не о содержимом ни одного артефакта, до которого эффект дотянется, артефактами, о которых вынесен вердикт, являются записи, исследованные шлюзом, и дайджест измеряется по ним. QG-0 — именно этот случай, и запись названа в 8.1.

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

e) Отказ в запрещающее состояние (fail-closed). Там, где шлюз не может получить вердикт — проверка не запускается, не завершается или завершается без определённого результата, — вердикт ОБЯЗАН быть отрицательным, а объявленный эффект ОБЯЗАН быть предотвращён. Отсутствие отрицательной находки НЕ ДОЛЖНО трактоваться как положительный вердикт. Это относится к недоступности самого шлюза и к недоступности всего, от чего шлюз зависит.

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

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

Шкала по конфигурациям

Пять свойств различаются тем, во что обходится их реализация, и уровень обязательности следует этой цене и ничему другому. Сохранение соответствия какой-либо существующей реализации основанием для установления уровня не является.

NOTE: Нормативные столбцы — Начальная, Командная и Корпоративная: три конфигурации, которые определяет настоящий Стандарт (Section 11). Столбец «Базовая» информативен и сохранён потому, что довод о стоимости ниже читается только на фоне наименьшего масштаба; как его читать, сказано в 13.3, и сказано один раз.

Основание каждого уровня:

• (a), (c), (e) — ОБЯЗАТЕЛЬНО на всех конфигурациях. Они стоят политики, а не способности. Объявить, что шлюз предотвращает; отказаться применять вердикт к состоянию, для которого он не выносился; считать неполученный вердикт отрицательным — это решения. Они исполнимы в одном лишь текстовом редакторе, который предполагает Базовая: Section 11.4 указывает инструментарий как отсутствующий там. Именно поэтому Основы SENAR говорят те же три свойства своими словами, и поэтому организацию, которая их не приняла, остановила не цена.
• (d) — РЕКОМЕНДУЕТСЯ на Базовой, ОБЯЗАТЕЛЬНО с Начальной. Измерение дайджеста стоит одной команды плюс дисциплины записать результат рядом с вердиктом. Это небольшая способность, но не бесплатная. Section 11.4 указывает инструментарий как рекомендуемый с Начальной.
• (b) — РЕКОМЕНДУЕТСЯ на Базовой и Начальной, ОБЯЗАТЕЛЬНО с Командной. Действовать до эффекта требует способности вклиниться в него. Это способность, а не решение. Section 11.4 указывает инструментарий как требуемый только с Командной.

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

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

Применение

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

Допуск объявленного эффекта ОБЯЗАН равным образом порождать запись, называющую вердикт, на который он опирается, и время. Такая запись порождается один раз на допуск в том виде, в каком шлюз зафиксировал его в (a), — для QG-0 один раз на Задачу (8.1), а не один раз на изменение. Без неё (b) и (c) не может оценить никто, кроме стороны, которая их утверждает: вердикт и эффект, никогда не зафиксированные в отношении друг к другу, не устанавливают ни порядка, ни соответствия, — а 13.7 спрашивает именно об этом отношении.

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

j) изменение артефакта в области Задачи путём, которому шлюз не предшествует, — включая прямое изменение Супервайзером — является допуском эффекта, объявленного QG-0 (8.1), без положительного вердикта и потому является Обходом шлюза по (h). Оно ОБЯЗАНО фиксироваться как Обход. Эта обязанность опирается на (a) и (h) и действует на всех конфигурациях настоящего Стандарта, включая Начальную, где (b) всего лишь РЕКОМЕНДУЕТСЯ: шлюз, не размещённый превентивно, всё равно объявляет эффект, а допуск этого эффекта без вердикта всё равно остаётся допуском.

Маршрутом является происхождение содержимого, а не то, какой процесс записал файл. Содержимое, составленное человеком и перенесённое агентом, — продиктованное, вставленное в промпт для дословной записи или иначе переданное для воспроизведения, — пришло путём, которому шлюз не предшествует, и (j) к нему относится. Шлюз, поставленный перед работой агента, не рассматривает текст, который агенту велели воспроизвести.

Маршрут — не размещение. Шлюз, детективный по отношению к своему эффекту (на Начальной (b) всего лишь РЕКОМЕНДУЕТСЯ, и такой шлюз там законен), всё равно распоряжается маршрутами, которыми работа доходит до его артефактов, и его детективность не превращает каждое изменение в допуск без вердикта. Там, где QG-0 вынес положительный вердикт о Задаче, а изменение возникло из работы, выполненной в рамках этой Задачи и в пределах области, для которой вердикт вынесен, изменение входит в допуск, открытый этим вердиктом. Настоящий пункт схватывает содержимое, дошедшее до артефакта маршрутом, которого не покрыл ни один вердикт, — а не работу, шлюз которой оказался после эффекта, а не до него.

Там, где Исследование (3.6) дало артефакты, которые оставляют себе, Задача, созданная по 10.1, не вводит их производство в свой шлюз задним числом: изменение произошло до того, как Задача возникла, и QG-0 вердикта о нём не выносил. Такие артефакты ОБЯЗАНЫ фиксироваться по настоящему пункту при создании Задачи либо воспроизводиться в рамках Задачи, QG-0 которой им предшествовал. Исследование освобождено от необходимости иметь Задачу; маршрутом, которым готовая работа входит в систему нерассмотренной, оно не является.

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

8.7 Проверка на основе рисков

Проверка безопасности для изменений высокого риска: для изменений, затрагивающих аутентификацию, обработку платежей, персональные данные или криптографию, проверка безопасности ОБЯЗАНА выполняться на ВСЕХ уровнях конфигурации, а не только Корпоративная. Это обязательное (ОБЯЗАТЕЛЬНО) требование вне зависимости от размера команды. Организации, разрабатывающие системы, критичные с точки зрения безопасности, ОБЯЗАНЫ внедрять контроли безопасности (QG-3 с Минимальными критериями проверки AI-вывода, проверка кода по уровню риска) вне зависимости от конфигурации.

NOTE — ОТКРЫТЫЙ ВОПРОС, в настоящей редакции не решённый и перенесённый в следующую. Предложение выше и Раздел 3 говорят о Начальной конфигурации разное. Здесь QG-3 причитается на всякой конфигурации для систем, чувствительных к безопасности; Раздел 3 называет QG-3 среди требований, которых §11.1 не содержит, и говорит, что такое требование «на Начальной не причитается ни на каком уровне», а 8.4, 8.9, 8.10 и 11.1 помечают QG-3 как Командная+. Решение в любую сторону меняет число шлюзов, которые организация на Начальной обязана держать, поэтому настоящая редакция конфликт называет, а не снимает, и выносит его на вычитку. Пока он не решён, организации на Начальной, строящей аутентификацию, платежи или обработку персональных данных, РЕКОМЕНДУЕТСЯ читать настоящий подраздел как более строгий и выполнять критерии 8.4 и ревью безопасности, а при невыполнении фиксировать это по 13.5.

8.8 Конвейер шлюзов

Исследование ──► (есть результат?) ──► Задача
Задача ──► [QG-0] ──► active ──► [QG-2] ──► done
                                  │
                         (Team+) [QG-3] ──► merged
                                  │
                                [QG-4] ──► released

История/Инкремент: [QG-1] ──► approved ──► Задачи созданы

NOTE: Эта схема информативна. Она показывает порядок, в котором шлюзы достигаются, а не место, в котором шлюз обязан действовать. Нормативное требование к размещению — 8.6(b) в связке с предотвращаемым эффектом, объявленным каждым шлюзом в Section 8.1–8.5.

8.9 Сводка

NOTE: Основы SENAR определяют QG-0 (Контекстный шлюз) и QG-2 (Шлюз реализации) как два шлюза качества. Начальная конфигурация наследует оба шлюза из Базовой (Section 11.1).

NOTE: Эта таблица говорит, какие шлюзы применяются. Чем каждый из них обязан быть — пять свойств и уровень обязательности каждого по конфигурациям — сказано один раз, в 8.6, и здесь не повторяется. Шкала, напечатанная дважды, есть шкала, способная разойтись сама с собой, и эта уже начала расходиться.

8.10 Перекрёстная ссылка по требованиям безопасности

Сводное представление всех требований безопасности по всему Стандарту. Используйте эту таблицу при аудите покрытия безопасности или при внедрении новой конфигурации.

NOTE: «Все конфигурации» означает, что требование применяется вне зависимости от размера команды — включая команды Начальной конфигурации. Нормативное утверждение о применимости проверки безопасности см. в 8.7.