Background
targetConstraint severity is now correctly stored on OperationOutcome issues and responseHasErrors already distinguishes error/fatal from warning. The severity is available — but the UI doesn't use it. All validation feedback currently renders with the same error styling regardless of whether the underlying issue is an error or a warning.
Problem
A targetConstraint with severityCode: 'warning' surfaces feedback identically to one with severityCode: 'error'. Users have no visual cue that some issues are advisory rather than blocking.
Proposed fix
Add a new useValidationFeedbackSeverity(linkId) hook returning { feedback: string; feedbackSeverity: 'error' | 'warning' } | null. Field components that need severity-aware styling (~19 *Field.tsx files) are updated to call this instead.
useValidationFeedback is kept as a thin wrapper around useValidationFeedbackSeverity (no duplicated store logic) and marked @deprecated for removal in the next major release.
Notes
- Cosmetic only — does not affect save-gate behaviour
- No breaking change
Background
targetConstraintseverity is now correctly stored on OperationOutcome issues andresponseHasErrorsalready distinguisheserror/fatalfromwarning. The severity is available — but the UI doesn't use it. All validation feedback currently renders with the same error styling regardless of whether the underlying issue is an error or a warning.Problem
A
targetConstraintwithseverityCode: 'warning'surfaces feedback identically to one withseverityCode: 'error'. Users have no visual cue that some issues are advisory rather than blocking.Proposed fix
Add a new
useValidationFeedbackSeverity(linkId)hook returning{ feedback: string; feedbackSeverity: 'error' | 'warning' } | null. Field components that need severity-aware styling (~19*Field.tsxfiles) are updated to call this instead.useValidationFeedbackis kept as a thin wrapper arounduseValidationFeedbackSeverity(no duplicated store logic) and marked@deprecatedfor removal in the next major release.Notes