docs: add handoff and integration entrypoints / 新增 handoff 與 integration 入口文件
This commit is contained in:
102
reports/agent-consumable-minimum.md
Normal file
102
reports/agent-consumable-minimum.md
Normal file
@@ -0,0 +1,102 @@
|
||||
# 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
|
||||
Reference in New Issue
Block a user