Fichier beeuni.toml hérité

État de la prise en charge et procédure de migration de beeuni.toml v1 vers beeuni.yaml v2.

Cette page concerne le manifeste v1 (beeuni.toml, beeuni_version: 1). Pour consulter le manifeste actuel, voir Référence du manifeste.

État de la prise en charge

Beeuni prend toujours en charge les manifestes v1. La plateforme recherche le manifeste d’un projet dans cet ordre : beeuni.yaml, puis beeuni.yml, puis beeuni.toml. Le modèle de démarrage actuel crée un beeuni_version: 2 beeuni.yaml. Un projet v1 continue de fonctionner sans mise à niveau forcée.

La v1 accepte la syntaxe TOML ou YAML. La version 2 accepte uniquement YAML. Un manifeste v2 écrit en TOML échoue à la validation.

Migrer vers la v2

Créez beeuni.yaml à la racine du dépôt. Définissez beeuni_version: 2.

Convertissez [[agents]] en une map agents:, indexée par nom d’agent.

Renommez le champ env de chaque agent en secrets. Listez tous les secrets dont l’agent a besoin — la v2 n’accorde aucun secret par défaut.

Ajoutez default_agent en indiquant l’agent exécuté par défaut.

Supprimez [[channels]]. Reconnectez chaque canal depuis le tableau de bord.

Si vous utilisez [sandbox] ou [[sandboxes]], déplacez chaque définition d’image sous sandbox.templates.

Exécutez beeuni validate sur beeuni.yaml. Corrigez toutes les erreurs signalées.

Supprimez beeuni.toml.

Le comportement de l’agent — prompt système, model, mode, temperature et plus encore — ne change jamais d’emplacement. Il se trouve déjà dans le frontmatter .md de chaque agent, sous .beeuni/opencode/agents/, en v1 comme en v2. Voir Agents.

Vérifiez le résultat avec beeuni validate --file beeuni.yaml. Récupérez le schéma v2 complet avec beeuni schema --version 2. Consultez la Référence CLI pour ces deux commandes.

Principales différences

v1 (`beeuni_version: 1`)	v2 (`beeuni_version: 2`)	Modification
`[[agents]]` (tableau)	`agents:` (map indexée par nom)	Convertissez chaque élément du tableau en entrée de map.
`[[agents]].env`	`agents.<name>.secrets`	Renommé. La valeur par défaut passe de `all` à `none` — voir l’encadré ci-dessous.
`[[agents]].model`	supprimé	Inactif en v1 (analysé, jamais appliqué). Le comportement de l’agent provient toujours du frontmatter `.md` de l’agent.
`[[agents]].file`	`agents.<name>.file`	Inactif en v1 (analysé, jamais appliqué). En v2, indique le `.md` de l’agent.
aucun `default_agent`	`default_agent` (obligatoire)	Doit désigner un agent déclaré et activé.
`[[channels]]`	supprimé	Le routage des canaux est géré depuis le tableau de bord. Un canal connecté apparaît sous la forme d’une entrée `connectors:` avec `provider: channel`.
`[sandbox]` (singulier, clés d’image directement dessus)	`sandbox.templates` (liste)	Déplacez chaque image dans une entrée de modèle.
`[[sandboxes]]`	`sandbox.templates`	Renommé.

Certaines actions beeuni_permissions sont tolérées pour des raisons de compatibilité en v1 (project.session.exec, project.gateway.routing.edit, project.schedule.read, project.schedule.write, project.webhook.read, project.webhook.write, channel.read, channel.connect, channel.send, channel.disconnect) — la plateforme émet un avertissement, mais les autorise. Ces mêmes actions provoquent une erreur bloquante en v2. Supprimez-les de l’autorisation beeuni_permissions de tout agent avant la migration.