粗排引擎 (Rough-Cut Scheduler) Requirement
下游：Functional Spec rough-cut-scheduler.fp.md → OOA ooa → 虛擬碼 pseudo 來源類型：內部 PO / 產品 | STD 通用 狀態：紀錄區（living doc）— 需求變更時追加素材並更新未解問題；不在此寫 Scope / Use Case / AC
Problem Statement
一句話。寫不出來就回去問。
內部 PO 想要一個可快速拉動的粗排引擎，讓產銷協調能即時評估交期（何時能交、某日期能否交），並同時作為細排引擎的 input——藉此避免把排程做成一顆大而難維護的單體引擎。
Stakeholders
| 類型 | 對象 | 備註 |
|---|---|---|
| 需求提出方 | 內部 PO / 產品 | 產品架構規劃發起 |
| 受影響方 | 產銷協調人員（業務 / PMC）、細排引擎（下游消費方） | 產銷協調為互動使用者；細排引擎為程式消費方 |
| 決策方 | 內部 PO / 產品負責人 | 可拍板 scope —— Scope 本身在 Stage 2 才定 |
素材清單
每筆對應
raw/一個檔或一條連結。照實記，不要美化。
| # | 素材 | 來源（誰） | 日期（何時） | 為何提 | 簡述 |
|---|---|---|---|---|---|
| 1 | raw/2026-06-01-內部PO-粗排引擎需求口述.md | 內部 PO / 產品 | 2026-06-01 | 產品架構規劃 | 粗排引擎兩個目標（產銷協調快速評估、細排 input）+ 反單體引擎的設計哲學 |
| 2 | raw/2026-06-01-內部PO-粗排模組邏輯說明.md | 內部 PO / 產品 | 2026-06-01 | 同場會議進展到說明邏輯 | 粗排模組大致邏輯（VSM／節拍點拉動推動／有限產能堆疊／LSD／LeanPlay 交期／投產順序）。原話留存，演算法本身屬 Stage 2/3/4，不在此拍板 |
| 3 | raw/2026-06-01-內部小會議-x-y參數來源決策.md | 內部小會議（Alan 轉述） | 2026-06-01 | 釐清 x/y 參數來源 | 拉動／推動 x、y 參數來源收斂為設定檔三方案（CT×數量+CO／CT×數量／生管固定天數）。尚未拍板選定，對應未解問題 #9 |
| 4 | raw/2026-06-03-內部會議-節拍點安排與三輸出價值.md | 內部會議（PO / 產品） | 2026-06-03 | 釐清節拍點安排主流程與三輸出價值 | 粗排主流程：投產單預計交期為 input；三輸出計算方向——LeanPlay 交期（自起排日正推、節拍點產能不足則順延）→ LSD（自交期反推）→ 投產順序（依 LeanPlay 交期排序）；含 D1/D2 概念範例與三輸出各自的價值（倒敘）。原話留存，計算方向／演算法屬 Stage 2/3/4，input/output 制訂亦屬 Stage 2，不在此拍板 |
| 5 | raw/2026-06-08-內部PO-節拍點資源適用性.md | 內部 PO / 產品（與 AI 討論時揭露） | 2026-06-08 | 揭露先前未記錄的領域事實 | 節拍點的「製程-工作站」（如 LASR-L）底下對應多台實體機台（LA01／LA02），佔產能時須找「時間足夠且符合製程-工作站的資源」；衍生情境：PartB 只能上 LA02，無法用「總產能」解釋（eligibility 限制）。原話留存；衍生 use case 屬 Stage 2，不在此展開 |
標籤 / 重複 / 矛盾
AI 主動標、人確認後寫入。
標籤： #粗排 #排程引擎 #產銷協調 #細排input #引擎拆解 #STD #VSM #節拍點takt #LSD #LeanPlay交期 #拉動推動 #有限產能 #投產順序 #CT #CO換線 #ERP #可用產能 #排擠逾期 #Freeze #投產單預計交期 #起排日 #集批 #leadtime
狀態標籤： #未答 #部分釐清 #已釐清
重複：
- 無（目前僅單一來源素材）
矛盾：
- 無明確矛盾。潛在張力（觀察點，非矛盾）：需求二主張「避免大型單體引擎」，但粗排引擎同時服務兩種 case（產銷協調 + 細排 input）——需留意它本身不要演化成共用大引擎。此為設計層討論，留待 Stage 2/3。
缺失：
- 「快速」未定義量級與回應時間（已列入未解問題 #1）
- 粗排時間顆粒度未定義（已列入未解問題 #2）
- 粗排作為細排 input 的交付格式 / 介面未定義（已列入未解問題 #3）
- 評估是否鎖定 / 佔用產能未提（已列入未解問題 #5）
- 節拍點「製程-工作站」底下的**多機台 + 資源適用性（eligibility）**先前未記錄；2026-06-08 由素材 #5 揭露（已列入未解問題 #17）
補充：素材 #2 已部分揭露輸入資料（VSM＝工單＋製程樹、資源產能、交期、Freeze 的看板產能），原未解問題 #4 改為「部分釐清，待完整盤點」（見下）。素材 #2 自身也帶出多個 PO 標註的不確定點（節拍點站別模糊、x/y 參數來源、交期早於當日、LeanPlay 交期落差），已列為 #8–#12。
補充（素材 #4，2026-06-03）：粗排主流程更細地揭露三輸出的計算方向（LeanPlay 交期正推、LSD 反推、投產順序依 LeanPlay 交期排序）並補上各輸出的價值（倒敘理由）。由此浮現四個新的不確定點，列為 #13–#16（LSD 反推是否看產能、起排日定義與 +1、投產順序與產能堆疊的順序依賴、LSD 是否足以支撐集批控制）。注意：input/output 的「制訂」屬 Stage 2 任務，本階段只原話留存、不拍板。
未解問題
AI 主動列、不裁決。每條：問題 + 來源 + 類型 + 建議找誰問。
狀態導航
-
「快速評估」的量級與回應時間未定義——產銷協調是互動情境，要求秒級回應嗎？要處理多少工單 / 多大產能範圍？
- 來源：#1（需求一）
- 類型：含糊
- 建議找誰問：內部 PO + 產銷協調實際使用者
- 狀態：🟡 部分釐清（回應時間已定；「範圍」連動 #12 Freeze） #部分釐清
- 答覆(2026-06-02，內部 Alan)：這裡的快速評估是指，排程階段只有節拍點考慮產能，因此，以現在硬體的基礎，基本上排程個能在1分鐘以內跑玩的過程。至於範圍，我認為這是一個”參數”，因為需要端看現場限定多久的產能無法更動，例如，已經上料的不能撤下，已經買料在線邊的無法更換…等等，因此這部分，應該可以交給生管決定。
- 釐清：回應時間 = 1 分鐘以內（因排程僅節拍點考慮產能）。「範圍/量級」轉為一個由生管決定的產能凍結參數 → 與 #12（Freeze 時間範圍） 為同一件事，併該題追。
-
粗排引擎的輸入資料——需要哪些資料才能評估？
- 來源：#1（全篇未提）；#2 部分揭露
- 類型：缺失（部分釐清）
- 已知（來自 #2） ：VSM（工單＋工單製程建立的製程樹，包含所需要製造的數量 以及 所需物料） 、各VSM 的 Leadtime/VSM 參數、資源產能、投產單交期、Freeze 的看板產能
- 仍待釐清：是否需要 BOM、行事曆/班別、換線、物料到料等；以上是否齊全
- 建議找誰問：內部 PO
- 狀態：🟡 部分釐清（輸入大致收斂；「是否齊全」待 Stage 2 盤點） #部分釐清
- 答覆(2026-06-02，內部 Alan)：
- 釐清：BOM 併入 VSM、行事曆/班別併入「可用產能」、到料功能初期 scope out（只保留「需要哪些料」）。
- 註：「換線」即 CO（Changeover，換線/換模整備時間）——見素材 #3 與 #9 ，已被 x/y 參數方案涵蓋，非新輸入。
-
「評估」是否會真實佔用 / 鎖定產能（落地影響後續排程），還是純試算不落地？「確認影響」一詞語意待釐清。
-
兩個使用情境（產銷協調工具、細排 input）是「同一顆引擎、同一邏輯」，還是「同一引擎、不同入口 / 參數」？
- 來源：#1（需求二 兩個 case）
- 類型：含糊
- 建議找誰問：內部 PO
- 狀態：✅ 已釐清 #已釐清
- 答覆(2026-06-02，內部 Alan)：同一引擎、不同入口 / 參數。
- 釐清：以「同引擎 + 參數化入口」服務兩情境，同時化解「矛盾」段的潛在張力（避免演化成共用大引擎）。
-
需求二的「依 User 實際操作拆解每種引擎不同目標」是一套導入方法論 / 拆解策略——具體要拆成哪些引擎、以什麼準則拆，尚未定義。
-
節拍點的「站」定義存在模糊空間——節拍點實為「一站」（站＝工作站＋製程），但生管認知模糊（如「折床站」可能含多個製程）。如何建立「容許模糊空間的 VSM」是後續重點；目前先只考慮「單一工作站＋製程」。
-
拉動／推動的 x、y 參數來源未定——PO 說「應該符合 VSM 內參數就好」，但「可能」就是生管給固定天數。到底以 VSM 參數為準，還是生管給的固定天數？
- 來源：#2（步驟 1.4，語氣本身不確定）；#3（6/1 小會議決策）
- 類型：含糊
- 建議找誰問：內部 PO + 生管
- 狀態：🟡 部分釐清（收斂成設定檔三方案，未拍板選定） #部分釐清
- 答覆(2026-06-02，內部 Alan)：這個有根據昨天 6/1 再開的小會議有決策，這部分應該是建議有個設定檔
- 釐清：方案收斂為設定檔三選項（見素材 #3 ） 。殘留：① 三選項採用哪一個未拍板；② 方案 3「固定天數如何給」未知。CO = 換線（呼應 #4）。
- 答覆(2026-06-04，內部 Alan)：三種都有可能，所以在計算前，要考慮當前是用哪一種策略!
- 釐清（更新）：① 已定向——三方案並存為可選策略，不單選；計算前需依「當前策略」決定算法（典型 Strategy 樣式，留待 Stage 3 設計）。② 殘留——方案 3「固定天數如何給」仍未知，故維持 🟡。
-
交期早於當日的工單如何處理——PO 把問題重構為：「這張單的交期要什麼時候才比較好？是否取決於投產順序？」
-
LeanPlay 交期 與 生管期待交期 不一致時如何處理／如何呈現——PO 指出兩者「可能不一樣」，但未說落差怎麼辦（是回饋、協商、還是以哪個為準）。
- 來源：#2（步驟 2.7）；#4（三輸出價值：LeanPlay 交期供業務／生管「得出這張單可能的交期與多少影響」）
- 類型：缺失
- 建議找誰問：內部 PO + 生管
- 狀態：✅ 已釐清 #已釐清
- 註（2026-06-03，素材 #4）：6/03 釐清此落差的用途是供業務／生管「評估交期與影響」；但「如何呈現／以哪個為準」仍未答。
- 答覆(2026-06-04，內部 Alan)：我們就是忠實呈現，怎麼反應是給客戶決定，屆時就是UI與報表的議題。
- 釐清：粗排忠實呈現 LeanPlay 交期與生管期待交期兩者、不替客戶決定；如何反應由客戶決定，呈現方式屬後續 UI／報表議題（不在粗排引擎核心 scope）。
-
排單前 Freeze 的「時間範圍」如何決定——PO 提到排單前會把「一個時間範圍內」的看板 Freeze 當初始產能規劃，但範圍長度與決定方式未定義。
-
LSD 反推是否考慮節拍點產能——LeanPlay 交期正推時節拍點產能不足會順延（看產能）；但 LSD 從投產單預計交期反推，範例僅逐站扣 leadtime、未見產能檢查。LSD 是否為「純 leadtime 反推、不看產能」？「正推看產能、反推不看」這個不對稱是否如此／是否正確？
-
「起排日」的定義與「+1」的基準——LeanPlay 交期正推從「起排日 +1」起算，但起排日是否＝排單日當天（範例中 6/3）？為何要 +1（排單日不可投產？換日邊界？）？
- 來源：#4（計算流程 1 步驟 1）
- 類型：含糊
- 建議找誰問：內部 PO
- 狀態：✅ 已釐清 #已釐清
- 答覆(2026-06-04，內部 Alan)：正常來說，這個作為一個參數保留，預設就是今天+1 。
- 釐清：起排日（正推起點）為可調參數，預設＝今天 +1。
-
投產順序與有限產能堆疊的順序依賴——投產順序「依 LeanPlay 交期排序」得出；但 LeanPlay 交期的正推有限產能堆疊本身又依賴「先處理哪張單先佔產能」。那麼正推時的初始處理順序以什麼為基準（投產單預計交期？投產單號？其他）？此為排序的先後相依問題。
-
LSD 是否足以支撐「集批控制」——LSD 的價值被描述為告訴細排／現場主管「不要集批太多，在此時間前可集批／打亂順序較不影響後續」。粗排是否只需輸出單一 LSD 日期即足以支撐此判斷，還是需要額外輸出（如容忍窗、可集批區間）？「集批」是 6/03 新出現、先前未記錄的關係人概念。
-
節拍點的「製程-工作站」底下對應多台實體機台，且零件對機台有適用性（eligibility）限制——粗排佔產能時是否／如何納入此限制？「總產能」無法表達「PartB 只能上 LA02」。
- 來源：#5（使用者揭露的排程過程 + 衍生情境）
- 類型：缺失（先前未記錄的領域事實）
- 建議找誰問：內部 PO + 生管 + 現場（確認機台適用性的實際維度與資料來源）
- 狀態：✅ 已釐清（領域事實與本期 scope 已定；機台分配精度與純機台硬綁屬下游階段，非 Stage 1 未決） #已釐清
- 與 #8 的關係：#8 處理節拍點「站」的定義（單一工作站-製程）；#17 是其內層問題——該工作站-製程底下是單台或多台機台、零件/工單是否綁定特定機台。兩者不衝突，#17 在 #8 範圍內更細一層。
- 答覆(2026-06-09，內部 Alan)：以一個 use case 釐清機制——
- 設 LA01 工作能力＝LASR-L；LA02 工作能力＝LASR-L、LASR-L2（LA02 能力涵蓋 LA01）。
- VSMNode1（PartA / LASR-L）matching 到 {LA01, LA02}；VSMNode2（PartB / LASR-L2）只 matching 到 {LA02}。
- 「PartB 只能上 LA02」是製程-工作站 matching 自然長出的結果（LA02 多一個製程能力），非外掛機台綁定。
- 粗排不指派實際機台／時段，但每個 VSMNode 的可用產能視野＝其 eligible 機台的產能聚合、隨可用機台變動（此即 C 方案）。
- 詞彙優先順序：描述 VSMNode 或機台能力時依 工序 → 製程 → 工作站；工序為 VSMNode 專有、機台沒有，故 VSMNode↔機台 的 matching 落在製程-工作站。
- 釐清（子點收斂）：
- 延後／下游（標記、不拍板）：
- 純機台硬綁（兩台能力全同仍要綁特定台）＝後續階段。
- 共用機台（如 LA02）爭用：純池扣減在共用機台上有精度殘差，是否做到機台分配屬 Stage 3。
- blast radius：本期確認
ooa/domain-model.md「產能鍵＝工作站×日」需下沉到資源（機台）×日 + 需求端 VSMNode 帶「eligible 機台集合」（屬 Stage 3；與capacity-module資源-時間模型對齊）。
需求收斂結論
把這份紀錄「收斂到什麼」描述清楚，作為 Stage 2 的乾淨 input。 鐵則：每一點都回指素材
[#N](#素材清單)或已答未解問題[#N](#qN)；不寫 scope（做不做什麼）——那是 Stage 2。
核心需求：內部 PO 要一個可快速拉動的粗排引擎，同時服務兩種情境——讓產銷協調能即時評估交期（何時能交、某日期能否交），並作為**細排引擎的 input**；背後的設計哲學是避免把排程做成一顆大而難維護的單體引擎（#1、#2）。
已定向（關係人已答／已釐清）：
§RCS-UR-1排程回應時間 < 1 分鐘——因排程階段只有節拍點考慮產能（#1）§RCS-UR-2粗排顆粒度到「天」（#2）§RCS-UR-3粗排結果＝為每個 VSM 節點標記 LSD、LeanPlay 預計完工、投產順序；細排引擎將整包當其一 input（#3）§RCS-UR-6兩情境採同一引擎、不同入口／參數——同時化解「演化成共用大引擎」的潛在張力（#6，呼應 矛盾段）§RCS-UR-4輸入大致收斂：VSM（工單＋製程樹＋數量＋所需物料，BOM 已含於 VSM）、可用產能（已含行事曆／班別）、投產單交期、外部決定的 Freeze 看板產能；關係人已表態到料排程初期不納入，只保留「需要哪些料」（#4）§RCS-UR-8節拍點＝單一「工作站-製程」；未來前端再提供多種設定方式（「模糊空間 VSM」延後）（#8）§RCS-UR-5「確認影響」語意收斂為判定逾期或排擠（#5）§RCS-UR-10逾期投產單容忍處理：不期望逾期投產單進入；若進入，LSD 計算無意義但影響小，不特別處理（#10）§RCS-UR-18三輸出各有明確用途（關係人於 6/03 說明）：LeanPlay 交期＋投產順序＝供生管／現場可依循、且符合生管投產方式的製造依據，並供業務／生管評估單子可能交期與影響；LSD＝標示「不在此前投產必逾期」的界線，供細排／現場主管判斷集批與打亂生產順序的容忍邊界（#4）§RCS-UR-13LSD 反推不看產能：LSD 純逐站扣 leadtime；確認「正推（LeanPlay 交期）看產能、反推（LSD）不看」的不對稱即為本意（#13）§RCS-UR-14起排日為參數、預設＝今天 +1（正推起點）（#14）§RCS-UR-15正推初始處理順序＝投產單進入順序，由投產單物件的prioritySeq決定；此「輸入處理順序」與「輸出投產順序（依 LeanPlay 交期排序）」為兩個不同概念（#15）§RCS-UR-16粗排不支援集批控制：LSD 是以工廠最壞情況排出的單一日期，不額外輸出容忍窗；集批判斷交由細排／現場依此日期自行決定（#16）§RCS-UR-11LeanPlay 交期 vs 生管期待交期落差＝忠實呈現兩者、不替客戶決定；如何反應由客戶決定，呈現方式屬後續 UI／報表議題（#11）§RCS-UR-9x／y 參數三方案並存為可選策略：不單選，計算前依「當前策略」決定算法（Strategy；方案 3「固定天數如何給」仍待補）（#9）§RCS-UR-7多引擎拆解策略暫緩：當前優先把粗排模組的 Input／Output／Process 處理好（#7）§RCS-UR-17節拍點 eligibility 採 C 方案：以「製程-工作站」對機台工作能力 matching 算出各 VSMNode 的 eligible 機台，可用產能視野隨 eligible 機台變動並納入粗排；產能承載下沉至資源（機台）×日（與capacity-module資源-時間模型對齊、經轉換器投影）；能力相同下的純機台硬綁延後、粗排不指派實際機台／時段（#17、#5）
仍待 Stage 2 拍板：
- 粗排 input／output 的「制訂」（要收哪些輸入欄位、輸出何種介面／欄位）——關係人明確表示此制訂工作放到 Stage 2，且為當前優先（#4、#7，呼應 #3、#4）
- 評估是否真實寫回／鎖定產能（落地）還是純試算——尚未直接回答（#5）
- x／y 三策略中**方案 3「固定天數如何給」**未知（#9）
- Freeze 時間範圍的具體長度與決定規則未定（方向：由生管決定）（#12）
- 輸入清單是否齊全待 Stage 2 完整盤點（#4）
交棒：→ /functional-spec-partner，以本結論 + 素材清單為 input 定 scope。
變更歷史
Living doc 追加段落，不覆寫。
- 2026-06-01：初版（素材 #1 入庫；列出 7 條未解問題）
- 2026-06-01：同場會議進展，追加素材 #2（粗排模組邏輯說明，原狀留存） ；未解問題新增 #8–#12（節拍點站別模糊、x/y 參數來源、交期早於當日、LeanPlay 交期落差、Freeze 範圍）；#4 因 #2 部分揭露輸入資料而更新為「部分釐清」
- 2026-06-02：Alan 回覆 #1–#6、#8、#9、#10 未解問題；追加素材 #3（6/1 小會議 x/y 參數三方案）。狀態收斂：✅ 已釐清 #2、#3、#6、#8、#10；🟡 部分釐清 #1、#4、#5、#9、#12；⬜ 未答 #7、#11。修正編號重複（原誤植兩個 #9／#10，回正為 #8–#12）。釐清「換線=CO」。補標籤 CT/CO/ERP/可用產能/排擠/Freeze
- 2026-06-02：為未解問題 12 條加扁平狀態標籤（#未答／#部分釐清／#已釐清）並於區塊頂部新增狀態導航圖例，供 Obsidian 點 tag 過濾；於「標籤」區登記狀態標籤族。未改題目內容與編號。
- 2026-06-03：套用全 repo Obsidian 導航慣例（見 workflow 文件 §可追溯性）。breadcrumb 改 markdown 連結；12 條未解問題各加
^qNblock-id；狀態導航圖例升級為[!info]callout 並把編號改為[#N](#qN)可點跳轉；素材引用改[素材清單](#素材清單)。純文字編號#N不再當作 tag（Obsidian 規定 tag 不可純數字）。未改題目內容與編號。 - 2026-06-04：新增「需求收斂結論」段（套用本次模板更新），把 12 條未解問題的收斂狀態壓成「已定向／仍待 Stage 2 拍板」兩欄、每點回指
^qN／素材，作為 Stage 2 的乾淨 input 與下游回指錨點。此段是對既有紀錄的收斂、未引入新 user need，不改變下游、不觸發 consistency-audit。 - 2026-06-04：記錄 2026-06-03 粗排會議內容，追加素材 #4（節拍點安排主流程與三輸出價值，原狀留存）。新增未解問題 #13–#16（LSD 反推是否看產能、起排日定義與 +1、投產順序與產能堆疊的順序依賴、LSD 是否足以支撐集批控制），皆 ⬜ 未答；#11 補上素材 #4 線索（用途已釐清、呈現方式仍未答）。收斂結論「已定向」加入三輸出用途、「仍待 Stage 2」加入 input/output 制訂與 #13–#16。補標籤 投產單預計交期／起排日／集批／leadtime。提醒：下游
functional-spec/rough-cut-scheduler.md已存在；本次素材深化了引擎主流程與輸出語意，Stage 2 應回看 spec 是否需更新（屬 mid-stage edit，簽核前跑consistency-audit）。 - 2026-06-04：Alan 回覆 #7、#9、#11、#13、#14、#15、#16。狀態收斂：✅ 已釐清 #7（拆解策略暫緩、聚焦粗排 I/O/Process）、#11（忠實呈現、反應由客戶決定→UI/報表）、#13（LSD 反推不看產能）、#14（起排日為參數、預設今天+1）、#15（正推初始順序＝投產單
prioritySeq，與輸出投產順序為兩概念）、#16（不支援集批、LSD 為最壞情況單一日期）；#9 仍 🟡（三方案並存為可選策略已定向，殘留方案3「固定天數如何給」）。⬜ 未答清空。收斂結論同步把 #7、#9、#11、#13–#16 移入「已定向」，「仍待 Stage 2」精簡為：input/output 制訂（當前優先）、寫回/鎖定產能（#5）、方案3固定天數（#9）、Freeze 範圍（#12）、輸入清單是否齊全（#4）。引入新領域欄位prioritySeq（投產單物件，#15）供 Stage 2 起 Use Case 時使用。 - 2026-06-08：追加素材 #5（與 AI 討論粗排產能 overlay 時，使用者揭露先前未記錄的領域事實——節拍點「製程-工作站」底下對應多台實體機台 LA01／LA02，且存在零件對機台的適用性限制：PartB 只能上 LA02，「總產能」無法表達）。新增未解問題 #17（⬜ 未答），含三個子點（適用性的鍵/維度、資料來源、此期是否納入＝Stage 2 scope）；#17 標明與 #8 的內外層關係，及對下游
ooa/domain-model.md「工作站×日」產能鍵的 blast radius（屬 Stage 3，不拍板）。收斂結論「仍待 Stage 2 拍板」加入 #17。此為新揭露的 user need，循 Path A（top-down cascade）：Stage 1 留底 → Stage 2 定 scope → 視結論再動 domain-model／pseudo；本階段不拍 scope、不展 use case。 - 2026-06-09：回答未解問題 #17（節拍點機台適用性）。關係人以 use case 釐清機制——eligibility 由「製程-工作站對機台工作能力 matching」自然長出（機台能力可有涵蓋差，如 LA02⊃LA01；PartB 走 LASR-L2 故只 match LA02），非外掛機台綁定；本期採 C 方案（產能視野隨 eligible 機台變動、納入粗排，產能承載下沉至資源（機台）×日、與 capacity-module 對齊），純機台硬綁與機台分配精度延後（Stage 2 scope／Stage 3 設計）。補詞彙慣例「工序 → 製程 → 工作站，工序為 VSMNode 專有、機台沒有」。#17 狀態 ⬜→✅；收斂結論將 #17 由「仍待 Stage 2」移入「已定向」；重新標上
ooa/domain-model.md「工作站×日 → 資源（機台）×日」blast radius（屬 Stage 3，前一輪曾誤撤、本次回復）。raw 追加 2026-06-09 補充原話。仍循 Path A：scope 方向已定，正式 scope 於 Stage 2 落地，下游 domain-model／spec 視 Stage 2 結論再動。 - 2026-06-11：因新開跨 feature 共用模組 資源篩選 resource-selection（
RS），於pseudo-code/rough-cut-scheduler.md§7（eligibility）加前向註記——本節能力匹配（製程-工作站找資源）未來抽出、委派 RS 第 1 層，與細排共用同一機制（RS [§RS-UR-8](../resource-selection/index.md#q8)／[§RS-UR-9](../resource-selection/index.md#q9)／[§RS-UR-12](../resource-selection/index.md#q12)）。僅附加說明，未改任何 § 編號／行為、未動 spec tag 與 code、未重新簽核；真正重構時才走 mid-stage edit →consistency-audit→ 重打rough-cut-scheduler/spec-vN+1→ code 跟進。屬登記性質、不觸發本輪 audit。