[plan] Improve Go type safety and eliminate type definition duplicates

[github-actions]

Overview

This tracking issue covers improvements to Go type safety based on a comprehensive type consistency analysis. The work focuses on eliminating duplicate type definitions, reducing reliance on map[string]any, and improving type safety throughout the codebase.

Source: Discussion #7368

Current State

Strengths:

• ✅ Zero interface{} usage (fully migrated to any)
• ✅ Excellent semantic type aliases in pkg/constants/constants.go
• ✅ Well-documented migration patterns in pkg/workflow/tools_types.go

Issues to Address:

• 🔴 2 critical type name collisions (MCPServerConfig, MCPGatewayConfig)
• ⚠️ 849 occurrences of map[string]any reducing type safety
• ⚠️ 148 occurrences of []any slice types

Planned Tasks

This work is broken into 5 focused sub-issues:

1. Fix MCPGatewayConfig naming collision (Critical) - Same type name with completely different structures
2. Consolidate MCPServerConfig definitions (High) - Two definitions of the same concept
3. Add type-safe configuration structs for workflow parsing (Medium) - Replace map[string]any in high-traffic parsing functions
4. Define WorkflowStep and WorkflowJob types (Medium) - Replace []any with proper structs
5. Document type safety patterns and guidelines (Low) - Codify best practices for future development

Success Criteria

• Zero duplicate type definitions
• All critical functions use typed structs instead of map[string]any
• Documented type safety guidelines for contributors
• All tests passing

Related

• Analysis: 🔤 Typist - Go Type Consistency Analysis #7368
• Existing patterns: pkg/constants/constants.go, pkg/workflow/tools_types.go

AI generated by Plan Command for discussion #7368