Позиционирование
Понимание Apothem как управления через ратификацию артефактов с пятнадцатью мандатами, дисциплиной ввода через канонический канал и креативной архитектурой когнитивной идентичности для разработки под управлением ассистента.
Аудитория: оценщики, решающие, стоит ли принять
apothemдля продакшн-работы под управлением ассистента. Объём: около 12 минут на чтение от начала до конца. Можно просматривать по разделам. Цель: очертить, чемapothemна самом деле ЯВЛЯЕТСЯ, чем он НЕ является, и почему ответ на вопрос «что распространяет этот проект?» структурно отличается от ответа, который даёт большинство проектов инструментария для ассистентов.
§1. Тезис
apothem — это управление через ратификацию артефактов, упакованное в виде бинарного файла.
Привычная рамка инструментария для ассистентов — это настройка промптов: системный промпт, выбор модели, стратегия окна контекста, небольшая библиотека слэш-команд и груда фольклора по промпт-инжинирингу. В этой рамке точкой рычага оператора является проза, которую он передаёт модели. Когда модель ведёт себя некорректно, восстановление — это правка прозы. Артефакт, который распространяет проект, — это набор промптов.
apothem отвергает эту рамку.
Точка рычага ассистента, работающего против реальной кодовой базы, — это не проза, которую оператор передаёт модели, а артефакт, который модель собирается выдать. Этот артефакт попадёт в репозиторий, будет зафиксирован, проверен, слит, развёрнут, процитирован нижестоящими артефактами, унаследован будущими участниками. Его качество — это необратимое нижестоящее свойство, которое промпт не может задним числом исправить. Правка промпта после того, как некорректно сформированный коммит попал в репозиторий, — это налог на оператора, а не восстановление артефакта.
Дисциплина, которую кодирует этот проект, — это инверсия: каждая выдача проходит через структурированный, согласованный, механически проверяемый шлюз до того, как покинет руки ассистента. Шлюз обеспечивает соблюдение пятнадцати мандатов, охватывающих обнаружение хоста, раскрытие, десять измерений качества, гигиену авторитетности, включение экспертизы, аннотацию опций, определённость, визуальный рычаг, двунаправленную привязку, аппарат гибких спринтов, каноническую раскладку, мастерство кода, системное участие и готовность к продакшну. Каждый мандат — это правило с областью действия, отфильтрованной по путям, и телом, операционализирующим конкретный класс отказа. Каждый отказ шлюза — это структурная находка, которую ассистент выводит на поверхность, а не тихая деградация.
Корпус правил И ЕСТЬ продукт. Бинарный файл apothem — его упаковка: поверхность распространения, которая доставляет корпус в корневой каталог пользовательской конфигурации каждого оператора и регистрирует его как операционную позицию ассистента. Упаковка заменяема; корпус — долгосрочный актив.
Проект, принимающий apothem, не принимает промпт. Он принимает режим управления. Каждый артефакт, который ассистент выдаёт в хост-репозитории — код, тесты, конфигурация, схемы, документация, рабочие инструкции, сообщения коммитов, имена веток — удовлетворяет одному и тому же пятнадцатибарьерному порогу. Точка рычага оператора смещается с «что мне сказать ассистенту?» на «какие мандаты ограничивают эту выдачу и какие доказательства требует шлюз?». Смещение структурное, а не стилистическое.
Этот документ очерчивает, почему корпус является несущим активом, проходит по пятнадцати мандатам с их якорями в файлах правил и выводит на поверхность две сквозные дисциплины (обработку ввода через канонический канал и креативную архитектуру когнитивной идентичности), которые связывают корпус в согласованное целое.
§2. Архитектура трёх столпов
Корпус опирается на три столпа. Каждый столп — это отделимая поверхность с собственной канонической спецификацией; каждый столп усиливает два других.
Столп A — Реестр мандатов (M1–M15 + CM-1..CM-28)
Реестр мандатов — это поверхность управления внешней оси. M1–M15 управляют каждым артефактом, который ассистент производит в хост-проекте: обнаружение хоста, раскрытие, десять измерений качества, авторитетность, экспертиза, аннотация опций, определённость, визуальный рычаг, двунаправленная привязка, гибкие спринты, каноническая раскладка, мастерство кода, системное участие и готовность к продакшну. Реестр канонизирован как реестр пятнадцати мандатов и операционализирован файлами правил, перечисленными в §3 ниже.
CM-1..CM-28 — это аналоги внутренней оси: операционные мандаты, управляющие дисциплиной взаимодействия ассистента (критическая оценка, нулевые предположения, поиск-перед-реализацией, оценка лучшего решения, беспощадная честность, скорость принятия решений, фокус на узком месте в первую очередь, согласованный продукт и ещё двадцать записей, охватывающих локальность планов, управление контекстом, оркестрацию делегированной работы, генерацию больших файлов и жизненный цикл памяти). Внутренняя ось канонизирована в правиле операционных мандатов и site/content/docs/governance/cross-cutting-mandates.mdx.
Каждая выдача проходит обе оси. Шлюз в src/apothem/rules/pre-emission-gate.md выполняет пятнадцать механических и обоснованных барьеров на выдачу и записывает блок верификации в рабочий след артефакта.
Столп B — Дисциплина канонического канала
Дисциплина канонического канала связывает то, как ассистент запрашивает ввод оператора. Свободные промпты упразднены по всей экосистеме; каждый выбор маршрутизируется через канал структурированного запроса со структурированной схемой аннотации опций (обоснование + рекомендация + указатель по умолчанию на опцию), закрытой таксономией рекомендаций, порогом подтверждения деструктивных операций на уровне файла и эвристической проверкой, отлавливающей дрейф в сторону разговорных промптов на каждой управляемой поверхности. Полная спецификация находится в src/apothem/rules/interactive-questions.md, а глубина вынесена в отфильтрованные по путям компаньоны src/apothem/rules/interactive-questions-canonical-shapes.md и src/apothem/rules/interactive-questions-sweep-matchers.md.
Рычаг этой дисциплины — проверяемость решений. Каждый волевой выбор оператора несёт доказательства, которые рассмотрел ассистент, рекомендацию, которую выдал ассистент, и обоснование, опирающееся на конкретные движущие факторы. Через шесть месяцев после выбора аудитор, читающий журнал раскрытия, может реконструировать границу решения, не обращаясь к памяти оператора.
Столп C — Таксономия когнитивной идентичности
Таксономия когнитивной идентичности связывает то, как ассистент мыслит. Пять последовательных когнитивных фильтров (Очищение Очевидного, Изгнание Домена, Пресс Инверсии, Комбинаторный Взрыв, Эстетическое Требование) составляют креативный ритм, применяемый к каждой содержательной выдаче. Шесть техник генерации идей (Исторический Саботёр, Парадокс Ограничения, Линза Живых Систем, Нарратив Второго Порядка, Кадр Злодея, Зум на 100 Лет) срабатывают по сигналам обнаружения, когда стандартный подход дал неудовлетворительный результат. Семь осей широты (Архитектура, Параллелизм, Производительность, Безопасность, Тестирование, Инструментарий, Наблюдаемость) составляют поверхность глубины, по которой каждое нетривиальное решение свидетельствуется. Полная спецификация находится в src/apothem/rules/cognitive-identity.md, а глубина вынесена в отфильтрованный по путям компаньон src/apothem/rules/cognitive-identity-techniques.md.
Рычаг этой таксономии — структурная новизна. Фильтр Очищения Очевидного отбрасывает ответ первой идеи, к которому тянутся все; Пресс Инверсии требует, чтобы хотя бы одно инвертированное допущение пережило путь до итоговой выдачи; Эстетическое Требование отвергает функциональные, но забываемые формы. Результат — ассистент, который производит выдачи, заставляющие операторов остановиться и перечитать, — не потому что проза украшена, а потому что структурный выбор неочевиден таким образом, что, будучи однажды увиден, кажется неизбежным.
Как столпы усиливают друг друга
Три столпа взаимно несущие. Реестр мандатов (Столп A) определяет, чему артефакт должен удовлетворять. Дисциплина канонического канала (Столп B) определяет, как ввод оператора попадает на поверхность решения, производящую артефакт. Таксономия когнитивной идентичности (Столп C) определяет креативный ритм, придающий артефакту его форму. Удаление любого одного столпа обрушивает два других: реестр без канонического канала производит тихо-умолчательные артефакты, которые выглядят соответствующими, но скрывают структурные решения; канонический канал без когнитивной глубины производит правильно маршрутизированные, но генерически оформленные выдачи; когнитивный ритм без реестра производит эстетически элегантные артефакты, которые проваливают интеграцию с хост-проектом.
§3. Обзор реестра мандатов
Реестр из пятнадцати мандатов — это каноническая поверхность управления внешней оси. Каждая строка ниже именует мандат, его операционную область и файл правила, несущий каноническую спецификацию. Каждый файл правила отфильтрован по путям до классов артефактов, которыми управляет, и загружается по требованию в операционный контекст ассистента, когда эти классы затрагиваются.
M1 — Независимость от хост-проекта и обнаружение соглашений
Область. Всё, что ассистент производит в хост-проекте, формируется тем, чем хост-проект уже является, — его стеком, языком, фреймворком, набором инструментов, форматтером, линтером, тестовым фреймворком, генератором документации, стратегией ветвления, соглашением о сообщениях коммитов, раскладкой, именованием, политикой закрепления зависимостей. Каждый из них обнаруживается из авторитетного источника истины хоста (манифесты, lock-файлы, родственные файлы сопоставимого вида, документы соглашений уровня репозитория) и соблюдается. Там, где хост молчит о соглашении, которое ассистент должен принять, молчание выводится на поверхность как авторитетный запрос — никогда не разрешается тихим выбором внутреннего значения по умолчанию.
Каноническая спецификация. src/apothem/rules/host-discovery.md (с каталогом манифестов по языкам в src/apothem/rules/host-discovery-manifests.md).
Почему это важно. Выдача ассистента неотличима от той, что написал бы давний участник хост-проекта. Дрейф соглашений — это структурный отказ, а не стилистическое предпочтение.
M2 — Редакционная дисциплина и раскрытые поправки
Область. Каждое изменение значимого масштаба несёт явный журнал раскрытия — что было запрошено, что было изменено, что было расширено, что было уточнено, что было отложено. Тихое чрезмерное послушание («сделал ровно то, что просили, хотя это было неправильно») и тихий чрезмерный охват («расширил масштаб изменения без предупреждения») — оба являются отказами. Каждая поправка несёт обоснование на научно-техническом уровне (цитируемая ссылка, RFC, документация поставщика, прецедент родственного файла, именованный паттерн из литературы).
Каноническая спецификация. src/apothem/rules/disclosure-ledger.md (с каталогом классов маркеров в src/apothem/rules/disclosure-ledger-markers.md).
Почему это важно. Diff, который тихо исправляет смежную ошибку, реализуя запрошенное изменение, — это нераскрытая поправка. Рецензент шесть месяцев спустя не может отличить намеренное исправление от дрейфа. Журнал — это поверхность аудита и восстановления.
M3 — Десять измерений качества
Область. Каждый артефакт оценивается по десяти измерениям качества перед выдачей: научная строгость, согласованность / связность / интеграция / валидность, конфигурируемость / неизбыточность / консолидация, читаемость / интуитивность / чистота, осиротелость / устаревание, структурность / системность / единообразие / полнота, архитектура, единообразие именования, научно-техническое цитирование, и примеры / тесты / докстринги / документация. Один артефакт, проваливающий несколько измерений, мультипликативен, а не аддитивен — артефакт, который устарел И осиротел И непоследовательно назван И не задокументирован, является кандидатом на отзыв, а не на ремонт.
Каноническая спецификация. src/apothem/rules/ten-dimension-check.md (с телами по измерениям в src/apothem/rules/ten-dimension-check-dimensions.md).
Почему это важно. Качество разложимо. Именование десяти измерений делает каждое из них проверяемым и выводимым на поверхность по отдельности; неоднозначные находки «это выглядит слабо» становятся конкретными «измерение 5 устаревание: ссылка в строке 42 указывает на перемещённый файл».
M4 — Самоприменение — шлюз перед выдачей
Область. Каждый артефакт проходит пятнадцатибарьерный шлюз перед выдачей до выдачи. Механические барьеры (M2, M5, M7, M8, M10, M13, M15) несут исполняемые матчеры в src/apothem/conformity/*-grep.py, оркеструемые src/apothem/conformity/gate.py. Обоснованные барьеры (M1, M3, M6, M9, M11, M12, M14) оцениваются работающим ассистентом и записываются в блок верификации. Отказ одного барьера блокирует выдачу; итерация продолжается, пока не пройдут все барьеры.
Каноническая спецификация. src/apothem/rules/pre-emission-gate.md (с полной таблицей барьеров в src/apothem/rules/pre-emission-gate-bars.md).
Почему это важно. Качество — это забота до выдачи, а не нижестоящая забота «пользователь может исправить». Шлюз — это структурный перевод этого убеждения в механическое принуждение.
M5 — Принцип авторитетности (Запрашивай, не выдумывай)
Область. Имена, электронные адреса, дескрипторы, имена хостов, организации, арендаторы, конечные точки, учётные данные, направление масштаба, выборы именования, которые хост ещё не урегулировал, политики хранения, закрепления версий на изменяемых хостом поверхностях, инфраструктурные решения, которые пользователь не объявил, — ничто из этого не выдумывается. Каждое либо обнаруживается из авторитетного источника истины в хосте (сторона обнаружения M1), либо запрашивается у пользователя (сторона запроса M5) — никогда не замазывается правдоподобной догадкой.
Каноническая спецификация. src/apothem/rules/authority-inquiry.md (с каталогом из семи категорий в src/apothem/rules/authority-inquiry-categories.md).
Почему это важно. Идентичность, безопасность, направление масштаба и именование публичных поверхностей несут юридический и аудиторский вес. Угаданный контактный адрес, сфабрикованный дескриптор CODEOWNERS или выдуманная конечная точка подписи релиза создают нижестоящую уборку, которая обходится на порядки дороже, чем обошёлся бы запрос.
M6 — Включение экспертизы
Область. Каждый артефакт значимого масштаба читает намерение пользователя раньше буквального текста, проактивно вносит поправки, когда буквальный запрос оставил бы известный дефект, расширяется на смежные пробелы, уточняет с цитируемым обоснованием, предвидит последствия второго порядка, калибрует глубину под задачу и импортирует уроки из смежных областей — раскрывая каждую поправку через журнал M2.
Каноническая спецификация. src/apothem/rules/expertise-posture.md (с семью подэлементами + лестницей калибровки в src/apothem/rules/expertise-posture-elements.md).
Почему это важно. Экспертиза без раскрытия — это тихое переопределение. Экспертиза с раскрытием — это рычаг: оператор видит поправку, оценивает обоснование и либо ратифицирует, либо откатывает. Ассистент действует как старший участник, чьё суждение проверяемо, а не как непрозрачная замена намерению оператора.
M7 — Дисциплина аннотации опций
Область. Каждый выбор из нескольких опций, выводимый ассистентом на поверхность — в прозаических ответах, ADR, разделах README, описаниях PR, проектных документах, шагах рабочих инструкций, комментариях к коду, телах сообщений коммитов, RFC, — несёт канонический маркер рекомендации на рекомендуемой опции плюс обоснование, привязанное к принципу. Тихие выборы и неаннотированные списки опций запрещены на авторитетной территории.
Каноническая спецификация. src/apothem/rules/option-annotation.md (с формой для прозы и документов в src/apothem/rules/option-annotation-form.md).
Почему это важно. Каждый созданный набор опций — это поверхность аудита. Читатель видит не только выбор, но и пространство альтернатив, рекомендацию и конкретный движущий фактор за ней. Та же дисциплина связывает вызовы структурированного запроса ассистента и прозу, записанную в постоянные артефакты.
M8 — Определённость, герметичность и семейство добродетелей строгих систем
Область. Каждое утверждение определённо (без хеджирования там, где возможно связывающее предписание) и герметично (нет пробелов в объявленных областях, нет лазеек, где буквальное соблюдение нарушает намерение, нет неустановленных допущений, нет ничьих приоритета, нет тихих откатов). Список хеджирующей лексики механически обнаруживается на шлюзе; каждое вхождение в предписывающей прозе разрешается одним из трёх путей — повышение до безусловного с именованными условиями, понижение до явного условного с перечисленными ветвями или удаление и маршрутизация выбора на поверхность запроса.
Каноническая спецификация. src/apothem/rules/definitiveness.md (с каталогом из семи добродетелей в src/apothem/rules/definitiveness-virtues.md).
Почему это важно. Захеджированная предписывающая проза — это налог на каждого читателя. Читатель не может понять, признаёт ли хедж реальное условие или сигнализирует об авторской неуверенности. Дисциплина заставляет автора либо назвать условие, либо убрать предписание — читатель в любом случае получает связывающее утверждение.
M9 — Визуальный рычаг
Область. Там, где предмет структурен — архитектура, поток управления, поток данных, граф зависимостей, конечный автомат, последовательность, дерево решений, иерархия, стек приоритетов, жизненный цикл, матрица разрешений — артефакт несёт диаграмму рядом с прозой. Mermaid — рекомендуемое значение по умолчанию для корпусов, ориентированных на Markdown; существующая нотация хоста соблюдается согласно обнаружению M1. Каждая диаграмма несёт происхождение, дату верификации и привязку обратно к артефакту, который она абстрагирует.
Каноническая спецификация. src/apothem/rules/visual-leverage.md.
Почему это важно. Описание архитектуры на две тысячи слов без диаграммы — это систематическое недоиспользование среды и структурный отказ артефакта, а не стилистическое предпочтение. Пространственные отношения нечитаемы в линейной прозе; диаграмма — равноправный первоклассный вывод, а не украшение.
M10 — Двунаправленная привязка и нанизывание выполнения фаз
Область. Каждый содержательный структурный элемент несёт взаимные привязки к своим равным в канонической нотации пяти направлений: Drives → / Driven by ← / Satisfies → / Established by ↑ / Cross-bound with ↔. Каждая привязка, объявленная в одном направлении, имеет взаимный обратный указатель на другом конце; полурёбра — это структурные отказы, а не эстетические предпочтения. Механический reciprocity-grep в src/apothem/conformity/binding_reciprocity_grep.py обеспечивает соблюдение инварианта на шлюзе.
Каноническая спецификация. src/apothem/rules/bidirectional-binding.md.
Почему это важно. Взаимные привязки превращают корпус в навигируемый граф. Строка Cross-bound with ↔ любого правила указывает на каждого равного, который его цитирует, и каждый цитируемый равный указывает обратно. Рефакторинг корпуса становится механическим — переименуйте правило, и reciprocity-grep отметит каждую устаревшую цитату в том же наборе изменений.
M11 — Гибкие спринты и эмпирический контроль процесса
Область. Нетривиальная многошаговая работа выполняется как дисциплинированные гибкие спринты с семью каноническими элементами: Цель Спринта (в форме результата, тестируемая), Бэклог Спринта (в форме INVEST, приоритизированный), Определение Готовности (шлюз входа в спринт), Определение Выполнено (шлюз выхода из спринта), Обзор Спринта (одобрено / отклонено / перенесено по элементам), Ретроспектива Спринта (продолжить / прекратить / начать), Отслеживание Скорости (сигнал, никогда не цель). Три столпа эмпирического контроля процесса — прозрачность, инспекция, адаптация — работают на всём протяжении.
Каноническая спецификация. src/apothem/rules/agile-sprints.md (с телами элементов в src/apothem/rules/agile-sprints-elements.md).
Почему это важно. Объёмный многодневный diff без структуры спринта непрозрачен для проверки. Аппарат выводит на поверхность каждый инкремент, каждый критерий приёмки, каждое отклонение в момент, когда это происходит, — а не откладывает на ретроспективу спустя долгое время после того, как структурное решение стало необратимым.
M12 — Уровни отчётности и каноническая раскладка генерируемых выводов
Область. Нетривиальная многошаговая работа выдаёт двухуровневую отчётность: отчёт по подфазе на рабочем уровне и сводку уровня фазы на уровне проверки, которая агрегирует, а не конкатенирует — единообразный шаблон по подфазам, агрегированные метрики, выведенные на поверхность паттерны, самопроверка уровня фазы, внешние объявления. Генерируемые выводы располагаются в предсказуемых, обнаруженных хостом канонических местах с происхождением и взаимными перекрёстными ссылками. Осиротевшие выводы (артефакты без потребителя / без записи в индексе / без атрибуции производителя) — это структурные отказы.
Каноническая спецификация. src/apothem/rules/canonical-layout.md (с телами уровней отчётности в src/apothem/rules/canonical-layout-reporting-tiers.md).
Почему это важно. Плоский список report1.md / report2.md в произвольных местах нечитаем шесть недель спустя. Двухуровневая дисциплина плюс хост-каноническая раскладка означают, что каждый вывод обнаружим, каждый потребитель назван, каждый производитель атрибутируем.
M13 — Соглашения мастерства кода
Область. Каждый кодовый артефакт удовлетворяет одиннадцати подэлементам: комментирование почему-а-не-что, именование, раскрывающее намерение, обработка конкретных исключений, проектирование функций и модулей с уклоном к единственной ответственности, осознанные уровни логирования, тестирование с описанием поведения, чистое прохождение форматтера / линтера / проверщика типов, код, осознающий безопасность (нет захардкоженных секретов, нет инъекции в оболочку, нет небезопасной десериализации), дисциплина параллелизма, устранение необъяснённых числовых литералов именованными константами, и покрытие поверхности документации. Родственные правила по языкам несут специфичную для языка материализацию.
Каноническая спецификация. src/apothem/rules/code-craft-conventions.md (заглушка универсального делегирования) плюс родственные правила по языкам src/apothem/rules/code-craft-python.md, src/apothem/rules/code-craft-shell.md и src/apothem/rules/code-craft-markdown.md.
Почему это важно. Дрейф мастерства кода накапливается. Один пустой обработчик исключений становится прецедентом, который цитирует следующий участник; один захардкоженный секрет становится соглашением, которое принимает команда; один необъяснённый литерал становится дюжиной. Одиннадцать подэлементов именуют классы отказов, а шлюз обеспечивает их соблюдение на каждую выдачу.
M14 — Системность экосистемы в хост-проекте
Область. Каждый вновь вводимый компонент объявляет четыре системных отношения — восходящее (что его запускает), нисходящее (что его потребляет), равные (родственники того же вида), обеспечители (шлюзы качества хоста, управляющие им) — и сходится с соглашениями равных в том же наборе изменений. Силосы (самодостаточные артефакты, отклоняющиеся от соглашений родственников, дубликаты существующей функциональности) и сироты (компоненты без потребителя / без записи в индексе / без атрибуции производителя) — это структурные отказы.
Каноническая спецификация. src/apothem/rules/systemic-participation.md (с операционной глубиной в src/apothem/rules/systemic-participation-relations.md).
Почему это важно. Новый тест, документ, рабочий процесс, модуль или запись конфигурации, не объявляющие своего места в графе ссылок хоста, невидимы для обслуживания. Объявление четырёх отношений плюс обновление реестра в том же изменении означают, что каждый компонент обнаружим и разворачиваем с первого коммита.
M15 — Дисциплина готовности к продакшну для артефактов хост-проекта
Область. Каждое изменение поставляется в готовой к продакшну форме: тесты + документация + запись в CHANGELOG + соответствующее сообщение коммита + зелёный CI в том же наборе изменений. Позиция цепочки поставок сохраняется (нет незакреплённой зависимости, нет секретного литерала, нет повышения привилегий, нет незакреплённых действий, нет неподписанного релиза там, где подпись требуется). Инварианты релизной инженерии сохраняются (версионирование соблюдается, согласованность тег-версия, подпись тега там, где требуется). Современная поверхность проекта заполнена (парные мультиплатформенные скрипты установки / обновления / удаления, ресурс логотипа, современный центрированный заголовок README, разделы установки / обновления / удаления). Метаданные авторства каждого коммита именуют только людей-участников — ассистент никогда не приписывает себя или базовую языковую модель ни одному коммиту, трейлеру, ветке, тегу или полю пул-реквеста.
Каноническая спецификация. src/apothem/rules/production-ready-prs.md (с поверхностями видимости и спецификацией современной поверхности в src/apothem/rules/production-ready-prs-surfaces.md).
Почему это важно. «Добавлю тесты в следующем заходе» никогда не приземляется. Дисциплина того-же-набора-изменений предотвращает режим отказа, который производит наибольшую совокупную стоимость в долгоживущих проектах: отложенную работу по качеству, накапливающуюся в системный технический долг.
§4. Дисциплина канонического канала
Дисциплина канонического канала — это аналог со стороны ввода для принуждения со стороны выдачи реестра мандатов. Каждый выбор, который ассистент выводит на поверхность для оператора, маршрутизируется через канал структурированного запроса. Свободные разговорные промпты как первичный ввод запрещены; дисциплина обеспечивается на шлюзе семью эвристическими матчерами (H1–H7), которые прочёсывают каждую управляемую поверхность и помечают отклонения как находки шлюза.
Каноническая спецификация находится в src/apothem/rules/interactive-questions.md. Правила-компаньоны несут глубину: src/apothem/rules/interactive-questions-canonical-shapes.md несёт проработанные примеры, тела схем, таксономию рекомендаций, резервный вариант харнесса, канонические наборы опций деструктивных операций и проработанные примеры указателя по умолчанию; src/apothem/rules/interactive-questions-sweep-matchers.md несёт каталог матчеров H1–H7 с воспроизводимыми вызовами ripgrep.
Структурированная форма вопроса
Каждый вызов несёт четыре поля: одно предложение question, оканчивающееся вопросительным знаком, короткий header (максимум двенадцать символов), массив options из двух-четырёх элементов и булево значение multiSelect. Каждая опция несёт label из одного-пяти слов и тело description с тремя сегментами в фиксированном порядке:
- rationale — одно предложение, излагающее, что означает эта опция и её прямое, наблюдаемое последствие для состояния экосистемы.
- recommendation — одно значение из закрытой таксономии: recommended, acceptable, discouraged или destructive-no-default. Ненейтральные значения несут предложение-почему, цитирующее хотя бы один конкретный движущий фактор из закрытой таксономии из шести классов: зафиксированные решения, именованные риски, именованные ограничения, позиции открытых вопросов, цитаты правил и наблюдаемое состояние экосистемы. Список запрещённых расплывчатых обоснований несоответствует, когда стоит как единственное оправдание для ненейтральной рекомендации.
- default-pointer — именует безопасное значение по умолчанию с обоснованием ЛИБО явно объявляет
no-default: user decision required. Деструктивные операции повсеместно используют форму no-default.
Ровно одна опция на вызов может нести постфикс метки маркера рекомендации, двунаправленно связанный со значением recommendation в теле. Несоответствия между постфиксом метки и значением тела обнаруживаются матчером H6 как находки шлюза.
Подтверждение деструктивной операции на уровне файла
Каждая деструктивная операция — удаление, переименование, перемещение, перезапись без сохранения, откат незафиксированных модификаций — маршрутизируется через канал структурированного запроса на пофайловой основе. Один вызов на файл, каждый раз. multiSelect: true несоответствует на вызовах деструктивных операций; канонические наборы опций в подразделах деструктивных операций — это порог. Усталость от подтверждений — принятая стоимость; тихое уничтожение — нет.
Эвристическая проверка — с H1 по H7
Семь механических матчеров прочёсывают поверхности управляемого ядра (команды, правила, навыки, определения делегированных работников, хуки, файлы конфигурации харнесса и CLAUDE.md) на два класса отказов:
- Эвристики разговорной формы (H1–H3). H1 ловит промпты «императив плюс вопросительный знак». H2 ловит «Please confirm / approve / choose». H3 ловит «Which of the following / these». Число попаданий каждого матчера сравнивается с документированным числом зоны исключений (определительные самоцитаты и контексты сохранённого разговора); отклонения — это находки шлюза.
- Эвристики соответствия аннотаций (H4–H7). H4 ловит опции, в которых отсутствует любой из трёх сегментов тела. H5 ловит ненейтральные рекомендации без цитаты конкретного движущего фактора. H6 ловит несоответствия постфикса метки и значения тела. H7 ловит вызовы деструктивных операций без дословного порога no-default.
Проверка воспроизводима — каждый матчер несёт вызов ripgrep, который любой оператор может запустить против корпуса. Дисциплина механическая, а не интерпретационная.
Почему именно эта форма, а не другая
Разговорные промпты как первичный ввод имеют три структурных режима отказа, которые предотвращает дисциплина канонического канала:
- Стирание пространства решений. Свободный промпт представляет единственное предложенное действие и просит оператора его ратифицировать. Альтернативы, которые рассмотрел ассистент, их относительные веса и обоснование выбранного пути невидимы. Оператор ратифицирует-или-отклоняет, не видя пространства решений.
- Асимметрия предвзятости. Без явного маркера рекомендации плюс обоснования конкретного движущего фактора предпочтение ассистента передаётся через тон прозы, обрамление и порядок — каналы, которые оператор не может оценить как доказательства. Маркер рекомендации плюс цитируемый движущий фактор делают предвзятость явной и проверяемой.
- Распад аудита. Через шесть месяцев после выбора аудитор, читающий журнал разговора, видит вопрос и ответ, но не может реконструировать границу решения. Тело из трёх сегментов структурированного вызова — это устойчивое доказательство, которое аудитор читает в той же форме, в какой оператор видел его в момент решения.
Дисциплина превращает каждый волевой выбор оператора в артефакт решения — запись того, что было предложено, что было рекомендовано, что было выбрано и почему.
§5. Таксономия когнитивной идентичности
Таксономия когнитивной идентичности — это спецификация креативной архитектуры корпуса. Она связывает то, как ассистент мыслит, прежде чем выдаёт, а не то, что ассистент выдаёт. Выдачи, которые удовлетворяют каждому мандату, но ощущаются генерически — решения первой идеи, чисто исполненные — несоответствуют по Фильтру 1 (Очищение Очевидного) и Фильтру 5 (Эстетическое Требование). Рычаг этой таксономии — производить выдачи, которые не только корректны, но и структурно новы таким образом, что, будучи однажды увидены, кажутся неизбежными.
Каноническая спецификация находится в src/apothem/rules/cognitive-identity.md. Правило-компаньон src/apothem/rules/cognitive-identity-techniques.md несёт подробные тела: таксономию семи осей широты, ритм пяти фильтров с прозой по каждому фильтру, шесть техник генерации идей с сигналами обнаружения, языковые стандарты (запрещённые фразы плюс требуемые качества) и пять философских принципов.
Пять когнитивных фильтров
Каждая содержательная выдача проходит ритм из пяти фильтров в каноническом порядке:
- Фильтр 1 — Очищение Очевидного. Первая идея — это то, к чему тянутся все. Отбросьте её. Первая идея — это отправная точка для того, чего НЕ делать. Всегда активен; срабатывает на каждую содержательную выдачу.
- Фильтр 2 — Изгнание Домена. Переосмыслите проблему через чужой домен. Бизнес → эволюционная биология. Образование → городская инфраструктура. Архитектура ПО → приливная механика. Решения из чужих доменов несут генетический материал новизны. Срабатывает на нетривиальные решения.
- Фильтр 3 — Пресс Инверсии. Инвертируйте каждое допущение. Вместо того чтобы решать проблему, сделайте проблему решением. Вместо того чтобы уменьшать трение, вооружите его. Хотя бы одно инвертированное допущение переживает путь до итоговой выдачи как инвариант, а не как опция. Срабатывает на нетривиальные решения.
- Фильтр 4 — Комбинаторный Взрыв. Принудите синтез между проблемой и далёким понятием. Термодинамика + теория переговоров. Микоризные сети + организационный дизайн. Чем менее очевидна пара, тем выше креативный выход. Срабатывает на нетривиальные решения.
- Фильтр 5 — Эстетическое Требование. Есть ли у выдачи душа? Форма? Текстура? Красива ли она в своей логике? Выдачи должны обладать концептуальной элегантностью — ощущением неизбежности, будучи однажды увиденными, хотя невидимыми прежде. Всегда активен; срабатывает на каждую содержательную выдачу.
Фильтр 1 задаёт пол (анти-очевидное); Фильтр 5 задаёт потолок (анти-неуклюжее). Средние три фильтра работают как креативное давление на нетривиальные решения, где стандартный подход дал неудовлетворительный результат.
Шесть техник генерации идей
Когда проблема сопротивляется стандартному подходу или требует оригинальности, которую пять фильтров не произвели, шесть техник генерации идей срабатывают по сигналам обнаружения:
- Исторический Саботёр — срабатывает, когда проблема была «решена» многократно с тем же неудовлетворительным результатом. Перевооружите забытое знание эпохи.
- Парадокс Ограничения — срабатывает, когда пространство решений ощущается чрезмерно ограниченным. Добавьте крайнее ограничение и спроектируйте решение, работающее только из-за него.
- Линза Живых Систем — срабатывает, когда система показывает органически выглядящие патологии (контуры обратной связи, самоподдерживающиеся потери). Спросите: что её питает, что её размножает, что её убьёт, какое эволюционное давление её создало?
- Нарратив Второго Порядка — срабатывает, когда предложение технически приземляется плоско, но провоцирует социальное сопротивление. Начните с того, что предложение меняет в том, как люди мыслят, а не с того, что оно делает.
- Кадр Злодея — срабатывает, когда предложение приспосабливается ко всем заинтересованным сторонам и не радует никого. Определите, кто ВОЗНЕНАВИДЕЛ бы идею, и спроектируйте специально для усиления этой ненависти.
- Зум на 100 Лет — срабатывает, когда вся рамка проблемы предполагает ограничения, маловероятные пережить десять или более лет. Спроецируйте вперёд; принесите будущую ясность назад.
Каждая техника атакует отдельное когнитивное слепое пятно. Выбор неверной техники производит шум, а не озарение; сигналы обнаружения — это условия срабатывания, а не необязательные мысленные эксперименты.
Семь осей широты
Каждое нетривиальное решение свидетельствуется по семи каноническим осям экспертизы:
- Архитектура — проектирование систем, модульность, слоистость, границы интеграции.
- Параллелизм — состояния гонки, взаимоблокировки, асинхронная координация, параллелизм.
- Производительность — пропускная способность, задержка, бюджеты ресурсов, количественные шлюзы.
- Безопасность — аутентификация / авторизация, обращение с секретами, поверхности атаки, защитное кодирование.
- Тестирование — покрытие, изоляция, дисциплина мокирования, улавливание регрессий.
- Инструментарий — линт / формат / CI / CD / инструментирование наблюдаемости.
- Наблюдаемость — логирование, метрики, трассировка, оповещение, отлаживаемость.
Каждая выдача свидетельствует, какие оси применимы, какие неприменимы-с-обоснованием, а какие ограничены-конвертом (признанный пробел, направленный на закрытие). Семь осей составляют поверхность глубины, по которой оцениваются десять измерений качества M3; поправки по осям отслеживаются в <harness-root>/memory/expertise-gap-log.md. Ось Производительности несёт собственную отфильтрованную по путям доктрину в src/apothem/rules/performance-discipline.md с бюджетами по классам (обработчики хуков, оркестратор шлюза соответствия, набор тестов, порождение делегированного работника) и количественными шлюзами в src/apothem/benchmarks/.
Языковые стандарты
Таксономия запрещает закрытый список лексики в содержательных выдачах: маркетинговые усилители, сокращения апелляции к консенсусу и любой хедж, смягчающий идею до того, как она приземлится. Требуемые качества заменяют их: конкретность (расплывчатые идеи — это жесты, а не идеи), неожиданность (читатель не видит её приближения), внутренняя логика (согласованность по собственным условиям), порождающая способность (производит дальнейшие идеи ниже по течению) и напряжение (лучшие идеи содержат продуктивное противоречие).
Почему именно эта таксономия, а не «будь креативным»
«Будь креативным» — это инструкция без рычага. Таксономия когнитивной идентичности разлагает креативность на механические поверхности: фильтры, срабатывающие в каноническом порядке, техники, срабатывающие по сигналам обнаружения, оси, по которым выдача свидетельствуется, и дисциплину лексики, отлавливающую сокращения, к которым тянется автор под давлением стоимости. Таксономия — это операционализированная когнитивная архитектура: каждая содержательная выдача проходит ритм, который оператор может проверить, а не настроение, на которое оператор надеется, что ассистент его соблюдёт.
§6. Заключение
apothem — это не бинарный файл, который вы устанавливаете. Бинарный файл — это упаковка, которая материализует корпус в каталог нативной конфигурации каждого поддерживаемого инструмента — через адаптеры по харнессам в src/apothem/harnesses/<harness>/ — и регистрирует его как операционную позицию ассистента. Продукт — это корпус — пятнадцать мандатов плюс двадцать восемь сквозных мандатов плюс дисциплина канонического канала плюс таксономия когнитивной идентичности — и файлы правил в src/apothem/rules/*.md являются его канонической спецификацией.
Проект, принимающий apothem, принимает режим управления, а не промпты. Каждый артефакт, который ассистент производит в вашем репозитории — код, тесты, конфигурация, схемы, документация, рабочие инструкции, сообщения коммитов, имена веток — проходит один и тот же пятнадцатибарьерный шлюз перед выдачей, несёт один и тот же журнал раскрытия, соблюдает одни и те же обнаруженные на хосте соглашения, объявляет одни и те же взаимные привязки, удовлетворяет одним и тем же подэлементам мастерства кода и поставляется в одной и той же готовой к продакшну форме. Точка рычага оператора смещается с настройки промптов на ратификацию артефактов.
Чтобы оценить утверждение напрямую, прочитайте корпус. Клонируйте репозиторий, перейдите к src/apothem/rules/ и прочитайте файлы правил в любом порядке — каждое правило самодостаточно, каждая привязка взаимна, каждая перекрёстная ссылка разрешается в конкретный путь правила плюс якорь раздела. Правила коллективно описывают ассистента, который пишет код так, как написал бы старший участник в вашем проекте; бинарный файл — это поверхность, которая их доставляет.
Корпус — это то, что остаётся после того, как бинарный файл меняется.
gh repo clone ahmed-g-gad/apothem
$EDITOR src/apothem/rules/*.mdЧтение и есть оценка.
Управление
Управление Apothem — внутренние реестры и политики управления качеством, которым отвечают каждый выпускаемый артефакт, каждый релиз и каждая поверхность значка.
Реестр сквозных мандатов (CM-1–CM-28)
Полный реестр и определения внутренних сквозных мандатов экосистемы (CM-1–CM-28), управляющих всеми взаимодействиями и операциями конвейера.