Add early button-path routing for Telegram decision flows

This commit is contained in:
Eve
2026-04-22 12:26:08 +08:00
parent a85403aa77
commit 5584790012
3 changed files with 17 additions and 0 deletions

View File

@@ -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** 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. 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 ### Forbidden behavior
These are violations when used as the closing interaction on Telegram: 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 - saying buttons will be used, but not actually sending them
- sending explanation first, and only later sending buttons after being corrected - 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 ### Required interpretation
@@ -38,6 +51,7 @@ The gate applies to:
- approval requests - approval requests
- next-step choices - next-step choices
- accept / rerun / stop style decisions - accept / rerun / stop style decisions
- pass / fail verdict requests
### Violation standard ### Violation standard

View File

@@ -51,3 +51,4 @@
- 因此已先補一條 skill 規則:`Telegram interaction guard`,禁止 governed long-task flow 在 Telegram 上用純文字選單收尾;若需要選擇,必須改用 inline buttons否則直接執行最合理下一步。 - 因此已先補一條 skill 規則:`Telegram interaction guard`,禁止 governed long-task flow 在 Telegram 上用純文字選單收尾;若需要選擇,必須改用 inline buttons否則直接執行最合理下一步。
- 後續再往前補強到更直接的操作層:新增 `Reply Closure Button Gate` 概念,明確規定只要回覆最後的可執行部分需要總管決定、確認、批准、停止、繼續、重跑或選下一步,就不能只在文字裡說會用按鈕,必須真的送出 inline buttons或直接執行最合理下一步。 - 後續再往前補強到更直接的操作層:新增 `Reply Closure Button Gate` 概念,明確規定只要回覆最後的可執行部分需要總管決定、確認、批准、停止、繼續、重跑或選下一步,就不能只在文字裡說會用按鈕,必須真的送出 inline buttons或直接執行最合理下一步。
- 在最短回歸測試後又確認一個更前面的根因:不只要「有按鈕」,而是**若需要按鈕,必須讓按鈕先出場**,不能先送普通文字再補按鈕;因此已把規則再收緊成 ordering rule優先用 `message` 工具送真按鈕,然後回 `NO_REPLY` - 在最短回歸測試後又確認一個更前面的根因:不只要「有按鈕」,而是**若需要按鈕,必須讓按鈕先出場**,不能先送普通文字再補按鈕;因此已把規則再收緊成 ordering rule優先用 `message` 工具送真按鈕,然後回 `NO_REPLY`
- 在完整 long-task 測試後再驗出更前置的根因:若一開始就可預見最後會進入 owner 的 pass/fail 或 accept/reject 判定,流程本身就必須提早切成 `button-path`,不能等到最後一段才臨時想起要用按鈕。

View File

@@ -177,6 +177,7 @@ When this skill applies:
4. if reporting progress, use the 5-part checkpoint structure 4. if reporting progress, use the 5-part checkpoint structure
5. before claiming progress, check for real evidence 5. before claiming progress, check for real evidence
6. if no evidence and no concrete action, stop the clock 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` - 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 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 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 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 - 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