2026-08-16 决策记录（凌晨场）

会话 20260815_204856_895cd86b 21:17–00:17 产生的决策。上一批见 2026-08-15。

1. 全站电话号码统一 01116880145（21:17 用户确认）

用户确认官方唯一号码 01116880145；旧号（+60 11-1082 5313）系早期 AI 做网站时随便写的
32 文件批量替换 + 部署 + 生产 0 残留 + Drive 源同步完成
含义：今后所有对外材料/页面一律 01116880145；出现旧号引用 = 待修 bug

2. 未来文章发布仓库机制（21:27–21:41 定案）

事故：11 篇 2026-09→2027-02 文章提前泄漏到生产（blog 显示未来日期，用户觉得”太假”）
定案：生产只放已到期内容；未来文章统一存 Drive 源 blog/_future_posts/（含 README 发布指引），月份到了才放回 blog/ 部署
sitemap lastmod 禁止未来日期（本次 about/contact 的 8/16 一并修正）

3. 分工铁律再强化（23:25，用户第二次纠正）

Hermes 只做分析 + 派单 + 验收；执行类（改代码/部署/验证/重启）一律整单交 agent
背景：briefing 入口升级 Hermes 亲自动手被纠正（“我只分析+派单，执行全交 agent”）

4. Portal「并排打开」方案 B 定案（23:41，先 B 后 A）

方案 A（master app 内真分屏，需后端代理约 1 天）暂缓；方案 B 先行：portal 加按钮 → 选 2 个 app → 一键弹出两个并排窗口（记住组合）
关键技术事实：所有 app 登录 cookie 均 SameSite=Lax → 跨域 iframe 分屏必卡登录；但 SSO secret 全系同源（master/webwatch 64B 相同）→ 方案 A 的认证桥最大风险已排除
00:17 方案 B 完成通知（验收待续）；用着不爽再上方案 A（两方案不冲突）

5. daily-cost-tracker 停用 + 细分归因版待定（00:07）

用户：每日总额花费在 DeepSeek 官网直接可看且最准 → 无增量价值 → 暂停 cron 0946cb581997（Python 重写版已就绪，可随时恢复）
保留价值点：Agent×任务归因（各域/各任务 token 与花费，官网只有总额）——形态二选一：每日一推 vs 按需查，待用户拍板

6. Prime 系 cron 全部暂停——弃用遗留的烧钱源头（05:47）

背景：用户账单发现每小时固定 ~ $0.03 ；排查 = P r im e 已弃用，但 * * 2 个 LL M 型 cr o n 仍每 5 分钟跑 * * （ 24 h 各 50 次 LL M \approx$ 0.02-0.04/小时，正好对上账单）
定案：暂停全部 4 个 Prime 系 cron——06896f3bfdf5（卡死自动救治，主犯）、860cf76120b5（任务验收播报，从犯）、b7c175658166（Watchdog）、2f9f284289f7（完成通知）；可随时恢复
附带确认：PI 停滞巡检 = no_agent 纯脚本零 token；持续 typing = 主会话被后台通知唤醒
教训：harness 退役时必须一并清理其 cron 体系（Prime 系 cron 在 Prime 弃用后仍白烧了一周）

7. 知识同步频率维持 3h，不降 6h（05:58）

用户提议降频省成本；结论：维持每 3h——成本仅 ~$0.1/天；会话中途崩溃时 3h 风险敞口更小；6h 摘要粒度虽无压力但无必要
明确概念：vault 同步频率与 LLM 上下文压缩无关（压缩按会话长度触发）

8. 知识同步空窗静默优化定案（06:01）

check_new_sessions.py 无新会话时输出 NO_NEW_KNOWLEDGE 标记（原为空串）；prompt 指示 LLM 见标记零分析直接 [SILENT]
收益：省掉模型每次 tick 判断”有无新知识”的推理成本（尤其凌晨 6 点空窗期）；脚本 3400cce6bf0f prompt 已更新

9. 流程纪律：完成通知 = 立即验收 → finish → 自动派发（06:34，用户指出）

用户发现 webwatch 任务 6:19 完成但我没及时验收+finish+派下一个，直到用户提醒才继续——失职
定案：域任务完成通知进来 → 验收通过就立刻接续（finish → 自动派发下个任务），不等用户催；“AI 不需要休息、自动推进”

10. 任务适应三层体系 + UPDATES 机制（06:39 定案）

用户提出任务耦合问题：新任务会连锁影响旧任务细节（master app 加功能 + UI 优化两任务重叠的例子）
旧模型：任务书 = 一次性快照，写死后不回头 → 返工
三层编排：① 新任务与排队任务重叠 → 合并/重写任务书（未开跑随便改）；② 紧急 → --urgent 插队（!URGENT- 前缀）；③ 进行中方向修正 → 每域 UPDATES.md（任务书模板加「每阶段完成后检查 UPDATES.md 吸收修订」，PI 自动吸收，不打断执行 = 软 interrupt）
校准认知：PI = 单任务执行器无自调度器（优先级排序是 Hermes 职责）；用户记忆中的 interrupt/插入 = DSH 模式（常驻 daemon 自管理队列）
已落盘：UPDATES 机制写入 _shared/PI_COMMON.md §6，下一个任务书起生效

11. Briefing 表单定位 + 编号 SSOT（06:46 用户拍板）

表单链接不发客户——briefing form 是用户面谈时自己打开录入的工具（凸显专业），非客户自助
Mr Lee = Kulai 顾客（来源字段不再纠结）
编号以 D1 项目编号为准（SSOT）：D1 查证无 HSP00013 → Drive 文件夹改名 HSP00016 Mr Lee @ Kulai；HSP00013 = 历史别名记入 Company_Graph
逻辑：Drive 编号缺失是历史创建项目时没同步建文件夹导致；D1 = 系统真相源

12. Briefing 独立 Worker 定案（06:51–07:21 落地）

用户 3 需求：① 面谈录入自动同步后台 ② 顾客不会因回退键看到 master app 内部 ③ 衍生独立页面但数据互通
硬伤认知：bf/?key= 挂 master app 同域 → 回退必回 master（同域 history）
正解落地：独立 Worker https://hsd-briefing.ida-czia.workers.dev + 绑定同一 D1（cd009bf4）→ 页面与 master 完全隔离（回退 → about:blank 实测）+ 数据写同一库（互通）；旧链接 302；master app 移除 public/bf/* 静态资源（部署 6b7670f8，回滚 1116cc88）

13. 美术统一：Apple 黑白风格基准（07:18 用户拍板）

方案：PORTAL_THEME_UNIFY_PLAN.md（7 章 212 行，审计全部真实源码）——#5E9E9B/#2D4E52 已是共享品牌色，统一 = 补齐+对齐非从零
用户拍板基准 = Apple 黑白风格（参考 AirPort 主题），不是公司青绿色——按 master app 主题延续到所有 app，各域并行处理（避免数据污染/memory 超载）
4 决策点：teal 只作 accent（正文 2D4E52 对比度 AAA）/ viewer 金色去留待定 / 自动为主手动临时覆盖 / hsdesign.biz 无源码仓库低优先
实施：logo 纯黑版第一阶段（portal/master/webwatch/life-map/viewer，hsdesign.biz 不碰）→ 按路线图分批

14. Prime 全面退役（07:19 用户拍板）

019ffb45 = Prime 遗留 master-app session；3 个 prime-agent daemon（PID 710/716/722）已杀（WSL 侧杀，MSYS kill 管不到 WSL 进程）；webwatch Prime section 移除
至此 Prime 体系全线退役：daemon 杀 + 面板移除 + cron 已暂停（05:47）；以后要用时重启 daemon 即可

15. webwatch Hermes 卡语义：空闲 ≠ 卡机（06:34–07:01）

误报根因：STALE_MIN 红闪逻辑是给 PI 用的（有任务在跑但 jsonl 不动 = 真卡），套到 Hermes 主会话 → 空闲一直闪警告——不合适
定案：Hermes 卡三态 🟢运行中（进程活 + 10min 内有消息）/ ⚪空闲 X 分钟（中性，不警告）/ 🔴进程离线（主机 restart/断网/budget 耗尽一眼可见）；cron「运行中」= 最近 5 分钟有消息（严格窗口），其余「最近运行 X 前」
PI 停滞去误报：进程已退出 = 「完成（待解锁）」绿色中性；进程活 + 停写 = 真卡死仍红

16. 模型统一核查结论：全 PI = deepseek-v4-flash + thinking max（07:05–07:07）

全域 jsonl 1168 条记录全部 deepseek-v4-flash（0 例外）；当前进程实测 --thinking max
6 条 thinkingLevel=high = 8/15 上午盲评 2×2 测试的早期 session（当时同时测 high/max 对比）——盲评后拍板 max，正式派发全部 max

17. VaultBridge 保留 + WOL 放弃（11:23 定案）

手机已走 Drive API 直连 → bridge 不再是手机必需品；保留理由：任何外部 agent 的标准只读入口（不依赖 OAuth token 有效性——token 会过期，bridge 不会）、schtasks 自启零维护 → 双通道冗余常驻
WOL 实测 = 死路：Wi-Fi（Realtek 8851BU USB 网卡）WakeOnMagicPacket = Unsupported（硬件不支持）；有线（Killer E2400）支持但未插网线 → 无网线物理收不到 magic packet
替代：智能插座断电→通电 + BIOS Restore AC Power Loss = Power On（100% 可靠，IDA 已设）；待用户进 BIOS 确认
未登录可 SSH 已确认（sshd/Tailscale Automatic + 防火墙 Any profile + 冷启动 3–5min 就绪）

18. 逆向救援通道定案——PC ⇄ 手机双向 SSH 救援（11:13–11:36 落地）

用户问：手机端 Hermes 卡死 PC 能否跨平台救 → Termux 非沙盒（Android 上真实 Linux 用户态，能跑 sshd）→ 可救
落地：手机 Termux openssh Port 8022（禁密码登录、runit 常驻、termux-wake-lock 保活）+ PC 专用密钥 id_ed25519_rescue_phone（公钥备份 vault env/pc-rescue-key.pub）→ ssh -p 8022 u0_a614@100.124.223.117 PONG 双向打通
边界：Termux 被 Android 整杀则 SSH 也进不去 → 保活兜底（电池优化白名单 / Termux:Boot / 前台服务）

19. watchdog 验收纪律：验收必须核对「改动落在真正在跑的目标」（11:29 教训）

v1 验收失败：PI 把心跳写进 hermes_watchdog.py（属于 Disabled 的 HermesWatchdog 任务），真正在跑的 AgentWatchdog → agent_watchdog.ps1 没有心跳 → 生产盲区原样
教训：声称完成 ≠ 生效；验收先 schtasks 实查计划任务实际命令，确认目标脚本，再验文件落盘 + 备份
v2 修正目标后验收通过（Test-TickHung 600s + 三次真实调度静默 exit 0）

20. OpenClaw 双计划任务清理：禁用旧 OpenClawGateway（10:49）

OpenClaw Gateway（在用，At logon，gateway.vbs）vs OpenClawGateway（旧，14/8 后没跑过）→ 禁用旧任务，消除重启双启动风险（重启场景只拉单实例）

2026-08-16 决策记录（午后场 12:53–15:06）

会话 20260816_105724_c21aeff1（12:53–13:37）+ 20260816_133824_22f82209（13:39–15:06）产生的决策。

21. cost tracker 细分归因版：按需查，不每日推（13:03 用户拍板）

凌晨 #5 遗留问题（每日一推 vs 按需查）用户已选：按需要查就好，不用每日一推
含义：细分归因版（Agent×任务 token/花费）做成按需查询形态，不再考虑每日推送 cron

22. WhatsApp 界面预测试：假 token 不可行 → DEMO 模式（13:08 定案）

用户想先测界面是否成熟，问能否用假 token → fail-closed 设计下假凭证 = 全部请求失败，测不出 UI
定案：DEMO 模式——无凭证时 UI 用内置模拟数据渲染 + DEMO 水印，凭证就位自动切真数据（已派单 whatsapp 域）
顺带拍板：viewer 金色 → Apple 黑白（demo 完成后接力）；master app 全面黑白（已派单）

23. Anne grill door ≠ 日式格栅门——两个独立 project（13:03 用户澄清）

用户纠正混淆：Anne 的 grill door 是直接问做铁的人；淘宝比价 = 日式格栅门（Permas d’Ambience QUO-AMB0002 定价更新用）
教训：报价单/任务不要凭相似主题合并，先确认是同一项目

24. 任务路由定案：默认派 PI max，Prime 收窄（14:51–15:01 用户纠正 + skill 更新）

14:51 用户纠正：watchdog 任务不该派 Prime，任务默认派 PI（域队列 —harness pi）——8/14 版 agent-task-routing skill「改系统→Prime」已过时（Prime/DSH 时代残留）
14:59 用户要求更新 skill → 3 处修改：标题/核心原则、场景分配表（PI 默认；Prime 仅 3 保留场景：已有 daemon 域 send 插队 / PI 失败备选 / 双盲对比对象；DSH 从零量产）、派活链路（enqueue → pi -p —session-id）
教训：skill 是活文档，harness 定案后必须同步（8/15-16 PI 定案后拖到 8/16 下午才改，害我派错一次）

25. Hermes 卡死根因定案：Telegram 网络故障，非内存压缩（14:34 诊断结论）

用户怀疑内存压缩 → 日志实锤：13:12:44 起 Telegram 断线（主路径+备用 IP 全失败、发送重试），12:54 那轮本就重（428.8s/10 API）
判定标准：「inbound message 收到但无对应 response ready」= 卡死（进程活不算数）；14:16-14:28 gateway 启动风暴（10+ 组并存）是症状不是根因
教训：卡死先查 gateway.log 时间线，别先怀疑压缩/内存

26. watchdog 重启方案：增强现有 ps1 + 重新启用，不新建（14:52–14:55 定案）

重大发现：用户已有 agent_watchdog.ps1 v2（11:44 验收心跳版）只是被 OpenCode 禁了任务；rescue_boot.ps1 本意就是止血后恢复守护
定案：增强现有 ps1（补熔断 + Telegram 通知）→ 重新启用 AgentWatchdog 任务；Hermes 手写 watchdog_v2.py 弃用
分工边界（用户 14:50 纠正）：设计分析归 Hermes，执行（修路径/建任务/dry-run/演练）整单交 agent——且演练要杀 gateway，派独立 agent 更安全（不杀自己所在进程）

27. watchdog v3 设计 7 漏洞修正（14:45–14:48 定案）

① watchdog 自身多实例风暴 → 计划任务 MultipleInstances: IgnoreNew；② 日志新鲜度会误杀活进程（空闲 46 分钟零写入实测）→ 只发「疑似假活」通知绝不自动杀；③ 拉起命令以真实启动器为准（Hermes = Hermes_Gateway.vbs，OpenClaw = gateway.cmd）；④ 判定 = 进程+端口，日志软指标；⑤ 熔断/冷却防无限拉起；⑥ 通知链路；⑦ 单实例锁

28. PI 派发 glob 陷阱：`[PI]-` 前缀被 bash 当字符类（14:57 定位）

症状：PI 两次「假完成」——输出上午旧任务简报、jsonl 零写入
根因：TASK=$(ls running/[PI]-*.md) 里 [PI] 被 bash 解释为字符类 → 匹配不到字面 [PI] 文件 → TASK 空 → PI 收到空输入基于旧 session 复述历史
修正：ls running/ | grep "^\[PI\]-" | head -1；教训已写入 agent-task-routing skill 派发链路章节
附带：验证 PI 是否真执行 = 核对 ~/.pi/agent/sessions/ jsonl mtime（文件最后写入时间 > 派发时间才算真跑）

2026-08-16 决策记录（晚间场 15:06–18:09）

会话 20260816_133824_22f82209（15:06–18:09）产生的决策。

29. 子代理选型定案：记忆优先，mini-swe 排除，oh-my-pi 试点（17:15–17:26）

背景：用户这几天连续做 harness 对比烧了不少钱（「不要浪费我的 token」）；Composio 报告（用户自搜「8 Best AI Agent Harnesses in 2026」+ Gemini 总结）vs 官方数据核对
定案：子代理选型标准 = 记忆优先；mini-swe 排除（无跨会话记忆，数据仅客观记录不纳入建议）；oh-my-pi 下一试点（Composio：业务通过率 88% vs pi 72%、每成功成本 $0.52 v s$ 0.57）；Hermes 永远主 Agent（管家）不变
关键校准：「每成功成本」才是用户模式的决策指标（有验收环节，失败要重跑；pi 每次运行更便宜但成功少）
纪律：外部 AI（Gemini 等）的总结/数据先查证官方来源再考量（本轮学到的规矩）

30. 试点缩为「单任务一局定高下」（17:26 用户拍板）

原计划 4 任务对比 → 1 个任务（hsdesign.biz 最新 3 篇文章三语一致性审计，预算 $0.5 内）——省钱：显著更优才切换，打平保持 pi
任务书升级「一局双验」：主验证 pi vs omp 完成度/正确性/成本；副验证 支配链路（SDK/RPC 能否无 TUI 驱动，防 DSH 式坑）+ 预隔离验证（per-project-tagged 记忆互不串扰）

31. omp 架构结论：可被支配 + 预隔离可设计 + compaction 原生（17:32–18:00 查证）

被支配 = 一等公民：SDK（createAgentSession/SessionManager）+ RPC 模式，无需 TUI（vs DSH 的 headless 残缺）；Composio 88% 即自动化驱动实证
预隔离机制：记忆 4 backend（off/local/mnemopi/hindsight）+ omp --profile 独立根目录 + per-project-tagged 分库 → 域隔离 + 跨平台协同可兼得（用户权衡：污染一点点换协同收益，值得）
架构定案：多 profile（每域一办公室）；测试 agent 单独隔离（独立 profile+bank+health-check skill，延续 Prime「隔离+自检」传统）；敏感数据（报价/客户）不进共享 bank
6 漏洞审查（用户要求找漏洞）：A 跨域知识断层 → 任务书强制域摘要；B 测试 agent 越界写 → 沙箱 + 越界检查；C 记忆过期 vs SSOT → 记引用不记快照；D 域 SOP/skill 断层 → profile 预装域 skill；E 记忆膨胀（recall 相关性检索已降级）→ 每周体检；F 并发写竞争 → 域 cwd 物理隔离
三层共享架构：Vault = 唯一共享层（真相源，按需查）→ OMP 域记忆 = 工作缓存（记引用）→ 任务书 = 显式上下文（三段模板）
compaction：会话级原生（含 snapcompact/streaming）；记忆库无自动过期 → 记忆体检每周（用户选频，cron 化，管「过期」非「膨胀」）
落地清单（试点后执行）：每周体检 cron / 任务书三段模板 / profile 预装域 skill / 记引用规范 / 测试沙箱

32. 18:00 research-only 执行 + omp 获胜三步切换预案（17:37–18:09）

用户指令（17:37）：18:00 只做 research 两任务，其他域全部冻结；omp 大概率获胜 → 预案三步：① 所有任务（含原 PI 任务）hand over 给 omp ② webwatch 新项目把 omp 加入监控 ③ 默认 = omp + Hermes，PI 降级非默认
18:00 cron 已改为只跑 research 两任务（其他域不派不 finish）；18:01 手动派发任务 1（cron 未触发）→ 18:09 完成（REPORT_AGENT_HARNESS_RESEARCH.md，含 SWE-bench 双榜 + Composio 体检 10 属实/4 查无）；任务 2（pi vs omp 单任务）排队中
18:00 cron 即使触发也会因 research 域已有进程自动跳过（防重复派发）

33. OMP 试点结果：8/8 全过 + 成本修正（18:09–19:02，晚间场）

复用 8/15 同任务横比法（用户提出，省 token）：kill 初版三语审计任务（proc_416021d7b6be）→ 任务书改写为 8/15 同一基准任务（从零迷你 HTTP 静态服务器，一字不改）只跑 omp → 分数直接横比：PI high 54/54（38min）/ PI max 54/54（47min）/ DSH high 50/50（30min）/ DSH max 58/58（53min）——历史记录在 bench_run_log.md + blind_review/
omp 模式体系：内置 7 agents（task 全能力主执行者 / sonic 低推理机械 / scout / designer / reviewer / security…）+ vibe mode（导演编排多 worker）+ approval mode（read/write/exec 三级审批）——默认主 agent 即全能力，无 DSH 式隐藏 CodeMode → 基准用默认跑 = 公平（不重蹈 DSH「默认 vs CodeMode」覆辙；UPDATES.md 标准通道传达执行中任务）
插队能力实锤（用户关心概念）：RPC 一等公民——follow_up（执行中注入新任务）/ set_interrupt_mode: immediate（立即打断）/ set_follow_up_mode: all（排队）——与 Hermes out-of-band 同级；域队列 --urgent 未来升级方向
试点结果：8/8 功能域（~40 断言）独立复核全过｜4.8min｜$0.026（94% 缓存命中）；预隔离验证 ✅（projA/projB 交叉查询互不串扰）+ SDK 支配链路验证 ✅（json mode / 事件流 / memory off 对照）
成本修正（用户质疑成立，教训）：初版报告「成本一个数量级更低」= 误报（没挖历史成本）→ 挖出 8/15 真实成本：PI high $0.0397 * * / P I ma x * *$ 0.0542（jsonl usage.cost 层级）/ DSH high $0.1077 * * / D S H ma x * *$ 0.1625（usage chunks 聚合）→ OMP 便宜 1.5-6× 而非数量级；速度 5-10× 但 thinking 配置不同 → 补跑同配置一轮再拍板（已写入 REPORT_OMP_BENCH.md 修正版）
交接清单定稿 bench/omp_handover_checklist.md（5 阶段 + 红线）：P0 报告验收+用户拍板 → P1 omp_run 封装/域 profile/测试沙箱 → P2 默认 harness 改 omp / webwatch 加面板 / 记忆 backend → P3 任务书三段模板 / RPC 插队 / 会话巡检 / 每周体检 → 等拍板

34. OMP 横比作废 + BENCH-HEAVY 正式重跑（22:39–00:05 深夜场，用户三质疑定调）

任务不对等 = 首轮横比作废（用户质疑全中）：OMP「8/8 全过 4.8min $0.026」跑的是迷你 HTTP 服务器（小任务），8/15 盲评跑的是 BENCH-HEAVY-20260815 装修公司业务管理系统（14 实体/15 表/54 用例大型任务）——不同任务不可横比，§33 结论（成本 1.5-6×、速度 5-10×）全部失效；教训：横比前先核对任务书原文——本次从 8/15 session jsonl 提取原始任务书 3,730 字存档 bench_heavy_20260815_original.md
8/15 盲评官方分数找回（评分机制确认存在）：skill agent-benchmark-blind-review 内记录——PI max 67 分 $0.054/47 min 、 P I hi g h * * 58 * *$ 0.040/38min、DSH high 59 $0.057/30 min 、 D S H ma x * * 57 * *$ 0.099/53min → 当时结论：PI max 值得（+9 分）、DSH max 不值（-2 分）→ 默认派发 PI max；流程复刻 = 匿名打包（OMP + 8/15 四路）→ 同一个 Prime agent 干净 session 当考官（用户指定，标准统一）→ 8 维 rubric 每项带文件:行证据 → REVIEW_REPORT.md
公平配置定案（用户裁决：配置不当 ≠ 能力）：omp 默认 maxTokens=32K 截断 thinking=max 思考流（stopReason: error+length，前两次跑烧 $0.0854）→ 按 DeepSeek 官方文档（V4-Flash-0731：CTX 1M / MAX OUTPUT 384K）设 maxTokens: 393216 + --effort max（双轴：effort=强度 thinking=模式，issue #7380）→ 与 8/15 PI max 同档极限配置；计时两段式：环境准备（一次性，不计入对比）vs 任务执行（唯一对比指标）；本次环境准备 68min（22:46-23:54），任务执行 23:54 起算
切换判据（用户预期，写入交接清单）：OMP 盲评 > 67 分 + 成本 $0.05 - 0.1 级 \to * * 全面交给 O M P * * （ H er m es 直接支配： o m p_{r} u n 封装 + 域 p r o f i l e ， P I 退役非默认备用）；分数接近则讨论；用户授权 384 K 极限（要知其极限，成本可控$ 0.05-0.25/请求）
webwatch OMP 可视化 = 切换后第一任务（已提前并行执行）：用户 23:46 等不及 → 立即派 PI [PI]-20260816-2350-webwatch_omp_ui.md（proc_e8dc115ffb47）；要求：OMP 卡片实时性优先（PI 将被取代）、research「空闲/进行中」两源不一致修复、UI 全流程走查、最新聊天消息默认展开其余折叠（23:55 追加）
定时跟进 cron 0d9c1c824e13（OMP评测定时跟进，every 15m × 10，deliver origin）：部署配置耗时过长，用户要求不再出差错；四态判据（进展/卡住/完成/异常）自动播报
OMP 血缘（部分实锤）：porting-from-pi-mono.md = OMP 源自 pi-mono；pi 正仓 GitHub 404；Prime 血缘未查完（回复被打断）→ 待续

HS Knowledge Vault

探索

2026-08-16 决策记录（凌晨场）

2026-08-16 决策记录（凌晨场）

1. 全站电话号码统一 01116880145（21:17 用户确认）

2. 未来文章发布仓库机制（21:27–21:41 定案）

3. 分工铁律再强化（23:25，用户第二次纠正）

4. Portal「并排打开」方案 B 定案（23:41，先 B 后 A）

5. daily-cost-tracker 停用 + 细分归因版待定（00:07）

6. Prime 系 cron 全部暂停——弃用遗留的烧钱源头（05:47）

7. 知识同步频率维持 3h，不降 6h（05:58）

8. 知识同步空窗静默优化定案（06:01）

9. 流程纪律：完成通知 = 立即验收 → finish → 自动派发（06:34，用户指出）

10. 任务适应三层体系 + UPDATES 机制（06:39 定案）

11. Briefing 表单定位 + 编号 SSOT（06:46 用户拍板）

12. Briefing 独立 Worker 定案（06:51–07:21 落地）

13. 美术统一：Apple 黑白风格基准（07:18 用户拍板）

14. Prime 全面退役（07:19 用户拍板）

15. webwatch Hermes 卡语义：空闲 ≠ 卡机（06:34–07:01）

16. 模型统一核查结论：全 PI = deepseek-v4-flash + thinking max（07:05–07:07）

17. VaultBridge 保留 + WOL 放弃（11:23 定案）

18. 逆向救援通道定案——PC ⇄ 手机双向 SSH 救援（11:13–11:36 落地）

19. watchdog 验收纪律：验收必须核对「改动落在真正在跑的目标」（11:29 教训）

20. OpenClaw 双计划任务清理：禁用旧 OpenClawGateway（10:49）

2026-08-16 决策记录（午后场 12:53–15:06）

21. cost tracker 细分归因版：按需查，不每日推（13:03 用户拍板）

22. WhatsApp 界面预测试：假 token 不可行 → DEMO 模式（13:08 定案）

23. Anne grill door ≠ 日式格栅门——两个独立 project（13:03 用户澄清）

24. 任务路由定案：默认派 PI max，Prime 收窄（14:51–15:01 用户纠正 + skill 更新）

25. Hermes 卡死根因定案：Telegram 网络故障，非内存压缩（14:34 诊断结论）

26. watchdog 重启方案：增强现有 ps1 + 重新启用，不新建（14:52–14:55 定案）

27. watchdog v3 设计 7 漏洞修正（14:45–14:48 定案）

28. PI 派发 glob 陷阱：[PI]- 前缀被 bash 当字符类（14:57 定位）

2026-08-16 决策记录（晚间场 15:06–18:09）

29. 子代理选型定案：记忆优先，mini-swe 排除，oh-my-pi 试点（17:15–17:26）

30. 试点缩为「单任务一局定高下」（17:26 用户拍板）

31. omp 架构结论：可被支配 + 预隔离可设计 + compaction 原生（17:32–18:00 查证）

32. 18:00 research-only 执行 + omp 获胜三步切换预案（17:37–18:09）

33. OMP 试点结果：8/8 全过 + 成本修正（18:09–19:02，晚间场）

34. OMP 横比作废 + BENCH-HEAVY 正式重跑（22:39–00:05 深夜场，用户三质疑定调）

关系图谱

目录

反向链接

28. PI 派发 glob 陷阱：`[PI]-` 前缀被 bash 当字符类（14:57 定位）