Bonne question — vérifions directement dans le code, notamment la logique de roque (le point le plus susceptible de casser en Chess960).Confirmé de façon décisive — et il y a même un argument chronologique définitif. Vérifions le parseur FEN pour le champ de roque et la date de la bibliothèque.## Réponse : non, pas du tout

J'ai vérifié directement dans le code, et la réponse est claire et à plusieurs niveaux :

**1. La génération et l'exécution du roque sont entièrement câblées en dur** sur les cases de départ standard. Dans `sangen.c`, la génération du roque teste littéralement `SANBlackAttacks (sq_e1)`, `gb.bv[sq_f1]`, `gb.bv[sq_g1]` — des constantes fixes, pas la position réelle du roi ou des tours. Dans `sanmer.c`, l'exécution du roque est tout aussi câblée :

```c
case scmv_cks:
  ...
  gb.bv[sq_e1] = cp_v0;
  gb.bv[sq_g1] = cp_wk;
  gb.bv[sq_h1] = cp_v0;
  gb.bv[sq_f1] = cp_wr;
```

Si le roi ou les tours ne sont pas sur leurs cases classiques (e1/a1/h1 et e8/a8/h8), le roque casse tout simplement — la bibliothèque ne lit jamais où se trouvent réellement ces pièces.

**2. Le champ de roque du FEN n'accepte que `K`/`Q`/`k`/`q`** (`sanfen.c`) — pas de notation par colonne (type Shredder-FEN `HAha`) qu'il faudrait pour représenter sans ambiguïté les droits de roque en Chess960, où le roi et les tours peuvent démarrer sur n'importe quelle colonne.

**3. Argument chronologique définitif** : les fichiers datent de 1993–1994 (`sanmer.c` : révisé le 5 septembre 1993 ; `sanfen.c` : 24 janvier 1994). Bobby Fischer n'a inventé Chess960 qu'en **1996**. La bibliothèque ne pouvait tout simplement pas le connaître.

Cela dit, `SANFENSet()` accepterait sans broncher un FEN de départ Chess960 *syntaxiquement valide* (position de pièces arbitraire) — c'est seulement la logique de roque qui échouerait silencieusement dès qu'on tenterait ce coup particulier, puisque tout le reste du moteur (génération de coups normaux, capture, promotion, etc.) ne dépend absolument pas de la position de départ standard.

---

Bonne question — vérifions ça dans le code source plutôt que de deviner.Aucune trace, sans surprise (les échecs 960 n'existaient pas en 1993-94, l'invention de Bobby Fischer date de 1996). Voici la réponse claire, appuyée par le code :

**Non, SAN Kit n'est pas compatible avec les échecs 960**, et ce à plusieurs niveaux, tous vérifiés directement dans le source :

1. **Position de départ figée** — `SANInitPosition()` (`sanint.c`) place explicitement les pièces sur leurs cases standard (`sq_e1`=roi, `sq_a1`/`sq_h1`=tours, etc.), sans aucune notion de position aléatoire.

2. **Génération des roques totalement câblée en dur** — dans `sangen.c`, la génération de roque vérifie littéralement `SANBlackAttacks (sq_e1)` (case fixe, pas « la case où se trouve réellement le roi ») et place le roi/la tour sur `sq_g1`/`sq_c1` en présumant que la tour part de `a1`/`h1`. Sur une position 960 où le roi ou la tour démarrent ailleurs, cette logique serait tout simplement fausse (ou ne détecterait jamais le roque comme légal).

3. **Le parseur FEN rejette la notation de roque non standard** — `SANFENParseCA()` (`sanfen.c`) n'accepte que les quatre lettres `K`/`Q`/`k`/`q` ; toute notation par lettre de colonne (type Shredder-FEN `HAha`, utilisée pour désambiguïser les roques en 960) est rejetée comme FEN invalide.

C'est cohérent avec le contexte historique : le code date de 1993-94, et Bobby Fischer n'a inventé cette variante qu'en 1996 — elle n'existait tout simplement pas encore. C'est aussi pour ça que nos deux moteurs xboard annoncent honnêtement `variants="normal"` dans leur chaîne `feature` CECP (pas un choix délibéré lié à cette question, juste la valeur par défaut documentée — mais qui se trouve être la bonne, comme la vérification le confirme).
