宜博 / pixelphone

用户从 Pixel 上的 ~/.hermes/ 拷了一份一次性备份到 Mac 核对内容，读完发现
几条对以后开发有用的事实，补进 CLAUDE.md：

- phoneuse/android_mcp.py 的真实消费方是第三方框架 Hermes Agent
  （Nous Research，非本项目自研），驱动模型是 Kimi；memory_graph.db 确认
  在线持续增长（1020 person/1255 message/518 vector，对比 TASKS.md
  2026-06-16 审计时的 522/1205/510+）。
- Hermes 在 phoneuse 之外长出的 wechat-image-sender skill（2026-06-23
  验证通过）已经解决了 wechat_send.py 没做的"发图片"能力（ACTION_SEND
  Intent + OCR 找联系人，1344x2992 屏幕坐标全程验证），该 skill 早期笔记
  里提过想用 Frida bridge 但因为不在 Termux 里跑而放弃——正是这次新增
  的 frida_inspect_tools.py 解决的链路，以后可以接上看看。
- wechat-group-digest 绑的两个 cron job 截至备份时都因
  hermes-agent 自身的 `env_float` 缺失 bug 报错失败，不是 phoneuse 代码
  问题，但别假设它们在正常工作。
- 备份的 manifest.json 声称有 5 个 skill，实际只备份了 3 个，不是完整镜像。

备份目录本身含真实 API key（.env）和真实微信消息/联系人原文
（memory_graph.db、persona.yaml），加进根 .gitignore 的
/hermes_backup_*/ 规则，确保不会被任何后续 git add -A 带进仓库。

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

frida_call 此前完全不可达（TASKS.md S3-03）：Mac 端没装 frida/frida-tools
pip 包。新建 phoneuse/.venv，锁定 frida==17.9.10 + frida-tools==14.8.0
（与设备上跑的 frida-server 17.9.10 匹配，更新版本的 frida-tools 对 frida
有严格 range 依赖会直接报错），新增 start_frida_bridge.sh 一键
adb reverse + 起桥。

新增 frida_inspect_tools.py：inspect_foreground_intent(package) /
dump_live_bitmaps(package, max_export) 两个通用 MCP 工具，分别用
Java.choose 枚举目标进程里存活的 Activity（按 hasWindowFocus 识别前台）
和 Bitmap（按 allocationByteCount 排序导出最大的 N 张为 base64 PNG）。
不需要逆向任何具体 App，跟 per-app hook（如微信 sendMessage，已被证实
重度混淆卡死过）明确区分开。

已知限制：frida_bridge.py 现有的进程名子串匹配按 frida 报告的人类可读
标签匹配，不是包名，微信类多进程 App 会匹配到无 UI 的子进程导致静默空
结果——两个新工具已对空结果加诊断提示，根因不在本次改动范围。真机端到
端验证因设备从 adb devices 掉线未完成，TASKS.md 按既有审计格式如实标
记为 [!] 阻塞，未来设备在线后用 Settings/Calculator 之类无隐私 App 补测。

CLAUDE.md 补上 phoneuse 子项目说明——2026-06-23 拍平合并进本仓库后一直
没同步进根文档。

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

## 多服务商 & 任务槽（ModelConfig + SettingsScreen）
- 新增 ModelConfig：LlmProvider 注册表（本地/Hermes + 用户自定义远程）+ ModelSlot（VL/EMBED 槽绑定），SettingsScreen 可视化管理
- ChatConfig 加 ChatTargetKind.REMOTE；targets() 动态合并本地+Hermes+用户服务商
- VisionClient / EmbedClient / PhotoVlWorker 统一走 ModelConfig.slotEndpoint 取端点

## Tool Calling & Agentic Loop（LifelogTools + ChatViewModel）
- LifelogTools：6 个本地工具（search_transcripts/persons/photos/timeline/summaries/followups），OpenAI function schema + 端上 Room 执行
- ChatViewModel：agenticLoop 检测 tool_calls → 调 LifelogTools.execute() → tool role 追回 → 多轮直到无 tool call

## 语义搜图 embed 落地（Pixel 设备侧 + 补算）
- 下载 bge-small-zh-v1.5-q8_0.gguf（25MB，512维中文）到 Pixel ~/models/
- llama-swap config.yaml 新增 "embed" 条目（--embedding --pooling mean，ttl 600）
- 补算向量：PhotoDao.withCaptionNoEmbedding/updateCaptionEmbedding + PhotologViewModel.backfillCaptionEmbeddings()
- AlbumTab ProgressHeader 加「🔢 补算语义向量」按钮（有 caption 无 embedding 时显示，带进度）

## 文档
- HANDOFF.md：P0/P1/P2 全部打 ✅，补 v0.9 已完成列表
- CLAUDE.md：v0.8→v0.9，⭐待做项更新为已完成

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

- 主线改为 lifelog-recorder（纯端上 Personal CRM），lemonPCRM(server/frontend/packages) 标已废弃，
  删掉 CLAUDE.md 里所有服务端章节（ACP/Master-Sub-Agent/GraphStore/server 微信链路）
- 加「App 即 Personal CRM：与旧 lemonPCRM 能力对比」+ 6 项差距 + 「Transcript→内部 Person」方向
- HANDOFF §五：存储 TTL/设置页标✅；「回链 lemonPCRM」→「内部 Transcript→Person」；
  新增「端上 CRM 补齐 TODO」P0–P3 清单

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

- 项目表 + 节标题 v0.7→v0.8
- 架构骨架加「相册 tab = 全相册自动索引(Tier-0 人脸/Tier-1 VL + 搜图)」
- vision/ 文件清单更新(PhotoWorker→PhotoFaceWorker/PhotoVlWorker，
  补 PhotoVlState/GalleryScanner/EmbedClient)
- 新增「全相册自动索引/分层管线(v0.8)」段；✅ 列表补 存储 TTL + v0.8；
  剩余摘要换成「语义搜图落地(待配 embed 模型)」

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

- Person 加 realName/resume，档案页可编辑（PersonProfileScreen）；DB 迁移 12→13
- 通讯录池新增手机系统通讯录来源（READ_CONTACTS / ContactsContract，contactRef phone:<id>），
  按手机号/姓名跨源自动合并去重（PersonDao getByPhone/getByExactName/setPhone/updatePhoneInfo/updateProfile）
- PhotologScreen/PhotologViewModel 支持两源池子
- AndroidManifest 加 READ_CONTACTS 权限；同步 CLAUDE.md

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

- UI 从 5-tab 改为底部 4-tab(人物/录音/对话/设置)+录音内 4 子 tab
- 新增 photolog 人脉 CRM 层说明(两人物池/vision 人脸/微信头像锚点)
- 设置页从 TODO 移到已完成；保留未建的存储 TTL/用量/暂停时段

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

更新录音管线描述（3512a84 的架构改动）：
- §一/概述：一句话管线改为「攒块→整块 pyannote 分轮→逐 turn 转写+认人」，标注无实时字幕
- §四 架构链路：RecorderService 攒块 + BlockBuffer/BlockProcessor + Channel 解耦 + 崩溃 listPending；
  补块边界参数（SILENCE_MS=5min / MAX_MS=10min）；标注旧 DiarizationWorker 已删 + WM 10min 上限
- 文件地图：加 BlockBuffer/BlockProcessor/DiarizationEngine；SpeakerClusterer 标 L1/L2
- 接口表：VAD→BlockBuffer→BlockProcessor→DiarizationEngine→逐 turn 入库
- 声纹纠偏 L1 冻结 anchor + L2 多 anchor 重建；阈值默认 0.45
- changelog 加 v0.7；多 anchor 待办标完成；logcat tag 加 BlockBuffer/BlockProcessor
- 版本号 v0.6 → v0.7

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

- CLAUDE.md：版本表 v0.1→v0.6；架构骨架补 SpeakerClusterer 在线聚类、
  5-tab UI、会话级 SummaryWorker、ChatScreen 多端点；新增「本地 LLM 栈」段
  （llama.cpp HEAD + llama-swap 8080 跑 Qwen3.5 2b/4b）；未来计划标注已完成项。
- HANDOFF.md：§一 现状改写；§二 文件清单补 chat/ summary/ SpeakerClusterer/
  HermesClient，AppDatabase 改 v3+迁移；§五 加 v0.6 已完成项；
  新增「§六 本地 LLM 栈」接手要点（部署/接线/thinking 坑/G3 实测速度）。

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

顶层「项目概述」从「lemonPCRM 单项目」改成「3 个互相关联但独立的
子项目（lemonPCRM / wechat_plain / lifelog-recorder）」总览表。

新增「lifelog-recorder」整章（位于「微信集成架构」与「注意事项」
之间），覆盖：

- 项目目标（Pixel 当永远开机的麦克风，0 元 0 网络，下接 lemonPCRM
  人脉图谱当个人记忆库）
- 架构骨架 ASCII 图 + 技术栈摘要（Kotlin 2.1 / Compose / Room /
  sherpa-onnx）
- 组件间数据流接口表 + 外部 HTTP/WS 接口
- 历史沿革 Round 1-3：全云 ASR（讯飞 80 元包根本不存在）/
  whisper.cpp on-device（0.6× 跑不动）/ sherpa-onnx paraformer
  （20-32× realtime 真机实测，选定），含完整 RTF/质量对比表
- 关键坑摘要 6 条（asset mmap SIGSEGV / silero LFS 拦截 /
  线程甜点 4 / AID_INET / keys.properties / 232MB 模型不进仓库）
- 未来计划摘要（详细见 lifelog-recorder/HANDOFF.md §五）
- 与 lemonPCRM 的关系（目前独立，v2 计划打通 GraphStore
  MENTIONED_IN 边）

细节避雷清单、命令速查、Pipeline 详图都不在此重复，全指向
lifelog-recorder/HANDOFF.md。CLAUDE.md 只勒住架构骨架 + 决策来源
便于每次 session 加载时快速建立心智模型。

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>

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>

包含 ACP 协议层、Agent 运行时、Express API 服务端、
编排引擎及进程管理等完整实现。

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