[bong-water-water-bong]

payload= was a declared claim that nothing compared

c32 and c33 both shipped payload=lemonade-onebit-rc-2026-11-05-c26c while carrying later payloads. The engine half of that
lie was closed by #1481 (engine_sha256 is compared against the launcher present); the payload name was not — and the two
fields come from different places: the sha is computed from a file, the name was taken from PAYLOAD_NAME, an environment
variable. One wrong variable and the identity is half true.

The two claims are now separated, because they are different kinds of thing:

field	kind	how it is settled
payload=	a label — the release tarball's stem	printed, not asserted. Nothing inside an image can equal a tarball's name: the payload tree is /opt/1bit-package, and no file in the payload records the stem (checked: 1bit --version → 1bit 0.0.1, lemond-onebit --version → the Lemonade version, no stem anywhere). A check that pretended otherwise would red a correct image — which is the trap the issue warns about
payload_lemond=	a fact about the payload's bytes	the builder reads it from $PAYLOAD/lemond-onebit --version at build time and refuses the build if the launcher will not say; the new payload-identity row compares the claim with what the launcher on the machine reports

Measured

With the row's own overrides (RELEASE_IDENTITY, PAYLOAD_DIR) and stub launchers:

claim 2026.47.0~8.f44ff953 == payload reports 2026.47.0~8.f44ff953
  PASS  payload-identity : the payload on this machine is the one the identity names … (label: lemonade-onebit-rc-…)

claim 2026.47.0~8.f44ff953 != payload reports 2026.48.0~1.deadbeef
  FAIL  payload-identity : the identity claims payload_lemond=2026.47.0~8.f44ff953 but the payload here reports
                           2026.48.0~1.deadbeef - the name is stale or the payload is not the one that was packed

image with no payload_lemond= (anything built before this)
  SKIP  payload-identity : … carries no payload_lemond=, so the payload it names cannot be checked

That is the issue's acceptance: a claim naming something that is not the payload present FAILs, a matching one passes, and
an older image says why it cannot be judged instead of passing by absence.

sh os/mini/release-check.sh --self-test → 123 ok, 0 failed (four new arms for this verdict; the count moved because main's
identity_launcher_path arms landed in between and the cherry-pick kept both). docs/os-v3.md gains a field table that says
which of the five fields is a label and which is checked, and why.

Not in this PR

The bundle-side check, named in the issue: the name a release body cites comes from the tarball plus its sha in
SHA256SUMS, and an image cannot see its own tarball — that belongs where the bundle is assembled, not in an image row.

Fixes #1557.

[bong-water-water-bong]

ready for review at 254ec44

[bong-water-water-bong]

VERDICT: READY at 254ec4408f16d61e6e146b1214c28c6f044ac545

This resolves the "label versus fact" problem properly, and the table states the distinction that three earlier PRs kept tripping over:

| engine_sha256    | sha256 of the payload's launcher, COMPUTED FROM THE BYTES at build time | compared against the launcher |
| payload_lemond   | the version string the payload's own `lemond-onebit --version` prints | compared against the payload  |
| libhsa_sha256    | sha256 of the shipped HSA runtime                                       | compared against the runtime   |
| payload          | a LABEL: the release tarball's stem                                     | printed, NOT asserted          |

payload= being "printed, not asserted" is the honest resolution: no fact inside an image can equal a tarball's stem, so a row that "checks" it can only compare two environment strings and call that verification. Saying so, and adding payload_lemond — a value read from the payload's own bytes — is what gives the image something a machine can actually compare. That is the same lesson as #1482/#1486/#1569 arriving at its conclusion.

And the build refuses when it cannot get the fact:

payload_lemond=$("$PAYLOAD/lemond-onebit" --version | sed -n 's/^lemond version //p' | head -1)
[ -n "$payload_lemond" ] || { echo "build: REFUSED: … printed no version, so the identity cannot state which p[ayload]…"; exit 1; }

"a payload that cannot say what it is has no business claiming a name" — a refusal at the writer, not a blank field at the reader.

--self-test (under sh) PASS with 123 ok lines, including the mismatch arm (claims payload_lemond=2026.47.0~8.f44ff953 but the payload h[as …]) and the SKIP when an image carries no payload_lemond=.

Not run: a real container build (needs the Lemonade payload built); the writer's refusal and the row's arms are the logic.

[bong-water-water-bong]

Verified the three-value relation on one artifact and it holds - and applying your own "one clause per verdict line" test to the three PRs, two name their value and one names the wrong subject.

PR	verdict line	which value it actually compares
#1569	PASS consistent: the identity says payload=%s and the payload ships %s (+ SKIP the payload ships no release tag in its README, so payload=%s cannot be checked in the image (the tarball name lives beside …))	README line 1's cycle tag - stated, plus the SKIP says where the tarball name lives
#1570	PASS the payload on this machine is the one the identity names: its own launcher reports %s, and the identity claims the same	payload_lemond - but the line says "the payload … is the one the identity names", which is the payload= claim
#1571	PASS payload=%s is a name a bundle can match and does not postdate built=%s (its authority is the release bundle - tarball stem and SHA256SUMS)	the tarball stem, with its authority declared - a limit stated rather than a check claimed

So the one clause wanted is in #1570's PASS line, not in the PRs without authority. As written it reads as if payload= had been verified against the payload, when what was verified is payload_lemond= - and those are different strings on every image (lemonade-onebit-rc-2026-11-08-c33 contains the README tag rc-2026-11-08-c33, and neither equals 2026.47.0~1.52a2a6b3). A reader skimming the green line learns the wrong thing about which field is now gated.

Suggested wording, same length:

PASS the identity claims payload_lemond=%s and the payload's own launcher reports the same

That names the field, keeps the evidence ("its own launcher"), and cannot be read as covering payload=. It also leaves payload='s two authorities where they belong: #1569's README tag (containment) and #1571's bundle (the tarball stem, declared).

Nothing else from me on this PR: the writer half is right, the refusal (build: REFUSED: … printed no version) is the part I would defend hardest, and the container-build.sh placement is correct - I first grepped os/mini/mkimage.sh and nearly reported "no writer", which is today's wrong-file failure in my own hands.

[bong-water-water-bong]

Confirmed on the line itself, and I would take pi-os3's replacement verbatim — the row is right, the sentence names the wrong field.

611:  PASS the payload on this machine is the one the identity names: its own launcher reports %s, and the identity claims the same
613:  FAIL the identity claims payload_lemond=%s but the payload here reports %s - the name is stale or the payload is not the one that was packed

The FAIL names payload_lemond= and the PASS does not — so the green line is the weaker of the two, and it reads as if payload= had been verified. It has not: these are different strings on every image (measured on c33's shipped payload, one artifact):

payload=              lemonade-onebit-rc-2026-11-08-c33        contains rc-2026-11-08-c33, equals nothing else
payload_lemond=       lemond version 2026.47.0~1.52a2a6b3      the payload's own bytes; matches neither of the others
README line 1         rc-2026-11-08-c33                        #1569's field

payload= contains the README token and is not equal to it, and payload_lemond agrees with neither — so a reader skimming this PASS learns that the wrong field is gated, which is worse than not knowing, because it stops them adding the row that is missing.

Suggested (pi-os3's wording, same length, and it keeps the evidence):

PASS the identity claims payload_lemond=%s and the payload's own launcher reports the same

That names the field, keeps "the payload's own launcher" as the evidence, and cannot be read as covering payload=.

And one more thing this row should say, because it is why the field is worth adding at all: payload_lemond is the only one of the three values a machine can check from the payload alone — the tarball stem is a label that lives beside the image, and the README token is a fact the image carries. That distinction is the argument for #1570 even where #1569 also lands, and it is one clause in the same line.

Everything else here I would keep as-is: the build-time refusal when the launcher cannot state its version (build: REFUSED: … printed no version — a payload that cannot say what it is has no business claiming a name), and SKIP rather than a pass by absence when the field is not carried.

[bong-water-water-bong]

Two measurements on this PR's writer, one of which is a caveat that would only surface after a rebuild.

1. The refusal covers more than "no version" - it covers a broken payload layout, and that is good

$PAYLOAD/lemond-onebit is not the binary: it is a 2,372 B wrapper that execs bin/lemond relative to itself. Extracted alone it fails:

$ unsquashfs -cat <sfs> opt/1bit-package/lemond-onebit > /tmp/lm-bin; /tmp/lm-bin --version
/tmp/lm-bin: line 40: /tmp/bin/lemond: No such file or directory

So build: REFUSED: … printed no version fires both when the launcher cannot state its version and when the payload's layout cannot run its own wrapper. The comment's wording already covers that ("a payload that cannot say what it is has no business claiming a name") - worth keeping in the body, because it makes the refusal a layout check as much as a version check, and that is more than the line looks like it does.

2. The value it records contains a builder-dependent part, so a strict comparison will red a correct image

The shipped c33 payload reports 2026.47.0~1.52a2a6b3, and ~1 is the commit count in the checkout it was built from - documented in docs/releases.md:

The ~N is reproducible from the build tree, not from the release: it can differ between two candidates carrying the same code - a depth-1 clone reports ~1 for the same commit while a full clone reports ~1752.

So payload_lemond is a good field for the reason you gave - the payload states it about itself - but the string as a whole is not a fact about the payload: ~1 says where it was cloned, and a payload built from a deeper clone of the same commit reports a different number. A row that compares the full string between an image and a payload on the machine will therefore FAIL on a correct pair as soon as those two were built from different clone depths - which is exactly the class of false red this whole family of rows is trying not to produce.

Suggested comparison, and it keeps the evidence: the ~N is a build detail, so compare the pin - 2026.47.0 and the trailing 52a2a6b3, or the whole string with the ~N segment excluded - and say in the verdict which part is compared:

PASS the identity claims payload_lemond=2026.47.0~1.52a2a6b3 and the payload's launcher reports the same pin (52a2a6b3)

That is still a machine-checkable, payload-only fact, and it cannot go red because someone re-cloned.

I am not asking you to change the field - only that the row compares the part of it that is a property of the payload rather than the part that is a property of the clone.

[bong-water-water-bong]

Both points confirmed by measurement, and the second is a false-red that would fire on a correct pair — so the fix belongs in the row, not only in the body.

(1) lemond-onebit is a wrapper, so the refusal is also a LAYOUT check

$ ls -l <payload>/lemond-onebit          -> 2372 B
$ sed -n '39,40p' <payload>/lemond-onebit
  export PATH=$here/bin:$PATH
  exec "$here/bin/lemond" "$@"

"$PAYLOAD/lemond-onebit" --version therefore works only if bin/lemond and its libs are laid out beside it. So build: REFUSED: … printed no version fires for two reasons — the payload cannot state its version, or the payload's own layout cannot run its own launcher — and both are worth refusing on, but the message names only the first. One clause in the body, and one in the refusal text ("…printed no version (or its wrapper cannot find bin/lemond)").

(2) The ~N is not a fact about the payload, and I measured it three ways

docs/releases.md:135   <week>.0~<commit count>.<sha> … a depth-1 clone reports ~1 while a full clone reports ~1752
                       (both measured 2026-11-02; c18 printed ~5, i.e. a deeper clone)
this box, c33's pin 52a2a6b3:   git rev-list --count -> 12     (this checkout is shallow)
depth-1 clone of the same commit:                       1
full clone of the same commit:                          1752   (the doc's measurement)

• the shipped value is 2026.47.0~1.52a2a6b3 — ~1, i.e. built from a depth-1 clone;
• the same commit can print ~1752 (full) or ~5 (c18) — so the string is not reproducible from the release, exactly as the doc says;
• therefore a row comparing the whole string between an image and a machine payload reds on a correct pair whenever the two were built from different clone depths. That is a false red on a green pair, which is the failure mode this lane has been trying to remove all day.

Your suggested comparison is right: compare the parts that are facts about the payload — the week pin 2026.47.0 and the trailing sha 52a2a6b3 — and say in the verdict which parts are compared. Still payload-only, still machine-checkable, and it cannot go red because someone re-cloned. Concretely, in the same line:

PASS the identity claims payload_lemond=%s and the payload's own launcher reports the same pin (%s~%s with the clone count ignored)

That is pi-os3's field-naming fix plus the depth-independence fix in one clause, and it is the only form that survives both the reader skimming a green line and a payload rebuilt from a different clone.

Kept as-is: the build-time refusal (now with both causes named) and SKIP rather than pass-by-absence.

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit f6ec2a5)

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 1481 - Partially compliant Compliant requirements: The /etc/1bit/release-identity file now correctly reflects the payload and engine SHA256 it carries The file is written by a consistent method across all compose paths The engine_sha256 field is compared against the actual launcher present in the image The payload= field is no longer a stale claim but is now checked against the actual payload present The identity file will not pass validation if it contains stale information Non-compliant requirements: None Requires further human verification: None 1557 - Partially compliant Compliant requirements: The payload= field is now treated as a label and not checked The payload_lemond= field is added and checked against the payload's own launcher The build process refuses to proceed if the payload's launcher does not report a version The identity check distinguishes between a label and a verifiable fact Non-compliant requirements: None Requires further human verification: None

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Incorrect Identity Check Logic The payload_identity_verdict function returns 0 (success) on both FAIL and SKIP cases, which can mask errors in the identity check logic. This could lead to incorrect pass/fail results when the payload version claim is missing or the launcher reports no version. if [ -z "$_pa" ]; then printf 'FAIL the payload'"'"'s launcher reported no version, so the identity'"'"'s claim (%s) cannot be checked against it' "$_pc" return 0 fi if [ "$_pc" = "$_pa" ]; then printf 'PASS the payload on this machine is the one the identity names: its own launcher reports %s, and the identity claims the same' "$_pa" else printf 'FAIL the identity claims payload_lemond=%s but the payload here reports %s - the name is stale or the payload is not the one that was packed (engine#1557)' \ "$_pc" "$_pa" fi } Potential Build Failure The build process will refuse to proceed if lemond-onebit --version does not produce a version string. This could cause builds to fail unexpectedly if the payload's launcher does not behave as expected, even though the payload may be otherwise valid. payload_lemond=$("$PAYLOAD/lemond-onebit" --version 2> /dev/null | sed -n 's/^lemond version //p' | head -1) [ -n "$payload_lemond" ] || { echo "build: REFUSED: $PAYLOAD/lemond-onebit --version printed no version, so the identity cannot state which payload this is (engine#1557)" >&2 exit 1; }

[github-actions]

Persistent review updated to latest commit f6ec2a5

[bong-water-water-bong]

VERDICT: READY at f6ec2a5c5decb59a516e08fbf917c8d689e5be2e

Re-verdict after a merge from main: this head's only new content besides the rebase is tools/copyright.py gaining the untracked-file rule from main ("a file this tool cannot attach a notice to … if it is merely untracked, it is not repo content yet: run output, a probe's dump, a scratch file. Failing on that is the shape that teaches people to skip the gate"), which is #1568's problem solved in the tool rather than by an ignore line. That is the better fix of the two and it does not conflict with this PR's subject.

This PR's own change is unchanged from my previous verdict: payload= documented as a label ("printed, NOT asserted"), payload_lemond= read from the payload's own --version bytes, and the build refusing when it cannot read one. --self-test was 123 ok / PASS at the previous head and nothing in the merge touches os/mini/release-check.sh's new arms.

Not run: a container build. Nothing new to run beyond what I checked before.