dev-conventions/TODO.md

К обсуждению

Черновик для следующего разговора: вопросы и варианты, а не принятые решения.

1. Ссылка на язык — закрыто

Заменено boilerplate-строкой по образцу BCP 14: каждая конвенция называет ключевые слова, версию языка и правило заглавных, но не путь. Строка стоит отдельным абзацем после вводной прозы во всех двенадцати файлах, «Форма записи — LANGUAGE.md» удалена. Точный текст — в LANGUAGE.md, раздел «Ссылка на язык из конвенции».

Побочно: строка перечисляет модальные слова заглавными, то есть сама нарушает проверку «заглавные модальные слова не встречаются вне правил». Исключение записано в список проверок — так же, как оно устроено в BCP 14, где boilerplate тоже содержит ключевые слова.

2. Тулинг: две разные задачи в одном conv

Сейчас в conv смешаны две категории работы, и они расходятся по всему — по частоте запуска, по тому, кто запускает, и по тому, что считается провалом.

Целостность канона. Префиксы уникальны и не переиспользованы, шапка совпадает с реестром, номера без дыр вниз, у каждого правила модальность и «Почему», ссылки разрешаются, чужой префикс не лезет в норму (META-20), путей канона в тексте нет (META-21). Запускается в каноне, при каждой правке, провал — это ошибка. Логика уже написана и много раз прогнана руками, но живёт в скретчпаде, а не в репозитории.

Установка в проект. Манифест .conventions.toml, сборка файла темы из секций (arch → языки → стеки → local), сохранение локальной секции при пересборке, отчёт «канон ушёл вперёд», предупреждение о висячих ссылках на неподписанные темы. Запускается в репозитории-потребителе, изредка, провал — это чаще «посмотри глазами», чем «ошибка».

Что обсудить:

• Разделять ли на два исполняемых файла, или хватит подкоманд с честной границей внутри.
• Валидацию канона стоит ли отдать агенту скиллом вместо (или вдобавок к) скрипту: часть проверок формулируется как «прочитай и скажи, самодостаточна ли норма» — механически это не берётся, а агентом берётся.
• Куда в этой раскладке ложится запаркованное предупреждение о висячих ссылках: это установка, а не целостность, но список подписок ему нужен из манифеста.

3. Модель сборки — записана, закрыто

Записана в README.md (разделы «Копия в репозитории» и «Манифест») и в GUIDE.md (META-22, META-23). Плоская раскладка, файл на тему, один маркер <!-- conv:local -->, манифест из источника и списка тем, направление строго одностороннее.

Против прежних заготовок разошлось в трёх местах:

• лока нет — «что было в прошлый раз» знает git, копии закоммичены, и автоматического обновления не существует; заодно из шапки копии ушли origin_hash и synced, осталось одно origin:;
• маркеров секций нет — раз обновление перезаписывает всё выше локального маркера, разметка слоёв тулингу не нужна; слои идут обычными заголовками;
• локальные префиксы не объявляются в манифесте — за репозиториями зарезервирована буква X, столкновение невозможно по построению.

Остаётся переписать conv: сейчас в нём зеркальное дерево, именованные регионы, origin_hash и команды status/diff/push. Это вопрос 2.

4. Именованные регионы — удалить из канона

Решение принято и записано: регионов нет, есть один маркер <!-- conv:local -->, который ставит сборщик в копии. Значит регионы не переносятся в единую секцию, а удаляются: в каноне их нечем наполнять, локальное принадлежит копии.

Остаётся механическая работа — 31 регион в 12 файлах:

7  связано        7  отступления     7  механизировано
1  эталон / эталоны / словарь / секреты / секретные-поля
1  проверки / поля / модель-владельца / маппинг / границы

Вопрос про связано снят: META-17 переписан, канонический раздел «Связано» остаётся в тексте и содержит только ссылки, верные у всех, а репо-специфичные уходят под маркер.

5. Пары слоёв и темы без базы

Отложено сознательно, но список стоит держать перед глазами:

• SLOG объявляет extends: arch/time.md — расширение чужой темы. Сборщик темы logging на это наткнётся: базового слоя с темой logging нет, а arch/time.md он тянуть не должен. Чинится переводом в обычную ссылку «связано».
• Темы без арх-слоя: db-schema, errors, web-ui. Собираются в файл с одной секцией — само по себе не ломается, но это и есть тот невыделенный арх-слой из известного долга.
• Имена тем в паре не совпадают: arch/db-identifiers.md против lang/go/db-schema.md. При сборке по имени темы это две разные темы — проверить, что так и задумано.
• В lang/go/db-schema.md сидит целый пласт stack/sqlite/ (типы колонок), тоже из известного долга README.

6. Подключение к репозиториям

Ничего ещё не подключено. Кандидаты — jellybit и pet-project-server. Понадобится: заполнить локальные секции тем, что сейчас в этих репозиториях записано по факту; обёртка в раннере (inv conventions / task conventions, единый интерфейс команд у трёх ansible-репозиториев); строка в AGENTS.md каждого потребителя про то, что файлы в docs/conventions/ — копии.

Открытый кусок с прошлого раза: как копия ссылается на канон, не ломая самодостаточность. Абсолютный путь ~/projects/private/dev-conventions в закоммиченном файле не годится — репозиторий перестаёт быть самодостаточным и получает хардкод путей. Пересекается с вопросом 1.

7. Не переизобретено ли это — разобрано

Проверка перед вложением в тулинг сделана. По слоям:

• Язык записи — совпал со стандартами почти во всём: шкала и правило «нормативно только заглавное» — BCP 14, обязательное обоснование и единичность нормы — ISO/IEC/IEEE 29148, категории — ISO/IEC Directives Part 2, таблицы решений — DMN, стабильные идентификаторы — semgrep/ESLint. Шесть точечных дельт применены, опора на источники записана в LANGUAGE.md разделом «Опора на стандарты».
• Оси и сборка — аналога не нашлось. Ближайшие соседи (каскад extends в ESLint, слои стилей Vale) дают праву слоя отменять базу; наш запрет строже, и это содержательная часть. Вкладываться сюда.
• Транспорт — переизобретался, но задача у нас другая, чем у copier и cruft. У них трёхсторонний merge потому, что шаблон порождает код, который правят везде: расхождение неограниченно. У нас расхождение ограничено и живёт под маркером, поэтому исключение из перезаписи лучше merge — детерминированно и без конфликтных маркеров. Из vendir/cruft взят разбор «манифест против лока», из ansible blockinfile — идея размечать управляемый кусок, а не локальный. Лок при этом не взят: его роль играет git.
• Раздача агентам — не наша задача, остаёмся на AGENTS.md/CLAUDE.md плюс скиллы.

Vale отклонён. Из восьми проверок в LANGUAGE.md он честно закрывает две-три (модальные слова вне правил, запрещённые формулировки); остальные пять структурные — «у каждого ### ПРЕФИКС-N есть модальность и Почему», «номера без дыр вниз», «префикс совпадает с реестром». Это разбор документа, а не проверка токенов в области. Ради двух-трёх проверок тянуть ещё один бинарь и директорию стилей при одном пользователе не стоит.

Что стоит посмотреть перед переписыванием conv (вопрос 2): дистрибуцию пакетов Vale (.vale.ini → vale sync → styles/) как готовый прототип манифеста, и vendir.yml — как пример того, где проходит граница между «чего хочу» и «что получил».

8. Мультиязычность ключевых слов — закрыто по механике

Вопрос был поставлен как «нужен ли английский набор параллельно русскому». Ответ оказался другой формы: словарь — параметр естественного языка набора, а не часть языка конвенций. Шкала из пяти ступеней инвариантна, слова под неё подбираются: для английского готовый словарь даёт BCP 14, для любого другого языка слова берут из перевода стандарта или переводят сами.

Отсюда следствия, снимающие исходный вопрос:

• параллельных наборов не бывает. Словарь один на канон: два словаря дают две формы записи одного требования и удваивают каждую проверку;
• версия языка при смене словаря не меняется — версия принадлежит шкале и правилам формы, а не буквам. Прежняя оценка «английский набор = версия 2» неверна;
• SHALL не берётся ни в одном словаре, потому что занято OpenSpec; для английского это выбор в пользу MUST из BCP 14, а не shall из ISO;
• отметка о механизации стандартом не даётся ни в одном языке и подбирается так же, как остальные слова (МЕХАНИЗИРОВАНО / MECHANIZED).

Открытым остаётся только прикладное: понадобится ли этому канону английская версия вообще. Механика для неё уже описана, заводить заранее нечего.

9. Описание языка отдельно от набора конвенций

LANGUAGE.md и GUIDE.md описывают, как пишутся конвенции; conventions/ — один конкретный набор. Сейчас они склеены в одном репозитории, и из одного описания нельзя собрать второй набор (рабочий, доменный, чужой).

Что это даёт, если разнести:

• канон объявляет, какой версии языка следует, а тулинг валидирует набор против объявленного описания, а не против зашитых в код правил;
• таблица модальных слов (вопрос 8) живёт в описании и одна на все наборы;
• вопрос 1 (LANGUAGE.md не переживает сборку) меняет форму: собранный файл ссылается не на путь, а на язык с версией.

Цена — ещё одна сущность и ещё одна синхронизация. Проверить, не выйдет ли лечение хуже болезни при одном пользователе.

Срочность снята: версия появилась у LANGUAGE.md (ключ version: в шапке), и boilerplate-строка из вопроса 1 уже ссылается на язык номером, а не путём — не дожидаясь выноса. Отдельный репозиторий остаётся вопросом второго набора конвенций, а не вопросом самодостаточности копии.

Что осталось поводом: из одного описания по-прежнему нельзя собрать второй набор, и тулинг валидирует правила, зашитые в код, а не объявленную версию языка. Оба повода включаются, только когда появится второй набор.

10. Тулинг на Go, живущий независимо

Сейчас conv — питоновский скрипт внутри канона, то есть тулинг и данные в одном репозитории и правятся одним движением. Мысль: вынести в отдельный Go-бинарь со своим релизным циклом, ставить через eget (механизм уже есть в pet-project-server).

Что за этим стоит помимо вкуса: независимый бинарь физически не даёт править инструмент «заодно» с правкой конвенции, работает против любого канона и любого потребителя — что прямо требуется вопросом 9, — и снимает питон из зависимостей репозиториев-потребителей.

Связано с вопросом 2: если тулинг всё равно переписывается, разделение «целостность канона / установка в проект» дешевле заложить сразу, чем отпиливать потом.

Порядок при этом обратный написанному: пока вопрос 9 не сделан, инструмент всё равно работает против одного конкретного канона, и независимый релизный цикл ему нечего обслуживать. Сначала 9, потом 10.

11. Ссылки на родительский слой своей темы

Из lang/ и stack/ ссылаться на идентификаторы своего же арх-слоя безопасно: при сборке они оказываются секциями одного файла, и ссылка никуда не ведёт — правило рядом. Ограничение META-20 писалось именно про чужую тему, так что формально это уже разрешено.

Формулировка проверки исправлена: в LANGUAGE.md теперь «префикс чужой темы не встречается в абзаце с модальностью», и там же сказано, что префикс своего базового слоя допустим. Ложного срабатывания на GTIM → TIME-3 больше нет.

Осталось решить одно: добавлять ли в META-20 явную строку ДОПУСКАЕТСЯ про родительский слой. За — правило, которое читают строже, чем оно есть, заставляет авторов дублировать текст без нужды. Против — норма META-20 уже говорит «чужой темы», и второе правило про то же место придётся держать согласованным с первым.

Из вчерашнего, не закрыто

• Вынос арх-ядра из errors и logging: закроет две хрупкие ссылки из web-ui (стек) в go-слой — единственные ссылки стек → язык в каноне.
• conv check должен уметь отличать ссылку на удалённое правило от упоминания дыры: сейчас META-16 в прозе «Оформления» даёт ложное срабатывание.