ревью: подключить конвейер в task-pipeline и task-batch

Шаг 4 стал профилем design на предложении (архитектурная находка на готовом коде
стоит переписывания и потому игнорируется — на предложении она стоит абзаца),
шаг 7 — вызовом review-pipeline с профилем по факту изменения. Границы покрытия
протаскиваются в финальный доклад строкой.

В task-batch финальная сверка сужена до того, что появилось от слияния:
повторять полный конвейер на интегрированном диффе бессмысленно — те же проходы
на тех же файлах дают те же находки и удорожают триаж.

Заодно убрана ссылка на несуществующий скилл verify: шага не было ни в проекте,
ни у пользователя, поведенческую верификацию делает Skill run.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

.claude/skills/task-batch/SKILL.md

@@ -110,17 +110,18 @@ remote — `git fetch` и синк). Зафиксируй базовый ком
      полный цикл SDD с промежуточными ревью-чекпоинтами.
    - Если задаче на шаге 2 назначен **номер миграции** — используй строго его
      (`internal/store/migrations/<номер>_*`), не бери «следующий свободный» сам.
-   - **Ревью-чекпоинты**: попробуй запустить агентов `jellybit-review-specs` /
-     `jellybit-review-code` через Agent tool (как в `task-pipeline`). Если
-     вложенный запуск сабагента недоступен — проведи ревью **инлайн**, используя
-     charter'ы `.claude/agents/jellybit-review-*.md` как чеклист. Чекпоинт «ревью
-     спек ДО кода» не пропускай.
+   - **Ревью-чекпоинты**: оба идут через Skill `review-pipeline` (профиль
+     `design` до кода, потом профиль по факту изменения). Если вложенный запуск
+     сабагентов недоступен — проведи ревью **инлайн** по тем же charter'ам
+     `.claude/agents/jellybit-review-*.md`, но обязательно сохрани гейт
+     (`task gate` до опиниативных проходов) и триаж; в отчёте прямо укажи, что
+     ревью шло инлайн — это меняет доверие к результату.
    - **Коммит.** `task-pipeline` коммитит в текущую ветку — а это твоя
      `task/<slug>` в worktree, так что специально ничего переопределять не нужно.
      Всё остальное (`opsx:archive`, чистка беклога `docs/backlog/<slug>.md` +
      строка индекса, синк спек/ADR) ложится коммитами туда же. Master не трогай,
      ветку не переключай, ничего не пушь, новых worktree не создавай.
-   - `task test` / `task lint` в своём worktree — добейся зелёного.
+   - `task gate` в своём worktree — добейся зелёного.
    - Верни отчёт: что сделано, какие развилки решались, изменённые файлы,
      **добавлял ли миграцию и её номер**, затронутые capability, статус
      тестов/линта, все неразрешённые вопросы.
@@ -143,7 +144,7 @@ remote — `git fetch` и синк). Зафиксируй базовый ком
   форсируй**: прерви (`git rebase --abort`), оставь ветку/worktree как есть и
   вынеси развилку пользователю (это признак нераспознанного пересечения).
 - `git checkout master && git merge --ff-only task/<slug>`.
-- После каждой интеграции: `task test` (+ `task lint`) на master. **Красное —
+- После каждой интеграции: `task gate` на master. **Красное —
   откати эту интеграцию** (`git reset --hard` на прошлую вершину master), ветку с
   worktree сохрани, вынеси пользователю. Master **никогда** не остаётся
   полузелёным.
@@ -159,28 +160,30 @@ worktree и ветке нетронутой (ничего не удаляем),
 перечисляем провалившиеся с их отчётами и причиной. Пользователь потом решит:
 дожать вручную, переназначить, отложить.
 
-### 6. Финальный гейт — все тесты
+### 6. Финальный гейт
 
-На master после всех интеграций: `task test` + `task lint` (+ `task build`).
-Зелёное — обязательно.
+На master после всех интеграций: `task gate` (+ `task build`). Зелёное —
+обязательно; пока красное, шаг 7 не начинается.
 
-### 7. Финальная сверка кода с требованиями — по затронутым capability
+### 7. Финальная сверка — только то, чего не видел никто
 
-Собери **объединение затронутых capability** по всем задачам. Запусти **по одному
-сабагенту-ревьюверу на каждую затронутую capability, все в одном сообщении**
-(параллельно), `subagent_type: jellybit-review-specs`. Каждому дай:
-- имя capability и путь `openspec/specs/<cap>/spec.md`;
-- интегрированный diff `git diff <база>..HEAD`, сфокусированный на файлах этой
-  capability;
-- задание: сверить **код на master с требованиями** capability — покрытие
-  `### Requirement` (все содержат `SHALL`/`MUST`), сценарии `GIVEN/WHEN/THEN`,
-  инварианты безопасности данных, непротиворечивость код↔спека после слияния
-  нескольких задач (косвенные рассинхроны на стыках).
+Каждая задача уже прошла полный конвейер ревью в своём worktree. Повторять его
+на интегрированном диффе бессмысленно: те же проходы на тех же файлах дадут те
+же находки и удорожат триаж. Здесь проверяется **только то, что появилось от
+слияния** и потому не было видно ни одному прогону:
 
-Опционально, если задач много и они пересекаются, добавь один
-`jellybit-review-code` на весь интегрированный diff (архитектура/конвенции/стиль
-сквозняком). Замечания отрабатывай как в `task-pipeline`: мелочь чини инлайн,
-развилки — на пользователя; после правок — снова `task test`/`task lint`.
+- Запусти **по одному `jellybit-review-specs` на каждую затронутую capability,
+  все в одном сообщении** (параллельно). Задание сузь до стыков: не сверять
+  capability целиком заново, а искать **рассинхрон код↔спека, возникший от
+  слияния нескольких задач** — требование, которое одна задача выполнила, а
+  соседняя незаметно отменила; два change, по-разному описавшие одно поведение.
+- Если задачи пересекались по файлам, добавь один
+  `jellybit-review-architecture` на интегрированный дифф с вопросом «не появился
+  ли второй способ делать то, что уже делается» — именно он возникает, когда
+  две задачи независимо решали похожее.
+
+Замечания отрабатывай как в `task-pipeline`: `инлайн` чини сам, `развилка` — на
+пользователя; после правок — снова `task gate`.
 
 ### 8. Прибраться и доложить