8b6184ecc5
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>
3.0 KiB
3.0 KiB
ADDED 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