"Rstack lint bridge" E2E fails on main: fixture rs lint loads 0 rules

[fi3ework]

Problem

The Rstack lint bridge E2E suite fails on main on a clean checkout, independent of any branch under review:

RSTACK_LINT_E2E_SUITES='Rstack lint bridge' VSCODE_CLI=1 pnpm test:e2e lint

Error: 2 E2E test(s) failed:
- Rstack lint bridge matches rs lint and evaluates define.lint outside the extension host: Timed out after 60000ms waiting for rslint diagnostics for file:///tmp/rsv-…/w/src/index.ts. Last rslint diagnostics: <none>
- Rstack lint bridge "after each" hook for "matches rs lint and evaluates define.lint outside the extension host": Timed out after 60000ms waiting for rslint diagnostics for file:///tmp/rsv-…/w/src/index.ts. Last rslint diagnostics: <none>

Reproduced twice on main (2026-09-03) after pnpm --filter rstack build. Environment: Node v26.5.0 (the repo's and fixture's .nvmrc selection), fixture rstack 0.6.1 with transitive @rslint/core 0.8.2.

What points at the fixture rather than the extension

Running the fixture's own CLI outside VS Code also loads no rules:

pnpm --dir packages/vscode/e2e/fixtures/rstack exec rs lint
Found 0 errors and 0 warnings (linted 4 files with 0 rules in 305ms using 14 threads)

So the fixture's define.lint() in rstack.config.* is not being picked up by rs lint either. The extension's bridge test asserts parity with rs lint, and both sides currently agree on "no rules", which is why the suite waits forever for a diagnostic that never comes.

Not yet isolated: whether this is the pinned rstack 0.6.1 shim vs @rslint/core 0.8.2, the Node 26 line, or a change in how @rstackjs/load-config resolves the config. Worth checking whether the fixture passes on the Node version CI uses and on rstack 0.6.4 (already bumped in the dev deps by #37).

Why it matters

• Nothing in CI can currently prove the lint × rstack.config.* bridge works.
• Track the latest @rslint/core / @rstest/core: verify 0.9.0, join rstack-ecosystem-ci, un-pin E2E fixtures #40 (tracking latest cores / ecosystem-ci) needs a green full lint slice as its baseline.

[fi3ework]

Root cause confirmed by A/B in isolated installs:

rstack	@rslint/core	rs lint on the fixture
0.6.1	0.8.1 (pinned via override)	1 rule, no-debugger reported
0.6.1	0.8.2	0 rules
0.7.2	0.9.0	1 rule, no-debugger reported

@rslint/core 0.8.2 (web-infra-dev/rslint#1851, "define config target semantics") changed an explicitly selected config's path base: relative files / ignores / parserOptions.project now resolve from the config module's directory, not the invocation cwd. rs lint in rstack 0.6.1 passes node_modules/rstack/dist/rslintConfig.js as --config, and that shim exports the project's lint entries with no path base, so files: ['src/**/*.ts'] is matched from node_modules/rstack/dist/ and nothing matches. rstack 0.7.2's shim maps every entry to { basePath: process.cwd(), ...entry } using the flat-config basePath support added in web-infra-dev/rslint#1945 (0.9.0), which restores the match.

Why it started failing between the 08-25 green run and now: the fixture pins rstack@0.6.1, whose @rslint/core: ~0.8.0 floated from 0.8.1 to 0.8.2 (published 2026-08-27). Fixture lockfiles are gitignored by design, so the float reached CI on the next run.

Not related to Node 26 and not a regression in #44 / #45. Fix: bump the fixture to rstack@0.7.2.