2026-W39 週報：還債的一週¶

第九份週報。本週 5 張卡、5 個工作日，全勤。第二輪冷卻鏈在液冷段收尾（dc-26 ~ dc-27），第三輪「空間」開工（dc-28 ~ dc-29）。

這一週的主軸是還債。前面的卡和週報欠下的東西，這週還掉了三筆：

欠債	誰欠的	本週誰還
`SplitDimension` 斷頭（W38 優先序 #1）	dc-23 發明後沒有下游	`dc-26` 在 backlog 記下「接不上、留給 dc-27」→ `dc-27` 接上
空間層級被提前借用四次	dc-19b 標高、dc-25 通道、dc-25b `AirBalance`、dc-27 跨實體約束	`dc-28`
同一間機房兩個熱容差 9%（W38 #5）	dc-23 / dc-25 各算一次	`dc-28` 的 `thermal_mass_kj_k(include_underfloor, exclude)` 兩個值都重現

三筆都是從「掛進下一張卡」這條路還掉的，沒有一筆靠週報本身。W38 押的那個機制（建議寫進下一張卡的練習題，不要寫進另一份文件）本週第一次完整跑通。

但還債的同時也在借新債。本週最大的新債是 Rack 型別在連續兩天裡出現兩個互不相容的版本（〈連貫性檢視〉🔴1），而且兩天用了三種長度單位。

本週卡片¶

卡	標題	這張卡最關鍵的一個事實
`dc-26`	液冷 CDU	冷板 ride-through ≈ 10 秒，跟發電機起動的 10 秒同一量級。 TCS 泵停時只剩冷板裡 0.1 L 冷媒加 1 kg 銅（1.2 kW → 1.54 K/s）；TCS 泵不在 UPS 上，就是拿起動時間的抖動在賭
`dc-26b`	CDU 的額定與可比較性	ASHRAE rating 的前提是「依廠商指示設置」，而廠商可以要求拆掉濾網再測。同一台 1 MW：拆濾網 1000 kW／乾淨濾網 957／堵到換芯門檻 913 kW，最多差 8.7%，而且在任何 kW 報表上都看不見
`dc-27`	RDHx 與 DLC	24 °C / 60% RH 的房間，滿載被動門的進水溫窗口是空的：不凝結要 EWT ≥ 17.3 °C，房間中性要 ≤ 15.0 °C。兩條約束各自都是綠燈，交集是空的；解法在 CRAH（RH ≤ 51.9%），不在門
`dc-28`	空間層級	空間是一棵包含樹加 N 張覆蓋分區，不是一棵樹。防火區可以跨房間，租戶籠可以只佔半間；同一 `kind` 的分區互斥，不同 `kind` 之間可以任意交疊
`dc-29`	機櫃與 U 位	空 U 是第一個由「缺東西」觸發的告警。回流 `T_in = T_s + r·ΔT/(1−r)` 會自我放大：r = 0.4 時天真算法低估 40%，而 WP49 的「8 °C 熱點」反推回去正好是 r ≈ 0.4

串起來¶

一、從晶片到樓板，一條垂直線¶

前八週畫的都是水平的流：電從市電往下流，熱從機櫃往外流。本週五張卡疊起來是一條垂直的線，從一顆晶片一路畫到它壓著的那塊樓板：

 晶片 ── 冷板（0.1 L，泵停 ≈ 10 s）                        dc-26
   │
   ├─ 60–80% 熱 → TCS 迴路（30 °C，1000 L，泵轉 ≈ 59 s）    dc-26
   │                 │
   │               [CDU：板式 HX ＋ 泵 ＋ 濾網]               dc-26 / dc-26b
   │                 │   濾網吃揚程 → 掉流量 → 掉 kW，不告警
   │               FWS → 板式 HX / 冰機 / 冷卻塔             dc-21 / dc-18 / dc-17
   │
   └─ 20–40% 熱 → 伺服器風扇 4900 m³/h → [RDHx 後門]        dc-27
                    │    ↑ 要 ≤ 15 °C 的水，跟 TCS 不同溫度等級
                    │    ↑ 門的 35 Pa 背壓
                    ▼
               機櫃 U 軸：空 U ＝ 熱空氣回前面的洞            dc-29
                    │
               機櫃總重 → 動態／靜態兩個上限                  dc-29
                    │
               樓板：均佈 kPa（除分擔面積）／點載重          dc-28
                    │
               房間：熱容、露點（CRAH 除濕，dc-24）           dc-28
                    │
               防火區（覆蓋分區，可跨房間）                   dc-28 → dc-33

上半段是熱鏈的最末端，下半段是空間樹的最末端，兩者在「機櫃」這個節點交會。 這是本軌跡第一次有一個節點同時是熱鏈的葉子、空間樹的葉子、電力樹的葉子（dc-14）。前三輪各自建的樹，全部落在這個 600 × 1068 mm 的長方形上。

也因為這樣，本週的 Rack 型別漂移（〈連貫性檢視〉🔴1）比任何一次漂移都貴：三棵樹共用的節點，只能有一個定義。

二、跨卡演算：後門的背壓會替空 U 加壓¶

dc-29 的 WP49 原文說回流的驅動力是前後壓差，比熱浮力大得多。dc-27 的被動門在額定風量下有 35 Pa 的空氣側壓損，而推這 35 Pa 的是伺服器風扇。

把兩件事接起來：裝了後門的機櫃，伺服器與門之間那一段是被墊高的正壓區，任何一個空 U 都是這個正壓區通往前面冷側的洞。⚠ 這一段是兩張卡的推論，本週沒有查到「RDHx 機櫃缺盲板」的實測，不要寫進規格書。

量級可以用 dc-29 的公式、代 dc-27 的溫升來看。dc-27 算出來的排風溫升是 21.3 K（35 kW ÷ 1.64 kW/K），dc-29 用的是 12 K：

回流比例 r	ΔT = 12 K（dc-29）	ΔT = 21.3 K（dc-27 的門）
0.05	+0.63 K	+1.12 K
0.10	+1.33 K	+2.37 K
0.19	+2.81 K	+5.00 K
0.40	+8.00 K	+14.2 K

（r·ΔT/(1−r)，例：0.19 × 21.3 / 0.81 = 5.00）

同一個洞、同一個回流比例，在 AI 機櫃上的進風溫升是傳統機櫃的 1.78 倍（21.3 / 12）。 而背壓推論如果成立，同一個洞的 r 在 AI 機櫃上還會更大。兩個效應同方向疊加。

更麻煩的是誰看得到它。dc-27 說被動門「是遙測黑盒」，它的告警只能掛在房間層。但門把排風冷回 21 °C 才吹進房間，所以房間感測器看到的是一個一切正常的房間。唯一看得到的是 dc-29 表上那三支機櫃進風溫度（上／中／下），而 dc-29 說「上層偏熱是缺盲板的特徵」。

→ 對一台裝了被動門的機櫃來說，機櫃進風感測器是唯一能看見兩種故障（門斷水、盲板缺失）的點位，而它是 PDU 的選配附件。

三、本週五張卡，容量的關鍵輸入都不在設施手上¶

W37 觀察到「binding 搬出設備」，本週更進一步：binding 搬出設施部門。

卡	決定容量／判定的那個輸入	擁有者	設施能不能改
`dc-26`	TCS 允許進水上限（決定台北要不要蓋冰機房）	晶片／冷板廠	採購那天就定了
`dc-26b`	rating 測試時濾網裝了沒、面積、泵模式	受測的廠商	只能要求揭露
`dc-27`	推過門的風量 4900 m³/h	伺服器廠	換一批伺服器就變
`dc-27`	液體捕獲率 60–95%	伺服器韌體＋進風溫度	不能
`dc-28`	樓板均佈活載重、點載重	結構技師的計算書	蓋好就不能改
`dc-29`	動態承重有沒有含櫃體自重	機櫃廠（頁面沒寫）	只能問

六個輸入，零個由設施自己決定。Setpoint.owner = ite_vendor 在 dc-26 第一次出現，兩天後 dc-27 的 depends_on: [ite_device_id] 第二次出現。「設施 vs IT 管理平面」（dc-16 立的分界）從第三次穿越到第五次只用了一週。

這對 infra management 系統的意思很具體：這套系統的資料來源一大半不在 BMS 或 EPMS 裡，在採購文件、結構計算書、伺服器規格書裡。 dc-28 那句「稽核接受的前提是每櫃現重有資產系統在追」講的就是這件事：資產系統的欄位是認證證據，不是備註。

四、掉一個會連鎖到哪¶

連鎖 A：一張 MAC 工單少了一步

技術員下架一台 2U 伺服器（dc-29：盲板是唯一「維護會讓它消失」的元件）
   → 前面板多一個 2U 的洞
   → 背後是被門墊高的正壓區（本週推論）
   → 回流 r 上升；ΔT 21.3 K 下 r = 0.1 就是 +2.4 K
   → 上層伺服器進風變熱 → 伺服器風扇加速
   → 風量變了 → 門的容量前提（4900 m³/h）變了（dc-27）
   → 而門把排風冷回 21 °C，房間感測器一切正常

OPEN_U_IN_FRONT_PLANE 要能觸發，前提是 USlot.state 被改成 open，而這一步只有工單知道。第一個由「缺東西」觸發的告警，觸發條件取決於資料輸入的紀律。

連鎖 B：市電掉了，而 CDU 泵在錯的那一路

市電中斷 → 發電機起動 ≈ 10 s（dc-05b）
   → CDU 的 TCS 泵不在 UPS 上（dc-26 該問的問題 #2）
   → 冷板只剩 0.1 L：30 → 45 °C 約 9.7 s
   → 晶片降頻或關機；而 FWS 那一側的 59 秒緩衝根本用不上（泵停時不算數）

dc-26 意涵 #1 說得很清楚：同一台 CDU 的 ride-through 是 59 秒還是 10 秒，看斷的是哪一側。這條連鎖的時間尺度是本軌跡目前最短的：從起點到終點不到 20 秒，人不可能介入。

連鎖 C：整櫃推進來的那一段路（⚠ 本週推論，卡片沒算）

dc-29 的 move_state ∈ {static, in_transit} 只檢查機櫃自己的動態上限。但 in_transit 的機櫃會經過卸貨區、貨梯、走廊，那些空間的樓板等級可能都不是 dc-28 算的那間機房。1360 kg 的整櫃在走廊上是點載重（輪子）問題，dc-28 已經說點載重是另一個上限、而且本次沒取得數值。

→ move_state = in_transit 的檢查對象應該是一條路徑上的每一個 Space，不只是目的地。這是「空間層級」第一次被一個動作而不是一個位置需要。放進本週該問的問題 Q2。

自我測驗¶

Q1.（事實回憶）台北、塔 approach 4 K、板式 HX approach 2 K、CDU approach 4 K。TCS 供水要 30 °C 與要 40 °C 時，各自需不需要冰機？把 CDU approach 從 4 K 買到 2 K 能改變哪一個答案？

答案

加法鏈 WB + a_tower + a_HX + a_CDU ≤ T_TCS（dc-26 演算二），三個 approach 合計 10 K。 - 30 °C：允許濕球 ≤ 20 °C。台北設計濕球取 28 °C（dc-17 佔位值），全年要冰機。 - 40 °C（W40）：允許濕球 ≤ 30 °C，全年不需要冰機。 - a_CDU 4 → 2 K 哪個答案都改不了：30 °C 那列缺 8 K，買小 approach 只補 2 K。真正的槓桿是 T_TCS 本身，而它寫在晶片規格書裡，採購時就定死了。同型結論見 dc-21：塔加大只能讓 a_tower 4 → 2，冰水設定值 7 → 18 °C 卻是 +11 K。

Q2.（事實回憶）CDU 型錄上「100% 載點 COP 66.7、75% 載點 COP 50.0」。這個 75% 是怎麼量的？這個 COP 能不能拿來預測你的電費？

答案

75% 不是把機器開到七成五。 ASHRAE 127 Add.B 的條件（dc-26b 演算三，經 Schneider 原文）：TCS 流量在 100% 載點建立後，四個載點全部凍結不變；TCS 出水恆 30 °C，75% 時回水從 39.6 降到 37.2 °C（ΔT 9.6 → 7.2 K）。「75% 容量」是同一流量下回水變涼時量到的熱量。所以 COP 從 66.7 掉到 50.0（750 ÷ 15）不代表機器在七成五負載時效率變差，只代表分母被凍結在 15 kW。 不能預測電費：流量凍結代表泵功不降，而現場控制邏輯一定會變速。卡片的例子在 25% 載點差到 5.5 倍（rating COP 16.7 vs 現場約 92.3）。rating COP 是比較值，不是預測值。 另外 COP 的分母不含 FWS 側泵，兩台 published COP 都是 66.7 的機器，算進 FWS 壓損後是 57.9 vs 62.0（演算四）。 對你的模型：Rating 要帶 load_pct 與流量控制假設，而 comparable_to() 只能回答「兩份型錄能不能比」，回答不了「現場會用多少電」。這是兩個函數。

Q3.（應用）有人提案：「液冷區的 RDHx 直接接 CDU 的 TCS 迴路，少拉一條水管。」機房設計 24 °C / 60% RH。你怎麼回覆？

答案

不行，而且接冰水也不行，兩邊出問題的方式不同。 - 接 30 °C 的 TCS：Q = 0.703 × 1.64 × (45.3 − 30) = 17.7 kW，滿載 35 kW 的門只收一半，出風約 34.5 °C，另一半熱直接進房間（dc-27 演算三）。 - 改接 7 °C 冰水：低於 24 °C / 60% 的露點 15.8 °C，每一片門都在凝結，而凝結水盤原廠明寫「只供偶發凝結」。 - 根本問題：24 °C / 60% 時窗口是空的，不凝結要 EWT ≥ 17.3 °C，房間中性要 ≤ 15.0 °C。要讓窗口存在，室內 RH 要壓到 ≤ 51.9%，那是 dc-24 的 CRAH 除濕要做的事。 回覆應該寫：門需要獨立的 ≤ 15 °C 迴路（CoolingLoop.temp_class 與 TCS 不同），而且室內 RH 設計值要先定在 52% 以下，否則任何進水溫都不合格。修正對象是房間，不是門。

Q4.（應用＋建模）一台預先上架好的 AI 整櫃，設備 1210 kg，裝在 ORv3 櫃（自重 150 kg、靜態 1600、動態 1400 kg）。要推進一間 TIA 最低值 7.2 kPa 的機房，冷熱通道各 1.2 m。列出系統該吐哪些判定、各自用哪個數字，並指出哪一格應該是 UNDETERMINED。

答案

總重 total_weight_kg = 150 + 1210 = 1360 kg，一個推導值、四個消費者： | 檢查 | 算式 | 結果 | |---|---|---| | 機櫃動態（推進來時） | 1360 vs 1400 | ✅ 餘裕 40 kg（假設動態上限含自重，頁面沒寫） | | 機櫃靜態（站定後） | 1360 vs 1600 | ✅ | | 樓板均佈 | 1360 ÷ (0.6 × (1.068 + 0.6 + 0.6)) = 999 kgf/m² = 9.80 kPa vs 7.2 | 🔴 FLOOR_OVERLOAD（對 12 kPa 建議值則通過） | | 樓板點載重 | 1360 ÷ 0.6408 m² = 20.8 kPa vs 未知 | ⚪ UNDETERMINED，不是綠燈 | 建模重點： 1. total_weight_kg 不能存，要從 RackType.self_weight_kg + Σ Mount.weight_kg 推，否則下架一台伺服器後四個判定同時變錯（dc-29 意涵 #4）。 2. max_dynamic_kg 要帶 includes_self: bool | unknown。含自重時設備只能掛 1250 kg、餘裕 40 kg；不含自重時設備可掛 1400 kg、餘裕 190 kg。兩個答案差將近 5 倍，unknown 時要取保守的那一個（含自重），並把 Finding 標成「依假設判定」。 3. FLOOR_OVERLOAD 必須帶出 source（7.2 是 TIA 最低值，還是結構計算書的值？），不帶出處的紅燈沒人知道該去找誰（dc-28 加分題）。 4. 點載重上限未知時是 W38 立的第五態 UNDETERMINED：「再加一份資料就能解」，處置是去要結構計算書，不是放行。

Q5.（建模判斷）本週有兩個 Rack：dc-28 的 Rack(id, x, y, rotation_deg, w, d, weight_kg) 與 dc-29 的 Rack(id, type, starting_unit, desc_units, mounts)。合併成一個時，外形尺寸、座標、重量、U 位編號各該住在哪個型別？哪幾個不該存？

答案

資訊	住哪	理由
外形寬深（600 × 1068）	`RackType`，單位 mm	同型號都一樣；樓板計算要它。dc-29 練習的 `RackType` 漏了外形，只有 `unit_mm`
座標與旋轉角	`Placement(room_id, x_m, y_m, rotation_deg)`	搬遷時只換這一格；`aisle_of()` 從它推
自重、靜態／動態上限	`RackType`，上限是 `Sourced` ＋ `includes_self`	型號屬性，但出處要跟著走
總重	不存，`total_weight_kg()` 推導	餵 `RACK_OVERWEIGHT` 與 `FLOOR_OVERLOAD` 兩個消費者
`u_height`、`starting_unit`、`desc_units`	`Rack` 實例	NetBox v5.0 的做法：同型號櫃子實際裝法可以不同
U 位顯示編號（`U13`）	不存，`label()` 推導	降序櫃不用改資料
通道歸屬	不存，`aisle_of()` 推導	dc-28 意涵 #2
合併後是 `Rack(id, type: RackType, placement: Placement, u_height?, starting_unit, desc_units, mounts)`。
判斷的依據：三棵樹（電、熱、空間）都落在機櫃上，所以這個型別只要有第二個定義，下游一定會有一半的函數拿到缺欄位的那一個。`dc-28` 的 `uniform_load_kpa()` 需要 `w, d`，`dc-29` 的 `Rack` 沒有；`dc-29` 的 `total_weight_kg()` 需要 `mounts`，`dc-28` 的沒有。兩個加分題都要求把它們接起來，而現在的型別接不起來。

間隔複習¶

刻意的間隔重複。本節是整份週報對長期記憶貢獻最大的一段。

抽 W37 的 dc-19b NPSH 與泵的擺放高度（2026-09-09，18 天前）¶

為什麼抽它：dc-28 演算二說「高程基準錯位 0.45 m，剛好等於一個 NPSH 餘裕」，引的就是這張卡的數字。空間層級本週把它的 Z_static 變成了 (value_m, datum_ref)，回頭看它原本在算什麼。

Q. 同一顆泵（NPSHr = 6.0 r²），A 放地面層（Z_static +18 m、h_f 3 m），B 放屋頂跟塔並排（Z_static −1.2 m、h_f 1.5 m、水溫 35.8 °C）。各自的最大可運轉流量是多少？B 在 110% 流量時會怎樣？如果有人把兩張圖的 ±0 搞錯 0.45 m，會發生什麼？

答案

B（屋頂）：NPSHa = 8.58 − 1.5r²，margin 判準 1.0 m → 7.58 ≥ 7.5r² → r ≤ 1.005。 A（地面）：NPSHa = 27.89 − 3r²，高流量下判準換成 0.1 × NPSHr → 27.89 − 3r² ≥ 6.6r² → r ≤ 1.704。 同一顆泵，只差擺放高度，最大流量從 100.5% 變成 170.4%。 B 在 r = 1.1：NPSHa 6.77 < NPSHr 7.26，margin 約 −0.5 m，直接汽蝕。而 dc-19 的系統曲線交點根本不在這裡算。 連到本週：0.45 m 的 datum 錯位，量級正好跟這個 −0.5 m 相同。兩份圖各自都抄對了數字，相減就可以把紅燈翻成綠燈、或把綠燈翻成紅燈。→ 標高永遠是 (value_m, datum_ref)，不能是裸 float（dc-28 意涵）。 順帶回憶：同一張卡的 HI 9.8 淹沒深度公式只在流速 > 0.61 m/s 時成立。VFD 降到 41% 以下，這條約束是 NOT_APPLICABLE，不是 SATISFIED。Check enum 的第三態就是這張卡立的。

抽 W35 的 dc-12 RPP 遠端配電盤（2026-08-28，30 天前）¶

為什麼抽它：dc-26b 意涵 #1 把 derating_basis 的來源數到第四種（外殼列名 → 環境溫度 → 內部導體 → 測試室當天有沒有裝濾網），而第一種就是這張卡立的。30 天前立的欄位，本週長到了冷卻設備身上。

Q. 380Y/220 V、400 A 主開關的 RPP，掛了 28 顆 30 A/3P 分路。(a) 這台盤的容量是 210.6 kVA 還是 263.3 kVA？(b) 分路加總 840 A 是主開關的 2.1 倍，算不算配置錯誤？(c) BCMS 30 天峰值 180 A，還能加幾個 6 kW 機櫃？

答案

(a) 看 (breaker, enclosure) 這個組合有沒有經 UL 489 列名為 100% rated，不是看斷路器本身。80% rated：√3 × 380 × 400 × 0.80 = 210.6 kVA；100% rated：263.3 kVA。差 52.7 kVA，約 8.7 個 6 kW 機櫃。把 0.80 寫成全域常數，每台 100% rated 的盤都會憑空少掉 9 櫃。 (b) 不算。 那是 IEM 的出廠標配，負載不會同時滿載（diversity）。寫 sum(branches) <= main 的驗證會把標配判成違規。 (c) 約 19 櫃。 NEC 220.87：既有負載 = 1.25 × 30 天峰值 = 225 A；剩 175 A → √3 × 380 × 175 = 115.2 kVA。⚠ 這是美規，台灣走屋內線路裝置規則，數字要另查（卡片原註）。 連到本週：dc-12 的教訓是「0.80 不是物理常數，是某個組合的屬性」。dc-26b 的教訓是「1000 kW 不是物理常數，是某個測試組態的屬性」。兩者結構一樣：headroom() 要回「數字＋用哪個 method」，Rating 要回「數字＋測試組態」，而 comparable_to() 其實就是在問「兩個 derating_basis 相不相同」。

本週的 model code 連貫性檢視¶

先結算 W38 的三項¶

項目	W38 預估	狀態
1. `dc-26` 下掛註解：接 `SplitDimension`	5 分鐘	✅ 做了，而且接上了。 `dc-26` 的排程在 backlog 寫下「W38 交辦事項已執行」，判斷 CDU 沒有顯熱／潛熱分量、硬接是為做而做，改由 `dc-27` 接。`dc-27` 意涵 #1 開頭就是「`SplitDimension` 終於接上了」
2. 同處掛第二條：`Check` enum 固定五態	5 分鐘	🟡 註解沒掛，但被引用了。 backlog 裡找不到這條註解；`dc-28` 意涵 #3 卻寫了「點載重未知時是 `UNDETERMINED` 不是綠燈（W38 立的第五態）」。成員被用了，定義還是沒有：dc-19b 的三態（`"not_applicable"`）與 dc-24 的四態（`"n/a"`）仍然並存，五態版本只存在於 W38 週報
3. `dc-16` 的 50.5% → 58.4%	5 分鐘，第三次排	🔴 沒做，第四次。 `dual-corded-equipment.md` 裡 `50.5` 仍出現 8 次

項目 3 依 W38 自己的承諾除名。 W38 原文：「若下週再不做，比照 energy_kwh() 降級成已知缺陷除名。」照辦。dc-16 的 50.5% 登記為已知缺陷，從優先序移除，與 dc-09 的 energy_kwh() 同列。兩者都是卡片內容錯誤，不是模型設計問題，讀者看到 dc-16 時請以 W36 週報的更正（58.4%）為準。

項目 1 值得多記一筆：這是本軌跡第一次有一條週報建議，經過「週報 → backlog 註解 → 下一張卡判斷『這裡接不上』→ 再下一張卡接上」四步完成。中間那步是關鍵：dc-26 沒有硬接，而是寫下為什麼不接、留給誰接。這種「延後但有交代」的判斷，比 W37 以前「每張卡各貼一份自己的 code」健康得多。

繼承鏈：本週是一條直線 ✅¶

dc-25b airflow_metrics.py
  → dc-26  cdu.py        「接 dc-25b 的 airflow_metrics.py」
  → dc-26b rating.py     「接 dc-26 的 cdu.py」
  → dc-27  rdhx.py       「接 dc-26b 的 rating.py」
  → dc-28  space.py      「接 dc-27 的 rdhx.py」
  → dc-29  rack.py       「接 dc-28 的 space.py」

六個檔案、一條鏈、沒有分叉。W38 那種斷頭節點本週沒有發生。但一條直線也代表每個檔案只被下一個檔案讀過一次，下面幾項漂移都是這樣產生的：只看前一天，看不到前三天。

本週新增六處¶

🔴 1. `Rack` 兩天兩個版本，欄位互不相容¶

# dc-28 space.py（09-24）
@dataclass(frozen=True)
class Rack:
    id: str; x: float; y: float; rotation_deg: int
    w: float = 0.6; d: float = 1.068; weight_kg: float = 1360

# dc-29 rack.py（09-25）
@dataclass
class Rack:
    id: str; type: RackType; starting_unit: int = 1; desc_units: bool = False
    mounts: list[Mount] = field(default_factory=list)

同名、不同檔、零個共同欄位（除了 id），一個 frozen、一個可變。dc-29 的加分題要求「把 dc-28 Rack.weight_kg 換成 rack.total_weight_kg()」，但 dc-28 的 uniform_load_kpa() 還需要 w 與 d，而 dc-29 的 Rack 和練習裡的 RackType 都沒有外形尺寸（意涵 #1 列了 width_in 和 mounting_depth_mm，那是安裝寬深，不是外殼佔地）。

照加分題字面做，會得到一個算不出樓板載重的機櫃。

→ 收斂（Q5 的答案）：RackType 補 outer_w_mm、outer_d_mm；座標搬進 Placement；只留一個 Rack。這是機櫃節點，三棵樹共用，只能有一個定義。

🔴 2. 同一個物件，兩天三種長度單位¶

欄位	卡	單位
`Rack.w` / `Rack.d`	dc-28	m（0.6、1.068）
`RackType.unit_mm`	dc-29 練習	mm（44.45）
`RackType.width_in`	dc-29 意涵 #1	inch（19 / 21）
`mounting_depth_mm`	dc-29 意涵 #1	mm

dc-29 自己的演算一在講「U 和 OU 格線對不齊，欄位不帶單位制就錯 7%」，同一張卡的欄位卻用了兩種單位制，加上前一天的公尺就是三種。另外 width_in 這個名字本身有歧義：_in 是 inch 還是 inner？

→ 收斂：機櫃相關長度一律 mm、欄位名一律帶 _mm 後綴；房間座標一律 m、帶 _m。19″／21″ 是標準名稱，存成 rail_standard: Literal["EIA-310", "ORv3"]，不要存成數字。

🟡 3. `Finding` 三種形狀，而且 `kind` 撞名¶

# W38 #6 提議
Finding.kind: Literal["violation", "prediction", "fact", "degradation"]

# dc-27 加分題
Finding(kind="INFEASIBLE_WINDOW", fix="room_rh <= 0.519")   # kind 被拿來當名稱

# dc-28 / dc-29 練習
def check(...) -> list[str]:  ...                            # Finding 退化成字串

kind 在 W38 是分類軸，在 dc-27 是 Finding 的名稱。 而 dc-28、dc-29 直接回字串，連型別都沒有。本週新增的 Finding：INFEASIBLE_WINDOW、RACK_FACING_HOT_AISLE、FLOOR_OVERLOAD、OPEN_U_IN_FRONT_PLANE、RACK_OVERWEIGHT，另外 RIDE_THROUGH_INSUFFICIENT 被 dc-26 要求補 failure_mode。

值得注意的是，卡片自己已經在要求兩個新欄位： - dc-27：「修正動作的對象是房間的 CRAH，不是門」→ fix_target - dc-28：「不帶出處的 FLOOR_OVERLOAD 沒有人知道該去找誰」→ source

→ 收斂：Finding(code: str, kind: Literal[...], subject_id, evidence: dict, source: str | None, fix_target: str | None)。code 是名稱（FLOOR_OVERLOAD），kind 維持 W38 的分類語意。list[str] 的版本本週就要換掉，因為 dc-29 的加分題要讓 OPEN_U_IN_FRONT_PLANE 的嚴重度隨通道升級，字串裝不下嚴重度。

🟡 4. `Sourced[T]` 在三張卡裡被當成已存在的型別使用，但從來沒被定義¶

dc-27：capture_ratio: Sourced[Range]
dc-28：Room.floor_uniform_kpa: Sourced[float]、point_load_kg: Sourced[float] | unknown
dc-29：max_static_kg / max_dynamic_kg 是 Sourced[float]，並帶 includes_self

「值＋出處」家族（dc-26b 數到第七次）本週第一次有了泛型名字，而且連續三天被引用。但沒有任何一張卡寫出它的欄位。

而卡片的寫作規則早就在要求一個欄位了：dc-26b、dc-28 反覆寫「搜尋摘要有、原文頁找不到，依 dc-26b 立的規則不寫入計算」。這條規則目前只活在卡片的 ⚠ 註記裡，它其實是一個資料欄位。

→ 收斂：

@dataclass(frozen=True)
class Sourced(Generic[T]):
    value: T
    source: str                       # "TIA-942 min" / "結構計算書 p.37" / "Vertiv DCD spec"
    evidence: Literal["first_hand", "relayed", "snippet"]
    version: str | None = None
    note: str | None = None

evidence == "snippet" 的值不可以參與計算，由型別擋掉，不靠寫卡的人記得。這條規則本軌跡已經用 prose 執行了一個月，該讓程式執行了。

🟡 5. 空氣的 ρcp 又被定義了兩次（W38 #5 的病，兩天後復發）¶

dc-27 rdhx.py：air_c_kw_k() 用 ρ = 1.2、cp = 1.005 → 1.206 kJ/(m³·K)
dc-28 space.py：RHO_CP = 1.21

差 0.33%，數值上無害。但 dc-28 正是修掉「同一個量算兩次」的那張卡，而它在修的同時又定義了一個跟前一天不一樣的常數。

→ 收斂：constants.py 放 AIR_RHO、AIR_CP、G（dc-28 已有 G = 9.80665），其他檔案一律 import。這是 5 分鐘的事，而且越晚做檔案越多。

🟡 6. 「迴路」在三張卡裡用三種方式指稱¶

卡	怎麼指一條迴路
dc-26	`fluid` 是模式欄位，掛在 CDU 上
dc-26b	`WaterQualitySpec(loop, ...)`，`loop` 是 `"TCS"` / `"FWS"` 字串
dc-27	`CoolingLoop.temp_class` ＋ `loop_id`

流體、水質限值、溫度等級，這三個本來就是同一條迴路的屬性，現在分散在三個地方、用三種鍵。dc-27 Q3 的結論（30 °C 的 TCS 與 15 °C 的門迴路不可共用 loop_id）要成立，前提是有一個地方同時知道兩條迴路的溫度等級。

→ 收斂：CoolingLoop(id, side: Literal["fws", "tcs", "door"], fluid, temp_class)，WaterQualitySpec 參照 side，CDU 用 primary_loop_id / secondary_loop_id 參照兩條迴路。

順帶：本週一個正面對照組¶

dc-26 的 ride_through_s(failure_mode, ...) 規定「failure_mode 缺席要 raise，不可有預設值」。這是本軌跡第一次在簽章層擋錯，而不是在註解裡提醒。驗收表第 5 列還要求測「少給參數會 raise」。

W38 記了 Limit.basis 是「唯一被三張卡沿用而沒有漂移的設計」。本週可以補一句：「沒有預設值」是比「寫在註解裡」更可靠的約束，Sourced.evidence 與 Finding.source 都應該照這樣做成必填。

本週優先序（兩項，全部走「掛進下一張卡」這條本週剛驗證有效的路徑）

dc-30 開工前把兩個 Rack 合一（RackType 補外形 mm、座標進 Placement、長度一律帶單位後綴）。dc-30 高架地板本來就要算機櫃壓在地板磚上的載重，需要的正是 outer_w_mm × outer_d_mm 與 total_weight_kg()，接點是自然的，不是硬接。

dc-30 同時定義 Sourced[T]（含 evidence）與 Check 五態的正式版。地板磚有自己的均佈與點載重等級（出處是地板廠商），點載重未知時要回 UNDETERMINED，兩個型別在 dc-30 都會被真的用到。

Finding 統一（#3）、常數模組（#5）、CoolingLoop（#6）本週不排。理由同 W38：一張卡掛兩條是已驗證的上限。#3 建議留給 dc-32 VESDA（第一張會產出大量告警的消防卡），#6 等冷卻鏈下次被碰到時再處理。

本週該問 facility 的問題¶

五張卡共列出 15 題，去重後取 3 題。這 3 題是給你下週真的拿去問人的。

Q1：問機電設計單位（冷卻）＋ IT 採購（必須同時在場）¶

🔴 最不可逆的一題。這個溫度決定台北要不要蓋冰機房，而且採購那天就定了。

「液冷區的 TCS 設計供水溫度是幾度？依據的是哪一份晶片或冷板規格書、哪一頁？如果有 RDHx，門的進水跟 TCS 是同一條迴路還是另拉一條？設計溫度多少？ CDU 的 TCS 泵接在哪一路電、有沒有在 UPS 上？ 設備內建的 ultracapacitor 標稱撐幾秒？」

為什麼要一起問：溫度的出處在 IT 採購手上，迴路與電源的設計在機電手上。冷板 10 秒 vs 發電機 10 秒（dc-26），以及 30 °C 的水餵門只收一半熱（dc-27），這兩個結論都要兩邊的答案湊在一起才看得出來。

Q2：問機電設計單位轉結構技師（樓板）＋維運（搬運）¶

🔴 AI 整櫃進場前一定要有答案，否則驗收時沒有證據。

「機房區樓板的設計均佈活載重是多少 kPa、點載重上限多少？請給結構計算書的頁碼，不要口頭數字。整櫃從卸貨區推到機房，沿路（卸貨平台、貨梯、走廊、高架地板）每一段的載重等級是多少？全廠高程的 ±0 是 GL、1F FFL 還是海拔？機電圖與建築圖是不是同一個基準？」

為什麼要這樣問：dc-28 只算了目的地房間。1360 kg 的整櫃在走廊上是輪子的點載重，而這條路徑上的每個空間都可能是不同等級（本週〈串起來〉連鎖 C）。高程基準那一句是 dc-28 演算二：0.45 m 的錯位，量級就是一個 NPSH 餘裕。

Q3：問控制系統承包商（commissioning 數據）＋維運（工單流程）¶

🟡 有時效性：這些數字只能在 commissioning 時量，錯過就沒有 baseline。

「commissioning 時，CDU 濾網的 clean ΔP 會在哪個流量、哪一種泵模式下量？誰存檔、存到哪個系統？ CDU 的水質三感測（導電度／濁度／pH）有沒有買？沒有的話，水質採樣的週期和紀錄誰負責？機櫃 MAC 工單裡有沒有『裝回盲板』與『更新資產系統的 U 位狀態』這兩步？」

為什麼要這樣問：dc-26b 演算二說同一顆濾網在雙泵同時運轉與 run/standby 下的 clean ΔP 差 3.5 倍（25 vs 87 kPa）。baseline 不記泵模式，告警門檻就沒辦法設。這是本軌跡第五個「沒有 commissioning 產出就沒有告警規則」的欄位。盲板那一句是本週連鎖 A：OPEN_U_IN_FRONT_PLANE 只有在工單更新 U 位狀態時才會觸發。

節奏¶

（一）全勤，而且五張都合格¶

卡	日期	`wc -m`	判定
`dc-26`	09-21	9 960	✅（初稿 12 363，拆出 dc-26b）
`dc-26b`	09-22	9 996	✅
`dc-27`	09-23	8 374	✅ 舒適區
`dc-28`	09-24	9 686	✅
`dc-29`	09-25	9 985	✅

五個工作日五張卡，是第二輪開工以來第一次全勤。dc-26 初稿超標直接拆卡，沿用 W38 記下的 dc-25 做法（拆卡而不是壓縮），第二次奏效。

⚠ 但有三張距上限不到 40 字元（9 960、9 996、9 985）。W38 已經觀察到 dc-25 的 9 993。一張剛好卡在上限下方可能是巧合，連續幾張都這樣，比較像是寫完之後壓到 10 000 以下。CLAUDE.md 說「不要再為省字數犧牲深度」，而舒適區是 6 000–9 000。建議 dc-daily-card 在收尾時，若 wc -m > 9 800，在 backlog 註記「是否有被壓掉的內容」，讓使用者判斷是不是該拆卡。這不是錯誤，是一個值得看的訊號。

（二）鎖檔殘留第三次，這次擋了三天¶

dc-29 的檔案時間是 09-25 08:28，commit 卻在 09-28 10:10 才出現。
本週報開工時 .git/index.lock 仍在，rm 回 Operation not permitted。取得刪檔授權、清掉鎖之後，dc-29 的 commit 才落地。本週報自己也因此延到 09-28（一）才完成。

這是 W38 記錄的「09-18 殘留兩天」、index 記錄的「09-22 開工時兩支都在」之後的第三次，而且是目前最久的一次。W38 建議把收工的 rm -f .git/*.lock 改成收工檢查（刪完 ls .git/*.lock 確認為空，不空就在 index 標紅），看起來還沒有落實。

→ 根本問題在授權：CLAUDE.md 寫了「刪檔權限每個 session 都要重新取得」。排程任務收工時如果沒有這個權限，rm 就會靜默失敗。建議 dc-daily-card 的收工步驟改成：先呼叫授權，再 rm，再 ls 驗證，三步都寫進 SKILL.md，不要只寫一行 rm。

（三）`mkdocs.yml` 缺 `pymdownx.arithmatex`，第五週未修¶

5 張舊卡、6 處 $$，在 CF Pages 上會印出字面字串（其中 dc-19b 就是本週間隔複習抽到的那張）。本週五張新卡都沒有用 $$，所以問題沒有擴大。修法（pymdownx.arithmatex: {generic: true} 加 extra_javascript 掛 MathJax）需要本機 build 驗證後再動。

下週¶

佇列下一張：dc-30 高架地板與線槽走線架，接 dc-29 的 total_weight_kg() 與 dc-28 的 underfloor_m3（地板下既是風道也是走線空間）。本週優先序的兩項都掛在它身上（Rack 合一、Sourced 與 Check 定案），dc-30 開工時請先看〈連貫性檢視〉最後的優先序。
之後依序 dc-31 結構化布線 → dc-32 VESDA → dc-33 氣體滅火 → dc-34 門禁。dc-33 會用到 dc-28 的防火區覆蓋分區，那是 Zone 同類互斥約束第一次被真的消費。
W40 的間隔複習：抽 W38 的卡（dc-23 ~ dc-25b）＋ W36 的卡（dc-14 ~ dc-18）。dc-15 已在 W38 抽過，請從 dc-14 / dc-16 / dc-17 / dc-18 選。建議 dc-16：它的 50.5% 本週剛被登記為已知缺陷，複習時順便確認讀者記得的是 58.4%。
⚠️ 現場驗收單第五次提醒。 W35 起每週都提。本週加三項，全部是 commissioning 才量得到的：(a) CDU 濾網 clean ΔP ＋當下流量＋泵模式（dc-26b）；(b) CDU 內建 ultracapacitor 的實測撐持秒數（dc-26）；(c) 每櫃實測重量（dc-28：稽核接受低於 12 kPa 的前提）。
⚠ 單線圖對照盤點仍未做，承 dc-17 ~ dc-29 的註記。排程任務手上沒有公司的單線圖，無法自動執行。本週再加一項需求：樓板結構計算書的載重頁（Q2）。