インタビュー冒頭の質問がゼロコンテキスト（標準タスクのベースライン仮説を提示せず、常に白紙の質問になる）

_Requested by **sunagawa** · [Slack thread](https://cfj-organization.slack.com/archives/C08T0JC9MKN/p1779407973888089?thread_ts=1779407973.888089&cid=C08T0JC9MKN)_

## 課題（現状の挙動）

標準タスク（約20業務、`docs/kb/workflows/_standardized-20/*`）でインタビューを開始すると、どのタスクでも「業務の正式名称と通称を教えてください」「関係者はどなたですか？」といった**完全に白紙・ゼロコンテキストの質問**から始まる。対象業務が固定資産税でも印鑑登録でも、開口一問目の文言はほぼ同一で、事前に分かっているはずの情報（正式名称・目的・根拠法・所管部署の当たり）が一切活用されていない。

職員としては、「一般的には資産税課が担当だと思いますが、他に関係する部署はありますか？」のように**仮説を提示して確認・訂正してもらう**形の方が回答しやすく、聞き取り効率も上がる。現状は毎回ゼロから聞かれるため、労力に対して得られる情報が薄い。

### 原因調査（コード確認済み）

1. `lib/server/interview/slots.ts` の `SLOT_DEFS` が定義する質問テンプレート（`taskName` / `purpose` / `legalBasis` / `stakeholders` 等のスロット）は、**全タスクで完全に同一の白紙テンプレート**であり、タスクごとに一切変化しない。
2. `lib/kb/loader.ts` の `loadStandardFlowSummary()` は mermaid フロー本体と `displayName` のみを `followup.ts` に渡しており、`flow-standard.md` の YAML frontmatter（`spec_law` / `psid_service_category` 等）は質問生成プロンプトに一切注入されていない。
3. `lib/server/interview/followup.ts` の `buildSystemPrompt` には「推測や断定はしない」という明示ルールがあり、これが「仮説を提示して確認してもらう」という望ましいUXと**構造的に矛盾**している。
4. この白紙前提の設計は、フォーク元（チームみらいのインタビューアプリ）から引き継いだものと推測される。フォーク元とこのアプリでは目的（標準フローベースのインタビュー）が異なるため、単なるデータ不足ではなく**設計のミスマッチ**である可能性が高い。

## あるべき姿

標準タスク（約20業務）については、インタビュー冒頭でタスクメタデータから導いたベースライン仮説（正式名称・通称、一般的な目的、典型的な根拠法、所管部署の当たり、よく関連する部署）を提示し、**確認・訂正を求める質問**として開始する。ベースラインデータが存在しないタスク（「その他」／カスタムタスク等）では、現状の白紙質問にフォールバックする。

## 技術的な着手ポイント

コンテンツ（`flow-standard.md` へのベースラインデータ追記、`docs/kb/concepts/department-naming-baseline.md` の新設）は別途人が作成予定。本Issueは**コード側の対応**を追跡する。

- `flow-standard.md` の frontmatter を拡張し、`baseline` オブジェクトを追加（`common_name` / `common_aliases` / `purpose_generic` / `primary_department_hint` / `related_department_hints` / `department_naming_note`。典型的な根拠法は既存の `spec_law` を再利用）。
- 部署名が自治体規模で揺れる問題（例：人事課↔総務課、固定資産税課↔税務課）を都度書かないよう、`docs/kb/concepts/department-naming-baseline.md` のような横断参照ファイルを既存 `concepts/` の作法に合わせて新設。
- **コード変更（本Issueのスコープ）**：
1. KB frontmatter の型／スキーマに `baseline` を追加（`lib/kb/types.ts` の `FlowStandardFrontmatterSchema` 等）。
2. `lib/kb/loader.ts` の `loadStandardFlowSummary`（または新規関数）を拡張し、`baseline` フィールドを呼び出し元に渡す。
3. `lib/server/interview/followup.ts` の `buildFollowupRequest`（相当）を拡張し、`baseline` データが存在する場合にLLMコンテキストへ注入する。
4. `buildSystemPrompt` の「推測・断定しない」ルールに明示的な例外を追加：ベースラインデータがある場合は仮説として提示し確認・訂正を求める、無い場合は現状どおり推測しない。
5. `lib/server/interview/slots.ts` の `SLOT_DEFS`（またはフォローアップのプロンプトテンプレート）を更新し、`taskName` / `purpose` / `legalBasis` / `stakeholders` 等のスロットで、ベースラインデータがある場合は仮説確認形、無い場合は現状の白紙形の文言にフォールバックする。

## 受け入れ条件

- [ ] `baseline` frontmatter フィールドがKB型定義・スキーマに追加され、パースできる
- [ ] `loadStandardFlowSummary`（または新規関数）が `baseline` フィールドを呼び出し元に渡す
- [ ] `baseline` データを持つタスクでインタビューを開始すると、開口の質問が仮説提示・確認形（例：「一般的には人事課だと思いますが、他にどんな関係部署がありますか？」）になる
- [ ] `baseline` データを持たないタスク（「その他」等）では、現状どおり白紙の質問にフォールバックする
- [ ] `buildSystemPrompt` の「推測・断定しない」ルールに、ベースラインがある場合の例外が明記される
- [ ] 既存の他業務のインタビュー進行が壊れない

## 優先度

中〜高。#34（本筋からの脱線防止）の対応後、聞き取り効率・職員の回答負担を下げる改善として着手を推奨。コンテンツ（ベースラインデータ本体）の作成待ちであり、コード側の受け皿を先行して用意しておくと着手が早い。

## 関連Issue

関連: #34, #36, #40（ただし別問題。冒頭質問のゼロコンテキスト問題は上記いずれとも別の根本原因であり、重複・統合はしない）

Start with FlowStandardFrontmatterSchema in lib/kb/types.ts, loadStandardFlowSummary in lib/kb/loader.ts, and the prompt and slot handling in lib/server/interview/followup.ts and lib/server/interview/slots.ts. Trace how standard-flow metadata reaches the opening question, then verify that baseline data produces hypothesis-confirmation wording, missing data preserves the blank fallback, and existing interview flows continue to work.

Written by the indexing model from the issue text.