[qingfengyu153781-star]

问题（lingshu #263 · 残余项 A）

induce_concepts 每凑够 min_cluster_size 条同主题记忆就新建一个概念节点，且从不与既有概念比对。

实测（沙箱复跑）：300 轮 / 3 个主题 ⇒ 99 个概念节点 = 每主题 33 个互不合并的副本，
知识层净膨胀（399 vs 300 条输入）。issue 的判据是「同主题应合并为 1 个概念」。

改动

lingshu/core/core.py（+30 / −1）：

• 新建概念前，先用 _summarize_cluster 得到候选摘要，与既有概念（layer=KNOWLEDGE 且带 concept 标签，最多 500 个）比 字符二元组 Jaccard；
• 达 similarity_threshold ⇒ 判为同主题 ⇒ 把本簇成员挂到该既有概念上
  （加 SIMILAR 边 + 打 cluster_member 标签），不新建节点；
• 只有确实不同主题时才新建。

未改动：既有概念的 content 不改写（保其 sha / 可追溯性）；累计规模不进摘要
（需要规模读数请从 SIMILAR 边数统计）。

明确的边界（这里削掉了什么判别力）

合并判据只看摘要文本的二元组相似度，不看簇内语义；
摘要由规则式 _summarize_cluster（代表节点前 40 字）生成
⇒ 同主题的不同表述可能被判为不同主题。
这是保守方向的取舍：宁可多留一个概念，也不错并两个主题。

验证（本地实跑）

门禁	读数
全量逐文件自证	差异恰好 3 个文件（core.py / 守卫 / manifest）
判别力	修复版 5 passed · main 原版 2 failed, 3 passed ⇒ 守卫有判别力
相关回归（模块 core，291 个既有测试）	2134 passed, 15 skipped in 1012.75s (16:52)

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

说明

修复取自沙箱 def-impl-4a，按当前 main 的真实 diff 重放（非整文件覆盖），
提交前所有内容均为 LF 行尾，PR 差异可直接审阅。

[FuRongJun-1999]

维护侧处置（值守第 161 轮）：修面已由镜像合并，关闭指向

你的修复已采纳并以镜像方式合并：PR #1164（合并提交 e2c1ec6）——induce_concepts 归纳压缩（命中既有概念并成员/更新代表而非新建）与守卫均为你的净增量原样（署名与致谢见镜像 PR 正文）。

未直接合并 #1114 的原因：你的分支基线 45b8359 先于维护侧 #1138/#1143/#1146/#1153/#1154 系，直接合并会回退已合工作——已按净增量摘取重放到最新 main 之上。

本端读数：守卫 test_issue263_induce_concepts_merge_guard 5 passed（基线 2 红/3 绿——红恰为合并压缩契约面）；test_issue263_maintenance_no_net_write_guard（#263 已收两面）回归 7 passed 无回归；CI 4/4 绿；manifest core.py 指纹重登记 strict 64/64。

#263 关联：本件即此前维护侧进度帖（#263 下）所注「归纳压缩面待裁定」的落地——作者提案经审读采纳，#263 主 issue 的该待裁面就此闭合。

感谢高质量修复——压缩语义（并成员/更新代表）与「构造期不净写入」的回归保持都到位。

[FuRongJun-1999]

净增量已镜像合并（PR #1164，e2c1ec6）——本 PR 关闭以避免与已落地内容重复。感谢贡献。