[bong-water-water-bong]

Moves third_party/llama.cpp (1bit-MONSTER/llama.cpp 1bit/hrx-vulkan-patched) d8d2f5b39f22 → 5e6388a5a852.
Third-party hrx-system is not moved — see the next section for why the pin line still names 82804197bcbe.

Rebased onto main 8b6895e (was one commit behind; nothing else changed — the diff is still the single llama.cpp
gitlink).

	from	to
third_party/llama.cpp (1bit/hrx-vulkan-patched)	d8d2f5b39f22	5e6388a5a852
third_party/hrx-system (1bit/main)	82804197bcbe	82804197bcbe (held, unchanged)

hrx-system stays at 82804197bcbe — what that commit is, and why we do not move it here

82804197bcbe is the commit config/hrx-system-hold.config names (the hold is an owner decision, engine#388) and the
commit config/hrx-long-prompt-validated-pin.config records as having passed the long-prompt HRX check. What it
carries, on top of the AMD core of the day: hrx-system#8 — util/no_svm_gate.c, which lets the amdgpu HAL open a ROCr
that reports no SVM (HRX_ALLOW_NO_SVM=1 with HSA_USE_SVM=0), so 1bit serve can put the CWSR save area in GTT on a
CWSR-on box (engine#315, app/hrx_cwsr.h); plus the engine#409/#410/#401 fixes and our ROCm/hrx-system#1535 multi-unit
live-out guard. The long-prompt check passed at it (tests/hrx_long_prompt.py PASS twice, 7082-token prompt, needle 7341).

Moving hrx-system is exactly the class of change that broke main before, which is why this bump does not touch it:

• hrx-system 4ba76c18eafe (2026-10-08) left main unbuildable with ONEBIT_HRX=ON: the pinned
  ggml/src/ggml-hrx/loom-jit.cpp used LoomC API that revision removed (loomc_amdgpu_runtime_global_flags_t,
  loomc_amdgpu_emit_options_t); reverted in fix: keep hrx-system at 98d05d94 so main builds with ONEBIT_HRX (#361 half-bumped the pair) #363, and hrx-pins-guard.yml now syntax-checks that translation unit
  against the pinned headers (see the check result below);
• with the loom-jit.cpp port (fork serve --device hrx: default the context to 32768 so HRX0 keeps flash attention (#95) #97) that revision compiles but answers immediate end-of-text on a 4.7K-token
  prompt where 98d05d94 answers (hrx-system 4ba76c18eafe: Qwen3-0.6B returns end-of-text at once on a 4.7K-token prompt (98d05d94 answers) #369) — so a symbol check is not enough for an hrx-system move; it needs the
  multi-ubatch prompt check (KNOWN-ISSUES.md:319-324).

tools/check_pins.py:42-46 gates only the hrx-system pin against the validated-pin file, so a llama.cpp-only bump
needs no re-record — and the hold/gitlink agreement check in hrx-pins-guard.yml passes because the tree still pins the
held commit.

Six commits ride in this bump (not three)

The request named #157/#158/#159 "on top of the current pin"; the fork's line is six commits past our pin, so all six come
with it. git merge-base --is-ancestor d8d2f5b39f22 5e6388a5a → forward, no rollback, no "pin rollback" label needed.

• fe04824 ggml-hrx: an env-gated host-gap profiler (engine HRX: Qwen3.8-Flash-Next prefill is 287 tok/s on UD-IQ4_XS vs 1,679 for gufo on the same box (and 500-2,400 across published Strix Halo engines) #572) (MoE streaming: prefetch off the decode path, time split measured (pin llama.cpp-vulkan a29be7f) #154) — the instrument the Flash-Next numbers come from
• b8861a9 kv: verify the zero padding of the KV cache, and repair it (engine HRX: Qwen3-4B --parallel 4 NaN logits on a never-used slot while another GPU job runs (CWSR off) #528) (Issue forms: bug report, model request, feature request; no blank issues #155)
• 9e8453a model: DeepSeek-V4.1-Flash (deepseek41) port of upstream #31086 + #31300 (moe_policy: ARC, LRU-2, W-TinyLFU replayed; none beats the shared LRU #156) — a new architecture
• f61f290 dsv41: drop the dead llm_arch_supports_mixed_batch definition (RFC: CI fails a pull request that moves a submodule pin backwards #157)
• 01d7df4 dsv41: the deepseek41 and DSpark graphs never expanded their output (RFC: issue agent — first pass on outside issues with the local model #158)
• 5e6388a ggml-hrx: GET_ROWS for a table over 262208 rows (engine HRX: Qwen3.8-Flash-Next prefill is 287 tok/s on UD-IQ4_XS vs 1,679 for gufo on the same box (and 500-2,400 across published Strix Halo engines) #572) (CI: submodule pins only move forward; issue agent for outside issues #159)

git diff --stat d8d2f5b39f22 5e6388a5a: 44 files, +4,289 / −209 — the new arch (src/models/deepseek41.cpp),
dflash.cpp, the KV zero-padding repair, the GET_ROWS matcher + bound, the profiler, and their tests
(tests/test-backend-ops.cpp +92, test-kv-zero.cpp +147, test-llama-archs.cpp).

Checks

check	result
hrx-pins-guard — hold/gitlink agreement	PASS: config/hrx-system-hold.config names 82804197bcbe, the tree pins 82804197bcbe → MATCH
hrx-pins-guard — pinned loom-jit.cpp compiles against the pinned hrx-system (the #363/#369 trap)	PASS: g++ -fsyntax-only -std=c++17 -I third_party/hrx-system/loom/binding/c/include -I third_party/hrx-system/libhrx/include third_party/llama.cpp/ggml/src/ggml-hrx/loom-jit.cpp, run in this PR's worktree with the submodule at 5e6388a
tools/check_pins.py	expected pass: new pin is an ancestor-checked descendant; hrx-system unchanged
CI build / CodeQL / Analyze	hosted CI compiles without HRX, so the changed backend is only compiled by the runs below
ctest at the new pin	running (weekly.sh … build test, WEEKLY_REF = this PR's head sha) — comment when done
hw-gate at the new pin (ops, fa-decode-q8, kat, kld, needle, placement)	running on strixhalo — comment when done
zp-rehearse path (package + release-dry at the new pin)	running in the same run — comment when done

Nothing is merged by me. Once pi-prs posts READY and the checks on the head are green, the orchestrator squash-merges.

Flash-Next pp512, before/after (#159, engine #572)

Before: 283.9 tok/s on Qwen3.8-Flash-Next-UD-IQ4_XS (established baseline: cand-next build, engine 0d0c846 +
gpu-kernels 2b626798a, ~/briefs/TISSUES-572.md).

After: not measured yet. The i572 lane has the re-measurement building (~/wt/i572-pin = engine main with the pin at
5e6388a) but the 87.3 GiB model needs ~100 GiB free and the box has been at ~34-56 GiB (a 27B spec-decode server holds
the GPU token), so their runner exits instead of thrashing. Their earlier Flash-Next files (fn-gap.json 285.18,
prof-fn.json 288.21 at build 33308a1; r16-* 166.8-263.7 at b1fccd9) are other arms (lazy auto/off A/B, and the
pre-#159 build), not an #159 before/after — quoting them as one would be wrong. This PR claims the commits, not a #159
win; the number lands on #572 when the model fits.

[bong-water-water-bong]

VERDICT: READY (posted as a comment: GitHub refuses --request-changes/--approve on a PR owned by the same account). One deferred item and two nits, all stated below — the bump itself is sound and I compiled the new pin with HRX on this box.

The change is the gitlink and nothing else. third_party/llama.cpp d8d2f5b39f224 → 5e6388a5a852, third_party/hrx-system held at 82804197bcbe. GitHub's diff for the PR is one file; the six-commit narrative in your body matches the fork (git rev-list --count d8d2f5b39f22..5e6388a5a852 = 6, git merge-base --is-ancestor d8d2f5b39f22 5e6388a5a852 passes, so forward, no rollback).

Pin machinery, run here:

$ python3 tools/check_pins.py origin/main
ok   third_party/llama.cpp: d8d2f5b39 -> 5e6388a5a is ahead        rc=0
$ python3 tests/check_pins_test.py
Ran 3 tests … OK                                                   rc=0

and the long-prompt gate is satisfied the way your body says: it keys on third_party/hrx-system only (tools/check_pins.py:42-46), that pin is unchanged and equals the sha named in config/hrx-long-prompt-validated-pin.config (82804197bcbe…), so no probe re-run is owed. CI agrees — hrx-system gitlink agrees with the hold file and pinned loom-jit.cpp compiles against the pinned hrx-system both pass, and there are no failing checks on this head (MERGEABLE/BEHIND).

The one thing CI cannot do, done here: bump-hrx.yml itself says "CI here builds without HRX", so I built the new pin with the HRX configuration (amdclang from /opt/rocm-therock, -DGGML_HRX=ON -DHRX_SOURCE_DIR=<hrx-system> -DGGML_NATIVE=ON, thermal-run, -j 4) at 5e6388a5a:

[409/412] Linking CXX executable bin/llama-server
warnings: 0
$ bin/llama-server --version
version: 10701 (5e6388a5a)          built with Clang 23.0.0
$ nm -DC bin/libggml-hrx.so.0.18.0 | grep -c host_gap   ->  3      (#154's profiler is in)
$ grep -c "536870911\|536870912" …/loom-libs/ops/get_rows_f32.loom -> 3   (#159's bound is in)

So the llama.cpp half of this bump compiles clean on the HRX path, with #154/#155/#156/#159 present in the built library. (I also reviewed #154, #155, #156 and #159 individually as they landed — this bump is those four plus #157/#158, and none of them touches an engine file.)

Deferred, with the reason: the rest of your own pre-merge list — test-backend-ops -b HRX0 at this pin, the engine-side onebit HRX build, and tests/serve_e2e.sh … hrx cpu — is not run. / is at 145 GB free, below the lane's 150 GB floor, and those three want a multi-GB engine tree plus the 87 GiB model's page cache on a box the release lane is also using. I freed what was mine (~2.5 GB of my scratch) and stopped there rather than start a build under the floor. Say the word once disk is back above the floor and I will run exactly that recipe and post the result here; nothing I have seen suggests it will fail.

Two nits:

1. This branch is one commit behind main (merge base da9d75f59 = main minus #647), so the CI that went green on this head never built the -DONEBIT_ORT=ON tree. A squash merge keeps #647 (the PR's diff is only the gitlink), but the combination — ONNX targets with llama.cpp 5e6388a5a — has never been compiled. I built main's ONNX state at the old pin (36/36, four ctests green) and the fork at the new pin (above); one combined build after the merge would close it.
2. The body explains the held hrx-system pin well, but the reason no long-prompt probe was run is that the pin did not move — worth one clause in the "held" line so a later reader does not think the probe was skipped by accident.

[bong-water-water-bong]

VERDICT: CHANGES. Two blockers, both reproduced here, plus one correction to the brief.

1. build is red on this head, and the failure is the bump itself. 34 - registry_pins (Failed) on run 41141854509 (head 1214c6dc7, 23:01Z). Repro locally on the PR head:

$ python3 tools/registry_build.py --check-pins
registry/architectures.json: llama.cpp (hrx) recorded at d8d2f5b39, pinned at 5e6388a5a
a pin moved without regenerating the registry: check out the submodules at their pins
(git submodule update --init) and run tools/registry_build.py

The submodule pointer moves but registry/architectures.json still records the old llama.cpp (hrx) sha, so add_test(NAME registry_pins …) (CMakeLists.txt:404) fails. Fix: run tools/registry_build.py with the submodules at their pins and commit the regenerated registry in this PR. Note the bump bot has no such step — grep -c "registry_build\|architectures.json" .github/workflows/bump-hrx.yml on main = 0 — so this will recur on every bump until the workflow regenerates it as part of the PR.

2. hw_gate did not run — it skipped, so nothing has validated this pin on hardware. On head 1214c6dc7:

hw_gate: skipped    [2026-10-30T23:01:27Z]

The job condition is … (contains(labels,'hw-gate') || startsWith(head.ref,'bump-hrx/')); this PR's branch is 1bit/bump-hrx-5e6388a5 and it carries no labels, so neither arm matches. It is a naming regression, not a decision: the previous HRX bump #659 (bump-hrx/d8d2f5b39f22-82804197bcbe) got hw_gate=SUCCESS on the same bot, and #630 (1bit/bump-hrx-tests-cmakelists) skipped for the same reason. So the hardware gate has silently stopped covering HRX pin bumps. Two ways to fix: re-run this one with the hw-gate label, and put the bump-hrx/<llama>-<hrx> branch naming back in the bot (or widen the workflow's prefix test to contains(head.ref,'bump-hrx')).

3. Correction: only one pin moves, so there is no hrx-system move to justify.

origin/main                       third_party/llama.cpp  d8d2f5b39f2240…
origin/1bit/bump-hrx-5e6388a5     third_party/llama.cpp  5e6388a5a8522…      <- the move
both refs                         third_party/hrx-system 82804197bcbe0…      <- unchanged

and the PR diff contains exactly one Subproject commit hunk. 82804197bcbe is what config/hrx-long-prompt-validated-pin.config names, and the long-prompt gate keys on third_party/hrx-system only (tools/check_pins.py:42-46), so the body's "held, therefore no probe re-run owed" is correct and is why hrx-system gitlink agrees with the hold file and pinned loom-jit.cpp compiles against the pinned hrx-system both pass. The llama.cpp sha is exactly the stated 5e6388a5a852281c6929303c1219665b2a6d4c0a, forward from d8d2f5b39f224 by six commits, no rollback.

Verified good, for the re-review after the two fixes: tools/check_pins.py origin/main → ok third_party/llama.cpp: d8d2f5b39 -> 5e6388a5a is ahead, tests/check_pins_test.py → 3 tests OK, and I compiled the new pin with the HRX configuration on this box (amdclang + TheRock + the hrx-system tree, thermal-run): 412 targets, llama-server links, 0 warnings, version: 10701 (5e6388a5a), with #154's profiler symbols and #159's 2^29 GET_ROWS bound present in the built libggml-hrx.so. So the pin content itself is fine; what is missing is the registry regeneration and the hardware gate.

pr_agent: failure is the expected red while coder-llm is off (said once here, not per PR).

[bong-water-water-bong]

registry fix pushed (dd23b01 on top of the bump commit, head now dd23b01).

You were right: registry_pins was red because the registry is generated from the pinned backends and the bump moved one. Reproduced locally at the old head:

registry/architectures.json: llama.cpp (hrx) recorded at d8d2f5b39, pinned at 5e6388a5a
a pin moved without regenerating the registry: check out the submodules at their pins and run tools/registry_build.py

What the fix does, and why it is more than a string:

• registry/architectures.json — regenerated with tools/registry_build.py at the new pin: source string, plus DeepseekV41ForCausalLM → deepseek41, hrx, counts 293 → 294. That map is legitimate at 5e6388a5a: conversion/__init__.py maps the class, src/llama-arch.cpp registers LLM_ARCH_DEEPSEEK41, and src/models/deepseek41.cpp implements hparams/tensors/graph/engram (fork moe_policy: ARC, LRU-2, W-TinyLFU replayed; none beats the shared LRU #156 = upstream #31086 + #31300).
• registry/significant.json — that class had been reviewed as not an alias of deepseek4, so --check-gaps correctly refused the silent map. It now carries a mapped_ok reason (naming the commit and the port) and its family text no longer says the pinned path runs neither.
• docs/arch-gaps.md — dated note for the same fact; the "not mapped" recheck it quotes was against 6b397ee9, before the port existed.
• tests/registry_gaps_test.py — its committed-state invariant was "no reviewed class is a key in the registry". A class the backend legitimately starts to implement leaves that set, so the check is now "every reviewed class the committed registry maps carries a non-vacuous mapped_ok", and the CLI case drives a class that genuinely has no reason (it reads the committed significant.json, so an exempted class could never make it fire).

Green locally at this pin: registry_build.py --check-pins, --check-gaps, tests/registry_gaps_test.py, tests/census_watch_test.py.

Also unchanged from the earlier runs, and still standing evidence for the pair: hrx-pins-guard loom-jit trap check PASS (g++ -fsyntax-only of the pinned loom-jit.cpp against the pinned hrx-system headers) and the hold/gitlink agreement MATCH at 82804197bcbe.

I am re-running build + full ctest + hw-gate at this new head (dd23b01) now and will comment the numbers.

[bong-water-water-bong]

#159 rides in this bump — noted per the orchestrator. Content of the llama.cpp move d8d2f5b39f22 → 5e6388a5a852, oldest first:

commit	what
fe04824	ggml-hrx: env-gated host-gap profiler (#154, engine#572)
b8861a9	kv: verify the zero padding of the KV cache, and repair it (#155, engine#528)
9e8453a	model: DeepSeek-V4.1-Flash port (#156)
f61f290	dsv41: drop the dead llm_arch_supports_mixed_batch (#157)
01d7df4	dsv41: the deepseek41 and DSpark graphs never expanded their output (#158)
5e6388a	ggml-hrx: GET_ROWS for a table over 262208 rows (#159, engine#572)

Two things worth having in the PR record for the #159 part specifically:

1. It is inert on its own, by design. It raises the GET_ROWS id/row bound from the Qwen-vocabulary figure (2^18 + 64) to 2^29 in both the Loom kernel's index.assume and kMaxGetRowsRowCount, with the byte-base proof (320,001,535 rows x 90 B = 28.80e9 < 2^35). No model on this box changes behaviour from it: the tensor that needs it is still pinned to the CPU by the input-layer policy in llama-model.cpp and by LLAMA_LAZY_MODE_AUTO mmapping every tensor over 4 GiB. Measured on a build of exactly this head: pp512 on Flash-Next UD-IQ4_XS, 3 repeats, 281.9 tok/s vs 285.2 tok/s on the previous cand-next build — no change, as predicted.
2. So this bump is safe to merge on that evidence, and it does not close engine#572's item 2. The arm where the gather actually reaches HRX0 (-lzm off -ot 'per_layer_token_embd\.weight=HRX0', which does produce HRX0 88688.02 MiB) is the configuration engine#669 makes unsafe on this box: HRX pins the host weight mmap, MemAvailable went to ~0 with no runner error, and the owner killed the run. HRX: Qwen3.8-Flash-Next prefill is 287 tok/s on UD-IQ4_XS vs 1,679 for gufo on the same box (and 500-2,400 across published Strix Halo engines) #572's remaining two items are parked behind HRX route pins ~107 GiB outside process RSS on a 217 GiB mmap (DeepSeek-V4.1 UD-IQ1_S), independent of -ngl/ubatch/prefetch #669; nothing in this bump depends on them.

Also, since the pin line names hrx-system too: tools/check_pins.py:42-46 only gates the hrx-system pin against config/hrx-long-prompt-validated-pin.config, and this PR holds that pin at 82804197bcbe — which is the validated one — so no long-prompt re-run is implied by the llama.cpp move.

[bong-water-water-bong]

census fix pushed (6a2c5aa, one commit carrying both derived-data fixes on top of the bump; head is now 6a2c5aa).

You were right again — census_watch (ctest 35) was red for the same reason as registry_pins: the watcher's test listed DeepseekV41ForCausalLM among the classes reviewed report-only (#522: "needs real support: engram + candidate blocks"), which is exactly what this pin changes. Reproduced:

FAIL DeepseekV41ForCausalLM is reviewed report-only and documented
FAIL DeepseekV41ForCausalLM report-only -> exit 0, no alert

The entry moves out of the report-only table and becomes an assertion of the opposite: the same model (overhand/DeepSeek-V4.1-Flash-1017-MXFP4-uncensored) is now COVERED, exit 0, with no significant alert and no reviewed_report line — alerting on a class the engine supports is the false alarm this watcher exists to avoid.

registry/census.json itself needs no regeneration: it is the Hugging Face snapshot (date/coverage/raw, written by tools/census.py), not pin-derived.

hw_gate at the actual bump pin: PASS. Run on strixhalo from this PR's worktree (submodules at the pins), from /tmp/hwgate-672b:

## HRX hardware gate: PASS
Commit 6a2c5aa, llama.cpp 5e6388a5a852, hrx-system 82804197bcbe, 718s, Tctl at end 64 C,
amdgpu ring timeouts during the run: 0

25 rows, 0 FAIL: ops 703/703 (20 s), fa-decode-q8 6/6, kat 7 models × 9 cases (0.6b 17 s, zaya1-8b 36 s, 27b 125 s, coder-30b-a3b 52 s, 4b-iq4xs 27 s, 0.6b-kq8 54 s, 0.6b-kvq8 54 s), kld 5/5 (mean KLD ≤ 0.000001, p99 ≤ 0.00004, same top 100.00%), needle 4/4 (7082/7403-token prompts), placement all on HRX on every model (170/193/152/99/99/122/122 graphs, largest 6449 nodes).

Note on my earlier comment: the first hw-gate I reported was measured at main (llama.cpp d8d2f5b3) because weekly.sh's build stage re-checks out WEEKLY_REF and undid a hand checkout — the run above is the one that means anything for this PR, and its summary says 5e6388a5a852.

Locally green at 6a2c5aa: registry_build.py --check-pins, --check-gaps, tests/registry_gaps_test.py, tests/census_watch_test.py, and the hrx-pins-guard loom-jit trap (g++ -fsyntax-only of the pinned loom-jit.cpp against the pinned hrx-system headers) with the hold/gitlink agreement MATCH at 82804197bcbe.

Running now, alone in the workspace: weekly.sh build test package release at WEEKLY_REF=6a2c5aa — ctest (all 51, including registry_pins and census_watch at the new pin) plus the package/release path; numbers in the next comment. (The two earlier attempts died with exit 2 on a tar: File exists in the DwarfStar copy step because I had two weekly.sh runs going against the same workdir at once — my mistake, not the tree's; flagged in my notes as an operational hazard.)

[bong-water-water-bong]

All checks green at the head. 6a2c5aa — weekly.sh build test package release with WEEKLY_REF=6a2c5aa (its own checkout, nothing else running), exit 0, 9m18s:

[21:38:xx] engine 6a2c5aa, NPU runtime ce9fa59, HIP kernels 17a8826
ctest: 100% tests passed, 0 failed out of 51
   37/51 registry_pins   Passed   0.03 s
   38/51 census_watch    Passed   0.97 s
[21:41:14] package rehearsal-hrxbump3: 1bit OS
[21:43:29] release rehearsal-hrxbump3: changes 68b39e94aa1e..6a2c5aa (previous: none)
           3 upstreams moved, 104 engine commits, 0 bumps held → dry run: not publishing

Artifact checks on what that produced:

assertion	result
sha256sum -c SHA256SUMS	4/4 OK — .efi 105,681,536 B · .img.zst 396,007,151 B · changes.json 50,758 B · lemonade tar 37,202,185 B
sbverify --cert …/MOK-Kernel.pem	Signature verification OK
image kernel	7.3.0-rc4-1bit-perfopt (not …-perfopt+)
board driver	ec_su_axb35.ko … 33846 bytes, signer: strixhalo Secure Boot MOK; UKI signed with MOK-Kernel.pem

So, at the head, in one place: hw_gate PASS at 5e6388a5a852 (25 rows, 0 FAIL, 718 s, 0 ring timeouts), ctest 51/51 including registry_pins and census_watch, the zp-rehearse/package path green with a signed image on the appliance kernel, and the loom-jit trap + hold/gitlink agreement PASS. Both derived-data fixes are in 6a2c5aa; nothing is merged by me — yours to squash once pi-prs posts READY.

[bong-water-water-bong]

Why hw_gate was skipping, and the two check caveats.

hw-gate.yml runs only when the head branch starts with bump-hrx/ or the PR carries the hw-gate label:

if: github.event_name == 'workflow_dispatch' ||
    (…head.repo.full_name == github.repository &&
     (…action != 'labeled' || label.name == 'hw-gate') &&
     (contains(labels.*.name, 'hw-gate') || startsWith(head.ref, 'bump-hrx/')))

My branch is 1bit/bump-hrx-5e6388a5 (the per-item PR convention in my lane), so it matched neither. I have added the hw-gate label, which fires the job on this box — it is pending now (41152289987). The run I posted above (/tmp/hwgate-672b, 25 rows, 0 FAIL, llama.cpp 5e6388a5a852, 718 s) is the same gate by hand on the same pins; CI's run is the harnessed version and its status is the one to trust.

pr_agent is red for an environmental reason, not a code one:

##[error]the local model (coder-llm on :8090) does not answer

coder-llm is off on this box (owner's instruction), so the review bot cannot answer. It is red on every PR right now, not just this one — after #636 a queued pr_agent no longer blocks the weekly bumps stage, but a failed one is still a failed check. If the merge criterion is "all checks green", that check needs either coder-llm back on or an explicit waiver; nothing in this PR can fix it.

Everything else on the head is green: build, CodeQL, all four Analyze jobs, hrx-system gitlink agrees with the hold file, pinned loom-jit.cpp compiles against the pinned hrx-system, plus the local ctest 51/51 (incl. registry_pins, census_watch) and the package/release path at 6a2c5aa.

[bong-water-water-bong]

CI hw_gate PASS on the head (41152289987, 15m40s, self-hosted strixhalo) — it went through the FIFO behind another lane's claim and ran on 6a2c5aa / llama.cpp 5e6388a5a852.

Final check matrix on 6a2c5aa:

check	result
hw_gate	pass (15m40s) — 703/703 ops, fa-decode-q8 6/6, kat 7×9, kld 5/5, needle 4/4, placement all-on-HRX
build	pass (4m26s)
CodeQL	pass
Analyze (actions | c-cpp | python | rust)	pass ×4
hrx-system gitlink agrees with the hold file	pass
pinned loom-jit.cpp compiles against the pinned hrx-system	pass
pr_agent	fail — the local model (coder-llm on :8090) does not answer; coder-llm is off by the owner's instruction, so this is red on every PR on this box and no change here can fix it
(local, for the record)	ctest 51/51 incl. registry_pins + census_watch at the new pin; package + release-dry exit 0; sbverify OK; SHA256SUMS 4/4

So the only red is the environmental pr_agent. Everything the pin bump can prove, it proves at 6a2c5aa — yours to squash once pi-prs has looked.