[sergo] Sergo Report: cached-enforce-readiness-audit(errorfwrapv)+newexplore-registry-detector-fix - 2026-08-28

[github-actions[bot]]

Executive summary

This run started from a stale local cache (last strategy entry: 2026-07-08, R60) but gh api reconciliation showed the sergo label now spans issues up to #56253, with only one currently open (#55932, filed by an earlier, untracked run). The gap means many runs' memory writes never persisted — treated as a lower bound going forward, not a hard count. Repo-memory has been updated to reflect this and to record a fix for a dead detector (see Tool updates).

Strategy this run: a cached playbook (enforcement-readiness audit — the most consistently productive pattern in this repo's history) applied to a new target (errorfwrapv, one of 11 linters doc_sync_test.go marks notYetEnforced, whose reason explicitly invites a post-fix audit). The audit surfaced a linter blind spot that was hiding a real, live bug.

Tool updates

• cmd/linters/main.go was refactored down to 24 lines (multichecker.Main(linters.All()...)); the old detector (grep -c Analyzer main.go) now returns 0. Analyzer registration lives in pkg/linters/registry.go's allAnalyzers slice. New detector: grep -c '\.Analyzer,$' pkg/linters/registry.go → 67, cross-checked against cgo.yml LINTER_FLAGS counts (55 native-enforced + 11 documented-notYetEnforced + ssljson as a filesystem-anchor special case = 67).
• Serena's 23-tool surface is unchanged.

Strategy split

• Cached (50%): reuse the "enforce-readiness audit" playbook (grep production code for the analyzer's exact pattern, confirm zero/near-zero true positives before recommending LINTER_FLAGS enablement) — this pattern has closed ~10 issues historically with a high hit rate.
• New exploration (50%): target errorfwrapv specifically, since it's one of the few notYetEnforced linters whose documented reason is "needs a re-audit" rather than "known prod violations to remediate" — a fresh, unaudited surface.

Findings

1. errorfwrapv's format-string matcher only accepts a literal *ast.BasicLit as call.Args[0] (pkg/linters/errorfwrapv/errorfwrapv.go:70-73). Any fmt.Errorf call whose format string is built by concatenation (message + "literal") is invisible to the analyzer — it returns before ever inspecting verbs or the trailing error argument.
2. That blind spot hides a real production bug: pkg/cli/audit_run_pipeline.go:317-325's cacheRecoveryError() helper builds its format string via message + "\n\n" + ... + "Original error: %v" and passes err — using %v instead of %w. The wrapped error can't be unwrapped via errors.Is/errors.As, in a file that otherwise relies on errors.Is(err, ErrNoArtifacts) for control flow. Two call sites are affected.
3. Grep confirmed this is the only production, non-test fmt.Errorf call under pkg/ with a concatenated format string and a trailing %v-formatted error — a narrow, well-isolated finding, not a systemic pattern.

Task generated

One issue filed (aw_sg2808a1): fix cacheRecoveryError to use %w, harden errorfwrapv to resolve concatenated format strings, add regression testdata, then re-audit before enabling -errorfwrapv in cgo.yml.

Metrics

• Findings: 3 (registry-detector staleness, the linter blind spot, the concrete prod bug)
• Issues created: 1 (of a max 3) — the other unenforced linters (hardcodedfilepath, largefunc, manualpathconcat, packagelevelmutableslicemap, seenmapbool, sprintferrdot, stringsconcatloop, lenstringzero, excessivefuncparams) were scoped for future runs rather than shallow-audited under time pressure this run
• Duplicate check: searched gh api issues?labels=sergo (open + a targeted search/issues query for errorfwrapv/cacheRecoveryError) — no prior issue on this exact finding
• Success self-score: 8/10 — one well-evidenced, non-duplicate, actionable finding with a concrete fix; docked slightly for not reaching 2-3 issues given the available unaudited surface

Historical context

Prior runs (through R60) systematically closed dozens of issues across bug classes: syntactic stdlib-package matching, FuncLit scope-boundary bugs, SuggestedFix compile-correctness (the stringbytesroundtrip/writebytestring isExactString class), node-filter/pattern-set narrowness, and CI-enforcement drift. That last class is still live: #55932 (open) covers the wasm/native LINTER_FLAGS asymmetry for contextcancelnotdeferred.

Recommendations & next-run focus

• Re-verify aw_sg2808a1 lands, then continue the enforcement-readiness sweep on the remaining unenforced linters listed above.
• Probe fmterrorfnoverbs, sprintferrdot, sprintfbool, and sprintfint for the same call.Args[0].(*ast.BasicLit)-only pattern — they likely share the identical blind spot to concatenated/dynamic format strings.
• Keep reconciling via gh api repos/github/gh-aw/issues?labels=sergo every run regardless of local memory state, since this run found the local history undercounts real activity.

References:

• §33147289052 (this run)
• §32928475496 (prior run that filed contextcancelnotdeferred is enforced on native CI but absent from wasm LINTER_FLAGS - the registry-drift guard cannot detect it #55932)

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• api.anthropic.com

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "api.anthropic.com"

See Network Configuration for more information.

Generated by 🤖 Sergo - Serena Go Expert · claude · agent · 223.6 AIC · ⌖ 7.23 AIC · ⊞ 6.8K · ◷

• expires on Aug 28, 2026, 10:27 PM UTC-08:00