資源篩選 (Resource Selection) Requirement
下游：Functional Spec resource-selection.fp.md → OOA ooa（草稿）→ 虛擬碼 pseudo（尚未建立） 性質：跨 feature 共用模組（Published Language，定位同 領域物件 domain-model）—— 被 粗排 rough-cut-scheduler 與 細排 fine-grain-schedule 共用消費 上游消費：本模組消費 產能模組 capacity-module 的資源（含獨立資源與單向限制關聯） 種子來源：細排 fine-grain-schedule #4 標記的「第 2 種匹配」新 feature 種子；本模組將範圍擴大為含第 1 種（能力匹配）的整個資源篩選職責 來源類型：內部 PO / 產品（Alan） | STD 通用 狀態：紀錄區（living doc）— 需求變更時追加素材並更新未解問題；不在此寫 Scope / Use Case / AC
Problem Statement
一句話。寫不出來就回去問。
內部 PO 要把粗排、細排都在用的「給一個 VSM 節點、找出有資格製造它的資源」這件事抽成一個共用模組，避免兩邊各自重造能力匹配，並在其上承載細排所需的人工指派限定。
Stakeholders
| 類型 | 對象 | 備註 |
|---|---|---|
| 需求提出方 | 內部 PO / 產品（Alan） | 產品架構規劃發起；對話中主動提出抽模組 |
| 受影響方 | 粗排引擎（既有消費方，已 coding）、細排引擎（消費方，規劃中）、產能模組（上游資源真相提供方）、現場（指派限定設定檔的實質維護者，待確認） | 粗排只用能力匹配層；細排兩層都用 |
| 決策方 | 內部 PO / 產品負責人 | 可拍板 scope —— Scope 本身在 Stage 2 才定 |
素材清單
每筆對應
raw/一個檔或一條連結。照實記，不要美化。
| # | 素材 | 來源（誰） | 日期（何時） | 為何提 | 簡述 |
|---|---|---|---|---|---|
| 1 | raw/2026-06-11-內部PO-資源篩選共用模組口述.md | 內部 PO / 產品（Alan） | 2026-06-11 | 產品架構規劃（釐清「匹配」+ 提案抽共用模組） | 釐清匹配分兩種（能力匹配／指派限定）、4 個 use case、4 種設定檔配對；提案抽成粗／細排共用的「資源篩選」模組；並答覆合成模型（指派優先、能力 fallback、韌性放行）、限制資源為獨立資源、VSMNode key、過不了門檻即 Exception。原話留存；分層／合成規則／設定檔 schema 屬 Stage 2 之後，不在此拍板 |
標籤 / 重複 / 矛盾
AI 主動標、人確認後寫入。
標籤： #資源篩選 #resourceSelection #能力匹配 #capabilityMatching #資源指派限定 #assignmentRestriction #限制資源 #稀缺資源 #模具 #操作人員 #換模技師 #單向限制關聯 #VSMNode #共用模組 #publishedLanguage #粗排消費 #細排消費 #產能模組 #韌性優先 #STD
狀態標籤： #未答 #部分釐清 #已釐清
重複 / 接力：
- 無重複素材（目前單一來源）。跨 feature 接力宣稱（非矛盾）：本模組的「能力匹配」即 粗排節拍點找機台 與 細排功能 3 自稱「同邏輯」者——本模組正是把該共用邏輯抽出落為單一真相。已定為共用同一機制（粗排只是最後產能表示方式不同；#12，呼應 細排 #6）。
- 指派限定層的配對 3、4（操作人員→機台、模具技師→模具）即 產能模組 #6 既有的「單向限制關聯」——本模組消費，非重新定義（#7）。
潛在張力（觀察點，非矛盾，留 Stage 2/3）：
- 合成模型採「指派優先、能力 fallback，即使能力不符也放行」（#3）——這違反「交集校驗」的直覺，是刻意的韌性設計，下游恐有人想「修正」回交集；須在 Stage 2 寫成明確 rationale 並守住。
- 〔已解〕本模組產出邊界已定為只到「已排序的合格資源序列」、不做任何產能計算（產能堆疊／CO 屬呼叫方細排）（#11）。
缺失：
- 〔已解〕指派限定「外部設定檔」的維護方式／格式先不納入本模組考量，只考慮內部結構（#10）。
- VSMNode 是否仍保留「工序」欄位（已確定工序不作篩選 key，但欄位是否存在於結構待確認）（#6 附帶）。
未解問題
AI 主動列、不裁決。每條：問題 + 來源 + 類型 + 建議找誰問。 狀態導航與其他文件以題號連結
[#N](#qN)連到各題（逐題錨由 build 注入）。
狀態導航
-
此模組的結構分幾層、各層職責為何？
- 來源：#1（一、二）
- 類型：含糊
- 建議找誰問：內部 PO + 架構
- 狀態：✅ 已釐清 #已釐清
- 答覆(2026-06-11，內部 Alan)：兩層 —— (1) 能力匹配：依 VSMNode 製程能力自動推導候選資源集；(2) 資源指派限定：人工外部設定檔在候選集上指定／限縮／排序，並掛限制資源門檻。
-
兩層如何合成出最終結果——是「能力候選 ∩ 指派集」的交集，還是有優先順序？
- 來源：#1（三-4）
- 類型：含糊（核心邏輯）
- 建議找誰問：內部 PO
- 狀態：✅ 已釐清 #已釐清
- 答覆(2026-06-11，內部 Alan)：覆寫式 cascade，非交集。有指派限定則以指派資源集為準（依指派優先序），即使能力不符也放行；無指派才用能力匹配候選集（fallback，依能力優先序）。理由：User 可能不顧資訊正確性強行指派，與其在資訊層阻擋，不如設計成放行以強化軟體韌性。限制資源門檻則正交套用於兩分支。
-
指派的資源連限制資源門檻都過不了（如指派 M5，但 M5 掛不起所需 MOLD1）時的行為？
- 來源：#1（四）
- 類型：缺失（例外邊界）
- 建議找誰問：內部 PO
- 狀態：✅ 已釐清 #已釐清
- 答覆(2026-06-11，內部 Alan)：這種程度的錯誤就該 Exception。前期（模組外）資料檢查會審視，所以模組內理論上不該出現空集合。
- 修訂(2026-06-11，Stage 2 拍板「甲」)：經 FS 展開，最終採指派一律韌性放行、不 throw（連「掛不起模具」也放行；現行模型亦無「機台↔模具」硬相容關聯）。Exception 僅保留在能力路徑（無指派）能力空集。原「過不了門檻＝Exception」由此收斂為「指派路徑無 Exception」。詳見 [spec §RS-FS-3/5](../../spec/resource-selection/resource-selection.fp.md)。
-
模具／操作人員／換模技師這些「限制資源」是新型別，還是？
- 來源：#1（一 use case + 三-1）
- 類型：含糊（與產能模組詞彙對齊）
- 建議找誰問：內部 PO + 架構
- 狀態：✅ 已釐清 #已釐清
- 答覆(2026-06-11，內部 Alan)：都是獨立的資源（同 [產能模組 §CAP-UR-10／§CAP-UR-1](../capacity-module/index.md)）；「限制」只是數量上相較稀缺、會成為門檻的語意，非新型別。
-
資源篩選的鍵（key）是什麼粒度？
- 來源：#1（三-2）
- 類型：含糊
- 建議找誰問：內部 PO + 架構
- 狀態：✅ 已釐清 #已釐清
- 答覆(2026-06-11，內部 Alan)：VSMNode = 料號 + 製程 + 工作站（工序不用看）→ 資源。
- 附帶待確認：工序不作篩選 key 已定；VSMNode 結構是否保留工序欄位——粗排 requirement 變更歷史 2026-06-09 已立詞彙慣例「工序 → 製程 → 工作站，工序為 VSMNode 專有、機台沒有」＝工序是 VSMNode 欄位、但非匹配維度，substance 已定。Stage 2 僅需把措辭與 [細排 §FGS-UR-5](../fine-grain-schedule/index.md#q5)「工序-製程-工作站節點」統一。
-
素材列的 4 種設定檔配對與產能模組既有的「限制關聯」是什麼關係？
-
粗排已抵達 coding 階段，這次怎麼處理它的能力匹配？
-
指派限定的「外部設定檔」格式為何、誰維護、怎麼維護（4 種配對如何落為資料）？
需求收斂結論
把這份紀錄「收斂到什麼」描述清楚，作為 Stage 2 的乾淨 input。 鐵則：每一點都回指素材
[#N](#素材清單)或已答未解問題[#N](#qN)；不寫 scope（做不做什麼）——那是 Stage 2。 全域碼：每條「已定向」結論行首掛§RS-UR-{N}（N＝其所解^qN的數字）。短名查 spec-codes.md。
核心需求：內部 PO 要把「給一個 VSMNode、找出有資格製造它的、已排序的資源序列」這個粗／細排共用的職責，抽成一個跨 feature 共用模組「資源篩選」（定位同 domain-model 的 Published Language），消費產能模組的資源真相，並承載細排所需的人工指派限定（#1、#1、#2、#8）。
已定向（關係人已答／已釐清）：
§RS-UR-1能力匹配抽成獨立共用模組，粗／細排共用（輸入皆 VSM + 資源），不重複造輪子（#1）§RS-UR-2模組分兩層：能力匹配（依製程能力自動推導候選集）+ 資源指派限定（外部設定檔指定／限縮／排序 + 限制資源門檻）（#2）§RS-UR-3合成採覆寫式 cascade（非交集）：有指派則指派為準（依指派優先序，能力不符也放行＝韌性優先），無指派則能力匹配 fallback；限制資源門檻正交套用（#3）§RS-UR-4指派路徑韌性放行：指派資源即使能力／耦合不符也保留、不 throw（2026-06-11 Stage 2 拍板「甲」，修訂原「過不了門檻＝Exception」）；Exception 僅發生在能力路徑（無指派）能力空集。模組外前期資料檢查負責資料正確性（#4）§RS-UR-5模具／操作人員／換模技師皆為獨立資源（同產能模組），「限制」僅指數量稀缺、會成門檻的語意，非新型別（#5）§RS-UR-6篩選 key ＝ VSMNode（料號 + 製程 + 工作站），工序不作 key（#6）§RS-UR-7設定檔配對 3、4（人員→機台、技師→模具）＝消費產能模組既有單向限制關聯；本模組新增的是配對 1、2（VSM→機台優先序、VSM→模具）的 VSM 層級指派及四者合成（#7）§RS-UR-8消費契約：細排用兩層、對每一 VSMNode 呼叫；粗排只用能力匹配層、僅在節拍點呼叫；模組對「餵哪些節點」中立（#8）§RS-UR-9粗排（已 coding）現階段只前向註記、不動 tag／code；未來小範圍重構走 mid-stage edit → audit → 重打 tag → code 跟進（#9）§RS-UR-10指派限定「外部設定檔」的維護方式／格式先不納入本模組考量；本模組只處理內部結構（使用者輸入與現實資料的併合在模組外）（#10）§RS-UR-11模組產出邊界＝只到「已排序的合格資源序列」、不做任何產能計算（產能堆疊／CO 屬呼叫方細排）（#11）§RS-UR-12能力匹配與粗排「節拍點找機台」是共用同一機制（差異僅在最後的產能表示方式）（#12）
仍待 Stage 2 拍板：
交棒：→ /functional-spec-partner，以本結論＋素材清單為 input 定 scope。
連帶下游（2026-06-11 已執行）：
- 細排 FGS §FGS-UR-4 已加註：第 2 種匹配的「另一支 spec」具體化為本模組；能力匹配改由本模組第 1 層提供（FGS 仍在 Stage 1，living doc 直接調整）。
- 粗排 RCS pseudo-code §7（eligibility）已加前向註記 + 變更歷史登記，未動 tag／code（見 #9）。
變更歷史
Living doc 追加段落，不覆寫。
- 2026-06-11（Stage 2 回饋）：Stage 2 FS 展開時，關係人就「指派門檻例外行為」拍板**「甲」——指派路徑一律韌性放行、不 throw**（連掛不起模具也放行；現行模型無機台↔模具硬相容關聯），Exception 僅保留能力路徑能力空集。修訂
§RS-UR-4（原「過不了門檻＝Exception」）並於 q4 補修訂註記。此為 Stage 2 對既有 UR 結論的回頭收斂，FS（§RS-FS-3/5）與 validate script 已同步；屬 living-doc 追加、不重編號。 - 2026-06-11（同日續）：關係人（內部 Alan）就 C 路徑回答 q10／q11／q12，三條轉已定向（掛
§RS-UR-10／11／12）：q10 外部設定檔維護先不納入考量、本模組只處理內部結構；q11 產出邊界＝只到已排序合格資源序列、不做任何產能計算；q12 與粗排「節拍點找機台」共用同一機制（差異僅最後產能表示方式）。狀態導航更新為 ✅12／🟡0／未答0；收斂結論「已定向」增至 12 點、「仍待 Stage 2」僅剩 q6 附帶（工序欄位是否保留）。潛在張力中「產出邊界」已解，保留「韌性放行 vs 交集直覺」為 Stage 2 守則。連帶下游（FGS §FGS-UR-4 轉指、粗排 §7 前向註記）已執行。Exit Gate 仍滿足。 - 2026-06-11：初版。登記全域短碼
RS（跨 feature 共用，見 spec-codes.md）。素材 #1 入庫（內部 Alan 口述：釐清匹配兩種 + 提案抽共用模組 + 4 項答覆 + 邊界）。源自 細排 #4 標記的「第 2 種匹配」種子，範圍擴大為含能力匹配的整個資源篩選職責。列 12 條未解問題，9 條已定向（q1–q9，掛§RS-UR-1…9）、3 條開放（q10 設定檔維護 #未答、q11 產出邊界、q12 共用機制 #部分釐清），另 q6 附帶「工序欄位是否保留」待 Stage 2 對齊措辭。標記兩處跨 feature 接力（能力匹配＝粗/細排同邏輯抽出、配對 3/4＝消費產能模組限制關聯）與兩處潛在張力（韌性放行 vs 交集直覺、產出邊界 vs 細排堆疊）。Exit Gate 五條滿足，可交棒 Stage 2。