Le garde de DoSync ne couvrait que l'empreinte, et les deux protections
s'excluent : un cache scelle par un code porte VER_PIN, donc
VaultNeedsAuth y est FAUX. Synchroniser reconstruisait le coffre depuis
le depot et l'affichait sans que le code soit demande - il ne gardait
qu'un bouton sur deux.
Exiger un champ rempli n'aurait rien valu : le depot est scelle par le
mot de passe de sync, pas par le code, donc rien ici ne le confronte a
quoi que ce soit et n'importe quelle frappe serait passee. Seul LoadVault
sait si le code est le bon, et c'est "Open vault" qui l'appelle - d'ou le
renvoi vers lui.
Place AVANT ReconcileWithRemote et PublishPending, qui sortent de DoSync
par leurs propres chemins.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La roue dentee de la liste mene au meme ecran : le repeter sur l'accueil
n'encombrait que l'accueil.
Mais pas de suppression pure et simple. Sans coffre local, la liste
n'existe pas - donc la roue dentee non plus - et il faut bien pouvoir
saisir l'adresse du depot pour aller le chercher. Le bouton parait donc
exactement quand "Open vault" ne parait pas, sur le meme signal.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pref DPAPI lazyOn, reprise par RestoreLazyBar depuis FormCreate - apres
le theme, parce que la barrette se peint elle-meme, et apres le cablage
de OnTrayRestore, dont depend son bouton Open.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Quand la barrette est allumee, elle est souvent la seule chose de
l'application a l'ecran : revenir au coffre ne doit pas demander de
retrouver l'icone du tray.
Le menu d'opacite passait derriere : le battement qui repose la barrette
en tete de la bande TOPMOST cinq fois par seconde recouvrait le menu que
la barrette venait d'ouvrir - lui aussi dans cette bande. TrackPopupMenu
est modal, donc le minuteur battait pendant tout ce temps. Il s'arrete
maintenant le temps du menu.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TOPMOST n'est pas un rang, c'est une bande. La barre des taches y est
aussi, et cliquer son fond vide la remonte en tete de cette bande : une
barrette posee dessus passe DERRIERE et semble avoir disparu. Le meme
battement de 200 ms la repose.
Traine depuis un bouton : les boutons sont subclasses, et DragDetect
tranche entre clic et glissement en respectant le seuil regle par
l'utilisateur. Sur un clic, on envoie BN_CLICKED a la place du bouton -
DragDetect a avale le WM_LBUTTONUP, lui rendre la main le laisserait
enfonce pour toujours.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pref DPAPI lazyPos, ecrite sur WM_EXITSIZEMOVE - une ecriture par
deplacement, pas une par pixel parcouru.
La position n'est reprise que si MonitorFromRect la trouve encore sur un
ecran. La barrette n'a pas d'entree dans la barre des taches : une
position heritee d'un ecran debranche, ou d'une resolution changee, la
laisserait hors du bureau et definitivement irrecuperable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Clic droit dessus -> 100/75/50/25 %, persiste en pref DPAPI. Pas dans
settings_json : la barrette peut etre allumee coffre ferme, ou aucune
session n'existe pour lire les reglages du serveur.
Le survol est sonde toutes les 200 ms plutot que suivi par
TrackMouseEvent : avec quatre fenetres enfants, passer de la barrette a
un bouton envoie deja un WM_MOUSELEAVE au parent, et il faudrait suivre
la souris sur les cinq fenetres pour recoller les morceaux.
Le menu appartient a la fenetre message-only : TrackPopupMenu reclame un
SetForegroundWindow pour se refermer seul, et le faire sur la barrette
detruirait le NOACTIVATE qui la fait fonctionner.
Transparente n'est pas traversante - les clics sont toujours avales.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Un quatrieme bouton X. Il POSTE WM_LAZY_CLOSE a la fenetre message-only
plutot que de detruire sur place : liberer une fenetre depuis son propre
gestionnaire libererait, en plein envoi, l'instance qui lui sert de
window proc.
Au passage, deux libelles sortaient en mojibake - "Quick search__|" dans
le menu du tray, un tiret cadratin dans l'infobulle. Le fichier est en
UTF-8 SANS BOM, que Delphi lit en ANSI, un octet par caractere : les
litteraux restent donc en ASCII.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SetPreferredAppMode(ForceDark) ne themise que ce que le systeme dessine
lui-meme - menus, ascenseurs, infobulles. Un bouton Win32 standard reste
donc gris clair sur fond sombre, ce que la capture montrait.
BS_OWNERDRAW + WM_DRAWITEM : le systeme garde le suivi de la souris et
l'etat enfonce, nous ne reprenons que les couleurs, recopiees des
variables de css/style.css. Le cadre passe dans WM_ERASEBKGND plutot que
par WS_BORDER, qui se sert dans les couleurs systeme.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Menu du tray -> "Lazy mode". Deux boutons Full / Password qui flottent
au-dessus de tout et font ce que font Ctrl+Shift+L / Ctrl+Shift+P.
WS_EX_NOACTIVATE est toute l'astuce : une fenetre ordinaire prendrait le
premier plan au clic, le champ que l'utilisateur vient de cliquer perdrait
son curseur, et GetForegroundWindow nous designerait nous-memes comme cible.
Le clic ne deplace donc jamais le premier plan.
Le corps du handler WM_HOTKEY est extrait dans FireAutofillRequest : hotkey
et barrette partagent la capture de la cible, le matching de titre et le
picker. Un seul chemin, deux gestes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The desktop keeps twenty previous versions per entry and never sent any. It
now sends three.
Three, not twenty, because the trade is not symmetrical. On the desktop they
sit encrypted column by column and never move. In the snapshot everything
travels in the clear inside the container, and comes down into a phone cache
sealed only by the device key - not by the master password. An old password
stays sensitive: it is often still valid somewhere else. The real use of the
list is short - "I changed it recently, what was it?" - and three cover it.
The other seventeen would be copies with no need facing them.
The phone reads them ON DEMAND from the raw snapshot, never into TVault:
loading them with the vault would put every entry's old passwords in the clear
in memory from the moment it opens, for something one looks at now and then.
Copying goes by RANK, not by value. The page displays the text but never sends
it back - that is the bridge's rule everywhere else, and an old password has
no reason to be the exception just because it happens to be on screen.
They leave with the plaintext at lock, on both sides.
Fetching https://<site>/favicon.ico directly would resolve a DNS name - and
open a connection - to EVERY domain kept in the vault. The list of sites where
someone holds an account is precisely what this vault protects; handing it to
the network for a sixteen-pixel drawing would be a poor trade. The relay sees
only that someone is interested in one domain, which is why the call is asked
for entry by entry and never happens on its own.
Two tries: the full host, then the second-level domain - chat.qwen.ai has no
icon at the relay, qwen.ai does. The type comes from the first bytes, never
from the extension: the relay answers PNG under a .ico address.
A dedicated patch rather than PatchEntryField, because icon_custom is a NUMBER
in the snapshot and writing it as a string would give "0" - which the desktop
reads with GetValue<Boolean> and would choke on. It is set to zero: the icon
comes from an automatic lookup, not from a choice, and that flag is what stops
the desktop from ever replacing a chosen icon during a refresh.
Base64 without line breaks. Delphi's encoder wraps at 76 characters by
default, a wrapped data: URI does not display, and that trap has already been
paid once on the containers.
Three things of different natures lived in collapsible panels on the home
screen - repository credentials, the unlock code, the log - on the one screen
where one mostly wants to open one's vault. They move to a settings sheet,
reachable from the list too.
A sheet, not a fourth view of the rail: each view costs its transform rules
and a place in back-key navigation, and settings is not somewhere one moves
about - it is a parenthesis one opens and closes.
The unlock code can now be REMOVED. It could not before: clearing the field
meant "nothing typed", not "drop the protection", so one could set a code and
never get out. It requires an open vault, and that is the proof being asked
for - the cache only let itself be read under the right code. Without that,
anyone holding the unlocked phone could lift the protection without knowing
it.
The refusal that guards every other path stays: it is what stopped a sync
from silently undoing a code. Removing is the one deliberate way out, and it
says so at the call site.
The old fields stay in the document as the source Delphi knows; the sheet is
only a view of them. Emptying them would lose the configuration at the first
sync.
A probe every ten minutes compares the remote fingerprint to ours and lights
an indicator. It does not pull: adopting on its own while someone is reading
an entry would change it under their eyes. The user decides when.
The body is downloaded anyway - Gitea's contents API cannot answer without it
- but it is thrown away undecrypted: no derivation, no write, just a string
comparison. The cost is network, not time or battery.
It rides the idle timer rather than a second one. That timer already beats
every 15 seconds for auto-lock; counting its beats costs an integer, where
another timer costs an object, a lifecycle, and one more chance to forget it
on shutdown.
Two indicators, two colours, two gestures. Orange: things wait HERE and the
repository does not know. Blue: the repository holds things we do not have.
One dot for both would say "something is wrong" without saying what - and one
is resolved by publishing, the other by fetching.
Two defects found by re-reading before adding more, along with a test plan.
MergeSnapshots merged entries and tombstones but not folders. A folder created
on the phone - offline, or just before another device published - vanished
from the list while the entries kept its name: filed under a folder nothing
displays, unfindable without knowing it. That is exactly what EnsureFolder was
written against, come back through another door.
The pending dot sat on the padlock, which only exists in the list. After
locking one lands on the home screen - precisely where one decides to sync -
and it said nothing there. It is on Sync as well now.
TESTS.md records what the reading checked and what it left alone, with reasons
for the two defects deliberately not fixed, and a scenario that says what each
step must PRODUCE rather than only what to do.
Two defects in what offline saving had just introduced, both losing data
silently - found by re-reading rather than by testing, since the device was
away.
The background refresh REPLACED the cache with the repository's version. An
edit made offline vanished at the next fetch, without a word, which is
exactly what offline saving promises to prevent. It merges now, and keeps the
flag: merging is not publishing.
And the flag lived only in memory. An application killed between the offline
save and the publish forgot it had anything to send - and the next refresh
then clobbered the cache. It is a file now, read before any refresh can run.
A file rather than a field of the sealed cache: the flag carries no secret,
its whole content is yes or no, and the cache's signature is already nine
parameters long.
The save used to start from the network: without it, nothing was kept. But
what someone has just typed is already theirs - publishing is a consequence,
not a condition. The cache is written first, always, and the repository
follows when it can.
A failed publish no longer loses anything. It raises a flag, and the toast
says both things: that it is kept, and that the repository does not know yet.
A bare "failed" would have people retype what is already there.
On conflict the two snapshots are now MERGED rather than the change replayed.
Replaying one edit onto the fresh snapshot was right while writing required
being online; with offline saving several changes can be waiting here, and
replaying one would drop the others.
Sync publishes what is pending BEFORE fetching. Fetching first would overwrite
our cache with the repository's version and the offline change would vanish
without a word - exactly what offline saving promises to prevent.
A dot on the padlock says changes are waiting: discreet until looked for,
present at every glance.
The creation form still put a note's body behind a single-line input, so one
could read and edit multi-line text but never create it - the note had to be
created, then reopened to be laid out.
And the newline could not be typed at all: the handler that turns the
validate key into "fold the keyboard" applied to every field. That rule
exists because in a one-line field the key can only jump to the next one, and
the next one sat on an off-screen view - which is how the unclosable keyboard
happened. In a text area, Enter means Enter. It is the third time that
handler has misfired by treating "any field" as one thing; it now carries its
three exceptions explicitly.
Two things fixed in the same code, since they lived there:
Rows were recognised BY THEIR LABEL - prose. Renaming a caption would have
been enough for this code to stop acting on it, silently. They go by id now.
And what is already typed survives a change of kind. Replacing the control
without carrying the value over would have wiped the entry for a mere change
of mind between Login and Note.
white-space defaults to normal, which folds newlines into spaces: the body of
a note read as one run-on paragraph, while the editor showed it correctly.
The formatting looked lost until you opened the pencil - the worst kind of
mismatch, since it invites re-typing what was already there.
The same rows also drop break-all, which cuts mid-word. That suits a password
and not prose; they break only where they must.
Making every field editable put a note's body behind an <input>, and HTML's
value sanitization removes CR and LF without a word. The formatting would
have been lost on the phone and published to the repository at the next
save - silent, and irreversible once the desktop pulled it.
Multi-line is marked on the row in Delphi, like the field name, rather than
guessed from the caption or from whether the value happens to contain a
newline today: a single-line note one wants to make multi-line deserves the
same control.
The row wraps through a class set when the editor opens, not through :has() -
that selector does not exist before Chrome 105, and an older engine would
ignore the rule without saying so.
Section 1 still said its points had never been exercised while a block below
recorded four of them as validated. Only point 4 remains - and the unlock
code has largely defused it: while a code is set the cache is sealed under an
unconstrained AES key that no screen-lock change invalidates, so the
authenticated branch never runs. That is what the code was built for.
The proposed order listed three things that are done. Replaced by what is
actually left.
build-apk.ps1 -Release builds the Release configuration and signs with the
user's keystore. Not through Delphi's Provisioning page, for three reasons:
the .dproj is versioned, paclient --apksign puts the password ON THE COMMAND
LINE where any process on the machine reads it, and tooling belongs in the
repository rather than hidden in an IDE setting. apksigner called directly
accepts --ks-pass env:.
The password is asked for with Read-Host -AsSecureString - nothing echoed,
nothing left in console history - handed over through an environment
variable, and removed in a finally even when the script fails.
It prints the certificate it signed with. A release signed by accident with
the debug key installs and runs: nothing tells it apart in use, and one finds
out only when the first update is refused.
It does not install the release. Android refuses a different signature on an
existing package, and uninstalling would wipe the local cache and the
device's settings - a deliberate act, not a script's side effect.
Keystores are gitignored. The debug path is unchanged and still builds.
267700 chars became 50457, and a save 2.8 s became 1.15 s. But the payload
fell 5.3x while the time fell only 2.4x: what remains is no longer the size,
it is the trip - TLS handshake, round trip, Gitea creating the commit. A
fixed six to eight tenths of a second whatever the load.
That is this transport's floor, and it closes the question. The other two
routes are no longer worth it: publishing in the background would remove one
second of waiting at the price of "saved" ceasing to mean "published", and
compression would change the format on both sides to shave a share that has
become the minority.
Attachment removed from the vault on the desktop, then a sync: 266299 bytes
became 49268. It weighed 217031 bytes - 81% of everything that travelled on
every write, against an estimate of 78%. The fetch fell from 3244 ms to
597 ms.
The phone can now save an attachment to Downloads, so it cost nothing. Worth
keeping: the weight of a synced vault is its attachments, and since the
container is monolithic, each one is paid on every write of any entry.
Worth recording before someone tries. The desktop restores attachments only
for a NEW entry; for an entry it already knows, the merge leaves them alone.
Publishing a snapshot without the attachment would leave the row untouched in
its database, and its next buildSyncSnapshot would put it back - the removal
would undo itself on the following pull.
So removing an attachment from the synced vault is a desktop action. The
phone can now save it first, which makes that lossless.
The URL and token no longer live as constants - they are in the
Keystore-encrypted settings file once the device has saved them, and the
debug-only preload is a recorded decision rather than an oversight.
And section 4's open list described a state that no longer exists: the 409
has run (it was a 422), every field is editable, and create, duplicate and
delete exist. What remains there is one deliberate choice - no offline
editing - and MergeSnapshots now exists, which lowers its price.
Two questions, and the code was only the second one.
WHERE THE FILE LANDS. The private directory is useless - no file manager
opens it and it leaves with the uninstall - and direct external storage has
been closed since Android 10. Of the three remaining doors, MediaStore ->
Downloads is the only one needing neither a permission nor an extra screen:
since API 29 an app may write what it inserted itself. The destination picker
would need an activity result, which FMX makes painful; sharing would need a
FileProvider in the manifest. Below API 29 it would take
WRITE_EXTERNAL_STORAGE - one of the ten permissions just removed - so it
refuses and says so.
WHERE THE CONTENT IS. TVault drops it on purpose: a single attachment took
the cache from 13 to 174 Ko. It is re-read from the raw snapshot, which has
been in memory ever since saving stopped fetching before publishing. The same
data now serves two needs that had nothing to do with each other.
Decoding and writing happen off the main thread, under the waiting veil: a
few megabytes would freeze the screen, and the veil would not even paint.
What leaves the application leaves its protection: the file lands in the
clear in Downloads. The confirmation names the place rather than saying
"saved".
Release configuration compiles too - checked, since that is what section 5
caught out.
An empty dark blue screen, which is the window's own background with nothing
drawn on it. The cause is one name used twice: the veil element carries class
`busy`, and the state was put on the body under the same name - so
`.busy { display: none }` applied to the BODY as well, and the page vanished
the moment any operation started.
The state is now called `is-busy`, which nothing else carries. Checked the
other body states - typing, selecting, searching, on-list, on-detail - none
of them names an element, so none has the same trap.
The home screen's buttons already dimmed during an operation, but from the
list nothing moved: deleting or duplicating takes a second or two - the
container's round trip - and the screen stayed identical, as if the tap had
not registered. A veil with a turning arc now covers any screen, and it also
prevents the second tap, which would not wait any better.
Its safety net is the existing 25 s deadline: even if an operation never
hands back, the veil lifts.
The plan records where deleted entries actually are: every publish is a Gitea
commit, so the snapshot from before the deletion is still in the repository's
history, readable in its web interface and recoverable by import. Not a
screen, but a real net - and one that catches what a trash would not: an
unlucky edit, a bad import.
The floating menu was wrong for a list. It closed on the next tap, so opening
an entry afterwards took two gestures and felt like a button had got stuck.
Android's contextual bar instead: a long press selects, the top bar takes the
place of search, says how many rows are held, and offers duplicate and
delete. It goes away when nothing is held. One does not search while choosing
what to delete, and two rows of controls would fight over the same thumb.
Selection is multiple, because the cost is in the bar, not in the work: the
patch closure loops, and ten deletions become ONE publish. The container goes
up whole on every write - deleting ten entries one by one would pay that trip
ten times, and give nine chances to fail halfway.
A tap during selection picks rather than opens, which is also the way out:
unpicking the last row closes the bar. The hardware back cancels the
selection before locking the vault - locking because someone wanted to cancel
a choice is the opposite of what the gesture means.
Both menus stay, with distinct jobs: the bar acts on rows chosen in the list,
the detail's three dots act on the entry in front of you. Duplicate copies
everything, attachments included, as the desktop does - a copy that silently
lost the attached document would be a surprise discovered too late.
Two things, and the second was me misreading the question: the affordance was
asked for in the LIST, not in the opened entry.
A long press on a row opens the same menu. Not a cross per row - an
irreversible action a thumb's width away on a list one scrolls - and not a
third button per row, when those were just cleared away. A long press is
invisible until used, it is Android's convention for acting on a list item,
and it is where multi-select would go if it ever comes.
And the deleted entry reopened itself. editDone hands control back after a
refusal, but it redrew the LAST detail - after a delete the view has already
returned to the list, so the entry one had just erased came back on screen.
It now hands back to what is on screen, not to what was.
Delphi deletes by rank when the list asks, by the open entry otherwise -
exactly like open and copy. The page never sends a uuid: it has one, but
letting it name a row Delphi never displayed is a door with no reason to be
open.
It was a full-width red button at the foot of every detail, permanently in
view for a gesture one makes three times a year. It now lives behind the
three dots in the header: open, then confirm - two deliberate gestures, and
nothing lingering in sight the rest of the time.
A single item in a menu is not an oversight. The action has no way back, and
an action with no way back should not sit where a stray tap reaches it. A
cross in the corner would be worse still: that corner means "close"
everywhere else.
The plan records what the server code says about the trash: receiving a
tombstone runs DELETE FROM vault_entries, a hard delete. A deletion from the
phone removes the row on both sides and bypasses the desktop's trash. The
only net is the desktop's backups, and there is no trash to show here - the
phone never receives its contents.
Focusing the Folder field made the screen jump: every .field-in was treated
as if a keyboard were coming, reserving 60% of the height and lifting the row
to the top of the panel. A <select> opens a native list over the page - it
occupies nothing and vanishes on choice.
And the lift threshold now says what the keyboard actually covers, a little
under the bottom half. At 40% it raised fields that stayed perfectly visible,
moving under the eye what was already fine.
The white "copied" chip appearing long after the gesture was Android's, and
it was ours to stop causing: the 45 s auto-clear wrote an empty string
through setPrimaryClip, which the system reads as a copy and announces like
one. The comment claimed the visible result was the same. It is not, and the
API has distinguished emptying from copying since 2018 - clearPrimaryClip,
kept behind an API 28 check because minSdk is 23.
It only showed every other time because the timer clears only if the
clipboard still holds our text; copying anything else in between cancels it.
Nothing to fix on the sensitive flag: it is set, the chip shows no content,
and that generic wording is exactly what the flag produces.
Show, Cancel and Save shared their row with the input field, and three words
left barely enough room to read what one types - the very crowding that made
the row overflow in the first place. A cross and a tick read without
translation.
The tick gives way to a turning arc while saving. The word "Saving..." said
the wait was real; a motionless tick would say nothing, and it is exactly
during that second or two that one presses again.
The form's Save and Delete entry keep their words: they are not inline
controls sharing a row, and the second is the only action with no way back.
With an icon inside, the tap target is the svg or one of its strokes, never
the button. Reading the attribute off the target returns null and the handler
falls through to its default - here, opening the entry instead of copying.
Half the taps worked, which is the worst kind of failure to diagnose.
Three translucent pills per list row weighed more than what they pointed at.
The drawing alone carries it.
The target stays 44 px: that is what a finger expects, and it does not need to
be visible to exist. The press feedback moves from the background to the
stroke, since there is no background left to dim.
Copying a password or a username opened the entry instead - about half the
time, which is the worst kind of failure to diagnose. Since those buttons
carry an icon, the tap target is the <svg> or one of its strokes, so reading
the attribute off the target returned null and the handler fell through to
"open". A finger landing sometimes on the glyph and sometimes on the margin
made it look random. Both handlers now resolve to the button first.
The new-entry form gets a folder, like the editor: an entry filed from the
start saves having to move it.
And a folder can now be created, not only chosen. Filing an entry under a
name is not enough - it is `folders` that fills the desktop's column, and a
name missing from it leaves the entry in a folder nothing displays, looking
lost. The two now go together, in one place, for both editing and creation.
'All' is never registered: it is the default, not a folder.
The folder had no row of its own - it shared "Folder / tags" with the tags,
so neither could be touched. It is now CHOSEN from the known folders rather
than typed: a typo would file the entry under a folder nothing displays,
here or on the desktop, and it would look lost. Tags stay read-only because
they are an array in the snapshot, and writing one as a string would break
its shape for the desktop.
The 2FA secret gets its own masked row. The code has had a panel for a long
time, but it is computed and renewed every thirty seconds; the secret is what
one sets, changes and removes, and nothing allowed that from the phone.
User, Pass, Copy, Show and Edit become drawings. Four words on a list row left
little room for the entry's name and had to be re-read every time. Every icon
carries an aria-label: replacing a word with a drawing must not take the
information away from someone listening to a screen reader.
Decided: it is outside the repository, it no longer enters a release build,
and the token it carries opens a test repository only. Keeping it saves
retyping forty characters at every reinstall of the bench.
What would warrant revocation is a token granting access to anything beyond
that repository - not this one. Recording the decision so it stops coming
back as an open item.
Until now the two situations never met: a local vault had no repository, a
pulled vault had no local container. The day both exist, the rule "the local
container is the authority" means saves never reach the repository - and the
two diverge in silence, which is the worst outcome available.
Sync now merges them once and then deletes the local container: the
repository becomes the authority and the device behaves like any other. That
makes divergence impossible rather than unlikely. Order matters - publish
first, delete after; the reverse would lose the whole vault if the publish
failed.
The remote is the base, never the local. It carries what the phone cannot
rebuild: attachment bodies, the avatar, folder colours, and whatever the
desktop adds next. Starting from the local would amputate all of it, and the
desktop would adopt the amputated version on its next pull.
Arbitration is the desktop's, term for term: last write wins on updated_at, a
tombstone beats an older entry but not one edited after it - that one was
revived on purpose. Timestamps are ISO 8601 UTC on both sides, milliseconds
included, so lexicographic order IS chronological order.
MergeSelfCheck asserts the four rules at startup in debug. The merge never
runs against a real vault before it has run there.
The manifest asked for fine and coarse location, camera, phone, phone state
and external storage - Delphi's defaults, none of them used. On a password
vault those are exactly the wrong signals: whoever reads the app's listing saw
a request for position and camera with no possible explanation. The list is
written by hand now.
A trap on the way: naming the substitution marker inside the comment that
explains its removal is enough to bring it back. The substitution is textual
and does not care that it lands in a comment.
The bench credentials are no longer compiled into a release - the local
include is debug-only. Verified in the binary in UTF-8 AND UTF-16: Delphi
stores strings as UTF-16, so an ASCII grep returned zero on both sides and
proved nothing.
The log leaves the home screen in release without leaving the application: a
1.5 s press on the status line brings it back. Nothing secret is in it, but a
permanent Log button is development noise, and diagnostics must stay reachable
for the day something goes wrong remotely.
And the Release configuration did not compile at all, which nobody knew: the
two self-checks had their declarations under IFDEF DEBUG and their bodies
outside. Invisible as long as one only ever builds Debug.
Signing is what remains, and the keystore password is the user's to hold.
Conflict detected, fresh snapshot pulled, the change applied ON TOP of it,
publish accepted. Nothing clobbered - which is the whole point of dropping
the pre-publish fetch.
The second attempt also derived the key again, 4397 ms: the desktop had
re-encrypted its container with a fresh salt, so the key in hand no longer
fitted. That is exactly the case the reuse guards against, seen firing for
the first time. It costs one derivation per desktop publish, no more.
The retry path finally ran, and did not recognise what it was handed. A
desktop publishing between our read and our write earns a 422, not a 409, so
the save failed instead of retrying - which is exactly what a never-exercised
path hides: it was written, it compiled, it was even commented, and it did
not fire.
Gitea answers 409 when the sha no longer matches and 422 when it is missing
or the request is judged unprocessable, "file already exists" among them.
Both say the same thing to us: the sha is stale. Re-reading and retrying is
right for both and cannot clobber anything - the retry publishes against the
fresh sha. A genuinely malformed body would fail again and give up after
three tries, carrying Gitea's own words.
The log now prints which code it was, rather than assuming.
The desktop, after syncing: pulled 4 new, 1 updated, 1 deleted, pushed 11
entries. Create, edit and delete in one line, seen from the side that did not
perform them. The deletion is the one that mattered - vanishing locally proved
nothing, the tombstone had to travel.
Steps 1 to 3 of section 7 are closed. The 409 is what remains.
It was introduced with two readers and no writer. Cancel called
renderDetail(null), which threw on d.rows and did nothing at all - and
editDone, which uses it to hand control back after a refusal, was dead the
same way. That is why the successive fixes for "Cancel does not respond"
changed nothing: they all ended in the same silent throw.
Assigned where a detail is drawn, which is the one place that knows it.
It went from 0000 to 00000000 with nobody deciding it. The typed code and the
code the cache is sealed under were the same variable, so every write of the
cache re-sealed under whatever sat in the field - a sync, which asks for no
code at all, was enough to change it, silently.
They are two things now. Only opening the vault touches the seal, because
that is the one moment we know the current code is known: the decryption just
proved it. Everything else - sync, background refresh, saving an entry -
rewrites the cache under the code already in place.
Hence a second field, shown only once a code exists: the current one must open
the vault for the new one to take. Without it this fix would have locked the
device under the code set by accident, which is exactly the harm it is meant
to prevent.
r-zakarya