[file-diet] File Diet: Refactor pkg/cli/add_workflow_resolution.go (1214 lines) #61354

Overview

The file pkg/cli/add_workflow_resolution.go has grown to 1214 lines, making it the largest non-test Go source file in the repository and difficult to maintain and test. This task involves refactoring it into smaller, focused files with improved test coverage.

Current State

• File: pkg/cli/add_workflow_resolution.go
• Size: 1214 lines
• Test Coverage: No dedicated add_workflow_resolution_test.go. Only two narrowly-scoped test files exist (add_workflow_resolution_manifest_ref_test.go, 50 lines; add_workflow_resolution_redirect_test.go, 143 lines) — a combined ~193 lines of tests, a ~16% test-to-source ratio.
• Complexity: Contains 5 distinct functional domains (spec parsing/orchestration, workflow spec resolution, local repository package resolution, repository package spec appending, and wildcard/content expansion) spanning ~40 functions and several private struct types, all in a single file.

Refactoring Strategy

Proposed File Splits

Based on the cluster analysis above, split the file into the following modules:

1. add_workflow_resolution.go (retained, core orchestration)

   • Functions: ResolveWorkflows, validateResolveWorkflowsInput, parseWorkflowSpecsForResolution, parseSingleWorkflowSpecForResolution, resolveLocalPackageWorkflowSpec, resolveRepositoryPackageWorkflowSpec, resolveRepositoryPackageFallback, resolveRepositoryPackageSpecs, validateCurrentRepositorySpecs, expandWorkflowSpecsIfNeeded, resolveWorkflowSpecs
   • Types: ResolvedWorkflow, ResolvedWorkflows, specResolutionResult
   • Responsibility: Top-level entry point and spec-parsing orchestration
   • Estimated LOC: ~330

2. add_workflow_resolution_spec.go

   • Functions: resolveSingleWorkflowSpec, resolvePackageOrActionWorkflow, resolveStandardWorkflow, validateManifestWorkflowPrivateSetting, selectBootstrapProfile
   • Type: resolvedWorkflowResult
   • Responsibility: Resolving a single workflow spec into fetched content and bootstrap profile
   • Estimated LOC: ~130

3. add_workflow_resolution_local_package.go

   • Functions: resolveLocalRepositoryPackage, resolveLocalPackageProjectFileAndValidateAssets, resolveLocalRepositoryPackageProjectFile, newResolvedLocalRepositoryPackage, resolveLocalRepositoryPackageManifestNodes, expandLocalPackageWildcardIncludes, localRepositoryPackageManifest, normalizeLocalPackageInstallablePaths, localPackageInstallablesFromScannedPaths, validateLocalPackageMappingSource, packageInstallableWorkflowName
   • Responsibility: Parsing and validating local repository package manifests and assets
   • Estimated LOC: ~330

4. add_workflow_resolution_local_package_files.go

   • Functions: resolveLocalPackageSkillFiles, collectLocalPackageSkillDirFiles, resolveLocalPackageAgentFiles, scanLocalPackageSkillDirs, appendLocalRepositoryPackageWorkflowSpecs
   • Responsibility: Skill/agent file discovery for local packages and appending resulting workflow specs
   • Estimated LOC: ~180

5. add_workflow_resolution_package_specs.go

   • Functions: appendRepositoryPackageWorkflowSpecs, appendRepositoryPackageExtensionSpecs
   • Responsibility: Appending resolved repository package specs (workflows and extensions) into the spec list
   • Estimated LOC: ~95

6. add_workflow_resolution_wildcard.go

   • Functions: resolveAddWorkflowSpecAndContent, expandLocalWildcardWorkflows, checkWorkflowHasDispatchFromContent, expandLocalWildcard
   • Responsibility: Fetching workflow content and expanding local wildcard workflow specs
   • Estimated LOC: ~150

Shared Utilities

No new shared-utility file is required — all helpers reference existing shared types (WorkflowSpec, RepoSpec, FetchedWorkflow, repositoryPackageManifest*) already defined elsewhere in pkg/cli. Keep those imports intact when splitting.

Interface Abstractions

• Consider introducing a small repositoryPackageResolver interface around resolveLocalRepositoryPackage/resolveRepositoryPackageSpecs to decouple local vs. remote resolution paths and simplify testing with mocks, but this is optional and can be deferred to a follow-up.

Implementation Guidelines

1. Preserve Behavior: Ensure all existing functionality works identically
2. Maintain Exports: Keep public API unchanged (ResolveWorkflows, ResolvedWorkflow, ResolvedWorkflows must stay exported from pkg/cli)
3. Add Tests First: Write tests for each new file before refactoring
4. Incremental Changes: Split one module at a time
5. Run Tests Frequently: Verify make test-unit passes after each split
6. Update Imports: Ensure all import paths are correct
7. Document Changes: Add comments explaining module boundaries

Acceptance Criteria

• Original file is split into 6 focused files
• Each new file is under 500 lines (target under 350)
• All tests pass (make test-unit)
• Test coverage is ≥80% for new files
• No breaking changes to public API
• Code passes linting (make lint)
• Build succeeds (make build)

Priority: Medium
Effort: Medium (6-way split across a well-clustered but interdependent resolution pipeline; no public API changes expected)
Expected Impact: Improved maintainability, easier testing, reduced complexity

Generated by 🧹 Daily File Diet · copilot · auto · 116.5 AIC · ⌖ 8.45 AIC · ⊞ 10.8K · ◷

• expires on Sep 18, 2026, 5:02 AM UTC-08:00