meeting-ingestion

ミーティング取り込みスキル — 統合パイプライン

ファイリングルール： 新しいページを作成する前に、skills/_brain-filing-rules.md を読んでください。

規約： Iron Law のバックリンクについては skills/conventions/quality.md を、検索チェーンについては skills/conventions/brain-first.md を参照してください。外部検索を行う前に、すべての名前を必ず brain 内で確認してください。

契約

このスキルでは、次のことを保証します。

• あらゆるミーティング録音ツールに対応します。AI メモツールのエクスポート、Webhook のペイロード、共有リンク、生の音声の文字起こし、手動で貼り付けたテキストに対応します。正規化された文字起こしレコード（以下参照）が契約となり、ソースごとの取得・解析はホストエージェントの役割です。
• 実際のミーティングごとに brain ページを 1 つ作成します。複数のミーティングが含まれる録音は、最初に分割します。
• 出席者、概要、重要な決定事項、アクション項目、注目すべき引用を含むミーティングページを作成します。
• 話者は推測ではなく、証拠に基づいて特定します。
• 録音ツールの自動要約は事実ではなく、主張として扱います。驚くような主張はすべて、エンティティページに反映する前に整合性チェックを通します。
• すべての出席者について、人物ページを作成または更新します。
• 話題に出たすべての企業について、エンティティへの反映を行います。
• 言及されたすべてのエンティティのタイムラインに項目を追加します（タイムラインの統合）。
• 双方向にバックリンクを作成します。
• すべてのエンティティに対して enrich を実行するまで、ミーティングの取り込みは完了しません。
• 以下の検証チェックリストに合格するまで、ミーティングを取り込み済みとして報告しません。すべての引用に根拠があり、すべてのスラッグに対応するページとタイムラインのバックリンクがあり、すべての話者が特定済みか、未解決としてフラグ付けされている必要があります。
• 内容とは別に、語られた順序を検証します。順序の矛盾は、修正されるか、ユーザーが明示的に免除するまで取り込みをブロックします。

出席者と話題に出た企業はすべて、それぞれのページからミーティングページへのバックリンクを必ず持つ必要があります。リンクのない言及は、壊れた 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 は情報が 2 層失われたものです（音声からテキストへの変換、その後の AI による要約）。どちらの段階でも内容が捏造される可能性があります。brain に記録する前に検証してください。

ソースに生の文字起こしが含まれている場合は、保持してください。サイドカーページとして、sources/meetings/YYYY-MM-DD-{slug}-transcript に type: source を設定して保存します（既定のパックでは、生の証拠は sources/ 配下に source として保存します。meeting-transcript を作成したり、transcript エイリアスを記述したりしないでください）。またはソースファイルを参照可能な状態に保ち、ミーティングページからリンクしてください。文字起こしは、後続処理におけるすべての引用と主張チェックの正式な証拠です。サイドカーのフロントマターに facts_backstop: false を設定してください。設定しないと、自動ファクト抽出によって、生の文字起こし（文字起こしの誤りや雑談も含む）が検証済みミーティングページと並んで抽出されてしまいます（フェーズ 5）。

保持する前に秘匿情報を除去してください。 生の文字起こしには、貼り付けられた秘密情報や個人を特定できる情報（読み上げられた API キー、画面共有されたトークン、個人の電話番号など）が含まれていることがよくあります。サイドカーに書き込む前に、秘密情報らしい文字列（sk-…、ghp_…、AKIA…、ベアラートークン、長い 16 進数／Base64 文字列）と個人を特定できる情報をスキャンし、一致したものをラベル付きプレースホルダーに置き換えてください。conversation-archive と同じ決定的な拒否リスト／runPrivacyLint の方式を使用します。「途中で切り詰められていない」とは、文字起こしの内容が保たれているという意味であり、有効な認証情報を残すという意味ではありません。

フェーズ

フェーズ 1：入力を正規化する

届いた内容から、トランスクリプトのレコードを作成します。入力に問題がある場合（トランスクリプトが空、トランスクリプトがなく要約だけのペイロード、録音中のレコード）は、処理を停止してください。要約だけから会議ページを作成してはいけません。問題をユーザーに伝えてください。

構造がまったくない生のトランスクリプトファイルには、gbrain capture を使うのが推奨される入口です（重複排除とフロントマターの振り分けに対応しています）。このパイプラインは、構造化された会議ページを作成するためのものです。

フェーズ 2：分割の検出 — 1 回の録音が常に 1 件の会議とは限らない

1 回の録音に、実際には複数の異なる会議がつなげて収録されていることがよくあります（録音機が連続するセッションをまたいで動き続けていた場合など）。各会議を個別のページにして、正しく重複排除・情報補完できるよう、ページ作成の前にこれを検出してください。

分割の兆候（1 つあれば調査が必要です。2 つ以上あれば、ほぼ確実に分割されています）：

• 参加者構成の変化 — トランスクリプトの途中で新しい人が現れる（ファイルのかなり後になって挨拶するなど）、または後半の話者の顔ぶれが前半と異なる
• 話題の急な切り替わりで、前半と後半に連続性がない
• 文脈のリセット — 「では、次の件に移ります」、新たな自己紹介、やり直しを示す表現
• 元のタイトル／アジェンダに複数のセッションが記載されている

分割が検出された場合：

1. 境界となるセグメント、つまり参加者構成や話題が切り替わる正確な箇所を特定します。
2. セグメントを、実際の会議ごとに N 個の連続したチャンクに分割します。セグメントを削除したり重複させたりしてはいけません。各チャンクを合わせると、元の順序のまま元の内容全体になる必要があります。
3. 残りのフェーズをチャンクごとに 1 回ずつ実行し、それぞれの会議ページを N 個作成します。各ページには、修正済みの参加者、タイトル、日時を設定します。
4. 関連するページ同士を相互リンクし（「同じ録音のセッション k／N」）、共通の source_id を記載して、重複排除によって再統合されないようにします。

判断が難しい場合： 同じ人たちが話し続け、話題が移り変わっても会話が一続きであれば、会議は 1 件です。分割しすぎないでください。判断基準は参加者構成と文脈の明確な断絶であり、「話題が変わった」ことではありません。本当に判断できない場合は推測せず、境界についてユーザーに確認してください。

フェーズ 3：複数の録音機器での重複排除

ユーザーがバックアップとして、2 台の録音機器を同時に使うケースが増えています。ページを作成する前に、同じ会議がすでに存在していないか確認してください。 gbrain search "{title or attendee names}" を実行し、日付が ± 1 日以内、参加者の重複率が 50% 以上、タイトルが類似しているかどうかで照合します。

• ページが存在する場合は、重複ページを作成するのではなく、既存のページにマージします。より情報量の多いトランスクリプトを使って作成し、両方のソース ID をフロントマターに記録してください。
• ソースの優先度（どの話者分離を信頼するか）は、ソースの完全性（どちらのトランスクリプトのほうが内容をより多く含むか）とは異なります。一方の録音機器がセッションの 20% しか捉えておらず、もう一方が全体を捉えている場合もあります。長さを比較し、根拠としてより内容の多いトランスクリプトを使ってください。

Phase 4: 話者の特定 — ページを書く前に

レコーダーは匿名のラベル（UNKNOWN_N、Participant 2、microphone）を付けて出力し、ときには自信満々に間違った名前を付けることもあります。根拠をもとに特定してください。

1. まず、情報源の参加者リストを確認し、ユーザーが提供できる名簿の証拠（招待リスト、イベントページ、「参加したのは私と charlie-example だけだった」など）で補正します。
2. 決して推測しないでください。 確信がない場合は [Room] または UNKNOWN と記載し、その旨を明示します。誤った帰属は、帰属を明示しないよりも問題です。
3. brain と照合します。候補者ごとに gbrain search "{name}" を実行し、特定を確定する前にその人のページを読みます。
4. 名前が判明した各話者に、確信度を割り当てます。high（名簿で確認済み）、medium（文字起こしで曖昧さなく名前が言及されている）、low（内容から推定 — 明示的にその旨を記載）です。
5. 内容と本人像の照合： 役職・会社・製品について自分の言葉で述べている名前付き話者（「Xを創業しました」「私の会社Yでは……」など）について、その発言を本人の brain ページと照合します。名前が付けられた人物の確立された本人像が、話者の自己紹介と矛盾する場合、レコーダーが別人の名前に置き換えています。名前ではなく本人像をもとに特定し、音声全体の帰属を修正します。
6. 架空の話者の確認： レコーダーが報告した話者の人数が、把握している参加者数より多い場合、過剰に分割されている可能性を疑います。1人の実際の声が2つのラベルに分けられていることがあります。兆候として、2つのラベルの話者が互いに話しかけない、または考えの途中で話者が切り替わることが挙げられます。架空の話者を実際の参加者に統合します。
7. ユーザーから示された事実は、ほかのすべてに優先します。 ユーザーが部屋にいた人を明示した場合、その情報はレコーダーの話者分離結果や名簿よりも優先されます。帰属を修正し、ページを直し、ユーザーが確認した参加者について再び議論しないでください。
8. 音声テキスト変換では名前が頻繁に誤認識されます。文字起こしにしかない名前から新しい人物ページを作る前に、姓の綴りとして考えられるバリエーションを brain で検索します。似た名前が見つかった場合、既存の人物名が誤って記録されたものだと考えるのが原則です。既存のページを更新し、そのバリエーションを別名として記録し、重複したページを作成しないでください。

フェーズ 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: で始まる1行として記述し（太字のマークアップは使わないでください）、出席した人のページへのリンクのみを、1人につき1つ、カンマで区切って記載します（「and」は使いません）。人物へのリンクは、識別の確信度が高または中程度の場合に限ります（フェーズ 4）。会社名、役職、発言者の確信度、確信度の低い推測、または UNKNOWN_2 のような未解決の発言者は、代わりに Discussion Notes に記載してください。行に余分なテキストがあると、抽出機能は出席記録として読み取れなくなります。また、行が2行目に折り返されると、改行以降の人はすべて認識されません。招待されただけの人や、言及されただけの人はこの行に含めないでください。attendees: フロントマターには、同じ人をスラッグで正確に列挙します。抽出機能はこれを2つ目の出席記録として読み取るため、両者は一致している必要があります。

必須セクションは Summary、Key Decisions、Action Items、Notable Quotes の4つです。Discussion Notes やトランスクリプトのサイドカーページへのリンクなどの追加セクションは、あくまで補足であり、必須セクションの代わりにはなりません。セクションが空の場合は、必ず明確な理由を記載してください。単に - None. とするのは、回答を避けているだけです。

引用は一字一句そのまま記載してください。実際に話されたとおりに書いてください。引用ブロック内での言い換えは、捏造された引用です。

タイムラインイベント（life/events/）は、保存された会議ページからバックグラウンドで抽出されます（Life Chronicle はデフォルトで有効です。ページごとに有料のチャット呼び出しが1回発生します）。書き込みレシートを確認してください。chronicle_backstop.pending: "next_cycle" は、次のサイクルで抽出されることを示します（gbrain dream --phase chronicle を実行すれば、その場で抽出できますが、有料です）。chronicle_backstop.skipped には理由とその解決方法が記載されます。life/events/ のページを手動で作成してはいけません。会議ページを編集すれば、抽出によってイベントが更新されます。docs/guides/life-chronicle.md を参照してください。

事実（recall が返す内容）も、デフォルトで有効なバックグラウンド処理により、保存されたページから抽出されます。ページの本文が変更されるたびに、有料のチャット呼び出しが1回発生します。各事実は、その事実が指すエンティティのページに記録されるため、フェーズ 6 を経由せずに人物や会社のページにも届きます。また、以前のバージョンのページから記録された事実が取り消されることはありません。そのため、テンプレートでは会議ページを facts_backstop: false の状態で下書きします（レシートには facts_backstop: { skipped: "opted_out" } と表示されます）。これにより、ページの修正中に抽出が行われません。検証チェックリストに合格したら、その行を削除してページをもう一度保存してください。レシートには facts_backstop: { queued: true } と表示されます。検証済みページの内容はすべて抽出対象となるため、ダウングレードプロトコルに従って残した不確かなメモは、確信度の低い事実として扱われます。トランスクリプトのサイドカーページでは facts_backstop: false を維持してください。会議やそのトランスクリプトに対して extract_facts を呼び出さないでください。

フェーズ 6：主張の検証と整合性チェック（すべてのエンティティ書き込みのゲート）

記録係の要約には誤った事実が入り込むことがあります。音声認識で固有名詞が誤変換され、AI による要約で冗談が約束に変わってしまうことがあります。以下の種類の主張を人物／会社のページ（まとめられた事実、フロントマター、またはタイムライン）に書き込む前に、必ず検証してください。

主張の種類	検証基準
関係／役割の変化（「共同創業者として加わった」「CTO になった」「widget-co を退職した」）	逐語的な文字起こしの該当箇所を見つけてください。熱意からの推測ではなく、発言内容に主張が明示されている必要があります。
所有権／帰属（「彼女のプロジェクト」「彼の会社」）	話者がその言葉を口にしたことは、所有していることを意味しません。所有を明示する表現、または brain による裏付けが必要です。
新しい固有名詞（brain にまだないプロジェクト名／会社名／製品名）	まず brain とウェブを検索し、正式な綴りを確認してください。確認できない場合は (unverified spelling) と注記し、注記なしで書いてはいけません。
重大な人生／取引上の出来事（資金調達、買収、採用、閉鎖）	逐語的な文字起こしによる裏付けが必要です。これらは最も広く波及し、誤っていた場合の修正コストも最も高くなります。

整合性チェック — 文字起こしによる裏付けだけでは不十分です。 主張が忠実に文字起こしされていても、誤っていることがあります。文字起こしの基準を満たした主張は、すべてさらに以下の確認を行ってください。

1. brain との矛盾チェック。 gbrain query "{entity}" を実行し、関連するページを読んでください。新しい主張は、確立された brain の事実と矛盾していませんか？ 矛盾する場合は、既存の確立された事実を原則として優先し、ユーザーに矛盾を伝えてください。黙って上書きしてはいけません。新しい主張が古い事実を上書きできるのは、明示的で、逐語的で、曖昧さのない文字起こしによる裏付けがある場合に限ります。その場合も、変更内容を取り込みレポートに記載してください。
2. 論理／妥当性チェック。 ほかに判明している事実に照らして、その主張はあり得ますか？ 2 人が同じプロジェクトをそれぞれ独立して「立ち上げる」ことはできません。昨年設立された会社が 5 年前に買収されていることもあり得ません。論理的にあり得ない場合は、誤認識の可能性が高いため、書き込む前に調査してください。
3. 驚きはシグナルです。 その主張を聞いてユーザーが「えっ、どういうこと？」と言いそうなら、まさにその驚きこそ、これらのチェックが必須となる場面です。「指標について話し合った」「出席した」といったありふれた主張は文字起こしの確認だけで構いませんが、意外な主張にはすべての確認が必要です。驚きを、筋の通る話に無理に当てはめてはいけません。質問として提示してください。

確度を下げる手順： 文字起こしが推測しか裏付けない場合は、ミーティングページに、明示的に不確実性を示した注記として記録してください。エンティティページのまとめられた事実やフロントマターには、決して記載してはいけません。

波及ルール： 検証に失敗した主張を波及させてはいけません。ほかのエンティティページやタイムライン項目にコピーせず、検証済みミーティングページにも記載しないでください。事実抽出によって、そのページの主張はエンティティページに引き継がれます（フェーズ 5）。誤った主張を 5 ページに書けば、修正も 5 回必要になります。

Phase 7: 参加者情報の充実（必須）

参加者ごとに、以下を行います。

1. 人物ページは存在しますか？完全一致のみを有効とします。gbrain whois <email> --json で1件一致する場合、そうでなければ gbrain whois "<name>" --json で1件一致する場合に限ります （IDの照合ルール）。 検索結果の最上位は確認対象の候補であり、参加者本人ではありません。
2. いいえの場合 → enrich スキル（skills/enrich/SKILL.md）を使って作成します。実際に会議に参加した人には、内容が少なくても必ずページを作成します。例外として、単独の文脈がない一時的な第三者への言及（その場にいない人物について名前が出た場合）と、非参加者（注文を受けるサーバーなど）のみ省略します。
3. はいの場合 → 会議の文脈を反映して、整理済みの情報を更新します（Phase 6 に従います）。
4. 人物のページにタイムラインエントリーを追加します。 gbrain timeline-add {person-slug} {date} "Attended {meeting-title}"

参加者だけでなく、トランスクリプト内で言及された、または発言した既知の人物にもバックリンクを追加します。ただし、確度の高い識別に限ります。聞き取りにくい名前や確度の低い推測には、絶対にバックリンクを追加しないでください。誤ったバックリンクは、リンクがない場合よりもグラフを汚染します。

注： gbrain put で会議ページを書き込むと、自動リンクのポストフックがページから出席情報を読み取ります。アクティブなスキーマパックで出席情報が上書きされていない場合（gbrain init が設定する gbrain-base-v2 など）、Attendees: 行と attendees: フロントマター（Phase 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 エッジがない原因は2つのいずれかです。参加者の記録が Phase 5 のルールに違反しているか、会議ページを書き込んだ時点で人物ページが存在していなかった場合です。後者の場合、自動リンクはエラーを報告し、ページ内のリンクを一切書き込みません。このスキルでは Phase 7 で会議ページの作成後に新しい人物ページを作成するため、Phase 7 の完了後に gbrain extract --stale を実行してください（MCP 経由の場合は上記のスイープを実行します）。日時付きイベントについては、引き続き gbrain timeline-add が必要です（自動リンクが処理するのはリンクのみで、タイムラインエントリーは処理しません）。

Phase 8: エンティティへの反映とタイムラインの統合（必須）

話題に上った各企業、プロジェクト、または概念について、以下を行います。

1. 既存ページが脳内にあるか確認します（gbrain search の後に gbrain get を実行します）。
2. 必要に応じて作成・更新します（主張については Phase 6 に従います）。
3. 会議を参照するタイムラインエントリーを追加します。
4. エンティティページから会議ページへのバックリンクを追加します。

タイムラインの統合： 同じイベントを、言及されたすべてのエンティティのタイムラインに記載します。alice-example が acme-example で charlie-example と会った場合、そのイベントは alice-example、charlie-example、acme-example の各ページに記載します。複数の企業が参加するセッション（例：グループのオフィスアワー）では、フィードバックを企業ごとに分けます。各企業のタイムラインエントリーには、その企業に関する内容を記載し、セッション全体についての内容をまとめて記載しないでください。

会議に、そのページ自体から切り出す価値のある独自の考えが含まれている場合は、取り込み後に skills/signal-detector/SKILL.md へ進みます。

フェーズ 9：同期

ページはすでにブレイン内にあります。この手順では、インデックスをブレインリポジトリのチェックアウトに追いつかせます。ブレインに合った形式を使ってください。

• 管理対象のブレイン（管理された永続化が有効）：gbrain sync --source <id> --no-pull。 管理対象のチェックアウトは gbrain sources refresh <id> でのみ移動し、同期では移動しません。そのため、ここで引数なしの gbrain sync を実行すると、コーディネーターに知らせずにチェックアウトを巻き戻してしまいます。
• 非管理対象のブレイン： gbrain sync。

どちらか判断できない場合は、gbrain sync --source <id> --no-pull を使ってください。どちらの場合にも正しく動作し、チェックアウトを移動させません。

完了を宣言する前に確認（必須ゲート）

書き込みフェーズで作業を行い、このフェーズで作業が実際に完了したことを確認します。完成したページに対してチェックリストを実行してください。すべての項目を、すべての会議について確認します。「手短な」事務連絡の会議も対象です。すべての項目に合格するまで、会議を取り込み済みと報告してはいけません。 先に「取り込み済み」と報告して後から修正するのは契約違反です。虚偽の完了報告は、正直に未完了と伝えるよりも重大です。

V1 — 必須セクションに実質的な内容がある。

• ## Summary には、実際の成果を記載します（箇条書き 2 項目以上、または内容のある数文）。曖昧な一文だけでは不十分です。
• ## Key Decisions、## Action Items、## Notable Quotes には、それぞれ実質的な内容、または明示的な理由（_None — exploratory conversation._）が必要です。
• チェックリストを黙らせるために - None. や _n/a_ だけを書くのは違反です。「なし」と書く前に、残す価値のある決定事項、約束、引用が本当にないことを、文字起こしで確認してください。

V2 — 人物／企業の各スラッグにページがあり、タイムラインからのバックリンクもある。 会議ページで参照されている人物／企業の各スラッグについて：

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

ページのないスラッグがある場合は、フェーズ 7／8 を飛ばしています。そこに戻って実施してください。この会議のタイムライン項目がないページがある場合は、マージが不完全です。項目を追加してください。

V3 — 発言者マップが解決されている。 解決済みであるか、明示的な不確実性フラグ（[Room]、⚠️ attribution uncertain）が付いていない限り、ページに Participant N／UNKNOWN_N／録音ツールの生ラベルが残っていてはいけません。名前のある発言者にはすべて、フェーズ 4 で判定した確信度を付けます。フラグのない匿名ラベルは、発言者の特定を飛ばしたことを意味します。

V4 — すべての引用が文字起こしの原文と逐語的に一致している。

• 決定的な確認（文字起こしが保持されている場合）： 各 > 引用ブロックについて、連続した引用部分が文字起こしのサイドカーに含まれていることを確認します。つなぎ言葉（like、you know、I mean）は両方から削除してもかまいません。実際の引用であれば、内容語が長く連続して一致しますが、捏造された引用は一致しません。

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

• プロンプト用チェックリスト（文字起こしが保持されていない場合）： ソースノートを読み直し、各引用が一語一句その記述に基づいていることを確認します。
• 引用が原文と一致しない場合、ほとんどの場合、話された表現に戻す（または、より明確に連続した箇所を選ぶ）のが修正方法です。引用を削除するのではなく、引用ブロック内に言い換えを残してはいけません。

V5 — 架空の出席者に関する妥当性チェック。 録音ツールは、ラベルのない発言者の名前やメールアドレスを確信を持って捏造することがあります。

• 出席者の名前が文字起こしにも名簿の証拠にも一切出てこない場合、その名前は証拠によって裏付けられていません。推測として扱ってください。通話中の手掛かり（所属企業、共有している経歴など）から本人を特定するか、名前を削除します。
• 出席者のメールアドレスのドメインが、その人の申告した所属組織と一致しない場合は、捏造が疑われます（録音ツールはよくホストのドメインを拾います）。実際のアドレスを確認するか、フィールドを空にしてください。
• いずれかに該当した場合、自動で名前を変更したり、自動入力したりしてはいけません。文字起こしを読み、証拠に基づいて特定し、ページ＋フロントマター＋バックリンクを修正してから、このチェックリストを再実行してください。

V6 — 順序を確認する（内容ではなく順序）。 会議ページは内容の深さが正しくても順序が間違っている場合があります。この 2 つは独立した失敗要因であり、V1～V5 では順序を確認しません。語られた順序を確認してください：

1. イベントの原子を抽出します。 ページ本文を文書上の順序に沿って確認し、語られている各サブイベントを {phase, place, people} として列挙します。ここで phase は、文章が主張する会議の中心イベントに対する位置（前／最中／後）です。
2. 決定論的チェック（エージェントが実行する機械的なチェック。判断は不要です）：
   • PHASE_INVERSION（重大）: 「前」として語られているイベントが、文書上の並びでは中心イベントの後に現れる（またはその逆）。例：ページでalice-exampleのプレゼンの振り返りを語った後、プレゼン自体をまだこれから行われるかのように語っている。
   • TELEPORT（重大）: 同じ人物が、移動や移動手段についての記述がないまま、連続していない2つの場所に配置されている。例：ある段落ではalice-exampleが移動中の車内にいて、次の段落では、2つをつなぐ記述がないのに、すでにacme-exampleのオフィスにいる。
3. 当日のタイムラインとの照合（ソフトチェック）：

   gbrain day {date}
   

は、脳全体にある当日のイベントとタイムライン項目を集約します。

• DAY_TIMELINE_GAP: 語られている参加者が、その日の集約されたタイムラインに一度も登場しない場合は、重大な失敗ではなくシグナルです。多くの場合、その人のタイムライン項目がまだ記録されていないことを意味します（Phase 7/8に戻って修正してください）。場合によっては、実際にはその場にいなかった人物が語りに登場していることを意味します。調査してください。自動的にブロックしないでください。

4. 判定 — PASSまたはBLOCK。
   • 重大な矛盾がない → PASS。レポートに進みます。
   • PHASE_INVERSIONまたはTELEPORTがある → BLOCK。会議は取り込まれません。語りを修正し（正しい順序を確認するため、トランスクリプトを読み直してください）、V6を再実行します。または、ユーザーが明示的に記載どおりの順序で問題ないと述べた場合は、waiveを記録します。waiveは解決済みではなく、確認済みとしてレポートに記録されます：sequence: WAIVED by user — {contradiction} stands。
   • 順序が本当に曖昧な場合（フラッシュバック、順序を暗示しているものの明示していない文章）は、決定論的な分類ではなく判断が必要です。レポートに記載し、これを理由にブロックしないでください。

ループ： すべての項目が合格するまで（またはV6が明示的にwaiveされるまで）、修正 → 再チェック → 修正を繰り返します。その後、下書きの facts_backstop: false 行を削除して会議ページを保存し（Phase 5）、レポートを作成します。

機微な内容を含む会議

タイトルまたはトランスクリプトから、法的または極めて個人的な内容（証言録取、弁護士、法務顧問、秘匿特権、健康）だと判断できる場合は、ページを必要最小限かつ事実に即した内容にしてください。ユーザーが事実の抽出に同意しない限り、ページの facts_backstop: false はそのままにします。他のページに経歴に関する詳細を抽出せず、相互リンクは控えめにしてください。内容を他に反映すべきか判断に迷う場合は、ユーザーに確認してください。

出力形式

会議ページが作成され、検証チェックリストに合格しました。次のように報告します：「会議を取り込みました：参加者{N}名の情報を補完し、エンティティ{N}件を更新し、アクションアイテム{N}件を記録しました。検証：合格。順序：PASS。」順序チェックがwaiveされた場合は、明示的に次のように記載します：「順序：ユーザーによりWAIVED — {contradiction}はそのままです（確認済み、解決済みではありません）。」録音が分割された場合は、作成された会議ページごとに1行ずつ報告します。最終的な会議ページの保存時に記録された facts_backstop の結果を明記します：queued、または抽出を無効のままにする理由を添えた opted_out（ユーザーが抽出を許可していない機微な内容を含む会議）。Phase 6で主張を保留した場合、または矛盾にフラグを付けた場合は、フラグごとに列挙してください。解決するのはユーザーであり、何も報告せずに済ませてはいけません。チェックリストの項目に合格できないものがある場合は、会議が取り込まれなかったことを報告し、不合格の項目を明記します。

失敗した場合

gbrain のエラー code、終了コード、[AGENT] ブロック、または通知ブロックが発生した場合は、エージェント運用プロトコルに従ってください。このスキルに固有の対応は次のとおりです。

• 既存のページと矛盾する場合は、ユーザーが修正または免除するまで取り込みを中断します。両方の情報源を示して、返答を待ちます。
• 会議ページを書き込んだ後、add_link / 自動リンクでエラーが報告された場合：ページは保存されていますが、リンクは保存されていません。失敗したリンクを列挙し、スラッグを修正してから追加します。
• 出席者ページへの put_page が revision_conflict を返した場合：再読み込みしてマージします。古い読み込み内容で人物ページを上書きしてはいけません。

アンチパターン

• 出席者の情報を充実させずに会議ページを作成する
• エンティティへの反映を省略する（「後でやる」）
• 言及されたすべてのエンティティのタイムラインを統合しない
• 意味のある内容を含まない出席者の仮ページを作成する
• すべての参加者への相互リンクを付けずに会議ページを登録する
• ベンダーごとのパイプラインを構築したり、このスキルを場当たり的な指示で言い換えたりして、文字起こし記録に正規化しない
• 文字起こしで確認せず、録音ツールの自動要約にある名前や主張を事実として扱う
• 要約にある関係性／役割／所有権の主張について、文字起こしの逐語的な該当箇所を見つけずにエンティティページへ書き込む
• 文字化けした固有名詞をそのまま記載し、正式な表記を確認しない
• 未検証の主張を複数のエンティティページへ拡散する
• 新たな会議での主張について矛盾を指摘せず、確立済みの脳内情報を黙って上書きする
• 発言者の身元を推測せず、[Room]／UNKNOWN と記載してフラグを立てる
• 文字起こしを途中で切ったり、引用のブロック引用内で言い換えたりする
• 2つの会議が含まれる録音を1つのページに取り込む
• 検証チェックリストに合格する前に「取り込み済み」と報告する
• 文字起こしで確認せず、チェックリストを回避するために必須セクションへ - None. と記載する
• 「簡単な段取り確認の会議だから」という理由でチェックリストを省略する
• シーケンスの矛盾が未解決かつ未免除のまま、ページを取り込み済みと宣言する
• ユーザーによる免除を解決として扱う。免除は認識を示すものであり、矛盾はページに残ったままです
• 移動時間の記載がないまま、ある人物を連続していない2つの場所にいると記載したページを合格とする
• シーケンス確認の段階で内容を再確認する（または V1～V5 で順序を再確認する）。設計上、これらの確認軸は互いに直交しています