# Référence du manifeste Toutes les clés de beeuni.yaml v2, avec leurs valeurs par défaut, leurs limites et leurs règles de validation. Canonical page: https://beeuni.ai/docs/fr/project/manifest Le manifeste est le fichier que la plateforme considère comme faisant autorité pour un projet. Cette page répertorie chaque clé `beeuni.yaml` (v2), son type, sa valeur par défaut et la façon dont la plateforme la valide. Pour une version en langage courant, consultez [Votre projet](/docs/fr/project). ## Deux surfaces de configuration Un projet Beeuni comporte deux surfaces de configuration aux responsabilités strictement distinctes. - **Configuration Beeuni** — `beeuni.yaml` à la racine du dépôt définit l’environnement du projet, les agents, les outils, les connecteurs et les déclencheurs. Les modèles de sandbox peuvent référencer un Dockerfile personnalisé. - **Configuration de l’agent** — les fichiers d’agent, les compétences et les fichiers du harnais. Le harnais de l’agent la lit, dans la sandbox comme en local. | Chemin | Contenu | | --- | --- | | `beeuni.yaml` | Le manifeste : les agents et les éléments auxquels chacun peut accéder, les déclencheurs, les connecteurs, l’environnement et les modèles de sandbox. | | `agents/.md` | Un agent : frontmatter et invite système. `agents..file` le désigne. | | `skills//SKILL.md` | Une compétence. Tous les harnais la chargent. | | `memory/` | La mémoire du projet. | | `tools/.ts` | Les outils du projet, un module par outil. `tools:` les déclare ; tous les harnais les exécutent. Consultez [Outils](/docs/fr/project/tools). | | `harnesses/opencode/` | Les fichiers lus uniquement par harness standard : `opencode.jsonc`, `plugins/`, `tools/`, `commands/`. `opencode.config_dir` pointe ici. | Les projets créés avant 2026-09 conservent leurs agents et compétences dans `.beeuni/opencode/` et leur mémoire dans `.beeuni/memory/`. Beeuni lit les deux structures. Le lien entre ces deux parties est le fichier `.md` de l’agent. Une clé du manifeste `agents.` régit le fichier désigné par `agents..file`, ou `agents/.md` si `file` est omis. Tous les champs comportementaux figurent uniquement dans le frontmatter et le corps de ce fichier `.md`, jamais dans `beeuni.yaml` : - invite système - `model`, `mode` - `temperature`, `top_p` - `steps`, `permission` Le bloc `agents:` du manifeste définit uniquement la gouvernance : quels agents peuvent être lancés et à quoi chacun peut accéder. Le validateur l’impose. Il rejette tout bloc d’agent v2 contenant un champ comportemental et affiche une erreur indiquant le fichier `.md` de l’agent concerné. ## Emplacement et versions Tout dépôt dont la racine contient un manifeste valide est un projet Beeuni. `beeuni.yaml` (v2, YAML uniquement) est le format actuel pour les nouveaux projets, créés par le flux Web « Create project » et par `beeuni init`. `beeuni.toml` (v1) fonctionne toujours pour les projets existants, mais la plateforme n’y accepte aucune nouvelle fonctionnalité v2. Consultez [TOML hérité](/docs/fr/project/legacy-toml) pour le schéma v1 et les étapes de migration de v1 vers v2. `beeuni_version: 2` exige le format YAML : un fichier `.toml` qui déclare `beeuni_version: 2` échoue à la validation. Tout manifeste déclarant une version supérieure à `2` est rejeté, afin que la plateforme n’interprète jamais silencieusement un champ futur de travers. Les clés de premier niveau inconnues sont ignorées ; vous pouvez donc y ajouter vos propres métadonnées. `validateManifest()` est le contrôle unique utilisé par `beeuni ship`, la vérification de fusion des demandes de modification et `beeuni validate`. Les mêmes règles s’appliquent partout ; tout ce qui est fusionné dans `main` est donc structurellement valide. Le schéma est public et généré à partir du même paquet : - [`beeuni.v2.schema.json`](/schema/beeuni.v2.schema.json) - [`beeuni.v1.schema.json`](/schema/beeuni.v1.schema.json) - [`beeuni.schema.json`](/schema/beeuni.schema.json) (effectue la sélection selon `beeuni_version`) Pointez un `beeuni.yaml` vers le schéma v2 pour valider dans l’éditeur, ou récupérez-le depuis la CLI : ```yaml # yaml-language-server: $schema=https://beeuni.ai/schema/beeuni.v2.schema.json beeuni_version: 2 ``` ```bash beeuni schema --version 2 ``` ## Exemple complet ```yaml beeuni_version: 2 default_agent: beeuni project: name: my-project description: What this project is. env: required: [DATABASE_URL] optional: [STRIPE_API_KEY, WEBHOOK_SLACK_SECRET] sandbox: templates: - slug: ml name: ML Development dockerfile: Dockerfile.ml cpu: 4 memory: 16 opencode: config_dir: harnesses/opencode agents: beeuni: file: agents/beeuni.md connectors: all secrets: all beeuni_permissions: all skills: all release-bot: file: agents/release-bot.md sandbox: ml connectors: [github] beeuni_permissions: [project.gitops.push] secrets: [GITHUB_AGENT_TOKEN] triggers: - slug: daily-digest type: cron agent: beeuni cron: '0 0 9 * * 1-5' timezone: America/Los_Angeles prompt: | Summarize yesterday's commits. Open a CR against main. ``` ## Clés de premier niveau | Clé | Obligatoire | Remarques | | --------------------------------------------------- | -------- | ------------------------------------------------------------------------------------------ | | `beeuni_version` | oui | doit être `2` | | `default_agent` | oui | doit désigner un agent déclaré et activé | | `imports` | non | autres fichiers YAML ou répertoires dont `triggers`, `connectors`, `agents`, `apps` et `tools` sont fusionnés dans ce manifeste. Consultez [`imports:`](#imports) | | `tools` | non | les outils attribués à chaque session : nom de l’outil → chemin du module relatif au dépôt, ou `beeuni:` pour un outil Beeuni. Avec une clé `tools`, les sessions ne reçoivent que les outils Beeuni qu’elle énumère. Tous les harnais les exécutent. Consultez [`tools:`](#tools) | | `runtime` | non | `"opencode"` (valeur par défaut) ou `"pi"` — le harnais de l’agent qu’une session démarre dans sa sandbox ; `pi` exécute harness expérimental en processus dans le démon de sandbox et lit les mêmes fichiers `.md` de l’agent et ses compétences. L’indicateur de fonctionnalité `pi_harness` du projet sélectionne harness expérimental sans cette ligne. harness expérimental nécessite l’indicateur `llm_gateway` ; sans lui, la session démarre harness standard. | | `harnesses.pi.packages` | non | les paquets harness expérimental chargés par les sessions harness expérimental du projet. Consultez [`harnesses:`](#harnesses) | | `pi.config_dir` | non | `harnesses/pi`, puis `.beeuni/pi` s’il est présent. `settings.json`, `extensions/`, `skills/` et `prompts/` propres à harness expérimental. | | `project.name` / `project.description` | non | métadonnées d’affichage ; la plateforme ne lit pas `project.name` pour déterminer le nom affiché du projet | | `env.required` / `env.optional` | non | noms de variables d’environnement ; `required` est fourni à titre indicatif uniquement et n’est jamais imposé au démarrage d’une session | | `sandbox` / `sandbox.templates` / `sandbox.default` | non | image(s) de sandbox et matériel | | `opencode.config_dir` | non | valeur par défaut `harnesses/opencode`, puis `.beeuni/opencode` hérité | | `triggers` | non | liste de déclencheurs cron, webhook et de surveillance | | `connectors` | non | liste des définitions de connecteurs | | `policy.default_mode` | non | `allow_all` (valeur par défaut) ou `risk` ; mode d’approbation des connecteurs à l’échelle du projet | | `agents` | oui | table de gouvernance associant les noms aux blocs ; ne doit pas être vide. Avec `imports`, cette table peut se trouver dans un fichier importé | ## `imports:` Répartissez un manifeste entre plusieurs fichiers YAML. Utilisez cette option lorsque `beeuni.yaml` dépasse une page : 30 déclencheurs avec des invites sur plusieurs lignes, un connecteur par équipe, un fichier par groupe d’agents. ```yaml # beeuni.yaml beeuni_version: 2 default_agent: beeuni imports: - triggers/ # a directory: every .yaml and .yml file below it - agents.yaml # a single file agents: beeuni: connectors: all ``` ```text beeuni.yaml agents.yaml triggers/ reports/ weekly.yaml monthly.yaml dockets/ freedom-forever.yaml ``` ```yaml # triggers/reports/weekly.yaml triggers: - slug: weekly-report name: Cross-Sector Weekly Report type: cron agent: galileo cron: "0 15 * * 0" prompt: |- Build the weekly report. ``` Le fichier racine et ses imports forment une configuration de projet. Un déclencheur dans un fichier peut désigner un agent déclaré dans un autre. **Règles** 1. Un chemin est relatif à la racine du dépôt. `..`, les chemins absolus et les motifs glob sont refusés. 2. Un import de répertoire inclut tous les fichiers `.yaml` et `.yml` qu’il contient, quelle que soit leur profondeur, triés par chemin. Les autres fichiers sont ignorés. 3. Un fichier importé déclare `triggers`, `connectors`, `agents`, `apps`, `tools` et `imports`. Toutes les autres clés (`beeuni_version`, `default_agent`, `runtime`, `project`, `env`, `opencode`, `sandbox`, `policy`, `policies`) restent dans le fichier racine. Un fichier importé qui en définit une échoue à la validation. 4. Un fichier importé peut en importer d’autres. La limite est de 8 niveaux et de 200 fichiers. Une boucle constitue une erreur. Un fichier atteint plusieurs fois n’est fusionné qu’une seule fois. 5. Un nom, un fichier. Si un slug de déclencheur, un slug de connecteur, un nom d’agent, de app ou d’outil est déclaré dans deux fichiers, une erreur nommant les deux fichiers est signalée. Aucun remplacement n’est effectué silencieusement. 6. Les entrées sont fusionnées dans l’ordre : le fichier importateur d’abord, puis ses imports dans l’ordre indiqué. Un import incorrect invalide l’ensemble du manifeste, tout comme une erreur de syntaxe YAML. `beeuni validate`, `beeuni ship` et la vérification de fusion de la demande de modification le signalent avant qu’il n’atteigne `main` : ```text imports: triggers "weekly-report" is declared in both triggers/a.yaml and triggers/b.yaml — one name, one file ``` **Les modifications sont apportées au fichier qui déclare l’entrée.** Lorsque le tableau de bord, l’API ou `beeuni triggers enable|disable|rm` modifie un déclencheur, un connecteur, un agent ou une app déclaré par un fichier importé, seul ce fichier est écrit. Le fichier racine n’est pas réécrit. Une nouvelle entrée est écrite dans le fichier racine. Déplacez-la manuellement dans un fichier importé si vous le souhaitez. `imports` exige `beeuni.yaml`. Un manifeste `beeuni.toml` ignore cette clé. ## `tools:` Les outils attribués à une session, par nom. Une valeur peut prendre l’une de ces deux formes : | Forme | Signification | | --- | --- | | `beeuni:` | Un outil Beeuni (`web_search`, `image_search`, `scrape_webpage`, `memory`, `show`), géré par Beeuni. La clé doit être ``. | | Chemin de module relatif au dépôt | Un outil propre au projet, dans n’importe quel dossier. Sous un nom d’outil Beeuni, le module remplace l’outil Beeuni. | ```yaml tools: web_search: beeuni:web_search image_search: beeuni:image_search scrape_webpage: beeuni:scrape_webpage memory: tools/memory.ts # replaces the Beeuni memory tool lookup_order: tools/lookup_order.ts crm_note: integrations/crm/note.ts ``` harness standard et harness expérimental exécutent le même module. Le contrat du module, `beeuni tools ls`, `beeuni tools eject` et la migration depuis `harnesses/opencode/tools/` sont décrits dans [Outils](/docs/fr/project/tools). **Règle de sélection.** - Aucune clé `tools`, dans le fichier racine ou dans un fichier importé : les sessions disposent des cinq outils Beeuni. Tous les projets créés avant l’existence de cette liste les conservent. - Une clé `tools`, même vide (`tools: {}` ou `tools:` avec toutes les lignes supprimées) : les sessions disposent uniquement des outils Beeuni qu’elle répertorie, sous la forme `beeuni:` ou d’un chemin de module. Une clé `tools` dans un fichier importé est également prise en compte. Supprimez une ligne `beeuni:` pour retirer cet outil de tous les agents. Utilisez [`agents..tools`](/docs/fr/project/tools#who-may-use-which-tool) pour limiter cela à un seul agent. **Erreurs.** - Un nom doit être en snake_case : `^[a-z][a-z0-9_]{0,63}$`. - Un nom d’outil du harnais (`bash`, `read`, `write`, `edit`, `apply_patch`, `glob`, `grep`, `list`, `task`, `question`, `todowrite`, `webfetch`, `websearch`, `skill`, `lsp`, `invalid`, `execute`, `plan_exit`, `pty_*`) constitue une erreur. - Un chemin se termine par `.ts`, `.js`, `.mts`, `.mjs`, `.cts` ou `.cjs`. Il ne doit pas commencer par `/` ou `-`, ni contenir de segment `.` ou `..`. - `beeuni:` sous une autre clé constitue une erreur. Sous un nom d’outil Beeuni, par exemple `web_search: beeuni:image_search` : ```text tools.web_search : doit être `beeuni:web_search` (l’outil Beeuni) ou un chemin relatif au dépôt vers un module .ts ou .js (par ex. `tools/web_search.ts`) qui le remplace. ``` - `beeuni:` pour un nom qui n’est pas celui d’un outil Beeuni, par exemple `web_serch: beeuni:web_serch` : ```text tools.web_serch : doit être un chemin relatif au dépôt vers un module .ts ou .js (par ex. `tools/web_serch.ts`). `beeuni:` désigne un outil Beeuni sous son propre nom : `web_search: beeuni:web_search`, `image_search: beeuni:image_search`, `scrape_webpage: beeuni:scrape_webpage`, `memory: beeuni:memory`, `show: beeuni:show`. ``` - `beeuni validate` signale également un module déclaré qui n’existe pas. Une valeur `beeuni:` ne nécessite aucun fichier. **Avertissements.** Un avertissement n’invalide jamais `beeuni validate`. - Une clé `tools` qui ne répertorie aucun des cinq outils Beeuni : ```text tools : les sessions de ce projet ne disposent d’aucun outil Beeuni (web_search, image_search, scrape_webpage, memory, show). Ajoutez `: beeuni:` pour en conserver un. ``` Cela permet de détecter un projet qui ajoute son premier outil personnalisé et supprime les cinq outils par erreur. - Le `tools` d’un agent qui nomme un outil Beeuni que le projet ne charge pas : ```text agents.beeuni.tools : « show » est un outil Beeuni que ce projet ne charge pas : ajoutez `show: beeuni:show` sous la clé `tools` de premier niveau, ou supprimez-le ici. ``` ## `project:` Métadonnées facultatives destinées aux personnes : `name` et `description`. La plateforme ne lit pas cette table — le nom affiché d’un projet provient de son propre enregistrement dans la base de données. Considérez-la comme de la documentation pour les personnes qui consultent le dépôt. ## `env:` Déclare les noms des variables d’environnement dont vos sessions ont besoin. Les valeurs se trouvent sur la page Variables d’environnement du tableau de bord, jamais directement dans le manifeste. La plateforme les déchiffre et les injecte en tant que variables d’environnement simples au démarrage de la session. ```yaml env: required: [DATABASE_URL] optional: [STRIPE_API_KEY] ``` | Champ | Type | Remarques | | ---------- | ---------- | -------------------------------------------------------------------------------------------------------- | | `required` | `string[]` | À titre indicatif. Le tableau de bord demande ces valeurs à l’utilisateur, mais le démarrage de la session n’est pas bloqué si une valeur manque. | | `optional` | `string[]` | Disponibles pour les sessions si elles sont définies. Leur absence ne pose pas de problème. | Les noms des variables d’environnement doivent respecter `^[A-Z_][A-Z0-9_]*$`. Secrets Manager limite les noms à 64 caractères : un nom plus long est analysé ici, mais ne peut jamais recevoir de valeur. Il en va de même pour les noms commençant par `BEEUNI_`. Limitez les noms à 64 caractères et évitez le préfixe `BEEUNI_`. Spécification complète : [Secrets](/docs/fr/project/secrets). ## `sandbox:` et `sandbox.templates` Une liste d’images de sandbox nommées et amorçables. Facultative — sans entrée, chaque session démarre avec l’image par défaut de la plateforme. Chaque modèle doit définir exactement l’un de ces éléments : `dockerfile` (relatif au dépôt) ou `image` (une référence Docker publique, épinglée à un tag ou à un digest). ```yaml sandbox: templates: - slug: ml name: ML Development dockerfile: Dockerfile.ml cpu: 4 memory: 16 disk: 50 ``` | Champ | Type | Par défaut | Notes | | ------------ | ------ | ------------------- | --------------------------------------------------------------------------------- | | `slug` | string | — | Obligatoire. Unique par projet. `default` est réservé. | | `name` | string | slug | Libellé affiché dans le sélecteur du tableau de bord. | | `dockerfile` | string | — | Chemin relatif au dépôt. Mutuellement exclusif avec `image`. | | `image` | string | — | Image Docker publique, avec tag ou digest fixé. Mutuellement exclusif avec `dockerfile`. | | `entrypoint` | string | propre à la couche d’exécution | Remplace le point d’entrée du conteneur. | | `cpu` | int | valeur par défaut du fournisseur | Cœurs vCPU. Limite : 1–32. | | `memory` | int | valeur par défaut du fournisseur | RAM en Gio. Limite : 1–128. | | `disk` | int | valeur par défaut du fournisseur | Disque en Gio. Limite : 1–500. | | `container_runtime` | bool | `false` | Exécuter Docker dans le bac à sable avec une mise en réseau bridge + overlay. Voir [Runtime](/docs/fr/work/runtime#docker-in-the-sandbox). | Chaque valeur doit être un entier positif. Une valeur inférieure au minimum échoue à la validation et génère une erreur. Une valeur supérieure au maximum passe avec un avertissement, puis est ramenée à la limite à l’exécution. Les GPU ne sont pas pris en charge — déclarer `gpu` génère un avertissement, pas une erreur. Consultez [Runtime](/docs/fr/work/runtime) pour savoir ce que la couche d’exécution ajoute à votre image. ### `sandbox.default` Définissez `default` sur `sandbox` pour faire d’un modèle le modèle par défaut de tout le projet. Toutes les sessions, tous les déclencheurs et tous les canaux le démarrent alors sans avoir à préciser de slug. ```yaml sandbox: default: dev templates: - slug: dev dockerfile: Dockerfile.dev ``` `default` doit désigner un modèle déclaré dans ce manifeste, ou la valeur réservée `"default"` pour l’image de la plateforme. Un agent peut sélectionner son environnement avec `agents..sandbox`. La valeur doit désigner un modèle du manifeste ou du tableau de bord, ou `"default"`. ```yaml agents: researcher: sandbox: ml ``` La résolution du modèle de session suit cet ordre : 1. `sandbox_slug` de session explicite. 2. `sandbox` de l’agent sélectionné. 3. `sandbox.default` du projet. 4. `"default"` de la plateforme. Les déclencheurs cron, les déclencheurs webhook, les planifications et les canaux utilisent le modèle de l’agent sélectionné. Une modification de spécification (`cpu`, `memory`, `disk`, `container_runtime` ou l’image elle-même) reconstruit l’instantané du projet. La nouvelle taille s’applique à la session suivante, pas à une session en cours. ## `opencode:` Emplacement du répertoire de configuration harness standard. Facultatif, avec une valeur par défaut. ```yaml opencode: config_dir: harnesses/opencode ``` | Champ | Type | Par défaut | Notes | | ------------ | ------ | ----------------------------------------------- | ------------------------ | | `config_dir` | string | `harnesses/opencode`, puis `.beeuni/opencode` | Répertoire relatif au dépôt. | Si `config_dir` n’est pas défini, Beeuni utilise le premier de `harnesses/opencode` et `.beeuni/opencode` qui contient un `opencode.json` ou un `opencode.jsonc`. Ce répertoire contient les fichiers lus uniquement par harness standard : `opencode.jsonc`, `plugins/`, `tools/` et `commands/`. Les agents et les compétences se trouvent à la racine du dépôt, dans `agents/` et `skills/`. `opencode.jsonc` reste le registre natif d’harness standard pour les plugins, les serveurs MCP, les fournisseurs et les autorisations — ne dupliquez pas ces paramètres dans le manifeste. Voir [Agents](/docs/fr/project/agents). ## `harnesses:` Paramètres propres à chaque moteur. `pi.config_dir` pointe vers un répertoire de configuration natif de harness expérimental relatif au dépôt (par défaut : `harnesses/pi`, puis `.beeuni/pi`). Le répertoire est importé au démarrage de harness expérimental. `pi.packages` est distinct : il installe des paquets à partir de `harnesses.pi.packages` du manifeste, par agent. Il existe aujourd’hui une clé de paquet : `pi.packages`, les paquets harness expérimental chargés par chaque session harness expérimental de ce projet (`runtime: pi` ou l’indicateur `pi_harness`). Un paquet peut être n’importe quel élément de packages : extensions (outils, hooks, commandes), ainsi que les compétences et les prompts fournis avec un paquet. ```yaml runtime: pi harnesses: pi: packages: - npm:pi-web-access@0.30.0 # pinned extension version - source: npm:pi-mcp-adapter@2.36.0 extensions: ["extensions/*.ts"] # load only these files of the package skills: [] # load none of its skills - ./harnesses/pi/audit.ts # an extension file in this repository ``` | Forme de l’entrée | Signification | | --- | --- | | `npm:@` | Paquet npm à une version précise. Une plage de versions ou l’absence de version échoue à la validation. | | `./` | Fichier d’extension ou répertoire de paquet dans ce dépôt. Il ne peut pas sortir du dépôt avec `..`. | | `{ source, extensions, skills, prompts, themes }` | Même source, avec les filtres d’inclusion et d’exclusion propres à harness expérimental. Si aucun filtre n’est indiqué, tout est chargé ; `[]` ne charge rien. | 20 entrées maximum. Les sources Git sont refusées. ### Par agent Un agent peut ajouter ses propres paquets et en retirer de la liste de premier niveau, sous `agents..harnesses` : ```yaml harnesses: pi: packages: [npm:pi-web-access@0.30.0] # every agent agents: researcher: harnesses: pi: packages: [npm:@juicesharp/rpiv-todo@2.11.0] # researcher only reviewer: harnesses: pi: exclude: [pi-web-access] # reviewer loads no web tools ``` - Les paquets d’un agent correspondent à la liste de premier niveau, moins son `exclude`, plus son propre `packages`. - Pour un agent, une entrée qui concerne un paquet également répertorié au premier niveau remplace l’entrée de premier niveau (autre version ou autres filtres). - `exclude` répertorie les noms de paquets (`pi-web-access`, `@scope/name`) ou les chemins `./` tels qu’ils sont indiqués dans la liste de premier niveau. Il ne prend jamais de version. - Chaque liste de paquets distincte est construite une seule fois. Les agents qui partagent la même liste partagent la même compilation. - Les paquets dépendent de l’agent avec lequel une session démarre. Un sous-agent démarré par un autre agent à l’aide de l’outil `task` utilise uniquement les outils d’espace de travail standard (`bash`, `read`, `write`, `edit`, `glob`, `grep`), pas ses propres paquets ni ceux de son agent parent ; les hooks d’extension du parent s’appliquent toujours à ses appels. Démarrez une session avec cet agent pour utiliser ses paquets. Comment les paquets sont mis à disposition d’une session : 1. La fusion de la demande de modification qui édite cette liste construit les paquets une seule fois, pour la plateforme du bac à sable, avec les scripts d’installation désactivés. Chaque extension est précompilée dans un fichier minifié. La compilation conserve les autres fichiers du paquet, sauf le code déjà inclus dans ce fichier, les déclarations de types, les source maps, ainsi que les fichiers README et CHANGELOG à la racine. Les projets qui ont la même liste partagent la compilation. 2. Une nouvelle session ou une session redémarrée télécharge la compilation pendant le clonage de son dépôt, puis charge directement chaque extension. Une session n’exécute jamais `npm install` et ne compile jamais de paquet. 3. Un paquet qui ne peut pas être précompilé (par exemple, si son `pi.extensions` utilise des globs) fonctionne quand même : la session le charge depuis les paquets installés, ce qui prend plus de temps. Si le code d’un paquet lit l’un des fichiers exclus de la compilation, ajoutez un filtre `extensions` à son entrée : la session le chargera également depuis les paquets installés. 4. Une session qui démarre avant que la compilation soit disponible démarre sans les paquets du projet et lance la compilation ; la session suivante les aura. Beeuni installe également un ensemble de paquets système dans chaque session harness expérimental. Une entrée de projet pour le même paquet remplace la version système. Un dépôt peut aussi contenir des extensions natives de harness expérimental dans `.pi/extensions/*.ts` ; harness expérimental les charge sans entrée de manifeste. Les extensions s’exécutent sans interface de terminal : les outils, hooks et commandes fonctionnent ; les widgets réservés au terminal ne font rien. ## `triggers:` Liste des définitions cron, webhook et de surveillance. Chaque entrée déclenche une session qui exécute `prompt` comme premier message. ```yaml triggers: - slug: daily-digest type: cron cron: '0 0 9 * * 1-5' prompt: Summarize yesterday's commits. ``` | Champ | Obligatoire | Valeur par défaut | Remarques | | -------------- | --------------------- | --------------------- | ----------------------------------------------------------------------------------------------------- | | `slug` | oui | — | `[a-z0-9][a-z0-9_-]{0,127}`, unique parmi les déclencheurs. | | `type` | oui | — | `cron`, `webhook` ou `monitor` (expérimental). | | `prompt` | oui | — | Non vide. Prend en charge la création de modèles. | | `name` | non | slug | Libellé lisible. | | `agent` | non | `default_agent` | Doit désigner une clé de `agents:`. Omettez-le pour utiliser `default_agent` ; n’écrivez pas la valeur littérale `default`. | | `enabled` | non | `true` | `false` ignore l’entrée. | | `model` | non | résolu au déclenchement | Format filaire `provider/model`. Fige le modèle de la session déclenchée. Voir [Modèles](/docs/fr/project/models). | | `session_mode` | non | `fresh` | `fresh`, `reuse`, `pinned` ou `keyed`. | | `session_id` | obligatoire pour `pinned` | — | Session exacte à laquelle envoyer un nouveau prompt. | Les déclencheurs Cron nécessitent exactement l’un de `cron` (une expression à 6 champs) ou `run_at` (un horodatage ISO-8601 ponctuel), ainsi que `timezone`, un nom IANA. Les déclencheurs Webhook nécessitent `secret_env`, le nom d’un secret qui utilise la livraison `broker` avec le consommateur `connector`. Les déclencheurs Monitor nécessitent `run` (une commande relative au dépôt) et `mode` (`poll` ou `stream`), et rejettent tous les champs Cron et Webhook. Pour la référence complète des champs, la configuration des identifiants, la création de modèles de charge utile, les points de terminaison et la stratégie de session, voir [Déclencheurs](/docs/fr/connect/triggers). ## `connectors:` Une liste d’outils externes qu’un agent peut appeler. La définition se trouve dans git ; les identifiants se trouvent sur la plateforme, jamais dans le manifeste. Voir [Connecteurs](/docs/fr/connect/connectors) pour le modèle conceptuel. ```yaml connectors: - slug: gmail-read name: Gmail read only provider: pipedream app: gmail authorization_strategy: user policies: - match: search_email action: always_run ``` | Champ | Obligatoire | Remarques | | ------------------------ | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `slug` | oui | `[a-z0-9][a-z0-9_-]{0,127}`, unique parmi les connecteurs. | | `provider` | oui | `pipedream`, `mcp`, `openapi`, `postman`, `graphql`, `http` ou `channel`. | | `name` | non | Nom affiché. Par défaut, le slug. | | `authorization_strategy` | non | `project` ou `user`. Par défaut, `project` si omis. Une stratégie de projet utilise les connexions actives du projet. Une stratégie utilisateur utilise uniquement la connexion du membre qui agit. | | `enabled` | non | Par défaut, `true`. | | `credential` | non | Seul `shared` est pris en charge. Le mode `per_user`, désormais obsolète, provoque une erreur bloquante. | | `sensitive` | non | Par défaut, `false`. `true` fait de `require_approval` la valeur par défaut pour les actions non correspondantes, y compris les lectures. Les règles explicites du projet et du connecteur sont toujours résolues en premier. | Champs spécifiques au fournisseur : | Fournisseur | Champ obligatoire | Remarques | | ----------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | `pipedream` | `app` | `account` facultatif, valeur par défaut : slug. | | `mcp` | `url` | `transport` : `http` (par défaut) ou `sse`. | | `openapi` | `spec` | Une URL ou un chemin relatif au dépôt. | | `postman` | `spec` | Une URL ou un chemin vers une Collection JSON, un manifeste `.postman/api` ou une URL d’espace de travail Postman. | | `graphql` | `endpoint` | `spec` facultatif (SDL). | | `http` | `base_url` | `spec` facultatif. | | `channel` | `platform` | `slack`, `teams`, `email` ou `voice`. | | `computer` | — | Géré par l’API. Vous ne pouvez pas le déclarer manuellement. Chaque ordinateur connecté correspond à l’un de ses comptes. Voir [Ordinateurs](/docs/fr/connect/computers). | Les connecteurs `channel` nécessitent rarement une entrée rédigée à la main : la connexion d’un canal depuis le tableau de bord en crée une automatiquement. Voir [Slack et canaux](/docs/fr/connect/slack). Les slugs `beeuni_slack`, `beeuni_teams`, `beeuni_email` et `computer` sont réservés à la plateforme ; leur utilisation avec un autre fournisseur provoque une erreur de validation. Le connecteur `computer` est créé lorsque le premier membre connecte un ordinateur, car les identifiants des machines sont des identités du plan de contrôle du compte et ne doivent pas figurer dans le manifeste. `connectors.auth` : facultatif, pour les fournisseurs autres que `pipedream`. `type` est `bearer`, `basic`, `custom`, `api_key`, `oauth1`, `hmac`, `aws_sigv4`, `mtls` ou `none` (par défaut). `oauth1` est réservé aux fournisseurs `openapi`, `postman` et `http`. `in` est `header` (par défaut), `query` ou `cookie`. `name` est obligatoire lorsque `type` vaut `custom` ou `api_key`. `connectors.policies` : une liste de paires `{match, action}`. `match` est un motif glob appliqué aux noms d’outils. `action` vaut `always_run`, `require_approval` ou `block`. Les politiques sont associées au connecteur. Toutes les connexions de ce connecteur utilisent les mêmes politiques. `policy.default_mode` : une clé de premier niveau, distincte de `connectors:`, qui définit le mode d’approbation des connecteurs à l’échelle du projet. Elle accepte `allow_all` (par défaut ; tous les outils sans correspondance s’exécutent) ou `risk` (approbation requise pour les appels sans correspondance qui modifient ou détruisent des données). Définissez-la avec `beeuni connectors policy set --default ` — voir [CLI](/docs/fr/cli). ## Canaux La v2 supprime `channels:` du schéma. Le routage des canaux vers les agents (Slack, Microsoft Teams, e-mail et voix actuellement) relève de l’état opérationnel en direct, et non d’une configuration déclarative. Vous le définissez depuis la page Channels du tableau de bord ou à l’aide de commandes de chat ; cette séparation permet aussi de garder les identifiants hors de git. La connexion d’un canal crée toujours une entrée `connectors` avec `provider: channel` que l’agent peut appeler. Voir [Slack et canaux](/docs/fr/connect/slack). La table `[[channels]]` de la v1 est présentée dans [Ancien format TOML](/docs/fr/project/legacy-toml). ## `agents:` Une table de correspondance entre noms et blocs, indexée par nom d’agent. Cette table sert uniquement à la gouvernance : elle définit ce qu’un agent peut utiliser, jamais ce qu’il dit ou fait. Ce bloc constitue **la deuxième des deux liaisons** : un principal obtient ses rôles de Beeuni, et un agent reçoit en plus les autorisations Beeuni déclarées ici. Une session ne peut faire que ce que les deux autorisent. Voir [Un vocabulaire, deux liaisons](/docs/fr/accounts#one-vocabulary-two-bindings). ```yaml default_agent: beeuni agents: beeuni: file: agents/beeuni.md connectors: all secrets: all beeuni_permissions: all skills: all release-bot: file: agents/release-bot.md connectors: [github] connectors_required: [github] beeuni_permissions: [project.gitops.push] secrets: [GITHUB_AGENT_TOKEN] ``` | Champ | Valeur par défaut | Notes | | --------------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | _(clé de la table)_ | — | `[a-z0-9][a-z0-9_-]{0,127}`, unique au projet. Sans `file`, c’est aussi le nom de fichier `.md`. | | `file` | `agents/.md` | Chemin relatif au dépôt vers le `.md` de l’agent. Voir [Le fichier de l’agent](#the-agent-file). | | `enabled` | `true` | `false` considère l’agent comme non déclaré — la plateforme ne le lancera pas. | | `connectors` | `none` | Slugs de connecteurs que cet agent peut appeler. `all` signifie tous les connecteurs. | | `connectors_required` | `none` | Obsolète : analysé et ignoré. Le démarrage du bac à sable n’est plus conditionné par la présence d’un connecteur ; un appel à un connecteur sans connexion renvoie `connector_not_connected` avec un lien de connexion. Doit toujours être un sous-ensemble de `connectors` lorsqu’il est présent. | | `secrets` | `none` | Secrets du projet transmis à cet agent sous forme de variables d’environnement du bac à sable. Renommé depuis `env` dans la v1. | | `beeuni_permissions` | `none` | Autorisations Beeuni (actions du projet) que cet agent peut exercer via la CLI, l’API ou git. `all` signifie toutes les autorisations du projet, toujours limitées par le rôle maximal de l’agent et sans jamais inclure les autorisations réservées aux humains. `beeuni_cli` est l’ancienne orthographe, toujours acceptée avec un avertissement de validation ; définir les deux avec des valeurs différentes constitue une erreur. | | `skills` | `none` | Compétences que cet agent peut charger. | | `apps` | `none` | Slugs d’applications Beeuni que cet agent peut ouvrir lorsque l’application est `restricted` ou `private`. `all` signifie toutes les applications du projet. Voir [Agents et applications](/docs/fr/feature-flags/apps#agents-and-apps). | | `tools` | `all` | Outils que cet agent peut utiliser : outils du harnais, de Beeuni et du projet. `all`, `none`, une liste (uniquement ceux-ci) ou `{ exclude: [...] }` (tous sauf ceux-ci). L’ancienne forme de table `{ bash: false }` fonctionne toujours. Contrairement aux autorisations ci-dessus, si `tools` est omis, tous les outils sont autorisés. Voir [Qui peut utiliser quel outil](/docs/fr/project/tools#who-may-use-which-tool). | | `repository_access` | `true` | Indique si les nouvelles sessions reçoivent le dépôt du projet. `false` désactive la remise du dépôt et l’accès à celui-ci via les identifiants de session. Les sessions existantes conservent la politique enregistrée. | La v2 applique le refus par défaut : si `connectors`, `secrets`, `beeuni_permissions`, `skills` ou `apps` est omis pour un agent déclaré, sa valeur devient `none`. Accordez explicitement à chaque agent toutes les autorisations dont il a besoin, comme le fait l’agent `beeuni` du modèle de démarrage ci-dessus. Un projet qui migre depuis la v1 doit réaccorder manuellement toutes les autorisations : dans la v1, `env` (secrets) prend la valeur `all` lorsqu’il est omis, soit l’inverse de la v2. `connectors_personal` reste un alias d’entrée obsolète pour `connectors_required`. Les nouveaux manifestes doivent utiliser `connectors_required`. Le paramètre `authorization_strategy` du connecteur détermine si l’autorisation appartient au projet ou au membre. Les autorisations `beeuni_permissions` proviennent d’un ensemble fixe d’autorisations limitées au projet (`project.read`, `project.gitops.push`, `project.gitops.merge`, `project.gitops.ref.any`, `project.trigger.*`, `project.secret.*`, `project.connector.*`, et plus encore). Les autorisations limitées au compte — `member.*`, `billing.*`, `project.create` — ne peuvent jamais être accordées à un agent. Exécutez `beeuni validate --scopes` depuis une session pour afficher la liste actuelle des autorisations pouvant être accordées. ### Le fichier de l’agent `agents..file` indique le `.md` de l’agent, relatif à la racine du dépôt. ```yaml agents: support: file: agents/support.md ``` - Le chemin doit se terminer par `.md`. - Le chemin ne doit pas commencer par `/` ou `-`. Il ne doit contenir aucun segment `.` ou `..`, ni aucun segment vide. - Chaque segment ne peut contenir que des lettres, des chiffres, `_`, `-`, `.` et des espaces. - Si `file` est omis, Beeuni lit `agents/.md`, puis `.beeuni/opencode/agents/.md`. Lorsque `opencode.config_dir` est défini, le second chemin est `/agents/.md`. - Lorsque le tableau de bord enregistre un agent doté de `.md`, il écrit `file` avec ce chemin. - L’API refuse toute requête qui modifie `file` (`400`, code `invalid_config`). Pour déplacer un agent, déplacez son `.md` et mettez à jour `file` dans `beeuni.yaml` au sein du même commit. `beeuni validate` et la vérification de fusion de la demande de modification rejettent tout `file` invalide avec une erreur sur `agents..file`. ## Quand les modifications de configuration prennent effet - Une modification du manifeste, `agents/`, `skills/` ou du répertoire de configuration harness standard ne s’applique qu’après la fusion d’une demande de modification dans `main`. Les sessions et les déclencheurs lisent la branche par défaut, et non les branches de session. - Une modification du cron ou du webhook d’un déclencheur est prise en compte par le planificateur quelques secondes après la fusion. - Une modification de l’image sandbox ou du matériel reconstruit l’instantané. La nouvelle spécification s’applique à la prochaine session, pas à la session en cours. - Une modification de la valeur d’un secret dans le tableau de bord est prise en compte lors de la création du sandbox. Elle s’applique à la prochaine session, pas à une session en cours. ## Règles de conversion aller-retour Les modifications effectuées dans le tableau de bord correspondent à une opération de lecture-modification-écriture sur le fichier qui déclare l’entrée : `beeuni.yaml`, ou un [fichier importé](#imports). Pour que les différences restent propres entre les modifications dans l’interface et celles effectuées pendant une session : 1. Gardez `beeuni_version` comme première clé. 2. Dans une entrée de déclencheur, ordonnez les champs ainsi : `slug`, `name`, `type`, `agent`, `enabled`, puis les champs propres au type, et enfin `prompt`. 3. Si vous ajoutez un déclencheur webhook avant que son secret soit défini, indiquez le nom du secret dans `env.optional`. Laissez le déclencheur `enabled: false` jusqu’à ce que la valeur soit renseignée. ### Accès au dépôt Définissez `agents..repository_access` sur `false` pour les agents qui n’ont pas besoin des fichiers source du projet. Ils peuvent tout de même créer des fichiers sandbox et utiliser les outils, secrets et connecteurs qui leur sont accordés. Définissez-le sur `true` pour les agents qui ont besoin du dépôt. Les autorisations Git restent distinctes. Modifiez ce paramètre dans l’éditeur d’agent, sous **Workspace → Project repository access**. Le paramètre s’applique aux nouvelles sessions. Les sessions existantes conservent la politique qui leur a été enregistrée, y compris après le remplacement du runtime. ```yaml agents: support: repository_access: false engineer: repository_access: true ``` Le champ obsolète `workspace` reste lisible : `branch` signifie `true`, et `runtime` signifie `false`. Les configurations `read` héritées continuent de rejeter la création de sessions tant que vous n’avez pas remplacé ce champ par une valeur booléenne explicite. Il n’existe pas de mode de dépôt en lecture seule. Les champs anciens et nouveaux en conflit sont rejetés. L’éditeur et le SDK envoient `repository_access`. Lorsque l’accès est désactivé, l’API stocke également `workspace: runtime` comme valeur miroir de compatibilité. Cela préserve la restriction pour les anciennes répliques de l’API pendant un déploiement ou un retour à une version précédente. Les lectures de l’API omettent cette valeur miroir. Les manifestes rédigés à la main qui utilisent uniquement `repository_access` nécessitent la version mise à jour de l’API.