跳轉到

資料中心學習軌跡

目標：在自建自營機房（新建中）建置 infra management 系統所需的領域知識。 時間預算：每天 1 小時，六個月（約 180 小時）。

這條軌跡怎麼運作

跟本站另一條 GitHub trending 軌跡機制完全不同：

GitHub trending 軌跡 資料中心軌跡
驅動方式 爬蟲驅動 — 每天掃 trending，看到什麼寫什麼 教材驅動 — 佇列決定今天寫什麼
語料 開放且每天在變 封閉且緩慢變動
每篇長度 800–1000 字 6000–9000 字元（上限 10000；深度優先，寧願慢也要學透）
節奏 每日 1–2 篇 每日 1 張卡（讀 15 分 + 動手 40 分），週日一份複習

之所以不用爬蟲驅動：資料中心的基礎知識十年沒變，每天去爬只會拿到同一批概念的第 N 次重述。這裡真正稀缺的不是資訊，是把資訊整理成你資料模型的欄位。

每張設備卡的六格

欄位 填什麼
拓撲位置 上游接誰、下游接誰
容量單位 kW / kVA / A / RT / CFM / U / kg，以及銘牌與實測的關係
冗餘表達 N、N+1、2N 在這類設備上具體長什麼樣
遙測介面 協定 + 關鍵點位清單
故障域 它掉了誰跟著死、多久內有影響
維護特性 週期、是否需停機、停機時的替代路徑

這六格不是背誦卡，是資料表的欄位規格。

導覽

進度

項目 狀態
佇列總數 71（2026-09-17 從 dc-25 拆出 dc-25b 氣流管理的度量，已於 2026-09-18 完成；2026-09-07 從 dc-19 拆出 dc-19b）
已完成 35
目前輪次 第二輪：冷卻鏈（2026-09-03 由 dc-17 冷卻水塔 開工）。第一輪電力鏈 dc-01 ~ dc-16 已於 2026-09-02 全數完成
下一張 dc-26 液冷 CDU（coolant distribution unit）。backlog 上 dc-25b 之後的下一個未完成項，第二輪冷卻鏈的液冷段開工
第一張主題卡開張 dc-25b 氣流管理的度量（2026-09-18）。 topics/ 原排第五輪，因 dc-25 拆卡而提前——拆出來的「度量」那一半不是設備，不套六格。本卡是第一個「後面的卡把前面的欄位刪掉」而非疊加的建議：能量守恆給 RTI = ṁ_IT/ṁ_送 = 1/λ，而 dc-22 自推的 BP = 1 − 1/λ（無再循環時）——三者只能存一個（存可直接量的 lam，rti / bypass 降為 property）。驗證：dc-22 的 λ = 1.75 → RTI 57.1%、BP 42.9%，與那張卡從三個溫度獨立算出的 0.43 吻合 ✓。病名是同義不同名，對照 W37 記的「值＋出處家族第五次」是同一種病的新變種。而最重要的一條是：一個 AirBalance 有三個概念，卻只有兩個獨立量測維度——質量平衡給 BP = 1 − (1−R)/λ，取 λ = 1、R = 0.4 → BP = 0.4 而 RTI = 100%：一間每台伺服器都吸 40% 自己排氣的機房拿滿分。λ 管「多少」，封閉管「去哪」，RTI 只看得到前者；要分開得靠 dc-22 的三溫度法（與 R 無關），兩個聯立才解得出 R = 1 − λ(1−BP) → 只量到一個時 recirculation 必須是 unknown 而非 0（同 dc-25 的 integrity 三態、dc-15 的「stale 不是 0」）
指數判準會給違規的機房高分 dc-25b：40 櫃、39 櫃 24 °C ＋ 1 櫃 33 °C（超過 A1 允許上限 32）→ 2011 A1 算 97.0%、2004 Class 1 算 97.1%，SL-08-018 表 1 評級「≥96% Good」兩版都判良好。更糟的是分母含機櫃數：同一櫃放進 200 櫃機房 → 99.4%，危險沒變、分數更漂亮 → RCI 不可跨房間比大小，Score(value, envelope_ref, n_intakes, flagged)（「值＋出處」家族第六次）。這不是編的邊界案例——Herrlin & Khankari NY-08-004 表 1（本次取到原文逐格核對）：70 °F/100% = 91*、55 °F/80% = 88，星號原文定義是「一個或多個進風溫度落在允許範圍外」，91* 比 88 危險，而評級表把 91 列 Acceptable、88 列 Poor——排序是反的。→ RCI_DEGRADED（調全房設定值）與 INTAKE_ABOVE_ALLOWABLE（派人看那一櫃）並列不可合併，且後者可在前者全綠時發生（結構同 dc-18 的 PROTECTION_TRIP_PREDICTED）。來源分歧：Herrlin 自己跟自己打架——NY-08-004 內文寫「≥95% 是良好設計」，同年同卷 SL-08-018 表 1 卻是 Good ≥96% / Acceptable 91–95%：95% 在一份文件裡是良好，在另一份裡是可接受的下半段
差壓設定值：一個數量級，零標準依據 dc-25b：AKCP（2021）同一篇文章內既寫「維持 20 Pa」又寫「理想是零差壓運轉」；同作者 2023 在 Data Centre Magazine 的圖說是「風扇加速以維持 20 Pa」、內文卻是「極輕微正壓」；專利文獻常見「1–5 Pa」。ASHRAE / Uptime 查不到規定值，全是廠商與專利口徑。 代價算得出來：孔口式 Q = C·A·√(2ΔP/ρ)，一條通道 10 櫃 × 6 kW、ΔT 20 K（ṁ_IT = 2.479 m³/s）、A = 0.5 m²（假設）→ 20 Pa 需 λ 1.70（RTI 58.9%）、2 Pa 只需 λ 1.22（RTI 81.9%），風扇功率差 2.69 倍。漏氣量比 = √(ΔP 比) = 3.16 這一項與洩漏面積無關，λ 與功率的絕對值才依賴 A。→ 差壓設定值是第四個「沒有 commissioning 產出就沒有告警規則」的欄位（前三：dc-09b 電池 baseline、dc-19 rate limiter、dc-21 clean ΔP）→ Setpoint(value, basis, source, commissioned_at)：沒有 basis 的 20 Pa 跟沒有 basis 的 2 Pa 在資料庫裡長得一模一樣
✅ 版控已補上（2026-09-17） 09-10 ~ 09-15 那五份積壓（dc-21、dc-22、2026-W37 週報、dc-23、dc-24）使用者已在本機 commit（a27a801 / d8306fb），本次排程開工時確認 git 樹只剩 dc-23／dc-24 兩檔未追蹤，已隨今日 commit 一併進版控。沙箱本日恢復正常（磁碟 9.3 G 可用，wc -m 與 mkdocs 皆可執行），.git/*.lock 開工與收工各確認一次皆乾淨。機制性建議仍成立且本日再獲一個證據（見下一列）——排程 skill 開工時應比對 git log -1 --format=%cd 與最新卡片 written_at，不一致就標紅
🔴 dc-23 與 dc-24 字數超標 本日實測：dc-23 wc -m = 10292、dc-24 = 10973，兩張都超過 10000 硬上限。 那兩天沙箱起不來、wc -m 沒能執行，卡片註記的「約 8500–9500」「約 9000–9500」是估算值，實測都超，誤差 1000 字元以上。→ 建議把 dc-daily-card 的規則從「wc -m 失敗時估算並註記」改成「wc -m 無法執行則不得 commit」，否則估算誤差會永久留在卡片裡。兩張卡是否回頭壓縮（或比照今日拆卡）留給使用者裁決。另 09-10 發現的 mkdocs.yml 缺 pymdownx.arithmatex（5 張卡 6 處 $$）仍未修；dc-23／dc-24／dc-25 皆已刻意避開 $$
（09-11 原始紀錄） dc-21（2026-09-10）與 dc-22（2026-09-11）都寫進本機資料夾但都沒有 commit。 原因是排程沙箱的 workspace 自 09-10 裝 mkdocs 時磁碟寫滿後一直沒恢復（no space left on device），09-11 重試三次仍同一錯誤。兩天都沒有執行任何 git 指令、沒有殘留 lock 檔。需在 Mac 本機補：git add -A && git commit -m "feat(dc): cards dc-21 plate-hx-free-cooling, dc-22 crah-chilled-water"，之後 launchd 輪詢會自動 push。順帶在本機跑 wc -m 與 mkdocs build --strict 驗證兩張卡（沙箱兩天都跑不了，dc-22 字數為估算值）。另有一個 09-10 發現、至今未修的 repo 級問題：mkdocs.yml 沒有 pymdownx.arithmatex，而 pdu-floor / sts-two-source-relationship / npsh-and-pump-placement / lib-fire-compliance / plate-hx-free-cooling 共 5 張卡 6 處用了 $$...$$，在 CF Pages 上會印出字面字串（與當初 wikilink 同一類的坑）。修法是加 pymdownx.arithmatex: {generic: true} ＋ extra_javascript 掛 MathJax，但需本機 build 驗證後再動。dc-22 已刻意全程避開 $$。
⚠ 欠的盤點 單線圖對照盤點尚未做。 排程任務手上沒有公司的單線圖，無法自動執行。backlog 的「第一輪補完」那一節先留空，等使用者拿到圖再回頭插項目
週報 8 份（最新：2026-W38）
下次間隔複習 W39：抽 W37 的卡（dc-19 ~ dc-22）＋ W35 的卡（dc-10b ~ dc-13）。⚠ dc-10b 已在 W37 抽過，請從 dc-10c / dc-11 / dc-12 / dc-13 裡選
🔴 綠燈的四種死法（W38 母題） 2026-W38 週報：本週四張卡各交了一份「儀表板全綠、機房在出事」，而四種死法互不相同——(1) dc-23 穩態報表結構上表達不了時間（ride-through 24 s vs 強制休息 300 s）；(2) dc-24 只在群組層級可見（甲機加濕、乙機除濕，每天都在發生）；(3) dc-25 物理世界真的變了而模型不知道（頂板落下、零點位）；(4) dc-25b 指標的定義本身就允許它（RTI 100% 可以是再循環 40%）。→ 正好把 Dimension 的 invalid 從兩種補到四種（meter_stale / formula_out_of_domain / no_consensus / physical_change），四者處置方向完全不同（退回別的方法／停止判定／換聚合／作廢整份報表），所以 status: Check 三態也不夠，必須配 invalid_reason。另立第五態 UNDETERMINED（dc-25b 的 recirculation：資料沒錯、公式沒錯、感測器沒壞，就是一個量測解不出兩個未知數）——它與 INVALID 的處置是「加點位」vs「修東西」，不可合併
🔴 dc-23 是本軌跡第一個斷頭節點 W38 週報 連貫性檢視 #1。 W37 立的規律是「可貼的 code 只被下一張卡採納」，本週繼承鏈第一次分叉：dc-22 → dc-23，dc-22 → dc-24（跳過 dc-23）→ dc-25 → dc-25b。dc-23 是分叉後沒有下游的那一支，而它是本週最重的一張卡（SplitDimension ＋ env_offset ＋ Dimension.kind = cycles ＋ RefrigerantCircuit）。依該規律，斷頭 ＝ 那四項不會進入模型，而 SplitDimension 恰恰是不做就會算錯的那種。→ W38 第一順位（5 分鐘）：在 backlog 的 dc-26 項目下掛 HTML 註解「開工前先把 dc-23 的 SplitDimension 接進 RoomReport」——走已被證明有效的路徑（下一張卡的練習題），不是再寫一份沒人讀的文件。W37 的三項優先序本週全紅（topics/model.md 沒建——但 topics/ 本週因拆卡開張了，證明障礙從來不是機制；dc-16 的 50.5% 第三次沒改；energy_kwh() 連續第五週）。energy_kwh() 改名依 W37 自己的承諾正式除名，登記為已知缺陷
🔴 Check enum 六天內被改名、改值、加第四態，而註解還寫「三態」 W38 #2，本週最容易驗證的一處漂移。 dc-19b（09-09）：SATISFIED = "satisfied"; VIOLATED; NOT_APPLICABLE = "not_applicable"；dc-24（09-15）：OK = "ok"; VIOLATED; NOT_APPLICABLE = "n/a"; INVALID = "invalid"，而註解仍寫「dc-19b 立的三態」。成員改名、值字串改寫、多出第四個成員，三件事沒有任何一張卡說明。實務後果："not_applicable" 與 "n/a" 若各有一批資料落庫，任何 WHERE status = ... 都會漏掉一半。這一處同時證明：(a) 鏈式繼承會傳播型別但不會保護型別；(b) 註解不會跟著改，所以漂移在 review 時看不出來
🟡 同一間機房、同一週、兩個熱容，差 9% W38 #5：同名同義不同值（首例，比 W37 的「同義不同名」深一層）。 dc-23（09-14）取 1000 m² × 4 m = 4 000 m³ → 4 840 kJ/K → 24 s；dc-25（09-17）取 3 770（房間扣熱通道）＋ 600（地板下）= 4 370 m³ → 5 288 kJ/K → 26.4 s。兩張卡都自稱「同一間機房、純空氣上界」，而 dc-25 沒有提到 dc-23 已經算過一次。→ 一旦一個量被算過兩次，它就該是函數不是數字：room_thermal_mass_kj_k(geometry, include_underfloor: bool)，且 include_underfloor 必須顯式——兩張卡的差別就在這裡，而沒有人寫下來。另 #3：AirBalance 的層級從房間降到通道（dc-22 的 (bypass, recirculation, balance) vs dc-25b 的 (aisle_id, lam, bp)），型別名沒變，而兩者的 λ 不是同一個量 → 拆成 AisleAirBalance / RoomAirBalance。dc-28 空間層級第三次被提前需要
🟡 Finding 一週新增八種，其中一種明說自己不是錯誤 W38 #6。 RIDE_THROUGH_INSUFFICIENT(dc-23)／OPPOSING_ACTUATION、CANNOT_MEET_LIMIT(dc-24)／CONTAINMENT_DEGRADED、FAULT_DOMAIN_SPLIT(dc-25)／RECIRCULATION_HIGH、RCI_DEGRADED、INTAKE_ABOVE_ALLOWABLE(dc-25b)。W36 #2 早已說過「Finding 只有 severity，還需要 kind 與 lifecycle」，本週給了無法迴避的證據：FAULT_DOMAIN_SPLIT 被 dc-25 明寫成「不是錯誤，是該被記錄的事實」——一個只有 severity 的型別裝不下「這不是問題」。→ Finding.kind: violation \| prediction \| fact \| degradation。正面對照組：Limit.basis 本週第三次擴張（dc-19 空間 → dc-20 改變改善動作 → dc-25 用在時間維度上，兩個門檻 generator_start 10 s 與 crac_restart_delay 300 s），三張卡沿用、零次漂移——目前唯一一個
⚠ 9/16（三）缺一張卡，且原因不在沙箱 W38 節奏（一）。 前後兩天都正常產出（09-17 明確記載沙箱恢復、磁碟 9.3 G），而 9/16 沒有 commit、沒有未追蹤檔案、沒有殘留 lock——沒有任何痕跡。→ 建議 dc-daily-card 收尾加一條：無論成功失敗都追加一行 runlog（日期＋結果＋失敗原因），否則「空手」與「沒跑」事後無法區分，而兩者處置完全不同。另 .git/*.lock 自 09-18 08:12 殘留到 09-20，兩天（正是 dc-25b 那次排程的收工時間，本次已清）——收工的 rm -f .git/*.lock 顯然沒有實際生效，建議改成收工檢查（刪完 ls 確認為空，不為空就標紅）。若卡在平日，使用者本機 git 會連鎖停擺
✅ 拆卡是處理超標最好的解法（dc-25 示範） 本週實測：dc-25 9 993（距 10 000 硬上限 7 個字元）、dc-25b 8 162，兩張都合格——初稿超標 → 拆卡 → 兩張都過，而且拆出來的那張成了第一張主題卡。對照 dc-23 10 292 與 dc-24 10 973 仍超標未處理。壓縮是犧牲深度，拆卡是把混在一起的主題分開 → 建議 dc-23 比照辦理：「冷媒法規與立管」（來源分歧一、二）本來就是獨立主題（制度＋管路設計），拆成 dc-23b 比壓縮合理。留給使用者裁決。 另 mkdocs.yml 缺 pymdownx.arithmatex 第四週未修（5 張舊卡 6 處 $$；dc-23 ~ dc-25b 皆已刻意避開，問題沒擴大也沒縮小）
🔴 模型收斂的機制壞了（W37 最重要的一項） W37 週報 結算 W36 六項優先序：六項全紅，包括那個標註「5 分鐘、排第一」的 dc-16 數字修正。 W34 立、W35／W36 各驗證一次的規律「寫成可貼 code 的建議會被採納」本週失效——W36 六項全部寫成了可貼的 dataclass，全部沒被採納。修正後的規律（證據在本週五張卡的練習區塊）：可貼的 code 只被「下一張卡」採納，而下一張卡會再貼一份自己的。dc-19→dc-20→dc-19b→dc-21→dc-22 形成一條乾淨的繼承鏈，而週報不在那條鏈上。→ 建議建 datacenter/topics/model.md 當模型的單一真相來源，並把 dc-daily-card 練習模板從「接昨天那張卡」改成「接 model.md 並 append 回去」。⚠️ 這會動到佇列（topics/ 原排第五輪），是取捨不是自動可做的決定，留給使用者裁決。W37 刻意只排三項優先序、全部 < 30 分鐘：(1) 建 model.md ＋ 改模板 25 分、(2) dc-16 的 50.5%→58.4% 5 分（第二次排）、(3) energy_kwh() 改名 10 分（連續第四週；再不做就降級成已知缺陷，從清單上拿掉）
🔴 已被後續卡片修正的結論 兩筆，都在 W36 週報 裡。 (1) dc-17 那張「WB 30 °C、4 格、用率 142%、紅燈」的表是錯的——它假設冷卻水恆定 32 °C，dc-18 解聯立後實際收斂在 32.9 °C、綠燈；真正的紅燈是「平衡點超過保護設定值」（WB 30／2 格 → 35.8 °C > 冷凝器進水上限 35 °C），而那一列的容量用率看起來完全正常。(2) dc-16 驗收表的 normal 應是 58.4% 不是 50.5%（分母誤用 10 kVA 而非單側 derated 的 8 646 VA）——照它寫測試會直接紅。W36 連貫性檢視 #6 給了不變式 used_pct(lose_b) == 2 × used_pct(normal)，並建議把「同卡內數字的自我一致性」加進 dc-daily-card 收尾檢查
幾何進入容量計算 dc-19b 立的新分界：前 20 張的拓撲只回答「誰接誰」，NPSH 回答的是「它在幾樓」。同一張單線圖、同一顆泵、同一組型錄數字，泵放地面層 vs 放屋頂與塔並排 → NPSHa 24.89 m vs 7.08 m，最大可運轉流量 170.4% vs 100.5%（後者在 110% 流量時 margin 已是 −0.50 m，直接汽蝕）。→ Device.elevation_m ＋ datum_ref，且冷水盤要記運轉水位不是溢流水位。第三輪的空間層級（dc-28）被提前需要了。 另：max_flow 第一次是解出來的（NPSHa(Q) 遞減 × NPSHr(Q) 遞增的交點）而非查表值，且 margin 判準本身會換分支（max(1.0 m, 0.1×NPSHr)），所以 Limit.basis 要記到判準層級
容量的自變數變成決策 dc-21 立的新分界：dc-16 的 scenario（故障情境）與 dc-17 的 env（濕球）都是外生的，模型只能接受；mode ∈ {mechanical, integrated, free} 是控制系統選的。而跨模式 binding 完全不同——free 模式下冰機根本不在圖上，binding 是 HX approach 與塔格數。連帶：模式切換是模型裡第一個帶記憶的約束（前 20 張所有 Constraint 都是當下狀態的純函數），ModePolicy 的 enter_wb_c ≠ exit_wb_c ＋ min_dwell_s，否則濕球在門檻附近抖動會讓冰機反覆起停；而切換動作本身開脆弱窗口（冰機回來要 10–15 分鐘，ride-through 只有 5.2 分鐘）→ dc-20 的 recovery_until 第二次派上用場
容量的自變數變成負載自己造的 dc-22 立的新分界，也是這條線的終點：dc-16 的 scenario 與 dc-17 的 env 是外生、dc-21 的 mode 是控制系統選的，三者都不受負載影響。CRAH 的容量是回風溫度的函數，而回風溫度取決於封閉品質、盲板、地磚開孔率——取決於營運習慣，不取決於硬體。Liebert CW 305（EWT 7.2 °C、35 000 ACFM）：回風 23.9 → 29.4 °C，顯熱 228 → 323 kW（+42%），而送風只從 12.5 動到 13.2 °C（離風溫被 EWT ＋ approach 釘住）。連帶兩件事：(a) 旁通率可從三個溫度直接讀出，BP = (T_exhaust − T_return)/(T_exhaust − T_supply) = 0.43，與從風量比 1.75 獨立算出的值一致——型錄「75 °F 回風」那列的招牌數字本身就是一間旁通 43% 的機房，和 Salim & Tozer 現場「平均半數風量旁通」吻合；(b) 在這種機房加第五台 CRAH 會讓回風更冷、每台容量更低，aggregation 第五種，不是 sum。→ Dimension.limit(return_air_c) ＋ CapacityReport.assumed_return_air_c / basis（規劃中的機房量不到它，只能假設，所以假設必須被記錄）
一個資源被拆成兩個互相排擠的分量 dc-23 立的新分界：前 22 張每個 Dimension 各自獨立（dc-22 的 kW 與 CFM 雖被同一個盤管選型綁住，仍是兩個資源）。CRAC 的 sensible 與 latent 是同一個 total 的分量，受守恆式綁住。Liebert DS105（室外 35 °C、露點固定 52 °F）回風 23.9 → 29.4 °C：total 只 +8.4%（97.4 → 105.6 kW），sensible +23.0%（82.2 → 101.1 kW），SHR 0.844 → 0.957——對照 dc-22 的 CW 305 同區間顯熱 +42% 且 total 跟著漲。差別是壓縮機在箱子裡，total 被它釘住：回風變暖變乾買不到冷量，只是把潛熱容量重新分配成顯熱。→ SplitDimension(total, sensible, latent)，三者不可各自設 limit，SHR 是 derived_from 不是欄位。實務後果：加濕器開大顯熱容量就掉，而型錄那格 101.1 kW 不會變
站點量測正確，設備仍拿到錯的輸入 dc-23：dc-22 的旁通病在室外重演，而且沒有任何設施表會記錄。 MCL110 排 130 kW、風量 12 m³/s → 排氣溫升 8.95 K；T_進風 = T_站 + r × 8.95。四情境（敏感度 −1.6 %/K，由「110 °F 較 95 °F 低 20–30%」反推的粗略區間，不可用於選型）：35 °C/無再循環 → 101.1 kW；再循環 15% → 99.0；圍牆井 40% → 95.2；屋頂實測 40 °C ＋ 40% → 87.2 kW。最後一列與型錄 105.6 kW 差 18.4 kW ＝ N+1 那個「+1」被一個沒人量的溫度吃掉。數學結構與 dc-22 的旁通率完全相同（冷熱氣流混合比例），只是換到室外。→ Device.env_offset(source_var, basis) 預設必須是 unknown 不是 0。這是繼 dc-15「拓撲 vs 標註」、dc-17「站點級外生變數」之後的第三層。連帶：SiteEnvironment 要存配對時間序列——蒸發式吃濕球、氣冷冷凝器吃乾球，台北最熱乾球日與最高濕球日不是同一天，ASHRAE 本身就分 DB with MCWB 與 WB with MCDB 兩套表，同一個 scenario 下兩邊必須用同一小時的資料
ride-through 歸零，而報表是綠的 dc-23：機房 1000 m² × 4 m → C_room = 4840 kJ/K；1600 kW → 19.8 K/min；24 → 32 °C（ASHRAE A1 允許上限）只有 24 秒。而 anti-short-cycle timer 強制停機後休息 3–5 分鐘——市電掉、發電機 10 秒起來、ATS 切回，CRAC 仍在 rest period，300 秒對上 24 秒。dc-18 的 5.2 分鐘與 dc-20 的 15 分鐘全是水側慣量（前提是泵還在轉、盤管還有冷水），CRAC 沒有那一層。→ ride_through_s 是拓撲的函數（CRAH loop_volume/load 分鐘級；CRAC room_air_mass×cp/load 秒級），且必須與 restart_delay_s 成對判定 → Finding.RIDE_THROUGH_INSUFFICIENT，而它在任何穩態容量報表上都是綠的。另立 Dimension.kind 第三種 cycles：兩段式機 min_on 180 s／min_off 300 s → 最短循環 480 s = 7.5 starts/hr，發生在負載恰為銘牌 18.8% 時（新機房頭一年正好在那裡）；無 min_on 的舊機由死區寬度決定，±0.5 K → 7.9、±0.2 K → 10.0 starts/hr 已踩到渦卷建議上限——一個控制參數直接決定硬體壽命，結構同 dc-21 的 ModePolicy
誰有權動這個量 dc-24 立的新分界：前 23 張每個致動器管自己那台設備。濕度只有一個房間層級的量，卻有 N 台機各自能動它 → ControlGroup(variable, actuators, sensors, arbitration) ＋ Finding.OPPOSING_ACTUATION，而這個 Finding 在任何單一設備的報表上都看不見（繼 dc-22 AirBalance 之後第二個只有房間層級才看得見的病，且它每天都在發生）。根因不是邏輯寫錯——感測器漂移 ±3% RH 就足以讓相鄰兩台方向相反，LBNL 的比喻是同時踩油門和煞車。連帶：控制輸入第一次需要多感測器共識（SensorGroup(min_valid=3, outlier_policy)），且「單支讀數在合理範圍內、但與群體不一致」是第三種 invalid（前兩種：dc-15 錶失聯 stale、dc-19b 公式適用域失效）——Dimension.valid: bool 三種都裝不下。另立 resource 第四種 moisture（第一個「不流過任何設備」的資源，住 RoomReport）與 aggregation 第六種 mean_of_converted：不可對 RH 取平均（22 °C 55% 與 35 °C 24% 是同一團空氣、露點都是 12.5 °C），必須先各自換算再平均，是第一種聚合前要做單位換算的
本卡與 dc-21 正面衝突 dc-24：室內露點的下限 ≈ 盤管表面溫度 ≈ T_chws + approach。 7 °C 冰水 → 下限 9–10 °C（合規）；18 °C 冰水 → 下限 20 °C，永遠壓不到 ASHRAE 建議上限 15 °C。而 dc-21 的結論正是「拉高 chws_setpoint 換 free cooling 小時數」——衝突點只有在台北才會爆（乾燥氣候室外露點本來就低於 15 °C，18 °C 冰水一樣合規；台北八個月高於 15 °C）。→ can_dehumidify: bool 是錯的欄位，要存推導值 min_achievable_dew_point_c = f(chws_setpoint, approach)：除濕能力會無聲消失，型錄照印、面板照按，按了只是水閥全開＋風扇降速，凝水盤沒有水、零告警。另：同一個設備在兩棵樹上符號相反（首例）——20 kg/h 需求下蒸汽式是電力樹 +15 kW，超音波式是電力樹 +1 kW 而熱樹 −12.5 kW（蒸發吸熱＝白拿的冷量）；dc-22 的 FanHeat 是同一個量出現在兩棵樹，這裡是異號，任何把熱側貢獻寫成 abs() 的程式碼都會算錯。台北全年不需要加濕（月均值 Magnus 推算：1 月 DP 12.5、7 月 23.6 °C，4–11 月八個月超上限、沒有任何一月接近下限）——照美規文獻配的加濕套裝有一半是死重
43% 不是熱力學，是 OSHA 的價格 dc-25 立的新分界：那個被引用到爛的「熱通道封閉省 43% 冷卻能耗、15% PUE」（APC WP135 Rev 2）不是設備性質。三個情境的溫度全部能用一個減法反推：冷通道封閉時房間＝熱通道（房間 = IT 進風 + 伺服器溫升），熱通道封閉時房間＝冷通道（兩者相等）。情境 1（不限制未封閉區）兩者 economizer 都是 6 218 小時、PUE 都是 1.65，完全相同；情境 3（房間 24 °C 給人待）HACS 是 5 319／1.69，CACS 是 0 小時／1.98——比完全不封閉的基準 2 814／1.84 還糟。43% 全部來自一個人因法規門檻（OSHA WBGT：連續作業 30 °C、25/75 工休 32.2 °C）沿著那個減號一路傳到冰水設定值。而懲罰隨伺服器溫升放大：用 dc-22／dc-23 的現代 20 K 溫升，CACS 要房間 24 °C → 送風 4 °C → 冰水約 0 °C，不是比較差，是無解。→ 模型需要一類不掛在任何設備上、卻能決定 chws_setpoint 的 HumanFactorConstraint。來源分歧：Intel／T-Systems 德國實驗機房實測論文標題直接是「Reveal No Significant Differences」——兩邊都對，差別只在有沒有把人因約束算進去
消防有權改寫容量模型的前提 dc-25：Dimension 的第四種 invalid，而且觸發者在模型外。 前三種（dc-15 錶失聯 stale、dc-19b 公式適用域失效、dc-24 群體不一致）都是感測或模型的問題；drop-away 頂板在煙偵動作後落下是物理世界真的變了，而幾乎沒有廠商提供 ceiling_panel_state 點位。後果：dc-22 的 CapacityReport.assumed_return_air_c 在一次火警演練後的數小時內是錯的，零告警。→ Containment.integrity 必須三態（缺回授點位時是 unknown，不可當 intact）＋ AirBalance.valid_while ＋ Finding.CONTAINMENT_DEGRADED。連帶兩件：(a) fault_domain 第一次不能是單一欄位——封閉通道的邊界是幾何不是接線，同一通道的機櫃可分屬不同 rack PDU／不同 UPS 母線 → {power, cooling, containment}，壓成字串會把「一條通道整條熱掉」歸到錯的故障域，且 rack → aisle 要靠座標算（dc-28 空間層級第二次被提前需要）；(b) MaintenanceRule.trigger 第一次不能是 cron——退化由 MAC 次數驅動不由時間驅動
ride-through 再降一層：幾何的函數 dc-25：同一間機房（1000 m² × 4 m、1600 kW、ρcp = 1.21）、同樣設備，換封閉型式差 5.3 倍。熱通道封閉的冷空氣庫存是房間 3 770 ＋ 地板下 600 ＝ 4 370 m³（5 288 kJ/K）→ 24→32 °C 撐 26 秒；冷通道封閉只有通道 230 ＋ 地板下 600 ＝ 830 m³ → 5.0 秒，連發電機起動的 10 秒都撐不過（dc-23 的參考值；CRAC anti-short-cycle 還要 300 秒）。dc-20 的 15 分鐘與 dc-18 的 5.2 分鐘全是水側慣量，前提是風扇還在吹 → 結論不是「加儲冷槽」而是「CRAH 風扇上 UPS」。這是 dc-18 之後第二個「加強某一項反而讓另一項變糟」的案例。來源分歧：Upsite 把「更多冷源表面積」列為冷通道封閉的優點，與此帳相反（可能指地板與樓板的固體熱質量），未能確認，兩說並列
法規門檻跨轄區不可比 dc-25：加州 Title 24 §140.9(a)6 是規範性氣流阻隔要求，門檻是每機房 ITE 設計負載，2016 版 175 kW → 2022 版 10 kW（降 17.5 倍，有 CFD 等效例外）；台灣是經濟部依《能源管理法》第 16 條 2025-11 修正三項子法，門檻是站點能源使用數量 5 MW，要求為「新設／擴建前提能源使用先期規劃送審」，7 大檢核項目第 4 項即「冷卻系統：設計冷熱通道，採用液冷技術」，並訂 PUE 上限（超大型 1.3／主機代管 1.4）。10 kW 與 5 MW 不能比大小——度量的不是同一件事 → CodeRule.threshold 要是 (metric, scope, value) ＋ edition ＋ jurisdiction，四者缺一即錯（沿用 dc-09c）。實務結論：站點未達 5 MW 時台灣沒有強制封閉條文，封閉是自己的工程決定，論證要靠演算不能靠法規。 另：消防要把封閉當獨立防護區還是障礙物，Upsite 與 APC 說法不同，APC 直接寫「問當地 AHJ」——這是 AHJ 裁量，是專案輸入不是設計常識
kW 綠、風量紅 dc-22：resource 第三種 air_flow，且是第一次同一設備上兩個資源被同一個設計決定綁住（盤管選 11 K 還是 16 K ΔT_air，同時決定 kW 與 CFM 的比例）。kW 帳面充足而風量短缺時缺口只能由回流補上——伺服器吸自己的排氣，容量報表全綠、機櫃過熱。Uptime 原話：被動排熱設備「不可能排掉比 CRAC 送來的冷風更多的熱」。另需房間層級 AirBalance(bypass, recirculation, balance)，它推導不出任何設備的銘牌。連帶 MeasurementPoint.role 要分 control / compliance：ASHRAE 明文「規範只針對進入 IT 設備的空氣」，CRAH 全綠與某櫃頂進風 38 °C 完全相容
同一筆 kW 出現在兩棵樹上 dc-22：dc-17／dc-19 的橫向邊傳的是「影響」，風扇熱（14–22 kW）傳的是同一個量——電力樹的葉負載（掛 UPS 就吃 dc-19 記的 UPS 容量）＝熱樹裡這台機要再排掉的熱 → FanHeat 不能各記一份。而「net sensible」這個詞不指同一個量：Vertiv 註腳明寫已扣風扇熱（可從水側反推 14–15 kW，兩列獨立吻合），Uptime 附錄 C 則註記「reduced by 7.5 kW × 3 = 22.5 kW for fans」——標 90 kW 的機實際只有 67.5 kW。→ capacity_basis 是第三個「不能是數字、要能指向一份文件」的欄位（前兩個：dc-12 derating_basis、dc-15 accuracy）。另：CRAH 備援吃的是要賣的白空間本身（電力側沒有設備會這樣）——Uptime 模型同機房同樣 4 台，N+2 → 40 櫃 × 4.5 kW = 180 kW、N+1 → 52 櫃 × 5.2 kW = 270 kW，少一台備援多 50% IT 容量、零額外資本支出 → RedundancyPolicy.footprint_m2
free cooling 是設定值買來的 dc-21 的實務結論：門檻濕球 = T_chws − a_tower − ΔT_load(1−ε)/ε。取 a_tower = 4 K、ΔT = 6 K、ε = 0.75 → 7 °C 冰水門檻 1 °C（台北一年 0 小時）、18 °C 冰水門檻 12 °C（冬季可觀）。塔加大只能把 a_tower 4 → 2（門檻 +2 K），冰水 7 → 18 是 +11 K——先確認自己在哪一列再談設備。而 chws_setpoint 的真正擁有者在 IT 側（機櫃進風上限 → 盤管選型 → 冰水設定），這是「設施 vs IT 管理平面」第三次穿越（前兩次：dc-16 的 iDRAC psu_policy、dc-19 的 BMS 流量變化率）：IT 把進風上限從 27 收到 22 °C 會砍掉整年 free cooling，而沒有任何一張設施表會顯示這件事發生過
待收斂的 model code 38 項（2026-09-20 W38 週報 新增四項，全部有明確載體：Check enum 固定四＋一態（UNDETERMINED）＋ invalid_reason: Literal[...]；AirBalance 拆 AisleAirBalance / RoomAirBalance；room_thermal_mass_kj_k(geometry, include_underfloor) 取代兩處手算常數；Finding.kind 四值。W38 優先序刻意只排三項、全部 < 15 分鐘、全部走「掛進 dc-26 的註解」這條已被證明有效的路徑：(1) dc-23 的 SplitDimension 接進 RoomReport、(2) Check enum 收斂、(3) dc-16 的 50.5% → 58.4%（第三次排，再不做就除名）。energy_kwh() 改名已除名；2026-09-17：dc-25 新增三項——Containment.integrity 三態 ＋ AirBalance.valid_while ＋ Finding.CONTAINMENT_DEGRADED（第四種 invalid，觸發者在模型外）、fault_domain 拆成 {power, cooling, containment} 多軸集合、MaintenanceRule.trigger = schedule \| event_count；另 dc-25b 將帶來一項收斂而非擴充：RTI = 1/λ = 1 − BP 三者恆等，dc-22 的 AirBalance.bypass 要改存 lam、其餘降為 property——這是第一個「後面的卡把前面的欄位刪掉」而非疊加的建議；2026-09-15：dc-24 新增三項——resource="moisture" ＋ aggregation="mean_of_converted"、ControlGroup ＋ Finding.OPPOSING_ACTUATION ＋ SensorGroup(min_valid=3)、min_achievable_dew_point_c 為推導值且熱側貢獻可為負；2026-09-14：dc-23 新增三項）。 W35 清掉四項舊帳（DeviceRegistry ✅ 欠四週終於兌現、Bound 值物件 ✅ 用在 Angle(deg, kind)、Alarm／Finding 循環依賴澄清 ✅、兩棵樹橫向邊 ✅）。新第一順位是 Finding 定義 ＋ 三處 validate() -> list[str] 改回 list[Finding]；第二順位 CapacityReport 統一（dc-11／dc-12／dc-13 三種回傳型別互不相交）。dc-14（2026-08-31）的動手練習就是把這兩項一次做完，並用 rack PDU 當第四個實作者驗證 binding 會跑（30 A 機 binding = 進線、50 A 機 binding = bank 斷路器）。Method 因此新增 vector_sum。dc-09 的 energy_kwh() 改名連續第二週掛第一順位卻沒做，10 分鐘。dc-15（2026-09-01）再加兩項：Method 新增 measured（remaining 要用誤差帶的保守端，不是點值），以及 Dimension.valid 從 dc-14 定義至今第一次真的被用上——錶失聯時實測維度是 stale 不是 0，要退回 nameplate 法並吐 METER_STALE 的 Finding。dc-16（2026-09-02）再加一項且優先級最高：CapacityReport 要多一維 scenario（normal / lose_a / lose_b），binding() 取跨情境最壞值。這是第一個會讓既有數字變壞的維度——10 kW 機櫃從「每側 50.5% 綠燈」翻成「failover 116.8% 紅燈」，所以它不能排隊，得跟 Finding 一起做。dc-17（2026-09-03）再加三項，其中一項是目前為止對既有 code 最大的一刀：(a) Dimension 新增 resource 與 unit，binding() 改成 per-resource 回傳——水是第二種資源，kW 不能跟 L/min 比大小，這會動到 dc-11 之後每一個實作者；(b) Dimension.limit 從 float 變成 limit(env)，CapacityReport 必須記 evaluated_at_env；(c) Method 新增 curve（廠商性能曲線），與 nameplate / measured / vector_sum 並列。dc-18（2026-09-04）再加三項：(a) CapacityReport 新增 converged / iterations / residual_k——冰機容量要用固定點迭代解，不收斂的報表必須能明講自己不收斂；(b) Dimension 新增 lower_limit，違反時吐 UNDERLOADED 而非 OVERLOADED（處置方向相反）；(c) Finding 新增 PROTECTION_TRIP_PREDICTED，與 OVERLOADED 並列不可合併。dc-19（2026-09-07）再加三項：(a) Dimension.aggregation 必須是欄位——兩台泵並聯只給 1.14 倍流量（87.3 vs 152.9 L/s，相加會高估 75%），這是 sum／vector_sum 之後第三種聚合，程式裡任何一處寫死 sum(...) 都是還沒發現的 bug；(b) Constraint 第一次要作用在時間導數上（|dQ/dt| ≤ limit），且該值住在 BMS 控制序列不在銘牌 → RateConstraint(max_pct_per_min, source, commissioned_at)；(c) Limit 要帶 basis 且同一維度可有多個上界（流速 12 ft/s vs 墊片 22.5 ft H₂O/pass），min_flow 則是函數不是欄位（線性 ＋ 50% 地板，寫錯會凍裂管束）。dc-20（2026-09-08）再加三項：(a) Dimension 新增 kind = power｜energy，binding() 在 per-resource 之上再加 per-kind——儲冷槽存得下 400 kWh 卻只放得出 480 kW（能量 100%、功率 334%），一個 capacity 欄位表達不了兩個維度，而 kWh 與 kW 之間比大小沒有意義；(b) CapacityReport 新增 recovery_until——容量第一次是路徑的函數，放電後充回期間第二次事件不可存活，放電測試本身也開同樣的脆弱窗口；(c) MeasurementPoint 要有陣列型別 SensorArray(positions_m, values)，SoC 是沿高度溫度剖面積分出來的推導值，頂底兩點量不到 thermocline 也量不到 tilt。dc-19b（2026-09-09）再加三項：(a) Constraint 必須三態 satisfied / violated / not_applicable——HI 9.8 淹沒公式只在 v > 0.61 m/s 成立，VFD 降到 41% 流量以下時該約束不適用而非滿足；這是 Dimension.valid 第一次因公式適用域失效（感測器好好的，是模型不成立），壓成 bool 會在低速時回報綠燈；(b) MeasurementPoint.range_min ＋ SENSOR_CANNOT_REPRESENT——吸入端裝普通壓力錶時負壓讀成 0，BMS 收到「正常」，這是 dc-15「錶失聯是 stale 不是 0」的孿生錯誤：這次錶是好的，是量程說不出危險；(c) expansion_tank_connection_point 是拓撲欄位，決定泵自身揚程在 NPSHa 算式裡的正負號（接吸入側 30.6 m，接出口側 −14.6 m、入口閃蒸）。W36 週報 結算 W35 六項優先序：#1 Finding ✅、#2 CapacityReport 統一 ✅（但五天內被五次正交擴充）、#3 continuous_factor 🔴、#4 Breaker／Panelboard 合併 🔴、#5 energy_kwh() 🔴 連續第三週、#6 Constraint 基數 ⚠️ 決定不走。本週新增六項，兩紅：#1 CapacityReport 已不是一個型別而是三個（五層正交擴充：向量和／誤差帶＋stale／情境／資源＋環境／迭代解）；#2 Finding 只有 severity，還需要 kind 與 lifecycle；#3 dc-16 驗收表算錯的數字（見上一列）；#4 Bound 與 Dimension.remaining: float | None 打架；#5 Method 混了兩件正交的事且已長到 8 個值；#6 方法命名第三次漂移。規律第三次成立：寫成可貼 code 的建議會被採納，需要跨卡重構的不會——所以 W36 六項全部寫成可貼的 dataclass。#1 與 #2 必須在 dc-19 動筆前做完（現在 30 + 20 分鐘；dc-19 是第六個實作者，寫完再做就是六張卡一起改）。dc-21（2026-09-10）再加三項：(a) CapacityReport.mode ＋ per-mode 的 binding()——binding() 至此是 per-resource（dc-17）× per-kind（dc-20）× per-mode，且這是第一個內生維度（前兩個都是外生的環境或故障情境）；(b) ModePolicy(enter_wb_c, exit_wb_c, min_dwell_s)，模型裡第一個帶記憶的約束，切換時要吐 recovery_until；(c) Dimension.proxy_for ＋ clean_baseline 是曲線不是單點——熱衰減只能從液壓側可靠偵測（同流量 ΔP +15–20% vs clean），而 ΔP ∝ Q^1.8，70% 流量時期望值是 23.7 不是 45 kPa，不對齊流量就比較 ΔP 會把節流看成變乾淨。這是繼 dc-09b 電池 baseline、dc-19 rate limiter 之後第三個「沒有 commissioning 產出就沒有告警規則」的欄位。dc-22（2026-09-11）再加三項：(a) Dimension.limit(return_air_c) ＋ CapacityReport.assumed_return_air_c / basis——容量的自變數第一次是負載自己造出來的室內狀態，規劃階段量不到只能假設，假設必須被記錄；(b) resource="air_flow" ＋ 房間層級 AirBalance(bypass, recirculation, balance)，且 aggregation 新增第五種（共用靜壓箱，加機會拉低每台容量，不是 sum）；(c) capacity_basis（風扇熱扣了沒）＋ MeasurementPoint.role = control｜compliance ＋ RedundancyPolicy.footprint_m2——三者都是「同一個詞在兩份文件裡不同意思」或「同一個讀數用途不可互換」造成的。W37 週報 結算 W36 六項：全紅、零兌現（含那個標註 5 分鐘的 dc-16 數字修正；energy_kwh() 改名連續第四週）。W37 新增六項，三紅：#1 🔴 Dimension 被 dc-20 重新定義而非擴充——實際貼出來的是 6 欄位、非 frozen 的版本（value ＋ limits: list[Limit]），把 remaining／used_pct／method／valid／scenario／lower_limit 六個欄位（分屬 dc-14 ~ dc-18 五張卡）一次覆蓋掉，而 dc-19b／dc-21／dc-22 三張卡接的都是這個新版本。valid 的消失最危險：它正是 dc-15「錶失聯是 stale 不是 0」的載體，而 dc-19b 本週又給了同一欄位第二種語意（公式適用域失效）→ 收斂版改 status: Check 三態 ＋ invalid_reason，且 lower_limit 不可併進 limits（要用 Limit.sense，上下界處置方向相反，min(limits) 會直接算錯）。#2 🔴 dc-22 沒用 CapacityReport，發明了 RoomReport——而這次是對的：AirBalance(bypass, recirculation, balance) 推導不出任何設備的銘牌，entity_id 指向什麼沒有答案 → 模型第一次真的需要「房間」這個層級。但要明訂邊界（凡是「從三個以上設備讀數推導、且不對應任何銘牌」的量住 RoomReport），且 RoomReport 要引用而非複製設備層報表。#3 🔴 「值 ＋ 出處」家族第五次，而且是同一週、同一個名字、三個不同欄位集：Limit(value, basis, source, fetched_at)(dc-19)／Limit(value, basis, source)(dc-20)／Limit.basis ＋ solved(dc-19b)；連帶時間欄位四個名字三種語意（fetched_at 取得時間 vs commissioned_at／measured_at 建立基準時間——同義不同名 vs recovery_until 有效期終點）。這正是 W36 Sourced[T] 要解的，現在有五個未合併實例。#4 🟡 Constraint 三態（dc-19b）與 Dimension.valid: bool（dc-14）正面衝突，各自表達 invalid 的一半，壓成 bool 會在 VFD 低速時回報綠燈——而低流量正是實際運轉時間最長的工況。#5 🟡 aggregation 從 3 種變 5 種，且第五種還沒有名字（建議 shared_plenum）；五種裡有三種需要設備以外的上下文（系統曲線／房間 AirBalance／槽的幾何），純函數 sum(...) 的簽章裝不下，趁只有五種時改成可註冊策略。#6 🟡 Method 已 9 個值且混了兩件正交的事（資料從哪來 vs 怎麼算出來）——dc-19 要「解交點」、dc-19b 用 Limit.solved 表達同一個區別，兩張卡兩個欄位；拆成兩軸是 9 → 4+5。但這是跨八張卡的重構，依 W37 修正後的規律不會被採納，除非先有 topics/model.md——誠實記下，不要第四次排進優先序然後第四次跳票。dc-23（2026-09-14）再加三項：(a) SplitDimension(total, sensible, latent)——第一次「一個資源被拆成兩個互相排擠的分量」，三者不可各自設 limit，SHR 是 derived_from；把 sensible_capacity_kw 存成獨立欄位，露點一變它就悄悄錯了；(b) Device.env_offset(source_var, basis)，預設 unknown 不是 0 ＋ SiteEnvironment 改存配對時間序列（乾球與濕球必須取同一小時）；(c) Dimension.kind 第三種 cycles ＋ capacity_steps: list[float] | "continuous" ＋ ride_through_s 與 restart_delay_s 成對判定。⚠ (a) 與 W37 #1 直接衝突：Dimension 已被 dc-20 重新定義過一次，dc-23 又要在同一個型別上加分量關係——topics/model.md 若再不建，這會是第二次在未收斂的型別上疊結構****
容量計算變成解聯立 dc-18 立的新分界，也是本軌跡至今對計算模型最深的一刀：前 17 張每一張的容量都是沿路徑的純函數（下游不影響上游）。冰機的 limit 依賴冷卻水溫，冷卻水溫又依賴冰機自己的排熱——互為因果的正回饋迴路，只能解不能算。dc-18 也因此推翻了 dc-17 那張「WB 30 °C、4 格、用率 142%、紅燈」的表：那是在「冷卻水恆定 32 °C」的錯誤前提下算的，聯立解出來其實收斂在 32.9 °C、綠燈。真正的紅燈是「解出的平衡點超過保護設定值」（WB 30／2 格 → 35.8 °C > 冷凝器進水上限 35 °C），而那一列的容量用率看起來完全正常
冗餘會反咬 dc-18：冰機有下界（min_load_pct，離心機典型 25–30%）。3 台 × 250 RT 跑 136 RT 時三台並聯每台只剩 18% → surge／熱氣旁通純燒電；只開一台則另兩台成冷備，重啟要好幾分鐘，ride-through 需求反而上升。這是第一個「加冗餘反而讓事情變糟」的案例 → RedundancyPolicy 要能表達熱備 vs 冷備，不能只有 N+1 這個標籤
兩棵樹的邊變成雙向 dc-17 建立的橫向邊方向是電→熱；dc-19 補上熱→電：為了熱側的 ride-through 把三台 30 kW 泵掛上 UPS，UPS 負載 1600 → 1690 kW（+5.6%）、runtime 10 → 9.5 分鐘。這是第一次「為了熱側的可用性去吃電側的容量」 → 電力樹的葉負載清單必須包含冷卻設備，否則 UPS 的 CapacityReport 是錯的。Uptime Tier IV 是唯一明文要求 continuous cooling 的等級
能量 ≠ 功率 dc-20 立的新分界：前 19 張所有 Dimension 的單位都是率（kW／A／L/min／kVA）。儲冷槽同時受能量與功率約束且兩者互不蘊涵——細高槽（H=10 m、D=2.93）存得下 400 kWh_th（能量 100%），擴散器卻只放得出 480 kW（功率 334%）：不是撐不到 15 分鐘，是撐 0 秒。而 binding 是誰取決於採哪套判準：矮胖槽（L=17 m）在 Fr≤1.0 下 binding 是 Re（1 116 kW，143%），在 Fr≤0.5 下 binding 是 Fr（884 kW，181%）——Fr 擋住可加大開口 h（∝ h^−1.5），Re 擋住只能加長 L（與 h 無關），選錯 basis 會把錢花在改不動的地方。這是 Limit.basis（dc-19 立的）第一次改變的是改善動作而不只是數字
第二個要迭代的設備 dc-20：dc-18 迭代的是運轉狀態，dc-20 迭代的是設計參數——為了讓功率過關把開口 h 從 0.15 加到 0.22 m → 死區 1.5 → 1.64 m → usable_fraction 62.5% → 59% → V_geo 91.7 → 97.1 m³ → 直徑變大 → L 變長 → Fr 又鬆了。另：usable_fraction 是幾何的函數不是 0.9 這種常數（H=10 m → 85%；H=4 m → 62.5%，同一個 400 kWh_th 需求矮胖槽要多裝 36% 的水）。冗餘也第一次無法靠加大單體達成：兩倍大的槽仍是單一容器，破管／汙染／清洗停用時 ride-through 一次歸零且是隱性的
第一個需要時間軸的量 dc-18：ride_through_s = f(loop_volume, allowed_dt, load, pumps_on_ups, restart_time) 橫跨冰機／泵／儲槽／UPS 四類設備，而 restart_time 本身又是回水溫的函數（Cundall 雪梨案例：回水太熱 → 重啟後蒸發器過壓 → 二次跳脫）。CapacityReport 這種穩態結構表達不了它 → 需要 TransientScenario
容量是環境的函數 dc-17 立的新分界：dc-16 讓容量多了離散的 scenario（3 個值），冷卻水塔多的是連續的環境自變數。冷水設定 32 °C 不變時，濕球 28→30 °C（approach 4→2 K）容量掉一半：4 格 × 650 kW 從 2 600 掉到 1 300 kW，而實需 1 850 kW——零設備故障、容量就已經不足。前 16 張卡的模型完全表達不了這種狀況。連帶：即時監控與容量規劃第一次需要不同的輸入（維護窗口可行性要用設計濕球算，不是今天的遙測值）
站點級外生變數 dc-17 立的第三類（繼 dc-15「拓撲 vs 標註」、dc-16「設施 vs IT 管理平面」）：濕球同時被水塔、冰機、free cooling 切換判斷、CRAH 除濕四處消費，掛在單一水塔下當 MeasurementPoint 會被複製四份且互相不一致 → 屬於 SiteEnvironment 時間序列，且常是推導值（乾球＋RH），要記 derived_from，RH 失效時走 dc-15 的降級路徑
兩棵樹第一次有真實流量 dc-17 是第一個同時是兩棵樹節點的設備：熱圖上的節點（上游冰機冷凝器、下游大氣）＋ 電力圖上的葉負載（風扇／泵／盆加熱器）。W35 收斂的「兩棵樹橫向邊」在這裡第一次被用上，且方向是電→熱：lose_a 要能傳播成熱側的容量損失，所以 dc-13 立、dc-16 參數化的 prefix_sum(edge, scenario) 需要一個熱側對偶
設施 vs IT 管理平面 dc-16 立的新分界（繼 dc-15 的「拓撲 vs 標註」）：Dell hot spare 開著時 A/B 分配是 100/0 不是 50/50，而這個設定住在 iDRAC，設施側任何一張表都沒有。psu_policy 要帶 source="redfish" ＋ fetched_at，會被伺服器管理員在設施不知情下改掉，變動時必須觸發容量重算。凡是「真相在 IT 管理平面」的欄位（PSU 政策、power cap、BMC 回報的實際功耗）之後一律走匯入＋TTL＋降級，不當設施側的靜態設定
樹變成 DAG dc-16：前 15 張建的是單父節點的樹，雙電源設備一來就是幾千個兩個父節點的葉子。沿樹的前綴和（dc-13 立的）要參數化成 prefix_sum(edge, scenario)；dc-10b 的 common-ancestor 測試從「幾台 STS」擴大到每一台伺服器，必須是查詢不是存欄位
dc-14 待回頭修 dc-16 記下 NetBox 斷點第二條（topic-10）：NetBox 有 PowerFeed.type = primary\|redundant，但機櫃用電率計算不看這個欄位——雙電源設備兩個 power port 各填 500 W，機櫃就顯示 1000 W（discussion #12837，至今未實作）。第一條斷點（dc-14 的 feed_leg 不支援 delta）是表達不了，這一條是算錯，後者更危險：它會給你一個看起來合理的數字
拓撲 vs 標註 dc-15 立的新分界：電錶不是電力樹上的節點，是掛在節點或邊上的觀測器（MeasurementPoint）。硬塞進樹裡的話每插一顆錶深度就多一層，dc-10b 的 common-ancestor 跳數會被污染。凡是「只看不供電」的東西（錶、感測器、CCTV、門禁讀卡機）之後一律走標註不走拓撲
dc-11 待回頭修 兩張卡各找出一個錯。dc-12：(1) ×0.80 不是常數，是「80% rated 斷路器＋列名外殼」這個組合的屬性（同一顆 400 A 差 8.7 個機櫃）→ 要 derating_basis；(2)「算得出來的一律不存」有例外——插拔式母線上相位是插法不是位置 → 把前提變成欄位 Panelboard.phase_mode。另 Pdu.kva_derated() 把 0.80 寫死，是目前唯一會改變既有數字的修正
dc-12 待回頭修 dc-13 找出一個錯：requires_outage_to_add_circuit: bool 不夠用。OSHA 2025-08-25 解釋函（引 NFPA 70E table 130.5(C)）確認 busway 插接箱插拔屬能量作業——不停機但要工單＋合格人員＋PPE。布林會把它錯分到「不用管」→ 改三態 change_class。另 Breaker／Panelboard 被 dc-11／dc-12 各定義一次且欄位不相容（load_kw 遺失 → dc-11 的不平衡計算會壞）

提醒：有時效性的事

機房在施工中，commissioning（系統測試調校）會在接下來幾個月內發生。整廠斷電測試、UPS 切換測試、發電機帶載測試——這些一次性且不可重現。

只要 commissioning 開始，中斷佇列，全部時間投進去。 事後補不回來。