[bong-water-water-bong]

Last piece of the A8W8 QDQ work: the fused group's multiply runs on the array, with the graph's own int8
bytes and the same epilogue as the host path.

What changed

• npu/ort gains gemm_q8_raw: int8 activations and int8 weights written straight into the kernel's
  BOs — no packB, no amax/127, because a quantised graph's bytes already carry its scales — and exact
  int32 accumulators back, M rows per launch. It reuses the existing State, so the device lock is still
  taken once per process, and a QDQ kernel is built on demand for a (K, N).
• onnx/ep/onebit_ep_kernel.cpp: gemm_q8 tries the device and falls back to the host loop (no ELF for
  that shape, busy device, XRT failure). The epilogue — scales, zero points, rounding — is one function
  shared by both paths, so a device run and a host run of the same graph cannot differ unless the
  accumulator does, and an exact integer accumulator cannot.
• Proof: a quark-o case at o_proj's real shape (5×2048×1024, rank-3 activation, per-column weight
  scales) — the shape a device ELF exists for here — so the existing |d| = 0 gate becomes the device gate
  the moment an ELF is configured.

Two bugs found by doing this, both fixed here:

• ONEBIT_EP_TRACE is a flag, but onebit_ep_kernel.cpp read it as a path, so ONEBIT_EP_TRACE=1
  wrote every npu_fallback/npu_qdq_fallback note into a file literally named 1. The float NPU path has
  done this since it landed. trace_fallback() now appends to the EP's real
  /tmp/onebit_ep_trace.<pid>.log, so "did the device run this shape" is answerable.
• A shape whose init_elf fails was rebuilt on every call (~50 ms of ELF parse + hw_context); measured,
  that turned a fallback into 8 decode tokens in 87 s instead of 4 s. Failed shapes are now remembered.

Measured (strixhalo, ORT 1.23.2, via npu-hold -l qdq, ticket …8728418.qdq)

Config: ONEBIT_EP_NPU_ELFS=128x2048x1024=full_i8_O_K2048_N1024.elf,128x3072x1024=full_i8_D_K3072_N1024.elf
— these xclbins are M=128 designs (npu-infer/docs/q4nx-forward-evidence.md: "the designs are M=128 but
only row 0 carries the token"), not the m16 ones the EP docs name.

Correctness — the gate, and the device really ran it:

case quark-o: 0 of 5120 int8 values differ, worst |d|=0 LSB, path=fused
trace: qdq runs=11   fallbacks=10   device-busy=0
       npu_qdq_fallback k=16 n=6 why=no QDQ kernel for 16x6   (and the other ELF-less shapes)

The two shapes that have an ELF (2048×1024, 3072×1024) are absent from the fallback list, so they went to
the array; device-busy=0 means nothing was refused for a busy device.

The real Quark export through it (197 fused groups, --basic, 8 tokens):

	8 tokens	trace
with the ELFs (o_proj + down_proj on the device)	56.2 s	qdq runs=1773, fallbacks=1269
host reference (no ELFs)	60.4 s	—

1773 = 197 × 9 forward passes; 1269 = 141 × 9 — i.e. exactly the 56 groups with an ELF (28 o_proj +
28 down_proj) ran on the array and the 141 others (q/k/v/gate/up/lm_head, no ELF here) fell back. Both runs
produced the same generated ids (279 3146 315 9625 374 279 3146 315), so the device path does not
change the model's output.

Throughput is not claimed here. Both runs took ~7 s/token on a box at load average 9 with kswapd0
active (the same host path does 0.48 s/token quiet): 56/197 groups on the array bought 7 % under that
contention, which says nothing about the kernel. A quiet-box measurement is the next step, and the q/k/v
shapes need m16 ELFs before the device share rises above 28 %.

Not in this PR

• No m16 ELFs for the q(1024×2048)/k/v(1024×1024) shapes — pi-ortep is asked in ~/briefs/TORTEP-STATE.md
  whether they exist on strixhalo and what design M each carries.
• I8Ctx::init_elf does not validate the design it is given: passing M=16 for one of these M=128 ELFs
  segfaults in the launch instead of failing, because init_elf sizes the BOs from the M its caller passes.
  That is the runtime's contract to check, not the EP's; reported, not worked around.
• gemm_q8_raw lives in npu/ort/onebit_npu_gemm.cpp (additive; gemm_f32 and the float weight-cache slot
  untouched) because two modules in one process cannot both take the device flock; pi-ortep can move it.

Report: ~/briefs/TQDQ-STATE.md.

[bong-water-water-bong]

VERDICT: CHANGES

At head e2db2b0. The design is right and the evidence is unusually good for a device leg; one thing must change before this lands because #701 lands first, and it is three lines.

The blocker: this new readback site ignores the canary that #701 is putting into readback().

gemm_q8_raw() in npu/ort/onebit_npu_gemm.cpp does exactly what #701 exists to stop, on a path #701 does not know about:

ctx.wait_kernel(run);
ctx.readback();                                   // <- canary runs here once #701 is in
for (r, j) c[(row0 + r) * n + j] = ctx.Cm[r * ctx.ND + j];   // poisoned row copied out as an "exact accumulator"

grep -c canary over npu/ort and onnx/ep on this head is 0. After both merge, a short result row on the QDQ device path becomes a large negative int32 "accumulator", goes through the shared epilogue, and is written into the graph — silently, because this path does not retry and does not log. That is the failure mode #701's title claims is impossible, reintroduced by the PR that builds on it. Fix, in the same shape as #701's own call sites: after readback(), if (ctx.canary_short()) → re-issue once (re-sync_A + launch + readback) and if it is still short, return false with why = "short read" so gemm_q8 falls back to the host loop for those rows. Falling back is strictly better than writing poison, and it is the same contract the rest of this file already follows ("always writes all of C").

Everything else I checked holds up:

• The epilogue really is shared, which is the claim that makes the device leg safe: gemm_q8 builds one epilogue_row lambda (scales, zero points, rounding, saturation) and calls it from both the device branch and the host loop. So device and host can only differ where the accumulator differs, and the accumulator is exact int32 arithmetic in both. That is the right way to add a device leg, and it is why a |d| = 0 gate means something here.
• Row blocks are handled, not assumed: for (row0 = 0; row0 < m; row0 += ctx.MD) with rows = min(MD, m - row0), zero-fill of the rest of Am, and only rows result rows copied out — so m > design M is multiple launches and m < design M does not read padding.
• Default off: nothing happens without ONEBIT_EP_NPU_ELFS, so the shipping configuration is unchanged by this PR; the shape cache and q8_unavailable keep a failed init_elf from being re-parsed per call (the 87 s vs 4 s case).
• The trace fix is real and worth having on its own: ONEBIT_EP_TRACE was read as a path in onebit_ep_kernel.cpp, so ONEBIT_EP_TRACE=1 appended notes to a file named 1 in the cwd. trace_fallback() now writes to /tmp/onebit_ep_trace.<pid>.log, the file the EP actually opens. That single bug made "did the device run this shape" unanswerable, which is exactly the question this PR needs answered.
• Evidence is self-consistent: 1773 = 197 x 9 and 1269 = 141 x 9 (56 of 197 groups have an ELF), the two ELF-backed shapes are absent from the fallback list, device-busy=0, worst |d| = 0 over 5120 values on quark-o, and both runs produce the same ids (279 3146 315 9625 374 279 3146 315). Speed is explicitly not claimed (7 % under kswapd0 contention), which is the honest way to present that window.
• Compiled by hand, because CI does not build either file (ci.yml sets no ONEBIT_NPU): g++-16 -DONEBIT_EP_NPU … -fsyntax-only onnx/ep/onebit_ep_kernel.cpp → rc=0, and g++-16 -DONEBIT_NPU_RUNTIME_OWN … -std=c++26 -fsyntax-only npu/ort/onebit_npu_gemm.cpp → rc=0.

One nit, not blocking: kern->w_ptr != b is the whole weight-cache key, so a graph that rewrites its initializer in place with the same pointer would keep stale weight bytes in layerB[0]. ONNX initializers are immutable in practice, and re-uploading every call would cost what the cache is there to save — but a one-line comment saying "initializers are immutable, so the pointer is the identity" is cheaper than rediscovering it.

Not verified by me: the device run itself (the window, the ELF-backed shapes on the array, the 56/197 split). The NPU is the owner's; I ran no device case, so my read of the numbers is consistency and compile only.

[bong-water-water-bong]

Fixed in d21dd4d — the canary is handled in the shape #701's own call sites use, and the nit is taken.

The blocker: gemm_q8_raw now launches/reads back through a helper and asks the canary — re-issues once (re-sync_A + launch + readback) if it is short, and if it is still short returns false with the row in why, so gemm_q8 redoes every row on the host loop. Never writes poison; that is the file's existing "always writes all of C" contract.

One thing worth flagging: this branch predates #701, so a direct ctx.canary_short() call would not compile here. It is a detection idiom — has_canary<Ctx> via std::void_t and an if constexpr on a dependent type, which is not instantiated when the method is absent. I checked both directions rather than assuming: it compiles on this tree as-is, and with a stand-in canary_short() added to I8Ctx for the test, nm -C on onebit_npu_gemm.cpp.o shows I8Ctx::canary_short() referenced — i.e. the branch really is instantiated once #701 lands. The stand-in was reverted; the window build is unchanged.

Nit taken: the weight-cache key comment now says why the pointer is the identity (ONNX initializers are immutable) and why re-uploading per call would cost what the cache saves.

Not verified by me either, same as you: the device behaviour of the retry path needs the array. What I can state is that the branch compiles in both configurations (host and ONEBIT_EP_NPU, which CI does not build either) and the host tests are 6/6.

[bong-water-water-bong]

Rebased onto main now that #701 is in (e7446ee) and fixed a gap my own first version had — thank you for making me read the real code rather than the review summary:

readback() only verifies if the watched row was poisoned before the launch, and #701's callers do that inside sync_and_launch(). My first attempt checked canary_short() but never called poison_canary(), so the check would have been vacuously false — protection in appearance only, on exactly the path that exists to stop poison reaching the graph. Now:

• poison_if_canaried(ctx, n) before every launch (same detection-idiom shape as short_read, so the branch still compiles on a tree without npu: canary + one retry in readback(), so a short result row is never silently dequantised (#666) #701 — with the real header both I8Ctx::canary_short and I8Ctx::poison_canary show up in nm -C on the object);
• on a short row: re-issue once; still short → return false with the row in why, and gemm_q8 redoes every row on the host.

Scope stated where it is limited: only row 0 of a launch is watched, which is what #701 covers deliberately (poisoning the padded last row of a batched launch fires on every prefill). So a block after the first is protected exactly as much as the rest of this file's batched paths — not less, and not claimed to be more.

Head 6276610, rebased so the diff is only my five files. Host build 6/6; ONEBIT_EP_NPU build compiles and the QDQ proof passes there (its onebit_ep_proof failure is pre-existing on main: with no ELF configured can_compute declines every float MatMul and that proof expects a claim; CI does not build that configuration). The nit about the weight-cache key is taken.

[bong-water-water-bong]

VERDICT: READY

At head 6276610, build pass, tprs-ready applied. The blocker is fixed, and fixed better than I asked: not just the check, but the poison as well, and the whole thing compiles on both sides of #701.

What the fix does (and #701 is now in main — e7446ee — so this is the shipping shape):

launch_and_read = { sync_A; poison_if_canaried(ctx, n); launch; wait; readback }
launch_and_read();
if (short_read(ctx)) { launch_and_read();                 // once, like #701's own sites
    if (short_read(ctx)) { *err = "short read (canary) for KxN at row R"; return false; } }
for (r, j) c[..] = ctx.Cm[r * ctx.ND + j];

• A short row can no longer become an accumulator. return false makes gemm_q8 redo every row on the host loop, so the graph never sees a poisoned INT32_MIN. That is the right direction: fall back rather than write garbage.
• It poisons too, not just checks — which my review did not spot and this PR needed, because #701's poison lives in I8Ctx::sync_and_launch()/launch_async_* in the forward code, and this path launches through ctx.sync_A() + ctx.launch() instead. Checking a canary nobody poisoned would have returned false forever.
• It compiles before and after #701, via a has_canary<Ctx> if constexpr probe on the dependent type — so the branch was not blocked on merge order, and on a tree without #701 it degrades to exactly the old behaviour rather than failing to build.
• The initializer-immutability comment I asked for is in, on both caches (gemm_q8_raw and gemm_f32).

Checked here: both changed files compile with the NPU lane's own flags — npu/ort/onebit_npu_gemm.cpp (g++-16 -DONEBIT_NPU_RUNTIME_OWN -std=c++26 -fsyntax-only, with the canary present in the tree, rc=0) and onnx/ep/onebit_ep_kernel.cpp (-DONEBIT_EP_NPU, rc=0) — which matters because ci.yml builds neither. Row-block handling unchanged and still right (for (row0; row0 < m; row0 += MD), zero-fill of Am, only rows copied out), the epilogue is still one shared lambda, the trace fix still routes to /tmp/onebit_ep_trace.<pid>.log, and ONEBIT_EP_NPU_ELFS still gates the whole path so the default configuration is untouched.

Not verified by me, unchanged from my review: the device window itself (the 56/197 split, worst |d| = 0 on quark-o, the identical ids, the 7 % under contention). The NPU is the owner's; I ran no device case. My check was the code, the contract, and the compile.

One thing to carry to whoever measures next: the QDQ path now depends on #701's poison being called before every launch on every path it uses. If a future launch site is added here that does not go through launch_and_read, the canary will read a stale row and return false — the safe direction, but it will look like a device failure rather than a missing poison.

[bong-water-water-bong]

VERDICT: READY

At head 1fc0291 (rebased onto main after #700 landed), build pass, MERGEABLE, tprs-ready applied.

Nothing about the PR changed in the rebase — the head's parent is 6276610, the head I verdicted, and the only content that came in with it is #700's docs paragraph:

$ git log --oneline --no-merges origin/main..1fc0291
6276610 … 829256c … 17dbd88 … 4929759 … 2ccf7d1        # the same five commits
$ git diff --stat origin/main 1fc0291
 5 files changed, 250 insertions(+), 25 deletions(-)     # npu/ort, onnx/ep kernel + proof
$ git diff --stat 6276610 1fc0291
 docs/onnx-pack.md | 9 ++++++---                          # #700's paragraph, not this PR's
$ git merge-base --is-ancestor origin/main 1fc0291        # yes

So the verdict stands in full: a short result row on the QDQ device path is detected and the row is poisoned before the launch (so the check is meaningful on this path at all), one retry, then return false → gemm_q8 redoes every row on the host, and the has_canary probe keeps it compiling on either side of #701. Both changed files still compile by hand with the NPU lane's flags (npu/ort/onebit_npu_gemm.cpp with the canary in the tree, onnx/ep/onebit_ep_kernel.cpp with -DONEBIT_EP_NPU).

The waiter can merge this on this line; nothing of mine is outstanding on it.

[bong-water-water-bong]

CodeQL fixed at the source in aeec4c1, no suppression.

cpp/world-writable-file-creation was real: trace_fallback() opened the trace with std::fopen(path, "a"), which creates the file 0666 & ~umask — under a permissive umask the NPU fallback notes land in a world-writable file in /tmp. Now:

const int fd = ::open(path, O_WRONLY | O_CREAT | O_APPEND | O_NOFOLLOW | O_CLOEXEC, 0600);
if (fd < 0) return;
FILE* f = ::fdopen(fd, "a");

which is exactly what the EP's own trace does (onebit_ep.cpp, tracef) — the two writers into that one file now agree on the mode as well as the path. O_NOFOLLOW came along because the same line was following a symlink planted at /tmp/onebit_ep_trace.<pid>.log, the other half of the same class.

Checked by running the code, not by reading it: the file comes out 0o600, two appends land in order, and a symlink at the path is refused (target stays empty).

Host build 6/6; ONEBIT_EP_NPU build compiles and its QDQ proof passes. Head aeec4c1 (fast-forward on 1fc0291, so the diff is unchanged apart from this line).

[bong-water-water-bong]

VERDICT: READY

Head aeec4c1d (one commit over the 1fc0291 I passed READY at: aeec4c1 onnx EP: create the trace file 0600, not 0666, onnx/ep/onebit_ep_kernel.cpp +12 −2). Nothing else in the PR moved and main is still 3d24206, so the earlier evidence stands; this re-review is the delta plus one re-check of the whole gate.

What the commit does: trace_fallback() in onnx/ep/onebit_ep_kernel.cpp replaces fopen(path, "a") with open(path, O_WRONLY|O_CREAT|O_APPEND|O_NOFOLLOW|O_CLOEXEC, 0600) + fdopen, closing the fd on the fdopen failure path.

Verified, in this order:

1. Both lanes compile by hand at the head (CI builds neither NPU lane; .github/workflows/ci.yml sets no ONEBIT_NPU):
   g++-16 -std=c++17 -fsyntax-only -DONEBIT_EP_NPU -I onnx/ep -I npu/ort -I npu/forward/include -isystem /usr/include/onnxruntime onnx/ep/onebit_ep_kernel.cpp → exit 0
   same command without -DONEBIT_EP_NPU → exit 0. <fcntl.h> sits in the unconditional include block, so the plain build sees O_NOFOLLOW too.

2. The property itself, old against new, via a harness TU that #includes the real source and calls trace_fallback() with ONEBIT_EP_TRACE=1 under umask(0000):

   	created mode	planted symlink at /tmp/onebit_ep_trace.<pid>.log
   1fc0291 (before)	0666	followed: victim file grew 10 → 24 bytes (probe note written through it)
   aeec4c1d (after)	0600	not followed: victim unchanged at 10 bytes, untouched

   So the alert was real (world-writable under a permissive umask, and a symlink was followed into it), and the new code closes both: 0600 cannot be world-writable for any umask, and O_NOFOLLOW fails the open instead of writing through the link.

3. The comment's claim is true: onnx/ep/onebit_ep.cpp:97 already opens its trace with O_WRONLY|O_CREAT|O_APPEND|O_CLOEXEC, 0600, so the two writers now agree on the mode. (O_NOFOLLOW is extra on the fallback side, not a disagreement.)

4. Swept the rest of the tree for the same class: no 0666-with-umask creation left under onnx/, npu/, tools/, scripts/. tools/moe_trace.cpp:234 is already 0644 (CodeQL alert 5, fixed). onnx/ep/onebit_ep_qdq_proof.cpp:548 opens /proc/self/clear_refs for write — procfs, not a file it creates. npu/ort/onebit_npu_gemm.cpp:106 creates the device lock 0644 with O_NOFOLLOW, not world-writable.

CI at this head: build SUCCESS, Analyze (c-cpp), Analyze (actions), Analyze (python), Analyze (rust) all SUCCESS, hw_gate SKIPPED, pr_agent CANCELLED (coder-llm is off, expected).

Merge gate: this is READY and tprs-ready is on the PR at aeec4c1d. Nothing merges to engine main before the Sunday release except what the orchestrator says.

[bong-water-water-bong]

VERDICT: READY

Restatement at the orchestrator's request (relayed as "new head aeec4c1"): this is not a new head. aeec4c1d is exactly the head I passed READY at 22:46:30Z, tprs-ready has been on the PR since then, base main is still 3d24206, and the diff is unchanged (+260 −25, 5 files). Nothing was pushed after that review, so nothing is re-opened and nothing is withdrawn — this line exists only so a waiter keyed to a fresh event fires.

State at this head right now: build SUCCESS; Analyze (c-cpp), Analyze (actions), Analyze (python), Analyze (rust) and CodeQL SUCCESS; hw_gate SKIPPED; pr_agent CANCELLED (coder-llm is off, expected).

The commit in question (aeec4c1 onnx EP: create the trace file 0600, not 0666) was verified by running the property, not by reading it: a harness that #includes the real source and calls trace_fallback() with ONEBIT_EP_TRACE=1 under umask(0000), built against both 1fc0291 and aeec4c1d — before: file created 0666 and a planted symlink at /tmp/onebit_ep_trace.<pid>.log was followed (victim grew 10 -> 24 bytes); after: created 0600 and the symlink refused (O_NOFOLLOW), victim untouched. Both NPU lanes compile by hand (CI builds neither). Full evidence, and the tree-wide sweep for the same class, in the 22:46Z review.

Merge gate is satisfied at aeec4c1d; the orchestrator merges.

[bong-water-water-bong]

Device leg re-verified on the rebuilt strixhalo box (b30629d), and it found two real bugs in this PR's own file — both now fixed.

1. The device lock was leaked across provider reloads (mine). State holds the lock as a raw descriptor with no destructor. ORT unloads the provider library when the Env that loaded it is released, so the static State is destroyed and re-created on the next load; the second incarnation opened /tmp/1bit-npu-device.lock, flock()ed it, and got EAGAIN from the first incarnation's leaked descriptor, in the same process. The trace blamed "held by another process", so it read as device contention.

Evidence (strace -f -e trace=flock on the QDQ proof, all from one pid):

flock(4,  LOCK_EX|LOCK_NB) = 0
flock(6..15, LOCK_EX|LOCK_NB) = -1 EAGAIN      # 9 of them

With ~State() closing the descriptor: 10 of 10 take the lock. The quark-o case (2048×1024, the shape an ELF exists for) then runs on the array with no fallback line in its trace slice — 0 of 5120 int8 values differ, worst |d| = 0 LSB. The cases that still report a fallback are honest: no QDQ kernel for 16x6 / 64x48 / 1024x2048 / 1024x1024 (no ELF for those shapes).

2. A device-open failure was reported as a missing driver (also mine). init() swallowed the runtime's exception, so this box's actual cause —

mmap(NULL, 67108864, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED|MAP_LOCKED, devfd, …) = -1 EAGAIN

a 64 MiB locked heap BO against RLIMIT_MEMLOCK = 8 MB — surfaced as no XRT device (amdxdna) found. The exception text from device 0 is now in the note; verified by lowering the limit on purpose, it reads no XRT device (amdxdna): device 0: npu runtime: memory error (code 204): Resource temporarily unavailable.

Gates at b30629d: host build 6/6 (ctest), ONEBIT_EP_NPU=ON build compiles, tools/copyright.py --check clean. On the array: M=128 K=2048 N=1024 probe PASS at 11.52 ms/call, and the fused QDQ proof PASS with worst |d| = 0/0/0/0 LSB.

Note for whoever runs this next: ulimit -l must be unlimited for the NPU in this process (/etc/security/limits.d/99-amdnpu-memlock.conf was written at 20:03, after this session's login, so sessions started earlier still have 8 MB). No speed claim from this: the m16 ELFs for the two small Qwen3 shapes (q 1024×2048, k/v 1024×1024) still do not exist on the box, so the device share stays at the two shapes that have designs.

[bong-water-water-bong]

VERDICT: READY

Head correction, because it matters for the merge waiter: the relayed head was aeec4c1, but the PR head is now b30629dd — one new commit since my READY at aeec4c1d:

b30629d npu: give the device lock back when the provider is unloaded, and say why a device open failed
npu/ort/onebit_npu_gemm.cpp | +20 −2

So aeec4c1 had a verdict and this head did not. tprs-ready was still sitting on the unreviewed head, so I removed it, verified, and have put it back on b30629dd — that is the only way a stale label cannot merge code nobody read.

What the new commit does, both parts verified here:

1. ~State() closes lock_fd, so ORT unloading the provider library (which destroys the function-static State and re-creates it on the next load) gives the flock back instead of leaking the descriptor. That is the bug it describes, and the mechanism checks out on a scratch file, not the NPU's:

   A open=3 flock=0            (first incarnation takes the lock)
   B open=4 flock=-1           (second fd, same process: EAGAIN -- the reported failure)
   after close(A): B flock=0   (closing releases the flock, as the destructor now does)
   

   No double close: the flock failure path already does close(s.lock_fd); s.lock_fd = -1;, and it is the only other close.
2. The device-open loop keeps the first id's exception (if (dev_why.empty())), so the real cause is reported instead of the last, nonexistent device's ENOENT.

Compiled by hand at b30629dd — CI builds neither NPU lane (.github/workflows/ci.yml sets no ONEBIT_NPU), both rc 0:

g++-16 -std=c++17 -fsyntax-only -DONEBIT_EP_NPU -I onnx/ep -I npu/ort -I npu/forward/include -isystem /usr/include/onnxruntime onnx/ep/onebit_ep_kernel.cpp
g++-16 -DONEBIT_NPU_RUNTIME_OWN -std=c++26 -O1 -fsyntax-only -isystem $PWD/npu/forward/include -isystem $PWD/npu/forward/engine-src -isystem $PWD/npu -I $PWD/npu/ort -fopenmp npu/ort/onebit_npu_gemm.cpp

The lock's open semantics are unchanged and still match app/npu_device_lock.h (engine#640): same path, O_CREAT|O_RDONLY|O_NOFOLLOW|O_CLOEXEC, 0644.

Not verified by me: that ORT actually unloads the provider library when the Env is released, which is the premise the destructor relies on. Exercising it means taking /tmp/1bit-npu-device.lock on a box where the owner's NPU serve is the holder, which is the one thing my lane rules forbid, so that runtime claim stays the author's measurement (the comment states it: 1 case took the lock, 9 refused, on the QDQ proof graph). The static-destruction path itself is standard, and the flock release on close is now demonstrated above.

Two nits, neither blocking: the first comment line in the error-message hunk starts mid-sentence — // a real cause (a 64 MiB is missing its opening words, so the sentence "…into "no XRT device found", which reads as a missing driver" has no subject; and the destructor releases the lock in its body, i.e. before the xrt::device member is destroyed, where the safer order is device first, lock second. Both are one-line edits for the next time this file is touched.

Merge gate: VERDICT: READY + tprs-ready at b30629dd. Prior evidence at aeec4c1d (the 0600 trace file, before/after with a real 0666 file and a followed symlink) still stands — that diff is untouched by this commit — and main is still 3d24206.