15のサブタスクを持つエピックを作成します。複数のエージェントやチームメイトに割り振ります。2日後、誰かが聞きます:「認証のリライト、どこまで進んでる?」

bd show bb-r4fを実行します。エピック自体が表示されます。タイトル、説明、優先度。子タスクがいくつ完了しているかはわかりません。そこでbd list --parent bb-r4fを実行します。IDとタイトルのフラットなリストが返ってきます。各タスクのステータスを見るには、jqでパイプするか、各子タスクに個別にbd showを実行します。子タスクの中にはさらにサブタスクを持つものもあります。3階層目に入り、ターミナル出力から頭の中でツリーを再構成しています。

エピックの子が3つなら問題ありません。10になると破綻します。AIエージェントがサブタスクを作成し、ブロッカーを登録し、イシューを高速でクローズしている場合、CLIの出力はコマンドを実行してから読み終わるまでの間に古くなります。

問題はbeadsにあるのではありません。beads CLIは構造化されたスクリプタブルなイシュー管理に優れています。問題は、階層的な進捗はビジュアルな概念であり、ターミナルはテキストを行単位でレンダリングするということです。

Beadboxでのエピックツリーの見え方

Beadboxを開き、エピックをクリックすると、折りたたみ可能なツリーで子タスクが表示されます。各子タスクにはステータスバッジ(open、in_progress、ready_for_qa、closed)、優先度インジケーター、アサイン先が表示されます。エピック自体にはプログレスバーが表示されます:「14件中9件完了(64%)」。子タスクがクローズされるとこの数字が更新されます。

子タスク自体がエピックの場合は展開でき、そのサブタスクがネストされて表示されます。親の進捗は直接の子だけでなく、すべての子孫から集計されます。エンジニアリング、QA、ドキュメンテーションにまたがる合計40イシューの3階層エピックでは、ツリーのすべてのリーフノードを考慮した実際の完了率がトップに表示されます。

ブロックされたイシューには視覚的な区別があります。bb-m3qがbb-k7pに依存していて、bb-k7pがまだオープンの場合、bb-m3qのステータスの横にブロックバッジが表示されます。ボトルネックを発見するためにbd dep listを実行する必要はありません。ツリーの中で、重要なレベルで見えています。

CLIワークフローと比較してみましょう。「認証エピックの進捗を妨げているものは何か」に答えるには:

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(", "))"'

これは完全に有効なパイプラインです。正しい答えを返します。しかし、書く必要があり、フラグを覚えておく必要があり、更新が欲しいたびに再実行する必要があります。Beadboxでは、同じ情報が常にツリーに表示されています。クエリ不要です。

リアルタイムアップデート: 見ている間にツリーが変わる

ここがビジュアルモデルの真価を発揮するところです。エージェントがターミナルでbd update bb-k7p --status=closedを実行すると、Beadboxはミリ秒以内にファイルシステムの変更を検知します。WebSocketサーバーが.beads/ディレクトリへの書き込みを検出し、変更をブロードキャストし、React UIが再レンダリングされます。

エピックツリーでは、次のように見えます: bb-k7pがオレンジの「in_progress」バッジから緑の「closed」バッジに切り替わります。親エピックのプログレスバーが64%から71%に上がります。そしてbb-k7pにブロックされていたbb-m3qのブロックインジケーターが消え、利用可能な作業として表示されます。

これらはすべて、コマンドを実行したりリフレッシュボタンをクリックしたりせずに起こります。リリースエピックを作業するエージェントフリートを監督しているなら、タスクが完了するにつれてツリーが埋まっていくのを見守ることができます。ボトルネックはブロックバッジがリアルタイムで表示されるため、形成された瞬間に浮上します。停滞したサブツリー(他の着実な進捗の中で数分間ステータスが変わらないイシューのクラスター)は視覚的に明らかになります。

基盤となるメカニズムは単純です。Beadboxは.beads/ディレクトリに対してfs.watch()を呼び出すWebSocketサーバーを実行しています。すべてのデータベース書き込みがブロードキャストをトリガーします。クライアントサイドのフックがシグナルを受信し、関連するサーバーアクションを再フェッチします。ポーリング間隔なし、手動リフレッシュなし。CLIコマンドからUIアップデートまでのレイテンシは通常1秒未満です。

キーボードファーストナビゲーション

Beadboxは開発者向けのデスクトップアプリであり、そのように動作します。jとkでイシューリストを移動します(vimスタイル)。Enterで選択したイシューをディテールパネルに表示します。/で検索バーにフォーカスします。Escapeで開いているものを閉じます。矢印キーでエピックツリーノードを展開・折りたたみます。

マウスに触れずにバックログ全体をトリアージできます。jでリストを下に移動し、イシューを開いて説明を読み、Escapeで閉じて次に移動します。ステータス変更が必要なものを見つけたら、ミューテーションはターミナルで行います(bd update)。Beadboxは設計上、読み取り重視のインターフェースです。CLIが書き込みを担当し、GUIが理解を担当します。

この分離は意図的です。書き込みまでCLIを置き換えようとするGUIは、あらゆるフラグの組み合わせに対してフォームを構築することになります。読み取りとナビゲーションに特化したGUIは、ターミナルが最も苦手なこと、つまり階層的で相互参照されたデータを一目で表示することに最適化できます。

複数プロジェクト、1つのウィンドウ

複数のコードベースにまたがって作業し、それぞれが独自の.beads/データベースを持っている場合、Beadboxのワークスペーススイッチャーが対応します。ヘッダーのドロップダウンに検出されたすべてのワークスペースが一覧表示されます。クリック(または/検索でワークスペースを検索)すると、そのプロジェクトのデータベースからビュー全体がリロードされます。フィルターとスクロール位置はワークスペースごとに保持されるため、切り替えてもアた場所を失いません。

検出は自動です。Beadboxはbd設定の登録済みワークスペースと.beads/データベースを含むディレクトリをスキャンします。新しいプロジェクトを追加し、beadsを初期化すると、次にBeadboxを開いた時にドロップダウンに表示されます。インポート不要、設定画面不要です。

複数のサービスを保守する開発者や、各エージェントが別々のリポジトリで作業するチームにとって、Beadboxはすべてのアクティブプロジェクトの単一ペインになります。代替手段は、それぞれ異なる--dbパスに対してbd listを実行する複数のターミナルウィンドウです。

何を置き換えるのか

BeadboxはCLIを置き換えません。ワークフローをスクリプト化し、bd listをjqにパイプし、エージェントがプログラマティックにイシューを作成・クローズしている場合、それはすべてそのまま動き続けます。Beadboxはスクリプトが書き込むのと同じデータベースを読みます。

置き換えるのは、フラットなテキスト出力からプロジェクトの状態を再構成するメンタルオーバーヘッドです。Beadboxが一目で答え、CLIが組み合わせクエリでしか答えられない質問:

このエピックは実際どこまで進んでいるか?
今何がブロックされていて、何にブロックされているか?
何時間も触れられていないサブタスクはどれか?
エージェントは進捗しているか、それとも停滞しているか?

これらはビジュアルな質問です。ビジュアルな答えが必要です。

はじめに

Beadboxはベータ期間中無料です。Homebrewでインストールしてください:

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

既にbeadsを使用している場合、Beadboxは起動時に.beads/ワークスペースを検出します。インポート不要、アカウント不要。アプリを開き、エピックを展開して、プロジェクトの実際の進捗を確認してください。

macOS、Linux、Windowsで動作します。