Состав прогона постоянный: гейт, спеки, код, триаж; приёмник тем идёт, когда у проекта есть свои темы. Метка, разметка и проход review-scope упразднены, review-levels.md удалён, ось «метка» снята из axes.md. Ступень 4 ушла из цикла: review-proof упразднён через день после заведения, review-architecture переехал в code-deep-review вслед за adversary и ops. Темы security, operations и architecture закрывает review-code сверкой с записанными инвариантами, потолком 1 находка. Умолчание разметки действий перевёрнуто на инлайн; развилка осталась за необратимым, изменением дельта-спек и нарушенным инвариантом. Задачи из урожая заводятся по слову человека, а не шагом сценария. Чекпоинт назван единственным местом, где решается форма решения. Потеряны ось времени в цикле и суждение о форме после кода — обе потери названы в «Честном пределе» строкой границ покрытия. Журнал — тема 77.
Решения по устройству процесса
Журнал согласований: что решено, почему и что из этого следует. Пишется по ходу разбора тем, одна тема — один файл; этот файл — только указатель.
Три сквозные нумерации, и они не пересекаются:
- Т — требование: вход, который обязан быть удовлетворён. Живут здесь, ниже.
- Р — решение: что согласовано и почему. По темам в порядке журнала.
- С — следствие: что из решения вытекает.
Номер закреплён за записью навсегда: журнал описывает прошлые состояния и задним числом не переписывается. Отсюда и разнобой формы — ранние темы держат решения под заголовком «Решено», поздние ведут их прозой.
Требования, зафиксированные по ходу
Не решения — вход, который обязан быть удовлетворён и разбирается в названной теме.
Т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.