sunday-note-ingest

name	sunday-note-ingest
description	当任务涉及 ingest / 资料摄取：整理、吸收或处理外部资料、待处理材料或 Raw source，并判断是否值得长期保留、应放入哪一层、如何形成可复用结论时使用。

Ingest

判断规则

• 先判断资料是否值得沉淀，再决定去向。
• 只有相对 LLM 默认知识和普通互联网搜索都有增量的信息，才是高价值候选。
• 增量不要求信息完全独有；更深入、更有组织、密度更高、更贴近用户项目或包含已确认判断，也算增量。
• 仅当需要判断普通搜索可替代性或外部事实可靠性时，才搜索核验；资料价值来自用户项目上下文、个人事实或已确认判断时，不默认搜索。

工作流

1. 读取路径配置解析 Raw、Routine、Wiki、Journal、Schema 路径；不要假设目录名。
2. 按判断规则评估资料价值和去向。
3. 区分来源事实、agent 推断和需要用户确认的问题，避免把外部观点或模型推理写成用户已确认判断。
4. 对 Wiki 候选，优先建议更新已有同主题页面，并按既有 Wiki header 处理字段；涉及长期兴趣、近期计划、推荐偏好、当前项目或明确不感兴趣方向时，优先建议更新个人上下文页面，而不是新建零散偏好页。
5. 只有候选会影响核心导航或维护历史时，才建议更新 index 或 maintenance log。
6. 给出来源、价值判断、建议去向和待确认问题；需要写入时，按知识库写入规则确认后再修改或创建文件。

Wiki header 更新规则

• 更新已有页面：用标题、topic、keywords 和正文主题识别同主题页面；正文结论或来源实质变化时更新 last_updated、update_count 和 sources。
• 创建新候选：生成最小 header；last_updated 写当天，update_count: 1，last_queried: ""，query_count: 0，sources 指向当前资料。
• topic 写单一稳定主题，用于 query 判断页面归属和合并边界，不用 ingest 材料临时改写已有主题。
• keywords 写 3-8 个能帮助 query 命中的真实检索词，包含实体名、项目名、术语、常用问法或中英文变体，不写任务动词、泛词和临时状态词。

结构原则

• 不套固定模板；按材料类型、用途和未来使用场景选择结构，只重组会影响理解、判断或复用的部分。
• 需要回答问题或形成建议时，可用 SCQA 梳理背景、冲突、问题和回答。
• 需要表达结论时，可用金字塔原则组织：核心判断 -> 分组理由 -> 来源证据。
• 需要拆分复杂内容时，分组尽量清楚，避免混合不同主题、层级或来源。
• Wiki 正文不保存来源结构复述；不要写“本文 / 本章 / 本节 / 主要介绍了 / 内容包括 / 围绕……展开”等只描述材料结构的句子。
• 每个写入 Wiki 的段落必须包含可独立复用的知识增量：事实、判断、关系、约束、经验模式、已确认结论、来源证据或待确认问题。
• 追加已有 Wiki 时，优先合并到最相关段落或新增短条目；正文只写可复用知识，因果解释、适用条件和反例必须是知识本身，不写“本次补充 / 基于以上 / 下面整理 / 我将更新”等写入过程、分析步骤、解释性铺垫或 agent 操作说明。
• 写入 Wiki 时，用户可读内容写在正文；仅供 agent 维护、继续编译、待确认或复查的内容写入 Obsidian 注释块 %% agent ... %%。