style: reformat codebase with oxfmt

docs/adr/0001-merge-litegraph-into-frontend.md

@@ -11,11 +11,13 @@ Accepted
 ComfyUI's frontend architecture currently depends on a forked version of litegraph.js maintained as a separate package (@comfyorg/litegraph). This separation has created several architectural and operational challenges:
 
 **Architectural Issues:**
+
 - The current split creates a distributed monolith where both packages handle rendering, user interactions, and data models without clear separation of responsibilities
 - Both frontend and litegraph manipulate the same data structures, forcing tight coupling across the frontend's data model, views, and business logic
 - The lack of clear boundaries prevents implementation of modern architectural patterns like MVC or event-sourcing
 
 **Operational Issues:**
+
 - ComfyUI is the only known user of the @comfyorg/litegraph fork
 - Managing separate repositories significantly slows developer velocity due to coordination overhead
 - Version mismatches between frontend and litegraph cause recurring issues
@@ -23,6 +25,7 @@ ComfyUI's frontend architecture currently depends on a forked version of litegra
 
 **Future Requirements:**
 The following planned features are blocked by the current architecture:
+
 - Multiplayer collaboration requiring CRDT-based state management
 - Cloud-based backend support
 - Alternative rendering backends
@@ -34,6 +37,7 @@ The following planned features are blocked by the current architecture:
 We will merge litegraph.js directly into the ComfyUI frontend repository using git subtree to preserve the complete commit history.
 
 The merge will:
+
 1. Move litegraph source to `src/lib/litegraph/`
 2. Update all import paths from `@comfyorg/litegraph` to `@/lib/litegraph`
 3. Remove the npm dependency on `@comfyorg/litegraph`
@@ -62,4 +66,4 @@ This integration is the first step toward restructuring the application along cl
 
 - Git subtree was chosen over submodules to provide a cleaner developer experience
 - The original litegraph repository will be archived after the merge
-- Future litegraph improvements will be made directly in the frontend repository
+- Future litegraph improvements will be made directly in the frontend repository

docs/adr/0002-monorepo-conversion.md

@@ -13,7 +13,7 @@ Proposed
 [Most of the context is in here](https://github.com/Comfy-Org/ComfyUI_frontend/issues/4661)
 
 TL;DR: As we're merging more subprojects like litegraph, devtools, and soon a fork of PrimeVue,
- a monorepo structure will help a lot with code sharing and organization.
+a monorepo structure will help a lot with code sharing and organization.
 
 For more information on Monorepos, check out [monorepo.tools](https://monorepo.tools/)
 
@@ -37,7 +37,7 @@ There's a [whole list here](https://monorepo.tools/#tools-review) if you're inte
 
 - Adding new projects with shared dependencies becomes really easy
 - Makes the process of forking and customizing projects more structured, if not strictly easier
-- It *could* speed up the build and development process (not guaranteed)
+- It _could_ speed up the build and development process (not guaranteed)
 - It would let us cleanly organize and release packages like `comfyui-frontend-types`
 
 ### Negative
@@ -47,4 +47,4 @@ There's a [whole list here](https://monorepo.tools/#tools-review) if you're inte
 
 <!-- ## Notes
 
-Optional section for additional information, references, or clarifications. -->
+Optional section for additional information, references, or clarifications. -->

docs/adr/0003-crdt-based-layout-system.md

@@ -24,7 +24,7 @@ The existing system allows each node to directly mutate its position within Lite
 
 5. **Inefficient Change Detection**: While LiteGraph provides some events, many operations require polling via changeTracker.ts. The current undo/redo system performs expensive diffs on every interaction rather than using reactive push/pull signals, creating performance bottlenecks and blocking efficient animations and viewport culling.
 
-   This represents a fundamental architectural limitation: diff-based systems scale O(n) with graph complexity (traverse entire structure to detect changes), while signal-based reactive systems scale O(1) with actual changes (data mutations automatically notify subscribers). Modern frameworks (Vue 3, Angular signals, SolidJS) have moved to reactive approaches for precisely this performance reason. 
+   This represents a fundamental architectural limitation: diff-based systems scale O(n) with graph complexity (traverse entire structure to detect changes), while signal-based reactive systems scale O(1) with actual changes (data mutations automatically notify subscribers). Modern frameworks (Vue 3, Angular signals, SolidJS) have moved to reactive approaches for precisely this performance reason.
 
 ### Business Context
 
@@ -53,12 +53,14 @@ This provides single source of truth, predictable state updates, and natural sys
 ### Core Architecture
 
 1. **Centralized Layout Store**: A Yjs CRDT maintains all spatial data in a single authoritative store:
+
    ```typescript
    // Instead of: node.position = {x, y}
-   layoutStore.moveNode(nodeId, {x, y})
+   layoutStore.moveNode(nodeId, { x, y })
    ```
 
 2. **Command Pattern**: All spatial mutations flow through explicit commands:
+
    ```
    User Input → Commands → Layout Store → Observer Notifications → Renderers
    ```
@@ -74,12 +76,14 @@ This provides single source of truth, predictable state updates, and natural sys
 ### Implementation Strategy
 
 **Phase 1: Parallel System**
+
 - Build CRDT layout store alongside existing system
 - Layout store initially mirrors LiteGraph changes via observers
 - Gradually migrate user interactions to use command interface
 - Maintain full backward compatibility
 
 **Phase 2: Inversion of Control**
+
 - CRDT store becomes single source of truth
 - LiteGraph receives position updates via reactive subscriptions
 - Enable alternative renderers and advanced features
@@ -89,17 +93,20 @@ This provides single source of truth, predictable state updates, and natural sys
 This combination provides both architectural and technical benefits:
 
 **Centralized State Benefits:**
+
 - **Single Source of Truth**: All layout data managed in one place, eliminating conflicts
 - **System Decoupling**: Rendering, interaction, and layout systems operate independently
 - **Predictable Updates**: Clear data flow makes debugging and testing easier
 - **Extensibility**: Easy to add new layout behaviors without modifying existing systems
 
 **CRDT Benefits:**
+
 - **Conflict Resolution**: Automatic merging eliminates position conflicts between systems
 - **Collaboration-Ready**: Built-in support for multi-user editing
 - **Eventual Consistency**: Guaranteed convergence to same state across all clients
 
 **Yjs-Specific Benefits:**
+
 - **Event-Driven**: Native observer pattern removes need for polling
 - **Selective Updates**: Only changed nodes trigger system updates
 - **Fine-Grained Changes**: Efficient delta synchronization
@@ -109,7 +116,7 @@ This combination provides both architectural and technical benefits:
 ### Positive
 
 - **Eliminates Polling**: Observer pattern removes O(n) graph traversals, improving performance
-- **System Modularity**: Independent systems can be developed, tested, and optimized separately  
+- **System Modularity**: Independent systems can be developed, tested, and optimized separately
 - **Renderer Flexibility**: Easy to add WebGL, DOM accessibility, or hybrid rendering systems
 - **Rich Interactions**: Command pattern enables robust undo/redo, macros, and interaction history
 - **Collaboration-Ready**: CRDT foundation enables real-time multi-user editing
@@ -140,9 +147,10 @@ This centralized state + CRDT architecture follows patterns from modern collabor
 **CRDT in Collaboration**: Tools like Figma, Linear, and Notion use similar approaches for real-time collaboration, demonstrating the effectiveness of separating authoritative data from presentation logic.
 
 **Future Capabilities**: This foundation enables advanced features that would be difficult with the current architecture:
+
 - Macro recording and workflow automation
 - Programmatic layout optimization and constraints
-- API-driven workflow construction  
+- API-driven workflow construction
 - Multiple simultaneous renderers (canvas + accessibility DOM)
 - Real-time collaborative editing
 - Advanced spatial features (physics, animations, auto-layout)

docs/adr/0004-fork-primevue-ui-library.md

@@ -11,22 +11,27 @@ Rejected
 ComfyUI's frontend requires modifications to PrimeVue components that cannot be achieved through the library's customization APIs. Two specific technical incompatibilities have been identified with the transform-based canvas architecture:
 
 **Screen Coordinate Hit-Testing Conflicts:**
+
 - PrimeVue components use `getBoundingClientRect()` for screen coordinate calculations that don't account for CSS transforms
 - The Slider component directly uses raw `pageX/pageY` coordinates ([lines 102-103](https://github.com/primefaces/primevue/blob/master/packages/primevue/src/slider/Slider.vue#L102-L103)) without transform-aware positioning
 - This breaks interaction in transformed coordinate spaces where screen coordinates don't match logical element positions
 
 **Virtual Canvas Scroll Interference:**
+
 - LiteGraph's infinite canvas uses scroll coordinates semantically for graph navigation via the `DragAndScale` coordinate system
 - PrimeVue overlay components automatically trigger `scrollIntoView` behavior which interferes with this virtual positioning
 - This issue is documented in [PrimeVue discussion #4270](https://github.com/orgs/primefaces/discussions/4270) where the feature request was made to disable this behavior
 
 **Historical Overlay Issues:**
+
 - Previous z-index positioning conflicts required manual workarounds (commit `6d4eafb0`) where PrimeVue Dialog components needed `autoZIndex: false` and custom mask styling, later resolved by removing PrimeVue's automatic z-index management entirely
 
 **Minimal Update Overhead:**
+
 - Analysis of git history shows only 2 PrimeVue version updates in 2+ years, indicating that upstream sync overhead is negligible for this project
 
 **Future Interaction System Requirements:**
+
 - The ongoing canvas architecture evolution will require more granular control over component interaction and event handling as the transform-based system matures
 - Predictable need for additional component modifications beyond current identified issues
 

docs/adr/README.md

@@ -8,13 +8,13 @@ An Architecture Decision Record captures an important architectural decision mad
 
 ## ADR Index
 
-| ADR | Title | Status | Date |
-|-----|-------|--------|------|
-| [0001](0001-merge-litegraph-into-frontend.md) | Merge LiteGraph.js into ComfyUI Frontend | Accepted | 2025-08-05 |
-| [0002](0002-monorepo-conversion.md) | Restructure as a Monorepo | Accepted | 2025-08-25 |
-| [0003](0003-crdt-based-layout-system.md) | Centralized Layout Management with CRDT | Proposed | 2025-08-27 |
-| [0004](0004-fork-primevue-ui-library.md) | Fork PrimeVue UI Library | Rejected | 2025-08-27 |
-| [0005](0005-remove-importmap-for-vue-extensions.md) | Remove Import Map for Vue Extensions | Accepted | 2025-12-13 |
+| ADR                                                 | Title                                    | Status   | Date       |
+| --------------------------------------------------- | ---------------------------------------- | -------- | ---------- |
+| [0001](0001-merge-litegraph-into-frontend.md)       | Merge LiteGraph.js into ComfyUI Frontend | Accepted | 2025-08-05 |
+| [0002](0002-monorepo-conversion.md)                 | Restructure as a Monorepo                | Accepted | 2025-08-25 |
+| [0003](0003-crdt-based-layout-system.md)            | Centralized Layout Management with CRDT  | Proposed | 2025-08-27 |
+| [0004](0004-fork-primevue-ui-library.md)            | Fork PrimeVue UI Library                 | Rejected | 2025-08-27 |
+| [0005](0005-remove-importmap-for-vue-extensions.md) | Remove Import Map for Vue Extensions     | Accepted | 2025-12-13 |
 
 ## Creating a New ADR