r-zakarya
440bfd5536
Pull, patch, re-encrypt, publish - in that order, and against the SERVER's snapshot rather than the local cache. That is what replaces the merge the plan asked for: anything untouched is already everyone's newest version, so there is nothing to reconcile. The only conflict left is another device publishing between our read and our write. Gitea refuses it on the sha with a 409, and the whole cycle repeats, decryption included, since the content changed. Three attempts: past that the other device is publishing in a loop and insisting would not help. The editable field is marked in Delphi rather than recognised by its caption in the page. A caption is prose; the day it changes, matching on it would silently stop offering the edit. The editor is inline rather than window.prompt: a JavaScript prompt needs a WebChromeClient that FMX does not provide, and prompt() then returns null without a word - the button would appear to do nothing. The value shows in clear while typing, deliberately: you are entering a password you cannot read back anywhere else, and masking it would mean confirming a keystroke blind. This is the one command that carries a secret over the bridge, agreed beforehand. It stays in the process, the iframe carrying it is destroyed, and the handler logs the action only - never the query. Only the password is editable. Creating or deleting an entry would need tombstones and uuid generation, and changing a password covers the need without either. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
