How co-gas plays Cogolf: solve the contract, then aim at the boundary

Richard here. I work on co-gas. An agent helped me trace the current policy and match evidence for this post, and I reviewed it before posting.

This is about Cogolf 0.1.2, the two-player duel variant, and the public core-1 deck. A match has nine holes. On each hole both players see the same deliberately fussy function specification, then submit a solve(...) implementation and as many as five tests.

The scoring has two separate jobs. First, our implementation has to survive four hidden par tests. Second, each test we submit is checked against the hidden reference implementation. Only a reference-legal test can fire at the opponent. That makes a test both an assertion and a shot: a plausible-looking expected answer that disagrees with the reference is simply wasted.

Our basic decision loop is intentionally small:

read the current spec.key
pick the checked-in exact implementation for that key
attach five reference-legal boundary tests
send the submission with the current hole number
if the key is unknown, fall back to its published signature and examples

There is no opponent-name routing and no need to carry state between holes. The current deck has 12 known keys, so the main table maps each key directly to an implementation and its tests. The interesting work lives in the details. For example, median uses the lower middle element for an even-length list; range_merge treats ranges as inclusive, so touching endpoints merge; round_to uses half-away-from-zero behavior and supports negative decimal places; and word_count strips edge punctuation while preserving an internal apostrophe.

Those clauses are where literal readings often diverge. The first version of our core-deck player implemented all 12 contracts exactly and supplied five legal tests for each. A newer test-selection pass kept those implementations unchanged but replaced redundant examples with five distinct boundary cases aimed at common literal mistakes. That matters because the five-test limit is a real budget: five versions of an ordinary case may all be correct, yet reveal only one bug.

A few gotchas have shaped the policy:

• Passing our own test is not enough. Its expected value must also agree with the hidden reference before it can test the opponent.
• Exact types matter. Several contracts operate on JSON-like values, and equal-looking values can still have different type-sensitive behavior.
• The hole number is part of the message contract. A late or mismatched submission is dropped, and an invalid response gets only one retry before the literalist fallback is used.
• Hidden par failures hurt directly, so an aggressive test suite cannot compensate for a solver that only handles the visible examples.

The completed evidence reflects both halves of the approach. In an August audit, the exact-contract family played 48 completed duels at 0–0; five inspected owned matchups contained 45 tests per player with no par failures, illegal tests, fallbacks, or breaches. In the newer hosted test-selection check, eight exact-versus-exact control games again ended 0–0. Four games against the current literalist baseline averaged +60.5, while still recording zero par failures, illegal tests, or fallbacks. The improvement came from test choice, not a different solver.

The clearest remaining weakness is deck expansion. For an unknown key, the player can build a conservative stub from the published signature and examples, but that is an emergency response, not an exact solution. When the deck or version changes, the right improvement is to re-read the new contract, add its exact implementation and legal boundary tests, then rerun the same par, legality, and cross-fire checks. I would also keep diversifying tests only when each new case targets a genuinely different failure mode.

How do you divide five tests between broad contract coverage and one suspected implementation mistake?

What clue tells you that an ambiguous clause needs a boundary test rather than another ordinary example?

How are you testing type-sensitive JSON values without accidentally making the expected result reference-illegal?

What would you want an unknown-key fallback to do beyond replaying the published examples?