130 lines
5.0 KiB
Markdown
130 lines
5.0 KiB
Markdown
# Product Adapters
|
|
|
|
Use this reference when the user wants OpenClaw, WorkBuddy, or a related product to install, configure, or run the WeChat Channels publishing workflow.
|
|
|
|
## Adapter Contract
|
|
|
|
Every product adapter must define:
|
|
|
|
| Field | Purpose |
|
|
| --- | --- |
|
|
| `name` | Stable adapter id such as `openclaw`, `workbuddy`, or `playwright`. |
|
|
| `product` | Human product name and version when known. |
|
|
| `docs_url` | Official docs, bundled README, or user-provided package path used as the source of truth. |
|
|
| `install_commands` | Commands copied from current docs or package instructions. |
|
|
| `verify_commands` | Non-destructive checks proving the product is installed and usable. |
|
|
| `run_command` | Command or UI workflow that starts the video publishing task. |
|
|
| `evidence` | Expected screenshots, logs, output files, or status pages after a run. |
|
|
|
|
If a field is unknown, ask for docs/package context or browse official sources before inventing commands.
|
|
|
|
## Installation Flow
|
|
|
|
1. Identify the product, edition, version, operating system, and whether the user wants local, cloud, desktop, CLI, or plugin usage.
|
|
2. Read current official docs or the package's README/install guide. Prefer product-provided instructions over memory.
|
|
3. Check prerequisites without changing the system: Python, Node.js, browser runtime, package manager, account login, license/token, and workspace permissions.
|
|
4. Install only after the user agrees to commands that download packages, modify global state, or open GUI apps.
|
|
5. Run `verify_commands` and capture the important output.
|
|
6. Run a smoke test that does not publish: open 视频号助手, validate config, or fill a draft without final submit.
|
|
7. Record product-specific commands in the user's config or notes so future runs do not rely on chat memory.
|
|
|
|
## OpenClaw Adapter
|
|
|
|
Use `name: "openclaw"` when the user explicitly requests OpenClaw.
|
|
|
|
Expected shape:
|
|
|
|
```json
|
|
{
|
|
"product_adapter": {
|
|
"name": "openclaw",
|
|
"product": "OpenClaw",
|
|
"docs_url": "https://official-docs-or-package-readme",
|
|
"install_commands": [],
|
|
"verify_commands": [],
|
|
"run_command": "",
|
|
"evidence": ["install log", "smoke-test screenshot", "run log"]
|
|
}
|
|
}
|
|
```
|
|
|
|
Map OpenClaw to this workflow by confirming:
|
|
|
|
- How OpenClaw installs skills, plugins, browser automation actions, or task bundles.
|
|
- Where it stores workspace files, browser profiles, cookies, and screenshots.
|
|
- Whether it can call Python scripts directly, import Playwright actions, or needs a wrapper command.
|
|
- How to pass `config.example.json` fields into an OpenClaw task.
|
|
- How to stop before final publish and expose a manual review checkpoint.
|
|
|
|
If OpenClaw cannot provide browser-session persistence, file upload, screenshots, and manual review pauses, use it only for orchestration and keep `scripts/publish.py` as the publishing executor.
|
|
|
|
## WorkBuddy Adapter
|
|
|
|
Use `name: "workbuddy"` when the user explicitly requests WorkBuddy.
|
|
|
|
Expected shape:
|
|
|
|
```json
|
|
{
|
|
"product_adapter": {
|
|
"name": "workbuddy",
|
|
"product": "WorkBuddy",
|
|
"docs_url": "https://official-docs-or-package-readme",
|
|
"install_commands": [],
|
|
"verify_commands": [],
|
|
"run_command": "",
|
|
"evidence": ["install log", "task result", "before-final-action screenshot"]
|
|
}
|
|
}
|
|
```
|
|
|
|
Map WorkBuddy to this workflow by confirming:
|
|
|
|
- Whether WorkBuddy is a desktop app, browser extension, CLI, cloud workflow, or agent runtime.
|
|
- How it imports a skill, script, prompt, or reusable task.
|
|
- How it grants file access to the video, cover, config, and output screenshot directory.
|
|
- How it exposes manual QR login and final publish review.
|
|
- Which command or UI step proves the installation worked.
|
|
|
|
When WorkBuddy is primarily a user-facing app, write product setup steps as operator instructions and keep destructive or account-changing actions behind explicit confirmation.
|
|
|
|
## Generic Browser-Automation Product
|
|
|
|
Use this profile for other products:
|
|
|
|
```json
|
|
{
|
|
"product_adapter": {
|
|
"name": "generic",
|
|
"product": "Product name and version",
|
|
"docs_url": "Official docs or package path",
|
|
"install_commands": [],
|
|
"verify_commands": [],
|
|
"run_command": "",
|
|
"evidence": []
|
|
}
|
|
}
|
|
```
|
|
|
|
Minimum capabilities for direct publishing:
|
|
|
|
- Open a persistent browser session.
|
|
- Upload local files into a web form.
|
|
- Fill text fields and click visible controls.
|
|
- Pause for QR login, CAPTCHA, account selection, and final review.
|
|
- Save screenshots and logs.
|
|
- Return a success/failure signal that can be verified.
|
|
|
|
If a product lacks any minimum capability, use it for setup/orchestration only and run the bundled Playwright script for the actual browser task.
|
|
|
|
## Verification Checklist
|
|
|
|
Before saying a product adapter is ready:
|
|
|
|
- Product source of truth is recorded: official URL, package README, or local docs path.
|
|
- Install command or manual installation steps are recorded.
|
|
- Non-destructive verification command has passed.
|
|
- Video publish config validates.
|
|
- A dry run produced a screenshot before final action.
|
|
- Final publish remains opt-in with `--publish` or an explicit user instruction.
|