# 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.