All checks were successful
ci / fmt (pull_request) Successful in 20s
bench / build (pull_request) Successful in 1m15s
ci / clippy (pull_request) Successful in 1m40s
ci / doc (pull_request) Successful in 2m6s
bench / measure (pull_request) Successful in 2m51s
ci / test (pull_request) Successful in 7m45s
quantus/miner#3. New crate, nothing in engine-gpu touched. - kernels/mining.cu: the same host contract and sponge schedule as mining_u64.wgsl (host midstate, low-256-bit nonce increments, lazy second squeeze), bit-exact with pow_core. The field multiply is __umul64hi plus a plain multiply and one reduction, instead of four 32-bit partials with carry reconstruction. - build.rs: generates poseidon2_constants.cuh from qp-poseidon-constants (a hash change at origin is a dependency bump, never a hand-copied table) and, when nvcc is present, compiles one fat binary with cubins for sm_86/89/120 plus compute_120 PTX. Without nvcc it writes an empty image, the crate still builds, and CudaEngine::try_new fails with a clear message so the miner falls back to wgpu. - lib.rs: CudaEngine with the same batch loop, cancellation, thread-local device assignment, metrics (kernel label "cuda") and stale accounting as engine-gpu. cudarc 0.19 with dynamic loading; no link-time CUDA dependency. - miner-service: resolve_gpu_configuration tries CUDA first unless --gpu-engine wgpu; --gpu-engine cuda makes its absence an error. miner-cli gains the flag on serve and benchmark (MINER_GPU_ENGINE). - bench-harness: --engine auto|cuda|wgpu. - deploy.yaml: matrix rows carry the kernel validate expects; a wgpu fallback on a CUDA host now fails the deploy instead of passing at a fraction of the hashrate. Measured on quadbrat (RTX 3060, 130 W, miner paused, 2 x 10 s windows, parity 5/5 verified against CPU): wgpu 37.3 MH/s, CUDA 59.5 MH/s (1.59x). Grid sizing 8192 threads/SM or more is flat; 2048 loses 10%. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CBgs2nSi4H2mdh8kD8vMX5