chore: auto release commit (2026-07-14 11:56:45)
All checks were successful
技能自动化发布 / release (push) Successful in 5s
All checks were successful
技能自动化发布 / release (push) Successful in 5s
This commit is contained in:
@@ -454,33 +454,41 @@ metadata:
|
||||
也就是说,`cli/app.py` 的职责是:
|
||||
|
||||
1. 打印帮助
|
||||
2. 定义 `run / logs / log-get / health / version`
|
||||
3. 把参数转交给 `service.task_service`
|
||||
2. 定义 `run / logs / log-get / health / version`(及业务子命令)
|
||||
3. 把参数转交给 `service.task_service`(或薄适配后再进 domain service)
|
||||
|
||||
不要在 `cli/app.py` 里直接写:
|
||||
|
||||
- 浏览器自动化
|
||||
- 子进程调用兄弟技能
|
||||
- SQLite 逻辑
|
||||
- 与 toolbar / cron / agent 来源相关的业务分叉
|
||||
|
||||
## 10. `service` 层怎么写
|
||||
|
||||
`service` 是核心层。
|
||||
`service` 是核心层。推荐拆分(**单业务内核、多入口**):
|
||||
|
||||
通常可以这样拆:
|
||||
```text
|
||||
cli/app.py → 只解析参数
|
||||
service/task_service.py → job_context / emit / checkpoint / finish / 错误转换
|
||||
service/<domain>_service.py → 唯一业务内核(同步、处理、统计等)
|
||||
db/*_repository.py → 事务与读写
|
||||
assets/actions.json → placements / bind / executionProfile / entrypoint
|
||||
```
|
||||
|
||||
- `task_service.py`
|
||||
放命令编排、参数兜底、结果分流(例如 `cmd_run`)
|
||||
通常还可以有:
|
||||
|
||||
- `sibling_bridge.py`
|
||||
放通用兄弟技能子进程工具(`call_sibling_json`);**具体调用哪个 slug 由业务在 `task_service.py` 决定**,不要在本文件硬编码发布类专用 helper
|
||||
放通用兄弟技能子进程工具(`call_sibling_json`);**具体调用哪个 slug 由业务在 `task_service.py` 或 domain service 决定**,不要在本文件硬编码发布类专用 helper
|
||||
|
||||
- `xxx_playwright.py`(按需新建)
|
||||
浏览器后台自动化 **不在模板默认结构中**;若确有需要,按命名约定自建模块并在 `task_service.py` 引用
|
||||
浏览器后台自动化 **不在模板默认结构中**;若确有需要,按命名约定自建模块并由 domain / task_service 引用
|
||||
|
||||
- `entitlement_service.py`
|
||||
放鉴权逻辑
|
||||
|
||||
禁止:toolbar / cron / Agent / CLI 各自复制一套采集或同步实现;为兼容旧命令再写第二套内核。
|
||||
|
||||
### 日志要求(`cmd_run` / 核心业务)
|
||||
|
||||
`service` 层是**关键业务日志**的落点,须遵循 [`LOGGING.md`](LOGGING.md):
|
||||
@@ -497,7 +505,9 @@ metadata:
|
||||
|
||||
推荐流向是:
|
||||
|
||||
`cli.app` -> `service.task_service` -> `service.sibling_bridge` / (可选)`service.xxx_playwright` -> `db`
|
||||
`cli.app` -> `service.task_service` -> `service.<domain>_service` -> `db`
|
||||
|
||||
(旁路:`sibling_bridge` / 可选 `xxx_playwright` 仅由 service 调用)
|
||||
|
||||
## 11. `db` 层怎么写
|
||||
|
||||
@@ -525,13 +535,14 @@ metadata:
|
||||
|
||||
若技能需要出现在宿主**数据管理按钮**、**技能详情**、**定时任务**或 **Agent 直接调用**中,提供 `assets/actions.json`。
|
||||
|
||||
- **运行时金标准**见 [`SKILL_ACTION_RUNTIME.md`](SKILL_ACTION_RUNTIME.md)(sync/async、任务中心、Agent 禁令)
|
||||
- 字段契约见 [`references/ACTIONS.md`](../references/ACTIONS.md)
|
||||
- **运行时金标准**见 [`SKILL_ACTION_RUNTIME.md`](SKILL_ACTION_RUNTIME.md)
|
||||
- 字段契约见 [`references/ACTIONS.md`](../references/ACTIONS.md)(`placements` / `bind.tables` / `executionProfile` 正交)
|
||||
- JSON Schema 见 [`assets/schemas/skill-actions.schema.json`](../assets/schemas/skill-actions.schema.json)
|
||||
- 模板最小示例仅暴露 `health` / `version` / `config-path`(均显式 `executionProfile: "sync"`)
|
||||
- 模板最小示例仅暴露 `health` / `version` / `config-path`(均显式 `executionProfile: "sync"`;**不**自动加 toolbar)
|
||||
- 含 `toolbar` 的 Action:**必须**声明合法 `bind.tables`(`POLICY-SKILL-ACTION-003`)
|
||||
- 含浏览器 RPA / 长耗时的业务技能:**必须**增加至少一条 `"executionProfile": "async"` 且 `placements` 含 `agent` 的 action(`POLICY-SKILL-ACTION-001`)
|
||||
- 没有宿主直接操作需求时,**可以删除** `actions.json`;删除后勿保留失效引用
|
||||
- 复制为新技能后,scaffold 会自动将 `your-skill-slug` 与 `your_skill_slug` 替换为新 slug(后者用于 `LOG_LOGGER_NAME` 等下划线形式);action 业务命令由技能作者自行调整
|
||||
- scaffold **不会**移除 Schema 中的 `bind` 支持,**不会**生成平台业务 Action 或业务表名;仅替换占位 slug
|
||||
|
||||
宿主执行方式:
|
||||
|
||||
@@ -543,22 +554,31 @@ CLI 必须提供稳定退出码、结构化成功输出,以及 `ERROR:<CODE>:`
|
||||
|
||||
### 编排范式:单内核 + 多入口
|
||||
|
||||
长任务 / RPA 技能推荐拆分(勿把 `job_context` 塞进纯业务内核):
|
||||
长任务 / RPA / 数据同步技能推荐拆分(勿把 `job_context` 塞进纯业务内核):
|
||||
|
||||
```text
|
||||
<domain>_service.sync_*(...) # 唯一业务内核:读外源 → 写本地库(或核心处理)
|
||||
cmd_sync_* (...) # 编排:job_context + 调用内核 + emit/finish(async 时)
|
||||
CLI / Action / cron / Agent # 全部进入同一 cmd_* → 同一内核
|
||||
```
|
||||
|
||||
RPA 批量亦可:
|
||||
|
||||
```text
|
||||
execute_single_<biz>(...) # 鉴权 + 业务 + task_log;无 job_context
|
||||
cmd_run(...) # 单条:job_context + execute_single + finish
|
||||
cmd_run_pick(N, ...) # 批量顺序:job_context + for-loop + emit(progress) + finish(partial|success|failed)
|
||||
cmd_run_pick(N, ...) # 批量顺序:job_context + for-loop + emit(progress) + finish
|
||||
cmd_stats() # 只读 sync:JSON,无 job_context
|
||||
```
|
||||
|
||||
- 批量数量用 **`pickCount` / `--pick N` 参数**(任意正整数),不写死条数。
|
||||
- **顺序执行、不并发**同一浏览器 Profile / account lease。
|
||||
- 详情见 [`SKILL_ACTION_RUNTIME.md`](SKILL_ACTION_RUNTIME.md) §5–§6。
|
||||
- **同步数据**与**宿主表导出**职责分离:同步不写 CSV/Excel;表导出交给数据管理。
|
||||
- 详情见 [`SKILL_ACTION_RUNTIME.md`](SKILL_ACTION_RUNTIME.md);契约样例见 `tests/samples/test_sync_contract.py.sample`、`tests/samples/test_action_core_contract.py.sample`。
|
||||
|
||||
### 队列 + pick(可选)
|
||||
|
||||
有「待处理列表」时:队列表 `pending → processing → success/failed`;数据管理录入或 `import-*` 入库;`run --pick N` 消费;失败用 `reset` 回 `pending`(不自动重试)。Manifest 上配置 `*-run-pick`(async,toolbar/cron/agent)。
|
||||
有「待处理列表」时:队列表 `pending → processing → success/failed`;数据管理录入或 `import-*` 入库;`run --pick N` 消费;失败用 `reset` 回 `pending`(不自动重试)。Manifest 上配置 `*-run-pick`(常见为 async + toolbar/cron/agent;有 toolbar 则须 `bind.tables`)。
|
||||
|
||||
## 12. 如何接兄弟技能
|
||||
|
||||
|
||||
Reference in New Issue
Block a user