Kata

There could also be checks that:

• there are no pawns on the 1st or 8th rank
• there is exactly 1 king for either side

Hi, thanks for the feedback. I'm aware of the simplicity of the en passant target validation that this kata requires. I've considered all the conditions you mentioned, and at first I wanted to include them in validation, but abandoned this idea, noticing how this would require much more complex random test generation. I thought that this kata is already quite fun as it is now. Or maybe I'm just too lazy :v On the side note, I don't feel that checking if the opposite color's pawn is able to capture the mentioned pawn is neccessary, for I see this notation only as an indication, that the pawn just moved two squares and is susceptible to the en passant capture, regardless of whether this capture is actually possible for the opposing color. But, aside from the en passant capturing, I think that adding at least the minimum board validation you mentioned would be a good idea, honestly I don't know why I didn't do that already. Will do.

The checks besides en passant rules are problematic because they are possible in chess variants, which use the same FEN notations to store games. Lichess has lots of popular variants.

there are no pawns on the 1st or 8th rank

Violated by horde chess, which has pawns on one's own back rank. Besides, the chess rules used to not forbid promoting to a pawn (or even opponent pieces), which would cause pawns to exist on the opponent's back rank.

there is exactly 1 king for either side

Violated by anti-chess (there can be 0 kings for each side).

the number of pieces is at least possible

It depends on the variant.

Good questions. Splitting empty squares into separate groups, while not practical, is still a valid notation. This standard, AFAIK, nowhere states that it is not valid, and this still can be clearly interpreted as a valid row on a board. So the answer is yes, this is valid, although the tests don't check this. But as this is an interesting observation, I will include this in fixed tests. For the second part - as per description, the second field in the notation represents: Active color, either `w` or `b` for white and black accordingly. So this field shall take only one of these characters, uppercase letters are not valid. Same thing applies to the en passant target, as traditionally, the algebraic notation identifies square's file as a lowercase letter from a to h.