Skip to content

chore: tidy guards and pins - #295

Merged
dinstein merged 4 commits into
mainfrom
chore/tidy-guards-and-pins
Aug 10, 2026
Merged

chore: tidy guards and pins#295
dinstein merged 4 commits into
mainfrom
chore/tidy-guards-and-pins

Conversation

@dinstein

Copy link
Copy Markdown
Owner

Four independent tidy fixes: fuzz-target prose count, a missing depguard probe, a stale doc line pin, and an unpinned cross-file correspondence.

  • 1. Makefile fuzz inventory prose named only seven targets (and so did a test/buildrules comment) while FUZZ_TARGETS and AGENTS.md carry eight — add FuzzDecodeHeaderValue to the prose, fix both counts, and add a test asserting every FUZZ_TARGETS entry is named in the prose above it.
  • 2. guard-zero-dep was the one hard-constraint depguard rule with no failing-case probe (canonical.md §6). Add rule4_guard_zero_dep to internal/depguardtest, shaped like the existing platform/logx probes, and update canonical.md §6 to record it proven.
  • 3. docs/modules/config.md pinned the dropChanged defect to a line number that has since moved; per docs/modules/README.md's stated preference, name the function instead of the line.
  • 4. Taskfile.yml and the Makefile each spell the GIT_HASH computation independently, held together only by a comment. Add a test/buildrules correspondence test asserting both files contain the same git rev-parse/-dirty snippet.

Verification: make fmt, make ci, and make ci-depguard-proof (for #2) all green.

dinstein and others added 4 commits August 10, 2026 11:46
The FUZZ_TARGETS inventory comment above the Makefile's list, and a
comment in test/buildrules/fuzzregistry_test.go, both still said "the
seven targets" after FuzzDecodeHeaderValue became the eighth entry in
FUZZ_TARGETS and in AGENTS.md's canonical list — a reader trusting either
comment undercounted what `make fuzz` actually runs.

Both prose spots now say eight and the Makefile's inventory gains the
missing FuzzDecodeHeaderValue entry, matching AGENTS.md's wording. Also
adds TestMakefileProseNamesEveryFuzzTarget, asserting every FUZZ_TARGETS
entry's name appears in the prose above it, so the count cannot drift out
from under the list again without a test catching it.

Verified with `go test ./test/buildrules/...`.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013pF7N8qiPEEKDHC9mxBRQm
canonical.md §6 recorded guard-zero-dep as the one hard-constraint rule
with no failing case: platform-zero-dep and logx-zero-dep each had a probe
proving golangci-lint blocks a business import, but the third leg of §2
rule 4 — internal/guard/** — had nothing showing its identical-looking
depguard rule was actually in effect. A rule that is configured and looks
proven is the shape AGENTS.md calls worse than no rule at all.

Adds rule4_guard_zero_dep to internal/depguardtest, shaped exactly like
the platform and logx probes: a probe importing github.com/spf13/cobra
under internal/guard, asserted blocked, plus a clean control asserted to
pass. canonical.md §6 now records six of seven rules proven, leaving only
no-third-party-mcp-libs — which this harness cannot probe without a fake
module — as the recorded gap.

Verified with `make ci-depguard-proof`.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013pF7N8qiPEEKDHC9mxBRQm
docs/modules/config.md pinned the dropChanged defect to
clients/jsonc.go:535, but the function has since moved to line 548 —
exactly the rot docs/modules/README.md warns about: a pin is a number in
prose, and nothing in `make ci` notices when a citation lands on the
wrong line after a nearby edit.

docs/modules/README.md prefers naming the function over pinning a line
number, keeping the number only where it saves a search that naming
cannot. Here the function name alone finds it, so the citation now reads
`clients/jsonc.go`'s `dropChanged` with no line number to go stale again.

Verified with `go test ./test/buildrules/...`.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013pF7N8qiPEEKDHC9mxBRQm
Taskfile.yml and the Makefile each compute GIT_HASH independently — one
feeds a `task`-driven wails3 GUI build, the other every `make` build — and
the only thing holding the two recipes in step was a comment on each side
reading "Must match the Makefile's GIT_HASH". Nothing stopped the shell
fragment itself from drifting while the comment stayed put, which would
mean a GUI build and a CLI build of the same commit mint different
version strings.

Adds TestGitHashRecipeMatchesAcrossBuilds, following the shape of this
package's other cross-file correspondence tests (e.g.
TestCIWorkflowDoesNotReimplementAMakeTarget): it checks for the two git
commands themselves — the `rev-parse --short=7` and the `diff --quiet`
dirty check — in both files, since those are identical text even though
each file wraps them in different shell syntax.

Verified with `go test ./test/buildrules/...`.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013pF7N8qiPEEKDHC9mxBRQm
@dinstein
dinstein force-pushed the chore/tidy-guards-and-pins branch from fba3bd4 to 57ba096 Compare August 10, 2026 03:46
@dinstein
dinstein marked this pull request as ready for review August 10, 2026 03:46
@dinstein
dinstein merged commit 57ba096 into main Aug 10, 2026
3 checks passed
@dinstein
dinstein deleted the chore/tidy-guards-and-pins branch August 10, 2026 03:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant