Architecture
Vue d'ensemble de l'architecture d'Apothem — le profil partagé, l'abstraction de l'adaptateur de harness et l'organisation de l'arborescence des sources.
Apothem s'articule autour d'une seule idée : un profil de gouvernance partagé, matérialisé dans le format de configuration natif de chaque environnement d'exécution d'assistant par un adaptateur propre à chaque harness. Cette section explique les pièces structurelles — le protocole de l'adaptateur, le schéma du profil, l'organisation de l'arborescence des sources et le flux d'installation qui les relie.
Vue d'ensemble du système
En un coup d'œil, Apothem est un seul pipeline : un unique profil partagé alimente le registre de harness, qui résout chaque adaptateur propre à un harness ; chaque adaptateur matérialise la surface de configuration native de son harness, et un contrôle de conformité permanent vérifie chaque surface matérialisée.
%% provenance: hand-authored %%
%% verified: 2026-06-23 %%
%% cross-reference: src/apothem/lib/harness_registry.py (runtime registry) + src/apothem/harnesses/ (adapter sub-packages) + src/apothem/conformity/ (conformity gate) %%
flowchart TD
accTitle: Apothem end-to-end materialization flow
accDescr: One shared profile feeds the harness registry, which resolves seventeen per-harness adapters; each adapter runs its install, uninstall, update, and verify lifecycle, with four single-file-config adapters also rendering a native config file through a materializer, and writes the harness's own native configuration surface. A standing conformity gate checks every materialized surface.
P["Shared profile<br/>~/.config/apothem/profile.yaml<br/>rules, skills, hooks, slash-commands, MCP servers"]
R["Harness registry<br/>authoritative at runtime<br/>(resolves every adapter)"]
A["17 per-harness adapters<br/>each: install / uninstall / update / verify<br/>+ materializer on 4 single-file-config adapters"]
N["Each harness's native config surface<br/>Claude Code settings.json, Cursor .mdc,<br/>Gemini GEMINI.md, Copilot instructions.md, …"]
G["Conformity gate<br/>pre-emission validators"]
P --> R
R --> A
A --> N
G -.->|standing check over every materialized surface| NPages
| Page | Description |
|---|---|
| Abstraction de l'adaptateur de harness | Le protocole HarnessAdapter — comment les adaptateurs traduisent le profil partagé en configuration native de la plateforme. |
| Schéma du profil partagé | Le profil YAML adossé à un schéma dans ~/.config/apothem/profile.yaml ou --profile PATH. |
| Organisation des sources | Pourquoi Apothem utilise une organisation src/ et comment l'arborescence est structurée. |
| Flux d'installation | Comment apothem install, update et uninstall fonctionnent de bout en bout. |
| Travailleurs délégués | Instructions à portée de dépôt pour les environnements d'exécution multi-travailleurs opérant dans ce dépôt. |
| Runtime autonome | Comment le moteur d'Apothem s'exécute depuis n'importe quel checkout — dépendances internalisées, le modèle d'invocation PYTHONPATH=src et le bootstrap de l'arbre du plugin. |
| Stratégie d'internalisation des dépendances | Quels paquets tiers Apothem internalise sous src/apothem/_vendor/, lesquels restent des prérequis système, et comment les copies internalisées sont rafraîchies. |
| Contrat d'empaquetage des cohortes | Le contrat stable, consommable en aval, pour l'empaquetage des cohortes et les manifestes de plugin — énumérer les cohortes et résoudre leurs cibles natives par environnement sans redériver la correspondance. |
| Diagramme du pipeline CI/CD | Carte visuelle et décomposition par couloirs des étapes du flux de travail de build, de test, de lint, de sécurité et de publication qui contrôlent chaque changement de code et chaque release. |