Previous limit was too conservative:
- Old: 10 messages (5 conversation turns) 鉂?Too limited
- New: 100 messages (50 conversation turns) 鉁?Reasonable
Context capacity comparison:
- DeepSeek-V3: 64K tokens 鈮?100-200 turns
- Qwen3-72B: 128K tokens 鈮?200-400 turns
- Previous 10 messages was only using ~1% of capacity
Real usage scenarios:
- Quick consultation: 5-10 turns
- In-depth discussion: 20-50 turns 鉁?Common
- Complete research design: 50-100 turns
The new 100-message limit covers 99% of real use cases while
staying well within model token limits.
Critical bug fix: Project background was being sent with EVERY message,
causing AI to respond to background instead of follow-up questions.
Problem:
- First message: User asks A, AI answers A 鉁?- Second message: User asks B, but prompt includes background again
- AI responds to background content, ignores question B 鉂?
Solution:
- Only send full prompt template (with project background) on FIRST message
- For follow-up messages, send ONLY user input (+ knowledge base if exists)
- Maintain conversation history properly
Updated: conversationService.assembleContext()
- Check if historyMessages.length === 0 (first message)
- First message: use renderUserPrompt() with all variables
- Follow-up: send userInput directly (optionally with knowledge base)
This ensures multi-turn conversations work correctly.
Changed userId from '1' to 'user-mock-001' in all conversation controller methods to match the actual mock user created in database.
This fixes the 400 error when creating conversations.
Issues fixed:
1. Frontend port is 3000 (not 5173)
2. Projects API returns 500 due to missing user
3. Foreign key constraint violation on projects_user_id_fkey
Solutions:
- Created create-mock-user.ts script
- Added user-mock-001 to database
- Created startup guide (娴嬭瘯鍜屽惎鍔?md)
- Created one-click launcher (涓€閿惎鍔?bat)
- Created diagnostic tool (璇婃柇闂.bat)
New files:
- backend/src/scripts/create-mock-user.ts
- 娴嬭瘯鍜屽惎鍔?md
- 涓€閿惎鍔?bat
- 璇婃柇闂.bat
Backend:
- Create project routes (GET, POST, PUT, DELETE)
- Implement projectController with CRUD operations
- Create projectService for database operations
- Add validation middleware for request validation
- Update Prisma schema (add background, researchType, deletedAt fields)
- Implement soft delete for projects
Frontend:
- Create projectApi service module
- Update useProjectStore with fetchProjects and loading state
- Connect ProjectSelector to real API with loading indicator
- Connect CreateProjectDialog to real API with error handling
- Connect EditProjectDialog to real API with loading state
- Add comprehensive error handling and user feedback
Build: Both frontend and backend build successfully
