[refactor] Semantic function clustering: version state duplication and entity helper inconsistency

[github-actions]

Overview

Semantic function clustering analysis of 668 non-test Go source files across pkg/workflow/ (322 files, 1625 functions), pkg/cli/ (237 files, 1053 functions), and pkg/parser/ (40 files, 236 functions). The codebase is generally well-organized with clear file naming conventions. Two concrete issues are worth addressing.

Analysis Metadata

• Total non-test Go files analyzed: 668
• Total functions cataloged: 2,914+
• WASM platform-specific file pairs: 22
• Genuine duplicate function definitions (non-WASM): 0
• Outlier functions (wrong file): 0 significant
• Analysis date: 2026-04-13
• Workflow run: §24341490268

---

Issue 1: Redundant workflow.SetVersion() call in main.go

Severity: Medium — latent bug risk, dual state
Files: cmd/gh-aw/main.go:858-861, pkg/cli/version.go, pkg/workflow/version.go

main.go calls both cli.SetVersionInfo(version) and workflow.SetVersion(version) sequentially, but cli.SetVersionInfo already calls workflow.SetVersion internally:

// cmd/gh-aw/main.go (lines 858-861)
cli.SetVersionInfo(version)            // this already calls workflow.SetVersion internally
workflow.SetVersion(version)           // ← redundant second call

// pkg/cli/version.go
func SetVersionInfo(v string) {
    version = v
    workflow.SetVersion(v) // Keep workflow package in sync
}
```

This dual initialization means there are **two separate version variables** (`version` in `pkg/cli` and `compilerVersion` in `pkg/workflow`) that must stay in sync manually. A caller invoking only `workflow.SetVersion()` directly would leave `cli.GetVersion()` returning `"dev"`, while callers in `main.go` going through `cli.SetVersionInfo` would see divergence if the sync code were ever removed.

**Recommendation**: Remove the redundant `workflow.SetVersion(version)` call at `main.go:861`. The single `cli.SetVersionInfo(version)` call is sufficient. Alternatively, refactor `pkg/cli` to not maintain its own `version` var and instead delegate directly to `workflow.GetVersion()`.

<details>
<summary>Current initialization flow</summary>

```
main.go
  ├── cli.SetVersionInfo(v)
  │     ├── cli.version = v        ← local var
  │     └── workflow.SetVersion(v) ← syncs workflow
  │           └── workflow.compilerVersion = v
  └── workflow.SetVersion(v)       ← REDUNDANT: already called above
        └── workflow.compilerVersion = v (set again, same value)

---

Issue 2: Inconsistent file organization for entity helpers

Severity: Low — maintainability
Files: pkg/workflow/close_entity_helpers.go, pkg/workflow/update_issue_helpers.go, pkg/workflow/update_discussion_helpers.go, pkg/workflow/update_pull_request_helpers.go

The close and update entity patterns use opposite file organization strategies:

Pattern	Organization	Files	Lines each
close-*	All variants in one file	close_entity_helpers.go (218 lines)	—
update-*	Each variant in separate file	update_issue_helpers.go	36
		update_discussion_helpers.go	45
		update_pull_request_helpers.go	41

The three update_*_helpers.go files each contain exactly one function and are very small (36–45 lines). The update_entity_helpers.go already provides the generic infrastructure (454 lines). These three tiny files add navigational overhead without meaningful separation.

Recommendation: Consolidate update_issue_helpers.go, update_discussion_helpers.go, and update_pull_request_helpers.go into update_entity_helpers.go, mirroring how close_entity_helpers.go bundles all close variants. This gives the two domains a consistent file structure.

---

Informational: WASM platform-specific file pattern

22 _wasm.go files provide WebAssembly-specific implementations of the same function signatures (e.g., github_cli.go / github_cli_wasm.go, git_helpers.go / git_helpers_wasm.go). This is an intentional architectural pattern and not a defect. Each pair covers the same function names under different build targets.

If the number of WASM pairs grows significantly, switching to build constraints within single files (//go:build !wasm and //go:build wasm) would reduce file count. No action required currently.

---

Positive Findings

• No genuine cross-file function duplicates found outside the intentional WASM pattern
• File naming is semantically consistent: *_validation.go, *_helpers.go, *_parser.go patterns are well-applied
• Utility packages (stringutil, typeutil, gitutil) are properly extracted and used by higher-level packages
• config_helpers.go parse functions serve a domain-specific config-map parsing role, distinct from pkg/parser/ which handles frontmatter and file parsing

Implementation Checklist

• Remove redundant workflow.SetVersion(version) at cmd/gh-aw/main.go:861
• (Optional) Consolidate update_issue_helpers.go, update_discussion_helpers.go, update_pull_request_helpers.go into update_entity_helpers.go
• Add or verify a test that calls only cli.SetVersionInfo() and confirms both cli.GetVersion() and workflow.GetVersion() return the same value

Generated by Semantic Function Refactoring · ● 567.4K · ◷

• expires on Apr 15, 2026, 11:51 AM UTC

[github-actions]

🍪 Issue Monster has assigned this to Copilot!

I've identified this issue as a good candidate for automated resolution and assigned it to the Copilot coding agent.

The Copilot coding agent will analyze the issue and create a pull request with the fix.

Om nom nom! 🍪

🍪 Om nom nom by Issue Monster · ● 214.8K · ◷

[copilot-swe-agent]

The agent encountered an error and was unable to start working on this issue: The service is temporarily unavailable. Please try again later. (Request id: 2040:67828:A6F6577:2B43A651:69DD020C)