2026-W38 週報：綠燈的四種死法¶

第八份週報。本週 4 張卡、5 個工作日——9/16（三）空手，這是第二輪開工以來第一次在非磁碟、非沙箱的理由下缺一天（詳見〈節奏〉）。

冷卻鏈本週走完了末端：CRAC 補上直膨式那一支，濕度把「露點是誰維持的」講清楚，封閉處理幾何，然後第一張主題卡處理「做完之後怎麼知道有沒有效」。

但本週真正該記的不是走完，是四張卡各交了一份「儀表板全綠、機房在出事」的案例，而且四種的死法互不相同：

卡	報表上看到什麼	實際發生什麼
`dc-23` CRAC	穩態容量用率正常	ride-through 24 秒，而壓縮機強制休息 300 秒
`dc-24` 濕度	每一台機的自我診斷都正常	甲機加濕、乙機除濕，每天都在發生
`dc-25` 封閉	`assumed_return_air_c` 照舊	消防演練後頂板整片落下，BMS 沒有任何點位說這件事
`dc-25b` 度量	RTI 100%、RCI 97%「良好」	再循環 40%；有機櫃在允許範圍外

四種都不是「感測器壞了」。 第一種是穩態報表結構上表達不了時間；第二種只在群組層級可見；第三種是物理世界真的變了而模型不知道；第四種是指標本身的定義就允許它。

而這四種正好把 Dimension 的 invalid 種類從兩種補到四種——W37 才剛記下「valid: bool 裝不下兩種」，本週變成四種。這是本週對資料模型最硬的一項結論，寫在〈連貫性檢視〉#4。

本週卡片¶

卡	標題	這張卡最關鍵的一個事實
`dc-23`	CRAC 精密空調（直膨式）	壓縮機在箱子裡，total 被它釘住。回風 23.9 → 29.4 °C，total 只 +8.4%、sensible +23.0%（SHR 0.844 → 0.957）——對照 dc-22 冰水式同區間顯熱 +42%。回風變暖買不到冷量，只是把潛熱容量重新分配成顯熱
`dc-24`	加濕與除濕	房間露點是補氣決定的，不是房間決定的——1000 m² 機房全年除濕潛熱只有 6.8 kW（IT 負載的 0.43%）。而台北 4–11 月八個月室外露點高於 15 °C、沒有任何一個月接近下限：加濕器一年 0 小時，照美規文獻配的濕度套裝一半是死重
`dc-25`	冷熱通道封閉	那個被引用到爛的「熱通道封閉省 43%」不是熱力學性質，是 OSHA 的價格。不限制未封閉區時兩種封閉 PUE 都是 1.65、economizer 都是 6 218 小時，完全相同；43% 全部來自「房間要維持 24 °C 給人待」這一條沿著一個減號傳到冰水設定值
`dc-25b`	氣流管理的度量（λ / RTI / RCI）	λ、RTI、旁通率是同一個數字的三個名字（能量守恆給 `RTI = 1/λ`，沒有例外）→ 三者只能存一個。而 λ=1、再循環 40% 的機房 RTI 拿滿分：λ 管「多少」，封閉管「去哪」，RTI 只看得到前者

串起來¶

一、把四張卡放回同一個房間裡¶

前七週的圖都畫得出「誰接誰」。本週畫不出來——四張卡裡有三張的主角不在任何一棵樹上。

   室外乾球 ──→ [屋頂氣冷冷凝器] ←── dc-23 env_offset（再循環 40% → +3.6 K）
                      ↑ 冷媒管
                      │
   室外露點 ──→ [補氣風門] ──→ dc-24（房間露點的唯一驅動源）
                      │
冰機 → 冰水 → CRAH ───┤
                      ├──→ ■ 房 間 空 氣 ■
CRAC（自帶壓縮機）────┘          │
                                 ├─ dc-25  封閉：決定空氣「去哪」← 幾何，不在樹上
                                 └─ dc-25b 度量：λ / RTI / RCI ← 事後怎麼知道
                                          ↓
                                      機櫃進風

dc-23 是本週唯一一台真的設備，但它最重要的那一段（env_offset）講的是屋頂的幾何。
dc-24 自己第一句就寫「本卡是第一張『設備可能根本不存在』的卡」——除濕沒有對應設備，它是「盤管表面溫度 < 室內露點」這個條件的副產品。
dc-25 明寫「不在任何一棵樹上」，是房間的邊界條件。
dc-25b 是主題卡，連設備欄位都沒有。

這是第一週「樹」不是主要的組織方式。 繼 dc-15 的「標註」、dc-17 的「站點外生變數」、dc-22 的「房間層級」之後，dc-25 補上第四類非樹物件：幾何。四類湊齊之後回頭看，它們其實是同一件事的四個面——模型裡最會出事的量，都不住在拓撲上。

二、本週最值得算的一件事：加濕器與屋頂，各自吃掉 N+1 的那個「+1」¶

dc-23 演算一把露點釘在 52 °F（11.1 °C），回風 29.4 °C 那列是 total 105.6、sensible 101.1 → latent 只有 4.5 kW（佔 4.3%）。而 dc-24 明白指出：把露點推到 58 °F，潛熱吃掉一塊，顯熱就掉——而型錄那格 101.1 kW 不會變。

把 dc-24 的數字代進 dc-23 的守恆式（total 被壓縮機釘住，sensible + latent = total）：

蒸汽式加濕器 20 kg/h 的水氣，換算潛熱負荷 20 × 2450 / 3600 = 13.6 kW。這 13.6 kW 必須由同一台 CRAC 再冷凝掉：

latent:    4.5 → 4.5 + 13.6 = 18.1 kW
sensible:  105.6 − 18.1 = 87.5 kW      （原 101.1，−13.4%）

而 dc-23 演算二「屋頂實測 40 °C ＋再循環 40%」那一列是 87.2 kW。

兩個完全不相干的原因——一台沒人管的加濕器、一片沒人量的屋頂——各自把顯熱容量從 101.1 打到 87 附近，各自吃掉 N+1 裡那個「+1」。兩個一起發生時約 73.6 kW，比型錄 105.6 少 30%。

⚠ 一階估算：假設 total 在露點變化下恆定。實際 total 會隨露點微升（廠商曲線未取得），所以 87.5 是保守偏低的一側。演算二的 −1.6 %/K 敏感度本身也是由「110 °F 較 95 °F 低 20–30%」反推的粗略區間。兩者都不可用於選型，但數量級與「兩個原因規模相當」這個結論是穩的。

而在台北，加濕器那一路百分之百是純損失——dc-24 已證明台北一年 0 小時需要加濕。它燒的 15 kW 電力樹負載（蒸汽式 0.75 kW/(kg/h) × 20）製造出來的水氣，又要在熱樹上被扣一次顯熱容量。同一台設備在兩棵樹上都是負分，而它的存在理由是一份寫給北美的文獻。

三、ride-through 的三連降，每一次都是「做得更好」造成的¶

出處	配置	ride-through	靠的是什麼
dc-20	儲冷槽	15 分鐘	水側熱容
dc-18	冰水環路	5.2 分鐘	水側熱容
`dc-23`	CRAC（無水側）	24 秒	房間空氣 4 840 kJ/K
`dc-25`	CRAC ＋熱通道封閉	26 秒	房間空氣＋地板下 5 288 kJ/K
`dc-25`	CRAC ＋冷通道封閉	5.0 秒	只剩通道 230 ＋地板下 600 m³

從 900 秒到 5 秒，三週，兩個數量級。而每一步都是一個看起來正確的決定：

改用 CRAC → 省掉整個冰機房、故障域變小（每台自己一套冷媒迴路）→ 水側慣量歸零
做冷通道封閉 → 省風扇電、機櫃密度上得去 → 冷空氣庫存再掉 5.3 倍

而參考時間完全沒動：發電機起動約 10 秒、CRAC anti-short-cycle 強制休息 300 秒。

冷通道封閉 + CRAC 的組合，連發電機起動的 10 秒都撐不過。 這是 dc-18（冰機加冗餘反而讓 ride-through 需求上升）之後第三、第四個「加強某一項反而讓另一項變糟」的案例，而這次兩個疊在一起。

結論不是「加儲冷槽」——dc-20 的 15 分鐘與 dc-18 的 5.2 分鐘全是水側慣量，前提是泵還在轉、風扇還在吹。風扇一停，冷水再冰也送不進通道。結論是「CRAH／CRAC 風扇上 UPS」，而那在多數設計裡被歸類成節能選項。

四、掉一個會連鎖到哪：本週兩條主連鎖，都從「一個沒人負責的東西」開始¶

連鎖 A：一支沒校正的 RH 感測器，穿過三張卡，改寫了容量表

RH 感測器漂移 ±3%（dc-24：這個幅度就足夠）
   → 甲機判定「太乾」，加濕器開（而台北一年 0 小時需要加濕）
   → 房間露點上升
   → dc-23 的 SHR 下降，顯熱容量 101.1 → 87.5 kW（上面演算）
   → 機櫃進風溫度上升
   → dc-25b 的 RCI 下降 ⋯⋯ 但如果只有一兩櫃超標，RCI 仍在 97%「良好」
   → 而 dc-23 的容量表印的還是 101.1

五個環節，零個告警。 唯一能直接看見「正在除濕」的訊號是凝水盤有沒有水（dc-24 遙測表明列），而多數現場沒接這個點位。

連鎖 B：消防演練，四小時內容量模型是錯的

煙偵動作（或 fusible link 熔斷）
   → drop-away 頂板整片落下
   → 封閉 integrity 失效，旁通率從 3–10% 回到 25–50%（WP135 典型值）
   → 回風溫度下降
   → dc-22 的 assumed_return_air_c 當場失效，CRAH 顯熱容量下降（該卡演算：回風每降一段，顯熱掉得很快）
   → 需要更高的 λ 才維持同樣的機櫃進風
   → 風扇轉速拉高（dc-25b 演算四：20 Pa vs 2 Pa 差 2.69 倍風扇功率）
   → 而 BMS 沒有任何點位叫 ceiling_panel_state

dc-25 對這件事的定性是本週最尖的一句：「這是本軌跡第一個『另一個系統有權即時改寫容量模型前提』的耦合，而它通常沒有回授點位。」

前三種 invalid（錶失聯、公式適用域、群體不一致）都是感測或模型的問題，這一種是物理世界真的變了。

五、模型悄悄長出了「通道」這一層，而型別名沒變¶

W37 記下「模型第一次真的需要第二個層級：房間」，並給了邊界規則（凡是「從三個以上設備讀數推導、且不對應任何銘牌」的量住 RoomReport）。

本週 dc-25 引入 Aisle，dc-25b 的 AirBalance 第一個欄位變成 aisle_id：

# dc-22（房間層級）
AirBalance(bypass, recirculation, balance)

# dc-25b（通道層級，同一個型別名）
AirBalance(aisle_id, lam, bp)

層級從房間降到通道、欄位全換，而型別名沒變。 現在模型有四層（設備 / 通道 / 房間 / 站點），而只有前兩層有型別、都叫同一個名字。

這件事本身是對的——旁通與再循環確實是一條通道的性質，不是整個房間的——但它必須被明講，否則「房間的 λ」與「通道的 λ」會在同一張表裡比大小。而通道歸屬要靠座標算，這是 dc-19b 與 dc-25 各提前叫過一次的空間層級（dc-28）第三次被需要。

六、第一次收斂：後面的卡刪掉前面的欄位¶

前 24 張卡對模型全是擴充。dc-25b 是第一個反過來的：

RTI ≡ 1/λ ≡ 1 − BP（無再循環時）  ← 能量守恆，不是經驗關係
→ 三者只能存一個。存可直接量的 lam，rti / bypass 降為 @property

而且它有交叉驗證：dc-22 從三個溫度獨立算出的旁通率 0.43，與從風量比 1.75 推的 42.9% 吻合 ✓。

這是本週最值得高興的一件事，原因不在這條恆等式，在它發生的位置。 W37 觀察到「可貼的 code 只被下一張卡採納，而週報不在那條鏈上」——dc-25b 的收斂建議是寫在卡片裡的，所以它在鏈上，所以它有機會真的發生。W36、W37 兩份週報的十二項收斂建議沒有一項被採納，而卡片裡的建議一天就傳到下一張。

機制的答案不是「建一份更好的文件」，是「把建議放進下一張卡的練習題」。 這改寫了 W37 的結論，詳見〈連貫性檢視〉最後的優先序。

自我測驗¶

Q1.（事實回憶）台北的機房，加濕器一年需要跑幾小時？為什麼？

答案

0 小時。 依中央氣象署台北站月均溫濕用 Magnus 式推算（月均值推導、非 TMY 小時級，不可用於選型），ASHRAE 2015 的死區是 16–59 °F DP（−9 ~ 15 °C）：1 月露點 12.5 °C、12 月 13.4 °C 在死區內；4 月 17.8、7 月 23.6、11 月 16.8 °C 都超上限。4–11 月共八個月高於 15 °C，而沒有任何一個月接近下限。 LBNL 全篇的擔心是「過度加濕浪費水電」，在台北問題整個翻面：除濕是全年八個月都在跑的那一邊，加濕器是死重——還附帶一條 DI/RO 水路要維護（而電極式蒸汽筒反而需要有導電度的自來水，dc-24 來源分歧二：兩種並存 = 兩條水路，規劃階段沒想到就要重拉管）。

Q2.（事實回憶）「熱通道封閉比冷通道封閉省 43% 冷卻能耗」——這 43% 從哪裡來？

答案

從 OSHA，不是從熱力學。 APC WP135 三個情境把話講完了：不限制未封閉區時兩者 economizer 都是 6 218 小時、PUE 都是 1.65，完全相同。43% 全部來自情境 3「房間要維持 24 °C 給人待」。機制是一個減號：冷通道封閉時房間 = 熱通道（房間 = IT 進風 + 伺服器溫升），所以房間 24 °C → IT 進風 24 − ΔT；熱通道封閉時房間 = 冷通道，人的約束與 IT 的約束是同一個溫度，沒有這個減法。 而懲罰隨溫升放大：WP135 的 13.9 K 下 CACS 是 10.1 °C（economizer 0 小時、PUE 1.98，比完全不封閉還差）；dc-22／dc-23 用的現代 20 K 下是 4 °C，冰水約 0 °C——不是比較差，是無解。佐證兩邊都對：Intel／T-Systems 德國實驗機房的第三方實測論文標題直接是《Reveal No Significant Differences》。差別在有沒有把人因約束算進去，不在設備。

Q3.（應用）一份驗收報告寫著「RTI = 100%，RCI_HI = 97%，氣流管理符合良好設計」。你要退件嗎？退件理由寫什麼？

答案

要退，而且兩個數字各有各的問題。 RTI = 100%：RTI = 1/λ，只說送風量等於 IT 抽風量，完全沒說空氣去了哪裡。對通道做質量平衡得 BP = 1 − (1−R)/λ，取 λ = 1、R = 0.4 → BP = 0.4，而 RTI 仍是 100%——一間每台伺服器都在吸 40% 自己排氣的機房拿滿分。要分開 BP 與 R 得有第二個獨立量測（dc-22 的三溫度法，BP = (T_排 − T_回)/(T_排 − T_送)，與 R 無關），兩個聯立才解得出 R = 1 − λ(1−BP)。 RCI_HI = 97% 缺三樣：(1) envelope 版本（2011 A1 帶寬 5 K vs 2004 Class 1 帶寬 7 K，同一批溫度給 97.0% 與 97.1%，而「良好」的門檻在 Herrlin 自己兩篇文章裡是 96% 與 95%）；(2) 星號（39 櫃 24 °C ＋ 1 櫃 33 °C，超過 A1 允許上限 32，兩版都判「良好」）；(3) 機櫃數（分母含 N：同一櫃放進 200 櫃機房 → 99.4%，危險沒變、分數更漂亮）。 唯一能回答「有沒有設備超出允許範圍」的是那個星號，不是那個數字。

Q4.（應用＋建模）有人為了多拿 free cooling 小時數，把冰水設定值從 7 °C 調到 18 °C。列出這個動作會打到哪幾張卡，以及資料庫裡哪些欄位會「安靜地變錯」。

答案

打到四張卡，方向不一致： - dc-21：這是它建議的——門檻濕球 = T_chws − a_tower − ΔT(1−ε)/ε，7 °C 冰水門檻 1 °C（台北一年 0 小時）、18 °C 門檻 12 °C（冬季可觀）。 - dc-24：正面衝突。 室內露點下限 ≈ 盤管表面溫度 ≈ T_chws + approach。18 °C 冰水 → 下限 20 °C，永遠壓不到 ASHRAE 建議上限 15 °C。而台北八個月室外露點高於 15 °C——衝突點只有在台北才會爆（乾燥氣候室外露點本來就低，18 °C 冰水一樣合規）。 - dc-22：離風溫被 EWT + approach 釘住，送風溫度整體上移。 - dc-25：若是冷通道封閉，送風上移反而是好事（房間 = 熱通道）；若是熱通道封閉則直接吃掉機櫃進風裕度。 安靜變錯的欄位： 1. can_dehumidify: bool —— 這個欄位在調整那天變成謊言。型錄照印、控制面板照按，按下去只是水閥開到底＋風扇降速，凝水盤沒有水，零告警。→ 不能存布林，要存推導值 min_achievable_dew_point_c = f(chws_setpoint, approach)。 2. CapacityReport 裡所有以 EWT 為輸入算出的顯熱容量，全部要重算。 3. ModePolicy 的 enter_wb_c / exit_wb_c——門檻濕球是 T_chws 的函數，設定值一動兩個門檻都要跟著動，否則遲滯窗口的位置就錯了。 而 chws_setpoint 的真正擁有者在 IT 側（機櫃進風上限 → 盤管選型 → 冰水設定），這是「設施 vs IT 管理平面」第三次穿越——沒有任何一張設施表會顯示這件事發生過。

Q5.（建模判斷）本週把 Dimension 的 invalid 種類從兩種補到四種。列出這四種，並說明為什麼 status: Check 三態也不夠。

答案

#	名稱	出處	發生什麼	處置
1	`meter_stale`	dc-15	錶失聯	退回 nameplate 法，吐 `METER_STALE`。不是 0
2	`formula_out_of_domain`	dc-19b	感測器好好的，公式不成立（HI 9.8 只在 v > 0.61 m/s 有效）	該約束不適用，不可回綠燈
3	`no_consensus`	`dc-24`	單支讀數在合理範圍內、但與群體不一致	剔除離群後重算；剩餘 < `min_valid` 則拒絕控制
4	`physical_change`	`dc-25`	物理世界真的變了（頂板落下），而模型不知道	整份 `CapacityReport` 的前提失效，不只是某一維
為什麼三態不夠：四種的處置方向完全不同——一個退回別的方法、一個停止判定、一個換聚合、一個作廢整份報表。壓成同一個 `NOT_APPLICABLE` 之後，下游只知道「別信這個數」，不知道該做什麼。→ `status: Check` ＋ `invalid_reason: Literal[...]`，兩個欄位都要。
另外還有第五種，但它不是 invalid：`dc-25b` 的 `recirculation = "unknown"`——資料沒錯、公式沒錯、感測器也沒壞，就是一個量測解不出兩個未知數。這是未定（under-determined），和上面四種是不同的軸，而它絕對不可以填 0：填 0 會宣告一間再循環 40% 的機房沒有再循環。

間隔複習¶

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

抽 W36 的 dc-15 電力監測儀表與電錶（2026-09-01，19 天前）¶

為什麼抽它：本週四種 invalid 的第一種就是它立的。dc-15 那句「錶失聯是 stale 不是 0」在 19 天裡長出了三個兄弟。

Q. 一顆 class 0.2 的電錶，接 class 0.5 的 CT，裝在 2 MW 的 IT 負載上。這條感測鏈的精度是多少？在資料庫裡該怎麼存？

答案

不是 0.2%。 IEC 61557-12 明寫：帶外部感測器的 PMD，最終等級要把感測器的 IEC 61869-2 等級與 PMD 本身的等級合併。

最壞情況（線性相加）：0.2% + 0.5% = 0.7%
統計合成（RSS）：    √(0.2² + 0.5²) ≈ 0.54%

2 MW 上的 0.7% = 14 kW，比兩個 6 kW 機櫃還多。拿來跟客戶分帳的話，這 14 kW 每個月都在跑。 所以「我們的錶是 class 0.2」不構成任何保證——資料庫要存的是鏈上每一段的等級，不是一個數字。 而且更糟的在低負載端：CT 精度是在額定電流附近定義的（驗證點 1/5/20/100/120%），一條裝 400/5 CT 的饋線初期只跑 60 A = 15% 額定，誤差比 ±0.5% 差得多。而新機房頭一年正是最需要準確用電資料做容量規劃的時候——CT 照最終負載選，你卻在初期低負載時讀它。 連到本週：dc-25b 對 Score(value, envelope_ref, n_intakes) 的要求是同一個病的第六次——一個裸 float 承載不了它自己的可比性條件。dc-15 是「值＋出處」家族的源頭，19 天後家族成員已經數不完，而共同型別仍然是 0 個。

抽 W34 的 dc-09b 電池測試制度（IEEE 1188）（2026-08-17，34 天前）¶

為什麼抽它：dc-25b 把差壓設定值列為「第四個『沒有 commissioning 產出就沒有告警規則』的欄位」，而前三個裡的第一個就是它。34 天前立的坑，本週第四次踩到。

Q. 電池內阻的 baseline 為什麼不能在驗收當天量？而「換了一台量測儀器」為什麼是資料模型問題而不是稽核問題？

答案

(a) 六個月，不是驗收日。 IEEE 1188 Annex C.4 與廠商保固程序一致要求 baseline 在投入服務約 6 個月後量——新電池尚未完全化成（fully formed），出廠讀值與穩定後差異大。型錄上的內阻值也不能當 baseline，那是實驗室新品平均值。 (b) instrument_id 是 trend 的分組鍵，不是稽核欄位。 內阻沒有絕對意義，只有相對基準線的偏差有意義（deviation% = (R_now − R_base)/R_base）。換一台儀器、換一種量測法、換一個探棒接觸點（壓極柱 vs 壓螺栓五金），baseline 就作廢。所以它必須參與分組，不能只在稽核日誌裡。 同理要記 cell 表面溫度、浮充電壓、充電電流，讀值還要校正到 25 °C 才可比。 (c) 順帶回憶那個最尖的結論：同一筆讀值 35.9% 偏差，在 CPBS 引的 20% 門檻下是「該換了」、在 IEEE 1188-2005 的 30–50% 灰帶裡是「再觀察」、在廠商 50% 保固門檻下是「索賠會被打回」。三個門檻服務三個目的（安全裕度／工程指引／商業契約），塞進同一個 threshold 欄位的系統，回答不了「我們現在能不能跟廠商要錢」。而分母也分歧（baseline vs 串平均：35.9% 會變成 14.5%，判定完全翻轉）。 連到本週：Setpoint(value, basis, source, commissioned_at) 要解的是一模一樣的問題——沒有 basis 的 20 Pa 跟沒有 basis 的 2 Pa 在資料庫裡長得一模一樣，但差 2.69 倍風扇功率。

本週的 model code 連貫性檢視¶

先結算 W37 的三項¶

W37 刻意只排三項、全部 < 30 分鐘。

項目	W37 預估	狀態
1. 建 `datacenter/topics/model.md` ＋改 `dc-daily-card` 練習模板	25 分鐘，「本週唯一一個機制性改動」	🔴 沒做。而 `topics/` 本週開張了——開的是 `dc-25b`（因拆卡），不是 `model.md`
2. `dc-16` 的 50.5% → 58.4%	5 分鐘，第二次排	🔴 沒做，第三次。實測 `dual-corded-equipment.md` 第 70、128、198、209 行仍是 50.5%
3. `dc-09` 的 `energy_kwh()` 改名	10 分鐘，連續第四週	🔴 沒做，連續第五週

項目 1 的結果比「沒做」更有資訊量：topics/ 這個位置本週被證明完全可用——第一張主題卡在那裡活得好好的，.pages、索引、交叉引用全部正常。所以障礙從來不是機制，是「週報寫的東西沒有人去做」這件事本身。

項目 3 依 W37 自己的承諾除名。 W37 原文：「若這週再不做，就照 W36 說的降級成『已知缺陷』，從優先序上拿掉。連續四週排在前面卻不做的事，掛著只會讓整份清單失去可信度。」照辦——energy_kwh() 改名本週正式從優先序移除，登記為已知缺陷。 這不是放棄，是讓剩下的清單重新可信。

而 W37 的那條規律，本週得到第一個反證¶

W37 修正後的規律是：「可貼的 code 只被下一張卡採納，而下一張卡會再貼一份自己的。」 本週的繼承鏈：

dc-22 ──→ dc-23  「接著 dc-22 留下的 RoomReport / AirBalance 往下長」
  └────→ dc-24  「延續 dc-22 的 RoomReport」        ← 跳過了 dc-23
dc-24 ──→ dc-25  「接 dc-24 的 RoomReport」
dc-25 ──→ dc-25b 「接 dc-25 昨天做的 Aisle / Containment」

鏈第一次分叉了，而 dc-23 是分叉後沒有下游的那一支。

後果具體且嚴重：dc-23 是本週最重的一張卡（SplitDimension 是模型第一個「分量」關係、env_offset 是第三層「站點量測正確設備仍拿到錯輸入」、Dimension.kind 第三種 cycles、RefrigerantCircuit），而它的四項貢獻沒有任何一張下游卡接手。 它是本軌跡第一個斷頭節點。

依 W37 的規律，斷頭 = 那四項不會進入模型。而 SplitDimension 恰恰是不做就會出錯的那種——把 sensible_capacity_kw = 101.1 存成獨立欄位，露點一變它就悄悄錯了（本週〈串起來〉第二節整節在講這件事）。

→ 這是本週第一順位，而且它現在只要 5 分鐘：在 backlog 的 dc-26 項目底下用 HTML 註解掛一條「開工前先把 dc-23 的 SplitDimension 接進 RoomReport」。走的是已被證明有效的路徑（下一張卡的練習題），不是再寫一份沒人讀的文件。

本週新增六處¶

🔴 1. `dc-23` 是斷頭節點（見上）¶

不重複，但它排第一。

🔴 2. `Check` enum 被改名、改值、加了第四態，而註解還寫著「三態」¶

這是本週最容易驗證、也最能說明問題的一處。

# dc-19b（2026-09-09）
class Check(Enum):          # 意涵 #3：三態，不是 bool
    SATISFIED = "satisfied"; VIOLATED = "violated"; NOT_APPLICABLE = "not_applicable"

# dc-24（2026-09-15）
class Check(Enum):                      # dc-19b 立的三態     ← 註解說三態
    OK = "ok"; VIOLATED = "violated"; NOT_APPLICABLE = "n/a"; INVALID = "invalid"

六天內，同一個 enum：成員改名（SATISFIED → OK）、值字串改寫（"not_applicable" → "n/a"）、多出第四個成員（INVALID），而註解仍宣稱自己是「dc-19b 立的三態」。

這不是風格問題。"not_applicable" 與 "n/a" 如果各有一批資料寫進資料庫，之後任何 WHERE status = ... 的查詢都會漏掉一半；而 INVALID 這個新成員正是 dc-15 那條 stale 語意的容身處——它被靜悄悄加進來，沒有任何一張卡說明它與 NOT_APPLICABLE 的分界。

這一處同時證明了兩件事：(a) 鏈式繼承會傳播型別，但不會保護型別；(b) 註解不會跟著改，所以漂移在 code review 時看不出來。

→ 收斂（併入 #4）：Check 固定四個成員、值字串用全名，INVALID 必須配 invalid_reason。

🔴 3. `AirBalance` 的層級從房間降到通道，型別名沒變¶

已在〈串起來〉第五節展開。補一條實作面的後果：dc-25b 的 evaluate(balance, intakes_c, envelope) 簽章收的是一條通道的 AirBalance，而 W37 給 RoomReport.binding() 的設計收的是房間的。兩個函式現在都存在、都叫得動、參數長得像，而它們的 λ 不是同一個量。

→ 明確命名：AisleAirBalance 與 RoomAirBalance，或至少讓 RoomReport 持有 aisles: list[Aisle] 而不是自己再存一份 air_balance。趁只有兩處的時候改。

🟡 4. 四種 invalid ＋一種未定，`Dimension.status` 的最終形狀¶

承 Q5。本週終於有足夠證據把它定下來：

class Check(Enum):
    OK = "ok"
    VIOLATED = "violated"
    NOT_APPLICABLE = "not_applicable"   # 公式適用域外（dc-19b）
    INVALID = "invalid"                 # 配 invalid_reason
    UNDETERMINED = "undetermined"       # ★ 新：量測數不足以解出（dc-25b）

InvalidReason = Literal["meter_stale", "formula_out_of_domain",
                        "no_consensus", "physical_change"]

UNDETERMINED 與 INVALID 必須分開：前者是「再加一個量測就能解」（dc-25b 的 R 需要三溫度法），後者是「這筆資料不能用」。處置一個是加點位，一個是修東西。

🟡 5. 同一間機房，同一週，兩個熱容，差 9%，兩張卡互不知情¶

卡	體積	熱容	ride-through
`dc-23`（09-14）	1000 × 4 = 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

兩張卡都自稱是「同一間機房、純空氣上界」，差 9.3%，而 dc-25 沒有提到 dc-23 已經算過一次。

數字本身不打緊（都是量級估算，且 dc-25 的版本更細緻）。打緊的是機制：這是「同一個推導在不同卡裡各做一次、結果不同」的首例——比 W37 記的「同義不同名」更深一層，是同名同義不同值。

→ 一旦有一個量被算過兩次，它就該是函數不是數字。 room_thermal_mass_kj_k(geometry, include_underfloor: bool)，而 include_underfloor 必須是顯式參數——因為兩張卡的差別就在這裡，而沒有人寫下來。

🟡 6. `Finding` 一週新增八種，而其中一種明說自己不是錯誤¶

dc-23:  RIDE_THROUGH_INSUFFICIENT
dc-24:  OPPOSING_ACTUATION, CANNOT_MEET_LIMIT
dc-25:  CONTAINMENT_DEGRADED, FAULT_DOMAIN_SPLIT
dc-25b: RECIRCULATION_HIGH, RCI_DEGRADED, INTAKE_ABOVE_ALLOWABLE

W36 #2 已經說過「Finding 只有 severity，還需要 kind 與 lifecycle」。本週給了它一個無法迴避的證據：FAULT_DOMAIN_SPLIT 被 dc-25 明寫成「不是錯誤，是該被記錄的事實」。

一個只有 severity 的型別裝不下「這不是問題」。→ Finding.kind: Literal["violation", "prediction", "fact", "degradation"]，而這次有八個新實例在等它，做與不做的差距會在下週變成十幾個。

另外兩組並列關係要在實作時保留、不可合併： - RCI_DEGRADED（指數判準 → 調全房設定值）vs INTAKE_ABOVE_ALLOWABLE（合規判準 → 派人去看那一櫃）——後者可以在前者全綠時發生 - CONTAINMENT_DEGRADED(reason="no_feedback_point") vs (reason="known_broken")——缺點位與已知壞掉是兩回事

順帶：`Limit.basis` 第一次用在時間維度上¶

dc-25 驗收表第 2 列：熱通道封閉的 26.4 秒仍應吐 RIDE_THROUGH_INSUFFICIENT，因為 26.4 < 300。兩個門檻要寫成 list[Limit]，basis 分別是 generator_start（10 s）與 crac_restart_delay（300 s）。

dc-19 立 Limit.basis 時是流速與壓降（空間維度），dc-20 讓它改變改善動作，本週它第一次用在時間上。同一個機制第三次擴張、零次重構——這是個好兆頭：Limit.basis 是目前唯一一個被三張卡沿用而沒有漂移的設計。值得記下來當正面對照組。

本週優先序（三項，全部 < 15 分鐘，且全部走「掛進下一張卡」這條已被證明有效的路徑）：

在 backlog.md 的 dc-26 項目下掛註解：開工前把 dc-23 的 SplitDimension 接進 RoomReport。 5 分鐘。排第一是因為 dc-23 已經斷頭，而 SplitDimension 是不做就會算錯的那種。

在同一處掛第二條：Check enum 固定四＋一個成員、值用全名、INVALID 配 invalid_reason。 5 分鐘。本週 #2 與 #4 一次解決。

dc-16 的 50.5% → 58.4%（四處：第 70、128、198、209 行）＋第 212 行那句自相矛盾的「50.5% × 2 = 101%」。 5 分鐘，第三次排。若下週再不做，比照 energy_kwh() 降級成已知缺陷除名。

3、#5、#6 本週不排，但理由跟 W37 不同：它們現在有明確的載體（下一張卡的註解），只是 dc-26 的註解一次掛三條會失效。先掛兩條，驗證這條路徑真的有效，下週再加。¶

本週該問 facility 的問題¶

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

Q1 — 問機電設計單位＋ IT 團隊（必須同時在場）¶

🔴 最不可逆的一題。封閉型式一旦蓋下去就改不了，而它同時決定冰水設定值與停電時的存活秒數。

「設計的是熱通道封閉還是冷通道封閉？伺服器的設計溫升抓多少 K？如果是冷通道封閉，請現在當場算一下『房間目標溫度 − 伺服器溫升』等於多少——那就是 IT 進風溫度。另外，CRAH／CRAC 的風扇在不在 UPS 上？」

為什麼要一起問：溫升的答案在 IT 手上，封閉型式的答案在機電手上，而兩個答案相乘才知道這個設計存不存在。分開問會得到兩個各自合理、湊在一起無解的答案。

你要聽到什麼：如果答案是「冷通道封閉」＋「溫升 20 K」＋「房間維持 24 °C」，那送風要 4 °C、冰水約 0 °C——當場指出這個組合無解，不是比較差。風扇那一題：冷通道封閉下停電 ride-through 是 5.0 秒，發電機起動 10 秒。如果對方把「風扇上 UPS」當節能選項在評估投報率，那個框架本身就錯了。

Q2 — 問機電設計單位（冰水系統）＋控制系統承包商¶

⚠️ 設備選型前必須定案。這一個數字同時決定三件事，而三件事的最佳值互相衝突。

「冰水設定值定案了嗎？定在幾度？ 如果要走高溫冰水（18 °C 左右）換 free cooling 小時數，那除濕靠哪一條路徑——是補氣端加一台 DOAS 走 DX 盤管，還是在 CRAH 裡塞 dual-fluid 的水冷 DX 迴路？ 這筆錢在預算裡嗎？」

為什麼是這三件事：T_chws 同時決定 free cooling 門檻濕球（7 °C → 台北全年 0 小時；18 °C → 冬季可觀）、室內露點的物理下限（≈ T_chws + approach，18 °C 冰水 → 下限 20 °C，永遠壓不到 ASHRAE 建議上限 15 °C）、以及 CRAH 送風溫度。在台北，第一件事和第二件事直接打架。

你要聽到什麼：如果對方說「高溫冰水啊，省電」但講不出除濕路徑，那就是買了 free cooling、賣掉了濕度合規，而且要到入夏才會發現。兩條路徑的資本支出落點完全不同（一個在補氣路徑上多一個設備節點、一個在既有設備上多一個模式），規格書裡混用兩套詞會直接打架。

Q3 — 問控制系統承包商 / BMS 整合商¶

⚠️ commissioning 當下問得到，事後永遠問不到。三個都是「沒有 basis 就等於沒有」的參數。

「(a) 冷通道的差壓設定值是多少 Pa，誰定的，依據是什麼？ (b) 每一台 CRAH／CRAC 的加濕與除濕功能是全開，還是只留兩台？溫濕度感測器有幾支、上次校正是什麼時候？ (c) CRAH 的 ΔT_設備 是量出來的還是假設的？ 驗收規格書裡的 RCI 門檻引的是哪一份文件、哪一版 envelope？」

為什麼這三個綁一起問：全部住在 BMS 的控制序列裡，全部不在任何銘牌上，而且全部都有一個「廠商預設值」會在沒人選擇的情況下生效。

你要聽到什麼： - (a) 若答案是「廠商預設」——20 Pa 與 2 Pa 之間差 2.69 倍風扇功率，而三個常見數字（20 / 1–5 / ≈0 Pa）沒有任何一個來自標準，全是廠商與專利口徑。這是每天在燒的錢，而沒有人選過它。 - (b) 若答案是「全開、沒校正過」——crossover 幾乎是必然。ENERGY STAR 的處方直接得近乎粗暴：把大部分機組的濕度控制關掉，只留兩台且彼此拉遠。而在台北，那些加濕器一年該跑 0 小時。 - (c) ΔT_設備 是 RTI 的分母，現場幾乎沒人真的量，通常塞一個 20 K 進去——而 dc-22 已指出舊機 10 K、新刀鋒 28 K 都存在。

這週沒選上、但別忘記的¶

屋頂冷凝器區的設備間距與圍牆高度，有沒有做過 CFD 或夏日實測進風溫度（dc-23）——這決定你落在演算二那張表的哪一列，而沒有任何一張設施表會記錄冷凝器進風溫度。若之後真的走 CRAC 路線，這題要升到第一順位。
冷媒種類、單台充填量、全廠總量、有沒有申請到環境部的 HFCs 核配（dc-23）——CRAC 設計壽命 15–20 年，台灣 2025 年起實施核配制度。這是營運風險不是採購風險，但時間軸比本季長。
補氣是專用 DOAS 還是靠 CRAH 自己吸進來，風量多少 CFM、怎麼量的（dc-24）——它決定整棟樓的加濕除濕負荷，而它常常從來沒人量過。已部分含在 Q2 裡。
消防把封閉當獨立防護區還是障礙物？頂板是 drop-away 還是固定？若是，動作後有回授點位進 BMS 嗎（dc-25）——這是 AHJ 的裁量，是專案輸入不是設計常識。單獨問會得到「再確認」，建議併進消防圖審的正式提問單。

節奏¶

（一）9/16（三）缺一張卡，而且原因不在沙箱¶

本週 4 張卡、5 個工作日。git log 與檔案時間戳一致：9/14 dc-23、9/15 dc-24、9/16 無產出、9/17 dc-25、9/18 dc-25b。

這次不能賴磁碟或 proxy：9/17 的紀錄明寫「沙箱本日恢復正常，磁碟 9.3 G 可用，wc -m 與 mkdocs 皆可執行」，而 9/16 的前後兩天都正常產出。排程任務那天沒有留下任何痕跡——沒有 commit、沒有未追蹤檔案、沒有殘留 lock。

→ 建議在 dc-daily-card 收尾加一條：無論成功失敗，都在 datacenter/index.md 或一個 datacenter/.runlog 追加一行（日期＋結果＋失敗原因）。 現在的情況是「空手」與「沒跑」在事後無法區分，而這兩件事的處置完全不同。斷鏈紀錄本身有價值——但前提是它存在。

（二）`.git/*.lock` 從 9/18 殘留到今天，兩天¶

開工時檢出 .git/HEAD.lock 與 .git/index.lock，時間戳 9/18 08:12——正是 dc-25b 那次排程的收工時間。本次已呼叫 allow_cowork_file_delete 清除。

這正是 CLAUDE.md 記載的那個坑，而它這次擋了兩天：使用者本機的 git 在這兩天內任何 commit 都會失敗。9/19（六）、9/20（日）不是工作日所以沒被發現，但如果卡在平日，就是連鎖停擺。

→ dc-daily-card 與 dc-weekly-review 收工時的 rm -f .git/*.lock 顯然沒有實際生效（9/18 那次收工後就留下了）。建議把它從「收工步驟的一行」改成收工檢查：刪完之後 ls .git/*.lock 確認為空，不為空就在 index 標紅。

（三）字數：本週兩張合格、兩張已知超標未處理¶

卡	`wc -m`	判定
`dc-23`	10 292	🔴 超過 10 000 硬上限（9/17 已記錄，未處理）
`dc-24`	10 973	🔴 超過（同上）
`dc-25`	9 993	✅ 距上限 7 個字元——拆出 `dc-25b` 是對的決定，否則必超
`dc-25b`	8 162	✅ 舒適區

dc-25 的 9 993 值得停一下：初稿超標 → 拆卡 → 兩張都合格，而且拆出來的那張成了第一張主題卡。這是本軌跡目前處理超標最好的一次示範，比回頭壓縮好——壓縮是犧牲深度，拆卡是把一個混在一起的主題分開。

dc-23 / dc-24 是否回頭處理仍留給使用者裁決。建議比照 dc-25：dc-23 的「冷媒法規與立管」那一段（來源分歧一、二）其實是獨立主題（制度＋管路設計），拆成 dc-23b 比壓縮合理。

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

5 張舊卡、6 處 $$，在 CF Pages 上會印出字面字串。dc-23 / dc-24 / dc-25 / dc-25b 皆已刻意避開 $$，所以問題沒有擴大，但也沒有縮小。修法（pymdownx.arithmatex: {generic: true} ＋ extra_javascript 掛 MathJax）需本機 build 驗證後再動。

下週¶

佇列下一張：dc-26 液冷 CDU（coolant distribution unit）。 第二輪冷卻鏈的液冷段開工。預期它會一次踩到本週三個新東西：(a) 又一個 SplitDimension（一次側／二次側是同一份熱的兩段，受守恆式綁住）；(b) fault_domain 的第四軸（液冷迴路的邊界既不是接線也不是通道幾何）；(c) ride-through 會再降一次——CDU 停了，冷板上的水幾公升，比本週的 5 秒還短。而 dc-26 是本週兩條收斂註解的載體，請先掛再動筆。
⚠️ dc-27 RDHx / DLC 幾乎確定要拆。 dc-26 之後緊接的那張同時有「後門熱交換器」與「直接晶片液冷」兩個主題，六格裝不下兩種拓撲。比照 dc-19b / dc-25b 的做法，建議現在就在 backlog 裡預留 dc-27b，不要等寫到一半才發現。
dc-28 空間層級本週第三次被提前需要（dc-19b 標高、dc-25 通道歸屬、dc-25b 的 AirBalance 掛在通道上）。三次了。 建議認真考慮把它從第三輪提到 dc-27 之後——沒有座標，通道歸屬算不出來，而本週已經有兩張卡的 Finding 依賴它。
W39 的間隔複習：抽 W37 的卡（dc-19 ~ dc-22）＋ W35 的卡（dc-10b ~ dc-13）。注意 dc-10b 已在 W37 抽過，請從 dc-10c / dc-11 / dc-12 / dc-13 裡選。
⚠️ 現場驗收單第四次提醒。 W35 建議整理成一頁帶去現場、W36 與 W37 各提一次，本週第四次。本週又加三項：(a) 冷通道差壓設定值與其依據（dc-25b，沒有 basis 的設定值等於沒有）、(b) 封閉頂板型式與煙偵動作後的回授點位（dc-25，沒有它火警演練後容量模型會靜默變錯）、(c) 溫濕度感測器支數、位置與校正紀錄（dc-24，少於 3 對就不該做濕度控制）。連同 W32 ~ W37 的清單，這九份合起來就是現場驗收單。 commissioning 隨時可能開始，而這件事的優先級應該高於下一張卡。
⚠ 單線圖對照盤點仍未做，承 dc-17 ~ dc-25b 共九張卡的註記。排程任務手上沒有公司的單線圖，無法自動執行。本週再加一個需求：盤點時除了拓撲與標高，還要記機櫃座標（dc-28 的前置）。