High Pipeline

---
name: high-pipeline
description: "Конвейер реализации на пресете high-pipeline — ТЗ пишет Opus 5.5 на high, ТЗ критикуют Sonnet 5.5 high, DeepSeek V4.1 Flash в pi и devin на SWE-2 max, код пишет Opus 5.5 на high, приёмку начинают три линзы GLM 5.3 Flash в pi, Grok 4.7 на xhigh в своём агентном харнессе зовётся только при их находке, а при чистых линзах порцию коммитит оркестратор; основной контекст только маршрутизирует, носит вопросы автору и ведёт журнал. Вызывай, когда шаг спеки или фичу надо провести через ТЗ, критику, реализацию и независимую приёмку и нужен расклад по умолчанию — квоты подписки уходит немного, внешних денег около четырёх долларов на задачу. Запускай только по явному имени: маршрутом карточки Listik (launch_route или метка process:<ключ>) или когда человек назвал пресет; по сходству задачи сам не подхватывай."
argument-hint: "[путь к <id>.<X>.md или описание задачи]"
license: MIT
---

# Конвейер high-pipeline

Пресет по умолчанию. Сторона автора — внутри подписки Anthropic (ТЗ и код), проверяющие —
снаружи и от других вендоров (критики DeepSeek в pi и devin SWE-2, линзы приёмки GLM в pi, судья SpaceXAI по их находкам),
кроме критика Sonnet 5.5 high: он той же семьи, что автор ТЗ (Opus, Anthropic), поэтому кворум критики требует хотя бы одного
не-Anthropic критика. Платишь ровно за независимость
приёмки; обоснование расклада — в [ROLES.md](../../references/ROLES.md) и
[presets-2026-09-24.md](../../references/presets-2026-09-24.md): Opus 5.5 обходит Fable 5.1 на каждом
усилии (Opus high — II 53.6 / TB4 .566 против Fable medium 48.9 / .449), поэтому Fable из пресета убран.
Внешних денег ≈ $4 на задачу (оценка AA).

**Прочитай [pipeline-core.md](../../references/pipeline-core.md) целиком до первого действия.**
Там всё, что у пресетов общее: твоя роль, жёсткие правила, протокол вопросов, шаг 0, треки,
сборка пакета диффа, пределы на порцию, журнал и общие грабли. Ниже — только то, чем high-pipeline
отличается: кто делает каждый этап и как его позвать.

Скил запускается только по явному имени — маршрутом карточки Listik (`launch_route` или метка
`process:high-pipeline`) или человеком (`/feature-pipeline:high-pipeline`); по сходству задачи сам его не подхватывай. Запуск скила — согласие
автора на отправку **ТЗ, чек-листа и диффа порции** наружу: критикам — шаг, ТЗ и чек-лист, код на чтение, линзам приёмки (GLM в pi) и судье —
дифф. Секреты в ТЗ не пропускает этап 1, в дифф — границы правки порции. Все команды — из корня
основного дерева.

## Роли

| Этап | Кто | Модель и усилие | Первая строка отчёта |
| --- | --- | --- | --- |
| 1. ТЗ и чек-листы | субагент `feature-pipeline:pipeline-spec-writer` | **`model: opus` в вызове** (frontmatter — opus, effort high) → Opus high | `готово` или `вопрос` |
| 2. Критика ТЗ | три критика одним сообщением: `sonnet` — `Agent` `feature-pipeline:pipeline-critic`, **`model: sonnet` в вызове**, фоном; `deepseek` — скил `pi:pi-delegate`, фоновой задачей; `devin` — скил `devin:devin-delegate`, фоновой задачей | Sonnet 5.5 high; канал `deepseek` (DeepSeek V4.1 Flash), `--permission read`; devin `--thinking max` (SWE-2 max), `--permission read`; кворум — `sonnet` и хотя бы один из `deepseek`, `devin` | по файлу на критика, потом твоя сводка `review-<X>.md` с разделами «Блокирующие» и «Существенные» |
| 3. Реализация | субагент `feature-pipeline:pipeline-implementer-high` | **`model: opus` в вызове** (frontmatter — Sonnet, effort high) → Opus high | `готово`, `не смог` или `вопрос` |
| 4. Приёмка: линзы | скил `pi:pi-delegate`, три фоновые задачи одним сообщением, на заходе `r1` | канал `glm` (`--channel glm`, GLM 5.3 Flash); `scope` — `--permission bash`, `holes` и `intent` — `--permission read` | по файлу на линзу, первая строка `чисто` или `находки` |
| 4. Приёмка: судья | `/grok:delegate`, фоновой задачей — только при находке линз, при «Критичных инвариантах» и на заходах `r2`+ | `--model grok-4.7 --effort xhigh` | `зелёный` с хешем или `красный` |

Оба Claude-субагента **перебивают параметром `model: opus` в вызове**: у автора ТЗ во frontmatter
`opus` + `high`, у исполнителя — `sonnet` + `high`. `model` перебивает frontmatter, усилие остаётся
из него — так и получается Opus high на обоих этапах. Забудешь `model` — код напишет
Sonnet, то есть уже другой пресет. Усилие меняется только сменой агента.

## Нужные скилы

Стоп, если нет хотя бы одного — раздел «Внешние скилы» `pipeline-core.md`. Скрипты из кэша не зови.

- [`pi:pi-delegate`](../../../pi/skills/pi-delegate/SKILL.md) (`plugins/pi/skills/pi-delegate/SKILL.md`) — критика ТЗ, канал `deepseek`, и линзы приёмки, канал `glm`; [`pi:pi-check`](../../../pi/skills/pi-check/SKILL.md) — готовность обоих; [`pi:pi-jobs`](../../../pi/skills/pi-jobs/SKILL.md) — забор ответов критика и линз; [`pi:pi-runtime`](../../../pi/skills/pi-runtime/SKILL.md) — контракт;
- [`devin:devin-delegate`](../../../devin/skills/devin-delegate/SKILL.md) (`plugins/devin/skills/devin-delegate/SKILL.md`) — критика ТЗ, `--thinking max`, `--permission read`; [`devin:devin-check`](../../../devin/skills/devin-check/SKILL.md) — готовность; [`devin:devin-jobs`](../../../devin/skills/devin-jobs/SKILL.md) — ход и забор; [`devin:devin-runtime`](../../../devin/skills/devin-runtime/SKILL.md) — контракт;
- `/grok:delegate` — этап 4 и предполётный прогон судьи; `/grok:setup` — готовность, если прогон
  упал не на балансе; `/grok:status` и `/grok:result` — ход и забор; `grok:grok-cli-runtime` — контракт;
- [`listik:listik`](../../../listik/skills/listik/SKILL.md) (`plugins/listik/skills/listik/SKILL.md`) — карточка, этапы, журнал, вопросы автору.

## Префикс

```
STEPS=docs/specs/steps
BASE=<id>        # без карточки — adhoc-<ГГГГ-ММ-ДД>-<слаг>
WT=.             # в треке — абсолютный путь дерева трека
```
`<X>` — буква порции, `<R>` — номер захода приёмки, `JOB` — id фоновой задачи судьи.

## Предполётная проверка — до этапа 1

**Стоп-фактор.** Любая роль недоступна (предполётная проверка не прошла, харнесс не установлен или не залогинен, запуск упал, ответила не та модель) — конвейер стоит: журнал `стоп: <роль> — <харнесс> недоступен: <причина>`, `listik needs-owner <id> "<вопрос>"` и тот же вопрос в чат, и больше ничего. Запасного исполнителя нет: роль не подменяется ни другим харнессом, ни другой моделью, ни локальным субагентом, в headless тоже (`pipeline-core.md`, «Стоп-фактор»). Повтор того же харнесса и той же модели в той же роли — не подмена. Исключение — критики этапа 2: они идут по кворуму, и выбывший критик не стоп, пока кворум пресета набран (`pipeline-core.md`, «Критика ТЗ»).

Все внешние каналы — здесь, не когда понадобятся. Скилов нет — уже стоп по ядру. Готовность:
критиков — `pi:pi-check` полной пробой для `deepseek` и `devin:devin-check` для `devin`; у Sonnet предполёта нет; выбывание критика на предполёте — по ядру (`pipeline-core.md`, «Критика ТЗ»); судья — **настоящим коротким прогоном** через
`/grok:delegate` без `--background`:

```
/grok:delegate --no-web --model grok-4.7 --effort low Ответь ровно одним словом: ok
```

Вернулось `ok` — канал живой. Вернулся 402 или другая ошибка — **стоп и вопрос автору** с текстом
ошибки дословно: без судьи порция дойдёт до приёмки и застрянет в рабочем дереве без коммита.
Сам судью не подменяешь.

Канал `glm` в критике больше не участвует, но нужен линзам приёмки: его проверяет та же полная проба
`pi:pi-check` (смотришь `ok` и `glm`, и `deepseek`) — отдельного прогона не надо; судейский предполёт выше остаётся: судья может понадобиться.

## Этапы

### 1. ТЗ и чек-листы — `pipeline-spec-writer`, `model: opus`, один раз на шаг

`Agent` `feature-pipeline:pipeline-spec-writer`, **`model: opus`** — обязательно, в каждом запуске и в
режиме правки. В задаче:
путь к спеке **или** текст автора; `$STEPS`; имя бумаг `<id>`. В треке добавь **границу этого трека** —
каталог или слой, за который его ТЗ не выходит, словами автора. Правила порций, границ
и чек-листов агент знает сам — не пересказывай.

`вопрос` — протокол вопросов. `готово` — в журнал `шаг <id>: старт, пресет high-pipeline,
порций <K>`; допущения агента, если он их назвал, покажи автору одной репликой: молчание —
согласие.

### 2. Критика ТЗ — Sonnet + DeepSeek + devin

**Стоп-фактор.** Критики этапа идут по кворуму, а не по правилу недоступной роли: выбывший критик (запуск упал, не залогинен, ответила не та модель, ответ негоден или не пришёл за окно) — не стоп, пока кворум пресета набран. Не набран — стоп по ядру: журнал `стоп: критика — кворум не набран: <кто не дал годного ответа и почему>`, `needs-owner` и тот же вопрос в чат (`pipeline-core.md`, «Критика ТЗ»).

Состав — три критика: `sonnet` — `Agent` `feature-pipeline:pipeline-critic` с **`model: sonnet` в вызове** (Sonnet 5.5 high), фоном; `deepseek` — `pi:pi-delegate`, канал `deepseek` (DeepSeek V4.1 Flash), `--permission read`, фоновой задачей, ответ — `result` через `pi:pi-jobs`; `devin` — `devin:devin-delegate` с `--thinking max` (SWE-2 max), `--permission read`, фоновой задачей, ответ — `result` через `devin:devin-jobs`. Кворум — годный ответ `sonnet` и хотя бы одного из `deepseek`, `devin`: Sonnet той же семьи, что автор ТЗ, и без не-Anthropic критика кворума нет. Все три запускаются одним сообщением, с одним заданием.
Проверка на секреты, старые ответы, запуск, задание, окно 15 минут, забор, годность, повтор, журнал выбывших и правила сведения в `$STEPS/$BASE.review-<X>.md` — `pipeline-core.md`, «Критика ТЗ».

Дальше как в локальном конвейере: решение по сводке — твоё, по ядру (`pipeline-core.md`, «Решение по сводке»): каждому пункту
`принять`, `отклонить` или `автору` в `$STEPS/$BASE.decisions-<X>.md`, автору — только пункты `автору`, строка в журнал.
Есть `принять` или `автору` — **автору ТЗ**: возобнови `pipeline-spec-writer` через `SendMessage` с путями к
`$STEPS/$BASE.decisions-<X>.md` и `$STEPS/$BASE.review-<X>.md`; после `/clear` — новый запуск в режиме правки
(`model: opus`, пути к порции, чек-листу, файлу решений и сводке). Одна критика на порцию, поправленное ТЗ не критикуется.

### 3. Реализация — `pipeline-implementer-high`, `model: opus`

`Agent` `feature-pipeline:pipeline-implementer-high`, **`model: opus`**. В задаче — путь к порции
`$STEPS/$BASE.<X>.md`, по одной за раз; право записи у агента в определении. В треке первой
строкой абсолютный путь дерева трека. Есть карточка — строка `Listik, карточка <P>` (id буквально) идёт в задачу первой строкой, в треке — второй,
сразу после пути дерева трека; карточки нет (`Listik: карточки нет`) — строки нет (`pipeline-core.md`, раздел
`## Listik`). Сессия выдаёт карточку себе и держит страховочные `claim`/`heartbeat`, а `claim`/`journal`
субагент пишет сам по скилу `listik:listik`. На повторе после красного — **тот же** субагент через
`SendMessage` по его agent id, красные пункты судьи **дословно**; продолжить нельзя (agent id
потерян после `/clear`, `SendMessage` отказал) — **новый** субагент с текущим текстом задачи
и теми же пунктами дословно, строкой в журнал (`pipeline-core.md`, «Шаг 0 — конфиг»).

`вопрос` — протокол вопросов, агент доделает после ответа. `не смог` — повтор **его
формулировкой**, не твоим пересказом, в пределах бюджета. `готово` с непустым разделом «открытые
вопросы и расхождения» — не остановка: покажи их автору одной репликой вместе с итогом этапа
и иди на этап 4.

### 4. Приёмка — линзы GLM в pi, по находкам судья Grok 4.7 xhigh

**Стоп-фактор.** Харнесс этапа недоступен (запуск упал, не залогинен, ответила не та модель) — конвейер стоит: журнал `стоп: <роль> — <харнесс> недоступен: <причина>`, `needs-owner` и тот же вопрос в чат; подмены другим харнессом, моделью или локальным субагентом нет (`pipeline-core.md`, «Стоп-фактор»).

Приёмку начинают дешёвые линзы, судья зовётся по их находкам. Когда судья зовётся, вердикт и коммит —
его: он единственный видит требования, чек-лист и код одновременно. Подсказок «это не дефект» ему не
давай: находку разрешаешь ты по отчёту.

**Первый заход (`r1`) — линзы.** Пакет диффа, проверка дампа на секреты, отпечаток дерева, три линзы
через `pi:pi-delegate` каналом `glm` одним сообщением, их забор, отпечаток после и развилка — строго по
`pipeline-core.md`, «Приёмка линзами»: команды и задание линзе там, здесь они не повторяются. Там же —
как выдать карточку себе перед линзами. На заходах `r2` и дальше линзы не запускаются: повтор приёмки
после красного идёт сразу судьёй.

**Линзы чисты и в чек-листе нет «Критичных инвариантов»** — судья не запускается. Коммитишь ты, по
ядру (пути, сообщение, `git show`), и сам ставишь в карточку `VERDICT: PASS` с хешем — команда там же.
После коммита — та же проверка, что после зелёного судьи: `git -C "$WT" log --oneline -1`. Дальше —
как после зелёного вердикта (ниже).

**Находки линз, «Критичные инварианты» или заход `r2`+ — судья.** На `r2`+ пакет диффа собирается по
`pipeline-core.md` («Пакет диффа для приёмки»). Выдай карточку судье заново — `claim` и вердикт он
пишет сам, за него — нельзя:

```
listik stage <P> --to s4-judge --holder grok --actor agent:claude --harness claude
```

и запусти судью. **Вызови `/grok:delegate`** с `--background`, `--write`, `--no-web`,
`--model grok-4.7`, `--effort xhigh`, каталог `$WT`. На `r1` в задание идут абсолютные пути трёх
файлов линз. Как ждать и забирать — `/grok:status` и
`/grok:result`: ждать финальной фазы `done`/`failed`/`cancelled`, не пропажи `running`, не дольше
трёх часов; предел исчерпан — стоп, строка в журнал и вопрос автору.

Задание, которое уходит в `/grok:delegate`:

```
Ты — приёмка одной порции ТЗ и последняя инстанция по ней. Кода ты не правишь никогда: твой
результат — вердикт и, если он зелёный, коммит.

Пути (подставлены буквально): чек-лист приёмки, файл порции, пакет диффа; при повторном заходе —
ещё дамп предыдущего захода, тогда смотри разницу, а не всю порцию заново. На первом заходе с
находками линз — ещё три файла линз: `…lens-<X>.scope.md`, `…lens-<X>.holes.md`,
`…lens-<X>.intent.md`.

Порядок: прочитай порцию и чек-лист. Прогони каждый пункт чек-листа по факту — открой код,
запусти команду, посмотри вывод; «выглядит сделанным» не считается. Прочитай пакет диффа и ищи
срезанные углы: правку тестов под реализацию, ослабленные ассерты, скипы и xfail, отключённые
правила линтера, заглушенные гарды, выход за границы правки порции, правки не по теме порции.
Прогони команды из раздела «Проверки порции» чек-листа — это минимум. Полный набор тестов сверх него — на твоё усмотрение: гоняй, если дифф задевает общий код, от которого зависит многое, конфиг сборки/тестов или зависимости, либо узкий запуск вызывает сомнение; в ответе строкой — запускал ли и почему. Дифф не трогает исполняемый код (документация, тексты, комментарии) — тесты не запускай вовсе, строкой «код не менялся». Раздела в чек-листе нет — минимум определи сам тем же правилом.

Находки линз — сигнал, не вердикт. Каждую проверь по факту — команда, вывод, `path:line` — и поставь
исход: `чинить` — дефект порции, пункт красного списка; `вынести` — реальная проблема вне требований
или границ порции, строка `вынести: <заголовок> — <суть, path:line>`, зелёный не блокирует;
`отбросить` — не подтвердилась, строка `отбросить: <находка> — <почему>`. Весь чек-лист и срезанные
углы проверяешь сам, как без линз: их чистота твою проверку не заменяет.

Чек-лист содержит непустой раздел «Критичные инварианты» — по каждому пункту предъяви
конкретный ломающий сценарий (одновременные запросы, повтор доставки, отрицательное
значение и т.п.) с наблюдаемым результатом: логом, состоянием тестовой БД, ответом API.
Пересказ кода без попытки не считается проверкой.

Чек-лист содержит негативный контроль — прогони его и покажи отказ выводом команды; отказа
нет — красный пункт. Порция добавляет или чинит проверку (барьер, `claim`, шлюз, гард,
валидацию, отказ API), а негативного контроля в чек-листе нет — построй сценарий отказа сам и
прогони его.

Каждое число, SHA и цитата в вердикте и отчёте — копией из вывода команды этого захода: хеш — из
`git rev-parse --short HEAD` после коммита, счётчики — из вывода раннера тестов, место в файле —
`path:line`; числа не из вывода в вердикт не идут. Утверждение исполнителя с числом или хешем
сверяй с выводом своей команды, а не принимай на веру.

Вердикт первой строкой:
- `зелёный` — все пункты чек-листа закрыты, проверки зелёные, срезанных углов нет. Тогда сам
  закоммить порцию. `git add` — только новые и изменённые; путь из `git rm` в него не идёт
  (`did not match any files`, не застейджит **ничего**), а коммить `git commit -m
  "<сообщение>" -- <все пути порции, включая удалённые>`. `git show --stat --name-status
  HEAD`: ровно пути порции. Неполный — второй коммит поверх, не `--amend` (запрещён);
  в отчёте оба хеша, вторая строка вердикта — через запятую, последний итоговый. Не
  добавляй `-A` и `.`: в дереве может лежать чужое. Не коммить бумаги шага (каталог ТЗ
  и файлы `*.journal.md`). Не пушить. Не делать reset, stash, checkout файлов, clean, rebase,
  amend и --no-verify. Не трогать .env, *.key, *.pem, credentials.json.
- `красный` — коммита нет. Дальше нумерованный список: пункт чек-листа или найденный срезанный
  угол, каждый — что не так и что именно доделать. Находку про выход за границы правки порции
  ставь первым словом строки `ГРАНИЦЫ:` — дальше её иначе маршрутизирует оркестратор. Остальные
  формулировки уйдут исполнителю дословно, поэтому они про дефект, а не про впечатление.

Ответ — не длиннее 40 строк. Первая строка `зелёный` с хешем коммита или `красный`; дальше:
пункты чек-листа с исходом по каждому / строки `вынести:` и `отбросить:` — отдельными строками
после пунктов чек-листа, по одной на находку / найденные срезанные углы / проверки одной строкой
каждая / что отложено или перенесено. Листинги и логи в ответ не клади.

Listik, карточка <P> (подставь её id буквально): судья берёт её сам и сам пишет вердикт — за тебя его не напишут.
listik
Первым действием: listik claim <P> --holder grok --actor agent:grok --harness grok
Вердикт — сразу после ответа, первой строкой аргумента ровно `VERDICT: PASS` или `VERDICT: FAIL`
(сервер читает только её), дальше хеш коммита или красные пункты дословно, по одному в строке:
  listik comment <P> $'VERDICT: PASS\n<hash7>' -k verdict --actor agent:grok --harness grok
  listik comment <P> $'VERDICT: FAIL\n<пункты дословно>' -k verdict --actor agent:grok --harness grok
Красный вердикт — ещё и release <P>: карточку снова возьмёт исполнитель.
```

Job id из ответа `/grok:delegate` — в журнал и в `JOB=`. Вердикт:

- **зелёный** — судья уже закоммитил, в отчёте хеш. В журнал `порция <X>: готово (коммит
  <hash7>)`, отложенное и перенесённое — отдельными строками. Дальше следующая порция — с этапа 3, если её критика уже прошла параллельно (см. «Цикл» в pipeline-core.md), иначе с этапа 2.
- **строки `вынести:`** в отчёте судьи захода `r1` — и зелёном, и красном — по каждой карточка
  `--discovered-from <P>` по ядру (`pipeline-core.md`, «Приёмка линзами»), id — строкой журнала;
  **строки `отбросить:`** — только в журнал, карточек по ним нет.
- **красный** — коммита нет, `K+1` по ядру (находки линз сами по себе не красное и `K` не
  трогают), порция на этап 3 с пунктами дословно, в пределах бюджета; повтор идёт
  продолжением того же исполнителя через `SendMessage`, новый субагент — только откат (см. этап 3).
- **`failed`, `402` или пустой ответ** — это не красное: вердикта не было. Строка в журнал
  и вопрос автору; порция остаётся незакрытой, следующую не начинаешь.

Проверь после зелёного, что коммит действительно есть: `git -C "$WT" log --oneline -1`. Судья
работает с автоодобрением всех своих инструментов, поэтому его «закоммитил» — утверждение,
которое стоит одной команды проверки.

## Грабли пресета

| Симптом | Причина | Что делать |
| --- | --- | --- |
| Код написан Sonnet вместо Opus | забыт `model: opus` у исполнителя | у `pipeline-implementer-high` во frontmatter `sonnet` — `model: opus` в каждом запуске и повторе |
| Судья упал с 402, порция повисла | баланс Grok Build исчерпан | предполётный прогон судьи до этапа 1; 402 по ходу — вопрос автору, порция не закрывается |
| Фоновая задача не находится по статусу | статус или забор вызваны из другого каталога, чем запуск | тот же каталог во всех вызовах; ход — `/grok:status` и `/grok:result` |
| Судья сказал «зелёный», коммита нет | прогон оборвался после вердикта | `git log --oneline -1` после каждого зелёного; нет коммита — вопрос автору |
| Судья закоммитил бумаги шага | в пакете диффа не исключены `<steps>` и `*.journal.md` | исключения из `pipeline-core.md`, плюс запрет в тексте задачи судье |
| Линза изменила дерево (отпечатки до и после не совпали) | линза `scope` идёт с `--permission bash`, у pi нет песочницы | стоп по ядру: `needs-owner` и вопрос автору, ничего не коммитить, судью не звать |
| После красного снова зовутся линзы | линзы — только на заходе `r1` | повтор приёмки сразу судьёй, без линз |