Vous créez une épique avec 15 sous-tâches. Vous les répartissez entre une poignée d'agents ou de coéquipiers. Deux jours plus tard, quelqu'un demande : "Ou en est la réécriture de l'auth ?"
Vous lancez bd show bb-r4f. Ca vous donne l'épique elle-même. Titre, description, priorité. Ca ne vous dit pas combien d'enfants sont terminés. Alors vous lancez bd list --parent bb-r4f. Vous obtenez une liste plate d'IDs et de titres. Pour voir le statut de chacun, vous passez par jq ou lancez bd show sur chaque enfant individuellement. Certains de ces enfants ont leurs propres sous-tâches. Vous voila trois niveaux de profondeur, en train de reconstituer un arbre dans votre tête a partir de la sortie du terminal.
Ca fonctionne quand une épique a trois enfants. Ca s'effondre a dix. Et si vous coordonnez des agents IA qui créent des sous-tâches, signalent des blocages et ferment des tickets en succession rapide, la sortie CLI devient obsolète entre le moment ou vous lancez la commande et le moment ou vous finissez de la lire.
Le problème n'est pas beads. Le CLI beads est excellent pour la gestion structurée et scriptable de tickets. Le problème est que la progression hiérarchique est un concept visuel, et les terminaux rendent du texte en lignes.
A quoi ressemble un arbre d'épique dans Beadbox
Ouvrez Beadbox, cliquez sur une épique, et vous voyez ses enfants dans un arbre dépliable. Chaque enfant affiche un badge de statut (open, in_progress, ready_for_qa, closed), un indicateur de priorité et l'assigné. L'épique elle-même affiche une barre de progression : "9 sur 14 terminés (64%)." Ce nombre se met a jour quand les enfants se ferment.
Dépliez un enfant qui est lui-même une épique et vous voyez ses sous-tâches imbriquées en dessous. La progression du parent agrège tous les descendants, pas seulement les enfants directs. Une épique a trois niveaux avec 40 tickets au total entre ingénierie, QA et documentation vous montre le vrai pourcentage de complétion en haut, comptant chaque noeud feuille de l'arbre.
Les tickets bloqués recoivent un traitement visuel distinct. Si bb-m3q dépend de bb-k7p et que bb-k7p est encore ouvert, le badge bloqué apparaît a côté du statut de bb-m3q. Pas besoin de lancer bd dep list pour découvrir le goulot d'étranglement. C'est visible dans l'arbre, au niveau ou ca compte.
Comparez avec le workflow CLI. Pour répondre a "qu'est-ce qui bloque la progression de l'épique auth", vous lanceriez :
bd list --parent bb-r4f --status=open --json | \
jq -r '.[].id' | \
xargs -I{} bd show {} --json 2>/dev/null | \
jq -r 'select(.blocked_by | length > 0) | "\(.id) blocked by \(.blocked_by | join(", "))"'
C'est un pipeline parfaitement valide. Il retourne la bonne réponse. Mais vous devez l'écrire, vous rappeler des flags, et le relancer a chaque fois que vous voulez une mise a jour. Dans Beadbox, la même information est toujours visible dans l'arbre. Aucune requête nécessaire.
Mises a jour en temps réel : l'arbre change sous vos yeux
C'est la que le modèle visuel prouve sa valeur. Quand un agent lance bd update bb-k7p --status=closed dans un terminal, Beadbox capte le changement sur le système de fichiers en millisecondes. Le serveur WebSocket détecte l'écriture dans le répertoire .beads/, diffuse le changement, et l'interface React re-rend.
Dans l'arbre d'épique, ca ressemble a ceci : bb-k7p passe d'un badge orange "in_progress" a un badge vert "closed". La barre de progression de l'épique parent passe de 64% a 71%. Et bb-m3q, qui était bloqué par bb-k7p, perd son indicateur de blocage et apparaît comme travail disponible.
Tout ca se produit sans que vous lanciez une commande ou cliquiez sur un bouton de rafraîchissement. Si vous supervisez une flotte d'agents travaillant sur une épique de release, vous regardez l'arbre se remplir au fur et a mesure que les tâches se terminent. Les goulots d'étranglement émergent au moment ou ils se forment parce que les badges de blocage apparaissent en temps réel. Les sous-arbres stagnants (des clusters de tickets qui cessent de changer de statut) deviennent visuellement évidents après quelques minutes d'inactivité sur un fond de progression régulière ailleurs.
Le mécanisme sous-jacent est simple. Beadbox lance un serveur WebSocket qui appelle fs.watch() sur votre répertoire .beads/. Chaque écriture de base de données déclenche une diffusion. Le hook côté client recoit le signal et relance la server action concernée. Pas d'intervalle de polling, pas de rafraîchissement manuel. La latence de la commande CLI a la mise a jour de l'interface est typiquement inférieure a une seconde.
Navigation keyboard-first
Beadbox est une application desktop pour développeurs, et elle se comporte comme telle. j et k parcourent la liste de tickets (style vim). Enter ouvre le ticket sélectionné dans le panneau de détail. / met le focus sur la barre de recherche. Escape ferme ce que vous avez ouvert. Les touches fléchées déplient et replient les noeuds de l'arbre d'épique.
Vous pouvez trier un backlog entier sans toucher la souris. Descendez la liste avec j, ouvrez un ticket pour lire sa description, appuyez sur Escape pour fermer, passez au suivant. Si vous repérez quelque chose qui nécessite un changement de statut, vous passez au terminal pour les mutations (bd update). Beadbox est une interface orientée lecture par conception. Le CLI gère les écritures. Le GUI gère la compréhension.
Cette séparation est intentionnelle. Une interface graphique qui essaie de remplacer le CLI pour les écritures finit par construire des formulaires pour chaque combinaison de flags possible. Une interface qui se concentre sur la lecture et la navigation peut optimiser pour ce que les terminaux font le moins bien : montrer des données hiérarchiques et a références croisées d'un coup d'oeil.
Plusieurs projets, une fenêtre
Si vous travaillez sur plus d'un codebase, chacun avec sa propre base de données .beads/, le sélecteur de workspace de Beadbox gère ca. Un menu déroulant dans le header liste chaque workspace détecté. Cliquez sur un (ou trouvez le workspace avec la recherche /), et toute la vue se recharge depuis la base de données de ce projet. Les filtres et la position de défilement persistent par workspace, donc revenir ne perd pas votre place.
La détection est automatique. Beadbox scanne les workspaces enregistrés dans la configuration bd et les répertoires contenant des bases de données .beads/. Ajoutez un nouveau projet, initialisez beads dedans, et la prochaine fois que vous ouvrez Beadbox il apparaît dans le menu déroulant. Pas d'importation, pas d'écran de configuration.
Pour les développeurs qui maintiennent plusieurs services, ou pour les équipes ou chaque agent travaille dans un dépôt séparé, cela transforme Beadbox en un panneau unique sur tous les projets actifs. L'alternative est de multiples fenêtres de terminal, chacune exécutant bd list sur un chemin --db différent.
Ce que ca remplace
Beadbox ne remplace pas le CLI. Si vous scriptez vos workflows, passez bd list par jq, ou avez des agents qui créent et ferment des tickets programmatiquement, tout ca continue a fonctionner sans changement. Beadbox lit la même base de données dans laquelle vos scripts écrivent.
Ce qu'il remplace, c'est l'overhead mental de reconstituer l'état du projet a partir de texte brut. Les questions auxquelles Beadbox répond d'un coup d'oeil, et auxquelles le CLI ne répond qu'a travers des requêtes composées :
- Ou en est vraiment cette épique ?
- Qu'est-ce qui est bloqué en ce moment, et par quoi ?
- Quelles sous-tâches n'ont pas été touchées depuis des heures ?
- Les agents progressent-ils, ou sont-ils bloqués ?
Ce sont des questions visuelles. Elles méritent des réponses visuelles.
Pour commencer
Beadbox est gratuit pendant la bêta. Installez avec Homebrew :
brew tap beadbox/cask && brew install --cask beadbox
Si vous utilisez déja beads, Beadbox détecte vos workspaces .beads/ au lancement. Pas d'importation, pas de compte. Ouvrez l'application, dépliez une épique, et voyez ou en est vraiment votre projet.
Tourne sur macOS, Linux et Windows.