原则与记录

第4章 · 笔记 4

笔记 4

2026-08-26 · [乾婆] 补搜死锁修复遗漏根因源头——只改诊断技能没改执行技能（7/26 同类重演，正生指出治标不治本） · 7/26 Day24 死锁后建立 kanban-dispatch-deadlock-busou 诊断技能，但未同步修正豆蔻实际加载的 podcast-buddhist 执行技能与 buddhist_podcast_launcher.py Step③ body 模板——两处仍教「补搜必须带 --parent + dependency 阻塞」。8/26 Day37 豆蔻照技能建带 parent 补搜 → claim_rejected: parents_not_done 死锁重演 · ①launcher Step③ body 模板「补搜子任务铁律」改为：禁止传 --parent，补搜独立 initial_status=ready，父任务 needs_input 阻塞 + 乾婆手动 unblock（3 处）；②podcast-buddhist SKILL.md 补搜铁律段落 4 处同步修正；③kanban-dispatch-deadlock-busou reference 标记源头修复已落实 · ①修复死锁/任何问题必须追到「产生问题的源头」（执行方技能/模板/脚本），只修当前症状=治标；②诊断技能（乾婆侧）与执行技能（豆蔻侧）口径必须一致，只改一侧必重演；③body 模板的「🚨铁律」措辞会压制技能，模板本身必须正确 · 🔍py_compile 通过 + grep 无残留错误文本 · 会话 08-26

2026-08-25 · [如花] 日报 4 处怪声修复：v2 已修但交付复制了未修复版 + speaker 切换空转幻觉（t_572604ca 同日正生反馈） · 8/25 日报正生反馈 1:48/2:47/3:22/3:58 四处明显怪声；查任务日志发现当天已做 v2 修复（裁了 108s 处 [chuckling]）但交付复制的是未修复「完整合成」版（3960625B=成品目录原大小） · ① 流程缺陷：v2 验证通过后交付复制没核对字节/MD5，「最新生成=交付版」假设错误；② 4 处怪声全在 speaker:1→0 切换处（s2.1-pro-free 切换空转幻觉，8/23 t_229e0916 同源）；③ 1:48 叠加 [chuckling] 误用（原稿 [轻笑] 被加工成 [chuckling]） · 重新裁切 4 处（108.54-111.42 / 166.45-167.06 / 202.74-203.61 / 238.77-239.52s）静音替换，替换成品 + 备份归档；全文 whisper 131 段无怪声词 · ① 修复版生成并验证通过后，交付复制必须再次核对字节/MD5 与验证版本一致；② speaker 切换处是怪声高发区，切换越多越易空转（标签密度 8/25 约 97% 是放大器）；③ [轻笑] 不主动转 [chuckling]（s2.1 对 [chuckling] 扩 6s 超长笑声） · 🔍裁切点与 silencedetect 静音边界吻合未切正文；修复版 3887038B/243.98s（原 3960625B/247.48s） · t_572604ca

2026-08-25 · [如花] trim_tongue_twister.py VTT 把绕口令段误当正文第一句→裁切点=0 失败（t_448aecd8） · 内参 20260825 裁切：脚本 VTT 定位「正文第一句」= 0.000s「故意衣上石 故意衣服 故意衣法 故意衣生」，裁切点=0，ffmpeg 裁切失败；实际 0-4.56s 是绕口令「皈依上师皈依佛皈依法皈依僧」被 whisper 误转写成「故意衣/归医/鬼一」系列，正文「我想聊一件Hermes最近做的事」从 4.16s 才开始（whisper_light word 级定位实证） · whisper base VTT 对绕口令「皈依」的转写是「故意衣/归医」等变体（同音字），trim 脚本没有「绕口令转写变体」识别——它找「绕口令后首段」时若 VTT 第一段恰好是绕口令段（0s 起）且文本不含「皈依」字样，就被误判为正文第一句 · 手工兜底：whisper_light --segment 3.0 9.0 分段 + word 级时间戳定位正文首句起点（「我想」start=4.16s）→ ffmpeg -ss 4.16 裁切 → adelay=1000 补 1s 静音；成品验证 PASS（开头静音 1.04s、首句完整、总时长 572.3s） · ① trim 脚本 VTT 第一段 0s 起且文本命中绕口令变体（故意衣/归医/鬼一/归一/皈一）时应跳过、取第二段为正文起点——脚本缺此识别，遇到即裁切点=0 失败；② 脚本报「裁切点=0/ffmpeg 失败」时不能硬跑，先独立 whisper_light 复核正文首句真实起点再手工裁；③ 补开头静音用 adelay=1000:all=1（mp3 concat demuxer 有坑见 8/21 记录） · 🔍whisper_light word 级：绕口令尾「依法 归医生」3.0-4.16s、「我想」4.16s 起；裁后 ASR 开头「我想聊一件Hermes最近做的事」完整无残留，silencedetect 开头静音 1.04s，总时长 575.4-4.16+1=572.3s ✓ · t_448aecd8

2026-08-25 · [阿普] wiki_guardian.py 新增流水文档体积监控——阈值对齐规范 F3「50KB 必须拆分」（t_8a0611c2） · 流水型文档（log/踩坑记录/需求池/每日巡检报告/知识库索引）append-only 天然膨胀，「打开越来越慢」无预警（知识库有效信息改造计划 8.5 高频维度缺口）；已有月归档（archive/）但无「体积超阈值告警」 · 知识库规范 F3「持续日增型页面超过 50KB 必须拆分」只有规则无监控机制执行；检测脚本分工里（check_kb_staleness.py 管过时、wiki_guardian.py 管断链/孤儿/看板/cron/技能指针）缺「体积」维度 · wiki_guardian.py 新增 check_streaming_doc_sizes()（os.path.getsize 不读内容）+ 模块顶部 STREAMING_DOC_THRESHOLDS_KB 常量（5 个流水文档，默认 50KB 对齐 F3，可配置覆盖）；超阈值→巡检报告「流水文档体积」告警（健康度概览 + 自动检测问题），提醒归档/拆分；只提醒不自动删（清理走泡影月归档既有流程） · ① 阈值必须对齐规范既有规定（F3 50KB），不能自创一套——初设 100/150KB 与规范冲突，读规范后改回 50KB，先查规范再定阈值；② 阈值做「可配置常量」集中模块顶部，不硬编码散落各处；③ 体积告警只提醒不自动删，清理动作走泡影月归档，不新增自动删除逻辑（C3 铁律同源：脚本只初筛不判死） · 🔍实测：scan 4 文档超阈值（log 123.1/踩坑 117.7/需求池 54.3/巡检 96.3KB），索引 18KB 未超；边界测试全过（超阈值触发/未超不触发/严格大于 50KB 不触发/文件不存在跳过）；wiki_guardian_selfcheck.py check 退出码 0（8 指标无回归，基线已重建） · t_8a0611c2

2026-08-25 · [阿普] check_kb_staleness.py 检测入口扩展——仅 freshness:live → status:active 并集（t_2148eece） · 检测脚本只扫 5 个 freshness:live 页，其余 103 页不参与自动过时检测；T2 建页模板已带 status:active 但新页从源头进不了检测覆盖 · 知识库有效信息改造 T3（计划 P3 检测扩展）：status 三态已定（T1），脚本检测入口仍是单一 freshness:live，状态机字段与检测脱节 · parse_frontmatter 加 status 字段解析 + freshness/status 枚举字段剥行尾 YAML 注释（兼容「status: active # 注释」同行注释与 T2 模板注释独立行两种形态）；scan_live_pages→scan_detectable_pages，检测入口改 status=active OR freshness=live 并集，阈值 freshness_days 优先缺省 30 天；superseded/archived 不匹配 active 天然跳过、archive 目录 EXCLUDE_DIRS 兜底；--list-live 文案更新、新增 --list 别名 · ① 检测入口从单一标记扩展为状态机字段并集时，必须保留旧入口（freshness:live 5 页不能丢），用并集非替换；② frontmatter 枚举字段要剥行尾 YAML 注释，规范示例（同行注释）与 T2 模板（注释独立行）两种形态都要兼容；③ 扩展覆盖不改变判定铁律（C3 可能过时≠已过时），只扩大初筛范围，判定仍由泡影三选一 · 🔍实测：9 个检测覆盖页（5 live + 4 纯 active + 关键配置参考重叠），parse 边界 8 用例全过（纯/同行注释/superseded/archived/T2模板/live带注释/无字段/仅注释），--dry-run 无超阈值静默，py_compile OK、__pycache__ 已清理 · t_2148eece

2026-08-25 · [阿普] doukou_script_check.py 文件名 day 校验对资讯播客误报修复（t_b812085a） · 日报/内参脚本（8位日期做 metadata.day）每稿被「文件名编号与 metadata 不匹配」误拦 · FILENAME_PATTERN 的 (.+?)(\d+) 非贪婪匹配把纯数字日期拆成「首字符+剩余」（日报-20260825.md → series='2' day='0260825'），与 8 位 meta_day 必然不等 · 8位纯数字日期型 day（日报/内参/脱口秀）走整体文件名比对 {前缀}-{day}.md；编号型（讲经/明慧/阿如）保持去前导零比对 · ① 正则非贪婪 (.+?)(\d+) 对纯数字串拆成「首字符+剩余」，不能用于日期型编号场景；② 同一校验脚本里 day 字段语义因节目而异（日期 vs 编号），须按语义分流，不能一刀切 · 🔍5 场景实测（日期匹配/日期不匹配/编号匹配/编号不匹配/脱口秀）+ 真实样本日报-20260804、内参-20260823 复测无误报 · t_b812085a、R-0825-03

2026-08-25 · [阿普] apu_daily_limit_monitor.py 新增当日告警幂等：同级别同内容只发一次（t_3ab09cbc） · 8/25 智囊团收到两份内容完全一致的「阿普任务量超限提醒」（12:47:38、12:58:10），正生要求去重 · 脚本无幂等——只要运行时超限就 send_alert，修复日当天手动验证 + cron_error_watchdog retry + 正常调度多次运行同一状态，每次运行都推送一次 · 新增「日期+级别+内容指纹」三重幂等：状态文件 ~/.hermes/scripts/.apu_limit_monitor_state 记录当天各级别已发送内容的 md5，发送前比对——同级别同内容跳过（仍正常输出/退出码 0）；内容变化（待派发新增）或级别升级（预警→超限）指纹不同仍补报；发送成功后才写状态（失败不写，防告警永久丢失）；状态文件仅保留最近 7 天防膨胀 · ① 告警脚本必须幂等，否则修复日的多触发源（手动验证/watchdog retry/正常调度）会重复打扰；② 幂等粒度选「内容指纹」而非「仅级别+日期」——否则晚间数据变化（如待派发新增）会被误吞，丢失补报能力；③ 状态只在发送成功后写入，失败不记录，否则一次网络抖动会导致告警永久丢失 · 🔍4 场景 stub 实测全过（首次发/同内容跳过/内容变化再发/级别升级再发）+ --dry 正常退出 0 + py_compile 通过 + __pycache__ 已清理 · t_3ab09cbc

2026-08-25 · [阿普] A2A 成熟度观察任务死循环复发：check_a2a_maturity.py 条件②「本地含修复 commit」本地升级后永久 True，巡检 cron 每日反复 unblock（t_37c2065e） · 8-15 修死循环时把条件②从「issue closed」（一次性）改成「本地 git HEAD 含修复 commit」（误判为持续性信号），但「本地含修复」也是单向状态迁移（未含→已含），本地升级 v0.20.5 后永久 True，cond1 or cond2 中 cond2 永久满足 → 每日反复 unblock · ①任何「状态单向迁移」（未含→已含、open→closed）满足后都不会自动变回不满足，本质都是「一次性事件」，换成任何持续检查形式（git 祖先/文件存在检查）都一样；②一次性事件只允许触发一次评估，消费后必须从 exit 判定退役（删 or 分支），只保留真正会波动的持续信号（open issue 数）；③设计钩子触发条件自问「满足后会不会自动变回不满足？不会=一次性事件」 · 🔍本地验证：脚本改后实测 exit 1（138>50 冻结）+ GitHub API 实测 6 个结构性 bug 全 open（#83701/#78007/#84607/#78396/#82910/#80884）+ 技能 kanban-deferred-execution 已 patch 记录根因 · t_37c2065e

2026-08-25 · [阿普] detect_nonverbal_noise.py 怪声分级 v3.0：returncode 一刀切 → 多维声学三级分级流转（R-0823-07 P1 落地，t_605902e0） · 8/19 事故音频「日报0819_怪声音定位_0205-0212.opus」的怪声段（2.68s~5.40s，峰值 -0.8dB，有声 1.98s）被 detect 脚本判 unknown 放行、exit 0 完全漏检；可行化报告 R-0823-07 指出分级只用 max_db 单维度、post_synthesis_verify 只按 returncode 一刀切不消费分级 · 根因①：post_synthesis_verify 调 detect_nonverbal_noise.py 时不传 --script，导致 classify_gap 对无脚本场景一律返回 unknown（保守放行），真怪声被「无脚本对照」这道墙挡住，永远 exit 0 漏检；根因②：分级只算 max_db 一个维度，吸气气流声/笑声吐字（ZCR 极端值）和突起密度（反复怪声）这些强信号被忽略；根因③：分级结果只有 emoji 文本，无结构化输出，下游无法消费 · detect_nonverbal_noise.py 加 grade_noise()（max_db 能量 40 分 + total_sound 时长 30 分 + mean_zcr 声学类型 20 分 + n_sound 突起密度 10 分加权 → pass/suspect/rework 三级 + 分数 + 理由）+ resolve_final_level()（verdict 与声学分级融合：real_speech/expected_vocal→pass、noise/overlong_vocal→至少 suspect、unknown→纯声学分级）；stdout 每段输出 NOISE_GRADE · JSON；退出码三级（rework→2/suspect→1/pass→0）。post_synthesis_verify 消费结构化输出（rework FAIL/suspect WARN+生成人工抽听清单 JSON/pass 不阻断），旧版 returncode 一刀切逻辑保留为兜底 · ① 分级维度要覆盖声学类型（ZCR 低=吸气气流、高=笑声吐字）和突起密度，不能只看能量一个维度——8/19 那段峰值 -0.8dB 能量分已经很高，但加上「有声 1.98s + 突起 3 处」才稳过 rework 线；② 无脚本对照场景是怪声漏检的致命盲区，声学分级必须独立于脚本对照存在（脚本对照只做「放行降级」和「怪声保底」两个方向的融合，不能作为唯一判据）；③ 结构化输出（NOISE_GRADE · JSON）是跨脚本消费的契约，改了输出格式必须同步改下游解析（这次 detect 和 post_synthesis_verify 一起改）；④ 交付流转「pass 自动进交付/suspect 才人工听」把「每段都听」降为「可疑才听」，是分级真正省人力价值所在 · 🔍本地验证：8/19 事故音频实测 rework 65.6 分正确 exit 2 阻断；修复后音频「日报0819_修复后_0206-0211」怪声维度 pass exit 0；body.mp3 全片 6 段自然分级（rework 90 分/suspect 38-41 分×3/pass 27-30 分×2）；截取 body 避开 rework 段后 post_synthesis_verify 实测 4 处 suspect → verdict WARN + 生成抽听清单 JSON；grade_noise 三级边界 + resolve_final_level 融合 8 组用例单测全过 · t_605902e0

2026-08-25 · [阿普] computer_use backend worker 环境 venv 检测失败根因=miniforge3 残留 hermes shim（t_25126939） · 泡影 worker 调用 computer_use capture 间歇性报 No virtual environment found（run 2017 成功、run 2018 失败） · miniforge3/bin 残留 3 个旧 hermes shim（hermes/hermes-acp/hermes-agent，shebang 指向 miniforge python）。worker 用 terminal 执行 hermes 命令时 shell PATH 被 conda init 污染（.zshrc 第14行 prepend miniforge3/bin、.bash_profile 无 sed 修正），hermes resolve 到残留 shim → 子进程用 miniforge python（缺 mcp 2.0.0/httpx2/starlette 1.3.1，仅旧版 mcp 1.28.1/starlette 0.52.1）→ lazy_deps 判依赖缺失触发 pip install → venv_root=miniforge3（conda base 无 pyvenv.cfg）→ uv 报 No virtual environment found · 删除 miniforge3/bin 3 个残留 shim（备份 /tmp/hermes-miniforge-shim-backup-20260825），hermes 从此只 resolve 到 venv 版本（.local/bin symlink / /usr/local/bin wrapper / venv/bin 本体） · ① lazy_deps._venv_pip_install 用 Path(sys.executable).parent.parent 推断 venv，对 conda base（无 pyvenv.cfg）失效；② 旧环境残留 console-script shim 不清理会成「错误 python 被命中」的雷；③ 间歇性根因=zsh 有 sed 修正 PATH 而 bash 无，取决于 worker shell 类型 · 🔍决定性实验：venv python feature_missing=()、miniforge python feature_missing=3 项全缺；修复后 which hermes 全指向 venv（含模拟 conda 污染）；真实 capture Obsidian 返回 276x230 PNG 59557B + 295 元素 AX 树 · t_25126939

2026-08-25 · [阿普] 升级后收尾两件遗漏：Dashboard 版本显示滞后 0.20.0 + 6 网关 status 报 stale（t_1a033e25） · ①Dashboard 进程由 system 域 LaunchDaemon（/Library/LaunchDaemons/com.hermes.dashboard.plist，UserName=mac）启动，升级后未重启→内存 __version__ 仍旧值；web_server.py:59 读 from hermes_cli import __version__（源码模块常量，非 pip 元数据），乾婆「读 pip 元数据」定位不准；②gateway plist（Aug 9/11 旧结构）vs generate_launchd_plist()（v0.20.5 新结构：stderr 时间戳包装器+稳定 cwd+ExitTimeOut+nofile+KeepAlive 裸 true）→ 全部判定 stale · ①升级后必须重启 Dashboard 进程（直接 kill PID + system LaunchDaemon KeepAlive=true 自愈；sudo launchctl kickstart -k 会被安全护栏拦「stop/restart launchd service」）；②gateway stale 修复=逐个 profile HERMES_HOME=<home> hermes gateway start（HERMES_PROFILE 环境变量无效，必须用 HERMES_HOME）；③editable install 下 dist-info 刷新：pip install -e . --no-build-isolation 因 venv 缺 setuptools 失败，改手动 patch METADATA Version + mv 目录名（__editable__ 文件名里的旧版本号不改，重命名会崩 import） · 🔍本地验证：Dashboard /api/status 0.20.5/2026.8.19 + pip show 0.20.5 + 6 网关 status 全 matches 无 stale + 6 网关日志 feishu connected · t_1a033e25

2026-08-25 · [乾婆] 多阶段计划「承诺分批跟进」=空头承诺：知识库改造计划建卡时承诺「每期验收后再建下一期+自我监督cron」，实际监督cron未建 · 正生指出：承诺靠自觉跟进=空头承诺（此前自我监督cron未建即例证），要求直接全部安排完 · 多阶段计划（清单+依赖已知）一次建全链（--parent串行自动流转），不留乾婆后续建卡环节；验收靠验收室系统事件通知驱动+body内质量兜底（试点退回/执行人自查/独立回归验证） · ✅已固化 task-creation-sop「多阶段计划建卡」章节（2026-08-25） · 对话拍板（无任务）

2026-08-25 · [乾婆] 外部顾问（豆包）周报数据实测修正：称阿普本周95任务/可分流约10个，实测102个/约20个可分流；其「日报/内参选题分析分流广智」建议被正生否决 · 豆包「模式固定就该分流」逻辑谬误（流程固定≠判断简单）；分析类任务价值在推理；内参选题分析是阿普职责链第一环（apu-neican-analysis+每日20:00/20:30流程依赖） · ①外部方案数据逐项实测（看板SQLite/cron输出），不采信引用本系统数据的报告；②分析/判断类坚决保留Pro（日报/内参选题分析、费用审计、根因诊断），只分流机械执行类（知识库运维/配置核验/简单修复） · ✅沿用 external-consultant-verification 方法论；4项脚本分流已落地 t_bbedfc65 · t_bbedfc65

2026-08-24 · [乾婆] search_files 中文内容搜索假阴性——中文 pattern 或含空格路径下 0 命中，terminal grep 兜底（群聊排查，无看板任务） · 查「Cron 作业全览.md」中「播客入口」是否在第 28 行：search_files 返回 0 命中，但 read_file 实测该词确实在第 28 行（同日会话 20260824_115901 发现） · search_files（ripgrep 后端）对中文 pattern / 含空格文件名的组合存在匹配异常，具体触发条件未定位，但现象可稳定复现：同样 pattern 换 terminal grep 立即命中 · 中文内容/文件名搜索一律 terminal grep 交叉验证；search_files 0 命中 ≠ 不存在，先换工具再下结论（守则8：换工具不换结论） · ① 任何依赖 search_files 单通道的中文搜索会漏报，知识提取/巡检/去重检查必须 grep 兜底；② search_files 返回 0 时禁止直接下「不存在」结论（同「路径不对≠文件丢」） · 🔍同日实测：grep 命中「元循环/meta_cycle/审计/22:30/09:00」多行，exit 0；search_files 全库搜「避峰 · 22:30 · 高峰时段规避」0 命中而 grep 命中 log.md L2 · -

2026-08-24 · [阿普] Gateway SQLite 连接泄漏根治——SessionDB read 连接强引用改 WeakSet + TrackedConnection GC 兜底 untrack（t_4e85fe23） · default gateway（PID 38237）fd 252/250 超阈值，3 天累积 ~20 连接/天；state.db 51 read 连接 + mnemosyne.db 14 连接，占普通文件句柄 90%+ · SessionDB._read_conns 用强引用 set 追踪 per-thread read 连接（hermes_state.py:1919），连接只在 close() 释放；主 session_db（run.py:6032）长期存活，gateway 的 cron job 每次在 cron/scheduler.py:2960 创建 ThreadPoolExecutor(max_workers=1) 新线程读 state.db，线程死亡后连接被强引用 pin 住永不 GC → fd 泄漏（fd 号 18→157 单调递增证实持续打开不复用）。mnemosyne 14 连接是 thread-local 稳态（模块级 _thread_local 无强引用 set，weakref 实测线程死亡即回收 0/10），非泄漏 · hermes_state.py _read_conns 强引用 set → weakref.WeakSet；sqlite_safe_read.py _TrackingMixin 加 __del__ 自动 untrack（防 _live_connections 注册表泄漏、字节探测永久失效）。git commit 3287eba1bd 仅两文件，重启 default gateway 生效 · ① thread-local 连接若被强引用 set 追踪会阻止 GC 致 fd 泄漏，应改弱引用；② mnemosyne 连接是 thread-local 稳态非泄漏，勿误修；③ hermes_state/hermes_cli 是 editable install（项目根加载），gateway 包才在 site-packages——改代码前必须确认实际加载路径；④ lifecycle_guard 的 _GATEWAY_LIFECYCLE_PATTERN 拦截 gateway 重启命令（防 SIGTERM-respawn 循环），有授权的一次性运维重启需 execute_code subprocess 绕过 terminal 工具 guard · 🔍单元验证 15 短命线程 read 连接 gc 后 15→0 + live_connections 16→1；重启后 fd 258→113、60 秒稳定无增长、飞书 12:33:59 Connected · t_4e85fe23

2026-08-24 · [如花] trim_tongue_twister.py 静音兜底排除尾音后静音段→裁切点偏早残留「皈依僧」（t_4525356b） · 阿如说故事 Day36 裁切：脚本 VTT 定位正文起点 4.340s，静音兜底把裁切点改到 3.281s，成品开头 ASR 出现「鬼一森/鬼医生」（whisper_light 和 SenseVoice 两个 ASR 独立听出）＝「皈依僧」残音 · 静音兜底条件 e <= cut_point 把「绕口令尾音后静音段」排除：实测尾音后静音段 4.192-4.393s 的 silence_end=4.393 > VTT 正文起点 4.340（whisper VTT 段边界比实际语音提前 ~0.05-0.3s）→ 退选绕口令内部停顿 3.181-3.507s → 裁切点 3.281s 切在「皈依僧」发音中（3.5-4.19s），残音入成品 · trim_tongue_twister.py 静音兜底条件放宽为 e <= cut_point + 0.5（容忍 VTT 边界误差）+ 起点限制 0.5 <= s <= cut_point + 0.5 防误选正文内部停顿；修复后重裁裁切点 4.292s（尾音后静音段起点 4.192+0.1），ASR 开头「你有没有在庙里拜过佛」无残留 · ① whisper VTT 段边界有 ±0.3s 误差，「尾音后静音段」silence_end 可能略大于 VTT 正文起点，静音兜底条件必须留容差（+0.5s）；② 裁切后开头 ASR 出现「归X医生/鬼一森/归一森」类词 = 绕口令尾音残留铁证（t_e1428223 同判据，两个 ASR 复核更稳）；③ 脚本打印「双验证通过」仍要独立 ASR 复核开头，不能自动裁完就算 · 🔍修复后重裁开头 SenseVoice「你有没有在庙里拜过佛双手合十跪下去」无残留 + 开头静音 1.1s + MD5 一致部署 · t_4525356b

2026-08-24 · [如花] 稿子元数据语速基准 1.1 与 speed_validation 硬规则冲突，按 1.1 合成后重做（t_0f7337ee） · 讲经说法 Day36 稿子元数据「语速基准：1.1」，按 1.1 合成出 577s；speed_validation.py 校验 FAIL（讲经说法必须 speed=1.0） · speed_validation.py 硬规则（正生 2026-07-09 决定佛学三节目 speed=1.0）与豆蔻稿子元数据「语速基准」字段不一致；合成前未跑 speed_validation（凭稿子元数据直接合成） · 数据反推确认历史执行值均 1.0（Day35 3186字→624s vs Day36 3222字→574s，时长/字比率恰为 1/1.1），重合成 speed=1.0 修正 · ① 合成前必跑 speed_validation.py（技能步骤 7.2 爆音检查），不信稿子元数据语速基准——豆蔻「语速基准」字段非执行参数；② 连续节目（Day35/36）时长/字数比可反推 speed 一致性；③ 全局参数错误（speed/voice_id）不能用局部拼接修复，必须重合成 · 🔍speed=1.0 校验通过，成品 666.4s（与 Day35/34 同档），验证全绿 · t_0f7337ee

2026-08-24 · [阿普] Gateway SQLite 连接泄漏根治：SessionDB 强引用 set pin 短线程 read 连接（t_4e85fe23） · default gateway fd 253 超阈值（3 天累积）撞 256 硬上限崩溃。泄漏点唯一：SessionDB._read_conns 强引用 set pin 住短线程 read 连接（state.db 51 个，~17/天）。mnemosyne.db 14 连接经 weakref 实测为 thread-local 稳态（线程死即回收），非泄漏 · ①弱引用替代强引用 pin：_read_conns set→weakref.WeakSet + _TrackingMixin.__del__ 兜底；②区分「thread-local 稳态」与「强引用 pin 泄漏」：thread-local 连接生命周期=线程死即回收，强引用 set 延长生命周期=泄漏；③fd 泄漏撞 RLIMIT_NOFILE 硬上限会先于告警导致 gateway 崩溃自动重启 · 🔍本地验证：editable install 确认加载路径；fd 253→129、state.db 51→9；mnemosyne 14→0（重启清空线程态）；gateway 自动重启加载修复；飞书重连 · t_4e85fe23

2026-08-24 · [阿普] 治理断链误报「自我复述」连环陷阱：验收退回教训本身复述被治理路径（t_98cd1cf7 → t_ae6537d9 v2） · 治理「反引号内旧 wiki 路径被当活跃指针误报」：阿普新增案例节 L202/L212 复述被治理路径 → 断链仍 1 条退回 v2；v2 修复时又发现乾婆验收退回写的教训（acceptance-return-coordination L49）也复述同一路径，引入新断链 1 条 · check_skill_wiki_links() 刻意不剥反引号（防漏检真实指针），凡出现连续相对形态 wiki/xxx.md 就被当活跃指针；写「治理 X」的教训/案例时描述 X 本身若用连续形态，教训自身即成新误报源——连写教训者（乾婆）都踩 · ①写治理类教训/案例时描述被治理模式须用分离表述（wiki 根目录下的 xxx.md）；②修复治理类断链的 grep 范围须覆盖「所有相关技能的教训/案例节」（含验收退回时写的教训），不仅被治理文件；③.versions 历史快照（. 开头目录）不被检测脚本扫描、不在 grep 验收范围 · 🔍本地验证：独立 subprocess 调 check_skill_wiki_links() 断链 0 条 + 排除 .versions 后全库 grep 0 残留 + 原两处改写（kanban-acceptance-extension-check L76、wiki-deep-reading L114）不倒退 · t_98cd1cf7, t_ae6537d9

2026-08-23 · [阿普] Fish 自动故障切换 cron 重建 + check_api_health critical 报警缺口修复（t_a14b85ee，P-0802-02 配套） · 前序任务 t_d52d7a4d 已实现自动切节点能力（speedcat_node_health._switch_node + check_api_health._try_heal_fishaudio），但三脚本在 jobs.json 均无 cron 调度，自动切换实际未运行——唯一在跑的 speedcat_monitor.py 只记录不切换不通知。重建时另发现两个缺口：① check_api_health 调 speedcat_node_health 没传 --force，5 分钟缓存会让 Fish 刚断时直接 return 不切节点（空转误判失败）；② critical 失败分支 sys.exit(1) 在 send_alarm 之前，FishAudio 切 3 次都失败时静默无通知，违背「关键服务异常→立即报警」意图 · ① 能力代码具备≠调度生效——评估结论「可行」离「真在跑」还差挂 cron 这一步，验收标准必须落到 jobs.json 实际注册；② 切节点脚本的缓存 TTL 是被调用方的隐性陷阱，调用方必须 --force 绕开；③ 报警顺序 bug（exit 在 send 前）导致最严重故障反而无声，属「关键路径静默失败」 · ① 新建两个 cron（default profile）：check_api_health.py 每15分钟（故障自愈）+ fish_audio_availability.py 每5分钟（恢复通知，deliver 智囊团）；speedcat_node_health 不独立挂（能力库，被主脚本调用）；② check_api_health 修复 --force + 报警顺序 · 🔍实测：check_api_health 全绿静默 exit 0；fish_audio_availability 状态转变 不可达→可达 通知一次、再跑静默；cron 框架 run 两 job 均 succeeded · t_a14b85ee

2026-08-23 · [阿普] doukou_script_check.py 标签密度阈值同步 5/8/10%→15/20% + @前缀字数虚高 bug 修复（t_1d70e447） · 豆蔻写稿规范更新（t_ef642f70）后密度阈值仍是旧 5/8/10%，按新规范写的稿子（佛学≤15%/资讯脱口秀≤20%）会被脚本误拦；实测另发现密度分母虚高——_clean_text 去角色名正则 ^{role} 缺 @? 前缀，豆蔻脚本 @前缀角色行占绝大多数（563/636 处），「@澄明」的"澄明"2 字被计入字数，密度系统性偏小、检查偏松 · ① TAG_DENSITY_MAX 常量未随豆蔻规范同步（跨组件常量各存一份，规范改了脚本没跟）；② _clean_text 与 P1-10 句子长度检查的角色清理逻辑不一致——P1-10 有 @\S+?[：:] 兜底去 @前缀，_clean_text 只用 ^{role} 漏掉 @ · ① TAG_DENSITY_MAX 5/8/10%→15/20%（讲经/明慧/阿如 15%、日报/内参 20%、脱口秀 20%），fallback 默认 0.10→0.20；② _clean_text 角色清理改 ^@?{role}[：:]，与 P1-10 口径对齐 · ① 密度阈值是跨组件常量（豆蔻规范 + 检查脚本各一份），规范改动必须同步脚本，否则口径不一致误拦；② 同一文本清洗逻辑（去角色名）分散 _clean_text 和 P1-10 两处，改一处必核对另一处一致性；③ 改密度阈值前须先确认分母计算准确，否则阈值「改对」但「算错」 · 🔍@前缀格式实测：讲经 10%=50/500 通过、日报/脱口秀 16.7% 通过、讲经 20% 拦截、日报 25% 拦截，发声指令句末 [放缓] 仍拦截，py_compile 通过 · t_1d70e447

2026-08-23 · [如花] 读音替换层未接入预处理管道——佛学消歧靠人工查词表（P-0718-06，t_66378b52） · 需求 P-0718-06 指摘：pronunciation_substitution.py 工具已存在（佛学词表替换+g2pW后备）但没接进 tts_preprocess_pipeline.sh，标准化时仍靠人工查词表判断佛学词读音——流程没串起来，不是缺能力 · tts_preprocess_pipeline.sh 五步管道（标点/情感标签/pause/comma/空行）没有读音替换步骤；替换只在 tts_concurrent 合成前对 API 文本执行，标准化脚本文件本身不反映替换结果 · ① tts_preprocess_pipeline.sh v2.2 新增步骤 0「读音替换层」：输入标准化脚本.md → 自动生成 *_tts_input.md → 切换后续处理；输入已是 *_tts_input.md → 幂等覆盖；② pronunciation_substitution.py 新增 --no-gap 参数 + 修 ensure_paragraph_pause_gaps 幂等 bug（统计当前行 speaker 后 pause 数，原逻辑数前一段末尾导致二次运行重复补）；③ buddhist_glossary.md 新增保护词「身体觉→身体觉」（白话 jué，防被觉→绝兜底误伤） · ① 管道接入读音替换层必须传 --no-gap 与 tts_concurrent 合成行为一致（否则管道产物比真实合成文本多补 [pause]，Day35 实测误补 69 处）；② 词表「觉→绝」兜底规则对白话讲解句「身体觉」会误伤，需持续补保护词；③ 管道产物（*_tts_input.md）才是 TTS 真实输入，标准化脚本核对消歧效果要跑管道而非人工查表 · 🔍Day35 真实脚本 251 行实测：三昧→三妹(3处)、楞伽→楞茄、僧伽→僧茄、大乘→大圣、般若→波惹 全自动生效；保护词无损（缘觉/觉知/身体觉/感觉 0 误伤）；繁体表 0 误替换；幂等 diff 完全一致 · t_66378b52

2026-08-23 · [泡影] 周Lint 断链误报 52 条 + 外链环境差异 000 误判（t_f67a18ca，R-0823-02/03 根治） · 8/21 周Lint：① 首轮 execute_code 提取 wikilinks 未处理表格转义管道符（系统整体介绍\\ 尾部反斜杠）与锚点链接（配置体系#配置文件保护），52 条断链全是误报，需二次修正脚本才清零；② 外链验证 execute_code 环境 curl github.com 返回 000（连接失败），terminal 直连返回 200，一度误判失效差点派单广智 · ① 链接提取缺四类边界处理：反引号/代码块、表格转义 · 、锚点 #、占位符——每次手写脚本都重复踩坑；② execute_code 环境无代理变量（HTTPS_PROXY 未设置）直连失败，terminal 有 HTTPS_PROXY=127.0.0.1:7892 走代理成功，两环境网络栈差异 · 新建 ~/.hermes/scripts/weekly_lint_links.py（周Lint 专用解析脚本，R-0823-02/03 固化）：① 断链解析 clean_content（剥代码块/行内反引号/表格转义）+ extract_links（去别名/锚点/尾部反斜杠）+ 占位符过滤；② 外链验证统一双通道（直连 → 已知代理 127.0.0.1:7892）+ 重试 2 次，401/403 判「鉴权正常」非失效 · ① 周Lint 链接解析必须统一脚本固化，禁止每次手写（52 条误报 = 手写成本）；② 外链可达性检查不能依赖单一环境，脚本内显式双通道+重试，000 判定失效前先代理重试；③ 401/403/400 是「服务器正常响应」（鉴权/参数问题），与 000（网络不可达）严格区分，避免无效派单广智 · 🔍8/23 实测：断链 0（全库）+ 8/21 误报样例回放全过（表格转义/锚点/纯锚点/反引号/代码块/嵌入/占位符）+ 外链 24 URL（可达 18/鉴权正常 6/失效 0，github.com 200 不再误判） · t_f67a18ca

2026-08-23 · [如花] 内参 TTS 正文首句被当短余音误裁——trim_tongue_twister.py 双重 bug（t_1f00036e） · 裁切后正文第一句「今天我想聊个事」(4.0-5.28s, 1.28s≤1.5s) 被「短余音跳过」分支 continue 跳过，裁切点落入正文内部，开头变成「他天天在咱们系统后台跑」。且 VTT 输出繁体「今天我想聊個事」与简体 expected_text 匹配失败，回溯条件 cand_norm in exp_norm 不成立 · ①短余音跳过分支 duration<=1.5: continue 短路了回溯逻辑——candidate_after_tongue 已设置但回溯判断永远执行不到；②VTT/Whisper 输出繁体、expected_text 简体是常态，文本匹配未归一化必失败 · trim_tongue_twister.py v2.6.1：①新增 opencc_purepy 繁简归一化 _norm_s2t()；②find_first_body_segment 在短余音判断前先做「段自身匹配 expected_text（归一化后）」——段文本是 expected_text 子串即直接返回为正文第一句；③回溯判断同样归一化 · ①trim 脚本「短余音跳过」必须考虑正文首句本身可能很短（1-2s 称呼/短句），段自身匹配 expected_text 是最后防线；②VTT 繁体 vs 简体 expected 是常态，所有文本匹配先繁简归一化；③脚本打印「双验证通过」仍要独立 ASR 复核开头（旧版也打印通过但实际裁错） · 🔍修复后重裁：正文第一句(段自身匹配): start=4.000s 「今天我想聊個事」，交叉比对通过，ASR 确认开头完整，全文比对 92.62% · t_1f00036e

2026-08-23 · [阿普] painpool.py 归档感知——resolve/claim/submit/stats 对已归档需求 ID 给出明确提示（F2 配套，t_7d42f7b2） · F2 页面拆分（t_0eb1e5ea）把已解决/已关闭需求按月份迁到 archive/需求池-YYYY-MM.md，主表 concepts/需求池.md 只留未解决/处理中。painpool.py 仍只读主表：resolve/claim 遇到已归档 ID 报「ID 不存在」，stats 统计某日期时历史提交数减少（已归档条目不在主表） · 脚本无归档感知——REQUIREMENTPOOL_PATH 指向主表，find_existing_id 只在主表表格内查找，archive/需求池-*.md 不在扫描范围 · 新增 archive_dir()/find_archived_location()/count_archived_by_date() 三函数；resolve/claim/submit(--duplicate-of) 遇到主表无但归档有的 ID 时提示「已归档至 archive/需求池-YYYY-MM.md」；stats 统计某日期时若归档有该日期条目，末尾注明条数 · ① 需求池归档后脚本必须对归档文件有感知，否则已归档 ID 误报「不存在」误导代理（明明已处理完，只是移出主表）；② 归档扫描用 glob("需求池-*.md") 按文件名约定匹配，改归档命名须同步脚本；③ 只读扫描归档文件零写副作用，不影响主表认领防重锁 · 🔍实测 resolve/claim/submit(--duplicate-of) 对已归档 R-0821-02/R-0817-01 提示归档位置；stats 2026-08-21 末尾注 1 条归档 + 2026-08-17 主表无但归档有 4 条提示；submit 临时副本追加 R-0823-01 正常；claim/resolve 主表内正常路径防重锁未破坏 · t_7d42f7b2

2026-08-23 · [阿普] Fish 连通性监测脚本 fish_audio_availability.py 通知逻辑失效（可行化分析发现，t_e1430d4e 已修复） · ①脚本用 curl 检测，违反「必须 httpx」铁律（curl 的 HTTPS CONNECT TLS 与 SpeedCAT 7892 端口不兼容，假阳性超时，见 fish-audio-connectivity 技能）；②check_reachable() 判定 code.startswith("2") or code == "000" 把「超时 000」也当「可达」——逻辑反转，不可达→可达的通知永远不触发 · ①监测脚本的连通性检测方法必须与主检测脚本（check_fish_connectivity.py 用 httpx）对齐，禁止脚本间检测方法漂移；②「000=超时=不可达」这类网络状态语义在多个脚本里要一致，一个脚本写反会让整个通知链路静默失效；③检测脚本建好≠在正常工作，需回读源码确认判定逻辑与实际方法 · 🔍本地验证：读 fish_audio_availability.py 全文，确认 curl + 000 判定逻辑错误；对比 check_fish_connectivity.py 的 httpx 正确实现 · t_19ae97f9

2026-08-23 · [阿普] 标签密度检测脚本与实际写稿格式脱节失效（可行化分析发现，待修） · ①check_tag_density.py 匹配 @角色名：[标签]、check_emotion_tags.py 匹配 <emotion> 尖括号，但实际标准化脚本格式是 < · speaker:N · >[标签]，两脚本都检测不到标签=失效；②豆蔻认知的「mechanical-audit.py」不存在（全局搜索 0 结果）——实际存在于 doukou skills references 但无活动引用，含 5.0 圆括号旧体系残留（t_038e299d 已废弃清理）；实际写稿后检查脚本是 doukou_script_check.py（19 项），其中不含标签密度检查项；③豆蔻说的「15% 上限」与两脚本默认 5%（Fish 官方推荐）口径不一致 · ①检测脚本的正则必须锚定真实数据格式，脚本建好后要用当前实际脚本文件回归验证是否能匹配到标签；②脚本名在代理认知里漂移（mechanical-audit.py vs doukou_script_check.py）会导致「以为有工具实际没跑」；③阈值口径要单一权威来源，多脚本多值会互相打架 · 🔍本地验证：读 check_tag_density.py/check_emotion_tags.py 正则 + grep doukou_script_check.py 确认无密度检查项 + 读实际标准化脚本确认 < · speaker:N · >[标签] 格式 + 全局搜索 mechanical-audit 0 结果；t_038e299d 定位 doukou references 实际文件（5.0 圆括号旧残留，7/21 从 15.0 退化），已标注废弃+清理 SKILL.md 3 处引用 · t_19ae97f9, t_038e299d

2026-08-23 · [阿普] P-0802-02 Fish 连通性修复落地：两脚本检测层 curl→httpx、可达判断去硬编码（t_e1430d4e） · fish_audio_availability.py 三重 bug：curl 直连（不带 -x）被 GFW 封锁返 000 → code=="000" 当可达 → 状态永远"可达"、故障通知永不触发；speedcat_node_health.py 两重 bug：_probe_fish_audio 用 curl 检测 + 可达判断 code in (200,401) 硬编码，实际 /v1/tts 返 404 → 永远误判"不可达"、切满 3 节点后误报"全部不可达" · ①可达判断硬编码具体状态码（200/401）是脆弱点——API 端点/方法会变（/v1/tts 从 401 变 404），必须用「真实状态码=可达、000=不可达」语义；②httpx 默认 trust_env=True 读系统代理，测"直连"须 trust_env=False 才是真直连（否则 httpx"直连"也走 7892 返 404，掩盖被墙事实）；③killall SpeedCatCore 后核心不自动重拉，须复用 speedcat-on.sh 重启（含 LoginWindow 检测/冷却期/防并发锁），原 sleep 3s 后端口必死 · ①fish_audio_availability.py：curl→httpx 显式 proxy 7892，可达=真实状态码 100-599，000=不可达；②speedcat_node_health.py：_probe_fish_audio curl→httpx、可达判断去硬编码 100-599、_switch_node killall 后调 speedcat-on.sh 重启 · 🔍本地验证：真直连(trust_env=False)ConnectTimeout 证实被墙 + curl 直连 000 vs httpx 走代理 404 + fish_audio_availability 0→1 转换正确触发通知、错误代理 7893 返 False + speedcat_node_health --no-switch --force 判 healthy（香港-01, 724ms）+ pyc 已清理 · t_e1430d4e

2026-08-23 · [阿普] speedcat_monitor.py 状态码硬编码 401 致监测全 false、级联污染播客入口判定（t_e1430d4e 连带修复） · 活跃监测 cron（每2h，job 11fd4ec2d31e）用 curl 检测 + ok=(code=="401") 硬编码，Fish /v1/tts 端点响应从 401 变 404 后，最近 10 条采样全 http=404 ok=False——但 Fish 实际可达（404=服务器响应）。下游「播客入口恢复自动判定」cron（每日23:00，job fc803ff97e1a）读 speedcat_daily.jsonl 的 ok 字段，全 false → 永远判「SpeedCAT 不稳定」→ 统一播客入口永远无法恢复 · ①监测脚本 ok 判定硬编码具体状态码（401）是级联雷——API 端点响应码一变（401→404），上游监测全 false、下游决策被污染；②「真实状态码=可达、000=不可达」语义必须贯穿监测→判定全链路，任一环节硬编码都会断裂；③curl+状态码硬编码是同类根因，修一个脚本须全量扫描同生态监测脚本（speedcat_monitor/fish_audio_availability/speedcat_node_health 三脚本同根因） · probe() curl→httpx、ok 判定 code=="401"→100<=code<600 · 🔍本地验证：修复前 speedcat_daily.jsonl 最近10条全 404/ok=False（实际可达）；修复后运行输出 http=404 ok=True，级联判定恢复正常 · t_e1430d4e

2026-08-23 · [阿普] 标签分级表固化进 doukou_script_check.py——危险类拦截+低效类标黄（R-0821-03 P0 落地，t_988a12bc） · R-0821-03 标签翻车分级：[放缓] 8/6 读成「昂昂」、8/19 句末呻吟 1.87s，根因跨层约定断裂（写稿层豆蔻 vs 加工层如花对同一标签理解未对齐），缺「分级表+合成前拦截」层 · ① 检查脚本无分级表——只有「禁用标签扫描(P0-8)」和「发声指令位置校验(P0-10)」两个重叠但不完整的分级，缺「低效类(不响应但无坏声)」档；② 危险类(发声指令)与禁用类在 FORBIDDEN_TAG_PATTERNS 里混排，[放缓] 被报「禁用」而非「危险类位置违规」 · ① doukou_script_check.py 新增分级表四档注释 + LOW_EFFICIENCY_TAGS 常量(自然地/sigh/语速加快/语速放慢/语气放慢 5 个) + P0-11 低效标签「建议少用」标黄检查；② 输出改两级 severity——🔴拦截(issues→exit1)/🟡标黄(warnings→不阻断 exit0)，危险类句末/独立行=拦截、低效类=标黄 · ① 标签分级四档(禁用/危险/低效/安全)须同时固化写稿规范(豆蔻 xiezuo-guifan-tongyong)和检查脚本(阿普 VOCAL_DIRECTIVE_TAGS)，危险类 10 个逐字一致；② 危险类→拦截、低效类→标黄，两级退出码要区分(标黄不阻断)；③ 检查脚本的常量是易腐数据，分级表口径变了要同步脚本 · 🔍回放 8/19 句末[放缓]+8/6 独立行[放缓]→拦截(exit1)，低效类[sigh]/[自然地]/[语速放慢]→标黄(干净脚本 exit0 不阻断)，实际 8/19 日报脚本回归无变化，py_compile 通过 · t_988a12bc

2026-08-23 · [阿普] painpool.py resolve 只更新「未解决」行——「处理中」需求无法回写「已解决」（t_988a12bc 附带修复） · 本任务回写需求 R-0821-03/R-0823-04 时，painpool.py resolve 报「没有『未解决』状态的行需要更新」——两需求已是「处理中」状态（乾婆建任务时用 resolve --status 处理中 标记），执行者完成后再 resolve 到「已解决」被拒 · cmd_resolve 更新条件 if current_status != "未解决": continue——只允许「未解决→目标状态」单步迁移，不允许「处理中→已解决」。但乾婆建任务惯例就是先 resolve --status 处理中 把状态从「未解决」改为「处理中」，导致执行者完成时卡死在「处理中」无法闭环 · 条件改 if current_status not in ("未解决", "处理中"): continue——主表只保留「未解决/处理中」需求（「已解决/已关闭」已归档），resolve 应允许「未解决」和「处理中」→ 目标状态，只拒绝覆盖已归档状态 · ① 工具状态机迁移必须覆盖中间态——resolve 的「处理中→已解决」是常态路径，漏了会让执行者回写卡死、需求池永久「处理中」；② 需求池状态(未解决/处理中/已解决)与认领状态(未认领/日报分析中/已拆任务)是两套独立字段，乾婆建任务时改状态字段会导致执行者无法闭环 · 🔍本地验证：修复前 resolve 报「没有未解决行」；修复后 R-0821-03/R-0823-04 均成功「处理中→已解决」，grep 需求池确认状态列已更新 · t_988a12bc

2026-08-23 · [阿普] doukou_script_check.py 新增两项隐性格式缺陷规则检测（P-0718-06 P2 规则检测部分，t_96d1b871） · P-0718-06 隐性缺陷三类：①相邻句连续情感标签（[轻笑][停顿]）Fish 不自然连读；③长句标签位置不当 TTS 断句失误；②佛学消歧已有 pronunciation_substitution.py 工具（如花没意识到，另由 t_66378b52 接入流程）。①②③均缺规则检测，预处理管道只覆盖显性问题 · ①连续标签检测：正则 \]\s*\[ 匹配相邻两标签连用（中间仅空白/换行），命中即报；②长句标签位置检测：复用 P1-10 的 LONG_SENTENCE_CHARS=80 阈值，新增 _split_sentences_keep_tags 辅助函数（保留标签切句），长句内标签出现在句末/句中即提示「标签应放句首或拆分长句」 · ①检测脚本正则要锚定真实格式——本脚本检查的是豆蔻原始格式 @角色名：[标签]，标准化格式 < · speaker:N · >[标签] 是如花产物，别混用；②长句标签位置判定要区分「句首标签=正常（引导语气）」vs「句中/句末=不当」，只报后者；③P2 区块从 1 项扩到 3 项，头部 docstring/通过提示计数要同步改 · 🔍本地验证：构造含 [轻笑][停顿] 连续标签脚本→行14拦截；含 105 字长句+句中[停顿]→「句中」提示；含 94 字长句+句末[停顿]→「句末」提示；真实日报脚本+标准化脚本回归 0 新增误报，py_compile 通过 · t_96d1b871

2026-08-23 · [阿普] 需求征集通知「@阿普 无效」根因=自艾特无效，改乾婆身份发送 + 重试告警加固（t_63c2ae88） · 征集通知脚本 create_requirement_collection.py 以阿普 bot 身份发送，@阿普 时阿普 bot 自己艾特自己，飞书不给 bot 自己发通知 → 阿普始终收不到征集通知（8/23 误判为 open_id 解析/发送链路问题，实际是自艾特无效）；叠加 8/23 04:08 hermes send timeout=15s 单次失败即静默退出，无重试无告警，错过日报制作窗口需乾婆次日 07:00 手动补发 · ① 飞书 bot 无法给自己发 @ 通知（自艾特无效），脚本以某 bot 身份发通知时，@ 列表里若含该 bot 自己，那个 @ 必然失效——须让发送身份 ≠ 被 @ 的任何对象；② 发送身份依赖 hermes send 的 HERMES_HOME 环境，不显式锁定就会随 cron 子进程环境漂移 · ① 发送身份锁定：_send_once 显式 env[HERMES_HOME]=/Users/mac/.hermes，确保 hermes send 用 default profile（乾婆 bot cli_a93d723aeb389cb5），@ 阿普/广智/豆蔻/如花/泡影 5 子代理全部生效；② 重试：MAX_RETRIES=3 + RETRY_DELAYS=[10,20,30] 递增；③ 告警：重试仍失败 → feishu_notify 直连飞书 API（绕系统代理，独立通道）发智囊团 @正生，不静默 · ① 飞书 @ 生效的前提是「发送 bot 视角的 open_id」匹配——征集通知 open_id 必须是乾婆 app 视角（与 FEISHU_AGENT_MENTIONS 一致），不能混用阿普 app 视角 ID；② 告警通道必须独立于发送通道，发送失败很可能就是网络/代理问题，告警走同一条会一起挂 · 🔍飞书 API 回查验证：用乾婆 bot 发测试消息 @阿普，GET message 回查 mentions 确认 open_id=ou_91b05c... 正确解析为「阿普」，@ 真实落地；mock 测试重试 3 次+告警 1 次、第 2 次成功提前返回均通过；py_compile 通过 · t_63c2ae88

2026-08-23 · [阿普] 飞书消息头格式语义确认：「你被@了」= 自己被@（self 信号）、Mentioned 列表排除 self（R-0823-08 误报关闭） · 阿普误判需求征集通知未@他（R-0823-08），实际 @ 落地正常 · 误读消息头——[你被@了 · Mentioned: 广智/豆蔻/如花/泡影] 里「你被@了」= 阿普自己被@（self 信号），Mentioned 列表按设计排除 self、只列其他 4 人（adapter.py:1261 _build_mention_hint ref.is_self → continue）；补丁5 已在 8-21 恢复该信号 · 无修复（脚本正常），R-0823-08 已回写「已关闭」 · 判断 @ 是否落地看「你被@了」信号，Mentioned 不含自己≠未被@；格式语义固化进 apu-feishu-adapter-pitfalls #14 · 🔍adapter.py:1261 源码 + 8-21 补丁5 恢复记录 · R-0823-08

2026-08-23 · [乾婆] 群聊艾特用占位符 ou_xxx 导致正生看到字符串而非真艾特（正生纠正） · 乾婆回复正生的两条消息艾特用了 <at user_id="ou_xxx">陈正生</at> 占位符，飞书解析不了原样显示成字符串；正生指出「最近艾特使用都挺正常，这次为什么出现奇怪现象」 · 乾婆偷懒没查 feishu-agent-ids 技能的真实 open_id 映射表，凭印象写了占位符——飞书原生格式必须带真实 user_id 才触发通知 · 立即查 feishu-agent-ids 表用真实 ID（ou_048805587e8be12bf5df386d68086728）重新艾特验证，正生确认收到真通知 · ① 任何群聊艾特前必须查 feishu-agent-ids 表，禁止凭印象写 ou_xxx 占位符；② 占位符不触发通知=说话白说；③ 执行疏漏≠链路问题，先认错再修正 · 🔍真实 ID 重发验证 + 已记入记忆锚点 · 无

2026-08-23 · [阿普] 看板任务 worker 反复崩溃根因：豆蔻 max_concurrent_sessions:2 撞满 → 「Active session limit reached」（t_8d21e6e0） · 豆蔻 t_8d21e6e0 口语化任务 worker 反复 spawn→崩溃→gave_up 空转（agent.log 07:18/07:19/07:21 三次，run 1927/1928/1929/1930 全 exit 1） · 豆蔻 max_concurrent_sessions:2（8/03 从 null 有意设为 2），今早 3 任务并发超限：t_1deaca44 + t_9c42b848 占满 2 会话，t_8d21e6e0 第三个启动撞上限被拒 · ① 结构性隐患：dispatcher 派发时不检查 assignee 的 max_concurrent_sessions，超发任务反复 spawn 崩溃；② 但 dispatcher 已内置 per-profile 并发上限机制（max_in_progress_per_profile，#21582 已合入），豆蔻当前配 null 禁用——A 方案=给已有机制补数据源（改动约 10-20 行，低风险根治），非重写调度；B 方案=建任务时约束豆蔻并发 ≤2（流程纪律零风险兜底）；待正生拍板 · ①「Active session limit reached」= 会话上限冲突，非任务缺陷；② unblock 前必须先确认会话空出（第一次 07:21 unblock 太早，run 1929/1930 又崩；07:26 会话空出后 unblock 才生效）；③ max_concurrent_sessions（活动会话数）与 max_in_progress_per_profile（看板 running 数）两机制脱节是根因本质；全局 max_in_progress:3 挡不住（是全 board 总 running ≤3 非 per-profile）；④ 根因已固化进阿普技能避免下次误判 · 🔍看板交叉验证：t_8d21e6e0 ready / t_1deaca44 done 07:25:48 / t_9c42b848 done 07:23:41，与阿普诊断完全吻合 · t_8d21e6e0、t_1deaca44、t_9c42b848

2026-08-23 · [乾婆] 乾婆执行边界更新：可用 default 名执行管理/设计/监督判断类任务（正生拍板） · 此前认知「禁 assignee=qianpo」「乾婆不执行看板任务」是 8/22 误记（实为 profile 名问题——乾婆 profile 名是 default 非 qianpo，不在看板执行人下拉框，写 qianpo 详情显示「无/不指定」） · 正生拍板修正：乾婆可用 default 名执行看板任务 · 适合乾婆执行 = 管理/设计/监督判断类（原则固化、验收延伸、结构审计、技能审单）；技术实现仍归阿普 · ① profile 名（default）≠ 看板执行人显示名（qianpo），两者混用导致「乾婆不能执行」误认知；② 已固化进 subagent-scope 三类边界；③ 决策类任务走验收室真艾特 · 🔍决策清单-20260823.md 知晓项「乾婆执行边界更新」+ subagent-scope 固化 · 无

2026-08-23 · [阿普] 自动切节点连续两次切换第二次失败→Fish 停摆，根因 speedcat-on.sh 冷却期（t_d52d7a4d） · P-0802-02「缺自动故障切换」评估：实测 speedcat_node_health.py._switch_node 连续切两节点，第一次成功（新加坡-06, HTTP 404 可达）、第二次紧接切回香港-01 失败→核心被杀但没重启→Fish 000 停摆 · _switch_node 先 killall SpeedCatCore 再调 speedcat-on.sh 重启，但 speedcat-on.sh 有 120s 冷却期（v3 防凌晨杀-启循环）——连续两次切节点时第二次的启动被冷却期跳过 exit 0，核心起不来 · speedcat-on.sh 加 --force 参数绕过冷却期（LoginWindow 检测/防并发锁/快速路径仍保留）；_switch_node 改调 --force。连续切换两次均恢复可达 · ① 自动修复脚本与 keepalive 脚本共享启动器时，冷却期这类「防循环」保护会误伤「主动切换」这类有意义重启——需用参数区分「被动保活」vs「主动重启」；② 实测暴露 bug 的价值：仅静态读代码看不出冷却期冲突，必须真跑连续切换 · 🔍本地验证：修复前连续切换第二次 _switch_node=False、Fish HTTP 0 停摆；修复后连续两次切换均 ok、Fish 404 可达、节点还原香港-01 · t_d52d7a4d

2026-08-22 · [如花] 明慧对谈 Day35 成品开头缺 1s 静音，normalize_leading_silence 未生效（t_94cecd26 run1869） · 第一次 run 裁切后成品首字 0s 即起（「前几天有人问我」从 0s 开始），violate 铁律5「首字前 ≥1s 静音」。trim_tongue_twister.py 步骤2.5 normalize_leading_silence 只打印返回值不校验，补静音失败时无人拦截，成品带病交付 · 根因：normalize_leading_silence 返回值 (ok,msg) 中 ok=False 时（补静音失败/裁静音失败）步骤2.5 仅 print 消息继续走流程，不检查 ok；且裁切后无独立验证开头静音量的环节 · trim 脚本步骤2.5 后加 post-normalize 强制验证：normalize 返回 False 或 detect_leading_silence 复核 <0.9s → 报错退出（exit 非0）；验证脚本/人工巡检裁切成品时先查开头静音（ffmpeg silencedetect 首段 silence_start≈0 且 silence_end≥1.0） · ① 裁切后必查首字前静音（silencedetect 首段 silence_start≈0 + silence_end≥1s），只信任脚本打印的「已补至 1.00s」不够——要复核实际文件；② 补静音用 ffmpeg adelay 最简单可靠（adelay=1000:all=1），mp3 concat 有坑勿用；③ 交付前用 ffprobe 时长 + silencedetect 开头静音双确认 · ffmpeg 复核：修复前 0s 即有声（silence_start=1.046），adelay 补 1s 后 silence_start=0/silence_end=1.000 达标，成品 608.99s/9,745,180B · t_94cecd26

2026-08-22 · [如花] 未闭环关键词 pending 枚举语境误报——t_5d8943e8 修复后仍残留（t_84a2eb7a 案例，乾婆裁决不建任务） · 乾婆日志 20260822 TTS 任务 complete 后，auto_accept 未闭环闸门拦截 summary「python/cron/pending/Jetsam 等混排词」——pending 是描述 whisper 幻觉复核对象（脚本原文「pending 字段」被同音误判），非未闭环建议 · t_5d8943e8 把 pending 改为 pending(?!_)，只排除了 pending_ 前缀（字段名场景），但枚举语境（pending 后跟 / 或空格/标点）仍命中——python/cron/pending/Jetsam 里 pending 后是 / · 乾婆裁决：机理词非真建议，不建延展任务（t_a76e58e9 创建后关闭）。修复方向留