細排引擎 (Fine-Grain Schedule) Requirement
下游：Functional Spec fine-grain-schedule.fp.md（尚未建立）→ OOA ooa（尚未建立）→ 虛擬碼 pseudo（尚未建立） 上游消費：本 feature 消費 粗排 rough-cut-scheduler 的投產順序輸出，與 產能模組 capacity-module 的資源-時間真相 來源類型：內部 PO / 產品（Alan） | STD 通用 狀態：紀錄區（living doc）— 需求變更時追加素材並更新未解問題；不在此寫 Scope / Use Case / AC
Problem Statement
一句話。寫不出來就回去問。
內部 PO 要一個**細排引擎**：吃粗排的投產順序與產能模組的資源-時間真相，以自然時間為節拍，把 VSM 真正排到「哪些資源、什麼時間製造」，產出給現場執行的命令（而非粗排那種參考）。
Stakeholders
| 類型 | 對象 | 備註 |
|---|---|---|
| 需求提出方 | 內部 PO / 產品（Alan） | 產品架構規劃發起 |
| 受影響方 | 現場製造單位（執行排程命令者）、生管、粗排引擎（上游 input 提供方）、產能模組（上游資源真相提供方） | 現場為命令的執行者；粗排／產能模組為程式上游 |
| 決策方 | 內部 PO / 產品負責人 | 可拍板 scope —— Scope 本身在 Stage 2 才定 |
素材清單
每筆對應
raw/一個檔或一條連結。照實記，不要美化。
| # | 素材 | 來源（誰） | 日期（何時） | 為何提 | 簡述 |
|---|---|---|---|---|---|
| 1 | raw/2026-06-10-內部PO-細排功能口述.md | 內部 PO / 產品（Alan） | 2026-06-10 | 產品架構規劃（細排功能輪廓） | 細排目的＝排出 VSM 用哪些資源／何時製造、給現場執行命令；四項內部功能：推式排單、SlidingWindow（自然時間節拍迴圈 + deadline）、匹配資源（VSM 製程-工作站找資源，自稱與粗排節拍點找機台同邏輯）、產能堆疊（自稱與粗排節拍點堆疊同邏輯）。原話留存；演算法／流程展開屬 Stage 2 之後，不在此拍板 |
標籤 / 重複 / 矛盾
AI 主動標、人確認後寫入。
標籤： #細排 #fineGrainSchedule #排程引擎 #推式排單 #SlidingWindow #自然時間節拍 #deadline #匹配資源 #產能堆疊 #VSM #製程工作站 #投產順序 #粗排input #產能模組 #資源時間 #現場命令 #節拍生產 #STD
狀態標籤： #未答 #部分釐清 #已釐清
重複 / 接力：
- 無重複素材（目前單一來源）。跨 feature 接力宣稱（非矛盾，待 Stage 2/3 確認）：素材 #1 功能 3、4 自稱「匹配資源」「產能堆疊」與粗排節拍點邏輯一樣——這是與 粗排 的復用宣稱。是否真共用、共用到哪（同概念 vs 同機制），屬 Stage 2/3 判斷，列入未解問題 #4、#6。
潛在張力（觀察點，非矛盾，留 Stage 2/3）：
- 細排要排到「用哪些資源」＝需指派到實際資源／機台；但粗排 #17 採 C 方案刻意不指派實際機台、把「機台分配精度／純機台硬綁」延後。細排正是接手粗排延後段的候選——這個接力邊界須 Stage 2 釐清（#4）。
- 細排定位為「命令（而非參考）」——是否代表結果落地佔用／鎖定真實產能？呼應粗排 #5「純試算 vs 寫回產能」尚未直接回答的殘留（#10）。
缺失：
- SlidingWindow 的 window size 與 deadline 量級／是否參數化未定（#1）
- 推式排單遇「當前 window 無可用資源」與「deadline 抵達 exception」的行為未定（#2、#3）
- 細排匹配的對象範圍（每個製程節點 vs 僅節拍點）、輸出時間精度、完整 input、是否消費 LSD/LeanPlay、CO 換線是否精算——均未定（#5、#7、#8、#9、#11）
未解問題
AI 主動列、不裁決。每條：問題 + 來源 + 類型 + 建議找誰問。 狀態導航與其他文件以題號連結
[#N](#qN)連到各題（逐題錨由 build 注入）。
狀態導航
-
SlidingWindow 的 window size（範例 2hr）與 deadline（範例一年）是固定值、可調參數、還是依現場／VSM 決定？「2hr／一年」是真實預設還是僅舉例？
- 來源：#1（功能 2）
- 類型：含糊
- 建議找誰問：內部 PO + 生管
- 狀態：✅ 已釐清 #已釐清
- 答覆(2026-06-10，內部 Alan)：參數化，但預設可以2hr + 一年。
-
推式排單依投產順序排單，當某 VSM 在當前 window 找不到可用資源時行為為何——順延到下一個 window？還是跳過、先排後面的單？換言之投產順序是硬約束（嚴格依序、前單未排則後單不得插隊）還是軟性參考？
- 來源：#1（功能 1、2）
- 類型：缺失
- 建議找誰問：內部 PO + 生管
- 狀態：✅ 已釐清 #已釐清
- 答覆(2026-06-10，內部 Alan)：順延到下一個 window。
-
deadline 抵達（你稱「一種 exception」）後的行為是什麼——報錯中止？產出「已排部分 + 未排清單」？整批視為失敗？此與粗排 #10 的「逾期投產單容忍」是不同層級的事。
- 來源：#1（功能 2）
- 類型：缺失
- 建議找誰問：內部 PO
- 狀態：🟡 部分釐清 #部分釐清
- 答覆(2026-06-10，內部 Alan)：有趣的議題，我認為先用整批失敗進行，但我不排除產出「已排部分 + 未排清單」，但這部分太模糊了，先擱置。
-
細排「匹配資源」要排出「用哪些資源」＝需指派到實際機台／資源；但粗排 #17 採 C 方案不指派實際機台、把「機台分配精度／純機台硬綁」延後。細排是否就是接手粗排延後的這段（做到實際機台指派 + 純機台硬綁）？接力邊界落在哪？
-
細排匹配／堆疊的對象是 VSM 的每一個「製程-工作站」節點，還是只有粗排認定的**節拍點**？（粗排只在節拍點看產能；細排「真正排出」是否要對 VSM 全部製程節點都匹配資源並佔產能）
-
「產能堆疊跟粗排節拍點堆疊邏輯一樣」——但粗排堆在「資源（機台）× 日」聚合視野，細排是「資源 × 時間區段（如 2hr window）」（呼應產能模組 #7「資源×時間區段」本質鍵）。鍵與單位不同，「一樣」指概念一樣還是要共用同一套堆疊機制？
-
細排輸出的時間精度到哪——到 window（如 2hr）、到分鐘、還是到實際起訖時段？「什麼時間製造」這個命令的時間粒度是？（粗排到「天」；細排明顯更細，但細到什麼程度未定）
- 來源：#1（功能 2 + 整體目的）
- 類型：含糊
- 建議找誰問：內部 PO + 現場
- 狀態：✅ 已釐清 #已釐清
- 答覆(2026-06-10，內部 Alan)：秒。所以內部的產能可能要用 Range<Long>
-
細排的完整 input 還有哪些——已知：粗排投產順序（投產順序 vsm）、產能模組資源-時間。是否還需要 VSM 製程樹本身、CO 換線時間、物料、Freeze 看板產能等？（對照粗排 input：VSM／可用產能／交期／Freeze）
-
細排消費粗排三輸出的哪些——你只提到「投產順序」。粗排另兩輸出 LSD（以工廠最壞情況排出的單一逾期界線）與 LeanPlay 交期 是否也作為細排的約束／檢查（如不得晚於 LSD），還是細排只吃投產順序、其餘不看？
-
「給現場執行的命令（而非參考）」是否代表細排結果會落地佔用／鎖定真實產能（寫回產能模組、鎖定資源時段），而非如粗排般純試算？此呼應粗排 #5「純試算 vs 寫回／鎖定產能」尚未直接回答的殘留。
-
CO 換線整備在細排如何納入——匹配到實際機台後，模治具／換模技師（產能模組 #1 為獨立資源、CO 量由
DataBox.changeOverTime推算）是否在細排堆疊產能時精算佔用？（粗排用 x/y 參數的 CT×數量+CO 概略；細排排到實際資源是否要精算 CO）
需求收斂結論
把這份紀錄「收斂到什麼」描述清楚，作為 Stage 2 的乾淨 input。 鐵則：每一點都回指素材
[#N](#素材清單)或已答未解問題[#N](#qN)；不寫 scope（做不做什麼）——那是 Stage 2。 全域碼：每條「已定向」結論行首掛§FGS-UR-{N}（N＝其所解^qN的數字）。短名查 spec-codes.md。
核心需求：內部 PO 要一個**細排引擎**，以自然時間為節拍，把粗排的投產順序（內含 VSM 資訊）連同產能、Freeze 看板產能，排到「哪些實際機台、什麼時間（到秒）製造」，產出給現場執行的命令；此命令為計劃結果，不直接鎖定／扣減真實產能（#1、#8、#7、#10）。
已定向（關係人已答／已釐清）：
§FGS-UR-1SlidingWindow 的 window size 與 deadline 參數化，預設 2hr＋一年（#1）§FGS-UR-2推式排單以投產順序為硬約束；當前 window 找不到可用資源則順延下一個 window、不插隊（#2）§FGS-UR-4細排做到實際機台指派；匹配採「依 VSM 製程-工作站找對應資源」一種（外部匹配檔案指派為另一種，屬另一支 spec）（#4）§FGS-UR-5匹配／堆疊對象為 VSM 每一個「工序-製程-工作站」節點（非僅粗排節拍點）（#5）§FGS-UR-7輸出時間精度到秒，產能本質鍵傾向以Range<Long>表時間區段（#7）§FGS-UR-8input＝粗排投產順序（內含 VSM 資訊）＋產能＋Freeze 看板產能（#8）§FGS-UR-9細排只消費粗排的投產順序，不把 LSD／LeanPlay 交期當約束（#9）§FGS-UR-10細排結果為計劃，不落地鎖定／扣減產能；實際扣產能由現場報工或生管 Freeze 指派（#10）§FGS-UR-11CO 換線精算＝CT×數量＋CO；模治具／換模技師等獨立資源延到第 2 種匹配 spec 才實作（#11）
仍待 Stage 2 拍板：
- deadline 抵達 exception 行為：暫定整批失敗，「已排部分＋未排清單」列為待議選項（關係人明示先擱置）（#3）
- 細排「資源×時間」堆疊與粗排節拍點堆疊是概念相同還是共用同一套機制（rename vs 同機制）——架構題留 Stage 2/3（#6）
交棒：→ /functional-spec-partner，以本結論＋素材清單為 input 定 scope。
變更歷史
Living doc 追加段落，不覆寫。
- 2026-06-10（同日續）：關係人（內部 Alan）回答全部 11 條未解問題。9 條已定向（q1/q2/q4/q5/q7/q8/q9/q10/q11，掛
§FGS-UR-N）、2 條部分釐清（q3 deadline exception 暫定整批失敗、q6 堆疊是否共用粗排機制，留 Stage 2/3）。q9 經本人更正為「只吃投產順序、不消費 LSD/LeanPlay」（前述「指派資源/預計開始/預計結束」係誤看其他欄位）。補寫需求收斂結論，狀態導航更新為 ✅9／🟡2／未答0，Exit Gate 五條滿足，可交棒 Stage 2。衍生標記：q4 的第 2 種匹配（外部匹配檔案指派 VSM 給特定資源 + 模治具／換模技師等獨立資源）為新 feature 種子，待開獨立 requirement，不在細排 scope 內。 - 2026-06-10：初版。登記全域短碼
FGS（見 spec-codes.md）。素材 #1 入庫（內部 PO 細排功能口述，原狀留存）。列出 11 條未解問題（全 ⬜ 未答），聚焦粗／細邊界：window/deadline 參數化（#1）、推式排單失配與順序約束強度（#2）、deadline exception 行為（#3）、與粗排 #17 機台指派的接力邊界（#4）、匹配對象範圍（每節點 vs 僅節拍點，#5）、堆疊機制是否共用粗排（#6）、輸出時間精度（#7）、完整 input（#8）、是否消費 LSD/LeanPlay（#9）、是否落地鎖定產能呼應粗排 #5（#10）、CO 換線是否精算呼應產能模組 #1（#11）。標記跨 feature 接力宣稱（功能 3/4 自稱與粗排同邏輯）與兩處潛在張力（指派實際資源 vs 粗排延後、命令落地 vs 粗排試算）為觀察點，留 Stage 2/3。需求收斂結論待未解問題釐清後補。