[sergo] Sergo Report: function-complexity-and-long-function-hot-spots — 2026-05-10

[github-actions[bot]]

Executive Summary

Run 5 of Sergo (2026-05-10) ran a function-complexity scan across all 766 non-test .go files in pkg/, enumerating every function declaration by line count. The scan identified 17 functions over 400 lines, of which two are clear refactor targets: (*Compiler).extractSafeOutputsConfig (637 lines, 45 repeated parse-and-assign blocks) and DownloadWorkflowLogs (508 lines + 26 positional parameters).

Three GitHub issues were created — two concrete refactors and one tracking issue surveying the remaining 12 long functions with refactor-potential annotations. Self-assessed success score: 9/10.

Server-side LSP (Serena) was used to confirm body locations on the top two findings (body_location: {start_line: 54, end_line: 690} and {38, 546}) and to enumerate callers of the second (find_referencing_symbols returned 1 production caller + 7 test callers, validating the options-struct case quantitatively).

🛠️ Serena Tools Update

Tools Snapshot

• Total Tools Available: 23
• New Tools Since Last Run: None
• Removed Tools: None
• Modified Tools: None

Tool Capabilities Used Today

• activate_project — activate the Go workspace (one-shot at start)
• get_symbols_overview — discover the qualified (*Compiler).extractSafeOutputsConfig form when the bare name returned []
• find_symbol — confirm body locations of extractSafeOutputsConfig (54–690) and DownloadWorkflowLogs (38–546)
• find_referencing_symbols — count callers of DownloadWorkflowLogs (8 total, 1 prod + 7 test)

LSP observation worth caching

find_symbol with a bare receiver-method name like extractSafeOutputsConfig returns an empty list — the qualified form (*Compiler).extractSafeOutputsConfig (the Go pointer-receiver name path) is required. get_symbols_overview is the easy way to discover that form. Saved to sergo-stats.json for future runs.

📊 Strategy Selection

Cached Reuse Component (50%)

Theme adapted: Maintainability/consistency analysis from Runs 1–4.

• Run 1 (score 7): error-handling-and-interface-design
• Run 2 (score 8): symbol-naming + redundant fields
• Run 3 (score 8): constructor consistency, type-safety
• Run 4 (score 9): concurrency safety, resource lifecycle

The common thread across all four runs is code-shape consistency: each run targeted a different axis (errors → naming → constructors → concurrency) but the underlying question is always "is this function/structure pulling its weight, and is it consistent with siblings?" Today's run extends that thread to function shape itself — length and parameter-list size.

New Exploration Component (50%)

Novel approach: A whole-pkg/ function-length enumeration. Past runs zoomed into specific patterns (panics, goroutines, type assertions); this is the first run to ask "sort all 3782 non-test functions by size and look at the head of the distribution." Implementation was a small awk script that emits <lines> <file>:<start> <name> for every ^func declaration, sorted descending. Top 50 inspected, top 17 (>400 lines) flagged.

Combined Strategy Rationale

The cached half ensures the analysis stays in the proven territory of code-shape findings (where Sergo has scored 7–9). The new half changes the unit of analysis from "specific anti-pattern" to "distribution of function sizes" — this is naturally complementary because long functions are the substrate where most code-shape issues compound.

Hypothesis going in: we'll find 3–5 functions of >500 lines, at least one of which has a clear table-driven shape. Hypothesis confirmed: 5 functions over 500 lines, and extractSafeOutputsConfig is a near-perfect table-driven candidate (45 repeated blocks).

🔍 Analysis Execution

Codebase Context

• Total non-test Go files in pkg/: 766
• Total non-test functions in pkg/: 3,782
• Non-test LOC in pkg/: 181,907
• Focus areas: cross-cutting (every package was sampled by the function-length scan)

Findings Summary

• Total Issues Found: 17 (functions >400 lines), plus 1 systemic finding (26-param signature on DownloadWorkflowLogs)
• Critical: 0
• High: 0
• Medium: 2 (issued separately)
• Low: 15 (covered by the tracking issue)

📋 Detailed Findings

Medium Priority — Refactor Targets (issued)

1. (*Compiler).extractSafeOutputsConfig — 637 lines, 45 repeated parse-and-assign blocks

• Location: pkg/workflow/safe_outputs_config.go:54–690
• LSP confirmed: body_location: {start_line: 54, end_line: 690}
• Pattern: 45 invocations of the form xConfig := c.parseXConfig(outputMap); if xConfig != nil { config.Y = xConfig } (verified grep -c 'c\.parse\w*Config(outputMap)' = 45)
• Recommendation: table-driven registry of {parse, assign} pairs
• Issue: created via safeoutputs (#aw_sg5fn1)

2. DownloadWorkflowLogs — 508 lines + 26 positional parameters

• Location: pkg/cli/logs_orchestrator.go:38–546
• LSP confirmed: body_location: {start_line: 38, end_line: 546}
• Callers (LSP): 1 production (NewLogsCommand at logs_command.go:245) + 7 test
• Each test call spells all 26 args by position — example from context_cancellation_test.go:73:

  err := DownloadWorkflowLogs(ctx, "", 10, "", "", "/tmp/test-logs", "", "", 0, 0, "",
      false, false, false, false, false, false, false, 0, "", "", false, false, "", nil, "")
  

• Recommendation: introduce LogsDownloadOptions struct
• Issue: created via safeoutputs (#aw_sg5fn2)

Low Priority — Tracked

3. Survey of remaining 12 functions over 400 lines

• Issue: created via safeoutputs (#aw_sg5fn3)
• Categorized by refactor potential into:
  • Highest-leverage targets: extractRepoMemoryConfig (400, same shape as rejig docs #1), extractAllImportFields (490), GetExecutionSteps triplet (478/373/287, sister functions with shared shape)
  • Likely best left alone: YAML emitters (buildMaintenanceWorkflowYAML 822, buildConclusionJob 607, buildPreActivationJob 480, generateSideRepoMaintenanceWorkflow 428)

Full top-50 function-length output

822 pkg/workflow/maintenance_workflow_yaml.go:15 buildMaintenanceWorkflowYAML
642 pkg/workflow/safe_outputs_config.go:55 (c *Compiler) extractSafeOutputsConfig
607 pkg/workflow/notify_comment.go:27 (c *Compiler) buildConclusionJob
554 pkg/workflow/frontmatter_extraction_yaml.go:107 (c *Compiler) commentOutProcessedFieldsInOnSection
513 pkg/cli/logs_orchestrator.go:39 DownloadWorkflowLogs
507 pkg/workflow/mcp_config_custom.go:53 renderSharedMCPConfig
499 pkg/parser/import_bfs.go:20 processImportsFromFrontmatterWithManifestAndSource
490 pkg/parser/import_field_extractor.go:96 (acc *importAccumulator) extractAllImportFields
480 pkg/workflow/compiler_pre_activation_job.go:20 (c *Compiler) buildPreActivationJob
478 pkg/workflow/copilot_engine_execution.go:42 (e *CopilotEngine) GetExecutionSteps
443 pkg/parser/schedule_fuzzy_scatter.go:184 ScatterSchedule
442 pkg/cli/run_workflow_execution.go:56 RunWorkflowOnGitHub
428 pkg/workflow/side_repo_maintenance.go:148 generateSideRepoMaintenanceWorkflow
418 pkg/cli/audit.go:244 AuditWorkflowRun
411 pkg/cli/logs_run_processor.go:31 downloadRunArtifactsConcurrent
400 pkg/workflow/repo_memory.go:75 (c *Compiler) extractRepoMemoryConfig
392 pkg/workflow/tool_description_enhancer.go:39 enhanceToolDescription
373 pkg/workflow/claude_engine.go:119 (e *ClaudeEngine) GetExecutionSteps
373 pkg/workflow/compiler_orchestrator_engine.go:34 (c *Compiler) setupEngineAndImports
353 pkg/workflow/compiler_jobs.go:513 (c *Compiler) buildCustomJobs
344 pkg/workflow/tools.go:20 (c *Compiler) applyDefaults
335 pkg/workflow/compiler_main_job.go:26 (c *Compiler) buildMainJob
320 pkg/workflow/compiler_orchestrator_tools.go:48 (c *Compiler) processToolsAndMarkdown
311 pkg/workflow/claude_tools.go:165 (e *ClaudeEngine) computeAllowedClaudeToolsString
309 pkg/cli/logs_download.go:634 downloadRunArtifacts
307 pkg/cli/logs_orchestrator.go:635 DownloadWorkflowLogsFromStdin
302 pkg/cli/logs_command.go:29 NewLogsCommand
301 pkg/workflow/engine.go:144 (c *Compiler) ExtractEngineConfig
292 pkg/workflow/compiler_orchestrator_workflow.go:15 (c *Compiler) ParseWorkflowFile
287 pkg/workflow/codex_engine.go:146 (e *CodexEngine) GetExecutionSteps

Side findings ruled out (saved as cache stats)

• Error-wrapping scan: of 1704 fmt.Errorf calls in pkg/, only 1 documented exception uses %v with err (compiler_orchestrator_frontmatter.go:41 with //nolint:errorlint and an explanatory comment). %w wrapping is consistent. NOT issue-worthy.
• Panic scan: 16 panic() calls in pkg/ non-test. All examined are legitimate (init-time embed-load, BUG: programmer-error guards, crypto/rand failure). NOT issue-worthy.
• os.Exit scan: 2 calls in pkg/, both in pkg/cli/upgrade_command.go — appropriate for CLI commands. NOT issue-worthy.

These rule-outs are intentionally documented in sergo-stats.json so future runs don't re-investigate.

✅ Improvement Tasks Generated

Task 1: Refactor extractSafeOutputsConfig to a table-driven handler registry

Severity: Medium · Effort: Medium · Issue: #aw_sg5fn1

Problem: 637-line function with 45 nearly-identical parse-and-assign blocks; new safe-output handlers must be added in this giant if block, and a wrong-field assignment (e.g. assigning to .UploadAsset vs .UploadAssets) compiles silently.

Validation:

• Verify all 45 invocations follow one of the 2 documented shapes
• Run go test ./pkg/workflow/...
• Diff against ≥10-handler fixture frontmatter for parity
• Confirm field-plurality differences are intentional

Task 2: Introduce LogsDownloadOptions struct for DownloadWorkflowLogs

Severity: Medium · Effort: Small · Issue: #aw_sg5fn2

Problem: 26-parameter positional signature; 7 test callers each enumerate every argument including filler zeros; adding any flag requires editing every callsite.

Validation:

• Migrate 1 production + 7 test callers (Serena confirmed exactly 8)
• Run go test ./pkg/cli/...
• Field-by-field check that false/""/0 defaults survive

Task 3: Track remaining 12 long functions and pick high-leverage extraction targets

Severity: Low · Effort: N/A (tracking) · Issue: #aw_sg5fn3

Recommendation: when convenient, knock off extractRepoMemoryConfig (same fix as Task 1), extractAllImportFields (table-driven), and the GetExecutionSteps triplet (shared helper). Add a CI line-count gate to keep the list from growing.

📈 Success Metrics

This Run

• Findings Generated: 17 (functions >400 lines) + 1 systemic (26-param signature)
• Tasks Created: 3
• Files Analyzed: 766 (full pkg/ non-test sweep)
• Success Score: 9/10

Reasoning for Score

• Findings Quality (4/4): two concrete refactors with quantitative evidence (45 repeated blocks; 26 parameters; 8 callsites enumerated by LSP), plus a survey that gives the next 12 sub-issues their priority order.
• Coverage (3/3): every non-test function in pkg/ was measured; rule-outs (panics, error wrapping, os.Exit) were also documented to prevent re-investigation.
• Task Generation (2/3): 3 tasks generated. Task 3 is a tracker, not a fully scoped task — that's why this isn't a 10/10. A perfect run would have promoted one or two of the tracker entries (e.g. extractRepoMemoryConfig) into a fourth concrete task; the 3-issue cap prevented that.

Issue duplication check

Attempted gh issue list --search ... for extractSafeOutputsConfig, DownloadWorkflowLogs, and the sergo label — all calls returned HTTP 403 from the sandbox firewall ((localhost/redacted)). Duplication could not be programmatically verified. Past Sergo run topics (concurrency, constructors, type-safety, error handling) are clearly distinct from today's function-length theme, so a duplicate is unlikely. Issues do carry the expires: 7d configured policy and are expected to auto-close if not actioned.

📊 Historical Context

Strategy Performance

Run	Date	Strategy	Score
1	2026-05-06	error-handling-and-interface-design	7
2	2026-05-07	deep-error-analysis-plus-symbol-naming	8
3	2026-05-08	constructor-consistency-plus-type-safety	8
4	2026-05-09	concurrency-safety-and-resource-lifecycle	9
5	2026-05-10	function-complexity-and-long-function-hot-spots	9

Scores are trending upward as the strategies move from "specific anti-pattern hunt" to "systematic enumeration with rule-outs" — both Run 4 and Run 5 took the form "inventory the entire population, then issue on the outliers" (goroutines for Run 4, function lengths for Run 5).

Cumulative Statistics

• Total Runs: 5
• Total Findings: 50
• Total Tasks Generated: 15
• Average Success Score: 8.2/10
• Most Successful Strategy (tied): Run 4 concurrency-safety and Run 5 function-complexity, both 9/10

🎯 Recommendations

Immediate Actions

1. #aw_sg5fn1 — Refactor extractSafeOutputsConfig (highest leverage; same fix mechanically extends to extractRepoMemoryConfig)
2. #aw_sg5fn2 — Options-struct refactor of DownloadWorkflowLogs (smallest effort, biggest readability win)
3. #aw_sg5fn3 — Pick one or two from the tracker when touching adjacent code

Long-term Improvements

• CI line-count gate: a simple lint that fails when a new (or modified) function exceeds, say, 400 lines would prevent the long-function distribution from growing further. Could be done as a workflow that runs the same awk algorithm used here and diffs against main.
• Parameter-count gate: same idea for parameter lists >10. DownloadWorkflowLogs at 26 is an outlier today; a soft cap would have caught it before it reached 26.

🔄 Next Run Preview

Suggested Focus Areas

• Cyclomatic-complexity hot-spots (orthogonal to length — short functions can still be deeply branched)
• Public API surface health: exported functions/types in pkg/ missing godoc comments
• Loop-variable capture in goroutines/closures (Go 1.22 changed semantics; verify no remaining for i := range ... { go func() { _ = i }() } patterns relying on old behaviour)
• interface{} vs any consistency sweep

Strategy Evolution

The "enumerate the population, rule out the boring, issue on the outliers" pattern (Runs 4 + 5) is scoring well. Continue using it. Avoid the temptation to revisit panics/error-wrapping — those have been ruled out and the rule-outs are now cached. Prefer underexplored axes: API surface, loop-capture, type-erasure (any).

---

Generated by Sergo — The Serena Go Expert
Run ID: §25620196889
Strategy: function-complexity-and-long-function-hot-spots

Generated by Sergo - Serena Go Expert · ● 77.2M · ◷

• expires on May 11, 2026, 5:21 AM UTC

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-05-11T05:21:38.654Z.

Closed by Workflow