[bong-water-water-bong]

third_party/laya: 118d361a774c -> 55a19f7b7b56 (NandhaKishorM/laya main). config/laya.json revision: 7b928d828b7b -> 7b928d828b7b (convaiinnovations/laya).

Before merging: scripts/fetch-laya.sh

(verifies every file) and the Laya tests.

[bong-water-water-bong]

VERDICT: READY — tprs-ready applied (build was still running when I posted; if it comes back red I pull the label). A one-line pin bump, and everything around it is consistent.

The diff is one line: third_party/laya 118d361a774c -> 55a19f7b7b56. Nothing else moved, which is right — nothing in the tree still references the old commit (grep -rn 118d361a finds only the submodule pointer), and the engine does not compile or link against this submodule at all (third_party/laya appears in no CMakeLists), so a code bump of it cannot break the build. The router the engine actually runs is its own C++ implementation (laya/route.cpp, laya/route.h) against the ggmlc daemon's scorer; tests/laya_route_cases.json is engine-owned (200 hand-labelled requests, generated by tests/laya_route_cases.py) and does not come from the submodule.

The pin: 55a19f7b7b56 is the tip of NandhaKishorM/laya main, commit "release: 0.4.19" (2026-10-31 05:14Z), and 118d361a...55a19f7b is a clean fast-forward — ahead_by 11, behind_by 0, so nothing was rewritten and nothing is lost. The 11 commits are upstream's own: routing diagnostics over HTTP, serve routing admission/cancellation tests, the LAYA_CUDA_AMP rejection fix, SDK timeout bound, docs and a 515-line tests/test_serve.py. No vendor or engine-specific patch in there.

Checked out and imported: git submodule update --init third_party/laya -> 55a19f7b7b56, 63 MB, and import laya reports 0.4.19.

Model revision correctly untouched: config/laya.json still pins convaiinnovations/laya at 7b928d828b7b…, so scripts/fetch-laya.sh's per-file hashes are unaffected and no re-download is implied by this bump. (The body's table writes that revision as 7b928d828b7b -> 7b928d828b7b, which is accurate but reads like a typo — worth writing as "unchanged" next time, and the value is 40 hex chars, not 12.)

Two notes, neither blocking:

• laya/router.py +59/-7 and laya/agent.py +42/-17 upstream mean the reference classifier moved. The engine's C++ router parity claim (95.5 % on tests/laya_route_cases.json, the same as the C++ scorer on the safetensors) is validated by laya_gate* against external goldens (ONEBIT_LAYA_GOLDEN), not against anything in this PR — so if those goldens came from an older reference, they are now one revision behind and should be regenerated when someone next runs that gate. Nothing in CI covers it (the gate tests are not registered without ONEBIT_LAYA_ROOT).
• The body's pre-merge step (scripts/fetch-laya.sh <dir> plus the Laya tests) needs the 2.3 GB of checkpoints; I did not run it on a box with 71 GB free and a 150 GB floor. Everything that can be checked without the weights is above.

[bong-water-water-bong]

VERDICT: READY

Gate line for the protocol, at head 9114357 (current). build pass now (it was still running when I first posted the review; the verdict was conditional on it and the condition is met), MERGEABLE, tprs-ready applied.

The diff is one line, third_party/laya 118d361a774c -> 55a19f7b7b56, and everything around it checks out: the target is the tip of NandhaKishorM/laya main ("release: 0.4.19"), the range is a clean fast-forward (ahead 11, behind 0, all upstream commits — routing diagnostics, serve admission tests, the LAYA_CUDA_AMP fix, docs, a 515-line tests/test_serve.py), the submodule checks out and imports as laya 0.4.19, config/laya.json's model revision is correctly untouched (so fetch-laya.sh's per-file hashes are unaffected), and no stale reference to the old commit remains. The engine does not compile or link against this submodule at all — its router is C++ in laya/route.cpp — so the bump cannot break the build.

Noted, not blocking: upstream's router.py +59/−7 and agent.py +42/−17 mean the laya_gate goldens (ONEBIT_LAYA_GOLDEN, external, not registered in CI) are one reference revision behind; and the body's pre-merge fetch-laya.sh step needs the 2.3 GB of checkpoints, which I did not download on a box at ~70 GB free.

[bong-water-water-bong]

VERDICT: READY

At head 33722f5 (post-update, main merged in), build pass, MERGEABLE, tprs-ready applied.

The merge added no author change — the PR is still exactly one line:

$ git log --oneline --no-merges origin/main..33722f5
9114357 Bump Laya: source 55a19f7b7b56, model 7b928d828b7b
$ git diff --stat origin/main 33722f5
 third_party/laya | 2 +-                              # 118d361a774c -> 55a19f7b7b56
$ git merge-base --is-ancestor origin/main 33722f5    # yes

Everything from my review carries: the pin is the tip of NandhaKishorM/laya main ("release: 0.4.19"), a clean fast-forward (ahead 11, behind 0), the submodule imports as laya 0.4.19, config/laya.json's model revision is untouched, nothing else in the tree references the old commit, and the engine does not link against this submodule so the bump cannot break the build. The laya_gate goldens being one reference revision behind stays a note, not a gate.