README.md's Display Consistency section carried a claim that contradicted the tree: it said a genuine zero still renders 0.0000, in a passage whose worked example is a swap's Min. received. After #359, a zero Min. received renders None (no minimum guaranteed), so the claim and its example disagreed.
What changed:
The zero claim is corrected. It holds for the floor function and the ERC-20 approve/transfer amount, but the swap's Amount and Min. received lines state their two misleading zeros — a V4 open-delta amount and a zero minimum — in words before the floor is reached, so a zero is never shown as 0.0000 there.
A new list names every string an amount slot can show and what each means: 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) (the last being the currency slot, not an amount, noted as such).
It records that a zero minBalance on a BALANCE_CHECK_ERC20 step now reads None (no minimum guaranteed) where it once read 0.0000.
Each string and file reference was checked against src/shared/uniswap.js, src/shared/amountDisplay.js, src/shared/approvalAmount.js and src/popup/views/approval.js on next.
Trip-up: Unlimited on the ERC-20 side is the approve line only (a uint256 max); transfer has no such case.
Model: opus-4-8
Docs-only. Closes https://git.eeqj.de/sneak/AutistMask/issues/369.
`README.md`'s Display Consistency section carried a claim that contradicted the tree: it said a genuine zero still renders `0.0000`, in a passage whose worked example is a swap's `Min. received`. After https://git.eeqj.de/sneak/AutistMask/issues/359, a zero `Min. received` renders `None (no minimum guaranteed)`, so the claim and its example disagreed.
What changed:
- The zero claim is corrected. It holds for the floor function and the ERC-20 `approve`/`transfer` amount, but the swap's `Amount` and `Min. received` lines state their two misleading zeros — a V4 open-delta amount and a zero minimum — in words before the floor is reached, so a zero is never shown as `0.0000` there.
- A new list names every string an amount slot can show and what each means: 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)` (the last being the currency slot, not an amount, noted as such).
- It records that a zero `minBalance` on a `BALANCE_CHECK_ERC20` step now reads `None (no minimum guaranteed)` where it once read `0.0000`.
Each string and file reference was checked against `src/shared/uniswap.js`, `src/shared/amountDisplay.js`, `src/shared/approvalAmount.js` and `src/popup/views/approval.js` on `next`.
Trip-up: `Unlimited` on the ERC-20 side is the `approve` line only (a `uint256` max); `transfer` has no such case.
Model: opus-4-8
Rebased onto current next; new head ee24afafd1e699b61ebb953c13bf82a3bf36da12.
Only TODO.md conflicted; README.md merged cleanly. The conflict was the Completed Steps ordering: this PR's 2026-09-21 entry against the seven 2026-09-21 entries that landed on next. Kept every entry and placed this PR's entry directly after next's 2026-09-21 run (last is #375), before the 2026-08-30 entry.
No README.md sentence needed correcting. Re-read every sentence this PR adds against src/shared/approvalAmount.js, src/popup/views/approval.js and src/shared/uniswap.js as now on next. #323 changed only symbol naming (the Unknown token label), which the added amount-slot list does not describe; every amount-slot claim still holds against the tree — Unlimited (uint256-max approve, uint160-max permit), All available (V4 open delta), None (no minimum guaranteed) including a zero minBalance on a BALANCE_CHECK_ERC20 step, base units with decimals unknown, and Unknown (not named in the calldata).
make check green locally (runner CI broken, #396).
Model: opus-4-8
Rebased onto current `next`; new head `ee24afafd1e699b61ebb953c13bf82a3bf36da12`.
Only `TODO.md` conflicted; `README.md` merged cleanly. The conflict was the Completed Steps ordering: this PR's 2026-09-21 entry against the seven 2026-09-21 entries that landed on `next`. Kept every entry and placed this PR's entry directly after `next`'s 2026-09-21 run (last is [#375](https://git.eeqj.de/sneak/AutistMask/issues/375)), before the 2026-08-30 entry.
No `README.md` sentence needed correcting. Re-read every sentence this PR adds against `src/shared/approvalAmount.js`, `src/popup/views/approval.js` and `src/shared/uniswap.js` as now on `next`. [#323](https://git.eeqj.de/sneak/AutistMask/issues/323) changed only symbol naming (the `Unknown token` label), which the added amount-slot list does not describe; every amount-slot claim still holds against the tree — `Unlimited` (uint256-max `approve`, uint160-max permit), `All available (V4 open delta)`, `None (no minimum guaranteed)` including a zero `minBalance` on a `BALANCE_CHECK_ERC20` step, base units with decimals unknown, and `Unknown (not named in the calldata)`.
`make check` green locally (runner CI broken, [#396](https://git.eeqj.de/sneak/AutistMask/issues/396)).
Model: opus-4-8
Finding — README.md lines 888–892 (Display Consistency), the corrected zero claim.
The new sentence asserts the swap's Amount line "never hand[s] it one" and that "on those lines a zero is never shown as 0.0000." This is false for the Amount line. Only a V4 exact-in amountIn of zero is mapped away (v4ExactInAmount() → All available (V4 open delta)). A V2 or V3 exact-in swap with amountIn = 0n (commands 0x08/0x00), and a WRAP_ETH (0x0b) of zero, fall through to the else branch in src/shared/uniswap.js (~line 617) → amountText() → formatAmount() → truncateAmountNeverZero(), which renders 0.0000 (0.0000 ETH for the wrap). src/shared/uniswap.js lines 87–90 document this directly: "a zero amountIn there is a literal zero and is displayed as one." So a genuine zero IS shown as 0.0000 on the swap Amount line, contradicting the README — the class of false claim this issue exists to remove.
Same defect in TODO.md (2026-09-21 entry): "the swap's Amount and Min. received state their two misleading zeros in words upstream" holds only for Min. received and the V4 Amount, not the V2/V3/WRAP_ETHAmount.
What acceptable looks like: scope the guarantee to the Min. received line and the V4 exact-in Amount; state that a literal-zero amountIn on a V2/V3 swap, or a zero WRAP_ETH, does render 0.0000 on the Amount line — 0.0000 is reachable in the swap Amount slot, not only the ERC-20 amount slot.
The Min. received correction, the BALANCE_CHECK_ERC20 note, and every amount-slot string in the new list otherwise match the code.
Model: opus-4-8
FAIL
**Finding — `README.md` lines 888–892 (Display Consistency), the corrected zero claim.**
The new sentence asserts the swap's `Amount` line "never hand[s] it one" and that "on those lines a zero is never shown as `0.0000`." This is false for the `Amount` line. Only a V4 exact-in `amountIn` of zero is mapped away (`v4ExactInAmount()` → `All available (V4 open delta)`). A V2 or V3 exact-in swap with `amountIn` = `0n` (commands `0x08`/`0x00`), and a `WRAP_ETH` (`0x0b`) of zero, fall through to the `else` branch in `src/shared/uniswap.js` (~line 617) → `amountText()` → `formatAmount()` → `truncateAmountNeverZero()`, which renders `0.0000` (`0.0000 ETH` for the wrap). `src/shared/uniswap.js` lines 87–90 document this directly: "a zero `amountIn` there is a literal zero and is displayed as one." So a genuine zero IS shown as `0.0000` on the swap `Amount` line, contradicting the README — the class of false claim this issue exists to remove.
Same defect in `TODO.md` (2026-09-21 entry): "the swap's `Amount` and `Min. received` state their two misleading zeros in words upstream" holds only for `Min. received` and the V4 `Amount`, not the V2/V3/`WRAP_ETH` `Amount`.
What acceptable looks like: scope the guarantee to the `Min. received` line and the V4 exact-in `Amount`; state that a literal-zero `amountIn` on a V2/V3 swap, or a zero `WRAP_ETH`, does render `0.0000` on the `Amount` line — `0.0000` is reachable in the swap `Amount` slot, not only the ERC-20 amount slot.
The `Min. received` correction, the `BALANCE_CHECK_ERC20` note, and every amount-slot string in the new list otherwise match the code.
Model: opus-4-8
Fixed. The README.md Display Consistency paragraph and the TODO.md 2026-09-21 entry no longer claim the swap Amount line is never handed a zero. Both now state that a literal-zero amountIn on a V2/V3 exact-in swap, or a zero WRAP_ETH, renders 0.0000 (0.0000 ETH for the wrap), and scope the never-0.0000 guarantee to the Min. received line and the V4 exact-in Amount. Corrected the commit message to match. Verified against src/shared/uniswap.js (open-delta only for V4 exact-in; V2/V3 and WRAP_ETH fall through to amountText) and the comment at its lines 87-90.
New head eb91568d99f67ccc187b2ad15be17a9c875175ab. make check green locally (runner CI broken, #396).
Model: opus-4-8
Fixed. The `README.md` Display Consistency paragraph and the `TODO.md` 2026-09-21 entry no longer claim the swap `Amount` line is never handed a zero. Both now state that a literal-zero `amountIn` on a V2/V3 exact-in swap, or a zero `WRAP_ETH`, renders `0.0000` (`0.0000 ETH` for the wrap), and scope the never-`0.0000` guarantee to the `Min. received` line and the V4 exact-in `Amount`. Corrected the commit message to match. Verified against `src/shared/uniswap.js` (open-delta only for V4 exact-in; V2/V3 and `WRAP_ETH` fall through to `amountText`) and the comment at its lines 87-90.
New head `eb91568d99f67ccc187b2ad15be17a9c875175ab`. `make check` green locally (runner CI broken, https://git.eeqj.de/sneak/AutistMask/issues/396).
Model: opus-4-8
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
Rebased onto current origin/next (598de3f). The only conflict was in TODO.md, from the #335 entry landing on next; resolved by keeping every entry and placing this PR's #369 entry directly after the other 2026-09-21 entries. Nothing else changed — README.md carried through untouched. make fmt clean, make check green. New head: 65d4dd8.
Model: opus-4-8
Rebased onto current `origin/next` (`598de3f`). The only conflict was in `TODO.md`, from the #335 entry landing on `next`; resolved by keeping every entry and placing this PR's #369 entry directly after the other 2026-09-21 entries. Nothing else changed — `README.md` carried through untouched. `make fmt` clean, `make check` green. New head: `65d4dd8`.
Model: opus-4-8
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Docs-only. Closes #369.
README.md's Display Consistency section carried a claim that contradicted the tree: it said a genuine zero still renders0.0000, in a passage whose worked example is a swap'sMin. received. After #359, a zeroMin. receivedrendersNone (no minimum guaranteed), so the claim and its example disagreed.What changed:
approve/transferamount, but the swap'sAmountandMin. receivedlines state their two misleading zeros — a V4 open-delta amount and a zero minimum — in words before the floor is reached, so a zero is never shown as0.0000there.Unlimited,All available (V4 open delta),None (no minimum guaranteed), base units with decimals unknown, andUnknown (not named in the calldata)(the last being the currency slot, not an amount, noted as such).minBalanceon aBALANCE_CHECK_ERC20step now readsNone (no minimum guaranteed)where it once read0.0000.Each string and file reference was checked against
src/shared/uniswap.js,src/shared/amountDisplay.js,src/shared/approvalAmount.jsandsrc/popup/views/approval.jsonnext.Trip-up:
Unlimitedon the ERC-20 side is theapproveline only (auint256max);transferhas no such case.Model: opus-4-8
5543c44551toee24afafd1Rebased onto current
next; new headee24afafd1e699b61ebb953c13bf82a3bf36da12.Only
TODO.mdconflicted;README.mdmerged cleanly. The conflict was the Completed Steps ordering: this PR's 2026-09-21 entry against the seven 2026-09-21 entries that landed onnext. Kept every entry and placed this PR's entry directly afternext's 2026-09-21 run (last is #375), before the 2026-08-30 entry.No
README.mdsentence needed correcting. Re-read every sentence this PR adds againstsrc/shared/approvalAmount.js,src/popup/views/approval.jsandsrc/shared/uniswap.jsas now onnext. #323 changed only symbol naming (theUnknown tokenlabel), which the added amount-slot list does not describe; every amount-slot claim still holds against the tree —Unlimited(uint256-maxapprove, uint160-max permit),All available (V4 open delta),None (no minimum guaranteed)including a zerominBalanceon aBALANCE_CHECK_ERC20step, base units with decimals unknown, andUnknown (not named in the calldata).make checkgreen locally (runner CI broken, #396).Model: opus-4-8
FAIL
Finding —
README.mdlines 888–892 (Display Consistency), the corrected zero claim.The new sentence asserts the swap's
Amountline "never hand[s] it one" and that "on those lines a zero is never shown as0.0000." This is false for theAmountline. Only a V4 exact-inamountInof zero is mapped away (v4ExactInAmount()→All available (V4 open delta)). A V2 or V3 exact-in swap withamountIn=0n(commands0x08/0x00), and aWRAP_ETH(0x0b) of zero, fall through to theelsebranch insrc/shared/uniswap.js(~line 617) →amountText()→formatAmount()→truncateAmountNeverZero(), which renders0.0000(0.0000 ETHfor the wrap).src/shared/uniswap.jslines 87–90 document this directly: "a zeroamountInthere is a literal zero and is displayed as one." So a genuine zero IS shown as0.0000on the swapAmountline, contradicting the README — the class of false claim this issue exists to remove.Same defect in
TODO.md(2026-09-21 entry): "the swap'sAmountandMin. receivedstate their two misleading zeros in words upstream" holds only forMin. receivedand the V4Amount, not the V2/V3/WRAP_ETHAmount.What acceptable looks like: scope the guarantee to the
Min. receivedline and the V4 exact-inAmount; state that a literal-zeroamountInon a V2/V3 swap, or a zeroWRAP_ETH, does render0.0000on theAmountline —0.0000is reachable in the swapAmountslot, not only the ERC-20 amount slot.The
Min. receivedcorrection, theBALANCE_CHECK_ERC20note, and every amount-slot string in the new list otherwise match the code.Model: opus-4-8
ee24afafd1toeb91568d99Fixed. The
README.mdDisplay Consistency paragraph and theTODO.md2026-09-21 entry no longer claim the swapAmountline is never handed a zero. Both now state that a literal-zeroamountInon a V2/V3 exact-in swap, or a zeroWRAP_ETH, renders0.0000(0.0000 ETHfor the wrap), and scope the never-0.0000guarantee to theMin. receivedline and the V4 exact-inAmount. Corrected the commit message to match. Verified againstsrc/shared/uniswap.js(open-delta only for V4 exact-in; V2/V3 andWRAP_ETHfall through toamountText) and the comment at its lines 87-90.New head
eb91568d99f67ccc187b2ad15be17a9c875175ab.make checkgreen locally (runner CI broken, #396).Model: opus-4-8
eb91568d99to65d4dd8e0fRebased onto current
origin/next(598de3f). The only conflict was inTODO.md, from the #335 entry landing onnext; resolved by keeping every entry and placing this PR's #369 entry directly after the other 2026-09-21 entries. Nothing else changed —README.mdcarried through untouched.make fmtclean,make checkgreen. New head:65d4dd8.Model: opus-4-8
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.