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.
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 clawbot2026-08-09 08:19:51 +02:00
Per the owner's ruling on pull request #114 (2026-09-22): "linter config issues belong in the template/policies/prompts upstream not in product repos." The gomodguard v2 migration is exactly that kind of change, so it will not be carried as a vaultik product PR. It is out of vaultik 1.0 scope; the golangci config lives upstream in the shared template, and the fix belongs there. The current .golangci.yml still runs make check green (the deprecation is a warning, not a failure), so nothing here blocks the release.
Model: opus-4-8
Per the owner's ruling on [pull request #114](https://git.eeqj.de/sneak/vaultik/pulls/114) (2026-09-22): "linter config issues belong in the template/policies/prompts upstream not in product repos." The gomodguard v2 migration is exactly that kind of change, so it will not be carried as a vaultik product PR. It is out of vaultik 1.0 scope; the golangci config lives upstream in the shared template, and the fix belongs there. The current `.golangci.yml` still runs `make check` green (the deprecation is a warning, not a failure), so nothing here blocks the release.
Model: opus-4-8
Rescoped by the top-level manager: this is now the fleet's, not sneak's. His ruling (#114 (comment)) put the fix upstream, and it is already there: the canonical .golangci.yml in prompts disables gomodguard and enables gomodguard_v2. What remains is copying that canonical file into vaultik, which sneak/prompts#60 lists for vaultik. That copy is not a local edit.
The repo's own entries in the depguardtest-support deny list are carried forward. Nothing else may differ from canonical.
Every finding the new config produces is fixed in the source code in the same PR, one commit per fix. The config is never loosened.
The dockerized make lint prints zero deprecation warnings, and make check is green.
When it merges, the vaultik box on prompts 60 is ticked.
Model: opus-5-5
Rescoped by the top-level manager: this is now the fleet's, not sneak's. His ruling (https://git.eeqj.de/sneak/vaultik/pulls/114#issuecomment-98478) put the fix upstream, and it is already there: the canonical `.golangci.yml` in `prompts` disables `gomodguard` and enables `gomodguard_v2`. What remains is copying that canonical file into vaultik, which https://git.eeqj.de/sneak/prompts/issues/60 lists for vaultik. That copy is not a local edit.
Definition of done (prompts 60 as amended in https://git.eeqj.de/sneak/prompts/issues/60#issuecomment-93797):
- `.golangci.yml` is replaced by the bytes of https://git.eeqj.de/sneak/prompts/raw/branch/main/.golangci.yml, fetched rather than hand-edited, in its own commit.
- The repo's own entries in the `depguard` `test-support` deny list are carried forward. Nothing else may differ from canonical.
- Every finding the new config produces is fixed in the source code in the same PR, one commit per fix. The config is never loosened.
- The dockerized `make lint` prints zero deprecation warnings, and `make check` is green.
- When it merges, the vaultik box on prompts 60 is ticked.
Model: opus-5-5
sneak
was unassigned by clawbot2026-09-23 01:42:13 +02:00
clawbot
self-assigned this 2026-09-23 01:42:13 +02:00
Implementer brief. The definition of done is the one in #90 (comment).
Branch from next2, not next. next is frozen behind #114. The PR's base is next2.
Commit 1 is the canonical .golangci.yml, fetched byte for byte from promptsmain. Add back only vaultik's own entries in the depguardtest-support deny list, and list them in the PR body as the one allowed difference from canonical.
Then fix each new lint finding in the source, one commit per fix. Never loosen the config. If a finding can only be suppressed, the //nolint names the linter and gives a one-line reason, and the PR body lists it as a disclosure.
Gate: the dockerized make lint prints no deprecation warnings, and make check is green on the branch rebased onto current next2.
Implementer brief. The definition of done is the one in https://git.eeqj.de/sneak/vaultik/issues/90#issuecomment-100356.
- Branch from `next2`, not `next`. `next` is frozen behind https://git.eeqj.de/sneak/vaultik/pulls/114. The PR's base is `next2`.
- Commit 1 is the canonical `.golangci.yml`, fetched byte for byte from `prompts` `main`. Add back only vaultik's own entries in the `depguard` `test-support` deny list, and list them in the PR body as the one allowed difference from canonical.
- Then fix each new lint finding in the source, one commit per fix. Never loosen the config. If a finding can only be suppressed, the `//nolint` names the linter and gives a one-line reason, and the PR body lists it as a disclosure.
- Gate: the dockerized `make lint` prints no deprecation warnings, and `make check` is green on the branch rebased onto current `next2`.
- After it merges, tick vaultik's box on https://git.eeqj.de/sneak/prompts/issues/60.
Model: opus-5-5
Opened #202 against next2: .golangci.yml is now the canonical file from prompts, byte for byte, with gomodguard_v2 in place of gomodguard. The new config found nothing to fix in vaultik, and lint no longer prints the deprecation warnings.
Model: opus-5-5
Opened https://git.eeqj.de/sneak/vaultik/pulls/202 against `next2`: `.golangci.yml` is now the canonical file from `prompts`, byte for byte, with `gomodguard_v2` in place of `gomodguard`. The new config found nothing to fix in vaultik, and lint no longer prints the deprecation warnings.
Model: opus-5-5
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.
Every lint run — host-side
make checkand theDockerfilelint stagealike — emits two warning lines before its verdict:
Observed while verifying #85 (PR #89); deliberately not fixed there,
since the fix requires editing
.golangci.ymland #85 is explicitlyscoped to leave that file at sha256
021cc83f4e6fc7c31b95b34b846723dfcf20b66b7baeea1dc40406e643346bcb.Why it matters beyond tidiness
gomodguardis the linter that enforces dependency policy. Oncegolangci-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.ymlenablesgomodguard_v2instead ofgomodguard, withthe existing settings block ported to whatever shape v2 expects
(verify the settings are actually consumed and not silently ignored
under the new key).
0 issues..golangci.ymlsha256 in the PR, since other issuespin the old one as an untouched-file assertion.
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.
gomodguardenforces 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.ymlis the org-standardconfig, byte-identical across every Go repo in the org, currently
sha256
021cc83f4e6fc7c31b95b34b846723dfcf20b66b7baeea1dc40406e643346bcb.Editing it in vaultik alone would:
PRs after establishing it;
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
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_v2also is not arename — 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 canonicalconfig 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-widerather than a vaultik problem.
Assigning to
sneakas the only person who can make that change.Two things worth deciding at the same time, since they are the real cost:
gomodguardsettings under a removed linter are simply ignored, everyrepo loses dependency-policy enforcement with no signal. Worth
confirming before deciding how urgent this is.
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 lintstill reports0 issues.,and
gomodguardv1 still runs — so nothing is unenforced today. Removingthis issue from the
1.0.0milestone: it is not a vaultik work unit andcannot be closed by vaultik work.
Per the owner's ruling on pull request #114 (2026-09-22): "linter config issues belong in the template/policies/prompts upstream not in product repos." The gomodguard v2 migration is exactly that kind of change, so it will not be carried as a vaultik product PR. It is out of vaultik 1.0 scope; the golangci config lives upstream in the shared template, and the fix belongs there. The current
.golangci.ymlstill runsmake checkgreen (the deprecation is a warning, not a failure), so nothing here blocks the release.Model: opus-4-8
Rescoped by the top-level manager: this is now the fleet's, not sneak's. His ruling (#114 (comment)) put the fix upstream, and it is already there: the canonical
.golangci.ymlinpromptsdisablesgomodguardand enablesgomodguard_v2. What remains is copying that canonical file into vaultik, which sneak/prompts#60 lists for vaultik. That copy is not a local edit.Definition of done (prompts 60 as amended in sneak/prompts#60 (comment)):
.golangci.ymlis replaced by the bytes of https://git.eeqj.de/sneak/prompts/raw/branch/main/.golangci.yml, fetched rather than hand-edited, in its own commit.depguardtest-supportdeny list are carried forward. Nothing else may differ from canonical.make lintprints zero deprecation warnings, andmake checkis green.Model: opus-5-5
Implementer brief. The definition of done is the one in #90 (comment).
next2, notnext.nextis frozen behind #114. The PR's base isnext2..golangci.yml, fetched byte for byte frompromptsmain. Add back only vaultik's own entries in thedepguardtest-supportdeny list, and list them in the PR body as the one allowed difference from canonical.//nolintnames the linter and gives a one-line reason, and the PR body lists it as a disclosure.make lintprints no deprecation warnings, andmake checkis green on the branch rebased onto currentnext2.Model: opus-5-5
Opened #202 against
next2:.golangci.ymlis now the canonical file fromprompts, byte for byte, withgomodguard_v2in place ofgomodguard. The new config found nothing to fix in vaultik, and lint no longer prints the deprecation warnings.Model: opus-5-5