« errorcode 104 » n'était pas un refus : mkdir sur un dossier déjà là

Sylvain a rapporté un errorcode 104 en testant l'envoi. Le code vient du
protocole PFTP de Polar, et pftp_error.proto du SDK officiel le nomme :
104 = DIRECTORY_EXISTS. Ce n'est donc pas un refus de la montre — la session BLE
s'était parfaitement ouverte, le transport fonctionnait, et c'est notre séquence
de mkdir qui n'était pas idempotente.

L'hypothèse fautive était écrite noir sur blanc dans parseSteps : « aucun des
deux n'existe d'avance pour une date neuve ». Vrai d'une date neuve, faux dès le
second envoi vers la même date — exactement ce que Sylvain venait de faire après
avoir réussi un premier envoi.

Un mkdir qui bute sur 104 est désormais considéré comme satisfait, à la manière
d'un mkdir -p : le dossier est là, c'est tout ce qu'on lui demandait. Strictement
limité à la création de dossier — un put de fichier n'est jamais avalé, 105
FILE_EXISTS signifierait que l'objectif est déjà écrit et l'appelant doit le
savoir.

Le renvoi n'est pas passé sous silence pour autant : ecrire() rend un drapeau
dossierPreexistant, le plugin le résout en alreadyExisted, et l'UI de coach
affiche « Un objectif existait déjà à cette date. Redémarrer la montre pour que
le nouveau s'affiche. » C'est la contrepartie de l'index en cache constaté le
31/08 — sans cet avertissement, l'envoi annoncerait un succès que la montre ne
montrerait pas.

Les codes PFTP sont définis dans PolarPftpStep.swift, donc couverts par les
tests Linux : 87 tests verts, dont 3 nouveaux qui vérifient que 104 est
satisfaisant pour un mkdir et que 103, 105, 106 et 108 restent des échecs.

⚠️ CoachPolarBLE.swift n'est pas compilable ici — Capacitor et le SDK Polar
n'existent pas sur Linux. La modification du plugin est à vérifier au prochain
build Xcode ; la logique des codes, elle, est testée.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

tests-linux/Tests/CoachModelTests/PolarPftpStepTests.swift

@@ -290,3 +290,32 @@ extension PolarPftpErrorTests {
                       "l'hypothèse du lien exclusif doit être énoncée")
     }
 }
+
+// MARK: - Codes d'erreur PFTP (01/09/2026)
+
+/// « errorcode 104 » rapporté par Sylvain sur un second envoi vers la même
+/// date. Ce n'était pas un refus de la montre : la session BLE s'était ouverte,
+/// et c'est notre séquence de `mkdir` qui n'était pas idempotente.
+final class PftpCodeTests: XCTestCase {
+
+    func test104EstBienDirectoryExists() {
+        XCTAssertEqual(PftpCode.directoryExists, 104)
+    }
+
+    func testUnMkdirSurDossierExistantEstSatisfait() {
+        XCTAssertTrue(PftpCode.mkdirEstSatisfait(par: 104))
+    }
+
+    func testLesAutresCodesRestentDesEchecs() {
+        // 103 NO_SUCH_FILE_OR_DIRECTORY : le parent manque, l'ordre des mkdir
+        // est en cause — surtout pas à avaler.
+        XCTAssertFalse(PftpCode.mkdirEstSatisfait(par: 103))
+        // 105 FILE_EXISTS : l'objectif est déjà écrit. L'appelant DOIT le
+        // savoir — le remplacer n'est visible qu'après redémarrage de la montre.
+        XCTAssertFalse(PftpCode.mkdirEstSatisfait(par: 105))
+        // 106 OPERATION_NOT_PERMITTED, 108 TIMEOUT : de vrais refus.
+        XCTAssertFalse(PftpCode.mkdirEstSatisfait(par: 106))
+        XCTAssertFalse(PftpCode.mkdirEstSatisfait(par: 108))
+        XCTAssertFalse(PftpCode.mkdirEstSatisfait(par: 0))
+    }
+}