[sergo] Sergo Report: Cached-Pattern Paren-Unwrap-Gap (appendoneelement + bytesbufferstring) - 2026-11-01

[github-actions[bot]]

🔬 Sergo Report: Cached-Pattern Paren-Unwrap-Gap (appendoneelement + bytesbufferstring)

Date: 2026-11-01
Strategy: STABLE-85 (no new linter) + reconcile (3 structurally-stuck opens, zero refile) + deliver tested PR (50% cached pattern reuse / 50% new targets)
Success Score: 9/10

Executive Summary

Registry is stable at 85 analyzers (no delta since R113). All 3 open sergo-labeled issues are reconciled but structurally un-actionable as new PRs this run (two need a .github/workflows/cgo.yml edit blocked by the standing GitHub-App workflow-write restriction; one is already fixed in code with no close-issue tool available). Per this run's task mode (deliver a tested PR, not file an issue), I followed up directly on the prior run's own stated next step and shipped one PR fixing a recurring paren_unwrap_gap bug class in two more CI-enforced linters: appendoneelement and bytesbufferstring.

🛠️ Serena Tools Update

Serena tool surface is STABLE at 24 tools (serena --help exact match to the cached snapshot). activate_project + get_current_config were checked first this run (per a past-run lesson that activation success text alone doesn't prove the language server actually started) - Go language server status: ready, cleared to proceed with semantic analysis.

📊 Strategy Selection (50/50 split)

• Cached (50%): Reused the proven paren_unwrap_gap diagnosis-and-fix recipe from the immediately preceding run - a bare Go AST type assertion on an argument/operand-position expression, with no astutil.UnwrapParenExpr call, silently lets a parenthesized expression escape detection. The fix is always the same one-line wrap, reusing the exact reference pattern already merged in appendbytestring.go:74.
• New exploration (50%): The prior run's own recorded next-step note named three specific, previously-unchecked linters for this exact sub-shape: appendoneelement, stringsconcatloop, bytesbufferstring. I read all three in full rather than guessing, cross-checked each against .github/workflows/cgo.yml for CI-enforcement status, and only implemented fixes where the finding was both genuine and live in CI.

🔍 Analysis Execution

Repository context: 85 registered analyzers in pkg/linters/registry.go, Go module pinned to go1.26.9. Reconcile via gh issue list --label sergo --state open returned exactly 3 opens, matching the prior run's predicted end-state with zero reverse-phantom flips:

Issue	Status this run
readerstringconv CI-enforcement half	Still blocked - requires a cgo.yml edit; any PR touching .github/workflows/*.yml is rejected by GitHub (GitHub App lacks workflows scope)
packagelevelmutableslicemap + manualpathconcat CI-enablement	Same cgo.yml-edit blocker
manualpathconcat paren_unwrap_gap	Already genuinely fixed in code (verified by direct file read); stays open only because no close_issue safe-output tool exists in this workflow

📋 Detailed Findings

Finding 1 - pkg/linters/appendoneelement/appendoneelement.go:98 (matchSingleElementSpread)
call.Args[1].(*ast.CompositeLit) is a bare type assertion with no paren-unwrap. append(s, ([]int{2})...) is valid, compiling Go (a parenthesized composite literal immediately followed by ... is legal), and was completely invisible to the linter. CI-enforced in both the native and wasm jobs of cgo.yml; zero paren testdata coverage existed before this change.

Finding 2 - pkg/linters/bytesbufferstring/bytesbufferstring.go:107 (matchBufBytesArg)
call.Args[0].(*ast.CallExpr) is a bare type assertion with no paren-unwrap. string((buf.Bytes())) is valid, compiling Go (a parenthesized call as a conversion argument), and was completely invisible to the linter. Also CI-enforced in both jobs; also zero paren testdata coverage before this change.

Scoped out - pkg/linters/stringsconcatloop/stringsconcatloop.go
concatAssignmentLHS/selfReferentialConcatLHS have the identical shape (assign.Rhs[0].(*ast.BinaryExpr), binExpr.X.(*ast.Ident), both bare). However, a direct grep of cgo.yml confirms stringsconcatloop is not present in either job's LINTER_FLAGS - it is not CI-enforced. To keep this PR focused and avoid scope creep, this instance was deliberately left unfixed and is called out explicitly in the PR body for a future run.

✅ Improvement Tasks Generated

Task 1: Fix paren-unwrap gap in two CI-enforced perf linters

• Issue Type: Correctness (false-negative diagnostic coverage)
• Locations: pkg/linters/appendoneelement/appendoneelement.go:98, pkg/linters/bytesbufferstring/bytesbufferstring.go:107
• Impact: Both linters silently skip a valid, idiomatic-but-rare parenthesized form, meaning a real simplification opportunity goes unflagged on affected code - a correctness gap in a CI-enforced check, not just a style nit.
• Recommendation: Wrap each bare type assertion with astutil.UnwrapParenExpr, matching the already-merged reference fix in appendbytestring.go.
• Before/after intent: Before, append(s, ([]int{2})...) and string((buf.Bytes())) pass through unflagged. After, both are correctly flagged and suggested for simplification.
• Validation checklist: get_diagnostics_for_file zero-errors on both source files; get_diagnostics_for_file on both testdata files shows only pre-existing informational notices (no new errors introduced by the new parenthesized test cases); find_referencing_symbols confirms exactly one caller per modified helper, so no other code path assumed the old behavior.
• Effort: Small.

📈 Success Metrics

• Findings this run: 2 (both implemented, not just filed)
• Tasks generated: 1 (bundling both fixes, same root-cause class)
• Pull requests delivered: 1 (sergo/paren-unwrap-gap-appendoneelement-bytesbufferstring-r114)
• Duplicates skipped: 0 (searched gh pr list and gh api search/issues first - no prior coverage found for either linter)
• Success score: 9/10 - a clean, validated, CI-enforced, non-duplicate fix with explicit, honest scope boundaries (the stringsconcatloop instance was found but correctly deferred rather than papered over).

📊 Historical Context

This is the 11th+ confirmed instance of the paren_unwrap_gap pattern class across Sergo's run history (first identified around R69, most recently fixed in 4 other coverage-gated perf linters - appendbytestring, writebytestring, bytescomparestring, stringbytesroundtrip - in the immediately preceding run). The class recurs because many linters implement their own bare Go type assertion on an argument or operand position instead of routing through the shared astutil.UnwrapParenExpr helper first. Total aggregate stats across all runs: 114 runs, 613 findings, 188 tasks generated, 8.64 average success score.

🎯 Recommendations

1. A maintainer with workflow-write credentials should resolve the two cgo.yml-edit-blocked issues directly (readerstringconv CI-enforcement, packagelevelmutableslicemap/manualpathconcat CI-enablement) - these cannot be delivered as PRs from this workflow by design.
2. Consider adding a close_issue safe-output capability to this workflow; at least one open issue (manualpathconcat paren_unwrap_gap) is already fixed in code but has no mechanism to close.
3. If stringsconcatloop is ever promoted to CI-enforced status, its own paren_unwrap_gap instance (noted above) should be fixed in the same PR that enables it, not left as a follow-up.

🔄 Next Run Preview

Verify this PR actually merged via direct file content read (not PR/issue state alone, per a hard-learned lesson that PR merge status has previously been unreliable on its own in this workflow). Re-tally open issues - expect the same 3 unless a maintainer resolves the workflow-edit-blocked pair. Consider a fresh sweep of the remaining coverage-gated perf linters not yet individually checked for this exact argument-position sub-shape, since the class has now recurred across many independent implementations.

Generated by 🤖 Sergo - Serena Go Expert · claude · agent · ~204 AIC · ⌖ ~1 AIC · ⊞ 4.3K · ◷

• expires on Nov 1, 2026, 7:55 PM UTC-08:00