Consistency Audit: resource-selection / OOA
- 修改文件：resource-selection.ooa.md
- 修改日期：2026-06-15
- 編輯者：Alan
- Diff 摘要：新建 resource-selection OOA（跨 feature 共用），完成 Step 1–3；其中子圖 A 宣告對 domain-model 的結構 delta（
Resourceflat→abstract base + 4 子類 +type()）與 N2（ResourcePool加findById()）。Step 3 SOLID 四檢點全判、patterns 裁定不新增。 - Audit 觸發時點：簽核前（mid-stage edit，路徑 B）
本份為前瞻式 audit：子圖 A／N2 的 delta 尚未套進 domain-model.ooa.md（該檔現行 diff 僅表格排版），僅在本 OOA 內「宣告」為待辦。故下游影響評估的是「若接受本 OOA，會逼 domain-model 與其已落地 code 做什麼」。
上游一致性
本 OOA 上游＝已簽核的 resource-selection.fp.md（Stage 2，跨 feature 共用 Published Language）。走 workflow §3b（修改 OOA）的上游範圍。
| 項目 | 狀態 | 說明 |
|---|---|---|
| Model 服務所有 Use Case | ✅ | §5 對照完整：UC-A→matchByCapability、UC-B→resolveByAssignment、UC-C→pruneByCoupling、UC-D→NoCapableResourceException；§RS-FS-1~9 皆有對應（§RS-FS-7 無產能型別、§RS-FS-8 跨型別組合刻意不建模，一致） |
resourceSelectionPriority 命名 | ✅ | FS §RS-FS-9 欄名 → RankedResource.resourceSelectionPriority: int，一致（含刻意避開 RCS prioritySeq） |
| 引入未提概念（技術 vs 業務） | ✅ | ResourceSelector／兩 port／ResourceType／各 VO 均為實作 FS 行為的技術抽象，未引入新業務概念 |
N1 — declaredTypes() 放置（§RS-FS-6「有宣告才回、不反推」） | ✅ | 2026-06-15 已裁定：受限型別（模具/操作員/技師）的「宣告」唯一合法來源即限制／指派設定——沒設限制即未宣告、不回（domain 規則：工廠未限定「哪支模具由誰更換」時不回技師才正確）；機台為無條件 baseline、不經宣告閘。故 declaredTypes() 從設定推為 domain 本來形狀，非耦合。採選項 (a) 維持現行設計。 |
N3 — ResourceCouplingQuery 為 consumed port（§CAP-UR-6） | ✅ | 2026-06-15 確認：維持 consumed port；capacity-module OOA 接著做，屆時兩邊對齊（follow-up，非矛盾） |
需討論項目
（無遺留 —— N1、N3 已於 2026-06-15 對話中裁定）
矛盾項目
（上游無 ❌）
下游影響
resource-selection 自身無 pseudo／code（待建立，非引用失效）。真正下游＝子圖 A 改動的是 domain-model 這個 sibling 共用 OOA，且其已落地為 code（消費
domain-model/spec-v1，SHA e01cacf）。
| 下游文件 | 受影響章節 | 行動 |
|---|---|---|
| domain-model.ooa.md | §DM-OA-4 Resource flat→abstract + type() + 4 子類（Published Language 結構改動） | 需更新 + 重打 domain-model/spec-v2 |
| domain-model.ooa.md | §DM-OA-9 ResourcePool 加 findById()（N2，純附加） | 需更新（附加，不破既有） |
…/com/agilelean/scheduling/domain/Resource.java | public final class→abstract + type() + ResourceType enum + 4 子類 | 需更新 |
…/com/agilelean/acl/scheduling/in/ResourcePoolMapper.java 第 63 行 | new Resource(ResourceId.of(entry.getKey()), …) —— abstract 後無法編譯，建構須改為某子類（ACL inbound 須建 legacy 資料→子型別對照） | 需更新（矛盾來源，見下） |
…/com/agilelean/scheduling/fixture/ToyFixtures.java 第 130 行 | new Resource(ResourceId.of(id), …) 測試 fixture，同樣失效 | 需更新 + 測試重跑 |
…/com/agilelean/scheduling/domain/ResourcePool.java | 加 findById()（N2，附加） | 需更新（附加，不破既有） |
docs/refactor/scheduling/SPEC-REF.md | 引用版本表 domain-model/spec-v1→v2 | 需更新 |
矛盾項目（❌，擋 OOA 簽核）
- 子圖 A note「粗排 code 不動（§RS-UR-9）」與下游 code 事實矛盾 — OOA 子圖 A 標註「粗排（已 coding）吃 base 視角、
List<Resource>不變 → code 不動」。讀取視角部分屬實（eligible()／resources()／canPerform()皆未動）；但Resource由 concretefinal變abstract會讓 2 處new Resource(...)建構點無法編譯 ——ResourcePoolMapper.java:63（main，ACL inbound）與ToyFixtures.java:130（test）。故「code 不動」不成立。註：本條為「OOA 對自身衝擊範圍的標註與 code 事實不符」，非評論設計對錯（audit 不評論設計）。標註與事實須對齊方可簽核。
建議行動清單
- 處理矛盾項目 1（必達，擋簽核）：由人（OOA 邊界）擇一方向——
(1) 標註誠實化：將 §RS-UR-9 從「code 完全不動」修正為「讀取視角不動、建構點需配合升 tag 改子類」，並列為 code repo 消費
domain-model/spec-v2時的實作工項；或 (2) 改設計降衝擊：重新考慮子圖 A 的 abstract 化（如type()改吃欄位）——但此舉回退 Step 3 已拍板的 Fork 1b（保留子類階層）。 - N1 採選項 (a)：開 object-oriented-analysis-partner，於 OOA 補一句「機台為無條件 baseline、
declaredTypes()只管模具/操作員/技師」的模型澄清（清晰度，不擋）。 - （v2 落地交接約束） 待時機成熟推進到
domain-model/spec-v2時，code 端落地須為手術式最小範圍重構：僅限「Resource升 abstract + 新增 4 子類 +type()／ResourceType」與上述 2 處建構點改子型別 + N2 附加findById()；禁止波及讀取視角（eligible／resources／canPerform／List<Resource>消費鏈）與既有粗排行為。驗收點：diff 範圍應可一一對應本表「需更新」列，超出即視為過度修改。 - N2：domain-model OOA §DM-OA-9 + code
ResourcePool.findById()為純附加，隨 v2 一併落地。 - capacity-module OOA：補做以對齊 §CAP-UR-6（N3 follow-up）。
統計
- ✅ 5 | ⚠️ 0 | ❌ 1
- 下游受影響點：7
- 簽核擋判定：擋（❌ = 1）
簽核
- 編輯者已跑過 audit：Alan / 日期 2026-06-15
- AI 產出 Impact Report：consistency-audit skill / 2026-06-15
- Reviewer 確認：____ / 日期 ____
❌ 矛盾項目 1 未處理前，本 audit 不應簽核通過；resource-selection OOA 的 Exit Gate 簽核應同步等待。 下游更新（domain-model OOA、code repo）由各階段對應的 partner skill／code repo
/refactor-acl執行，本 audit 不開處方。