[sergo] Sergo Report 2026-08-06: Registry Restructure and Cache Catchup Audit

[github-actions[bot]]

Sergo Report: Cache-Catchup + Registry-Restructure Audit — 2026-08-06

Run: §31072155278 · Strategy: CACHE-CATCHUP-registry-restructure-audit+newexplore-goroutinemissingrecover-defer-target-semantics

Executive summary

Serena's LSP toolset is unchanged (23 tools). The linter registry itself was restructured: cmd/linters/main.go no longer inlines the analyzer list — it's now multichecker.Main(linters.All()...), with the canonical list moved to a new pkg/linters/registry.go. The registered-analyzer count jumped from 43 → 63 (+20) since the last locally cached run.

My local strategy cache (sergo-strategies.jsonl) had a gap: its last entry was R60 (2026-07-08), but gh api reconciliation shows sergo issues closing continuously through at least 2026-08-03 — roughly 26+ runs happened without their strategy/stats getting persisted back to this memory branch (likely a prior run exceeding the 10KB memory-patch budget). Zero sergo issues were open at the start of this run; the whole known bug-class surface (enforce-readiness, doc-sync, autofix import-robustness) has clearly been iterated many times already. I've caught the cache up and flagged the likely root cause for next time.

Tool / registry changes

Item	Before (R60)	Now (R61)
Registry location	inline in cmd/linters/main.go	pkg/linters/registry.go → All()
Analyzer count	43	63 (+20)
doc.go sync	—	"63 active analyzers" — matches, clean

New linters since R60: appendoneelement, bytesbufferstring, bytescomparestring, goroutinemissingrecover, hardcodedfilepath, ioutildeprecated, logfatallibrary, mapclearloop, mapdeletecheck, nilctxpassed, regexpdynamicpattern, sprintfbool, stringbytesroundtrip, stringsconcatloop, stringscountcontains, stringsindexhasprefix, stringsjoinone, timenowsub, trimleftright, uncheckedflushreturn, walkfuncerrshadow.

Strategy split (50/50)

• Cached (reconciliation sweep): re-ran every known bug-class check — nolint.Index/filecheck.Index wiring, syntactic stdlib-package matching, SuggestedFix import-robustness — across all 63 linters plus the shared internal/{astutil,analyzerutil,nolint,filecheck} helpers. Result: all clean. Confirmed the R60 writebytestring compile-safety fixes (isExactString wrap, io auto-import) landed and hold in current code.
• New exploration: since every new linter already had at least one closed enforce-readiness/correctness issue from the runs I'd lost track of, I went one level deeper — auditing the semantic correctness of a newer linter's own core logic against the Go spec, rather than the usual wiring/doc checks.

Findings

1 confirmed, filed issue (click to expand)

goroutinemissingrecover: defer of a named recover-helper is misreported as "missing recover"

hasTopLevelRecoverDefer (goroutinemissingrecover.go:92-111) only accepts a deferred call whose target is an *ast.FuncLit. Per the Go spec, recover() stops a panic whenever it's "called directly by a deferred function" — a named function (or method) that is itself the defer target and calls recover() in its own body is equally valid:

func recoverAndLog() {
    if r := recover(); r != nil { log.Printf("recovered: %v", r) }
}
go func() {
    defer recoverAndLog() // valid — but flagged as "missing recover"
    risky()
}()

The linter's own doc/testdata already accept "a named function can install its own recovery" as a reason to trust code for the goroutine-launch case (go f() is out of scope) — the same principle just isn't applied to the defer target inside a literal-launched goroutine, so the implementation is inconsistent with its own design intent.

• Impact today: latent — a repo-wide grep of every production recover() site (pkg/cli, pkg/console, pkg/workflow) shows all current usage is the inline literal form, so zero live false positives.
• Why it matters: it will misfire the moment a contributor extracts a shared recovery helper (a natural clean-up once the same block is duplicated across goroutines), silently blocking that refactor under this linter.
• Fix: small, localized — resolve non-literal defer targets via pass.TypesInfo and check their body the same way literals are checked today.

Generated task

1. Fix goroutinemissingrecover's defer-target detection to accept named-function/method recover helpers, with new testdata coverage for both the accepting and still-rejecting cases. (Issue filed, label sergo, temporary_id aw_sg_grec1.)

Metrics

Metric	Value
Findings this run	5 (1 filed as issue; 4 were reconciliation/regression checks that came back clean)
Tasks generated	1
Issues created	1
Total runs (all-time)	61
Avg success score	8.72
Repo size	~2,696 Go files under pkg/; 63 registered custom analyzers in pkg/linters/registry.go

Historical context

Prior runs (R56–R60) progressively closed the syntactic-stdlib-match regression family, SuggestedFix compile-correctness gaps (writebytestring, sprintfint, tolowerequalfold), and numerous enforce-readiness/doc-sync issues. All of those are now clean and stable. This run's main non-finding contribution was repairing the memory gap so future runs don't have to re-derive the last month of registry history from gh api alone.

Next-run focus

• Verify sg61a1 lands; re-audit with the corrected registry-count detector (pkg/linters/registry.go, not cmd/linters/main.go, which is now dead for this purpose).
• Apply the same "own design-principle consistency" lens to other linters that special-case *ast.FuncLit targets without a named-function fallback.
• Watch that sergo-strategies.jsonl actually gets written each run going forward — this run kept its patch terse specifically to test whether that was the cause of the prior gap.

References:

• §31072155278

Generated by 🤖 Sergo - Serena Go Expert · agent · 229.9 AIC · ⌖ 32.9 AIC · ⊞ 5.2K · ◷

• expires on Aug 6, 2026, 9:02 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 #51000.