[sergo] Sergo Report: Tool-Change Detect 23rd Linter (sortslice) — Doc-Sync + Package-Identity Precision — 2026-06-09

[github-actions[bot]]

Summary

Run R31 detected a linter-registry tool change — a 23rd custom analyzer, sortslice, has landed in the driver — and applied the proven two-pronged template to it: a self-consistency doc-sync finding and a package-identity precision finding. Last run's two issues (#37740, #37741) both landed and closed within a day, confirming the new_linter_doc_lag and single-file-precision fast-land patterns. Two new, non-duplicate issues were filed.

Metric	Value
Strategy	tool-change-detect-23rd-linter-sortslice-docsync + package-identity-precision-audit
Findings	6 (2 filed, 1 deferred to other bot, 3 verified-resolved)
Issues created	2 (sg31a1, sg31a2)
Linters registered	23 (was 22) — 12 enforced, 11 unenforced
Serena LSP tools	23 (stable R4–31)
Success score	9 / 10

Critical Findings

🆕 sg31a1 — sortslice (23rd linter) registered but undocumented. cmd/linters/main.go:37,63 wires sortslice.Analyzer, but doc.go still says "All 22 active analyzers", README.md has zero sortslice references, and spec_test.go documentedAnalyzers() lists only 22 — so TestSpec_PublicAPI_SubpackageAnalyzers does not validate the 23rd analyzer. Identical to the just-landed lenstringzero gap (#37740). → Issue filed.

🆕 sg31a2 — sortslice matches by syntactic name, not package identity. sortslice.go:54-57 gates on pkgIdent.Name == "sort" with no pass.TypesInfo check. It is the only package-matching custom linter that skips type verification, yielding a false positive on any shadowing identifier named sort and a false negative on stdlib sort imported under an alias. Fix = mirror fmterrorfnoverbs.isFmtErrorf (ObjectOf → *types.PkgName → Imported().Path() == "sort"). → Issue filed.

Strategy: 50 / 50 Split

Cached reuse (50%) — tool-change detection + reverify-prior-landed

• Diffed cmd/linters/main.go analyzer count (23) against doc.go ("All 22") and spec_test.go documentedAnalyzers() (22) → surfaced the 23rd-linter doc-lag, the same template that landed sg30a1 in one day.
• Reverified last run via gh api .../issues?labels=sergo&state=all: lenstringzero (22nd custom linter) is registered in the driver but undocumented — sync doc.go, README, and spec_test to 22 analy [Content truncated due to length] #37740 (lenstringzero doc-sync) and lenstringzero precision: flag len() stored in an intermediate variable (n := len(s); n == 0) using the alias-tracking pattern th [Content truncated due to length] #37741 (intermediate-var FN) both closed. lenstringzero now appears in doc.go, README.md (5 entries), and spec_test.go.

New exploration (50%) — package-identity precision audit of the newcomer

• Used Serena search_for_pattern for TypesInfo|PkgPath across pkg/linters to map how each analyzer resolves stdlib-package calls. Result: fmterrorfnoverbs, jsonmarshalignoredeerror, strconvparseignorederror, ossetenvlibrary (and others) all resolve via pass.TypesInfo; sortslice alone matches on the spelled identifier → precision finding sg31a2.
• Cross-bot dedup (gh search issues): lint-monster already owns the 50+ call-site migration ([lint-monster] Sort Type-Safety: Migrate from sort.Slice to slices.SortFunc #38012, [lint-monster] Migrate unsafe sort.Slice calls to type-safe slices.SortFunc #38014), so sergo deliberately scoped to doc-sync + analyzer correctness — orthogonal, non-duplicate.

Evidence Snapshot

Registry vs documentation (23 vs 22)

Surface	Count / state
cmd/linters/main.go imports + registrations	23 (incl. sortslice L37/L63)
doc.go header + bullets	22 ("All 22", no sortslice)
README.md sortslice references	0
spec_test.go documentedAnalyzers()	22 entries
CI enforced (cgo.yml:1119 LINTER_FLAGS)	12

Precision: sibling linters vs sortslice

fmterrorfnoverbs.go:90  ObjectOf(pkgIdent).(*types.PkgName).Imported().Path() == "fmt"
jsonmarshal...go:88     pass.TypesInfo.Uses[ident]
strconvparse...go:75    pass.TypesInfo.Uses[ident]
ossetenvlibrary.go:71   pass.TypesInfo.Uses[fun.Sel]
sortslice.go:55         pkgIdent.Name != "sort"     <-- syntactic only

FP: sort := newSorter(); sort.Slice(...) wrongly flagged. FN: import s "sort"; s.Slice(...) silently missed. Testdata also lacks alias / shadowing / nolint cases.

Generated Tasks

1. sg31a1 — Bump doc.go/README.md/spec_test.go to 23 analyzers (mirror lenstringzero lenstringzero (22nd custom linter) is registered in the driver but undocumented — sync doc.go, README, and spec_test to 22 analy [Content truncated due to length] #37740). Small effort, docs-only.
2. sg31a2 — Resolve sortslice package via pass.TypesInfo.ObjectOf(...).(*types.PkgName).Imported().Path() == "sort" + add alias/shadowing testdata. Small effort, single-file precision.

Historical Context

• 31 runs; avg success 8.72; 239 cumulative findings, 61 tasks.
• new_linter_doc_lag now confirmed twice (lenstringzero R30→landed R31; sortslice R31) — each new linter lands in the driver before docs/spec sync.
• Single-file precision/doc fixes consistently land in ~1 day (sg27a1, sg29a1/a2, sg30a1/a2). Non-near-zero linters (seenmapbool 60+, sortslice 50+ sites) do not auto-land via sergo and are deferred to migration owners.

Recommendations / Next-Run Focus (R32)

• Verify sg31a1 (doc-sync) and sg31a2 (type-identity) landed.
• Re-run the registry diff to detect a possible 24th linter, and apply the new_linter_precision_audit (TypesInfo check) to any newcomer.
• Track sortslice CI enforcement, which should auto-follow the lint-monster migration ([lint-monster] Sort Type-Safety: Migrate from sort.Slice to slices.SortFunc #38012/[lint-monster] Migrate unsafe sort.Slice calls to type-safe slices.SortFunc #38014); revisit lenstringzero enforce-roadmap.

References:

• §27184898314

Generated by 🤖 Sergo - Serena Go Expert · 239.4 AIC · ⌖ 14.4 AIC · ⊞ 6.5K · ◷

• expires on Jun 9, 2026, 9:12 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 #38283.