个微早会汇报 · 第二版 · 10 月 19 日

数据来源：看板接口 weixin-pc-live（口径代码 wecom-chat src/lib/weixin-pc-live.ts，#2221 修正后）；今早公开页取数 07:30–08:00，09:05 重新取了三天合计与逐天逐台，数字没变（客户消息 33、自动回复 6、首触 1、召回已发 191）。「应召回」「当天未召回」是今早按召回规则新算的，没重算（已发数当天固定，应召回由历史送达回推，不随时间变）。

• 添加新人 / 首触：全部是 C 10-16 一位。看板口径是程序读到「好友通过」旁边的具体时间才记通过（10-01 起有意如此，宁可漏记不虚增），所以不等于销售实际加了多少人；销售实际加友数靠看板底部「销售加友登记」，#2227 今早合并后「是否通过」由系统自动回填。
• 首触另有 1 条（C·4a49e7，10-16 19:28）库里有记录但实际红叹号，#2221 后看板不再计入（见 2(5)）。
• 召回已发：「含第 1 轮」；应召回、当天已发只算第 2 轮及以后。148 是人次（同一位连着几天没发，每天都算一次），不能和「召回已发」相减。
• A 三天当天应发 88、实发 14，约 16%；A 10-17 没掉线也只发 7/33，主因是巡检翻不到人（见 2(3)）。
• 今天（10-19）截至 09:15：召回已发 2 条（任务表 sent_at ≥ 10-19 00:00，三台电脑；09:00 开窗前为 0）。

(1) 召回打断正在进行的对话

问题：客户正在聊，或销售已经接手，系统还是按排期发了召回话术。

真实案例（messages 表原文时间，北京时间） —— 已验证

另有 7 条召回发在上次互动后 21–48 小时，属边缘，不算打断。10-16—10-18 三天库里能看到的打断是 0 条；但销售在微信里手打、没被电脑读到的消息不在库里，所以「0」不能证明没打断。检测口径：10-09 00:00 起全部 736 条召回回执（电脑 487 + 安卓 249），逐条查发送前 24/48 小时内同会话有没有客户消息或我方非召回消息；另有 36 条电脑召回是「没读到聊天的盲发」（B 11、C 25），库里无对照，是否打断待核实。

根因（已验证到代码）：召回放行链上没有“这位客户最近一次互动是多久以前”和「是否已转人工」两个判据。读不到聊天时还会按服务端兜底话术照发（windows-recall-service.ts 的 read:fallback 路径）；titleRecallEligibility 原先不读 handed_off_at；电脑端 60 秒空闲判断是整台电脑空闲，不是这位客户空闲（runner.py:4758）。

修复（wecom-chat #2225，服务端，不用装新版）：合并 10-19 08:00:12（commit ffb0ada2）；生产 /api/status 09:03 返回 commit f91b0b9（含它）。规则：同会话最近 24 小时有客户消息、自动回复、首触或销售手打，召回推迟到满 24 小时再发，不取消、不扣次数；stage=handed_off / handed_off_at / handoff_triggered_at 任一非空视为转人工，不派不发；读成功和兜底两条路径都拦，安卓同样；拦下时任务 reason 写 recent_interaction_<24h 或 handed_off。库里没有互动证据时不拦（历史没导入的老客户照旧）。

进度检查（09:15，北京 9 点开窗之后）

• 拦截记录：windows_recall_tasks 里 reason 含 recent_interaction / handed_off 的行 = 0 条。截至此刻 0 次拦截。
• 原因（已验证）：今天的召回才刚开始（开窗 09:00），截至 09:15 共发出 2 条；而且积压的会话本来就不会被这个闸拦住——预检：现在到期未发的 83 个任务对应 83 个会话，其中已转人工 0 个、最近 24 小时库里有互动记录的 0 个（conversations 与 messages 表，09:15 查询）。所以补发这批时 0 拦截是预期，不是闸没生效；闸要等“刚聊完的客户恰好到了召回时间”才会出现第一次真实拦截。
• 反向核（上线后发出的召回，发送前 24 小时内有没有互动、是不是转人工会话）：

• 上线前 4 个案例已写成自动测试（#2225 的单测：AI 刚回完 2 小时 / 销售手打 5 小时 / stage=handed_off / handed_off_at 非空，都应返回不发）；真实拦截的第一次要等有案例触发，待观察。
• 没拦住的：读不到聊天、库里也没有近期互动记录的盲发（三天 36 条）。要等电脑端读屏改好再收紧。
• 验收口径（建议每天跑）：召回发送前 24 小时内同会话有客户或我方非召回消息的条数 = 0；转人工会话召回数 = 0。

(2) 首触记录缺失（最高优先级）

一句话：系统里「缺首触」的会话共 17 个（16 位客户，10-09 起三台电脑、系统认为该由我方先开口的新好友会话 39 个里没有送达首触的）；Jade 10-19 早上在销售电脑上逐个搜索、截图核对：9 个不是好友，6 个是几个月前的老联系人，2 个是同一位真新好友（客户先开口，我们也回了）。没有发现「首触发了但系统没记录」，也没有漏发给真新好友。

分母是 39（22 个首触送达 + 17 个没送达），按会话算 17/39＝43.6%（按人 16/38）。10-15 起 10/12，10-16 起 1/2。这个比例里的 15 个不是真新好友，所以不能读成“43.6% 的新好友没收到首触”。

(2)-1 逐个客户（17 个会话）

A 组：9 个空会话（C，10-15 14:42–15:42 建）—— 系统里：0 条消息、挂「等首触」任务；真实：9 位都不是好友，在 C 的微信里搜不到

证据：

• 库：9 个会话 stage=nurture、messages 0 条、weixin_friend_lifecycle 无行；任务 campaign=list_topic_one_title_v1、attempts=0、claimed_at 空，今早（09:15 回读）9 个任务全部 status=cancelled，reason=not_friend_verified_by_ops_20261019。
• 日志（C，10-15 14:42–15:43，每个会话同形态；以 C·6c3d38 为例）：14:42:28 read_system_notices bubbles=0 notices=0 → first_touch_notice_only … verdict=最新一条不是「刚加上好友」的系统提示 → first_touch_skip → 同一拍 list_walk_customer queued=True；14:42:55 read_chat reason=vl_no_bubbles；14:43:27 recall_presend_new_friend direction=empty_chat 首触那种：不发召回，交给首触；事件 14:43:30 recall_presend_read_failed（detail.reason=invalid_bubble_count）。
• 截图（Jade）：9 位都不是好友。系统给不存在的好友建了会话和任务。为什么会建：待核实（猜测是列表里的占位或搜索残留行被当成客户，缺少证据）。
• 缺口环节（已验证）：端上「召回」和「首触」两条路互相把对方当责任人。召回判「空聊天＝新好友，交首触」（runner.py:5328-5330）；首触要求有「刚加上好友」灰字，没有就判非新好友并 30 天不再探测（first_touch.py:568 NOT_NEW_TTL_SEC）。任务停在 awaiting_first_touch#1，没有人领、没有告警。

B 组：6 位老联系人（C） —— 见 2(5) 的逐位表：5 个「首触已发但红叹号」（系统记成已发），1 个首触自动撤回。

C 组：1 位真新好友（B，两个会话）

真实情况：同一位客户，10-10 20:07 通过好友并主动说「你好，过些天联系你」，销售 10-11 10:12 回「好的呢」。不缺首触，但这段对话系统里一条都没有，还被拆成了两个会话。

证据：Jade 的电脑截图（见公开页第 4 节）；lifecycle 里该人 accepted_at=10-10 20:07；B 10-11 10 时日志里没有任何 first_touch 行（连同小时已确认送达的另一位也没有），B 的 runner 日志 other 目录缺 10-11 —— 日志缺口，无法确认当时读屏做了什么（待核实）。

(2)-2 回答 Jade 的五个问题

(2)-3 补录可行性

(2)-4 一致性校验机制（修复后每天 09:00 自动对账，不一致推卡）

验收：用 C 的 6 位老联系人和 9 个空会话回放，必须全部拦下或报出。

(2)-5 还要核：已送达的首触是不是也发给了老联系人

10-09 起已送达的 22 条首触里，只有 12 条有通过时间（C 的 10 条里只有 1 条有）。另外 10 位没有精确通过时间（C 9、A 1；A 那位只有销售截图补的日期），无法判断是不是几个月前的老联系人。清单见附录 F4。默认：请销售在微信里看这 10 位的添加日期（只看不发）；不核的话按 #2226 新规则往后执行，历史不追。

(3) 历史召回漏发、到期未执行、频次不足

(3)-1 到期未发的任务数：现在 vs 07:40

口径：windows_recall_tasks，status ∈ {pending, needs_review} 且 due_at < 取数时刻；不含 4 条 operator_paused（A 的人工暂停，due=2099）。电脑三台。

变化说明（已验证）：C 少 9 条＝上面 2(2) 的 9 个空会话任务今早被运营改成 cancelled；B 多 1 条＝10-18 晚新建的会话（会话 78137759）今早 09:00:11 生成了新任务（list_target_not_open）；A 没变。C 剩的 8 条是老链路 next_day_unanswered_v1 任务（reason 为空，从未被领；三台现在都走标题链，老链路任务没人领也没人作废，其中 1 条备注含「已签」，是僵尸）。今天开窗以来没有任何一条积压任务发出（发出的召回里，第一条是 B 当天新生成的任务，不是积压；回执见 2(1) 反向核表）。到期天数：A <1天 1、1–3天 3、3–7天 4、7–14天 9、≥14天 2；B <1天 1、3–7天 30、7–14天 3、≥14天 22；C 3–7天 8。

(3)-2 「该发没发」按规则算多少

规则（三台相同，已验证）：每位客户最多 7 轮，两轮之间至少隔 2 个北京自然日，客户回复后等 48 小时，发送时段 09:00–22:00，每台每天最多 50 条、两条之间至少 60 秒；三台都要等巡检在聊天列表里翻到这位客户并认准才会发，服务端不能主动指定客户。

• 07:40 取证：按规则现在该发没发的客户 168 位（A 59 / B 75 / C 34；有的客户系统里根本没建任务，所以比任务数 91 多）；候选 218 位里去掉了“今天 09:00 起才到期、属正常节奏”的约 50 位（A 8、B 41 或 42：两份底稿差 1 位，没追）。分类和名单是 07:40 的快照，没重算（今天到现在没有积压任务发出，唯一变化是 C 的 9 位被作废）。
• 三天人次：148（A 74 / B 66 / C 8，见第 1 节），按第 1 节「当天已发／应召回」：A 每天 10%–21%（3/29～7/33）、B 46%–67%（22/48～43/64）、C 10-16 与 10-18 为 87% 与 76%，10-17 为 0/2。
• 反方向：10-09 起没有出现两条召回间隔小于 2 天的过密触达（规则闸有效）。

(3)-3 按 Jade 的分类：条数与证据（168 位，07:40 快照）

名单与上表对不齐（待核实）：上表是 07:40 按「为什么没发」分的类（⑥ 31、⑦ 34，合计 168）；附录 R6/R7 名单是 07:50 按补发清单重新归的类（⑥ 30、⑦ 36，五类合计 169）。差异集中在 B（⑥ 5 对 6、⑦ 17 对 15）和一位同时被取消又被服务端拦的客户，没有逐位追到。条数以上表为准，附录名单用于找人。

证据案例（每类，已验证；日志行为 A/B/C 运行日志原文，北京时间）

① A·c1a912（第 6 轮）：任务表该客户 5 条 sent，最后一次召回 10-15 09:13；规则 10-17 起可发第 6 轮，现在没有任何 pending 行在等他（09:15 查）。日志 A 10-15 09:11:04 recall_title_verified … poll_now=True（最后一次被巡检点开），10-16 00:00 之后 A 全部日志里 0 次再被认准。→ 逾期 2 个自然日，系统里没有任何一行在等他。

② B·0f5411（第 1 轮）：任务 88b4d81c pending，reason=read_failed#1，attempts=0，due 09-23 12:48（已逾期 26 天，09:15 回读仍 pending）。B 10-15～10-18 日志全量里 0 命中该客户；巡检三天点开 2488 次，1245 次用在 56 位「今天才到期」的人身上、540 次用在已满 7 轮的人身上，第 1 轮待发的 49 位里只点开了 4 位。

③ A·40b28b（第 1 轮）：任务 35253c1e 09-23 创建，reason=live_view_unverified，attempts=36（09:15 回读，due 10-18 21:51）。A 日志 10-16 09:44、10:22、11:17 … 10-18 20:41、21:21 共 10 次 DEFERRED 当前窗口状态未核实 … reason=recall_live_view_unverified；事件表 10-18 18:05–21:21 另有 7 条同码 blocked。服务端对该码走通用失败分支：退避 15/45/120 秒后每 30 分钟重试，无上限（windows-recall-policy.ts:169-173）。→ 一位客户占着 A 的发送机会循环失败 36 次，从未发出。

④ C·37d605（第 1 轮）：10-16 18:22 领取，18:24:20 ALERT send_uncertain … score=2/3 failed_marker=True，18:24:33 customer_unreachable kind=blocked_by_customer，任务 1666ac1e → cancelled(recall_send_failed_marker)；之后 18:40、19:35、19:40、19:57 巡检 list_walk_customer_unreachable … 不登记召回、不首触。→ 客户已拉黑/删除我方，不该补发。另 B 的 6 条 needs_review（recall_send_uncertain 5、enter_rejected 1，最老 09-20 创建，已 10–30 天）无人处理，且超过 48 小时不再提醒（needs-review-reminder.ts:44），同时把对应客户永久挡在召回之外（windows-title-recall.ts:400）。

⑤ A·fb934d（第 6 轮，任务 83bb45d3）：10-17 10:15:18 巡检认准 → 10:16:14 brain_reply_ready → 10:17:22 ALERT send_uncertain score=1/3 receipt_exact=None receipt_visual=None failed_marker=False，任务进 needs_review；Jade 截图核对后 10:43 经 review 路由标 sent。结果：任务表 sent_at=10-17 10:17，messages 无回执（review 路由从不写回执，review/route.ts:32 注释原文 it never inserts a messages receipt）；样板房协议海报也没发出（正文发出、图片没跟上）。同类：B·d18885（任务 b2c075cd，10-16 15:22，正文重复两遍、海报未见）、A·59296a（任务 f8339c02，10-18 17:35）。这 3 条正是回执表（150 条）比 sent 任务（153 条）少的 3 条。

⑥ A·a34e11（第 1 轮）：第 1 轮槽位（会话×anchor×day=1）上有一条 cancelled（manual_cancel_20260927_not_new_friend，任务 dbf0963f，due 09-28 19:53）；10-18 巡检把他点开 7 次，服务端每次回 round_slot_closed（windows-title-recall.ts:409-413），因为领取 RPC 的 ON CONFLICT 只更新 pending 行（supabase/wecom-ddl/20260918165118_windows_title_daily_rounds.sql:75-78）。31 位同族，其中 10 条是 09-27 人工决定取消，不少当时合理，现在要人工逐位判断，不能自动复活。

⑦ A·04d90a / A·f9165c（同一位客户的两个会话）：f9165c 已发第 1 轮（10-12 18:30，任务 9be42e5b），04d90a 没发过、没有任务。巡检点开他时，服务端按「同一人所有会话的已送达」算出该发第 2 轮（windows-title-recall.ts），却用被点开的那个会话 id 去调领取 RPC，而 RPC 要求“该会话名下已送达数 = 轮次−1”（…daily_rounds.sql:52-53），于是恒返回空；日志 waiting_for_claim 10-16～18 共 60 次。「一人多会话」目前 5 位（A2/B2/C1）。另：C 的 30 位第 1 轮客户 10-16～18 点开过 17 位，服务端回 customer_title_invalid 5、customer_owner_unverified 2（备注编号位数不对或没有「地区+六位编号」）。

每类具体客户（每台电脑逾期最久的前 4 位，共 12 位左右；表里的 # 是附录完整名单里的序号）

① 任务没建（22 位）

② 调度没触发（58 位）

③ 执行失败（23 位；C 的 9 位已作废，其余 14 位待处理）

④ 发送失败/不确定（14 条任务，全部在附录 R4）

⑤ 发送成功未记录（3 位，全列）

⑥ 被取消过再领不到（30 位）

⑦ 服务端没放行（36 位）

另有 4 条任务本身已不该再发（备注含状态词、客户已删好友等），建议作废而不是补发（全列）：

(3)-4 频次不足：37 位

口径：对 active persona 内、仍可召回、已发 1–6 轮、最后一次召回后客户没回话的人，规则要求下一轮在「上次送达自然日 + 2」当天 09:00 起可发；到 10-19 为止已超期 ≥ 2 个自然日仍没发下一轮＝频次不足（07:40 取证）。

完整 37 位名单见附录 R9（最久的是 B 五位 09-15/16 发完第 1 轮至今 33–34 天没有第 2 轮）。过去 3 天没有「过密」风险，风险在于补发时一次性把积压放出去。另有 A 62 位 / C 22 位「看起来可召回」的客户属于已退役的旧微信号，当前电脑用另一个号，不在补发范围；他们是否已在新号里重新加好友，缺少证据，待核实。

为什么没补上（日志证据，三天点开次数）：A 点开 1667 次（第 1 轮待发 408 次/19 人、已满 7 轮 322 次/19 人、不在名单 281 次、超期补发只有 141 次/8 人）；B 点开 2488 次（「今天才到期」1245 次/56 人、已满 7 轮 540 次/42 人、超期补发 57 次/3 人、第 1 轮 27 次/4 人）；C 点开 2346 次（其中 1914 次落在 227 个不在召回名单的标题上）。巡检的点开配额大量花在「没任务可领」的人身上，该发的人排不进视野。

(3)-5 补发方案：122 位的状态

> 更正：07:50 的 122 位清单里，C 的最后 9 位（附录 R10 第 114–122 位）就是 2(2) 的 9 个空会话，Jade 已核实不是好友、任务已作废，不补发。实际可补 113 位（A 38、B 68、C 7）。

• 状态：未执行，等 Jade 回「补」。 09:15 回读：三台任务表今天发出的召回里没有任何一条属于这 122 位的补发（今天只有正常新到期的任务发出）。
• 清单：122 位＝A 38（超期 23 + 昨日到期 2 + 第 1 轮 13）、B 68（超期 10 + 昨日到期 14 + 第 1 轮 44）、C 16（超期 1 + 昨日到期 2 + 第 1 轮 13）；完整见附录 R10（含建议发送时刻）。另 49 位今天起正常到期（A 8、B 41），不额外补发，由正常节奏发。
• 已排除：已转人工、已签/勿扰、48 小时内有过对话、被拒收或删好友的客户。不补发、单列：以前被取消过轮次的 30 位、被服务端拦下的 17 位（C 13 位，多为备注编号不合规；这是补发筛选时的口径，只算本来可补发、但会被服务端拦的客户，和上表 ⑦ 不是同一集合）、该作废的 4 条、B 的 6 条「不确定是否发出」——这些要先看聊天记录再定。
• 节奏：与日常召回共用每台每天 50 条上限，补发每台每天另限 A 20 / B 12 / C 20、每小时 ≤4 条，09:40–21:20 均匀铺开、三台错开 5 分钟；先补逾期最久的，第 1 轮最后补；发前再查 48 小时内有没有新对话，有就跳过。A 约 2 天、C 1 天、B 约 6 天补完。
• 还缺什么：服务端现在没法主动指定「先发这位」，只能等巡检翻到。两种做法：① 销售按名单在微信里点开这位客户的聊天（不用打字），程序认出来后自动按规则发，所有闸门照常生效，但占人力；② 做一个「按名单优先翻到」的功能（建议，工作量小）。默认：Jade 不回就不补发；回「补」就先走 ① 的 C（1 天可清完），② 同步开发。

(4) 自动升级后无法自启动

现象：三天里 client-auto-update 共发 11 次 restart_client（wecom_fleet_commands，created_by=client-auto-update，10 次 status=delivered、无 acked_at——端上自杀，设计上不回执；C 10-17 16:20 那次（#6）是 done、有 acked_at），只有 1 次在预期的 10–15 分钟附近回来。

取证方式：wecom_fleet_commands 指令时刻 + 事件表 update_installing/installed + runner 日志相邻两行间隔 ≥240 秒记一次「Winds 进程无日志」（心跳表只有最新态，推不出历史）。已验证：11 次暗区中位 163 分钟，≥180 分钟的 5 次；明确人工恢复证据只有 #8 #9 #10（来自 Jade），其余 8 次靠什么回来缺证据。

不是关机：三台暗区期间微信主进程 pid 不变（A 6580、B 10468、C 31916，日志 window_watch hooked pid=），是我们的程序没被拉起，不是电脑没开（已验证）。

掉线小时数：三台日志无写入合计 63.9 小时（工作时段 9–22 点 31.5 小时：A 9.1 / B 9.7 / C 12.7）；其中 restart_client 直接引起的（含与登录框重叠的段）47.9 小时。另 B 10-18 04:31–约 09:33 微信被踢回登录框，程序在跑、看板显示在线但干不了活（约 4 小时），已单列。

现在的心跳与版本（09:15 重新取，wecom_loop_heartbeats）

• A 的版本在 07:3x 之后变了：事件表 07:53:50 update_installed 1.25.14+8d72b4b（随后 autostart_audit），同时间窗里 wecom_fleet_commands 没有对 A 的 restart_client，所以是有人在现场启动了程序（推测，没有现场证据；日志首行有没有 takeover 痕迹未查）。这也说明“每天到岗双击 start.bat 会顺带装最新版”是目前唯一可靠的升级路径。
• 三台都没装 1.25.16（记录拉起过程）、1.25.18（首触修复，尚未出包）；生产里 restart_launcher_trace 事件全表 0 条。

根因

• 已验证：① 重启指令发出去就算成功，没有任何环节确认新程序起来了（main.py:1183-1229：写 restart_done.json → 起隐藏 PowerShell 延 15 秒 Start-Process start.bat → 本进程 8 秒后 os._exit）；② 1.25.15 及以前，start.bat 之后的接力（run.ps1 → startup_update.py → install.ps1 → 新进程）一律不写文件日志；③ install.ps1 失败路径会弹 MessageBox 等人点（:16-18，无人值守就停在那里）；④ 安装本身不慢（C 10-18 08:26:39→08:27:08，约 28 秒）；⑤ 监控盖不到这条链（wecom-heartbeat/route.ts:1148 只盯 kind=update，不盯 restart_client）。
• 推测、未证实：隐藏 PowerShell 没起来或被拦；启动锁冲突后静默退出；安装器停在弹窗；startup_update.py 超时（上限 240 秒）。成功与失败的分布看不出规律。
• 现场说法核对：B「18 号上午微信未登录」与日志吻合（04:31 被踢回登录框）；C「17 号上午微信未登录」日志对不上（日志里的登录框是 10-16 上午；10-17 上午程序没在写日志，既不能证实也不能否定）。

进度

• 已做：#2216（1.25.16）拉起每步写 state/restart_launcher.log、下次启动上报 restart_launcher_trace，已出包，三台都没装；A、B（10-18 17:2x）和 C（10-19 早）都加入 WECOM_AUTO_UPDATE_EXCLUDE_HOSTS，10-18 11:03 之后 A、B 再没收到 restart_client，C 10-18 21:30 那次是排除前最后一次。
• 没做：根因没落到日志行（1.25.16 没在现场跑过）；restart_client 送达后无心跳不告警；24 小时同标题节流吞掉第二次掉线告警（待核实）；开机自启三台都没证实（C 远程开了两次都被拦：计划任务 Unspecified error、启动文件夹 UnauthorizedAccessException，疑似安全软件；A、B 没试过）。
• 下一步（需要现场）：① 选一台有人在的电脑（默认 C）手动装 1.25.16，再远程重启一次，读 trace 定位卡在哪一步——注意 trace 只写到 start.bat 退出码，安装器那段要 1.25.18 补日志；② 修好后再恢复自动升级，并给“重启后 20 分钟没心跳”加告警；③ C 请销售确认启动文件夹快捷方式放了没有、截图安全软件拦截记录；④ 微信被踢回登录框时程序显示在线但不干活，看板单独标红。

(5) 把老客户当成新好友发送首触

问题：程序判断「是不是新好友」只看聊天窗口里有没有「你已添加了…」「我通过了你的朋友验证请求」这类灰字，没核对灰字上方的日期；几个月前加的好友、后来没聊过，窗口里最新的仍是那行老提示，于是被当新好友发了首触。这 6 位后来都删了我们或开了朋友验证，发出的全被拒收。如果对方没删，客户会在加好友几个月后突然收到一条「新好友欢迎语」。

6 位老联系人（均在 C；证据＝Jade 10-19 在 C 微信上的截图 + 库 + C 运行日志） —— 已验证

证据（日志原行，C，已重新下载对应小时核过）：5 条首触都是 ALERT send_uncertain … failed_marker=True 后接 ALERT customer_unreachable … source=first_touch，再 first_touch_not_sent result=uncertain tag=send_uncertain、first_touch_sent ok=False：

第 6 位（C·624c62）：10-14 18:09:44 first_touch_candidate direction=we_added → 18:09:58 first_touch_not_sent result=deferred tag=identity_unreachable…identity_unreadable → 18:10:02 first_touch_undelivered … retracted=True（15 分钟后重试的结果日志没下，待核实）。

为什么记成已发（已验证到代码）：idle_history.py:2153-2156 elif unknown or maybe_delivered: 把「看不清有没有送达」一律按「可能已送达」记已发且不撤账；服务端 chat/reply/route.ts:3472 recordOpenerSent（交话术时先记 sent）只在端上回报 opener_undelivered（同文件 3484–3497 那段）才撤；同一拍里 customer_unreachable（红叹号/需验证＝确定没送达）已判出，首触路径没用它改判（idle_history.py:2160-2165 只做 halt_today）。副作用：看板「首触」多计。

修复（#2226，10-19 08:29 合并；电脑端版本 1.25.18（#2226 当时记的是 1.25.17，未出包，已并入 1.25.18）；尚未出包） —— 下面第 2、3 点电脑端代码要装 1.25.18 才对电脑生效

1. 添加提示旁的日期分隔条必须读得到且距今 ≤ 3 天（first_touch.py:325 NOTICE_MAX_AGE_SEC = 3 * 86400；超过 → notice_stale；读不到 → notice_date_unverified，skip 且不落 30 天封禁）。
2. 同一屏出现“开启了朋友验证 / 你还不是他朋友 / 被对方拒收”直接判 unreachable，不发（first_touch.py:331 unreachable_notice、:354-356）。
3. send_uncertain 同拍读到 customer_unreachable → 走 first_touch_undelivered 撤账，不记已发（idle_history.py:2143、2159）。
4. 空窗口读不出内容时不再判新好友交首触，按“读屏失败、24 小时后再试”处理，不兜底发、不进 awaiting_first_touch（windows-recall-service.ts 的 EMPTY_CHAT_UNVERIFIED，服务端部分已随部署上线）；「等首触」超 6 小时没人领进心跳主卡黄牌（已上线）。
5. ~~首触只在北京 9:00–22:00 发~~（#2226 原方案，已被推翻）：Jade 10-19 定首触不限时段，凌晨通过也当场发，#2229 已合并把这个时段闸关掉，随 1.25.18 生效。

验收：C 的 6 位回放必须全部不发（第 2 点覆盖 5 位有「开启了朋友验证」的；第 1 点覆盖 e54fd2、c19786 这类只有「你已添加了…」但日期是 5 月 / 8 月的）；认出拒收后记录被撤；夜里首触 0 条。

状态：代码已合并；电脑端 1.25.18 未出包，三台都没装（A/B 1.25.14、C 1.25.15）；装之前这类问题仍可能再发生。历史上 5 条红叹号首触记录未撤（见 (2)-3）。

另有两个发现（和第 2(1) 同族，转人工后客户再开口没人跟进）：A·490f06（编码 闽D**）：10-11 13:25 被管理员设为“由销售人工回复，未经手动恢复不得自动接回”（stage=handed_off，handed_off_at 为空），此后客户在 10-11 13:50–10-15 10:46 又发来 50 条消息，库里我方 0 条；B·2dd3cb（编码 闽D**）：10-11 22:17 设为持续人工接管（handed_off_at 同样为空），此后客户 10-12 09:42–10-18 17:04 又发 17 条，库里我方 0 条。因为 handed_off_at 为空，现有二次提醒（只覆盖 handed_off_at 在 [now-24h, now-4h] 的会话）覆盖不到；#2228 的再开口提醒能覆盖，但开关默认关。销售是否在微信里手打回复过：待核实（销售手打没被电脑读到的话库里没有）。

说明：每张表的 # 顺序和私聊里的「备注名对照表」一致。电脑·会话＝设备字母·会话 id 前 6 位。取数时刻见页首。