クライアント自作ERP ValueOS（stanaka-blip/valueos・Next.js＋Supabase）の卸(商社)まわりUIを、新CRM（アーキテクチャ＝Next.js＋Supabase＋サーバー層）へ統合するための方針と移植計画。
ValueOS フロントは app配下 tsx 115ファイル（うち page.tsx＝画面 66）／lib .ts 143ファイル（ロジック）。Next.js App Router・全面 "use client" 寄り・Tailwind 生className 多用。
- ドメイン/計算ロジックが
lib/ に分離＋ユニットテストあり（threeParty/・purchasePrices・workflow・*.test.ts）。View/Panel は計算を lib から import し表示に専念（例: CaseDetailView ThreePartyMoneyPanels SettlementForm は supabase直叩き0・prop駆動・lib依存4〜5）。
- TypeScript が堅い（主要ファイルで
any ほぼ0）。
- 受発注〜三社間〜請求入金の業務フローが実DB付きで動く。
- ビューがモノリシック：
CaseDetailView 2,412行 / ThreePartyMoneyPanels 1,463行 / orders/new 1,412行 / invoices/new 1,262行 / orders/[id]/edit 1,103行。1画面＝1ファイル・className 100〜231個。コンポーネント分解がほぼ無い。
- 共有UIプリミティブ（デザインシステム）が無い：Button/Table/Field/Panel/StatusBadge が無く、各画面が生Tailwindでフォーム/表を手書き → 重複と不統一。
- データアクセスが不統一：
invoices/new(supabase直7＋useState13)・orders/[id]/edit(直5)・cases/[id]/page(直7) 等がページ内で supabase を直接叩く。一方 saveDealerOrder.ts はサーバーアクション分離 → 方針がバラバラ。
- 全面
"use client"：App Router なのに Server Components を使わず読み取りもクライアント。
- CI無し＋巨大ファイル → 変更リスクが高い。
| 対象 | 判断 | 具体 |
|---|
| 画面の切り方・画面構成 | 踏襲(Keep) | ValueOS のルーティング・画面粒度をそのまま新CRMに写す |
| 業務フロー・状態遷移 | 踏襲(Keep) | 受発注→請求→入金・三社間・canOrder/canInvoice 等の仕様を維持 |
lib/ ドメイン・計算・workflow・テスト | 移植(Keep) | 新CRMのサーバー層(TS)へ1:1移植。テストごと確保 |
| 巨大ビュー/パネル | 分解して再構築(Rebuild) | セクション/パネル単位の小コンポーネントへ。ロジックはlibのまま |
| フォーム（useState 10〜25の塊） | 共通フォーム化(Rebuild) | 新CRMの record-ui/Field部品＋パターンに載せる |
| 生Tailwind | shadcn/ui＋トークン(Rebuild) | Button/Table/Field/StatusBadge を共通化＝重複解消・統一 |
| クライアント直叩き supabase | サーバー層＋RLSへ(Rebuild) | 決定済みアーキに統一。.from()直叩きは持ち込まない |
| 読み取り（一覧/詳細の初期表示） | RSC化(Rebuild) | Server Componentsで取得、操作だけクライアント |
- 共有UIプリミティブを先に整備（Button/Input/Field/Select/Table/Panel/StatusBadge）。以降の全画面再構築が速く・統一される。
- 巨大コンポーネントの分解：目安 1コンポーネント ~200行以下。
CaseDetailView は「サマリ／三社間／受発注／請求／入金／タスク」等のパネルに分割。
- データ層の統一：取得はサーバー（RSC/サーバー関数）、更新はサーバーアクション/RPC。ブラウザに supabase を直接叩かせない。
- フォーム標準化：手書き useState 群を共通Field＋バリデーションパターンへ。
- 移植は画面単位：1枚ずつ「同じ見た目・同じフロー」で置換。ロジックは lib から呼ぶ。
規模＝ValueOSの実ファイル規模。難度の目安：特大＝要分解(>25KB or >1000行)／大＝12–25KB／中＝6–12KB／小＝<6KB。ロジック（lib/*.ts 143本）は原則そのまま移植のため本表は画面(tsx)のみ。
| 画面/部品 | 規模 | 種別 | 難度 | 依存・備考 |
|---|
cases/[id]/CaseDetailView | 2,412行 | 詳細ビュー | 特大 | 直叩き0・lib依存5・className231。最優先で分解 |
cases/[id]/ThreePartyMoneyPanels | 1,463行 | 三社間パネル | 特大 | 直叩き0・lib4・useState25。パネル分割 |
cases/[id]/orders/new | 1,412行 | 受発注フォーム | 特大 | 直叩き14・useState13。データ層＋フォーム再構築 |
cases/[id]/invoices/new | 1,262行 | 請求作成 | 特大 | 直叩き7・useState13 |
cases/[id]/page | 526行 | 詳細エントリ(RSC) | 大 | 直叩き7（取得）→サーバー層へ |
cases/[id]/SettlementForm | 353行 | 決済フォーム | 中 | 直叩き0・useState15 |
cases/[id]/WorkflowPanel | 366行 | 工程パネル | 中 | lib5（workflow） |
cases/[id]/products/new・edit・CasesList・cases/page・StatusBadge/Select | 300〜9KB | 一覧/小物 | 中〜小 | |
| 画面 | 規模 | 難度 | 備考 |
|---|
orders/[id]/edit | 1,103行 | 特大 | 直叩き5・useState11 |
orders/[id]/print・delivery-print・orders/[id]/page | 16–23KB | 大 | 印刷は機械的だが量が多い |
admin/orders/OrderDetail・OrdersList・OrderStatusActions | 10–19KB | 中〜大 | 管理側受発注 |
| 画面 | 規模 | 難度 | 備考 |
|---|
invoices/[id]/payments/new | 21KB | 大 | 入金登録フォーム |
invoices/[id]/page | 775行 | 大 | 直叩き3 |
invoices/[id]/print・invoices/page | 13–19KB | 中〜大 | |
payments/PaymentsBoardClient・payments/page | 2–16KB | 中 | 入金ボード |
| 画面 | 規模 | 難度 | 備考 |
|---|
dealer-settlements/[id]/print | 19KB | 大 | 精算書PDF |
components/threeParty/FinanceReceiptPaidForm | 5KB | 小 | |
| 画面 | 規模 | 難度 | 備考 |
|---|
dealer/orders/new/page＋Step2ProductForm | 25KB＋26KB | 特大 | 直叩き0・saveDealerOrder(サーバーアクション)分離＝良い手本。ステップフォーム |
dealer/orders/new/Step3/Step4 | 3–10KB | 中〜小 | |
| 画面 | 規模 | 難度 | 備考 |
|---|
prices/new | 711行 | 大 | 直叩き7・useState10 |
sales-prices/bulk-by-dealer | 575行 | 大 | 直叩き5・useState15（販売店別一括） |
prices/bulk-by-supplier | 18KB | 大 | 仕入先別一括 |
prices/page・[id]/edit・sales-prices/page・new・[id]/edit・components/prices/* | 1–15KB | 中〜小 | |
| 画面 | 規模 | 難度 | 備考 |
|---|
products/setup | 461行 | 大 | 直叩き2・useState12（初期設定） |
products/new・[id]/edit・products/page・検索 | 3–15KB | 中〜小 | |
packages/bulk | 23KB | 大 | 一括 |
packages/new・[id]/edit・[id]/page・page・検索 | 2–14KB | 中〜小 | |
| 群 | 規模 | 難度 | 備考 |
|---|
各マスタの page/new/[id]/[id]/edit | 大半 <11KB | 中〜小 | CRUD定型。新CRMの MasterScreen 定型に載せ替えると大幅に共通化・削減 |
staff/page | 346行 | 中 | useState11 |
components/masters/*（削除ボタン等） | <4KB | 小 | |
| 画面/部品 | 規模 | 難度 | 備考 |
|---|
queues/payments-management/PaymentsManagementClient | 804行 | 大 | useState16（入金消込キュー） |
queues/collections/CollectionsQueueClient | 9.9KB | 中 | 回収キュー |
DashboardClient | 368行 | 中 | ダッシュボード |
components/AppSidebar | 589行 | 大 | ナビ＋認証。新CRMのSidebarに統合 |
components/case-registration/*（ウィザード5枚） | 8–10KB×5 | 中 | 案件登録ウィザード。良い分割の手本 |
components/case-attachments/*・print/*・layout・login・auth | 各<9KB | 中〜小 | |
- 共有UIプリミティブ整備（Button/Table/Field/Panel/StatusBadge）＋
lib/ ロジック移植（テストごと）。← 最初にやると以降が加速
- 卸コアから画面単位で再構築：案件詳細
CaseDetailView（分解）→ 受発注 orders/new・orders/[id]/edit（データ層＋フォーム）→ 三社間 ThreePartyMoneyPanels → 請求・入金 → 販売店発注（dealer/orders＝既に分割が綺麗なので早い）
- マスタ群は新CRMの MasterScreen 定型へ載せ替え（多数の小画面を一気に共通化・削減）
- クライアント直叩き（invoices/new・orders/edit・prices/new 等）をサーバー層/RPCへ移設
リスクと対策：特大5画面（CaseDetailView・ThreePartyMoneyPanels・orders/new・invoices/new・orders/edit）が工数の山。ここは「見た目・フロー据え置き＋内部分解」を徹底し、lib/ の計算は移植して振る舞いの同一性をテストで担保する。