排程模組規格站 — 五階段可追溯性

index

15 min read

產能模組 (Capacity Module) Requirement

下游：Functional Spec capacity-module.fp.md（已簽核 2026-06-15）→ OOA ooa（草稿 2026-06-15，Step 1–3）→ 虛擬碼 pseudo（尚未建立） 來源類型：內部 PO / 產品　|　STD 通用 狀態：紀錄區（living doc）— 需求變更時追加素材並更新未解問題；不在此寫 Scope / Use Case / AC

Problem Statement

一句話。寫不出來就回去問。

內部 PO 想重構產能模型：先前版本以「工作站」為主體、再往下找對應資源，導致使用者填寫困惑與部分排單邏輯無法實作；改採以「資源」為主體的彈性結構（資源各自帶工作能力、隸屬工作站、地理位置與資源間關聯，並以行事曆＋班表＋加班/休息描述可用時間），作為產能真相源頭，透過轉接器餵給粗排等下游模組。

Stakeholders

類型對象備註
需求提出方內部 PO / 產品（Alan）產品架構規劃發起（重構方向）
受影響方現場填表人員（產能/班表維護）、排程引擎（粗排為下游消費方）、產銷協調填表人員為主要受益者（解決填寫困惑）；粗排透過轉接器消費本模組產出
決策方內部 PO / 產品負責人可拍板 scope —— Scope 本身在 Stage 2 才定

素材清單

每筆對應 raw/ 一個檔或一條連結。照實記，不要美化。

#素材來源（誰）日期（何時）為何提簡述
1raw/2026-06-08-內部PO-產能模組重構口述.md內部 PO / 產品（Alan）2026-06-08產品架構規劃（重構方向）產能＝資源-時間表；資源為多型且帶能力/隸屬/位置/關聯；時間＝行事曆+班表+加班休息；建模主體由工作站翻轉為資源；架構意圖＝產能模組為源頭、經轉接器餵下游

標籤 / 重複 / 矛盾

AI 主動標、人確認後寫入。

標籤：#產能模組 #capacity #資源時間表 #資源 #機台 #模治具 #操作人員 #換模技師 #工作能力 #製程 #工作站 #地理位置 #限制關聯 #優先度關聯 #行事曆 #班表 #加班休息 #跨日班 #時間區段 #DDD #轉接器ACL #重構 #STD #DataBox #CO換線

狀態標籤：#未答 #部分釐清 #已釐清

重複：

  • 無（目前僅單一來源素材）

矛盾：

  • 無明確矛盾。下游衝擊（觀察點，非矛盾，留 Stage 2/3）：
    • 「資源為主體」對既有共用 domain-model 的「WorkCenter（工作站）為產能承載主體」是結構性翻轉，且 rough-cut-scheduler 已消費既有產能物件——非矛盾，是 cascade 衝擊。
    • 配對特例（同製程、不同工作站；見 #2）挑戰既有不變量「節點＝工單-料號-工作站-製程-工序的單一對」。
    • 「資源×時間區段」（見 #7）vs 既有 CapacitySlot「工作站×日」——預期 AvailableCapacity／CapacitySlot 變成轉接器（ACL）算出的下游投影，與架構意圖一致。

缺失：

  • 優先度關聯的「某些條件」未定義（已列入未解問題 #4）
  • 限制關聯的維護方式未討論（已列入未解問題 #6）

未解問題

AI 主動列、不裁決。每條：問題 + 來源 + 類型 + 建議找誰問。 狀態導航與其他文件以題號連結 [#N](#qN) 連到各題（逐題錨由 build 注入）。

狀態導航

點編號可跳到該題。

  • ⬜ #未答 — #4
  • 🟡 #部分釐清 — #5 #6 #8
  • ✅ #已釐清 — #1 #2 #3 #7

  1. 模治具、換模技師算「獨立資源」還是「換線整備（CO）的一部分」？

    • 來源：#1（資源舉例：模治具、換模技師）
    • 類型：含糊
    • 建議找誰問：內部 PO
    • 狀態：✅ 已釐清 #已釐清
    • 答覆(2026-06-08，內部 Alan)：是獨立資源；但到時候佔用產能時，是要用 DataBox.changeOverTime 去計算。
    • 釐清：模治具／換模技師為第一級資源，非 CO 的附屬；惟其佔用產能的「量」由 DataBox.changeOverTime 推算（佔用計算屬 Stage 2/3）。

  2. 「工作能力＝製程列表」與既有 VSMNode 的「工作站-製程」配對如何對接？（以前製程綁工作站，現在綁資源，配對邏輯翻轉）

    • 來源：#1（每個資源必須有工作能力、工作站）
    • 類型：含糊 / 缺失
    • 建議找誰問：內部 PO + 現場
    • 狀態：✅ 已釐清（主規則＋特例規則皆定） #已釐清
    • 答覆(2026-06-08，內部 Alan)：先看製程、再看工作站；目前絕大部分都是兩者都要能 match 才能使用這個資源，但都會有一些特例（現場真的把某個 VSMNode 拿去給「相同製程但不同工作站」的資源使用）。
    • 釐清：主配對規則＝製程優先、工作站次之、預設兩者皆 match。此特例衝擊既有「節點＝工作站-製程單一對」不變量（見矛盾段）。
    • 答覆(2026-06-08，內部 Alan)：特例 = 現場將某個 VSMNode 上機到不同工作站的資源，因此在佔用時，直接找對應的資源就好，不管工作站。
    • 釐清（更新）：特例佔用規則＝直接找對應資源、不論工作站。主規則＋特例皆定，#q2 收斂為 ✅。「不論工作站」進一步印證產能以資源為鍵（呼應 #7 與矛盾段的「節點單一對」衝擊）。

  3. 地理位置是否牽動 DataBox.transferTime（移動至下站），還是純資訊欄位？

    • 來源：#1（每個資源必須有地理位置）
    • 類型：含糊
    • 建議找誰問：內部 PO
    • 狀態：✅ 已釐清 #已釐清
    • 答覆(2026-06-08，內部 Alan)：純欄位資訊。
    • 釐清：地理位置為純資訊欄位，不參與移動時間計算。

  4. 優先度關聯「某些條件下 A、B 機台被同時選中排單」——「某些條件」指什麼？

    • 來源：#1（優先度關聯舉例）
    • 類型：缺失
    • 建議找誰問：內部 PO + 現場
    • 狀態：⬜ 未答 #未答
    • 答覆(2026-06-08，內部 Alan)：還不知道，只是在說明可能有這個需求。
    • 註：先記為「可能有此需求」，條件與規則屬 Stage 2 展開。

  5. 跨日班的「日界」歸屬哪一天？（星期二晚班跨到週三 07:00，產能算週二還是週三）

    • 來源：#1（時間 1-1 跨日班）
    • 類型：含糊
    • 建議找誰問：內部 PO + 現場
    • 狀態：🟡 部分釐清（暫定、待確認） #部分釐清
    • 答覆(2026-06-08，內部 Alan)：產能可能要算在週二；這確實是個好問題，但先算在週二。
    • 釐清：跨日班暫定歸屬起班日（前一日，週二）；最終確認待 Stage 2。

  6. 限制關聯（模具↔技師、機台↔操作員）是雙向還是單向？資料怎麼維護？

    • 來源：#1（限制關聯舉例）
    • 類型：含糊 / 缺失
    • 建議找誰問：內部 PO
    • 狀態：🟡 部分釐清（方向已定、維護待議） #部分釐清
    • 答覆(2026-06-08，內部 Alan)：單向——技師 → 模具、操作員 → 機台；維護方式沒討論。
    • 釐清：限制關聯為單向（資源 → 受限資源）；維護方式（誰填、怎麼填）待 Stage 2。

  7. 「資源為主體」後，產能的鍵還是「×日」嗎？還是「資源×時間區段」？

    • 來源：#1（時間＝行事曆+班表+加班休息組成的時間區段）
    • 類型：含糊
    • 建議找誰問：內部 PO
    • 狀態：✅ 已釐清 #已釐清
    • 答覆(2026-06-08，內部 Alan)：時間區段，「日」只是轉換後的結果。
    • 釐清：產能本質鍵＝資源 × 時間區段；「日」為轉換後產物。對既有 CapacitySlot「工作站×日」之影響見矛盾段（預期由轉接器投影）。

  8. 產能模組 → 轉接器 → 下游模組的 context 邊界與轉接器（ACL）設計？

    • 來源：#1（架構意圖：粗排所用產能由本模組計算、經多個轉接器餵其他模組）
    • 類型：缺失（偏架構/解法，屬 Stage 3 OOA）
    • 建議找誰問：內部 PO + 架構
    • 狀態：🟡 部分釐清（意圖已定、設計留 OOA） #部分釐清
    • 釐清：架構意圖已定（產能模組為源頭、轉接器餵下游、符合 DDD Context Mapping/ACL 方向）；context 邊界切法與轉接器設計屬 Stage 3 OOA，Stage 1 不拍板。Stage 2 碰既有共用 domain-model 時需處理「AvailableCapacity／CapacitySlot 是否成為轉接器投影」。

需求收斂結論

把這份紀錄「收斂到什麼」描述清楚，作為 Stage 2 的乾淨 input。 鐵則：每一點都回指素材 [#N](#素材清單) 或已答未解問題 [#N](#qN)；不寫 scope（做不做什麼）——那是 Stage 2。

核心需求：內部 PO 要把產能模型從工作站為主體翻轉成資源為主體的彈性結構——先前「先設工作站、再找資源」造成填寫困惑與排單邏輯無法實作；新結構讓多型資源（機台／模治具／操作人員／換模技師…，不限於此）各自帶工作能力、隸屬工作站、地理位置與資源間關聯，並以行事曆＋班表＋加班/休息描述可用時間。產能模組定位為產能真相源頭，經多個轉接器餵粗排等下游模組（#1）。

已定向（關係人已答／已釐清）：

  • §CAP-UR-9 建模主體翻轉：工作站為主體 → 資源為主體（#1）
  • §CAP-UR-10 資源為多型：機台／模治具／操作人員／換模技師…（「包含但不限於」）（#1）
  • §CAP-UR-11 每個資源帶三項：工作能力（製程列表）、隸屬工作站、地理位置（#1）
  • §CAP-UR-1 模治具／換模技師＝獨立（第一級）資源；佔用產能的量由 DataBox.changeOverTime 推算（#1）
  • §CAP-UR-2 資源-製程-工作站配對主規則＝先製程、再工作站、預設兩者皆 match；特例（同製程／異工作站）＝佔用時直接找對應資源、不論工作站（#2）
  • §CAP-UR-3 地理位置＝純資訊欄位，不牽動移動時間（#3）
  • §CAP-UR-6 限制關聯＝單向（技師→模具、操作員→機台）（#6）
  • §CAP-UR-5 跨日班日界暫定歸起班日（週二晚班算週二）（#5）
  • §CAP-UR-12 時間三件套結構：行事曆＝日曆天；班表＝dayOfWeek＋起始時間＋時長（Duration）＋多組休息時段；加班/休息＝日曆天＋起始時間＋時長（#1）
  • §CAP-UR-13 使用者用工廠術語（早班／中班／晚班）表達，後端轉成時間區間；含跨日班（#1）
  • §CAP-UR-7 產能本質鍵＝資源 × 時間區段；「日」只是轉換後結果（#7）
  • §CAP-UR-8 架構意圖：產能模組為產能真相源頭，經轉接器（ACL 方向）餵粗排等下游；粗排可用產能由本模組計算而來（#1、#8）

仍待 Stage 2 拍板：

  • 優先度關聯的「某些條件」與規則（#4）
  • 限制關聯的維護方式（誰填、怎麼填）（#6）
  • 跨日班日界歸屬的最終確認（暫定週二）（#5）
  • 與既有共用 domain-model 的關係：「資源×時間區段」是否／如何經轉接器產生既有 AvailableCapacity／CapacitySlot「工作站×日」，及「節點＝工作站-製程單一對」之特例衝擊（#7、#8、#2）

交棒：→ /functional-spec-partner，以本結論 + 素材清單為 input 定 scope。

變更歷史

Living doc 追加段落，不覆寫。

  • 2026-06-08：初版。素材 #1 入庫（內部 PO 產能模組重構口述，原狀留存）。列出 8 條未解問題並就地收斂關係人當日答覆（✅ #1、#3、#7；🟡 #2、#5、#6、#8；⬜ #4）。寫需求收斂結論（核心需求 + 已定向 12 點 / 仍待 Stage 2 拍板 5 點，每點回指素材／^qN）。標記三項對既有共用 domain-model 的下游衝擊（主體翻轉、節點單一對特例、資源×時間區段 vs 工作站×日）為觀察點，留 Stage 2/3 處理。
  • 2026-06-08：使用者補充 #q2 特例佔用規則（直接找對應資源、不論工作站）。#q2 由 🟡 收斂為 ✅；同步更新狀態導航、移除「缺失」與「仍待 Stage 2」中的特例待辦、收斂結論「已定向」改寫配對規則。已定向 12 點不變、仍待 Stage 2 由 5 點減為 4 點。

1 item under this folder.

  • raw