PROPAGATION: roll the new canonical .golangci.yml bytes (gomodguard_v2 migration) into every consuming repository #60
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Follow-up required by the definition of done in
#25. Consuming repos vendor the
canonical
.golangci.ymland verify it by sha256, so they all mismatch themoment #55 lands.
Do not start until that PR has merged.
The bytes
.golangci.yml:d10f47ef5e0d8620efd62275b016a7de8fd5abedf333922eec86fe4abc06176e.golangci.yml:a79b63a254602a5318db5d0e9a06bc71b84bf0c1d896305229d8bfed1d1b1776Per-repo definition of done
https://git.eeqj.de/sneak/prompts/raw/branch/main/.golangci.ymlrather thanhand-editing the local copy, and land it as its own commit.
denylist of thetest-supportdepguardrule. That list is the one part exempt frombyte-identity (
REPO_POLICIES.md), and a re-vendor that drops it silentlyremoves a rule the repo relies on.
denyentries will notmatch the new sha256 above and is not supposed to. Diff against canonical
and confirm the only difference is that list. Do not "fix" a repo to match
the hash.
make lintthrough the repo's own dockerized entrypoint and confirmzero deprecation warnings, not merely that the
gomodguardone is gone.gomodguard_v2block list (rs/zerolog, thepre-fork
go-redis/redis,sergi/go-diff,hexops/gotextdiff). No repobelow required any of them when their
go.modfiles were read on2026-08-31, so no new findings are expected. If a repo has since taken one
on, stop and report rather than editing the vendored config.
homoiconis a special case: its copy carries a header comment recording theowner-approved agent edit of 2026-08-07, under the one-case exception in
sneak/homoicon#4. The re-vendor must carry that
comment forward, and is tracked at
sneak/homoicon#632.
Repos
Named as vendoring the canonical config in
#25; their
go.modfiles were read on2026-08-31 for the block-list check above:
Go repos on the tooling roster that were not part of that survey; confirm
applicability first and tick with a note if the repo carries no vendored
.golangci.yml:Separate from #35 (Docker build-context
trio) and #39 (Go tooling fixes). A repo
can take this in any order relative to those, but keep it as its own commit.
Model: opus-5
The new canonical sha256 in "The bytes" was stale and has been corrected to
a79b63a254602a5318db5d0e9a06bc71b84bf0c1d896305229d8bfed1d1b1776; the oldcanonical value is unchanged. Nobody has started yet, since
#55 has not merged.
The block list also changed shape while that PR was in review: the pre-fork
go-redis is now three exact entries (
github.com/go-redis/redis,/v7,/v8)rather than one prefix match, so
github.com/go-redis/redismockis notblocked. Item 5's list of blocked modules is otherwise as written.
Model: opus-5
Ruling from sneak, 2026-09-09, amending the per-repo definition of done: a repo's re-vendor PR must land green. If the new config produces lint findings in that repo (the
gomodguard_v2block list, or any check the new file turns on), the same PR includes the commits that fix those findings — fix the code, never loosen the vendored config. This replaces item 5's "stop and report": stop and ask only if fixing a finding would need a judgement call an implementer cannot make (a dependency that has to stay, an owner decision), otherwise fix it in the PR.So each repo's PR is: the vendored
.golangci.ymlas its own commit, the repo's owndenyentries carried forward, then one commit per source fix the new config demands, ending green through the repo's own dockerizedmake lintwith zero deprecation warnings.Model: opus-4-8