Nhật ký cập nhật

Lịch sử phát hành và cập nhật tính năng.

v3.48.373

Stable · Mới nhất 10 ngày trước

# 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.

⬇ Tải v3.48.373

v3.48.372

11 ngày trước

## 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.

⬇ Tải v3.48.372

v3.48.371

11 ngày trước

## 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`.

⬇ Tải v3.48.371

v3.48.370

11 ngày trước

## 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`.

⬇ Tải v3.48.370

v3.48.369

11 ngày trước

# AutoWave v3.48.369

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

⬇ Tải v3.48.369

v3.48.368

11 ngày trước

# AutoWave v3.48.368

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

⬇ Tải v3.48.368

v3.48.367

11 ngày trước

# 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。

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

⬇ Tải v3.48.367

v3.48.366

11 ngày trước

# AutoWave v3.48.366

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

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

⬇ Tải v3.48.366

v3.48.366

11 ngày trước

# AutoWave v3.48.366

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

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

⬇ Tải v3.48.366

v3.48.365

11 ngày trước

# 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`.

⬇ Tải v3.48.365

v3.48.364

15 ngày trước

release-notes-3.48.364.md

⬇ Tải v3.48.364

v3.48.363

16 ngày trước

release-notes-3.48.363.md

⬇ Tải v3.48.363

v3.48.362

16 ngày trước

release-notes-3.48.362.md

⬇ Tải v3.48.362

v3.48.361

16 ngày trước

release-notes-3.48.361.md

⬇ Tải v3.48.361

v3.48.360

16 ngày trước

release-notes-3.48.360.md

⬇ Tải v3.48.360

v3.48.359

16 ngày trước

release-notes-3.48.359.md

⬇ Tải v3.48.359

v3.48.358

16 ngày trước

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

> 非强制。force_update_below=v3.48.193。

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

含 347–357。

⬇ Tải v3.48.358

v3.48.357

16 ngày trước

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

> 非强制。force_update_below=v3.48.193。

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

含 347–356。

⬇ Tải v3.48.357

v3.48.356

16 ngày trước

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

> 非强制。force_update_below=v3.48.193。

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

含 347–355。

⬇ Tải v3.48.356

v3.48.355

16 ngày trước

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

> 非强制。force_update_below=v3.48.193。

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

含 347–354。

⬇ Tải v3.48.355

v3.48.354

16 ngày trước

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

> 非强制。force_update_below=v3.48.193。

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

含 347–353。

⬇ Tải v3.48.354

v3.48.353

16 ngày trước

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

> 非强制。force_update_below=v3.48.193。

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

⬇ Tải v3.48.353

v3.48.352

16 ngày trước

# v3.48.352 — owner 表列调整

> 非强制。force_update_below=v3.48.193。

•删掉「用户名(拥有者)」列(FB 恒不返回)。
•「归属(序号)」= 本次检测账号 {seq} (You)。

列:序号|ID|名称|状态|用户ID|归属(序号)|权限。含 347–351。

⬇ Tải v3.48.352

v3.48.351

16 ngày trước

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

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

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

含 347–350 全部。

⬇ Tải v3.48.351

v3.48.350

16 ngày trước

# 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.

⬇ Tải v3.48.350

v3.48.349

16 ngày trước

# 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).

⬇ Tải v3.48.349

v3.48.348

17 ngày trước

# 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.

⬇ Tải v3.48.348

v3.48.347

17 ngày trước

# 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

⬇ Tải 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 一致

⬇ Tải 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

|---|---|---|---|

---

## 修复 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`），用户可自行选择时机

⬇ Tải v3.48.345