type: architecture status: accepted last-reviewed: 2026-08-20 relates-to:
- docs/book/src/foundations/fnd-002-documentation-standards.md
Enregistrements de décisions architecturales
Les Architecture Decision Records (ADRs) constituent la trace pérenne des choix d’architecture qui contraignent les futurs travaux sur ZeroClaw. Ils sont plus courts que les RFC : chacun consigne le contexte, la décision, les conséquences et les sources qui justifient cette décision.
Les ADR acceptés sont immuables. Si l’architecture change, rédigez un nouveau ADR et marquez l’ancien comme supersédé plutôt que de réécrire l’historique.
ADRs actuels
| ADR | Statut | Décision |
|---|---|---|
| ADR-001 | accepté | Le runtime et les crates first-party de ZeroClaw sont implémentés en Rust. |
| ADR-002 | accepté | Les surfaces d’extension de première partie utilisent des contrats de trait explicites. |
| ADR-003 | remplacé par ADR-009 | Les plugins WASM utilisaient initialement Extism comme pont d’exécution. |
| ADR-004 | accepté | L’état partagé détenu par l’outil suit l’identité détenue par le démon, la propriété des handles, l’isolation et les règles de rechargement. |
| ADR-005 | accepté | Le stockage de la mémoire repose sur un contrat indépendant du backend, SQLite étant la valeur par défaut. |
| ADR-006 | proposé | Les plugins d’exécution sont la cible des canaux optionnels, avec des exceptions natives explicites basées sur les capacités lors de la migration. |
| ADR-007 | proposé | La passerelle devient un processus optionnel distinct via un contrat IPC local pris en charge. |
| ADR-008 | accepté | Le mode Goal utilise le plan de contrôle des tâches durables et le registre d’utilisation canonique. |
| ADR-009 | accepté | Les composants WIT et wasmtime direct remplacent le pont de plugins Extism. |
| ADR-010 | proposé | L’historique de session, la mémoire organisée et l’enrichissement ont des périmètres d’autorité distincts. |
| ADR-011 | accepté | Les agents configurés disposent de limites d’exécution explicites sous un même démon. |
| ADR-012 | proposé | L’application de configuration en direct utilise des générations canoniques et des résultats spécifiques à la cible. |
| ADR-013 | proposé | L’acquisition de la clé maîtresse utilise une seule autorité de source de clés configurée. |
| ADR-014 | proposé | L’accès réseau des plugins est géré par une seule autorité d’egress contrôlée par l’hôte. |
| ADR-015 | proposé | Le catalogue unifié des capacités est une projection en lecture seule des propriétaires de packages, de capacités, d’implémentations, de configurations et d’environnements d’exécution. |
| ADR-016 | proposé | L’extraction est la règle par défaut pour les sous-systèmes du crate holding ; les exceptions bornées sont consignées, délimitées et accordées par la Core Team. |
| ADR-017 | proposé | L’authentification entrante résout les identifiants en principaux canoniques et en autorisations de profil de permissions avant que les surfaces d’exécution privilégiées n’agissent. |
| ADR-018 | proposé | Le cadre de sécurité à l’exécution et de provenance repose sur des frontières de décision détenues par le runtime pour les actions protégées, l’admission des modèles, les tours internes et les preuves canoniques. |
ADR-006 et ADR-007 sont des décisions de feuille de route conditionnées par l’implémentation issues de FND-002. Leurs orientations cibles sont consignées, mais elles restent proposées jusqu’à la livraison des limites d’acceptation définies dans chaque enregistrement.
ADR-010 reste proposé jusqu’à ce que les critères d’acceptation du document soient satisfaits.
ADR-012 reste à l’état proposé jusqu’à ce que la publication de la configuration canonique, les résultats délimités par génération, ainsi que les consommateurs de live-apply liés à la sécurité et aux canaux satisfassent aux critères d’acceptation définis dans le document.
ADR-013 reste à l’état de proposition jusqu’à ce que la frontière canonique de la source de clés, la compatibilité sécurisée des fichiers, la sélection configurée en mode de refus par défaut et une source non basée sur un fichier prise en charge satisfassent aux conditions d’acceptation consignées dans l’enregistrement.
ADR-014 reste à l’état « proposé » tant que la frontière de transport de plugin appliquée, la déclaration de manifeste couverte par la signature, la cérémonie d’octroi par l’opérateur et le déploiement sur la flotte n’auront pas satisfait les critères d’acceptation consignés dans le registre.
ADR-015 reste à l’état de proposition jusqu’à ce que les projections de catalogue unifiées préservent les éléments probants de la source de vérité, la provenance des artefacts, les ponts de compatibilité et la règle selon laquelle la visibilité ne peut pas conférer de droits d’invocation.
ADR-016 reste à l’état proposé tant que le contrat de la crate de détention n’énonce pas la règle d’exception et ne comporte pas de tableau des exceptions actives, et qu’au moins une exception n’a pas été accordée ou refusée via le processus.
ADR-017 reste à l’état proposé tant que la résolution de l’identité canonique et des autorisations, la compatibilité native et des identifiants de pair (peer-credential), l’application RPC/WSS, l’intégration OIDC et de la passerelle, le stockage des sessions et de la mémoire privée appartenant au principal, la documentation de migration/reprise et les règles de propriété des origines internes n’auront pas satisfait les critères d’acceptation énoncés dans le registre.
ADR-018 reste à l’état proposé tant que le pipeline d’actions à l’exécution, l’enveloppe d’entrée et de provenance, la liaison de conversation au principal interne, la provenance des réponses pair, les résultats séparés, le chemin d’audit durable et les garde-fous d’implémentation n’ont pas satisfait les critères d’acceptation définis dans le registre.