Error responses follow one structure

When auth errors return { message: '...' }, validation errors return { errors: [...] }, and not-found errors return raw strings, consumers must write a different parser for each error type. This is not just inconvenient — it makes automated error handling (retry logic, error monitoring, user-facing messages) impossible to build generically. iso-25010:2011 compatibility.interoperability and maintainability.modifiability both require a stable, machine-readable error contract. Inconsistent errors are also a debugging liability: different shapes in different production logs make tracing failures significantly harder.

Define one error structure and use it for every error response across every endpoint. Create a helper to enforce it:

interface ApiError {
  error: {
    code: string        // machine-readable: "NOT_FOUND", "VALIDATION_ERROR"
    message: string     // human-readable description
    details?: unknown   // field-level detail for validation errors
  }
}

function apiError(code: string, message: string, status: number, details?: unknown) {
  return Response.json({ error: { code, message, details } }, { status })
}

// In every handler:
return apiError('NOT_FOUND', 'User not found', 404)
return apiError('VALIDATION_ERROR', 'Invalid request', 400, zodError.issues)
return apiError('INTERNAL_ERROR', 'Something went wrong', 500)

The code field is the key — it lets consumers branch on machine-readable values rather than parsing human-readable strings. See the status-codes check for HTTP code consistency.