avandClaude Opus 5
00ddfb0dde
Плагин владел двумя разными вещами сразу — документацией проекта и учётом работ, — и это мешало обеим. Канон нельзя было поставить без задач, задачи без канона, а язык проектных текстов лежал внутри скилла canon и потому принадлежал половине. Теперь плагина два, каждый ставится сам по себе. av-dev-docs: скиллы canon, docs, init; агенты doc-consistency, doc-code-drift, doc-wording; скрипт docs.py. av-dev-tasks: скиллы tasks, session; агенты task-form, task-wording; скрипт tasks.py. Между собой они зовутся через пространство имён, а не по пути в чужое дерево. Все относительные ссылки, пересекшие границу плагина, сняты: tasks больше не указывает в canon, canon не указывает в tasks. Вместо ссылки — имя скилла и оговорка, что вызов может не разрешиться, и это исход, а не поломка. То, что нужно обоим дословно, стало вторым общим домом. Словарь «Сопровождение и эксплуатация» назван в трёх местах трёх плагинов — секция роадмапа, раздел «Эксплуатация» в architecture.md, тема ревью operations — и ни один из трёх им не владеет; он уехал в shared/operations.md, а canon.md и скилл задач везут копии. Три перечня «чем держат проект» уже разъезжались на «метриках и логах» против «мониторинга», так что ссылка тут не годится: плагин, поставленный в одиночку, получил бы указатель в никуда. Тем же способом язык: у av-dev-tasks появилась своя копия language.md. Копий стало 18 при 8 домах. Переименования разведены по смыслу, а не заменой строки: где речь о каноне — av-dev-docs, где об учёте задач — av-dev-tasks. В пайплайне таких мест одиннадцать, и оба адресата там встречаются вперемешку. Журналы (DECISIONS, TODO, HISTORY) намеренно не тронуты: они описывают состояние на момент записи. По той же причине оставлена наблюдённая строка в комментарии docs.py — она цитирует конфиг живого проекта, а не называет плагин. Не входит в этот заход и названо отдельно: слияние canon и docs в один скилл, разделение docs/.pm.json на два конфига и переезд openspec в пайплайн. Гейт зелёный: копии, фронтматтеры, диаграммы, json. Оба скрипта прогнаны после переезда — docs.py version и tasks.py check на фикстуре. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2.7 KiB
Сопровождение и эксплуатация
Копия. Дом — shared/operations.md в репозитории плагинов. Словарь общий для
роадмапа, архитектуры и темы ревью operations, и не принадлежит ни одному из
трёх — правится дом, а не этот файл.
Скиллу задач он нужен для секции Сопровождение в ROADMAP.md: она отвечает не
на «что приложение будет уметь», а на «чем его держат», и путать эти два вопроса
нельзя.
Одна тема живёт в трёх местах, и путать их слова нельзя.
Сопровождение — всё, чем держат проект: инструмент и сборка, процесс, выкладка, метрики и логи, инфраструктура, дежурство. Эксплуатация — его часть: работа системы на проде. Целое и часть, и никогда наоборот.
| Место | Уровень | Что там |
|---|---|---|
ROADMAP.md, секция Сопровождение |
план | работы, которые собираемся делать: цели и их задачи |
architecture.md, раздел «Эксплуатация» |
состояние | как устроено сейчас: где работает, что рядом, кто перезапускает |
тема ревью operations |
оптика | чем проверяем: «это упало через неделю на проде» |
Слово «поддержка» не употребляется вовсе — в нём слышится помощь пользователю, а это другая работа.
Граница с возможностями проходит по тому, кто наблюдает. «Приложение сообщает о своём состоянии» — возможность приложения, её место среди прочих целей: наблюдает пользователь сервиса. «Дежурный видит состояние на одном экране» — сопровождение: наблюдаем мы. Одни и те же метрики попадают в разные секции роадмапа, и это верно — секции отвечают на разные вопросы.