Objective

Split pkg/constants/constants.go (1,083 lines) into domain-grouped constant files to improve discoverability and adhere to the 300-line guideline.

Context

From discussion #23903 (Repository Quality: File Size Discipline). All constants are bundled regardless of domain, making navigation difficult. The type system is well-designed (semantic types with String()/IsValid() methods) — just group them by domain into separate files.

Approach

Split by domain:

1. pkg/constants/engine_constants.go — EngineName type + String()/IsValid() methods + all engine name constants (CopilotEngine, ClaudeEngine, CodexEngine, CustomEngine, etc.)
2. pkg/constants/job_constants.go — JobName and StepID types with their methods and all job name / step ID constants
3. pkg/constants/url_constants.go — URL and DocURL types with their methods and all URL constants
4. pkg/constants/version_constants.go — Version and ModelName types with their methods and all version/model name constants
5. pkg/constants/feature_constants.go — FeatureFlag type with its methods and all feature flag constants
6. Keep pkg/constants/constants.go for CommandPrefix, LineLength, WorkflowID, and any truly general constants

Rules

• Same package (package constants)
• Do NOT change type names, constant names, or method signatures
• Run make fmt after changes
• Run go test ./pkg/constants/... to validate
• Run make agent-finish before committing

Acceptance Criteria

• Each domain-focused file created with appropriate types and constants
• constants.go reduced to general constants — under 300 lines
• All files compile successfully
• All existing tests pass (go test ./pkg/constants/...)
• Each file under 300 lines

Generated by Plan Command for issue #discussion #23903 · ◷

• expires on Apr 3, 2026, 2:40 PM UTC