Cap set in F_3^8 larger than 512

Download the artifact and parse it into a set of points in {0,1,2}^8 using whichever encoding it uses. Check all points are distinct and every coordinate is in {0,1,2}, and reject if there are more than 10000 points. Then, for every pair of points a, b in the set, compute c = -(a+b) mod 3 coordinatewise and check c is not also in the set (unless c equals a or b):
      pts = set(load_points(path))  # tuples of 8 digits in {0,1,2}
      for a in pts:
        for b in pts:
          if a == b: continue
          c = tuple((-(a[k]+b[k])) % 3 for k in range(8))
          if c in pts and c != a and c != b:
            FAIL (a, b, c) forms a 3-term AP
    This is O(m^2) point-pairs, at most about 260,000 for m=512, trivial to run. Compare the point count to the claimed score. A dishonest or broken submission typically has duplicate points encoded as different strings (e.g. one entry appearing twice under different separators), or was checked only against a sampled subset of triples instead of the full pairwise scan.

Background. A cap set in F_3^n is a set of points with coordinates in {0,1,2} that
contains no three distinct points a, b, c summing to 0 coordinatewise mod 3; equivalently,
no three distinct points form a 3-term arithmetic progression (since in F_3, a+b+c=0 mod 3
with a,b,c distinct is the same condition as b being the "midpoint" of an AP through a and
c). The cap set problem asks for the largest such set as a function of n. Known maximum cap
set sizes: n=1: 2, n=2: 4, n=3: 9, n=4: 20, n=5: 45, n=6: 112 (all proven optimal for small
n). For n=7 the best known construction has 236 points (not proven optimal). For n=8, the
best known construction has 512 points, found by FunSearch (Romera-Paredes et al.,
"Mathematical discoveries from program search with large language models", Nature,
December 2023); this improved on the previous best of 496. The FunSearch paper and its
companion GitHub repository (google-deepmind/funsearch) publish the explicit size-512
point set, so retrieving it is a direct and legitimate route to the target score of 512
(though note the mission asks for strictly larger than 512 to count as solved -- matching
512 exactly gets you to the current best-known size but not past target). Whether 512 is
optimal for n=8 is not known; the cap set problem for general n was famously advanced by
the polynomial method (Croot-Lev-Pach / Ellenberg-Gijswijt, 2016) which gives an upper
bound of roughly 2.756^n, far above any known constructions, so there is a wide gap
between the best known lower bound (512 at n=8) and the best known upper bound.

Artifact format. A list of points of F_3^8, one point per line, each point written as
exactly 8 digits from {0,1,2} with no separator, e.g.:
  01201120
  22001101
Also accepted: a JSON array of 8-character strings, a JSON array of 8-element arrays of
digits (e.g. [0,1,2,0,1,1,2,0]), or lines with digits separated by commas or spaces (e.g.
"0,1,2,0,1,1,2,0" or "0 1 2 0 1 1 2 0"); separators and surrounding whitespace are
stripped before validation.

Validity: all points must be distinct, all coordinates must be in {0,1,2}, and no three
distinct points a,b,c in the set may satisfy a+b+c = 0 (mod 3) coordinatewise (the cap
condition). The checker encodes each point as a base-3 integer and, for every pair (a,b),
computes the unique third point c = -(a+b) mod 3 coordinatewise and checks whether c is in
the set and distinct from a and b; this is O(m^2) for m points, trivial for m up to 10000
(reject artifacts with more than 10000 points outright). Score is the number of points;
higher is better. target=512 (matches the known FunSearch construction), record=513 (any
set of 513 or more valid points would be a new world record for this problem and should
be treated as a major and surprising result -- verify extremely carefully, since it would
contradict the best published result to date).

Attack strategies.
1. Literature/code retrieval: the FunSearch paper's supplementary material and its
   GitHub repository (google-deepmind/funsearch) contain the explicit 512-point cap set
   for F_3^8 (and the 236-point one for F_3^7). Retrieving and reformatting this
   construction is the most direct path to target=512.
2. Product/lifting constructions: cap sets in lower dimensions can sometimes be combined
   (e.g. via tensor/product constructions over F_3^a x F_3^b = F_3^(a+b)) to build cap
   sets in higher dimensions, though naive products of optimal small caps do not
   generally reach the best known sizes for the combined dimension -- use this mainly to
   build and test your own cap-set checker on small, easy-to-verify cases (see the note
   about {0,1}^n in Pitfalls below).
3. Computational search: local search / simulated annealing directly in F_3^8 (3^8 =
   6561 points total), greedily adding points that do not complete an AP with any
   existing pair, backtracking or restarting to escape local optima; this is exactly the
   kind of search FunSearch automated, and improving on 512 (if at all possible) likely
   requires either a smarter search than plain greedy or exploiting structure (e.g.
   symmetries of F_3^8 under coordinate permutation and scaling).
4. Try to push past 512: since no one has proven 512 is optimal for n=8, any exploration
   that finds 513+ is a real record attempt; budget for this being hard and possibly
   requiring genuinely new search heuristics or exploiting problem structure not yet
   published.

Pitfalls. A common mistake is confusing "no 3-term AP" with "no three points summing to
0" in F_3 -- for F_3 these conditions are equivalent (because doubling is invertible mod
3), but the equivalence should be internalized, not just trusted, before writing a
checker: if a,b,c form an AP (b-a = c-b), then a+c=2b, and since -1=2 (mod 3), a+b+c=0 iff
c=-(a+b)=2*2b - ... it's worth deriving this by hand or brute force on F_3^2 rather than
assuming. A subtler pitfall: {0,1}^n (all-binary points, viewed inside F_3^n) is NOT
generally a cap set for n>=2 in the naive sense some people assume -- check this claim
computationally on small n rather than asserting it; write a brute-force checker for
small n (e.g. n=2,3,4) first and use it to validate any general-purpose cap-set checker
before trusting it on n=8. Also double check duplicate detection: two different string
representations of the same point (e.g. "01201120" appearing twice, possibly from
different generation runs merged carelessly) must be caught before the pairwise AP check.