av
72d9aa8034
Сценарий решения идёт от предложения сразу к чекпоинту и коду: стадия ревью дизайна упразднена целиком, review-scope запускается после apply и меряет размер по диффу, сложность — сверкой обещанных границ с тронутыми. Чекпоинт остался единственным плановым стопом и стоит теперь до кода. review-rubric конвейером не зовётся, слот рубрики в скелете config.yaml снят. Журнал — тема 74.
15 KiB
Решения по устройству процесса
Журнал согласований: что решено, почему и что из этого следует. Пишется по ходу разбора тем, одна тема — один файл; этот файл — только указатель.
Три сквозные нумерации, и они не пересекаются:
- Т — требование: вход, который обязан быть удовлетворён. Живут здесь, ниже.
- Р — решение: что согласовано и почему. По темам в порядке журнала.
- С — следствие: что из решения вытекает.
Номер закреплён за записью навсегда: журнал описывает прошлые состояния и задним числом не переписывается. Отсюда и разнобой формы — ранние темы держат решения под заголовком «Решено», поздние ведут их прозой.
Требования, зафиксированные по ходу
Не решения — вход, который обязан быть удовлетворён и разбирается в названной теме.
Т1. Адаптация и проверка проекта под канон — обязательный скилл. Нужно уметь прийти в любой старый проект и перевести его на текущие рельсы. Канон при этом сам будет меняться, поэтому уже приведённые проекты тоже должны повышаться до новых версий. Разбирается в теме 5 (старт и жизненный цикл проекта).
Следствия, которые из этого уже видны:
- У канона обязана быть версия, а у проекта — отметка, под какую он приведён. Иначе «соответствует канону» не имеет определённого ответа: сравнение идёт с тем, что модель помнит сейчас, а это и есть дрейф.
- Журнал изменений канона — как миграции. Каждое повышение версии несёт запись «что добавилось, что переехало, что удалено, что сделать проекту». Без него адаптация переизобретается на каждом проекте.
- Отметка версии машиночитаема.
.docs.jsonотвергнут как указатель путей (решение Р6), но отметка версии — другое: её читает скрипт, и разбирать прозуCLAUDE.mdдля этого не нужно. Прецедент —.tasks.json. - Операций три:
check(соответствие текущему канону),adopt(перевод чужой раскладки),upgrade(повышение с версии N до M по журналу). Первая и третья — одно сравнение с разными исходами. - Механизируемое и суждение не смешивать. Скрипт проверяет пути, лишние
файлы, битые ссылки, версию. Агент судит о смысловых дублях (
docs/specs/ recognition.mdпротив capabilityrecognition) и об оставшемся поведении вarchitecture.md. Скрипт, отчитавшийся «канон соблюдён» на проекте с тремя лишними файлами, хуже отсутствующего. - Границы плагинов:
docs/tasks/— часть канона документов, но владеет имav-dev-tasksсо своимtasks.py adopt. Два плагина сходятся на одном каталоге. Тема 7.