Архитектура исполнителей

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

Apothem читает один общий профиль (~/.config/apothem/profile.yaml) и материализует конфигурацию, нативную для среды, для семнадцати зарегистрированных адаптеров. Среды не разделяют общую модель возможностей делегированных исполнителей: одни предоставляют хуки перед вызовом инструмента, другие исполняют правила из плоских файлов .md, третьи встраивают каждое правило в единый файл инструкций, а некоторые рендерят конфигурацию на основе профиля во время установки. Эта страница описывает это расхождение и дисциплину, которую Apothem применяет поверх него.

Матрица возможностей делегированных исполнителей по средам

Приведённая ниже матрица охватывает все семнадцать сред. Колонки: поверхность хука PreToolUse, которую предоставляет каждая среда, формат, который Apothem использует для активации правил, класс адаптера (см. Классы адаптеров) и рендерит ли адаптер нативную конфигурацию через материализатор.

Примечания к матрице:

• claude-code — эталонный адаптер. Он несёт нативные хуки PreToolUse, PostToolUse, Stop и SessionStart и поставляет шаблоны настроек вендора. Он намеренно не управляет CLAUDE.md — этот файл является территорией, принадлежащей оператору.
• codex устанавливает нативные хуки жизненного цикла через hooks.json, преобразует исполнителей в TOML, оборачивает запросы команд как навыки Codex и оставляет config.toml во владении оператора.
• antigravity сохраняет ~/.gemini/GEMINI.md в качестве глобального якоря контекста и устанавливает плагин Apothem в ~/.gemini/antigravity-cli/plugins/apothem/. Файлы хуков сохраняются как вспомогательный материал, пока адаптер не возьмёт на себя трансляцию схемы хуков Antigravity.
• cursor активирует правила через файлы .mdc, несущие фронтматтер MDC вендора (description, globs, alwaysApply); адаптер не пишет одиночный файл .cursorrules.
• windsurf использует .devin/rules/; адаптер не пишет одиночный файл .windsurfrules.
• hermes и open-claw рендерят нативные файлы конфигурации и подключают вспомогательные каталоги навыков Apothem через документированную настройку каталога навыков каждой среды. Неподдерживаемые общие группы остаются в поддеревьях поддержки, принадлежащих Apothem.
• qwen-code рендерит документированные ключи settings.json для контекста и диспетчеризации хуков, затем использует нативные для Qwen каталоги команд, навыков и исполнителей.

Дисциплина межсредовой оркестрации

Apothem применяет сходимость по соглашениям соседних элементов: один и тот же вызываемый оператором рабочий процесс проецируется в нативную идиому каждой среды, а не принудительно приводится к одному общему формату. Правило, которое активируется как плоский файл .md под claude-code, становится правилом рабочей области .mdc под cursor, встроенным разделом GEMINI.md под gemini-cli и конкатенированной ссылкой в QWEN.md под qwen-code плюс нативными каталогами обнаружения — то же намерение, диалект каждой среды.

Каноническая эталонная группа находится по адресу:

src/apothem/{rules,commands,skills,agents,output-styles,hooks,conformity,statuslines}/

Каждый адаптер распространяет подмножество этой группы. Подмножество для каждой среды объявлено в src/apothem/lib/propagation-manifest.yaml; манифест является единым источником истины о том, какие артефакты достигают какой среды и в какой форме. Адаптер никогда не изобретает артефакты вне манифеста, а манифест никогда не назначает артефакт среде, у которой нет поверхности для его размещения.

Объяснение классов адаптеров

Apothem сортирует адаптеры на три класса по тому, как они транслируют общий профиль в нативный для среды вывод.

• Класс I — прямое распространение. Адаптер копирует канонические эталонные артефакты (подмножество, объявленное в манифесте) напрямую в место конфигурации среды без шага рендеринга. Материализатора нет. antigravity, codebuddy, codex, cursor, gemini-cli, github-copilot, glm, kimi-code, kiro, trae, windsurf и zed относятся к Классу I.
• Класс II-A — прямое распространение + шаблоны настроек, привязанные к вендору. Адаптер выполняет прямое распространение артефактов и дополнительно управляет специфичными для вендора шаблонами настроек, привязанными к схеме вендора. claude-code относится к Классу II-A.
• Класс II-B — материализатор единой поверхности, рендеримой из профиля. Адаптер рендерит общий профиль в единую нативную поверхность конфигурации через материализатор. hermes, open-claw, opencode и qwen-code относятся к Классу II-B.

Поведение во время материализации

Различие классов проявляется во время материализации — когда оператор запускает CLI против среды:

• apothem install --harness <H> распространяет подмножество манифеста для <H> и для адаптеров Класса II-A / II-B рендерит нативную для среды конфигурацию.
• apothem verify --harness <H> проверяет установленную конфигурацию против того, что произвёл бы текущий профиль, и сообщает о расхождении.
• apothem doctor сообщает статус по средам для каждого зарегистрированного адаптера — установлено / отсутствует / расхождение.

См. справочник по CLI для полных поверхностей команд.

Таксономия расхождений

Семнадцать сред расходятся по трём осям. Каждое различие между средами в матрице сводится к одной из них.

Задача Apothem — удерживать одно согласованное намерение оператора постоянным, пока эти три оси варьируются от среды к среде. Манифест распространения и контракт класса адаптера — два механизма, которые сохраняют это намерение стабильным поверх расхождения.