requirement-convergence

# 要件収束 ## 目的 要件は、膨らんだ状態、曖昧な状態、狙う成果を外した状態で届く。能力の高いモデルはその3つをまとめて筋の通った計画に組み直し、忠実に作り上げてしまう — 求められたものが間違っていたときに、求められたとおりのものを届けることになる。 このスキルは**何を作るか**を収束させる。どう作るか、そして変更にどのドキュメントが必要かは、何を作るかが決まった後に定める。 ## 収束フィールド | フィールド | 通過条件 | |-----------|---------| | `outcome` | 観測可能な結��が1つ。それに寄与しない要件は余剰である。 | | `requirements[]` | 各項目に `current-state`、`desired-future`、`speculative` のいずれかのラベルが付いている。`speculative` はこのレイヤーラベルの1つであり独立したフィールドではない。「投機的要件」とはそのラベルを持つ項目を指す。 | | `nonGoals[]` | ユーザーが挙げたもの。または、除外すべきものはないとユーザーが述べたこと。 | | `cost` | バンド1つと、それを決めた構造���の根拠、および残っている不明点。 | `cost` は粗いバンドであり、作業計画書がスケジュールの根拠にする工数見積ではない — 要件の段階では人日を支えられない。その不明点は、大きさよりも判断上の重みを持つ。 各フィールドは自身の readiness ラベルを持つ: `ready`、`weak`、`weak-but-explicit`（weak だが、未解決のまま残すことにユーザーが同意した状態）。`weak-but-explicit` を設定できるのはユーザーだけである。該当する全フィールドが `ready` または `weak-but-explicit` になった時点で、要件は収束したとみなす。 フィールドごとの判断ルール: [references/criteria.md](references/criteria.md)。 ## ヒアリングプロトコル 聞き出す作業と判定の両方をオーケストレーターが担う。アナライザーが出したスコープとコストのエビデンスを用い、リポジトリからは答えられないプロダクト上の選択のみを尋ねる。アナライザーを再実行するのは、回答が分析対象または必要なスコープエビデンスを変える場合のみとする。 開始前に以下のステップを登録し、完了ごとにその根拠を記録する: | ステップ | 行うこと | 完了の根拠 | |---------|---------|-----------| | 1 | 分析が出したスコープの事実を述べ、そこから要件について何が言えるかを分けて示す | 事実が、その出所となった分析出力とともに列挙されている | | 2 | `ready` に達していないフィールドについて、1メッセージあたり最大2問で質問する | `ready` に達していないフィールドごとに1問 | | 3 | 各回答をそのフィールドの値として記録する | 値が、ユーザーが選択した選択肢、またはユーザーが述べた言い回しになっている | | 4 | 記録した値がまだ通過条件を満たさない場合は1度だけ聞き直し、2度目の回答のままでよいとユーザーが同意した時点でそのフィールドを `weak-but-explicit` とする | 記録された回答が2つ、またはそこで止める...