reply-end-controls/reports/telegram-openclaw-poc-success.md

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.