76-76: Documentation updated to reference AbstractGraph instead of Graph.

The documentation has been updated to reference AbstractGraph instead of Graph, which aligns with the broader refactoring effort across the codebase that's transitioning to a more abstract graph representation.

21-22: Module declaration updated to reference AbstractGraph.

The module declaration and interface have been updated from Graph to AbstractGraph, reflecting the codebase's transition to a more abstract graph representation. This change maintains consistency with the architectural updates across the project.

24-25: Module declaration updated to reference AbstractGraph.

The module declaration and interface have been updated from Graph to AbstractGraph, reflecting the codebase's transition to a more abstract graph representation. This change is consistent with the architectural updates across the project.

19-20: Module declaration updated to reference AbstractGraph.

The module declaration and interface have been updated from Graph to AbstractGraph, reflecting the codebase's transition to a more abstract graph representation. This change is consistent with the architectural updates across the project.

21-22: Type reference update looks good.

This change from Graph to AbstractGraph is consistent with the broader refactoring effort in this PR, which appears to be moving from concrete implementation types to more abstract interfaces. This approach improves the codebase's flexibility by allowing different graph implementations to share the same interface.

21-22: Type reference update is appropriate.

This change from Graph to AbstractGraph is consistent with the broader refactoring effort in this PR. The interface content remains the same, maintaining functionality while making the type hierarchy more flexible.

21-22: Type reference update looks good.

This change from Graph to AbstractGraph is consistent with the broader refactoring effort in this PR. This systematic approach to updating type references throughout the codebase will help ensure a cohesive abstraction layer for graph functionality.

19-20: Type reference updated to use AbstractGraph

The module declaration and interface name have been changed from Graph to AbstractGraph. This change is part of a broader refactoring pattern across the codebase to use a more abstract representation of graph functionality.

25-25: Import statement updated to use AbstractGraph

The import has been updated to use the more abstract AbstractGraph type instead of the concrete Graph implementation, which aligns with the refactoring pattern across the codebase.

31-31: Constructor parameter type updated

The constructor parameter type has been changed from Graph to AbstractGraph, allowing the PanningManager to work with any implementation that adheres to the AbstractGraph interface rather than requiring a specific implementation.

17-17: Import statement updated to use AbstractGraph

The import has been updated to use the more abstract AbstractGraph type instead of the concrete Graph implementation, aligning with the refactoring pattern across the codebase.

20-20: Type reference updated in Pick utility

The Pick utility type now selects properties from AbstractGraph instead of Graph, maintaining the same interface while making the code more flexible by working with a more abstract type.

19-20: Module declaration and interface name updated

The module declaration and interface name have been changed from Graph to AbstractGraph. This change is consistent with the broader refactoring pattern to use a more abstract representation of graph functionality throughout the codebase.

21-22: Interface abstraction improves extensibility.

The change from Graph to AbstractGraph enhances modularity by providing a more generic interface that can be implemented by different graph types. This change aligns with the PR objective of efficiently loading plugins by allowing more selective feature implementation.

23-24: Interface abstraction enables flexibility in plugin loading.

Updating the module declaration to use AbstractGraph instead of Graph is consistent with the changes in other files and supports the goal of allowing selective feature loading. This abstraction will enable more granular control over what plugins and style builtins are loaded.

20-21: New exports support the feature-selective loading mechanism.

Adding exports for AbstractGraph and BaseGraph is essential for the PR objective. These exports allow consumers to:

1. Use AbstractGraph for type-checking against the minimal required interface
2. Use BaseGraph as a foundation for custom graph implementations that don't load all default plugins

This change is a key enabler for the "efficiently not load default plugins and style builtins" feature.

20-21: Type change from Graph to AbstractGraph enhances flexibility

This change is part of a broader refactoring to use the more abstract AbstractGraph type instead of the concrete Graph implementation, which aligns with the PR's goal of making plugin loading more efficient.

28-28: Replacing Graph with AbstractGraph import

Good addition - importing the more abstract type to replace concrete implementations throughout the codebase.

1105-1105:

#!/bin/bash
# Verify if there are any plugins that might break with this change
echo "Checking for plugins that might depend on Graph-specific methods not in AbstractGraph..."
rg -l "import.*Graph.*from" --glob "**/*Plugin*.ts"

Action Required: Verify Plugin Compatibility with the New AbstractGraph Interface

The interface update to use AbstractGraph is on track. However, our verification script flagged one potential risk:

• File: packages/core/src/view/plugins/FitPlugin.ts
  It appears this plugin imports or may depend on a concrete Graph implementation. Please verify that it either no longer relies on any Graph-specific methods or has been updated to fully support the new AbstractGraph interface.

19-20: Module declaration updated to use AbstractGraph

This change is consistent with the overall pattern of replacing concrete Graph types with the more abstract AbstractGraph interface.

20-21: Module declaration updated to use AbstractGraph

This is part of the consistent pattern of abstraction throughout the codebase, which will enable more flexible plugin loading as described in the PR objectives.

19-20: Appropriate switch from concrete implementation to abstract interface.

The change from Graph to AbstractGraph aligns with good software design principles by depending on abstractions rather than concrete implementations. This supports the PR's objective of more efficient plugin loading by enabling more flexible architectural patterns.

21-21: Good addition of the required import.

Adding the import for AbstractGraph is a necessary part of the type refactoring across the codebase.

28-30: Appropriate type replacement for PartialGraph.

Changing from Graph to AbstractGraph in the type definition reflects the PR's effort to make the codebase work with a more abstract graph representation.

42-44: Consistent type replacement for PartialEdge.

This change maintains consistency with the other modifications, ensuring the EdgeMixin properly references the abstract interface rather than the concrete implementation.

20-20: Updated import to use AbstractGraph.

This change is consistent with the abstract interface pattern being applied throughout the codebase.

41-42: Updated JSDoc parameter type documentation.

Good practice to keep documentation in sync with code changes, ensuring that JSDoc properly reflects the AbstractGraph type.

44-44: Updated constructor parameter type.

The parameter type change from Graph to AbstractGraph allows the CircleLayout to work with any implementation that satisfies the AbstractGraph interface, increasing flexibility.

1390-1395: Improved method documentation for createGraph.

The updated documentation clarifies that the graph is created without a container and is initialized later via setGraphContainer. This provides better guidance to developers about the method's behavior.

19-19: Good job updating the import to use AbstractGraph

The change from importing Graph to AbstractGraph aligns with the PR's objective to create a more abstract implementation, which would facilitate not loading default plugins when unnecessary.

22-24: LGTM - Type update from Graph to AbstractGraph

This update to the PartialGraph type definition is in line with the refactoring effort to use the more abstract AbstractGraph type throughout the codebase.

35-37: LGTM - Type update for PartialValidation

Changing from Graph to AbstractGraph in the PartialValidation type definition is consistent with the overall refactoring approach.

22-23: LGTM - Module declaration updated to use AbstractGraph

The update from '../Graph' to '../AbstractGraph' in the module declaration and from Graph to AbstractGraph in the interface name is part of the broader refactoring effort to use a more abstract graph type. This change allows the folding functionality to be applied to any implementation of the abstract graph interface, which aligns with the goal of more efficient plugin loading.

21-22: LGTM - Module declaration updated to use AbstractGraph

The change from '../Graph' to '../AbstractGraph' in the module declaration and from Graph to AbstractGraph in the interface name is consistent with the refactoring approach. This allows editing capabilities to be applied to any implementation of the abstract graph interface.

20-21: LGTM - Module declaration updated to use AbstractGraph

The update from '../Graph' to '../AbstractGraph' in the module declaration and from Graph to AbstractGraph in the interface name follows the consistent pattern of refactoring across the codebase. This change ensures tooltip functionality can work with any implementation of the abstract graph interface.

23-23: Type import updated to use AbstractGraph instead of Graph

The import has been changed to use AbstractGraph instead of Graph, which aligns with the broader refactoring effort in this PR to use more abstract interfaces for graph-related functionality.

26-39: Type reference updated from Graph to AbstractGraph

The PartialGraph type now picks properties from AbstractGraph instead of Graph. This change is consistent with the architectural shift towards using abstract interfaces and maintains all the existing property selections.

40-52: Type reference updated from Graph to AbstractGraph

The PartialFolding type now picks properties from AbstractGraph instead of Graph. This is part of the consistent refactoring to use the abstract interface across the codebase.

46-46: Type import updated to use AbstractGraph instead of Graph

The import has been changed to use AbstractGraph instead of Graph, which aligns with the broader refactoring effort to use more abstract interfaces.

49-90: Type reference updated from Graph to AbstractGraph

The PartialGraph type now picks properties from AbstractGraph instead of Graph. This is a consistent change as part of the refactoring effort while maintaining all the existing property selections.

92-194: Type reference updated from Graph to AbstractGraph

The PartialCells type now picks properties from AbstractGraph instead of Graph. This is part of the consistent architectural change across the codebase, and maintains all the original functionality.

20-21: Module declaration and interface updated to use AbstractGraph

The module declaration has been changed from '../Graph' to '../AbstractGraph' and the interface has been updated from Graph to AbstractGraph. This change is significant as it moves the augmentation of graph functionality to the abstract interface level, which is consistent with the architectural refactoring in this PR.

17-17: Type import updated to use AbstractGraph instead of Graph

The import has been changed to use AbstractGraph instead of Graph, which aligns with the broader refactoring effort in this PR to use more abstract interfaces.

20-23: Type reference updated from Graph to AbstractGraph

The PartialImage type now picks properties from AbstractGraph instead of Graph. This maintains the existing functionality while being consistent with the architectural changes across the codebase.

21-21: Updated import to use AbstractGraph

The import has been updated to use the abstract interface type AbstractGraph instead of the concrete Graph implementation. This is part of the overall refactoring to reduce coupling with concrete implementations.

82-82: Constructor parameter updated to use AbstractGraph

The constructor parameter type has been changed from Graph to AbstractGraph, making the class more flexible by depending on the abstract interface rather than the concrete implementation. This aligns with the PR's goal of making plugin loading more efficient.

21-21: Updated import to use AbstractGraph

The import has been updated to use the abstract interface type AbstractGraph instead of the concrete Graph implementation. This is consistent with the changes in other files.

24-25: Type reference updated to use AbstractGraph

The PartialGraph type now picks its properties from AbstractGraph instead of Graph, making it more abstract and flexible. This change maintains the same picked properties but from the abstract interface.

35-36: Type reference updated to use AbstractGraph

Similarly, the PartialCells type now picks its properties from AbstractGraph instead of Graph. This is consistent with the overall pattern of making the codebase depend on abstractions rather than concrete implementations.

31-31: Updated import to use AbstractGraph

The import has been updated to use the abstract interface type AbstractGraph instead of the concrete Graph implementation, consistent with other changes in the PR.

43-43: Class property updated to use AbstractGraph

The type of the graph property has been changed from Graph to AbstractGraph, reducing coupling with the concrete implementation and allowing for more flexibility in how graph functionality is provided.

19-19: Updated import to use AbstractGraph

The import has been updated to use the abstract interface type AbstractGraph instead of the concrete Graph implementation, consistent with the pattern in other files.

30-31: Added JSDoc comment for graph parameter

A JSDoc comment has been added to describe the graph parameter, improving documentation clarity. The comment accurately describes the parameter's purpose.

40-41: Function parameter updated to use AbstractGraph

The type of the graph parameter in findTreeRoots has been changed from Graph to AbstractGraph, making the function more flexible by depending on the abstract interface rather than the concrete implementation.

21-22: Consistent interface naming - updating from Graph to AbstractGraph

This change updates the module declaration and interface name from Graph to AbstractGraph, aligning with the abstraction approach being implemented across the codebase. This refactoring will provide better flexibility by allowing different graph implementations to share the same validation interface.

19-20: Consistent abstraction - changing module declaration from Graph to AbstractGraph

Good refactoring to use AbstractGraph instead of the concrete Graph implementation. This change maintains consistency with the broader architectural changes being made across the codebase and supports the goal of not loading default plugins and style builtins unless necessary.

19-20: Updated module declaration to use AbstractGraph

This change correctly updates the module declaration to use AbstractGraph instead of Graph, maintaining consistency with the architectural changes being implemented. The zoom functionality will now extend the AbstractGraph interface, allowing for more flexible graph implementations.

25-30: Well-structured collaborator initialization with sensible defaults

The implementation correctly provides fallback options for each collaborator with a clean null coalescing syntax. This allows consumers to override specific collaborators while accepting defaults for others.

20-20: Appropriate type import update.

Importing AbstractGraph instead of likely Graph aligns with the PR's objective of enhancing modularity. This change facilitates more flexible plugin loading patterns.

22-24: Good refactoring to use AbstractGraph.

Updating PartialGraph to pick properties from AbstractGraph instead of concrete Graph improves abstraction and flexibility. This change is part of a consistent pattern across the codebase to make components depend on abstractions rather than implementations.

33-35: Consistent type abstraction.

Updating PartialPageBreaks to use AbstractGraph maintains consistency with the other changes. This refactoring enhances flexibility without changing functionality.

23-24: Appropriate module declaration update.

Changing the module declaration from '../Graph' to '../AbstractGraph' and updating the interface name maintains consistency with the broader refactoring to use abstract types. This change supports the PR goal of making plugin loading more efficient.

18-18: Consistent import update.

Importing AbstractGraph instead of Graph aligns with the rest of the refactoring changes and maintains consistency across the codebase.

43-43: Good function signature update.

Changing the parameter type to typeof AbstractGraph improves flexibility by making the applyGraphMixins function work with the abstract type instead of a concrete implementation. This enables more modular loading of graph functionality.

28-28: Appropriate import update.

Importing AbstractGraph instead of Graph maintains consistency with the other changes in the PR.

303-306: Good parameter type update and naming convention.

Changing the parameter type from graph: Graph to _graph: AbstractGraph serves two purposes:

1. Uses the abstract type for better flexibility
2. The underscore prefix properly indicates the parameter is unused in the function body

This change enhances code clarity while maintaining the same functionality.

21-21: Good addition of AbstractGraph import.

This change adds the import for the AbstractGraph type to support the constructor parameter type change, which is part of the broader refactoring to use abstract interfaces instead of concrete implementations.

42-42: Good refactoring to use AbstractGraph instead of Graph.

Changing the constructor parameter type from Graph to AbstractGraph follows the Dependency Inversion Principle. This makes the PartitionLayout class more flexible as it can now work with any implementation that satisfies the AbstractGraph interface rather than requiring a specific concrete class.

17-17: Good change to import AbstractGraph.

Replacing the Graph import with AbstractGraph aligns with the broader refactoring to use abstract interfaces throughout the codebase.

19-26: Good refactoring in PartialGraph type.

The change to use AbstractGraph instead of Graph in the Pick utility makes the type definition more flexible and consistent with the rest of the codebase refactoring.

27-39: Good refactoring in PartialLabel type.

The change to use AbstractGraph instead of Graph in the Pick utility follows the same pattern as the PartialGraph type, ensuring consistency throughout the mixin interfaces.

19-19: Good change to import AbstractGraph.

Replacing the Graph import with AbstractGraph aligns with the broader refactoring to use abstract interfaces throughout the codebase.

21-24: Good refactoring in PartialGraph type.

The change to use AbstractGraph instead of Graph in the Pick utility makes the type definition more flexible and consistent with the rest of the codebase refactoring.

25-36: Good refactoring in PartialZoom type.

The change to use AbstractGraph instead of Graph in the Pick utility follows the same pattern as the PartialGraph type, ensuring consistency throughout the mixin interfaces.

44-44: Good change to import AbstractGraph.

Replacing the Graph import with AbstractGraph aligns with the broader refactoring to use abstract interfaces throughout the codebase.

47-89: Good refactoring in PartialGraph type.

The change to use AbstractGraph instead of Graph in the Pick utility makes the type definition more flexible and consistent with the rest of the codebase refactoring. This is particularly important for this type as it includes many methods and properties.

90-156: Good refactoring in PartialEvents type.

The change to use AbstractGraph instead of Graph in the Pick utility follows the same pattern as the PartialGraph type, ensuring consistency throughout the mixin interfaces. The extensive list of methods and properties picked from AbstractGraph indicates good attention to detail in the refactoring.

576-576: Good update to use AbstractGraph type.

The change to cast this as AbstractGraph instead of Graph in the fireMouseEvent method ensures type consistency throughout the codebase and aligns with the dependency inversion principle.

29-29: Good addition of the AbstractGraph type import.

This change correctly imports the AbstractGraph type that will be used to replace the concrete Graph type in the constructor, aligning with the PR's goal to make the code more modular.

43-44: Documentation properly updated to reflect type change.

The documentation has been correctly updated to reference AbstractGraph instead of Graph. The orientation parameter documentation now correctly references DIRECTION.NORTH instead of DIRECTION_NORTH, which is more consistent with the actual code.

47-47: Appropriate type signature change to use AbstractGraph.

Changing the constructor parameter from Graph to AbstractGraph is a good refactoring that improves abstraction. This change allows the layout to work with any implementation of the AbstractGraph interface, making the code more flexible and modular.

28-28: Good addition of the AbstractGraph type import.

This change correctly imports the AbstractGraph type that will be used to replace the concrete Graph type in both the constructor parameter and class property.

65-65: Property type properly updated to AbstractGraph.

The graph property type has been correctly changed from Graph to AbstractGraph, maintaining type consistency with the constructor parameter.

86-86: Appropriate constructor parameter type change to AbstractGraph.

Changing the constructor parameter from Graph to AbstractGraph improves abstraction. This change allows CellHighlight to work with any implementation of the AbstractGraph interface, making the code more flexible and modular.

19-19: Good import change from Graph to AbstractGraph.

This change correctly updates the import to use AbstractGraph instead of Graph, aligning with the broader refactoring effort across the codebase.

22-22: Type definition updated to use AbstractGraph.

The PartialGraph type has been correctly updated to pick properties from AbstractGraph instead of Graph, maintaining consistency with the import changes.

24-24: PartialVertex type correctly updated to use AbstractGraph.

Updating the PartialVertex type to reference AbstractGraph instead of Graph ensures type consistency throughout the mixin implementation.

25-25: Good addition of the AbstractGraph type import.

This change correctly imports the AbstractGraph type that will be used to replace the concrete Graph type in both the constructor parameter and class property.

35-35: Appropriate constructor parameter type change to AbstractGraph.

Changing the constructor parameter from Graph to AbstractGraph improves abstraction. This change allows Guide to work with any implementation of the AbstractGraph interface, making the code more flexible and modular.

43-43: Property type properly updated to AbstractGraph.

The graph property type has been correctly changed from Graph to AbstractGraph, maintaining type consistency with the constructor parameter.

22-22: Good change to import AbstractGraph instead of Graph.

This change aligns with the overall refactoring to use more abstract interfaces throughout the codebase. Using abstractions rather than concrete implementations improves flexibility and maintainability.

25-27: Appropriate type update from Graph to AbstractGraph.

The PartialGraph type now picks its properties from AbstractGraph instead of Graph, which is consistent with the abstraction approach. This change maintains the same functionality while improving the architecture.

39-41: Correct update of PartialSwimlane type.

Similar to the PartialGraph change, this properly updates the source type for the property picking while maintaining the same properties and functionality.

19-19: Good change to import AbstractGraph instead of Graph.

This import change is consistent with the overall refactoring approach of using AbstractGraph throughout the codebase.

77-77: Well-maintained documentation with updated type reference.

The JSDoc comment has been properly updated to reference AbstractGraph instead of Graph, maintaining consistency between code and documentation.

81-81: Appropriate constructor parameter type update.

Changing the constructor parameter type from Graph to AbstractGraph allows for more flexible usage of this handler with different graph implementations.

98-100: Consistent property type and documentation update.

Both the JSDoc comment and the actual property type have been updated to use AbstractGraph, maintaining internal consistency.

33-33: Good change to import AbstractGraph instead of Graph.

This import change is consistent with the broader refactoring effort across the codebase.

63-63: Appropriate constructor parameter type update.

Updating the constructor parameter type from Graph to AbstractGraph makes this handler more flexible and aligns with the dependency inversion principle.

104-104: Consistent property type update.

The graph property type has been correctly updated to AbstractGraph to match the constructor parameter.

51-51: Good change to import AbstractGraph instead of Graph.

This import change is consistent with the overall refactoring approach of using AbstractGraph throughout the codebase.

156-156: Appropriate constructor parameter type update.

Changing the constructor parameter type from Graph to AbstractGraph allows this handler to work with different graph implementations.

194-194: Consistent property type update.

The graph property type has been correctly updated to AbstractGraph to match the constructor parameter.

24-24: Type import correctly updated to AbstractGraph.

The import change from Graph to AbstractGraph is consistent with the PR's objective of making the codebase more flexible by using abstractions.

53-53: Documentation updated correctly.

The JSDoc parameter description now properly references AbstractGraph instead of Graph, maintaining documentation consistency with the code changes.

59-64: Constructor signature correctly updated to use AbstractGraph.

The constructor parameter type has been properly changed to use the more abstract type, which aligns with the PR goal of implementing more flexible architecture.

66-66: Class property type correctly updated.

The internal property type is properly updated to match the constructor parameter, maintaining type consistency throughout the class.

44-44: Type import correctly updated to AbstractGraph.

The import is properly updated to use the abstract type for greater flexibility.

95-99: Constructor signature correctly updated to use AbstractGraph.

The GraphView constructor now properly uses the abstract type, allowing for more flexible implementations.

161-161: Class property type correctly updated.

The graph property type is correctly updated to AbstractGraph to match the constructor parameter.

24-24: Type import correctly updated to AbstractGraph.

The import statement is properly changed to use the abstract type, consistent with other files in this PR.

54-76: Constructor signature correctly updated to use AbstractGraph.

The SelectionCellsHandler constructor now properly accepts the abstract type.

81-81: Class property type correctly updated.

The graph property type is appropriately updated to AbstractGraph, maintaining type consistency across the class.

18-18: Type import correctly updated to AbstractGraph.

The import statement is properly updated to use the abstract type, consistent with the overall refactoring approach in this PR.

57-57: Constructor parameter type correctly updated.

The FitPlugin constructor now properly uses the AbstractGraph type, which aligns with the PR's objective of implementing more flexible architecture.

1-110: Code looks good with proper abstraction implementation.

The changes to use AbstractGraph instead of concrete Graph implementation are well-implemented throughout this file. This refactoring follows good software engineering practices by promoting loose coupling and allowing for more flexible implementations.

30-30: Import updated to use AbstractGraph

The import has been changed from using the concrete Graph type to the more abstract AbstractGraph type. This is part of a broader refactoring to make the codebase more flexible.

241-241: Method signature updated to accept AbstractGraph

The redirectMouseEvents method now accepts AbstractGraph instead of Graph. This change makes the method more flexible, enabling it to work with any implementation that conforms to the AbstractGraph interface.

21-21: Import changed to AbstractGraph

The import has been updated to use AbstractGraph instead of Graph, consistent with the architectural changes in the codebase.

26-29: PartialGraph type now picks from AbstractGraph

The PartialGraph type definition has been updated to pick properties from AbstractGraph instead of Graph. This ensures the mixin works with any implementation of the abstract interface.

30-31: PartialPanning type now picks from AbstractGraph

Similarly, the PartialPanning type has been updated to use AbstractGraph as its base type, maintaining consistency with the rest of the refactoring.

17-17: Import changed to use AbstractGraph

The import statement has been updated to import AbstractGraph instead of Graph, consistent with the architectural refactoring across the codebase.

19-19: PartialGraph type updated to pick from AbstractGraph

The PartialGraph type now picks the getView property from AbstractGraph rather than Graph, in line with the ongoing refactoring.

21-21: PartialSnap type now uses AbstractGraph

The PartialSnap type has been updated to pick properties from AbstractGraph instead of Graph, maintaining consistency with the architectural changes.

17-17: Import updated to use AbstractGraph

The import statement has been modified to import AbstractGraph instead of Graph, consistent with the architectural refactoring throughout the codebase.

19-19: PartialGraph type now picks from AbstractGraph

The PartialGraph type definition has been updated to pick the getEdgeValidationError property from AbstractGraph instead of Graph, aligning with the ongoing architectural changes.

21-21: PartialDragDrop type now based on AbstractGraph

The PartialDragDrop type now picks its properties from AbstractGraph rather than Graph, maintaining consistency with the rest of the codebase's refactoring.

22-22: Type import updated correctly to AbstractGraph.

The import has been properly updated from Graph to AbstractGraph, which aligns with the broader refactoring effort evident across the codebase.

42-42: Parameter type updated to match import change.

The function parameter type has been correctly updated from Graph to AbstractGraph, maintaining consistency with the import change. This change allows the function to work with any implementation that satisfies the AbstractGraph interface rather than requiring the concrete Graph class.

25-25: Import statement updated to use AbstractGraph.

The import has been correctly changed from Graph to AbstractGraph, consistent with the broader refactoring pattern across the codebase.

28-28: PartialGraph type properly updated to use AbstractGraph.

The PartialGraph type has been updated to reference AbstractGraph instead of Graph, maintaining the same picked properties. This change aligns with the dependency inversion principle by depending on abstractions rather than concrete implementations.

29-31: PartialConnections type updated to reference AbstractGraph.

The PartialConnections type definition has been updated to pick properties from AbstractGraph instead of Graph. This change is consistent with the refactoring pattern and maintains the same picked properties.

19-19: Import statement updated from Graph to AbstractGraph.

The import has been correctly changed from Graph to AbstractGraph, consistent with the broader refactoring pattern across the codebase.

21-22: PartialGraph and PartialTerminal types updated to use AbstractGraph.

Both type definitions have been updated to pick properties from AbstractGraph instead of Graph. This change follows the dependency inversion principle and maintains the same interface expectations.

56-56: Import statement updated to use AbstractGraph.

The import has been correctly changed from Graph to AbstractGraph, consistent with the broader refactoring pattern across the codebase.

81-81: Graph property type updated to AbstractGraph in EdgeHandler class.

The type of the graph property in the EdgeHandler class has been updated from Graph to AbstractGraph. This change allows the handler to work with any implementation that conforms to the AbstractGraph interface.

2251-2251: Constructor parameter type updated in EdgeHandlerCellMarker class.

The constructor parameter type has been changed from Graph to AbstractGraph in the EdgeHandlerCellMarker class, maintaining consistency with the rest of the changes in this file and across the codebase.

34-34: LGTM: Import updated from Graph to AbstractGraph

The import change looks good, correctly shifting from the concrete Graph type to the more abstract AbstractGraph type, which aligns with the PR's objective of making plugin loading more flexible.

54-56: LGTM: Documentation and type declaration updated correctly

The documentation and type declaration have been properly updated to reference AbstractGraph instead of the previous references to mxGraph and Graph.

88-88: LGTM: Constructor parameter type updated

The constructor parameter type has been correctly updated from Graph to AbstractGraph, maintaining consistency with the property type change.

28-28: LGTM: Import updated from Graph to AbstractGraph

The import statement has been correctly updated to use AbstractGraph type.

41-42: LGTM: Documentation updated correctly

The constructor documentation has been properly updated to reference AbstractGraph.

46-46: LGTM: Constructor parameter type updated

The constructor parameter type has been correctly updated from Graph to AbstractGraph.

24-24: LGTM: Import updated from Graph to AbstractGraph

The import statement has been correctly updated to use AbstractGraph type.

27-27: LGTM: Type parameters updated correctly

Both PartialGraph and PartialGrouping type parameters have been properly updated from Graph to AbstractGraph, maintaining type consistency throughout the mixin.

Also applies to: 52-52

23-23: LGTM: Import updated from Graph to AbstractGraph

The import statement has been correctly updated to use AbstractGraph type.

20-20: LGTM: Changed import from Graph to AbstractGraph

This change correctly updates the import to use the more abstract AbstractGraph type. This aligns with the broader refactoring effort to use a more generalized graph interface.

45-45: LGTM: Updated JSDoc parameter type

The JSDoc comment is properly updated to reflect the new AbstractGraph type, maintaining documentation consistency.

49-49: LGTM: Changed constructor parameter type

Constructor signature updated to accept the more abstract AbstractGraph type instead of Graph. This change enhances flexibility by allowing different implementations that conform to the AbstractGraph interface.

22-22: LGTM: Changed import from Graph to AbstractGraph

Import statement correctly updated to use the AbstractGraph type instead of Graph. This is consistent with the project-wide refactoring.

21-21: LGTM: Changed import from Graph to AbstractGraph

Import statement correctly updated to use the AbstractGraph type instead of Graph, consistent with the project-wide type refactoring.

23-25: LGTM: Updated PartialGraph type definition

The PartialGraph type definition is correctly updated to reference AbstractGraph instead of Graph. The set of picked properties remains the same, ensuring consistent behavior.

33-35: LGTM: Updated PartialOverlays type definition

The PartialOverlays type definition is correctly updated to reference AbstractGraph instead of Graph. The set of picked properties remains the same, ensuring consistent behavior.

20-20: LGTM: Changed import from Graph to AbstractGraph

Import statement correctly updated to use the AbstractGraph type instead of Graph, consistent with the project-wide type refactoring.

25-28: LGTM: Updated PartialGraph type definition

The PartialGraph type definition is correctly updated to reference AbstractGraph instead of Graph, while maintaining the same set of picked properties.

29-32: LGTM: Updated PartialTooltip type definition

The PartialTooltip type definition is correctly updated to reference AbstractGraph instead of Graph, while maintaining the same set of picked properties.

20-21: Type references updated to AbstractGraph

The references have been correctly updated from Graph to AbstractGraph, which aligns with the broader refactoring in this PR to make the code more abstract and enable efficient loading of plugins.

20-20: Import updated to use AbstractGraph

The import statement has been properly updated to reference the AbstractGraph type instead of Graph.

24-25: Type reference updated in PartialGraph

The PartialGraph type now correctly refers to AbstractGraph instead of Graph, maintaining consistency with the rest of the refactoring.

37-38: Type reference updated in PartialEditing

The PartialEditing type now correctly refers to AbstractGraph instead of Graph, completing the refactoring in this file.

20-20: Import updated to use AbstractGraph

The import statement has been correctly updated to reference the AbstractGraph type.

66-66: Constructor parameter type updated

The constructor parameter type has been updated from Graph to AbstractGraph, which is consistent with the PR's objective of abstracting graph implementations.

72-72: Class property type updated

The graph property type has been updated from Graph to AbstractGraph, maintaining type consistency with the constructor parameter.

27-27: Import updated to use AbstractGraph

The import statement has been correctly updated to reference the AbstractGraph type.

78-78: Constructor parameter type updated

The constructor parameter type has been updated from Graph to AbstractGraph, which is consistent with the broader refactoring effort.

20-20: Good architectural refactoring - switching to AbstractGraph

The changes to use AbstractGraph instead of Graph are part of a good architectural refactoring that follows the Dependency Inversion Principle. By depending on abstractions rather than concrete implementations, the code becomes more flexible and easier to maintain.

Also applies to: 24-25, 27-27

25-25: Good abstraction with AbstractGraph

The changes to use AbstractGraph instead of Graph in the constructor parameter improve the flexibility of the RadialTreeLayout class, allowing it to work with any implementation that satisfies the AbstractGraph interface.

Also applies to: 40-40

23-23: Consistent refactoring to AbstractGraph

The changes to use AbstractGraph are consistent with the broader refactoring effort. Good job updating both the type declarations and documentation comments to maintain consistency.

Also applies to: 30-30, 36-38

25-25: Consistent refactoring to AbstractGraph with improved formatting

The changes to use AbstractGraph are consistent with the broader refactoring effort. The improved formatting with parameters on separate lines enhances readability.

Also applies to: 51-51, 56-60, 136-136

35-35: Updated import to use AbstractGraph type.

The import has been changed to use the AbstractGraph type instead of the concrete Graph type. This aligns with the PR's objective of creating a more flexible architecture that can efficiently handle plugins.

65-65: Updated constructor parameter to use AbstractGraph.

The constructor now accepts the more abstract AbstractGraph type instead of the concrete Graph type. This change enables the PanningHandler to work with any implementation that conforms to the AbstractGraph interface.

126-126: Updated graph property type to AbstractGraph.

The graph property type has been changed to AbstractGraph, maintaining consistency with the constructor parameter change. This is a good practice to ensure type consistency throughout the class.

21-21: Updated import to use AbstractGraph type.

The import statement has been changed to use the AbstractGraph type, replacing the previous Graph type. This matches the refactoring pattern seen in other files and supports the PR's goal of creating a more flexible architecture.

40-40: Updated constructor parameter to use AbstractGraph.

The constructor's graph parameter now uses the AbstractGraph type instead of the concrete Graph type. This change allows StackLayout to work with any implementation that conforms to the AbstractGraph interface, increasing flexibility.

29-29: Updated import to use AbstractGraph type.

The import has been changed to use the AbstractGraph type instead of the concrete Graph type. This is consistent with the changes in other files and aligns with the more abstract approach to graph handling.

58-58: Updated graph property type to AbstractGraph.

The graph property type has been changed to AbstractGraph, which makes the VertexHandler compatible with any implementation that conforms to the AbstractGraph interface rather than requiring a specific Graph implementation.

32-32: Updated import to use AbstractGraph type.

The import statement has been changed to use the AbstractGraph type, replacing the previous Graph type import. This is consistent with the changes in other files and supports the more flexible architecture being implemented.

60-62: Updated graph property comment and type to AbstractGraph.

The property comment and type for the graph property have been updated to reference AbstractGraph instead of Graph. This change ensures proper documentation and type checking with the new abstract type.

92-92: Updated constructor parameter to use AbstractGraph.

The constructor now accepts an AbstractGraph parameter instead of the concrete Graph type. This allows the LayoutManager to be more flexible and work with any implementation that conforms to the AbstractGraph interface.

167-167: Updated setGraph method parameter type to AbstractGraph.

The setGraph method parameter type has been changed to AbstractGraph | null from Graph | null. This maintains consistency with the constructor and property type changes, ensuring type safety throughout the class.

21-21: LGTM: Updated import to use AbstractGraph type

The change to import the AbstractGraph type aligns with the PR's objective to improve abstraction in the codebase.

36-36: Updated constructor parameter type correctly

Changed from concrete Graph type to more abstract AbstractGraph type, maintaining the same functionality while allowing more flexible implementations.

50-52: Documentation and property type update

The reference and type for the graph property have been properly updated to AbstractGraph.

118-118: Method parameter type updated consistently

The setGraph method parameter type has been updated to match the new AbstractGraph type, maintaining consistency throughout the class.

32-32: LGTM: Updated import to use AbstractGraph type

The import has been correctly changed to reference the AbstractGraph type, consistent with the code refactoring strategy.

64-64: Property type updated correctly

The graph property type has been properly updated to AbstractGraph, aligning with the PR objectives.

122-122: Constructor parameter type updated

Changed from concrete Graph type to more abstract AbstractGraph type, consistent with other changes in the codebase.

60-61: Added new build step for TypeScript example with selected features

This new build step supports the PR objective of allowing efficient loading without default plugins.

68-69: Added new build step for JavaScript example with selected features

This build step complements the TypeScript example build, providing comprehensive testing of the new feature.

78-79: Improved artifact upload paths with wildcards

Using wildcards for js-example* and ts-example* paths simplifies the configuration and makes it more maintainable as new example directories are added.

20-20: LGTM: Updated import to use AbstractGraph type

The import has been correctly changed to reference the AbstractGraph type, consistent with the code refactoring strategy.

20-20: Import looks good.
No concerns here; switching from Graph to AbstractGraph improves consistency with the ongoing refactor.

97-99: Updated drop target type is consistent with the AbstractGraph refactor.
Ensuring it receives an AbstractGraph instead of Graph aligns with the broader usage shift.

23-23: Import statements align with the transition to AbstractGraph.
No issues here; this import is consistent with the broader refactoring.

33-33: JSDoc annotation matches the parameter change to AbstractGraph.
This accurately reflects the method's updated expectation.

40-40: Function signature updated to use AbstractGraph.
This enhances consistency across the codebase.

166-166: JSDoc param updated to AbstractGraph.
This documentation update ensures alignment with the actual function parameter type.

173-173: show function now accepts AbstractGraph.
This refactoring is in line with the move to a more generic graph interface.

282-284: printScreen function updated to accept AbstractGraph.
Promises improved flexibility and compatibility with different graph implementations.

2-2: Year updated to 2025.
No functional impact.

17-20: Refined imports for newly introduced types.
Importing GraphPluginConstructor, GraphView, and AbstractGraph aligns with the refactor.

Also applies to: 26-26

30-32: Updated class description clarifies usage.
Recommending “prototype-only” usage is clear for new consumers.

34-34: Class now extends AbstractGraph.
This is a key step in simplifying the code and providing more generic capabilities.

63-63: Override method aligns with new base class design.
Refactoring logic into registerDefaults keeps configuration consistent.

69-74: Collaborators initialization ensures consistent setup.
These lines consolidate and clarify instantiation logic, maintaining the correct default object creation.

82-82: Constructor refactored to rely on superclass parameters.
Leverages the new constructor signature in AbstractGraph.

22-22: Types updated to use AbstractGraph instead of Graph.

The import statement is updated to use the AbstractGraph type, which is part of a larger refactoring to make the codebase more modular by using abstract types rather than concrete implementations.

36-37: Constructor parameter type updated to AbstractGraph.

The constructor parameter type has been changed from Graph to AbstractGraph, making the component more flexible by allowing it to work with any implementation that satisfies the AbstractGraph interface.

63-65: JSDoc and property type updated to AbstractGraph.

Documentation and property type declaration are updated to reflect the change to the AbstractGraph type, maintaining consistency throughout the class.

172-172: Method parameter type updated to AbstractGraph.

The setGraph method parameter type has been updated to AbstractGraph | null to align with the other type changes in this class.

23-23: Import statement updated to use AbstractGraph.

The import has been updated to use the AbstractGraph type, consistent with the pattern seen across other files in this PR.

36-36: Constructor parameter type updated to AbstractGraph.

The constructor parameter type has been changed from Graph to AbstractGraph, continuing the consistent pattern of using more abstract types.

41-43: JSDoc and property type updated to AbstractGraph.

The documentation comment and property type declaration have been updated to reflect the change to AbstractGraph.

99-99: Method return type updated to AbstractGraph.

The return type of the getGraph method has been updated to AbstractGraph to maintain type consistency throughout the class.

27-27: Import statement updated to use AbstractGraph.

The import statement has been updated to use the AbstractGraph type instead of Graph, following the same pattern as other files in this PR.

150-150: Constructor parameter type updated to AbstractGraph.

The constructor parameter type has been updated from Graph to AbstractGraph, maintaining consistency with the architectural changes.

174-176: JSDoc and property type updated to AbstractGraph.

The documentation and property type have been consistently updated to use AbstractGraph instead of Graph.

313-314: Method parameter type updated to AbstractGraph.

The appendGraph method's parameter type has been updated to AbstractGraph, completing the type transition in this class.

24-24: Import statement updated to use Guide directly.

The import has been changed from mxGuide to Guide, likely as part of a broader effort to standardize class naming by removing the "mx" prefix.

43-43: Import AbstractGraph type.

Added import for the AbstractGraph type, consistent with changes in other files.

58-61: Improved JSDoc documentation.

The documentation has been enhanced to provide clearer explanation about how individual cells are handled within the selection process and the relationship with SelectionCellsHandler.

75-75: Constructor parameter type updated to AbstractGraph.

The constructor parameter type has been updated from Graph to AbstractGraph, consistent with the pattern in other files.

172-172: Property type updated to AbstractGraph.

The graph property type has been updated to AbstractGraph to maintain type consistency throughout the class.

730-731: Updated Guide instantiation.

The createGuide method now instantiates Guide instead of mxGuide, reflecting the import change on line 24 and maintaining consistency with the naming changes.

23-23: LGTM: Updated import to use AbstractGraph.

This change is part of the refactoring to use the more abstract graph interface, which aligns with the goal of allowing efficient loading of components.

40-40: Good update to use AbstractGraph interface.

Changing the graph parameter and property types from concrete Graph to AbstractGraph increases flexibility and modularity. This allows PopupMenuHandler to work with any graph implementation that adheres to the AbstractGraph interface.

Also applies to: 64-64

57-57: LGTM: Updated import to use AbstractGraph.

This import change is consistent with the overall refactoring to use the AbstractGraph interface.

220-220: Appropriate type change to use AbstractGraph.

Updating the graph property type to AbstractGraph allows for better abstraction and modularity in the codebase.

388-388: Good update to the constructor parameter type.

Using AbstractGraph instead of Graph for the constructor parameter aligns with the property type and follows the pattern of interface-based programming.

1991-1991: Consistent type update in ConnectionHandlerCellMarker.

The type change for the graph parameter in the nested class maintains consistency with the parent class changes.

20-20: LGTM: Updated import to use AbstractGraph.

This import change aligns with the refactoring pattern seen across the codebase.

126-126: Good update to static method signatures.

All static methods now accept AbstractGraph instead of Graph, making the Clipboard utility more flexible and able to work with different graph implementations. This is consistent with the goal of allowing more efficient component loading.

Also applies to: 140-140, 152-152, 167-167

30-31: LGTM: Updated imports for AbstractGraph and BaseGraph.

These imports support the refactoring to use more abstract interfaces and provide the concrete implementation needed in this file.

82-82: Good update to use AbstractGraph for class properties and parameters.

Changing the types of source, outline properties, and constructor parameter to AbstractGraph allows for more flexibility in the graph implementations that can be used with Outline.

Also applies to: 236-236, 241-241

320-325: Good refactoring of createGraph method.

The method now returns AbstractGraph and delegates the actual creation to createGraphInstance, which allows for better extensibility.

327-338: Well-structured implementation of createGraphInstance.

This new protected method enables customization of the graph instance creation without requiring plugins, aligning with the PR objective to efficiently not load default plugins. The comments provide good explanation of the rationale and potential extension points.

The BaseGraph instantiation with minimal configuration is appropriate for an outline view that doesn't need all the features of a full graph.

476-481: Confirm necessity of registerDefaults
This method is currently empty and only shows a TODO comment. If the intention is to prevent auto-loading of defaults, consider removing it altogether or adding relevant logic with an explanatory comment.

247-264: Verify boundary conditions in fit method
When the container is very small or has unusual scroll behaviors, the logic in fit could lead to unexpected scaling. Verify that extreme cases (e.g., zero-size container, forcibly large scale) are handled gracefully.

583-649: Validate runtime checks when transferring events to graph
The dragOver method attempts to compute a valid drop coordinate and highlight targets, but concurrency with rapidly changing container layouts or scroll offsets can cause off-by-few-pixels mismatches. Ensure edge cases (like container resizing while dragging) are handled.

135-178: Ensure error messages are localized
You're using translate(...) for the errors in countError and typeError. Confirm that all relevant user-facing strings are similarly translated and that fallback strings do not conflict with the new workflow.

31-31: Good addition of the AbstractGraph type import.

The import statement correctly uses TypeScript's type import, which ensures this is only used for type checking and will not affect runtime behavior.

667-667: LGTM: Parameter type refactoring from Graph to AbstractGraph

This change is part of a broader refactoring effort to use the more abstract AbstractGraph type instead of the concrete Graph implementation. This follows the Dependency Inversion Principle (part of SOLID), making the code more flexible and enhancing extensibility.

Also applies to: 694-694, 762-762, 863-863, 1033-1033