Chaque issue tracker que vous avez utilisé suit le même schéma. Il y a un service cloud. Il a une interface web. Quelqu'un construit un CLI qui parle à 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 écrire dans une base de données locale. Faites en sorte que la base soit versionnée, avec la même sémantique de branching et merging que vous utilisez sur le code source. Puis posez une app de bureau native par-dessus qui lit les mêmes fichiers de base de données 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 problème : les agents ne peuvent pas cliquer sur des boutons

Si vous coordonnez une flotte d'agents IA (générateurs de code, relecteurs, testeurs, déployeurs), vous avez besoin qu'ils créent des issues, mettent à jour des statuts et lisent des files d'attente 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 écrit dans une base de données locale, rapidement, avec zéro dépendance réseau.

beads est ce CLI. C'est un issue tracker open-source, Git-native, conçu exactement pour ce workflow. La commande bd crée, met à jour, liste et ferme des issues. Chaque écriture atterrit dans une base de données locale Dolt à l'intérieur du répertoire .beads/ de votre dépôt.

Les chiffres comptent ici. bd create prend environ 15 ms. bd list sur 10 000 issues retourne en environ 200 ms. Ces benchmarks proviennent de la suite de tests beads. Quand les agents traitent des items de travail en boucles serrées, les millisecondes par opération déterminent si votre issue tracker suit le rythme ou devient le goulot d'étranglement.

Pourquoi Dolt, pas SQLite ?

Dolt est une base de données SQL qui implémente la sémantique Git. Chaque écriture est un commit. Vous obtenez dolt diff pour voir ce qui a changé entre deux points. Vous obtenez dolt log pour l'historique d'audit complet. Vous obtenez dolt branch et dolt merge avec le même modèle mental que vous utilisez déjà sur le code.

Pour le suivi d'issues, cela signifie que l'historique de votre projet a deux pistes d'audit parallèles : git log pour les changements de code, dolt log pour les changements d'issues. Vous pouvez répondre à des questions comme « à quoi ressemblait la base d'issues quand on a tagué v2.1.0 ? » en faisant checkout de ce point dans l'historique Dolt. Vous pouvez brancher votre base d'issues pour expérimenter une réorganisation, puis la merger ou la jeter.

beads a supprimé le support SQLite en v0.9.0 et a tout misé sur Dolt. La sémantique de contrôle de version n'est pas un bonus ; c'est le fondement. Quand vingt agents écrivent dans la même base d'issues, vous voulez pouvoir faire diff, branch et merge de ces données avec la même confiance que vous avez dans votre contrôle de code source.

La collaboration optionnelle fonctionne via DoltHub. Poussez votre base d'issues vers un distant, vos collègues tirent. Le même workflow push/pull que Git, appliqué aux données structurées.

La couche visuelle : Beadbox

Les agents prospèrent avec les CLIs. Les humains non, du moins pas quand ils ont besoin de la vue d'ensemble. Graphes de dépendances, arbres de progression d'épiques, chaînes d'issues bloqués : ce sont des problèmes spatiaux qu'un terminal ne peut pas bien rendre.

Beadbox est une application de bureau native construite avec Tauri (pas Electron) qui lit le même répertoire .beads/ dans lequel le CLI écrit. Pas d'étape d'import, pas de processus de synchronisation, pas de couche API. La GUI surveille le système de fichiers via fs.watch(), détecte les changements de la base Dolt et diffuse les mises à jour par un WebSocket local. Quand un agent exécute bd update BEAD-42 --status in_progress, le badge de statut change dans Beadbox en quelques millisecondes.

Voici à quoi ressemble le workflow en pratique :

# Un agent crée un issue
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 dépendances, arbres épiques, filtres par statut/priorité/assigné
# Pas de commandes. Juste regarder.

# L'agent termine et le marque pour revue
bd update BEAD-42 --status ready_for_qa

# Beadbox se met à jour en temps réel. L'agent QA le prend.

Les agents écrivent via le CLI. Les humains lisent via la GUI. Les deux opèrent sur la même base Dolt locale. Pas de réconciliation, pas de caches périmés, pas de « laissez-moi rafraîchir. »

Beadbox tourne sur macOS, Linux et Windows. Il supporte plusieurs workspaces, vous pouvez donc changer de projet sans redémarrer.

Ce que « local-first » signifie vraiment

Le terme est galvaudé. Voici ce qu'il signifie concrètement pour beads et Beadbox :

Pas de compte. Vous ne vous inscrivez à rien. Installez le CLI, installez l'app, pointez-la vers un répertoire. C'est fait.

Pas de dépendance cloud. Tout tourne sur votre système de fichiers. Vos données ne quittent jamais votre machine à moins que vous ne fassiez explicitement dolt push vers un distant. Internet tombe ? Rien ne change. Vous continuez à travailler.

Pas de serveur. Il n'y a pas de démon à gérer, pas de conteneur Docker à lancer. La base Dolt est un répertoire de fichiers. Le CLI lit et écrit ces fichiers. Beadbox surveille ces fichiers.

Collaboration optionnelle. Quand vous voulez partager, poussez vers DoltHub. Vos collègues tirent. Les conflits de merge sur les données d'issues se résolvent comme sur le code. Mais c'est opt-in, pas obligatoire.

Comparez avec les alternatives. Jira a besoin d'un serveur (ou Atlassian Cloud). Linear a besoin d'un compte et d'une connexion internet. GitHub Issues a besoin d'un dépôt sur les serveurs de GitHub. Même les options auto-hébergées comme Gitea nécessitent de faire tourner un service web.

beads a besoin d'un répertoire. Beadbox a besoin de ce même répertoire et d'un double-clic.

Pour qui c'est fait

Si vous faites tourner des agents IA qui doivent se coordonner via une file d'attente de travail partagée, et que vous voulez que les humains surveillent et pilotent ce travail visuellement, ce stack a été construit pour votre workflow.

Si vous gérez des projets en solo et voulez un suivi d'issues versionné qui vit à côté de votre code, sans compte cloud, ce stack fonctionne aussi.

Si vous avez besoin du modèle de permissions enterprise de Jira ou de l'édition collaborative en temps réel de Linear à travers une équipe distribuée, ce n'est pas le bon outil. beads est local-first par conception. C'est un compromis, pas un oubli.

Démarrer

Installez le CLI beads depuis github.com/steveyegge/beads, puis installez Beadbox :

brew tap beadbox/cask && brew install --cask beadbox

Initialisez une base beads dans n'importe quel projet :

cd your-project
bd init

Ouvrez Beadbox, pointez-le vers le répertoire, et vous regardez votre tableau d'issues. Pas d'inscription. Pas d'assistant de configuration. Pas de modale « connectez votre compte GitHub. »

Beadbox est gratuit pendant la bêta.