NDF Factory: 画面の地図の「予定」の画面に、作る課題（持ち主）が書かれていない（#2382 の受け入れ条件 2 の残り） #2431

何を見つけたか

ndf v10.27.14（タグ ndf--v10.27.14、commit 84381ee）のリリース後テストで、#2382 の受け入れ条件 2「まだ画面が無い機能は、載せる予定の画面と持ち主の課題が分かる」のうち、持ち主の課題が画面の地図に無い。

docs/specifications/ndf-factory-screen-map.md の「画面の地図」で状態が「予定」の 3 行（承認・請求と使用量・手元のマシン）は、載る機能だけを書き、どの課題がその画面を作るかを書いていない。

| 未定 | 承認 | 個人・管理者・席 | 予定 | 承認の依頼・Web からの承認・通知 |
| 未定 | 請求と使用量 | 個人・管理者 | 予定 | 料金プランの料金・使用量の台帳・決済 |
| 未定 | 手元のマシン | 個人・管理者 | 予定 | 手元のマシンの登録・心拍 |

タグの時点（2026-11-02 21:50 JST に確かめた）と、確定仕様化の後の develop の両方で同じである。

どこで見つけたか

• docs/specifications/ndf-factory-screen-map.md の「画面の地図」43〜45 行
• リリース後テストの記録: Pull Request Release: ndf v10.27.14 #2426 のコメント

なぜこの変更の範囲外なのか

リリース後テストは不合格を即時修正しない（release-verification の「合否を判定する」）。リリース後の修正は新しい変更として、モードの判定から始める。根拠: プロジェクト Value 7（判断の理由を残す・正本を 1 か所に）・スプリント Value 2（画面先行で地図を土台にする）（MVV 版 4）。

直さないと何が起きるか

画面を足す課題が、地図の「予定」の行を自分の持ち物か判断できない。#2382 の非機能の条件（運用・保守性）「画面を足す課題は、地図の行と翻訳のキーを足すだけで済む」の前提になる、行と課題の対応が無いままになる。#2382 が閉じられると、この条件の残りを持つ課題が無くなる。

起票者の推定

• 承認の画面の持ち主は NDF Factory: 承認ゲートの通知（Slack を含む）と Web からの承認 #2173（承認ゲートの通知と Web からの承認）である（推した出所: NDF Factory: 承認ゲートの通知（Slack を含む）と Web からの承認 #2173 の題）
• 残りの 2 行（請求と使用量・手元のマシン）の持ち主は起票者には決められず、直す変更で課題を探して書く（推した出所: 起票者の判断）

由来

PR #2426

以下は要求と受け入れ条件である（2026-11-04、requirements-design）。上の節は起票の時点の本文で、書き換えていない。

依頼（原文）

NDF Factory: 画面の地図の「予定」の画面に、作る課題（持ち主）が書かれていない（#2382 の受け入れ条件 2 の残り）

（書き手: 起票者、日付: 2026-11-02。課題の題。リリース後テストの記録 #2426 から起票した AI の文で、利用者の指示の原文ではない）

2. 確定仕様 docs/specifications/ndf-factory-*.md の機能のうち利用者が操作するものが、地図のどの画面に載るか（まだ画面が無い機能は、載せる予定の画面と持ち主の課題）が分かる

（書き手: 起票者、日付: 不明。#2382（UX の土台）の受け入れ条件 2。#2382 は承認ゲート 1 を通っており、この条件は利用者が承認で確かめた条件として扱う）

画面を足す課題は、地図の行と翻訳のキーを足すだけで、部品・整形・API クライアントの仕組みに手を入れずに済む

（書き手: 起票者、日付: 不明。#2382 の非機能の条件の「運用・保守性」の行）

この課題の要求の出所は #2382 の受け入れ条件 2 の後半（「持ち主の課題」）だけである。利用者が会話で書いた文は無い。

起票者の推定

目的

• 画面を足す課題が、画面の地図の「予定」の行を見て、その行が自分の課題の持ち物か（自分が作る画面か）を 1 回の読みで判断できる状態にする
• NDF Factory: UX の土台（画面の地図・部品・端末・オフラインの見せ方・国際化・ダミーデータの API クライアント）を機能の画面より先に作る #2382 の受け入れ条件 2 の残り（まだ画面が無い機能の、作る課題）を満たし、NDF Factory: UX の土台（画面の地図・部品・端末・オフラインの見せ方・国際化・ダミーデータの API クライアント）を機能の画面より先に作る #2382 が閉じた後もこの条件を持つ文書が残る状態にする

前提

• 前提 1: 承認の画面（承認の依頼・Web からの承認・通知）を作る課題は NDF Factory: 承認ゲートの通知（Slack を含む）と Web からの承認 #2173 である。根拠: NDF Factory: 承認ゲートの通知（Slack を含む）と Web からの承認 #2173 の受け入れ条件 5〜7 が「承認の画面」「判断の依頼の画面」を定め、受け入れ条件 4 が「承認の画面の URL」を Slack の通知へ入れる
• 前提 2: 請求と使用量の画面（料金プランの料金・使用量の台帳・決済）を作る課題は NDF Factory: サブスクリプションと Bedrock の token 課金 #2174（サブスクリプションと Bedrock の token 課金）である。根拠: NDF Factory: サブスクリプションと Bedrock の token 課金 #2174 の本文が「この課題の使用量の台帳」「決済の手段（Stripe など）」を持つ。NDF Factory: サブスクリプションと Bedrock の token 課金 #2174 の本文は画面をまだ受け入れ条件に書いていないため、画面を作るかどうかは NDF Factory: サブスクリプションと Bedrock の token 課金 #2174 の要求で決まる。この課題は地図に作る課題を書くだけで、NDF Factory: サブスクリプションと Bedrock の token 課金 #2174 の範囲を変えない
• 前提 3: 手元のマシンの画面（手元のマシンの登録・心拍）を作る課題は NDF Factory: 手元のマシン（利用者の環境で、利用者の claude ログインで実行する） #2189（手元のマシン）である。根拠: NDF Factory: 手元のマシン（利用者の環境で、利用者の claude ログインで実行する） #2189 の受け入れ条件 17 が「手元のマシンの一覧」の画面を定め、起票者の推定 S9 が「手元のマシンの一覧と登録の token の管理の画面を作る」とする
• 前提 4: 作る課題は、画面の地図の表の「予定」の行に、GitHub の課題の番号（#<番号>）で書く。列を足すか既存の列に書くかは設計で決める（未決 1）
• 前提 5: 状態が「あり」の行（すでに画面がある行）には、作った課題を書き足さない。NDF Factory: UX の土台（画面の地図・部品・端末・オフラインの見せ方・国際化・ダミーデータの API クライアント）を機能の画面より先に作る #2382 の受け入れ条件 2 が課題を求めるのは「まだ画面が無い機能」だけである
• 前提 6: factory/web/src/screens.ts の予定の画面の定義（approvals・billing・runners）は、作る課題を持たない。画面の地図の文書が人の読む対応の正本で、screens.ts は経路の定義の正本である（文書の「概要」）。作る課題は経路を作らないため、screens.ts へ写さない

対象範囲

含む:

• 画面の地図（docs/specifications/ndf-factory-screen-map.md）の「予定」の 3 行に、作る課題を書く
• 画面の地図の冒頭の、画面を足す課題が行う手順の文に、「予定」の行を自分の課題が作るときの扱い（行を「あり」へ変える）を書く

含まない:

• 予定の画面そのものを作ること（NDF Factory: 承認ゲートの通知（Slack を含む）と Web からの承認 #2173・NDF Factory: サブスクリプションと Bedrock の token 課金 #2174・NDF Factory: 手元のマシン（利用者の環境で、利用者の claude ログインで実行する） #2189 が持つ）
• NDF Factory: 承認ゲートの通知（Slack を含む）と Web からの承認 #2173・NDF Factory: サブスクリプションと Bedrock の token 課金 #2174・NDF Factory: 手元のマシン（利用者の環境で、利用者の claude ログインで実行する） #2189 の本文と受け入れ条件を書き換えること
• factory/web/src/screens.ts と翻訳のファイルの変更（前提 6）
• 状態が「あり」の行へ、作った課題を書き足すこと（前提 5）
• 画面の地図のほかの節（ナビゲーション・動線・見本の画面）の変更

ドメインイベント

E2 の失敗の経路（作る課題が後から変わる）は、この課題では作る課題を書き換える仕組みを作らず、画面を足す課題が自分の要求で直すものとして扱う（含まない）。

用語

「持ち主」は用語集で状態の持ち主・見直しの持ち主など別の意味に使われているため、この要求では「作る課題」と書く。

受け入れ条件

• 1. 画面の地図の状態が「予定」の 3 行が、それぞれ作る課題を #<番号> で示す。承認は NDF Factory: 承認ゲートの通知（Slack を含む）と Web からの承認 #2173、請求と使用量は NDF Factory: サブスクリプションと Bedrock の token 課金 #2174、手元のマシンは NDF Factory: 手元のマシン（利用者の環境で、利用者の claude ログインで実行する） #2189 である
• 2. 受け入れ条件 1 で書いた課題は、どれも GitHub で open である（gh issue view <番号> --json state が OPEN を返す）
• 3. 画面の地図の冒頭の、画面を足す課題が行う手順の文に、作る課題として書かれた「予定」の行を作るときは、その行の状態を「あり」へ変え経路を書くことが書かれている
• 4. 状態が「あり」の行の内容と行の数（13 行）は変わらない（変更の差分が「予定」の 3 行と冒頭の手順の文だけである）
• 5. 既存のテスト（factory/web/src/docs.test.ts の、地図の「あり」の行の経路の集合と screens.ts の一致）が通る
• 6. 文書の書式の検査（document-style のセルフチェック）で、追記した行に内部の識別子の裸の使用と多義語の新たな当たりが無い

非機能の条件

影響

検証手段

前提とする取り決め

境界

未決

根拠にした MVV の項目

• プロジェクト Value 8（判断の理由を残し、語をそろえる。正本を 1 か所に置き、番号には題か中身を添える）: 作る課題を画面の地図の 1 か所に書き、screens.ts へ写さない（前提 6）。「持ち主」を多義を避けて「作る課題」と書く
• スプリント Value 2（画面先行。画面の地図を UX の土台にする）: 予定の画面と作る課題の対応を地図に持たせる
• プロジェクト Value 2（人が判断できる量に収める）: 変更を「予定」の 3 行と冒頭の 1 文に限る
• 共通原則の C1〜C8・プロジェクトの P1 に当たる操作は無い（文書だけの変更）

進行

モード: — / 進め方: auto

• 要求と受け入れ条件 — 2026-11-04 15:29
• 作業場所の用意 — 2026-11-04 22:15
• 設計 — 2026-11-04 15:33
• 素材の収集と出典の確定
• ドキュメント再構成
• ドキュメントレビュー
• 計画 — 2026-11-04 22:15
• 実装 — 2026-11-05 00:08
• 構造改善 — 2026-11-05 00:25
• 実装レビュー — 2026-11-05 00:50
• 完了判定 — 2026-11-05 00:10
• Pull Request — 2026-11-05 00:22
• 確定仕様化 — 2026-11-05 03:28
• 後片付け — 2026-11-05 03:53
• 配布 — 2026-11-05 01:34
• 体裁レビュー
• リリース後テスト — 2026-11-05 03:48
• 振り返り — 2026-11-05 03:48
• 棚卸し — 2026-11-05 03:54

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

• 判定: unknown（承認ゲート 1）
• 理由: 設計の中身はスプリント Value 2（画面先行）とプロジェクト Value 8（判断の理由を残し、語をそろえる）に沿う。予定の画面の行に作る課題を括弧で添え、表の形と状態が「あり」の行は変えない。決定の記録に根拠もある。人の承認が要る操作（C1〜C8・P1）に当たる変更も見当たらない／変更したファイルの一覧に plugins/ndf/scripts/tests/test_sprint_loop.py（+3 -1）がある。しかし本文は「変更は 4 ファイル・追加 373 行・削除なし」と書き、設計の適用範囲も「配布物（plugins/）は変えない」と定めている。配布物のテストへの変更が何を目的とし範囲内なのかを、材料から判断できない（Value 2・Value 8 に照らした承認資料の正しさ）／要求の検査（requirements-check）は exit 2 で止まった。理由は issues/issue-2431-requirements.md を読めなかったことで、原因は未確認のまま。この検査は配布の前に取れる確認であり、通らないままでは要求の文書が検査の基準を満たすかを決められない（Value 1: 確かめていないものを済んだと記録しない）／このため、Mission・Vision に沿い Value のどれにも反しないとは、材料だけでは言い切れない。人へ戻して、余分なファイルの扱いと検査が止まった原因を確かめてもらう必要がある
• 根拠の項目: Mission, Value 1, Value 2, Value 8, スプリント Value 2
• 設計 Pull Request: 画面の地図: 予定の画面ごとに、その画面を作る課題が分かる（#2431） #2496
• 答え: approved
• 答え方: python3 /persistent/ai/.claude/plugins/cache/ai-plugins/ndf/10.27.16/scripts/sprint-state.py loop answer lfactory3 2431 --approved|--rejected|--revise --note <指摘ファイル>

閉じた理由

ndf v10.27.19 で直った。docs/specifications/ndf-factory-screen-map.md の画面の地図の「予定」の 3 行（承認・請求と使用量・手元のマシン）に、作る課題（#2173・#2174・#2189）が書かれている（タグ ndf--v10.27.19 の 44〜46 行で確かめた）。冒頭の段落に、作る課題が画面を作ったときの行の書き換え方もある。

振り返り: #2532 (comment)