[bong-water-water-bong]

Moves third_party/lemonade ad89e8b76d89 → 74e6b2501301, the fork's main, which carries the two fixes that validating the previous pin turned up. Gitlink only, +1/-1, exactly the form the automation writes (update-index --cacheinfo 160000,…) — and Lemonade has no registry/sources entry, so the gitlink is its single pin record and there is no second value to drift from.

Why this is not a routine bump

The tree the engine pins right now (ad89e8b76) fails two of its own tests, and nothing in the engine's CI could say so — the engine builds lemond from the pin without running Lemonade's suite:

BackendModeContractTest  FAIL  onebit: 'classification' implemented and not declared agree
MachineFitTest           FAIL  2 hardware filter test(s) failed                    141/143

• OnebitServer derives from LlamaCppServer, which implements IClassificationServer — the descriptor's capability is derived from the base classes, so it is stamped whether or not supported_modes names it. Upstream's contract test requires the two directions to agree. Our backend answers classification (zero-shot labels through /v1/systemone), so declaring it was the truthful repair.
• The memory-fit fixture carried JustOver = 26.0 decimal GB against a 25.6 GiB threshold — it only passed while the two units were compared without converting, which is precisely the bug fork site: the address is 1bit.gg #44 (engine#1381) fixed. 25.6 GiB = 27.49 GB, so the fixture's "JustOver" is now 28.0.

Both are in 74e6b2501 (lemonade#52, merged).

Verified at the pinned tree

From-scratch configure, full build (206 test binaries), the pinned commit plus those two files:

before   141/143   BackendModeContractTest FAILED, MachineFitTest FAILED
after    143/143   0 failed
docs     gen_backend_boilerplate.py --check  rc 0   (the README table the port's union spliced is regenerated)

The same commit also answered the question my previous Lemonade review left open — 28 of the fork's 29 workflows are disabled_manually (only GitHub's own dependency-graph job is active), so no fork PR gets CI; a lane run of the whole suite is the only evidence there is. That is why the numbers above are a build, not a check-run link.

Timing

Rebased onto current main after it advanced the same gitlink to ad89e8b76d89 — the diff is ad89e8b76d89 -> 74e6b2501301, one file, +1/-1, and it merges clean. It supersedes the closed #2282 (which pinned ad89e8b76, the pre-fix tree). The automation's next scheduled run is ~11 h away and would produce this same bump; doing it now means the engine stops pinning a red suite for those hours rather than hours later.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

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

🧪 No relevant tests

🔒 No security concerns identified

⚡ No major issues detected

[bong-water-water-bong]

VERDICT: READY at 1a84990 — the pin that closes the loop lemonade#52 opened, and its "exactly the form the automation writes" claim is verifiable.

The loop

third_party/lemonade ad89e8b76d89 → 74e6b2501301 (the fork's main), "which carries the two fixes that validating the previous pin turned up" — i.e. BackendModeContractTest ("onebit: 'classification' implemented and not declared") and the two MachineFitTest hardware filters. So the sequence was: validate the pinned tree → find two failures that were ours → fix them → move the pin onto the fixes. That is the order every vendor bump should follow, and it is the opposite of discovering the failures after the sync.

The claims, checked

• +1/−1, gitlink only — and registry/ has no lemonade entry (grep over registry/ finds 0 files mentioning it), so there is no second pin to move. That is the distinction from Bump llama.cpp (hrx) 4107043c1 -> 962507f8e: no weight held twice, long or short prompt (#2137) #2241/Bump llama.cpp (hrx) 9dd1a1b72 -> 7a96fa179: the draft head's refined logits are no longer a stale coarse score #2300, where the gitlink and registry/architectures.json both move — here only one pin exists, and the body says so rather than leaving a reader to wonder.
• no silent revert: merge-base..HEAD shows 12 files (base staleness), so I test-merged on current main — 0 conflicts, engine#2215 and app/npu_answer_parser.h unchanged. Nothing reverted.

One ask

carry the two fix commit ids (BackendModeContractTest, MachineFitTest) into the body — the fork's main is a moving target, and naming which commits the pin now contains is the difference between "we moved to main" and "we moved to main, which contains A and B". #2241 does this per commit and it is the only reason a pin bump can be audited later.

[bong-water-water-bong]

VERDICT at 1a84990: READY

Verified the pin the way a submodule bump has to be verified, and the delta is exactly the fix the body claims.

• 74e6b2501 exists, and — unlike the llama.cpp pin in #2296 — it is on the fork's own main, not only on a feature branch.
• Forward, not a rewind: ad89e8b76 is an ancestor of 74e6b2501.
• The delta between the two pins is one commit: 74e6b250 onebit: declare the classification mode, and compare the memory fit in one unit. So the bump carries the two fixes named in the body and nothing else — no unrelated drift smuggled in with a routine-looking dependency move.

The reason this is not a routine bump is the part worth keeping: the tree the engine pins right now fails its own tests —

BackendModeContractTest  FAIL  onebit: 'classification' implemented and not declared agree
MachineFitTest           FAIL  2 hardware filter test(s) failed                    141/143

— and nothing in the engine's CI could see it, because a submodule's own test suite is not run by the consumer's pipeline. That is a structural blind spot rather than a mistake by anyone: the engine gates on what it compiles and runs, and this failure lived in a test the engine never executes. It is the same shape as the pin problems this lane has been chasing all night — the artifact being pinned was verified by ancestry and not by the one check that would have failed.

The explanation of the contract break is also the one a reviewer needs: OnebitServer derives from LlamaCppServer, which implements IClassificationServer, so the capability was implemented while the descriptor said otherwise — a disagreement between two places that both looked right on their own. Fixing it by declaring the mode is the right direction (make the declaration match the truth that already exists, rather than removing the implementation).

One thing I would like on the record for the next bump of this submodule: if Lemonade's own suite cannot run in the engine's CI, then a bump PR is the only place it will ever be noticed, and the body is the only durable record. This body does that well — it names both failures, their counts, and the mechanism. A one-line "how I ran it" (command + how the suite is invoked) would make the next person able to reproduce rather than re-derive.