L'editeur d'une ligne n'a plus de bouton : sa machinerie part avec lui. Seule
la liste des dossiers en est gardee (folderSelect), pour que le champ Folder du
formulaire reste un choix et non une faute de frappe.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Un crayon ouvre un formulaire pre-rempli : tous les champs modifiables a la
fois, un seul Save, donc UN commit au lieu d'un par champ ('setfields',
plusieurs PatchEntryField dans le meme CommitChange).
L'icone quitte le menu de l'entree pour ce formulaire : From site (recherche),
Image... (galerie, reduite a 128 px, provenance custom) et Remove.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sept champs faisaient sept cartes, chacune contenant un champ avec son propre
fond et ses coins - rectangle dans rectangle. Une carte, des lignes dedans, le
champ reduit a son trait de saisie ; le bouton Save sort de sa carte.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Android ne laisse pas choisir l'app qui passe devant : moveTaskToBack
ramenait souvent l'ecran d'accueil. Le coffre se reverrouillait aussi
apres 30 s, avant qu'on revienne chercher le mot de passe.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- OpenContainer reutilisait la cle de l'ancien mot de passe : jamais tant
qu'un nouveau n'est pas verifie
- un essai rate vidait FKey (parametres out TBytes) : derivation dans des
locales, rangee seulement apres succes
- Save coffre ouvert : verification immediate (DoSync), le bon mot de passe
est range dans le coffre scelle ; coffre ferme, le champ est grise
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
GitHub parle la meme API des contenus (base64, sha, corps du PUT) : meme
chemin, reconnu a api.github.com/repos/. User-Agent pose partout (GitHub
refuse sans). Un depot public est refuse avant toute lecture ou ecriture,
Gitea comme GitHub : l'historique garde tous les instantanes chiffres.
Telephone : github.com/O/R se convertit en URL d'API et inversement.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- de sur le champ mot de passe (nouvelle entree et modification), tirage
crypto.getRandomValues avec rejet
- Download vault sans reglages ouvre les reglages
- 404/401 tranches (jeton refuse, utilisateur ou depot inexistant, fichier
absent) et mauvais mot de passe de synchro : les reglages s'ouvrent avec
le message en rouge
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
En release le telephone ne sait que reprendre le coffre du depot : l'ecran
d'accueil n'offre plus que Download vault, et RegisterLocal refuse aussi.
Depot vide (404) ou conteneur illisible : rien n'est cree.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le scanner du systeme demandait avec quoi ouvrir le lien. L'app ouvre la
camera arriere, decode une image sur quatre et remplit URL + jeton des
qu'un lien pmserver://sync est lu. Rien n'est enregistre avant Save.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le poste genere le QR (DelphiZXingQRCode, Apache 2.0) depuis ses prefs :
URL + jeton, jamais le mot de passe de synchro. Le telephone lit le texte
copie par l'appareil photo et remplit les champs ; Save valide.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le formulaire New entry n'avait pas le champ et AddEntry ecrivait
totp_secret = '' en dur : il fallait enregistrer l'entree puis la rouvrir
pour poser un second facteur, alors que l'editeur portait deja le champ.
Meme intitule que l'editeur ("2FA secret"), masque pour une note comme
site et identifiant, et achemine par &o= — t, s, u, p, k, d etaient
pris.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le chien de garde mesurait la duree TOTALE, alors que son message dit
"no reply from the server". Sur un coffre devenu gros - 286 Ko - la
reponse arrivait en 841 ms et les vingt secondes suivantes partaient dans
la derivation de la cle puis l'affichage : il criait donc a l'absence de
reponse alors que tout avait reussi, cache ecrit compris. Un faux echec
est pire qu'un vrai, il apprend a se mefier de ce que l'application dit.
Il est desarme des que le statut HTTP est connu, quel qu'il soit : ce qui
suit ne depend plus du reseau, et le voile est leve par le finally.
Au passage, les boutons des reglages n'avaient pas de margin-top : le
champ du code et ses deux boutons se touchaient et se lisaient comme un
seul bloc. Les piles de l'accueil ont leur gap ; ici les elements se
suivent en flux normal, donc c'est au bouton de reserver sa place.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"+ new folder" n'existait qu'a l'edition. Creer une entree ET son dossier
demandait donc trois gestes - creer, rouvrir, changer le dossier - pour
ce que le meme controle sait faire ailleurs en un seul. L'asymetrie ne se
voyait qu'en s'en servant.
Deux cas que le chemin de l'edition ne posait pas : un champ laisse vide
et le marqueur interne du "+ new folder" retombent tous deux sur All -
sans quoi valider sans rien taper aurait envoye au coffre un nom de
dossier fait d'un caractere de controle.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Il vit en bas des reglages, apres tout le reste, et demande deux appuis :
un effacement sans retour ne se declenche pas sur un doigt qui glisse.
Absent en release, et pas seulement cache : la commande du pont n'est pas
compilee et Delphi ne devoile la section que dans une version de
debogage. Le bouton ne peut donc pas reapparaitre par accident. Verifie -
Release compte 8060 lignes contre 8072 en debug, soit exactement ce bloc.
DropLocalVault efface le cache, le conteneur local et le drapeau
d'attente, chacun sous son propre try : un fichier absent ou verrouille
ne doit pas empecher les deux autres de partir. Les reglages du depot
restent - c'est le coffre qu'on jette, pas la facon d'aller le rechercher.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Retenir le focus au mousedown fait atteindre la cible du premier coup,
mais laissait le clavier ouvert : apres "Open vault" il restait dresse
par-dessus la liste. Les deux moities vont ensemble - on retient le focus
le temps de l'appui, on le lache des que l'action est partie.
Sauf si le bouton agit sur le champ lui-meme : un oeil qui devoile, une
fleche qui deroule. Ceux-la vivent dans la meme rangee que le champ, et
replier le clavier apres eux obligerait a le rouvrir pour continuer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le toast vit a bottom: 14px, donc sous le clavier des que celui-ci est
leve : il ne se decouvrait qu'en quittant l'ecran, quand le clavier se
repliait. Et depuis qu'un appui sur un bouton ne vole plus le focus, le
clavier RESTE ouvert - ce qui a rendu systematique un defaut jusque-la
occasionnel.
Il remonte au-dessus de la reserve que body.typing menage deja pour le
clavier : meme mesure, meme raison.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Un bouton touche pendant qu'un champ a le focus recevait d'abord le
blur : le clavier se repliait, la reserve de body.typing disparaissait,
la page remontait - et le bouton n'etait plus sous le doigt quand le clic
partait. Il fallait appuyer deux fois, la premiere ne servant qu'a fermer
le clavier.
Empecher le defaut du mousedown empeche le TRANSFERT DE FOCUS, pas le
clic : le champ garde le curseur, rien ne bouge, et l'appui atteint sa
cible du premier coup. Pose sur toute la page - le piege n'a aucune
raison d'etre propre aux reglages.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le toast n'avait pas de z-index : il se peignait DERRIERE l'ecran des
reglages, qui est a 80. "Unlock code set" partait bien, mais sous la
page, et ne se decouvrait qu'en sortant - quand il ne s'etait pas deja
eteint. Un message qui ne se voit pas la ou on l'a provoque ne sert a
rien.
La section du code de deverrouillage ne parait plus que coffre ouvert.
Poser comme retirer exigent le clair en main : coffre ferme, les deux ne
pouvaient que refuser, et proposer une action qui refuse toujours vaut
moins que ne rien proposer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le coffre ouvert ne prouvait rien : il peut l'etre depuis une heure et
rester a l'ecran. Quiconque trouvait le telephone dans cet etat levait la
protection en deux appuis, sans que rien ne le lui demande.
Le code courant voyage maintenant avec la demande, et Delphi le compare a
FPinSealed - ce sous quoi le cache est REELLEMENT scelle, pose seulement
par une ouverture reussie, jamais par un champ.
Fermee au passage : SetUnlockCode('') retirait le code en silence, ce qui
contournait le controle qu'on vient de poser.
Le FBusy de ClearUnlockCode ne sort plus sans un mot - une sortie muette
se lit comme une reussite.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Un refus s'affichait du meme gris qu'un etat : "Master password: 8
characters at least" se lisait comme "Vault on this device", et rien ne
disait que l'application venait de refuser. StatusErr le met en rouge -
deux procedures plutot qu'un drapeau devine du texte, parce que trier des
messages sur leur contenu a deja detruit un cache dans ce projet. C'est
l'appelant qui sait s'il refuse.
La croix des champs etait calee a top: 8px, en compensation du margin-top
du champ. Les piles annulent ce margin depuis qu'on y a unifie
l'espacement, et la croix restait donc 8 px trop bas. Elle s'ancre
desormais au bord INFERIEUR, le seul que le champ touche dans les deux
cas.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le mot de passe de creation scellait le conteneur local ET pretendait
sceller l'instantane du depot. Un coffre cree ici publiait donc sous son
propre mot de passe, que le poste ne savait plus ouvrir - et le
rafraichissement echouait avec "wrong password" sur un depot pourtant
intact.
FVaultPwd ouvre le conteneur local et s'arrete la. Le secret du depot vit
dans les reglages, doit etre le meme sur tous les appareils, et c'est lui
seul qui ouvre et rescelle l'instantane.
Les deux ne se rencontrent qu'a UN endroit, la reconciliation : le
conteneur local s'ouvre sous le sien, puis la cle est jetee avant de
toucher au depot - la garder rescellerait le depot sous le mauvais
secret. Ailleurs ils ne se croisent jamais : un coffre ne ici ne publie
pas, un coffre publie n'a plus de conteneur local.
Migration : rien a rechiffrer. Les coffres existants ont simplement les
deux valeurs egales, et cessent d'etre forces de le rester.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"Local vault unreadable" laissait croire a une corruption, donc a une
perte, alors que le coffre est intact dans le depot. Quand Android a
lui-meme detruit la cle - verrouillage d'ecran retire ou reinitialise -
l'application le dit maintenant, et dit aussi que rien n'est perdu.
Le tri passe par un drapeau pose la ou l'invalidation se constate, pas
par un test sur le texte du message : c'est ce tri-la, fait sur des
chaines, qui detruisait autrefois le cache en se trompant.
Le code de deverrouillage accepte un mot de passe, et l'a toujours
accepte - aucune validation n'a jamais impose des chiffres. Seul
inputmode="numeric" le laissait croire, et le clavier numerique
decourageait d'essayer. Clavier complet, libelles et note mis a jour.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Un champ porte son propre margin-top de 8 px, dont il a besoin dans les
reglages ou les champs se suivent en flux normal, sans gap. Dans une
pile, ce margin s'ajoutait au gap : deux champs se retrouvaient a 16 px
l'un de l'autre, un champ et un bouton a 8. Dans une pile, c'est le gap
qui commande.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
L'espace de 8 px vit A L'INTERIEUR de chaque pile. "Create vault" et
"Download vault" etaient dans deux piles voisines et se touchaient donc,
tandis que "Download vault" et "Settings", dans la meme pile,
respiraient. Un margin entre piles adjacentes suffit.
L'ordre suit maintenant les frequences et non l'ordre du code : aller
chercher le coffre, regler, creer en dernier. La creation etait en tete
parce que son bloc etait ecrit en premier dans la page.
L'accent suit le geste attendu - il va a "Download vault" des qu'un depot
est configure, et ne reste sur la creation que lorsqu'il n'y a rien a
aller chercher.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deux branches de l'ouverture posaient le code a partir de ce qui trainait
dans les champs.
La premiere appliquait un "nouveau code" depose par les reglages. Elle
n'exigeait rien de celui qui le deposait : n'importe qui tenant le
telephone deverrouille pouvait en poser un, et c'est le proprietaire qui,
en ouvrant son coffre, l'appliquait contre lui-meme.
La seconde rescellait sous le code tape des que le cache ne l'etait plus,
ce qui DEFAISAIT LE RETRAIT : on retirait le code, le champ le portait
encore, et l'ouverture suivante le reposait sans qu'un mot le dise. Le
premier octet du cache le disait - VER_PIN apres un retrait annonce
reussi.
Poser et changer passent maintenant par SetUnlockCode, jumeau de
ClearUnlockCode : geste explicite, coffre deja ouvert - donc code courant
connu - et effet immediat. Le champ de l'accueil ne veut plus dire qu'une
chose, "ouvre avec ceci", et ne parait que lorsqu'un code est pose.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Il y en avait deux, "Settings" et "Log", et le second a fini par ouvrir
le premier depuis que le journal a demenage dans les reglages. Un bouton
nomme "Log" qui ouvre "Settings" se ment sur son etiquette.
Settings redevient VISIBLE EN PERMANENCE. Le cacher des qu'un coffre
existe laissait l'accueil sans aucune porte vers les reglages - et c'est
precisement quand le coffre refuse de s'ouvrir, code faux ou adresse
fausse, qu'on en a besoin avec le journal. Ce n'est pas un doublon de la
roue dentee : celle-ci est DANS le coffre, ce bouton est sur l'accueil,
jamais cote a cote.
En release, c'est desormais le bouton des reglages qui s'efface, l'appui
long sur la ligne d'etat le ramenant comme avant.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Il n'affichait rien, et pas parce qu'il etait vide. togglePanel
parcourait ['cfg','log'] et cherchait pour chacun le bouton qui le
commande - or btnCfg a perdu son data-panel le jour ou les reglages sont
devenus un ecran. La premiere iteration levait sur un null, et le journal
n'etait jamais deplie, quel que soit le chemin.
Il vivait de plus sur l'accueil : "Show the log" refermait les reglages
pour le deplier derriere, c'est-a-dire sur un ecran qu'on ne regarde plus
des que le coffre est ouvert. Il est maintenant DANS les reglages, deplie
sur place - le seul ecran atteignable depuis l'accueil comme depuis le
coffre.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le garde pose juste avant fermait la seule porte : le bouton Sync ne vit
que sur l'accueil, et une fois le coffre ouvert on est sur la liste, ou
il n'existe pas. Synchroniser devenait impossible des qu'un code etait
pose. Sync ouvre donc le coffre - ce qui verifie le code, seul LoadVault
le peut - et OpenLocalNow reprend la synchronisation ou elle s'est
arretee. Le drapeau est consomme des sa lecture, pour qu'un code faux ne
laisse pas une synchronisation en embuscade.
Le champ "new unlock code" quitte l'accueil : les reglages posent et
changent le code, il y faisait doublon sur l'ecran ou l'on veut seulement
ouvrir. Il reste dans la page, cache - c'est lui que "Set this code"
remplit avant pushConfig.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
r-zakarya