The world's smallest chess game that enforces every official rule.

A complete, tournament-grade chess arbiter packed into a single HTML file of 2.7 KB (the measure of how much room a file takes on disk; 1 KB = 1024 bytes). Built on the Golfstack idea, the project is an engineering exercise that pushes code optimisation to its limit: the most function in the least space.

Two players share one device, and the engine delivers a fully featured game of chess without reaching for a single external library.

Nothing is missing on the rules side. The whole FIDE book is implemented. You can find how each article behaves, one by one, on the Official rules of play tab. Even in the thorny scenarios where resignation and flag fall meet insufficient material, the ruling follows 5.1.2 and 6.9 exactly. On the blocked-position branch of 5.2.2 every ruling the engine makes is correct: a position it calls dead really is dead. Measured coverage is 93%; the remaining 7% are edge cases involving a bishop. Anything it does not recognise, it plays on — so the margin of error always falls on the safe side.

The real claim is not these items one by one, but the ratio itself: bytes per unit of service. Everything above comes out of a single downloadable file of 2.7 KB.

The engine was tested thousands of times during development, edge cases included, and every known bug was cleared. Even so, if something catches your eye during a game, report it; feedback improves the engine directly.

Each build runs in its own frame, and the clocks only start ticking once you start it. Changing builds closes the running game.

If the board feels small in the L3 and L3 input builds, use the browser's zoom — Ctrl +, or ⌘ + on macOS. The game scales along with the frame; Ctrl 0 restores it.

Code golf is the art of writing a program in as few characters as possible without giving up anything of its function, its rules or its logical correctness. There is one constraint: the behaviour stays the same, the volume shrinks.

From beginning to end this project chased a single question:

The answer is below. But to ask the question at all, I first had to decide where the word “complete” begins.

Writing the engine, I found myself in the middle of the Ship of Theseus paradox: what can you strip out of a game of chess and still be left with chess?

An unavoidable question of identity surfaces here. I did not take pre-fifteenth-century chess as the starting point — there the bishop leaps exactly two squares, the queen moves one square diagonally, and there is no castling and no double pawn step. They share a name, but that game and the one we play today are fundamentally two different identities; taking it as the baseline would have meant answering the question for a different game.

What I took as the starting point was this: today's piece movement, check, checkmate and stalemate, the pawn's single-square advance, and automatic promotion to a queen. That is the core left over once everything removable has been removed. Take one more article away and the game stops being chess.

With the core in hand there was only one direction left: adding.

The engine did not arrive in one piece; it grew through overlapping rounds.

Choice of promotion piece came first, releasing the pawn from its sentence to the queen and making knight, bishop and rook options too. Then the pawn's two-square advance, and with it the en passant capture that has to come along — the two are inseparable, because the second closes the hole the first opens. Then castling. At that point what was happening on the board was chess as we play it today.

After that I moved off the board. The two theoretical limits that keep a game from running forever, the 50-move rule and the clock, entered the engine at this stage.

Normally I would have stopped there. But having come this far I wanted to finish the rest of the rulebook: repetition of position, insufficient material, the draw offer and the draw claim, flag fall, resignation. That brought in the rulings an arbiter makes without ever looking at the board.

I cannot claim this path was a straight line. Again and again I had to go back after noticing that a rule I had already added did not match FIDE exactly, or behaved wrongly in a particular position. Sometimes a new discovery threw out the entire solution I had written up to that point. Every reversal meant a structural revision and then a fresh round of byte optimisation; the code grew, then shrank again.

It was a long and instructive process, on both the coding and the chess-logic side. Which rule broke what, which discovery forced a rewrite of what — I will tell that step by step and in far more detail in a separate “Build log” section.

Asked how he made his sculptures, Michelangelo is famously said to have answered:

That is what I did in Golfstack. What the rules were was clear from the outset; the work was carving away every excess that described them.

Claude Shannon's information theory tells you where that carving ends: every message has a lower bound below which it cannot be compressed losslessly, and any saving past that bound is no longer a saving but a loss of information. Code golf is exactly the walk toward that bound. The difference here is that the compression has to be lossless: drop a single article from the logical data the rules require and what is left is not a smaller chess; it is something that is not chess.

The answer to the question is therefore a single number: 1,815 bytes. numerical_packed.html arbitrates an official game between two human players from the first move to the last.

One of the first questions that comes up is this: why the browser, why JavaScript?

The first half of the answer is about reach. Measured by which device, which operating system and which environment it will open in, the browser comes first by a wide margin. No compiler, no runtime install, no package manager; double-clicking the downloaded file is enough. On top of that HTML hands you the visual layer almost for free — no separate UI infrastructure is needed for the board, the clocks and the indicators, and the file even opens when <html>, <head> and <body> are never written at all. If the distance the engine had to cover to reach a player were any longer, the 2.7 KB claim would mean nothing in practice.

The second half is about the language itself. JavaScript suits Golfstack far better than you would expect: it requires no variable declaration keyword, it imposes no mandatory skeleton of entry point and imports, and implicit coercion means the board's numeric encoding never forces you to write a cast. Arrow functions, the ternary operator and the comma operator working together let an entire function collapse into one expression with no braces and no return. Self-extracting packers are native to this language too; the packed form of the engine rests directly on that.

An objection follows from this: the browser is hundreds of megabytes, and it supplies both the JavaScript engine and the runtime. Isn't 1,815 bytes just a play on words, then?

There is no such thing as a zero baseline. Written in C it would need libc and an operating system; written in assembly, an instruction set and a machine. A measure that also counts the runtime has nowhere to stop; measured that way, no size claim could be made in any language. Code golf therefore always draws the line in the same place: the code you write and the libraries you pull in count; the environment and the baseline do not. Neither the browser nor the operating system nor the processor goes on the tab. Cross-language comparison is done on this measure, and record attempts are open to any language.

Anyone who takes the end user's view and wants a stricter measure is also right: same environment, same language, zero libraries. Both are legitimate, and under both a single file stands on this side of the line — nothing downloaded, nothing bundled, nothing added.

The “smallest in the world” claim rests on that measure. I have been looking for a good while and have not come across anything smaller that enforces every official rule, in JavaScript or anywhere else. The claim is falsifiable, and it should be: it falls the moment someone ships something smaller. Until then it stands.

The second question is harder: why is there no AI opponent in the main build?

The usual route is clear enough. A board is drawn on the screen, the pieces are set out, and the player takes on a bot that plays a little better than random; the great majority of attempts so far have run along that line. The code-golf world has chess bots squeezed into a few hundred bytes, but to make room they give up almost every rule that forms the backbone of the game — castling, en passant, the 50-move rule, 3-fold repetition. Bot logic inflates the code considerably; a build where two people play is far cheaper in byte budget. And adding a bot contributes nothing to FIDE compliance.

The real issue is measurability. What counts as a bot is vague: is the thing that fits under 100 bytes and plays random but legal moves a bot? Is one that counts material a bot, or is the threshold higher? Who decides? Rules are not like that; they are exact. Whether a piece of code implements an article is visible on inspection and leaves no room for argument. I tried writing a bot along the way too; then I put all my energy into the side that can be measured.

The two stand apart in the code as well, and that is no accident. The engine core knows nothing about the driver, so putting a search on top does not touch the rule side. That is exactly how the build with a bot came about: the same rule layer, the clock and the interactions between players left out, a search on top. Its measured strength is around 2400 Elo. I do not consider it finished, because the criterion I have set for bringing a bot here is the same one the arbiter engine had to meet: it has to be a masterpiece in ratio of bytes to quality. That is a longer job — but since it is a hobby I enjoy a great deal, I will make a concrete attempt at a record on that side too.

What remains is what the measurable side bought: at 1,815 bytes this build is ahead of the large platforms on the hard half of the draw. The common practice, even where pure FIDE is applied, is to stop at the material test: is there enough left on the board to mate with. The side that looks at the position itself — whether a mating position can be constructed once the flag has fallen, and the detection of blocked positions — is not common. And that has been measured: CHA-Solver scanned a large public game database end to end and counted around 200,000 wrongly decided games — 50,000 of them from blocked positions, the remaining 150,000 from the question that goes unasked at flag fall. Chess.com applies a FIDE-USCF hybrid for some articles; not a shortcoming but a choice, blending the rules of two federations deliberately. The choice here is a different one: one book, one measure. On those same articles the engine is therefore bound more tightly to FIDE.

Chess projects in the code-golf world generally compromise on the 50-move limit, 3-fold repetition and insufficient material — often on castling and en passant too — and focus on the basic core alone. I looked at the side hardly anyone visits, and I think that is exactly where the project's originality came from. As far as I know, Golfstack is the world's smallest complete arbiter engine able to fit the full 100% FIDE standard into a byte space this narrow.

It is not a commercial product and makes no such claim. But layering all the rules of chess this way and fitting them into the fewest bytes is pure engineering, pushing the limit on the code side.

Getting to this point I had substantial help from models like Claude and Gemini. Work that would normally take months — debugging, code optimisation, picking apart browser behaviour — I compressed enormously with those tools. The decisions stayed mine; what I gained was speed.

As Chekhov put it: writing long is easy, writing short is the hard part. In this project I tried to turn that vast world of chess into its shortest form without losing anything of its function.

This exception does not ask “can the opponent force mate?”; it asks “can a mating position be constructed with this material?” Because the losing side can help by shutting off its own king's escape squares with its own pieces, the defender's material counts too — the mechanism is the same one as in a smothered mate.

Mate with a lone knight can only be constructed if the defending side owns a piece to wall itself in with — a bishop, a knight, a pawn, even a rook. A defending queen cannot do the job, because from every square where it could close the escape in the corner it simultaneously attacks the mating knight. What makes a defending pawn sufficient is promotion: the article allows any series of legal moves, so the pawn can turn into the piece that does the shutting in.

These are constructible positions, not forced wins. None of them is a winning method; they are only the answer to “does mate exist at all with this material?”, and that is exactly what 6.9 and 5.1.2 ask. Dead positions that do not rest on material — a locked pawn chain, say — are detected separately, as long as only kings and pawns remain; seeing those took a search, not a scan.

FIDE article 5.2.2 reads as follows: when a position arises in which neither player can checkmate the opponent's king by any series of legal moves, the game is drawn. Such a position is called dead.

The form of this condition that arises from insufficient material is fully implemented; the two tables above describe exactly that. The second form — blocked positions, where the material is sufficient but mate is impossible all the same — is now implemented too, in part. When only kings and pawns are left on the board, the engine decides whether the position is blocked. Measured coverage is 93%; every one of the remaining 7% involves a bishop.

The direction matters as much as the number: there are draws it misses, but none it invents. Every position it calls dead really is dead. Anything it does not recognise it plays on, so the margin of error always falls on the safe side.

The diagnosis was this: a blocked position is not revealed by any inference from the board layout or the state variables. The rest of the engine is not like that — everything else can be settled with geometry and arithmetic, in a way that is both sound on every diagnosis and complete across every case. Here a scan was not enough; it took a search.

The search was written. Eight bitboard masks grow the squares the pawns and kings can reach, step by step; when no mask grows any further, the position is blocked. Sixty-four squares and eight masks put the worst case at 512 steps, and the loop stops at 600 — so the bound is proved, and the search is never cut short. 488 bytes in total.

That search has been done. CHA-Solver decides with mathematical certainty whether a position is winnable; the algorithm was published in a peer-reviewed paper, it is open source, and it has been run across the entire Lichess database. As of 8 August 2026, when this was written, it has identified around 200,000 games that were decided wrongly, 50,000 of them from blocked positions and the remaining 150,000 from the question that goes unasked at flag fall. So soundness is a solved problem — the answer it gives is never wrong.

What is not solved is completeness, and the difference is not a fine one. The tool's own documentation says so plainly: complete on every known legal position, real or constructed, but not proven complete in theory — and it invites you to find a position it cannot resolve. That is not a flaw; it is the kind of problem this is. Induction rather than proof: CHA too kept refining its implementation against the counterexamples that arrived after the claim, closing each position it had missed. In the other articles of the book the boundary is drawn by proof; here it is drawn by measurement.

An extension covering nearly all of the bishop cases was designed and measured: it would have taken coverage from 93% to 99.94%. Even golfed it came to close to 1,000 bytes in plain form, and it was shelved.

The arithmetic runs like this. The detector in place buys 93 points for 488 bytes; the extension a further 7 for 1,000. The return per byte falls by a factor of 27. And what it buys is a subset of a position class that is already rare — the exception to an exception. In an engine of 1,935 bytes 1,000 bytes is more than half the program again; packed, it would take numerical_packed.html from 1,815 bytes to about 2,600.

And 99.94% is still not 100%. It is a measured figure, not a proved bound — 1,000 bytes does not buy completeness, it only pushes the shortfall into the decimals.

So the rule is shelved, not lost. Size and certainty are both measured on the engine itself tab.

How long the miss actually lasts has been measured too. In the position below each side has exactly one legal move — the white king shuttles between a1 and b1, the black king between a8 and b8, both bishops are shut in by their own pawns, and no pawn can move at all:

The engine cannot see this as dead, because there is a bishop on the board. But the game ends on the sixteenth ply by five-fold repetition: the same position returns every four plies. The code that comes out is 5R rather than DP, and both are draws. The cost of a blocked position going undetected is not a hundred and fifty plies but, more often than not, sixteen — being blocked is what makes mobility collapse, and that is why the repetition arrives early.

The target was never 100%, and could not have been. It was to cover more than 90% of the blocked positions that actually occur and to say plainly what was covered; the measured result is 93%. The engine now declares a draw only where it is certain. What is common on the large platforms, even those independent of any federation, is to stop at the material test.

That is the whole of the deviation. The two exceptions for impossibility of mate, at resignation and at flag fall — 5.1.2 and 6.9 — are implemented in full, and each is reported as a result of its own.

One player's move is a ply; a move by each side together is one full move.

Checkmate takes precedence. If a move results in checkmate, the mate stands even when automatic draw conditions such as the 75-move rule or a 5-fold repetition arise on that same move. The same holds for claims: a draw suffix appended to a move is ignored if the move delivers mate. The instant the mating move is played, the game ends in a win.

How a game may end varies considerably by federation. Under USCF rules resignation is always a loss, whatever the material. There is no such thing as an automatic draw: 75 moves and 5-fold repetition produce no result, and a draw is awarded only if the 50-move rule or 3-fold repetition is claimed.

The real difference appears where flag fall meets material, and the two federations ask different questions. FIDE asks: is mate possible even if the opponent plays the worst moves available? That is the helpmate, the geometric possibility. The answer to that question can be both sound and complete; it can be derived from a one-dimensional board array alone — which is exactly what this code does. USCF asks something else: does the opponent of the player who flagged have a forced mate?

Up to a point the two give nearly the same result. But USCF can produce unwanted edge cases by calling a lone knight, a lone bishop, and sometimes even two knights insufficient material outright. Chess.com goes the other way on that article: if the player who flags faces a king and two knights, the result is a loss, not a draw. Over the board, spotting a forced mate is easy; achieving the same accuracy in a digital algorithm requires a search. Without one, cases such as a mate delivered by a single knight go undetected.

All eight use the same core. The differences are in the input format, in whether the board is drawn at all, and in the clock. Sizes are in bytes and cover the whole shipped file: the <script> wrapper, the 28-byte markup prefix of the L3 input family, and the BOM in the files that carry glyphs are all included.

If you are going to copy the source off the screen and paste it into a text file, there is one thing to watch: the L3 family and L3 prompt carry chess glyphs, so the file has to be saved as UTF-8. In Notepad, picking UTF-8 from the dropdown in the save dialog is enough — choose the variant with a BOM and the encoding is read from the file itself, with no guessing left to the browser. L3 input, L3 input_blindfold, L3 numerical and the three .js files are pure ASCII; there it makes no difference how you save them.

The measurement is the same in all five. The difference is in the rounding: L3 rounds the remaining time up, so 0:00 appears only once the flag has actually fallen, while the others that show seconds truncate. In the L3 input family the same rounding would have cost 10 bytes, since the two clocks are printed separately.

Anything other than playing a move is done differently in each build. In L3 each is a separate control; in the rest they all go through the same text field.

In no build does the engine narrate the state; what gets displayed is entirely the driver's choice, and the indicators multiply as the byte budget grows. Five builds report the state in text, two say almost nothing.

In the builds that carry indicators the line is built in the same order. L3's status line has the form a8-h8 C! M=0 R=1; L3 input and L3 prompt write the same fields above the board.

M= is the ply counter — the halfmove clock, in FEN and engine parlance. It resets on a capture and on a pawn move. At M=100 the 50-move draw can be claimed; at M=150 it is declared without a claim. The practical reading: if you see M=99 on screen, then the move you are about to play will fill the threshold provided it is neither a capture nor a pawn move — which is exactly what b2b3= in UCI is for.

R= is the repetition count. This is how many times the current position has been seen. R=3 opens the 3-fold claim; R=5 is an automatic draw. It is not a countdown but a value recalculated after every move: it drops back to R=1 as soon as the position becomes unique.

Both numbers carry two thresholds, and which one bites depends on the build. L2 has no button for asking a draw, so the claim-based R=3 and M=100 trigger nothing there; the game ends only on the automatic R=5 and M=150. L2_aybars_2400 has no player layer either, yet it still ends at R=3 and M=100, and deliberately so: the bot's search reads those same two thresholds internally, and raising the game's without touching the search would pull the two apart. A loose end, left visible.

C! says the side to move is in check — so on your own screen, always your own king. D? marks an open draw offer. In L3 input and L3 prompt the two share one slot and D? takes precedence; L3 does not write it at all — there the amber outline on the draw radio carries the same information for free. When the game ends L3 replaces the whole status line with the result code, while L3 input writes only into that slot — M= and R= stay put.

What to do in the builds without indicators. In both, keeping track of check, the counters and repetition is entirely up to you; the engine reminds you of nothing. The only channels left are the last-move log and the clock, and both carry more than you would think.

In L3 input_blindfold the draw suffix makes it into the log: if your opponent played e7e5= you will see [e7e5=] in the square brackets, so whether they offered or claimed is readable from there. The same goes for promotion — e7e8n lands in the log as [e7e8N], letting you verify what they actually promoted to without holding the board in your head. The side to move is not given, so you read it off whichever clock is running.

In L3 numerical the log is the raw input itself, so an opponent's draw request is read from the non-numeric characters in it: 1229asd is both a legal move and a request. A request without a move leaves no trace. The clock is two unlabelled millisecond counts — White on the left, Black on the right — and whichever is falling tells you who is to move. Since the clock only refreshes when the dialog opens, a numerically valid but unplayable input is the only way to refresh the display without triggering an offer.

Everything is done by clicking: the piece first, then the destination square. When a promotion square is reached a picker opens and the move is not complete until a piece is chosen; the clock keeps running meanwhile. If you do not choose a piece you can cancel the promotion and play a different move instead.

The draw radio works independently of the move. If the threshold is already met on the board, ticking it triggers the draw directly; if your opponent has sent an offer, ticking it accepts the offer; if neither holds, the tick stays set and is evaluated when you play your move — a claim if the move meets the threshold, an offer to your opponent if it does not.

The format is <from><to><promotion><draw>. It is case-insensitive: E2E4, e2e4 and e2E4 are the same move.

The promotion letter is r, b or n. Any other letter — q included — and the absence of a letter both give a queen, so e7e8 is enough. Colour is the engine's own business; you only choose the type.

Castling is written with the square the king lands on: e1g1 and e1c1 for White, e8g8 and e8c8 for Black. There is no king-takes-rook form. En passant is written with the square the pawn actually arrives on, so it needs no rule of its own.

Draws use an = appended to the move. b2b3= means: if the threshold is met once I play this move, I claim; if it is not, I offer a draw to my opponent. The engine decides by looking at the state after the move is played; if the move resets the counter or makes the position unique, no draw results. = on its own claims the current position or accepts a pending offer.

Resignation is r. In L3 prompt, cancelling the dialog also counts as resignation; an empty Enter does not — it is an illegal move and the clock keeps running.

If a move delivers mate, a trailing = is ignored. Mate overrides the claim just as it overrides every automatic draw condition.

The same layout, with squares as two-digit numbers. The numbering is deliberately 1–64 rather than 0–63: a1 = 01, h8 = 64.

The promotion input is a digit: 0 bishop, 1 rook, 2 knight, 3 and everything else a queen. No letters — there are no letters anywhere in this build. Castling again uses the king's squares: White 0507 and 0503, Black 6163 and 6159.

The draw has no button of its own; the channel rides on the input itself. Any non-numeric input is a draw request. If the request happens to match a valid claim — the 50-move rule or threefold repetition — it ends the game there; if it does not, it passes to the opponent as an offer. Four cases follow:

Being able to attach the request to a move is not a convenience but a requirement of the handbook. In the case of “the counter stands at 99 plies, but playing this makes it 100”, or “the position has occurred twice and this move brings the third”, the claim rests on the move about to be played. That is why the channel travels with the move, and the behaviour follows 9.2 and 9.3 exactly.

The fourth case has a side benefit. The clock in this build is not live; it sits in the title of the prompt() dialog. Since numeric but illegal input reopens that dialog without triggering anything, it is also the only way to see the time remaining.

Resignation is a separate channel: Cancel, Esc, an empty Enter and leaving the tab all resign. 0, 00 and a space do not — all three are numerically zero, which makes them merely illegal moves. Typing r is not a resignation either; it contains a letter, so it falls into the draw channel.

The awkwardness of this interface is deliberate. The build was written for bytes, not for comfort.

There are fifteen ways a game can end; six decisive, nine drawn. The engine has two encodings and both name the same fifteen outcomes: L3 and the three UCI builds return a two-letter abbreviation, L3 numerical and engine.js an integer. Each cell shows both.

The abbreviations are self-explanatory: those beginning with W are wins for White, those beginning with B wins for Black. Those beginning with D, those ending in M, and any code carrying a digit are draws. All fifteen codes fall into these patterns; none is left outside.

The rows carry meaning too: the first concerns mate and stalemate, the second flag fall, the third resignation. The fourth row holds the draws that trigger by themselves, the fifth those that come at a player's request.

One naming choice is worth spelling out. DP carries the name of the article rather than of the case: 5.2.2 covers dead positions arising from insufficient material and blocked ones alike, and the engine reports both — measured coverage on the blocked side is 93%. Naming the code after the narrow half would have been the easy route; naming it after the article left the door open, and when blocked positions were added they did come out under the same code: the list stayed at fifteen.

These fifteen codes follow FIDE. Another federation's rules produce a different list. Under USCF, for instance, the 75, 5R and RM endings do not exist, and TM works quite differently. Adapting the engine to USCF is possible.

The board is a flat array of 64. Each element is one square, its value the code of the piece on it. The index starts at zero on a1 and ends at 63 on h8; i>>3 gives the rank, i%8 the file.

The piece code is type*2+colour. Bit zero is the colour — 1 white, 0 black — the rest is the type. An empty square is 0.

The type numbering is not arbitrary. The upper trio — pawn, king, knight — feeds G's ladder of P>3, P>4, P>5. In the lower trio the queen is the bitwise union of bishop and rook: 3 = 1|2. That is why the diagonal test h==v&P lets bishop and queen through together, and the straight test P>1 does the same for rook and queen. No separate branch for the queen was ever written.

The classification is square-centric: the information hangs off the square, not off the piece. The opposite pole is piece-centric representation — in a bitboard the information is scattered across bit sets split by piece type, so “what is on this square?” gets expensive while set operations get cheap. Here it is the reverse: a square query is one array access, b[i], four characters.

And it is flat: no border padding, no 0x88, no sentinel squares. The array is exactly 64, not one more. All of these were tried and eliminated; the reasoning is in a section of its own.

The engine without a front end. Pure state and functions; no DOM, no dependencies, no build step. One line, 1,935 bytes. The source below is the file in the builds/ directory itself, read as the page loads.

The 4x switch moves to a second source: engine_4x.js, the accelerated variant that enforces the same rules. 48 bytes longer and logically identical — the same moves at every depth, the same node counts, the same result codes. What it does differently, and the measurements behind it, are under a separate heading.

The perft switch opens the third: engine_onlyMoveGenerator.js, 727 bytes. Only the move-generating half of the engine — piece movement, castling, en passant, promotion and king safety. Everything else is gone; even the side to move is not state here, the driver carries it.

This file passes the whole suite: the CPW positions, van Kervinck's list, the Vajolet corpus, the move-list comparison against Stockfish. That is not a surprise but the point — not one of them asks whether the game is over. The 1,219 bytes engine.js carries beyond this file — the counters, the repetition table, the material test, the verdict — are called by none of those billion and a half nodes. Passing the tests proves the move generation correct, not the whole rule set; what covers the rest is a careful reading of the rule text. To run the suite at this level, ENGINE=./engine_onlyMoveGenerator.js is enough.

The whole file amounts to thirty-six names: fifteen state variables, fifteen functions, six scratch globals. Every remaining letter is a function parameter, and so free for a driver to reuse. All of them are below.

The naming is not arbitrary. Most names are the initial of an English word — A apply, G geometry, V vulnerable, M move, d distance, i initial, f final — and in the tables below that letter is bolded inside the word it comes from. A few follow a different logic: n is the counting letter, k the one conventionally used for vectors, q and Q come from ℚ, x and y are coordinates, and z and Z sit at the end of the alphabet because they carry the end of the game. O is shaped like the zero it looks for, and $ like a hash.

Case carries a convention of its own: functions tend to take the capital, state variables and parameters the lowercase. It is a tendency rather than a rule — l and a are lowercase functions, R an uppercase table — but a bare letter usually tells you which kind of name you are looking at. And where both cases of one letter are in use, they often name the same idea at two levels: p the piece code and P its type, l the check test and L the legal list, c the castling rights and C the function that clips them, z the stored result and Z the function that produces it.

A driver does not need to know chess. Validate the click or the text input with L, apply it with A, then paint the screen. The remaining four are for the ways a game can end away from the board.

The side is everywhere the colour bit of the piece code. The clock is the driver's business — the engine does no counting; it only carries the U and N fields; decrement them on each tick and call F(side,0) when one reaches zero.

Three more things worth knowing. The engine sets itself up: the moment the file loads, the board, the side to move, the castling rights and the counters are at the starting position; there is no separate setup call. There is no undo: A only goes forwards. L takes a snapshot and restores it for its own legality trial, but does not expose that; a driver wanting undo must save b, e, n, t, c, R and $ itself — leave R out and the counter rolls back while the table keeps the entry, so the next move produces a wrong $. There is no FEN and no PGN: to set up a position, write to the b array directly.

Everything a driver reads in order to paint the screen is here. The only thing it has to write is the clocks.

You saw six of them above. The remaining nine are internal machinery; a driver need never call them, but they are necessary for reading the engine.

Six letters are global scratch — born inside a function, meaningless once the call ends: m the bishop square-colour mask, W the material weight, B the bishop colours of g that H holds while I runs a second time, r the square of the castling rook, O H's absence test, s the position key — the state — that A builds.

The remaining sixteen letters are all function-local; a driver can safely use the same names as globals. The “Where” column shows which functions in engine.js that letter appears inside.

Letters that never appear as identifiers in engine.js: E j _. All seven files are below.

What the letters mean is in the tables above. What is described here is the order in which those letters do what: which expression enforces which rule, which operator turns what into what, and which functions run in which order as a move is written to the board.

The whole file is twenty-three top-level declarations: seven of initial state, one alias — Q, a string — and fifteen functions; the fifteenth being a, itself an alias for Math.abs. The same fifteen counted in the table above.

Their order is not arbitrary — each function leans almost entirely on the ones before it. It looks forward in three places: G to both V and C, and L to M. Two of those are genuine mutual recursion, the third is just a lookup into a constant table; the detail follows below.

The engine has five layers. At the bottom is pure geometry: can a piece go from this square to that one — without asking what stands on the target or whether the king is left exposed. Above it, attack: is a square being attacked? Then legality: the layer that actually makes the move, tests the king, then takes the board back. Then adjudication: is the position over, and if so how? At the top, application: the three functions that make a move permanent, forfeit rights, advance the counters and return the result. A driver touches only this last layer.

The dependency is almost entirely one-way. It breaks in two places:

There is a third recursion, but it does not cross a layer: in its castling branch G calls itself to test whether the rook's path is clear.

The declaration that builds the board is a single expression:

Three steps. The template literal produces a 64-character string; the middle 40 characters are not written in the source but come into being at runtime from 10n**40n-10n**32n. The subtraction is really 10n**32n * (10n**8n - 1n), that is eight 9s followed by thirty-two 0s — exactly 40 digits. It has to be a BigInt: held in an ordinary Number, the same value would long since have fallen into floating point and had its digits corrupted.

The spread operator splits the string into 64 single characters, and map turns each character into a number. The trick here is precedence: + and - have equal precedence and associate left to right, so '0x'+u concatenates first — '0xd' for 'd' — and then -0 coerces that string to a number, whereupon JavaScript reads the 0x prefix as hexadecimal and yields 13. Written as +0 the concatenation would have continued and produced '0xd0'; no other conversion this short exists.

In the resulting array index 0 is a1 and index 63 is h8.

The remaining initial state is seven declarations: c=15 leaves all four castling rights open, e=-1 means no en passant square, t=1 puts White to move, and z=n=o=0 zeroes the result, the 50-move counter and the offer bits. U=N=600 sets up the clocks, but the engine never touches them; they belong to the driver. Y is never read again — it is there only to complete the signature. a=Math.abs saves 10 bytes over its three uses; Q='indexOf' does the same job for array search, again over three uses, for 3 bytes. Neither is chess state — both are aliases any project could use.

The last declaration builds the repetition table with the starting position already seen once:

The key has four parts: the array itself converted to text — sixty-four numbers, comma separated — followed by the side to move, the en passant square and the castling mask, with no separator. The absence of a separator looks at first like a collision risk, but what closes the risk is a chess rule itself: e is either -1 or a square in the 16–23 / 40–47 range, that is always two characters. Since the side to move is one character, the key always reads as “one character side, two characters square, the rest mask”. That the en passant square can only arise on the third or sixth rank is the only thing that guarantees this parse.

G(i,f,T) answers a single question: can the piece on square i reach square f as far as the geometry of the board is concerned? It does not look at whether one of its own pieces stands on the target, nor at whether the move leaves the king exposed. Both are the business of the layers above. It is the engine's longest function: 270 bytes, close to a quarter of the file.

The third argument T is attack mode. When set, three things change: castling is switched off (castling is not an attack), the pawn's diagonal square counts even with no piece on it (the pawn attacks that square), and the pawn's straight push is switched off (a push attacks nobody). So G(i,u,1) means “does this piece attack this square?”

Because default parameters are evaluated before the body and from left to right, G's header does the work of a let block without spending the keyword. By the time the body starts running, the whole geometry has been derived:

P is the piece type, g its colour, y the rank of the origin square, and h and v the absolute horizontal and vertical distances. Three of them are interesting:

For the knight d and k come out meaningless — 1|2 is three, and dividing by three gives an absurd vector — but the knight branch never reads either. The same holds for pairs whose geometry fits no piece at all: when S lands on a fractional or off-board index, b[i] is undefined, undefined<1 is false, and the walk stops immediately. The infinite loop is not prevented by anything written; it is absent because it is impossible.

The body is a single ternary chain. The ordering descends by type number from high to low, and the last branch of the chain gathers three pieces at once.

Knight. h*v==2 — if the product of the distances is two the move is an L, because the only integer pairs giving two are 1×2 and 2×1. One multiplication instead of an eight-direction table.

King. Two branches. The first is d<2: one square in any direction. The second is castling, with every one of its conditions in a single chain. T|v|h^2 gathers all three conditions into one expression: in attack mode, off the rank, or with h anything but two, castling is out and the ordinary king move d<2 applies instead. Then the rook's square is worked out:

The rook stands three squares away on the kingside and four on the queenside — that asymmetry is closed by 3.5 and 0.5 rather than by a ternary. Then c&C(r) tests that the rook's right is still in the mask, G(r,i) that the rook finds a clear path all the way to the king's square — recursion, and the way b1 is also tested for emptiness on the queenside — !V(i,g) that the king is not currently in check, and !V(i+k,g) that the square it crosses is not attacked. The square the king arrives on is absent here, because L's legality filter already catches it: when the move is made and the king queried, an attacked destination square is eliminated by itself.

Pawn. Direction first: f<i^g. Since < binds tighter than ^ the expression parses as (f<i)^g — White (g=1) must increase the index, so f<i has to be false and the XOR yields one; for Black it is the other way round. Then two branches, split on h: if the file changed it is a capture, if not it is a push.

Sliding pieces. The last branch of the chain handles bishop, rook and queen together, and does it by reading the type number as a capability bit field. Bishop 1, rook 2, queen 3 — in binary 01, 10, 11. Bit zero means “can move diagonally”, bit one “can move straight”.

In h==v&P the comparison binds tighter than &, so the result is (h==v)&P: bishop and queen pass, the rook falls at 1&2=0. In the straight test P>1 takes rook and queen and leaves the bishop. Which direction either piece may move is written down nowhere — it sits in the numbers themselves.

The & S() at the end of the branch forces the path to be clear. If the geometry does not fit, the left side is zero and the product stays zero whatever S() returns; the verdict does not change.

The geometry layer knows one piece. The attack layer asks the whole board.

V(u,s) asks: is square u attacked by the side opposing s? The filter is p%2^s — the XOR of the piece's colour bit with s, which is one when the colours differ. Then G(i,u,1), in attack mode. some stops the moment it finds the first attacker; a full scan happens only when the square really is safe.

Empty squares leak through the filter — 0%2 is zero, and with s=1 the XOR gives one. The reason this is harmless lies a layer below: on an empty square P is zero, so G falls into its last branch, where h*v?h==v&0:0>1 is zero under every condition and the result does not change.

l(g) is a one-line wrapper: it finds the king with b[Q](10+g) — type 5, hence code 10+colour — and asks V about that square. The king's position is stored nowhere; it is searched for afresh on every call. A cache would have to be updated on every move, and that update would also have to stay correct across the moves L takes back. Searching is cheaper.

Geometry looks at the shape of a move, legality at its consequence. Between them lies one rule: a move that leaves your own king exposed cannot be played. There is no short way to test that statically, so L actually makes the move, asks about the king, and takes the board back.

The accumulator q is born as a default parameter, so no further let is spent. The filter !p|p&1^g requires the target to be empty or to be of a different colour — since & binds tighter than ^, which binds tighter than |, the expression parses as (!p)|((p&1)^g). This eliminates both moving onto your own piece and the case where f equals i, without geometry ever running.

The real subtlety is in the backup. The state is written as the triple [b,e,n] over the p parameter — over the letter that held the target square's contents a moment ago and whose work is done. A global backup would be corrupted here, because M calls L back while setting the en passant square, and that inner call would write to the same global. That the backup lives on the call stack, inside a parameter, is not elegance but necessity.

The board is cloned by spreading; e and n are numbers, so saving them by value is enough. M(i,f) is called without specifying a promotion type, so the default queen is used — irrelevant to legality, because whether the king is left exposed depends on the destination square being occupied, not on the type of the piece standing there.

M writes the move to the board and does nothing else: it does not flip the side to move, does not touch castling rights, does not write to the repetition table. The reason is that L calls it as a trial — a move that will be taken back must leave no permanent trace. Everything permanent lives one layer up, in A.

The fifth step is this fastidious because of the repetition table. Since the key contains e, writing an en passant square nobody could use would drop the same position under two different keys and silently miss a 3-fold claim. FIDE's definition of “the same position” includes the available moves; this line is that definition to the letter.

Because the neighbour search uses f-1 and f+1, it can spill across the board's vertical edges. That is harmless: the spilled square is at the opposite end of the a- or h-file, and L(x) will never generate a move from there to e — G's pawn branch does not count a seven-file horizontal difference as a diagonal capture.

The four castling rights are four bits in c. The function that says which square forfeits which bit is 27 bytes:

Two steps. i%56 folds the first and eighth ranks onto the same eight indices: a1 and a8 to zero, e1 and e8 to four, h1 and h8 to seven. The 48 squares in between land in the 8–55 range, that is outside an 8-character string — where undefined is read. The string itself is a table: character zero is '2', character four '3', character seven '1', and the remaining five are '0'.

Then <<i/28. The shift operator coerces both of its sides to integers: '2' becomes two, '0' becomes zero, undefined becomes zero; and the right-hand side comes out 0 on the first rank and 2 on the eighth. The result is four bits:

That the king's square forfeits two bits at once is the whole of the '3' in the string. And all the forfeiting is one line in A:

The origin square says the king or a rook has moved, the destination square says a rook has been captured on its own corner. Two separate rules, one expression. Since irrelevant squares return zero, their complements are -1 and leave the mask untouched — no condition needs writing.

I(g) scans the board once, fills two scratch globals and answers a single question: can mate be constructed with this material?

Called with g>1 the colour filter drops away and both sides are counted at once; that is how Z uses it. Bishops are kept separate because it is not their number that matters but their square colours: (i/8^i)%2 takes the last bit of the XOR of rank and index, that is the colour of the square; +1 makes this 1 or 2 and it is or-ed into m. Five bishops of the same colour still light one bit, while one bishop of each colour makes m 3.

Every other piece writes a score into W, and the threshold W*2+m<3 fits all of FIDE's distinctions into one comparison:

Scoring the knight one, the bishop one per square colour and a heavy piece nine looks arbitrary, but its only purpose is to cut this table in the right place. The threshold distinguishes just three things: whether W is zero, one, or greater than one. That is the only constraint on the heavy piece — it must not weigh less than two knights, so at least two. Every digit from two to nine gives the same verdicts and every one of them costs a single character; nine is chosen because it is the queen's conventional value, which lets W read as material weight rather than as a counter.

When I finishes, m and W are left readable, and H uses exactly that:

O(u) means “g has no piece of type u/2” — O(4) rook, O(8) pawn, O(12) knight. Then I runs twice: the first only for its side effect, because B=m has to save g's bishop colours; the second for both its return value and its side effect. After the second call, m and W now describe the opponent's material, and the rest of the condition reads those two letters that way.

What is being asked is not whether the opponent can mate but whether mate is possible — that is, whether a mate could arise even if g plays the worst moves available. The three sub-tests correspond, in order, to: against a bare king no arrangement gives mate; if g has a knight or a pawn, mate can be constructed, because that piece can shut off its own king's escape square; and g's bishop only matters if it is on the same colour as the opponent's, in which case neither side can ever touch the other's squares. The rule itself and a case-by-case breakdown are in the rules section.

The material test asks whether mate exists at all with these pieces. Article 6.9 asks something narrower: can mate be built from this position. The material may be more than sufficient while the position forbids it outright. X is the search that closes the gap.

What it asks is exactly what the article asks: can the side that flagged or resigned be mated by its opponent through any series of legal moves. It looks for a helpmate, not a forced mate — can a mating position be built even with the losing side helping.

There are three gates. H(g) leaves at once if the material already falls short. Xs leaves if the position has been searched to at least this depth before — the table stores a depth, not a yes or no, because a shallow result satisfying a deeper query would quietly falsify the search. J(0) leaves if the position is blocked.

Its neatest turn is the third parameter. v=t^g|!l(g) is a leaf test: if it is not g to move, or g is not in check, there is no mate here. When both are false and no legal move was generated anywhere on the board, v keeps its default and comes out zero — a mate has been found. The mate test is never written as a branch of its own; it is folded into a parameter default. The same line separates stalemate: no move, but g not in check, and the answer is true — no mate down this branch.

The undo sits inside the expression too. In X(g,d-1)|([b,e,n,t]=w) the array assignment falls to NaN as an operand of | and contributes nothing, so the recursion's answer passes through untouched.

The search sees more than mates; it sees every ending that arrives before one. Where a forced capture leaves the material short, H closes the branch at the next node. If the ply counter fills during the search, n>149 takes over. There is no separate counter for repetition, but Xs cuts a branch that returns to a position already searched — that is how forced repetition reaches its result. If the budget runs out, v is zeroed and the answer becomes mate is possible: an impossibility that cannot be proved does not count as a draw.

The visible consequence is this. A queen has driven you into the corner and given check, your flag falls, but your only legal move is to take the queen and two bare kings remain — you do not lose, you get TM. The converse is stranger still:

White is in check and has exactly one legal move: Qe3xg5, and that move is mate. But there was no time left to play it. Black still has a queen, so H has nothing to say about the material. X settles it in a single node: White's only move mates Black, so Black never gets a turn, and therefore cannot mate White by any sequence at all. The result is TM — a draw.

Article 6.9 asks whether your opponent can mate, not whether you can. The game ended when the flag fell, and the winning move was never played.

I looks at the material, X at the search. Between them sits a third question: the pieces may be sufficient and the search may still find nothing — because the position is blocked. J is the scan for that.

The gate asks two things: is an en passant right standing now, and did anything irreversible happen in the last two half-moves. Both are matters of chess, not of code.

The first is a silencer. While an en passant right stands the position cannot be dead: the capturing pawn lands on the file the opponent has just vacated, and its path there is permanently clear — promotion is possible, mate is possible. The detector's model cannot see that sideways jump, because its advance set grows vertically only; so it is not allowed to rule at all. “Where there is en passant there is no lock” is not a guess but a provable proposition.

The second is a trigger. A position can only pass from live to dead through an irreversible move: either a pawn advanced or a piece was captured. A king move is reversible and can destroy no possibility for good — the king can walk back. A pawn move and a capture are exactly the two things that reset n. So the natural trigger is n=0.

On its own it is not enough, and the reason is the first point. An en passant square arises from a double push, and a double push is a pawn move — so the ply on which n resets is precisely the ply on which the silencer is in force. The moment the trigger should fire is the moment the detector is forbidden to speak. The ruling has to be deferred by one ply: look again once the en passant right lapses. At that moment n is one. So the rule “look again when en passant lapses” needs no bit of its own; widening the n=0 window by one ply covers it. Together they come to n<2.

The same reasoning covers check. Because the scope is kings and pawns, there is no sliding piece on the board; with no slider there is no discovered check, and a king cannot give check itself. One possibility is left: a pawn move gave the check. That resets n, and the escape makes it one. Inside the window again. The alternative was to carry a snapshot of the previous ply — was there a check, what was the en passant square — and all of that information is already sitting inside n.

J's parameter is a force switch. Z passes 1 after a real move and turns the window on; the 6.9 search passes 0 to say “judge this position as it stands”, because inside the search n counts the search's own moves rather than the game's, and the window has no meaning. The silencer stays in force on both calls. The parameter is named Y and shadows the global of the same name — that global exists only for the signature and is read nowhere.

Its scope is drawn by w. p-8>>2 lights up on anything outside the pawn and king codes, and the !w condition then keeps the search from starting at all. That single line is the whole reason blocked positions containing a bishop get away.

The fill binds to direction, not colour: W is the pawns moving toward increasing indices, B those moving the other way. That is why the flipped-board build only swaps the binding and never touches the body.

The loop grows four mirrored pairs. P/Q are the blocked pawns, C/Z the squares the pawns can still advance to, K/L the squares the kings can reach, r/q the ground each side controls. Every turn feeds them into one another: a king may enter neither a blocked pawn nor a square an enemy pawn covers, and a pawn may not advance onto a square an enemy pawn holds. When no mask grows any further, the balance has settled.

Eight masks across 64 squares put the worst case at 512 steps, and the loop stops at 600. So unlike X, no cut ever happens here — the bound is not measured but proved.

Six questions remain at the exit. Two are about promotion: can White reach the eighth rank, can Black reach the first. Four are about capture: do the diagonal neighbours of the advance squares touch an enemy pawn or the ground an enemy king holds. If all six answer no, the position cannot breathe.

Every game-ending rule hangs on one question: does the side to move have a move it can play? If yes, the game can only end by an automatic draw; if no, it is checkmate or stalemate. Z is precisely the shape of that distinction.

The two halves of the dead position meet here under a single |: I reads it from the material, J from the structure. Whichever returns true, the code is the same — 6, because the article is the same: 5.2.2.

L(i)+'' is the shortest form of the empty-array test: an empty array converted to text is '' and counts as false, while a full one gives something like '28,24' and counts as true. .length is 7 characters, this is 3.

The mate code is t+1. If Black is to move (t=0) the mating side is White and the code comes out 1; if White is to move, 2. One addition names both outcomes.

The order of the branches is itself a rule. FIDE 9.6 says 5-fold repetition and 75 moves end the game in a draw — unless the last move was mate. Here that exception was never written, because mate lives inside the “no move” branch: on a mate with the 75-move counter full, the engine does not even look at the counter, because it never enters that branch. The precedence is not encoded; it is a consequence of the shape.

The cost of the distinction is asymmetric too. Saying “the game continues” ends as soon as the first legal move is found; saying “mate” requires trying every move and proving that none exists. Measured, the difference is this: a mating move makes Z generate moves for 48 squares; in the e2-e4 trace below the counter stopped at 33, because the scan ended the moment Black's first movable piece was found.

The two in I(2) is the argument that drops the colour filter — insufficient material is decided by looking at both sides at once. The filter p%2==t lets empty squares through as well, but since L returns an empty array for an empty square, the verdict does not change.

The first step gathers two separate rules into one expression. C(i) asks about the origin square: if the king or a rook has left its own corner, the right is forfeited. C(f) asks about the destination: if a rook has been captured on its own corner, the right is forfeited too. In castling both of these collapse onto a single square — C(e1) returns three, so both of White's rights go at once and the rook's own square is never consulted.

The third step must precede the fourth, because the repetition key has to describe the position after the move — and the side to move is part of that position. In the fourth step the left-hand side of the assignment is evaluated first, so s is already set to the new key when -~R[s] reads it. ~undefined is minus one, and negating it gives one: a position seen for the first time lands directly on 1 without any default write.

Two things A does not do are part of its definition too: it does not touch the clocks and it does not clear the draw offer. Both are driver policy, not rules.

The offer bits live in o: White is bit zero, Black bit one. 2-g selects between them with one subtraction. Called with no argument, 2-undefined is NaN, and o^=NaN leaves o as it was — so the same function can also be used to read the verdict alone, without disturbing the bits.

That the thresholds differ from those in Z is no accident. Fifty moves and 3-fold repetition are claimed; 75 moves and 5-fold repetition happen of themselves. FIDE puts the two in separate articles; the engine puts them in separate functions. What is optional goes in D, what is mandatory in Z.

g is the side that flagged or resigned, and k is zero for timeout, one for resignation. If X(g,15) is true, it is impossible for the opponent to mate and the result is a draw — 14 or 15. Otherwise the opponent wins and a single piece of arithmetic names all four outcomes: k picks timeout from resignation, g picks the side. 10 and 11 come from the clock, 12 and 13 from resignation.

The numbers below were measured by running the engine — a counter was attached to each function and the number of entries over a single A call was recorded.

The driver first validates the clicked or typed square with L(12), and if the target is in the list calls A(12,28). Inside, five steps run: the castling mask does not change (C returns zero for both squares), M writes the pawn to 28 and resets the 50-move counter, the move passes to Black, the new position is entered into the table once, and Z returns zero — the game continues.

The en passant square is not written. Despite being a double step, there is no black pawn on 27 or 29 to capture, so e stays at minus one. The same move, with a black pawn beside it, would have written the square.

The distribution sums up the shape of the engine. The move itself is almost free — one M, two C. Nearly all sixteen hundred geometry questions come from the last step: Z has to show that Black has a piece able to move in order to prove the game is not over, and it generates moves for 33 squares before finding one. The engine works not to make the move but to arbitrate.

Once the path is clear, L(4) returns the king's moves as [5, 6, 12] — f1, g1 and e2. g1 sits in the list like an ordinary destination; the driver never learns that it is castling, it merely clicks a square. Every condition for castling is tested inside G, before the target ever reaches the list.

In that single L call, C runs once and V five times. Two of the five come directly from G's castling branch — that the king is not currently in check and that the square it crosses is not attacked. Queenside castling is never even asked about: with the bishop still on c1, L's filter eliminates the target before it reaches geometry, which is why C is not called a second time.

Then A(4,6): C(4) returns three and the mask drops from 15 to 12 — both of White's rights go in one step. M's fourth step fires, the rook moves from h1 to f1 and h1 empties. The measured final state: white rook on f1, white king on g1, h1 empty.

In the sequence 1.e4 a6 2.e5 d5 the real work happens on Black's double step. M's fifth step fires: the difference is 16, the square is provisionally written as e=43 (d6), and then the two neighbours of the destination square are examined. There is a white pawn on 36 — 17-8 is looking for exactly that — and L(36) does generate 43. That generation is only possible because e has already been written; G's pawn branch performs the f==e comparison. The result: e=43 stands.

The same move, with no white pawn on e5, ends with e=-1. I measured both. The difference goes to the repetition table: had a square nobody could use been written, the same position would fall under two different keys and a 3-fold claim would be silently missed.

When White captures with A(36,43), M's third step comes into play: since f==e, the square to be cleared is 43^8, that is 35 — d5. The measured result is d5 empty, a white pawn on d6, e5 empty. And because this move is not a double step, the fifth step does not fire and e reverts to minus one.

The four text drivers call A as it stands: A(i,f,promotion), writing the returned code into z. The builds that draw a board redefine A and inline the five steps into their own body; in L3 the reason is that the clock increment has to sit in the very middle of the third step, at the moment the side to move is flipped. The engine's rule logic stands unchanged; the only thing inserted is U[t^=1]+=5.

Five separate tests arrive at the same result. H, I, J, the repetition counter and the ply counter all say the game is drawn. What separates them is how early and how cheaply they say it.

The net at the bottom is the 75-move rule: every blocked position falls into it eventually. Five-fold repetition short-circuits that, because being blocked is what makes mobility collapse and repetition arrive sooner. I and J short-circuit repetition by recognising the position on the first move. And H short-circuits X, never letting the search start when the material already falls short.

In principle X could subsume all of them. With unbounded depth and budget it would exhaust the reachable state space and prove the impossibility itself. But that has been measured, and the measurement is not encouraging.

Nothing in this position can cross to the other side. The pawns are blocked head to head with empty diagonals; each bishop is confined to squares on its own half; neither king can pass the rank the enemy pawns cover. It is a dead position. But there is a bishop on the board, so J is out of scope, and the material is more than sufficient, so H has nothing to say. That leaves the search itself.

The node count grows linearly with depth, not exponentially — and the answer never changes. The reason is in the design of X: every breaks on the first false, and when the depth runs out the leaf zeroes v and answers "mate is possible". The search walks a single line to the bottom, gives up there, and never opens a sibling.

So X can only prove impossibility when every line closes before the depth runs out. With the kings free, no line ever closes. What is needed is not a few times the budget but a depth on the order of the reachable state space — the product of king and bishop placements, tens of thousands of positions. That is exactly why the short circuits exist: J reaches the same ruling by a scan, without the search ever opening.

An extension covering nearly all of the bishop cases was designed and measured: it would have taken coverage from 93% to 99.94%. Even golfed it came to close to 1,000 bytes in plain form. In an engine of 1,935 bytes that is more than half the program again; packed, it would take numerical_packed.html from 1,815 bytes to about 2,600. The return per byte falls by a factor of twenty-seven.

And 99.94% is still not 100%. Even after adding it, I could never be certain of completeness — it is a measured figure, not a proved bound. Putting something I cannot be certain of into an arbiter engine weakens the guarantee everything else in it gives, and that guarantee is exactly what the tests measure. So the rule is shelved, not lost.

The engine's claims about the rules were tested with perft: the number of legal move sequences generated from a position down to a given depth, compared against published reference values. A deviation of even a single node means an error in the rule set, which makes perft the harshest test of an arbiter engine — it probes the whole of move generation, king safety, castling rights and en passant availability at once.

The comparison draws on four sources: the Chess Programming Wiki's published node counts, van Kervinck's list of tricky positions, the 6,838-position Vajolet corpus, and Stockfish. At shallow depths where no published value exists, comparison is supplied by a naive 0x88 implementation written directly from the rules that shares not one line of code with the engine.

The depths below are consolidated: where a position was split across several runs — to d5 first, then d6 and d7 in a separate run — it appears on one row at the deepest layer reached. Every position was also verified at all intermediate depths from d1 up to that layer.

Seven positions, including the colour mirror of the fourth. The mirror is not incidental: an error that breaks colour symmetry shows up only there.

Illegal en passant, castling out of check, a discovered check opened by an en passant capture, promotion and underpromotion giving check, the stalemate–checkmate distinction, evading a bishop pin. In ten of the fifteen positions the published depth was exceeded; since no published value exists at those layers, verification was done against Stockfish.

Hand-picked positions catch the edge cases; bulk runs catch what turns up in ordinary play.

The random-play run does not look at node totals, it compares lists. A total can match because two errors cancel each other out; the list comparison is there because it rules that out.

The tests run by default on engine_4x.js. To test engine.js byte for byte, ENGINE=./engine.js is enough.

All the numbers above are a single claim: the engine produces these nodes in these positions. You do not have to take my word for it to check.

The repository is public: github.com/cuneytinann/FideLite. To download the whole test folder as one file, use test.zip · 236 KB — it contains the suite, copies of all three engines, the Vajolet position list and eight double-clickable .bat files, and you need nothing else. On Windows, double-clicking the file is enough; on other platforms, node test.js <command>.

Five of the eight runs need only Node. The standard CPW positions, the Vajolet suite and the deep single-position runs compare against published values; no external engine is required. The quickest is 1-sanity-test.bat.

Two require Stockfish: the random-play simulation and the verifications that go past the published depth. One uses it optionally — the tricky-positions run adds a cross-check if Stockfish is present and settles for the reference values if it is not.

Stockfish is not in the package; on its own it exceeds 100 megabytes. Put your own binary in the test folder or add it to PATH; the suite looks in order at the STOCKFISH variable, then stockfish.exe on Windows, then the usual install paths on Linux and macOS.

For the places where neither a published value nor Stockfish is available, the package includes ref.js: a naive reference written straight from the rules that shares not one line of code with the engine. That the two arrive at the same number is proof of genuine agreement rather than of a shared bug. Its board is 0x88 — the architecture eliminated from the engine over bytes, and the most readable one where bytes do not matter.

The two engines are logically identical: the same moves at every depth, the same node counts, the same result codes. Perft d1–d4 from the starting position gives 20 / 400 / 8,902 / 197,281 in both. The difference is only in how many operations it takes to reach the same answer.

All 13 bytes go to four changes. The gain column below is each change's effect measured on its own — on the Z() call, the engine's hottest path, in the starting position, averaged across both sides to move.

Applying all four to engine.js in order gives a file byte-identical to engine_4x.js; there is nothing in between.

There was a fifth change, and it is not on the list because it now sits in both: L used to call the expensive G first and only then ask “is the target already my own piece?”, and the order was reversed. That swap is byte-neutral — G(i,f)&&!p|p&1^g&& and !p|p&1^g&&G(i,f)&& are both 18 characters — and on its own it brings 1.49×. It is applied in every shipped build. Being free in the source does not make it free in the packed output: because the repeat sequences RegPack sees changed, it cost a total of 3 bytes across the packed files of the day.

The third row is the most interesting on the list, because what it fixes is not slowness but asymmetry. The code for an empty square is 0, and in engine.js the scan conditions are p%2==t and p%2^s. Since zero modulo two is zero, those conditions count empty squares as Black's pieces. The consequence: with Black to move, Z() runs a full legal move generation for every empty square on the board, and with White to move it does not.

Measured, the difference is stark:

This is why “twice” is not a single number but a range that depends on the workload. Perft d4 from the starting position — where the great majority of nodes have White to move, the cheap side of the asymmetry — gives 2.4×. The same perft at d3, whose majority ends with Black to move, gives 9.7×. The two in the build's name is the good-case figure, not the bad-case one; a modest name, in other words.

The 13 bytes only repay themselves where the engine's hot path is permanently open. In a driver that takes its move from a human, the engine's microseconds are invisible next to the user's thinking time; which is why the measurement is run without a driver at all. engine_4x.js is embedded in no driver; its source sits under builds/, with a copy in the test bundle.

The four changes above are not a guess. A candidate list was measured, four survived, several were eliminated. What survived is written out one by one above; what follows here is what was eliminated and why.

Every number under this heading depends on method, and there are two easy mistakes in measuring speed — both of which inflate the gain.

The first is taking the best run. Run the same code 15 times and record the fastest and you have measured the most generous moment of the noise, and that generosity is not the same across builds. The second is the artificial bench: looping move generation over a handful of fixed positions leaves out the state management that runs alongside it in a real deep count.

Do both at once and the result does not merely shift numerically; it changes sign. The unmake line below showed an 11% gain when measured on a synthetic bench with the best run; with the median and a real perft, a 13% loss. The table is therefore perft d3 from the starting position (8,902 nodes), the median of 15 repetitions, each build in a separate process.

The overall ratio is not a single number, because the gain differs sharply from one function to the next. The measurement below exercises each function on its own, as the median of 7 repetitions.

One thing has to be said first: perft never touches X or J. Perft counts nodes, it does not rule; Z calls J and F calls X only when a game ends. The perft table above and the table below therefore measure different things — the speed of the move generator on one hand, of the arbitration layer on the other.

The gulf in J comes down to a single line. The 1x version runs a fixed 600 iterations for a reason of correctness — so that the bound is a proved one. The 4x version watches the sum of the masks instead and stops the moment none of them grows. In a locked position the balance usually settles in 15-20 rounds, so the 4x version never does 99% of the work. That is what 24 bytes buy.

That the gain stays near two and a half in L and X is the same reason inverted: the work done there is work that genuinely has to be done, and there is no slack to cut.

The timings were measured on the generation before the dead position and the mate-impossibility search; the byte column is written against today's engines, because none of the four experiments touches those two layers — their cost is the same whichever generation they are added to. All four were rejected, and the reasons have not changed since.

Hoisting the S closure out of the parameter list. G's last default parameter is a self-referencing closure, recreated on every call — before the first comparison in the body even runs. The theory was that the closure forced G's locals onto the stack on every call. +22 bytes, 8%. V8 handles the closure better than the theory assumed.

Bounding the target scan. Non-sliding pieces cannot travel further than seventeen in index terms — a pawn at most 16, the king 9, the knight 17. Putting a single guard in L and bounding the scan to that range for non-sliders is +25 bytes, 14%. The best ratio on the list, and a local bound whose correctness is provable from the piece codes.

True unmake. Restoring only the squares M touched, instead of L's reference-swap take-back; the copy path is kept for king moves, because the castling rook writes two more squares. +85 bytes, and slower. It allocates a 5-element array per candidate, whereas [...b] is a single bulk copy of a packed 64-element array. It is also the most volatile version measured — its maximum climbs to 1,806 ms, meaning it feeds the garbage collector.

On top of that, its correctness depends on knowing exactly which squares M writes to. In the first version the restore square was held in a global, and because M's en passant branch calls L again from the inside, the inner call was overwriting that global: the outer call restored the wrong square and the board was silently corrupted. Every new write added to M would recreate the same bug.

The same lesson turned up one step beyond the map → forEach change: replacing forEach with a hand-written for loop is +19 bytes and 10% slower. Intuitions carried over from C — bulk copies are expensive, hand loops are fast — do not hold in JavaScript.

Unmake once measured far better than this, and that measurement was not wrong either. Before V's empty-square scan was fixed — the p&& precondition above, 6.34× on its own — board copies were a far larger share of a far larger total. Measured before and after that fix, the same edit looks like two different optimisations.

Order matters when you credit a gain to a change: what you are measuring is not the change itself but its share of the bottleneck at that moment.

The gulf in ratios shows up in a single line. From engine.js to engine_4x, 13 bytes bring a tenfold gain. The best candidate after that is 16% for 47 bytes. A hundredfold difference per byte.

The profile says why. In the opening position a full scan makes 768 shape probes, and 97% of them are rejections — all at the first comparison. The rejections break down as 50% pawn, 31% slider, 12.5% knight, 6.3% king, which is exactly the material count. Measured again ten moves later it is the same, because the scan is uniform: every piece, whatever its type, receives the same number of target probes. Speeding up a particular piece has no surprise payoff in any position.

There is nothing left to trim. Beyond this point means narrowing the scan space — target lists per piece, that is, move tables — and that road was already measured and eliminated; it costs kilobytes.

The goal was an engine that is fast without breaking Golfstack. engine_4x is that. What comes after neither speeds things up enough nor earns its bytes.

The 13 bytes above belong to the engine's base and are still exactly that. When the dead position and the mate-impossibility search arrived, the gap grew to 48; the 35 bytes in between come entirely from the fast variants of those two functions.

The check test moves to the leaf. In the 1x version the leaf test is the default of the third parameter, v=t^g|!l(g). A default runs on every call — including nodes that leave at once through H, the Xs memo or J. And l(g) scans the board. The 4x version writes v=0, which costs nothing, and moves the expression to the end, inside &&(v||t^g|!l(g)). On every early exit the check test never runs at all. +5 bytes.

The empty square short-circuits. !p||p%2^t instead of !p|p%2^t. When the square is empty the colour comparison is never made. +1 byte.

The promotion test starts with the cheap half. (f%56>7||p>>1^4) instead of p>>1^4|f%56>7. The destination not being on the last rank is both the cheaper test and the far more common answer, so it goes first under ||. +3 bytes.

The undo returns a number. ([b,e,n,t]=w,0) instead of ([b,e,n,t]=w). The 1x version relied on the array falling to NaN under |, which means turning the array into text and then into a number on every node. A literal 0 does the same job for free. +2 bytes.

The counted loop becomes a fixed point. This is the single largest gain in the engine. The 1x version runs 600 iterations through X=k=>k&&(…,X(k-1)), so that the bound is a proved one. The 4x version takes one more local — o=W — and compares the sum of all the masks at the end of every round: X=_=>(o^(o=C+Z+K+L+r+q-P-Q))&&(…,X()). The moment the sum stops changing, it stops. In a locked position the balance usually settles in 15-20 rounds, so the 4x version never does almost any of the work. The measured gain is 37×.

The fill allocates nothing. b.every instead of b.map. map allocates a fresh 64-element array on every call and throws the result away; every allocates nothing.

That is what 24 bytes buy. The rest of the rule's text is byte for byte the same in both versions — the only thing that differs is when it stops.

The engine's board representation is a flat, square-centric array of 64. No padding, no 0x88, no bitboards. That is not a default — it is what was left over. Everything below was either written or measured, and all of it was eliminated.

The first idea was to define movement by absolute distance: the Pythagorean distance from one square to another on a discrete plane. A small simulation was written that drew an empty 8×8 board and measured every distance from a chosen square, and at first glance the formulas looked flawless — the knight always √5, the king between 1 and √2, the rook the integers {1…7}, the bishop the multiples of √2 {1√2…7√2}, the queen the union of the last two.

The knight and king really are clean. In an eight-square space the only shape giving d²=5 is (1,2); the knight owns √5 outright. The shapes giving d²≤2 are (0,1), (1,0), (1,1) — the king has no rival either.

The rook and bishop are not. In the whole distance space there are exactly two collisions:

The 3-4-5 triangle impersonates the rook's fifth square, and (1,7) the bishop's fifth. The queen inherits both. Distance alone cannot define a legal move.

The second problem is more fatal: distance has no direction. The square root swallows the sign, and the pawn is the board's only one-way piece. No patch could have saved the Euclidean approach for the pawn.

The solution was to throw away the square root: keep the horizontal and vertical differences apart. The engine's present h and v come from here, and one move closed both problems at once — the collision, because (3,4) and (0,5) are now two different pairs; and the direction, because f<i^g carries a signed comparison. The residue of the abandoned approach is still visible: h*v==2 is the knight, h|v<2 the king, h==v the bishop, h*v==0 the rook. The distance went, the shape stayed.

Once distance had turned into shape, the next question was: could the shape test go too? Reading legality from the raw index difference between i and f, or from per-piece move-vector tables, was tried.

The difference between the two formulations is not merely speed but kind. The chosen road scans: for a source square it walks all 64 targets one by one and asks each “is this shape legal?” The delta road generates: the piece type carries its own direction list and produces targets with f = i + offset. Whether each generated target is actually on the board is then a separate question — with the knight on h2, +10 throws you to the other side of the board.

On a flat 64 that question goes unanswered. The delta is ambiguous at the edge: +1 means one to the right, but on the h-file it wraps to the a-file of the rank above, and the diagonals' +7 / +9 and the knight's +6/+10/+15/+17 do the same. Removing the ambiguity requires adding |i%8-f%8|, which is just h again; so on a flat board the delta road falls back into the shape test. Delta only acquires meaning on a padded board: 0x88's 128 cells or the sentinel border of a 10×12 mailbox absorb the wraparound and make the difference unambiguous. That is why the two were tried together.

Both came out noticeably larger, and the reason is simple: in this engine there is no problem for padding to solve. G works from-to and generates no offsets — L walks the targets with b.map, so f is not generated but an already existing square. With no arithmetic that could leave the board, wraparound is impossible too; across a full scan in the opening position, the number of off-board indices reaching G is zero. The only exposure is S's ray walk, and that closes for free: b[i]<1 is false for undefined.

What is more, in this scheme padding does not remove a test; it adds one. Under 0x88 the array grows to 128 cells, L walks 128 targets and has to filter half of them out — a check that does not exist at all on a flat 64. The initial literal doubles as well. The free edge test that padding sells finds a buyer only in a move generator that emits offsets; here no offsets are emitted.

The cost of scanning is not as heavy as one might suppose either, because it is not a separate loop: L walks b anyway while building the move list, and b.map reads the piece code and supplies the target at the same time. In the opening, a single Z() call runs G 192 times — the theoretical ceiling is 4096, and early exits close the gap.

The trade would also have been incomplete. A delta table could only have replaced G's shape half; whether a sliding piece's path is blocked still has to be tested by walking, because blocking is a question independent of the representation. So the cost of the padding and the table would be paid and S would remain. The structure that survives is therefore flat 64 + G's shape test + S's linearity walk.

The converse is not true: a padded board does not require vector tables, and h / v could have run on top of 0x88 too. But the only reason to pay padding's cost is to use deltas. The two were not eliminated separately; they were eliminated together.

This section's thesis rests on two words: square-centric and array. Each of the two alternatives tried rejects one of them.

Bitboards give up square-centricity: the information is spread across 64-bit words split by piece type, each bit saying “is there a white pawn on this square?”. Set operations become cheap — you get the attacks of all white pawns in a single mask. In exchange, “what is on square 12?” gets expensive; you have to test each word separately. A packed integer, by contrast, preserves square-centricity and only changes the container: the same 64 digits, inside a single number rather than an array. The data model is identical, the access pattern different.

Both are forced to the same place: BigInt. 64 squares × 4 bits is 256 bits, far beyond Number's 53-bit integer precision. So both roads pay JS's BigInt tax — an n suffix on every literal, an explicit conversion in every mixed expression, and a TypeError the moment you mix BigInt and Number with +.

Where the cost accumulates is measurable. engine.js touches the board in the form b[…] in eighteen places — 13 reads, 5 assignments — and walks it a further 6 times with map, some and indexOf. As an array, b[i] is four characters; packed, the same read wants a shift and a mask, roughly 25. That is a difference of over 200 bytes on the reads alone, and the walks have no direct equivalent — all six turn into hand loops. On top of that, bitboards add attack tables.

What makes these models cheap in C or assembly is 64-bit arithmetic being free at the processor level. JavaScript offers no such ground; far from gaining, both attempts added hundreds of bytes. Worse, both would have changed the engine's entire skeleton and returned a pile of hard-to-manage algorithmic unknowns in exchange — the wrong direction of trade in a project that trades speed for size.

The irony is that BigInt stayed in the engine, but in a completely different job. The starting board is built with 10n**40n-10n**32n: the expression produces a 40-digit number — eight 9s, then thirty-two 0s — that is, the white pawn rank and the four empty middle ranks. 20 characters in the source, 40 in the string it produces. A 20-byte gain. BigInt was eliminated as a board representation and kept as a literal compressor.

The en passant square is a global of its own: e, a square index, -1 when there is none. Marking it on the board instead of keeping it apart was tried. The idea is clean: the position becomes the single source of truth, the repetition key shortens from b+t+e+c to b+t+c, and a letter comes free.

The half-nibble encoding leaves three values unused: 1, 14 and 15. Only 1 is cheap, and the reason is G's branch chain. The code separates piece types with p>>1: 1>>1 is zero, so it lands in the last branch, where an empty square already lands and the expression is always false. 14 and 15 give 7 — the first branch, the knight test. A ghost there attacks like a knight and puts a phantom check on the king from eight squares; on top of that the glyph string has no seventh character. 1, by contrast, comes free in four separate places: it threatens nothing in G, it lands on the blank in the glyph table, it silences the dead-position scan by itself, and it does not disturb the material count — if a ghost is on the board a pawn is too, and the count already sees enough material.

That is the beautiful part of the idea. It is also the only one. What loses fits in a sentence: while e was a variable, where the en passant square sat was free; buried in the board it has to be searched for on every move. The gains are scattered and small — each is one use of the letter e disappearing. The cost collects in two items.

+19 — clearing the old ghost. With e, clearing was a single assignment. With a ghost the board has to be searched:

The assignment that writes the destination square also has to move down: in the original the destination was written before the b[f]==1 test, and without the reorder an en passant capture reads its own piece and clears the wrong square. Why the chain works at all is subtle — JavaScript resolves assignment targets left to right and assigns right to left, so indexOf and b[f] still see the old values. The clearing also has to sit inside the raw move: a variant that passes the square in from outside and searches once a layer up saves 2 more bytes, but every path that calls the raw move without going through that layer — and the legality trial calls it exactly that way — leaves a stale ghost behind.

+9 — rescuing the forcing bit. The trigger of the dead-position scan does three jobs at once: silence the scan while en passant is open, force it once en passant lapses, and force it once a check lapses. The first comes free with a ghost — with a 1 on the board the scan already leaves through its own first gate, so no separate guard has to be written, 3 bytes gained. But the second was hidden inside e and a search has to take its place, 9 bytes lost. A net +6 from those two lines alone.

Why the silencing is needed is interesting in itself: the scan grows the squares a pawn can advance to vertically only, and cannot see a pawn jumping sideways to promote on a neighbouring file. With en passant open, the capturing pawn lands on the file the opponent has just vacated, and its path there is permanently clear — promotion is possible, mate is possible, the position is not dead. So “where there is en passant there is no lock” is not a conservative guess but a provable proposition, and the silencing closes this one blind spot in the scan's model. Without it a classic locked wall gets declared dead by mistake: a single double step waiting at the edge of the chain queens through the file that the en passant capture opens.

In the mate-and-stalemate build most of the items a ghost could win are absent to begin with — no repetition key, no silencing, no forcing bit — while the clearing chain stays exactly as it is. In exchange the en passant mechanism vanishes there completely: no separate f==e rule is needed on G's pawn diagonal, because the ghost already reads as a capturable target. That is where the idea looks cleanest, and it is also where it loses most plainly.

The alias story is instructive in its own right. Setting up an alias for indexOf costs 12 bytes and saves 5 per use — break-even at three uses. In the two shipped builds indexOf appears in a single place, where the alias is a 7-byte loss. The ghost creates the third use itself: the search that finds the king's square, the search that rescues the forcing bit, and the search in the clearing chain. It is the only file that crosses the threshold, and there the alias gains 3 bytes. So this is not an independent win but the ghost partly clawing back its own damage — and it shows the real rule of the tool: an alias is not a lever but a threshold, set by the number of uses.

There is a speed cost as well. Perft d3 from the starting position runs 25% slower in the ghost builds. It comes from two places: an extra board scan on every raw move, and the dead-position scan walking 64 squares for nothing before leaving through its first gate whenever a ghost is on the board. In the interface it cannot be measured — a click already takes microseconds — but it shows up in testing, and it says the idea is not free.

Not adopted. Break-even or losing in all three code bases, and slower. The final irony is this: the ghost frees the e and f slots, but both give >>1 = 7 and cannot be used without adding a guard to G's hottest expression. The only cheap free slot in this encoding was 1, and the ghost spends it to hand back two that cannot be spent.

Its correctness is not in question: across seven positions the perft counts come out identical to the index-based builds — the starting position, four standard CPW positions, and two positions built specifically to be dense in en passant. It was eliminated on price, not on error.

The figures above belong to the code base as it stood before the trigger of the dead-position scan was tied to the n<2 window; the ghost was measured against that generation. The new trigger closes the ghost's last refuge as well: the third indexOf use, the one that made the alias profitable, sat on the very line the trigger removed. Without it the ghost is down to two uses and the alias falls back below the threshold.

The ghost raises the question of whether the values left unused on the board can be put to work. Two more things were tried with the same question, and both hit the same wall.

Classifying empty squares by threat. Could 0, 1, 14 and 15 hold a two-bit threat map over the empty squares, and shorten king safety and the castling test? No, for three separate reasons. The first is fatal: the flag describes the position before the move, whereas the king's own body blocks the ray — the rule that a king may not retreat along the ray of the piece checking it collapses in the cache. Measured: on 0.2% of candidate king moves the map permits a move it should not. The current code gets the same thing right for free, through the make-test-unmake of the legality trial. Second: the king's own square is occupied, so the squares the check test and castling actually need are not the squares the map covers. Third: once an empty square is no longer 0, eight separate emptiness tests in the code break — 16 bytes before a line of map maintenance is even written.

Moving the castling rights onto the board. The same idea applied to c. Here the wall comes earlier: there is no free value giving >>1 = 2, the rook's branch. The remaining route would be to mark the rook squares, but the function that clips the rights is already 27 bytes and so tight that the string itself acts as the table — squares falling outside its range return zero for free through undefined → NaN → 0. Moving it onto the board would cost exactly that free behaviour.

Keeping a ±1 direction variable per colour and writing the pawn's move with that multiplier was tried. It gained nothing. The reason is not that the chosen representation is cheaper but that it is more versatile: the colour information sits as a single bit and the engine uses it simultaneously as a truth value (p%2==g), an XOR operand (t^=1), an addend (l(t)?t+1:3 gives the mate code, 10+2*k+g the result code), an index ('WB'[t]) and a multiplier (t*49+7, the render flip). A ±1 can do only the last of these, and a signed direction is meaningful for one piece only. The pawn carries no separate variable today: f<i^g asks whether the destination index is lower than the source and XORs that with the colour bit — direction and colour in one expression.

The board once started from the eighth rank: Black at the top, a8=0, b8=1, … h1=63. The reason was the render — in that layout, printing the array from start to finish gives you a board directly from White's point of view, with no cost for the first flip.

But what this engine was after was not brevity alone; being intelligible and universal was a priority too. And not every build has a board — one is blindfold, one numeric. A concern about rendering does not bind all seven files.

Measured, the scales came out even anyway. On the engine side a8=0 costs exactly zero; among the drivers it saves zero in some files and a byte or two in others. But the compressible block of the starting board shifts position in that layout, and the numeric compression takes back just as much. What is won in the render is lost in the literal.

One justification remains, and it is free: a1=0 is standard chess indexing. Because rank and file both count upward in White's direction, every expression in the engine reads naturally across all 64 squares. The engine's universality was preferred at a cost of zero bytes. The claim is about the engine, not the render.

There are two packed builds: dom_packed.html at 2,728 bytes and numerical_packed.html at 1,815. Both are self-extracting RegPack output — the body of the file is an unpacking loop whose last step is eval(_). Put an assignment in place of eval(_) and the file hands back its own source:

What comes back is not the plain file. What RegPack looks for is not brevity but repetition, so the packed source is longer than plain: 2,238 bytes instead of 2,145 in L3 numerical, 3,368 instead of 2,796 in L3. The difference falls under three headings — aliases expanded, functions inlined, operators widened — and in L3 there is a fourth: obsolete markup.

X and J stay functions in both files; both are recursive, so inlining them is not an option. V and l, on the other hand, differ. l's body is a single call to V, so inlining one multiplies the other's call sites. In L3 neither is inlined: l ends up with 7 call sites and V keeps its 3. In L3 numerical the choice goes the other way — l stays a function and V, with 3 call sites in the plain source, is inlined away.

Operators are widened wherever only the truth value is used: in L3 numerical && goes from 25 to 37 and || from 10 to 14; in L3 from 28 to 42 and from 14 to 19. In the engine, colour extraction is written %2 rather than &1. Naming is preserved — reassignVars is off, and in both files the globals sit on the same letters as in plain.

That expanding an alias pays is specific to Math.abs; it is not a general rule. In L3 numerical all 64 subsets of the aliases h, v, d, y, P and g were tried, and every one of them made the packed file bigger. The cheapest expansion adds a byte to the baseline, the dearest twenty-six. Going the other way lands in the same place — re-aliasing Math.abs costs 3 bytes, expanding l 11, expanding C 21, aliasing b.indexOf 15.

The reason is token economy. A hand-written alias is a free abbreviation: it is already short in the source and it takes nothing from the packer's one-character token pool. Expand it and a long piece of text enters the source, the packer spends a token compressing that text, and the token it spends comes out of some other pattern. Math.abs is the exception because it occurs in only three places and its expanded form merges with the text beside it — Math.abs( — into a longer shared pattern than it would make alone.

The rule: expand an alias only when its expanded form merges with neighbouring text into a longer shared pattern. Aliases standing for a plain value used many times in different contexts are already optimal, and touching them loses every time.

dom_packed.html is not the packed form of today's L3.html; it comes from an earlier generation of L3. The clock and the signature are the same in both — the recovered source opens with c=15,U=[600,600],N='innerText',e=Y=-1,t=1 and measures elapsed time from the U[2] stamp with new Date. The difference is in the markup: the packed build prints the board and everything round it with document.write, using methods today's plain build no longer contains.

The globals match, but a few local names diverge. The render function is an expression rather than a block and its parameter is p, not _; the b.map indices in L and I converge on w; G's ray walker is S=T=> rather than S=Q=>; and the render's J, E and s temporaries are gone, with everything going through p.

Two of these shadow something. S=T=> covers G's own T parameter. d=p=> covers the promotion picker element for the whole body of the render, and the b.map((p,w)=>(p=this[w], … )) inside takes the same letter again. Both are harmless: the shadowed value is never read in that scope — the picker appears only in A and S.

The version is v5.0.4, from the GitHub tag. Taking the package from npm is not enough: things stopped at 5.0.1 there, and that release is short in two ways. It has no tokenCost, so it never accounts for a token that needs escaping costing two bytes inside the regexp class; and it cannot handle modern syntax — the output of 5.0.0 dies on ||= with Unexpected token '='. The source has to come from the repository.

5.0.4 has a habit of its own: it trims whitespace inside a template literal. On its own that was reason enough to rule the version out; it no longer is, because one space written as an escape settles it.

The two packed files are not files whose source can be copied off the screen. Their dictionary keys are control characters in the \x01–\x1f range; the moment they pass through a clipboard, a text box or an editor's line-ending normalisation they vanish or turn into something else, and the file never opens again. For these two, downloading is the only correct route. The plain builds carry no such restriction.

The three coefficients only mean anything as a ratio; multiplying all of them by the same positive number changes nothing. The default ratio (2/1/0 with a tiebreaker of 1) is optimal for neither file, and the optimum moves with the file. The sweep shows it: in L3 numerical zeroing every coefficient wins, while in L3 the length coefficient has to stay in play.

The wrapper row comes from a constraint: RegPack hard-codes the unpacking loop's variable as G in its own source, no option changes it, and G is our geometry function. Even so, neither file needs the letter swapped: the unpacking loop finishes before eval(_), the unpacked code writes its own value to that same letter, and nothing reads G in between. Not a collision — a question of order.

Repacked with v5.0.4 under these settings, the recovered source reproduces both files byte for byte — dictionary character class, candidate ordering and recovered source included. As it stands, packing is a reproducible step.

In dom the gain settles onto a plateau at 3/1: four, five and six all return the same 2,708, so the smallest integer that reaches the plateau was taken. Turning up the length coefficient on its own (0/1) is a disaster in both files — it means chasing long patterns with no regard for what they gain.

Keeping reassignVars off is more than a preference. With it on, RegPack redistributes the single-letter names by frequency and, taking the never-read Y for a free letter, shifts it — breaking the signature embedded in the source. With it off the recovered source stays byte-identical to the input and not one identifier moves. The cost was measured: allow the renaming and numerical would come to 1,789, dom to 2,694. Fidelity costs 9 bytes and 14.

The option is called varsNotReassigned. Pass varsNotReassignedRaw instead and RegPack skips the transformation block and ignores the option in silence. The command line holds a trap of its own: --reassignVars false does not work, because minimist hands the value over as the string "false" and RegPack reads it as true. Renaming stays on, the signature quietly disappears, and since the file comes out a few bytes smaller it is not easy to notice. Either write --reassignVars=, or pass the options through the API as a real boolean.

RegPack picks its tokens from characters that never occur in the source. Control characters are nearly free, since they fit into a single \u0001-\u001f range inside the regexp class; the printable ones are counted individually. Every new character entering the source removes a candidate from the pool, and every character leaving it adds one — which is why moving the render's parameter and the font family off _ in L3 makes _ a token.

dom holds the live example of the other direction. The \x20 written into the template literal puts a backslash into the source, and \ drops out of the pool that moment — it was the dearest candidate anyway, costing two bytes inside the regexp class because it needs escaping. A three-character fix does not stop at bytes: it takes a letter out of the token alphabet too.

Packing makes the source unreadable, so there is no judging the output by eye. These are the checks run on both files:

Anyone repacking should run three of these without fail: the signature, the generated markup and lock-step equivalence against the previous pack. A smaller size on its own says nothing — a file that has lost its signature also comes out a few bytes shorter.

The engine side is modern: BigInt literals, template literals, the logical assignment ||=, default parameters. The one old place is the packed L3, and even there the reason is one word — bytes. HTML's abandoned presentational attributes are shorter than their CSS equivalents, and browsers are not free to drop them: the specification still defines how they are to be processed, because a large part of the web depends on them. Being obsolete does not mean not working; it means the validator complains.

The whole load sits in dom_packed.html. Not one of the eight plain builds carries a single obsolete element or attribute; the ones that draw a board write their markup statically and leave the measurements to <style>. The “modern equivalent” column below is an inventory of what today's L3.html actually does; the “in the source” column belongs to the generation before it.

The cost column is what the shortest equivalent would cost in the source, before packing — 18 bytes in total. It does not carry through linearly: a change both disturbs the repeat sequences the packer sees and, for every new character entering the source, costs a slot in the token pool. The cheapest measured packing of today's plain L3.html is 2,891 bytes2,470 of packed script + 404 of static markup + 17 of tags; the shipped older generation sits at 2,728, and the 15 bytes of <!DOCTYPE html> fall outside the packed payload and land directly on top of that.

Reaching for an obsolete technique remains not a preference but a last resort, turned to only when there is no room left — the moment room appeared, the plain build dropped all six.

document.write() is the most contentious of the three. MDN marks it deprecated outright and the specification itself carries a warning box: the method can change the document's state while the parser is running, can produce a DOM that does not correspond to the source, and erases the document if called after the page has loaded. The intervention Chrome has applied since 2016 is narrow in scope: only for a user on a slow connection, in a top-level document, does it decline to execute parser-blocking <script> elements injected via document.write(). dom_packed.html prints markup rather than script, and does it during parsing, so it falls outside the intervention. It does still block the parser. Today's L3.html does not call document.write at all — its markup is static and only the table body is written, through innerHTML.

with is present in both packed files, but it is not code we wrote: RegPack's unpacking loop uses the with(_.split(…)) pattern. The practical consequence is that, since with is a syntax error in strict mode, the packed files cannot be loaded as ES modules and cannot have 'use strict' placed at the top. The plain builds carry no such restriction.

eval is not obsolete, but it is the last step of the unpacking loop. Its consequence is a compatibility boundary: under a Content Security Policy without unsafe-eval, the packed builds will not run. Rather than assume this, the launcher on this page tests it — because the iframe is loaded from the same origin it inherits the same policy, so the page's own test answers for the iframe too.

None of the nine HTML files contains <!DOCTYPE html>, so all of them open in quirks mode. That is not an oversight but a 15-byte-per-file choice. For the three JavaScript files — engine.js, engine_4x.js and engine_onlyMoveGenerator.js — neither a DOCTYPE nor a rendering mode means anything.

One common confusion is worth separating out here: obsolete presentational attributes do not belong to quirks mode. bgcolor, width and cellspacing are attributes the specification defines as presentational hints, and they behave identically in standards mode. Adding <!DOCTYPE html> fixes not one row of the table above; the two are independent matters.

The two classic quirks behaviours people reach for change nothing here either. The first is the box model: it is widely believed that the old IE model still applies in quirks, but in current browsers a table cell is content-box in both modes. Measured: with <th width=54> and the default 1px padding the cell comes out 56×56 — 54 of content plus one pixel on each side, exactly the number standards mode would give. The second is tables not inheriting the font from the body; that one is moot as well, since every file opens with the universal selector and gives the cells a rule of their own.

L3.html opens in quirks mode but does not depend on it. The file contains no unitless length, no hashless colour and no presentational attribute; the only difference between the two modes is none at all: the 56×56 measured above comes out the same either way, leaving not even a digit to compensate. A <!DOCTYPE html> could therefore be added today for 15 bytes, without shifting a single pixel. The one file that genuinely depends on quirks is dom_packed.html.

There are also usages frequently flagged in audits that are in fact current; they are listed here so the question does not come up again.

The engine offers six calls and all of them speak in square indices: for A(i,f,u), both i and f have to be numbers in 0–63. What the user supplies is letters, digits or a click. The conversion between the two is the driver's job, and it runs both ways: a move in, a result out. Where the input formats are described only the user's side appears; here is the code.

There are three parsers and each is a single line. What they have in common: none of them validates. An invalid input does not reach an error branch, it becomes a number that is not in the L(i) list — and falls through there in silence.

The L3 input family and L3 prompt, three builds in all, carry the same parser. A square is two characters: the file letter and the rank digit.

Three tricks are stacked on top of each other. The first is type mixing. K.charCodeAt(V) returns a number, while K[++V] is a one-character string. Multiplying it by 8 forces JavaScript to coerce that string to a number — no separate parseInt is needed, and the multiplier is already the rank's weight in the index.

The second is a side effect. ++V increments the parameter in place, so a single call reads two characters. The caller only supplies where the pair starts: k(0) is the origin square, k(2) the destination.

The third is the constant. 105 did not fall from the sky: the code for 'a' is 97, and the first rank contributes 8*1. Their sum lands a1 on zero, and a1=0 indexing is the engine's layout anyway.

Because the input passes through toLowerCase() first, E2E4 and e2e4 give the same square. Case-insensitivity is not a separate rule but a by-product of one call.

L3 numerical has no k, because it does not need one. Its squares are already numbers from 1 to 64, and the conversion finishes inline.

+ here is not addition but concatenation: K[0] and K[1] are one-character strings, and '5'+'6' is '56'. The -1 immediately after does two jobs — it coerces the string to a number and shifts the 1–64 range to 0–63. String behaviour and then numeric behaviour, in one expression.

Choosing 1–64 rather than 0–63 costs exactly those two characters. In exchange the user never has to count from zero.

In L3 there is no text to parse; there is a state machine instead. Each of the sixty-four squares carries onclick=S(id) and, thanks to named access, passes its own id.

u ^= K turns a screen square into a board square. The render always draws the board from the point of view of the side to move, so cell zero on screen is not a1 when Black is to move. The mask K = t*49+7 undoes this: ^7 flips the files for White, ^56 the ranks for Black. It is the click handler's first act, because everything after it speaks in board indices.

~i is the selection flag. With nothing selected i is -1, and ~(-1) is zero — so there is no separate flag variable; i itself carries both the selected square and the question of whether there is one.

Two phases. If something is selected and the clicked square is in the L(i) list, the move is made. If not — or if nothing was selected — and the clicked square holds a piece of the side to move, the selection moves there. Clicking the wrong square raises no error; it quietly changes the selection or does nothing.

The selection is set with i = f = u, both at once. The reason is the render: the green outline marks f, so at the moment of selection it shows the selected square, and after a move the destination. One variable carrying two meanings, both of them right.

When a piece is selected, the squares it can reach turn gold. No separate mechanism does this — the render already calls L.

s = L(i) sits outside the loop over 64 squares. Left inside, it would be recomputed for every square — the engine's hottest path, sixty-four times over. Hoisting it out is the only reason the letter s crosses the engine–driver boundary, and why it appears in the shadowing table.

With nothing selected, i is -1 and L(-1) returns an empty array: b[-1] is undefined, the piece type is zero, and G passes for no target. So the “nothing selected” case needs no branch of its own — an empty list simply colours no square.

Three visual channels overlap, each answering a different question: gold for reachable squares, a green outline for the selected or last-arrived square, white text for the piece's colour. None overwrites another because they write to different properties — bgColor, outline and color.

When the move is legal, S does not call A() straight away; it asks one question first: b[i]>>1 == 4 & u%56 < 8 — is the selected piece a pawn, and is the destination on the first or eighth rank? If so, p.hidden = 0 opens the panel and the move is suspended there. f has already been written; the panel's buttons call A(3), A(2), A(1), A(6), supplying the piece type and finishing the move.

Suspending it needs no state variable of its own, but it does need the board locked, and the z || p.hidden && guard is there for that. Without the guard, clicking one of your own pieces while the panel is open runs S's second branch, i = f = u, with the panel still open; pressing a button then runs M(i,f) with i == f, and b[i] = 0 immediately after b[f] = p clears the square just written — the piece vanishes and the turn passes. Neither exists in chess. p.hidden is truthy at all other times and zero only while the panel is open, so the guard closes exactly that window. The move stays half-made until the promotion is chosen — this line is the source of the behaviour described in the notation section.

The panel has a second door: the promotion buttons call A without going through S, so S's guard does not cover them. If the game ends while the panel is open — a resignation, a claimed draw, or a flag — F or the timer writes z, the panel stays open (only A clears p.hidden), and pressing a button lets A recompute z and overwrite it: the game carries on after it has ended. A = T => z || d(…) puts all four entry points — S, A, F and the timer — behind the same door.

L3's draw control is a radio button, and on its own it displays both offer bits at once.

Bit 0 of o is White's open offer, bit 1 Black's. The radio reads both, through two separate channels:

Being checked is your own offer. o & 2-t — with White to move 2-1 = 1, that is bit 0; with Black, 2, that is bit 1. Always the bit of the side to move.

The yellow outline is the opponent's offer. o & t+1 — with White to move that is 2, Black's bit. Exactly the reverse. The same element, the same o, two different masks: one says “I have offered”, the other “I have been offered”.

It travels with the move. A move played while the radio is checked takes the x.checked ? D() : Z(o=0) branch. Because D() is called with no argument it does not touch the bits, it only evaluates — the offer was already lit by F(). If it is not checked, o = 0 extinguishes every offer: making a move withdraws an open one.

The same function also serves the resign button: F(1) with an argument, F() without. One letter carrying two controls.

The three drivers take the promotion type in three different ways, but all three arrive at the same place: M's third parameter, that is the piece type.

The queen column is empty, and deliberately so. The first two expressions return undefined for any character they do not recognise — no match in the object lookup, an out-of-range index in the string. When undefined is passed as an argument, JavaScript falls back on the default parameter, and M's default is u=3: the queen.

So the behaviour “omit the promotion letter and you get a queen” comes from a language rule, not from a check. It is the same in all three drivers, and in all three it costs zero bytes.

L3's buttons are the exception: there is no default there because the user has to pick one of the four. While the panel is open the move stays suspended, so the undefined path never arises.

The engine returns a number: a code from 1 to 15. What goes on the screen is the driver's business, and here too there are three roads.

L3 numerical does not convert at all — alert(z) prints the figure itself. In an interface that stays numeric from end to end, turning the code into letters would be the inconsistency. L3 never produces a number: it replaces Z, D and the result builder with its own versions, and the string comes out directly. Only the three UCI builds convert, and they do it in one line.

Two strings sit in parallel and are read with the same index. Put the z-th character of each side by side and the two-letter code appears — no separate table, object or branch.

Character zero is a space in both, but it is never reached: z && short-circuits, so while the game continues w returns zero. No branch is spent on the “still going” case.

The strings are 10 characters long, so the coverage stops at 9. Flag fall and resignation never pass through here; the driver's own F=k=>(Xm=2e4,Xs={},X(t,15))?k+'M':'WB'[t]+k builds those — it takes 'T' or 'R' and adds a prefix or a suffix depending on whether mate is impossible. Two mechanisms, because their inputs differ: one takes a code, the other a letter.

The nine is not a coincidence either. In the engine, draw by agreement is 15; in these three builds it is 9. A pair of strings running to fifteen would cost twelve more bytes, and nine is the first free slot after the 75-move rule. That the two encodings diverge is not a design preference but a consequence of fitting this table.

The allocation of slots on the engine side carries the mark of the same squeeze: the low slots were left to the literal codes so they would fit in a single digit, and the only code that spills into two digits is the rarest, draw by agreement. The output the user sees is the same under all three schemes; the difference is only in the inner layer.

Who calls the parser also varies from build to build, and that choice directly determines how the clock is kept.

In the blocking builds the clock does not merely pause, it never ticks — a timer cannot run while a modal dialog is open. Instead the difference is measured and deducted once the dialog closes. The result is the same, but this is why L3 numerical's clock is in milliseconds: since the measurement is a raw Date difference, rounding to seconds would buy nothing.

The same distinction explains the choice of engine.

The letters engine.js does not use are left to the driver. The tables below say what those letters actually do across the five drivers, which names are shadowed, and which are genuinely free. L2 and L2_aybars_2400, which have no player layer, and L1, which carries no draw rules at all, are outside these tables. The tables to consult before renaming a letter are here; the procedure itself is under Pitfalls.

All eight plain builds and all three engine files read as the same four blocks, in the same order. First the state: c, the clocks, e, t, the board, the counters and the repetition table — everything that describes the game at this instant. Then the helpers: Q='indexOf' and a=Math.abs, abbreviations with nothing to do with chess, useful only as JavaScript. Then the engine: G V l L C M I H X J Z A D F, the whole of the rules, ignorant of input and output alike. Last the driver: parsing, formatting, drawing, interaction, hooks and start-up.

engine.js stops after the third block. That is what “no front end” amounts to in practice.

In two places the boundary moves with the content. A letter finds its block by what it holds: N is state in the four builds where it is a clock, and a helper in the L3 family where it is 'innerHTML'. And where functions are inlined the engine block closes early — in L3 the engine's A is folded into the interface handler; in L2 and L2_aybars_2400 the block ends at M. The bot layer of L2_aybars_2400 sits after the driver, like a fifth block.

The two packed files stand outside this arrangement: their aliases are written out, so the helper block is empty, and some of their functions are inlined, so the engine block has gaps.

The 15 letters and three two-character names above are actually used by the five drivers, and the same letter does a different job from build to build. The three tables below describe the plain builds; the naming of the packed builds is a separate matter.

The sharpest divide is between L3 and the text drivers. Because L3 writes to markup, most of its letters hold elements; in the text drivers the same letters do parsing and timing work. K is the clearest example: the raw input text in the four text builds, the board's orientation mask in L3.

Two letters live in a single build: u and S, both in L3. E and p live in two builds each, y in two. onkeyup appears only in the L3 input family — the reason is the loop shape.

L3 numerical's two gaps are not accidental. J is absent because, squares being two-digit numbers, they are resolved inline with K[0]+K[1]-1; w is absent because this build returns the result code as a number and never enters the lookup table. Together, the two are part of why the file is the smallest build.

The unit of x is not the same in the two builds that hold it: L3 prompt keeps the elapsed time in seconds, while L3 numerical keeps it in raw milliseconds — since its clock is in milliseconds anyway.

Three files carry markup, and all of them reach their elements from JavaScript by named access: an id can be read as if it were a global of the same name. This is a lever — not writing getElementById is worth dozens of bytes per file.

Two of these make up the entire 28-byte markup prefix of the L3 input family: <pre id=T></pre><input id=x>. L3's prefix is 185 bytes and static too; only the ids of the sixty-four squares arise later, from a template literal written through T[N]=. The same sixty-four ids are used in dom_packed.html.

There are seventeen places where the same letter is two separate things, and none of them is a bug. The reason is simple: the engine never touches the DOM, and the shadowing side never reads what it shadows. The two are never live at the same time — by the time one sets its value, the other has long since finished its work.

z stays inside the engine and never reaches the driver. That is no longer true of s: L3's render hoists L(i) out of the loop and holds it in this letter — left inside, it would be recomputed for each of the sixty-four squares. The rest sit on the engine–driver boundary, and the great majority arise only in L3, since it is the only build that prints markup.

The densest shadowing in the file is inside one function. J declares eighteen locals in its parameter list, and most of them stand on engine names — W, B, V, K, L, C, Z, P, Q, N, S, X. None is read from outside; the rule works entirely on bitboards of its own, and the shadowing is what keeps it from needing new global letters at all.

What makes this safe is timing: u, for instance, holds the square index in L3's render loop while the engine's M uses the same letter as the promotion type. The two do not collide because the render does not begin until the engine call has finished. The shadowing list is therefore not an exemption but a constraint: consult this table before adding a new driver global.

The four tables above say which letters are used. This one says the reverse: the letters that never appear as identifiers in each file. The source of all seven plain files was parsed and every single-letter identifier collected; what follows is what was left.

The count falls as you move from the engine without a front end to a complete driver: engine.js has no interface and three letters free; one remains in L3. Exactly one letter is free in all seven files: j.

Even that one is not usable outright, and the reason lies in the packer. RegPack wants a letter for the unpacking loop's wrapper, but it also picks its token characters from characters that occur nowhere in the source. So there are two separate tests: the letter must be free as an identifier, and must not appear in the file as a character at all. The two are not the same thing.

No letter passes both tests. j is free as an identifier in all seven files but fails the second: the join call puts it into the source, as a character, in L3, L3 input and L3 prompt. _ passes the second test — it does not occur even once in the three files where it is free — but it can only be used in those three; for a single name across all seven it does not qualify. E is narrower still: free in five files, present as a character in three.

The space was not always this tight. X used to be free in all seven files, and that is exactly why it was held in reserve; when the 6.9 search arrived it took the letter. J went to the dead position scan in the same round, and K and w to the locals of those two functions. What was once the extreme case — k, the direction vector in G, free in no file and present as a character in all seven — is now the rule rather than the exception: X, J, K and w lose both tests as well.

Every line of golfed code is a concession, and most of the concessions are invisible. What follows is what anyone about to change the engine or the drivers needs to know: the points that break silently when touched, or that are misread at first glance.

The state table describes the engine's general form. Four variables step outside it, and this is the first thing to break when moving code from one driver to another. In the two builds without the player layer there is no one left to claim, so 3-fold repetition and the 50-move rule are ruled on without waiting for a claim.

In L3's array the index is the inverse of the colour bit: U[0] is White, U[1] Black. The driver decrements the running clock with U[t^1] and applies the increment with U[t^=1]+=5 — which, after the side to move has been flipped, lands on the player who made the move.

The flag test depends on those units too. Both prompt drivers look for the flag in the product of the two clocks, but with different thresholds: L3 numerical uses U*N<1, L3 prompt uses U*N<=0. That is not a matter of style. L3 numerical keeps its clock in whole milliseconds, so there the product is either at or below zero or at least one, with nothing in between; <1 is a byte shorter and safe. The clock in L3 prompt is in fractional seconds, and had <1 been written there, a scramble with 0.9 and 1.0 seconds left would give a product of 0.90 and declare a win on time with neither flag down. So <1 is correct only on an integer clock; change the unit one day and the flag starts falling early, in silence.

It is easy to assume the board in L3 has two entrances: clicking a square and pressing a button. There is a third, and it hides well. The four buttons of the promotion panel are wired straight to A in the markup — <button onclick=A(3)> — so they never pass through S. No guard placed on S can stop them.

Here is the hole that opened. When a pawn picks the last rank the panel appears and the game waits for the promotion choice. In that window the game can end by another route: the flag falls, resignation is pressed, or a draw offer is accepted with the radio already set. Then the player clicks the queen. With A unguarded the move would be written to the board and z overwritten with the new verdict, on top of the finished game's result. The result vanished from the status line and play carried on.

The guard is A=T=>z||d(…), 3 bytes. The same 3 bytes sit in F: without them, pressing resign or draw again after the game is over rewrites the result.

The panel's second gift is worse. Click another piece while the panel is open and the selection moves there, but the panel stays up; press the queen afterwards and A now runs a move whose i and f are the same square — and because M writes b[f]=… before b[i]=0, the piece evaporates. What stops that is the p.hidden&& in S: while the panel is open, square clicks are not processed at all.

L2 closes the same hole differently, and more cheaply. Instead of p.hidden=0 it writes p.hidden=z--: with z at zero, z-- returns zero and leaves z at -1, so opening the panel marks the game “over” at the same instant and S=u=>z||(…) locks itself out. It costs nothing, because that build has neither clock nor buttons — nothing but A ever sets z. Which is why only the second half of this trap was reachable in L2. The same trick would not work in L3: with three separate routes setting z, the -1 would collide with their results.

Some files carry non-ASCII glyphs: the ones that draw a board use the chess pieces, and prompt.html full-width letters. Every one of them begins with a BOM, and it is necessary — the files carry no <meta charset>, and the BOM is the only thing declaring the encoding.

The second trap is subtler. In the render string of the board-drawing builds, the character for an empty square is not an ordinary space but a non-breaking space — the first character of the string ' ♝♜♛♟♚♞' is U+00A0. Convert it to 0x20 and it becomes collapsible whitespace in the markup, the cell counts as empty and the board collapses. An editor that “cleans up an unnecessary character” does this all by itself.

The order of the six assignments that precede b, the one that builds the board, is not a coincidence. Read their initials and a name signed at the bottom of the source appears — case does not change the reading:

The order is preserved in every build that carries a clock — engine.js, engine_4x.js and five front ends — and it reappears intact when the two packed files are unpacked. A driver without a clock cannot carry the reading at all — there is no U and no Y to read.

Y is the one dead letter inside the signature. It is initialised to -1 and is neither read nor written anywhere after that; its only function is to complete the reading of the acrostic. That is not waste but the price of the acrostic: five of the letters are already doing work, and the sixth costs two bytes.

The same letter also names J's parameter, but that is a separate binding shadowing the global — the force switch. The two do not collide, because the acrostic belongs to the text of the declaration, not to run time. The practical consequence is that a driver may take Y for its own use and the signature will still read.

Changing a letter is not as mechanical as it looks; a blind find-and-replace breaks things in three places at once.

The right method is to parse the source with acorn and change only Identifier nodes, doing the id= migration separately by hand. That way the literal and template fragments are never seen at all.

All the perft runs look outward: the measure is FIDE itself and the engine's history is irrelevant. Once the source is touched the question changes — not “is the rule right?” but “did this change break something?” The measure is now the previous build. Five checks exist for that:

Perft is not on this list: if move generation was not touched it is not needed, and if it was, all the runs above rerun from the start anyway.