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

Состав прогона постоянный: гейт, спеки, код, триаж; приёмник тем идёт, когда у проекта есть свои темы. Метка, разметка и проход review-scope упразднены, review-levels.md удалён, ось «метка» снята из axes.md. Ступень 4 ушла из цикла: review-proof упразднён через день после заведения, review-architecture переехал в code-deep-review вслед за adversary и ops. Темы security, operations и architecture закрывает review-code сверкой с записанными инвариантами, потолком 1 находка. Умолчание разметки действий перевёрнуто на инлайн; развилка осталась за необратимым, изменением дельта-спек и нарушенным инвариантом. Задачи из урожая заводятся по слову человека, а не шагом сценария. Чекпоинт назван единственным местом, где решается форма решения. Потеряны ось времени в цикле и суждение о форме после кода — обе потери названы в «Честном пределе» строкой границ покрытия. Журнал — тема 77.
2026-08-23 17:26:07 +03:00
parent daf9f8b824
commit 3c89d7111d
30 changed files with 1055 additions and 1781 deletions
@@ -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`,
 сверка плана с исходом, урожай и доклад. **Коммит и закрытие задачи агенту не
 отдаются ни в одном сценарии** — они необратимы для учёта: закрытие удаляет запись
 и правит индексы, а коммит уезжает в историю. Оркестратор делает их сам, уже
-сверив план прогона с исходом. Ни одна из этих
+сверив перечень тем с исходом. Ни одна из этих
 работ не пишет файлов проекта — они и есть та работа, ради которой контекст
 берегут.

@@ -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`.

 ## Тонкости сценария

@@ -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` — по слову человека, у него на этот вход отдельный сценарий
+  «задачи из ревью и аудита». Каталога задач в
  проекте нет — урожай остаётся списком в докладе, и это говорится строкой.
 - **Способ решения ты не выбираешь.** Он приходит известным: из постановки, из
  разведки, от человека. Выбор между двумя подходами с разной ценой делается в