119 lines
3.1 KiB
Markdown
119 lines
3.1 KiB
Markdown
# reply-end-controls
|
|
|
|
Reply end controls for chat responses.
|
|
|
|
## Goal
|
|
|
|
At the end of each assistant reply, attach explicit user controls so the user can quickly choose whether the conversation should continue or stop cleanly.
|
|
|
|
The initial product goal is a two-button ending control:
|
|
|
|
- `A. 繼續`
|
|
- `B. 就這樣吧，不需要額外處理`
|
|
|
|
The system should capture the user's button selection and feed it back into the assistant/runtime so future behavior can adapt accordingly.
|
|
|
|
If the user has a new request instead of choosing a button, they should still be able to type normally without any extra workflow.
|
|
|
|
## Scope
|
|
|
|
This is a separate project from the OpenClaw governance interceptor work.
|
|
|
|
This repo is for the interaction-control feature only:
|
|
|
|
- rendering reply-end controls
|
|
- receiving button callbacks
|
|
- mapping user choice into conversation state
|
|
- preserving the ability to type freely instead of pressing a button
|
|
|
|
## Phase 1 target
|
|
|
|
Build the first working version for **Telegram**.
|
|
|
|
Telegram is the first target because it already supports inline buttons and callback payloads, which makes it the easiest place to validate the interaction model.
|
|
|
|
## Expected behavior
|
|
|
|
### At the end of every assistant reply
|
|
|
|
The system appends two visible controls:
|
|
|
|
- Continue
|
|
- Stop here
|
|
|
|
### If the user taps Continue
|
|
|
|
The runtime records that the user wants to keep going.
|
|
|
|
Possible future uses:
|
|
|
|
- allow follow-up prompting
|
|
- keep short-term task context active
|
|
- suppress premature closure behavior
|
|
|
|
### If the user taps Stop here
|
|
|
|
The runtime records that the user does not want additional handling.
|
|
|
|
Possible future uses:
|
|
|
|
- avoid unnecessary follow-up suggestions
|
|
- mark the reply as closed
|
|
- reduce proactive continuation behavior
|
|
|
|
### If the user types a new message instead
|
|
|
|
The typed message takes priority.
|
|
|
|
The user must not be forced to press a button before continuing the conversation.
|
|
|
|
## Non-goals
|
|
|
|
For the initial version, this project does **not** try to:
|
|
|
|
- redesign the full chat UI
|
|
- replace all reply delivery logic
|
|
- solve governance / claim verification
|
|
- support every chat platform at once
|
|
|
|
## Initial implementation direction
|
|
|
|
Phase 1 will likely need these parts:
|
|
|
|
1. **Reply payload augmentation**
|
|
- append Telegram inline buttons to assistant replies
|
|
|
|
2. **Callback handling**
|
|
- receive button presses from Telegram
|
|
- map callback data into internal conversation state
|
|
|
|
3. **Conversation state storage**
|
|
- remember the most recent reply-end choice for a session or conversation
|
|
|
|
4. **Policy hook**
|
|
- let the assistant/runtime inspect whether the user chose Continue or Stop here
|
|
|
|
## Suggested milestones
|
|
|
|
### Milestone 1
|
|
|
|
- Telegram proof of concept
|
|
- one reply can render the two buttons
|
|
- one button click can be received and logged
|
|
|
|
### Milestone 2
|
|
|
|
- map button clicks into session state
|
|
- confirm typed follow-up still works without pressing a button
|
|
|
|
### Milestone 3
|
|
|
|
- apply button state to runtime behavior
|
|
- define exactly how Continue / Stop here influences future turns
|
|
|
|
## Current status
|
|
|
|
- Repository created
|
|
- Initial README expanded
|
|
- Technical design and implementation not yet started
|