feat(packaging): add DOMjudge problem packager

[rsalesc]

Summary

Adds rbx package domjudge, building a DOMjudge-importable problem zip. The layout follows the ICPC problem package format plus DOMjudge extensions, mirroring what pol2dom produces (known to import cleanly):

domjudge-problem.ini      # short-name, name, exact fractional timelimit, contest color
problem.yaml              # limits {memory, output}, validation[, validator_flags]
problem.pdf               # the already-built main statement PDF
data/sample/, data/secret # 001.in/001.ans per-directory counters
output_validators/        # custom checker (flattened) + patched testlib.h + rbx.h
submissions/              # jury solutions by expected outcome

Design doc: docs/plans/2026-06-12-domjudge-packager-design.md.

Key decisions

• Checker mapping: checkers resolving to the bundled builtins map to DOMjudge's default output validator (wcmp/ncmp/yesno → no flags, dcmp → float_tolerance 1e-6). Anything else — including a same-named local file, which may have been user-edited — ships as a custom validator, flattened via flattening.build_flat_namespace (cross-dir includes rewritten).
• testlib patch (domjudge/testlib_patch.py): DOMjudge validators speak the Kattis protocol (exit 42/43, team output on stdin, feedback dir), which vanilla testlib doesn't. Ports pol2dom's patch (from cn-xcpc-tools/testlib-for-domjudge), applied to the bundled testlib at package time; raises if an anchor is missing so a testlib upgrade fails tests, not packages. Verified locally: patched wcmp compiles and exits 42/43 with judgemessage.txt under the DOMjudge calling convention.
• Solutions: ACCEPTED→accepted, WA→wrong_answer, TLE→time_limit_exceeded, RTE/MLE→run_time_error (DOMjudge reports MLE as RTE); ambiguous outcomes skipped with a console note.
• Limits: uses the domjudge limits profile when saved, else package limits (not required, unlike BOCA — DOMjudge has a single per-problem TL).
• Scope: BATCH only; rbx COMMUNICATION pairs interactor+checker, which doesn't map onto DOMjudge's single output validator (follow-up). Build only — no upload.

Testing

• 12 new tests in tests/rbx/box/packaging/test_domjudge.py (testlib patch against bundled testlib, ini/yaml content, builtin-vs-custom checker resolution, flattening, submissions mapping, sample/secret routing, full package() smoke).
• tests/rbx/box/packaging + tests/rbx/box/completion: 1139 passed (3 docker-compose BOCA e2e errors are pre-existing local-env failures).
• Completion spec regenerated (mise run gen-completion-spec); drift test green.
• Docs: new docs/setters/packaging/domjudge.md + index table row + mkdocs nav.

🤖 Generated with Claude Code

[rsalesc]

please let's not resort to domjudge default output validators. let's always honor the rbx checker.

[rsalesc]

Done in 087f800. Dropped the default-validator mapping entirely — the rbx checker is now always shipped as a custom output validator (validation: custom), so DOMjudge judges with exactly the checker rbx uses locally. This applies to the builtins (wcmp, ncmp, …) too. Verified locally that a builtin checker compiles and exits 42/43 under the DOMjudge calling convention after the testlib patch.

[rsalesc]

please use the language kinds for the checker to identify this

[rsalesc]

Done in 087f800. Now uses LanguageKind.CPP in environment.language_kinds(code.find_language(checker)) instead of the hardcoded suffix set, so detection derives from the actual toolchain and is robust to custom language names. Added test_output_validators_reject_non_cpp_checker to cover the rejection path.

[rsalesc]

could you explain this better? i'm not sure i like the idea of solutions with certain outcomes just vanishing from the upload. please research how these submissions are used, when they matter, which ones we can map to their outcomes, etc. please specifically validate that domjudge (not only problem package format) supports what you're stating.

[rsalesc]

You're right — dropping solutions was wrong. I researched how DOMjudge actually handles jury submissions (verified against the DOMjudge 9.0 source, not just the problem-package spec) and reworked it in 087f800 so no solution is ever dropped.

How DOMjudge uses these: on import it auto-judges every solution in submissions/ and records an expected verdict per submission, then surfaces any mismatch on the jury Judging verifier page (it never blocks the import). The expected verdict comes from one of two places:

• Directory name, when it normalizes to a real verdict via DOMjudge's PROBLEM_RESULT_REMAP table (SubmissionService.php). That's 7 dirs, not 4: accepted, wrong_answer, time_limit_exceeded, run_time_error, output_limit, compiler_error, no_output.
• An @EXPECTED_RESULTS@: source annotation, which supports multiple acceptable verdicts (e.g. CORRECT, TIMELIMIT). Crucially, in a verdict-named dir DOMjudge collapses the annotation to the dir's single verdict; in a non-verdict dir (e.g. mixed/) it keeps the full list. So multi-verdict expectations must live in a non-verdict dir.

New mapping (every outcome shipped):

rbx outcome	placement
ACCEPTED / WRONG_ANSWER / TIME_LIMIT_EXCEEDED / RUNTIME_ERROR	matching standard dir, no annotation
OUTPUT_LIMIT_EXCEEDED	output_limit/ (DOMjudge extension dir)
ACCEPTED_OR_TLE	mixed/ + @EXPECTED_RESULTS@: CORRECT, TIMELIMIT
TLE_OR_RTE	mixed/ + TIMELIMIT, RUN-ERROR
INCORRECT	mixed/ + all non-CORRECT verdicts
ANY	mixed/ + all verdicts
MEMORY_LIMIT_EXCEEDED	mixed/ + RUN-ERROR, TIMELIMIT

The one thing DOMjudge genuinely can't represent: there is no memory-limit verdict and no @EXPECTED_RESULTS@ token for it — an over-memory run surfaces as RTE (sometimes TLE). So MLE is the single lossy mapping; I encode it as RUN-ERROR, TIMELIMIT and documented the caveat. Everything else is exact.

Annotation comment prefix is # for Python, // otherwise. Docs/CLAUDE.md updated with the table and a note that mixed/ solutions trigger a harmless "result does not match directory" message on import. Covered by test_submissions_single_verdict_use_standard_dirs and test_submissions_ambiguous_outcomes_use_mixed_dir_with_annotation.