From 91d4264b405e5622334c0022ce6b6fc6c04f07ed Mon Sep 17 00:00:00 2001 From: Anton Vakhrushev Date: Fri, 7 Aug 2026 11:40:09 +0300 Subject: [PATCH] =?UTF-8?q?=D0=BF=D1=80=D0=B0=D0=B2=D0=B8=D0=BB=D0=BE=20?= =?UTF-8?q?=D0=B2=D1=8B=D0=B1=D0=BE=D1=80=D0=B0=20=D0=BC=D0=B5=D1=82=D0=BA?= =?UTF-8?q?=D0=B8=20=D1=83=D0=B5=D1=85=D0=B0=D0=BB=D0=BE=20=D0=B2=20=D1=81?= =?UTF-8?q?=D0=B2=D0=BE=D0=B9=20=D0=B4=D0=BE=D0=BA=D1=83=D0=BC=D0=B5=D0=BD?= =?UTF-8?q?=D1=82,=20=D0=B2=20=D1=81=D0=BA=D0=B8=D0=BB=D0=BB=D0=B5=20?= =?UTF-8?q?=D0=BE=D1=81=D1=82=D0=B0=D0=BB=D1=81=D1=8F=20=D0=B4=D0=B8=D1=81?= =?UTF-8?q?=D0=BF=D0=B5=D1=82=D1=87=D0=B5=D1=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit SKILL.md конвейера дорос до 1168 строк, и двести с лишним из них отвечали на вопрос, который на обычной задаче не задаётся: как выбирается метка. Называет её review-scope один раз, до обеих стадий, а всем остальным нужна не процедура выбора, а состав по уже названной метке — три строки таблицы. В references/review-levels.md переехали правило двух осей, «спорное решается вниз», «максимум по поверхности», разбор того, чем small дешевле medium, и обе проверки долей. В скилле остались таблица состава, схема процесса и раздача тем: метка названа — состав читается. Форма выбрана одна на все метки, а не по документу на метку, как у типов задач в av-dev-pm:tasks. Аналогия не переносится дважды. Типы задач разъединены — общее лежит в task-format.md, в файле типа только своё; метки вложены: medium это small плюс два прохода, large — medium плюс доказательство, и три файла повторяли бы костяк трижды. Такое расхождение copies.py не ловит: он сверяет дословные копии по маркерам, а вышли бы почти-копии с намеренными мелкими отличиями, неотличимые от задуманного. Причина сильнее: ценность текста в сравнении. Вопрос читателя не «что делает small», а «чем small отличается от medium» — на него отвечают и выбор метки, и «спорное вниз», и корректор; сравнение, разложенное по трём файлам, не читается. Механика рычагов осталась в скилле. Непуск, вход и потолок общие для всех проходов и всех меток, их дом — «Модель по проходу»; в переехавшем тексте от них только то, что они делают с small, и ссылка на дом. Точные потолки не продублированы, чтобы не заводить второй источник чисел. Ссылку на дом правила получили review-scope, для которого он основная опора, и task-pipeline, где раньше стояло безадресное «правило живёт в скилле конвейера». Заодно вычищено последнее живое упоминание quick и standard: имена удалены каноном 6, но уцелели в объяснении, зачем нужна проверка доли. Решение — 46. SKILL.md: 1168 → 1026 строк. Co-Authored-By: Claude Opus 5 (1M context) --- DECISIONS.md | 39 +++++ av-dev-pipeline/agents/review-scope.md | 5 + .../skills/review-pipeline/SKILL.md | 158 +---------------- .../references/review-levels.md | 165 ++++++++++++++++++ av-dev-pipeline/skills/task-pipeline/SKILL.md | 5 +- 5 files changed, 220 insertions(+), 152 deletions(-) create mode 100644 av-dev-pipeline/skills/review-pipeline/references/review-levels.md diff --git a/DECISIONS.md b/DECISIONS.md index afbfcbf..d0ba774 100644 --- a/DECISIONS.md +++ b/DECISIONS.md @@ -2992,3 +2992,42 @@ JJJ): у профиля обязан быть один правильный от 164. **Оценка по одному источнику — оценка по остатку.** Источники о задаче отвечают на разные вопросы; пропущенный не ухудшает точность понемногу, а оставляет ось без данных. + +## 46. Правило выбора метки съехало из скилла в отдельный документ (2026-08-07) + +**АЕАЗА. У правила выбора метки теперь свой дом — `references/review-levels.md`, +а в скилле остался диспетчер.** `SKILL.md` конвейера дорос до 1168 строк, и +двести с лишним из них отвечали на вопрос, который на обычной задаче не задаётся +вовсе: **как** выбирается метка. Метку называет `review-scope` один раз, до обеих +стадий; всем остальным нужна не она, а состав по уже названной метке — три строки +таблицы. Переехали правило двух осей, «спорное решается вниз», «максимум по +поверхности», разбор того, чем `small` дешевле `medium`, и обе проверки долей. +Остались таблица состава, схема процесса и раздача тем. + +**Форма выбрана одна на все метки, а не по документу на метку.** Предлагался +разрез по образцу типов задач в `av-dev-pm:tasks`, где у `fix`, `feature` и +`chore` по своему файлу. Аналогия не переносится, и по двум причинам. Типы задач +**разъединены** — общее вынесено в `task-format.md`, а в файле типа лежит только +своё; метки же **вложены**: `medium` это `small` плюс два прохода, `large` — +`medium` плюс доказательство. Три файла повторяли бы костяк трижды, а `copies.py` +такое не ловит: он сверяет дословные копии по маркерам, тогда как здесь вышли бы +почти-копии с намеренными мелкими отличиями — расхождение, неотличимое от +задуманного. Вторая причина сильнее первой: ценность этого текста **в +сравнении**. Читателю нужно не «что делает `small`», а «чем `small` отличается от +`medium`» — на этот вопрос отвечают и выбор метки, и «спорное вниз», и корректор. +Сравнение, разложенное по трём файлам, не читается. + +**Механика рычагов осталась в скилле, а не уехала с меткой.** Непуск, вход и +потолок общие для всех проходов и всех меток, их дом — раздел «Модель по +проходу». В переехавшем тексте от них только то, что они делают с `small`, и +ссылка на дом; точные потолки не продублированы. + +### Что из этого следует + +165. **Дом правила — там, где правило выбирают, а не там, где его применяют.** + Применяют состав на каждой задаче, выбирают метку один раз; текст, + обслуживающий выбор, в потоке применения лежит мёртвым грузом. +166. **Вложенные вещи не режутся по файлу на вещь.** Разъединённое (типы задач) + режется, вложенное (метки) — нет: разрез вложенного даёт дублирование + общей части, а дублирование намеренно неточное машина не сверит. + diff --git a/av-dev-pipeline/agents/review-scope.md b/av-dev-pipeline/agents/review-scope.md index bd0706f..aa3f19f 100644 --- a/av-dev-pipeline/agents/review-scope.md +++ b/av-dev-pipeline/agents/review-scope.md @@ -186,6 +186,11 @@ color: green **Ты меряешь изменение по двум независимым осям и называешь обе.** Метка — не ответ на один вопрос, а максимум по двум измерениям. +Ниже рабочая выжимка. Дом правила — скилл `av-dev-pipeline:review-pipeline`, +`references/review-levels.md`: там разобрано, почему оси именно эти, чем `small` +дешевле `medium` и какие доли служат проверкой правила. Открывай его, когда +метка **спорная или оспорена**; на обычной задаче хватает того, что здесь. + **Ось «размер» — про объём: сколько мест трогается.** - **малое** — помещается в один узел; diff --git a/av-dev-pipeline/skills/review-pipeline/SKILL.md b/av-dev-pipeline/skills/review-pipeline/SKILL.md index 36f1ebf..9178449 100644 --- a/av-dev-pipeline/skills/review-pipeline/SKILL.md +++ b/av-dev-pipeline/skills/review-pipeline/SKILL.md @@ -373,61 +373,17 @@ flowchart TD отвечал на тот же вопрос сам — то есть о размере изменения судили дважды и в одном из двух мест без разведённости с автором. -**`small` дешевле `medium` тремя разными способами сразу, и каждый назван.** - -1. **Составом.** `basics` на `small` не запускается — кроме случая, когда у - проекта есть свои темы; тогда он идёт **только с ними**, ровно как в `large`. - Три темы ядра, которые он держал бы, переходят к `code` сверкой по - инвариантам. -2. **Входом.** На `small` `specs` читает только дельта-спеку, а `code` — только - **индекс** конвенций (перечень родов и что механизировано), не весь их дом. На - `medium` оба читают дома целиком. -3. **Потолком.** На `small` потолки жёсткие и напечатаны: `specs` — 3 находки, - `code` — 3 технических плюс 2 конвенционных плюс 1 по трём темам ядра. - -**Что `small` за это не проверяет, названо поимённо и обязано идти строкой в -границы покрытия:** темы `security`, `operations` и `architecture` смотрятся -только против **записанных инвариантов** `CLAUDE.md`. Свойство, которого в -инвариантах нет, с этой меткой не спросит никто — ни сценарием, ни чтением -дома темы. Это и есть цена метки, и она заметно больше прежней: раньше `small` -отличался от `medium` одним проходом на один вопрос, то есть не экономил -ничего и назывался отдельной меткой зря. - **Три глубины, и они не про старательность, а про способ доказательства.** **Сверка** — открыть дом темы, открыть дифф, сравнить. **Разбор** — построить сценарий рассуждением, ничего не запуская. **Доказательство** — прогнать, померить, построить путь. Только третья требует машины, и только она стоит часов. -**`large` назван по тому, что он добавляет: вход шире диффа.** Он единственный, где -живут тяжёлые проходы, и единственный, где что-то **запускается**. `basics` в нём -берёт только проектные темы; своих тем у проекта нет — он не запускается вовсе, и -план говорит об этом строкой. **На `small` действует то же правило и по той же -причине** — приёмник запускается только тогда, когда ему есть что принимать. -Совпадение неслучайное: `basics` держит темы ядра ровно при одной метке из трёх, -а приёмником проектных тем работает на всех. - -**Доли — не пожелание, а проверка правила, и проверок теперь две.** - -**Сверху: `large` — 5–10%.** Если туда уходит каждая третья задача, метку -выбирают по ощущению важности. Обратный перекос виден по журналу проскочивших -дефектов: класс, который ловят только меряющие проходы, начинает всплывать после -мерджа. - -**Снизу: `small` не должен обгонять `medium`.** Ориентир — до трети задач, но -сравнение важнее числа: **перевес `small` над `medium` значит, что рабочее -умолчание сместилось, а решения об этом никто не принимал.** Проверка нужна -именно теперь: пока `quick` и `standard` совпадали составом, дрейф между ними не -стоил ничего, и её не было. Сейчас он стоит трёх тем ядра, которые на `small` -смотрятся только против инвариантов, — то есть ровно того, чем `small` и дёшев. - -Считается это по журналу дефектов и по отчётам, а не по ощущению: метка -напечатана в каждом отчёте, и посчитать её за спринт — работа на минуту. - -**У дрейфа вниз есть свой стимул, и его стоит назвать.** `small` дешевле по -времени и по деньгам, а выбирает метку хоть и не автор, но проход, читающий -описание, написанное автором. Занижённое описание даёт занижённую метку без -чьего-либо злого умысла — потому корректор и вынесен в `code`, который смотрит -уже на код, а не на описание. +**Здесь диспетчер и кончается: метка названа — состав читается.** Само правило +выбора — две оси, «спорное решается вниз», максимум по поверхности, — а с ним +разбор того, чем именно `small` дешевле `medium` и почему доли служат проверкой +правила, живут в [references/review-levels.md](references/review-levels.md). Тот +файл открывают, когда метку **выбирают, оспаривают или калибруют**; его +единственный постоянный читатель — `review-scope`. **Состав сверяется до коммита — по плану разметки задачи, а не по этой таблице.** План и есть реестр: тема, дом, глубина, кто закрывает. Это единственная защита от @@ -437,106 +393,6 @@ flowchart TD запускался» с причиной, а не отсутствует. Цена молчащего пропуска измерена: семь находок и отдельная задача на их дозакрытие. -### Правило выбора — две оси, а не один вопрос - -Дом правила здесь, а применяет его `review-scope` при разметке задачи — не автор -изменения. **Оси две, они измеряют разное, и метка есть максимум по ним.** - -| | **знакомое** — форму решения можно назвать до начала | **незнакомое** — форму предстоит нащупать по ходу | -|---|---|---| -| **малое** — один узел | `small` | `large` | -| **среднее** — несколько узлов одного слоя | `medium` | `large` | -| **крупное** — несколько слоёв, перенос ответственности, большой рефакторинг | `large` | `large` | - -**Метка — не синоним размера.** Совпадают они только в левом верхнем углу: малое -**незнакомое** изменение получает `large`, трогая один узел. Поэтому в плане -стоят три строки, а не одна: размер, сложность и метка — каждая со своим -обоснованием. Проход, выведший объём диффа из метки, ошибётся ровно на этом -случае — а он и есть самый опасный: незнакомая форма в одном узле течёт там, где -её никто не ждёт. - -**Размер** — про объём: сколько мест трогается. **Сложность** — про -неизвестность: знаем ли мы форму решения заранее. Признак незнакомого простой и -проверяемый: **перед работой нельзя назвать, какие узлы будут тронуты**. - -Раньше обе оси были склеены в один вопрос «крупное **или** незнакомое?». Ответ -получался тот же, но две вещи под одним именем не измеришь по отдельности, и -потому разметка не могла сказать «изменение среднее, но совершенно знакомое» — -а именно эта пара и есть рабочее умолчание. Теперь обе оси называются в плане -поимённо, и обе — с обоснованием. - -**Оси называются и на стадии дизайна, и на стадии кода — но считаются один -раз.** Это и есть причина, по которой разметка переехала к `propose`: состав -ревью дизайна выводится из той же пары, что и состав ревью кода, а считать её -дважды значит один раз посчитать без разведённости с автором. - -**Обратимость — не третья ось, а отрицательный тест.** Она не уточняет размер и -не уточняет сложность: она запрещает нижнюю метка независимо от обеих. - -**Отрицательный тест `small`, и он важнее положительного:** изменение, которое -после мерджа **не откатывается обратной правкой**, — не `small`, каким бы -маленьким ни был дифф. Сюда попадают миграция схемы и данных, формат на диске, -публичный контракт, имя, которое разойдётся по кодовой базе. Три строки миграции -— это `medium`, а не `small`: размер диффа и цена ошибки здесь расходятся. - -Что здесь считается крупным, что — незнакомым и что — мелким, проект уточняет в -`docs/review.md`, подразделе «Триггеры метки»: **тремя списками** — по одному на -каждую ось вверх и один вниз, поимённо, узлами или capability. Это **уточнение**, -а не отмена: не записано — работает таблица выше. - -### Спорный случай решается вниз, и у этого есть цена - -Правило асимметрично, потому что асимметрична цена ошибки. - -- **Спорно между `medium` и `large` → бери `medium`.** Ошибка в эту сторону - стоит находки, которая всплывёт на следующей задаче или в журнале дефектов. - Ошибка в обратную стоит трёх тяжёлых проходов, двое из которых держат машину и - идут цепочкой, — и платится она **на каждой** задаче, выбранной неверно. -- **Спорно между `small` и `medium` → бери `medium`.** Раньше эта строка - обосновывалась тем, что состав одинаков и ошибка почти бесплатна. Теперь состав - разный, и обоснование стало прямо противоположным: на `small` три темы ядра - смотрятся **только против записанных инвариантов**, а спорный случай — ровно тот, - где неизвестно, покрыт ли он инвариантом. Сомнение здесь стоит дороже, чем - раньше, и потому решается вниз тем более твёрдо. - -**Выбор сделан в пользу пропускной способности, и это записано, а не подразумевается.** -Конвейер настроен на поток задач, а не на максимум находок с каждой: поправить в -следующей задаче дешевле, чем держать одну два часа. Отсюда три обязанности, -без которых сделка превращается в незаметную потерю качества: - -- **границы покрытия называют темы и их глубину**, а не только запущенные - проходы — иначе `small` выглядит так же, как `large` без находок; -- **журнал дефектов в `docs/review.md` перестаёт быть хорошей практикой и - становится единственной обратной связью**: проскочивший дефект — единственный - сигнал, что метка выбрана слишком низко; -- **возврат в код — повод пересмотреть метку.** Задача, которая приходит в тот - же узел третий раз, уже не мелкая, чем бы ни выглядел её дифф. - -### Метка — максимум по поверхности - -**Обе оси меряются по всему диффу разом, и максимум по каждой отвечает за весь -дифф.** Метка изменения — не средневзвешенное: одна строка в перечне границ -задачи поднимает метку всему остальному, включая ту часть, которая сама по себе -была бы `small`. - -Обратное тоже верно и тоже не бесплатно: у каждой задачи есть **несокращаемый -костяк — гейт, спеки, код, триаж**. Разрезать задачу, обе половины которой -остаются в одной метке, значит заплатить костяк дважды за ту же проверку. -Резать стоит там, где разрез **снимает доказательство с большей части диффа**. -Шов и правило нарезки живут у того, кто ведёт задачи, — скилл `av-dev-pm:tasks`, -его `references/split.md`. Пути туда конвейер не выносит: за пределы своего -плагина он ходит вызовом скилла, а не файлом. - -Разметка в костяк не входит — она платится один раз на задачу, а не один раз на -прогон, и потому **разрез задачи её не удваивает**. Это единственное, что стало -дешевле от переезда разметки к `propose`, и это же снимает прежний довод против -нарезки. - -**Размер, сложность, метка и глубина объявляются в отчёте, и все четыре с -обоснованием.** Метка выбирает `review-scope`; он вправе и поднять, и понизить -её — но не молча: строка «метка X, потому что размер Y и сложность Z» -обязательна на каждом прогоне, а не только когда метка отличается от ожидаемой. - ## Порядок прогона — граф, а не очередь Метка отвечает «какие темы и на какой глубине», порядок — «что кого ждёт». @@ -1161,6 +1017,8 @@ flowchart TD - [references/project-facts.md](references/project-facts.md) — что нужно проходу и где это лежит в документах проекта; таблица поразрядной деградации. +- [references/review-levels.md](references/review-levels.md) — дом правила выбора + метки: две оси, спорное вниз, чем `small` дешевле, доли как проверка правила. - Skill `av-dev-pm:canon` — приведение проекта к канону документов. - [references/finding-contract.md](references/finding-contract.md) — контракт находок. - [references/promote.md](references/promote.md) — промоут находка → конвенция → правило → удаление. diff --git a/av-dev-pipeline/skills/review-pipeline/references/review-levels.md b/av-dev-pipeline/skills/review-pipeline/references/review-levels.md new file mode 100644 index 0000000..193225d --- /dev/null +++ b/av-dev-pipeline/skills/review-pipeline/references/review-levels.md @@ -0,0 +1,165 @@ +# Метки задачи — выбор, цена, доли + +**Дом правила выбора метки.** Состав проходов по каждой метке, схема процесса и +раздача тем живут в [SKILL.md](../SKILL.md) — там диспетчер, и на готовой задаче +его достаточно. Здесь то, что читают, когда метку **выбирают, оспаривают или +калибруют**. + +Применяет правило `review-scope` при разметке задачи — не автор изменения. Его +рабочая выжимка лежит в уставе агента; расходиться она с этим файлом не вправе, а +при расхождении прав этот. + +## Правило выбора — две оси, а не один вопрос + +**Оси две, они измеряют разное, и метка есть максимум по ним.** + +| | **знакомое** — форму решения можно назвать до начала | **незнакомое** — форму предстоит нащупать по ходу | +|---|---|---| +| **малое** — один узел | `small` | `large` | +| **среднее** — несколько узлов одного слоя | `medium` | `large` | +| **крупное** — несколько слоёв, перенос ответственности, большой рефакторинг | `large` | `large` | + +**Метка — не синоним размера.** Совпадают они только в левом верхнем углу: малое +**незнакомое** изменение получает `large`, трогая один узел. Поэтому в плане +стоят три строки, а не одна: размер, сложность и метка — каждая со своим +обоснованием. Проход, выведший объём диффа из метки, ошибётся ровно на этом +случае — а он и есть самый опасный: незнакомая форма в одном узле течёт там, где +её никто не ждёт. + +**Размер** — про объём: сколько мест трогается. **Сложность** — про +неизвестность: знаем ли мы форму решения заранее. Признак незнакомого простой и +проверяемый: **перед работой нельзя назвать, какие узлы будут тронуты**. + +Раньше обе оси были склеены в один вопрос «крупное **или** незнакомое?». Ответ +получался тот же, но две вещи под одним именем не измеришь по отдельности, и +потому разметка не могла сказать «изменение среднее, но совершенно знакомое» — +а именно эта пара и есть рабочее умолчание. Теперь обе оси называются в плане +поимённо, и обе — с обоснованием. + +**Оси называются и на стадии дизайна, и на стадии кода — но считаются один +раз.** Это и есть причина, по которой разметка переехала к `propose`: состав +ревью дизайна выводится из той же пары, что и состав ревью кода, а считать её +дважды значит один раз посчитать без разведённости с автором. + +**Обратимость — не третья ось, а отрицательный тест.** Она не уточняет размер и +не уточняет сложность: она запрещает нижнюю метку независимо от обеих. + +**Отрицательный тест `small`, и он важнее положительного:** изменение, которое +после мерджа **не откатывается обратной правкой**, — не `small`, каким бы +маленьким ни был дифф. Сюда попадают миграция схемы и данных, формат на диске, +публичный контракт, имя, которое разойдётся по кодовой базе. Три строки миграции +— это `medium`, а не `small`: размер диффа и цена ошибки здесь расходятся. + +Что здесь считается крупным, что — незнакомым и что — мелким, проект уточняет в +`docs/review.md`, подразделе «Триггеры метки»: **тремя списками** — по одному на +каждую ось вверх и один вниз, поимённо, узлами или capability. Это **уточнение**, +а не отмена: не записано — работает таблица выше. + +## Спорный случай решается вниз, и у этого есть цена + +Правило асимметрично, потому что асимметрична цена ошибки. + +- **Спорно между `medium` и `large` → бери `medium`.** Ошибка в эту сторону + стоит находки, которая всплывёт на следующей задаче или в журнале дефектов. + Ошибка в обратную стоит трёх тяжёлых проходов, двое из которых держат машину и + идут цепочкой, — и платится она **на каждой** задаче, выбранной неверно. +- **Спорно между `small` и `medium` → бери `medium`.** Раньше эта строка + обосновывалась тем, что состав одинаков и ошибка почти бесплатна. Теперь состав + разный, и обоснование стало прямо противоположным: на `small` три темы ядра + смотрятся **только против записанных инвариантов**, а спорный случай — ровно тот, + где неизвестно, покрыт ли он инвариантом. Сомнение здесь стоит дороже, чем + раньше, и потому решается вниз тем более твёрдо. + +**Выбор сделан в пользу пропускной способности, и это записано, а не подразумевается.** +Конвейер настроен на поток задач, а не на максимум находок с каждой: поправить в +следующей задаче дешевле, чем держать одну два часа. Отсюда три обязанности, +без которых сделка превращается в незаметную потерю качества: + +- **границы покрытия называют темы и их глубину**, а не только запущенные + проходы — иначе `small` выглядит так же, как `large` без находок; +- **журнал дефектов в `docs/review.md` перестаёт быть хорошей практикой и + становится единственной обратной связью**: проскочивший дефект — единственный + сигнал, что метка выбрана слишком низко; +- **возврат в код — повод пересмотреть метку.** Задача, которая приходит в тот + же узел третий раз, уже не мелкая, чем бы ни выглядел её дифф. + +## Метка — максимум по поверхности + +**Обе оси меряются по всему диффу разом, и максимум по каждой отвечает за весь +дифф.** Метка изменения — не средневзвешенное: одна строка в перечне границ +задачи поднимает метку всему остальному, включая ту часть, которая сама по себе +была бы `small`. + +Обратное тоже верно и тоже не бесплатно: у каждой задачи есть **несокращаемый +костяк — гейт, спеки, код, триаж**. Разрезать задачу, обе половины которой +остаются в одной метке, значит заплатить костяк дважды за ту же проверку. +Резать стоит там, где разрез **снимает доказательство с большей части диффа**. +Шов и правило нарезки живут у того, кто ведёт задачи, — скилл `av-dev-pm:tasks`, +его `references/split.md`. Пути туда конвейер не выносит: за пределы своего +плагина он ходит вызовом скилла, а не файлом. + +Разметка в костяк не входит — она платится один раз на задачу, а не один раз на +прогон, и потому **разрез задачи её не удваивает**. Это единственное, что стало +дешевле от переезда разметки к `propose`, и это же снимает прежний довод против +нарезки. + +**Размер, сложность, метка и глубина объявляются в отчёте, и все четыре с +обоснованием.** Метка выбирает `review-scope`; он вправе и поднять, и понизить +её — но не молча: строка «метка X, потому что размер Y и сложность Z» +обязательна на каждом прогоне, а не только когда метка отличается от ожидаемой. + +## Чем `small` дешевле `medium` и что это стоит + +Экономят три рычага — непуск, вход, потолок, — и они общие для всех проходов и +всех меток; их дом и точные числа в [SKILL.md](../SKILL.md), раздел «Модель по +проходу». Здесь только то, что рычаги делают **с этой меткой**: + +1. **Составом.** `basics` на `small` не запускается — кроме случая, когда у + проекта есть свои темы; тогда он идёт **только с ними**, ровно как в `large`. + Три темы ядра, которые он держал бы, переходят к `code` сверкой по + инвариантам. +2. **Входом.** На `small` `specs` читает только дельта-спеку, а `code` — только + **индекс** конвенций (перечень родов и что механизировано), не весь их дом. На + `medium` оба читают дома целиком. +3. **Потолком.** На `small` потолки самые жёсткие из трёх меток, и каждый + напечатан в границах покрытия своего прохода. + +**Что `small` за это не проверяет, названо поимённо и обязано идти строкой в +границы покрытия:** темы `security`, `operations` и `architecture` смотрятся +только против **записанных инвариантов** `CLAUDE.md`. Свойство, которого в +инвариантах нет, с этой меткой не спросит никто — ни сценарием, ни чтением +дома темы. Это и есть цена метки, и она заметно больше прежней: раньше `small` +отличался от `medium` одним проходом на один вопрос, то есть не экономил +ничего и назывался отдельной меткой зря. + +**`large` назван по тому, что он добавляет: вход шире диффа.** Он единственный, где +живут тяжёлые проходы, и единственный, где что-то **запускается**. `basics` в нём +берёт только проектные темы; своих тем у проекта нет — он не запускается вовсе, и +план говорит об этом строкой. **На `small` действует то же правило и по той же +причине** — приёмник запускается только тогда, когда ему есть что принимать. +Совпадение неслучайное: `basics` держит темы ядра ровно при одной метке из трёх, +а приёмником проектных тем работает на всех. + +## Доли — не пожелание, а проверка правила, и проверок две + +**Сверху: `large` — 5–10%.** Если туда уходит каждая третья задача, метку +выбирают по ощущению важности. Обратный перекос виден по журналу проскочивших +дефектов: класс, который ловят только меряющие проходы, начинает всплывать после +мерджа. + +**Снизу: `small` не должен обгонять `medium`.** Ориентир — до трети задач, но +сравнение важнее числа: **перевес `small` над `medium` значит, что рабочее +умолчание сместилось, а решения об этом никто не принимал.** Проверка нужна +именно теперь: пока две нижние метки совпадали составом, дрейф между ними не +стоил ничего, и проверки не было. Сейчас он стоит трёх тем ядра, которые на +`small` смотрятся только против инвариантов, — то есть ровно того, чем `small` и +дёшев. + +Считается это по журналу дефектов и по отчётам, а не по ощущению: метка +напечатана в каждом отчёте, и посчитать её за спринт — работа на минуту. + +**У дрейфа вниз есть свой стимул, и его стоит назвать.** `small` дешевле по +времени и по деньгам, а выбирает метку хоть и не автор, но проход, читающий +описание, написанное автором. Занижённое описание даёт занижённую метку без +чьего-либо злого умысла — потому корректор и вынесен в `code`, который смотрит +уже на код, а не на описание. diff --git a/av-dev-pipeline/skills/task-pipeline/SKILL.md b/av-dev-pipeline/skills/task-pipeline/SKILL.md index baddf69..a57cab6 100644 --- a/av-dev-pipeline/skills/task-pipeline/SKILL.md +++ b/av-dev-pipeline/skills/task-pipeline/SKILL.md @@ -317,8 +317,9 @@ change ``, **план разметки с шага 4** и указание, `review-scope` ещё на шаге 4 — по размеру и сложности, с обоснованием по каждой оси. Причина в разведённости: ты только что написал этот код, и решать, насколько глубоко его проверять, тебе нельзя — под давлением «я почти закончил» решение -известно заранее. Правило выбора живёт в скилле конвейера, проектные триггеры — в -`docs/review.*`, подраздел «Триггеры метки». +известно заранее. Правило выбора живёт в скилле конвейера — +`av-dev-pipeline:review-pipeline`, `references/review-levels.md`; проектные +триггеры — в `docs/review.*`, подраздел «Триггеры метки». **Метка не пересматривается по факту диффа.** Дифф может выйти крупнее, чем ожидалось при разметке, — это не повод её поднимать: пересмотр означал бы второй