docs
evals
scenario-1
scenario-10
scenario-2
scenario-3
scenario-4
scenario-5
scenario-6
scenario-7
scenario-8
scenario-9
{
"context": "Evaluates how well the solution leverages the punycode package to convert domain names and email addresses into ASCII-safe form. Checks focus on correct use of punycode’s toASCII API for domains, emails, separator handling, and idempotent ASCII passthrough.",
"type": "weighted_checklist",
"checklist": [
{
"name": "Import punycode",
"description": "Imports the npm package via the userland path (e.g., require('punycode/') or equivalent) rather than reimplementing the conversion.",
"max_score": 20
},
{
"name": "Domain conversion",
"description": "Uses punycode.toASCII to convert Unicode domain labels to ASCII Punycode, avoiding manual encoding logic.",
"max_score": 20
},
{
"name": "Email domain handling",
"description": "Extracts only the domain portion after '@' and applies punycode.toASCII there, leaving the local part untouched.",
"max_score": 20
},
{
"name": "Separator normalization",
"description": "Relies on punycode.toASCII to normalize legacy IDNA separators (., 。, ., 。) before conversion instead of custom parsing.",
"max_score": 20
},
{
"name": "Idempotent ASCII passthrough",
"description": "Uses punycode.toASCII in a way that preserves already-ASCII or already-Punycode inputs without double-encoding or alteration.",
"max_score": 20
}
]
}