…canary after #17) Adds the second mutation/canary pair, covering ERC1155 position state (distinct from #15/#16 which covered ERC20 wallet state). Establishes the mutation-pair-+-canary as a reusable pattern; future mutation types (allowances, native xDAI, NFT transfers, etc.) follow the same shape. Scenario #17 — position mutation: - Asserts pre-mutation "Available 1100 sDAI" (baseline) - Mutates ERC1155 state via setConditionalPosition on currencyYes + currencyNo IDs in HOOK_FALLBACK_POSITION_IDS, raising both 100 → 200 - Asserts post-mutation "Available 1200 sDAI" (wallet 1000 + min(YES 200, NO 200) = 1200). Both outcomes lifted because the panel reads min(YES, NO) — mutating only YES would leave the floor at 100. Scenario #18 — second isolation canary: - Asserts baseline "Available 1100 sDAI" again, after #17 ran - Catches "snapshot/revert breaks for ERC1155 nested-mapping mutations" — distinct from #16's "ERC20 flat-mapping mutations" coverage. Anvil's evm_revert could regress on one without the other (partial-revert bugs that drop nested-mapping writes are a documented class). Refactor: HOOK_FALLBACK_POSITION_IDS extracted from the inline constant in fork-state-setup.mjs to an exported constant in fork-state.mjs. globalSetup now imports + iterates the same export. Comment makes the distinction from deriveYesNoPositionIds() explicit. Verification: 18/18 scenarios pass live in 1.3 min (was 51.5s with 16 — +~30s for the two new scenarios). 65/65 smoke tests pass. Pattern established: mutation/canary pairs are now a reusable shape.

Uh oh!

Improve experience of showing positions #17

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions