ci: run the unit suite on Windows and smoke the Playwright sample there

[chinmayajha]

Closes #580

What Windows coverage was before

The installer CI in mozarkai/optics-framework-org runs on a real windows-latest runner and verifies install → optics --version → optics list → idempotent re-run → uninstall. That proves the CLI starts on Windows. It does not prove the framework works there. The macOS and Linux journeys were walked by hand end to end; Windows had no equivalent, and the suite had never been run on it at all.

What this adds

1. The existing pytest job now runs on ubuntu-latest and windows-latest (fail-fast: false, so a Windows failure still reports the Linux result). This is the bulk of the value: ~1393 tests covering path handling, encoding and cleanup across the whole codebase, each reporting a precise failing assertion, rather than one opaque end-to-end step.

2. A playwright-sample job for the one thing unit tests cannot reach — a real browser launch writing real artefacts:

optics init demo --template playwright
optics doctor demo --check
optics execute demo

Each command is its own step, so any non-zero exit fails the job. execute does propagate failure — execute_main (optics_framework/helper/execute.py) calls sys.exit(1) when any test case is not PASS, and anything raised out of a subcommand is caught by cli.main's handler, which also exits non-zero.

Two things the exit code alone would not catch, so they are asserted explicitly:

• _has_failed_results({}) is False, so optics execute exits 0 on an empty result set. The job reads execution_output/junit_output.xml and fails if it lists zero test cases, or any failure/error.
• utils.save_screenshot wraps cv2.imwrite in a try/except, and cv2.imwrite returns False rather than raising on a rejected path. A write Windows refuses would be dropped silently and still exit 0. The job fails if no screenshot landed under execution_output/.

On failure, execution_output/ is uploaded as an artifact — the only way to diagnose a Windows-only failure from a non-Windows machine.

Both jobs live in tests.yml

Same triggers, same purpose, one checks list, one set of pinned action SHAs to maintain. #585 put its bare-image smoke in the same file for the same reason.

Why the e2e job skips pull requests

if: github.event_name != 'pull_request' — it runs on push to main and on workflow_dispatch.

The unit matrix now carries the regression-catching load, and it catches more, faster, with better failure messages. Against that, the e2e job downloads ~150 MB of Chromium and fetches a live example.com on every run: it would be the only network-dependent check in the repo, and making it a per-PR check couples PR throughput to a third party's uptime. It is also the slowest job here by a wide margin.

The trade is real and worth naming: a regression that only the e2e catches now surfaces on main rather than on the PR that caused it. Three things make that acceptable — the unit matrix covers the same defect classes at a finer grain, workflow_dispatch lets anyone run the e2e on demand before merging something risky, and main is still upstream of every release. If it turns out to catch things the matrix misses, moving it back to per-PR is a one-line change.

What the Windows matrix found: 28 failures, all of them test bugs

None were product bugs. Four harness assumptions, each of which passed on POSIX for the wrong reason (fixed in the first commit):

Root cause	Tests
monkeypatch.setenv("HOME", ...) does not redirect expanduser on Windows — ntpath reads USERPROFILE, then HOMEDRIVE/HOMEPATH, and ignores HOME. The tests were asserting against the runner's real home.	11 (test_onboarding.py, test_doctor.py)
Constructing a prompt_toolkit Application resolves an output eagerly; with no Windows console that raises NoConsoleScreenBufferError. POSIX falls back to a vt100 writer, so no session was ever needed.	14 (test_live_keywords.py, test_live_driver_agnostic.py)
A / hardcoded in an assertion where the product correctly writes os.path.join.	2 (test_autocompletion.py)
python3 -m venv asserted where the product already, correctly, tells Windows python -m venv and Scripts\Activate.ps1.	1 (test_environment.py)

In the two cases where a platform difference was involved, the product was already the correct side of it. The Playwright browser-cache test also gains the Windows cache location — _playwright_browser_dirs has always listed AppData\Local\ms-playwright, but nothing covered it.

The e2e job is expected to stay red

It fails at optics doctor with:

Error: 'charmap' codec can't encode character '\U0001fa7a' in position 0

U+1FA7A is the stethoscope in doctor.py:498. On Windows sys.stdout is UTF-8 only when attached to a console; redirected (CI, optics doctor > log.txt, any build system) Python falls back to the ANSI code page and Rich writes the emoji straight through. Rich's safe_box degrades box-drawing to ASCII — visible in the optics init step, which printed +---+ — but it does not transcode emoji. It is unconditional: _STATUS_GLYPH (doctor.py:41) puts ✅/⚠️/❌ on every row.

This needs no Windows runner to reproduce:

stream = io.TextIOWrapper(io.BytesIO(), encoding="cp1252")
Console(file=stream).print("🩺 optics doctor")   # UnicodeEncodeError

That fix, and the save_screenshot timestamp sanitisation (utils.get_timestamp() returns ...T16:51:50.397462+05:30, and utils.save_screenshot interpolates a caller-supplied timestamp into the filename unsanitised — colons are reserved on Windows), belong in the Windows-correctness PR, not in a CI change. This job goes green when that lands. The assertions are deliberately left intact rather than relaxed to make it pass.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[malto101]

add macOS too

[malto101]

remove the comments, seems quite obvious