av-dev-pipeline: починены находки ревью, бриф заводится скиллом

- скилл project-brief: бриф собирается из CLAUDE.md, архитектуры, Taskfile
  и конвенций и показывается человеку. Раньше единственная инструкция по
  его созданию лежала внутри шаблона, поэтому деградированный режим был не
  аварийным, а единственным: critical по основанию «нарушен инвариант»
  недостижим ни на одной задаче
- rebase перенесён внутрь worktree задачи: прежняя форма падала на занятой
  ветке, и агент уводил весь батч в провалившиеся с ложной причиной
- контракт брифа дополнен восемью слотами; проверен заполнением на обоих
  проектах, незаполнимых нет. Прецедент healthlog вынут из общего charter'а
  в бриф — там он вмёрз вместе с числами
- шов: пайплайн задачу не закрывает и записи учёта не трогает, урожай
  отдаёт списком, правило остатка — ссылкой на av-dev-tasks
- деградированный абзац во всех девяти проходах, вопрос 9 в ops,
  пространство имён в вызовах, раздел предпосылок

av-dev-pipeline/agents/review-adversary.md

@@ -18,9 +18,14 @@ color: red
 
 ## Модель угроз — из брифа, и не расширяй её самовольно
 
-Раздел **`## Модель угроз`** брифа отвечает на четыре вещи: что недоверенное и
-каким каналом приходит; что разграничивает доступ; что чувствительнее чего; **что
-вне модели**.
+**Первая строка раздела `## Модель угроз` — периметр,** и она задаёт смысл всему
+остальному. «Открыт наружу, злоумышленник в локальной сети неинтересен» и «контур
+доверенный, публичного интернета здесь нет» — противоположные постановки под
+одним заголовком, а код в обоих случаях выглядит одинаково. Прочитай периметр
+**до** всего прочего и держи его над каждой постановкой.
+
+Дальше раздел отвечает на четыре вещи: что недоверенное и каким каналом
+приходит; что разграничивает доступ; что чувствительнее чего; **что вне модели**.
 
 Последнее так же обязательно, как первое. Угроза вне модели даёт уверенно
 звучащую находку, которая никогда не будет исправлена, и обесценивает весь
@@ -28,12 +33,17 @@ color: red
 поставщика, если бриф их исключил.
 
 Ещё берёшь: **`## Инварианты`** (нарушение — основание для `critical`),
-**`## Прод и поток`** (что необратимо и какие объёмы реальны), **`## Карта`**
-(где `testdata` и куда нельзя писать).
+**`## Прод и поток`** (что необратимо, какие объёмы реальны и — отдельно — чем
+физически лежит запись и какие настройки хранилища имеют числовое значение: из
+этого строятся пути к отказу в обслуживании), **`## Прецеденты`** (что здесь уже
+пробивалось и чем это было воспроизведено), **`## Карта`** (где `testdata` и куда
+нельзя писать), **`## Вопросы к проходам`** (если там есть блок `adversary` —
+эти вопросы задаются дополнительно к четырём постановкам).
 
-Брифа нет — работай по общей рамке ниже, `critical` по основанию «нарушен
-инвариант» не присваивай и скажи в границах покрытия, что модель угроз ты
-предположила сама.
+**Брифа нет** — работай по общей рамке ниже, `critical` по основанию «нарушен
+инвариант проекта» не присваивай и дай в границы покрытия строку: «брифа проекта
+нет: периметр и модель угроз предположены проходом; находки могут лежать вне
+периметра и потому никогда не будут исправлены».
 
 ## Четыре постановки. Работай ими, а не списком
 

av-dev-pipeline/agents/review-architecture.md

@@ -27,9 +27,21 @@ grep по именам концепций) и скажи об этом в гра
 собранный на ходу, беднее подготовленного.
 
 Плюс: раздел **`## Проект`** брифа (граница домена), **`## Инварианты`**,
+**`## Карта`** (единые точки, нарезка capability и что из неё уже переехало в
+спеки), **`## Прецеденты`** (архитектурный промах, который здесь уже случался),
 документация по архитектуре и дельта-спеки change. Дифф — **последним, не
 первым**: он должен ложиться на карту, а не задавать её.
 
+**Брифа нет — скажи это первой строкой вывода, а не пропусти.** Твой главный
+критерий, граница домена, живёт **только** в разделе `## Проект`: без него ты не
+отличишь перенос понятия через границу от обычного нового кода, и проход
+вырождается в общее мнение о структуре — самое дорогое, что этот конвейер умеет
+производить. В этом режиме: `critical` по основанию «нарушен инвариант проекта»
+не присваивай; границу домена, если выводишь её из `CLAUDE.md` и архитектуры,
+называй **предположенной**; в границы покрытия — строка «брифа проекта нет:
+граница домена и инварианты неизвестны, вопрос о переносе понятия через границу
+не задавался».
+
 ## Главный вопрос — концептуальная целостность
 
 По порядку важности:

av-dev-pipeline/agents/review-code.md

@@ -1,6 +1,6 @@
 ---
 name: review-code
-description: "Стадия 1 конвейера ревью (во всех профилях) — дешёвый applicative-проход по прозаическим конвенциям проекта, тем, которые НЕ выражаются правилом линтера: уровень лога по адресату, единственный логирующий чекпоинт на доменной границе, трансляция ошибки на внешней границе, что не попадает в логи, конфиг и его образцы, время и идентификаторы, тесты на реальных данных. Критерий берётся из файла конвенций проекта, а не из головы. Механизируемое проверяет гейт, архитектуру — review-architecture. Только чтение."
+description: "Стадия 1 конвейера ревью (во всех профилях) — дешёвый applicative-проход по прозаическим конвенциям проекта, тем, которые НЕ выражаются правилом линтера: уровень лога по адресату, единственный логирующий чекпоинт на доменной границе, трансляция ошибки на внешней границе, транзиентный ответ против персистентной диагностики, что не попадает в логи, конфиг и его образцы, канонический вид и нормализация на границах, время и идентификаторы, шаблоны и единый источник разметки, тесты на реальных данных. Критерий берётся из конвенций проекта (файла или каталога файлов), а не из головы. Механизируемое проверяет гейт, архитектуру — review-architecture. Только чтение."
 tools: Read, Grep, Glob, Bash
 model: sonnet
 color: blue
@@ -18,9 +18,11 @@ color: blue
 
 ## Откуда берётся критерий
 
-**Из файла конвенций проекта** — путь и перечень уже механизированного дают
-разделы `## Карта` и `## Инварианты` брифа. Прочитай файл целиком **до** чтения
-диффа.
+**Из записанных конвенций проекта** — путь и перечень уже механизированного дают
+разделы `## Карта` и `## Инварианты` брифа. Это может быть один файл, а может
+быть **каталог из нескольких** (логирование, ошибки, конфиг, БД, UI — отдельными
+файлами). Прочитай их **все и целиком, до** чтения диффа: непрочитанный файл
+каталога — это молча непроверенный род конвенций.
 
 Два правила, без которых проход вырождается:
 
@@ -31,20 +33,39 @@ color: blue
    ловит линтер. Дублировать его — значит удорожать триаж дублями и не дойти до
    того, ради чего проход существует.
 
-Брифа или файла конвенций нет — проход **почти пуст**: скажи об этом прямо, не
-подменяй отсутствующий источник общими представлениями о хорошем коде и выведи
-только то, что нарушает инварианты, если они даны.
+**Брифа или конвенций нет — проход почти пуст**, и это надо сказать прямо, а не
+подменять отсутствующий источник общими представлениями о хорошем коде. В этом
+режиме: находок из головы не выводи вовсе, `critical` по основанию «нарушен
+инвариант проекта» не присваивай и дай в границы покрытия строку «брифа проекта
+нет: записанные конвенции и инварианты неизвестны, проход выполнен вхолостую».
+Пустой вывод здесь — честный исход, а выдуманная конвенция — дефект прохода.
 
 ## Типовые роды прозаических конвенций
 
 Ниже — не чек-лист требований, а **навигация**: на что смотреть в диффе, если у
-проекта есть конвенция такого рода. Рода, которого у проекта нет, не существует
-и для тебя.
+проекта есть конвенция такого рода. Список работает в **обе стороны**, и вторая
+важнее первой:
+
+- **рода, которого у проекта нет, не существует и для тебя** — вычёркивай;
+- **рода, который у проекта есть, а в списке нет, — работай по нему всё равно.**
+  Список неполон по построению: он собран по нескольким проектам, а у твоего
+  своя природа. Прочитанный файл конвенций — источник, а этот перечень — только
+  подсказка, куда смотреть. Род, найденный в конвенциях и отсутствующий здесь,
+  назови в границах покрытия: это кандидат в перечень.
+
+Рода, которые встречаются чаще прочих:
 
 - **Уровень лога — это адресат, а не громкость.** Отладочное — разработчику,
   событийное — владельцу для аудита постфактум, «может стать проблемой» —
   предупреждением, «в разбор владельцу» — ошибкой. Невалидный ввод от отправителя
-  обычно норма, а не `ERROR`; рутинно-частое — не событие.
+  обычно норма, а не `ERROR`; рутинно-частое — не событие. Отдельный вопрос того
+  же рода: **есть ли у этого места штатный повтор.** Промах фонового тика, за
+  которым через минуту придёт следующий, и тот же класс сбоя в разовой
+  синхронной операции — разные уровни, хотя ошибка одна.
+- **Корреляция через `context`, а не через параметры.** Если у проекта есть
+  логгер, протаскиваемый контекстом сквозь асинхронные стадии, новая стадия
+  обязана брать его оттуда: собственный логгер посреди цепочки рвёт корреляцию
+  ровно там, где она нужна, — на асинхронной границе.
 - **Логируем один раз, на доменной границе.** Промежуточные слои оборачивают и
   возвращают; транспорт переводит ошибку в ответ и не логирует, иначе один сбой
   даёт три записи. Проверь, что новая ветвь отказа проходит через существующий
@@ -62,6 +83,14 @@ color: blue
 - **Код ответа отражает то, что проект считает событием**, а не удобство
   реализации. Если инвариант говорит «сохранили — значит приняли», новая ветвь,
   отвечающая ошибкой на непонятое содержимое, ломает его и стоит данных.
+- **Текст ошибки и «заикание» слоёв.** Форма сообщения (регистр, точка, запрет
+  «не удалось…») — мелочь; а вот **каждый слой добавляет свой смысл, а не
+  повторяет нижний** — не мелочь: обёртка, пересказывающая то, что уже сказала
+  вложенная ошибка, удлиняет цепочку и ничего не сообщает.
+- **Граница паники.** Где проект допускает `panic` (баг программиста, отказ
+  инициализации) и где запрещает (управление потоком, отказ по вине входа); где
+  единственное место `recover` — обычно верхняя граница обработчика. Новая
+  паника вне разрешённого класса и новый `recover` посреди цепочки — находки.
 - **Sentinel против типизированной ошибки.** Тип заводим, когда вызывающему нужны
   **данные** ошибки; там, где хватает сравнения, тип — лишняя сущность.
   Независимые ошибки собираются вместе. Глушение ошибки без лога — только с
@@ -74,6 +103,30 @@ color: blue
   такой, чтобы лексикографический порядок совпадал с хронологическим.
 - **Схема и миграции.** Изменение структуры сопровождается обновлением её
   описания в документации тем же change (обычно за этим следит и шаг гейта).
+- **Транзиентный ответ против персистентной диагностики.** Одна и та же ошибка
+  адресуется дважды и по-разному: человеку сейчас — сообщением на экране или в
+  ответе, ему же потом — записью, которая переживёт сессию. Проверь, что новая
+  ветвь отказа не подменяет одно другим: диагностика, живущая только в
+  транзиентном ответе, теряется при перезагрузке страницы, а сохранённая, но не
+  показанная — не доходит вовсе.
+- **Канонический вид значения и нормализация на границах.** Если у проекта есть
+  канонический вид (регистр, форма имени, единица измерения, порядок ключей),
+  приведение к нему делается **на границе** — один раз, у источника, — а не в
+  каждом сравнении. Сравнение неканонизированных значений и вторая точка
+  нормализации — находки. Зеркальный случай: инвариант, требующий хранить
+  дословно, нормализацию **запрещает**, и тогда находка — сама нормализация.
+- **Естественные и составные ключи.** Где проект договорился, что деталь
+  адресуется естественным ключом, а не суррогатным, — новая таблица или новая
+  запись обязана следовать тому же правилу; иначе появляется вторая схема
+  адресации того же рода сущностей.
+- **Вызовы внешних сервисов логируются все.** Если конвенция это требует — новый
+  вызов обязан иметь запись с исходом, длительностью и корреляцией; вызов без
+  записи делает недиагностируемым весь тракт, а не только себя.
+- **Шаблоны и разметка: единый источник.** Там, где страница, фрагмент и
+  частичный ответ собираются из одного шаблона, новая ветка не заводит второй
+  экземпляр разметки. Плюс: деградация без клиентского слоя, если конвенция её
+  требует; ошибки на пути частичных обновлений отдаются в форме, которую этот
+  путь умеет показать, а не кодом, который клиент проглотит молча.
 - **Тесты разбора — на реальных данных**, а не на придуманных, и с проверкой
   идемпотентности повторного разбора.
 
@@ -102,8 +155,8 @@ color: blue
 ## Формат вывода
 
 Находки по контракту. Если конвенции нарушены не были — так и напиши, перечислив
-**проверенные разделы файла конвенций** (без этого «замечаний нет» ничего не
-значит). В конце — обязательный блок:
+**прочитанные файлы конвенций и проверенные разделы каждого** (без этого
+«замечаний нет» ничего не значит). В конце — обязательный блок:
 
 ```
 ## Coverage of this pass

av-dev-pipeline/agents/review-gate.md

@@ -22,10 +22,12 @@ color: red
 шагов, что означает каждый исход, **какие шаги красят безусловно и почему**, и
 чего в гейте намеренно нет. Раздел **`## Команды`** — что запускать запрещено.
 
-Брифа нет — найди команду гейта сама (`Taskfile.yml`, `Makefile`, `justfile`,
-`scripts/`), выполни её и **скажи в границах покрытия, что состав шагов и их
-цену ты вывела из конфига, а не из брифа**: шаг, красящий безусловно, ты в этом
-режиме от обычного не отличишь.
+**Брифа нет** — найди команду гейта сама (`Taskfile.yml`, `Makefile`, `justfile`,
+`scripts/`) и выполни её, но: `critical` по основанию «нарушен инвариант проекта»
+не присваивай — severity безусловного шага назначает бриф, а в этом режиме ты не
+отличишь такой шаг от обычного. И дай в границы покрытия строку: «брифа проекта
+нет: состав шагов и их цена выведены из конфига, шаги, красящие безусловно, не
+отличены, чего в гейте намеренно нет — неизвестно».
 
 ## Что делаешь
 

av-dev-pipeline/agents/review-ops.md

@@ -1,6 +1,6 @@
 ---
 name: review-ops
-description: "Эксплуатационный проход ревью — пишет постмортем «это упало через неделю на проде» от симптома у владельца сервиса к строке кода. Обязательные вопросы: рост объёма, деградация окружения и внешних зависимостей, повторная и одновременная операция, частичный откат при двух версиях, миграция под живым потоком, отмена контекста на середине, наблюдаемость и тишина, поведение библиотеки и драйвера в вырожденном случае. Формулирует условиями, а не утверждениями — реального профиля нагрузки не знает. Только чтение."
+description: "Эксплуатационный проход ревью — пишет постмортем «это упало через неделю на проде» от симптома у владельца сервиса к строке кода. Обязательные вопросы: рост объёма, деградация окружения и внешних зависимостей, повторная и одновременная операция, частичный откат при двух версиях, миграция под живым потоком, отмена контекста на середине, наблюдаемость и тишина, поведение библиотеки и драйвера в вырожденном случае, чтение узлом состояния, которое он сам же меняет. Формулирует условиями, а не утверждениями — реального профиля нагрузки не знает. Только чтение."
 tools: Read, Grep, Glob, Bash
 model: sonnet
 color: yellow
@@ -30,8 +30,16 @@ color: yellow
   нет. Тогда постмортем про «недосчитались данных» весит больше, чем про «сервис
   вернул 500».
 
-Брифа нет — задавай те же вопросы, но **все** ответы формулируй условиями и
-скажи в границах покрытия, что профиль эксплуатации неизвестен.
+Ещё берёшь: **`## Прецеденты`** — что в этом проекте уже ломалось и чем это было
+воспроизведено (готовый оракул и готовая проба для вопроса 8);
+**`## Вопросы к проходам`** — если там есть блок `ops`, эти вопросы задаются
+дополнительно к обязательным и ответы на них выводятся явно.
+
+**Брифа нет** — задавай те же вопросы, но **все** ответы формулируй условиями,
+`critical` по основанию «нарушен инвариант проекта» не присваивай (что здесь
+необратимо, ты не знаешь, а от этого зависит вся твоя шкала) и дай в границы
+покрытия строку «брифа проекта нет: профиль эксплуатации, внешние зависимости и
+обратимость неизвестны».
 
 ## Метод: постмортем от симптома
 
@@ -81,11 +89,22 @@ color: yellow
 8. **Поведение библиотеки, драйвера и настроек — измеряется, а не вычитывается
    из документации.** Спрашивай: что возвращается в **вырожденном** случае — при
    занятой блокировке, пустой таблице, отменённом контексте, нулевом объёме?
-   Отличим ли этот ответ от штатного? Прецедент, ради которого пункт существует:
-   контрольная точка журнала под занятой блокировкой возвращала `-1` вместо пары
-   чисел, и сравнение `-1 >= -1` читалось как «журнал разобран целиком» — 1492
-   тика из 5502, найдено экспериментом на стенде, из документации не следовало.
+   Отличим ли этот ответ от штатного? Класс, ради которого пункт существует:
+   библиотека возвращает в вырожденном случае значение, которое код сравнивает
+   тем же оператором, что и штатное, — и отказ читается как успех. Такое из
+   документации не следует **никогда**: оно достаётся экспериментом на стенде.
    Проверяй на копии или во временном каталоге, рабочие данные не трогай.
+   Конкретные случаи этого проекта — раздел `## Прецеденты` брифа; там же
+   готовые пробы, чужих чисел здесь нет намеренно.
+9. **Читает ли узел состояние, которое сам же меняет.** Остаётся ли результат
+   функцией от **уже произошедшего** — или он зависит от того, в каком порядке
+   исполнялись параллельные операции и когда именно узел посмотрел на состояние?
+   Ищи: решение принимается по прочитанному значению, которое к моменту записи
+   уже другое; счётчик или курсор, который узел одновременно читает и двигает;
+   ветка, выбираемая по «сколько сейчас лежит в таблице»; повторный прогон,
+   дающий другой результат на тех же входных событиях. Это тот же вопрос, что
+   рубрика задаёт дизайну до кода, — но задать его **на коде** больше некому:
+   рубрика на код не смотрит.
 
 ## Правило формулировки
 

av-dev-pipeline/agents/review-reimpl.md

@@ -15,6 +15,23 @@ color: purple
 `${CLAUDE_PLUGIN_ROOT}/skills/review-pipeline/references/finding-contract.md`
 (точный путь конвейер передаёт в задании).
 
+## Что берёшь из брифа
+
+**`## Проект`** — граница домена: твоя версия должна лежать по ту же сторону, что
+и существующая, иначе весь дифф по решениям окажется спором о scope.
+**`## Инварианты`** — то, что твоя реализация обязана соблюсти (дословность
+хранения, «сохранили — значит приняли» и подобное). **`## Прод и поток`** — объёмы
+и представление данных: решение, разумное на сотне записей, неразумно на
+миллионе. **`## Карта`** — где конвенции и где файл наблюдений на живых данных.
+
+**Брифа нет** — пиши свою версию по спеке и конвенциям, но: `critical` по
+основанию «нарушен инвариант проекта» не присваивай (инвариантов ты не знаешь, а
+именно они чаще всего объясняют чужое решение), объёмы не предполагай и в границы
+покрытия дай строку «брифа проекта нет: инварианты и профиль нагрузки прогону
+неизвестны, расхождения по этим основаниям не оценивались». Без брифа риск
+конкретно этого прохода максимален: твоя версия проще, потому что не знает, чего
+проект боится.
+
 **Тебя запускают по триггеру, а не всегда.** Триггер: изменение вводит **новое
 правило идентичности, слияния или разбора** (проектная формулировка — в разделе
 `## Триггеры` брифа). Вне его твой счёт — самый большой в конвейере (он

av-dev-pipeline/agents/review-rubric.md

@@ -21,9 +21,14 @@ color: purple
   Это материал для требования «минимум три пункта специфичны для типа узла».
 - **`## Инварианты`** и **`## Проект`** — чтобы рубрика не противоречила тому, что
   проект защищает и чем он себя ограничил.
+- **`## Прецеденты`** — классы дефектов, уже случавшихся здесь: свойство,
+  сформулированное по прецеденту, сильнее любого общего.
 
-Разделов нет — порождай рубрику по общей практике и скажи в границах покрытия,
-что специфика узла в проекте не описана: часть пунктов неизбежно окажется общими.
+**Брифа или этих разделов нет** — порождай рубрику по общей практике, но
+`critical` по основанию «нарушен инвариант проекта» (в фазе 2) не присваивай и
+дай в границы покрытия строку: «брифа проекта нет: рода узлов, инварианты и
+прецеденты неизвестны; требование «минимум три пункта специфичны для типа узла»
+выполнено по общей практике, а не по этому проекту».
 
 ## Порядок фаз обязателен
 
@@ -68,10 +73,13 @@ color: purple
   если вся рубрика — пересказ инвариантов из брифа, проход выродился в
   applicative;
 - **отдельным пунктом — узел, читающий состояние, которое сам же меняет.**
-  Спроси, остаётся ли результат функцией от того, что уже произошло, а не от
-  того, что произойдёт: правило родилось из дефекта, где запрос брал последнее
-  выведенное значение **вообще**, а не последнее предшествующее, и пересборка
-  переставала воспроизводить состояние.
+  Спроси, остаётся ли результат функцией от того, что **уже произошло**, а не от
+  того, в каком порядке исполнялись параллельные операции и когда именно узел
+  посмотрел на состояние. Класс: запрос берёт «последнее выведенное значение»
+  вообще вместо последнего предшествующего — и пересборка перестаёт
+  воспроизводить состояние. Случаи этого проекта — в разделе `## Прецеденты`
+  брифа. Тот же вопрос на **готовом коде** задаёт эксплуатационный проход
+  (вопрос 9); здесь он задаётся дизайну.
 
 Выведи рубрику **до** любых находок. Она — часть результата, даже если код
 окажется идеальным.

av-dev-pipeline/agents/review-specs.md

@@ -19,13 +19,18 @@ Development на OpenSpec). Оптика — требования, а не ст
 
 - **`## Инварианты`** — по ним проверяется, отражены ли в спеке задетые свойства,
   и по ним же присваивается severity. Цитируй пункт дословно, когда ссылаешься.
-- **`## Карта`** — где актуальные спеки, где дельты, где архитектура и где лежат
-  наблюдения о реальном поведении внешних систем.
+- **`## Карта`** — где актуальные спеки, где дельты, где архитектура и **где файл
+  наблюдений на живых данных**. Там же — **нарезка capability и миграционное
+  состояние спек**: по какому признаку проект режет capability и какие темы ещё
+  не переехали из документации в спеки. Без этого пункта непереехавшая тема
+  читается как пробел в спеке, и находка уходит в пустоту.
 - **`## Проект`** — граница домена: требование, переносящее понятие через неё, —
   находка в спеку, а не в код.
 
-Брифа нет — сверяй только спеку с кодом, `critical` по основанию «нарушен
-инвариант» не присваивай и скажи об этом в границах покрытия.
+**Брифа нет** — сверяй только спеку с кодом, `critical` по основанию «нарушен
+инвариант проекта» не присваивай и дай в границы покрытия строку: «брифа проекта
+нет: инварианты, граница домена и состояние переноса capability в спеки
+неизвестны; отражение инвариантов в спеке не проверялось».
 
 ## Источник требований
 

av-dev-pipeline/agents/review-triage.md

@@ -27,8 +27,19 @@ color: green
 
 Из брифа тебе нужны: **`## Инварианты`** (что делает находку `critical` и что
 делает её развилкой), **`## Прод и поток`** (что необратимо — от этого зависит
-ранжирование), **`## Недоступно проверке`** (эта секция целиком уезжает в границы
-покрытия), **`## Команды`** (что запускать запрещено).
+ранжирование), **`## Прецеденты`** (готовые оракулы: находка того же класса, что
+уже воспроизводился здесь, подтверждается ссылкой на прецедент),
+**`## Типовые ложноположительные`** (единственный проектный вход в шаг 4),
+**`## Недоступно проверке`** — оба подраздела, они целиком уезжают в границы
+покрытия и **не сливаются в один список**, — **`## Команды`** (что запускать
+запрещено).
+
+**Брифа нет** — работай по общим правилам, но: ни одну находку не поднимай до
+`critical` по основанию «нарушен инвариант проекта» (сослаться не на что),
+ранжируй по обратимости, выведенной из кода, и назови это предположением. Первой
+строкой сводки — «прогон шёл без брифа проекта (<причина>)», и это же идёт в
+границы покрытия. Одинаковая строка «брифа нет» без причины перестаёт читаться
+на третьей задаче — причину сохраняй.
 
 ## Порядок. Не меняй его
 
@@ -79,9 +90,16 @@ severity:
 
 Типовая вкусовщина в выводах generative-проходов: переименования без коллизии,
 перестановка функций, «лучше вынести в отдельный файл», предложения обобщить
-работающий частный случай. Отдельный класс — предложение «нормализовать» то, что
-инвариант проекта велит хранить дословно: это не просто вкусовщина, а нарушение
-инварианта, и выбрасывать его надо с пометкой почему.
+работающий частный случай.
+
+**Проектный вход сюда один — раздел `## Типовые ложноположительные` брифа.**
+Там перечислены находки, которые в этом проекте выглядят убедительно и всегда
+неверны: они выбрасываются со ссылкой на пункт и с пометкой почему, а не
+«смягчаются». Классический обитатель раздела — предложение «нормализовать» то,
+что инвариант велит хранить дословно: это не просто вкусовщина, а находка,
+предлагающая нарушить инвариант. Раздела нет или он пуст — скажи об этом строкой
+в границах покрытия: отсев шёл по общим критериям, проектных ложноположительных
+ты не знал.
 
 ### 5. Ранжирование по ущербу × вероятности
 
@@ -121,8 +139,7 @@ severity:
 Сводка отчёта называет **каждый проход профиля** и его исход: отработал (сколько
 находок) / не запускался (почему). Сверь список запущенного с составом профиля
 сам, а не доверяй тому, что тебе подали: пропуск прохода **не отличим от прохода
-без находок**, и однажды это стоило семи находок и отдельной задачи на их
-дозакрытие.
+без находок**, и назвать его больше некому.
 
 Расхождение состава с профилем — это находка о прогоне, и она идёт в сводку
 первой строкой, а не растворяется в границах покрытия.
@@ -135,12 +152,16 @@ severity:
 - какие **не** запускались и почему (профиль, бюджет, недоступный инструмент,
   остановленный прогон);
 - что каждый запущенный проход **не мог проверить в принципе** — из его charter'а;
-- **что осталось целиком на человеке** — раздел `## Недоступно проверке` брифа
-  целиком, плюс: история инцидентов, поведение под реальным потоком, поведение
-  внешних систем в их версиях, завязка потребителей на текущее поведение и вопрос
-  «а нужна ли эта функциональность вообще»;
-- если брифа не было — строку об этом: инварианты, модель угроз и профиль
-  нагрузки прогону были неизвестны.
+- **что осталось целиком на человеке** — раздел `## Недоступно проверке` брифа,
+  **двумя отдельными списками**: «не проверит ни один проход» и «перестали
+  проверять сознательно». Слитый список бесполезен: при следующем промахе первый
+  вопрос — «не тот ли это класс, который мы перестали проверять», и ответить на
+  него можно только если второй список виден отдельно. Плюс общее: история
+  инцидентов, поведение под реальным потоком, поведение внешних систем в их
+  версиях, завязка потребителей на текущее поведение и вопрос «а нужна ли эта
+  функциональность вообще»;
+- если брифа не было — строку об этом **с причиной**: инварианты, модель угроз и
+  профиль нагрузки прогону были неизвестны, потому что <причина>.
 
 Формулировка «критичных проблем не обнаружено» **запрещена** без этой секции: она
 потребляет ощущение проверенности, ничего не гарантируя, и это хуже, чем