sneak/prompts
1
0
Fork 0
Code Issues 10 Pull Requests Actions Packages Projects Releases Wiki Activity

Migrate canonical .golangci.yml to gomodguard_v2, with a block list #55

Merged
sneak merged 2 commits from gomodguard-v2-with-settings into main 2026-09-09 14:04:19 +02:00
Conversation 8 Commits 2 Files Changed 2 +45 -1
clawbot commented 2026-08-31 03:54:50 +02:00
Collaborator
Copy Link

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
clawbot added the needs-review label 2026-08-31 03:54:50 +02:00
sneak was assigned by clawbot 2026-08-31 03:54:50 +02:00
clawbot added 1 commit 2026-08-31 03:54:51 +02:00
Migrate canonical .golangci.yml to gomodguard_v2 with a block list
All checks were successful
check / check (push) Successful in 9s
Details
bb19029f53 
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.
sneak was unassigned by clawbot 2026-09-03 20:29:47 +02:00
clawbot self-assigned this 2026-09-03 20:29:48 +02:00
clawbot added needs-rework and removed needs-review labels 2026-09-03 22:59:53 +02:00
clawbot removed their assignment 2026-09-03 23:38:12 +02:00
sneak was assigned by clawbot 2026-09-03 23:38:12 +02:00
sneak was unassigned by clawbot 2026-09-08 05:16:03 +02:00
clawbot self-assigned this 2026-09-08 05:16:03 +02:00
clawbot force-pushed gomodguard-v2-with-settings from bb19029f53 to 8e5af9d31d 2026-09-08 06:16:27 +02:00 Compare
clawbot added needs-review and removed needs-rework labels 2026-09-08 06:16:52 +02:00
clawbot commented 2026-09-08 06:28:16 +02:00
Author
Collaborator
Copy Link

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 #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
clawbot added needs-rework and removed needs-review labels 2026-09-08 06:35:04 +02:00
clawbot force-pushed gomodguard-v2-with-settings from 8e5af9d31d to 5a1303bb2c 2026-09-08 06:41:26 +02:00 Compare
clawbot added needs-review and removed needs-rework labels 2026-09-08 06:41:40 +02:00
clawbot commented 2026-09-08 06:41:56 +02:00
Author
Collaborator
Copy Link

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
    #25 (comment).
  3. 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
clawbot commented 2026-09-08 07:01:36 +02:00
Author
Collaborator
Copy Link

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 #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
clawbot added needs-rework and removed needs-review labels 2026-09-08 07:05:00 +02:00
clawbot force-pushed gomodguard-v2-with-settings from 5a1303bb2c to 1c903bae5e 2026-09-08 07:07:54 +02:00 Compare
clawbot commented 2026-09-08 07:08:28 +02:00
Author
Collaborator
Copy Link

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

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
clawbot added needs-review and removed needs-rework labels 2026-09-08 07:08:28 +02:00
clawbot commented 2026-09-08 07:28:14 +02:00
Author
Collaborator
Copy Link

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 #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
clawbot added needs-rework and removed needs-review labels 2026-09-08 07:35:11 +02:00
clawbot force-pushed gomodguard-v2-with-settings from 1c903bae5e to 2feca302ed 2026-09-08 07:38:27 +02:00 Compare
clawbot commented 2026-09-08 07:40:06 +02:00
Author
Collaborator
Copy Link

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
    #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
clawbot added needs-review and removed needs-rework labels 2026-09-08 07:40:11 +02:00
clawbot commented 2026-09-08 07:52:50 +02:00
Author
Collaborator
Copy Link

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
clawbot added merge-ready and removed needs-review labels 2026-09-08 08:05:13 +02:00
clawbot removed their assignment 2026-09-08 08:05:13 +02:00
sneak was assigned by clawbot 2026-09-08 08:05:14 +02:00
clawbot removed the merge-ready label 2026-09-09 13:43:26 +02:00
sneak was unassigned by clawbot 2026-09-09 13:43:30 +02:00
clawbot self-assigned this 2026-09-09 13:43:30 +02:00
clawbot force-pushed gomodguard-v2-with-settings from 2feca302ed to e59471aaa8 2026-09-09 13:46:06 +02:00 Compare
clawbot commented 2026-09-09 13:46:37 +02:00
Author
Collaborator
Copy Link

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
clawbot added the merge-ready label 2026-09-09 13:46:37 +02:00
clawbot removed their assignment 2026-09-09 13:46:37 +02:00
sneak was assigned by clawbot 2026-09-09 13:46:38 +02:00
sneak added 1 commit 2026-09-09 14:03:15 +02:00
Merge branch 'main' into gomodguard-v2-with-settings
All checks were successful
check / check (push) Successful in 29s
Details
207e8148d1
sneak merged commit ed5ed236b1 into main 2026-09-09 14:04:19 +02:00
sneak deleted branch gomodguard-v2-with-settings 2026-09-09 14:04:19 +02:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
merge-ready
PR approved and ready to merge
 needs-review
PR needs code review
 needs-rework
PR needs changes based on review
No Label merge-ready
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
clawbot sneak
No Assignees sneak
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/prompts#55
Delete Branch "gomodguard-v2-with-settings"

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?