🔧 Semantic Function Clustering Analysis
Analysis of repository: github/gh-aw — package slice: pkg/types, pkg/typeutil
Executive Summary
Analyzed 6 non-test Go files across 2 packages. pkg/types is cleanly organized (one type-group per file, no outliers). pkg/typeutil has one actionable finding: convert.go mixes two distinct semantic clusters — single-value numeric conversion and keyed map extraction — and its package doc omits three of the map-extraction functions. No code duplicates were detected in this slice.
Function Inventory
pkg/types (well organized ✓)
| File |
Symbols |
Purpose |
doc.go |
package doc |
package overview |
input_definition.go |
InputDefinition, GetDefaultAsString() |
workflow input schema |
mcp.go |
BaseMCPServerConfig, MCPAuthConfig |
MCP server config |
token_weights.go |
TokenClassWeights, TokenWeights |
cost weights |
Each file has a single clear purpose. No outliers.
pkg/typeutil
| File |
Functions |
convert.go |
ParseIntValue, SafeUint64ToInt, SafeUintToInt, ConvertToInt, ConvertToFloat, ParseBool, LookupMap, LookupString, LookupStringPath |
effective_token_limits.go |
ParseInt64KMSuffix, NormalizeInt64KMSuffix |
Identified Issue
Outlier Cluster: map-extraction functions in convert.go
convert.go currently holds two semantically distinct clusters:
- Cluster A — single-value numeric conversion (the file's stated purpose per its package doc):
ParseIntValue, SafeUint64ToInt, SafeUintToInt, ConvertToInt, ConvertToFloat. These take one any and return a numeric type.
- Cluster B — keyed extraction from
map[string]any: ParseBool, LookupMap, LookupString, LookupStringPath. These take a map + key(s) and return a typed value with an ok flag. Different signature shape, different responsibility.
Two supporting signals that Cluster B is a real, separate feature group:
- The package doc is out of sync.
convert.go's doc comment (lines 1–27) documents ParseBool under "Bool Extraction" but never mentions LookupMap, LookupString, or LookupStringPath at all — they were added to the conversion file without being reflected in its stated scope.
- Callers already treat them as a "map helpers" group.
pkg/workflow/map_helpers.go:28 documents typeutil.ParseBool() as a map helper, and the Lookup* functions are consumed alongside it in pkg/cli/logs_metrics.go, pkg/workflow/claude_logs.go, and pkg/workflow/claude_tools.go.
Recommendation: Move the four map-extraction functions (ParseBool, LookupMap, LookupString, LookupStringPath) into a new pkg/typeutil/lookup.go, leaving convert.go focused on single-value numeric conversion. Split the package doc block accordingly so both files' stated scopes match their contents.
Estimated impact: Pure code-organization improvement — no signature or behavior changes, so callers and tests are unaffected. Aligns both files with the one-file-per-feature rule and fixes the doc drift. Effort: ~30 min.
Why this is not a duplicate finding
GetDefaultAsString (types) and ParseIntValue/ConvertToInt (typeutil) share a type-switch shape but serve opposite directions (format-to-string vs parse-to-int) and are correctly separated. ParseIntValue vs ConvertToInt are intentional strict-vs-lenient variants, already documented as such. No consolidation is warranted.
What Was Checked and Found Clean
pkg/types — 4 files, each a single cohesive type group. No outliers, no misplaced functions.effective_token_limits.go — Parse/Normalize K/M-suffix pair is cohesive and correctly named.- No exact, near, or functional duplicates across the slice.
Analysis Metadata
- Go files analyzed: 6 (test files excluded)
- Functions/methods cataloged: 17
- Clusters identified: 5 (types: 3; typeutil: numeric-conversion, map-extraction)
- Outliers found: 1 cluster (4 functions)
- Duplicates detected: 0
- Detection method: naming/signature pattern analysis + caller usage cross-reference
- Analysis date: 2026-08-02
Generated by 🔧 Semantic Function Refactoring · sonnet46 · 140.7 AIC · ⌖ 19.7 AIC · ⊞ 9.7K · ◷
🔧 Semantic Function Clustering Analysis
Analysis of repository: github/gh-aw — package slice:
pkg/types,pkg/typeutilExecutive Summary
Analyzed 6 non-test Go files across 2 packages.
pkg/typesis cleanly organized (one type-group per file, no outliers).pkg/typeutilhas one actionable finding:convert.gomixes two distinct semantic clusters — single-value numeric conversion and keyed map extraction — and its package doc omits three of the map-extraction functions. No code duplicates were detected in this slice.Function Inventory
pkg/types(well organized ✓)doc.goinput_definition.goInputDefinition,GetDefaultAsString()mcp.goBaseMCPServerConfig,MCPAuthConfigtoken_weights.goTokenClassWeights,TokenWeightsEach file has a single clear purpose. No outliers.
pkg/typeutilconvert.goParseIntValue,SafeUint64ToInt,SafeUintToInt,ConvertToInt,ConvertToFloat,ParseBool,LookupMap,LookupString,LookupStringPatheffective_token_limits.goParseInt64KMSuffix,NormalizeInt64KMSuffixIdentified Issue
Outlier Cluster: map-extraction functions in
convert.goconvert.gocurrently holds two semantically distinct clusters:ParseIntValue,SafeUint64ToInt,SafeUintToInt,ConvertToInt,ConvertToFloat. These take oneanyand return a numeric type.map[string]any:ParseBool,LookupMap,LookupString,LookupStringPath. These take a map + key(s) and return a typed value with anokflag. Different signature shape, different responsibility.Two supporting signals that Cluster B is a real, separate feature group:
convert.go's doc comment (lines 1–27) documentsParseBoolunder "Bool Extraction" but never mentionsLookupMap,LookupString, orLookupStringPathat all — they were added to the conversion file without being reflected in its stated scope.pkg/workflow/map_helpers.go:28documentstypeutil.ParseBool()as a map helper, and theLookup*functions are consumed alongside it inpkg/cli/logs_metrics.go,pkg/workflow/claude_logs.go, andpkg/workflow/claude_tools.go.Recommendation: Move the four map-extraction functions (
ParseBool,LookupMap,LookupString,LookupStringPath) into a newpkg/typeutil/lookup.go, leavingconvert.gofocused on single-value numeric conversion. Split the package doc block accordingly so both files' stated scopes match their contents.Estimated impact: Pure code-organization improvement — no signature or behavior changes, so callers and tests are unaffected. Aligns both files with the one-file-per-feature rule and fixes the doc drift. Effort: ~30 min.
Why this is not a duplicate finding
GetDefaultAsString(types) andParseIntValue/ConvertToInt(typeutil) share a type-switch shape but serve opposite directions (format-to-string vs parse-to-int) and are correctly separated.ParseIntValuevsConvertToIntare intentional strict-vs-lenient variants, already documented as such. No consolidation is warranted.What Was Checked and Found Clean
pkg/types— 4 files, each a single cohesive type group. No outliers, no misplaced functions.effective_token_limits.go—Parse/NormalizeK/M-suffix pair is cohesive and correctly named.Analysis Metadata