[sergo] Sergo Report: New-Linter Audit (reflectdeepequalusage) and Clean Reconcile - 2026-10-07

[github-actions[bot]]

Executive summary

Run R89. Serena tool set stable at 24 tools. The linter registry grew from 76 to 77 analyzers (reflectdeepequalusage). Reconcile of open sergo-labeled issues matched the prior run prediction exactly with zero reverse-phantom flips. One new, high-confidence, self-documented bug was found in the brand new linter and filed. Overall this was a clean, low-drama run: no reverse phantoms to refile, cached fixes held up, and the only action needed was the new-linter audit.

Tool and registry changes

• Serena: 24 tools, unchanged from the cached list (activate_project, find_symbol, search_for_pattern, and friends all reconfirmed live via serena --help).
• Linter registry: 76 to 77 analyzers (grep -c of Analyzer,$ in pkg/linters/registry.go). The 77th is reflectdeepequalusage (pkg/linters/reflect-deepequal-usage), which flags reflect.DeepEqual usage in favor of typed equality checks. Its creation issue ([linter-miner] Add reflect-deepequal-usage linter #66239) is already closed; this was its first-ever bug audit.

Strategy: 50 percent cached, 50 percent new exploration

Cached half: reconcile open sergo issues via gh api, then verify in code (not by trusting the open or closed label) whether each is still genuinely unfixed. New-exploration half: audit the newly registered 77th linter from scratch, since a brand new linter is by definition the least-covered target available this run.

Findings

Reconcile (cached). gh api state=open labels=sergo returned exactly 2 open issues: #65753 (contextcancelnotdeferred native-vs-wasm CI enforcement asymmetry) and #66009 (globwalkignorederror and strconvparseignorederror still missing bare-statement discard detection). Both match the prior run prediction exactly, with zero new reverse-phantom closures this run.

Cached-vein verification. Re-read astutil.MatchDiscardedErrorCall (astutil.go:50-79): it still accepts only *ast.AssignStmt, confirming #66009 remains fully accurate and needs no refile.

New finding (reflectdeepequalusage, first audit). The linter detects reflect.DeepEqual only when called directly as a selector expression. If the function is first assigned to a variable and invoked indirectly (r := reflect.DeepEqual; r(a, b)), astutil.PackageCall requires call.Fun to type-assert to *ast.SelectorExpr, which fails for a bare identifier, so the call is never reported. The notable part: this exact scenario is already present in the linter own positive-case test fixture (testdata/src/a/a.go, function testDeepEqualWithAlias) with a comment stating it should be flagged, but it is the only function in that file with no // want annotation, meaning the test suite has quietly encoded the false negative as expected behavior rather than catching it as a regression. No live production call sites use this aliasing pattern today, and the linter is not yet CI-enforced (doc_sync_test.go lists it under notYetEnforced pending case-by-case review of existing reflect.DeepEqual uses), so there is no immediate risk, but it is worth fixing or formally documenting as a scope limit before enforcement is turned on.

Task generated

Filed as a single GitHub issue (see below) recommending either extending analyzeCall to resolve aliased references via types info, or removing the misleading comment and fixture entry if aliasing is intentionally out of scope.

Issue created

• reflectdeepequalusage: function-value alias bypasses detection, gap documented by its own test fixture (label: sergo)

Metrics this run

• Findings: 4 (registry delta detection, reconcile match, cached-vein confirmation, new-linter bug)
• Tasks generated: 1
• Issues created: 1 (no duplicates skipped, dedup search on reflectdeepequalusage returned only the creation issue)
• Success score: 8 out of 10

Historical context

Total runs to date: 89. Average success score: 8.72. This continues a run of clean reconciles (R87, R88) where the bounded 3-run strategy memory window shows zero flips, suggesting the maintainers are keeping up with sergo-filed issues at a steady cadence. A maintenance note: the repo-memory strategies log was measured at 93160 bytes, close to the 102400-byte cap, so the oldest entry was pruned this run and a standing prune-before-append policy was adopted to keep the file size stable going forward.

Recommendations and next-run focus

• Verify the newly filed issue lands as described.
• Re-tally open issues next run; expect 3 (the 2 existing plus the new one) unless bulk-closed again.
• If the registry grows to 78, audit the new linter fresh as the top priority.
• Otherwise continue rotating a non-linter-logic cross-file sweep (doc.go, README, cgo.yml consistency), per the standing recommendation from R87.

References:

• §37568876769

Generated by 🤖 Sergo - Serena Go Expert · claude · agent · 249 AIC · ⌖ 5.47 AIC · ⊞ 5.2K · ◷

• expires on Oct 7, 2026, 8:05 PM UTC-08:00

[github-actions[bot]]

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

A newer discussion is available at Discussion #66774.