Kamigotchi 脚本全功能手册

这是篡改猴四件套（核心脚本 / 辅助脚本 / 精简数据库 / 轻量杀手监控）的功能查阅书：每个功能做什么、大概怎么做、有哪些参数和命令、为什么会有它。

图例　测试线独有最早在测试线上线的功能（2026-09-19 已随测试线整体合并进主代码，标记保留作来历）　｜　已停用已停用，代码保留　｜　仅观测仅观测：只打日志做诊断，不改变任何行为

条目格式　功能名〔标记〕— 做什么 + 怎么做的要点。参数：…｜命令…｜来历…｜版本…（没有的字段不写）

总览

三层版本

本手册以测试线（beta）为准，它是功能最全的一层。2026-09-19 测试线已整体合并进主代码（两条线当天版本相同），合并前的主代码打成了稳定版 v1.4.0。之后测试线再有新改动，版本标签写"测试版 x.y.z"且晚于下表主代码版本的，才是测试线独有。

四个脚本的分工

• 核心脚本　整个套件的主流程。每轮扫一遍 kami：该停采的停采（日常批量 + 紧急停采两级）、休息的凑批部署、低血和饿死的喂食、死亡的复活，外加拾荒、XP 药水合成与喂食。所有链上 tx 都经过它的"紧急锁 + 普通锁"排队，gas 真值账本、死亡/停摆监控、保活、日志落盘也都在这里。
• 辅助脚本　核心的配套，必须和核心同时启用。在卡片上显示清算线并把危险的标红；每 6 小时全网扫描最强杀手，按官方公式重算全库精确清算线；自动升级、按标准路线加点、必要时洗点；步长够时自动合成；刷新后抢先复活；按规则在物品池自动买 Pine Cone（测试版 1.2.17 加，1.2.18 起默认开、每 7 天最多买一次）；地块适配分析（kamiAnalyze）和代码健康看板（showHealth）。
• 精简数据库　给整个套件建"精简数据库"：扫描账户全部 kami，每只压成 17 个字段（编号、链上 ID、清算线、体型/手型、harmony、maxhp、出生属性等）存进 localStorage.kami_core_db。首次安装或数据异常时启用跑一次，建完建议停用；日常新 kami 由核心的 syncKamiDb() 增量补。
• 轻量杀手监控　盯一份自己维护的杀手 kami 名单，纯 API 轮询、不读页面。杀手出现在你的采集房间或隔壁时告警，并调用核心的 emergencyStopHarvest() 紧急停采；会过滤掉"主人 24 小时没动作"和"隔壁 10 分钟既没杀人也没移动"的杀手，避免白停。自家杀手自动登记进 MY_KILLER_KAMIS，让核心和辅助跳过它们。

使用须知

• 核心和辅助要同时启用：缺辅助时合成读不到步长会跳过，转移停采不可用。杀手监控没有核心时只告警不停采。
• 脚本会替你发真实链上交易、花 gas。批量操作按大账户（kami 多于 7 只）设计，凑够 6 只才发一批。
• 四个脚本共用一个日志缓冲区，saveKamiLogs() 一次导出全部。

一、核心脚本

核心脚本是整个套件的主流程：部署、停采、喂食、复活、拾荒、XP 药水都在这里，所有 tx 都经它的锁排队。

1.1 启动与页面生命周期

脚本注入后怎么等游戏加载、怎么防止双开、什么时候整页刷新，以及刷新或关页时怎么保住日志。

脚本头与运行前提

• 篡改猴元数据头 — 声明脚本名、版本、作者、匹配域名与注入时机，让篡改猴在游戏页自动注入核心脚本。@match https://*.kamigotchi.io/*，@grant none，@run-at document-idle，@version v1.2.58。注释（第92行）写「@name 固定不带版本号，篡改猴才会自动拉新版」，本地这份文件的 @name 实际带版本号「Kamigotchi核心脚本-测试版-1.2.58」（发布器可能改写，以发布产物为准）。触发：篡改猴加载页面时｜版本测试版1.2.58
• 脚本总览与设计哲学说明仅观测 — 文件头的大框，列出九大功能：自动部署、停采（普通+紧急两级）、喂食、复活、XP药水、合成、拾荒、杀手检测、Gas统计，并写明设计哲学。设计哲学：少发 TX、省 gas、单个周期里尽量多采；所有批量决策都要落在 gas 成本曲线的甜区里。触发：文档（不执行）
• 运行前提与依赖说明仅观测 — 说明核心必须和辅助脚本一起启用、靠精简数据库 window.kami_core_db 存清算线，脚本面向 kami 超过7只的大账户，而且会真发交易、真花 gas。缺辅助脚本时合成读不到步长会跳过，转移停采命令也用不了。数据库启动时自动恢复，有新 kami 时增量自愈，首次全量构建要跑精简数据库脚本。凑批门槛≥6只，小账户可能长期凑不满。建议先小规模观察几个循环。触发：文档（不执行）｜参数凑批门槛≥6只；大账户定义>7只｜存储kami_core_db（localStorage）
• 测试版与公开版互斥警告仅观测 — 提醒测试版和公开版的 @name 不同，可以同时装上；两个核心同时跑会双份操作、互抢 nonce，所以装测试版前必须先停用公开版。文档提示。代码兜底见「单实例守卫」。触发：文档（不执行）｜命令安装说明()｜来历两核心同跑=双份部署/停采/喂食+两条通道抢nonce白烧gas

单实例与启动提示

• 重复核心实例拒绝启动 — 第一个加载的核心在 window 上插旗；后加载的核心看到旗子就整体不启动，并用红底大字说明本页已有哪个线/版本在跑、该去关哪个。本线 SCRIPT_VARIANT='测试版'。window.__kamiCoreInstance 存在且带 variant 时，打印红底提示，写 window.__kamiCoreDuplicateBlocked={blocked,running,at}，然后 return。否则插旗 {variant,version:null,at}，version 稍后由版本检查回填。刷新页面会清空 window，iframe 也是独立 window，所以不误伤。只有先加载的实例同样会插这个旗时才识别得出。另外 'use strict' 写在守卫之后、不在函数首句，实际不生效（无行为影响）。触发：脚本注入时立即执行｜参数SCRIPT_VARIANT='测试版'｜来历0911起公开版/测试版两条发行线@name不同可被同时启用，同页双核心=双份部署/停采/喂食+nonce互抢，白烧gas甚至挤掉真正要发的交易
• 守卫fail-open — 守卫读旗子时出任何异常都照常启动核心，只有确实读到旗子才拦。整段包在 try 里，catch 为空，继续往下启动。触发：守卫执行异常时｜来历宁可重复也不能让核心整个不跑——不跑就没人停采，kami会被清算
• 启动成功横幅仅观测 — 脚本注入后立即打一条绿底白字大号横幅：「Kamigotchi核心脚本-测试版 v版本（构建时间）已成功启动，等待网页加载完成…」。本脚本最早的控制台输出之一。触发：脚本注入后立即｜版本1.1.20
• 防睡眠与Chrome强节流挂机提示仅观测 — 启动时提醒：夜里挂机要先关电脑自动睡眠（必做）；Chrome 后台页强节流会让夜里紧急停采慢 1~2 分钟，测试版 1.2.59 起写明脚本按「默认会被节流」设计、关不关可选，并纠正 Mac 指引（defaults write 是推荐级不生效，要 ⌘Q 后带 --disable-background-timer-throttling 启动），附 Mac/Windows 睡眠设置路径。四条彩色 log，纯提示，无副作用。触发：脚本注入后立即｜命令安装说明()｜来历电脑睡眠会让页面JS定时器全停，HP跌破清算线被清算；Chrome强节流会让夜里紧急停采慢1~2分钟
• 小账户kami数量警告仅观测 — 启动60秒后统计当前账户 kami 数：1~7只时用红字警告凑批策略可能不适用，超过7只时绿字确认凑批正常生效。地址兼容 connectedAddress.value_ 和 .value 两种字段，再用 getByOperator 取 kamis 数组长度；取不到地址直接返回，kamis 不是数组记-1、两个分支都不命中。红字警告共4行：凑批要攒≥6只 urgent 才批量停采，小账户可能反复「跳过本轮」让 kami 在边缘等死，建议养到7只以上或手动调 emergencyStopHarvest。异常静默。触发：自动：启动60s后一次｜参数延迟60s；阈值7只（对应凑批下限6）｜命令emergencyStopHarvest()｜来历小账户可能永远凑不满一批，紧急停采反复跳过，kami在清算边缘等死
• 启动命令清单banner仅观测 — 启动3秒后打印完整命令清单，按紧急控制/模式切换/黑名单/喂食重置/Gas·TX状态/Gas账本/数据库/日志调试/安装更新分组；每条命令独占一行可直接复制，高危高频命令红字高亮。纯打印，全部走 clog 进日志。文案与实现有两处不一致：①写「旧名 'starving' 仍兼容」，但 setKamiMode 实际会拒绝 starving 并提示改用 greedy；②写 setStopTxChannel「mud(默认)」，代码缺省是 raw。末尾附提示：切地块前用 stopCurrentRoom、多账户分工先 kamiAnalyze 再 stopMinorityForTransfer、新增 kami 用 syncKamiDb、查 gas 用 showGasReport、装机说明用 安装说明()。触发：自动：启动3s后一次｜参数延迟3000ms｜命令emergencyStopHarvest()；stopCurrentRoom()；stopMinorityForTransfer()；resumeDeploy()；setKamiMode('greedy'|'normal')；getKamiMode()；showBlockedKamis()；showStopBlockedKamis()；clearBlockedKamis()；clearStopBlockedKamis()；clearFeedFails()；clearStarvingStuck()；clearXPPotionFed()；clearFortifiedFed()；feedXPPotionNow()；showMyKillers()；showGasRules()；getTxLockStatus()；setStopTxChannel('mud'|'raw')；setKeepAlive('on'|'off')；showGasReport()；syncKamiDb()；window.kami_core_db；saveKamiLogs()；kamiDebugOn({ parse: true })；kamiDebugOff()；安装说明()；kamiAnalyze()【辅助】｜版本1.1.17
• 测试版双开人眼兜底横幅测试线独有仅观测 — banner 顶部打一条紫底醒目横幅「测试线独有 测试版核心运行中 v版本（构建时间）」，并说明若同一控制台同时看到「公开版」横幅就是双开了。作为代码守卫之外的人眼兜底。触发：自动：启动3s后｜来历两个核心同跑会双份交易+抢nonce｜版本测试版

版本号与版本检查

• 版本常量收敛与构建时间自报测试线独有 — 版本号、线名、构建时间收敛成三个常量 SCRIPT_VERSION、SCRIPT_LINE、SCRIPT_BUILT，启动 log、命令 banner、版本检查都引用它们。SCRIPT_BUILT 由发布器打包时注入真实发布时间（版本没变就沿用旧日期），本地未发布时保持占位「(本地未发布)」。日志里看到这个占位，就说明这份不是从 GitHub 装的。触发：脚本注入时｜参数SCRIPT_VERSION='1.2.58'；SCRIPT_LINE='测试版'｜来历0913某账户实盘日志：辅助@version已是1.2.10，启动log却打v1.2.8（数据库/监控同类），导致两次误判「beta没装全」「监控没更新」——日志撒谎比没有日志更糟｜版本测试版1.2.47
• 启动版本检查仅观测 — 启动8秒后拉 GitHub 上 beta 版的 meta.js，对比本机版本，打「已是最新 / 请更新 / 本地比远端新」三种提示，并带上发布日期和本机安装时间。URL 加时间戳 cache-bust，并用 cache:no-store。正则解析 @version 和 @x-release-date，按段逐个数字比较。解析不到版本号就打一条跳过日志。触发：自动：启动8s后｜参数延迟8000ms｜版本1.1.18
• 本机版本首次运行时间记录仅观测 — 第一次见到某个版本时记下当时时间，近似篡改猴的安装/更新时间，显示在版本检查日志里。key 为 kami_ver_seen_核心脚本_版本号，不存在就写当前本地时间；localStorage 不可用时记「未知」。触发：版本检查初始化时｜存储kami_ver_seen_核心脚本_<版本>｜来历无法直接读篡改猴的安装时间｜版本1.1.18
• 版本号全局回写测试线独有 — 把本脚本版本号写回单实例旗子 __kamiCoreInstance.version，并写入 window.__kamiCoreVersion。前者让重复实例的拦截提示能显示正在运行的版本，后者供 安装说明() 打印，省掉一处版本号维护。触发：版本检查初始化时｜命令安装说明()｜来历避免多出一处需同步修改的版本号｜版本测试版1.2.47
• 版本检查CSP失败降噪仅观测 — 拉 GitHub 失败（绝大多数是游戏页 CSP 拒绝外联）时，24小时内只提示一次「属正常，不影响自动更新」，并附手动检查路径。时间戳存在 localStorage，24小时内命中就静默；localStorage 不可用时每次都打。触发：版本检查 fetch 失败时｜参数节流窗口86400000ms｜存储kami_vercheck_csp_note_核心脚本｜来历游戏SPA运行时注入CSP connect-src白名单，raw外联在游戏页永久失败，旧版每次页面加载都打一行=刷屏｜版本1.1.21

启动主流程与页面自检

• 启动前等待 120~150 秒（随机错峰） — 脚本注入后先等页面充分加载，再启动各业务模块。initialDelay = 120 秒 + getRandomDelayMs(30/60)，后者是 0~30 秒随机，所以总共 120~150 秒；开始时打一条「等待 X 秒」日志。触发：脚本注入时排定｜参数基础 120*1000ms；抖动 getRandomDelayMs(30/60)=0~30s｜来历随机化是为了多账户、多标签页错峰启动
• 启动倒计时日志仅观测 — 等待期间定期打印剩余秒数，方便确认脚本还活着。每秒检查一次，剩余秒数是 10 的倍数或只剩最后 10 秒时打「⌛ 剩余 N 秒后启动…」；到 0 清掉定时器，正式启动时也会先清一次。触发：脚本注入后每秒｜参数打印规则 secondsLeft%10===0 或 ≤10｜来历方便确认脚本存活
• 启动前页面自检（未就绪则整条启动链中断） — 倒计时结束后先做页面自检，没就绪就刷新重来，后续模块一个都不启动，绝不带病启动。await checkAndRefreshIfNeeded()，返回 false 就 return；通过后打「✅ 页面已完全加载，继续启动」。触发：初始延迟结束｜来历绝不带病启动
• 自检 1：钱包仍在连接中 — 钱包连接弹窗还显示着，就判定页面未就绪，原因是「钱包连接中」。#wallet-connector 存在且内联 style.display !== 'none'。代码实际读的是内联样式，和 detectGameError 用 computedStyle 不同：元素没有内联 display 时也会被当成显示中。触发：被 checkAndRefreshIfNeeded() 调用
• 自检 2：账户注册弹窗显示中 — 账户注册弹窗（#account-registrar）显示着，判定未就绪，原因是「需要注册账户」。同样读内联 style.display。按代码实际：命中后照样走 10~20 秒后刷新，刷新解决不了注册问题，所以在人工注册之前会一直循环刷新（每次还要先等启动延迟）。触发：被 checkAndRefreshIfNeeded() 调用
• 自检 3：Unknown error 崩溃界面 — 页面正文包含 "Unknown error" 就判定未就绪。document.body?.innerText?.includes('Unknown error')触发：被 checkAndRefreshIfNeeded() 调用
• 自检 4：可见的「You are Kamiless」提示 — Party 里显示「You are Kamiless」（名下没有 kami 或列表没加载对），判定未就绪；隐藏在 DOM 里的这句提示不算。遍历 #party 下所有元素，找到文字含该提示的元素后，先看自身 computedStyle 的 display 和 visibility，再沿父链一级级往上查到 body，任何一级 display:none 或 visibility:hidden 都算不可见。触发：被 checkAndRefreshIfNeeded() 调用｜来历游戏会把这句提示隐藏着留在 DOM 里，只查元素自身会误判
• 未就绪时随机等 10~20 秒后自动刷新 — 自检不通过就打出原因，随机等 10~20 秒后刷新页面，从头再来；自检通过则放行启动。打橙色日志说明原因和等待秒数，等 10000 + random×10000 毫秒后 location.reload()，返回 false 让调用方中断启动；就绪返回 true。按代码实际：这条刷新路径不调 saveLogsBeforeReload，也不走 smartReload 的计数和清缓存，日志只能靠卸载钩子保存（启动阶段离上次保存通常超过 30 秒，一般会存）。触发：启动主流程初始延迟结束后调用一次｜参数等待 10000 + random*10000 ms｜来历随机等待是为了错开多账户同时刷新
• 启动先做 kami 数据库增量同步 — 启动业务模块前，先把账户新入手的 kami 补进本地数据库，保证各模块启动时数据是全的。await syncKamiDb()，外层再包一层 try/catch（函数内部也已捕获所有异常），失败只打「同步异常（不影响主流程）」。账户没变化时 0 新增、0 额外 API 调用，几乎没有开销。触发：页面自检通过后｜来历保证后续模块启动时本地数据已补全
• 业务模块启动顺序 — 按固定顺序拉起 5 个常驻模块：防断连模拟 → 自己 kami 的死亡监控 → 自动 scavenge 领取 → 自动部署/停采主循环 → XP 药水全流程（合成 + 喂食）。打「🚀 启动自动化部署/采集」后依次调用 initIdleKeepAlive()、startMyKamiDeathMonitor()、autoScavenge()、startSequenceAfterDelay()、autoXPPotionFlow()。代码实际都没有 await，只是按顺序发起，几个模块并发运行。触发：数据库同步完成后｜来历防断连最先拉起保证长时间不掉线；死亡监控先于部署，部署后一旦被杀能立刻发现
• 被喂食监控交给配套杀手监控脚本 — kami 被喂食（Feed）的监控不在本脚本启动，由配套的轻量杀手监控脚本负责，两个脚本需要一起运行。启动序列里没有 Feed 监控，只留注释说明分工。触发：启动主流程

等待游戏加载

• 游戏加载轮询等待 — 脚本入口处每 5 秒调用 checkGameLoaded() 检查一次：钱包是否已连接、玩家 API 是否就绪，并打出最长等待时间。等待上限为 3 分钟加随机 0~3 分钟。触发：页面加载后由脚本入口调用一次｜参数maxWaitTime=3 分钟 + 随机 0~3 分钟；checkIntervalMs=5000
• 错误界面随机延时刷新 — 检测到错误界面（如 Wallet Connector / Unknown error）时，红字提示，随机等 1~20 秒后以错误原因调用 smartReload 刷新。随机延时 = Math.random()×19000 + 1000 毫秒。触发：启动轮询检测到错误界面｜参数随机延时 1~20 秒｜来历随机化避免多账户同一时刻一起刷新
• 加载成功复位错误刷新计数 — 游戏加载成功后，如果 kami_reload_count 大于 0，就把它复位为 0，并打「[智能重载] 游戏加载成功，错误刷新计数已复位为 0」。读写都包在 try/catch 里，隐私模式等异常环境不影响启动。触发：启动检测到加载成功｜存储kami_reload_count（读/写）｜来历残留的旧计数会让下一次错误刷新直接清 ECSCache，触发全量重同步，启动明显变慢
• 游戏加载超时刷新 — 超过等待上限仍没进入游戏，打出检测详情（connectedAddress、playerApiExists），然后 smartReload('游戏加载超时')。触发：启动轮询超时｜参数maxWaitTime=3 分钟 + 随机 0~3 分钟｜来历不会无限等待
• 加载进度日志节流仅观测 — 等待期间，只在剩余秒数是 30 的倍数或只剩最后 10 秒时，才打「游戏加载中，剩余 N 秒…(钱包: 已连接/未连接, API: 可用/不可用)」。每 5 秒轮询一次，剩余秒数向上取整后命中才打，所以实际输出比较稀疏。触发：启动轮询每轮｜来历避免刷屏
• 加载期顺手点加载按钮（带状态门）测试线独有 — 等待加载期间，发现 #party_button 按钮时顺手点击以加速进入游戏；但只在没有别处正在开列表、且列表确实处于折叠状态时才点，打「检测到加载按钮（列表未打开），点击…」。条件：按钮存在，且 !window.__ensurePartyInFlight，且 __isPartyListClosed()；simulateClick 延时 500ms。触发：启动轮询每轮（尚未加载成功时）｜参数simulateClick 延时 500ms｜来历复核 0914 时序推演：这颗开关按钮盲点会把紧急停采刚打开的列表点关｜版本测试版1.2.53
• 钱包连接弹窗卡住识别 — 检查页面上的钱包连接弹窗（#wallet-connector）是否还显示着，显示着就判定为「Wallet Connector 认证卡住」（认证超时卡死）。用 getComputedStyle 取实际显示状态，display 不为 none 即算卡住；按元素 id 定位，不依赖容易随前端改版变化的 class 名。触发：被 checkGameLoaded() 调用；游戏加载等待循环检测到该错误后随机等 1~20 秒再调 smartReload(错误原因)｜来历认证超时时弹窗会一直挂着，游戏进不去，必须识别出来刷新
• Unknown error 崩溃界面识别 — 页面正文里出现 "Unknown error" 字样就判定为游戏崩溃黑屏，返回「Unknown error 界面」；两种错误都没有时返回 null。该界面没有稳定 id，只能读 document.body.innerText 按文字匹配；document.body 还没就绪时用可选链兜底成空串，不会报错。触发：被 checkGameLoaded() 调用｜来历崩溃界面没有稳定 id，只能靠文案判断
• 真实 Kami 条目判断（仅作诊断）仅观测 — 看 Party 列表里有没有渲染出真正的 kami 卡片，而不是提示文字。在 Party 列表条目（div#party>…>div）里找带 direction="row" 属性的子元素，找到任意一个就算有真实 kami。结果只放进 details 当诊断信息，不作为「进入游戏成功」的依据。触发：被 checkGameLoaded() 调用｜来历进游戏后没点开 Party 列表时 DOM 里检测不到 kami，但游戏其实已经进去了，拿它当判据会误判
• 进入游戏成功判据（钱包地址 + player API） — 综合判断是否真正进入了游戏：没有错误界面，并且钱包地址和 player API 都已就绪，才算成功。success = connectedAddress（window.network.network.connectedAddress.value_ 有值）且 playerApiExists（window.network.api.player 存在）。返回 {success, error, details}。调用方（加载等待循环，范围外）：出错走 smartReload；成功把 kami_reload_count 复位；3 分钟仍未成功则 smartReload('游戏加载超时')。触发：游戏加载等待流程循环调用｜来历Kami 列表要手动展开才会渲染，所以成功标准只看钱包加 API
• 错误界面优先短路 — 只要识别到错误界面，就直接判定失败，哪怕钱包地址和 API 已经就绪也不算成功。checkGameLoaded 先调 detectGameError()，有错误就立即返回 success:false 和错误描述，不再做成功判断。触发：checkGameLoaded() 内部
• 加载诊断信息包 details仅观测 — 每次判定都顺带收集 9 项页面和接口状态，方便排查加载失败的原因。9 项分别是：partyExists、partyButtonExists、eyeButtonExists（#party 里的 eye- 图标按钮）、kamiListLength、hasRealKami、networkExists、apiExists、playerApiExists、connectedAddress。调用方在加载超时时会打印 connectedAddress 和 playerApiExists。触发：checkGameLoaded() 每次调用

打开列表、切眼睛、拉起主循环

• 按状态打开 Kami 列表测试线独有 — 有 Party 按钮时调用 __ensurePartyListOpen('启动')，列表折叠才点开；已经打开就不点，打「列表已打开（本处未点击）」。打开过程异常时打警告并继续启动；找不到 #party_button button 时打「未找到 Party 按钮，跳过点击」。触发：启动检测到加载成功后｜参数Party 点击后等 2500ms、眼睛每下 1500ms（见 __ensurePartyListOpen）｜来历Party 是开关按钮，列表已开（例如紧急停采刚点开）时再点会被点关｜版本测试版1.2.53
• 切到 eye-half 后启动主循环 — 打出当前眼睛状态，调用 waitForEyeHalf 切到 eye-half；成功后等 3.5 秒，立即执行一次 runAutomation，再用 setInterval 按 checkInterval 周期执行。主循环周期 checkInterval = 10 分钟 + 随机 0~3 分钟（页面加载时定一次）。触发：启动检测到加载成功后｜参数启动主循环前固定等待 3500ms
• eye-half 失败终止启动 — waitForEyeHalf 返回失败时，红字打「waitForEyeHalf 失败，已触发刷新，终止当前启动流程」并直接结束，不再重复刷新。触发：waitForEyeHalf 返回 false｜来历waitForEyeHalf 内部已经触发刷新，这里再刷会双重刷新
• 读取眼睛显示模式 getEyeState — 读取 Party 面板眼睛按钮的图标，返回 open / half / closed 三态之一；找不到按钮或识别不了返回 null。选择器 #party button img[src*="eye-"]，按 src 是否包含 eye-open / eye-half / eye-closed 判断。触发：启动序列和 waitForEyeHalf 调用，也可随时单独调用
• 自动切换到 eye-half 模式 — 轮询眼睛状态，已经是 half 就打「成功切换到 eye-half 状态」并返回 true；否则模拟点击眼睛按钮（三态循环切换），等 1 秒后下一轮再看。打「尝试点击眼睛按钮切换状态」，simulateClick 延时 300ms，点击后等 1000ms，再等轮询间隔 2000ms。触发：启动序列在列表打开后调用｜参数checkIntervalMs=2000；stateDelay=1000；simulateClick 延时 300ms｜来历脚本的 DOM 状态检测（卡片状态图标等）都建立在 eye-half 模式的卡片结构上
• 眼睛状态变更日志仅观测 — 只有状态和上一次不同时才打「状态变更: 旧 → 新」（首次显示「初始」），便于回溯。用 lastState 记录上一次状态，相同不打。触发：waitForEyeHalf 每轮
• 找不到眼睛按钮时只等待不点击 — 找不到眼睛按钮就不点，打「找不到眼睛按钮，等待中…」继续轮询。每轮都会打这一行，点击日志同理。触发：waitForEyeHalf 每轮
• 切换超时自动刷新 — 超过 3 分钟基础时间加随机余量仍没进入 eye-half，打「超时仍未进入 eye-half 状态，触发刷新」，调用 smartReload 刷新页面并返回 false。刷新原因为「眼睛按钮状态异常，未能切换到 eye-half」；随机余量由 getRandomDelayMs(3) 给出，为 0~3 分钟。触发：waitForEyeHalf 超时｜参数baseWaitTime=3 分钟 + 随机 0~3 分钟｜来历防止挂机卡死在异常界面；随机化避免多账户同一时刻集体超时刷新
• 启动停采退避复读调度器 — 主循环启动后，同时启动一个每 15 秒扫描一次的退避复读调度器，只做零 gas 的 state 复读，并打出调度表（7s/20s/45s/90s/180s/300s）。用 window.__stopBackoffSchedulerStarted 防止重复启动；整段 try/catch，不影响主循环。触发：启动主循环后一次｜参数STOP_BACKOFF_SCAN_INTERVAL_MS=15000；STOP_BACKOFF_TABLE_MS=[7000,20000,45000,90000,180000,300000]｜版本1.1.22
• 启动 gas 账本回执补录器仅观测 — 主循环启动后，同时启动 gas 账本 reconciler：每 3 分钟按 tx hash 只读补一次回执 gas，单轮最多 20 条，不新增任何 tx。用 window.__gasLedgerReconcilerStarted 防止重复启动；整段 try/catch；启动日志提示报告命令 showGasReport()。触发：启动主循环后一次｜参数GAS_LEDGER_RECONCILE_MS=3 分钟；GAS_LEDGER_RECONCILE_BATCH=20｜命令showGasReport()｜版本1.2.7

定时刷新与智能重载

• 约 45~50 分钟定时整页刷新 — 每运行约 45 分钟加随机 0~5 分钟就整页刷新一次，让页面回到干净状态。totalDelayMs = 45 分钟 + getRandomDelayMs(5)，注入时打「页面将在 X 分钟后刷新」并排定 performScheduledReload；刷新后脚本重新注入，等于自动续期。触发：脚本注入时排定｜参数baseMinutes=45；getRandomDelayMs(5)=0~5分钟｜来历长时间不刷新会积累内存泄漏、WebSocket 断连、状态漂移；随机量用于多账户错峰
• 紧急停采让路（总上限 10 分钟）测试线独有 — 紧急锁被持有、紧急停采流程正在跑、或有刚登记（5 分钟内）的残留补停待补时，先不刷新，每 15 秒再查一次。判断条件 __reloadBlockedByEmergency() = hasEmergencyLock() || (window.__emergencyStopRunning===true 且不是卡死的一轮) || __residualRestopBlocksReload()，排在所有判断最前面，不占用 3 次延迟额度。测试版 1.2.60 起有总上限：从这次到点的刷新第一次被挡起累计 10 分钟（__RELOAD_EMERGENCY_MAX_MS，不因原因切换而清零），到点打红字「已给紧急停采让路 N 分钟，达到总上限…强制刷新」照常刷新；已卡死（20 分钟无进展）的一轮直接不让。加上「操作进行中」的 3×3 分钟，最坏约 19 分钟必刷新。让路日志带「已让路 Ns，上限 10 分钟」。触发：定时刷新到点时｜参数__RELOAD_EMERGENCY_RECHECK_MS=15000；__RELOAD_EMERGENCY_MAX_MS=600000｜来历1.2.54 加这道闸门时没设上限；0918 一台机器上一轮紧急停采卡在永不返回的请求上，运行标志挂了 4 小时，能救场的刷新被拦了 968 次，期间杀手进房死 24 只。用户 0918：「不能无限延长，有时候卡的东西刷新一下就好了」｜版本测试版1.2.54；测试版1.2.60
• 刷新落地前二次复查紧急停采测试线独有 — 决定刷新后、真正 reload 之前再查一次，如果这期间紧急停采已经开始，就取消这次刷新。__reloadIfStillClear：发现被紧急停采挡住就打橙色日志，15 秒后重新走完整的 performScheduledReload（通过后会再保存一次日志，可能多出一份日志文件），否则 location.reload()。触发：performScheduledReload 保存日志后约 1 秒（后台节流时可能更久）｜参数复查间隔 15s｜来历0914 实录：后台节流把「等 1 秒再刷新」拖到约 1 分钟，期间紧急停采刚开始就被刷新切断，9 只已跌破线的 kami 拖到 5.6 分钟后才停｜版本测试版1.2.54
• 操作进行中让路（最多 3 次，每次 3 分钟） — 有停采操作正在执行时，先推迟 3 分钟再刷新，不打断正在发送的 TX。__kamiOperationInProgress 为 true 且延迟次数 < 3 时，计数 +1，打橙色日志「第 n/3 次延迟」，3 分钟后重试。计数在本会话内不复位，刷新后自然归零。触发：performScheduledReload 执行时（紧急停采判断之后）｜参数__RELOAD_MAX_DELAYS=3；__RELOAD_DELAY_MS=3分钟｜存储window.__kamiOperationInProgress（读）｜来历半途刷新可能造成状态不一致或白烧 gas
• 延迟额度用尽强制刷新（熔断） — 已经推迟满 3 次（共 9 分钟）但操作标记还没复位时，打红色警告并强制刷新。额度用尽且标记仍为 true 时打「已达到最大延迟次数（3次×3分钟=9分钟），强制刷新」，然后照常存日志并刷新。触发：延迟额度用尽后｜参数__RELOAD_MAX_DELAYS=3｜来历防止业务异常导致标记没复位，刷新被无限推迟
• 定时刷新前存日志并等 1 秒 — 任何定时刷新之前都先把日志保存到下载文件夹，再等 1 秒让下载完成。调 saveLogsBeforeReload()，打「🔄 执行定时刷新」，setTimeout(__reloadIfStillClear, 1000)。卸载钩子会因为 30 秒内刚存过而不再重复保存。触发：通过紧急停采和操作让路判断后｜参数刷新前等待 1000ms｜来历刷新后内存日志会丢失
• 全局操作进行中标记 __kamiOperationInProgress — 一个全局布尔标记，表示当前有停采类操作正在执行。定时刷新看到它为 true 时会让路，避免刷新打断正在发送的 TX。脚本加载时初始化为 false。按代码实际（grep 结果），置位方有两处：emergencyStopHarvest 开始时置 true、收尾置 false；批量停采/部署轮次在待停列表（apiList/domList）非空时置 true、结束置 false。注释写「停采/部署开始时置位」，代码实际只在有停采任务时置位，纯部署轮不置位。触发：脚本加载时初始化；业务流程写，定时刷新读｜存储window.__kamiOperationInProgress（全局变量）｜来历半途刷新可能造成状态不一致或白烧 gas
• 带连续失败计数的智能重载 — 需要刷新页面时先记一次重载次数，再刷新；这个计数跨刷新保存，用来识别「连续失败」。读 localStorage 的 kami_reload_count（没有或非数字按 0）并 +1，打「🔁 第 N 次尝试重载（原因）」。调用方（范围外）：钱包连接异常（死地址）、眼睛按钮没能切到 eye-half、游戏加载检测到错误界面、游戏加载超时、检测不到 Kami 列表。加载成功的流程会在计数 >0 时复位为 0。代码实际：smartReload 本身不检查紧急锁和 __kamiOperationInProgress，直接刷新。触发：异常检测流程调用 smartReload(reason)｜命令手动重置计数：localStorage.removeItem('kami_reload_count')｜存储kami_reload_count｜来历加载成功后要复位计数，否则残留计数会让下一次错误刷新直接清缓存、触发全量重同步，启动明显变慢
• 白屏保护：第 2 次重载清 ECS 缓存 — 连续第 2 次需要重载时，判定本地 ECS 缓存已损坏（典型表现是白屏），先删掉游戏的 IndexedDB 缓存库再刷新，迫使客户端从链上全量重新同步。nextCount>=2 时用 indexedDB.databases() 枚举，只删名字以 ECSCache- 开头的库（不碰其他站点数据），每删一个打一条日志。删除请求是异步发出、没有 await，靠后面等 1.5 秒给它时间完成。触发：smartReload 计数达到阈值时｜参数阈值 nextCount>=2｜存储IndexedDB ECSCache-*｜来历本地 ECS 缓存损坏会导致白屏，普通刷新治不好
• 旧内核不支持枚举时退化为普通刷新 — 浏览器不支持 indexedDB.databases() 时跳过清缓存，只普通刷新，不报错。!indexedDB.databases 时打「当前环境不支持…跳过清除」，继续后面的计数归零和刷新。触发：清缓存分支内｜来历旧内核不能枚举数据库，无法定位 ECSCache-*
• 清缓存后计数归零 — 清完缓存立刻把重载计数写回 0，避免下一次正常刷新也误触发清缓存。localStorage.setItem('kami_reload_count','0')触发：清缓存分支内｜存储kami_reload_count｜来历避免下次误触发全量重同步
• 刷新前先存日志并留出等待时间 — 刷新前先保存日志；普通重载等 1 秒、清缓存重载等 1.5 秒再刷新。函数开头先调 saveLogsBeforeReload()。普通分支写回计数后 setTimeout(reload, 1000)；清缓存分支 setTimeout(reload, 1500)，多出的 0.5 秒留给 IndexedDB 删除请求。触发：每次 smartReload｜参数1000ms / 1500ms｜来历等待太短，日志下载或 IndexedDB 删除可能来不及完成

关页或刷新前抢救日志

• 页面卸载时自动保存日志 — 用户手动 F5、关标签页或浏览器崩溃前，也尝试把日志存下来。在 window 上挂 pagehide 和 beforeunload 两个监听，触发时调 saveLogsBeforeReload()，全程 try/catch 静默。挂好后打一条启动日志。已知限制：浏览器可能拦截卸载期间的下载（后台标签页尤其常见），这是尽力而为的兜底；Chrome 第一次会问「允许下载多个文件」，需要允许一次。触发：自动：页面 pagehide / beforeunload 事件｜来历原来只有脚本自己的两条刷新路径会存日志，手动刷新、关标签或崩溃时最多丢 45 分钟日志；做法参考了其他脚本的 pagehide/beforeunload 打法｜版本1.2.19
• 30 秒去重（与自动保存互斥） — 30 秒内已经存过日志，卸载时就不再存一次，避免同一次刷新下载两份文件。Date.now() - __lastLogSaveAt < 30000 就跳过。因为 __lastLogSaveAt 是内存变量、新会话归零，连续手动刷新每次仍会各存一份，不会被上个会话的时间戳挡住。触发：卸载钩子触发时｜参数MIN_GAP_MS=30000｜来历自动刷新路径是「先保存，1~1.5 秒后 reload」，不去重会重复下载｜版本1.2.19
• 卸载监听幂等挂载 — 脚本被重复注入时，先摘掉旧监听再挂新的，保证一次刷新只触发一次下载。处理函数存在 window.__kamiUnloadSave 上；已存在时先 removeEventListener 摘掉 pagehide 和 beforeunload 的旧监听，每步单独 try/catch。触发：脚本注入时｜存储window.__kamiUnloadSave（全局变量）｜来历防止一次刷新触发多次下载｜版本1.2.19

1.2 主循环总览

runAutomation 每 10~13 分钟跑一轮：读卡片 → 分池 → 停采 → 部署 → 喂食 → 复活。这一节是骨架和它依赖的通用工具，各环节细节见后面各节。

主循环骨架

• 主循环扫描→决策→执行闭环 — 脚本的心脏：每个检测周期读一遍 Party 面板里每只 kami 的状态和血量，依次完成停采、紧急停采升级、饿死救援、批量部署、低血喂食、批量复活。顺序：列表就绪检测→DOM 预检→遍历分池→停采分流→紧急硬触发→锁协调→锁内（单停凑批→饿死救援→API/DOM 停采→批量部署）→锁外（库存盘点→低血喂食→批量复活）。设计哲学：减少 TX、省 gas、采集更久，凑批/跳过都在 gas 甜区内争取最长采集。触发：检测周期定时器反复调用；页面加载后首轮同一入口｜命令syncKamiDb() 重建/补全本地库；resumeDeploy() 立即解除转移部署暂停窗口（两者定义在别处）
• 主循环健康心跳仅观测 — 每轮开头写一个时间戳，让辅助脚本的健康看板分得清主循环是「没活干」还是「卡死了」。window.__kamiHealthBeats['主循环']=Date.now()。触发：每轮开头｜来历主循环平时可能整轮静默（无候选不打日志）｜版本v1.1.5
• 每轮刷新前端冻结传感器仅观测 — 每轮顺手评估一次游戏前端数据流是否冻住。存在 window.__evalFrontendFrozen 时调用(600000)，纯日志并维护 window.__frontendFrozen，异常吞掉。触发：每轮开头｜参数参数 600000ms｜版本v1.1.25
• 跨脚本全局变量约定（主循环读写） — 主循环与辅助脚本、杀手监控脚本靠一组 window 全局变量互相通气。读：window.__kamiMode（greedy=贪婪）、window.__killerDetected（杀手告警）、window.MY_KILLER_KAMIS（自家杀手 Set）、window.__deployPausedUntil（转移暂停截止时间）、window.__txNormalLock（普通锁持有者）、window.kami_core_db。写：window.__kamiOperationInProgress、window.__deployPauseReminder、window.__kamiHealthBeats。触发：每轮
• 主监控循环间隔 10~13 分钟 — 主循环轮询间隔 = 基础 10 分钟 + 0~3 分钟随机，页面会话内固定（刷新才重新随机）。checkInterval 在脚本注入时算一次，启动时 setInterval(runAutomation, checkInterval) 使用。触发：脚本注入时计算一次｜参数基础 10*60*1000；getRandomDelayMs(3)｜来历监控检查本身不发 TX，拉长间隔减少链上/DOM 读取开销；HP 危险另有紧急停采线兜底，不依赖轮询密度
• 启动打印本轮检测间隔仅观测 — 打印「本轮检测间隔为：10 分钟 + 随机 X 分钟，共 Y 分钟」。计算完立即打印，方便确认。触发：脚本注入时
• kamiHistory 状态历史容器 — 按 kami 记录上一轮观测到的状态的 Map，供主循环跨轮次对比状态变化。new Map()，由主循环读写。触发：脚本加载时创建
• getRandomDelayMs 随机抖动 — 生成 0~maxMinutes 分钟之间的随机毫秒数，给周期性动作加抖动。Math.random()×分钟上限→换算毫秒向下取整；纯函数，maxMinutes 默认 1。触发：被检测间隔计算等位置调用｜参数maxMinutes（调用方传入）｜来历避免每轮间隔完全固定，错峰执行、降低行为规律性

列表就绪与 DOM 预检

• 卡片列表就绪检测 + 定时重查 — 确认 Party 面板里的 kami 卡片已经渲染出来，没渲染就隔一会儿再查。选择器 div#party>div>div:nth-of-type(3)>div:nth-of-type(2)>div:nth-of-type(2)>div；为空则计数并打「第N次检测：未发现任何 Kami」，setTimeout 定时重查。代码实际：checkKamiList() 没有 await，首次为空时主流程不等重查照常往下走，由 DOM 预检兜底。触发：每轮 runAutomation 开始｜参数retryIntervalMs=10秒+随机0~10秒抖动｜来历重试间隔加随机抖动，避免与其他定时任务同拍
• 连续查不到刷新页面自救 — 连续 10 次都查不到卡片，判定页面卡死，自动刷新。retryCount 达 maxRetries 时打红色「连续 10 次未检测到 Kami，刷新页面防止卡顿」，调 smartReload('检测不到 Kami 列表')（带防抖，防无限刷新）。触发：重查计数达上限｜参数maxRetries=10
• 检测成功打印账户与地块信息仅观测 — 查到卡片后报出数量，并打印账户与地块信息。打「检测到 N 个 Kami，正在监测血量百分比...」后 await printAccountAndRooms()。触发：卡片列表非空时
• 卡片不完整率检测测试线独有 — 正式扫描前统计有多少卡片缺关键字段，超过一半就先修复再扫，避免大批 kami 被早期过滤、整轮白跑。__countIncompleteDom(kamiList) 统计缺状态图标/HP(N%)/图号/主按钮任一项的卡片，占比>阈值即进入修复重试。该函数已提升到顶层与紧急停采共用。触发：checkKamiList 之后、遍历之前｜参数__DOM_INCOMPLETE_THRESHOLD=0.5｜版本测试版1.2.51
• 规模严重不足检测（历史峰值 10%） — 卡片数量少于历史峰值的一成时判为渲染异常，宁可先修也不在 DOM 不全时误操作；小账户不适用。读 localStorage 峰值，峰值≥20 且当前数<峰值×0.1 → 打红色「规模严重不足 当前/峰值」进入修复。触发：每次 DOM 预检循环｜参数__SCALE_ANOMALY_RATIO=0.1；峰值门槛≥20｜命令localStorage.removeItem('kami_last_known_count') 重置基线｜存储kami_last_known_count（读）｜来历列表只渲染出几只时会把渲染缺失误当真实状态做错决策
• 第 1 次修复：纯等待 8 秒 — 第一次发现 DOM 不对劲时只等 8 秒，多数情况只是渲染慢半拍。__domRetry===0 时打「等待 8 秒让 DOM 充分加载」并 delay(8000)。触发：预检不通过的第 1 次｜参数8000ms
• 第 2 次修复：按状态打开列表 + 眼睛切 half测试线独有 — 第二次仍不对时，确保 Party 列表是打开的、眼睛视图在 half 档，再等 5 秒。__ensurePartyListOpen('DOM预检')（折叠才点开）；getEyeState()!=='half' 时打日志并 waitForEyeHalf()；delay(5000)。触发：预检不通过的第 2 次｜参数5000ms｜来历原来盲点 Party 按钮，列表已经开着时会被点关｜版本测试版1.2.53
• 修复后重查、修不好照常向下 — 每次修复后重新抓卡片列表；两项检查都通过就提前结束，修不好也继续往下走。重新 querySelectorAll 并打「重新查询 kamiList，共 N 条」；最多 __maxDomRetry 次，之后由遍历阶段的早期过滤兜底（不完整卡片只会被跳过）。触发：每次修复后｜参数__maxDomRetry=2
• 历史规模峰值记录（只升不降） — 本轮卡片数≥20 且超过旧峰值时更新历史峰值，个别异常轮不会把基线拉低。localStorage.setItem('kami_last_known_count',N)，打「更新历史峰值: 旧 → 新」。触发：DOM 预检结束后｜参数峰值记录门槛≥20｜命令localStorage.removeItem('kami_last_known_count') 重置｜存储kami_last_known_count（写）｜来历避免个别异常轮拉低基线

卡片遍历与分池

• 扫描统计器（早期过滤按字段细分）仅观测 — 记录本轮各种跳过原因的数量，停采/部署池意外为空时能直接看出是哪个字段没渲染。__scanStats 含 earlyFilter 及 emptyState/nanHP/emptyImg/emptyBtn 四个细分，以及 restingTotal/restingLTSkip/restingHPLow/restingAlreadyActed；每轮在分流后打「扫描统计」一行。触发：每轮遍历中累加
• 卡片状态解析（含 STARVING 推断） — 从卡片图标和血量文字判断每只 kami 是死亡、饿死、采集中还是休息。img src 含 kami_dead→DEAD；含 kami_harvesting 且 HP=0%→STARVING，否则 HARVESTING；含 kami_resting→RESTING；HP 取图标下一个兄弟元素的 (N%)。触发：每轮遍历每张卡片｜来历游戏 DOM 没有独立的饿死图标，只能用「采集图标 + HP 归零」推断
• 个性化停采线 safePercent — 按每只 kami 的精确清算线加 3% 缓冲算出它自己的停采线，最高不超过 80%。record.LT 有效时 safePercent=min(floor(LT+LT_STOP_MARGIN), MAX_THRESHOLD)，否则 undefined。触发：每只卡片解析时｜参数LT_STOP_MARGIN=3；MAX_THRESHOLD=80｜来历封顶 80% 是有意设计：目标是单周期采集时长最大化，清算线过高的 kami 应先升级而不是放宽上限
• 体质判定 — 判断 kami 是不是普通体质，用于没有清算线数据时选默认停采线。属性图标行 *[direction='row'] img 第 1 张 src 含 normal 即普通体质；图标缺失时回退本地库 body==='normal'。触发：每只卡片解析时
• DEAD 只收集，循环后统一复活 — 扫描中遇到死亡 kami 只记下来，整轮扫完再一次性批量复活；缺 kamiId 的提示先补数据。有 kamiId（或 id）则 push 进 __deadToRevive 后 continue；没有则打「已死亡但缺 kamiId，无法复活（请跑 syncKamiDb() 补数据）」。不做地块检查。触发：遍历中遇到 DEAD｜命令syncKamiDb()｜来历逐只拿锁等确认时慢链下后面的死 kami 全被自己上一笔挡住，表现为「日志提示复活但迟迟没动作」；死亡 kami 任何地块都能复活且 harvest.node 基本读不到，查地块既无必要也不可靠
• 早期过滤不完整卡片 — 状态、血量、图号、主按钮任一缺失说明卡片没渲染完，直接跳过，不做任何操作。任一缺失时 earlyFilter+1，并按缺失字段分别计数后 continue；主按钮=harvest-/stop- 图标所在的 button。触发：每只非 DEAD 卡片
• 扫描阶段不检查操作面板 — 扫描时刻意不要求操作面板存在。只有注释说明，没有面板检查代码。触发：遍历中｜来历面板只有点击卡片后才渲染，扫描阶段检查必然失败导致误跳过
• 卡片解析调试日志仅观测 — 调试开关打开时逐只输出解析结果。dlog('parse','[PARSE] #index/img state hp isNormal')。触发：每只通过早期过滤的卡片
• 本地库状态与 DOM 状态并联判定 — 本地库记录的链上状态和卡片图标，任何一个显示采集中就按采集中处理，宁可多查一次也不漏停。stateAPI=record.state 大写；停采分支条件 stateAPI==='HARVESTING'||DOM 为 HARVESTING/STARVING；部署分支条件 stateAPI==='RESTING'||DOM 为 RESTING。代码实际：两个 if 并列不互斥，本地库与 DOM 不一致时同一只可能同时进停采池和部署池。触发：每只卡片
• 单只异常不影响整轮 — 某只 kami 处理出错时只记日志，继续处理其余 kami。每只包 try/catch，打「Kami 处理异常：错误」。触发：遍历中

通用工具

• 从 DOM 节点提取 imgNumber — 从 Kami 卡片（或头像 img 本身）提取头像 gif 编号，作为「DOM 卡片 ↔ 链上 Kami」唯一的对应桥梁。节点本身是 IMG 就直接用，否则找内部的 img[src*="/kami/"]；用正则 /kami/(\d+).gif 取编号（string），取不到返回 null，不抛错。触发：所有需要把 DOM 卡片和链上数据对应起来的逻辑调用
• 同类动作去重窗口 alreadyActed — 同一只 Kami 最近一次动作与本次同类型，且距今不到一个主循环周期时，视为本周期已处理，调用方跳过，防止重复操作。只记最后一次动作，异类动作会覆盖记录；窗口到期自动失效，不用手动清理。触发：对 Kami 执行动作前查询｜参数去重窗口 = checkInterval（10 分钟 + 随机 0~3 分钟）
• 动作登记 recordAction — 动作执行成功后，以 imgNumber 为 key 记下 {动作类型, 时间戳}，供去重查询使用。存在全局内存 Map kamiHistory 里，页面刷新即清空。触发：动作成功后调用（如普通停采确认已停后登记 stopHarvest）
• 批量操作后 UI 沉降时长 — 批量 TX 之后等一段固定时间，再读游戏前端的界面和状态。调小流程更快但可能读到未刷新的旧状态；调大更稳但整轮耗时变长。普通停采确认后的复核也用这个值。触发：批量部署/停采后被引用｜参数UI_SETTLE_MS=25000
• TX 哈希合法性校验 _isHash64 — 判断一个值是否是合法的交易哈希：字符串，且为 0x 加 64 位十六进制。正则 ^0x[0-9a-fA-F]{64}$。触发：被其他板块调用
• 小清单整批发送 — 清单为空返回空数组；清单长度不超过上限（10）时整体作为一批，即使不足下限（6）也不再拆。arr.length ≤ maxSize 时直接返回 [arr.slice()]。触发：部署/普通停采/紧急停采组批时｜参数minSize=6 / maxSize=10｜来历单独一小批也比再拆成更小的零头好
• 最少批数保证每批不低于下限（防小残批） — 清单超过上限时，先算出能让每批基础大小都不低于 6 的批数，避免拆出 3~5 只的小残批单独发 TX。批数从 ceil(L/10) 开始，只要 floor(L/批数) < 6 就减一。触发：组批时｜参数minSize=6 / maxSize=10｜来历避免 L=13/14/15/23/25 这类长度出现小残批，小批 gas 单价高，违背省 gas 原则
• 11 只超上限整批例外 — 批数被减到 1 时（数学上只有 L=11 会发生），11 只整体作为一批发出，略超上限。因此算法最大批就是 11 只，不需要额外的硬上限常量。触发：组批且 L=11 时｜来历N=11 停采约 16.15M gas，低于 N=12 的约 17.40M，仍在安全区
• 零头随机指派错峰 — 均匀分批后，把余数随机分给若干批次各多 1 只，保留批量大小的随机性。基础大小 floor(L/批数)，用 Fisher-Yates 洗牌批次序号，取前「余数」个批次各 +1。注释写「每批 6-10 随机错峰」，代码实际每批大小由 L 决定，只可能是基础大小或基础大小+1，随机的只是哪几批多 1 只。触发：组批时｜来历固定的大批量在链上 gas 飙升时段失败率偏高，错峰可降低整批失败概率
• 链上状态归一 getKamiState — 把链上返回的状态字符串统一成小写状态码：harvesting（采集中）、resting（休息中）、dead（已死亡）、external（已作为 ERC-721 转出到外部钱包，不归本账户管）。其余一律 unknown。取 res.state 转大写后 switch 映射；res 为空或没有 state 时经 ?. 和 || '' 兜底落到 unknown，不抛异常。触发：所有需要判断链上状态的地方调用｜来历避免各处散落大小写比较
• isHarvesting / isResting / isDead 判断函数 — 三个便捷判断，分别判断是否采集中、休息中、已死亡，供停采、喂食、复活等决策统一调用。都基于 getKamiState 的结果做等值比较。触发：被决策逻辑调用

1.3 停采

日常停采：主循环按停采线挑出候选，凑批后优先走链上 API 批量停采，失败的走 DOM 模拟点击兜底；另有两个一键停采命令。血量已经触线的紧急情况见 1.4。

停采决策与候选分流

• 停采线三选一 — 按模式和杀手情况为每只采集中的 kami 选停采线：贪婪无杀手用极限线，否则用个性化线，没数据用默认线。__kamiMode==='greedy' 且无杀手→GREEDY_THRESHOLD（来源 GREEDY_EXTREME）；否则有 LT→safePercent，无 LT→普通体质 65%、其他体质 76%；来源在贪婪+有杀手时为 GREEDY_SAFE，其余为 NORMAL。触发：本地库或 DOM 判定为采集中/饿死时｜参数GREEDY_THRESHOLD=5；DEFAULT_THRESHOLD_NORMAL=65；DEFAULT_THRESHOLD_OTHER=76；MAX_THRESHOLD=80｜命令setKamiMode 等模式命令定义在别处｜来历有杀手时即使贪婪模式也退回安全线；非普通体质受亲和克制更易被清算，默认线更高
• 预警带入停采池 — 血量离停采线不到 1 个百分点（或已饿死）且不在动作冷却期，就放进停采池。delta=HP-阈值（保留两位）；delta≤1 或 STARVING，且 !alreadyActed(img,'stopHarvest') → push {imgNumber,dbIndex,harvestId,delta,isStarving}；alreadyActed 的冷却窗口为主循环周期 checkInterval；dlog 输出 [STOP?] 判定明细。触发：每只采集中 kami｜参数入池预警带 delta≤1｜来历isStarving 标记随候选带入：饿死的必须先喂食才能停采
• 普通模式停采线独立计数 — 不管当前是不是贪婪模式，都再按普通停采线数一遍有多少只该停，用于尽早识别批量受攻击。普通线=safePercent 或 65%/76% 默认线；delta≤1 或 STARVING 且不在冷却期则 __normalLineStopCount+1。注释写「>25 即触发紧急停采」，代码实际动手线是 STOP_TRIGGER_ACT=42（公开版口径；测试线 1.2.59 为 106、贪婪线 30%）。触发：每只采集中 kami｜来历贪婪无杀手时停采线仅 5%（公开版），按当前模式几乎凑不出大批候选，「候选过多→紧急停采」保护会形同虚设
• 停采池按危险程度排序 — 停采候选按离停采线的距离从小到大排，最危险的最先停。过滤掉 delta 非数字的，按 delta 升序 sort。触发：遍历结束后
• 按 harvestId 分 API/DOM 两路 — 有合法 harvestId 的走链上 API 批量停采（快、省 gas），没有的走模拟点击兜底。_isHash64(harvestId) 为真进 apiList，否则进 domList。触发：排序后
• 每轮分流与池子统计日志仅观测 — 每轮打出 API/DOM 两路停采名单、部署池大小和扫描统计。「stop 分流 API=N → 列表」「stop 分流 DOM=N → 列表」「部署池 kamiList/strong/warm/stop」「扫描统计 …」，另有 dlog 汇总。触发：每轮分流后

凑批省 gas（单只停采决策）

• 单只停采凑批四分支 — 本轮只有 1 只要停（且 DOM 路为空）时，判断是跳过等凑批省 gas，还是马上单停。饿死→打「必须立刻喂食+停采，不凑批」不跳过；贪婪无杀手→打「停采线仅5%…立刻停采」不跳过；普通线且 delta>-1→清空 apiList 跳过本轮等凑够≥2 只；delta≤-1→打「HP已低于停采线超过1%…立刻单独停采」。板块注释写「低于停采线超过 3%」，代码实际危险线是 -1。饿死分支日志说「立刻喂食+停采」，但 1.2.26 起 API 停采会剔除 STARVING，本轮实际只喂不停。触发：apiList 恰好 1 只且 domList 为空｜参数SINGLE_STOP_DANGER_DELTA=-1；GREEDY_THRESHOLD=5｜来历为 1 只单独发 TX 最不划算；危险线配合 +3 薄垫收紧，再等一轮就可能踩到清算线

批量修剪硬触发

• 候选过多硬触发紧急停采（修剪到 100）测试线独有 — 一轮该停的 kami 多到异常（按当前线或按普通线任一达到 106 只），判定可能遭批量攻击，后台启动紧急停采，只停最危险的超额部分，留 100 只继续采。__totalStopCount≥STOP_TRIGGER_ACT 或 __normalLineStopCount≥STOP_TRIGGER_ACT，且当前无紧急锁→打红色「紧急触发 原因，升级为紧急停采流程接管（修剪到 100）」，emergencyStopHarvest({trimTo:100}) 不 await；主流程继续，在锁协调处让路。只有无杀手警戒的这条路径带 trimTo，杀手监控等调用方不修剪。公开版仍为 HARD=36、ACT=42。触发：每轮分流后自动判断｜参数STOP_TRIGGER_HARD=100（公开版 36）；STOP_TRIGGER_ACT=106（HARD+6）；测试版 1.2.59 起两个常量在模块级（残留补停也读）｜来历0718 用户定案 25→36；0914 用户定案 36→80，分档 80→120→160 每档跑两夜——实测 36 时贪婪线从未生效、修剪停的是线下 1~2 点的 kami，线下池天花板约 150~160；0915~0917 三夜保留 80 零死亡后，0917 用户定案 80→100｜版本1.2.17；测试版1.2.57；测试版1.2.59
• 硬触发去重与异常隔离 — 已经有紧急锁时不重复触发；启动紧急停采时的同步或异步异常只记日志，不中断主流程。条件带 !hasEmergencyLock()；外层 try/catch 记「紧急停采启动失败」，.catch 记「紧急停采异常」。触发：硬触发时
• 杀手警戒中硬触发全撤不修剪测试线独有 — window.__killerDetected 为真（死亡监控发现我方被杀后置位）时，安全线候选只要 ≥6 只就硬触发，且不带 trimTo，把越线的全部撤下。打「紧急触发 杀手警戒中，安全线候选 N 只，升级为紧急停采流程接管（全撤，不修剪）」。触发：每轮分流后自动判断｜参数候选≥6（=TARGET_BATCH_MIN）｜来历0914 审查——切安全线那一刻候选从 0 跳到上百只，不够动手线会掉进普通停采路径（全局 maxAttempts=5 只发得出 5 批），够动手线又会被修剪留一堆在场｜版本测试版1.2.57
• 批量预警（超额不足 6 只）仅观测 — 候选超过 HARD 但不到 ACT 时只打一条预警，不硬触发，交给普通停采流程。当前线计数或普通线计数落在 (HARD,ACT) 时打「批量预警 停采线候选N只(>HARD)但超额<6，暂不硬触发…」，每轮最多一条。贪婪模式下普通流程按 30% 线，实际不会停这些 kami，等候选到 ACT 再修剪（测试版 1.2.59 起日志写明这一点）。触发：未硬触发且无紧急锁时｜参数STOP_TRIGGER_HARD=100（公开版 36）；STOP_TRIGGER_ACT=106（公开版 42）

API 批量停采

• STARVING 只喂不停 + 喂活转健康不停 — API 批量停采名单剔除仍饿死的 kami，以及喂食后血量已回到停采线以上的 kami。__apiNoStarv=apiList 过滤掉 isStarving 为真或 delta>1 的；有被剔除时打橙色「N 只 STARVING 已交喂食救援，本轮不停采（0血停不了采）」。触发：饿死救援之后｜来历0 血 kami 停采链上必 revert；喂活后血量健康的应继续采集｜版本1.2.26 / 1.2.27
• 停采随机切批 6~10 只 — 把待停名单切成每批 6~10 只的随机批次，批量落在 gas 甜区，随机大小也避免链上行为有固定指纹。chunkRandom(list,6,10)：总数≤10 一批装下（不足 6 也接受）；11 只也一批；更多时算批数、余数随机分到各批。触发：每轮 API 停采｜参数批量下限 6；上限 10
• 每批停采前紧急锁中断 — 每批 API 停采发出前检查紧急锁，有就中断剩余批次。hasEmergencyLock() 为真打「检测到紧急锁，中断普通停采」并 break。触发：每批前
• 退避重试批量停采 + 失败件交 DOM 兜底 — 每批用带退避重试的批量停采发出，最终仍失败的条目收集起来交给 DOM 兜底。打「批量停止/API - 第 i/N 笔 计划 x 个 → 列表」，await stopWithBackoff(batch,5)，返回值累加进 needDomAll。触发：每批｜参数退避重试上限 5 次

普通停采工具（AllowFailure + 退避重试）

• DOM 卡片采集中判断（不确定按未采集） — 在 Party 面板（eye-half 模式）的卡片列表里，按 imgNumber 找到卡片，读状态小图标，src 含 kami_harvesting 就算采集中。卡片找不到、图标读不到或出异常，一律返回 false（fail-open）。只适合做筛选（最坏少重试一只、下轮再捞），不能拿来打「已停」标记。触发：普通停采粗筛、复核、失败重试、残留收集时调用
• DOM 确证已停 _cardStopConfirmed（不确定不算已停）测试线独有 — 只有卡片找得到、状态图标读得到、图标不是 harvesting 三条同时成立，才确认这只 Kami 已停采。三种不确定（找不到卡、读不到图标、异常）全部返回 false（fail-closed），宁可少打一个标记下轮重新处理，也不误锁。触发：普通停采复核后决定是否 recordAction 时｜来历三态修复激活了原本是死代码的确认分支，旧的取反判据会把 DOM 抖动这种不确定当成已停去打标锁住，导致漏停被清算（风险不对称律：停采侧宁发勿漏）｜版本测试版1.2.41
• AllowFailure 容错批量停采 — 绕过游戏封装，直接调用停采 System 合约的 executeBatchedAllowFailure，一笔 TX 批量停采；某只失败时合约自动跳过，其余照常停，不整批回滚。返回三态：false=确定失败，null=待 state 复读裁决，true 只在 API 回退通道出现。触发：stopWithBackoff 每轮发送时调用｜来历普通批量调用只要一只失败就整批回滚连坐
• 合约句柄/target/签名器守卫，缺失回退 API测试线独有 — 停采合约句柄的 interface、合约地址 target、签名器任意一个不可用，就打警告并改走游戏自带 api.stop 回退通道。守卫同时检查 .interface 和 .target 和 signer。触发：_allowFailureStop 入口｜来历0911 审计：原守卫只看 interface 不看 target，句柄有 interface 却没 target 时会放行，发出一笔 to=undefined 的交易（等于部署合约）｜版本测试版1.2.35
• MUD 通道发送耗时观测（D4）仅观测 — 走 MUD 队列时，记录 enqueue 到 resolve 的耗时，打「本批经 MUD 队列发送(nonce统一) tx=前10位… mud enqueue+resolve=Xms」。只在拿到 tx 时打印。触发：mud 通道每次发送｜来历用实测数据裁决队列 resolve 的语义（拿 hash 还是等上链）｜版本1.1.19
• 发送前清单日志与 ID 调试输出仅观测 — 发送前打「[AllowFailure停采] N 个 → 清单」，并通过 dlog('api') 输出完整 harvestId 数组。触发：_allowFailureStop 每次发送前
• 空交易判失败 — 发送后拿到的 tx 为空时，打「[AllowFailure停采/返回空Tx]」并返回 false。触发：发送后
• 停采 gas 真值记账仅观测 — tx 非空后立即以动作 stop 登记到 gas 账本，mud 和 raw 两个分支都覆盖，之后由 reconciler 按 hash 补回执 gas。调用 _gasLedgerRecord('stop', harvestIds, tx)。触发：每笔普通停采 tx 发出后｜命令showGasReport()｜版本1.2.7
• 回执形状归一 — 不管队列返回的是带 wait 的 tx 还是直接是 receipt，都通过 _awaitStopReceipt 统一成 {receipt, hash, shape} 再判断。raw 分支的 tx 带 wait，走 wait()，行为与旧版逐字节等价。触发：tx 入队后确认阶段｜来历0710 停采事故：MUD 队列等上链才 resolve，返回的对象没有 .wait，旧码写死 tx.wait() 导致假失败｜版本1.1.21
• 回执形状未知或缺 gasUsed 转 state 复读（I2 红线） — 回执形状未知、没有回执或 gasUsed 为空时，无法按 gas 判级，本批不计成功也不计失败，返回 null，交由之后复读 state≠HARVESTING 裁决。待确认批数 __pendingVerifyBatchCount +1，打「回执形状未知/缺gas，转 state 复读裁决」。触发：确认阶段｜来历旧码缺 gas 时按 0 算，会被误判成 revert 级而记失败｜版本1.1.21
• 交易整体 revert 判定 — 回执 status 缺失不当失败；只有明确读到非 1 才判「交易上链但执行失败」，返回 false。raw 回执的 status 恒为 0/1，行为与旧版等价。触发：确认阶段
• gas 像全执行只观测、不作停成凭据 — 每只均摊 gas ≥ 120 万且估算执行只数 ≥ 全员时，只打黄色 gas 观察日志，返回 null，不据此判定已停，交由下轮复读 state 确认。估算执行只数 = round((gasUsed − 100000) / 1500000)；待确认批数 +1。判据和紧急停采 _emergencyConfirmBatch 同款双条件，两处必须一起改。单只真停约 1.54M/只会命中；单只 revert 约 261k/只落不到这里。触发：确认阶段 gas 判级｜参数GAS_FULL_EXEC_PER_KAMI=1200000（v1.1.14 从 800000 收紧）；GAS_REVERT_BASE=100000；GAS_PER_KAMI_ESTIMATE=1500000｜来历0709 审计：receipt.status===1 只说明交易没有整体 revert，已停或不可停的成员同样 status=1，旧版看到 status=1 就报成功是误报根因｜版本1.1.12 / 1.1.14 / 1.1.17
• revert 级 gas 判未生效 — 每只均摊 gas ≤ 30 万时，打「上链但未生效(revert级gas)，多半该 kami 已停，待索引器确认」，返回 false。触发：确认阶段 gas 判级｜参数GAS_FULL_REVERT_PER_KAMI=300000｜版本1.1.12
• 混合 gas 按未完全确认处理 — 均摊 gas 介于 revert 级和全执行之间时，打出均摊值和估算执行只数，按未完全确认返回 false，交调用方复核。触发：确认阶段 gas 判级｜来历多个 id 合发时，无法单从 gas 确认每个成员是否都生效｜版本1.1.12
• 发送失败与确认异常分开处理 — tx 已入队（进入确认段）之后才抛错的，返回 null 交 state 复读裁决，不记失败；入队之前抛错的才算真正发送失败，打「发送失败 全部 N 个未停采」并返回 false。用 reachedConfirm 标志区分，错误信息截取前 80 字。代码里确认异常日志的前缀写的是「[紧急停采/确认异常]」，实际位于普通停采函数中（文案沿用）。触发：_allowFailureStop 捕获异常时｜来历codex Q5#5：确认阶段偶发抛错曾被误记为失败并导致拉黑｜版本1.1.21
• API 回退停采 _apiStopOnceFallback — 合约句柄不可用时，改走游戏自带的 api.player.pet.harvest.stop 批量停采；成功打「批量停止/完成(API fallback)」返回 true，这是唯一会返回 true 的路径。api.stop 不存在时直接 throw；由于 _allowFailureStop 调它的位置在 try 之外，这个异常会一路冒出 stopWithBackoff 交给上层。空 tx 返回 false；tx 有 wait 就等上链，没有就固定等 15 秒兜底；调用异常打「API fallback失败」返回 false。发送前同样打清单日志并 dlog 输出 ids。触发：_allowFailureStop 守卫不通过时｜参数tx 无 wait 时固定等待 15000ms
• 普通停采入场静默期 — stopWithBackoff 一进来先等 5 秒，再检查清单并动手。清单为空也会先等满 5 秒再返回 []。触发：主循环判定有 Kami 达到普通停采条件后调用 stopWithBackoff｜参数STATE_CHECK_DELAY_MS=5000｜来历让链上和 UI 状态沉淀，拉开 TX 间隔，避免与其他交易抢 nonce
• 停采包队列与连续未收敛计数 — 整份停采清单作为一个「包」入队，每个包带 failStreak（连续未收敛次数），作为二分拆包的依据。队列元素结构为 {items, failStreak}，逐包 shift 处理。触发：stopWithBackoff
• 上链尝试轮数熔断 — 最多上链尝试 5 轮，用完后退出循环，进入残留逐只排查。只有真正发出 tx 才计一轮；包级跳过（无采集中、链上已无采集、无有效 harvestId）不消耗次数。触发：stopWithBackoff 循环｜参数maxAttempts=5（调大更执着，但失败场景多耗 gas）
• 每轮开头检查紧急锁并让路 — 每轮处理前先查紧急锁，命中就打「[TX锁] 检测到紧急锁，中断stopWithBackoff」立即退出，把 TX 通道让给紧急停采。代码实际：退出后，队列里剩下的包仍会进入末尾的逐只预检排查（会做预检、可能拉黑）。触发：stopWithBackoff 每轮开头｜来历紧急停采优先级最高（TX 双锁机制的一环）
• DOM 粗筛仍显示采集中 — 本包只保留界面上仍显示「采集中」的 Kami；一只都没有就打「本包已无 HARVESTING」跳过。用 _isCardHarvestingByImg 过滤。触发：每包处理时
• 发送前链上预检：已死/已停跳过 — 逐只查链上实时状态：已死亡打「链上已死亡，跳过」，休息中或状态不是 HARVESTING 打「链上已停采，跳过」。getByIndex 带 harvest 选项；状态比较用原始大写字符串 'HARVESTING'。触发：每包发送前
• 地块不匹配跳过并汇总警告 — 只停当前所在地块上的采集；Kami 在其他地块采集的跳过，本包末尾用橙色汇总「[地块不匹配] 当前地块: X，N 个kami在其他地块，已跳过: #编号(地块N)…」。当前地块或 Kami 采集节点号任一取不到时不拦截。触发：每包发送前预检｜来历防止误停其他地块的采集
• 停采冷却预筛 — 用本次已查到的 harvest.time.last 算剩余冷却，剩余大于 0 的本次跳过停采。冷却按 180 秒算；time.last 缺失或非正数按无冷却处理。注释说冷却解除后由主循环下一两轮重新捞；代码实际上，如果同包有其他成员发出了 tx，被冷却或跨地块跳过的成员在复核时仍在采，会随包回队，本函数内还会再试。触发：每包发送前预检｜参数KAMI_ACTION_COOLDOWN_SEC=180｜来历冷却中此刻发停采 tx 必败，跳过只是省一次必败 tx，不是永久拉黑，主循环间隔小于 10 分钟，不存在漏停风险｜版本1.1.11
• 冷却跳过日志防刷屏仅观测 — 冷却跳过不超过 8 只时逐只打「#编号 冷却剩余 Xs（time.last age=Ys）」；超过 8 只时只详细打前 5 只，其余合成一行样例，最后打统计「本批 N 只候选，M 只在冷却中已跳过（下轮重停）」。触发：本包有冷却跳过时｜参数逐只阈值 8 / 详细样例 5｜来历防刷屏｜版本1.1.11
• harvestId 兜底重刷 — 发送前、以及失败重试筛选时，用链上最新的 harvest.id 覆盖清单里的 harvestId。行内注释仍写「更新harvestId（可能变了）」，但板块头 0913 勘误已说明 harvestId 固定不变，这里只是防库记录缺失或损坏的兜底。触发：预检和失败重试筛选时｜来历0913 实测两账户 354 只在采 Kami、跨 2 个地块，与建库时存的值 100% 一致、0 例外，与 0709 实盘结论一致；原注释「重新部署后会变化」是错的，别据此写「不能缓存 harvestId」｜版本0913 实测勘误
• 预检查询失败保守保留 — 发送前查链上状态出错时，不跳过这只，照样加入发送清单。catch 分支直接 push。触发：预检查询异常时｜来历停采侧宁发勿漏
• 预检过滤结果处理 — 链上预检后全部被过滤掉就打「本包链上已无HARVESTING」跳过；数量减少时打「链上状态过滤: N → M」；有效 harvestId 全空就打「无有效harvestId，跳过本批」。harvestId 用 filter(Boolean) 去空。AllowFailure 通道下不做逐只 estimateGas 预检，坏个体由合约跳过。触发：每包发送前
• tx 发出后再次检查紧急锁 — 停采 tx 发出后立刻再查紧急锁，命中就打「停采Tx已发送，检测到紧急锁，跳过确认让路紧急停采」，不等确认直接退出。当前包已出队、不再回队；队列里其余包进入末尾残留排查。触发：每次发出 tx 后｜来历保证紧急停采永远优先占用 TX 通道
• 停采结果三态分流修复测试线独有 — 发送结果为 true 或 null（待确认）时都进入「沉降后复核」分支，只有 false 才走失败重试分支。true 打「API链上确认成功」；null 打「待确认…已上链(gas 特征像全执行)，等 25s 沉降后复核」。null 也可能来自回执形状未知或确认异常，这句文案在那些情况下并不准确。触发：每次发送返回后｜来历ChatGPT 审计 A11 + 0912 复核：raw 主通道从不返回 true，一批全部真停的标准结果是 null，旧的二态 if(ok) 让成功分支成了死代码，每次停采都掉进失败分支，5 秒后回队重发，最多白烧 4 次 gas｜版本测试版1.2.41
• 沉降后链上 + DOM 双重复核 — 等 UI 沉降后逐只复核：链上既不是休息也不是死亡，且 DOM 仍显示采集中，才算仍在采集。链上查询异常时 console.warn 并保守当作仍在采。遍历的是整包原始成员（包括预检时被跳过的）。触发：发送结果非 false 时｜参数UI_SETTLE_MS=25000
• 确证已停才登记动作标记测试线独有 — 只有 DOM 确证已停的 Kami 才 recordAction('stopHarvest') 登记防重复，并打「停采成功(API)：Kami #编号（img:x） Δ=」。用 _cardStopConfirmed 判断（不确定不算已停）；遍历整包，本来在预检前就已停的成员也会被登记并打成功日志；单只登记异常忽略。触发：复核阶段｜来历旧判据会把 DOM 不确定当作已停去打标锁住，锁期内不再处理，导致漏停被清算｜版本测试版1.2.41
• 未收敛回队重试 — 复核后仍在采集的，failStreak+1，打「UI未收敛 仍在采集 x/y → 清单」后回队；全部停下则打「最终确认成功」。不满足二分条件时整体回队，保留当前 failStreak，打「重试排队 回队 N 个」。触发：复核发现仍有采集中
• 二分拆包隔离坏个体 — 连续 2 轮未收敛且剩余不止 1 只时，把剩余清单对半拆成两个新包（failStreak 归零）分别回队，打「二分拆包 N → a + b」。复核分支和失败分支用同一套条件。触发：failStreak ≥ 2 且剩余 > 1 只｜参数二分条件 failStreak>=2 且包内>1（写死）｜来历把可能的坏个体隔离到更小的包里，逐步定位
• 发送失败后逐只核实真实状态 — 发送结果为 false 时，先打「API失败，正在查询真实状态」，逐只筛出真正还需要重试的：DOM 不显示采集中的直接剔除，链上不是 HARVESTING 的打「实际状态: X，跳过重试」；查询失败保守加入重试。全部被剔光就打「重试放弃 本包已无真正HARVESTING；不再回队」；否则打「重试筛选 原N个 → 真正需重试M个」，failStreak+1 后按二分规则回队，并打「回队 N 个（failStreak=x）」。触发：发送结果为 false 时｜来历避免二分拆包时「假采集中」的问题 Kami 反复污染重试队列
• 失败重试间隔 — 失败分支回队后等 5 秒再进入下一轮；成功复核分支不额外等待（已经等过 25 秒沉降）。触发：发送失败回队后｜参数RETRY_DELAY_MS=5000｜来历调小会提高 nonce 冲突概率，调大则整体停采变慢
• 残留逐只预检排查 — 循环结束后，把队列里 DOM 仍显示采集中的 Kami 收集起来，打「对 N 个未停采的kami逐个预检」，逐只用 _preCheckStop([harvestId]) 做模拟调用预检。没有 harvestId 的直接交给 DOM 兜底；预检通过的通过 dlog 记录后加入交 DOM 清单。触发：stopWithBackoff 循环结束（轮数用尽或因紧急锁中断）且有残留时｜来历找出真正卡住的个体
• 预检失败拉入停采黑名单 — 残留预检失败的 Kami，把 kamiId 加入停采黑名单并记下拉黑时刻，由外部逻辑按时限解封。写入 __stopBlockedKamis（Set）和 __stopBlockedTime（Map）；没有 kamiId 的只打「无kamiId，无法加入黑名单」。触发：残留预检失败且前端未冻结时｜来历防止无限重试
• 前端冻结时不拉黑、改下轮再处理 — 判定前端疑似失真（冻结）时，残留预检失败的 Kami 不加入黑名单，只打「前端疑似失真，不加入停采黑名单，defer 到下轮」。由 _isFrontendFrozen() 判断。被推迟的成员不进交 DOM 清单，但汇总日志仍把它算在「失败(已拉黑)」里。触发：残留预检失败且 _isFrontendFrozen() 为真｜来历前端冻结时预检和读数不可信，避免冤枉拉黑
• 预检汇总与交 DOM 兜底 — 有预检失败时打「预检结果 通过: N个(交DOM), 失败: M个(已拉黑)」；最终只把预检通过的清单返回给上层，走 DOM 点击兜底；没有残留则返回空数组。触发：stopWithBackoff 结束时

DOM 兜底停采

• 兜底名单合并、过滤与去重 — 把没有 harvestId 的候选和 API 失败件合在一起，只留仍在预警带且没饿死的，同一只不重复处理。[...domList,...needDomAll] 过滤 delta≤1 且 !isStarving；按 imgNumber|dbIndex 去重。触发：API 停采之后｜来历0 血点停采按钮同样无效｜版本1.2.26
• DOM 停采切批 + 每批紧急锁中断 — 兜底名单同样随机切成 6~10 只一批，每批前遇紧急锁就中断。chunkRandom(uniqDom,6,10)；hasEmergencyLock() 为真打「检测到紧急锁，中断DOM停采」break；非空批打「批量停止/DOM - 第 i/N 批」。触发：DOM 兜底停采｜参数批量 6~10
• 点击前双重确认仍在采集 — 点停采按钮前再查一次，链上和卡片都不显示采集中就跳过，避免对 API 路其实已停成功的重复操作。getByIndex 读 state，state 非 HARVESTING 且 _isCardHarvestingByImg 也为假才 continue（任一显示采集中就继续点）。触发：每只 DOM 停采前
• 模拟点击主按钮→面板→Stop Harvest — 找到卡片主按钮点开操作面板，1.2 秒后在面板里找到可见的 Stop Harvest 点下去，并记动作冷却。主按钮缺失打「DOM 停止找不到主按钮」跳过；simulateClick(主按钮,0)；1200ms 后取主按钮 closest div[cursor='pointer'] 父节点第 2 个子节点为面板，找不到打「找不到操作面板」；找文本为 Stop Harvest 且 offsetParent 非空的元素 simulateClick(…,1000)，recordAction(img,'stopHarvest')，打「停采成功(DOM)」。代码实际：成功日志在点击时就打出，不是链上确认；找不到只记日志不重试，交下轮再收集。触发：通过双重确认后｜参数面板等待 1200ms
• DOM 停采只间节流 — 每点完一只歇 0.8 秒，防止点击过快、面板来不及渲染。await delay(800)。代码实际：800ms 短于面板回调的 1200ms，下一只的主按钮点击会早于上一只的面板回调执行，时序交错。触发：每只 DOM 停采后｜参数只间 delay 800ms
• DOM 停采单只异常只记日志 — 某只点击停采出错时记日志继续下一只。catch 打「DOM 停止异常：错误」。触发：DOM 停采时

一键停采当前地块 stopCurrentRoom

• 一键停采当前地块命令 — 把本账户在当前所在地块上所有正在采集的 kami 一次性批量停采，按血量从低到高发送，停完方便换到别的地块采集。流程：查账户地块和 kami 列表 → 挑出 HARVESTING → 从 DOM 读实时 HP% → 10 路并发查 harvestId/采集地块 → 剔除其他地块、查不到 harvestId 的和冷却中的 → 按 HP 升序 → 加紧急锁 → 每批随机 6~10 只用 AllowFailure 停采，批间隔 6.5 秒 → 汇报，并暂停自动部署 10 分钟。触发：命令（纯手动，不会自动触发）｜参数CONC=10；chunkRandom(6,10)；批间隔 6500ms｜命令stopCurrentRoom() 执行；resumeDeploy() 提前结束停采后的 10 分钟部署暂停
• 与紧急停采共用运行标志防重入 — 紧急停采或另一个一键停采正在跑时，直接拒绝本次调用，提示稍后再试。window.__emergencyStopRunning 为真就打日志返回；否则置真，finally 里无条件清掉。紧急停采、一键停采、转移停采共用这个标志，互斥运行。触发：调用 stopCurrentRoom() 时｜来历互斥运行，防止 nonce 冲突
• 读账户地块失败或地块未知即放弃 — 用操作员地址查账户的当前地块和 kami 列表；查询出错，或者地块号读不到，都直接放弃不发 tx。connectedAddress.value_ → accounts.getByOperator 取 roomIndex 和 kamis（非数组按空数组处理）；异常打「获取账户信息失败」返回，roomIndex==null 打「当前地块未知，放弃」返回。触发：stopCurrentRoom 第 1 步
• 当前地块名日志仅观测 — 在日志里打印当前地块的名字和编号。__getRoomNameByIndex 取名，取不到时显示 #编号。触发：stopCurrentRoom 第 1 步之后
• 只挑采集中的 kami，没有就直接结束 — 只处理 state 为 HARVESTING 的 kami；一只都没有时打「无需停采」然后结束。state 转成大写后比较 HARVESTING。触发：stopCurrentRoom 第 2 步
• 从 DOM 读实时 HP%（图片编号→卡片映射） — 先扫一遍 Party 列表卡片，建立「图片编号→卡片」的映射，再按图片编号读卡片上的实时 HP 百分比，作为排序依据。卡片选择器 div#party>div>div:nth-of-type(3)>div:nth-of-type(2)>div:nth-of-type(2)>div；从 img[src*=/kami/] 提取编号；状态小图标 img[src*=/assets/kami_] 的下一个兄弟节点就是 HP 文本「123/456 (78%)」，取括号里的百分比。触发：stopCurrentRoom 第 2~3 步｜来历API 的 stats.health.sync 是链上同步值，有滞后；UI 上的 HP% 是客户端实时算出来的
• DOM 读不到 HP 时按满血排最后 — 某只 kami 在 DOM 里读不到 HP% 时，当作 100% 处理，排到最后停，不挤占危险 kami 的优先位置。_readHpPctFromDom(imgNumber) ?? 100；查询异常时 hpPct 也记为 100。触发：并发查详情时｜来历保守处理，不挤占危险 kami 的优先级
• 10 路并发查单只详情 — 开 10 个 worker 共同消费一个队列，逐只查 harvestId、采集地块号和图片编号，顺便算出冷却剩余时间。共享下标 nextI，Promise.all 同时启动 10 个 workerLoop；getByIndex(index,{harvest:true}) 取 harvest.id、harvest.node.index、image、harvest.time.last。触发：stopCurrentRoom 第 3 步｜参数CONC=10（调大查得快但节点压力大）｜版本v1.1.11
• 详情查询异常的 kami 被静默丢弃 — 某只 kami 查详情抛异常时，既不停采，也不出现在「其他地块」或「查不到 harvestId」的提示里。注释说查不到 harvestId 的会跳过并列出；代码实际上异常时 nodeIdx 记为 null，这种项三个分流条件都不满足（要么要求 nodeIdx===当前地块，要么要求 nodeIdx!=null），所以不会进任何名单，也没有日志。触发：分流时
• 其他地块的采集中 kami 只提示不处理 — 在别的地块采集的 kami 本命令不停，只在日志里列出来。条件 nodeIdx!=null 且不等于当前地块；最多列 10 个「#编号(地块N)」，超过 10 个加省略号。触发：stopCurrentRoom 第 4 步
• 查不到 harvestId 的跳过并列出 — 在当前地块、但查不到 harvestId 的 kami 跳过不停，把编号全部列在日志里。条件 nodeIdx===当前地块 且 harvestId 为空。触发：stopCurrentRoom 第 4 步
• 180 秒操作冷却预筛 — 还在 180 秒操作冷却里的 kami 从本批剔除，这次不发 tx。只是跳过，不拉黑。用同一次查询拿到的 harvest.time.last 算 _cooldownRemainSec，大于 0 就剔除；读不到 time.last 按无冷却处理，回到旧行为。冷却解除后，下次手动调用或自动化主流程（10 分钟内扫一次）会重新捕获。触发：stopCurrentRoom 第 4 步之后｜参数操作冷却 180s｜来历冷却中发停采 tx 必败；跳过只是省一次必败 tx，不会永久漏停｜版本1.1.11
• 冷却预筛日志防刷屏仅观测 — 冷却中的 kami 少时逐只打印；超过 8 只时只打印前 5 只的详情，其余合成一行样例，最后再给一句汇总。showN = 数量>8 ? 5 : 数量；逐条日志包含冷却剩余秒数和 time.last 距今多少秒。触发：冷却预筛命中时｜参数阈值 8 只 / 样例 5 只｜版本1.1.11
• 没有可停的 kami 时友好结束 — 剔除后当前地块没有要停的 kami，就打一句完成然后结束；如果是因为冷却才剩 0 只，会注明「扣除冷却中的以外」。inThisRoom.length===0 时 return（此时还没加锁）。触发：冷却预筛之后
• 按 HP% 升序、危险优先停 — 血量最低、最接近被清算的 kami 最先停，日志显示本批 HP 范围。inThisRoom.sort((a,b)=>a.hpPct-b.hpPct)。触发：stopCurrentRoom 第 5 步｜来历越低越危险，优先停
• 发 tx 前加紧急锁，只释放自己加的锁 — 开始发停采 tx 前设置紧急锁，让 runAutomation 主循环暂停让路；结束时只在自己确实加过锁的情况下才释放。setEmergencyLock() 后 emergencyLockSet=true，finally 里 if(emergencyLockSet) releaseEmergencyLock()。和紧急停采不同，这里不等普通锁释放，也不设 __kamiOperationInProgress。触发：stopCurrentRoom 第 6 步｜参数主循环见到紧急锁最长等 300 秒（注释所写）｜来历防止与主流程的 tx 撞 nonce
• 每批随机 6~10 只分批 — 待停的 kami 按每批 6~10 只随机分组发送。chunkRandom 先算出最少批数，保证每批不少于 6 只再均匀分配，零头随机分散；总数不超过 10 时一批发完。触发：stopCurrentRoom 第 7 步｜参数chunkRandom(inThisRoom,6,10)｜来历避免固定节奏的批量 tx 被识别为机器人
• AllowFailure 批量停采，返回 true 直接计成功 — 每批用容错批量停采发一笔 tx，返回值严格为 true 时整批计为成功。_allowFailureStop(harvestIds, fmt)；日志列出每只的 #编号(HP%)。触发：逐批
• 三态沉降等待（已上链等 25 秒 / 真失败等 5 秒）测试线独有 — 批次返回不是 true 时先等一会儿再核查：返回 null（tx 已上链、等确认）等 25 秒，返回 false（真失败）等 5 秒。__settle = ok===null ? UI_SETTLE_MS : 5000；两种情况日志文案不同（🟡已上链待确认 / 🔄整批失败）。raw 主通道下 ok 永远不是 true，所以每批都会走这个分支。触发：批次返回非 true 时｜参数UI_SETTLE_MS=25000；真失败等待 5000ms｜来历索引器确认滞后实测 17~99 秒，旧版只等 5 秒时状态还没翻过来，就把已停的又发了一遍｜版本测试版1.2.41
• 核查后只重发仍在采集的 — 等待结束后逐只查链上状态，只留下仍是 HARVESTING 的去重试，并换上最新的 harvestId。逐只 getByIndex；state 为 HARVESTING 时取 res.harvest.id（取不到用旧的）加入 stillNeed。触发：沉降等待之后｜来历第一次 tx 可能部分成功，不重发已停的，免得浪费 gas
• 核查时查询失败保守保留 — 核查阶段某只 kami 查询出错时，保守地把它留进重试名单。catch 分支里 stillNeed.push(d)。触发：核查阶段｜来历宁可多试一次，也不能漏停
• 核查结果：全部已停或部分已停计入成功 — 核查发现全部已停，就整批记成功不重试；只停了一部分，就把已停数计入成功，只重试剩下的。stillNeed 为空时 totalOk += 整批数量；数量少于整批时 totalOk += 差值，并打「核查后 N 只已停，剩 M 只重试」。触发：核查之后
• 只重试一次，仍失败交给主循环 — 对剩下的 kami 再发一次批量停采；这次还失败就不再坚持，留给下一轮 runAutomation 自动处理。retryOk 为真值才计成功。注释说失败才计失败；代码里 if(retryOk) 只认真值，返回 null（已上链待确认）也会被记成「重试仍失败」计入 totalFail，没有二次核查。触发：核查后仍有未停｜来历重试后仍失败不再死磕，下一轮常规流程会兜底
• 批间隔 6.5 秒 — 两批之间固定等 6.5 秒，最后一批发完不等。bi < batches.length-1 时 delay(6500)。触发：每批之后｜参数delay(6500)｜来历避免连续 tx 撞 nonce 或触发限流
• 完成汇报仅观测 — 用绿色大字打印成功数/总数、失败数和总耗时（毫秒加分秒两种写法）。_fmtMinSec(elapsedMs)。触发：全部批次结束
• 停采后暂停自动部署 10 分钟 — 停完后自动部署暂停 10 分钟，给转移或换地块留出时间；日志显示到几点恢复，并提示可以用命令提前恢复。_pauseDeployAfterStopAll('一键停采') 设置 window.__deployPausedUntil=现在+10 分钟，按配置时区显示 HH:MM；成功数为 0 时也会触发。触发：汇报之后｜参数DEPLOY_PAUSE_AFTER_STOPALL_MS=10 分钟｜命令resumeDeploy() 立即清零暂停，下一轮恢复自动部署｜来历防止刚停的 kami 又被自动部署回去
• 可以去其他地块的提示仅观测 — 至少停成 1 只时，用青色大字提示当前地块的 kami 已停采，可以去别的地块采集了。totalOk>0 时打印。触发：汇报之后
• 异常兜底 — 整个流程中出现任何未捕获异常都只打日志；锁和运行标志照常清掉。catch 打「[一键停采] 异常」，finally 释放锁、清标志。触发：异常时

转移停采 stopMinorityForTransfer

• 转移停采命令 — 配合多账户分工：每个账户只专注一种地块类型（主流），其他类型（少数派）的 kami 要转给对应账户。本命令把本账户所有正在采集的少数派 kami 批量停采，再按目标地块类型分组打印可转移清单，照着清单用游戏内转移功能发送即可。流程：取分类 → 分出 HARVESTING 和 RESTING → 读 DOM HP% → 并发查 harvestId → 按 HP 排序 → 加锁 → 冷却预筛 → 第一轮全部发 → 等 60 秒核查 → 第二轮重试 → 等 8 秒最终核查 → 汇报、暂停部署、失败名单、可转移清单。和 stopCurrentRoom 的区别是按非主流类型筛，不按当前地块筛。触发：命令（纯手动）｜参数CONC=10；chunkRandom(6,10)；批间隔 6500ms；COOLDOWN_WAIT_MS=60000；终核等待 8000ms｜命令stopMinorityForTransfer() 执行，失败后可重复调用，只处理仍在采集的；syncKamiDb() 同步本地精简数据库；resumeDeploy() 提前结束部署暂停
• 防重入 — 紧急停采或一键停采正在运行时拒绝执行。window.__emergencyStopRunning 为真则打日志返回；和紧急停采、一键停采共用这个标志，finally 里清除。触发：调用时｜来历与紧急停采互斥
• 检查辅助脚本接口是否可用 — 辅助脚本没加载、版本太旧、拿不到少数派数据时，直接红字报错退出，不做半吊子降级。typeof window.__getMinorityKamis !== 'function' 时打两行红字（提示先确认辅助脚本已开启并加载完成）然后返回。这是跨脚本全局接口约定。触发：调用时｜来历不做半吊子降级
• 按目标地块类型分组、着色打印转移清单仅观测 — 把 kami 按目标地块类型分组，每组一种颜色，列出全部编号；超过 25 个自动换行，方便完整复制不遗漏。_printByTarget：按 terrain 分组；颜色 normal 灰 #9e9e9e / eerie 紫 #c678dd / scrap 橙 #e5a13a / insect 绿 #4ec94e（和辅助脚本 kamiAnalyze 同色系），未知类型用灰色；标题写「N 只 → 转给 XXX 主流账户」。触发：打印 RESTING 清单或最终可转移清单时｜参数PER_LINE=25；TERRAIN_COLORS｜来历单行过长不方便复制；按类型着色，转移时不容易看混
• 取分类结果失败即放弃 — 调用辅助脚本接口取主流/少数派分类，出错就放弃。await window.__getMinorityKamis()，返回 {majority, majorityCount, minorityKamis, excludedKillers}；抛异常时打日志返回。触发：第 1 步
• 识别不出主流类型时提示先同步数据库 — 本地精简数据库为空、识别不出主流类型时放弃，并提示先运行同步命令。!r.majority 时打「无法识别 majority（db 可能为空，先运行 syncKamiDb()）」然后返回。触发：第 1 步｜命令syncKamiDb()
• 主流/少数派统计日志仅观测 — 打印主流类型名、主流 kami 数量和少数派数量。青色加粗。触发：取到分类后
• 杀手保护：担任杀手的 kami 不转走 — 担任杀手职责的 kami 不会被本命令停采转走，日志会说明排除了几只。过滤在辅助脚本 __getMinorityKamis 内部完成，本处只根据 excludedKillers.length 打「🛡️ 杀手保护」日志。触发：取到分类后
• 少数派没有在采集的，直接给出 RESTING 转移清单 — 少数派里没有 HARVESTING 时不发任何 tx：有 RESTING 的就直接打印「已可立即转移」清单；连 RESTING 都没有就说明全是死亡或升级中等状态，无可操作。minHarvesting.length===0 时分支，结束后 return。触发：第 2 步
• 从 DOM 读实时 HP%（和一键停采同款） — 建立图片编号到卡片的映射，读卡片上括号里的实时 HP%，用来排序。选择器和解析逻辑与 stopCurrentRoom 完全一致；读不到按 100 处理。触发：第 3 步｜来历UI 实时值比链上同步值新
• 10 路并发查 harvestId — 10 个 worker 并发查每只少数派 kami 的 harvestId 和图片编号；查询失败的 harvestId 记为空。getByIndex(index,{harvest:true})；异常时记 {harvestId:null, hpPct:100}，同时带上 terrain。触发：第 4 步｜参数CONC=10
• 查不到 harvestId 的跳过，全都查不到则放弃 — 查不到 harvestId 的列出编号后跳过；一只都查不到时整个命令放弃。stoppable=有 harvestId 的，missingId=没有的；stoppable 为空时返回（此时还没加锁）。触发：第 5 步
• 按 HP 升序、危险优先 — 血量低的少数派先停，日志显示 HP 范围。stoppable.sort 按 hpPct 升序，和 stopCurrentRoom 顺序一致。触发：第 5 步
• 紧急锁（在冷却预筛之前就加） — 冷却预筛和发 tx 前先设置紧急锁，让主循环让路；finally 里只释放自己设的锁。setEmergencyLock()，emergencyLockSet=true。锁在冷却重查（10 路查询）之前就已加上；全部冷却中提前 return 时也由 finally 释放。触发：第 6 步
• 首轮发送前重新查一次，做冷却预筛 — 第一轮发 tx 前再并发查一次 time.last，把仍在 180 秒冷却里的 kami 剔出首轮。只是跳过，不拉黑。单独再开 10 路 cdWorker 查询，保证数据新鲜（第 4 步到这里可能已过了几秒到十几秒）；查询失败时 remain=0，回到旧行为。触发：第 6.5 步｜参数CONC2=10；冷却 180s｜命令stopMinorityForTransfer() 冷却解除后重调｜来历冷却中发停采 tx 必败；本命令设计上就是失败后重复调用、只处理仍在采集的｜版本1.1.11
• 冷却预筛日志：带预计解除时刻，并防刷屏仅观测 — 逐只打印冷却剩余秒数、time.last 距今秒数和预计几点解除；超过 8 只时只详列 5 只，其余合成一行样例，最后给汇总。clearAt = 现在 + remain 秒，toLocaleTimeString 显示。触发：冷却预筛命中时｜参数阈值 8 / 样例 5｜来历记录首轮预测的解除时刻，方便事后核对｜版本1.1.11
• 全部在冷却中时提示稍后重调 — 候选全部在冷却里时，本次不发任何 tx，提示稍后再调一次。readyNow.length===0 时 return；不会触发暂停部署。触发：冷却预筛之后｜命令stopMinorityForTransfer()｜版本1.1.11
• 第一轮全部发送，不假设成功 — 把所有能停的少数派按每批 6~10 只全部发出去，不看返回值，成功与否以之后的链上核查为准。chunkRandom(readyNow,6,10)；await _allowFailureStop 但不接返回值；批间 delay(6500)；日志写「#编号(→目标类型)」。批内不再做「发完等 5 秒立即重试」，统一留到第 8 步处理。触发：第 7 步｜参数批间隔 6500ms｜来历容错批量模式下部分 kami 可能因冷却没停成，要以链上结果为准
• 等 60 秒后核查链上真实状态 — 第一轮发完固定等 60 秒，再逐只查链上状态，仍在采集的进入第二轮（换上最新 harvestId）。COOLDOWN_WAIT_MS=60000 之后逐只顺序 getByIndex。注释已更正：冷却实测 180 秒，60 秒小于 180 秒，二轮仍可能撞上冷却，靠第 6.5 步预筛降低概率，剩下的靠失败提示引导重调。触发：第 8 步｜参数COOLDOWN_WAIT_MS=60000｜来历冷却实测 180 秒（0708 定案），不是旧估计的「最长约 3 分钟 / 60 秒覆盖大部分」｜版本v1.1.11
• 一轮核查时查询失败保守进二轮 — 第一轮核查中查询出错的 kami 保守地放进第二轮重试。catch 时 stillH.push(d)；之后打印「已停采 X/Y，剩 N 只需二轮」。触发：一轮核查
• 第二轮批量重试一次，等 8 秒最终核查 — 只对仍在采集的再批量发一次，等 8 秒后做最终核查；这次查询出错的保守计为失败。chunkRandom(stillH,6,10)，批间 6.5 秒；delay(8000) 后逐只 getByIndex，仍 HARVESTING 或查询异常的都进 finalFailed。触发：第 9 步（一轮核查后仍有未停）｜参数delay(8000)｜来历宁可让用户多跑一次，也不能把没停的当成可转移
• 两轮战果汇报仅观测 — 根据链上真实状态汇报「第一轮 X + 第二轮 Y = 总数/候选数」，或者「一轮全部成功」，再加失败数和耗时。分母是 readyNow（实际发过 tx 的）。触发：第 10 步
• 停采后暂停自动部署 10 分钟 — 停完后开一个 10 分钟的转移窗口，这段时间不自动部署。_pauseDeployAfterStopAll('转移停采')。触发：汇报之后｜参数10 分钟｜命令resumeDeploy()｜来历防止刚停的 kami 又被自动部署回去
• 失败名单和重跑建议仅观测 — 两轮后仍没停的 kami 用红字列出（带目标类型，每行 25 个），并建议等 2~3 分钟再调一次命令。失败原因写的是可能仍在 180 秒冷却内、链上拥堵或其他问题。触发：totalFail>0｜参数PER_LINE=25｜命令stopMinorityForTransfer()｜来历措辞已同步为实测的 180 秒冷却，不再写旧估计的「cooldown > 3 分钟」｜版本v1.1.11
• 可转移清单（原本 RESTING 的 + 本次真正停成的） — 最后打印可以转移的少数派清单：原本就在休息的，加上本次经链上核查确认停成的；并提示等约 30 秒让链上同步后再用游戏内转移功能发送。successfullyStopped 从 readyNow（实际发过 tx 的）里去掉 finalFailed，而不是从 stoppable 里去；再映射回 minorityKamis 的原始条目。触发：汇报末尾｜来历冷却预筛剔除的 kami 从没发过 tx、仍在采集，如果误用 stoppable 会把它们也当成停采成功列进清单｜版本v1.1.11
• 不写停采黑名单 — 转移停采失败不会把 kami 拉进停采黑名单。本函数全程不调用任何失败计数或拉黑记账函数（板块说明所写的设计）。触发：始终｜来历转移停采的失败是临时性的（冷却、链上拥堵），不应该像常规停采失败那样拉黑
• 异常兜底 — 未捕获异常只打日志；finally 释放自己设的锁并清运行标志。catch 打「[转移停采] 异常」。触发：异常时

1.4 紧急停采

emergencyStopHarvest 只停血量触及停采线（≤ 停采线 +1%）和正在饿死的 kami，健康的不动。触发来源有四个：杀手监控发现杀手靠近（见 4.5）、主循环候选多到异常的硬触发（见 1.3）、死亡监控发现有 kami 死亡（见 1.13）、手动在控制台调用。

入口与总流程

• 控制台命令 emergencyStopHarvest — 把紧急停采入口挂到 window，可在浏览器控制台手动立即跑一轮完整紧急停采：DOM 扫描、凑批、批量发送、链上复核、cooldown 重试。触发：命令｜命令emergencyStopHarvest()｜来历方便控制台测试和手动救急
• 紧急停采设计要点总述 — 板块注释总述紧急停采策略：每批随机 6~10 只；并行发送不等 tx.wait() 先抢时间窗口；用链上 API 查询确认结果；无 harvestId 先补查；失败≥10 走 API 整批重试、少量走 DOM 兜底；RPC 超时先查链上状态再决定是否重发。本段只是注释总述，具体实现在紧急停采主流程（不在本段范围，未在此核实）。触发：紧急停采时｜来历gas 飙升时大批量易整批 revert，随机批量错峰提高成功率；盲目重试可能两笔都上链，双倍 gas 甚至 nonce 冲突
• 紧急停采主入口 — 扫描页面上所有采集中的 kami，找出血量已跌破或逼近停采线的，按凑批省 gas 的策略批量停采；饿死的先喂食救援。delta = 当前 HP% − 停采线，越负越危险。流程：DOM 扫描 → STARVING 可疑重扫 → 剔除退避队列成员 → 可选修剪 → 凑批决策 → 分级日志 → 链上预检 → 加锁、等普通锁、等喂食排空 → 喂 STARVING → 剔除 STARVING 后二次预检 → 冷却预筛 → 最多 3 轮「门禁 → 背靠背发送 → 并行确认 → 首批强化 → 动态等待 → 复读」→ 冷却收尾 → 汇总 → finally。opts.trimTo 只有硬触发路径会传。触发：自动：危险 HP 监控、杀手监控、批量硬触发（传 {trimTo:25}）调用，也会被盲扫重试 setTimeout 调用｜参数EMERGENCY_CONFIG（CRITICAL_DELTA=-20 / HIGH_RISK_DELTA=-10 / DANGER_DELTA=0 / MAX_ROUNDS=3 等）｜命令无独立命令
• 防重入：已在运行就跳过 — 同一时刻只允许一个紧急停采实例运行，重复调用直接跳过。window.__emergencyStopRunning 为真时打「已在运行中，跳过」并返回；否则置真，finally 里无条件清除。触发：每次调用
• 被跳过的全撤请求自动补撤测试线独有 — 不带 trimTo 的全撤请求（杀手监控/死亡监控/手动）撞上正在跑的一轮时，记到 window.__pendingFullEvac（次数+时间）并打「已在运行中，跳过（本次是全撤请求，已记待办…）」；当前轮 finally 释放锁后 1 秒自动再调一次 emergencyStopHarvest()（不修剪），打「[紧急停采/补撤] 本轮运行期间有 N 次全撤请求被跳过…」。修剪请求撞上照旧丢弃不记。触发：重入被拒时记、本轮结束时补｜参数延时 1s｜来历0914 全库「已在运行中，跳过」805 次，含同房间杀手告警撞上修剪被吞的样本；保留数抬高后单轮更长、被吞窗口更大｜版本测试版1.2.57
• 启动时刷新前端冻结信号 — 每次紧急停采开始时先刷新一次前端冻结判断，供后续的冻结门闩读取。window.__evalFrontendFrozen 存在就调用，出错静默吞掉。触发：每次调用开头｜版本v1.1.25
• 「kami 操作进行中」全局标记 — 紧急停采运行期间设置一个全局标记，供其他模块避让。开始时 window.__kamiOperationInProgress=true，finally 里置 false。触发：每次调用
• 调用级状态重置 — 每次调用都把去重、熔断、卡链、成功集、冷却队列和各项统计清零，让本次的记账和上一次互不干扰。__stopInvocationId++；清零 __stopConsecutiveRevertBatches、__stopCircuitBroken；清空 __stopStuckThisInvocation、__stopConfirmedThisInvocation、__stopCooldownDeferredThisInvocation；__pendingVerifyBatchCount=0、__stopChanFallbackCount=0；清空 tx 确认耗时和索引滞后样本、revert 原因去重集、群体滞后日志标记。__stopPendingVerify（退避复读队列）跨调用保留，不清。触发：每次调用开头｜来历熔断计数、疑似卡链名单只在单次调用范围内生效｜版本1.1.12 / 1.1.14 / 1.1.17 / 1.1.19 / 1.1.22
• 没有要停的就直接返回 — 扫描结果为空时打「没有需要停采的 kami」然后返回，不加锁。stopList.length===0 时 return。触发：第 1 步
• STARVING 过多时防误判：等 5 秒重扫 — 首次扫描发现超过 10 只饿死时，怀疑页面没加载完，等 5 秒重扫一次，以重扫结果为准；重扫后仍然很多就当作真的大规模饿死继续处理。重扫后 STARVING 数下降打绿色「以最新结果为准」，没下降打「可能确实发生大规模饿死」；重扫结果为空则返回。触发：首次扫描 STARVING 数 > 10｜参数SUSPICIOUS_STARVING=10；等待 5000ms｜来历大量 STARVING 通常是网页没加载好、HP 文本解析成 0%，要避免误停一大批健康 kami
• 剔除已在退避确认队列的 kami，不重发 — 已经发过停采、正在等索引器追上的 kami，本轮不再重发。kamiId 在 __stopPendingVerify 里的从 stopList 移除，日志最多列 12 个编号；全部被剔除时返回。真没停的由 estimateGas 裁决快速放回候选。整段 try/catch 包住，出错不影响主流程。触发：扫描之后、修剪之前｜来历对已停的 kami 重发必然 revert 白烧 gas（0711 实测 24 批浪费全出在这里）｜版本1.2.1
• 危险分级统计日志仅观测 — 按 delta 把名单分为极危、高危、危险、一般四档并打印数量，只用于展示。≤-20 极危；-20~-10 高危；-10~0 危险；>0 一般。触发：凑批放行后｜参数CRITICAL_DELTA=-20，HIGH_RISK_DELTA=-10，DANGER_DELTA=0
• 延迟加锁，只释放自己加的锁 — 扫描、凑批、预检全程只读不加锁，确认确实有停采目标后才设置紧急锁；finally 里只在本次加过锁时才释放。setEmergencyLock()，emergencyLockSet=true；finally 中 if(emergencyLockSet) releaseEmergencyLock()。触发：第 4 步｜来历把紧急锁的占用时间压到最短，也避免误释放其他流程持有的锁
• 加锁后等普通锁释放（最多 30 秒） — 加锁后如果普通操作还占着锁，等它把当前这笔 tx 做完，最多等 30 秒。window.__txNormalLock 存在时打出占锁的脚本名和操作名，然后 waitForNormalLockRelease(30000)；返回值没人接，超时照样往下走。触发：加锁后｜参数30000ms｜来历普通操作检测到紧急锁会主动让路，避免 nonce 冲突
• finally 兜底清理 — 不论成功、失败还是提前 return，最后都释放本次加的紧急锁，并清掉「操作进行中」和「运行中」两个标记。if(emergencyLockSet) releaseEmergencyLock()；__kamiOperationInProgress=false；__emergencyStopRunning=false。触发：每次调用结束｜来历避免误释放其他流程持有的锁

DOM 扫描、列表打开与盲扫守卫

• 扫描前先判断 DOM 是否就绪测试线独有 — 扫描卡片前先确认页面 DOM 可读：卡片不为 0、不完整比例不超过一半、数量没有低于历史峰值的 10%；未就绪就每 3 秒重扫，最多 6 次，期间最多主动打开一次 Party 列表或切换眼睛状态。__emergencyScanWithDomGuard('首次扫描') 返回 {ready, list, reason}；判断不要求主按钮存在（列表折叠时血量仍可读）。阈值和主循环同源，改一处必须同步另一处。触发：第 1 步，以及 STARVING 可疑重扫时｜参数MAX_TRIES=6，GAP_MS=3000，DOM_INCOMPLETE_THRESHOLD=0.5，SCALE_ANOMALY_RATIO=0.1（历史峰值≥20 才判断）｜存储kami_last_known_count（读，历史卡片峰值）｜来历读不到卡片时绝不能报「没有需要停采」｜版本测试版1.2.51
• 盲扫告警与自动重试测试线独有 — 页面没就绪时红字大写说明「本次无法判断，这不是没有需要停采」，20 秒后自动再调一次紧急停采，连续最多 3 次；只要读到了真实 DOM，计数就清零。__scheduleEmergencyBlindRetry(opts, reason)：window.__emergencyBlindRetryCount 达到 3 次就停止自重试，交给下一轮杀手监控或主循环，并提示检查 Party 列表是否展开；否则 setTimeout 20 秒后重调，带原 opts。触发：DOM 预检未就绪时｜参数MAX=3，RETRY_MS=20000｜来历读不到卡片时绝不能报「没有需要停采」｜版本测试版1.2.51
• Kami 列表折叠判定 __isPartyListClosed测试线独有 — 判断 Party 列表是不是折叠或还没打开：div#party 计算样式为 display:none，或者元素不存在，都算没打开。getComputedStyle 抛错时按已打开处理（返回 false）。触发：__ensurePartyListOpen 和 DOM 预检调用｜来历0914 探针：刷新后 94 秒、启动流程还没点开列表时，#party 是 display:none，只有 1 张卡、读不到血量、眼睛=open，于是每次刷新后约 2~3 分钟紧急停采读不到血量｜版本测试版1.2.53
• 按状态打开 Kami 列表 __ensurePartyListOpen测试线独有 — 列表折叠时才点 Party 按钮展开（点完等 2.5 秒）；眼睛不在 half 时才点眼睛切换（最多点 3 下，每下等 1.5 秒）。返回本次有没有真的动过手，有的话调用方立刻重扫。找不到 Party 按钮（游戏页没就绪）直接返回 false；点过眼睛后再等 1 秒复读，还不是 half 只记日志，不再点（启动路径另有 waitForEyeHalf 兜底）。触发：启动流程、主循环 DOM 修复、紧急停采 DOM 预检共三处调用｜来历Party 按钮和眼睛都是开关，盲点会把已经打开的点关。1.2.51 为此干脆不点，1.2.53 改为先读状态再点｜版本测试版1.2.53
• 打开列表三方串行锁 window.__ensurePartyInFlight测试线独有 — 同一时刻只允许一个调用方在点列表开关。后来的先等前一个做完，再按当前状态重新判断；判据是幂等的，不会重复点。最多循环等 5 次；把当前任务挂到 window.__ensurePartyInFlight，finally 里只清除自己挂的那个任务。触发：__ensurePartyListOpen 每次调用｜来历三处调用同时盲点开关会把列表点关｜版本测试版1.2.53
• DOM 不完整计数 __countIncompleteDom（requireButton 选项）测试线独有 — 统计有多少张卡片不完整：缺状态图、缺「(NN%)」血量文字、缺 kami 编号、缺主按钮，任一即算。紧急停采传 requireButton:false，不把缺主按钮算作不完整。默认仍要求主按钮，因为主循环要点按钮（DOM 兜底部署/停采）；紧急停采只走 API 发交易，从不点按钮。触发：主循环 DOM 预检、紧急停采 DOM 预检｜来历0913 23:34 探针：列表折叠时 313 张卡的状态图、血量、编号都还在，只有主按钮不渲染。不加这个选项，列表一折叠紧急停采就整晚「无法判断」，一只都不停（0913 23:23、23:28 实录）｜版本测试版1.2.52
• 紧急停采 DOM 就绪预检 __emergencyScanWithDomGuard测试线独有 — 扫描前先判断页面有没有准备好。三个条件同时满足才算就绪：卡片数>0、不完整占比≤50%、规模不低于历史峰值的 10%（峰值≥20 时才判规模）。就绪才调 _emergencyScanKamis。判据逐字照搬主循环 DOM 预检，另加一条主循环没有的「卡片数>0」（主循环 0 张卡时占比算 0，历史峰值<20 会被放行）。常量与主循环同值，注释要求改一处必须同步另一处。触发：emergencyStopHarvest 首次扫描、STARVING 可疑重扫｜参数DOM_INCOMPLETE_THRESHOLD=0.5; SCALE_ANOMALY_RATIO=0.1｜存储kami_last_known_count（只读，历史规模峰值）｜来历0913 14:48:18 杀手监控拉起紧急停采时页面还没就绪：匹配 div 数=0，却报「没有需要停采的kami」，而前后两次扫描实际分别需停 2 只和 6 只。停采侧 fail-open，正好违背「宁发勿漏」｜版本测试版1.2.51 紧急停采盲扫修复
• 预检未就绪：每 3 秒重扫，最多 6 次测试线独有 — 页面没就绪时打橙色日志，写明原因（匹配div数=0 / 规模异常 N/峰值 / 不完整 N/M 及百分比），3 秒后重扫，最多检查 6 次（约 15 秒）。最后一次不再等待，直接返回 {ready:false, list:[], reason}。触发：DOM 预检每次未就绪｜参数MAX_TRIES=6; GAP_MS=3000｜来历要覆盖实测开机竞态 +2~+14 秒：核心启动要等 120 秒加随机 0~30 秒才点 Party，监控固定 150 秒首启就开扫，0913 十个会话里有 3 个余量 ≤0 秒｜版本测试版1.2.51
• 预检中主动打开列表（每次预检最多一次）测试线独有 — 未就绪，且列表折叠或眼睛不在 half 时，调 __ensurePartyListOpen 主动打开。真的动过手就立即重扫，不干等启动流程。每次预检最多主动打开一次（__ensured 标记）；没动手就照常等 3 秒再扫。触发：DOM 预检未就绪时｜来历刷新后启动流程还没点开列表时，紧急停采会读不到血量｜版本测试版1.2.53
• 眼睛不在 half 但卡片可读时照常扫描测试线独有 — DOM 已就绪但眼睛不是 half，或者有少量不完整卡片时，照常扫描，只打一行 ℹ️ 日志；重试多次后才就绪的，打 ✅「第 N 次检查就绪」。和主循环一致：DOM 完整时也不看眼睛。触发：DOM 预检就绪时｜版本测试版1.2.51
• 盲扫后有界自重试 __scheduleEmergencyBlindRetry测试线独有 — 预检仍不就绪时，20 秒后自动再调一次 emergencyStopHarvest(opts)，最多连续 3 次。到上限后打红字：停止自重试，交下一轮杀手监控或主循环，请检查 Party 列表是否展开。计数存在 window.__emergencyBlindRetryCount，调用方读到真实 DOM 时清零；重试异常会被 catch 打日志。预检失败时调用方输出 🚨「无法判断」，绝不输出「没有需要停采」。触发：紧急停采扫描判定页面未就绪后｜参数MAX=3; RETRY_MS=20000｜来历不能只等约 2 分钟后的下一轮杀手监控。计数挂在 window 上而不是模块级 let：脚本是 async IIFE，模块级 let 初始化前被调用会 TDZ 崩溃，而紧急停采恰恰可能在启动早期被监控拉起｜版本测试版1.2.51
• DOM 扫描开头诊断日志仅观测 — 每次扫描开始打印眼睛状态、匹配到的卡片 div 数、maxDelta，扫描为 0 张时方便排查 selector 是否失效。卡片 selector：div#party>div>div:nth-of-type(3)>div:nth-of-type(2)>div:nth-of-type(2)>div。触发：_emergencyScanKamis 入口
• 只处理采集中的卡片 — 状态图 src 不含 kami_harvesting 的卡片直接跳过；只有采集中（包括 STARVING）的 kami 才可能需要停采。触发：逐卡扫描
• 血量解析失败时跳过并记原始文本 — 从状态图相邻节点解析「(NN%)」，解析不出时记下标签名和原始文本（截 60 字），跳过这张卡。触发：逐卡扫描｜来历方便排查游戏前端 DOM 改版
• STARVING 判定与无条件入选 — 采集中但血量为 0% 判为 STARVING（正在饿死，最高优先级），不看停采线，无条件入选并打上 isStarving 标记，同时记录 hpRaw 原始文本和停采线。触发：逐卡扫描｜来历单独记原始文本，便于核对是否是 DOM 渲染异常造成的误判
• 按形象编号匹配本地库 — 从卡片形象图提取 imgNumber，在 window.kami_core_db 里找对应记录，拿到 index、kamiId、harvestId、LT、body。找不到就跳过（没法定位链上 id）。两边都转成字符串再比较。触发：逐卡扫描
• 个体停采线计算 — 有有效清算线 LT 时，停采线 = min(LT+3, 80)；没有 LT 时按体型回退：normal 用 65%，其他用 76%。触发：逐卡扫描｜参数LT_STOP_MARGIN=3; MAX_THRESHOLD=80; DEFAULT_THRESHOLD_NORMAL=65; DEFAULT_THRESHOLD_OTHER=76｜来历在精确清算线上方留 3 个百分点安全垫，同时封顶 80%，保证每个周期至少能采 20 个百分点｜版本v1.1.8 起安全垫回归3
• 入选宽容度 maxDelta（默认 1） — delta = 当前血量 − 停采线。delta ≤ maxDelta 就入选，默认只收距停采线 1% 以内的临界 kami。调用方可以放宽到 5 或 8，把接近临界的也凑进同一批，摊薄单笔交易的 gas；放太宽就等于提前停采，缩短采集时长。触发：逐卡扫描｜参数maxDelta 默认 1｜来历批量化要落在 gas 甜区
• 单张卡异常隔离 — 某一张卡解析时抛错，只记一行日志（带扫描序号），不影响其余卡片。触发：逐卡扫描
• 扫描汇总日志与 STARVING 过多告警仅观测 — 扫完打印汇总：采集中数量、STARVING 数量及占比、需停采数量。STARVING 超过 10 只时打红色告警，提醒先核对每只的 hpRaw，确认 DOM 是否正常。告警只提示，不影响停采行为。触发：扫描结束｜参数STARVING 告警阈值=10｜来历大面积 STARVING 更可能是 DOM 渲染异常导致的集体误判，不应对着假数据狂发停采
• 按危险程度排序（delta 升序） — 需停采名单按 delta 从小到大排序，最贴近或已跌破停采线的排在最前，优先进批。触发：扫描结束返回前
• 按形象编号重新定位最新卡片 — 按 imgNumber 在当前 DOM 里重新找到对应卡片，不复用扫描时缓存的元素引用。从形象图 src 用正则 /\/kami\/(\d+).gif/ 提取编号，转字符串后比较；imgNumber 为空或找不到返回 null，由调用方兜底。触发：_isKamiInCooldown 调用｜来历紧急停采可能跨多轮、持续较久，缓存的 kamiDiv 会因前端重渲染被替换失效

凑批与修剪

• 硬触发修剪：只停超出目标数的部分 — （测试版 1.2.59 起：修剪进行中来了全撤请求，会在下一轮发送前提前收尾让全撤先跑；冷却中非高危 1~2 只「推迟到下轮合批」只在修剪来源生效，全撤来源直接发）批量硬触发时，只停超出目标数（主循环硬触发传入 trimTo=STOP_TRIGGER_HARD，测试版 100、公开版 36）的那部分，剩下的继续采。饿死的优先占停采名额，其余按 delta 从低到高挑。公开版只在 opts.trimTo 存在且候选数 > trimTo 时生效；测试版 1.2.59 起带 trimTo 就一律按修剪算：超额数 = max(0, 候选数 − trimTo)，超额为 0 时只停 STARVING，没有 STARVING 就打「✂️ [批量修剪] 候选N只 ≤ 保留数M，无需修剪，本轮不停（没有需要停采的kami）」直接返回——旧写法下二次扫描（C1 剔掉退避中的）候选一旦 ≤ trimTo，会跳过修剪把整池当危险全停（1370 次历史触发里没真发生过，最险一次只差 1 只）。实际停采数 = max(超额数, STARVING 数)，普通 kami 按 delta 升序补足。STARVING 多于超额数时会停得更多，保留数少于 trimTo 属于预期。修剪后的名单仍要过凑批门槛。杀手/危险路径不传参，行为逐字节不变。触发：无杀手警戒的批量硬触发路径传 {trimTo:STOP_TRIGGER_HARD}｜参数trimTo=100（测试版）/36（公开版），由调用方传入；残留补停模式（opts.residual）忽略 trimTo｜来历用户 0710 定案：这个触发器没有杀手威胁，纯粹是数量管理，贪婪模式下 Δ≤-1 本来就可以继续采｜版本1.1.24；测试版1.2.59
• 凑批决策：有危险 kami 立即发 — 名单里只要有一只饿死，或 delta 不高于 -1，就立刻批量停采，不等凑批。hasDangerous = 任一 isStarving 或 delta ≤ EMERGENCY_DANGER_DELTA；红字日志写明其中几只危险。名单保持原样，不会把中危 kami 拉进来。触发：修剪之后｜参数EMERGENCY_DANGER_DELTA=-1｜来历危险护栏：保命优先
• 凑批决策：够 6 只立即发 — 没有危险 kami，但数量达到 6 只时立即批量停采。stopList.length ≥ TARGET_BATCH_MIN，日志注明每只约 1.5M gas。触发：修剪之后｜参数TARGET_BATCH_MIN=6｜来历批量停采的固定 gas 要摊到足够多的 kami 上才划算
• 凑批决策：不够 6 只且无危险就跳过本轮 — 没有危险、数量又不到 6 只时本轮不停采、不加锁，等下一轮积累到 6 只再合批发；同时提醒小账户可能永远凑不够。日志显示 Δ 范围（toFixed(2)，避免浮点长小数），并提示账户 kami ≤7 时可以考虑切回手动模式；然后 return。不会放宽 delta 去拉中危 kami 凑数。触发：修剪之后｜参数TARGET_BATCH_MIN=6｜来历小批量停采白付固定 gas；等积累后合批更省，现有 urgent 还能多采几分钟；拉中危凑数会过度停采，损失采集时长
• 按 delta 升序，最危险的进第一批 — 待停名单按 delta 从低到高排序，最危险的排进第一批优先处理。recheck.validList.sort((a,b)=>a.delta-b.delta)。触发：第 5 步

链上预检

• 首次链上预检（不加锁） — 发 tx 前先查链上真实状态，剔除已死、已停、在黑名单、在其他地块的 kami；剔除后没有剩余就结束。_emergencyPreCheck(stopList) 返回 {validList, filteredCount}。罕见竞态下预检后只剩 1 只也允许单只停采（约 2.43M gas，保命优先）。触发：第 3 步
• 喂食后二次预检 — 喂食期间链上状态可能变了，用户也可能已经手动停采，所以发 tx 前再预检一次；没有剩余就打总耗时后结束。_emergencyPreCheck(__stopListNoStarv)；recheck.validList 为空时打「重新预检后无需停采」和总耗时，然后 return。触发：第 4.6 步
• 停采黑名单 30 分钟到期自动解除 — 在停采黑名单里的 kami 满 30 分钟后自动移出黑名单，回到正常预检。对比 __stopBlockedTime 里的加入时间，超过 STOP_BLOCK_COOLDOWN_MS 就从 __stopBlockedKamis 和 __stopBlockedTime 里删掉，并打「黑名单已过期」。触发：紧急停采首次预检和喂食后二次预检｜参数STOP_BLOCK_COOLDOWN_MS=30 分钟｜来历防止对停不掉的 kami 反复浪费 gas，同时不永久拉黑
• 黑名单中先探测，通过的并入主批 — 还在黑名单冷却期但有 harvestId 的 kami，用 estimateGas 探测一次；通过就并入主停采批，加锁后跟大批一起发，不在这里单独发 tx。_preCheckStop([harvestId]) 结果 ok 时放进 blacklistToRetry，最后合并回主清单并打「黑名单回流」日志；停成后由 _emergencySendBatch 的 okList 处理移出黑名单。触发：预检黑名单处理｜来历预检发生在紧急锁之前，无锁发写 tx 有与普通操作撞 nonce 的窗口；并入主批还能省一笔单独 tx 的固定 gas（约 1.07M）；不必干等冷却到期
• 黑名单预检仍失败或没有 harvestId 就跳过 — 黑名单里探测仍失败，或者没有 harvestId 的 kami，本次跳过，日志显示还剩几分钟解除。blacklistSkipped++，计入 filteredCount。触发：预检黑名单处理
• 黑名单跳过统计，全部被拦时提前返回 — 打印黑名单跳过了几只；如果名单全部被黑名单拦下，直接返回空结果。itemsAfterBlacklist 为空时返回 {validList:[], filteredCount: blacklistSkipped}。触发：黑名单处理之后
• 限流并发查链上状态，刷新 harvestId、地块和 time.last — 限流并发地逐只查链上状态，顺带刷新 harvestId、采集地块号和冷却所需的 time.last。_emergencyRunPool 并发 8；getByIndex(dbIndex,{harvest:true})，_emergencyGetState 归一化成 harvesting / resting / dead / unknown；查询异常时 state='unknown'。触发：黑名单处理之后｜参数EMERGENCY_CONFIG.CONFIRM_CONCURRENCY=8｜来历限制并发，防止压垮查询接口；顺手取 time.last 不增加查询｜版本v1.1.10
• 其他地块的 kami 过滤并醒目提示手动处理 — 正在其他地块采集的 kami 当前页面没法批量处理，过滤掉，用橙色加粗日志列出当前地块名和这些 kami 所在的地块，请用户手动处理。myRoom 取自 __getMyRoomIndex()；只有 myRoom 和 harvestRoom 都读得到且不相等时才过滤，任一读不到则放行。触发：状态分类时
• 查询异常时有 harvestId 就保守放行 — 链上状态查不到（unknown）的 kami，只要有 harvestId 就留在停采名单里；没有 harvestId 的才过滤。r.state==='unknown' 分支。触发：状态分类时｜来历宁可多发一次停采，也不漏掉危险的 kami
• 已死、已停的过滤并打日志 — 已死亡的打「☠️ 已死亡，跳过」，已停采的打「💤 已停采，跳过」，都计入过滤数；状态是采集中但拿不到 harvestId 的也被过滤，但不打日志。else 分支 filteredCount++，只对 dead 和 resting 打日志；最后返回 {validList, filteredCount}。触发：状态分类时｜来历防止把注定失败的成员混进批量交易，白付 gas 还拖累整批成功率
• 预检全程只读，不发写 tx — 预检运行在紧急锁设置之前，整个过程只查询、不发任何写 tx；黑名单里恢复的 kami 也只并入主批，由加锁后的主流程发送。本函数内只有 getByIndex 和 estimateGas 预检，没有任何停采调用。触发：始终｜来历延迟加锁设计的锁纪律，避免无锁写 tx 与普通操作撞 nonce
• 并发查链上真实状态并分组 — 并发查询一批 kami 的链上状态，分成仍在采集（需要停）和已停止（不用发 tx）两组，同时用链上返回的 harvest.id 刷新 harvestId（本地库或 DOM 缓存可能过期）。名单为空直接返回两个空数组；走并发池，状态经 _emergencyGetState 归一，harvesting 进仍在采，其余进已停。读状态只查本地索引器，不花 gas。触发：紧急停采主流程发送前确认名单、发送后复核战果时｜参数EMERGENCY_CONFIG.CONFIRM_CONCURRENCY=8
• 单只查询抛错按 unknown 归入已停一侧 — 单只查询失败时记为 unknown，不中断整批，并归入 alreadyStopped。发送前状态不明时宁可不发。注释说明，这和发送后复核「查不到保守算未停」方向相反：一个为省 gas，一个为保命。触发：_emergencyQueryStatus 内｜来历避免 RPC 抖动时对同一只 kami 重复烧 gas
• 已停项挂 _resolvedState（防假记成功） — 归入已停的项目上挂一个 _resolvedState 字段，写明归一后的链上状态。调用方据此区分「确实读到了非 HARVESTING」和「查询抛错的 unknown」，只有前者才能记成功清计数。触发：_emergencyQueryStatus 分组时｜来历读取失败绝不能被当成已停，假记成功｜版本1.1.21 轮末已停实锤记账
• 链上状态三态归一 — 把索引器返回的原始对象归一成 harvesting、resting、dead 三种。state 字段缺失或异常时，回退看 harvest 子对象：存在且没结束算 harvesting，已结束算 resting。state 转大写比较；全程可选链，传入 null 也不抛错。触发：被 _emergencyQueryStatus 调用
• 判不出状态默认 resting — 完全判断不出状态时，默认按已停（resting）处理，上层就不会再对它发停采。触发：_emergencyGetState 兜底分支｜来历避免对状态不明的 kami 重复发停采空烧 gas
• 固定并发池（结果按输入顺序） — 以固定并发上限执行一批异步任务，results[i] 严格对应 items[i]。多个 worker 共用一个游标抢活，启动 min(并发数, 任务数) 个协程；单个任务抛错写入 {error} 占位，不会让整个 Promise.all 失败。默认并发 6，实际调用处传 CONFIRM_CONCURRENCY=8。触发：_emergencyQueryStatus 调用｜参数concurrency 默认6；CONFIRM_CONCURRENCY=8｜来历调大更快但 RPC/索引器压力大，调小更温和但拖慢紧急响应

饿死 kami 先喂后停

• 等喂食通道排空再发停采（超时照发）测试线独有 — 如果另一条路径正在喂食（走 queue 通道），先等它排空再发停采批，最多等 120 秒；等超时也照发停采。每 500ms 轮询 window.__starvingFeedRunning；超时红字「漏停会被清算，代价高于撞号」；等了超过 1 秒才排空时打「通道干净，继续」。触发：加锁后｜参数上限 = FEED_PHASE_CAP_MS(90000) + FEED_TAIL_GRACE_MS(30000) = 120s；轮询间隔 500ms｜来历普通锁的粒度是整个 batch_stop_deploy 大块，喂食本身不单独持锁，所以 30 秒等待管不到正在飞的喂食 tx；超时照发是用户定的「停采侧宁发勿漏」｜版本测试版1.2.45
• 饿死 kami 先喂食救援（喂食阶段有时限）测试线独有 — 预检后的名单里有饿死的 kami，就先批量喂食（按库存自动在 11 种回血食物中选），喂食排在停采前面，一秒不推迟；喂食阶段 90 秒封顶，喂不完的交给下一轮。_starvingFeedKamis(starvingList,'紧急/饿死救援',{deadlineMs: 现在+FEED_PHASE_CAP_MS})，返回喂成数量。成功后日志写「直接进入停采流程」，但代码实际上 STARVING 随后会被剔出停采名单（见「只喂不停」）。触发：第 4.5 步｜参数FEED_PHASE_CAP_MS=90000｜来历0 血 kami 只有喂食能救（停采链上必 revert），用户 0825 定「饿死的不能等下一轮」；封的只是尾巴，换来后面停采一定有预算｜版本测试版1.2.43
• 停采阶段独立计时测试线独有 — 停采阶段的 180 秒硬上限从喂食结束时开始算，喂食花多久都不会挤占停采预算；汇总里的「总耗时」仍从调用开始算。__stopPhaseStart=Date.now() 放在喂食之后；主循环硬上限和冷却收尾硬上限都拿它比。锁占用上界约 120（喂）+180（停）+93（冷却补停）≈393 秒，远低于紧急锁 600 秒超时自愈线（TX_EMERGENCY_TIMEOUT=600000；源码注释写 720s，按代码实际为 600 秒）。触发：喂食之后｜参数INVOCATION_HARD_CAP_MS=180000｜来历旧版喂食超过 180 秒时停采循环第一次判断就 break，一批 tx 都没发，日志只留一句「达到硬上限」看着像正常收尾，实际整轮停采被吞掉了｜版本测试版1.2.43
• 饿死的只喂不停，喂活转健康的也不停 — 停采名单里剔除所有 STARVING，以及 delta>1（喂活后已高于停采线）的 kami；它们只走喂食救援，下一轮扫描时自然回到正常逻辑。__stopListNoStarv = validList 过滤掉 isStarving 以及 delta 为数字且 >1 的；剔除数量用橙色日志说明。触发：喂食之后、二次预检之前｜来历0 血 kami 停采链上必 revert（0825 实测 10/10 CALL_EXCEPTION）；也化解了 1.2.23 互斥的副作用（跳过喂食时曾把「跳过」当「喂完」去停 0 血 kami，造成 16 批必败 tx）｜版本1.2.26 / 1.2.27

参数与风险分级

• 紧急停采风险分级阈值 — 按 delta=实时HP%-停采线 分级排序：≤-20 极度危险最优先，≤-10 高危，≤0 刚触线。EMERGENCY_CONFIG 中定义，由紧急停采流程读取排序。触发：紧急停采排序时｜参数CRITICAL_DELTA=-20；HIGH_RISK_DELTA=-10；DANGER_DELTA=0
• 预检/状态查询并发数 — 紧急停采预检与状态查询并发 8 路。调大更快但 RPC 压力大、可能被限流。触发：紧急停采查询时｜参数CONFIRM_CONCURRENCY=8
• 动态确认等待（基础+每批增量） — 确认等待 = 自适应基础等待 + 批次数×1.5 秒，随批次数放宽。BASE_WAIT_MS=9000 仅在样本<5笔冷启动或计算异常时使用，平时由 _adaptiveStopWaitMs() 滚动 p90 决定。触发：紧急停采发送后等待确认｜参数BASE_WAIT_MS=9000；PER_BATCH_WAIT_MS=1500｜来历固定短超时会误判失败而重发（重发=双倍 gas）；9 秒来自 0712 实测 tx 确认 p50≈5.8s+索引≈3.1s｜版本1.2.4
• 重试轮数熔断与轮间隔 — 紧急停采最多重试 3 轮，轮间隔 3 秒。防止无限重试烧 gas。触发：紧急停采重试时｜参数MAX_ROUNDS=3；ROUND_INTERVAL_MS=3000
• 批间隔 500ms — 批次之间发送间隔 500ms。让钱包 nonce 排队稳定。触发：紧急停采分批发送时｜参数BATCH_INTERVAL_MS=500
• 混合批执行只数估算仅观测 — (gasUsed−10万)/150万 ≈ 实际执行只数，仅用于日志展示。不参与判定。触发：混合批日志｜参数GAS_PER_KAMI_ESTIMATE=1500000；GAS_REVERT_BASE=100000｜版本1.1.12
• 同轮背靠背发送随机错峰 — 同一轮多批发送之间随机间隔 800~1500ms。随机抖动错峰。触发：紧急停采同轮多批发送｜参数SEND_STAGGER_MIN_MS=800；SEND_STAGGER_MAX_MS=1500｜来历防 RPC 限流｜版本1.1.12
• 紧急路径喂食阶段时间上限测试线独有 — 紧急停采里的饿死救援喂食最多 90 秒，api 补发段额外宽限 30 秒（总上限 120 秒），剩下的交下一轮。喂食失败不写 __starvingFedRecord，下轮必被重新捞起。1.2.46 量级修正：喂食单笔实测 722~2148ms，N 只约 N×2.4s，本上限很少触发，属安全阀不是常态闸。触发：紧急停采调用 _starvingFeedKamis 时传 deadlineMs｜参数FEED_PHASE_CAP_MS=90000；FEED_TAIL_GRACE_MS=30000｜来历断网夜一次攒出十几二十只 STARVING 时喂食能吃光 180 秒预算，停采循环第一轮都进不去、一只都没停成；90 秒保证至少约 9 只能喂到｜版本测试版1.2.43
• 连续全 revert 批熔断 — 连续 2 批「全 revert / estimateGas 全部不可停」→ 本次调用熔断，不再发新 tx。配合 __stopConsecutiveRevertBatches / __stopCircuitBroken 状态变量，由紧急停采主循环短路后续发送。触发：紧急停采调用内｜参数CIRCUIT_BREAK_STREAK=2｜来历防对卡链 kami 批量白烧 gas｜版本1.1.12
• 索引器滞后诊断自适应轮询仅观测 — 按 3/6/12/24/45 秒间隔轮询测索引器滞后，上限 90 秒，超时只警告。纯观测，不改判。触发：紧急停采确认阶段｜参数INDEX_LAG_POLL_MS=[3000,6000,12000,24000,45000]；INDEX_LAG_POLL_CAP_MS=90000｜版本1.1.12
• gas 判级：像全执行阈值 — 每只均摊 gas ≥120万 → 判「像全执行」，但只作观测，交由下轮 state 复读确认；低于则落进 mixed 档改走逐只 estimateGas 裁决。_allowFailureStop 与批量判级共用同一常量，单点生效。注释 1.1.12 段仍写「gas 是唯一不受索引器滞后影响的真值」，但同常量注释与退避复读 I3 红线已改为 gas 永不作成功凭据。触发：停采批回执返回后判级｜参数GAS_FULL_EXEC_PER_KAMI=1200000｜来历0709 grok+Claude 交叉审：旧阈值 80 万在「3只真执行+3只真revert」混合批均摊≈90万时被误判全执行，真失败被漏掉；0709 夜 47 批满批误判+140 次误拉黑+约 87M gas 空烧｜版本1.1.14
• gas 判级：全 revert 阈值 — 每只均摊 gas ≤30万 → 判「全 revert」，转 estimateGas 逐只裁决。必须盖住单只调用固定 revert 成本≈26.1万（单笔固定开销全摊在一只身上）。触发：停采批回执返回后判级｜参数GAS_FULL_REVERT_PER_KAMI=300000｜来历阈值过低会让单只重试的真 revert 被误判为混合，多打冗余 estimateGas 并让诊断标签失真｜版本1.1.14

多轮停采主循环

• 多轮停采，最多 3 轮 — 每轮发送、确认、复读状态，没停的进入下一轮，最多 3 轮；两轮之间隔 3 秒。while(remaining.length>0 && round≤MAX_ROUNDS)；还有剩余且未到上限时 delay(ROUND_INTERVAL_MS)。触发：第 5 步｜参数MAX_ROUNDS=3；ROUND_INTERVAL_MS=3000｜来历熔断，防止无限重试烧 gas
• 停采阶段 180 秒硬上限测试线独有 — 每轮开始前检查停采阶段已用的时间，超过 180 秒就强制收尾，剩下的交给下一次调用（测试版 1.2.59 起：不在退避队列里的交残留补停，约 1 分钟后补）。这条上限只在每轮发送之前判；整批失败后降级的「逐只单发」循环有意不按它截断（测试版 1.2.60 验证过：慢 RPC 下两次整批失败加两道逐只 estimateGas 门禁就要约 285 秒，截断会让单发一只都发不出去，而那种时候只有单发能把 kami 停下来）。Date.now()−__stopPhaseStart > INVOCATION_HARD_CAP_MS 时红字日志后 break，让 finally 释放紧急锁。1.2.43 起从「喂食结束」起算（见 __stopPhaseStart）。触发：紧急停采调用内计时｜参数INVOCATION_HARD_CAP_MS=180000｜来历防止单次调用长期占锁｜版本1.1.12 / 测试版1.2.43
• 熔断生效时不再发新一轮 — 本次调用中连续多批全部 revert 触发熔断后，不再开新一轮。__stopCircuitBroken 为真时红字日志后 break（熔断在确认阶段连续 CIRCUIT_BREAK_STREAK=2 批全 revert 时置位）。触发：每轮开始前｜参数CIRCUIT_BREAK_STREAK=2｜版本1.1.12
• 本次已判定卡链的 kami 不再发 tx — 本次调用内已经判定为疑似卡链的 kami，从后续任何一批里剔除，交给黑名单机制处理。remaining 过滤掉 kamiId 在 __stopStuckThisInvocation 里的；过滤后为空就 break。触发：每轮开始前｜版本1.1.12
• 第 2 轮起发送前过 estimateGas 门禁 — 从第 2 轮开始，发送前先用 estimateGas 过一遍，通过的才真正发送；不通过的按「已停 / 冷却 / 卡链」三类记账，不盲发。第 1 轮数据刚预检过，够新鲜，跳过门禁省一轮 RPC。_emergencyGateByEstimate(remaining) 分出 passItems 和 blockedItems，blocked 的交 _emergencyCreditBlocked；全部被门禁判定完则 break。触发：round>1 时｜来历旧代码直接拿 remaining 重新组批盲发，等于对其实已停、在冷却、真卡链的 kami 再发一次 tx｜版本1.1.14
• 发送阶段：本轮各批连续发出，不等确认 — 本轮所有批一批接一批只广播不等确认，批与批之间隔 800~1500 毫秒随机时间。chunkRandom(remaining,6,10)；逐批 _emergencySendOnly(batch) 收集到 sentBatches；最后一批之后不等。触发：每轮｜参数SEND_STAGGER_MIN_MS=800，SEND_STAGGER_MAX_MS=1500；每批 6~10 只｜来历发送和确认解耦，不再发一批等一批；随机间隔防 RPC 限流；小批加随机批量能降低 gas 飙升时整批被拒的连带损失｜版本1.1.12
• 发送途中熔断则跳过后续批 — 发送过程中一旦熔断被触发，剩下的批不再发出。每批发送前检查 __stopCircuitBroken，为真就打「熔断中，跳过批 i」后 break。触发：发送循环中｜版本1.1.12
• 每批按危险程度加图标仅观测 — 发送日志按该批最低 delta 标上 🔴/🟠/🟡/⚪，并列出批次序号、数量和编号。minDelta 依次与 CRITICAL / HIGH_RISK / DANGER 阈值比较。触发：每批发送时
• 确认阶段：所有批并行确认 — 已发送的各批同时等待上链确认、按 gas 判级和 estimateGas 裁决；某批确认抛异常时按失败处理，不影响其他批。Promise.allSettled(sentBatches.map(_emergencyConfirmBatch))；rejected 的转成 {success:false, error, items}。触发：发送阶段之后｜版本1.1.12
• 收集各批因冷却没停成的 kami — 确认结果里因操作冷却没停成的 kami，按 dbIndex 去重放进冷却推迟队列，轮次结束后统一重试。result.cooldownList 逐只 cooldownDeferred.set(dbIndex, cd)。触发：逐批处理确认结果时
• 首批强化：部分失败先批量重试再逐只单发 — 第一批装的是最危险的 kami；这批上链了但有失败的，立刻过门禁批量重试，仍没停的再逐只单发。i===0 且 result.success 且 failCount>0 时，调 _emergencyRetryBatchGated(batch,'首批强化')，retryItems 不为空再调 _emergencySingleRetryGated。其他批的失败留给下一轮。触发：逐批处理结果（只针对第一批）｜来历第一批装的是最危险的 kami，有失败要立刻重试｜版本1.1.12
• 首批整批失败只重试高危 — 第一批整批没上链时，只挑高危（delta ≤ -10）的做门禁批量重试，仍失败再逐只单发；低危的留给下一轮合批。highRiskBatch = batch 过滤 delta ≤ HIGH_RISK_DELTA；retryResult 不成功或有失败时单发。触发：第一批 result.success 为假时｜参数HIGH_RISK_DELTA=-10｜来历整批没上链多半是 gas 问题，低危的留给下一轮合批更省｜版本1.1.12
• 动态等待（自适应 p90 + 每批 1.5 秒） — 每轮复读状态前的等待时间 = 最近停采 tx 确认耗时的滚动 p90 + 批数 × 1.5 秒；日志显示 p90 秒数和样本数。_adaptiveStopWaitInfo()：取最近 30 笔确认耗时的 p90 加 3 秒索引余量，限制在 8~30 秒；样本不足 5 笔或计算异常时退回 BASE_WAIT_MS=9000。只调整等待时长，不改任何判定或重发逻辑。触发：每轮确认处理之后｜参数PER_BATCH_WAIT_MS=1500；BASE_WAIT_MS=9000（兜底）；限制在 8~30s｜来历用自适应值替代静态基础等待；9 秒兜底值来自 0712 实测 tx 确认 p50≈5.8s + 索引≈3.1s｜版本1.2.4
• 轮末复读状态并给已停的记账 — 等待后查链上真实状态；确认已停的记入操作账，并清掉失败计数、加入成功集。_emergencyQueryStatus(remaining) 返回 stillHarvesting 和 alreadyStopped；已停的调 recordAction(imgNumber,'stopHarvest')；_resolvedState 存在且不是 unknown 时才 _stopCreditSuccess，查询抛错（unknown）绝不据此清计数。触发：每轮等待之后｜来历避免真已停的 kami 因残留失败计数被误拉黑｜版本1.1.21
• 用成功集剔除索引器滞后项 — 索引器读数说「仍在采」，但本次调用中已被 gas 判级或 estimateGas 实锤停成的 kami，不进下一轮。_stopFilterConfirmed(stillHarvesting) 剔除 __stopConfirmedThisInvocation 里的 kamiId，结果作为新的 remaining。触发：每轮复读之后｜来历本地索引器读数可能落后于已实锤停成的结果｜版本1.1.14
• 每轮结果日志和仍在采名单仅观测 — 每轮打印已停数和仍在采数（索引器读数）；剔除成功集后仍在采的不超过 20 只时逐个列出编号。超过 20 只不列。触发：每轮复读之后｜参数列出上限 20｜来历方便排查

发送段

• 停采发送与确认拆成两段（背靠背发送、并行确认） — 原来的一条龙流程是：发交易、等回执、delay(2000)、再用索引器复核。现在拆成两段：_emergencySendOnly 只管把交易广播出去，_emergencyConfirmBatch 负责等回执并裁决。主流程先把本轮所有批次一口气发完，再一起确认。首批强化、cooldown 补停重试这类零散调用点继续用厚包装 _emergencySendBatch（内部就是发送加确认各跑一次），返回值形状和 v1.1.11 一样，调用方不用改。触发：被 emergencyStopHarvest 主流程及各重试路径调用｜来历0709 夜 42-agent 审计：交易其实成功了，但旧码 tx.wait 后只等 2 秒就去问滞后 17~99 秒的索引器，整批被误判为真失败，随后触发重试风暴，每只约 261k gas 白白烧掉｜版本1.1.12
• 失败计数每次调用每只最多记一次 — 停采的成功和失败都统一走 _stopCreditSuccess / _stopCreditFail 记账，同一次紧急停采调用里，每只 kami 最多记 1 次失败。要连续好几次独立调用都判失败才会被拉黑。拉黑阈值是连续 3 次独立调用都判失败。触发：各裁决路径记账时｜参数STOP_BLOCK_THRESHOLD=3｜来历旧版失败计数只增不清，一次调用里被多条路径重复计数，直接穿透拉黑阈值（Change D）｜版本1.1.12
• 发送前尽力读 nonce（诊断用）仅观测 — 原始签名器通道发交易前读一次当前 nonce，只写进发送日志，方便排查 nonce 冲突。先试 signer.getNonce（ethers v6），再试 getTransactionCount（v5）；读不到或抛错就静默返回 null，不影响发送。触发：raw 通道每批发送前
• api.stop 回退通道 _apiStopBatchFallback — 底层合约句柄或签名器不可用时，改走游戏自带的 api.player.pet.harvest.stop 批量停采。整批同成同败，没有「坏的自动跳过」能力；api 不存在返回失败「API不可用」；返回空视为失败「API返回空」；成功打印耗时和 tx hash 前 10 位；异常打日志（消息截 50 字）后返回失败。触发：发送阶段判 useFallback 时，由确认阶段调用｜来历只在 AllowFailure 依赖缺失时才用
• 发送阶段：无 harvestId 拦截 — 这一批过滤后一个 harvestId 都没有时，不发送，直接返回错误「无harvestId」。确认阶段看到后原样返回失败。触发：_emergencySendOnly 入口
• 发送守卫补 .target 检查（防 to=undefined 发交易）测试线独有 — 停采合约句柄缺 interface、缺 target、或者没有 signer，任一情况都不发，改走 api.stop 回退。触发：_emergencySendOnly 发送前｜来历0911 审计：旧守卫只查 interface。句柄有 interface 却没有 target 时守卫会放行，发出一笔 to=undefined 的交易，等于部署合约｜版本测试版1.2.35
• MUD 队列只入队不 await（保住背靠背发送） — mud 通道调 executeBatchedAllowFailure 拿到 promise 就立即返回，不等上链。真正的错误处理放到确认阶段 await 时再做。拿到 promise 后立刻挂一个空 catch，防止悬空期间出现 unhandled rejection；返回 {tx:null, txPromise}。触发：mud 通道发送时｜来历MUD 队列 promise 可能要等上链才 resolve（链上 RPC 是 eth_sendRawTransactionSync）。如果 await，多批背靠背广播会退化成串行等上链，每批多 2~6 秒｜版本1.1.19 停采通道统一·背靠背修正
• 发送段耗时日志（D1）仅观测 — mud 通道入队后打印「已入队(nonce统一) 耗时Xms」，用来证明发送段很快、背靠背成立。触发：mud 通道入队后｜版本1.1.19 停采通道统一 D1
• gas 真值账本记账 hook（紧急停采）仅观测 — 两个通道发出停采交易后，都按动作 stop 把这批 harvestId 和 tx（或 txPromise）记进 gas 账本，后台再按 hash 补回执统计真实 gas。mud 分支传的是没 await 的 promise（fire-and-forget 抓 hash），raw 分支传 tx 对象。触发：每批紧急停采发送后｜来历余额差统计不准（混入买道具和充值），改为发交易时按动作打标签记账｜版本1.2.7 gas真值账本
• 原始签名器发送路径（raw） — 默认通道。把 harvestId 转成 BigInt，用合约 interface 编码 executeBatchedAllowFailure 的 calldata，经 signer.sendTransaction 发往 system.target。发送前读 nonce 打日志；返回空 tx 记错误「返回空Tx」；抛错时把消息放进 error，交确认阶段分类（发送函数本身不抛）。触发：通道为 raw 或 mud 跌落时｜来历AllowFailure 容错批量：坏的那只自动跳过，其余照停
• 发送失败分类日志（交易未上链） — 发送阶段就出错时，按错误文本分四类打日志：timeout/not mined（交易可能已发出）、nonce/sequence mismatch（Nonce 冲突，未发出）、RPC/network（网络错误）、其他（截 80 字）。返回里带 isTimeout 标记。只有 tx 和 txPromise 都没有时才走这里；mud 成功入队（tx=null 但有 txPromise）不走。触发：确认阶段入口
• 单批厚包装 _emergencySendBatch（带熔断短路） — 对一批 kami 连着做一次发送加确认，返回值形状和 v1.1.11 一致。熔断生效时不发送，直接返回 {error:'熔断', circuitBroken:true}，并打「跳过本批发送，交下一轮对账」。触发：紧急停采主流程里的冷却等待危险批、cooldown 补停重试等零散调用点｜版本1.1.12

确认段与 gas 判级

• 停采回执形状归一 _awaitStopReceipt — 队列 resolve 出来的东西可能是带 wait() 的交易对象，也可能直接就是回执。这个函数把两种统一成 {receipt, hash, shape}。有 wait 函数就调 wait()，shape=tx；有 gasUsed、status 或 transactionHash 字段就直接当回执，shape=receipt；空值记 shape=null；都认不出记 unknown。wait() 真失败（revert 等）原样抛给调用方。raw 分支的行为与旧版逐字节等价。触发：_emergencyConfirmBatch 确认每批时｜来历0710 停采事故：MUD 队列等上链约 9528ms 才 resolve，返回的对象没有 .wait，旧码写死 tx.wait()，结果报了假失败｜版本1.1.21 停采回执适配
• 未知回执形状只打印一次字段名仅观测 — 第一次遇到认不出的回执形状时，把它的 keys 打印到日志（截 200 字符），方便以后适配。之后不再重复打印。用模块级标记 __stopShapeDumped 控制只打一次。触发：_awaitStopReceipt 遇到未知形状时｜版本1.1.21 停采回执适配
• txPromise 解析耗时计时（D2）仅观测 — 确认阶段 await 队列 promise 时计时并打日志。参考线：≤300ms 大约是拿到 hash 就返回，≥2000ms 大约是等上链后才返回。用首夜实盘数据裁决 resolve 语义这个悬案。await 本身不变，只在前后计时。触发：mud 通道确认时｜版本1.1.19 停采通道统一 D2
• 回执缺 gas / 形状未知 → pendingVerify（I2 最高红线） — 回执形状 unknown、没有回执、或 gasUsed 缺失时，本批不计成功也不计失败、不重发、绝不当成全 revert。成功与否交给之后复读 state≠HARVESTING 来判定。连续 revert 批计数清零；pendingVerify 批数+1；全员入退避复读队列（gasLikely=false）；后台起索引滞后诊断；返回 okCount:0 failCount:0 pendingVerify:true。触发：确认阶段拿到回执后｜来历旧码 gasUsed 缺失时按 0 处理，0 小于阈值，于是被判成全 revert，这是事故式假失败的根因之一｜版本1.1.21 停采回执适配
• tx 执行失败判定（status 缺失不算失败） — 只有回执的 status 明确读到、而且不等于 1，才判整批「上链但执行失败」（全部未停采）。status 缺失不当失败。raw 回执的 status 恒为 0 或 1，行为和旧版等价。触发：确认阶段 gas 判级前
• 每批确认耗时与 gas 均摊日志仅观测 — 每批打印一行：tx 确认耗时、hash 前 10 位、gasUsed 总量、每只均摊 gas。触发：每批回执确认后
• gas 三级判级（full_exec 双条件） — 按每只均摊 gas 把一批分三级。每只 ≥1.2M 且估算执行只数 ≥ 全员 → 像全执行（full_exec）；每只 ≤300k → 全 revert；其余 → 混合（mixed）。估算执行只数 = max(0, round((gasUsed−100000)/1500000))。这个估算原来只在 mixed 分支算来给日志看，现在提前到判级之前当第二个条件。阈值本身不变，靠第二维堵漏。触发：确认阶段拿到有效 gas 后｜参数GAS_FULL_EXEC_PER_KAMI=1200000; GAS_FULL_REVERT_PER_KAMI=300000; GAS_PER_KAMI_ESTIMATE=1500000; GAS_REVERT_BASE=100000｜来历只看均摊会被「少败多成」的混合批骗过（比如 9 成执行、1 只 revert，均摊约 1.41M，仍大于 1.2M），误判全执行，真失败就漏掉了。阈值 v1.1.14 从 800k 收紧：之前一批 0.9005M 的混合批曾被判成全执行。300k 是为了盖住单只 revert 固定约 261k 的情况｜版本1.1.14 停采闭环边角 修复1
• full_exec 不作停成凭据 → pendingVerify + 打 gasLikely — 判「像全执行」时，gas 只作观测：本批不计成功不计失败，成功交下轮复读 state≠HARVESTING 判定。每只打上 _gasLikelyExecuted 标记，入退避复读队列（gasLikely=true）。以后这只如果因为索引滞后导致 estimateGas revert，分类器会 defer，不当场记失败。连续 revert 批计数清零、pendingVerify 批数+1、后台起索引滞后诊断，返回 okCount:0 failCount:0。注释头写「≥GAS_FULL_EXEC_PER_KAMI 即像全执行」，代码实际还要求估算执行只数≥全员。触发：gas 判级为 full_exec 时｜参数GAS_FULL_EXEC_PER_KAMI=1200000｜来历Bug B 修复前，full_exec 直接给整批记成功，名单剔除完全由 gas 驱动。gas 不可作为停成凭据，所以改了｜版本1.1.22 退避复读 C1+C2
• pendingVerify 批数统计（C4）仅观测 — 统计本次调用里产生 pendingVerify 的批数（full_exec 批和缺 gas 批），供完成小结显示。__pendingVerifyBatchCount++，每次调用开头清零。触发：判 pendingVerify 时｜版本1.1.17 可观测性批次 C4
• mixed / 全 revert 批逐只 estimateGas 裁决 — 混合批先打日志（估算执行≈N 只 < 全员），全 revert 批打红色日志。两种都逐只过 estimateGas 门禁：通过的算「仍可停但没停成」；未通过的交分类器记账。触发：gas 判级为 mixed 或 full_revert 时｜版本1.1.12
• 连续空转熔断 — 一批判为全 revert，或者 estimateGas 裁决后全员都「仍可停但没停成」（这批 tx 对它们完全没生效），连续空转批数+1。连续 2 批就置位熔断：本次调用不再发任何新交易，交给下一轮对账。熔断时打红色粗体日志；其他情况把计数清零（full_exec 批和缺 gas 批也清零）。触发：确认阶段逐只裁决后｜参数CIRCUIT_BREAK_STREAK=2｜来历防止空转批一批接一批白烧 gas｜版本1.1.12 Change D
• 没停成的成员分流：冷却推迟 vs 真失败 — estimateGas 仍能通过却没停成的 kami 分两类：冷却中的推迟处理、不计失败；真失败的调 _stopCreditFail 记失败计数。判冷却：time.last 公式剩余秒数>0，或 DOM 主按钮 disabled（两个条件是或的关系）。注释说明 DOM 判据实盘恒为 false，只作兜底。触发：确认阶段 mixed / 全revert 路径｜参数KAMI_ACTION_COOLDOWN_SEC=180｜来历0708 实测定案：胶水和自身操作都会刷新 time.last，DOM 判据在实盘已经失效｜版本v1.1.10 起
• 批次战果汇总日志仅观测 — 每批打印一行：本批 N 个，成功几只、cooldown 推迟几只（附编号）、真失败几只（附编号）。触发：确认阶段每批末尾
• 确认阶段异常：中性文案、不记失败 — txPromise 解析或回执归一时抛错，日志写「tx 已入队但确认阶段出错，成员状态交 state 复读裁决」。本批不记失败，成员留给轮末 state 复读定夺。返回 success:false，带 isTimeout。触发：确认阶段 try 块抛错时｜来历走到这里的交易其实已经入队，不能再写「发送失败/未发出/未停采」误导人（codex 审查 Q5#5）｜版本1.1.21 确认异常文案区分

estimateGas 门禁与失败分类

• estimateGas 门禁（发前预演） — 重试或单发之前，先对每只 kami 用 estimateGas 预演一次停采。能通过的才放行发交易；不通过的交给分类器，判断是已经停了还是卡链。没有 harvestId 的直接丢弃，不进任何一组；逐只串行调 _preCheckStop([harvestId])；返回 {passItems, blockedItems}。触发：_emergencyConfirmBatch（mixed/全revert 时）、批量重试、单只重试调用｜来历不放任对停不了的 kami 发 tx 白烧 gas｜版本1.1.12
• 已知卡链短路（本次调用不再碰它） — 本次调用里已经判过「疑似卡链」的 kami，门禁和分类器都直接把它归到未通过或卡链，不再调 estimateGas，更不会再发交易。查 __stopStuckThisInvocation 集合，日志标注「已知卡链」或「已知」。触发：门禁与分类器逐只处理时｜来历省一次 RPC，也避免同一次调用里反复白烧｜版本1.1.12
• estimateGas revert 原因观测（C6）仅观测 — estimateGas 没通过时，把 revert 原因串打印一次，不改变判定。同一次调用里相同的原因串只打一次，用 __stopRevertReasonSeen 去重（每次调用开头清空）；提取过程出错静默。触发：门禁判未通过时｜来历想确认「因为已经停了而 revert」有没有可辨认的明文原因（部署 revert 就带 kami not RESTING）。如果有，下版可以升级成绕开索引器滞后的链上实时判据｜版本1.1.22 revert原因观测
• 裁决名单日志超长截断仅观测 — 门禁、分类器和索引滞后超时的日志里，名单超过 8 只时只显示总数加前 5 只样例，防止刷屏。fmt 辅助函数：长度>8 输出「N只(样例: 前5个...)」。触发：打印裁决日志时
• 分类器：已停实锤（不拉黑） — estimateGas revert 后直接读链上 state。不是 HARVESTING 就判「已停实锤」（只是索引器还没追上），记成功、清失败计数、绝不拉黑。调 explorer.kamis.getByIndex(dbIndex,{harvest:true})，state 转大写后比较。拉黑机制本身保留：真卡链的 kami 可能卡好几天，每次停采都必然 revert，不能无限重试。触发：_emergencyCreditBlocked 调用｜来历0709 事故的问题不是「拉黑该取消」，而是「抓错人」：索引器滞后、其实已经停成的健康 kami 被误判成卡链，拉黑了 140 次｜版本1.1.12
• 分类器：冷却分支（不计失败、转补停） — 链上仍在 HARVESTING，但 180 秒操作冷却还没到期，就归为 cooldown。不计失败、不拉黑，转进本次调用的冷却待补停队列。冷却按 time.last 公式计算：优先用本次 getByIndex 刚读到的 harvest.time.last，读不到才用 item 上缓存的旧值，不多发一次查询。触发：分类器逐只判定时｜参数KAMI_ACTION_COOLDOWN_SEC=180｜来历旧版只分两类，会把冷却期内的 estimateGas revert 连带判成疑似卡链，记失败甚至拉黑｜版本1.1.14 停采闭环ABCD 改动D
• 分类器：前端冻结门闩 — 冷却已过期但 estimateGas 仍然 revert 时，如果此刻判定前端冻结，就归为 unknown：不判卡链、不计数、不拉黑。调 _isFrontendFrozen()，为真就 push 进 unknown，日志标注 frontendFrozen。触发：分类器冷却已过期分支｜来历前端冻结时读到的是冻住的旧值。Bug B 修复前，这种情况仍会判疑似卡链，后续可能计数或拉黑
• 分类器：退避门禁（疑似卡链不当场计数） — 「revert + 仍在 HARVESTING + 冷却已过期」算疑似卡链，但不当场记失败。要先过 _stopBackoffGate：只有同时满足退避复读表走完、过了证据窗、没有群体滞后冻结、最后一次复读仍是 HARVESTING，才真判 stuck（记一次可疑计数，并加入本次调用的卡链集合）。否则 defer，进退避复读队列，本次不计失败。_stopBackoffGate 返回 'count' 才判 stuck。退避表见 STOP_BACKOFF_TABLE_MS。触发：分类器冷却已过期且未冻结时｜参数证据窗 普通300s / gasLikely 30min；STOP_BACKOFF_TABLE_MS=[7000,20000,45000,90000,180000,300000]｜来历防止把索引滞后、其实已停的 kami 冤枉计数。真卡链最早约 15 分钟后仍会经拉黑通路落网（I2 保留）｜版本1.1.22 退避复读 C1+C3
• defer 日志措辞按 gasLikely 反转仅观测 — 进了退避队列的 kami，如果之前那批 gas 曾达到真执行水平，日志写「疑似已停/索引滞后」；否则写「退避表未走完 t+Xs/第N档」。读 __stopPendingVerify 条目里的 gasLikely、sentAt、attempts。触发：分类器 defer 时｜版本1.1.22 退避复读 C1
• 分类器：状态查询失败保守保留（unknown） — estimateGas 已经失败，紧接着链上状态查询又抛错（两次抖动叠在一起），就归为 unknown，只打日志不记账：不写成功集、不拉黑、不转冷却队列，留在待停名单里交下轮重试。在 catch 分支 push 进 unknown。触发：分类器 getByIndex 抛错时｜来历旧版在 catch 里把它当「已停」写进成功集，于是被剔出重试名单，而它可能还在采。紧急停采时漏停的代价远大于多查一次 RPC｜版本1.1.14 停采闭环边角 修复2
• 分类器五类汇总日志仅观测 — 分类结果按类各打一行日志：✅已停实锤、🧊冷却待补停、⚠️疑似卡链记一次、已停用defer 交退避复读、⚠️双失败/前端失真保守保留。每类非空才打印。触发：分类器结束时
• 未通过项分类记账 _emergencyCreditBlocked — 按分类结果记账。stopped 记成功并清计数；stuck 记失败，原因写「疑似卡链(estimateGas revert+state仍HARVESTING)」；cooldown 汇入模块级冷却待补停队列，交本轮末统一补停；unknown 和 deferBackoff 不记账。名单为空直接返回。cooldown 队列用 Map，以 dbIndex 为键去重，和 emergencyStopHarvest 里的局部 cooldownDeferred 引用同一个对象；转入后打一行「N只转入cooldown待补停」。触发：确认阶段、批量重试、单只重试调用｜版本1.1.14 改动D / 1.1.22 退避复读
• 后台索引器滞后诊断 _emergencyDiagIndexLag仅观测 — 某批判成 pendingVerify 后，在后台（不阻塞主流程）自适应轮询本地索引器，记录每只 kami 从发出到索引器显示非 HARVESTING 用了多少秒。轮询间隔依次 3/6/12/24/45 秒（超出后一直用最后一档），总时长上限 90 秒；查询抛错当作仍在滞后；超时仍是 HARVESTING 只打警告（「未被 state 复读确认停成，保留到下轮重试」），不改判；异步异常会被 catch 打日志。gas 不再作为停成凭据。触发：确认阶段判 full_exec 或回执缺 gas 时｜参数INDEX_LAG_POLL_MS=[3000,6000,12000,24000,45000]; INDEX_LAG_POLL_CAP_MS=90000｜版本1.1.12
• 停采时延样本收集（供完成小结）仅观测 — 把每只 kami 的索引器滞后毫秒数，以及每批交易的确认耗时收集起来，供紧急停采完成小结算中位数和最慢值。推入 __stopIndexLagMsList 和 __stopTxConfirmMsList，写入失败静默。触发：索引滞后诊断翻状态时、每批回执确认后｜版本1.1.22 退避复读 C4
• 确认耗时写入滚动 p90 自适应窗口 — 每批停采的确认耗时同时写进一个滚动 p90 窗口（跨会话持久化），部署侧据此自适应决定停采后要等多久。调 _recordTxConfirmMs(confirmMs)，异常静默。触发：每批停采回执确认后｜存储（由 _recordTxConfirmMs 持久化，键不在本段）｜来历用滚动 p90 替代静态等待 5 秒，随网络状况自动调整｜版本1.2.4 部署防重发门禁 D4v2
• 重试候选链上刷新 _emergencyRefreshCandidates — 重试前逐只直读链上：已经不是 HARVESTING 的直接记成功（清计数），不再重试；仍在采的换上链上最新的 harvestId 和 time.last，再进入候选。查询抛错时保守保留旧 item（前提是它有 harvestId）。代码这里用 res?.state !== 'HARVESTING' 严格比较，没有转大写，和分类器不同。触发：批量重试、单只重试调用
• 批量重试闸门 _emergencyRetryBatchGated（显式熔断检查） — 没停成的批次重试流程：先刷新候选，再过 estimateGas 门禁，未通过的分类记账，通过的一次性批量重发并确认。入口先查熔断，生效时打日志、返回空结果，不发送。触发：紧急停采主流程「首批强化」「整批失败重试」｜来历这个函数直接调发送函数，不经过带熔断的厚包装。必须在这里补一道，否则熔断刚在本轮确认阶段触发时，首批强化或整批失败重试仍会漏网发送｜版本1.1.12
• 单只降级重试 _emergencySingleRetryGated — 批量重试后仍失败的逐只单发：同样先刷新候选、过 estimateGas 门禁，再逐只调 _allowFailureStop。返回 true 记成功（state 复读确认），false 记失败，null（pendingVerify）入退避复读队列（gasLikely=true）。入口先查熔断；日志带 Δ 值（保留两位小数）；每只之间隔 300ms。触发：「首批强化单发」「整批失败单发」｜来历熔断期间不能逐只漏网发送。Bug B 修复前，_allowFailureStop 只要 gas 判 full_exec 就直接记成功｜版本1.1.22 退避复读 C1/C2

冷却处理

• 操作冷却公式 _cooldownRemainSec — kami 任意操作后有约 3 分钟操作冷却，冷却期内停采/喂食/部署 TX 必败；按 harvest.time.last + 180 秒算冷却剩余秒数。time.last 经本地 ECS getByIndex(idx,{harvest:true}) 零 gas 读取，RESTING 状态同样有效；读不到（null/0/非正数）按无冷却返回 0，保持旧行为交下游失败分类兜底。触发：被部署/停采/喂食的冷却预筛调用｜参数KAMI_ACTION_COOLDOWN_SEC=180｜来历2026-07-08 冷却判定探针实测：T 夹逼区间 (157,189]，取游戏 3 分钟常量，269 只样本混淆矩阵零错配（含「胶水」攻击导致的冷却）｜版本v1.1.10
• 组批前冷却预筛，归入冷却推迟队列 — 还在 180 秒冷却里的 kami 不进发送批，直接放进冷却推迟队列，等轮次结束后统一处理。用预检时顺带取到的 timeLast 算 _cooldownRemainSec；remain>0 逐只打日志并按 dbIndex 放入 cooldownDeferred（即模块级 __stopCooldownDeferredThisInvocation，classify 阶段发现的冷却 kami 也汇入同一个队列）；timeLast 读不到时 remain=0，回到原有行为。触发：组批前｜参数冷却 180s｜来历发了也必败，省一次注定失败的 tx｜版本v1.1.10 / 1.1.14
• 冷却收尾同样受 180 秒硬上限约束测试线独有 — 轮次结束后如果停采阶段已超过 180 秒，放弃冷却收尾，冷却队列交给下一轮（测试版 1.2.59 起其中危险的交残留补停，冷却完就补），直接去 finally 释放锁。cooldownDeferred.size>0 且已超时时打红字（同时显示停采阶段耗时和调用总耗时）。触发：所有轮次结束后｜参数INVOCATION_HARD_CAP_MS=180000｜来历冷却定时补停最长可等 93 秒，叠加前面多轮耗时可能整体超时｜版本1.1.12 / 测试版1.2.43
• 冷却收尾与 remaining 解耦 — 冷却队列里的 kami 总是全量处理（只要求有 harvestId），不再要求它们出现在 remaining 里、或 remaining 已清空。是否还需要处理，由后面逐只实时复读链上状态来判断（state 不是 HARVESTING 就跳过）。触发：冷却收尾｜来历冷却预筛出的成员从来没进过 remaining，旧条件永远命中不了；只要还有别的 kami 没停，危险冷却 kami 的保命补停就会被整批跳过｜版本1.1.14
• 冷却收尾前先剔除成功集 — 冷却队列里本次已实锤停成的 kami 先剔掉，不再为它们查链上状态。_stopFilterConfirmed(cdListRaw,'cooldown收尾扫描前')，只是过滤，不改判定语义。触发：冷却收尾开始｜来历省掉对已确认成功的 kami 的无谓 RPC｜版本1.1.14
• 冷却队列按实时状态分三路 — 逐只重新查链上状态：已不在采集的跳过；冷却已结束的立即重试；危险且冷却剩余不超过 90 秒的定时等待后补停；其余留到下一轮。getByIndex 同时刷新 harvestId 和 time.last 重算 remain；「危险」= isStarving 或 delta ≤ -1；查询失败按无冷却处理，放进立即重试。触发：冷却收尾｜参数危险冷却等待线 90s；EMERGENCY_DANGER_DELTA=-1｜来历不在本次紧急停采里白等非紧急的冷却 kami｜版本v1.1.10
• 非紧急冷却留到下一轮的日志仅观测 — 列出仍在冷却（剩 >90 秒或非危险）、留到下一轮处理的 kami 及剩余秒数；测试版 1.2.59 起其中危险的交残留补停（冷却完 +5 秒补），日志写明。cdDeferNext 非空时打印。触发：冷却分流之后｜版本v1.1.10
• 危险 kami 冷却定时补停（加随机缓冲，封顶 93 秒） — 危险且冷却剩余不超过 90 秒的 kami，取其中最长剩余时间，加 1~3 秒随机缓冲统一等待，到点后一次性批量补停。waitMs = min(最大 remain×1000 + 1000~3000ms 随机, 93000)；然后 _emergencySendBatch。触发：cdWaitDanger 非空｜参数抖动 1~3s；封顶 93000ms（随缓冲上限从 92000 同步调整）｜来历缓冲防止卡在 180 秒冷却结束的边界上又失败一次，也错开多只同时解除；封顶是防呆，避免计算异常导致长时间占锁｜版本v1.1.10
• 定时补停后等 2.5 秒复核战果 — 批量补停上链后等 2.5 秒逐只复核，仍在采集或查询失败的进入单发降级；批量本身失败则全部转单发。复核前先用成功集剔除，已实锤停成的跳过复核 RPC。触发：定时补停批发送后｜参数delay(2500)｜来历省掉对已确认成功的 kami 的无谓 getByIndex｜版本1.1.14
• 熔断时跳过冷却补停的单发 — 熔断已生效时，定时补停和冷却重试后剩下的都不再逐只单发。waitStillFail 或 stillFail 非空且 __stopCircuitBroken 时打「跳过单发」。触发：冷却收尾单发前｜版本1.1.12
• 冷却单发前：卡链跳过 + estimateGas 门禁 — 冷却收尾里每次单发前，先跳过本次已判定卡链的，再用 estimateGas 预检，不通过的按「已停（索引滞后）/ 冷却 / 疑似卡链」分类记账，不盲发。__stopStuckThisInvocation 命中则 continue；_preCheckStop([harvestId]) 结果 ok 为假时调 _emergencyCreditBlocked([item], 场景名) 后 continue。定时补停和冷却重试两条单发路径都有这一步。触发：冷却定时补停 / 冷却重试的逐只单发｜来历不盲发 tx｜版本1.1.12
• 单发结果三态记账 — 单发返回 true 记成功，false 记失败，null（已上链待确认）放进退避复读队列，由调度器之后复读定夺；单发异常只打日志。每次单发间隔 0.8 秒。true → _stopCreditSuccess；false → _stopCreditFail；null → _stopBackoffEnroll(item,true)；每只之后 delay(800)。触发：冷却收尾的逐只单发｜参数单发间隔 800ms｜来历单发间留 0.8 秒，避免连续 tx 造成 nonce 冲突和节点压力｜版本1.1.22
• 补停后回写 remaining 并记账 — 定时补停或冷却重试做完后，重新查一遍 remaining 的状态，剔除成功集后回写；确认已停的记操作账并清失败计数（unknown 不算确认）。_emergencyQueryStatus(remaining) → _stopFilterConfirmed；alreadyStopped 调 recordAction 和 _stopCreditSuccess。注意复读的是主循环剩下的 remaining，不是冷却队列本身。触发：定时补停后 / 冷却重试后｜来历避免下面推迟判断提前 return 时漏更新；避免最终汇总把已实锤停成的算成未停｜版本1.1.14 / 1.1.21
• 冷却重试少量且低危时推迟合批 — 冷却结束、待立即重试的 kami 只有 1~2 只，且没有饿死、没有高危时，不在本次发，推迟到下一轮合批。canDefer = 数量 >0 且 <3、无 isStarving、全部 delta > -10；满足时打青色日志后直接 return。代码实际上这个 return 会跳过后面的最终汇总、收敛小结和时延小结日志（finally 照常执行）。触发：冷却收尾，定时补停之后｜参数COOLDOWN_DEFER_MIN=3；HIGH_RISK_DELTA=-10｜来历单只重试约 2.43M gas 很浪费；高危的即使只有 1 只也立即发，避免 30 分钟后变成 STARVING 被杀
• 冷却重试含高危时保命不推迟仅观测 — 冷却重试不到 3 只，但其中有高危或饿死的，用橙色日志说明保命优先、不推迟。列出编号、Δ 和是否 STARVING。触发：冷却收尾｜来历保命优先原则：高危绝不推迟
• 冷却重试：先批量，2.5 秒后复核 — 冷却结束的 kami 先一次批量停采；上链后等 2.5 秒逐只复核，仍在采集的记下最新 time.last，进入单发降级；批量整体失败则全部转单发。_emergencySendBatch(cdToRetry)；复核前用成功集剔除；复核查询失败的也进 stillFail。触发：冷却收尾，cdToRetry 非空｜参数delay(2500)｜来历冷却最长 3 分钟，前面多轮等待中可能已自然恢复；顺手取 time.last 不增加查询｜版本v1.1.10 / 1.1.14
• 单停降级前再做一次冷却复检 — 冷却重试的单发前，用复核时拿到的 time.last 再算一次冷却剩余，仍在冷却就跳过这只。_cooldownRemainSec(item.timeLast)>0 时 continue；读不到 timeLast（没走复核分支）时 remain=0，直接尝试。触发：冷却重试逐只单发前｜来历批量 tx 和单发之间隔了 2.5 秒以上，理论上可能被别的操作重新打入冷却｜版本v1.1.10
• DOM 主按钮 disabled 判冷却（降级兜底） — 判断 kami 是否在被胶水打中后的 3 分钟冷却期：卡片是采集中，且主操作按钮（harvest/stop 图标所在的 button）是 disabled，就判为冷却中。优先按 imgNumber 重新定位卡片，找不到再用缓存的 kamiDiv；不是采集中返回 false。v1.1.10 起主判据改为 time.last 公式，这里降级为或条件兜底。注释称实盘恒为 false，已失效。触发：确认阶段没停成的成员分流时（|| 兜底）｜来历冷却期内停采和喂食必然失败，要和真失败分开，冷却的推迟处理、不计失败｜版本v1.1.10 起
• DOM 缺失一律判非冷却（保守取向） — 卡片、状态图或按钮任一读不到时都返回 false（不在冷却）。全程可选链。触发：_isKamiInCooldown 内｜来历宁可把冷却误判成真失败多计一次，也不能把真失败误判成冷却，否则那只 kami 永远进不了黑名单，反复白烧 gas

退避复读与自适应等待

• 疑似卡链退避复读（不当场记失败） — estimateGas revert + 仍 HARVESTING 的疑似卡链 kami 不再当场记失败，而是进 __stopPendingVerify 队列，按相对发送时刻 7/20/45/90/180/300 秒零 gas 复读 state；走完全表(≥6档且跨度≥300s)仍 HARVESTING 才真记失败。条目 {item, sentAt, attempts, nextAt, gasLikely, enrolledAt} 跨调用存续，终态（确认停成/拉黑/死亡/兜底超时）才删除；I3 红线：成功唯一出口是 state≠HARVESTING，gas 永不作凭据。等效拉黑需≥15分钟持续证据。触发：停采失败判定时入队，由 15 秒调度器复读｜参数STOP_BACKOFF_TABLE_MS=[7000,20000,45000,90000,180000,300000]；STOP_BACKOFF_FULL_MS=300000｜来历0710 下午账户A实测 tx 确认 p50=5.3s/p95=16s/max=376s，疑似卡链 3 笔几分钟内就凑满，快于长尾确认，41 只已停成的 kami 被误判卡链拉黑｜版本1.1.22
• 退避入队 _stopBackoffEnroll — 把一只 kami 纳入退避复读队列。已在队只刷新 item（取最新 harvestId/timeLast），gasLikely 只升不降，不覆盖 sentAt（退避时钟不重置）；新条目 nextAt=now+7s；全 try/catch 异常静默跳过。触发：卡链计数门禁首次遇见时等｜版本1.1.22
• 退避出队 _stopBackoffRemove — 终态时把 kami 移出退避复读队列。全 try/catch；供成功/拉黑/兜底调用。触发：_stopCreditSuccess、_stopCreditFail 拉黑时｜来历防 Map 泄漏｜版本1.1.22
• 群体组件滞后冻结计数 — 退避队列里≥3 只卡在 90 秒+档（attempts≥4）仍未确认 → 判群体组件同步滞后，本轮冻结全部卡链计数，全体只 defer。_componentMassLagSuspect 判定；冻结时每次调用只打一条「🧊 群体组件滞后→本轮冻结全部卡链计数」。触发：_stopBackoffGate 判定时｜参数STOP_BACKOFF_MASSLAG_MIN=3｜来历用规模区分病灶：账户A 滞后是群体现象（0710 实测 41 只），真卡链是孤例（1~2只）不会触发冻结｜版本1.1.22
• 卡链计数门禁 _stopBackoffGate — 判定一只疑似卡链 kami 现在是否够格真记失败：返回 'count' 或 'defer'。首次遇见入队并 defer；需 attempts≥6（读数证据）且跨度≥证据窗（时间证据）两条件同时满足；任一不足（如页面被节流复读不足）都保守 defer；任何异常 defer。触发：停采失败记账前调用｜来历绝不凭单一维度提前拉黑；出错保守 defer，因为漏停代价大于少拉黑一次｜版本1.1.22
• gasLikely 30 分钟长证据窗 — 本批 gas 曾达真执行水平的 kami，count 需跨度≥30 分钟；其余维持 300 秒。gasLikely 只延长证据窗、不豁免 count：走完仍 HARVESTING 说明 gas 谎报，必须允许最终记失败，否则拉黑通路被永久架空。触发：_stopBackoffGate 判定时｜参数STOP_BACKOFF_GASLIKELY_FULL_MS=30分钟｜来历grok 审查关键洞：账户A 组件滞后达数十分钟，300 秒表按索引 21 秒滞后标定差一个数量级｜版本1.1.22
• count 前终审新鲜复读 — 真记失败前再读一次链上 state：已非 HARVESTING 则移出队列，非 DEAD 记「终审复读确认已停」成功，并返回 defer；读到空 state 或查询异常也 defer。window.network.explorer.kamis.getByIndex(dbIndex,{harvest:true})。触发：_stopBackoffGate 即将返回 count 时｜来历关闭 count/success 的 TOCTOU 竞态，也是最后一道滞后保险｜版本1.1.22
• 退避复读调度器（15 秒 tick） — 独立 setInterval 每 15 秒扫描退避队列，对到期条目做零 gas state 复读。启动时由 window.__stopBackoffSchedulerStarted 防重复挂载并打印「退避复读调度器已启动（表 7s/20s/…）」；__stopBackoffTickRunning 重入保护（上轮 getByIndex 慢于周期则跳过）；队列空直接返回；整体异常静默吞掉不影响主循环。触发：自动（首轮 runAutomation 后启动，每 15 秒）｜参数STOP_BACKOFF_SCAN_INTERVAL_MS=15000｜版本1.1.22
• 调度公平：按 nextAt 升序限量复读 — 先收集全部到期条目，按 nextAt 升序只取最早 20 只处理，其余下轮。处理过的条目 nextAt 后移、自然轮转。触发：每次调度 tick｜参数STOP_BACKOFF_SCAN_MAX=20｜来历grok 审查 B2：290 只风暴下旧写法队头垄断，队尾被饿死｜版本1.1.22
• 退避 30 分钟兜底移除 — 入队满 30 分钟仍未确认的条目直接移除，并打「退避复读N分钟仍未确认已停，兜底移除，交下轮常规流程重新对账」。扫描时先于到期判断执行。触发：每次调度 tick｜参数STOP_BACKOFF_STALE_MS=30分钟｜来历防 Map 泄漏｜版本1.1.22
• 复读结果分类处理 — 读到空 state → 不推进 attempts，15 秒后重试；读到 DEAD → 移出队列不记成功并打「⚰️ 复读到已死亡」；读到其他非 HARVESTING → 记「退避复读确认已停」成功并打「📈 第N档(t+Xs)确认已停」。📈 日志用于画出确认时间分布。触发：调度 tick 对到期条目｜版本1.1.22
• 90 秒后 estimateGas 单向裁决释放重发 — 仍 HARVESTING 且距发送≥90 秒、有 harvestId 时，做一次停采 estimateGas：成功（ok===true）= 首停 tx 真没生效，移出队列释放回候选待下轮重发（测试版 1.2.59 起：来自紧急停采的条目当场登记残留补停，5 秒后只补这一只）；revert/异常不作任何判定，继续等退避档位。只信一个方向：estimateGas 成功无歧义说明还能停且不在冷却；打「🔁 estimateGas可停 + 仍HARVESTING(≥90s) ⇒ 首停未生效」。触发：调度 tick｜参数90000ms 门槛｜来历异源审查铁律：estimateGas revert 有已停/冷却/卡链/网络毛刺四种成因，不能反推「已停」，那半边已砍，不拿保命赌 30 分钟优化｜版本1.2.1
• 退避档位推进 — 仍 HARVESTING 时 attempts+1，nextAt 设为表中下一个未过点的档位；全表过点后按 15 秒周期持续复读直到确认或兜底移除。单只查询抛错不推进 attempts（保守），15 秒后重试，不影响其余条目。触发：调度 tick｜版本1.1.22
• 残留补停：点名要停却没停成的那几只，1 分钟左右补一次测试线独有 — 紧急停采（主循环修剪、杀手/死亡监控全撤、手动）点名要停、却没停成的 kami，不再等下一轮主循环（约 11 分钟；贪婪模式下要候选到 106 才会再修剪），按 kamiId 登记后单独补停。只补被点名的那几只，不重新整池修剪或全撤；到时已停/已回血到停采线之上/不在采就跳过。两个入口：①轮末残留（emergencyStopHarvest 的 finally）：没停成、且不在退避队列/没判卡链/没确认停成的，加上冷却收尾里没处理完的危险 kami（被 180 秒硬上限或全撤抢占跳过、冷却剩 >90 秒、单发失败或熔断跳过；补停轮自己点名的目标不论危险与否都会再登记）→ 最早 60 秒后补，还在冷却的等冷却完 +5 秒；②退避释放（C2 判「首停未生效」且条目来自紧急停采）→ 当场登记，5 秒后补。补停这一轮（opts.residual）：扫描后只留点名的，不修剪、不等凑批，第 1 轮也先过 estimateGas 门禁（只发「还能停」的，revert 转分类不发 tx）。让路：紧急停采正在跑或有全撤排队（__pendingFullEvac / 补撤定时器未落地 __fullEvacQueuedAt）→ 15 秒后再看，最多 40 次后放弃（❌ 日志）；反过来，修剪或补停正在跑时来了全撤请求，会在下一轮发送前提前收尾（__preemptForFullEvac），让全撤先跑。补停撞上正在跑的一轮 → 重新登记 15 秒后再补，不会被当成全撤请求。限流：30 分钟最多发起 6 次，一笔停采 tx 都没发的轮次不计数（按 window.__stopTxSentCount 差值）；超了不丢，等窗口空出。单只从第一次登记起 40 分钟未补成放弃（❌ 日志；首次时刻记在 window.__residualRestopFirstSeen，补停后重新登记不重置这个时钟）。补停轮的完成行带「（残留补停轮）」，统计撤离耗时可据此剔除。已知限制：补停门禁遇到 RPC 超时（不是真 revert）会把目标推回退避队列，等下次确认再补。按「后台默认会被节流」设计：主时钟 setTimeout，退避调度器每拍（重入保护之前）再查一次当看门狗，节流时可能晚到约 1 分钟。登记后 5 分钟内会挡一下定时刷新（刷新会清空待补名单和退避队列）。日志前缀：「⏱️ [紧急停采/残留补停] 轮末残留/退避释放/补停仍残留：… 约 Ns 后只补这几只」「🔁 … 开始」「🎯 … 只补点名的」「✅ … 没有需要停采的kami」「已停用 … 达上限」「❌ … 放弃」。触发：紧急停采结束 / 退避调度 tick｜参数RESIDUAL_RESTOP_DELAY_MS=60000、RESIDUAL_RESTOP_RELEASE_DELAY_MS=5000、RESIDUAL_RESTOP_MAX_IN_WINDOW=6、RESIDUAL_RESTOP_WINDOW_MS=30 分钟、RESIDUAL_RESTOP_TARGET_TTL_MS=40 分钟、RESIDUAL_RESTOP_BUSY_RETRY_MS=15000×RESIDUAL_RESTOP_BUSY_MAX=40、RESIDUAL_RESTOP_RELOAD_HOLD_MS=5 分钟｜存储window.__residualRestop（待补名单）、window.__residualRestopHist（限流时间戳），刷新即清空｜来历0916 20:55 服务端 RPC 故障，一个账户的修剪最深 2 只首发失败，C2 一分钟后判首停未生效，却要等 6 分钟后的下一轮主循环才重发，共晚停约 11 分钟；历史日志同类真实晚停 6 起（4.6~13.8 分钟）。用户 0917「按你想的改」｜版本测试版1.2.59
• 紧急停采防卡死：请求超时 + 心跳看门狗 + 全撤可打断单发测试线独有 — 防止一轮紧急停采卡在某个永不返回的网络请求上、把之后所有停采（含杀手全撤）都挡在「已在运行中，跳过」外面。①超时：停采 tx 的发送与等回执各套 120 秒（__raceTimeout，覆盖单发 _allowFailureStop 的 mud/raw 发送与回执、批量 raw 发送、批量确认的 txPromise 与回执）；超时=结果未知，单发返回 null → 入退避复读、不记失败（记失败 3 次会拉黑 30 分钟），真没停的约 90 秒后被 C2 释放、由残留补停补上；一只单发卡住最多耗 240 秒，然后轮到下一只。②逐只单发循环每只之前看一眼：有全撤请求排队（修剪/补停轮）或本轮已被接管就收手，打「…不再逐只单发（交残留补停/下一轮）」；不按 180 秒截断。③看门狗：每轮开头、每发完一批、每只单发之前刷新心跳 window.__emergencyStopStartedAt；连续 20 分钟没有心跳（__emergencyRunIsStale()）→ 下一个请求不再走「已在运行中」，打红底「🚨 [紧急停采/看门狗] 上一轮…已 N 分钟没有任何进展，判定卡死，强制接管」并开始新一轮；慢但活着的一轮（上百只全撤、逐只单发）因为一直有心跳不会被误接管。每轮有代号 window.__emergencyStopGen：被接管的旧一轮日后醒来，while 顶部/单发循环不再发送，它的 finally 只打「被接管的旧一轮…忽略它的收尾」，不碰锁、运行标志、补撤、残留登记。④定时刷新不给卡死的一轮让路，且让路有 10 分钟总上限（见「紧急停采让路」条目）。已知限制（罕见路径，只会多发不会漏停）：冷却收尾里的两个逐只单发循环不看抢占/代号；旧一轮若卡在设紧急锁之前，醒来后可能再发一批、紧急锁空挂到 600 秒自愈；残留补停见到卡死的运行标志仍让路（由主循环硬触发/杀手监控触发接管）；一键停采命令自己置的运行标志没有心跳，不受看门狗管。触发：每次 emergencyStopHarvest 调用｜参数超时 120000ms；卡死阈值 20 分钟（写在函数里，无模块级常量）｜存储window.__emergencyStopStartedAt、window.__emergencyStopGen，刷新即清空｜来历0918 18:28~22:50 一台 RPC/钱包签名很慢的机器上，修剪轮降级成逐只单发，第 10 只的请求永不返回 → 运行标志挂 4 小时 → 20 多次修剪与 20 次杀手/死亡全撤全部被跳过，线下候选 90→171，杀手进房后死 24 只。回放同一时间线：旧版 4 小时 20 分后仍卡死；新版首轮约 14 分钟正常结束，最深 10 只 17 分钟内全部停成｜版本测试版1.2.60
• 停采确认耗时滚动历史持久化 — 把最近 30 笔停采 tx 确认耗时存到 localStorage，跨刷新保留。加载时读 JSON，过滤非正数/非有限值，截尾 30；读失败（无 localStorage/坏 JSON）空数组冷启动；_recordTxConfirmMs 入窗并持久化，任何异常静默吞掉，持久化失败内存窗口仍生效。触发：停采确认耗时收集点（约 5314 行）调用 _recordTxConfirmMs｜参数__TX_CONFIRM_HIST_MAX=30｜存储kami_tx_confirm_hist｜版本1.2.4
• 自适应停采基础等待（滚动 p90） — 样本<5 笔用 9 秒；否则取 p90+3 秒索引余量，限制在 8~30 秒；计算异常回退 9 秒。纯等待时长调整，不改任何判定/重发逻辑。触发：紧急停采计算确认等待时｜参数下限 8000 / 上限 30000 / 余量 3000｜存储kami_tx_confirm_hist｜来历用真实确认时延替代静态等待，避免「确认慢→误判失败→重发白烧gas」；30 秒封顶防 376 秒极端长尾拖垮，长尾交多轮重试+退避复读｜版本1.2.4
• 自适应等待读数观测仅观测 — _adaptiveStopWaitInfo 返回 {ms, n, secs} 供日志验证自适应在工作。异常返回默认 9 秒/0 样本。触发：被日志调用｜版本1.2.4

熔断、去重记账与停采黑名单

• 停采失败黑名单 — 连续 3 次 AllowFailure 模式都停不下来才拉黑，30 分钟后自动解除。__stopBlockedKamis / __stopBlockedTime / __stopFailCount；纯内存；window.__stopBlockedKamis 只读引用供看板读规模。触发：停采失败记账 _stopCreditFail 写入｜参数STOP_BLOCK_THRESHOLD=3；STOP_BLOCK_COOLDOWN_MS=30分钟｜命令showStopBlockedKamis() / clearStopBlockedKamis()｜来历卡在链上的 kami 继续发停采 tx 只会白烧 gas
• 每次调用同一 kami 最多记一次失败 — 每次 emergencyStopHarvest 调用自增 __stopInvocationId；同一调用内同一 kami 重复失败只记 1 次，并打「本次调用内已记过失败，跳过重复计数」。__stopFailCreditedInvocation 记 kamiId→已记账的 invocationId；天然要求连续 3 次独立调用都判卡链才拉黑。触发：_stopCreditFail 时｜来历0709 审计：同一 kami 在一次调用内被主批→强化批量重试→强化单独重试多路径重复判失败，计数 3→4→5 连加，配合误判穿透阈值误拉黑｜版本1.1.12
• 失败处置两分类（索引滞后 vs 疑似卡链） — estimateGas revert 但链上 state 已非 HARVESTING → 判「已停实锤、索引器滞后」清计数绝不拉黑；仍 HARVESTING → 判「疑似卡链」进计数/退避流程。实现在 classify 函数（本段外）；拉黑机制必须保留，只是要抓对人。触发：停采 estimateGas 裁决时｜来历部分 kami 会卡链数天、任何停采必 revert，不能无限重试；0709 问题是把已停成只是索引读数滞后的健康 kami 误拉黑 140 次｜版本1.1.12
• 本次调用已判卡链集合 — __stopStuckThisInvocation：本次调用内已判疑似卡链的 kami，除 estimateGas 探测外不再发起任何操作，尤其不再发真实 tx。模块级 Set，每次调用清空。触发：紧急停采调用内｜版本1.1.12
• 本次调用已确认停成集合 — __stopConfirmedThisInvocation：本次调用内用强证据（链上直接读到非 HARVESTING，或 estimateGas blocked 后复读 state≠HARVESTING）确认停成的 kami。唯一写入点是 _stopCreditSuccess；主循环每轮查完状态后用它剔除 remaining。触发：紧急停采调用内｜来历0709 事故直接根因：索引器滞后 17~99s，已停 kami 仍报 HARVESTING 被再发一次 tx｜版本1.1.14
• 冷却延后队列跨函数共享 — __stopCooldownDeferredThisInvocation：classify 发现「estimateGas revert 但仍在 180 秒操作冷却期内」的 kami 归入此 Map，主循环局部变量 cooldownDeferred 直接引用同一个 Map。模块级+每次调用清空，解决 classify 顶层函数够不到主循环局部变量的问题。触发：停采 classify 时｜来历冷却中的 revert 不是卡链，不应计失败｜版本1.1.14
• 停采调用内统计计数器仅观测 — __pendingVerifyBatchCount 统计本次调用产生 pendingVerify 的批数；__stopChanFallbackCount 统计本次调用 mud→raw 通道跌落次数。纯统计，调用开头清零，供小结日志。触发：紧急停采调用内｜版本1.1.17 / 1.1.19
• 时延与 revert 原因观测容器仅观测 — __stopTxConfirmMsList 记本调用各批 tx 确认耗时、__stopIndexLagMsList 记各 kami 索引器滞后，完成小结算中位/最慢；__stopRevertReasonSeen 记已打过的 revert 原因串去重防刷屏。均在调用开头清空（群体滞后日志节流标记也在此时重置）。触发：紧急停采调用内｜版本1.1.22
• 前端冻结时停采失败不计数 — 前端疑似失真（window.__frontendFrozen）时，停采失败不计数、不拉黑，只打「🧊 前端疑似失真，本次不计数、不拉黑，记 defer」。_stopCreditFail 第一关读 _isFrontendFrozen()。触发：_stopCreditFail 时｜来历MUD 前端同步流卡死时读数冻在旧值，冻结期间累计失败会误拉黑（Bug B）｜版本v1.1.25
• 停采失败达阈值拉黑 — 连续失败计数 +1，达到 3 次加入停采黑名单并移出退避队列，打「🚫 连续N次…加入停采黑名单」；未达阈值打「(n/3)，暂不拉黑」。reasonTag 只影响日志措辞；拉黑后由黑名单自己的 30 分钟到期复查。触发：_stopCreditFail 时｜参数STOP_BLOCK_THRESHOLD=3｜版本1.1.12
• 停采成功统一记账 _stopCreditSuccess — 确认停成时：移出退避队列、清零失败计数与去重记录、若在黑名单主动移出（打「停采成功，移出停采黑名单」）、写入本次调用已确认集合（首次写入打「写入已确认停成，下轮remaining剔除，不再重发tx」）。是全部「确认停成」路径的唯一记账出口，比在多个调用点分别插入更不易漏改。触发：classify 已停实锤、链上读到非 HARVESTING、退避复读确认等｜来历30 分钟自动解除只是兜底，主动移出避免已恢复的 kami 白等｜版本1.1.14
• 剔除已确认停成的 remaining — 从 stillHarvesting/remaining 里剔除本次调用已强证据确认停成的 kami，并打「索引器仍报N只HARVESTING，其中M只已实锤停成→剔除」。剔除超过 8 只时只显示前 5 个样例。触发：主循环每轮查完状态后｜来历索引器滞后（0709 实测 17~99s）会让已停 kami 被重新组批空烧 gas；改动 A 收紧阈值后必须配合本函数，否则真失败不再被滞后兜住重试而真正漏停（顺序陷阱）｜版本1.1.14
• clearBlockedKamis 清空全部黑名单 — 同时清空部署黑名单三件套、停采黑名单三件套和退避复读队列，打印并返回 {deploy, stop} 数量。不清 __stopFailCreditedInvocation。触发：命令｜命令clearBlockedKamis()｜来历手动处理完卡住的 kami 后立即解封；清退避队列给这些 kami 干净重来｜版本1.1.22
• clearStopBlockedKamis 只清停采黑名单 — 清停采黑名单、拉黑时间、失败计数和退避复读队列，返回数量。触发：命令｜命令clearStopBlockedKamis()｜版本1.1.22
• showStopBlockedKamis 查看停采黑名单 — 逐只打印「#编号 已拉黑N分钟，剩余M分钟」及总数，返回列表。kamiId 反查 kami_core_db 编号，查不到显示 '?'；kamiId 截断前 10 位；剩余分钟用硬编码 30 计算（未引用 STOP_BLOCK_COOLDOWN_MS 常量）；为空提示并返回 []。触发：命令｜命令showStopBlockedKamis()

收尾小结

• 最终汇总仅观测 — 打印未能停采的编号，以及「停采 X/Y、耗时 N 分 N 秒」；全部停成用绿色，否则橙色。stopped = 首次预检后的 validList 数 − 最终 remaining 数。代码实际上凡是不在 remaining 里的都算停成，包括只喂不停的 STARVING、冷却留到下一轮的、卡链跳过的和门禁拦下的，所以这个数字偏乐观。触发：全部结束后
• 停采收敛小结仅观测 — 打印本次 pendingVerify 批数、已确认停成只数、当前停采通道，以及 mud 跌落到 raw 的次数，并注明 gas 不作为停成凭据。读 __pendingVerifyBatchCount、__stopConfirmedThisInvocation.size、_getStopTxChannel()、__stopChanFallbackCount。触发：汇总之后｜来历成功以下一轮 state 不是 HARVESTING 的复读为准；保守起见不为凑指标改流程｜版本1.1.17 / 1.1.19
• 停采时延小结仅观测 — 打印本次 tx 确认耗时的中位数和最慢值、索引器反映耗时的中位数，以及还留在退避队列里的只数。对 __stopTxConfirmMsList 和 __stopIndexLagMsList 取中位数，无样本显示 NA；整段 try/catch 包住。触发：收敛小结之后｜来历用来日后画确认时间分布、标定退避表｜版本1.1.22

1.5 部署

休息中、血量够的 kami 凑够一批才部署。部署前核对主地块、做 estimateGas 预检、查黑名单；失败的回队重试并二分拆包隔离坏个体。

部署候选与组池

• RESTING 动作冷却跳过 — 休息中的 kami 若刚处理过部署，本周期内不再重复收集。alreadyActed(imgNumber,'startHarvest') 为真则 restingAlreadyActed+1 跳过；restingTotal 每只+1。触发：每只 RESTING kami｜参数冷却窗口=checkInterval
• 缺 kamiId 链上补查并回填 — 本地库缺 kamiId 时按编号从链上补查，顺手把 harvestId 也补进本地库。_fetchKamiAndHarvestIds(dbIndex)；拿到 kid 回填 record.kamiId；拿到 hid 且本地 harvestId 不是合法 64 位哈希时回填。回填的是内存中的 kami_core_db 记录。触发：RESTING 且缺 kamiId 且编号有效
• 清算线过高跳过部署 — 清算线超过 95% 的 kami 不自动部署，提示先升级。record.LT>95 时 restingLTSkip+1，打「部署跳过 #N 清算线过高(LT=x%)，需先升级后再部署」（每轮都会打）。触发：每只 RESTING kami｜参数LT 跳过线 95｜来历未升级的低级 kami 清算线接近 100%，部署后几乎立刻要停采，纯浪费 gas
• 部署候选按 HP 分层 — 血量≥98% 进主力池，95%~98% 进随队池，更低的继续休息。HP≥98→__startStrong；HP≥95→__startWarm；否则 restingHPLow+1；dlog 输出 [START?] STRONG/WARM/skip。触发：每只 RESTING kami｜参数strong 门槛 98；warm 门槛 95｜来历warm 不单独成行：为血没回满的 kami 单独发 TX 不划算，部署后也更早触线停采
• 部署池组池规则（strong 带队） — 决定哪些休息中的 kami 进本轮部署池：主力≥2 只时主力加随队全上，1 只主力可带随队，没有主力就不部署。strong≥2→strong+warm；strong=1 且 warm≥1→1 只 strong+全部 warm；strong=1 且无 warm→单只候选（能否真部署由凑批闸门决定）；strong=0→空池。触发：停采流程结束后、仍持普通锁｜来历warm 不单独成行：为血没回满的 kami 单独发 TX 不划算
• 自家杀手 kami 不自动部署 — 注册为自家杀手的 kami 从部署池里剔除，由用户手动部署到攻击位置。window.MY_KILLER_KAMIS 为 Set 且非空时，按 Number(dbIndex) 剔除，打橙色「部署 跳过 N 只杀手 kami: #编号（不参与自动部署…）」。该 Set 由杀手监控脚本自检后自动注册。触发：组池后｜来历杀手站位是战术选择，脚本不代劳
• 无可部署 kami 提示仅观测 — 本轮没有血量够的休息 kami 时打一条提示；被主地块校验清空的不重复提示。池为空且 strong/warm 都为 0 且不在暂停窗口→打「没有HP足够的RESTING Kami可以部署（需HP≥98%）」。触发：池为空时
• 小账户逃生通道 — 账户 kami 总数不超过凑批门槛时，把门槛降为 1，按实际数量部署。getByOperator(addr).kamis.length≤MIN_DEPLOY_BATCH 时 effectiveMin=1，打灰色提示；读不到账户按默认门槛走。触发：池非空时｜参数MIN_DEPLOY_BATCH=6｜来历否则小账户永远凑不齐一批，陷入反复跳过部署的死循环
• 部署凑批闸门 — 候选不够一批时跳过本轮，等下一轮凑齐再批量部署省 gas。pool.length<effectiveMin 时打青色「部署/凑批 候选仅 N 只 (#…) < 门槛，跳过本轮等下一轮凑批省 gas」和「单只部署 1.35M gas vs N=6 时 0.80M/只，凑批可省 ~40%」。触发：小账户判定后｜参数MIN_DEPLOY_BATCH=6｜来历单只部署约 1.35M gas，6 只一批约 0.80M/只
• 部署凑批门槛 MIN_DEPLOY_BATCH — 部署候选不足 6 只时本轮跳过部署，等下一轮凑够再一起发（常量在此定义，由部署板块使用）。调小部署更及时但单只 gas 上升；调大更省 gas 但 Kami 闲置更久。触发：部署板块组批时读取｜参数MIN_DEPLOY_BATCH=6｜来历单只部署约 1.35M gas，6 只批量约 0.80M/只，散着发要多花约 70%
• 查询账户当前地块编号 _getTileNumber — 通过 getByOperator 取当前账户所在地块（房间）编号 roomIndex，部署流程用它确认要部署到哪个采集点。roomIndex 不是有限数就抛错；任何失败都打「获取地块编号失败」并返回 NaN，调用方用 Number.isFinite 判断，不中断流程。触发：部署流程按需调用

主地块校验

• 采集中不足 5 只不校验 — 账户里采集中的 kami 少于 5 只时跳过主地块校验，样本太小容易误判。getByOperator(addr).kamis 中 state 为 HARVESTING 的≥5 才校验；当前地块读不到也不校验。触发：部署池非空时｜参数启用校验最少采集中数量 5
• 等距抽样求主地块 — 从采集中的 kami 里等距抽最多 15 只查所在地块，出现最多的就是主地块；每轮实时抽，不缓存，用户真搬家后自动认新家。samplePrimaryRoom：step=floor(总数/样本数)，逐只 getByIndex 读 harvest.node.index 计数，单只查询失败跳过，取众数。触发：校验启用时｜参数抽样上限 15
• 不匹配时错开样本二次确认 — 第一次抽样发现当前地块不是主地块时，错开样本再抽一次，两次都不匹配才认定。第二次 offset=floor(样本数/2)；dlog 记第 1 次结果；任一次抽样结果为空或与当前一致都不暂停。触发：第一次抽样不匹配｜来历排除偶然误判
• 确认不在主地块则暂停部署 — 两次确认都不在主地块时，清空本轮部署池并打大号红色提示，回到主地块后自动恢复。打「部署暂停 主地块: 名称(#x)，当前: 名称(#y)。回到主地块后自动恢复部署」，pool=[]。触发：二次确认仍不匹配｜来历用户临时跑图办事时照常部署会把 kami 撒到错误地块
• 部署暂停定时提醒 — 暂停期间每 3 分钟提醒一次；检测到已回主地块时打恢复提示并停掉提醒。注册前先 clearInterval 旧的 window.__deployPauseReminder 防堆积；setInterval 每 3 分钟读当前地块，等于主地块打绿色「部署恢复」并清除定时器，否则打红色「自动部署仍暂停中」。触发：确认暂停时注册｜参数提醒间隔 3*60*1000ms
• 校验出错放行部署 — 主地块校验本身出错时照常部署，不因查询故障卡死自动化。catch 中 dlog「主地块检查出错，继续部署」。触发：校验抛异常

全量停采后的暂停窗口

• 全量停采后自动暂停部署 10 分钟 — 一键停采(stopCurrentRoom)/转移停采(stopMinorityForTransfer) 完成后，自动暂停自动部署 10 分钟，并橙色打印到期时刻（配置时区 HH:MM）和恢复命令。写 window.__deployPausedUntil=now+10分钟；自动部署入口每轮检查未到期则跳过部署；用绝对到期时间戳+主循环轮询实现，不挂定时器无需清理。触发：两个停采命令收尾时调用 _pauseDeployAfterStopAll(tag)｜参数DEPLOY_PAUSE_AFTER_STOPALL_MS=10分钟｜命令resumeDeploy()｜来历用户全量停采通常是为转移地块或转给其他账户，不暂停的话下一轮会把刚 RESTING 的 kami 重新部署回原地块，白停一次浪费两笔 gas
• 部署暂停标志幂等初始化 — window.__deployPausedUntil = 已有值 || 0。挂 window 让部署入口跨作用域共享。触发：脚本加载时｜来历脚本重复加载时不清零已生效的暂停
• resumeDeploy 手动解除暂停 — 立即把暂停标志清零，打印「暂停已手动解除，下一轮恢复自动部署」。触发：命令｜命令resumeDeploy()｜来历误触停采命令后的逃生口
• 转移暂停窗口 — 全量停采后的一段时间内不自动部署，避免用户要转移地块时刚停完又被部署回原地块。window.__deployPausedUntil 未到期且池非空→打橙色「转移暂停窗口生效中，剩余 N 分钟，本轮 x 只候选不部署（立即恢复 → resumeDeploy()）」并清空池。触发：主地块校验后｜命令resumeDeploy() 立即解除暂停窗口（定义在别处）

发送批量部署

• 部署准备日志 + tile 获取失败放弃 — 打出准备部署的数量和目标地块；拿不到地块 tile 编号时放弃本轮部署。打「部署 准备部署 N 个Kami到 地块名（HP≥98%: x个, HP≥95%: y个）」；await _getTileNumber() 非有限数则打「tile 获取失败，跳过本轮部署」。触发：通过凑批闸门后｜来历缺 tile 参数无法发部署 TX
• 部署随机切批（含尾批合并） — 部署池按门槛到 10 只随机切批，与停采同一套策略，避免零碎尾批浪费 gas。chunkRandom(pool,effectiveMin,10)；dlog 输出各批大小。小账户门槛为 1 时可退化为单只部署。触发：tile 获取成功后｜参数批量上限 10
• 每批部署前紧急锁中断 — 每批部署发出前检查紧急锁，有就中断剩余部署。hasEmergencyLock() 为真打「检测到紧急锁，中断部署」break。触发：每批前
• 发送前逐只 ready 过滤 — 发 TX 前把已经在采集或没有 kamiId 的从本批剔除，剔完为空就跳过这批。batch.filter(!_isCardHarvestingByImg && kamiId)，为空 continue；打「批量部署/第 i/N 笔(API) 计划 x 个」。触发：每批
• API 批量部署 + 成功件记冷却 + 整批汇总 — 调用带退避的批量部署，确认成功的记部署冷却防重复，整批只打一行汇总。const {pending:still,succeeded:doneList}=await deployWithBackoff(ready,tile,5)；doneList 逐只 recordAction('startHarvest')；打「批量部署/第 i 笔(API) 成功 N 个：#编号(img:…)」。触发：每批｜参数退避尝试 5 次｜来历0709 审计：旧版用 ready 减 still 的差集反推成功，被拉黑/冷却跳过的项被误算成功。同一笔原子成功，逐只打印是冗余刷屏｜版本1.1.12

交易预检与发送

• estimateGas 通用交易预检 — 发真实交易前先模拟执行整笔批量 TX，会失败的就不发，识别坏 kami 完全不花 gas。_preCheckTx(type,params)：用 system.interface.encodeFunctionData('executeBatched',…) 构造与真实 TX 一致的 calldata，再 signer.estimateGas({to:system.target,data})；deploy 参数 [kamiIds,tile,0(taxerID),0(taxAmt)]，stop 参数 [harvestIds]；成功返回 {ok:true,gasEstimate}，失败返回 {ok:false,reason,detail}，reason 取 e.code||e.reason。触发：被 _apiDeployOnce、D3 复核、DOM 兜底部署门禁、停采流程调用｜来历以 0 gas 成本拦截注定失败的部署/停采
• 预检不可用时放行 — 签名者、合约接口不可用或类型未知时，预检直接放行，不卡住主流程。signer 为空→dlog 后返回 {ok:true}（无 gasEstimate）；system.interface 为空→{ok:true}；未知 type→dlog 后 {ok:true}。没有 feed 分支。触发：每次预检
• revert 原因多字段提取 — 预检失败时尽量抓出完整的 revert 原因串，写进调试日志并随结果返回。依次取 e.reason / e.shortMessage / e.info.error.message / e.data / e.message 的第一个非空值，截 120 字作为 detail。注释写「判定逻辑不变，仍以 reason 为准」，代码实际：1.2.4 的 D3 复核会用 reason+detail 做 revert 正则判断，detail 已参与部署成功判定。触发：预检失败时｜参数detail 截断 120 字｜来历供停采 estimateGas 裁决处打观测日志｜版本1.1.22
• 部署/停采预检便捷封装 — 给部署和停采各包一个简单的预检入口，停采流程复用同一个预检通道。_preCheckDeploy(kamiIds,tile) / _preCheckStop(harvestIds)。触发：被部署与停采代码调用
• 交易回执轮询兜底 — TX 对象没有 wait 方法时，自己去链上轮询回执；拿不到就如实返回空，绝不当作成功。_pollTransactionReceipt(signer,hash,capMs)：按 3s→6s→12s→24s 退避查 provider.getTransactionReceipt，累计不超过 capMs；查询异常继续退避不中断；循环结束再查一次；provider 或 hash 缺失直接返回 null。触发：部署 TX 无 wait 方法时调用｜参数退避序列 3000/6000/12000/24000ms｜来历绝不能因为拿不到回执就假设已经成功｜版本1.1.12
• 单次批量部署入口检查与准备日志 — 部署 API 不可用时直接报错；可用时先打出本批准备部署的列表。api.player.pet.harvest.start 不存在则 throw 'api.start 不可用'；打「批量部署/准备(API) N 个 → 列表」，dlog 输出 ids 与 tile。触发：_apiDeployOnce 开头
• 整批一次预检 — 先用一次 estimateGas 覆盖整批，通过就直接发，并打出预估 gas。_preCheckDeploy(ids,tile)，通过打「批量部署/预检通过 预估gas: …」。触发：每次单批部署前
• 整批预检失败→逐只预检定位坏 kami — 整批模拟失败时，一只只单独预检，找出是哪几只有问题，剩下的健康 kami 照常部署。逐只 _preCheckDeploy([id])，通过的进 okIds，失败的打「逐个预检 #N ❌ 失败: 原因」并只给失败的累加失败次数；打排查结果统计；全失败返回 {ok:false,isCallException:true,isPreCheckFail:true} 跳过本批；否则只用 okIds 继续。触发：整批预检失败时｜来历预检不上链不花 gas，避免一只坏 kami 连累整批
• 预检连续失败拉黑（未花 gas） — 同一只 kami 部署预检连续失败达到次数就进部署黑名单，暂时不再尝试部署它。__kamiDeployFailCount 达 DEPLOY_BLOCK_CONFIG.FAIL_THRESHOLD 时加入 __blockedKamiIds，记 __kamiBlockedTime，打「连续失败N次，已加入黑名单（未消耗gas）」。三者均为内存态，重载清空。触发：逐只预检失败时｜参数DEPLOY_BLOCK_CONFIG.FAIL_THRESHOLD=2
• 部署发 TX 前等紧急锁（最多 300 秒） — 发部署 TX 前如果紧急停采正持锁，先原地等它结束；等太久就放弃这次部署。hasEmergencyLock() 为真时 waitForEmergencyRelease('批量部署',300000)，超时打「等待紧急锁释放超时，放弃本次部署」并返回失败（非 CALL_EXCEPTION）。触发：预检之后、api.start 之前｜参数紧急锁等待上限 300000ms｜来历发 TX 前最后一道防线，紧急停采优先
• 发送批量部署 TX（空 TX 视为失败） — 用一笔 TX 把整批 kami 部署到采集点；API 返回空就当失败。api.start(idsToUse,tile)；返回空打「API返回空Tx」并返回 {ok:false}。触发：通过预检与紧急锁检查后｜来历N 只合并 1 笔摊薄固定 gas
• gas 真值账本记账（部署）仅观测 — 部署 TX 发出后记一笔账，按 hash 事后补真实 gas，归类到部署动作。_gasLedgerRecord('deploy',idsToUse,tx)，非侵入仅此一行。触发：部署 TX 非空后｜命令showGasReport()（定义在别处）｜版本1.2.7
• 部署 TX 无 wait 改轮询回执（不假设成功） — TX 没有 wait 方法时轮询回执最多 60 秒，拿到 status=1 才算成功，拿不到按「已发送待确认」交上层去链上复核。有 wait 就 await tx.wait()；否则 _pollTransactionReceipt(cap 60s)：无回执返回 {isTimeout:true,attemptedIds}；status≠1 返回 {isCallException:true}；status=1 打「轮询到回执确认成功」继续。板块头注释仍写「Tx 无 wait 方法时的回退延时 15000ms」，代码实际已改为轮询回执、上限 60 秒。触发：部署 TX 发出后｜参数回执轮询上限 60000ms｜来历0709 审计：v1.1.11 及更早 delay(15000) 就当已确认，TX 到底成没成完全未知，是「部署假成功」的根因之一｜版本1.1.12
• 部署成功清失败计数 + 完成日志 — 部署确认成功后清掉这些 kami 的失败计数，并打出 tx 前缀和编号列表。打「批量部署/完成(API) tx:前10位… → #编号 [消耗Gas]」，逐只 __kamiDeployFailCount.delete，返回 {ok:true,deployedIds}。触发：TX 确认成功后
• 部署失败错误分类 — 把部署失败分成合约回滚、超时、nonce 被拒几类，上层按类别决定怎么重试。CALL_EXCEPTION：e.code 或消息含 CALL_EXCEPTION/revert；超时：消息含 timeout/not mined；nonce：消息含 nonce 或 sequence mismatch。返回 {isCallException,isTimeout,attemptedIds}。触发：api.start 或 tx.wait 抛异常时
• 失败 gas 消耗提示仅观测 — 部署失败日志里标出这笔大概有没有花掉 gas，方便对账。nonce 被拒→[未消耗Gas - Nonce被拒]；超时→[可能消耗Gas - 超时]；其余→[消耗Gas]；日志截 80 字。触发：部署失败时
• CALL_EXCEPTION 整批计失败并拉黑 — 真实 TX 合约回滚时，本批每只都记一次失败，达到次数就拉黑。打「检测到CALL_EXCEPTION，可能有kami卡在链上」，idsToUse 逐只失败计数+1，≥阈值进黑名单并记时间、打日志。触发：部署 TX 回滚时｜参数DEPLOY_BLOCK_CONFIG.FAIL_THRESHOLD=2

部署队列、复核与拆包

• 部署进场静置 5 秒 — 进入部署队列前先等 5 秒，让上一轮 TX 的 nonce 和链上状态稳定下来。delay(STATE_CHECK_DELAY_MS)；代码实际：这 5 秒在空输入检查之前，传入空列表也会先等 5 秒再返回。触发：deployWithBackoff 开头｜参数STATE_CHECK_DELAY_MS=5000｜来历避免 Nonce 冲突
• 包队列调度 + 尝试次数上限 — 把待部署的 kami 放进队列按包发 TX，失败的回队重试，发 TX 总次数有上限。queue=[{items,failStreak}]，while 队列非空且 attempts<maxAttempts；真正调用 _apiDeployOnce 才 attempts++（本包无目标直接 continue 不计次）。触发：被主循环批量部署调用｜参数maxAttempts=5（形参默认，上层也传 5）｜来历防止无限重试烧 gas
• 显式成功清单（不再差集反推） — 部署结果明确分成「确认成功」和「仍待处理」两份返回，被跳过的 kami 绝不会被误算成成功。succeeded 只收 DOM 已采集中/链上确认/最终确认成功/D3 复核确认的；被拉黑或冷却预筛跳过、没真正尝试过的进 droppedPending，收尾并入 pending；返回 {pending,succeeded}。触发：deployWithBackoff 全程｜来历0709 审计：旧版上层用「输入减 pending」反推成功，中途被悄悄丢弃的项被误算成功，是部署假成功根因之一｜版本1.1.12
• 部署队列每轮紧急锁检查 — 每处理一包之前检查紧急锁，有紧急停采就中断整个部署队列。hasEmergencyLock() 为真打「检测到紧急锁，中断deployWithBackoff」并 break，剩余队列在收尾时进 pending。触发：每包循环开始
• 卡片已显示采集中计为成功 — 部署前过滤时发现卡片已经在采集，直接算作部署成功，不重复发 TX。_isCardHarvestingByImg(imgNumber) 为真则 push 进 succeeded 并从本包剔除。触发：每包过滤阶段｜来历可能是本次更早一批已成功或本来就在采，不再悄悄丢弃｜版本1.1.12
• 缺 kamiId 项直接剔除 — 没有 kamiId 的条目在过滤阶段直接去掉。filter 中 !x.kamiId 直接 return false。代码实际：这类项既不进 succeeded 也不进 droppedPending（上层 ready 已预先过滤掉缺 kamiId 的，实际不会走到）。触发：每包过滤阶段
• 部署黑名单过滤 + 30 分钟自动解除 — 跳过黑名单里的 kami；拉黑满 30 分钟的自动解除并清零失败计数，给它自愈后重新上岗的机会。在黑名单且拉黑时长>AUTO_CLEAR_MS→删除黑名单/时间/失败计数，打「已超时自动解除黑名单」并保留；否则打「跳过被blocked的 Kami #N」，push 进 droppedPending。触发：每包过滤阶段｜参数DEPLOY_BLOCK_CONFIG.AUTO_CLEAR_MS=30分钟｜版本1.1.12
• 本包无可部署目标跳过 — 过滤后一只都不剩就跳过这包，不发 TX。打「批量部署/跳过 本包无可部署目标」或「冷却预筛后本包无可部署目标」并 continue。触发：过滤后/冷却预筛后
• 部署冷却公式预筛 — 部署前逐只查一次冷却，还在 3 分钟操作冷却里的本批不发，避免整批模拟失败连累健康 kami。本包≤20 只时逐只 getByIndex({harvest:true}) 用 _cooldownRemainSec(time.last)；剩余>0 进冷却列表，打「冷却预筛 N 个冷却中，本批不发（tx必败省gas）: #编号(剩Xs)」并并入 droppedPending；读取失败按无冷却处理（回落旧行为）。触发：每包过滤后｜参数补读阈值≤20 只；KAMI_ACTION_COOLDOWN_SEC=180｜来历整批 estimateGas 失败会触发二分拆包，冷却中的 kami 让同批健康 kami 被误伤｜版本v1.1.10
• 部署 TX 发出后立即让路紧急锁 — 部署 TX 发出后马上再看紧急锁，紧急停采来了就跳过确认环节直接让路（TX 已广播不受影响）。hasEmergencyLock() 为真打「部署Tx已发送，检测到紧急锁，跳过确认让路紧急停采」并 break。代码实际：这一包已从队列取出，既不进 succeeded 也不进 pending，交下轮扫描重新判断。触发：每次 _apiDeployOnce 返回后
• 部署成功后等 UI 收敛逐只链上复核 — TX 确认成功后等前端刷新 25 秒，再逐只查链上是否真的进入采集状态。delay(UI_SETTLE_MS) 后逐只 getByIndex：state 非 HARVESTING 且卡片也不显示采集中→进 stillNotHarvesting；查询异常 console.warn 并保守算未收敛。触发：result.ok 后｜参数UI_SETTLE_MS=25000
• D3 estimateGas 复核纠偏（索引滞后假失败） — 25 秒后索引器仍说「没起采」的 kami，再单独模拟部署一次；链上拒绝再次部署说明其实已经部署了，直接计成功，不回队重发。只对 stillNotHarvesting 中属于本批已发送子集的逐只 _preCheckDeploy；ok===false 且 reason 为 CALL_EXCEPTION 或 reason+detail 匹配 /call_exception|revert/i 才算已部署→清失败计数、进 succeeded，打「D3复核纠偏 N只 estimateGas确认已部署…」；ok===true（真没部署）、网络错、预检异常→保守回队。双重证据：只有原子批 status=1 加 revert 两条都指向已部署才计成功，revert 单独在别处不能当「已部署」用。触发：部署成功后的复核发现未收敛时｜来历掐断 25 秒索引复核的假失败源头；若这 25 秒内恰被紧急停采，start 因冷却 revert 也计成功是对的（本批确实部署过），回队重发只会撞冷却白烧 gas｜版本1.2.4
• D3 成功判定限定本批已发送子集（B1 修） — 用 revert 反推已部署只对本批真正发出去的 kami 有效，预检阶段就被剔掉、没发送的 kami 一律回队。_deployedSet=new Set(result.deployedIds)，不在集合里的直接进幸存者回队。触发：D3 复核时｜来历grok 审出：整批预检可能只发子集，没发送的 kami 若因地块满等其他原因 revert 会被误计成功导致漏部署｜版本1.2.4
• 未收敛回队 + 连败二分拆包 — 复核后仍没起采的回队重试；同一包连续失败 2 次且还有多只时对半拆开，把整包连坐收敛成隔离个别坏 kami。failStreak+1，打「UI未收敛 仍未起采 x/y」；failStreak≥2 且>1 只→前后两半各自 failStreak=0 入队，打「二分拆包 N → a + b」；否则整体回队打「重试排队」。代码实际：部分收敛时，本包已确认起采的那部分不会进 succeeded（只影响上层记账和日志，下轮扫描已是采集中不会重发）。成功分支回队后没有额外 5 秒重试间隔（已等过 25 秒）。触发：复核后仍有未收敛项时｜参数二分拆包阈值 failStreak≥2
• 最终确认成功（去重 D3 已计） — 全部收敛时整包计入成功，D3 已经计过的不重复计。打「批量部署/最终确认成功 共 N 个」，succeeded.push(live 中不在 D3 已计集合的)。触发：复核后无未收敛项｜来历唯一的「最终确认成功」分支｜版本1.1.12 / 1.2.4
• 超时后查真实状态只重试真正失败的 — 部署超时后等 5 秒逐只查卡片和链上状态，已在采集的不再重发，只把真没部署的回队。打「超时 等待5秒后查询链上状态」；逐只：卡片显示采集中→确认成功；getByIndex 为 HARVESTING→确认成功；否则进重试；查询失败保守进重试。确认的进 succeeded；无需重试打「超时但成功」；否则 failStreak+1，同样二分拆包/回队。触发：_apiDeployOnce 返回 isTimeout 且有 attemptedIds｜参数超时后核对前延时 5000ms｜来历避免对已成功的 kami 重复发 TX 烧双倍 gas｜版本1.1.12
• 非超时失败按 DOM 过滤后回队 — 合约回滚或 nonce 被拒等失败后，卡片已显示采集中的算成功，其余回队或二分拆包。已采集中的 push 进 succeeded；剩余为空打「重试放弃 本包已无可部署目标」；否则 failStreak+1、≥2 且>1 只拆包、否则回队。全部预检失败（isPreCheckFail）也走这条并消耗一次尝试次数，已拉黑的下一轮过滤会跳过。触发：部署失败且非超时｜版本1.1.12
• 失败后重试间隔 5 秒 — 部署失败（超时或非超时）处理完后歇 5 秒再进下一包。delay(RETRY_DELAY_MS)；超时但全成功、重试放弃这两种 continue 不走这个间隔。触发：每次部署失败后｜参数RETRY_DELAY_MS=5000｜来历避免 Nonce 冲突
• 部署队列收尾汇总 — 队列结束时把没成功的整理成待处理清单交给上层，收尾时已显示采集中的归为成功。pending=droppedPending + 队列里卡片仍不显示采集中的；队列里卡片已显示采集中的进 succeeded。触发：队列清空或尝试次数用完｜来历上层直接用 succeeded 判成功，不再差集反推｜版本1.1.12

DOM 兜底部署

• DOM 兜底部署去重 + 紧急锁跳过 — API 部署后仍未成功的条目去重后走 DOM 兜底；紧急锁存在时整个兜底跳过。按 imgNumber|dbIndex 去重；有紧急锁打「紧急锁存在，跳过DOM兜底部署（N个）」，否则打「批量部署/第 i 笔(DOM) 准备 N 个」。触发：每批 API 部署后｜来历避免 nonce 冲突
• D2 DOM 兜底遵守部署黑名单 — 被 API 层拉黑的 kami 不再在 DOM 兜底里点击部署。__blockedKamiIds.has(kamiId) 时打「DOM兜底 #N 在API黑名单内(30min自动解除)，跳过点击省gas」并 continue。触发：每只 DOM 兜底部署前｜参数黑名单 30 分钟自动解除｜来历被拉黑者经 pending 流回兜底，旧码不查黑名单会逐只重发→revert 白烧 gas｜版本1.2.4
• DOM 兜底部署前确认未在采 — 点击部署前查链上和卡片，已经在采集的跳过。getByIndex 读 state，为 HARVESTING 或卡片显示采集中则 continue。触发：每只 DOM 兜底部署前
• D1v2 第一道：冷却公式预筛 — DOM 兜底部署前先看操作冷却，冷却中必败，连模拟都不跑直接跳过。复用同一次 getByIndex 的 harvest.time.last，_cooldownRemainSec>0 打「DOM兜底 #N 冷却中剩Xs,跳过(tx必败省gas)」；读不到按 0 落到第二道。零额外 RPC。触发：通过未在采确认后｜参数KAMI_ACTION_COOLDOWN_SEC=180｜版本1.2.4
• D1v2 第二道：estimateGas 门禁（只信成功方向） — 冷却已过才单只模拟部署；只有模拟成功且拿到预估 gas 才点击，其余一律保守跳过。_preCheckDeploy([kamiId],tile)，仅 ok===true 且有 gasEstimate 才进入第三道；revert、signer 不可用（ok 但无 gasEstimate）、异常都打「estimateGas未通过(冷却已排除⇒疑似已部署/读不到结果)，跳过省gas」。漏点一轮下轮主循环会重扫。触发：通过冷却预筛后｜来历DOM 兜底曾把 API 层已实锤「已部署」的 kami 逐只重发，某账户实测 18 笔 revert 白烧 gas；部署侧宁跳勿发｜版本1.2.4
• D1v2 第三道：模拟点击 Start/Onyx Harvest — 通过门禁后点开卡片面板，点击可见的 Start Harvest 或 Onyx Harvest，并记部署冷却。主按钮缺失打「DOM 部署找不到主按钮」；simulateClick(主按钮,100)；1200ms 后在面板找 harvest/start/onyx 图标所在、文本匹配 Start Harvest|Onyx Harvest 且可见的元素 simulateClick(…,800)，recordAction('startHarvest')，打「单个部署成功(DOM)」（点击即打，非链上确认）；每只后 delay(800)；单只异常打「DOM 部署异常」。触发：通过 estimateGas 门禁后｜参数面板等待 1200ms；只间 800ms｜版本1.2.4
• 部署段整体异常隔离 — 整个部署段出错只记日志，不影响后面的喂食和复活。外层 try/catch 打「批量开始 失败：错误」。触发：部署段

部署黑名单

• 部署失败黑名单 — 同一 kami 连续部署失败 2 次拉黑、暂停对其部署，30 分钟后自动解除。三件套：__blockedKamiIds（名单 Set）、__kamiDeployFailCount（连续失败次数）、__kamiBlockedTime（拉黑时刻）；纯内存，刷新即清空不跨会话；window.__blockedKamiIds 只读引用供健康看板/控制台直读规模。触发：部署流程失败时写入｜参数FAIL_THRESHOLD=2；AUTO_CLEAR_MS=30分钟｜命令showBlockedKamis() / clearBlockedKamis()｜来历防止对卡在链上的 kami 反复发无效部署 tx 白烧 gas
• showBlockedKamis 查看部署黑名单 — 用表格展示部署黑名单：编号、截断 kamiId、拉黑多少分钟前，返回列表。不显示剩余解封时间；为空打印「没有blocked的kami」返回 []。触发：命令｜命令showBlockedKamis()

1.6 喂食

两条喂食线：日常喂食给低血的休息 kami 喂 3 种食物；饿死救援给血量 0 的采集中 kami 喂 11 种回血食物，喂活后再决定停不停。

日常低血喂食

• 紧急锁存在跳过喂食，否则调度低血喂食 — 紧急停采进行中时整轮不喂；否则调低血喂食函数，由它自己确认有活才拿锁。hasEmergencyLock() 为真打「紧急锁存在，跳过本轮喂食」；否则 await autoFeedLowHpRestingKamis(kamiList)。触发：每轮普通锁释放后｜来历候选为 0 的常见轮次不占锁，不挡辅助脚本的合成等模块
• 低血 RESTING 候选收集 — 逐张扫描 kami 卡片，挑出正在休息且掉血够多、值得喂一口食物的 kami。状态看卡片 img[src*='/assets/kami_'] 的 src 含 resting/harvesting；血量取该图标下一个兄弟元素文本里的 (xx%)；用图号在 kami_core_db 反查 index/kamiId/maxhp（maxhp 缺省按 100），当前 HP=floor(百分比×maxhp)，缺口=maxhp-当前HP；只收 RESTING、血量可解析且缺口≥50 的。触发：被 runAutomation 末尾的低血喂食调度调用（每轮一次）｜参数MIN_GAP_BURGER=50｜来历最小食物汉堡恢复 50HP，缺口不到 50 喂了就溢出浪费
• 单只喂食失败冷却 — 同一只 kami 喂食连续失败达到次数后，冷却期内静默跳过，不再反复发失败 TX。内存 Map __feedFailedKamis 记 {count,lastFailTime}；count≥FEED_MAX_FAILS 且未满冷却时长则跳过；冷却期满自动删除记录重新尝试；喂食成功也删记录；失败时 count+1。只对有 kamiId 的记录生效，脚本重载即清空。触发：候选收集时检查；每次喂食成功/失败时更新｜参数FEED_MAX_FAILS=2；FEED_FAIL_COOLDOWN_MS=5分钟｜来历kami 卡在 STARVING 等链上异常状态时，避免反复发必败 TX 烧 gas
• 单卡解析异常静默跳过 — 某张卡片解析出错时不打断整轮，直接跳过这一张。每张卡片的解析包在 try/catch 里，catch 为空（不打日志）。触发：候选收集循环内
• 无候选早退不拿锁 — 没有需要喂的 kami 时直接结束，不查库存、不拿锁、不发 TX。候选数为 0 时打「✅ 喂食完成，无需喂食」后 return。触发：候选收集结束后｜来历多数轮次没有喂食需求，不白占锁挡住辅助脚本的合成等模块
• 钱包地址缺失早退 — 拿不到当前钱包地址时放弃本轮喂食。读 window.network.network.connectedAddress.value_，为空则打「无法获取钱包地址」并 return。触发：查询库存前
• 一次性查询三种食物库存 — 一次读出汉堡、蜜露鳞、金苹果三种食物的库存数量，后面整轮都用这份本地计数。accounts.getByOperator(addr).inventories 里按 item.index 找 11302/11312/11313 的 balance；读取抛异常则打日志并 return。代码实际：inventories 不是数组时按空数组处理，余额全算 0，随后落到「库存不足」直接放弃，没有区分「没读到」和「真没货」。触发：有候选时｜参数ITEM_CHEESEBURGER=11302(+50)；ITEM_HONEYDEW_SCALE=11312(+75)；ITEM_GOLDEN_APPLE=11313(+150)
• 库存全空早退 — 三种食物加起来为 0 时不拿锁，直接放弃并报出库存数。总数≤0 时打「库存不足：金苹果=…蜜露鳞=…汉堡=…」后 return。触发：查询库存后
• 库存档位预筛（不匹配不取锁） — 先算出手上食物最小能喂多大的缺口，把喂不了的候选筛掉；一只都喂不了就不拿锁，并建议补低档食物。有汉堡时最小档=50，否则有蜜露鳞=75，否则=150；只保留缺口≥最小档的候选；全不匹配时打日志（含库存最小档与候选最大缺口，建议补汉堡/蜜露鳞）后 return。触发：库存非空后、拿锁前｜参数MIN_GAP_BURGER/HONEY/APPLE=50/75/150｜来历曾出现只有金苹果的账户 30+ 候选逐只链上复查约 12 分钟，普通锁超时被强制释放
• 先查后锁 + 拿不到普通锁跳过本轮 — 确认真有活干后才申请普通锁；锁被别的模块占着就跳过本轮喂食，不排队等。tryAcquireNormalLock('feed','core') 失败则打「普通锁被占用，跳过本轮喂食」并 return；拿到后打候选数、可匹配数与三种库存。触发：档位预筛通过后｜来历避免空转占锁挡住其他 TX 板块
• 分批喂食与批间隔 — 把可匹配的候选按每批 3 只分组依次喂，批与批之间歇 2 秒。按 BATCH_SIZE 切片循环；最后一批之后不再等待。触发：拿到普通锁后｜参数BATCH_SIZE=3；批次间隔 2000ms
• 喂食中紧急锁让路（批前 + 每只前） — 每批开始前、每只喂食前都看一眼紧急锁，发现紧急停采来了就立刻中断喂食，把 TX 通道让出去。hasEmergencyLock() 为真时打「检测到紧急锁，中断喂食」并 break。触发：每批前、每只前｜来历紧急停采优先于一切普通操作
• 按缺口匹配食物（不浪费原则） — 缺口大的优先用大食物，恢复量绝不溢出；实在对不上宁可不喂。缺口≥150 且有金苹果→金苹果；否则缺口≥75 且有蜜露鳞→蜜露鳞；否则缺口≥50 且有汉堡→汉堡；都不满足打「无匹配食物，跳过」并 continue（此时还没发任何链上调用，也不走 1.5 秒间隔）。候选本身没有按缺口排序。触发：每只喂食时｜参数MIN_GAP_APPLE=150；MIN_GAP_HONEY=75；MIN_GAP_BURGER=50｜来历链上复查挪到匹配之后，避免为注定喂不了的候选浪费一次约 20 秒的 getByIndex；大缺口用大食物还能少发 TX
• 发 TX 前链上状态复核 — DOM 可能滞后，发喂食 TX 前再用链上数据确认这只还在休息，不在就跳过。kamis.getByIndex(index,{harvest:true}) 读 state，非 RESTING 打日志跳过且不计失败。代码实际：这次查询本身抛异常会落进 catch，被计为一次喂食失败（计入熔断和失败冷却）。触发：食物匹配通过后
• 喂食冷却公式预筛 — kami 还在 3 分钟操作冷却里时不发喂食 TX，跳过且不算失败。复用同一次 getByIndex 的 harvest.time.last，_cooldownRemainSec 算剩余秒数，>0 打「冷却中(剩余Ns)，跳过」并 continue，不写 __feedFailedKamis。time.last 读不到按无冷却处理。触发：链上复核为 RESTING 后｜参数KAMI_ACTION_COOLDOWN_SEC=180｜来历冷却中发 TX 必败，还会误触发喂食熔断，熔断只该记真失败｜版本v1.1.10
• 喂食不做 estimateGas 预检（有意设计） — 日常喂食刻意不走 gas 预检，直接发 TX。_preCheckTx 里也没有 feed 分支；实际喂食调用 api.player.pet.item.use(kamiId,itemId)。触发：每只喂食发 TX 前｜来历能用的预检路径走 system.kami.use.item，签名与封装层 api 不一致，encodeFunctionData 必抛 UNEXPECTED_ARGUMENT，预检 100% 误报；偶尔失败浪费约 100-500K gas，远好于永远不喂
• 发送喂食 TX — 通过游戏 API 给这只 kami 用上匹配到的食物。打「#N 缺口xHP → 食物名」后调用 window.network.api.player.pet.item.use(kamiInfo.id, itemId)，kamiId 取自链上复核结果。触发：通过全部前置检查后
• gas 真值账本记账（日常喂食）仅观测 — 每笔日常喂食 TX 发出后记一笔账，事后按 hash 补真实 gas，归类到喂食动作。_gasLedgerRecord('feed',[kamiId],tx)，只挂钩不改流程。触发：喂食 TX 发出后｜命令showGasReport()（定义在别处）｜版本1.2.7
• 等待上链 + 无 wait 回退 8 秒 — 等喂食 TX 上链确认；TX 对象没有 wait 方法时固定等 8 秒。typeof tx.wait==='function' 则 await tx.wait()，否则 delay(8000)。触发：喂食 TX 发出后｜参数无 wait 回退延时 8000ms
• 本地扣减库存计数 — 喂成功后在本地把对应食物数量减 1，后面的候选直接按新数量选食物，不再重复查链。按所用食物 balApple/balHoney/balBurger--。触发：每只喂食成功后｜来历省去重复查链
• 喂食失败只记日志继续 — 单只喂食报错时记下原因和失败次数，接着喂下一只。catch 打「喂食/失败 #N: 错误前60字」，批失败数与总失败数+1，写失败冷却记录。触发：喂食 TX 或链上复核抛异常时
• 相邻喂食 TX 间隔 1.5 秒 — 每喂完一只（成功或失败）歇 1.5 秒再喂下一只。delay(1500) 放在 try/catch 之后；匹配不到食物、链上非 RESTING、冷却中的 continue 不走这个间隔。触发：每只喂食后｜参数喂食间隔 1500ms｜来历防 nonce 冲突和 RPC 限流
• 单批失败熔断 — 一批里失败达到 2 只，判断为系统性问题，停止后续所有批次。batchFail≥FAIL_THRESHOLD 时打「喂食/熔断 批次N失败x个，疑似系统问题，停止喂食」并 break。触发：每批结束时｜参数FAIL_THRESHOLD=2｜来历RPC 故障、余额异常等系统性问题下防止连环烧 gas
• 批次与整轮喂食小结日志仅观测 — 每批打成功数，整轮结束打总成功/失败数。「喂食/批次N 成功x/y」与「喂食完成，成功x个，失败y个」。触发：每批结束、整轮结束
• finally 必释放喂食普通锁 — 无论喂食中途是熔断、让路还是报错，最后一定释放普通锁。try…finally 里 releaseNormalLock('feed','core')。触发：喂食流程结束
• 喂食失败冷却记录 — __feedFailedKamis 记 kamiId→{count,lastFailTime}，连续失败 2 次进入 5 分钟冷却，冷却期内不再尝试喂同一只。纯内存，由喂食模块（约 9353 行）读写；调大冷却更省 gas 但恢复更慢。触发：喂食模块失败时写入｜参数FEED_FAIL_COOLDOWN_MS=5分钟；FEED_MAX_FAILS=2｜命令clearFeedFails()｜来历避免反复失败白烧 gas
• clearFeedFails 清空喂食失败记录 — 清空 __feedFailedKamis 并返回数量。触发：命令｜命令clearFeedFails()

每轮库存盘点

• 每轮食物库存盘点日志测试线独有仅观测 — 每轮把账户里 11 种回血食物中数量>0 的列出来（名称+回血量×数量），并单独标出日常喂食能用的是哪几种。getByOperator(addr).inventories 同步本地读、零成本；食物行格式「名称+HP×数量」，全 0 时写（全部为 0）；后缀「日常喂食可用: …（日常只认汉堡/蜜露鳞/金苹果三种；饿死救援认全部 11 种，差异是设计）」。只读只打日志，不改任何判断、不发交易。触发：runAutomation 每轮，在喂食的紧急锁判断之前调用（紧急轮次也照打）｜参数INV_SNAPSHOT_ITEMS.食物 11 种（Blue Pansy/Ghost Gum/Gingerbread 25，Fetid Egg/Resin 35，Cheeseburger/Pom-Pom 50，Honeydew 75，Gakki/Paeon法术卡 100，Golden Apple 150）｜来历0912 查日志想知道账户有什么食物，13 份日志一条都没有（盘点原本只在饿死救援里，那晚救援没跑），导致给出「补汉堡/蜜露鳞」的错误建议，其实账户里有 Pom-Pom 和 Gakki｜版本测试版1.2.40
• 日常/救援食物清单差异标注测试线独有仅观测 — 在盘点日志里把「日常喂食只认 3 种、饿死救援认 11 种」直接标出来，一眼分清没喂是因为没货还是这档食物不在日常清单里。DAILY_FEED_ITEMS = Set(11302,11312,11313)，与 autoFeedLowHpRestingKamis 保持一致，用于过滤出「日常喂食可用」。触发：随每轮库存盘点｜参数DAILY_FEED_ITEMS={11302,11312,11313}｜来历当时没标清楚，把有意设计当成 bug 改了两版｜版本测试版1.2.40
• 库存盘点其他道具行（复活丝带 + 步长道具）测试线独有仅观测 — 同一轮再打一行：复活丝带数量，以及 5 种步长道具的库存。「复活丝带×数量 ｜步长道具: 名称+值×数量」，步长道具为 Ice Cream 20、Better 40、Best 80、Candyfloss 80、Neith卡 80，全 0 写「无」。触发：随每轮库存盘点｜参数复活丝带 item 11001；步长道具 21201~21205｜版本测试版1.2.40
• 盘点读不到时区分「没读到」和「空」测试线独有仅观测 — 库存数组读不到时明确写「不是空，是没读到」，避免把读取失败误读成没货；任何异常都不影响主流程。无钱包地址静默 return；inventories 不是数组打「读不到 acc.inventories（不是空，是没读到）」；整体 try/catch，异常打「读取异常（不影响主流程）」+前 80 字。触发：随每轮库存盘点｜版本测试版1.2.40
• 库存盘点放在紧急锁判断之前测试线独有仅观测 — 每轮在喂食锁判断之前先打库存盘点，紧急轮次也照打。_logInventorySnapshot()。触发：每轮停采/部署段之后｜来历紧急轮次正是最想知道库存的时候｜版本测试版1.2.40

饿死救援 · 主循环入口

• 饿死 kami 地块核对（跨地块只提醒） — 逐只查饿死 kami 在哪个地块采集，不在当前地块的无法喂，打醒目日志请用户手动处理。getByIndex({harvest:true}) 读 harvest.node.index，与 __getMyRoomIndex() 不同则进其他地块列表；打橙色「饿死救援/地块不匹配 当前地块: 名称，N 个STARVING kami在其他地块，请手动处理: #编号(地块x)」。触发：停采池中有 isStarving 候选｜来历跨地块发喂食注定失败，只提醒不操作
• 地块读不到时保守保留 — 查地块失败或当前地块未知时，仍把这只饿死 kami 留在救援队列，宁可多试不漏救。当前地块或采集地块为 null 时不判不匹配；getByIndex 抛异常直接进救援队列。触发：地块核对时
• 同地块饿死 kami 批量救援喂食测试线独有 — 对同地块的饿死 kami 先批量喂一轮食物（支持 11 种回血食物，按库存自动选），喂活且确认上链、仍在停采线下的随本轮停采批带走。打橙色「发现 N 个STARVING的kami，需先喂食」，await _starvingFeedKamis(list,'普通/饿死救援',{yieldToEmergency:true})，开紧急让路、不设 deadline；fedCount>0 打「已喂食 N 个kami，直接进入停采流程」。救援函数喂后复查会原地翻 isStarving 并更新 delta。触发：救援队列非空｜来历0 血 kami 游戏规则要求先喂食回血才能 Stop｜版本测试版1.2.45

饿死救援 · 预查与食物分配

• 救援食物表 — 11 种非复活类 HP 恢复食物：Blue Pansy/Ghost Gum/Gingerbread Cookie(+25)、Fetid Egg/Resin(+35)、Cheeseburger/Pom-Pom Candy(+50)、Honeydew Scale(+75)、Gakki Cookie/Paeon Spell Card(+100)、Golden Apple(+150)。表内按 HP 升序便于阅读，选食时降序；复活类道具留给复活模块；增删条目即可调整范围。触发：救援选食时｜参数STARVING_FOOD_LIST｜来历救援喂大食物优先，一次到位省 tx｜版本1.2.2
• 救援函数整函数互斥 — 普通停采与紧急停采两条路径同时调救援时，先到先做，后到者直接返回 0 并打「另一条救援路径正在喂食同一批，本轮跳过」。window.__starvingFeedRunning 标志，finally 中复位。触发：_starvingFeedKamis 入口｜来历0825 实盘两路并发，3 只 kami 各被重复喂食一次白烧食物+gas，并加剧 mempool 拥堵；根因是两路富化都在任何喂食落地前完成（TOCTOU）｜版本1.2.23
• 救援起始时刻全局标记测试线独有 — window.__starvingFeedSince 记录救援开始时刻，结束清零。供紧急停采的 waitForStarvingFeedDrain 判断救援进行了多久。触发：_starvingFeedKamis 入口/出口｜版本测试版1.2.45
• 紧急路径喂食截止时刻测试线独有 — 紧急停采调用时传 deadlineMs（now+90秒），每只发送前检查，到点 break，剩余交下一轮并打「喂食阶段已到时间上限」。日常救援不传 → Infinity，行为逐字节不变；未发送的没记账，下轮会被重新捞起。触发：紧急停采 Step 4.5 调用｜参数FEED_PHASE_CAP_MS=90000｜来历不让喂食把紧急停采的时间预算吃光｜版本测试版1.2.43
• 日常救援遇紧急锁立即让路测试线独有 — 普通路径传 yieldToEmergency:true；每只发送前若出现别人设的紧急锁就 break，打「紧急停采已接管，立即让路，剩余交给紧急停采的饿死救援接手」。只让路不设 deadline；互斥此刻已释放，由紧急停采 Step 4.5 接着喂同一批。触发：普通停采调用 _starvingFeedKamis 时｜来历这是核心里唯一漏做让路的发 tx 循环：停采走 raw、救援走 queue 同时在飞就是双账本 nonce 分叉（0710 定案 46 起撞号）；0815 那次 1105 只死亡雪崩根因正是只在循环前查一次锁｜版本测试版1.2.45
• 单次库存查询与本地余额表 — 一次 getByOperator 取回账户全部 inventories，建立「食物 index→余额」表，只收余额>0 的。之后全程不再逐只查询链上库存。触发：救援 Step 1｜来历少 RPC、快速批量救援
• 库存查询异常不放弃（defer） — 库存查询抛错时打「查询库存失败」和「库存读取疑似前端失真，本轮不放弃 starving，defer 到下轮重试」。注释写「直接返回 0，本轮放弃救援」，代码实际同样 return 0，但语义改为 defer（下轮重试）。触发：救援 Step 1 异常｜来历实盘上前端失真被当成无库存放弃喂食导致饿死（Bug B）｜版本v1.1.25
• 食物全 0：失真 defer / 真空红字告警 — 一种可用食物都没有时：前端冻结或读数可疑（inventories 非数组或空数组）→ defer 不告警；否则红色告警「所有HP恢复食物库存为0，请手动处理」并列出全部候选编号。invReadSuspicious 在读库存时判定。触发：救援 Step 1 后｜来历冻结/空数组读数曾走红字放弃整批｜版本v1.1.25
• 可用食物摘要日志仅观测 — 打印「🍔 可用食物: 名称(+HP)×余额, …」。纯日志。触发：救援 Step 1 后
• 8 路并发预查（worker 抢号） — 8 个 worker 共享 nextI 指针抢号处理每只 kami 的预查，结果按原顺序写回。Promise.all 等全部完成。调大更快但 RPC 压力大。触发：救援 Step 2｜参数CONC=8｜来历避免逐个串行等待
• 补 kamiId 两级兜底 — 候选只带 dbIndex/imgNumber 时先查本地 kami_core_db（按 imgNumber 或 index），查不到再走链上 getByIndex(dbIndex,{}) 取 id，仍拿不到记「无法获取kamiId」跳过。触发：救援 Step 2
• 链上 24h 无 tx 疑似卡链先试喂一次 — harvest.time.last 距今超过 24 小时只算卡链嫌疑：首次照常喂食抢救（标 stuck24hTrying），近期试过仍饿着才真跳过。板块注释仍写「超过24小时跳过」，代码实际是先试一次；查询失败不阻断后续。同时把 time.last 存到 out 上供冷却预筛复用。触发：救援 Step 2｜参数STARVING_STUCK_TIME_MS=24小时｜来历用户 0825 定案：旧码一次扫描 238 只 STARVING 里 232 只被无差别跳过只喂 6 只；24h 无 tx 也可能是长挂机刚醒、索引滞后，一次喂食成本仅 1 笔 tx+1 个食物。1.2.24 撤销了 1.2.23 的单轮限流，因为 STARVING 是活着的 0 血，不能等下一轮｜版本1.2.22
• 卡链试喂闸两档（6h / 30min）测试线独有 — window.__stuck24hTried 记每只 kami 上次试喂：有链上实锤（confirmed）→ 6 小时内不再试；无实锤 → 30 分钟短闸；旧版遗留的裸时间戳一律当未实锤走短闸。window 级 Map，会话内有效，刷新后重来一次可接受。触发：救援 Step 2 判卡链时｜参数STUCK_RETRY_COOLDOWN_MS=6小时；STUCK_RETRY_SHORT_MS=30分钟｜来历用户 0912 复现：1.2.43 用 Number(tx.status)===0 判 revert，raw 返回无 status、queue 形状未实测，判据在两通道都是死代码，100% 登记 6h；改后判错代价是多试一次而非 0 血 kami 锁死 6 小时｜版本测试版1.2.45
• S2 链上检查点 HP 纯观测仅观测 — 每次救援调用至多 1 次查 stats.health，打印 sync/total/keys/time.last（标定用非判据）；不可读也打一条 statsKeys。尝试即置位防每只每轮空发 RPC；独立 try，异常不拖累主链路。触发：救援 Step 2 首只｜来历原链上 HP 闸门发布前被异源审 REJECT 砍掉：sync 是上次 tx 检查点非实时，真饿死的 sync 系统性偏高，闸门会精准误拦最需要喂的；勿复活｜版本1.2.2
• 重复喂食熔断（保护2） — __starvingFedRecord 记喂食次数；累计≥2 次且在 30 分钟内的跳过（skipReason alreadyFedNStuckMm），冷却过期则清记录允许重试。按代码推演：该记录只有本函数写入，且 Step 3 发送前复查会跳过 30 分钟内喂过 1 次的，count≥2 分支在本函数自身写入路径下实际难以触达。喂食路径不读停采黑名单（保持解耦）。触发：救援 Step 2｜参数STARVING_STUCK_THRESHOLD=2；STARVING_STUCK_COOLDOWN_MS=30分钟｜命令clearStarvingStuck()｜来历防止对救不回来的 kami 反复浪费食物和 gas
• 逐只停采预检（能停就不喂）已停用 — 旧逻辑：对每只先 _preCheckStop(estimateGas)，能停说明实时 HP>0 无需喂食。已砍除。板块注释仍写有这一步，代码已无；stopOk 恒 false，「停采预检通过无需喂食」日志与汇总里「API验证HP>0跳过N个」分支成为死代码。来历：用户 0825 定案：196 只×RPC÷8 ≈ 3 分钟，这批 0 血 kami 一口没吃，杀手来就全灭；及时性远大于省几个食物（金苹果库存 1500+）｜版本1.2.24
• 单只预查异常隔离 — 单只 kami 预查中任何异常只记 skipReason=preQueryError 跳过它自己，不影响其他只。外层 try/catch 包每只。触发：救援 Step 2
• 全量食物预分配 — 发第一笔 tx 前用本地 kami_core_db.maxhp 当缺口给全部待喂分配食物：选 HP≤缺口的最大有库存食物（不浪费前提下加血最多）；都超缺口取最小有库存的；读不到 maxhp 直接取最大；边分边扣工作库存。零链上调用；板块注释写「按HP降序取第一个有库存」，代码实际是上述不浪费规则。触发：救援 Step 2.5｜来历1.2.24 编辑事故此块未落盘，致 plannedFood 全空、151 只被静默跳过、发送 0，本版补齐｜版本1.2.25
• 食物分配报告与不足告警 — 蓝色打印「食物分配完成：N只可喂（食物×数量）」；有没分到的红字「食物不足，另有N只没分到，请尽快补货（Mina 商店）」；否则提示「食物充足，接下来连续发送」。触发：救援 Step 2.5 后｜来历0 血 kami 停不了采也躲不了杀手，喂食是唯一救法｜版本1.2.25
• 0 分配防复发 guard仅观测 — 有候选却 0 只分到食物时打红色大字🚨「若食物有库存仍见此条，请把日志发给维护者」。决不静默。触发：救援 Step 2.5 后｜来历防 1.2.24 那种逻辑坏掉静默不发的事故复发｜版本1.2.25
• 无分配食物静默跳过 — 预分配阶段没分到食物的 kami 在发送循环里直接跳过。Step 2.5 已打过食物不足红字。触发：救援 Step 3｜版本1.2.24
• clearStarvingStuck 清空重复喂食熔断 — 清空 __starvingFedRecord，立即允许重新喂食，返回数量。不清 window.__stuck24hTried（卡链试喂 6h/30min 闸）。触发：命令｜命令clearStarvingStuck()｜来历手动处理完卡住的 kami 后调用

饿死救援 · 发送通道与 nonce

• 救援喂食通道开关 — setStarvingFeedChannel('raw'|'queue') 切换救援喂食通道，下轮救援生效；默认 queue（MUD 队列 api，稳）。非法参数打印用法与当前值；注释曾写默认 raw，1.2.29 起以 localStorage 读取默认 'queue' 为准；读取异常也回 queue。触发：命令；救援时读取｜命令setStarvingFeedChannel('raw') / setStarvingFeedChannel('queue')｜存储kami_starving_feed_channel｜来历用户 0825 定案：raw 当晚两翻车（旧地址/nonce 空洞），默认回归 api，raw 留作测试开关，单机实测喂后复查≈发送数后再考虑转正｜版本1.2.29
• raw 直发并行喂食 — raw 模式下手拼 calldata（选择器 0xe60f3a76 + kamiId + 食物index 各 32 字节）、显式递增 nonce 直接 sendTransaction，提交即返回，真正连发。默认不启用，需 setStarvingFeedChannel('raw')；要求 signer.sendTransaction 与 provider.getTransactionCount 可用；不走 ABI 编码。queue 模式下本函数不自取任何锁。触发：救援 Step 3（raw 通道）｜参数FEED_RAW_SELECTOR='0xe60f3a76'｜命令setStarvingFeedChannel('raw')｜存储kami_starving_feed_channel｜来历MUD 队列串行，0825 实测 60~75 秒/笔，133 只≈2 小时；raw 同停采批量打法约 1~2 分钟｜版本1.2.27
• raw 先加锁→排空→再读 nonce测试线独有 — raw 模式先设紧急锁（若还没有）关死普通通道，再等在飞普通操作让出（最多 30 秒，打「等待普通操作让出通道后再读 nonce」），最后读 pending nonce 作起点。waitForNormalLockRelease 返回值未检查：30 秒后仍被占也会继续读 nonce。救援全程持紧急锁独占 tx 通道。触发：raw 模式初始化｜参数等待 30000ms｜来历旧顺序先读 nonce 再加锁留有裸窗口，普通操作塞进一笔即抢号整串错位（0710 同型 46 次冲突）｜版本测试版1.2.43
• 运行时解析 use.item 合约地址 — 从 txQueue.systems['system.kami.use.item'].target 取当前合约地址；解析不到则本轮回退 MUD 队列并打「绝不打硬编码地址」。FEED_RAW_SELECTOR_ONLY 常量定义但未被使用。触发：raw 模式初始化｜来历0825 血训：游戏 patch 重新部署系统合约，旧地址成僵尸（写权限注销）157 笔全灭；铁律严禁硬编码系统合约地址｜版本1.2.28
• 按真实通道打印发送模式测试线独有仅观测 — 真在 raw 时打「raw直发模式:合约(运行时解析),nonce起点,回退命令」；否则打「走 MUD 队列(api)通道逐笔发送」。纯日志。触发：raw 初始化完成｜来历0911 审计：地址解析失败已回退却仍打「raw直发 合约=null」，误导读日志的人｜版本测试版1.2.35
• raw 初始化失败回退队列 — raw 初始化任何异常 → 本轮回退 MUD 队列逐笔发送并打日志。触发：raw 模式初始化异常｜版本1.2.27
• raw 批 gasLimit 实测估算测试线独有 — 每批第一笔 estimateGas 一次，×1.5 余量并压 4,000,000 地板，全批复用；估不出来直接给 4,000,000，并打估算日志。不逐只估；链上按 gasUsed 计费，gasLimit 给大不浪费。触发：raw 批首笔发送前｜参数余量×1.5；地板 4000000｜来历0911 实盘：写死 2M 而实际需 2.85M，gasUsed 1,998,856 out of gas；同一 kami Ghost Gum 估 2.85M、Gakki Cookie 1.87M 差 52%，只估一次可能恰好估到最便宜的｜版本测试版1.2.35
• raw nonce 成功才自增 + 失败重新对账 — 只有 sendTransaction 成功后 nonce 才 +1；发送失败时重新读链上 pending nonce 并等 2 秒再继续。触发：raw 发送｜参数失败后等待 2000ms｜来历0825 实锤：nonce 空洞卡死后续 101 笔；失败不烧号、防空洞防重号｜版本1.2.28
• raw 批里法术卡挪到批尾 api 段测试线独有 — raw 批中选中 Paeon Spell Card(11305) 时不当场走 api，登记进待补发列表，整批 raw 发完后由 api 补发段统一发。打「选中法术卡(只有api入口)，挪到批尾api段统一发，避免与raw混用nonce」。触发：raw 发送循环｜来历在 raw 连发中间插一笔 MUD 队列 tx 会造成两套 nonce 交错分叉｜版本测试版1.2.43
• 法术卡 cast / 食物 use 入口分流测试线独有 — 11305 Paeon Spell Card 走 api.player.pet.item.cast，其余食物走 .use；只有确实要走 api 时才检查入口是否可用，不可用打日志跳过该只。触发：救援发送｜来历0911 审计：旧守卫无条件挡在 raw 前，raw 根本不用 apiFn 却因其缺失白白放弃救援｜版本测试版1.2.35
• queue 通道 await 实为等上链测试线独有 — api.player.pet.item.use() 实测 722~2148ms 才 resolve，返回 {hash, receipt}，没有 wait() 方法——即等到上链才返回，链上成败可当场判；raw 提交即返回无回执只能事后对账。函数 docstring 仍写「await apiFn() 仅等 nonce 分配，fire-and-forget」，与 1.2.46 实测不符，以实测为准；每笔另加 300ms 间隔。触发：救援 queue 通道发送｜来历藏在共享前提里的错，异源交叉验证纠不出来，只有实盘能纠｜版本测试版1.2.46
• 喂食发送节奏 — raw：每笔间隔 150ms，每 10 笔歇 1.2 秒（批量分批）；queue：每笔 300ms。调小更快但 nonce 排队冲突风险升高。触发：喂食发送成功后｜参数raw 150ms/1200ms；queue 300ms｜来历让 nonce 排队稳定｜版本1.2.27

饿死救援 · 发送、补发与喂后复查

• 喂食冷却预筛 — 发喂食 tx 前算操作冷却剩余，冷却中跳过（tx 必败），不计失败、不进喂食记录，单独计数，下轮自动重试；打「⏳ 冷却剩余Ns（time.last age=Xs），跳过本次喂食」。复用预查已读到的 time.last，零额外链上查询（注释写复用 Step 1，实际来自 Step 2 预查）。触发：救援 Step 3 每只｜参数KAMI_ACTION_COOLDOWN_SEC=180｜版本1.1.11
• 发 tx 前实时复查已喂记录 — 用最新 __starvingFedRecord 再查一次，30 分钟内已被喂过就跳过并打「刚刚已被喂过（N秒前），跳过重复喂食」。Step 2 富化那次只是快照，可能已过去几分钟。触发：救援 Step 3 每只｜参数STARVING_STUCK_COOLDOWN_MS=30分钟｜来历期间可能已被别的路径或上一轮喂过｜版本1.2.23
• 卡链抢救性试喂提示仅观测 — 对 stuck24hTrying 的 kami 橙色提示「链上已N小时无tx（疑似卡链），先尝试喂食一次抢救；若无效6小时内不再重试，请手动处理」。纯日志。触发：救援 Step 3｜来历明确告知用户这是抢救性尝试｜版本1.2.22
• 卡链试喂登记：发送成功后按回执三态测试线独有 — 只有 tx 确实交出去才登记试喂：回执 status=0 → 不登记（打「链上revert，不登记冷却，下一轮继续救」）；status=1 → 登记 confirmed 走 6h 长闸；拿不到回执（raw）→ 登记未确认走 30min 短闸。读 __feedTx.receipt.status（Number('0x1')===1）。触发：救援发送成功后｜来历旧码先登记再发，发送抛错也被锁 6 小时，断网夜整批饿着锁死；0913 控制台实测 api 返回 {hash, receipt}、receipt 已是完整回执、顶层无 status，此前 Number(tx.status)===0 在两通道都是死代码｜版本测试版1.2.46
• 喂食 gas 真值账本记账仅观测 — 每笔喂食（主循环与补发）调用 _gasLedgerRecord('feed', [kamiId], tx)。记账不影响发送。触发：喂食发送成功后｜版本1.2.7
• 记录喂食 tx hash测试线独有 — 发送成功后把 hash 存到 info.__feedTxHash，补发成功的也存。供喂后复查按 hash 查回执。触发：喂食发送成功后｜来历补发的不留 hash 会被复查一律判未落地，转停覆盖率变差｜版本测试版1.2.43
• 喂食次数记账与疑似卡链提示 — 发送成功后 __starvingFedRecord 次数+1、记时刻；累计≥2 次打红字「已累计喂食N次仍是STARVING，疑似卡链，后续将跳过（冷却30分钟），请手动处理」。触发：喂食发送成功后｜参数STARVING_STUCK_THRESHOLD=2
• 本地扣减库存余额 — 每喂一只在 balMap 里扣 1，扣到 0 删除，不再重复查链上库存。预分配上线后选食改用 plannedFood，balMap 扣减之后不再被读取，属残留记账。触发：喂食发送成功后
• 单只发送失败不中断整批测试线独有 — 某只发送抛错时打「喂食tx发送失败」（截断 160 字），登记待 api 补发，继续下一只。失败未写喂食记录，不会被永久丢弃。触发：喂食发送异常｜版本测试版1.2.35
• 失败补救段：api 逐只补发一次测试线独有 — 主循环跑完后，对发送失败的与 raw 批挪来的法术卡，用 api 通道逐只再发一次；补发再失败交下一轮，不无限重试；结束打红/绿汇总「补发完成：成功N只，仍失败M只」。补发成功同样记 gas 账本、hash、试喂登记（按回执三态）、喂食次数，每笔间隔 300ms。触发：救援 Step 3 结束且有待补发｜来历0911 审计：catch 只打日志就滑走，本轮不再尝试；用户 0825 规矩「饿死的不能等下一轮」、0911「至少把 api 作为备选」；raw 失败多为 nonce 错位/池满，同路重试大概率同样死，api 由队列统一管 nonce｜版本测试版1.2.35
• 补发段让路与宽限上限测试线独有 — 补发每只前：日常路径遇别人设的紧急锁则让路 break；超过喂食截止+30 秒宽限则 break 并报剩余只数；api 入口不可用计补发失败。触发：补发循环每只｜参数FEED_TAIL_GRACE_MS=30000｜来历补发段也要有上限，不能吃掉紧急停采预算｜版本测试版1.2.43 / 测试版1.2.45
• 补发前复查防重复花钱测试线独有 — 补发前再查喂食记录，30 分钟内已被喂过就跳过补发。触发：补发循环每只｜来历万一刚才那笔其实发出去了、或别的路径已喂过｜版本测试版1.2.35
• 喂后复查·当场转停测试线独有 — 等 20 秒后逐只按 hash 查回执，status===1 才信链上 sync HP：喂活则更新 hpPercent/delta 并把 isStarving 翻 false，delta≤1 的由紧随其后的停采批带走；没 hash/无回执/status≠1 → 保持 isStarving 只喂不停，下轮再救。只读 provider（_gasLedgerProvider）绝不发 tx；代码仅在 raw 模式且发送数>0 时执行，默认 queue 通道不做喂后复查；异常打日志不影响已发喂食。触发：救援发送与补发结束后（raw 模式）｜参数__postWaitMs=20000｜来历sync 是上次 tx 检查点：tx 还堵在池里时读到 sync=100 会误判喂活，把 0 血 kami 塞进停采批必 revert（0825 实测 10/10 CALL_EXCEPTION）；宁可多饿一轮也不塞进停采批｜版本测试版1.2.43
• 喂后复查实锤升 6h 长闸测试线独有 — 喂后复查拿到 status=1 回执的卡链试喂 kami，登记 confirmed:true，之后走 6 小时长闸。触发：喂后复查｜参数STUCK_RETRY_COOLDOWN_MS=6小时｜来历确实喂进去却还饿着才算真卡链，防对真卡死的反复烧 gas｜版本测试版1.2.45
• 喂后复查结果日志测试线独有仅观测 — 打印未见回执实锤只数（保持只喂不停），以及「N只已确认喂活(M只在停采线下转入本轮停采)，K只确认未到账」。纯日志。触发：喂后复查结束｜版本测试版1.2.43
• 紧急锁归属令牌释放测试线独有 — 救援只释放自己设的那把紧急锁：比对取锁时保存的对象引用，不是同一把就不动并打「紧急锁已被他人重设，本轮不释放」。注释提到 720s 强制释放兜底；代码里紧急锁的超时自愈实际是 TX_EMERGENCY_TIMEOUT=600000（10 分钟），720s 是过时注释。触发：救援收尾（raw 模式设过锁）｜来历持锁期间锁被强制释放后紧急停采重新取锁，旧逻辑只看布尔会掐掉别人正在用的锁｜版本测试版1.2.43
• 救援汇总日志与返回值仅观测 — 打印「汇总：N个候选 → 发送M个，冷却预筛跳过K个（下轮重试）」，返回成功交出去的笔数 fedCount。冷却跳过单独展示，便于和其他跳过区分复盘。触发：救援结束｜版本1.1.11

1.7 复活

用复活丝带批量复活死亡 kami。和辅助脚本的启动窗口复活（2.6）共用一张 15 分钟防重发表，不会重复花丝带。

• 本轮死亡 kami 批量复活 — 每轮最后把扫描中收集到的死亡 kami 交给批量复活函数一次处理。await _reviveDeadBatch(__deadToRevive)，锁、分批、重试都在函数内部处理；放在停采和喂食之后。触发：每轮 runAutomation 末尾｜来历停采/喂食是保命操作优先；死亡 kami 不会再有进一步损失，垫后不吃亏；逐只复活在慢链下会被自己上一笔长时间占锁挡住
• 复活统一走链上 API 的约定 — 注释约定：复活操作统一通过链上 API 完成，不走 DOM 点击。本段仅为约定注释，实现在复活模块。来历：DOM 复活路径不可靠
• 批量复活主流程（复活丝带） — 发现死亡 kami 后，用复活丝带 Red Ribbon Gummy(#11001) 在一次普通锁内逐只串行发复活 tx，复活成功回 10 HP。_reviveDeadBatch(deadList)：合并名单 → 15 分钟防重发过滤 → 查丝带库存 → 按丝带数截断 → 单轮上限 30 → 查锁 → 逐只发 pet.item.use(kamiId,11001) → finally 释放锁。触发：自动：死亡监控发现死亡时不等主循环，立即 fire-and-forget 调 _reviveDeadBatch([])；主循环扫描收尾 await _reviveDeadBatch(__deadToRevive)；辅助脚本启动窗口复活是第三路，三路靠锁和防重登记互不重发｜参数REVIVE_RIBBON_ID=11001；REVIVE_RETRY_COOLDOWN_MS=15分钟；REVIVE_MAX_PER_ROUND=30｜来历复活放在停采/喂食之后：已死的 kami 不会再有损失，保命操作优先
• API 全量查死亡名单补 DOM 漏扫 — 复活名单以链上 API 查到的 state=DEAD 为准，DOM 扫描名单只当底本，把 DOM 漏掉的死亡 kami 补进来。getByOperator(当前地址) 取 acc.kamis 过滤 DEAD；按 dbIndex 去重后追加；补进了几只就打橙色日志「API 全查补充 N 只」。触发：每次调用 _reviveDeadBatch 时｜来历网络慢时 party 列表渲染不全，只信 DOM 会让没渲染出来的死亡 kami 永远进不了复活流程
• kamiId 三级反查 — 给 API 补进来的死亡 kami 找 kamiId：先查本地映射表，再用 API 返回的 id，最后单独调 API 反查。先查 window.kami_core_db 按 index 找 kamiId，其次用 k.id，都没有再调 explorer.kamis.getByIndex(index)；这一步出错静默吞掉，最终还是没有 kamiId 的就不加入名单。触发：API 全查补充名单时｜来历优先走本地映射表，省一次网络请求
• API 全查失败降级只按 DOM 名单 — API 查死亡名单出错时不中断，改为只处理 DOM 扫描出来的名单。整段 try/catch，报错时打「API 死亡全查失败…仅按 DOM 扫描名单处理」；合并后名单为空就直接 return。触发：getByOperator 等调用抛异常时
• 复活 15 分钟防重发冷却 — 同一只 kami 发出复活 tx 后 15 分钟内不再重发，防止慢链确认期间重复消耗丝带。window.__reviveSentAt 是 Map<kamiId,发送时间>；过滤掉距上次发送不足 15 分钟的，并打「N 只在 15 分钟内已发过复活tx（慢链确认中），本轮不重发」；全被过滤就 return。登记只在内存，刷新页面清空；已存在的 Map 不覆盖（跨调用共享）。触发：每次复活前｜参数REVIVE_RETRY_COOLDOWN_MS=15*60*1000｜命令window.__reviveSentAt.clear()｜来历慢链下 tx.wait 会卡几十秒，不防重就会对同一只重复发 tx、重复烧丝带
• 复活防重登记清空命令 — 手动清空复活防重登记，让刚发过复活 tx 的 kami 可以立刻重发。控制台执行 window.__reviveSentAt.clear()；适用于确认丝带没被消耗、需要马上重发的情况。触发：命令｜命令window.__reviveSentAt.clear()
• 丝带为 0 时红字提醒购买且不发 tx — 背包里一个复活丝带都没有时，大号红字提醒去 Mina 商店购买，本轮一笔 tx 都不发。从 acc.inventories 找 item.index=11001 的 balance；≤0 时打 14px 红字（GDA 浮动价，基价约 100 musu）后 return。触发：每次复活流程查库存时｜参数REVIVE_RIBBON_ID=11001｜来历防止每轮白发注定失败的 tx 烧 gas
• 丝带库存查询失败按有货处理 — 查不到丝带库存时，保守地假设丝带够用，照样尝试复活。catch 里把 ribbons 设成待复活数量并打日志「保守按有货尝试」。触发：库存查询抛异常时｜来历宁可多发一笔 tx，也不漏掉复活
• 丝带不足时截断名单并提醒补货 — 丝带比死亡 kami 少时，本轮只复活名单前 N 只（N=丝带余额），并提示补货。fresh.slice(0, ribbons)；名单顺序没有排序，就是 DOM 名单在前、API 补充的在后；截断时打橙色「丝带仅 X 个 < 死亡 Y 只…请补货」。触发：丝带余额小于待复活数时
• 单轮复活上限 30 只（限流分轮） — 每轮最多复活 30 只，剩下的交给下一轮死亡扫描（约 3 分钟后）接着救，避免一次性长时间独占 TX 锁。byRibbon.slice(0, 30)；超出时打三行说明：本轮救几只、为什么限流、剩几只预计几轮救完（丝带不浪费、不会重复发 tx、无需人工干预）。触发：待复活数超过 30 时｜参数REVIVE_MAX_PER_ROUND=30｜来历0815 实盘 1105 只死亡雪崩：一次复活 215 只≈215 笔 tx、10~18 分钟独占普通锁，喂食/部署/停采/拾荒全被卡住，反而害死更多 kami；分轮后每轮锁占用降到约 1.5 分钟｜版本1.2.21
• 复活前检查紧急锁与普通锁 — 准备发复活 tx 之前，有紧急锁或普通锁被占，就整轮跳过，下轮再试。hasEmergencyLock() 为真时打「紧急锁存在，本轮跳过复活」；tryAcquireNormalLock('revive','core') 抢不到时打「普通锁被占用（可能上一轮复活tx仍在确认）」。触发：每轮进入发 tx 阶段前
• 复活循环逐笔让路紧急停采 — 每发一笔复活前都查一次紧急锁，一旦杀手来袭触发紧急停采，立刻中断剩余复活让出 TX 通道。循环内 hasEmergencyLock() 为真就打橙色让路日志（已复活几只、剩余几只延后）后 break。注释写「已复活」，代码实际 __revDone 在发 tx 前就自增，统计的是已尝试发送数，包含失败的。触发：复活循环每只 kami 发送前｜来历0815 雪崩：旧码只在循环开始前查一次紧急锁，实测紧急停采干等复活跑完卡死 353 秒，该停的没停继续被杀；紧急停采救的是活着的，复活的已经死了，多等一轮零损失｜版本1.2.20
• 复活冷却观察日志（180s 窗）仅观测 — 只打日志不改逻辑：记录每只死亡 kami 的 harvest.time.last 距今多久、有没有落在 180 秒操作冷却窗内，以及复活成败，用来统计复活受不受冷却影响。发 tx 前每只额外调一次 getByIndex(index,{harvest:true})；有值打「age=Xs（⚠️在180s冷却窗内/已过冷却窗）」，查不到打「查不到 time.last」；发完再打「age=Xs 时复活结果=成功/失败(原因)」，age 沿用发送前查到的值、不再重查（省一次 RPC）。查询失败不影响复活。触发：复活循环每只 kami｜参数冷却窗 180s（写死在日志判断里）｜来历复活对象是 DEAD kami，它的 time.last 是否受同一冷却计时器约束没有实盘验证，所以只观察、不预筛，留待 grep 统计后再决定要不要加预筛｜版本1.1.11
• 发送前登记、发送异常撤销登记 — 发复活 tx 之前先登记防重；如果发送本身抛异常（tx 没发出去），就删掉登记，允许下轮立刻重试。__reviveSentAt.set 在 use() 之前；catch 里 __reviveSentAt.delete 并打红字「发送失败」。触发：每只 kami 发复活 tx 时｜来历防止同一轮或下一轮对同一只重发
• 复活确认 45 秒超时（三态结果） — 等复活 tx 上链确认最多 45 秒，超时只记日志不卡整批，下轮死亡监控会自动核查。Promise.race(tx.wait→'ok'/'revert', 45s→'timeout')。ok 打绿字成功；timeout 打「tx已发出但确认超时（慢链），15分钟内不重发」且不删登记；revert 打红字执行失败。触发：tx 对象带 wait 函数时｜参数确认超时 45000ms｜来历慢链下 tx.wait 可能卡几十秒，不加超时会拖慢整批复活
• 无 wait 函数时按已发出视为成功 — API 返回的 tx 对象没有 wait 方法时，直接当作复活 tx 已发出，算成功。typeof tx?.wait !== 'function' 时打「复活tx已发出」，结果标注「(已发出未confirm)」。触发：use() 返回值不带 wait 时
• 复活 gas 账本记账 — 每笔复活 tx 记进 gas 真值账本，分类为 revive。_gasLedgerRecord('revive', [kamiId], tx)，拿到 hash 后由账本后台补回执算 gas。触发：每笔复活 tx 发出后｜命令showGasReport()（账本报告，定义在别处）｜版本1.2.7
• 复活间隔 1.2 秒 — 相邻两只复活 tx 之间固定间隔 1.2 秒。每只处理完 await delay(1200)。触发：复活循环每只之后｜参数delay(1200)｜来历配合锁，防止 nonce 冲突
• 复活锁在 finally 中必定释放 — 无论复活成功、失败还是中途异常，普通锁都会被释放。try/finally 里执行 releaseNormalLock('revive','core')。触发：复活流程结束时｜来历避免锁被带走，卡死其他模块

1.8 拾荒

采集点的拾荒次数（rolls）攒到 1000 次自动领取。

• 自动拾荒领取主流程 — 打开当前采集点 Node 面板读累计拾荒次数 rolls，攒到 1000 次以上就点 Scavenge 按钮，一笔 tx 领取全部奖励。等 5 分钟 → 查紧急锁 → 点 Harvest 按钮开面板 → 解析 rolls → 未达门槛关面板返回 → 抢普通锁点 Scavenge → 释放锁 → 关面板。注释写「由主循环按周期调用」，代码实际只在页面加载的启动序列里调用一次（页面约每 45 分钟+随机刷新）。触发：自动：启动序列里 autoScavenge()，每次页面加载跑一轮｜参数rolls 门槛=1000（写死）｜来历攒一大批再一次领取 = 减少 TX 次数、省 gas
• 拾荒模块健康心跳仅观测 — 模块启动时写一个存在性时间戳，供辅助脚本的健康看板判断模块是否在运行。window.__kamiHealthBeats['拾荒'] = Date.now()（跨脚本全局变量）。触发：autoScavenge 入口（每次页面加载一次）
• 拾荒入口固定等 5 分钟错峰 — 拾荒流程启动后先等 5 分钟再动作，和其他模块的启动时序错开。await delay(5*60*1000)。触发：autoScavenge 入口｜参数delay(5*60*1000)
• 拾荒遇紧急锁整轮跳过 — 有紧急锁时本轮不拾荒。hasEmergencyLock() 为真时打「紧急锁存在，跳过拾荒」后 return。触发：等待 5 分钟结束后
• 拾荒先查后锁 — 开面板、读 rolls 都是纯 DOM 读取，不占锁；只有真正点 Scavenge 发 tx 时才进普通锁。锁在 rolls≥1000 之后才申请。触发：每轮拾荒｜来历rolls 不够时不白占一趟锁，免得挡住合成、喂食等模块
• 按图标路径识别 Harvest 按钮 — Harvest 按钮没有稳定的 id/class，靠按钮里图片地址匹配 assets/harvest-*.png 找到它并点击，打开 Node 面板。#node_button 下的 button，img.src 匹配正则；找不到打「未找到 Harvest 按钮」后 return；点完等 500ms 渲染。触发：每轮拾荒｜参数delay(500)
• 面板未打开直接放弃 — #node 面板不存在或处于隐藏状态时，本轮直接放弃，不报错也不重试。!node || node.style.display==='none' 时 return。触发：点击 Harvest 后
• rolls 解析与失败按 0 处理 — 从 Scavenge 按钮同容器里的文本「N rolls」解析累计次数，解析不出来就按 0 算，自然走未达门槛分支。找文本正好是 Scavenge 的按钮 → 其父容器里第一个 div → 正则 ^(\d+)\s*rolls；按钮不存在时 rolls 也是 0，所以不会对空按钮发 tx。触发：每轮拾荒
• rolls 未满 1000 跳过并关面板 — rolls 小于 1000 时本轮不领取，关掉面板。打「rolls=N < 1000 未到领取门槛，本次跳过（未占锁）」→ 关面板 → 等 500ms → return。触发：rolls<1000｜参数门槛 1000｜来历门槛调小领取更频繁、更费 gas；调大更省 tx，但奖励积压更久
• 拾荒普通锁被占时跳过 — 要发 tx 时普通锁被别的模块占着，本轮不拾荒，关面板等下次。tryAcquireNormalLock('scavenge','core') 失败时打「普通锁被占用，跳过拾荒」→ 关面板 → return。触发：rolls≥1000 时
• 点击 Scavenge 发 tx 并记账（只计次数） — 点击 Scavenge 按钮领取奖励，并在 gas 账本里记一次拾荒动作。scavengeBtn.click()；_gasLedgerRecord('scavenge', [], null) 因为是 UI 点击拿不到 tx/hash，只计次数，gas 无法回填；日志「本次自动拾荒完成，rolls: N」；等 500ms 后在 finally 释放锁。锁只覆盖点击后约 500ms，不覆盖 tx 上链确认。触发：拿到普通锁后｜版本1.2.7
• 关闭 Node 面板还原界面 — 领取完或跳过时，点面板里文字为 X 的按钮关掉 Node 面板。closeNodePanel() 找 textContent==='X' 的按钮点击，并打「关闭弹窗」日志；找不到按钮不报错。触发：跳过或领取结束时｜参数delay(500)

1.9 合成与 XP 药水

XP 药水总控在一次锁里做完三件事：合成 Greater XP Potion → 给高清算线 kami 喂 XP 药水 → 凑批合成松花粉。步长不够就等它随时间恢复，不吃步长道具（步长道具要花钱；测试线 1.2.36~1.2.55 曾临时自动吃道具，1.2.56 已移除）。

XP 药水总控流程

• XP 药水总控流程（合成→喂食→凑批） — 一次普通锁占用内串行完成三件事：合成 Greater XP Potion、喂 XP 药水、凑批合成松花粉，最后关掉 Crafting 窗口。查紧急锁 → 无锁预判 → 拿锁 → 锁内补步长 → Greater 合成 → autoFeedXPPotion → 重读背包凑批 Pine Pollen → 关窗 → finally 释放锁。注释写「主循环约每 30 分钟一轮、可控制台手动执行」，代码实际只在页面加载的启动序列里调用一次，且没有挂到 window。触发：自动：启动序列 autoXPPotionFlow()，每次页面加载跑一轮｜来历三件事共用一次锁，减少锁争抢
• XP 流程健康心跳仅观测 — 模块启动时写存在性时间戳，供辅助脚本健康看板判活，并打启动日志。window.__kamiHealthBeats['XP流程'] = Date.now()；打「启动 XP 药水总控流程」。触发：autoXPPotionFlow 入口
• XP 流程遇紧急锁整轮让路 — 紧急停采等高优先级流程占着 TX 通道时，整轮 XP 流程直接跳过。hasEmergencyLock() 为真时打「紧急锁存在，跳过XP Potion流程」后 return。触发：入口
• 先查后锁预判与诊断早退 — 先无锁读步长和背包，预判合成、喂食、补步长是否至少有一件可能要做；全都不满足就不占锁，直接打两张诊断卡返回。_greaterOk=步长≥50且松花粉≥2500且罐≥1且炉≥1；_pollenOk=步长≥100且松果≥10且研磨器≥1；_feedMaybe 见单独条目；再加补步长两项。五项全假时打「合成/喂食条件均不满足，本轮不占锁」+ Greater 诊断 + 凑批不足提示 + Pine Pollen 诊断。触发：每轮总控｜来历条件全不满足是最常见的轮次，先拿锁再检查会白占普通锁、挡住其他模块的 TX
• 喂食可能性粗筛（阈值引用常量） — 背包有可喂药水（Fortified>0 或 Greater 超出保留量），且数据库存在 LT>70 的记录，就认为可能要喂、值得拿锁。阈值直接引用 XP_POTION_LT_THRESHOLD 和 GREATER_RESERVE；这里不做持有过滤。触发：无锁预判区｜参数XP_POTION_LT_THRESHOLD=70；GREATER_RESERVE=3｜来历粗筛阈值若比正式喂食更严，落在两个阈值之间的 kami 会被判「无事可做」不拿锁，永远轮不到喂食
• XP 流程普通锁被占时跳过 — 拿不到普通锁说明别的模块正在发 TX，本轮跳过。tryAcquireNormalLock('xp_potion','core') 失败时打「普通锁被占用，跳过XP Potion流程」。触发：预判有活干之后｜来历与其他发 TX 的模块互斥，防 nonce 冲突
• Greater XP Potion 合成门槛与不满足诊断 — 步长≥50、松花粉≥2500、玻璃罐≥1、便携炉≥1 时合成 1 瓶 Greater；否则打红字跳过并打诊断卡。材料判断用的是拿锁前的背包快照 items（锁内复查的库存只用于补步长判断），步长用可能已补过的本地值。触发：锁内｜参数门槛写死：步长50/松花粉2500/罐1/炉1
• 合成确认成功才本地扣 50 步长（A09）测试线独有 — Greater 合成确认成功时，本流程内的步长才减 50，失败不扣。_craftOk 为 true 时 stamina=max(0, stamina-50)。触发：Greater 合成后｜来历官方队列 sendTx 等成功回执才 resolve、失败抛错，没抛即成功｜版本测试版1.2.37
• Greater 合成后等 30 秒 — 执行过 Greater 合成（无论成败）后固定等 30 秒，让链上库存和状态刷新，再进喂食环节。await delay(30000)。触发：执行过 Greater 合成时｜参数delay(30000)
• 凑批前重读背包、步长不重读 DOM（A09）测试线独有 — 合成和喂食后重新读一次背包，但步长不重读 DOM，沿用本流程内已确认的增减（Greater 合成成功 -50）。合成后 DOM 步长滞后在偏高一侧，重读或取较大值会高估步长，让松花粉凑批合成白发一笔必失败的 tx。触发：Greater 合成与喂食之后｜版本测试版1.2.37
• Pine Pollen 固定 10 次一笔凑批合成 — 步长≥100、松果≥10、研磨器≥1 时，单笔 tx 执行 10 次合成（10 松果 + 100 步长 → 5000 松花粉）；不够就等下轮，不拆小批。account.item.craft(6,10)；成功打红色粗体日志并等 3 秒；失败只记日志；不足时打「凑批条件不足，跳过等下轮（步长 x/100，松果 y）」+ Pine Pollen 诊断卡。诊断卡按单次配方判定（松果≥1、步长≥10），可能卡片全 ✅ 但凑批仍被跳过。触发：锁内，喂食之后｜参数POLLEN_BATCH=10；POLLEN_BATCH_STAM=100；成功后 delay(3000)｜来历拆小批 = 同样步长变多笔 tx、多付固定 gas；松花粉是囤积材料，不赶时间，减少 TX 优先
• Pine Pollen 合成 gas 补记账 — 松花粉凑批合成 tx 记进 gas 账本，分类为 craft。_gasLedgerRecord('craft', [6], __ptx)。触发：凑批合成 tx 返回后｜来历原来这笔从不入账本（ChatGPT 审计 A14）｜版本1.2.37（A14）
• 合成后关闭 Crafting 窗口 — 合成走 API 后页面可能残留打开的 Crafting 面板，找到其中的 X 按钮点掉。#crafting 下文本为 X 的按钮用 simulateClick 点击，打「已关闭 Crafting 窗口」；找不到只打「未找到 Crafting 关闭按钮」，不报错。触发：锁内流程末尾
• XP 流程锁在 finally 中必定释放 — 无论正常结束还是中途异常，都释放 xp_potion 普通锁。try/finally 里执行 releaseNormalLock('xp_potion','core')。触发：流程结束｜来历避免锁泄漏卡死其他模块

XP 药水自动喂食

• XP 药水按 LT 降序自动轮喂 — 给 LT>70% 的高价值 kami 喂 XP 药水加速升级，稀缺药水按 LT 从高到低优先投放，Fortified 优先、Greater 兜底。依次打印规则 → 幽灵过滤 → LT 筛选 → 剔除杀手 → 轮喂去重/重置 → 算可用库存 → 逐只查状态和冷却后发 pet.item.use → 收尾统计。循环内不复查紧急锁。注释说可在控制台手动执行 autoFeedXPPotion()，代码实际没有挂到 window，手动请用 feedXPPotionNow()。触发：被 autoXPPotionFlow（合成 Greater 之后）和 feedXPPotionNow 调用｜参数XP_POTION_LT_THRESHOLD=70；GREATER_RESERVE=3｜命令feedXPPotionNow()｜存储kami_xp_potion_fed｜来历LT 越高越扛饿、单周期采集越久、价值越高，所以按 LT 降序投放
• 喂食规则速览打印仅观测 — 每次喂食入口打印 7 条规则，解释背包有药水为什么有时不喂，并附强制重喂方法。_printXPPotionRules()：LT 门槛、持有过滤、仅 RESTING、Fortified>Greater、Greater 保留数、轮喂去重、杀手保护（带当前只数），全部合并为一次 log。触发：autoFeedXPPotion 入口｜命令clearXPPotionFed()
• 幽灵 kami 过滤 — 只喂当前账户链上实际持有的 kami，跳过数据库里已转走或卖掉的记录。getByOperator 取 acc.kamis 的 index 集合，打「当前账户实时持有 N 只 kami，数据库 M 条」；查询失败打「退化为不过滤」并继续（宁可多试一只也不中断整轮）。触发：每次自动喂食｜来历对幽灵 kami 发喂食 tx 必然失败，白烧 gas
• LT 门槛筛选与无目标早退 — 从精简数据库筛出 LT 是数字且大于 70 的 kami，一只都没有就跳过喂食。typeof LT!=='number' 或 LT≤70 的排除；为空时打「没有LT>70%的Kami，跳过XP Potion喂食」。触发：每次自动喂食｜参数XP_POTION_LT_THRESHOLD=70
• 全部喂过自动开新一轮 — 候选按 LT 降序，只取本轮没喂过的；达标 kami 都喂过一轮后，自动清空去重记录开始新一轮，杀手依然排除在外。候选为空时打青色「已全部喂过一轮，自动重置开始新一轮」，removeItem 去重 key，候选改用全部非杀手 kami。触发：候选为 0 时｜存储kami_xp_potion_fed
• 可用药水库存计算与无货早退 — 算出本轮能喂的药水数：Fortified 全部可用，Greater 只算超出保留 3 瓶的部分；两者合计为 0 就跳过。fetchInventoryItems 取库存；为 0 时打「背包中无可用XP Potion（Fortified: x, Greater: y, 保留3个用于合成）」；有货时打开始日志（Fortified×、Greater 可用×、待喂几只）。触发：每次自动喂食｜参数GREATER_RESERVE=3
• 药水优先级 Fortified > Greater，用完即停 — 每喂一只前选药水：先用 Fortified，没了再用 Greater，Greater 降到保留线就停止喂食。balFortified>0 用 11411；否则 balGreater>3 用 11402；都不满足打「Potion已用完…停止喂食」后 break。触发：喂食循环每只之前｜参数ITEM_FORTIFIED_XP=11411；ITEM_GREATER_XP=11402
• 只喂 RESTING 状态的 kami — 喂之前查 kami 实时状态，只有 RESTING 才喂；采集中、死亡、升级中一律跳过并计数。getByIndex(index,{harvest:true}) 的 state 不是 RESTING 就 skippedNotResting++ 并 continue（跳过时不走 3 秒间隔）。触发：喂食循环每只｜来历HARVESTING 中喂食会影响采集参数，DEAD/升级中喂不进去
• 180 秒操作冷却预筛 — 复用同一次状态查询带回的 harvest.time.last，判断 kami 是否还在 180 秒操作冷却内，冷却中不发 tx 直接跳过。_cooldownRemainSec(time.last) > 0 时打「#x 冷却中(剩余Ns)，跳过」，skippedCooldown++ 后 continue；time.last 读不到按无冷却处理。不新增查询。触发：喂食循环每只（状态为 RESTING 后）｜参数KAMI_ACTION_COOLDOWN_SEC=180｜来历冷却中发 tx 必定失败｜版本v1.1.10
• 发喂食 tx、记账、立即写去重并扣本地库存 — 对选中的 kami 发喂食 tx，记进 gas 账本，立刻写入轮喂记录，并在本地扣减药水计数。先打「喂食 X 给 Kami #n (LT)，剩余 F/G」，再发 pet.item.use(kamiId, 物品)；_gasLedgerRecord('xp_potion', [kamiId], tx)；_saveXPPotionFed 在 tx 返回后立刻写；本地对应药水计数减 1，打绿色成功日志。tx 返回即算成功，不等上链回执。触发：喂食循环每只通过状态和冷却检查后｜存储kami_xp_potion_fed｜来历立即写记录：即使后续流程中断，这只也不会被重复喂｜版本1.2.7
• 单只失败不连坐 — 某只 kami 状态查询或喂食 tx 出错时，只记日志，继续喂下一只。每只包在 try/catch，打「喂食失败：Kami #n」。若写去重记录的 setItem 抛错，也会走这里：此时 tx 已发出，但本地库存没扣、fedCount 没加。触发：喂食循环每只异常时
• 喂食间隔 3 秒节流 — 每喂一只（含失败）后固定等 3 秒。await delay(3000)；被 continue 跳过的非 RESTING 和冷却中的 kami 不等。触发：喂食循环每只之后｜参数delay(3000)｜来历降低 TX 过密引发 nonce 冲突的风险
• 喂食收尾统计与 0 喂食原因提示仅观测 — 喂完打印统计：因非 RESTING 跳过几只、因冷却跳过几只、共喂几只；有候选却一只没喂时给出原因提示。分别打「非RESTING=N」「冷却中=N（下轮自动重试）」「共喂 N 个kami」；fedCount=0 且有候选时打黄字「候选全部不在 RESTING 状态…等下一轮（30 分钟后）」。代码实际只要 0 喂食就打这句（冷却跳过或发送失败也会触发）；实际下一轮是下次页面加载，不是 30 分钟后。触发：喂食循环结束｜版本v1.1.10（冷却计数）
• 立即手动喂 XP 药水命令 — 控制台立即触发一次 XP 药水喂食，只喂不合成（不合成 Greater 也不合成松花粉），沿用自动喂食的全部规则。feedXPPotionNow()：打青色启动日志 → 紧急锁存在就让路返回 → tryAcquireNormalLock('xp_potion','manual') 拿不到就让路返回（不排队不重试）→ await autoFeedXPPotion() → finally 释放锁。已挂到 window；没有列入 wrapManual 手动命令标记列表。想重喂已喂过的 kami，先 clearXPPotionFed() 再调它。触发：命令｜命令feedXPPotionNow()；配合 clearXPPotionFed()｜存储kami_xp_potion_fed

喂食记录与参数

• XP 药水喂食去重记录（持久化） — 在 localStorage 记下本轮已经喂过 XP 药水的 kamiId（Fortified 和 Greater 共用一份），跨刷新保留。_getXPPotionFedSet() 读取 JSON 解析成 Set，异常返回空 Set；_saveXPPotionFed 把 kamiId 转字符串加入后整体写回。注释写「每只 kami 终生只喂一次」，代码实际全部喂完一轮会自动清空重来（按轮去重）；注释写「读写全部包 try/catch」，代码实际写入的 setItem 没有包 try。触发：自动喂食挑候选时读，每喂一只写｜命令clearXPPotionFed()｜存储kami_xp_potion_fed｜来历kamiId 统一转字符串存，防数字/字符串混型导致查重失效
• 旧记录 key 自动迁移 — 脚本载入时，把旧 key kami_fortified_fed 的数据迁到新 key kami_xp_potion_fed，并删除旧 key。只有旧 key 有数据、新 key 为空时才迁移，避免覆盖已有新记录；异常静默。触发：脚本载入时执行一次｜存储kami_fortified_fed → kami_xp_potion_fed
• 清空 XP 药水喂食记录命令 — 清空全部 XP 药水喂食记录，所有 kami 重新变成可喂。控制台 clearXPPotionFed()，旧名 clearFortifiedFed() 指向同一个函数；删除 localStorage key 并打印清除了多少条。两个名字都在手动命令标记列表里。触发：命令｜命令clearXPPotionFed()；clearFortifiedFed()（旧名兼容）｜存储kami_xp_potion_fed
• XP 药水物品 ID 常量 — 定义 Fortified XP Potion 和 Greater XP Potion 的链上物品 ID。链上固定值，勿改。触发：喂食时选物品｜参数ITEM_FORTIFIED_XP=11411；ITEM_GREATER_XP=11402
• XP 药水喂食 LT 门槛 70 — 只有清算线 LT 高于 70% 的 kami 才参与 XP 药水轮喂。精确清算线刻度（由旧公式刻度的 70% 换算）；调高喂得更少更保守，调低时药水摊给本就安全的低 LT kami，性价比更低。触发：自动喂食筛选和总控预判｜参数XP_POTION_LT_THRESHOLD=70｜来历升级能降 LT，所以优先喂高清算线 kami
• Greater XP Potion 保留 3 瓶 — Greater XP Potion 始终保留 3 瓶作为合成 Fortified 的原料，超出部分才拿去喂。可喂数 = max(0, 库存-3)；循环中库存降到 ≤3 就停喂 Greater。触发：喂食和总控预判｜参数GREATER_RESERVE=3

杀手保护清单

• 杀手 kami 免喂 XP 药水保护清单 — 维护一份杀手 kami 编号集合，XP 药水喂食自动跳过其中的 kami，保住手调的技能 build。window.MY_KILLER_KAMIS 是全局 Set，默认为空；已被其他脚本或控制台定义时沿用、不覆盖。喂食时按 Number(index) 命中就跳过，并打「跳过我的杀手 N 只: #编号(LT=x%)」。代码只认 Set 类型，赋成数组等其他类型会被当作空集。需要和辅助脚本的 RESET_WHITELIST 手动保持一致，长期生效要改两个脚本的源码。触发：脚本载入初始化；每轮喂食前读取｜参数window.MY_KILLER_KAMIS=new Set([])｜命令window.MY_KILLER_KAMIS = new Set([编号...])｜来历喂 XP 药水会升级，升级重新分配技能点，会冲掉专为清算/攻击精调的 build
• 查看杀手清单命令 — 打印当前杀手保护清单和修改方法提示。控制台 showMyKillers()；清单为空时提示「XP Potion 喂食对所有 kami 生效」；否则列出编号，并提示可 .add/.delete、长期生效需同时改核心和辅助两处。已列入手动命令标记列表。触发：命令｜命令showMyKillers()
• 临时增删杀手清单 — 在控制台临时增删保护清单成员，只在当前会话有效，刷新后恢复脚本里写的清单。window.MY_KILLER_KAMIS.add(编号) / .delete(编号)。触发：命令｜命令window.MY_KILLER_KAMIS.add(编号)；window.MY_KILLER_KAMIS.delete(编号)

合成配方与材料诊断

• 步长只认 DOM 实时值（getStamina） — 读取账户当前步长，只信页面 #MyPath 步长条的实时值，读不到就返回 0，本轮跳过合成。调辅助脚本暴露的 window.getStaminaFromDOM()，返回有限数值就用；否则打「DOM 步长读取失败，本轮按 0 处理（跳过合成，不用陈旧 API sync 值）」并返回 0。触发：被 autoXPPotionFlow 调用｜来历API 的 acc.stamina.sync 是上次链上动作的检查点旧值，不随时间自然回复，直接用会严重偏离真实体力、导致合成超扣
• 背包合成链物品查询（fetchInventoryItems） — 查询背包里合成链相关 7 种物品的数量：松果、松花粉、玻璃罐、香料磨、便携炉、Greater XP Potion、Fortified XP Potion。getByOperator 取 inventories，物品名转小写后经 nameMap 映射成内部 key，返回 {key:数量}；不在映射表里的物品忽略；查询失败打「获取背包物品失败」并返回 {}（上层当库存全 0，不会触发合成）。触发：被 XP 总控流程、自动喂食、诊断调用｜参数nameMap（显示名→内部 key，新增物品在此登记）
• 合成 Greater XP Potion 并返回成败测试线独有 — 调链上合成接口合成 1 瓶 Greater XP Potion，返回是否成功，供调用方决定本地扣不扣 50 步长。account.item.craft(2,1)（配方 2=Greater，执行 1 次）；没抛异常就算成功（官方队列等到成功回执才 resolve），打红色粗体成功日志，等 3 秒返回 true；失败打日志返回 false，不重试。触发：被 autoXPPotionFlow 调用｜参数craft(2,1)；成功后 delay(3000)｜来历原来没有返回值，调用方拿到 undefined 永远当失败，步长本地不扣、被低估，白白跳过后续合成（A09）｜版本测试版1.2.37
• Greater 合成 gas 补记账 — Greater XP Potion 合成 tx 记进 gas 账本，分类为 craft。_gasLedgerRecord('craft', [2], __tx)。触发：每次 Greater 合成 tx 返回后｜来历ChatGPT 审计 A14 指出核心两处合成从没记账，导致「账本攒够一天就当完整」的判据建立在残缺样本上｜版本1.2.37（A14）
• 合成配方真值表 — 定义 XP 药水合成链的链上实测配方：Greater XP Potion 每次产 1 瓶、耗 50 步长、消耗松花粉 2500 和玻璃罐 1、工具便携炉 1；Pine Pollen 每次产 500、耗 10 步长、消耗松果 1、工具香料磨 1；测试版 1.2.58 给 Pine Pollen 加 batch=10（主流程凑满 10 次才合成，诊断按一批核对）。RECIPE_DEFS：consumes 按合成次数倍数消耗，tools 只要持有量达到阈值、不随次数累加。链上 craft(6,10) = 执行 10 次 = 10 松果 + 100 步长 → 5000 松花粉。触发：诊断函数读取｜参数greater_xp_potion:{out=1,stam=50,pollen 2500,jar 1,burner 1}；pine_pollen:{out=500,stam=10,cone 1,grinder 1}
• 玻璃罐循环容器语义仅观测 — 玻璃罐合成时每瓶占 1 个（库存确实会减，所以算消耗品），但喂掉 Greater/Fortified 药水后会返还，不是净消耗。标签写「玻璃罐·喂食XP药水后返还」。注释说缺罐应先喂药水回收，但代码里罐没有配方，实际仍会被列进 🛒 采购清单。触发：诊断输出测试版 1.2.58 起诊断里缺玻璃罐提示「喂 Greater/Fortified XP 药水会返还空瓶；背包没药水就去市场买或拾荒」，不再写需采购。｜来历缺罐时应优先喂掉库存药水回收空瓶，而不是买新瓶
• 合成诊断卡片仅观测 — 合成条件不足时打印一张完整诊断卡：体力缺口、每项消耗品/工具 ✅❌、短缺的递归追溯、最底层补货清单。_diagnoseCraft(配方key, items, stamina, crafts=1)；所有行合并成一次 log，避免每行重复时间戳和来源链接；未知配方直接 return。顶层短缺中，消耗品会调 _traceDeficit 下钻，工具只进采购清单不下钻；体力不足提示仍写「等恢复或喝体力药」。触发：XP 总控流程判定不合成时测试版 1.2.58：第 4 个参数按一批核对（Pine Pollen 两处调用传 10，体力与消耗品需求乘批数）；步长不够提示「等它随时间恢复（不吃步长道具）」（此前写「等恢复或喝体力药」）；清单每项附去哪补，末行提示辅助脚本会大字提醒补货（辅助 1.2.16 起大字提醒只管 Fortified XP Potion 材料链，Greater 有库存时不往下查松花粉/松果，这句待下次核心升级改）。
• 短缺递归追溯仅观测 — 对某个短缺物往下追：可合成的算出还要合成几次、每次产量和耗体力，并继续核对下层材料；不可合成的基础料标 🛒 缺 N 个并附去哪补（1.2.58 前写需采购）。_traceDeficit：合成次数 max(Math.ceil(缺口/产量), 该配方一批次数 batch)，不低估；消耗品按次数倍数算需求，工具看是否 ≥ 阈值；按层级缩进输出树状行。触发：_diagnoseCraft 内
• 补货清单折算最底层基础料仅观测 — 把所有短缺递归折算到最底层基础原料的数量，汇总成补货清单（每项附去哪补），并提示「补齐后才能合成」。_accumulatePurchase：没有配方的物品累加进 summary；可合成物按 max(ceil, batch) 次数继续向下折算（消耗品按倍数，工具补到阈值）。触发：_diagnoseCraft 内
• 去哪补提示 _supplyHintOf测试线独有 — 诊断卡片里每个缺货的基础料附一句去哪补：研磨器、便携炉「Mina 商店有售（工具，买一次一直用）」；玻璃罐「喂 Greater/Fortified XP 药水会返还空瓶；背包没药水就去市场买或拾荒」；其余「商店不卖：市场购买或拾荒获得」。依据游戏 listings 表（合成相关只有两样工具在商店卖）。触发：诊断卡片输出时｜版本测试版1.2.58
• 物品中文显示标签仅观测 — 诊断输出里给物品显示中英文名，只影响日志可读性。ITEM_LABEL 映射，_labelOf 查不到时显示原 key。触发：诊断输出｜参数ITEM_LABEL

1.10 模式与停采线

两种停采模式：normal 用"精确清算线 +3%，封顶 80%"，greedy（默认）用极限线（测试版 30%，公开版 5%）。

• normal / greedy 两种停采模式 — normal=安全模式，停采线=精确清算线 LT+3%（封顶80%），取不到 LT 用 65%/76%；greedy=贪婪模式，无杀手时用极限停采线（测试版 30%，公开版 5%），尽量采到接近极限才停。模式从 localStorage「kami_mode」读，未设置默认 'greedy'；加载时固化，写入 window.__kamiMode 供停采线计算模块读。触发：脚本加载时｜参数GREEDY_THRESHOLD=30（测试版 1.2.57 起；公开版 5）｜命令setKamiMode('greedy'|'normal')｜存储kami_mode｜来历最大化单周期采集时长；旧名「饥饿模式 starving」改名为贪婪模式｜版本1.1.13
• 默认停采线兜底值 — 取不到精确清算线 LT 时：normal body 默认 65%，非 normal body 默认 76%。挂到 window.DEFAULT_THRESHOLD_NORMAL / DEFAULT_THRESHOLD_OTHER。触发：停采线计算取不到 LT 时由其他模块读取｜参数DEFAULT_THRESHOLD_NORMAL=65；DEFAULT_THRESHOLD_OTHER=76｜来历非 normal body 受亲和度克制、更易被清算，所以默认线更高
• 停采线封顶 80% — LT 再高的 kami 也最多在 80% 停采，保证每周期至少采 20 个百分点血量区间。挂 window.MAX_THRESHOLD 供计算模块读。触发：停采线计算时｜参数MAX_THRESHOLD=80｜来历有意设计，目标是单周期采集时长最大化；LT 过高的 kami 应先升级属性而不是抬高停采线
• 停采线安全垫 LT+3% — 停采线 = 精确清算线 LT + 3 个百分点。只在本脚本闭包内使用，未挂 window；配套凑批等待与单停危险线收紧至 -1。调大更保命但采集更短。触发：停采线计算时｜参数LT_STOP_MARGIN=3｜来历精确清算线经官网/单测/实盘三重验证后收窄；此前 v1.1.1~1.1.7 过渡期为 15｜版本v1.1.8 起
• 贪婪极限线常量与兼容别名 — GREEDY_THRESHOLD 挂到 window.GREEDY_THRESHOLD，同时保留 window.STARVING_THRESHOLD 指向同一个值。供停采线计算模块与辅助脚本读取；调小采集更久但风险升高。触发：脚本加载时｜参数GREEDY_THRESHOLD=30（测试版）/5（公开版）｜来历兼容 v1.1.13 改名前的旧引用方式｜版本1.1.13
• 贪婪线 5% → 30%测试线独有 — 测试版把极限停采线从 5% 抬到 30%。依据是 0914 全网探针：全网 22222 只里 97% 是白板（无攻击技能），我方 313 只全带防御加成，血量 ≥20% 时没有任何一只白板能杀我方任何一只；带技能的 3% 在 30% 时只有 0.5~1.6% 能杀。5% 线只剩 5 点垫子，夜里卡片血量停更会直接采成 STARVING（0 产出+必须喂+intensity 清零）；30% 多留 10 点给读数滞后和深处掉血加速。每点血换的 MUSU 恒定 =(harmony+20)/6.5，深采收益在少停部 tx 与 intensity，5→30 损失很小。触发：脚本加载时｜参数GREEDY_THRESHOLD=30｜来历用户 0914 定案｜版本测试版1.2.57
• 旧值 starving 一次性存储迁移测试线独有 — 读到老机器 localStorage 里残留的 'starving' 时自动改写为 'greedy' 并打一条迁移提示。只迁移一次，之后永不触发；注释特别警告这不是残留别名，别删。触发：脚本加载读取模式时｜存储kami_mode｜来历若不迁移，__kamiMode 既非 normal 也非 greedy，下游 === 'greedy' 判假，停采线从 5% 静默跳回约 72%｜版本测试版1.2.50
• setKamiMode 切换模式命令测试线独有 — 只接受 'normal' / 'greedy'，写入 localStorage 后打印绿色提示，1.5 秒后自动刷新页面生效。非法值打印用法（normal: 清算线+3%上限80%；greedy: 无杀手5%有杀手切安全线）并返回。触发：命令｜参数刷新延迟 1500ms｜命令setKamiMode('greedy') / setKamiMode('normal')｜存储kami_mode｜来历模式常量在加载时固化，运行中改 localStorage 不生效，必须刷新让所有模块按新模式重建｜版本测试版1.2.50
• 拒收旧名 starving 并解释原因测试线独有 — setKamiMode('starving') 不再作为别名接受，打印「旧名已移除，请用 greedy」及改名原因。输入侧别名移除，读取侧 localStorage 迁移保留。触发：命令输入 'starving' 时｜命令setKamiMode('starving')（会被拒）｜来历用户 0913 定案：该旧名指「停采线压到 5% 榨干周期」，与「0 血还在采」的 STARVING 状态无关，两个概念共用一个词，读代码的人和 AI 都会混｜版本测试版1.2.50
• getKamiMode 查看模式命令 — 打印当前模式、杀手状态、恢复倒计时、当前停采线、默认值和切换提示，并返回 {mode, killerDetected, cooldownRemain}。恢复倒计时 = max(0, SAFE_COOLDOWN_MS - 距上次发现杀手时长)；greedy 下显示极限线(5%)或安全线(LT+3%，上限80%)。触发：命令｜命令getKamiMode()
• 模式启动 banner仅观测 — greedy 打印橙色「[贪婪模式] 已启用，无杀手时使用 GREEDY_THRESHOLD% 极限停采线，杀手监控由独立脚本负责」；normal 打印绿色「[安全模式] 停采线=LT+3%（上限80%）或默认65%/76%」。纯日志。触发：脚本加载时
• 杀手检测自动切安全线（滑动窗口）已停用 — 设计为：5 分钟窗口内收到 2 条 liquidated 消息判定有活跃杀手，贪婪模式自动改用安全线；15 分钟无新击杀才恢复极限线。数据源是杀手监控脚本的 Feed 监控，现已停用，__killerDetected 默认无人写入恒为 false；本段只定义常量与初始化变量，规则默认不触发。实际杀手保护是杀手监控脚本的位置轮询直接触发紧急停采。触发：（原）杀手监控脚本写入全局变量｜参数LIQUIDATE_WINDOW_MS=5分钟；LIQUIDATE_COUNT_TRIGGER=2；SAFE_COOLDOWN_MS=15分钟｜来历冷却 15 分钟是为避免杀手只是短暂停手就贸然切回激进线
• 跨脚本模式/杀手全局变量约定 — 初始化 window.__kamiMode、__killerDetected=false、__lastKillerTime=0、__liquidatedTimestamps=[]。__kamiMode 被下游读取生效；三个杀手变量为兼容保留，默认无人写入。触发：脚本加载时
• 贪婪模式说明（文档）仅观测 — 对比 normal（LT+3%，封顶80%）和 greedy（极限线，测试版 30% / 公开版 5%）两种模式，说明本地无记录时默认是 greedy，杀手检测主路径是轻量杀手监控按名单轮询位置、直接触发紧急停采。紧急停采触发条件（文档）：杀手监控报告名单内杀手逼近，或任意 kami 的 HP 低于清算线+2%。1.2.50 起 setKamiMode 只接受 normal/greedy。公开版杀手名单默认为空，没配置好就建议先切 normal。触发：文档（不执行）｜参数normal=LT+3%封顶80%；greedy=GREEDY_THRESHOLD｜命令setKamiMode('greedy') / setKamiMode('normal') / getKamiMode()｜存储kami_mode｜来历v1.1.13 饥饿模式改名贪婪模式，避免与0血仍在采的STARVING状态混淆｜版本1.1.13
• 清算消息计数杀手检测（辅路径）已停用 — 旧的辅助检测路径：按 liquidated 清算消息计数，5分钟内2条就切安全线，15分钟无新击杀再恢复。依赖杀手监控脚本的 Feed 监控写 __killerDetected 标记。Feed 监控已停用，标记恒为 false，安全线自动切换这条路不再生效，greedy 的安全性因此更依赖杀手名单是否填全。触发：原依赖 Feed 监控写标记｜参数5分钟2条切安全线；15分钟无击杀恢复｜来历Feed监控停用
• Feed（被喂食）监控外置说明已停用 — 本脚本没有 Feed 监控（openChatAndSwitchToFeed / startFeedMonitor），注释说明由配套的轻量杀手监控脚本负责，启动流程里也不启动。1.2.51 的注释把它称作「已停用的 Feed 监控」。

1.11 TX 双锁与 nonce

同一钱包的 tx 必须串行，否则 nonce 冲突。紧急锁给紧急停采，普通锁给其他所有操作；另有停采发送通道（mud / raw）的选择。

双锁机制

• TX双锁机制说明（文档）仅观测 — 说明为什么需要紧急锁和普通锁：所有操作共用一个 Operator nonce 序列，紧急停采被抢号就可能漏停。文档写：紧急锁10分钟超时，普通锁5分钟超时，紧急停采最多等普通锁释放30秒；锁纪律是「先确认有活干再拿锁、锁内只留发tx段」；并列出各模块的锁检查点。具体实现在后文，数值以实现为准。触发：文档（不执行）｜参数文档值：紧急锁10min/普通锁5min/等待普通锁30s｜命令getTxLockStatus()｜来历最危险场景：紧急停采被其他操作抢走nonce→停采失败→kami被清算
• 双锁串行化全部链上 TX — 用挂在 window 上的两把内存锁（紧急锁/普通锁）把核心脚本与辅助脚本所有发 TX 的动作排成一条队，避免同钱包并发发 TX。锁对象记录 operation（操作名）、script（哪个脚本）、since（上锁时间戳）便于诊断；紧急锁专供紧急停采，持有期间任何普通 TX 不允许启动。触发：所有发 TX 的入口在发送前调用｜参数TX_LOCK_TIMEOUT=300000(5分钟)；TX_EMERGENCY_TIMEOUT=600000(10分钟)｜来历同一钱包并发发 TX 会造成 nonce 冲突，交易被替换或丢弃
• 锁防重复初始化 — 只有当 window.__txEmergencyLock / __txNormalLock 为 undefined 时才置 null。typeof === 'undefined' 判断后再初始化，不覆盖已有值。触发：脚本加载时｜来历脚本热重载时不能清掉另一个脚本正持有的锁
• hasEmergencyLock 紧急锁前置检查 — 所有发 TX 的操作都先过这一关：有紧急锁就返回 true。无锁返回 false；有锁先做超时检查再返回 true。触发：被所有 TX 入口、抢普通锁、排队让路等调用；挂 window 供辅助脚本用
• 紧急锁超时自愈 — 紧急锁持有超过 10 分钟视为持有方异常（页面卡死/流程中断），检查时强制释放并打警告日志。Date.now()-since > TX_EMERGENCY_TIMEOUT → 置 null，打印已持有秒数；紧急锁超时取普通锁 2 倍，因为批量停采耗时更长。触发：每次调用 hasEmergencyLock 时顺带检查｜参数TX_EMERGENCY_TIMEOUT=600000｜来历防止一把僵尸锁永久卡死整个自动化
• setEmergencyLock 上紧急锁 — 设置 operation='emergency_stop' 的紧急锁并打日志。直接覆盖写入 {operation, since}，打印「🚨 设置紧急锁」。触发：紧急停采、raw 模式饿死救援调用；挂 window
• releaseEmergencyLock 释放紧急锁 — 存在紧急锁时清空并打日志。无锁时什么都不做。触发：紧急停采/救援收尾；挂 window
• 紧急锁长持锁诊断仅观测 — 释放紧急锁时若持有超过 120 秒，打一条「⏱️ [锁诊断] 紧急锁持有 Ns（长持锁）」日志。since 为取锁时刻；只在 >120s 才打，防刷屏；纯日志不改行为。触发：releaseEmergencyLock 时｜参数阈值 120000ms｜来历可观测性批次：定位长时间占锁的流程｜版本1.1.17
• 抢普通锁时紧急锁优先 — 紧急锁存在时任何常规操作都拿不到普通锁，直接返回 false 并打「已停用 紧急锁存在，无法获取普通锁」。tryAcquireNormalLock 第一步调用 hasEmergencyLock。触发：部署/喂食/合成/升级等常规 TX 抢锁时｜来历保命操作（紧急停采）先行，常规 TX 一律让路
• 普通锁非阻塞抢占 — 普通锁已被占用且未超时时立即返回 false（打印占用者脚本/操作），不硬等，由调用方延后重试；抢到则写入 {operation, script, since} 并打「🔒 获取普通锁」。同一时刻只允许一个操作持有普通锁。触发：常规 TX 入口调用 tryAcquireNormalLock(operation, script)
• 普通锁超时强制接管 — 普通锁持有超过 5 分钟视为异常，抢锁方强制释放并由本次直接接管。Date.now()-since > TX_LOCK_TIMEOUT → 打警告「普通锁[脚本/操作]超时，强制释放」后继续获取。触发：tryAcquireNormalLock 发现锁被占时｜参数TX_LOCK_TIMEOUT=300000｜来历避免僵尸锁卡死自动化；调小恢复快但可能误杀执行中的慢 TX
• 普通锁释放双匹配校验 — 只有 operation 和 script 都与当前持有者一致才释放普通锁。不匹配静默不动。触发：常规 TX 收尾调用 releaseNormalLock(operation, script)｜来历防止 A 操作误释放 B 操作持有的锁
• 普通锁长持锁诊断仅观测 — 释放普通锁时持有超过 120 秒打「⏱️ [锁诊断] 普通锁[脚本/操作] 持有 Ns」。纯日志，>120s 才打。触发：releaseNormalLock 时｜参数阈值 120000ms｜版本1.1.17
• waitForNormalLockRelease 紧急停采礼让等待 — 上紧急锁前先等在途普通 TX 收尾，最多 30 秒，每 1 秒轮询；返回普通锁是否已清空。等待期间若普通锁超过 5 分钟也强制释放并立刻结束等待；超 30 秒仍被占则返回 false（由调用方决定怎么办）。触发：紧急停采、raw 模式饿死救援读 nonce 前调用｜参数maxWaitMs 默认 30000；轮询 1000ms｜来历紧急场景不能久等，但先让在飞 TX 收尾可减少 nonce 冲突
• waitForEmergencyRelease 常规 TX 排队让路 — 部署/升级/合成/喂食等常规 TX 遇到紧急锁时不直接失败，每 500ms 轮询等待，紧急停采完成后自动继续发送。无锁直接返回 true；开始等待打「排队等待（最多N秒）」；超时打「放弃本次」返回 false；等到后打「紧急锁已释放（等待N秒），继续tx」。触发：常规 TX 入口（核心与辅助脚本）调用｜参数maxWaitMs 默认 300000（与 runAutomation 主流程等待对齐）；轮询 500ms｜来历尽量不丢弃本次操作
• getTxLockStatus 查看锁状态 — 返回两把锁当前持有者与已持有秒数的描述串。如「紧急锁(12秒) + 普通锁脚本/操作」，无锁返回「无锁」；只返回字符串不主动打印。触发：命令｜命令getTxLockStatus()
• 锁函数挂 window 跨脚本共享 — 把 hasEmergencyLock / setEmergencyLock / releaseEmergencyLock / tryAcquireNormalLock / releaseNormalLock / waitForNormalLockRelease / waitForEmergencyRelease / getTxLockStatus 挂到 window。辅助脚本直接调用这些全局函数，两个脚本共享同一份锁状态。触发：脚本加载时｜来历辅助脚本的 tx 入口同样要排队让路
• 抢锁失败建议重试间隔常量已停用 — 定义抢锁失败后延后重试的建议间隔 3 分钟。注释写「供各调用方引用」，代码实际在全文件中只有定义、没有任何引用处。参数：TX_RETRY_DELAY=180000

主循环里的锁协调

• 本轮有活才等紧急锁（最多 300 秒） — 有停采或部署候选、但紧急停采正持锁时，原地等它结束，不直接丢掉整轮扫描结果。__hasWorkThisRound 为真且有紧急锁→打「紧急锁存在，等待紧急停采完成…（最多300秒）」，每 3 秒轮询；结束后打实际等待秒数和是否已释放。触发：锁协调开始｜参数等待上限 300000ms；轮询 3000ms｜来历立即跳过会把扫描好的候选池整个丢掉，只能等下个周期重扫，白白错过可部署的 kami
• 紧急锁仍在则跳过本轮停采/部署 — 等过之后紧急锁还在，放弃本轮普通停采和部署，直接去喂食检查。hasEmergencyLock() 为真打「紧急锁存在，跳过本轮普通停采/部署」。触发：紧急锁等待之后
• 抢普通锁 + 被占时等最多 60 秒 — 有活时申请普通锁；被别的模块占着就等它释放，等待中出现紧急锁立即放弃。tryAcquireNormalLock('batch_stop_deploy','core') 失败→打占用者 script/operation，每 3 秒轮询 window.__txNormalLock 最多 60 秒，遇紧急锁 break；之后再尝试一次，仍失败打「等待60秒后仍无法获取普通锁，跳过本轮停采/部署」。空轮不碰锁。触发：无紧急锁且本轮有停采/部署候选｜参数普通锁等待上限 60000ms；轮询 3000ms｜来历先查后锁，空轮不白占锁挡住辅助脚本的合成等模块
• 锁归属校验 — 进执行段前确认手上的普通锁确实是自己的，不把别的模块刚抢到的锁当成自己的。window.__txNormalLock.operation==='batch_stop_deploy' 且 script==='core' 才进 try 执行段。触发：抢锁流程后
• 停采/部署普通锁 finally 释放 — 停采和部署执行段结束后一定释放普通锁。try…finally 中 releaseNormalLock('batch_stop_deploy','core')。触发：执行段结束
• 停采进行中标记（防刷新打断） — 停采执行期间挂一个「操作进行中」标记，强制刷新等自保逻辑看到会避让。apiList 或 domList 非空时 window.__kamiOperationInProgress=true，DOM 兜底停采结束后置 false。代码实际：复位语句不在 finally 里，停采段中途抛异常时标记可能残留。触发：拿到普通锁、有停采候选时｜来历防止停采中途被刷新打断

停采发送通道（mud / raw）

• 停采发送通道启动播报仅观测 — 启动时播报当前停采发送通道和切换命令。读 localStorage kami_stop_tx_channel，只有值为 'mud' 才是 mud，否则一律 raw（缺省 raw）。banner 里 setStopTxChannel 的说明写「mud=MUD队列(默认)」，与代码实际缺省 raw 不一致。触发：脚本注入后立即｜命令setStopTxChannel('mud'|'raw')｜存储kami_stop_tx_channel｜来历v1.1.21会诊：MUD队列回执形状未经实盘验证，默认保守回退到验证过的raw原始签名器｜版本1.1.21
• 停采发送通道选择（默认 raw 原始签名器） — 紧急停采交易有两条路：MUD 队列（和游戏 api 共用一本 nonce 账）和原始签名器。默认走 raw，只有明确设成 mud 才走队列。localStorage 里的值严格等于 'mud' 才走 MUD，其余情况（包括读取抛错）一律 raw。触发：每批停采发送时读取｜存储kami_stop_tx_channel｜来历0710 取证发现，原始签名器和 MUD TXQueue 各记一本 nonce 账，两边分叉，每夜约 46 次 sequence mismatch，所以 1.1.19 切到 MUD。但 MUD 队列 resolve 出来的对象长什么样没在实盘验证过，1.1.21 默认又保守切回了验证过的 raw｜版本1.1.19 停采通道统一 / 1.1.21 默认通道保守回raw
• 控制台命令 setStopTxChannel — 一条命令切换紧急停采的发送通道，立即生效。参数不是 mud 或 raw 时打印用法和当前通道，不做修改；合法时写入 localStorage 并打印确认。触发：命令｜命令setStopTxChannel('mud') 切 MUD 队列（nonce 统一）；setStopTxChannel('raw') 切回原始签名器（旧路）｜存储kami_stop_tx_channel｜来历留一个开关，出事时秒回退，也方便实盘验证 mud 通道｜版本1.1.19 停采通道统一
• MUD 队列入口缺失时自动跌落 raw 并计数 — 通道设为 mud 但队列上的 executeBatchedAllowFailure 不是函数时，打一行 ⚠️，本批自动改走原始签名器。跌落次数计入 __stopChanFallbackCount，供完成小结显示。触发：mud 通道每批发送时｜版本1.1.19 停采通道统一 D3
• 停采发送通道选择（mud / raw） — 通道设为 mud 且队列入口可用时，走 MUD txQueue 发送，与游戏 api 共用同一个 nonce 账本；否则走原始签名器，把 harvestId 转成 BigInt 按 uint256[] 做 ABI 编码后 signer.sendTransaction。通道由 localStorage kami_stop_tx_channel 决定，只有值为 'mud' 才走 mud，其余（含默认、读异常）都是 raw。两路用同一个入口、同一组 harvestIds，容错语义一致。触发：_allowFailureStop 每次发送｜命令setStopTxChannel('mud') / setStopTxChannel('raw')（即刻生效，定义在本段之外）｜存储kami_stop_tx_channel（读）｜来历signer.sendTransaction 与 MUD api 各走各的 nonce 账本，会造成 sequence mismatch｜版本1.1.19
• MUD 入口缺失自动跌落 raw 并计数 — 选了 mud 通道但队列停采入口不是函数时，打「MUD 队列停采入口不可用，本批自动回退原始签名器」，跌落计数 +1，本批改走 raw。累加 __stopChanFallbackCount，供停采小结统计。触发：mud 通道发送时入口不可用｜版本1.1.19

1.12 gas 账本与余额

每笔脚本 tx 按动作分类记账，后台按 hash 补真实 gas，showGasReport 汇总；余额偏低时大字告警。

低余额告警

• 账户余额DOM抓取 — 从页面读出账户余额文本，比如「12.34 mETH」。锚点是 #tx-logs（id 稳定，不依赖 sc-* 哈希 class）。在它父容器的 div/span 叶子节点里找匹配「数字+可选单位前缀+ETH」的文本；找不到返回 null。触发：checkLowBalanceOnce 调用｜版本1.2.7
• 余额单位换算为mETH — 把余额文本换算成 mETH 数值。ETH×1000，m×1，µ/μ/u×1e-3，n×1e-6，p×1e-9，未识别的单位前缀按×1。格式不匹配返回 null。触发：checkLowBalanceOnce 调用｜版本1.2.7
• 低余额高亮充值提醒 — 余额低于10 mETH 时，用红底白字16px 大字警告，并追加一行充值提醒（注明是启动时还是刷新前检测到的）。两行 clog 高亮，再 log 一条「🚨 [余额警告]」。clog 本身已写日志，再加 log 会让缓冲区出现两份同内容（「同步进 buffer」那条注释写于 clog 改造之前）。触发：余额<阈值时｜参数__LOW_BALANCE_THRESHOLD_METH=10｜版本1.2.7
• 低余额检查触发与去重 — 会话启动时检查一次余额，页面刷新前再检查一次。stage='start' 用 __lowBalanceChecked 保证每会话只查一次；stage='end' 不去重，每次刷新前都查。抓不到余额或解析失败就静默跳过，整体 try/catch。触发：printAccountAndRooms 会话启动时调 'start'；刷新前调 'end'｜版本1.2.7
• 读数为 0 先复核再告警测试线独有 — 余额读的是游戏界面文字，页面还没渲染出余额时读到的就是 0.00mETH。所以读到低于警戒线时：大于 0 的按真低余额立刻告警；恰好为 0 的不立即报，20 秒后重读，两次都是 0 才报；复核后变正常则只打一行 ℹ️ [余额] 首次读到 0.00mETH（页面多半还没渲染出余额）…不告警，读不到元素也不报。刷新前那次检查的复核可能赶不上页面卸载，那种情况最多少报一次，下次启动照样查。触发：checkLowBalanceOnce｜参数__LOW_BALANCE_RECHECK_MS=20000｜来历0921 夜账户最大的那台每次启动都报「余额仅剩 0.00mETH」共 6 次、并把健康看板刷红，链上实测该号 operator 有 65 mETH，纯误报｜版本测试版1.2.61
• 旧余额差gas统计已停用 — 原来靠刷新前后余额求差来统计 gas，包括 recordGasStart、recordGasEnd、showGasUsage、clearGasUsage、showGasStats、showEpochGasStats。1.2.7 整体删除，改用链上真值 gas 账本 showGasReport。本板块只保留独立的低余额告警。账户信息 banner 处原先启动这套统计的代码也已删除，只剩注释。触发：已删除｜来历余额差混入充值/买道具/充能，统计不准｜版本1.2.7

gas 真值账本

• gas账本存储与有界裁剪 — 本地保存一份 gas 账本，每笔脚本 tx 一条，按时间和条数双重限长。读取损坏或缺失时回退空数组；写入超配额静默。裁剪先删35天前的，再按5000条上限截掉最旧的。gasWei 用 BigInt 转 string 存，不丢精度。触发：每次记账/回填时｜参数GAS_LEDGER_MAX=5000；GAS_LEDGER_RETAIN_DAYS=35｜命令showGasReport()｜存储kami_gas_ledger｜版本1.2.7
• 记账钩子 _gasLedgerRecord — 各发 tx 点只加这一行调用，按动作类型（deploy/stop/feed/revive/scavenge/xp_potion，辅助另有 craft/upgrade 等）记一条待补 gas 的账。条目格式 {ts, action, kamiIds(字符串数组), n, hash, gasWei:null, status:null}。全程 try/catch、异常静默，绝不改 tx 发送逻辑、返回值或时序（非侵入红线 I1）。触发：被核心各发 tx 点同步调用｜存储kami_gas_ledger｜来历单kami/动作gas不是链上字段，只能在发tx时打标签；取代不准的余额差统计｜版本1.2.7
• tx哈希抓取（三种形态） — 从 tx 对象、hash 字符串或 promise 里拿到交易哈希。字符串直接用；有 .hash 取 .hash；promise 不 await，在 .then 里取 hash/transactionHash，按 ts+action 且 hash 为空找回条目再落盘。抓不到保持 null；无 hash 的条目（如拾荒 UI 点击）永远不会被补 gas，只计动作次数。触发：_gasLedgerRecord 内调用｜存储kami_gas_ledger｜来历fire-and-forget发送也要能事后按hash补账｜版本1.2.7
• MUD队列回执当场入账测试线独有 — 发送结果里已经带着解析好的回执时，直接当场算出 gas 和状态，不再让 reconciler 去链上查一遍。txOrHash.receipt 是非 promise 对象时，gasWei=gasUsed×(gasPrice 或 effectiveGasPrice)（算法照搬 reconciler），status 取 receipt.status，缺 hash 时用 receipt.transactionHash 补。算不出就留 null 交给 reconciler。触发：记账时检测到 receipt｜存储kami_gas_ledger｜来历0913实测MUD队列(api通道)返回{hash,receipt}；喂食是发tx最密的动作，省下每笔一次RPC｜版本测试版1.2.46
• 暴露记账钩子给辅助脚本 — 把记账函数挂到 window.__kamiGasRecord，让辅助脚本的合成/升级/加点/重置技能也能记进同一本账。辅助脚本调用前有 typeof 守卫，核心是旧版没有这个接口时静默跳过。报告说明写需辅助≥1.2.4。触发：脚本注入时挂载；辅助发 tx 时调用｜版本1.2.10
• 只读provider获取 — 取一个只用来读回执和余额的 provider，绝不拿它发 tx。优先 network.signer.provider，其次 network.provider，都没有返回 null，异常也返回 null。触发：reconciler/owner查询/余额续航调用｜版本1.2.7
• reconciler 按回执回填真实gas — 后台定时扫描账本，给有 hash 但还没 gas 的条目查链上回执，回填 gasWei 和 status。__gasReconcileRunning 防重入。每轮按账本顺序从最旧取前20条，逐条 getTransactionReceipt：没上链或缺字段就保持 null 下轮再补；gasWei=BigInt(gasUsed)×BigInt(gasPrice||effectiveGasPrice)；status=0 表示 revert，照样计入。回写时重新读当前账本、只填仍为 null 的同 hash 条目，避免覆盖期间新记的账，回写后裁剪。注意：从最旧开始取，一直查不到回执的条目会持续占住前20个名额，直到35天后被裁掉。零新增 tx（I2）。触发：主循环启动时挂 setInterval，每3分钟一次（window.__gasLedgerReconcilerStarted 防重复挂，并打一条启动日志）｜参数GAS_LEDGER_RECONCILE_MS=3分钟；GAS_LEDGER_RECONCILE_BATCH=20｜存储kami_gas_ledger｜来历ethers v6单笔字段是gasPrice（兼容effectiveGasPrice），0713实测｜版本1.2.7

链上 gas 查询与动作分类

• owner手动tx gas查询仅观测 — 查 owner 主身份地址（充值、转 kami 这类脚本发不了的手动 tx）的链上 gas。调 Yominet 官方索引器 Rollytics 的 evm-txs/by_account?is_signer=true，每页100条、最多翻5页。累加 gasUsed×effectiveGasPrice（hex 值用 BigInt 解析）。回复里没有时间戳，就用当前块号减「窗口秒数÷2.29秒/块」切窗；拿不到当前块时全部计入各窗，并标 blockBased=false。结果按同地址缓存1小时。失败返回 {ok:false,error}。纯只读。触发：showGasReport 调用｜参数OWNER_GAS_TTL_MS=1h；OWNER_GAS_MAX_PAGES=5；OWNER_SEC_PER_BLOCK=2.29｜命令showGasReport()｜存储kami_owner_gas_cache｜来历owner tx稀少（实测约0.7笔/天），游戏页CORS放行Rollytics｜版本1.2.8
• operator 24h链上全量总账仅观测 — 从链上索引器的 cosmos 端点拉 operator 最近24小时的全部 tx，算出真实扣费总额，用来和本地账本对照。端点 txs/by_account，每条自带真实时间戳。单笔实扣=fee_amount×gas_used÷gas_limit，先乘后除保精度；fee 或 limit≤0 的跳过。索引严格新→旧，看到24h外的 tx 就停止翻页；最多15页，翻满仍没越过24h边界则标 truncated（报告标「仅下限」）。缓存1小时。触发：showGasReport 调用｜参数ADDR_GAS_24H_TTL_MS=1h；ADDR_GAS_24H_MAX_PAGES=15｜命令showGasReport()｜存储kami_addr_gas_24h_cache_v3｜来历0717深夜三口径对账：Rollytics evm-txs索引不完整（7d仅约75%）会把缺口算成负数；fee_amount是预付额比实扣高约43%不可直接累加；该口径与kamistats偏差+1.2%｜版本1.2.11
• 链上tx动作反推分类仅观测 — 对链上拉到的每笔 tx，从 MsgCall 的函数选择器和合约地址反推动作类型并分桶，连没记过账的 tx（含拾荒 UI 点击、账本启用前的 tx）也能分类。取第一个 MsgCall 的 input 前10字符和 contract_addr，交给 _chainActionLabel 打标签；没有 MsgCall 记「未知(非MsgCall)」。分类异常不影响总额统计。缓存 key 升到 v3，防旧结构串味。触发：_fetchAddrGas24h 内逐笔执行｜命令showGasReport()｜存储kami_addr_gas_24h_cache_v3｜来历0718实测cosmos tx自带完整calldata，选择器+合约地址就是天然动作标签｜版本1.2.13
• 运行时系统合约地址动态分类 — 每次出报告前，从游戏运行时读取各系统合约的当前真实地址并优先匹配；合约换代后分类自动跟上。用64个官方 key 逐个读 window.network.txQueue.systems[key].target（容器是 Proxy，没实现 ownKeys，无法枚举，只能点名）。结果缓存10分钟，只按地址前缀匹配、不比选择器。触发：_chainActionLabel 调用｜参数缓存10分钟｜来历0911实盘gas报告48%开销落进「未知」——停采合约已换代，硬编码表patch后必然腐烂；铁律：严禁硬编码系统合约地址，唯一安全源是运行时target｜版本1.2.32
• 官方64个系统key清单 — 维护官方客户端全部64个 systems key 及中文标签（移动、部署、停采、道具使用、升级、加点、拾荒领取、市场、交易等）。从官方客户端源码 packages/client/src/network/api 里把 systems['...'] 字面量全部抓出来，替代原先手写猜测的11个；容器路径按源码校准为 txQueue.systems。触发：运行时分类读取｜来历Proxy容器不可枚举，只能拿已知key逐个点名｜版本1.2.34
• 硬编码历史地址分类表 — 给系统合约换代前的旧 tx 打标签，保证旧账也看得懂。老条目要同时匹配选择器和地址。0911 从 World 注册表链上解析出的64个系统真值条目 sel 为 null，只比地址。拾荒重掷/领取按地址前缀匹配（0717日志对时认领）。另有0825发现的道具使用新址（1.2.28）。触发：运行时表未命中后使用｜来历1.2.33曾把加点标成道具使用、升级标错；选择器0xe60f3a76=executeTyped(uint256,uint32)被多个系统共用，光看选择器会张冠李戴，必须认地址｜版本1.2.34
• 未知动作指纹兜底 — 两张表都没匹配上的 tx 归进「未知 选择器@合约前12位…」桶，显示指纹方便后续认领。见到一个就改表认领一个。触发：分类未命中时｜版本1.2.13

showGasReport 报告

• showGasReport() 链上真值gas报告命令 — 汇总输出 gas 报告：账本概况、operator 分窗分类统计、链上24h全量对照、owner 手动 tx、合计、余额续航。开头列账本条目数/上限/保留天数、未补 gas 条数（有 hash）、无 hash 无法补的条数。地址用 connectedAddress→getByOperator 解析出 operator（发 tx 地址）、owner（主身份）和账户名。全部行先攒进数组，最后用一次 clog 输出，所以会进日志。生成过程异常时输出「❌ 生成报告异常」。在后文被 wrapManual 包装。触发：控制台手敲；页面加载10分钟后自动一次｜参数窗口24h/3d/7d/30d｜命令showGasReport()｜存储kami_gas_ledger / kami_owner_gas_cache / kami_addr_gas_24h_cache_v3｜版本1.2.10
• operator分窗按动作分类统计仅观测 — 对24h/3d/7d/30d四个窗口分别统计总 gas、笔数、日均、revert 白烧，并给出11类动作各自的金额、占比、笔数、每笔均价。只统计已补上 gasWei 的条目。status=0 的单列为 revert 白烧（已含在总额里）。动作包括部署/停采/喂食/复活/拾荒/XP药水/合成/升级/加点/重置技能/补步长。单位 mETH（1e15 wei）。触发：showGasReport 内｜命令showGasReport()｜存储kami_gas_ledger｜版本1.2.10
• 日均按账本实际覆盖时长折算仅观测 — 日均的分母取「窗口长度」和「账本实际覆盖时长」里较小的那个，避免账本刚启用时日均被稀释、续航虚高。覆盖时长最少按1小时算，防冷启动除以极小数爆表。窗口没被覆盖满时，在日均后面加人话说明。触发：showGasReport 内｜参数最小覆盖1小时｜来历0718实测账本只记了1.5小时就按整窗口除，续航曾算出4988天｜版本1.2.12
• 报告重复窗口折叠仅观测 — 账本覆盖不足时，更长窗口的数据会完全相同；只展示第一个不满的窗口，其余折叠成一行说明。折叠只影响显示，合计段和续航用的统计数据在折叠前就已填好。触发：showGasReport 内｜版本1.2.14
• 链上总账对照与账本外缺口仅观测 — 报告里列出 cosmos 全量24h总账（金额/笔数，截断时标「仅下限」）、链上分类明细（按金额降序），以及「账本外缺口=链上全量−账本24h」。缺口里包括账本启用前的 tx 和拾荒等无 hash 项。失败时显示「链上总账对照不可用」，不影响主报告。结果同时留给余额续航复用。触发：showGasReport 内（有 operator 地址时）｜存储kami_addr_gas_24h_cache_v3｜来历防gas记账漏挂；账本=实时口径能细分道具/单kami，链上=全量兜底，两者互补｜版本1.2.13
• owner段报告与不假分窗仅观测 — 报告里列出 owner 手动 tx 在各窗口的 gas，拉取时先提示「⏳ 拉取中…」。拿不到当前区块（blockBased=false）时不假装分窗：只报「全部拉到的总额」，也不掺进各窗口和合计，免得把全部历史算进24h。查询失败时提示可用命令行脚本 bash 查gas.sh 兜底，合计段只按 operator 算。没解析到 owner 地址就跳过这段。触发：showGasReport 内｜存储kami_owner_gas_cache｜来历grok审查non-blocking：拿不到区块时假分窗会显示误导数字并污染合计｜版本1.2.8
• operator+owner合计段仅观测 — 按窗口列出 operator 和 owner 的合计 gas，以及合计日均。operator 部分按实际覆盖天数折算，owner 部分按整个窗口算；7天合计日均留给续航段作参考。触发：showGasReport 内｜版本1.2.8
• 余额续航智能数据源仅观测 — 读 operator 链上余额，估算还能用几天，并用人话说明用了哪份数据、为什么。账本覆盖不足24小时且链上24h消耗>0时，用链上真实24h消耗算（链上样本被截断时提示续航可能更短）；否则用 operator 7天日均（按实际覆盖折算）；两者都没有就提示暂无数据。另附 operator+owner 合计日均作参考，续航仍以 operator 为准（owner 你控不了）。异常静默。触发：showGasReport 内｜参数账本成熟线=24h｜来历用户0718定案：账本不足24h时续航直接用链上真实数据，攒满24h自动切回账本口径（能分类、能剔除owner）｜版本1.2.12
• gas报告美化配色与图标仅观测 — 按行的类型自动配色（标题、各段标题、窗口行、动作行、续航行、警告行），动作行前加图标，比如部署🚀、停采🛑、喂食🍎。一次 clog 用多个 %c 分段着色。纯展示层，数据不动；美化出任何异常就原样纯文本输出，保证数据永远可读。触发：showGasReport 末尾｜版本1.2.14
• 页面加载后10分钟自动gas报告仅观测 — 每次页面加载后10分钟自动跑一次 showGasReport()，报告会进日志。只挂一个 setTimeout，不是 interval。调用前设 __kamiCallSource='auto_10min_timer'，所以日志标记为「🤖 [脚本调用@auto_10min_timer]」。核心大约每45分钟例行刷新一次，等效每45分钟一份报告；Rollytics 查询有1小时缓存，多数轮次零网络成本。异常静默。触发：自动：加载后10分钟｜参数10*60*1000 ms｜命令showGasReport()｜版本1.2.16

gas 规则说明

• Gas消耗规则说明（文档）仅观测 — 分清哪些失败不花钱（estimateGas失败、RPC错误、签名/参数错误、预检过滤），哪些会花钱（revert、超时但其实成功、nonce冲突两笔都上链、重复停采）。脚本的预检体系（estimateGas、状态过滤、防重复标记）都是为了把失败拦在不花钱的阶段。触发：文档；showGasRules() 可查看｜命令showGasRules()
• Gas 消耗分类说明 — 说明不耗 gas 的（estimateGas 失败、RPC 连接错误、签名失败、参数错误、预检 CALL_EXCEPTION）与耗 gas 的（上链 revert、超时但成功、nonce 冲突重试两笔上链、重复操作）。静态文本，不读状态不发 tx，随时可安全调用。触发：命令｜命令showGasRules()
• 部署/停采批量 gas 实测表与结论 — 列出 N=1..12 部署与停采单 tx 总 gas、每只摊销与省比；结论：部署 N=10 起省约 45%（边际 0.69M/固定 0.66M），停采 N=12 省 40%（边际 1.36M/固定 1.07M），停采反比部署贵 80~94%；省 gas 优先级①少停不必要的②停采批量③部署批量。单账户单次实测（间隔 1.5s，cooldown 3min），不同账户/时段有偏差，以省比为准。触发：命令｜命令showGasRules()｜来历停采涉及收益结算+状态清理+事件 emit，写操作更多（推测）
• 脚本省 gas 优化清单文案 — 列出紧急停采每批随机 6-10、预检过滤已死/已停、动态等待防重发、一键停采 6-10 随机、喂食每批 3 个、喂食 4 层预检+失败冷却、部署 estimateGas 预检、默认 API 批量，并提醒 cooldown/revert/nonce 冲突会拉高真实成本。静态历史文案，不随代码自动同步，个别描述可能与当前实现不一致（本段未核实）。触发：命令｜命令showGasRules()

1.13 死亡监控与停摆检测

每 3 分钟查一次自家 kami 有没有死；电脑睡眠或页面被冻住醒来后，立刻做一次急救扫描。

自家 kami 死亡监控

• 定时全量死亡检测（启动自动开启） — 每 3 分钟查一次本账户所有 kami，统计 state 为 DEAD 的数量和编号。脚本启动时自动开启，排在部署流程之前。用连接地址调 window.network.explorer.accounts.getByOperator(addr) 拿全量 kami 列表，state 转大写后比较。注释写的是「链上 API」，代码实际读的是 explorer 本地索引器。触发：启动序列自动调 startMyKamiDeathMonitor()，之后每 3 分钟一次｜参数MY_KAMI_DEATH_CHECK_INTERVAL=3min｜来历刻意不用 DOM：渲染不保证完整，可能漏掉部分 kami，以 API 全量查询为准｜版本1.1.13 饥饿模式改名贪婪模式
• 地址或列表缺失时早退 — 拿不到连接地址时打「无法获取账户地址」并返回；kami 列表为空时打「未找到 Kami 列表」并返回。触发：每轮检测开头｜来历页面没就绪时不误判
• 发现死亡：红色大横幅仅观测 — 有 kami 死亡时打白字红底大号横幅「发现 N 个 Kami 死亡」，并列出死亡 kami 的编号。触发：检测到 DEAD 时
• 发现死亡：置杀手警戒，切安全停采线 — 置 window.__killerDetected=true，记下 __lastKillerTime。贪婪模式下由此改用安全停采线。首次进入警戒且处于贪婪模式时，打橙色提示「自动切换到安全停采线，15 分钟后自动恢复贪婪模式」；已在警戒中则打「已处于安全模式中」。注：1.2.51 盲扫注释称 __killerDetected 只有已停用的 Feed 监控会置位，但代码里本死亡监控发现我方死亡时也会置位。触发：检测到 DEAD 时｜参数SAFE_COOLDOWN_MS=15min｜版本1.1.13
• 发现死亡：立即批量复活（不等主循环） — 发现死亡后立刻 fire-and-forget 调 _reviveDeadBatch([])，传空数组，由它内部重新走 API 查死亡名单再复活。挂了 .catch 打日志。本监控、主循环兜底复活、辅助脚本启动窗口复活三路互不重发，并发安全靠 _reviveDeadBatch 内部的 revive 锁和 __reviveSentAt 15 分钟防重发窗口。触发：检测到 DEAD 时｜来历主循环周期约 10 分钟，等它会让死掉的 kami 白白闲置；传空数组是因为两次查询之间状态可能变化，不复用手里的旧列表
• 发现死亡：触发紧急停采 — 发现死亡后调 emergencyStopHarvest()，保护其余还在采集的 kami。调用前检查函数是否存在。代码既没有 await 也没有挂 .catch；注释说 fire-and-forget 都有 catch，实际只有复活那条挂了。触发：检测到 DEAD 时
• 无死亡时自动解除杀手警戒 — 没有死亡时打「检测 N 个 Kami，无死亡」。如果正处于警戒中，且距上次发现死亡已满 15 分钟，就解除警戒（贪婪模式恢复极限停采线，打绿色日志）；没满就打剩余分钟数。剩余分钟数向上取整。触发：每轮检测无死亡时｜参数SAFE_COOLDOWN_MS=15min; GREEDY_THRESHOLD｜版本1.1.13
• 单轮检测异常隔离 — 整个检测体包在 try/catch 里，某一轮出错只打日志，不影响后续轮次。触发：每轮检测
• 控制台命令 startMyKamiDeathMonitor（防重复启动） — 启动死亡监控：打启动日志和检测间隔，立即检测一次，然后每 3 分钟定时检测。定时器已存在时打「已在运行中」并拒绝二次启动。触发：命令（启动时也会自动调用）｜参数MY_KAMI_DEATH_CHECK_INTERVAL=3min｜命令startMyKamiDeathMonitor()
• 控制台命令 stopMyKamiDeathMonitor — 清除定时器，停止死亡监控，打「已停止」。没在运行时静默不做事。触发：命令｜命令stopMyKamiDeathMonitor()
• 控制台命令 checkMyKamiDeath — 手动立即跑一轮死亡检测，发现死亡会同样触发复活、紧急停采和警戒。触发：命令（停摆检测器急救也会调用）｜命令checkMyKamiDeath()

停摆检测器

• 启动中断时长回溯仅观测 — 启动时读上次运行的心跳时间戳，距今超过5分钟就用红底大字报告中断了多久（推测是睡眠、关机或浏览器关闭），并提示即将做死亡扫描。只读 localStorage，不在这里触发急救。读不到（如隐私模式）静默。时长显示为「X小时Y分」或「Y分」。触发：脚本注入后立即｜参数中断阈值5分钟｜存储kami_last_heartbeat（只读）｜来历只读不急救，避免与死亡监控双跑｜版本1.2.9
• 停摆检测器幂等初始化 — 脚本注入后在模块级自动启动。window.__stallDetectorOn 已置位时直接返回，重复加载不会重复挂定时器。初始化整体 try/catch，失败只打「初始化失败（不影响主流程）」。触发：脚本加载时自动｜来历防止双挂 setInterval（I3）｜版本1.2.9 停摆检测器
• 30 秒心跳写入 localStorage — 每 30 秒记一次心跳时间戳，启动时也立即写一次，供下次会话在启动阶段回溯上次中断（回溯在启动提示板块，只打日志、不急救）。只写这一个键，写失败静默（I4）。触发：启动时及每 30 秒｜参数STALL_TICK_MS=30s｜存储kami_last_heartbeat｜来历启动回溯不急救，避免和 startMyKamiDeathMonitor 双跑｜版本1.2.9 停摆检测器
• 事件循环跳变检测 — 每次 tick 计算和上次 tick 的间隔 gap。gap<120 秒算正常抖动，忽略；≥120 秒说明 JS 事件循环被系统睡眠或浏览器挂起打断过。触发：每 30 秒 tick｜参数STALL_SHORT_MS=120s｜版本1.2.9 停摆检测器
• 停摆事件 2 小时窗口计数 — 短停摆和睡眠级停摆都记为事件，只保留最近 2 小时，用于判断是不是碎片化睡眠。每次记录后剪掉超过 2 小时的旧事件。触发：gap≥120s 时｜参数STALL_EVENTS_KEEP_MS=2h｜版本1.2.9 停摆检测器
• 短停摆黄色日志仅观测 — 停摆 2~5 分钟时打黄色日志：停摆多久、从几点到几点（HH:MM）、近 2 小时第几次。时长格式化成「X 分钟 / X 小时 Y 分」，时间按本地时区偏移 __TZ_OFFSET_MS 显示。触发：120s≤gap<5min｜参数STALL_SLEEP_MS=5min｜版本1.2.9 停摆检测器
• 睡眠级停摆大红横幅仅观测 — 停摆 ≥5 分钟时打白字红底大横幅，写明停摆时长、时间段和推测原因；第二行提示「停摆期间 kami 血量仍在流失且无人停采，请立即插上电源/关闭自动睡眠；正在自动急救」。触发：gap≥5min｜参数STALL_SLEEP_MS=5min｜版本1.2.9 停摆检测器
• 停摆原因人话诊断（决策树）仅观测 — 按顺序判断：navigator.onLine 为 false → 网络当前断开；近 2 小时停摆 ≥3 次 → 碎片化睡眠，笔记本没插电源，电池模式下系统反复自动睡眠（Mac 的防睡眠设置只在插电时生效）；否则 → 电脑睡眠/待机或浏览器被挂起。不发任何新请求。触发：睡眠级停摆时｜参数碎片化判定阈值=近2小时≥3次｜版本1.2.9 停摆检测器
• 醒来急救去重 — 急救正在进行时再次触发，只打「急救已在进行中，跳过重复触发」，不重复执行。用 __stallRescueInFlight 标记，finally 里复位。触发：睡眠级停摆触发急救时｜版本1.2.9 停摆检测器
• 急救尊重紧急锁（排队不硬闯） — 紧急锁被占用时，调 waitForEmergencyRelease 最多等 300 秒；超时就跳过本次急救死亡扫描（橙色日志）。没有等待接口时也直接跳过。和常规交易入口的锁策略一致。触发：醒来急救开始时｜参数等锁超时=300000ms｜版本1.2.9 停摆检测器
• 醒来立即死亡扫描 — 醒来后立即 await checkMyKamiDeath()。发现死亡时会连带触发批量复活、紧急停采和杀手警戒。函数不可用时只打日志。不新增任何直接发交易的路径，只调现有的死亡扫描。注释写「checkMyKamiDeath 内部锁保护」，但它本身代码里没有锁，复活防重发在 _reviveDeadBatch 内部。触发：睡眠级停摆急救｜版本1.2.9 停摆检测器
• 醒后 90 秒复检 — 急救扫描之后 90 秒再做一次死亡扫描，复检前同样等紧急锁（最多 300 秒，超时放弃复检）。用 setTimeout 异步执行，异常 catch 后打日志；排定时打一行「醒后索引可能滞后，90s后复检」。触发：醒来急救后 90 秒｜参数STALL_RECHECK_MS=90s｜来历0716 实测：刚醒时扫描可能读到滞后的索引，误报「无死亡」｜版本1.2.9 停摆检测器
• 醒来不强制抢跑主循环 — 醒来后不直接调 runAutomation，只提示「建议等主循环下轮（≤10分钟）」。触发：醒来急救末尾｜来历查证 runAutomation 开头没有 running 标志或重入锁，醒来强行调用会和周期主循环并发｜版本1.2.9 停摆检测器
• 检测器自身异常隔离 — tick、急救、急救 Promise、90 秒复检都各自 try/catch，自身出错只打日志，不影响主流程。急救以 fire-and-forget 方式调用，不阻塞 interval 回调。触发：全程｜版本1.2.9 停摆检测器
• 停摆检测器启动日志仅观测 — 启动时打绿色日志，写明每 30 秒心跳、≥120 秒记短停摆、≥5 分钟触发睡眠级急救。触发：初始化完成时｜版本1.2.9 停摆检测器

1.14 保活

防止页面长时间没人操作被降速或断开。

防断连模拟点击

• 真实鼠标活动计时（isTrusted 守卫） — 记录用户最后一次真实动鼠标或点击的时间，供判断「是否长时间无人操作」。window 上监听 mousemove 和 click，只有 e.isTrusted 为 true（真人事件）才刷新 lastMouseActivity，合成事件一律忽略。触发：initIdleKeepAlive() 启动时注册，常驻｜来历两套保活各自独立判断真人：忽略人化保活和本模块自己派发的合成事件，免得被当成真人活动而误跳过模拟
• 定期空闲检查循环（带随机抖动） — 一个永不退出的循环，隔一段时间醒来检查一次，长时间无人操作就模拟一次鼠标点击，防止被判离线或断开。每轮等 60 秒 + getRandomDelayMs(1)。注释写「约 60 秒 + 抖动」，代码实际 getRandomDelayMs(1) 是 0~60 秒，所以每轮间隔 60~120 秒。按代码实际：这个模块没有开关，setKeepAlive('off') 关不掉它（那个命令只管人化保活）。触发：启动主流程第一个拉起 initIdleKeepAlive()，之后常驻｜参数循环基础间隔 60*1000ms + 0~60s 随机｜来历间隔不完全固定，行为更接近真人
• 60 秒无真人活动才模拟 — 距上次真实鼠标活动不到 60 秒就跳过这一轮，真人在用时不打扰。now - lastMouseActivity > 60 秒才执行模拟，否则打「🟢 有鼠标活动，跳过模拟」。触发：每轮循环醒来时｜参数空闲判定阈值 60*1000ms｜来历真人在用时不干扰
• 左下角合成鼠标点击 — 在屏幕左下角 (10, 窗口高-10) 处，按真实点击的顺序派发一整组鼠标事件。elementFromPoint 取该坐标下的元素，取不到退回 document.body；依次派发 mousemove、mousedown、mouseup、click，bubbles 和 cancelable 都为 true，保证游戏的事件监听收得到。代码没有检查该坐标下的元素是不是按钮，安全性依赖左下角恰好是空白处（不像人化保活那样用白名单）。触发：判定空闲时｜参数坐标 x=10, y=innerHeight-10｜来历固定点左下角空白处，避免误点游戏内按钮
• 模拟点击日志限流仅观测 — 模拟点击的日志只在第 1 次和之后每满 10 次各打一条，避免每分钟一条刷满日志缓冲区。__idleSimCount 累加，等于 1 或能被 10 整除时打「💻 模拟点击屏幕左下角（累计 N 次）」。按代码实际：「有鼠标活动，跳过模拟」那条日志没有限流，真人在用时每轮都会打。启动时另有一条「🌀 已启动 idle 模拟机制」。触发：每次模拟后｜参数限流步长 10｜来历防止日志缓冲区被刷满

人化活动保活

• 人化保活总开关 setKeepAlive — 开关人化活动保活，默认开启。localStorage 的 kami_keepalive 值为 'off' 时禁用；读取出错按开启处理。setKeepAlive 只接受 'on' 或 'off'，其他参数打印用法和当前状态；设置后打「✅ 活动保活已切为 X」。每次定时触发都会重新读开关，改完立即生效。整个模块全程 try/catch，异常静默跳过，不发任何 tx。触发：命令；每次定时触发时读取｜命令setKeepAlive('on') / setKeepAlive('off')；不带参数则显示当前状态｜存储kami_keepalive｜版本1.1.22
• 真人活动监听与 3 分钟让路 — 监听真人操作，3 分钟内有过真人操作时，合成移动和列表扫掠全部跳过，不打扰玩家，也不污染对照实验。用 capture+passive 方式监听 mousedown、keydown、wheel、mousemove、pointerdown、touchstart，只有 isTrusted 的事件才刷新 __lastRealActivity；_humanActive() = 距上次真人操作不到 3 分钟。注释只列了 5 种事件，代码实际还多监听了 touchstart。触发：模块注入即注册，常驻｜参数REAL_IDLE_MS=3分钟｜来历不打扰玩家，也不污染对照实验数据｜版本1.1.22
• 约 75 秒一次合成 mousemove — 定期在页面上派发一次随机位置的合成鼠标移动，让页面「看起来有人在」。在 document 上派发 mousemove，坐标 x 100~700、y 100~500 随机（isTrusted=false）。开关开且无真人活动时才派发并计数；开关开但真人活跃时计一次「让路」。周期 75 秒 + 0~15 秒随机；脚本注入 45 秒后第一次触发，不等启动主流程。触发：自动：setTimeout 自循环｜参数MOVE_BASE_MS=75000 + 0~15s 随机；首次 45s｜来历0710 某账户组件同步滞后风暴时，页面可见、WS 和区块流都正常，嫌疑集中在 app 级「无操作降速」，于是做模拟真人活动的对照实验｜版本1.1.22
• 约 5 分钟一次人化全程扫掠 — 定期把 kami 列表像真人一样慢慢滚到底、再滚回顶、最后回到原位，全程约 20 秒。只在开关开、无真人活动、未持有紧急锁时启动扫掠，否则（开关开时）计一次「让路」。周期 5 分钟 + 0~60 秒随机；脚本注入 90 秒后第一次触发。触发：自动：setTimeout 自循环｜参数SWEEP_BASE_MS=5分钟 + 0~60s 随机；首次 90s｜来历对照实验：风暴消失就坐实并保留，无效就下轮撤掉｜版本1.1.22
• 紧急锁期间跳过扫掠 — 紧急停采持有 TX 紧急锁时，本轮不扫掠。直接读 window.__txEmergencyLock，没走 hasEmergencyLock()，所以不会顺带触发 10 分钟超时自愈。被锁挡住也记进「真人让路」计数。注释写「紧急锁期间顺延」，代码实际是本轮跳过，等 5~6 分钟后的下一轮再判断。扫掠开始后中途不再检查锁。触发：每次扫掠定时触发时｜存储window.__txEmergencyLock（读）｜版本1.1.22
• 扫掠防重入 — 上一轮扫掠还没结束时，不会再开新一轮。用 __sweepRunning 标记，开始时置 true，finally 里复位为 false。触发：_sweep() 入口｜版本1.1.22
• 定位 kami 列表滚动容器 — 找到真正可以滚动的 kami 列表容器，找不到这一轮就不扫。从 Party 列表第一张卡片开始沿父元素往上找，第一个 scrollHeight > clientHeight+10 的元素就是滚动容器；一张卡片都没有、或一直找到 body 都没找到时返回空，本轮直接退出。触发：_sweep() 开始时｜版本1.1.22
• 保活点击白名单锚定（HP 文本 / 状态图标） — 扫掠前的一次点击，只点两种确认安全的纯展示元素，绝不随机点。主锚点：卡片里没有子元素、宽高都大于 5px、整段文字完全匹配「数字/数字 (数字%)」（_HP_RE 全匹配，防止含这个格式子串的其他元素混进来）的 HP 文本。备用：状态图标，优先 img[src*="/assets/kami_harvesting"]，否则 kami_* 图标（宽高大于 3px）。主锚点有就只用主锚点，都没有才用图标；从候选里随机选一个，在中心坐标派发 mousedown、mouseup、click。触发：每次扫掠开始时｜参数_HP_RE=/^\s*\d+\s*\/\s*\d+\s*(\s*\d+\s*%\s*)\s*$/｜来历真钱教训：游戏的喂食、停采按钮都是纯 div，旧版「排除 button/a 后随机点 div」点开了喂食菜单，下轮又点中食物，误喂了 Half Heart / Cleaning Fluid 等真钱道具｜版本1.2.3
• 点击找不到锚点时本轮不点（fail-closed） — 两种锚点都认不到时，这一轮干脆不点，并计数方便排障。候选池为空就 __keepaliveNoTarget++ 后 return，这个数会出现在小时汇总里。触发：_safeClick 内｜来历交互必须正向锚定，认不出就不动手｜版本1.2.3
• 语义按钮兜底排除 — 选中的锚点如果在按钮、链接或可点击元素里面，就不点。t.closest('button,a,[role=button],[onclick]') 命中就 return。注释说明：事件会冒泡，这个检查挡不住 React 在根节点的事件委托；但两个锚点的祖先是卡片行（点了只是选中，不发 tx），里面不含喂食按钮，所以误喂链已经断了（经 grok 审查确认）。触发：_safeClick 内｜来历多一层语义兜底｜版本1.2.3
• 扫掠滚动节奏（仿真人） — 模仿真人的节奏滚动列表：小步走、随机停顿、偶尔停下来，到底后歇一会再回顶，最后回到原位。每步滚 250~420px，停 300~700ms，每步有 12% 概率额外停 1.5 秒；到底后停 0.8~1.5 秒再往回滚；每个方向最多 120 步（防死循环）；结束后 scrollTop 恢复原位，扫掠计数 +1。触发：_sweep() 内｜参数步长 250~420px；停顿 300~700ms；驻足 12%×1.5s；每方向最多 120 步｜版本1.1.22
• 扫掠中真人来了立即还原 — 滚动过程中一旦检测到真人操作，立刻停下并把列表还原到原来的位置。每滚一步都检查 _humanActive()，是则 scrollTop=origin、让路计数 +1，打橙色日志「检测到你在操作，已立即停止滚动并还原位置」后退出。触发：扫掠每一步后｜来历不打扰玩家｜版本1.1.22
• 扫掠可见性提示日志仅观测 — 扫掠开始和结束时各打一条控制台说明，让用户知道列表自己滚动是脚本行为。开始时打蓝色说明：脚本在自动滚动 kami 列表防浏览器降速，约 20 秒，不是电脑被入侵，动一下鼠标就停止并还原，永久关闭用 setKeepAlive('off')。结束时打绿色「自动滚动结束，列表已回到原位」。只打日志，不碰游戏 UI。触发：每次扫掠开始/结束｜命令setKeepAlive('off')｜来历用户反馈列表突然自己滚动，不明真相会以为电脑被黑｜版本1.2.18
• 保活每小时汇总日志仅观测 — 每小时汇总一次：合成 mousemove 次数、全程扫掠次数、真人让路次数、点击找不到锚点次数，汇报后清零。在 _tickMove 里判断距上次汇报 ≥3600000ms 就输出。统计口径：开关开且真人活跃时每个 75 秒周期计一次让路，扫掠被紧急锁挡住也计让路，所以「真人让路」里混有锁让路。按代码推断：计时从脚本注入开始算，而定时刷新每 45~50 分钟整页刷新一次（计数随之归零），正常会话里到不了 60 分钟，这条汇总基本不会输出，除非刷新被紧急停采或操作让路推迟。触发：_tickMove 每次运行时检查｜参数汇报间隔 3600000ms｜版本1.1.22
• 人化保活启动说明日志仅观测 — 模块启动时打两条说明：机制概要（75 秒合成移动 + 5 分钟扫掠，真人 3 分钟内让路，关闭命令），以及「每约 5 分钟自动滚动一次列表不是异常，届时有蓝色提示」。模块是注入即执行的 IIFE，不经过启动主流程的 120 秒等待。触发：脚本注入时｜命令setKeepAlive('off')｜版本1.1.22

1.15 日志、调试与诊断

日志怎么打、怎么存、怎么开调试，以及一批只打日志、不改行为的诊断传感器。

日志输出

• 日志时区设置 — 所有日志和时间显示使用的时区，默认 'auto' 跟随浏览器本地，也可写死小时数（可带小数）。加载时算一次偏移量 __TZ_OFFSET_MS，生成标签 __TZ_LABEL（如 UTC+8）和 ISO 后缀 __TZ_ISO_SUFFIX（供 gas 时间戳解析）。只影响显示；gas 账本按 epoch 毫秒存，中途改时区不影响统计。偏移只在加载时计算，时区变化要刷新才生效。触发：脚本注入时计算一次｜参数TZ_OFFSET_HOURS='auto'｜版本v1.1.3 起
• log() 统一业务日志出口 — 全脚本业务日志的唯一出口：自动加 [核心脚本][时间] 前缀，打到控制台，同时把纯文本副本写进内存日志缓冲区。首参以 %c 开头时把前缀插在 %c 后面，保证样式生效。时间按配置时区格式化为 YYYY-MM-DD HH:MM:SS。注释写「剥掉 %c 样式标记」，代码实际只删掉 %c 字符，配套的 CSS 样式字符串仍会原样写进缓冲区；多行文本也不拆行。触发：全脚本各处调用
• 跨脚本共享日志缓冲区 — window.__kamiLogBuffer 是全局字符串数组，供 saveKamiLogs() 一键导出完整日志。用 window.__kamiLogBuffer || [] 初始化：辅助脚本已建就复用，脚本重载或多脚本共存时不清空已有日志。页面刷新即清空，持久化靠导出。触发：脚本注入时初始化｜命令saveKamiLogs()
• 日志对象序列化防抛错 — log() 把对象参数转成 JSON 写入缓冲区，序列化失败（比如循环引用）就回退成 String，保证 log 自身不因序列化抛错。JSON.stringify 外包 try/catch。触发：每次 log()
• clog 控制台输出同步入日志 — 替代脚本自有的 console.log：控制台显示一字不变（%c 彩色照常），另把纯文本副本写进日志缓冲区。纯文本按换行拆开，每行单独入库、各带时间戳，方便 grep。缓冲区不是数组时重建。入库部分全程 try，日志功能绝不能把主流程搞挂。触发：启动命令清单、gas报告、模式/通道切换回执、告警等处调用｜来历0911实盘：showGasReport()被自动触发164次，日志文件里零记录；用户定案「我要都走日志，方便事后检查日志」｜版本1.2.32
• __plainArgs 样式剥离 — 把 console 参数转成可读纯文本：删掉首参里的 %c，并跳过与之配套的 CSS 字符串参数。数出首参里 %c 的个数 N，跳过后面 N 个字符串参数；其余字符串原样保留，对象 JSON 化，失败回退 String。触发：clog 调用｜版本1.2.32
• ctable 表格输出入日志 — 替代 console.table：控制台照常画表，日志里先写「（表格 N 行）」，再每行一条 JSON。console.table 失败时回退 console.log。非数组包成单元素数组。每行序列化失败回退 String。整体 try 包住。触发：脚本需要表格输出处调用｜版本1.2.32
• wrapManual 调用来源标记 — 包装挂到 window 上的控制台命令，每次调用先打一条入口标记，区分用户手敲和外部脚本调用。先读 window.__kamiCallSource，读完立即 delete（一次性消费）。有来源打蓝色「🤖 [脚本调用@来源] 命令(参数)」，没有打紫色「🖐️ [手动调用] 命令(参数)」。参数里字符串加引号、函数记 fn、序列化异常记 …，然后原样透传调用并返回结果。只包装 window.xxx 入口（后文统一包装16个命令），内部以裸函数名调用的路径不打标，避免刷屏。触发：window 命令被调用时；杀手监控等外部脚本调用前写 __kamiCallSource｜来历读后立即删除，防外部调用崩溃后残留，把下一次手动调用误判成脚本调用
• _fmtMinSec 耗时格式化仅观测 — 把毫秒数格式化成「X分X.X秒」，用于日志里的耗时说明。分钟向下取整，秒保留1位小数。触发：各日志处调用
• 部署清单单行格式化 _fmtStartList仅观测 — 把待部署清单压缩成一行，每只格式为「#数据库编号/img图片编号/kid:前6位…」，逗号拼接。缺 kamiId 时显示 kid:N/A；截断长度 6 写死；字段缺失不抛错。触发：批量部署日志输出处｜来历便于在控制台快速对照每只 Kami
• 停采清单单行格式化 _fmtStopList仅观测 — 把待停采清单压缩成一行，每只格式为「#数据库编号/img图片编号/hid:前6位…/Δ=两位小数」。缺 harvestId 时显示 hid:N/A；delta 不是数字时不附 Δ；Δ 是清单构造方传入的指标，只原样展示。触发：批量停采日志输出处

错误与异常入日志

• console.error 抄送入日志仅观测 — 替换 console.error：先原样转发给控制台，再把内容以 [ERROR] 标签写进日志缓冲区，保证导出的日志带完整错误现场。Error 对象展开成 name、message 和 stack，其余参数 JSON 化，失败回退 String。游戏自身的 error 也会被抄送。触发：任何 console.error 调用｜命令saveKamiLogs()
• console.warn 抄送与噪声过滤仅观测 — 替换 console.warn：控制台照常显示，写日志前先过噪声名单，命中的不入库，其余以 [WARN] 标签写入。噪声名单6条正则，都锚定行首：getSourceID/getAccountIndex/getOperatorAddress/getOwnerAddress/getRoomIndex 的「(): undefined」告警，以及「no onyx item found」。[TXQueue]/[queue] 这类有价值的 WARN 全部保留。触发：任何 console.warn 调用｜参数__WARN_NOISE_PATTERNS（6条正则）｜来历游戏自身对entity 0/未知实体的getter告警每5秒一轮，不过滤时单份日志30-40%是噪声
• 全局未捕获异常记录仅观测 — 监听 window 的 error 事件，把未捕获异常以「[UNCAUGHT] 消息 at 文件:行:列」写进日志。只写缓冲区，不影响控制台。触发：页面出现未捕获异常时
• 未处理Promise拒绝记录仅观测 — 监听 unhandledrejection，把未处理的 Promise 拒绝以 [REJECTION] 标签写进日志。reason 是 Error 时记 name: message，否则记 String(reason)。触发：出现未处理 rejection 时

日志保存

• 日志导出为 txt 文件下载 — 把内存日志缓冲区一次性导出成 .txt 文件，触发浏览器下载到「下载」文件夹。日志按换行拼接成 Blob（text/plain;charset=utf-8），创建隐藏的 <a download> 并 click() 触发下载，随后移除 <a> 并 revokeObjectURL 释放内存。完成后打绿色日志「已保存 N 条日志到 下载文件夹/文件名」。触发：smartReload 刷新前、定时刷新前、卸载钩子、用户手动 saveKamiLogs()｜命令saveKamiLogs()｜存储window.__kamiLogBuffer（读）｜来历刷新后内存日志会丢，必须先落盘
• 文件名带账户名（反查失败则省略） — 文件名格式是 kami_log_<账户名>_<日期>_<时间>.txt，多号日志一眼能分清。由 connectedAddress 通过 explorer.accounts.getByOperator 反查账户名，整段包在 try/catch 里，接口没就绪时静默留空；账户名为空时文件名直接省略这一段。触发：saveLogsBeforeReload() 内部
• 导出前做一次低余额告警检查 — 导出日志前先检查一次账户余额是否偏低，产生的告警日志会一起写进同一份文件。调用 checkLowBalanceOnce(账户名或'(unknown)', 'end')，外面包 try/catch；stage='end' 不受「只查一次」限制。顺序不能颠倒，否则告警进不了文件。注释写「导出前结算一次 gas 统计」，代码实际调用的是低余额检查，没有 gas 结算。触发：每次保存日志时｜来历先检查后导出，告警日志才能进同一份文件
• 空缓冲区不生成文件 — 缓冲区里没有日志时不下载空文件，只打一条「无日志需要保存」。logs.length===0 时直接 return；这种情况不更新 __lastLogSaveAt。触发：saveLogsBeforeReload() 内部｜来历避免下载空文件
• 文件名时间按配置时区换算 — 文件名里的日期和时间统一按配置的时区生成，多台机器的日志文件名能对齐。now + __TZ_OFFSET_MS 后取 ISO 字符串，日期取 YYYY-MM-DD，时间取 HH-MM-SS（冒号换成连字符）。TZ_OFFSET_HOURS='auto' 时用浏览器本地时区。注释写「时区偏移（8 小时）内置」，代码实际可配置，默认 auto。触发：saveLogsBeforeReload() 内部｜参数TZ_OFFSET_HOURS='auto'｜来历便于多机日志按同一时区对齐
• 记录上次保存时刻供去重 — 每次成功保存后记下时间，供「卸载前抢救日志」判断刚才是不是已经存过。__lastLogSaveAt = Date.now()。这是内存变量，页面刷新（新会话）后归零。触发：每次成功保存后｜来历自动刷新路径是先保存再 reload，不去重会产生两份重复文件｜版本1.2.19
• 控制台命令 saveKamiLogs — 随时手动把当前全部日志导出到下载文件夹。window.saveKamiLogs = saveLogsBeforeReload；也在「手动调用」标记列表里，调用时日志会标 🖐️ [手动调用]。触发：命令｜命令saveKamiLogs()

手动调用标记

• 控制台命令统一加手动/脚本调用标记仅观测 — 把 16 个面向用户的控制台命令统一包一层，每次调用都在日志里写明是手动敲的还是脚本调的，并带上参数，事后查日志能分清人工和自动。遍历命令名列表，仅当 window[name] 是函数时才替换成 wrapManual(name, fn)，不存在就静默跳过。wrapManual：读 window.__kamiCallSource，读完立即 delete（一次性消费）；有来源打蓝色「🤖 [脚本调用@来源] 命令(参数)」，没有则打紫色「🖐️ [手动调用] 命令(参数)」。参数用 JSON 序列化，函数显示为 fn，序列化失败退回 String 或「…」。原命令功能不变。触发：脚本加载时执行一次原地替换；之后每次调用命令时记日志｜命令emergencyStopHarvest()、stopCurrentRoom()、setKamiMode(mode)、getKamiMode()、clearBlockedKamis()、clearStopBlockedKamis()、showStopBlockedKamis()、showBlockedKamis()、clearFeedFails()、clearStarvingStuck()、showGasRules()、clearXPPotionFed()、clearFortifiedFed()、saveKamiLogs()、showGasReport()、showMyKillers()｜来历排查问题时区分自动流程和人工操作非常关键
• 跨脚本调用来源约定 __kamiCallSource仅观测 — 杀手监控等外部脚本调用核心脚本的 window 命令前，先写入调用来源，这样日志里显示「脚本调用@来源」，不会被误记成手动。调用方在调用前给 window.__kamiCallSource 赋值；包装器读完立即删除，防止上次调用崩溃后残留，把下一次真正的手动调用误判成脚本调用。控制台手敲不会赋值，默认归为手动。只包装 window.xxx 入口，脚本内部直接用函数名调用的路径不受影响。触发：外部脚本调用被包装的命令时｜存储window.__kamiCallSource（跨脚本全局变量）｜来历一次性消费，防崩溃残留误判下一次手动调用
• 刻意不包装的入口 — 有几个入口故意不加手动标记。kamiDebugOn / kamiDebugOff 内部会 location.reload，刷新后标记不稳定；waitForEmergencyRelease 是给辅助脚本用的 API，不算用户手动命令。另外按代码实际：setKeepAlive 定义在这个列表之后、也不在列表里，所以调用时同样不带手动标记。触发：脚本加载时｜来历debug 开关带刷新副作用；辅助脚本 API 不属于人工操作

调试开关

• 分类调试日志 dlog — 按标签分类的调试日志开关，平时全部静默，排查时只开需要的几类；输出走 clog 进日志。总开关 kami_debug 为 '1' 才开。标签默认值 parse/start/stop/api/dom/feed 全为 false。dlog 在总开关关闭时第一行就 return（零开销）；标签被显式设为 false 才拦，默认表里没有的新标签放行。开关只在加载时读一次，改完要刷新。__DBG_ON 那次 localStorage 读取没包 try/catch。触发：各板块调用 dlog(tag, ...)｜参数__DBG_DEFAULT={parse,start,stop,api,dom,feed 全 false}｜命令kamiDebugOn({ parse: true }) / kamiDebugOff()｜存储kami_debug / kami_debug_flags｜来历避免控制台刷屏
• 调试flags损坏回退 — kami_debug_flags 内容损坏或不存在时，自动回退到默认标签表。JSON.parse 包 try/catch；空字符串解析失败也走默认值。触发：脚本注入时初始化｜存储kami_debug_flags
• kamiDebugOn(flags) 开启调试命令 — 打开调试总开关，并把传入的标签合并进已有设置，然后刷新页面生效。写 kami_debug='1'，kami_debug_flags=JSON({...当前,...flags})，再 location.reload()。因为默认全 false，只有传入 true 的标签会打开。触发：控制台手敲｜命令kamiDebugOn({ parse: true })（可选标签 parse/start/stop/api/dom/feed）｜存储kami_debug / kami_debug_flags｜来历开关只在加载时读取，必须刷新
• kamiDebugOff() 关闭调试命令 — 关闭调试总开关并刷新页面。写 kami_debug='0' 后 location.reload()。kami_debug_flags 不清除，下次开启时沿用。触发：控制台手敲｜命令kamiDebugOff()｜存储kami_debug

前端冻结传感器与每小时心跳

• 前端冻结门闩读取口 _isFrontendFrozen — 给停采/喂食/拉黑等业务门闩读「前端是否冻死」的统一入口。window.__frontendFrozen 是布尔就返回它，否则返回 false，传感器没接线时保持旧行为。后文多处业务代码调用。触发：被业务门闩调用｜来历Bug B：前端卡死时禁止新增拉黑、禁止放弃喂食｜版本v1.1.25
• 前端传感器·冻死判定 — 判断 MUD 前端同步流是否卡死（WebSocket 断或后台被节流），结果写入 window.__frontendFrozen 供门闩使用；本身不发 tx、不刷新页面。至少两个独立信号、以 blockStalled 为锚才判冻死：blockStalled&&connDown、blockStalled&&timerDrift、blockStalled&&canaryNull、connDown&&canaryNull；hidden 只作旁证。代码注意：canaryNull 读 window.__frontendCanaryNull，全文件无处写入，恒为 false；gated 读 window.__emergencyLockHeld，全文件也无处写入，门控恒不生效。实际等效为 blockStalled 且（connDown 或 timerDrift）。触发：runAutomation / emergencyStopHarvest 入口调用 window.__evalFrontendFrozen(expectedIntervalMs)｜参数BLOCK_STALL_MS=90000｜命令showFrontendSensor()｜来历v1.1.25根因：MUD同步流卡死→explorer读冻旧值→停采发不出、喂食库存读0、gas谎报成功→误拉黑/放弃喂食→kami饿死｜版本v1.1.25
• 前端传感器·区块号订阅与基线 — 订阅 window.network.network.blockNumber$，区块号一变就记下前进时间。订阅成功才建立基线，没基线不判 stalled，避免刚启动就误判冻死。订阅时立即读一次当前值。首次订阅成功打一条「🧊 已订阅 blockNumber$，传感器启动」，靠 _subscribed 天然去重。触发：每次 __evalFrontendFrozen 时尝试（已订阅则跳过）｜来历Initia出块快，区块号是最可靠的同步心跳｜版本1.1.17
• 前端传感器·不可订阅时轮询退路 — blockNumber$ 不是可订阅对象时，每轮直接读值比较，也能判断区块有没有前进。依次尝试 getValue()、.value、原始值。首次读到值时建立基线，并只播报一次「退化为轮询读值模式」（_fallbackAnnounced 防刷屏）。触发：每次评估且未订阅成功时｜版本1.1.17
• 前端传感器·WS断连信号 — 读 network.connected，判断 WebSocket 是否断开。兼容布尔、Subject.getValue()、{value} 三种形状，只有明确为 false 才算断。读不到或异常一律算未断（不判冻死）。触发：每次评估｜版本v1.1.25
• 前端传感器·后台节流计时漂移 — 两次评估的实际间隔远超预期时，判为疑似被浏览器后台节流。实际间隔 ≥ 预期×3（预期缺省600000ms）时开始计时，持续≥60秒才判 timerDrift=true；间隔一恢复就清零。触发：每次评估｜参数TIMER_DRIFT_RATIO=3；TIMER_DRIFT_SUSTAIN_MS=60000；缺省预期间隔600000ms｜版本v1.1.25
• 前端传感器·读失败降级 — 评估过程出任何异常都返回 false，不判冻死，也不打断主循环。整个评估包在 try，catch 里 return false（注释标 I2）。触发：评估异常时｜来历读失败不应误触门闩或中断主流程｜版本v1.1.25
• 前端传感器·冻死翻转日志仅观测 — 冻死状态发生翻转时打一条日志（冻死红色、恢复绿色），附带各信号的当前值。frozen 和上一次不同才打，不重复刷屏。内容含 blockStalled、块号、停滞秒、已订阅、connDown、timerDrift、canaryNull、hidden。触发：判定结果翻转时｜版本v1.1.25
• 前端传感器·冻结瞬间深快照仅观测 — 刚判为冻死的那一刻，dump 一份现场快照，用来抓组件仓滞后的根因。内容：blockNumber$ 当前值和停滞秒、connected 原值、explorer.kamis/txQueue 是否就绪、停采退避队列长度（__stopPendingVerify.size）、document.hidden/visibilityState、rAF 近窗最大帧隔、WS 状态。每项独立 try，纯观测。触发：frozen 翻转为 true 时｜来历抓某账户组件滞后风暴根因（区块流正常但组件仓单独滞后=已知盲区；connected翻false=WS问题）｜版本1.2.1
• 前端传感器·每小时心跳仅观测 — 每小时打一条灰色健康心跳，把区块同步、渲染帧率、WS、可见性、RPC 延迟几条健康线汇总在一行。_lastHeartbeatAt 初始为0，所以启动后第一次评估就打首条，之后间隔≥1小时再打。内容含 frozen、已订阅、当前块、停滞秒、connDown、timerDrift、hidden、componentLag、退避未确认只数、rAF fps/最大帧隔/是否冻结、WS 描述、visibility、RPC p50/p90/失败数及测量时间。触发：评估时距上次≥1h｜参数间隔3600000ms｜版本1.1.17
• 组件滞后补盲信号 componentLag仅观测 — 停采退避复读队列里只要有条目复读≥4次（≥90秒档）仍没确认已停，心跳就标 componentLag=疑似。只进心跳日志，不进 frozen 判定，不影响门闩，留给后续标定。触发：每小时心跳时计算｜参数attempts≥4｜来历某账户组件滞后可达数十分钟而blockNumber$仍正常前进=blockStalled盲区｜版本1.1.22
• rAF渲染帧率监视器仅观测 — 用一个空的 requestAnimationFrame 回调计帧，测前端渲染循环是否被浏览器节流冻结；和区块同步是两条独立的健康线。启动即运行，只计数和记最大帧间隔，不会阻止节流（正好如实测量）。心跳时读窗口统计后清零；fps<1 或单帧间隔>5000ms 判 renderFrozen。首次读窗口按1小时算分母。只进日志，不进门闩。触发：脚本注入即启动；心跳时读取｜参数renderFrozen判据：fps<1 或 最大帧隔>5000ms｜来历用户0712实测：关显示器/切后台时浏览器节流rAF，游戏推算的实时HP停更，晃鼠标后HP突跳｜版本1.2.5
• RPC网速诊断仅观测 — 测到链上 RPC 的往返延迟和失败率，结果写进心跳。连续调4次 provider.getBlockNumber、每次间隔300ms，排序取 p50/p90，统计失败数。启动30秒后先测一次；之后每次心跳踢一次、不等结果，结果留给下次心跳打印。_rpcProbeRunning 防重入；没有 provider 就记 note='无provider'。零 tx，零 gas。触发：启动30s + 每小时心跳｜参数RPC_PROBE_N=4；间隔300ms｜来历tx快慢的真因是到链上RPC这条链路而非本机宽带；用户0712定案纯诊断、不据此自动调行为｜版本1.2.6
• showFrontendSensor() 传感器查看命令 — 在控制台打印传感器当前状态。用 clog 输出对象：已订阅、当前块、区块停滞秒、frozen。不经 wrapManual 包装，不打调用标记。触发：控制台手敲｜命令showFrontendSensor()｜版本v1.1.25
• Tampermonkey长source link无法缩短说明仅观测 — 说明控制台每行后面那串 userscript.html 虚拟 URL 在脚本内部改不掉，想看清爽日志请用 saveKamiLogs() 下载。在 kamigotchi.io 的 CSP 加 V8 规则下实测过：new Function、iframe console wrapper 等改写 console 的方案都缩不短。触发：文档（不执行）｜命令saveKamiLogs()｜来历source link是Tampermonkey注入机制生成的虚拟URL

环境指纹与账户信息打印

• 环境指纹自动诊断仅观测 — 启动60秒后自动把排障常问的环境事实写进日志，用户只要发日志，不用再手贴控制台探针。window.network/explorer/txQueue 没就绪时每30秒重试，最多再试3次，仍不行就打一条跳过日志。共输出4行：①通道、模式（kami_mode 缺省 greedy）、explorer/txQueue/api/clock/LoadingState 是否存在；②blockNumber$ 能否订阅及当前块、connected 的形状、frozen；③停采 system 的 executeBatched 与 executeBatchedAllowFailure 类型、api.stop 源码前80字；④CSP meta 内容前120字。纯只读，全 try/catch。触发：自动：启动60s（未就绪再重试3次×30s）｜存储kami_stop_tx_channel / kami_mode（只读）｜来历首战立功：发现不同会话的allowFailure形状差异（一边=function一边=undefined）｜版本1.1.21
• 账户信息 banner仅观测 — 在控制台打印账户总览：账户名、Owner、Operator、Kami 总数（高亮），以及当前地块名、编号和亲和属性。名称缺失显示「(未命名)」，地址缺失显示「(无)」；地块名通过 __getRoomNameByIndex 查，查不到显示「未知」；以分隔线包围。触发：启动流程中游戏加载成功后执行一次
• 采集中地块分布统计（6 路并发池）仅观测 — 找出所有采集中的 Kami，逐只查它所在的采集节点，按地块聚合计数、降序打印「地块名 (#编号) | 采集中 N 个」；没有采集中的就打「(无采集中 Kami)」。内置小型并发池 runPool，并发度 6；单项查询异常写入 {error} 占位，不中断整批。触发：printAccountAndRooms 执行时｜参数runPool concurrency=6（调大更快但链上 API 压力更大）｜来历避免一次性对链上 API 发起几十个请求
• 当前地块亲和属性展示仅观测 — 从全部采集节点里找到当前地块，把它的亲和属性转大写后用 + 拼接，附在「当前地块」行后面。用 nodes.all() 按 roomIndex 严格相等查找；取不到或出错就静默不显示。触发：printAccountAndRooms 执行时
• 启动时低余额检查仅观测 — 会话启动时以账户名调用一次 checkLowBalanceOnce(名称,'start')，检查余额是否低于警戒线。失败静默忽略，不影响主流程。注释头写「以账户名为 key 启动本会话 gas 消耗统计」，代码实际只剩低余额检查。触发：printAccountAndRooms 执行时一次｜版本1.2.7
• 钱包 deadzone/死地址自检自动刷新 — 账户所在房间号为 0，或 Owner/Operator 变成 0x…dead 占位死地址时，判定钱包连接异常：红字提示，10 秒后自动刷新页面，并跳过后续分析和预警。只有数值 0 触发（roomIndex 缺失显示「(未知)」时不触发）；地址转小写后做包含匹配；调用 smartReload('钱包连接异常：deadzone/死地址') 后 return。触发：printAccountAndRooms 打印完地块分布后｜参数刷新前等待 10000ms｜来历钱包连接异常时继续挂机没有意义
• 调用辅助脚本地块适配分析 — 如果辅助脚本注入了 window.kamiAnalyze，就在 banner 之后 await 调用它做地块适配分析；没有就跳过。这里没有单独 try，kamiAnalyze 抛错会被外层 catch 吞掉，同时跳过后面的高清算线预警和缺录提示。触发：printAccountAndRooms 执行时（跨脚本可选）
• 高清算线预警仅观测 — 以 API 实时 Kami 列表去关联本地库，把清算线 LT 超过 65% 的 Kami 按 LT 降序红字逐只列出（#编号、LT、body、链上状态），并提示「停采线上限仅 80%，极易被清算」和维护建议（升级 harmony / 重置技能加 defense，从最高的开始）。LT 为 null 或 NaN 的不计。注释写「阈值 80% 与停采线上限 80% 对应」，代码实际判据是 rec.LT > 65，80 只出现在提示文案里。触发：printAccountAndRooms 执行时（启动一次）｜参数LT 预警阈值 65（写死）｜来历停采线封顶 80%，清算线过高的 Kami 缓冲空间极小，应优先升级降线；以实时列表为基准，已转出账户的 Kami 不会产生幽灵警告
• 清算线全部良好提示仅观测 — 没有高清算线 Kami 且本地库非空时，打绿色「账户内所有已收录 Kami 清算线均 ≤ 80%，状态良好」。文案写 ≤ 80%，代码实际判据是没有 LT > 65 的（或 LT 缺失）；库为空时不打这句。触发：printAccountAndRooms 执行时
• 数据库缺录提示仅观测 — 账户里有但本地库没收录的 Kami，用橙色列出编号，建议刷新页面重跑精简数据库脚本。与高清算线预警在同一次遍历中收集。触发：printAccountAndRooms 执行时
• 账户打印整体异常兜底 — 整个账户/地块打印流程出任何错，都只打一行「获取账户/地块信息失败」，不影响启动。最外层 try/catch。触发：printAccountAndRooms 执行时

1.16 数据库恢复与自愈

启动时从 localStorage 恢复精简数据库；账户有新 kami 时增量补录，只补不删。

启动恢复

• 复用已加载的内存数据库 — 脚本注入时若 window.kami_core_db 已经是数组，直接沿用、不覆盖，并打印条数和查询提示。用 Array.isArray 判断，是数组才走沿用分支，打印共 N 条和「控制台输入 window.kami_core_db 查询」提示。触发：脚本加载时执行一次（顶层代码）｜命令window.kami_core_db（查看数据库内容）｜来历避免覆盖同页其他脚本刚构建好的内存版
• 从本地存储恢复精简数据库 — 读取 localStorage 的 kami_core_db（JSON 数组），挂到 window.kami_core_db 供部署、停采、喂食、XP 药水等板块反查 kamiId 和清算线。读不到时按空数组 '[]' 处理；JSON.parse 放在 try/catch 里，数据损坏只打「读取 kami_core_db 失败」，不中断脚本（此时 window.kami_core_db 保持未定义，下游用 || [] 兜底）。首次使用要先启用精简数据库脚本做一次全量构建，看到「构建完成」后可停用；不做的话库为空，部署、停采、喂食会因查不到 kamiId/LT 而大量跳过。触发：脚本加载时执行一次｜命令window.kami_core_db｜存储kami_core_db（读）
• 精简数据库 17 字段记录约定（跨脚本） — 每条 Kami 记录固定 17 个字段：index、imgNumber、kamiId、harvestId、name、level、harmony、maxhp、body、hand、ratio、shift、LT、LTHP、vioBase、harmBase、powBase。由精简数据库脚本全量生成，本脚本增量维护。imgNumber 是 string 类型，匹配时要 String() 转换；body/hand 是小写亲和字符串；LT 是清算线占最大 HP 的百分比，LTHP 是对应的 HP 绝对值；harvestId 未部署时为 null。触发：部署/停采/喂食/XP 药水等板块按 index 或 imgNumber 反查时使用｜存储kami_core_db

增量自愈 syncKamiDb

• 接口就绪等待 — 开始补全前先轮询等 network/explorer 接口就绪；最终拿不到钱包地址就跳过本次补全。每 200ms 探测 accounts.getByOperator、kamis.getByIndex、connectedAddress.value_ 三者，最多等 10 秒；地址仍为空时打「[DB增量] network/explorer 未就绪，跳过增量补全」，返回 {added:0,total:0,skippedFail:0}。触发：syncKamiDb 调用时｜参数就绪等待上限 10000ms / 探测间隔 200ms｜来历兼容页面加载慢的情况
• 账户 Kami 列表拉取重试 — 用 getByOperator 拉账户全量 Kami 列表，失败最多重试 3 次，间隔递增。拿到 acc.kamis 就停。注释写间隔 300/600/900ms（行内注释写 600/900ms），代码实际每次失败后等 300+tries×300，即 600/900/1200ms；第 3 次失败后还会白等 1200ms 才退出。3 次都失败时按空列表继续。触发：syncKamiDb 调用时｜参数列表重试 3 次｜来历抗网络抖动
• 按 index 做差集，只补不删 — 把账户 Kami 列表和本地库按 index 对比，只挑出库里没有的 Kami 去补；已有记录即使数据陈旧也不动。库的 index 数值化后放进 Set，列表中 index 为有限数且不在 Set 里的算缺失。没有缺失时打「[DB增量] 账户 N 只 vs DB M 条，无新增」并返回 {added:0,total:N}；有缺失时打橙色「发现 N 只账户内有但 DB 没有的 kami」。触发：syncKamiDb 调用时｜命令rebuildKamiCoreDb()（全量重建，由数据库构建脚本提供）｜来历全量刷新交给手动 rebuildKamiCoreDb，自动流程绝不删改旧数据；库缺条目会导致部署跳过、停采漏判清算线、XP 药水找不到目标
• 逐只串行拉详情 + 指数退避 — 对每只缺失 Kami 串行调用 getByIndex（stats/traits/bonus/harvest/progress/time 全开）拉详情，失败最多重试 3 次。退避间隔 250×2^(t-1)，即 250/500/1000ms（行内注释只写到 250/500ms）；第 3 次失败后同样会白等 1000ms 再放弃。触发：发现缺失 Kami 时｜参数详情重试 3 次｜来历缺失量通常很小，串行即可，省掉并发控制的复杂度
• 详情拉取失败时写占位记录 — 某只详情 3 次都拉不到时，仍写入一条 17 字段齐全的占位记录，数值字段全部为 null。占位记录用列表里已有的信息填：index、从 image URL 正则提取的 imgNumber、kamiId、harvest.id、name、level，其余 null；skippedFail+1，打「#index 拉详情失败，已写入占位记录」后继续下一只。触发：单只详情拉取彻底失败时｜来历保证下游 find 至少能按 index 命中，避免每轮都重复 miss、无限循环补拉
• 详情字段解析入库 — 成功拉到详情后，解析出 17 个字段组成记录并追加到内存库，打绿色「➕ #index (名字) Lv.x LT=y% 已入库」。imgNumber 从立绘 URL /kami/(数字).gif 提取（string）；body/hand 亲和转小写；防御 threshold 的 ratio/shift 缺失按 0；harmony/maxhp 和三项 base 值缺失为 null。记录就地 push 进库，同时记进本次新增列表。触发：单只详情拉取成功时
• 旧公式清算线初值 __computeLT — 用「假想满配杀手」旧公式给新补的 Kami 算一个 LT/LTHP 初值，只在拿不到辅助脚本精确算法时兜底。harmony、maxhp、body 任一缺失就不算（LT 为 null）；harmony 或 maxhp 不是正数返回 null。公式：E=normal 取 0.2，其余 0.5；deltaR=max(0,0.5−ratio)；deltaS=max(0,0.4−shift)；phi=正态 CDF(ln(V/harmony))，用 Abramowitz-Stegun 近似并夹到 [0,1]；frac=clamp(phi×0.4×(1+E+deltaR)+deltaS)；LT 保留两位小数。注释矛盾：常量上方行内注释仍写「必须与数据库构建脚本同公式同 V_CONST」，板块头 0912 更正说这句是假的，代码实际只把它当入库初值。触发：详情解析入库时自动｜参数V_CONST=41｜来历0912 更正：数据库脚本 1.2.3 没有 V_CONST，走 DB_TOP_PREDATORS 四档取最坏，辅助还含装备余量，三处算同一只得 66.13/62.75/72.75，真正对齐靠下面的精确重算
• 新增记录改用现役精确清算线重算测试线独有 — 补录结束后，只对本次新增的记录调用辅助脚本的 window.computePreciseLTForRecord，就地改写 LT/LTHP，老记录一个字节不动。逐条 try/catch：返回的 LT 不为 null 才覆盖，值有变化计为修正；单条异常就保留旧值并计失败。完成后打蓝色「新增 N 条已改用现役精确清算线重算（修正 x 条，y 条失败保留旧值）」。这个入口就是辅助每小时用的那个（现役杀手档案 + 装备余量 + 沉寂降级）。触发：syncKamiDb 有新增记录时自动｜来历0912 实测旧公式只会低估、从不高估（NORMAL 最大 −9.52pp，harmony=45 的例子停采线 74.48 低于真清算线 76.49，会漏停）；辅助启动重算约 95s、核心补录约 120s+，辅助每小时重算又常赶不上 45~55 分钟一次的整页刷新，只靠辅助兜底会永久带病｜版本测试版1.2.42
• 刻意不做全库重刷（防反向压低 LT）测试线独有 — 精确重算只作用于本次新增记录，不调用 refreshPreciseLT 重算整个库。用 __newRecs 保存新增记录的对象引用，只遍历它。触发：新增记录重算时｜来历全库重刷时，如果 kami_top_predators 缺失或四桶全空（例如辅助正在强制全网重扫），会回落内置默认档案，把全库 LT 压低，正好是漏停方向；辅助有 __usable 和 6 小时 TTL 闸门挡这一下，核心没有｜版本测试版1.2.42
• 辅助脚本缺失红底告警测试线独有仅观测 — 有新增记录但检测不到辅助的 computePreciseLTForRecord 时，打红底白字警告：这些记录用的是旧公式初值，只会低估，有漏停风险，请确认辅助脚本已启用。typeof 检查不是函数就进这个分支，只告警，不改数据。触发：新增记录重算时检测不到辅助入口｜来历旧公式 NORMAL 最大低估约 9.5pp，停采线会跟着偏低｜版本测试版1.2.42
• 补全结果写回本地存储 — 处理完后先把库挂回 window.kami_core_db，再整体写回 localStorage 持久化，打「完成：新增 x 条（失败占位 y 条），DB 现有 z 条」。setItem 失败（例如配额满）时打「写回 localStorage 失败（内存已更新但下次刷新会丢失）」，本次会话仍可用内存版。触发：syncKamiDb 补全流程末尾｜存储kami_core_db（写）
• 整体异常兜底 — syncKamiDb 任何未预料的异常都会被捕获，打「syncKamiDb 异常」并返回全 0 结果，调用方不需要额外容错。最外层 try/catch，返回 {added:0,total:0,skippedFail:0}；正常时返回 {added, total: 账户 Kami 数, skippedFail}。触发：syncKamiDb 调用时
• 控制台命令 syncKamiDb() — 把 syncKamiDb 暴露到 window，控制台可随时手动执行一次增量补全。控制台输入 syncKamiDb()，返回 Promise<{added,total,skippedFail}>。脚本启动或主循环也会在需要时自动调用（注释称页面加载后约 120s+）。触发：命令；启动/主循环按需调用｜命令syncKamiDb()｜存储kami_core_db

1.17 杂项工具

安装说明、Epoch 提醒、房间映射和几个底层小工具。

安装、更新与说明文档

• 四件套安装指引仅观测 — 四件套（核心/辅助/精简数据库/轻量杀手监控）装齐的步骤、每缺一件的后果，以及 beta 目录的四条 raw 安装链接。要在 Chrome 扩展详情里打开「允许用户脚本」（最容易漏，漏了装上也不跑）。装好后以启动横幅和篡改猴面板里的版本号为准，别拿「[版本检查] 已是最新」当判据：游戏页有 CSP，这行基本不会出现。触发：文档；控制台 安装说明() 可打印｜命令安装说明()｜来历游戏页CSP使脚本fetch不到GitHub，版本检查行基本不出现
• 夜间挂机两项系统设置指引仅观测 — 必做：关掉电脑自动睡眠。可选：关掉 Chrome 对后台页的强节流（IntensiveWakeUpThrottlingEnabled），不关夜里紧急停采会慢1~2分钟，测试版 1.2.59 起脚本按「默认会被节流」设计。Windows 管理员 cmd 用 reg add 写 HKLM Policies（强制级），完全退出 Chrome 再打开后生效。Mac 上 defaults write 写的是「推荐」级，这一项 Chrome 只认强制级，chrome://policy 显示 false 也不生效（2026-09-15 实测，看「级别」列）；要 ⌘Q 完全退出后用 open -na "Google Chrome" --args --disable-background-timer-throttling 重开（同机多开每个实例加原来的 --user-data-dir）。触发：文档（不执行）｜来历2026-09-14实测：窗口被挡或熄屏超5分钟后Chrome把定时器降到每分钟醒一次，紧急停采慢1~2分钟
• 更新与回退说明仅观测 — 更新不用重装，篡改猴会自动拉新版，也可以手动点「检查用户脚本的更新」。回退有两条路：从 Releases 页装历史快照，或请维护者发一版「旧内容+更高版本号」。Releases 快照里的 @downloadURL 仍指向 main。装完必须逐个脚本关掉「检查更新」，否则下个检查周期会被静默升回最新版。触发：文档（不执行）｜命令安装说明()｜来历篡改猴没有自动回退
• 新手术语速查仅观测 — 解释一批术语：清算线LT、停采线、delta、四种状态（RESTING/HARVESTING/STARVING/DEAD）、mETH、musu、Operator、nonce、凑批、步长、幽灵kami、majority/minority、eye-half。normal 模式停采线=LT+3%，封顶80%。v1.1.1 起 LT 是精确清算线，由辅助脚本按官方公式加全网最强杀手档案维护。greedy 模式停采线=5%。启动时自动切到 eye-half 显示模式。触发：文档（不执行）｜参数normal=LT+3%封顶80%；greedy=5%｜版本v1.1.1 起
• 常用控制台命令速查（文件头）仅观测 — 在文件头按「模式与状态 / 停采与部署 / 黑名单与冷却 / XP药水 / 数据库与日志 / Gas统计」分组列出常用命令，完整清单以启动 banner 为准。列出 setKamiMode、getKamiMode、getTxLockStatus、stopCurrentRoom、stopMinorityForTransfer、resumeDeploy、clearBlockedKamis、showBlockedKamis、clearStopBlockedKamis、showStopBlockedKamis、clearFeedFails、clearStarvingStuck、feedXPPotionNow、clearXPPotionFed、showMyKillers、syncKamiDb、saveKamiLogs、showGasRules、showGasReport。触发：文档（不执行）｜命令见 how 中列举
• 安装说明() 命令 — 打印四件套安装链接、配套规则、夜间挂机设置、更新机制、回退办法和完整说明书链接，并显示当前测试版核心版本号。中文命令 安装说明() 与英文别名 showKamiInstall() 指向同一函数；全是硬编码字符串，不能改成 fetch 远端；只读不发 tx。触发：命令｜命令安装说明() / showKamiInstall()｜来历游戏页 SPA 运行时注入 CSP，raw.githubusercontent.com 在游戏页永久拉不到（版本检查就是这么废掉的）
• 测试版与公开版互斥警告 — 橙色提醒：这是测试版，公开版必须在篡改猴里停用。触发：安装说明() 输出｜命令安装说明()｜来历两个核心同时跑=双份交易+抢 nonce
• 四件套缺一不可与安装步骤 — 说明核心/辅助/精简数据库/轻量杀手监控缺一块少一块功能；安装步骤：装 Tampermonkey→打开「允许用户脚本」（最易漏）→点四条 GitHub beta 目录 raw 链接→看到启动横幅即成功，别拿「[版本检查] 已是最新」当判据。文案「缺杀手监控→不会自动切安全停采线」与贪婪模式板块「Feed 监控已停用、自动切换默认不生效」不一致，实际杀手保护是位置轮询触发紧急停采。触发：安装说明() 输出｜命令安装说明()｜来历游戏页 CSP 拦外联，版本检查行基本不会出现
• 夜间挂机设置指引 — ①必做：关闭电脑自动睡眠（Mac 能耗设置/Win 电源永不）；②可选：Chrome 后台页强节流（测试版 1.2.59 起按默认会被节流设计）。Win 给 reg add 命令（强制级）；Mac 说明 defaults write 是推荐级不生效，给 ⌘Q 后 --disable-background-timer-throttling 启动参数（多开加 --user-data-dir）。触发：安装说明() 输出｜命令安装说明()｜来历电脑一睡页面 JS 全停；窗口被挡/熄屏超 5 分钟后定时器每分钟只醒一次，紧急停采会慢 1~2 分钟
• 更新与回退指引 — 更新：@name 固定不带版本号，篡改猴自动拉新版，可在面板手动检查更新；回退：从 GitHub Releases 装历史快照，装完必须逐个关掉「检查更新」否则会被静默升回；或联系维护者发「旧内容+更高 @version」全网秒回滚。篡改猴没有自动回退。触发：安装说明() 输出｜命令安装说明()｜来历快照资产的 @downloadURL 仍指向 main

Epoch 结束提醒

• Epoch结束提醒 — 当前 Epoch 进入最后3天时打红色大字提醒：销毁 VIP 点数（vipp），需要的话投票给 kamigotchi，附投票入口链接，并显示结束时间和剩余小时。Epoch30 起点 2026-06-04 08:00 UTC，每期14天，用 _epochAt/_epochRange 推算当前期号和结束时间。剩余天数向上取整 ≤3 才打印。启动30秒后首查，此后每6小时查一次，异常静默。触发：自动：启动30s + 每6h｜参数__EPOCH_REMIND_DAYS=3；__EPOCH_LENGTH_MS=14天；起点2026-06-04 08:00 UTC｜来历1.2.7删余额差统计时连带误删，grok审查抓出(B1)后恢复（只留提醒，不含旧 showEpochGasStats）｜版本1.2.7

房间映射

• 房间名→房间号静态映射表 — 手工维护约 70 个房间名到 roomIndex 的映射（0 deadzone … 90 Scenic View）。编号跳号（如 7、8、14、17）是游戏本身的缺口不是遗漏；游戏新增房间需手动补充，否则显示 'Unknown'。触发：被部署/停采/救援/日志模块按需查询｜参数ROOM_NAME_TO_INDEX
• __getMyRoomIndex 当前账户房间号 — 取当前连接钱包地址→本地 ECS 按操作地址查账户实体→读 roomIndex。window.network.network.connectedAddress.value_ → explorer.accounts.getByOperator(addr)；无网络请求；全程 try/catch，network 未就绪/未登录等任何异常返回 null，调用方自行处理。触发：被其他模块调用
• __getRoomNameByIndex 房间号反查名 — 遍历映射表按房间号反查房间名，主要用于日志显示。查不到返回 'Unknown'，不抛异常。触发：被日志输出等模块调用

模拟点击与链上查询小工具

• 完整鼠标事件序列模拟点击 — 按真人操作节奏给元素依次派发 mouseover、mousedown、mouseup、click，让游戏按钮真正触发业务逻辑。四个事件分别在 delayMs+50、+150、+200、+300ms 触发，全部 bubbles:true，上层的事件委托监听也能收到。触发：各 UI 操作板块需要点页面按钮时调用｜参数delayMs 默认 0；四步相对间隔 50/150/200/300ms（调太小可能被前端忽略）｜来历游戏前端用 React 合成事件，部分按钮不响应孤立的 click 事件
• 点击后补 mouseout 复位悬停态 — click 后立刻补发一个 mouseout（relatedTarget 指向 document.body），让按钮 hover 样式正常复位。mouseout 设 bubbles:true、cancelable:true，和 click 在同一个定时回调里发出。触发：每次 simulateClick｜来历避免 UI 卡在 hover 态
• 空元素保护与 delayMs 错峰 — 传入元素为空时直接返回、不抛错；需要连续点击多个元素时，可传不同的 delayMs 把事件序列错开。首行判断 !element 就 return；delayMs 是整体时序偏移量。触发：每次 simulateClick｜参数delayMs｜来历避免多个事件序列互相交叠
• 按图鉴编号实时查 kamiId/harvestId — 用 getByIndex 实时查单只 Kami 的链上实体 ID 和当前采集实体 ID，本地库缺记录或 harvestId 缺失、非法时作为回退来源。只开 harvest 选项，查询开销最小。触发：部署/停采流程按需调用
• ID 查询失败返回空值不中断批量 — 查 kamiId/harvestId 时，接口不存在就静默返回双 null；查询抛错就打日志后返回双 null，调用方据此走跳过或重试。接口缺失时不打日志；异常时打「[explorer] index=N 取 Kami/Harvest ID 失败」。触发：_fetchKamiAndHarvestIds 调用时｜来历不中断批量流程
• delay(ms) 等待工具 — 返回一个 ms 毫秒后 resolve 的 Promise，供全脚本 await 等待使用。基于 setTimeout。触发：全脚本调用

二、辅助脚本

辅助脚本是核心的配套，必须和核心同时启用：清算线显示与精确计算、杀手扫描、升级加点、自动合成、启动窗口复活、地块分析和代码健康看板。

2.1 启动、日志与调试

脚本头说明、单实例守卫、日志与版本检查、调试开关。

脚本头与说明

• 篡改猴元数据与注入时机 — 声明脚本名、版本、生效站点和注入时机。脚本只在 kamigotchi.io 各子域运行，等页面空闲后才注入。@name 为「Kamigotchi辅助脚本-测试版-1.2.19」，@version v1.2.19，@match https://*.kamigotchi.io/*，@grant none（跑在页面上下文，可直接读 window.network），@run-at document-idle。头部 SYNC 注释规定：升版本时 @name、@version、banner、启动 log、命令清单 banner 要一起改。触发：篡改猴加载页面时｜来历版本仪式要求多处同步升号，防止各处版本号不一致｜版本测试版1.2.16；版本仪式标签 1.1.20
• 功能总览与跨脚本协作约定（头注释） — 头注释列出本脚本 9 大能力，并写明与核心、精简数据库、杀手监控三个脚本之间通过哪些 window 全局接口互相调用。八项能力：LT 显示增强、自动升级与技能管理、自动合成（步长只认 DOM 读数）、启动窗口复活（与核心共享防重发记录和 revive 锁）、地块适配分析、杀手候选扫描、实时步长接口、精确清算线、自动买松果（测试版 1.2.17 加，1.2.18 起默认开）。协作约定：核心调用本脚本的 getStaminaFromDOM() 和 __getMinorityKamis()；本脚本升级或重置前调用核心的 TX 锁接口（如 hasEmergencyLock），给紧急停采让路；精简数据库脚本提供 window.kami_core_db；杀手监控脚本维护 window.MY_KILLER_KAMIS。本段只是声明，各项实现在后文。触发：文档声明｜来历链上 API 的 stamina.sync 是检查点旧值，不随时间回复，所以步长只能以 DOM 为准
• 自动任务时刻表（头注释） — 写明各自动任务的时间节奏：自动升级在游戏加载完成后执行，之后每 30 分钟一次；自动合成在启动 5 分钟后首检，之后每 30 分钟一次；LT 显示每 5 分钟刷新；自动买松果买满一批后 7 天内不再买、到期后每天查一次（1.2.18）。本范围内只实现了 LT 的 5 分钟兜底定时器，升级和合成的定时实现在后文。触发：文档声明｜参数升级间隔 30min；合成首检 5min、之后 30min；LT 刷新 5min
• 术语速览（新手文档）仅观测 — 给新手解释 TX、TX 双锁、清算线 LT、步长、build、标准技能、Respec、affinity、majority/minority、db-first 等术语。TX 双锁指紧急锁（紧急停采专用，最高优先级）加普通锁（升级、合成、复活互斥），用来防止多个脚本同时发 TX 导致 nonce 冲突。db-first 指先在本地 kami_core_db 内存里筛选，只对少量候选发 API 查询。触发：文档
• 常用控制台命令速查表 — 列出 16 个常用控制台命令及用途（测试版 1.2.17 加 showPineBuy()、startAutoBuyPine()/stopAutoBuyPine()、buyPineNow()）。这些命令大多在后文定义并挂到 window 上，本段只是速查表。compareLT()、setPredatorEquipHeadroom()、setPredatorEquipCapacity() 不在速查表里。触发：文档｜命令upgradekamis()：手动跑一轮升级和技能管理；checkAllKamiSkills()：只查不改，检查技能是否符合标准 build；getRespecPotionCount()：查背包里的洗点药水；kamiAnalyze()：地块适配分析（四色分类）；findKillerCandidates()：在自己号里找适合转杀手的 kami；scanTopPredators()：全网扫描最强杀手；showTopPredators()：查看当前生效档案；refreshPreciseLT()：按档案重算全库清算线；showHealth()：代码健康看板（每 30 分钟自检）；autoCraft()、startAutoCraft()、stopAutoCraft()：合成手动跑、启动、停止；window.__refreshLT()：手动刷新 LT 显示

单实例守卫

• 同页双辅助脚本拦截测试线独有 — 同一页面已有一份辅助脚本（公开版或测试版）在跑时，本份不启动，控制台打一条红底警告，然后整个脚本直接 return。读取 window.__kamiHelperInstance，若存在且带 variant 字段就打警告并 return；否则写入 {variant:'测试版', at: 当前时间}。刷新后 window 被清空，旗子自然消失。警告直接走 console.log，不进日志缓冲区。触发：脚本载入时立即执行｜参数HELPER_VARIANT='测试版'｜存储window.__kamiHelperInstance（跨脚本全局旗子）｜来历测试版和公开版 @name 不同，篡改猴当成两个脚本可同时启用。两份一起跑等于双份升级、合成、复活 tx，还会抢普通锁、争同一份步长和材料，而 __txNormalLock 的 5 分钟超时抢占窗口挡不住这种情况｜版本辅助测试版 1.2.10
• 守卫 fail-open测试线独有 — 只有确实读到旗子才拦截；读或写旗子出任何异常都照常启动。整段包在 try/catch 里，catch 中什么也不做。注释说这只是兜底，测试机上仍应在篡改猴里停用公开版辅助。触发：守卫执行出错时｜来历辅助不跑只是少升级、少合成，比整个脚本挂掉强｜版本辅助测试版 1.2.10

日志输出

• 统一日志函数 log()仅观测 — 全脚本统一的留痕输出：控制台打印带「[辅助脚本][时间]」前缀的日志，同时把一份明文推进与核心脚本共享的日志缓冲区，核心的 saveKamiLogs() 会把两个脚本的日志合并导出。控制台分两行打印：先打前缀行，再原样打内容，保留对象展开能力。存档时字符串去掉 %c，对象用 JSON.stringify。注释写「+8 小时偏移」，代码实际按 TZ_OFFSET_HOURS 的偏移计算，默认跟随浏览器本地时区。另外 log() 存档只删 %c、不跳过配套的 CSS 参数，样式字符串会被当正文写进日志文件（clog 没有这个问题）。触发：脚本内所有需要留痕的输出｜命令saveKamiLogs()（核心脚本提供，导出合并日志）｜存储window.__kamiLogBuffer（跨脚本共享数组）｜来历让核心和辅助的日志能合并导出，方便事后复盘
• 时区设置 TZ_OFFSET_HOURS — 日志时间戳的时区可配置：默认 'auto' 自动跟随浏览器本地时区，也可写死小时数，如 8、-5、5.5。值为 'auto' 时偏移取 -getTimezoneOffset() 分钟，否则取 Number(值) 小时。log、clog、ctable 共用 __TZ_OFFSET_MS。触发：脚本载入时计算一次｜参数TZ_OFFSET_HOURS='auto'｜版本v1.1.3 起
• 共享缓冲区自建兜底 — 哪个脚本先启动就由谁创建日志缓冲区；本脚本发现缓冲区不存在或不是数组时，会自己初始化成空数组。写缓冲区整体包在 try/catch 里，缓冲区不可用只影响存档，控制台照常输出。触发：每次 log() 写缓冲区时｜存储window.__kamiLogBuffer
• 日志对象序列化容错 — 对象序列化失败时（如循环引用）退回 String()，不让日志本身抛错。try { JSON.stringify(a) } catch { String(a) }。触发：log() 参数含对象时
• clog：控制台输出同时入日志仅观测 — 替代直接 console.log：控制台原样输出（%c 彩色不变），另把纯文本副本写进共享缓冲区，多行文本按行拆开逐行入库。每行加「[辅助脚本][时间]」前缀后 push。写缓冲区全程 try 包住，绝不影响主流程。触发：启动命令清单、参数设置回执、调试行等原先直接 console.log 的地方｜存储window.__kamiLogBuffer｜来历用户 0911 定案「我要都走日志，方便事后检查日志」。之前命令清单、设置回执、表格等控制台看得见，保存出的日志文件里一行没有，事后无法复盘｜版本SYNC→内部版[全量输出入日志]
• %c 样式参数剥离（__plainArgs） — 生成纯文本副本时，不仅删掉首参里的 %c，还按 %c 个数跳过后面对应数量的 CSS 字符串参数，避免样式代码混进日志文件。首参统计 %c 个数得到 cssLeft，后续字符串参数先抵扣 cssLeft，其余字符串原样拼接，对象走 JSON.stringify（失败则 String）。触发：clog 调用时｜版本SYNC→内部版[全量输出入日志]
• ctable：表格输出入日志仅观测 — 控制台打表格，同时在缓冲区写一行「（表格 N 行）」，再把每行 JSON 逐行入库。console.table 失败时回退 console.log；传入非数组时包成单元素数组。两段各自 try 包住。触发：被 checkAllKamiSkills 等表格输出调用｜存储window.__kamiLogBuffer｜来历用户 0911 定案全量输出入日志｜版本SYNC→内部版[全量输出入日志]

版本号与版本检查

• 版本号、线名、构建时间三常量收敛测试线独有 — 版本号、线名（测试版）、构建时间统一收敛到 SCRIPT_VERSION、SCRIPT_LINE、SCRIPT_BUILT 三个常量，启动 log、命令 banner、版本检查的 SELF_VERSION 全部引用它们，不会再各改各的。SCRIPT_VERSION='1.2.16'，SCRIPT_LINE='测试版'。触发：脚本载入｜参数SCRIPT_VERSION='1.2.16'；SCRIPT_LINE='测试版'｜来历0913 账户 A 实盘日志里辅助 @version 已是 1.2.10，启动 log 却打公开版 v1.2.8（数据库、监控也各差一版），直接导致误判「beta 没装全」「监控没更新」两次。日志撒谎比没有日志更糟｜版本测试版1.2.11
• 构建时间自报（SCRIPT_BUILT）测试线独有仅观测 — 启动日志括号里显示发布时间：发布器打包时注入真实发布时间（同 @x-release-date，版本没变就沿用旧日期），本地没发布过的显示「(本地未发布)」。占位值为 '(本地未发布)'，注释标注勿手改。看到这个占位值就说明这份不是从 GitHub 装的。触发：启动日志｜参数SCRIPT_BUILT='(本地未发布)'｜来历方便从日志一眼判断安装来源和发布批次｜版本测试版1.2.11
• 醒目启动横幅仅观测 — 启动时打一条绿底白字、16px 加粗的横幅，内容是「✅ Kamigotchi辅助脚本-测试版 v1.2.13（构建时间）已成功启动，等待网页加载完成…」。走 log()，同时进入日志缓冲区。触发：脚本载入｜来历让启动确认一眼可见｜版本1.1.23 启动横幅醒目化
• 启动在线版本检查仅观测 — 启动 8 秒后拉取 GitHub 上测试线的 meta.js，与本机版本比较，告诉用户是否已是最新。URL 带 ?_=时间戳，fetch 用 cache:'no-store'。正则解析 @version 和 @x-release-date。cmpVer 逐段按数字比较（1.2.10>1.2.9）。结果有三种：一致打「✅已是 GitHub 最新（发布于 X；本机安装/更新于 Y）」；本机旧打橙色「⚠️…请到篡改猴面板『实用工具→检查用户脚本更新』拉取」；本机更新打「ℹ️本地开发版」。延迟 8 秒是为了避开启动拥挤。触发：脚本载入后 setTimeout 8s 自动执行一次｜参数延迟 8000ms；META_URL=GitHub beta/kamigotchi-helper-beta.meta.js｜来历内部版没有 GitHub 分发，同步到内部版时可整块跳过｜版本1.1.21 版本检查
• 本机版本首次运行时间记录仅观测 — 记录本机第一次运行某版本的时刻，近似当作篡改猴安装或更新时间，显示在版本检查结果里。键名为 'kami_ver_seen_辅助脚本_' 加版本号；没有值时写入当前时间（zh-CN 格式）。读写 localStorage 出异常时显示「未知」。触发：版本检查 IIFE 执行时｜存储kami_ver_seen_辅助脚本_<版本号>｜来历篡改猴的更新时间无法直接读，只能取首次见到该版本的时刻｜版本1.1.21 版本检查
• 远端版本解析失败跳过仅观测 — meta 文件里解析不出 @version 时（网络或格式异常），打一行 ℹ️ 提示后跳过，不做比较。remoteVer 为空时 log 并 return。触发：版本检查拿到响应后｜版本1.1.21 版本检查
• CSP 外联失败提示 24 小时降噪仅观测 — fetch 失败（绝大多数是游戏页 CSP 拒绝外联 GitHub）时，24 小时内只提示一次「游戏页 CSP 限制外联，属正常，不影响篡改猴自动更新」，并附手动检查路径。读 localStorage 里的上次提示时间，距今 ≥86400000ms 才打并刷新时间戳，否则静默。localStorage 本身出异常时退化为每次都打。代码 8000 那行的注释写「raw 带 CORS *，页面上下文可直接 fetch」，但 catch 里的注释说明游戏页 CSP 会永久拦截，两处注释互相矛盾；代码按失败降噪处理。触发：版本检查 fetch 抛异常时｜参数节流窗口 24h｜存储kami_vercheck_csp_note_辅助脚本｜来历游戏 SPA 运行时注入 CSP meta 的 connect-src 白名单，raw 外联在游戏页永久失败，旧版每次页面加载都打一行，刷屏｜版本1.1.24 版本检查降噪

调试开关

• [调试] 前缀日志统一拦截 — 给 console.log 打补丁：首参是以「[调试]」开头的字符串时，开关关（默认）直接吞掉，开关开时放行。调试语句可以常驻代码，平时不刷屏。用 RAW_LOG 保存原生 console.log；其余输出一律透传。补丁作用于整个页面的 console.log 调用。前缀判断包在 try/catch 里，异常时照常透传。触发：脚本载入时打补丁，此后每次 console.log 都经过它｜参数拦截前缀 '[调试]'｜来历高频调试输出常驻代码，但正常使用不能刷屏
• 调试开关优先级与持久化 — window.__AUX_DEBUG__ 是布尔值时以它为准；否则看 localStorage 的 aux_debug 是否为 '1'，可跨刷新保持。开关只在载入时确定一次，运行中改 localStorage 要刷新才生效。代码读 localStorage 这一步没包 try，浏览器禁站点数据时理论上会抛错并中断后续脚本。触发：脚本载入时｜命令开启：localStorage.setItem('aux_debug','1') 后刷新；关闭：localStorage.removeItem('aux_debug') 后刷新；或载入前设 window.__AUX_DEBUG__=true｜存储aux_debug
• 调试模式开启一次性提示仅观测 — 调试开着时，第一条被放行的调试日志前额外打一句「测试线独有 调试模式已开启（仅此一次提示）」。用 shownOnce 标志保证只提示一次。触发：首条 [调试] 日志放行时
• 调试状态只读查询 — 在 window 上定义只读属性 __AUX_DEBUG_ACTIVE__，随时查看当前是否处于调试模式。Object.defineProperty，只设 getter，返回 !!DEBUG。触发：控制台查询｜命令window.__AUX_DEBUG_ACTIVE__

启动命令清单

• 启动命令清单 banner仅观测 — 脚本启动 3 秒后在控制台打一份带样式的可用命令清单，标题含版本线、版本号和发布时间，并附带各自动任务的时间说明和使用提示。标题「Kamigotchi辅助脚本-版本线 v版本（发布时间）可用命令」。命令包括：checkAllKamiSkills()、upgradekamis()、getRespecPotionCount()、findKillerCandidates()（可自定义阈值如 {vio:25,harm:17,pow:10}；db-first；需配合精简数据库脚本重建 db，老 db 自动降级为全 API 扫描）、scanTopPredators()（6 小时自动重扫）、showTopPredators()/refreshPreciseLT()、compareLT()（传 true 看全量）、showHealth()（每 30 分钟自检）、autoCraft()（步长≥80 合成）、getStaminaFromDOM()、showPineBuy()/startAutoBuyPine()/stopAutoBuyPine()/buyPineNow()（测试版 1.2.17 加，含买入规则与每 7 天一次一行）、window.kami_core_db。提示部分：自动合成启动 5 分钟后首检、之后每 30 分钟；UI 更新每 5 分钟；日志已接入 saveKamiLogs()；grep「技能重置摘要」查 Respec；findKillerCandidates 启动自动跑一次；升级和重置会联动检查 window.MY_KILLER_KAMIS；LT 显示改用 CSS 伪元素，调试用 window.__refreshLT()。只打一次。触发：自动：脚本加载后 3 秒｜参数setTimeout 3000ms｜来历等各模块的启动日志先刷完，让命令清单出现在控制台靠后的位置，更显眼。banner 是写死的字符串，功能变了要人工同步修改｜版本1.1.20 看板白名单三批

2.2 清算线显示与计算

在每张卡片上显示清算线（LT）、危险的标红；按合约官方公式 + 最强杀手档案 + 装备余量算精确清算线。

数据库恢复

• 复用已加载的内存数据库 — 精简数据库脚本先加载时，直接使用它放在内存里的 window.kami_core_db，并打印条数和查看提示。Array.isArray(window.kami_core_db) 为真时打「📦 已检测到已加载的精简数据库，共 N 条」和「🔍 控制台查看」。数据库每条 17 个字段，含清算线 LT。没有数据库时，LT 显示、重置门槛、地块分析、杀手候选扫描都会跳过或降级；日常新增的 kami 由核心脚本的 syncKamiDb() 增量补全。触发：脚本载入时｜命令window.kami_core_db（控制台直接查看）
• 从 localStorage 恢复数据库 — 内存里没有数据库时，从 localStorage 的持久化副本反序列化到内存。JSON.parse(localStorage.kami_core_db，缺省 '[]')，经 Array.isArray 校验：是数组才采用，否则置空数组。触发：脚本载入且内存无数据库时｜存储kami_core_db（读）｜来历数据库建好后持久化，刷新页面无需重跑
• 数据库损坏兜底为空数组 — JSON 损坏等解析异常时打「❌ 读取 kami_core_db 失败」并置空数组，保证后续 find 或遍历不抛错。catch 分支中 window.kami_core_db=[]。触发：解析 localStorage 失败时

卡片 LT 显示与危险标红

• LT 标签与危险标红的 CSS 渲染通道 — 向页面注入一段全局 CSS：带 data-lt-tag 属性的元素在末尾用伪元素显示灰色小字 LT 值；带 data-kami-danger="1" 的元素文字标红。[data-lt-tag]::after 规则：content 为 " " attr(data-lt-tag)，颜色 #7F8C8D !important，margin-left 6px，0.8em，不加粗。[data-kami-danger="1"] 规则：颜色 #E74C3C !important。不往卡片里插 DOM 节点，只写 data 属性。触发：脚本载入时立即执行一次（IIFE）｜参数LT 标签颜色 #7F8C8D；危险色 #E74C3C；间距 6px；字号 0.8em｜来历游戏前端是 React，重渲染会整批删掉脚本插入的子节点，而 data 属性通常不会被清掉。改 attribute 也不会触发 childList 型 MutationObserver，不会和本脚本的 DOM 监听形成「写入→触发→再写入」的反馈循环
• 样式防重复注入 — 用固定 id __aux_lt_style__ 判断是否已注入，已存在就直接返回；document.head 还不存在时挂到根元素上。document.getElementById('__aux_lt_style__') 存在则 return。触发：注入时｜来历脚本被多次执行也安全
• imgNumber 主键提取（getimgNumber） — 从卡片或 img 节点中提取 kami 形象图编号（src 里的 /kami/<数字>.gif），作为和精简数据库对齐记录的主键。节点本身是 IMG 就直接用，否则找内部 src 含 /kami/ 的图；匹配不到返回 null。实现必须和核心脚本保持一致。触发：combinedUIUpdate 处理每张卡片时
• 页面就绪等待（waitForPageReady） — 用 MutationObserver 监听 body 的 DOM 变化，眼睛图标（eye-half）和 party 卡片列表同时出现时视为就绪，再启动 LT 显示。先同步检查一次，已就绪就直接 resolve；否则挂 observer（childList+subtree），满足条件就 disconnect 并 resolve。卡片选择器为 div#party>div>div:nth-of-type(3)>div:nth-of-type(2)>div:nth-of-type(2)>div，依赖站点当前 DOM 层级。触发：脚本载入后｜来历替代每秒轮询，省 CPU
• 就绪等待 60 秒超时强制放行 — 60 秒内等不到就绪条件也强制继续，避免异常页面把流程卡死。超时后 disconnect 并 resolve，照常执行后续。此时如果 #party 还不存在，就不会挂 #party 监听，只剩 5 分钟兜底定时器生效。触发：就绪等待超过 60s｜参数超时 60000ms
• 旧版 DOM 插入方案残留清理 — 启动时删除历史方案插入的 span.__lt_percent__ 节点和 data-lt-inserted 标记，防止视觉重复或 dataset 干扰。有残留时打「🧹 清理旧版残留: X 个 LT span + Y 个 dataset.ltInserted」。querySelectorAll 后逐个 remove 或 delete dataset。触发：页面就绪后执行一次｜来历旧方案往卡片插 span，已被 data 属性加 CSS 方案取代
• 卡片 HP 后显示清算线 LT — 在 party 面板每张 kami 卡片的 HP 文本后，用灰色小字显示该 kami 的清算线，例如「31.25%」。用 imgNumber 在 window.kami_core_db 里查记录，取 LT 字段，格式化成两位小数加 % 写入 hpDiv.dataset.ltTag，由 CSS ::after 渲染。状态图标（src 含 /assets/kami_）的下一个兄弟节点就是 HP 文本。触发：就绪后执行一次、#party 变化防抖、5 分钟兜底、手动 __refreshLT()｜参数小数位 toFixed(2)｜命令window.__refreshLT()｜来历不用 appendChild span，是因为 React 重渲染会删掉脚本插入的节点
• LT 标签值相同不重写 — 写 dataset 前先比对旧值，相同就不写，把属性突变减到最少。只在 hpDiv.dataset.ltTag !== newTag 时写入；危险属性同样先比对再写或删。触发：每次 combinedUIUpdate｜来历大量卡片同屏时不引发突变风暴，也不和 #party 监听形成反馈循环
• 危险 Kami HP 标红 — 采集中且 HP% 低于「清算线 + 2 个百分点」的 kami，HP 文本整体标红；不满足时移除标红。状态图标 src 含 kami_harvesting 才算采集中，休息中的不参与（不会被清算）。满足条件写 data-kami-danger="1"，否则 delete。HP% 或 LT 为 NaN 时不判危险。触发：每次 combinedUIUpdate｜参数安全余量 +2 百分点（killPercent + 2）｜来历+2 是安全余量，宁可早提示。不用 style.color 是因为 inline style 会被 React 重渲染重置
• HP 百分比解析回退 — 从 HP 文本解析百分比：优先匹配带括号的「(xx%)」，找不到再回退匹配裸「xx%」。正则只认整数，/((\d+)%)/ 失败再用 /(\d+)%/，都失败得 NaN。触发：处理每张卡片时
• 单卡容错跳过 — 每张卡片单独 try/catch；imgNumber、HP 节点或数据库记录任一缺失就跳过该卡，不报错也不影响其他卡。缺 imgNumber 或 hpDiv 时 return；查不到记录时 LT 为 NaN，不写标签。记录缺失时不会清除该节点上已有的旧 ltTag。触发：处理每张卡片时
• 清除历史 inline 颜色残留 — 发现 HP 节点上有旧方案写的 style.color，顺手清空，避免和 CSS 规则叠加冲突。if (hpDiv.style.color) hpDiv.style.color=''。触发：处理每张卡片时｜来历旧版用 inline style 标红
• LT 显示健康心跳仅观测 — 每次执行 LT 刷新都记下心跳时间，供代码健康看板检查辅助脚本的定时器层是否还活着。写 window.__kamiHealthBeats['LT显示'] = Date.now()。据后文健康看板，页面存活超过 20 分钟仍无此埋点就报 🔴「辅助脚本自身定时器层疑似半死」。触发：每次 combinedUIUpdate｜命令showHealth()｜存储window.__kamiHealthBeats（跨脚本全局）
• #party 区域变化自动重算（300ms 防抖） — 监听 #party 区域的 DOM 变化（如点眼睛图标切换卡片展开），300ms 防抖后重跑 LT 显示和标红。MutationObserver（childList+subtree）配合 clearTimeout/setTimeout，挂上后打「仅观测 已启动 #party 区域监测」。触发：#party 子树变化｜参数防抖 300ms｜来历卡片被 React 重建后要重新写入属性
• LT 5 分钟兜底定时重跑 — 每 5 分钟无条件重跑一次 LT 显示，覆盖 MutationObserver 漏触发的极端情况。setInterval 内 try/catch，异常时打「⚠️ [LT兜底] 异常」；启动时打「⏰ 已启动 LT 5 分钟兜底定时器」。触发：就绪后每 5 分钟｜参数间隔 5*60*1000ms
• 手动刷新 LT 命令 — 在控制台立即重跑一次 LT 显示和危险标红。window.__refreshLT = combinedUIUpdate。触发：控制台手动｜命令window.__refreshLT()
• 逐卡调试输出仅观测 — 调试模式下逐卡打印检测到的卡片数、imgNumber、HP 原文和解析值、未命中数据库、找不到 HP 节点、单卡异常。全部以「[调试]」开头，走 console.log，由调试总开关拦截，默认不显示，也不进日志缓冲区。触发：每次 combinedUIUpdate（需开调试开关）｜命令localStorage.setItem('aux_debug','1') 后刷新