Пайплайн нескольких задач снят с повестки: работаем по одной. Каталог
скилла удалён, и с ним всё, что держалось только на нём.
Хвосты были не только ссылками. У review-specs исчез третий режим
(стык после слияния) — вместе с исключением «живого change нет, берём
актуальные спеки источником»: теперь отсутствие дельта-спеки это отказ.
У review-triage исчезло единственное исключение из правила «плана нет —
не запускаюсь». В каноне и у doc-code-drift имя основной ветки
обосновывалось тем, что «в неё вливает батч», — довод заменён на
верный.
"description":"Проведение задачи через полный цикл Spec Driven Development и конвейер ревью с детерминированным гейтом, сверкой со спеками, враждебными постановками, эксплуатационным постмортемом, независимой реализацией и обязательным триажем; плюс прогон нескольких задач разом по одной в изолированном worktree. Требует OpenSpec и сам его заводит скиллом openspec. Задача принимается и обычным текстом. Плагины av-dev-docs и av-dev-tasks опциональны: первый даёт документы канона, из которых проходы читают проектную конкретику, второй — учёт задач; без них прогон деградирует поразрядно и называет это строкой.",
"description":"Проведение задачи через полный цикл Spec Driven Development и конвейер ревью с детерминированным гейтом, сверкой со спеками, враждебными постановками, эксплуатационным постмортемом, независимой реализацией и обязательным триажем. Требует OpenSpec и сам его заводит скиллом openspec. Задача принимается и обычным текстом. Плагины av-dev-docs и av-dev-tasks опциональны: первый даёт документы канона, из которых проходы читают проектную конкретику, второй — учёт задач; без них прогон деградирует поразрядно и называет это строкой.",
description:"Сверка изменения с дельта-спеками в обе стороны — spec→code (каждое требование реализовано и подтверждено тестом) и, что важнее, code→spec (поведение, которое код имеет, а спека не заказывала: тихие ветки, самодеятельные дефолты, проглоченные ошибки, отброшенные поля, ретраи «на всякий случай»). Плюс границы спеки — что она не определяет и что пришлось домыслить. Работает в трёх режимах: дизайн/спеки ДО кода, код против спек ПОСЛЕ apply и стык после слияния нескольких задач, когда change уже заархивированы. Только чтение."
description:"Сверка изменения с дельта-спеками в обе стороны — spec→code (каждое требование реализовано и подтверждено тестом) и, что важнее, code→spec (поведение, которое код имеет, а спека не заказывала: тихие ветки, самодеятельные дефолты, проглоченные ошибки, отброшенные поля, ретраи «на всякий случай»). Плюс границы спеки — что она не определяет и что пришлось домыслить. Работает в двух режимах: дизайн/спеки ДО кода и код против спек ПОСЛЕ apply. Только чтение."
tools:Read, Grep, Glob, Bash
model:opus
color:yellow
@@ -63,11 +63,9 @@ Development на OpenSpec). Оптика — требования, а не ст
намерение, а спека нормирует. Расхождение между proposal и дельтой — само по себе
находка.
**Исключение — режим 3 (ниже): живого change нет.** Тогда источник требований —
**актуальные**`openspec/specs/<capability>/spec.md`, а дельты поднимаются из
архива (`openspec/changes/archive/<id>/specs/`) как свидетельство о намерении
каждой слитой задачи. Задание обязано назвать этот режим явно; не названо —
работаешь по режиму 1 или 2 и говоришь в границах покрытия, что change не нашёл.
**Живого change нет — ты не запускаешься.** Оба режима стоят на дельта-спеке; без
неё сверять нечего, и это строка отказа, а не повод взять источником актуальные
спеки: они описывают, что система делает вообще, а не что заказало это изменение.
Дополнительно поднимаешь **с метки `medium`**: `design.md` и `tasks.md`
change, затронутые актуальные спеки. Инварианты из `CLAUDE.md` — при любой метке. Если тема ещё не перенесена в спеки и живёт только в
description:"Конвейер ревью изменения, устроенный по темам: документ проекта либо заводит тему ревью, либо питает чужую тему источником, либо процессный и в ревью не читается вовсе. Ядро тем — requirements, autotests, conventions, architecture, security, operations; список тем открытый, свои темы проект заводит документом. Разметка задачи идёт один раз, после propose: агент review-scope выводит размер и сложность, из их максимума — метка, и раздаёт темы проходам обеих стадий. Метка правит и ревью дизайна (small — только specs; medium — плюс rubric; large — плюс architecture), и ревью кода (small — гейт, спеки, код, триаж; medium — плюс приёмник тем; large — плюс доказательство: враждебные постановки, эксплуатационный постмортем, архитектурный проход на широком входе). Триаж обязателен всегда. Порядок прогона — граф зависимостей: гейт открывает опиниативные проходы, проходы с пометкой «держит машину» идут цепочкой, триаж — единственный сток. Проектная специфика приходит из документов канона av-dev-docs. Вызывается из task-pipeline (чекпоинты ревью) и из task-batch (финальная сверка)."
description:"Конвейер ревью изменения, устроенный по темам: документ проекта либо заводит тему ревью, либо питает чужую тему источником, либо процессный и в ревью не читается вовсе. Ядро тем — requirements, autotests, conventions, architecture, security, operations; список тем открытый, свои темы проект заводит документом. Разметка задачи идёт один раз, после propose: агент review-scope выводит размер и сложность, из их максимума — метка, и раздаёт темы проходам обеих стадий. Метка правит и ревью дизайна (small — только specs; medium — плюс rubric; large — плюс architecture), и ревью кода (small — гейт, спеки, код, триаж; medium — плюс приёмник тем; large — плюс доказательство: враждебные постановки, эксплуатационный постмортем, архитектурный проход на широком входе). Триаж обязателен всегда. Порядок прогона — граф зависимостей: гейт открывает опиниативные проходы, проходы с пометкой «держит машину» идут цепочкой, триаж — единственный сток. Проектная специфика приходит из документов канона av-dev-docs. Вызывается из скилла resolve — двумя чекпоинтами: ревью дизайна до кода и ревью кода после apply."
description:Проводит несколько задач разом — планирует порядок и пересечения, гонит каждую задачу отдельным сабагентом в своём git worktree через task-pipeline (по умолчанию по одной задаче за раз; параллельно по графу зависимостей — по явной просьбе), интегрирует по одной ветке через rebase + fast-forward (линейная история), проверяет полноту ревью каждой ветки и в конце сверяет стыки, возникшие от слияния. Набор задач приходит извне. Использовать, когда просят сделать несколько задач сразу.
---
# Батч задач
Оркестратор **набора** задач. Планирует порядок, раскидывает задачи по
изолированным worktree, каждую проводит через полный цикл
`av-dev-pipeline:task-pipeline`, затем сводит в основную ветку линейной историей
и делает финальную сверку. Тонкая обёртка над пайплайном задачи — не
переизобретай её шаги, вызывай как есть.
**По умолчанию задачи идут по одной**, в порядке зависимостей. Параллельно — по
явной просьбе, и тогда параллельность **по графу зависимостей**: одновременно
гонится только то, между чем нет ни зависимости, ни пересечения. Правило и его
цена — в шаге 4.
Работай **максимально автономно**, по тому же принципу, что и одиночный пайплайн:
вопрос, который решать не тебе, записывается и не останавливает поток; спрашиваем
только про **необратимое** (деплой, выкладка наружу, удаление или перезапись
рабочих данных). Механику — планирование, worktree, rebase, интеграцию, чистку —
делаем без спроса.
## Предпосылки
- **OpenSpec и скиллы `opsx:*`** — на них стоит цикл внутри каждого сабагента и
проход `review-specs` финальной сверки. Проекта без OpenSpec это касается так
же, как одиночного пайплайна (см. его раздел «Предпосылки»).
- **Проектные копии этих скиллов и агентов при установке плагина удаляются.**
### Обращение к соседним плагинам
**Копия.** Дом — `shared/plugin-boundary.md` в репозитории плагинов. Правится
дом, а не этот файл.
<!-- копия: граница-плагинов из shared/plugin-boundary.md -->
Плагины `av-dev` ставятся порознь, и ни один не вправе считать, что сосед на
месте.
**Чужой скилл зовётся полным именем** — `av-dev-docs:canon`,
`av-dev-tasks:tasks`, `av-dev-pipeline:review-pipeline`. Короткое имя может
разрешиться в устаревшую проектную копию из `.claude/skills/`, и подмены не будет
видно ни в докладе, ни в поведении.
**Путь в дерево чужого плагина не пишется никогда.**`$CLAUDE_PLUGIN_ROOT` ведёт
только в свой плагин; вычисленный от него путь к соседу либо не откроется, либо
откроет чужую установку. Нужен чужой справочник — зови владеющий им скилл, он
прочитает его сам.
**Вызов не разрешился — плагина в проекте нет.** Это исход, а не поломка: назови
строкой доклада, чего теперь не делает никто, и продолжай работу. Молчать нельзя,
пропуск неотличим от сделанного; выдумывать обходной путь нельзя тоже.
**Присутствие узнаётся вызовом или следом в проекте, но не объявлением.** Перечня
установленных плагинов проект не ведёт — он разошёлся бы с действительностью
молча. Что сосед здесь работал, видно по заведённому им файлу: `docs/.pm.json` —
Темы, которых в этом списке нет (`autotests`, `conventions`, `security`,
`operations`, свои темы проекта), назови строкой «не проверяется на сверке
стыка: закрыто прогонами отдельных задач». Это не формальность — без такой
строки отчёт сверки читается как полное ревью ветки.
Граф этой сверки — веер в один сток, и он такой же, как у обычного прогона:
```mermaid
flowchart TD
merged["основная ветка после всех интеграций<br/>(финальный гейт зелёный)"]
s1["review-specs: capability 1<br/>режим «стык после слияния»"]
s2["review-specs: capability 2<br/>режим «стык после слияния»"]
arch["review-architecture на интегрированном диффе<br/>(если задачи пересекались по файлам)"]
tri["review-triage — сток"]
merged --> s1 --> tri
merged --> s2 --> tri
merged --> arch --> tri
```
Замечания отрабатывай как одиночный пайплайн: `инлайн` чини сам, `развилка` —
вопросом в запись; после правок — снова гейт.
### 9. Прибраться и доложить
- Убери worktree и ветки **только успешно влитых** задач, в конце
`git worktree prune`. Worktree и ветки **провалившихся** не трогай — они нужны
для ручного дожатия.
- **Записей учёта батч не трогает** — их правит пайплайн внутри сабагента на
шаге 12. Батч сообщает исход по каждой задаче; если какой-то сабагент дошёл до
коммита, но закрытия не сделал (плагина нет, вызов не разрешился), скажи это
строкой — иначе задача останется открытой молча.
- Доложи кратко:
- **исход по каждой задаче** одним из трёх слов, с хешем коммита;
- **режим прогона** — по одной или волнами, и если волнами, то по чьей просьбе;
порядок задач или состав волн, порядок интеграции, с пометкой, какие задачи
шли по одной как замеряющие;
- вопросы, записанные сабагентами, пачкой;
- что дозапускалось на шаге 5 и почему; шло ли где-то ревью инлайн;
- итог финальной сверки и ссылки на архивные change;
- **`Урожай`** — отложенные находки всех задач одним списком, с провенансом.
Задачи из него заводит тот, кто ведёт задачи проекта, а не батч;
- **отдельно — провалившиеся** задачи с настоящей причиной и путём к
оставленному worktree;
- **границы покрытия сводной строкой**, включая задачи, чьи замеры снимались в
общей волне, и ветки, где ревью шло инлайн.
## Тонкости
- **Изоляция параллельных тестов — цена параллельного режима, и проверяется она
до первой волны.** Прежде чем гнать несколько прогонов разом, убедись, что
тесты не делят фиксированный порт или файл БД (обычно берут временный каталог и
эфемерный порт — тогда ок). Делят — такие задачи гони по одной, даже если
просили параллельно, и скажи об этом строкой: просьба про параллельность, а не
про сломанные тесты. В умолчательном режиме вопрос не встаёт вовсе — это одна
из причин, по которым умолчание такое.
- Поведенческая верификация внутри сабагента поднимает изменение вживую: в
параллельном режиме следи, чтобы соседние worktree не дрались за порты и
рабочие каталоги. Если проект умеет поднимать только один экземпляр — такие
задачи в одну волну не ставь.
- Ревью выполненного — **до** интеграции; это забота
`av-dev-pipeline:task-pipeline` внутри каждого сабагента, дублировать не надо.
- `openspec validate --strict` тоже внутри пайплайна задачи — не пропускай его
своими правками на интеграции.
- Крупная переработка, предложенная ревью внутри задачи, — развилка: не вливай
молча, вынеси в доклад.
- Держи вызывающего в цикле короткими репликами на переходах фаз (план → прогон
задач → интеграция → финальная сверка), но не проси подтверждать механику.
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
