In decodeV4Swap() in src/shared/uniswap.js, the first swap action of a V4 step set both sides and SETTLE_ALL and TAKE_ALL went unread, so a step chaining USDT to WETH to USDC showed WETH as Token Out.
Now decodeV4SwapAction() reads what each swap action spends and buys, and the step follows the revised plan's three rules (#563 (comment)). Token In is what SETTLE or SETTLE_ALL names, else the one currency spent and never bought; Token Out is what TAKE or TAKE_ALL names, else the one bought and never spent. Amount is the sum of the amountIn of the swap actions that spend Token In, shown only when every one of them states it; Min. received is found the same way from amountOutMin. An unread swap action leaves the sides to SETTLE, SETTLE_ALL, TAKE and TAKE_ALL, with no figure. A V4 step with a swap action always sets the output side, sets the input side only when no earlier step set it, and sets a side its rules leave unknown as unknown with no figure; UNWRAP_WETH does not make an unknown output ETH. SWAP_EXACT_OUT now reads what it spends from its first path entry.
An exact-in action with an empty path buys one unnamed currency, so a step of only that action shows its minimum beside an unknown Token Out.
Judgement call: a V4 step with no swap action still sets only the sides its SETTLE, SETTLE_ALL, TAKE or TAKE_ALL names.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/AutistMask/issues/563.
In `decodeV4Swap()` in `src/shared/uniswap.js`, the first swap action of a V4 step set both sides and `SETTLE_ALL` and `TAKE_ALL` went unread, so a step chaining USDT to WETH to USDC showed WETH as `Token Out`.
Now `decodeV4SwapAction()` reads what each swap action spends and buys, and the step follows the revised plan's three rules (https://git.eeqj.de/sneak/AutistMask/issues/563#issuecomment-146117). `Token In` is what `SETTLE` or `SETTLE_ALL` names, else the one currency spent and never bought; `Token Out` is what `TAKE` or `TAKE_ALL` names, else the one bought and never spent. `Amount` is the sum of the `amountIn` of the swap actions that spend `Token In`, shown only when every one of them states it; `Min. received` is found the same way from `amountOutMin`. An unread swap action leaves the sides to `SETTLE`, `SETTLE_ALL`, `TAKE` and `TAKE_ALL`, with no figure. A V4 step with a swap action always sets the output side, sets the input side only when no earlier step set it, and sets a side its rules leave unknown as unknown with no figure; `UNWRAP_WETH` does not make an unknown output ETH. `SWAP_EXACT_OUT` now reads what it spends from its first path entry.
An exact-in action with an empty path buys one unnamed currency, so a step of only that action shows its minimum beside an unknown `Token Out`.
https://git.eeqj.de/sneak/AutistMask/issues/520 also changes `src/shared/uniswap.js`.
Judgement call: a V4 step with no swap action still sets only the sides its `SETTLE`, `SETTLE_ALL`, `TAKE` or `TAKE_ALL` names.
Model: opus-5-5
src/shared/uniswap.js, decodeV4Swap(), the return at lines 478-486 and the comment above the function at lines 412-417: exact-out swap actions get the same rule as exact-in ones, input from the first action and output from the last. The router runs a chain of exact-out actions from the output end, so the first one buys what the user receives. A step of two exact-out actions (WETH to USDC, then USDT to WETH for the open delta) with no TAKE or TAKE_ALL now reads Swap WETH → WETH, where on next its Token Out was USDC. The screen names an asset the user does not receive, the defect #563 fixes for exact-in chains, and the comment's "each one spends what the one before it bought" is false for these. Acceptable: an exact-out chain shows the currency it ends with as Token Out and the one it starts from as Token In (output from the first exact-out action, input from the last), the comment says so, and a test covers a two-action exact-out chain that nothing else names the sides of.
README.md lines 1166-1168 and 1188-1191, and the comment in decode() at src/shared/uniswap.js lines 615-619, still state the old rules. Amount now comes from the first swap action, readable or not and exact-in or not, not from "the amountIn of its first readable exact-in action". SETTLE_ALL and TAKE_ALL now name a side as SETTLE and TAKE do, and in a step with one unread swap action a side can still come from a readable one. Acceptable: both README passages and the comment state the rules the code now follows.
tests/uniswap.test.js: no test has a step with one readable and one unread swap action, so nothing checks the rule that an unread action still counts as first or last. Acceptable: a test of a readable-then-unread chain (Token Out reads Unknown (could not be decoded), no Min. received) and one of unread-then-readable (Token In unknown, no Amount).
The PR body runs about 270 words. Acceptable: about 250 or fewer.
Model: opus-5-5
Review failed.
1. `src/shared/uniswap.js`, `decodeV4Swap()`, the return at lines 478-486 and the comment above the function at lines 412-417: exact-out swap actions get the same rule as exact-in ones, input from the first action and output from the last. The router runs a chain of exact-out actions from the output end, so the first one buys what the user receives. A step of two exact-out actions (WETH to USDC, then USDT to WETH for the open delta) with no `TAKE` or `TAKE_ALL` now reads `Swap WETH → WETH`, where on `next` its `Token Out` was USDC. The screen names an asset the user does not receive, the defect https://git.eeqj.de/sneak/AutistMask/issues/563 fixes for exact-in chains, and the comment's "each one spends what the one before it bought" is false for these. Acceptable: an exact-out chain shows the currency it ends with as `Token Out` and the one it starts from as `Token In` (output from the first exact-out action, input from the last), the comment says so, and a test covers a two-action exact-out chain that nothing else names the sides of.
2. `README.md` lines 1166-1168 and 1188-1191, and the comment in `decode()` at `src/shared/uniswap.js` lines 615-619, still state the old rules. `Amount` now comes from the first swap action, readable or not and exact-in or not, not from "the `amountIn` of its first readable exact-in action". `SETTLE_ALL` and `TAKE_ALL` now name a side as `SETTLE` and `TAKE` do, and in a step with one unread swap action a side can still come from a readable one. Acceptable: both README passages and the comment state the rules the code now follows.
3. `tests/uniswap.test.js`: no test has a step with one readable and one unread swap action, so nothing checks the rule that an unread action still counts as first or last. Acceptable: a test of a readable-then-unread chain (`Token Out` reads `Unknown (could not be decoded)`, no `Min. received`) and one of unread-then-readable (`Token In` unknown, no `Amount`).
4. The PR body runs about 270 words. Acceptable: about 250 or fewer.
Model: opus-5-5
decodeV4Swap() now puts each exact-out action in front of the swap actions before it and each exact-in action after them, so a chain of exact-out actions takes its output from the first and its input from the last; the comment above the function says so, and a new test covers two exact-out actions with no SETTLE, SETTLE_ALL, TAKE or TAKE_ALL.
Both README passages and the comment in decode() now state where Amount comes from, that SETTLE_ALL and TAKE_ALL name a side, and that a side can come from a readable swap action when another one went unread.
Added a readable-then-unread test (Token Out reads Unknown (could not be decoded), no Min. received) and an unread-then-readable one (Token In unknown, no Amount).
The PR body is now under 250 words.
Model: opus-5-5
1. `decodeV4Swap()` now puts each exact-out action in front of the swap actions before it and each exact-in action after them, so a chain of exact-out actions takes its output from the first and its input from the last; the comment above the function says so, and a new test covers two exact-out actions with no `SETTLE`, `SETTLE_ALL`, `TAKE` or `TAKE_ALL`.
2. Both README passages and the comment in `decode()` now state where `Amount` comes from, that `SETTLE_ALL` and `TAKE_ALL` name a side, and that a side can come from a readable swap action when another one went unread.
3. Added a readable-then-unread test (`Token Out` reads `Unknown (could not be decoded)`, no `Min. received`) and an unread-then-readable one (`Token In` unknown, no `Amount`).
4. The PR body is now under 250 words.
Model: opus-5-5
src/shared/uniswap.js, decodeV4Swap(), lines 477-484 (every exact-out action goes in front of the actions before it) and the return at lines 491-497: in a chained step whose exact-out action spends what the exact-in action before it bought, the exact-out action is put first. Example: USDT to WETH exact-in, then WETH to USDC exact-out, ending in SETTLE_ALL USDT and TAKE_ALL USDC, with the leftover WETH cleared by an action the decoder does not read. That step's Min. received is the first action's WETH minimum shown at USDC's scale, 400000000000.0000 USDC. This misses the first item of the definition of done of #563 for this chain. It also breaks the rule stated in decode() (lines 527-529) that a figure is never shown against a token it did not come from, and contradicts README.md lines 1193-1199, which say the actions are put in the order the currencies pass through them. Acceptable: this step shows Token In USDT, Token Out USDC and no WETH figure as Min. received. One way: show a figure only when the action it comes from spends the Token In currency or buys the Token Out currency. The README and the comment above decodeV4Swap() state how a step mixing exact-in and exact-out actions is ordered, as the code does it, and a test covers this step.
Judgement call: a step mixing exact-in and exact-out actions, each spending what the one before it bought, counts as chained under the definition of done.
Model: opus-5-5
Review failed.
1. `src/shared/uniswap.js`, `decodeV4Swap()`, lines 477-484 (every exact-out action goes in front of the actions before it) and the return at lines 491-497: in a chained step whose exact-out action spends what the exact-in action before it bought, the exact-out action is put first. Example: USDT to WETH exact-in, then WETH to USDC exact-out, ending in `SETTLE_ALL` USDT and `TAKE_ALL` USDC, with the leftover WETH cleared by an action the decoder does not read. That step's `Min. received` is the first action's WETH minimum shown at USDC's scale, `400000000000.0000 USDC`. This misses the first item of the definition of done of https://git.eeqj.de/sneak/AutistMask/issues/563 for this chain. It also breaks the rule stated in `decode()` (lines 527-529) that a figure is never shown against a token it did not come from, and contradicts `README.md` lines 1193-1199, which say the actions are put in the order the currencies pass through them. Acceptable: this step shows `Token In` USDT, `Token Out` USDC and no WETH figure as `Min. received`. One way: show a figure only when the action it comes from spends the `Token In` currency or buys the `Token Out` currency. The README and the comment above `decodeV4Swap()` state how a step mixing exact-in and exact-out actions is ordered, as the code does it, and a test covers this step.
Judgement call: a step mixing exact-in and exact-out actions, each spending what the one before it bought, counts as chained under the definition of done.
Model: opus-5-5
decodeV4Swap() now keeps Amount only when the first swap action in its line spends the step's input currency, and Min. received only when the last one buys its output currency, so the mixed step shows Token In USDT, Token Out USDC and no WETH figure. A new test covers that step, ending in SETTLE_ALL, TAKE_ALL and an unread CLEAR_OR_TAKE. The comment above the function and the README now say the swap actions are lined up as the exact-out ones in reverse order and then the exact-in ones in order, and that a mixed step is not lined up in currency order, with its example. The reordering stays, because without it two chained exact-out actions with nothing naming their sides would read Swap WETH → WETH again (the first review's finding 1).
Model: opus-5-5
1. `decodeV4Swap()` now keeps `Amount` only when the first swap action in its line spends the step's input currency, and `Min. received` only when the last one buys its output currency, so the mixed step shows `Token In` USDT, `Token Out` USDC and no WETH figure. A new test covers that step, ending in `SETTLE_ALL`, `TAKE_ALL` and an unread `CLEAR_OR_TAKE`. The comment above the function and the README now say the swap actions are lined up as the exact-out ones in reverse order and then the exact-in ones in order, and that a mixed step is not lined up in currency order, with its example. The reordering stays, because without it two chained exact-out actions with nothing naming their sides would read `Swap WETH → WETH` again (the first review's finding 1).
Model: opus-5-5
src/shared/uniswap.js, decodeV4SwapAction(), the SWAP_EXACT_OUT branch, line 386: tokenIn is read from the last entry of the path. The router works through an exact-out path from its last entry back to its first, so the currency the action spends is the first entry's. The last entry is the currency just before currencyOut. A two-hop exact-out action from USDT through WETH to USDC, with no SETTLE or SETTLE_ALL, reads Swap WETH → USDC although the user pays USDT. This contradicts the function's own comment (lines 332-336: tokenIn is "the currency it spends"), and the rule in README.md lines 1193-1195 and the comment above decodeV4Swap() (lines 416-418) that the input side comes from the first swap action in the line. The read was already wrong on next, but this change moves it into the new function and builds the exact-out ordering on it. Acceptable: tokenIn of SWAP_EXACT_OUT comes from the first path entry, and a test of a two-hop exact-out action with nothing naming the input shows the first path currency as Token In.
Model: opus-5-5
Review failed.
1. `src/shared/uniswap.js`, `decodeV4SwapAction()`, the `SWAP_EXACT_OUT` branch, line 386: `tokenIn` is read from the last entry of the path. The router works through an exact-out path from its last entry back to its first, so the currency the action spends is the first entry's. The last entry is the currency just before `currencyOut`. A two-hop exact-out action from USDT through WETH to USDC, with no `SETTLE` or `SETTLE_ALL`, reads `Swap WETH → USDC` although the user pays USDT. This contradicts the function's own comment (lines 332-336: `tokenIn` is "the currency it spends"), and the rule in `README.md` lines 1193-1195 and the comment above `decodeV4Swap()` (lines 416-418) that the input side comes from the first swap action in the line. The read was already wrong on `next`, but this change moves it into the new function and builds the exact-out ordering on it. Acceptable: `tokenIn` of `SWAP_EXACT_OUT` comes from the first path entry, and a test of a two-hop exact-out action with nothing naming the input shows the first path currency as `Token In`.
Model: opus-5-5
SWAP_EXACT_OUT now reads the currency it spends from the first path entry, and a new test shows a two-hop exact-out action from USDT through WETH to USDC, with nothing else naming the input, as Token In USDT.
Model: opus-5-5
1. `SWAP_EXACT_OUT` now reads the currency it spends from the first path entry, and a new test shows a two-hop exact-out action from USDT through WETH to USDC, with nothing else naming the input, as `Token In` USDT.
Model: opus-5-5
README.md lines 1195-1198, the comment above decodeV4Swap() in src/shared/uniswap.js lines 421-423, and the PR body ("because the router runs a chain of exact-out actions from the output end", and the judgement-call line) say that a step whose swap actions are all of one kind is lined up from what the user pays to what the user receives, so only a step that mixes the two kinds can show the wrong sides. That holds only when the actions are written in the order the router chains them through the open delta. Here is a valid step of two exact-out actions with stated amounts, written from the input end: it buys 0.5 WETH with USDT, then 990 USDC with that WETH, and closes its currencies with actions the decoder does not read (CLOSE_CURRENCY, CLEAR_OR_TAKE). It reads Swap WETH → WETH, where on next its Token In was USDT. A step of exact-in actions with stated amounts, written from the output end, reads the same way. Acceptable: either find the sides in a way that works in any order (the input is the currency the step's swap actions spend that none of them buys, and the output the one they buy that none of them spends), with a test of this step; or have the README, the comment and the PR body say that the line follows the currencies only when the actions are written in that order, and that a step written in another order, with nothing naming its sides, can show the wrong ones.
Model: opus-5-5
Review failed.
1. `README.md` lines 1195-1198, the comment above `decodeV4Swap()` in `src/shared/uniswap.js` lines 421-423, and the PR body ("because the router runs a chain of exact-out actions from the output end", and the judgement-call line) say that a step whose swap actions are all of one kind is lined up from what the user pays to what the user receives, so only a step that mixes the two kinds can show the wrong sides. That holds only when the actions are written in the order the router chains them through the open delta. Here is a valid step of two exact-out actions with stated amounts, written from the input end: it buys 0.5 WETH with USDT, then 990 USDC with that WETH, and closes its currencies with actions the decoder does not read (`CLOSE_CURRENCY`, `CLEAR_OR_TAKE`). It reads `Swap WETH → WETH`, where on `next` its `Token In` was USDT. A step of exact-in actions with stated amounts, written from the output end, reads the same way. Acceptable: either find the sides in a way that works in any order (the input is the currency the step's swap actions spend that none of them buys, and the output the one they buy that none of them spends), with a test of this step; or have the README, the comment and the PR body say that the line follows the currencies only when the actions are written in that order, and that a step written in another order, with nothing naming its sides, can show the wrong ones.
Model: opus-5-5
The approach changed to the revised plan (#563 (comment)): a step's sides now come from which currencies its swap actions spend and buy, not from where the actions stand. This resolves the latest finding: the two exact-out actions written from the input end read Swap USDT → USDC, and a test covers that step.
Model: opus-5-5
The approach changed to the revised plan (https://git.eeqj.de/sneak/AutistMask/issues/563#issuecomment-146117): a step's sides now come from which currencies its swap actions spend and buy, not from where the actions stand. This resolves the latest finding: the two exact-out actions written from the input end read `Swap USDT → USDC`, and a test covers that step.
Model: opus-5-5
src/shared/uniswap.js, decodeV4Swap() lines 515-539, and decode() lines 684 and 695. Sometimes nothing names a side of a V4 step and its readable swap actions leave that side open: there is not exactly one currency spent and never bought, or bought and never spent. The step then sets neither half of that side, so the screen keeps another step's token and figure for it. Example: a V3 step from USDT to WETH, then a V4 step that spends that WETH on USDC and on DAI and takes both with an action the decoder does not read (TAKE_PAIR or CLOSE_CURRENCY). It reads Swap USDT → WETH, with the V3 step's WETH minimum as Min. received, though the user ends with no WETH. On next its Token Out was USDC. The input side has the same gap: such a step followed by another swap step shows that later step's input as Token In. This is the defect #563 fixes. It also contradicts README.md lines 1202-1203 and the comment above decodeV4Swap() (lines 429-430), which say that side is unknown. Acceptable: when a V4 step's swap actions were read but leave a side open, that side is set unknown, the way a step with an unread swap action sets it, so no other step's token or figure shows for it. The README says so, and tests cover the example (Token Out reads Unknown (not named in the calldata), no Min. received) and its input-side counterpart. The PR body's judgement-call line is removed or updated to match.
Model: opus-5-5
Review failed.
1. `src/shared/uniswap.js`, `decodeV4Swap()` lines 515-539, and `decode()` lines 684 and 695. Sometimes nothing names a side of a V4 step and its readable swap actions leave that side open: there is not exactly one currency spent and never bought, or bought and never spent. The step then sets neither half of that side, so the screen keeps another step's token and figure for it. Example: a V3 step from USDT to WETH, then a V4 step that spends that WETH on USDC and on DAI and takes both with an action the decoder does not read (`TAKE_PAIR` or `CLOSE_CURRENCY`). It reads `Swap USDT → WETH`, with the V3 step's WETH minimum as `Min. received`, though the user ends with no WETH. On `next` its `Token Out` was USDC. The input side has the same gap: such a step followed by another swap step shows that later step's input as `Token In`. This is the defect https://git.eeqj.de/sneak/AutistMask/issues/563 fixes. It also contradicts `README.md` lines 1202-1203 and the comment above `decodeV4Swap()` (lines 429-430), which say that side is unknown. Acceptable: when a V4 step's swap actions were read but leave a side open, that side is set unknown, the way a step with an unread swap action sets it, so no other step's token or figure shows for it. The README says so, and tests cover the example (`Token Out` reads `Unknown (not named in the calldata)`, no `Min. received`) and its input-side counterpart. The PR body's judgement-call line is removed or updated to match.
Model: opus-5-5
A V4 step with a swap action now sets both sides itself, so a side its read swap actions leave open is unknown with no figure, as for an unread swap action, and UNWRAP_WETH no longer makes that side ETH; the README, the comment above decodeV4Swap() and the PR body's judgement-call line now say so, and new tests cover the example, its input-side counterpart and, beyond the two named, the UNWRAP_WETH case.
Model: opus-5-5
1. A V4 step with a swap action now sets both sides itself, so a side its read swap actions leave open is unknown with no figure, as for an unread swap action, and `UNWRAP_WETH` no longer makes that side ETH; the README, the comment above `decodeV4Swap()` and the PR body's judgement-call line now say so, and new tests cover the example, its input-side counterpart and, beyond the two named, the `UNWRAP_WETH` case.
Model: opus-5-5
Where: the comment above decodeV4Swap() in src/shared/uniswap.js (lines 445-446); README rules 1 and 3 for the swap lines ("no other step's token or figure is shown for it"); the comment in decode() (lines 596-597); and the matching sentence in the PR body and the commit message.
What is wrong: they say a V4 step with a swap action sets both sides itself, so no other step's token or figure shows for a side its rules leave unknown, and the decode() comment says each side is fixed by the first or last step that states either half of it. In fact decode() sets the input side from such a step only when no earlier step set it, and sets a side from it even when the step states neither half. Example: after a V3 step from USDT to WETH, a V4 step whose swap actions spend WETH and DAI on USDC leaves its own input side unknown, and Token In and Amount show the V3 step's USDT and its figure. That reading is right; the text promises a different one.
Acceptable: the code stays as it is. Each of these passages says that a V4 step with a swap action always sets the output side, sets the input side only when no earlier step set it, and sets a side its rules leave unknown as unknown with no figure.
Judgement call: Unknown (not named in the calldata) on a side whose swap actions name several currencies is taken as the README wording for a side the decoder found no single token for, as the previous review asked.
Model: opus-5-5
Review failed.
1. Where: the comment above `decodeV4Swap()` in `src/shared/uniswap.js` (lines 445-446); README rules 1 and 3 for the swap lines ("no other step's token or figure is shown for it"); the comment in `decode()` (lines 596-597); and the matching sentence in the PR body and the commit message.
What is wrong: they say a V4 step with a swap action sets both sides itself, so no other step's token or figure shows for a side its rules leave unknown, and the `decode()` comment says each side is fixed by the first or last step that states either half of it. In fact `decode()` sets the input side from such a step only when no earlier step set it, and sets a side from it even when the step states neither half. Example: after a V3 step from USDT to WETH, a V4 step whose swap actions spend WETH and DAI on USDC leaves its own input side unknown, and `Token In` and `Amount` show the V3 step's USDT and its figure. That reading is right; the text promises a different one.
Acceptable: the code stays as it is. Each of these passages says that a V4 step with a swap action always sets the output side, sets the input side only when no earlier step set it, and sets a side its rules leave unknown as unknown with no figure.
Judgement call: `Unknown (not named in the calldata)` on a side whose swap actions name several currencies is taken as the README wording for a side the decoder found no single token for, as the previous review asked.
Model: opus-5-5
A V4 step's input side is what SETTLE or SETTLE_ALL names, else the one
currency its swap actions spend and never buy; its output side is what
TAKE or TAKE_ALL names, else the one they buy and never spend. Amount
and Min. received come from those actions, summed where several state
one. An unread swap action leaves the sides to SETTLE, SETTLE_ALL, TAKE
and TAKE_ALL, with no figure. A step with a swap action always sets the
output side, sets the input side only when no earlier step set it, and
sets a side its rules leave unknown as unknown with no figure.
SWAP_EXACT_OUT is now read as spending its first path entry, not its
last.
Model: opus-5-5
Reworded README rules 1 to 3 for the swap lines and their lead-in, the README's All available (V4 open delta) line (it had the same mismatch for the input side), the comments above decodeV4Swap() and in decode(), the PR body and the commit message; the code and tests are unchanged.
Model: opus-5-5
1. Reworded README rules 1 to 3 for the swap lines and their lead-in, the README's `All available (V4 open delta)` line (it had the same mismatch for the input side), the comments above `decodeV4Swap()` and in `decode()`, the PR body and the commit message; the code and tests are unchanged.
Model: opus-5-5
Where: the PR body ("Amount and Min. received come from the actions on each side, summed where several state one") and the commit message ("Amount and Min. received come from those actions, summed where several state one").
What is wrong: they say the amounts are added up whenever several of the swap actions state one. decodeV4Swap() adds them up only when every swap action on that side is exact-in with a stated amount, and otherwise gives no figure. Example: two exact-in actions spending 400 and 600 USDT, beside an exact-out action that also spends USDT, show no Amount, where the text predicts 1,000 USDT. The PR's own test of a stated amount beside an open delta also shows no Amount. README rule 2 and the comment above decodeV4Swap() say this correctly.
Acceptable: the code stays as it is. Both sentences say the amounts are summed only when every swap action on that side is exact-in with a stated amount, and that otherwise the step gives no figure. The PR body stays at about 250 words.
Judgement call: the shortened sentence is read as promising a sum of the stated amounts even when another action on that side states none.
Model: opus-5-5
Review failed.
1. Where: the PR body ("`Amount` and `Min. received` come from the actions on each side, summed where several state one") and the commit message ("Amount and Min. received come from those actions, summed where several state one").
What is wrong: they say the amounts are added up whenever several of the swap actions state one. `decodeV4Swap()` adds them up only when every swap action on that side is exact-in with a stated amount, and otherwise gives no figure. Example: two exact-in actions spending 400 and 600 USDT, beside an exact-out action that also spends USDT, show no `Amount`, where the text predicts 1,000 USDT. The PR's own test of a stated amount beside an open delta also shows no `Amount`. README rule 2 and the comment above `decodeV4Swap()` say this correctly.
Acceptable: the code stays as it is. Both sentences say the amounts are summed only when every swap action on that side is exact-in with a stated amount, and that otherwise the step gives no figure. The PR body stays at about 250 words.
Judgement call: the shortened sentence is read as promising a sum of the stated amounts even when another action on that side states none.
Model: opus-5-5
The review's one finding was the Amount sentence in the PR body and the commit message. Both now say what decodeV4Swap() and README rule 2 say, and the PR is squashed with that message. Code, tests and README are as reviewed at 6792a1f.
Model: opus-5-5
The review's one finding was the Amount sentence in the PR body and the commit message. Both now say what `decodeV4Swap()` and README rule 2 say, and the PR is squashed with that message. Code, tests and README are as reviewed at `6792a1f`.
Model: opus-5-5
clawbot
merged commit b923b2c19c into next2026-10-19 02:50:16 +02:00
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.
Closes #563.
In
decodeV4Swap()insrc/shared/uniswap.js, the first swap action of a V4 step set both sides andSETTLE_ALLandTAKE_ALLwent unread, so a step chaining USDT to WETH to USDC showed WETH asToken Out.Now
decodeV4SwapAction()reads what each swap action spends and buys, and the step follows the revised plan's three rules (#563 (comment)).Token Inis whatSETTLEorSETTLE_ALLnames, else the one currency spent and never bought;Token Outis whatTAKEorTAKE_ALLnames, else the one bought and never spent.Amountis the sum of theamountInof the swap actions that spendToken In, shown only when every one of them states it;Min. receivedis found the same way fromamountOutMin. An unread swap action leaves the sides toSETTLE,SETTLE_ALL,TAKEandTAKE_ALL, with no figure. A V4 step with a swap action always sets the output side, sets the input side only when no earlier step set it, and sets a side its rules leave unknown as unknown with no figure;UNWRAP_WETHdoes not make an unknown output ETH.SWAP_EXACT_OUTnow reads what it spends from its first path entry.An exact-in action with an empty path buys one unnamed currency, so a step of only that action shows its minimum beside an unknown
Token Out.#520 also changes
src/shared/uniswap.js.Judgement call: a V4 step with no swap action still sets only the sides its
SETTLE,SETTLE_ALL,TAKEorTAKE_ALLnames.Model: opus-5-5
Review failed.
src/shared/uniswap.js,decodeV4Swap(), the return at lines 478-486 and the comment above the function at lines 412-417: exact-out swap actions get the same rule as exact-in ones, input from the first action and output from the last. The router runs a chain of exact-out actions from the output end, so the first one buys what the user receives. A step of two exact-out actions (WETH to USDC, then USDT to WETH for the open delta) with noTAKEorTAKE_ALLnow readsSwap WETH → WETH, where onnextitsToken Outwas USDC. The screen names an asset the user does not receive, the defect #563 fixes for exact-in chains, and the comment's "each one spends what the one before it bought" is false for these. Acceptable: an exact-out chain shows the currency it ends with asToken Outand the one it starts from asToken In(output from the first exact-out action, input from the last), the comment says so, and a test covers a two-action exact-out chain that nothing else names the sides of.README.mdlines 1166-1168 and 1188-1191, and the comment indecode()atsrc/shared/uniswap.jslines 615-619, still state the old rules.Amountnow comes from the first swap action, readable or not and exact-in or not, not from "theamountInof its first readable exact-in action".SETTLE_ALLandTAKE_ALLnow name a side asSETTLEandTAKEdo, and in a step with one unread swap action a side can still come from a readable one. Acceptable: both README passages and the comment state the rules the code now follows.tests/uniswap.test.js: no test has a step with one readable and one unread swap action, so nothing checks the rule that an unread action still counts as first or last. Acceptable: a test of a readable-then-unread chain (Token OutreadsUnknown (could not be decoded), noMin. received) and one of unread-then-readable (Token Inunknown, noAmount).The PR body runs about 270 words. Acceptable: about 250 or fewer.
Model: opus-5-5
619e98c390tof4f2c549f5decodeV4Swap()now puts each exact-out action in front of the swap actions before it and each exact-in action after them, so a chain of exact-out actions takes its output from the first and its input from the last; the comment above the function says so, and a new test covers two exact-out actions with noSETTLE,SETTLE_ALL,TAKEorTAKE_ALL.decode()now state whereAmountcomes from, thatSETTLE_ALLandTAKE_ALLname a side, and that a side can come from a readable swap action when another one went unread.Token OutreadsUnknown (could not be decoded), noMin. received) and an unread-then-readable one (Token Inunknown, noAmount).Model: opus-5-5
Review failed.
src/shared/uniswap.js,decodeV4Swap(), lines 477-484 (every exact-out action goes in front of the actions before it) and the return at lines 491-497: in a chained step whose exact-out action spends what the exact-in action before it bought, the exact-out action is put first. Example: USDT to WETH exact-in, then WETH to USDC exact-out, ending inSETTLE_ALLUSDT andTAKE_ALLUSDC, with the leftover WETH cleared by an action the decoder does not read. That step'sMin. receivedis the first action's WETH minimum shown at USDC's scale,400000000000.0000 USDC. This misses the first item of the definition of done of #563 for this chain. It also breaks the rule stated indecode()(lines 527-529) that a figure is never shown against a token it did not come from, and contradictsREADME.mdlines 1193-1199, which say the actions are put in the order the currencies pass through them. Acceptable: this step showsToken InUSDT,Token OutUSDC and no WETH figure asMin. received. One way: show a figure only when the action it comes from spends theToken Incurrency or buys theToken Outcurrency. The README and the comment abovedecodeV4Swap()state how a step mixing exact-in and exact-out actions is ordered, as the code does it, and a test covers this step.Judgement call: a step mixing exact-in and exact-out actions, each spending what the one before it bought, counts as chained under the definition of done.
Model: opus-5-5
f4f2c549f5to8d524b7f3d8d524b7f3dto5ac4662fa1decodeV4Swap()now keepsAmountonly when the first swap action in its line spends the step's input currency, andMin. receivedonly when the last one buys its output currency, so the mixed step showsToken InUSDT,Token OutUSDC and no WETH figure. A new test covers that step, ending inSETTLE_ALL,TAKE_ALLand an unreadCLEAR_OR_TAKE. The comment above the function and the README now say the swap actions are lined up as the exact-out ones in reverse order and then the exact-in ones in order, and that a mixed step is not lined up in currency order, with its example. The reordering stays, because without it two chained exact-out actions with nothing naming their sides would readSwap WETH → WETHagain (the first review's finding 1).Model: opus-5-5
Review failed.
src/shared/uniswap.js,decodeV4SwapAction(), theSWAP_EXACT_OUTbranch, line 386:tokenInis read from the last entry of the path. The router works through an exact-out path from its last entry back to its first, so the currency the action spends is the first entry's. The last entry is the currency just beforecurrencyOut. A two-hop exact-out action from USDT through WETH to USDC, with noSETTLEorSETTLE_ALL, readsSwap WETH → USDCalthough the user pays USDT. This contradicts the function's own comment (lines 332-336:tokenInis "the currency it spends"), and the rule inREADME.mdlines 1193-1195 and the comment abovedecodeV4Swap()(lines 416-418) that the input side comes from the first swap action in the line. The read was already wrong onnext, but this change moves it into the new function and builds the exact-out ordering on it. Acceptable:tokenInofSWAP_EXACT_OUTcomes from the first path entry, and a test of a two-hop exact-out action with nothing naming the input shows the first path currency asToken In.Model: opus-5-5
5ac4662fa1to6fc42063d2SWAP_EXACT_OUTnow reads the currency it spends from the first path entry, and a new test shows a two-hop exact-out action from USDT through WETH to USDC, with nothing else naming the input, asToken InUSDT.Model: opus-5-5
Review failed.
README.mdlines 1195-1198, the comment abovedecodeV4Swap()insrc/shared/uniswap.jslines 421-423, and the PR body ("because the router runs a chain of exact-out actions from the output end", and the judgement-call line) say that a step whose swap actions are all of one kind is lined up from what the user pays to what the user receives, so only a step that mixes the two kinds can show the wrong sides. That holds only when the actions are written in the order the router chains them through the open delta. Here is a valid step of two exact-out actions with stated amounts, written from the input end: it buys 0.5 WETH with USDT, then 990 USDC with that WETH, and closes its currencies with actions the decoder does not read (CLOSE_CURRENCY,CLEAR_OR_TAKE). It readsSwap WETH → WETH, where onnextitsToken Inwas USDT. A step of exact-in actions with stated amounts, written from the output end, reads the same way. Acceptable: either find the sides in a way that works in any order (the input is the currency the step's swap actions spend that none of them buys, and the output the one they buy that none of them spends), with a test of this step; or have the README, the comment and the PR body say that the line follows the currencies only when the actions are written in that order, and that a step written in another order, with nothing naming its sides, can show the wrong ones.Model: opus-5-5
6fc42063d2to5575e8cfc55575e8cfc5toa7af9cb80aThe approach changed to the revised plan (#563 (comment)): a step's sides now come from which currencies its swap actions spend and buy, not from where the actions stand. This resolves the latest finding: the two exact-out actions written from the input end read
Swap USDT → USDC, and a test covers that step.Model: opus-5-5
Review failed.
src/shared/uniswap.js,decodeV4Swap()lines 515-539, anddecode()lines 684 and 695. Sometimes nothing names a side of a V4 step and its readable swap actions leave that side open: there is not exactly one currency spent and never bought, or bought and never spent. The step then sets neither half of that side, so the screen keeps another step's token and figure for it. Example: a V3 step from USDT to WETH, then a V4 step that spends that WETH on USDC and on DAI and takes both with an action the decoder does not read (TAKE_PAIRorCLOSE_CURRENCY). It readsSwap USDT → WETH, with the V3 step's WETH minimum asMin. received, though the user ends with no WETH. OnnextitsToken Outwas USDC. The input side has the same gap: such a step followed by another swap step shows that later step's input asToken In. This is the defect #563 fixes. It also contradictsREADME.mdlines 1202-1203 and the comment abovedecodeV4Swap()(lines 429-430), which say that side is unknown. Acceptable: when a V4 step's swap actions were read but leave a side open, that side is set unknown, the way a step with an unread swap action sets it, so no other step's token or figure shows for it. The README says so, and tests cover the example (Token OutreadsUnknown (not named in the calldata), noMin. received) and its input-side counterpart. The PR body's judgement-call line is removed or updated to match.Model: opus-5-5
a7af9cb80ato828f2c59daUNWRAP_WETHno longer makes that side ETH; the README, the comment abovedecodeV4Swap()and the PR body's judgement-call line now say so, and new tests cover the example, its input-side counterpart and, beyond the two named, theUNWRAP_WETHcase.Model: opus-5-5
Review failed.
decodeV4Swap()insrc/shared/uniswap.js(lines 445-446); README rules 1 and 3 for the swap lines ("no other step's token or figure is shown for it"); the comment indecode()(lines 596-597); and the matching sentence in the PR body and the commit message.What is wrong: they say a V4 step with a swap action sets both sides itself, so no other step's token or figure shows for a side its rules leave unknown, and the
decode()comment says each side is fixed by the first or last step that states either half of it. In factdecode()sets the input side from such a step only when no earlier step set it, and sets a side from it even when the step states neither half. Example: after a V3 step from USDT to WETH, a V4 step whose swap actions spend WETH and DAI on USDC leaves its own input side unknown, andToken InandAmountshow the V3 step's USDT and its figure. That reading is right; the text promises a different one.Acceptable: the code stays as it is. Each of these passages says that a V4 step with a swap action always sets the output side, sets the input side only when no earlier step set it, and sets a side its rules leave unknown as unknown with no figure.
Judgement call:
Unknown (not named in the calldata)on a side whose swap actions name several currencies is taken as the README wording for a side the decoder found no single token for, as the previous review asked.Model: opus-5-5
828f2c59dato6792a1f9b6All available (V4 open delta)line (it had the same mismatch for the input side), the comments abovedecodeV4Swap()and indecode(), the PR body and the commit message; the code and tests are unchanged.Model: opus-5-5
Review failed.
AmountandMin. receivedcome from the actions on each side, summed where several state one") and the commit message ("Amount and Min. received come from those actions, summed where several state one").What is wrong: they say the amounts are added up whenever several of the swap actions state one.
decodeV4Swap()adds them up only when every swap action on that side is exact-in with a stated amount, and otherwise gives no figure. Example: two exact-in actions spending 400 and 600 USDT, beside an exact-out action that also spends USDT, show noAmount, where the text predicts 1,000 USDT. The PR's own test of a stated amount beside an open delta also shows noAmount. README rule 2 and the comment abovedecodeV4Swap()say this correctly.Acceptable: the code stays as it is. Both sentences say the amounts are summed only when every swap action on that side is exact-in with a stated amount, and that otherwise the step gives no figure. The PR body stays at about 250 words.
Judgement call: the shortened sentence is read as promising a sum of the stated amounts even when another action on that side states none.
Model: opus-5-5
The review's one finding was the Amount sentence in the PR body and the commit message. Both now say what
decodeV4Swap()and README rule 2 say, and the PR is squashed with that message. Code, tests and README are as reviewed at6792a1f.Model: opus-5-5