136 lines
4.0 KiB
Markdown
136 lines
4.0 KiB
Markdown
# 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.
|
|
|
|
## 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.
|