Bloc 99 — 🐛 Transfert Stuff → Paramètres joueur annulé tout seul (tampon de version dans les réglages)

[magicgg91]

Le bug, tel qu'un joueur le vit

Un transfert depuis le simulateur Stuff vers les paramètres du joueur pouvait revenir à zéro tout seul, peu après le chargement de la page. C'est le même défaut qui rendait player-settings-panel.test.tsx instable en CI depuis le Bloc 93 — je l'avais signalé sans le corriger.

J'ai capturé un échec réel avant de toucher au code, pour ne pas partir d'une hypothèse : c'est bien le test reflects an external equipment-skills transfer live qui tombe, sur Attaque avec équipement attendu 12.5, reçu 0. Le transfert est écrasé, pas ignoré.

La cause

safePlayerSettings étalait l'objet stocké en entier :

return { ...fallback, ...parsed, /* … */ };

parsed contient v, le tampon de version — de la comptabilité de stockage, absente du type PlayerSettings. Il repartait donc à l'intérieur des réglages, et TypeScript ne le voyait pas (un spread de Partial<PlayerSettings> & { v?: number } passe).

Conséquence : toute comparaison entre la valeur en mémoire et la valeur relue est inégale par construction, quel que soit le contenu. Vérifié sur le vrai code avant correctif :

clés en trop : [ 'v' ]
garde égale  : false      ← sur des réglages pourtant identiques

La garde de syncFromStorage en est une :

setSettings((current) =>
  JSON.stringify(current) === JSON.stringify(next) ? current : next,
);

Le panneau répondait donc à sa propre sauvegarde par un nouvel objet. Le cycle écriture/diffusion supplémentaire qui suivait portait un instantané d'avant le transfert — et c'est lui qui écrasait l'écriture externe arrivée entre-temps.

Le correctif

v est séparé des réglages à la lecture, et sert uniquement à décider de la migration v1 → v2 comme avant :

const { v: storedVersion, ...saved } = JSON.parse(raw) as Partial<PlayerSettings> & { v?: number };

Rien d'autre ne change : la sérialisation continue d'estampiller, replaceEquipmentSkills aussi.

Mesure — comparaison contrôlée

Même charge CPU (6 boucles saturantes), même N, 60 exécutions du fichier de test dans chaque bras, le bras « avant » tourné sur le code d'origine restauré :

	échecs
avant	6 / 60
après	0 / 60

0/60 ne prouve pas l'impossibilité — c'est une mesure, pas une démonstration. Mais la cause, elle, est corrigée de façon déterministe, et c'est ce que verrouillent les deux tests ajoutés.

Tests

• safePlayerSettings rend les réglages seuls : mêmes clés que defaultPlayerSettings, et la comparaison JSON que fait syncFromStorage est égale sur des réglages inchangés.
• Un montage ne produit plus qu'une seule sauvegarde/diffusion au lieu de deux — c'est le cycle en trop, dont l'instantané périmé causait l'écrasement.

Les deux rougissent sur le code d'avant ('v' en clé surnuméraire ; 2 diffusions au lieu de 1), donc ni l'un ni l'autre n'est décoratif.

Validation

• pnpm lint + typecheck + prettier : propres
• pnpm test : 1298 tests verts (+2)
• pnpm build : succès
• pnpm test:e2e : 87/87 verts (4,9 min), sur une base e2e recréée à neuf

🤖 Generated with Claude Code

https://claude.ai/code/session_01HJgsDSfsCbbn8cochFGwe2

---

Generated by Claude Code