**Root Cause:**
The summarizer was not receiving tool execution results (buy/sell trades)
because they were never captured to conversation_history.
**What was captured:**
- User: 'Please analyze positions'
- Assistant: 'I will buy/sell...'
- Assistant: 'Done <FINISH_SIGNAL>'
**What was MISSING:**
- Tool: buy 14 NVDA at $185.24
- Tool: sell 1 GOOGL at $245.15
**Changes:**
- Added tool message capture in trading loop (line 649)
- Extract tool_name and tool_content from each tool message
- Capture to conversation_history before processing
- Changed message['tool_name'] to message['name'] for consistency
**Impact:**
Now the summarizer sees the actual tool results, not just the AI's
intentions. Combined with alpha.8's prompt improvements, summaries
will accurately reflect executed trades.
Fixes reasoning summaries that contradicted actual trades.
**Problem:**
Final positions showed empty holdings despite executing 15+ trades.
The issue persisted even after fixing the get_current_position_from_db query.
**Root Cause:**
At end of trading day, base_agent.py line 672 called
_get_current_portfolio_state() which queried the database for current
position. On the FIRST trading day, this query returns empty holdings
because there's no previous day's record.
**Why the Previous Fix Wasn't Enough:**
The previous fix (date < instead of date <=) correctly retrieves
STARTING position for subsequent days, but didn't address END-OF-DAY
position calculation, which needs to account for trades executed
during the current session.
**Solution:**
Added new method _calculate_final_position_from_actions() that:
1. Gets starting holdings from previous day (via get_starting_holdings)
2. Gets all actions from actions table for current trading day
3. Applies each buy/sell to calculate final state:
- Buy: holdings[symbol] += qty, cash -= qty * price
- Sell: holdings[symbol] -= qty, cash += qty * price
4. Returns accurate final holdings and cash
**Impact:**
- First trading day: Correctly saves all executed trades as final holdings
- Subsequent days: Final position reflects all trades from that day
- Holdings now persist correctly across all trading days
**Tests:**
- test_calculate_final_position_first_day_with_trades: 15 trades on first day
- test_calculate_final_position_with_previous_holdings: Multi-day scenario
- test_calculate_final_position_no_trades: No-trade edge case
All tests pass ✅
Changes:
- Update context_injector.trading_day_id after trading_day record is created
Root Cause:
- ContextInjector was created before trading_day record existed
- trading_day_id was None when context_injector was initialized
- Even though trading_day_id was written to runtime config, the
context_injector's attribute was never updated
- MCP tools use the injected trading_day_id parameter, not runtime config
Flow:
1. ModelDayExecutor creates ContextInjector (trading_day_id=None)
2. Agent.run_trading_session() creates trading_day record
3. NEW: Update context_injector.trading_day_id = trading_day_id
4. MCP tools receive trading_day_id via context injection
Impact:
- Fixes: "Trade failed: trading_day_id not found in runtime config"
- Trading tools (buy/sell) can now record actions properly
- Actions are linked to correct trading_day record
Related: agent/base_agent/base_agent.py:541-543
Changes:
- Update get_today_init_position_from_db to query trading_days table
- Remove obsolete add_no_trade_record_to_db calls from BaseAgent
- Simplify _handle_trading_result (trading_day record handles both scenarios)
Root Cause:
- Code was still querying old positions table after schema migration
- The add_no_trade_record_to_db function is obsolete in new schema
New Schema Behavior:
- trading_day record created at session start (regardless of trading)
- trading_day record updated at session end with final results
- No separate "no-trade" record needed
Impact:
- Fixes: "no such table: positions" error in get_today_init_position_from_db
- Removes unnecessary database writes for no-trade scenarios
- Simplifies codebase by removing obsolete function calls
Related: tools/price_tools.py:340-364, agent/base_agent/base_agent.py:661-673
Changes:
- Write TRADING_DAY_ID to runtime config after creating trading_day record in BaseAgent
- Fix datetime deprecation warnings by replacing datetime.utcnow() with datetime.now(timezone.utc)
- Add test for trading_day_id=None fallback path to verify runtime config lookup works correctly
This ensures trade tools can access trading_day_id from runtime config when not explicitly passed.
Critical fixes:
1. Fixed api/database.py import - use get_db_path() instead of non-existent get_database_path()
2. Fixed state management - use database queries instead of reading from position.jsonl file
3. Fixed action counting - track during trading loop execution instead of retroactively from conversation history
4. Completed integration test to verify P&L calculation works correctly
Changes:
- agent/base_agent/base_agent.py:
* Updated _get_current_portfolio_state() to query database via get_current_position_from_db()
* Added today_date and job_id parameters to method signature
* Count trade actions during trading loop instead of post-processing conversation history
* Removed obsolete action counting logic
- api/database.py:
* Fixed import to use get_db_path() from deployment_config
* Pass correct default database path "data/trading.db"
- tests/integration/test_agent_pnl_integration.py:
* Added proper mocks for dev mode and MCP client
* Mocked get_current_position_from_db to return test data
* Added comprehensive assertions to verify trading_day record fields
* Test now actually validates P&L calculation integration
Test results:
- All unit tests passing (252 passed)
- All P&L integration tests passing (8 passed)
- No regressions detected
This implements Task 5 from the daily P&L results API refactor plan, bringing
together P&L calculation and reasoning summary into the BaseAgent trading session.
Changes:
- Add DailyPnLCalculator and ReasoningSummarizer to BaseAgent.__init__
- Modify run_trading_session() to:
* Calculate P&L at start of day using current market prices
* Create trading_day record with P&L metrics
* Generate reasoning summary after trading using AI model
* Save final holdings to database
* Update trading_day with completion data (cash, portfolio value, summary, actions)
- Add helper methods:
* _get_current_prices() - Get market prices for P&L calculation
* _get_current_portfolio_state() - Read current state from position.jsonl
* _calculate_portfolio_value() - Calculate total portfolio value
Integration test verifies:
- P&L calculation components exist and are importable
- DailyPnLCalculator correctly calculates zero P&L on first day
- ReasoningSummarizer can be instantiated with AI model
This maintains backward compatibility with position.jsonl while adding
comprehensive database tracking for the new results API.
Generated with Claude Code
Co-Authored-By: Claude <noreply@anthropic.com>
Add instrumentation at component boundaries to trace where ContextInjector values become None:
- ModelDayExecutor: Log ContextInjector creation and set_context() invocation
- BaseAgent.set_context(): Log entry, client creation, tool reload, completion
- Includes object IDs to verify instance identity across boundaries
Part of systematic debugging investigation for issue #TBD.
Critical fixes for ContextInjector and database concurrency:
1. ContextInjector Not Working:
- Made set_context() async to reload tools after recreating MCP client
- Tools from old client (without interceptor) were still being used
- Now tools are reloaded from new client with interceptor active
- This ensures buy/sell calls properly receive injected parameters
2. Database Locking:
- Closed main connection before _write_results_to_db() opens new one
- SQLite doesn't handle concurrent write connections well
- Prevents "database is locked" error during position writes
Changes:
- agent/base_agent/base_agent.py:
- async def set_context() instead of def set_context()
- Added: self.tools = await self.client.get_tools()
- api/model_day_executor.py:
- await agent.set_context(context_injector)
- conn.close() before _write_results_to_db()
Root Cause:
When recreating the MCP client with tool_interceptors, the old tools
were still cached in self.tools and being passed to the AI agent.
The interceptor was never invoked, so job_id/signature/date were missing.
This commit migrates the system to database-only position storage,
eliminating file-based position.jsonl dependencies and fixing
ContextInjector initialization timing issues.
Key Changes:
1. ContextInjector Lifecycle Refactor:
- Remove ContextInjector creation from BaseAgent.__init__()
- Add BaseAgent.set_context() method for post-initialization injection
- Update ModelDayExecutor to create ContextInjector with correct trading day date
- Ensures ContextInjector receives actual trading date instead of init_date
- Includes session_id injection for proper database linking
2. Database Position Functions:
- Implement get_today_init_position_from_db() for querying previous positions
- Implement add_no_trade_record_to_db() for no-trade day handling
- Both functions query SQLite directly (positions + holdings tables)
- Handle first trading day case with initial cash return
- Include comprehensive error handling and logging
3. System Integration:
- Update get_agent_system_prompt() to use database queries
- Update _handle_trading_result() to write no-trade records to database
- Remove dependencies on position.jsonl file reading/writing
- Use deployment_config for automatic prod/dev database resolution
Data Flow:
- ModelDayExecutor creates runtime config and trading session
- Agent initialized without context
- ContextInjector created with (signature, date, job_id, session_id)
- Context injected via set_context()
- System prompt queries database for yesterday's position
- Trade tools write directly to database
- No-trade handler creates database records
Fixes:
- ContextInjector no longer receives None values
- No FileNotFoundError for missing position.jsonl files
- Database is single source of truth for position tracking
- Session linking maintained across all position records
Design: docs/plans/2025-02-11-database-position-tracking-design.md
Complete rewrite of position management in MCP trade tools:
**Trade Tools (agent_tools/tool_trade.py)**
- Replace file-based position.jsonl reads with SQLite queries
- Add get_current_position_from_db() to query positions and holdings tables
- Rewrite buy() and sell() to write directly to database
- Calculate portfolio value and P&L metrics in tools
- Accept job_id and session_id parameters via ContextInjector
- Return errors with proper context for debugging
- Use deployment-aware database path resolution
**Context Injection (agent/context_injector.py)**
- Add job_id and session_id to constructor
- Inject job_id and session_id into buy/sell tool calls
- Support optional parameters (None in standalone mode)
**BaseAgent (agent/base_agent/base_agent.py)**
- Read JOB_ID from runtime config
- Pass job_id to ContextInjector during initialization
- Enable automatic context injection for API mode
**ModelDayExecutor (api/model_day_executor.py)**
- Add _initialize_starting_position() method
- Create initial position record before agent runs
- Load initial_cash from config
- Update context_injector.session_id after session creation
- Link positions to sessions automatically
**Architecture Changes:**
- Eliminates file-based position tracking entirely
- Single source of truth: SQLite database
- Positions automatically linked to trading sessions
- Concurrent execution safe (no file system conflicts)
- Deployment mode aware (prod vs dev databases)
This completes the migration to database-only position storage.
File-based position.jsonl is no longer used or created.
Fixes context injection errors in concurrent simulations.
Resolves issue where MCP trade tools couldn't access SIGNATURE and TODAY_DATE
during concurrent API simulations, causing "SIGNATURE environment variable is
not set" errors.
Problem:
- MCP services run as separate HTTP processes
- Multiple simulations execute concurrently via ThreadPoolExecutor
- Environment variables from executor process not accessible to MCP services
Solution:
- Add ContextInjector that implements ToolCallInterceptor
- Automatically injects signature and today_date into buy/sell tool calls
- Trade tools accept optional parameters, falling back to config/env
- BaseAgent creates interceptor and updates today_date per session
Changes:
- agent/context_injector.py: New interceptor for context injection
- agent/base_agent/base_agent.py: Create and use ContextInjector
- agent_tools/tool_trade.py: Add optional signature/today_date parameters
Benefits:
- Supports concurrent multi-model simulations
- Maintains backward compatibility with CLI mode
- AI model unaware of injected parameters
- Remove _log_message() and _setup_logging() methods
- Remove all calls to logging methods in run_trading_session()
- Update log_path parameter docstring for clarity
- Update integration test to verify conversation history instead of JSONL files
- Reasoning logs now stored exclusively in database via model_day_executor
- Conversation history tracking preserved in memory
Related: Task 6 of reasoning logs API feature
- Add conversation_history instance variable to BaseAgent.__init__
- Create _capture_message() method to capture messages with timestamps
- Create get_conversation_history() method to retrieve conversation
- Create clear_conversation_history() method to reset history
- Modify run_trading_session() to capture user prompts and AI responses
- Add comprehensive unit tests for conversation tracking
- Fix datetime deprecation warning by using timezone-aware datetime
All tests pass successfully.
