Complete implementation of reasoning logs retrieval system that
replaces JSONL file-based logging with database-only storage.
Database Changes:
- Add trading_sessions table (one record per model-day)
- Add reasoning_logs table (conversation history with summaries)
- Add session_id column to positions table
- Add indexes for query performance
Agent Changes:
- Add conversation history tracking to BaseAgent
- Add AI-powered summary generation using same model
- Remove JSONL logging code (_log_message, _setup_logging)
- Preserve in-memory conversation tracking
ModelDayExecutor Changes:
- Create trading session at start of execution
- Store reasoning logs with AI-generated summaries
- Update session summary after completion
- Link positions to sessions via session_id
API Changes:
- Add GET /reasoning endpoint with filters (job_id, date, model)
- Support include_full_conversation parameter
- Return both summaries and full conversation on demand
- Include deployment mode info in responses
Documentation:
- Add complete API reference for GET /reasoning
- Add design document with architecture details
- Add implementation guide with step-by-step tasks
- Update Python and TypeScript client examples
Testing:
- Add 6 tests for conversation history tracking
- Add 4 tests for summary generation
- Add 5 tests for model_day_executor integration
- Add 8 tests for GET /reasoning endpoint
- Add 9 integration tests for E2E flow
- Update existing tests for schema changes
All 32 new feature tests passing. Total: 285 tests passing.
Document:
- New downloading_data status
- Warnings field in responses
- Async flow and monitoring
- Example usage patterns
Co-Authored-By: Claude <noreply@anthropic.com>
Add comprehensive design for moving price data downloads from
synchronous API endpoint to background worker thread.
Key changes:
- Fast API response (<1s) by deferring download to worker
- New job status "downloading_data" for visibility
- Graceful rate limit handling with warnings
- Enhanced logging for dev mode monitoring
- Backwards compatible API changes
Resolves API timeout issue when downloading missing price data.
Co-Authored-By: Claude <noreply@anthropic.com>
Add design document for layered configuration system that enables
per-deployment model customization while maintaining defaults.
Key features:
- Default config baked into image, user config via volume mount
- Root-level merge with user config taking precedence
- Fail-fast validation at container startup
- Clear error messages on validation failure
Addresses issue where mounted configs would overwrite default config
in image.
BREAKING CHANGE: end_date is now required and cannot be null/empty
New Features:
- Resume mode: Set start_date to null to continue from last completed date per model
- Idempotent by default: Skip already-completed dates with replace_existing=false
- Per-model independence: Each model resumes from its own last completed date
- Cold start handling: If no data exists in resume mode, runs only end_date as single day
API Changes:
- start_date: Now optional (null enables resume mode)
- end_date: Now REQUIRED (cannot be null or empty string)
- replace_existing: New optional field (default: false for idempotent behavior)
Implementation:
- Added JobManager.get_last_completed_date_for_model() method
- Added JobManager.get_completed_model_dates() method
- Updated create_job() to support model_day_filter for selective task creation
- Fixed bug with start_date=None in price data checks
Documentation:
- Updated API_REFERENCE.md with complete examples and behavior matrix
- Updated QUICK_START.md with resume mode examples
- Updated docs/user-guide/using-the-api.md
- Added CHANGELOG_NEW_API.md with migration guide
- Updated all integration tests for new schema
- Updated client library examples (Python, TypeScript)
Migration:
- Old: {"start_date": "2025-01-16"}
- New: {"start_date": "2025-01-16", "end_date": "2025-01-16"}
- Resume: {"start_date": null, "end_date": "2025-01-31"}
See CHANGELOG_NEW_API.md for complete details.
Complete rebrand of project to reflect REST API service architecture:
- Updated all documentation (README, guides, API reference)
- Updated Docker configuration (compose, Dockerfile, images)
- Updated all repository URLs to Xe138/AI-Trader-Server
- Updated all Docker images to ghcr.io/xe138/ai-trader-server
- Added fork acknowledgment crediting HKUDS/AI-Trader
- Updated GitHub Actions workflows and shell scripts
All 4 phases completed with validation checkpoints.
Co-Authored-By: Claude <noreply@anthropic.com>
Update deployment documentation files:
- docker-deployment.md: Update git clone URL, Docker image references
(ghcr.io/xe138/ai-trader to ghcr.io/xe138/ai-trader-server), and
container/service names (ai-trader to ai-trader-server)
- monitoring.md: Update container names in all docker commands
- scaling.md: Update multi-instance service names and Docker image
references
All deployment examples now use ai-trader-server naming.
Part of Phase 3: Developer & Deployment Documentation
Update developer documentation files:
- CONTRIBUTING.md: Update title to AI-Trader-Server
- development-setup.md: Update git clone URL from
github.com/Xe138/AI-Trader to github.com/Xe138/AI-Trader-Server
- testing.md: Update title to reference AI-Trader-Server
Part of Phase 3: Developer & Deployment Documentation
Update all user-guide documentation files:
- configuration.md: Update title and container name references
- using-the-api.md: Update title
- integration-examples.md: Update title, class names
(AsyncAITraderServerClient), container names, DAG names, and log paths
- troubleshooting.md: Update title, container names (ai-trader to
ai-trader-server), GitHub issues URL
All Docker commands and code examples now reference ai-trader-server
container name.
Part of Phase 3: Developer & Deployment Documentation
Added comprehensive implementation plan for development mode feature
and test configuration used during verification.
Files:
- docs/plans/2025-11-01-dev-mode-mock-ai.md: Complete 12-task plan
- configs/test_dev_mode.json: Test configuration for dev mode
These files document the feature implementation process and provide
reference configurations for testing.
Fix critical bug where dev mode was initializing the production database
path instead of the dev database path. The initialize_dev_database() call
now correctly uses get_db_path() to resolve to data/jobs_dev.db.
Impact:
- Before: DEV mode would reset data/jobs.db (production database)
- After: DEV mode correctly resets data/jobs_dev.db (dev database)
Testing:
- Verified database isolation between dev and prod
- Confirmed PRESERVE_DEV_DATA flag works correctly
- Validated dev mode banner and deployment mode detection
Documentation:
- Added comprehensive manual verification results
- Documented all test cases and outcomes
- Recorded fix details for future reference
Task: Task 12 - Manual Verification and Final Testing
Plan: docs/plans/2025-11-01-dev-mode-mock-ai.md
Add comprehensive design document for rebranding project from AI-Trader
to AI-Trader-Server. Includes 4-phase approach with validation
checkpoints, naming conventions, and success criteria.
Co-Authored-By: Claude <noreply@anthropic.com>
Reorganize documentation into user-focused, developer-focused, and deployment-focused sections.
**New structure:**
- Root: README.md (streamlined), QUICK_START.md, API_REFERENCE.md
- docs/user-guide/: configuration, API usage, integrations, troubleshooting
- docs/developer/: contributing, development setup, testing, architecture
- docs/deployment/: Docker deployment, production checklist, monitoring
- docs/reference/: environment variables, MCP tools, data formats
**Changes:**
- Streamline README.md from 831 to 469 lines
- Create QUICK_START.md for 5-minute onboarding
- Create API_REFERENCE.md as single source of truth for API
- Remove 9 outdated specification docs (v0.2.0 API design)
- Remove DOCKER_API.md (content consolidated into new structure)
- Remove docs/plans/ directory with old design documents
- Update CLAUDE.md with documentation structure guide
- Remove orchestration-specific references
**Benefits:**
- Clear entry points for different audiences
- No content duplication
- Better discoverability through logical hierarchy
- All content reflects current v0.3.0 API
Add VOLUME_PATH environment variable to customize storage location for
all persistent data (data/, logs/, configs/ subdirectories).
Changes:
- .env.example: Add VOLUME_PATH variable with documentation
- docker-compose.yml: Use ${VOLUME_PATH:-.} for all volume mounts
- docs/DOCKER.md: Document custom volume location feature
Benefits:
- Store data outside project directory (e.g., on separate disk)
- Easier backup/restore (single directory)
- Clean separation of code and data
- Support for absolute or relative paths
Usage:
# In .env file
VOLUME_PATH=/home/user/trading-data
# Results in mounts:
/home/user/trading-data/data:/app/data
/home/user/trading-data/logs:/app/logs
/home/user/trading-data/configs:/app/configs
Defaults to current directory (.) if not set for backward compatibility.
Implement automatic detection of custom_config.json for simpler Docker usage.
No environment variables or command-line arguments needed for most users.
Changes:
- entrypoint.sh: Add smart config detection (custom_config.json > CLI arg > default_config.json)
- docker-compose.yml: Add configs volume mount for editing without rebuilds
- docs/DOCKER.md: Update documentation with simplified workflow
- .gitignore: Add custom_config.json to prevent accidental commits
Usage:
cp configs/default_config.json configs/custom_config.json
nano configs/custom_config.json
docker-compose up # Automatically uses custom_config.json
Simplifies user experience by following convention over configuration principle.
Complete guide for creating releases:
- Tag creation and push process
- GitHub Actions automation workflow
- Verification and testing steps
- Troubleshooting common issues
