Crate

L’espace de travail est divisé en couches. Les crates de bordure communiquent avec le monde extérieur ; les crates de cœur orchestrent ; les crates de support fournissent des utilitaires. Chaque crate possède sa propre rustdoc, voir API (rustdoc).

Couche : Core

zeroclaw-runtime

La boucle d’agent, l’application de la politique de sécurité, le moteur SOP, le planificateur cron, le cycle de vie des SubAgent et la couche RPC pour zerocode. Dépend de tous les autres crates core et edge.

Sous-modules notables :

• agent/ : la boucle principale requête/réponse, le streaming, l’orchestration des appels d’outils
• security/ : types de politiques, détection de sandbox, OTP, arrêt d’urgence
• sop/ : moteur de procédures opérationnelles normalisées (voir SOP → Vue d’ensemble)
• subagent/ : création et cycle de vie des SubAgents (voir Délégation & SubAgents)
• cron/, daemon/, heartbeat/ : planification et gestion des processus de longue durée
• skills/ : compilation et exécution des compétences
• service/ : intégration systemd / launchctl / service Windows
• rpc/ : la couche RPC de zerocode

zeroclaw-config

Schéma TOML et sa validation. Gère :

• Niveau d’autonomie énuméré (ReadOnly / Supervised / Full)
• Magasin de secrets chiffrés (fichier de clé local)
• Résolution de l’espace de travail (variables d’environnement, chemins Homebrew, XDG, détection de conteneur)
• Versionnement des schémas et migration

Toutes les clés de configuration visibles par l’utilisateur sont documentées dans Référence → Config, qui est générée à partir de ce crate.

zeroclaw-api

L’ABI du noyau. Définit les traits publics fondamentaux, notamment :

• ModelProvider : interface client LLM avec indicateurs de capacité de streaming
• Channel : surface de messagerie entrante/sortante
• Tool : capacités invocables par un agent
• Memory : stockage et récupération des conversations
• Observer : collecteur typé pour les métriques/l’observabilité

L’exécution ne dépend que de ces traits, et non des implémentations concrètes. C’est ce qui permet d’ajouter des fournisseurs, des canaux ou des outils en implémentant un trait plutôt qu’en modifiant le noyau.

Couche : Arête

zeroclaw-providers

Toutes les implémentations de clients LLM ainsi que les wrappers de routage et de réessai. Voir Fournisseurs de modèles → Vue d’ensemble pour la liste.

Structure :

• traits.rs : réexportations depuis zeroclaw-api plus des assistants internes au fournisseur
• anthropic.rs, openai.rs, ollama.rs, … : un fichier par fournisseur natif
• compatible.rs : une implémentation unique compatible OpenAI réutilisée par plus de 20 fournisseurs (Groq, Mistral, xAI, Venice, etc.)
• router.rs : sélection de route de modèle par appel basée sur des hints
• reliable.rs : nouvelle tentative / temporisation / délai d’attente et wrapper de repli ordonné entre fournisseurs de modèles
• streaming.rs : analyse SSE, estimation des tokens, deltas d’appels d’outils

zeroclaw-channels

Plus de 30 intégrations de messagerie. Consultez Channels → Vue d’ensemble pour le catalogue.

Tous les canaux implémentent le trait Channel de zeroclaw-api. Chacun est conditionné par une fonctionnalité (feature-gated), une compilation minimale n’inclut que les canaux que vous compilez.

Le sous-module orchestrator/ gère le streaming des messages, les mises à jour des brouillons, les divisions en plusieurs messages et le serveur ACP.

zeroclaw-gateway

Passerelle HTTP/WebSocket. Expose l’exécution via :

• API REST (gestion des sessions, de la mémoire, du statut et des tâches cron)
• WebSocket pour les réponses en streaming
• Tableau de bord Web (actifs statiques + authentification)
• Points de terminaison des webhooks (entrants provenant des canaux qui envoient des données)

L’appairage est requis par défaut ; [gateway.allow_public_bind = true] permet la liaison à 0.0.0.0.

zeroclaw-tools

Outils appelables que l’agent invoque. À ne pas confondre avec les sous-commandes CLI zeroclaw.

Comprend : browser, http_request, web_search, shell, file_read, file_write, sondes matérielles (hardware_board_info, hardware_memory_read), et plus. Voir Outils → Vue d’ensemble.

Chaque outil est enregistré via une fabrique et décrit au modèle à l’aide de chaînes de caractères localisées via Fluent.

Couche : Prise en charge

zeroclaw-memory

Mémoire de conversation et récupération. SQLite est le backend par défaut ; PostgreSQL est disponible via --features memory-postgres pour les déploiements multi-instances nécessitant un magasin partagé avec écritures concurrentes. Optionnel :

• Backends d’intégration (OpenAI, Ollama, local)
• Récupération de vecteurs sur les conversations stockées (pgvector lorsque vous utilisez PostgreSQL)
• Consolidation de la mémoire (résumés, extraction de faits)

zeroclaw-tool-call-parser

Analyse de la syntaxe des appels d’outils côté modèle. Gère les variations entre les fournisseurs :

• JSON tool_calls au format OpenAI
• Blocs <tool_use> de style Anthropic
• Formats d’appel de fonction de Qwen/Ollama
• Deltas de streaming des appels d’outils natifs

zeroclaw-plugins

Hôte de plugins WASM sandboxé : charge des plugins du modèle de composants (tool, channel, memory, skill bundles) en processus sous WASI avec des limites de fuel et de mémoire par appel. Voir Développement → Protocole des plugins.

zeroclaw-hardware

Abstraction matérielle : GPIO, I2C, SPI, USB. Conditionné par la plateforme. Voir Matériel → Vue d’ensemble.

zeroclaw-log

La surface d’émission unique pour chaque événement de journalisation dans l’espace de travail. Possède le schéma JSONL sur disque (LogEvent), le registre d’attribution lié aux alias (ATTRIBUTION_FIELDS + COMPOSITE_PREFIXES), la Layer tracing-subscriber qui capture chaque appel tracing::*, les macros record! et scope!, le writer à élagage roulant, le lecteur à curseur paginé derrière /api/logs, et la passerelle vers l’Observer typé pour les consommateurs Prometheus / OTel. Voir architecture/logging.md.

zeroclaw-spawn

Le wrapper sanctionné autour de tokio::spawn. Fournit la macro spawn!, qui instrumente chaque tâche d’arrière-plan avec le span d’attribution courant de l’appelant, de sorte qu’un record! émis à l’intérieur du future lancé hérite des agent_alias / channel / session_key du parent. Les sites d’appel utilisent spawn! au lieu de tokio::spawn directement.

zeroclaw-infra

Support au niveau processus : debouncers, watchdogs, le backend de session SQLite. Pas une couche de tracing/métriques, c’est zeroclaw-log. Voir État d’exécution et persistance pour les limites de propriété d’état et de durabilité concernant la config, les sessions, la mémoire, les logs, les coûts, le cron et les métadonnées de la gateway.

zeroclaw-macros

Générer des macros pour le schéma de configuration, l’enregistrement des outils et l’enregistrement des canaux. Réduit le code répétitif dans l’ensemble de l’espace de travail.

zerocode

Interface utilisateur en terminal, construite comme une application séparée sous apps/zerocode/. C’est un membre de workspace à part entière sans dépendance à une crate zeroclaw-* (voir Docs & Translations → zerocode strings pour son catalogue i18n indépendant).

Drapeaux de fonctionnalité

La feuille de route du micro-noyau (RFC #5574) définit une taxonomie des indicateurs de fonctionnalité. Pour l’utilisateur, cela se traduit concrètement par :

• default : une build de base raisonnable
• ci-all : tout activé, pour la CI
• channel-<name> : activation par canal (p. ex. channel-matrix, channel-discord)
• hardware : activer le sous-système matériel
• gateway, acp-bridge, whatsapp-web : groupes de capacités à activation explicite

Les providers ne sont pas conditionnés par des feature flags ; ils sont tous compilés. La sélection du canal est le principal paramètre par build. Consultez la table [features] du Cargo.toml de premier niveau pour la liste complète.