golangci-lint deprecation: gomodguard replaced by gomodguard_v2 #90

New Issue

clawbot · 2026-08-09T08:17:48+02:00

clawbot commented

2026-08-09 08:17:48 +02:00

Every lint run — host-side make check and the Dockerfile lint stage
alike — emits two warning lines before its verdict:

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"

Observed while verifying #85 (PR #89); deliberately not fixed there,
since the fix requires editing .golangci.yml and #85 is explicitly
scoped to leave that file at sha256
021cc83f4e6fc7c31b95b34b846723dfcf20b66b7baeea1dc40406e643346bcb.

Why it matters beyond tidiness

gomodguard is the linter that enforces dependency policy. Once
golangci-lint drops the v1 name, the linter silently stops running and
the config keeps parsing — the same shape of failure as #78 and #85: a
check that appears configured but no longer executes. Better to migrate
while the deprecation is still loud.

Definition of done

.golangci.yml enables gomodguard_v2 instead of gomodguard, with
the existing settings block ported to whatever shape v2 expects
(verify the settings are actually consumed and not silently ignored
under the new key).
A lint run produces no deprecation warnings and still reports
0 issues.
Record the new .golangci.yml sha256 in the PR, since other issues
pin the old one as an untouched-file assertion.

Every lint run — host-side `make check` and the `Dockerfile` lint stage alike — emits two warning lines before its verdict: ``` 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" ``` Observed while verifying #85 (PR #89); deliberately not fixed there, since the fix requires editing `.golangci.yml` and #85 is explicitly scoped to leave that file at sha256 `021cc83f4e6fc7c31b95b34b846723dfcf20b66b7baeea1dc40406e643346bcb`. ## Why it matters beyond tidiness `gomodguard` is the linter that enforces dependency policy. Once golangci-lint drops the v1 name, the linter silently stops running and the config keeps parsing — the same shape of failure as #78 and #85: a check that appears configured but no longer executes. Better to migrate while the deprecation is still loud. ## Definition of done 1. `.golangci.yml` enables `gomodguard_v2` instead of `gomodguard`, with the existing settings block ported to whatever shape v2 expects (verify the settings are actually consumed and not silently ignored under the new key). 2. A lint run produces no deprecation warnings and still reports `0 issues.` 3. Record the new `.golangci.yml` sha256 in the PR, since other issues pin the old one as an untouched-file assertion.

clawbot referenced this issue

2026-08-09 08:18:07 +02:00

Make script/cibuild unable to report an unearned green (closes #85) #89

clawbot commented

2026-08-09 08:19:47 +02:00

Manager note — this cannot be fixed in vaultik, and I am redirecting
it rather than scheduling it.

The substance of the report is right and worth keeping. gomodguard
enforces dependency policy, and when the v1 name is eventually dropped
the config will still parse while the linter silently stops running.
That is the same failure shape as #78 and #85: enforcement quietly
disappears while the gate keeps reporting green. That argument is a good
reason to prioritise it, so I do not want it lost.

But the fix does not belong here. .golangci.yml is the org-standard
config, byte-identical across every Go repo in the org, currently
sha256 021cc83f4e6fc7c31b95b34b846723dfcf20b66b7baeea1dc40406e643346bcb.
Editing it in vaultik alone would:

break the byte-identical invariant #59 was opened to establish, three
PRs after establishing it;
invalidate the hash that #78, #85, #88 and every recent PR assert as
an untouched-file check — those assertions are load-bearing, since
"nothing was weakened to make lint pass" is exactly what they exist to
prove; and
leave vaultik silently diverged, so the next sync would either revert
the fix or produce a spurious conflict.

The repo policy is explicit that agents never modify this file and only
the owner may change it. A migration to gomodguard_v2 also is not a
rename — the settings block moves to a different schema, so it needs to
be authored once and validated against every repo that consumes it, not
per-repo.

Correct path: fix upstream in sneak/prompts, where the canonical
config lives, then re-vendor to all consuming repos as a coordinated
change with a new sha256. Sibling repos already track the same warning
(sneak/pixa#57, sneak/homoicon#4), which confirms it is org-wide
rather than a vaultik problem.

Assigning to sneak as the only person who can make that change.

Two things worth deciding at the same time, since they are the real cost:

When v1 is dropped, does the config fail loudly or silently? If
gomodguard settings under a removed linter are simply ignored, every
repo loses dependency-policy enforcement with no signal. Worth
confirming before deciding how urgent this is.
The re-vendor needs a hash-update sweep. Several vaultik issues and
PRs assert the current sha256 verbatim. When the canonical config
changes, those assertions need updating in lockstep or they will start
failing for the right reason in the wrong place.

Meanwhile the warning is non-fatal, make lint still reports 0 issues.,
and gomodguard v1 still runs — so nothing is unenforced today. Removing
this issue from the 1.0.0 milestone: it is not a vaultik work unit and
cannot be closed by vaultik work.

Manager note — **this cannot be fixed in vaultik**, and I am redirecting it rather than scheduling it. The substance of the report is right and worth keeping. `gomodguard` enforces dependency policy, and when the v1 name is eventually dropped the config will still **parse** while the linter silently stops running. That is the same failure shape as #78 and #85: enforcement quietly disappears while the gate keeps reporting green. That argument is a good reason to prioritise it, so I do not want it lost. But the fix does not belong here. `.golangci.yml` is the org-standard config, **byte-identical across every Go repo in the org**, currently sha256 `021cc83f4e6fc7c31b95b34b846723dfcf20b66b7baeea1dc40406e643346bcb`. Editing it in vaultik alone would: 1. break the byte-identical invariant #59 was opened to establish, three PRs after establishing it; 2. invalidate the hash that #78, #85, #88 and every recent PR assert as an untouched-file check — those assertions are load-bearing, since "nothing was weakened to make lint pass" is exactly what they exist to prove; and 3. leave vaultik silently diverged, so the next sync would either revert the fix or produce a spurious conflict. The repo policy is explicit that agents never modify this file and only the owner may change it. A migration to `gomodguard_v2` also is not a rename — the settings block moves to a different schema, so it needs to be authored once and validated against every repo that consumes it, not per-repo. **Correct path:** fix upstream in `sneak/prompts`, where the canonical config lives, then re-vendor to all consuming repos as a coordinated change with a new sha256. Sibling repos already track the same warning (`sneak/pixa#57`, `sneak/homoicon#4`), which confirms it is org-wide rather than a vaultik problem. Assigning to `sneak` as the only person who can make that change. Two things worth deciding at the same time, since they are the real cost: - **When v1 is dropped, does the config fail loudly or silently?** If `gomodguard` settings under a removed linter are simply ignored, every repo loses dependency-policy enforcement with no signal. Worth confirming before deciding how urgent this is. - **The re-vendor needs a hash-update sweep.** Several vaultik issues and PRs assert the current sha256 verbatim. When the canonical config changes, those assertions need updating in lockstep or they will start failing for the right reason in the wrong place. Meanwhile the warning is non-fatal, `make lint` still reports `0 issues.`, and `gomodguard` v1 still runs — so nothing is unenforced today. Removing this issue from the `1.0.0` milestone: it is not a vaultik work unit and cannot be closed by vaultik work.

sneak was assigned by clawbot

2026-08-09 08:19:51 +02:00

clawbot referenced this issue

2026-08-09 08:42:07 +02:00

Make script/cibuild unable to report an unearned green (closes #85) #89

clawbot referenced this issue

2026-08-09 09:01:02 +02:00

Make script/cibuild unable to report an unearned green (closes #85) #89

clawbot referenced this issue

2026-08-09 09:53:28 +02:00

Make a missing CHECK_EPOCH fail the build instead of faking it (closes #91) #92

clawbot referenced this issue