AutoWave Free trial
中文ENVI

Changelog

Release history and feature updates.

v3.48.373

Stable · Latest 10d ago
# v3.48.373

## 修复 detect-bm 表格大面积空白（BM 名 / 验证状态 / 受限 / 所有用户）/ Fix detect-bm Excel going blank (BM name / verification / restriction / users)

**问题 / Problem**
  • •detect-bm 导出的「BM详情」表里，BM 名称、验证状态、受限/申诉状态、所有用户（邮箱+权限+lastActive）等列大面积变空，功能像是「都没用了」。

**根因 / Root cause**
  • •detect-bm 的核心查询（BM 名/验证/死活/成员/主页/广告户）都通过一个共用的网页内 GraphQL 请求拿数据，而这个请求把地址**写死成 `www.facebook.com`**。
  • •但 detect-bm 实际运行时页面停在 `business.facebook.com`。Facebook 现在**拦截了跨子域请求**（business → www 报 `Failed to fetch`），于是所有字段都抓不到 → 表格整片空白。
  • •真机实测确认：同样的请求发到 `www.facebook.com` 失败，发到当前同源地址（`business.facebook.com` / 相对路径）成功返回数据。

**修复 / Fix**
  • •把请求地址改成**相对路径 `/api/graphql/`（同源）**，无论页面在 `www` 还是 `business.facebook.com` 都能正确发送。真机端到端验证：BM 名、验证状态（NOT_VERIFIED）、受限状态、所有用户（含邮箱+权限+lastActive）全部恢复。
  • •附带修两处：①「申诉剩余」列字段名写错（`appealDays` → `appealDaysLeft`），受限 BM 的该列以前一直空；②单 BM 检测模式下「BM 名称」列显示占位符而非真名，现已显示真名。
  • •性能优化：**主页不再逐个查「拥有者/权限」**（这步最慢且易被 FB 限流）。主页只输出 ID/名称/状态列表即可，无需为每个主页单独发请求。广告户的拥有者查询保持不变（旧方式对死户也有效）。需要恢复主页拥有者可设环境变量 `AUTOWAVE_BM_PAGE_OWNER=1`。
  • •完整性修复：**主页/广告户列表现在会翻页拉全**。此前资产查询单次只返回约 20 条且分页游标被 FB 忽略，导致主页/广告户多的 BM 被截断（实测某 BM 101 个主页只列出 10 个）。现改为跟随游标循环拉取直到没有下一页（CDP 实测拿全 101/101 主页）。

---

**English**
  • •detect-bm's "BM Details" sheet went largely blank — BM name, verification status, restriction/appeal status, and the full user list (email + permissions + lastActive) all empty.
  • •Root cause: the shared in-page GraphQL request that fetches all BM info **hardcoded `www.facebook.com`**, but detect-bm runs on `business.facebook.com`. Facebook now CORS-blocks the cross-subdomain request (`Failed to fetch`), so every field came back empty.
  • •Fix: use a **relative same-origin endpoint `/api/graphql/`** — works on both `www` and `business.facebook.com`. Verified end-to-end on a live BM: verification, restriction, and full user list all restored.
  • •Also fixed: the "appeal days left" column field-name bug (`appealDays` → `appealDaysLeft`), and the BM-name column showing a placeholder instead of the real name in single-BM mode.

> 普通修复，非强制更新 / Regular fix — non-force update.

⬇ Download v3.48.373

v3.48.372

11d ago
## AutoWave v3.48.372

  • •Fixed Detect BM deep ad-account checks timing out after 300000ms on large BMs.
  • •Increased the Detect BM workflow step budget to 25 minutes so billing cards, payment history, and consecutive charge checks can finish before the browser is closed.
  • •Fixed "all ad accounts" deep-check coverage so Detect BM keeps the full billing-hub account set instead of stopping at the currently visible 9 rows.
  • •Added guarded reconciliation with BM detail ad-account rows, with overlap checks to avoid mixing internal asset IDs into billing ad-account IDs.
  • •Verified on VM with seq 51440 / BM 1638120844294281: BM resolved ACTIVE, 87 ad accounts were discovered, and 87 unique ad accounts completed card/history deep checks without the old 5-minute timeout.
  • •Stable release. Force-update threshold remains v3.48.193.

⬇ Download v3.48.372

v3.48.371

11d ago
## v3.48.371

  • •Hardened the updater download phase so it writes byte progress and active status while downloading.
  • •Added response-header, total-download, and no-progress stall timeouts to prevent update status from staying on `downloading` forever.
  • •On download failure, the updater now records clearer diagnostics and relaunches the untouched old executable.
  • •Stable release. `force_update_below` remains `v3.48.193`.

⬇ Download v3.48.371

v3.48.370

11d ago
## v3.48.370

  • •Fixed large group/seq dispatch stalls before browser launch.
  • •Slimmed per-profile metadata so `perProfileNurtureParams`, `perProfileOpenPaymentMap`, and `perProfileAdAccounts` only carry the current seq entry instead of duplicating the full map into every profile.
  • •Kept `skipNurtureProfileIds` top-level only during dispatch to avoid repeated payload bloat.
  • •Added `SIDECAR_RPC request_marshaled bytes` diagnostics for `dispatch-batch` requests.
  • •Stable release. `force_update_below` remains `v3.48.193`.

⬇ Download v3.48.370

v3.48.369

11d ago
# AutoWave v3.48.369

  • •修复 BM 广告户深度检测连续扣款漏记：GraphQL payment account 候选链路优先查真实付款账户，GraphQL 历史不足时自动读取 `payment_activity` 页面已渲染交易作为兜底。
  • •detect-bm 深度检测固定查询全部历史，不再受 UI 查询时间范围影响；UI 只保留连续扣款阈值。
  • •广告户 + 主页列表只使用列表已有状态，不再逐个广告户跑 `checkOne`，减少 user-id / people 维度额外查询和限流风险。
  • •保持软更新：强制更新阈值仍为 `v3.48.193`。

⬇ Download v3.48.369

v3.48.368

11d ago
# AutoWave v3.48.368

  • •修复 BM 深度广告户检测中连续扣款漏记：当 GraphQL 交易接口返回历史不完整、最长连续成功扣款低于阈值时，自动读取 `payment_activity` 页面已渲染的交易行作为兜底。
  • •`detect-bm` 逐户历史检测现在会把 BM ID 传入付款活动页 URL，避免读取错误业务资产上下文。
  • •保持软更新：不提高强制更新阈值。

⬇ Download v3.48.368

v3.48.367

11d ago
# AutoWave v3.48.367

  • •修复 BM 深度广告户交易检测使用错误 ID 的问题：先从 BillingHub 广告户列表提取真实 `billingPaymentAccount.id`，再用该 `payment_account_id` 拉绑卡和交易历史。
  • •保留广告户 ID 用于表格展示，交易查询改用账单 payment account，避免截图里同一张卡已有 6 笔 Paid 但系统查错户而漏记。
  • •延续 v3.48.366 的连续扣款修复：成功状态兼容 `PAID` / `SUCCESS` / `SUCCEEDED` / 中文“已支付”，并把最长连续成功扣款笔数透传到 BM 导出 sheet。

本版本为稳定软更新，不强制更新。

⬇ Download v3.48.367

v3.48.366

11d ago
# AutoWave v3.48.366

  • •修复 detect-bm 深度广告户检测没有把“最长连续成功扣款笔数”写入最终结果的问题，连续扣款独立 sheet 现在能读取 BM 深度检测数据。
  • •账单交易状态兼容 `PAID` / `SUCCESS` / `SUCCEEDED` / 中文“已支付”等成功状态，避免只识别 `COMPLETED`。
  • •连续扣款阈值从任务参数透传到检测链路，并在导出重建时从深度检测结果兜底读取。

本版本为稳定软更新，不强制更新。

⬇ Download v3.48.366

v3.48.366

11d ago
# AutoWave v3.48.366

  • •修复 detect-bm 深度广告户检测没有把“最长连续成功扣款笔数”写入最终结果的问题，连续扣款独立 sheet 现在能读取 BM 深度检测数据。
  • •账单交易状态兼容 `PAID` / `SUCCESS` / `SUCCEEDED` / 中文“已支付”等成功状态，避免只识别 `COMPLETED`。
  • •连续扣款阈值从任务参数透传到检测链路，并在导出重建时从深度检测结果兜底读取。

本版本为稳定软更新，不强制更新。

⬇ Download v3.48.366

v3.48.365

11d ago
# v3.48.365

## 多 sidecar 启动卡住修复 / Multi-sidecar startup stall fix

  • •修复多 sidecar 分片派发时,第 0 个 sidecar 卡在 `dispatch-batch` 返回前会阻塞后续 sidecar 的问题。
  • •所有非空 shard 现在独立后台派发,并按启动间隔错峰;单个 sidecar 卡住不会导致整批任务看起来“不启动浏览器”。
  • •保留原有 Stop / runGen 防护和 panic recover,不改变单 sidecar 路径。

---

**English**
  • •Fixed a multi-sidecar dispatch stall where shard #0 could block shards #1..N if its `dispatch-batch` call did not return promptly.
  • •Non-empty shards are now dispatched independently in background goroutines while preserving staggered startup.
  • •Existing Stop / run generation guards and panic recovery are preserved; single-sidecar behavior is unchanged.

> 普通稳定修复,非强制更新 / Stable fix — non-force update. `force_update_below = v3.48.193`.

⬇ Download v3.48.365

v3.48.358

16d ago
# v3.48.358 — 修诊断上传(jsonl/xlsx 绕过冷却)

> 非强制。force_update_below=v3.48.193。

  • •修:.final.jsonl/.xlsx 之前撞 1h 冷却传不上来,现全部正常上传。
含 347–357。

⬇ Download v3.48.358

v3.48.357

16d ago
# v3.48.357 — 白屏/限流时 owner 兜底 Full control

> 非强制。force_update_below=v3.48.193。

  • •服务器页面白屏时页内 GraphQL fetch 失败→owner 查不到。现:查不到 owner 的页/户一律标 Full control(管理员对所有资产全控),保证「都有权限」可见。
含 347–356。

⬇ Download v3.48.357

v3.48.356

16d ago
# v3.48.356 — 主页/广告户 owner 补全

> 非强制。force_update_below=v3.48.193。

  • •FB 限流导致逐个查 owner 大量失败(101只出20多)。现:重试加5次+退避多抢;仍查不到的页用管理员(本号自己,对所有页 Full control)兜底回填,保证不空白。
含 347–355。

⬇ Download v3.48.356

v3.48.355

16d ago
# v3.48.355 — 日志上传锁定测试机

> 非强制。force_update_below=v3.48.193。

  • •诊断日志上传现在硬锁定唯一测试机(machine_id 白名单):该机器自动上传、无需设置;其他机器永不上传。
含 347–354。

⬇ Download v3.48.355

v3.48.354

16d ago
# v3.48.354 — 诊断上传含 .final.jsonl + .xlsx

> 非强制。force_update_below=v3.48.193。

  • •诊断日志上传(测试机开关)现在除 runtime.log 外,还会上传最近一次的 .final.jsonl + .xlsx,方便远程定位表格类问题。
含 347–353。

⬇ Download v3.48.354

v3.48.353

16d ago
# v3.48.353 — 诊断日志上传开关(测试机)

> 非强制。force_update_below=v3.48.193。

  • •设置→维护区新增「上传运行日志(诊断)」开关,默认关。只在测试机开——开后运行日志自动上传,方便远程定位问题。不含账号密码。
  • •含 347–352 全部。

⬇ Download v3.48.353

v3.48.352

16d ago
# v3.48.352 — owner 表列调整

> 非强制。force_update_below=v3.48.193。

  • •删掉「用户名(拥有者)」列(FB 恒不返回)。
  • •「归属(序号)」= 本次检测账号 {seq} (You)。
列:序号|ID|名称|状态|用户ID|归属(序号)|权限。含 347–351。

⬇ Download v3.48.352

v3.48.351

16d ago
# v3.48.351 — BM 拥有者表修复(补全/归属/状态)

> 普通修复版,非强制。force_update_below=v3.48.193。

  • •修复主页/广告户拥有者“id不全”(101个只出17个)——限流导致,现加重试救回。
  • •新增「归属(序号)」列:自己拥有的显示「{seq} (You)」,与用户ID/用户名并列。
  • •状态空值兜底成「活」。
含 347–350 全部。

⬇ Download v3.48.351

v3.48.350

16d ago
# v3.48.350 — BM 主页/广告户「拥有者」分页(真正修好导出)/ Per-BM page & ad-account owner sheets (export fix)

> **普通修复版,非强制 / Regular fix, NOT force-update.** `force_update_below = v3.48.193`(不变)。

## 修了什么 / What

detect-bm 勾选「广告户 + 主页列表」后,导出的 Excel 现在会为**每个 BM** 生成两张独立分页:
  • •**`{BM_ID}主页`**:序号 / 主页ID / 主页名称 / 状态 / 用户ID / **用户名(拥有者)** / **权限**
  • •**`{BM_ID}广告户`**:序号 / 广告户ID / 广告户名称 / 状态 / 用户ID / **用户名(拥有者)** / **权限**

一个主页/广告户有多个拥有者 = 多行。权限 = 完全控制 / 直接管理员 / 部分权限。

After ticking "广告户 + 主页列表" in detect-bm, the export now produces per-BM **{BM_ID}主页** and
**{BM_ID}广告户** sheets with ID / name / status / **owner (user) / permission** columns.

## 为什么之前没有 / Why it was missing

拥有者数据其实一直查到了(后台每个 BM 查到 101 个主页用户),但**自动导出的 Excel 由另一个写入器
生成,那个写入器没有"分页+拥有者"这段逻辑**。本版把它补齐到正确的写入器里。

The owner data was always fetched, but the auto-export Excel is built by a different writer that
lacked the split-sheet logic. This release adds it to the correct writer.

含 v3.48.347–349 全部内容(自动分组 + 引擎版本握手/一键重置引擎 + sidecar 防陈旧)。
Includes everything from v3.48.347–349.

⬇ Download v3.48.350

v3.48.349

16d ago
# v3.48.349 — 引擎版本握手 + 一键重置引擎(根治 stale-sidecar)/ Engine handshake + one-click reset

> **普通修复版,非强制 / Regular fix, NOT force-update.** `force_update_below = v3.48.193`(不变)。

## 解决什么 / What

彻底解决反复出现的「界面更新了,但后台引擎(sidecar,真正干活的部分)还是旧版」—— 导致新功能界面有、实际不生效。
Permanently fixes the recurring "UI updated but the engine (sidecar) is stale" problem.

## 四层根治 / Four-layer root fix

  • •**引擎版本握手**:launcher 启动时核对后台引擎版本是否 = app 版本。/ Launcher verifies engine version == app version on startup.
  • •**界面显示引擎版本**:顶栏版本号旁;引擎是旧版时**变红告警**。/ Engine version shown in the header; turns red on mismatch.
  • •**一键「重置引擎」**:引擎旧了直接点版本号 → 自动清缓存、重载最新引擎(几秒)。**不用删目录、不用重装。**/ Click the version → auto purge + reload latest engine. No folder-delete, no reinstall.
  • •**构建期闸门 + 哈希命名(承 348)**:构建时强制校验引擎已正确嵌入;引擎按内容哈希命名,更新时永不被旧文件锁卡住。/ Build-time embed gate + content-hash filenames (from 348) — engine never gets stuck on a locked old file.

## 给同事 / For testers

更新到本版后,**顶栏会显示引擎版本**:绿色/正常 = 引擎已最新;**变红 = 点一下版本号即可一键刷新引擎**。这样能一眼确认引擎是否真的更新了。
After updating, the header shows the engine version. Red = click the version number to one-click refresh the engine. You can see at a glance whether the engine actually updated.

含 v3.48.347/348 全部功能(自动分组打散参数 + BM 主页/广告户拥有者表)。
Includes everything from v3.48.347/348 (auto-group params + BM page/ad-account owner sheets).

⬇ Download v3.48.349

v3.48.348

16d ago
# v3.48.348 — 根治「更新后引擎(sidecar)不刷新」/ Permanent fix: stale sidecar after update

> **普通修复版,非强制升级 / Regular fix, NOT a force-update.** `force_update_below = v3.48.193`(不变)。

## 问题 / Problem

更新 launcher 后,界面更新了,但**后台引擎(sidecar,承载全部业务逻辑)有时仍是旧版本** —— 导致新功能(自动分组、BM 主页/广告户拥有者表等)明明界面有、实际不生效。此问题反复出现。
After a launcher update the UI refreshes but the **sidecar engine (all business logic) sometimes stays on an OLD version**, so new features silently don't take effect. Recurring.

## 根因 / Root cause

旧逻辑把 sidecar 解压到**固定文件名** `autowave-sidecar.exe`。升级时旧 sidecar 进程常还活着 → Windows **锁住该文件** → 覆盖失败 → launcher 回退继续跑旧引擎。
Fixed-name extraction + Windows file lock (old sidecar process still alive) → overwrite fails → launcher keeps the stale engine.

## 修复 / Fix

按**内容哈希命名**:`autowave-sidecar-<hash>.exe`。新版本 = 新文件名,**永不与被锁的旧文件冲突**;launcher 永远只跑与自身嵌入版本哈希一致的那个引擎。旧文件后台清理,删不掉也不影响。**以后更新不会再卡旧引擎。**
Content-hash filename: `autowave-sidecar-<hash>.exe`. New version = new name → never collides with a locked old file; the launcher always runs the hash-matched engine. Stale files cleaned best-effort. Updates will no longer get stuck on a stale engine.

## 含 / Includes

v3.48.347 的全部内容(自动分组打散参数 + BM 主页/广告户拥有者表 via「广告户+主页列表」开关)。更新到本版后,引擎保证刷新到最新,这些功能即可正常使用。
Everything from v3.48.347 (auto-group anti-clustering + BM page/ad-account owner sheets). After updating, the engine is guaranteed fresh and these features work.

⬇ Download v3.48.348

v3.48.347

17d ago
# v3.48.347 — 自动分组打散参数 / Auto-group anti-clustering nurture params

> **普通功能版,非强制升级 / Regular feature, NOT a force-update.**
> 按 CLAUDE.md 硬规则:`force_update_below = v3.48.193`(维持不变)。仅真 P0"应用根本不能用"才强制。本版是 feature,用户自由选择是否升级。
> Per CLAUDE.md mandate: `force_update_below` stays `v3.48.193`. Only a true P0 "app unusable" may force-update; this is a feature → user's choice.

---

## 为什么 / Why

大规模(5000+ 号)普通养号时,即使每号已有 12 层 per-account 个性派生,**所有号仍共用同一套时间范围**(如搜索都用 1–5 分)。FB 把整批的"搜索停留时长"画直方图 → 一根尖刺 → 批量聚类识别 → 少量号被强制退出登录。
At large scale, all accounts still share ONE set of time-ranges even with 12-layer per-account personality. FB's per-step duration histogram across the fleet spikes → batch-clustering → a slice of accounts gets logged out.

## 做了什么 / What

新增「**自动分组打散参数**」开关(普通养号设置区,分组/序号模式可见)。勾上后:
New toggle **"auto-group anti-clustering params"** in the basic-nurture settings (groups/seqs source). When ON:

  • •本次所有号**每 50 个切一组** / chunk this run's accounts into groups of **50**
  • •每组在**已验证的安全区间内确定性随机**生成一套 6 项时间范围(搜索/群组/Marketplace/Reels/首页静默/直播)/ each group gets a **distinct deterministic-random** set of the 6 ranges within proven safe bounds
  • •**每步硬封顶,不让单号跑太久** —— 实测单号一轮约 **12–25 分钟**(踩满上限的极端值,与已验证稳定的参考档同量级);动作子集默认开再砍约 40% → 典型 14–18 分钟 / every step hard-capped → one pass ~**12–25 min** (extreme = all upper bounds; same magnitude as the proven-stable reference); action-subset default trims ~40% → typical 14–18 min
  • •**组组不同、几万号全池不重复** → 整池打散成几百个行为各异的小队,直方图压平 / distinct per group, no repeat across the whole fleet → histogram flattens
  • •下方 6 个时间参数**自动变灰、由系统接管**(无需手填);会话档位仍可手选 / the 6 range inputs grey out (system-managed); archetype stays manual
  • •**同一个号每次都进同一组、参数稳定**(种子 = 该组首个 seq;符合反风控"同号行为稳定")/ same account always lands in the same group with stable params (seed = group's first seq)
  • •**并发与启动间隔不受影响,仍由用户手动设置** / concurrency + launch-interval untouched (manual)

## 实现 / Implementation

复用现成的 per-seq 参数管道(同 `perProfileOpenPaymentMap`),业务模块零改动:
Reuses the existing per-seq map plumbing (like `perProfileOpenPaymentMap`); zero business-module change:

  • •`frontend/index.html` — 开关 `opt-nurture-autogroup` + 分组数提示
  • •`frontend/public/aw-shim.js` — Start 时生成 `perProfileNurtureParams` map(seq 升序、每 50 一组、mulberry32 确定性 PRNG、JSON 签名去重)+ 灰化/状态/持久化(`localStorage: aw-nurture-autogroup-enabled`)
  • •`app.go` — RunTasks 白名单加 `perProfileNurtureParams`
  • •`sidecar/.../dispatch.ts` — 按 seq 把该组 6 项参数写进每个 task 的 metadata
  • •数据链路:flat metadata keys → `task.runner generateSessionProfile(overrides)` → `sessionProfile` → 模块读取(与 Excel 每行参数同路径)

## 兼容 / Compatibility

  • •不勾 = 完全维持原手动行为 / OFF = unchanged manual behavior
  • •Excel(file)来源不受影响(每行自带 metadata)/ Excel source unaffected (per-row metadata)
  • •groups 来源在拉取(probe)后才能预览分组数;seqs 来源即时预览 / group-count preview needs a successful probe for the groups source; instant for seqs

⬇ Download v3.48.347

v3.48.346

2026-05-26
# v3.48.346 — P0 紧急修复 / P0 emergency fix

## P0 紧急回滚 / P0 emergency rollback

**v3.48.344 与 v3.48.345 均有严重回归** —— 用户实测 v3.48.345 升级后**所有按钮都点不动**（task type radio / 设置 / Stop 全部冻结），应用根本不可用。本版直接回滚到 v3.48.343 的代码基线，已验证 v3.48.343 是最后一个已知可用版本。

按 CLAUDE.md mandate「仅真 P0 紧急修复（应用根本不能用）可设 force-update-below = latest_version」：

  • •受影响版本 / Affected: v3.48.344, v3.48.345
  • •`force_update_below = v3.48.346`（强制升级 v3.48.345 及以下全部用户）

## 回滚内容 / Rollback scope

回滚到 commit `3e2e466` 的 frontend/sidecar/excel-dispatch 状态：

  • •`proof-of-concept/wails/frontend/public/renderer.js` — 撤销 v3.48.344 在 `_syncRunButtons` 加的 banner guard
  • •`proof-of-concept/wails/frontend/public/aw-shim.js` — 撤销 v3.48.344 / v3.48.345 的 day-shuffle IIFE
  • •`proof-of-concept/wails/sidecar/src/handlers/excel-dispatch.ts` — 撤销 v3.48.345 加的 Excel 行 day-shuffle

仅保留版本号 bump（3.48.346）。

## 已知问题 / Known issues

养号"打乱顺序 seq"反集群功能本版**暂时下线**，等找到正确实现方式（且不影响其他任务）再单独发版本。用户原诉求记录在案：
  • •只有养号三类需要 shuffle，其他任务保留原序
  • •seqs / groups / Excel 都要支持养号 shuffle

下版重新引入时会先做小范围 canary 验证再全量推。

## 用户行动 / What users need to do

  • •v3.48.344 / v3.48.345 用户：本版强制升级，重启 AutoWave 即自动拉取
  • •若 v3.48.345 客户端 GUI 已死无法收 update：手动下载
https://commerce.autowave.dev/releases/v3.48.346/AutoWave.exe
覆盖原文件后重启

## 验证 / Verification

  • •主项目 `npx tsc --noEmit` 通过
  • •代码状态与 v3.48.343（commit 3e2e466）frontend/sidecar 一致

⬇ Download v3.48.346

v3.48.345

2026-05-26
# v3.48.345 — Hotfix: shuffle 仅养号 + Start 按钮回退

## 紧急回归修复 / Regression fix

v3.48.344 引入的两处改动误伤其他任务类型，本版回归修复。**不属于 P0 紧急**（用户可继续用 v3.48.343 或 v3.48.344 但 Start 按钮被 banner 钉死的情况），按规则非强制升级，`force_update_below = v3.48.193`。

> 用户硬性 mandate（2026-05-26）：
> "所有功能只能用 seq 了… 只有养号打乱顺序 seq，其他的功能别打乱… 检测 BM 点不起开始了"

---

## 修复 1 / Fix 1：shuffle 限定到养号三类（其他任务保留原序）

### 问题 / Problem

v3.48.344 对**所有 task type** 的 `payloadObj.seqs` / `payloadObj.groups` 做 day-shuffle。但只有养号（nurture-basic / nurture-live / nurture-full）从 shuffle 中受益；其他顺序敏感任务（detect-bm / BM 拉户 / 邀请 / 分配 / 广告户 / boost-post 等）被波及，业务逻辑错乱。

### 改动 / Fix

  • •`aw-shim.js` `_dayShuffleApply` 在 IIFE 顶部读 `_taskType`，仅当任务为 `nurture-basic` / `nurture-live` / `nurture-full`（含旧别名 `basic-nurture` / `live-nurture` / `full-nurture`）时才洗牌；其他任务 log `skipped (taskType=… is not nurture-*)` 后直接 return。
  • •分组 (`groups`) 与 seq textarea (`seqs`) 都在 nurture-* 内继续打乱（一个 group 含多 seq，用户硬性要求）。
  • •**新增**：养号 Excel 表格行序也支持 shuffle —— `proof-of-concept/wails/sidecar/src/handlers/excel-dispatch.ts` 在 `result.tasks.map(...)` 之前按 `params.taskType` 是 nurture-* + UTC day-epoch seed 做 Fisher-Yates 行级 shuffle。同一 UTC 天内重复 Start 得到相同顺序（idempotent），跨天得到独立排列；同样用 Mulberry32 PRNG，跟前端 seqs/groups 路径行为一致。
  • •log：`[excel-dispatch] day-shuffle taskType=nurture-basic count=N seed=S before5=… after5=…`

### 用户可见行为 / User-visible behavior

| 任务类型 / Task type | seqs textarea | 分组 / Groups | Excel 表格 |
|---|---|---|---|
| nurture-basic / nurture-live / nurture-full | ✅ 按 UTC day-epoch 洗 | ✅ 洗 | ✅ 洗（v3.48.345 新增）|
| 其他 19 种任务（detect-bm / 拉户 / 邀请 / 分配 / 广告户 / boost-post 等）| ❌ 保留原序 | ❌ 保留原序 | ❌ 保留原序 |

---

## 修复 2 / Fix 2：Start 按钮回退 banner guard（普通升级提示不再禁用"开始"）

### 问题 / Problem

v3.48.344 `_syncRunButtons` 把 `updateBanner.hidden === false` 也算"禁用 Start 的条件"，每天发布 release 后，所有任务类型的"开始"按钮都被升级横幅钉死显示"⚠ 请先升级"，用户反馈"检测 BM 点不起开始"。

### 改动 / Fix

`renderer.js` 删除 v3.48.344 在 idle 分支新增的 `_updatePending` 块。普通升级 banner 不再禁用 Start；`forceUpdateActive` 强制更新自带 modal 拦 click，本来就有保护，不需要此层重复 guard。`onUpdateAvailable` / `btnUpdateLater` 里 v3.48.344 加的 `_syncRunButtons()` 调用保留（无副作用，幂等）。

---

## 验证 / Verification

  • •主项目 `npx tsc --noEmit` 通过
  • •sidecar `npx tsc --noEmit` 通过
  • •检测 BM / BM 拉户 / 邀请 / 广告户检测等顺序敏感任务现在正确保留 seqs/groups/Excel 行序
  • •养号三类继续按 day-epoch shuffle，分组与 Excel 也覆盖
  • •用户切回 v3.48.345 后，无论是否有 update banner，所有 task type 的 Start 按钮都正常可点

---

## 升级建议 / Upgrade guidance

  • •跑非养号任务（检测 BM / 拉户 / 邀请 / 分配 / 广告户 / boost-post 等）的用户：建议升级，恢复正常顺序与 Start 按钮可点
  • •跑养号任务但用了 Excel 表格的用户：升级后表格行也会自动 day-shuffle（养号专属）
  • •非强制升级（`force_update_below = v3.48.193`），用户可自行选择时机

⬇ Download v3.48.345