Installations-Workflow
Wie apothem install, update und uninstall durchgängig funktionieren.
Installationsablauf
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]Aktualisierungsablauf
Bei apothem update --harness X:
- Lädt und validiert
~/.config/apothem/profile.yamloder--profile PATH. - Löst den ausgewählten Harness oder
allüber die zentrale Registry auf. - Validiert den vollständigen Materialisierungsplan vor dem ersten Schreibvorgang.
- Ruft
Adapter.update(profile, project=...)auf. - Meldet die Ergebnisse erstellt, aktualisiert, unverändert, übersprungen, Warnung und Fehler.
Deinstallationsablauf
Bei apothem uninstall --harness X:
- Ruft
Adapter.uninstall()auf. - Der Adapter entfernt nur die Dateien, die er geschrieben hat; das gemeinsame Profil-YAML und nicht zugehörige, vom Operator verfasste Dateien bleiben unberührt.
- Das Memory, die Kontexte und die Lernspeicher des gemeinsamen
Arbeitsverzeichnisses werden gesichert und entfernt, wenn dies der letzte
dort installierte Harness ist. Sie werden an dem Ort entfernt, den die
Installation vermerkt hat. Das Verzeichnis
plans/wird nie entfernt.
Geltungsbereich-Auflösung
Jeder Adapter schreibt in seine eigene feste Installationswurzel: das
Benutzer-Home für Adapter mit Benutzergeltungsbereich und der projektlokale Pfad
für Adapter mit Projektgeltungsbereich. Die CLI stellt kein --scope-Flag bereit;
Adapter mit Projektgeltungsbereich erfordern --project <path>. Sieben der
Adapter mit Projektgeltungsbereich schreiben außerdem gemeinsame Ordner im
Home-Verzeichnis, etwa ~/.agents/skills/ und ~/.config/apothem/, bevor sie
die Projektdatei schreiben, und --project ändert nicht, wohin diese gehen. Die
Install-Referenz
listet sie auf. Jedes Ziel ist unter site/content/docs/harnesses/<harness>.mdx dokumentiert.
Fehlerbehandlung
Installations-/Aktualisierungsvorgänge validieren vor dem Schreiben, sichern
vorhandene passende Ziele vor dem Ersetzen und führen in gemeinsamen
Discovery-Verzeichnissen nur von Apothem verwaltete Untereinträge zusammen.
--dry-run führt dieselbe Validierung aus und gibt das Ergebnis zurück, das
jeder Schreibvorgang gehabt hätte, etwa created oder updated, ohne
Verzeichnisse oder Dateien anzulegen.
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| R1Vertrag zur Kohorten-Paketierung
Der stabile, nachgelagert nutzbare Vertrag für die Kohorten-Paketierung und Plugin-Manifeste — Kohorten aufzählen und ihre harness-spezifischen nativen Ziele auflösen, ohne die Zuordnung neu abzuleiten.
Eigenständige Laufzeit
Wie Apothems Engine aus jedem Checkout läuft — gevendorte Abhängigkeiten, das Aufrufmodell PYTHONPATH=src und der Bootstrap des Plugin-Baums.