Add early button-path routing for Telegram decision flows
This commit is contained in:
@@ -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
|
||||||
|
|
||||||
|
|||||||
@@ -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`,不能等到最後一段才臨時想起要用按鈕。
|
||||||
|
|||||||
@@ -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
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user