dsh-data-domain-knowledge 0.1.1-alpha.2 → 0.1.1-alpha.3

package/README.md

@@ -1,5 +1,5 @@
-> 当前实现（2026-10-25）：Source Raw → Knowledge（Fact、Procedure、Case）→ Wiki（Wiki Fact、Wiki Way）。
-> 核心链路与本地验证见 [完整方案](../../docs/prd/20261025-领域知识编译与召回总体方案.md#14-代码落地与验证范围)；实际编译提示词见 [源码快照](../../docs/prd/20261025-领域知识现有提示词快照.md)。运行中的插件尚未重启。
+> 当前实现（2026-10-27）：Source Raw → Knowledge（Fact、Procedure、Case）→ Wiki（Wiki Fact、Wiki Way）。
+> Fact、Procedure 都按完整坐标聚合，Wiki 使用稳定双链按需读取。核心链路与本地验证见 [完整方案](../../docs/prd/20261025-领域知识编译与召回总体方案.md#14-代码落地与验证范围)；实际编译提示词见 [源码快照](../../docs/prd/20261025-领域知识现有提示词快照.md)。运行中的插件尚未重启。
 
 # dsh-data-domain-knowledge
 
@@ -24,8 +24,7 @@
 | **方法知识** | 描述在一定条件下，如何完成任务或解决问题 | 如何追加内容；如何申请权限；如何定位指标异常，操作步骤、业务流程、分析方法、排查策略|
 
 
-事实知识：提取的是不同坐标下的knowledge，然后同一坐标组织为wiki card，二级目录是描述具体知识点的，RAG检索增强生成
-方法知识：提取的是不同坐标下的Case，然后把同一坐标的case组织为不同的排查策略wiki strategy，二级目录不同的子问题，内容是具体的排查策略，RAR检索增强推理
+Fact 与 Procedure 都按坐标提取，再分别聚合成 Wiki Fact 与 Wiki Way。Case 保存实际发生的经历；有过程证据时，可以从 Case 提炼 Procedure。操作手册中的明确方法可以直接提取为 Procedure。
 
 按坐标提取，object x action x scene，
 
@@ -42,12 +41,7 @@
 Case RAG	历史问题与完整案例	有没有类似案例
 Reasoning Memory	子问题与解决策略	我下一步应该怎么做
 
-方法知识：
-抽取策略应该是：
-1. 导入文档
-2. 抽取历史问题与完整案例，抽取的是event case，不应该只是问题，SOP、操作手册、明确的方法说明 ─────────→ 策略知识
-复盘、历史任务、排查记录 → 案例证据 ──→ 策略知识
-1. 抽取子问题与策略，从event case抽取到wiki层的是子问题和策略，将同一个坐标下的子问题和策略组织为wiki_strategy
+方法知识的输入有两条路径：操作手册、明确流程和用户确认直接提供 Procedure；复盘、历史任务与排查记录先提供 Case，再按已执行过程提炼 Procedure。过去的根因不自动成为当前问题的根因。
 
 
 ### 架构
@@ -97,16 +91,29 @@ Procedure → Wiki Way
     ↓ 索引
 发布可召回的结果
 
-保留 Object、Action、Scene，先取消“每个三轴组合固定生成一份 Wiki”的强规则。Fact 默认围绕对象，Procedure 默认围绕对象与动作；Scene 保留为记录条件，不进入 Wiki 文件分组键。
+Fact、Procedure 都按 Object × Action × Scene 抽取和聚合。每个坐标分别生成 Wiki Fact、Wiki Way，类型进入主键；空轴不是通配符。按 Object 可以读取这些坐标的 Wiki 目录，再沿稳定双链按需读取全文。
 那生成规则是：
-Wiki Fact：按Object生成，
-Wiki Way：按 Object＋Action 生成。两类文件都按明确的检索需求组织二级标题；回答同一需求的内容合并，独立需求拆分，必要条件和步骤不能拆散。
+Wiki Fact：按完整坐标聚合 Fact。
+Wiki Way：按完整坐标聚合 Procedure。两类文件都按明确的检索需求组织二级标题；回答同一需求的内容合并，独立需求拆分，必要条件和步骤不能拆散。
 | Knowledge 类型 | Wiki 分组规则 | 索引单元 |
 |---|---|---|
-| **Fact** | 同一个 **Object** → 一份 Wiki Fact | 一个检索需求对应一个 H2；命中后交付完整文件 |
-| **Procedure** | 同一个 **Object + Action** → 一份 Wiki Way | 一个检索需求对应一个 H2；命中后交付完整文件 |
+| **Fact** | 同一 **Object × Action × Scene** → 一份 Wiki Fact | 一个检索需求对应一个 H2；命中后交付完整文件 |
+| **Procedure** | 同一 **Object × Action × Scene** → 一份 Wiki Way | 一个检索需求对应一个 H2；命中后交付完整文件 |
 | **Case** | 按独立 Case 保存，不生成 Wiki | 需要时单独检索或按引用读取 |
 
+### 来源身份与处理一致性
+
+- **文件导入前分配 Source Raw ID**：文件进入队列时生成 `src_<UUID>`。直读、格式转换和本次重试沿用该 ID。文件名只用于展示；不同目录的同名文件分别保存，并提示重名。更新已有来源时明确传入原 `source_id`。批量导入、单条导入和转换导入均支持该参数。
+- **聚合键包含类型与完整坐标**：合并 Object、Action 或 Scene 时，Wiki Fact 与 Wiki Way 分别迁移，不能互相合并。
+- **已保存 Wiki 绑定支撑版本**：双链读取、索引发布和召回共用可用性校验。Procedure 改动、支持撤回或 Case 版本变化后，旧方法立即停止交付；仅重建索引不能代替重新组织 Wiki。
+- **提炼缓存也恢复来源贡献**：重归一会撤回旧贡献，复用提炼缓存时仍核验证据并重新入库，不能只返回“已复用”。
+- **人工停用独立保存**：物化不恢复人工停用的 Wiki；系统因依据撤回而停用的 Wiki，可以在依据恢复并重新物化后发布。
+- **范围内阻断必须报告**：按来源处理时，不完整方法、坐标歧义和过期 Case 引用仍计入 `partial`，不能以“生成零份 Wiki”冒充全部成功。
+- **全文交付遵守预算**：按完整 Wiki、Knowledge 依据及必要证据计费，整份装入或转入临时溢出文件。Agent 工具仅在预算内的 `context` 交付完整 Wiki；命中列表只保留引用与分数。诊断面板可以显式读取候选明细。
+- **智能归因只读引用知识**：即使没有历史 Case 或诊断图，也可查看当前问题召回的 Wiki 依据并返回原 Wiki。
+
+可用性规则集中在 `src/wiki-availability.ts`，交付形状集中在 `src/recall-delivery.ts`。集中这两条规则，是为了让双链、索引和召回对同一份知识作出一致判断。
+
 
 ### 长期记忆组织
 6. 目前最大的缺口，是第三个问题还没有被解决：用户确认过的上下文如何进入知识库。
@@ -117,4 +124,4 @@ Wiki Way：按 Object＋Action 生成。两类文件都按明确的检索需求
   → 提取候选知识
   → 确定适用范围与确认对象
   → 保存原话、消息位置、时间与确认人
-  → 进入同一套 Knowledge 治理
+  → 进入同一套 Knowledge 治理