# reply-end-controls - Telegram + OpenClaw PoC Success Report

- Date: 2026-05-13
- Scope: Telegram-only PoC in `openclawtest`
- Status: PoC successful

## Executive summary

The Telegram + OpenClaw PoC is successful.

The project has now proven the full core path from reply decoration to callback-triggered state persistence and visible behavior influence.

This does **not** mean the feature is production-complete. It means the main V1 proof-of-concept chain is real and working on a live Telegram bot.

## What was proven

### 1. Assistant replies can show reply-end buttons

Telegram assistant replies successfully displayed two inline buttons:

- `A. 繼續`
- `B. 就這樣吧，不需要額外處理`

This proves that the Telegram outbound reply chain can be decorated with reply-end controls.

### 2. Callback clicks can be received

The callback flow was debugged and proven through:

- visible button click effects
- explicit callback acknowledgement replies
- callback-specific debug logging

This proves that Telegram callback queries are being received and handled by the patched OpenClaw Telegram runtime.

### 3. Callback state can be persisted

After clicking a reply-end button, a state file was successfully written:

- `~/.openclaw/reply-end-controls.json`

Observed stored fields included:

- `lastChoice`
- `lastChoiceAt`
- `sourceMessageId`
- `sourceCallbackId`
- `active`

This proves that button selection is not just a UI event; it becomes durable runtime state.

### 4. Callback flow can update Telegram UI

When the `continue` button was clicked, the Telegram UI updated and showed the selected state, confirming that callback handling can mutate the original inline keyboard state.

### 5. Callback flow can send visible acknowledgement replies

The patched handler successfully emitted visible confirmation replies such as:

- `reply-end-controls: continue received`
- `reply-end-controls: stop received`

This provides a strong human-visible proof that callback handling executed.

### 6. Stored stop state can influence the next assistant turn

After `stop` was selected, a later inbound message was processed with a stop-state instruction injected before the assistant run.

Observed outcome:

- the assistant still replied,
- but it became materially more restrained,
- and it stopped producing the earlier style of long proactive extension / checklist expansion.

This proves the state is not merely recorded; it can influence later assistant behavior.

## What exactly succeeded end-to-end

The following chain is now real and working:

1. assistant reply generated
2. Telegram reply-end buttons attached
3. user clicks `continue` or `stop`
4. callback query reaches OpenClaw Telegram runtime
5. callback state is persisted
6. UI/acknowledgement response can be generated
7. later assistant behavior can read that state and change tone/continuation behavior

## Limits of the current PoC

The PoC is successful, but not finished as a product feature.

### 1. Stop behavior is only partially hardened

The `stop` choice clearly influences behavior, but the assistant can still continue in a softened internal way instead of fully hard-stopping.

Current result:

- the assistant becomes more restrained
- but may still continue some internal follow-up rather than ending absolutely

### 2. The implementation currently uses local patches inside the `openclawtest` runtime

The PoC proves feasibility, but some of the changes are currently local runtime patches rather than a clean packaged integration path.

### 3. Only Telegram is in scope

This project is intentionally Telegram-only right now.

### 4. The callback/state path needs productization

The PoC shows the path works. It still needs to be cleaned into a maintainable, reusable plugin/integration structure.

## Recommended next step

The most sensible next step after this PoC is:

- turn the Telegram PoC patch set into a cleaner implementation boundary
- reduce direct runtime patching
- harden the `stop` policy so it more strongly suppresses proactive continuation

## Final judgment

The Telegram + OpenClaw PoC should be considered successful.

It has crossed the threshold from design-only work into a real, user-visible, callback-capable interaction control path.