v5.5.0：Ask-First 要件アライメント——エージェントが不要なものを届けなくなる¶
クイックアンサー： エージェントは自律実行できるのに、ユーザーが本当に欲しいものと逆のものを届けることがありました。根本原因：要件明確化はユーザーが「受け入れ基準」「要件が不明確」などのキーワードを偶然使ったときだけ発動し、「ランディングページを最適化して」のような曖昧なリクエストは明確化をスキップして計画に直行し、モデルがゴールを推測していました。v5.5.0 はワークフロー層でこれを修正します。曖昧な変更リクエストは計画前に自動的に要件明確化へ入り、エージェントは「調べる→推測する→仮定する→尋ねる」の優先順位（質問は最後の手段）に従い、すべての質問にデフォルト回答が付き、明確化予算（3 ラウンド）＋仮定フォールバックで会話にハードな出口を設け、無限ループを構造的に防ぎます。
失敗モード：有能なエージェント、ずれた成果物¶
ワークフローは実行できました。テストも diff もレビューも行われました。それでも繰り返し起こったのは、戻ってきたものがユーザーの欲しいものではなかったことです。
- リクエスト到着：「优化一下前端页面」/「Improve the landing page.」
- requirements ケイパビリティは、メッセージに明示キーワード（
acceptance criteria、需求不清、clarify the requirements…）があるときだけ発動。 - キーワードなし → 明確化なし → モデルは計画に入り、ゴールを自分で仮定。
- モデルは仮定を完璧に実行——だからこそ、間違ったものが「確実に」作られる。
これは典型的な要件検証の欠落です。ソフトウェア工学の規範では、設計・実装の前に「正しいものを作っているか（Are we building the right thing?）」を検証します。我々の証拠駆動のケイパビリティチェーンは後者しか保証していませんでした。
v5.5.0 の変更¶
1. 曖昧リクエストの構造的検出（キーワード不要）¶
derive-facts は文言ではなく構造で「要件欠落」を判定します：
- 汎用最適化ゴール（「优化」「improve」「优化一下前端页面」）
- かつ観測可能な受け入れ/成果の記述がない（「要求首屏加载时间降低到 2 秒以内」）
- かつ特定機能エンティティがない（「支付模块」「login」「checkout」）
→ 自動で acceptance-criteria-missing を生成 → 計画の前に rex-requirements（Grilling モード）へ。
誤検知ガード内蔵：「我们把上次讨论的优化方案提交了」（完了時制）や名詞句（「optimization plan」）では発動しません。
2. Ask-First 優先順位チェーン——尋ねる前に考える¶
- 調べる —— 環境から確認（ファイル、コード、既存の requirements decision）
- 推測する —— 文脈から推定（過去の決定、リポジトリ制約、ドメイン慣習）
- 仮定する —— 合理的デフォルトを採用し「これは仮定」と明示
- 尋ねる —— 上記がすべて失敗し、かつ実装・受け入れ方法を変える質問のときだけ
すべての質問に仮説＋デフォルトを添付：「ゴールはページのコンバージョン向上だと理解しています。違うなら A か B ですか？（回答がなければ A で続行します）」。回答がなければデフォルトで続行——回答欠落でブロックしない。
3. 明確化予算——無限ループ防止のハード保証¶
要件証拠契約に anyOf 収束グループを追加：
{
"expectedEvidence": [
{ "anyOf": ["acceptance-criteria-recorded", "assumptions-recorded"] },
{ "anyOf": ["non-goals-recorded", "assumptions-recorded"] },
"first-slice-identified",
"requirements-decision-recorded"
]
}
- 受け入れ基準または仮定記録でグループを満たす。
- 3 ラウンド未収束 → 質問を止め、未決項目を仮定リスト（
assumptions-recorded）として記録し、実装をアンロック。 - 仮定リストは成果物と一緒に納品され、受け入れ時にユーザーは何が仮定されたかを一目で確認。
要件ごとに一度だけ明確化し、型付き requirements-decision アーティファクトがアライメントを記録。同じ要件の再リクエストで再発動しません。
旧フロー vs 新フロー¶
以前：「优化一下前端页面」→ 計画 →「スタイルリファクタ＋性能＋ダークモード」→ 納品 → 「私はコンバージョンが欲しかったのに。」
現在：「优化一下前端页面」→ 自己チェック：目標が曖昧（何を？誰に？成功の測り方は？） → デフォルト付きの質問：「ページのコンバージョン向上がゴールだと理解しています。違うなら A か B ですか？」→ 確認 → requirements-decision 記録 → 開発アンロック → 届くのはユーザーが求めたもの。
検証¶
- rex-harness 200 テスト合格（199/200。唯一の失敗は macOS
/privateパス環境ベースラインで本変更と無関係）。 - メインリポジトリのワークフローテスト 103/103 全緑。新規ケース含む：曖昧な中国語リクエスト→明確化、曖昧な英語リクエスト→明確化、受け入れ記述あり→明確化なし、特定機能ターゲット→明確化なし、明確化済み→再発動なし、仮定収束→ステージ完了。
- 収束契約テスト追加：完全受け入れ証拠（互換パス）、仮定フォールバック（ループ出口）、グループ欠落で blocked（契約を緩めない）。
rex-harness doctorはreadyを報告。
アップグレードメモ¶
- これは動作変更です。リクエストが構造的に曖昧な場合、ワークフローは一時停止して質問します。その一時停止こそが機能です。
- 既存の型付き requirements decision（
requirements-decision-recorded）は尊重され、再明確化を抑制。 - UI タスクには方向確認ステップを追加：実装前に 1-2 のスタイル/レイアウト方向を提示。
意図的に曖昧なリクエストで試してみてください。手を動かす前にアライメントするワークフローを確認できます。