Shogi

Implémenté sur la branche feature/shogi, depuis origin/main (e4a9016). Publié le 27 octobre 2026, code c7ea4fa, tag production-shogi-2026-10-27. Route : /rubriques/jeux-shogi, dans jeux-strategie. La création de la carte se fait uniquement par la migration ciblée ci-dessous, pas par copie de Ressources.

Interface et préférences

Plateau 9 × 9, pièces monochromes en forme de pentagone, pointe vers l’adversaire. À distance, le camp du joueur connecté est en bas ; la rotation change seulement la vue, jamais les coordonnées du moteur. En local, le joueur 1 est en bas. Pas d’IA, de pendule, de handicap ni de variante de plateau.

Trois modes : classique (un caractère japonais), simplifié (lettre française), intermédiaire (caractère et lettre en coin). Lettres distinctes : roi R, tour T, fou F, or O, argent A, cavalier C, lance L, pion P ; suffixe + après promotion. Une légende et le rappel du mouvement de la pièce sélectionnée sont affichés. Les pièces adverses sont retournées, textes compris.

Par défaut : intermédiaire, destinations légales activées. Une pièce sélectionnée révèle ses destinations légales (y compris les parachutages) si l’aide est cochée. Les captures possibles sont cerclées. Dernier déplacement doré ; roi en échec encadré. L’aide ne montre pas seulement la géométrie : pièces clouées, échec et parachutages interdits sont pris en compte.

• Local : deux profils, appliqués au plateau entier selon le joueur au trait. Ils sont modifiables pendant une sélection ou un choix de promotion.
• Distant : un profil personnel par onglet, indépendant de l’hôte, de l’adversaire et du camp attribué à chaque revanche. Aucune préférence ne circule dans l’API. Les paramètres de salon sont {} ; y envoyer une préférence est refusé.
• Le clic sur une destination valide directement, sauf promotion facultative : Promouvoir/Conserver achève le coup ; Annuler abandonne la sélection. Une promotion obligatoire est automatique. Promotion et capture font un seul coup annulable.
• Une réserve indique toutes les espèces et leurs quantités. Sélectionner une pièce disponible puis une case vide effectue un parachutage.
• Tab, flèches, Entrée/Espace sur le plateau ; Tab pour les réserves et contrôles. Une sélection non envoyée peut être annulée sans accord adverse.
• Nouvelle partie locale demande confirmation. En salon, annulation et revanche exigent le consentement adverse ; l’hôte commence la première partie, puis les rôles de premier joueur alternent. Le lobby est ouvert par défaut sous règles/options et utilise Sente/Gote, sans mentions de couleurs.

Règles retenues

Déplacements classiques des huit espèces, pièces coulissantes arrêtées par les obstacles, saut du cavalier, captures puis réutilisation dans le camp capturant, toujours après dépromotion. La zone de promotion correspond aux trois dernières rangées : départ OU arrivée dans la zone. Or et roi ne sont jamais promus. Promotion obligatoire des pions/lances sur la dernière rangée et des cavaliers sur les deux dernières.

Parachutages : case vide, réserve disponible, pas de pion non promu déjà présent dans cette colonne pour ce camp (nifu), pas de pièce définitivement immobile, pas de mat immédiat par parachutage de pion (uchifuzume). Un pion peut donner échec en étant parachuté si une réponse existe, et un pion déjà posé peut donner mat en avançant. Les autres pièces peuvent mater par parachutage. Aucun coup ne peut exposer son propre roi ; les rois ne se capturent pas dans le moteur.

La partie s’arrête si le joueur suivant n’a aucun coup légal (défaite), sur abandon confirmé à son tour, ou dans les cas suivants :

1. Quatrième occurrence du même plateau (camps/promotions inclus), réserves ET joueur au trait : partie à rejouer. Si un camp a donné échec à chacun de ses coups entre les occurrences, ce camp perd, que la dernière position soit en échec ou après sa levée.
2. Déclaration d’entrée du roi, avant 500 coups : roi du déclarant dans le camp adverse sans échec, au moins dix autres pièces du déclarant dans ce camp, au moins 24 points. Sont comptées les pièces du déclarant dans le camp adverse et sa réserve ; tour/fou 5, autres 1, roi 0. À 31 points : victoire ; de 24 à 30 : partie à rejouer. Les promotions ne changent pas la valeur. Le bouton apparaît uniquement si la déclaration est recevable ; confirmation requise.
3. Après 500 coups individuels, partie à rejouer dès que le joueur au trait n’est plus en échec. Le mat et la répétition sont évalués avant cette fin.

Une partie à rejouer reste affichée ; les joueurs déclenchent eux-mêmes Nouvelle partie. Les salons ne ferment pas à la fin : limites communes d’inactivité, déconnexion et durée absolue conservées.

Adaptations pédagogiques explicites : coups et déclarations illégaux bloqués au lieu d’une défaite pour faute, annulations possibles, pas de tirage traditionnel du premier joueur, pas de chronométrage, pas d’adjudication manuelle d’impasse par accord. Une nouvelle partie locale repart avec le joueur 1 ; l’alternance d’identités est celle des salons. Abandon disponible uniquement au tour du joueur dans cette interface.

Sources consultées le 27 octobre 2026 : Fédération française, règlement de la Fédération japonaise et correctif du 1er octobre 2025. Le choix est la déclaration 31/24 points de ce règlement, pas une règle alternative 27 points.

Moteur et protocole

src/lib/shogi.mjs est pur, sans DOM, réseau ni dépendance ajoutée. Shogi.svelte gère rendu, préférences, sélection et historique local. online/games.mjs déclare shogi → jeux-shogi, options {}, présentation monochrome:true. online/adapters.mjs réutilise le même moteur serveur ; OnlineLobby.svelte adapte les noms des camps pour les jeux monochromes, sans modifier le fonctionnement coloré des autres jeux. La page est intégrée à src/pages/rubriques/[id].astro et respecte les droits du catalogue.

État :

• board[81] : null ou {type,owner,promoted}. Indice = ligne × 9 + colonne ; origine en haut à gauche, joueur 0 vers ligne 0, joueur 1 vers ligne 8. Types internes K/R/B/G/S/N/L/P (distincts des lettres françaises).
• hands[2] : quantités par type R/B/G/S/N/L/P, jamais de roi ni de promotion.
• player, moves, last, over, winner (0/1/null), reason.
• records : signatures des positions et {by,check} pour la répétition et l’échec perpétuel. La position initiale compte ; une annulation restaure aussi ces enregistrements.

API du moteur : initialShogi, legalShogiMoves, playShogi, inCheck, enteringKing, positionKey ; fonctions de libellés pour l’affichage. Les transitions ne modifient pas l’état d’entrée. Les contrôles du serveur déduisent le camp depuis playerIndex, jamais depuis le client.

Commandes de salon : op:'play', action:... avec :

{type:'move', from:54, to:45, promote:false} // promote est un booléen obligatoire
{type:'drop', piece:'P', to:40}
{type:'resign'}
{type:'declare'}

Une sélection et un choix de promotion non validés restent uniquement dans le composant. Recharger les efface, mais conserve un coup validé à distance. Le contrôle du mat par pion parachuté teste les réponses par déplacement : un échec de pion adjacent ne peut pas être interposé par un parachutage ; cela évite une récursion des tests de mat.

Stockage et limites

• localStorage['shogi-preferences-v1'] : {profiles:[{mode,hints},{mode,hints}]} ; profils locaux seulement.
• sessionStorage['shogi-personal-v1'] : {mode,hints} du joueur en ligne, indépendant par onglet. Persiste au rechargement, pas après fermeture définitive de l’onglet. Les préférences restent personnelles après une revanche et un changement de camp.
• sessionStorage['shogi-online-seat-v1'] : clé de place commune aux salons ; mêmes protections, délais et limites que Jeu à distance.
• Les données de préférences sont validées à la lecture ; un stockage indisponible laisse jouer et affiche un avertissement lors de l’enregistrement.
• Pas de sauvegarde durable de partie locale ou serveur. Les salons restent en mémoire et disparaissent au redémarrage. Pas d’import de position dans l’interface, d’export de notation, de spectateur ni de mode ordinateur.

Une future IA devra utiliser les coups légaux du moteur dans un Worker annulable, intégrer réserves/promotions/trait à ses clés et tenir compte de la répétition et des échecs continus. Aucun niveau de jeu ni budget de recherche n’est implémenté.

Migration et retour arrière

Dans la version sélectionnée, contre les données de l’installation destinataire :

node scripts/migrate-shogi.mjs          # contrôle, ne modifie rien
node scripts/migrate-shogi.mjs --apply  # ajoute la seule rubrique absente
npm run catalogue:refresh

Préconditions : catégorie unique d’id jeux-strategie, type category ; aucun id jeux-shogi incompatible ou dupliqué ; aucun dossier Shogi orphelin à l’emplacement prévu. Recherche par identifiant, même si le dossier parent a été renommé. Liens symboliques refusés. Avant actualisation, contrôler les fichiers non déclarés selon le workflow général : la migration ne lance pas un import global elle-même.

Seule création : <catégorie de stratégie>/Shogi/_rubrique.json, accès déclaré public (toujours soumis à celui du parent), ordre 80. Aucun fichier parent, ancien jeu, bloc, date, tag ni secret existant n’est réécrit. Une seconde exécution conserve intégralement une rubrique compatible déjà présente, y compris ses modifications éditoriales et droits. La migration Shogi a été appliquée lors de la livraison du 27 octobre 2026 ; voir le compte rendu de publication.

Avant livraison : sauvegarder les données sur l’installation destinataire, vérifier le plan, compiler le code sélectionné, organiser la bascule avec le responsable de livraison. Retour arrière : remettre la version de code précédente ; rendre la rubrique jeux-shogi indisponible via l’administration si nécessaire, sans supprimer ses éventuels nouveaux contenus. Ne retirer le dossier nouvellement créé que s’il est toujours vide hormis sa fiche initiale inchangée, après contrôle et sauvegarde. Un redémarrage Node ferme tous les salons, pas seulement Shogi.

Démonstration isolée et validation

Dans un worktree neuf sans Ressources : npm ci, puis node scripts/setup-shogi-demo.mjs. Ce script refuse si Ressources existe ; il crée un catalogue synthétique, sans documents ni secrets, et .work pour les tests. Ne jamais le lancer pour peupler la production. Le serveur de ce chantier écoute seulement sur 127.0.0.1:4325 ; aucun autre serveur arrêté.

Validation : 219 tests réussis, compilation réussie. Recettes HTTP/SSE des huit jeux réussies sur le développement et sur le serveur compilé isolé (port 4326, arrêté après test). Tests : npm test, npm run build. tests/shogi.test.mjs : 15 tests de règles, position initiale (30 ouvertures et 900 positions à deux coups), mouvements/promotions, immutabilité, réserves, restrictions, clouage, roi, mat par pion, répétitions et déclaration. tests/shogi-migration.test.mjs : création, simulation sans écriture, relance, conservation des champs, refus des conflits. tests/online-games.test.mjs inclut deux parties complètes Shogi générées légalement, synchronisation, annulation terminale, droits, alternance et reconnexion. Les recettes HTTP/SSE communes incluent désormais huit jeux.

Recette navigateur réalisée : trois affichages, profils locaux différents, aide désactivée pour le second joueur ; capture du fou, choix de promotion, recapture dépromue, parachutage et annulation ; flèches ; rechargement conservant les profils. Deux onglets distants : orientations opposées, préférences indépendantes conservées au rechargement, promotion synchronisée, annulation consentie, abandon terminal, salon conservé, revanche et premier coup invité. Tests de tactile physique et de charge non réalisés. Après publication : recette HTTP/SSE des huit jeux réussie sur https://esuong-maths.fr ; page, sélection et premier coup vérifiés dans le navigateur. Les parcours détaillés à deux onglets ci-dessus ont été effectués localement, pas sur deux appareils/réseaux publics.

Livraison : périmètre, version, effets sur les données et recette de publication (../LIVRAISON_SHOGI.md).

Extraction commune dans la branche Mini Shogi (non publiée)

shogi.mjs devient une façade stable : mêmes exports, état 81 cases, règles 31/24, répétition et limite 500 coups. Le code des règles est extrait dans shogi-core.mjs, sans changement de paramètres du Shogi classique. Shogi.svelte monte désormais ShogiBoard.svelte en 9 × 9 ; les anciennes clés de préférences et de place restent intactes. Mini Shogi possède sa page séparée, son moteur configuré en 5 × 5 et ses propres clés. Cette extraction fait partie du chantier Mini Shogi non publié, pas de la version de production historique c7ea4fa.

Ajustement visuel (branche Mini Shogi, non publié) : caractères et lettres des pièces promues en rouge foncé, y compris la lettre en coin. Capture puis parachutage rétablissent le texte normal puisque la promotion est perdue. Le choix facultatif Promouvoir/Conserver apparaît dans une fenêtre superposée au plateau (deux variantes), avec Annuler et Échap ; focus placé dans la fenêtre puis rendu à la case. Les options hors plateau restent accessibles, la fenêtre n’est pas une modale bloquant toute la page.