reply-end-controls/reports/pluginization-status-report.md

reply-end-controls - Pluginization Status Report

• Date: 2026-05-13
• Status: in progress

Summary

The project has moved beyond a one-off Telegram/OpenClaw PoC and is now in an active pluginization transition.

It is not yet a clean installable plugin package, but it is also no longer just a pile of undocumented runtime edits.

The project now has enough structure to support continued convergence toward a reusable integration path.

What has already been pluginized or partially pluginized

1. Shared configuration source

The project now has a single repo-owned config source:

• config/reply-end-controls.json

This centralizes:

• callback data
• button labels
• resolved button labels
• acknowledgement text
• stop-policy text

Both repo-side runtime helpers and the apply script now read from this source.

2. Reusable core modules

The project already contains reusable logic for:

• state model
• callback normalization
• policy behavior
• file-backed store behavior

These live under:

• src/core/

3. Adapter layer foundations

The project now includes:

• src/adapters/openclaw.ts
• src/adapters/openclaw-state-file.ts
• src/runtime/openclaw-telegram-bridge.ts

This means OpenClaw-specific behavior is no longer entirely trapped inside ad hoc runtime patch descriptions.

4. PoC runtime helper extraction

Telegram PoC behavior has already been captured into reusable helper code:

• default button generation
• resolved button rendering
• acknowledgement reply text
• stop-state inbound text shaping

5. Reproducible patch flow

The project now has:

• scripts/apply-openclaw-poc-patch.sh
• scripts/rollback-openclaw-poc-patch.sh

The apply/rollback flow has been validated against a pristine extracted openclaw@2026.5.7 package.

What is still not pluginized enough

1. Live OpenClaw runtime still uses inline patch behavior

Even though repo-side modules now exist, the live openclawtest runtime still depends on patched OpenClaw distribution files.

That means the behavior is reproducible, but not yet cleanly consumed from the repo at runtime.

2. Telegram callback behavior is still wired through patched runtime code

The callback path has been proven, but it is still implemented as a runtime patch rather than a clean runtime integration seam.

3. Stop policy is still injected as text

The PoC successfully alters later behavior using a stop-state instruction, but the implementation is still based on injected text policy rather than a more explicit first-class runtime policy hook.

4. Acceptance still has manual UI steps

The project has repeatable scripts, but acceptance is still partly human-driven because Telegram UI behavior must be observed directly.

Current maturity assessment

The project is currently at this maturity level:

• more than a PoC patch experiment
• less than a true installable plugin package
• suitable for continued structured development
• suitable for another agent to continue work with clear repo-side ownership points

Recommended next work

Priority 1

Reduce runtime inline logic by replacing more hardcoded patch content with repo-side helper ownership.

Priority 2

Make apply/rollback/verify feel more like a supported integration workflow than an engineering exercise.

Priority 3

Document exactly which remaining runtime behaviors are still inline and what their intended repo-side owners are.

Final judgment

Pluginization is underway and meaningfully advanced, but not complete.

The project has crossed from:

• undocumented patch success

to:

• structured PoC
• reusable repo-side modules
• shared config source
• reproducible patch workflow

The remaining work is real, but it is now focused and understandable rather than exploratory.