diff --git a/WORKFLOW_GATES.md b/WORKFLOW_GATES.md
index 9d36381..e7eb84f 100644
--- a/WORKFLOW_GATES.md
+++ b/WORKFLOW_GATES.md
@@ -19,6 +19,18 @@ If buttons are required, the assistant must prefer this sequence:
 Do **not** first send a normal text reply that says buttons will be used later.
 Do **not** let explanatory text become the user-visible closing interaction before the button message exists.
 
+### Early-routing rule
+
+If a workflow can already predict that its final step will require user judgement or acceptance, it must switch to a **button-path** early instead of waiting until the last paragraph.
+
+This especially applies to:
+- full long-task tests
+- regression tests
+- acceptance / fail verdict flows
+- any report whose natural ending is "please judge this result"
+
+If the endpoint is predictably a user decision, the assistant should structure the run so that the final user-facing handoff is already prepared as a button interaction.
+
 ### Forbidden behavior
 
 These are violations when used as the closing interaction on Telegram:
@@ -29,6 +41,7 @@ These are violations when used as the closing interaction on Telegram:
 - `要不要我繼續？`
 - saying buttons will be used, but not actually sending them
 - sending explanation first, and only later sending buttons after being corrected
+- running a full test/report in plain text even though the result is obviously heading toward a pass/fail owner decision
 
 ### Required interpretation
 
@@ -38,6 +51,7 @@ The gate applies to:
 - approval requests
 - next-step choices
 - accept / rerun / stop style decisions
+- pass / fail verdict requests
 
 ### Violation standard
 
diff --git a/memory/2026-04-22.md b/memory/2026-04-22.md
index 9746745..886be2e 100644
--- a/memory/2026-04-22.md
+++ b/memory/2026-04-22.md
@@ -51,3 +51,4 @@
 - 因此已先補一條 skill 規則：`Telegram interaction guard`，禁止 governed long-task flow 在 Telegram 上用純文字選單收尾；若需要選擇，必須改用 inline buttons，否則直接執行最合理下一步。
 - 後續再往前補強到更直接的操作層：新增 `Reply Closure Button Gate` 概念，明確規定只要回覆最後的可執行部分需要總管決定、確認、批准、停止、繼續、重跑或選下一步，就不能只在文字裡說會用按鈕，必須真的送出 inline buttons，或直接執行最合理下一步。
 - 在最短回歸測試後又確認一個更前面的根因：不只要「有按鈕」，而是**若需要按鈕，必須讓按鈕先出場**，不能先送普通文字再補按鈕；因此已把規則再收緊成 ordering rule：優先用 `message` 工具送真按鈕，然後回 `NO_REPLY`。
+- 在完整 long-task 測試後再驗出更前置的根因：若一開始就可預見最後會進入 owner 的 pass/fail 或 accept/reject 判定，流程本身就必須提早切成 `button-path`，不能等到最後一段才臨時想起要用按鈕。
diff --git a/skills/long-task-governor/SKILL.md b/skills/long-task-governor/SKILL.md
index 2931785..c9571d9 100644
--- a/skills/long-task-governor/SKILL.md
+++ b/skills/long-task-governor/SKILL.md
@@ -177,6 +177,7 @@ When this skill applies:
 4. if reporting progress, use the 5-part checkpoint structure
 5. before claiming progress, check for real evidence
 6. if no evidence and no concrete action, stop the clock
+7. if the run is clearly heading toward a user pass/fail or accept/reject judgement on Telegram, prepare a button-path before the final handoff
 
 ---
 
@@ -196,6 +197,7 @@ When operating under long-task governance on Telegram:
 - do not end checkpoints, test progress, or next-step decisions with plain-text menus like `1 / 2 / 3` or `A / B / C`
 - if a choice is genuinely required, use Telegram inline buttons
 - if buttons are required, send them first via the `message` tool rather than first producing a normal text reply
+- if the workflow can already predict the final handoff is a user judgement, move to a button-path before the final closing paragraph
 - if no real choice is needed, execute the most reasonable next step directly
 - if the assistant accidentally emits a plain-text choice menu, or says buttons will be used without actually sending them first, treat that as a workflow violation and convert the lesson into a permanent rule