原则与记录

第3章 · 笔记 3

笔记 3

2026-08-29 · [阿普] break_glass.py 增加 target 别名 default→main（正生问「乾婆 profile 不是 default 吗」） · 乾婆全局配置历史上有 default/main 两种叫法（SOUL 记忆用 default、break_glass 用 main），break_glass.py 的 target 映射只认 main，用 default 调用直接报「未知目标」 · 入口 args[1] 归一化：if len(args)>1 and args[1]=="default": args[1]="main"，覆盖 read/set/restore/restart/backups 全部子命令；验证 read default 正常输出乾婆配置 · ①同一实体多叫法是脚本间协议漂移的典型来源，别名归一化在入口一处解决；②profile 名与记忆/文档叫法不一致时优先统一别名而非改文档 · 🔍本地验证：read default → 乾婆 config.yaml 输出正常；.pyc 已清 · 乾婆模型切换

2026-08-29 · [阿普] token_daily_report.py v5→v6：智谱费用按 key 分开统计——账单接口是账户级的，按 key 各查会重复统计（t_9ed3a5f4） · 乾婆 8/29 切智谱 GLM-5.3-Flash 用独立专用 key，正生要求两 key 费用分开统计；首版按「每个 key 各调一次账单接口」实现，实测两 key 返回费用完全相同（各 ¥4.61）——智谱 expenseBillList 是账户级接口：同账户任意 key 鉴权返回同一份账户全量账单（两 key 各查仅相差查询间隔内新增行），按 key 各查=同一账单重复计入 · 重构为「账户账单只查一次 + 按明细行 apiKey 字段分组」：智谱 key 格式为 id.secret，账单明细行 apiKey 字段=key 的 id 部分（实测 167fd803…=阿普、88be9936…=乾婆对应关系验证通过）；query_zhipu_daily 增加 key_id_map 参数按行分组，未登记 apiKey 归入 _unknown 桶（非零时输出「智谱-未登记key」并提示检查 ZHIPU_KEYS 配置，保证分组合计=账户总费用）；新增 ZHIPU_KEYS 配置（显示名/env路径/变量名/日志tag，key 值从 .env 读取不硬编码）；新增 --dry-run（验收模式：不写 OpenRouter 快照/wiki/日志）与 --date（仅限 --dry-run 搭配，正式运行固定统计昨天）；stdout/wiki 条目/日志行全部按 key 分开展示（zhipu_apu/zhipu_qianpo 字段） · ①「接口按 key 鉴权」≠「接口按 key 返回数据」——鉴权粒度与数据粒度是两回事，多 key 分账需求必须先实测两 key 返回是否相同再定方案；②智谱无公开 usage API，账单接口是用户中心前端挖的，明细行 apiKey 字段是唯一 key 级区分依据；③验收模式（--dry-run）是带状态副作用脚本（快照差分/wiki 幂等标记）的标配，验收跑正式数据不污染生产状态 · 🔍实测：两 key 各查返回 1110 行仅差 6 行（查询间隔新增）；按 apiKey 分组 08-29 阿普 ¥4.27/1032次、乾婆 ¥0.50/51次，合计=账户总费用；08-28 乾婆 key 未启用日正确显示无账单；--date 无 --dry-run 正确拒绝；dry-run 后 OpenRouter 快照 mtime 未变（无污染） · t_9ed3a5f4

2026-08-29 · [阿普] 智谱 400 第二层根因：request_dump 实录请求体 reasoning_effort=medium——真正生效的是 agent.reasoning_effort（CustomProfile 写成顶层字段），providers.zhipu.extra_body.reasoning_effort 整块不进请求体（连 temperature 都没有）。第一次修复只改 extra_body 层+重启，未改 agent 层，故复发 · ①两处 reasoning_effort 是覆盖关系：agent 级 > provider 级 extra_body；②CustomProfile（provider=custom 走的 profile）只把 agent.reasoning_config 写成顶层 reasoning_effort；③验证配置必须走与 gateway 相同代码路径（load_config→resolve_reasoning_config→build_api_kwargs_extras），仅 yaml 回读不够；④验证脚本注意 HERMES_HOME 继承陷阱（apu shell 里会读错配置） · 🔍request_dump_20260828_121504 实录 + 源码链路（transports/chat_completions.py L836 overrides 合并、plugins/model-providers/custom/__init__.py L54-78 顶层写入、hermes_constants.py resolve_reasoning_config） + 修正后全链路验证通过 · 乾婆模型切换

2026-08-29 · [阿普] 新增 qianpo_switch_model.sh：乾婆 glm-5.3-flash ↔ deepseek-v4-flash 一键切换（正生需求） · 首次修复教训固化：脚本内置强制备份→curl冒烟→两层reasoning参数写入→yaml断言→全链路验证（gateway同路径）→break_glass重启→回滚命令。zhipu↔deepseek 真实往返切换 2 轮 + --rollback 各验证通过 · 备份命名 config.yaml.qianpo-<旧模型>-<时间戳>-backup；温度/档位定值 high/0.7；回滚后自动重启+验证 · 🔍2轮往返切换+回滚实测，gateway 飞书重连正常、零400 · 乾婆模型切换

2026-08-29 · [乾婆] agent_bus 废弃清剿漏掉 gateway 插件层：agentbus-context-inject 空转 27 天后由正生质询发现 · 8/2 大清剿按「技能+脚本+db+launchd plist」四层清单清理，漏了 gateway 插件目录——agentbus-context-inject（pre_gateway_dispatch hook，每次用户发消息前从 agent_bus.db 读未读 kanban-events 注入消息头）继续挂在 gateway 上。因写入端已废、db 是 0 字节空库，插件每次查空、静默空转，无功能损害但正生看到「📬 摘要附在消息末尾」现象后质询才暴露。8/29 已删插件目录+db 三文件，网关进程验证正常 · ①组件废弃清理清单必须按「所有可能的挂载层」枚举：脚本、cron、launchd、db、技能、插件/gateway hook——漏一层就留一个静默僵尸；②「查不到消息」≠「无害」：空转插件每次 dispatch 白跑 hook，且让用户困惑（本次正是质询触发）；③废弃系统的暴露靠用户偶然发现而非自动巡检，可在每日巡检加「已废弃组件挂载层全扫」检查项 · 🔍实测：删除后 plugins 目录 grep 归零、db 文件消失、主/泡影网关+dashboard 进程正常 · 无看板任务（乾婆自做小操作，正生授权）

2026-08-29 · [阿普] wiki_read_queue.py --conflict-check 增加状态标注剥离：引用行含 ⛔/📦/superseded/archived 即跳过（t_fdce2716） · T7 跨页矛盾检测连续三天命中 30+（8/27 30→8/28 35→8/29 35），人工核实发现 35 处中 30+ 已带状态标注——「active 页引用已废弃/归档页但行内已标注」是设计使然的提示项，不是待处置冲突，机械命中导致精读噪音大、人工核实成本高 · ①新增 STATUS_ANNOTATION_RE（⛔/📦/superseded/archived 词边界）+ _line_has_status_annotation()；②「active引用非active」检测改为逐行处理：围栏逐行跟踪 + 行内反引号逐行剥离（不做跨行 re.sub，遵守 wiki-review-script-maintenance 反引号逐行等长配对教训）；③仅对「该行已带标注」生效，未标注引用照报（真冲突不漏检）；④文本/JSON 输出均增加 skipped_annotated 计数，剥离生效可验证 · ①「只提示不判死」的检测项若长期高位命中，应区分「已人工确认（行内标注）」与「待处置（无标注）」两层，否则噪音淹没信号；②测试数据里描述文本含 superseded/archived 字样会被判定器当标注剥离——构造测试页时描述文本不能含状态标记词；③回归测试用 /tmp 构造页（同名页冲突/取代链断裂/未标注引用/代码块/历史沿革区截断全覆盖），零污染生产库 · 🔍生产基线 35→0（skipped_annotated=35 与命中数吻合，无多剥无漏剥）；/tmp 回归 6 项断言全过；JSON 模式 exit 1 语义保留；__pycache__ 已清理 · t_fdce2716

2026-08-29 · [阿普] wiki 矛盾检测基线快照 + SQLite 裸操作 schema 版本保护落地（t_3f1a0e5c，R-0829-01+P-0721-05） · ①wiki_mechanism_selfcheck.py E 项每次全量重报 30 条已核实存量矛盾，周 Lint 无法区分新增；②泡影 3 个脚本（check_kanban_wiki_gaps/check_readiness/deliver_podcast）裸 sqlite3 写看板库，kanban.db user_version=0 无版本保护，schema 变更后会静默写脏数据 · 任务A：wiki_read_queue.py --conflict-check 新增基线机制——fingerprint=SHA-256(矛盾类型+详情)，基线文件 ~/.hermes/state/wiki_conflict_baseline.json（WIKI_CONFLICT_BASELINE 环境变量可覆盖），union 推进（每次运行把当前指纹并入基线，「新增」=自上次运行以来新出现），输出分「存量 N（基线内）/新增 M（基线外）」两段，JSON 输出加 total/existing/new/baseline_exists 字段；selfcheck E 项改走 --json 消费（解析失败回退旧文本正则），存量-only 时 ⚠️ 不算硬失败（exit 0）、有新增才 ❌（exit 1）。任务B：3 脚本加 check_kanban_schema_version() 门禁——启动读 PRAGMA user_version，期望值 1，0=自举写 1，其他非期望值 fail loud（gaps/readiness exit 2，deliver 抛 SchemaVersionMismatch 由 __main__ 捕获 exit 2，detect_show_from_date 的 except Exception 加 re-raise 防吞）；kanban.db 已置 user_version=1（hermes 框架源码零处使用 user_version，无冲突） · ①「全量重报」型检测项加基线快照是降噪标准解法，fingerprint 用「类型+详情」全量串而非仅路径对——status 值变化（如指向页从不存在变 archived）会换指纹照报新增，不漏检；②基线推进用 union 而非「只存首次快照」：否则存量矛盾永远报新增，违背周 Lint 只看新增的初衷；③裸 SQL 脚本加 user_version 门禁 = schema 变更的保险丝，自举写 1 让存量部署零迁移成本；④吞异常的 except Exception 前必须 re-raise 自定义异常，否则 fail loud 门禁被静默降级；⑤测试数据陷阱：取代链检测只认 wikilink 格式，中文引号「X」不算横幅指向（本次测试首跑漏检即此因） · 🔍沙箱 wiki 三步测试（首次生成基线→二次存量0新增0→造新矛盾识别为新增→矛盾消除→status变化新指纹→基线损坏容错）+ 生产回归（75 页 0 矛盾、selfcheck E 项 ✅、gaps/readiness/deliver 正常路径 exit 0、模拟 v=2 三脚本全部拒绝执行 exit 2、v=0 自举写 1、--help 不触发门禁）+ py_compile 5 文件全过 · t_3f1a0e5c

2026-08-29 · [阿普] 质量门禁交付声明标准化：正则盲扫退役改读 metadata 结构化字段 + 通知/评论双层去重（t_1389ff35） · 质量门禁对「未闭环任务」「延展任务」反复误判：已声明延展的任务被当未闭环报、同一异常重复推送飞书/评论刷屏 · 根因是 complete_quality_check.py 用正则/关键词盲扫自由文本（summary/result），无法区分「已闭环的延展任务」和「真未完成的待办」——文本语义判断是死路，必须让 worker 输出机器可读声明 · 三方对齐改造：①create_task.py 建卡时 body 末尾幂等注入【交付声明规范】固定段（DELIVERY_SPEC_MARKER/DELIVERY_SPEC_TEMPLATE，播客链同样注入）；②complete_quality_check.py check_unclosed_suggestions 新任务路径退役正则盲扫，改读最近 completed run 的 metadata JSON（extended_tasks/decisions_pending/deliverables 三字段：缺任一→「格式缺失」flag 转人工 fail-safe；decisions_pending 非空→「待拍板」flag；extended_tasks 非空=已声明延展不算未闭环），历史任务（body 无标记）保留关键词扫描降级路径；③飞书通知按 task_id+flag类型 去重（.notified_flags.json，24h 清理，发送成功才记录）；④quality_flag_comment.py 补任务级评论去重（原 .json.processed 只做文件级，同 flag 出现在不同批次文件会重复发） · ①「文本语义判断」类误判的治本位在「结构化声明」而非「更精细的正则」——让数据生产方（worker）按格式输出，消费方（门禁）只读字段；②新旧任务判别锚点用 body 内标记而非时间戳（建卡时固化，可靠）；③fail-safe 方向：metadata 缺失不自动通过，宁多人工不误放行；④终端显示层脱敏陷阱实录：grep 输出中 Bearer * 是工具对 token 模式的显示脱敏，磁盘文件实际是 Bearer {token}——本次误判「token 被改坏」折腾两轮，教训：显示层含 * 遮罩时先用 Python repr() 读原始字节再下结论，勿把显示脱敏当文件内容 · 🔍32 用例 dry 自测全过（注入幂等/三字段结构化判断/格式缺失 fail-safe/降级路径/handoff 白名单/去重 round-trip/24h 清理/临时库评论去重）+ 三脚本 AST/py_compile 通过 + create_task.py 交互流实测注入命中 · t_1389ff35

2026-08-28 · [阿普] Mnemosyne P2 治理落地：13 条噪音清理 + memory_type 回填 1035 条（t_0a25723c） · 体检报告（t_5645b77e）遗留 P2 两项：①5 组 13 条零信息重复条目（-/Nothing to save./「用户说了一个字：\"好\"。」等 consolidation 摘要无信息量系统消息的产物）②memory_type 94.5%（3160/3359）unknown，recall(memory_type=) 过滤无效 · ①P2-1 删除对齐官方路径（beam.py:7920）：vec_episodes（vec0 表按 rowid 对齐主表，无 memory_id 列）+ memory_embeddings（按 memory_id）+ episodic_memory 三表同删，FTS trigger em_ad 自动同步——只删主表会留孤儿向量；②P2-2 实测推翻「回填成本高」前提：classify_memory() 是零成本 regex（3160 条仅 0.73s），且写入侧自 mnemosyne 3.15.1（8/10 安装）起已内置分类自动生效，3160 条 unknown 全是历史存量；③🔴 0.3 置信度陷阱：classify_memory() 无 pattern 匹配时返回 fallback 默认值（短文本→fact 0.3/长文本→context 0.3，typed_memory.py:242-247），中文内容几乎不匹配英文 regex 会大量落入——回填必须只取 confidence ≥0.5 的真实分类，0.3 fallback 保持 unknown，否则类型过滤被兜底猜测污染 · ①13 条已删（episodic 3407→3394，FTS/vec 同步验证通过）；②1035 条 ≥0.5 真实分类已回填（unknown 3160→2125，剩余全是 0.3 fallback=正确状态），beam.recall(memory_type=) 过滤实测纯净；③recall 过滤链三层两层有缺口：beam 层支持、顶层 memory.py recall() 签名无此参数、hermes_memory_provider recall_kwargs 不透传——按类型过滤目前只能直接用 beam.recall()，打通 Hermes 侧需上游 patch（未做，交乾婆决策） · 🔍删除前后三表行数对比+过滤纯净度实测（error/preference/decision/instruction 四类型零混入） · t_0a25723c

2026-08-28 · [阿普] 一次性释放 cron exit 127（裸 hermes 不在 no_agent PATH）→ 手动补释放 + audit_cron_scripts 新增裸调用检查（t_5358487c） · 8/27 22:05 release_t_0a25723c.sh 退出码 127：no_agent cron 执行环境 PATH 精简（/usr/bin:/bin:/usr/sbin:/sbin），脚本 L4 裸命令 hermes 不在 PATH（实际 ~/.local/bin/hermes）；一次性 job 失败后 enabled=False 无重试 → 释放动作永久丢失，t_0a25723c 滞留 scheduled 一天 · 手动 ~/.local/bin/hermes kanban unblock t_0a25723c 补释放（scheduled→ready 实证）；删除残留 job cd481e1187fe（需 HERMES_PROFILE=default + HERMES_HOME 显式）+ 一次性脚本；audit_cron_scripts.py 新增 audit_no_agent_script_paths()：Python 脚本 AST 解析只查真实执行点（subprocess/os.system 系），shell 脚本逐行正则跳注释，裸调用 CLI（hermes/brew/node/npm/ffmpeg/lark-cli）报错提示绝对路径 · ①no_agent cron 脚本内调 CLI 一律绝对路径（~/.local/bin/hermes），正则全文匹配会误报 docstring/注释（首版 72 处误报全为文档文本），Python 必须走 AST 执行点分析；②一次性 cron 失败无重试=动作永久丢失，关键动作失败要靠巡检兜底；③hermes cron remove 在 agent profile 下找不到全局 job，需 HERMES_PROFILE=default + HERMES_HOME=/Users/mac/.hermes 双显式 · 🔍9 用例单测（裸列表/绝对路径/docstring/os.system/变量命令/shell=True/裸shell/注释/agent job）全过 + 真实环境 72→0 误报 + 抽查 kick_stranded/daily_briefing/kanban_event_collector 实际调用均绝对路径无漏检 · t_5358487c

2026-08-28 · [如花] 读音替换层「觉→绝」兜底规则误伤「妄觉」为「妄绝」（t_380497bb） · Day38 阿如说故事脚本中「那是妄觉」被 pronunciation_substitution 替换为「妄绝」——「妄觉」是佛学术语（wàng jué，虚妄觉知），不在 glossary 保护词表，命中「觉→绝」兜底规则 · glossary 保护词表只有常见词（本觉/觉性/圆觉/自觉/睡觉/直觉等），漏了「妄觉」；兜底规则「觉→绝」对未保护词一律替换，无法区分佛学术语 vs 日常词 · ①buddhist_glossary.md 新增「妄觉 · 妄觉」保护行；②重跑 tts_preprocess_pipeline 验证替换统计「妄觉(1次) → 妄觉」不再误替换，grep 确认产物无「妄绝」 · ①新佛学术语出现时若与兜底规则冲突，必须先补保护词再跑替换层；②替换统计「X(2次)→Y」是匹配计数非替换成功数，以产物 grep 为准 · 🔍重跑替换层「妄觉(1次)→妄觉」+ grep 无「妄绝」 · t_380497bb

2026-08-28 · [如花] tts_postcheck.py 开头静音验证 RMS 未归一化误判 FAIL（t_4eafacad） · 讲经说法合成后跑 tts_postcheck.py，开头 1s RMS 报 6.6dB「非静音」FAIL，但 astats 实测 -36.58dB、silencedetect 1.003s 静音、波形 0-0.8s 全零——三工具矛盾 · 脚本 RMS 计算 20*log10(rms) 未除以 16-bit 满幅 32767：静音段 raw RMS≈2.1 → 6.6dB，而正确 dBFS = 20*log10(2.1/32767) ≈ -83.9dB；判定阈值 -40dB 永远过不了 · tts_postcheck.py 修复：rms_db = 20 * math.log10(rms / 32767.0 + 1e-10)（2026-08-28 t_4eafacad），修复后重跑开头静音验证通过 · ①RMS→dBFS 必须归一化满幅，20*log10(rms) 只适用于浮点[-1,1]音频；②验证脚本报 FAIL 先自查计算口径，用 astats/silencedetect/波形三工具交叉验证再判定音频问题 · 🔍astats RMS=-36.58dB + silencedetect silence_end=1.003s + 逐 100ms 波形 0-0.8s 峰值=0；修复后 tts_postcheck 重跑 ✅ · t_4eafacad

2026-08-28 · [阿普] buddhist_podcast_launcher.py step03 f-string 未转义花括号 NameError，佛学建链 Day38 差点断链（t_436e8a0a） · 8/28 00:58 佛学建链 dry-run 崩溃：build_body_step03 L369 f-string 中字面文本 {补搜ID} 被 Python 当变量插值 → NameError: name '补搜ID' is not defined，10 步链在第 3 步就建不出来 · 8/26 16:31「防调度死锁」修正引入——教子代理写 kanban_block reason 的说明文字里写了 {补搜ID} 占位符，位于 f-string 内未转义；8/27 AI 日未触发佛学建链，bug 潜伏 36h，8/28 04:00 cron 统一播客入口（run_daily_podcasts_safe.sh --live）首次撞上前被紧急修复 · {补搜ID} → {{补搜ID}}（f-string 双大括号输出单大括号，保留给子代理看的占位符语义）；全文件 grep 排查确认仅此一处未转义（676 行三元表达式为合法用法，398 行 {{版本号}} 已正确转义） · ①f-string 内写「给子代理看的模板占位符」必须用 {{}} 转义，字面花括号是 NameError 地雷；②确定性脚本的 body 构建函数改动后应立即跑一次 --dry-run 验证，不能等下一次定时触发才暴露（本次潜伏 36h，距 04:00 生产触发仅 3h） · 🔍本地验证：build_buddhist_chain.sh --dry-run 完整跑通，10 步 body 全部构建成功（step03 body=878 chars），Day38（自动计算）正确，EXIT=0；验证日志 /Users/mac/正生的播客/.deliverables/t_436e8a0a_step03_NameError修复_dryrun验证.log · t_436e8a0a

2026-08-28 · [阿普] check_api_health.py v4.1：代理(GH) 瞬时抖动重试 + GUI 文案条件化 + port_ok 元组赋值 bug 修复（t_9be54e7e） · 8/28 智囊团告警实况：代理(GH) 一次 SSL 握手抖动（UNEXPECTED_EOF, 5024ms）即触发「需在 GUI 下启动 SpeedCat_Lite」断头报警——7892 端口明明在监听，文案却让去 GUI 启动 · 三层叠加：①代理(GH) info 级探测无重试，瞬时抖动直接进冷却+报警；②文案 else 分支固定输出 GUI 提示，与实际故障状态（端口在监听）不匹配；③隐藏 bug：main() 中 port_ok = _try_switch_node() 把 (bool, dict) 二元组赋给 port_ok（恒 truthy），端口真挂时消息头误显「监听中」、SC_DOWN 分支永不触发 · ①代理(GH) 失败后立即重试（第1次不等待，后续间隔 12s，共 3 次尝试 GH_RETRY_ATTEMPTS/GH_RETRY_INTERVAL 常量），全部失败才报警——不复用 FishAudio 切节点模式（Fish UP 说明链路是好的，切节点会打断正常服务）；②GUI 文案条件化：if not port_ok 独立条件行（不与 critical 分支互斥），端口在监听时改用「节点出口异常，建议切节点」文案；③port_ok, _ = _try_switch_node() 解包修复；④报警前 port_ok = check_port() 刷新实测状态防 heal 循环后文案错位 · ①「函数返回元组赋给 bool 变量」是静默逻辑炸弹——恒 truthy 让下游所有 bool 判断失真，review 时对 x = f() 且 f 返回 tuple 的赋值要查解包；②告警文案必须与实测故障状态绑定（报警前刷新端口状态），不能写死在 else 分支；③info 级探测也要有抖动重试，单次失败≠持续故障（与 healthcheck-script-design 技能「短暂空窗 vs 持续故障」原则一致） · 🔍本地验证：mock 三路径测试 6/6 通过（抖动自愈静默 0 告警+GH 探测 2 次；连续失败 1 告警+新文案+12.2s 重试节奏；端口不通 GUI 文案出现）；生产回归真实运行 exit 0 静默；py_compile 通过；测试后 pyc 清理+冷却文件 mtime 恢复 · t_9be54e7e

2026-08-28 · [阿普] 未闭环建议检测加 handoff 白名单——「待办：请乾婆验收」类管线措辞误报根治（t_0103f5f1，t_ca3699bd 延展） · pattern_detector「未闭环建议」第三类 false positive：写稿任务 t_6dbd5715 result「待办：请乾婆验收」（标准交付流转）+ 固化任务 t_1deaca44 result「建议少用」（分级表描述措辞）被 UNCLOSED_KEYWORDS 宽泛词误伤；前两轮修复只覆盖「创作蓝图」标题过滤，本次两事件标题均不含该词，过滤失效 · UNCLOSED_KEYWORDS 宽泛词「待办」「建议」无法区分「跨代理管线 handoff 措辞」与「真未闭环建议」；标题级过滤（创作蓝图）覆盖面不足，result 措辞级才是根治位 · ①两条链路（complete_quality_check.py check_unclosed_suggestions + task_evaluator.py check_unclosed）加白名单正则 待办[：:]\s*请，检测前 sub 替换为 [handoff] 占位符（防残留「待办」字样误命中），同文本其余真未闭环关键词仍检测；②t_1deaca44「建议少用」白名单不覆盖，属分级表一次性事件按任务 body 判定豁免不改代码；③豆蔻侧已固化「交付 result 措辞纪律」（podcast-writing-guide：写稿交付改「已交付，请乾婆验收」） · ①「待办：请X」是跨代理 handoff 协议措辞（写稿→乾婆验收→解锁下游 TTS），与「待办：还需要补充」类真未闭环的区分位在「请」字——白名单用措辞级正则而非标题级过滤才治本；②检测逻辑修改选「剔除后检测」而非「命中后跳过」，保证混合文本中真未闭环不被白名单连带放过；③改检测类脚本必须用真实事件 result 做回归（本次 4 测试全过）+ 真实跑 collect_rolling_7d() 确认归零 · 🔍本地验证：白名单正则 grep 确认写入两个生产脚本（非 deliverables 副本）；真实事件回归 4/4 通过（t_6dbd5715 待办跳过/混合文本真未闭环仍检测/纯 handoff 归零）；collect_rolling_7d() 实跑 doukou 列表 t_6dbd5715 消失仅剩 body 预判豁免的 t_1deaca44；无其他模块导入两脚本、无 .pyc 缓存，改完即生效 · t_0103f5f1、t_ca3699bd

2026-08-28 · [阿普] Jetsam 事件定性：knowledgeconstructiond 单进程超限被杀，非系统内存压力，与 Hermes/播客链无关（t_d2f3bd63） · 8/22-8/28 六天内 5 份 JetsamEvent 报告（bug_type 298，reason=per-process-limit），8/27 乾婆日志承诺「再现就建任务排查」，8/28 00:11 再现触发本任务 · 全部 5 份被杀进程均为 knowledgeconstructiond（Apple Intelligence 知识构建守护进程），rpages 960-1017（约 15-16MB）超该进程 per-process-limit 被杀；事发时系统 free 2.7-4G、compressor 2.2-4.2G 无恶化趋势、当前 memory_pressure 82% free——系统级无压力；appleIntelligenceStatus state=unavailable（regionIneligible，中国区不可用），被杀的是未启用功能的后台进程自身超限 · 无需干预，结论留档；不限制进程、不改配置（系统进程自愈重启，killDelta 后自动恢复） · ① macOS Jetsam 报告先分两类：per-process-limit=单进程超自身限额（系统无压力，只看被杀进程自身）vs 系统级压力（vpages 超限/compressor 告急），处置动作完全不同；② 被杀进程名是相关性判断第一要素——knowledgeconstructiond 是 Apple Intelligence 系统进程，与第三方应用无关；③ .ips 解析要点：reason 字段在 processes[] 数组内带 reason 的条目里（不在顶层），进程表是 list 非 dict，pages 字段部分条目为 null 需容错 · 🔍5 份报告全量解析（8/22 05:25、8/23 07:58、8/25 13:42、8/27 04:41、8/28 00:11）被杀进程全部 knowledgeconstructiond；memoryStatus 五次对比无恶化趋势；appleIntelligenceStatus 两份均 unavailable；当前系统 82% free · t_d2f3bd63

2026-08-28 · [阿普] 写稿校验 doukou_script_check.py FILENAME_PATTERN 补版本号分组 + metadata.day 归一化（t_110bc207 Bug1） · 佛学三场景写稿交付文件名实测形态为「说-Day38-v1.md」（带版本后缀），修复前缀收录后编号提取 (.+?)(\d+) 仍把 v1 的 1 当编号（day=1），交叉校验 metadata.day 必然误报；且 metadata.day 实测有「38」「Day38」两种写法，int('Day38') 抛 ValueError 落入字符串比较再次误报 · 正则补可选版本组 (?:-v(\d+))?\.md$，编号固定取数字段；meta_day 比较前 re.sub(r'^[Dd]ay\s*','',...) 归一化 · Day38 三场景真实文件全通过，反例（前缀错/day 错/乱命名）均正确报错 · 🔍9 组真实形态回归 + 3 反例验证 · t_110bc207

2026-08-28 · [阿普] verify_citations.py source_pattern 对齐素材包三种实测格式，引用校验从空跑到生效（t_110bc207 Bug2 / R-0828-01） · 素材包「来源」行实际有三种格式（①来源1：冒号在加粗内 ②来源：冒号在加粗外 ③【来源1】方头括号），旧规则只认第①种，八识规矩颂素材包（格式②）解析出 0 条来源，引用出处校验形同虚设 · source_pattern 扩展为 \*\*来源(\d*)\*\*\s*[：:]? 或 【来源(\d*)】\s*[：:]? 双分支；冒号后为空（URL 在下一行）时整行兜底作 label · 豆蔻提交 R-0828-01，校验真正生效后可拦截引用出处不符 · 🔍构造样例 3 格式均解析出来源（总 3 条） · t_110bc207

2026-08-28 · [阿普] doukou_script_check.py 交叉校验死代码修复 + verify_citations.py 第四种来源格式（t_110bc207 并发 run 合并态补验） · ① 交叉校验旧条件 scene in SHOW_TO_FILE_PREFIX（scene 短 key vs 全名 key）恒为 False，metadata.show 与文件名前缀校验从未实际执行；run 2146 曾把 reverse_map key 改成「讲/谈/说」与 _detect_scene 返回值（讲经/明慧/阿如）脱节；② 来源：（冒号在加粗内、URL 在下一行）变体不被三格式正则匹配，label 丢失 · ① reverse_map 回归 scene key 体系（讲经/明慧/阿如/日报/内参/脱口秀），条件改 scene in reverse_map；② 正则补 \*\*来源\d*[：:]?\*\* 分支，label 单捕获组 · 构造样例反向验证：错误 metadata.show 正确报「文件名与 metadata 不匹配」；四格式解析 4/4 条 · 🔍合并态全量重验（Bug1 正反向+Bug2 四格式+端到端 24 项 exit 0） · t_110bc207

2026-08-28 · [阿普] dispatcher 存活判定结构性缺口：crash 重试路径无执行体互斥——会话复活体×重试 worker 并发写盘（t_52c611aa，实证自 t_110bc207） · 8/28 07:30:44 整机复位杀死 run 2146 worker（pid 82108），dispatcher 07:31:21 恢复后首个 tick 判 "pid not alive" 立即放行重试 run 2147，但 run 2146 的会话经 gateway 恢复机制换新身份复活继续工作 → 两执行体同时修改同批文件（07:47 合并态验证实证） · 判定机制实测（kanban_db.py）：①detect_crashed_workers（60s tick）判 pid 死即清 claim 同 tick 可派新 run——crash 路径无终止/互斥步骤（pid 已死无可杀，直接放行），它验证的是「pid 死亡」不是「该任务无活跃执行体」；②防双进程保护只存在于 TTL 回收路径（release_stale_claims L5045-5052 先 _terminate_reclaimed_worker SIGTERM→SIGKILL、存活则 defer）；③当执行体可经 gateway 会话恢复获得新 pid 时，pid 这个代理标识完全失效——判定本身无误判（07:31:21 时 82108 确实已死），是覆盖不到 · 方案已出未动代码（按任务卡先方案后动）：L1 task_runs 记 worker_create_time 双因子校验（process_identity.py::_pid_alive_matches 现成，兼堵 PID 复用误判活/误杀）；L2 crash 判定后 retry_after=+120s 延迟放行；L3（推荐先落）build_worker_context crashed 场景注入接手协议「接手前核实磁盘态与评论区」；L4 复活体自首（gateway 恢复时查绑定 run 是否已 crashed） · ①「pid 判活」≠「任务无活跃执行体」——进程存活判定对会话恢复类系统天然失效，评估并发风险要追「执行体身份」而非「pid 存亡」；②防线不对称是常见模式：同系统内 TTL 回收有防并发保护、crash 路径没有，审计时按路径逐条对账不要默认防线全覆盖；③heartbeat 停止≠进程死（LLM 长 API 调用间隙心跳可停 90s+），心跳只用于 wedge 检测（1h 阈值）不用于存活判定 · 🔍本地验证：kanban_db.py L367/377/419/4947-5100/8123-8250 + gateway/status.py _pid_exists L820-874 源码实测；看板 DB task_events/task_runs 还原 8/28 完整时间线（07:16:14 spawn→07:29:47 心跳止→07:30:44 复位→07:31:21 判死+重试同刻 spawn→合并态）；修复方案未实施（P2 排期，L3 可随下任务落地） · t_52c611aa、t_110bc207

2026-08-28 · [阿普] ANS2 存储固件 PCIe 双链路断开 wdog 硬复位（07:30:44），26.6.2 后 9.5 天首次复发（诊断任务） · ResetCounter wdog,reset_in_1 + .contents.panic 41KB：assert 14533 apcie0[1] 2/2 links down DETECT_QUIET，aspcore timer tick(16) 触发，与 7/24 同模式；连带杀死看板 worker run 2146（t_110bc207 崩溃重试恢复） · NVMe SSD 控制器与 NAND 间 PCIe 物理链路在运行中静默断开（26.6.2 固件栈 RTKit 160.4 已改善频率 48h3次→9.5天1次但未根除），disksleep 0 + powernap 0 规避在位仍未防住，SMART Verified 排除 SSD 硬件损坏，无新系统更新可装 · ①该类 wdog 复位为固件级已知缺陷，监控计数继续、频率再加速才需升级响应；②worker crashed 时间与硬件复位吻合时先查 ResetCounter（kern.boottime）再怀疑软件；③panicked 系统 uptime 对比是评估系统更新是否修复缺陷的量化指标 · 🔍ResetCounter+panic strings+pmset log+SMART+last reboot 五源交叉 · 诊断

2026-08-28 · [阿普] L3 重试接手协议落地：build_worker_context crashed 场景注入防并发指令（t_52d62f89，t_52c611aa 方案 L3 实施） · crash 重试路径无执行体互斥的结构性缺口（前条）需要防线：重试 worker 拿到的上下文里没有任何「可能有复活执行体在并发工作」的提示，直接开工即与复活体并发写盘 · kanban_db.py build_worker_context Prior attempts 节末尾新增注入块：prior attempts 存在 outcome='crashed' 的 run 时，注入「Crash-retry handoff protocol」——①首次写盘前核实磁盘态（工作可能已被 crashed run 部分或全部完成，完成则验证合并态直接 complete 不重做）②查评论区有无并发执行体新观察 ③发现并发写盘迹象（文件在手下变化/异常新鲜 mtime）→ 停写、kanban_comment 记录、kanban_block，不与复活体竞速。零结构改动（无 schema 变更），注入文本走既有 _cap 上限体系 · ①防线可以注入到「人」（重试 worker 的指令层）而不必改「机制」（dispatcher 互斥逻辑）——LLM worker 的指令遵循能力本身就是防线资源；②注入点选在 build_worker_context 而非 detect_crashed_workers 的 error_text：error_text 只进 run.error 字段，注入块能带结构化三步协议且位置紧邻 prior attempts 上下文；③验证用真实事故数据：t_110bc207（run 2146 crashed）正例注入、t_52c611aa（全 completed）负例不注入 · 🔍实测：正例 t_110bc207 注入=True、负例 t_52c611aa 注入=False、注入块位于 Prior attempts 节内、四必备要素（gateway session recovery/on-disk state/comment thread/kanban_block）齐全；py_compile 通过 + .pyc 已清；生产生效需 gateway 重启（dispatcher 内嵌长驻循环） · t_52d62f89、t_52c611aa

2026-08-28 · [阿普] 修正 t_52c611aa 踩坑记录的「会话恢复体」假说——真凶是同一 profile 双 surface 并发（CLI worker + 飞书 main agent） · t_110bc207.log 逐行核验：两个 session 顺序追加（L1-156 run 2146 无收尾块=被复位杀死从未恢复；L157-539 run 2147 正常收尾），07:47「双进程」评论出自 run 2147 自己的 session 尾部；apu gateway 07:31:10 重启后无 auto-resume 记录、run 2146 session 文件不存在 · ①gateway 日志实锤：07:32:06 乾婆 @阿普「看板有 2 个技术异常」→ main agent 接手（544.9s/40 API 调用/07:41 完成/07:47 写评论）与 run 2147（07:31-07:40）重叠=双执行体并发，身份是 main agent 非会话恢复体；②t_52c611aa 同模式：08:06:54 乾婆把 CLI worker（run 2150）误认为群聊阿普→main agent 08:07 接手→08:18 写评论→08:22 complete 归档（CLI worker 仍在跑）；③触发器=乾婆群聊 @ 布置/推进看板任务，main agent 有完整工具权限（实测 break_glass/patch/kanban_complete） · 修复方案更新：L3 保留有效；L4 降级（会话恢复非实际触发器）；新增 L5 main agent 行为协议（群聊 @ 提及看板任务先查活跃 run，有则只讨论不执行不 complete）；L6 乾婆认知对齐（群聊阿普≠看板 CLI worker） · 🔍本地验证：t_110bc207.log 结构核验+apu/main gateway.log 时间线+ps pid 15099 存活实测 · t_52c611aa、t_110bc207

2026-08-28 · [阿普] 羊毛雷达 cron 触发 drift_skip（Skipped to prevent unintended spend: global inference） · job 07108b7a1519 只剩旧快照 model_snapshot=deepseek-v4-flash，model/provider 主字段为 null——框架防漂移机制拒绝让 agent cron 落到 global inference（当前会话模型 glm-5.3-flash，烧高成本 Pro token），运行时直接 RuntimeError 跳过 · hermes cron edit 补 pin --model deepseek-v4-flash --provider deepseek；cron run 实测触发 succeeded · ①agent cron 必须 pin model/provider（铁律 #4.2），快照只是兜底不是主配置；②drift_skip 报错文案「global inference」= model/provider 主字段失效的指纹，看到即查 jobs.json 主字段；③修复后必须 cron run 立即验证，不能等次日定时 · 🔍jobs.json 读改前后对比 + cron run succeeded · 07108b7a1519

2026-08-27 · [阿普] log.md 归档策略实施：阈值 50→100KB + 归档自动化脚本（t_c9d8fdae） · log.md 日均约 20 条/+12.7~25.7KB，「保留近 3 天」策略偏激进（3 天必超 50KB），归档频率会升至每 2-3 天一次；归档动作此前靠手动执行 · 正生拍板方案②+③组合：① wiki_guardian.py STREAMING_DOC_THRESHOLDS_KB["log.md"] 50→100（仅 log.md，其余流水文档仍 50KB），归档频率回落每周左右；② 新增 ~/.hermes/scripts/wiki_log_archive.py 一条命令完成归档（备份→按日期切分→archive 倒序插入→frontmatter/指针/说明/索引四同步→体积验证，幂等可重复，跨月自动路由），封装泡影 t_335b41be 验证的手动模式 · ①阈值策略变更须同步知识库规范 F3（已加 log.md 例外条款）+ wiki-maintenance 技能 ③.7 节 + 知识库运维体系 T9 节三处；②归档脚本必须同时匹配表格行与简写行（只配表格行漏简写条目）；③改 wiki_guardian.py 后跑 wiki_guardian_selfcheck.py check（本次 exit 0，断链/孤儿零回归，基线已重建） · 🔍dry-run 三场景（days=2 幂等零写入/days=3/days=1 识别 21 条）+ 实跑归档 21 条（50444B→24191B）+ 数据完整性核对（条目守恒 43=22+21、archive 186→207、内容零丢失）+ 幂等复跑 + 阈值生效验证（log.md=100 其余=50） · t_c9d8fdae

2026-08-27 · [阿普] 交付复制 MD5 比对校验（R-0827-01） · 修复版生成并验证通过后，交付复制拿错版本——8/25 t_572604ca 日报 v2 已修但交付复制了未修复「完整合成」版，交付版与验证版字节不一致 · .deliverables 工作区多版本共存（修复版/验证版/中间产物如 _段1已裁切/_完整合成_已裁切 命名相近），deliver_podcast.py discover 按 mtime 选版不可靠 + 复制后只查文件大小零字节校验，「最新生成=交付版」假设错误 · deliver_podcast.py 复制环节加双层 MD5 比对（R-0827-01）：①复制前 --expected-md5 锚点比对（验证版 MD5 与源文件不一致→阻断，防选错版本）；②复制后源 vs 目标 MD5 比对（不一致→告警阻断，防复制过程出错/截断）；新增 file_md5() 流式计算 + parse_expected_md5()（单一 md5 或 '场景名:md5' 逗号分隔）；已同步 paoying-podcast-review 技能交付流程第 5 步 + 陷阱 5 · ①mtime 选版在多版本共存下不可靠，交付复制必须与「验证版 MD5」比对而非「最新文件」；②复制后校验字节一致性，不只查文件大小；③防「选错版本」靠锚点（--expected-md5）不靠复制后比对（选错版本时源==目标必然一致，复制后比对查不出） · 🔍三场景实测（正常复制 MD5 一致 exit0 / 错误 expected-md5 阻断 exit1 / 正确 expected-md5 通过 exit0）+ file_md5 与 md5 命令一致 + parse_expected_md5 4 格式单测 + py_compile 通过 · t_426c16d8

2026-08-27 · [阿普] 看板事件通知 gave_up 语义模糊误唤醒阿普无谓诊断（R-0827-04） · kanban_event_collector.py gave_up 分支读错字段 payload.get("reason")（gave_up payload 实际只有 error 字段无 reason）→ 永远「原因未知」；且 gave_up 归入 TECH_ANOMALY_KINDS 无条件 @阿普诊断，但 gave_up 是「连续失败熔断器触发」元事件，实测 68 条中 52 条（预算耗尽7+协议违规45）是 dispatcher 正常重派机制非崩溃 · 新增 _classify_gave_up() 按 error 字段分三类（Iteration budget exhausted→预算耗尽 / protocol violation→正常重派 / 其余→真崩溃）；format_event 对前两类置 subject=None 静默（不推送不 @阿普），仅真崩溃走智囊团 @阿普；build_feishu_message 改读 error 修复「原因未知」 · ①gave_up 是熔断器触发元事件，语义取决于 trigger_outcome+error 字段，不能一概报「放弃执行」；②修 bug 追到「读错字段」层（reason 字段根本不存在），不能只改文案；③预算耗尽/协议违规是 dispatcher 正常重派，误唤醒阿普诊断=纯浪费 token · 🔍实测 DB 68 条 gave_up 分类（预算耗尽7/协议违规45/真崩溃16）；py3.9+py3.x 编译过；端到端验证三类路由正确 · t_3a0e0013

2026-08-27 · [乾婆] Mnemosyne 每日 4AM 清理 cron（b77e5af55435）确认已失效——由官方 auto-sleep 机制接管，技能文档过时更正 · 全局 jobs.json（77 job）+ 各 profile 均无 b77e5af55435；但 mnemosyne-configuration 技能 SKILL.md 仍写「已配置运行中」（含晨间回顾「先确认该 cron 存在」提示、验证步骤），文档过时 2 个月+；consolidation 实际由 Hermes 官方集成层 hermes_memory_provider _maybe_auto_sleep() 承担（WM>50 条+有到期未合并记忆自动触发，非自研） · ①官方 auto-sleep 优于自写每日 cron（按需触发+预算护栏，近7天 80 次压缩全 llm 方法零 aaak 兜底）；②no_agent 模式≠AAAK 压缩（脚本只是 wrapper，压缩方法由 env 决定，已配 DeepSeek Flash）；③AAAK「机器可读」≠检索可用（FTS5 搜不到=存了等于没存） · ①SKILL.md 三处修正（定时任务节标失效+晨间回顾提示改查 consolidation_log+验证步骤改 sqlite 查询）+ 陷阱9 补失效注；新增 references/auto-sleep-official-and-cron-removed-2026-08-27.md（v1.3→v1.4）；②Cron 作业全览.md 无此条目无需改；③勿据此恢复 cron，官方机制接管 · ①文档与实际系统状态必须定期交叉验证，技能文档会过时；②「已配置」类描述要带核实日期；③工具/机制变更后同步技能文档，不只记踩坑 · 🔍8/27 核实 jobs.json+各 profile+consolidation_log 近7天 80 次 llm 记录+源码 _maybe_auto_sleep 定位 · -

2026-08-27 · [乾婆] Memory 治理专项拍板开工：全代理 memory 爆仓治理（计划 t_17241755 拍板） · 全代理 MEMORY 5/6 ≥90%（泡影97/阿普97/豆蔻95/如花96/乾婆90），仅广智健康；历史噪音与当前状态混杂，压缩后新条目又填回（8/25 压缩后 2 天 +190 字符）；USER 8/22 误记与 MEMORY 澄清冲突未同步=历史噪音实证 · 治理三层：M1 写入规范（写前四问+禁止时效日期/案例编号/金额）+ M2/M3 存量清理（备份→三选一→去向记录，目标乾婆≤2200/子代理<85%）+ M4 Mnemosyne 体检（AAAK 526 条重压缩）+ M5 cron 升级（三选一铁律+统一巡检 cron 每10天，正生拍板方案 A）；P0 规范已固化进 qianpo-management-ops「Memory 治理规范」章节；全链 7 卡一次建完（t_e1c8f5cf/t_292775f4/t_0b957058/t_89476611/t_c45755b5/t_5645b77e/t_4265a8d6） · ①「写入纪律（源头）+存量清理（一次性）+例行压缩（周期）+Mnemosyne迁移（存档）」是 memory 治理四手段，压缩治标写入纪律治本；②移除前必先迁 Mnemosyne，正生删除零容忍；③多阶段计划一次建全链（--parent 串行），不留乾婆后续建卡环节 · 🔍8/26 实测全代理占用 + consolidation_log 近7天 80 次全 llm 方法 · t_17241755

2026-08-27 · [阿普] Mnemosyne 向量召回通道启用 + FTS trigram 评估（t_4474af14，承接 t_5645b77e P1-1/P1-2） · P1-1 向量通道空（binary_vector 3360 全空）+ P1-2 中文检索差 · ①真根因三层叠加：venv 缺 numpy/fastembed/sqlite_vec（mnemosyne-memory 只声明 PyYAML，numpy 是可选项）+ .env 未配 embedding + fastembed 默认模型是英文版 bge-small-en-v1.5；②reindex 命令继承 shell 的 HERMES_HOME（apu worker=~/.hermes/profiles/apu）会连错空 DB，必须显式 MNEMOSYNE_DATA_DIR；③trigram tokenizer 要求 query≥3 字符才能生成 3-gram，中文 2 字词（验收/网关/看板）命中 0%，且索引体积 900 倍膨胀（unicode61 991 vs trigram 90 万 token） · ①「向量通道空」不能只看 .env 缺配置，先查 venv 依赖（numpy/fastembed/sqlite_vec）是否装了——缺依赖时 available() False 即使配了 env 也白搭；②reindex/回填类 CLI 命令先 dry-run 验证连对 DB（看 working/episodic 条数是否匹配预期），再正式跑；③FTS 中文方案选型：trigram 不适合中文（2 字词致命缺陷），正确方向是 jieba 分词 + 自定义 tokenizer 或向量召回兜底，非 trigram · 🔍实测：fastembed 加载 bge-small-zh 512 维 + 词面零重叠语义召回命中（"代理服务挂了"→飞书记忆）+ reindex 53.7s 回填 3360+486 + binary_vector 0→3360 + recall 纯向量 dense 命中 + trigram vs unicode61 命中对比表 · t_4474af14

2026-08-27 · [阿普] send_group_msg.py 改造：强制显式身份 + 发送后回查 sender，消除 env fallback 乾婆默认值误发（R-0827-02 P0，t_2ad3f077） · lark-cli/群发脚本默认当前App=乾婆身份，误发=严重事故（正生对身份归属敏感）；旧脚本 send_group_msg.py:38 os.environ.get("FEISHU_APP_ID") or "cli_a93d723aeb389cb5" 硬编码乾婆默认值 · 调用方以为「设了 env 就是自己身份」，没设时却静默 fallback 成乾婆 app → 误发串号 · 改造：①强制显式身份（--app-id/--app-secret 或 --profile qianpo/apu/ruhua/guangzhi/doukou/paoying 或环境变量，三者都没有直接报错退出，绝不 fallback 硬编码默认值）；②发送后 GET /im/v1/messages/{msg_id} 回查 sender.id==预期 app_id 且 id_type==app_id 才返回成功，不一致报「疑似误发」exit 1；③内置完整 6×7 open_id 视角矩阵按发送方 app 自动选行艾特 · ①发消息脚本的 app_id 禁止 env fallback 硬编码默认值——「or 默认值」=埋地雷；②身份验证要「发送后回查 sender」而非只信拿 token 成功（token 成功只证 secret 匹配，回查才证消息真以预期身份发出）；③子代理发群消息一律走统一脚本，禁止裸 lark-cli（currentApp=乾婆易误发） · 🔍实测：缺身份 exit 1 + 未知 profile/群名 exit 1 + 阿普身份真实发智囊团回查 sender.id=cli_a925a4ee9e78dbcc 一致 exit 0；纪律已固化 apu-feishu-agent-ids-patches · t_2ad3f077、R-0827-02

2026-08-27 · [阿普] 飞书@判读规则散布多源致「谁@了我」反复误判（R-0827-05，t_db5e03dd） · 判读规则散布 4 处（memory + 3 技能），apu-feishu-agent-ids-patches 残留旧判读「你被@了是通用前缀、Mentioned 才是名单」，与 adapter.py _build_mention_hint 代码真相相反 · 代码真相（_build_mention_hint L1261-1287）：if ref.is_self 把 self 从 Mentioned 过滤，self 被@靠 self_mentioned 标志追加 [你被@了] 信号 → 正确判读：[你被@了]=自己被@（唯一可靠信号）；[Mentioned:X]=其他人（排除 self，列表永远不含自己）。旧判读曾致两次漏响应/误报（R-0819-04、R-0823-08） · ①判读类规则必须单一真相源（apu-feishu-adapter-pitfalls #14 节含代码根因），其他技能/memory 只引用不另行定义；②清理旧规则后全量 grep 确认无现行旧表述残留；③agent 误判「没@我」先查代码真相，不靠记忆判读（治本不治标） · 🔍代码层确认 _build_mention_hint L1261-1287；全量扫描 58 处命中，清理 1 处旧规则（agent-ids-patches 218-225），3 处「通用前缀/才是名单」均已是废弃标注；painpool resolve 完成 · t_db5e03dd、R-0827-05

2026-08-27 · [乾婆] 机制迁移必须全库同步所有引用技能——08-15 只更新权威源漏了 qianpo-management-ops 埋雷（会话 20260827_151155，无看板任务） · 8/27 核查「任务执行人错误」时发现 13+ 处教学式废弃残留：旧 hack「assignee=qianpo」的教学式表述仍散布在 qianpo-management-ops 等多个技能里，08-15 机制迁移（延后任务=实际执行人+schedule park、禁 qianpo）未同步清除 · 08-15 迁移时只更新了 kanban-deferred-execution 权威源，漏了引用它的 qianpo-management-ops 等其他技能——机制迁移只改权威源不清理引用源，旧表述继续在教学场景教坏新任务 · 单任务修正 t_0a25723c → apu+scheduled（当晚 22:05 自动释放执行）；13+ 处教学式废弃残留全清；宪法与权威源统一（延后任务=实际执行人+schedule park、禁 qianpo）；memory 更新确保未来建卡加载正确规范 · ①机制迁移必须全库同步所有引用技能，不能只更新权威源；②「禁 X」类废弃表述会在引用技能里以教学示例形式残留，迁移后要 grep 全库清理教学式残留，不只改规范正文 · 🔍知识库侧干净：看板延期执行体系-历史沿革.md 08-15 已正确归档（旧 hack 标「已废弃」、正文只留官方 scheduled），污染只发生在技能层已全清，无残留无重复源 · 会话处理

2026-08-27 · [阿普] 报告索引「自动追加」链路名实分离：主通道改造落在退役脚本上+兜底时序错位致巡检误报断档（t_1e840fd2） · 8/27 巡检报「报告索引断档」：8/27 报告 04:13 已生成但索引最新停 8/25；任务怀疑 deliver_podcast_mp3.py 未调 wiki-index-add · 全链路还原：①全局 deliver_podcast_mp3.py（6/28 旧版）确实无 wiki-index-add 调用，但它已退役（无任何 cron/launchd 引用），非活跃通道；②真正主通道=泡影 profile deliver_podcast.py ⑤ 环节（8/4 t_0a872d61 接入，auto-detect 模式），有调用但不稳定——8/23 触发过，8/25/8/27 交付 worker 按 body 三步（检查→复制→发送）执行漏掉 ⑤ 环节；③23:00 reconcile 兜底实际可靠（23 次 completed ok，8/25 断档当天补上），8/27 两条 21:13 已补录带真实结论；④巡检 21:10 读索引时兜底（23:00）还没跑，交付(04:50)→兜底(23:00)之间 18h 窗口期被误判为「断档」 · ①「脚本存在≠被调用」第二次验证（8/4 已踩过一次）：A1 验收只确认 wiki-index-add 有 report 子命令+cron 在跑，没验证主通道接线；②交付 worker 行为由任务 body 驱动，body 不写索引步骤=不执行——链路改造必须写进交付任务模板 body；③兜底时序必须早于巡检时序，否则兜底可靠也会被误报断档 · ①reconcile cron 23:00→06:00+23:00 双兜底（断档窗口 18h→~1h，幂等按路径去重无重复风险）；②报告索引页「自动维护」说明更新为双通道真相（主通道=泡影交付脚本 ⑤ 环节+兜底=cron 对账）；③Cron 作业全览.md 同步；④验证：reconcile 手动跑 exit 0 静默、wiki-index-add 对已收录路径去重跳过、8/27 条目无重复 · 🔍本地验证：deliver_podcast_mp3.py 全文无 wiki-index-add（read_file 全文）；泡影 deliver_podcast.py L1011/L1105 有调用；delivery_log.jsonl 最后一条 8/25；t_6511a2ed 交付任务 metadata 只派生播客交付索引；reconcile 手动 exit 0；去重实测跳过 · t_1e840fd2

2026-08-26 · [泡影] 版本号快照滞后「第五次同型」——升级动作本身没触发全库扫描（t_5542ae1e 固化联动机制） · 8/25 t_1a033e25 完成 v0.20.5 升级，但深度分析（21:05）在升级前实测 v0.20.0 → 全库 23 页 frontmatter version + 7 处正文示例仍写 v0.20.0，8/26 深度分析才发现并清账 · 前四次（8/22-8/25）是「单页漏修」（配置体系/CLI 参考/安装指南/部署指南），第五次是「升级动作本身没有触发全库扫描」——精读周期最长 30 天，升级可发生在两次精读之间，纯靠精读碰巧发现，滞后最长 30 天 · 固化「升级类变更事件级联动」：hermes update / 端口变更 / profile 新增后，升级方（阿普/乾婆）建看板任务给泡影执行升级同步 checklist（全库 grep 版本号 + 端口表核对），精读被动发现改为事件主动触发 · ① 升级类变更（hermes update/端口变更/profile 新增）落地时不能只靠精读碰巧发现版本号滞后，必须事件级主动触发知识库同步；② 版本号/端口表是高频快照字段，全库 grep 是唯一可靠清账手段；③ 已固化：wiki 知识库运维体系.md「升级类变更事件级联动」章节 + wiki-maintenance 技能 ④.5 + knowledge-base-update-checklist 技能「升级类变更联动」 · 🔍8/26 深度分析清账 frontmatter 23 页 + 正文 7 处；联动机制 3 处固化完成 · t_5542ae1e

2026-08-26 · [如花] ffmpeg concat 拼接两段 TTS 产出 64kbps 低码率版，且错误版已被复制进 .deliverables（t_cd10f382 run 2051） · Day37 明慧对谈两段串行合成（seg1/seg2 均 128kbps），拼接后成品变成 64kbps；run 2051 超时前已把错误版复制进 .deliverables；run 2052 用 128kbps 原始段重拼+重裁修复 · ffmpeg concat demuxer 对 MP3 默认可能产出低码率版——裸 -c copy 拼接不保证码率保持 · 拼接必须显式 -c:a libmp3lame -b:a 128k；交付前必须 ffprobe 核验 bit_rate 与原始段一致（128000），发现 64000 立即重拼，不交付低码率版 · ① 拼接/裁切产物交付前必须 ffprobe 核验 bit_rate 与原始段一致（128kbps）；② 核对项含码率/采样率/位深，不只文件大小；③ 已固化技能铁律 20.5 + podcast-tts-protocol 拼接方案 · 🔍ffprobe 核验 677.57s/128kbps；MD5 2b0b9610 一致 · t_cd10f382

2026-08-26 · [如花] post_synthesis_verify v3.0 grade_noise rework 级对正常高能量语音误报（t_cd10f382） · 2 处 rework（233.5s「你问得对，我换个比方，路牌」、569.1s「贝克莱英国那位，他说存在」）实为正常对话台词；波形 Peak -2.7~-2.8dB 无削波 · grade_noise 多维声学分级只看 max_db+total_sound+mean_zcr+n_sound 加权，不看内容——正常高能量语音（无削波）会被判 rework · 7 处 suspect + 8 处幻觉报告全部经 whisper+SenseVoice 双 ASR 人工抽听确认正常台词（无真怪声无真幻觉）后放行，不裁切 · rework 级也非最终结论：触发后必须 whisper+SenseVoice 双 ASR 人工抽听确认（双 ASR 转出脚本台词=正常放行；仅 whisper 报幻觉但 SenseVoice 复核为同音误判=放行；双 ASR 均听出非脚本音节=真幻觉才裁），不机械阻断交付；误报模式已固化技能铁律 21.5 · 🔍双 ASR 逐段确认 11 处可疑段全部正常；成品 128kbps 与原始段一致 · t_cd10f382

2026-08-26 · [如花] trim_tongue_twister.py VTT 把正文普通首句（非称呼）并入绕口令段→裁切点误伤正文开头 + 残留「皈依僧」（t_926de517） · 阿如说故事 Day37 裁切：脚本 VTT 定位正文起点 3.368s 自动裁切，成品开头 ASR 出现「皈依僧，前两天读经」残留；独立 whisper_light 复核显示正文「前两天读经」实际从 4.62s 开始（0-6.72s VTT 段把「前两天读经，读到一句」并进绕口令段） · 与 t_34c91f83（称呼并段）同源但形态不同：正文普通首句也会被 whisper VTT 并进绕口令段（本案例 VTT 段 0-6.72s=「皈依上师...皈依僧，前两天读经，读到一句」），trim 脚本取 VTT 正文第一句 3.368s 裁切点落在绕口令「皈依僧」内部→尾音残留+正文开头「前两天」之前被裁入 · 手工兜底：silencedetect(-40dB,d=0.12) 定位绕口令尾音后静音段 4.372-4.627s → 裁切点 4.47s（静音段起点+0.1s）→ adelay=850 补开头静音至 1.007s；裁后 whisper 开头 ASR 验证「前两天读经，读到一句，我合上书，愣了很久」完整、无「皈依」残留 · ① 凡 VTT 裁切报「交叉比对不通过」或验证 A 关键词命中率低，先用 whisper_light --segment 0 12 独立复核正文真实起点（首句非称呼同样会被并段）；② 裁切点锚定「绕口令尾音后静音段起点+0.1s」比 VTT 段起点可靠（VTT 段边界 ±0.3s 误差）；③ 裁后开头 ASR 必须含正文首句完整内容（含首句非称呼情况），出现「皈X/归一」类词=尾音残留铁证 · 🔍裁切后 whisper 开头「前两天读金,读大一句,我和尚书愣了很久」完整无残留；开头静音 1.007s；成品 532.5s/8,520,559B；SenseVoice 复核 5 处幻觉报告（干屎橛→丹使觉/干使诀、香严→相言、恭恭敬敬→公公尽尽、祖师西来意→组细来异、庄严→装颜）均为同音误判内容完整 · t_926de517

2026-08-26 · [如花] trim_tongue_twister.py VTT 把正文首句称呼「阿如」并入绕口令段→首字被误裁（t_34c91f83） · 讲经说法 Day37 成品开头直接是「咱们这些天」，缺首句称呼「阿如」；v1 裁切时 whisper VTT 把「皈依上师皈依佛皈依法皈依僧阿如」整段识别为「归一上施 归一佛 归一法 归一生 二如」单段（0-3.96s），正文起点定在 3.96s，3.70-3.96s 的「阿如」被裁掉 · whisper base VTT 段边界不稳定：正文首句 1-2 字称呼（「阿如」）会被并入前一绕口令段，裁切点落在称呼之后正文之前；脚本 find_first_body_segment 无法识别「段内混有称呼」 · 手动重裁：绕口令尾音后静音段（3.51-3.70s）锚定裁切点 3.60s（+0.1s 容差）→ 保留「阿如」+ 开头 adelay 归一化 1s → 与段2重新拼接；开头 ASR 复核「阿如，咱们这些天翻来覆去说一句」完整 · ① 正文首句带称呼（阿如/老师等 1-2 字）的节目，裁切后必须独立 ASR 复核开头含称呼，VTT 段边界会吞称呼；② 裁切点锚定绕口令尾音后静音段（silence_start+0.1s）比 VTT 正文起点可靠；③ 交付复制前 MD5 核对验证版（铁律 #20 同源） · 🔍修复后开头 ASR=「阿如，咱们这些天…」、开头静音 1.1s、全文匹配率 90.0%（v1 80.3%）、5 处幻觉段 SenseVoice 复核全为同音误判 · t_34c91f83

2026-08-26 · [阿普] 修复楞伽经偈颂品科判版经文源路径失效（t_492c9c4d） · 豆蔻 Day37 蓝图任务上报：podcast-buddhist 等技能标注的经文唯一源 /Users/mac/Downloads/楞伽经偈颂品科判版.md 已失效，文件不在原位 · 文件 5/31 被移入 .Trash（58112 字节）；Downloads 是临时目录无保护；技能仍标注 Downloads 路径 → 未来建链/写稿按技能找科判版全文扑空 · 从 .Trash 迁移到 /Users/mac/.hermes/kanban/deliverables/（与 88天方案同目录），全量 grep 并同步 7 个技能文件的路径引用（podcast-buddhist×2、podcast-orchestration-core、kanban-orchestrator/references、chuangzuo-lantu、lengqie-podcast-characters、podcast-script-craft×2+references，含 doukou profile 跨 profile 修） · ① 关键参考文件（经文源）不放 Downloads 临时目录，放 deliverables 等稳定目录；② 路径变更须全量 grep 所有 profile 的 skills（含 doukou profile），不只改任务点名文件；③ 444 只读锁定的 SKILL.md 用 patch 会 Permission denied，需临时 chmod u+w → patch → chmod 444 回锁 · 🔍全库 grep 活跃技能 0 残留失效引用 + 新路径文件存在（58112 字节/1692 行含完整科判结构）+ 旧 .bak 备份与 bug 报告 reference 历史描述保留不动 · t_492c9c4d