宜博 / pixelphone

wechat_reply_watcher.py：纯 ctypes inotify 监听当前账号 EnMicroMsg.db 目录
（SELinux 放行、零轮询），失败退回 stat mtime；解密增量读 message(isSend=0
& msgId>last)→ 分类(私聊/群@我/群引用我/群其它)→ 写 incoming.jsonl 队列。
账号运行时按 MD5("mm"+uin) 自适应，首跑建基线不重放历史。真机验证 inotify
触发读取、多账号切换自适应、解密/分类均通过。含 --selftest/--once/--tail。

配套需求文档 md/wechat-auto-reply-requirements.md 标注环节1 完成。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

纯调研，未做任何实际操作（未关 SIP/未装解密工具），记录目录结构、
密文确认、key_info.db 误判等试错过程，供后续评估是否接入 Mac 端
微信聊天记录作为数据源时参考。

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

- HermesAccessibilityService: 折叠态封面屏(1080×2364)下 A11y 节点 bounds 全 0、
  ACTION_CLICK/SET_TEXT 失效，改用固定坐标 dispatchGesture 全流程（搜索图标 →
  设剪贴板长按粘贴 → 首条结果 → IME 剪贴板候选插入 → 绿色发送按钮），
  删 ~750 行旧反射/节点路径（-749/+74）。
- setup_termux_boot.sh: frida-server 路径挪到 Termux 家目录(~/hermes-wechat/bin)，
  弃用 /data/local/tmp（Termux 路径约定）。
- server/services/wechat/wechat-contacts.{json,md}: 从 EnMicroMsg.db rcontact 导出
  5423 联系人（发送时确定真实 wxid 的权威来源）。
- wechat_plain/scripts/frida-daemon/: Frida 调试脚本（已废弃发送路径，留作参考）。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

记录 2026-06-04 打通的 lifelog 纪要端到端链路与两项优化：

- HERMES_AGENT_PIXEL_SETUP.md 新增 §3「作为 lifelog 纪要后端」：
  开 api_server（API_SERVER_* env，key 与 lifelog 一致）、精简 token
  （platform_toolsets.api_server=[] + skills.platform_disabled → 12,500→399）、
  Magisk service.d 自启（su 在 /system_ext/bin/su 的坑、动态 uid）、端到端验证
- HANDOFF.md §五：第5项 gateway 自启标记完成（service.d，非 Termux:Boot），
  补 token 精简必做项、Kimi provider 配置交叉引用、api_server 出口被掐排错

API key 用占位符，未写真实凭证。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

新增 HERMES_AGENT_PIXEL_SETUP.md，记录从 Mac 经 adb 把 NousResearch
hermes-agent 装到 Pixel Termux 的完整流程及两个坑（bootstrap 过期导致
node openssl 符号缺失需先 apt upgrade；wrapper /usr/bin/env shebang 在
su -c 下失效需改绝对路径），以及 Kimi Coding Plan 的原生配法（kimi-coding
provider + api.kimi.com/coding，运行时自动切 anthropic 协议 + claude-code UA）。

- README.md 目录清单登记新文档 + 补登 PIXEL_CLAUDE_CODE_OAUTH_SETUP.md
- API key 用占位符，未写真实凭证

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

把顶层平铺的脚本按功能归入子目录，并清理可重新生成的产物：

- db-decrypt/: Frida 抓 key + 解密 EnMicroMsg.db（attach↔hunter 同目录依赖保持）
- search/: Web 搜索服务 + 聊天统计生成
- docs/: HANDOFF.md / README_Android.md + notes/（原 md/）
- 删除 *.tar.gz / *.zip 打包产物与 GITEOF，新增 .gitignore
- 新增 README.md 目录索引，同步文档内路径引用

lsposed-wechat-sendmsg / local-testkit / platform-tools / frida-daemon / archive 保持不动。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

问题：目标会话被大量群消息挤出可见 chat list → FSM CHAT_LIST 状态
findChatListRow 找不到 → 直接退搜索 → 搜索 UI 时序脆弱经常卡死。

方案 A（主）：CHAT_LIST 找不到目标时，dispatchGesture 上滑列表
（540,1500→540,600）逐屏 scan，会话一定在列表里只是被挤下去。
- chatListScrolls 计数，上限 MAX_CHATLIST_SCROLLS=6
- 每条消息在 onReceive 重置
- 滚动不计入 transitionCount（用自己的上限防死循环）

方案 C（兜底）：滚到上限还找不到才 performSearch 退搜索。

新增 scrollChatListDown(onCompleted) — 合成上滑手势。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

#1 auto-reply.js: callHermesRunStream 的 res.on('end') 还在调旧的 flush()
   （重构成 flushTextBuf/emit 时漏改），触发 ReferenceError: flush is not defined
   → 之前直接崩 node（被 keepalive 重启打断 run）。改用 flushTextBuf/flushReasoningBuf。
   （上一个 commit 的 unhandledRejection 兜底捕获到了这个真凶）

#2 HermesAccessibilityService @ 选人卡死：
   - 成员名匹配：选人面板节点文本是"昵称: ZZ"等带前缀格式，严格 equals
     匹配不上 → 新增 findMentionMember 做包含匹配 + 向上找 clickable 祖先
   - 找不到成员时 fallback：之前直接 typeFinalContent 但仍停在"选择提醒的人"
     整页/半屏页，找不到 bkk 输入框 → 卡死。改成先 GLOBAL_ACTION_BACK 退出
     选人页回到聊天页，800ms 后再 findInnerEditText + typeFinalContent

实测：宜创群回复曾卡在 HalfScreenTransparentActivity（选择提醒的人），
要 @ 的 ZZ 在面板显示为"昵称: ZZ"，严格匹配失败 + 无退出逻辑 → 卡死。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

旧路径：/v1/chat/completions 同步阻塞拿完整 reply → 一条微信消息。
长 agent loop 用户体验差（"稍等" 之后再无下文）。

新路径：
  1) POST /v1/runs { input, conversation_history, session_id, instructions }
     拿 run_id 立即返回
  2) GET /v1/runs/{run_id}/events SSE 长连接，消费事件：
     - message.delta { delta }  → 累积到 textBuf
     - tool.started             → flush(false): textBuf → onUtterance
     - run.completed { output } → flush(true): 最后一段
     - run.failed/cancelled     → reject

  3) onUtterance 在串行 Promise 队列（sendChain）里跑：
     - idx===0 的 utterance 带 quoteText + atSender（群里 @ 原消息）
     - 后续 idx>0 仅文本，不重复 quote/@
     - 发完后 await sleep(14000 或 9000) 等 A11y 跑完整一轮 chat-list-click
       → quote → @ → type → send，避免下一个 broadcast 打断当前 FSM 状态

handleMessage：
  - 移除旧的 this.replyGenerator + sendTextMessageBroadcast 同步路径
  - 改成 callHermesRunStream(messages, sessionId, onUtterance)
  - state.markReplied 在 run 整体完成后才标记（避免中间步骤已发但失败时重发漏掉）

诊断：增加 [STREAM EV] 日志统计事件类型 + textBuf 长度，
方便诊断"agent loop 跑很久但没 utterance"等情况（实测发现
深度探索时 hermes 几乎只调 tool 不发 text，多步分割效果依赖 LLM 行为）。

keepalive.sh: HERMES_TIMEOUT 180s → 600s，长 agentic run 经常 3-5min。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

症状：群里 @ 后，FSM 循环 CHAT_LIST→click→WRONG_CHAT→BACK 死磕，
最终撞 MAX_STATE_TRANSITIONS=6 cap 放弃。

根因：进群聊页后 obn (id=/obn) 文本是 "宜创AI全员群(60)"（带成员数后缀），
而 broadcast 传的 toUserDisplayName 是 "宜创AI全员群"（从 chatroom.displayname
查的，不带后缀），严格 equals 永远 false → 永远判定 WRONG_CHAT。

修法：classifyState 拿到 obn.text 后用正则剥掉末尾 (数字)，再与目标做
equals 比对。两种格式都接受（带 / 不带后缀都能匹配）。

实测（22:23:00 后）：
  classifyState: obn.text=宜创AI全员群(19) normalized=宜创AI全员群
  FSM[0] state=TARGET_CHAT      ← 一步到位（不再 BACK 死磕）
  Quote bubble matched [5]
  Long-press → 引用 → @ 火星人 → 写文本 → send
  整条 3 秒走完

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

旧代码的 onReceive postDelayed 块里嵌套 if + ad-hoc relaunch 逻辑，
覆盖不到几种边界情形：
- 微信停在非"会话"主 tab（通讯录/发现/我），CLEAR_TASK 不重置 LauncherUI
  内部 fragment，导致 chat list 扫到 0 个 kbq 后只能 fallback 搜索
- 在错误聊天页（用户上次跟别人聊到一半），CLEAR_TASK 也保留 fragment
- 在子页（搜索/创建群/朋友圈等），需要 BACK 才能退出

新实现：状态机
  WeChatState ∈ {TARGET_CHAT, WRONG_CHAT, CHAT_LIST, NO_CHAT_VIEW, OUTSIDE_WECHAT}

  classifyState(root): O(1) 检测 bkk / obn / kbq / pkg.name → 5 状态
  driveStateMachine(n): switch dispatch + postDelayed 递归
    - TARGET_CHAT  → performTypeAndSend (终态)
    - WRONG_CHAT   → GLOBAL_ACTION_BACK → 再 classify
    - CHAT_LIST    → findChatListRow + click cj1 → 再 classify (→ TARGET_CHAT)
    - NO_CHAT_VIEW → 优先 findBottomNavTab("微信") click（Y 最大者），fallback BACK
    - OUTSIDE_WECHAT → startActivity LauncherUI → 再 classify
  MAX_STATE_TRANSITIONS = 6 防死循环

新增辅助：
  findChatListRow(root, name): kbq strict equals → 回溯找 cj1 ancestor
  findBottomNavTab(root, text): findByText + 选 Y 坐标最大的 clickable 祖先
    （区分底部 nav 与标题栏 / 联系人列表里的同名 text）

删除：enterChatViaListOrSearch (被状态机吸收)

实测（从群聊页起步，FSM[0]→[3] 共 8s）：
  FSM[0] state=WRONG_CHAT target=火星人 → BACK
  FSM[1] state=WRONG_CHAT target=火星人 → BACK
  FSM[2] state=CHAT_LIST  target=火星人 → click cj1
  FSM[3] state=TARGET_CHAT target=火星人 → performTypeAndSend ✅

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

#1 HERMES_TIMEOUT 120s → 180s
   Moonshot kimi-k2.6 在 turns=9 长 context 下 LLM call 可达 60s+，
   旧的 2 分钟整体超时偶发不够，导致私聊 / 群聊回复直接 socket hang up。
   keepalive.sh 内联 HERMES_TIMEOUT=180000 启动 node。

#2 keepalive 直起 node，绕过 start-ar.sh
   phone 上某个 claude-run/hermes 会话有 shell snapshot hook，每次
   start-ar.sh 通过 dash 启动时触发它写 /data/local/tmp/hermes-snap-*.sh，
   Permission denied 错误被某种机制注入到 hermes-wechat/*.js 末尾，
   下一次 node 加载就 SyntaxError 起不来。
   修法：keepalive 用 `su -c 'cd X && env... nohup node auto-reply.js & echo $!'`
   直接起 node，不经 dash 包装层。

#3 is_auto_reply_running 的两个 bug
   - 第一版 pgrep -f node.*auto-reply.js: regex 在 su shell cmdline 里
     自匹配（'su -c "..."' 包含 pattern），永远返 true，永远不重启
   - 第二版用 PID 文件 + grep /proc/PID/comm: 但 echo $! 写的是 sh
     wrapper PID（comm=sh），不是 node 子进程 PID，永远返 false → 暴 spawn
   - 终版：ps -ef + grep -E node.auto-reply.js + grep -v sh.-c
     精确匹配 "node auto-reply.js" 实进程（含空格），排除 sh wrapper line。
     pattern 里用 . 占位避开嵌套引号问题（双引号外/单引号内/转义都崩）

实测：keepalive 起 1 次后稳定 45s+，loop tick 不再误重启；
auto-reply.js 单实例（不再 4 个并行）。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

#1 主进入路径改造（用户提议）— A11y 在不在目标聊天页时，
   优先扫主界面 chat list 直接点击进入，而不是走"搜索 → 点结果"。
   理由：搜索 "丁鹏、🍋火星人、火星人" 这种群名会被 WeChat 解读成
   "创建包含这 3 人的新群"建议，clickFirstSearchResult 误点进了
   MMCreateChatroomUI，然后 bkk 不出现，整条发送链路挂掉。

   新流程：
   - HermesAccessibilityService.enterChatViaListOrSearch:
     扫 root 下所有 ID_CHATLIST_NAME (kbq) 节点
     文本严格 equals pendingToUserDisplayName 时
     向上找 ID_CHATLIST_ROW (cj1) clickable 容器并 ACTION_CLICK
     等 2.2s 后检查 bkk 出现就 performTypeAndSend
   - 找不到匹配（chat 不在可见列表 / 不在 LauncherUI）回退到 performSearch
   - 实测：群在 chat list 第一/二行可定位，整段比搜索快 ~3s

#2 @ 选人面板修复
   - auto-reply.js: senderName 是 wxid（"yibooo"），但群 @ 面板显示
     的是昵称（"火星人"），传 wxid 进 picker 永远找不到。改成
     getContactNickname(senderName) 翻译后再传给 broadcast 的 atSender。
   - HermesAccessibilityService.pickMentionMemberAndContinue:
     @ 失败 fallback 时旧 edit 节点引用已过期（IPC backed，600ms
     postDelayed 后失效），SET_TEXT 静默 false 整条发送挂掉。
     fallback 路径重新 getRootInActiveWindow + findInnerEditText
     拿 fresh edit 节点再 type 内容。

实测（msgId 1556 type=57）：
  ChatList scan: 10 kbq names → matched 丁鹏、小火子、火星人、延墨...
  Clicking row → Chat UI loaded
  Quote bubble @小火子 测试一下 → long-press → 引用
  @ mention typing → Clicking @ member: 火星人
  Append "延墨好！欢迎欢迎..." → Clicking send button

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

新增功能：
- HermesAccessibilityService 支持广播 extras quoteText / atSender
- quoteText: 在聊天页找文本含此 substring 的 bkl 气泡 → 长按 → 点「引用」
  菜单项 → 输入回复文本 → 点发送
- atSender: 在输入框先打「@」触发选人面板 → 找匹配成员点击 → 追加回复

实测路径完整跑通（msgId 1409 验证）：
1. 广播触发 A11y service
2. 进入聊天页（"already in correct chat" 或经过搜索）
3. findBubbleByPartialText 在 bkl 列表里倒序匹配
4. dispatchGesture 派发 800ms 合成长按手势（ACTION_LONG_CLICK 在 WeChat
   GestureDetector 实现上不触发菜单，必须用 gesture 派发）
5. 等 1.2s 后用 findClickableByTextAllWindows 搜「引用」 — 关键：菜单在
   popup window 不在 active window，必须遍历 getWindows() 才能找到
6. 点击引用 → 引用 chip 注入到输入框 → 写文本 → 点发送
7. DB 写入的 message 是 type=57 (微信内部引用回复消息类型)

关键依赖（Android AccessibilityService）：
- accessibility_service_config.xml 必须设 canPerformGestures="true"
  否则 dispatchGesture 不回调 onCompleted

群聊路径：
- auto-reply.js handleMessage 在 replyType=group-at/group-quote 时自动
  从触发消息 content 解析 bubbleText 当 quoteText，senderName 当 atSender
- android-wechat-sender.js sendTextMessageBroadcast 接受 options.quoteText
  / options.atSender，拼到 am broadcast --es 参数里

测试覆盖（在 Pixel 实测）：
- ✅ 私聊回归：plain text 路径不影响（msgId 1408）
- ✅ 引用回复：私聊场景已验证（msgId 1409 type=57）
- ⏸ 群聊 + @ 群成员：代码已写完，需要真实群消息触发才能测

APK 已重编 + 用 debug.keystore 签 + adb install -r 升级（A11y 权限保留）。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

#17 群昵称查询：
- android-wechat-tracker-sqlcipher.js:getContactNickname 删掉
  if (wxid.endsWith('@chatroom')) return wxid 的早退分支
- 群（xxxx@chatroom）和私聊都走同一 rcontact 表查询，nickname 就是群名
- A11y 现在可以用群名搜索进入群聊
- 在 Pixel 已部署并重启 auto-reply (PID 18678)

#18 wake-lock + keepalive 重写：
- 通过 am startservice com.termux.service_wake_lock 启用 wake-lock
  （确认 dumpsys power 已持有 'termux:service-wakelock'）
- 重写 keepalive.sh 对齐当前部署：
  - 守护 4 项：wake-lock / A11y service / hermes gateway / auto-reply
  - hermes 走 termux native gateway 而不是 proot-distro Ubuntu（已淘汰）
  - 健康检查端口 8642（不再是 3010）
  - A11y 被关掉时自动 settings put secure 重新启用
- 在 Pixel 已部署到 ~/hermes-wechat/keepalive.sh

#16 残留清理（仅 phone 操作，无 git 文件）：
- pkill -9 frida-server + rm -rf ~/.frida_queue/
- ~/.hermes/auth.json 删掉 credential_pool['kimi-coding'] 老 sk-kimi 条目
  保留 anthropic + kimi-coding-cn

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

通过 DB 实证与 LSPosed 日志对比定位到：

- LSPosed `HermesWeChatModule.sendTextMessageDirect` 在 WeChat 8.0.72 上
  返回 `Send result: true` 后，主线程异步 NetScene 提交触发 NPE 被 swallow，
  消息**不进 message 表**。这是误报。
- Frida daemon 队列方案（`android-wechat-sender-frida.js`）在 Frida 17 +
  微信 8.0.72 上注入会触发反调试，进程崩溃，无法生产使用。
- 实际可用路径是 `HermesAccessibilityService`（lsposed-wechat-sendmsg 模块内）：
  监听同一广播 `com.hermes.wechat.SEND_MSG`，纯 UI 自动化点击微信完成发送。
- A11y service 易被系统关闭（`enabled_accessibility_services = null`），
  这是消息发送失败的最常见根因，docs 中加上启用 / 验证命令。

更新范围：
- CLAUDE.md
- server/services/wechat/README.md, SKILL.md
- server/services/wechat/android-wechat-sender-frida.js（标注废弃）
- wechat_plain/scripts/local-testkit/docs/README.md, HERMES_WECHAT_ARCHITECTURE.md
- wechat_plain/scripts/lsposed-wechat-sendmsg/README.md

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

- HERMES_WECHAT_ARCHITECTURE.md: v2.0 → v3.0, rewrite for Node.js plugin
- README.md: update architecture diagram, file list, API endpoint, env vars
- server/services/wechat/README.md: add sqlcipher tracker + frida sender
- SKILL.md: add Frida daemon and SQLCipher tracker usage
- wechat-auto-reply-status.md: mark SQLCipher + Frida as verified, update plans

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

- auto-reply.js 接入 hermes-agent OpenAI-compatible API (:8642)
- 新增 android-wechat-tracker-sqlcipher.js 替代 LSPosed 日志 tail
- 新增 android-wechat-sender-frida.js 替代 am broadcast 发送
- 更新 keepalive.sh、README、HermesWeChatModule.java
- 添加 .gitignore SQLite 变体规则
- 新增 docs: 息屏发送尝试记录与屏幕自动唤醒方案

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

- auto-reply.js: connect to hermes /api/master/chat for AI reply generation
  - SSE response parsing, session isolation per talker
  - notification watcher (termux-notification-list) for screen-off fallback
  - wechat foreground check + wake before send
- hermes_wechat_daemon.py: prefer hermes API, fallback to direct LLM API
- config.json: add hermes host/port for local API connection
- keepalive.sh: termux-wake-lock + process guardian for hermes + auto-reply
- Move docs into local-testkit/docs/ directory
- .gitignore: exclude server/db/

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Mac side (lemonPCRM):
- Express server with /api/master/chat SSE endpoint
- MasterSession multi-round orchestration
- AgentManager + ToolRegistry
- ClaudeCliProtocol ACP implementation

Pixel side (wechat_plain/scripts/):
- hermes_wechat_daemon.py: standalone daemon
  - SQLCipher DB decryption with WAL checkpoint fix
  - Direct LLM API calls (Kimi/Anthropic/OpenAI)
  - am broadcast to trigger LSPosed send
  - Auto wake WeChat to foreground before poll/send
- lsposed-wechat-sendmsg: LSPosed module
  - sendTextMessageDirect via WeChat internal API
  - u01.r1.a -> builder -> m1.a() full chain
  - Background thread NetScene submission

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>