Knowledge Card Review 闭环

定位

Knowledge card 是企业微信未接入前的本地任务 artifact，也是未来企微回复进入知识库前的最小审计单元。

它不等同于正式知识。默认状态是 review_status: pending，只能支撑当前任务或作为待整理材料。只有经过人工 review 后，才能提升到 vault/20-wiki/、vault/30-projects/ 或 docs/。

Semantic Review Queue 是另一类 review：它不审单张知识卡事实，而是追踪页面口径、Loop handoff、adapter 边界和语义过时风险。两者都属于研用测一体的人工接管点。

本地闭环

当前本地 MVP 已跑通：

text 用户问题 -> orgreorg_demo 搜索 docs/vault -> 证据不足时生成 knowledge card -> 模拟被询问人回复 -> 人工 review -> review 通过后 promote 到 vault/docs -> 投影为 ContextDocumentRecord -> 写入本地待 reindex queue -> queue 处理 ready item，生成本次增量索引 -> SearchConnector / D3 检索投影 adapter

核心实现：

• framework/workflows/knowledge_card.py
• scripts/orgreorg_demo.py --reply-card
• scripts/orgreorg_demo.py --reply-card --reply-text
• scripts/orgreorg_demo.py --review-card
• scripts/orgreorg_demo.py --promote-card
• scripts/orgreorg_demo.py --context-document-card
• scripts/orgreorg_demo.py --enqueue-reindex-card
• scripts/orgreorg_demo.py --process-reindex-queue
• scripts/orgreorg_demo.py --reindex-cards
• scripts/orgreorg_demo.py --search-card-index
• tests/test_knowledge_card_workflow.py
• framework/workflows/knowledge_card_gateway.py
• scripts/knowledge_card_gateway_conformance.py
• tests/test_knowledge_card_gateway.py

--enqueue-reindex-card 和 --process-reindex-queue 先用 domain/orgreorg-demo/knowledge-card-reindex-queue.json 模拟 reviewed/promoted card 的增量队列。--process-reindex-queue、--reindex-cards 和 --search-card-index 已切到 Knowledge Card Tool Gateway，其中 queue processing 还会先经过 Ontology Tool Gateway，不再直接暴露本地 SearchConnector 原始输出。

本地命令

先生成待补充卡片：

bash python scripts/orgreorg_demo.py "客户合同付款状态现在该问谁确认？" --write-card --min-score 100

模拟被询问人回复：

bash python scripts/orgreorg_demo.py \ --reply-card vault/00-inbox/demo-xxx-knowledge-card.md \ --responder "财务负责人" \ --answer "合同 CT-9 的付款状态以财务系统 FIN-42 为准，今天已确认待开票。" \ --permission-scope team

模拟企微回调文本解析后写回：

bash python scripts/orgreorg_demo.py \ --reply-card vault/00-inbox/demo-xxx-knowledge-card.md \ --reply-text $'最新事实：合同 CT-9 的付款状态以财务系统 FIN-42 为准。\n回答人：财务负责人\n使用范围：team\n可信度：source_link_confirmed\n来源：https://finance.example.local/FIN-42'

--reply-text 是当前的本地 WeCom callback 替身。它会解析 answer / responder / permission_scope / confidence / source_uri / better_owner，再调用同一条 knowledge_card workflow。真实企业微信接入后，只应替换消息投递和回调 adapter，不应重写 review、promote、reindex 规则。

如果回复里包含 better_owner 或“不是我负责”这类路由纠错信号，framework/workflows/ask_router.py 会把它转成 AskFeedbackEvent。下一轮调用 apply_feedback_events 后，原被问 owner 会进入 not_owner 反馈，更合适 owner 会被前置到候选列表。这保证 knowledge card 的回复不仅沉淀事实，也能改进主动询问路由。

本地无企微时，可以把这条回调事件写入 domain/orgreorg-demo/ask-feedback-events.json：

bash python scripts/orgreorg_demo.py \ --reply-card vault/00-inbox/demo-xxx-knowledge-card.md \ --reply-text $'最新事实：这不是我负责，请找客户与 CRM 负责人。\n回答人：财务负责人\n更合适负责人：客户与 CRM 负责人' \ --feedback-log domain/orgreorg-demo/ask-feedback-events.json

下一次本地路由时读取同一事件日志：

bash python scripts/orgreorg_demo.py \ "客户合同付款状态现在该问谁确认？" \ --ask-feedback-log domain/orgreorg-demo/ask-feedback-events.json

人工 review：

bash python scripts/orgreorg_demo.py \ --review-card vault/00-inbox/demo-xxx-knowledge-card.md \ --reviewer "知识库维护人" \ --decision approve \ --promote-to vault/20-wiki

提升到 vault：

bash python scripts/orgreorg_demo.py --promote-card vault/00-inbox/demo-xxx-knowledge-card.md

投影到标准 context document：

bash python scripts/orgreorg_demo.py \ --context-document-card vault/00-inbox/demo-xxx-knowledge-card.md \ --json

写入待 reindex 队列：

bash python scripts/orgreorg_demo.py \ --enqueue-reindex-card vault/00-inbox/demo-xxx-knowledge-card.md \ --json

处理本地队列，生成本次增量索引：

bash python scripts/orgreorg_demo.py \ --process-reindex-queue \ --json

批量刷新本地知识卡索引：

bash python scripts/orgreorg_demo.py \ --reindex-cards \ --allowed-scope public \ --allowed-scope team \ --allowed-scope restricted \ --json

通过本地 SQLite FTS 替身检索 reviewed/promoted 卡片：

bash python scripts/orgreorg_demo.py \ --search-card-index "FIN-42 待开票" \ --allowed-scope team \ --json

安全规则

• 未 review 的卡片不能 promote。
• reject 和 needs_changes 状态不能 promote。
• promote 路径必须留在 vault/20-wiki、vault/30-projects 或 docs 下。
• 已 review 的卡片不能继续追加回复，避免正式结论被静默修改。
• promote 生成的页面会保留 source card、responder、reviewer、source time、review time 和 permission scope。
• 只有已经 promote 的 reviewed card 才能投影为 ContextDocumentRecord。
• task_only / restricted 卡片投影时必须保留 field mask，避免进入无范围约束的长期检索。
• 批量 reindex 会跳过 pending、reject、needs_changes 和 reviewed-but-unpromoted 卡片。

当前暴露的问题

本轮本地 smoke 发现 infer_task_type 曾把“付款状态”误判成 project_dashboard，因为“状态”是过宽触发词。已收紧为“看板 / dashboard / project-progress / 研发进度 / 项目状态”等信号，并新增回归测试。

这说明 task skill runtime 后续不能只看正例，还要持续把真实任务里的误触发写回 negative terms、fixture 和测试。

后续深化

下一步不是马上做复杂 UI，而是继续把企微前替身补成真实运行契约：

1. 把真实企业微信回调接到 append_parsed_reply_to_card，并补真实消息 ID、会话 ID 和签名校验。
2. 给 review 增加 reviewer、owner、过期时间和复核原因字段。
3. 把当前 SQLite FTS 替身替换为真实 Postgres FTS/pgvector adapter，并复用同一 reindex contract。
4. 对 task_only / restricted 卡片增加更细的 PII 检测和脱敏建议。
5. 在 Web 工作台中把 reply、review、promote 和 reindex 变成可点击动作。