meetings/

Meeting extraction from three independent sources — Google Meet (via email), Fathom recordings, and Notion inbox — writing to a shared entity store. This domain is the exemplar for the entity pipeline pattern.

Scripts

Data Flow

flowchart TD
  email["Email cache"] --> extract["extract.ts"]
  extract --> packages["meeting packages\n(silo/meetings/id/)"]
  packages --> fetch["fetch-notes.ts"]
  fetch --> gemini["Gemini docs\n(gog export)"]
  fetch --> fathom["Fathom transcripts\n(puppeteer / share page)"]

  notion["Notion inbox"] --> ingest["ingest-notion.ts\n(browser extract)"]
  ingest --> notionPkg["meeting packages\n(summary.txt, transcript.txt,\nmeeting.json)"]
Copy

Meeting Package Structure

Each meeting lives in a directory under {silo}/meetings/{meetingId}/:

• meeting.json — canonical metadata (Zod-validated via meeting-schema.ts). participants holds email addresses (they derive the meeting id); people lists the participants who are in the people config as { id, name } (config.md) and is absent when none are
• transcript.txt — extracted transcript (from Gemini, Fathom, or Notion)
• summary.txt — meeting summary (from Fathom or Notion)
• gemini_link.txt — Google Meet Gemini doc URL
• fathom-*.html — raw Fathom email HTML
• Source email JSON files

Three Independent Extractors

1. Google Meet (via email): Detects meeting invitations/summaries in email, extracts participants, creates packages with gemini_link.txt; fetch-notes.ts then exports the Gemini doc transcript via gog as the meeting's source mailbox
2. Fathom (via email + share pages): Detects Fathom recording URLs in email bodies, fetches transcripts from public share pages using puppeteer-core with headless Chrome
3. Notion (via API + browser): Queries a Notion inbox database, extracts content (Summary/Notes/Transcript tabs) via gateway browser tool, archives processed pages

Prerequisites

• Gmail OAuth via gog (email pipeline must be running for extract/fetch-notes)
• For Notion ingestion: NOTION_API_KEY_PATH, and two refs in pipeline.refs (see the pipeline block): notion.inboxDataSourceId (the Inbox data source meetings-ingest-notion queries) and notion.archiveDatabaseId (the database each processed page is copied into)
• Chrome installed (for Fathom share page extraction via puppeteer-core)

Key Files

reportOnly catch-up

While a meeting's account is report-only (emailConfig.reportOnly is true, or the account's own accounts[].reportOnly is), extract.ts still packages its new meetings but enqueues none of their Gmail actions. Instead it records each new meeting as pending (runner state namespace meetings, collection pendingEmailActions, keyed by source key).

Each run catches up to 20 pending meetings whose account is no longer report-only (CATCH_UP_PER_RUN in lib/pending-actions.ts), so a long report-only window drains gradually. Pending meetings of an account that is still report-only stay pending and do not count towards the 20:

• Actions are built from the message's current labels in the thread cache. A message a human has since labelled watch, or already moved out of the inbox, is not archived. A message no longer in the cache gets the meeting label only.
• The current emailConfig.meetings.archive setting applies.
• Everything goes through enqueueEmailUpdates, the single per-account report-only gate. A meeting's pending record is removed once its actions are enqueued, so nothing is enqueued twice.

Only meetings packaged while report-only after this behaviour was introduced are pending. Meetings packaged earlier have no record and are never caught up, so turning report-only off can't mass-archive old mail. A pending record that can't be read is moved, unchanged, to the pendingEmailActionsInvalid collection (same namespace) and named in a WARNING line in the run log. It is never retried: inspect it, then re-create or delete it by hand. To discard pending actions instead of applying them, delete the pendingEmailActions items in the meetings namespace before turning report-only off.