[sergo] Sergo Report: parameter-list-systematic-scan-plus-deep-nesting - 2026-05-11

[github-actions[bot]]

Overview

Run 6 (2026-05-11) ran a two-pronged static-analysis strategy on pkg/ of github/gh-aw: a cached extension of Run 5's flagged-but-not-completed parameter-list scan, paired with a new exploration into control-flow nesting depth. Both axes turned up actionable, distinct findings that complement Run 5's function-length tracker (#31300). Three issues were filed: a 3-function options-struct cluster, a depth-11 type-assertion ladder, and a tracker covering the remaining ≥10-param functions.

Success score: 9/10 — high-coverage scan with concrete refactor targets and a survey artefact for future runs.

Summary

• Strategy: parameter-list-systematic-scan-plus-deep-nesting
• Files scanned: 770 non-test .go files in pkg/ (1897 total .go files)
• Findings: 11 functions with ≥10 positional params + 1 depth-11 nesting hot-spot
• Issues created: 3 (out of max 3)
• Status: ✅

🛠️ Serena Tools Update

Tools Snapshot

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

Tool list has been stable for 3 runs (4 through 6).

Tools Used Today

• activate_project — session setup
• get_symbols_overview — discovered the (*ClaudeEngine).parseToolCallsWithSequence symbol path in claude_logs.go
• find_symbol — confirmed body bounds 333–425 (93 lines)
• find_referencing_symbols — verified the RunUpdateWorkflows → UpdateWorkflows → updateWorkflow chain has exactly 1 prod + 2 test callers, and that the call sites really do pass 14 positional args

📊 Strategy Selection (50/50 Split)

Cached Reuse Component (50%): Systematic parameter-list scan

Run 5's stats note explicitly flagged this: "No other functions sampled exceed 15. Worth a future scan." Run 5 only enumerated DownloadWorkflowLogs (26 params) because its functioning-length scan happened to reveal it. Run 6 picked up that thread and ran a systematic scan instead of incidental sampling.

• Original success score: 9/10 (Run 5)
• What I changed: switched the angle of attack from line-count to parameter-count, but kept the same downstream verification (Serena find_referencing_symbols to gauge blast radius)
• Why it worked: the codebase had already adopted CompileConfig in pkg/cli/compile_pipeline.go — meaning the refactor target is already proven idiomatic for this codebase, not a foreign pattern

New Exploration Component (50%): Control-flow nesting depth

None of Runs 1–5 explicitly looked at nesting depth or cognitive complexity. I used a tab-prefix heuristic as a proxy for nesting depth:

• ^\t{7}if → depth 8
• ^\t{8}if → depth 9 (57 occurrences across 30 files)
• ^\t{9}if → depth 10 (rare, ~20 occurrences across ~10 files)

The depth-9 set was broad enough to be uninteresting (most are JSON-shape probing where the alternative refactor doesn't actually help). The depth-10+ set clustered tightly in 3 files and revealed the parseToolCallsWithSequence finding.

Combined Strategy Rationale

The two components are complementary: the parameter-list axis targets API shape (call-site readability), the nesting axis targets function-body shape (reader cognitive load). Neither overlaps with Run 5's line-count axis, so the three together now cover the three independent dimensions a function can be "too much": too wide, too tall, too deep.

🔍 Analysis Execution

Codebase Context

• Total Go files: 1897
• Non-test .go files in pkg/: 770
• Strategy time: ~25 min wall-clock

Findings Summary

• Critical: 0
• High: 1 (the 3-function 14-param chain — high churn cost on every flag addition)
• Medium: 2 (depth-11 nesting; remaining ≥10-param funcs tracker)
• Low: 8 documented in tracker

📋 Detailed Findings

High Priority: RunUpdateWorkflows/UpdateWorkflows/updateWorkflow trio (#31423)

Three functions, all at 14 positional parameters, all in the same call chain (cobra → RunUpdateWorkflows → UpdateWorkflows → updateWorkflow-in-loop), with arguments forwarded verbatim layer-to-layer. Test callers spell out the full 14 positional args:

RunUpdateWorkflows(context.Background(), nil, false, false, false, "", "", false, "", false, false, false, false, 0)

The CompileConfig precedent in pkg/cli/compile_pipeline.go:41,206 is the obvious model.

Medium Priority: depth-11 type-assertion ladder in parseToolCallsWithSequence (#31424)

pkg/workflow/claude_logs.go:333-425 (93-line method) reaches depth 11 in a single branch — 7 nested if x, ok := y.(T); ok casts to reach a single bash-command string. Same shape repeats in claude_tools.go and logs_metrics.go. A simple mapStringAt(m, path...) helper flattens all of them.

Medium Priority: parameter-list tracker (#31425)

Full catalog of the remaining 8 pkg/ functions with ≥10 positional params, including a recommended grouping for future refactors:

• audit cluster: AuditWorkflowRun (14), renderAuditReport (12), RunAuditDiff (12) — one AuditOptions struct covers all three
• Download* cluster: DownloadWorkflowLogsFromStdin (19) is a sister of DownloadWorkflowLogs (26, already Tracking: 14 production functions in pkg/ are >400 lines (function-length hot-spots) #31300)
• Standalone: fetchFrontmatterImportsRecursive (11, recursion amplifies the cost), writeMCPGatewayExports (13), showTrialConfirmation (11)

Methodology details

• Pattern: ^func [^(]*\([^)]*,(\s*[^)]*,){9,}[^)]*\) against pkg/**/*.go (non-test)
• Counted comma-separated parameter groups at paren depth 0
• Excluded test files (*_test.go) per Serena Go analysis guidelines
• Verified prod-caller counts with Serena find_referencing_symbols

Lower-priority observations (not issued)

• showTrialConfirmation (11 params, trial_confirmation.go:18) — interactive prompt only, likely fine until next touched
• Depth-9 nesting in 30 files (57 occurrences) — mostly JSON-shape probing where the alternative refactor doesn't simplify enough to be worth a churn
• pkg/cli/codemod_*.go files have several depth-8/9 if-cast ladders, but they read more like YAML-shape probes than business logic; deferred

✅ Improvement Tasks Generated

Task 1: Adopt UpdateWorkflowsOptions for the update-workflows trio (#31423)

• Severity: Medium-High
• Effort: Small/Medium
• Validation: existing go test ./pkg/cli/... covers — 2 test call sites become field-by-field instead of 14-positional

Task 2: Extract mapStringAt(m, path...) helper and flatten 3 sites (#31424)

• Severity: Medium
• Effort: Small
• Validation: existing pkg/workflow/claude_logs_test.go + one new fixture for missing-field case

Task 3: Track ≥10-param functions in pkg/ (#31425)

• Severity: Low/Medium
• Effort: N/A (tracker)
• Followups: audit cluster, Download* cluster, recursion-amplified fetchFrontmatterImportsRecursive

📈 Success Metrics

This Run

• Findings generated: 11 (1 chain + 1 nesting + 8 in tracker + 1 already-known sister)
• Tasks created: 3
• Files analyzed: 770 (non-test pkg)
• Success score: 9/10

Reasoning for Score

• Findings Quality (3.5/4): All 3 issues are concrete and actionable; no speculation. The trio finding has a precedent (CompileConfig) which makes adoption near-mechanical.
• Coverage (2.5/3): Systematic scan, not sampling — high confidence the catalog is complete for single-line signatures. Limitation: multi-line signatures could have been missed, though the spot-check on compile_pipeline.go showed those are mostly already adopting the options-struct pattern.
• Task Generation (3/3): Three tasks of different shapes (cluster refactor, helper extraction, tracker) — no overlap, no duplication, all distinct from previous runs.

📊 Historical Context

Cumulative Statistics

• Total runs: 6
• Total findings: 61
• Total tasks generated: 18
• Average success score: 8.3/10
• Top-tier strategies (9/10): concurrency-safety (Run 4), function-complexity (Run 5), parameter-list+nesting (Run 6)

Strategy Evolution

Runs 1–3 focused on correctness (errors, context, type safety). Runs 4–6 shifted to maintainability shape (concurrency lifecycle, function length, parameter count, nesting depth). The correctness scans have largely returned diminishing results — the codebase is well-disciplined on %w error wrapping (1704 calls, only 1 documented exception), type assertions (5 total, all comma-ok), context propagation (1 remaining, already tracked), goroutine recover (2 fixed).

The maintainability axis still has runway — Runs 5 and 6 together opened 6 tracker/refactor issues that will keep paying out as authors touch each function.

🎯 Recommendations

Immediate Actions

1. High: Land Refactor: RunUpdateWorkflows/UpdateWorkflows/updateWorkflow trio each take ~14 positional params (options-struct candidate [Content truncated due to length] #31423 — the update-workflows trio has the most callers per line and the precedent is already in the codebase
2. Medium: Land Refactor: (*ClaudeEngine).parseToolCallsWithSequence nests if x, ok := y.(T); ok 7 levels deep (depth-11 control flow) #31424 — the mapStringAt helper benefits 3 production sites and is genuinely small
3. Low/Medium: Use Tracking: 8 production functions in pkg/ take ≥10 positional parameters (parameter-list hot-spots) #31425 as a per-PR checklist when touching audit/logs code

Long-term Improvements

• Add a CI lint that fails on (a) new func declarations with >12 positional params and (b) if statements at indentation depth >6. Prevents new entrants without forcing a refactor sprint.
• Consider whether the audit cluster and the Download* cluster should share a more general RunCommandOptions shape — they have many overlapping fields.

🔄 Next Run Preview

Suggested Focus Areas (Run 7)

• New axis: import-graph / dependency-cycle analysis using find_referencing_symbols to traverse the call graph. The Run 5+6 tracking issues will accumulate evidence for which packages get touched most.
• Cached: revisit one of Runs 1–3's correctness scans with the now-stable LSP tools (Run 1's findings predated working Serena) — re-run the error-handling scan as a regression check.
• Avoid: another function-length or parameter-count scan — those are now well-catalogued.

Strategy Evolution

Now that the three function-shape dimensions (width/height/depth) are catalogued, the next natural axis is inter-function shape — call graph topology, package fan-out, cyclic dependencies. This pivots from intra-function complexity to architectural complexity.

---

Generated by Sergo - The Serena Go Expert
Run ID: 25651209481
Strategy: parameter-list-systematic-scan-plus-deep-nesting

References:

• §25651209481 — current run
• §25620196889 — Run 5 (function-length tracker Tracking: 14 production functions in pkg/ are >400 lines (function-length hot-spots) #31300)

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

• expires on May 12, 2026, 5:10 AM UTC

[github-actions[bot]]

This discussion has been marked as outdated by Sergo - Serena Go Expert.

A newer discussion is available at Discussion #31634.