[sergo] Sergo Report: Reverse-Phantom Reconcile + Presnapshot-Position-Blind Sweep Closeout - 2026-09-29

[github-actions[bot]]

Overview

Run R81 of the Sergo Go static-analysis loop against github/gh-aw. Serena tools stable at 24, registry stable at 73 analyzers (no delta since R74). This run split effort 50/50 between a cached-vein reconcile (re-verifying previously-closed issues against the current code) and finishing a new-exploration sweep started two runs ago.

Key Metrics

• Registry: 73 analyzers, STABLE since R74
• Open sergo issues pre-run: 15
• Reverse-phantoms confirmed this run: 1 (11th overall across the project history)
• New bug classes found: 0 (a planned sweep completed with a clean result, which is itself useful signal)
• Issues filed this run: 1
• Open sergo issues post-run (expected): 15 (14 unchanged + the new refile)

Findings

1. resourcetracker sibling-branch merge is still unfixed (11th reverse-phantom)

Issue #62304 (originally filed against the shared pkg/linters/internal/resourcetracker package, backing manualmutexunlock/fileclosenotdeferred/contextcancelnotdeferred) was auto-closed as not_planned since the last run. Direct re-reading of resourcetracker.go confirms the bug is 100 percent present: inspectBody keeps exactly one map[K]*state entry per acquired resource, populated by a single flat ast.Inspect with no branch scoping. When a resource is acquired once and an if/else has one arm release it manually and the sibling arm defer it, both arms write into the same state object, so the manual arms violation gets masked by the sibling defers presence.

Interestingly, a genuinely new feature landed in this file since the bug was first filed: a report-before-overwrite check for RE-acquisition of the same key (covered by a new ReassignReportsPreviousViolation test case). That fixes a different, narrower scenario and does not touch the sibling-branch case, since the latter only involves one acquisition. Refiled as a new issue with a concrete repro and a validation checklist.

2. presnapshot-position-blind sweep completed - vein closed at 2 confirmed instances

Two runs ago a new bug class was discovered: a linter that pre-builds an alias/lookup table across the WHOLE function or file before checking anything, then deletes entries during that same pass whenever a variable is reassigned. The effect is that a comparison which was textually valid EARLIER in the function gets retroactively blinded by a LATER reassignment, because every query hits the same static post-collection map regardless of source position. This was confirmed in lenstringzero and tolowerequalfold.

This run finished checking the remaining candidates identified by grepping for other collect* whole-pass helpers:

• hardcodedfilepath.collectKnownPathConsts - collects package-scope constants, which have fixed identity for the whole run (constants cannot be reassigned) - immune by construction.
• packagelevelmutableslicemap.collectPackageLevelSliceMapVars - collects package-level var declarations, also fixed identity across the run - immune.
• seenmapbool.collectSeenMapCandidates / findNonSetMaps - intentionally scans the whole function regardless of position, because whether a map is genuinely a set is a whole-lifetime property, not something tied to a single comparison site - correct design, not a bug.
• sprintfbool.collectSprintfBoolCandidates - does a direct single-pass type check on the immediate argument expression, with no alias pre-collection step at all - immune.

No new issue filed from this probe since all four came back clean; this closes out the sweep rather than leaving it open-ended.

Cache and Strategy Notes

The 50 percent cached-reuse half of the strategy was the reconcile pass (a proven high-yield tactic across this projects history - 11 of the last ~15 runs found at least one auto-expired-but-unfixed issue). The 50 percent new-exploration half was spent closing out a partially-finished vein from the last two runs, rather than opening a brand new one, since finishing a started sweep to a clean, well-documented conclusion is more valuable than starting a third parallel thread.

Historical Context

This is the 81st recorded run. Running averages: ~503 total findings, ~143 tasks generated, average success score 8.74/10 across all runs. Confirmed reverse-phantoms (issues auto-closed by the tracker while the underlying code is unchanged) now stand at 11 - this remains the single most reliable source of high-confidence findings in this project, since the auto-expiry policy does not correlate with whether a fix actually landed.

Next Run Focus

• Verify this runs refiled issue lands as expected
• Re-tally open issues (expect 15: 14 unchanged plus the new refile)
• If the analyzer registry grows past 73, prioritize a fresh audit of the new linter
• The presnapshot-position-blind vein is now closed; good candidates for new exploration include re-probing already-clean linters for bug classes other than the one each was originally checked for, or searching for a third branch_state_merge-style single-flat-map tracker beyond resourcetracker and httprespbodyclose

References:

• §36518904513

Generated by 🤖 Sergo - Serena Go Expert · claude · agent · 195.7 AIC · ⌖ 7.58 AIC · ⊞ 6.9K · ◷

• expires on Sep 29, 2026, 8:00 PM UTC-08:00

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-09-30T04:00:00.245Z.

Closed by Workflow