av
e5dc0a1a39
Оба слова стояли в закрытом словаре правила 6 с оговоркой, и обе оговорки отвергали один русский вариант, а вывод из них делался про все. Отсюда общее требование к записи словаря: она обязана говорить, чем слово незаменимо, а не чем плох один из кандидатов. Латинизм, переживший проверку одним синонимом, — не имя вещи, а непроверенная привычка. Провенанс заменён двумя словами, потому что смысла было два, и это же его и держало: происхождение у числа (чем и при каких условиях получено) и откуда у вопроса и находки (кто нашёл, каким проходом, из какой записи журнала). Слово стояло и в скелете docs/review.md, уезжающем в репозитории проектов, поэтому раскладка повышена до версии 4 с записью журнала: правка формы вопроса и проход grep по docs/. Интейк заменён заведением с названным источником — «из диалога», «из ревью». Оговорка защищала слово от голого «заведения» и в этом была права, но в паре с источником двусмысленности нет, а скилл задач уже называет операцию так же. Раскладку это не двигает: слово жило только в прозе плагина. Образец стиля назван прямо и отдельным разделом: научно-популярная книга, не спецификация и не конспект для себя. Три умолчания — воды нет, сложных конструкций нет, англицизм исключение с причиной. Находок образец не порождает: он для того, кто пишет, а вычитка судит по правилам, иначе «звучит сложно» стало бы находкой и порог правки перестал бы работать. Журнал решений: темы 70 и 71, Р258–Р264 и С244–С249. Остальной словарь — триаж, дедуп, чек-лист, дифф, промпт, чекпоинт, синк — не пересматривался, и это сказано записью: пересмотр меняет язык всего корпуса и делается своей работой, а не попутно.
14 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.