amenbo 2.0.0 — les plugins : votre programme s'exécute quand une tâche bouge
Installez un plugin et il s'exécute quand il arrive quelque chose à une tâche. Les équipes peuvent servir leurs plugins depuis leur propre catalogue. Dans la CLI, `--actor` est désormais obligatoire sur chaque commande.
À partir de cette version, un programme que vous avez écrit peut s’exécuter quand il arrive quelque chose à une tâche. Une chose change aussi dans la façon d’appeler la CLI, et des commandes qui marchaient jusqu’ici seront refusées — lisez « Sur la mise à jour » avant de passer à cette version.
Les plugins
- Les événements d’une tâche appellent votre programme — un plugin s’exécute quand une tâche est terminée, quand son état change, quand un commentaire est ajouté. Vous pouvez aussi en lancer un vous-même avec
amenbo plugin run <name>. - Installer depuis l’écran Marché, ou depuis la ligne de commande — choisissez-en un dans le catalogue officiel sur l’écran « Marché » de l’interface, ou lancez
amenbo plugin install <name>. Il y a une entrée à ce jour :worktree, qui découpe un worktree git par tâche. - Installer n’est pas activer — l’activation est une étape à part,
amenbo plugin enable <name>. Que cet interrupteur soit par projet ou par machine, c’est l’auteur du plugin qui le décide. - Signature et somme de contrôle sont vérifiées avant que quoi que ce soit ne se pose — ce qui ne peut pas être vérifié n’est pas installé.
- Un plugin, c’est juste un exécutable — écrivez-le dans le langage que vous voulez. amenbo le lance comme processus enfant et lui passe du JSON sur l’entrée standard. Voyez Écrire un plugin.
Ce que vous pouvez lire, régler et vérifier
- Ouvrez une ligne et voyez ce que vous prenez — le détail vous dit quels événements appellent le plugin et ce qu’il faudra régler une fois installé, avant que vous l’installiez.
- Les réglages sont un formulaire — les champs déclarés par l’auteur dans le manifeste deviennent le formulaire. Les champs secrets sont masqués, et un projet peut redéfinir les valeurs dont il a besoin.
amenbo plugin log— les exécutions récentes, avec leur sortie et leur code de retour. C’est ici qu’on regarde quand un plugin n’a pas fait ce que vous attendiez.
Servir des plugins depuis votre propre catalogue
- Enregistrez un catalogue et ses plugins se rangent à côté des officiels —
amenbo plugin catalog add <URL of catalog.json> --name "Team catalog", et ils apparaissent dans la même liste, prêts à installer. Les plugins internes peuvent être distribués sans passer par le catalogue officiel. - Un catalogue, c’est trois fichiers statiques — aucun serveur à faire tourner. Voyez Tenir un catalogue.
- La clé de signature est épinglée à l’enregistrement — l’enregistrement vous montre l’empreinte de la clé publiée par le catalogue, et l’accepter l’épingle. Les plugins installés depuis ce catalogue sont vérifiés avec cette clé à partir de là. Un catalogue dont la clé a été changée est refusé ; un catalogue qui ne publie aucune clé ne peut être que parcouru.
- Chaque ligne porte le nom de son catalogue — et la liste se filtre par source. La marque « officiel » n’est donnée qu’aux entrées du catalogue officiel : un catalogue tiers qui se la donne à lui-même ne l’obtient pas.
- Un plugin installé se souvient d’où il vient — ses mises à jour sont prises dans ce catalogue-là, si bien que le même nom dans un autre catalogue n’est jamais ramassé par erreur.
Aussi dans cette version
- Rejeter un enregistrement de décision depuis l’interface — écrivez la raison et rejetez-le sur place. Plus besoin de passer à la CLI pour ça.
- Deux réglages qui n’avaient aucun effet en ont un —
default_view, la vue ouverte au lancement, etdate_locale, la façon d’écrire les dates. - Classer une tâche à sa création —
amenbo task add --dim <axis>=<value>.amenbo task showaffiche aussi le classement de la tâche.
Sur la mise à jour
--actorest désormais obligatoire sur chaque commande CLI qui touche à l’espace de données — il était rempli depuis la variable d’environnementAMENBO_ACTOR, ou par une valeur par défaut quand vous n’écriviez rien. À partir de cette version, vous l’écrivez à chaque fois :--actor humanquand c’est vous qui tapez,--actor aiquand c’est une IA. Par exemple,amenbo task list --actor human. Si vous le posiez par la variable d’environnement, déplacez-le sur les commandes. LesAGENTS.mdetCLAUDE.mdque dépose amenbo écrivent maintenant--actor ainoir sur blanc, eux aussi. Rien ne change dans l’interface.- Le format des données stockées monte d’un cran — le premier lancement sur cette version le migre, et une sauvegarde d’avant la migration est gardée automatiquement. Une fois migré, une version antérieure ne peut plus l’ouvrir. L’interface et la CLI sont mises à jour ensemble par le même programme d’installation : ne laissez donc pas l’une des deux sur l’ancienne version.
Se le procurer
Ouvrez le programme d’installation de votre système depuis la dernière version. L’interface et la CLI viennent ensemble, et aucun droit d’administrateur n’est nécessaire.
- macOS —
.pkg, un pour Apple silicon et un pour Intel (la première ouverture affiche une alerte Gatekeeper : clic droit → Ouvrir) - Windows —
.exed’installation - Linux —
.deb/.rpm
Pour mettre à jour : dans l’interface, la bannière « une version plus récente est disponible » l’applique désormais sur place. Si vous n’avez installé que la CLI, amenbo update --apply la remplace.
Vous débutez ? Voyez Démarrer.