跳轉到

資料中心學習軌跡

目標：在自建自營機房（新建中）建置 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 在這類設備上具體長什麼樣
遙測介面 協定 + 關鍵點位清單
故障域 它掉了誰跟著死、多久內有影響
維護特性 週期、是否需停機、停機時的替代路徑

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

導覽

進度

項目 狀態
佇列總數 73（2026-09-28 從 dc-30 拆出 dc-30b 線槽走線架；2026-09-21 從 dc-26 拆出 dc-26b CDU 額定與可比較性；2026-09-17 從 dc-25 拆出 dc-25b；2026-09-07 從 dc-19 拆出 dc-19b）
已完成 59
目前輪次 第五輪：主題卡（2026-10-23 由 topic-01 開工）。第四輪系統與協定 dc-38 ~ dc-45 已於 2026-10-22 完成。第三輪空間、消防、安全 dc-28 ~ dc-37 已於 2026-10-12 完成；第二輪冷卻鏈 dc-17 ~ dc-27 已於 2026-09-23 完成；第一輪電力鏈 dc-01 ~ dc-16 已於 2026-09-02 全數完成
下一張 topic-03 N / N+1 / 2N / 2N+1 的精確定義與差異（第 0 步：W43 🔴2＋🟡4 points.py 回寫）
🔴 80% 是熱的規則，不是跳脫的規則 topic-02（2026-10-26）。 UL 489 開放空氣 40 °C：100% hold、135% 才在 1 h 內跳——85% 跑一年也不跳，違規靜默，只能由軟體算。選型式 非連續＋1.25×連續 與載量式 連續 ≤ 80% 只在全連續時等價：50＋125 → 200 A，總量 ÷0.8 誤得 225 A。台灣 32 A 三相 80% 16 849 VA vs IEC 全額 21 062（差 4 212 VA）；26／18／20 A 平均「合規」但 L1 違規；2N 單邊平時上限 40%。100% 額定列名的是組合（外殼、90 °C 線 75 °C 欄）。W43 🔴1 落地：Finding(code, subject_kind, subject_id, result, kind)，驗收 #14 一次呼叫產出 VIOLATION＋DATA_QUALITY。來源分歧：100% 框架下限（VIOX 離群）、「IEC 100%」說法、台灣 100% 例外由設計者確認 vs NEC listed。
🔴 觀察者也有拓撲（W43 母題） 2026-W43 週報（5 張卡，10-19 ~ 10-23 滿週；10-22 的 dc-45 當輪未 commit，隔天補上）。 第四輪收尾：四張協定卡是 topic-01「實測值」的上游，每條路徑各有一種「成功的錯誤」（SNMP scale、IPMI 飽和、閘道器 hold-last、BACnet Out_Of_Service）。高估會被 MEASURED_ABOVE_NAMEPLATE 抓，低估不會：1600 W 機 IPMI M=4 卡在 1020 W → 配額 1224 W → 每 PDU 6 台、真實 8 842 VA 超降載 2.3%，topic-01 兩個告警都不響（配額由實測算出，錯誤流進兩邊），只有 PDU 計量對帳 RACK_POWER_UNRECONCILED 抓得到。觀察圖有自己的故障域（trunk／trap receiver／帳號組／管理網／閘道器），Point.via 只看得到閘道器。W42 收斂清單整份落地（dc-42 Result.reason＋單一 Point、dc-43 Coverage，已有 9 個 kind；機制「寫進 backlog 條目」第二次驗證）。W43 收斂清單（已同步寫入 backlog topic-02／topic-03 條目）：🔴1 Finding 連三週無形狀、本週 7 個 check_* 全回元組、15 個「缺東西」無 kind 可聚合 → Finding(code, subject_kind, subject_id, result, kind)（掛 topic-02 第 0 步）；🔴2 Point 一週長出 side／aggregation／via／age_bound_s／三種 time_basis 字串，points.py 未改，age_bound_s 是存起來的派生值 → TimeBasis、Aggregation(stat, window_s) 與 topic-01 MEASURED 共用、via: HopRef(kind, id)（掛 topic-03 第 0 步）；🔴3 effective（coverage vs BACnet 優先序）、kind（四種）、side（供需 vs PSU 側）、quality（回 Quality vs 回 Result）撞名 → effective_command、@observer_kind、Point.tap（掛 topic-02）；🟡4 UNSOURCED 被拿去裝三件事，建議新增 VALIDITY_UNSIGNALED、SATURATED；🟡5 假設值仍在預設參數（含來源分歧值 hi=4194302）；🟡6 dc-38／39／41 三個 Coverage wrapper 已在週報給出；🟡7 Figure.source="" 合法＝「值＋出處」第九次重開防線。
🔴 銘牌／降載／實測／配額：四種數字、兩個方向 topic-01（2026-10-23）。 同一 rack PDU 8 646 VA：銘牌 32 台、實測零緩衝 56、實測 ×1.2 47（Fan 2007：251 W 銘牌 vs 145 W 實測＝57.8%）。降載在供給側往安全修、在需求側往風險修。標籤電流標在最低電壓：台灣 220 V × 低壓電流＝高估 2.2 倍。峰值不可相加：40×6 kW＝240 vs 同時峰值 172.6 kW。NetBox 用電率＝Σ配額÷Σ降載，實測不參與；預設 120 V／15 A＝1 440 VA，三相填相電壓只得 57.9%。收斂：Figure(value, unit, kind, side, basis, source) 取代六個 Rating／Limit，dc-09 energy_kwh() 已知缺陷就是缺 kind。來源分歧：實測／銘牌比 26%–80% 無通用值；McFarlane 40–60% 兩種讀法；NetBox 文件 W vs 程式 VA。
🔴 閘道器：有自己輪詢週期的第二個觀察者 dc-45（2026-10-22）。 代理模式年齡＝916.7 ms＋5 s＝5.92 s；死設備每輪吃 1500 ms，1 台死週期 2.59 倍，第 3 台死就超過 5 s，健康設備年齡 10.28 s。collector 1000 ms＜閘道器 1500 ms → 例外碼 11 被記成 TIMEOUT，透通模式健康設備也逾時（1545.8 ms）→ TIMEOUT_NOT_NESTED。hold-last 讓 POINT_STALE 永不響；哨兵 −99 原始值＝−9.9 °C 在範圍內。A／B 路 UPS 共用閘道器 → GATEWAY_SPANS_REDUNDANT_PAIR（電力圖⨝觀察圖）。第十五個「缺東西」POINT_VALIDITY_UNSIGNALED。來源分歧：離線回例外碼 11 vs 4 vs 預設值、retries 含不含首次、Moxa 命名倒置。
🔴 裸值不是事實（W42 母題） 2026-W42 週報（5 張卡，10-12 ~ 10-16 滿週）。 五張卡各替同一個數字加一個限定語：不確定度（dc-37）、品質×年齡（dc-38）、時鐘來源（dc-39）、登記與驗證（dc-40）、暫存器表與字序（dc-41）。串起來：資料供應鏈由下往上流，最後一張 dc-41 其實是前四張的上游（30 台 9600 baud 一輪 1375 ms → BMS 有效取樣 ≥ 1.375 s，可觀測事件 ≥ 2.75 s，SER 是 1 ms，差 1375 倍）；「缺東西」告警家族（第七到十一個）的分母是 DCIM 清單，偵測「缺」的能力上限是清單準確度。⚠ W41 收斂清單本週零落地（dc-37~41 無第 0 步、仍用 (code, subject) 元組；W41 的指示沒寫進本表該列，W40 的有）。W42 收斂清單（請 dc-42 開工前讀，已同步寫入 backlog dc-42 條目）：🔴1 覆蓋查詢寫了四次、effective() 零次 → 做 Coverage＋effective（掛 dc-43）；🔴2 Point 三份定義、live 只看年齡不看品質（字序錯＝新鮮的壞值仍算覆蓋）→ 單一 Point，拆 last_attempt_ts_s／last_good_ts_s，kind 改 role（掛 dc-42 第 0 步）；🔴3 「不確定」四種拼法兩種意思、零個檢查回 Result → 只留 UNDETERMINED＋Result.reason（掛 dc-42 第 0 步）；🟡4 dc-37 Rack(id, aisle, pos) 是第三個 Rack；🟡5 假設值藏在預設參數；🟡6 時間欄位單位不一；🟡7 冷卻維度在容量帳本沒有生產者。間隔複習：dc-31（W40）、dc-24（W38）
🔴 沉默的失效（W41 母題） 2026-W41 週報（4 張卡、10-06 無卡）。 偵測迴路被隔離、門無 DPS、感測線被污染——狀態 Normal 而保護不存在，「缺東西」告警已有六個。串起來三條線：釋放鏈（161.7 s ＋ cross-zone）、同一條 UPS 分支養著鎖／PoE／漏水控制器／釋放盤四個彼此的證人（沒有跨系統共因查詢）、證據鏈（時間是唯一 join key，被 NTP 與稽核週期約束）。防火連動停 CRAH 是冷卻鏈的外生故障情境（我的推論，卡片未寫）。
🔴 Redfish／IPMI：BMC 與 rack PDU 是看同一條電的兩個觀察者 dc-44（2026-10-21）。 IPMI SDR 1 byte：12 V 軌步階 0.07 V；功率 M=4 上限 1020 W 靜默飽和，M=10 時 20 台最壞 ±100 W。對帳 8050−7600−300 = 150 W OK；讀成 PSU 輸出側 → −335.1 W；容差 1% < 量化誤差 → PRECISION_INSUFFICIENT。DCMI 3 h 平均窗把 900 W 尖峰抹成 522.2 W。Redfish 新 schema 9 GET vs 舊 4 GET，500 台 70 GET 262.5 s vs $expand 7.5 s。CVE-2013-4786 是規格缺陷無修補 → IPMI_LAN_EXPOSED。第十四個「缺東西」SERVER_POWER_UNATTRIBUTED（沿用 dc-43 Coverage）。來源分歧：Power/Thermal 棄用 vs OpenBMC 並存；DCMI 統計期間毫秒 vs ipmitool 印秒。
🔴 SNMP：語意在 MIB 文件，MIB 是有版本、會出錯的實體 dc-43（2026-10-20）。 scale 三種慣例（UPS-MIB 0.1 A、APC 0.01 kW、Raritan 讀 DecimalDigits）；counter 差值三態（繞回 496／重開機丟棄／能量被歸零）；1 Gbps 繞回 34.4 s、8 kW Wh 計 61 年。120 varbind：GetNext 121 次 vs GetBulk 13 次，300 台 145.2 s vs 15.6 s；60 s 輪詢吃掉 8 分鐘續航 12.5%。W42 🔴1 已落地：coverage.py（Coverage＋effective＋通用 uncovered），第十三個「缺東西」UPS_NO_NOTIFICATION_PATH 是第一個用它寫的告警。來源分歧：upsOutputSource RFC 自身 compliance 段寫錯（Errata 4831，4＝bypass、5＝battery）；SNMPv3 AES-192/256 非標準 USM。
🔴 BACnet：設備自描述，語意在實例；命令是優先序堆疊 dc-42（2026-10-19）。 role 由型別＋有無 Priority_Array 推導；16=40／10=60／8=100 有效 100，放開後 60→40→default。MS/TP 9600 baud 單次 RP 72.92 ms，11 master 讀 100 屬性 16.46 s（4 框 9.58 s、38400 為 4.11 s）。新告警 SUBNET_NO_BBMD（第十二個「缺東西」）、MAX_MASTER_TOO_LOW、DUPLICATE_MAC、COMMAND_OVERRIDE_STALE。W42 🔴2＋🔴3 已落在練習第 0 步。來源分歧：Event_State 值、Device instance 上限 4,194,302 vs 4,194,303；規範原文未讀到。
🔴 Modbus 只傳位元組：暫存器表是有版本的實體，輪詢時間是共享資源 dc-41（2026-10-16）。 125／123 是 PDU 253 的推論；RS-485 9600 baud 讀 10 暫存器 45.83 ms，30 台一輪 1375 ms 超過 1 s（上限 21 台），19200 則 687.5 ms（43 台）；十次單讀是批次的 5.5 倍。50.0 Hz = 0x42480000，字序錯解成 2.38e-41 仍是成功回應。新告警 ASSET_NO_REGISTER_MAP（第十一個「缺東西」）、WORD_ORDER_UNDECLARED、POLL_BUDGET_EXCEEDED。來源分歧：19200 baud 框間靜默 2.005 vs 1.83 ms（同站自相矛盾）；規範 PDF 抓取失敗，未讀原文。
🔴 DCIM 是被維護的資產記錄：容量取最先見底的維度，準確度隨登記率衰減 dc-40（2026-10-15）。 38U／8000 W／冷卻 7000 W、2U 450 W → 空間 19、電力 17、冷卻 15，取 15 卡在冷卻，擱置 8U＋1250 W。準確度 A(t)=(1−c(1−r))^t：c=3%、r=80% 掉到 90% 要 18 個月，r=50% 只要 7 個月。新告警 ASSET_UNREGISTERED／ASSET_NOT_DISCOVERED／POINT_ORPHAN（第十個「缺東西」，三集合差集）。來源分歧：範疇（white space vs 匯流）、市場 2.2B／4.7B／3.1B、導入 18 月 vs 6–9 月；60% 失敗率無出處不採用。
🔴 EPMS 的主角是時間基準：事件順序是三態 dc-39（2026-10-14）。 事件不確定度＝時鐘誤差＋解析度；PTP–PTP 門檻 2.2 ms、PTP–NTP 3.1、NTP–NTP 4.0（60 Hz 四分之一週期 4.17 ms），Δt 在門檻內為 INDETERMINATE。對時失聯（假設 20 ppm）203 s 後誤差超過四分之一週期。新告警 BREAKER_NO_STATUS（第九個「缺東西」）、BREAKER_STATUS_INCOMPLETE。來源分歧：PTP 精度 sub-µs／<100 µs／100 µs／1 µs／ns–µs；BMS-EPMS 合併與否（兩家皆廠商）。
🔴 BMS 是第三張圖：控制依賴邊；畫面上有值不等於有人在看 dc-38（2026-10-13）。 P 控制殘差 0.8 K（設定 24 → 實際 24.8 °C，露點 15.75 → 16.51 °C）；15 分鐘趨勢看不到 5 ms 事件（180,000 倍）；趨勢緩衝 1000 筆 = 10.4 天 vs 400 筆 = 4.2 天。同一句「BMS 掛了」依 standalone 可為無事或冰水機失控。新告警 EQUIPMENT_UNMONITORED（第八個「缺東西」）、POINT_STALE。來源分歧：BMS 管不管電、BMS-EPMS 該不該互通（三方皆廠商）；UFGS Buffer_Size 1000 vs 400。
🔴 感測器是進風口的代理；露點才是判準，讀值是區間 dc-37（2026-10-12）。 24 °C/60% RH 露點 15.75 °C 超過建議上限 15 °C；DP 15 °C 在 27 °C 只對應 47.8% RH。讀值區間 [13.94, 17.49] 橫跨限值 → IN/OUT/UNCERTAIN。10 排×20 櫃密度 25 vs 1200 顆（48 倍）。新告警 RACK_INLET_UNCOVERED（第七個「缺東西」）。來源分歧：密度每第 4/3 櫃 vs 每櫃 6 顆；濕度 20–80% vs 露點 −9~15 °C；溫變速率 5/20 vs 5 °C/20 h。
🔴 漏水覆蓋是對盛水設備的關係；線上距離不是地板座標 dc-36（2026-10-09）。 45 m 路徑讀 27 m → (20,7)；13 Ω/m，351 Ω → 27 m；精度 0.61 m+0.5%L；85 m 管線 30.5 m 繩要 3 條 vs 1524 m 型號 1 條。直驅閥 54.2 L vs 輪詢 79.2 L（排水盤 60 L）。新告警 LEAK_SOURCE_UNCOVERED（第六個「缺東西」）、LEAK_FLUID_UNDETECTABLE。來源分歧：最大線長 30.5 m / 1524 m / 9000 ft、定位精度；台灣法規與非導電液偵測型態未取得。
🔴 保存期間是區間、屬於攝影機群組；證據窗口被稽核週期約束 dc-35（2026-10-08）。 1 Mbps 連續一天 = 10.8 GB；40 支 2 Mbps 30 天 25.92 TB，80% 上限需 32.4 TB → RAID 6 8 TB 要 7 顆（6 顆差 0.4 TB）。分群（入口 90 天連續＋走道 30 天事件）39.4 TB vs 93.3 TB，省 57.8%。PoE 24 埠 250 W：class 3 依等級預留 16 支 vs 依實際 24 支。新告警 DOOR_NO_VIDEO_COVERAGE（第五個「缺東西」）、EVIDENCE_WINDOW_EXPIRED。來源分歧：PCI DSS 是否規定影像保存期、PoE class 7 功率、forasoft 自身算術；台灣法規未取得。wc -m 9778
🔴 門是邊、鎖是電力消費者、無 DPS 全盲 dc-34（2026-10-07）。 Wiegand 26 位元 255×65535 = 16,711,425，(123,4567) → 10111101100010001110101110；憑證身分鍵 (format, facility, number)。fail-safe 40 扇 × 500 mA = 20 A，不在 UPS 上則市電斷時整區開門；mantrap 5 人/分，60 人交班 12 分鐘。新告警 DOOR_UNMONITORED（第四個「缺東西」）。
🔴 釋放盤：cross-zone 讓一條迴路被隔離就使自動釋放不可達 dc-33（2026-10-05）。 Novec 1230 W=V/S×C/(100−C)，288 m³／20 °C：ISO 14520（5.3%）224.2 kg vs NFPA 2001（4.5%）188.8 kg（差 19%）；85% 規則 4.505%；煙進孔到藥到位 121.7+30+10 = 161.7 s（天真 81.6 s）。新告警 RELEASE_PATH_DEGRADED／RELEASE_LOCKED_OUT（第三個「缺東西」）。來源分歧：保持時間 10／5／30 分鐘、NFPA vs ISO 濃度與洩漏模型；NFPA／ISO 原文與台灣法規未取得。W40 交辦的 core.py／rack.py 收斂放進練習第 0 步
🔴 夾層裡的三個租客（W40 母題） 2026-W40 週報（4 張卡、09-30 無卡）。 地板下夾層同時被送風（dc-30）、線槽（dc-30b）、取樣管（dc-32）佔用，卻沒有聚合物件替它負責；dc-30b 槽長 → dc-31 perm_max 是第一條跨卡數值依賴（同一條 80 m 固定線，10 m 跳線 OK、15 m 跳線 VIOLATED）。連貫性檢視：🔴1 Rack 合一只合一半（dc-30 缺 mounts，dc-31 加分題的 Rack.mount 落空）；🔴2 Check 四份副本；🔴3 Sourced 文字要求、骨架規則表全是裸 dict。三項排進 dc-33 練習第 0 步（建 core.py／rack.py）。🟡 outer_w_mm vs width_mm、NemaClass 跨距缺分支、Alert vs Finding 撞名。間隔複習：dc-25（W38）、dc-18（W36）
🔴 VESDA 是取樣網路不是感測器 dc-32（2026-10-02）。 孔稀釋：單孔等效靈敏度 = 門檻×N/k（80 孔、0.1 %obs/m → 單孔要 8.0 %obs/m）；傳輸時間理想化推導 t=(L·A/Q)·H_N，60 m／30 L/min／10 孔 天真 41.6 s、修正後 121.7 s（假設值，不可設計用）。新 Finding DETECTION_COVERAGE_GAP（第二個「缺東西」告警）；來源分歧：傳輸時間上限 60／90／120 s 三套說法，標準原文未取得、不裁決
🔴 連線不等於一條線：固定線＋跳線＋降額，前後埠對應是資料 dc-31（2026-10-01）。 固定線 90 m ＋ 跳線 10 m = channel 100 m；28 AWG 跳線降額 perm_max = 102 − 1.95L（10 m → 82.5、15 m → 72.75，Fluke 的 73 四捨五入會超標，須 floor）；Cat 8 = 24 + 3 + 3 = 30 m、≤2 連接點。ZDA ≤144 連接／≤1 個／無 cross-connect（來源為 TIA-942 原版，942-C 未驗證）；直連僅限同或相鄰機櫃；942-C 交換器區機櫃寬 ≥800 mm。NetBox FrontPort/RearPort：(rear_port, position) 唯一，反轉面板使 A.LC3 → B.LC10。→ Cable.kind/awg/category、ChannelRule（來源沒說回 UNDETERMINED）、CHANNEL_TOO_LONG 等五告警，接 dc-30b Cable.route 與 dc-29 RackType.width_mm。來源分歧：100 m 非通用常數；interconnect 定義疑點；連接點是否含設備端插孔所有來源皆未說。wc -m 9503
🔴 資料線面積先滿、電力線重量先滿 dc-30b（2026-09-29）。 300×100 網格槽 25/40/50% = 169/271/339 條、50% 也才 20.3 kg/m；600 寬梯架 4C185 單層 11 條 93.5 kg/m。更正 backlog：B 級就夠，非 C 級。 填充率三種分母（面積／深度／NEC 表格）；地板下槽體積 −1%，但垂直擋 16.7% 截面、平行 0.5%。→ Pathway、Cable.route/od_mm/kg_per_m、route_independence()。NetBox 斷點第五條：Cable 無實體路由。wc -m 8613
🔴 機櫃用四個輪子壓在磚上：816 kg，而錯開半格沒用 dc-30（2026-09-28）。 NVL72 1360 kg、前重 60/40（假設）→ 兩顆前輪同一塊 600 mm 磚 816 kg；錯開 300 mm 後隔壁機櫃的前輪補進來，整排中間磚仍是 816。台灣廠商 700 型（中心點 700 kgf）不過；600 kg 傳統櫃只有 360——舊機房從沒被這題測過。第三層承重面：樓板（dc-28）／機櫃（dc-29）／磚（今天），total_weight_kg 有了三個消費者。風口磚不是常數：Tate 25% @24.9 Pa = 5.11 kW，風門全開 −31%（3.53 kW），Q ∝ √ΔP。Upsite 走線開口旁通表由面積比四格全數重現（21.9/12.3/78.3/64.3%）→ 一列 10 櫃各一個沒封的開口吃掉 14.4 kW；同表風扇節能欄照 P∝Q³ 重現不出來、不引用。→ TILE_OVERLOAD、TILE_LIFTED（第二個「缺東西」告警）、PanelRating.comparable_to()（值＋出處家族第八次）、Opening 給出第一個從幾何算出的 BP。來源分歧：磚載重測法三種（最弱 1 in²／中心點／設計載重）；滾動載重 10 次與 10,000 次不同輪子。初稿 11942 → 拆卡（地板 vs 線槽）。W39 兩項優先序本卡執行：Rack 合一（RackType.outer_w_mm/outer_d_mm ＋ Placement）、Sourced[T]（必填 evidence，snippet 不可參與計算）與 Check 五態定案，驗收表第 5 列：額定未知與只有摘要都回 UNDETERMINED。wc -m 9933
🔴 還債的一週（W39 母題） 2026-W39 週報：三筆舊債經「掛進下一張卡」還清——W38 #1 SplitDimension（dc-26 判斷接不上、交給 dc-27 接上）、空間層級被提前借用四次（dc-28）、dc-23／dc-25 雙熱容差 9%（dc-28 thermal_mass_kj_k(include_underfloor, exclude) 兩值都重現）。第一次有週報建議走完「週報 → backlog 註解 → 下一張卡判斷延後 → 再下一張接上」。繼承鏈本週一條直線、無分叉
🔴 Rack 兩天兩個版本（W39 連貫性 #1、#2） dc-28 Rack(id, x, y, rotation_deg, w, d, weight_kg) vs dc-29 Rack(id, type, starting_unit, desc_units, mounts)：除 id 外零共同欄位，而 dc-29 的 RackType 沒有外形尺寸——照 dc-29 加分題做會得到算不出樓板載重的機櫃。同時兩天用了 m／mm／inch 三種長度單位。已排為 dc-30 開工前第一項：RackType 補 outer_w_mm/outer_d_mm、座標進 Placement、長度一律帶單位後綴
🟡 Sourced[T] 被引用三次、定義零次 W39 #4：dc-27／dc-28／dc-29 都把 Sourced[...] 當既有型別用。另「搜尋摘要不寫入計算」這條寫作規則其實是資料欄位 → Sourced(value, source, evidence: first_hand\|relayed\|snippet, version, note)，snippet 由型別擋掉不入計算。排在 dc-30 開工前第二項，與 Check 五態正式版一起定案
⚠ 已知缺陷（不再排入優先序） W39 依 W38 承諾除名：(1) dc-16 的 50.5% 應為 58.4%（連排四週未修，檔內仍 8 處，以 W36 更正為準）；(2) dc-09 的 energy_kwh() 改名（W38 除名）
⚠ 鎖檔殘留第三次，擋了三天 dc-29 檔案 09-25 08:28 寫成，commit 到 09-28 10:10 才落地；W39 週報開工時 .git/index.lock 仍在，取得刪檔授權後才清掉，週報因此延到 09-28 完成。建議 dc-daily-card 收工改成「先取刪檔授權 → rm → ls .git/*.lock 驗證」三步
🔴 機櫃是一條半 U 整數軸，而空 U 是告警 dc-29（2026-09-25）。 U（EIA-310，44.45 mm）與 OU（OCP，48 mm）格線對不齊：44OU = 2112 mm = 47.5U，u_height 不帶單位制就每台錯 7%。位置標準形 ＝ 從底算起的半 U 整數，starting_unit／desc_units 只是視圖。回流會自我放大：T_in = T_s + r·ΔT/(1−r)，WP49 的 8 °C 在 ΔT 12 K 下反推 r ≈ 0.4；盲板片間縫 42U 累積 1.5U（Upsite）vs 0.38U（IEC 60297 公差，讀者留言）——來源分歧，差 4 倍。承重兩個上限：ORv3 實例靜態 1600／動態 1400／自重 150 kg → NVL72 1360 kg 整櫃推入動態只剩 40 kg。→ Rack.total_weight_kg 改推導值，同時餵 RACK_OVERWEIGHT 與 dc-28 FLOOR_OVERLOAD；USlot.state ＋ OPEN_U_IN_FRONT_PLANE——第一個由「缺東西」觸發的 Finding。NetBox 斷點第四條：無空 U 狀態、無靜／動態承重、無 U 單位制欄位
🔴 空間不是一棵樹 dc-28（2026-09-24）。 一棵嚴格包含樹（site → building → floor → room → aisle）＋ N 張覆蓋分區（fire / cooling / security / tenancy / containment，同類互斥、異類交疊）。防火區可跨兩房、租戶籠可只佔半房，塞進一棵樹必錯。→ Space ＋ Zone；fault_domain 多一個 fire 軸（「2N 但兩路同一防火區」＝拓撲獨立、空間不獨立）。NetBox 斷點第三條：Location 單一樹、RackGroup 扁平單值，表達不了覆蓋分區。W38 #5 收斂：Room.thermal_mass_kj_k(include_underfloor, exclude) 重現 dc-23 的 4840 與 dc-25 的 5287.7 kJ/K——兩張卡都沒錯，差在兩個沒寫下來的布林
🔴 同一台機櫃 9.80 kPa 與 20.8 kPa 都對 dc-28：GB200 NVL72 1.36 t、600×1068 mm。除底面積 → 20.8 kPa（點載重問題）；除分擔面積（含半冷半熱通道各 0.6 m）→ 9.80 kPa，超 TIA 最低 7.2、低於建議 12。傳統 600 kg 櫃只有 4.32 kPa——舊機房從沒人算過，AI 櫃第一次需要。台灣權威來源是結構計算書（建築技術規則構造編 §17「不在表列應按實計算」）。另：標高基準錯位（GL vs 1F FFL）0.45 m ≈ dc-19b 110% 流量的 margin −0.50 m → 標高一律 (value_m, datum_ref)。來源分歧：12 kPa 是全體建議（一般摘要）還是 Rated-3 要求（EPI）；NetBox Site 是一棟樓（官方）還是一個校區（社群）
🔴 兩條各自合理的約束，交集是空的 dc-27（2026-09-23）。 Vertiv DCD35 原廠（第一手）：35 kW @ 21 °C / 12 °C 進水 / 50% RH，空氣側 35 Pa @ 4900 m³/h → 排風溫升 21.3 K、盤管 ε = 0.703。進水溫下限＝露點 + 1.5 K（原廠露點上限 10.5 vs 進水 12），上限＝房間中性 T_室 − 9.0 K。24 °C / 60% RH 時下限 17.3 > 上限 15.0，窗口為空，而兩條約束各自都是綠燈；要保住窗口室內 RH 須 ≤ 51.9%——修正對象是 CRAH 不是門。→ SplitDimension 終於接上（W38 交辦）：RDHx 的 latent 由跨實體約束釘成 0，住 RoomReport；WaterTempWindow ＋ Finding.INFEASIBLE_WINDOW。另：DLC 的 30 °C TCS 餵門只收 17.7/35 kW → CoolingLoop.temp_class；捕獲率三個廠商說法（60–80% / 70/30 / 近 100%）無第三方量測條件 → HybridLoad(capture_ratio: Sourced[Range])，兩側設計值取區間相反端，130 kW 櫃合計要備 156 kW（120%）；被動門 observability = none，告警必須掛房間層
🔴 rating 裡有一格由受測方自己填 dc-26b（2026-09-22）。 Schneider 原文（本次取得第一手，非 dc-26 的轉述）明寫 ASHRAE 127 Add.B rating 的前提是「受測 CDU 依廠商指示設置」，並自己舉例：若廠商要求測試室拆掉濾網，ratings 會更漂亮，而 Addendum B 仍在制定中、沒有條文禁止。代價算得出來：1 MW CDU 標稱 300 kPa @ 1591 L/min，密閉迴路無靜揚程（dc-19b）、阻力 ∝ Q² → 拆濾網 1000 kW／裝上乾淨（−25 kPa）957 kW／堵到更換門檻（−50 kPa）913 kW，乾淨就差 4.3%、堵到門檻共差 8.7%（一個 20 櫃 × 45 kW 機廳約兩個機櫃）。→ Rating 第一次要帶測試時的機器組態，comparable_to() 回 False 不是 warning。「值＋出處」家族第七次，第一次出處裡有一項是受測方可調的；derating_basis 也多了第四種來源——不是外殼列名（dc-12）、不是環境溫度（dc-13）、不是內部導體與斷路器數（dc-14），而是測試室當天有沒有把濾網裝上去
🔴 同一顆濾網、兩個泵模式、一個合格一個判準 2 倍 dc-26b：Vertiv CoolChip 原廠 guide spec（第一手）給了硬判準——濾材流速 < 0.5 m/s ＋ 零濾材旁通，且濾網是每台泵各一個。全流量 1591 L/min → A_min = Q/v = 0.0530 m²；雙泵同時運轉時每個只吃一半 → 0.0265 m² 就過。於是一顆照「同時運轉」選的濾網，切到 run/standby 流速變 1.0 m/s、是判準的 2 倍，乾淨 ΔP 從 25 跳到 25 × 2^1.8 = 87 kPa ——全新濾芯就超過 50 kPa 的更換門檻，告警會說它髒了而它是新的。→ filter_installed: bool 完全不夠，要 (filter_installed, filter_area_m2, pump_mode)，而 pump_mode 是客戶下單時選的，不是設備常數。另 Dimension.consumable_state：濾網是第一個「耗材本身就是容量維度」的東西（前 25 張的耗材只住 MaintenanceRule），clean baseline 是第五個「沒有 commissioning 產出就沒有告警規則」的欄位（前四：dc-09b 電池 baseline、dc-19 rate limiter、dc-21 clean ΔP、dc-25b 差壓設定值），方向與 dc-21 相反——dc-21 拿 ΔP 當熱性能的 proxy_for，這裡 ΔP 本身就是自變數
🟡 凍結流量是為了可比較，不是為了預測 dc-26b：ASHRAE 的 TCS 流量在 100% 載點建立後，四個載點（100/75/50/25%）固定不變，所以「75% 容量」不是「把機器開到七成五」，是同一流量下回水降到 37.2 °C 時量到的熱量（7.2 ÷ 9.6 = 0.75 ✓）。後果在 COP：rating 假設泵不降速，現場一定降速（Vertiv 就是 TCS 差壓決定泵速——正是 dc-19 那個把指數從 3 壓到 2.1 的 DP setpoint 機制）。取輸入 15 kW（泵 13 ＋ 控制 2）：50% 載點 rating COP 33.3 vs 現場 99.4（3.0×）、25% 載點 16.7 vs 92.3（5.5×）。再加一層：Schneider 明文 COP 分母不含 FWS 側泵——兩台都標 1000 kW / 15 kW（published COP 皆 66.7），FWS 壓損 60 vs 30 kPa、η 0.7 → 實質 COP 57.9 vs 62.0（差 7%），而差額記在 dc-19 的帳上。這是「成本被記到別人的表上」的第一個具體案例
⚠ 二手筆記把兩個迴路的水質限值攪在一起 dc-26b：Dell 白皮書（第一手，引 ASHRAE TC 9.9 ＋ OCP）的表是兩欄——TCS/PG25 pH 8.0–10.5、硬度 <50、氯 <25、硫酸鹽 <25、銅 <2、鐵 <2；FWS/水 pH 7.0–9.0、硬度 <200、氯 <50、硫化物 <10、硫酸鹽 <100。而 dc-26 拆卡時備下的二手筆記寫「氯 <50 (304SS)、硬度 <30」——氯是 FWS 那一欄的值、硬度兩邊都對不上。→ WaterQualitySpec(loop, param, limit, source, version)，一個 chloride_ppm 欄位裝兩個迴路會錯得非常安靜。另：Dell 表沒有導電度與菌落欄位（二手筆記有 <1500 µS/cm、<100 CFU/mL）→ 兩份表不可合併，合併出來的那張沒有任何來源背書。順帶回頭修正 dc-26：fluid 光是模式欄位不夠——dc-26 取黏度比 1.8（25 °C 口徑）算 ΔP ×1.24，Dell 給 PG25 在 20 °C ~2.4 cP（水 ~1.0）→ 比值 2.4 → ×1.32，差 6 個百分點，而 dc-26 沒記求值溫度 → 物性必須是 props(fluid, temp_c)。同一份白皮書順帶驗證了 dc-26 另兩個假設值（cp ~3.9 ✓、ρ 1.03 ✓）
⚠ 搜尋摘要生出了原文沒有的句子 dc-26b 本次唯一一次摘要與原文對不上。 濾材商頁的搜尋摘要有「依工程經驗，clean ΔP 應控制在系統可用差壓的 20–30%」這句，本次抓到的原文頁裡不存在；原文只給數字例（TCS 500 GPM、泵差壓 12 psi、其他損失 7.5、clean 濾網 1.2、loaded 2.5），反算是 27% / 56%（我算的，不是它寫的）。卡片裡已標為不可引用。→ 取材規則要多一條：摘要裡的數字必須在原文頁找到原句才能寫進卡片。 另三個 dc-26 的斷言本次獲 Vertiv 原廠證據：水質可以是點位（導電度／濁度／pH 三感測走 Modbus RS485，但是選配，修正 dc-26 的「多半離線採樣」）、SCCR 65 kA 或 5 kA 依客戶選擇、ATS 為選配出廠加裝 → Device.embedded_power 的每一格都是選配欄位，不可由型號推定
✅ 鎖檔殘留第二次證實，收工 rm 沒有生效 2026-09-22 開工時 .git/index.lock 與 .git/HEAD.lock 兩支都在（09-21 dc-26 那次排程收工殘留），與 W38 節奏（一）記的「.git/*.lock 自 09-18 殘留到 09-20、收工的 rm -f 顯然沒有實際生效」同一個病、第二次發生。本次 rm 先回 Operation not permitted，呼叫 allow_cowork_file_delete 取得權限後再 rm 成功，並 ls 確認為空。→ W38 的建議應正式寫進 dc-daily-card SKILL：收工不是「rm 就好」，是「rm 之後 ls 確認為空，不為空就標紅回報」，且開工時就該預期需要重新取得刪檔權限（該權限每個 session 都要重拿）
🔴 ride-through 第一次短過發電機起動時間 dc-26（2026-09-21）。 情境 A（FWS 斷但 TCS 泵仍轉，迴路 1000 L、1000 kW）≈ 59 秒；情境 B（TCS 泵停，只剩冷板 0.1 L ＋ 1 kg 銅 → C = 0.778 kJ/K、1.2 kW 晶片）≈ 9.7 秒。階梯補完：dc-20 儲冷槽 15 分 → dc-18 冰水環路 5.2 分 → dc-23 機房空氣 24 秒 → 本卡 59 秒 / 10 秒。而 dc-05b 的發電機起動也是 10 秒——市電掉的那一刻，CDU 泵不在 UPS 上就是在賭起動抖動，這一題沒有安全餘裕。→ ride_through_s 不能掛在設備上，要掛在 (resource, failure_mode) 對上：同一台機兩個值差 6 倍且處置方向相反（去看冰機／HX vs 立刻降載，後者人來不及到現場）。dc-23 立的 Finding.RIDE_THROUGH_INSUFFICIENT 不帶 failure_mode 就判不出來，而 W38 才剛把它列為斷頭節點的產出之一
🔴 買 approach 更小的 CDU 換不回一個溫度等級 dc-26：無冰機可行性是一條加法鏈 WB + a_tower + a_HX + a_CDU ≤ T_TCS。取 a_tower = 4 K（dc-17）、a_HX = 2 K（dc-21）、a_CDU = 4 K（ASHRAE rating 值）：T_TCS = 30 °C → 允許濕球 20 °C（台北設計 28 °C，全年都要冰機）；T_TCS = 40 °C（W40 等級）→ 允許濕球 30 °C，全年不需要冰機。而 a_CDU 從 4 買到 2 只補 2 K，缺的是 8 K。結構與 dc-21 的「塔加大只能 a_tower 4→2，冰水 7→18 是 +11 K」完全一樣：要不要冰機不是氣候決定的，是設定值決定的。 但這次設定值的擁有者不是設施、也不是 IT 營運，是晶片／冷板規格書，採購當天就定死 → Setpoint.owner = ite_vendor ＋ mutable = False。「設施 vs IT 管理平面」第四次穿越（前三：dc-16 iDRAC psu_policy、dc-19 BMS rate limiter、dc-21 chws_setpoint），也是第一次穿不回來
🟡 冷卻設備第一次往電力模型裡長欄位 dc-26：方向與前三次相反。 CDU 內建 ATS ＋ ultracapacitor ＋ 雙電源 ＋ SCCR ＋ 諧波濾波器——全是 dc-07b／dc-10／dc-16 的語彙，卻長在一台冷卻設備肚子裡。→ Device.embedded_power(ats, energy_storage_j, sccr_ka)，且 dc-16 的 scenario 傳到熱側時 CDU 那一格不是「掉了」而是「撐 N 秒」，布林的掉電傳播在這裡會算錯。另 fluid 是模式欄位不是標籤（同 dc-14 的 wiring）：ASHRAE rating point（FWS 進 26／TCS 出 30／approach 4 K／TCS 回 39.6 → ΔT 9.6 K、TCS 側 PG25）下 1000 kW 要 1591 L/min（1.59 LPM/kW），同 kW 同 ΔT 改純水只要 1505（1.50）；差 5.7% 流量，加上 PG25 黏度約水的 1.8 倍 → ΔP ≈ ×1.24。對照 OCP OAI 指引 1.5 LPM/kW @10 K、可接受帶 1.25–2.0（7.5–12 K），1.59 落在帶內 ✓ → 流量不可以被存成設備常數
⚠ 「approach」跨兩個數量級，兩邊都叫 approach dc-26 來源分歧。 L2L 的 rating 條件是 4 K（ASHRAE 127-2020 Addendum B，經 Schneider 轉述，定義為 TCS 出水 − FWS 進水）；L2A 的實驗論文報 ATD 18.3 K（送風 31 °C、89 LPM → 89.9 kW；反推 0.99 LPM/kW、ΔT ≈ 15.4 K，已超出 OCP 的 7.5–12 K 帶——「做得到 89.9 kW」與「能在你的晶片規格內做 89.9 kW」是兩句話）。結構同 dc-16 的「ATS 跨兩個數量級」、dc-12 的「PDU 與 RPP 同一台設備兩個名字」。→ approach_k 必須配 sink_type ∈ {fws_water, room_air}，否則規格書寫「approach ≤ 5 K」供應商兩邊都能交差。⚠ ASHRAE 127 Addendum B 原文未取得且仍在制定中，rating 條件全部經二手轉述
✅ 拆卡第二次奏效（dc-26 初稿 12363） 2026-09-21：初稿 12363 字元，遠超 10000 → 依 W38 對 dc-25 的結論直接拆卡，不壓縮。 拆縫與 dc-07/dc-07b、dc-09/dc-09b 同一條：設備物理 vs 額定與制度。今天寫 dc-26（本體、approach 鏈、ride-through，wc -m = 9960），dc-26b（rating 可比較性與濾網 ΔP）明天寫，材料六條已在 backlog 該項下備齊。另 W38 連貫性檢視 #1 的交辦已部分執行：RideThrough 的加分題要求回填 dc-23／dc-18／dc-20 的三個數字並看有幾筆填不出 failure_mode——走的是「下一張卡的練習題」這條已被證明有效的路徑；但 SplitDimension 本身仍未接（CDU 沒有顯熱/潛熱分量，硬接是為做而做，dc-27 RDHx 有空氣側才是自然接點）
第一張主題卡開張 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 的「第一輪補完」那一節先留空，等使用者拿到圖再回頭插項目
週報 13 份（最新：2026-W43；2026-10-25 更正：此欄位自 W41 後未更新，W42 已是第 12 份）
下次間隔複習 W44：抽 W42 的卡（dc-37 ~ dc-41）＋ W40 的卡（dc-30、dc-30b、dc-32）。⚠ dc-31 已在 W42 抽過。（W43 已抽 W41 的 dc-34 ＋ W39 的 dc-29）
🔴 綠燈的四種死法（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 W43（2026-10-25 W43 週報）：W42 的 🔴1–3 與 🟡6 已在卡片層落地（dc-42／dc-43 第 0 步，待本機確認），🟡4（dc-37 第三個 Rack）、🟡7（冷卻預算無生產者）未處理、🟡5 部分；新增 3 個 🔴＋4 個 🟡——🔴 Finding 形狀（W41 起第三週）、🔴 Point 欄位擴張未回寫 points.py、🔴 四組撞名；🟡 Reason.UNSOURCED 語意漂移、假設預設值、三個 Coverage wrapper（週報已給）、Figure.source 可空。排序：topic-02 第 0 步（🔴1＋🔴3）→ topic-03 第 0 步（🔴2＋🟡4）→ topic-04（🟡5、🟡7、W42 🟡7）。 下列為 W41 原紀錄： W41（2026-10-11 W41 週報）：W40 三個 🔴（Rack 合一、Check 副本、Sourced 無防線）在卡片層已由 dc-33 第 0 步收斂（待本機確認）；新增 3 個 🔴＋3 個 🟡——🔴 Finding.space_id 被拿去裝 zone／door／camera／source、🔴 Door 三到四種形狀、🔴「有效觀測」判定三處各寫且 dc-36 對 contaminated／silenced 放行；🟡 「連到電」四種寫法、檢查函式 Result／bool 混用、above 混 Space 與 Asset。總數未重算（W40 新增項是否已併入 41 未見記錄），下次對帳。下列為 W39 原紀錄：*41 項（2026-09-27 W39 週報：+6 新增〔Rack 合一、長度單位、Finding 形狀、Sourced[T] 定義、ρcp 常數、CoolingLoop〕、−2 收斂〔SplitDimension 由 dc-27 接上、雙熱容由 dc-28 函數化〕、−1 降為已知缺陷〔dc-16 50.5%〕。下列為 W38 原紀錄）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 開始，中斷佇列，全部時間投進去。 事後補不回來。