Реестр внешнего соответствия — при работе над проектами-хостами
Реестр пятнадцати мандатов (M1–M15), задающий требования к соответствию для всех артефактов, создаваемых в проектах-хостах, с перекрёстным сопоставлением с внутренними мандатами экосистемы.
Канонический реестр пятнадцати продакшн-мандатов. Этот документ несёт полный реестр пятнадцати мандатов (M1–M15), ратификацию порога тривиального против нетривиального, политику перекрёстного сопоставления M↔CM и протокол введения мандатов; содержательные перечисления живут здесь, операционализированные пофайловыми правилами по каждому мандату.
Когда эта экосистема создаёт, редактирует, перерабатывает, дооснащает, расширяет или удаляет любой артефакт в проекте-хосте (цель вызова пользователя — git-репозиторий, дерево документации, исследовательский корпус, манифест инфраструктуры, блокнот), каждый произведённый артефакт удовлетворяет планке из пятнадцати мандатов (M1–M15), объявленной ниже. Это не подлежит обсуждению и применяется к любой поверхности экосистемы (помощник, ассистент, команда, хук, ответ, diff, сообщение). Принуждение осуществляется шлюзом предэмиссии (см. site/content/docs/governance/pre-emission-gate-registry.mdx); принуждение механической доли живёт в src/apothem/conformity/*-grep.py, оркеструемом через src/apothem/conformity/gate.py.
Пятнадцать мандатов действуют наряду с мандатами CM-N согласно политике параллельного словаря (см. site/content/docs/governance/cross-cutting-mandates.mdx); M и CM — ортогональные измерения управления (M — внешняя ось: артефакты проектов-хостов; CM — внутренняя ось: внутренние артефакты экосистемы). Каждое правило, перечисленное ниже, является каноническим домом своего мандата; этот реестр — указатель.
| ID | Мандат | Краткое резюме | Каноническое правило |
|---|---|---|---|
| M1 | Агностицизм к проекту-хосту | Обнаружь стек / форматтер / линтер / компоновку / идиомы хоста; уважай их; выводи молчание как запрос по M5 с аннотацией M7 | src/apothem/rules/host-discovery.md |
| M2 | Редакционная дисциплина | Раскрывай каждую поправку / расширение / уточнение с обоснованием; никакого молчаливого сверхподчинения, никакого молчаливого выхода за рамки | src/apothem/rules/disclosure-ledger.md |
| M3 | Десять измерений качества | Каждый артефакт проходит проверку по десяти пунктам (строгость, согласованность, конфигурируемость, читаемость, осиротелость, структурность, архитектура, именование, научное цитирование, примеры/тесты/документация) | src/apothem/rules/ten-dimension-check.md |
| M4 | Самоприменение | Запускай шлюз предэмиссии из пятнадцати пунктов перед каждой эмиссией значимого масштаба; записывай результат шлюза | src/apothem/rules/pre-emission-gate.md |
| M5 | Принцип авторитета | Спрашивай, не выдумывай; данные об идентичности / области / предпочтениях / безопасности / именовании / инфраструктуре / закреплении версий никогда не фабрикуются | src/apothem/rules/authority-inquiry.md |
| M6 | Внедрение экспертизы | Читай намерение, вноси поправки проактивно, расширяй на смежных пробелах, уточняй с цитируемым обоснованием, предвосхищай последствия второго порядка | src/apothem/rules/expertise-posture.md |
| M7 | Аннотация вариантов | Каждый выбор из нескольких вариантов несёт маркер рекомендации и обоснование, привязанное к принципу; молчаливые выборы запрещены на авторитетной территории | src/apothem/rules/option-annotation.md |
| M8 | Определённость и герметичность | Никакой уклончивости там, где возможно обязывающее предписание; никаких «зависит» без перечисленных ветвей; каждый контракт имеет условия до / после / при отказе | src/apothem/rules/definitiveness.md |
| M9 | Визуальный рычаг | Структурный предмет несёт диаграмму текущей реальности (по умолчанию Mermaid) с происхождением и датой проверки | src/apothem/rules/visual-leverage.md |
| M10 | Двунаправленное связывание | Содержательные структурные элементы объявляют взаимные связи (Drives → / Driven by ← / Satisfies → / Established by ↑ / Cross-bound with ↔) | src/apothem/rules/bidirectional-binding.md |
| M11 | Гибкие спринты | Нетривиальная многошаговая работа выполняется как дисциплинированные спринты (Цель / Бэклог / DoR / DoD / Ревью / Ретроспектива) | src/apothem/rules/agile-sprints.md |
| M12 | Отчётность по фазам и каноническая компоновка | Многофазная работа выпускает отчёты по подфазам и сводку на уровне фазы; выводы располагаются в канонической компоновке | src/apothem/rules/canonical-layout.md |
| M13 | Ремесло кода | Комментарии «почему, а не что»; имена, раскрывающие намерение, с единицами измерения; типизированная обработка исключений; именованные константы; уважай линтер / форматирование / проверку типов хоста | src/apothem/rules/code-craft-{python,shell,markdown,conventions}.md (по языкам) |
| M14 | Системность экосистемы | Новые компоненты объявляют вышестоящие / нижестоящие / равноправные / принуждающие элементы; индексируются в реестрах хоста; никаких изолированных островов и сирот | src/apothem/rules/systemic-participation.md |
| M15 | Форма, готовая к продакшену | Изменения кода поставляются с тестами, документацией, записью в CHANGELOG, соответствующим сообщением коммита и зелёным CI в одном наборе изменений | src/apothem/rules/production-ready-prs.md |
1. Порог тривиального против нетривиального (решён)
Порог, разделяющий тривиальную и нетривиальную работу, — нетривиальная работа запускает аппарат M11 + M12, — это гибрид количества строк + области: изменение тривиально, когда это правка одного файла на ≤ 5 строк И не вводит изменения поверхности публичного API И не меняет поведение. Всё остальное нетривиально. Решено единожды согласно дисциплине решить-однажды M5; порог живёт здесь в области пользователя и переопределяется только явным объявлением области проекта, уважающим обнаружение хоста M1 (например, <project>/.claude/CLAUDE.md для Claude Code или эквивалентная попроектная поверхность для другого окружения).
2. Перекрёстное сопоставление M↔CM
Каждое тело правила с номером M объявляет своё перекрёстное сопоставление CM-N встроенно (в своей связке Cross-bound with ↔), используя политику параллельного словаря: там, где у мандата M есть ближайший аналог CM-N, оба правила применяются там, где применяются оба (без замены). Сопоставления внутренне присущи телам правил; этот реестр резюмирует политику осей, не дублируя таблицу сопоставления.
3. Протокол введения мандатов
Добавление нового мандата с номером M (например, будущего M16) — это связанное изменение. Связка достигает реестра только тогда, когда каждый из приведённых ниже компонентов присутствует в том же наборе изменений. Молчаливые добавления — новая строка M в таблице реестра без поддерживающей связки — порождают дрейф оси мандатов и являются несоответствующими согласно системному участию M14.
| Требуемый компонент | Назначение | Куда приземляется |
|---|---|---|
| Строка мандата в таблице реестра | Называет мандат, его однострочное резюме и его каноническое правило | Таблица этого реестра выше |
| Ячейка перекрёстного сопоставления CM-N | Объявляет ближайший аналог CM-N (или помечает (no direct CM-N analog) как новую ось) согласно политике параллельного словаря §2 | Строка Cross-bound with ↔ нового правила |
| Тело канонического правила | Содержательная спецификация мандата (предусловия / требуемое поведение / поверхность раскрытия / признаки отказа / пятинаправленные связи) | src/apothem/rules/<mandate-name>.md |
| Строка шлюза предэмиссии | Называет вид проверки пункта (механическая / обоснованная / смешанная) и его Failure → action | Таблица реестра шлюза предэмиссии (site/content/docs/governance/pre-emission-gate-registry.mdx) |
| Поверхность принуждения | Либо механический grep в src/apothem/conformity/<name>-grep.py, оркеструемый через gate.py, либо явное объявление обоснованного пункта с якорем самопроверки оператора | src/apothem/conformity/ (механическая) или строка шлюза, помеченная reasoned (самопроверка оператора) |
| Фикстура соответствия | Фикстура под tests/conformity-scenarios/fixtures/F-<N>-<name>/, проверяющая режимы отказа мандата; список мандатов верификатора обновляется, чтобы включить новый пункт | tests/conformity-scenarios/ |
| Обновление схемы результата шлюза | Блок bars: результата шлюза получает новую строку; блоки результата шлюза существующих артефактов трактуют новую строку как n/a (with reason: pre-mandate-N artifact) до повторного аудита | site/content/docs/governance/pre-emission-gate-registry.mdx §1, схема |
| Запись в журнале раскрытия | Фиксирует введение мандата с обоснованием, опирающимся на конкретный драйвер (повторяемость наблюдаемого паттерна; выявленный пробел безопасности; возможность, не покрытая существующими пятнадцатью пунктами) | Тело коммита или описание PR набора изменений согласно src/apothem/rules/disclosure-ledger.md |
Дисциплина применения. Предложение мандата, прибывшее без связки, отклоняется на ревью; предлагающий либо завершает связку, либо понижает предложение до расширения существующего мандата. Существующие пятнадцать мандатов были приняты вместе как внешняя ось спецификации; будущие добавления чтят тот же ритм принятия «все компоненты или ни одного компонента», а не приземляются по частям.
Протокол понижения / вывода из эксплуатации. Когда установленный M-N признаётся избыточным с существующим CM-N или с другим M-N (карта покрытия перекрёстного сопоставления в теле материализующего правила показывает смежность direct в обоих направлениях), понижение — это симметричная обратная операция: строка реестра выводится из эксплуатации, строка шлюза выводится из эксплуатации, каноническое правило выводится из эксплуатации (с содержимым, свёрнутым в поглощающее правило согласно src/apothem/rules/clean-room-generation.md §3 «Протокол переписывания»), фикстура соответствия выводится из эксплуатации, блок bars: схемы результата шлюза отбрасывает строку, а набор изменений фиксируется в журнале раскрытия со ссылкой на поглощающее правило. Понижение сохраняет тот же инвариант «все компоненты или ни одного компонента».
Реестр авторитетных запросов — Обязательные категории
Семь обязательных категорий запросов и исключения для автоматических решений, определяющие, что ассистент должен спрашивать против того, что он может решать при работе над проектами-хостами.
Политика инженерии релизов
Пять канонических политик для версионирования, тегирования релизов, циклов устаревания, несовместимых изменений и процедур отката.