Реестр внешнего соответствия — при работе над проектами-хостами
Реестр пятнадцати мандатов (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 или эквивалентная попроектная поверхность для другого harness).
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: схемы доказательства выпуска отбрасывает строку, а набор изменений фиксируется в журнале раскрытия со ссылкой на поглощающее правило. Понижение сохраняет тот же инвариант «все компоненты или ни одного компонента».
Реестр авторитетных запросов — Обязательные категории
Семь обязательных категорий запросов и исключения для автоматических решений, определяющие, что ассистент должен спрашивать против того, что он может решать при работе над проектами-хостами.
Политика инженерии выпусков
Пять канонических политик для версионирования, тегирования выпусков, циклов устаревания, несовместимых изменений и процедур отката.