一 先定義完成不是動畫結束
操作程序畫面常把按鈕變色、進度條走完或旋轉圖示停止當成完成，這些只代表前端呈現，不代表設備真的接受或套用。先把每一步寫成可驗收條件：請求被系統接受是accepted，設備已採用是applied，實際條件成立才是completed。三者要有各自時間、版本、操作識別與來源證據，畫面才可讓另一位人員重查。
例如操作員送出設定轉速120。accepted只能表示請求格式、權限與流程入口檢查通過；applied要有設備回讀版本或明確回覆；completed還要看實際轉速在規格容許範圍並持續指定時間。正常結果是三階段逐一出現且可以展開證據。若網路在 accepted 後中斷，狀態應為未知，不得因按鈕已禁用就顯示成功。本文採通用介面模型，不假設任何PLC或HMI原生欄位。
每一步開始先產生不可猜測的operation_id，保存程序版本與步驟編號。相同意圖的查詢或契約支援的冪等重試沿用識別與內容，並核對保留期限；結果未知且不具去重能力時不可盲重送；不要因重新整理畫面就產生第二個看似相同操作。
畫面上的狀態詞也要有明確定義。可以把accepted描述為入口驗證完成，把applied描述為目標端回覆已採用，把completed描述為條件引擎以指定資料判定成立；每個詞旁邊提供簡短說明與證據連結。不要使用「完成中」涵蓋所有等待原因，至少區分等待回覆、等待條件、資料品質不足與權限拒絕，排查才不會從錯的層級開始。
二 每一步證據與版本關聯
程序可拆成準備、下達、確認、完成等步驟。每一步畫面都顯示狀態、operation_id、程序版本、開始時間、最後更新時間、來源與原因；點開可看送出摘要、接受回覆、回讀值與判定規則。證據要存原始值和品質，不能只保存「綠色勾勾」。版本號至少分程序版本與設備或資料版本，否則同一操作在規則更新後無法說明當時如何判定。
例如步驟2送出閥門開度，回覆accepted= true、設備版本=18，但設定回讀仍是40而目標為60，畫面顯示已接受、等待套用證據；若設定已60而實際位置40，則應區分已套用與尚未到位，不能跳到完成。若回讀品質Bad，保存原狀態碼與最後可信讀值，明確寫出目前無法驗證。正常驗收需能從列表追到每一筆原始證據；失敗驗收要能指出哪一步缺證據。
程序重新載入時，先以operation_id和版本恢復狀態，不用動畫進度猜測。已完成步驟要顯示證據摘要；未完成、逾時或未知步驟要由規格決定查詢、人工確認或安全停止。跨版本恢復若判定規則不同，標記需要重新驗證，不能直接沿用舊的完成標籤。
證據內容需考慮最小權限與敏感資料。操作人員看到足以驗收的摘要，稽核角色才可展開完整回覆；遮蔽秘密不代表刪除操作識別與版本。匯出或交接時依追加式政策保留證據摘要、產生時間與雜湊，另存原始資料的存取位置和權限。若證據被修改或刪除，畫面要顯示缺失原因，不能維持原來的綠色完成狀態。
三 實際完成條件與未知狀態
完成條件必須引用可觀測資料。例如「泵已啟動」可要求運轉回讀為On、故障品質為Good，並在本例三次有效採樣中成立；三次不等於固定持續時間，若要求持續兩秒，還要核對採樣間隔、時間涵蓋與中途未知區間；「批次完成」可要求設備狀態為Complete、批次識別相符且結果摘要已保存。條件中的時間、容許誤差、品質與資料版本都應顯示，避免不同人各自解讀。
逾時只代表在期限內沒有收到足夠證據，不代表失敗，也不代表已套用。畫面用Unknown或待查，附上最後一次已知狀態、deadline、收到的部分回覆及下一步處理。若重新查詢能取得相同operation_id的結果，才轉為已套用或失敗；若只能收到新操作的回覆，不能代替舊證據。
設計故障案例：accepted後服務重啟、回讀延遲、資料品質變Bad、程序版本切換。每案要檢查畫面是否保留步驟順序與未知標記，是否阻止不安全的盲重試，是否可匯出證據供交接。逾時排查先看日誌關聯、版本與來源時鐘，再判斷是設備未完成還是證據未抵達。
四 證據顯示與驗收測試
證據區不要依賴短暫動畫。固定顯示目前總狀態與各步驟最後狀態，另提供可展開的時間線；每列至少有step_id、operation_id、procedure_version、accepted_at、applied_at、completed_at或unknown_reason。文字與圖示同時出現，顏色只作輔助，列印或截圖仍能讀懂。
測試先執行一個兩步程序，確認第一步accepted後故意延遲回讀，畫面應保持等待而非完成；再送入正確版本的回讀值，才轉applied，滿足實際條件後才轉completed。第二步逾時時，總狀態應為Unknown或規格指定的部分完成，且第一步證據不得消失。重新整理、重新登入與服務重啟後，逐項核對operation_id和版本仍一致。
驗收紀錄應包含操作前條件、送出內容、每次回覆、判定輸入、顯示結果與人員確認。若只測按鈕動畫或固定延遲，不能證明流程可靠。此設計可套用於一般工作流畫面；設備是否提供足夠回讀、事件或版本資料，必須在目標系統文件與現場測試中確認。
時間線的排序以明確時區或UTC表示，並把來源時間與本機接收時間分開，排序前先正規化UTC；不同偏移的RFC3339字串不能直接按字典序排。設備時鐘未校準時，不能用兩者差值推論實際處理時間；可改報告「收到回覆前經過幾秒」。驗收表可以列出預期條件、實際值、品質、版本與判定結果，讓測試人員逐列勾核，不必依賴動畫錄影或口頭描述。
若人員只看到動畫而找不到證據，驗收應判定不合格；介面必須提供可複核的狀態、值、時間與識別。
交接時保留失敗與未知紀錄，才能避免下一班誤把未確認操作當成已完成。
五 常見問題與官方參考
FAQ1：accepted是不是已完成？答：不是；它只表示請求被流程入口接受，仍須有applied與實際條件證據。
FAQ2：逾時可以直接顯示失敗嗎？答：不能一概而論；若沒有足夠證據應顯示未知，只有規格明定的失敗回覆才能定為失敗。
FAQ3：程序版本為何要顯示？答：同一條件可能隨規則更新而改變，版本能讓稽核者重建當時使用的判定。
FAQ4：進度條完成可當作驗收證據嗎？答：不可；動畫是呈現層，必須連到可追溯的每步回覆、回讀與完成條件。
參考：W3C WCAG 2.2 Status Messages：狀態訊息應能被使用者辨識，作為文字化狀態顯示的可及性參考。
參考：IETF RFC 3339：可讀且可排序的日期時間表示，供操作證據時間欄位設計參考。