amenbo 2.0.0 — Plugins: Ihr eigenes Programm läuft, wenn sich eine Aufgabe bewegt
Installieren Sie ein Plugin, und es läuft, wenn mit einer Aufgabe etwas passiert. Teams können Plugins aus einem eigenen Katalog ausliefern. In der CLI ist `--actor` jetzt bei jedem Befehl Pflicht.
Ab diesem Release kann ein Programm, das Sie geschrieben haben, laufen, wenn mit einer Aufgabe etwas passiert. Auch am Aufruf der CLI hat sich eine Sache geändert, und Befehle, die bisher funktionierten, werden jetzt abgelehnt — lesen Sie „Beim Aktualisieren“, bevor Sie umsteigen.
Plugins
- Aufgabenereignisse rufen Ihr Programm auf — ein Plugin läuft, wenn eine Aufgabe abgeschlossen wird, wenn sich ihr Zustand ändert, wenn ein Kommentar dazukommt. Sie können eines auch selbst mit
amenbo plugin run <name>starten. - Aus dem Bildschirm „Markt“ installieren, oder von der Kommandozeile — suchen Sie sich im Bildschirm „Markt“ der Oberfläche eines aus dem offiziellen Katalog aus, oder führen Sie
amenbo plugin install <name>aus. Dort steht heute ein Eintrag:worktree, das je Aufgabe einen Git-Worktree abzweigt. - Installieren heißt nicht einschalten — das Einschalten ist ein eigener Schritt,
amenbo plugin enable <name>. Ob dieser Schalter pro Projekt oder pro Rechner gilt, entscheidet der Autor des Plugins. - Signatur und Prüfsumme werden geprüft, bevor irgendetwas landet — was sich nicht überprüfen lässt, wird nicht installiert.
- Ein Plugin ist einfach eine ausführbare Datei — schreiben Sie es in einer beliebigen Sprache. amenbo startet es als Kindprozess und reicht ihm JSON auf der Standardeingabe. Siehe Writing a plugin.
Was Sie lesen, einstellen und nachsehen können
- Eine Zeile öffnen und sehen, was Sie bekommen — das Detail sagt Ihnen schon vor der Installation, bei welchen Ereignissen das Plugin aufgerufen wird und was Sie danach einmal einstellen müssen.
- Einstellungen sind ein Formular — die Felder, die der Autor im Manifest erklärt, werden zum Formular. Geheime Felder sind verdeckt, und ein Projekt kann die Werte überschreiben, die es überschreiben muss.
amenbo plugin log— die letzten Läufe, mit ihrer Ausgabe und ihren Exit-Codes. Hier sehen Sie nach, wenn ein Plugin nicht getan hat, was Sie erwartet haben.
Plugins aus einem eigenen Katalog ausliefern
- Einen Katalog anmelden, und seine Plugins stehen neben den offiziellen —
amenbo plugin catalog add <URL der catalog.json> --name "Team catalog", und sie erscheinen in derselben Liste, bereit zur Installation. Hauseigene Plugins lassen sich verteilen, ohne durch den offiziellen Katalog zu gehen. - Ein Katalog sind drei statische Dateien — kein Serverprozess, der laufen müsste. Siehe Running a catalog.
- Der Signaturschlüssel wird beim Anmelden festgenagelt — beim Anmelden sehen Sie den Fingerabdruck des Schlüssels, den der Katalog veröffentlicht, und mit Ihrer Zustimmung ist er festgenagelt. Plugins aus diesem Katalog werden von da an mit diesem Schlüssel überprüft. Ein Katalog, dessen Schlüssel ausgetauscht wurde, wird abgelehnt; ein Katalog, der keinen Schlüssel veröffentlicht, lässt sich nur durchsehen.
- Jede Zeile trägt den Namen ihres Katalogs — und die Liste lässt sich nach Herkunft filtern. Das Kennzeichen „offiziell“ bekommen nur Einträge aus dem offiziellen Katalog: Ein fremder Katalog, der es für sich beansprucht, bekommt es nicht.
- Ein installiertes Plugin weiß, woher es kam — Aktualisierungen werden aus diesem Katalog geholt, derselbe Name in einem anderen Katalog wird also nie versehentlich aufgegriffen.
Außerdem in diesem Release
- Ein Entscheidungsprotokoll aus der Oberfläche ablehnen — schreiben Sie dort den Grund und lehnen Sie es ab. Dafür in die CLI zu wechseln ist nicht mehr nötig.
- Zwei Einstellungen, die nichts bewirkten, bewirken jetzt etwas —
default_view, die beim Start geöffnete Ansicht, unddate_locale, wie Daten geschrieben werden. - Eine Aufgabe schon beim Anlegen einordnen —
amenbo task add --dim <axis>=<value>.amenbo task showgibt die Einordnung der Aufgabe ebenfalls aus.
Beim Aktualisieren
--actorist jetzt bei jedem CLI-Befehl Pflicht, der den Datenspeicher anfasst — bisher wurde es aus der UmgebungsvariablenAMENBO_ACTORgefüllt, oder von einem Standardwert, wenn Sie nichts geschrieben haben. Ab diesem Release schreiben Sie es jedes Mal:--actor human, wenn Sie tippen,--actor ai, wenn eine KI tippt. Zum Beispielamenbo task list --actor human. Wenn Sie es über die Umgebungsvariable gesetzt hatten, holen Sie es an die Befehle heran. DieAGENTS.mdundCLAUDE.md, die amenbo ablegt, schreiben--actor aijetzt ebenfalls aus. In der Oberfläche ändert sich nichts.- Das gespeicherte Datenformat steigt — der erste Start in dieser Version migriert es, und ein Backup von vor der Migration wird automatisch aufbewahrt. Nach der Migration kann eine ältere Version es nicht mehr öffnen. Oberfläche und CLI werden vom selben Installer zusammen aktualisiert, lassen Sie also keines von beiden auf der alten Version stehen.
So bekommen Sie es
Öffnen Sie den Installer für Ihr Betriebssystem aus dem neuesten Release. Oberfläche und CLI kommen zusammen, und Adminrechte braucht es nicht.
- macOS —
.pkg, je einer für Apple Silicon und für Intel (beim ersten Öffnen erscheint eine Gatekeeper-Meldung: Rechtsklick → Öffnen) - Windows —
.exe-Setup - Linux —
.deb/.rpm
Zum Aktualisieren: In der Oberfläche wendet das Banner „Eine neuere Version ist verfügbar“ die Aktualisierung jetzt an Ort und Stelle an. Wenn Sie nur die CLI installiert haben, tauscht amenbo update --apply sie aus.
Neu hier? Siehe Loslegen.