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 turn a single Unicode domain label into its ASCII Punycode form while preserving ASCII-only input and surfacing dependency errors. Scoring prioritizes direct use of the library API and correctness of the encoded outputs called out in the spec.",
"type": "weighted_checklist",
"checklist": [
{
"name": "punycode usage",
"description": "Imports and calls `punycode.encode` on the provided label instead of reimplementing the encoding algorithm or using unrelated APIs, ensuring the dependency performs the conversion.",
"max_score": 35
},
{
"name": "mañana result",
"description": "Encoding the label \"mañana\" returns exactly \"maana-pta\" as produced by `punycode.encode`.",
"max_score": 20
},
{
"name": "bücher result",
"description": "Encoding the label \"bücher\" returns exactly \"bcher-kva\" as produced by `punycode.encode`.",
"max_score": 20
},
{
"name": "ASCII passthrough",
"description": "An ASCII-only label such as \"example\" is returned unchanged, matching `punycode.encode` behavior without extra modifications.",
"max_score": 15
},
{
"name": "RangeError propagation",
"description": "Any RangeError raised by `punycode.encode` for invalid or overflowing input is allowed to surface (or is rethrown unchanged) instead of being swallowed or replaced with a different error type.",
"max_score": 10
}
]
}