Skip to content

[refactor] Semantic function clustering: one genuine duplicate + minor re-export cleanup (codebase already well-centralized) #39468

Description

@github-actions

🔧 Semantic Function Clustering Analysis

Analysis of repository: github/gh-aw — non-test .go files under pkg/

Overview

I clustered every top-level function and method across 917 non-test Go files by name and purpose, then verified each name collision against its actual implementation (Serena + signature/impl inspection).

Headline: the codebase is already well-organized. The vast majority of same-name collisions are intentional, not duplication:

  • Build-tag _wasm.go pairs — e.g. validateDockerImage, setupGHCommand, findGitRoot, ResolveIncludePath, IsWorkflowSpec exist twice only because of //go:build js || wasm vs native variants. These are correct and must stay separate.
  • Thin delegating wrappers to shared util packagesSanitizeName (pkg/workflow/strings.gostringutil.SanitizeName) and resolveImportInputPath (pkg/parser & pkg/workflowimportinpututil.ResolvePathValue) are already centralized. Maintainers have clearly done prior consolidation passes.

So this report is deliberately short: I am reporting only what is genuinely actionable and not re-flagging already-centralized code.

Key finding

1. Genuine functional duplicate: hasCopilotRequestsWritePermission

Two independent implementations of the same predicate, in different packages:

Location Input Core logic
pkg/cli/workflow_secrets.go:116 frontmatter map[string]any parse → perms.Get(PermissionCopilotRequests) == PermissionWrite
pkg/workflow/permissions_operations.go:62 *WorkflowData (cached) perms.Get(PermissionCopilotRequests) == PermissionWrite

Both reduce to the identical check: does the resolved Permissions grant write to PermissionCopilotRequests? Only the input plumbing differs.

Recommendation: extract a method on the existing workflow.Permissions type — there is already a precedent ((*Permissions) HasContentsReadAccess() in permissions_operations.go:32):

func (p *Permissions) HasCopilotRequestsWrite() bool {
    if p == nil { return false }
    level, ok := p.Get(PermissionCopilotRequests)
    return ok && level == PermissionWrite
}

Then both call sites become one-liners:

  • workflow: ...ToPermissions().HasCopilotRequestsWrite()
  • cli: workflow.NewPermissionsParserFromValue(permissionsValue).ToPermissions().HasCopilotRequestsWrite()

Impact: single source of truth for a permission semantics check; removes drift risk between the CLI and compiler views of the same rule. Effort: ~30 min.

Minor / optional

2. Redundant package-local re-export in pkg/parser

pkg/parser/schema_suggestions.go:245 LevenshteinDistance is a pure pass-through to stringutil.LevenshteinDistance (same for FindClosestMatches at :235). Internal parser callers could call stringutil.* directly and the local aliases dropped — unless these are deliberately kept as a stable package API surface, in which case leave them. Low value; listed only for completeness.

What was checked and found clean

  • LevenshteinDistance cross-package collision (stringutil vs parser) → already a wrapper, not a real copy.
  • SanitizeName (stringutil vs workflow) → already a wrapper.
  • resolveImportInputPath, extractToolsFromFrontmatter → delegate to / differ by importinpututil; not duplicates.
  • codemod_*.go cluster (~80 files in pkg/cli) → exemplary one-feature-per-file organization. ✅
  • All _wasm.go collisions → intentional build-tag variants. ✅

Metadata

  • Files analyzed: 917 (pkg/**/*.go, excluding _test.go)
  • Same-name collisions triaged: ~45 → 1 genuine functional duplicate, ~1 optional cleanup; remainder intentional
  • Method: function/method inventory + Serena semantic inspection + implementation diffing
  • Date: 2026-06-16

References: run 27585078383

Generated by 🔧 Semantic Function Refactoring · 164.7 AIC · ⌖ 13.4 AIC · ⊞ 8.6K ·

  • expires on Jun 17, 2026, 4:23 PM UTC-08:00

Metadata

Metadata

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions