共通タスク（前確・太陽光）

共通フレーム「案件タスク」

前確（訪問前確認）と太陽光調査・設計は、どちらも次の同型フローです。個別実装ではなく**1つの型（DealTask）**に載せます。

依頼 ─▶ 担当候補を提示（負荷順）─▶ 人が割当 ─▶ 作業 ─▶ Slack通知 ─▶ 結果/成果物 ─▶ 次の担当へ通知

共通項目（DealTask）：種別(type) / 割当先(assignee) / ステータス(status) / 予定・期限(due) / 結果(result) / 成果物リンク(driveUrl) / ゲート(gate・前確のみ)

タスク種別	トリガー	担当候補（負荷順）	通知（受け渡しごと）	結果／成果物
前確（訪問前確認）	営業がアポ情報入力	バックオフィス（前確ロール）	依頼時→担当／ OK時→営業	OK/NG/不出 → 案件ステータス更新
太陽光調査・設計	営業が依頼	バックオフィス（設計ロール）	依頼時→担当／完了時→営業	Driveに処理一式 → 案件に紐付け
（将来の工程依頼）	…	…	…	…

前確（訪問前確認）

営業がアポ情報を入力した後、バックオフィスが電話でアポ取りする流れ。前確は「初回訪問の前」と「クロージング訪問の前」の2箇所で発生し、いずれも案件ステータス上は同一の「前確」タスクとして扱う（案件ステータス＝DealStatusはそのまま。DealTaskのgate（初回前 / クロージング前）で区別する）。

① 営業が案件にアポ情報を入力
② CRMが前確担当の候補を負荷順に提示 → 人が担当を選んで割当
③ Slack通知（担当宛）：顧客名（世帯）・案件リンク＋[OK] [NG] [不出] ボタン（予定日時は本文に含まない）
④ 担当が架電 → ボタン押下で案件に結果反映
     ├ OK  → 案件=商談 ／【営業にも通知】
     ├ NG  → 案件=失注（理由）
     └ 不出 → 再架電（リスケ）

旧フォームの CW_* / Slack* 項目は、このタスクの内部状態に吸収（入力項目から消える）。
担当候補は「現在の未完タスク数（負荷）が少ない順」に提示する（staffCandidates()）。割振は人が行う（当日の量を見て振り分ける運用。CRMは自動で確定割当はしない）。
クロージング前の前確（gate: クロージング前）は、商談ステータスのまま並行して発生するタスクとして持つ。パイプライン（DealStatus）は1本のまま増やさない。

太陽光調査・設計

訪問アポで「太陽光あり」の場合の、調査・設計の依頼フロー。

① 営業が【調査・設計を依頼】（太陽光あり案件）
② CRMが調査・設計担当の候補を負荷順に提示 → 人が担当を選んで割当
      └─ Slack通知（担当宛）：案件リンク・物件情報
③ 担当が調査 → 設計
④ Googleドライブの【所定フォルダに処理一式（設計図/シミュレーション/見積根拠 等）】が格納
      └─ Slack通知（営業宛）：成果物が届いた／クロージング準備OK
⑤ 営業がその設計を持って【訪問クロージング】へ

成果物は Google Drive の案件フォルダに格納し、CRMから**参照（リンク）**して案件画面で開ける（連携参照）。
担当候補は前確と同じ仕組み（負荷順の提示、割振は人）を使う。
「成果物が届いた」を起点に営業へ通知（Drive監視 or 担当の完了操作でDriveリンク添付、のいずれか。実装時に選択）。

状態遷移（まとめ）

案件:アポ ─▶ 前確 ─OK▶ 商談 ─受注▶ 成約 ─▶ 工事 ─▶ 完了
   │              └NG▶ 失注                    └失注▶ 失注
   └─(太陽光あり)─▶ 太陽光 調査・設計 ─完了(Drive)▶ （商談へ合流）

状態はDealStatus（アポ／前確／商談／成約／工事／完了／保留／失注／クーリングオフ）に準拠。上図は主要パイプライン（DEAL_STAGES）と主な分岐のみを示す。
クロージング前の前確は、上図の状態を追加で分岐させるものではない（商談ステータスのまま、DealTaskとして並行実施）。

共通タスク（前確・太陽光）

共通フレーム「案件タスク」

前確（訪問前確認）

太陽光 調査・設計

状態遷移（まとめ）

太陽光調査・設計