Skip to content

v0.21.0 — パイプライン/バックログのライブダッシュボードとフォローアップ捕捉

Choose a tag to compare

@wfukatsu wfukatsu released this 06 Aug 12:45
· 204 commits to main since this release

パイプラインとバックログの進捗を「今どこを走っているか」まで含めてターミナルで可視化し、デリバリー中に見つかった作業を取りこぼさない仕組みを入れたリリースです。

ハイライト

ダッシュボードが 1 本に — tools/nexus-status.shTab で 2 ビュー切替)

バックログにはライブ表示があったのに、その手前の product / architect パイプラインには手段がなく、work/pipeline-progress.json を生の JSON で読むしかありませんでした。新規スキル /architect:report-status / /product:report-status(haiku)が、フェーズツリーをカテゴリ単位で表示します。

  • 各フェーズの状態、宣言された outputs: のうち実在する数([==..] 2/4)、直近 5 分の書き込み/トークン消費、未充足の依存、モデルティア、記録済みコスト
  • architect の手動拡張ティアは折りたたみ可能な独立グループ
  • product ビューはヘッダに validate-assumptions のゲート判定と未検証前提の件数を追加
  • 状態は進捗レジストリ優先・実ファイル補完。食い違い(completed なのに出力なし/pending なのに全出力あり)はドリフトとして明示し、丸めません
  • Enter で次コマンド生成(クリップボード、または --execclaude 実行)、a で選択行の文脈つきで Claude に質問、? でヘルプ。--once / --json / --md は非対話レンダリング

実行中のフェーズが「実行中」に見えるようになった

進捗レジストリに in_progress 契約を追加。オーケストレータは各フェーズをスキル起動in_progress + started_at)と復帰後(completed/failed)の 2 回書きます。これが実行中の可視化の唯一の手段であり、トークン使用量フックのコスト按分もこれに依存します(無いとトークンが pending バケットに溜まる)。

バックログデリバリーのライブダッシュボード

/architect:report-backlog-status(haiku)+ tools/backlog-status.sh。Epic → Sub-Epic → Issue のツリーで、各アイテムのデリバリー状態(todo/doing/review/done/blocked — トラッカー優先、次に impl.status、seed の labels は使わない)と Implemented / Reviewed / Merged のステージを表示。s / --sync でライブの glab / gh ラベルを重ねてドリフトを検出します。

フォローアップの取りこぼしを止める

/architect:capture-followup(sonnet)。デリバリー中に出てくる先送りタスク・スコープ外の指摘・ドキュメントドリフト・切り出したスコープ・waive された受入条件を、半自律の実装ランを止めずにキュー(reports/backlog/followup-queue.md)へ捕捉。承認ゲートを経てトラッカー Issue として起票し、backlog-manifest.jsonF 番台ローカル ID(I1.2.F1)+ origin トレイルで追記します。F 番台は export-backlog の位置採番 ID と構造的に非交差です。

チェックボックスの意味を変更(破壊的ではないが挙動が変わります)

従来は merge-issue がマージした時にしかチェックが入らず、実装もテストも終わってレビュー待ちの Epic が 0% 表示になっていました。チェックボックス = 実装済み + テスト通過デリバリー状態(マージ済み)は status::* ラベルと impl.status に分離。本文には ## Delivery Status セクション(Status: 行 + ステージ別チェックリスト)が入り、「マージされたか」はこちらが答えます。既存アイテムは編集時にレトロフィットされます。

ドキュメント

docs/analysis-mechanism_ja.md(新規)— architect プラグインが既存コード・設計ドキュメントをどう解析しているか。AST 優先のツール階層、シンボル参照による別名実装の検出、2 段階ルーブリック採点、テンプレート突合とギャップ駆動ヒアリング、進捗レジストリという状態機械、exit 2 によるフックの自己修正ループ、5 視点 × 3 次元の二重並列レビューと externalize された品質ゲートまで。

契約テスト

tools/lib/pipeline_status_data.test.pytools/lib/backlog_status_data.test.pyskills/capture-followup/followup-contract.test.py を追加。

詳細は CHANGELOG.md / CHANGELOG_ja.md を参照。