meeting-assistant/openspec/changes/define-meeting-assistant-v1/design.md

Context

Meeting Assistant is a local/server-side .NET 10 application that helps capture and process meetings. It should work for any meeting format, including in-person conversations, and should not require direct APIs from meeting products such as Teams or Zoom.

The central artifact is an Obsidian markdown note created before transcription begins. The user can add attendees, project context, meeting purpose, and live notes while the meeting is happening. Meeting Assistant can add discovered context to the same note, then later append or link summaries, next steps, and knowledge base updates.

Goals / Non-Goals

Goals:

• Establish a .NET 10 application skeleton and OpenSpec workflow.
• Model a platform-independent meeting session flow.
• Create a meeting note before transcription starts.
• Preserve user-authored notes as first-class input to summarization.
• Transcribe meeting audio with speaker attribution.
• Generate summaries, decisions, and next steps.
• Maintain project knowledge from meeting output and additional future sources.
• Let agents retrieve project context and keyword context.
• Allow guarded project file updates when the project context or user explicitly permits them.

Non-Goals:

• Build a Teams, Zoom, or calendar-specific integration in version 1.
• Require cloud transcription APIs.
• Define the final Obsidian vault path or note template completely in this first change.
• Implement unrestricted autonomous file edits.

Decisions

1. Build the source application as ASP.NET Core on .NET 10.

   • Rationale: It matches the requested runtime and keeps the application service-oriented.

2. Make the Obsidian markdown note the session anchor.

   • Rationale: The user can enrich the meeting context before and during transcription, and agents can work from a durable human-readable artifact.

3. Treat meeting-platform APIs as optional augmentation.

   • Rationale: The assistant must be usable for in-person meetings and for platforms where no integration is available or desired.

4. Keep project knowledge as a generic capability.

   • Rationale: Meeting-derived knowledge should later combine with other sources without coupling the design to transcripts only.

5. Require explicit guardrails for project file mutation.

   • Rationale: Agents may update project files, but only when the project is known and the user or project context permits edits.

Risks / Trade-offs

• [Risk] Speaker attribution quality depends on the selected transcription pipeline. -> Mitigation: keep attribution requirements observable and provider-independent.
• [Risk] The Obsidian note may become too dense. -> Mitigation: separate metadata, user notes, assistant context, transcript references, and generated outputs into clear sections.
• [Risk] Agent file updates could affect the wrong project. -> Mitigation: require explicit project binding before mutation tools are available.
• [Risk] Retrieval can surface stale or irrelevant project context. -> Mitigation: include source references and update timestamps in retrieved context.

Open Questions

• What exact Obsidian vault folder should hold meeting notes?
• What metadata fields are required before transcription can start?
• Which transcription provider should be used first?
• Which storage backend should hold embeddings and project knowledge?
• What approval model should govern agent project file edits?