Follow-up from PR #338 review round 6 (recorded limitation there).
WorkflowEditor guards rail clicks and create-flow with a discard confirm when the doc is dirty, but a project switch resets the editor (useEffect on project → reducer reset) with no confirm — navigation is owned by the shell (App.tsx breadcrumb switcher), which doesn't know the Workflow screen holds unsaved HCL edits. The unsaved chip is the only signal.
Sketch: the shell needs a navigation guard seam (e.g. a useBlocker-style callback screens can register while dirty), or WorkflowEditor persists a draft per project and restores it. Either way it should cover the other dirty-state screens too (Docs editor has the same shape, mitigated by its save-on-blur).
Severity: low-probability data loss (switch projects mid-edit), but the flow editor now holds real unsaved work, unlike the cosmetic AppConfig blocks it replaced.
🤖 Generated with Claude Code
Follow-up from PR #338 review round 6 (recorded limitation there).
WorkflowEditorguards rail clicks and create-flow with a discard confirm when the doc is dirty, but a project switch resets the editor (useEffectonproject→ reducerreset) with no confirm — navigation is owned by the shell (App.tsxbreadcrumb switcher), which doesn't know the Workflow screen holds unsaved HCL edits. Theunsavedchip is the only signal.Sketch: the shell needs a navigation guard seam (e.g. a
useBlocker-style callback screens can register while dirty), or WorkflowEditor persists a draft per project and restores it. Either way it should cover the other dirty-state screens too (Docs editor has the same shape, mitigated by its save-on-blur).Severity: low-probability data loss (switch projects mid-edit), but the flow editor now holds real unsaved work, unlike the cosmetic AppConfig blocks it replaced.
🤖 Generated with Claude Code