Proactive error handling for React and vanilla JS frontends — every data-fetching component gets loading, error, and empty states, error boundaries, fetch error handling, form validation, optimistic rollback
90
84%
Does it follow best practices?
Impact
100%
1.38xAverage score across 5 eval scenarios
Passed
No known issues
{
"context": "Tests whether the agent proactively adds comprehensive error handling to a settings form that both loads and saves data, without being told to. The task says nothing about loading states, error states, validation, or submission error handling -- the agent should apply these patterns on its own.",
"type": "weighted_checklist",
"checklist": [
{
"name": "Loading state while fetching settings",
"description": "The component shows a loading indicator while the current settings are being fetched from the API, not a blank or partially rendered form.",
"max_score": 12
},
{
"name": "Fetch error state with retry",
"description": "When the initial settings fetch fails, the component shows an error message with a retry button, rather than rendering an empty or broken form.",
"max_score": 14
},
{
"name": "Submitting/saving state shown",
"description": "While the PATCH request is in flight, the component shows a saving/submitting indicator (disabled button, spinner, 'Saving...' text) to prevent double-submission and give feedback.",
"max_score": 14
},
{
"name": "Submission error handling",
"description": "The form submission is wrapped in try/catch and displays an error message to the user when the PATCH request fails.",
"max_score": 16
},
{
"name": "Client-side validation",
"description": "The form validates required fields (at minimum display name and email) on the client side before attempting the API call, showing inline error messages.",
"max_score": 10
},
{
"name": "Error messages use role=alert",
"description": "Error messages (both fetch errors and submission errors) use role=\"alert\" for screen reader accessibility.",
"max_score": 10
},
{
"name": "Fetch handles HTTP errors",
"description": "The code checks res.ok or res.status and handles non-2xx HTTP responses as errors rather than silently proceeding.",
"max_score": 12
},
{
"name": "User-friendly error messages",
"description": "All error messages shown to the user are human-readable strings, not raw Error objects or stack traces.",
"max_score": 8
},
{
"name": "Error boundary present",
"description": "The app includes a React error boundary that catches render-time errors.",
"max_score": 4
}
]
}evals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
skills
frontend-error-handling
verifiers