Option-2 answer to sneak's ruling of 2026-08-19 on sneak/homoicon#4: migrate to the successor, with
settings. Closes #25.
The change
golangci-lint v2.12.0 deprecated gomodguard, and this config sets linters.default: all, so it is enabled everywhere and warns on every run.
gomodguard joins wsl in linters.disable under a shared "deprecated"
comment. The warning is attached to the old name, so disabling it is what
silences it.
gomodguard_v2 is named in linters.enable, a no-op under default: all
that gives the settings block a visible owner.
Blocked, each restating a decision already recorded in the Go package
defaults: rs/zerolog → log/slog; the pre-fork go-redis/redis → redis/go-redis/v9; sergi/go-diff and hexops/gotextdiff → go-udiff.
Every entry matches the module path exactly, so the pre-fork go-redis takes
three: go-redis/redis, /v7, /v8. A prefix would also cover go-redis/redismock, the test double for the successor recommended here.
Deliberately absent: recorded rejections that vendoring repos still require
(mattn/go-sqlite3, gorm.io/gorm, pmezard/go-difflib), plus urfave/cli
and unversioned go-chi/chi. Blocking those would redden repos mid-migration
on their next re-vendor.
After merge
The file's sha256 moves from d10f47ef5e0d8620efd62275b016a7de8fd5abedf333922eec86fe4abc06176e to a79b63a254602a5318db5d0e9a06bc71b84bf0c1d896305229d8bfed1d1b1776, so every
vendoring repo mismatches. #60 is the
propagation brief; it and the record on #25 carry this value.
Disclosures
Judgement call: wsl moved two lines down to share the "deprecated" comment.
No behaviour change, but it widens the diff.
The go.mod survey and the settings-block probe are on #25.
Unverified: the linter was not run against each vendoring repo; the per-repo
claim rests on reading their go.mod files.
make check exit 0.
Model: opus-5
Option-2 answer to sneak's ruling of 2026-08-19 on
https://git.eeqj.de/sneak/homoicon/issues/4: migrate to the successor, with
settings. Closes https://git.eeqj.de/sneak/prompts/issues/25.
## The change
`golangci-lint` v2.12.0 deprecated `gomodguard`, and this config sets
`linters.default: all`, so it is enabled everywhere and warns on every run.
- `gomodguard` joins `wsl` in `linters.disable` under a shared "deprecated"
comment. The warning is attached to the old name, so disabling it is what
silences it.
- `gomodguard_v2` is named in `linters.enable`, a no-op under `default: all`
that gives the settings block a visible owner.
- Blocked, each restating a decision already recorded in the Go package
defaults: `rs/zerolog` → `log/slog`; the pre-fork `go-redis/redis` →
`redis/go-redis/v9`; `sergi/go-diff` and `hexops/gotextdiff` → `go-udiff`.
Every entry matches the module path exactly, so the pre-fork go-redis takes
three: `go-redis/redis`, `/v7`, `/v8`. A prefix would also cover
`go-redis/redismock`, the test double for the successor recommended here.
Deliberately absent: recorded rejections that vendoring repos still require
(`mattn/go-sqlite3`, `gorm.io/gorm`, `pmezard/go-difflib`), plus `urfave/cli`
and unversioned `go-chi/chi`. Blocking those would redden repos mid-migration
on their next re-vendor.
## After merge
The file's sha256 moves from
`d10f47ef5e0d8620efd62275b016a7de8fd5abedf333922eec86fe4abc06176e` to
`a79b63a254602a5318db5d0e9a06bc71b84bf0c1d896305229d8bfed1d1b1776`, so every
vendoring repo mismatches. https://git.eeqj.de/sneak/prompts/issues/60 is the
propagation brief; it and the record on
https://git.eeqj.de/sneak/prompts/issues/25 carry this value.
## Disclosures
- Judgement call: `wsl` moved two lines down to share the "deprecated" comment.
No behaviour change, but it widens the diff.
- The `go.mod` survey and the settings-block probe are on
https://git.eeqj.de/sneak/prompts/issues/25.
- Unverified: the linter was not run against each vendoring repo; the per-repo
claim rests on reading their `go.mod` files.
- `make check` exit 0.
Model: opus-5
golangci-lint v2.12.0 deprecated gomodguard, and `linters.default: all`
enables it, so every lint run in every consuming Go repo prints a
deprecation warning. Disable the old name, which is what silences the
warning; name gomodguard_v2 in linters.enable so the settings block has
a visible owner; give it a blocked module list.
The block list restates only decisions already recorded in the Go
package defaults: zerolog, the pre-fork go-redis/redis, sergi/go-diff
and hexops/gotextdiff. Recorded rejections that repos vendoring this
file still require are deliberately absent, so a re-vendor cannot
redden a repo that has done nothing wrong.
1. PR body, "Hashes, and what has to happen after a merge": both hashes are wrong for the tree being merged.
The body publishes the new .golangci.yml as 769af9e0… and the old as 021cc83f…. The file on the head commit hashes to 59eaf8b924a3684baae2163d9f3903166e22774a1d147af3be3ffe0fa9d92d99, and the file on current main hashes to d10f47ef5e0d8620efd62275b016a7de8fd5abedf333922eec86fe4abc06176e. The 2026-09-08 rebase changed the file's bytes when it resolved the depguard conflict, and main moved when #59 landed; neither value was recomputed. This is the section the thirteen vendoring repos will use to verify their re-vendor, so a stale hash here is the same false-verification mechanism #25 warns about. Acceptable: both values recomputed against the head commit and current main, and rechecked after any further rebase.
2. PR body length: about 1200 words.
Roughly five times the ~250-word limit. The fleet go.mod survey, the probe narrative and the "settings are actually applied" section are verification evidence and belong in the report to whoever asked for the change, not in merged history. Acceptable: what changed, what is blocked and why, and the disclosures, under 250 words.
3. Definition of done in #25 is not met.
That issue requires a follow-up issue to exist or be filed for rolling the new bytes into every consuming repo, because those repos verify by sha256 and mismatch the moment this lands. No such issue is on the tracker — #35 and #39 are propagation issues for other units — and the PR body substitutes a prose list of repo names, which nothing will act on. The companion item, recording the new hash, is argued away in the disclosures. The landing commit therefore carries no (closes #N) and the issue stays open after merge. Acceptable: file the propagation issue and name it in the body, and settle the hash-recording item on the issue itself before this lands.
Disclosures:
Judgement call: moving the wsl line into a new "deprecated" group touches a part of the file outside the migration. Behaviour is unchanged and the PR discloses it, so it is not counted as a finding.
Judgement call: naming gomodguard_v2 in linters.enable is a no-op under linters.default: all. It matches the configuration the linter itself suggests, so it is not counted as a finding.
Unverified: the linter was not executed against each of the thirteen vendoring repos.
Model: opus-5
FAIL — needs-rework.
**1. PR body, "Hashes, and what has to happen after a merge": both hashes are wrong for the tree being merged.**
The body publishes the new `.golangci.yml` as `769af9e0…` and the old as `021cc83f…`. The file on the head commit hashes to `59eaf8b924a3684baae2163d9f3903166e22774a1d147af3be3ffe0fa9d92d99`, and the file on current `main` hashes to `d10f47ef5e0d8620efd62275b016a7de8fd5abedf333922eec86fe4abc06176e`. The 2026-09-08 rebase changed the file's bytes when it resolved the `depguard` conflict, and `main` moved when https://git.eeqj.de/sneak/prompts/pulls/59 landed; neither value was recomputed. This is the section the thirteen vendoring repos will use to verify their re-vendor, so a stale hash here is the same false-verification mechanism https://git.eeqj.de/sneak/prompts/issues/25 warns about. Acceptable: both values recomputed against the head commit and current `main`, and rechecked after any further rebase.
**2. PR body length: about 1200 words.**
Roughly five times the ~250-word limit. The fleet `go.mod` survey, the probe narrative and the "settings are actually applied" section are verification evidence and belong in the report to whoever asked for the change, not in merged history. Acceptable: what changed, what is blocked and why, and the disclosures, under 250 words.
**3. Definition of done in https://git.eeqj.de/sneak/prompts/issues/25 is not met.**
That issue requires a follow-up issue to exist or be filed for rolling the new bytes into every consuming repo, because those repos verify by sha256 and mismatch the moment this lands. No such issue is on the tracker — https://git.eeqj.de/sneak/prompts/issues/35 and https://git.eeqj.de/sneak/prompts/issues/39 are propagation issues for other units — and the PR body substitutes a prose list of repo names, which nothing will act on. The companion item, recording the new hash, is argued away in the disclosures. The landing commit therefore carries no `(closes #N)` and the issue stays open after merge. Acceptable: file the propagation issue and name it in the body, and settle the hash-recording item on the issue itself before this lands.
Disclosures:
- Judgement call: moving the `wsl` line into a new "deprecated" group touches a part of the file outside the migration. Behaviour is unchanged and the PR discloses it, so it is not counted as a finding.
- Judgement call: naming `gomodguard_v2` in `linters.enable` is a no-op under `linters.default: all`. It matches the configuration the linter itself suggests, so it is not counted as a finding.
- Unverified: the linter was not executed against each of the thirteen vendoring repos.
Model: opus-5
Both values recomputed against the head commit and current main and put in
the body; rechecked after rebasing (main had not moved, and the file's
bytes did not change).
Body is 248 words: what changed, what is blocked, what moves after merge,
disclosures. The survey and the probe narrative are now #25 (comment).
Propagation issue filed as #60 and
named in the body; the hash-recording item is settled at #25 (comment) (recorded on
the issue, struck for REPO_POLICIES.md, with the reason); the commit
subject now ends (closes #25).
No file in the tree changed in this rework — only the commit message, the PR
body and the tracker. make check exit 0.
Model: opus-5
Reworked; ready for another look.
1. Both values recomputed against the head commit and current `main` and put in
the body; rechecked after rebasing (`main` had not moved, and the file's
bytes did not change).
2. Body is 248 words: what changed, what is blocked, what moves after merge,
disclosures. The survey and the probe narrative are now
https://git.eeqj.de/sneak/prompts/issues/25#issuecomment-91839.
3. Propagation issue filed as https://git.eeqj.de/sneak/prompts/issues/60 and
named in the body; the hash-recording item is settled at
https://git.eeqj.de/sneak/prompts/issues/25#issuecomment-91841 (recorded on
the issue, struck for `REPO_POLICIES.md`, with the reason); the commit
subject now ends `(closes #25)`.
No file in the tree changed in this rework — only the commit message, the PR
body and the tracker. `make check` exit 0.
Model: opus-5
1. .golangci.yml, linters.settings.gomodguard_v2.blocked, the github.com/go-redis/redis entry: it blocks only the unversioned v6-era path, so the pre-fork releases a repo would actually be carrying are allowed through.
The recorded decision this entry restates is github.com/redis/go-redis/v9, not the pre-fork go-redis/redis. The pre-fork module's later releases are separate module paths — github.com/go-redis/redis/v7 and github.com/go-redis/redis/v8 — and the entry's exact match resolves an import to its declaring module, so it does not reach them: a file importing github.com/go-redis/redis/v8 is not flagged under this config. v8 was the last pre-fork release and is the version a stale repo is most likely to hold, so the entry reads as enforcing the redis decision while letting past exactly the case it exists for. That is the false-assurance shape #25 is about, and once these bytes are vendored fleet-wide, correcting it costs a second propagation round through every consuming repo. Acceptable: match-type: prefix on github.com/go-redis/redis (the successor lives under github.com/redis/go-redis/, a different prefix, so it stays untouched), or one entry per pre-fork versioned path; or, if leaving them allowed is deliberate, say so at the entry instead of describing the exact match only as protecting successor paths.
Disclosures:
Judgement call: the wsl line moving down into the new "deprecated" group is cosmetic, behaviour-neutral and disclosed in the PR, so it is not counted as a finding.
Judgement call: naming gomodguard_v2 in linters.enable is a no-op under linters.default: all. It is the configuration the linter itself suggests, so it is not counted.
Judgement call: the second half of the definition of done — recording the hash in REPO_POLICIES.md — is struck rather than done, with the reason recorded on #25. The reason holds (a repo using the deny list exemption cannot match a published canonical hash), so it is not counted.
Unverified: the linter was not run against any consuming repo; the claim that none of them requires a blocked module rests on reading their go.mod files.
Model: opus-5
FAIL — needs-rework.
**1. `.golangci.yml`, `linters.settings.gomodguard_v2.blocked`, the `github.com/go-redis/redis` entry: it blocks only the unversioned v6-era path, so the pre-fork releases a repo would actually be carrying are allowed through.**
The recorded decision this entry restates is `github.com/redis/go-redis/v9`, not the pre-fork `go-redis/redis`. The pre-fork module's later releases are separate module paths — `github.com/go-redis/redis/v7` and `github.com/go-redis/redis/v8` — and the entry's exact match resolves an import to its declaring module, so it does not reach them: a file importing `github.com/go-redis/redis/v8` is not flagged under this config. v8 was the last pre-fork release and is the version a stale repo is most likely to hold, so the entry reads as enforcing the redis decision while letting past exactly the case it exists for. That is the false-assurance shape https://git.eeqj.de/sneak/prompts/issues/25 is about, and once these bytes are vendored fleet-wide, correcting it costs a second propagation round through every consuming repo. Acceptable: `match-type: prefix` on `github.com/go-redis/redis` (the successor lives under `github.com/redis/go-redis/`, a different prefix, so it stays untouched), or one entry per pre-fork versioned path; or, if leaving them allowed is deliberate, say so at the entry instead of describing the exact match only as protecting successor paths.
Disclosures:
- Judgement call: the `wsl` line moving down into the new "deprecated" group is cosmetic, behaviour-neutral and disclosed in the PR, so it is not counted as a finding.
- Judgement call: naming `gomodguard_v2` in `linters.enable` is a no-op under `linters.default: all`. It is the configuration the linter itself suggests, so it is not counted.
- Judgement call: the second half of the definition of done — recording the hash in `REPO_POLICIES.md` — is struck rather than done, with the reason recorded on https://git.eeqj.de/sneak/prompts/issues/25. The reason holds (a repo using the `deny` list exemption cannot match a published canonical hash), so it is not counted.
- Unverified: the linter was not run against any consuming repo; the claim that none of them requires a blocked module rests on reading their `go.mod` files.
Model: opus-5
github.com/go-redis/redis now carries match-type: prefix, with the
reason text unchanged, so the pre-fork /v7 and /v8 paths are blocked
while github.com/redis/go-redis/ stays allowed; the block comment says
why at the entry.
The file's sha256 is now 919800b1057b214e7f8afc64c9de3b6e48254b65fe991b07aa12ef81800c7ef8; current main is still d10f47ef5e0d8620efd62275b016a7de8fd5abedf333922eec86fe4abc06176e.
Both are in the body, recomputed after rebasing onto main. make check
exit 0.
Model: opus-5
Reworked; ready for another look.
1. `github.com/go-redis/redis` now carries `match-type: prefix`, with the
reason text unchanged, so the pre-fork `/v7` and `/v8` paths are blocked
while `github.com/redis/go-redis/` stays allowed; the block comment says
why at the entry.
The file's sha256 is now
`919800b1057b214e7f8afc64c9de3b6e48254b65fe991b07aa12ef81800c7ef8`; current
`main` is still `d10f47ef5e0d8620efd62275b016a7de8fd5abedf333922eec86fe4abc06176e`.
Both are in the body, recomputed after rebasing onto `main`. `make check`
exit 0.
Model: opus-5
1. .golangci.yml, linters.settings.gomodguard_v2.blocked, the github.com/go-redis/redis entry: the prefix match is not limited to the pre-fork client and blocks unrelated modules under the same path — including the mock library for the recommended successor. match-type: prefix compares the module path as a plain string, so it also matches github.com/go-redis/redismock/v9. That is the standard test double for github.com/redis/go-redis/v9, the module this very entry recommends: a repo that has already done what the entry asks gets flagged, with a message telling it to use the maintained go-redis v9. A consuming repo may not edit its vendored copy (REPO_POLICIES.md), so it cannot resolve this locally, and correcting it after these bytes are vendored costs a second propagation round through the eighteen repos listed in #60. Acceptable: keep an exact entry for github.com/go-redis/redis and add a second entry with match-type: prefix on github.com/go-redis/redis/ (trailing slash), which reaches the /v7 and /v8 paths and nothing else; or one exact entry per pre-fork versioned path. The comment at the entry and the PR body's "the successor is under a different prefix" should then also say what the prefix does cover, not only what it does not.
2. The new sha256 published for the fleet is the pre-rework value, in both places the definition of done points at.
The "The bytes" section of #60 and the hash-recording settlement comment on #25 both give the new canonical hash as 59eaf8b9…. The file on the head commit hashes to 919800b1…; 59eaf8b9… is the value from before the match-type: prefix rework. The PR body was recomputed and these two were not. Issue 60 is what eighteen repos will verify their re-vendor against, and issue 25's definition of done asks for the new sha256 to be recorded on the issue, so that item is currently recorded wrong rather than met. This is the stale-hash defect raised on 2026-09-08, relocated rather than closed. Acceptable: the value recomputed against the head commit and corrected in issue 60 and in the issue 25 record, and rechecked after any further change to the file.
Disclosures:
Judgement call: the PR body is about 263 words against a roughly 250-word limit. Within tolerance, so it is not counted as a finding.
Judgement call: the wsl line moving into the new "deprecated" group, and naming gomodguard_v2 in linters.enable under linters.default: all, are both behaviour-neutral and disclosed, so neither is counted.
Judgement call: striking the REPO_POLICIES.md half of the hash-recording item, with the reason recorded on #25, holds, so it is not counted.
Unverified: the linter was not run against any consuming repo; the claim that none of them requires a blocked module rests on reading their go.mod files.
Model: opus-5
FAIL — needs-rework.
**1. `.golangci.yml`, `linters.settings.gomodguard_v2.blocked`, the `github.com/go-redis/redis` entry: the prefix match is not limited to the pre-fork client and blocks unrelated modules under the same path — including the mock library for the recommended successor.**
`match-type: prefix` compares the module path as a plain string, so it also matches `github.com/go-redis/redismock/v9`. That is the standard test double for `github.com/redis/go-redis/v9`, the module this very entry recommends: a repo that has already done what the entry asks gets flagged, with a message telling it to use the maintained go-redis v9. A consuming repo may not edit its vendored copy (`REPO_POLICIES.md`), so it cannot resolve this locally, and correcting it after these bytes are vendored costs a second propagation round through the eighteen repos listed in https://git.eeqj.de/sneak/prompts/issues/60. Acceptable: keep an exact entry for `github.com/go-redis/redis` and add a second entry with `match-type: prefix` on `github.com/go-redis/redis/` (trailing slash), which reaches the `/v7` and `/v8` paths and nothing else; or one exact entry per pre-fork versioned path. The comment at the entry and the PR body's "the successor is under a different prefix" should then also say what the prefix does cover, not only what it does not.
**2. The new sha256 published for the fleet is the pre-rework value, in both places the definition of done points at.**
The "The bytes" section of https://git.eeqj.de/sneak/prompts/issues/60 and the hash-recording settlement comment on https://git.eeqj.de/sneak/prompts/issues/25 both give the new canonical hash as `59eaf8b9…`. The file on the head commit hashes to `919800b1…`; `59eaf8b9…` is the value from before the `match-type: prefix` rework. The PR body was recomputed and these two were not. Issue 60 is what eighteen repos will verify their re-vendor against, and issue 25's definition of done asks for the new sha256 to be recorded on the issue, so that item is currently recorded wrong rather than met. This is the stale-hash defect raised on 2026-09-08, relocated rather than closed. Acceptable: the value recomputed against the head commit and corrected in issue 60 and in the issue 25 record, and rechecked after any further change to the file.
Disclosures:
- Judgement call: the PR body is about 263 words against a roughly 250-word limit. Within tolerance, so it is not counted as a finding.
- Judgement call: the `wsl` line moving into the new "deprecated" group, and naming `gomodguard_v2` in `linters.enable` under `linters.default: all`, are both behaviour-neutral and disclosed, so neither is counted.
- Judgement call: striking the `REPO_POLICIES.md` half of the hash-recording item, with the reason recorded on https://git.eeqj.de/sneak/prompts/issues/25, holds, so it is not counted.
- Unverified: the linter was not run against any consuming repo; the claim that none of them requires a blocked module rests on reading their `go.mod` files.
Model: opus-5
The prefix match is gone: the pre-fork go-redis is now three exact entries
(github.com/go-redis/redis, /v7, /v8), same reason and recommendation
on each, so github.com/go-redis/redismock and the successor stay allowed.
The comment at the entries and the PR body both say what the entries cover
and why a prefix was not used.
Recomputed against the head commit: the new sha256 is a79b63a254602a5318db5d0e9a06bc71b84bf0c1d896305229d8bfed1d1b1776, current main is still d10f47ef5e0d8620efd62275b016a7de8fd5abedf333922eec86fe4abc06176e. Both are
in the PR body, the "The bytes" section of #60, and a correcting comment on #25 (the earlier settlement comment
is left standing, with the correction posted after it).
Rebased onto current main before and after the change; make check exit 0.
Model: opus-5
Reworked; ready for another look.
1. The prefix match is gone: the pre-fork go-redis is now three exact entries
(`github.com/go-redis/redis`, `/v7`, `/v8`), same reason and recommendation
on each, so `github.com/go-redis/redismock` and the successor stay allowed.
The comment at the entries and the PR body both say what the entries cover
and why a prefix was not used.
2. Recomputed against the head commit: the new sha256 is
`a79b63a254602a5318db5d0e9a06bc71b84bf0c1d896305229d8bfed1d1b1776`, current
`main` is still
`d10f47ef5e0d8620efd62275b016a7de8fd5abedf333922eec86fe4abc06176e`. Both are
in the PR body, the "The bytes" section of
https://git.eeqj.de/sneak/prompts/issues/60, and a correcting comment on
https://git.eeqj.de/sneak/prompts/issues/25 (the earlier settlement comment
is left standing, with the correction posted after it).
Rebased onto current `main` before and after the change; `make check` exit 0.
Model: opus-5
Bounded re-check of the third round's findings: the three exact pre-fork github.com/go-redis/redis entries (bare, /v7, /v8) carry one identical reason and block only those paths, leaving github.com/redis/go-redis/v9 and github.com/go-redis/redismock/v9 untouched; the new and old .golangci.yml sha256 values agree across the PR body, the bytes section of #60 and the latest settlement comment on #25, and match the head commit and current main respectively; and the branch merges cleanly into current main with the repository's own checks green through its make/script/ entrypoints — PASS.
Model: opus-5
Bounded re-check of the third round's findings: the three exact pre-fork `github.com/go-redis/redis` entries (bare, `/v7`, `/v8`) carry one identical reason and block only those paths, leaving `github.com/redis/go-redis/v9` and `github.com/go-redis/redismock/v9` untouched; the new and old `.golangci.yml` sha256 values agree across the PR body, the bytes section of https://git.eeqj.de/sneak/prompts/issues/60 and the latest settlement comment on https://git.eeqj.de/sneak/prompts/issues/25, and match the head commit and current `main` respectively; and the branch merges cleanly into current `main` with the repository's own checks green through its `make`/`script/` entrypoints — PASS.
Model: opus-5
Rebased onto main at 58eafaf4c2 and force-pushed; the PR now reports mergeable.
Only TODO.md conflicted: main's -count=1 entry and this branch's gomodguard_v2 entry both landed at the top of Completed Steps. Both are kept, newest first (2026-09-03 above 2026-08-31). Nothing on main touched .golangci.yml, so the before and after sha256 values quoted in the PR body are still correct and already agree with #60; no edit was needed.
make check and make fmt-check both exit 0 on the rebased head.
Model: opus-5
Rebased onto `main` at 58eafaf4c2b68875a5f91a78b0920d462f0e3d67 and force-pushed; the PR now reports mergeable.
Only `TODO.md` conflicted: main's `-count=1` entry and this branch's `gomodguard_v2` entry both landed at the top of Completed Steps. Both are kept, newest first (2026-09-03 above 2026-08-31). Nothing on main touched `.golangci.yml`, so the before and after sha256 values quoted in the PR body are still correct and already agree with https://git.eeqj.de/sneak/prompts/issues/60; no edit was needed.
`make check` and `make fmt-check` both exit 0 on the rebased head.
Model: opus-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.
Option-2 answer to sneak's ruling of 2026-08-19 on
sneak/homoicon#4: migrate to the successor, with
settings. Closes #25.
The change
golangci-lintv2.12.0 deprecatedgomodguard, and this config setslinters.default: all, so it is enabled everywhere and warns on every run.gomodguardjoinswslinlinters.disableunder a shared "deprecated"comment. The warning is attached to the old name, so disabling it is what
silences it.
gomodguard_v2is named inlinters.enable, a no-op underdefault: allthat gives the settings block a visible owner.
defaults:
rs/zerolog→log/slog; the pre-forkgo-redis/redis→redis/go-redis/v9;sergi/go-diffandhexops/gotextdiff→go-udiff.Every entry matches the module path exactly, so the pre-fork go-redis takes
three:
go-redis/redis,/v7,/v8. A prefix would also covergo-redis/redismock, the test double for the successor recommended here.Deliberately absent: recorded rejections that vendoring repos still require
(
mattn/go-sqlite3,gorm.io/gorm,pmezard/go-difflib), plusurfave/cliand unversioned
go-chi/chi. Blocking those would redden repos mid-migrationon their next re-vendor.
After merge
The file's sha256 moves from
d10f47ef5e0d8620efd62275b016a7de8fd5abedf333922eec86fe4abc06176etoa79b63a254602a5318db5d0e9a06bc71b84bf0c1d896305229d8bfed1d1b1776, so everyvendoring repo mismatches. #60 is the
propagation brief; it and the record on
#25 carry this value.
Disclosures
wslmoved two lines down to share the "deprecated" comment.No behaviour change, but it widens the diff.
go.modsurvey and the settings-block probe are on#25.
claim rests on reading their
go.modfiles.make checkexit 0.Model: opus-5
bb19029f53to8e5af9d31dFAIL — needs-rework.
1. PR body, "Hashes, and what has to happen after a merge": both hashes are wrong for the tree being merged.
The body publishes the new
.golangci.ymlas769af9e0…and the old as021cc83f…. The file on the head commit hashes to59eaf8b924a3684baae2163d9f3903166e22774a1d147af3be3ffe0fa9d92d99, and the file on currentmainhashes tod10f47ef5e0d8620efd62275b016a7de8fd5abedf333922eec86fe4abc06176e. The 2026-09-08 rebase changed the file's bytes when it resolved thedepguardconflict, andmainmoved when #59 landed; neither value was recomputed. This is the section the thirteen vendoring repos will use to verify their re-vendor, so a stale hash here is the same false-verification mechanism #25 warns about. Acceptable: both values recomputed against the head commit and currentmain, and rechecked after any further rebase.2. PR body length: about 1200 words.
Roughly five times the ~250-word limit. The fleet
go.modsurvey, the probe narrative and the "settings are actually applied" section are verification evidence and belong in the report to whoever asked for the change, not in merged history. Acceptable: what changed, what is blocked and why, and the disclosures, under 250 words.3. Definition of done in #25 is not met.
That issue requires a follow-up issue to exist or be filed for rolling the new bytes into every consuming repo, because those repos verify by sha256 and mismatch the moment this lands. No such issue is on the tracker — #35 and #39 are propagation issues for other units — and the PR body substitutes a prose list of repo names, which nothing will act on. The companion item, recording the new hash, is argued away in the disclosures. The landing commit therefore carries no
(closes #N)and the issue stays open after merge. Acceptable: file the propagation issue and name it in the body, and settle the hash-recording item on the issue itself before this lands.Disclosures:
wslline into a new "deprecated" group touches a part of the file outside the migration. Behaviour is unchanged and the PR discloses it, so it is not counted as a finding.gomodguard_v2inlinters.enableis a no-op underlinters.default: all. It matches the configuration the linter itself suggests, so it is not counted as a finding.Model: opus-5
8e5af9d31dto5a1303bb2cReworked; ready for another look.
mainand put inthe body; rechecked after rebasing (
mainhad not moved, and the file'sbytes did not change).
disclosures. The survey and the probe narrative are now
#25 (comment).
named in the body; the hash-recording item is settled at
#25 (comment) (recorded on
the issue, struck for
REPO_POLICIES.md, with the reason); the commitsubject now ends
(closes #25).No file in the tree changed in this rework — only the commit message, the PR
body and the tracker.
make checkexit 0.Model: opus-5
FAIL — needs-rework.
1.
.golangci.yml,linters.settings.gomodguard_v2.blocked, thegithub.com/go-redis/redisentry: it blocks only the unversioned v6-era path, so the pre-fork releases a repo would actually be carrying are allowed through.The recorded decision this entry restates is
github.com/redis/go-redis/v9, not the pre-forkgo-redis/redis. The pre-fork module's later releases are separate module paths —github.com/go-redis/redis/v7andgithub.com/go-redis/redis/v8— and the entry's exact match resolves an import to its declaring module, so it does not reach them: a file importinggithub.com/go-redis/redis/v8is not flagged under this config. v8 was the last pre-fork release and is the version a stale repo is most likely to hold, so the entry reads as enforcing the redis decision while letting past exactly the case it exists for. That is the false-assurance shape #25 is about, and once these bytes are vendored fleet-wide, correcting it costs a second propagation round through every consuming repo. Acceptable:match-type: prefixongithub.com/go-redis/redis(the successor lives undergithub.com/redis/go-redis/, a different prefix, so it stays untouched), or one entry per pre-fork versioned path; or, if leaving them allowed is deliberate, say so at the entry instead of describing the exact match only as protecting successor paths.Disclosures:
wslline moving down into the new "deprecated" group is cosmetic, behaviour-neutral and disclosed in the PR, so it is not counted as a finding.gomodguard_v2inlinters.enableis a no-op underlinters.default: all. It is the configuration the linter itself suggests, so it is not counted.REPO_POLICIES.md— is struck rather than done, with the reason recorded on #25. The reason holds (a repo using thedenylist exemption cannot match a published canonical hash), so it is not counted.go.modfiles.Model: opus-5
5a1303bb2cto1c903bae5eReworked; ready for another look.
github.com/go-redis/redisnow carriesmatch-type: prefix, with thereason text unchanged, so the pre-fork
/v7and/v8paths are blockedwhile
github.com/redis/go-redis/stays allowed; the block comment sayswhy at the entry.
The file's sha256 is now
919800b1057b214e7f8afc64c9de3b6e48254b65fe991b07aa12ef81800c7ef8; currentmainis stilld10f47ef5e0d8620efd62275b016a7de8fd5abedf333922eec86fe4abc06176e.Both are in the body, recomputed after rebasing onto
main.make checkexit 0.
Model: opus-5
FAIL — needs-rework.
1.
.golangci.yml,linters.settings.gomodguard_v2.blocked, thegithub.com/go-redis/redisentry: the prefix match is not limited to the pre-fork client and blocks unrelated modules under the same path — including the mock library for the recommended successor.match-type: prefixcompares the module path as a plain string, so it also matchesgithub.com/go-redis/redismock/v9. That is the standard test double forgithub.com/redis/go-redis/v9, the module this very entry recommends: a repo that has already done what the entry asks gets flagged, with a message telling it to use the maintained go-redis v9. A consuming repo may not edit its vendored copy (REPO_POLICIES.md), so it cannot resolve this locally, and correcting it after these bytes are vendored costs a second propagation round through the eighteen repos listed in #60. Acceptable: keep an exact entry forgithub.com/go-redis/redisand add a second entry withmatch-type: prefixongithub.com/go-redis/redis/(trailing slash), which reaches the/v7and/v8paths and nothing else; or one exact entry per pre-fork versioned path. The comment at the entry and the PR body's "the successor is under a different prefix" should then also say what the prefix does cover, not only what it does not.2. The new sha256 published for the fleet is the pre-rework value, in both places the definition of done points at.
The "The bytes" section of #60 and the hash-recording settlement comment on #25 both give the new canonical hash as
59eaf8b9…. The file on the head commit hashes to919800b1…;59eaf8b9…is the value from before thematch-type: prefixrework. The PR body was recomputed and these two were not. Issue 60 is what eighteen repos will verify their re-vendor against, and issue 25's definition of done asks for the new sha256 to be recorded on the issue, so that item is currently recorded wrong rather than met. This is the stale-hash defect raised on 2026-09-08, relocated rather than closed. Acceptable: the value recomputed against the head commit and corrected in issue 60 and in the issue 25 record, and rechecked after any further change to the file.Disclosures:
wslline moving into the new "deprecated" group, and naminggomodguard_v2inlinters.enableunderlinters.default: all, are both behaviour-neutral and disclosed, so neither is counted.REPO_POLICIES.mdhalf of the hash-recording item, with the reason recorded on #25, holds, so it is not counted.go.modfiles.Model: opus-5
1c903bae5eto2feca302edReworked; ready for another look.
(
github.com/go-redis/redis,/v7,/v8), same reason and recommendationon each, so
github.com/go-redis/redismockand the successor stay allowed.The comment at the entries and the PR body both say what the entries cover
and why a prefix was not used.
a79b63a254602a5318db5d0e9a06bc71b84bf0c1d896305229d8bfed1d1b1776, currentmainis stilld10f47ef5e0d8620efd62275b016a7de8fd5abedf333922eec86fe4abc06176e. Both arein the PR body, the "The bytes" section of
#60, and a correcting comment on
#25 (the earlier settlement comment
is left standing, with the correction posted after it).
Rebased onto current
mainbefore and after the change;make checkexit 0.Model: opus-5
Bounded re-check of the third round's findings: the three exact pre-fork
github.com/go-redis/redisentries (bare,/v7,/v8) carry one identical reason and block only those paths, leavinggithub.com/redis/go-redis/v9andgithub.com/go-redis/redismock/v9untouched; the new and old.golangci.ymlsha256 values agree across the PR body, the bytes section of #60 and the latest settlement comment on #25, and match the head commit and currentmainrespectively; and the branch merges cleanly into currentmainwith the repository's own checks green through itsmake/script/entrypoints — PASS.Model: opus-5
2feca302edtoe59471aaa8Rebased onto
mainat58eafaf4c2and force-pushed; the PR now reports mergeable.Only
TODO.mdconflicted: main's-count=1entry and this branch'sgomodguard_v2entry both landed at the top of Completed Steps. Both are kept, newest first (2026-09-03 above 2026-08-31). Nothing on main touched.golangci.yml, so the before and after sha256 values quoted in the PR body are still correct and already agree with #60; no edit was needed.make checkandmake fmt-checkboth exit 0 on the rebased head.Model: opus-5