Desktop E2E has never run: paths filter points at nclaw/desktop/** which does not exist

[acamarata]

The Desktop E2E suite has never run. Not once.

.github/workflows/desktop-e2e.yml is gated on:

on:
  pull_request:
    paths: ['nclaw/desktop/**']
  push:
    branches: [main]
    paths: ['nclaw/desktop/**']

nclaw/desktop/ does not exist in this repository. The directory is desktop/. The nclaw/ prefix looks like a leftover from a monorepo-relative path that no longer applies.

A path filter that matches nothing means the workflow can never trigger. Confirmed against the run history: the only run that has ever existed is the one accidentally triggered by #49, which added the workflow to its own paths: list.

So this is not a flaky suite or a slow suite. It is a suite that has produced zero signal for its entire lifetime, while appearing in the workflow list as though it were protecting the desktop app.

And it is red

That single accidental run failed immediately:

Job	Result	Failing step
e2e (windows-latest)	failure	Install deps
e2e (macos-latest)	failure	Install deps
e2e (ubuntu-latest)	queued

It does not get as far as running a test. Whatever Install deps needs has drifted since the suite was written, which is unsurprising for something that has never executed.

Why this was not fixed in #49

Correcting the path to desktop/** is the obvious one-line fix, and it is deliberately not included in #49.

Doing so would make a known-broken suite start running on every desktop change and turn main red immediately. That trades an invisible problem for a loud one before anyone has decided to fix the suite itself. Turning someone else's main red as a side effect of a workflow-hygiene sweep is not an acceptable trade.

#49 only makes the workflow trigger on edits to itself, which is what surfaced this.

Suggested order

1. Fix Install deps until the suite is green when run manually via workflow_dispatch.
2. Then correct the filter to desktop/** so it guards real desktop changes.
3. Consider making it a required status check on main once it is trustworthy.

Doing 2 before 1 just moves the breakage somewhere more annoying.

Context

Found during an org-wide sweep for gates whose success condition is unreachable or trivially satisfiable. Related instances: a required status check named nself-ci that no workflow produced (blocking every PR in 4 repos, later found in 3 more), a postgres readiness check satisfied by the temporary initdb server, a quarterly cron firing ~10x per quarter, and nself-org/cli#268 / nself-org/cli#270.

This one is the most complete version of the pattern: not hard to satisfy, but impossible.

[acamarata]

Infrastructure fixed; the suite itself is genuinely failing

The nclaw/ prefix is corrected in #49 — paths:, all three working-directory: values, and the artifact path.

Confirmed effect: the workflow now gets past Install deps and Install Playwright browsers and reaches Run E2E on all three runners. Previously it could not even start a shell (No such file or directory).

Run E2E now fails on macos, ubuntu and windows. That is real test debt, not a CI misconfiguration — expected for a suite that has never executed since it was written.

Remaining work is therefore a different job from this issue: making the Playwright tests actually pass. Suggest tracking that separately so this issue can close once #49 lands, with the suite reaching the tests being the definition of done here.

Until the tests pass, note that e2e is not a required check on main (required: Gitleaks, Desktop Build Check), so this does not block merges — but it will now show red, which is honest rather than the previous silence.

[acamarata]

Infrastructure is fully fixed; one real test failure remains

Second fix landed in #49: pnpm-workspace.yaml globs ../packages/@nself/* — the nself-org/packages repo as a sibling — and desktop/package.json depends on five of them as workspace:*. CI checked out only nclaw, so vite died with Failed to resolve import "@nself/observability" and four siblings. The workflow now checks out both repos into the layout the workspace file expects, and installs at the workspace root (the lockfile is the root 712 KB pnpm-lock.yaml, not desktop/'s).

Confirmed progression across three fixes:

	Result
before	never ran at all — paths filter matched nothing
after path fix	shell would not start: No such file or directory
after workspace fix	installs, downloads Chromium, runs playwright test

What now fails is a genuine application test, not CI:

1) [chromium] › tests/e2e/chat.spec.ts:3:5 › user can send a message and see a stub reply
   TimeoutError: locator.waitFor: Timeout 5000ms exceeded.

The suite reaches the tests and the chat stub-reply flow does not produce what the test waits for within 5s. That is app/test behaviour and needs someone who knows the desktop chat UI — a different job from the CI plumbing this issue was opened for.

Suggest closing this issue when #49 merges (its stated definition of done — the suite reaching the tests — is met) and tracking the chat.spec.ts timeout separately.

e2e is not a required check on main (required: Gitleaks, Desktop Build Check, both green on #49), so this does not block the merge. It will now show red, which is accurate rather than the previous silence.

[acamarata]

Fixed and verified.

Desktop E2E now runs on push and pull_request and passes on all three platforms:

success  2026-08-27T15:43  push
success  2026-08-27T15:23  pull_request
success  2026-08-27T15:08  pull_request

Getting there took more than the path filter. Once the workflow could actually run, it failed for real, and there were three independent causes stacked behind each other (#53, #54):

Cause	Detail
App.tsx had no authenticated branch	ChatContainer — the entire built chat UI — was never mounted
chat-client.ts sent an obsolete SSE payload	AI SDK v6's strict transport rejected it; wrong function signature too
main.tsx never imported globals.css	Tailwind never loaded, message list collapsed to zero height

plus Tailwind v3 syntax against a v4 install that was only present by hoisting accident, and cc-rs picking up a machine-local Xcode path from a bare [env] block in .cargo/config.toml that applied to every target.

The tests were rewritten against real output rather than loosened: the old markdown test never typed anything and matched any article/.markdown/.prose container. It now types **bold text** and asserts a real <strong> renders, so it still fails if markdown rendering breaks.

Left open deliberately, tracked separately: icon.icns and the three tray-*.png files are still 1×1 placeholders. They make the macOS app and tray look blank but break no build.