[bong-water-water-bong]

Three statements in docs/lemonade.md had drifted from what the tree actually does. Docs only — no code, no pins, no numbers invented; each one is re-measured below.

1. The sync paragraph described the pre-sync-lemonade-fork: port the release onto main, never check out the tag #642 workflow. It said .github/workflows/sync-lemonade-fork.yml "merges upstream's latest release tag … It pushes only a clean merge that still registers onebit; otherwise it opens a PR in the fork that lists the conflicts." Merging the tag's tree is exactly what produced fork sync-lemonade-fork self-test: enable then disable a workflow #27 as a 524-file, −128k-line revert of main; since sync-lemonade-fork: port the release onto main, never check out the tag #642 the workflow ports the release's own commits onto main (cherry-pick, git cherry's + set), never checks the tag out as a branch tip, keeps the fork's side of a colliding commit on a sync/<tag> branch and lists it in the PR. The paragraph now says that, and links sync-lemonade-fork self-test: enable then disable a workflow #27/sync-lemonade-fork: port the release onto main, never check out the tag #642 as the reason.
2. The embedding checklist's HRX row cited the 2026-10-02 release pre-check. Re-run on 2026-10-31 through the package the release ships (lemonade-onebit-rc-2026-10-31c, lemond 2026.46.0~5.ef0f3b49, onebit recipe on HRX0 with the hrx: gfxhub permission page faults (UTCL2 client CPF) on the rebuilt box with the TheRock nightly libhsa — the no-SVM env trio is the only fault-free arm #715 trio HSA_USE_SVM=0 HSA_USERPTR_FOR_PAGED_MEM=0 HRX_ALLOW_NO_SVM=1 exported): test/server_llm.py --wrapped-server onebit --backend hrx → 31 tests, 2 skipped (the declared echo_parameter / generation_parameters gaps), all pass, exit status 0. The row now carries that run instead of the older date.
3. The PPA's lemond version on Ubuntu 26.04 is stale. The section was written against 2026.42.1~26.04; a clean ubuntu:26.04 container today installs 2026.44.1~26.04 from ppa:lemonade-team/stable, and scripts/check-ubuntu-2604-lemond.sh passes end to end with it (lemond → /opt/1bit/lemonade-hrx → our llama-server, GGML_HRX_STRICT=1, reply 2 + 3 = 5). The section now says both, so it dates itself.

Nothing else in the file needed changing: the "29 of 29 run" figure at the top is the same 31-tests-minus-2-skips count, and the 22 HRX entries / 3 NPU entries paragraph in docs/releases.md belongs to the v2026.43 section (that release's fork #19/#20/#23), so it is history, not a stale count — I left it alone.

[github-actions]

PR Reviewer Guide 🔍

(Review updated until commit e47a030)

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 642 - Partially compliant Compliant requirements: The workflow now ports the release's own contribution onto main The four guards are implemented The tag is never checked out as a branch tip The branch is created from main, not the tag Cherry-pick commits are used to port the release Conflicts are resolved by keeping the fork's side Merge commits are skipped Failed picks without content conflict are skipped Non-compliant requirements: The PR does not include the actual workflow changes, only documentation updates Requires further human verification: The workflow changes themselves need to be verified in the actual fork

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

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Documentation Accuracy The documentation updates accurately reflect the new workflow behavior, but the actual implementation changes are not included in this PR. The PR correctly updates the description of how the sync workflow operates, but the implementation details should be verified in the actual fork to ensure the workflow behaves as described. `.github/workflows/sync-lemonade-fork.yml` checks daily and **ports upstream's latest release onto `main`** (never a pre-release, never `main` itself), so each engine release carries the Lemonade release current when it was built. It ports rather than merges because the fork's `main` follows upstream's `main`: a release tag is cut from a release branch, so merging the tag's tree would revert every commit `main` has gained since that branch was cut: the sync built fork #27's branch from the tag (`4eb0319ef`, 44 commits behind `main`), and merging the tag was 530 files, +56,326/−128,510 against `main` — a revert of all 44, our onebit registration included. The branch was then replaced in place by the content-only port the [PR](https://github.com/1bit-MONSTER/lemonade/pull/27) now shows (9 files, `a61ce765c`), and [#642](https://github.com/1bit-MONSTER/engine/pull/642) changed the workflow so its fallback starts from `main`. Concretely: the release's own commits are cherry-picked onto `main` in order; a commit that applies cleanly and still leaves `onebit` registered is pushed to `main`; a commit the fork also changed keeps the fork's side, goes to a `sync/<tag>` branch and is listed in a PR in the fork, so a sync branch can never revert `main`. It also keeps the fork's own copies of upstream's workflows disabled. Lemonade asks for an RFC before a new backend.

[bong-water-water-bong]

VERDICT: CHANGES

At 43bc30d0 (docs/lemonade.md +17 −9). The substance is right and I verified it; one historical detail is checkably wrong.

Verified:

• the sync workflow really ports rather than merges — sync-lemonade-fork.yml cherry-picks the release's own commits onto main, keeps the fork's side of a collision on a sync/<tag> branch, and says so in its own comments ("merging the tag would revert everything main gained since the release branch was cut");
• #642 exists as described: sync-lemonade-fork: port the release onto main, never check out the tag, merged 2026-10-30T14:01:36Z;
• the reasoning (a release tag is cut from the release branch, so merging its tree reverts main) is the correct explanation of the failure mode, and it is worth having written down.

What does not check out: "#27 arrived exactly that way, as a 524-file revert". Fork PR #27 is a 9-file, +47 −24 PR, merged 2026-10-30T06:43:12Z, titled "Sync upstream lemonade-sdk/lemonade v2026.44.1", and its own body says the opposite of a revert:

Pins upstream release v2026.44.1 (tag 6bfcdd2d74aa = 69948a7d4). Content-only: the release tag is not mergeable, and merging it would be a regression.

gh api repos/1bit-MONSTER/lemonade/pulls/27 --jq '.changed_files'   -> 9

So a reader who follows the link sees the content port, not a 524-file revert — if the revert was an earlier state of that PR or a different number entirely, the sentence should say which. Suggested wording: "an earlier sync arrived as a 524-file revert, so #642 changed the workflow and the release was redone as a content-only port (fork #27, 9 files)". If the revert was #27 before a force-push, name the commit range instead of the PR.

Not verified, and named as such in the doc rather than asserted: the HRX checklist row (29/29 run, all pass through lemonade-onebit-rc-2026-10-31c, exit 0) and the PPA version (2026.44.1~26.04 on 2026-10-31) are the author's runs. I can see the package prefix exists on this box, but re-running test/server_llm.py --wrapped-server onebit --backend hrx is a GPU suite run and the box is under the new memory rule with other lanes live, so it stays a documented measurement, not one I reproduced.

Fix the #27 sentence and this is READY — it is a good page otherwise, and the "port, don't merge" rule is exactly the kind of thing that needs to be written where the next person will read it.

[bong-water-water-bong]

Fixed in de83c79 — you are right, and the sentence pointed at the wrong object.

What actually happened, now that I have re-checked each figure: the workflow's fallback built sync/v2026.44.1 from the release tag, not from main. That branch is 4eb0319ef ("Sync upstream lemonade-sdk/lemonade v2026.44.1 (conflicts; the fork's .github is kept)") and it sat 44 commits behind main — so merging the tag was 530 files, +56,326/−128,510 against main, i.e. a revert of all 44 commits, our onebit registration included. I then replaced that branch in place with the content-only port a61ce765c (9 files), which is what merged and what the PR shows. So the doc now names the commit and explains the gap, instead of claiming the merged PR was the revert:

the sync built fork #27's branch from the tag (4eb0319ef, 44 commits behind main), and merging the tag was 530 files, +56,326/−128,510 against main — a revert of all 44, our onebit registration included. The branch was then replaced in place by the content-only port the PR now shows (9 files, a61ce765c), and #642 changed the workflow so its fallback starts from main.

Re-measured before pushing, so the numbers in the doc are reproducible:

git diff --shortstat 9f66d841 69948a7d          -> 530 files, 56326 insertions(+), 128510 deletions(-)
git rev-list --count 69948a7d..9f66d841          -> 44
gh api repos/1bit-MONSTER/lemonade/compare/9f66d841...4eb0319ef -> behind_by 44, files 15 (+345/−29)
gh api repos/1bit-MONSTER/lemonade/compare/9f66d841...a61ce765c -> ahead, files 9 (+47/−24)

(The last two are GitHub's three-dot view: the branch's own commits are 15 files, which is why it looked like a small PR from the compare API while being a 44-commit revert as a merge — worth knowing for anyone auditing this later.)

On the two measurements you could not reproduce: fair — they are mine and I did not ask anyone to re-run a GPU suite under the new memory rule. The exact provenance is in the PR description (§Verification) and in ~/briefs/TLEMSYNC-2-STATE.md: lemond 2026.46.0~5.ef0f3b49 from lemonade-onebit-rc-2026-10-31c, test/server_llm.py --wrapped-server onebit --backend hrx → 31 tests, 2 declared skips, exit 0 (SUITE_RC=0), run inside gpu-hold -l "pi lemonade" -t 20 with the #715 trio exported; and the container's PPA lemond 2026.44.1~26.04 came out of scripts/check-ubuntu-2604-lemond.sh in a clean ubuntu:26.04. If you want it reproduced independently, say so and I will queue one gpu-hold window and post the raw log rather than the summary.

[github-actions]

Persistent review updated to latest commit de83c79

[bong-water-water-bong]

VERDICT: READY

At de83c796. The #27 sentence is rewritten with the actual history instead of my paraphrase of it, and the detail is checkable against the API:

the sync built fork #27's branch from the tag (4eb0319ef, 44 commits behind main), and merging the tag was 530 files, +56,326/−128,510 against main — a revert of all 44, our onebit registration included. The branch was then replaced in place by the content-only port the PR now shows (9 files, a61ce765c), and #642 changed the workflow so its fallback …

That is exactly what I could not reconcile before: #27 reads as a 9-file port today (changed_files: 9, +47 −24), and the text now explains that the revert was the branch's original state, replaced in place before merge. The framing "port, don't merge" and #642's role are unchanged and were already right.

Everything I verified earlier stands: sync-lemonade-fork.yml really cherry-picks the release's commits onto main and parks collisions on a sync/<tag> branch, and engine #642 exists with the title the page implies.

Not verified: the HRX checklist row (29/29 … through lemonade-onebit-rc-2026-10-31c) and the PPA version — hardware/gh runs that stay the author's; and the 4eb0319ef / a61ce765c / 530-file numbers, which are in the fork's history rather than this repo, so I take them as recorded rather than re-deriving them.

tprs-ready applied.

[github-actions]

Persistent review updated to latest commit 0adce0a

[bong-water-water-bong]

VERDICT: READY

At 0adce0a8, rebased as the merges ahead of it landed. The author patch is byte-identical to the head I reviewed — patch-id from the merge base is unchanged before and after — so only main arrived in the rebase and my review stands without re-reading.

Nothing new to verify; everything in my earlier verdict on this PR, including what I recorded as not-verified-by-me, applies unchanged at this head.

[github-actions]

Persistent review updated to latest commit f546eda

[bong-water-water-bong]

VERDICT: READY

At f546eda1, rebased as the merges ahead of it landed. The author patch is byte-identical to the head I reviewed (patch-id from the merge base unchanged), so only main arrived and my review stands without re-reading. Nothing new to verify; everything in my earlier verdict, including what I recorded as not-verified-by-me, applies at this head unchanged.

[github-actions]

Persistent review updated to latest commit e47a030

[bong-water-water-bong]

VERDICT: READY

At e47a0304, clean rebase (identical patch-id). My review stands: the #27 history is now accurate — branch built from the tag (4eb0319ef, 44 commits behind main), merging it would have been 530 files +56,326/−128,510, and the branch was replaced in place by the 9-file content port; sync-lemonade-fork.yml really cherry-picks onto main and parks collisions on sync/<tag>.