feat(process): a failed show verdict re-routes to ask without a fresh budget (#726)

A non-green show verdict that found "something to decide" went down the same
path as "fix the code": S6 with a limit of 2. Promoting the task to track:ask
was left to the agent's memory, with no named criterion and no trace, and the
exhausted budget only surfaced on the next S7 - after a fix nobody would read.

The structured verdict now carries `route` (fix | reclassify) and an optional
`criterion` (one of the six show criteria of PROCESS.md section 5). The trust
boundary reads a missing route as fix, rejects one outside the dictionary and
rejects reclassify on a green verdict. `reviewRoute` in process-track.mjs is
the single decision: on a code review of an unconfirmed show it moves the task
to track:ask and S3-spec; on an owner-confirmed show it adds `blocked` and asks
the owner; anywhere else reclassify degrades to fix with a note. The verdict
that spends the last cycle sets review-4 at once; the stage budget is shared
across tracks, so promotion changes the limit (4), not the count.

The "Решение по вердикту" step makes one `process-track.mjs route` call (from
dev, like the track step) and only executes its output: comment from a file,
labels from add/remove lists, status via status-label.mjs as before. The track
step also emits `confirmed` and a `route_note` for the review prompt; the
review document anchor gains a route tail that the old reader still parses;
wait-verdict reports the two new pipeline comments. The guard's own
spent >= limit check stays as the safety net.

Issue: #726
User-Visible: no
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd

docs/process/AUTHOR.md

@@ -60,6 +60,12 @@
   `S7`; на `show` ревьюер спросит, где поведение зафиксировано, — нет ссылки,
   повысь трек до `ask` до `S7`. Классы и следствие печатает пакет задачи
   ([§5](../../PROCESS.md#5-треки-ship-show-ask--метка-владельца)).
+- Вердикт код-ревью `show` с `route: reclassify` конвейер исполняет сам:
+  `track:ask`, `S3-spec` и комментарий с критерием §5 (#726). Дальше — полное ТЗ
+  по §7.1 в теле issue под `## ТЗ` и ревью ТЗ; код остаётся в ветке, код класса A
+  не пушить до `S5`. Бюджет код-ревью не обнуляется, лимит — 4. Подтверждённый
+  владельцем `show` получает `blocked` и вопрос владельцу
+  ([§5](../../PROCESS.md#5-треки-ship-show-ask--метка-владельца)).
 - `track:show`: `S2-analysis` → `S5-ready`, до трёх AC автор пишет в теле
   issue до перехода; ревью ТЗ нет, лимит код-ревью 2. Уместен, когда всё
   сразу: сложность и риск ≤ 3, одна поверхность, нет миграции, нового
@@ -102,8 +108,9 @@
   открытых продуктовых вопросов. На `ship` и `show` пункты DoR закрываются
   словом «нет» ([§2.5](../../PROCESS.md#25-готово-к-разработке-dor)).
 - Лимит — 4 цикла ревью, на `track:show` 2 цикла код-ревью; зелёный вердикт цикла
-  не тратит; исчерпание — решение владельца: разделить, отклонить, арбитраж
-  ([§4](../../PROCESS.md#4-лимит-циклов-ревью-4)).
+  не тратит; бюджет этапа один на все треки задачи; вердикт, исчерпавший
+  бюджет, сразу ставит `review-4`; исчерпание — решение владельца: разделить,
+  отклонить, арбитраж ([§4](../../PROCESS.md#4-лимит-циклов-ревью-4)).
 
 ## Реализация (`S6-in-progress`)
 

docs/process/REVIEWER.md

@@ -125,7 +125,8 @@
 - Вперёд двигает только зелёный вердикт; жёлтый и красный возвращают автору
   ([§7.2](../../PROCESS.md#72-шаблоны-комментариев)).
 - Зелёный вердикт цикла не образует; лимит — 4 цикла, на `track:show` 2;
-  бюджет считается по этапу
+  бюджет считается по этапу и один на все треки задачи; вердикт, исчерпавший
+  бюджет, сразу ставит `review-4`
   ([§4](../../PROCESS.md#4-лимит-циклов-ревью-4),
   [§10.4](../../PROCESS.md#104-событийный-конвейер-метка-как-триггер)).
 - Запрещено: Medium-находки, оставленные как TODO в документе ревью;
@@ -146,11 +147,18 @@
   ветка как есть, кандидат проверит Validate при слиянии
   ([§10.4](../../PROCESS.md#104-событийный-конвейер-метка-как-триггер)).
 - Промпт несёт риск по изменённым участкам: по каждому классу назови документ
-  или AC, где поведение уже зафиксировано; не нашёл — Medium «решать есть что —
-  нужен `track:ask`» с названным критерием. `show`, подтверждённый владельцем,
-  не повышать — вопрос владельцу, вариант по умолчанию «повысить до `ask`»; на
-  `ask` — сверить, что каждый класс покрыт AC ТЗ
-  ([§5](../../PROCESS.md#5-треки-ship-show-ask--метка-владельца)).
+  или AC, где поведение уже зафиксировано; не нашёл — вердикт с
+  `route: reclassify` и названным критерием. `show`, подтверждённый
+  владельцем, конвейер не повышает — `blocked` и вопрос владельцу, вариант по
+  умолчанию «повысить до `ask`»; на `ask` — сверить, что каждый класс покрыт
+  AC ТЗ ([§5](../../PROCESS.md#5-треки-ship-show-ask--метка-владельца)).
+- Поле `route` вердикта (#726): на код-ревью `show` — `reclassify` и
+  `criterion` (`complexity`, `surfaces`, `migration`, `ux-contract`,
+  `perf-touch`, `undocumented`), если задача не проходит критерий §5; иначе и
+  на прочих этапах и треках — `fix`. `reclassify` — только не зелёный вердикт;
+  трек и метки меняет конвейер, не ревьюер
+  ([§5](../../PROCESS.md#5-треки-ship-show-ask--метка-владельца),
+  [§10.4](../../PROCESS.md#104-событийный-конвейер-метка-как-триггер)).
 - Визуальный риск в пути отрисовки плана без `ci:golden`: если задача меняет
   вид, нужен `ci:golden`; иначе — запись в «чего не проверял»
   ([§5.1](../../PROCESS.md#51-метки-тяжёлых-проверок-и-прежние-метки)).