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** 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
|
||||
|
||||
|
||||
@@ -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`,不能等到最後一段才臨時想起要用按鈕。
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user