A Repair Tool Learned From a Single Example, Then Survived Every Renumbering

A small open-source repair tool was handed a single routing example and asked to recover the rule. It generated four arithmetic instructions, compiled them to arm64, and shipped the result. Tested against all 4 billion possible inputs against an independent reference checker, it produced zero mismatches. Then it fixed five byte-exact bugs in code it had never seen, in 10.3 seconds, using zero LLM tokens. The post is a self-report on r/MachineLearning, and the artifact is a GitHub repository.

The tool's routing function is a 4-instruction arm64 sequence: logical shift right, subtract, add, and AND. In source form, the expression is 15 & ((x >> 4) + ((x >> 8) - x)), and the offset between the index and the action code is recomputed on every call. Nothing is stored. Renumber the action codes, and the function still works, because the rule is structural rather than a memorized mapping. A 16-entry lookup table, the obvious alternative, holds 16 stored answers, and the moment an upstream developer renumbers the action codes, 15 of those 16 entries are wrong. A repair tool that memorizes the table inherits the brittleness. A repair tool that derives the rule inherits the renumbering.

The synthesis was done by organism_inf.sphere, a program-synthesis engine that takes an input/output pair, an operator budget, and an intent cut, and returns the smallest expression in the searched space. The author independently re-derived the expression and couldn't beat it on instruction count. The verification is exhaustive: all 2^32 inputs checked against an independent reference, zero mismatches. Across the input range, each of the 16 action codes occurs exactly 2^28 times, and bits 12 through 31 of the input never influence the result, which is mechanically consistent with a routing kernel that only needs the low four bits.

The UNSEEN.md file documents five single-line faults in idioms the tool had not seen before: a funcy callback signature, an off-by-one in a chunking loop, a TTL decrement in cachetools-style arithmetic, a sortedcontainers-style bisect bound, and one unattributed single-line fault. The tool repaired all five byte-exact in 10.3 seconds, with zero LLM tokens. Byte-exact means the patched line is character-identical to the intended source, not merely that the test suite went green. A weak test suite will happily accept a wrong edit, and the source is explicit about it.

Then the tool hit a 595-second hang. During testing, a candidate with action code 6 decremented a literal inside a loop that never advanced. The pipeline executed it without a timeout, and the whole run hung for 595 seconds, producing nothing. The fix was a 5-second per-candidate bound; the same corpus then finished in 10.3 seconds at 5 of 5. A non-terminating mutated candidate will stall any repair pipeline that doesn't bound it, and the cost is paid in wall-clock time, not in a graceful error. The lesson generalizes to any system that runs candidate code: fuzzers, synthesizers, repair tools, and property-based test generators all need the same per-candidate bound.

The four-action vocabulary covers roughly 63% of real-world buggy code lines. Boolean swaps, removals, and multiplicative flips have no assigned action and are never repaired; there is no action to route to. The identifiability limit is sharper. One input/output pair is consistent with all 15! relabellings of the action codes, exactly one of which is a translation. The tool can't recover an arbitrary permutation from one example, and the source argues, plausibly, that nothing can.

The tests directory holds the verification harness. The artifact and the measurements are the author's own, and no independent reproduction is in the source bundle. An independent source running the same five UNSEEN.md lines through the same 5-second-bounded pipeline is the next concrete test.