Enterprise Meeting Knowledge Management System with: Backend (FastAPI): - Authentication proxy with JWT (pj-auth-api integration) - MySQL database with 4 tables (users, meetings, conclusions, actions) - Meeting CRUD with system code generation (C-YYYYMMDD-XX, A-YYYYMMDD-XX) - Dify LLM integration for AI summarization - Excel export with openpyxl - 20 unit tests (all passing) Client (Electron): - Login page with company auth - Meeting list with create/delete - Meeting detail with real-time transcription - Editable transcript textarea (single block, easy editing) - AI summarization with conclusions/action items - 5-second segment recording (efficient for long meetings) Sidecar (Python): - faster-whisper medium model with int8 quantization - ONNX Runtime VAD (lightweight, ~20MB vs PyTorch ~2GB) - Chinese punctuation processing - OpenCC for Traditional Chinese conversion - Anti-hallucination parameters - Auto-cleanup of temp audio files OpenSpec: - add-meeting-assistant-mvp (47 tasks, archived) - add-realtime-transcription (29 tasks, archived) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
76 lines
3.2 KiB
Markdown
76 lines
3.2 KiB
Markdown
# meeting-management Specification
|
|
|
|
## Purpose
|
|
TBD - created by archiving change add-meeting-assistant-mvp. Update Purpose after archive.
|
|
## Requirements
|
|
### Requirement: Create Meeting
|
|
The system SHALL allow users to create meetings with required metadata.
|
|
|
|
#### Scenario: Create meeting with all fields
|
|
- **WHEN** user submits POST /api/meetings with subject, meeting_time, chairperson, location, recorder, attendees
|
|
- **THEN** a new meeting record SHALL be created with auto-generated UUID and the meeting data SHALL be returned
|
|
|
|
#### Scenario: Create meeting with missing required fields
|
|
- **WHEN** user submits POST /api/meetings without subject or meeting_time
|
|
- **THEN** the server SHALL return HTTP 400 with validation error details
|
|
|
|
#### Scenario: Recorder defaults to current user
|
|
- **WHEN** user creates meeting without specifying recorder
|
|
- **THEN** the recorder field SHALL default to the logged-in user's email
|
|
|
|
### Requirement: List Meetings
|
|
The system SHALL allow users to retrieve a list of meetings.
|
|
|
|
#### Scenario: List all meetings for admin
|
|
- **WHEN** admin user requests GET /api/meetings
|
|
- **THEN** all meetings SHALL be returned
|
|
|
|
#### Scenario: List meetings for regular user
|
|
- **WHEN** regular user requests GET /api/meetings
|
|
- **THEN** only meetings where user is creator, recorder, or attendee SHALL be returned
|
|
|
|
### Requirement: Get Meeting Details
|
|
The system SHALL allow users to retrieve full meeting details including conclusions and action items.
|
|
|
|
#### Scenario: Get meeting with related data
|
|
- **WHEN** user requests GET /api/meetings/:id
|
|
- **THEN** meeting record with all conclusions and action_items SHALL be returned
|
|
|
|
#### Scenario: Get non-existent meeting
|
|
- **WHEN** user requests GET /api/meetings/:id for non-existent ID
|
|
- **THEN** the server SHALL return HTTP 404
|
|
|
|
### Requirement: Update Meeting
|
|
The system SHALL allow users to update meeting data, conclusions, and action items.
|
|
|
|
#### Scenario: Update meeting metadata
|
|
- **WHEN** user submits PUT /api/meetings/:id with updated fields
|
|
- **THEN** the meeting record SHALL be updated and new data returned
|
|
|
|
#### Scenario: Update action item status
|
|
- **WHEN** user updates action item status to "Done"
|
|
- **THEN** the action_items record SHALL reflect the new status
|
|
|
|
### Requirement: Delete Meeting
|
|
The system SHALL allow authorized users to delete meetings.
|
|
|
|
#### Scenario: Admin deletes any meeting
|
|
- **WHEN** admin user requests DELETE /api/meetings/:id
|
|
- **THEN** the meeting and all related conclusions and action_items SHALL be deleted
|
|
|
|
#### Scenario: User deletes own meeting
|
|
- **WHEN** user requests DELETE /api/meetings/:id for meeting they created
|
|
- **THEN** the meeting and all related data SHALL be deleted
|
|
|
|
### Requirement: System Code Generation
|
|
The system SHALL auto-generate unique system codes for conclusions and action items.
|
|
|
|
#### Scenario: Generate conclusion code
|
|
- **WHEN** a conclusion is created for a meeting on 2025-12-10
|
|
- **THEN** the system_code SHALL follow format C-20251210-XX where XX is sequence number
|
|
|
|
#### Scenario: Generate action item code
|
|
- **WHEN** an action item is created for a meeting on 2025-12-10
|
|
- **THEN** the system_code SHALL follow format A-20251210-XX where XX is sequence number
|
|
|