[dovvnloading]

Problem

SceneCanvas.tsx registered all 17 *NodeView components through static imports, so every one landed in the initial chunk whether or not the open canvas held a single node of that kind.

That is the whole of the gap the bundle ratchet has been raised four times to accommodate — 815,000 → 840,000 → 866,000 → 917,000 — and every one of those amendments named this as the fix and then deferred it:

Closing the real gap still needs the eagerly-rendered node views code-split — work no stage owns, and which this stage does not pretend to do.

Change

Each kind is now its own chunk, fetched the first time a node of that kind renders.

largest chunk   890,541 -> 780,470 bytes   (-110,071, -12.4%)
total JS      1,445,539 -> 1,456,011 bytes (+10,472,  +0.7%)

The first time either number in check-bundle-size.mjs has moved down. Total going the other way is expected rather than a regression — splitting redistributes code and adds a small per-chunk overhead — and the budget ADR-019 actually sets is on the initial chunk, what the app must parse before it can paint. Both ceilings are re-anchored to ~3% over measured reality, and the raise on the total is recorded as a raise.

Stated plainly, as the raises were: at 780,470 the initial chunk is still ~52% over the 512,000-byte budget, down from ~74%. React and React Flow are the bulk of what remains. This closes the gap attributed to the node views, not the whole gap.

The Suspense boundary is per node, not one around the canvas. React Flow renders node components itself, deep in its own tree, so a single boundary higher up would suspend the whole canvas — every node plus the pane, controls and minimap — the first time any one kind loaded. The fallback renders a card-shaped shell rather than nothing, because React Flow has already positioned and sized the node by then, and an empty fallback would collapse the card and let edges snap to a zero-size box.

The render-count gate needed real work, not a relaxed assertion

renderCountGate.test.tsx measures re-renders by counting a stubbed ChatNodeView. With the views behind lazy(), the first synchronous render produces the fallback — so the gate measured zero renders, and its own "guards the guard" case caught exactly that. It would have passed vacuously if I had only touched the ceiling.

It now waits for the chunks to mount before counting. Two details were load-bearing:

• The wait condition is positive (every expected stub on screen). "No fallback shells remain" is also true before anything renders, so it resolved immediately under load and put the zero-measurement bug straight back — it passed when the file ran alone and failed in the full suite.
• The timeout is 5s rather than waitFor's 1s default, because what is being waited on is vitest transforming 17 new chunk entry points, which exceeded 1s in a full parallel suite.

With that fixed, the gate still measures exactly 1 re-render for a single-node content edit — which is the evidence that memoization survives the new wrapper rather than an assumption that it does.

Test plan

• npm run check clean end to end: schema, typecheck, lint (0 errors), 2190 vitest tests, build, and the bundle gate at the new ceilings.
• Verified in the real built app against the real backend, not just in jsdom:
  • an empty canvas fetches no node-view chunk at all;
  • creating a Conversation node fetches ConversationNodeView plus its shared card components (NodeShell, NodeMenu, NodeMarkdown, CollapseToggleButton, useStreamBuffer) and nothing else;
  • the other 16 kinds are never requested, and the node renders correctly with no stuck fallback.

🤖 Generated with Claude Code