2026-W40 週報：夾層裡的三個租客¶

第十份週報。本週 4 張卡、5 個工作日，週三（09-30）沒有卡，見〈節奏紀錄〉。第三輪「空間、消防、安全」進行到第二週：dc-30 ~ dc-32（含拆出的 dc-30b）。

本週的主題是把樓板以上的實體路徑補完：磚（承重＋開口）→ 地板下的槽（填充＋重量）→ 槽裡的線（長度預算）→ 天花與地板下的煙偵測取樣管（孔＋傳輸時間）。四張卡的共同點是：容量由幾何決定，而幾何不在設備銘牌上。同時本週也是 W39 開出的兩張支票（Rack 合一、Sourced[T]／Check 定案）第一次被兌現，兌現得不完整（〈連貫性檢視〉🔴1、🔴3）。

本週卡片¶

卡	標題	這張卡最關鍵的一個事實
`dc-30`	高架地板	整櫃 1360 kg、前重 60/40（假設）時，兩顆前輪落在同一塊 600 mm 磚上是 816 kg，而且錯開半格沒用（隔壁機櫃的前輪補進來，整排中間磚仍是 816）；台灣廠商 700 型（中心點 700 kgf）不過
`dc-30b`	線槽與走線架	資料線面積先滿、電力線重量先滿：300×100 網格槽 25/40/50% 填充 = 169/271/339 條、50% 也才 20.3 kg/m；600 寬梯架 4C185 單層 11 條就 93.5 kg/m，NEMA A 級（74.4）不夠、B 級（111.6）就夠
`dc-31`	配線架與結構化布線	「100 m」是含跳線的 channel，不是一條線的上限：28 AWG 跳線降額 `perm_max = 102 − 1.95L`，10 m 跳線 → 82.5 m、15 m → 72.75 m；Fluke 的 73 四捨五入會超標，必須 floor
`dc-32`	極早期偵煙 VESDA	VESDA 是取樣網路不是感測器：80 孔、門檻 0.1 %obs/m → 單孔等效靈敏度要 8.0 %obs/m；60 m／30 L/min／10 孔的傳輸時間天真算 41.6 s、修正後 121.7 s（假設值，不可設計用）

串起來¶

一、從樓板到煙霧，一條「路徑」的垂直線¶

上週（W39）把樓板→機櫃接成一條垂直線；本週把機櫃腳下與頭上的東西接進來。四張卡在同一個空間裡各佔一層：

樓板（結構計算書）                                   dc-28
  └─ 高架地板：磚（承重、開口、送風）                 dc-30
       └─ 地板下夾層 ←── 三個租客同時使用
            ├─ 送風（風口磚 5.11 kW/磚）           dc-30
            ├─ 線槽（垂直擋 16.7% 截面）            dc-30b
            └─ 取樣管／孔（掛在 Space 上）          dc-32
  機櫃 ── 跳線 ── 配線架 ── 固定線（沿槽走）       dc-31 ← dc-30b 的 Cable.route
  天花／回風 ── 取樣孔 → VESDA 主機 → 警報分級     dc-32 → dc-33（滅火）

地板下夾層是本週最擠的共享資源：dc-30 的風口磚與開口吃它的空氣（一個沒封的線孔就旁通），dc-30b 的槽擋它的截面（垂直擺 16.7%、平行 0.5%），而且同一個夾層的 underfloor_m3 又是 dc-23／dc-28 熱容的輸入（槽使它 −1%）。三個租客各自的告警都合理，但沒有人替夾層整體負責。目前 Opening、Pathway、Hole 三個實體各自指向 Space，沒有一個聚合物件把三者對同一個夾層的占用加總——這是 dc-28 的 Space 該承擔、但還沒承擔的角色。

二、跨卡演算：槽的實體長度終於吃掉長度預算¶

dc-31 意涵 #4 說「線槽的實體長度終於跟長度預算接上」。用一個假設場景把 dc-30b 與 dc-31 對接：水平固定線沿槽走 70 m、兩端各留 5 m 餘量（示意值，卡片沒給）：

場景	perm 長度	兩端跳線合計	`perm_max`（28 AWG）	判定
短跳線	70 + 10 = 80 m	10 m	102 − 1.95×10 = 82.5	OK（餘 2.5 m）
長跳線	80 m	15 m	102 − 1.95×15 = 72.75	VIOLATED（超 7.25 m）

同一條槽、同一段固定線，跳線多 5 m 就從綠變紅。而 route 的長度由 dc-30b 的 Pathway.length_m 決定，所以「改線槽路徑」（例如為了滿足 dc-30b 的電力／資料分隔距離而繞道）會悄悄改掉 dc-31 的判定。這是兩張卡之間第一條數值依賴（之前都是型別依賴）。

三、掉一個會連鎖到哪¶

連鎖 A：2N 的兩路進了同一條槽（dc-30b → 電力鏈）

竣工圖：A 路、B 路在配電盤層分開（拓撲上 2N，dc-16 scenario 通過）
   → 現場：兩路電纜都走同一條 600 寬梯架（Cable.route 沒記，NetBox 斷點第五條）
   → 一次施工掀磚／槽過載／支撐失效
   → A、B 同時掉，拓撲圖上完全看不到共因

route_independence() 要能算，前提是 Cable.route 有資料；而這個欄位在 NetBox 裡不存在。

連鎖 B：機櫃增減，煙偵測悄悄失準（dc-32 → dc-33）

機櫃增減／隔間改動 → 氣流與取樣點的關係變了
   → 傳輸時間偏離設計值（同一條管天真 41.6 s vs 修正 121.7 s，差 2.9 倍，可見對假設多敏感）
   → 主機仍顯示 Normal（dc-32 常見誤解 #3：保護失效但狀態正常）
   → dc-33 的氣體釋放 Stage 1／Stage 2 觸發晚了，沒有任何告警說它晚了

這條鏈上唯一的防線是「計算報告的日期是否早於最近一次機櫃增減」——是文件欄位，不是遙測點位。

連鎖 C：三個「缺東西」告警共同依賴工單紀律

dc-29 OPEN_U_IN_FRONT_PLANE、dc-30 TILE_LIFTED、dc-32 DETECTION_COVERAGE_GAP，三者都是「物件不在」比「量超標」更危險，觸發都靠一個有時窗的狀態（空 U 靠 MAC 工單、掀磚靠 lifted_at＋work_order_id、VESDA Isolate 靠有起訖時間的工單）。第一次有三張卡共用同一種資料結構需求（見自我測驗 Q5）。

四、「擁有者不是設施」的清單又多三筆¶

延續 W39 的觀察：決定判定的輸入，擁有者多半不是設施。本週新增：

卡	決定判定的輸入	擁有者	設施能不能改
`dc-30`	磚的額定測法（最弱一平方吋／中心點／設計載重）	地板廠商	只能要求揭露
`dc-31`	跳線 24 還是 28 AWG、有沒有 ZDA	布線承包商	施工完成即固定
`dc-32`	Alert／Action／Fire 1／Fire 2 的 %obs/m（日夜兩套）	消防承包商	承包商可改，設施模型不會知道

節奏紀錄¶

本週 4/5：09-28（dc-30）、09-29（dc-30b）、09-30 無卡、10-01（dc-31）、10-02（dc-32）。觀察到的事實：

dc-30b 的 written_at 是 09-29，但 commit 時間是 10-01 00:15 UTC，與 dc-31（00:18 UTC）只差 3 分鐘；同週 dc-30 是 09-28 11:21（+0800）。
09-28 以前的 commit 是本機時區（+0800），10-01 起是 UTC（雲端排程）。
本次開工時 .git/*.lock 不存在。另：本週報的第一次執行在寫檔時遇到與本機的連線中斷，重跑後完成——雲端排程與本機之間的連線本身是一個新的斷鏈點。

可能原因（無法從現有資料確認，只是假設）：(a) 09-29、09-30 的排程都沒能 commit，10-01 才一併落地；(b) 09-30 排程沒觸發或連線中斷。佇列是教材驅動，缺一天不會讓 backlog 錯位，建議不補卡；但請查 09-30 的排程執行紀錄。

連貫性檢視：這週累積的 model code¶

⚠ 範圍說明：repo 內沒有使用者實際寫的 .py 檔，我檢視的是卡片裡的練習骨架與意涵段落（floor.py、pathway.py、channel.py、vesda.py）。本機若已有實作，請以實作對照。

🔴 1. `Rack` 合一只合了一半（W39 #1 的後續）¶

dc-30 骨架宣告「全軌跡唯一的 Rack」，欄位是 id, type, placement, device_kg，註解寫「mounts 加總，這裡先簡化」。W39 定案的合一形式是 Rack(id, type, placement, u_height?, starting_unit, desc_units, mounts)。缺口馬上被打到：dc-31 加分題 (b) 要「呼叫 dc-29 的 Rack.mount」，而 dc-30 的「唯一 Rack」沒有 mounts、mount()、starting_unit——實質上是第三個 Rack。

收斂建議：dc-33 練習第 0 步建立 rack.py，裡面只有一個 Rack（含 mounts）；total_weight_kg() 改為 type.self_weight_kg + Σ mounts.weight_kg，刪掉 device_kg（它是第二個重量來源，會與 mounts 加總不一致）。

🔴 2. `Check` 有四份副本，且都宣稱「與上一張同一個」¶

floor.py 定義一次；pathway.py、channel.py、vesda.py 各自「為獨立執行」重定義，註解分別寫「與 dc-30 同一個」「與 dc-30b 同一個」「與 dc-30b / dc-31 同一個」。目前五態名稱與值完全一致，沒有實際錯誤，但這正是 W39 #5 糾正過的模式（RHO_CP 各自定義）：dc-33 會是第五份，任何人加第六態（例如 STALE）就漂移。vesda.py 另自創 DState，之後 Isolate 狀態與 Space 覆蓋會跨檔使用。

收斂建議：core.py 只放 Check、Sourced、Finding 三個型別，其他檔一律 from core import；「可獨立執行」用「練習資料夾已有 core.py」解，不用複製解。

🔴 3. `Sourced` 在文字裡被要求、在程式碼裡沒人用¶

意涵寫「ChannelRule 數字用 Sourced 包起來」（dc-31 #3）、「load_class: Sourced[NemaClass]」（dc-30b #1）。但骨架裡 NEMA = {"A": 50, "B": 75, "C": 100}、derated_perm_max() 內嵌數字、LIMITS／HOLES 都是裸 dict。UNDETERMINED 目前只由查無 key／回 None 觸發，不由 evidence == "snippet" 觸發——W39 定案的「摘要不可進計算」在這三張卡的程式碼裡沒有防線，只剩人工自律。

收斂建議：規則表 value 一律 Sourced[...]，統一走 resolve(table, key) -> Sourced | None，None 與 snippet 走同一條 UNDETERMINED；驗收表加一列「值存在但 evidence=snippet → UNDETERMINED」。

🟡 4. 同一個欄位兩個名字、同一個位置兩套表示¶

機櫃寬：dc-30 合一後是 RackType.outer_w_mm，dc-31 意涵 #4 與加分題寫 RackType.width_mm ≥ 800——同一欄位。統一用 outer_w_mm，dc-31 文字順手修。
位置：check_direct_attach(row_a, idx_a, row_b, idx_b) 用「列字母＋序號」，而合一後的位置是 Placement(x_m, y_m, rotation_deg)。相鄰應從座標推導（同 dc-28 aisle_of()），不要另存 row／idx。
空間 id：Placement.room_id、FloorSystem.room_id、Hole.space_id 並存；房間只是 Space 的一種 kind，建議統一叫 space_id。

🟡 5. `NemaClass` 的跨距：模型有、程式碼沒有¶

dc-30b 意涵 #3：NemaClass(letter, span_ft, rated_kg_m)，實際跨距大於額定跨距 → UNDETERMINED。但 check_load(load_kg_m, letter) 沒有跨距參數，驗收表 9 列也沒有跨距案例——文字承諾的分支在程式碼裡不存在。建議 check_load 加 span_ft，驗收表補一列。

🟡 6. `Alert` 與 `Finding` 撞名；`INVALID` 長出三種語意¶

dc-32 的 Alert.triggers 指 VESDA 的警報等級（Alert／Action／Fire），而全軌跡的模型輸出叫 Finding。建議設備側改叫 AlarmLevel，Finding 專指模型輸出。另外 INVALID 現在有三種語意：輸入矛盾（check_thresholds 非遞增、面板對應重複）、不可用的門檻（kind == "ultimate"）、W38 的 Dimension 失效。建議 Check 結果帶 reason: str，不要再增態。

做得好的地方¶

dc-30 確實兌現了 W39 兩張支票的主體：外形進 RackType、座標進 Placement、Sourced／Check 定案，驗收表把「額定未知」與「只有摘要」都導向 UNDETERMINED。
total_weight_kg 家族到第四個成員（樓板／機櫃／磚／槽）；繼承鏈 dc-30 → dc-30b → dc-31（Cable.route 加分題）→ dc-32（掛 Space）一條直線，無分叉。

建議的收斂順序：🔴1 → 🔴2 → 🔴3 放進 dc-33 練習的第 0 步（約 20 分鐘）；🟡 項目留到 dc-34 前掃尾。沿用 W39 證明有效的路徑：掛進下一張卡，不寫進另一份文件。

自我測驗¶

Q1.（事實回憶）NVL72 整櫃 1360 kg、前重 60/40（假設）。兩顆前輪壓在同一塊 600 mm 磚上時，這塊磚承受多少？把機櫃錯開半格（300 mm）排列，整排中間那塊磚會變輕嗎？

答案

1360 × 0.6 = 816 kg。錯開 300 mm 後，隔壁機櫃的前輪補進同一塊磚，整排中間磚仍是 816 kg（dc-30 演算一）。台灣廠商 700 型中心點額定 700 kgf 不過；傳統 600 kg 機櫃只有 360 kg，舊機房從沒被這題測過。 對你的模型：tile_loads() 必須由 Rack 的外形、座標、腳輪幾何推導，不能把每櫃重量平均分給磚；額定的測法不同時 PanelRating.comparable_to() 回 False。

Q2.（事實回憶）28 AWG 跳線兩端合計 15 m，固定線量到 73 m，Fluke 報表顯示 73。合格嗎？

答案

不合格。perm_max = 102 − 1.95 × 15 = 72.75 m，73 > 72.75。Fluke 把 72.75 四捨五入成 73，所以「報表上的 73」與「規則的 72.75」不是同一個數（dc-31 驗收表第 5 列）。降額後的固定線要 floor，寫死在程式裡。若改 24 AWG 且跳線 > 10 m，來源沒有數字 → UNDETERMINED，不是照 90 m 放行。

Q3.（應用）VESDA 管網 60 m、30 L/min、10 孔，傳輸時間約 121.7 s，超過 NFPA VEWFD 的 60 s。有人提「把管縮短一半」，另一人提「把流量加倍」。能過關嗎？系統該怎麼判？

答案

兩個方案結果相同：transport_far(30, 30, 10) 與 transport_far(60, 60, 10) 都 ≈ 60.9 s，仍 > 60 s，差 0.87 s → VIOLATED（dc-32 驗收表第 4、6 列）。原本的 121.7 s 對 fia_max（120 s）也超 1.7 s、對 nfpa_ewfd（90 s）也不過。判定取決於採用哪個 regime；查不到 regime（例如 en54_20，三個來源說法不同、原文未取得）→ UNDETERMINED。 對你的模型：transport_time_s 是推導值，要帶 method（naive／harmonic／vendor_software）與 limit_regime，不能是設備欄位；孔被封或流量改變要觸發重算。

Q4.（應用＋建模）一條 600 寬梯架放 11 條 4C185（93.5 kg/m），資料庫記的槽等級是 NEMA A。另一條槽資料庫沒有等級。而 A、B 兩路 2N 電纜都在第一條梯架上。系統該吐什麼？

答案

記 A 級的槽：93.5 > 74.4 → TRAY_OVERLOAD（VIOLATED）；required_class(93.5) 回 B（111.6）。
沒有等級（或只有摘要）的槽：UNDETERMINED，處置是去要等級與支撐跨距，不是放行（dc-30b 驗收表第 5 列）。跨距大於額定跨距也該是 UNDETERMINED（注意 🟡5：骨架目前沒有這分支）。
A、B 共槽 → route_independence() 吐 SHARED_PATHWAY，fault_domain 多一個 pathway 軸。這需要 Cable.route，而 NetBox 沒有，只能自己補 custom field。 對你的模型：TRAY_OVERLOAD 與 FILL_EXCEEDED 分開（兩個上限、兩種單位）；Cable.od_mm、Cable.kg_per_m 必填。

Q5.（建模判斷）OPEN_U_IN_FRONT_PLANE（dc-29）、TILE_LIFTED（dc-30）、DETECTION_COVERAGE_GAP（dc-32）三個「缺東西」告警，觸發前提看起來各不相同。抽象出它們共同需要的資料結構，並指出哪種情況下這類告警會完全不觸發。

答案

共通點是一個有時窗的缺席狀態，不是布林：

Absence(entity_ref, kind, since, expected_until?, work_order_id?, state)

- 空 U：USlot.state = open，起點是下架工單。 - 掀磚：Tile.state = lifted，帶 lifted_at＋work_order_id。 - VESDA Isolate：有起訖時間的工單狀態。嚴重度隨「超過 expected_until 多久」「同區同時缺席數」「房間 kW/櫃」上升。 完全不觸發的情況：缺席沒被登錄成狀態——下架沒開工單、掀磚沒填、VESDA 現場關掉沒進系統。這類告警的有效性上限就是工單紀律，不是演算法。所以三者都該帶 last_audit_at，過久未實地稽核時把覆蓋度標成 UNDETERMINED。

間隔複習¶

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

抽 W38 的 dc-25 冷熱通道封閉（2026-09-17，17 天前）¶

為什麼抽它：dc-25 的來源分歧（三）說冷通道封閉可能被消防視為獨立防護區（separate volume）、熱通道封閉只是障礙物，結論是「AHJ 裁量，必須當成專案輸入」。本週 dc-32 的偵測孔掛在 Space 上，下一張 dc-33 滅火就要決定「通道算不算獨立防護區」——這個舊結論下週就要用。

Q. 一間 1000 m² × 4 m、IT 1600 kW、伺服器溫升 20 K 的機房。(a) 房間要維持 24 °C 給人待，選冷通道封閉，IT 進風會是幾度？(b) 停電瞬間 CRAH 風扇停、伺服器風扇繼續抽，24 → 32 °C 兩種封閉各撐多久？(c) 這對 fault_domain 與消防分區各意味著什麼？

答案

(a) CACS：房間＝熱通道，IT 進風 = 24 − 20 = 4 °C，對應冰水約 0 °C，無解——這個組合在那間機房不存在（dc-25 演算一）。HACS 時房間＝冷通道，沒有這個減號。 (b) 熱通道封閉（冷空氣庫存 4370 m³、熱容 5288 kJ/K）約 26 秒；冷通道封閉（230 + 600 = 830 m³、1004 kJ/K）約 5.0 秒，差 5.3 倍。後者撐不過發電機起動的 10 秒，CRAH 風扇上不上 UPS 是可用性前提。 (c) fault_domain 要拆成 {power, cooling, containment}，再加 dc-28 的 fire 軸；通道歸屬靠座標算。消防：冷通道封閉可能構成 separate volume（要再給通道一套，或讓封閉在煙偵動作時自行解除），熱通道封閉多半只是障礙物——兩說（Upsite vs APC）並列，AHJ 裁量。 回扣本週：drop-away 頂板在消防動作時整片落下，是「另一個系統即時改寫容量模型前提」的耦合；dc-33 的 Detector.level → ReleaseStage 映射要同時帶出 Containment.integrity 的變化。

抽 W36 的 dc-18 冰水主機（2026-09-04，30 天前）¶

為什麼抽它：這張卡的「容量要用求解器、不是常數」是後面許多卡的原型；本週 dc-32 的 transport_time_s（不能是常數）是同一個思路再次出現。

Q. 沿用 dc-17／dc-18 的機房（IT 1600 kW、455 RT、0.55 kW/ton、水塔 4 格 Q = 650 × (T_cw − WB)，冷凝器進水上限 35 °C）。濕球 30 °C、一格保養（剩 3 格）時，系統停在哪個冷卻水溫？紅燈還是綠燈？「紅燈條件」到底是什麼？

答案

3 格 → Q_tower = 487.5 × (T_cw − 30)；Q_reject = 1600 + 455×0.55×(1 + 0.036(T_cw − 32))。兩邊相等：478.49·x = 16186.96 → T_cw ≈ 33.8 °C（approach 3.8 K、壓縮機約 267 kW），低於 35 °C，不紅，但只剩約 1.2 K 餘裕；再掉一格（2 格）就是 35.8 °C → 紅燈（高壓跳脫）。（3 格這列是我用同一組公式解的，原卡表沒有；4 格 32.9 °C、2 格 35.8 °C 與原卡一致。） 紅燈條件不是「水塔容量 < 負載」（dc-17 那樣會算出 142% 的錯誤紅燈），而是解出的平衡點 > max_condenser_entering_c。 對你的模型：max_condenser_entering_c 是設備欄位；equilibrium_T_cw(wb, n_cells_available) 是推導函數；告警是「平衡點逼近上限」，不是「容量不足」。

本週該問 facility 的問題¶

從四張卡的「該問 facility 的問題」（共 12 題）去重、排序後選 3 題。排序依據：答案會直接改變模型某個欄位，且只有現場能給。

1.〔建議問：機電（含地板廠商資料與結構計算書）〕

「AI 櫃那一列的地板磚，廠商額定是『集中載重（最弱一平方吋）』『中心點』還是『設計載重』？請給型錄頁與測法。整櫃從貨梯、走廊推到機房這一路，滾動載重最低的是哪一段、用什麼輪子測的？結構計算書有沒有點載重上限？」

為什麼是它：PanelRating.kind 與 wheel_spec 目前是空的，check_tile() 只能回 UNDETERMINED。來源：dc-30 該問 #1、W39 連鎖 C（整櫃推入路徑）。

2.〔建議問：機電〕

「A 路和 B 路的電力電纜，在哪一段共用同一條線槽或梯架？竣工圖上有沒有線槽路徑這一層？每條電力槽的 NEMA 等級、支撐跨距各是多少？後來加線有沒有人核算過重量？」

為什麼是它：Cable.route 在 NetBox 裡不存在，要自己補；沒有它，route_independence() 算不出 2N 的共因。來源：dc-30b 該問 #1、#2。

3.〔建議問：控制系統承包商（消防警報／VESDA 系統商）；年度維護設不設 Isolate 順帶問維運〕

「每個取樣孔的位置、所屬空間、傳輸時間，有沒有 PipeCAD／ASPIRE 的計算報告？報告日期是不是早於最近一次機櫃增減？Alert／Action／Fire 1／Fire 2 目前各設幾個 %obs/m，日夜兩套是否不同，最近誰改過？」

為什麼是它：transport_time_s 與 Thresholds 都在承包商手上，設施模型不會自己知道；報告日期是唯一能偵測「機櫃改了、管網沒重算」的線索（連鎖 B）。來源：dc-32 該問 #1、#2。

沒選但值得順帶問：dc-31 的「跳線是 24 還是 28 AWG、有沒有 ZDA」——只影響 Cable.awg 一個欄位，問 Q2 時一起要即可。