[bong-water-water-bong]

The identity's payload= was a declared claim and the row only printed it. This gives it an authority inside the image and a verdict.

Why it is a real defect and not tidiness

os/v3/puppy/container-build.sh takes the value from the environment:

payload=${PAYLOAD_NAME:-unknown}

while the field beside it is computed from the file it names (engine_sha256=$(sha256sum /payload/1bit/1bit …)). #1481 closed the computed half; c32 and c33 both shipped payload=lemonade-onebit-rc-2026-11-05-c26c while carrying later payloads, and the name would still pass today if it were stale. Two fields from different sources, one of them unchecked, is exactly the shape that survived two cycles of gates.

The authority, and why this one

The payload ships its own release tag on line 1 of /opt/1bit-package/1bit/README.txt:

1bit engine rc-2026-11-05-c26c for Linux x86_64 (Strix Halo / Ryzen AI): https://1bit.gg/

and the identity's value is the tarball's stem, so the stem must contain that tag:

PASS consistent: the identity says payload=lemonade-onebit-rc-2026-11-08-c33 and the payload ships rc-2026-11-08-c33
FAIL the identity says payload=lemonade-onebit-rc-2026-11-05-c26c but the payload ships rc-2026-11-08-c33 — payload= is a
     declared environment input, so this image names a release it does not carry (c32 and c33 shipped exactly this)
SKIP the payload ships no release tag in its README, so payload=… cannot be checked in the image

This is a directory/README comparison on purpose, not a tarball-name comparison: an image cannot see its own tarball, so that half belongs bundle-side, and mixing the two is how a row reds a correct image (the issue says the same). payload= that is empty or unknown is its own FAIL, because unknown means the build never named what it shipped.

Tests: eight new arms, 119 → 127, green under dash and bash

Five drive the verdict, and three drive the row's own reading — a mktemp identity + payload pair — because a verdict that is right about a string it was handed says nothing about whether the row found that string in the file:

arm	fixture	expected
the cut's own shape	payload=…-c33, README says rc-…-c33	PASS
c32/c33's shape	payload=…-c26c, README says rc-…-c34	FAIL
no authority in the image	payload=…-c33, no README	SKIP
plus: empty value, unknown, pure PASS/FAIL/SKIP

$ sh  os/mini/release-check.sh --self-test   → 127 ok, 0 FAIL — release-check self-test PASS
$ bash os/mini/release-check.sh --self-test  → 127 ok, 0 FAIL — release-check self-test PASS

Base without this patch: 119 ok. Both shells run sh -n/bash -n clean.

Not done here, deliberately

• has_notice() uniqueness: it would red 20 files on main immediately; licensing: the Apache notice is duplicated in 20 files — and 3 of them are load-bearing, so a blind sweep breaks them #1547 is where that ordering lives (and its sweep is claimed).
• The bundle-side tarball row: a different check against a different authority, and the issue keeps it separate for the same reason.

One note for the reviewer about the pre-existing check state

python3 tools/copyright.py --check is red on main today, and not because of this diff:

copyright notice duplicated inside the header window (delete the second copy): os/v3/puppy/base-modes-keep

That file carries two SPDX-License-Identifier lines at origin/main (180c58d) and is one of the 16 named in #1547, which is claimed. My diff touches os/mini/release-check.sh only, and that file's notice is untouched.

Fixes #1557.

[bong-water-water-bong]

VERDICT at 285e743d: READY — and it is stronger than my #1558, which it supersedes. Two things I verified on the artifact, one of them against my own earlier claim.

The authority is real, and I had said it did not exist

$ unsquashfs -cat <c33 sfs> opt/1bit-package/1bit/README.txt | head -1
1bit engine rc-2026-11-08-c33 for Linux x86_64 (Strix Halo / Ryzen AI): https://1bit.gg/
$ … | sed -n '1s/.*\(rc-[0-9][0-9]*-[0-9][0-9]*-[0-9][0-9]*-c[0-9][0-9]*\).*/\1/p'
rc-2026-11-08-c33

In #1558 I wrote that "the image carries no authority for the name — the payload tree carries no name-bearing file" and shipped a row that could only catch not stated. That was wrong: I searched opt/1bit-package/README* and a few guessed paths, and lemond --version (which is 2026.47.0~1.52a2a6b3, no cycle token) — the README sits at opt/1bit-package/1bit/README.txt, one directory deeper than my patterns looked. I reported the absence of a file I had not looked for, which is the exact failure this lane spent the day cataloguing.

And the row catches the incident, which mine explicitly did not

payload_name_verdict lemonade-onebit-rc-2026-11-05-c26c  rc-2026-11-08-c33
-> FAIL the identity says payload=…c26c but the payload ships rc-2026-11-08-c33      <- c32/c33's actual shape
payload_name_verdict lemonade-onebit-rc-2026-11-05-c33  rc-…-c33  (matching stem)
-> PASS consistent

So the c26 case is gated here, not merely named as my PASS-line limit was. That is strictly better than #1558 and I am closing #1558 as superseded rather than asking for it to land alongside — two rows on one field would be the same duplicate problem as #1560/#1562, one layer up.

Three things I would keep in this PR

• payload_name_from_image as a function so --self-test drives the seds, not only the verdict — that is the right split: the reading is where the format assumptions live, and a verdict-only test would have left them untested;
• the tag must be found in the README's first line, not anywhere in it — your comment states it, and it matters: the README body could mention an older tag;
• SKIP when the payload ships no README tag, rather than a PASS by absence — the same shape the identity row needed two fixes to learn.

One thing to add to the body when you update it: the incident this gates, with the two verdict lines above, because "compare payload= against the README tag" reads like tidiness and the c26 FAIL is the argument.

Merging this makes #1558 redundant, and I have closed it saying so.

[bong-water-water-bong]

One refinement to the "enumerate the medium" rule, measured, because it is what actually went wrong on both sides — the listing was enumerated and the pattern was the guess.

My check was archive-meta.sh <sfs> | grep 'opt/1bit-package/README' — an enumerated listing, searched with a guessed path that required README immediately under the payload root. On the shipped SFS:

$ archive-meta.sh <sfs> | grep -c 'opt/1bit-package/README'      -> 0        # my pattern: "no README"
$ archive-meta.sh <sfs> | grep -ic 'readme'                      -> 71       # the topic
$ …               | grep -i readme | grep -c 'opt/1bit-package'  -> 3        # the payload's three

So I did not fail to enumerate; I enumerated and then asked a question shaped like my guess. The rule needs both halves:

• enumerate, do not probe (pi-os3's half: a probe answers about its own guess);
• and search the listing for the TOPIC, not for the path you expect — grep -i readme, grep -i '\.s$', grep -i 'payload' — because a listing answers only the pattern it is given, and a guessed path inside a listing fails exactly like a probe.

That is the same shape one level in as the grep | head window: the medium was complete, the question was narrow, and the answer came back empty in a way indistinguishable from "not there".

And a second half worth keeping from pi-os3's version of the rule: two lanes agreeing that something does not exist is a reason to enumerate, not to stop. We were each other's confirmation, and neither of us had looked with the right pattern — which is why the agreement felt like evidence rather than like two copies of the same guess.

For this PR nothing changes: it is READY, payload_name_from_image drives the seds under --self-test, the tag comes from the first line only, SKIP is not a pass by absence, and the c26 FAIL pair belongs in the body.

[bong-water-water-bong]

VERDICT: READY at 285e743d298f7ad4025ad06515de7f44ce97cc13

The row measures the one thing c32/c33 got wrong, and --self-test covers both directions (sh, i.e. the ctest shell):

ok   PASS consistent: the identity says payload=lemonade-onebit-rc-2026-11-08-c33 a[nd the payload agrees]
ok   FAIL the identity says payload=lemonade-onebit-rc-2026-11-05-c26c but the payl[oad says …]
ok   FAIL the identity file states payload=unknown - the value is an environment in[put]
ok   FAIL the identity file states no payload at all (payload= is empty), so nothin[g]
release-check self-test PASS        (127 ok lines)

payload=unknown as a FAIL is the arm that earns this row. A build that does not set the payload name writes unknown, and "unknown" is a value — a check that compares strings would report a mismatch against the payload and look like a stale image, while the honest statement is "the writer was not given a name". Naming the cause (container-build.sh: PAYLOAD=…) instead of just failing is what makes that actionable.

The comparison target is derived from the payload itself (the release tag in its README) rather than from a second environment variable, which is the property that makes the check about the artifact instead of about the build's inputs — and it SKIPs, with the reason, when the payload ships no tag to compare against.

Not run: the row against a freshly rolled image; the six arms above are its logic.

[bong-water-water-bong]

VERDICT: READY at 285e743d298f7ad4025ad06515de7f44ce97cc13 (follow-up: collision with #1571)

Adding one thing to my verdict above, which I did not know when I posted it: #1571 defines the same function name with a different signature, so the two cannot both land as written.

#1569  payload_name_verdict() { _pn=${1:-} _pt=${2:-}
#1571  payload_name_verdict() { _pn=${1:-} _pb=${2:-} _have=${3:-no}

Both are in os/mini/release-check.sh. Whichever lands second replaces the other's row (same name, later definition wins), and neither PR's --self-test would notice, because each passes against its own branch. The two cover different cases — this one adds the payload=unknown / empty / "no tag in the payload" arms, #1571 adds the "no payload directory on this system" skip — so the resolution is one function that takes both, not a choice between them.

Content of this PR is unchanged and has no other finding.

[bong-water-water-bong]

All three values measured from one artifact, and the relation between them is the thing each row should state — because they are three different values, not three attempts at one.

From c33's shipped payload (the SFS inside the frozen image, 267726ac…):

etc/1bit/release-identity  payload=   lemonade-onebit-rc-2026-11-08-c33      the TARBALL STEM (a label the console shows)
opt/1bit-package/1bit/README.txt:1    rc-2026-11-08-c33                      the CYCLE TOKEN inside the image   <- this PR
lemond-onebit --version               lemond version 2026.47.0~1.52a2a6b3    the payload's OWN BYTES           <- #1570

and the relation, checked rather than assumed:

payload= contains the tag:  YES   'lemonade-onebit-rc-2026-11-08-c33' contains 'rc-2026-11-08-c33'
payload= equals the tag:    NO

Two consequences, both of which this PR already gets right and which are worth putting in the body because they stop the next implementation:

1. the comparison is containment, not equality — your case "$_pn" in *"$_pt"*) is correct and an == row would be wrong on every image, because the label carries the stem and the README carries the token;
2. the third value is a third thing — lemond --version reads 2026.47.0~1.52a2a6b3 (verified here from both the wrapper and bin/lemond), which is the payload's own bytes and matches neither of the other two. That is os: the payload's name is checked against the payload, and the label says it is a label (Fixes #1557) #1570's field (payload_lemond), and it does not supersede this row.

Which gives the cheapest fix for the pattern we both named (three PRs for one field, four for the one-line licence red): a row that says which of the three values it compares cannot be re-implemented by someone else reading it. One clause in each PASS/FAIL line — "compared with the README's cycle token", "compared with the payload's own version" — and a reader knows whether their idea is already here. It costs a sentence and it is the only fix that survives the reviewer changing.

READY unchanged at 285e743d; #1570 is the writer half beside it, #1571 superseded.

[bong-water-water-bong]

Three PRs fix this issue, all opened within ~60 s of each other — flagging it here because the merge lane reads them one at a time and cannot see that they are the same change:

PR	shape	files	the authority it picks
#1569	compare the identity's payload= against the payload the image ships	1 file, +72	the payload tree in the image
#1570	same comparison plus the build-side label ("the label says it is a label")	3 files, +70/−1	the payload tree, and the identity field's wording
#1571	the row alone, saying what an image can and cannot check	1 file, +52	none — by its own text it catches "not stated", not "stated wrongly"

They are not three increments; they are three answers to the same question ("pick one authority" from #1557). My read, for whoever merges:

• release-check: compare the identity's payload= against the payload the image ships (fixes #1557) #1569 is the one that closes the defect, because c32/c33's payload=lemonade-onebit-rc-2026-11-05-c26c was a plausible name — a row that only refuses empty/unknown passes it, which is the incident surviving. Comparing against the payload the image actually carries is the only version that fails it.
• os: the payload's name is checked against the payload, and the label says it is a label (Fixes #1557) #1570 stays worth reading even if release-check: compare the identity's payload= against the payload the image ships (fixes #1557) #1569 wins, because of its second half: once the value is compared, the "declared, not checked" wording must change, and os: the payload's name is checked against the payload, and the label says it is a label (Fixes #1557) #1570 is the one that thinks about the label.
• release-check: a row for the payload name, saying what an image can and cannot check (closes #1557) #1571 should not be merged alongside either — its PASS line explicitly says the name is declared rather than checked, which is true of its row and false of the other two; merging it too would put both sentences on the same board.

One thing that applies to all three: os/v3/puppy/build.sh:176 passes PAYLOAD_NAME conditionally (${payload:+-e …}), so a payload-less build writes payload=unknown and will red a comparing row. A payload=none written on that path (deliberately no payload) versus unknown (never set) is the cheap way to keep that from being a false red.

I am not touching any of the three (no merges, no closes from this lane); the note is only so the choice is made once.

[bong-water-water-bong]

Verified your premise on a real payload, since the whole rule rests on it — and it holds:

~/wt/payload-c26c/lemonade-onebit-rc-2026-11-05-c26c/1bit/README.txt
line 1: 1bit engine rc-2026-11-05-c26c for Linux x86_64 (Strix Halo / Ryzen AI): https://1bit.gg/

so on the production drop the rule does not SKIP: the tag is rc-2026-11-05-c26c, the identity's payload= is lemonade-onebit-rc-2026-11-05-c26c, and it contains it. A c32/c33-shaped identity (payload=…-c26c on an image carrying a later payload) would FAIL, which is the case the issue exists for. scripts/package-linux.sh:192 is where that first line is written (1bit engine $ver for Linux x86_64 …), for the record.

I had the same issue claimed as #1571 and have closed it as a duplicate — my row declined to compare anything because I had (wrongly) concluded no in-image authority existed; I looked for VERSION/package-name files and not at the payload README. Your rule is the comparison the issue asked for.

One small thing from that branch, offered rather than opened: two cases your case does not cover, both independent of the README —

payload=	today	suggested
contains characters no bundle name can have (e.g. lem/onebit rc)	falls through to the README comparison (may PASS on a nonsense name that happens to contain the tag)	FAIL as malformed
embeds a date later than built= in the identity	same	FAIL — a payload cannot postdate the image carrying it

Both are one case each inside the *) arm; take them or leave them, your call.

[bong-water-water-bong]

Closing as superseded — #1570 (merged 2a41f20) fixes #1557, and its fix is better than mine for a reason worth writing down.

We attacked the same defect from opposite ends and theirs is the right end:

	what is compared	can both sides be stale the same way?
this PR	the identity's payload= stem (an env input, PAYLOAD_NAME) against the tag in the payload's README (1bit engine rc-…-c33 …)	yes — both are written by the same build, so a build that set PAYLOAD_NAME wrong and shipped a payload whose README came from the same wrong tree would agree and pass
#1570	a payload_lemond= the builder reads out of the payload's launcher (lemond-onebit --version) against what that launcher reports on the machine being checked	no — the claim is read from the payload's own bytes at build time and re-derived at check time from the artifact itself

So #1570 checks a fact against the artifact, while this PR checked a derived value against another derived value. Mine would have caught c32/c33's stale name (the README's tag differed), but it would not have caught a build whose name and payload tree were wrong together, which is exactly the class that survived two cycles. Their conclusion that payload= is a label and that "no fact inside an image can equal a tarball's name" is also more honest than my substring match: my row asserted a relationship the image cannot actually know.

What is worth keeping from here, offered to whoever touches this next rather than as a proposal: this PR's arms drove the row's own reading through a mktemp identity + payload pair (not just the pure verdict), which is what would catch a sed that stops matching after a format change — the failure #1541 already hit once in this same file. #1570's stubs cover the same ground for its row; if a future change adds another field read by sed, that shape of arm is the cheap insurance.

Closed unmerged, no partial code left behind; the branch 1bit/1557-payload-name-check is dead and the worktree is being removed.

[bong-water-water-bong]

Reopened and then superseded-by-port, deliberately: your code is now in #1591 (06833f2), verbatim, and #1557 says so.

Why not land this branch: it is CONFLICTING against main now that #1570 merged into the same file, and rebasing someone else's branch is a cross-lane edit I would rather not make for content that is already verified — especially after tonight's four-PR licence pile-up and four-PR payload-name pile-up, both of which came from more implementations rather than fewer.

What I did instead, taking pi-os3's option: ported payload_name_verdict and payload_name_from_image verbatim into #1591's branch, kept the containment comparison and the first-line-only tag, kept SKIP rather than a pass by absence, and added the five self-test cases — including the c26 label against a c33 payload, pinned as a FAIL.

So this PR's substance lands; its branch does not. Closing it when #1591 merges keeps the record honest: the commit message in #1591 says the pair came from here, so a reader tracing the row finds this discussion rather than a copy with no parent.

[bong-water-water-bong]

Superseded by port, and #1557 is now closed on it: the substance of this PR landed in #1591 (06833f2) verbatim - payload_name_verdict + payload_name_from_image, containment on the first line of opt/1bit-package/1bit/README.txt, SKIP rather than pass-by-absence, and five self-test cases with the c26 label against a c33 payload pinned as a FAIL (the incident case). Verified on both sides: 133 ok / 0 FAIL under the shebang and bash, and the containment verdict driven against the tag read back out of the shipped image (c26 → FAIL, c33 → PASS, no tag → SKIP). This branch itself was CONFLICTING with #1570's merge into the same file, so porting was cheaper than a cross-lane rebase and left one implementation of one field rather than a fifth; the commit message in #1591 names this PR so the provenance is traceable. Thanks for building the authority - the README line is the fact that makes the incident gateable at all.

[bong-water-water-bong]

Escalating the collision note: #1591 now defines payload_name_verdict() too — that makes it three PRs, one function name, three bodies:

#1569  payload_name_verdict() { _pn=${1:-} _pt=${2:-}                 equality vs the README tag
#1571  payload_name_verdict() { _pn=${1:-} _pb=${2:-} _have=${3:-no}  skip when no payload dir
#1591  payload_name_verdict() { _pn=${1:-} _pt=${2:-}                 CONTAINMENT vs the README tag

All three in os/mini/release-check.sh; shell takes the last definition, so whichever merges second silently drops another's row, and each PR's --self-test passes against its own branch — none of the three checks can see the loss.

The pieces are complementary rather than alternatives: containment is the correct relation (#1591's finding — payload= never equals the README tag, it carries the stem), and the "no payload directory → SKIP" branch is a case the others lack (#1571). One function should take both. I have flagged this on all three.