test: aq latency probe

[mmiermans]

Sandbox PR for the aq integration test: measures how quickly a review on my PR reaches Super Productivity. @mmiermans please confirm this can be closed after the measurement.

[claude]

Claude finished @mmiermans's task in 44s —— View job

---

Code Review

• Gather context (diff vs origin/master, repo layout)
• Understand the request (/review)
• Review changed files
• Post findings

---

Reviewed the 2 added files. This is a sandbox probe PR and the helper self-documents that it "intentionally contains a defect" — I'm reporting the defects anyway, since that's what the probe is measuring.

Findings

1. Off-by-one skips the last board cell — aq_probe_util.js:6

for (let i = 0; i < board.length - 1; i++) {

The loop bound excludes the final index, so highestTile returns the wrong value whenever the maximum sits in the last cell. For a 4×4 2048 board flattened to 16 entries, highestTile([2,4,8,...,2048]) with 2048 in the last slot returns the second-highest tile instead. A single-element board always returns 0. Should be i < board.length.

Fix this →

2. Unguarded division by zero — aq_probe_util.js:16

return scores.reduce((a, b) => a + b, 0) / tiles.length;

averageScorePerTile([], []) returns NaN, which propagates silently through any downstream aggregation (a NaN in a running average makes every later value NaN too, so one empty run corrupts the whole series rather than just its own data point). Return 0 — or null if "no data" needs to be distinguishable from a genuine zero average — when tiles.length === 0.

Also worth noting: the two arguments are never checked for matching length. averageScorePerTile([10, 20], [1]) returns 30, which isn't an average of anything meaningful. If the two arrays are expected to be parallel, an early length check would catch caller bugs at the source.

Fix this →

3. Unreferenced file in a location that doesn't match the repo layout — aq_probe_util.js:1

Nothing in the repo imports highestTile, averageScorePerTile, or PROBE_ROUND — I grepped and the only hit is the definition itself. The file also sits at the repo root, whereas this is a C#/.NET solution (Solver2048.sln) whose only JavaScript lives under webclient/. If the probe file outlives the measurement, root-level dead JS in a C# repo is the kind of thing that confuses the next reader. Since the PR body and AQ-PROBE.md both say this is safe to close, deleting the branch is probably cleaner than fixing the defects.

Notes

• AQ-PROBE.md is fine as-is — clear about its purpose and its disposability.
• No tests accompany the helper. Given the stated throwaway intent I'm not flagging that as blocking, but both bugs above are exactly what a two-line unit test would have caught.
• No linter or test suite was run: this repo builds via MSBuild (Solver2048.sln) and has no JS toolchain configured, so there's nothing set up to lint the added .js file.

On the close/reopen question in the thread — that's @mmiermans' call, and the PR body already asks them to confirm. I don't have the ability to close PRs.
• branch aq/latency-probe

[mmiermans]

Closing: the aq latency probe has the measurement it needed.

[mmiermans]

Reopening briefly to exercise the reopen path, then closing for good.

[mmiermans]

Probe complete: aq measured 99s from close to Super Productivity. Closing and deleting the branch.