Build your own meeting bot
(a personal Otter)

Build the webhook receiver and bot spawner for a personal meeting bot. Requirements:
- Node 20+ with Express, better-sqlite3, and dotenv; put secrets in .env and ship .env.example
- SQLite schema: meetings (id, status, platform, started_at) and segments (id, meeting_id, speaker, text, ts_start, ts_end)
- POST /bots accepts {meeting_url, bot_name}, calls the Recall.ai create-bot endpoint with webhook_url set to your public base URL plus /webhook, and stores the returned bot id
- POST /webhook verifies a shared secret header, then updates meeting status on bot.status events and inserts segments on transcript events
- GET /bots/:id returns the meeting row plus segment count so you can watch progress
- Graceful failure: a bad meeting link returns a clear 400 naming what Recall rejected
- Out of scope: summaries, search, chat, and any frontend
- Pain warning: webhooks must reply 200 fast or Recall retries, so acknowledge before doing heavy work
Done means creating a bot against a dummy link writes a meeting row and your webhook accepts a hand-delivered transcript event.

Wire the bot into a real meeting and persist the transcript stream. Requirements:
- On bot.status events map waiting, joining, in_meeting, leaving, and completed to the meetings.status column
- On transcript events insert one row per segment: meeting_id, speaker, text, ts_start, ts_end
- Keep speaker labels as given by the platform's per-participant audio, stored verbatim
- On participant events, log join and leave times to a participants table so you can map speakers to names
- When the bot completes, mark the meeting finished and write the raw transcript to a file
- Handle the lobby: if the bot sits in waiting for more than 90 seconds, surface a clear message saying the host must admit it
- Pain warning: Google Meet may deny bots by name under some access settings, treat that as a real outcome to report, not an error to hide
Done means a completed test meeting has segments in SQLite with speaker names and a transcript file on disk.

Add LLM note generation over stored meeting transcripts. Requirements:
- For a finished meeting, send the transcript segments (speaker, text, timestamp) to the LLM with a system prompt requesting: a five-bullet summary, decisions made, and action items each with an owner
- Write the result to notes/<meeting_id>.md with the meeting title and date in front matter
- Reuse the transcript file from the capture step as the source of truth, never the webhook payload
- Keep the LLM key in .env and fail with a clear message when it is missing
- Add a POST /bots/:id/notes endpoint that triggers generation and returns the note path
- Out of scope: template libraries, per-speaker summaries, sentiment
- Pain warning: long meetings exceed context windows, chunk the transcript by timestamp and summarize in passes
Done means one real meeting produces a notes file with a summary, decisions, and owned action items.

Add full-text search and question answering over the transcript archive. Requirements:
- Create an FTS5 virtual table over segments with content = segments so rows stay in sync
- GET /search?q= returns matching segments with meeting id, speaker, and timestamp, ranked by relevance
- GET /meetings/:id/ask?q= retrieves the top matching segments and asks the LLM to answer using only that context, then returns the answer plus the segments it used
- Render results with the query terms highlighted and a link to each meeting
- Out of scope: semantic embeddings, cross-meeting chat, typo tolerance
- Pain warning: FTS5 tokenizes brackets oddly, so test quoted phrases against bare words
Done means a search for a phrase from a real transcript returns the right segment and ask answers with a citation.

Add nightly export and bot-media cleanup to the meeting bot. Requirements:
- scripts/export.js writes one .md file per meeting into ./export/ combining the raw transcript and the generated note
- Clear ./export/ at the start of each run and log the count of files written
- After a meeting is exported, delete its media from Recall via the delete-bot-media API so storage stays bounded
- Add npm run export to package.json and README instructions for launchd on macOS or cron on Linux
- Acceptance: running export twice yields byte-identical files and the meeting list is unchanged
- Out of scope: uploading exports, object storage, anything cloud
- Pain warning: deleting media is irreversible, so only delete meetings already exported and marked finished
Done means a second export run matches the first byte for byte.