# 4. Границы плагинов (2026-08-03)

## Что было

Связь `tasks` ↔ `pipeline` уже сделана **ролями, а не именами**: скиллы говорят
«пайплайн проекта», «владелец спринта», «тот, кто ведёт задачи». Жёсткая ссылка
по имени ровно одна — `task-pipeline:112` на канонический текст правила про
остаток внутри `session`, и рядом обработан случай «плагин не подключён».

Слоты `CLAUDE.md` при этом дублировались уже внутри одного плагина: шесть у
`tasks`, семь у `session`, три пары — одно и то же. Темы 2–3 растворили ещё
часть: «куда переезжает суть» отвечает канон, «оракулы» — семантика гейта
(решение [Р13](03-review-brief-is-canon.md)), «где живёт разбор процесса» —
`docs/review.md` (решение [Р11](03-review-brief-is-canon.md)). Из тринадцати
остаётся около четырёх.

## Решено

**Р15. Три плагина: `av-dev-pm`, `av-dev-pipeline`, `av-dev-git`.**

- **`av-dev-pm`** (бывший `av-dev-tasks`) — управление продуктом: канон
  документов, задачи, цели, спринты, старт и адаптация проекта. Владеет всем
  `docs/`, включая `docs/tasks/`.
- **`av-dev-pipeline`** — исполнение: SDD-цикл, конвейер ревью, девять агентов.
- **`av-dev-git`** — стиль коммитов; работает в любом репозитории.

*Причина (словами владельца):* «пайплайн можно и переиспользовать в других
проектах с более простым подходом к управлению». Это подтверждается разбором:
пайплайн зависит от **файлов канона и от OpenSpec, а не от плагина** `av-dev-pm`.
В чужом проекте нужных файлов нет — включается поразрядная деградация (следствие
16), и это штатный режим, а не поломка.

*Имя:* `pm` = product management, «объединение всех операций по управлению
продуктом», и согласуется с `av-dev-git`.

**Р16. Граница «пайплайн не закрывает задачу» снимается.** Закрывает задачу и
двигает строки между `SPRINT.md` / `BACKLOG.md` / `REJECTED.md` **агент-
оркестратор** — `task-pipeline` и `task-batch`, а не сабагенты внутри них. Зовёт
он `tasks.py` через слот «Команда учёта задач» в `CLAUDE.md`.

Слот, следовательно, **не исчезает, а становится мостом между плагинами** — и
заодно тем, чего в чужом проекте нет, отчего пайплайн там работает как прежде:
докладывает исход, записей учёта не трогает.

**Р17. `av-dev-backlog` помечается устаревшим и остаётся** до перевода jellybit.
*(заменено на [тему 30](30-av-dev-backlog-removed.md): плагин удалён раньше
этого срока — условие пережило свою причину.)* Описание переписывается так,
чтобы не ловить триггер «добавь задачу в беклог» — иначе агент выбирает между
ним и `av-dev-pm` случайно.

## Что из этого следует

**С18. Переименование `av-dev-tasks` → `av-dev-pm`** тянет `plugin.json`,
`marketplace.json` и пространство имён скиллов: `av-dev-tasks:session` →
`av-dev-pm:session`, включая ссылку из `task-pipeline:112`.

**С19. Раздел «Стимулы, которые процесс создаёт» в `session` переписывается.**
Снятая граница выбила механическую опору у трёх защит: «сжать задачу до
остатка», «занизить урожай», «занизить критерии приёмки» — во всех трёх приёмщик
и исполнитель теперь совпадают. Остаются: **отчёт триажа** в
`openspec/changes/<id>/review/` (независимый артефакт, `task-batch` уже сверяет
полноту ревью по нему, а не по прозе исполнителя), **`SPRINT.md` под git** с
видимой историей и **`reopen <slug> --reason`** — закрытие не окончательно,
приёмка человеком на сессии его отменяет. Раздел обязан назвать их поимённо,
иначе обещает защиту, которой нет.

**С20. Конфликт владения `docs/tasks/` снят** — канон и задачи теперь в одном
плагине.

**С21. Скилл `adopt` из `av-dev-tasks` поглощается** скиллом адаптации проекта
уровня канона (требование [Т1](README.md)). Разбирается в [теме
5](05-project-start-lifecycle.md).

**С22. Состав `av-dev-pm`:** `tasks`, `session` (есть), `docs` — ведение канона,
`project` — старт, adopt, check, upgrade ([тема
5](05-project-start-lifecycle.md)).