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.

This means reply-end callback values, labels, resolved labels, acknowledgement text, and stop-policy text are no longer duplicated independently across helper code and patch tooling.

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

In addition, callback-resolution behavior is now explicitly represented by a dedicated helper module, rather than being only implicit in runtime patch code.

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.

The live acceptance loop has also shown why observability matters: a pre-answer callback debug write was needed to separate Telegram callback ingress from later acknowledgement failures. That instrumentation is now part of the current PoC patch flow.

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.