Skip to main content
Run source checks from a clone of library-motd, using Node 24.
Required checks must pass for the actual PR head. Keep current test totals and failure artifacts in the run rather than treating a historical count as a permanent coverage guarantee.

​
Evidence levels

Synthetic composition events do not certify a physical IME. A Windows browser comparison against a Linux native capture does not certify Windows Java. Playwright WebKit does not replace a shipping Safari test on macOS/iOS.

​
Native reference corpus

The source repository keeps versioned manifests and comparison fixtures under tests/fixtures/client. They record exact status data, client/resource hashes, GUI settings, crop coordinates, and capture checksums. Client binaries, extracted game resources, and private full-screen captures are not npm assets. The independent sessions cover Java 1.20.4, 1.21.1, 1.21.11, 26.1, 26.1.1, 26.1.2, 26.2, and 26.3. Supported text cases include foreground/shadow geometry, decorations and wrapping at the recorded settings. The full scope and font exceptions are in client profiles. All bundled presets remain verified: false.

​
Native client reference procedure

1

Prepare an isolated client

Use an authorized local installation of the exact official version named by the manifest. Verify hashes and use a separate game directory with no user world or launcher credentials. The existing Linux procedure uses a dedicated Xvfb display, 854×480, GUI scale 2, lang:en_us, and narrator:0.
2

Serve one controlled response

Use the source repository’s localhost-only status-server.py with the manifest’s complete status response. This fixture accepts status/ping packets, not a game login. Keep the exact JSON and response log for each case.
3

Confirm the displayed response

Wait for the case-specific generated icon color before capturing. Refresh when the case calls for it and move the pointer outside the row. This prevents an earlier cached status response or loading frame from becoming a reference.
4

Record and compare

Capture the manifest’s region and record timing, scale, resource versions, and checksums. Compare declared masks/geometry, not approximate background artwork. Keep random obfuscation frames separate from deterministic pixel assertions.
For the font references, the generated readiness icon uses RGB (20 + caseIndex * 15, 40, 220). The recorded font crop is [194,94,440,42] for 1.20.4/1.21.1 and [194,96,440,42] for modern clients. Use each manifest’s actual values rather than reusing those dimensions for unmeasured profiles.

​
Native motion and icon studies

The 26.3 timing session distinguishes cached MOTD status from host-side frame selection. See Vanilla behavior for the measured idle intervals and refresh control. The favicon audit and isolated STB probe establish a static/default PNG path for the measured client. See static icons and the original fixtures for alpha/default-image provenance. Obfuscation cadence, candidate pools, and complete animated rasterization still need their own native comparison; see issue #106.

​
Remaining manual verification

An actual Windows Java-client capture remains open in #70. Physical IME and screen-reader workflows remain open in #17. Do not turn those items into passing claims because browser composition or raster tests pass. Diagnostic artifacts can help investigate intermittent browser/graphics failures, but a later passing run does not prove the cause of an earlier failure. Retain bounded observations and keep actual rendering assertions in place. See browser regression coverage for the detailed case matrix and CI diagnostic boundaries.