[sergo] Sergo Report: Fresh-Linter Audit (Registry Delta 77->79) - 2026-10-11

[github-actions[bot]]

Executive Summary

Run R93. The registry grew by 2 analyzers since yesterday's run (77 -> 79): consolestderr (78th) and unchecked_deferredclose (79th), both merged 2026-10-10. A full day-one audit of both turned up two distinct, code-verified findings, and the standing reconcile check confirmed all 6 previously-open sergo issues are tracked accurately with zero drift. 2 new issues filed.

Tool & Registry Updates

• Serena: 24 tools, unchanged (serena --help reconfirmed live, exact match against cache).
• Linter registry: 77 -> 79 (grep -c 'Analyzer,\$' pkg/linters/registry.go).
  • 78th: consolestderr (PR Fix console formatter stream contracts and guard stderr usage #67423) - requires destination-aware console formatting for direct fmt.Fprint*(os.Stdout/os.Stderr, ...) writes.
  • 79th: unchecked_deferredclose (PR [linter-miner] Add unchecked-deferred-close linter #67481, pkg/linters/unchecked-deferred-close/) - reports defer x.Close() calls that ignore the returned error.

Strategy: 50/50 Split

• Cached reuse (50%): re-ran the standing gh api reconcile against all 6 previously-filed open issues (65753, 66009, 66436, 66773, 67102, 67336). All matched the prior run's prediction exactly - zero reverse-phantom flips, and deferinloop: range-over-func (Go 1.23+ iterators) false-positives defer-does-not-run-per-iteration, which is backwards for that #67336 confirmed as the prior run's deferinloop filing landing cleanly. No refile work was needed, so no issue budget was spent here this run.
• New exploration (50%): with a registry delta on the table, all exploration budget went into a first-ever audit of both brand-new analyzers rather than probing older ones - consistent with how prior delta runs (R74, R82, R84, R85) have allocated effort.

Findings

1. unchecked_deferredclose contradicts closeerrorunchecked's documented policy

unchecked_deferredclose flags every bare defer x.Close() whose Close() returns an error. But the sibling linter closeerrorunchecked - already in the registry - has test fixtures that explicitly label the identical code shape as correct:

Evidence

• closeerrorunchecked/testdata/.../closeerrorunchecked.go:74-79 - comment: "GoodDeferClose uses defer, which is the best practice — not flagged."
• closeerrorunchecked/testdata/.../closeerrorunchecked.go:132-136 - comment: "GoodCustomCloserDefer defers custom type Close — not flagged."
• closeerrorunchecked's own nodeFilter is {AssignStmt, ExprStmt} only - it structurally never even visits DeferStmt nodes.
• unchecked_deferredclose/testdata/src/basic/bad.go:20-28 reproduces the exact same os.Open + err-check + defer f.Close() idiom and expects it to be flagged.

A grep found roughly 150+ live production call sites of this exact shape across pkg/cli, pkg/parser, pkg/workflow, pkg/fileutil. Neither linter is currently in a shared CI gate together, so there's no live breakage yet - but the two linters hold opposite, testdata-documented opinions on the same idiom.

Filed as a new issue. New pattern class added to memory: cross_linter_policy_contradiction - distinct from every prior finding class because both analyzers are independently well-implemented; the conflict is one of policy, not of a missed AST shape or lost state.

2. consolestderr has the same native/wasm CI asymmetry as a previously-filed bug

consolestderr gets its own dedicated CI step in cgo.yml:1530-1531, but that step only runs in the native job. The wasm job (cgo.yml:1554-1555) has no equivalent step or flag, even though its LINTER_PACKAGES list explicitly includes ./pkg/console - the very package this linter targets.

This is the third occurrence of the ci_target_asymmetry class already tracked in memory (originally contextcancelnotdeferred, filed at #55932, refiled at #65753 which is still open today) - but the first time it's shown up on a linter's very first day rather than being found later via a retrospective sweep.

Tasks Generated (2)

#	Title	Effort
sg93a1	Reconcile unchecked_deferredclose vs closeerrorunchecked defer-Close() policy	Medium - decide and align one philosophy, update whichever testdata is stale
sg93a2	Add consolestderr to the wasm custom-linters CI step	Small - mirror the existing native step/flag into the wasm job

Both issues were dedup-checked via gh api search/issues before filing (zero prior coverage beyond the original creation PRs).

Metrics

• Findings this run: 6 (2 filed as issues, rest were clean-audit confirmations: reconcile x6 unchanged, 1 additional consolestderr helper audited clean).
• Tasks created: 2
• Success score: 9/10
• Running totals: 93 runs, 566 cumulative findings, 161 cumulative tasks, 8.72 avg success score.

Historical Context

This is the 9th registry-delta run (after R66, R67, R70, R74, R77(dbl), R82, R84, R85, R89) and the first to add two linters in a single delta. It's also the first run where a brand-new linter's CI wiring was checked for native/wasm parity on day one rather than being caught later - worth keeping as a standing day-one check per the updated memory notes.

Recommendations

• Resolve the unchecked_deferredclose/closeerrorunchecked policy conflict before unchecked_deferredclose is ever wired into CI enforcement.
• Mirror consolestderr's native CI step into the wasm job, and consider a direct diff test between the two LINTER_FLAGS strings (not just the registry-union test) given this is now a 3-time-recurring gap.

Next-Run Focus (R94)

• Verify sg93a1/sg93a2 landed; re-tally opens (expect 8 unless bulk-closed).
• If the registry grows again (80th), audit fresh.
• Sweep the now-3-linter Close()-semantics family (fileclosenotdeferred, closeerrorunchecked, unchecked_deferredclose) for any further 3-way conflicts if no new registry delta appears.
• Check wc -c on both memory files before writing (strategies file is at ~98.7 KB of a 102.4 KB cap).

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

• expires on Oct 11, 2026, 8:06 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 #67867.