d30bf95815
feat(auth): integrate Aliyun SMS verification flow with docs update
...
Wire auth verification-code delivery to Aliyun SMS with mock fallback, config validation, and a standalone SMS smoke-test script. Update deployment checklist and system status docs with required env vars and rollout notes.
Made-with: Cursor
2026-03-09 20:30:52 +08:00
a666649fd4
feat(iit): harden QC pipeline consistency and release artifacts
...
Implement IIT quality workflow hardening across eQuery deduplication, guard metadata validation, timeline/readability improvements, and chat evidence fallbacks, then synchronize release and development documentation for deployment handoff.
Includes migration/scripts for open eQuery dedupe guards, orchestration/status semantics, report/tool readability fixes, and updated module status plus deployment checklist.
Made-with: Cursor
2026-03-08 21:54:35 +08:00
c3f7d54fdf
feat(platform): Implement legacy system integration with Wrapper Bridge architecture
...
Complete integration of the old clinical research platform (www.xunzhengyixue.com)
into the new AI platform via Token injection + iframe embedding:
Backend:
- Add legacy-bridge module (MySQL pool, auth service, routes)
- POST /api/v1/legacy/auth: JWT -> phone lookup -> Token injection into old MySQL
- Auto-create user in old system if not found (matched by phone number)
Frontend:
- LegacySystemPage: iframe container with Bridge URL construction
- ResearchManagement + StatisticalTools entry components
- Module registry updated from external links to iframe embed mode
ECS (token-bridge.html deployed to www.xunzhengyixue.com):
- Wrapper Bridge: sets cookies within same-origin context
- Storage Access API for cross-site dev environments
- CSS injection: hide old system nav/footer, remove padding gaps
- Inner iframe loads target page with full DOM access (same-origin)
Key technical decisions:
- Token injection (direct MySQL write) instead of calling login API
- Wrapper Bridge instead of parent-page cookie setting (cross-origin fix)
- Storage Access API + SameSite=None;Secure for third-party cookie handling
- User isolation guaranteed by phone number matching
Documentation:
- Integration plan v4.0 with full implementation record
- Implementation summary with 6 pitfalls documented
- System status guide updated (ST module now integrated)
Tested: Local E2E verified - auto login, research management, 126 statistical
tools, report generation, download, UI layout all working correctly
Made-with: Cursor
2026-02-27 21:54:38 +08:00
dc6b292308
docs(asl): Complete Tool 3 extraction workbench V2.0 development plan (v1.5)
...
ASL Tool 3 Development Plan:
- Architecture blueprint v1.5 (6 rounds of architecture review, 13 red lines)
- M1/M2/M3 sprint checklists (Skeleton Pipeline / HITL Workbench / Dynamic Template Engine)
- Code patterns cookbook (9 chapters: Fan-out, Prompt engineering, ACL, SSE dual-track, etc.)
- Key patterns: Fan-out with Last Child Wins, Optimistic Locking, teamConcurrency throttling
- PKB ACL integration (anti-corruption layer), MinerU Cache-Aside, NOTIFY/LISTEN cross-pod SSE
- Data consistency snapshot for long-running extraction tasks
Platform capability:
- Add distributed Fan-out task pattern development guide (7 patterns + 10 anti-patterns)
- Add system-level async architecture risk analysis blueprint
- Add PDF table extraction engine design and usage guide (MinerU integration)
- Add table extraction source code (TableExtractionManager + MinerU engine)
Documentation updates:
- Update ASL module status with Tool 3 V2.0 plan readiness
- Update system status document (v6.2) with latest milestones
- Add V2.0 product requirements, prototypes, and data dictionary specs
- Add architecture review documents (4 rounds of review feedback)
- Add test PDF files for extraction validation
Co-authored-by: Cursor <cursoragent@cursor.com >
2026-02-23 22:49:16 +08:00
5db4a7064c
feat(iit): Implement real-time quality control system
...
Summary:
- Add 4 new database tables: iit_field_metadata, iit_qc_logs, iit_record_summary, iit_qc_project_stats
- Implement pg-boss debounce mechanism in WebhookController
- Refactor QC Worker for dual output: QC logs + record summary
- Enhance HardRuleEngine to support form-based rule filtering
- Create QcService for QC data queries
- Optimize ChatService with new intents: query_enrollment, query_qc_status
- Add admin batch operations: one-click full QC + one-click full summary
- Create IIT Admin management module: project config, QC rules, user mapping
Status: Code complete, pending end-to-end testing
Co-authored-by: Cursor <cursoragent@cursor.com >
2026-02-07 21:56:11 +08:00
9c96f75c52
feat(storage): integrate Alibaba Cloud OSS for file persistence - Add OSSAdapter and LocalAdapter with StorageFactory pattern - Integrate PKB module with OSS upload - Rename difyDocumentId to storageKey - Create 4 OSS buckets and development specification
2026-01-22 22:02:20 +08:00
1ece9a4ae8
feat(asl): Add DeepSearch smart literature retrieval MVP
...
Features:
- Integrate unifuncs DeepSearch API (OpenAI compatible protocol)
- SSE real-time streaming for AI thinking process display
- Natural language input, auto-generate PubMed search strategy
- Extract and display PubMed literature links
- Database storage for task records (asl_research_tasks)
Backend:
- researchService.ts - Core business logic with SSE streaming
- researchController.ts - SSE stream endpoint
- researchWorker.ts - Async task worker (backup mode)
- schema.prisma - AslResearchTask model
Frontend:
- ResearchSearch.tsx - Search page with unified content stream
- ResearchSearch.css - Styling (unifuncs-inspired simple design)
- ASLLayout.tsx - Enable menu item
- api/index.ts - Add research API functions
API Endpoints:
- POST /api/v1/asl/research/stream - SSE streaming search
- POST /api/v1/asl/research/tasks - Async task creation
- GET /api/v1/asl/research/tasks/:taskId/status - Task status
Documentation:
- Development record for DeepSearch integration
- Update ASL module status (v1.5)
- Update system status (v3.7)
Known limitations:
- SSE mode, task interrupts when leaving page
- Cost ~0.3 RMB per search (unifuncs API)
2026-01-18 19:15:55 +08:00
66255368b7
feat(admin): Add user management and upgrade to module permission system
...
Features - User Management (Phase 4.1):
- Database: Add user_modules table for fine-grained module permissions
- Database: Add 4 user permissions (view/create/edit/delete) to role_permissions
- Backend: UserService (780 lines) - CRUD with tenant isolation
- Backend: UserController + UserRoutes (648 lines) - 13 API endpoints
- Backend: Batch import users from Excel
- Frontend: UserListPage (412 lines) - list/filter/search/pagination
- Frontend: UserFormPage (341 lines) - create/edit with module config
- Frontend: UserDetailPage (393 lines) - details/tenant/module management
- Frontend: 3 modal components (592 lines) - import/assign/configure
- API: GET/POST/PUT/DELETE /api/admin/users/* endpoints
Architecture Upgrade - Module Permission System:
- Backend: Add getUserModules() method in auth.service
- Backend: Login API returns modules array in user object
- Frontend: AuthContext adds hasModule() method
- Frontend: Navigation filters modules based on user.modules
- Frontend: RouteGuard checks requiredModule instead of requiredVersion
- Frontend: Remove deprecated version-based permission system
- UX: Only show accessible modules in navigation (clean UI)
- UX: Smart redirect after login (avoid 403 for regular users)
Fixes:
- Fix UTF-8 encoding corruption in ~100 docs files
- Fix pageSize type conversion in userService (String to Number)
- Fix authUser undefined error in TopNavigation
- Fix login redirect logic with role-based access check
- Update Git commit guidelines v1.2 with UTF-8 safety rules
Database Changes:
- CREATE TABLE user_modules (user_id, tenant_id, module_code, is_enabled)
- ADD UNIQUE CONSTRAINT (user_id, tenant_id, module_code)
- INSERT 4 permissions + role assignments
- UPDATE PUBLIC tenant with 8 module subscriptions
Technical:
- Backend: 5 new files (~2400 lines)
- Frontend: 10 new files (~2500 lines)
- Docs: 1 development record + 2 status updates + 1 guideline update
- Total: ~4900 lines of code
Status: User management 100% complete, module permission system operational
2026-01-16 13:42:10 +08:00
5523ef36ea
feat(admin): Complete Phase 3.5.1-3.5.4 Prompt Management System (83%)
...
Summary:
- Implement Prompt management infrastructure and core services
- Build admin portal frontend with light theme
- Integrate CodeMirror 6 editor for non-technical users
Phase 3.5.1: Infrastructure Setup
- Create capability_schema for Prompt storage
- Add prompt_templates and prompt_versions tables
- Add prompt:view/edit/debug/publish permissions
- Migrate RVW prompts to database (RVW_EDITORIAL, RVW_METHODOLOGY)
Phase 3.5.2: PromptService Core
- Implement gray preview logic (DRAFT for debuggers, ACTIVE for users)
- Module-level debug control (setDebugMode)
- Handlebars template rendering
- Variable extraction and validation (extractVariables, validateVariables)
- Three-level disaster recovery (database -> cache -> hardcoded fallback)
Phase 3.5.3: Management API
- 8 RESTful endpoints (/api/admin/prompts/*)
- Permission control (PROMPT_ENGINEER can edit, SUPER_ADMIN can publish)
Phase 3.5.4: Frontend Management UI
- Build admin portal architecture (AdminLayout, OrgLayout)
- Add route system (/admin/*, /org/*)
- Implement PromptListPage (filter, search, debug switch)
- Implement PromptEditor (CodeMirror 6 simplified for clinical users)
- Implement PromptEditorPage (edit, save, publish, test, version history)
Technical Details:
- Backend: 6 files, ~2044 lines (prompt.service.ts 596 lines)
- Frontend: 9 files, ~1735 lines (PromptEditorPage.tsx 399 lines)
- CodeMirror 6: Line numbers, auto-wrap, variable highlight, search, undo/redo
- Chinese-friendly: 15px font, 1.8 line-height, system fonts
Next Step: Phase 3.5.5 - Integrate RVW module with PromptService
Tested: Backend API tests passed (8/8), Frontend pending user testing
Status: Ready for Phase 3.5.5 RVW integration
2026-01-11 21:25:16 +08:00
36ce1bbcb2
feat(iit): Complete Day 3 - WeChat Work integration and URL verification
...
Summary:
- Implement WechatService (314 lines, push notifications)
- Implement WechatCallbackController (501 lines, async reply mode)
- Complete iit_quality_check Worker with WeChat notifications
- Configure WeChat routes (GET + POST /wechat/callback)
- Configure natapp tunnel for local development
- WeChat URL verification test passed
Technical Highlights:
- Async reply mode to avoid 5-second timeout
- Message encryption/decryption using @wecom/crypto
- Signature verification using getSignature
- natapp tunnel: https://iit.nat100.top
- Environment variables configuration completed
Technical Challenges Solved:
- Fix environment variable naming (WECHAT_CORP_SECRET)
- Fix @wecom/crypto import (createRequire for CommonJS)
- Fix decrypt function parameters (2 params, not 4)
- Fix Token character recognition (lowercase l vs digit 1)
- Regenerate EncodingAESKey (43 chars, correct format)
- Configure natapp for internal network penetration
Test Results:
- WeChat developer tool verification: PASSED
- Return status: request success
- HTTP 200, decrypted 23 characters correctly
- Backend logs: URL verification successful
Documentation:
- Add Day3 WeChat integration development record
- Update MVP development task list (Day 2-3 completed)
- Update module status guide (v1.2 -> v1.3)
- Overall completion: 35% -> 50%
Progress:
- Module completion: 35% -> 50%
- Day 3 development: COMPLETED
- Ready for end-to-end testing (REDCap -> WeChat)
2026-01-03 00:13:36 +08:00
fa72beea6c
feat(platform): Complete Postgres-Only architecture refactoring (Phase 1-7)
...
Major Changes:
- Implement Platform-Only architecture pattern (unified task management)
- Add PostgresCacheAdapter for unified caching (platform_schema.app_cache)
- Add PgBossQueue for job queue management (platform_schema.job)
- Implement CheckpointService using job.data (generic for all modules)
- Add intelligent threshold-based dual-mode processing (THRESHOLD=50)
- Add task splitting mechanism (auto chunk size recommendation)
- Refactor ASL screening service with smart mode selection
- Refactor DC extraction service with smart mode selection
- Register workers for ASL and DC modules
Technical Highlights:
- All task management data stored in platform_schema.job.data (JSONB)
- Business tables remain clean (no task management fields)
- CheckpointService is generic (shared by all modules)
- Zero code duplication (DRY principle)
- Follows 3-layer architecture principle
- Zero additional cost (no Redis needed, save 8400 CNY/year)
Code Statistics:
- New code: ~1750 lines
- Modified code: ~500 lines
- Test code: ~1800 lines
- Documentation: ~3000 lines
Testing:
- Unit tests: 8/8 passed
- Integration tests: 2/2 passed
- Architecture validation: passed
- Linter errors: 0
Files:
- Platform layer: PostgresCacheAdapter, PgBossQueue, CheckpointService, utils
- ASL module: screeningService, screeningWorker
- DC module: ExtractionController, extractionWorker
- Tests: 11 test files
- Docs: Updated 4 key documents
Status: Phase 1-7 completed, Phase 8-9 pending
2025-12-13 16:10:04 +08:00
d4d33528c7
feat(dc): Complete Phase 1 - Portal workbench page development
...
Summary:
- Implement DC module Portal page with 3 tool cards
- Create ToolCard component with decorative background and hover animations
- Implement TaskList component with table layout and progress bars
- Implement AssetLibrary component with tab switching and file cards
- Complete database verification (4 tables confirmed)
- Complete backend API verification (6 endpoints ready)
- Optimize UI to match prototype design (V2.html)
Frontend Components (~715 lines):
- components/ToolCard.tsx - Tool cards with animations
- components/TaskList.tsx - Recent tasks table view
- components/AssetLibrary.tsx - Data asset library with tabs
- hooks/useRecentTasks.ts - Task state management
- hooks/useAssets.ts - Asset state management
- pages/Portal.tsx - Main portal page
- types/portal.ts - TypeScript type definitions
Backend Verification:
- Backend API: 1495 lines code verified
- Database: dc_schema with 4 tables verified
- API endpoints: 6 endpoints tested (templates API works)
Documentation:
- Database verification report
- Backend API test report
- Phase 1 completion summary
- UI optimization report
- Development task checklist
- Development plan for Tool B
Status: Phase 1 completed (100%), ready for browser testing
Next: Phase 2 - Tool B Step 1 and 2 development
2025-12-02 21:53:24 +08:00
88cc049fb3
feat(asl): Complete Day 5 - Fulltext Screening Backend API Development
...
- Implement 5 core API endpoints (create task, get progress, get results, update decision, export Excel)
- Add FulltextScreeningController with Zod validation (652 lines)
- Implement ExcelExporter service with 4-sheet report generation (352 lines)
- Register routes under /api/v1/asl/fulltext-screening
- Create 31 REST Client test cases
- Add automated integration test script
- Fix PDF extraction fallback mechanism in LLM12FieldsService
- Update API design documentation to v3.0
- Update development plan to v1.2
- Create Day 5 development record
- Clean up temporary test files
2025-11-23 10:52:07 +08:00
beb7f7f559
feat(asl): Implement full-text screening core LLM service and validation system (Day 1-3)
...
Core Components:
- PDFStorageService with Dify/OSS adapters
- LLM12FieldsService with Nougat-first + dual-model + 3-layer JSON parsing
- PromptBuilder for dynamic prompt assembly
- MedicalLogicValidator with 5 rules + fault tolerance
- EvidenceChainValidator for citation integrity
- ConflictDetectionService for dual-model comparison
Prompt Engineering:
- System Prompt (6601 chars, Section-Aware strategy)
- User Prompt template (PICOS context injection)
- JSON Schema (12 fields constraints)
- Cochrane standards (not loaded in MVP)
Key Innovations:
- 3-layer JSON parsing (JSON.parse + json-repair + code block extraction)
- Promise.allSettled for dual-model fault tolerance
- safeGetFieldValue for robust field extraction
- Mixed CN/EN token calculation
Integration Tests:
- integration-test.ts (full test)
- quick-test.ts (quick test)
- cached-result-test.ts (fault tolerance test)
Documentation Updates:
- Development record (Day 2-3 summary)
- Quality assurance strategy (full-text screening)
- Development plan (progress update)
- Module status (v1.1 update)
- Technical debt (10 new items)
Test Results:
- JSON parsing success rate: 100%
- Medical logic validation: 5/5 passed
- Dual-model parallel processing: OK
- Cost per PDF: CNY 0.10
Files: 238 changed, 14383 insertions(+), 32 deletions(-)
Docs: docs/03-涓氬姟妯″潡/ASL-AI鏅鸿兘鏂囩尞/05-寮€鍙戣褰?2025-11-22_Day2-Day3_LLM鏈嶅姟涓庨獙璇佺郴缁熷紑鍙?md
2025-11-22 22:21:12 +08:00
3634933ece
refactor(asl): ASL frontend architecture refactoring with left navigation
...
- feat: Create ASLLayout component with 7-module left navigation
- feat: Implement Title Screening Settings page with optimized PICOS layout
- feat: Add placeholder pages for Workbench and Results
- fix: Fix nested routing structure for React Router v6
- fix: Resolve Spin component warning in MainLayout
- fix: Add QueryClientProvider to App.tsx
- style: Optimize PICOS form layout (P+I left, C+O+S right)
- style: Align Inclusion/Exclusion criteria side-by-side
- docs: Add architecture refactoring and routing fix reports
Ref: Week 2 Frontend Development
Scope: ASL module MVP - Title Abstract Screening
2025-11-18 21:51:51 +08:00
e3e7e028e8
feat(platform): Complete platform infrastructure implementation and verification
...
Platform Infrastructure - 8 Core Modules Completed:
- Storage Service (LocalAdapter + OSSAdapter stub)
- Logging System (Winston + JSON format)
- Cache Service (MemoryCache + Redis stub)
- Async Job Queue (MemoryQueue + DatabaseQueue stub)
- Health Check Endpoints (liveness/readiness/detailed)
- Database Connection Pool (with Serverless optimization)
- Environment Configuration Management
- Monitoring Metrics (DB connections/memory/API)
Key Features:
- Adapter Pattern for zero-code environment switching
- Full backward compatibility with legacy modules
- 100% test coverage (all 8 modules verified)
- Complete documentation (11 docs updated)
Technical Improvements:
- Fixed duplicate /health route registration issue
- Fixed TypeScript interface export (export type)
- Installed winston dependency
- Added structured logging with context support
- Implemented graceful shutdown for Serverless
- Added connection pool optimization for SAE
Documentation Updates:
- Platform infrastructure planning (04-骞冲彴鍩虹璁炬柦瑙勫垝.md)
- Implementation report (2025-11-17-骞冲彴鍩虹璁炬柦瀹炴柦瀹屾垚鎶ュ憡.md)
- Verification report (2025-11-17-骞冲彴鍩虹璁炬柦楠岃瘉鎶ュ憡.md)
- Git commit guidelines (06-Git鎻愪氦瑙勮寖.md) - Added commit frequency rules
- Updated 3 core architecture documents
Code Statistics:
- New code: 2,532 lines
- New files: 22
- Updated files: 130+
- Test pass rate: 100% (8/8 modules)
Deployment Readiness:
- Local environment: 鉁?Ready
- Cloud environment: 馃攧 Needs OSS/Redis dependencies
Next Steps:
- Ready to start ASL module development
- Can directly use storage/logger/cache/jobQueue
Tested: Local verification 100% passed
Related: #Platform-Infrastructure
2025-11-18 08:00:41 +08:00
0c5310fb77
refactor(backend): incremental architecture evolution (Task 19)
...
- Add common/ layer for shared capabilities (LLM, RAG, document, middleware)
- Add legacy/ layer for existing business code
- Move files to new structure (controllers, routes, services)
- Update index.ts for new route registration
- System remains fully functional
2025-11-16 15:42:44 +08:00
AI Clinical Dev Team
b26700a7d5
feat(backend): implement knowledge base management backend API
2025-10-11 11:32:47 +08:00
AI Clinical Dev Team
8a4c703128
feat: complete Dify client implementation (Day 19)
...
## Dify 瀹㈡埛绔皝瑁呭畬鎴?鉁?
### 瀹屾垚鐨勫伐浣?
1. 绫诲瀷瀹氫箟 (backend/src/clients/types.ts)
- Dataset, Document, Retrieval 鐩稿叧绫诲瀷
- 瀹屾暣鐨?TypeScript 绫诲瀷瀹氫箟
- 鑷畾涔?DifyError 閿欒绫?
2. DifyClient 鏍稿績绫?(backend/src/clients/DifyClient.ts)
- 鐭ヨ瘑搴撶鐞? createDataset, getDatasets, getDataset, deleteDataset
- 鏂囨。绠＄悊: uploadDocumentDirectly, getDocuments, getDocument, deleteDocument
- 鐭ヨ瘑搴撴绱? retrieveKnowledge (鏀寔璇箟鎼滅储銆乼op_k銆佺浉浼煎害闃堝€?
- 杈呭姪鏂规硶: waitForDocumentProcessing, uploadAndProcessDocument
3. 娴嬭瘯鑴氭湰 (backend/src/scripts/test-dify-client.ts)
- 8椤瑰畬鏁存祴璇曞叏閮ㄩ€氳繃
- 娴嬭瘯鑰楁椂绾?5绉? - 楠岃瘉鎵€鏈堿PI鍔熻兘姝ｅ父
### 娴嬭瘯缁撴灉
鉁?娴嬭瘯1: 鍒涘缓鐭ヨ瘑搴?鉁?娴嬭瘯2: 鑾峰彇鐭ヨ瘑搴撳垪琛?(鎵惧埌3涓?
鉁?娴嬭瘯3: 鑾峰彇鐭ヨ瘑搴撹鎯?鉁?娴嬭瘯4: 涓婁紶鏂囨。 (247 tokens)
鉁?娴嬭瘯5: 鑾峰彇鏂囨。鍒楄〃
鉁?娴嬭瘯6: 鐭ヨ瘑搴撴绱?(鐩镐技搴?.4420)
鉁?娴嬭瘯7: 鍒犻櫎鏂囨。
鉁?娴嬭瘯8: 鍒犻櫎鐭ヨ瘑搴?
### 鎶€鏈寒鐐?
- 瀹屽杽鐨勯敊璇鐞嗘満鍒?(axios 鎷︽埅鍣?
- 鏅鸿兘杞绛夊緟鏂囨。澶勭悊瀹屾垚
- FormData 鏂囦欢涓婁紶鏀寔
- 鍗曚緥妯″紡瀵煎嚭
- 鏀寔鑷畾涔夐厤缃?
### 渚濊禆鏇存柊
- form-data: ^4.0.0
- @types/form-data: ^2.5.0
### 閰嶇疆鏇存柊
- DIFY_API_KEY 鏇存柊涓烘湇鍔PI瀵嗛挜
- DIFY_API_URL=http://localhost/v1
### 鏂囨。鏇存柊
- 鏂板: docs/05-姣忔棩杩涘害/Day19-Dify瀹㈡埛绔皝瑁呭畬鎴?md
- 鏇存柊: docs/04-寮€鍙戣鍒?寮€鍙戦噷绋嬬.md (Day 19 鏍囪涓哄畬鎴?
### 涓嬩竴姝?
Day 20-22: 鐭ヨ瘑搴撶鐞嗗姛鑳?- 鏁版嵁搴撹〃璁捐 (KnowledgeBase, Document)
- 鍚庣 CRUD API
- 鍓嶇鐭ヨ瘑搴撶鐞嗛〉闈?- 鏂囨。涓婁紶缁勪欢
---
Progress: 閲岀▼纰?1 (MVP) 90% -> 鐭ヨ瘑搴撶鐞嗗紑鍙戜腑
2025-10-11 10:25:30 +08:00
AI Clinical Dev Team
8afff23995
docs: Day 12-13 completion summary and milestone update
2025-10-10 20:33:18 +08:00
AI Clinical Dev Team
864a0b1906
feat: Day 10-11 - Agent Configuration System completed
...
Backend:
- Create agents.yaml config file with 12 agents definition
- Create Prompt templates for topic-evaluation agent
- Implement agentService.ts for loading and managing agent configs
- Create agentController.ts with CRUD operations
- Create agent routes (GET /agents, /agents/:id, etc.)
- Register agent routes in main server
Frontend:
- Create agentApi.ts service module
- Update AgentChatPage to dynamically load agent config from API
- Add loading state and error handling
- Display agent details (description, category, model)
Build: Both frontend and backend build successfully
2025-10-10 20:13:08 +08:00
AI Clinical Dev Team
39e14cfb97
feat(backend): Day 5 - backend basic architecture setup completed
2025-10-10 15:56:45 +08:00
