Decision Log — 2026-08-11-12(11-12日)
2026-08-12 从 decision-log.md 按月份拆分（>40KB 维护规则）——内容与原文一致。索引: decision-log
2026-08-11（晚）: HERDR 备用吸收（长期主义）+ Antigravity CLI 断线问题解法线索 + 文档纯英文规则
Decision: ① HERDR 备用吸收：clone herdrdev/herdr（27k stars，Rust agent 复用器：多 agent 窗格 + 分离后继续运行 + socket API 互通信）+ Hermes skill herdr（备用激活、不部署不占资源）——用户「我喜欢做准备」哲学：未来出现更好/更全面的 Agent 时多一条架构路，不必死守 Hermes + Prime。② Antigravity CLI 断线问题潜在解法：直接控 agy CLI 跑大任务易断线丢任务（长期未解决）；HERDR「分离后 agent 继续运行」= 潜在解法（agy 跑 herdr 窗格 → 分离 → 任意终端重连不丢，未验证）；备选 = 派 Prime 解决。③ 对外文档默认纯英文：WO 等客户文档以英文版为准（ARCH_CHANGES 登记），中文原版留档。
Context: 用户 21:04 分享 HERDR 教程视频（youtu.be/3ZVWhFI5bpw）问产能帮助（顺带问 Antigravity Pro 18 号过期前配额用法）；21:09 明确要求吸收备用——「很难说哪一天会用到…以后可能出了一个更好用的 Agent，更全面的 Agent，到那个时候我们可能又要改整个架构了」。WO 英文版 20:49 验收通过（CJK=0、金额全命中）后确立英文规则。
What changed: D:\hermes\herdr（clone）+ skill D:\hermes\skills\autonomous-ai-agents\herdr\SKILL.md；StarRenovation_WO_A_PulaiFlora_20260811_EN.pdf + StarRenovation_WO_B_Austin_20260811_EN.pdf 交付（WO-HSD-2026-001/002）；ARCH_CHANGES「文档默认纯英文」；Antigravity Pro 8/18 前任务清单建议（SEO P1 30 pSEO 页 + 9 博客加厚）待用户确认。
Related: antigravity-cli MultiAgent_Graph 2026-08-11
2026-08-11（上午）: WhatsApp 方案 B 定版开工（迁移做工号码）+ 历史导出铁律
Decision: ① 方案 B 定版：迁移做工号码 01116880145 接 WhatsApp Cloud API + master app 聊天模块——反转 8/11 凌晨「方案 A（新 SIM）优先」。核心认知：迁移 = 对外号码零变更（网页/Google Ads/名片不动；电话照常接——运营商层与 WhatsApp 无关；顾客 WhatsApp 看到同一号码零感知）；方案 A 反而有信任问题（新号码不公开 → AI 跟进被当诈骗/举报）。唯一代价：手机 WhatsApp App 不能登录该号 → master app 聊天界面替代（webhook → D1 → 聊天界面 + 回复框 + AI 跟进开关 + PWA 推送）。② 历史导出铁律：API 无历史导入能力 → 迁移前必须手机 App 官方 Export chat（含媒体），重点分包商+顾客；❌ 禁 Baileys/web.js（封号风险）。③ 需求全景：还原 WhatsApp 功能（含语音/bank slip 下载）+ Filter（最近/需要/potential/类型/sub supplier）+ 分包商价钱表附属（成本中心）+ AI 跟进 + Hermes 看全部对话（轻量查询 Hermes 秒答 / 大资料分析派 Prime）。
Context: 用户 08:34 担心换号码（网页/广告），assistant 澄清方案 B 零换号后用户 08:41 拍板开工（「可以请开工，这个工作应该还蛮大的」）；08:55 用户问历史聊天能否读 → 诚实答案 API 读不了 → 导出铁律。
What changed: 需求文档 D:\hermes\hsdesign_work\prime_setup\whatsapp_requirements.md（2632B）+ 鉴权前置任务 auth_task.md 已 send 派常驻 agent 5d154ada2977（Prime 队列：地图 → 鉴权 → WhatsApp 底座）；注册行动版改为 01116880145 迁移注册（原 6 步中 Step 0 买 SIM 删除）；Company_Graph WhatsApp 行更新。
Related: Company_Graph 能力升级路线图 2026-08-11
2026-08-11（上午）: 撞期检查铁律 + 盲审隔离机制 + 安全审计大任务
Decision: ① 撞期检查铁律（Mr Lee 9:30 古来 vs Perumal 10:00 量尺撞期教训）：任何「约时间」事件必须先查 ①全部 cron 提醒 ②sozo-todos ③D1 里程碑，冲突立即提醒——已固化进 hsdesign-customer-followup skill。② 盲审隔离：盲审 session 只有程序性 skill 无领域记忆；AGENTS.md 加盲审禁令（禁查 vault 审查/修复/实施记录）+ 标准模板 blind_review_template.md（隔离条款不可删）。③ 全面安全审计大任务：6 大块（master app / 网站 / 本地环境 / 凭据盘点 / 数据备份 / 供应链），Prime 扫描 → 盲审 → 批准 → 修复；优先级最后；每 session 安全基线写入 AGENTS.md。
Context: 08:24 用户发现撞期已发生（昨晚加 Mr Lee 待办时未查日程）——「下次自动提醒我撞期」；08:59 用户质疑盲审有记忆会带偏见（「有偏见的审查会跳过一些漏洞」）→ 发现 AGENTS.md 能力自寻指引可能把盲审带进 vault 历史 = 污染源；09:12 用户提出全面安全检查（零 coding 背景 + 今天已发现 XSS/泄露 token）。
What changed: skill hsdesign-customer-followup 撞期铁律 + cron 633b93f2abfc（8/13 09:00 follow up Mr Lee）；Prime AGENTS.md 盲审禁令 + prime_setup/blind_review_template.md；路线图新增「🛡️ 全面安全审计」+「🦞 Prime 触手扩展（OpenClaw 浏览器/Whisper 语音/Workspace 全量）」+「AGENTS.md 能力自寻指引（7 步）」；hsdesign_work/能力升级路线图.md 已更新。
Related: 能力升级路线图 2026-08-11
2026-08-11（凌晨）: WhatsApp 沟通架构方向定版——不迁号码 + 新 SIM 方案 A 优先 + master app 聊天模块为 B 案
Decision: ① 不迁做工号码（保留手机 Business App 完整掌控）；API 主动跟进挂起；AI 只做前台（内置 AI 被动回复 + 现有 cron 提醒/客户主档跟进日期/季报机制）。② 方案 A 优先：新买 prepaid SIM（RM10-30）专号接 API——做工号码不动、零损失、App 保留；值得先花 10 块试，运营商不让办才走 B。③ 方案 B 后备：做工号码迁移 + master app 聊天模块（webhook → D1 → 聊天界面 → 回复框 → AI 跟进开关 → PWA 推送；Telegram 只收通知不操作——用户否决 Telegram 中转：顾客聊天混进个人助理对话流 = 上下文灾难）。④ 聊天模块设计底线 8 项（媒体收发/文件下载存 Drive/文件发送/按钮交互/wa_handoff 接管/AI 跟进+CRM 记录/PWA 推送）。⑤ 架构审查结论采纳：master app 鉴权必须前置（线上匿名可读，聊天含隐私）+ 媒体 30 天过期需自动归档 + Hermes typing/已读回执零开发。⑥ 未注册/未实施；下一步 = 用户试 SIM（方案 A）+ 状态好时启动 WABA 注册（10-01 前上线最大化免费窗口）。
Context: 23:56 用户连问 5 轮（待办 → 号码迁移代价 → Telegram 监控 → master app 消息视图 → PWA 通知 → 媒体功能），暴露「迁号码 = 失去手机 App + 无法监控聊天」硬伤；Telegram 中转方案被用户直觉否决；00:07 Hermes 深度分析 12 类坑（杀招级：24h 窗口/媒体过期/webhook/鉴权/AI 幻觉乱报价）；00:13 派 Prime 架构审查（用户补充重点：动态缓存/定时备份/数据增长长期稳定性）；00:35 审查完成（23.9KB + Phase1 指南 7.1KB + 模板草稿 4.4KB，Meta 官方文档 + Hermes 91KB 适配器源码双源核实）。
What changed: 报告 master-review/WHATSAPP_ARCH_REVIEW.md + WHATSAPP_PHASE1_SETUP_GUIDE.md + WHATSAPP_TEMPLATES_DRAFT.md（均 D:\hermes\hsdesign_work\prime_setup\master-review\）；8/11 待办 4 条已入 sozo-todos；vault daily/2026-08-11 已记。
Related: 2026-08-11 2026-08-10 Company_Graph 能力升级路线图
2026-08-11（凌晨）: Prime daemon 常驻 + send 随时插队正式启用（PTY TUI = resident worker 机制）
Decision: ① 插队模式正式启用：master-app 域 TUI agent 常驻（deepseek-v4-flash），Hermes 用 prime-agent send <agent> <message> 派活/插队；用户新想法随时 send，当前任务完成后优先处理（“Queued” 礼貌排队不打断当前轮）。② 正确机制：只有 TUI 交互会话（真 PTY）= resident worker 才注册 daemon（list 可见、= send 目标）；json/print/管道 = one-shot 不注册——此前 send 失败根因；需 --daemon-socket 指定 socket。③ 诚实更正：8/10 上午「send 端到端可用」说法过于乐观（盲审 E2E 实际卡死）——8/11 00:34 才是真验证。④ 日常分工不变：Hermes 编排/验收/沉淀 + Prime 执行。
Context: 00:23 用户要求「停所有任务→重启→daemon 常驻」（人类记性差、AI 记得，不想因等待忘记新想法）；00:25 杀旧任务（json 前台，记录全在 JSONL 可恢复）；00:26-00:32 试错（print/json 均不注册 → 读官方 docs daemon 架构 → PTY TUI 方案）；00:32 agent 5d154ada2977 注册成功；00:32-00:34 send 送达 + 长任务中插队 Queued → 完成后立即处理——全流程验证通过；两个被停任务（架构审查/vault 清理）kill 前已完成，重派验证确认。
What changed: daemon 常驻运行中（master-app 域）；新工作流 = 常驻 TUI agent + Hermes send；MultiAgent_Graph 已更新；vault daily/2026-08-11 已记。
Related: MultiAgent_Graph 2026-08-11 2026-08-10
2026-08-11（早）: WhatsApp 注册正式启动 + 地图能力任务派发（路线图 #3 → 执行中）
Decision: ① WhatsApp 注册启动（主人 05:49 下令）：按 6 步行动版执行——Step 0 先买新 prepaid SIM（RM10-30，方案 A，不动做工号码）→ Meta 开发者账号+应用 → WABA 测试模式 → SSM 企业验证 → 号码注册 → 4 凭证交 Hermes 跑 hermes whatsapp-cloud 向导；目标 10-01 前上线最大化免费窗口。② 地图能力落地派发：send 插队派常驻 agent（5d154ada2977）执行，任务文件 prime_setup/map_tools_task.md。
Context: 05:47 用户要全面汇报 → 05:49 下令「地图能力落地吧 + WhatsApp 注册启动应该怎么做」；注册 9 步压缩为 6 步行动版（建议节奏：明天买 SIM、有空一晚 Step 1-3、审核期等 Meta 1-5 天）。
What changed: 地图路线图 #3 状态 排队→⏳ 进行中；WhatsApp 路线图 #4 进入注册执行阶段（Phase 0）；Phase 1 配置清单就绪（4 凭证 → C:\Users\Sozo\.hermes\.env，生产必须 System User 永久 token——临时 token 24h 过期）。IDA PC 06:03 远程关机成功（WinRM shutdown /s /f——裸 /s 返回 status:1 不生效，已记入 winrm-ida-pc）。
Related: 能力升级路线图 2026-08-11 Company_Graph winrm-ida-pc
2026-08-11（午）: 赠送项目成本规则定版（Mr Chen 层板案例）+ 地图能力交付完成
Decision: ① 送客项目只记内部成本、不进卖价/VO——免费赠送 item 入 Item均价表（标注「送 X 免费」），顾客确认消息只列收费项（Mr Chen 案例：层板 ×7 成本 RM245 入行 22，卖价剔除）。② VO 增项流程定版：中文原价清单 → ×1.2 markup = 卖价 → 英文消息发顾客确认 → 确认后出正式 VO（增项 + omission 减项 + 总调整金额，含签名区 PDF）。③ 地图能力（路线图 #3）第一批交付完成：D:\hermes\hsdesign_work\map_tools.py（OSM Nominatim 地理编码 + OSRM 路由 + OSM 瓦片静态图，免费零 key，内置 1.15 req/s 限速 + COMPANY 公司地址常量）——供应商距离估算/顾客家位置标注/看工地路线即日可用。
Context: 11:49-11:51 Mr Chen（Austin HSD00011）VO 增项 4 项成本合计 RM965（①橱头换板+15mm 防水板 420 ②七片层板 245 ③改门 50 ④box up 左边板延伸覆盖橱身 250）；用户先要求 markup 20%（→RM1,158），随即修正「item 2 层板是送他的」→ 卖价只列 3 项 = RM864（504+60+300）。10:35 播报地图任务完成（map_tools.py 14.4KB + MAP_TOOLS_REPORT.md + 3 张实测图 Kulai/Ambience/IKEA）。
What changed: Item均价表行 22 新增（层板 ×7 成本 RM245 送 Mr Chen）；今日待办扩至 7 条（+Lily quotation / Perumal BQ+视频 / Mr Chen aluminium sample+addon）；VO 待顾客确认后出正式件（omission：aluminum 第一项 + 衣橱，等用户给减项价钱）。
Related: 2026-08-11 Company_Graph Quotation_Graph
2026-08-11（下午）: ARCH_CHANGES.md 架构变更日志 + master app git 初始化（协作机制）
Decision: ① ARCH_CHANGES.md 建立（glm5.2_cashflow/glm_return/ARCH_CHANGES.md）：所有架构变更必须登记（谁/何时/改了啥/为什么）——解决「Hermes 紧急修复 → Prime 记忆缺口」（原本 Prime 处理的东西被 Hermes 改了，Prime 不知道）。② Prime 处理 master app 任务前先读变更日志 + 改完必登记（AGENTS.md 规则；通知是加分、日志是保障）。③ master app 初始化 git（本地 repo，不 push 云端也行；部署前自动 commit）——改坏可回滚。④ 验收哲学定版：Hermes 验收所有 Prime 工作（懂原理 = 无黑箱）；紧急微调 Hermes 直修但必须登记。
Context: 13:31-14:12 登录页闪烁 bug 期间 Prime 卡在自己的长任务（glob 递归扫 C:\Users）无法及时响应，Hermes 紧急直修（sw.js v1.1.0 + network-first）→ 用户担心 Prime 用旧知识处理后续 + 不知道改动 → 提出登记机制；14:16 用户问「这类似 git push？记录改动但不占容量」→ 确认 master app 目前无 git repo → 建议初始化。
What changed: ARCH_CHANGES.md 已建（登记鉴权/LoginGate v2/sw.js/密码全记录）；git init 任务派 Prime（队列 4 号位，完成后部署脚本自动 commit）；8/11 鉴权上线 + 登录修复完成并登记。
Related: 2026-08-11 CashflowApp_Graph
2026-08-11（下午）: Prime TUI 常驻防卡铁律（单点阻塞教训）
Decision: ① AGENTS.md 新增防卡铁律：分层超时——网络调用 30s / 普通命令 60s / 明确长任务（build/部署）600s；交互命令一律禁止（不等超时）；禁止递归扫描 Windows 挂载（/mnt/c）；卡住自检。② 完成通知联通方案升级为最高优先（解决「任务完成无事件推送」+ 要求含 turn 级打断/进度上报设计）。③ 任务队列串行重派：警察报价 → quotation 修复+hide → 完成通知 → git → 人生导图修复。
Context: 14:25-14:41 连续三次卡死（昨天零次）：根因 = ① glob.glob('/mnt/c/Users/**', recursive=True) 递归扫几十万文件 ② subprocess 交互命令等 stdin ③ TUI 常驻 = 单点阻塞架构（一个 turn 卡 = 整个 agent + 全队列停；json 前台进程隔离无此问题）。用户质疑 60s 一刀切会误杀正经命令 → 分层超时定版。另发现人生导图 not found（上次 Prime 优化遗留 bug）。
What changed: daemon+TUI 重启（新 agent 9de32a923620，之前 5d154ada2977 → b70c788e989d → 9de32a923620）；watch_prime 桌面 shortcut 修正（旧参数指向 8/10 旧 JSONL）→ 改 live_watch.py .../sessions。
Related: MultiAgent_Graph 2026-08-11
2026-08-11（下午）: Mr Chen VO 顾客确认 RM864 → 完整 PDF 交付 + Quotation hide 功能
Decision: ① Mr Chen（Austin HSD00011）已确认增项 RM864 → 出 quotation + 完整 VO（增项 864 + omission 减项）+ deposit official receipt 同一 PDF；用户授权「出错成本不高，直接出，错了再发」（首次可先文字描述细节确认）。② Quotation hide 功能：报价项加 hidden 标志（D1 持久化），报价表/PDF 生成自动排除——先发水泥+油漆价钱、隐藏 carpentry（后续再加钱）用。③ 清理 split item 造成的重复 quotation（标记待删 → 用户确认后清，不硬删）。
Context: 14:19 用户发现 split item 复制出重复报价 + 需要 hide 功能（「我的 carpentry work 需要建塔才可以加钱，想先给他水泥以及油漆的价钱」）；14:25 用户报告已发 RM864 价钱给 Mr Chen 并获同意。
What changed: Prime 队列任务 2（quotation 修复 + hide 功能，D1 持久化）；警察顾客报价 HSD00001（draft）3 items 已录待填 sqft/价钱；待 VO PDF 交付。
Related: 2026-08-11 Quotation_Graph CashflowApp_Graph
2026-08-11（晚）: 完成通知验收架构——最终定案（Job B 恢复；cron 触发的 LLM 就是「我」）
Decision: ① 恢复 Job B（860cf76120b5 Prime任务验收播报）——17:08 曾暂停（以为违背「不要 cron 提醒」），17:37 用户点破死循环后正式恢复并定案：主会话（事件驱动）无法主动醒来，cron 触发是唯一主动通道，且 cron 触发的 LLM 与主会话同一大脑/记忆/工具——验收自动做、播报自动来，用户回复即 attach 接续主会话。② 最终架构：Job A（每分钟 no_agent 静默检测）→ 验收包落盘 → Job B（每分钟 gate 零成本短路）→ 「我」验收（读报告+线上验证）→ 播报 → 用户回复接续。③ Hermes 固化习惯：每次用户发消息第一件事读验收包。④ 已知缺口待补：LATEST_EVENT.md 主会话直读入口文件不存在（v2 设计未落地）。
Context: 17:08 Prime 交付 COMPLETION_ACCEPTANCE_UPGRADE.md（9.4KB 三层链路设计）；Hermes 暂停 Job B；17:29 用户质问「为什么又不汇报」→ 排查发现检测层全正常（验收包 16:13/16:16/16:27/17:13 全落盘）但主会话没主动读（依赖用户发消息触发）；17:37 用户完整描述死循环逻辑并问「还是只能跟回 cron 方案？」→ 17:38 恢复 Job B + 通知 Prime；17:54 Job B 首条实测播报到达（地图工具落地验收）✅。
What changed: Job B 恢复启用（enabled=true）；COMPLETION_ACCEPTANCE_UPGRADE.md v2 更新；LATEST_EVENT.md 缺口挂起待补；播报链路端到端实测通过。
Related: 2026-08-11 MultiAgent_Graph Company_Graph
2026-08-11（晚）: 三域架构定版（master-app / webwatch / hsdesign）+ Hermes 角色 = 总管非员工
Decision: ① 域分离原则：业务任务必须放业务域——SEO 属业务域 → 新开 hsdesign 域 agent 0a3180746771；三域 = master-app（2f7f464d6913 系统/开发）、webwatch（d27324d52b5b 工具）、hsdesign（0a3180746771 业务）——域独立上下文/记忆，业务连续性；同域不能并发（写坏 JSONL），不同域可并行。② Web APP 一切改动归 webwatch 域（含 toast 任务通知功能评估）。③ Hermes 角色定版（用户 18:10 原话「你是我的总管不是我的小员工」）：Hermes = 看全局/派对活/盯验收/管节奏；不亲自上手改代码、赶 PDF（Prime 执行）；Hermes 可做紧急微调但必须登记 ARCH_CHANGES。④ SEO 任务设计：skill 路径（hsdesign-blog-ai-seo + hsdesign-seo-audit）+ 自主诊断结合 → P0/P1/P2 可执行方案。
Context: 17:46 用户为测试 Prime Web APP 派「AI SEO 优化」大任务 → Hermes 误放 master-app 域 → 17:48 用户质疑「为什么不在 hsdesign 自己的 session」→ 17:49 开第三个域重派；18:08 用户要求 Web APP 执行中 session 置顶 → Hermes 动手改 server.py → 18:09 用户纠正「请你让 prime 帮忙做，我不想要你执行」→ 交接 webwatch 域。
What changed: 三域架构定版（新 agent 0a3180746771 hsdesign 域）；SEO 任务在 hsdesign 域执行中（98+ messages）；Web APP UX 任务（working 置顶 + prime-agent PATH 修复）派 webwatch 域；server.py 留有 FIX(2026-08-11-ux) 初步补丁待 Prime 审查。
Related: MultiAgent_Graph 2026-08-11 Company_Graph
2026-08-11（晚）: Mr Chen 三合一 PDF v2 修复（中文乱码/编号/金额三坑固化）
Decision: ① 中文传输一律用 Python urllib（UTF-8），禁止 curl 传中文——本次 VO 中文乱码根因（curl 在 Windows 终端编码损坏），违反既有铁律的教训实证。② 中文 PDF 打印用 Chrome headless，不用 Edge（Edge 中文字体 fallback 失败 → 乱码）。③ VO 编号 seq 只传序号（route 自动拼前缀 VO-HSD00011-1），传全称会重复。④ 数据缺失顺手补：D1 project.quotationTotal=10620（原 null 导致 Original Contract Sum RM0）。⑤ 修复必须登记 ARCH_CHANGES + 通知 Prime（协作机制落地）。
Context: 17:43-17:46 Hermes 生成三合一 PDF（Quotation QUOAUS0001 RM10,620 + VO RM864 + Deposit Receipt RM2,400）；17:53 重发；18:04 用户发回 PDF 指出问题（「看来 prime agent 的优化也未尝可以直接落地」）→ 18:05-18:07 定位三坑并修复 → v2 生成（4 页，3MB，中文/编号/金额全过）可发顾客。
What changed: MrChen_QUOAUS0001_Full_Package_v2.pdf（D:\hermes\hsdesign_work\）✅；D1 proj_06 quotationTotal 补 10620；ARCH_CHANGES 已登记；omission 2 项金额仍「待确认」（铝工移除 + 衣橱，等用户给价）。
Related: 2026-08-11 CashflowApp_Graph Quotation_Graph
2026-08-11（深夜）: Prime 插队机制 + send 后 30 秒验证铁律
Decision: ① 派任务给 Prime 可中途插入——不必等当前任务完成；Prime 收到全部消息后自己排优先级；特别紧急的在插入时备注「优先处理」。② send 后 30 秒必须验证 working=收到（skill 已更新）——Queued/Sent 状态不代表已执行，曾静默丢任务。
Context: 23:12 用户质问「为什么 Prime 没在执行那个大任务？是不是你忘了我们有插队的功能」→ 排查发现 prime-agent send 消息 Queued 即丢：任务 10 之前 Queued 丢了、任务 3（WO Route）重派 Sent 也丢了两次均未执行；重发 Sent 后 Prime idle 收到立即执行。
What changed: 任务 10 重发成功并完成（11 模板优化）；prime-agent skill 增加 send 后 30 秒验证步骤；任务 3 重新排队。
Related: 2026-08-11 MultiAgent_Graph
2026-08-11（深夜）: PDF 生成一律走系统 route + research-first 模板优化流程
Decision: ① 客户 PDF（VO/WO/报价等）一律用 master app 正式 route 生成，禁止 Prime 手写 HTML 另起炉灶——手写导致 logo 占位符（src=“{logo}“）未替换 + 颜色体系乱（黄色系 C9A84C）；正式 vo route（/api/pdf/vo/[projectId]）本就带 LogoPath 正确 logo + teal + XSS 修复。② 模板优化必须 research-first：先上网研究专业模板 → 差距清单 → 用户拍板 → 才改 v2 → blind 盲审（任务 13 补轮——任务 10 教训：任务文件漏写 research 步骤，Prime 按文件执行导致缺 research 深度）。
Context: 22:37-23:46 用户对 Prime 手写 VO HTML 不满（美感 + 条款吓人）→ 定位到已有 vo route 未用；用户强调「我是室内设计公司，不是大型建筑商，条款要温和」+「有认真做 research 的表格真的不一样」。
What changed: VO route 升级（增减项合一表格/全 teal/删 IMPORTANT/deposit 参数）；11 个 PDF route 模板全面优化部署（Version aa1c3146，旧严厉措辞 0 残留）；任务 13 research 差距流程确立（TEMPLATE_RESEARCH_GAP.md）。
Related: 2026-08-11 CashflowApp_Graph Company_Graph
2026-08-11（深夜）: SSOT 应付账款走系统 + AR/AP 双线文档架构
Decision: ① 财务记录必须走系统（唯一真相源），不手动加——应付账款走现金流系统 D1 的 Supplier + Bill + BillPayment（Buildsmart = BILL-2026-001 同路）。② 文档双线架构：AR 客户侧 = Quotation → VO → Progress Claim → Receipt；AP 分包商侧 = WO 工单 → 进度付款 → 付款记录（WO 是 AP 源头凭证）。③ Star Renovation 应付录入系统：9,250（WO-HSD-2026-001/002），已付 50% = 4,625，余额各 3,145/1,480。
Context: 23:33-23:38 用户问 Star Renovation 两个 carpentry WO 能否整合进应付账款 + 「确保记录到唯一真相源，希望靠系统去加而不是你手动加」。
What changed: 任务 12 派 Prime（系统录入 AP）；Mr Chen 第二笔收款定案 RM 1,542（VO 后结算 6,570 × 60% = 3,942 − 已收 2,400）；任务 11 Progress Claim 出版派发。
Related: 2026-08-11 CashflowApp_Graph Finance_Graph
2026-08-12（早）: 任务归类域铁律 + 通知链路二次缺口（任务 11/12/13 无播报 → 任务 16）
Decision: ① 同性质任务同 session、不同性质分开域（用户 07:28 原话「同性质的东西才放在同一个 session，不同性质的尽量分开，这样才可以并行处理」）——任务 16（通知链路根因诊断）属系统优化 → 应归 system-ops/webwatch 类域，误放 master-app = 塞车（三域架构后 Hermes 第二次犯归类错域）。② 通知链路二次缺口确认：任务 11/12/13 完成均无播报（webapp 可见完成、cron 播报未到）→ 任务 16 诊断中；07:44 system-ops 卡住无通知、无自动修复 → watchdog 自动救治链（8/11 18:30 版）对 system-ops 域未生效，需再次优化。③ 播报问题移交 WhatsApp/prime agent 处理（09:04 用户指示）。
Context: 00:22-07:13 用户发现任务 13 完成无播报并两次追问（「是不是我们的联通通知系统不够完善」）；07:27 用户纠正任务 16 归属；07:44 用户报 system-ops 卡死无自动修复；07:50 Web APP 历史回放/废弃 session 需求提出（08:44 已交付）。
What changed: 任务 16 派发（system-ops 域）；watchdog 救治链优化需求登记；webwatch 域 08:44 交付 v2（历史回放倒序 + hide_after_days=3，pid 121657）。
Related: MultiAgent_Graph 2026-08-12
2026-08-12（早）: 报价单归档防重复计数 + PDF 文件命名自动跟随文档编号
Decision: ① 旧报价单 archive 不硬删——确保不会不小心被计入年度数据汇总（防同一项目双倍价钱/重复计数）；AMB0002 标记[重复-待删除] 用户确认后归档。② PDF 文件命名自动跟随 document 编号（系统级，master app 所有模板）——方便按名字 trace data/file（09:18 用户要求）。③ 报价 item 合并金额必须闭合：Ambience 200+150+750 → 并入 1 项 RM1,100（本钱模式，subcon 让 10% 利润），grandTotal 18,600 不变，账目验证 18,600−6,950（隐藏 carpentry）=11,650。
Context: 08:56 用户问 split item 造成的两个报价单怎么处理（「确保它不会不小心被计算进入我的数据整理里面…总结今年的报价的时候出现重复」）；09:18 用户要求 PDF 自动编号。
What changed: Ambience QUO-AMB0002 3 项合并为 1 项并交付顾客 PDF v2（11,650）；归档规则登记；PDF 自动编号列入模板优化待办。
Related: Company_Graph Quotation_Graph 2026-08-12
2026-08-12（午）: 每日新闻跨天去重规则（同一事件只报一次）
Decision: 新闻播报去重必须跨天：yesterday-news-sourcing skill 加必做步骤——生成前读最近 3 天已报条目，标题相似或关键实体（队伍/比分/人物）重叠 → 跳过；播客 cron（ef4bdca0178f）挂载去重 skill；文字摘要/PPT 同步补。宁可少报不重复。
Context: 用户 10:52 质疑切尔西 vs JDT 3-3 同一事件 8/11、8/12 连报两天（不同文章标题绕过旧「当天标题去重」）——实锤。
What changed: yesterday-news-sourcing skill + 播客 cron 挂载 + 文字摘要 skill；8/13 起生效。
Related: 2026-08-12
2026-08-12（午）: Vault 健康检查机制定案（>40KB 拆分规则 + 每月 cron）
Decision: 共享知识库定期健康检查：任何 md >40KB 必须考虑拆分（先备份 → 拆子文件 → 原文件改索引 → 逐字搬运零改动）；建每月 1 号自动扫描 cron，超标自动提醒/建议。代码工程不做健康检查（按需读、无整库读场景——用户 12:15 确认）。
Context: 用户 10:29 提出「臃肿文件每次读浪费 token；内容质量一样但分散+索引可精准提取」；执行后全量扫描仅 5 个 >40KB。
What changed: decision-log.md（186KB）→ 8 个月份子文件 + 索引（112 条导航）；research_research-paper-writing.md（104KB 单行 JSON 包装异常）→ 解包 + 按阶段拆 4 文件；archive 旧会话（308/124KB）评估保留 + 标记；vault-maintenance skill + 每月 1 号 cron；备份 _backup_vault_split_20260812/；auth.json（API keys）移 D:\hermes\private\。
Related: vault-maintenance decision-log
2026-08-12（午）: Prime Watch 独立品牌身份（PWA 化 + 摄像头 SVG logo）
Decision: Prime Watch（webwatch 实时驾驶舱）PWA 化：manifest + service-worker + Install App 按钮；独立 logo = 简约摄像头 SVG（teal 5E9E9B）——品牌 logo 专属 master APP 不共用；低优先级：页面全部 emoji 换同套 SVG。
Context: 用户 11:07 要求网页版可安装（比 TUI shortcut 舒服）；11:09 先要求品牌 logo，11:10 纠正为独立摄像头 logo（「品牌 logo 是给 master APP 的」）。
What changed: webwatch（8787）PWA 全套上线（manifest start_url 内嵌 token——已知取舍：安装即带鉴权；/api/* 不缓存）；SVG 摄像头图标 192/512 + favicon；WEBWATCH_PWA.md。
Related: MultiAgent_Graph 2026-08-12
2026-08-12（午）: 工程排期分工定案 + 系统级确认提醒机制
Decision: ① 分工：排期规划+录入 = Hermes（领域知识在 skill），新功能开发 = Prime，自动提醒 = Hermes cron。② 系统级提醒：排期条目置入 confirmLeadDays/confirmWith 字段 + master APP dashboard 通知区（打开 app 显示即将/紧急事项）——Prime 开发中。③ Perumal 安装暂定 8/29（顾客旅行 8/20-28，8/31 兜底）；Mr Chen 安装 8/17-18（顾客本地至 8/18，赶不上则回来再装，提前 3-4 天通知）。
Context: 用户 11:25 启动工程排期（「是时候进行了」）；11:44 要求提醒机制系统级化 + 发现 purchase list 消失。
What changed: proj_09（Perumal）排期录入/整合修正（制作 8/12-25、安装 8/29-31、电工合并一次进场、验收 8/31）+ 提醒 8/25 09:00 确认 subcontractor+屋主；proj_06（Mr Chen）排期修正（8/18 前）+ 提醒 8/14 门把手/安装日确认；dashboard 通知区开发任务已派。
Related: Work_Schedule_Graph 2026-08-12
2026-08-12（午）: Purchase List 误删回归教训 + 收款流程系统化
Decision: ① Purchase List 是核心功能——P0 模板优化误删（前端 purchase-list.tsx + 后端 route 全没）→ git 历史恢复（优先）；教训：优化任务必须核对功能清单不误删。② 收款流程系统化：一键收款端点 POST /api/claims/[invoiceId]/receive（自动建 claim invoice → payment → receipt）；Progress Claim 生成时自动落 claim invoice 记录；Receipt route 必须输出真 PDF（application/pdf——当前输出 HTML 导致手机打不开）。
Context: 用户 11:44 发现 purchase list 消失；11:55 Mr Chen 付第二笔 1,656（60% 累计 4,056 达成）→ 11:58 要求收款流程系统化（「系统化会减少人为或不小心的错误」）；11:59 手机打不开 receipt（HTML 冒充 PDF）。
What changed: Mr Chen 收款入账（INV-2026-010-1 + payment 1,656 + Receipt REC-INV20260101-UW425H）；Prime 队列：purchase 恢复 → Progress Claim 链接修复（quotationId 缺失）→ 收款系统化 → receipt 真 PDF。
Related: CashflowApp_Graph 2026-08-12
2026-08-12（下午）: WO Route 部署源目录纪律（只认 glm_return）+ 盲审与实测矛盾教训
Decision: ① 部署源目录铁律：master-app Worker 部署只认 glm_return 目录（含 wo 路由的权威副本）——本次 WO 路由线上 404 根因 = 从无 wo 路由的目录重新部署覆盖了线上（盲审 E5 预警成真）；部署前必须核对目录含目标路由。② WO Route 加固全套（用户 13:48 批准）：从 glm_return 重部署恢复 /api/pdf/wo/ + 防枚举 token（无/错 token → 404）+ supplier 缺失显式标注（不静默回退默认分包商）+ UI 工种选择（盲审 A 项）+ 复测（proj_09 200+6,290 / proj_06 200+2,960 / 无效 404）。③ 安全：WO 公开 + projectId 可枚举暴露分包商成本单价 + Maybank 账号 551539158314——防枚举必做。
Context: 13:34 验收播报显示盲审（BLIND_WO_REVIEW.md 8/8 通过”可上线”）与独立实测矛盾——线上两个 /api/pdf/wo/ URL 均 404（同域其他路由 200）——报告称已部署（git 8d05e5a）但生产 Worker 不可达；13:48 用户「可以进行全部你说的所谓的下一步」。
What changed: 已派 Prime（优先）WO route 全套恢复 + 加固；教训记录：报告/盲审通过 ≠ 线上可用——必须独立 curl 实测验收。
Related: Company_Graph 2026-08-12
2026-08-12（下午）: FileBrowser 选型定案——现成开源优先（不自研）+ 顾客文件展示痛点
Decision: ① 现成工具优先：顾客要快速展示项目文件（手机看照片/PDF）→ 直接用开源 FileBrowser（部署 30 分钟），不从头开发；备选 Google Drive 网页版 / Google Photos 分享相册；PWA 离线缓存（缓存最近 10 天开过的文件）为后续增强，仅常用才做（手机存储有限——只缓存缩略图/小图）。② FileBrowser 上线配置：Tailscale 内网 HTTPS，根目录 D:\hermes\hsdesign_work，默认密码需改。③ 待办：其他目录（D 盘/vault）按需加 + 开机自启未设。
Context: 用户 13:59 提出「大胆想法」（见顾客快速展示文件）——痛点真实；Hermes 客观评论：不必从零开发，有现成工具。14:22 用户确认不需要自己下载安装 → 14:35 部署完成上线。
What changed: FileBrowser v2.63.23 部署上线（https://desktop-f9ksppp.tail1b1993.ts.net/fb，admin/admin123 默认密码）；新 env 笔记 filebrowser；Fleet_Graph Sozo PC 服务登记。
Related: filebrowser Fleet_Graph 2026-08-12
2026-08-12（晚）: 项目编号规则修复——HSD=成交 / HSP=proposal（dealPrefix 自动编号）+ 开档先查编号铁律
Decision: ① 编号规则定版：HSD = 成交项目、HSP = proposal（未成交）——系统编号生成必须按项目状态自动区分（Prime 新增 dealPrefix() 逻辑，部署 e9f4665d）。② 开档铁律：任何新项目开档（建云端文件夹/报价单）前必须查系统项目编号（D1 projectNo）——禁止自己猜（本次教训：先猜 HSP00014 → 系统错标 HSD00013 → 报价单 HSD00001 还与 John 冲突——三方全不一致）。③ 报价单 ↔ 云端文件夹 ↔ 系统编号必须三方一致。
Context: 用户 20:50 要求给警察项目（Mr Marul + Tuan Harizi，Sentral Police）建云端文件夹；建夹时系统显示 HSD00013（Feature Wall），但 20:57 用户指出「HSD 是拿下的项目编号，警察还没拿下应属 HSP 系列」——实锤系统生成编号时没实现 proposal/成交区分（报价单甚至用了已被 John 占用的 HSD00001）。
What changed: 云端文件夹定版 HSP00014 Sentral Police @ Johor Bahru（04-Projects，Quotation + Drawing 完整子结构）；Prime 完成：D1 projectNo/quotationNo → HSP00014（HSD00001 冲突释放）+ dealPrefix() 自动编号 + 重生成 Quotation_HSP00014_Police.pdf（21:12 验收：HSP00014 在、HSD00001 残留 0）；SOP 固化进 skill（开档先查 D1 编号）。
Related: Company_Graph 2026-08-12
2026-08-12（晚）: 外部 Skill 库建立（吸收流程 + 安全筛查）+ Skill Recorder 不引入
Decision: ① 建立外部 skill 库 D:\hermes\skills\external\（+ INDEX.md 清单）：从 GitHub 官方/高星仓库批量吸收可复用 skill——安全筛查铁律：下载前查来源（官方团队/星数合理，排除星数异常可疑仓库）、入库前扫描恶意模式（偷 API key 等）、用前仍读代码。② microsoft/skill-recorder 不引入：MIT 开源但核心 Analyze 依赖 GitHub Copilot CLI 订阅（录屏+语音上云）——免费等效方案 = 用户演示/录屏一次 → Hermes 手写 skill。③ 多平台发布痛点结论：Typefully skill 不覆盖 YouTube/TikTok/小红书——发布主方案不变。
Context: 用户 21:10 发 skill-recorder 链接（想解决多平台发布时视觉能力弱的痛点）；21:19 要求探索 GitHub 实用 skill（担心恶意 skill 内置偷 API 代码）→ 21:25「每一个有用的都吸收」。
What changed: 已入库 22 文件（Anthropic 官方 17：doc-coauthoring/docx/pdf/pptx/xlsx/canvas-design/frontend-design/theme-factory/algorithmic-art/mcp-builder/claude-api/skill-creator/webapp-testing/internal-comms/brand-guidelines/slack-gif-creator + Typefully 官方），安全扫描 0 恶意命中；待下载：trailofbits 安全系列 / Corey Haines 营销系列 / Figma 系列（路径已记录 INDEX）。
Related: external-skills 2026-08-12