🔄 Implement specific error handling with retry logic

Problem

Current error handling is too generic (index.js:111-114). All errors result in immediate process termination without distinguishing between recoverable and fatal errors.

} catch (error) {
  console.error('Error while summarizing Git changes:', error)
  process.exit(1) // ⚠️ All errors treated the same
}

Issues:

• No retry logic for transient failures (network issues, rate limits)
• All errors exit with same code (1)
• No helpful recovery suggestions
• Poor user experience for common issues

Current Behavior

• ❌ Network timeout → immediate exit
• ❌ OpenAI rate limit (429) → immediate exit
• ❌ Invalid API key → immediate exit
• ❌ Git command error → immediate exit

All errors show generic message without actionable guidance.

Proposed Solution

1. Specific Error Type Handling

} catch (error) {
  // Git not found
  if (error.code === 'ENOENT') {
    console.error('❌ Git not found. Please install git.')
    console.error('   Visit: https://git-scm.com/downloads')
    process.exit(1)
  }
  
  // OpenAI rate limit
  if (error.status === 429) {
    console.error('⏱️  OpenAI rate limit reached.')
    console.error('   Please wait a moment and try again.')
    process.exit(1)
  }
  
  // Network error
  if (error.code === 'ENOTFOUND' || error.code === 'ETIMEDOUT') {
    console.error('🌐 Network error. Check your internet connection.')
    process.exit(1)
  }
  
  // Invalid API key
  if (error.status === 401) {
    console.error('🔑 Invalid OpenAI API key.')
    console.error('   Run: git gpt open-api-key add')
    process.exit(1)
  }
  
  // Generic error with context
  console.error('❌ Unexpected error:', error.message)
  console.error('   Please report at: https://github.com/laststance/git-gpt-commit/issues')
  if (error.stack) {
    console.error('\nStack trace:', error.stack)
  }
  process.exit(1)
}

2. Retry Logic with Exponential Backoff

/**
 * Call OpenAI API with retry logic for transient failures
 * @param {Object} parameters - OpenAI API parameters
 * @param {number} maxRetries - Maximum retry attempts
 * @returns {Promise<Object>} API response
 */
async function callOpenAIWithRetry(parameters, maxRetries = 3) {
  for (let i = 0; i < maxRetries; i++) {
    try {
      return await openai.chat.completions.create(parameters)
    } catch (error) {
      const isRateLimit = error.status === 429
      const isNetworkError = ['ETIMEDOUT', 'ECONNRESET'].includes(error.code)
      const shouldRetry = (isRateLimit || isNetworkError) && i < maxRetries - 1
      
      if (shouldRetry) {
        const delay = Math.pow(2, i) * 1000 // Exponential backoff: 1s, 2s, 4s
        console.log(`⏳ ${isRateLimit ? 'Rate limited' : 'Network error'}. Retrying in ${delay}ms... (${i + 1}/${maxRetries})`)
        await new Promise(resolve => setTimeout(resolve, delay))
      } else {
        throw error
      }
    }
  }
}

3. Config File Error Recovery

function loadConfig() {
  try {
    if (fs.existsSync(CONFIG_FILE)) {
      const configContent = fs.readFileSync(CONFIG_FILE, 'utf8')
      const config = JSON.parse(configContent)
      
      // Validate config structure
      if (typeof config !== 'object') {
        throw new Error('Config file is not a valid object')
      }
      
      // Apply config with validation
      if (config.model && typeof config.model === 'string') {
        model = config.model
      }
      // ... rest of config loading
    }
  } catch (error) {
    if (error instanceof SyntaxError) {
      console.warn('⚠️  Config file is corrupted. Using defaults.')
      console.warn(`   Config location: ${CONFIG_FILE}`)
      console.warn('   Consider deleting and reconfiguring.')
    } else {
      console.error('Error loading configuration:', error.message)
    }
    // Continue with defaults
  }
}

Benefits

• ✅ Better user experience with actionable error messages
• ✅ Automatic recovery from transient failures
• ✅ Reduced frustration from rate limits
• ✅ Clearer guidance for fixing issues
• ✅ More robust error handling

Acceptance Criteria

• Implement specific error type handling for common scenarios
• Add retry logic with exponential backoff for API calls
• Improve config file error recovery
• Add helpful error messages with resolution steps
• Add tests for error scenarios
• Document error handling behavior

Priority

High - Significantly impacts user experience

Related

Quality analysis report: claudedocs/quality-analysis-report.md section 4

Start by reading the error handler at index.js:111-114, then trace the OpenAI call and config loading code referenced in the issue. Review claudedocs/quality-analysis-report.md section 4 and identify existing tests before changing behavior. Done means specific error handling, retry behavior, config recovery, actionable messages, tests, and documentation are covered.