# Managed NIC smoke preflight

**Superseded handoff, 2026-10-04:** the source and checks below are historical.
The frozen hftnet library is ABI 68; the current binding expects ABI 69.
`~/stage-libhft-managed.sh` now refuses staging rather than installing this
obsolete bundle, and its previous contents are retained in the verification
archive. No installed library or running NIC sitting was changed. A new matched
bundle and fresh checks are required before staging; see
[the follow-up verification](RECORD_2026-10-04_hp-dotnet-store-verification.md).

A fresh development Java/.NET benchmark bundle is prepared and verified but
was **not installed**. Its guarded home helper used to check the artifact
manifest, wait for an `isol-no-shared` CPU lease, then request sudo for the
scoped staging script. That handoff is now disabled. The frozen script and
artifacts remain evidence, not current installation instructions.

## Source and verification

The common source checkpoint is
`60b9ea2534712ea06f743cc926764b881180daa7`, including the Java TCP write-owner
fix and the current JNI/hftnet FIXP signatures. Both native libraries include
TCPDirect and SocketXtreme support. The normal optimized release build was
used, with `LIBHFT_TUNED_DIR` unset: this is a functional smoke-test handoff,
not a replacement for the requested tuned latency matrix. No NIC timing has
been measured or published from these bundles.

- Java: 1,074 tests in 44 selected suites; zero failures, errors or skips.
  Coverage includes provider matrices, durable stores, reset/recovery policy,
  TLS, the write-owner regression, FIXP runners and native runtimes.
- .NET: 156 selected TLS, FAST, queue and native FIXP checks passed, with zero
  skipped cases. The native-pool broadcast check passed separately with
  `LIBHFT_ACCEPTOR_THREADS=2`. The standalone completed-read reproduction
  passed all eight cases.
- Eight smoke-preflight, one .NET bench-build and four JNI build-target
  self-tests passed.

These are selected-suite results. They do not supersede the full .NET run's
two file-store failures and environmental skips recorded in
[the .NET review](RECORD_2026-10-03_hp-dotnet-read-fast-review.md).
The first preparation invocation failed only during report archiving: it
assumed every Java suite used `com.atrekes.libhft`, but the lifecycle suite
uses `com.atrekes.libhft.sim`. The Java runner had already passed, and the
fresh-report collector had verified its actual package. The helper now copies
the collector's fully qualified names; all 44 verified XML files were retained
before finalizing the manifest. No failed test was converted to a pass.

JNI SHA-256:
`3eb70fd2e3dd0d17b2dcb1d79b6239170778faf0e7df0a86e9a99b01bd060d75`.
hftnet SHA-256:
`f71d420dab0ba9714e4a44c5c7f342751dc940a51ed1e75c87f80bcc6b9e6579`.

## Evidence and staging guard

`~/archive/libhft/nic-managed-preflight-20261003/prepare.1BmOnR/` retains the
source pin, original and corrected preparation scripts, build/test output,
all selected Java XML reports and JSON totals, both .NET TRX files, the
standalone read log, native hashes and the exact staging manifest.
The 59-file current manifest is
`~/archive/libhft/nic-20261002-managed-rust/managed-stage-current.sha256`;
it covers the staged runtime bundles, native libraries, installer, dispatcher,
placement/capability/standards inputs and both privileged staging wrappers.
An unchanged copy is kept beside the fresh verification evidence.

The manifest now points to the placement file under `internal/bench/load/`.
The retired scratch refresh script, which expected the old completed-read
failure, was preserved in the earlier archive and replaced by the preparation
script. At this preflight the home helper refused changed inputs. No installed
runtime or configuration was changed. Noninteractive sudo for the explicit
staging script still required the user's password. That handoff is superseded
as noted above: an unchanged manifest does not prove that its bundle matches
newer bindings.

## Quiet-window evidence

The cooperating shared-core conformance sweep was still active at handoff.
An older Java 21 test fork had remained hung in the original recovery fixture.
Two read-only thread dumps captured its writer parked in
`SocketChannelImpl.implConfigureBlocking`; its reader was inside
`SocketDispatcher.read0` and owned the exact same `ReentrantLock` that the
writer awaited. This independently confirms the cycle documented by
[the Java write-owner review](RECORD_2026-10-03_hp-java-tcp-write-owner-review.md).
The process command and both dumps are retained in this archive's
`coordination/` subdirectory. They are runtime observations, not a new build
pin for the other session's binaries.

Both observed Java PIDs had exited by the final process check. This session
did not stop them or the sweep. A request on the shared claims board asks
`claude-conformance` to finish its sweep and leave the approved quiet window;
the CPU queue prevents a later cooperating sweep from overtaking the staging
request. A lease does not certify a fully quiet machine: inspect actual
process placement again before hardware measurements.