Validate Shared Graph View Cross-Host Parity

Goal

Establish evidence that the WebApp and VS Code Graph surfaces share one implementation and produce consistent behavior and visual semantics under Host-specific themes and navigation.

Sources

• discovery/editor-graph-view-technical-research-2026-07-17
• tasks/implement-shared-graph-view-runtime
• tasks/migrate-webapp-to-shared-graph-view
• tasks/integrate-shared-graph-view-vscode-preview

In Scope

• Run the same empty, small, medium, and large projection fixtures through WebApp and VS Code adapters.
• Compare normalized node attributes, edge programs, selected and neighbor state, labels, viewport actions, and source-activation outcomes.
• Validate light, dark, high-contrast where supported, reduced motion, long labels, reciprocal references, unresolved targets, and empty graphs.
• Measure bundle delta, projection size, first meaningful render, layout settle time, longest main-thread task, interaction responsiveness, refresh movement, idle CPU, and retained memory after disposal.
• Exercise 25-node, approximately 500-node, and approximately 5,000-node fixtures.
• Run real WebApp, packaged VSIX, Preview reload, extension restart, and Remote validation.
• Record discrepancies as shared-runtime defects or explicit Host-adapter differences rather than silently accepting divergent implementations.

Out Of Scope

• Pixel-identical colors, fonts, borders, or focus styling across different Host themes.
• Frontmatter-defined groups and filters.
• A production 3D renderer.
• Editable graph relationships.

Acceptance Criteria

• Both Hosts use packages/graph-view; no duplicate Host-specific Sigma construction, layout, reducers, or Graph state remains.
• The same projection and presentation configuration produce equivalent normalized layout, node sizing, edge direction, label policy, selection, one-hop emphasis, and reset behavior.
• Theme differences are traceable only to explicit Host semantic-token mappings.
• Source navigation, active-document following, reload, and disposal work according to each Host adapter contract.
• The text legend exposes configured taxonomy and Term identities, while the accessible selected-node summary exposes the active Page identity, path, and relationship count in both Hosts without duplicating the complete searchable node collection. Filter summaries become required when filters are implemented.
• Medium and large fixtures remain responsive within recorded budgets, layout work is bounded, and idle graphs do not consume continuous CPU after settling.
• WebApp checks, VS Code package and integration checks, shared package tests, performance evidence, and the milestone local validation gate pass before push and CI.

Result

The 2026-08-12 and 2026-08-13 follow-ups completed the local WebApp, packaged VS Code, and Remote SSH validation loops. Evidence covers 25-, approximately 500-, and approximately 5,000-node fixtures; first render, layout settle, longest task, reset responsiveness, 30-second idle samples, high contrast, reduced motion, repeated disposal, window reload, Remote source navigation, and Remote Extension Host and LSP resource use. The exact d57079e candidate passed main CI, and its Linux CLI and VSIX artifacts were used for the Remote run.

The accepted Remote host at tiscs@10.0.0.53 rendered and interacted with both the 25-node and 5,000-node fixtures. Node activation navigated the native Remote Markdown Preview to the real note path, expand and Escape worked, window reload restored one Graph instance, ten Preview disposal cycles left no iframe target, and the large fixture completed render, selection, F reset, expand, Escape, and close. The 5,000-node CLI projection was 2,314,372 bytes, confirming the scoped 8 MiB stdout budget. Validation-created remote and local state was recorded, copied to ignored evidence storage, and removed after the complete run; post-cleanup checks found no validation directories, processes, temporary paths, or listeners.

The task is ready for review with two explicit Host boundaries: WebApp Worker settle and VS Code synchronous layout are measured separately, and VS Code workbench.reduceMotion: on did not propagate to the native Markdown Preview webview even though the shared runtime honored reduced motion when the media feature was present. Repeated VS Code Preview disposal released the iframe and all Forma lifecycle references, but Chromium retained collectible renderer memory until DevTools garbage collection; this Host high-water behavior remains a recorded performance risk rather than being reported as zero growth. Full evidence is recorded in discovery/shared-graph-view-cross-host-parity-validation-2026-08-11.

The 2026-08-13 performance closeout records explicit budget, observation, and pass/fail comparisons; exact WebApp and VSIX integration deltas; five-run refresh-movement measurements for both Host policies at approximately 500 and 5,000 nodes; and a final real packaged VS Code medium-fixture run. Measurement exposed a whole-graph relayout on projection refresh. Commit 09a6788 preserves initial Host layout behavior while keeping every surviving refresh coordinate stable and seeding only new nodes near known neighbors. The packaged 500-node VS Code Preview reached first render and synchronous settle in 100.7 ms, recorded a 109 ms longest main-thread task, and completed five F-reset two-frame samples in at most 13.9 ms. All recorded performance, bundle, selection-retention, finite-position, and refresh-stability budgets now pass. The validation record also corrects the output-budget scope: config inspect remains at 1 MiB while only check, workspace health, workspace dashboard, and view render use 8 MiB.