словарь, манифесты, README: одно слово — одна вещь, одно описание — один дом
- «готовность» значила и «запись можно брать», и «что считается сделанным»; второй смысл стал «определением сделанного» — своё же правило про занятое слово запрещало это прямо - «пайплайн» жил в 24 местах вне журналов при том, что DECISIONS фиксирует его уход «целиком»; рабочее имя — конвейер - «чекпоинт» в review значил стадию и проход, в resolve — остановку человеку; слово оставлено за остановкой - у описания плагина было два дома, и три из четырёх уже разошлись. Сведены, и класс закрыт машиной: frontmatter.py сверяет plugin.json с marketplace, гейт разбужен на *.json - README врал про односторонние зависимости и терял healthcheck на диаграмме - перечень агентов в REMAINING отстал на два поколения Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude Opus 5
@@ -157,7 +157,7 @@ OpenSpec заводит человек командой выше.
|
||||
|
||||
## Чего этот скилл не делает
|
||||
|
||||
- **Не пишет спеки и предложения.** Это `opsx:propose` и пайплайн задачи.
|
||||
- **Не пишет спеки и предложения.** Это `opsx:propose` и конвейер задачи.
|
||||
- **Не ведёт документы канона** — их дом плагин `av-dev-docs`, и адреса в
|
||||
`context` только на них ссылаются.
|
||||
- **Не чинит расхождение формы с версией OpenSpec в проекте.** Оно чинится в
|
||||
|
||||
@@ -20,10 +20,10 @@ description: "Решить одну задачу от постановки до
|
||||
шаги 2, 6 и 8, шаг Р2 разведки, проход `review-specs` и ревью дизайна (они
|
||||
завязаны на `openspec/changes/<id>/specs/*/spec.md` и на
|
||||
`openspec validate --strict`). **Проект без OpenSpec этим скиллом не ведётся** —
|
||||
подключай OpenSpec, а не вырождай цикл: ветка деградации здесь не пишется,
|
||||
потому что непроверенная ветка деградации хуже честного отказа. Заводить
|
||||
руками не надо: каталог и настройку в `config.yaml` делает скилл
|
||||
`av-dev-code:openspec`.
|
||||
подключай OpenSpec, а не вырождай цикл; почему ветка деградации здесь не
|
||||
пишется, сказано в `av-dev-code:review`, раздел «Предпосылки», и дом у этого
|
||||
довода там. Заводить руками не надо: каталог и настройку в `config.yaml`
|
||||
делает скилл `av-dev-code:openspec`.
|
||||
- **Проектные копии этих скиллов и агентов удаляются при установке плагина**
|
||||
(`.claude/skills/` — голые имена `resolve`, `review`, а у проектов прошлого
|
||||
поколения ещё `task-pipeline`, `review-pipeline`, `task-batch`, и с префиксом
|
||||
@@ -212,9 +212,9 @@ flowchart TD
|
||||
- **Форматом задач.** Индексы руками не правятся, путь к скрипту учёта не
|
||||
выдумывается: этим владеет `av-dev-tasks:tasks` (шаг 11). Закрытие — работа
|
||||
этого скилла, и это осознанное решение с названной ценой: **приёмщик и
|
||||
исполнитель совпали**. Закрытие поэтому **не окончательно** — человек на сессии
|
||||
возвращает задачу `reopen` с причиной, а доклад по критериям приёмки становится
|
||||
единственным, по чему приёмка вообще возможна.
|
||||
исполнитель совпали**. Закрытие поэтому **не окончательно** — человек на
|
||||
груминге (`av-dev-tasks:groom`) возвращает задачу `reopen` с причиной, а доклад
|
||||
по критериям приёмки становится единственным, по чему приёмка вообще возможна.
|
||||
- **Заведением задач из урожая ревью.** Отложенные находки отдаются **списком**;
|
||||
превращать их в задачи — работа `av-dev-tasks:tasks`, у него на этот вход
|
||||
отдельный сценарий «задачи из ревью и аудита». Плагина нет — урожай остаётся
|
||||
@@ -226,7 +226,7 @@ flowchart TD
|
||||
|
||||
Ровно четыре, и каждый обязан быть назван в докладе прямо:
|
||||
|
||||
- **сделана** — определение готовности выполнено целиком;
|
||||
- **сделана** — определение сделанного выполнено целиком;
|
||||
- **не доведена** — с причиной и с записанным вопросом; что именно сделано и до
|
||||
какой границы, названо явно. Сюда же попадает чекпоинт, на котором человек
|
||||
решение не одобрил;
|
||||
@@ -236,7 +236,7 @@ flowchart TD
|
||||
по названному адресу, кода задача не потребовала. Это полноправный исход, а не
|
||||
недоведённая работа.
|
||||
|
||||
## Определение готовности
|
||||
## Определение сделанного
|
||||
|
||||
Задача сделана, когда верно всё:
|
||||
|
||||
@@ -394,7 +394,7 @@ flowchart TD
|
||||
| `large` | `specs`, `rubric`, `architecture` + вопрос автору о трёх формах решения |
|
||||
|
||||
`review-specs` в режиме «дизайн ДО кода» идёт **на каждой задаче**: это самый
|
||||
дешёвый чекпоинт конвейера, и он ловит то, что на готовом коде уже не чинят.
|
||||
дешёвый проход конвейера, и он ловит то, что на готовом коде уже не чинят.
|
||||
Остальные включаются меткой, потому что стадия стоит на каждой задаче и каждый
|
||||
лишний проход здесь умножается на число задач.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: review
|
||||
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: "Конвейер ревью изменения, устроенный по темам: документ проекта либо заводит тему ревью, либо питает чужую тему источником, либо процессный и в ревью не читается вовсе. Ядро тем — requirements, autotests, conventions, architecture, security, operations; список тем открытый, свои темы проект заводит документом. Разметка задачи идёт один раз, после propose: агент review-scope выводит размер и сложность, из их максимума — метка, и раздаёт темы проходам обеих стадий. Метка правит и ревью дизайна (small — только specs; medium — плюс rubric; large — плюс architecture), и ревью кода (small — гейт, спеки, код, триаж; medium — плюс приёмник тем; large — плюс доказательство: враждебные постановки, эксплуатационный постмортем, архитектурный проход на широком входе). Триаж обязателен всегда. Порядок прогона — граф зависимостей: гейт открывает опиниативные проходы, проходы с пометкой «держит машину» идут цепочкой, триаж — единственный сток. Проектная специфика приходит из документов канона av-dev-docs. Вызывается из скилла resolve — двумя стадиями: ревью дизайна до кода и ревью кода после apply."
|
||||
---
|
||||
|
||||
# Конвейер ревью
|
||||
@@ -44,7 +44,7 @@ description: "Конвейер ревью изменения, устроенны
|
||||
|
||||
- **OpenSpec — жёсткая предпосылка, а не опция.** Ревью дизайна, проход
|
||||
`review-specs` и
|
||||
вызывающий пайплайн задачи завязаны на дельта-спеки
|
||||
вызывающий скилл `av-dev-code:resolve` завязаны на дельта-спеки
|
||||
(`openspec/changes/<id>/specs/*/spec.md`), на актуальные спеки
|
||||
(`openspec/specs/`) и на `openspec validate --strict`. В проекте без OpenSpec
|
||||
шаги, зовущие `opsx:explore` / `opsx:propose` / `opsx:apply` / `opsx:archive`,
|
||||
@@ -624,7 +624,7 @@ flowchart TD
|
||||
|
||||
**План живёт в контексте прогона задачи и на диск не пишется.** Файл-план был бы
|
||||
четвёртым артефактом рядом с `proposal.md`, `tasks.md` и `design.md`, жил бы
|
||||
дольше задачи и расходился бы с ней молча. Прервали пайплайн — разметка
|
||||
дольше задачи и расходился бы с ней молча. Прервали прогон задачи — разметка
|
||||
повторяется; это самый дешёвый проход конвейера, и платить за его вечность
|
||||
дороже, чем перезапустить.
|
||||
|
||||
@@ -848,7 +848,7 @@ Recall темы `conventions` равен длине конвенций прое
|
||||
|
||||
## Ревью дизайна — до кода
|
||||
|
||||
Запускается на первом чекпоинте ревью (шаг 4 скилла
|
||||
Запускается на первой стадии ревью (шаг 4 скилла
|
||||
`av-dev-code:resolve`), когда change уже имеет `proposal.md` и
|
||||
дельта-спеки, но кода ещё нет. Разметка задачи к этому моменту уже прошла — она
|
||||
шагом раньше, и метка известна.
|
||||
@@ -864,7 +864,7 @@ Recall темы `conventions` равен длине конвенций прое
|
||||
| `large` — крупное или незнакомое | `specs`, `rubric`, `architecture` + вопрос автору | **3** |
|
||||
|
||||
- **всегда** — `review-specs` в режиме «дизайн ДО кода». Дельта-спеки сверяются
|
||||
на каждой задаче: это самый дешёвый чекпоинт конвейера, и он ловит то, что на
|
||||
на каждой задаче: это самый дешёвый проход конвейера, и он ловит то, что на
|
||||
готовом коде уже не чинят;
|
||||
- **со `medium`** — `review-rubric`: рубрика на задуманный узел, по ней же
|
||||
разбирается дельта-спека, а сами пункты уезжают приёмочными критериями в
|
||||
@@ -886,14 +886,15 @@ Recall темы `conventions` равен длине конвенций прое
|
||||
отвечается «нет» ещё до запуска. Держать её ниже `large` значит платить за
|
||||
предсказуемый ответ на каждой задаче.
|
||||
|
||||
Причина меток — арифметика, а не экономия на осторожности. Чекпоинт стоит
|
||||
Причина меток — арифметика, а не экономия на осторожности. Стадия стоит
|
||||
**на каждой задаче**, поэтому каждый проход здесь умножается на число задач, и при
|
||||
мелкой нарезке это самая большая статья конвейера.
|
||||
|
||||
**Граф этой стадии свой, и он плоский.** Гейта нет — кода ещё нет, запускать
|
||||
нечего; метка уже названа разметкой задачи; машину не держит ни один проход;
|
||||
сток — не триаж, а шаг пайплайна задачи, где замечания отрабатываются правкой
|
||||
спек. Триаж здесь не нужен: находок единицы, и каждая либо правит спеку, либо
|
||||
сток — не триаж, а шаг скилла `av-dev-code:resolve`, где замечания
|
||||
отрабатываются правкой спек. Триаж здесь не нужен: находок единицы, и каждая
|
||||
либо правит спеку, либо
|
||||
становится развилкой.
|
||||
|
||||
```mermaid
|
||||
@@ -904,7 +905,7 @@ flowchart TD
|
||||
rubric["rubric → приёмочные критерии в tasks.md"]
|
||||
arch["architecture на предложении"]
|
||||
author["вопрос автору: три формы решения и компромисс каждой"]
|
||||
fix["шаг пайплайна: правка спек, развилки — вопросом в запись"]
|
||||
fix["шаг resolve: правка спек, развилки — вопросом в запись"]
|
||||
|
||||
plan --> proposal
|
||||
proposal --> specs
|
||||
@@ -938,7 +939,7 @@ flowchart TD
|
||||
|
||||
- Оркестратор чинит помеченное `Действие: инлайн` и **не логирует мелочь**.
|
||||
- `Действие: развилка` — вопросом с вариантами и ценой каждого туда, где проект
|
||||
держит вопросы (это знает вызвавший пайплайн, а не конвейер). Оркестратор не
|
||||
держит вопросы (это знает вызвавший скилл, а не конвейер ревью). Оркестратор не
|
||||
останавливается: он урезает изменение до остатка и доводит его.
|
||||
- Находка не для этого мерджа, но реальная (отложенный `major`, развилка,
|
||||
решённая «потом»), — не теряется, но **и не заводится здесь**. Конвейер отдаёт
|
||||
@@ -960,10 +961,10 @@ flowchart TD
|
||||
заведено: нулевой урожай при непустом отчёте виден сразу.
|
||||
**Вместе с изменением он и переезжает:** после `opsx:archive` его адрес —
|
||||
`openspec/changes/archive/<id>/review/`. Кто ищет отчёт после архивации
|
||||
(приёмщик на сессии, разбор дефекта), смотрит **оба** пути; «отчёта нет»
|
||||
объявляется, только когда пуст и архивный, иначе самый дорогой сценарий
|
||||
«состав ревью неизвестен, гоняем заново» срабатывает на каждой доведённой
|
||||
задаче.
|
||||
(приёмщик на груминге `av-dev-tasks:groom`, разбор дефекта), смотрит **оба**
|
||||
пути; «отчёта нет» объявляется, только когда пуст и архивный, иначе самый
|
||||
дорогой сценарий «состав ревью неизвестен, гоняем заново» срабатывает на
|
||||
каждой доведённой задаче.
|
||||
|
||||
## Честный предел
|
||||
|
||||
@@ -1030,7 +1031,7 @@ flowchart TD
|
||||
сверкой и доказательством лежит весь класс дефектов, который виден только
|
||||
построенным путём, — и он проверяется на 5–10% задач.
|
||||
|
||||
Это сознательная сделка, а не пробел в устройстве: цес меткой `large` платится на
|
||||
Это сознательная сделка, а не пробел в устройстве: цена метки `large` платится на
|
||||
каждой задаче, а окупается на немногих. Проверяется сделка не рассуждением, а
|
||||
журналом дефектов: если класс, который ловят только меряющие проходы, начал
|
||||
всплывать после мерджа — метку выбирают слишком низко.
|
||||
|
||||
@@ -132,5 +132,6 @@
|
||||
на диск и на СУБД» экономит обязательный вопрос. Отсутствие строки — не факт,
|
||||
а пробел, и его надо назвать в границах покрытия.
|
||||
- **Свойство, ставшее правилом линтера, из конвенций удалено** и лежит в
|
||||
перечне механизированного в `docs/conventions/README.md`. Проверять его
|
||||
проходом — тратить внимание на уже проверенное.
|
||||
перечне механизированного — в `docs/conventions/README.md`, если конвенции
|
||||
каталогом, и отдельным разделом `docs/conventions.md`, если файлом. Проверять
|
||||
его проходом — тратить внимание на уже проверенное.
|
||||
|
||||
@@ -18,7 +18,7 @@ flowchart TD
|
||||
no["промоуту не подлежит:<br/>место одно — комментарий в коде;<br/>вкусовщина — вон на триаже;<br/>нужен рантайм — в журнал ревью"]
|
||||
conv["конвенция:<br/>проверяемое свойство + какой проход нашёл"]
|
||||
rule["правило линтера, запретитель,<br/>тест-сканер или анализатор"]
|
||||
clean["шаг 3: формулировка удалена из конвенций,<br/>строка — в conventions/README.md"]
|
||||
clean["шаг 3: формулировка удалена из конвенций,<br/>строка — в перечень механизированного"]
|
||||
|
||||
f --> cond
|
||||
cond -->|нет| no
|
||||
@@ -85,8 +85,9 @@ flowchart TD
|
||||
- из файла конвенций убирается формулировка правила; остаётся, если нужно, одна
|
||||
строка «проверяется линтером `<имя>`» — но только там, где без неё раздел
|
||||
теряет связность;
|
||||
- правило переезжает в **перечень механизированного в
|
||||
`docs/conventions/README.md`** — со ссылкой на место механизации: конфиг
|
||||
- правило переезжает в **перечень механизированного в доме конвенций**
|
||||
(`docs/conventions/README.md` у каталога, отдельный раздел
|
||||
`docs/conventions.md` у файла) — со ссылкой на место механизации: конфиг
|
||||
линтера, собственный анализатор, тест-сканер исходников. Не названное место
|
||||
означает, что проход будет добросовестно проверять уже проверенное;
|
||||
- из контекста инструмента спек убирается дубль, если он там был.
|
||||
|
||||
Reference in New Issue
Block a user