This is a comment left during a code review.
Path: apps/sim/app/workspace/[workspaceId]/w/components/sidebar/components/workflow-list/components/workflow-item/workflow-item.tsx
Line: 84:94

Comment:
The refactored hooks are being renamed but not passed the required arguments, breaking duplicate and export functionality.

**The Bug:**
- Line 81: `useDuplicateWorkflow` returns `handleDuplicateWorkflow` but it's renamed to `duplicateWorkflow`
- Line 83: `useExportWorkflow` returns `handleExportWorkflow` but it's renamed to `exportWorkflow`
- Lines 84-94: New wrapper functions `handleDuplicateWorkflow` and `handleExportWorkflow` are created
- **CRITICAL**: These wrappers call `duplicateWorkflow(workflowIds)` and `exportWorkflow(workflowIds)`, BUT the hooks now require `workflowIds` as parameters (not getter functions), so the hooks receive NO workflow IDs

**Impact:**
When users try to duplicate or export workflows, the operations will silently fail because `workflowIds` prop passed to the hooks is `undefined`.

**The Fix:**
Remove the renaming and pass workflowIds directly when calling the hook functions:

```suggestion
  const { handleDuplicateWorkflow } = useDuplicateWorkflow({ workspaceId })

  const { handleExportWorkflow } = useExportWorkflow({ workspaceId })

  const handleDuplicateWorkflowClick = useCallback(() => {
    const workflowIds = capturedSelectionRef.current?.workflowIds || []
    if (workflowIds.length === 0) return
    handleDuplicateWorkflow(workflowIds)
  }, [handleDuplicateWorkflow])

  const handleExportWorkflowClick = useCallback(() => {
    const workflowIds = capturedSelectionRef.current?.workflowIds || []
    if (workflowIds.length === 0) return
    handleExportWorkflow(workflowIds)
  }, [handleExportWorkflow])
```

Then update the ContextMenu calls (lines 359-360) to use the new names.

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: apps/sim/app/workspace/[workspaceId]/w/hooks/use-export-workflow.ts
Line: 145:157

Comment:
Filename collision handling logic has a subtle bug that could lead to duplicate filenames in the ZIP archive.

**The Issue:**
The collision detection uses `seenFilenames.has(filename.toLowerCase())` (line 151) but adds the filename in its original case to the set (line 155). This creates an inconsistency where:
1. The check uses lowercase comparison
2. The storage uses original case
3. On the next iteration, if two workflows have names that differ only in case (e.g., "MyWorkflow" and "myworkflow"), the second one won't be detected as a collision

**Example Failure Case:**
```
Workflow 1: "Test"     → filename = "Test.json"     → stored as "Test.json"
Workflow 2: "TEST"     → filename = "TEST.json"     → check "test.json", doesn't find "Test.json" in set
```
Result: ZIP contains both "Test.json" and "TEST.json", which could fail on case-insensitive filesystems.

**The Fix:**
Store lowercase filenames in the set to match the comparison logic:

```suggestion
          for (const exportedWorkflow of exportedWorkflows) {
            const baseName = exportedWorkflow.name.replace(/[^a-z0-9]/gi, '-')
            let filename = `${baseName}.json`
            let counter = 1
            while (seenFilenames.has(filename.toLowerCase())) {
              filename = `${baseName}-${counter}.json`
              counter++
            }
            seenFilenames.add(filename.toLowerCase())
            zip.file(filename, exportedWorkflow.content)
          }
```

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: apps/sim/app/workspace/[workspaceId]/w/hooks/use-export-folder.ts
Line: 198:208

Comment:
Same filename collision bug exists here - the set stores original case but checks lowercase, leading to potential duplicates.

This is identical to the issue in `use-export-workflow.ts`. When multiple workflows in a folder have names that differ only in case, the collision detection fails.

```suggestion
      for (const exportedWorkflow of exportedWorkflows) {
        const baseName = exportedWorkflow.name.replace(/[^a-z0-9]/gi, '-')
        let filename = `${baseName}.json`
        let counter = 1
        while (seenFilenames.has(filename.toLowerCase())) {
          filename = `${baseName}-${counter}.json`
          counter++
        }
        seenFilenames.add(filename.toLowerCase())
        zip.file(filename, exportedWorkflow.content)
      }
```

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: apps/sim/app/workspace/[workspaceId]/w/hooks/use-export-workflow.ts
Line: 91:95

Comment:
The workflow API response check doesn't validate the response data structure, potentially causing silent failures.

**The Issue:**
After checking `workflowResponse.ok`, the code assumes the JSON will have a `data` property with a `state` property. However, if the API returns a successful response (200) with an unexpected structure (e.g., `{ error: "..." }` or malformed data), line 98's check `if (!workflowData?.state)` will catch it but only log a warning and continue to the next workflow.

**Potential Problem:**
- User exports multiple workflows
- One workflow has corrupted data or API returns unexpected format
- Export silently skips that workflow
- User doesn't know which workflows were actually exported

**Recommendation:**
Consider accumulating errors and reporting them to the user, similar to how import operations typically work. At minimum, the `onSuccess` callback should receive information about partial failures:

```typescript
// Track both successes and failures
const results = {
  exported: exportedWorkflows.map(w => w.name),
  failed: [] as string[]
}

// In the catch block:
results.failed.push(workflow.name)

// After the loop, inform user of partial success
if (results.failed.length > 0) {
  logger.warn(`${results.failed.length} workflows failed to export`, results.failed)
}
```

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: apps/sim/stores/workflows/registry/store.ts
Line: 100:120

Comment:
The hydration preservation logic has improved but could still incorrectly preserve state in one edge case.

**What Changed:**
The code now preserves hydration when:
1. Currently in 'state-loading' phase, OR
2. In 'ready' phase AND the workflow still exists in the new metadata

**The Edge Case:**
If a workflow is deleted from another tab/session while the current tab has that workflow open and in 'ready' state, the condition on line 105 `mapped[state.hydration.workflowId]` will be `undefined` (falsy), so hydration will be reset. This is actually **correct behavior** - we want to reset hydration when the workflow no longer exists.

However, there's still a potential race condition:
- Tab A: User opens workflow W1 (hydration.phase = 'ready', workflowId = W1)
- Tab B: User deletes workflow W1
- Tab A: `syncMetadata` is called, W1 is gone from metadata
- Tab A: Hydration is correctly reset to 'metadata-ready'
- **BUT**: The UI might still be showing W1's content because the workflow state in memory hasn't been cleared yet

**Recommendation:**
Consider adding a check to detect when the currently loaded workflow has been deleted and handle it gracefully (e.g., navigate away, show "Workflow no longer exists" message). This is more of an architecture consideration than a bug in this specific change.

<sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub>

How can I resolve this? If you propose a fix, please make it concise.