From 9a59c4a0d2a84483e95fd501770d2f3e83cdef1b Mon Sep 17 00:00:00 2001
From: Claude <noreply@anthropic.com>
Date: Mon, 14 Sep 2026 20:27:13 +0000
Subject: [PATCH] =?UTF-8?q?Bloc=2099=20:=20le=20tampon=20de=20version=20ne?=
 =?UTF-8?q?=20fait=20plus=20partie=20des=20r=C3=A9glages=20joueur?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Bug utilisateur : 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 aussi ce qui rendait
player-settings-panel.test.tsx instable en CI depuis le Bloc 93.

Cause. `safePlayerSettings` étalait l'objet stocké en entier, donc `v`
— de la comptabilité de stockage, absente de `PlayerSettings` — repartait
à l'intérieur des réglages. Toute comparaison entre la valeur en mémoire
et la valeur relue était donc inégale par construction, quel que soit le
contenu. La garde de `syncFromStorage` en est une : le panneau répondait
à sa propre sauvegarde par un nouvel objet, et le cycle
écriture/diffusion supplémentaire qui suivait portait un instantané
d'avant le transfert — instantané qui écrasait l'écriture externe arrivée
entre-temps.

Correctif : `v` est séparé des réglages à la lecture (déstructuration),
et sert uniquement à décider de la migration v1 → v2 comme avant. Rien
d'autre ne change : la sérialisation continue d'estampiller.

Mesure, comparaison contrôlée (même charge CPU, 6 boucles saturantes,
60 exécutions du fichier de test dans chaque bras) :

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

0/60 ne prouve pas l'impossibilité, mais la cause est corrigée de façon
déterministe et deux tests l'épinglent : `safePlayerSettings` rend les
réglages seuls (mêmes clés que `defaultPlayerSettings`, comparaison JSON
égale), et un montage ne produit plus qu'une seule sauvegarde/diffusion
au lieu de deux. Les deux rougissent sur le code d'avant.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HJgsDSfsCbbn8cochFGwe2
---
 src/components/player-settings-panel.test.tsx | 50 +++++++++++++++++--
 src/components/player-settings-panel.tsx      | 29 +++++++----
 2 files changed, 66 insertions(+), 13 deletions(-)

diff --git a/src/components/player-settings-panel.test.tsx b/src/components/player-settings-panel.test.tsx
index d1e327e4..0ee25267 100644
--- a/src/components/player-settings-panel.test.tsx
+++ b/src/components/player-settings-panel.test.tsx
@@ -11,10 +11,12 @@ import { NextIntlClientProvider } from "next-intl";
 import messages from "../../messages/fr.json";
 import {
   PlayerSettingsPanel,
+  playerSettingsChangedEvent,
   playerStorageKey,
   replaceEquipmentSkills,
   safePlayerSettings,
 } from "./player-settings-panel";
+import { defaultPlayerSettings } from "../lib/player-settings";
 import { templarRates } from "../lib/gems-templars";
 
 // Bloc 68/F: the league field is a LeagueButtons group now, not a <select>
@@ -32,6 +34,50 @@ describe("PlayerSettingsPanel", () => {
   beforeEach(() => window.localStorage.clear());
   afterEach(cleanup);
 
+  // Bloc 99: the panel used to answer its own save by replacing its state
+  // again. safePlayerSettings spread the stored object wholesale, so the
+  // version stamp `v` — storage bookkeeping, not a setting — came back out
+  // inside the settings, and syncFromStorage's equality guard therefore
+  // compared a value carrying `v` against one that never does: never equal,
+  // whatever the settings held. Each mount then ran a second write/broadcast
+  // cycle whose effect closure held the pre-transfer value, and an external
+  // write landing in that window (the Stuff simulator's transfer button) was
+  // overwritten by it — the transferred skills silently went back to 0.
+  it("Bloc99: hands back the settings alone, without storage bookkeeping", () => {
+    const settings = defaultPlayerSettings();
+    const stored = JSON.stringify({ ...settings, v: 2 });
+
+    expect(Object.keys(safePlayerSettings(stored))).toEqual(
+      Object.keys(settings),
+    );
+    // The comparison syncFromStorage makes, on settings that did not change:
+    // it has to hold, or the panel answers its own write with a new object.
+    expect(JSON.stringify(safePlayerSettings(stored))).toBe(
+      JSON.stringify(settings),
+    );
+  });
+
+  it("Bloc99: settles in a single save, instead of answering its own", async () => {
+    const broadcasts: unknown[] = [];
+    const listener = (event: Event) => broadcasts.push(event);
+    window.addEventListener(playerSettingsChangedEvent, listener);
+    try {
+      render(
+        <NextIntlClientProvider locale="fr" messages={messages}>
+          <PlayerSettingsPanel />
+        </NextIntlClientProvider>,
+      );
+      await waitFor(() =>
+        expect(window.localStorage.getItem(playerStorageKey)).not.toBeNull(),
+      );
+      // One save, one broadcast. A second one is the redundant cycle whose
+      // stale snapshot is what reverted an external transfer.
+      expect(broadcasts).toHaveLength(1);
+    } finally {
+      window.removeEventListener(playerSettingsChangedEvent, listener);
+    }
+  });
+
   it("starts with no league selected", () => {
     render(
       <NextIntlClientProvider locale="fr" messages={messages}>
@@ -252,9 +298,7 @@ describe("PlayerSettingsPanel", () => {
         <PlayerSettingsPanel />
       </NextIntlClientProvider>,
     );
-    expect(
-      screen.queryByRole("group", { name: "Ligue" }),
-    ).not.toBeVisible();
+    expect(screen.queryByRole("group", { name: "Ligue" })).not.toBeVisible();
     const line2 = screen.getByTestId("player-summary-line2");
     expect(line2).toBeVisible();
     // Attaque and Vitesse are temple skills: even with no input yet, their
diff --git a/src/components/player-settings-panel.tsx b/src/components/player-settings-panel.tsx
index 72dffcfa..b92b63c2 100644
--- a/src/components/player-settings-panel.tsx
+++ b/src/components/player-settings-panel.tsx
@@ -44,25 +44,34 @@ function isTemplarKey(key: SkillKey): key is TemplarKey {
 export function safePlayerSettings(raw: string): PlayerSettings {
   const fallback = defaultPlayerSettings();
   try {
-    const parsed = JSON.parse(raw) as Partial<PlayerSettings> & {
-      v?: number;
-    };
-    if (!("equipmentSkills" in parsed)) return fallback;
-    const clanTemple = { ...fallback.clanTemple, ...parsed.clanTemple };
-    if ((parsed.v ?? 1) < currentSettingsVersion && parsed.clanTemple) {
+    // Bloc 99: `v` is separated from the settings here rather than spread
+    // along with them. It is storage bookkeeping — PlayerSettings has no such
+    // field — and letting it ride into the returned object made every
+    // stored-vs-current comparison unequal by construction, whatever the
+    // settings held. The panel's syncFromStorage is one such comparison: it
+    // answered the panel's own save with a fresh object, and the extra
+    // write/broadcast cycle that followed carried a pre-transfer snapshot,
+    // which overwrote an external write (the Stuff simulator's transfer)
+    // that had landed in between.
+    const { v: storedVersion, ...saved } = JSON.parse(
+      raw,
+    ) as Partial<PlayerSettings> & { v?: number };
+    if (!("equipmentSkills" in saved)) return fallback;
+    const clanTemple = { ...fallback.clanTemple, ...saved.clanTemple };
+    if ((storedVersion ?? 1) < currentSettingsVersion && saved.clanTemple) {
       for (const key of templarKeys) {
         clanTemple[key] = Math.max(0, clanTemple[key] - templeBase[key]);
       }
     }
     return {
       ...fallback,
-      ...parsed,
+      ...saved,
       equipmentSkills: {
         ...fallback.equipmentSkills,
-        ...parsed.equipmentSkills,
+        ...saved.equipmentSkills,
       },
-      skillPoints: { ...fallback.skillPoints, ...parsed.skillPoints },
-      templars: { ...fallback.templars, ...parsed.templars },
+      skillPoints: { ...fallback.skillPoints, ...saved.skillPoints },
+      templars: { ...fallback.templars, ...saved.templars },
       clanTemple,
     };
   } catch {