We're treating this as a pre-existing environment issue rather than something to fix in this PR: the hydration class mismatch comes from the router's active/hash computation in @tanstack/vue-router/router-core, which this diff doesn't touch. The PR description itself confirms this is a known bug tracked in a separate, blocking PR (#8440), and this PR is intentionally kept in draft until that fix lands, so no code changes are proposed here.
Self-Healing CI
Classification: Environment state
No code changes are applicable.
This was not classified as a code change for the following reasons:
The failing tests all show the same deterministic error: a Vue hydration class mismatch where the server renders class="null" but the client expects class="active" on a hash-sensitive Link. This isn't a flaky or timing-related failure (flakiness rate is 0%), so it comes down to whether the root cause lives in code this PR changed.
Looking at the diff, every new file belongs to the benchmark scenario itself (fixture.ts, setup.ts, src/app.tsx, src/client.tsx, src/server.tsx, vite configs, project.json, docs). None of them touch router runtime code — no files under @tanstack/vue-router or router-core are part of this PR, and touched_projects is limited to "root" and "@benchmarks/client-nav".
The actual mechanism causing the mismatch is structural: the scenario's hash-sensitive Link uses hash={...} with activeOptions={{ includeHash: true }}, evaluated against a router that sees serverUrl (no fragment) during SSR and clientUrl (${serverUrl}#details) during client hydration. Since browsers never send URL fragments to the server, the router's active-state computation for that Link will always disagree between the server-rendered markup and the client's first render. That computation lives in the router packages, not in anything this diff modifies — the new scenario only exercises a pre-existing behavior.
Critically, the PR body itself states this explicitly: test:unit is documented as currently failing on "the known hydration class mismatch," and the PR says it is "Blocked on #8440, which fixes the hash-dependent Link hydration mismatch exercised by this workload," with the PR intentionally kept in draft until that fix lands.
The similar-task-failure-detector found no matching failure on branch 8439, but that's expected rather than exculpatory — branch 8439 doesn't contain this Vue hydration scenario at all (it only retains the React and Solid scenarios per the PR body), so there was nothing there to reproduce the failure against. It doesn't indicate the underlying router bug is new to this diff.
Given the instructions to never weaken test assertions or diagnostics to force a pass, and that a genuine fix would require router runtime changes that are explicitly out of scope for this PR (and already deferred to the blocking PR #8440), no code changes are proposed. This is a pre-existing issue in unmodified dependency code that this PR's new test surfaces but did not cause.</reasoning> <parameter name="confidence">9