fix(router): invoke parallel slot revalidate() fns when slot missing from clientSegmentIds - #482

…ng nav (#482 follow-up) (#483)

* test(router): e2e for parallel slot revalidate() after action + sibling nav (#482 follow-up)

Adds Playwright coverage for the user-reported scenario PR #482 fixed at the
unit level: parent-chain @panel parallel slot, server action that opts out
of POST revalidation via revalidate() returning false, sibling-route
navigation immediately after.

Pre-fix observable symptom: the action's revalidation phase pruned the
panel from the client's matched set (matchedIds.push was guarded by a
4-condition check that excluded parent-chain parallels), and the next nav
arrived without @panel in _rsc_segments. The resolver short-circuited and
never invoked the panel's revalidate() fn — the count from the panel's
loader did not change, and in some cases the slot rendered as
component:null.

Fixture (test-app/src/urls/parallel-reval-after-action.tsx) sets up the
exact shape from the bug report: parent layout with @panel, panel has
loader(ParallelRevalLoader) + revalidate({method}) => method !== "POST",
two sibling pages, and reuses the existing RevalidateButton + triggerRevalidation
no-op action.

Test (e2e/parallel-reval-after-action.test.ts) walks the sequence in both
dev and production modes (per the global "ALL e2e tests must cover both
modes" mandate):

  1. nav to page A → assert panel mounted, capture count
  2. click action → panel must stay mounted, count unchanged (POST opt-out)
  3. nav to page B → panel re-renders, count strictly greater
  4. nav back to A → panel re-renders again, count strictly greater
  5. (second test) repeat the action+nav cycle twice to pin that the fix
     survives multiple round-trips, not just the first

Both tests pass on main; they would fail (count stays equal, or panel
disappears) if either part of the PR #482 fix is reverted.

* test(router): name parallel-reval-after-action include + regenerate gen file

Reviewer flagged that the new test-app routes (revalAfterActionPageA/B)
were not appearing in router.named-routes.gen.ts, which AGENTS.md mandates
must stay in sync with route definitions. The original include() was
unnamed, matching the sibling parallel-loader-reval pattern, so the rango
plugin filtered the route names out of the gen file.

Adding `{ name: "parallelRevalAfterAction" }` to the include() and
rebuilding registers them as `parallelRevalAfterAction.revalAfterActionPageA`
and `parallelRevalAfterAction.revalAfterActionPageB`. The Playwright tests
still pass in dev and production (they reference the routes by URL string,
not by name lookup, so the rename is transparent to them).

…r via policy args (#568) (#578)

resolveOrphanLayoutWithRevalidation inlined ~130 lines of parallel-slot
resolution that duplicated resolveParallelSegmentsWithRevalidation. The two
diverged in exactly two ways; both are now explicit args on the shared helper,
preserving each path BYTE-FOR-BYTE:

  - parentChainDefault: "type-derived" (main) seeds an unknown parent-chain
    slot with belongsToRoute || isNewParent; "force-render" (orphan) seeds
    unconditional true -- orphan parallels always belong to the route (the #482
    blank-parent-chain-slot guard). Divergence (A): INTENTIONAL, carried, not
    normalized.
  - loaderOrder: "after" (main) emits a slot's loaders after the slot segment;
    "before" (orphan) emits them first. Divergence (B): cosmetic emission order
    (the client reconciler is order-insensitive), carried exactly.

The orphan loop becomes a single call; the orphan layout's own loader/inherited/
handler resolution is untouched.

Coverage-first: the existing parallel-revalidate-fns suite never exercised the
divergent case (all orphan tests used belongsToRoute=true, where the policies
coincide). Added pinning tests, written + verified green BEFORE the refactor:
  - (A) belongsToRoute=false, slot not in client, parent in client, zero
    revalidate fns -> main SKIPS the slot (component null), orphan FORCE-RENDERS
    it. Non-vacuous: normalizing the orphan policy turns the orphan test red.
  - (B) loaderOrder flips slot-vs-loader emission order; orphan chooses "before".

Behavior-preserving: semantic matrix 61/61 dev+prod (no row changes), parallel
e2e 65/65 dev+prod, adversarially verified byte-identical for both paths.

…an unrendered parallel slot (#814)

A parallel() slot carrying revalidate(() => false) never appeared when the route
owning it was reached by soft navigation, while a direct load of the same URL
rendered it fine. Reported against tests/vite-rsc-demo: land on
/shop/product/:slug, click through to /shop, and the category sidebar stays
blank until a full reload. Whether the slot showed up depended on the order the
user happened to navigate in.

The slot id is absent from the partial request's client-segment set because the
product page never rendered it. resolveParallelSegmentsWithRevalidation seeds
that case "new-segment" (render it), then passes the seed to
evaluateRevalidation, where the user's hard `false` overrode it — emitting
component:null for a slot the client had nothing cached to fall back on.

The three sibling resolvers (loaders, layout/route entries, orphan layouts)
never had this bug because they express the same invariant as an unconditional
early return that never consults user predicates. The parallel path cannot copy
that shape: #482 deliberately made it consult predicates for an unknown slot so
a "skip-parent-chain" seed could still be raised, and because evaluateRevalidation
re-throws a Response from a predicate as control flow, an early return would
silently drop revalidate(() => { throw redirect(...) }).

So the seed is floored rather than short-circuited. defaultOverride gains an
optional `floor`; evaluateRevalidation applies it at all three exits through a
new local decide(), so predicates still run and may only raise the decision.
Applying it inside evaluateRevalidation rather than clamping the returned
boolean at the call site keeps the revalidation trace to one entry per segment —
an outer clamp pushed a second, contradicting entry, and flushRevalidationTrace
buckets by finalShouldRevalidate with no dedup by segmentId, so the slot was
counted as both revalidated and skipped and `total` was inflated.

revalidate() now means "render once, then never refetch" rather than "sometimes
never appear at all". Once the slot is on the client the seed is unfloored and a
`false` is honored exactly as before, as are a `true` and a thrown Response in
every case.

Regression tests proven red before green: parallel-revalidate-fns-invocation.test.ts
gains six tests covering the floored seeds (belongsToRoute, isNewParent, orphan
force-render, and soft {defaultShouldRevalidate: false}, which exits by a
different path than a hard false) plus the two cases that must NOT floor —
client already has the slot, and the skip-parent-chain seed — without which
"floor to true" could widen into "parallel slots always render".
revalidation-trace-pipeline.test.ts gains two tests pinning one trace entry per
decision, verified to fail against the double-push shape. Dev and production e2e
in three apps: the router test-app and cloudflare-basic (workerd) via a reduced
fixture, and vite-rsc-demo driving the reported /shop routes with no new fixture;
each has a direct-load control so a broken fixture is distinguishable from a
broken soft nav.

The client-knowledge seed invariant, previously implicit in five differently
shaped code blocks with no name, is now stated in docs/internal/execution-model.md
with a table of which resolver uses which shape and why the parallel path
diverges. skills/parallel/SKILL.md covers the consumer half.

Not done: a general floor adopted by the sibling resolvers. Each would have to
start calling evaluateRevalidation unconditionally, invoking user predicates on
paths that never have — reversing #482's deliberate sibling audit. No userland
test through @rangojs/router/testing either: dispatch is RSC-free by design and
rejects partial requests to component routes, and renderRoute is client-only, so
no primitive can reach a partial component-route render.

Also carries an unrelated test fix. default-prefetch-none's intersection test
asserted one /assets/runtime-*.js fetch, but #809 folded the prefetch runtime
into the eager router chunk precisely so that fetch would stop happening, making
the production assertion unsatisfiable. #809 updated build-test-app.setup.ts and
the manual-chunks unit tests but not this assertion, and its merge-time run
skipped cloudflare-basic-e2e via path filtering, so it landed unnoticed; main's
scheduled runs had been red on it since 2026-07-24. The count is mode-dependent —
dev still serves browser/prefetch/runtime.ts as its own unbundled module — so it
is flipped to a mode-aware check rather than deleted, turning a stale expectation
into a guard for the invariant #809 established.