[topcoder1]

What was wrong

coverage-floor.yml's detect step read only go.mod's go directive and gave it to actions/setup-go as an exact version. setup-go then exports GOTOOLCHAIN=local (its setGoToolchain()), so go runs whatever was installed and skips go.mod's toolchain line. A repo that pins a patched toolchain had its required coverage lane measured on the unpatched floor, green and with no warning.

Seen on whois-api-llc/techrecon, which pins toolchain go1.26.10 for GO-2026-6809 (crypto/x509 Certificate.Verify) over go 1.26.1:

• whois-api-llc/techrecon#1213, job 120625436528: Setup go version spec 1.26.1, go version go1.26.1, GOTOOLCHAIN='local'.
• techrecon main today, same commit b853a3a44: ci.yml's test job (it uses go-version-file: go.mod) runs go1.26.10. Coverage-floor run 40261908797 runs go1.26.1.

The fix

When the caller passes no go_version and the run measures coverage itself, the detect step resolves the Go release this way:

1. A caller's go_version input wins, used as given. Unchanged.
2. Both directives are read the way Go reads them, without a trailing CR or a // comment. Go ends a token at // even with no space before it (toolchain go1.26.10//pin).
3. A toolchain goV pin, or goV-suffix for a custom build of V, installs the newer of V and the go line, compared in Go's own order. A pin below the go line is stale: Go ignores it, and under GOTOOLCHAIN=local the older release cannot build the module (go: go.mod requires go >= 1.26.2 (running go 1.26.1; GOTOOLCHAIN=local)).
4. toolchain default, or no toolchain line, installs the go line. Unchanged.
5. A release candidate, on either line, goes to setup-go as SemVer's 1.27.0-rc.2. setup-go's findMatch normalizes the candidate versions, not the requested one, so Go's 1.27rc2 matches nothing; that was already true for an rc go line. The comparison happens before this mapping, in Go's spelling. sort -V orders that spelling as Go does (1.27 < 1.27rc1 < 1.27rc2 < 1.27.0 < 1.27.1, checked on GNU coreutils 9.11 and macOS sort), so a stale rc pin still loses to its release.
6. A toolchain line that names no Go release (toolchain 1.26.10, toolchain go1.26.10x) fails the job with an ::error:: that quotes the line, instead of measuring the floor again unseen.
7. No go.mod installs 1.23. Unchanged.

A pre-measured run (pre_measured_coverage_artifact) installs no Go, so it never reads go.mod, and no toolchain line can fail it. The go_version input gets a description that states the default.

Why not go-version-file: go.mod: setup-go v7's own version-file mode has these same gaps. It reads toolchain only when GOTOOLCHAIN isn't local at parse time. It falls back to the go line silently on a toolchain line its regex can't match. It takes a pin below the go line as given. And it returns rc toolchains as 1.27rc2, which its own matcher then can't find. Resolving in the detect step also keeps the chosen version visible as the step's output, and lets the selftest run the shipped step with literal expectations.

Fleet repos whose behavior changes

I enumerated all 145 non-archived repos in topcoder1 and whois-api-llc through the tree API (no truncated trees), not code search alone. 22 have a go.mod, and 2 have a toolchain line. Code search across all owners found no callers anywhere else; its positive controls (techrecon, wxa-graph) appeared.

Repo	Caller	go.mod	Installs before → after
whois-api-llc/techrecon	language: go	go 1.26.1 + toolchain go1.26.10	1.26.1 → 1.26.10
whois-api-llc/wxa-graph	language: go	go 1.26.10	1.26.10 (unchanged)
whois-api-llc/wxa-mcp-server	language: go	go 1.26.10	1.26.10 (unchanged)
topcoder1/ipgeo_core	language: python	go 1.26.1 + toolchain go1.26.10	no Go install (unchanged)
every other caller	python / js	—	unchanged

techrecon is the only repo that changes. Every other Go lane there already runs 1.26.10: they read go.mod through go-version-file, and deploy.yml pins 1.26.10 exactly. Its ci.yml test job is green on main on 1.26.10, so the coverage lane joins them.

Not in this PR

tests-runner.yml's detect step has the same go-line-only resolver it shared with this file. No fleet repo calls tests-runner.yml with Go today, so it changes nothing yet. It's a follow-up.

Tests

selftest/test_coverage_floor_go_version.py runs the shipped detect step against hand-written go.mod files, and every expected version is a literal. It has 24 cases:

• 17 resolve cases: go-only, techrecon's go+toolchain shape, a patch that crosses a digit (go 1.26.9 + go1.26.10), toolchain above the go line, a spaced and an unspaced // comment, two stale pins below the go line, an rc pin, a stale rc pin below its release, an rc go line, CRLF, default, -suffix, caller input wins (twice), no go.mod.
• 3 toolchain lines the job must fail on: 1.26.10, go1.26.10x, banana.
• 2 pre-measured runs, with those lines, that must not fail.
• A negative control: a commented-out // toolchain, a misspelled toolchian and a require …/toolchain module path must not move the version. A positive control through the same harness then finds a real directive.
• A wiring check: setup-go installs the detect step's output, and detect's env carries go_version and pre_measured_coverage_artifact.

Results:

• RED before each fix:
  • 10 failed on the original resolver.
  • 4 failed on the first commit: the stale pins, the unspaced comment, rc.
  • 3 failed on the second: pre-measured runs and their wiring.
  • 3 failed on the third: the rc cases.
• GREEN after: 24 passed, under bash 5.3, under macOS /bin/bash 3.2, and with GNU sort first on PATH.
• Mutation check: 18 of 18 mutants killed. Among them: the pin taken even below the go line, a text sort instead of a version sort, rc mapped before comparing or left in Go's spelling, no comment or CR strip, unusable lines falling back, the pre-measured gate and its env wiring dropped, setup-go wired to the raw input, and the pre-fix resolver.
• Lint: pinned ruff 0.15.10 check and format are clean, actionlint 1.7.12 is clean, and shellcheck is clean on the extracted step.
• Full selftest suite on 14f6780: 1304 passed, 1 skipped, in 9m18s. The skip is environmental and predates this change.
• Evidence: each review finding below was reproduced with a real go binary, or from setup-go's source and README, before it was fixed.

Auto-merge rationale: manual merge. PRs to topcoder1/ci-workflows are always click-merged, and this changes a reusable that every Go repo's required coverage lane calls.

Codex rounds: 8, run in pairs on each commit, and every finding was reproduced before it was fixed:

• Rounds 1–2, on edce29b: 3 P2s. A stale pin below the go line won, an unspaced // comment failed the job, and the rc spelling was one setup-go can't install. Fixed in 2ccd64f; the rc part was revised in 14f6780.
• Rounds 3–4, on 2ccd64f: 1 P2. Pre-measured runs failed on go.mod. Fixed in 5740d56.
• Rounds 5–6, on 5740d56: clean.
• Rounds 7–8, on 14f6780: clean.

An independent code-reviewer agent separately found the stale-pin and rc issues on edce29b. It approved edce29b..5740d56 with one pre-existing P3 (an rc go line) and recommended normalizing rc rather than failing it. That is 14f6780, which also fixes the P3. Its check of 14f6780: approve, with no finding over the bar. Its probes under bash 5.3 and 3.2, with both BSD and GNU sort, all agree.

🤖 Generated with Claude Code

[github-actions]

Risk class: blocked — manual merge required.

This PR touches one of the blocked path categories from .github/risk-paths.yml (Dockerfiles, docker-compose, .github/workflows/**, **/.env*, **/secrets*, infra/, terraform/, k8s/, or the classifier config itself).

Auto-merge is refused by claude-author-automerge.yml. A maintainer should review the diff and click "Squash and merge" themselves.

(This is a policy notice, not a code-quality failure. The classify job itself does not fail — required CI checks remain authoritative for "is the code green.")

[github-actions]

The diff is small and focused. I've reviewed both changed files:

.github/workflows/coverage-floor.yml

• The new INPUT_PRE_MEASURED guard correctly prevents go.mod from being read on pre-measured runs (no Go is installed, so parsing toolchain is pointless and could fail the job on an unreadable line).
• The directive() awk function correctly strips CRLF and // comments before comparing field 1, and the exit after the first match handles duplicate directives safely.
• sort -V | tail -n 1 picks the newer of the go line and the toolchain capture — the comment explicitly notes this relies on sort -V ordering 1.27rc2 < 1.27.0 (Go's own order), which is tested in stale-rc-pin-below-release.
• The RC conversion (1.27rc2 → 1.27.0-rc.2) only needs to handle the final GO_VER value, which is correct: whether the RC came from the go line or was selected as the newer toolchain version, it passes through the same RC_RE check.
• Error path for unrecognized toolchain spellings (e.g., go1.26.10x, banana) is explicit and intentional — failing loudly avoids the silent re-measurement of the floor.

selftest/test_coverage_floor_go_version.py

• Test harness feeds the shipped run: script through bash, reading outputs from a fake GITHUB_OUTPUT file — a faithful replica of how Actions runs a run: step.
• Coverage is comprehensive: go-line-only, toolchain pin, stale pin below go line, RC in toolchain, RC in go line, CRLF, default, custom suffix, caller override, no go.mod, pre-measured bypass, lookalike directives, and the structural assertion that setup-go actually uses steps.detect.outputs.go_version.

No issues found. Diff is well-tested and the logic is correct.

_{Claude Review · workflow run}