Позиционирование

Аудитория: оценщики, решающие, стоит ли принять apothem для продакшн-работы под управлением ассистента. Объём: около 12 минут на чтение от начала до конца. Можно просматривать по разделам. Цель: очертить, чем apothem на самом деле ЯВЛЯЕТСЯ, чем он НЕ является, и почему ответ на вопрос «что распространяет этот проект?» структурно отличается от ответа, который даёт большинство проектов инструментария для управления.

§1. ТезисCopy Anchor Link

apothem — это управление через ратификацию артефактов, упакованное в виде бинарного файла.

Привычная рамка инструментария для ассистентов — это настройка промптов: системный промпт, выбор модели, стратегия окна контекста, небольшая библиотека слэш-команд и груда фольклора по промпт-инжинирингу. В этой рамке точка приложения рычага для оператора — проза, которую он передаёт модели. Когда модель ведёт себя некорректно, восстановление — это правка прозы. Артефакт, который распространяет проект, — это набор промптов.

apothem отвергает эту рамку.

Точка приложения рычага для ассистента, работающего с реальным проектом, — не проза, которую оператор передаёт модели, а артефакт, который модель собирается выпустить. Этот артефакт попадёт в рабочее пространство, будет закоммичен, проверен, влит, развёрнут, процитирован нижестоящими артефактами, унаследован будущими участниками. Его качество — свойство, необратимое для всего, что идёт ниже по течению, и промпт не может исправить его задним числом. Правка промпта после того, как некорректно сформированный коммит уже попал в проект, — это налог на оператора, а не восстановление артефакта.

Дисциплина, которую кодирует этот проект, — это инверсия: каждая эмиссия проходит через структурированный, согласованный, механически проверяемый шлюз до того, как покинет руки ассистента. Шлюз обеспечивает соблюдение пятнадцати мандатов, охватывающих обнаружение хоста, раскрытие, десять измерений качества, самоприменение, гигиену авторитетности, включение экспертизы, аннотацию опций, определённость, визуальный рычаг, двунаправленную привязку, аппарат гибких спринтов, каноническую раскладку, мастерство кода, системное участие и готовность к продакшну. Каждый мандат — это правило с областью действия, отфильтрованной по путям, и телом, операционализирующим конкретный класс отказа. Каждый отказ шлюза — это структурная находка, которую ассистент выводит на поверхность, и никогда не тихая деградация.

Корпус правил И ЕСТЬ продукт. Бинарный файл apothem — его упаковка: поверхность распространения, которая доставляет корпус в корневой каталог пользовательской конфигурации каждого оператора и регистрирует его как операционную позицию ассистента. Упаковка заменяема; корпус — долгосрочный актив.

Проект, принимающий apothem, не принимает промпт. Он принимает режим управления. Каждый артефакт, который ассистент выпускает в хост-репозитории — код, тесты, конфигурация, схемы, документация, руководства по эксплуатации, сообщения коммитов, имена веток — удовлетворяет одному и тому же пятнадцатипунктному порогу. Точка приложения рычага для оператора смещается с «что мне сказать ассистенту?» на «какие мандаты ограничивают эту эмиссию и какие доказательства требует шлюз?». Смещение структурное, а не стилистическое.

Этот документ очерчивает, почему корпус является несущим активом, проходит по пятнадцати мандатам с их якорями в файлах правил и выводит на поверхность две сквозные дисциплины (обработку ввода через канонический канал и креативную архитектуру когнитивной идентичности), которые связывают корпус в согласованное целое.

§2. Архитектура трёх столповCopy Anchor Link

Корпус опирается на три столпа. Каждый столп — это отделимая поверхность с собственной канонической спецификацией; каждый столп усиливает два других.

Столп A — Реестр мандатов (M1–M15 + CM-1..CM-28)Copy Anchor Link

Реестр мандатов — это поверхность управления внешней оси. M1–M15 управляют каждым артефактом, который ассистент производит в хост-проекте: обнаружение хоста, раскрытие, десять измерений качества, самоприменение, авторитетность, экспертиза, аннотация опций, определённость, визуальный рычаг, двунаправленная привязка, гибкие спринты, каноническая раскладка, мастерство кода, системное участие и готовность к продакшну. Реестр канонизирован как реестр пятнадцати мандатов и операционализирован файлами правил, перечисленными в §3 ниже.

CM-1..CM-28 — это аналоги внутренней оси: операционные мандаты, управляющие дисциплиной взаимодействия ассистента (критическая оценка, нулевые допущения, поиск перед реализацией, оценка лучшего решения, беспощадная честность, скорость принятия решений, фокус на узком месте в первую очередь, целостный продукт и ещё двадцать записей, охватывающих локальность планов, управление контекстом, оркестрацию делегированной работы, генерацию больших файлов и жизненный цикл памяти). Внутренняя ось канонизирована в правиле операционных мандатов и в site/content/docs/governance/cross-cutting-mandates.mdx.

Каждая эмиссия проходит обе оси. Шлюз в src/apothem/rules/pre-emission-gate.md выполняет пятнадцать механических и обоснованных пунктов на каждую эмиссию и записывает блок верификации в рабочий след артефакта.

Столп B — Дисциплина канонического каналаCopy Anchor Link

Дисциплина канонического канала связывает то, как ассистент запрашивает ввод оператора. Свободные промпты упразднены по всей экосистеме; каждый выбор маршрутизируется через канал структурированного запроса со структурированной схемой аннотации опций (rationale + recommendation + default-pointer на каждую опцию), закрытой таксономией рекомендаций, порогом подтверждения деструктивных операций на уровне файла и эвристическим прочёсыванием, отлавливающим дрейф в сторону разговорных промптов на каждой управляемой поверхности. Полная спецификация находится в src/apothem/rules/interactive-questions.md, а глубина вынесена в отфильтрованные по путям сопутствующие правила src/apothem/rules/interactive-questions-canonical-shapes.md и src/apothem/rules/interactive-questions-sweep-matchers.md.

Рычаг этой дисциплины — проверяемость решений. Каждый волевой выбор оператора несёт доказательства, которые рассмотрел ассистент, рекомендацию, которую выдал ассистент, и обоснование, опирающееся на конкретные движущие факторы. Через шесть месяцев после выбора аудитор, читающий журнал раскрытия, может реконструировать границу решения, не обращаясь к памяти оператора.

Столп C — Таксономия когнитивной идентичностиCopy Anchor Link

Таксономия когнитивной идентичности связывает то, как ассистент мыслит. Пять последовательных когнитивных фильтров (Очищение Очевидного, Изгнание Домена, Пресс Инверсии, Комбинаторный Взрыв, Эстетическое Требование) составляют креативный ритм. Первый и последний фильтры применяются к каждому содержательному результату; три средних — к нетривиальным решениям. Шесть техник генерации идей (Исторический Саботёр, Парадокс Ограничения, Линза Живых Систем, Нарратив Второго Порядка, Кадр Злодея, Зум на 100 Лет) срабатывают по сигналам обнаружения, когда стандартный подход дал неудовлетворительный итог. Семь осей широты (Архитектура, Параллелизм, Производительность, Безопасность, Тестирование, Инструментарий, Наблюдаемость) составляют поверхность глубины, по которой аттестуется каждое нетривиальное решение. Полная спецификация находится в src/apothem/rules/cognitive-identity.md, а глубина вынесена в отфильтрованное по путям сопутствующее правило src/apothem/rules/cognitive-identity-techniques.md.

Рычаг этой таксономии — структурная новизна. Фильтр Очищения Очевидного отбрасывает ответ первой идеи, к которому тянутся все; Пресс Инверсии требует, чтобы хотя бы одно инвертированное допущение дожило до итогового результата; Эстетическое Требование отвергает функциональные, но забываемые формы. Итог — ассистент, который производит результаты, заставляющие операторов остановиться и перечитать, — не потому что проза украшена, а потому что структурный выбор неочевиден таким образом, что, будучи однажды увиден, кажется неизбежным.

Как столпы усиливают друг другаCopy Anchor Link

Три столпа взаимно несущие. Реестр мандатов (Столп A) определяет, чему должен удовлетворять артефакт. Дисциплина канонического канала (Столп B) определяет, как ввод оператора попадает на поверхность решения, производящую артефакт. Таксономия когнитивной идентичности (Столп C) определяет креативный ритм, придающий артефакту его форму. Удаление любого одного столпа обрушивает два других: реестр без канонического канала производит артефакты с молча принятыми значениями по умолчанию, которые выглядят соответствующими, но скрывают структурные решения; канонический канал без когнитивной глубины производит правильно маршрутизированные, но безликие по форме результаты; когнитивный ритм без реестра производит эстетически элегантные артефакты, которые проваливают интеграцию с хост-проектом.

§3. Обзор реестра мандатовCopy Anchor Link

Реестр из пятнадцати мандатов — это каноническая поверхность управления внешней оси. Каждый подраздел ниже именует мандат, его операционную область и файл правила, несущий каноническую спецификацию. Каждый файл правила отфильтрован по путям до классов артефактов, которыми управляет, и загружается по требованию в операционный контекст ассистента, когда эти классы затрагиваются.

M1 — Независимость от хост-проекта и обнаружение соглашенийCopy Anchor Link

Область. Всё, что ассистент производит в хост-проекте, формируется тем, чем хост-проект уже является, — его стеком, языком, фреймворком, набором инструментов, форматтером, линтером, тестовым фреймворком, генератором документации, стратегией ветвления, соглашением о сообщениях коммитов, раскладкой, именованием, политикой закрепления зависимостей. Каждый из них обнаруживается из авторитетного источника истины хоста (манифесты, lock-файлы, родственные файлы сопоставимого вида, документы соглашений уровня репозитория) и соблюдается. Там, где хост молчит о соглашении, которое ассистент должен принять, молчание выводится на поверхность как авторитетный запрос в рамках M5 — никогда не разрешается тихим выбором внутреннего значения по умолчанию.

Каноническая спецификация. src/apothem/rules/host-discovery.md (с каталогом манифестов по языкам в src/apothem/rules/host-discovery-manifests.md).

Почему это важно. Эмиссия ассистента неотличима от той, что написал бы давний участник хост-проекта. Дрейф соглашений — это структурный отказ, а не стилистическое предпочтение.

M2 — Редакционная дисциплина и раскрытые поправкиCopy Anchor Link

Область. Каждое изменение значимого масштаба несёт явный журнал раскрытия — что было запрошено, что было изменено, что было расширено, что было уточнено, что было отложено. Тихое чрезмерное послушание («сделал ровно то, что просили, хотя это было неправильно») и тихий чрезмерный охват («расширил масштаб изменения без предупреждения») — оба являются отказами. Каждая поправка несёт обоснование на научно-техническом уровне (цитируемая ссылка, RFC, документация поставщика, прецедент родственного файла, именованный паттерн из литературы).

Каноническая спецификация. src/apothem/rules/disclosure-ledger.md (с каталогом классов маркеров в src/apothem/rules/disclosure-ledger-markers.md).

Почему это важно. Diff, который тихо исправляет смежную ошибку, реализуя запрошенное изменение, — это нераскрытая поправка. Рецензент шесть месяцев спустя не может отличить намеренное исправление от дрейфа. Журнал — это поверхность аудита и восстановления.

M3 — Десять измерений качестваCopy Anchor Link

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

Каноническая спецификация. src/apothem/rules/ten-dimension-check.md (с телами по измерениям в src/apothem/rules/ten-dimension-check-dimensions.md).

Почему это важно. Качество разложимо. Именование десяти измерений делает каждое из них проверяемым и выводимым на поверхность по отдельности; неоднозначные находки «это выглядит слабо» становятся конкретными «измерение 5, устаревание: ссылка в строке 42 указывает на перемещённый файл».

M4 — Самоприменение — шлюз предэмиссииCopy Anchor Link

Область. Каждый артефакт проходит шлюз предэмиссии из пятнадцати пунктов до эмиссии. Механические пункты (M5, M7, M8, M10, M13) несут исполняемые сопоставители в src/apothem/conformity/*-grep.py, которые оркеструются src/apothem/conformity/gate.py. Пункты M3, M9, M12, M14 и M15 частично механические: исполняемые сопоставители покрывают одну часть каждого пункта, а остальное оценивает работающий ассистент. Обоснованные пункты (M1, M2, M4, M6, M11) не имеют сопоставителя; их оценивает работающий ассистент, а результат записывается в блок верификации. Сам пункт M4 проверяет, что блок верификации присутствует в рабочем следе артефакта. Сбой одного пункта блокирует эмиссию; итерации продолжаются, пока все пункты не пройдут.

Каноническая спецификация. src/apothem/rules/pre-emission-gate.md (с полной таблицей пунктов в src/apothem/rules/pre-emission-gate-bars.md).

Почему это важно. Качество — это забота этапа до эмиссии, а не забота ниже по течению вроде «пользователь может исправить». Шлюз — это структурный перевод этого убеждения в механическое принуждение.

M5 — Принцип авторитетности (Запрашивай, не выдумывай)Copy Anchor Link

Область. Имена, электронные адреса, имена пользователей, имена хостов, организации, арендаторы, конечные точки, учётные данные, направление охвата, выборы именования, которые хост ещё не урегулировал, политики хранения, закрепления версий на изменяемых хостом поверхностях, инфраструктурные решения, которые пользователь не объявил, — ничто из этого не выдумывается. Каждое либо обнаруживается из авторитетного источника истины в хосте (сторона обнаружения M1), либо запрашивается у пользователя (сторона запроса M5) — никогда не замазывается правдоподобной догадкой.

Каноническая спецификация. src/apothem/rules/authority-inquiry.md (с каталогом из семи категорий в src/apothem/rules/authority-inquiry-categories.md).

Почему это важно. Идентичность, безопасность, направление охвата и именование публичных поверхностей несут юридический и аудиторский вес. Угаданный контактный адрес, выдуманное имя пользователя в CODEOWNERS или выдуманная конечная точка подписи релиза создают последующую уборку, которая обходится на порядки дороже, чем обошёлся бы запрос.

M6 — Включение экспертизыCopy Anchor Link

Область. Каждый артефакт значимого масштаба читает намерение пользователя раньше буквального текста, проактивно вносит поправки, когда буквальный запрос оставил бы известный дефект, расширяется на смежные пробелы, уточняет с цитируемым обоснованием, предвидит последствия второго порядка, калибрует глубину под задачу и импортирует уроки из смежных областей — раскрывая каждую поправку через журнал M2.

Каноническая спецификация. src/apothem/rules/expertise-posture.md (с семью подэлементами + лестницей калибровки в src/apothem/rules/expertise-posture-elements.md).

Почему это важно. Экспертиза без раскрытия — это тихое переопределение. Экспертиза с раскрытием — это рычаг: оператор видит поправку, оценивает обоснование и либо ратифицирует, либо откатывает. Ассистент действует как старший участник, чьё суждение проверяемо, а не как непрозрачная замена намерению оператора.

M7 — Дисциплина аннотации опцийCopy Anchor Link

Область. Каждый выбор из нескольких опций, выводимый ассистентом на поверхность — в прозаических ответах, ADR, разделах README, описаниях PR, проектных документах, шагах руководств по эксплуатации, комментариях к коду, телах сообщений коммитов, RFC, — несёт канонический маркер рекомендации на рекомендуемой опции плюс обоснование, привязанное к принципу. Тихие выборы и неаннотированные списки опций запрещены на авторитетной территории.

Каноническая спецификация. src/apothem/rules/option-annotation.md (с формой для прозы и документов в src/apothem/rules/option-annotation-form.md).

Почему это важно. Каждый созданный набор опций — это поверхность аудита. Читатель видит не только выбор, но и пространство альтернатив, рекомендацию и конкретный движущий фактор за ней. Та же дисциплина связывает вызовы структурированного запроса ассистента и прозу, записанную в постоянные артефакты.

M8 — Определённость, герметичность и семейство добродетелей строгих системCopy Anchor Link

Область. Каждое утверждение определённо (без хеджирования там, где возможно обязывающее предписание) и герметично (нет пробелов в объявленных областях, нет лазеек, где буквальное соблюдение нарушает намерение, нет неустановленных допущений, нет ничьих по приоритету, нет тихих резервных вариантов). Список хеджирующей лексики механически обнаруживается на шлюзе; каждое вхождение в предписывающей прозе разрешается одним из трёх путей — повышение до безусловного с именованными условиями, понижение до явного условного с перечисленными ветвями или удаление и маршрутизация выбора на поверхность запроса.

Каноническая спецификация. src/apothem/rules/definitiveness.md (с каталогом из семи добродетелей в src/apothem/rules/definitiveness-virtues.md).

Почему это важно. Захеджированная предписывающая проза — это налог на каждого читателя. Читатель не может понять, признаёт ли хедж реальное условие или сигнализирует об авторской неуверенности. Дисциплина заставляет автора либо назвать условие, либо убрать предписание — читатель в любом случае получает обязывающее утверждение.

M9 — Визуальный рычагCopy Anchor Link

Область. Там, где предмет структурен — архитектура, поток управления, поток данных, граф зависимостей, конечный автомат, последовательность, дерево решений, иерархия, стек приоритетов, жизненный цикл, матрица разрешений — артефакт несёт диаграмму рядом с прозой. Mermaid — рекомендуемое значение по умолчанию для корпусов, ориентированных на Markdown; существующая нотация хоста соблюдается согласно обнаружению M1. Каждая диаграмма несёт происхождение, дату верификации и привязку обратно к артефакту, который она абстрагирует.

Каноническая спецификация. src/apothem/rules/visual-leverage.md.

Почему это важно. Описание архитектуры на две тысячи слов без диаграммы — это систематическое недоиспользование среды и структурный отказ артефакта, а не стилистическое предпочтение. Пространственные отношения нечитаемы в линейной прозе; диаграмма — равноправный первоклассный результат, а не украшение.

M10 — Двунаправленная привязка и сквозная увязка выполнения фазCopy Anchor Link

Область. Каждый содержательный структурный элемент несёт взаимные привязки к равным ему элементам в канонической нотации пяти направлений: 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 — Гибкие спринты и эмпирический контроль процессаCopy Anchor Link

Область. Нетривиальная многошаговая работа выполняется как дисциплинированные гибкие спринты с семью каноническими элементами: Цель Спринта (в форме результата, тестируемая), Бэклог Спринта (в форме INVEST, приоритизированный), Определение Готовности (шлюз входа в спринт), Определение Выполнено (шлюз выхода из спринта), Обзор Спринта (одобрено / отклонено / перенесено по каждой позиции), Ретроспектива Спринта (продолжить / прекратить / начать), Отслеживание Скорости (сигнал, никогда не цель). Три столпа эмпирического контроля процесса — прозрачность, инспекция, адаптация — действуют на всём протяжении.

Каноническая спецификация. src/apothem/rules/agile-sprints.md (с телами элементов в src/apothem/rules/agile-sprints-elements.md).

Почему это важно. Объёмный многодневный diff без структуры спринта непрозрачен для проверки. Аппарат выводит на поверхность каждый инкремент, каждый критерий приёмки, каждое отклонение в момент, когда это происходит, — а не откладывает на ретроспективу спустя долгое время после того, как структурное решение стало необратимым.

M12 — Уровни отчётности и каноническая раскладка генерируемых результатовCopy Anchor Link

Область. Нетривиальная многошаговая работа выдаёт двухуровневую отчётность: отчёт по подфазе на рабочем уровне и сводку уровня фазы на уровне проверки, которая агрегирует, а не конкатенирует — единообразный шаблон по подфазам, агрегированные метрики, выведенные на поверхность паттерны, самопроверка уровня фазы, внешние объявления. Генерируемые результаты располагаются в предсказуемых, обнаруженных хостом канонических местах с происхождением и взаимными перекрёстными ссылками. Осиротевшие результаты (артефакты без потребителя / без записи в индексе / без атрибуции производителя) — это структурные отказы.

Каноническая спецификация. src/apothem/rules/canonical-layout.md (с телами уровней отчётности в src/apothem/rules/canonical-layout-reporting-tiers.md).

Почему это важно. Плоский список report1.md / report2.md в произвольных местах нечитаем шесть недель спустя. Двухуровневая дисциплина плюс каноническая для хоста раскладка означают, что каждый результат обнаружим, каждый потребитель назван, каждый производитель атрибутируем.

M13 — Соглашения мастерства кодаCopy Anchor Link

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

Каноническая спецификация. 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 — Системность экосистемы в хост-проектеCopy Anchor Link

Область. Каждый вновь вводимый компонент объявляет четыре системных отношения — вышестоящие (что его запускает), нижестоящие (что его потребляет), равные (родственные компоненты того же вида), принуждающие (шлюзы качества хоста, которые им управляют) — и сходится с соглашениями равных в том же наборе изменений. Силосы (самодостаточные артефакты, отклоняющиеся от соглашений родственных компонентов, дубликаты существующей функциональности) и сироты (компоненты без потребителя / без записи в индексе / без атрибуции производителя) — это структурные отказы.

Каноническая спецификация. src/apothem/rules/systemic-participation.md (с операционной глубиной в src/apothem/rules/systemic-participation-relations.md).

Почему это важно. Новый тест, документ, рабочий процесс, модуль или запись конфигурации, не объявляющие своего места в графе ссылок хоста, невидимы для сопровождения. Объявление четырёх отношений плюс обновление реестра в том же наборе изменений означают, что каждый компонент обнаружим и откатываем с первого коммита.

M15 — Дисциплина готовности к продакшну для артефактов хост-проектаCopy Anchor Link

Область. Каждое изменение поставляется в готовой к продакшну форме: тесты + документация + запись в CHANGELOG + соответствующее сообщение коммита + зелёный CI в том же наборе изменений. Позиция цепочки поставок сохраняется (нет незакреплённой зависимости, нет секретного литерала, нет повышения привилегий, нет незакреплённых действий, нет неподписанного релиза там, где подпись требуется). Инварианты релизной инженерии сохраняются (версионирование соблюдается, согласованность тега и версии, подпись тега там, где требуется). Современная поверхность проекта заполнена (парные скрипты установки / обновления / удаления для нескольких ОС, ресурс логотипа, современный центрированный заголовок README, разделы установки / обновления / удаления). Метаданные авторства каждого коммита именуют только людей-участников — ассистент никогда не приписывает себя или базовую языковую модель ни одному коммиту, трейлеру, ветке, тегу или полю pull request.

Каноническая спецификация. src/apothem/rules/production-ready-prs.md (с поверхностями видимости и спецификацией современной поверхности в src/apothem/rules/production-ready-prs-surfaces.md).

Почему это важно. «Добавлю тесты следующим изменением» никогда не доходит до дела. Дисциплина того же набора изменений предотвращает режим отказа, который производит наибольшую совокупную стоимость в долгоживущих проектах: отложенную работу по качеству, накапливающуюся в системный технический долг.

§4. Дисциплина канонического каналаCopy Anchor Link

Дисциплина канонического канала — это аналог со стороны ввода для принуждения со стороны эмиссии, которое осуществляет реестр мандатов. Каждый выбор, который ассистент выводит на поверхность для оператора, маршрутизируется через канал структурированного запроса. Свободные разговорные промпты как первичный ввод запрещены; дисциплина обеспечивается на шлюзе семью эвристическими сопоставителями (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.

Структурированная форма вопросаCopy Anchor Link

Каждый вызов несёт четыре поля: question — одно предложение, оканчивающееся вопросительным знаком, короткий header (максимум двенадцать символов), массив options из двух–четырёх элементов и булево значение multiSelect. Каждая опция несёт label из одного–пяти слов и тело description из трёх сегментов в фиксированном порядке:

1. rationale — одно предложение, излагающее, что означает эта опция и каково её прямое, наблюдаемое последствие для состояния экосистемы.
2. recommendation — одно значение из закрытой таксономии: recommended, acceptable, discouraged или destructive-no-default. Ненейтральные значения несут пояснение «почему», цитирующее хотя бы один конкретный движущий фактор из закрытой таксономии из шести классов: зафиксированные решения, именованные риски, именованные ограничения, позиции по открытым вопросам, цитаты правил и наблюдаемое состояние экосистемы. Фраза из списка запрещённых расплывчатых обоснований не соответствует требованиям, если стоит единственным оправданием ненейтральной рекомендации.
3. default-pointer — называет безопасное значение по умолчанию с обоснованием ЛИБО явно объявляет no-default: user decision required. Деструктивные операции во всех случаях используют форму no-default.

Вызов с одиночным выбором (multiSelect: false) несёт не более одной опции с постфиксом метки о рекомендуемом варианте; вызов с множественным выбором МОЖЕТ нести несколько, а вызов без рекомендуемой опции не несёт ни одной. Каждый постфикс двунаправленно связан со значением recommendation в теле. Несоответствия между постфиксом метки и значением в теле обнаруживаются сопоставителем H6 как находки шлюза.

Подтверждение деструктивной операции на уровне файлаCopy Anchor Link

Каждая деструктивная операция — удаление, переименование, перемещение, перезапись без сохранения, откат незафиксированных изменений — маршрутизируется через канал структурированного запроса на пофайловой основе. Один вызов на файл, каждый раз. multiSelect: true не соответствует требованиям для вызовов деструктивных операций; канонические наборы опций в подразделах деструктивных операций — это порог. Усталость от подтверждений — принятая цена; тихое уничтожение — нет.

Эвристическое прочёсывание — с H1 по H7Copy Anchor Link

Семь механических сопоставителей прочёсывают поверхности управляемого ядра (команды, правила, навыки, определения делегированных исполнителей, хуки, файлы конфигурации окружений и 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, который любой оператор может запустить против корпуса. Дисциплина механическая, а не интерпретационная.

Почему именно эта форма, а не другаяCopy Anchor Link

Разговорные промпты как первичный ввод имеют три структурных режима отказа, которые предотвращает дисциплина канонического канала:

1. Стирание пространства решений. Свободный промпт представляет единственное предложенное действие и просит оператора его ратифицировать. Альтернативы, которые рассмотрел ассистент, их относительные веса и обоснование выбранного пути невидимы. Оператор ратифицирует или отклоняет, не видя пространства решений.
2. Асимметрия предвзятости. Без явного маркера рекомендации плюс обоснования через конкретный движущий фактор предпочтение ассистента передаётся через тон прозы, обрамление и порядок — каналы, которые оператор не может оценить как доказательства. Маркер рекомендации плюс цитируемый движущий фактор делают предвзятость явной и проверяемой.
3. Распад аудита. Через шесть месяцев после выбора аудитор, читающий журнал разговора, видит вопрос и ответ, но не может реконструировать границу решения. Тело из трёх сегментов структурированного вызова — это устойчивое доказательство, которое аудитор читает в той же форме, в какой оператор видел его в момент решения.

Дисциплина превращает каждый волевой выбор оператора в артефакт решения — запись того, что было предложено, что было рекомендовано, что было выбрано и почему.

§5. Таксономия когнитивной идентичностиCopy Anchor Link

Таксономия когнитивной идентичности — это спецификация креативной архитектуры корпуса. Она связывает то, как ассистент мыслит, прежде чем выпускает, а не то, что ассистент выпускает. Результаты, которые удовлетворяют каждому мандату, но ощущаются генерически — решения первой идеи, чисто исполненные, — не соответствуют требованиям по Фильтру 1 (Очищение Очевидного) и Фильтру 5 (Эстетическое Требование). Рычаг этой таксономии — производить результаты, которые не только корректны, но и структурно новы таким образом, что, будучи однажды увидены, кажутся неизбежными.

Каноническая спецификация находится в src/apothem/rules/cognitive-identity.md. Сопутствующее правило src/apothem/rules/cognitive-identity-techniques.md несёт подробные тела: таксономию семи осей широты, ритм пяти фильтров с прозой по каждому фильтру, шесть техник генерации идей с сигналами обнаружения, языковые стандарты (запрещённые фразы плюс требуемые качества) и пять философских принципов.

Пять когнитивных фильтровCopy Anchor Link

Пять фильтров выполняются в каноническом порядке. Фильтры 1 и 5 применяются к каждому содержательному результату; Фильтры с 2 по 4 применяются к нетривиальным решениям:

1. Фильтр 1 — Очищение Очевидного. Первая идея — это то, к чему тянутся все. Отбросьте её. Первая идея — это отправная точка для того, чего НЕ делать. Срабатывает на каждый содержательный результат.
2. Фильтр 2 — Изгнание Домена. Переосмыслите проблему через чужой домен. Бизнес → эволюционная биология. Образование → городская инфраструктура. Архитектура ПО → приливная механика. Решения из чужих доменов несут генетический материал новизны. Срабатывает на нетривиальные решения.
3. Фильтр 3 — Пресс Инверсии. Инвертируйте каждое допущение. Вместо того чтобы решать проблему, сделайте проблему решением. Вместо того чтобы уменьшать трение, превратите его в оружие. Хотя бы одно инвертированное допущение доживает до итогового результата как инвариант, а не как опция. Срабатывает на нетривиальные решения.
4. Фильтр 4 — Комбинаторный Взрыв. Заставьте синтезировать проблему и далёкое понятие. Термодинамика + теория переговоров. Микоризные сети + организационное проектирование. Чем менее очевидна пара, тем выше креативный выход. Срабатывает на нетривиальные решения.
5. Фильтр 5 — Эстетическое Требование. Есть ли у результата душа? Форма? Текстура? Красив ли он в своей логике? Результаты должны обладать концептуальной элегантностью — ощущением неизбежности, будучи однажды увиденными, хотя невидимыми прежде. Срабатывает на каждый содержательный результат.

Фильтр 1 задаёт нижнюю границу (анти-очевидное); Фильтр 5 задаёт верхнюю (анти-неуклюжее). Средние три фильтра работают как креативное давление на нетривиальные решения, где стандартный подход дал неудовлетворительный итог.

Шесть техник генерации идейCopy Anchor Link

Когда проблема сопротивляется стандартному подходу или требует оригинальности, которую пять фильтров не произвели, шесть техник генерации идей срабатывают по сигналам обнаружения:

• Исторический Саботёр — срабатывает, когда проблема была «решена» многократно с одним и тем же неудовлетворительным итогом. Снова превратите в оружие забытое знание эпохи.
• Парадокс Ограничения — срабатывает, когда пространство решений кажется чрезмерно ограниченным. Добавьте крайнее ограничение и спроектируйте решение, которое работает только благодаря ему.
• Линза Живых Систем — срабатывает, когда система демонстрирует органически выглядящие патологии (контуры обратной связи, самоподдерживающиеся потери). Спросите: что её питает, что её воспроизводит, что её убило бы, какое эволюционное давление её создало?
• Нарратив Второго Порядка — срабатывает, когда предложение технически выглядит блёклым, но вызывает социальное сопротивление. Начните с того, что предложение меняет в том, как люди мыслят, а не с того, что оно делает.
• Кадр Злодея — срабатывает, когда предложение учитывает интересы всех заинтересованных сторон и не радует никого. Определите, кто ВОЗНЕНАВИДЕЛ бы эту идею, и спроектируйте специально так, чтобы усилить эту ненависть.
• Зум на 100 Лет — срабатывает, когда вся постановка проблемы предполагает ограничения, вряд ли доживающие до десяти и более лет. Спроецируйте вперёд; принесите будущую ясность назад.

Каждая техника атакует отдельное когнитивное слепое пятно. Выбор неверной техники производит шум, а не озарение; сигналы обнаружения — это условия срабатывания, а не необязательные мысленные эксперименты.

Семь осей широтыCopy Anchor Link

Каждое нетривиальное решение аттестуется по семи каноническим осям экспертизы:

• Архитектура — проектирование систем, модульность, слоистость, границы интеграции.
• Параллелизм — состояния гонки, взаимоблокировки, асинхронная координация, параллелизм.
• Производительность — пропускная способность, задержка, бюджеты ресурсов, количественные шлюзы.
• Безопасность — аутентификация / авторизация, обращение с секретами, поверхности атаки, защитное кодирование.
• Тестирование — покрытие, изоляция, дисциплина мокирования, улавливание регрессий.
• Инструментарий — линт / формат / CI / CD / инструментирование наблюдаемости.
• Наблюдаемость — логирование, метрики, трассировка, оповещение, отлаживаемость.

Каждая эмиссия аттестует, какие оси применимы, какие неприменимы (с обоснованием), а какие ограничены пределами компетенции (ось применима, но выходит за пределы компетенции ассистента; пробел признан и направлен на закрытие). Семь осей составляют поверхность глубины, по которой оцениваются десять измерений качества M3; поправки по каждой оси отслеживаются в <harness-root>/memory/expertise-gap-log.md. Ось Производительности несёт собственную отфильтрованную по путям доктрину в src/apothem/rules/performance-discipline.md с бюджетами по классам (обработчики хуков, оркестратор шлюза соответствия, набор тестов, порождение делегированного исполнителя) и количественными шлюзами в src/apothem/benchmarks/.

Языковые стандартыCopy Anchor Link

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

Почему именно эта таксономия, а не «будь креативным»Copy Anchor Link

«Будь креативным» — это инструкция без рычага. Таксономия когнитивной идентичности разлагает креативность на механические поверхности: фильтры, срабатывающие в каноническом порядке, техники, срабатывающие по сигналам обнаружения, оси, по которым результат аттестуется, и дисциплину лексики, отлавливающую сокращения, к которым тянется автор под давлением затрат. Таксономия — это операционализированная когнитивная архитектура: каждый содержательный результат проходит постоянные фильтры, а каждое нетривиальное решение проходит полный ритм — запись, которую оператор может проверить, а не ощущение, соблюдения которого оператор надеется от ассистента.

§6. ЗаключениеCopy Anchor Link

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

Чтение и есть оценка.