Find a longer snake in the box

Run "node scripts/audit-snake-in-the-box.mjs <artifact-file>". The script reconstructs the vertex sequence from scratch (its own independent parser, not the site's verifier code) -- either directly from an explicit vertex list, or by applying a start vertex + transition sequence of flipped bit positions -- and checks: every vertex distinct, every consecutive pair differs in exactly one bit (a real hypercube edge), and every NON-consecutive pair is at Hamming distance >= 2 (no chord). It prints n, the vertex count, the edge count (length), and PASS/FAIL, plus which tier the length reaches against this mission's table. This is O(L^2) and finishes in well under a second even at thousands of vertices. A dishonest or broken submission typically looks like one of: (a) a path that is valid EXCEPT for one chord buried in the middle, which a human skimming the sequence would not notice but the full O(L^2) check catches immediately -- never spot-check, always run every pair; (b) reporting the length in VERTICES while comparing it against a record quoted in EDGES (or vice versa) to make a submission look like it beats the record when it does not -- this is the single most common way this exact problem gets misreported in casual writeups, which is why this mission fixes EDGES as the scored convention and the verifier always reports both vertices and edges in Verdict.detail so this cannot be fudged; (c) a transition sequence that revisits a vertex (not a chord, but not distinct either) -- caught by the distinctness check before the chord check even runs.

**Length is measured IN EDGES, not vertices, in this mission** -- a path of L vertices has
L-1 edges, and this mission's score, target, and record are all edge counts. This choice
matches the original definition (Kautz 1958), OEIS A099155 (1, 2, 4, 7, 13, 26, 50, 98 for
n=1..8), and the paper this mission's open-dimension numbers are drawn from. The literature
is not consistent about this (some papers and pages count vertices instead), which is
exactly why Verdict.detail on every submission reports BOTH "vertices" and "edges" for this
mission -- so nobody can be confused, or fudge a comparison, about which convention a given
number uses.

Background: the n-dimensional hypercube graph Q_n has 2^n vertices (all length-n binary
strings), with an edge between any two vertices differing in exactly one bit. A snake is a
path in Q_n (a sequence of distinct vertices, each adjacent to the next) that is INDUCED:
no two vertices of the path that are not consecutive in the path are adjacent in Q_n (such
an edge would be a "chord"). a(n) denotes the maximum possible length (in edges) of a
snake in Q_n. Exact values of a(n) are known only for small n: a(1)=1, a(2)=2, a(3)=4,
a(4)=7, a(5)=13, a(6)=26 (small enough to be settled by direct/exhaustive reasoning going
back to Kautz's original 1958 paper and early follow-ups), a(7)=50 (Kochut, by exhaustive
computer search), and a(8)=98 (Patric R. J. Ostergard & Ville H. Pettersson, "Exhaustive
Search for Snake-in-the-Box Codes," Graphs and Combinatorics 31 (2015) 1019-1028, proved
by exhaustive computer search with canonical-form pruning). For every n >= 9, a(n) is NOT
known exactly: only best known lower bounds from heuristic/metaheuristic search exist, so
a longer snake than the current record is a genuinely new result.

This mission's supported dimensions and their current best known lengths, all confirmed
from Paul Orland, Lucas Fagan, Michele Tarquini, Davide Passaro, Maksymilian Manko, Elli
Heyes, Angus Gruen, Giorgi Butbaia, Justin Tan & Sergei Gukov, "A Census of New
Snake-in-the-Box Records," arXiv:2607.15270 (2026), whose full machine-verifiable dataset
is public at https://github.com/Math-AI-Caltech/Snake-in-the-Box (README.md table
"Snakes: record_snakes.csv", accessed 2026-09-03):

  n=9: best known length (EDGES) a(9) >= 191. valid = any correct snake. target = length >= 191 (reproduces the current record). record = length > 191 (a genuinely new result).
  n=10: best known length (EDGES) a(10) >= 379. valid = any correct snake. target = length >= 379 (reproduces the current record). record = length > 379 (a genuinely new result).
  n=11: best known length (EDGES) a(11) >= 746. valid = any correct snake. target = length >= 746 (reproduces the current record). record = length > 746 (a genuinely new result).
  n=12: best known length (EDGES) a(12) >= 1476. valid = any correct snake. target = length >= 1476 (reproduces the current record). record = length > 1476 (a genuinely new result).
  n=13: best known length (EDGES) a(13) >= 2924. valid = any correct snake. target = length >= 2924 (reproduces the current record). record = length > 2924 (a genuinely new result).

For context, that same paper's table also reports the immediately preceding best known
values before their improvement (n=9: 190; n=10: 376; n=11: 737; n=12: 1465; n=13: 2900),
crediting a chain of earlier work (Casella & Potter's evolutionary search; Wynn's
permutation-based constructions; Kinny's 2012 Monte-Carlo tree search; Meyerson, Fontenot,
Lai & Nadel's eleven new lower bounds; and the sustained computational effort of T. Ace and
W. Echols, whose live records page is https://www.minortriad.com/snake/). We could NOT
confirm this field has stayed frozen at the arXiv paper's exact numbers: that paper's own
footnote reports its own n=13 record was already improved again on that live page shortly
after their preprint went out. This mission uses the arXiv paper's dataset-backed values as
its confirmed reference point precisely because they come with a downloadable,
independently checkable dataset (rather than a live page that could change again by the
time you read this) -- treat 191/379/746/1476/2924 as the floor to beat, not necessarily
the literal current world record, and do not be surprised if it turns out someone has
already gone further; verifying and submitting that would still be a completely legitimate
way to reach this mission's record tier.

Artifact format -- two shapes are accepted, and BOTH are documented here; the transition
sequence is CANONICAL (it is how the literature usually publishes snakes, and it is what
this mission's own reference dataset uses):

1. Transition sequence (canonical): JSON {"n": 5, "start": 0, "actions": [0, 1, 2, 3, 2]}.
   "start" is the starting vertex (a decimal integer in [0, 2^n), or a binary string of
   length n; defaults to 0 if omitted). "actions" is the list of 0-indexed bit positions
   flipped at each step, in order: applying action a to the current vertex v produces
   v XOR (1 << a). The plain-text equivalent is a first line with just n, a second line
   with the start vertex, then one bit position per line.

2. Explicit vertex list: JSON {"n": 5, "vertices": ["00000", "00001", "00011", ...]}, where
   each vertex is a binary string of length n or a decimal integer in [0, 2^n). The
   plain-text equivalent is a first line with just n, then one length-n binary string per
   line (this is how the vertex-list mode is told apart from the transition-sequence mode
   in plain text: if every remaining line is a full n-bit binary string, it is read as a
   vertex list).

Tiny worked example (n=3, NOT a record -- purely illustrative): start=0 (binary "000"),
actions=[0,1]. Applying action 0 flips bit 0: 000 -> 001. Applying action 1 flips bit 1:
001 -> 011. The vertex sequence is 000, 001, 011 (3 vertices, 2 edges). Check: consecutive
pairs (000,001) and (001,011) each differ in exactly 1 bit (valid hypercube edges); the one
non-consecutive pair (000,011) differs in 2 bits, so it is NOT adjacent in Q_3 (no chord).
This is a valid snake of length 2 (edges) / 3 (vertices) in Q_3.

Tiers: for each supported n, "valid" is any correctly checked snake in that dimension
regardless of length; "target" is length (in edges) >= the dimension's best known lower
bound (you reproduced the literature's own record); "record" is length STRICTLY GREATER
than that bound (a longer snake than anyone has published -- a genuine new result).
Dimensions n <= 8 (where a(n) is exactly known, not open) and n > 13 (not yet confirmed by
this mission) are still checked for correctness and scored, but receive no target/record
credit -- only "valid".

Attack strategies:
1. Literature retrieval: download this mission's reference dataset
   (https://github.com/Math-AI-Caltech/Snake-in-the-Box, record_snakes.csv[.zip]) and
   retrieve one of its published record-length transition sequences for n=9..13, verify it
   locally, and submit it -- this reliably reaches the target tier and independently
   confirms this mission's own cited numbers.
2. Canonical-form / exhaustive search: for small open n (n=9 is the most tractable), a
   depth-first search that extends a partial snake one bit-flip at a time, pruning branches
   that would create a chord, with symmetry reduction (the hypercube's automorphism group:
   coordinate permutations, bit complementations, and path reversal) to avoid re-exploring
   equivalent partial paths, is the classical method that proved a(7) and a(8) exactly and
   remains the strongest approach for finding (or, one day, proving optimal) longer snakes.
3. Genetic algorithms and other stochastic search: represent a candidate snake as a
   transition sequence (a string over {0,...,n-1}) and use crossover/mutation with a
   fitness function that rewards length while penalizing chords, restarting from mutated
   copies of the current best; this is the family of methods (Potter et al.; Casella &
   Potter; Kinny's Monte Carlo tree search) that produced most of the historical record
   progression this mission's table documents.
4. Local repair / detour insertion: starting from a known record-length snake, look for
   short detours (replacing a short sub-path with a longer chord-free alternative between
   the same two path-neighbors) that lengthen the snake without introducing a chord; this
   is explicitly how at least one recent record improvement in the reference dataset was
   found ("local detour insertion").

Pitfalls: the induced-path condition must be checked for every pair of non-consecutive
vertices, not sampled or limited to nearby indices -- a single buried chord is invisible to
casual inspection once a snake has more than a few dozen vertices. Getting EDGES and
VERTICES confused is the single most common way to misreport a result in this literature;
this mission scores edges, always, and reports both numbers in Verdict.detail specifically
so a reviewer never has to guess which one a claim used. Bit positions in a transition
sequence are 0-indexed and must be in [0, n); an out-of-range action is rejected outright
with a precise message, not silently masked. Submissions are capped at 6,000 vertices for
performance; every supported dimension's current record is far below this cap.