03 1リクエストの旅 — 依頼が成果物になるまで

「ログイン機能を追加して」と1文依頼したとき、NexusCoreの内部では何が起きるのか。依頼が出口に着くまでの旅を追います。

旅の全体図

flowchart TB
    A["👤 依頼が届く"] --> B["🚪 受付（API）が受け取る"]
    B --> C["🧠 指揮官が仕事を分解する"]
    C --> D["📋 手順書を作る"]
    D --> E["✍️ 書く係が実装"]
    E --> F["🧪 テストを走らせる"]
    F --> G{"合格？"}
    G -->|"No"| H["🔧 直す係が分析・修正"]
    H --> F
    G -->|"Yes"| I["🔍 検品する係が確認"]
    I --> J["📦 成果物として納品"]

各停留所での出来ごと

受付口: 依頼を安全に受け取ります。ここで「どのプロジェクトに対する依頼か」の検証も行います（勝手な場所を触られないため）
指揮官: 依頼を小さな仕事に分解し、手順書を作って各係に割り振ります
書く係→テスト→直す係: 第2章の自己修復ループがここで回ります
検品する係: 「テストは通ったが、そもそも依頼の内容を満たしているか？」を別の目で確かめます

なぜ検品を分けたのか

書いた人自身に検品を任せると「自分のコードは正しいはず」という思い込み（確証バイアス）が働きます。NexusCoreでは書いた係と検品する係を別のAIにすることで、この思い込みを構造的に防いでいます。

技術的な土台

<details><summary>▶ 技術的にどうなっているか</summary>

受付: FastAPI の POST /api/v1/runs。validate_project_path により依頼先パスの検証（symlink解決・機密ディレクトリ拒否）を実施
指揮官: Orchestrator（PhaseRunnerMixin）。手順は goal_spec として分解され、完了判定基準（criterion）も一緒に定義される
検品: ReviewerAgent / PostmortemAgent などが生成結果を依頼文と突合
完了判定は「コードがある」だけでなく criterion 満足で判定（get("code") or get("files") のキー不整合バグ修正は第9章の実話）

</details>