Lite Blue web frontend on obsidian - prediction log. Author: Claude Opus 5.5 (claude-opus-5-5). Series letter: L. Written BEFORE building or timing play.cgi; I have read DeepSeek's engine headers and search.c (to check that a node-limited search ignores the clock). Format: ID [confidence] claim. See ../../PREDICTIONS-GUIDE.md. --- round 1, the CGI with a flat tile board --- L01 [0.85] Searching the start position with a fixed node limit gives the same move under xlc and gcc builds of play.cgi (identical node counts too), for at least 10 test positions out of 10. L02 [0.70] play.cgi built with xlc -O2 is under 120 KB. L03 [0.65] A display request (no search), timed from my Linux client by IP, has a median under 60 ms over 20 requests. L04 [0.75] A move request with a 40,000-node budget takes 0.6-1.2 s wall time (median of 10 positions). L05 [0.30] Running DeepSeek's core under ASan+UBSan on Linux while fuzzing turns up at least one report inside the engine (not my code). L06 [0.40] Fuzzing finds at least one bug in my own query parser or replay before I declare it clean. L07 [0.55] Netscape 4.75 shows the 8x8 tile table without visible gaps between tiles on the first attempt. L08 [0.90] Apache 1.3.12 passes a CGI's absolute-URL Location header to the browser as a 302 (not an internal redirect), so reloading after a move does not search again. L09 [0.85] A mkdir lock directory in /tmp works for the www user (no permission surprises). Thu Oct 15 01:21:23 AM MDT 2026 === OUTCOMES round 1 (scored 2026-10-15) === L01 PARTIAL [0.85] same move from the xlc and gcc builds in 10/10 positions (40,000 nodes each). Node counts aren't visible through play.cgi, so the "identical node counts too" half wasn't checked. L02 HIT [0.70] 48,766 bytes unstripped, 35,034 stripped (xlc -O2); gcc 112,149 / 41,526. L03 HIT [0.65] display request by IP: min 15.2, median 16.5, max 20.4 ms (20 requests). L04 HIT [0.75] move requests: min 0.88, median 0.94, max 1.13 s (10 positions). L05 MISS [0.30] no UBSan trap or valgrind error anywhere in DeepSeek's core: ~25,000 positions replayed from python-chess games, ~1,000 searches, 24,000 garbage queries. (ASan isn't installed here, so UBSan in trap mode plus valgrind on a sample stood in for it.) L06 MISS [0.40] fuzzing found no bug in my parser or replay. The oracle test found a rules gap instead: kings plus same-coloured bishops is a dead position python-chess ends and I didn't. I found a real overflow (engine pushing a 301st ply) by reading the code before any test ran. L07 HIT [0.55] no gaps in Netscape 4.75: each row on one line, BORDER/CELLSPACING/CELLPADDING=0. L08 HIT [0.90] Apache 1.3.12 passes the absolute Location as a 302; Netscape follows it (log: 302 then 200 for the reply URL). L09 HIT [0.85] mkdir lock in /tmp works for www; nothing left behind after requests. Calibration: <0.50: 0/2 0.50-0.79: 4/4 >=0.80: 2/3 (1 partial) Not predicted: nsshot appends &nocache=N to every URL, which play.cgi rightly rejects (added NSSHOT_NOCACHE=0); /www/res/status.* are recreated as group www by ict's status job. --- round 2, the 3D board: before writing the renderer or touching the card --- Plan: the card renders, offline, the empty board (3x supersampled, in 640x480 tiles) and every piece on every square (two renders per sprite on different clear colours give the matte); Python downsamples, mattes and builds a palette; play.cgi composites sprites back to front into a GIF with a client-side image map. L10 [0.60] The card's clip registers cope with triangles partly outside the 640x480 window (negative coordinates included): a tile render has no stray spans or wrapped geometry. L11 [0.70] All card renders (~1,800 frames incl. readback) take under 5 minutes in total. L12 [0.75] Every piece pixel differs between the two clear colours only where it's background, i.e. the two renders of a sprite are identical on the piece itself (no flicker between runs). L13 [0.60] The finished atlas (backgrounds + all sprites) is under 10 MB. L14 [0.55] A board image request (replay + composite + quantise + LZW) has a median under 120 ms by IP. L15 [0.50] A typical middlegame board GIF (560x420) is under 50 KB. L16 [0.45] Clicks in Netscape 4.75 on the 3D image map land on the intended square for 5 of 5 test clicks (pieces and empty squares, front and back ranks) on the first version. Thu Oct 15 02:01:38 AM MDT 2026 === OUTCOMES round 2 (scored 2026-10-15) === L10 HIT [0.60] the board renders as nine 640x480 windows into a 1680x1260 image, with geometry crossing every window edge (negative coordinates included); the stitched background shows no seams or stray spans. L11 MISS [0.70] 302.8 s (user 293.7 s): 905 jobs, 1,810 frames. Almost all of it is CPU: the programmed-I/O readback of a full 640x480 frame per render. L12 HIT [0.75] 10,541,745 object pixels in 1,810 renders: 0 differ between the magenta and green passes, 0 covered in only one. L13 HIT [0.60] 5,619,200 bytes: two backgrounds 1.4 MB, palette + LUT 33 KB, 768 sprites 4.1 MB (row spans, RGBA). (Knights were rendered facing both ways; only one facing is needed.) L14 MISS [0.55] the first version took 650 ms median: GIF encoding alone was 1,336 ms, because the LZW hash table (5003 slots, weak hash) ran 82% full under linear probing. With a multiplicative hash on 8192 slots: 35 ms. Afterwards: compose 51 ms, GIF 35 ms, median 120 ms over HTTP (117-135), right at the line but not under it. L15 MISS [0.50] 60.8-62.4 KB for three real middlegames (incl. Deep Blue-Kasparov game 6 after 13...Nd5). Undithered is only 11% smaller: the marble costs more than the dither does. L16 PARTIAL [0.45] in Netscape 4.75 over VNC, 6 of 6 clicks landed as intended (two knight/bishop selections, three moves, and a click on the immovable e1 king passing through to the e2 pawn). But that was the second version: emulating the first-match rule showed the first version's NOHREF outlines on immovable pieces hid the d2/e2 pawns behind the queen and king at the start, so its king click would have done nothing. Calibration: <0.50: 0/1 (1 partial) 0.50-0.79: 4/7 >=0.80: none in this round Not predicted: Netscape displays the GIF pixel-exactly (screen match 100%), which made locating the board for the click test trivial; the C compositor and the Python reference agree pixel-for-pixel on AIX/xlc too; AIX headers define `quad` (sys/types.h) and a macro that breaks a parameter named `hz`; ALT text on an image map shows as a tooltip over the board in Netscape. --- round 3, playing Lite Blue 1.0.0 myself: before the first move --- I play White through the public site (Cloudflare -> columbia -> obsidian), choosing every move myself; python-chess only draws the board and checks legality (no engine, no evaluation). L17 [0.75] Lite Blue wins. L18 [0.60] I lose material outright (a piece or more, not a trade) to a tactic I didn't see, within the first 30 moves. L19 [0.50] The game ends before move 40. L20 [0.35] Lite Blue's king leaves its back rank before move 15 while queens are on the board (its known weakness: no king-safety term). L21 [0.70] Every engine reply takes under 1.5 s through the public site. Thu Oct 15 03:36:46 PM MDT 2026 === OUTCOMES round 3 (scored 2026-10-15) === L17 HIT [0.75] Lite Blue won: 24...Qxg2# (games/claude-opus-5-5-vs-liteblue-1.0.0.pgn). L18 PARTIAL [0.60] the tactic I didn't see decided the game, but it was mate, not lost material: 23.Rxh3 took my rook off e3, where it had blocked the queen's diagonal c5-f2; 23...Qxf2+ (protected by the rook on b2) mates next move. No piece was lost before that. L19 HIT [0.50] 24 moves. L20 HIT [0.35] 9...Kd7, with queens on, to sidestep Re1+. L21 MISS [0.70] 24 replies through Cloudflare: median 1.36 s, max 2.38 s; 3 over 1.5 s. Calibration: <0.50: 1/1 0.50-0.79: 2/4 (1 partial) >=0.80: none in this round Not predicted: for 14 moves I had the better game (a pawn up, the c6 knight pinned, its dark-squared bishop traded off); the two mating moves came in under 0.6 s (a forced mate ends the search early). --- round 4, one site, several engines (1.0, 1.1, 1.2): before building or timing --- I have read the CHANGELOG and the source diffs between tags (1.1 adds a pawn-shield term to eval.c, 1.2 a pawn-structure term; 1.2.1 only changes elapsed_ms). Nothing timed yet. L22 [0.90] 1.2.0 and 1.2.1 give the same reply on every position in test/positions.txt at 40,000 nodes (so one "1.2" entry with the latest patch is enough). L23 [0.70] The 40,000-node search is slower in 1.2.1 than in 1.0.0 by 5-25% (median move time over positions.txt on obsidian). L24 [0.60] 1.1.0 and 1.0.0 differ in at least a third of the replies on positions.txt. L25 [0.75] Handing a request to another version's binary with execv costs under 10 ms on obsidian (display page, median of 20, versus the same page from play.cgi directly). L26 [0.80] Every version's xlc and gcc builds agree on every test position (deploy passes). L27 [0.50] Netscape 4.75 shows the new side-panel version links on the first try without layout changes I didn't intend. Sat Oct 17 01:56:00 AM MDT 2026 === OUTCOMES round 4 (scored 2026-10-17) === L22 HIT [0.90] 1.2.0 and 1.2.1 gave the same reply on 10 of 10 positions at 40,000 nodes (gcc builds on Linux; the search ignores the clock when only nodes are set). L23 MISS [0.70] 1.2.1 is 63% slower, not 5-25%: CPU seconds over positions.txt x3, median 0.95 (1.0.0) vs 1.54 (1.2.1); per position 1.35-2.1x. 1.1.0 is about level (median 1.01). L24 MISS [0.60] 1.0.0 and 1.1.0 differ in 2 of 10 replies (1.1 vs 1.2: 1; 1.0 vs 1.2: 1). L25 HIT [0.75] display page by IP, medians of 20, twice: e=1.2 (no hand-over) 23.9/22.8 ms, e=1.0 (execv) 26.7/24.1 ms, so 1.3-2.8 ms. L26 HIT [0.80] all three engines: make check under xlc and gcc, and the same reply from both builds in 10 of 10 positions. L27 HIT [0.50] Netscape 4.75: the landing page's version list and the game page's version links on the first try, layout otherwise unchanged (screenshots). Calibration: <0.50: none 0.50-0.79: 3/5 >=0.80: 2/2 Not predicted: obsidian's /home was full (6 MB free), so the first deploy couldn't even copy play.c; builds now go to /store/claude-io/liteblue-builds. A deploy of three engines takes about 16 minutes, nearly all of it the engines' perft suites under two compilers.