chore(config): 工作流配置、清单与文档同步

workflows/schedules/commands/notification-routing 与 source-manifests 四模块
清单同步登录统一化与新工作流(product.hk_anpei_public_inventory.daily 等)；
docs 运维手册、控制台与耗时分布文档、CI 关键脚本清单、AGENTS 指南更新；
测试与模块注册对齐。

docs/runbook.md

@@ -190,16 +190,38 @@ uv run gyxx schedule run --env-file /etc/gyxx-flow/gyxx-flow.env
 - `tmall-ozko`：商品经营日报 ozko 账号，900 秒；
 - `xiaohongshu-content`：小红书，900 秒；
 - `douyin-content`：抖音内容侧，900 秒；
-- `xingtu`：星图，900 秒；
-- `chanmama`：蝉妈妈，900 秒；
+- `chanmama`：蝉妈妈，900 秒（脚本自带账密登录）；
 - `bilibili-content`：B 站，900 秒。
 
+星图/百应采集（`xingtu_scraper_v2.py`）的登录态挂在 `douyin-shop` 账号下；`xingtu` 账号当前无成员脚本，仅保留 vault。
+
 商品经营日报 `product_commerce:taobao_sycm_collect.py` 会在同一次运行中按品牌路由账号：光影行星使用 `tmall-shop`，ozko 使用 `tmall-ozko`，两边各自使用独立 Profile 和账号 vault。`tmall-ozko` 没有静态成员脚本是有意设计，因为它由这个按品牌拆分的包装工作流动态选择；登录态成功后仍会回写 `state/accounts/tmall-ozko/`，由同一套 keepalive 负责续期。
 
 账号需要在 `config/runtime-bindings.json` 的 `accounts.<account_id>.keepalive` 中显式开启续期，并配置一个不会产生业务副作用的已登录页面 URL。所有账号由唯一的 `gyxx schedule run` 常驻进程在后台维护；每个账号使用独立 CDP 端口、独立 Profile 和账号级 Cookie vault，启动后按 `initial_delay_seconds` 错峰访问，避免同时打开多个登录页面。访问成功且没有跳转到登录页时，Scrapling 才会把最新 Cookie/storage state 原子写回 `state/accounts/<account_id>/`，并同步给成员脚本；不需要另建 Windows 任务计划、cron 或 timer。
 
 Cookie 续期只能延长站点支持滑动续期的会话，不能突破服务端硬过期、主动退出、风控或验证码。keepalive 检测到登录页/无效 Cookie 时会停止发布，不会用失效状态覆盖最后一份有效 vault；此时按 `gyxx accounts list` 检查 `keepalive.status`，必要时重新执行 `gyxx accounts login <account_id>`。
 
+### 工作流执行前的 Cookie 健康网关
+
+每个正式执行（非 dry-run）的工作流在采集步骤前会自动注入"每账号一个"的 `cookie-gate.<account_id>` 关键步骤，由 `src/gyxx_flow/cookie_gate.py` 实现按账号分三级的状态机：
+
+- **blocking**（纯扫码/验证码账号：`douyin-shop`、`xiaohongshu-content`、`douyin-content`、`bilibili-content` 等）：先看 keepalive 近期成功状态（默认 1 小时内视为新鲜，可用 `GYXX_COOKIE_GATE_MAX_STATUS_AGE_SECONDS` 调整），新鲜且 vault 静态有效则直接放行；否则用 keepalive 同款无头浏览器真实探活。探活失败即判定过期：gate 步骤失败，依赖它的采集步骤记 `dependency-failed` 跳过、工作流失败退出，并通过飞书通知登录负责人（`config/notification-routing.json` 中手机号为 `+8613663785145` 的人员，默认 30 分钟节流，可用 `GYXX_LOGIN_ALERT_OPEN_IDS` 覆盖收件人）执行 `uv run gyxx accounts login <account_id>` 完成扫码/验证码重登。
+- **recover**（配置了 `login_command_id` 的账密自动重登账号：`erp-jushuitan`）：过期时先自动跑账密登录恢复，恢复成功放行；失败才阻断并飞书通知。
+- **defer**（成员脚本自带账号密码登录的账号：京东系、天猫系、`chanmama`）：不注入 gate，保持脚本内账密自动登录流程不变。
+
+按账号划分的持久状态在 `state/accounts/<id>/cookie_state.json`（`healthy` ↔ `awaiting_login`）。编排器型工作流（入口脚本本身无账号绑定、由子采集脚本使用账号）在 `config/workflows.json` 的 `required_accounts` 字段声明依赖账号。`--rerun-step`/`--resume-from` 切片和 shadow 运行不发送通知；dry-run 完全不注入 gate。设置 `GYXX_COOKIE_GATE=0` 可临时关闭整网关。
+
+采集脚本不再内嵌扫码/验证码登录：运行中检测到登录态失效会以 `CookieExpiredError` 快速失败并按退出码 75 记为 cookie 跳过；`self_xhs_scraper.py --login-only` 是唯一保留的人工登录引导（该脚本不在任何账号成员内，自管绑定状态）。
+
+### 登录恢复后的自动重跑
+
+gate 阻断工作流时会把待重跑清单（工作流 + 业务日期，shadow/验收运行不记录，同工作流同日期去重，上限 20 条）写进 `state/accounts/<id>/cookie_state.json` 的 `pending_reruns`。常驻调度器（`gyxx schedule run`）的维护循环里挂着 `CookieGateRecoveryManager`：
+
+- 每个心跳检查有待重跑记录的账号：keepalive 近期成功 + vault 静态有效 → 立即视为恢复；否则每 5 分钟做一次真实探活（mode C 账号会自动账密重登，重登成功同样触发恢复）。
+- 恢复确认后，用调度器同款启动器按**原业务日期**自动重跑全部待重跑工作流（日志在 `data/logs/scheduler/`），清空清单并飞书通知"登录态已恢复 + 已自动重跑清单"。
+- 启动失败的任务保留在清单里下一轮重试；同一账号两次重跑启动之间有 5 分钟冷却；控制台手动脚本类临时运行 id（`script.*`）不会自动重跑。
+- 与正常调度并发安全：工作流级锁 + EffectLedger 幂等保证同一天不会重复产生副作用。
+
 项目不会自动搬动或删除已有 `var/`。迁移数据根时应停止调度器，完整备份和复制原目录，修改环境变量后依次运行 doctor、dry-run 和一次指定日期的对账执行。
 
 ## 清理和保留