Spike: Node-edit interaction & UX (design)

[lornakelly]

Description

Design how node editing looks and behaves.

Two central questions:

1. Save model - does the user click a field, edit, and click away (blur) to commit, or is there an explicit Save button? Plus dirty / unsaved state, discard, and per-field vs whole-node editing
2. Validation model - when do we validate (live as-you-type, on blur, or only on save) and who validates: SDK-only (reuse the existing validateWorkflow / produced errors after the edit is written back and re-parsed - simple, one source of truth, but feedback lags a full round-trip) vs some validation in the editor

Investigate, comment on ticket and discuss with team

Motivation

The save + validation models shape the whole feel of editing and have real trade-offs. Blur-to-save is fast but risks accidental commits; an explicit Save is clearer but heavier. SDK-only validation keeps one source of truth but only reacts after a round-trip (so a structural edit is rejected late); in-editor pre-checks catch bad edits earlier but add a second validation surface to keep in sync. These need deciding before implementation so the feature is built once.

Proposed Implementation

No response

Definition of Done

• Implementation: Fully implemented according to the Serverless Workflow spec.
• Unit Tests: Comprehensive unit tests are included and passing.
• Integration Tests: Verified within the monorepo and target environments (Web/VS Code).
• Documentation: Updated README.md, ADRs, or official docs.
• Performance: No significant regression in editor responsiveness.
• Accessibility: UI changes comply with accessibility standards.