Не допускать бесконечных циклов проверки после реализации

[dapi]

Проблема

Текущие процессы поставки требуют проверки реализации, исправления замечаний и
зелёного CI перед завершением работы, но не определяют единый порядок действий
между окончанием реализации и состоянием «готово».

Из-за этого остаются неоднозначности:

• достаточно ли одной проверки или после исправлений новую редакцию кода нужно
  проверить повторно;
• должны ли положительный результат проверки и зелёный CI относиться к одной и
  той же редакции кода;
• сколько раз допустимо повторять проверку и исправления;
• что делать, если повторные исправления не приводят к успешному результату;
• как отличить локальный дефект реализации от ошибки в плане, проектном решении,
  спецификации, брифе или первоначальной маршрутизации задачи;
• когда действительно требуется решение человека, а когда процесс должен
  самостоятельно вернуться к более раннему этапу.

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

Желаемый результат

После реализации каждый применимый процесс поставки должен приводить работу к
одному из двух явных состояний:

1. Проверка успешно завершена — текущая редакция кода независимо проверена,
   все блокирующие замечания устранены, а обязательные проверки CI зелёные.
2. Проверка не сошлась — допустимое число циклов исчерпано, работа не
   закрыта, причина проанализирована, а задача возвращена к правильному
   владельцу фактов и этапу жизненного цикла.

Процесс должен быть ограниченным: по умолчанию допускается не более 10 полных
циклов «проверка — исправление». Исчерпание лимита служит поводом для
диагностики, а не разрешением принять работу, проигнорировать замечания или
автоматически запросить решение человека.

Наблюдаемые последствия проблемы

• Исправленная после проверки редакция кода может попасть к завершению без
  повторной чистой проверки.
• Результат проверки и результат CI могут подтверждать разные редакции кода.
• Одинаковые замечания могут повторяться без анализа системной причины.
• Локальные исправления могут расходиться с принятыми требованиями или проектным
  решением.
• Нет общего проверяемого следа, объясняющего, почему цикл продолжили,
  остановили или вернули на более ранний этап.
• Feature Flow, Small Change Flow, Bug Fix Flow и Refactoring Flow могут
  по-разному трактовать условия успешного завершения проверки.

Требования к процессу

Условие успешного завершения

• Положительный результат проверки и полностью зелёный набор обязательных
  проверок CI относятся к одной редакции кода.
• Если по результатам проверки код изменился, новая редакция проходит повторную
  проверку.
• Требования выбранного профиля проверки, обязательные согласования и правила
  для проверок, доступных только вручную, не ослабляются ради завершения цикла.
• До выполнения этих условий работа не переходит в конечное состояние
  Done/Resolved.

Ограничение цикла

• Лимит по умолчанию — 10 полных циклов «проверка — исправление».
• Документация однозначно определяет, что считается одним циклом.
• Повторный запуск нестабильной или недоступной проверки CI без изменения кода
  не должен автоматически считаться новым циклом исправления.
• Нельзя бесконечно начинать новый лимит без анализа причины и обновления
  соответствующего владельца исходных фактов.

Действия при несходимости

После исчерпания лимита требуется краткий анализ, основанный на наблюдаемых
данных:

• какие замечания повторялись;
• какие исправления предпринимались и к чему они привели;
• какие локальные проверки и проверки CI остаются красными;
• является ли причина локальной или находится на более раннем этапе;
• какой владелец фактов и какой этап должны быть пересмотрены.

Минимальная классификация причин:

Причина	Куда вернуть работу
Дефект реализации или необоснованная сложность	Пересоставить ограниченный план исправления реализации
Недостаточное изучение текущего кода или ошибочная последовательность выполнения	Вернуться к готовности плана (Plan Ready)
Пробел или противоречие в решении, контракте, инварианте, обработке отказов либо правилах выпуска	Вернуться к владельцу проектного решения или ADR и повторно пройти готовность решения (Solution Ready)
Пробел или противоречие в границах, требовании, критерии приёмки либо составе доказательств	Вернуться к канонической спецификации или брифу и повторно пройти готовность проблемы (Problem Ready)
Недостаточно определены проблема, результат или границы	Повторить брифование или первичный разбор
Неверно определён тип задачи или её объём	Повторить маршрутизацию задачи; при необходимости выбрать исследование, Feature Flow или Epic Flow
Внешняя блокировка, недоступная инфраструктура или нестабильный CI без причины в коде	Зафиксировать ожидание или блокировку с доказательствами, не меняя исходные факты без основания

После изменения исходного владельца все зависящие от него документы и этапы
проверки проходят заново.

Решение человека требуется только при результате «escalate» по протоколу
структурированного принятия решений (Structured Decision Protocol) либо при уже
существующем обязательном согласовании. Самих десяти неуспешных циклов
недостаточно для передачи задачи человеку.

Область изменения

Нужно определить один канонический процесс проверки после реализации и
подключить к нему как минимум:

• Feature Flow;
• Small Change Flow;
• Bug Fix Flow;
• Refactoring Flow;
• правила валидации и тестирования;
• применимые шаблоны и манифесты подготовки контекста.

Новый процесс не должен смешиваться с проверкой готовности плана (Plan Ready):
это отдельный этап до реализации, для которого сейчас установлен собственный
лимит в пять итераций.

Критерии приёмки

• В канонических правилах описаны проблема несходимости после реализации и
  риск преждевременного завершения работы.
• Для применимых процессов поставки определены одинаковые состояния:
  «проверка успешно завершена» и «проверка не сошлась».
• Для успеха требуются положительный результат проверки и зелёный
  обязательный CI для одной редакции кода.
• Любая редакция с исправлениями требует последующей чистой повторной
  проверки.
• Лимит по умолчанию равен 10 полным циклам «проверка — исправление», а
  граница одного цикла определена однозначно.
• Повтор нестабильной или недоступной проверки CI без изменения кода
  учитывается отдельно от цикла исправления.
• Исчерпание лимита оставляет этап незавершённым и запускает анализ,
  основанный на наблюдаемых данных.
• Анализ различает причины в реализации, плане, проектном решении или ADR,
  спецификации или брифе, первичном разборе или маршрутизации, а также
  внешние причины.
• Для каждого класса причин определён возврат к владельцу исходных фактов и
  повторный проход соответствующего этапа.
• Исчерпание лимита само по себе не создаёт Human Gate.
• Решение сохраняет требования выбранного профиля проверки и обязательных
  согласований.
• Проверка готовности плана остаётся отдельным непротиворечивым этапом.
• После изменения правил успешно проходят проверки шаблона, lint и doctor.

Связанные решения и ограничения

В issue #120 отдельно рассматривается code-converge как канонический механизм
проверки. Если это решение будет принято, описанный здесь процесс должен
использовать его структурированный результат, а не создавать второй способ
запуска проверки.

Эта задача не должна повторно выбирать механизм проверки, параметры командной
строки, терминальный оркестратор или внутреннюю реализацию автоматизации
«проверка — исправление». Такие детали определяются после принятия требований к
процессу и принадлежат issue #120 либо отдельному проектному решению.

Не входит в задачу

• Изменение продуктовых требований только ради успешного прохождения проверки.
• Ослабление CI, профиля проверки или обязательных согласований.
• Проектирование внутреннего устройства выбранного инструмента проверки.
• Автоматическое создание Human Gate только из-за сложности задачи или
  исчерпания лимита.

Связано с #120.