繼續昨天的FormAdapter

4. 出線行為

節點進入等待狀態後，能讓它繼續往下走的只有三種情況：有權限的簽核者透過表單中心送出決定；設定了簽核 逾時且已到期，由執行器排程自動喚醒重新判定；或流程因為其他分支先觸發了「結束」節點。第三種情況的後續 處理依「結束」節點的結束模式而不同——cancel 模式會主動取消所有還在等待的節點（含這個簽核 任務），任務直接從待簽清單消失，不會留下核決紀錄；detach 或 strict 模式不會 主動取消，這個任務會繼續留在簽核者的待辦清單裡，看起來完全正常——這時候如果簽核者還是把它簽了，系統照樣 會建立簽核紀錄，只是因為流程已經是終態，不會再建立任何新節點，不會報錯，也不會有任何畫面提示。詳見 結束（End）。

誰能簽，判定的不是「進關卡當下的名單快照」，而是「簽核當下即時的身分」：ROLE／ DEPARTMENT（舊）型別在簽核送出時會重新查一次角色與單位的持有關係（含代理與候補），只要 當下持有就算數，即使原本沒被列進等待中的快照也能簽；反之原本在快照裡的人若角色已被收回，就簽不了。 INITIATOR／USER／DYNAMIC 三種型別沒有這層即時判定，認的是進關卡 當下解析出的那份名單，事後身分異動不影響能不能簽。

5. 常見設計方式

5.1 依決策分流到完全不同的後續節點（取自 SOC 團隊版）

出廠預設的SOC版流程圖，為何在設計圖中只有兩條線？其實是因為線條重疊導致視覺誤判，只要拖拉移動即可
這次特別把node拉開，避免讀者誤解。

5.2 依角色與單位動態指派簽核者，不寫死人

固定寫死一個人（USER）適合「這張表單本來就該給某個特定窗口審」的情境；大多數簽核流程 更常見的需求是「依申請人的組織位置動態找主管」，這時用 ROLE 搭配 unit_scope：

{
  "assignee_type": "ROLE",
  "assignee_value": "<部門主管角色的 secure_code>",
  "unit_scope": "APPLICANT_UNIT",
  "self_target_action": "escalate_or_return"
}

unit_scope=APPLICANT_UNIT 只認「申請人自己所屬單位」持有這個角色的人；同一份設計改成 unit_scope=GLOBAL 就變成「全企業任何一個持有這個角色的人都算」，兩者是完全不同範圍，不要 互相取代。部門主管這類角色通常是「職位型」，不會因為單位是祖先關係就自動套用到上層或下層——申請人所屬 單位的上一層若也有主管，要用 unit_scope=APPLICANT_ANCESTOR（往上找）明確指定，不會因為 用了 APPLICANT_UNIT 就自動含括。self_target_action 只在申請人自己剛好就是 目標單位的主管本人時才會觸發，決定要往上一層找別人簽、還是乾脆讓本人簽、還是找不到人就退回申請人重送。

5.3 找不到簽核人時的兩種 fail-safe

「核准」接一條出線走向正常結束；「退回補件」接到一個留痕節點後再繞回這個 FormAdapter 節點自己，形成真正的重簽迴圈——選了這個按鈕流程不會結束，會重新產生一筆等待 簽核的任務；「駁回」刻意不配對任何出線，是唯一會讓流程真的以 REJECTED 結束的按鈕。同一批 決策也可以兩個選項刻意指向同一條出線（例如「核准」與「需要補充資料」都先送到同一個下游節點），這時圖 形結構本身分不出簽核者選了哪一個，必須靠傳出變數，再交給下游的「分支」節點依變數值二次判斷。

要避免案件因為沒人簽核而卡住太久，同一個節點另外加上逾時：

"timeout_enabled": true,
"timeout_minutes": 480,
"timeout_mode": "ABSOLUTE",
"timeout_path_id": "<逾時要走的出線或決策 id>"

ABSOLUTE 從進入關卡那一刻起算，不論是否在工作時間一律倒數；WORKING 只在 簽核者的班表工作時間內倒數，適合「上班時間 8 小時內要簽完」這類需求，但簽核者沒有班表時會自動退回 ABSOLUTE，見注意事項。

6. 注意事項

顯示備註欄位關閉，但最少字數仍大於 0——簽核者永遠送不出決定
症狀：簽核畫面上根本看不到留言欄，但按下任何決策都被擋下「簽核意見至少需要 N 字」，而且 沒有辦法輸入任何文字去補足，形同卡死。
原因：關閉「顯示備註欄位」只是把留言區塊在畫面上藏起來，不會連帶把「最少字數」歸零；兩個欄位 在設定畫面上各自獨立存檔，關閉備註欄位時若沒有手動把最少字數也改回 0，儲存的設定就是 allow_comment=false 加上 min_comment_length>0 這個矛盾組合，而前端與 後端的長度檢查完全不管欄位看不看得到，只認 min_comment_length。
正確做法：要留言就同時打開「顯示備註欄位」；不需要留言就把「最少字數」設回 0。改設定後重新 打開一次面板確認兩者一致，不要只憑「我剛剛關掉了」就假設最少字數也一起清空。

角色型簽核者解析成功，但當下零持有者——不會走「找不到簽核人時」，會靜默停等
症狀：案件卡在等待簽核，待簽清單裡沒有任何人看得到這張單，也沒有觸發「找不到簽核人時」的 退回或改派，查不到任何錯誤或警告紀錄。
原因：「找不到簽核人時」的判定只在簽核者類型不是 ROLE／DEPARTMENT （舊），或這兩種類型本身解析失敗（角色、單位不存在等）時才會觸發；ROLE／ DEPARTMENT 只要角色與單位本身存在、解析「成功」，即使當下一個持有者都沒有，也會直接 帶著空的簽核者清單進入等待，不會被視為異常。
正確做法：這其實是設計上刻意允許的行為——之後只要有人被授予這個角色（或在該單位範圍內）， 就能追溯簽這張已經在等待中的單，不需要事後補救。真正要避免的是「角色暫時沒人」變成事故，那應該在 角色與單位的日常管理上把關，不要指望 FormAdapter 幫忙偵測。

決策選項的「條件顯示」不會真的隱藏按鈕
症狀：在決策選項上設定了「條件顯示」（變數／運算子／比較值），存檔也沒有錯誤，但不論流程 變數是什麼值，簽核畫面上該決策按鈕永遠都在，從未被隱藏過。
原因：「條件顯示」只是把設定值存進 decision_options[].visible_when 並原樣傳給 前端，設計器與執行端都沒有任何程式碼會拿它來過濾要不要顯示這個按鈕——是一個目前沒有作用的欄位。 真正能動態隱藏決策按鈕的是另一個獨立機制：「來向變數控制」（input_variables），要設 decision_visibility 類型的控制規則，並在裡面指定要顯示哪些決策的 id。
正確做法：需要依流程變數動態隱藏／顯示某些決策按鈕時，一律改用「來向變數控制」，不要以為 在決策選項本身填了「條件顯示」就會生效。

駁回類按鈕只要接了出線，簽核紀錄一律記成「已核准」
症狀：語意上明顯是否定或退回的按鈕（顏色是危險樣式、文字寫「駁回」「退回」），事後查簽核 紀錄的動作欄位卻是 approved，不是 rejected。
原因：動作欄位不是照按鈕的顏色或文字語意決定，決定權在送出簽核時的一條獨立規則：只有當這個 按鈕「沒有配對任何出線」而且「按鈕風格是危險樣式」兩個條件同時成立，才會記成 rejected； 只要按鈕接了任何出線，不論按鈕語意上是核准、退回補件還是別的什麼，一律記成 approved。 SOC 團隊版的「封鎖攻擊來源」與「誤判結案」兩個危險樣式按鈕都配了出線，兩者都會被記成 approved，就是同一個規則。
正確做法：要知道簽核者實際選了哪個按鈕，一律去看傳出變數（output_variable 寫入 的流程變數）或簽核意見，不要只看動作欄位；真正需要記成 rejected 的按鈕，設計時就要 刻意不配對任何出線。

逾時去向沒接在目前的出線／決策清單裡，逾時功能整個悄悄不啟用
症狀：畫面上「啟用逾時自動處理」是勾選的，但案件放著不簽，過了設定的時間也完全沒有自動 改道，執行紀錄裡只留一行「逾時去向不在可選路徑內，本關卡不啟用逾時」的錯誤，不會顯示在畫面上。
原因：逾時去向記的是一個具體的出線或決策 id；改了節點的出線、或切換過自訂決策的開關、或 重新配過決策選項之後，原本記住的那個 id 可能已經不在目前算出來的可選清單裡。系統採取的是 「寧可不啟用逾時，也不要啟動一個到期後走不出去的倒數」，所以會整批放棄這次的逾時設定，但簽核本身 完全正常，不會有任何錯誤訊息浮上畫面。
正確做法：改了出線或決策選項之後，一定要重新打開簽核設定，確認「逾時去向」下拉裡目前選的 項目還在、還對；這個下拉每次開啟面板才會依當下的自訂決策或出線重新算一次清單。

WORKING 逾時模式在簽核者沒有班表時會悄悄退回 ABSOLUTE
症狀：設定成「工作時間」倒數，以為下班與假日不會計時，實際卻是連續 24 小時不間斷倒數， 跟「絕對時間」沒有兩樣。
原因：工作時間模式需要一個班表可以參照；系統會從目前的簽核者清單裡找第一個有設定班表的人 當參照對象，找不到任何人有班表時，就直接改用絕對時間倒數，不會報錯也不會有提示。
正確做法：需要「只在上班時間倒數」的效果時，先確認至少有一位簽核者已經設定了班表；企業或 帳號完全沒建過班表時，工作時間模式形同虛設。

7. 在 node展覽館 實際操作

node展覽館裡的簽核示範分兩批，都在系統預設企業（平台建置時內建、唯一看得到 node展覽館 分類的企業） 底下，每個示範都是一份完整可以送單的表單＋流程：

在平台安裝目錄下（載入 .env 後）可以先列出安裝計畫，再實際佈建：

venv/bin/python scripts/seed_node_showcase.py --list
venv/bin/python scripts/seed_node_showcase.py --apply --only B5a
venv/bin/python scripts/seed_node_showcase.py --apply --only B5b

佈建完成後到表單中心的「填寫表單」分類「node展覽館」下即可送單。怎麼看結果：每個示範送單後，用對應 的示範帳號完成或刻意不完成簽核，接著查流程實例的最終狀態、簽核紀錄的動作與簽核者顯示文字、以及各示範 自己的傳出變數是否等於預期值（例如角色＠單位示範的兩個傳出變數應各自反映哪一關被誰簽過）。找不到簽核人 與逾時兩個示範特別要對照「案件是直接以 REJECTED 結束」還是「留在等待中」，這正是本篇第 4、6 節說明的 行為差異。

8. 相關節點

• 結束（End）：簽核者的每個決策通常都有一條路徑最終匯聚到這裡；「結束」 的結束模式也決定了還在等待中的簽核任務會被主動取消，還是繼續留在待辦清單裡。
• 分支（Branch）：兩個決策接到同一條出線時，靠它讀取簽核寫入的傳出 變數做二次判斷；也常用來檢查傳出變數是否已寫入，藉此判斷「這一關是否已經有人簽過」。
• 暫停（Delay）：常與簽核的傳出變數搭配，做「等一段時間後檢查有沒有人 簽、沒有就催辦」的 SLA 計時分支——這條分支本身不會代替人做決定，只負責提醒。
• 寫入欄位（OpFieldWrite）：常接在某個決策之後，留一筆可追溯的 留痕記錄（例如「退回補件」的補件說明、逾時改道的處理註記）。
• 防禦決策（DecisionWriter）：資安處置流程裡，簽核者選擇 「封鎖」或「放行」之後，實際寫入封鎖或放行決策的是這個節點，簽核節點本身不做這件事。
• 緊急廣播（AlertBroadcast）：簽核完成後常接一則廣播通知相關 角色處置結果，或在簽核逾時、無人可簽時發出催辦或升級通報。
• 並行匯合（ParallelJoin）：需要多個 FormAdapter 節點各自等待不同人、 全部都簽過才繼續（會簽）時，靠它收斂——單一簽核節點本身沒有這個能力。未在本系列第一批收錄，暫不 提供連結。