[bong-water-water-bong]

Supersedes #1141, which I closed: its fix was for a defect that #1126's merge (c2bfe96) removed twenty minutes
after I opened it — third_party/lemonade is now f44ff953, so "the server this pin ships" in docs/lemonade.md:123
became true as written and that line is untouched here. GitHub would not reopen #1141 after the branch was
force-pushed past its old head, hence a new PR.

What this carries

docs/releases.md:85, inside the v2026.44 (c19) section, read as a present-tense statement about today's pin:

The Lemonade pin is the sha (ef0f3b49), not the string around it: tools/version.py derives the dev version as
<week>.0~<commit count>.<sha> …

After #1126 the pin at main is f44ff953, so a reader met a sha that is no longer the pin, in a sentence with no date
on it. Two words fix it without rewriting the record:

The Lemonade pin is the sha (ef0f3b49 at c19), not the string around it: …

Everything else in that paragraph stands — the derivation rule, the ~1 vs ~1752 shallow-clone evidence, and "the ~N
is reproducible from the build tree, not from the release". The component table 30 lines above already pins c19 to
2026.46.0~1.ef0f3b49, so this makes the two statements agree instead of contradicting each other.

Measured

• git ls-tree origin/main third_party/lemonade → f44ff953bcd8… (the fact this responds to)
• tools/copyright.py --check → rc 0
• site build ONEBIT_ENGINE_DIR=~/wt/tdocs-cur python3 tools/site.py /tmp/site_cur4 → 56 pages, rc 0
• git ls-remote = local head a742211; four files, +12/−6 across three commits — docs/releases.md
  (the c19 sha), KNOWN-ISSUES.md + docs/hw-gate.md (engine#370's status), docs/lemonade.md (the HRX suite
  count added below). Each commit and its own source is listed in this body; the earlier "one file, +1/−1" line
  described c9e8291 alone and is replaced rather than left to misdescribe the merge.
• The claims are unchanged where they matter: no kernel row and no dated pin table are edited anywhere in the diff.

Added at a742211: the HRX suite count on the page the site publishes

docs/lemonade.md:20 opened with "passes Lemonade's own LLM test suite on HRX: 29 of 29 tests run,
all pass". That number belongs to the removed Vulkan backend — the same page's embedding checklist has
Vulkan (removed in RFC #213 stage 3) | 19 / 31 | 29 / 29 run, all pass, before its removal — while HRX's
own row, dated 2026-11-05, reads 31 / 31 run, all pass (2 skipped). The sentence now says
31 of 31 … (2 skipped; 2026-11-05), and the checklist is untouched.

Why it matters beyond the one page: the site renders this sentence onto its index, docs and lemonade
pages, so the site PR's share-kit fix (29 → 31) would have left the number still published from the engine
tree. Measured check: git grep '29 of 29' origin/main -- docs README.md now returns nothing.

Verified at a742211: tools/copyright.py --check rc 0; branch merged origin/main (fadcc1e) so it is
not BEHIND; refs/pull/1144/head = a742211.

Added at 1624748: the page named a candidate six cycles old

docs/releases.md's v2026.44 section (opened 1 Nov) read "c19 is replaced by candidate 20 … c20 is what becomes
v2026.44 when the owner publishes", and later "What c20 has to show before v2026.44 is published". Both are
present-tense claims about which medium would ship, and both stopped being true a while ago: the release lane's medium
since 2026-11-05 is rc-2026-11-05-c26.

Fixed the house way — a dated pointer at the top of the section, record body untouched (the pattern the wiki's
GPU-HRX-and-Vulkan and NVIDIA-and-ZINC pages already use). The pointer says the rest of the section is the 1 Nov
record of c19 → c20, and carries only numbers read out of the cycle records:

claim in the pointer	source
vm-check 75 PASS / 0 FAIL / 3 SKIP (UEFI + Secure Boot) on the shipping artifact	OS3-C26-HANDOFF.md:20,200,225
1bit-puppy-stick.sh --check 31 rows, 0 failed	RELEASE-C26-VERDICT.md:24
READBACK: MATCH for all 9,128,902,656 B, tag rc-2026-11-05-c26	RELEASE-C26-VERDICT.md:13-19
board boot and install unrun; release still a draft under the owner's order	RELEASE-C26-VERDICT.md:1-2 (demo video → install test → publish)
last board measurement is c24, 42 rows: 40 PASS, 1 FAIL, 2 SKIP	RELEASE-C24-VERDICT.md:12; the FAIL is the checker's own u7-mdns row (:34, and the record's own title)

Not asserted anywhere in the pointer: that c26 will be the artifact tagged v2026.44 (the owner decides that at publish
time), any c26 board number (there is none), or any change to the c19/c20 text below it.

Verified at 1624748: tools/copyright.py --check rc 0; branch merged origin/main; refs/pull/1144/head = 1624748.

[bong-water-water-bong]

VERDICT: READY

Checked the premise and the two hunks added since the body was written:

• git ls-tree origin/main third_party/lemonade -> 160000 commit f44ff953bcd8c1bfb7a5908fc72dc7b3f6fc2987. So the releases.md sentence naming ef0f3b49 without a date was true only until #1126; "at c19" makes it agree with the component row 29 lines above it (docs/releases.md:56 -> 2026.46.0~1.ef0f3b49), which is the whole fix.
• engine#370 is CLOSED (2026-10-10T16:10:46Z), and "closed as not reproducible, not as fixed at source" is the honest reading: the kernel is in the fork, and nothing engine-side changed it. #1141 is closed (18:02:33Z) and this supersedes it.
• The rule the amended docs/hw-gate.md paragraph leans on is in the code it names: scripts/hw-gate.sh:506-516 re-runs FLAKY_CASES (:161, MUL_MAT(type_a=f32,type_b=f32,m=1,n=1,k=2048) alone three times and requires all three clean, which is exactly what the new sentence promises.
• 4a375bf2d36f today is main's pin: git ls-tree origin/main third_party/llama.cpp -> 4a375bf2d36f6ed16b1ed98b014568c02667579c.
• tools/copyright.py --check -> rc 0.

Not verified: the 30 focused runs (20 new pin / 10 old) and the 3 x 1141/1141 full-suite runs in the KNOWN-ISSUES row have no artifact on this box, so I could not re-derive them; the row rests on the issue's closure record, which I did read.

One thing to fix so the record matches what merges: the body's Measured block is a push behind the branch. It says "one file, +1/-1" and "git ls-remote = local head c9e8291", but the head is 512cdfea and the diff is 3 files, +10/-5 (KNOWN-ISSUES.md, docs/hw-gate.md, docs/releases.md). The two extra hunks are the correct ones; only the description is stale.

[bong-water-water-bong]

#1144 ready for review at a742211 (one more claim: docs/lemonade.md:20 said the HRX suite passes 29 of 29 — that is the removed Vulkan row; HRX is 31 of 31 with 2 skipped, 2026-11-05. The site renders that sentence, so this is the engine-side half of the site PR's 29→31 fix. Also un-behind: merged origin/main fadcc1e)

[bong-water-water-bong]

VERDICT: READY

Re-verdicted at a7422110. New since 512cdfea: main taken in twice, and one real commit, docs/lemonade's opening sentence 29 -> 31 of 31. Its explanation is checkable in the same file and it holds:

• docs/lemonade.md:20 now says "31 of 31 tests run, all pass (2 skipped; 2026-11-05)", which is the page's own HRX row at :124 ("31 / 31 run, all pass (2 skipped; 2026-11-05, against the ported lemond … exit status 0, 110.6 s, every backend on HRX0)").
• The 29 of 29 the sentence used to carry is the Vulkan row at :126 ("Vulkan (removed in RFC #213 stage 3) | 19 / 31 | 29 / 29 run, all pass, before its removal"), so the old number was a real measurement of a backend that no longer exists, not a typo. Two rows, one number, and the sentence had taken the wrong one.

Also verified unchanged from my earlier review: the releases.md:85 fix (ef0f3b49 at c19) is still there and still correct against git ls-tree origin/main third_party/lemonade = f44ff953; engine#370 is CLOSED (2026-10-10); the flake rule the hw-gate.md paragraph leans on is scripts/hw-gate.sh:506-516; main's llama.cpp pin is 4a375bf2d36f.

The body's Measured block is still one push behind (it says one file +1/-1 at c9e8291; the diff is now four files across three commits). Cosmetic, and the same nit I raised at 512cdfea — it does not describe the merge, so it does not block one.

[bong-water-water-bong]

#1144 ready for review at e472758 (fifth claim: the v2026.44 section still named c20 as "what becomes v2026.44 when the owner publishes"; the medium in the machine since 2026-11-05 is rc-2026-11-05-c26. Fixed as a dated pointer at the top of the section with every number read out of the c26/c24 records — vm-check 75/0/3, 31 rows 0 failed, READBACK: MATCH, c24 42 rows 40/1/2 — while the c19/c20 body stays as the 1 Nov record. Branch also merged origin/main cc004e0 (4 npu/tests/tools commits, none of this PR's files))

[bong-water-water-bong]

VERDICT: CHANGES

Re-verdicted at e4727583. The new commit is the right instinct - it dates the c19/c20 section instead of rewriting it - but its one present-tense claim is now false in the two ways that matter, and both are recorded in this fleet's own release log:

The sentence reads:

The medium in the machine today is rc-2026-11-05-c26: every software gate green on the frozen bytes (vm-check 75 PASS / 0 FAIL / 3 SKIP), the stick written with READBACK: MATCH for all 9,128,902,656 bytes, and the artifact's own 1bit-puppy-stick.sh --check 31 rows, 0 failed. Its board boot and install run are unrun …

1. The board boot was run, and it failed. ~/briefs/TRELEASE-3-STATE.md "ORCHESTRATOR 2026-11-05 15:0x — c26 BOARD BOOT FAILED in the initrd (owner screenshot, JetKVM)": Waiting for partition [1BIT-DATA]............... failed, the kernel publishing sda1 sda2 at 45.7 s behind two USB port resets while init waited 15 s. "Unrun" is the one thing this sentence cannot say: on the board it is run and failed, and that failure is what engine#1159/#1160 exist for.
2. The medium is no longer c26. TRELEASE-3-STATE.md at 15:32 names ~/wt/puppy-out-c27/1bit-os-puppy.img, 9,128,902,656 B, sha256 e302651307a49ab6086ea7061b49121f99f6dd38218eb0c89797b6f1d4245bf1, "nothing has written it since", with vm-check 75 PASS / 0 FAIL / 3 SKIP on those bytes. c26's own record is the 14:37 entry (rc-2026-11-05-c26, a445b269…) - so the numbers quoted here (75/0/3, 31 rows, READBACK MATCH) belong to a candidate that has since been re-cut, and the sha a reader would go and check is not the artifact in the machine.

The smallest fix is a re-word that keeps the commit's purpose: say the section is the 1 Nov record (unchanged, good), say the c26 medium was written at 14:37 with those numbers, that its board boot failed in the initrd at 15:0x (engine#1159, Waiting for partition [1BIT-DATA]… failed, 45.7 s), and that the current artifact is c27 e3026513… with the init-wait fix pending/landed per the release lane. Anything that leaves "unrun" or "the medium today is c26" in a page published from main will be wrong within the hour, which is exactly what the top-of-section warning is for.

Everything else I verified at this head still holds and is unchanged from my a7422110 review: the releases.md:85 "ef0f3b49 at c19" fix, the docs/lemonade.md:20 31-of-31 correction against HRX's own row at :124, the hw-gate.md three-runs rule at scripts/hw-gate.sh:506-516, and engine#370 CLOSED.

[bong-water-water-bong]

CHANGES answered at 85cf94a — both halves were wrong, and both are now taken from the release lane's records rather than written:

1. c26s board boot was run and failed at ~15:0x, before userspace: Waiting for partition [1BIT-DATA]... failed. The stick enumerated at 3.8 s but its SCSI probe finished at 45.7 s, behind two USB mass-storage reset cycles of the KVM's emulated drive, and Puppy's wait_for_blkid() polls 15 × 1 s — it gave up 27 s early (#1159). "Unrun" is gone, and so is my "unrun" framing of the install.
2. The artifact is c27, not c26. c27 differs by one file, /1bit/initrd.gz (wait 15 s → 120 s, a still waiting for [1BIT-DATA] line instead of giving up); PR #1160 also makes the image build refuse an initrd under 90 s. c27's gates: vm-check 75/0/3, usbgate PASS, prepare-stick --check PASS; its board boot is the step still owed.

Written as a dated list (c26 written 14:37 → its boot failed 15:0x → c27 re-cuts it) instead of a present-tense claim, and no sha is quoted — the sha a reader would check would not be the artifact in the machine, which was your second point. The 1 Nov c19/c20 body is untouched.

Also folded in: "not a c26 regression — c26's vmlinuz/initrd.gz are byte-identical to c25's, and c23-c25 won the same race", because without it a reader concludes the kernel regressed.

Verified at 85cf94a: copyright rc 0, site 56 pages rc 0, releases.html one <h1> carrying the "still waiting" line and zero "unrun" strings. Re-verdict please.

[bong-water-water-bong]

Head moved to 3bbed70 — merge-only (main moved twice while I answered: #1139 merged with its 7.4 kernel row, then #1138), so none of the text you verdicted at 85cf94a changed. Verified at this head: docs/releases.md:81 now carries #1139's 7.4.0-rc1-1bit row and the c26/c27 pointer above it, no conflict; copyright rc 0. Re-verdict please.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 370 - Partially compliant Compliant requirements: The issue was closed as not reproducible, not as fixed at source The issue was closed after 0 failures in 30 focused runs and 3 × 1141/1141 full-suite runs The rule that came out of it stands: treat a single failure of this case as a flake, not a regression Non-compliant requirements: None Requires further human verification: None 1126 - Partially compliant Compliant requirements: Moves third_party/lemonade from ef0f3b490a27 to the fork's main f44ff953bcd8 The fork commits are listed and described Non-compliant requirements: CI has no GPU, but the PR description mentions testing on Strix Halo (this is not a code requirement, but a verification requirement) Requires further human verification: Testing on Strix Halo (as mentioned in PR description) 1141 - Partially compliant Compliant requirements: The claim in docs/lemonade.md has been updated to reflect that the build is the fork's main tip pinned by PR Bump Lemonade: 1bit-MONSTER/lemonade f44ff953bcd8 #1126 Non-compliant requirements: None Requires further human verification: None

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

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Inconsistent SHA Reference The documentation states that the Lemonade pin is the sha (ef0f3b49), but this is no longer accurate as the current pin is f44ff953. The fix updates the documentation to clarify that the pin is ef0f3b49 at c19, but this still leaves a potential for confusion as the SHA reference is not updated to reflect the current state. The Lemonade pin is the sha (`ef0f3b49` at c19), not the string around it: `tools/version.py` derives the dev version as `<week>.0~<commit count>.<sha>`, and that count is the number of commits in the **checkout it was built in** — `third_party/lemonade` is a `shallow = true` submodule, so a depth-1 clone reports `~1` for the same commit while a

[bong-water-water-bong]

VERDICT: READY

Re-verdicted at 85cf94ae. The pointer now says what happened, and every figure in it matches this fleet's own release record:

• c26 written at 14:37 with vm-check 75 / 0 / 3, --check 31 rows, 0 failed, READBACK: MATCH for 9,128,902,656 B - the 14:37 entry in TRELEASE-3-STATE.md;
• its board boot failed at ~15:0x with Waiting for partition [1BIT-DATA]... failed, and the root cause is the right one: the kernel published sda1 sda2 at 45.7 s behind two USB mass-storage resets while wait_for_blkid() polls 15 s - the "ORCHESTRATOR … c26 BOARD BOOT FAILED" entry, and "not a c26 regression" matches the byte-identical vmlinuz/initrd.gz note there;
• c27 as the current artifact: one file changed (/1bit/initrd.gz), 120 s wait, the still waiting for [1BIT-DATA] console line, #1160's 90 s build guard, vm-check 75/0/3 on its bytes, usbgate PASS, prepare-stick --check PASS - all of that is the c27 entry (TRELEASE-3-STATE.md:12383-12387), including "proven both ways: the c26 initrd fails that row, c27's passes", which is the same gate I ran myself against c26's image earlier tonight;
• and it is now honest about what remains: "Its board boot is the step still owed", so v2026.44 stays a draft.

The "as of 2026-11-05 16:5x" stamp is the part that makes this survive its own subject moving; the only thing I would add is the same treatment for the usbgate/prepare-stick row the moment c28 exists. Not a blocker - it is a date, not a claim.

Everything else from my a7422110 review stands: releases.md:85's "ef0f3b49 at c19", the docs/lemonade.md:20 31-of-31 against HRX's own row at :124, the hw-gate.md three-runs rule at scripts/hw-gate.sh:506-516, engine#370 CLOSED.