You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs/PLATFORM-PARITY.md is currently the manual reconciled view of what works where. It states its own invariant:
If a row here disagrees with capabilities(), the code wins — and that disagreement is a bug (it's how #133 was found).
#133 (KDE advertises watch_windows/raise_window it can't fulfil) and #135 (macOS can enumerate/raise but doesn't advertise) were both found by reading the doc against the code. Automate that read so the next drift fails CI instead of waiting for someone to notice.
Proposal
A test (tests/test_platform_parity.py) that treats the doc's capability matrix as the spec and asserts it matches the backends:
Parse the ## Capability matrix table in docs/PLATFORM-PARITY.md — for the three capability rows (watch_active_app, watch_windows, raise_window), read ✓/✗ per backend column.
Instantiate each backend (GNOME, KDE, X11, macOS) — reuse the construction already in tests/test_platform.py (test_x11_backend_does_not_advertise_watch_windows, test_gnome_backend_advertises_watch_windows).
Assert backend.capabilities() contains the flag iff the doc row is ✓. A ✓ the code lacks, or a flag the doc marks ✗, fails with a message naming the backend + capability.
This makes the doc executable: capability changes must update the table in the same PR, and dishonest advertisement (the #133 class) cannot merge.
Scope / decisions
macOS instantiation — macOS backend construction may need guarding on non-Darwin CI (skip or stub _load_quartz); enumerate the advertised flags, not the live mechanism, so no PyObjC runtime is required.
Only the three compositor-axis capabilities are gated by capabilities(); the input-injection rows in the matrix are informational (no capability flag) — either scope this test to the top three rows or extend capabilities() to cover injection later. Start with the three.
Live-bus verification of the rows (that's the #129–#131 desktop-integration harness in docs/TESTING.md). This test only checks doc ↔ capabilities() agreement, which is pure and fast.
Motivation
docs/PLATFORM-PARITY.mdis currently the manual reconciled view of what works where. It states its own invariant:#133 (KDE advertises
watch_windows/raise_windowit can't fulfil) and #135 (macOS can enumerate/raise but doesn't advertise) were both found by reading the doc against the code. Automate that read so the next drift fails CI instead of waiting for someone to notice.Proposal
A test (
tests/test_platform_parity.py) that treats the doc's capability matrix as the spec and asserts it matches the backends:## Capability matrixtable indocs/PLATFORM-PARITY.md— for the three capability rows (watch_active_app,watch_windows,raise_window), read ✓/✗ per backend column.tests/test_platform.py(test_x11_backend_does_not_advertise_watch_windows, test_gnome_backend_advertises_watch_windows).backend.capabilities()contains the flag iff the doc row is ✓. A ✓ the code lacks, or a flag the doc marks ✗, fails with a message naming the backend + capability.This makes the doc executable: capability changes must update the table in the same PR, and dishonest advertisement (the #133 class) cannot merge.
Scope / decisions
_load_quartz); enumerate the advertised flags, not the live mechanism, so no PyObjC runtime is required.capabilities(); the input-injection rows in the matrix are informational (no capability flag) — either scope this test to the top three rows or extendcapabilities()to cover injection later. Start with the three.Out of scope
Live-bus verification of the rows (that's the #129–#131 desktop-integration harness in docs/TESTING.md). This test only checks doc ↔
capabilities()agreement, which is pure and fast.