Refactor safe_outputs_config_generation.go into 6 focused modules using registry pattern

[Claude]

Splits 1023-line monolithic file into 6 focused modules, replacing 84+ conditional branches with a data-driven registry pattern.

Problem

safe_outputs_config_generation.go had grown to 1023 lines with repetitive conditional logic:

• generateSafeOutputsConfig(): 387 lines checking if data.SafeOutputs.X != nil 84+ times
• generateFilteredToolsJSON(): 242 lines with duplicate tool enablement checks
• Poor separation of concerns mixing config generation, tool filtering, and MCP schema building

Changes

Registry Pattern (new: safe_outputs_tool_registry.go, 400 lines)

• Defines SafeOutputToolHandler interface for tool config generation
• Maps 32 tool names to handler functions in toolRegistry
• Eliminates all 84+ conditional branches from generateSafeOutputsConfig()

// Before: 84+ conditional checks
if data.SafeOutputs.CreateIssues != nil {
    config := generateMaxWithAllowedLabelsConfig(...)
    if data.SafeOutputs.CreateIssues.Group { ... }
    safeOutputsConfig["create_issue"] = config
}
// ... repeated 84+ times

// After: registry pattern
for toolName, handler := range toolRegistry {
    if config, shouldInclude := handler(data.SafeOutputs); shouldInclude {
        safeOutputsConfig[toolName] = config
    }
}

Focused Modules

• safe_outputs_config_builder.go (256 lines): Main orchestration using registry, custom job/dispatch workflow helpers
• safe_outputs_tool_filter.go (89 lines): Tool filtering and description enhancement
• safe_outputs_tool_definitions.go (206 lines): MCP tool schema generation for custom jobs and dispatch workflows
• safe_outputs_repo_parameters.go (166 lines): Cross-repo parameter injection logic
• safe_outputs_dispatch_workflows.go (58 lines): Workflow file discovery and mapping

Public API

Unchanged. generateSafeOutputsConfig() and generateFilteredToolsJSON() maintain identical signatures and behavior.

Impact

• Maintainability: Largest file now 400 lines (registry) vs 1023 previously
• Extensibility: Adding new tools requires only registering a handler function
• Testability: Individual handlers can be unit tested in isolation

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• https://api.github.com/graphql
  • Triggering command: /usr/bin/gh /usr/bin/gh api graphql -f query=query($owner: String!, $name: String!) { repository(owner: $owner, name: $name) { hasDiscussionsEnabled } } -f owner=github -f name=gh-aw GO111MODULE 64/bin/go base64 -d GOMODCACHE go /home/REDACTED/.cargo/bin/sh heck '**/*.cjs' infocmp GO111MODULE 64/bin/go sh (http block)
  • Triggering command: /usr/bin/gh /usr/bin/gh api graphql -f query=query($owner: String!, $name: String!) { repository(owner: $owner, name: $name) { hasDiscussionsEnabled } } -f owner=github -f name=gh-aw GO111MODULE /opt/hostedtoolc-m infocmp ance�� REDACTED go 0/x64/bin/node -json GO111MODULE ndor/bin/git infocmp (http block)
• https://api.github.com/repos/actions/github-script/git/ref/tags/v8
  • Triggering command: /usr/bin/gh gh api /repos/actions/github-script/git/ref/tags/v8 --jq .object.sha /x64=/_/GOROOT HEAD u/13/cc1 rfaces_test.go .go bin/git u/13/cc1 t(AR�� p/bin/git 64/src/runtime/cgo x_amd64/vet --abbrev-ref HEAD (http block)
  • Triggering command: /usr/bin/gh gh api /repos/actions/github-script/git/ref/tags/v8 --jq .object.sha 64/src/runtime/cgo HEAD 64/pkg/tool/linux_amd64/vet home/REDACTED/.nvmbase64 (http block)
  • Triggering command: /usr/bin/gh gh api /repos/actions/github-script/git/ref/tags/v8 --jq .object.sha 64/src/runtime/cgo HEAD 64/bin/as #versions/iojs/#base64 (http block)
• https://api.github.com/repos/github/gh-aw/git/ref/tags/v1.0.0
  • Triggering command: /usr/bin/gh gh api /repos/github/gh-aw/git/ref/tags/v1.0.0 --jq .object.sha -json GO111MODULE ndor/bin/git GOINSECURE GOMOD GOMODCACHE go env -json GO111MODULE /opt/hostedtoolcache/go/1.25.0/x64/bin/go GOINSECURE GOMOD GOMODCACHE go (http block)
  • Triggering command: /usr/bin/gh gh api /repos/github/gh-aw/git/ref/tags/v1.0.0 --jq .object.sha /ref/tags/v8 go ache/node/24.13.0/x64/bin/git -json GO111MODULE 64/bin/go tail -n /ref/tags/v8 go /usr/bin/base64 -json GO111MODULE 64/bin/go base64 (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[file-diet] Refactor safe_outputs_config_generation.go (1023 lines) into focused modules</issue_title>
<issue_description>### Overview

The file pkg/workflow/safe_outputs_config_generation.go has grown to 1023 lines, making it the largest source file in the codebase and difficult to maintain and test. This task involves refactoring it into smaller, focused files with improved test coverage.

Current State

• File: pkg/workflow/safe_outputs_config_generation.go
• Size: 1023 lines
• Test Coverage: No test file found (requires comprehensive test coverage)
• Function Count: 6 primary functions
• Complexity: High - 84 conditional checks on data.SafeOutputs.* fields

Full File Analysis

Detailed Breakdown

The file contains three distinct functional domains:

1. Main Configuration Generation (lines 58-445)

• generateSafeOutputsConfig() - 387 lines
• Massive function with 84 conditional branches checking SafeOutputs fields
• Repetitive pattern: check if field exists → call helper → add to config map
• Clear candidates for extraction: each safe-output type could be a separate handler

2. Tool Definition Generation (lines 449-535)

• generateCustomJobToolDefinition() - 87 lines
• Converts SafeJobConfig into MCP tool definitions
• Self-contained logic for custom job schema generation
• Input type mapping (choice → string with enum, boolean, number, string)

3. Filtered Tools and Repo Parameter Handling (lines 539-926)

• generateFilteredToolsJSON() - 242 lines
  • Loads all tools, filters based on enabled SafeOutputs
  • Adds custom job tools (sorted for deterministic output)
  • Generates dispatch_workflow tools dynamically
  • Heavy function with multiple responsibilities
• addRepoParameterIfNeeded() - 147 lines
  • Massive switch statement handling repo parameter injection
  • Repetitive pattern for each tool type
  • Could benefit from data-driven approach

4. Dispatch Workflow Tool Generation (lines 930-1023)

• generateDispatchWorkflowTool() - 94 lines
• Converts GitHub Actions workflow_dispatch inputs to MCP tool schema
• Input type mapping similar to custom job tools

Helper Functions Already Extracted:

• safe_outputs_config_generation_helpers.go - Contains generateMaxConfig, generatePullRequestConfig, etc.
• tool_description_enhancer.go - Contains enhanceToolDescription

Complexity Hotspots

1. generateSafeOutputsConfig() (lines 58-445):

   • 84 conditional branches checking different SafeOutputs fields
   • Highly repetitive pattern that could be data-driven
   • Lines 69-340: Create/update/close operations
   • Lines 342-379: Custom jobs handling
   • Lines 381-441: Mentions and dispatch-workflow configuration

2. generateFilteredToolsJSON() (lines 539-777):

   • Multiple responsibilities: filtering, enhancing, custom jobs, dispatch workflows
   • Lines 560-656: Building enabledTools map (97 lines of repetitive checks)
   • Lines 685-707: Custom job tools generation
   • Lines 713-765: Dispatch workflow tools generation

3. addRepoParameterIfNeeded() (lines 781-926):

   • Massive switch statement with repetitive patterns
   • Each case checks config for hasAllowedRepos and targetRepoSlug
   • Lines 845-895: Nested switch for SafeOutputTargetConfig tools

Duplicate/Similar Patterns

1. Config generation pattern (repeated 30+ times):

   if data.SafeOutputs.FieldName != nil {
       safeOutputsConfig["tool_name"] = generateHelper(...)
   }

2. Tool enablement pattern (repeated 30+ times):

   if data.SafeOutputs.FieldName != nil {
       enabledTools["tool_name"] = true
   }

3. Repo parameter check pattern (repeated 15+ times):

   if config := safeOutputs.FieldName; config != nil {
       hasAllowedRepos = len(config.AllowedRepos) > 0
       targetRepoSlug = config.TargetRepoSlug
   }

Refactoring Strategy

Proposed File Splits

Based on functional domains and responsibilities, split the file into the following modules:

1. safe_outputs_config_builder.go (~200 lines)

• Purpose: Main configuration generation orchestrator
• Functions:
  • generateSafeOutputsConfig() - Refactored to use registry pattern
  • buildConfigForTool() - Helper to build config for a single tool
• Responsibility: Coordinate config generation using tool registry
• Estimated LOC: ~200 lines (simplified from current 387-line function)

2. safe_outputs_tool_registry.go (~150 lines)

• Purpose: Data-driven tool configuration registry
• Types:
  • SafeOutputToolHandler - Interface for tool config generation
  • toolRegistry - Map of tool names to handlers
• Functions:
  • registerTools() - Initialize registry with all tool handlers
  • Per-tool handler functions (small, focused)
• **Responsi...

• Fixes [file-diet] Refactor safe_outputs_config_generation.go (1023 lines) into focused modules #13499

[pelikhan]

@copilot recompile