Decision Log — 2026-08-01-05(1-5日)

2026-08-12 从 decision-log.md 按月份拆分（>40KB 维护规则）——内容与原文一致。索引: decision-log

2026-08-05（深夜）: 发票 logo 破图修复 + 新需求落地 — 相对路径改绝对 URL

Decision: ① PDF logo 一律用绝对 URL（https://hsd-cashflow.ida-czia.workers.dev/logo.png），不再用相对路径 /logo.png ——本地 Chrome headless 打印 file:// HTML 时相对路径解析成 file:/// 导致破图；invoice/quotation/bill 三个 PDF route 统一加 logoUrl helper。② 中国顾客签名栏 IC 标签：身份证号码 (IC) / 护照号码 (Passport) 双写（高先生可填身份证或护照）。③ 应付账款首笔 Bill：Buildsmart Construction (Albert) RM11,516.25（Chai Fun Lip Skudai Indah 电气分包）= BILL-2026-001，供应商档案新建成。④ 多分店商业客户：一个 customer 挂多个 project（Paradigm The Bag Shop 只是 Vincent 一间分店），未来新店直接挂同一客户。

Context: 用户发现高先生发票左上角 logo 破图（quotation 正常）；排查发现两个 route 代码相同，真正差异是打印环境（file:// vs 在线）；fitz 检查 PDF 图片 xref=7 是 14x16 破图占位符而非 logo（此前误判「2 张图=logo+签名」）。同时用户报 3 则新需求（enbei 付 600 / Vincent 设计发票 / Buildsmart 欠款）+ 问中国顾客 IC 写法。

What changed: 部署 bf6a4870；INV-2026-005 收 RM600 余额 1,685；INV-2026-009（Vincent RM2,700 英文 12 items 专业描述）；BILL-2026-001（RM11,516.25 unpaid）；高先生/ Vincent PDF 重新生成交付。

Related: Finance_Graph 2026-08-05

2026-08-05（晚）: 对账机制定案 — master app 应收/应付建模 + Bukku 数据源判读

Decision: ① 应收建模：每笔历史欠款建一张 master app Invoice（billTo + amount + remark），invoices 列表即应收看板；应付建模：供应商欠款逐笔录成 Bill（用户口头报，系统此前 0 数据）。② 对账数据源：Bukku Statement of Account（PG1/PG2）+ all_invoices.pdf + Maybank 流水三源交叉；PG 应收 ↔ 银行实收差额 = 真欠款（已验证 Afiq 等能对上）。③ Jeffley RM1,860 判坏账（多次无回复，不追）。④ Invoice PDF 升级：签名区 + 中文自动渲染（检测 billTo 含中文 → Noto Sans SC 模板）+ 改图限两次 T&C（高先生要求）。

Context: 用户 18:57 提出「想知道顾客欠我多少 + 我欠供应商多少」，用 Bukku 导出 PDF（PG1/PG2 29 账户 58 交易 + 30 张发票 + Maybank 7 个月 301 笔）做首轮理解；用户逐笔口头修正 13 户余额 → 最终应收 7 户 RM25,645（可回收 23,785 + 坏账 1,860）；最大客户 Chai Fun Lip 欠 RM15,000（新年 5k + 2027-06-30 还 10k）；52 个联系人含 8 个 CS 类（既顾客又供应商）。

What changed: 7 张应收发票 INV-2026-002~008 已导入 master app；高先生发票 INV-2026-001（中文 + 签名，RM1,400，50% 定金 RM700）已生成并交付 PDF；归档 reconciliation_archive.json/.md + vault Finance_Reconciliation_2026-08-05.md。

2026-08-05（晚）: life-map v6.1 PWA 收尾 — 禁用 SW + 关动画换稳定

Decision: ① 禁用 service worker 注册（sw.js 实际 404，单文件应用不需要离线缓存，SW 反而是风险源）；manifest start_url 改绝对路径 + scope + id（修 PWA 安装后 “not found”）。② markmap duration: 0 关闭节点动画——消除左侧镜像子树「刷新时往左跑产生空段」+ 节点圆圈 hover 闪烁（r:0→6 反复过渡），代价是折叠/展开失去平滑过渡（可接受）。③ 移动端 topbar 修复：search-box 从 width:100% 改 flex:1（此前反复复发的月亮/齿轮按钮出界真根因）。④ 删除 index.html 第 14 行损坏 favicon 后的游离 SVG（<rect><path></svg> 被当裸文本渲染成左上角 ”>”）。

Context: 用户 18:25 报告 PWA 安装后 not found + 月亮按钮出界复发；此前的 overflow-x 修复是治标不治本；”>” 排查多轮（远程浏览器/Breadcrumb/伪影猜想）最终靠字节级源码搜索定位。用户拍板：动画不重要，待办同步才重要（已验证同步正常，cron 脚本升级为 D1 云端版）。

What changed: life-map 部署 v6.1 + PWA 横幅上线（beforeinstallprompt，仿 master）；待办同步脚本 sync_lifemap_todos_cron.py 指向 v61 D1 版（job 233832d10c8d）；遗留 2 个 error cron（18452f343ff1 改图明浩、dc82e5d8edb4 语音缓存）。

Related: LifeMap_Graph 2026-08-05

2026-08-05（凌晨）: 个人语音学习闭环方案（不做 IME；Telegram 语音 + Gemini 转录 + 个人词库迭代）

Decision: 不做自制输入法（IME 是 Android 最难系统组件之一，3-5 周业余工作量，不值得）。方案：用户直接发 Telegram 语音 → Hermes 用 Gemini 3.6 flash 转录（马来西亚华语混杂/语气词/粗口全保留）→ 用户只在错时纠正 → 个人表达词库自动迭代。识别层用 EXTRA_HINTS / 个性化上下文注入解决词汇层 80%（不训练模型）；「腔调」实为语码混杂问题，系统 STT 已适配音色。语音存本地 D:\hermes\audio_cache（定期清理），转录存文本日志（永久可搜索）。

Context: 用户想要「越来越懂我」的语音转文字——微信输入法发来的是他精修过的「成品」，Hermes 需要的是「原矿石」（原始语音 + 纠正 = 训练闭环）；用户明确不强求，理性探讨后 00:06 主动发首条语音验证。

What changed: 首条语音（2:38）转录成功几乎零错字，模式可行；用户偏好记录：说话不刻意专业、会带粗口（「屌」「干」「妈的」）不介意。

Related: 2026-08-05 2026-08-04

2026-08-04（晚）: 报价数据源正式迁移 master APP（弃 Sheets 报价）+ GLM 分工限定

Decision: 以后报价全部在 master APP 生成（数据唯一源 = 云端 D1），不再使用 Google Sheets 报价单。协作机制：用户微调后 Telegram 说一声（如「我改了 HSP00001 报价单加了矮灯」）→ Hermes 读数据库同步认知（app 自带 updatedAt，无需专门痕迹系统）。GLM5.2 分工限定 UI/视觉（work schedule 精美版适配 HS Design 风格）；报价同步与后期微调由 Hermes 负责。

Context: 用户验收 master APP 发现旧报价单未同步（独立 Sheets 格式与 app 报价模型不同）；拍板 master APP 为唯一报价出口；报价同步只是提取/输入数据，不需要 GLM 参与（但可问架构注意事项）。

What changed: 4 份报价单 + 67 items 导入 D1 并线上验证——QUO-AMB0001 Ms Ong RM10,065 / QUO-0000 Perumal RM400（真实状态：subcon 报价中）/ QUOAUS0001 Mr Chen RM6,900 / QUOJJRM0001 Vincent RM532,754 (lost)。

Related: CashflowApp_Graph 2026-08-04

2026-08-04（晚）: 纯提醒 cron 全改脚本直发（no_agent），AI 只留知识类任务

Decision: 纯提醒类 cron（文本提前写好、不需要推理）一律用 no_agent 脚本直发模式（到点直接发文字，不经过 LLM）——永不超时、永不失败、零 token；需要智商的（Obsidian 知识沉淀/新闻播报/SEO 检查）保留 AI 模式。8 个纯提醒已全部改造，原则写入 Hermes 记忆（以后建提醒默认遵守）。

Context: 23:00「发图给明浩」提醒 cron 失败——DeepSeek API 600s 未响应 + fallback 链为空（用户 8/4 下午拍板「只留 flash，报错就等」清空 fallback）→ 无备用模型可切换 → 提醒没发出（人工补救，用户 23:21 已发图给明浩）。用户拍板分类原则：纯提醒根本不需要 AI。

What changed: KK / Jian Wei / 高先生×2 + 远期 Fiona（8/8）/ Google AI 订阅（8/16）/ 巴西古当拿锁匙（8/31 + 9/1）共 8 个提醒全部改为脚本直发。

Related: 2026-08-04

2026-08-04（傍晚）: 永久保持 max 模式（adaptive skill 不重启）— 性价比决策

Decision: 永久保持 reasoning_effort: max，adaptive 模型强度 skill 不重启；同时钉死配置防止被自动改回 high（元凶是 agent.reasoning_overrides.deepseek-v4-flash = high 会盖掉 max → 已改 max；model.options.reasoning_effort / agent.reasoning_effort 全部 max）。

Context: 用户 16:45 担心「max 模式会被背后插件自动变回 high」；18:03 发现 max 模式下 token 损耗非常少（DeepSeek V4 flash 0731 评测分大幅超过 GLM5.2、逼近 opus 4.8，且便宜）→ 用户拍板「一直保持 max，adaptive skill 不用重启」。

What changed: Hermes config 三处 reasoning_effort/reasoning_overrides 全部 = max 并验证生效；以后不再自动降档。master app 大任务继续用 max 完成。

Related: 2026-08-04 cashflow-system

2026-08-04（傍晚）: hsd-system v2 定版 + Cloudflare Worker 部署完成（含三大坑）

Decision: 以 GLM5.2 改好的 hsd-system-v2 替换 v1 为主版本（含 Bills 应付账款 + 独立发票 + PDF 修复 + 完整 Prisma 适配），部署目标从 Pages 改为 直接部署 Worker（opennext 产物即 worker.js，官方推荐）；部署链路定版：opennext 1.17.3 + esbuild 0.21.5（修 Invalid alias name）+ Prisma driverAdapters/WASM 无引擎模式 + serverExternalPackages: ["@prisma/client", ".prisma/client"] + wrangler.json 配 assets（修空白页）。

Context: 用户 15:29 提议让 GLM5.2 帮忙做 Cloudflare 适配（Hermes 已改得很辛苦、卡 Prisma 坑）；GLM 16:26 交付 v2（220 条目）并完美实现三个需求（Cloudflare 适配 / PDF 排版修复 / 独立 invoice）+ 15:14 的 AP 应付模块（netCashFlow = bankBalance + AR − AP）；API 500 卡 1 小时（17:00–18:00）最终根因 = getCloudflareContext({async:true}) 返回 Promise 未 await → env 永远 undefined → fallback 本地分支崩溃（Prisma wasm/fs 是假嫌疑，GitHub issue #139 / __PRISMA_BINARY 注入均无效）。

What changed: 线上成功：https://hsd-cashflow.ida-czia.workers.dev 首页 200 + Items/Dashboard API 正常；真实数据导入 D1（65 queries / 166 行：27 客户 + 18 项目 + 20 item，18:15 验证）；部署流程脚本化（fix_prisma_worker.mjs 等）；db.ts 异步化（await getDb()）为 v2 规范。

2026-08-04（下午）: Maybank MY email 交易通知判死 → 现金流 = AP/AR + 手动余额（用户 15:14 新需求）

Decision: 马来西亚 Maybank 没有 email 交易通知（官方仅 MAE App Push + SMS；site:maybank2u.com.my "email" 零结果；E-Payment alerts 是新加坡功能）→ 「银行邮件解析」路线正式终结（上午的方案 B 暂缓 → 现在判死）；现金流系统数据源改为 AP 应付账款（开 bill 给 subcon/supplier 记欠款）+ AR 应收 + 手动银行余额；用户要求把 AP 模块写进 GLM5.2 二轮优化 prompt（配合已有应收 + 手动余额算出真实现金流）。

Context: 用户 12:31 要求确认 Maybank email 交易通知能否开通（OpenClaw 真实浏览器查官方源）；结论：邮件多促销、交易只有 App Push；用户 15:14 主动提出：「既然 email 无法知道 transaction，那我就只能知道我还欠别人多少钱 + 别人欠我多少钱 + 自己看银行余额 = 现金流」→ 并要求输出「二轮优化 prompt」给 GLM5.2（含 AP bill 模块 + 部署注意事项）。

What changed: Gmail 邮件解析模块（hsd-system 内）定位为无用模块（README 已诚实标注近似）；现金流公式 = AP（欠别人）+ AR（别人欠）+ 银行余额；影响 Master DB 财务栏补数据优先级（19 项目仅 Ms Ong 有报价额）。

2026-08-04（下午）: Hermes fallback 清空（V4 PRO 账单问题）— 省钱铁律强化

Decision: 清空 Hermes 所有 fallback provider（fallback_providers = []），主模型只用 deepseek-v4-flash，报错就等待重试；任何情况下不再自动切到 deepseek-v4-pro（更贵）。

Context: 用户账单出现 V4 PRO 费用；排查发现 config.yaml fallback 链 deepseek-v4-pro 在 flash 超时/限流时自动触发 → 隐形加钱；用户拍板：「去掉所有 fallback，只用 flash，报错就等一等」；用 hermes config set 修改（config.yaml 不可直接 patch）。

What changed: D:\hermes\hermes-agent config 已改 + 验证生效（fallback_providers: '[]'）；以后模型调用失败会直接报错重试而非悄悄换贵模型。

Related: 2026-08-04 Credentials_Graph

2026-08-04（下午）: hsd-system 部署路线 = Cloudflare D1 + @opennextjs/cloudflare（弃 next-on-pages）

Decision: GLM5.2 现金流管家（hsd-system, Next.js）部署走 Cloudflare Pages + D1，适配器用 @opennextjs/cloudflare（弃 @cloudflare/next-on-pages——spawn npx ENOENT + Next 版本上限 15.5.2 双重坑）；Next 16.1.1 降级 15.5.22（opennext 要求 >=15.5.21 <16）；本地开发用 SQLite、云端用 D1（getDb() 双模式）。

Context: 用户明确「长期高质量优先，接受短期学习成本」+ Cloudflare 是主战场（quotation SaaS 已在跑）；GLM 默认的 Neon Postgres 方案被否（用户已有 Cloudflare 全家桶经验）；next-on-pages 对 Next 16 不支持（>=14.3.0 && <=15.5.2），且 Node 24 下 spawn .cmd bug；opennext 1.20.2 对 Next 15.5.22 esbuild 别名报错 → 降级 1.17.3（~15.5.10 覆盖）。

What changed: D1 hsd-cashflow-db（cd009bf4-3d28-4956-84e3-f60c4e7e2a5d，binding hsd_cashflow_db）+ 9 表已推云端；23 个 API 路由批量改 getDb()；Buffer→atob 清干净；next build 通过；部署尚未完成（opennext 版本兼容卡点验证中）；auth 决策 = 无登录（用户+AI 双权限裸奔，权衡接受）。

2026-08-04（上午）: 现金流管家路线 = 方案A（发票/报价应收）+ GLM5.2 定制系统（Bukku API 不用于实时余额）

Decision: 现金流管家走方案 A：基于 Master DB 报价/应收数据算现金流；银行实时余额另辟 GLM5.2 定制系统（现金流检查 + 应收账款 + 出 invoice，Google 生态优先）；方案 B（银行邮件解析）暂缓——Maybank 交易是 APP 通知非邮件；Bukku API 不承担实时余额（无余额端点 + token 过期 + 订阅无 Open API 权限）。

Context: 用户长期想要现金流管家（随时知道负债/未来现金流），前提是实时银行余额；实测 Bukku API：token JWT exp 2026-04-17（过期 3 个多月）+ /api/accounts 等 403 Open API access is not included in your subscription plan；用户：「如果有（API 权限）我才愿意花这个 35 块」，手动传 PDF 不实际（只能更新到上个月）。

What changed: GLM5.2 完整任务 prompt（D:\hermes\hsdesign_work\cashflow_glm_prompt.md）+ 素材包 HS_Design_GLM5.2_素材包.zip（2.1MB 已打包给用户）；Bukku token 新位置 D:\hermes\.bukku_token（⚠️ 需换新）；发现 Master DB 财务栏缺失（19 项目仅 Ms Ong HSP00007=10065 有报价额，已收/待收全空）→ 补数据是前提；Maybank email 交易通知开通可行性待确认（决定自动化）。

2026-08-04（上午）: N8N 自托管值得做（小步）/ ever-gauzy 明确不做

Decision: N8N 自托管社区版值得投入（0 成本、增量增强不迁移），从「顾客跟进提醒」一个流程起步；ever-gauzy 不做（过度设计）；Google Sheets 继续当唯一数据源（账本），N8N 当「自动手脚」；MacroDroid geofence 关灯留在原处（手机本地 GPS，N8N 替代不了）。

Context: 用户 08:09 把 CRM/N8N skill 列入待办，AI SEO 完成后启动；子代理（20260804_094354_457b0c）全官方源核实：n8n v2.32.7、自托管免费、内置 Google Sheets 节点（含触发器）+ 内置官方 MCP server（v2.13+）；gauzy v111.0.12 定位 ERP（员工工时/工资/招聘占大半功能）、4+ 容器、AGPL 系许可复杂、官方重心转 Ever Teams。

What changed: skill hsdesign-business-automation（references/n8n-gauzy-research.md）+ research/tech-vendor-research（references/n8n-ever-gauzy-2026.md）建立；待办 crm-n8n-research 继续；尚未部署 n8n（下一步：Docker 起容器 → Hermes 连 MCP → 跟进提醒流程）。

Related: 2026-08-04 sozo-todos Company_Graph

2026-08-04（上午）: 每周 SEO 健康检查 cron 建立（dba43311ad92）

Decision: 建每周一 9:00 的 SEO 健康检查 cron（脚本采集 + agent 简报双模式），用户拍板「我觉得这个 cron 很好」；用 DeepSeek/免费省 token。

Context: AI SEO 收尾时发现软 404 等隐患需持续监控；用户偏好主动健康检查、慢任务报进度。

What changed: seo_health_check.py 自动测首页可达/canonical/schema/sitemap/软404/blog title；job dba43311ad92 首跑 2026-08-10；已手动触发验证成功（execution_success）。

Related: 2026-08-04 SEO_Strategy_Graph

2026-08-04（上午）: AI SEO 工具链 — 吸收 claude-seo 为 Hermes skill（弃 Claude Code 路径）

Decision: AgriciDaniel/claude-seo（25 sub-skills + 18 sub-agents + 53 个纯 Python 脚本）直接吸收为 Hermes skill，不走 Claude Code CLI——本机 Claude Code 被配置成 MiniMax（ANTHROPIC_BASE_URL=api.minimax.io）且 token 过期，print mode 全部超时；且工具链纯 Python 不依赖 CC 当大脑，无需改 API 配置。

Context: 用户问 claude-seo 对 hsdesign.biz 有无帮助 → 试本地跑 CC 失败 → 用户：「先试试本地 Claude Code 方案，实在不行才移植成 Hermes 的 skill」+「如果很依赖 CC 可以把它的 API 配置改成 DeepSeek」→ 实测发现 Python 工具链在 Hermes 直接跑通（sitemap_discovery 成功），采纳吸收方案。

What changed: 4 个新 skill（hsdesign-seo-audit / seo-audit-toolchain / hsdesign-blog-seo / hsdesign-blog-publishing）+ cloudflare-pages-deploy 更新；Google 凭据软链 ~/.config/claude-seo/google-api.json；第三轮 SEO 修复上线（软404 / 19 篇 blog title ≤60 / Indexing 推 19 篇）——详 2026-08-04。

2026-08-04（凌晨）: 知识同步 cron 增量策略 — 质量优先（用户拍板）

Decision: 「知识同步至Vault」cron（3400cce6bf0f，每 3 小时）超时修复方向 = 增量拉取 + 质量优先，绝不砍沉淀内容。用户原话：「知识沉淀的质量很重要，不要只读摘要吧，可能可以延长时间上限，而不是减少沉淀」。

Context: cron 因主会话 20260802_210508_8353eb 累积 1135+ 条消息、每次全量重读 → 单次 API 请求超 600s（idle for 603s waiting for non-streaming API response）→ 失败。DeepSeek API 本身健康；fallback 链兜不住（问题是响应时间不是不可用）。初始错误方案是「大会话只读摘要」——被用户否决。

What changed: cron prompt 改为增量策略：session_search 用游标/时间戳只读「本次 cron 新增消息」；首尾摘要定位新决策 + 针对新知识点深入；10 分钟完成目标。增量机制天然防超时（每次只处理增量，负载固定）。

Related: 2026-08-04 FOR-PC-AGENTS

2026-08-03（深夜）: Work Schedule 权威再升级 — GLM 5.2 V6（弃 Antigravity v4）+ 三级备份铁律

Decision: 装修排程权威版本从 Antigravity v4 升级为 GLM 5.2 生成的 V6 系统（用户拍板「效果最理想」）：7 tab 完整系统（AI Guide/Overview/Gantt Day/Week/Today/Categories/Settings），Gantt (Day) 17 列 A-Q、数据行 12 起、甘特区 R 列起 167 列、J/K/P 自动公式。三级文件结构铁律（用户批评「只是做测试不是应该做了备份才试吗」后确立）：🟢 母版 1JMgliJew... 永不 write ｜ 🟡 测试副本 1esQZu68... 实验区｜ ⚠️ 污染旧表弃用；任何改动先 copy 副本。另确立：让 Gemini/GLM 直接产出成品 Sheet（Hermes 落地易出格式问题）、Obsidian 图谱必须用 Mermaid（打开即见图形）、H 盘（Google Drive 挂载）write_file 会静默失败 → D 盘写 + cp + 验证字节数。

Context: 用户分享 GLM 5.2 做的 V6 表（Drive 文件夹「Work Schedule」1aEr6dqDqDXe3vCmCAgINkt6gzxU2zp5M）说效果最理想；.gs 脚本评估=有用但非必须（EMAIL_TO 占位符、部署需 Owner [email protected] 授权）；Rosmerah Banglo（HSD00009，Mr Vincent，RM53 万大工程）15 任务/104 天试跑在测试副本全验证通过（自动工种配色/J/K/P 公式/依赖顺序/Alert 时序）；用户认可「很好地理解它的规则，没有擅自编辑不该动的地方」。

What changed: skill hsdesign-work-schedule 更新为 V6 权威（含三级结构 + Rosmerah 案例 + AI Guide 教学）；同一晚完成公司图谱体系（16 张：Company/Website+3索引/Work_Schedule/MasterDB/Quotation/QuotationSaaS/Bukku/Renovation_Process/Customer_Lifecycle/Finance/SEO_Strategy/SmartHome/MultiAgent/KnowledgeSync/AIProjects/Credentials）——详 2026-08-03。

2026-08-03（晚场）: Work Schedule 定版 — Antigravity v4 系统为权威（弃 API 自建版）⚠️ 已被 V6 取代（见上条）

Decision: 装修排程系统定版为 Antigravity Desktop 生成的 v4 甘特系统（1seUKtnNU8qRwmA5VVCka5FaN6kSu4ClwOLZLptKSUVo），弃用此前 API 自建的两版（1ocpMzx2H... v3 18 阶段、1GMGo6sk... 中间版）。载体必须是 Google Sheets 而非 HTML——用户明确指出 HTML 只有能改代码的人能编辑，Sheets 可在手机/电脑 App 直接改日期自动更新。Hermes 角色 = 按逻辑文档做数据录入（Category/任务/Lead Time/工期/开始日期，不填结束/下单日）+ 状态维护 + 盯 ⚠️ NEED TO ORDER 提醒。

Context: 用户嫌 API 版”很丑”，建议让 Gemini Pro 直接生成高质量模板；过程中发现 agy CLI 后台 PTY 跑长生成任务会卡死（8.5 分钟无进展）、headless 又静默回退 Flash → 改用 Antigravity Desktop（GUI 版，用户实际使用的工具） 直接产出成品表 + 专门给 agent 的逻辑文档（HS_Design_Logic_For_Hermes.md）。v4 核心亮点 = Lead Time 准备周期 + Order Date 最迟下单日 + Status 状态 + ⚠️ NEED TO ORDER 自动提醒——装修排期真痛点：材料要提前订。

What changed: 权威表已含示例 6 阶段（拆除/泥作/水电/木作/油漆/软装），提醒逻辑已验证触发（木作 Lead Time 30 天 → 最迟下单日已过 → ⚠️ NEED TO ORDER）；skill hsdesign-work-schedule 更新为 v4 逻辑；另确认 Gemini 视觉免费 quota 用完（图片分析截断）→ 视觉验证改用 Sheets API 读结构/背景色。下一步：拿真实项目（Sanna/Jali）试填验证 Alert 逻辑。

2026-08-03（傍晚）: Master 数据库落地 — 全量主档 + filter 视图 + 项目号超链接（IMPORTRANGE 授权解谜完成）

Decision: Master 数据库系统建成，关键架构定案：

客户主档 = 全量档案（以后含历史成交客户）；跟进表 = 只镜像「跟进中」顾客的 filter 视图（QUERY+IMPORTRANGE，不是全量镜像）——用户纠正：“客户主档如果全部跟跟进表镜像，就只有跟进中的顾客会出现；已完成/成交的顾客资料也应该在主档里”
项目号本身做 HYPERLINK（删独立「报价单链接」列，点项目号直达 04-Projects 项目夹）——用户拍板：“不需要报价单链接 column，直接在这个项目号里面的每一个字都 hyperlink 到对应的 project 就好了”
报价单独立、不连 Master（每个新报价单都连 Master = 每份授权一次，烦）——Master 用超链接”看”项目夹即可
拒定时脚本同步（30 分钟 cron 在多人在线编辑时会覆盖最新数据）→ 用 IMPORTRANGE 实时同步
Item均价必须有「价格类型」列（成本/加成率）——用户指出”你写的价钱是成本还是卖价，这一点需要注明”

Context: 下午启动的 Master 库（方案 B）卡在 IMPORTRANGE #REF! 授权；真凶有二：①授权需在接收表点 REF! 格的「允许访问」（用户在跟进表操作后通过）；②O1 公式要展开 10 列但被 P1 提示文字挡住 → “Array result was not expanded because it would overwrite data in P1”，清掉即通；另发现旧 Sheet1（frozenRows=1）A1 公式展开失败（显示 “Column 1”）→ 新建 tab 解决。

What changed: 跟进表只剩 ColdCall视图 tab（QUERY 实时拉”跟进中”状态顾客：今晚打电话/待报价/跟进中/待勘察/进行中/等定金）；客户主档重构 11 列（与跟进表同构）；项目总览 19 项目 + 状态 + 项目号 HYPERLINK（21 项目 folder_id 映射入 skill）；HSP00003/04 标「未成交」；Item均价 20 条；Master 移到 CRM 文件夹 1a_iLNewEAQ_suiVf8trYp98ZI2oj0Gbw（用户指定）；skill hsdesign-customer-followup + memory 已更新；Google Sheets API 超时 = 网络问题（用户重启 modem 恢复）。

2026-08-03（傍晚）: 装修 Work Schedule 工具选型 — Google Sheets 甘特图模板（弃 Notion/ClickUp）

Decision: 装修工程排程用 Google Sheets 甘特图模板（起止日期 + 条件格式色块自动铺开），不用 Notion/ClickUp——用户要求”浏览器随时打开、不用下载 App、免费、留在 Google 生态”。模板已建：「HS Design 装修Work Schedule模板」1ocpMzx2H_rAe2sqfR2EniBNGCsMRin2e3vNBHeGOekA（CRM 文件夹，18 阶段）。

Context: 用户确认 work schedule 是当前最痛点（手动写麻烦、持续性低）；报价自动生成已有 skill 不重复做；转介绍 = 朋友佣金、无需自动化。用户提供关键装修工序知识：电工分多阶段进场（敲墙后第 1 次拉 conduit 管线 → 石膏（含灯线）→ 石膏后回来装灯/开关/壁橱 LED）；木工必须等石膏才能测量精确尺寸；铺地砖必须在木工安装前（没地砖厨柜放不上）；双轮油漆（石膏后第一轮 + 木工完成后第二轮收口）；floor protection 地砖后到木工完才拆；窗帘/沙发清洁后（无尘）才进场且可并行；水电可并行、石膏与地砖可分区域并行但一般分开（避免工人纠纷）。工期参考（双层排屋后厨房扩建）：总 1-2 个月含敲工；石膏 ~1 周；木工测量→安装 ~4 周；油漆 ~1 周；突发状况 1.5-2 倍时间。

What changed: 模板工作簿已建（Schedule tab：准备→敲工→砌墙→电工①→石膏→瓦工→油漆①→木工测量/制作/安装→电工②→油漆②→五金→清洁→软装 + 地砖保护行）；备份 work_schedule_template.json；条件格式甘特图美化 + 用户实测待续（会话结束时正在用 OpenClaw CDP 找现成模板参考）。

Related: hsdesign-work-schedule 2026-08-03

2026-08-02（晚场）: 人生思维导图托管方案 — Cloudflare Worker + URL 密钥（弃 Google Drive 直开 / GitHub Pages）

Decision: 完整版 HTML 思维导图（幸福人生全景图.html）托管方式定案：

❌ Google Drive 直开：Drive 把 HTML 当文档预览（view/preview 均显示「Page 1 of 3」文档查看器，不执行 JS）→ 手机打不开渲染图
❌ GitHub 私有库 + Pages：免费但每次打开要登录 GitHub 账号（手机体验差），账号密码是单点风险
✅ Cloudflare Worker + URL 密钥（用户 18:06 拍板）：免费版 10 万请求/天；32 位随机 hex 路径密钥做访问控制（无登录框 → 无破解面，非密钥路径 404）；点链接即开零登录；可 Add to Home Screen 当 app 用；更新只需改 KV/重部署

Context:

用户要求：手机随时在线打开、私密（不放 hsdesign.biz 避免公开）、免登录、add to home screen
hsdesign.biz 已用 Cloudflare（wrangler 4.84.0，账号 [email protected]，token 在 site_full/.env）

What changed:

Jakephone/Life-Map/（Drive folder 1flLN9wzio_6-UAcXufpLc-IGDvDbMBtS）已上传 HTML（file 1UXTcivDeR-cucHYq3IQoHWQ8O3CcmJGJ）作备份
life-map-worker 搭建中（D:\hermes\hsdesign_work\life-map-worker\，base64 内嵌 HTML + SECRET 路径判断）——gen_worker.py 有 f-string 语法错误，未部署完成（下场会话续）

Related: happiness-canvas 2026-08-02

2026-08-02（下午）: 人生思维导图改用 vis-network 力导向图 + 报价模板新增 Electrical Work 组与紧凑化规范

Decision 1 — 人生思维导图技术选型：vis-network 力导向图（弃 Obsidian Canvas / Markdown 树）

用户要「上帝视角」网状分布（参考 Coggle/GitMind），Markdown 树会收起内容、Obsidian Canvas 手工坐标必然重叠/连线乱
数据存 JSON（程序可维护），渲染用 vis-network 物理引擎自动布局（防重叠、弹簧连线、天然支持交叉节点）
file:// 下 fetch JSON 被 CORS 拦 → JSON 内嵌 HTML；日期节点（🗓MM-DD）黄色高亮 → 接 sozo-todo-manager 自动进待办，无日期节点只留在导图
Demo 完成于 D:\hermes\hsdesign_work\life-map\（2026-08-02 11:59）；待用户给全量节点后建完整版

Decision 2 — 报价流程新规范（Perumal 报价实践 + 用户确认）

新增工种组时 teal 样式只能 apply 标题行：repeatCell 范围写错会把整组 item 行染青（Perumal Electrical 组事故）
item 少时删除每组未用的空 item 行（模板每组预置 6 行）：报价紧凑专业，删后必须修复 SUM/Total/Payment 公式引用
Electrical Work 成为模板可选组：插座/开关延长、装油烟机（客户供机器只算安装）等电工项归此组
item 描述 = 粗体标题 + bullet point 明细（不能写成一段话）

Context:

Perumal（Pulai Flora）报价 7 item 覆盖 3 个工种组，模板 11 组只用到 2 组 + 需要电工项 → 暴露「新增组样式」与「空行冗余」两个问题
人生导图旧方案（2026-05 happiness-canvas）4 坑：Canvas 文件没落盘 / 中文路径混淆 / 329 节点手工不可维护 / 数据源分裂

What changed:

HSP00009 报价单已建：https://docs.google.com/spreadsheets/d/1T3DvdN7bL7VJW83fmfPbmmzIvqcyNdUFQAr5DayA7XU/edit
两条教训已 patch 进 skill hsdesign-quotation-system（13:57–13:58）
life-map demo：D:\hermes\hsdesign_work\life-map\index.html + life-map.json

2026-08-02: 报价单底部区标准定型 — A 列 + merge A-F + Payment Term 青绿白字 + Bank 完整资料（真实手机号）

Decision: 报价单底部区统一标准（Ambience 实践 + 用户 2026-08-02 确认）：

所有底部 detail 写 A 列 + merge A-F（新模板已删 A 列空格；Rosmerah 用 B 是因为旧版 A 列有一整排空格占位）
Payment Term 标题行 = 青绿底 + 白字粗体（标题所在格 + 右边一格，如 Ambience R24 / MASTER R91）
Bank/Contact 4 行完整资料（teal 10pt LEFT，merge A-F）：RegNo 202603001610 / 地址 / email + 网站 www.hsdesign.biz + 真实手机号 011-1688 0145（不脱敏，脱敏号码客户无法联系） / Maybank 551539158314
不再需要 “Bank Account” 标题（底下填 Maybank 账号即可）
长地址分段写 + wrap + 行高 40px（postcode/Masai 曾因 22px 单行高 wrap 被挤掉）

Context:

Ambience（Ms Ong）报价收尾时用户逐项指出底部问题：手机号带星号、缺网站/RegNo/Maybank、多余 “Bank Account” 标题、Payment Term 白底橙字不符品牌
根因之一：values().update 只写文字不写样式 → 新内容继承错误深灰格式；补写内容必须带样式
参考 Rosmerah R81：B、C 列青绿底白字粗体（因其 A 列有空格列）

What changed:

Ambience R24 + MASTER R91 Payment Term A/B 刷青绿白字粗体（已修并 verify）
Ambience 底部 Bank/Contact 4 行重写：RegNo / 地址 / email+网站+真手机号 / Maybank，merge A-F
Project Site 地址分段（B8/B9）+ wrap + 40px 行高
skill hsdesign-quotation-system 新增「底部区（Bank/Contact/Payment）标准（2026-08-02 用户确认）」节
Austin 报价单待同步（会话结束时进行中）：删 “Bank Account” 标题、手机号脱敏 → 011-1688 0145、补网站/RegNo/Maybank；Payment Term 已青绿 ✓、Bank merge A-E ✓

2026-08-01（深夜）: 报价模板体系定型 — MASTER v3 全工种组 + 用户原模板为版面基准 + PDF 用户自导出

Decision: 报价版面以用户 G: 原模板（Quotation sample.xlsx）为基准——xlsx 上传转换 Google Sheets 1:1 保留格式；MASTER 模板 v3 含 11 个工种组（Masonry/Flooring/Steel/Window/Ceiling/Aluminium/Carpentry/Plumbing/Tiles/Painting/Partition），每次新报价从 MASTER 复制并自动裁剪不需要的工种组；PDF 导出由用户自己完成（agent 不自动导出）。

Context:

用户 22:00 反馈报价 v1 版面「不够漂亮、description 超出格子」→ 分析发现用户原模板布局完全不同（Description C 列、成本/利润列 J-P 靠打印区域 A1:I66 自动跳过）
MCP 无合并单元格/打印区域工具，但导入 xlsx 会保留全部格式 → 用 Drive API 上传转换，用户认可（“很高度还原了我之前喜欢的风格”）
用户纠正 tall cabinet 不是铝蜂窝板 → 归 Carpentry（plywood+laminate+PVC internal）；确立工种归属规则
用户偏好：agent 确认文字对、用户微调后自己 export PDF（API 导出默认 Letter 且带成本列，不符合需求）
用户纠正：删除 A 列/第 1 行是一次性模板动作，不应写进 SOP

What changed:

Item 库 85 → 91 item（新增 Austin 铝蜂窝板 ID 191-196，首个 honeycomb 条目）
修复模板级白字白底 bug（根因：模板创建时整列误设白字）：MASTER 335 处 + Ambience 100 处 → item 行深青绿 2D4E52、青绿标题行白字
SOP 修正：工种组 10→11、模板坐标 v3、移除「删 A 列+第 1 行」步骤、新增「操作前重读布局」坑
Ambience（Permas Jaya）报价草稿：Masonry 13 + Carpentry 3 + Painting 1（plumbing 并入 masonry）
文件：Austin v2 / MASTER v3 / Ambience / Item 库 4 个 Sheets，见 hsdesign-quotation-sheet-system

Related: hsdesign-quotation-system hsdesign-quotation-sheet-system skill: hsdesign-quotation-system（D:\hermes\skills\productivity\）

2026-08-01（深夜）: 开启 Auto-compaction（compression.enabled: true）

Decision: 开启 Hermes 自动压缩 — hermes config set compression.enabled true → D:\hermes\config.yaml：compression.enabled: true / threshold: 0.5（上下文 50% 触发）/ target_ratio: 0.2（压到 20%）。

Context:

用户 21:15 看到「Context overflow and auto-compaction is disabled」提示，问是否没开自动压缩
确认 compression.enabled: false（之前被关）→ 用户指示「请打开 autocompaction」
配置改完需 /reset 开新会话才生效（避免破坏提示缓存，不中途热切换）

Related: 2026-08-01（深夜场）

2026-08-01: Antigravity CLI 用 PRO 模型 → PTY 交互方案（订阅 8/18 到期前尽量用尽）

Decision: [SozoPC] 上 Antigravity CLI（agy）使用 PRO 模型（Gemini 3.1 Pro）必须走 PTY 交互模式；8/18 订阅到期前把 PRO 额度尽量用尽；建 cron 定期检查官方修复状态。

Context:

agy v1.1.9 headless（--print）模式指定 --model gemini-3.1-pro-high 会静默回退 Flash（不报错、无提示）——官方 bug：google-antigravity/antigravity-cli Issue #710，官方 workaround = 交互模式 + /model 斜杠命令
桌面版（Antigravity 2.0）一直能用 PRO → 订阅有效；问题在 CLI 登录态（consumer 认证 [email protected] 未带 PRO entitlement）
用户决策（2026-08-01）：订阅 8/18 过期，过期前尽量用 PRO，不做长期维护；任务按难度调模型强度（flash / pro-high / pro-low）

What changed:

OAuth 手动兑换：CLI 每次运行生成新 PKCE code_challenge 且认证窗口仅 60s → Python 脚本自生成 PKCE + 从 agy.exe 二进制提取 client_secret（GOCSPX-…）→ 直接调 Google token 端点兑换成功（access + refresh token）
凭据存 Windows 凭据管理器 gemini:antigravity（keyring）
C:\Users\Sozo\.gemini\antigravity-cli\settings.json 持久化模型选择（重启后状态栏记住 Gemini 3.1 Pro · low）
Skill 固化：antigravity-cli-pro（D:\hermes\skills\autonomous-ai-agents\antigravity-cli-pro\SKILL.md，含完整按键序列与坑）
新 cron 4658b0a0070e「检查AntigravityIssue710」每天 09:00 查官方修复
待办：研究 agy quota 查看（weekly + 5-hour limit，quota_manager.go 日志 / fetchAvailableModels API）

2026-08-01: 主力执行切换到 Antigravity CLI（Gemini PRO）— 8/18 前尽量用尽

Decision: 8/18 订阅到期前，几乎所有任务优先派给 agy CLI 的 Gemini PRO 执行（省 DeepSeek token）；按任务难度调模型强度（flash / pro-low / pro-high）；研究 quota 查看方法（weekly + 5-hour limit）。任务分工：研究/搜索类 → Hermes（DeepSeek，有 web/知识库工具），批量生成类（博客、文案、翻译长文）→ agy（Gemini PRO）。

Context:

用户指示（08:59）：“18 号之前尽量把模型用尽”，几乎所有任务尽量让 agy 执行；agy 无 skill/知识，需本 agent 结合自身知识给出正确路径/命令词
Gemini 有 weekly + 5-hour quota，用尽后只能退回 cloud/sonnet 的小 quota
10:24 教训：直接发问题给 agy 不注入 context 回答很浅 → 必须先注入 skill/背景再派任务

2026-08-01: Google Workspace 集成选型 → workspace-mcp（121 工具）

Decision: Google Workspace 能力采用 GitHub taylorwilsdon/google_workspace_mcp（⭐2949）作为标准集成 — 12 服务 120+ 工具，配置进 Hermes mcp_servers.google_workspace（--single-user --tool-tier complete，env 清 PYTHONPATH 防污染）；原 google-workspace skill 保留为已验证的日常主力（token 已配好），workspace-mcp 完整授权作为增强。

Context:

用户问（10:46）“GitHub 上有没有更完善的 Google Workspace 方案可以一次过吸收” → 找到 workspace-mcp 是最成熟方案（vs 手写 skill 只有基本 CRUD）
安装后遇 PYTHONPATH 污染（Hermes venv 旧 pydantic 缺 pydantic_core 二进制）→ env 清空修复
hermes config set 把 args/env 存成字符串 → 需 Python 直接写 YAML 修正类型
gateway 重启后 121 工具全部加载；发测试邮件成功（用原 skill token）；workspace-mcp 自带 OAuth 需浏览器授权一次（进行中，start_google_auth 已生成授权 URL）

2026-08-01: 报价工具弃用 quotation SaaS → Google Sheets 报价系统（HS Design）

Decision: 弃用 quotation SaaS（quotation.hsdesign.biz，部署老出问题），改用 Google Sheets 共享报价系统。主工作簿：https://docs.google.com/spreadsheets/d/1AtTlTiqMLbl8t0u8u6osQQ6NmiQ-lG6kXewsgIuUwRM/edit — Sozo 与 Hermes 同权限共同维护；大框架由 agent 写、定制化细节用户写；定期把报价逻辑沉淀进 Item 库/价格参考，长期逐步自动化（用户做的工作越来越少）。

Context:

用户 13:38：「quotation 网页部署的时候经常出现问题，所以我有点累了，所以我们就走 Google Sheet」
用户 13:41 协作模式：大框架 agent 写、细节用户写、双方同权限、定期整理逻辑 → 越来越自动化
用户 13:56 选方案 A：Google Sheets 报价数据库（Dashboard + Quotation_<项目> 工作台 + Cost Breakdown + Item 库 + 价格参考）— 会成长的库，不占 agent memory
格式以用户喜欢的 HSD00009 Rosmerah / HSP00001 / HSP00002 为准；品牌色从 quotation SaaS UI 提取（鼠尾草绿 7C9A8E + 金 C9A84C）
Hill Land = 前公司（数据更多但格式不是目标，只作词汇/工种参考）；HS Design（HSD + HSP）是主训练数据
第一轮提取：6 份 xlsx → 114 item / 29 工种分组（Excavation/Masonry/Flooring/Steel/Window/Partition…）
今日待处理报价：Austin（商家版橱柜 + 铝蜂窝板橱柜）、Permas d’Ambience Condo（敲工/水泥/地砖/安装/少量木工）

Related: hsdesign-quotation-sheet-system workspace-mcp（Sheets 工具）[SozoPC] skill: D:\hermes\skills\devops\hs-design-quotation-automation

2026-08-01（晚）: 报价系统架构细化 → 方案 B（Item 库为核心），ITEM 库 85 item 固化

Decision: 报价系统结构定为方案 B：「Item 大数据 + 项目 Sheet 结合，以一处累积的 Item 库为核心」——所有报价 item 累积在单一 Item 库（越用越准），每个项目用独立 Quotation Sheet。取代早前 13:56 的方案 A 表述。

Context:

17:58 用户对比 A（每项目单独 Sheet）vs B（总 Sheet 累积）后确认 B：item 集中才能做训练/分析、自动化匹配、跨项目漏项检查
参考格式 = Rosmerah（用户喜欢）；item 数据大量从前公司 Hill Land 提取（用户 17:57 指示）
用户指示：一小时内没回复就继续完善数据库（自动续跑模式）

What changed:

ITEM 库最终 85 个 item（Rosmerah 28 + HS Design 92 → Hill Land 451 → 去重 298 → 智能分类 → 清洗合并 85；Carpentry 候选最多，Austin 橱柜可用）
Quotation 模板重建 54 行（品牌表头 + 10 工种分组 + 利润公式）；检查SOP Sheet 18 条漏项规则
skill hsdesign-quotation-system 固化（D:\hermes\skills\productivity\hsdesign-quotation-system\SKILL.md）；提取脚本存 D:\hermes\hsdesign_work\
Hill Land 43 个 xlsx 报价单复制到本地；工作簿现有 4 Sheet：Quotation 模板 / Cost Breakdown / Item 库 / 检查SOP
工作簿: https://docs.google.com/spreadsheets/d/1AtTlTiqMLbl8t0u8u6osQQ6NmiQ-lG6kXewsgIuUwRM/edit

2026-08-02（深夜）: Gemini 免费层多账号 key 轮换 + fallback 链插入 Gemini（视觉省钱方案）

Decision: 视觉模型（gemini-3.6-flash 免费层）quota 用尽（429）后，采用 Hermes 原生多 key 自动轮换：多个 Google 账号的免费 Gemini key 组成轮换池，key exhausted 自动跳到下一个（mark_exhausted_and_rotate，无需自建脚本）。同时把 Gemini 免费层插入 fallback 链、web_extract、compression，把付费 openrouter/gpt-4.1 挤到最末位兜底。

Context:

视觉 = Gemini 免费层（免费 quota 用完 429），用户问如何省钱 → 用户有多个 Google 账号，20:19 同意 key 轮换策略
Hermes 已原生支持 Gemini 多 key 轮换
主文本模型仍是 deepseek-v4-flash（无其他缺口；Gemini 只补视觉）

What changed:

轮换池 4 账号：GOOGLE_API_KEY（429 跳过）/ [email protected]（429 跳过）/ [email protected]（✅）/ [email protected]（✅ 200 验证）
20:43 配置：fallback 链 = deepseek-flash → deepseek-pro → gemini（免费）→ openrouter/gpt-4.1（付费兜底）；web_extract → gemini-3.6-flash；compression → gemini-3.6-flash（用户批准重启）
key 原文只存 Hermes 配置，不入 vault（见 gemini-api-rotation）

Related: 2026-08-02 gemini-api-rotation

2026-08-02（深夜）: compression/web_extract 撤出 Gemini 免费层（配额烧尽 → 超时事故）

Decision: auxiliary.compression 和 web_extract 从 gemini-3.6-flash 改回 auto（走主模型 deepseek），仅 vision 保留 Gemini 免费层。高频辅助任务（每次上下文压缩/网页提取）不再占用免费层额度。

Context:

08-02 20:43 把 compression/web_extract 指到 Gemini 免费层 → 21:30 出现 compression 30s 超时 + state.db 写入失败告警
根因：免费层额度 ~450 req/天被高频压缩/网页提取烧光 → 全 key 429 exhausted；state.db 写入失败 = gateway 重启后多进程争锁
config 启动时加载、会话内不可热更新 → 修复必须重启 gateway 才生效

What changed:

compression/web_extract → auto（deepseek 主模型）；vision 仍 gemini-3.6-flash；gateway 重启（PID 16264→15892）✅ 生效

Related: gemini-api-rotation 2026-08-02

2026-08-02（深夜）: 报价成本明细悬浮查看 = 单元格 Notes（弹窗替代切 sheet）

Decision: 报价单查看 item 成本子项明细的方式定为 Google Sheets 单元格 Notes（注释）——鼠标悬停自动弹黄条显示该 item 的 subcon 成本分类明细，不用切去 Cost Breakdown sheet。用户验证满意（「非常满意，我很清楚地看到了我的成本」）。

Context: 一格只能放一个成本，但卖价 item 常由多个 subcon 成本组成；用户要一眼对比成本与卖价，又不想切 sheet。

What changed: 价钱格（G 卖价 / K 成本）加 Note（每 subcon 一行 + 金额）；K 列成本公式已接；成为报价系统新标准（已入 skill）。

2026-08-02（深夜）: 思维导图已完成任务 30 天保留 + 待办事实源联动规则

Decision: life-map 里已完成的任务保留 30 天后自动消失（保留成就感 + 防项目臃肿）；没做的任务直接删。带 🗓 日期的节点 = 待办事实源（每日提醒从导图/sozo-todos 读，不靠记忆收集）。

Context: 用户 23:05 提出：已完成任务马上消失没成就感，一直留着又臃肿难读；待办要能从导图节点自动进每日提醒。

What changed: 巴西古当顾客 9/1 拿锁匙 follow up 已入 sozo-todos.json + 导图 Projects 节点（🗓2026-09-01）+ 2 个 cron（8/31 提前提醒 + 当天）；打羽球 08-05、游泳 08-09 未做已删；30 天自动消失逻辑待实现。

Related: sozo-todos 2026-08-02 [SozoPC] D:\hermes\hsdesign_work\life-map\

2026-08-03（早）: 导图待办同步自动化 + 固定 SOP（导图 = 唯一待办来源）

Decision: ①新增 cron 233832d10c8d「导图待办同步到sozo-todos」每 30 分钟自动跑 sync_lifemap_todos.py --quiet（no_agent 静默，有新增才输出）；②在 sozo-life-map skill 写入「🔥 待办增删固定流程 SOP」：用户说新增/完成待办时必走完整两步（思维导图部署链 + 待办同步），缺一不可。用户明确拍板”两个都要”。

Context: 用户发现每日待办提醒（cron 5a0d4c69b096 8:00）只读 sozo-todos.json active 数组，且导图与待办清单常不同步（Austin/Ambience 状态过时）；导图带日期节点要手动同步进清单，容易漏。同步脚本原本按 id 去重，与手动建条目（不同 id 同任务）重复，需改为按任务文本/关键词去重（幂等）。

What changed: 待办同步从手动变自动（30 分钟粒度，静默 watchdog）；sync 脚本去重逻辑重写（norm 文本 + 6 字关键词宽松匹配）；cron 提示词更新为同时参考导图日期节点；每日提醒现在能显示 waiting_supplier 状态。

Related: sozo-todos sozo-life-map 2026-08-03 [SozoPC] D:\hermes\hsdesign_work\life-map\sync_lifemap_todos.py

2026-08-03（上午）: 顾客跟进 CRM 定为 Google Sheets + 手动更新模式 + 报价约见面策略

Decision: ①顾客跟进系统用 Google Sheets「HS Design 顾客跟进表」（ID 1Tdz6J95a7C6Gtzq19DOwmpz5gQ-hf0TW_49IRQgAGZk，CRM 文件夹 1a_iLNewEAQ_suiVf8trYp98ZI2oj0Gbw），手动更新模式（用户报状态→Hermes 写表；不自动读 WhatsApp——个人 WhatsApp 无开放 API 不可行）；②12 列结构：E 状态列只放可 filter 关键词，L 状态备注独立成列（括弧备注会破坏 filter）；③报价后尽量约见面，不设 follow up 提醒（成交率高）；④已成交顾客完成后 1 个月回访（转介绍机会）。

Context: 用户开始打广告，顾客增多需系统化跟进；曾设想 Hermes 直接读 WhatsApp 自动更新状态（最理想但难实现），退而求其次手动模式；用户发现状态栏里括弧备注让 filter 无法同质化拉取（如”今晚打电话”），要求备注独立成列。

What changed: 13 位顾客/lead 录入跟进表；Hermes skill hsdesign-customer-followup 建立（含访问代码/踩坑/项目号对照表）；2 个一次性 cron：今晚 8 点打 6 位顾客（f1951990560a）、8/8 follow up Fiona 约见面（eb7a9e51e9ef）；项目号核对修正（Lily=HSP00001 非 08、Mr Chen=HSP00006 非 Chi、Granvia 旧项目移除）；新待办 HSD00004 书包店 3D；踩坑：values().append() 覆盖已有行（Fiona/Sanna 互覆盖）、中文批量写需 RAW。

2026-08-03（下午）: 统一 Master 数据库 = 索引 + IMPORTRANGE 连接（方案 B，弃全量迁移方案 A）

Decision: 建统一 Master 数据库（客户 + 项目 + 报价一处查全），架构定为方案 B：Master = 索引 + 自动汇总，不是仓库。报价单/跟进表通过 Google Sheets IMPORTRANGE 跨表引用自动同步，Master 客户主档为权威数据源，跟进表降级为 cold call 专用视图。弃方案 A（全部数据迁进一个表）。

Context: 用户对比两方案后拍板：方案 A 每次报价都要重读 Master 再写回报价单（token 浪费），且数据变两份（Master + 报价单）改一处另一处不同步（像 Lily 项目号搞错那样）；方案 B 长期有效省 token，金额类数据只需定期核对（subcon 成本每家不同，只求均价）；跟进表是打电话前看的视图，融进 Master 会太多数据同页。

What changed: MASTER 工作簿已创建（ID 1EYcHpHwI-H50MHzbk27f0l_u7RGROvx6WiS_DR_-7og，已移入 1SLTrLHv_mOKt-AMnXhuXLzblwGVFidrZ），3 tabs：项目总览 / 客户主档 / Item均价；跟进表 14 位顾客已迁入客户主档作种子数据；IMPORTRANGE 连接测试中（首次跨表引用 #REF! 授权问题未解，待续）。

2026-08-03（下午）: 跟进表回归 11 列（删 L 状态备注列）+ 「等定金」新状态词

Decision: ①跟进表删掉 L 状态备注列，回归 11 列——用户确认 K 备注已含全部细节，L 列冗余；E 状态列只放可 filter 干净关键词（状态里不加括弧，细节全放 K 备注）。②新增标准状态词 「等定金」（已口头成交、未收定，区别于「已成交」）。

Context: 上午刚建的 12 列结构（E 状态 + L 括弧备注）用户试用后发现多余——原本 K 备注就有这些内容；Jali 新顾客（口头成交等定金）暴露需要区分「口头成交」与「已成交」的状态粒度。

What changed: L 列删除（回到 11 列 A顾客|B来源|C类型|D地点|E状态|F首次|G最后|H下次|I次数|J联系|K备注）；查找顾客改按姓名（不依赖行号，用户可能手动排序）；「等定金」入 skill hsdesign-customer-followup 标准状态清单。

2026-08-05（凌晨）: 语音转录学习闭环制度化 + Google Sheets 退役 + 混合输入模式

Decision: ①语音转录学习闭环制度化：新 skill voice-transcript-learning + 词库 voice_transcripts/knowledge_base.md（初始 20 地名 + 19 人名，从 master app 数据提取）；Gemini 转录 prompt 注入词库（识别层）+ 转录后对照词库二次校验（文本层），用户更正反馈 = 词库复利主燃料；②Google Sheets 退役：master app（云端 D1）为唯一数据源，Sheets 只读存档不再更新；③混合输入模式：短指令/紧急事 → 微信输入法，长内容/闲聊 → 语音发 Hermes（两通道并行）；④转录脚本改精简输出（一行结果，上下文减 80%）；⑤Gemini 配额规则：语音转录永远优先，视觉省着用（共用同一免费 key，429 时自动降级本地 Whisper）。

Context: 用户确认语音转录方案可行后追问「机制怎么固定」→ 拍板建 skill 而非只写 memory；问「Gemini 凭什么认识我的地名/人名」→ 发现裸转写不认词库，当场升级为 prompt 注入；凌晨 00:43 实测撞 429（computer use 视觉 quota 用多挤掉语音配额）→ Whisper 本地兜底成功；用户确认 master app 数据全在云端 D1 后同意 Sheets 退役。

What changed: skill 建好（D:\hermes\skills\personal\voice-transcript-learning\SKILL.md）；词库/日志建立（D:\hermes\hsdesign_work\voice_transcripts\）；转录脚本 voice_transcript.py 词库注入上线；新 cron：语音缓存清理（dc82e5d8edb4 每天 04:00，ogg 保留 30 天）、提醒改图给明浩（18452f343ff1 8/5 11:00）；D:\hermes 已整体进 Google Drive 云端备份。

2026-08-05（白天）: 新闻播客两步 cron 防撞车 + Windows 脚本全转 .py + life-map 升 D1（方案 A1）+ 报价自动保存

Decision: ①新闻播客改两步 cron：05:00 LLM 生成（ef4bdca0178f：搜昨天新闻→写对话腔播报稿→TTS 分段→ffmpeg 合并→存 daily_podcast_<date>.ogg + 摘要）+ 07:30 纯脚本直发（33a603119683，零 LLM 零超时）——修掉 8/5 早 7:30 新闻任务与主会话抢 DeepSeek 配额导致「假成功」（last_status ok 但无音频产出）的撞车根因；播报风格改小雅阿轩对话感（用户明确：不要轮流一人念一篇）。②Windows cron 脚本一律 .py：10 个提醒/清理脚本从 .sh 全转 .py（MSYS bash 吞反斜杠 → D:hermesscripts... 找不到文件）；不手动 run 一次性 cron（会消耗一次性提醒，9:00 KK 提醒因此重建过）。③life-map 升 Web App + 独立 D1（方案 A1）：新建 life-map-db（APAC，id ed20aa50-8463-4820-9a1b-5fe580c97e7b），state 单表 JSON，KV→D1 迁移完成（HTML 376KB + state 72KB，参数化绑定避开 SQLITE_TOOBIG），worker 部署验证通过；与 master app 分开数据库、链接连接（不共享数据，超链接模式）；给 GLM5.2 的 prompt 加三大模块：📚 知识第二大脑（knowledge_nodes）/ 👥 人脉关系图（contacts）/ 🎯 长期规划（goals，可达目标里程碑模式，月度/季度/年度分组，非数字目标）。④master app 报价编辑器自动保存上线（停输入 1 秒自动存；移除保存按钮改绿色呼吸灯「已自动保存 HH:MM:SS」）；资金动作保留按钮——Invoice 记录收款（POST /api/payments）、账单付款是真实交易，金额填一半自动提交 = 错误账目。⑤Bukku API 判死：订阅不含 Open API（403，8/4 已确认）→ 方案 B 手动导出 CSV 整合 master；WhatsApp 群发走半自动：每周 Hermes 生成装修知识/节日祝贺文案（马华、分客户类型）→ 用户 WhatsApp Business 广播列表一键群发（RM0、零封号风险）；官方 Business API/第三方（WATI/Respond.io）到 ~300 条/月或 30-50 活跃顾客才值得。⑥Antigravity 检查 cron 已删（4658b0a0070e）。⑦Hermes Desktop 桌面 shortcut 已建（官方 logo）；「手动打开带后台窗口、关窗口即退出」问题待优化。

Context: 早 7:25 主会话触发 context 压缩（489 条/13.4 万 token，DeepSeek 压缩耗时 54 秒）→ 7:30 新闻 cron 启动后与主会话抢 DeepSeek 配额/并发，下一步调 LLM 没走通就静默结束（日志截断在第一步 terminal，无 TTS 无发送，但 status 标记 ok）。用户追问「新闻没漏吧」时发现假成功，并要求播报改对话腔调。life-map 升级：用户选方案 A（这次就上 D1），并拍板架构原则（分开存储/链接连接/可达里程碑/不碰付费 API/情绪日记不做）；8/5 12:10 用户回传 GLM5.2 交付 life-map-v6.1.zip 待部署验证。报价整理时要求 auto-save（报价单 + invoice 及其他手动保存点），但资金动作必须保留确认。

What changed: 新闻 cron 一拆二（生成/发送彻底解耦，发送永不超时）；10 个脚本 .py 化；life-map-db 建成 + 迁移 + 部署（避开 master 迁移踩过的坑：SQLITE_TOOBIG→参数化绑定、split(');') 切坏 SQL、D1 不关事务）；life-map-app.zip + PROMPT_TO_GLM52 交 GLM5.2；报价自动保存部署（Version e70a5b34）；⚠️ 未解决：部署后 master app 全 API 500（回退 8/4 版本仍 500；D1 库本身正常、life-map-db 与 hsd-cashflow-db 无交叉污染；根因指向 Prisma query-compiler wasm 加载失败——loaded wasm module was undefined，且 .open-next/worker.js 是 8/4 旧文件未随今日 build 更新 → 下轮续查）。

2026-08-05（傍晚）: 报价系统加 Cost Breakdown 成本明细（item 级成本行 + 报价单汇总两版都要）+ 欠款录入流程启动

Decision: ① 报价 item 加成本明细拆解（用户拍板「两种都要」）：item 级——每个 item 下挂多条供应商成本行（如 Ambience 客户 item 1 水泥 = 多供应商散装成本）+ 报价单级汇总（整份报价单成本清单）；实现上新增 CostBreakdownItem 模型（Prisma schema 已加、client 已生成、D1 增量建表 SQL 已写，API/UI 未做）。② 欠供应商款项录入流程：master app Bills/Suppliers（v2 已交付模型）线上 0 条 → 用户逐个报欠款明细，Hermes 录入 Bills 系统（Supplier/Bill/BillItem/BillPayment 全链路）。

Context: 用户回顾成本时发现报价系统只有单个 costTotal 数字，无法拆开「这个 item 由哪几个供应商、各多少钱」；他报价时为防顾客猜到本钱会把成本算成整体，但内部是多供应商协作，需要随时知道「欠谁多少钱」——直接影响工作流效率和成本控制（8/5 14:30 已设「下午记录欠款」提醒）。

What changed: CostBreakdownItem 模型加入 schema.prisma + Prisma client 生成 + D1 增量建表 SQL 已写（glm5.2_cashflow/src/hsd-system/）；开发未完成（18:06 被 life-map 排查打断，下轮续）；Bills 录入尚未开始（等用户报明细）。

HS Knowledge Vault

探索

2026-08-01-05

Decision Log — 2026-08-01-05(1-5日)

2026-08-05（深夜）: 发票 logo 破图修复 + 新需求落地 — 相对路径改绝对 URL

2026-08-05（晚）: 对账机制定案 — master app 应收/应付建模 + Bukku 数据源判读

2026-08-05（晚）: life-map v6.1 PWA 收尾 — 禁用 SW + 关动画换稳定

2026-08-05（凌晨）: 个人语音学习闭环方案（不做 IME；Telegram 语音 + Gemini 转录 + 个人词库迭代）

2026-08-04（晚）: 报价数据源正式迁移 master APP（弃 Sheets 报价）+ GLM 分工限定

2026-08-04（晚）: 纯提醒 cron 全改脚本直发（no_agent），AI 只留知识类任务

2026-08-04（傍晚）: 永久保持 max 模式（adaptive skill 不重启）— 性价比决策

2026-08-04（傍晚）: hsd-system v2 定版 + Cloudflare Worker 部署完成（含三大坑）

2026-08-04（下午）: Maybank MY email 交易通知判死 → 现金流 = AP/AR + 手动余额（用户 15:14 新需求）

2026-08-04（下午）: Hermes fallback 清空（V4 PRO 账单问题）— 省钱铁律强化

2026-08-04（下午）: hsd-system 部署路线 = Cloudflare D1 + @opennextjs/cloudflare（弃 next-on-pages）

2026-08-04（上午）: 现金流管家路线 = 方案A（发票/报价应收）+ GLM5.2 定制系统（Bukku API 不用于实时余额）

2026-08-04（上午）: N8N 自托管值得做（小步）/ ever-gauzy 明确不做

2026-08-04（上午）: 每周 SEO 健康检查 cron 建立（dba43311ad92）

2026-08-04（上午）: AI SEO 工具链 — 吸收 claude-seo 为 Hermes skill（弃 Claude Code 路径）

2026-08-04（凌晨）: 知识同步 cron 增量策略 — 质量优先（用户拍板）

2026-08-03（深夜）: Work Schedule 权威再升级 — GLM 5.2 V6（弃 Antigravity v4）+ 三级备份铁律

2026-08-03（晚场）: Work Schedule 定版 — Antigravity v4 系统为权威（弃 API 自建版）⚠️ 已被 V6 取代（见上条）

2026-08-03（傍晚）: Master 数据库落地 — 全量主档 + filter 视图 + 项目号超链接（IMPORTRANGE 授权解谜完成）

2026-08-03（傍晚）: 装修 Work Schedule 工具选型 — Google Sheets 甘特图模板（弃 Notion/ClickUp）

2026-08-02（晚场）: 人生思维导图托管方案 — Cloudflare Worker + URL 密钥（弃 Google Drive 直开 / GitHub Pages）

2026-08-02（下午）: 人生思维导图改用 vis-network 力导向图 + 报价模板新增 Electrical Work 组与紧凑化规范

2026-08-02: 报价单底部区标准定型 — A 列 + merge A-F + Payment Term 青绿白字 + Bank 完整资料（真实手机号）

2026-08-01（深夜）: 报价模板体系定型 — MASTER v3 全工种组 + 用户原模板为版面基准 + PDF 用户自导出

2026-08-01（深夜）: 开启 Auto-compaction（compression.enabled: true）

2026-08-01: Antigravity CLI 用 PRO 模型 → PTY 交互方案（订阅 8/18 到期前尽量用尽）

2026-08-01: 主力执行切换到 Antigravity CLI（Gemini PRO）— 8/18 前尽量用尽

2026-08-01: Google Workspace 集成选型 → workspace-mcp（121 工具）

2026-08-01: 报价工具弃用 quotation SaaS → Google Sheets 报价系统（HS Design）

2026-08-01（晚）: 报价系统架构细化 → 方案 B（Item 库为核心），ITEM 库 85 item 固化

2026-08-02（深夜）: Gemini 免费层多账号 key 轮换 + fallback 链插入 Gemini（视觉省钱方案）

2026-08-02（深夜）: compression/web_extract 撤出 Gemini 免费层（配额烧尽 → 超时事故）

2026-08-02（深夜）: 报价成本明细悬浮查看 = 单元格 Notes（弹窗替代切 sheet）

2026-08-02（深夜）: 思维导图已完成任务 30 天保留 + 待办事实源联动规则

2026-08-03（早）: 导图待办同步自动化 + 固定 SOP（导图 = 唯一待办来源）

2026-08-03（上午）: 顾客跟进 CRM 定为 Google Sheets + 手动更新模式 + 报价约见面策略

2026-08-03（下午）: 统一 Master 数据库 = 索引 + IMPORTRANGE 连接（方案 B，弃全量迁移方案 A）

2026-08-03（下午）: 跟进表回归 11 列（删 L 状态备注列）+ 「等定金」新状态词

2026-08-05（凌晨）: 语音转录学习闭环制度化 + Google Sheets 退役 + 混合输入模式

2026-08-05（白天）: 新闻播客两步 cron 防撞车 + Windows 脚本全转 .py + life-map 升 D1（方案 A1）+ 报价自动保存

2026-08-05（傍晚）: 报价系统加 Cost Breakdown 成本明细（item 级成本行 + 报价单汇总两版都要）+ 欠款录入流程启动

关系图谱

目录

反向链接