av
bf6a173115
- DECISIONS.md (4040 строк, 65 тем) → decisions/, файл на тему плюс указатель; - буквенные метки решений заменены сквозными Р1–Р234, следствия получили префикс С при прежних номерах: схема букв выродилась до пятибуквенных и сломалась — `АЕАКЛ` была занята и темой 53, и темой 65; - 42 перекрёстные ссылки переписаны под новые номера и стали живыми; где номер означал тему, а слово стояло «решение», формулировка исправлена.
84 lines
6.3 KiB
Markdown
84 lines
6.3 KiB
Markdown
# 7. Раскладка скиллов и доставка скриптов (2026-08-03)
|
||
|
||
## Решено
|
||
|
||
**Р24. Пять скиллов в `av-dev-pm`.**
|
||
|
||
```
|
||
av-dev-pm/skills/
|
||
init/ интервью по брифу → канон нового проекта
|
||
canon/ раскладка: check / adopt / upgrade
|
||
docs/ содержимое канона: ADR из архивного design.md, промоут конвенций,
|
||
запись в research/ и review.md, чистка architecture.md
|
||
tasks/ формат и содержимое задач
|
||
session/ ритуал спринта
|
||
```
|
||
|
||
*Причина отдельного `docs`:* правила ведения содержимого канона обязаны жить у
|
||
владельца канона, а не в шаге синка чужого плагина — иначе проект без пайплайна
|
||
документацию вести не может. Это работает потому, что **вызов скилла через
|
||
пространство имён между плагинами возможен**, в отличие от
|
||
`$CLAUDE_PLUGIN_ROOT`: `task-pipeline` уже зовёт `opsx:propose` и
|
||
`av-dev-pipeline:review-pipeline`. Шаг синка зовёт `av-dev-pm:docs`, а в чужом
|
||
проекте деградирует до прозаического списка.
|
||
|
||
Симметрия, по которой резалось: **раскладка и содержимое разделены и для
|
||
документов, и для задач** — `canon` / `docs`, `tasks` / `session`.
|
||
|
||
**Р25. Скрипты не копируются — живут вместе со скиллами.** Три вызывающих, три
|
||
способа дотянуться:
|
||
|
||
| Кто зовёт | Как |
|
||
| --- | --- |
|
||
| скиллы `tasks`, `canon`, `docs` | `$CLAUDE_PLUGIN_ROOT` — свой плагин, работает всегда |
|
||
| `task-pipeline`, `task-batch` | **вызов скилла** `av-dev-pm:tasks`, а не путь |
|
||
| гейт проекта | путь переменной с умолчанием на канонический путь маркетплейса; пишет `canon adopt`, внятный красный отказ, если не найден |
|
||
|
||
**Слот «Команда учёта задач» всё равно исчезает** — но снимает его не копия, а
|
||
**вызов скилла через пространство имён**. Тот же приём, которым шаг синка зовёт
|
||
`av-dev-pm:docs` (решение Р24): чужой плагин зовёт скилл, скилл разрешает свой
|
||
`$CLAUDE_PLUGIN_ROOT` сам. Путь наружу не выносится вовсе.
|
||
|
||
*Первоначально здесь было решено вендорить `scripts/tasks.py` и
|
||
`scripts/docs.py` в проект. Отменено после проверки фактов:*
|
||
|
||
- **CI нет ни в одном проекте** (ни `.github`, ни woodpecker, ни drone).
|
||
Pre-commit есть только у jellybit — `lefthook` с gofmt/vet/lint/test/gitleaks —
|
||
и гоняется на той же машине, где установлен плагин. Довод «не работает в CI и
|
||
у человека без Claude Code» оказался гипотетическим.
|
||
- **Пара «источник — копия» существует и без вендоринга.** Установленный
|
||
маркетплейс — git-клон; на момент разбора он стоял на `092d07c`, на четыре
|
||
коммита позади `master`, и `av-dev-tasks` с `av-dev-pipeline` в нём
|
||
отсутствовали вовсе. Довод «вендоринг создаёт вторую копию» был слабее, чем
|
||
подан.
|
||
- **Обновление маркетплейса — одна точка на все проекты.** При вендоринге каждый
|
||
проект повышается отдельно, и проекты расходятся друг с другом — ровно та
|
||
разнородность, против которой принято решение [Р6](02-project-doc-canon.md).
|
||
|
||
**Р26. Имени у процесса нет — процесс это `av-dev`.** Маркетплейс уже
|
||
`av-dev-skills`, плагины `av-dev-*`; в `CLAUDE.md` проекта пишется «процесс
|
||
av-dev, канон версии N». Имя, которое нигде не работает, — украшение.
|
||
|
||
## Что из этого следует
|
||
|
||
**С32. Решение P уточняется:** оркестратор закрывает задачи **вызовом скилла**
|
||
`av-dev-pm:tasks`, а не запуском скрипта по пути. Плагина в проекте нет — вызов
|
||
не разрешается, и пайплайн, как прежде, только докладывает исход.
|
||
|
||
**С33. Слот исчезает из двух скиллов** — `tasks` (слот 6) и `session` (слот 7),
|
||
— и из текстов `task-pipeline` и `task-batch`, которые на него ссылаются.
|
||
|
||
**С34. `canon upgrade` отвечает за раскладку и версию в `docs/.pm.json`.**
|
||
Скрипты обновляются обновлением маркетплейса, а не проектом.
|
||
|
||
**С35. Скрипты живут в `av-dev-pm/skills/{tasks,canon}/scripts/`.** `docs.py` —
|
||
в `canon`, потому что раскладку проверяет он.
|
||
|
||
**С36. `canon check` сверяет версию канона проекта с версией установленного
|
||
плагина** и говорит, кто отстал. Это нужно и без вендоринга: маркетплейс —
|
||
git-клон, обновляется явно, и на момент разбора отставал на четыре коммита.
|
||
|
||
**С37. Установленный маркетплейс требует обновления перед любой работой** —
|
||
сейчас в нём нет ни `av-dev-tasks`, ни `av-dev-pipeline`. Это первый шаг выката
|
||
([тема 8](08-rollout-order.md)), иначе проверять будет нечего.
|