Send the empty answer, and actually run the browser-compat tests

[JWriter20]

Two fixes uncovered while diagnosing a Tier 3 result that looked like a model regression and wasn't.

1. The empty answer was the one shape the driver could not send

The submit-control lookup sat INSIDE the loop over the model's actions; the decision to press it sat outside:

for (const action of actionList) {
  ...
  const lookup = frame ?? (slid ? null : scope);
  if (lookup) verifyButton = await this.getVerifyButton(lookup);
}
const shouldClickSubmit = !slid && (answered || !performedAction);
if (shouldClickSubmit && verifyButton) { ... }

A plan with no actions never enters that loop. shouldClickSubmit then computes true — through !performedAction, the branch that exists precisely for "we had nothing to do and want the round to advance" — and presses nothing, because the control it needs was never resolved. performedAction stays false and the caller aborts on "still detected but the solver performed no interactions".

Why it looked like a model regression

reCAPTCHA's 3x3 has a none_present variation: the prompt names a class, no tile contains it, and the control reads SKIP rather than VERIFY. Selecting nothing and pressing it is the correct answer. Tier 3 fixture seed 20260730 is exactly that — target traffic light, target_ids: [], submit_label: SKIP.

It surfaced when CaptchaKrakenFinetune fixed font resolution on the macOS Tier 3 runner. That box has no /usr/share/fonts, so every face missed and the prompt had been rendering in a fallback bitmap face reading "Selectall images with / traffic lights". After the fix it draws real reCAPTCHA chrome, with the target term bolded and a legible "If there are none, click skip."

This client runs at temperature: 0, so the model is a function of the picture: a correct picture invites a correct empty answer — and the empty answer is the one shape the driver drops.

Scope note, from re-running Tier 3 on identical code. recaptcha_grid_3x3 js went 2/3 → 1/3 in the run that prompted this investigation, and I initially read that as this bug biting. A re-run of the same commit put it back at 2/3, and 8 of 88 pairs flipped between those two identical runs, so that particular movement was within Tier 3's own noise and is not evidence for this fix. The defect stands on the code: seed 20260730 really is none_present with target_ids: [] and submit_label: SKIP, and an empty plan really does leave verifyButton null and abort. What is fixed here is a path that provably cannot submit, not a measured regression.

getVerifyButton was never at fault: 'Skip' has been in its list since the GeeTest OK fix (geetest-submit-button.test.ts pins the finder itself). The finder was simply never called.

Both ports had it identically; both are fixed, per CLAUDE.md 1c.

2. browser-compat tests errored because a build number moved

Those four reported as ERRORS, and the cause was not a missing browser. Playwright's Python bindings resolve one pinned Chromium build and refuse to launch anything else, so p.chromium.launch() with no path fails on a box that has Chromium — just not the pinned one. This box has four (chromium-1148/1208/1228/1234) and 1234 launches fine when passed as executable_path. playwright install fetching build N+1 does not make build N stop working; what looked like an availability check was a version check.

The fixture now tries the pinned build first, then every build actually installed, newest first — the same resolution CaptchaKrakenFinetune's tests/test_fixtures_are_solvable.py already uses. This file should not have been the odd one out.

Skipping stays reserved for a box with no browser at all, which is a real case: the package ships with no browser dependency and an end user is not required to have one. Skipping because a build number moved is not that case, and it left the one test that checks the compatibility claim against something real quietly doing nothing. A fake page happily keeps agreeing with a driver that no longer matches the library — which is the entire reason this file exists.

The JS twin needed no change. playwright, puppeteer and camoufox-js all resolve from js/node_modules, and tests 10–12 already run against real Playwright and real Puppeteer with 0 skipped. Only the Python bindings pin a build this box no longer has.

While confirming that: there is no browser dependency in this package, and it is verified rather than asserted. pyproject.toml lists pydantic, pillow, numpy, opencv-python-headless, requests, python-dotenv; the dev extra is pytest, mypy, ruff. js/package.json has dependencies: {} and peerDependencies: {}. Nothing in src/ imports a browser package in either port — every remaining mention is prose, and page_solver.py's docstring says so outright.

Tests

Structural, and deliberately so: what is wrong in (1) is where a call sits relative to a loop, and solveSingle / _execute_plan is ~200 lines wrapped around a screenshot, a planner round-trip and a live page — mocking that observes the nesting far less directly than reading it. The Python half asserts over a real AST; the JS half brace-scans, ignoring braces inside strings so an xpath template cannot shift the depth. Each also pins that the lookup still happens at all, so deleting the call does not pass by vacuum. Both confirmed RED first, naming the exact offending lines (2468 and 1030).

• js 91/91
• python 406 passed, 15 skipped, 0 errors (was 402 passed, 15 skipped, 4 errors) — the four browser-compat tests now RUN and pass against real Chromium

🤖 Generated with Claude Code

[JWriter20]

✓ Tier 3 driver-gate — pass

Aggregate: 0.841 · 6/10 families passing · 14 pair(s) not solved

Port	Pairs solved
js	0.864
python	0.818

Vendor family	Solve rate
botdetect	1.000
geetest	0.714
hcaptcha	0.885
lemin	1.000
mtcaptcha	1.000
prosopo	1.000
recaptcha	0.500
tencent	0.000
yandex	1.000
yidun	1.000