docs: name every approval-screen amount string, fix stale zero claim (closes #369)

The README's amount-display section claimed a genuine zero always renders
`0.0000`. That is corrected and scoped: it holds for the ERC-20 amount and for
the swap's `Amount` line on a literal-zero `amountIn` in a V2/V3 exact-in swap
or a zero `WRAP_ETH`. Only two zeros are stated in words before the floor — the
swap's `Min. received` (any zero minimum) and its V4 exact-in `Amount` (an
`amountIn` of zero, V4's open delta).

A new list names every string an amount slot can show: a formatted quantity,
`Unlimited`, `All available (V4 open delta)`, `None (no minimum guaranteed)`,
base units with decimals unknown, and `Unknown (not named in the calldata)`. It
also records that a zero `minBalance` on a `BALANCE_CHECK_ERC20` step now reads
the no-minimum wording where it once read `0.0000`. Each claim checked against
the tree. Docs only.

Model: opus-4-8

README.md

@@ -64,7 +64,9 @@ release/SHA256SUMS
 ```
 
 Nothing is published by this. Tagging, CRX packing and any upload are
-outward-facing acts and are the owner's alone.
+outward-facing acts and are the owner's alone. The full procedure that turns a
+green `main` into a tagged, packaged release — the order of steps, who performs
+each, and how to check it worked — is in [docs/RELEASE.md](docs/RELEASE.md).
 
 The archives are deterministic — entries sorted, timestamps fixed, compression
 level fixed — so two builds of one commit produce byte-identical files and the
@@ -880,9 +882,18 @@ On those screens, when the truncated string would contain no digit from 1 to 9
 and the value does, the amount is extended to its first significant digit
 instead: `0.000000000000000001 DAI`, not `0.0000 DAI`. The test is on the whole
 truncated string, integer part included, so `1.00005` still shows as `1.0000` —
-the exception only fires where the entire displayed figure would read as zero. A
-genuine zero still renders `0.0000`, and truncation stays truncation: `0.99999`
-shows as `0.9999`, never rounded up.
+the exception only fires where the entire displayed figure would read as zero.
+Truncation stays truncation: `0.99999` shows as `0.9999`, never rounded up. A
+genuine zero reaching this rule renders `0.0000`. The ERC-20
+`approve`/`transfer` amount does exactly that, and so does the swap's `Amount`
+line for a literal-zero `amountIn` on a V2 or V3 exact-in swap, or a zero
+`WRAP_ETH` (`0.0000 ETH`). Only two zeros are stated in words before the floor:
+the swap's `Min. received` line reads `None (no minimum guaranteed)` for any
+zero minimum, and its `Amount` line reads `All available (V4 open delta)` for a
+V4 exact-in `amountIn` of zero, which V4 treats as the whole open credit rather
+than a quantity. So the guarantee that a zero is never shown as `0.0000` covers
+the `Min. received` line and the V4 exact-in `Amount`; a V2/V3 or `WRAP_ETH`
+`Amount` still renders it (see the list of amount-slot strings below).
 
 The rule and its exception live in `src/shared/amountDisplay.js` as
 `truncateAmount()` and `truncateAmountNeverZero()`. Everything the approval and
@@ -934,6 +945,38 @@ and compare against. Reading the stored field directly instead answers `null`
 for a bundled or tracked token the explorer merely omitted, which is not a
 refusal the wallet has any reason to make.
 
+**Every string an amount slot can show:** taken together, the exceptions above
+mean an amount line on the dApp approval screen (and the wait/success/error
+screens that carry a figure forward) shows one of a fixed set of strings, not
+always a number:
+
+- A formatted quantity, e.g. `17.1900 USDT`: the token's scale is known and the
+  figure is at or above the floor, or below it and extended to its first
+  significant digit. This is `truncateAmountNeverZero()`
+  (`src/shared/amountDisplay.js`).
+- `Unlimited`: an unbounded allowance or permit, which needs no scale to
+  describe — a `uint256`-max ERC-20 `approve` (`src/popup/views/approval.js`) or
+  a Permit2 amount at the `uint160` max on a swap's `Amount`
+  (`src/shared/uniswap.js`).
+- `All available (V4 open delta)`: a V4 exact-in swap whose `amountIn` is zero.
+  V4 reads that zero as "use the whole open delta", not as a literal zero, so
+  the calldata states no quantity at all. Swap `Amount` line only
+  (`src/shared/uniswap.js`).
+- `None (no minimum guaranteed)`: a zero minimum — the swap guarantees nothing
+  back. It is a literal zero slippage floor on a V2/V3/V4 swap, and it also
+  reaches a `BALANCE_CHECK_ERC20` step: a zero `minBalance`, which once rendered
+  `0.0000` beside the token symbol, now reads this. Swap `Min. received` line
+  (`src/shared/uniswap.js`).
+- `<amount> base units (decimals unknown)`: the token's scale could not be
+  resolved, so the base-unit integer is shown with that caveat rather than
+  formatted (see Unknown token scale above). Reaches both the ERC-20 amount line
+  and the swap's `Amount` and `Min. received` (`unknownDecimalsAmount()` in
+  `src/shared/approvalAmount.js`).
+- `Unknown (not named in the calldata)`: not an amount but the currency itself —
+  the `Token In` or `Token Out` line when nothing in the calldata established
+  which token, shown beside the amount and, like the strings above, a sentence
+  rather than a value (`src/shared/uniswap.js`).
+
 #### Partial USD totals
 
 Prices are fetched for the top 25 tokens only, so an address can hold assets the

TODO.md

@@ -90,6 +90,16 @@ but the review is broader than any of them.
   approve, reject and disconnect paths against a transaction approval
   broadcasting behind them: each is declined and the dApp still receives its
   broadcast result.
+- 2026-09-21: `docs/RELEASE.md`, linked from `README.md`, states the release
+  procedure as a numbered list a newcomer can follow: confirm `main` is green in
+  CI, confirm the one version in the three files matches the intended tag,
+  `make package` from a clean checkout, verify `SHA256SUMS`, tag `vX.Y.Z`, then
+  distribute per browser. Each step names who performs it (owner-only steps
+  marked) and the check that it worked. The distribution step is written as
+  pending the owner's choice on
+  [#386](https://git.eeqj.de/sneak/AutistMask/issues/386), with the Firefox and
+  Chrome options named but none settled. Docs only
+  ([#387](https://git.eeqj.de/sneak/AutistMask/issues/387)).
 
 - 2026-09-21: Adding a second wallet no longer accepts a different password with
   nothing saying it is a separate one
@@ -122,6 +132,32 @@ but the review is broader than any of them.
   constant rather than `isDebug()`, so it survives only in a debug build; a
   testnet or the runtime debug toggle still raises the banner but without the
   view id.
+
+- 2026-09-21: The Confirm Delete button on the delete-wallet screen no longer
+  stays dead after a successful delete
+  ([#335](https://git.eeqj.de/sneak/AutistMask/issues/335)). The password route
+  disabled the button before the decrypt and never re-enabled it, so a second
+  delete in the same popup session needed a reopen; the lost-password route
+  re-enabled its own button in its leave hook, so the two screens behaved
+  differently. Both now reset through the shared `finishDelete()`, the one path
+  both routes take, so they behave the same and the button is live for the next
+  delete.
+
+- 2026-09-21: `README.md` now documents the approval screen's amount-slot
+  vocabulary and no longer contradicts itself
+  ([#369](https://git.eeqj.de/sneak/AutistMask/issues/369)). The stale claim
+  that a genuine zero still renders `0.0000` is corrected: it holds for the
+  ERC-20 amount, and also for the swap's `Amount` line on a literal-zero
+  `amountIn` in a V2/V3 exact-in swap or a zero `WRAP_ETH`. Only two zeros are
+  stated in words upstream — the swap's `Min. received` (any zero minimum) and
+  its V4 exact-in `Amount` (an `amountIn` of zero, V4's open delta). The
+  amount-display section now names every string a slot can show — a formatted
+  quantity, `Unlimited`, `All available (V4 open delta)`,
+  `None (no minimum guaranteed)`, base units with decimals unknown, and
+  `Unknown (not named in the calldata)` — and records that a zero `minBalance`
+  on a `BALANCE_CHECK_ERC20` step now reads `None (no minimum guaranteed)` where
+  it once read `0.0000`. Docs only; each claim checked against the tree.
+
 - 2026-08-30: An address no longer wraps, or is shortened to fit, in any of the
   common views ([#380](https://git.eeqj.de/sneak/AutistMask/issues/380)). The
   wallet list was the reported case: the address shared one row with the

docs/RELEASE.md

@@ -0,0 +1,87 @@
+# Releasing AutistMask
+
+This is the procedure that turns a green `main` into a tagged, packaged release.
+It gathers into one place what is otherwise spread across the `Makefile` and
+three `README.md` sections, so the person cutting a release does not have to
+reconstruct the order from them.
+
+There is one version, declared in three files (`package.json`,
+`manifest/chrome.json`, `manifest/firefox.json`), and `make package` builds and
+packages but publishes nothing. `make build` and `make package` can be run by
+anyone; tagging, signing, packing a CRX and any upload need credentials only the
+owner ([@sneak](https://sneak.berlin)) holds and are marked **owner-only**
+below. Releases are tagged from `main` (see the Workflow section of `TODO.md`),
+so the "release commit" throughout is the `main` commit the milestone PR merged.
+
+## Procedure
+
+1. **Confirm `main` is green in CI.** The `check` workflow
+   (`.gitea/workflows/check.yml`) runs `script/cibuild`, i.e. `docker build .`,
+   and the `Dockerfile` runs `make check` as a build step, so a green `check`
+   run is a green `make check`. Find the run for the exact release commit on the
+   tracker's Actions view. _Check:_ that commit's `check` run succeeded; running
+   `make check` on a clean checkout of the commit reproduces it and exits 0.
+
+2. **Confirm the version matches the intended tag.** `package.json`,
+   `manifest/chrome.json` and `manifest/firefox.json` must all declare the same
+   `X.Y.Z`. `make build` fails when they disagree, but nothing checks that they
+   equal the tag you mean to create — that is this manual step. _Check:_ all
+   three files read the same `X.Y.Z`, and it is the version you intend to tag
+   `vX.Y.Z`.
+
+3. **Build and package from a clean checkout of that commit.** From a fresh
+   clone, or a working tree with no local modifications (`git status` clean),
+   checked out at the release commit: run `make setup`, then `make package`.
+   `make package` runs `make build` first, so the archives can only be made from
+   a `dist/` verified against that build's own receipt as a release (not debug)
+   build. It writes three files into `release/`:
+   `autistmask-chrome-<version>.zip`, `autistmask-firefox-<version>.xpi`, and
+   `SHA256SUMS`. _Check:_ those three files exist and `<version>` in the archive
+   names is the version confirmed in step 2. The Firefox `.xpi` is **unsigned**
+   (see step 6 and "Installing on Firefox" in `README.md`).
+
+4. **Verify `SHA256SUMS`.** The archives are deterministic — sorted entries,
+   fixed timestamps, fixed compression — so a second `make package` from another
+   clean checkout of the same commit produces byte-identical files. Verify the
+   recorded digests against the files with `sha256sum -c SHA256SUMS`, run from
+   `release/`. To confirm reproducibility, run `make package` again on a
+   separate clean checkout and compare the digests. _Check:_ `sha256sum -c`
+   reports `OK` for every file, and an independent build's digests match.
+
+5. **Tag the release commit.** _(owner-only)_ Create an annotated tag `vX.Y.Z`
+   on the release commit and push it: `git tag -a vX.Y.Z` (with a message), then
+   `git push origin vX.Y.Z`. _Check:_ `git tag` lists `vX.Y.Z`, and
+   `git rev-parse vX.Y.Z^{commit}` resolves to the release commit.
+
+6. **Distribute per browser.** _(owner-only; pending the owner's choice on
+   https://git.eeqj.de/sneak/AutistMask/issues/386)_ How 1.0.0 is distributed on
+   each browser is not yet decided; it is the open question on that issue, and
+   the concrete steps cannot be written until the owner records a choice there.
+   These steps need credentials only the owner holds. The options under
+   consideration are:
+    - **Firefox** — the packaged `.xpi` is unsigned, and release Firefox and ESR
+      refuse an unsigned add-on:
+        - (a) AMO self-distribution signing (unlisted): submit the `.xpi` to AMO
+          with the owner's credentials; AMO returns a signed `.xpi` installable
+          on every Firefox, with nothing listed publicly.
+        - (b) AMO listed: as (a), plus a public AMO listing and review.
+        - (c) Ship the unsigned `.xpi` and state that Firefox support means
+          Developer Edition, Nightly, or an Unbranded build with
+          `xpinstall.signatures.required` set to `false`.
+    - **Chrome** — the repo packs no CRX and publishes nothing; the extension id
+      is fixed by the `key` in `manifest/chrome.json`:
+        - (a) Chrome Web Store (unlisted): upload the `.zip` with the owner's
+          developer account; the store delivers installs and updates.
+        - (b) Self-hosted CRX signed with the private key the owner holds
+          (`chrome --pack-extension=dist/chrome --pack-extension-key=<path to the .pem>`),
+          installable only via enterprise policy on Windows and macOS, so
+          realistically Linux-only.
+        - (c) "Load unpacked" from `dist/chrome/` only, as today.
+
+    Once the owner decides, the chosen steps — including which credentials they
+    need and who holds them — are written into this section and `README.md`'s
+    installation sections are updated to match, which is part of the definition
+    of done of https://git.eeqj.de/sneak/AutistMask/issues/386. _Check:_ for a
+    store or AMO route, the artifact installs from the store or AMO on a clean
+    browser profile; for the CRX or unpacked route, the documented load succeeds
+    and Chrome reports the extension id `gipbhkogfopeahplcjhipkgpcimdpkip`.

src/popup/views/deleteWallet.js

@@ -51,16 +51,12 @@ function clear() {
 // The lost-password screen holds no secret — a wallet name is not one —
 // but it is wiped on leave for the neighbouring reason: a typed
 // confirmation left standing in a hidden view is one click away from
-// destroying a wallet the user has since navigated off. The button is
-// re-enabled here too, so a screen left mid-delete is usable on re-entry.
+// destroying a wallet the user has since navigated off.
 function clearLostPassword() {
     lostPasswordIndex = null;
     $("delete-wallet-lost-name-input").value = "";
     $("delete-wallet-lost-flash").textContent = "";
     $("delete-wallet-lost-flash").style.visibility = "hidden";
-    const btn = $("btn-delete-wallet-lost-confirm");
-    btn.disabled = false;
-    btn.classList.remove("text-muted");
 }
 
 function show(walletIdx) {
@@ -98,6 +94,17 @@ function showLostPassword() {
 // cleanup and the accountsChanged broadcast cannot drift apart between
 // them.
 async function finishDelete(walletIdx) {
+    // Each route's confirm button was disabled by its own click handler
+    // before the delete ran. Re-enable both here, on the one path they
+    // share, so the two routes reset the same way and a second delete in
+    // the same popup session finds a live button instead of a dead one.
+    const passwordBtn = $("btn-delete-wallet-confirm");
+    passwordBtn.disabled = false;
+    passwordBtn.classList.remove("text-muted");
+    const lostPasswordBtn = $("btn-delete-wallet-lost-confirm");
+    lostPasswordBtn.disabled = false;
+    lostPasswordBtn.classList.remove("text-muted");
+
     const { activeAddressChanged } = removeWalletFromState(state, walletIdx);
 
     deleteWalletIndex = null;
@@ -187,8 +194,8 @@ function init(_ctx) {
         btn.disabled = true;
         btn.classList.add("text-muted");
 
-        // finishDelete() navigates, and the leave hook re-enables the
-        // button and wipes the typed name on the way out.
+        // finishDelete() re-enables the button; navigating away then runs
+        // the leave hook that wipes the typed name.
         await finishDelete(lostPasswordIndex);
     });
 

tests/deleteWalletLostPassword.test.js

@@ -172,6 +172,15 @@ async function openLostPassword(deleteWallet, walletIdx) {
     await click("btn-delete-wallet-lost-password");
 }
 
+// Delete a wallet through the password route: open its confirm screen,
+// enter the password, and confirm. The vault is mocked, so the password
+// text itself is irrelevant — decryptWithPassword decides pass or fail.
+async function deleteWithPassword(deleteWallet, walletIdx) {
+    deleteWallet.show(walletIdx);
+    node("delete-wallet-password").value = "any password";
+    await click("btn-delete-wallet-confirm");
+}
+
 // ------------------------------------------------------------ tests
 
 // The stub is what every persistence assertion below rests on, so its one
@@ -456,15 +465,21 @@ describe("what the screen leaves behind", () => {
         );
     });
 
-    // Left mid-delete, the screen has to come back usable.
-    test("the confirm button is re-enabled on the way out", async () => {
-        const { helpers, deleteWallet } = load();
+    // Both routes now re-enable through finishDelete(), not their leave
+    // hooks, so the button comes back live once a delete completes.
+    test("the confirm button is re-enabled after a delete", async () => {
+        const { deleteWallet } = load();
         await openLostPassword(deleteWallet, 1);
 
-        node("btn-delete-wallet-lost-confirm").disabled = true;
-        helpers.showView("settings");
+        node("delete-wallet-lost-name-input").value = "Wallet 2";
+        await click("btn-delete-wallet-lost-confirm");
 
         expect(node("btn-delete-wallet-lost-confirm").disabled).toBe(false);
+        expect(
+            node("btn-delete-wallet-lost-confirm").classList.contains(
+                "text-muted",
+            ),
+        ).toBe(false);
     });
 
     // A wallet name is not a secret, so the screen is excluded for the
@@ -475,3 +490,48 @@ describe("what the screen leaves behind", () => {
         expect(RESTORABLE_VIEWS.has("delete-wallet-confirm")).toBe(false);
     });
 });
+
+// The password route is the pre-existing bug this file's fix addresses:
+// its Confirm Delete button was disabled before the decrypt and never
+// re-enabled on success, so a second delete in the same popup session
+// found a dead button. Now both routes re-enable through finishDelete().
+//
+// Against head these tests fail: with the re-enable absent, the button
+// stays disabled after the first delete, so the disabled assertions read
+// true where they expect false.
+describe("the password route's confirm button", () => {
+    test("is re-enabled after a successful delete", async () => {
+        const { deleteWallet, vault } = load();
+        vault.decryptWithPassword.mockResolvedValue();
+
+        await deleteWithPassword(deleteWallet, 1);
+
+        expect(node("btn-delete-wallet-confirm").disabled).toBe(false);
+        expect(
+            node("btn-delete-wallet-confirm").classList.contains("text-muted"),
+        ).toBe(false);
+    });
+
+    // The reported symptom: delete one wallet, then open Delete Wallet for
+    // a second one without reopening the popup. The button must be live on
+    // that second visit, and the second delete must actually persist.
+    test("a second delete works in the same popup session", async () => {
+        const { deleteWallet, vault, storage } = load();
+        vault.decryptWithPassword.mockResolvedValue();
+
+        await deleteWithPassword(deleteWallet, 1);
+
+        // Wallet 2 is gone; the list is now [Wallet 1, Wallet 3]. Opening
+        // the confirm screen for the wallet now at index 1 (Wallet 3) must
+        // find its button live, not the dead one the first delete left.
+        deleteWallet.show(1);
+        expect(node("btn-delete-wallet-confirm").disabled).toBe(false);
+
+        node("delete-wallet-password").value = "any password";
+        await click("btn-delete-wallet-confirm");
+
+        expect((await persistedWallets(storage)).map((w) => w.name)).toEqual([
+            "Wallet 1",
+        ]);
+    });
+});