5.70 publish

.gitignore

@@ -23,6 +23,7 @@ __pycache__/
 patchright/
 patchright-v*/
 openclaw/
+tests/
 
 # addon crews copied into crews/ at install time — not tracked
 .pnpm-store/

CHANGELOG.md

@@ -1,3 +1,53 @@
+# v5.7.0 (2026-08-31)
+
+### 专家包（Expert Pack）架构
+
+> 解决 `AGENTS.md` 膨胀到 257 行 / 19,094 字符逼近注入上限、平台流程互相干扰、运营风格无法结构化复用的问题。详见 `docs/expert-pack-dna-architecture.md`。
+
+- **改造后形态**：一个 crew = 薄 `AGENTS.md`（通用准则 + 专家包路由表）+ 多套专家包（工作流 + 技能组合 + 知识库 + DNA）+ DNA 库 + 共享的 `SOUL` / `TOOLS` / `IDENTITY` / `USER` / `MEMORY`。同一个 crew 保持一个 workspace、一套记忆、一个人格；专家包只是「工作面」，不是子 crew。
+- **基于 OpenClaw Skill 按需加载**：源码验证 bootstrap 文件每轮全量注入、`bootstrap-extra-files` hook 也是全量注入、祖先链加载不会发现任意子目录——均不适合承载专家包。Skill 机制只注入 `name + description + 路径`，agent 任务匹配时才 read 全文，是原生的按需加载通道。
+- **技能收纳规则**：只被一个领域使用的技能整体迁入对应专家包 `tools/`，从路由面消失；跨领域复用的保持顶层。收纳后技能总数不增反降，路由更准。技术依据：workspace 扫描器发现 `SKILL.md` 后停止深入，包内 `tools/*/SKILL.md` 不会被注册为独立技能。
+- **薄 `AGENTS.md` 职责边界**：只保留通用准则（品牌红线、素材治理）、专家包路由表（任务特征 → 专家包名）、兜底规则。各平台具体流程全部下沉到对应专家包。
+- **专家包内六大 workflow**：`style-dna`（DNA 创建与更新）、`content-production`（内容生产）、`account-setup`（起号与定位）、`account-benchmark`（对标比较）、`editing`（改稿与调整）、`review`（数据复盘）。workflow 每一步必须能落到工具或明确标注为 agent 推理任务，严禁"专家进行 XX"空话。
+- **首个改造对象**：`crews/main`（小贝），已完成 `expert-wx-mp` 专家包。
+
+### DNA（内容风格 DNA）
+
+- **三层产物**：单篇文章 → DNA report（单篇定性提取）→ DNA 文档（聚合同一 DNA 目录下全部 report 的生产规则）→ DNA template（写稿时直接执行的结构化要求）。
+- **存储结构**：运行时保存在平台运营文件夹下，按平台和 DNA ID 分层——`<platform>/dna/<dna-id>/reports/`、`covers/`、`{dna-id}.dna.md`、`{dna-id}.template.md`。`dna/` 与 `calibration/` 由集中目录下沉进各平台运营文件夹。
+- **数据直连 DNA（废除 rubric）**：`pub_*` 表新增 `dna_id` / `account` / `perf_evaluated` 列，作品与 DNA 直接挂钩。评估按量触发（每平台每 DNA 累积 ≥5 条成熟记录），归因走趋势优先（同账号相对值），复盘一律针对 DNA 无单篇复盘。旧 rubric 脚本与 seed 文件已删除。
+- **跨平台 style-profiler 统一规范**：每个平台专家包必须有对应 profiler tool，命令模式（`report` / `build` / `update`）、存储模式、三层产物、权重/focus、用户输入转译、统计边界统一；仅维度定义、分组命名、template 第三项起的分段结构允许平台自定义。
+
+### openclaw 上游同步 v2026.7.1 → v2026.7.1-2
+
+> 7.1 release branch 上的两个补丁发行版（7.1-1 / 7.1-2，均 2026-08-04 发布）。37 个 patch（002 / 007 + 35 个 browser-camoufox-pivot per-file）全部 `git apply --3way --check` 干净通过，无需重新生成。变更集中在 codex / memory-core / state-migrations / plugins / infra，与浏览器转向 patch 无重叠。**未 build**，待次日整体 apply-addon。
+
+- **v2026.7.1-1**（`81ac4f3bdd`）：Codex progress replies 不再中途停 turn（#106961/#108487）；Memory Core 启动期修复 derived sidecar 冲突避免 Gateway fatal restart loop（#107220/#108652）；WSL state permissions 容忍 EROFS（#108250/#108258）；legacy migration residue 改非致命（#106101）；managed plugin 更新修复 stale npm lock（#107294/#107866）。
+- **v2026.7.1-2**（`0790d9f593`）：npm plugin updates 接受 singleton-array metadata（#108336），tracked 官方插件可正常安装/升级。
+- `openclaw.version` → `2026.7.1-2` / `0790d9f593ad30c940ed93b5872a8cf6d6f3cf8c`。`openclaw-weixin.version.json` 无新发行版，不变。
+
+### camoufox-cli fork 跟随上游 0.7.3 + 浏览器二进制升 FF152
+
+> 本轮把 wiseflow fork 的 camoufox-cli 从 `0.6.2-wiseflow.1` 升到 `0.7.3-wiseflow.1`，同步上游 0.7.x 的安装链路修复，浏览器二进制从 FF135 那一代升到 `v152.0.4-beta.28`（Firefox 152 基线，2026-07-19）。FF152 修了 "synthetic mouse input stalling under heavy load"（地址栏换 IP 死机的根因之一）、"humanized mouse trajectory dropped in FF146 migration"、juggler hang 等多个稳定性问题。
+
+- **`patches/camoufox-cli/src/install.ts` 同步上游 0.7.3 三块缺失修复**：
+  - `stableTags()` 函数 + `assetsViaWeb()` 重构（上游 #17）——scrape path 过滤 prerelease tag，不再误拉 beta 版浏览器。
+  - `browserPresent()` + install 后 `launchPath()` 兜底（上游 #17/#19）——"已安装"不只看 version.json，还要检查二进制在磁盘上；broken install 立即报错。
+  - `launchPath` 加入 import，支持上面两处。
+- **`patches/camoufox-cli/package.json` 升级**：
+  - `version`: `0.6.2-wiseflow.1` → `0.7.3-wiseflow.1`
+  - `camoufox-js`: `^0.11.1` → `0.11.2`（pin 死，跟上游 0.7.3 对齐，避免意外升 0.12）
+  - `playwright-core`: 保持 `1.52.0`（camoufox juggler 兼容性需要）
+  - `wiseflowForkBaseline`: `0.6.2` → `0.7.3`
+- **浏览器二进制 `v152.0.4-beta.28`（FF152 基线）**：`camoufox-js@0.11.2` 的 `CamoufoxFetcher` 指向 `daijro/camoufox` 仓库，`fetchLatest()` 跳过 prerelease，拉第一个 stable release。比 fork 之前用的 FF135 那一代新 17 个 Firefox 大版本。
+- **`scripts/update.sh` 加入 camoufox-cli fork rebuild（第 6.5 步）**：
+  - 老用户跑 `update.sh` 时，在 `apply-addons.sh` 之后、`pnpm build` 之前，自动 `bash patches/camoufox-cli/build.sh`（rebuild dist + npm install -g 覆盖旧版）+ `camoufox-cli install`（用新 fork 拉新浏览器二进制）。
+  - 修复之前老用户升级后全局 `camoufox-cli` 还是旧版、浏览器二进制不更新的缺口。
+- **未引入多 tab 架构**：上游 0.7.3 的 `browser.ts` 引入 `TabState` + `tabs` Map + ref-counted close（多 agent 共享浏览器指纹），跟 fork 的单 page + fail-first 队列架构冲突。wiseflow 当前"一个 session 一个 agent"场景不需要多 tab，保留 fork 现状。
+- **保留的 fork 独有功能**：`shortenSession()`（支持 cron 长 session 名）、`recoverOrphanBrowser()`/`killDaemon()`/`termThenKill()`（孤儿浏览器进程树回收）、`--viewport` 参数（weibo/xianyu 二维码登录用）、fail-first 队列、`upload`/`identity` 三件套。
+
+---
+
 # v5.6.5 (2026-08-15)
 
 ### 安装脚本与镜像运行时 bug 修复

README.md

@@ -9,7 +9,7 @@
 - Twitter/X、微博、知乎等平台发文
 - 爆款视频追爆分析、仿写与再创作（支持抖音、B站和小红书视频链接）
 - 已发布作品数据监控与每日定时复盘
-- 内置小红书、抖音、twitter/x、公众号、视频号平台起号方法论
+- 内置小红书、抖音、twitter/x、公众号、视频号平台“专家包”
 - 信息搜集与情报：内置 Smart Search，覆盖小红书、抖音、微博、知乎、B站、Twitter、YouTube、视频号、LinkedIn、Reddit、新闻、政务、财经、学术、购物、GitHub 等 18 类信源——无需配置任何 key、纯免费
 - 指定信源监控与提取
 - 通过社交媒体寻找潜在客户或市场调研
@@ -32,6 +32,19 @@ xiaobei 由Wiseflow (原AI首席情报官）作者 bigbrother666sh 开发。
 
 ---
 
+## 🚀 **v5.7.0 更新**
+
+> Let's do this like an expert.
+
+- **专家包（Expert Pack）——像专家一样干活**：公众号、小红书、抖音、视频号能力升级为“专家包”，起号定位、对标拆解、内容生产、改稿调整、数据复盘六条工作流跑通账号运营全生命周期。你只管把任务丢过来，小贝按专业路数把活办完，不再拿一份越写越厚的通用说明书应付所有平台。
+- **内容风格 DNA——先像人写，再自我进化**：16+维细颗粒度复刻对标账号，统计学聚合做证据底座、定性判断提炼规则，最后落成内容生产 DNA template；发布数据回流后按量触发评估 -> DNA不断自我进化，迎合目标客群口味。
+- **OpenClaw 上游同步 v2026.7.1-2**。
+- **camoufox-cli 升 0.7.3 + 浏览器二进制升 FF152**：同步上游安装链路修复（不再误拉 beta 版浏览器、broken install 立即报错），FF152 解决重负载下鼠标输入卡死等稳定性顽疾。
+
+详见 [CHANGELOG.md](CHANGELOG.md)
+
+---
+
 ## 🚀 **v5.6.3 更新**
 
 - **🎬 Content Producer 正式发布**：我们参考了GitHub上几乎所有热门的视频生产项目，并重点解决了纯AIGC模式容易被平台限流，以及难以融合业务素材的问题。xiaobei系统的content-producer就是你目前能够找到的最适合获客内容制作的开源免费方案！
@@ -42,11 +55,8 @@ xiaobei 由Wiseflow (原AI首席情报官）作者 bigbrother666sh 开发。
   >  - bilibili：https://www.bilibili.com/video/BV1euMR6PEDh
   >  - 开发与使用心得: https://mp.weixin.qq.com/s/zxvWdCMUd0XquWxujvxkSg 
 
-- **🔄 数据闭环彻底打通，为自我进化奠基**：`content-calibrator`（打分+预测）与 `published-track`（数据复盘）机制全面完善，内容产出→发布→数据回流→下一轮策略调优的闭环不再有断点，为后续小贝自主迭代选题与打法提供燃料。现在主力四平台（微信视频号、微信公众号、小红书、抖音）全系支持内容自动生产、自动发布、自动取数、自动复盘
 - **安装脚本大幅优化**：对比 5.6.0，install.sh / install-atomgit.sh / install.ps1 / install-atomgit.ps1 四脚本修了若干实测踩坑——tarball 下载原子写、Windows `.env`/`daemon.env` 换行与 BOM、技能 wrapper 在 Windows 用 `.cmd` shim 替代软链、`OPENCLAW_HOME` 在 `set -u` 下报 unbound、atomgit 国内线路默认跳过 gum spinner bootstrap 避免连 GitHub 超时、Windows 软链需要开发者模式等，产品稳定性显著提高。
-- **全面测试 bug 排除**：对比5.6.0版本，在过去的三个版本里面，我们累计修复了100余个bug，xiaobei系统现在更稳定、更成熟。
 - **wx-mp-hunter 更新**：原微信公众号素材接口方案因官方调整已不可用，我们更新了微信公众号获取方案
-- **底座升级到 OpenClaw v2026.7.1**
 
 详见 [CHANGELOG.md](CHANGELOG.md)
 
@@ -213,13 +223,6 @@ irm https://raw.atomgit.com/wiseflow/xiaobei/raw/master/scripts/install-atomgit.
 
 小贝的背后其实是一支 AI 团队，他们有的为小贝提供运维支撑，有的扩增小贝的能力：
 
-| Crew | 职责 | 关键技能 |
-|------|------|---------|
-| **小贝（main agent）** | AI 搞钱搭子，统筹全局、对接用户、内容选题与发布策略、按需招募/调度其他 crew | 多平台发布（公众号/小红书/视频号/抖音/微博/知乎/Twitter/YouTube）、`viral-chaser` 追爆、`content-calibrator` 打分、`published-track` 复盘、`smart-search` / `lead-hunting` / `intel-gathering` / `market-research` 信息搜集、`rss-reader` 信源监控、投融资与 IR 材料（`pitch-deck` / `investor-*` / `ir-record`）、`swcr-register` 软著、`xianyu-ops` 闲鱼 |
-| **IT 工程师（it-engineer）** | 幕后支撑，被其他 crew spawn 协助 | 系统运维与排障、`openclaw.json` / `daemon.env` / cron 配置、`login-manager` 登录管理、平台绑定、ICP 备案、腾讯云/阿里云 CLI、GitHub/issue 追踪 |
-| **创作者（content-producer）**| 专业内容制作者，承担内容生产线重活 | 视频生产（脚本→素材→TTS→渲染→合成）、网页/落地页/APP 视觉设计... |
-| **销售型客服（sales-cs）** | AI 客服，可绑企业微信，客户可以直接用个人微信添加 | 售前咨询、销售推进、客户画像维护、投诉/售后分流 |
-
 ### AI 团队的自主协作
 
 小贝团队成员之间可以自主完成协作，而无需用户介入，这也是为什么您只需要一个微信入口就可以完整使用所有功能的原因，这意味着：

awada/README.md

@@ -1,7 +1,5 @@
 # awada（client 侧）
 
-> 产品拆分后本仓承担 **wiseflow-client** 角色。awada-server 已整体迁出至 relay 仓 `services/awada-server/`（决策 D4）。本仓仅保留 **awada-extension** 作为 openclaw channel，走 HTTP/WS transport 调 relay 网关（决策 D2），**不再直连 Redis**。
-
 ## 为什么需要 awada？
 
 部分第三方消息服务提供商（企微 bot、个微 bot）要求固定公网 IP 接收 webhook，而 openclaw 多为本地部署。awada 在公网中转消息到本地 openclaw 实例。
@@ -12,9 +10,9 @@
 微信用户
    │  (消息)
    ▼
-WorkTool / QiweAPI ──webhook──► awada-server（relay 仓 services/awada-server/）
+provider service ──webhook──► awada-server
                                       │
-                                   HTTP/WS 网关（OFB_KEY 鉴权）
+                                   HTTP/WS 网关（X-Awada-Key 鉴权）
                                       │
                                       ▼
                             awada-extension（本地 openclaw，本仓）
@@ -28,8 +26,8 @@ WorkTool / QiweAPI ──webhook──► awada-server（relay 仓 services/awad
 **传输契约**：见 `docs/AWADA-CLIENT-TRANSPORT.md`（唯一耦合面）。
 
 - **inbound**（server 写 / bot 读）：bot 通过 `WS /api/v1/awada/inbound?lane=` 拉取，处理完发 `{type:"ack",id}`。
-- **outbound**（bot 写 / server 读）：bot 通过 `POST /api/v1/awada/outbound?lane=` 回执，`meta` 必填 `platform`/`channel_id`/`user_id_external`（从 inbound `event.meta` 原样回传）。
-- **Redis** → relay 内部，**不对客户端暴露**（D2）。客户端只见 `relayBaseUrl` + `ofbKey` + `lane`。
+- **outbound**（bot 写 / server 读）：bot 通过 `POST /api/v1/awada/outbound?lane=` 回执，`meta` 必填 `channel_id`/`user_id_external`（从 inbound `event.meta` 原样回传）；`platform` 回复时回传、主动外呼省略。
+- **Redis** → relay 内部，**不对客户端暴露**（D2）。客户端最少只需配 `awadaKey`。
 
 **核心组件（拆分后归属）：**
 - **awada-server** → relay 仓 `services/awada-server/`。客户端不部署、不持凭据。
@@ -54,27 +52,24 @@ openclaw 配置文件中添加 `channels.awada` 节点：
 {
   "channels": {
     "awada": {
-      "enabled": true,
-      "relayBaseUrl": "https://relay.wiseflow.example.com",
-      "ofbKey": "<OFB_KEY>",
-      "lane": "user",
-      "platform": "worktool:mybot"
+      "awadaKey": "<AWADA_KEY>"
     }
   }
 }
 ```
 
-> **传输改造点**：原 `redisUrl` 字段已作废，替换为 `relayBaseUrl` + `ofbKey`。extension 走 `WS /api/v1/awada/inbound?lane=`（读 inbound + ack）+ `POST /api/v1/awada/outbound?lane=`（写回执），带 `X-OFB-Key` header。Redis 直连模式不再支持。
+> **传输改造点**：原 `redisUrl` 字段已作废，替换为 `relayBaseUrl` + `awadaKey`。extension 走 `WS /api/v1/awada/inbound?lane=`（读 inbound + ack）+ `POST /api/v1/awada/outbound?lane=`（写回执），带 `X-Awada-Key` header。Redis 直连模式不再支持。
+>
+> `awadaKey` 与签名服务用的 `OFB_KEY` 是两份独立凭证，relay admin 分别签发。`lane` 在 relay 侧 provision 时已绑死 platform，客户端不发 `platform`。
 
-**awada-extension 配置项（拆分后）：**
+**awada-extension 配置项：**
 
 | 字段 | 类型 | 默认值 | 说明 |
 |------|------|--------|------|
 | `enabled` | boolean | `true` | 是否启用 |
-| `relayBaseUrl` | string | — | relay 网关端点，**必填**（http/https） |
-| `ofbKey` | string | — | OFB_KEY，**必填**，由 relay admin 签发（含 `awada:lane:<laneId>` scope） |
-| `lane` | string | `"user"` | 订阅的 lane |
-| `platform` | string | — | 平台标识，主动发消息时必填 |
+| `awadaKey` | string | — | awada key，**必填**，由 relay admin 签发（含 `awada:lane:<laneId>` scope），作为 `X-Awada-Key` header 发出 |
+| `relayBaseUrl` | string | `https://relay.openclaw-for-business.com` | relay 网关端点（http/https）；官方域名可不配 |
+| `lane` | string | `""`（server 默认 `User`） | 订阅的 lane，可选；不传时服务器默认使用 `User` lane |
 | `dmPolicy` | string | `"open"` | `open`/`pairing`/`allowlist` |
 | `allowFrom` | string[] | `[]` | `allowlist` 模式下允许的用户 ID |
 | `perMsgMaxLen` | number | — | 单条消息最大字符数，超长自动拆分 |
@@ -85,12 +80,7 @@ openclaw 配置文件中添加 `channels.awada` 节点：
 {
   "channels": {
     "awada": {
-      "enabled": true,
-      "relayBaseUrl": "https://relay.wiseflow.example.com",
-      "ofbKey": "<OFB_KEY>",
-      "lane": "user",
-      "platform": "worktool:mybot",
-      "dmPolicy": "open",
+      "awadaKey": "<AWADA_KEY>",
       "perMsgMaxLen": 500
     }
   },
@@ -110,10 +100,6 @@ openclaw 配置文件中添加 `channels.awada` 节点：
 
 ## 多 Bot / 多实例
 
-- **多 bot**：在 relay 侧 awada-server 配置多个 bot，每个 bot 绑定一个 lane（1:1）。客户端用不同 `ofbKey`/`lane` 订阅。
+- **多 bot**：在 relay 侧 awada-server 配置多个 bot，每个 bot 绑定一个 lane（1:1）。客户端用不同 `awadaKey`/`lane` 订阅（`lane` 可省略，server 默认 `User`）。
 - **多 openclaw 实例**：不同实例订阅不同 lane。
 - 客户端无需感知 Redis db 隔离（relay 内部处理）。
-
-## awada-server 在哪？
-
-`services/awada-server/` 已迁至 relay 仓（`git-server:repos/wiseflow-relay.git`），交接文档见该仓 `docs/HANDOVER.md`。本仓不再包含 server 代码。启用 sales-cs（D10）由 IT engineer 操作改 `enabled: true` + 软链 business_knowledge。

awada/openclaw.plugin.json

@@ -11,9 +11,8 @@
         "properties": {
           "enabled": { "type": "boolean" },
           "relayBaseUrl": { "type": "string" },
-          "ofbKey": { "type": "string" },
+          "awadaKey": { "type": "string" },
           "lane": { "type": "string" },
-          "platform": { "type": "string" },
           "dmPolicy": { "type": "string", "enum": ["open", "pairing", "allowlist"] },
           "allowFrom": { "type": "array", "items": { "type": "string" } },
           "perMsgMaxLen": { "type": "integer", "minimum": 1 },
@@ -37,9 +36,8 @@
     "properties": {
       "enabled": { "type": "boolean" },
       "relayBaseUrl": { "type": "string" },
-      "ofbKey": { "type": "string" },
+      "awadaKey": { "type": "string" },
       "lane": { "type": "string" },
-      "platform": { "type": "string" },
       "dmPolicy": { "type": "string", "enum": ["open", "pairing", "allowlist"] },
       "allowFrom": { "type": "array", "items": { "type": "string" } },
       "perMsgMaxLen": { "type": "integer", "minimum": 1 },