會議匯入
將一份會議記錄轉換為附有來源的會議頁面、更新後的實體檔案以及結構化的聲明，然後對其進行驗證。僅在需要時才閱讀參考資料：
- setup：總是優先執行（狀態、本體、搜尋）
- source acquisition：從 API 獲取資料，包括 Granola
- sources：保留原始資料；引文格式
- speakers：可能的拆分、重複或不明確的發言者
- identity：解析人物、公司或專案
- writing：在撰寫任何頁面內容之前
- meeting page：撰寫會議頁面
- profiles：建立或更新檔案
- assertions：聲明、參與關係邊、重新執行
- publish：批次或頁面寫入
- recovery：任何不確定、被拒絕或有衝突的寫入
- verify：驗證與報告
合約
- 每場實際會議建立一個頁面。保留完整記錄；錄音工具的摘要僅是聲明，而非事實。
- 發言者應基於證據並附帶信心度來解析，絕不猜測。使用所有真實訊號；只有在完全沒有任何訊號時，才將發言者保留為未解析狀態。
- 每位參與者（發言、被提及或以其他方式參與）都應建立一個檔案，其中包含時間軸記錄和一條參與關係邊。僅出現在邀請名單中的名字則不包含這兩項。
- 會議中提及的每個公司、專案或概念，若涉及實質性內容，都應建立（或尋找）一個頁面、一條時間軸記錄以及雙向連結。僅順帶提及的則不包含。
- 頁面風格應如同良好的人類筆記：先寫名字，少用限定詞，無過程評論。
- 決定、承諾和事件應轉化為聲明。未經驗證的聲明不應擴散到其他頁面。
- 在驗證通過之前，絕不將會議標記為「已完全匯入」。
步驟
1. 獲取與標準化
取得完整的會議記錄。空的、僅摘要或進行中的輸入會導致此步驟失敗：請回報。如果使用者只想儲存筆記，請使用 knowledge-capture，並說明會議匯入未完成。
在工作環境中標準化為：source, source_id, title, date, time, duration, attendees（來源聲明）、帶有 speaker、speaker_raw 和 text 的有序段落、來源摘要、URL。未知值設為 null。特定錄音工具的處理到此結束；之後所有工具都執行相同的步驟。
保留原始匯出檔案和會議記錄（sources）。標準化後的文字是帶有標籤的衍生品。分別報告獲取、保留和發佈的情況，並附上實際計數（例如「保留 9/16 份原始資料」）。
以約 150 行為一個區段，讀取標準化後的會議記錄一次。每個區段後，將以下內容附加到工作摘要檔案中：行號範圍、發言者、主題、候選決定、承諾和事實（附帶確切行號引用）、引用候選內容以及新的專有名詞。後續步驟將根據摘要進行草稿。只有在需要檢查特定行號範圍（以確認措辭或引用）時，才重新回到原始會議記錄，絕不進行全文重讀。
完成條件： 保存了完整會議記錄；持有證據收據；摘要涵蓋了每一行。
2. 分割、去重、解析發言者
檢查是否存在多場會議的錄音、此會議的現有頁面，以及發言者對應關係（speakers）。
完成條件： 每場實際會議都已分配其段落範圍；找到重複項；每個發言者標籤都已對應或明確標記為未解析，並附有依據。
3. 門控審查每個聲明
對照會議記錄和知識庫中該實體的既有資訊，檢查每個提議的聲明。
- 角色或關係：必須有明確段落支持，而非暗示。
- 所有權：必須有明確的所有權措辭；提及名字不等於擁有。
- 新的專有名詞：先在知識庫中搜尋，若允許則搜尋網路，以找到標準拼寫；否則將其寫為
Name (unverified spelling)，並且不為其建立頁面或連結。 - 重大人生或交易事件：必須有逐字逐句的支持，並與現有時間軸核對。
僅有會議記錄的支持是不夠的。同時須檢查：
- 矛盾： 它是否與知識庫已建立的內容衝突？預設情況下，既有內容優先。不要將衝突的聲明寫入檔案；將其保留在會議頁面上，並附上兩方的引用，然後在報告中列出以供使用者解決。只有在有明確、逐字支持的證據時才可覆寫，且仍須報告此變更。
- 合理性： 根據已知資訊，它是否可能發生？（兩個人不可能同時啟動同一個專案；去年成立的公司不可能在五年前被收購。）不可能的情況通常表示內容有誤。
- 驚喜： 如果使用者會說「等等，什麼？」，請套用所有檢查。將此驚喜以問題形式提出，而非將其解釋掉。
推論和不確定的身份應在會議頁面上標示，且永遠不會以事實的形式進入檔案、時間軸、元資料或關係。
完成條件： 每個聲明都被標記為「發佈」、「標記為不確定」或「保留」。
4. 發佈
順序：會議頁面 → 實體頁面 → 聲明與邊 → 連結編輯。批次處理相關記錄（publish）。
- 根據 meeting page 建立會議頁面。
- 對於每位參與者和實質性實體，請遵循
knowledge-entities技能 SKILL.md 中的步驟：它會解析實體、決定是否需要建立頁面，並撰寫檔案和時間軸記錄。與此技能同名的參考資料是相同的副本；使用您已讀過的，無需重讀。它唯一額外的參考資料是豐富（enrichment）（請閱讀其「During ingestion」章節）。 - 根據 assertions 建立聲明：決定、承諾、事實，以及一個描述會議本身的
source_event: true事件，並包含所有相關的entities。其他事件則保留各自的日期。 - 為每位參與者建立一條有證據的
attended關係。在最終版本的本體中，其方向為參與者 → 會議；請在定義中確認。設定source_page。 - 被提及且有頁面的人也會獲得連結。不要為未知的發言者建立頁面。
- 對於法律或個人內容，請保持會議頁面的事實性，並限制其僅擴散到檔案；若範圍不明確，請詢問。
完成條件： 計劃中的每筆記錄都在您的工作日誌中有一份已發佈的收據。
5. 驗證（嚴格關卡，每場會議必做）
先執行 verify。然後檢查：
- 實質內容： 必要章節需有內容或有基於來源的理由。
- 連結：
knowledge_verify的expectedLinks用於會議 ↔ 每個實體，加上聲明的entities/dependencies、承諾的owner，以及邊的from/to/label/source_page。每個連結的檔案都應有針對此會議的時間軸記錄。 - 狀態： 沒有任何更新後的檔案其 State 主題是以日期或會議名稱命名的。
- 風格： 在發佈前，將工作檔案中的草稿與 writing 進行比對：名字在前，沒有堆疊的限定詞，沒有給自己的註記，沒有填充行。不要為了檢查風格而重新讀取已發佈的頁面；修正後，僅重新讀取您修改過的章節。
- 發言者： 沒有原始標籤被當作已知人物；執行 speakers 中的虛假與會者檢查。
- 引用： 使用
knowledge_evidence_read讀取每個引用段落所在的幾行。僅填充詞（例如「like」、「you know」）可以有所不同。修正失敗的引用方法為恢復口語用詞，或選擇一個更乾淨的段落；永遠不要在引用中保留改寫內容。 - 順序： 比較敘述順序（之前/期間/之後、地點、人物）與時間戳記，不受標題順序影響。對相關實體使用
knowledge_chronicle_day（會議日期和時區）和knowledge_timeline。時間順序顛倒或不可能的地點/時間視為矛盾；永遠不要發明交通方式。修正並重新檢查，或記錄明確的使用者豁免，標記為 WAIVED（已豁免），而非 resolved（已解決）。豁免僅涵蓋順序。若參與者未出現在當天的時間日誌中，通常表示缺少時間軸記錄：請調查，不要阻止。真正模糊的順序應在報告中標記，而非阻止。
完成條件： 所有檢查皆通過，或失敗處已修正並重新檢查。
報告
每場會議一行（若是分割錄音則每頁一行）：頁面、保留的來源、豐富的參與者、更新或重複使用的實體、行動項目、聲明與邊、驗證結果、順序檢查為 PASS 或 WAIVED（附上未解決的矛盾）。在此報告中列出與知識庫的矛盾、保留的聲明、未解決的身份以及剩餘工作，而非寫在頁面上；由使用者解決。如果某項檢查無法通過，請將該會議報告為「未匯入」，並指明是哪項檢查。部分報告代表誠實的進度，而非完成。