+90
−8
+8
−0
Loading
Remplacer 60 par 120 commençait par envoyer « 1 ». L'API refuse — la
borne basse est de 5 — et la réponse en erreur remettait aussitôt
l'ancienne valeur dans le champ. Il devenait impossible de saisir un
nombre dont un préfixe est hors bornes, c'est-à-dire presque tous : 120,
et toute valeur à trois chiffres, étaient hors d'atteinte.
Le défaut touchait les deux champs. Sur le plafond de sessions, il était
plus sournois que bloquant : taper « 5 » de « 50 » enregistrait
réellement 5, une valeur valide mais non voulue, sans que rien ne le
signale.
Ces deux champs étaient les seuls de l'application à enregistrer sur
« onChange ». Partout ailleurs — plafonds d'organisation, réglages SMTP
— un champ numérique garde un état local et attend une action explicite.
Ils rejoignent cette forme : la saisie est libre, l'enregistrement se
fait à la sortie du champ, ou sur Entrée.
Un nombre ne veut rien dire tant qu'il n'est pas fini de taper. C'est la
raison du brouillon local, pas le confort.
Les bornes sont désormais vérifiées AVANT l'aller-retour réseau, et le
message dit d'abord que rien n'a été enregistré, ensuite la règle : le
champ conserve la saisie refusée pour qu'on puisse la corriger sans tout
retaper, et l'écran ne doit pas laisser croire à un enregistrement.
L'accusé de réception disait « Bac à sable ouvert. » quelle que soit
l'action, y compris pour un simple changement de durée. Il nomme
maintenant ce qui a été enregistré.
Vérifié dans le navigateur sur le geste rapporté : sélectionner 60,
taper 1 — le champ garde « 1 », sans erreur ni retour en arrière — puis
120, quitter le champ, et le serveur porte 120. Refus de 3 et de 2000
sans requête, acceptation de la borne haute 1440, champ vidé qui rend
la main au défaut.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>