out-of-scopelisted

# 範囲外の課題を、見つけたその場で起票する 作業の途中で見つけた**この変更の範囲に含まれない課題**を、発見の瞬間に issue へ残す。 **この手順は工程ではない。** 順序を持たず、モードごとの要否も持たない。実装・構造改善・ レビュー・完了判定・原因の調査のいずれからも呼ばれる。範囲外の課題は見つかるか見つからないか であって、変更の重さが決めるものではない。 ## 用語 | 用語 | この文書での意味 | | --- | --- | | 範囲外の課題 | この変更の受け入れ条件にも、直す対象にも含まれない課題 | | 起票 | GitHub の issue を新しく作ること | | 由来 | その課題を見つけた元。Pull Request がまだ無ければ、起点の issue になる | | 起票先 | `gh issue create` が issue を作るリポジトリ | ## いつ呼ぶか | 呼び出し元 | 呼ぶ場面 | | --- | --- | | `tdd-cycle` | 実装中に、対象の外で不具合や不整合に気づいたとき | | `refactoring` | 手を付ける範囲の外に、直したい兆候を見つけたとき | | `cross-review` / `pr-review` / `fix` | 指摘を範囲外と判断したとき | | `quality-gates` | 完了報告の「範囲外と判断したもの」を書くとき | | `problem-solving` | 根本原因がこの変更の範囲の外にあったとき | ```mermaid flowchart TD H[実装] -.-> S[起票] R[構造改善] -.-> S V[実装レビュー] -.-> S K[完了判定] -.-> S S -.番号.-> T[振り返り] ``` ## 手順 ### 1. 範囲かを照合する **この手順は基準を新しく作らない。** 次の 2 つと突き合わせる。 | 照合の相手 | 読む場所 | | --- | --- | | 受け入れ条件 | `requirements-design` が作った仕様（`issues/` 配下） | | やらないこと | `implementation-plan` の計画ファイルの「目的と非目的」 | どちらも無い変更では、依頼文が範囲を決める。 ### 2. 3 択で決める 判断は次の 3 つに限る。**迷ったら起票する側へ倒す。** 後で閉じるほうが、拾い直すより安い。 | 判断 | 選ぶ条件 | 残すもの | | --- | --- | --- | | 起票する | 範囲外だが、直さないと誰かが困る | issue と、作業メモへの 1 行 | | 範囲内へ入れる | この変更で直す対象と同じ原因・同じ形で、分けると片方だけが残る | 範囲を広げた事実と理由を計画ファイルへ 1 行 | | 起票しない | 変更前と同じ挙動で、直す価値が現時点で無い | 理由を 1 行（作業メモか完了報告） | 3 つ目も理由を残す。理由が残っていないと、後から指摘されたときに「判断した」のか 「気づかなかった」のかを区別できない。 ### 3. 起票先を決める **「起票する」を選んだときだけ行う。** 残る 2 つの判断には起票先が要らない。 NDF を使う開発では、Skill の実体を持つリポジトリと、開発している側のリポジトリが別に なることがあ