# Mistral API Logging Changes

## Overview
Added comprehensive logging to debug and monitor Mistral API calls in the planning phase. All logs now output to container logs using `console.log()` and `console.error()` for easy debugging.

## Changes Made

### 1. Enhanced `sendMistralChat()` Function (lines 3187-3276)
Added detailed logging at every stage:

- **Request Initialization**:
  - Logs API URL, model, message count
  - Shows API key status and prefix (first 8 chars for debugging)
  
- **Response Handling**:
  - Logs HTTP status, headers, and response OK status
  - Logs detailed response structure inspection
  - Shows if choices/message/content exist in response
  - Logs content length and preview (first 200 chars)
  
- **Error Handling**:
  - Logs full error response body on HTTP errors
  - Logs fetch errors with stack traces
  - Alerts when response has no content

**Example log output:**
```
[MISTRAL] Starting API request { url: '...', model: 'mistral-large-latest', messageCount: 3 }
[MISTRAL] Response received { status: 200, ok: true }
[MISTRAL] Response data structure { hasChoices: true, choicesLength: 1, hasContent: true, contentLength: 523 }
[MISTRAL] Successfully extracted reply { replyLength: 523, replyPreview: '...' }
```

### 2. Enhanced `sendMistralPlanWithFallback()` Function (lines 3366-3410)
Added fallback chain logging:

- Logs full model chain before attempting
- Logs each model attempt
- Logs success/failure for each model
- Shows why fallback was triggered or broken
- Logs final failure with all attempts

**Example log output:**
```
[MISTRAL] Starting fallback chain { preferredModel: '', chainLength: 2, models: [...] }
[MISTRAL] Trying model: mistral-large-latest
[MISTRAL] Plan succeeded on first try { model: 'mistral-large-latest' }
```

### 3. Enhanced `handlePlanMessage()` Function (lines 3460-3593)
Added end-to-end planning logging:

- Logs plan chain configuration at start
- Logs each provider attempt
- Logs provider limits and skips
- Logs detailed Mistral result inspection
- Logs final success with reply preview
- Logs comprehensive error info with stack traces

**Example log output:**
```
[PLAN] Starting plan message handling { sessionId: '...', planChainLength: 2, providers: [...] }
[PLAN] Trying provider { provider: 'mistral', model: '' }
[PLAN] Using Mistral provider { modelHint: '', messagesCount: 3 }
[PLAN] Mistral result received { hasResult: true, hasReply: true, replyLength: 523, model: '...' }
[PLAN] Provider succeeded { provider: 'mistral', model: '...', replyLength: 523, replyPreview: '...' }
[PLAN] Plan message completed successfully { sessionId: '...', provider: 'mistral', model: '...' }
```

### 4. Bootstrap Configuration Logging (lines 6590-6615)
Added provider configuration display on server startup:

- Shows OpenRouter configuration
- Shows Mistral configuration (API key status, models, URL)
- Shows planning settings
- Helps verify environment setup

**Example output:**
```
=== PROVIDER CONFIGURATION ===
[CONFIG] OpenRouter: { configured: true, apiUrl: '...', primaryModel: '...' }
[CONFIG] Mistral: { configured: true, apiUrl: '...', primaryModel: '...', hasApiKey: true, apiKeyPrefix: 'sk_test_...' }
[CONFIG] Planning Settings: { provider: 'mistral', planningChainLength: 2, planningChain: [...] }
==============================
```

## Log Prefixes

All logs use consistent prefixes for easy filtering:

- `[MISTRAL]` - Mistral API-specific operations
- `[PLAN]` - Plan message handling
- `[CONFIG]` - Configuration at startup

## Benefits

1. **Debugging**: Full visibility into API request/response cycle
2. **Monitoring**: Easy to track provider performance
3. **Troubleshooting**: Detailed error messages with context
4. **Configuration Validation**: Startup logs verify settings
5. **Container Logs**: All output goes to stdout/stderr for Docker log collection

## Testing

To verify logging works:

1. Start the container
2. Watch logs: `docker logs -f <container_name>`
3. Send a plan message through the builder
4. You should see detailed logs for each step

## Common Issues Debuggable Now

1. **Empty responses**: Logs will show if API returns no content
2. **Wrong response format**: Structure inspection shows what fields exist
3. **API errors**: Full error body and status logged
4. **Fallback chain**: See exactly which models are tried and why they fail
5. **Configuration issues**: Startup logs show if API keys/models are set