Outcome
The owner has decided whether the agent-handoff 1.15/1.16 session-start binaries should
carry a --version string that matches the payload they ship in, or whether byte-identical
carry-forward (with --version naming the artifact's origin build rather than the payload) is
the intended contract — and the build script or the documentation is updated to match.
Context
The 2026-09-01 Go-tooling efficiency survey (E4, incidental observation) found that the
committed session-start binaries for agent-handoff payload versions 1.14, 1.15, and 1.16
are byte-identical (SHA-256 group 8b90…, 3,906,258 bytes each) and all report
agent-handoff session-start 1.14 from --version.
scripts/build-agent-handoff-session-start.sh:31 still targets the 1.14 source path and
passes -X main.version=1.14 regardless of which payload version's binary it is producing —
so on 1.15 and 1.16 the byte-identical carry-forward is deliberate and reproducible, but the
--version diagnostic silently keeps naming 1.14 instead of the version it was actually built
(or copied) for.
--version is documented as the stale-binary diagnostic ("which package version produced
this binary"). On 1.15/1.16 it answers a question about which build produced the bytes
rather than which payload version installed them, which is a different question from the
one the diagnostic exists to answer.
Scope
- Confirm the intended semantics of
--version for a carried-forward binary: does it name the
build that produced the bytes, or the payload version that ships it?
- If it should name the payload version: update
scripts/build-agent-handoff-session-start.sh
so each retained version's -X main.version= argument matches its own standard.toml
version, even when the source is unchanged and the binary bytes end up identical to the
predecessor's (i.e., rebuild rather than byte-copy, or re-link the version string alone).
- If it should name the build/origin: update the stale-binary-diagnostic documentation to say
so explicitly, so a future investigator does not read a 1.14 answer on a 1.16 binary as a
packaging defect.
- Either resolution is independent of, but overlaps in duplication group with, the wheel-size
and binary-retention decision tracked in the companion issue linked below.
Out of scope
- Any change to the 1.10–1.13 duplicate group (
a539…) unless the same question applies
there too — not established by this survey leg.
- The wheel-size/retention decision itself (separate issue).
Evidence / references
/tmp/ps528-session/efficiency/E4-go.md, "Incidental observation" section.- Companion issue: "Decide payload binary retention and wheel size" — same duplication group,
size/retention concern rather than version-diagnostic concern.
Acceptance criteria
Defined 2026-09-01 for the next release. Investigation: scripts/build-agent-handoff-session-start.sh:31,45 still target versions/1.14/… with -X main.version=1.14, while its own comment says the script "advances to the newest unpublished cut" — 1.15 and 1.16 were byte-copied, never rebuilt. The script's comment and the README both define --version as the stale-launcher diagnostic ("detect a stale installed launcher"), which a carried-forward stamp defeats. Decision recommended and adopted for definition: --version names the payload version that ships the binary. 1.15/1.16 bytes are published and immutable, so they stay as they are and are documented as the known exception; the fix lands with the next cut. Pair this with #235, which needs the same agent-handoff 1.17 reseal.
Outcome
The owner has decided whether the
agent-handoff1.15/1.16session-startbinaries shouldcarry a
--versionstring that matches the payload they ship in, or whether byte-identicalcarry-forward (with
--versionnaming the artifact's origin build rather than the payload) isthe intended contract — and the build script or the documentation is updated to match.
Context
The 2026-09-01 Go-tooling efficiency survey (E4, incidental observation) found that the
committed
session-startbinaries foragent-handoffpayload versions 1.14, 1.15, and 1.16are byte-identical (SHA-256 group
8b90…, 3,906,258 bytes each) and all reportagent-handoff session-start 1.14from--version.scripts/build-agent-handoff-session-start.sh:31still targets the 1.14 source path andpasses
-X main.version=1.14regardless of which payload version's binary it is producing —so on 1.15 and 1.16 the byte-identical carry-forward is deliberate and reproducible, but the
--versiondiagnostic silently keeps naming 1.14 instead of the version it was actually built(or copied) for.
--versionis documented as the stale-binary diagnostic ("which package version producedthis binary"). On 1.15/1.16 it answers a question about which build produced the bytes
rather than which payload version installed them, which is a different question from the
one the diagnostic exists to answer.
Scope
--versionfor a carried-forward binary: does it name thebuild that produced the bytes, or the payload version that ships it?
scripts/build-agent-handoff-session-start.shso each retained version's
-X main.version=argument matches its ownstandard.tomlversion, even when the source is unchanged and the binary bytes end up identical to the
predecessor's (i.e., rebuild rather than byte-copy, or re-link the version string alone).
so explicitly, so a future investigator does not read a 1.14 answer on a 1.16 binary as a
packaging defect.
and binary-retention decision tracked in the companion issue linked below.
Out of scope
a539…) unless the same question appliesthere too — not established by this survey leg.
Evidence / references
/tmp/ps528-session/efficiency/E4-go.md, "Incidental observation" section.size/retention concern rather than version-diagnostic concern.
Acceptance criteria
Defined 2026-09-01 for the next release. Investigation:
scripts/build-agent-handoff-session-start.sh:31,45still targetversions/1.14/…with-X main.version=1.14, while its own comment says the script "advances to the newest unpublished cut" — 1.15 and 1.16 were byte-copied, never rebuilt. The script's comment and the README both define--versionas the stale-launcher diagnostic ("detect a stale installed launcher"), which a carried-forward stamp defeats. Decision recommended and adopted for definition:--versionnames the payload version that ships the binary. 1.15/1.16 bytes are published and immutable, so they stay as they are and are documented as the known exception; the fix lands with the next cut. Pair this with #235, which needs the same agent-handoff 1.17 reseal.session-startbuilt from the 1.17 path with-X main.version=1.17;session-start --versionprintsagent-handoff session-start 1.17.--versionequals the payload version; it tolerates nothing else (1.15/1.16 are retained, not default, and are not asserted).scripts/build-agent-handoff-session-start.shdocuments the cut-time rule in its comment: a new payload version always re-links the binary with its own version stamp, even when the Go source is unchanged, so bytes may differ from the predecessor by the stamp alone.docs/handoff/bugs/as a durable lesson (which versions answer1.14, and why that is not drift).