av
d79f9d2286
Ревью трансформации нашло, что тема 78 спорит сама с собой в четырёх местах. Учёт был отдан агенту, хотя перечень оркестратора объявлен закрытым, а границы задания прямо говорят «задач не заводит»: вызов av-dev:task-track вернулся оркестратору, агенту третьего такта осталось письмо в документы. Ветка отказа не была покрыта — на ответе «ничего» правка первого такта уезжала в коммит невычитанной и с непрогнанным гейтом. Теперь третий такт идёт всякий раз, когда была реплика; не идёт он только тогда, когда реплики не было вовсе. Дом правила вычитки в doc-sync знает про два захода. Барьер карты кластеров из сценария «задачи из ревью и аудита» снимается там, где его уже прошли: список показан человеку и получил ответ. При прямом вызове и вызове из code-deep-review карта по-прежнему вопрос. Счёт стопов сведён в таблицу по сценариям; у обслуживания появился второй заход и одна реплика с поводом «новый запрет или инвариант». Сигнал сверки считается по архиву change и каталогу задач разом — иначе chore и research не считались вовсе — и вошёл в возврат агента и в доклады трёх сценариев. Ось «род правки документа» внесена в перечень осей. Журнал — тема 80; отложенный старший долг назван в С287.
Решения по устройству процесса
Журнал согласований: что решено, почему и что из этого следует. Пишется по ходу разбора тем, одна тема — один файл; этот файл — только указатель.
Три сквозные нумерации, и они не пересекаются:
- Т — требование: вход, который обязан быть удовлетворён. Живут здесь, ниже.
- Р — решение: что согласовано и почему. По темам в порядке журнала.
- С — следствие: что из решения вытекает.
Номер закреплён за записью навсегда: журнал описывает прошлые состояния и задним числом не переписывается. Отсюда и разнобой формы — ранние темы держат решения под заголовком «Решено», поздние ведут их прозой.
Требования, зафиксированные по ходу
Не решения — вход, который обязан быть удовлетворён и разбирается в названной теме.
Т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.