[qingfengyu153781-star]

问题

record_action_sequence 用 LIKE 子串认技能，且失败从不降信。
issue #200 四条指控里 ①②④ 在基线已修，③ 仍复现：

• 50 败 10 胜后 conf 仍为 0.95，而 issue 判据要求 < 0.5。

根因

技能命中只增信、不降信：成功/失败被混在同一个"出现次数"里，
失败路径没有任何扣除项，所以反复失败也压不下置信度。

改动（3 个文件，差异恰好）

文件	说明
lingshu/core/core.py	新增 _SKILL_OK_KEY / _SKILL_FAIL_KEY 两个 engine_meta 前缀 + _bump_skill_counter()；成功与失败分别计数，失败参与降信。不动 SCHEMA_VERSION、不碰 skills 表结构（走 KV 表）
tests/test_issue200_lose_then_win_guard.py	新增守卫（4 断言）
docs/intake/body-export-v0.1/_export_manifest.json	按 main 重登记 core.py 指纹

验证（本地实跑，非推断）

判别力：修复版 4 passed，main 原版 2 failed, 2 passed ⇒ 守卫有判别力。

相关回归：引用被改模块 core 的既有测试 290 个：

2129 passed, 15 skipped in 1025.91s (17:05)

全量逐文件自证：与 main 的差异集合恰好等于本 issue 的 3 个文件。

锚定：上游 main 598eed26（验证树底座与本提交的父提交同源）。

说明

• 修复取自沙箱 def-impl-4c，按当前 main 的真实 diff 重放（非整文件覆盖）。
• 判别力与相关回归均在「当前 main 完整树」上跑，底座与 main 同提交，避免 API 版本错配造成的假红。

[FuRongJun-1999]

已修复并合并（维护侧实测）

确认属实——本端在最新 main（合并前 e2c1ec6）上以作者守卫直跑复现：2 红/8 绿（红恰为「失败降信/计数」契约面），已由 PR #1166（镜像自 #1101 净增量，合并提交 2ca383c）收口：

修法（#1101 方案原样）：record_action_sequence 的技能置信度改 Beta(1,1) 先验平滑成功率 (ok+1)/(ok+fail+2)——50 败 10 胜 ⇒ conf≈0.166（issue 判据 < 0.5 达成）；成功/失败经 engine_meta KV 计数（_bump_skill_counter/_skill_counts，不动 SCHEMA_VERSION）；建卡把建卡前失败历史折进初始置信度（无失败时 0.5，旧行为不变）。

合并后 main（2ca383c）读数：其守卫 test_issue200_skill_failure_confidence_guard（脚本式→包 pytest 收集入口，直跑 exit=0）＋ lose_then_win/skill_binding 回归全绿；CI 4/4 绿（runs 41033242612→41037886384 两轮：一轮 manifest 定因 core.py 指纹→重登记后全绿）；manifest strict 64/64。

致谢与署名：修法与守卫的净增量来自 @qingfengyu153781-star 的 PR #1101（原样保留）；#1101 未直接合并的原因是其分支基线 598eed2 先于维护侧 #1138/#1143/#1146/#1153/#1154 系（直接合并会回退已合工作，净 diff -2659 行），已按净增量摘取重放。

感谢报告与修复——「Beta 平滑成功率」的选择（而非线性降信）与「engine_meta KV 不动表结构」的克制都到位。