What

Adds an additive release field to dist/build-info.json, stamped from git describe --tags --always --dirty:

{ "version": "2026.6.2", "release": "v2026.6.8-bench.3-3-gd401e877d6", "commit": "d401e877…", "builtAt": "…" }

Why (the durable fix — NOT a version bump)

The bench fork deliberately keeps package.json version at the upstream base (2026.6.2) and carries the bench release identity in the git TAG (…-bench.3) — confirmed: even the v2026.6.8-bench.3 release tag has package.json 2026.6.2. So build-info version alone can't tell you which bench release is running. This bit the Briggs go-live and tonight's gateway cutover (--version→6.2 vs the real 6.8-bench.3).

I investigated bumping package.json instead and rejected it as non-durable: that field is load-bearing — npm-shrinkwrap.json (×3 embeds), deps:shrinkwrap:check, the npm-release/postpublish/appcast tests, and the publish workflow all key off it, and the bench release process intentionally decouples it. Changing it risks the release pipeline for a cosmetic label.

This instead makes a build self-report its true lineage (nearest bench tag + commits-ahead + sha) where the system reads it (build-info / health / the drift guard / debugging), with the load-bearing field untouched. The -dirty marker is a bonus floating-build signal (a build from an uncommitted worktree now flags itself).

Anvil-ready handoff

• Scope: 1 file — scripts/write-build-info.ts (+resolveRelease(), +1 field). Purely additive.
• Touched surfaces: build-info stamping only. package.json / version / shrinkwrap untouched → no release-pipeline impact.
• Local gates: ran the stamper — emits release: v2026.6.8-bench.3-3-gd401e877d6-dirty; package.json unchanged; existing build-info consumers see an extra field (additive, non-breaking).
• Blockers: none.
• Follow-up: optionally surface release in the bench-harness drift-guard summary + openclaw --version/health output.

🤖 Generated with Claude Code