reply-end-controls/INTEGRATION.md

INTEGRATION

Current integration model

The current working integration path is:

1. patch OpenClaw Telegram runtime
2. restart the openclawtest gateway
3. send a real Telegram assistant reply
4. verify button rendering, callback handling, and state persistence

Runtime files currently involved

See:

• reports/openclaw-patch-inventory.md

Apply

Current patch apply script:

• scripts/apply-openclaw-poc-patch.sh <openclaw-dist-dir>

Example target dir in openclawtest:

/home/openclawtest/.nvm/versions/node/v22.22.2/lib/node_modules/openclaw/dist

Rollback

Rollback script:

• scripts/rollback-openclaw-poc-patch.sh <openclaw-dist-dir>

This expects backup files created by the apply script.

Verify

At minimum, verify these behaviors in Telegram:

1. assistant replies show both buttons
2. clicking continue updates UI and writes state
3. clicking stop updates UI and writes state
4. later turns are influenced by stop/continue state

Current persisted files in PoC mode

• ~/.openclaw/reply-end-controls.json
• ~/.openclaw/reply-end-debug.log

Current adapter-related repo modules

• src/adapters/openclaw.ts
• src/adapters/openclaw-state-file.ts
• src/adapters/openclaw-message-tool.ts
• src/adapters/openclaw-interactive-handler.ts
• src/adapters/openclaw-plugin-skeleton.ts
• src/runtime/openclaw-telegram-bridge.ts
• src/runtime/openclaw-telegram-poc.ts

These do not yet replace the runtime patch end-to-end, but they are the current repo-side ownership points for the logic.

Current preferred future seam:

• src/adapters/openclaw-plugin-skeleton.ts

This is the clearest current approximation of where a cleaner formal plugin-facing integration path should grow.

Known limitation

The current integration path is reproducible, but not yet clean enough to call a final plugin package.

That is the next direction of work.