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

package/README.md

@@ -156,19 +156,24 @@ HTTP `GET /knowledge/bases` 在返回前先刷新。
 （同一句话在哪个知识库下说，理解方式不该变），所以它不分库。这样知识、记忆、意图三段
 都是可以直接备份、直接 diff 的用户文件。
 
-知识树内部（`domain_knowledge/<知识库 id>/`）现在是**四段**：`00_schema` 与 `04_memory`
-都已不在（后者搬去了 `memory/`）。
+知识树内部（`domain_knowledge/<知识库 id>/`）现在是**三段**：schema 段与记忆段都已不在
+（后者搬去了 `memory/`）。
 
 | 段 | 装什么 | 删掉的后果 |
 | --- | --- | --- |
 | `01_source_truth/<source_type>/` | SourceRaw，一级是**来源分类**，二级是文档 | 丢数据 |
 | `02_wiki/<entity_type>/` | Wiki 卡片，一级是卡片类型 | 丢结论 |
-| `03_compiled/` | wikiNotes / 向量 / 知识图谱 | 可重建 |
-| `05_diagnosis/` | 智能归因图谱 | 可重建 |
+| `03_compiled/` | wikiNotes / 向量 / 知识图谱 / 归因图谱 | 可重建 |
 
-`00_schema` 已撤掉：它从建出来那天起就是一个**空目录**，分类注册表与 Wiki 类型注册表
+**归因图谱也在这三段里**（v1.1）：一次排查的产物是一条来源分类为 `agent_diagnosis_case`
+的 SourceRaw（落 `01_source_truth/`），模板卡由类型定义派生、不落盘，字段级的归因图
+落 `03_compiled/diagnosis_graph.json`。旧的 `05_diagnosis/` 撤销了；它里面的 `*.jsonl`
+如果还在，角色是**只读的迁移输入与历史快照** —— 不再被写，但仍然读得出来（证据与根因
+就从那里来），所以旧知识根不会因为这次改动而读不出内容。
+
+schema 段已撤掉：它从建出来那天起就是一个**空目录**，分类注册表与 Wiki 类型注册表
 一直住在 `<agentRoot>/resource/knowledge-bases.json`（那是配置，跟着根路径走）。
-启动时会把空的 `00_schema` 删掉 —— **非空则保留**：那就不属于「没用的空文件夹」了，
+启动时会把空的那个目录删掉 —— **非空则保留**：那就不属于「没用的空文件夹」了，
 删掉别人的文件比留一个空目录危险得多。
 
 `01_source_truth` 按分类分目录（而不是平铺）的理由与 `02_wiki` 一致：分类是每份来源的
@@ -218,13 +223,32 @@ POST   /knowledge/bases        { name, description?, rootDir? }    → { base }
 PATCH  /knowledge/bases/:id    { name?, description?, sourceTypes?, wikiTypes?, wikiSchemaMode? } → { base }
 DELETE /knowledge/bases/:id                                        → { deleted: true }
 GET    /knowledge/documents?kb=&query=&source_type=&limit=&offset= → { documents, total }
-GET    /knowledge/documents/:docId?kb=                             → { document }
+GET    /knowledge/documents/:docId?kb=                             → { document }（正文截前 4000 字符）
+GET    /knowledge/documents/:docId/content?kb=&offset=&limit=      → { text, offset, nextOffset, totalChars, eof }
+GET    /knowledge/documents/:docId/view?kb=                        → 独立整页（HTML，读全文）
 GET    /knowledge/documents/:docId/versions?kb=                    → { versions }
 POST   /knowledge/documents/:docId/revert?kb= { versionId }        → { document }
 DELETE /knowledge/documents/:docId?kb=                             → { deleted: true }
 GET    /knowledge/assets/:kb/*                                     → 知识库根目录下的文件流
+GET    /knowledge/doc-page.js                                      → 独立整页的脚本（构建产物）
+GET    /knowledge/card-proposals?kb=&status=                       → { total, proposals }（默认只看待审）
+POST   /knowledge/card-proposals/review { kb, proposal_id, action, reason? } → { proposalId, status, written }
+POST   /diagnosis/run           { kb, record }                     → { sourceId, proposalId }
 ```
 
+**`/knowledge/card-proposals/review` 是「人的确认动作」，刻意不做成 Agent 工具。**
+类型层的写入现在有两段：Agent 与编译只**提议**（`propose_wiki_cards`、Pass 0），
+未确认的提议不落 `02_wiki/`、不进编译、不参与召回、不在归因图上出现；人在面板上
+逐条 review（通过并写入 / 仅确认 / 拒绝），确认之后才走 `write_knowledge_card` ——
+而那个工具现在要求一条**已确认且尚未落卡**的 `proposal_id`，确认凭证是一次性的。
+提议落在记忆段 `<agentRoot>/memory/<库 id>/card-proposals/`，不在知识树里。
+
+**原文预览只发前 4000 个字符。** `GET /knowledge/documents/:docId` 返回的 `content` 是
+截断过的，全文长度在 `contentChars`、是否截断在 `contentTruncated`。理由是抽屉只有
+380px 宽，读不完一份几十万字的文档 —— 而把整份正文发过去正是「打开弹层要等半天」的
+成因。要读全文走 `.../view` 那个独立整页：它按 `offset`/`limit` **一页一段**地取
+（默认 20000 字符一页，切点对齐空行），所以任何一次响应都不与文档大小成正比。
+
 `/knowledge/stats`、`/knowledge/search`、`/knowledge/rebuild`、`/knowledge/cards`、
 `/knowledge/sources`、`/knowledge/graph`、`/knowledge/embedding/health` 与全部
 `*_knowledge*` 工具都接受**可选** `kb`（query 或 body 字段）。`docId` 含 `:`

package/cordis.patch.yml

@@ -112,11 +112,17 @@
                 3. **Never invent a number.** Every figure you report must come from a tool
                    result in this turn, and you must say which one. "I don't have that data" is
                    a correct answer; a made-up number is not.
-                4. **Put it in writing while you still have the evidence.** A definition, a
-                   metric's exact calculation, a process, a diagnosed cause — if it will be
-                   asked again, write it as a card with `write_knowledge_card`, with
-                   `source_refs` that already exist in the store. A card whose refs point
-                   nowhere is rejected, and rightly so.
+                4. **Put it in writing while you still have the evidence — as a proposal, not
+                   a card.** A definition, a metric's exact calculation, a process, a diagnosed
+                   cause — if it will be asked again, call `propose_wiki_cards` with the
+                   `source_id` you just wrote and drafts whose `source_refs` already exist in
+                   the store. A draft whose refs point nowhere is rejected, and rightly so.
+                   **You cannot write a card yourself**: `write_knowledge_card` only accepts a
+                   proposal a human has already confirmed, and unconfirmed proposals never
+                   reach the wiki — they are not compiled, not recalled and not on the graph.
+                   So say what you proposed and that it is waiting for review; do not claim the
+                   card exists. Call `list_card_proposals` first so you do not re-propose
+                   something a human already turned down.
                 5. **Correct a card, do not quietly overwrite it.** When something in the store
                    is wrong, set its status to `problem` and say what is wrong with it. Cards
                    marked `problem` drop out of recall by default — that is how a wrong