Support multiple independent XYG visualizations with one lifecycle contract #81

Problem

There is no general visualization lifecycle manager today. ResultGraphPanel, ArtifactVisualizationPanel, and FigurePanel each expose a static singleton current. A second graph replaces the first graph; a second chart/map/timeline replaces the current artifact view. Selection linking and session data also follow one current graph/result.

Existing renderer code has useful fragments—destroy/fit/relayout/highlight handles, render generations, worker cancellation, draft/committed state—but they are not one instance-keyed contract.

Objective

Replace singleton visualization state with a multi-instance XYG controller and lifecycle protocol that safely coordinates data, layouts, interactions, temporal/spatial filters, state, diagnostics, and disposal.

Concrete Lifecycle Contract

Each instance is keyed by a stable instanceId—normally project root plus visualization path, with a generated ID for an unsaved view—and owns:

• source result and graph generation identity;
• typed data/XYG figure handle and viewport;
• presentation state and dirty/committed state where applicable;
• monotonic renderGeneration;
• native/worker layout and playback cancellation;
• row/node/edge/mark selection mapping;
• diagnostics and disposal registrations.

The bounded controller surface should cover:

• mount
• updateData
• updatePresentation
• fit
• relayout
• highlight
• resize
• extractSerializableState
• dispose

Requirements

• Replace static singleton panel state with a registry keyed by instance identity.
• Allow multiple graphs, charts, timelines, and maps to remain open independently.
• Correlate every host/webview/native/worker message with instanceId and renderGeneration.
• Reject stale updates, events, layout positions, playback frames, and selections.
• Cancel superseded render/layout/playback work and dispose timers, workers, native handles, listeners, and buffers.
• Link table/graph/chart/map/timeline selection and temporal/spatial filters only through explicit coordination groups.
• Preserve each instance's source result rather than routing through one session lastResult.
• Maintain visible dirty/commit behavior only for the active contract; no legacy visualization compatibility is required.
• Define lifecycle diagnostics as prepare/layout/paint/ready/failed/disposed with safe counts, durations, and stable codes.
• Do not log result properties, rows, coordinates, timestamps, vectors, or artifact contents.
• Honor VS Code webview serialization/revival and remote extension-host constraints.

Acceptance Criteria

• Two or more saved graphs and mixed visualization kinds remain open, update, select, and dispose independently.
• Late worker/native replies cannot mutate a newer revision or another instance.
• Closing/replacing a view terminates all owned work and releases resources deterministically.
• Explicitly linked views synchronize selection/time/space; unlinked views remain isolated.
• Lifecycle events identify the correct instance, revision, phase, counts, duration, and stable failure code.
• Extension reload/revival restores the active XYG-native state or fails clearly.
• Leak/resource tests cover repeated open/update/close and multi-view stress.

BDD Completion Scenarios

Scenario: Multiple views remain independent

Given two graphs, a timeline, and a map opened from distinct GraphForge results
When one view relayouts, changes time range, selects an entity, or closes
Then only explicitly linked views receive the intended coordination event
And every other view retains its own data, viewport, and work.

Scenario: Superseded work cannot land

Given an XYG instance starts a new render while an older layout is still running
When the older job replies
Then its revision is rejected and its resources are disposed
And the active scene remains unchanged.

Implementation Notes

Likely surfaces include all three panel classes, panel grouping, GraphForgeSession, result table linking, project commands, webview protocols, renderer handles, worker scheduling, document state, and extension serialization.

Observability

Safe instance ID hash, visualization kind, render revision, phase, entity/row counts, duration, cancellation/disposal outcome, and stable code.

Security And Privacy

Do not place project paths or result values in cross-view diagnostics. Validate all instance/revision messages and preserve strict CSP/local assets.

Testing

Unit registry/state transitions, stale-message races, worker/native cancellation, multi-panel extension integration, selection/filter coordination, webview revival, repeated lifecycle leak tests, accessibility, and remote-host E2E.

Documentation

Update architecture, lifecycle protocol, requirements, testing, commands/agent responses, troubleshooting, and multi-visualization examples.

Non-Goals

Cross-library adapters, legacy artifact readers, automatic cross-view linking, or visualization computation in GraphForge Core.

Related Issues

• Typed projection: this repository's sibling XYG projection issue
• XYG scheduling: Implement CoSE-grade layout and progressive cancellable graph scheduling xyg#35
• XYG interaction: Complete graph interaction, coordinated selection, and accessibility fidelity xyg#36
• Historical lifecycle implementation: feat: make AntV the explicit visualization default and add geospatial + temporal artifacts #67