Claude VM
1c8d7ea59c
Found via a real 2-item batch (280067 + 327649) on 2026-06-05 that produced a wrong PDF (correctly caught as "De verificat" by the R4 safety net) and a failed download: 1. addToCartDetailed took items[items.length-1], but ePay returns the cart NEWEST-FIRST, so the just-added row is items[0]. On a 2+ item batch every add reported the OLDEST row's id → two rows collapsed onto one basketRowId → metadata saved to the wrong row → broken cart. Single-item orders were unaffected (one element). Reverted to items[0]. 2. findNewOrderId accepted any id != previousOrderId, so when our submit created nothing it adopted an unrelated OLDER order (yesterday's 10009605) and attached its 15 Feleacu PDFs to today's parcels. ePay order numbers are sequential, so a genuinely-new order must be numerically GREATER than the latest pre-submit order; otherwise fail (recoverable) instead of matching a stale order. Take the highest genuinely-new id. Removed the now-dead latest-id fallback. The R4 "review" flag did its job — the wrong PDF was flagged for verification, never shown as valid. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>