[Investigation] Linter on save: UX and API design

[andrewtelnov]

Overview

This is a design/investigation task, not an implementation task. Output is a UX + API proposal, prepared jointly by a developer and our designer, to be reviewed before any implementation issue is created.

Goal: optionally run the linter as part of the Creator save flow, so a survey with logic problems is caught at the moment it is persisted, for users who never open the JSON tab.

Questions to answer

UX

1. How and where are linter issues shown when the user saves? Options to evaluate: a popup/dialog, a notification bar with a link to the issue list, a dedicated panel. If a popup, what does it contain (full issue list vs. summary + link)?
2. Should the issue list be shown at all by default, or only a summary with an action to open details?
3. What does the user see when the save proceeds with warnings vs. when the integration cancels it (see API below)? The two states must be visually distinct.
4. How does this interact with auto-save (isAutoSave)? Showing a popup on every auto-save is not acceptable; propose the behavior for both manual and auto save.

API
5. How does a developer control whether the save proceeds? Proposed direction to evaluate: an event (e.g. onSurveySaving or an extension of the existing save flow) that receives the linter result and exposes allow/cancel, sync and async.
6. How does a developer opt out of linting on save entirely, or restrict it to selected rules/severities?
7. How does the host application receive the linter result on save (for its own UI or logging), independent of what Creator shows?
8. Default behavior when the developer configures nothing: proposal + rationale. (Working assumption from prior discussion: save is never blocked by default; linter issues warn, only an explicit developer decision can cancel a save.)

Deliverables

• Mockups for the chosen presentation (manual save and auto-save cases), reviewed by the designer.
• API sketch: properties, events, and their default values.
• Note on performance: expected linter cost in the save path for large surveys and whether the run must be async/cancelable.
• Short written recommendation; review meeting scheduled before implementation issues are filed.