Files

T

каталог задач уехал из docs/ в корень репозитория

Версия 8 отпустила задачи из канона — перестала требовать каталог и перестала в
него смотреть, — но место он занимал всё то же, docs/tasks/. Полдела: каталог,
принадлежащий одному плагину, лежал внутри дерева, которым владеет другой.
Проекту, поставившему учёт работ без канона документов, приходилось заводить
docs/ ради одной вложенной папки.

Дом задач теперь tasks/ в корне. tasks.py ищет его там первым, docs/tasks и
doc/tasks остались в списке поиска для непереехавших проектов, init заводит
только в корне, --target у adopt тоже. Настройки лежат рядом, tasks/.tasks.json —
после версии 8 они уже были в своём файле, теперь и файл вне чужого дерева.

docs.py продолжает терпеть docs/tasks/ в списке нечитаемого: непереехавший проект
не должен получать выдуманную ошибку «файл вне канона» вдобавок к записи журнала,
которая и так велит ему переехать. Адреса упразднённых слотов (plan.md, backlog/)
теперь ведут в tasks/ и называют плагин.

Тридцать три живых упоминания пути разведены по смыслу, а не заменой строки: в
раскладке канона tasks/ вышел из-под docs/ и стоит на своём уровне; у
doc-consistency каталог перестал быть исключением внутри docs/** и стал чужой
территорией, названной в обеих формах; у review-scope и review-pipeline
процессный список поехал вместе с путём. В журнале версий тринадцать упоминаний
оставлены как есть — они описывают прошлое состояние.

Канон повышен до версии 11. В записи названа тихая часть переезда: файл
tasks/items/x.md стал на уровень ближе к корню, и ../../passport.md в теле записи
теперь ../docs/passport.md. Битую относительную ссылку внутри записи tasks.py
check не ловит вовсе — её видит только docs.py и только у документов канона, так
что этот шаг делается руками и тем же коммитом, что git mv.

Фикстура переехала, поиск вверх по дереву находит новый путь, гейт зелёный.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-09 14:33:33 +03:00

9.5 KiB

Raw Blame History

name, description

name	description
init	Завести новый проект — сессия вопросов и ответов по свободному описанию замысла, из которой рождается первичная документация по канону av-dev: паспорт, CLAUDE.md с инвариантами и командами, модель угроз с периметром, первые цели в роадмапе и скелет остальных документов. OpenSpec заводит не сам, а вызовом скилла av-dev-pipeline:openspec — каталог принадлежит конвейеру; плагина конвейера нет — шаг пропускается строкой доклада. Использовать, когда начинают новый проект с нуля, когда есть только текст «что мне нужно и почему» и надо превратить его в рабочую документацию, когда просят провести стартовое интервью по брифу. Проект, где документация уже как-то ведётся, переводит скилл canon.

name

description

init

Завести новый проект — сессия вопросов и ответов по свободному описанию замысла, из которой рождается первичная документация по канону av-dev: паспорт, CLAUDE.md с инвариантами и командами, модель угроз с периметром, первые цели в роадмапе и скелет остальных документов. OpenSpec заводит не сам, а вызовом скилла av-dev-pipeline:openspec — каталог принадлежит конвейеру; плагина конвейера нет — шаг пропускается строкой доклада. Использовать, когда начинают новый проект с нуля, когда есть только текст «что мне нужно и почему» и надо превратить его в рабочую документацию, когда просят провести стартовое интервью по брифу. Проект, где документация уже как-то ведётся, переводит скилл canon.

Заведение нового проекта

Вход — свободный текст «что мне нужно и почему». Выход — канон документов, с которого дальше работают все остальные скиллы.

Определение канона — канон. Прочитай его до первого вопроса: интервью идёт по слотам канона, а не по вкусу. Что класть в каждый файл — скелеты; не выдумывай заглушки своей формы, docs.py узнаёт только плейсхолдер оттуда.

Что `init` физически не может произвести

В новом репозитории нет кода, а architecture.md, database.md, conventions/ и research/ выводятся из него. Сочинить их на старте — значит проектировать вперёд реальности, и написанное протухнет раньше первой задачи.

Поэтому init заполняет то, что человек знает до первой строки кода:

Заполняется	Остаётся скелетом с честной строкой
`passport.md`	`architecture.md`
`CLAUDE.md`	`database.md`
`security.md`	`conventions/`
`tasks/ROADMAP.md` — первые цели	`research/`, `adr/`
`docs/.pm.json`	`review.md` — журнал пуст, настройка появится с первым ревью

Честная строка информативна, а не «TBD»: «архитектуры пока нет: кода нет, заводится первой задачей». Проход читает её как факт.

Порядок интервью — зависимость, а не удобство

Каждый блок опирается на ответ предыдущего; переставлять нельзя.

Цель и потребители. Ради чего это; кто пользуется — список закрытый, и он определяет, что считать нужным, а что интересным.
Чем это НЕ является и мера успеха. Граница домена — критерий, по которому потом судят в теме architecture о переносе понятия. Мера — по чему поймём, что удалось.
Периметр и недоверенный вход. Открыт наружу или контур доверенный; что приходит извне и каким каналом; что чувствительнее чего. Контур ещё не развёрнут — назови оба периметра, целевой и сегодняшний.
Стек, хранилище, необратимое. Чем пишем и почему; где данные; что в этом проекте нельзя откатить — деплой, выкладка наружу, перезапись данных.
Чем краснеет гейт. Какие проверки обязательны; что красит безусловно; чего в гейте намеренно не будет и кто тогда это гоняет.
Первые цели. Возможности приложения, а не задачи: три-пять целей в Запланировано, каждая — ответ на «что приложение будет уметь», с обоснованием очереди прозой.

Как вести

Не больше трёх вопросов за итерацию (AskUserQuestion), рекомендация первым вариантом. Между итерациями применяй уже решённое.
Сперва вычитай ответы из брифа. Если ответ уже есть в тексте, вопрос не задавай — покажи своё прочтение и спроси, верно ли.
Не выдумывай четыре вещи: периметр, что необратимо, измеренные числа и адресата дорогой проверки. Их из замысла не вывести. Не сказано — пиши «неизвестно» с пометкой, что ждёт ответа.
Развилка замысла — человеку, механика — сама. Имена файлов, слаги, порядок строк не выноси.

Порядок работы

Прочитай бриф целиком. Выпиши, на какие блоки интервью ответ уже есть.
Проведи интервью итерациями по ≤3 вопроса.
OpenSpec — вызови Skill av-dev-pipeline:openspec. Он заводит каталог и заменяет пример в config.yaml настройкой. Делается это до первого документа: без openspec/ не работают ни opsx:propose, ни ревью дизайна, ни сверка требований. Каталог принадлежит конвейеру, а не канону, поэтому здесь только вызов — ни команды, ни формы файла init не знает.

Вызов не разрешился — плагина конвейера в проекте нет. Это законный исход, а не поломка: проект без конвейера живёт без OpenSpec. Скажи это строкой в докладе и иди дальше; docs.py check о каталоге тоже промолчит.
Заведи docs/.pm.json с текущей версией канона.
Напиши заполняемые документы. Бриф переезжает в passport.md и отдельным файлом не остаётся: два дома для одного замысла разойдутся на первом же уточнении.
Заведи скелет остальных по скелетам — каждый с честной строкой.
Каталог задач и первые цели — вызови скилл av-dev-tasks:tasks: он владеет форматом целей и задач. Не разрешился — учёт задач остаётся владельцу, и это тоже строка доклада.
docs.py check из скилла canon — до отсутствия дрейфа. Замечания о незаполненных плейсхолдерах остаются: их закрывает не init, а работа.
Покажи человеку, что получилось, и отдельным списком — что выведено из брифа, что предположено, что осталось неизвестным. Правят по этим строкам.

Что дальше

Содержимое канона по ходу разработки ведёт скилл docs.
Раскладку проверяет canon check.
Первую задачу берёт пайплайн проекта; architecture.md и conventions/ наполняются его шагом синка, а не заранее.

Чего этот скилл не делает

Не проектирует систему. Архитектура выводится из кода, а не наоборот.
Не пишет код и не заводит сборку.
Не переводит существующий проект — это canon adopt. Признак: в репозитории уже есть документация или беклог в какой-то раскладке.
Не решает за человека, что важно: цель, границы и периметр — его ответы.

9.5 KiB Raw Blame History Unescape Escape