av/dev-skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
Состав прогона постоянный: гейт, спеки, код, триаж; приёмник тем идёт,
когда у проекта есть свои темы. Метка, разметка и проход review-scope
упразднены, review-levels.md удалён, ось «метка» снята из axes.md.

Ступень 4 ушла из цикла: review-proof упразднён через день после
заведения, review-architecture переехал в code-deep-review вслед за
adversary и ops. Темы security, operations и architecture закрывает
review-code сверкой с записанными инвариантами, потолком 1 находка.

Умолчание разметки действий перевёрнуто на инлайн; развилка осталась
за необратимым, изменением дельта-спек и нарушенным инвариантом.
Задачи из урожая заводятся по слову человека, а не шагом сценария.

Чекпоинт назван единственным местом, где решается форма решения.
Потеряны ось времени в цикле и суждение о форме после кода — обе
потери названы в «Честном пределе» строкой границ покрытия.

Журнал — тема 77.
This commit is contained in:
av
2026-08-23 17:26:07 +03:00
parent daf9f8b824
commit 3c89d7111d
30 changed files with 1055 additions and 1781 deletions
Download Patch File Download Diff File Expand all files Collapse all files
av-dev/skills/canon/references/canon.md
+21 -27
View File
@@ -77,7 +77,7 @@ openspec/
Раньше здесь стояло плоское правило «каждый документ `docs/` — тема ревью». Оно
неверно ровно наполовину: паспорт и схема хранилища ревью нужны, но темами не
являются, а журнал решений и журнал наблюдений ревью изменения не нужны вовсе.
Плоское правило заставляло разметчика либо плодить фантомные темы, либо терять
Плоское правило заставляло прогон либо плодить фантомные темы, либо терять
документы молча — а молчащая потеря и есть то, против чего канон написан.
**Разрез один и проверяемый: можно ли по документу сказать «в этом изменении
@@ -167,19 +167,17 @@ kebab-case.** Причина не эстетическая: имя файла с
Одна строка на каждый — на какой вопрос он отвечает, в какой он категории и
какую тему питает. **Кто именно закрывает тему, здесь не указано намеренно**: это
зависит от метки прогона и меняется вместе с конвейером, а документ живёт
дольше. Раскладку «тема → проход → глубина» держит скилл
`av-dev:code-review`.
меняется вместе с конвейером, а документ живёт дольше. Раскладку «тема → кто
закрывает → против чего» держит скилл `av-dev:code-review`.
**Общего словаря у канона с конвейером ровно три вида имён: имена категорий,
имена тем и имена меток.** Категорий три — `тема`, `источник`, `процессный`;
**меток тоже три, и они закрыты: `small`, `medium`, `large`.** Метка это итог
классификации задачи, и по ней конвейер выбирает исполнителей на обеих стадиях
ревью; проект её не выдумывает, а только уточняет триггеры. Ими проект и
настраивает ревью — вопросами по темам и триггерами метки. **Имён проходов канон не называет нигде**, включая вывод `docs.py`:
проход переименовывается и переезжает между метками, и канон, назвавший его, в
этот день соврёт молча. Обратное направление законно — конвейер называет
документы канона поимённо, потому что он их читатель.
**Общего словаря у канона с конвейером два вида имён: имена категорий и имена
тем.** Категорий три — `тема`, `источник`, `процессный`; список тем открытый, и
пополняет его сам проект своим документом. Настраивает проект ревью двумя вещами:
вопросами по темам и признаками, по которым зовут глубокое ревью. **Имён проходов
канон не называет нигде**, включая вывод `docs.py`: проход переименовывается и
переезжает в другой скилл, и канон, назвавший его, в этот день соврёт молча.
Обратное направление законно — конвейер называет документы канона поимённо,
потому что он их читатель.
| Документ | Вопрос | Категория и тема |
| --- | --- | --- |
@@ -319,22 +317,18 @@ kebab-case.** Причина не эстетическая: имя файла с
- **Типовые ложноположительные** — находки, которые здесь выглядят убедительно и
всегда неверны, каждая со строкой «почему здесь это не дефект»;
- **Вопросы по темам** — в форме `<тема>: <вопрос> (<откуда>)`. **Не по именам
проходов**: проход уезжает между метками, а тема остаётся, и вопрос,
адресованный проходу, перестал бы задаваться молча в тот день, когда тот уехал
в старшую метку. Задаёт вопрос тот, кто закрывает тему на этом прогоне.
проходов**: проход уезжает в другой скилл, а тема остаётся, и вопрос,
адресованный проходу, перестал бы задаваться молча в тот день, когда тот уехал.
Задаёт вопрос тот, кто закрывает тему на этом прогоне.
Адресовать можно только теме: `passport`, `database`, `adr`, `research` и
`review` — не темы, и вопрос, адресованный им, не задаст никто;
- **Триггеры метки** — проектная конкретизация правила выбора метки ревью,
**тремя списками**. Два поднимают, по одному на ось: что в этом проекте считается
**крупным** (объём: сколько узлов и слоёв трогает) и что считается
**незнакомым** (форма решения: известна до начала или нащупывается по ходу).
Любая из двух осей поднимает прогон до `large`, старшей метки, — а она
рассчитана на 5–10% задач. Третий список — что считается **мелким** (опускает
до `small`); он один, потому что вниз метку опускает только совпадение обеих
осей сразу. Перечнем мест, узлами или capability, а не вторым определением
класса. Уточняет умолчания, а не отменяет их. Рабочее умолчание — `medium`:
миграция схемы и публичный контракт метку **не** поднимают, их проверяют
проходы, которые в `medium` и так есть;
- **Когда звать глубокое ревью** — проектная конкретизация признаков, по которым
зовут `av-dev:code-deep-review`, **двумя списками**: области, которые смотрят
целиком (узлы с частым возвратом, места с историей инцидентов, код под дорогое
решение), и **необратимое здесь** — что в этом проекте после мерджа не
откатывается обратной правкой. Второй список работает и в цикле задачи: находка
в таком месте уходит человеку развилкой, а не чинится молча. Перечнем мест,
узлами или capability, а не вторым определением класса;
- **Недоступно проверке** — два подраздела, оба **по темам**: «не проверит ни
один проход» (принципиальная граница, по факту промаха не пересматривается) и
«перестали проверять сознательно» (пересматривается первым). Тема, у которой в
av-dev/skills/canon/references/skeletons.md
+14 -23
View File
@@ -287,10 +287,9 @@
задаёт тот проход, который закрывает эту тему на текущем прогоне, дополнительно
к обязательным.
**Адресуй теме, а не имени прохода.** Проходы переезжают между метками и
**Адресуй теме, а не имени прохода.** Проходы переезжают между скиллами и
упраздняются; вопрос, адресованный проходу, перестанет задаваться в тот день,
когда тот уедет в старшую метку, — и заметить это будет нечем. Тема переезд
переживает.
когда тот уедет, — и заметить это будет нечем. Тема переезд переживает.
Темы ядра: `requirements`, `autotests`, `conventions`, `architecture`,
`security`, `operations`. Плюс любая своя — та, под которую проект завёл в
@@ -299,30 +298,22 @@
`review` нельзя — таких тем нет. Вопрос про границу домена адресуй
`architecture`, вопрос про хранилище и числа — `operations`.
### Триггеры метки
### Когда звать глубокое ревью
Проектная конкретизация правила выбора метки. **Списка три: по одному на
каждую ось вверх и один вниз** — поимённо, узлами или capability.
Проектная конкретизация признаков, по которым зовут `av-dev:code-deep-review`.
**Списка два, оба поимённо — узлами, слоями или capability.**
**Крупное здесь** — про объём: что трогает несколько узлов или слоёв, переносит
ответственность между ними, перекладывает существующий код в новую форму.
**Области, которые смотрят целиком:** узлы, куда задачи возвращаются чаще
прочих, места с историей инцидентов, код, на который обопрётся дорогое решение.
**Незнакомое здесь** — про форму решения: то, чего в проекте ещё не было и чью
форму предстоит нащупать по ходу. Признак простой: перед работой нельзя назвать,
какие узлы будут тронуты.
**Необратимое здесь:** что в этом проекте после мерджа не откатывается обратной
правкой — миграции, формат на диске, публичный контракт, имена, расходящиеся по
базе. Находка в таком месте уходит человеку развилкой, а не чинится молча, и
список нужен затем, чтобы «необратимое» не решалось на глаз.
Любая из двух осей поднимает прогон до `large`, старшей метки: там `security`,
`operations` и `architecture` проверяют запуском, и там же единственные замеры.
Метка рассчитана на **5–10% задач**; если сюда попадает каждая третья, списки
написаны слишком широко.
**Мелкое здесь** — опускает до `small`. Ориентир по доле — до трети задач, и в
любом случае меньше, чем `medium`: перевес `small` значит, что рабочее умолчание
сместилось само. Помни отрицательный тест конвейера: что
после мерджа не откатывается обратной правкой (миграция, формат на диске,
публичный контракт, имя), — не `small`, каким бы маленьким ни был дифф.
Уточняет умолчания конвейера, не отменяет их; рабочее умолчание — `medium`.
Цикл задачи проверяет корректность и механику одним и тем же составом; глубину
даёт только отдельный прогон по области, и **зовёт его человек**. Списки уточняют
признаки, а не заводят расписание.
### Недоступно проверке
av-dev/skills/code-deep-review/SKILL.md
+30 -21
View File
@@ -1,6 +1,6 @@
---
name: code-deep-review
description: "Глубокое ревью области кода — не задачи, а куска проекта: модуля, слоя, сервиса целиком. Зовёт тяжёлые проходы, которых нет в цикле задачи: review-adversary (строит путь и прогоняет падающий тест), review-ops (снимает числа замером), review-architecture на входе шире диффа, review-code по коду целиком, а сводит их review-triage. Проходы, помеченные «держит машину», идут цепочкой. Исход — не правки, а разговор: находки предлагаются человеку, обсуждаются по одной, и согласованное уезжает задачами через av-dev:task-track, сценарий «задачи из ревью и аудита». Использовать время от времени и по признаку: накопился десяток задач в одной области, перед тем как опереться на узел в дорогом решении, после инцидента, по строке «отложено в code-deep-review» из отчётов ревью. Дорого — не на задаче и не по расписанию. Ревью одного изменения — скилл av-dev:code-review."
description: "Глубокое ревью области кода — не задачи, а куска проекта: модуля, слоя, сервиса целиком. Зовёт проходы, которых нет в цикле задачи: review-adversary (строит путь и прогоняет падающий тест), review-ops (снимает числа замером), review-architecture на входе шире диффа и по форме решения, review-code по коду целиком, а сводит их review-triage. Здесь единственное место процесса, где форму решения судят после кода и где находка доказывается прогоном и замером. Проходы, помеченные «держит машину», идут цепочкой. Исход — не правки, а разговор: находки предлагаются человеку, обсуждаются по одной, и согласованное уезжает задачами через av-dev:task-track, сценарий «задачи из ревью и аудита». Использовать время от времени и по признаку: накопился десяток задач в одной области, перед тем как опереться на узел в дорогом решении, после инцидента, по строке «отложено в code-deep-review» из отчётов ревью. Дорого — не на задаче и не по расписанию. Ревью одного изменения — скилл av-dev:code-review."
---
# Глубокое ревью области
@@ -15,30 +15,37 @@ description: "Глубокое ревью области кода — не за
## Зачем он появился
Тяжёлые проходы стояли в цикле задачи, на метке `large`: `review-adversary`
строил путь и прогонял падающий тест, `review-ops` снимал числа замером. Оба
держали машину, шли цепочкой и стоили часов **на каждой задаче**, где
Тяжёлые проходы стояли в цикле задачи: `review-adversary` строил путь и прогонял
падающий тест, `review-ops` снимал числа замером, `review-architecture` судил
форму решения на входе шире диффа. Первые двое держали машину и шли цепочкой,
третий требовал карты проекта; все трое стоили часов **на каждой задаче**, где
запускались, — при том что их ценность оплачивается на каждой, а получается на
немногих.
Их вынесли сюда целиком. В цикле задачи обе темы закрывает лёгкий проход
`review-proof` — чтением и рассуждением, без запуска, — и он же **копит вход для
этого скилла**: строка «отложено в `av-dev:code-deep-review`» в границах покрытия
называет тему, место и запуск, которым это проверяется.
Их вынесли сюда целиком, и цикл задачи после этого проверяет **корректность и
механику**: заказанное против сделанного, дефект, который сработает сам,
конвенции проекта и сверку с записанными инвариантами `CLAUDE.md`. Темы
`security`, `operations` и `architecture` остались там ровно в объёме
инвариантов — свойства, которого в них нет, цикл не спросит.
**Вход этому скиллу копят проходы цикла.** Строка «отложено в
`av-dev:code-deep-review`» в границах покрытия называет тему, место и запуск,
которым это проверяется; триаж сводит такие строки в отдельную секцию отчёта.
Второй источник — сигнал «это изменение просит глубокого ревью», который подаёт
`review-code`.
## Когда звать
**Зовёт человек**, и признак наблюдаемый, а не календарный:
- **накопился десяток задач в одной области** — по одной каждая была `medium`, а
вместе они переписали узел;
- **накопился десяток задач в одной области** — по отдельности каждая прошла
обычный цикл, а вместе они переписали узел;
- **строки «отложено» скопились**: в отчётах ревью по одному месту повторяется
один и тот же неснятый замер;
- **перед дорогим решением**, которое обопрётся на этот узел;
- **после инцидента** — когда уже известно, где болит, и надо понять, что рядом;
- **узел, в который возвращаются третий раз**: `av-dev:code-review`,
`references/review-levels.md` называет это поводом пересмотреть метку, а здесь
это повод посмотреть весь узел.
- **узел, в который возвращаются третий раз**: цикл задачи проверяет его каждый
раз заново и одним и тем же составом, а здесь это повод посмотреть узел целиком.
**Не на задаче и не по расписанию.** Цена реальная: два прохода держат машину и
идут цепочкой, вход шире диффа собирается командой проекта, а разбор находок
@@ -107,13 +114,14 @@ capability — одним адресом или несколькими. Скил
| дома тем | `docs/security.*`, `docs/architecture.*`, `docs/conventions.*` | против чего судить |
Отложенного нет вовсе — скажи это строкой. Пустой список значит либо что цикл
ничего не откладывал, либо что `review-proof` не писал свою строку; вторая
причина — находка о процессе, и она идёт в доклад.
ничего не откладывал, либо что проходы не писали свою строку; вторая причина —
находка о процессе, и она идёт в доклад.
## Состав прогона
Метки здесь нет и разметчик не зовётся: метку выводят из задачи, а задачи нет.
Состав **постоянный**, и глубина у всех проходов одна — **доказательство**.
Постоянен и состав цикла задачи, но он другой и мельче: разница между скиллами не
в старательности, а в том, что здесь запускают, меряют и строят путь.
| Проход | Тема | Что делает |
|---|---|---|
@@ -217,8 +225,9 @@ capability — одним адресом или несколькими. Скил
разговора, это задачи и запись в журнале ревью.
- **Область меньше — прогон лучше.** Модуль разбирается до конца, сервис целиком
даёт список, который бросают на середине.
- **Находка о процессе — тоже находка.** Пустая строка «отложено» у прохода
`review-proof`, дефект, трижды проскочивший в одном узле, тема без дома —
всё это идёт в доклад наравне с находками о коде.
- **Метку сюда не приносят.** Она свойство задачи; здесь задачи нет, и подставлять
`large` «по аналогии» нельзя — состав здесь и так постоянный.
- **Находка о процессе — тоже находка.** Пустой список отложенного, дефект,
трижды проскочивший в одном узле, тема без дома — всё это идёт в доклад наравне
с находками о коде.
- **Задачи здесь нет, и границей служит только область.** Дифф, дельта-спеки,
критерии приёмки — всё это про задачу; сюда они не приходят, и подставлять их
«по аналогии» нельзя.
av-dev/skills/code-openspec/SKILL.md
+1 -1
View File
@@ -52,7 +52,7 @@ openspec init --tools claude
Пересказ паспорта, инвариантов, конвенций и правил ревью сюда **не переносится**.
Место для второго дома здесь самое частое: `context` читается при порождении
каждого артефакта, туда удобно дописать «чтобы агент знал», и так заводятся копии
инвариантов, состава гейта и правил выбора метки. Расходятся они молча, а
инвариантов, состава гейта и правил ревью. Расходятся они молча, а
замечают это в уже написанном предложении.
Разрез, по которому отличают одно от другого: **утверждение, которое можно
av-dev/skills/code-resolve/SKILL.md
+7 -7
View File
@@ -1,6 +1,6 @@
---
name: code-resolve
description: "Взять одну задачу и довести её до закрытия. Одна точка входа, три сценария, и выбирает сценарий сам скилл, прочитав постановку. Способ известен и меняется поведение — сценарий решения: цикл Spec Driven Development (opsx propose → чекпоинт с объяснением человеческим языком → opsx apply → разметка по диффу → ревью кода → archive → синк документации → коммит → закрытие). Способ известен, а спека не меняется (тип chore: тулчейн, зависимости, сборка, гит-хуки, перенос, чистка) — сценарий обслуживания: правка → гейт со сверкой состава проверок → ревью фиксированным планом без change (autotests, operations, плюс conventions, если тронут код) → синк документации → коммит → закрытие; планового стопа нет, change не заводится. Нашлась дельта-спека — задача оказалась шире своего типа: стоп с объяснением простым языком и двумя решениями человека, переформулировать запись в fix или feature и решать её процессом того типа следующим прогоном либо прекратить работу. Способа нет, постановка мутная, тип research — сценарий разведки: вопрос и рамки → чтение документов, кода и внешних источников (можно opsx:explore) → чекпоинт вариантов: 2–4 способа решить, цена каждого, что становится невозможным, рекомендация → ответ уезжает в документы канона, исход — в задачи → вычитка написанного → коммит → закрытие. Разведка кода не пишет и change не заводит, а выбранный способ реализуется следующим прогоном. На входе путь к файлу задачи, её слаг или просто текст постановки: размеченная запись не обязательна — текст берётся так же, как его берёт opsx:propose, и текстом идут все три сценария. Использовать, когда просят взять, сделать или решить задачу — хоть записью из каталога, хоть описанием прямо в разговоре, — обновить зависимости или сборку, разобраться, изучить, сравнить подходы, проработать сырую идею, ответить на вопрос из беклога."
description: "Взять одну задачу и довести её до закрытия. Одна точка входа, три сценария, и выбирает сценарий сам скилл, прочитав постановку. Способ известен и меняется поведение — сценарий решения: цикл Spec Driven Development (opsx propose → чекпоинт с объяснением человеческим языком, где форму решения одобряет человек → opsx apply → ревью кода постоянным составом → archive → синк документации → коммит → закрытие). Способ известен, а спека не меняется (тип chore: тулчейн, зависимости, сборка, гит-хуки, перенос, чистка) — сценарий обслуживания: правка → гейт со сверкой состава проверок → ревью фиксированным планом без change (autotests, operations, плюс conventions и техника, если тронут код) → синк документации → коммит → закрытие; планового стопа нет, change не заводится. Нашлась дельта-спека — задача оказалась шире своего типа: стоп с объяснением простым языком и двумя решениями человека, переформулировать запись в fix или feature и решать её процессом того типа следующим прогоном либо прекратить работу. Способа нет, постановка мутная, тип research — сценарий разведки: вопрос и рамки → чтение документов, кода и внешних источников (можно opsx:explore) → чекпоинт вариантов: 2–4 способа решить, цена каждого, что становится невозможным, рекомендация → ответ уезжает в документы канона, исход — в задачи → вычитка написанного → коммит → закрытие. Разведка кода не пишет и change не заводит, а выбранный способ реализуется следующим прогоном. На входе путь к файлу задачи, её слаг или просто текст постановки: размеченная запись не обязательна — текст берётся так же, как его берёт opsx:propose, и текстом идут все три сценария. Использовать, когда просят взять, сделать или решить задачу — хоть записью из каталога, хоть описанием прямо в разговоре, — обновить зависимости или сборку, разобраться, изучить, сравнить подходы, проработать сырую идею, ответить на вопрос из беклога."
---
# Работа над одной задачей
@@ -31,7 +31,7 @@ description: "Взять одну задачу и довести её до за
## Предпосылки
- **OpenSpec и скиллы `opsx:*` — жёсткая предпосылка сценария решения**, а не
опция. На них стоят его шаги 2, 4 и 7 и проход `review-specs`
опция. На них стоят его шаги 2, 4 и 6 и проход `review-specs`
(они завязаны на `openspec/changes/<id>/specs/*/spec.md` и на
`openspec validate --strict`). **Проект без OpenSpec этим скиллом не ведётся** —
подключай OpenSpec, а не вырождай цикл сценария; почему ветка деградации здесь
@@ -284,7 +284,7 @@ flowchart TD
скилл написал бы сам, если бы писал.
Причина про контекст, и она одна. Оркестратор ведёт задачу целиком: выбрал
сценарий, собирает чекпоинт, сверяет план прогона с исходом, пишет доклад, — а
сценарий, собирает чекпоинт, сверяет перечень тем с исходом, пишет доклад, — а
для всего этого надо помнить постановку, критерии приёмки и то, что человек
одобрил. Письмо тянет в контекст ровно то, чего в докладе не будет ни строкой:
содержимое тронутых файлов, вывод линтеров и гейта, перебранные варианты правки.
@@ -293,23 +293,23 @@ flowchart TD
**Разведённость тут ни при чём**, и путать два довода нельзя. Агент пишет по
заданию оркестратора и отвечает перед ним; разведён с автором тот, кто работу
**судит**, — разметчик и проходы ревью.
**судит**, — проходы ревью.
| Работа | Где шаг |
| --- | --- |
| предложение и дельта-спеки — `opsx:propose` | [solve](references/solve.md), шаг 2 |
| правки спек и дизайна по сказанному на чекпоинте | [solve](references/solve.md), шаг 3 |
| код — `opsx:apply`, вместе с гейтом до зелёного и поведенческой верификацией | [solve](references/solve.md), шаг 4 |
| правки по находкам триажа, помеченным `инлайн` | [solve](references/solve.md), шаг 6; [maintain](references/maintain.md), шаг 4 |
| правки по находкам триажа, помеченным `инлайн` | [solve](references/solve.md), шаг 5; [maintain](references/maintain.md), шаг 4 |
| правка оснастки в сценарии обслуживания | [maintain](references/maintain.md), шаг 2 |
| архивация change и синк документации — `opsx:archive` и `av-dev:doc-sync` | [solve](references/solve.md), шаг 7; [maintain](references/maintain.md), шаг 5 |
| архивация change и синк документации — `opsx:archive` и `av-dev:doc-sync` | [solve](references/solve.md), шаг 6; [maintain](references/maintain.md), шаг 5 |
**Остальное остаётся оркестратору, и перечень закрыт:** выбор сценария и стопы,
чекпоинт, вызовы `av-dev:code-review`, `av-dev-git:commit` и `av-dev:task-track`,
сверка плана с исходом, урожай и доклад. **Коммит и закрытие задачи агенту не
отдаются ни в одном сценарии** — они необратимы для учёта: закрытие удаляет запись
и правит индексы, а коммит уезжает в историю. Оркестратор делает их сам, уже
сверив план прогона с исходом. Ни одна из этих
сверив перечень тем с исходом. Ни одна из этих
работ не пишет файлов проекта — они и есть та работа, ради которой контекст
берегут.
av-dev/skills/code-resolve/references/maintain.md
+29 -32
View File
@@ -19,10 +19,9 @@
**У обслуживания нет дельта-спек по построению.** Тип `chore` определён через
«наблюдаемое поведение не меняется», а на дельтах стоит весь цикл: `propose`
их порождает, разметка выведена **из них**, `review-specs` сверяет **с ними**,
объяснение чекпоинта собирается из `proposal.md` и `design.md`, `archive` вливает
их в актуальные спеки. Change без дельт — пустой артефакт, который потом надо
архивировать, и разметчик по нему назовёт не те темы.
их порождает, `review-specs` сверяет **с ними**, объяснение чекпоинта собирается
из `proposal.md` и `design.md`, `archive` вливает их в актуальные спеки. Change
без дельт — пустой артефакт, который потом надо архивировать.
Шаги цикла здесь не пропущены — **им нечего обрабатывать**. Отсюда и состав
сценария: выпали ровно те шаги, у которых нет предмета, и не выпал ни один из
@@ -126,7 +125,7 @@
**Третьего решения — «доделать как обслуживание» — нет.** Оно и есть то самое
молчаливое изменение поведения, против которого стоит весь разрез: под коммитом,
заявляющим «поменяли оснастку», уехала бы правка, не прошедшая ни чекпоинта, ни
ревью по метке, и не оставившая следа в спеках.
ревью цикла задачи, и не оставившая следа в спеках.
**Сделанное не выбрасывается ни при каком из двух решений.** Оно остаётся в
рабочем дереве незакоммиченным: при переформулировке уезжает в change следующим
@@ -312,38 +311,35 @@ ADR: список источников канон закрыл двумя — а
**исход гейта с шага 3** — сводку, путь к логам шагов и отпечаток дерева. Change
ты не передаёшь — его нет.
**Разметчик здесь не зовётся, и это правило, а не пропуск.** Обе оси, по которым
он судит, у обслуживания не определены: размер он меряет по `proposal.md`,
`design.md`, `tasks.md` и дельта-спекам, а незнакомость — по форме решения,
которой здесь нет (незнакомое ушло в разведку шагом 1). Разметчик без своего
корпуса вернул бы метку, выведенную из ничего.
**План у сценария свой, и он не совпадает с перечнем тем цикла задачи.** Тема
`requirements` там есть, а здесь её предмета нет вовсе; `operations` в цикле
закрыта сверкой с инвариантами внутри `review-code`, а здесь её берёт `basics` —
правка оснастки задевает выкладку, откат и соседей чаще, чем что-либо ещё, и
инвариантов на этот счёт у проекта обычно нет.
Поэтому план у сценария **свой и постоянный**, и глубину он называет сам —
проходы берут её из метки, а метки здесь нет:
<!-- дом: план-без-метки -->
<!-- дом: план-обслуживания -->
| Тема | Дом | Кто закрывает | Глубина и вход | Когда |
| --- | --- | --- | --- | --- |
| `autotests` | `CLAUDE.md`, семантика гейта | `review-autotests` | как обычно: гейт запускается целиком | всегда |
| `operations` | `architecture.*`, раздел эксплуатации | `review-basics` | **сверка**: дом темы против диффа, потолок 2 | всегда |
| `conventions` + технический разбор | `conventions.*` | `review-code` | вход `small`: только индекс конвенций; потолки 3 технических и 2 конвенционных; **третья половина включена** — сверка с инвариантами `CLAUDE.md`, потолок 1 | дифф трогает код, а не только оснастку |
| `conventions` + технический разбор | `conventions.*` | `review-code` | как в цикле: дом конвенций целиком, потолок 4 конвенционных, у техники потолка нет; сверка с инвариантами `CLAUDE.md` по темам `security`, `operations`, `architecture`, потолок 1 | дифф трогает код, а не только оснастку |
<!-- /дом: план-без-метки -->
<!-- /дом: план-обслуживания -->
**Глубина названа в плане потому, что иначе её неоткуда взять.** Вход и потолки
`review-code` заданы меткой, у `review-basics` меткой задана и сама возможность
запуска; на прогоне без метки оба взяли бы их наугад — то есть по-разному от
прогона к прогону, и молча.
**Глубина названа в плане потому, что иначе её неоткуда взять.** У `review-basics`
и тема, и глубина приходят заданием — в цикле он держит только свои темы проекта,
а здесь ему дают чужую; без строки плана он взял бы её наугад, то есть по-разному
от прогона к прогону и молча.
**Третья половина `review-code` включена намеренно.** В конвейере она живёт при
метке `small`, где приёмник тем не запускается, и сверяет дифф с записанными
инвариантами `CLAUDE.md` по темам `security`, `operations` и `architecture`.
Здесь у неё та же работа: без неё `security` не смотрит вообще никто.
**`review-code` идёт тем же составом, что в цикле, и это не совпадение.** Обе его
половины и сверка с инвариантами постоянны — от прогона они не зависят, потому и
переносятся сюда без оговорок. Единственное, что план решает за него, — идти ли
вообще: правка, тронувшая только оснастку, кода не меняла.
Триаж обязателен, как и на всяком прогоне: он единственный сток и единственный,
кто сверяет план с исходом. На его вход подаётся этот план — вместо плана
разметки, которого нет.
кто сверяет план с исходом. На его вход подаётся этот план — вместо перечня тем
цикла задачи.
**Условие третьей строки проверяемое, и смотрится оно по диффу**, а не по
намерению: обновление зависимости или правка файла CI кода не трогают, чистка и
@@ -351,9 +347,10 @@ ADR: список источников канон закрыл двумя — а
«здесь ошибка в логике», и чистка, прошедшая без него, проверена только на то,
что она собирается.
**Сигнал о заниженной метке на этом прогоне не работает** — метки нет, и
поднимать нечего. Его место занимает признак сценария: показалось, что глубины
мало, потому что задача крупнее заявленного, — ищи дельту, а не метку.
**Сигнал «просит глубокого ревью» работает и здесь**, но читается иначе: у
обслуживания поднимать нечего — состав фиксирован сценарием. Показалось, что
глубины мало, потому что задача крупнее заявленного, — ищи дельту, а не глубину;
всё прочее уходит строкой «отложено в `av-dev:code-deep-review`».
**Границы покрытия называются полностью:**
@@ -465,9 +462,9 @@ ADR: список источников канон закрыл двумя — а
- **состав гейта до и после**, если правка его трогала; не сверялся — почему;
- по каждому критерию приёмки: **оракул и наблюдаемый исход**;
- **`Урожай`** — отложенные находки списком;
- **строка границ покрытия**: план сценария фиксирован, разметчик не запускался,
`requirements` не смотрел никто, а `security` и `architecture` — только против
записанных инвариантов, и то если шёл проход `code`.
- **строка границ покрытия**: план сценария фиксирован; темы `requirements` в нём
нет — её не смотрел никто, а `security` и `architecture` смотрелись только
против записанных инвариантов, и то если шёл проход `code`.
## Тонкости сценария
av-dev/skills/code-resolve/references/solve.md
+97 -116
View File
@@ -11,13 +11,12 @@
пересказывается.
**OpenSpec — жёсткая предпосылка именно этого сценария** (SKILL.md,
«Предпосылки»): на нём стоят шаги 2, 4 и 7 и проход `review-specs`.
«Предпосылки»): на нём стоят шаги 2, 4 и 6 и проход `review-specs`.
Тонкая обёртка над каноническими скиллами `opsx:propose` / `opsx:apply` /
`opsx:archive` — их шаги не переизобретаются, а **зовёт их агент**, не ты
(SKILL.md, «Кто пишет: письмо уходит агентам»). Ревью — скилл
`av-dev:code-review`; он же держит правило выбора метки, а называет её агент
`review-scope` — один раз на задачу, **после того как код написан**.
`av-dev:code-review`; состав его прогона постоянный, выбирать и размечать нечего.
## Ход работы
@@ -28,17 +27,15 @@ flowchart TD
s2["2. opsx:propose — change, дельта-спеки,<br/>tasks.md — агентом"]
s3(["3. ЧЕКПОИНТ: объяснение<br/>в чём проблема, как решаем,<br/>чем рискуем"])
s4["4. opsx:apply — код, гейт,<br/>поведенческая верификация — агентом"]
s5["5. разметка — review-scope по диффу:<br/>размер, сложность, метка, план тем"]
s6["6. ревью кода по метке<br/>+ отработка замечаний агентом"]
s7["7. opsx:archive + синк документации —<br/>одним агентом"]
s8["8. коммит работы — av-dev-git:commit"]
s9["9. закрыть задачу — av-dev:task-track,<br/>вторым коммитом учёта"]
s5["5. ревью кода — постоянный состав<br/>+ отработка замечаний агентом"]
s6["6. opsx:archive + синк документации —<br/>одним агентом"]
s7["7. коммит работы — av-dev-git:commit"]
s8["8. закрыть задачу — av-dev:task-track,<br/>вторым коммитом учёта"]
in --> s1
s1 --> s2 --> s3 --> s4 --> s5 --> s6 --> s7 --> s8 --> s9
s5 -.->|"план задачи: темы и глубины"| s6
s1 --> s2 --> s3 --> s4 --> s5 --> s6 --> s7 --> s8
s3 -.->|"скорректировать:<br/>правка спек и дизайна"| s3
s6 -.->|"находка отменяет дизайн:<br/>меняются дельта-спеки"| s3
s5 -.->|"находка отменяет дизайн:<br/>меняются дельта-спеки"| s3
```
Схема — **сводка**: содержание каждого шага в его разделе ниже, и при
@@ -63,8 +60,8 @@ flowchart TD
Задача сделана, когда верно всё:
1. гейт проекта зелёный;
2. ревью проведено, **план прогона сверен с исходом по каждой теме**, темы без
отчёта и без дома названы в границах покрытия;
2. ревью проведено, **перечень тем сверен с исходом по каждой**, темы без отчёта
и без дома названы в границах покрытия;
3. решение прошло чекпоинт и не разошлось с одобренным — либо разошлось, и
чекпоинт был пройден заново;
4. change заархивирован, дельты влиты в актуальные спеки;
@@ -141,6 +138,13 @@ flowchart TD
нечем: человек читает предложение как оно есть. Взамен стоп пришёл **раньше** —
коррекция здесь стоит правки спеки, а не переписывания готового кода.
**Это единственное место процесса, где решается форма решения, и решает её
человек.** Ревью после кода судит корректность и механику против записанного
критерия; «то ли это решение» там не спрашивает ни один проход, а глубокое ревью
области придёт позже и не всегда. Значит, чекпоинт — не формальность и не
доклад о ходе работ: одобренное здесь уезжает в код без второго суждения о
замысле.
**Объяснение не сочиняется заново — оно собирается из артефактов**, `proposal.md`
и `design.md`. Третий пересказ был бы третьим домом одного и того же и разошёлся
бы с обоими. Что показываешь:
@@ -180,8 +184,7 @@ flowchart TD
(SKILL.md, «Кто пишет»): сказанное человеком уходит ему дословно, вместе с
идентификатором change и требованием перепрогнать
`openspec validate --strict <id>`. Затем чекпоинт **заново** — правленое
объяснение читает тот же человек. Разметки на этот момент ещё нет, и повторять
здесь нечего: она идёт после кода;
объяснение читает тот же человек;
- **не одобрено** — исход «не доведена» с причиной. Change остаётся
незаархивированным, задача не закрывается, ничего не коммитится наполовину.
@@ -192,7 +195,7 @@ flowchart TD
поведенческая верификация. Возврат — адреса тронутого, исход гейта и строка
верификации; диффа в нём нет. **Исход гейта возвращается сводкой, путём к логам
шагов и отпечатком дерева** (SKILL.md, «Возврат — не длиннее экрана»): его
передача на шаг 6 избавляет ревью от второго прогона того же гейта.
передача на шаг 5 избавляет ревью от второго прогона того же гейта.
Код — по конвенциям проекта
(каталог `docs/conventions/`). Меняешь схему — обнови её описание в документации
@@ -208,87 +211,47 @@ flowchart TD
**Сервис не оставляем лежать.** Если запуск упал — агент чинит или откатывает до
конца шага; возврат с лежащим сервисом — незакрытый шаг, а не исход.
### 5. Разметка задачи — агент `review-scope`
### 5. Ревью кода — состав постоянный
**Один запуск на всю задачу, и он идёт после кода.** Запусти агента
`review-scope`, дав ему корень проекта, идентификатор change, базу диффа и запись
задачи. Код уже написан, и **дифф — его источник размера**: он видит, сколько
мест тронуто на самом деле, а не сколько обещала постановка.
Вызови Skill **`av-dev:code-review`**, дав ссылку на change `<id>`, базу диффа,
режим запуска и **исход гейта с шага 4** — сводку, путь к логам шагов и отпечаток
дерева.
Он возвращает **план задачи**:
- **размер** (малое / среднее / крупное) и **сложность** (знакомое /
незнакомое), каждое с обоснованием по факту;
- **метку** как максимум по двум осям: `small`, `medium` или `large`;
- **таблицу тем** «тема → дом → глубина → кто закрывает» — для шага 6;
- разнесение документов проекта по трём категориям и строку про директивы.
**Метку выбираешь не ты, и это правило держится разведённостью.** Код только что
написан по твоему заданию, и решать, насколько глубоко его проверять, тебе нельзя:
под давлением «я почти закончил» решение известно заранее. Разметчик работу не
писал, а обе оси выводит из фактов — из диффа и из постановки, — и обязан назвать
признак по каждой.
**План держи в контексте до конца задачи.** На диск он не пишется: файл-план стал
бы четвёртым артефактом рядом с `proposal.md`, `tasks.md` и `design.md`, пережил
бы задачу и разошёлся бы с ней молча. Прервался прогон — повтори шаг 5, это самый
дешёвый его проход.
**Разметка повторяется ровно в одном случае** — если правки изменили сами
**дельта-спеки**: план выведен из задачи, и план по отменённым требованиям назовёт
не те темы. Во всех прочих случаях, включая отработку находок инлайна на шаге 6,
метка остаётся прежней: дифф от правок по находкам растёт, а задача — нет.
### 6. Ревью кода — по метке разметки
Вызови Skill **`av-dev:code-review`**, дав ссылку на change `<id>`,
базу диффа, **план разметки с шага 5**, режим запуска и **исход гейта с шага 4** —
сводку, путь к логам шагов и отпечаток дерева.
**Метку ты не выбираешь, и это правило, а не упрощение.** Её назвал
`review-scope` шагом раньше — по размеру и сложности, с обоснованием по каждой
оси; причина в разведённости, и она разобрана там же. Правило выбора живёт в
скилле конвейера — `av-dev:code-review`, `references/review-levels.md`; проектные
триггеры — в `docs/review.*`, подраздел «Триггеры метки».
**Метка, названная по диффу, внутри прогона больше не пересматривается.**
Разметчик видел дифф целиком и посчитал по нему обе оси; второй запуск на том же
дереве вернул бы то же самое.
**Считаешь метку заниженной — скажи это в докладе строкой, а не переспорь.**
Разметчик вправе и поднять, и понизить; твоё несогласие это факт для человека, а
не команда конвейеру. Место, где такое несогласие превращается в изменение
правил, — журнал дефектов `docs/review.md`, и только постфактум.
**Плана нет — ревью кода не запускается.** Триаж требует план обязательным
входом: без него он не может сверить, все ли размеченные темы вернули отчёт, а
эта сверка — единственная защита от молчащего пропуска. Потерял план (прервалась
сессия, ушёл контекст) — повтори шаг 5, а не гони прогон без него.
**Выбирать и размечать нечего.** Состав прогона один и тот же на всякой задаче:
гейт, сверка со спекой, разбор кода, триаж; приёмник тем идёт, когда у проекта
есть свои темы. Прежде между кодом и ревью стоял отдельный проход разметки — он
считал размер по диффу, сложность по постановке и выдавал метку, из которой
выводился состав. Метка снята вместе с ним: цикл задачи проверяет корректность и
механику, а этой работе нечего добавить и нечего убавить от размера изменения.
**Режим по умолчанию — `по графу`, и обосновывать его не надо.** Конвейер сам
знает свои рёбра: гейт открывает проходы с мнением, проходы с пометкой «держит
машину» идут цепочкой (иначе замеры портят друг друга и находка выглядит
доказанной), триаж — сток. Просить **`линейно`** нужно только по причине, и она
называется строкой: так сказал оператор; машина занята чем-то ещё; идёт разбор
самого конвейера.
знает свои рёбра: гейт открывает проходы с мнением, триаж — сток. Просить
**`линейно`** нужно только по причине, и она называется строкой: так сказал
оператор; машина занята чем-то ещё; идёт разбор самого конвейера.
Скилл сам гоняет гейт, нужные проходы и обязательный триаж. Возвращает отчёт с
потолком 7 пунктов, разметкой `Действие: инлайн | развилка` и секцией границ
покрытия.
потолком 7 пунктов, разметкой `Действие: инлайн | развилка`, секцией `Урожай`,
секцией отложенного в глубокое ревью и границами покрытия.
**Сверь план прогона с исходом, прежде чем коммитить.** Отчёт начинается планом
разметчика — таблицей «тема → дом → глубина → кто закрывает», — и против каждой
темы обязан стоять исход. Тема без отчёта и тема без дома — разные вещи, и обе
должны быть названы. Реестр короткий — темы ядра плюс свои проекта, — и сверка стоит
одного взгляда.
**Сверь перечень тем с исходом, прежде чем коммитить.** Отчёт начинается таблицей
«тема → кто закрывает → против чего», и против каждой темы обязан стоять исход.
Тема без отчёта и тема без дома — разные вещи, и обе должны быть названы.
Реестр постоянный и короткий, сверка стоит одного взгляда.
#### Отработка, и здесь появляется одно новое правило
#### Отработка — чинится молча, спрашивается редко
Помеченное `инлайн` чинит **агент** (SKILL.md, «Кто пишет»): находки уходят ему
**дословно, вместе с оракулом**, одним заданием на весь урожай инлайна, и гейт
после правок гоняет он же. Логировать их по-прежнему не надо. `развилка` —
вопросом в запись (он уже сформулирован триажем, его остаётся перенести), и
агенту она не отдаётся.
после правок гоняет он же. Логировать их не надо. **Это умолчание, и оно
широкое** — прогон, вернувший человеку список замечаний вместо готового
результата, свою работу не сделал.
`развилка` — вопросом в запись (он уже сформулирован триажем, его остаётся
перенести), и агенту она не отдаётся. Оснований у неё три, и все узкие: правка
меняет **дельта-спеки**, находка сидит в **необратимом** месте (миграция, формат
на диске, публичный контракт), находка трогает **инвариант** `CLAUDE.md`.
Развилок больше двух на задачу — это факт для доклада: либо задача не та, либо
разметка действий съехала.
**Находка, отменяющая одобренный дизайн, отменяет и одобрение.** Признак
проверяемый: **меняются ли дельта-спеки**.
@@ -296,8 +259,8 @@ flowchart TD
- не меняются — находка внутри дизайна, дожимай сам, это обычная отработка;
- меняются — решение стало другим, а одобрено было прежнее. **Вернись на чекпоинт
шага 3** с тем, что изменилось и почему; дальше задача идёт своим ходом заново —
код, разметка, ревью. Такая находка агенту не отдаётся ни при каких условиях:
она отменяет одобрение, а это разговор с человеком.
код, ревью. Такая находка агенту не отдаётся ни при каких условиях: она отменяет
одобрение, а это разговор с человеком.
**Это правило старше правила о развилке.** Находка класса `развилка`, чьё
основание — «надо менять спеку», подпадает под оба; побеждает возврат на
@@ -308,31 +271,44 @@ flowchart TD
ревью, не значит ничего, а человек при этом уверен, что одобрил именно то, что
уехало в коммит.
**Урожай — списком, не задачами.** Отложенные находки (реальный `major` не для
этого мерджа, развилка, решённая «потом», пачка `nit`) собери в секцию доклада
`Урожай`: формулировка, оракул, откуда взялась. Задачи из него **заводит не этот
скилл** — их заводит `av-dev:task-track` своим сценарием «задачи из ревью и
аудита»: своя нарезка, свой формат, свои правила дублей. Твоя обязанность — не
потерять и передать.
#### Урожай — список в докладе, задачи только по слову человека
Отложенные находки (реальный `major` не для этого мерджа, развилка, решённая
«потом», пачка `nit`) собери в секцию доклада `Урожай`: формулировка, оракул,
откуда взялась.
**Задачи из урожая заводятся только тогда, когда человек сказал «заводим».**
Покажи список одной репликой и спроси. Сказал — зови `av-dev:task-track`, у него
на этот вход отдельный сценарий «задачи из ревью и аудита»: своя нарезка, свой
формат, свои правила дублей, и передавать находку туда надо дословно. Не сказал —
урожай остаётся строками доклада, и это исход, а не потеря.
**Молча беклог не наполняется.** Очередь работ ведёт человек, и задача, заведённая
за него по ходу чужого прогона, отнимает у него ровно то решение, ради которого
очередь и существует. Прежде вызов `av-dev:task-track` был обязательным шагом —
теперь он шаг по ответу.
**Границы покрытия из отчёта не выбрасывай** — они уезжают в финальный доклад
сжатой строкой. Отчёт, из которого исчезло «что проверить было невозможно»,
превращается в ложное ощущение проверенности.
**Строку «отложено в `av-dev:code-deep-review`» перенеси дословно.** Проход
`review-proof` называет в ней тему, место и запуск, которым это проверяется, —
всё, что доказывается только прогоном и замером, цикл задачи не доказывает ни на
одной метке. Эти строки копятся и однажды становятся поводом позвать глубокое
ревью области; пересказанные своими словами, они теряют оракул и перестают быть
поводом.
**Строки «отложено в `av-dev:code-deep-review`» перенеси дословно.** Их пишут
проходы, упёршиеся в предел цикла: нужен замер, нужен прогнанный путь, нужен вход
шире диффа. В цикле задачи это не доказывается ничем, а строки копятся и однажды
становятся поводом позвать глубокое ревью области; пересказанные своими словами,
они теряют оракул и перестают быть поводом.
**Отчёт триажа сохрани вместе с change (`openspec/changes/<id>/review/`; шаг 7
**Сигнал «это изменение просит глубокого ревью»** приходит от `review-code` и
подтверждается `review-basics`. Он не команда и не стоп — строка доклада: когда
звать глубокий прогон, решает человек.
**Отчёт триажа сохрани вместе с change (`openspec/changes/<id>/review/`; шаг 6
унесёт его в архив вместе с change) — это обязательно, а не «если удобно».** По
нему потом видно, что было найдено и что из этого осталось в урожае. И это
единственный **независимый** артефакт о составе прогона: своей прозе здесь верить
нельзя — она написана тем же, кто мог проход и пропустить.
нельзя — её написал тот, кто мог проход и пропустить.
### 7. Архивация и синк документации — одним агентом
### 6. Архивация и синк документации — одним агентом
**Оба шага уходят одному агенту, и это один запуск** (SKILL.md, «Кто пишет»).
Работа здесь письменная от начала до конца: `opsx:archive` вливает дельты в
@@ -373,7 +349,7 @@ flowchart TD
задачу нельзя: документ, заведённый мимо канона, окажется вторым домом ровно
тому, что канон потом заведёт своим.
### 8. Коммит
### 7. Коммит
Коммить **в текущую ветку** (`git rev-parse --abbrev-ref HEAD`), сам ветку не
создавай и не переключай, ничего не пушь.
@@ -383,14 +359,14 @@ flowchart TD
напиши сообщение сам и скажи строкой доклада, что форму коммита не сверял никто.
Одна задача — один осмысленный коммит.
### 9. Закрыть задачу — **после коммита, не раньше**
### 8. Закрыть задачу — **после коммита, не раньше**
**Вызови Skill `av-dev:task-track`** и попроси закрыть задачу как реализованную —
он владеет форматом и двигает строку индекса сам. Путь к его скрипту не выясняй и
индексы руками не правь: мост между плагинами — вызов скилла, а не путь.
**Порядок обязателен.** Закрытие удаляет файл задачи; сделанное до коммита оно
оставило бы задачу закрытой без единого следа работы, если шаг 8 упадёт.
оставило бы задачу закрытой без единого следа работы, если шаг 7 упадёт.
**Закрытие тоже коммитится — вторым коммитом, тут же.** Удаление файла задачи и
правка индексов (их имена знает `av-dev:task-track`, не ты) — это правки в рабочем
@@ -418,8 +394,12 @@ change. Заводить запись задним числом, чтобы её
- ссылка на архивный change и хеш коммита;
- по каждому критерию приёмки, если они были: **оракул и наблюдаемый исход** —
это доклад приёмщику, а не отметка «принято»;
- **`Урожай`** — отложенные находки списком (формулировка, оракул, откуда взялась);
- **одна строка границ покрытия**: какая метка и режим гонялись, какие проходы не
- **`Урожай`** — отложенные находки списком (формулировка, оракул, откуда
взялась) и **что человек по нему решил**: заведены задачи или список остался в
докладе;
- **сколько находок ушло инлайном и сколько развилкой** — числом. По нему видно,
во что прогон обошёлся человеку;
- **одна строка границ покрытия**: какой режим гонялся, какие проходы не
запускались и что проверить было невозможно;
- **отложенное в `av-dev:code-deep-review`** — дословно из отчёта, либо «нечего». Доклад без неё сообщает
«проверено», не сообщая, что именно.
@@ -430,14 +410,15 @@ change. Заводить запись задним числом, чтобы её
перезапускать, а не «посмотреть заодно».
- Стиль правок — заточка под проект и конвенции, по размеру задачи, без
улучшений заодно.
- **Занизить метку ревью, пропустить тему или проскочить чекпоинт — самый дешёвый
способ «ускориться», и он же самый дорогой по последствиям.** Защита устроена
так, что регулятора у тебя нет: метку выбирает **не ты, а разметчик, и выводит
её из диффа**, план сверяется по темам, непокрытое называется строкой, а
расхождение с одобренным — отдельным пунктом доклада.
- **Заведение задач из урожая ревью — не твоя работа.** Отложенные находки
отдаются **списком**; превращает их в задачи `av-dev:task-track`, у него на
этот вход отдельный сценарий «задачи из ревью и аудита». Каталога задач в
- **Пропустить тему или проскочить чекпоинт — самый дешёвый способ «ускориться»,
и он же самый дорогой по последствиям.** Защита устроена так, что регулятора у
тебя нет: состав прогона постоянный и сокращению не подлежит, перечень тем
сверяется по исходу, непокрытое называется строкой, а расхождение с одобренным
— отдельным пунктом доклада.
- **Заведение задач из урожая ревью — не твоя работа и не работа этого прогона по
умолчанию.** Отложенные находки отдаются **списком**, и в задачи их превращает
`av-dev:task-track` — по слову человека, у него на этот вход отдельный сценарий
«задачи из ревью и аудита». Каталога задач в
проекте нет — урожай остаётся списком в докладе, и это говорится строкой.
- **Способ решения ты не выбираешь.** Он приходит известным: из постановки, из
разведки, от человека. Выбор между двумя подходами с разной ценой делается в
av-dev/skills/code-review/SKILL.md
+310 -458
View File
File diff suppressed because it is too large Load Diff
av-dev/skills/code-review/references/calibration.md
+5 -4
View File
@@ -27,7 +27,7 @@
```mermaid
stateDiagram-v2
state "проход в составе метки" as live
state "проход в составе прогона" as live
state "retune №1 — правка charter'а" as r1
state "retune №2 — последняя попытка" as r2
state "проход удалён" as dead
@@ -79,7 +79,6 @@ stateDiagram-v2
| Проход | Класс дефекта для инъекции | Заготовка пробы |
|---|---|---|
| `review-scope` | пропущенная тема | положить в `docs/` новый документ и проверить, попал ли он в план темой |
| `review-autotests` | отсутствующая верификация | убрать тест на изменённую ветку, оставить код рабочим |
| `review-specs` | поведение вне спеки | добавить незаказанный фолбэк-дефолт на пустом входе |
| `review-code` | нарушение прозаической конвенции | увести штатный отказ мимо единой точки трансляции ошибки |
@@ -88,7 +87,9 @@ stateDiagram-v2
| `review-basics` | отказ, видимый чтением | убрать обработку ошибки записи так, чтобы отказ считался успехом |
| `review-basics` | своя тема проекта | нарушить правило из документа, у которого нет именного прохода |
| `review-architecture` | второй способ | завести вторую точку генерации id мимо единой |
| `review-proof` | набросок пути и ось времени | принять внешний идентификатор без разбора до запроса в хранилище; убрать обработку недоступности внешней зависимости в фоновом цикле |
| `review-code` | инвариант проекта | нарушить записанный в `CLAUDE.md` запрет по темам `security`, `operations` или `architecture` |
| `review-adversary` | построенный путь | принять внешний идентификатор без разбора до запроса в хранилище |
| `review-ops` | ось времени | убрать обработку недоступности внешней зависимости в фоновом цикле |
| `review-triage` | шум | подать 20 находок, из них 15 вкусовщина и 3 дубля — проверить потолок и дедуп |
Метрик сверх этого не заводим. Precision, корреляция между проходами, стоимость
@@ -100,7 +101,7 @@ stateDiagram-v2
## Когда калибровать
- при заведении нового прохода — **до** включения в состав метки по умолчанию;
- при заведении нового прохода — **до** включения в состав прогона;
- при правке charter'а существующего — иначе непонятно, правка помогла или нет;
- при появлении записи в журнале проскочивших дефектов — калибруем тот проход,
который должен был поймать;
av-dev/skills/code-review/references/finding-contract.md
+18 -12
View File
@@ -75,19 +75,23 @@ Severity — ось процесса; перечень осей — [shared/axes
1. `Блокирует мердж` (≤3, каждая с оракулом);
2. `Стоит исправить сейчас` (≤4);
3. `Гипотезы без доказательства` — что понижено и почему;
4. `Promote candidates` — кандидаты в конвенцию или правило линтера;
5. `Границы покрытия` — сводная, обязательная.
4. `Урожай` — реальные находки не для этого мерджа: формулировка, оракул,
происхождение. Задачи из них заводит человек своим словом, не отчёт;
5. `Отложено в av-dev:code-deep-review` — что доказывается только запуском,
замером или входом шире диффа: тема, место, чем проверяется;
6. `Promote candidates` — кандидаты в конвенцию или правило линтера;
7. `Границы покрытия` — сводная, обязательная.
Перед секциями — сводка для человека: размер, сложность, метка и режим
прогона, состояние гейта, **план разметки задачи с исходом по каждой теме**,
сколько находок пришло на вход и сколько осталось.
Перед секциями — сводка для человека: режим прогона, состояние гейта, **перечень
тем с исходом по каждой**, сколько находок пришло на вход и сколько осталось,
сколько из них помечено `инлайн` и сколько `развилка`.
**Реестр сводки — темы, а не проходы, и это не оформление.** Перечень запущенных
проходов отвечает «все, кто должен был, отработали» и молчит о том, что именно
осталось непроверенным: уехавший в старшую метку проход уносит тему с собой
беззвучно. План же называет тему, её дом, глубину и исполнителя — и тема,
осталось непроверенным: уехавший в другой скилл проход уносит тему с собой
беззвучно. Перечень тем называет тему, её дом, глубину и исполнителя — и тема,
оставшаяся без отчёта, видна сразу. Перечень проходов из сводки не исчезает, но
идёт **внутри** плана, колонкой «кто закрывает».
идёт **внутри** него, колонкой «кто закрывает».
Каждая находка в секциях 1–2 несёт дополнительное поле:
@@ -95,10 +99,12 @@ Severity — ось процесса; перечень осей — [shared/axes
- Действие: инлайн | развилка
```
`инлайн` — оркестратор чинит сам, не спрашивая и не логируя. `развилка` — цена
исправления сопоставима с переработкой, либо выбор меняет scope, либо решение
трогает инвариант: уезжает вопросом с вариантами и ценой каждого туда, где
проект держит вопросы, а работа продолжается на остатке.
`инлайн` — оркестратор чинит сам, не спрашивая и не логируя, **и это
умолчание**. `развилка` — узкий выход с тремя основаниями: правка меняет
дельта-спеки, находка сидит в необратимом месте (миграция, формат на диске,
публичный контракт), находка трогает инвариант. Она уезжает вопросом с вариантами
и ценой каждого туда, где проект держит вопросы, а работа продолжается на
остатке.
Потребитель отчёта — оркестратор, который **реализует прочитанное**. Поэтому
потолок в 7 пунктов — не забота о внимании читателя, а защита кодовой базы от
av-dev/skills/code-review/references/project-facts.md
+18 -15
View File
@@ -14,7 +14,7 @@
## Карта тем
**Дом бывает файлом или каталогом** — `docs/security.md` и `docs/security/`
называют одну и ту же тему. Форму дома называет план разметки задачи; проход её не
называют одну и ту же тему. Форму дома называет задание прохода; проход её не
угадывает.
| Тема | Дом | Что оттуда берётся |
@@ -34,10 +34,11 @@
второй — `operations` и `requirements`; обе строки убраны, и цена этого названа в
`SKILL.md`, раздел «Честный предел».
**Дом темы зависит ещё и от метки.** На `small` темы `security`, `operations` и
`architecture` смотрятся не против домов из этой таблицы, а против **инвариантов
`CLAUDE.md`**, и закрывает их `code`. Таблица описывает полный дом темы; сколько
из него открыто на этом прогоне, говорит план разметки задачи.
**Дом темы зависит от того, кто её закрывает.** В цикле задачи темы `security`,
`operations` и `architecture` смотрятся не против домов из этой таблицы, а против
**инвариантов `CLAUDE.md`**, и закрывает их `code`. Полные дома открывает скилл
`av-dev:code-deep-review` своими проходами. Таблица описывает полный дом темы;
что из него открыто на этом прогоне, говорит состав прогона.
Сквозное, не привязанное к теме:
@@ -45,12 +46,12 @@
| --- | --- |
| инварианты **с severity рядом с формулировкой** | `CLAUDE.md` (и `AGENTS.md`, если он рядом), раздел инвариантов |
| что запускать запрещено, с путями; `testdata`; куда писать временное; имя основной ветки | `CLAUDE.md` |
| типовые узлы, типовые ложноположительные, **вопросы по темам**, триггеры метки, недоступно проверке | `docs/review.*`, раздел настройки |
| типовые узлы, типовые ложноположительные, **вопросы по темам**, недоступно проверке | `docs/review.*`, раздел настройки |
| прецеденты: воспроизведённые дефекты с оракулом | `docs/review.*`, журнал |
**Вопросы проекта привязаны к теме, а не к имени прохода.** Раньше блок в
`docs/review.md` адресовался поимённо (`ops: <вопрос>`), и когда проход уехал в
старшую метку, вопрос перестал задаваться молча. Тема переезд прохода
другой скилл, вопрос перестал задаваться молча. Тема переезд прохода
переживает.
## Сшивать обязаны проходы
@@ -65,7 +66,8 @@
«запись лежит сжатой и распаковывается целиком»; «блокировка удерживалась
5.019 с» — гарантированный отказ соседа только рядом с известным таймаутом
занятости. **Число проход снимает сам, на этом прогоне**, настройки берёт из
`docs/database.md`, и сшивает их `proof`. Раньше числа брались из
`docs/database.md`, и сшивает их `ops` в глубоком ревью — в цикле задачи не
снимает чисел никто. Раньше числа брались из
`docs/research/`; теперь этот документ процессный, и замер неизвестной свежести
больше не выдаёт себя за оракул.
- **инвариант + обратимость.** severity берётся из `CLAUDE.md`; если её там
@@ -75,15 +77,16 @@
**У `basics` стыков нет, и это не упущение.** Он не меряет, поэтому сшивать число
с настройкой ему нечего; единственное его основание для `critical` — инвариант из
`CLAUDE.md`, всё остальное он формулирует условиями и оставляет гипотезой. Его
вход намеренно узкий: дома тем из плана плюс инварианты и журнал. Широкий вход —
это метка `large`, и там он есть у `architecture`. Греп по базе ему разрешён
вход намеренно узкий: дома тем из задания плюс инварианты и журнал. Широкий вход
есть только у `architecture`, а он работает в глубоком ревью. Греп по базе ему разрешён
точечный — «есть ли второй вызывающий», — но обход всей базы и инвентарь
концепций не его работа.
**У `scope` стыков нет по другой причине: он не читает содержимого.** Его дело —
найти дома и раздать темы, а не пересказать написанное. Пересказ сделал бы его
посредником между документом и проходом, а посредник расходится с источником и при
этом выглядит актуальным.
**Дома передаются адресом, а не пересказом, и это правило пережило проход,
который его исполнял.** Прежде темы раздавал `review-scope`: он находил дома и
называл их путём с разделом, ничего не пересказывая. Прохода нет, состав
постоянный, но правило то же — проход, получивший проинтерпретированный периметр,
не заметит, что интерпретация неверна.
## Деградация — поразрядная
@@ -94,7 +97,7 @@
**Кто какой документ читает — из документа не выводится, а назначается планом.**
Документ питает тему (это записано на стороне канона, таблица «Роли документов и
темы ревью»), а тему на этом прогоне закрывает тот, кого назвала разметка задачи; вся
темы ревью»), а тему на этом прогоне закрывает тот, кто назван в составе прогона; вся
раскладка «тема → проход → глубина» — в `SKILL.md` этого скилла и больше нигде.
**Списка читателей не ведёт никто, и это не пробел.** Он жил бы на стороне
канона, а документ живёт дольше, чем раскладка проходов: список разошёлся бы с
av-dev/skills/code-review/references/review-journal.md
+3 -3
View File
@@ -29,7 +29,7 @@
и `docs/adr/`.
Отдельно сюда попадают **решения о составе прогонов**: перестали звать проход,
понизили метку правилом, сузили класс проверяемого. Не потому, что это промах,
переселили его в другой скилл, сузили класс проверяемого. Не потому, что это промах,
а потому, что здесь лежит цена: если что-то теперь проскочит, первый вопрос —
«не тот ли это класс, который мы перестали проверять».
@@ -81,8 +81,8 @@
что необратимо и какой шаг гейта красит безусловно → `CLAUDE.md`; периметр и
недоверенный вход → `docs/security.*`. **Вопрос по теме**, если промах лечится
не фактом, а заданным вопросом, → раздел «Вопросы по темам» того же
`docs/review.*`; адресуй теме, а не имени прохода — проход уедет между
метками, тема останется. Самый частый адрес и самый дешёвый. Прежде чем
`docs/review.*`; адресуй теме, а не имени прохода — проход уедет в другой
скилл, тема останется. Самый частый адрес и самый дешёвый. Прежде чем
править charter, проверь, не хватит ли факта или вопроса: charter общий для
всех проектов, документ — про этот.
- **в конвенции или в правило линтера** — если свойство выражается
av-dev/skills/code-review/references/review-levels.md
-175
View File
@@ -1,175 +0,0 @@
# Метки задачи — выбор, цена, доли
**Дом правила выбора метки.** Состав проходов по каждой метке, схема процесса и
раздача тем живут в [SKILL.md](../SKILL.md) — там диспетчер, и на готовой задаче
его достаточно. Здесь то, что читают, когда метку **выбирают, оспаривают или
калибруют**.
Применяет правило `review-scope` при разметке задачи — не автор изменения. Сама
матрица уехала в его устав **помеченной копией**, и дословность её держит
`copies.py`, а не обещание: прежде здесь стояло «расходиться не вправе», и
подкреплено это было ничем. Проза вокруг матрицы — отрицательный тест `small`,
доли, цена — принадлежит месту и живёт только здесь.
## Правило выбора — две оси, а не один вопрос
**Оси две, они измеряют разное, и метка есть максимум по ним.**
<!-- дом: матрица-метки -->
| | **знакомое** — форму решения можно назвать до начала | **незнакомое** — форму предстоит нащупать по ходу |
|---|---|---|
| **малое** — один узел | `small` | `large` |
| **среднее** — несколько узлов одного слоя | `medium` | `large` |
| **крупное** — несколько слоёв, перенос ответственности, большой рефакторинг | `large` | `large` |
<!-- /дом: матрица-метки -->
**Метка — не синоним размера.** Совпадают они только в левом верхнем углу: малое
**незнакомое** изменение получает `large`, трогая один узел. Поэтому в плане
стоят три строки, а не одна: размер, сложность и метка — каждая со своим
обоснованием. Проход, выведший объём диффа из метки, ошибётся ровно на этом
случае — а он и есть самый опасный: незнакомая форма в одном узле течёт там, где
её никто не ждёт.
**Размер** — про объём: сколько мест трогается. **Сложность** — про
неизвестность: знаем ли мы форму решения заранее. Признак незнакомого простой и
проверяемый: **перед работой нельзя назвать, какие узлы будут тронуты**.
Раньше обе оси были склеены в один вопрос «крупное **или** незнакомое?». Ответ
получался тот же, но две вещи под одним именем не измеришь по отдельности, и
потому разметка не могла сказать «изменение среднее, но совершенно знакомое» —
а именно эта пара и есть рабочее умолчание. Теперь обе оси называются в плане
поимённо, и обе — с обоснованием.
**Обе оси считаются один раз — по готовому диффу.** Раньше разметка шла до кода,
и размер приходилось выводить из написанного о задаче: перечня границ, `tasks.md`,
дельта-спек. Теперь размер меряется по тому, что тронуто на самом деле, а
написанное о задаче остаётся источником **сложности**: признак незнакомого —
нельзя было назвать тронутые узлы заранее — проверяется сверкой обещанного с
сделанным.
**Обратимость — не третья ось, а отрицательный тест.** Она не уточняет размер и
не уточняет сложность: она запрещает нижнюю метку независимо от обеих.
**Отрицательный тест `small`, и он важнее положительного:** изменение, которое
после мерджа **не откатывается обратной правкой**, — не `small`, каким бы
маленьким ни был дифф. Сюда попадают миграция схемы и данных, формат на диске,
публичный контракт, имя, которое разойдётся по кодовой базе. Три строки миграции
— это `medium`, а не `small`: размер диффа и цена ошибки здесь расходятся.
Что здесь считается крупным, что — незнакомым и что — мелким, проект уточняет в
`docs/review.md`, подразделе «Триггеры метки»: **тремя списками** — по одному на
каждую ось вверх и один вниз, поимённо, узлами или capability. Это **уточнение**,
а не отмена: не записано — работает таблица выше.
## Спорный случай решается вниз, и у этого есть цена
Правило асимметрично, потому что асимметрична цена ошибки.
- **Спорно между `medium` и `large` → бери `medium`.** Ошибка в эту сторону
стоит находки, которая всплывёт на следующей задаче или в журнале дефектов.
Ошибка в обратную стоит двух лишних проходов на каждой задаче, выбранной
неверно. Цена этого шага заметно упала: тяжёлая пара, что держала машину и шла
цепочкой, переехала в `av-dev:code-deep-review`, и `large` теперь добавляет два
прохода чтением, а не часы запусков.
- **Спорно между `small` и `medium` → бери `medium`.** Раньше эта строка
обосновывалась тем, что состав одинаков и ошибка почти бесплатна. Теперь состав
разный, и обоснование стало прямо противоположным: на `small` три темы ядра
смотрятся **только против записанных инвариантов**, а спорный случай — ровно тот,
где неизвестно, покрыт ли он инвариантом. Сомнение здесь стоит дороже, чем
раньше, и потому решается вниз тем более твёрдо.
**Выбор сделан в пользу пропускной способности, и это записано, а не подразумевается.**
Конвейер настроен на поток задач, а не на максимум находок с каждой: поправить в
следующей задаче дешевле, чем держать одну два часа. Отсюда три обязанности,
без которых сделка превращается в незаметную потерю качества:
- **границы покрытия называют темы и их глубину**, а не только запущенные
проходы — иначе `small` выглядит так же, как `large` без находок;
- **журнал дефектов в `docs/review.md` перестаёт быть хорошей практикой и
становится единственной обратной связью**: проскочивший дефект — единственный
сигнал, что метка выбрана слишком низко;
- **возврат в код — повод пересмотреть метку.** Задача, которая приходит в тот
же узел третий раз, уже не мелкая, чем бы ни выглядел её дифф.
## Метка — максимум по поверхности
**Обе оси меряются по всему диффу разом, и максимум по каждой отвечает за весь
дифф.** Метка изменения — не средневзвешенное: одна строка в перечне границ
задачи поднимает метку всему остальному, включая ту часть, которая сама по себе
была бы `small`.
Обратное тоже верно и тоже не бесплатно: у каждой задачи есть **несокращаемый
костяк — гейт, спеки, код, триаж**. Разрезать задачу, обе половины которой
остаются в одной метке, значит заплатить костяк дважды за ту же проверку.
Резать стоит там, где разрез **снимает старшую метку с большей части диффа**.
Шов и правило нарезки живут у того, кто ведёт задачи, — скилл
`av-dev:task-track`, его раздел о нарезке. Пути туда конвейер не выносит: за
пределы своего скилла он ходит вызовом, а не файлом.
Разметка в костяк не входит — она платится один раз на задачу, а не один раз на
прогон, и потому **перезапуск прогона её не удваивает**. Разрез задачи, впрочем,
удваивает: у каждой половины свой дифф, и мерить его приходится порознь.
**Размер, сложность, метка и глубина объявляются в отчёте, и все четыре с
обоснованием.** Метка выбирает `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`, который смотрит
уже на код, а не на описание.
av-dev/skills/doc-sync/SKILL.md
+3 -2
View File
@@ -197,8 +197,9 @@ av-dev:code-review`, его `references/review-journal.md`.
Твоя часть на синке: **дефект пишется сразу**, а не «потом, когда починим».
Со временем теряется не факт, а то, почему дефект не поймали, — единственное,
ради чего журнал есть. И решение сузить проверки (перестали звать проход, понизили
метку) обязано попасть в раздел настройки, а не остаться в отчёте ревью.
ради чего журнал есть. И решение сузить проверки (перестали звать проход,
переселили его в другой скилл) обязано попасть в раздел настройки, а не остаться
в отчёте ревью.
## Промоут в конвенции
av-dev/skills/task-track/references/split.md
+16 -17
View File
@@ -30,25 +30,24 @@
Тест выше говорит, **допустим** ли разрез. Где его провести из нескольких
допустимых мест — отвечает шов.
**Шов — там, где падает метка ревью.** Раздел «Затрагивает» перечисляет
границы; если одна строка перечня поднимает метку выше остальных, эта часть и
режется отдельно. Пример: задача перекладывает несколько узлов разом и заодно
добавляет два поля в существующий ответ. Целиком это `large` — полный состав проходов по
всему диффу, включая те, что держат машину и идут цепочкой. Разрезанная по шву,
она даёт `large` на маленькой переложенной части и `medium` на остатке.
**Шов — там, где меняется род работы.** Раздел «Затрагивает» перечисляет
границы; если одна строка перечня стоит особняком от остальных — трогает другой
слой, переносит ответственность, вводит новое понятие, — эта часть и режется
отдельно. Пример: задача перекладывает несколько узлов разом и заодно добавляет
два поля в существующий ответ; переложенная часть и добавленные поля проверяются
по-разному человеком, хотя конвейером — одинаково.
**Считай костяк, а не файлы.** У каждой задачи есть несокращаемые четыре прохода
(гейт, спеки, код, триаж), и они платятся за каждую. Разрез, после которого обе
половины остаются в одной метке, делает ревью **дороже**: тот же объём
проверяется тем же составом, но костяк оплачен дважды. Отсюда правило: **резать,
когда разрез снимает дорогой проход с большей части диффа**, и не резать, когда
он просто делает файлы мельче.
**Ревью на цену разреза больше не влияет.** Состав прогона постоянный: гейт,
спеки, код, триаж плюс приёмник тем, — и каждая половина платит его целиком.
Значит, разрез удваивает костяк ревью **всегда**, а не только когда обе половины
остаются в одной метке; выигрыш он даёт не в проверке, а в том, что каждая
половина доводится и мерджится сама по себе. Прежде здесь стояло правило «резать,
когда разрез снимает дорогой проход с большей части диффа» — снимать больше
нечего.
**Это планирование, а не предписание процесса.** Метка ревью выбирается по
факту изменения — тем, кто его видит, — и в тело задачи не пишется: строка
«делать с меткой medium» это ровно тот второй дом правила выбора, который
гигиена полей снимает. Шов пользуется меткой как **признаком**, что в задаче
две разнородные работы; решение о метке остаётся за конвейером.
**Это планирование, а не предписание процесса.** Как проверять изменение, решает
конвейер, увидев его; в тело задачи это не пишется — строка «делать вот так» и
есть тот второй дом правила, который гигиена полей снимает.
## Что делать с родителем