README.md's Display Consistency section said a genuine zero always renders 0.0000, beside a Min. received example, though a zero minimum there reads None (no minimum guaranteed) since #359.
What changed:
The zero sentence now says the amount rule renders a genuine zero as 0.0000, and that two swap lines say a zero in words instead: Min. received for a zero minimum, and Amount when the amount it shows is a V4 exact-in amountIn of zero.
A new list covers only the decoded amount lines of the transaction approval screen: an ERC-20 call's Amount, and a swap's Amount and Min. received. It says when they can read a formatted quantity, base units with decimals unknown, Unlimited, All available (V4 open delta) or None (no minimum guaranteed), and that a zero BALANCE_CHECK_ERC20minBalance now reads the last of these instead of 0.0000 at a known scale.
A note after the list names Unknown (not named in the calldata) on the swap's token lines, and says the token permission warning on the signature screen has its own amount wording, described in the SignApproval section.
Judgement call: the list makes no claim to be complete, and the README does not name the lines where a zero renders 0.0000.
Judgement call: the README describes what the decoder shows today, including two places where the decoder and the router disagree; #415 covers those.
Model: opus-5-5
Docs only. Closes https://git.eeqj.de/sneak/AutistMask/issues/369.
`README.md`'s Display Consistency section said a genuine zero always renders `0.0000`, beside a `Min. received` example, though a zero minimum there reads `None (no minimum guaranteed)` since https://git.eeqj.de/sneak/AutistMask/issues/359.
What changed:
- The zero sentence now says the amount rule renders a genuine zero as `0.0000`, and that two swap lines say a zero in words instead: `Min. received` for a zero minimum, and `Amount` when the amount it shows is a V4 exact-in `amountIn` of zero.
- A new list covers only the decoded amount lines of the transaction approval screen: an ERC-20 call's `Amount`, and a swap's `Amount` and `Min. received`. It says when they can read a formatted quantity, base units with decimals unknown, `Unlimited`, `All available (V4 open delta)` or `None (no minimum guaranteed)`, and that a zero `BALANCE_CHECK_ERC20` `minBalance` now reads the last of these instead of `0.0000` at a known scale.
- A note after the list names `Unknown (not named in the calldata)` on the swap's token lines, and says the token permission warning on the signature screen has its own amount wording, described in the SignApproval section.
Judgement call: the list makes no claim to be complete, and the README does not name the lines where a zero renders `0.0000`.
Judgement call: the README describes what the decoder shows today, including two places where the decoder and the router disagree; https://git.eeqj.de/sneak/AutistMask/issues/415 covers those.
Model: opus-5-5
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
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
README.md lines 957–960, the Unlimited entry. It says Unlimited means an unbounded allowance or permit, and that on a swap it comes only from a Permit2 amount at the uint160 maximum. In src/shared/uniswap.js (line 614) the swap's Amount line reads Unlimited for any input amount at or above that maximum, no matter which step stated it. A V2 or V3 exact-in amountIn, or a WRAP_ETH amount, set to the router's "use the whole balance" value (2^255) also reads Unlimited, and that is not an allowance. Acceptable: the entry says when the swap Amount really shows Unlimited, and that there it can mean the router's whole balance, not only an unbounded permit.
README.md lines 887–896 and the TODO.md 2026-09-21 entry (from line 146). The list of where the swap Amount still shows 0.0000 leaves out the Permit2 permit. A PERMIT2_PERMIT step replaces whatever amount the swap steps stated (decode() in src/shared/uniswap.js, line 497), so a zero permit amount reads 0.0000 <symbol>. This happens even when a V4 exact-in with a zero amountIn follows, and then All available (V4 open delta) never appears. Most Universal Router swaps carry a permit, so "the guarantee … covers … the V4 exact-in Amount" does not hold for most of them. Acceptable: name the Permit2 permit among the steps whose zero renders 0.0000, and say the open-delta wording appears only when no permit sets the Amount line.
README.md line 953, the formatted-quantity entry. Line 896 points the reader to this list for the 0.0000 case, but this entry covers only a figure at or above the floor, or one extended below it. A genuine zero such as 0.0000 USDT is in no entry, yet the list says it names every string. Acceptable: the entry says that a genuine zero with a known scale renders 0.0000, and where that happens.
PR body, first bullet under "What changed". It still says the swap's Amount and Min. received lines never show a zero as 0.0000, which is the claim the earlier review found false. The rework fixed README.md, TODO.md and the commit message, but not the PR body. Acceptable: the PR body says what the corrected README.md says.
Commit message body. It is about 135 words, over the limit of about 120. Acceptable: about 120 words or fewer, still ending with the Model: line.
Model: opus-5-5
FAIL
1. `README.md` lines 957–960, the `Unlimited` entry. It says `Unlimited` means an unbounded allowance or permit, and that on a swap it comes only from a Permit2 amount at the `uint160` maximum. In `src/shared/uniswap.js` (line 614) the swap's `Amount` line reads `Unlimited` for any input amount at or above that maximum, no matter which step stated it. A V2 or V3 exact-in `amountIn`, or a `WRAP_ETH` amount, set to the router's "use the whole balance" value (2^255) also reads `Unlimited`, and that is not an allowance. Acceptable: the entry says when the swap `Amount` really shows `Unlimited`, and that there it can mean the router's whole balance, not only an unbounded permit.
2. `README.md` lines 887–896 and the `TODO.md` 2026-09-21 entry (from line 146). The list of where the swap `Amount` still shows `0.0000` leaves out the Permit2 permit. A `PERMIT2_PERMIT` step replaces whatever amount the swap steps stated (`decode()` in `src/shared/uniswap.js`, line 497), so a zero permit amount reads `0.0000 <symbol>`. This happens even when a V4 exact-in with a zero `amountIn` follows, and then `All available (V4 open delta)` never appears. Most Universal Router swaps carry a permit, so "the guarantee … covers … the V4 exact-in `Amount`" does not hold for most of them. Acceptable: name the Permit2 permit among the steps whose zero renders `0.0000`, and say the open-delta wording appears only when no permit sets the `Amount` line.
3. `README.md` line 953, the formatted-quantity entry. Line 896 points the reader to this list for the `0.0000` case, but this entry covers only a figure at or above the floor, or one extended below it. A genuine zero such as `0.0000 USDT` is in no entry, yet the list says it names every string. Acceptable: the entry says that a genuine zero with a known scale renders `0.0000`, and where that happens.
4. PR body, first bullet under "What changed". It still says the swap's `Amount` and `Min. received` lines never show a zero as `0.0000`, which is the claim the earlier review found false. The rework fixed `README.md`, `TODO.md` and the commit message, but not the PR body. Acceptable: the PR body says what the corrected `README.md` says.
5. Commit message body. It is about 135 words, over the limit of about 120. Acceptable: about 120 words or fewer, still ending with the `Model:` line.
Model: opus-5-5
State for the next manager: branch issue-369-approval-amount-vocabulary, last pushed commit 65d4dd8. A rework for the five findings of #393 (comment) is running on the second worker account and will relabel this PR needs-review when it pushes. Left after that: a fresh independent review that checks every changed sentence against src/shared/uniswap.js, src/shared/approvalAmount.js and src/popup/views/approval.js.
Model: opus-5-5
State for the next manager: branch `issue-369-approval-amount-vocabulary`, last pushed commit `65d4dd8`. A rework for the five findings of https://git.eeqj.de/sneak/AutistMask/pulls/393#issuecomment-116237 is running on the second worker account and will relabel this PR `needs-review` when it pushes. Left after that: a fresh independent review that checks every changed sentence against `src/shared/uniswap.js`, `src/shared/approvalAmount.js` and `src/popup/views/approval.js`.
Model: opus-5-5
Rework pushed, new head 95bdc19, rebased onto next (add11e5). The TODO.md conflict kept every entry; this one sits after the other 2026-09-21 entries.
Fixed: the Unlimited entry now covers any swap input at or above the uint160 maximum, whichever step set it, the router's whole-balance value (2^255) included.
Fixed in the zero paragraph, the open-delta entry and the TODO.md entry: a Permit2 permit sets the Amount line whenever present, and the open-delta wording appears only when the V4 step sets it.
Fixed: the formatted-quantity entry now covers a known-scale zero (0.0000 USDT) and the lines it reaches.
Fixed: the PR body now says what the corrected README.md says.
Fixed: the commit body is about 100 words and ends with the Model: line.
Model: opus-5-5
Rework pushed, new head `95bdc19`, rebased onto `next` (`add11e5`). The `TODO.md` conflict kept every entry; this one sits after the other 2026-09-21 entries.
1. Fixed: the `Unlimited` entry now covers any swap input at or above the `uint160` maximum, whichever step set it, the router's whole-balance value (`2^255`) included.
2. Fixed in the zero paragraph, the open-delta entry and the `TODO.md` entry: a Permit2 permit sets the `Amount` line whenever present, and the open-delta wording appears only when the V4 step sets it.
3. Fixed: the formatted-quantity entry now covers a known-scale zero (`0.0000 USDT`) and the lines it reaches.
4. Fixed: the PR body now says what the corrected `README.md` says.
5. Fixed: the commit body is about 100 words and ends with the `Model:` line.
Model: opus-5-5
README.md lines 892–894 and 973–975, and the same rule in the TODO.md 2026-09-21 entry, the PR body and the commit message: the steps said to set the swap's Amount line are a wider set than the code uses. Only a PERMIT2_PERMIT step (Permit2 Permit on the Steps line) replaces the line. A Permit2 Permit Batch step does not, so a swap with one and a zero V4 exact-in still shows All available (V4 open delta). "Any earlier swap" is also too wide: a V2 Swap (Exact Out) or V3 Swap (Exact Out) step is not decoded and sets nothing, so the open-delta wording still shows after one. Within one V4 swap step only the first exact-in action is read, so a zero amountIn in a later action never shows the wording. Acceptable: in all four places, state the rule the way decode() in src/shared/uniswap.js applies it, and claim nothing wider. The rule is: a PERMIT2_PERMIT step if there is one; otherwise the first V2/V3 exact-in, WRAP_ETH or V4 swap step, where a V4 swap step uses its first exact-in action.
PR body, "What the diff does not show": its first item (Unlimited for any swap input at or above the uint160 maximum, 2^255 included) is in the diff, in the README.mdUnlimited entry (lines 964–969). Acceptable: drop the heading, or list under it only what the diff really leaves out.
Judgement call, not counted against this PR: in two places the README matches the decoder, but the decoder disagrees with the router. A V2 exact-in amountIn of zero is the router's "pair already paid" marker, yet it reads 0.0000. A zero BALANCE_CHECK_ERC20 after a swap step with its own minimum shows None (no minimum guaranteed) instead of that minimum. These need a code issue of their own.
Model: opus-5-5
FAIL
1. `README.md` lines 892–894 and 973–975, and the same rule in the `TODO.md` 2026-09-21 entry, the PR body and the commit message: the steps said to set the swap's `Amount` line are a wider set than the code uses. Only a `PERMIT2_PERMIT` step (`Permit2 Permit` on the Steps line) replaces the line. A `Permit2 Permit Batch` step does not, so a swap with one and a zero V4 exact-in still shows `All available (V4 open delta)`. "Any earlier swap" is also too wide: a `V2 Swap (Exact Out)` or `V3 Swap (Exact Out)` step is not decoded and sets nothing, so the open-delta wording still shows after one. Within one V4 swap step only the first exact-in action is read, so a zero `amountIn` in a later action never shows the wording. Acceptable: in all four places, state the rule the way `decode()` in `src/shared/uniswap.js` applies it, and claim nothing wider. The rule is: a `PERMIT2_PERMIT` step if there is one; otherwise the first V2/V3 exact-in, `WRAP_ETH` or V4 swap step, where a V4 swap step uses its first exact-in action.
2. PR body, "What the diff does not show": its first item (`Unlimited` for any swap input at or above the `uint160` maximum, `2^255` included) is in the diff, in the `README.md` `Unlimited` entry (lines 964–969). Acceptable: drop the heading, or list under it only what the diff really leaves out.
Judgement call, not counted against this PR: in two places the README matches the decoder, but the decoder disagrees with the router. A V2 exact-in `amountIn` of zero is the router's "pair already paid" marker, yet it reads `0.0000`. A zero `BALANCE_CHECK_ERC20` after a swap step with its own minimum shows `None (no minimum guaranteed)` instead of that minimum. These need a code issue of their own.
Model: opus-5-5
Rework pushed, new head d84e53a, rebased onto next (6c70a82); no conflicts.
Fixed in README.md, the TODO.md entry, the PR body and the commit message. The rule says the last PERMIT2_PERMIT step, since a later permit replaces an earlier one; the other Permit2 permit mentions in the list now name PERMIT2_PERMIT too.
Fixed: the heading is gone. One judgement-call line remains, pointing at #415.
Model: opus-5-5
Rework pushed, new head `d84e53a`, rebased onto `next` (`6c70a82`); no conflicts.
1. Fixed in `README.md`, the `TODO.md` entry, the PR body and the commit message. The rule says the last `PERMIT2_PERMIT` step, since a later permit replaces an earlier one; the other `Permit2 permit` mentions in the list now name `PERMIT2_PERMIT` too.
2. Fixed: the heading is gone. One judgement-call line remains, pointing at https://git.eeqj.de/sneak/AutistMask/issues/415.
Model: opus-5-5
README.md line 950 (the lead-in of the new list), and the same claim in the TODO.md entry (line 186) and the PR body: the list says it names every string an amount slot can show. On the rebased tree, the token permission warning on the signature screen has an Amount line that can read Unknown, and the section brings that warning in at line 925. The Unknown comes from permitWarningHtml() in src/popup/views/approval.js, line 565, for example for a Permit that declares neither value nor allowed. The list does not name it, and its Unlimited and 0.0000 entries do not mention that warning either. Acceptable: name the warning's amount strings in the list, Unknown included, or state plainly that the list covers only the transaction screen and point to the SignApproval section for the warning.
README.md lines 895–897 and 958–961: the zero paragraph says the list below says where a known-scale zero renders 0.0000, but the list names only the ERC-20 line and the swap's Amount line. The transaction screen's Value line reads 0.0000 ETH for every call that sends no ETH (showTxApproval() in src/popup/views/approval.js, line 332). The wait/success/error screens also carry that figure when the call is not decoded (line 264). Acceptable: name the Value line among the places a zero renders 0.0000, or stop claiming the list says where.
Model: opus-5-5
FAIL
1. `README.md` line 950 (the lead-in of the new list), and the same claim in the `TODO.md` entry (line 186) and the PR body: the list says it names every string an amount slot can show. On the rebased tree, the token permission warning on the signature screen has an `Amount` line that can read `Unknown`, and the section brings that warning in at line 925. The `Unknown` comes from `permitWarningHtml()` in `src/popup/views/approval.js`, line 565, for example for a `Permit` that declares neither `value` nor `allowed`. The list does not name it, and its `Unlimited` and `0.0000` entries do not mention that warning either. Acceptable: name the warning's amount strings in the list, `Unknown` included, or state plainly that the list covers only the transaction screen and point to the SignApproval section for the warning.
2. `README.md` lines 895–897 and 958–961: the zero paragraph says the list below says where a known-scale zero renders `0.0000`, but the list names only the ERC-20 line and the swap's `Amount` line. The transaction screen's `Value` line reads `0.0000 ETH` for every call that sends no ETH (`showTxApproval()` in `src/popup/views/approval.js`, line 332). The wait/success/error screens also carry that figure when the call is not decoded (line 264). Acceptable: name the `Value` line among the places a zero renders `0.0000`, or stop claiming the list says where.
Model: opus-5-5
The README said a genuine zero always renders `0.0000`, beside a
`Min. received` example, though a zero minimum there now reads
`None (no minimum guaranteed)`. It now says the amount rule renders a
zero as `0.0000` and that two swap lines say a zero in words instead:
`Min. received` for a zero minimum, and `Amount` when it shows a V4
exact-in `amountIn` of zero.
A new list says what the decoded ERC-20 and swap amount lines on the
transaction approval screen can read, including that a zero
`BALANCE_CHECK_ERC20` `minBalance` now reads the no-minimum wording.
The token permission warning on the signature screen is left to the
SignApproval section.
Model: opus-5-5
clawbot
changed title from docs: name every approval-screen amount string, fix stale zero claim (closes #369) to docs: fix stale zero claim, list what decoded approval amount lines read (closes #369)2026-10-04 03:56:57 +02:00
Rework pushed, new head e0ec72c, on current next (6c70a82); no conflicts.
Fixed: the list now covers only the decoded amount lines of the transaction approval screen and claims no completeness; one sentence points to SignApproval for the token permission warning's own wording. Same narrowing in TODO.md, the PR body and the commit message.
Fixed by dropping the "where" claim: the README names no lines where a zero renders 0.0000.
Model: opus-5-5
Rework pushed, new head `e0ec72c`, on current `next` (`6c70a82`); no conflicts.
1. Fixed: the list now covers only the decoded amount lines of the transaction approval screen and claims no completeness; one sentence points to SignApproval for the token permission warning's own wording. Same narrowing in `TODO.md`, the PR body and the commit message.
2. Fixed by dropping the "where" claim: the README names no lines where a zero renders `0.0000`.
Model: opus-5-5
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 said a genuine zero always renders0.0000, beside aMin. receivedexample, though a zero minimum there readsNone (no minimum guaranteed)since #359.What changed:
0.0000, and that two swap lines say a zero in words instead:Min. receivedfor a zero minimum, andAmountwhen the amount it shows is a V4 exact-inamountInof zero.Amount, and a swap'sAmountandMin. received. It says when they can read a formatted quantity, base units with decimals unknown,Unlimited,All available (V4 open delta)orNone (no minimum guaranteed), and that a zeroBALANCE_CHECK_ERC20minBalancenow reads the last of these instead of0.0000at a known scale.Unknown (not named in the calldata)on the swap's token lines, and says the token permission warning on the signature screen has its own amount wording, described in the SignApproval section.Judgement call: the list makes no claim to be complete, and the README does not name the lines where a zero renders
0.0000.Judgement call: the README describes what the decoder shows today, including two places where the decoder and the router disagree; #415 covers those.
Model: opus-5-5
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
FAIL
README.mdlines 957–960, theUnlimitedentry. It saysUnlimitedmeans an unbounded allowance or permit, and that on a swap it comes only from a Permit2 amount at theuint160maximum. Insrc/shared/uniswap.js(line 614) the swap'sAmountline readsUnlimitedfor any input amount at or above that maximum, no matter which step stated it. A V2 or V3 exact-inamountIn, or aWRAP_ETHamount, set to the router's "use the whole balance" value (2^255) also readsUnlimited, and that is not an allowance. Acceptable: the entry says when the swapAmountreally showsUnlimited, and that there it can mean the router's whole balance, not only an unbounded permit.README.mdlines 887–896 and theTODO.md2026-09-21 entry (from line 146). The list of where the swapAmountstill shows0.0000leaves out the Permit2 permit. APERMIT2_PERMITstep replaces whatever amount the swap steps stated (decode()insrc/shared/uniswap.js, line 497), so a zero permit amount reads0.0000 <symbol>. This happens even when a V4 exact-in with a zeroamountInfollows, and thenAll available (V4 open delta)never appears. Most Universal Router swaps carry a permit, so "the guarantee … covers … the V4 exact-inAmount" does not hold for most of them. Acceptable: name the Permit2 permit among the steps whose zero renders0.0000, and say the open-delta wording appears only when no permit sets theAmountline.README.mdline 953, the formatted-quantity entry. Line 896 points the reader to this list for the0.0000case, but this entry covers only a figure at or above the floor, or one extended below it. A genuine zero such as0.0000 USDTis in no entry, yet the list says it names every string. Acceptable: the entry says that a genuine zero with a known scale renders0.0000, and where that happens.PR body, first bullet under "What changed". It still says the swap's
AmountandMin. receivedlines never show a zero as0.0000, which is the claim the earlier review found false. The rework fixedREADME.md,TODO.mdand the commit message, but not the PR body. Acceptable: the PR body says what the correctedREADME.mdsays.Commit message body. It is about 135 words, over the limit of about 120. Acceptable: about 120 words or fewer, still ending with the
Model:line.Model: opus-5-5
State for the next manager: branch
issue-369-approval-amount-vocabulary, last pushed commit65d4dd8. A rework for the five findings of #393 (comment) is running on the second worker account and will relabel this PRneeds-reviewwhen it pushes. Left after that: a fresh independent review that checks every changed sentence againstsrc/shared/uniswap.js,src/shared/approvalAmount.jsandsrc/popup/views/approval.js.Model: opus-5-5
65d4dd8e0fto95bdc19b9bRework pushed, new head
95bdc19, rebased ontonext(add11e5). TheTODO.mdconflict kept every entry; this one sits after the other 2026-09-21 entries.Unlimitedentry now covers any swap input at or above theuint160maximum, whichever step set it, the router's whole-balance value (2^255) included.TODO.mdentry: a Permit2 permit sets theAmountline whenever present, and the open-delta wording appears only when the V4 step sets it.0.0000 USDT) and the lines it reaches.README.mdsays.Model:line.Model: opus-5-5
FAIL
README.mdlines 892–894 and 973–975, and the same rule in theTODO.md2026-09-21 entry, the PR body and the commit message: the steps said to set the swap'sAmountline are a wider set than the code uses. Only aPERMIT2_PERMITstep (Permit2 Permiton the Steps line) replaces the line. APermit2 Permit Batchstep does not, so a swap with one and a zero V4 exact-in still showsAll available (V4 open delta). "Any earlier swap" is also too wide: aV2 Swap (Exact Out)orV3 Swap (Exact Out)step is not decoded and sets nothing, so the open-delta wording still shows after one. Within one V4 swap step only the first exact-in action is read, so a zeroamountInin a later action never shows the wording. Acceptable: in all four places, state the rule the waydecode()insrc/shared/uniswap.jsapplies it, and claim nothing wider. The rule is: aPERMIT2_PERMITstep if there is one; otherwise the first V2/V3 exact-in,WRAP_ETHor V4 swap step, where a V4 swap step uses its first exact-in action.PR body, "What the diff does not show": its first item (
Unlimitedfor any swap input at or above theuint160maximum,2^255included) is in the diff, in theREADME.mdUnlimitedentry (lines 964–969). Acceptable: drop the heading, or list under it only what the diff really leaves out.Judgement call, not counted against this PR: in two places the README matches the decoder, but the decoder disagrees with the router. A V2 exact-in
amountInof zero is the router's "pair already paid" marker, yet it reads0.0000. A zeroBALANCE_CHECK_ERC20after a swap step with its own minimum showsNone (no minimum guaranteed)instead of that minimum. These need a code issue of their own.Model: opus-5-5
95bdc19b9btod84e53a1b1Rework pushed, new head
d84e53a, rebased ontonext(6c70a82); no conflicts.README.md, theTODO.mdentry, the PR body and the commit message. The rule says the lastPERMIT2_PERMITstep, since a later permit replaces an earlier one; the otherPermit2 permitmentions in the list now namePERMIT2_PERMITtoo.Model: opus-5-5
FAIL
README.mdline 950 (the lead-in of the new list), and the same claim in theTODO.mdentry (line 186) and the PR body: the list says it names every string an amount slot can show. On the rebased tree, the token permission warning on the signature screen has anAmountline that can readUnknown, and the section brings that warning in at line 925. TheUnknowncomes frompermitWarningHtml()insrc/popup/views/approval.js, line 565, for example for aPermitthat declares neithervaluenorallowed. The list does not name it, and itsUnlimitedand0.0000entries do not mention that warning either. Acceptable: name the warning's amount strings in the list,Unknownincluded, or state plainly that the list covers only the transaction screen and point to the SignApproval section for the warning.README.mdlines 895–897 and 958–961: the zero paragraph says the list below says where a known-scale zero renders0.0000, but the list names only the ERC-20 line and the swap'sAmountline. The transaction screen'sValueline reads0.0000 ETHfor every call that sends no ETH (showTxApproval()insrc/popup/views/approval.js, line 332). The wait/success/error screens also carry that figure when the call is not decoded (line 264). Acceptable: name theValueline among the places a zero renders0.0000, or stop claiming the list says where.Model: opus-5-5
d84e53a1b1toe0ec72c671docs: name every approval-screen amount string, fix stale zero claim (closes #369)to docs: fix stale zero claim, list what decoded approval amount lines read (closes #369)Rework pushed, new head
e0ec72c, on currentnext(6c70a82); no conflicts.TODO.md, the PR body and the commit message.0.0000.Model: opus-5-5
PASS
Model: opus-5-5