Рабочий процесс установки
Как apothem install, update и uninstall работают от начала до конца.
Поток установки
flowchart TD
accTitle: Apothem install workflow
accDescr: Top-down flowchart of the apothem install command from CLI invocation through adapter lookup, profile load, adapter install call, native config write, and a follow-up apothem verify check that the operator runs.
A[apothem install --harness X] --> B[Resolve adapter through registry]
B --> C[Load and validate profile YAML<br/>before writes]
C --> D[Adapter.install(profile, project)]
D --> E[Write native config and support cohorts]
E --> F[Operator runs: apothem verify --harness X]
F --> G{All checks pass?}
G -- yes --> H[Done]
G -- no --> I[Report failures]Поток обновления
При apothem update --harness X:
- Загружает и проверяет
~/.config/apothem/profile.yamlили--profile PATH. - Разрешает выбранное окружение или
allчерез центральный реестр. - Проверяет полный план материализации перед первой записью.
- Вызывает
Adapter.update(profile, project=...). - Сообщает о результатах: создано, обновлено, без изменений, пропущено, предупреждение и ошибка.
Поток удаления
При apothem uninstall --harness X:
- Вызывает
Adapter.uninstall(). - Адаптер удаляет только те файлы, которые он записал; общий профиль YAML и несвязанные файлы, написанные оператором, остаются нетронутыми.
- Память, контексты и хранилища обучения общего рабочего каталога резервно
копируются и удаляются, когда это последнее установленное в нём окружение.
Удаление выполняется по месту, которое записала установка. Каталог
plans/никогда не удаляется.
Разрешение области
Каждый адаптер пишет в свой собственный фиксированный корень установки: домашний
каталог пользователя для адаптеров с областью пользователя и локальный путь
проекта для адаптеров с областью проекта. CLI не предоставляет флаг --scope;
адаптеры с областью проекта требуют --project <path>. Семь адаптеров с
областью проекта также записывают общие папки в домашнем каталоге пользователя,
такие как ~/.agents/skills/ и ~/.config/apothem/, до того как записать файл
проекта, и --project не меняет, куда они попадают. Их перечисляет
справочник по install.
Каждое место назначения задокументировано в
site/content/docs/harnesses/<harness>.mdx.
Обработка ошибок
Операции установки и обновления выполняют проверку перед записью, создают резервную копию существующих совпадающих целей перед заменой и объединяют только дочерние записи, управляемые Apothem, в общих каталогах обнаружения. --dry-run выполняет ту же проверку и возвращает результат, который дала бы каждая запись, например created или updated, не создавая каталогов и файлов.
Reversibility (backup and rollback)
Every install pass is reversible. Replaced bytes are captured into the Apothem
backup root and the pass is recorded in the harness ledger under a ULID
install id; apothem rollback selects a
recorded pass and restores those captured backups.
%% provenance: hand-authored %%
%% verified: 2026-07-06 %%
%% cross-reference: this page's Error handling section (back up before replace); /docs/cli-reference/rollback %%
flowchart LR
accTitle: Apothem backup and rollback lifecycle
accDescr: At install time each replaced target's prior bytes are captured into the Apothem backup root and the pass is recorded in the harness ledger under a ULID install id. The rollback command selects a recorded install pass by latest or install-id, restores every captured backup from the backup root, and appends a rollback record to the ledger.
subgraph Install
direction TB
I1["Back up existing targets<br/>before replacement"] --> I2["Apothem backup root"]
I1 --> I3["Ledger install record<br/>ULID install-id"]
end
subgraph Rollback
direction TB
R1["Select install pass<br/>--last or --install-id ULID"] --> R2["Restore captured backups<br/>from the backup root"]
R2 --> R3["Append rollback record<br/>to the harness ledger"]
end
I2 -.->|captured bytes| R2
I3 -.->|resolves pass| R1Контракт упаковки групп
Стабильный контракт для упаковки групп и манифестов плагинов, предназначенный для внешних потребителей: перечислить группы и разрешить их нативные цели по окружениям без повторного выведения сопоставления.
Самодостаточная среда выполнения
Как движок Apothem запускается из любого чекаута — вендоренные зависимости, модель вызова PYTHONPATH=src и начальная загрузка дерева плагина.