ZXing.Delphi declarait rgbIndex/luminanceIndex en Byte dans les conversions
octets bruts -> luminance : au-dela de 255 ils repassaient a 0, la boucle ne
finissait jamais. L'APK n'y passait pas (CreateFromBitmap). Mesure apres
correctif : 60 ms sur un ecran 1920x1080 avec TRY_HARDER, 86 ms sans QR.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Un jeton faux faisait repondre 401 a GitHub avant tout verdict : le refus
d'un depot public ne pouvait pas s'exprimer. Public = visible en anonyme.
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>
Delphi ecrivait android:debuggable=true meme en Release : sur un telephone
avec le debogage USB actif, adb run-as ouvrait le dossier prive de l'app.
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>
$p et $outDir etaient relatifs (".\Android64\..."). Lance depuis un
autre dossier que la racine du depot, build-apk compilait bien dans le
depot mais repack empaquetait un dossier inexistant sous le repertoire
courant, y semait des copies de ressources, puis echouait sur un
Copy-Item ("Container cannot be copied onto existing leaf item").
Les deux chemins partent maintenant de $PSScriptRoot. Ca ne se voyait
pas tant que le script etait appele depuis la racine.
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>
L'APK signe existe. Le chemin -Release n'avait jamais tourne et a butte
quatre fois - dossier de mise en scene absent, volume plein, cinq
doublons refuses par aapt, ressources generees jamais rangees. Toutes des
choses que seule une release partant d'un terrain vierge pouvait
rencontrer.
La verification de la section Debug est corrigee : chercher wipelocal
dans le .so ne prouve rien, la page HTML embarquee la contient dans les
deux configurations. Seule la chaine du gestionnaire Pascal tranche, et
en UTF-16LE. La garantie est "inatteignable et sans effet", pas
"absente".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le Build depose a plat dans Android64\<Config>\ les ressources d'Android
- styles.xml, strings.xml, les variantes -v21/-v31, l'icone adaptative -
et c'est le Deploy qui devrait les ranger dans res\. Il le fait en DEBUG
et pas en RELEASE, alors que les proprietes Android_* du .dproj sont
communes aux deux configurations et qu'aucune entree de deploiement ne
les nomme.
Sans elles, aapt refuse le paquet sur "@style/AppTheme" introuvable : le
manifeste reference un theme que plus rien ne definit.
Le script les range donc lui-meme, avant nos propres ressources pour que
notre colors.xml garde le dernier mot. La correspondance nom-fichier vers
sous-dossier est transcrite explicitement : un fichier nouveau se
signalera au lieu d'etre range au hasard.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le deploiement de Delphi depose a la racine de res\ une copie a plat de
cinq de ses ressources - ic_launcher_*, splash_* - alors que les vraies
sont dans res\drawable\. Or aapt n'accepte que des DOSSIERS a cette
racine : il refusait le paquet entier, "invalid resource directory name",
une fois par fichier.
On les retire avant l'appel, et rien n'est perdu : ce sont des doublons,
verifies presents dans drawable.
Ne se voyait pas en debogage, ou l'arbre traine depuis longtemps. C'est
la premiere release qui l'a montre, comme le dossier de mise en scene
absent juste avant.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
L'arbre de mise en scene est creuse par l'etape Deploy, qui vient APRES
les trois copies qui s'y deversent. En debogage il existait deja, laisse
par un deploiement anterieur, et personne ne s'en apercevait ; pour une
configuration jamais empaquetee, la premiere copie tombait sur un chemin
absent - "Could not find a part of the path".
Les creer d'abord ne coute rien quand elles existent. C'est exactement le
defaut que TESTS.md annoncait : le chemin -Release n'avait jamais tourne.
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>
AUTOLOCK_MINUTES = 3 verrouille apres trois minutes d'inactivite, tandis
que PROBE_EVERY_TICKS = 40 - quinze secondes le battement - demande dix
minutes de coffre OUVERT. Le compteur n'avance que tant qu'il l'est, et
LockVault sort avant de l'incrementer. "Laisser ouvert dix minutes sans y
toucher" verrouillait donc a la troisieme, et le sondage ne partait
jamais.
Ce n'est pas un defaut : le temoin sert pendant qu'on se sert du coffre,
et qui s'en sert le touche. Mais sans le dire, on cherche un point qui ne
peut pas paraitre. La serie demande maintenant de toucher toutes les deux
minutes, et offre la contre-epreuve courte - PROBE_EVERY_TICKS a 8 le
temps d'un essai.
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>
La serie A guette un point orange sur un coffre ne ici, ou il ne peut pas
paraitre : CommitChange voit LLocalOnly, ecrit localement et ne publie
rien - il n'y a pas de depot tant qu'on n'a pas reconcilie. On aurait
conclu a un defaut la ou il n'y a que l'ordre.
C reconcilie, donc C passe avant A.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Plusieurs series agissent sur une entree existante, sans dire d'ou elle
vient. Partir d'un coffre vide les rend ininterpretables : on ne
distingue pas "la modification n'a pas voyage" de "il n'y avait rien a
faire voyager".
Etat de depart : coffre neuf, une seule entree, un seul dossier - All, et
c'est le premier enregistrement qui le fait apparaitre.
Le coffre vide reste un cas a eprouver, mais nomme comme tel : c'est lui
qui a revele que "coffre ouvert" se lisait sur le nombre d'entrees.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La version precedente decrivait une application qui n'existe plus - deux
secrets confondus, des reglages qui n'appliquaient rien sur-le-champ, un
coffre qui s'ouvrait sans rien demander.
Trois series nouvelles : les deux secrets (C), l'ouverture qui demande
quelque chose (D), et le clavier avec le retour d'application (I). F est
reprise en entier. La remise a zero passe desormais par le bouton Debug
plutot que par adb, ce qui rend le scenario deroulable sans machine.
En tete, ce que la seance a vraiment appris : les defauts se tiennent par
la main, et le journal doit se lire AVANT de retenter - la
synchronisation le vide.
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>
r-zakarya