Installation workflow
How apothem install, update, and uninstall work end-to-end.
Install flow
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 final apothem verify check.
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[apothem verify --harness X]
F --> G{All checks pass?}
G -- yes --> H[Done]
G -- no --> I[Report failures]Update flow
On apothem update --harness X:
- Load and validate
~/.config/apothem/profile.yamlor--profile PATH. - Resolve the selected harness or
allthrough the central registry. - Validate the full materialization plan before the first write.
- Call
Adapter.update(profile, project=...). - Report created, updated, unchanged, skipped, warning, and error outcomes.
Uninstall flow
On apothem uninstall --harness X:
- Call
Adapter.uninstall(). - The adapter removes only the files it wrote; the shared profile YAML and unrelated operator-authored files are untouched.
Scope resolution
Each adapter writes to its own fixed install root: user-home for user-scope
adapters and project-local for project-scope adapters. The CLI does not expose
a --scope flag; project-scope adapters require --project <path>. Each
destination is documented at
site/content/docs/harnesses/<harness>.mdx.
Error handling
Install/update operations validate before writing, back up existing matching
targets before replacement, and merge only Apothem-managed child entries in
shared discovery directories. --dry-run executes the same validation and
returns skipped or unchanged outcomes without creating directories or files.
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| R1Cohort packaging contract
The stable, downstream-consumable contract for cohort packaging and plugin manifests — enumerate cohorts and resolve their per-harness native targets without re-deriving the mapping.
Self-contained runtime
How Apothem's engine runs from any checkout — vendored dependencies, the PYTHONPATH=src invocation model, and the plugin-tree bootstrap.