FR-080 判準（開工前寫定，全程只用這一組）

一支套件 = 一個「能力」。兩支要不要合併，只問三個問題，順序固定：

C1 資料同生共死？（D17 律①）

• 兩邊的表想建 FK、同一交易寫兩邊、一邊沒另一邊沒意義 → 是同一件事，合。
• 只存對方 id 的軟參照 → 不算。

C2 換個產品，會不會一起被拿走？

• 一個跟稽核無關的新產品要裝 A，一定也要裝 B（或反之）→ 合。
• A 可以單獨用、B 也可以單獨用 → 不合，即使同族。

C3 同一個人養？（發版節奏／操作者）

• 兩邊從未獨立演化、同批 bump、改一邊必改另一邊 → 支持合。
• 這是輔助條件，C1/C2 都不成立時 C3 單獨不能合。

反向條件（任一成立就不合，即使 C1–C3 都像）： R1 合併後會讓一堆本來不依賴 X 的套件被迫依賴 X（合併對象是「被很多人依賴的供應者」） R2 合併後套件會變成「開機時做很多不相干事」的雜物袋（決策者對 system-infra 的定義是「系統開起來一定要有」，不是「雜物」）

決策者已表態（輸入，不重議）：

• asset：device + information-system 合
• flow-engine 不併 task-platform
• notification 獨立（會持續擴充）
• system-infra = 「系統開起來一定要有的基本功能」

「套件疆界」與「部署疆界」是兩件事，用兩個詞：

• 合併/不動 → 講套件
• 同進程/分開部署 → 講部署

一支套件能不能分開部署，只問： S1 它跟宿主之間的資料交換能不能全部變成「網路呼叫 + 軟參照」？（有跨界 FK 就不行，先改軟參照） S2 它有沒有獨立的生命週期理由：不同的擴縮型態（CPU 重／I/O 重／長時間工作）、不同的發版節奏、不同的安全邊界、不同的操作者 S3 分開之後，宿主的哪些聚合查詢會斷？（骨幹 readmodel 清單）斷的能不能改成 API 拼裝或 CQRS 讀模型？

沒有 S2 理由的，不分開部署——微服務的成本（網路、一致性、部署、觀測）要有理由才付。

• 25 支逐支：結論（合併進 X／不動／退役）+ 一句內容級理由（引 C1–C3 / R1–R2）
• 部署：哪些「可分開部署」、哪些「預設分開部署」、每個分開的理由（引 S1–S3）、要補什麼
• 白話、詳細，給決策者討論用