出廠測試規範

#1.1.13 候選：遠端 DI → MQTT Converter 驗收（WI-266）

以下為必測項，尚非 PASS 紀錄；必須用最終候選 firmware 與配套網頁資產完成。記錄 UID、Build ID、boot、Master/Slave ID、接線及 MQTT topic。

範例（41 須替換成現場站號）：

{"di2":${rs485.41.DI2:0},"measuredAt":${rs485.41.DI2.timestamp}}

這是 Converter 範本，不是尚未填值即可解析的 JSON。量測時間為 Master 成功收到 FC02 的時間；未對時為 null。不可把無效來源當成 OFF。

2026-10-27／1.1.12 發布狀態：功能整合版已上雲端；Master／Slave、Finder 通訊及 HTTP 穩定性尚未完成驗收。發布與驗收分開記錄，以下測項仍須以目標設備實測，不以主機測試或短輪成功代替。

2026-10-27 增補：Master/Slave 交付另須完成下方 RN.1～RN.6；其後 6.0.134/135 結果為歷史記錄，不代表 1.1.8 已通過。

#2026-10-27：1.1.9 總覽角色驗收補充（待實機驗證）

• Slave 模式總覽不顯示外接 RS485 設備卡，顯示本機 Slave ID 與 DI；角色未確認時不沿用舊 Master 卡。
• 切回 Master 後恢復原設備卡，設備設定與 enable 值不變。
• MQTT telemetry 啟用時仍更新角色；接收 DI 資料超過 10 秒後，下一次刷新須顯示未知／過期，新 IO 資料才可恢復 ON/OFF。角色回覆不能延長 IO 有效期。
• 角色回覆逾時（含 body 未結束）須能自動恢復查詢。主機測試不替代安裝後的畫面核對。

#RS485 角色與網路並行驗收（1.1.8 新增）

適用於提供 Master/Slave 功能的韌體。8310/Ethernet 與 8320/Wi-Fi 分別測試；測到其中一台或只在 Master 操作不算通過。記錄 UID、版本、Build ID、bootCount、角色與起始完整設定備份。以下是測試要求，並非已完成結果。

USB rs485 <JSON> 僅存在於實驗室 network-diag 映像，不是交付介面。正式使用設備頁或既有 MQTT/HTTP 角色協定。診斷版的通過不可取代最終 production 映像測試；本輪實際結果見 1.1.8 驗證紀錄。

135手動測試增補（v2）：135另跑OC.4／OC.5／OC.7，不能沿用134的實測PASS。確認sample在±0.02kg波動及20秒人工等待內固定、reading繼續增加；全區段最大最小差>0.1kg、失穩／讀取缺口後舊憑證不復活，重新穩定至少5秒。設定可由begin的toleranceKg調整，預設0.1kg，與精度允收分開。手動完整三段、工廠震動、保活／長時仍須本輪記錄。

2026-10-06 134 現場結果：.46 已安裝 6.0.134，Build ID 35B4EEB5DA9C49EC9B363566A7EFE4B7；實秤三段總量 5→25→45 kg 與 finish 均有匹配 applied／complete。降載 25／5／0 kg，面板與系統為 25.01／5.01／0.01 kg。原 checkbox／Converter 設定保存，收尾後已觀察到恢復數值變動才送。完整 MESB 含8資產，BIN 778128 bytes，餘裕1872。雲端通道 beta，僅此台此輪證據，其他設備仍須自行驗收。

仍未完成：業主允許誤差尚未定義，以上讀值不是精度簽核；五段實秤、校正後物理斷電保存、業主 Edge、長時與例外故障仍待驗。134 只讀觀察仍有 read_frame／MQTT 重連及最大27.772秒接收缺口；133保活逾時FAIL保留。OC.12與1.0均未放行。內部原始證據：docs/qa/qa-wi252-field134-2026-10-06.md。

版本：3.17 | 日期：2026-10-06 | 韌體版本：6.0.134（beta，1.0 未放行） 來源 PRD：docs/prd/prd-factory-test.md(內部文件,未公開) v1.2（結構基線）+ 本文件 v2.1 增量（依 6.0.8 源碼/實機核校） 操作手冊：guide-user-operation-manual.md

WI-252 新增範圍：交付線上多段校正時必做 Phase 5C。134已通過本輪容量、安裝及三段實秤協定核對；SC 舊流程與主機模擬均不能替代 OC 的實機結果。

#工站人員先看這一頁

這份文件要確認「設備出貨前，該做的檢查都有做」。自動程式跑完，只代表它負責的部分完成；磅秤、接線、斷電與現場交接還要逐項確認。

每個指令只做一次對應動作；看完預期結果，再往下一步。Mac 與 Windows 選自己的指令版本。有錯誤就記下來，不要直接跳到「出貨通過」。 沒有實體磅秤時，可以完成模擬和通訊檢查，但實際準確度要交接到現場。

新版校正與時間檢查的詳細命令集中在 現場驗收流程，不要另外抄出一套不同的指令。下表的編號是對照用，並不代表程式已經幫你全部做過。

#⚡ 先跑自動化閘門(v2.2 起,任何改動後都必須執行)

任何韌體或網頁改動之後,先跑這一道再談其他。 此套件含暫時寫入與還原設定的 ST 測項，必須在允許變更的測試設備執行。只讀頁面核對使用 test:factory:pages。

cd web
DUT_URL=http://<設備IP> EXPECT_FW=<版本> npm run test:gate

目前包含 35 個 Playwright 測試:頁面渲染(2A–2F)、v6 能力契約、穩定性與持久化(ST.*)。 全數通過才算通過 —— 任何一項紅燈都代表出貨品質有缺口。

其他交機前自動化套件如下，均須確認治具可操作並保留起始完整備份：

npm run test:converter  # ★ MQTT Converter 鏈路(產品主幹),素材自建自清,約 3 分鐘
npm run test:enable     # 啟用/停用機制(⚠ 見下方說明,目前不作為出貨門檻)
npm run test:backup     # ★ 雲端備份/還原閉環(會讓設備重開一次),約 2 分鐘
npm run test:persist    # 真的重開設備,驗設定與統計跨重開存活(約 1 分鐘)
npm run test:factory    # 完整功能測(含 MQTT 佈建,會寫入設定)

#驗收走查回歸（npm run test:regression，RG.1–RG.9）— 納入出貨門檻，須在當輪候選執行

2026-08-25/26 照著驗收單實機走了一遍,挖到五個缺陷。既有出廠閘門一個都沒攔到, 而且不是「剛好沒測到」,是測試的形狀不對 —— 既有測項驗的是「東西在不在、頁面開不開」, 五個缺陷全部落在「內容對不對、值有沒有真的寫進去」。

最直接的證據:把 WI-202 的壞值注回設備(整份 TCP IO 設定在網頁上消失、 顯示「尚無 TCP IO 通道」),factory-pages 依然 6/6 全綠。閘門對它完全無感。

cd web
DUT_URL=http://<設備IP> npm run test:regression

只有 RG.5 預設略過(它會重開設備,要跑帶 RG_ALLOW_REBOOT=1;已實測通過)。

⚠️ 2026-08-27:RG.7 在此之前從來沒有真的執行過。 package.json 的 test:regression 是唯一沒帶 MQTT 環境變數的腳本 (旁邊四個都有),RG.7 因此每次都靜默 skip —— 報表顯示「6 passed」, 看起來很健康。已補齊環境變數,現在會真的跑。

教訓:skipped 不是中性的。一個永遠跳過的測項,和沒有這個測項是一樣的, 但它在報表上長得像有在守。看回歸結果時要同時看 skipped 的數量與原因。

⚠️ 2026-08-28:RG.7 在整套連跑時偶發假紅燈,已修測試方法。 單獨跑綠、RG.5+RG.6+RG.7 最小組合也綠,只有整套跑會紅 —— 而整套跑到 RG.7 時 設備剛經歷 RG.5 的重開加一輪負載。原本的寫法是「建通道 → 固定等 2.5 秒 → 發一次 → 固定等 5 秒 → 讀一次」。MQTT 對「訂閱之前就發出的訊息」沒有補送 —— 設備若還沒訂好新通道的 topic,那則訊息就永遠消失,測試必紅。

已改為週期重發 + 輪詢讀回(45 秒內每三輪重發一次)。這個教訓 acceptance_run.py 早就記過(「通道剛建好時設備可能還沒訂閱」),RG.7 沒套用。

誠實記一筆:那次的錯誤訊息因為輸出被 grep 過濾而遺失,根因是從程式碼推斷、 不是從錯誤訊息實證。修正本身站得住(移除的是本檔已咬過兩次的同一類問題), 但若日後 RG.7 再紅,不要假設就是這個原因。

教訓:跑長時間測試套件時,不要用 grep 過濾輸出 —— 失敗細節只有一次機會保留。

⚠️ 2026-09-01 追加 RG.9(WI-212)。 這一項補的是既有閘門的一個結構性盲點: 43 項測試全都在區網內對設備發請求,所以「設備連不到網際網路」一項都不會紅。

WI-212 的設備看起來完全健康 —— 網頁開得了、區網連得到、IP/閘道/遮罩查起來全對 —— 但跨網段的封包一個都出不去(真兇是多建的一張 netif 搶走預設介面)。

鑑別力是實測的:故障狀態(v6.0.86)量到 dnsErr=-3009、connCloudIP443_ms=0, 兩條斷言當時都會紅。

教訓:閘門測「設備回應我們」,不等於測「設備到得了外面」。 這兩件事在一台工控閘道上同樣重要,而後者過去完全沒有守。

⚠️ RG.2 / RG.3 必須走瀏覽器,不能用 API 並發代替。 這兩個缺陷都在前端 (saveRule 算 index 的邏輯、saveIoName 走 WI-170 的寫入佇列),直接打 API 測到的是我們自己的測試碼,不是產品。初版就是這樣寫的:RG.2 一次就綠(bug 還在)、 RG.3 則「測出」一個其實不存在的缺陷(WI-201 因此大幅更正)。

2026-08-27 追加 RG.8(WI-208)。 業主人工驗收時回報「藍色呼吸燈會卡住, 卡住的時候按鈕就延遲、甚至沒反應」—— 量出主迴圈有 6.8% 的時間完全凍結, 真兇是授權門控每 30 秒重驗一次簽章(663ms)。改為到期驅動後降到約 0.8%。

這一項有實測的鑑別力,不是推論:修正的第一版(v6.0.76)把 expiresAt==0 誤當成「1970 年就過期」,快取完全沒生效 —— 同樣的 200 秒觀測窗裡 gate 重驗 出現 8 次。RG.8 的判準當時會紅。

2026-08-27 更新:七項全綠(RG.5 另以 RG_ALLOW_REBOOT=1 單獨驗過)。 這一輪另外修掉兩個測試自身的問題,兩個都會產生假紅燈: ① RG.2/RG.3 用固定 4 秒等 window.nav 備妥 —— 單獨跑夠,整套跑時設備有負載就不夠 (實測單獨 2 秒即備妥、整套跑時逾時)。已改為輪詢至函式真的存在。 ② RG.3 用譯文 /儲存中|Saving/ 判斷寫入佇列是否忙碌,但徽章實際顯示「💾 bH 1」 —— io.saving 這個 i18n 鍵三個語系檔全缺(WI-207),t() 查不到時回傳鍵本身, 讓 || "儲存中" 變成死碼。判斷失效 → 提早讀取 → 假紅燈。已改為比對不會被翻譯的 💾。

2026-08-26 更新:六張卡全部修好,這一組已全綠。 每一項都經過「先紅後綠」—— 修正前該測項紅、修正後綠,同一台設備、同一支測試。 韌體 v6.0.72 經 LAN .mesb OTA 上機驗證,test:gate 35/35、test:regression 6/6。 已納入 test:gate:full,現在它真的有在守。

test:converter 是最該跑的一支。 業主買的就是「MQTT 進來能驅動輸出、 量測值能定時送出去」—— 頁面全部正常但這條鏈斷掉,設備等於沒有用。 它會自建 CV-* 前綴的素材、測完自己刪光,並以「素材必須清乾淨」作為最後一項斷言。

#閘門守著的「已知會壞的那幾類」(逐項對應真實事故)

#MQTT Converter 鏈路(npm run test:converter,5 項 + 收尾清理)

這幾項固化的是 2026-08-18 夜間的完整手動驗證。當時結論只存在於對話裡, 下次改動不會有人幫忙擋 —— 這正是「測試樣本要全面覆蓋」的意思。

#啟用/停用機制(npm run test:enable,7 項)

畫面上到處是啟用/停用的開關,先前一個都沒測。這類機制壞掉的方式特別惡劣: 「畫面顯示停用、實際還在動」(業主以為關掉了,機器卻自己跑), 或「停用之後再啟用回不來」(現場只能重開機碰運氣)。兩種都不會有錯誤訊息。

⚠ test:enable 目前不列入出貨門檻。 它已經達成目的 —— 2026-08-20 完整跑過 7/7,證實六種停用機制的語意都正確 (停用真的停、重新啟用都回得來)。但這支測試本身還不夠穩: 測項之間有順序耦合(前一項的雲端等待會影響後一項的量測)、 依賴 MQTT 環境變數(用 npx playwright -g 單獨跑會因前綴/密碼未設而失敗)。 結論可信,工具待磨。修穩之前不要拿它當出貨紅綠燈,否則會訓練人忽略紅燈。 | 收尾 | 用 afterAll 清素材(不能寫成最後一個 test,見下方) |

每一項都同時驗兩個方向:停用要真的停、重新啟用要回得來。 只驗前者的話,「停用之後就再也回不來」這種更難救的缺陷會漏掉。

收尾一定要用 afterAll,不能寫成最後一個 test。 序列模式下只要前面任何一項失敗, 後續 test 就不會執行 → 素材殘留 → 下一輪再建一份同名的 → 名稱查找抓到第一份 → 鏈路指向錯的通道 → 之後每一輪都失敗。2026-08-20 實際踩到:一次失敗滾成兩份素材, 手動清掉才恢復。 一律走「真的送 MQTT、真的看實體 DO」,不看欄位存不存得進去(那是 ST.4 的事)。

#雲端備份 / 還原閉環(npm run test:backup,4 項)

備份/還原是所有其他測試的安全網 —— 出廠測試會寫入設定、現場調參數也會出錯, 能不能救回來全靠它。它壞掉時最危險的地方是平常看不出來:設備→雲端的推送 有自己的授權路徑、照樣 HTTP 200,只有真的要「讀回來」時才發現 401。

寫這幾項時踩了兩個判準錯誤,值得記下來:

1. 不能用「快照數量增加」當判準 —— 雲端會裁切舊快照,數量可能不變;要比對最新那份有沒有換人。
2. 設定沒變更時推送不會產生新快照,那是正確行為(內容相同不重複存,實測連推 80 秒都不會多)。 所以測試要先真的改一個欄位再推,否則會把正確行為誤判成「回成功但沒發生」。

維護原則:每修一個缺陷,就在這裡加一列。 出廠測試的價值來自「它涵蓋了已知會壞的東西」,不是「它有很多項」。

#本批韌性修正:閘門測不到的那些(v6.0.41 → 6.0.65)

上面的表格是「有自動化守著」的部分。但這批交付還改了一些自動化測不到、卻直接影響 現場可靠度的行為。列在這裡不是為了完整,是因為下一個人改到這些地方時要知道當初為什麼這樣寫 —— 沒有測試會替他擋。

這張表的維護方式和上面那張不同。 上面那張是「每修一個缺陷加一列測試」; 這張是「改到這塊之前先讀這一列」。如果哪天有辦法替其中一項寫出自動化測試, 就把它搬到上面那張表去 —— 那才是真正被守住了。

#🔧 換設備 / 換現場時要改哪裡

測試分成兩類,換環境時只有第二類需要動:

#只改一個檔:web/tests/factory-env.js

const HARDWARE = {
  // RS485 上預期存在的設備。空陣列 = 該站沒有 RS485,相關測項自動略過
  rs485: [ { slaveId: 1, model: 'finder6m', name: '電流計' } ],
  // 預期的擴充模組「實際連線」數量。0 = 沒有擴充槽
  expansionModules: 1,
  hostDoWiring: '4 個 DO 接三色燈(DO1=紅 DO2=綠 DO3=藍 DO4=蜂鳴器)',
};

改完之後 ST.14 會替你把關:設定檔宣告的硬體與設備實際回報不符就直接紅燈, 不必等某個功能測莫名其妙失敗才回頭猜哪裡不一樣。

#常見情境

原則:測試碼一行都不該為了換環境而改。要改就改設定檔 —— 改測試碼會讓「這一站為什麼要特別處理」的知識散落各處,下一個人接手就看不懂。

#文件用途

本文件是正式工站操作規範，供產線測試人員逐步執行。所有步驟可由一位測試員在單一工站完成。

自動化實作（v5.9.130+，跑真實 DUT）：

🚀 一鍵測試（自動偵測 UID + 前置檢查 + 跑功能+頁面）：

bash

./scripts/run-factory-test.sh [DUT_IP] [ADMIN_TOKEN]
# 預設 192.168.72.77 / smmsadmin；輸出 12 tests PASS/FAIL

套件	涵蓋	執行
web/tests/factory-functional.spec.js	決定性韌體能力（beforeAll 自佈建 fixtures，不依賴設備現狀/RS485）：連線、MQTT 輸入、2-source AND 順序強制、signal→rule→CH_TCP publish→broker loopback（6 tests）	npm run test:factory:func
web/tests/factory-pages.spec.js	Phase 2 五頁面渲染（Overview/Config/Rules/Devices/Settings，5 tests）	npm run test:factory:pages
web/tests/factory-v6.spec.js	v6.0.x 能力回歸（純 HTTP 唯讀契約,不改 config）：Phase 0 機型身分（hasWifi/boardModel/version/mac）、Phase 6B 遠端診斷（/api/log + /api/diag + auth 401）、Phase 2E.6a MQTT 測試契約（202+輪詢）、Phase 2E.6b namespace 欄位 + TLS 出廠預設（13 tests）	npm run test:factory:v6
web/tests/factory-cleanup.spec.js	Phase 7 出貨清理（FR-H，部分 test.skip 待韌體 endpoint）	—

一次跑功能+頁面+v6 回歸：npm run test:factory（於 web/,共 41 tests，含 stability）或 ./scripts/run-factory-test.sh（repo root，自動偵測 UID）。EXPECT_FW 環境變數鎖定出廠版號基線（預設讀取 src/config.h）。

決定性原則（出廠品質基準）：functional 測試在 beforeAll 自己 idempotent 佈建 fixtures（wdprobe + ft_* 引擎元件）+ 清 retained，不依賴設備現有 config、不依賴 RS485 硬體。因此同韌體 → 同結果；唯有韌體能力改變才會讓結果變。對出廠空機也成立。fixtures 由 Phase 7 一併清除。 物理治具步驟（砝碼/SG-002/DI 開關/拔網路線）無法自動化，仍由本文件手動 ☐ 執行。 ⚠️ 跑前 watchdog 須暫停（會 reboot 干擾）。

#工站前置條件

#治具接線

#平台容量基準（硬體衍生，6.0.8 沿用）

#變體識別（機型 × 網路，二維）

工站開始前必須讀 /api/system 判定 兩個維度，並寫入結果摘要 metadata：

維度 1 — 機型（來源 = OTP boardInfo().wifi，不可靠 WiFi.status()）：

• hasWifi=false / boardModel="8310" → 8310 機型（無 WiFi 模組）：強制乙太網路;設定頁隱藏 WiFi 欄位;心跳燈 = 琥珀色（紅+綠同亮）;H6 Failover Skip;AP 模式進不了。
• hasWifi=true / boardModel="8320" → 8320 機型（有 WiFi）：可 WiFi;心跳燈 = 藍燈（LEDB）;H6 Failover 依網路變體決定。

維度 2 — 網路變體（讀 network.netType 與 /api/config interfaceMode）：

• netType="Ethernet" 且 interfaceMode=0/1 → ethernet 變體（H6 Failover Skip）
• netType="WiFi" 或 interfaceMode=2 → wifi 變體（H6 Failover 必測，僅 8320 可能）

⚠️ 8310 恆為 ethernet 變體(無 WiFi 硬體)。wifi 變體必為 8320。

工站 profile 需於啟動時設 model: 8310|8320 + variant: ethernet|wifi，寫入結果摘要 metadata。

#啟動檢查清單

• DUT 已上電，Status LED 閃爍中
• DUT 已取得 IP，工站電腦可 ping 通
• 瀏覽器可開啟 DUT Web UI（http://<DUT-IP>）
• RS485 設備已上電（Finder + YX523R 兩台）
• SG-002 信號產生器已上電
• MQTT Broker 已啟動（明文 1883）
• 機型 + 網路變體 已從 /api/system 讀取並寫入結果摘要
• 首次燒錄後首開機：Web UI 完整渲染（非裸 HTML;app.js 走 QSPI 已載入）

#Phase 0：連線檢查（FR-F、FR-A1-07）

測試記錄：

DUT UID:        ___________________
DUT MAC:        ___________________  (12-hex 對外身分)
FW Version:     6.0.100 (預期)
Board Model:    8310 | 8320
Variant:        ethernet | wifi
configCrc:      ___________________  (出廠 baseline)
測試日期:        ___________________
測試員:          ___________________

#Phase 0A：空機、網路與授權路徑（人工治具）

#Phase 1：初始化（FR-C1）

#Phase 2：UI 驗證

#2A. Dashboard 總覽頁（FR-A1）

#2B. Config 配置頁（FR-A2）

#2C. Rules 規則頁（FR-A3）

#2D. Devices 設備頁（FR-A4）

#2E. Settings 設定頁（FR-A5）

#🛑 Phase 2 的判準:畫面說成功,不算數

上面 2A–2F 驗的是「頁面元素在不在」。那擋得住整頁壞掉, 但擋不住這一族更常見的失敗:

畫面回成功、HTTP 回 200、清單上東西也在 —— 唯獨值沒寫進去,或寫到別的地方。

走查至今挖到的假 PASS 幾乎都是這個形狀(WI-199 index 撞號覆蓋、 WI-202 一個引號讓整頁設定蒸發、WI-206 下拉選項對錯韌體列舉)。

所以凡是在網頁上做的設定,存完要立刻打 API 對照,兩者相符才算過:

在畫面上做了什麼	立刻對照
幫 I/O 通道命名	GET /api/config 的 inputNames / doNames
建輸入群組	GET /api/signals —— sourceCount 不可以是 0
建輸出群組	GET /api/actions —— outputCount 不可以是 0
建規則	GET /api/rules + 交叉比對 signals/actions,抓懸空參照

懸空參照特別重要:群組被刪掉、規則還指著它,韌體是 fail-safe 當「關」, 不會報任何錯,畫面上也看不出來。

完整做法見驗收單〈情境 U:網頁設定流程〉—— 那一段就是為這件事寫的。

#Phase 3：跨頁與持久化驗證（FR-B）

#Phase 4：硬體煙霧測試（FR-C）

#H1. 初始化

#H2. Host / Expansion DO 跑馬燈（FR-C2）

測試員操作：觀察燈號與通道對應

#H3. RS485 驗證（FR-C3）

#H3-A. YX523R 光警器寫入（Slave ID=4）

透過 Dashboard setDO() 或 POST /api/modbus/manual_write（FR-I1-02）

人工確認點：測試員目視確認光警器燈色 / 爆閃模式（FR-C3-01）

#H3-B. Finder 6M.TB 讀取驗證（Slave ID=1）

#H3-B2. 同型號多台 slaveId 持久化（v6.0.2，選做）

驗 6.0.2 修正:ModbusRegister.slaveId 存進 flash,重開機後不歸零、不退回陣列位置比對 → 同型號多台不串台。需兩台同型號設備(如兩台 SF965)。單台工站可跳過並標 H3-B2: SKIPPED (單台)。

#H3-B3. 離線來源不發假 0（v6.0.7，選做）

驗 6.0.7:converter 模板引用到離線 RS485 來源時,整筆跳過發佈(不送 {"counter":0} 讓 MES 誤判計數歸零)。ConverterEngine::pushTemplate 依 _fillHadOfflineSource 跳過。需 broker 訂閱觀測。單台工站可跳過並標 H3-B3: SKIPPED。

#H3-B4. SF965 計數器原生解碼（v6.0.8，選做,需 SF965 硬體）

驗 6.0.8 新 dataType VAR_SF965_PV(=8):SF965 PV@addr4 為特規 32-bit——高 3 byte=計數值、低 byte=小數點位數(dot)→ 值 = (raw>>8)/10^dot。選 SF965 型號套預設暫存器即用此型別(不再靠 ÷256 scale 湊)。

#H3-C. TDA-08B 稱重控制器情境驗證（Slave ID=1，v5.9.111 sensor-fusion 計件器情境）

對應源碼提交 9cea4cd（v5.9.111）TDA-08B + sensor-fusion 虛擬通道 + 計數器 peak-detection。 v5.9.112+ 已移除 TDA-08B 模板，本情境必須手動建立暫存器與虛擬通道。 完整逐欄位 / 標定流程 / 排錯：docs/hardware/setup-tda-08b.md(內部文件,未公開) 治具：TDA-08B 稱重控制器 1 台、5kg 標準砝碼、感測器（壓力 / 應變片）。

❗ curl 配置時 JSON 必須 compact（無空格）：Python 用 json.dumps(obj, separators=(',', ':'))，否則 firmware parser 靜默忽略。詳見 setup-tda-08b.md §2B。

#Step 1：手動建立 RS485 設備（Slave ID=1, 9600/8N1, ABCD Big-Endian）

#Step 2：建立 Scale 虛擬通道（sensor-fusion）

#Step 3：計數器 peak-detection 規則

#Step 4：標定指令往返驗證

人工確認點：H3.16 / H3.17 / H3.21 需測試員實際操作砝碼並目視確認讀值穩定（FR-C3-01 延伸）

#Step 5：校正引導精靈 chain 驗證（v5.9.130+，選做）

驗證 MQTT-Chain 工作流校正精靈（4 步驟 + 燈號）。需先佈建 wizard（見 guide-calibration-wizard.md §5）。無 wizard 佈建則跳過並標 H3 Step5: SKIPPED。

人工確認點：H3.23/H3.25 目視燈號切換；H3.26 需實體砝碼。

#H4. 類比輸入 AI 驗證（FR-C4）

容差數值在 HW 拆工後由 web/tests/fixtures/factory-baseline.json 鎖定。

#H5. 數位輸入 DI 驗證（FR-C5）

#H6. 網路 Failover 驗證（變體 = wifi 限定，FR-C6）

Skip 條件：variant != wifi 時整個章節跳過，並在報告標 H6: SKIPPED (ethernet-only)

#H7. 跨協議多對多路由（FR-C7）

#H8. 機型感知 UI 過濾 + 心跳燈（WI-151 / WI-152，8310 / 8320）

來源 = OTP boardInfo().wifi。此章節依機型分流:8310 驗「無 WiFi + 琥珀燈」,8320 驗「有 WiFi + 藍燈」。

#H9. 冷開機:設備比網路先起來（WI-236，每一台都要做）

斷電前先確認所有供電來源；同時接 USB 與獨立 DC 時，必須兩路都切斷並確認設備熄燈。延長線斷電但 USB 仍供電，不算冷開機。

為什麼要單獨測:H6 只是拔網路線,那時分享器是好的 —— 線一插回去馬上就有 IP。 但客戶端停電是整廠一起停,分享器也會關,而設備開機比分享器快很多:

	大約多久可用
設備	20 幾秒
一般網路分享器	60～120 秒

所以設備開機時網路根本還沒好。這件事在 6.0.94 之前是壞的 —— 一台 8310 因此離線 18.4 小時而沒有人發現:它有電、燈在閃, 雲端後台也顯示「上線中」,只有真的去打開網頁才會發現進不去。

⚠️ 8310 沒有 Wi-Fi 備援,一定要測。 8320 就算有線慢了還有 Wi-Fi 頂著, 所以同樣的問題在 8320 上不容易看出來 —— 那正是它長期沒被發現的原因。

兩種「沒過」的樣子,都不可出貨:

看到的	意思
網頁打不開,ping 也不通	設備沒拿到 IP,也沒有再試
雲端顯示上線中,但網頁打不開	最陰險的一種:底層網路好了、MQTT 也通,設備自己卻不知道 → 網頁伺服器沒啟動。從遠端看一切正常

⚠️ 第二種不會出現在任何監控指標上。唯一的檢查方式就是真的去打開那個網頁(H9.3)。

對應驗收單:7.4 設備和網路設備一起斷電

#H10. 單機斷電後完整復原（與驗收 7.1–7.3 對齊）

保留起始完整設定與模板，單獨切斷 DUT 所有供電（含 USB 與獨立 DC），確認熄燈並等待 30 秒後復電（網路設備保持供電）。核對網路、RS485 清單、規則引用、Converter 模板與 onChange，並以新鮮 MQTT 訊息及輸出雙向轉換驗證功能。逐欄比對 D4／ST.16；軟體 reboot 不代替此項。H9 另外驗設備與網路共同斷電。

#Phase 5：端到端業務流（FR-G）

必須在 Phase 4 全通過後才執行。

#Phase 5B：磅秤、量測時間與復電都要驗（6.0.122）

出廠時也要做現場會做的驗收：必須逐列執行驗收 v3.51 的 SC.1～7、TS.1～7、NR.1，並完成其他適用的既有驗收及本文 Phase。以 現場驗收流程「新增驗收」節為操作與通過條件的唯一來源；下表指定出廠證據與責任邊界，不縮減步驟。

#哪些程式會幫你做，哪些要另外做

• scripts/tests/test_scale_multical.py：校正建構與模擬；scripts/tests/calibration_write_failures.py --out OUTPUT_DIR：production loop 寫入失敗停止及 3／4／5 段。需要專案開發環境，不能當實秤精度。
• scripts/tests/calibration_no_scale_live.py --gw DEVICE_IP --out OUTPUT_DIR：無磅秤實機負例，會建立夾具及刻意重開；只在已備份的隔離台操作，結束核對完整清理。不能拿缺設備、沒收到命令的沉默當 PASS。
• scripts/tests/wi250_timestamp_live.cjs：指定實驗室 .46 真 Finder 的 7 項 broker 路徑測試，須提供本輪 EXPECT_FW 與 EXPECT_BUILD_ID；不是任何現場 IP 可直接套用的通用命令。
• Native／host clock 故障測試、實際 Chrome 範本測試、遷移測試與逐輪證據補足 TS 項；單一 timestamp 腳本不代表 TS.1～7 全部完成。
• 現有 test:gate:full／acceptance_run.py 沒有自動串入以上全部新流程。執行者必須另附 SC／TS／NR 結果表；任一適用項缺結果、FAIL 或未清理，不可把出廠標成完整通過。
• 磅秤精度、接點量測、接收端事件時間及完整 H9／H10 依實際資源分別取證。移交待現場項需有負責人與條件，不是放寬 PASS。

#Phase 5C：線上多段校正（WI-252，134 beta）

出廠完整承接 現場 OC.1～OC.12，該節是操作與判準的唯一來源，包含工程命令、治具前置及結果欄。先通過 OC.1，才可進行硬體寫入。不可為了工站先測而調高 OTA 上限或改用 USB 繞過候選門檻。

同一個 ID 可有主機、MQTT+UART替身、真實OPTA+RS485治具、實秤、業主Edge 多列結果。工站只能簽自己實際執行的層級；完整線上校正交付需補齊所有適用層級。控制器掉電保存不能用 OPTA config 備份替代；業主 Edge 生產統計分流不能用我們的模擬器替代。

test:gate:full、acceptance_run.py 尚未自動執行 OC 全套。Phase 8 摘要必須附 OC.1～12 逐項結果、原始證據與未完成責任人。缺任何適用結果、容量 FAIL、未恢復配置或未完成實秤／Edge 驗收，就不能簽完整出廠／交付 PASS。舊 123、其他 UID 或較舊 Build ID 的 PASS 不繼承。

#Phase 6：OTA + 升級迴歸（FR-D / FR-E）

#Phase 6B：遠端維運健檢（v6.0.1）

驗證 VPN-only / 現場無 USB 情境的遠端診斷能力。需 PERM_ADMIN（Bearer smmsadmin）。

⚠️ 勿以「打整頁 + 高頻並發」壓 /api/log（會觸 IWDG 重開）;/ 是 gzip,curl 用 --compressed。

#Phase 7：出貨前清理（FR-H）

由 WI-103 自動化腳本執行。

註 — 校正精靈 / wdprobe / watchdog：H3-C Step5 佈建的 wizard signals/actions/rules、以及 watchdog 用的 wdprobe signal，屬部署時佈建、非出廠基線，會被步驟 7.2 一併清除。出廠不保留；現場部署時依 guide-first-deployment.md §6 重新佈建。

#Phase 8：結果輸出與彙整（FR-F）

#總結表

自動化入口範圍：test:factory = functional 6 + pages 6 + v6 13 + stability 16，共 41 個測試；test:gate 為其中 35 項。test:gate:full 另串 regression／converter／backup，enable 仍按既有政策列非阻擋結果；它不含 test:persist、驗收執行器與人工 Phase，因此名稱中的 full 不代表整份出廠完成。RG.5 須 RG_ALLOW_REBOOT=1 才執行；所有 SKIP 都須列明。完整出廠另需逐項完成本文 Phase 0–8、0A、H9／H10、CV.5／CV.6、ST.16 並簽核。

#結果摘要 metadata

DUT UID:          ___________________
DUT MAC:          ___________________ (12-hex 對外身分)
Board Model:      8310 | 8320
Variant:          ethernet | wifi
FW Version (前):  ___________________（本輪 6.0.134 beta，實際讀回並核對Build ID）
FW Version (後):  ___________________ (Phase 6 後)
configCrc (前):   ___________________
configCrc (後):   ___________________ (Phase 7 後)
Boot Reason:      ___________________ (Phase 6B /api/diag)
測試日期:          ___________________
測試員:            ___________________
工站位置:          ___________________
PRD v1.2 已知 bug 命中:  E-01 / E-04 / E-08 / E-09 (列舉)
擋出貨 bug:        無 | E-XX

#判定

• ☐ PASS — 全部通過 + 0 個擋出貨 bug → 可出貨
• ☐ CONDITIONAL — 全部通過 + 含 🟡 不擋 bug → 可出貨但記錄
• ☐ FAIL — 任一擋出貨 bug 或 Phase 失敗 → 退回工程修復

#失敗項目記錄

#附錄 A：API 快速參考

不存在的端點（404，腳本不可引用）：/api/devices、/api/status、/api/health、/api/version、/api/expansion、/api/tcp_io、/api/templates。

#附錄 B：操作手冊章節對照

#附錄 C：PRD v1.2 已知 UI bug 對工站的影響

已關閉 (False Positive)：E-02（TCP loading 慢顯示）、E-05（時間欄位 probe 用錯 selector）。

#文件修訂紀錄

#2026-09-11 v3.9 同步紀錄

對齊驗收 v3.45／候選 6.0.100，新增 0A、H10、CV.7；ST.16 加入虛擬引用與參數持久化判準。測試基線改讀 src/config.h；保留 EXPECT_FW 覆寫。test:gate 含暫時寫入，不能稱唯讀。

#2026-09-12 v3.10 同步紀錄

驗收 v3.46／出廠 v3.10 同步補記正式雲端 2.5.8 的實測狀態與剩餘門檻；候選規範基線仍為 6.0.100，8320 的 6.0.103 為診斷版。測項 ID 與對應不變；補上 backup 整輪重開數守門，清理失敗與診斷缺樣都不放行。

#2026-09-12 v3.11 同步紀錄

驗收 v3.47／出廠 v3.11 同步明列各套件的版本與證據範圍，撤除未標版本的回歸全數通過標題；階段 7／H9／H10 補上切斷 USB 與獨立 DC 等所有供電。韌體規範基線仍為 6.0.100，未將診斷版 111 或單輪 41 項通過提升為整機放行；測項 ID 不變。

#2026-09-12 v3.12 同步紀錄

驗收v3.48／出廠v3.12同步WI-246的單次補發訂閱前置與失敗分類。出廠CV.4使用MQTT客戶端實際SUBACK，未放寬12秒／至少1則判準；驗收B6固定等待的證據限制明列。測項ID與6.0.100規範基線不變，111的實機結果另記。

#2026-10-01 v3.13 同步紀錄

承接驗收 v3.50 的全部 SC／TS／NR 項，區分模擬、實機與現場精度，明列既有自動化未自動串入新版完整流程。

#驗收既有項目的出廠交接補齊

#附錄：版本演進與工程判定規則

以下保留先前的版本紀錄與工程規則，供查問題時使用。

#歷史：2026-10-01 出發前候選補充（6.0.122）

下方 2026-09 的版本與逐輪紀錄保留為歷史；本輪候選為 6.0.122，並非 1.0 正式放行。雙機全套最終 .46 72 PASS、.250 70 PASS／2 硬體 SKIP（含保留首輪失敗的明確補跑）；acceptance .46 29 PASS／2 原接線 WARN，.250 18 PASS／5 硬體 SKIP。

本次重點為 磅秤零點＋3～5 段 與 MQTT 原始量測時間。缺實體磅秤的精度／實際 RS485 校正仍需現場驗收；不能把邏輯故障模擬當成實秤 PASS。整組斷電且路由器延後啟動已驗雙機自動恢復與 186 秒穩定觀察；未做逐路接點／獨立 DUT 斷電，也未量精準全滅時間。本次整組斷電不能替代下方 H9／H10 全部條件。

新驗收應檢查量測時間屬於原樣本、未知時間為 null、寫入失敗不誤亮完成燈，以及復電後先 reset 再重新標零。原測項 ID 與歷史證據不改寫。

v3.7 修訂摘要（2026-09-02,韌體基線 → 6.0.90）：

• 韌體基線 6.0.89 → 6.0.90(WI-216 / WI-217)。兩者都無功能變更: /api/net/diag 拿掉恆為誤導的 netifIsDefault、app.js 刪掉一段死碼。 驗證結果:test:gate 35/35、factory-stability 16/16(ST.1 40/40、 ST.9 bootCount 全程未變)、test:regression 的 RG.9 通過。
• ⚠️ 新開 WI-218:OTA 之後不要馬上跑閘門。 這次 OTA 後設備在 WiFi 上 花了 605 秒 MQTT 才接上,期間每次重連失敗把主迴圈卡住 18.4 秒 (設備單執行緒,那段時間 HTTP server 沒被輪到)。結果 ST.0 ECONNRESET、 ST.1 超時、RG.8 抓到一次 NTP 校時觸發的授權重驗 —— 三項紅在三個不同理由上, 但根都是「設備還在暖機」。等 /api/system 的 mqttConnected 翻成 true 再開跑,同樣的測試全綠。詳見 docs/sprints/cards/backlog/wi-218-*.md。

v3.6 修訂摘要（2026-09-01,首次在「無線」環境完整重跑三套）：

• 兩個假紅被抓出來並修掉,都在測試裡、韌體沒有回歸(WI-214 / WI-215)。 當晚網路線被移到 8310,8320 落到 WiFi 上 —— 這是這兩個缺陷第一次被看見, 因為它們只在較慢的無線環境發作,有線環境一路全綠。
• RG.9 改為「先靜置再量、最多重試 4 次」,timeout 120s → 240s。 原因:/api/net/diag 是在 inbound handler 裡再開 outbound 連線,而設備共 4 個 socket(ADR-019)。套件連跑時借不到 socket,connect() 回 -1,長得像網路斷了。 靜置後連量三次全部健康(閘道 38ms、跨網段 9113ms、dnsErr=0)。
• 2B(TCP 通道渲染數)改為輪詢到數量相符,斷言本身一字未改。 同一頁在 WiFi 上要 5~7 秒才畫完,而原本只等 4 秒。
• ⚠️ 教訓:測試套件在單一環境全綠,不代表它在交付環境會綠。 出貨前至少要在「設備當下實際使用的介面」上跑過一次。

v2.9 修訂摘要（2026-08-26,完整重跑驗收流程後）：

• 新增 RG.7(WI-206:Parser「值類型」下拉的 option value 必須對得上韌體 ParserValueType)。該缺陷是走情境 M.3 時抓到的:選「數值」實際會得到布林, 任何非零數字變成 1.0。RG.7 必須斷言 UI 的 option value —— 只用 API 送 parserType:1 驗「韌體會給數值」是抓不到的(韌體本來就對,錯的是前端綁定)。
• 韌體基線 6.0.72 → 6.0.74(WI-206 + WI-197)。
• 全流程重跑結果:test:gate 35/35、test:regression 7/7。

v2.8 修訂摘要（2026-08-26,六張卡修完並實機驗證）：

• test:regression 全數通過,已納入 test:gate:full —— WI-199/200/202/203/205 五個缺陷 已修並經「先紅後綠」驗證(修正前紅、修正後綠,同一台設備同一支測試); WI-201 經查是誤判(WI-170 的寫入佇列早就處理了),已大幅更正該卡。
• 韌體基線 6.0.69 → 6.0.72,經 LAN .mesb OTA 上機,test:gate 35/35。
• 新增 RG.6(WI-205:被拒絕的規則 POST 不得毀掉既有規則)。
• 順帶修好一個從沒被測到的舊 bug:modbusTcpWriteDO 的擴充分支對區域副本取址轉型, Modbus TCP 寫擴充輸出一直沒有作用;已與規則引擎統一用 getExpansionPtr。

v2.7 修訂摘要（2026-08-26,與驗收走查對齊）：

• 新增 npm run test:regression（RG.1–RG.5） —— 驗收走查挖到五個缺陷, 既有閘門一個都沒攔到。這五項是它們的回歸,目前預期紅燈,修好前不列入出貨門檻。
• 修正一個實驗證明的閘門盲點:2B 原本只斷言「TCP 通道」標題可見, 注入 WI-202 的壞值(整份 TCP IO 設定在網頁上消失)後仍 6/6 全綠。 已改為比對「設備上有幾個通道」與「畫面上列出幾個」。
• 環境預設值對齊:factory-env.js 的 DUT_URL 改 .77(有線)、EXPECT_FW 改 6.0.69; package.json 內的舊值一併更新。
• ST.2 改為非破壞性:原本寫死 index: 7,設備規則數 ≥ 8 時會覆蓋現場既有規則 —— 2026-08-26 實際毀掉一條 A2-MQTT亮。已改用「附加位置」(ruleCount)。 該次紅燈同時揭露韌體缺陷 WI-205(回 400 卻仍寫入且不回滾),已補 RG.6 回歸。
• 測試設定來源收斂:先前 6 支 spec 各自寫死 DUT_URL 預設(3 支 .46、3 支 .77), factory-v6 的 EXPECT_FW 還停在 6.0.8 —— 文件卻宣稱「換設備只改一個檔」。 已全部改為從 factory-env.js 取值,那句承諾現在才是真的。
• 已知未處理:package.json 有 4 處明文 broker 密碼(見 WI-204,交付優先暫緩)。

v2.6 修訂摘要（2026-08-20,交付定案版）：

• 測項與腳本對齊(文件先前寫錯)：test:converter 是 5 項 + afterAll 收尾(CV.9 是清理不是測項); test:enable 是 7 項,EN.5(停用 RS485 設備)已從腳本移除 —— 該卡片在畫面上只有「刪除」沒有停用開關, 測一個使用者碰不到的控制項沒有意義;新增 EN.8(停用 Config Server 總開關)。
• 新增章節「本批韌性修正:閘門測不到的那些」:WI-175/180/181/182/183/189 六項, 列出各自「為什麼會壞」與「怎麼驗的」。這張表的用途是改到那塊之前先讀,不是測試清單。
• 新增 npm run test:gate:full:唯讀閘門 + 三支會改動設備狀態的套件一次跑完(交機前用)。 test:gate 維持唯讀語意不變(OTA 後、現場都能安全跑)。
• 本文件已發佈到雲端文件中心 /docs/factory-test.html。

v2.1 修訂摘要（2026-07-16,韌體 6.0.4 → 6.0.8 對齊 + 源碼核校修正）：

• 韌體基線 6.0.4 → 6.0.8：全文版號斷言改 v6.0.8；新增 v6.0.5~6.0.8 能力。
• 新增自動化套件 web/tests/factory-v6.spec.js(13 tests,純 HTTP 唯讀契約)：Phase 0 機型身分 + Phase 6B 遠端診斷 + Phase 2E.6a MQTT 測試契約 + Phase 2E.6b namespace 欄位;npm run test:factory:v6。已對實機 8320(6.0.8)全綠。
• ⚠️ 源碼核校修正欄位名(舊文件錯,自動化已抓出)：
  • /api/diag 實際欄位 = resetReason(非 bootReason)、bootDetail、prevResetReason、bootCount、prevUptimeSec(非 prevUptime)、uptimeSec、rawRsr、fwVersion。
  • /api/system boardModel 值 = 字串 "Opta RS485 (8310)" / "Opta WiFi (8320)"(非 "8310"/"8320");hasWifi 為 boolean;兩者一致。
  • mac 在 /api/config(非 /api/system),格式為冒號大寫(如 A8:61:0A:50:8B:61);對外 topic 12-hex 身分 = 去冒號轉小寫。
• SF965 原生解碼(6.0.8)：H3 新增 VAR_SF965_PV(dataType=8)手動驗證列(需 SF965 硬體;PV@addr4 高 3 byte=值、低 byte=小數點)。
• 離線來源不發假 0(6.0.7)：Phase 4 新增 H3-B3(converter 引用離線 RS485 來源 → 整筆跳過發佈,不送假 0 誤導 MES)。

v2.0 修訂摘要（2026-07-02，韌體 5.9.45 → 6.0.4 對齊）：

• 韌體基線 5.9.45 → 6.0.4：全文版號斷言改 v6.0.4；Phase 0 讀 boardModel/hasWifi/mac。
• 機型維度（8310 / 8320）新增：變體識別從單一「網路變體」擴為 機型 × 網路 二維（8310 無 WiFi / 8320 有 WiFi），來源 = OTP boardInfo().wifi。新增 Phase 4 H8 機型感知 UI 過濾 + 心跳燈（8310 隱藏 WiFi 欄位 + 琥珀燈；8320 露 WiFi + 藍燈）。
• WI-155 平台化（6.0.0）：新增 Phase 2E MQTT 命名空間（projectName+env → {proj}-{env}/gateway/{mac}，留空 = legacy）與 MAC 軟體覆寫 + 90s 試用回退 驗證。
• 遠端診斷（6.0.1）：新增 Phase 6B 遠端維運健檢——/api/log 網頁 Serial Log（/log.html）+ /api/diag 開機原因（BKPSRAM intent 標記）+ 密碼遮罩不外洩。
• RS485 slaveId 持久化（6.0.2）：H3 新增 同型號多台防串台 驗證（各設不同 slaveId ≤32，重開機後不退回陣列位置、不串台）。
• MQTT 測試連線修正（6.0.4）：Phase 2E MQTT 測試改 deferred（POST 202 → GET /api/mqtt/test 輪詢）+ 對已連線同 broker 短路判定；密碼留空 = 用已存密碼。
• 授權撤銷門控（WI-145）：Phase 7 補「撤銷後 TCPIO/MQTT 擋、DIO/管理不擋」的門控驗證。
• MQTT TLS 出廠預設：tlsInsecure=true（業主指定,不驗 CA）——Phase 2E 斷言此為出廠預設,勿改回驗 CA。
• Web 部署模型：index.html 編進韌體、app.js 等 6 資產走 QSPI 熱更——出廠燒錄後首開機須確認網頁完整（非裸 HTML）。
• 附錄 A 補 /api/log、/api/diag、/api/mqtt/test、/api/license/token 端點。

v1.2 修訂摘要（2026-05-27）：

• H3-C 新增 Step 5 校正引導精靈 chain 驗證（4 步驟 + 燈號 + 順序強制，v5.9.130+）
• 附錄 A 補 /api/signals、/api/actions、/api/converter/template 端點
• Phase 7 註記 wizard / wdprobe / watchdog 屬部署佈建非出廠基線
• 相關：spec-mqtt-chain-workflow.md、guide-calibration-wizard.md、guide-failover-resilience.md

v1.1 修訂摘要：

• 韌體版本對齊：5.9.25 → 5.9.45
• 治具校正：Expansion 1 → Expansion 0（array 從 0 起）；YX523R Slave ID 2 → 4
• 新增 MQTT broker fixture（FR-G E2E 必需）與變體識別（ethernet/wifi）
• Phase 結構從 05 擴充為 08，補上 OTA、E2E 業務流、出貨前清理、結果輸出
• 各步驟加上 PRD FR-* 對應 ID + DOM ID 速查表
• 補上 EEPROM DIP+斷電 物理步驟（先前完全漏掉）
• 附錄 C 列 PRD v1.2 已知 UI bug 對工站的影響

#1.0 候選的驗證與文件同步規則

驗收流程確認現場使用情境；出廠測試另涵蓋機型、硬體、授權、升級、故障恢復及出貨清理。出廠應包含驗收的產品行為；現場接地、照片與業主簽名保留現場執行。

• 每輪記錄 commit、韌體與網頁資產版本、設備 UID／機型、實際網路介面、治具、起訖時間與 bootCount。文件版號表示規範修訂，不表示該版全部實測通過。
• BK.0–BK.3 整輪另守重開數：還原排程前 bootCount 必須維持起始值；取得有效還原工作後，收尾必須恰好增加一次且為 SOFTWARE／api-reboot。缺少診斷、額外重開或非預期原因一律 FAIL；清理失敗時仍要檢查重開，兩種錯誤都保留。
• BK.2 等待雲端 ACK 最多六分鐘（另受整項十二分鐘上限約束），期間只輪詢雲端。此測試預算考量主迴圈 127 秒心跳排程、工作執行緒 60 秒喚醒，以及靜默延後與連線時間；工作 ID 必須相同且狀態為 applied，逾時仍 FAIL。
• PASS、FAIL、WARN、SKIP、未測、受阻分開記錄。缺治具的 SKIP 不能算硬體已通過；刻意略過重開不能算持久化已通過。讀不到 bootCount 時不得宣告整輪通過。
• 各套件的 PASS 必須附當輪韌體、Build ID、設備與報告；舊版回歸結果不能沿用為新候選通過。test:factory 的 41 項不含獨立 regression／converter／backup／persist、完整驗收執行器或人工測項；長時觀察另記實際時長，不以短輪代替。
• 單次補發先建立接收端訂閱，再觸發開閘；出廠 CV.4 等實際 SUBACK 成功後才觸發，保持原12秒觀察與至少1則判準。接收端拒訂、斷線或確認逾時列測試失敗，不能當作有效的0則窗口；驗收 B6 既有4秒等待只屬預備時間，若收不到訊息，須區分訂閱未就緒與產品漏發。
• 未接 RS485 測試目標的工站，驗收執行器須明確加 --no-rs485；階段 5 記 SKIP，不能當成 RS485 已通過。出廠另以 EXPECT_RS485='' 指定無該治具。
• 自動 6.2 選主機及每個已連線擴充中未被已啟用規則控制的 DO 各一路，記錄實際 index；測後即使發生錯誤也恢復原值。所有 DO 都被規則占用時須安排隔離治具，不能把規則持續覆寫當成輸出故障；全路實體接點仍須另驗。
• 備份還原比對排除系統產生的版本、還原工作 ID、checksum、timestamp 與 license.lastCheckAt；身份本身、授權設定及模板內容仍須相符。
• 日誌穩定性測項 RG.8 只計觀察基線後的新增紀錄，保持完整 300 秒；相同文字的新事件仍計入，不能把舊開機日誌重算，日誌銜接中斷或 bootCount 改變也不得通過。
• HTTP 200／queued 只證明推送排程。4.3／8.1／BK.1 必須核對新送達狀態及雲端選定快照內容（含 Converter 模板）；最終備份在 QA 素材清理與原設定核對之後執行。
• 雲端身份以設備管理介面取得的有效身份為準，包含 license fallback。空 cloudToken 本身不是 FAIL；以本設備歷史讀取的實際 HTTP 結果判斷，不把 token 寫入公開紀錄。
• 改測項時，同一筆變更更新驗收步驟、出廠對應及相關自動化；唯一 ID 對應來源為驗收單的「出廠測試對照」。執行 python3 scripts/test_coverage_matrix.py --write 後再以 --check 檢查。
• 同步 docs/assets/acceptance_run.py 與文件站附件，重新建置文件站。靜態對照只證明編號與腳本關係；頁面測試只證明該套頁面斷言，均不能代替整份驗收或出廠簽核。

歷史限制（2026-09-09 候選）：曾有 WI-156 虛擬通道引用錯位及計數器參數跨重開遺失的重現證據，該輪 D4／ST.16 不得簽 PASS。新候選應看相同 Build ID 的逐項重測，不能沿用舊版 PASS 或 FAIL；2026-10-01 本輪結果見本文開頭。

9/11 授權桌上驗收中，8320 在 6.0.100 發生 SOFTWARE/cs-wedge（392 → 393，未要求重開），WI-220 仍擋發布。正式雲端實讀為 2.5.5，8310 的 BK.2 因缺少候選 2.5.8 所要求的 restore.id 未過；不能把部分功能或名稱還原成功當成完整簽核。

9/12 正式 Config Server 已升到 2.5.8；8310／6.0.100 的 BK.0–BK.3 通過，驗收自動項為 18 PASS／0 FAIL／5 SKIP，另四組出廠自動項為 40 PASS／0 FAIL／1 SKIP。8320／Wi-Fi 曾在收到完整內容後拒絕套用；6.0.103 復測的備份／還原功能通過，但還原排定重開之外又多出一次 UNEXPECTED／webhdr，整輪穩定性不合格。WI-220 非預期重開、WI-156、實體斷電與長時門檻仍開啟；不得把部分自動項通過當作整機出廠通過。

#2026-10-01 v3.14：照表操作與白話說明

與驗收 v3.50 同步；操作順序移到前面，保留原測項、完整驗收對照與未執行項標示。

#畫面操作驗收補充（2026-10-02）

多段校正請先依畫面設定 A～E核對入口。6.0.122 尚缺全程網頁的多段安裝與參數操作；工程工具驗證與畫面驗收分欄記錄，不得因 SC 邏輯通過就把純網頁流程標成完成。

#2026-10-05 v3.15：承接線上校正驗收

新增 Phase 5C／OC.1～OC.12，與驗收 v3.51 一對一對照；適用項未測、容量受阻或尚缺業主 Edge／實秤不得簽完整出廠。既有 SC／TS／NR 與自動化套件範圍不改寫。

#6.0.128 毫秒時間驗收補充（WI-250）

沿用 TS.1～7，不以本補充取代原項目。TS.2 檢查 ${sys.timestamp} 訊息時間與 ${rs485.<站號>.<欄位>.timestamp} 量測時間：收到的 UTC 字串有三位小數（例如 .237Z）；Edge 能完整解析並保存，不能固定只收 20 字元。保存至少三筆原始 MQTT payload，確認毫秒不是一律補 .000。未對時／無有效樣本仍為 null。

TS.4 的延遲／補送須逐位元組比對原 payload；TS.3／5／6 依原有時鐘修正、讀取失敗與 onChange 判準驗證，時間單獨改變不得觸發發送。跨秒、跨日、長時計數回繞與舊樣本不被重新對時改寫由時鐘／Converter／輪詢測試留證。毫秒解析度不代表 UTC 誤差小於 1 ms，不可在驗收表代簽該準確度。

#WI-253：32 個 MQTT 命令通道補充驗收（6.0.130 候選）

在隔離設備將測試群組綁定 cmd/signal/31，輸出使用測試 MQTT topic，不接實體 DO。等待接收端 SUBACK 後，分別發裸數字及 value JSON，核對規則／Converter 行為；另驗 0、7、8。32、負數與非數字尾碼不得改變既有命令值。

保存測試前設定及閘門值，設定 31 為非零，等待落地後正常重啟，核對映射與閘門恢復；真正斷电保存仍需獨立物理斷電測試。升級舊 8 筆保存檔時確認 0–7 保留、8–31 為零。測完回復群組／模板／閘門與原設定，確認無殘留。

主機測試不代替 MQTT 實機、重啟或物理斷電證據；本次不擴充輸入群組數。

#WI-259 靜態 IP 中斷復原補充驗收（1.1.6 候選）

此項需 USB 接在受測 OPTA，並先保存設定備份與連續 USB 日誌；一般 USB 可供救援指令，不是 RS485 轉接器。

1. 記錄 UID、版本、Build ID、bootCount、原網路設定；每次測試只操作指定設備。
2. 正確固定 IP：透過 net static <ip> <mask> <gateway> 套用，等首次重啟後從 Ethernet 開網頁確認；再次重啟仍保留設定。
3. 錯誤閘道：使用隔離測試網段，不得占用其他設備 IP；持續 USB 錄影式日誌，測試期間不要對設備送 HTTP/API 或 net keep（這些會確認試用）。
4. 連線未確認：連續 link-up 五分鐘後還原原設定；若試用途中另一次重啟，應在網路初始化前還原，不能每次重啟重算五分鐘而失聯。
5. 核對日誌的實際重啟原因、檢查點及還原訊息，再讀回網路、MQTT、I/O、群組設定；不能只依 LED 或「沒有 fault record」宣稱正常。
6. 正確 Ethernet 連線可確認；Wi-Fi 連線不應替未使用的 Ethernet 設定確認。儲存失敗不得宣稱已還原或刪除唯一備份。

結果需逐項附實機證據；主機測試或候選版建置成功不等於現場／出廠驗收完成。本補充不表示 1.1.6 已正式發布。

#WI-266 交易排程補充（2026-11-02）

• DC.8：網頁輸入20、50、1000 ms並儲存重讀；拒絕19、1001、小數、空白；重開後仍保留。舊設定缺鍵回到50 ms。
• DC.9：單次輪詢失敗後按原週期重試；連續第三次起退避；其他設備仍輪詢，MQTT繼續含null發送。
• DC.10：容量提示區分設定週期、交易間隔、排程窗口及整輪估算；16台邏輯測試不代替16台實機。
• DC.11：混合有效／失敗自訂暫存器，逐欄位null；資料年齡及失敗次數與原始API核對。

#MQTT 密碼邊界（WI-267／1.1.13）

• 31 ASCII：測試／儲存可送出完整值；使用隔離 Broker或攔截請求，不覆寫現場正式憑證。
• 32 ASCII、11個中文字、8個emoji：測試與儲存均提示超長，沒有POST。
• 貼上40 ASCII：整次貼上拒絕並提示，不能先截成31後顯示成功；選取原值後貼上31 ASCII可完整替換。
• 檢查三語提示皆清楚標示31 UTF-8 bytes；頁面無JavaScript錯誤。

#密碼眼睛與 Wi-Fi 長度（1.1.14）

• 在Wi-Fi與MQTT輸入測試字串，實際點眼睛兩次，核對password→text→password、內容不變、aria-pressed與提示切換；不應送出任何設定。
• Wi-Fi63ASCII、21中文符合上限；64ASCII、22中文、16emoji應拒絕。即時計數與aria-invalid一致。
• Wi-Fi一般儲存、全部網路設定儲存、AP儲存並重啟都要在超長時零POST；測試需攔截有效請求，不可用假密碼改正式網路。
• 重載後密碼輸入值為空且隱藏，已存密碼不由API取回；留空保留僅適用一般設定頁。

#1.1.14 出廠 Ethernet 直連驗收

• 清空設定的新機與一般恢復原廠：無 DHCP 伺服器，電腦 192.168.50.10/24 直連，開啟 http://192.168.50.50。核對遮罩 /24、閘道 0.0.0.0，觀察至少 10 分鐘沒有閘道自救重啟。
• 網頁改 DHCP／其他靜態 IP 後重啟，讀回儲存設定；再次升級不得恢復成出廠 IP。
• USB net show、net dhcp、net static 192.168.50.50 255.255.255.0 0.0.0.0，核對試用確認與還原。
• 2026-11-02：預設值、實際 JSON 儲存／載入程式、舊格式遷移及 USB 命令解析已做主機測試；因沒有可清空設定的備用設備，出廠直連、無閘道 10 分鐘與設定切換的實機驗收尚未執行，不得填 PASS。