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

package/src/types.ts

@@ -7,7 +7,12 @@ export type KnowledgeStatus = 'unreviewed' | 'draft' | 'reviewed' | 'active' | '
  * 注册表允许用户追加自定义分类，所以**运行时一律按 `string` 处理**
  * （见 `SourceType`）；这个字面量联合只用来标记哪些 id 是内置的。
  */
-export type BuiltinSourceType = 'chat_message' | 'ai_chat_message' | 'document' | 'book' | 'article' | 'prd' | 'question'
+export type BuiltinSourceType =
+  | 'chat_message'
+  | 'agent_chat_message'
+  | 'agent_diagnosis_case'
+  | 'document' | 'book' | 'article' | 'prd' | 'question'
+  | 'table' | 'metric' | 'data_dev_script' | 'query_case'
 /** 来源业务分类 id。自定义分类是开放集合，所以不是字面量联合。 */
 export type SourceType = string
 /**
@@ -20,8 +25,8 @@ export type SourceType = string
  */
 export type SchemaType =
   | 'concept' | 'metric' | 'table' | 'event' | 'playbook' | 'case'
-  | 'diagnosis/symptom' | 'diagnosis/hypothesis' | 'diagnosis/check'
-  | 'diagnosis/failure-mode' | 'diagnosis/case'
+  | 'diagnosis/symptom' | 'diagnosis/hypothesis' | 'diagnosis/check-point'
+  | 'diagnosis/failure-reason' | 'diagnosis/case'
 export type EmbeddingProvider = 'wemm-python' | 'ollama' | 'none'
 export type EmbeddingDevice = 'auto' | 'mps' | 'cpu'
 export type RerankProvider = 'bert-python' | 'none'
@@ -184,7 +189,7 @@ export type RuntimeKnowledgeConfig = Omit<KnowledgeConfig, 'rootDir' | 'agentRoo
 export const DEFAULT_KNOWLEDGE_CONFIG: RuntimeKnowledgeConfig = {
   // 智能归因的五类在这里一并默认开启：没有它们，排查思路写不进 wiki、召不回来（见 SchemaType）。
   schemaTypes: ['concept', 'metric', 'table', 'event', 'playbook', 'case', ...DIAGNOSIS_ENTITY_TYPES],
-  sourceAppendTypes: ['chat_message', 'ai_chat_message', 'document'],
+  sourceAppendTypes: ['chat_message', 'agent_chat_message', 'document'],
   allowSourceTruth: true,
   // 0029 撤掉了 `maxSourceBytes`：单条来源**没有**字符数上限。见
   // `runtime.ts` 的 `addSource` —— 真正的边界是转换内核的 `maxInputBytes`
@@ -570,8 +575,21 @@ export interface KnowledgeAssetRef {
   url: string
 }
 
+/**
+ * 文档详情。
+ *
+ * `content` **可能只是正文的前一段**：明细接口按 `SOURCE_PREVIEW_CHARS` 封顶，
+ * 因为抽屉里的预览读不完一份几十万字文档，而把它整份发过来正是「打开弹层要等半天」
+ * 的原因。要全文走独立整页的分页接口（`GET /knowledge/documents/:docId/content`）。
+ * 两件事分开之后，`contentChars` / `contentTruncated` 就是界面必须读的那两个字段 ——
+ * 「这里显示了多少、全文有多少」不能靠猜。
+ */
 export interface KnowledgeDocumentDetail extends KnowledgeDocument {
   content: string
+  /** 正文总字符数（不是 `content.length`）。 */
+  contentChars: number
+  /** `content` 是否被截断过。为真时界面要给「新页面打开」。 */
+  contentTruncated: boolean
   frontmatter: Record<string, unknown>
   assets: KnowledgeAssetRef[]
   lineage?: Record<string, string>
@@ -668,15 +686,23 @@ export interface RebuildReport {
    * 「SourceRaw → Wiki」第一段的诚实计数。
    *
    * 这八个数**每一个都来自真实发生过的事件**，没有一个是估算出来的：抽取了几个
-   * 候选、其中几个被类型闸门拒了、建了几张卡、并进几张卡、几条关系真的连上了、
+   * 候选、其中几个被类型闸门拒了、提了几条新卡提议、几条更新提议、几条关系真的连上了、
    * 几条因为端点不存在被丢掉、几份来源这次被重抽、几份因为指纹没变被跳过。
    * `extractCandidates` 关掉时它们全部回 0，而不是从响应里消失 —— 「跳过」和
    * 「没有这个能力」是两件事，用缺字段表达会让人分不清。
    */
   candidatesExtracted: number
   candidatesRejected: number
-  cardsCreated: number
-  cardsMerged: number
+  /**
+   * 这一轮**新提**的卡片提议条数。
+   *
+   * 名字原来是 `cardsCreated`（v1.5 改名）：Pass 0 不再直接落卡，它只提议，
+   * 由人在「知识库 → Wiki」的待办区确认之后才走 `writeCard`（0021 §6.1）。
+   * 计数不改名的话，报告会持续说「新建了 N 张卡片」，而磁盘上一张都没有。
+   */
+  proposalsCreated: number
+  /** 这一轮**更新**已有卡片内容的提议条数（原来叫 `cardsMerged`）。 */
+  proposalsMerged: number
   relationsExtracted: number
   relationsDropped: number
   sourcesExtracted: number
@@ -735,14 +761,23 @@ export const BUILTIN_SOURCE_TYPES: ReadonlyArray<Omit<SourceTypeDef, 'sourceCoun
     label: '聊天日志',
     description: '人与人之间在日常沟通中产生的消息记录，以对话往返为主要形态。',
     signals: ['有发言人与时间戳的短消息流', '多话题跳转、口语化、缩写多', '常见 @提及、表情、附件'],
-    excludes: ['与 AI 的对话归 ai_chat_message', '整理后的会议纪要归 document', '已成问题—根因—方案的记录归 question'],
+    excludes: ['与 AI 的对话归 agent_chat_message', '整理后的会议纪要归 document', '已成问题—根因—方案的记录归 question'],
     enabled: true,
     builtin: true,
     fallback: false,
   },
   {
-    id: 'ai_chat_message',
-    label: 'AI 对话日志',
+    /**
+     * `ai_chat_message` 在 0040 改名为 `agent_chat_message`（**只改名，不改语义**）。
+     *
+     * 理由：原有八个内置分类里只有它带 `ai_` 前缀，而链路里其他地方一律用 `agent`
+     * （`agent_diagnosis_case`、Agent 工具、`agentRoot`）。统一词根，避免同一份设计里
+     * 出现两套命名。存量来源靠一次性迁移换目录 + 改 frontmatter（见
+     * `runtime.migrateLegacySourceTypeRename`），注册表侧的旧 id 在
+     * `normalizeSourceTypes` 里按别名认。
+     */
+    id: 'agent_chat_message',
+    label: '用户与 AI 的对话日志',
     description: '用户与 AI 助手之间的完整对话记录，包含双方往返消息。',
     signals: ['user / assistant 角色交替', '提示词与回答成对出现', '代码块密集、常与会话 id 或模型名同现'],
     excludes: ['人在群里转贴 AI 回答归 chat_message', '由 AI 对话整理出的方法论文档归 document 或 article'],
@@ -750,6 +785,28 @@ export const BUILTIN_SOURCE_TYPES: ReadonlyArray<Omit<SourceTypeDef, 'sourceCoun
     builtin: true,
     fallback: false,
   },
+  {
+    /**
+     * `agent_diagnosis_case`（0040 §3.1）—— **AI 诊断日志**。
+     *
+     * 它装的是**一次排查的过程记录**：现象、走过的路径（有序）、每个检查点的产出
+     * （含被否定与给不出结论的）、确认的根因、耗时、误导段。作者是 Agent，
+     * 每次排查结束自动写一条（`externalId` = runId，重跑不产生重复记录）。
+     *
+     * **与 `question` 的边界是「谁写的、是不是已经归纳过」**：
+     * 人写的结论（手册、人工复盘）→ `question`；Agent 自动记录的过程 → 这里。
+     * 同一件事可以有两条来源，它们不是重复 —— 一个回答「结论是什么」，
+     * 一个回答「当时怎么走的」。
+     */
+    id: 'agent_diagnosis_case',
+    label: 'AI 诊断日志',
+    description: 'Agent 跑完一次问题排查后留下的过程记录：现象、路径、各检查点的产出、确认的根因、耗时与误导段。',
+    signals: ['带 runId / 现象 id / 耗时与有序路径的结构化记录', '每个检查点有成对的「实际查询 + 结果 + 这个结果算不算数」', '含被否定的假设与「给不出结论」的检查'],
+    excludes: ['人写的手册与人工复盘归 question', '由这次排查归纳出的卡片是 wiki 卡片而不是来源，那类内容归 document', '日常取数问答归 query_case'],
+    enabled: true,
+    builtin: true,
+    fallback: false,
+  },
   {
     id: 'document',
     label: '企业内部文档',
@@ -795,7 +852,7 @@ export const BUILTIN_SOURCE_TYPES: ReadonlyArray<Omit<SourceTypeDef, 'sourceCoun
     label: '问题排查文档',
     description: '以某个具体问题或故障为中心的记录：现象、影响、排查过程、根因、解决方案与后续动作。',
     signals: ['错误码、堆栈或日志片段', '复现步骤、临时规避、根因、修复版本', '时间线、一问一答或一问题多方案'],
-    excludes: ['一般性经验总结归 document', '产品需求归 prd', '外部作者的公开分析归 article'],
+    excludes: ['一般性经验总结归 document', '产品需求归 prd', '外部作者的公开分析归 article', 'Agent 跑出来的一次排查过程记录归 agent_diagnosis_case'],
     enabled: true,
     builtin: true,
     fallback: false,
@@ -862,6 +919,20 @@ export const BUILTIN_SOURCE_TYPES: ReadonlyArray<Omit<SourceTypeDef, 'sourceCoun
 
 const BUILTIN_SOURCE_TYPE_IDS: ReadonlySet<string> = new Set(BUILTIN_SOURCE_TYPES.map(def => def.id))
 
+/**
+ * 改名之前的来源分类 id → 新 id（0040 §3.2）。
+ *
+ * 它有两个消费者，缺一个就会静默丢东西：
+ * 1. **注册表**（`normalizeSourceTypes`）—— 存量 `knowledge-bases.json` 里那一项写着
+ *    旧 id，不认别名的话它会被当成一个**自定义分类**留下来，于是「注册表里到底有什么」
+ *    永远说不清（内置项和它并存）。
+ * 2. **磁盘**（`runtime.migrateLegacySourceTypeRename`）—— `01_source_truth/` 是按分类
+ *    分目录的，存量来源的 frontmatter 里写着 `source_type: ai_chat_message`。
+ */
+export const LEGACY_SOURCE_TYPE_IDS: Record<string, string> = {
+  ai_chat_message: 'agent_chat_message',
+}
+
 export function isBuiltinSourceType(id: string): boolean {
   return BUILTIN_SOURCE_TYPE_IDS.has(id)
 }
@@ -919,12 +990,16 @@ function deepFreeze<T>(value: T): T {
 
 export const SOURCE_CLASSIFIER_PROMPT: SourceClassifierPrompt = deepFreeze({
   readonly: true,
-  version: 2,
+  version: 3,
   title: '来源业务分类判定规则',
   priority: [
     { type: 'user', rule: '用户显式指定分类 → 直接用，记 source_type_source: user。' },
-    { type: 'ai_chat_message', rule: '内容是人与 AI 的对话记录（含 AI 回复）→ ai_chat_message。' },
+    { type: 'agent_chat_message', rule: '内容是人与 AI 的对话记录（含 AI 回复）→ agent_chat_message。' },
     { type: 'chat_message', rule: '内容是人与人之间的消息流（IM / 会议聊天 / 客服会话）→ chat_message。' },
+    // `agent_diagnosis_case` 紧跟对话类、排在通用文档之前：它的形状最特征化
+    // （runId + 有序路径 + 每个检查点的「实际查询 / 结果 / 算不算数」），而它和
+    // `question` 最容易混 —— 落到 question 之后再想捞回来就晚了。
+    { type: 'agent_diagnosis_case', rule: '内容是 Agent 跑完一次排查留下的过程记录（runId + 有序路径 + 每个检查点的实际查询与结果 + 确认的根因 + 耗时）→ agent_diagnosis_case。' },
     // 数据域四类排在通用文档之前：它们的形状（DDL、公式、SQL、问答）比
     // 「像不像一篇内部文档」更特征化，落到 document 之后再想捞回来就晚了。
     // 四类之间的次序按「定义的确定性」排：口径与表结构有明确文本特征，脚本次之，
@@ -932,7 +1007,7 @@ export const SOURCE_CLASSIFIER_PROMPT: SourceClassifierPrompt = deepFreeze({
     { type: 'metric', rule: '内容在定义一个可计算的量化口径（指标名 + 公式 + 维度 / 粒度 / 负责人）→ metric。' },
     { type: 'table', rule: '内容在描述一张表或数据集本身（字段清单、类型、分区、主键、更新频率）→ table。' },
     { type: 'data_dev_script', rule: '内容是生产数据的加工逻辑（SQL / PySpark / Shell / 调度定义，读什么写什么）→ data_dev_script。' },
-    { type: 'question', rule: '内容以某个具体问题或故障为中心（现象 → 排查 → 根因 → 措施）→ question。' },
+    { type: 'question', rule: '内容是**人写**的、以某个具体问题或故障为中心的结论（现象 → 排查 → 根因 → 措施）→ question。' },
     { type: 'query_case', rule: '内容是一次取数问答的完整记录（问题 → 口径 → SQL → 结果）→ query_case。' },
     { type: 'prd', rule: '内容面向「要做什么功能、给谁用、怎么算做完」→ prd。' },
     { type: 'book', rule: '内容是正式出版物或成体系的整书 → book。' },
@@ -1088,7 +1163,14 @@ export interface WikiFieldSpec {
  * 一个 wiki 卡片类型（0024）。
  *
  * 它是"SourceRaw → Wiki"这一段的**约束**：哪些类型能生成、每类必须有哪些小节与字段、
- * 期望来自哪些来源分类、模板长什么样。判定与生成仍交给模型，这里给的是**判据与骨架**。
+ * 模板长什么样。判定与生成仍交给模型，这里给的是**判据与骨架**。
+ *
+ * **「期望来源分类」（`sourceTypes`）在 0040 删掉了。** 它当时的实际作用只有一条：
+ * reference 层校验时，卡片引用的来源分类不在列表里就提示一下、不阻断 —— 既不参与拦截，
+ * 也不参与生成，只是让人手填一份「我猜这类卡片大概会引用哪些来源」的静态清单。
+ * 三条撤销理由（详见 prd/0040 §4.2）：它是一份会漂移的猜测；「这类卡片该引用什么来源」
+ * 需要读卡片内容与历史引用分布，那是 Agent 在一次生成里顺手就能判断的事；而留着一个
+ * 不拦截的必填感字段，会教坏写定义的人。
  */
 export interface WikiTypeDef {
   /** 稳定 id，`^[a-z][a-z0-9_/-]{1,60}$`（允许 `diagnosis/symptom` 这类命名空间）。 */
@@ -1099,11 +1181,9 @@ export interface WikiTypeDef {
   layer: 'type' | 'instance'
   sections: WikiSectionSpec[]
   fields: WikiFieldSpec[]
-  /** 期望的来源业务分类 id（0013 的 `source_type`）；空数组表示不限制。 */
-  sourceTypes: string[]
   /** few-shot：用户会怎么提到这种卡片。随工具描述下发。 */
   examples: string[]
-  /** 模板卡（Markdown 骨架），新建卡片时照抄。 */
+  /** 模板卡（Markdown 骨架），新建卡片时照抄。由 `sections` / `fields` **派生**。 */
   template: string
   enabled: boolean
   /** 内置类型只允许停用，不允许删除。 */
@@ -1125,7 +1205,7 @@ export interface CardSchemaIssue {
   message: string
 }
 
-/** 卡片类型目录：注册表 + 生效方式 + 内置只读判定规则 + 当前卡片的问题清单。 */
+/** 卡片类型目录：注册表 + 生效方式 + 内置只读判定规则 + 当前卡片的问题清单 + 待审提议。 */
 export interface WikiTypeCatalog {
   types: WikiTypeDef[]
   mode: WikiSchemaMode
@@ -1134,6 +1214,20 @@ export interface WikiTypeCatalog {
   /** 已落库卡片的三层校验结果（前 N 条）。 */
   issues: Array<CardSchemaIssue & { entityId: string; entityType: string }>
   issueCount: number
+  /**
+   * 待人确认的提议（0021 §6.1）。
+   *
+   * 它挂在**类型目录**上而不是单独一路，是因为这一屏（「知识库 → Wiki」的待办区）
+   * 就是 review 的地方 —— 与 Pass 0 的候选草案、lint 待补清单是同一处，
+   * 不新造第二套 review 界面。未确认的提议**不落 `02_wiki/`**，所以它们不在
+   * `types[].cardCount` 里，必须单独报出来。
+   */
+  proposals: {
+    pending: number
+    rejected: number
+    /** 已经确认、等人或等 Agent 落卡的条数。 */
+    confirmed: number
+  }
 }
 
 /** 卡片类型 id 的形状；允许 `diagnosis/symptom` 这类带命名空间的 id。 */

package/src/wiki-types.ts

@@ -1,4 +1,4 @@
-import { DIAGNOSIS_ENTITIES } from './diagnosis/schema.js'
+import { DIAGNOSIS_ENTITIES, LEGACY_ENTITY_TYPES } from './diagnosis/schema.js'
 import type { CardSchemaIssue, WikiFieldSpec, WikiSectionSpec, WikiTypeDef } from './types.js'
 
 /**
@@ -29,7 +29,6 @@ const GENERIC_TYPES: Array<Omit<WikiTypeDef, 'template' | 'enabled' | 'builtin'
       { label: '关联', required: false },
     ],
     fields: [{ name: 'owner', required: false, note: '谁维护这个概念的定义' }],
-    sourceTypes: [],
     examples: ['什么是活跃用户', '「有效订单」的口径是什么', '这个指标和那个指标什么关系'],
   },
   {
@@ -46,7 +45,6 @@ const GENERIC_TYPES: Array<Omit<WikiTypeDef, 'template' | 'enabled' | 'builtin'
       { name: 'formula', required: true, note: '可执行的表达式或伪代码' },
       { name: 'owner', required: true, note: '谁对这个口径负责' },
     ],
-    sourceTypes: ['document', 'prd'],
     examples: ['上个月的 GMV 怎么算', '转化率的口径是什么', '这个指标怎么拆'],
   },
   {
@@ -63,7 +61,6 @@ const GENERIC_TYPES: Array<Omit<WikiTypeDef, 'template' | 'enabled' | 'builtin'
       { name: 'owner', required: true, note: '表责任人' },
       { name: 'grain', required: true, note: '一行代表什么（粒度）' },
     ],
-    sourceTypes: ['document'],
     examples: ['订单表有哪些字段', '这张表的粒度是什么', '这张表多久更新一次'],
   },
   {
@@ -77,7 +74,6 @@ const GENERIC_TYPES: Array<Omit<WikiTypeDef, 'template' | 'enabled' | 'builtin'
       { label: '处理方式', required: true },
     ],
     fields: [{ name: 'severity', required: true, note: '影响级别' }],
-    sourceTypes: ['chat_message', 'question'],
     examples: ['上游延迟告警怎么处理', '这次大促爆单是怎么回事'],
   },
   {
@@ -91,7 +87,6 @@ const GENERIC_TYPES: Array<Omit<WikiTypeDef, 'template' | 'enabled' | 'builtin'
       { label: '验收与失败处理', required: false },
     ],
     fields: [{ name: 'owner', required: true, note: '手册维护人' }],
-    sourceTypes: ['document', 'prd'],
     examples: ['新人怎么接入一张表', '发布前要检查什么'],
   },
   {
@@ -105,7 +100,6 @@ const GENERIC_TYPES: Array<Omit<WikiTypeDef, 'template' | 'enabled' | 'builtin'
       { label: '结果与教训', required: true },
     ],
     fields: [{ name: 'occurred_at', required: true, note: '发生时间' }],
-    sourceTypes: ['chat_message', 'question'],
     examples: ['上次数据延迟是怎么定位的', '那次口径改动的来龙去脉'],
   },
 ]
@@ -114,16 +108,16 @@ const GENERIC_TYPES: Array<Omit<WikiTypeDef, 'template' | 'enabled' | 'builtin'
 const DIAGNOSIS_DESCRIPTIONS: Record<string, string> = {
   'diagnosis/symptom': '一类可复用的现象：可观测口径 + 进入条件，是排查的入口。',
   'diagnosis/hypothesis': '一条可判真假的假设，带反例边界，是排查的中间层。',
-  'diagnosis/check': '一步可执行的检查，回答「怎么验证一个假设」。',
-  'diagnosis/failure-mode': '失败模式切面：把假设按根因类别分组，用于排序与查重。',
+  'diagnosis/check-point': '一步可执行的检查点，回答「怎么验证一个假设」；必须能回答谁、用什么、多久、看到什么算真、看到什么算假。',
+  'diagnosis/failure-reason': '失败原因切面：把假设按**原因出在链路的哪一环**分组，用于先验冷启动、跨症状复用与覆盖度盘点。',
   'diagnosis/case': '一次真实排查的完整路径，是实例层的记录而不是可复用知识。',
 }
 
 const DIAGNOSIS_EXAMPLES: Record<string, string[]> = {
   'diagnosis/symptom': ['销售额突然掉了', '今天报表数对不上'],
   'diagnosis/hypothesis': ['上游同步漏了', '口径被人改过'],
-  'diagnosis/check': ['查一下上游任务状态', '比对两天的分区行数'],
-  'diagnosis/failure-mode': ['上游缺失', '口径变更', '数据处理'],
+  'diagnosis/check-point': ['查一下上游任务状态', '比对两天的分区行数'],
+  'diagnosis/failure-reason': ['上游未产出', '口径变更', '数据处理'],
   'diagnosis/case': ['上次大促数据延迟的排查过程'],
 }
 
@@ -139,7 +133,7 @@ export function templateCardFor(sections: WikiSectionSpec[], fields: WikiFieldSp
 function make(def: Omit<WikiTypeDef, 'template' | 'enabled' | 'builtin' | 'cardCount'>): WikiTypeDef {
   const sections: WikiSectionSpec[] = def.sections.map(section => ({ ...section }))
   const fields: WikiFieldSpec[] = def.fields.map(field => ({ ...field }))
-  return { ...def, sections, fields, sourceTypes: [...def.sourceTypes], examples: [...def.examples], template: templateCardFor(sections, fields), enabled: true, builtin: true, cardCount: 0 }
+  return { ...def, sections, fields, examples: [...def.examples], template: templateCardFor(sections, fields), enabled: true, builtin: true, cardCount: 0 }
 }
 
 /**
@@ -157,13 +151,21 @@ export const DEFAULT_WIKI_TYPES: WikiTypeDef[] = [
     layer: spec.layer === 'instance' ? 'instance' : 'type',
     sections: spec.sections.map(label => ({ label, required: true })),
     fields: spec.fields.map(field => ({ name: field.name, required: field.system !== true, note: field.note })),
-    sourceTypes: [],
     examples: DIAGNOSIS_EXAMPLES[spec.entityType] ?? [],
   })),
 ]
 
 const BUILTIN_IDS: ReadonlySet<string> = new Set(DEFAULT_WIKI_TYPES.map(def => def.id))
 
+/**
+ * 改名之前的卡片类型 id → 新 id。
+ *
+ * 定义处仍在 `diagnosis/schema.ts`（`LEGACY_ENTITY_TYPES`），这里只是**换一个面向注册表的
+ * 名字**再导出：`normalizeWikiTypes` 读它来决定「存量配置里那一项算不算内置」。
+ * 抄第二份的下场是两处迟早不一致，而不一致的表现是「注册表里同时有两个近义类型」。
+ */
+export const LEGACY_WIKI_TYPE_IDS: Record<string, string> = { ...LEGACY_ENTITY_TYPES }
+
 export function isBuiltinWikiType(id: string): boolean {
   return BUILTIN_IDS.has(id)
 }
@@ -174,7 +176,6 @@ export function defaultWikiTypes(): WikiTypeDef[] {
     ...def,
     sections: def.sections.map(section => ({ ...section })),
     fields: def.fields.map(field => ({ ...field })),
-    sourceTypes: [...def.sourceTypes],
     examples: [...def.examples],
     cardCount: 0,
   }))
@@ -191,6 +192,8 @@ export const WIKI_TYPE_RULES = [
   '一张卡片只讲一件事：概念讲定义、指标讲口径、手册讲做法、案例讲发生过的事。混在一起时要拆成多张卡片。',
   '卡片必须引用真实存在的 SourceRaw：`source_refs` 写了不存在的来源会被直接拒绝。',
   '必填小节与必填字段来自类型定义；缺了它们卡片仍然可写（report 模式），但会被标成待补。',
+  '**写卡片之前先提提议**：用 `propose_wiki_cards` 把草案挂到触发它的那条 SourceRaw 上，由人在「知识库 → Wiki」的待办区确认之后才落卡。未确认的草案不落 `02_wiki/`、不进编译、不参与召回、不在图上出现。',
+  '`write_knowledge_card` 只接受**已确认且尚未落卡**的提议（带 `proposal_id`）—— 它没有「未确认也能写」这条路径。',
 ].join('\n')
 
 /** 新增 / 编辑类型时提交的草稿。 */
@@ -201,7 +204,6 @@ export interface WikiTypeDraft {
   layer?: string
   sections?: unknown
   fields?: unknown
-  sourceTypes?: unknown
   examples?: unknown
 }
 
@@ -325,18 +327,6 @@ export function validateCardAgainstType(
     }
   }
 
-  // ---- reference：来源分类是否符合该类型的期望（只提示，不阻断）
-  if (type.sourceTypes.length > 0) {
-    const mismatched = card.metadata.source_types
-    if (Array.isArray(mismatched) && mismatched.length > 0) {
-      const allowed = new Set(type.sourceTypes)
-      const outside = mismatched.map(String).filter(id => !allowed.has(id))
-      if (outside.length > 0) {
-        issues.push({ level: 'reference', field: 'source_types', message: `来源分类 ${outside.join(' / ')} 不在该类型的期望范围（${type.sourceTypes.join(' / ')}）内` })
-      }
-    }
-  }
-
   // ---- semantic：正文不能只有标题，也不能留着占位符
   const body = card.content
     .split('\n')