test(desktop): lint the POSIX-path-literal defect instead of hunting it

[dizhaky]

What does this PR do?

The same defect turned up three times in three files across #177 and #180: a hard-coded absolute POSIX path meeting a path the code builds with path.join. On Windows path.join emits backslashes and path.resolve prepends a drive letter, so the two sides can never be equal — the assertion is dead on that platform, silently, because the file had only ever run on Linux.

	file	shape
#177	update-relaunch.test.ts	const ROOT = '/home/u/.hermes/hermes-agent'
#177	windows-hermes-path.test.ts	p => p === '/venv/lib/python3.12/site-packages'
#180	ssh-connection.test.ts	assert.match(a, /\/[0-9a-f]{16}\.sock$/)

Two were found by the Windows lane going red; the third by reading a file before adding it. One at a time, after the fact, on a required check. This makes it a lint error instead.

It does not ban leading-slash literals. A blanket ban is unusable: the seven lane files hold 71 absolute POSIX string literals, and all but the three above are inputs — a fake execPath, a ControlPath handed to ssh, a path the stub filesystem is asked about. Coping with those is the job of the code under test. The defect is where a literal meets a computed path, so the rule keys on that meeting:

• joined-root — path.join(X, …) where X is, or is a const bound to, an absolute POSIX literal. Fix: path.resolve('/…'), a no-op on POSIX.
• comparison — x === '/a/b', plus the expected slot of an assertion, which is the same comparison through a helper.
• regex — a pattern that opens with a path separator. "Opens with" rather than "contains" is what keeps /^#!\/bin\/bash/ (a shebang) and /^cd '\/home\/me\/project'…/ (a remote shell command, and remotes are always POSIX) quiet — both live in lane files today.

Single-segment roots ('/tmp') are ignored, and path.posix.join / path.win32.join are exempt because a stated flavour makes the literal deliberate.

Scope is self-maintaining. The rule applies only to the suites named in test:desktop:win-install, and that list is parsed from package.json rather than restated in the ESLint config. A second copy fails silently: a suite added to the lane but missing from the config would get no cross-platform linting at exactly the moment it starts needing it. Files that only ever run on Linux keep their POSIX literals — this is a portability rule, not a style rule.

Related Issue

No issue — this follows directly from the defect class found in #177 and #180.

Type of Change

• ✅ Tests (adding or improving test coverage)

Changes Made

• apps/desktop/eslint-rules/no-posix-path-literals.mjs — the rule (+ .test.mjs, 26 cases).
• apps/desktop/eslint-rules/windows-lane.mjs — parses the lane suite list out of the test:desktop:win-install script (+ .test.mjs, 5 cases).
• apps/desktop/eslint.config.mjs — registers it as hermes/no-posix-path-literals, files derived from the lane list.
• apps/desktop/electron/windows-hermes-path.test.ts — two annotated disables (see below).
• apps/desktop/package.json — lint now also covers eslint-rules/ and scripts/*.test.mjs; three lane suites live in scripts/ and were outside eslint src/ electron/. The rest of scripts/ stays unlinted — it carries 10 pre-existing errors that are not this change.
• apps/desktop/vitest.config.ts — eslint-rules/**.test.mjs joins the electron project.
• package.json / package-lock.json — eslint becomes a declared root devDependency. It was only ever an auto-installed peer, and the rule's tests import { RuleTester } from 'eslint' — a source import, not a CLI invocation. The lock delta is mechanical "peer": true removal with no version movement.
• .github/workflows/desktop-install-windows.yml, docs/system-log/2026-08-11.md — docs.

How to Test

1. npm ci && npm run --prefix apps/desktop check:lint — 0 errors.
2. npm run --prefix apps/desktop test:desktop:platforms — 976 passed, including the 31 new rule tests.
3. Positive control: check out apps/desktop/electron/update-relaunch.test.ts at 1770376^ (or ssh-connection.test.ts at 50e2b2b^) and re-run lint — the pre-fix defects are reported.

Checklist

Code

• My commit messages follow Conventional Commits
• My PR contains only changes related to this fix/feature
• I've added tests for my changes
• I've tested on my platform: Linux (the rule is platform-independent; it is about Windows but does not run there)
• pytest tests/ -q — N/A, no Python touched

Documentation & Housekeeping

• I've updated relevant documentation (docs/system-log/2026-08-11.md, workflow header)
• N/A — cli-config.yaml.example
• N/A — CONTRIBUTING.md / AGENTS.md
• I've considered cross-platform impact — that is the entire point of the change
• N/A — tool descriptions/schemas

Screenshots / Logs

Positive control — the rule over the pre-fix files reports exactly the three known defects and nothing else:

ssh-connection.test.ts
  :66   [regex]      pattern opens with a path separator
update-relaunch.test.ts
  :41   [joinedRoot] path.join() onto "/home/u/.hermes/hermes-agent"
  :77   [joinedRoot] path.join() onto "/home/u/.hermes/hermes-agent"
windows-hermes-path.test.ts
  :173  [comparison] "/venv/lib/python3.12/site-packages"

Self-maintenance, proved rather than claimed. A probe file with a known defect drew no report; adding only its name to test:desktop:win-install — no config edit — made eslint report joinedRoot. Probe removed.

Two false positives, kept and annotated. windows-hermes-path.test.ts compares against /root/venv/Scripts/python.exe twice, and both are safe: every path helper that resolver touches is injected by makeDeps and joins with /. They now carry eslint-disable-next-line with that reason — which is the rule earning its keep, since "why is this POSIX literal safe on Windows?" is exactly what the next person adding a suite needs answered.

The rule's own tests caught two bugs in it before it ran anywhere: expect(x).toBe(v) puts the expected value at argument 0, not 1, so expect-style assertions were never checked; and the lane parser consumed the token after every flag, so a boolean -u swallowed the suite name behind it. It now consumes values only for known value-taking flags — erring towards an extra glob that matches nothing rather than silently dropping a suite. Separately, the first disable comments did not work at all: eslint-disable-next-line followed by more comment lines applies to the next comment. Found by running lint, not by reading it.

---

Unrelated finding, not fixed here

vitest --project ui fails at collection on every file with Incompatible React versions: react 19.2.8 / react-dom 19.2.7. Confirmed pre-existing: I stashed all of my changes, ran npm ci from main's lockfile on a pristine tree, and reproduced the identical failure. Root react is pinned at 19.2.8 in package-lock.json while react-dom is 19.2.7, though both workspaces declare 19.2.7. I can't date it — this clone is shallow, and git log -S attributes the line to the graft boundary rather than a real commit. Left alone deliberately: a dependency-resolution fix does not belong in a lint-rule PR.

---

Generated by Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.