feat: Initial commit - Task Reporter incident response system

Complete implementation of the production line incident response system (生產線異常即時反應系統) including:

Backend (FastAPI):
- User authentication with AD integration and session management
- Chat room management (create, list, update, members, roles)
- Real-time messaging via WebSocket (typing indicators, reactions)
- File storage with MinIO (upload, download, image preview)

Frontend (React + Vite):
- Authentication flow with token management
- Room list with filtering, search, and pagination
- Real-time chat interface with WebSocket
- File upload with drag-and-drop and image preview
- Member management and room settings
- Breadcrumb navigation
- 53 unit tests (Vitest)

Specifications:
- authentication: AD auth, sessions, JWT tokens
- chat-room: rooms, members, templates
- realtime-messaging: WebSocket, messages, reactions
- file-storage: MinIO integration, file management
- frontend-core: React SPA structure

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

openspec/project.md

@@ -0,0 +1,71 @@
+# Project Context
+
+## Purpose
+**Production Line Incident Response System (生產線異常即時反應系統)**
+
+An on-premise, centralized event response platform that transforms chaotic communication channels (LINE, Teams, radio) into structured, traceable data. Each production incident (equipment failure, material shortage, quality issues) gets a dedicated chat room where all messages, images, and documents are collected. The system uses on-premise AI (Ollama) to automatically generate professional .docx reports with timelines and embedded evidence.
+
+**Business Value:**
+- Reduce MTTR (Mean Time To Resolution) through information centralization
+- Enable post-mortem analysis with complete digital audit trails
+- Automate report generation from hours to minutes
+- Keep sensitive production data inside corporate network
+
+## Tech Stack
+- **Backend**: Python (FastAPI) - API server with built-in WebSocket support (localhost:8000)
+- **Database**: PostgreSQL v14+ - Metadata storage for users, incident rooms, messages (localhost:5432)
+- **Object Storage**: MinIO - S3-compatible storage for images/PDFs/logs (localhost:9000)
+- **AI**: Ollama - On-premise LLM for JSON blueprint generation (localhost:11434)
+- **Frontend**: React (Vite) - Single-page application served as static files
+- **Real-time**: WebSockets (native FastAPI support) - Bidirectional communication
+- **Document Generation**: python-docx - Dynamic .docx assembly with embedded images
+
+## Project Conventions
+
+### Code Style
+- **Python Backend**: Follow PEP 8, use type hints (Python 3.10+)
+- **React Frontend**: ESLint + Prettier (configure as needed)
+- Use descriptive variable names in English
+- Comments and documentation in Traditional Chinese when needed for domain concepts
+
+### Architecture Patterns
+- **Single-server deployment**: All services (FastAPI, PostgreSQL, MinIO, Ollama) run on one internal server
+- **Event-driven architecture**: Each incident is an independent chat room
+- **Frontend-backend separation**: React SPA communicates with FastAPI via REST + WebSocket
+- **On-premise first**: All services communicate via localhost, no external dependencies
+- **Security**: All communication within corporate firewall, files never leave internal network
+
+### Testing Strategy
+- **TDD (Test-Driven Development)**: Write tests before implementation
+- **Unit Tests (UT)**: Test individual functions (e.g., `prepare_ai_input`, `assemble_docx`)
+- **Integration Tests (IT)**: Test cross-service flows (e.g., file upload → MinIO → DB → WebSocket broadcast)
+- **End-to-End Tests (E2E)**: Full user workflows (login → create room → upload image → send message → generate report)
+- Use pytest for backend testing
+- Mock Ollama responses for deterministic AI testing
+
+### Git Workflow
+- **Specification-Driven Development (SDD)**: All features must align with spec requirements
+- Use feature branches for each phase (e.g., `phase-1-backend-core`, `phase-2-realtime`)
+- Commit messages in English, reference task IDs (e.g., "T-2.3: Implement MinIO upload service")
+
+## Domain Context
+**Manufacturing Operations:**
+- **Incident types**: Equipment failure, material shortage, quality issues
+- **Users**: Line operators, supervisors, engineers, managers
+- **Workflow**: Incident reported → chat room created → team collaborates → AI generates report → supervisor reviews and closes
+- **Critical requirement**: Audit trail for compliance and continuous improvement
+- **Sensitive data**: Production photos, equipment logs, defect images (must stay on-premise)
+
+## Important Constraints
+- **No external cloud services**: All components (app, DB, storage, AI) must run on corporate servers
+- **Network isolation**: System operates in internal network only
+- **Data sovereignty**: Production data cannot leave corporate infrastructure
+- **Scalability**: Initially single production line, may expand to multiple buildings/sites
+- **Compliance**: May need to satisfy ISO 9001 or similar quality management audit requirements
+
+## External Dependencies
+- **Internal only**:
+  - PostgreSQL server
+  - MinIO cluster
+  - Ollama AI inference server
+- **No external APIs**: All services are self-hosted