The go-test pre-commit hook is red on a clean checkout, which trains agents to bypass it

go-test in .pre-commit-config.yaml runs go test -short ./... over the whole project. The script names no build tag, but GOFLAGS carries -tags=integration,development_stubs in the environment and a hook subprocess inherits it, so the hook does compile and run the integration suite. -short narrows almost nothing here: one file in all of internal/ checks testing.Short(), and none of the 108 *_integration_test.go files under internal/datastore/ does.

On a developer or agent machine the hook fails without any local change, so a commit that touches Go cannot pass the hook chain.

Observed on 2026-08-19, on a clean worktree of main plus a four-file change confined to cmd/artifact-registry: four packages hit panic: test timed out after 10m0s — cmd/artifact-registry, internal/datastore, internal/datastore/migrations, and internal/storage/driver/s3. Three contain no file the change touched. go test -short ./internal/storage/driver/s3/ -count=1 -timeout 120s hangs to timeout on its own, with ar-run-pg and ar-run-minio both up, so it is not a missing-backend problem — those suites hang rather than skip when their backend configuration is absent. cmd/artifact-registry passes standalone in 193s and times out only inside the full parallel run.

The cost is not the failed hook. It is that the only ways past it are --no-verify, which CLAUDE.md guardrail 9 forbids, or a targeted SKIP=go-test. A hook that is red for reasons unrelated to the change teaches every contributor who meets it to reach for the flag the guardrail exists to prevent, and the next person to do it will be bypassing a hook that would have caught something.

Two directions, either of which removes the incentive:

• Scope the hook to the packages the commit touches, so an unrelated hanging suite cannot block an unrelated change.
• Make the suites that need a backend skip when it is absent, rather than hang to the timeout.

A second defect in the same area

A fresh git worktree starts with go-test and golangci-lint non-functional. Both fail with mise ERROR Config files ... are not trusted until mise trust is run on the worktree. That failure is loud, so nothing skips silently.

What keeps it unnoticed is which commits fire the two hooks. Both are Go hooks, so a Markdown-only commit reports (no files to check) and the worktree looks healthy. In one session on 2026-08-19 two Markdown-only commits passed in a worktree where both hooks were already broken, and the failure surfaced only when the next commit touched Go. Three agent worktrees hit the trust failure that day.

So the two defects compound. A contributor meets the trust failure first, fixes it with mise trust, and then meets a go-test hook that is red anyway — at which point the only remaining move is the one the guardrail forbids.