codebee 0.1.67 → 0.1.68

package/app/core/skillpacks/market/release-notes.md

@@ -1,72 +1,72 @@
----
-name: 版本发布说明撰写模板
-note: 面向用户的更新公告：固定六段结构 / 写作纪律 / 破坏性变更三要素 / 可复制模板与反例
-scopes:
-- "*"
-source: market
-market_id: release-notes
----
-
-# 版本发布说明撰写模板（市场包）
-
-适用：发版时写 Release Notes / 更新公告 / changelog 的用户可读部分。
-核心立场：**写给用户看，不是写给 git log 看**——用户不关心重构了哪个模块，
-只关心「这次更新后我能多做什么、少烦什么、会坏什么」。
-
-## 一、标准结构（顺序固定）
-1. **一句话概览**：这版最值得用户知道的一件事；实在没有就写「稳定性修复」。
-2. **新功能**：能做以前做不了的事。每条 = 功能名 + 用户收益 + 入口在哪。
-3. **体验优化**：以前能做、现在更快 / 更顺 / 更省的事。
-4. **问题修复**：写用户见过的**症状**（「修复导出 PDF 中文乱码」），
-   不写内部成因（「修复字体子集化模块的编码偏移」）。
-5. **升级注意事项 / 破坏性变更**：有则紧跟概览**置顶**（不按上面的顺序排），
-   没有就省略此节。
-6. **已知问题**：带着已知问题发版必须如实列出，并给临时绕过办法。
-
-## 二、写作纪律
-- 每条只说**一个行为变化**，动词开头、面向结果：「支持按标签筛选任务」，
-  而不是「重构筛选服务并接入标签存储」。
-- 收益优先于实现：先说用户能干什么，实现细节放括号或链接里。
-- 数字具体化：「启动更快」要写成「冷启动从约 6 秒降到约 2 秒」；
-  没有数据不要编数字。
-- 不用内部术语：对用户写「登录更稳定」，不写「修复 OAuth2 refresh token 竞态」；
-  这类内容放进面向开发者的附录小节。
-- 每条尽量带出处：issue / PR / 需求单号，方便日后回溯。
-
-## 三、破坏性变更的写法（最容易写砸的部分）
-- 三要素齐全：**什么会坏**（哪个行为 / 接口 / 配置）、**影响谁**、**怎么办**
-  （迁移步骤或替代写法，给可直接复制的示例）。
-- 正面示例：
-  > **升级注意**：`/api/tasks` 返回的 `status` 字段由中文改为枚举值
-  > （`running` / `done` / `failed`）。依赖该字段的脚本需同步修改，
-  > 新旧值对照表见帮助文档「status 迁移」一节。
-- 「可能影响部分用户」这类模糊表述禁止——写清判定条件，让用户 10 秒内
-  判断自己在不在影响范围内。
-
-## 四、模板（可直接复制）
-```
-## vX.Y.Z 更新说明（YYYY-MM-DD）
-
-概览：一句话说清这版最重要的事。
-
-### 新功能
-- 支持xxx：现在可以……（入口：设置 > xxx）(#123)
-
-### 优化
-- xxx 更快 / 更省：从……到……
-
-### 修复
-- 修复「用户看到的现象」(#456)
-
-### 升级注意
-- 变更点 → 影响谁 → 迁移步骤（附示例代码或对照表链接）
-
-### 已知问题
-- ……；临时绕过：……
-```
-
-## 五、反例对照
-- 反例：「优化了底层性能。」→ 正例：「任务列表在 1 万条数据时加载时间从约 4 秒降到约 1 秒。」
-- 反例：「修复若干问题。」→ 正例：「修复搜索结果偶发重复显示；修复深色模式下按钮文字不可读。」
-- 反例：「接口升级，请注意适配。」→ 正例：按三要素写全（什么坏 / 影响谁 / 怎么办）。
-- 反例：「重构核心模块。」→ 用户视角无行为变化的重构不进用户公告，放开发者 changelog。
+---
+name: 版本发布说明撰写模板
+note: 面向用户的更新公告：固定六段结构 / 写作纪律 / 破坏性变更三要素 / 可复制模板与反例
+scopes:
+- "*"
+source: market
+market_id: release-notes
+---
+
+# 版本发布说明撰写模板（市场包）
+
+适用：发版时写 Release Notes / 更新公告 / changelog 的用户可读部分。
+核心立场：**写给用户看，不是写给 git log 看**——用户不关心重构了哪个模块，
+只关心「这次更新后我能多做什么、少烦什么、会坏什么」。
+
+## 一、标准结构（顺序固定）
+1. **一句话概览**：这版最值得用户知道的一件事；实在没有就写「稳定性修复」。
+2. **新功能**：能做以前做不了的事。每条 = 功能名 + 用户收益 + 入口在哪。
+3. **体验优化**：以前能做、现在更快 / 更顺 / 更省的事。
+4. **问题修复**：写用户见过的**症状**（「修复导出 PDF 中文乱码」），
+   不写内部成因（「修复字体子集化模块的编码偏移」）。
+5. **升级注意事项 / 破坏性变更**：有则紧跟概览**置顶**（不按上面的顺序排），
+   没有就省略此节。
+6. **已知问题**：带着已知问题发版必须如实列出，并给临时绕过办法。
+
+## 二、写作纪律
+- 每条只说**一个行为变化**，动词开头、面向结果：「支持按标签筛选任务」，
+  而不是「重构筛选服务并接入标签存储」。
+- 收益优先于实现：先说用户能干什么，实现细节放括号或链接里。
+- 数字具体化：「启动更快」要写成「冷启动从约 6 秒降到约 2 秒」；
+  没有数据不要编数字。
+- 不用内部术语：对用户写「登录更稳定」，不写「修复 OAuth2 refresh token 竞态」；
+  这类内容放进面向开发者的附录小节。
+- 每条尽量带出处：issue / PR / 需求单号，方便日后回溯。
+
+## 三、破坏性变更的写法（最容易写砸的部分）
+- 三要素齐全：**什么会坏**（哪个行为 / 接口 / 配置）、**影响谁**、**怎么办**
+  （迁移步骤或替代写法，给可直接复制的示例）。
+- 正面示例：
+  > **升级注意**：`/api/tasks` 返回的 `status` 字段由中文改为枚举值
+  > （`running` / `done` / `failed`）。依赖该字段的脚本需同步修改，
+  > 新旧值对照表见帮助文档「status 迁移」一节。
+- 「可能影响部分用户」这类模糊表述禁止——写清判定条件，让用户 10 秒内
+  判断自己在不在影响范围内。
+
+## 四、模板（可直接复制）
+```
+## vX.Y.Z 更新说明（YYYY-MM-DD）
+
+概览：一句话说清这版最重要的事。
+
+### 新功能
+- 支持xxx：现在可以……（入口：设置 > xxx）(#123)
+
+### 优化
+- xxx 更快 / 更省：从……到……
+
+### 修复
+- 修复「用户看到的现象」(#456)
+
+### 升级注意
+- 变更点 → 影响谁 → 迁移步骤（附示例代码或对照表链接）
+
+### 已知问题
+- ……；临时绕过：……
+```
+
+## 五、反例对照
+- 反例：「优化了底层性能。」→ 正例：「任务列表在 1 万条数据时加载时间从约 4 秒降到约 1 秒。」
+- 反例：「修复若干问题。」→ 正例：「修复搜索结果偶发重复显示；修复深色模式下按钮文字不可读。」
+- 反例：「接口升级，请注意适配。」→ 正例：按三要素写全（什么坏 / 影响谁 / 怎么办）。
+- 反例：「重构核心模块。」→ 用户视角无行为变化的重构不进用户公告，放开发者 changelog。

package/app/core/skillpacks/market/weekly-report.md

@@ -1,71 +1,71 @@
----
-name: 周报晨报生成器守则
-note: 从任务与运行记录生成汇报：先取材再总结 / 晨报三段 / 周报四段 / 量化纪律与模板
-scopes:
-- "*"
-source: market
-market_id: weekly-report
----
-
-# 周报 / 晨报生成器守则（市场包）
-
-适用：为个人或团队生成晨报（昨日 / 今日 / 阻塞）与周报（本周 / 风险 / 下周）。
-第一原则：**先取材，再总结，不许凭印象编**。事实原料来自任务系统、运行记录、
-提交历史与日志；生成器的工作是把原料提炼成「能支撑决策」的信息，不是文学创作。
-
-## 一、取材清单（动笔前先收集）
-- 已完成：本周关闭的任务、成功结束的运行、合并的提交 / PR（git log --since 起止）。
-- 进行中：各任务当前状态、最近一次运行结论、卡在哪一步。
-- 信号类：评审打分、测试通过率、失败与重试次数、耗时的环比变化——量化的来源。
-- 未进系统的口头承诺 / 临时插活：单独列出并标注「口头事项」，不混进正式条目。
-
-## 二、晨报结构（10 行以内，站着读完）
-- **昨日完成**：2-4 条，每条写一个**结果**（不是动作）。
-- **今日计划**：2-4 条，每条可验证（「提测搜索分页」，而不是「继续做搜索」）。
-- **阻塞**：0-2 条，每条带「需要谁 / 需要什么」；没有就写「无」，不硬凑。
-
-## 三、周报结构
-1. **本周一句话**：本周最重要的结果或结论。上级只读这一行也能掌握大局。
-2. **关键进展**：按目标 / 项目分组，每组 1-3 条；每条 = 结果 + 量化 + 对照计划
-   （提前 / 按期 / 延期几天）。流水账禁止——「周一做了 A，周二做了 B」是日志，
-   不是汇报。
-3. **风险与阻塞**：每条 = 风险描述 + 影响面 + 需要的支持或缓解方案。
-   **只报风险不给方案 = 把问题原样上交；报喜不报忧 = 把雷埋到下周。**
-4. **下周计划**：2-5 条可验证的目标，与风险呼应，高风险项排前面。
-
-## 四、写作纪律
-- **量化**：能带数字必带数字（章数、字数、通过率、耗时、条数）；
-  「大量」「明显」「基本完成」这类模糊词出现即重写。
-- **结果导向**：写「完成了 X，达到 Y」；「在做 X」「推进中」放进计划或阻塞，不进步进展。
-- **动词开头、一条一意**：每条脱离上下文独立可懂。
-- **诚实纪律**：延期就写延期，附原因与新预计时间；数据缺失标注「缺」，不估算充数。
-- **篇幅纪律**：周报正文 ≤400 字（附录与链接不计）；超了说明没提炼。
-
-## 五、常见毛病对照（反例 → 正例）
-- 反例：「本周推进了 A 项目。」→ 正例：「A 项目完成搜索分页改造并提测，1 万条数据下翻页响应小于 200ms。」
-- 反例：「一切顺利。」→ 正例：「整体按期；联调依赖的 B 接口周三可用，已与对方确认。」
-- 反例：「风险：时间紧。」→ 正例：「风险：评审通过率低于阈值会触发返工，预计延期 2 天；已加排一轮预审。」
-- 反例：把 12 条流水账逐日列出 → 正例：归并成 3 条按目标分组的结果，逐日明细放附录链接。
-
-## 六、周报模板（可直接复制）
-```
-# 周报（MM.DD - MM.DD）
-
-一句话：完成xxx，指标y环比+z%；主要风险：xxx。
-
-## 关键进展
-- 【目标A】交付xxx（量化数据）；对照计划：按期 / 延期n天
-- 【目标B】……
-
-## 风险与阻塞
-- 风险：……；影响：……；需要：……（或已采取措施：……）
-
-## 下周计划
-- ……
-```
-
-## 七、自检
-- [ ] 每个数字都能在任务 / 运行记录 / git log 里找到出处
-- [ ] 无「继续推进」「持续优化」这类无信息量条目
-- [ ] 风险条目全部带缓解方案或明确的求助对象
-- [ ] 下周计划每条都有可验证的完成标志
+---
+name: 周报晨报生成器守则
+note: 从任务与运行记录生成汇报：先取材再总结 / 晨报三段 / 周报四段 / 量化纪律与模板
+scopes:
+- "*"
+source: market
+market_id: weekly-report
+---
+
+# 周报 / 晨报生成器守则（市场包）
+
+适用：为个人或团队生成晨报（昨日 / 今日 / 阻塞）与周报（本周 / 风险 / 下周）。
+第一原则：**先取材，再总结，不许凭印象编**。事实原料来自任务系统、运行记录、
+提交历史与日志；生成器的工作是把原料提炼成「能支撑决策」的信息，不是文学创作。
+
+## 一、取材清单（动笔前先收集）
+- 已完成：本周关闭的任务、成功结束的运行、合并的提交 / PR（git log --since 起止）。
+- 进行中：各任务当前状态、最近一次运行结论、卡在哪一步。
+- 信号类：评审打分、测试通过率、失败与重试次数、耗时的环比变化——量化的来源。
+- 未进系统的口头承诺 / 临时插活：单独列出并标注「口头事项」，不混进正式条目。
+
+## 二、晨报结构（10 行以内，站着读完）
+- **昨日完成**：2-4 条，每条写一个**结果**（不是动作）。
+- **今日计划**：2-4 条，每条可验证（「提测搜索分页」，而不是「继续做搜索」）。
+- **阻塞**：0-2 条，每条带「需要谁 / 需要什么」；没有就写「无」，不硬凑。
+
+## 三、周报结构
+1. **本周一句话**：本周最重要的结果或结论。上级只读这一行也能掌握大局。
+2. **关键进展**：按目标 / 项目分组，每组 1-3 条；每条 = 结果 + 量化 + 对照计划
+   （提前 / 按期 / 延期几天）。流水账禁止——「周一做了 A，周二做了 B」是日志，
+   不是汇报。
+3. **风险与阻塞**：每条 = 风险描述 + 影响面 + 需要的支持或缓解方案。
+   **只报风险不给方案 = 把问题原样上交；报喜不报忧 = 把雷埋到下周。**
+4. **下周计划**：2-5 条可验证的目标，与风险呼应，高风险项排前面。
+
+## 四、写作纪律
+- **量化**：能带数字必带数字（章数、字数、通过率、耗时、条数）；
+  「大量」「明显」「基本完成」这类模糊词出现即重写。
+- **结果导向**：写「完成了 X，达到 Y」；「在做 X」「推进中」放进计划或阻塞，不进步进展。
+- **动词开头、一条一意**：每条脱离上下文独立可懂。
+- **诚实纪律**：延期就写延期，附原因与新预计时间；数据缺失标注「缺」，不估算充数。
+- **篇幅纪律**：周报正文 ≤400 字（附录与链接不计）；超了说明没提炼。
+
+## 五、常见毛病对照（反例 → 正例）
+- 反例：「本周推进了 A 项目。」→ 正例：「A 项目完成搜索分页改造并提测，1 万条数据下翻页响应小于 200ms。」
+- 反例：「一切顺利。」→ 正例：「整体按期；联调依赖的 B 接口周三可用，已与对方确认。」
+- 反例：「风险：时间紧。」→ 正例：「风险：评审通过率低于阈值会触发返工，预计延期 2 天；已加排一轮预审。」
+- 反例：把 12 条流水账逐日列出 → 正例：归并成 3 条按目标分组的结果，逐日明细放附录链接。
+
+## 六、周报模板（可直接复制）
+```
+# 周报（MM.DD - MM.DD）
+
+一句话：完成xxx，指标y环比+z%；主要风险：xxx。
+
+## 关键进展
+- 【目标A】交付xxx（量化数据）；对照计划：按期 / 延期n天
+- 【目标B】……
+
+## 风险与阻塞
+- 风险：……；影响：……；需要：……（或已采取措施：……）
+
+## 下周计划
+- ……
+```
+
+## 七、自检
+- [ ] 每个数字都能在任务 / 运行记录 / git log 里找到出处
+- [ ] 无「继续推进」「持续优化」这类无信息量条目
+- [ ] 风险条目全部带缓解方案或明确的求助对象
+- [ ] 下周计划每条都有可验证的完成标志

package/app/core/skillpacks/market/worldview-consistency.md

@@ -1,70 +1,70 @@
----
-name: 世界观设定一致性台账守则
-note: 设定台账五件套 / 设定变更三步流程 / 高频吃书场景 / 章前查章后记闭环
-scopes:
-- novel
-- serial_novel
-source: market
-market_id: worldview-consistency
----
-
-# 世界观设定一致性台账守则（市场包）
-
-适用：连载与长篇的设定管理。吃书（前后矛盾）是长篇差评第一来源，且几乎全部
-源于**「没有台账」而不是「记性差」**——几十万字跨度下，任何人都记不住自己写过的
-每个数字与专名。本包给出一套零工具依赖的台账纪律。
-
-## 一、台账五件套（开书第一天建立，一个文件即可）
-1. **规则体系**：力量 / 能力等级、代价与限制、禁忌（什么绝对做不到）。
-   **限制比能力更重要**——能赢只是爽，不能做什么才产生剧情。
-2. **地理与组织**：地名 / 势力名清单（含从属关系）。一地一名，写法逐字固定
-   （定了「云州」就不能又写「云洲」）。
-3. **时间线**：故事内历法 + 大事件年表（含「现在」的锚点日期）；每章推进了
-   多长时间记一笔，跨章对表。
-4. **专有名词表**：自造词、称谓、咒语、物品名，逐字锁定。
-5. **数字台账**：金额、距离、年龄、队伍人数、库存——正文出现过的每个数字。
-   数字是最容易吃书的类别，因为最枯燥、最没人记。
-
-## 二、铁律
-- **设定一经正文确认，不可静默更改。**要改，走三步：登记「改了什么 / 从哪章起
-  生效」→ 排查并修订前文旧描述（或用剧情解释）→ 更新台账。三步缺一不可。
-- 设定揭示分层：世界观全貌不必第一章交底，但**已揭示的部分永不反悔**。
-  未揭示的可以随时丰富——区分「未揭示」与「矛盾」：读者无从知晓的不算吃书。
-- 新设定入正文前先对台账查重：与既有规则冲突吗？冲突就要么改新、要么改旧，
-  不许「先写上再说」。
-- 跨书 / 跨卷沿用设定时，以台账为准重读一遍，不凭上一本的记忆。
-
-## 三、高频吃书场景（评审时重点排查）
-- 时间线对不上：上一段还是「昨天」，三天后又被称作「昨天」；旅程三天的两头
-  都只过了一夜。
-- 能力凭空升级 / 降级：前面明确做不到的事，后面无解释做到了（或反之）。
-- 称谓漂移：同一人物 / 势力的称呼前后不一；称呼随剧情需要临时变化。
-- 死人复活 / 物品复用：已确认死亡的角色、已消耗或损毁的物品再次登场。
-- 年龄与亲缘错位：年龄推算矛盾、辈分关系前后颠倒。
-
-## 四、闭环纪律：章前查、章后记
-- **章前查**：写 / 审每一章前，读一遍本章涉及的台账条目（出场地名、势力、规则、
-  上次时间锚点）。30 秒的事，防 30 万字后的大返工。
-- **章后记**：本章产生的任何新设定、新专名、新数字、时间推进，**当章写入台账，
-  不过夜**。攒三章再补 = 必漏。
-- 一致性评审给出的矛盾项，当轮修复并回填台账；同类矛盾出现第二次 = 台账结构
-  要补一类条目，而不是「下次更小心一点」。
-
-## 五、台账文件模板（可直接复制）
-> ## 规则体系
-> - 等级：……；代价：……；禁忌（绝对做不到的事）：……
-> ## 地理与组织
-> - 云州（州）＞ 落霞城（城）；青岚宗（宗门，驻落霞城）
-> ## 时间线
-> - 第 1 章：启程日（春三月初七）；第 2 章：+3 日 → 三月十一
-> ## 专有名词表
-> - 破妄瞳（术法名，逐字锁定）；称「宗主」不写「掌门」
-> ## 数字台账
-> - 主角 16 岁；启程盘缠 3 两银；落霞城至云州城 700 里
-
-## 六、交稿前自检
-- [ ] 本章新设定已查重并入台账，未与既有规则冲突
-- [ ] 时间推进已记账，与上一章锚点衔接无误
-- [ ] 数字（金额 / 距离 / 人数 / 年龄）与台账一致，新数字已登记
-- [ ] 专名写法与名词表逐字一致
-- [ ] 若改过既有设定：三步流程（登记 / 排查前文 / 更新台账）已走完
+---
+name: 世界观设定一致性台账守则
+note: 设定台账五件套 / 设定变更三步流程 / 高频吃书场景 / 章前查章后记闭环
+scopes:
+- novel
+- serial_novel
+source: market
+market_id: worldview-consistency
+---
+
+# 世界观设定一致性台账守则（市场包）
+
+适用：连载与长篇的设定管理。吃书（前后矛盾）是长篇差评第一来源，且几乎全部
+源于**「没有台账」而不是「记性差」**——几十万字跨度下，任何人都记不住自己写过的
+每个数字与专名。本包给出一套零工具依赖的台账纪律。
+
+## 一、台账五件套（开书第一天建立，一个文件即可）
+1. **规则体系**：力量 / 能力等级、代价与限制、禁忌（什么绝对做不到）。
+   **限制比能力更重要**——能赢只是爽，不能做什么才产生剧情。
+2. **地理与组织**：地名 / 势力名清单（含从属关系）。一地一名，写法逐字固定
+   （定了「云州」就不能又写「云洲」）。
+3. **时间线**：故事内历法 + 大事件年表（含「现在」的锚点日期）；每章推进了
+   多长时间记一笔，跨章对表。
+4. **专有名词表**：自造词、称谓、咒语、物品名，逐字锁定。
+5. **数字台账**：金额、距离、年龄、队伍人数、库存——正文出现过的每个数字。
+   数字是最容易吃书的类别，因为最枯燥、最没人记。
+
+## 二、铁律
+- **设定一经正文确认，不可静默更改。**要改，走三步：登记「改了什么 / 从哪章起
+  生效」→ 排查并修订前文旧描述（或用剧情解释）→ 更新台账。三步缺一不可。
+- 设定揭示分层：世界观全貌不必第一章交底，但**已揭示的部分永不反悔**。
+  未揭示的可以随时丰富——区分「未揭示」与「矛盾」：读者无从知晓的不算吃书。
+- 新设定入正文前先对台账查重：与既有规则冲突吗？冲突就要么改新、要么改旧，
+  不许「先写上再说」。
+- 跨书 / 跨卷沿用设定时，以台账为准重读一遍，不凭上一本的记忆。
+
+## 三、高频吃书场景（评审时重点排查）
+- 时间线对不上：上一段还是「昨天」，三天后又被称作「昨天」；旅程三天的两头
+  都只过了一夜。
+- 能力凭空升级 / 降级：前面明确做不到的事，后面无解释做到了（或反之）。
+- 称谓漂移：同一人物 / 势力的称呼前后不一；称呼随剧情需要临时变化。
+- 死人复活 / 物品复用：已确认死亡的角色、已消耗或损毁的物品再次登场。
+- 年龄与亲缘错位：年龄推算矛盾、辈分关系前后颠倒。
+
+## 四、闭环纪律：章前查、章后记
+- **章前查**：写 / 审每一章前，读一遍本章涉及的台账条目（出场地名、势力、规则、
+  上次时间锚点）。30 秒的事，防 30 万字后的大返工。
+- **章后记**：本章产生的任何新设定、新专名、新数字、时间推进，**当章写入台账，
+  不过夜**。攒三章再补 = 必漏。
+- 一致性评审给出的矛盾项，当轮修复并回填台账；同类矛盾出现第二次 = 台账结构
+  要补一类条目，而不是「下次更小心一点」。
+
+## 五、台账文件模板（可直接复制）
+> ## 规则体系
+> - 等级：……；代价：……；禁忌（绝对做不到的事）：……
+> ## 地理与组织
+> - 云州（州）＞ 落霞城（城）；青岚宗（宗门，驻落霞城）
+> ## 时间线
+> - 第 1 章：启程日（春三月初七）；第 2 章：+3 日 → 三月十一
+> ## 专有名词表
+> - 破妄瞳（术法名，逐字锁定）；称「宗主」不写「掌门」
+> ## 数字台账
+> - 主角 16 岁；启程盘缠 3 两银；落霞城至云州城 700 里
+
+## 六、交稿前自检
+- [ ] 本章新设定已查重并入台账，未与既有规则冲突
+- [ ] 时间推进已记账，与上一章锚点衔接无误
+- [ ] 数字（金额 / 距离 / 人数 / 年龄）与台账一致，新数字已登记
+- [ ] 专名写法与名词表逐字一致
+- [ ] 若改过既有设定：三步流程（登记 / 排查前文 / 更新台账）已走完

package/app/core/skills.py

@@ -410,6 +410,14 @@ def upsert_lesson(scope, title, content, source="", category=None, dim=None):
             it.update({k: new_rev[k] for k in ("revision_id", "content_sha256")})
             it["seen"] = int(it.get("seen") or 1) + 1
             it["updated_at"] = _now()
+            # 合并不吞变体标题（批2 记忆卫生）：近似题被吸收时留痕——溯源可见，
+            # 且后续按变体措辞检索也能命中（bigram 检索只看 survivor 自己的题）。
+            # 去重+封顶 8 条，防止长跑自动化把字段撑成第二正文。
+            if title != str(it.get("title") or ""):
+                mt = it.setdefault("merged_titles", [])
+                if title not in mt:
+                    mt.append(title)
+                    del mt[:-8]
             # 合并时不降级已有分类：除非本次归到了明确类别，或该条原本没有分类
             if cat != LESSON_UNCATEGORIZED or not it.get("category"):
                 it["category"] = cat
@@ -599,7 +607,13 @@ def block_for(task, scope_override=None, *, stable_order=False, run_id=None):
         for x in lessons:
             # 编号可见：复盘官据此点名「哪条已沉淀教训没防住本次问题」，
             # 归因才能落到单条而不是整批（见 note_outcome）。
-            lines.append("- [%s] **%s**：%s" % (x["id"], x["title"], x["content"]))
+            # karma 标注（批5 对称补齐）：won≥2 才标——1 次可能是巧合，噪音为零；
+            # 与知识库［有据］置信标同构，模型可按实证强度校准采信。
+            # run 内稳定：won 只在 run 收尾回写，任务中途字节不变。
+            karma = ""
+            if int(x.get("won") or 0) >= 2:
+                karma = "（已验证有效 %d 次）" % int(x.get("won") or 0)
+            lines.append("- [%s] **%s**%s：%s" % (x["id"], x["title"], karma, x["content"]))
             used.append(x["id"])
             lesson_ids.append(x["id"])
         lesson_part = ("### 【本项目已沉淀的教训（历史评审反复出现，务必规避；方括号内为教训编号）】\n"