首次提交代码

This commit is contained in:
zhijun song
2026-07-09 13:55:56 +08:00
commit b3b1593efa
6 changed files with 855 additions and 0 deletions

View File

@@ -0,0 +1,40 @@
{
"video_path": "C:/path/to/video.mp4",
"title": "视频标题示例",
"description": "视频正文或简介。可以包含换行。",
"topics": ["视频号", "自动发布"],
"cover_path": "C:/path/to/cover.jpg",
"publish_at": null,
"visibility": "public",
"product_adapter": {
"name": "playwright",
"product": "built-in",
"docs_url": "",
"install_commands": [
"python -m pip install -r requirements.txt",
"python -m playwright install chromium"
],
"verify_commands": ["python -c \"import playwright; print('playwright ok')\""],
"run_command": "python scripts/publish.py --config path/to/config.json --headed",
"evidence": ["before-final-action screenshot", "run log"],
"notes": "Use name=openclaw or name=workbuddy when the user wants a specific product adapter."
},
"browser": {
"storage_state": ".auth/wechat_channels_state.json",
"headless": false,
"slow_mo_ms": 100,
"timeout_ms": 60000,
"review_seconds": 0
},
"selectors": {
"create_url": "https://channels.weixin.qq.com/platform/post/create",
"video_input": "input[type='file']",
"cover_input": "",
"title": "",
"description": "",
"save_draft_button": "",
"publish_button": "",
"schedule_button": "",
"schedule_input": ""
}
}

View File

@@ -0,0 +1,129 @@
# 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.