Regardons le code source de chacune de ces cinq stratégies pour donner une explication précise, pas approximative.Confirme ce que je savais déjà de `ran`. Voyons maintenant `gtp`, `sc0`, `sc1`.`eat` et `gtp` sont **algorithmiquement identiques** — seul le nom de la fonction diffère. Regardons maintenant `sc0` et `sc1`.Confirmé : `sc0` est aussi identique à `ran`, mot pour mot. Regardons maintenant `sc1`, bien plus volumineux.Confirmé aussi pour `sc1` : le vrai mécanisme de communication externe est présent dans le code (formatage FEN, position, config...) mais **jamais exécuté** — un bloc `#if (1)` toujours actif court-circuite tout. Vérifions les deux fonctions utilitaires (`SANSingleMove`, `SANMatingMove`) utilisées par `eat`/`gtp`, pour être précis.J'ai désormais une image complète et vérifiée. Voici ce que fait réellement chacune des cinq stratégies, dans `demos/xboard-engine` :

## `ran` — coup aléatoire pur

```c
select_m = *(curr_g.g_base + (rand () % curr_g.g_gmvc));
```
Une seule ligne : tire un coup légal au hasard, sans aucune considération tactique.

## `sc0` — identique à `ran`

`SC0Select()` (« Stanback Chess Program, variante interne ») contient **exactement la même ligne**, mot pour mot. J'ai comparé les deux fonctions directement : aucune différence hormis le nom. Malgré son nom qui suggère un lien avec un vrai programme d'échecs, c'est un simple générateur aléatoire.

## `eat` et `gtp` — identiques entre eux, et un peu plus élaborées que `ran`/`sc0`

Là aussi, comparaison directe : `EATSelect()` et `GTPSelect()` (« Gillogly TECH program ») sont **byte pour byte identiques**, seul le nom de fonction diffère. Leur logique, dans l'ordre :
1. **Un seul coup légal ?** (`SANSingleMove()`) → le jouer, sans réfléchir davantage.
2. **Un coup qui mate immédiatement ?** (`SANMatingMove()`, cherche le drapeau `mf_chmt`) → le jouer.
3. **Sinon, la plus grosse capture** : simule chaque coup, calcule le différentiel matériel (`cpmv[actif] - cpmv[passif]`), trie, et joue le meilleur *si* il améliore réellement le score par rapport à ne rien capturer.
4. **Sinon, un coup au hasard** — comme `ran`.

C'est donc un « glouton » myope : mat en un coup si possible, sinon la plus grosse prise disponible, sinon aléatoire. Aucune anticipation au-delà d'un demi-coup, aucune notion de pièce mise en prise en échange (contrairement à ce qu'on a ajouté dans le moteur tactique).

## `sc1` — le cas le plus intéressant : une coquille vide

`x_sc1.c` (« Stanback Chess Program, variante externe ») est de loin le fichier le plus long (364 lignes) et a manifestement été conçu comme un **pont vers un vrai programme d'échecs externe séparé** : il contient du code complet pour sérialiser la position (FEN, échiquier case par case, droits de roque, horloges...) et les coups en chaînes de caractères, prêts à être envoyés à un sous-processus externe.

Mais toute cette tuyauterie est court-circuitée par un bloc `#if (1)` — donc **toujours actif** — au tout début de la fonction `SC1()` : pour toute demande de sélection de coup, il se contente de :
```c
mptr = curr_g.g_base + (rand () % curr_g.g_gmvc);
```
...un coup aléatoire, ensuite ré-encodé dans un format binaire compact (probablement celui qu'aurait utilisé le vrai programme externe), puis redécodé côté SAN Kit. Le vrai code de communication (un `printf`/`scanf` interactif tout en bas de la fonction) est du **code mort**, jamais atteint. Et pour toutes les autres requêtes (jouer un coup, définir la position, configurer) le même bloc renvoie simplement `0` sans rien faire — tout le travail de formatage FEN/position dans `SC1Play`/`SC1SetPos`/`SC1Config` est donc préparé... puis jeté.

## En résumé

| Stratégie | Comportement réel |
|---|---|
| `ran` | Coup légal aléatoire |
| `sc0` | Identique à `ran` (aucune différence de code) |
| `eat` | Mat en 1 → grosse capture → aléatoire |
| `gtp` | Identique à `eat` (aucune différence de code) |
| `sc1` | Identique à `ran`/`sc0` en pratique — la tuyauterie vers un moteur externe existe dans le code mais n'est jamais exécutée |

Concrètement, il n'existe donc que **deux comportements distincts** parmi ces cinq noms : un joueur purement aléatoire (`ran`/`sc0`/`sc1`) et un glouton myope orienté matériel (`eat`/`gtp`). C'est cohérent avec ce que documente déjà `SAN_DOC/DIY` : ces modules sont présentés comme des *exemples* pédagogiques à copier pour écrire sa propre stratégie, pas comme des IA achevées — et `sc1` en particulier ressemble à un gabarit d'intégration laissé inachevé, avec son échafaudage de test (`#if (1)`) jamais retiré avant la publication du code source.
