resolve: ревью дизайна снято, разметка переехала за код

Сценарий решения идёт от предложения сразу к чекпоинту и коду: стадия ревью
дизайна упразднена целиком, review-scope запускается после apply и меряет
размер по диффу, сложность — сверкой обещанных границ с тронутыми. Чекпоинт
остался единственным плановым стопом и стоит теперь до кода. review-rubric
конвейером не зовётся, слот рубрики в скелете config.yaml снят. Журнал —
тема 74.

av-dev/skills/code-resolve/references/maintain.md

@@ -125,8 +125,8 @@
 
 **Третьего решения — «доделать как обслуживание» — нет.** Оно и есть то самое
 молчаливое изменение поведения, против которого стоит весь разрез: под коммитом,
-заявляющим «поменяли оснастку», уехала бы правка, не прошедшая ни ревью дизайна,
-ни чекпоинта, и не оставившая следа в спеках.
+заявляющим «поменяли оснастку», уехала бы правка, не прошедшая ни чекпоинта, ни
+ревью по метке, и не оставившая следа в спеках.
 
 **Сделанное не выбрасывается ни при каком из двух решений.** Оно остаётся в
 рабочем дереве незакоммиченным: при переформулировке уезжает в change следующим

av-dev/skills/code-resolve/references/solve.md

@@ -2,7 +2,7 @@
 
 Способ решения известен, спорно только как. Проводит задачу от постановки до
 закрытия и **пишет код**: цикл Spec Driven Development с одним плановым стопом —
-объяснением после ревью дизайна.
+объяснением сразу после предложения.
 
 Сценарий выбирается развилкой на входе скилла ([SKILL.md](../SKILL.md), раздел
 «Развилка: какой сценарий») и называется вслух первой репликой. Здесь только его
@@ -11,14 +11,13 @@
 пересказывается.
 
 **OpenSpec — жёсткая предпосылка именно этого сценария** (SKILL.md,
-«Предпосылки»): на нём стоят шаги 2, 6 и 8, проход `review-specs` и ревью
-дизайна.
+«Предпосылки»): на нём стоят шаги 2, 4 и 7 и проход `review-specs`.
 
 Тонкая обёртка над каноническими скиллами `opsx:propose` / `opsx:apply` /
 `opsx:archive` — их шаги не переизобретаются, а **зовёт их агент**, не ты
 (SKILL.md, «Кто пишет: письмо уходит агентам»). Ревью — скилл
 `av-dev:code-review`; он же держит правило выбора метки, а называет её агент
-`review-scope` — один раз на задачу, для обеих стадий ревью.
+`review-scope` — один раз на задачу, **после того как код написан**.
 
 ## Ход работы
 
@@ -27,21 +26,20 @@ flowchart TD
     in["сценарий выбран: решение"]
     s1["1. прочитать задачу<br/>критерии приёмки выписать сразу"]
     s2["2. opsx:propose — change, дельта-спеки,<br/>tasks.md — агентом"]
-    s3["3. разметка — review-scope:<br/>размер, сложность, метка, план тем"]
-    s4["4. ревью дизайна, состав по метке<br/>+ отработка замечаний агентом"]
-    s5(["5. ЧЕКПОИНТ: объяснение<br/>в чём проблема, как решаем,<br/>чем рискуем"])
-    s6["6. opsx:apply — код, гейт,<br/>поведенческая верификация — агентом"]
-    s7["7. ревью кода, та же метка<br/>+ отработка замечаний агентом"]
-    s8["8. opsx:archive"]
-    s9["9. синк документации — av-dev:doc-sync"]
-    s10["10. коммит работы — av-dev-git:commit"]
-    s11["11. закрыть задачу — av-dev:task-track,<br/>вторым коммитом учёта"]
+    s3(["3. ЧЕКПОИНТ: объяснение<br/>в чём проблема, как решаем,<br/>чем рискуем"])
+    s4["4. opsx:apply — код, гейт,<br/>поведенческая верификация — агентом"]
+    s5["5. разметка — review-scope по диффу:<br/>размер, сложность, метка, план тем"]
+    s6["6. ревью кода по метке<br/>+ отработка замечаний агентом"]
+    s7["7. opsx:archive"]
+    s8["8. синк документации — av-dev:doc-sync"]
+    s9["9. коммит работы — av-dev-git:commit"]
+    s10["10. закрыть задачу — av-dev:task-track,<br/>вторым коммитом учёта"]
 
     in --> s1
-    s1 --> s2 --> s3 --> s4 --> s5 --> s6 --> s7 --> s8 --> s9 --> s10 --> s11
-    s3 -.->|"план задачи: та же метка"| s7
-    s5 -.->|"скорректировать:<br/>меняются дельта-спеки"| s3
-    s7 -.->|"находка отменяет дизайн:<br/>меняются дельта-спеки"| s3
+    s1 --> s2 --> s3 --> s4 --> s5 --> s6 --> s7 --> s8 --> s9 --> s10
+    s5 -.->|"план задачи: темы и глубины"| s6
+    s3 -.->|"скорректировать:<br/>правка спек и дизайна"| s3
+    s6 -.->|"находка отменяет дизайн:<br/>меняются дельта-спеки"| s3
 ```
 
 Схема — **сводка**: содержание каждого шага в его разделе ниже, и при
@@ -93,7 +91,7 @@ flowchart TD
 
 **Постановка пришла текстом** (SKILL.md, «Постановка текстом») — записи нет,
 читаешь сам текст. Критерии в нём бывают редко: выпиши то, что там есть, а
-недостающие **предложи на чекпоинте шага 5** и считай их данными только после
+недостающие **предложи на чекпоинте шага 3** и считай их данными только после
 ответа человека. Сам себе критерии не проставляешь — правило то же, что и с
 записью: они приходят снаружи, и подсунуть их себе значит назначить себе приёмку.
 Человек критериев не назвал — скажи строкой, что задача идёт без них и приёмка
@@ -116,7 +114,7 @@ flowchart TD
 сценарии — `GIVEN/WHEN/THEN`.
 
 **`proposal.md` и `design.md` после возврата читаешь сам** — из них собирается
-чекпоинт шага 5, и держать их в контексте это твоя работа, а не переполнение.
+чекпоинт шага 3, и держать их в контексте это твоя работа, а не переполнение.
 Кода нет, читать нечего сверх них.
 
 Ещё две вещи задание называет прямо, иначе их не сделает никто. **Критерии
@@ -128,84 +126,21 @@ flowchart TD
 `design.md`, с причиной отказа по каждому отвергнутому.
 
 **`proposal.md` пишется так, чтобы его понял человек, не читавший спек.** Это не
-стилистическое пожелание: из него собирается чекпоинт шага 5, и переписывать его
+стилистическое пожелание: из него собирается чекпоинт шага 3, и переписывать его
 там заново значит завести второй дом для одного объяснения. Требование стоит в
 `openspec/config.yaml`, `rules.proposal` — то есть применяется в момент
 порождения артефакта, а не вспоминается после.
 
-### 3. Разметка задачи — агент `review-scope`
-
-**Один запуск на всю задачу, и он обслуживает обе стадии ревью.** Запусти
-агента `review-scope`, дав ему корень проекта, идентификатор change, базу диффа и
-запись задачи. Кода на этот момент нет, и это условие его работы, а не помеха.
-
-Он возвращает **план задачи**:
-
-- **размер** (малое / среднее / крупное) и **сложность** (знакомое /
-  незнакомое), каждое с обоснованием по факту;
-- **метку** как максимум по двум осям: `small`, `medium` или `large`;
-- **состав ревью дизайна** — что звать на шаге 4;
-- **таблицу тем** «тема → дом → глубина → кто закрывает» — для шага 7;
-- разнесение документов проекта по трём категориям и строку про директивы.
-
-**Метку выбираешь не ты.** Раньше состав ревью дизайна называл сам оркестратор —
-то есть тот, кто только что довёл предложение до `propose`. Разведённости с
-автором в этой точке не было вовсе; теперь есть.
-
-**План держи в контексте до конца задачи.** На диск он не пишется: файл-план стал
-бы четвёртым артефактом рядом с `proposal.md`, `tasks.md` и `design.md`, пережил
-бы задачу и разошёлся бы с ней молча. Прервался прогон — повтори шаг 3, это самый
-дешёвый его проход.
-
-**Разметка повторяется ровно в одном случае** — если правки изменили сами
-**дельта-спеки**: план выведен из них, и план по отменённым требованиям назовёт
-не те темы. Во всех прочих случаях, включая переделку формы кода на шаге 7,
-метка остаётся прежней.
-
-### 4. Ревью дизайна — ДО кода, состав по метке
-
-Вызови Skill **`av-dev:code-review`**, дав ссылку на change `<id>`,
-**план разметки с шага 3** и указание, что это ревью дизайна.
-
-Состав приходит планом, а не решается здесь:
-
-| Метка | Проходы на предложении |
-|---|---|
-| `small` | `specs` |
-| `medium` | `specs`, `rubric` |
-| `large` | `specs`, `rubric`, `architecture` + вопрос автору о трёх формах решения |
-
-`review-specs` в режиме «дизайн ДО кода» идёт **на каждой задаче**: это самый
-дешёвый проход конвейера, и он ловит то, что на готовом коде уже не чинят.
-Остальные включаются меткой, потому что стадия стоит на каждой задаче и каждый
-лишний проход здесь умножается на число задач.
-
-Смысл стадии: архитектурная находка на готовом коде стоит переписывания и потому
-игнорируется — та же находка здесь стоит абзаца обсуждения. Если `review-rubric`
-запускался, перенеси его рубрику в `tasks.md` как приёмочные критерии; там же уже
-лежат критерии от постановки, если они были.
-
-**Отработка замечаний, и она идёт до чекпоинта, а не после:**
-
-- мелочь и явные улучшения — правкой спек и дизайна, и её делает **агент**
-  (SKILL.md, «Кто пишет»): находки уходят ему дословно, вместе с
-  идентификатором change и требованием перепрогнать
-  `openspec validate --strict <id>`;
-- развилки (компромисс, scope, инвариант) — **не в запись, а в чекпоинт**: он
-  следующим шагом, и это ровно то, ради чего он поставлен здесь. Агенту развилка
-  не отдаётся вовсе: решает её человек, а не тот, кто правит спеку;
-- возврат агента — адреса тронутых дельт и исход валидации; правленые спеки
-  перечитываешь по адресам, если чекпоинт опирается на изменившееся.
-
-### 5. Чекпоинт: объяснение
+### 3. Чекпоинт: объяснение
 
 **Остановись и объясни человеку, что происходит.** Единственный плановый стоп
 этого сценария, и он обязателен для всякой задачи.
 
-Он стоит **после** ревью дизайна намеренно. Человек читает объяснение, уже
-просеянное машиной: то, что поймал бы `review-specs`, до него не доходит, а
-внимание — самый дорогой ресурс процесса, и тратить его на выловимое машиной
-нельзя.
+Он стоит **сразу после предложения и до кода** — намеренно. Раньше между
+`propose` и чекпоинтом стояла стадия ревью дизайна, и человек читал объяснение,
+уже просеянное машиной. Стадию сняли ради времени прогона, и просеивать теперь
+нечем: человек читает предложение как оно есть. Взамен стоп пришёл **раньше** —
+коррекция здесь стоит правки спеки, а не переписывания готового кода.
 
 **Объяснение не сочиняется заново — оно собирается из артефактов**, `proposal.md`
 и `design.md`. Третий пересказ был бы третьим домом одного и того же и разошёлся
@@ -217,7 +152,7 @@ flowchart TD
 - **что человек увидит иначе**, когда это будет сделано;
 - **чего мы намеренно не делаем** и почему — граница scope ловится хуже всего;
 - **чем рискуем и что осталось нерешённым** — сюда съезжаются развилки,
-  накопленные до этого места, и находки ревью с пометкой `развилка`;
+  накопленные до этого места;
 - **что дальше**, если возражений нет;
 - **критерии приёмки, если постановка пришла текстом и не назвала их** —
   предложенными, а не принятыми: человек их подтверждает или правит здесь же.
@@ -241,22 +176,24 @@ flowchart TD
 
 Три исхода:
 
-- **согласен** — идёшь на шаг 6;
-- **скорректировать** — правишь спеки и дизайн по сказанному. Изменились
-  **дельта-спеки** — повтори шаг 3 (разметка выведена из них) и ту часть ревью
-  дизайна, которой касается правка; затем чекпоинт **заново**. Правка внутри
-  дизайна без спек — повтори только чекпоинт;
+- **согласен** — идёшь на шаг 4;
+- **скорректировать** — правку спек и дизайна по сказанному делает **агент**
+  (SKILL.md, «Кто пишет»): сказанное человеком уходит ему дословно, вместе с
+  идентификатором change и требованием перепрогнать
+  `openspec validate --strict <id>`. Затем чекпоинт **заново** — правленое
+  объяснение читает тот же человек. Разметки на этот момент ещё нет, и повторять
+  здесь нечего: она идёт после кода;
 - **не одобрено** — исход «не доведена» с причиной. Change остаётся
   незаархивированным, задача не закрывается, ничего не коммитится наполовину.
 
-### 6. Написать код — `opsx:apply`
+### 4. Написать код — `opsx:apply`
 
 **Код пишет агент, и в его же задании лежит весь этот раздел** (SKILL.md, «Кто
 пишет»): вызов `opsx:apply` для реализации `tasks.md`, гейт до зелёного,
 поведенческая верификация. Возврат — адреса тронутого, исход гейта и строка
 верификации; диффа в нём нет. **Исход гейта возвращается сводкой, путём к логам
 шагов и отпечатком дерева** (SKILL.md, «Возврат — не длиннее экрана»): его
-передача на шаг 7 избавляет ревью от второго прогона того же гейта.
+передача на шаг 6 избавляет ревью от второго прогона того же гейта.
 
 Код — по конвенциям проекта
 (каталог `docs/conventions/`). Меняешь схему — обнови её описание в документации
@@ -272,23 +209,52 @@ flowchart TD
 **Сервис не оставляем лежать.** Если запуск упал — агент чинит или откатывает до
 конца шага; возврат с лежащим сервисом — незакрытый шаг, а не исход.
 
-### 7. Ревью кода — та же метка
+### 5. Разметка задачи — агент `review-scope`
+
+**Один запуск на всю задачу, и он идёт после кода.** Запусти агента
+`review-scope`, дав ему корень проекта, идентификатор change, базу диффа и запись
+задачи. Код уже написан, и **дифф — его источник размера**: он видит, сколько
+мест тронуто на самом деле, а не сколько обещала постановка.
+
+Он возвращает **план задачи**:
+
+- **размер** (малое / среднее / крупное) и **сложность** (знакомое /
+  незнакомое), каждое с обоснованием по факту;
+- **метку** как максимум по двум осям: `small`, `medium` или `large`;
+- **таблицу тем** «тема → дом → глубина → кто закрывает» — для шага 6;
+- разнесение документов проекта по трём категориям и строку про директивы.
+
+**Метку выбираешь не ты, и это правило держится разведённостью.** Код только что
+написан по твоему заданию, и решать, насколько глубоко его проверять, тебе нельзя:
+под давлением «я почти закончил» решение известно заранее. Разметчик работу не
+писал, а обе оси выводит из фактов — из диффа и из постановки, — и обязан назвать
+признак по каждой.
+
+**План держи в контексте до конца задачи.** На диск он не пишется: файл-план стал
+бы четвёртым артефактом рядом с `proposal.md`, `tasks.md` и `design.md`, пережил
+бы задачу и разошёлся бы с ней молча. Прервался прогон — повтори шаг 5, это самый
+дешёвый его проход.
+
+**Разметка повторяется ровно в одном случае** — если правки изменили сами
+**дельта-спеки**: план выведен из задачи, и план по отменённым требованиям назовёт
+не те темы. Во всех прочих случаях, включая отработку находок инлайна на шаге 6,
+метка остаётся прежней: дифф от правок по находкам растёт, а задача — нет.
+
+### 6. Ревью кода — по метке разметки
 
 Вызови Skill **`av-dev:code-review`**, дав ссылку на change `<id>`,
-базу диффа, **план разметки с шага 3**, режим запуска и **исход гейта с шага 6** —
+базу диффа, **план разметки с шага 5**, режим запуска и **исход гейта с шага 4** —
 сводку, путь к логам шагов и отпечаток дерева.
 
 **Метку ты не выбираешь, и это правило, а не упрощение.** Её назвал
-`review-scope` ещё на шаге 3 — по размеру и сложности, с обоснованием по каждой
-оси. Причина в разведённости: ты только что написал этот код, и решать, насколько
-глубоко его проверять, тебе нельзя — под давлением «я почти закончил» решение
-известно заранее. Правило выбора живёт в скилле конвейера —
-`av-dev:code-review`, `references/review-levels.md`; проектные
+`review-scope` шагом раньше — по размеру и сложности, с обоснованием по каждой
+оси; причина в разведённости, и она разобрана там же. Правило выбора живёт в
+скилле конвейера — `av-dev:code-review`, `references/review-levels.md`; проектные
 триггеры — в `docs/review.*`, подраздел «Триггеры метки».
 
-**Метка не пересматривается по факту диффа.** Дифф может выйти крупнее, чем
-ожидалось при разметке, — это не повод её поднимать: пересмотр означал бы второй
-запуск разметчика, ровно то, ради устранения чего он и переехал на шаг 3.
+**Метка, названная по диффу, внутри прогона больше не пересматривается.**
+Разметчик видел дифф целиком и посчитал по нему обе оси; второй запуск на том же
+дереве вернул бы то же самое.
 
 **Считаешь метку заниженной — скажи это в докладе строкой, а не переспорь.**
 Разметчик вправе и поднять, и понизить; твоё несогласие это факт для человека, а
@@ -298,7 +264,7 @@ flowchart TD
 **Плана нет — ревью кода не запускается.** Триаж требует план обязательным
 входом: без него он не может сверить, все ли размеченные темы вернули отчёт, а
 эта сверка — единственная защита от молчащего пропуска. Потерял план (прервалась
-сессия, ушёл контекст) — повтори шаг 3, а не гони прогон без него.
+сессия, ушёл контекст) — повтори шаг 5, а не гони прогон без него.
 
 **Режим по умолчанию — `по графу`, и обосновывать его не надо.** Конвейер сам
 знает свои рёбра: гейт открывает проходы с мнением, проходы с пометкой «держит
@@ -329,9 +295,9 @@ flowchart TD
 проверяемый: **меняются ли дельта-спеки**.
 
 - не меняются — находка внутри дизайна, дожимай сам, это обычная отработка;
-- меняются — решение стало другим, а одобрено было прежнее. Повтори шаг 3
-  (разметка выведена из дельта-спек) и **вернись на чекпоинт шага 5** с тем, что
-  изменилось и почему. Такая находка агенту не отдаётся ни при каких условиях:
+- меняются — решение стало другим, а одобрено было прежнее. **Вернись на чекпоинт
+  шага 3** с тем, что изменилось и почему; дальше задача идёт своим ходом заново —
+  код, разметка, ревью. Такая находка агенту не отдаётся ни при каких условиях:
   она отменяет одобрение, а это разговор с человеком.
 
 **Это правило старше правила о развилке.** Находка класса `развилка`, чьё
@@ -354,18 +320,18 @@ flowchart TD
 сжатой строкой. Отчёт, из которого исчезло «что проверить было невозможно»,
 превращается в ложное ощущение проверенности.
 
-**Отчёт триажа сохрани вместе с change (`openspec/changes/<id>/review/`; шаг 8
+**Отчёт триажа сохрани вместе с change (`openspec/changes/<id>/review/`; шаг 7
 унесёт его в архив вместе с change) — это обязательно, а не «если удобно».** По
 нему потом видно, что было найдено и что из этого осталось в урожае. И это
 единственный **независимый** артефакт о составе прогона: своей прозе здесь верить
 нельзя — она написана тем же, кто мог проход и пропустить.
 
-### 8. Архивировать — `opsx:archive`
+### 7. Архивировать — `opsx:archive`
 
 Вызови Skill `opsx:archive`: change уезжает в архив, дельты вливаются в
 актуальные спеки. Не пропускай `openspec validate --strict` перед этим.
 
-### 9. Синк документации
+### 8. Синк документации
 
 **Вызови Skill `av-dev:doc-sync`**: он владеет содержимым документов канона и
 ведёт чек-лист синка.
@@ -385,7 +351,7 @@ flowchart TD
 задачу нельзя: документ, заведённый мимо канона, окажется вторым домом ровно
 тому, что канон потом заведёт своим.
 
-### 10. Коммит
+### 9. Коммит
 
 Коммить **в текущую ветку** (`git rev-parse --abbrev-ref HEAD`), сам ветку не
 создавай и не переключай, ничего не пушь.
@@ -395,14 +361,14 @@ flowchart TD
 напиши сообщение сам и скажи строкой доклада, что форму коммита не сверял никто.
 Одна задача — один осмысленный коммит.
 
-### 11. Закрыть задачу — **после коммита, не раньше**
+### 10. Закрыть задачу — **после коммита, не раньше**
 
 **Вызови Skill `av-dev:task-track`** и попроси закрыть задачу как реализованную —
 он владеет форматом и двигает строку индекса сам. Путь к его скрипту не выясняй и
 индексы руками не правь: мост между плагинами — вызов скилла, а не путь.
 
 **Порядок обязателен.** Закрытие удаляет файл задачи; сделанное до коммита оно
-оставило бы задачу закрытой без единого следа работы, если шаг 10 упадёт.
+оставило бы задачу закрытой без единого следа работы, если шаг 9 упадёт.
 
 **Закрытие тоже коммитится — вторым коммитом, тут же.** Удаление файла задачи и
 правка индексов (их имена знает `av-dev:task-track`, не ты) — это правки в рабочем
@@ -443,8 +409,8 @@ change. Заводить запись задним числом, чтобы её
   улучшений заодно.
 - **Занизить метку ревью, пропустить тему или проскочить чекпоинт — самый дешёвый
   способ «ускориться», и он же самый дорогой по последствиям.** Защита устроена
-  так, что регулятора у тебя нет: метку выбирает разметчик **до того**, как ты
-  написал код, план сверяется по темам, непокрытое называется строкой, а
+  так, что регулятора у тебя нет: метку выбирает **не ты, а разметчик, и выводит
+  её из диффа**, план сверяется по темам, непокрытое называется строкой, а
   расхождение с одобренным — отдельным пунктом доклада.
 - **Заведение задач из урожая ревью — не твоя работа.** Отложенные находки
   отдаются **списком**; превращает их в задачи `av-dev:task-track`, у него на