docs: bound review convergence across delivery flows

[dapi]

Closes #121.

Проблема

Процессы требовали независимой проверки реализации и зелёного CI, но не определяли порядок между «реализация закончена» и «готово». Отсюда ровно те последствия, что перечислены в issue: исправленная после проверки редакция могла дойти до закрытия без повторной чистой проверки, verdict и CI могли подтверждать разные редакции, одинаковые замечания повторялись без разбора причины, а четыре flow трактовали успешное завершение по-своему.

Где живёт контракт

flows/testing-policy.md уже canonical для verification_context_separation — то есть для того, как устроены проходы проверки. Туда и добавлен cross-flow раздел Review Convergence; добавлен ключ review_convergence_contract в canonical_for.

Что он задаёт

• Ровно два исхода. Сошлась или не сошлась. Третьего — «вроде замечания закрыли» — не существует.
• Одна редакция. Clean verdict и зелёный обязательный CI обязаны относиться к одной и той же редакции кода; любое исправление после verdict создаёт новую редакцию и аннулирует его. Verdict по одной редакции и CI по другой вместе не доказывают ничего.
• Бюджет. По умолчанию десять полных циклов «проверка — исправление» на один review pass. Flow может задать более строгий предел — как пять итераций Plan Ready artifact review в Feature Flow, которые теперь явно связаны с общим контрактом.
• Исчерпание — повод для разбора, а не для приёмки. И не Human Gate само по себе: применяется Structured Decision Protocol, эскалация только при outcome escalate.
• Классификация причины с возвратом к владельцу фактов: локальный дефект → тот же execution step; ошибка последовательности → Plan Ready; ошибка решения или контрактов → Solution Ready; ошибка требований → Problem Ready; неверный процесс → Task Routing.
• След. Номер цикла, проверенная редакция, verdict и класс причины фиксируются в canonical carrier flow. Без него нельзя отличить сошедшуюся проверку от брошенной.

Что изменилось в flow

Feature, Small Change, Bug Fix и Refactoring ссылаются на общий контракт вместо собственной формулировки «последний review cycle завершён без открытых замечаний», которая не требовала ни одной редакции, ни разбора причины. Done gate в Feature Flow дополнен тем же условием.

Границы

Контракт механизм-нейтрален: требует независимой проверки со структурированным verdict, но не выбирает инструмент, команду или оркестратор — это предмет #120, и он подставит code-converge в готовый контракт, не создавая второй способ запуска проверки.

Выбранный validation profile, обязательные approvals и CI контракт не ослабляет: они действуют на каждом цикле.

Проверки

lint шаблона, lint --repo-root ., doctor --profile template, валидатор priming-манифестов, git diff --check — всё зелёное.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RtxeRwhVf1y8zvxUtk6xrS

[dapi]

Ревью нашло 15 проблем, 8 высоких — переписал раздел (0ea10af)

Корень один и он мой: первая редакция проектировалась по частично прочитанному issue. Я прочитал постановку и хвост, но пропустил середину — таблицу из семи классов причин, требования к границе цикла, исключение нестабильного CI и прямой запрет смешивать контракт с Plan Ready.

Отдельно признаю фактическую ошибку в описании PR: там было сказано «Done gate в Feature Flow дополнен», хотя условие стояло только в testing-policy.md, который сам ссылается на feature.md как на владельца gates. Теперь дополнен по-настоящему.

#	Находка	Как закрыто
1, 2	Done gate Feature Flow не был обновлён, условие висело в файле, который делегирует владение	дополнен feature.md
3, 14	Plan Ready подчинён контракту, который сам себя объявляет проверкой реализации; дубль константы «пять»	связь снята, контракт явно ограничен проверкой после реализации
4	«Локальный дефект → тот же шаг» открывал закрытый цикл заново	возврат — пересоставить ограниченный план исправления; новый лимит нельзя начать без разбора
5	не было седьмого класса причин — внешней блокировки	добавлен по таблице issue
6	повтор нестабильного CI жёг бюджет	без изменения кода циклом не считается
7	возвраты указывали на gates, которых нет в трёх flow из четырёх	правые ячейки называют владельца фактов, gates Feature Flow — в скобках
8	«независимая проверка» молча поднимала планку для documentation и low-risk	глубина отдана validation profile
9	research refactoring становился незакрываемым	CI требуется только для production change
10	не определены граница цикла и редакция	цикл — review → исправления → повторный review, редакция — commit SHA
11	бюджет на проход давал 50 циклов вместо десяти	считается на delivery-единицу
12	след не имел владельца	canonical carrier flow — тот же, что владеет routing record и validation profile decision
13	форма записи решения дублировала SDP	ссылка вместо повтора полей
15	слабая формулировка выживала в Incident	подключён для repository changes

По Epic Flow (тоже упомянут в находке 15) намеренно ничего не менял: его review относится к epic package, а не к проверке реализации — доставку он делегирует feature-пакетам, и там контракт уже действует.

Проверки зелёные: оба lint, doctor --profile template, валидатор priming-манифестов, git diff --check. Манифесты подготовки контекста трогать не потребовалось — flows/testing-policy.md уже входит в стадии feature, small-change, bug-fix, refactoring и incident, поэтому контракт доезжает до агента вместе с ними.

[dapi]

Второй раунд закрыт в 29f041c

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

Определение цикла было дырявым

Цикл начинался «verdict-ом с блокирующими замечаниями». Значит петля

чистый verdict → красный CI по коду → правка → снова чистый verdict → снова красный CI

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

Теперь цикл считается по любой несошедшейся проверке: verdict с замечаниями или красный обязательный CI по причине в коде. В текст добавлено объяснение, почему одних замечаний reviewer недостаточно.

Остальные высокие

Находка	Как закрыто
След ссылался на «тот же carrier, что routing record и profile decision» — у Feature Flow это разные документы	один владелец: canonical owner profile decision из таблицы validation-profiles.md; добавлена минимальная форма записи
Incident подключён к контракту, хотя validation-profiles.md не назначает ему profile — два пункта контракта остались бы без референта	Incident отключён; permanent remediation получает и profile, и контракт после отдельного Task Routing

Medium и low

• Контракт добавлен в сами чек-листы gate, а не только в Required Evidence: терминальное состояние определяется через «все gates выполнены», и агент работает по чек-листу — раньше он мог дойти до Done мимо контракта.
• Research refactoring полностью выведен из-под контракта: у него нет production change, а контракт объявляет себя проверкой после реализации.
• Возврат при дефекте реализации — «ограничить объём исправления», а не «пересоставить план»: в Small Change план сам является триггером rerouting, то есть прежняя формулировка заставляла нарушить flow.
• Для flow без нужного этапа возврат ведёт к повторному Task Routing.
• derived_from дополнен autonomy-boundaries.md и routing.md, откуда контракт берёт нормативное содержание.
• Терминальное состояние названо как Done, Resolved или эквивалент — Bug Fix и Incident не заканчиваются в Done.

Проверки зелёные: оба lint, doctor --profile template, валидатор манифестов, git diff --check.

[dapi]

Ответ на «не слишком ли усложняем»: да — сократил вдвое (e3de010)

Ревью на соразмерность дало цифры, которые всё решают: 114 добавленных строк, из них на счастливом пути работают 18. Контракт занимал 48% файла, а файл входит в priming всех четырёх flow — то есть 800 слов протокола несходимости читались на каждой задаче, включая те, где проверка сходится с первого раза.

Раздел: 114 строк → 53, без потери критериев приёмки #121.

Упрощение вскрыло два дефекта, которых не нашли два предыдущих раунда

След создавал петлю, которую сам же контракт запрещает. Я предписал писать его в canonical owner profile decision — для Feature Flow это brief.md в репозитории. Значит запись следа = новый commit = новая revision, на которой verdict уже недействителен. Теперь след пишется вне проверяемой revision: issue, PR или routing record. Побочно ушла и претензия, что execution-факты лежали в problem-space документе.

«Дефект реализации → повторить в текущем flow» не сочеталось с запретом открывать новый лимит без обновления владельца фактов: состояние было не определено, то есть цикл мог идти вечно за пределами бюджета. Разрешено одно продолжение с явно суженным объёмом, дальше — SDP.

Что выброшено

• След на счастливом пути — вместе с полями, которые там физически не заполняются: Cycle: <номер>/<бюджет> при нуле циклов не определён, у Decision нет значения «сошлось».
• Два абзаца обоснования («без этого правила петля не расходовала бы бюджет…») — это ответы прошлым ревьюерам, а не норма. Место им в описании PR, а не в документе, который читают на каждой задаче.
• Пересказ факта о глубине проверки, которым владеет validation-profiles.md.
• Дубли формулировки в восьми местах → одна голая ссылка на flow. dna/principles.md: «Дубли = дефект», и расхождение уже началось — чек-листы требовали записи следа, Required Evidence нет.

Что добавлено

• Восстановлено требование закрытого review для research refactoring: сужение до production change случайно сняло его совсем, и research с открытыми блокирующими замечаниями формально проходил Exit Contract.
• Манифесты priming для Small Change и Refactoring дополнены autonomy-boundaries.md и routing.md. Контракт требует их при несходимости, а агент читает только exact manifest стадии — иначе на несходимости у него не будет нужного документа. Это же прямо входит в область изменения по Не допускать бесконечных циклов проверки после реализации #121.
• dependency-tree.md обновлён под новый derived_from.

Проверки зелёные: оба lint, doctor --profile template, валидатор манифестов, git diff --check.