Vous creez un epic avec 15 sous-taches. Vous les repartissez entre plusieurs agents ou coequipiers. Deux jours plus tard, quelqu'un demande : "Ou en est la refonte de l'authentification ?"
Vous lancez bd show bb-r4f. Ca donne l'epic lui-meme. Titre, description, priorite. Ca ne dit pas combien d'enfants sont termines. 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-taches. Vous etes maintenant trois niveaux plus bas, reconstituant un arbre dans votre tete a partir de la sortie du terminal.
Ca fonctionne quand un epic a trois enfants. Ca s'effondre a dix. Et si vous coordonnez des agents IA qui creent des sous-taches, declarent des blocages et ferment des tickets en succession rapide, la sortie CLI devient obsolete entre le moment ou vous lancez la commande et celui ou vous finissez de la lire.
Le probleme n'est pas beads. Le CLI beads excelle dans la gestion structuree et scriptable de tickets. Le probleme est que le progres hierarchique est un concept visuel, et les terminaux affichent du texte en lignes.
A quoi ressemble un arbre d'epics dans Beadbox
Ouvrez Beadbox, cliquez sur un epic et vous voyez ses enfants dans un arbre depliable. Chaque enfant affiche un badge de statut (open, in_progress, ready_for_qa, closed), un indicateur de priorite et le responsable. L'epic lui-meme affiche une barre de progression : "9 sur 14 termines (64%)." Ce nombre se met a jour a mesure que les enfants sont fermes.
Depliez un enfant qui est lui-meme un epic et vous voyez ses sous-taches imbriquees en dessous. La progression du parent agregue tous les descendants, pas seulement les enfants directs. Un epic a trois niveaux avec 40 tickets au total entre ingenierie, QA et documentation vous montre le pourcentage reel d'achevement en haut, en tenant compte de chaque noeud feuille dans l'arbre.
Les tickets bloques recoivent un traitement visuel distinct. Si bb-m3q depend de bb-k7p et que bb-k7p est encore ouvert, le badge bloque apparait a cote du statut de bb-m3q. Pas besoin de lancer bd dep list pour decouvrir le goulot. Il est visible dans l'arbre, au niveau ou ca compte.
Comparez avec le workflow CLI. Pour repondre a "qu'est-ce qui bloque la progression de l'epic d'authentification", 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(", "))"'
Ce pipeline est parfaitement valide. Il renvoie la bonne reponse. Mais vous devez l'ecrire, retenir les flags et le relancer a chaque mise a jour souhaitee. Dans Beadbox, la meme information est toujours visible dans l'arbre. Aucune requete necessaire.
Mises a jour en temps reel : l'arbre change pendant que vous regardez
C'est la que le modele visuel prend tout son sens. Quand un agent lance bd update bb-k7p --status=closed dans un terminal, Beadbox detecte le changement sur le systeme de fichiers en quelques millisecondes. Le serveur WebSocket detecte l'ecriture dans le repertoire .beads/, diffuse le changement et l'interface React se re-rend.
Dans l'arbre d'epics, ca ressemble a ceci : bb-k7p passe d'un badge orange "in_progress" a un badge vert "closed". La barre de progression de l'epic parent avance de 64% a 71%. Et bb-m3q, qui etait bloque par bb-k7p, perd son indicateur de blocage et s'affiche comme travail disponible.
Tout cela se produit sans lancer de commande ni cliquer sur un bouton de rafraichissement. Si vous supervisez une flotte d'agents travaillant sur un epic de release, vous regardez l'arbre se remplir a mesure que les taches se terminent. Les goulots d'etranglement apparaissent des qu'ils se forment car les badges de blocage surgissent en temps reel. Les sous-arbres stagnants (groupes de tickets qui cessent de changer de statut) deviennent visuellement evidents apres quelques minutes d'inactivite, en contraste avec la progression reguliere ailleurs.
Le mecanisme sous-jacent est simple. Beadbox execute un serveur WebSocket qui appelle fs.watch() sur votre repertoire .beads/. Chaque ecriture en base de donnees declenche une diffusion. Le hook cote client recoit le signal et relance la server action concernee. Pas d'intervalle de polling, pas de rafraichissement manuel. La latence entre la commande CLI et la mise a jour de l'interface est generalement inferieure a une seconde.
Navigation keyboard-first
Beadbox est une application desktop pour developpeurs, et il se comporte comme tel. j et k parcourent la liste de tickets (style vim). Enter ouvre le ticket selectionne dans le panneau de details. / place le focus sur la barre de recherche. Escape ferme ce qui est ouvert. Les fleches deplient et replient les noeuds de l'arbre d'epics.
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 necessite un changement de statut, vous basculez vers le terminal pour les mutations (bd update). Beadbox est une interface orientee lecture par conception. Le CLI gere les ecritures. L'interface gere la comprehension.
Ce decoupage est intentionnel. Une interface graphique qui essaie de remplacer le CLI pour les ecritures finit par construire des formulaires pour chaque combinaison possible de flags. Une interface qui se concentre sur la lecture et la navigation peut optimiser ce que les terminaux font le moins bien : afficher des donnees hierarchiques et a references croisees d'un seul coup d'oeil.
Plusieurs projets, une seule fenetre
Si vous travaillez sur plusieurs bases de code, chacune avec sa propre base de donnees .beads/, le selecteur de workspace de Beadbox gere ca. Un menu deroulant dans l'en-tete liste chaque workspace detecte. Cliquez sur l'un d'eux (ou trouvez le workspace avec la recherche /) et toute la vue se recharge a partir de la base de donnees de ce projet. Les filtres et la position de defilement persistent par workspace, donc revenir en arriere ne vous fait pas perdre votre position.
La detection est automatique. Beadbox scanne les workspaces enregistres dans la configuration de bd et les repertoires contenant des bases de donnees .beads/. Ajoutez un nouveau projet, initialisez beads dedans, et la prochaine fois que vous ouvrez Beadbox, il apparait dans le menu deroulant. Pas d'import, pas d'ecran de configuration.
Pour les developpeurs qui maintiennent plusieurs services, ou pour les equipes ou chaque agent travaille dans un depot separe, cela transforme Beadbox en un panneau unique pour tous les projets actifs. L'alternative est de multiplier les fenetres de terminal, chacune lancant bd list contre un --db path different.
Ce que ca remplace
Beadbox ne remplace pas le CLI. Si vous scriptez vos workflows, passez bd list dans jq ou avez des agents qui creent et ferment des tickets programmatiquement, tout continue de fonctionner sans changement. Beadbox lit la meme base de donnees que vos scripts alimentent.
Ce qu'il remplace, c'est la charge mentale de reconstituer l'etat du projet a partir de sorties textuelles plates. Les questions auxquelles Beadbox repond d'un coup d'oeil, et que le CLI ne resout qu'a travers des requetes composees :
- Ou en est vraiment cet epic ?
- Qu'est-ce qui est bloque en ce moment, et par quoi ?
- Quelles sous-taches n'ont pas ete touchees depuis des heures ?
- Les agents progressent-ils ou sont-ils au point mort ?
Ce sont des questions visuelles. Elles meritent des reponses visuelles.
Pour commencer
Beadbox est gratuit pendant la beta. Installez-le avec Homebrew :
brew tap beadbox/cask && brew install --cask beadbox
Si vous utilisez deja beads, Beadbox detecte vos workspaces .beads/ au demarrage. Pas d'import, pas de compte. Ouvrez l'application, depliez un epic et voyez ou en est reellement votre projet.
Fonctionne sur macOS, Linux et Windows.