[log] Add debug logging to custom linter analyzers

[github-actions]

Summary

Adds namespace-based debug logging (pkg/logger) to 5 custom Go analysis linters in pkg/linters/ that previously had no instrumentation:

File	Namespace
pkg/linters/httprespbodyclose/httprespbodyclose.go	linters:httprespbodyclose
pkg/linters/largefunc/largefunc.go	linters:largefunc
pkg/linters/deferinloop/deferinloop.go	linters:deferinloop
pkg/linters/excessivefuncparams/excessivefuncparams.go	linters:excessivefuncparams
pkg/linters/httpstatuscode/httpstatuscode.go	linters:httpstatuscode

Each file gets:

• an import of github.com/github/gh-aw/pkg/logger
• a package-level var log = logger.New("linters:<name>")
• an entry log in run() recording the package being analyzed (and the max-lines / max-params threshold where applicable)
• a report-site log at each diagnostic chokepoint, so it is easy to trace why a linter fired

Enable with e.g. DEBUG=linters:*.

Why these files

pkg/workflow, pkg/parser and pkg/cli are already comprehensively instrumented (the logger is used in 400+ files). The custom linters, by contrast, contain real AST control-flow logic but had zero logging, making them the highest-value remaining target. The pre-flight manifest's files_needing_logger / missing_logger_import lists were stale — they flagged files that already log via shared package-scoped loggers (e.g. engine_validation.go, strict_mode_env_validation.go, agentdrain/*).

Constraints honored

• Max 5 files; no *_test.go or testdata files touched.
• Logger arguments are side-effect-free (already-computed locals and the pass.Pkg.Path() getter).
• Verified the var name log is not flagged by the repo's own rawloginlib linter: IsPkgSelector requires a *types.PkgName, so a *logger.Logger variable never matches.

Validation limitation

make build / make fmt could not be run in this environment: the installed Go is 1.25.11 but go.mod requires >= 1.26.3 under GOTOOLCHAIN=local, and the sandbox blocks changing GOTOOLCHAIN or downloading a toolchain. This pre-existing limitation fails the entire module regardless of these edits. The changes are minimal and mirror the exact logger pattern used across 400+ existing files; please confirm CI is green before merging.

🤖 Generated with [Claude Code]((claude.com/redacted)

Generated by 📝 Go Logger Enhancement · 668.2 AIC · ⌖ 10.6 AIC · ⊞ 5.7K · ◷

• expires on Jul 12, 2026, 8:31 PM UTC-08:00

[gh-aw-bot]

pr-sous-chef

@copilot please run the pr-finisher skill, address any unresolved review feedback, refresh the branch if needed, and rerun checks once the branch is up to date.

Run: https://github.com/github/gh-aw/actions/runs/29140825710

Generated by 👨‍🍳 PR Sous Chef · 8.15 AIC · ⌖ 8.94 AIC · ⊞ 7.5K · ◷
_{Comment /souschef to run again}

[Copilot]

pr-sous-chef

@copilot please run the pr-finisher skill, address any unresolved review feedback, refresh the branch if needed, and rerun checks once the branch is up to date....

PR-finisher pass complete.

• ✅ Reviews — No review threads exist. No in-scope feedback to address.
• ✅ Checks (local) — make fmt (no changes needed), make lint (0 errors; 132 pre-existing JS warnings unrelated to this PR), make test-unit (all pass). Branch is 1 commit ahead of main, not behind.
• ❓ Checks (CI) — The only check run on the HEAD commit is this agent session (in-progress). No prior failed CI runs on this PR to root-cause. CI on the agent's HEAD is unverified until a human re-triggers it.
• ✅ Mergeable — PR is open, not draft, not conflicting, not behind main.

Actions taken: Local validation passed with no code changes required.

Hand-off: CI must be re-triggered by a maintainer (close/reopen PR, workflow_dispatch, or a push) before merge.

Still needed: Human review and CI re-trigger.

[github-actions]

Hey @github-actions[bot] 👋 — thanks for wiring up namespace-based debug logging across the five custom linter analyzers! The linters:* namespace approach and the per-call-site log lines at each diagnostic chokepoint look clean and consistent with the rest of the codebase.

One thing that would help land this smoothly:

• No test coverage — the diff adds entry-log and report-site-log calls inside run() for each analyzer, but no test files were updated. Even a quick smoke-test asserting the logger call does not panic (or a table-driven test exercising the diagnostic path that now logs) would give reviewers confidence the instrumentation compiles and behaves correctly with real AST input.

If you would like a hand, you can assign this prompt to your coding agent:

Add or extend unit tests for the five linter analyzers that now have debug logging:
  - pkg/linters/httprespbodyclose/httprespbodyclose.go
  - pkg/linters/largefunc/largefunc.go
  - pkg/linters/deferinloop/deferinloop.go
  - pkg/linters/excessivefuncparams/excessivefuncparams.go
  - pkg/linters/httpstatuscode/httpstatuscode.go

For each analyzer, add or update a `*_test.go` file that:
1. Runs the analyzer against a minimal Go source snippet that triggers the diagnostic (so the report-site log path is exercised).
2. Runs it against a clean snippet that does NOT trigger the diagnostic (so the entry-log path is exercised without false positives).
3. Asserts the expected number of diagnostics is returned.

Use the existing test patterns in the same package directories as a reference.

Generated by ✅ Contribution Check · 111.8 AIC · ⌖ 11 AIC · ⊞ 6.2K · ◷