@sneak — this one is yours by construction, because the only file that can fix it is one no agent is permitted to touch.
Situation
Every make lint run in this repo emits:
level=warning msg="The linter 'gomodguard' is deprecated (since v2.12.0) due to: new major version. Replaced by gomodguard_v2."
level=warning msg="Suggested new configuration:\nlinters:\n enable:\n - gomodguard_v2\n"
This is not caused by any PR in the 1.0 milestone — it is present on main and appears on every branch. It surfaced on PR #113 (where the reviewer correctly flagged it as pre-existing and declined to chase it) and again on #112 and #118 during lint revalidation.
The trigger is the golangci-lint v2.12.2 upgrade that landed in PR #96: gomodguard was deprecated in v2.12.0, exactly the version this repo pinned to.
Why I am not fixing it
REPO_POLICIES.md is unambiguous:
> .golangci.yml is standardized and must NEVER be modified by an agent, only manually by the user.
The fix is a one-line change in .golangci.yml (gomodguard → gomodguard_v2), and that file is off limits to me. Its sha256 must remain 021cc83f4e6fc7c31b95b34b846723dfcf20b66b7baeea1dc40406e643346bcb in every PR I approve, and I have been verifying exactly that on each one.
There is a second reason to route this through you rather than around it: the config is org-standard and shared. Every Go repo on the same pinned linter has this warning. Fixing it here alone would fork this repo's config away from the canonical one and break the sha256 check that several open issues rely on. The change belongs upstream in the prompts repo, then propagates.
Options
Update the canonical .golangci.yml upstream (gomodguard → gomodguard_v2), then propagate the new file and its new sha256 to every Go repo. Correct and durable. Requires touching the shared template and re-baselining the hash everywhere it is asserted.
Leave it. It is a warning, not an error — make lint still reports 0 issues. and the gate is not compromised. Cost is permanent noise on every lint run, which is the specific condition under which real signals get overlooked.
Defer past 1.0. Tag the release with the warning present and fix it in the next config refresh.
Recommendation
Option 1, upstream, but not as a 1.0 blocker. The warning is cosmetic today and nothing in the gate depends on gomodguard specifically. But standing warnings are how genuine ones get missed, and this repo has already been bitten three times this milestone by checks that looked authoritative and were not (#115, #117, #121). Clearing avoidable noise from the one gate that still reports honestly is worth doing — just not on the critical path to tagging.
If you would rather I do nothing at all here, say so and I will close this.
Definition of done (whichever option you pick)
make lint emits no deprecation warnings, or this issue is closed with a decision recorded.
If the config changes, the new sha256 is published so agents can keep verifying it — several open issues (#109, #115, #117, #119, #121) assert the current hash, and they will all need the new value.
The linter version pin c0d3ddc9cf3faa61a4e378e879ece580256d76e5 is unchanged; this is a config change, not a version bump.
Related
Three other gate-integrity defects found this session, all filed and none of them requiring your intervention: #115 (script/cibuild reports an unearned green from the Docker layer cache), #117 (script/bootstrap skips the pinned linter install, so the running linter may not be the pinned one), #121 (script/lint shares one golangci-lint cache and lock across concurrent worktrees, so a result can come from a different codebase). All three are tracked upstream too.
@sneak — this one is yours by construction, because the only file that can fix it is one no agent is permitted to touch.
## Situation
Every `make lint` run in this repo emits:
```
level=warning msg="The linter 'gomodguard' is deprecated (since v2.12.0) due to: new major version. Replaced by gomodguard_v2."
level=warning msg="Suggested new configuration:\nlinters:\n enable:\n - gomodguard_v2\n"
```
This is not caused by any PR in the 1.0 milestone — it is present on `main` and appears on every branch. It surfaced on [PR #113](https://git.eeqj.de/sneak/dnswatcher/pulls/113) (where the reviewer correctly flagged it as pre-existing and declined to chase it) and again on [#112](https://git.eeqj.de/sneak/dnswatcher/pulls/112) and [#118](https://git.eeqj.de/sneak/dnswatcher/pulls/118) during lint revalidation.
The trigger is the golangci-lint **v2.12.2** upgrade that landed in PR #96: `gomodguard` was deprecated in v2.12.0, exactly the version this repo pinned to.
## Why I am not fixing it
`REPO_POLICIES.md` is unambiguous:
> `.golangci.yml` is standardized and must _NEVER_ be modified by an agent, only manually by the user.
The fix is a one-line change in `.golangci.yml` (`gomodguard` → `gomodguard_v2`), and that file is off limits to me. Its sha256 must remain `021cc83f4e6fc7c31b95b34b846723dfcf20b66b7baeea1dc40406e643346bcb` in every PR I approve, and I have been verifying exactly that on each one.
There is a second reason to route this through you rather than around it: the config is **org-standard and shared**. Every Go repo on the same pinned linter has this warning. Fixing it here alone would fork this repo's config away from the canonical one and break the sha256 check that several open issues rely on. The change belongs upstream in the `prompts` repo, then propagates.
## Options
1. **Update the canonical `.golangci.yml` upstream** (`gomodguard` → `gomodguard_v2`), then propagate the new file and its new sha256 to every Go repo. Correct and durable. Requires touching the shared template and re-baselining the hash everywhere it is asserted.
2. **Leave it.** It is a warning, not an error — `make lint` still reports `0 issues.` and the gate is not compromised. Cost is permanent noise on every lint run, which is the specific condition under which real signals get overlooked.
3. **Defer past 1.0.** Tag the release with the warning present and fix it in the next config refresh.
## Recommendation
**Option 1, upstream, but not as a 1.0 blocker.** The warning is cosmetic today and nothing in the gate depends on `gomodguard` specifically. But standing warnings are how genuine ones get missed, and this repo has already been bitten three times this milestone by checks that looked authoritative and were not (#115, #117, #121). Clearing avoidable noise from the one gate that still reports honestly is worth doing — just not on the critical path to tagging.
If you would rather I do nothing at all here, say so and I will close this.
## Definition of done (whichever option you pick)
1. `make lint` emits no deprecation warnings, **or** this issue is closed with a decision recorded.
2. If the config changes, the new sha256 is published so agents can keep verifying it — several open issues (#109, #115, #117, #119, #121) assert the current hash, and they will all need the new value.
3. The linter version pin `c0d3ddc9cf3faa61a4e378e879ece580256d76e5` is unchanged; this is a config change, not a version bump.
## Related
Three other gate-integrity defects found this session, all filed and none of them requiring your intervention: #115 (`script/cibuild` reports an unearned green from the Docker layer cache), #117 (`script/bootstrap` skips the pinned linter install, so the running linter may not be the pinned one), #121 (`script/lint` shares one golangci-lint cache and lock across concurrent worktrees, so a result can come from a different codebase). All three are tracked upstream too.
clawbot
added this to the 1.0 milestone 2026-08-09 08:05:15 +02:00
sneak
was assigned by clawbot2026-08-09 08:05:15 +02:00
[manager] Still reproducing — the gomodguard deprecation warning appears on every Docker lint run after #134 landed. No new issue filed; this one already covers it.
Confirming the constraint holds: .golangci.yml is org-canonical and must not be edited downstream, so the migration to gomodguard_v2 belongs in sneak/prompts and then fans out to every repo vendoring it. Nothing to do here until that lands.
**[manager]** Still reproducing — the `gomodguard` deprecation warning appears on every Docker lint run after https://git.eeqj.de/sneak/dnswatcher/issues/134 landed. No new issue filed; this one already covers it.
Confirming the constraint holds: `.golangci.yml` is org-canonical and must not be edited downstream, so the migration to `gomodguard_v2` belongs in `sneak/prompts` and then fans out to every repo vendoring it. Nothing to do here until that lands.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
@sneak — this one is yours by construction, because the only file that can fix it is one no agent is permitted to touch.
Situation
Every
make lintrun in this repo emits:This is not caused by any PR in the 1.0 milestone — it is present on
mainand appears on every branch. It surfaced on PR #113 (where the reviewer correctly flagged it as pre-existing and declined to chase it) and again on #112 and #118 during lint revalidation.The trigger is the golangci-lint v2.12.2 upgrade that landed in PR #96:
gomodguardwas deprecated in v2.12.0, exactly the version this repo pinned to.Why I am not fixing it
REPO_POLICIES.mdis unambiguous:>
.golangci.ymlis standardized and must NEVER be modified by an agent, only manually by the user.The fix is a one-line change in
.golangci.yml(gomodguard→gomodguard_v2), and that file is off limits to me. Its sha256 must remain021cc83f4e6fc7c31b95b34b846723dfcf20b66b7baeea1dc40406e643346bcbin every PR I approve, and I have been verifying exactly that on each one.There is a second reason to route this through you rather than around it: the config is org-standard and shared. Every Go repo on the same pinned linter has this warning. Fixing it here alone would fork this repo's config away from the canonical one and break the sha256 check that several open issues rely on. The change belongs upstream in the
promptsrepo, then propagates.Options
.golangci.ymlupstream (gomodguard→gomodguard_v2), then propagate the new file and its new sha256 to every Go repo. Correct and durable. Requires touching the shared template and re-baselining the hash everywhere it is asserted.make lintstill reports0 issues.and the gate is not compromised. Cost is permanent noise on every lint run, which is the specific condition under which real signals get overlooked.Recommendation
Option 1, upstream, but not as a 1.0 blocker. The warning is cosmetic today and nothing in the gate depends on
gomodguardspecifically. But standing warnings are how genuine ones get missed, and this repo has already been bitten three times this milestone by checks that looked authoritative and were not (#115, #117, #121). Clearing avoidable noise from the one gate that still reports honestly is worth doing — just not on the critical path to tagging.If you would rather I do nothing at all here, say so and I will close this.
Definition of done (whichever option you pick)
make lintemits no deprecation warnings, or this issue is closed with a decision recorded.c0d3ddc9cf3faa61a4e378e879ece580256d76e5is unchanged; this is a config change, not a version bump.Related
Three other gate-integrity defects found this session, all filed and none of them requiring your intervention: #115 (
script/cibuildreports an unearned green from the Docker layer cache), #117 (script/bootstrapskips the pinned linter install, so the running linter may not be the pinned one), #121 (script/lintshares one golangci-lint cache and lock across concurrent worktrees, so a result can come from a different codebase). All three are tracked upstream too.[manager] Still reproducing — the
gomodguarddeprecation warning appears on every Docker lint run after #134 landed. No new issue filed; this one already covers it.Confirming the constraint holds:
.golangci.ymlis org-canonical and must not be edited downstream, so the migration togomodguard_v2belongs insneak/promptsand then fans out to every repo vendoring it. Nothing to do here until that lands.