Qualify CUDA-JS alpha.20 for Connect4 BSFP dominance consumer

[iteathen]

Consumer-backed request

Connect4 CUDA-BSFP P2 now has a concrete Tensor consumer seam: accelerating exact antichain dominance checks for overflow segments while keeping packed representation and compaction Connect4-owned.

The intended first experiment uses the existing device-callable Tensor profile:

• item axis = candidate masks;
• shared right operand = accepted-frontier bit rows;
• rank-2 item matmul computes candidate/frontier overlap counts;
• exact elementwise/reduction logic derives one dominated/keep result per candidate;
• Connect4 imports tensorRunItem into Device-JS and keeps final compaction on-device.

No new Tensor math operation is currently required.

Concrete compatibility gate

Connect4 P2 is qualified against CUDA-JS:

98e2ebc942c14d63acf4dd82e912dd548c363a05 (cuda-js@0.1.0-alpha.20)

Current protected CUDA-JS-Tensor main remains frozen to:

45a9ef15537b52d6fd7c615b7e596676dfd00587 (cuda-js@0.1.0-alpha.18)

Tensor correctly fails closed on the newer pair today. The requested work is an exact-pair refresh/qualification, not relaxation of Tensor compatibility checks.

Acceptance

• Review CUDA-JS changes from the protected Tensor pin through 98e2ebc... for Tensor-relevant contract changes.
• Update the exact CUDA-JS dependency and Tensor compatibility identity only if review supports it.
• Run the complete Tensor portable/repository test suite on the exact new pair.
• Qualify device-callable rank-2 item matmul + per-item reduction generation on the exact new pair.
• Preserve fail-closed workspace/resource bounds and lifecycle behavior.
• Obtain native evidence on the Connect4 Windows GPU host before making any native/performance claim.

Ownership boundary

CUDA-JS-Tensor owns generic Tensor math, device-callable ABI and workspace/resource facts. Connect4 owns packed mask representation, BSFP antichain semantics, tiling policy, survivor compaction and correctness oracle. CUDA-JS owns runtime/compiler/device mechanisms.

If this exact-pair qualification exposes a missing or broken CUDA-JS primitive, file that defect in iteathen/CUDA-JS; do not emulate a lower-layer workaround inside Tensor or Connect4.

No claim is made that Tensor will be faster until the bounded native A/B is measured.

[iteathen]

Connect4 BSFP pair qualification checkpoint

Draft PR #82 now qualifies the concrete consumer shape without changing protected main compatibility.

At 63fbd0c5cd50a2251e3474a15bc79e786530eaec:

• protected CUDA-JS alpha.18 verify: 111/111 pass;
• staged exact Connect4 pair CUDA-JS 98e2ebc942c14d63acf4dd82e912dd548c363a05 / alpha.20: 111/111 pass;
• minimal and maximal Connect4 dominance Tensor programs both map to one item-parallel device-callable leaf and compose through public CUDA-JS Device-JS imports on both pairs;
• the first alpha.20 failure was qualification-only: stale alpha.18 test fixtures plus a non-contract assertion on an import alias field. After isolating those fixture identities, the full staged suite is green.

No CUDA-JS runtime/compiler/API defect was exposed, so no CUDA-JS issue is warranted from this checkpoint.

Consumer resource bound

For frontier width F and candidate item tile I, the current f32 device-callable formulation needs approximately:

• minimal: 4 * I * (4F + 2*nextPow2(F) - 1) bytes;
• maximal: 4 * I * (4F + 2*nextPow2(F) + 126) bytes.

For I=256 this is about 9.8 MiB at F=1,487, 22.2 MiB at F=3,618, and 64.5 MiB at F=8,283. These are static Tensor workspace facts, not native performance claims.

Next consumer step is an isolated Connect4 A/B against the existing packed exact normalizer. The current Tensor device-callable matmul is generated SIMT, not cuBLASLt; performance remains unqualified until that native A/B.

[iteathen]

Additional native exact-pair consumer evidence from Connect4, without changing Tensor or CUDA-JS:

• CUDA-JS 98e2ebc942c14d63acf4dd82e912dd548c363a05; CUDA-JS-Tensor 9df9324.
• Connect4 tested 6a0082dd2b068fccd65ed388a0edbc3d755e6caa, GTX 1660 Ti / driver 610.74 / Node 26.7.0.
• Native callable full-shape A/B PASS, run 20260916T090952138Z-6869ee54. Two warmups, seven rotated-order samples; packed / Tensor-only / packed-to-Tensor medians 15.9651 / 17.8028 / 30.0435 ms. Exact oracle match, callable arena 164,544,512 bytes under its separate 201,326,592-byte ceiling.
• Independent real-input resolved-SIMT replays also PASS: maximal 16,005 candidates -> 1,055 exact survivors; minimal 448,941 -> 2,473. Three measured repetitions plus warmup per executor, full BigInt oracle, graceful cleanup. Resolved workspace remains 67,108,864 bytes, not the callable limit.
• Resolved-Tensor whole pair/recovery medians 327.3094 / 19,921.3156 ms, versus selected packed stack 36.5302 / 187.1082 ms on the same fixtures. This is why current Connect4 defaults to packed recovery; it is not a Tensor correctness failure. All samples and scope distinctions are preserved.

Detailed report, fixture hashes and sanitized run evidence.

The final 7x6 integration reached a clean 120-second case timeout, not a solve. This supplies native consumer evidence for the staged exact-pair refresh; it does not bypass the remaining #81/PR #82 review or compatibility gates. No generic Tensor/CUDA-JS defect was demonstrated. A Connect4 bucket histogram synchronization defect discovered during optimization was fixed in Connect4.