[epic] Misty meeting capabilities #211

Blocked by

#212, #125

Google Docs is the chosen destination for durable transcripts and minutes. #212 must settle the integration, identity, permissions, and retention design before the post-meeting strands can start. #125 (actor-scoped retrieval) is what the voice document-lookup strand consumes rather than rebuilds.

Summary

Misty can already carry a live meeting: /record streams transcription, generates minutes through the LLM service, and drops a PDF in the channel, and this issue in its current form makes those records durable and discoverable. What no issue owns is the meeting experience the team actually wants around that spine — live subtitles and translation while people are talking, a shared post-meeting notes drop members can find later, in-channel Q&A over what was said, and pulling a document by voice mid-meeting. #125 (retrieval) and #81 (helper bot) each solve a neighbouring problem, but neither covers the meeting surface itself. This epic is the umbrella for those four capabilities and folds the existing durable-records work in as the foundation the other three stand on.

Model

The work splits on two axes: live (happening during the call) versus post-meeting, and text versus voice. Four pillars fall out of that:

1. Live transcription surface — subtitles in-channel, with an optional translation layer, built on the transcription feed /record already produces.
2. Durable transcripts + notes in Google Docs — each completed meeting produces one native Google Doc containing the full transcript and generated minutes, saved in the configured team Drive folder. Misty catalogs its URL and posts a link in the originating channel.
3. /qna over the meeting — an in-channel command that answers questions from what was said, first against the live transcript, later against stored meetings.
4. Voice-driven document retrieval — asking Misty by voice to surface a document mid-meeting, answered through #125.

The governing constraint is unchanged from the current epic: audio is never persisted; only text-derived records (transcript, minutes, and metadata) are retained, and visibility is actor-scoped, so a private team's meeting is not made org-wide by default. Ordering is a consequence: #212's design gates the Google Docs persistence integration; persistence gates post-meeting delivery and /qna-over-past-meetings; the live transcription feed already exists and is the substrate for subtitles, translation, and live /qna; and voice-RAG waits on #125.

Decomposition

• [task]: Define Google Docs meeting records, identity, and retention #212 — Define the Google Docs write integration, meeting-to-Doc/catalog identity, metadata ownership, retention/removal policy, PDF handling, and visibility/consent decisions in docs/MEETING-RECORDING.md. The document destination is settled.
• [task] Save completed meeting transcripts and minutes as Google Docs #222 — Create the Google Doc after the session ends: full transcript, generated minutes, participants, channel, and start/end times; register its URL and retain structured decisions/action items as catalog-associated meeting metadata.
• [task] Deliver the saved Google Docs meeting link to the team #223 — Deliver the existing Google Doc link to the originating channel after persistence succeeds, respecting the meeting audience and making delivery retryable without duplicating the Doc.
• [task] Live subtitle stream during meetings #224 — surface the existing transcription feed as in-channel subtitles during the meeting.
• [task] /qna over the current meeting #225 — a text-channel command answering questions from the live transcript through the LLM service.
• [task] Voice document retrieval mid-meeting #226 — let a member ask by voice for a document, answered via [epic] Build authorized document retrieval and member search #125's actor-scoped retrieval.

What we can build on

• /record already streams transcription, generates minutes through the LLM service, and renders a PDF; directory lookup resolves Discord participants.
• Google Docs is the durable, member-readable transcript/notes artifact. documentation-system catalogs its real URL, ownership/grants, and content snapshot for [epic] Build authorized document retrieval and member search #125; [task]: Define Google Docs meeting records, identity, and retention #212 defines the associated meeting-metadata schema. These are complementary roles, not alternative destinations.
• [epic] Build authorized document retrieval and member search #125 owns actor-scoped document retrieval and member search; the voice-lookup strand consumes it.
• [epic] Fetch document text through authenticated source connectors #82 (authenticated source connectors) and [epic] Build shared internal authentication and an external gateway #60 (internal auth + external gateway) are the prior art for Google egress. The existing connector can read Google Docs; document creation, folder placement, and write authorization are new work in [task] Save completed meeting transcripts and minutes as Google Docs #222.
• docs/MEETING-RECORDING.md (via [task]: Define Google Docs meeting records, identity, and retention #212) is the cross-service design of record.

Not in this epic

• Embedding and general document retrieval — owned by [epic] Build authorized document retrieval and member search #125; this epic consumes it, it does not rebuild it.
• The generic member-facing helper bot — owned by [epic] Build a member-facing helper bot #81; /qna here is meeting-scoped.
• Document visibility enforcement for the asking member — owned by [epic] Scope document access and Misty answers #77.
• Action-item chasing, reminders, and nudges.
• Changes to core transcription or speaker handling.

Open questions

• Google setup: which team folders, file-owning account or Shared Drive, write scopes, and permission mapping? [task]: Define Google Docs meeting records, identity, and retention #212 resolves these; Google Docs is already chosen. A service account needs a Shared Drive for file creation, or the integration must act on behalf of a user via OAuth.
• Consent & default visibility: must participants explicitly consent to persistence, and what is a meeting's default scope?
• /qna corpus: live transcript only at first, or also across stored past meetings?
• Translation: which target languages, and is it on-demand or always-on?
• Voice-RAG trigger: wake word vs an explicit voice command, and the acceptable latency budget for both subtitles and voice lookup.

Area

bot, service, docs-system, integration