89: Review

docs/EvelynLiquidityService.md

@@ -57,13 +57,16 @@ identities come from CIS; token programs and precision come from chain metadata.
 A single worker runs immediately on startup and then with fixed delay after
 completion. Every iteration follows the same three independent steps:
 
-1. Read current on-chain pool state in SyrupUSDC per EVE. For each owned,
-   positive-liquidity position in the configured pool, withdraw complete
+1. Discover the wallet's position NFTs. For each owned, positive-liquidity
+   position in the configured pool, read fresh on-chain pool state in
+   SyrupUSDC per EVE after discovery and any earlier withdrawals. Withdraw complete
    liquidity when its normalized **upper** boundary satisfies
    `U <= P * (1 - h/100)`. Equality qualifies. Both token orientations use
    exact squared Q64.64 comparisons, without display-price rounding. At
    `P=15, h=10`, `13–13.5` qualifies and `13.5–14` does not. Withdrawals retain
    the position and NFT, and return pool-token fees to the same wallet.
+   Each position uses its own fresh state for both eligibility and withdrawal
+   minimums; the price is not reused across positions.
 2. Read current SyrupUSDC balance and swap the full balance above its reserve
    into USDC through the confirmed exact-input Jupiter operation.
 3. Read current USDC balance and send the full balance above its reserve to
@@ -71,8 +74,8 @@ completion. Every iteration follows the same three independent steps:
    The transfer submits once and is awaited at `CONFIRMED`.
 
 Missing/zero balances and balances equal to their reserves are skipped. Amounts
-are rounded down to mint precision. An unusable positive market price skips
-withdrawals while retaining steps 2 and 3. EVE returned as principal/fees and
+are rounded down to mint precision. An unavailable or unusable pool price stops
+the remaining withdrawals in that iteration while retaining steps 2 and 3. EVE returned as principal/fees and
 other reward tokens remain in the wallet and never enter the conversion/payout
 pipeline. All available SyrupUSDC/USDC is eligible, including manual deposits.
 
@@ -98,14 +101,21 @@ Withdrawal and closure are separate actions in
 
 Raydium validates pool/personal-position discriminators, the owned NFT holding,
 current complete liquidity, mint precision, vaults and tick arrays before signing.
-Missing destination ATAs are created idempotently in the same transaction,
-which requests a 600,000 compute-unit limit.
+For every pool or reward mint, existing owner token accounts are reused after
+validating their mint, owner, token program and initialized state, including
+empty accounts and accounts outside the owner's ATA. Only when no owner holding
+exists does the withdrawal use or idempotently create its ATA. A failed holdings
+read aborts rather than creating an additional account. This preserves the
+existing wallet's single-account-per-mint balance/transfer contract. The
+transaction requests a 600,000 compute-unit limit.
 The bitmap extension and initialized reward triplets are included when required.
 The integer principal math matches Raydium's
 [tick algorithm](https://github.com/raydium-io/raydium-clmm/blob/master/programs/amm/src/libraries/tick_math.rs).
 Minimum principal amounts are floored after applying explicit withdrawal
 slippage. An amount too small to protect at least one raw unit is rejected.
 No withdrawal always substitutes zero for both minimums.
+Price movement after the per-position read remains possible before execution;
+principal minimums protect received amounts, not the harvest-distance threshold.
 
 The current EVE mint uses Token-2022 metadata pointer/token metadata extensions;
 SyrupUSDC uses legacy SPL. Read-only mainnet inspection on 2026-10-04 found the
@@ -122,7 +132,10 @@ The Gradle JUnit fixtures exercise exact threshold equality, inversion, raw
 principal amounts, owner/pool filtering, reserves, independent failures,
 restart recovery and shutdown. Captured serialized transactions verify account
 order, full liquidity, minimum output, NFT retention, bitmap/reward accounts and
-one submission/confirmation attempt. All financial dependencies are controlled;
+one submission/confirmation attempt. Review regression fixtures also cover price
+changes during discovery or earlier withdrawals in both token orientations,
+quote consistency, and reuse/validation of existing pool and reward token accounts
+under both token programs. All financial dependencies are controlled;
 no verification submits live withdrawals, swaps or transfers.
 
 ```sh