Files
dev-skills/av-dev-pipeline/skills/review-pipeline/references/project-facts.md
T
avandClaude Opus 5 4386eb3e1c шов между плагинами: канон перестал называть имена проходов
av-dev-pm и av-dev-pipeline раздельны: канон работает без конвейера, конвейер без
канона — поразрядно деградируя и называя это строкой. Но канон в шести местах
называл конвейер поимённо, и одно из них — вывод docs.py пользователю: «свои темы
проекта: … — их разбирает review-basics». Такая строка чинится не правкой файла,
а недоумением на чужом проекте.

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

Что вычищено: имя review-basics в canon.md, в changelog версии 5 и в выводе
docs.py; «её берёт basics» из таблицы ролей; описательные адресации того же
класса — «архитектурный проход судит», «враждебный проход выдумает». Худшей была
строка в skeletons.md «там идут враждебный, эксплуатационный и архитектурный
проходы»: утверждение о составе ступени, живущее на стороне, которая о составе не
знает. Строка таблицы «эксплуатационный проход ревью» стала «тема ревью
operations» — заодно совпала со словарём, к которому tasks/SKILL.md отсылает как
к единому дому.

Отдельно — пример, нарушавший собственное правило. Объяснение, почему вопросы
адресуются темам, звучало «вопрос, адресованный ops, перестал задаваться в тот
день, когда ops уехал в верхнюю ступень»: правило про нестабильность имён,
проиллюстрированное именем. Стало «адресованный проходу» и переживёт
переименование.

Починена и висячая ссылка: project-facts.md отсылал к таблице «Кто читает» в
каноне, которой там нет — она была убрана правкой, вводившей темы, и по новому
правилу её и не должно быть. Списка читателей не ведёт никто: читателя назначает
план прогона.

Тема 38 в DECISIONS.md, следствия 143-144.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-07 08:57:09 +03:00

12 KiB
Raw Blame History

Откуда проход берёт проектную конкретику

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

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

Определение канона — в плагине av-dev-pm, skills/canon/references/canon.md. Здесь только карта «тема → её дом → что оттуда берётся».

Карта тем

Дом бывает файлом или каталогомdocs/security.md и docs/security/ называют одну и ту же тему. Форму дома называет план разметчика; проход её не угадывает.

Тема Дом Что оттуда берётся
requirements openspec/specs/, openspec/changes/<id>/specs/ нормативное поведение и дельты изменения
autotests CLAUDE.md, семантика гейта команда гейта, чем краснеет безусловно, чего в нём нет, кто гоняет дорогое
conventions docs/conventions.* конвенции прозой и что уже механизировано правилом
architecture docs/architecture.* компоненты и capability, единые точки проекта
docs/passport.* что система делает и чего не делает, граница домена
docs/adr/ почему решено так, отвергнутые варианты
security docs/security.* периметр, недоверенный вход, из чего строятся пути и ключи, что вне модели
operations docs/architecture.*, раздел эксплуатации окружение, внешние зависимости поимённо, наблюдатель, характер потока
docs/database.* чем физически лежит запись, что при чтении и записи, настройки с числовым значением
docs/research/ измеренные числа с провенансом, поведение внешних систем на самом деле
тема проекта её документ в docs/ то, что проект счёл нужным записать

Сквозное, не привязанное к теме:

Что нужно проходу Где лежит
инварианты с severity рядом с формулировкой CLAUDE.mdAGENTS.md, если он рядом), раздел инвариантов
что запускать запрещено, с путями; testdata; куда писать временное; имя основной ветки CLAUDE.md
типовые узлы, типовые ложноположительные, вопросы по темам, триггеры профиля, недоступно проверке docs/review.*, раздел настройки
прецеденты: воспроизведённые дефекты с оракулом docs/review.*, журнал

Вопросы проекта привязаны к теме, а не к имени прохода. Раньше блок в docs/review.md адресовался поимённо (ops: <вопрос>), и когда проход уехал в верхнюю ступень, вопрос перестал задаваться молча. Тема переезд прохода переживает.

Сшивать обязаны проходы

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

Два обязательных стыка:

  • замер + настройка. «Пик 768 МиБ» — аномалия только рядом со строкой «запись лежит сжатой и распаковывается целиком»; «блокировка удерживалась 5.019 с» — гарантированный отказ соседа только рядом с известным таймаутом занятости. Числа в docs/research/, настройки в docs/database.md, и оба читает ops и adversary.
  • инвариант + обратимость. severity берётся из CLAUDE.md; если её там нет — она выводится по обратимости последствия и помечается «выведена по обратимости», а не выдаётся за решение проекта.

У basics стыков нет, и это не упущение. Он не меряет, поэтому сшивать число с настройкой ему нечего; единственное его основание для critical — инвариант из CLAUDE.md, всё остальное он формулирует условиями и оставляет гипотезой. Его вход намеренно узкий: дома тем из плана плюс инварианты и журнал. Широкий вход — это профиль wide, и там он есть у architecture.

У scope стыков нет по другой причине: он не читает содержимого. Его дело — найти дома и раздать темы, а не пересказать написанное. Пересказ сделал бы его посредником между документом и проходом, а посредник расходится с источником и при этом выглядит актуальным.

Деградация — поразрядная

Документа нет — деградирует то, что из него читалось, и только оно. Каждый проход пишет свою строку в границы покрытия; триаж собирает их в один список и не сливает в одну строку: разные пробелы чинятся разным — периметр пишется руками за десять минут, а числа требуют замера.

Кто какой документ читает — из документа не выводится, а назначается планом. Документ питает тему (это записано на стороне канона, таблица «Роли документов и темы ревью»), а тему на этом прогоне закрывает тот, кого назвал разметчик; вся раскладка «тема → проход → глубина» — в SKILL.md этого скилла и больше нигде. Списка читателей не ведёт никто, и это не пробел. Он жил бы на стороне канона, а документ живёт дольше, чем раскладка проходов: список разошёлся бы с конвейером молча и при этом выглядел актуальным. Однажды уже разошёлся.

Ниже — только последствие отсутствия дома, и оно называет самое дорогое, а не всех пострадавших.

Нет дома Что деградирует
CLAUDE.md без инвариантов critical по основанию «нарушен инвариант проекта» не присваивается никем
docs/security.* тема security остаётся без дома: вопросы задаются по коду, critical не ставится, периметр неизвестен
docs/research/ числа неизвестны темам operations и requirements — формулируют условиями, а specs теряет проверку «требование против наблюдения»
docs/database.* замер не с чем сравнить: находка темы operations не поднимается выше гипотезы
docs/passport.* тема architecture теряет границу домена и вырождается в общее мнение
docs/adr/ «не отменяет ли изменение записанное решение» не спрашивает никто
docs/review.* triage отсеивает вслепую: типовых ложноположительных нет; вопросы проекта по темам не задаются
docs/conventions.* вторая половина code идёт вхолостую: записанных конвенций нет
docs/architecture.* «не появился ли второй способ» не проверяется — единых точек не знает никто; тема operations теряет перечень внешних зависимостей

Строка в границах покрытия обязана называть причину: «docs/security.md в проекте нет» читается иначе, чем «есть, но периметр не назван». Без причины строка неотличима от «мы просто не стали» и перестаёт читаться на третьей задаче.

Документов канона нет вовсе — проект не приведён к канону. Это не повод работать вслепую: скажи об этом строкой и предложи av-dev-pm:canon. Одна операция на проект против деградации на каждой задаче.

Правило чтения

  • Читай в источнике, не по памяти. Документы правятся по ходу работы, в том числе этой же задачей.
  • Число без провенанса — условие, а не утверждение. Число, чей источник по ссылке не подтвердился, читается как условие и называется расходящимся, а не подменяется догадкой.
  • Пустое, названное пустым, — это факт. «Внешних зависимостей нет — смотри на диск и на СУБД» экономит обязательный вопрос. Отсутствие строки — не факт, а пробел, и его надо назвать в границах покрытия.
  • Свойство, ставшее правилом линтера, из конвенций удалено и лежит в перечне механизированного в docs/conventions/README.md. Проверять его проходом — тратить внимание на уже проверенное.