Chaque gestionnaire de tickets que vous avez utilise suit le meme schema. Il y a un service cloud. Il a une interface web. Quelqu'un construit un CLI qui communique avec l'API cloud. Le CLI est un citoyen de seconde classe : plus lent, moins capable, toujours une version d'API en retard.
Maintenant inversez cette architecture. Commencez par le CLI. Faites-le ecrire dans une base de donnees locale. Donnez a cette base un controle de version, avec la meme semantique de branches et de fusions que vous utilisez sur le code source. Puis placez une application desktop native par-dessus qui lit les memes fichiers de base de donnees directement, sans API entre les deux.
C'est ce que font beads et Beadbox. Et la raison pour laquelle cette architecture existe, ce sont les agents IA.
Le probleme : les agents ne cliquent pas sur des boutons
Si vous coordonnez une flotte d'agents IA (generateurs de code, reviewers, testeurs, deployeurs), vous avez besoin qu'ils creent des tickets, mettent a jour des statuts et lisent des files de travail. Ils ne peuvent pas s'authentifier sur Jira. Ils ne peuvent pas naviguer dans l'interface de Linear. Ils ont besoin d'un CLI qui ecrit dans une base de donnees locale, rapide, avec zero dependance reseau.
beads est ce CLI. C'est un gestionnaire de tickets open-source et Git-natif concu exactement pour ce workflow. La commande bd cree, met a jour, liste et ferme les tickets. Chaque ecriture atterrit dans une base de donnees Dolt locale a l'interieur du repertoire .beads/ de votre depot.
Les chiffres comptent ici. bd create prend environ 15ms. bd list sur 10 000 tickets repond en environ 200ms. Ces benchmarks proviennent de la suite de tests beads. Quand des agents traitent des elements de travail en boucle rapide, les millisecondes par operation determinent si votre gestionnaire de tickets suit le rythme ou devient le goulot d'etranglement.
Pourquoi Dolt et pas SQLite ?
Dolt est une base de donnees SQL qui implemente la semantique Git. Chaque ecriture est un commit. Vous avez dolt diff pour voir ce qui a change entre deux points. Vous avez dolt log pour l'historique d'audit complet. Vous avez dolt branch et dolt merge avec le meme modele mental que vous utilisez deja sur le code.
Pour le suivi de tickets, cela signifie que l'historique de votre projet a deux pistes d'audit paralleles : git log pour les changements de code, dolt log pour les changements de tickets. Vous pouvez repondre a des questions comme "a quoi ressemblait la base de tickets quand nous avons tague v2.1.0 ?" en faisant un checkout de ce point dans l'historique Dolt. Vous pouvez creer une branche de votre base de tickets pour experimenter une reorganisation, puis la fusionner ou l'abandonner.
beads a supprime le support SQLite en v0.9.0 et a tout mise sur Dolt. La semantique de controle de version n'est pas un bonus ; c'est la fondation. Quand vingt agents ecrivent dans la meme base de tickets, vous voulez pouvoir faire des diff, des branches et des merges sur ces donnees avec la meme confiance que vous avez dans votre controle de code source.
La collaboration optionnelle fonctionne via DoltHub. Poussez votre base de tickets vers un remote, vos coequipiers tirent. Meme workflow push/pull que Git, applique aux donnees structurees.
La couche visuelle : Beadbox
Les agents prosperent avec les CLIs. Les humains moins, du moins quand ils ont besoin de la vue d'ensemble. Graphes de dependances, arbres de progression d'epics, chaines de tickets bloques : ce sont des problemes spatiaux qu'un terminal ne peut pas bien rendre.
Beadbox est une application desktop native construite avec Tauri (pas Electron) qui lit le meme repertoire .beads/ dans lequel le CLI ecrit. Pas d'import, pas de synchronisation, pas de couche API. L'interface surveille le systeme de fichiers via fs.watch(), detecte les changements de la base Dolt et diffuse les mises a jour via un WebSocket local. Quand un agent lance bd update BEAD-42 --status in_progress, le badge de statut change dans Beadbox en quelques millisecondes.
Voici a quoi ressemble le workflow en pratique :
# Un agent cree un ticket
bd create --title "Migrate auth to OIDC" --type task --priority 1
# Un autre agent le revendique
bd update BEAD-42 --claim --actor agent-3
# Un humain ouvre Beadbox et voit le tableau complet :
# graphes de dependances, arbres d'epics, filtre par statut/priorite/responsable
# Aucune commande necessaire. Il suffit de regarder.
# L'agent termine et marque pour revue
bd update BEAD-42 --status ready_for_qa
# Beadbox se met a jour en temps reel. L'agent QA prend le relais.
Les agents ecrivent via le CLI. Les humains lisent via l'interface graphique. Les deux operent sur la meme base de donnees Dolt locale. Pas de reconciliation, pas de caches obsoletes, pas de "laissez-moi rafraichir."
Beadbox fonctionne sur macOS, Linux et Windows. Il supporte plusieurs workspaces, vous pouvez donc basculer entre les projets sans redemarrer.
Ce que "local-first" signifie vraiment
Le terme est suremploye. Voici ce qu'il signifie concretement pour beads et Beadbox :
Pas de compte. Vous ne vous inscrivez nulle part. Installez le CLI, installez l'application, pointez vers un repertoire. C'est tout.
Pas de dependance cloud. Tout tourne sur votre systeme de fichiers. Vos donnees ne quittent jamais votre machine sauf si vous faites explicitement dolt push vers un remote. Plus d'internet ? Rien ne change. Vous continuez a travailler.
Pas de serveur. Pas de daemon a gerer, pas de conteneur Docker a lancer. La base de donnees Dolt est un repertoire de fichiers. Le CLI lit et ecrit dans ces fichiers. Beadbox surveille ces fichiers.
Collaboration optionnelle. Quand vous souhaitez partager, poussez vers DoltHub. Vos coequipiers tirent. Les conflits de fusion sur les donnees de tickets se resolvent de la meme maniere que sur le code. Mais c'est opt-in, pas obligatoire.
Comparez avec les alternatives. Jira a besoin d'un serveur (ou d'Atlassian Cloud). Linear a besoin d'un compte et d'une connexion internet. GitHub Issues a besoin d'un depot sur les serveurs de GitHub. Meme les options auto-hebergees comme Gitea necessitent de faire tourner un service web.
beads a besoin d'un repertoire. Beadbox a besoin de ce meme repertoire et d'un double-clic.
Pour qui c'est fait
Si vous faites tourner des agents IA qui doivent se coordonner via une file de travail partagee, et que vous voulez que les humains surveillent et orientent ce travail visuellement, cette stack a ete construite pour votre workflow.
Si vous gerez des projets en solo et voulez un suivi de tickets versionne qui vit a cote de votre code, sans compte cloud, cette stack fonctionne aussi.
Si vous avez besoin du modele de permissions enterprise de Jira ou de l'edition collaborative en temps reel de Linear au sein d'une equipe distribuee, ce n'est pas le bon outil. beads est local-first par conception. C'est un compromis, pas un oubli.
Pour commencer
Installez le CLI beads depuis github.com/steveyegge/beads, puis installez Beadbox :
brew tap beadbox/cask && brew install --cask beadbox
Initialisez une base de donnees beads dans n'importe quel projet :
cd your-project
bd init
Ouvrez Beadbox, pointez vers le repertoire et vous regardez votre tableau de tickets. Pas d'inscription. Pas d'assistant de configuration. Pas de modale "connectez votre compte GitHub".
Beadbox est gratuit pendant la beta.