av-dev-pipeline стал av-dev-code, review-pipeline — review

Имя описывало устройство, а не предмет: «пайплайн» говорит, что внутри
конвейер, — а плагин занят кодом по задачам, и с появлением чекпоинтов
он уже не конвейер в чистом виде. Набор имён стал параллельным:
docs / tasks / code / git, каждое называет материал.

Заодно review-pipeline стал review — слово ушло из плагина целиком, а
не наполовину; скиллы выровнялись: resolve / review / openspec.

Журнал версий канона переписан вместе со всеми, DECISIONS.md — нет.
Разрез по типу высказывания, а не файла: наблюдение и причина
неприкосновенны, предписание и адрес обязаны оставаться исполнимыми.
Запись версии 10 велит «проверить, что плагин av-dev-pipeline
установлен» — проект, дошедший до неё, выполнил бы невыполнимое.

README.md

@@ -27,7 +27,8 @@
     вычитывают их два отдельных прохода: `task-form` (форма записи) и
     `task-wording` (язык записей);
   - `session` — ритуал между спринтами и ведение спринта.
-- **av-dev-pipeline** — исполнение. **Требует OpenSpec и сам его заводит.**
+- **av-dev-code** — код по задачам: решение одной задачи и его проверка.
+  Владеет `openspec/`. **Требует OpenSpec и сам его заводит.**
   - `openspec` — завести, настроить и **проверить** `openspec/` в проекте:
     `openspec init`, замена примера в `config.yaml` настройкой канонической
     формы, скрипт `openspec.py` (форма файла + сверка слепка с живой версией
@@ -39,7 +40,7 @@
     **чекпоинта вариантов** — способы решить, цена каждого, рекомендация; выбор
     оседает по адресу, который назвала сама задача. Между чекпоинтами — без
     согласований;
-  - `review-pipeline` — конвейер ревью **по темам**: документ проекта либо
+  - `review` — конвейер ревью **по темам**: документ проекта либо
     заводит тему проверки, либо питает чужую тему источником, либо процессный и в
     ревью не читается вовсе. Разметка идёт **один раз на задачу**, сразу после
     `propose`: агент `review-scope` меряет изменение по двум осям — размер и
@@ -57,9 +58,9 @@
 
 ```mermaid
 flowchart TB
-    subgraph pipe["av-dev-pipeline — исполнение, требует OpenSpec"]
+    subgraph pipe["av-dev-code — исполнение, требует OpenSpec"]
         direction LR
-        tp["resolve<br/>2 чекпоинта человеку"] --> rp["review-pipeline<br/>10 агентов-проходов"]
+        tp["resolve<br/>2 чекпоинта человеку"] --> rp["review<br/>10 агентов-проходов"]
         osp["openspec<br/>заводит и проверяет openspec/"]
     end
     subgraph docsp["av-dev-docs — документация, владеет docs/"]
@@ -85,10 +86,10 @@ flowchart TB
     tp --> tasks
 ```
 
-Зависимости **односторонние: `av-dev-pipeline` знает про `av-dev-docs` и
+Зависимости **односторонние: `av-dev-code` знает про `av-dev-docs` и
 `av-dev-tasks`, обратно — нет.** Между собой эти двое тоже не связаны жёстко:
 каждый работает без другого. Как именно зовут соседа и что делают, когда вызов не
-разрешился, — `shared/plugin-boundary.md`: правило нужно семи скиллам в трёх
+разрешился, — `shared/plugin-boundary.md`: правило нужно шести скиллам в двух
 плагинах, и ни один им не владеет. То, что нужно нескольким дословно — граница
 плагинов, язык проектных текстов, словарь сопровождения, — живёт домом в
 `shared/` и уезжает в каждый плагин помеченной копией.
@@ -116,7 +117,7 @@ flowchart TB
 
 Отдельного файла-брифа при этом нет — проходы читают документы напрямую; карта
 «тема → её дом → что оттуда берётся» —
-[project-facts.md](av-dev-pipeline/skills/review-pipeline/references/project-facts.md).
+[project-facts.md](av-dev-code/skills/review/references/project-facts.md).
 
 Прийти в старый проект и перевести его на канон — `/av-dev-docs:canon`. Канон
 версионируется, и проекты повышаются по [журналу
@@ -137,7 +138,7 @@ claude plugin marketplace add https://git.vakhrushev.me/av/dev-skills.git --scop
 # плагины: scope обязателен, умолчание у команды — user, а нам нужен project
 claude plugin install av-dev-docs@av-dev-skills --scope project
 claude plugin install av-dev-tasks@av-dev-skills --scope project
-claude plugin install av-dev-pipeline@av-dev-skills --scope project
+claude plugin install av-dev-code@av-dev-skills --scope project
 claude plugin install av-dev-git@av-dev-skills --scope project
 ```
 
@@ -155,7 +156,7 @@ claude plugin install av-dev-git@av-dev-skills --scope project
   "enabledPlugins": {
     "av-dev-docs@av-dev-skills": true,
     "av-dev-tasks@av-dev-skills": true,
-    "av-dev-pipeline@av-dev-skills": true,
+    "av-dev-code@av-dev-skills": true,
     "av-dev-git@av-dev-skills": true
   }
 }
@@ -186,7 +187,7 @@ claude plugin marketplace update av-dev-skills
 cd /path/to/project
 claude plugin update av-dev-docs@av-dev-skills --scope project
 claude plugin update av-dev-tasks@av-dev-skills --scope project
-claude plugin update av-dev-pipeline@av-dev-skills --scope project
+claude plugin update av-dev-code@av-dev-skills --scope project
 claude plugin update av-dev-git@av-dev-skills --scope project
 ```
 
@@ -306,7 +307,7 @@ uv run python scripts/frontmatter.py    # 0 в порядке, 1 расхожд
   а не «имя не то»;
 - **цвет charter'а, не отвечающий его модели.** Цвет кодирует модель, а не роль
   прохода — раскладка живёт в
-  [review-pipeline/SKILL.md](av-dev-pipeline/skills/review-pipeline/SKILL.md),
+  [review/SKILL.md](av-dev-code/skills/review/SKILL.md),
   разделе «Модель по проходу», здесь только её механизация. Держаться вниманием
   правило не может: цвет ставится один раз при заведении charter'а, а модель
   потом меняется калибровкой.