[endrix]

The first seam for moving wfpy's own features into wfpy-ide. wfpy's property-panel and run-time agent UI live in the webview, so wfpy-ide needs a webview bundle of its own (as chisel-ide already ships) that is the stock diagram plus wfpy's modules, without copying the stock start-up.

What changes

• startStockDiagram({ features }) in packages/diagram-client/src/stock-starter.ts (imported by path, @dialogram/diagram-client/stock-starter, not from the barrel: it pulls in GLSP's VS Code webview integration, which only a bundle needs). It does exactly what the stock entry did:

  • the webview channel and the execution-overlay routing on GLSP's messenger;
  • the stock views and feature UI;
  • the palette header controls and SVG export;
  • the context-menu debug switch and the start-up perf breadcrumb.

  The product's feature modules load after the stock views and feature UI (stockDiagramOptions, beside composeDiagramModules), so a rebind there replaces a stock feature binding. The VS Code integration and GLSP's grid, helper-line, hover and context-menu modules still load after them, and the context-menu service is rebound last. A stock module passed again throws a clear TypeError, not a blank webview, and a second call warns and does nothing.

• The stock entry (diagram-client.ts) is now startStockDiagram() and its stylesheet imports.

• clientAssets on SidecarProfileInput, threaded onto DiagramProfile.clientAssets as data. A hand-assembled profile could already name its own bundle; a sidecar product could not.

• README §4 shows the product bundle. §3 shows the resolver a product needs for the path import, since the package has no exports map. Changelog entry under Added.

• stock-starter-build.test.ts builds the stock entry and a product entry (through that resolver) with esbuild and pins the stylesheet order: GLSP's, then the stock diagram's, then the product's. With the stylesheets imported before the starter, it fails.

The cascade trap, and how it was checked

esbuild writes CSS in the order it meets it, and the starter's imports bring GLSP's own stylesheets (sprotty, tool palette, …). My first version imported the stylesheets before the starter, which put GLSP's rules after the stock ones and let them win. I caught that by building main and this branch side by side. The entry now imports the starter first. Results:

• The stylesheet is byte-identical to main's, ignoring the path comments esbuild writes.
• The script runs the same start-up in the same order: debug switch, starter, perf breadcrumb, header controls, SVG export.
• The remaining script differences are renumbered identifiers, composeDiagramModules placed after the module it now imports, and two empty CSS stubs evaluated later.

Checks

• scripts/typecheck.sh: 5/5 packages.
• scripts/check-neutrality.sh: 5/5 gates.
• npm run build: OK.
• vitest:
  • diagram-client 367/367, including the new stock-feature-modules.test.ts and stock-starter-build.test.ts;
  • sidecar-toolkit 328/329, including the new client-assets.test.ts. The one failure is the known local timeout in variant-node-create-wizard.test.ts, which passes in CI.

https://claude.ai/code/session_01EToj6RJRMSSHQiqGNMU9wv