План описывал мир до раскола: av-dev-pm в живых, каталог задач в docs/, шаги повышения на каноны 3, 4 и 5 — при том что канон уже 11. Двести с лишним строк, из них живых полтора десятка, и найти их можно было только прочитав всё. Умер он двумя способами сразу, и оба записаны в новом заголовке, чтобы не повторились. Первый: сделанное помечалось галочкой и оставалось в файле — список из двух сотен [x] перестают читать целиком, и живые пункты в нём теряются. Теперь сделанное удаляется, след остаётся в коммитах и DECISIONS. Второй: план построчно повторял записи журнала версий канона, то есть был вторым домом для шагов повышения, и половина повторов протухла молча. Теперь на журнал стоит ссылка. Новый план — пять разделов: вернуть живые проекты в рабочее состояние, учёт работ без спринтов, калибровка, пайплайн одной задачи в три этапа, обкатка. Поимённой раскладки файлов healthlog в нём нет намеренно: её знает canon adopt, и второй перечень разошёлся бы со скиллом. Зато названо то, чего скилл не сделает и что легко потерять — гейт проекта теперь три шага вместо одного, потому что docs.py перестал тянуть за собой и задачи, и форму config.yaml. REMAINING ссылался на разделы TODO по номерам — переведён на имена; заодно строка про непрогнанное на живом проекте дополнена скиллом openspec и оговоркой, что раскол проверен только на фикстурах и на установке каждого плагина в одиночку. Решение 53: canon и docs остаются двумя скиллами. Довод не про объём, а про description — это триггер, по которому загрузчик решает, звать ли скилл, и моменты вызова у этих двух разные. Слитое описание покрывает оба хуже, чем два покрывают каждое своё. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
9.5 KiB
Что осталось сделать
Здесь только работы и их порядок. Чего здесь нет намеренно:
- риски, открытые вопросы и принятые пределы — REMAINING.md;
- почему решено так — DECISIONS.md, записи датированы;
- шаги повышения проекта с версии канона на версию — журнал версий (changelog.md). Пересказ их сюда был бы вторым домом, и прежний план на этом уже разъезжался: он повторял записи версий 3, 4 и 5 построчно, и половина повторов протухла молча.
Сделанное отсюда удаляется, а не помечается галочкой. След остаётся в
коммитах и в DECISIONS.md; список из двух сотен [x] перестают читать целиком,
и живые пункты в нём теряются — прежний план умер именно так.
Где мы сейчас
Плагинов четыре, и каждый ставится отдельно: av-dev-docs (канон документов и
их содержимое), av-dev-tasks (задачи и цели), av-dev-pipeline (SDD и конвейер
ревью, он же заводит OpenSpec), av-dev-git. Общее, что нужно нескольким
дословно, живёт домом в shared/ и уезжает копиями.
Канон документов — версия 11. Живые проекты стоят на 2–3 и на плагине
av-dev-pm, которого больше нет.
1. Живые проекты — вернуть в рабочее состояние
Блокирует всё остальное: под текущим каноном не стоит ни один проект, и ни один
скилл, кроме docs.py check, не исполнялся на живом коде ни разу
(см. REMAINING, «Что ещё не сделано»).
healthlog — первым
- переустановить плагины: снять
av-dev-pm, поставитьav-dev-docsиav-dev-tasks.marketplace update, затемplugin update— одного шага мало (README, «Обновление») - удалить проектные копии:
.claude/skills/healthlog-{task,review}-pipelineи девять.claude/agents/healthlog-review-*.md. Они прошлого поколения и после переезда указывают на документы, которых уже не будет av-dev-docs:canonв режимеadopt— он приведёт проект к канону 11 сразу, картой и с подтверждением. Файл-в-файл здесь не расписан: раскладку знает скилл, и второй перечень разошёлся бы с ним- каталог задач — в
tasks/корня (канон 11), не вdocs/tasks/. Скилл задач зовётся изadoptсам - гейт проекта: три шага вместо одного —
docs.py check,tasks.py check --dir tasks,openspec.py check. Второй и третий раньше не были нужны: согласованность задач тянул за собойdocs.py, формуconfig.yamlон же. Теперь оба молчат, и без своих шагов дрейф перестанет ловиться - разобрать урожай
doc-consistencyиdoc-code-driftпорциями — правило единственного дома на живом проекте не проверял никто
jellybit — после калибровки
Порядок не произволен: замер (раздел 3) блокирует переезд jellybit, и только его.
- то же, что у healthlog: плагины, проектные копии,
adopt, каталог задач, гейт - проектные копии здесь опаснее: скиллы названы
task-pipeline,review-pipeline,task-batch— ровно как в плагине, и короткое имя может увести в устаревшую копию молча (REMAINING)
2. Учёт работ без спринтов
Решено: спринты отменяются, беклог и роадмап остаются. Причина — процесс идёт задача за задачей, и замороженный набор перестал что-либо удерживать.
- снять спринт:
SPRINT.md, командыsprint *, переходы схемы состояний, правило «задача живёт в одном индексе за раз» упрощается до беклога - приоритет — явный порядок строк в беклоге. Правило 4 скилла задач («порядка нет, есть цель») переписывается целиком: оно обосновано тем, что «что делать дальше» отвечает набор спринта, — а набора больше нет. Записать, что приоритет это свойство очереди, а не задачи, и потому его дом индекс: то же исключение из правила 2, что уже есть у «в каком индексе лежит задача, знают индексы»
- перевесить гейт готовности. Схема типа (обязательные разделы, ≥2
критерия, границы) проверяется на
sprint take. Спринта нет — момента нет; нуженtasks.py ready <слаг>илиcheck --task <слаг>на входе пайплайна, иначе задача уедет в работу без критериев приёмки check --fix: восстановленная строка индекса теряет позицию, а позиция теперь и есть приоритет. Класть в конец категории и печатать пометкой, что приоритет назначен не человекомsession→ скилл груминга внутриav-dev-tasks: пересортировка беклога, разбор вопросов, переоценка.references/sprint.mdв мусор,cadence.mdпереписать под ритуал без спринта- запись в журнал версий канона: проектам надо снести
SPRINT.mdи расставить порядок
3. Калибровка — блокирует переезд jellybit
- замер на четырёх находках healthlog: скелет из
null, откат бинаря, канонизация в транзакции,-1 >= -1. Цена и ожидаемый исход — REMAINING, «Главный незакрытый риск»
4. Пайплайн одной задачи — три этапа
Обкатывается на healthlog после разделов 1 и 2. Пайплайн нескольких задач на паузе намеренно.
- этап 1 — первичный ресерч и смысл задачи. Заканчивается дешёвым подтверждением: две строки «понял так, собираюсь делать это». Без него проверка «то ли я делаю» приходит после готового дизайна, то есть когда ошибка стоит дороже всего
- этап 2 — propose, дизайн, ревью дизайна, краткое объяснение решения. Заканчивается полноценным чекпоинтом
- этап 3 — код, ревью, архивация. Автоматически: дизайн уже согласован. Решить, что делает этап, когда ревью находит расхождение с утверждённым дизайном: находка внутри дизайна дожимается сама, находка, отменяющая дизайн, отменяет и чекпоинт и обязана всплыть к человеку
- перемерить
review-pipelineтем же вопросом, что и проект целиком: сколько из пяти стадий реально смотрятся глазами. 1028 строк, и весь автоматический этап держится на них
5. Обкатка
- один-два цикла healthlog на новом процессе; наблюдение к первой обкатке — не выродились ли «границы покрытия» в шаблон (REMAINING, «Открытые вопросы»)