meeting-ingestion

会议摄入技能 — 统一流水线

归档规则： 在创建任何新页面之前，请先阅读 skills/_brain-filing-rules.md。

约定： 有关 Iron Law 反向链接，请参阅 skills/conventions/quality.md；有关查找链，请参阅 skills/conventions/brain-first.md——在使用外部查找之前，务必先在 brain 中解析每个名称。

契约

本技能保证：

• 适用于任何会议录制工具——AI 笔记工具导出、webhook 负载、分享链接、原始音频转录或手动粘贴。下面的标准化转录记录即为契约；按来源进行的获取与解析由宿主 Agent 负责
• 每场真实会议对应一个 brain 页面——多会议录音会先被拆分
• 会议页面包含参会人、摘要、关键决策、行动项和重要引文
• 说话人依据证据确定，绝不靠猜测
• 录制工具的自动摘要视为主张（CLAIMS），而非事实——每一条令人意外的主张，在写入实体页面之前都必须通过一致性检查
• 每位参会人都必须有一个人物页面（新建或更新）
• 每家被讨论的公司都必须进行实体传播
• 为所有被提及的实体生成时间线条目（时间线合并）
• 双向创建反向链接
• 只有当 enrich 对每个实体都运行完毕后，会议才算完全摄入
• 在通过下方的验证清单之前，绝不能报告会议已摄入——每条引文都有依据，每个 slug 都有页面和时间线反向链接支持，每位说话人都已确定或已标记
• 叙述的顺序独立于内容进行验证：顺序矛盾会阻止摄入，直到修复或由用户明确豁免

每位被提及的参会人和公司，其页面都必须有指向会议页面的反向链接。未链接的提及意味着 brain 已损坏。

任何录制工具，同一条流水线

会议内容来自多种来源：AI 笔记工具（Granola 和 Circleback 是常见示例）、手机语音备忘录、视频通话转录导出，或用户直接粘贴的文字稿。请勿为每个供应商单独构建流水线，也不要在临时指令中改写本技能——将来源提供的任何内容标准化为下方的转录记录，然后运行共享阶段。特定来源的逻辑仅止于标准化环节。

标准化转录记录

在运行流水线之前，请将输入简化为以下结构（可在脑中完成，也可作为临时草稿文件——它不会原样写入 brain）：

source: "<recorder name, or 'manual'>"
source_id: "<unique recording id from the source, if any>"
title: "Meeting Title"
date: YYYY-MM-DD
time: "HH:MM TZ"               # null if unknown
duration: "45m"                # null if unknown
attendees:                     # the SOURCE'S notion of who was there —
  - name: "..."                # may need correction during speaker resolution
    email: "..."               # only if the source provides it
    role: "..."                # only if known
transcript_segments:           # structured form when the source diarizes
  - speaker: "..."             # resolved name OR "UNKNOWN_N" if unresolved
    speaker_raw: "..."         # the source's raw speaker label, for traceability
    text: "..."
raw_transcript_text: "..."     # the complete transcript. NEVER truncate.
source_summary: "..."          # the recorder's AI summary if present — a CLAIM, not a FACT
source_url: "..."              # link back to the source platform, if any

不变量：

• raw_transcript_text 必须完整且未截断，始终如此。
• attendees 是来源的一项主张。受邀人员 ≠ 实际出席人员。
• source_summary 经过两层有损处理（语音转文字，然后 AI 摘要）。两层都可能产生臆造内容。在将其中任何内容写入 brain 之前，必须先验证。

当来源提供原始转录时，应予以保留：将其作为旁路页面归档，类型为 type: source，路径为 sources/meetings/YYYY-MM-DD-{slug}-transcript（默认包将原始证据归档在 sources/ 下，类型为 source；切勿自创 meeting-transcript，也不要写 transcript 别名），或保持源文件可访问，并从会议页面链接到它。转录文本是后续每一条引文和主张检查的权威依据。请在旁路页面的 frontmatter 中设置 facts_backstop: false：否则自动事实抽取会从原始转录中挖掘内容（包括识别错误和闲聊），与已验证的会议页面混在一起（见阶段 5）。

保留前先脱敏。 原始转录常会捕获粘贴的密钥和个人身份信息（例如朗读出来的 API 密钥、屏幕共享中的令牌、私人电话号码）。在写入旁路页面之前，请扫描类似密钥的字符串（sk-…、ghp_…、AKIA…、bearer 令牌、较长的十六进制或 base64 数据块）以及个人身份信息，并将匹配项替换为带标签的占位符——与 conversation-archive 使用相同的确定性拒绝列表 / runPrivacyLint 模型。"未截断"指的是转录的实质内容，绝不包括有效凭据。

阶段

Phase 1: 标准化输入

根据收到的内容构建转录记录。如果输入格式有误（转录为空、只有摘要而没有转录、录音仍在进行中），立即停止——不要仅凭摘要创建会议页面。将问题告知用户。

对于完全没有结构的原始转录文件，首选 gbrain capture（它会处理去重和 frontmatter 路由）；本流程用于构建结构化的会议页面。

Phase 2: 拆分检测——一段录音不一定对应一场会议

一段录音通常是多场不同会议拼接在一起的结果（录音设备在连续的会议之间一直未关闭）。因此需要在创建页面之前进行检测，以确保每场真实会议都能生成独立页面，并正确完成去重与补充。

拆分信号（出现一个即可开始调查；出现两个或以上则几乎可以确定需要拆分）：

• 参会人员变化——转录中途有新人加入（文件较靠后的位置出现问候），或后半段的发言人集合与前半段不同
• 话题硬性切换，且两段之间没有连贯性
• 语境重置——例如"好，下一个"、重新开始的自我介绍环节、重新开始的措辞
• 来源自带的标题或议程中列出了多场会议

检测到拆分时：

1. 找出边界片段——即参会人员或话题发生切换的确切位置。
2. 将片段划分为 N 个连续的块，每场真实会议对应一个块。绝不能丢弃或重复任何片段；所有块的并集必须等于原始内容，且顺序保持不变。
3. 对每个块分别执行其余阶段 → 生成 N 个独立的会议页面，每个页面都有各自修正后的参会人、标题和时间。
4. 在兄弟页面之间互相交叉链接（"同一录音，第 k 场，共 N 场"），并注明共享的 source_id，以确保去重流程不会将它们重新合并。

边界情况判断： 同一批人 + 一段连贯的对话，即使话题有所游移，也应视为一场会议；不要过度拆分。判断标准是参会人员变化加上明显的语境断裂，而不是"话题变了"。如果确实无法判断，应将边界告知用户，而不是随意猜测。

Phase 3: 跨录音设备去重

越来越多的用户会同时使用两台录音设备作为备份。在创建页面之前，先检查同一场会议是否已存在： 运行 gbrain search "{标题或参会人姓名}"，然后按以下条件匹配：日期相差在 ±1 天之内、参会人重叠度 ≥ 50%、标题相近。

• 如果页面已存在，则合并到该页面中，而不是创建重复页面：以内容更丰富的转录为基础构建，并在 frontmatter 中记录两个来源的 id。
• 来源的优先级（应信任哪个说话人分离结果）与来源的完整度（哪份转录内容更全）是两回事。一台录音设备可能只录到了某场会议的 20%，而另一台录全了。应比较长度，并将内容更完整的转录保留为依据证据。

第 4 阶段：说话人识别，在写页面之前进行

录音设备会输出匿名标签（UNKNOWN_N、Participant 2、microphone），有时还会自信满满地给出错误的姓名。请依据证据进行识别：

1. 以来源中的参会人名单为起点，并根据用户能够提供的名单证据加以修正（例如邀请名单、活动页面，或“当时只有我和 charlie-example”这类说明）。
2. 绝不猜测。 不确定时，写入 [Room] 或 UNKNOWN 并加以标注。错误的归属比没有归属更糟。
3. 对照知识库：针对每个候选人执行 gbrain search "{name}"；在接受某个身份识别之前，先阅读其页面。
4. 为每位具名说话人分配置信度：high（名单已确认）、medium（在转录文本中明确指名）、low（从内容推断，须明确标注）。
5. 内容身份核查： 对于每位以自身口吻声称了角色、公司或产品的具名说话人（如“我创立了 X”“在我的公司 Y 里我们……”），请对照该人员的知识库页面核实这一说法。如果被命名者已确立的身份与说话人对自己的描述相矛盾，说明录音设备替换成了错误的人——应按身份而非姓名进行识别，并将整条音轨重新归属。
6. 虚假说话人核查： 如果录音设备报告的不同说话人数量多于已知参会人数，则怀疑存在过度切分——即同一真实声音被拆分为两个标签。判断迹象：两个标签之间从不互相称呼，或在一句话中途交接。将虚假说话人合并到对应的真实参会人名下。
7. 用户提供的实情高于一切。 如果用户说明了在场的人员，该说明优先于录音设备的说话人分离结果以及名单。据此重新归属、修正页面，并且对用户已确认的在场人员不再反复质疑。
8. 语音转文字经常会把人名识别错。在根据仅来自转录文本的姓名新建人员页面之前，先在知识库中搜索该姓氏的可能拼写变体；默认假设是，近似的名字即是已存在的同一个人，只是姓名被识别错了。应更新已有页面，并将该变体记录为别名，而不是创建重复页面。

第 5 阶段：创建会议页面

---
type: meeting
attendees: [{comma-separated slugs of the same people, e.g. people/alice-example}]
facts_backstop: false
---

# {Meeting Title} — {Date}

Attendees: {comma-separated links to the people pages of everyone in the room}
**Date:** {YYYY-MM-DD}
**Duration:** {if available}

## Summary
{3-5 bullet key outcomes}

## Key Decisions
{Decisions with context. If none: _No decisions — discussion only._}

## Action Items
{Tasks with owners and deadlines. If none: _None — exploratory conversation._}

## Notable Quotes
{Verbatim from the transcript, attributed, `>` blockquotes.
If none: _No notable quotes — operational/logistics meeting._}

## Discussion Notes
{Structured notes by topic}

Attendees: 这一行是页面的出席记录，链接提取器会逐字读取它。请将其写成一行，以 Attendees: 开头（不加粗），且只包含指向人员页面的链接，每位在场者一个，用逗号分隔（不要用“和”）。只有在身份识别为高或中等置信度（第 4 阶段）时，才为该人员添加链接。公司、职位、发言人置信度、低置信度的猜测，或像 UNKNOWN_2 这样未确定的发言人，都应写入讨论记录（Discussion Notes）。该行上的任何多余文字都会让提取器无法将其识别为出席记录，而一旦该行在中途换行，换行之后的所有人都会丢失。仅被邀请或仅被提及的人不要列在该行中。attendees: 前言中按 slug 列出的人员必须与之完全一致；提取器会把它当作第二份出席记录来读取，因此两者必须保持一致。

四个必需章节是摘要（Summary）、关键决定（Key Decisions）、行动项（Action Items）和值得注意的引述（Notable Quotes）。其他章节（讨论记录（Discussion Notes）、指向转录侧车文件的链接）只能作为补充，不能替代这四个必需章节。空章节必须注明明确的原因；单独一行 - None. 是在回避问题，而不是回答。

引述必须逐字准确。按原话的方式记录所说的内容；在引用块中改写的内容就是伪造的引述。

时间线事件（life/events/）会在后台从已保存的会议页面中提取（Life Chronicle，默认开启；每个页面调用一次付费的聊天接口）。请查看写入回执：chronicle_backstop.pending: "next_cycle" 表示下一周期会提取该页面（运行 gbrain dream --phase chronicle 可立即执行，需付费）；chronicle_backstop.skipped 会说明原因及修复方法。切勿手动编写 life/events/ 页面；应编辑会议页面，提取过程会随之更新其中的事件。详见 docs/guides/life-chronicle.md。

事实（即 recall 返回的内容）同样会在后台从已保存的页面中提取，默认开启，每当页面正文发生变化时调用一次付费的聊天接口。提取过程会把每条事实归入其所指向的实体页面，因此无需通过第 6 阶段即可触达人员页面和公司页面。它也永远不会撤销此前从页面早期版本中归档的事实。这就是模板以 facts_backstop: false 起草会议页面的原因（回执显示为 facts_backstop: { skipped: "opted_out" }）：页面仍在修正时，不会提取任何内容。当验证清单全部通过后，请再次保存页面，并去掉该行；此时回执会显示为 facts_backstop: { queued: true }。已验证页面上的全部内容都是提取的输入，因此在降级协议下保留的不确定注记，会变成置信度较低的事实。转录侧车文件保留其 facts_backstop: false。不要对会议或其转录调用 extract_facts。

第 6 阶段：主张核验 + 一致性检查（每次写入实体前的关卡）

录音转写摘要会注入错误事实：语音转文字会弄错专有名词，AI 摘要会把闲聊变成承诺。在将以下任一类主张写入人物/公司页面（编译后的核心结论、frontmatter 或时间线）之前，请先核验：

主张类型	核验标准
关系/角色变化（"以联合创始人身份加入"、"成为 CTO"、"离开 widget-co"）	找到逐字转录的原文。主张必须是原话中的明确表述，而不是从热情语气中推断出来的。
所有权/归属（"她的项目"、"他的公司"）	说话人提到某个词，不等于拥有该事物。需要明确的所有权表述，或知识库的佐证。
新专有名词（知识库中尚未收录的项目/公司/产品名称）	先在知识库和网络上搜索规范写法。若无法确定，标注 (unverified spelling)，绝不能直接裸写。
重大人生或交易事件（融资、被收购、被聘用、关停）	必须有逐字转录的原文支持。这类信息传播范围最广，出错代价也最高。

一致性检查——仅有转录支持是不够的。 一条主张可能被忠实转录，却依然是错的。每条通过转录标准的主张，还需要进行以下检查：

1. 知识库矛盾检查。 执行 gbrain query "{entity}" 并阅读相关页面。新主张是否与知识库中已确立的事实相矛盾？若存在矛盾，默认以已确立的事实为准——向用户标记冲突，不得悄悄覆盖。只有在存在明确、逐字、无歧义的转录原文支持时，新主张才能取代旧事实，并且即便如此，该变更也须在导入报告中标记。
2. 逻辑/合理性检查。 结合已知的其他信息，该主张是否可能成立？两个人不可能各自独立"启动"同一个项目；一家去年成立的公司不可能五年前就已被收购。逻辑上不可能的主张往往意味着可能是转写错误——写入前必须先调查。
3. 意外即信号。 如果某条主张会让用户说出"等等，什么？"，那么正是必须进行全部检查的时候。平淡的主张（"讨论了指标"、"出席了会议"）通过转录核验即可通过；令人意外的主张则需要通过每一层检查。不要把意外之处合理化为一个看似说得通的故事——应将其作为问题提出。

降级处理规程： 若转录仅支持推断，则应将其记录为会议页面上一条明确标注不确定性的备注——绝不能写入实体页面的编译后核心结论或 frontmatter。

传播规则： 未通过核验的主张不得扩散。不要将其复制到其他实体页面或时间线条目中，也不要保留在已核验的会议页面上：事实提取会将该页面的主张带入实体页面（第 5 阶段）。一条错误主张若写入五个页面，就需要五次更正。

第 7 阶段：参会者信息补全（必须执行）

对每位参会者：

1. 是否存在人物页面？只有精确匹配才算：先通过 gbrain whois <email> --json 查询；否则通过 gbrain whois "<name>" --json 查询， 且只能有一条匹配结果（身份规则）。 搜索结果中的首个命中只是待核实的候选对象，不能直接视为参会者。
2. 如果不存在 → 使用信息补全技能创建页面（skills/enrich/SKILL.md）。每位实际参加会议的人都必须有页面，即使内容很少也一样。只有临时提及的第三方（提到某人，但对方不在场，且没有独立上下文）和非参会者（例如负责接单的服务端）才跳过。
3. 如果存在 → 根据会议上下文更新整理后的事实（遵循第 6 阶段）。
4. 在人物页面添加时间线条目： gbrain timeline-add {person-slug} {date} "Attended {meeting-title}"

也要为逐字稿中被提及或发言的已知人物添加反向链接，不要只处理参会者，但只能添加高置信度的身份识别结果。切勿为无法辨认的姓名或低置信度的猜测添加反向链接；错误的反向链接对知识图谱的污染比缺少链接更严重。

注意： 通过 gbrain put 写入会议页面后，自动链接后置钩子会从页面读取参会信息。在活动架构包未覆盖参会规则的情况下（gbrain init 设置的 gbrain-base-v2 即属此类），Attendees: 行和 attendees: frontmatter（第 5 阶段）中的每个人都会生成一条 person --attended--> meeting 边；页面其他位置链接到的人不会被记录为参会者。覆盖参会规则的架构包（例如较旧的 gbrain-base）会设置自己的规则和方向。将参会关系交给自动链接处理，不要使用 gbrain link 或 add_link：手动编写的 attended 边可能指向错误方向。通过 MCP 使用时，put_page 不会在调用过程中自动链接内联内容（回执会显示 auto_links.skipped: remote）。它会为已存在的页面排队创建普通的 mentions 边（auto_links.mention_links: queued），但绝不会创建类型化的 attended 边。这些边由维护流程创建：stdio 模式下的 gbrain serve 会在启动和空闲扫描时运行该流程；在 gbrain serve --http 后面运行时，宿主会执行 gbrain sweep --once 或 gbrain extract links --source db。没有 MCP 工具会替你运行这个流程，所以通过 HTTP 使用时请联系宿主操作员；不要用 add_link 手动编写 attended 边。

缺少 attended 边有两种原因：要么参会者记录违反了第 5 阶段的规则，要么记录中提到的人在写入会议页面时还没有页面；在后一种情况下，自动链接会报告错误，并且不会写入该页面的任何链接。本技能会在第 7 阶段、会议页面写入之后创建新人物页面，因此完成第 7 阶段后，请运行 gbrain extract --stale（通过 MCP 使用时，运行上文所述的扫描），以便为页面添加链接。对于有日期的事件，你仍然需要运行 gbrain timeline-add（自动链接只处理链接，不处理时间线条目）。

第 8 阶段：实体传播与时间线合并（必须执行）

针对每个讨论过的公司、项目或概念：

1. 检查知识库中是否已有页面（运行 gbrain search，然后运行 gbrain get）。
2. 根据需要创建或更新（主张须遵循第 6 阶段）。
3. 添加引用该会议的时间线条目。
4. 从实体页面添加指向会议页面的反向链接。

时间线合并： 同一事件会出现在所有被提及实体的时间线上。如果 alice-example 与 charlie-example 在 acme-example 会面，该事件会添加到 alice-example、charlie-example 和 acme-example 的页面上。对于涉及多家公司的会议（例如团体办公时间），应按公司分别整理反馈——每家公司的时间线条目都应包含该公司的专属内容，而不是一段关于整场会议的笼统内容。

如果会议中包含值得提取、且超出会议页面本身的原创思考，请在导入后继续执行 skills/signal-detector/SKILL.md。

阶段 9：同步

页面已经在 brain 中；这一步让索引与 brain 仓库检出副本保持一致。请根据 brain 的类型选择对应命令：

• 托管 brain（已开启托管持久化）：gbrain sync --source <id> --no-pull。 托管检出副本只能通过 gbrain sources refresh <id> 更新，绝不能通过 sync 更新，否则直接运行 gbrain sync 会绕过协调器拉取检出副本。
• 非托管 brain： gbrain sync。

如果无法判断属于哪一种，请使用 gbrain sync --source <id> --no-pull：它在两种情况下都是正确的，并且从不会更新检出副本。

声明完成前的验证（硬性门禁）

写入阶段负责完成工作；本阶段负责验证工作确实已经完成。对完成的页面运行检查清单——每一项、每场会议，包括“简单”的后勤类会议。在每一项都通过之前，绝不能报告某场会议已摄入。 先说“已摄入”、之后再修复，属于违反契约；虚假的完成报告比如实的部分完成报告更糟。

V1 — 必需章节有实质内容。

• ## Summary 包含真实的结果（2 条以上要点或几句有实质内容的句子），而不是一句含糊的话。
• ## Key Decisions、## Action Items 和 ## Notable Quotes 各自要么有实际内容，要么写明明确的理由（_None — exploratory conversation._）。
• 为应付检查清单而写的单独 - None. 或 _n/a_ 属于违规。在写“无”之前，请先对照转写稿确认确实没有值得保留的决定、承诺或引语。

V2 — 每个人物/公司 slug 都有页面，并有时间线回链。 对于会议页面引用的每个人物/公司 slug：

gbrain get people/{slug}          # page exists?
gbrain timeline people/{slug}     # has an entry pointing back at this meeting?

没有页面的 slug 意味着跳过了阶段 7/8——请去补做。页面中没有本次会议的时间线条目，意味着合并不完整——请补充。

V3 — 说话人映射已解析。 页面中不得残留 Participant N / UNKNOWN_N / 原始录音标签，除非已有解析结果或明确的不确定性标记（[Room]、⚠️ attribution uncertain）。每个具名说话人都需带有阶段 4 给出的置信度。未标记的匿名标签意味着说话人解析被跳过了。

V4 — 每条引语都能在转写稿中逐字找到依据。

• 确定性检查（保留转写稿）： 对每个 > 引用块，验证其连续片段出现在转写稿附属文件中。可以从两侧同时去掉填充词（如 like、you know、I mean）；真实引语仍会共享一段较长的连续实词，而编造的引语则不会。

  gbrain get sources/meetings/{date}-{slug}-transcript   # then locate each quote span
  

• 提示检查清单（未保留转写稿）： 重新阅读源笔记，并确认每条引语都能逐字追溯到这些笔记。
• 当引语未通过依据检查时，通常的修复方法是恢复口语原文（或选取更干净的连续片段）——而不是删除引语，也绝不能把转述内容留在引用块中。

V5 — 虚构与会者的合理性检查。 录音工具常会为无标签的说话人自信地编造姓名和邮箱。

• 出现在转写稿或名册证据中都找不到的与会者姓名，未经证据支撑，应视为猜测。请根据通话中的线索（公司、共同经历）识别真实身份，或删除该姓名。
• 与会者邮箱的域名与该人声称的所属机构不符，属于疑似编造（录音工具常会套用主持人的域名）。请核实真实地址或清空该字段。
• 出现上述任一情况时：不要自动重命名或自动填充。请阅读转写稿，依据证据解决问题，修正页面、frontmatter 和回链，然后重新运行本检查清单。

V6 — 顺序验证（检查顺序，而非内容）。 会议页面的深度可能正确，但顺序可能有误——两者是相互独立的失败维度，V1–V5 从不检查顺序。请验证叙述的先后顺序：

1. 提取事件原子。 按文档顺序遍历页面正文，将每个叙述的子事件列为 {phase, place, people}，其中 phase 是该子事件相对于会议核心事件的位置（之前 / 期间 / 之后），以文中叙述为准。
2. 确定性检查（由 Agent 机械执行，无需主观判断）：
   • PHASE_INVERSION（硬性）： 被叙述为“之前”的原子出现在文档序列中核心事件之后（反之亦然）。示例：页面先叙述 alice-example 路演的复盘，然后又把路演本身描述为仍未发生。
   • TELEPORT（硬性）： 同一人被放置在两个不相邻的地点，而两者之间没有叙述任何交通或移动。示例：alice-example 在某段中还在前往目的地的车上，下一段却已身处 acme-example 办公室，中间没有任何衔接。
3. 当日时间线佐证（软性）：

   gbrain day {date}
   

   汇总整个知识库中当天的事件和时间线条目。
   • DAY_TIMELINE_GAP： 被叙述的参与者若从未出现在当天汇总的时间线中，这是一个信号而非硬性失败。最常见的原因是其时间线条目从未被写入（请回去修复第 7/8 阶段），偶尔也可能是叙述中提到了实际并未到场的人。需要排查，但不要自动阻断。
4. 结论：PASS 或 BLOCK。
   • 不存在硬性矛盾 → PASS。继续生成报告。
   • 出现任何 PHASE_INVERSION 或 TELEPORT → BLOCK。该会议不得入库。修正叙述（重读转录稿以确定真实顺序），然后重新运行 V6；或者，如果用户明确表示原文顺序无误，则记录一次豁免（waive）。豁免在报告中记为已确认而非已解决：sequence: WAIVED by user — {contradiction} stands。
   • 确实存在歧义的顺序（倒叙、仅暗示而未明确陈述先后的叙述）属于判断问题，而非确定性类别，应在报告中标记，不应因此阻断。

循环流程： 修复 → 重新检查 → 再修复，直到所有项目通过（或 V6 被用户明确豁免）。然后保存会议页面，去掉草稿中的 facts_backstop: false 行（第 5 阶段），并生成报告。

敏感会议

如果标题或转录稿显示涉及法律或高度私人的内容（证词采集、律师、法律顾问、特权信息、健康相关），请保持页面精简且以事实为准，除非用户同意进行事实提取，否则保留其 facts_backstop: false；不要将传记式的细节信息提取到其他页面中；反向链接应尽量克制。对于内容是否应当传播存在疑问时，请询问用户。

输出格式

会议页面已创建且核查清单已通过。报告格式为：“会议已入库：{N} 位参会者已补充信息，{N} 个实体已更新，已记录 {N} 项行动事项。核查：通过。顺序：PASS。”如果顺序检查被豁免，需明确说明：“顺序：WAIVED by user — {contradiction} stands（已确认，未解决）。”如果录音被拆分，则每个生成的会议页面各报告一行。注明最终会议页面保存时 facts_backstop 的回执：queued，或 opted_out 并说明为何提取保持关闭（即未获用户许可的敏感会议）。如果第 6 阶段撤回了某项主张或标记了矛盾，需逐条列出每个标记，由用户解决，不可默默忽略。如果任何核查项目无法通过，应报告该会议未入库，并指明未通过的项目。

失败时如何处理

对于任何 gbrain 错误 code、退出码、[AGENT] 代码块或通知代码块，均遵循代理操作员协议。本技能特有的规则如下：

• 与现有页面存在矛盾时，在用户修正或豁免之前阻止导入：展示两个来源并等待。
• 会议页面写入后，add_link / 自动链接报错：页面已保存，但链接未保存；列出失败的链接，并在修正 slug 后再添加。
• 参会人页面的 put_page 返回 revision_conflict：重新读取并合并；切勿基于旧的读取结果覆盖人员页面。

反模式

• 创建会议页面时不丰富参会人信息
• 跳过实体传播（"我稍后再做"）
• 未合并所有被提及实体的时间线
• 创建没有实质内容的参会人占位页
• 归档会议页面时未链接所有参与者
• 为每个供应商单独构建流水线，或在临时指令中改写本技能，而不是将内容归一化到转录记录
• 未经转录核实，就将录音工具自动生成的摘要中的名称或断言当作事实
• 未找到逐字转录原文，就把摘要中的关系/角色/归属断言写入实体页面
• 直接写入识别有误的专有名词，而不解析其规范拼写
• 将未经核实的断言扩散到多个实体页面
• 默默用新的会议断言覆盖已确立的 brain 事实，而不标记矛盾
• 猜测说话人身份，而不是写入 [Room]/UNKNOWN 并加以标记
• 截断转录内容，或在引用块中改写原文
• 将包含两场会议的录音只导入为一个页面
• 在核对清单通过之前就报告"已导入"
• 为了让核对清单通过而在必需章节下写入 - None.，却未对照转录内容确认
• 因为"只是一次简单的事务会议"而跳过核对清单
• 在时序矛盾尚未解决也未豁免的情况下，宣称页面已导入
• 将用户的豁免视为解决——豁免只是确认，矛盾仍保留在页面中
• 页面中同一人物出现在两个不相邻的地点，且两者之间没有交通衔接
• 在时序检查中重复检查实质内容，或在 V1–V5 中重复检查顺序——这些检查维度在设计上彼此正交