state the toolchain this binary is built with, and keep the caller on v1

go.mod said `go 1.26`, a floor of 1.26.0, while the Dockerfile pins
golang:1.26.5-bookworm. Nothing imports this — it is a binary — so the directive
constrains only its own build, and naming the patch says which toolchain it is
actually built and tested with rather than one it happens to clear.

The caller goes back to @v1. Pinning an immutable tag there looked like a canary
and is not one: this forge leaves GITHUB_WORKFLOW_REF unset, so build.yml clones
its own bin/ tools from `v1` whatever ref the caller named. A caller pinned
elsewhere gets that build.yml against v1's tools, which is the skew the
pipeline's own tool check exists to catch.

.hanzo/workflows/cicd.yml

@@ -21,9 +21,10 @@ concurrency:
 
 jobs:
   cicd:
-    # Pinned to the immutable tag, not the `v1` alias, because this repo is the
+    # `@v1`, and pinning an immutable tag here would be worse than useless: this
-    # canary for ci v1.0.75 — the release that stopped `gover` reading a
+    # forge leaves GITHUB_WORKFLOW_REF unset, so build.yml clones its own bin/
-    # two-part `go` directive as a demand for the newest patch. The alias moves
+    # tools from `v1` whatever the caller asked for. A caller pinned elsewhere
-    # once this run is green.
+    # gets that build.yml against v1's tools — the skew the pipeline's own tool
-    uses: hanzoai/ci/.hanzo/workflows/[email protected]
+    # check exists to catch. One ref or none.
+    uses: hanzoai/ci/.hanzo/workflows/build.yml@v1
     secrets: inherit

LLM.md

@@ -97,7 +97,19 @@ before anything can serve them; the likely upstreams are `FerretDB/gh` and
 
 ## Build
 
-`go 1.26` in go.mod is a floor of 1.26.0, and the Dockerfile pins
+go.mod says `go 1.26.5` and the Dockerfile pins `golang:1.26.5-bookworm`. This
-`golang:1.26.5-bookworm` — above the floor and hermetic. The `gover` gate in
+is a binary — nothing imports it — so the directive constrains only its own
-`hanzoai/ci` read a two-part directive as demanding the newest patch and refused
+build, and naming the patch states the toolchain it is actually built and tested
-that pairing; fixed in ci v1.0.75.
+with instead of a floor it happens to clear.
+
+Separately: `gover` in `hanzoai/ci` read a two-part directive like `go 1.26` as
+a demand for the newest patch of that minor, so it refused `golang:1.26.5` — an
+image that builds it. Sixteen repos write a two-part directive, `mcp-gateway`
+among them. Fixed on ci main (`6b1ea4f`) with three cases covering the floor;
+that fix reaches the fleet when `v1` next moves, which is blocked on ci main's
+`site` gate (four failures from `1177811`, unrelated to this).
+
+The caller pins `@v1` and must keep doing so. This forge leaves
+`GITHUB_WORKFLOW_REF` unset, so `build.yml` clones its own `bin/` tools from
+`v1` no matter which ref the caller named — pinning an immutable tag here gets
+that build.yml against `v1`'s tools, which is skew, not a canary.

go.mod

@@ -1,5 +1,5 @@
 module github.com/hanzoai/mod
 
-go 1.26
+go 1.26.5
 
 require golang.org/x/mod v0.38.0