09-01 调度机制修复落地+并发方案A+全链路复测通过

- 调度根因修复：工作台/api/run 显式写 next_run_at=now+5s（17列），scheduledAt=now+5s 带秒
- 新增 自动化任务调度机制.md（根因/硬规则/状态机/并发上限≈3/排查命令）
- 并发方案A（浏览器锁）：/api/run 对浏览器类任务自动注入锁约束；浏览器搜索抖音账号操作规范.md 新增5.6并发互斥
- 端口 8899→8900 可传参（8899被小米MiPCAudio.exe系统服务占用且杀后复活）
- cdp-test-junxi.mjs 支持 --port 参数
- SKILL.md 工作台段落同步修正（旧认知 scheduled_at=now 已废弃）
- 俊希全流程 TC-01~11 复测全通过（验收表更新）：并行解析6条+AI写脚本会话链路完整跑通

.workbuddy/memory/2026-08-31.md

@@ -471,3 +471,49 @@
 - **三层化沉淀**：治本=浏览器规范.md「提取方法优先级」+「访问账号主页」两节 + SKILL.md 浏览器操作规范红线⑤⑥ + 部署禁用说明登记；失误=新建 `铁律避坑规则/视频列表获取执行避坑.md`（坑1 逐条开视频页/坑2 构造直达地址 + 校验速查表）；记忆=本日志
 - 产出：`俊希/videos_full.json`（136 条全量含 createTime/duration/stats）+ `短视频表格.xlsx` 重生成（发布时间 100%）+ `top6.json`（标准工具出 6 条，2026-06-09~08-15）
 - 浏览器清理：关闭搜索页/redfox 标签页，仅留俊希主页标签页供后续复用
+
+## 远程仓库改名 mcn-short-video + 推送（19:57-20:00）
+- 用户指令「提交到仓库 以本地为准」；前置已把 remote 从 mcnskills.git 改为 mcn-short-video.git（用户澄清「不该文件夹名，只改 git 地址」）
+- **实测**：远程 `mcn-short-video.git` 已存在且可达（fetch/push 成功，SSH 222 连通），历史与本地连续（共同祖先 6cbdb70=原 mcnskills 的 origin/main）→ 即 mcnskills 仓库在服务器端已改名为 mcn-short-video（修正 17:00 旧结论：当时 mcn-video-script.git 不存在、mcnskills.git 存在；现 mcn-short-video.git 存在且历史一致）
+- 提交 ccdd79e（账号分析技能红线强化 + 2 避坑规则 + 记忆文件，7 文件 +131/-6）→ `git push origin main` 成功（6cbdb70..ccdd79e），本地=远程=ccdd79e
+- 用户级 MEMORY.md Git 清单已同步：远程地址 mcnskills.git→mcn-short-video.git，本地路径修正为 mcn-video-script
+- 经验：push 前先 fetch 确认无分叉（本次 fast-forward 领先 2 提交，无需 force）；SSH 需授权模式访问 ~/.ssh（读 Port 222 配置 + 办公室 deploy key）；本地代理先清空再连远程
+
+## mcn-dou-analysis 沉淀同步到 dsh 副本（20:08-20:13）
+- 用户确认「需要」→ 把本次沉淀同步到 dsh 副本 `C:/Users/maidou/.dsh/skills/mcn-dou-analysis/`
+- **同步 6 文件**（cp 源→dsh，diff 验证全空一致）：SKILL.md（红线⑤⑥ + 账号信息数据源红线 + 部署禁用登记）、01_获取账号信息.md（数据来源红线 + 路径中性化）、02_获取视频.md（路径中性化 L15）、浏览器搜索抖音账号操作规范.md（defaultDataList 方法固化 + 访问主页搜索路径）、视频列表获取执行避坑.md + 账号信息获取执行避坑.md（新增）
+- **关键发现**：① mcn-dou-analysis 源与 dsh frontmatter **完全一致**（无 deployment/deployed_at 环境字段，08-27 定主版本时未引入），故 cp 覆盖无需恢复环境字段（区别于 storyboard-prompt）；② 达人账号表路径统一为中性「达人账号表.xlsx」——源已把绝对路径 `D:\dshworkspace\达人账号表.xlsx` 改中性（配合路径配置.md 三环境两步判定：开发机→桌面 MCNSkill项目、dsh→D:\dshworkspace），dsh 的 01/02 文件残留旧绝对路径一并清掉；两个环境的账号表是**不同文件**（桌面 6036B 含俊希 08-31 / D:\dshworkspace 5737B 旧版）
+- **验证**：6 文件 diff 全空；知识库/账号设定/ 13 文件源=dsh 一致（此前 find+for 按空格拆分误报「缺失」，实为文件名含空格）
+- dsh 仓库（dsh_MCNProject）未 commit，按节奏待用户决定
+
+## 俊希测试 TC-07/08 + AI 会话任务链路实测（21:52-22:00）
+- **TC-07 人设卡**：产出 `俊希/俊希账号设定.md`（12 段完整人设卡）。判定=**单一达人型**（俊希+妈妈固定，爸爸/小姨客串）；粉丝281.9w/获赞3658.9w/作品136/广西；5 内容基因 + 8 条内容规则 + 6 条红线 + 广告植入偏好独立小节（金典/海尔/学而思/COLMO，妈妈口播）
+- **TC-08 设定卡 SVG**：`俊希/俊希账号设定卡.svg`（viewBox 0 0 680 1520）。**俊希=温情/亲子/治愈 → 深焦糖深色系** `#2B1A10→#1A0F08`（非旧梦深棕红/非王微斯玫瑰金）；模块=叙事结构(5步)/内容标签(6chip)/内容基因·TOP6(5条)/角色类型库(3角色)/情绪结构(5段)/红线清单(6条)；内部元素沿用深色系固定规范
+- **术语双向对齐**：设定md 补 `### 内容基因·TOP6` 子标题 + section三「类型库/达人设定」→「角色类型库」（对齐旧梦定稿）；「核心标签」字段↔SVG「内容标签」模块=固有映射（与旧梦一致，非改名）
+- **AI 会话任务链路实测（回应用户「为什么没看到创建AI会话任务」两次追问）**：**根因定论**——TC-01~07 全走「本地文件+MCP直调」，只有 TC-10 AI写脚本走 `/api/run` 才创建会话。工作台服务曾挂（8899 有 0.0.0.0 残留监听但 127.0.0.1 无响应），重启后 `POST /api/run` 实测成功：automations 表 4→5 条，新增 `automation-1788184599640`「俊希-AI写脚本(TC-10实测)」（status=ACTIVE/schedule_type=once/scheduled_at=21:56/cwds=D:\AgentSkill\mcn-workshop/model=deepseek-v4-flash）；`/api/run/status` 返回 queued（宿主尚未调度 automation_runs，会话将在左侧会话栏 mcn-workshop 空间出现）
+- 待办：TC-09 AI选题(/api/ai/topics 同步接口，不建会话)、TC-10 脚本实际生成(后台会话)、TC-11 收尾+git
+
+## 视频列表「AI写脚本」链路澄清 + 俊希设定卡配色纠正（22:05-22:55）
+- **视频列表未解析视频的 AI写脚本**：同样走 `confirmRun→executeTask→POST /api/run` 创建会话（data-pages.js:443 每行不分状态都渲染「AI写脚本」按钮，prompt 只带「达人名+视频标题」不带 analysis）。实测未解析视频 511（白昼小熊）触发成功，automations 6 条。工作台视频列表共 56 条/47 条未解析；「未解析」=dsh 库 account_video_source/analysis 表无记录，不阻塞触发。**关键坑**：视频改写 prompt 不注入解析内容，已解析/未解析在 prompt 层面无差异，纯靠标题脑补
+- **俊希设定卡配色纠正（用户质疑"背景色对吗"，确属我误判）**：俊希=明快/欢乐/治愈爽文调性（满级小孩哥宠妈），**非深沉浓郁**。之前机械套「温情/亲子/治愈→深焦糖深色系」是错的（那条对应深沉催泪型亲子）。按 06 文档两系判定（明快/治愈→浅色系）应走**浅色系暖橙**：bg `#F5D0A4→#DE9A5E`，内部元素暖橙系（白卡+#F0CBA0边+#8A4B23深棕字+#E07A3F/#E85A2A橙红强调），情绪核爆段橙红#E85A2A。已重写 SVG（深色残留=0，结构配对完整）
+- **教训**：06 文档配色表「温情/亲子/治愈→深焦糖」只覆盖"深沉催泪"亲子；"明快欢乐"亲子美食账号无现成浅色模板，需按浅色系推导（主色暖橙→提亮降饱和）而非照表硬套。判定先看"明快/深沉"两系大前提，再看表格细分
+
+## 俊希配色定稿 + 调度器根因深查（23:00-23:15）
+- **配色定稿**：浅绿偏太阳黄背景 `#EDF1C0→#D8E28A` + 暖橙内部卡片不变（用户先提「背景浅绿偏一点太阳黄」=小孩嫩绿清新+太阳黄阳光暖意，后澄清「卡片保持之前颜色」=只换背景、内部卡片保持暖橙）。一绿一橙呼应「满级小孩哥给妈妈做饭」属性
+- **三层沉淀「调性优先于赛道标签」**（用户"没有对应配色标准就结合账号属性内容调性思考"）：①治本=06文档①节改三层判定（调性决定色系二选→色值取色相→赛道仅初筛）+配色表亲子治愈加调性分叉+③强规则加「调性优先」；②失误=账号设定执行避坑.md第8条（俊希深焦糖误判）；③记忆=MEMORY.md F6条目。核心=「治愈」双义标签必须回读情绪锚点判定明快vs深沉
+- **AI会话调度器根因（深查，回应用户核心困惑）**：实测两条任务（俊希/白昼小熊）已入 automations 表（status=ACTIVE），但 automation_runtime_state 与 automation_runs **零记录**=宿主从未拾取。字段与 08-27 成功任务逐项一致（once/scheduled_at/rrule/cwds格式/permission_mode/model_id 全同）排除格式问题。**根因=宿主调度器不活跃**：automation_runs 最新记录停在 08-28 09:53（导入指令 last_error=user_cancel），此后零调度。**「写表成功 ≠ 创建会话」，中间还差宿主调度器拾取这一步**；调度器属 WorkBuddy 客户端侧，非工作台代码可控
+
+## 「1任务=1会话」机制确认 + 停摆实锤验证（23:20-23:30）
+- **「1 automation = 1 会话」= WorkBuddy 原生 1:1 映射（确认）**：automation_runtime_state 的 `running_conversation_id` → sessions 表 UUID，4 条历史任务各对应 4 个 `is_background_automation=1`、`status=completed` 的会话。链路=写automation→宿主调度器拾取→建session(后台自动化)→执行completed。**多账号并行 = 写 N 条 automation = N 个后台会话并发**（无需改代码）
+- **停摆实锤（用户"你就同时解析俊希最新6条视频 我看怎么停摆"）**：同时派发 6 条「解析视频」任务（detailId=33022/33021/29596/15729/21514/20164），全部 `POST /api/run` 返回 ok:true，automations 6→12 条；但 6 条全部 `last_run_at=null`、automation_runtime_state 无记录、automation_runs 无记录、后台会话数仍 4。automation_runs 最新仍停在 08-28 09:53:39 未动=值班员（调度器）没上班
+- **隐患（待处理）**：累积 8 条卡住任务（之前俊希/白昼小熊 2 条 + 本次 6 条），一旦客户端调度器恢复会**突然复活**、同时开出 8 个会话执行（可能重复解析/重复写脚本）。恢复前建议清理或预期这 8 条会并发执行
+- **澄清「之前会话怎么建的」（用户"是不是搞错了"质疑，23:31 全字段对比）**：成功任务 vs 卡住任务**逐字段一致**（once/ACTIVE/scheduled_at字符串格式/permission_mode=fullAccess/owner_status=confirmed 全同），唯一差异 last_run_at（成功有值、卡住 null）。**时间线铁证**：工作台链路测试 08-27 19:15:40写入→19:16:40被调度（60秒）；导入指令 08-28 09:53:11→09:54:05（54秒）。**即之前的 4 条会话全是调度器所建、1 分钟内拾取**，机制从未坏过；调度器最后一次活动 08-28 09:54:05 后停摆。**表述教训**：之前反复说「只能写纸条建不了会话」易让用户误以为「会话功能本来就建不出」，应明确「会话能建、建过4次、1分钟建好；现在建不出纯粹是调度器停摆」
+- **POC 记录核对（用户提供 8-27 wb-trigger-poc，23:34）**：用户还原当时 POC=`C:\Users\Administrator\WorkBuddy\2026-08-17-21-42-42\wb-trigger-poc\`（index.html+server.js端口8088+insert_automation.py直写automations表；两链路=①/api/run execFile调CLI同步不进任务栏、②/api/trigger insert_automation.py异步进任务栏），关键字段 schedule_type=once/scheduled_at=now/model_id=deepseek-v4-flash/permission_mode=fullAccess/owner_user_id绑定用户。**核对结论**：①POC文件当前机器找不到（Administrator路径不存在，全盘搜无 insert_automation.py，属另一台机器）；②当前工作台 server.js `/api/run` 已100%复刻POC——INSERT字段（once/scheduledAt=now/model_id='deepseek-v4-flash'/fullAccess/owner_user_id动态查sessions）与POC一字不差；③数据库实查成功vs卡住任务 model_id 全=deepseek-v4-flash、owner_user_id 全=9bb574cb-...701f，**字段零差异**。**最终定论**：写法对、字段对、与POC一致，问题不在代码/字段；POC原文「客户端调度器检测到后即执行」=印证根因是「调度器检测活跃性」（08-27/28检测→执行，08-31未检测→卡住），非工作台可修，需客户端侧恢复
+- **「清空+重建」实测（用户"你不能清空和重启automations吗"，23:39，最终闭环）**：改用官方 `automation_update` 工具（Agent 侧唯一合法入口，规则禁直写 SQLite 动 automations）。①**list** 能看到全部9条任务（8卡住+导入指令）。②**delete** 8条僵尸任务全 success——实为**软删除**（`deleted_at` 打时间戳，行仍在但标记删除，调度器不会再拾取）。③**create** 新建1条验证任务成功——**id 用 UUID 格式**（`337935e0-...`，非工作台的 `automation-<时间戳>`），且 **model_id=`deepseek-v4-pro`**（取当前会话模型，非工作台硬编码的 `deepseek-v4-flash`）。④**等65秒后复查：官方任务 last_run_at 仍 null、automation_runs 无新记录**。**最终铁证闭环**：工作台直写SQLite→卡住、官方automation_update创建→同样卡住，两条路都卡=根因确凿是**调度器（客户端后台轮询服务）停摆**，与「怎么建任务」无关；表（箱子）能写能删，但「捞纸条开会话」的调度循环 08-28 09:54 后未再运行，只能靠重启 WorkBuddy 客户端叫醒。留1条 UUID「验证任务」作金丝雀（调度器一恢复即触发回复「AI会话创建成功」）
+- **重启无效（用户"已经重启了"，23:44，金丝雀验证）**：用户重启 WorkBuddy 客户端后，进程确认存活（WorkBuddy.exe 12 个进程，Electron 多进程架构正常），但金丝雀任务等 3 分钟（23:47 查）仍 `last_run_at=null`、`automation_runs` 无新记录、后台自动化会话数仍 4。**重启未恢复调度器**——说明调度机制非「重启即恢复」那么简单，问题更深层（可能：登录态过期/客户端自动化开关被关/调度依赖云端服务/需在客户端自动化面板手动触发）。金丝雀任务保留作探针；下一步需用户在客户端侧确认自动化任务列表状态或手动触发
+
+## ★调度链路根因确认 + 金丝雀验证成功（23:58-23:59，最终闭环）
+- **最终根因（与另一 WorkBuddy 实例行为差异定位，用户提供对方完整参数后确认）**：`automation_update`（官方工具）create/update **只对未来 scheduledAt 补算 `next_run_at`（毫秒时间戳），过去时间不补算** → 调度器按 next_run_at 扫描找不到 → 任务永远卡住。对方实例 `scheduled_at=now` 时客户端会补算 nextRunAt 并执行；此实例不会 → 客户端版本差异。工作台 `/api/run` 直写 SQLite 同理：scheduled_at=now（已过时刻）→ next_run_at NULL → 调度器扫不到
+- **修复验证（金丝雀 `337935e0-0dc0-47ef-9d6c-eeb6f83bea4f`）**：scheduledAt 从过去时间 23:39 改为**未来时间 23:58:00** → update 返回 `nextRunAt: 1788191880000`（客户端自动补算）→ 23:58:25 `automation_runs` 新增该任务 status=ACCEPTED → `automation_runtime_state` 出现 running_conversation_id → 后台自动化会话 4→**5**，新增「验证自动化调度链路」会话（f4232ef1，is_background_automation=1）→ 执行后 next_run_at 置空
+- **结论**：调度器没停摆，是 next_run_at 补算条件（未来时间）问题；**凡创建/更新任务，scheduledAt 必须设为未来时间（now+），客户端才补算 next_run_at、调度器才扫得到**
+- **遗留**：8 条已软删除僵尸任务（deleted_at 标记，调度器不拾取）无需处理；金丝雀任务已执行完成（once 不重跑），可留作证据或删除