103 lines
2.5 KiB
Markdown
103 lines
2.5 KiB
Markdown
# Agent-Consumable Minimum
|
|
|
|
## Purpose
|
|
|
|
Define the minimum bar for saying `reply-end-controls` is ready for another AI agent to use directly, rather than merely continue developing.
|
|
|
|
## Current state
|
|
|
|
The project is already:
|
|
|
|
- understandable by another agent
|
|
- reproducible as a Telegram/OpenClaw PoC
|
|
- documented well enough for engineering handoff
|
|
|
|
But it is not yet at the point where another agent can simply adopt it as a clean integration without understanding the current patch model.
|
|
|
|
## Minimum bar for direct consumption
|
|
|
|
Another AI agent should be able to:
|
|
|
|
1. understand what the feature does
|
|
2. understand what environment it targets
|
|
3. apply it without hand-editing runtime files
|
|
4. verify it works
|
|
5. roll it back if needed
|
|
|
|
## Required deliverables
|
|
|
|
### 1. Clear integration entrypoint
|
|
|
|
There must be a single obvious entrypoint explaining:
|
|
|
|
- what to install
|
|
- what to patch
|
|
- what scripts to run
|
|
- what runtime assumptions exist
|
|
|
|
### 2. Apply path
|
|
|
|
Another agent must be able to apply the current PoC without inventing its own patch process.
|
|
|
|
Current direction:
|
|
|
|
- `scripts/apply-openclaw-poc-patch.sh`
|
|
|
|
### 3. Verify path
|
|
|
|
Another agent must be able to verify:
|
|
|
|
- buttons appear
|
|
- callback is received
|
|
- state is written
|
|
- stop/continue affect later behavior
|
|
|
|
Current direction:
|
|
|
|
- acceptance instructions
|
|
- PoC reports
|
|
|
|
### 4. Rollback path
|
|
|
|
Another agent must be able to revert the patch safely.
|
|
|
|
Current direction:
|
|
|
|
- `scripts/rollback-openclaw-poc-patch.sh`
|
|
|
|
### 5. Integration contract
|
|
|
|
Another agent should not need to reverse-engineer the feature from raw runtime patches.
|
|
|
|
It should have direct access to:
|
|
|
|
- state model
|
|
- callback contract
|
|
- Telegram rendering rules
|
|
- OpenClaw adapter assumptions
|
|
|
|
## Missing pieces before this bar is truly met
|
|
|
|
The main gaps are:
|
|
|
|
- no single `HANDOFF.md` or `INTEGRATION.md` entrypoint yet
|
|
- the current implementation still relies on runtime patching rather than a clean installable integration unit
|
|
- acceptance is still partly human-driven instead of fully scripted
|
|
|
|
## Recommended next tasks
|
|
|
|
1. add `HANDOFF.md`
|
|
2. add `INTEGRATION.md`
|
|
3. add a user-facing apply/verify/rollback flow description
|
|
4. tighten the acceptance steps into a smaller repeatable checklist
|
|
|
|
## Completion rule
|
|
|
|
We can say the project is ready for another agent to directly use when:
|
|
|
|
- the repo contains a single handoff entrypoint
|
|
- patch application is reproducible
|
|
- patch rollback is reproducible
|
|
- verification steps are explicit and bounded
|
|
- the other agent does not need to inspect OpenClaw runtime internals before getting started
|