NDF Factory: スプリントの一覧（フェーズ）と詳細（工程・PR・CI・承認ゲート） #2172

親: #2168（Neural Development Factory）。前提: #2169（確定仕様）・#2170（v10.26.0 で配布）・#2171（contracts と進捗の受け口）・#2186（実行の制御とランナー）。

形と契約は サービス全体の確定仕様 の「サービス全体の契約（子課題が実装する）」と、契約の定義と型・進捗の受け口・実行ジョブの token にある。この課題は「一覧と詳細」（進捗の事象から一覧と詳細の読み出しの形を導く派生）の持ち主で、phase.changed が運ぶフェーズの名前の集合を決める（確定仕様の「受け持つ課題」の #2172 の行）。

今の状態（2026-11-05）

受け入れ条件 1〜18 の実装は Pull Request #2484 （スプリント lfactory3-1）で develop へ入り、ndf 10.27.16 で配った。残るのは検証手段の「手動確認」（実環境の 1 本のスプリントの実行を一覧と詳細で開き、フェーズ・工程・Pull Request・CI・承認ゲートが実際の進み方と合うかを人が見る）で、factory/ がどの環境にもデプロイされていないため確かめていない。実環境で確かめるまで開いておく。

依頼（原文）

• /ndf:development-workflow のsprintを並列で進めることが可能。
  • sprint一覧でそれぞれがどのフェーズを進めているかが化しかできる
• sprint詳細で進捗状況が可視化できる。

（書き手: 利用者、日付: 2026-10-30。#2168 の構想を伝えた会話の原文のうち、この課題が受け持つ行。全文は #2169 の「依頼（原文）」にある。「化しか」は「可視化」の誤記と読む）

スプリントの一覧と詳細の画面を作る。

（書き手: 起票者、日付: 2026-10-30。この課題の旧本文の「何をするか」）

• 工程の記録は 1 行ずつ詳細へ辿れる。押すと右側が詳細パネルに切り替わり、触ったファイル（GitHub へのリンク）・その工程で決めたこと・終了コード・秒・費用・ログと作業の報告を出す（モック https://claude.ai/artifact/MYL6CPBTsm6JFTNgtiwY2J の「スプリント詳細」）
• 仕上げのフェーズに振り返りと棚卸し（必須）を出す（NDF の定義どおり。スプリントは棚卸しの報告で終わる）。棚卸しはスプリントの外でも実施できるよう、バックログの画面（順位・棚卸しの記録・今すぐ棚卸し）を持つ

（書き手: 起票者、日付: 2026-10-31。旧本文の「画面の方針（2026-10-31 の利用者の指摘、モックで確かめる）」。利用者の指摘の原文は確かめられないため、利用者の文としては扱わず、指摘の中身（詳細パネル・仕上げの 2 工程・バックログの画面）を利用者の方針として読む。モックは要求を書いた時点で読めなかった（未決 1））

起票者の推定

題・本文のうち、利用者の指示の原文に無く起票者が推して足した条件。承認ゲート 1 で利用者が確かめるまで、利用者の決定として扱わない。

目的

• 1 つのアカウントで並列に流れる複数のスプリントの実行が、それぞれ今どのフェーズにいて、承認待ちか止まったかを、1 つの画面で見分けられる状態にする（Neural Development Factory: NDF を Web UI で操作できる Software Factory のサービスにする #2168 の受け入れ条件 5 の後半）
• 1 つのスプリントの実行について、課題ごとの工程・Pull Request・CI の結果・承認ゲートの状態を 1 つの画面で追え、工程を 1 行ずつ辿ってその工程の中身（触ったファイル・決めたこと・終了コード・秒・費用・ログ）まで確かめられる状態にする（Neural Development Factory: NDF を Web UI で操作できる Software Factory のサービスにする #2168 の受け入れ条件 6）
• スプリントの外でも、取り込んだリポジトリの順位と棚卸しの記録を読める状態にする

前提

• 前提 1: 一覧と詳細は、進捗の記録（NDF Factory: contracts と進捗の受け口 #2171）の事象の列と、スプリントの実行（NDF Factory: スプリントの実行の制御とランナー #2186）の状態だけから導く。課題の本文・ボード・GitHub の API は読まない。例外はバックログの画面で、順位の表は NDF Factory: スプリントの実行の制御とランナー #2186 の GitHub の口（factory/api/src/github/port.ts の棚卸しの順位の表の読み出し）を使う
• 前提 2: フェーズの名前の集合は 設計・実装・検査・取り込み・仕上げ の 5 つとし、factory/contracts/ に列挙として置く。NDF のプランの "フェーズ" の値 配布（開発版） は 取り込み、配布（本番） は 仕上げ へ、ランナーの翻訳が写す（NDF の agent-layers.md の「フェーズ」の表で、検証リリースは取り込み、本番へのリリースは仕上げの工程）。受け口は今どおり文字列で受け、集合に無い名前の phase.changed は 400 にせず残し、画面は「その他（<名前>）」と出す（NDF の版がフェーズを足しても記録が失われない）
• 前提 3: 一覧の「今のフェーズ」は、そのスプリントの実行の最後の phase.changed の phase（order_key の順）とする。並列の実装で複数の課題が同じフェーズにいるときも 1 つの名前になる。phase.changed が 1 件も無い実行は「始まる前」と出す
• 前提 4: 詳細パネルの「触ったファイル」「その工程で決めたこと」「ログと作業の報告」は、今の進捗の事象の形では届かない。この課題は step.recorded の payload に任意の項目（触ったファイルのパスの並び・決めたことの文の並び・作業の報告の本文）を足し、schema_version を上げない互換の追加とする（今のランナーの事象も通る）。足す形は設計で決め、確定仕様（ndf-factory-service-boundary.md の「進捗の事象の種類と受け口」・ndf-factory-contracts-and-progress.md の「進捗の事象の定義」）を直す Pull Request を先に出す。ランナーの翻訳（factory/runner/）もこの課題で直す
• 前提 5: 工程を課題へ結び付けるため、step.recorded の payload に課題の番号の並び（任意）を足す（前提 4 と同じ互換の追加）。番号を持たない step.recorded（スプリントで 1 つの検査・取り込み・仕上げの工程や、足す前のランナーの事象）は、課題ごとの欄でなく「スプリント全体」の欄に出す
• 前提 6: 工程の費用は、同じスプリントの実行の usage.recorded のうち payload.step がその工程と等しいものの cost の和とする。等しいものが無ければ「—」と出す。形態 ①・② の費用も同じく出す（確定仕様の「usage.recorded は 3 つの形態とも出す」）
• 前提 7: 一覧と詳細は、画面を開いている間 30 秒ごとに API を読み直して更新する。押し出しの通知は作らない。読み直しの間隔は設定の 1 か所で変えられる
• 前提 8: 承認ゲートの状態は、承認の依頼の集約（NDF Factory: 承認ゲートの通知（Slack を含む）と Web からの承認 #2173。まだ実装されていない）を読まず、進捗の事象 gate.reached・gate.answered・job.finished（gate）と、スプリントの実行の状態 awaiting_approval から導く。状態は「承認待ち」「承認された」「差し戻された」「判断を待っている」「判断に答えた」の 5 つとする。承認するボタンは NDF Factory: 承認ゲートの通知（Slack を含む）と Web からの承認 #2173 が置き、この課題は置かない
• 前提 9: 見せる範囲は、resolveAccount で解決できたアカウントのスプリントの実行だけ。チームのアカウントでは席を持つ人なら誰でも一覧と詳細を読める（スプリントの一覧と同じ。NDF Factory: スプリントの実行の制御とランナー #2186 の確定仕様の「持ち主だけの経路」）。他人のアカウントのもの、アカウントに属さない sprint_run_id はどれも 403 forbidden と同じ本文で返し、有無を明かさない
• 前提 10: 詳細の読み出しは、1 つのスプリントの実行の事象を全件読んで導く。件数の上限は設計で過去のスプリントの progress.jsonl の行数を実測して決め、超えたら古い工程から省いて省いた件数を出す
• 前提 11: 時刻は ISO 8601 の UTC で受け、画面はブラウザの地域の時刻で出す
• 前提 12: 「仕上げのフェーズに振り返りと棚卸し（必須）を出す」は、仕上げのフェーズの欄に工程 振り返り・棚卸し の行を常に置き、step.recorded がまだ無ければ「まだ」と出すことを指す。工程の名前の照合は、ランナーが step.recorded の step に写す NDF のステップの識別子のうち、どれを振り返り・棚卸しと見なすかを設計で決める
• 前提 13: バックログの画面は、取り込んだリポジトリごとに、順位の表（NDF Factory: スプリントの実行の制御とランナー #2186 の候補が読むものと同じ）と、そのリポジトリのスプリントの実行のうち仕上げのフェーズで記録された棚卸しの工程の一覧（日時・要約・Pull Request）を出す。読むだけで、課題やマイルストーンを書き換えない

対象範囲

含む:

• 画面（factory/web/）: スプリントの一覧・スプリントの詳細（工程の詳細パネルを含む）・バックログの画面と、そこへの導線（アカウントとリポジトリの画面から）
• API（factory/api/）: 一覧の派生を足した読み出し・詳細の読み出し・バックログの読み出しの経路と、その OpenAPI（factory/contracts/openapi/）
• 契約（factory/contracts/）: フェーズの名前の列挙と、step.recorded の任意の項目の追加（前提 4・5）。確定仕様を直す Pull Request を先に出す
• ランナー（factory/runner/）: フェーズの名前の写し（前提 2）と、step.recorded の足した項目の翻訳（前提 4・5）

含まない:

• 承認と差し戻しの操作・承認の依頼の保存・Web と Slack の通知（NDF Factory: 承認ゲートの通知（Slack を含む）と Web からの承認 #2173）
• 「今すぐ棚卸し」の操作（スプリントの外で棚卸しの実行ジョブを起こす。未決 2）
• スプリントの開始と取り消しの操作（NDF Factory: スプリントの実行の制御とランナー #2186 が置いた画面のまま）
• 料金と請求の画面（NDF Factory: サブスクリプションと Bedrock の token 課金 #2174）
• 押し出しの通知（WebSocket・Server-Sent Events）
• DynamoDB の表と GSI・API の入口などインフラの定義（private リポジトリ）
• 課題の本文の ## 進行 とボードを読むこと

ドメインイベント

用語

受け入れ条件

一覧:

• 1. アカウントに、フェーズの異なる 3 つのスプリントの実行（最後の phase.changed が 設計・検査・仕上げ）があるとき、一覧の 3 行にそれぞれ 設計・検査・仕上げ が出る
• 2. 一覧の各行に、リポジトリ・課題の番号・スプリントの実行の状態（実行中・承認待ち・終わった・止まった・失敗・取り消し）・今のフェーズ・始めた日時が出る。phase.changed が 0 件の実行は今のフェーズに「始まる前」が出る
• 3. phase が 5 つの名前に無い phase.changed（例 準備）が最後の実行は、今のフェーズに「その他（準備）」が出て、一覧の読み出しは 200 を返す
• 4. ランナーが NDF のプランの "フェーズ" の値 配布（開発版） を 取り込み、配布（本番） を 仕上げ として phase.changed に写す。5 つの名前はそのまま写す

詳細:

• 5. 課題 2 つ（#A・#B）を持つ実行で、payload に課題 #A を持つ step.recorded は #A の欄に、#B を持つものは #B の欄に、課題を持たないものは「スプリント全体」の欄に、order_key の順で並ぶ
• 6. 各課題の欄に、その課題の工程を作った・更新した Pull Request（番号と GitHub へのリンク）と、最後の pr.updated の状態（open / closed / merged）と、その Pull Request の ci.updated のチェックの名前ごとの最後の結論（未完了は「実行中」）が出る。pr.updated が無い Pull Request は状態に「不明」が出る
• 7. 工程の行を押すと、右側が詳細パネルに切り替わり、ステップ・終了コード・秒・費用（前提 6）・要約・触ったファイル（各パスが GitHub のそのリポジトリのファイルへのリンクで、足した行数と消した行数を添える）・決めたこと（問い・答え・誰が決めたか）・作業の報告とログを開く操作・差分を GitHub で見るリンクが出る。「概要に戻る」で右側が承認ゲート・Pull Request と CI・使用量の欄に戻る。足した項目を持たない工程では、その欄に「記録なし」が出る
• 8. 承認ゲートの状態が、gate.reached（ゲート 1）だけの実行では「ゲート 1: 承認待ち」、続いて承認の gate.answered があれば「ゲート 1: 承認された」、差し戻しなら「ゲート 1: 差し戻された」と出る。判断の gate.reached は「判断を待っている」、答えがあれば「判断に答えた」と出る。承認ゲート 1・2 と判断の 3 つの欄を持ち、承認の欄は 2 つだけである
• 9. 仕上げのフェーズの欄に、工程 振り返り と 棚卸し の行が常にあり、step.recorded が届く前は「まだ」、届いた後はその工程の終了コードと秒が出る
• 10. 一覧と詳細を開いたまま、新しい進捗の事象が追記されると、読み直しの間隔（既定 30 秒）の 2 倍以内に画面へ出る。読み直しが失敗しても前の表示は消えない

認可と読み方:

• 11. 一覧・詳細・バックログの読み出しは、他人のアカウント・存在しないアカウント・そのアカウントに属さない sprint_run_id・存在しない sprint_run_id のどれでも、403 forbidden を同じ本文で返す
• 12. API が 401 を返すと、画面は token を消してログインの画面へ移る
• 13. 一覧と詳細の読み出しは、課題の本文・ボード・GitHub の API を呼ばない（偽の GitHub の口の呼び出しが 0 回）
• 14. step.recorded の足した項目（前提 4・5）を持たない事象（今のランナーの形、schema_version 1）を受け口が 202 で受け、詳細に出る。受け口の既存のテストが変えずに通る

バックログ:

• 15. バックログの画面に、リポジトリの順位の表（順位・課題の番号・題）と、そのリポジトリのスプリントの実行の棚卸しの工程の一覧（日時・要約・Pull Request）が新しい順に出る。順位の表が無いリポジトリでは「順位の表がありません」が出る
• 16. バックログの画面は、課題・マイルストーン・ボードへ書き込む操作を持たない

退行:

• 17. factory/ の npm run check（CI の factory-check）と境界の検査（python3 scripts/check-service-boundary.py）が通る
• 18. スプリントの一覧の既存の経路（GET /accounts/{accountId}/sprint-runs）の既存の項目の名前と型は変わらない（足すだけ）

非機能の条件

影響

検証手段

前提とする取り決め

境界

モックの中身

モック https://claude.ai/artifact/MYL6CPBTsm6JFTNgtiwY2J の 3 画面（2026-10-31 に conductor が読んだ版 1793412669-5df4）。値は例示で、配置と項目だけを要求として読む。

モックにあってこの課題の受け入れ条件に入れないもの: 件数の札の token・上限（#2174）、「止める」（#2186）、承認する・答えるの操作（#2173）、「今すぐ棚卸しする」（未決 2）。表示の場所は残し、操作は前提の課題が入るまで出さない。

未決

🤖 Generated with Claude Code

進行

モード: — / 進め方: auto

• 要求と受け入れ条件 — 2026-10-31 08:26
• 作業場所の用意 — 2026-11-04 08:23
• 設計 — 2026-10-31 08:52
• 素材の収集と出典の確定
• ドキュメント再構成
• ドキュメントレビュー
• 計画 — 2026-11-04 08:23
• 実装 — 2026-11-04 09:56
• 構造改善 — 2026-11-04 10:52
• 実装レビュー — 2026-11-04 11:33
• 完了判定 — 2026-11-04 10:20
• Pull Request — 2026-11-04 10:37
• 確定仕様化 — 2026-11-04 14:29
• 後片付け — 2026-11-04 15:02
• 配布 — 2026-11-04 12:57
• 体裁レビュー
• リリース後テスト — 2026-11-04 14:58
• 振り返り — 2026-11-04 14:58
• 棚卸し — 2026-11-04 15:02

人の判断待ち（開発ループ l20261031）

• 判定: follow（承認ゲート 1）
• 理由: Mission と Vision に沿う: 並列のスプリントのフェーズ・工程・承認ゲートを画面で追えるようにし、人が止まる箇所（承認待ち・失敗）を探す手間を減らす。変更は factory/ の内側に限り、plugins/ の利用者の振る舞いは変えない／Value 3 に沿う: 件数の上限・報告の切り詰め・ページ数の見込みを過去 11 スプリントの実測で決めている。p95 2 秒は配布の後に測るものとしてリリース後テストへ回している／Value 6 と Value 7 に沿う: フェーズの写しをランナーの翻訳（腐敗防止層）の 1 か所に置き、列挙を contracts の 1 か所にまとめている。14 件の決定に、採らなかった案とその理由を残している／Value 2 に沿う: 事象の形の追加を、この設計 PR の承認ゲート 1 で見る（決定 13）。別の承認の工程は足していない／C1 と C2 に当たる設計を含む: 作業の報告・ログ・判断の文を外へ送る経路の伏せ字の範囲（決定 7）と、新しい 3 つの読み出しの経路の認可（I12・決定 14）は人が見る必要がある
• 根拠の項目: Mission, Vision, Value 2, Value 3, Value 5, Value 6, Value 7, Value 10, C1, C2
• 設計 Pull Request: NDF Factory: 並列に動くスプリントの今のフェーズと、課題ごとの工程・Pull Request・CI・承認ゲートを画面で追える（#2172） #2278
• 答え: approved
• 答え方: python3 /persistent/ai/.claude/plugins/cache/ai-plugins/ndf/10.27.7/scripts/sprint-state.py loop answer l20261031 2172 --approved|--rejected

前提にする方針（2026-11-02 追記）

利用者の指示で、マイルストーン「25 Neural Development Factory」の説明にスプリント MVV を置いた（操作性と UX 重視・画面先行・オフライン利用・AI からも人と同じく使える・国や地域を越えて使える。#2168 の方針の表にも同じ行がある）。この課題の画面は #2382（UX の土台）の上に作り、#2383（オフラインで読める）と #2384（API と MCP から画面と同じ操作）の形に合わせる。

振り返り: #2490 (comment)