Medium Pipeline

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

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

Пониженное усилие на понятную работу. Сторона автора — внутри подписки Anthropic (ТЗ и код),
проверяющие — снаружи и от других вендоров (критик DeepSeek в pi, судья SpaceXAI), кроме критика Sonnet 5.5 high: он
той же семьи, что автор ТЗ (Opus, Anthropic), поэтому кворум критики требует хотя бы одного не-Anthropic критика —
здесь это DeepSeek, и кворум — оба. Отличие от high-pipeline
не в моделях, а в усилии: **экономия идёт понижением effort у Opus (ТЗ и код на medium) и у судьи
(high вместо xhigh), а не сменой моделей на более слабые.** Fable из пресета убран: Opus 5.5
обходит Fable 5.1 на каждом усилии по II, TB4 и Hal и дешевле. Внешних ≈ $3 на задачу; обоснование
расклада — в [presets-2026-09-24.md](../../references/presets-2026-09-24.md) и [ROLES.md](../../references/ROLES.md).

Судья на high — **сознательный размен на цену, а не недосмотр**: `grok-4.7` xhigh против high даёт
+0.1 II и +.011 TB4 за +37 % денег, и в этом пресете надбавку не платят. Medium у судьи не берём:
Grok 4.7 medium в Artificial Analysis не замерен. Со стороны ТЗ: писатель и разработчик — один
Opus medium, так что ТЗ глубже реализации тут не уйдёт.

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

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

## Роли

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

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

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

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

- [`pi:pi-delegate`](../../../pi/skills/pi-delegate/SKILL.md) (`plugins/pi/skills/pi-delegate/SKILL.md`) — критика ТЗ, канал `deepseek`; [`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) — контракт;
- `/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`, «Критика ТЗ»).

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

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

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

## Этапы

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

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

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

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

**Стоп-фактор.** Критики этапа идут по кворуму, а не по правилу недоступной роли: выбывший критик (запуск упал, не залогинен, ответила не та модель, ответ негоден или не пришёл за окно) — не стоп, пока кворум пресета набран. Не набран — стоп по ядру: журнал `стоп: критика — кворум не набран: <кто не дал годного ответа и почему>`, `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`. Кворум — годные ответы обоих: Sonnet той же семьи, что автор ТЗ, а не-Anthropic критик в составе один. Оба запускаются одним сообщением, с одним заданием.
Проверка на секреты, старые ответы, запуск, задание, окно 15 минут, забор, годность, повтор, журнал выбывших и правила сведения в `$STEPS/$BASE.review-<X>.md` — `pipeline-core.md`, «Критика ТЗ».

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

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

`Agent` `feature-pipeline:pipeline-implementer`, **`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. Приёмка и коммит — Grok 4.7 high фоновой задачей

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

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

Собери пакет диффа по `pipeline-core.md` («Пакет диффа для приёмки»), выдай карточку судье
(`listik stage <P> --holder grok --actor agent:claude --harness claude`; `claim` и вердикт он пишет сам,
за него — нельзя) и запусти судью. **Вызови `/grok:delegate`** с `--background`, `--write`, `--no-web`,
`--model grok-4.7`, `--effort high`, каталог `$WT`. Как ждать и забирать — `/grok:status` и
`/grok:result`: ждать финальной фазы `done`/`failed`/`cancelled`, не пропажи `running`, не дольше
трёх часов; предел исчерпан — стоп, строка в журнал и вопрос автору.

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

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

Пути (подставлены буквально): чек-лист приёмки, файл порции, пакет диффа; при повторном заходе —
ещё дамп предыдущего захода, тогда смотри разницу, а не всю порцию заново.

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

Чек-лист содержит непустой раздел «Критичные инварианты» — по каждому пункту предъяви
конкретный ломающий сценарий (одновременные запросы, повтор доставки, отрицательное
значение и т.п.) с наблюдаемым результатом: логом, состоянием тестовой БД, ответом 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.
- **красный** — коммита нет, порция на этап 3 с пунктами дословно, в пределах бюджета; повтор идёт
  продолжением того же исполнителя через `SendMessage`, новый субагент — только откат (см. этап 3).
- **`failed`, `402` или пустой ответ** — это не красное: вердикта не было. Строка в журнал
  и вопрос автору; порция остаётся незакрытой, следующую не начинаешь.

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

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

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