wiki-query

Wiki 查询 — 知识检索

你要基于编译后的 Obsidian wiki 回答问题，而非原始源文档。该 wiki 包含经过预先综合、相互交叉引用的知识。

此技能为只读

wiki-query 用于回答问题。它绝不能创建或修改任何 wiki 内容。唯一允许的写入操作是步骤 6 中向 log.md 追加一次内容。

即使某项更改看起来显然有帮助，也绝不能：

• 在 concepts/、entities/、skills/、references/、synthesis/、journal/ 或 projects/ 下创建或编辑页面
• 修改 index.md、hot.md、_insights.md 或 .manifest.json

如果用户的消息包含新发现、操作请求（“保存这个”“禁止 X”“记录下来”）或任何暗示需要更改的内容，不要执行更改。 回答问题，提出建议的更改，并引导用户使用相应技能：

• 快速笔记 / 注意事项 → wiki-capture --quick
• 完整的新页面 → wiki-capture
• 项目知识同步 → wiki-update

开始之前

1. 解析配置 — 按照 llm-wiki/SKILL.md 中的 Config Resolution Protocol 执行（行内 @name 覆盖 → 沿 CWD 向上查找 .env → 全局配置 → 提示设置）。对于未使用 @name 的跨项目查询，如果存在全局配置，则优先使用它，即使它是指向 vault .env 的符号链接。这样即可获取 OBSIDIAN_VAULT_PATH 和任何 QMD 变量。可从任何项目目录执行。
2. 在确定检索策略之前，先从解析后的配置中加载 QMD 设置。如果设置了 QMD_WIKI_COLLECTION，则视为 QMD 可用，但仍须通过下文的传输 / 工具检查。如果该变量为空或未设置，则在使用 grep / 页面读取之前，简要说明跳过 QMD 的原因。
3. 如果 $OBSIDIAN_VAULT_PATH/hot.md 存在，先读取它——其中提供近期活动的即时上下文。如果用户的问题涉及最近摄入的内容，hot.md 可能在你打开 index.md 之前就能提供答案。
4. 读取 $OBSIDIAN_VAULT_PATH/index.md，了解 wiki 的范围和结构。

可见性筛选（可选）

默认情况下，无论可见性标签为何，都会返回所有页面。这保留了现有行为——除非用户提出要求，否则不会有任何变化。

如果用户的查询包含 “仅公开内容”、“面向用户”、“不含内部内容”、“以用户看到的方式”或“排除内部内容”等措辞，则启用筛选模式：

• 建立屏蔽标签集：{visibility/internal, visibility/pii}
• 在索引阶段（步骤 2）跳过任何 frontmatter 标签中包含屏蔽标签的候选项
• 在章节 / 全文读取阶段（步骤 3–4），不要读取或引用任何被屏蔽的页面
• 仅根据允许的页面综合答案——不要提及被排除页面的存在

没有 visibility/ 标签或带有 visibility/public 标签的页面始终包含在内。

在筛选模式下，在步骤 6 的日志条目中注明筛选条件：mode=filtered。

检索流程

遵循 llm-wiki/SKILL.md 中的 Retrieval Primitives 表。 阅读是此技能的主要成本——使用能够回答问题的最廉价原语，仅在无法回答时才逐步升级。绝不要直接跳到读取完整页面。

步骤 0：GraphRAG 预检索（快速索引查询——不读取页面）

打开任何页面之前，先查询已编译的图索引：

obsidian-wiki graph-query "$OBSIDIAN_VAULT_PATH" "<question>" --pretty

输出字段：

• answer_type：direct | path | list | gap | impact | bridges | hubs | clusters | surprising — 决定接下来要做什么。最后五种是结构意图：问题询问知识库的结构，答案会通过 graph（见下文）完整计算得出，无需读取任何页面。
• graph：仅在结构意图下提供 — 计算得出的答案。其他情况为 null。
• candidates：按标题／标签／摘要匹配度和度数排名靠前的页面，包含评分和摘要
• should_read：最值得打开的页面 — 从这里开始，而不是凭猜测读取大量文件
• path：对于多跳查询，两个概念之间最短的维基链接路径
• god_nodes_relevant：与你的查询词相关的枢纽页面 — 始终是有用的上下文
• index_only：如果为 true，排名第一的候选页面摘要已能回答问题 — 跳过页面读取
• temporal：as_of、retrievable、excluded_historical — 事件时间筛选器排除了多少页面（见下文）

结构意图 — 这些问题完全根据图来回答。系统会自动识别用户的措辞：

用户提问	answer_type	graph 包含
"删除 X 会导致什么失效" / "什么依赖于 X" / "哪些内容链接到 X"	impact	direct_dependents、transitive_dependents、total
"哪些页面连接了我的集群" / "什么会让我的知识库分裂"	bridges	按中介中心性排列的页面，包含 label 和 connects_labels
"什么最核心" / "顶级枢纽" / "我的主要主题"	hubs	按度数排列的页面，含入度／出度细分
"我有哪些集群" / "我的维基是如何组织的"	clusters	每个集群的 label、size、cohesion、fragmented
"令人惊讶的关联" / "意料之外的链接"	surprising	跨集群链接，按稀有程度从高到低排列

直接报告 graph 负载 — 不要通过读取页面重新推导。如果结构性问题中提到的页面无法解析，CLI 会回退到 direct，且 graph 为 null。

决策树：

1. 如果 graph 非 null → 结构性答案已完整。报告答案并停止；无需读取页面。
2. 如果 index_only: true → 直接根据 candidates[0].summary 回答。跳过步骤 1–4，转到步骤 5。
3. 如果 answer_type == "path" 且 path 非空 → 关联关系就在 path 中。只读取这些页面。
4. 否则 → 只打开 should_read 中的页面（而不是所有候选页面）。这取代了旧流程要求的凭猜测读取 5–10 个页面。

此处使用的图不包含知识库管理文件（index.md、log.md、hot.md、_insights.md）。它们链接到几乎所有页面，因此纳入这些文件会让任意两个页面看起来相距约 2 跳，并产生毫无意义的 A → index → B 路径。

事件时间。 页面可能带有 valid_from / valid_until / superseded_by frontmatter。valid_until 已过期的页面属于历史页面：它仍保留在 知识库和图中，但默认会从 candidates 中移除，因此“我们使用哪个 X？” 会回答当前有效的内容，而不是最早记录的内容。

• 当 temporal.excluded_historical 不为零时，如果这会实质影响答案，请说明这一点 — 用户可能询问的是已被取代的状态。
• 如果问题询问过去的情况（“我们在 2025 年使用了什么”“迁移之前”），请使用 --as-of YYYY-MM-DD 重新查询，以检索当时有效的内容。
• 当用户明确想了解完整历史，或你正在追踪某项决策如何变化时，请使用 --include-historical。
• 返回的候选页面若带有 superseded_by，该字段会指出替代页面 — 请跟进替代页面，而不要将过时说法报告为当前事实。

obsidian-wiki graph-query "$OBSIDIAN_VAULT_PATH" "<question>" --as-of 2025-06-01 --pretty
obsidian-wiki graph-query "$OBSIDIAN_VAULT_PATH" "<question>" --include-historical --pretty

结构意图会有意忽略此筛选器：删除页面仍会影响链接到它的历史页面，因此不能仅因为依赖页面已不再有效，就缩小影响范围。

后备方案（如果未安装 obsidian-wiki）：照常使用 grep 和 index.md 执行步骤 1。

Step 1：理解问题

对查询类型进行分类：

• 事实查询 — “X 是什么？” → 查找相关页面
• 关系查询 — “X 与 Y 有何关系？”/“什么内容与 X 矛盾？” → 查找两个页面、它们的交叉引用，以及其中用于表示有类型边的 relationships: frontmatter 区块
• 路径／多跳查询 — “X 如何与 Y 相连？”/“什么将 X 与 Y 联系起来？”/“追踪从 X 到 Z 的链路”/“X 在传递依赖上依赖什么？” → X 和 Y 之间没有直接链接；它们通过中间页面建立联系。使用 Step 4b 中的多跳图遍历。
• 综合查询 — “目前对 X 有什么看法？” → 查找所有涉及 X 的页面并综合整理
• 信息缺口查询 — “关于 X，我还不知道什么？” → 查找缺失内容，并检查开放问题部分
• 质疑查询 — “质疑这个”/“反驳 X”/“找出我的计划中的漏洞”/“我对 X 做了什么决定？” → 用户即将做出决定。查找知识库中反对该决定的证据。参阅 Step 5 中的“质疑查询”。

还要判断模式：

• 仅索引模式 — 由“快速回答”“只做扫描”“不要读取页面”“快速查询”等表述触发。在 Step 3 结束。仅根据 frontmatter 和 index.md 作答。
• 正常模式 — 执行下面完整的分层流程。

Step 2：索引扫描（低成本）

不打开任何页面正文，先整理候选集：

• 你已经读过上面的 index.md，将其用作第一轮筛选。它列出了每个页面，并附有一行描述和标签。
• 使用 Grep 仅扫描页面 frontmatter，查找标题、标签、别名和摘要匹配项。限定在知识库 .md 文件中的 ^(title|tags|aliases|summary): 之类的模式，比搜索正文便宜得多。
• 收集排名靠前的 5–10 个候选页面路径，按以下标准排序：
  1. 标题或别名完全匹配
  2. 标签匹配
  3. summary 字段包含查询词
  4. index.md 条目包含查询词
• **在每个排名档次内应用层级排序：**如果两个候选项得分相同，优先选择 tier: core，其次是 tier: supporting，然后是 tier: peripheral。像读取其他字段一样，用相同的低成本 grep 读取 frontmatter 中的 tier: 字段。没有 tier: 字段的页面视为 supporting。

随时记录检索数量（供 Step 5/6 中的透明度报告使用）：

• candidates_seen — 符合上述任一排名标准的不同页面总数，截取前 5–10 个之前统计。
• candidates_used — 实际带入 Step 3/4 的页面数量。
• dropped — candidates_seen − candidates_used，即存在匹配但从未读取的页面。如果此值不为零，请列出被舍弃的页面（如果数量较多，则报告数量），让用户知道检索并不完整——这不是错误，只是如实说明有哪些内容未被纳入。

如果处于仅索引模式，请在此处停止。仅根据 summary: 字段、标题和 index.md 描述作答。明确标注答案：“（仅索引答案——未读取页面正文；以下事实来自页面摘要，可能遗漏细节）”。然后跳到 Step 5。

步骤 2b：QMD 语义检索（可选——需要在解析后的配置中设置 QMD_WIKI_COLLECTION）

守卫条件：如果解析配置后 $QMD_WIKI_COLLECTION 为空或未设置，请跳过此步骤，直接进入步骤 3。请在工作进度更新中说明该变量缺失。

没有 QMD？ 跳到步骤 3，直接对知识库使用 Grep。QMD 速度更快，也能理解概念，但 grep 路径仍可正常使用。设置方法请参阅 .env.example。

如果已设置 QMD_WIKI_COLLECTION，除非问题已由 hot.md 或 index.md 中的元数据完全解答，否则在使用 Grep 前先运行 QMD。遇到语义性问题、项目特定问题、询问相关背景，或问题使用的术语可能不会原样出现在标题或 frontmatter 中时，应优先使用 QMD。

根据 $QMD_TRANSPORT 选择 QMD 传输方式：

• mcp（默认）：使用 Agent 中配置的 QMD MCP 工具。
• cli：运行本地 qmd CLI。如果已设置 $QMD_CLI，则使用它；否则使用 qmd。

如需了解 CLI 命令选择、维护和 VM 注意事项的详细信息，请使用本地的 $qmd-cli 技能（如果已安装）。

如果所选传输方式不可用（没有 MCP 工具、qmd 不在 PATH 中，或命令报错），则跳过 QMD，继续执行步骤 3。

对于 MCP 传输方式：

mcp__qmd__query:
  collection: <QMD_WIKI_COLLECTION>   # e.g. "knowledge-base-wiki"
  intent: <the user's question>
  searches:
    - type: lex    # keyword match — good for exact names, file paths, error messages
      query: <key terms>
    - type: vec    # semantic match — good for concepts, patterns, "what is X like"
      query: <question rephrased as a description>

对于 CLI 传输方式，根据 $QMD_CLI_SEARCH_MODE 选择命令：

将类似运算符或包含大量标点的词条（如 no-sudo、ansible_become=false 和 ~/.local/bin）保留在 lex: 行中。将 vec: 行改写成普通自然语言，不要使用带连字符的 -term 词语；QMD 会将 -term 视为否定词，而 vec/hyde 查询不支持否定。

• quality（默认）：相关性最佳；在 CPU 上速度较慢。

  ${QMD_CLI:-qmd} query $'lex: <key terms>\nvec: <question rephrased as a description>' -c "$QMD_WIKI_COLLECTION" -n 8 --files
  

• balanced：不使用 LLM 重排的混合搜索；当 quality 速度过慢时使用。

  ${QMD_CLI:-qmd} query $'lex: <key terms>\nvec: <question rephrased as a description>' -c "$QMD_WIKI_COLLECTION" -n 8 --no-rerank --files
  

• fast：仅语义召回；如果精确名称、文件路径或错误消息很重要，则改用 search。

  ${QMD_CLI:-qmd} vsearch "<question rephrased as a description>" -c "$QMD_WIKI_COLLECTION" -n 8 --files
  

如果 CLI 输出提供了 docid，请使用 ${QMD_CLI:-qmd} get "#docid" 获取排序后的文档。

返回的片段或排序后的文件可作为预读章节摘要。如果它们已完全解答问题，则跳过步骤 3，直接进入步骤 4（只阅读 QMD 排名最高的页面）。否则，使用排序后的文件列表来指导在步骤 3 中要 grep 或阅读哪些文件。

将 QMD 命中计入步骤 2 中同一个 candidates_seen 计数（按路径去重——通过 frontmatter grep 和 QMD 同时找到的页面只计一次）。

防御性过滤：从知识库集合的结果中移除所有 _raw/ 路径。 知识库集合本应只索引编译后的页面，但配置错误的集合（参见 .env.example）可能会索引 _raw/，包括 _raw/_archived/ 中已被提升后的页面取代的过时草稿。在使用来自 $QMD_WIKI_COLLECTION 的 QMD 命中前，请检查其路径：如果路径包含 _raw/，则将其从知识库集合的结果集中丢弃（它仍可能通过 $QMD_PAPERS_COLLECTION 合法出现，并作为原始来源引用）。这样可确保配置错误的集合只会导致“召回缺失”，而不会“悄悄将过时草稿引用为编译后的知识”。如果知识库集合返回了 _raw/ 路径，请在工作进度更新中说明，以便用户知道需要修正集合范围（参见 .env.example 的 QMD 部分）。

如果问题可能涉及 _raw/ 中的源材料，也请搜索 papers：

如果已设置 QMD_PAPERS_COLLECTION，且用户询问的主题可能由已摄取的论文涵盖（研究、理论、背景），则并行搜索 papers 集合。在回答中将原始来源与编译后的知识库页面分开引用。

第 3 步：章节检查（中等成本 — 仅在第 2/2b 步无法得出结论时）

针对每个优先候选文件，提取相关章节，不要读取整页：

• 使用 Grep -A 10 -B 2 "<query-term>" <candidate-file> 获取匹配项附近的行。
• 通常每个命中项会返回 15–30 行，而不是 100–500 行。
• 如果章节检索结果能给出明确答案，直接进入第 5 步。

第 4 步：完整读取（成本高 — 最后手段）

仅当第 2 步和第 3 步都无法回答问题时：

• 完整 Read 优先级最高的 3 个候选文件。选择要读取的 3 个文件时，请按层级排序：先读 core 页面，再读 supporting 页面；除非 peripheral 页面是唯一匹配项，否则跳过。
• 如果答案需要交叉引用，最多沿着这些页面中的 [[wikilinks]] 跳转一次。
• 对于关系查询（“X 与 Y 有什么关系？”／“什么内容与 X 矛盾？”）：还要读取候选页面的 relationships: frontmatter 区块。每个条目都表示一条带类型的有向边（extends、implements、contradicts、derived_from、uses、replaces、related_to）。请在答案中明确说明这些关系——“页面 A contradicts 页面 B（带类型的边）”比“页面 A 链接到页面 B”更有用。
• 检查“Open Questions”章节，了解已知缺口。
• 如果仍然找不到足够的信息，再回退到对整个知识库进行广泛内容检索。请告知用户你已升级检索范围——这是成本较高的路径，用户应当知情。

第 4b 步：多跳图遍历（类型化边）

普通检索只能找到提及查询词的页面。它无法回答路径／多跳查询——“X 和 Y 有什么关联？”“X 间接依赖什么？”“追踪从 X 到 Z 的链路”——尤其是在 X 和 Y 从未出现在同一页面时。答案存在于类型化边构成的图的结构中，而非任何单个页面正文中。这一步会遍历该图。

仅在路径／多跳查询时（或关系查询未能返回两个页面之间的直接边时）运行此步骤。整个过程只使用 frontmatter——此处绝不读取页面正文。

1. 构建类型化边邻接表（开销低）。 一次性 Grep 所有页面的 relationships: 区块——Grep -A 20 "^relationships:" <vault>/**/*.md（仅 frontmatter）。每个条目都会生成一条有向、带类型的边 source —type→ target。同时添加反向遍历边（标记为 (reverse)），因为“有关联”是对称的，尽管类型化断言具有方向性。只有在需要补全路径时，才将普通正文中的 [[wikilinks]] 视为无类型的 related_to 边——优先使用类型化边。

2. 定位端点。 使用第 2 步中的注册表，将 X（如果查询中提及两个端点，也包括 Y）解析为页面路径。如果端点存在歧义，则选择 tier: core 候选项，并注明此假设。

3. 有界 BFS。 如果已安装 obsidian-wiki，先让 CLI 遍历 wikilink 图——结果精确且即时：

   obsidian-wiki graph-analyse "$OBSIDIAN_VAULT_PATH" --path "<X>" "<Y>"                  # two-endpoint: shortest chain + hop count
   obsidian-wiki graph-analyse "$OBSIDIAN_VAULT_PATH" --around "<X>" --depth 3 [--direction out|in]  # one-endpoint: reachable pages by hop
   

   --path 默认双向跟随链接，除非指定 --direction out；--around --direction in 可回答“哪些内容依赖 X”（即其影响范围）。然后用第 1 步中的类型化边为返回的链路补充信息（CLI 能看到 [[wikilinks]]，但看不到关系类型）。否则，或要查找其他路径时，请手动遍历：

   • 默认最多遍历 3 跳（超过此范围的关联通常意义不大）。只有在用户说“深入”／“需要多少跳都行”时，才增加到 4 跳。
   • 前沿上限： 已访问页面超过约 60 个时，停止扩展节点——报告部分结果，不要扩展到整个知识库。
   • 对于双端点查询（X→Y）：找到最短路径后立即停止；然后继续短暂搜索，最多找出 2 条其他路径（如果存在）。
   • 对于单端点查询（X 的传递关系）：收集深度限制内可到达的所有节点，并按跳数分组。

4. 报告路径及其边类型。 展示链路，而不只是端点——类型化边就是答案：

   [[concepts/transformers]] —uses→ [[concepts/attention]] —derived_from→ [[concepts/rnn-seq2seq]] —contradicts (reverse)→ [[concepts/lstm]]
   

   说明跳数，并指出是否有任何一跳是 (reverse) 遍历或无类型的 related_to 回退（此类链路较弱——请标明）。如果在深度限制内不存在路径，请明确说明：“在 3 跳范围内，X 和 Y 之间没有类型化边路径——它们位于图中互不连通的区域。”这本身就是有用的发现（图的缺口）。

成本控制： 此步骤仅通过 grep 读取 frontmatter。如果邻接表 grep 没有返回任何结果（尚无页面使用 relationships:），请说明图中没有可遍历的类型化边，并建议运行 cross-linker 来填充它们，然后回退到普通的一跳检索。

第 5 步：综合答案

根据维基内容撰写答案：

• 使用 [[page-name]] 格式引用具体维基页面
• 注明答案来自哪一步（“在摘要中找到”还是“grep 了相应章节”还是“读取了完整页面”）——帮助用户了解可信度
• 如果维基内容存在矛盾，请呈现双方观点
• 如果维基未涵盖某项内容，请明确说明
• 建议哪些来源可能填补这一缺口

页面可信度标注： 对答案中引用的每个页面，检查其 lifecycle frontmatter，并计算 is_stale = (today − updated) > 90 days。对存在风险的页面添加行内标注，让用户知道哪些引用需要核实：

Condition	Annotation
lifecycle: archived	(ARCHIVED: superseded by [[target]]) — 请改用后继内容
lifecycle: disputed	(DISPUTED, marked <lifecycle_changed>: <lifecycle_reason or "reason unspecified">)
is_stale + lifecycle: verified	(VERIFIED but stale: last updated <updated>) — 读者应在依赖该内容前重新核实
is_stale（其他生命周期）	(stale: last updated <updated>)

综合回答中的示例：

[[concept-page]] (stale: last updated 2026-01-15) — Original claim was X.
[[verified-page]] (VERIFIED but stale: last updated 2025-09-10) — Reader should reverify before relying.
[[disputed-page]] (DISPUTED, marked 2026-04-30: contradicted by [[new-source]]) — Earlier said Y, now uncertain.
[[old-page]] (ARCHIVED: superseded by [[new-page]]) — Use the successor.

没有生命周期字段的页面（早于该架构的旧页面）按 draft 处理——如果内容过时则添加注释，否则跳过。切勿编造 lifecycle_reason；如果该字段不存在，注释中应省略原因。

标明项目源代码位置（项目范围查询）。 如果引用的页面属于项目范围——其路径位于 projects/<name>/... 下，或其 frontmatter 包含 source_path/source_repo 字段——请确定实际代码所在位置，以便提出的修复方案能指出真实文件，后续轮次也能编辑这些文件：

1. 读取 $OBSIDIAN_VAULT_PATH/.manifest.json，查找 .projects.<name>.source_repo——这是权威且与机器无关的标识（例如 github.com/owner/name）。报告时应使用此标识。
2. 按以下顺序尝试解析本地检出根目录，找到第一个存在的路径后即停止：.projects.<name>.source_cwd_hint（相对于 ~ 的提示路径），然后是旧版 .projects.<name>.source_cwd（绝对路径，仅适用于较旧的清单），最后是页面 frontmatter 中的 source_path。展开候选路径中的 ~，并确认目录确实存在后再使用。旧版绝对路径仅作为本地便利路径使用，绝不能作为项目标识报告。

使用 source_repo 报告 Source code: 行。如果在步骤 2 中解析到本地检出路径，则附上具体路径，方便读者操作（例如 <repo> — local checkout at ~/code/name/public/lib/anticheat.js）。如果查询意味着需要修复代码，且存在本地检出，则指出要编辑的具体文件，并明确提出将其作为单独的下一步来实现——但在本次查询中绝不编辑（参见上文的只读防护规则）。如果无法解析到本地检出，则报告仓库，并说明代码尚未检出到此计算机上。

质疑类查询。 任务是用用户自己的笔记与其辩论，而不是一味赞同。先针对该想法的主题进行常规检索，然后进一步查找：

• 关于同一问题的早期决策，尤其是方向相反的决策（synthesis/、projects/、包含“decision”“decided”“chose”“rejected”“won't do”的页面）；
• 失败或回滚的事项：事后复盘、“gotcha”、“broke”、“reverted”、lifecycle: disputed 或 archived 页面、contradicts 关系；
• 该想法可能面临的未决问题和限制。

回答开头应列出最有力的反证，每点都应引用或紧密转述，并附上其 [[page]] 和日期，例如 “[[synthesis/rust-rewrite]]（2025-11-02）称，由于构建时间过长，重写已被放弃。现在有什么不同？” 然后列出知识库中的支持理由（如有）。最后提出一两个用户在继续之前应回答的问题。如果知识库中没有反对该想法的内容，请直言说明。绝不编造笔记中没有的反对理由：没有质疑也是有价值的回答。

第 6 步：记录查询

这是此技能唯一执行的写入操作——不要编辑其他内容，也不要手动追加到 log.md：

obsidian-wiki memory log QUERY \
  query="the user's question" result_pages=<N> \
  mode=<normal|index_only|filtered> escalated=<true|false> \
  candidates_seen=<N> candidates_used=<N> dropped=<N>

该命令会获取记忆锁并追加一行可解析的记录；它不会修改 index.md 或 hot.md。

使用自第 2 步以来跟踪的计数。如果某个计数未跟踪（例如，仅索引模式从未构建完整候选集），则写入 0，不要省略该字段——日志格式应保持可解析。

答案格式

按以下格式组织答案：

基于 Wiki：

[整理后的答案，并使用 [[wikilinks]] 链接到来源页面]

查阅的页面： [[page-a]]、[[page-b]]、[[page-c]]

缺失内容： [Wiki 未涵盖但可能相关的内容]

检索： 看到 N 个候选项，阅读 M 个，舍弃 D 个（未查看的匹配项，如有：[[page-d]]、[[page-e]]）

源代码： <source_repo>（本地检出位于 ~/code/<name>）——如需实现，相关文件为 …。 （告诉我一声，我就会从查询模式切换到修改模式。）

源代码这一行是可选的——仅在针对项目的查询中解析出 source_repo 时才包含（参见第 5 步）。报告仓库，而不是机器上的绝对路径；仅当此机器上确实存在本地检出时，才添加本地检出路径。

检索这一行始终包含——它是自第 2 步起跟踪的计数透明报告（与第 6 步记录的 candidates_seen/candidates_used/dropped 字段一致）。在仅索引模式下，报告从 frontmatter 扫描得到的计数；如果 D 为 0，则省略括号内容，不要写空列表。