[sergo] Sergo Report: MAJOR-SERENA-TOOLSET-OVERHAUL+registry-refactor+coverage-gate-position-audit - 2026-08-16

[github-actions[bot]]

Overview

Run R61 (2026-08-16) — strategy: MAJOR-SERENA-TOOLSET-OVERHAUL(23→24, LSP-native) + registry-refactor(main.go→registry.go) + DELTA-43to65(22 new linters) + coverage-gate-position-audit.

This run followed a large (~5 week / ~40 run) gap in this memory's tracking since the last recorded run (2026-07-08). Both the Serena tool surface and the linter registry structure changed materially in that gap. One new issue filed: mapclearloop coverage-gate position bug (aw_sg61a1).

Key findings

• Serena tools: 23 → 24, fully refreshed to an LSP-native set. Added find_declaration, find_implementations, get_diagnostics_for_file, open_dashboard, rename_memory, replace_in_files, safe_delete_symbol. Removed check_onboarding_performed, find_file, list_dir, and all three think_about_* reflection tools. get_diagnostics_for_file could not be used this run (go not on PATH in this sandbox → LSP unavailable) — not treated as blocking since Grep/Read covered the same ground.
• Registry moved: cmd/linters/main.go is now a thin multichecker.Main(linters.All()...) wrapper. The real source of truth is pkg/linters/registry.go (var allAnalyzers). The old detector (grep -c Analyzer main.go) is dead; the new one is grep -c '\.Analyzer,' pkg/linters/registry.go compared against doc.go's header count — both read 65 this run, in sync.
• Registry delta 43 → 65 (+22 linters) accumulated over the gap. A gh api sweep of labels=sergo issues showed nearly all of that growth already individually audited, filed, and closed by intervening runs.
• New bug found: pkg/linters/mapclearloop/mapclearloop.go:86 gates on rangeStmt.Pos() — the for-header position — instead of a position inside the loop body. Go's coverage instrumentation counts the body separately from the header, so this gate answers "was the loop entered" rather than "did the body run," defeating the stated intent of ADR-51573 for this specific linter. All 12 sibling coverage-gated linters were checked and use a correct in-body position.
• Audited clean (7 linters, unaudited since R60): mapdeletecheck, nilctxpassed, packagelevelmutableslicemap, bytesbufferstring, bytescomparestring, ioutildeprecated, logfatallibrary.
• Also noted (not filed, already fixed by others): #52309/#52566, the coverage.findProfile module-prefix path-matching bug — fix confirmed present in current coverage.go.

Detail: strategy split, evidence, and fix suggestion

Strategy split: this run leaned toward exploration (new Serena toolset, new registry structure, 22 unaudited linters) rather than reuse of a cached-proven strategy, since the underlying tooling and registry had changed enough that prior cached approaches needed re-validation first.

mapclearloop evidence (pkg/linters/mapclearloop/mapclearloop.go:86):

if !coverage.ShouldApply(pass, rangeStmt.Pos(), *hotThreshold) {
    return
}

For the codebase's standard gofmt multi-line style:

for k := range m {
    delete(m, k)
}

the for line is reached once per loop entry regardless of whether m is empty, while the body's hit count is tracked by a separate coverage block starting at delete(m, k). Suggested fix: query the hit count at rangeStmt.Body.List[0].Pos() (the body statement already validated by matchDeleteBody) instead, plus a regression test mirroring coverage_test.go's TestMultiBlockProfileLookup with distinct header/body hit counts.

Also probed and ruled out: exact-type-param vs Underlying()-match assignability bugs (the class behind the historical writebytestring bug) in bytesbufferstring/bytescomparestring/mapdeletecheck/mapclearloop — all clean, since []byte as an unnamed literal type doesn't hit the named-type assignability trap that string (a named predeclared type) does.

Deferred, lower-confidence lead (not filed): coverage.go's hitCount() is column-blind — for a query line, it matches any covered block whose [StartLine, EndLine] contains that line and returns the last such block by slice order, without checking columns. This could pick the wrong block's count on a line with multiple non-overlapping blocks (e.g. compact single-line if/else). Flagged as a next-run probe target rather than filed, since a concrete repro wasn't constructed this run.

Metrics & historical context

• Total tracked runs: 61 (was 60). Total findings: 413 (+5). Total tasks: 110 (+1). Avg success score: 8.75. This run's score: 9/10.
• Last recorded run before this one: 2026-07-08 — a ~5-week gap in this memory's run history.
• All prior sergo-labeled issues were closed prior to this run except one unrelated stale probe issue.

Next-run focus

• Re-verify the aw_sg61a1 mapclearloop fix lands (body-position fix + regression test).
• Probe coverage.go's hitCount() column-blindness with a concrete same-line multi-block repro.
• Continue sweeping the newer linters (of the 22 added since R60) not yet individually audited.
• Watch for further registry growth via the new detector: grep -c '\.Analyzer,' pkg/linters/registry.go vs doc.go header (registry.go is now canonical, not main.go).

References:

• mapclearloop bug: issue aw_sg61a1 (filed this run, see Key findings above)

Generated by 🤖 Sergo - Serena Go Expert · agent · 248.2 AIC · ⌖ 4.84 AIC · ⊞ 6.2K · ◷

• expires on Aug 16, 2026, 8:14 PM UTC-08:00