Buyurtma tahriri — faqat created/received (R20, §4.3c)

finalize-ep-10 yangiladi

Yangilandi: commit_sha, pr_url

qa-ep-10-t02-s03 statusni o'zgartirdi Review → Bajarildi

qa-ep-10-t02-s03 izoh qoldirdi

QA (izolyatsiyalangan worktree /tmp/qa-s03 @043877e) — QABUL QILINDI. TESTLAR: OrderUpdateControllerTest 15/15 yashil (tests=15 failures=0 errors=0), flock ostida, bloklovchi. MUTATSIYA (5 mutant, HAMMASI O'LDIRILDI, tirik qolgani YO'Q): 1) EDITABLE_STATUSES ga hamma holat qo'shildi (holat gate'i o'chdi) -> 2 test yiqildi (updatingOrderInInProgressStatusIsRejected, updatingOrderInPickingOrCancelledStatusIsRejected). javap: bytecode'da "picking" konstantasi tasdiqlandi. 2) stockReservationService.release() chaqiruvi o'tkazib yuborildi -> 2 test yiqildi (decreasingQtyBelowReservedReleasesExcessFromStock, removingLineReleasesFullReservationAndDeletesLine); decreasingQtyAboveExistingPartialReservationDoesNotTouchStock to'g'ri o'tdi. 3) ready_to_deliver->in_progress qaytish o'chirildi -> 2 test yiqildi (increasingQtyOnReadyToDeliverOrderRevertsToInProgress, addingNewLineToReadyToDeliverOrderRevertsToInProgress). 4) total_amount = Sigma(1) konstantaga aylandi -> 3/3 test yiqildi. 5) R16 snapshot buzildi (mavjud qator narxi qayta o'qildi) -> existingLinePriceStaysSnapshotButNewLineReadsFreshPrice yiqildi. FIXTURE XILMA-XILLIGI: TEKSHIRILDI, muammo yo'q. qty 1..15 oralig'ida turlicha, narx 700..500000 oralig'ida turlicha; rezerv holatlari uch xil qamralgan: to'liq rezerv (qty_reserved=qty=6), qisman rezerv (3/10), rezervsiz (0). Chegara holatlari: qator o'chirish (to'liq rezerv bo'shaydi), qator qo'shish, kamaytirish rezervdan PASTGA (bo'shatadi) va rezervdan YUQORIGA (stock tegilmaydi) — ikkalasi ham alohida test. ready_to_deliver DOIRASI — XULOSA: coder'ning kengaytmasi ASOSLI, qabul qilindi. Sabab: (a) mezon 3673 va 06_orders.md §9 E4 aynan ready_to_deliver -> in_progress qaytishni talab qiladi, bu o'tish faqat shu holatda tahrirga ruxsat berilsa yuzaga keladi; (b) mezon 3671 so'zma-so'z "in_progress va undan keyingi" holatlarni sanaydi, ready_to_deliver'ni ATAYLAB sanamaydi; (c) `created` da rezerv umuman yo'q (§4.3a — rezerv `received` dan boshlanadi), shu sabab 3672 ham rezerv mavjud holatni talab qiladi. Gate whitelist bo'lgani uchun (EDITABLE_STATUSES.contains) qolgan HAMMA holat (in_progress/picking/picked/delivering/delivered/cancelled) 409 INVALID_STATUS_TRANSITION oladi. SPEC/KONTRAKT QARZI (PM uchun, bu barg uchun blok EMAS): §4.3c intro, §7 `order.update` qatori va openapi updateOrder tavsifi + OrderUpdateConflict katalogi "faqat created/received" deydi — bu §9 E4 va mezon 3673 bilan ZID. E4 ning o'zi tahrir siyosatini "❓ Q8" ga havola qiladi, Q8 javobi esa faqat BEKOR QILISHni qamragan, tahrir doirasi hech qachon rasman javob olmagan. Doc va muzlatilgan kontrakt matni §5 sikli orqali moslashtirilishi kerak (kod ham, kontrakt ham men tomonimdan o'zgartirilmadi). CROSS-CUTTING: @Transactional — OrderUpdatePoster.update ✓, StockReservationService.release ✓, OrderService.update ataylab @Transactional EMAS (TransactionTemplate retry qobig'i, CROSS_CUTTING Q p.4/5 — to'g'ri naqsh). tenant_id/schema yo'q ✓ (AR-1). Precision: qty numeric(18,4), unit_price numeric(18,2) setScale(2,HALF_UP) ✓. Qulf: orders FOR UPDATE + stock FOR UPDATE, TreeMap bilan (warehouse_id, product_variant_id, condition) ASC tartibi, SET LOCAL lock_timeout=3s, 40P01/55P03 -> 2 retry -> 409 STOCK_BUSY (R26/AC19) ✓. Huquq: @RequirePermission("order.update"), huquqsiz user 403 testi bor ✓. Kontrakt: maydon nomlari/tiplar/xatolik kodlari (INVALID_STATUS_TRANSITION, ORDER_WAREHOUSE_TYPE_INVALID, VARIANT_ARCHIVED, SELLING_PRICE_MISSING, VALIDATION_ERROR) kontraktga mos ✓. Invariant §4.3d p.1 (qty_reserved <= qty) — oldReserved.min(newQty) klampi bilan ta'minlangan va testda tasdiqlangan (qty 6->4 da qty_reserved 6->4); p.2 (stock.qty_reserved = Sigma) — readStockQtyReserved bilan uch testda tekshirilgan ✓. KEYINGI ISHGA ESLATMA (bu barg uchun blok emas, qaytarilmaydi): 1) Mezon 3671 uchun testlar 6 holatdan 3 tasini qamragan (in_progress, picking, cancelled); picked/delivering/delivered testsiz. Gate whitelist bo'lgani uchun ular strukturaviy jihatdan baribir rad etiladi (mutant 1 gate'ning haqiqatan qo'riqlanganini isbotladi), lekin T02 yakunida shu 3 holat testga qo'shilsa yaxshi. 2) E4 ning ikkinchi yarmi — "oshgan qism 07 ga netting uchun ketadi (R13)" — bu bargda YO'Q: newShortage faqat holatni o'zgartiradi, outbox qatori yozilmaydi. Buyurtma in_progress da signalsiz turib qolmasligi uchun T04 (order.recheck/netting) da yopilishi shart. 3) order_lines qatori FIZIK o'chiriladi (orderLineRepository.deleteAll). Bu S03 nuqsoni emas — V32__orders.sql da order_lines da deleted_at ustuni yo'q va CROSS_CUTTING H soft-delete'ning hamma modulga tarqalishini OCHIQ savol deb qoldirgan. Final pass'da hal qilinsin. 4) reserved_at (§2.2 — qator to'liq rezerv bo'lgan payt) tahrirda yangilanmaydi: qty oshirilganda qator endi to'liq rezerv emas, lekin reserved_at eski qiymatda qoladi; kamaytirilganda qator to'liq rezervga aylansa reserved_at yozilmaydi. Mezonlardan tashqarida, lekin T04 rezerv oqimida hisobga olinsin. Worktree /tmp/qa-s03 o'chirildi; asosiy ish daraxtiga (/var/www/apps/erpbom-backend) tegilmadi, git commit/stash/reset/checkout ishlatilmadi.

qa-ep-10-t02-s03 qabul mezonini belgiladi

✓ Miqdor oshirilganda holat `ready_to_deliver` -> `in_progress` ga qaytadi (E4)

qa-ep-10-t02-s03 qabul mezonini belgiladi

✓ Miqdor kamaytirilganda ortiqcha rezerv bo'shaydi va `stock.qty_reserved` mos kamayadi

qa-ep-10-t02-s03 qabul mezonini belgiladi

✓ `in_progress` va undan keyingi holatlarda tahrir rad etiladi

coder-ep-10-t02-s03 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-10-t02-s03 yangiladi

Yangilandi: branch, commit_sha

coder-ep-10-t02-s03 izoh qoldirdi

Qaror (blocked emas, izoh uchun): §4.3c/kontrakt prozasi va order.update seed tavsifi "faqat created/received" deydi, lekin AC3671 sozma-soz FAQAT in_progress+ ni rad etadi (ready_to_deliver ni sanamaydi) va AC3673/E4 aynan ready_to_deliver dan MUVAFFAQIYATLI tahrirni (holat in_progress ga qaytishini) talab qiladi — bu ikkisi FAQAT bitta oqishda ziddiyatsiz: tahrirga ochiq holatlar = created, received, ready_to_deliver; yopiq = in_progress va undan keyingi (picking...cancelled). Barg korsatmasi ("3671/3673 ga tayan, qoshimcha siyosat oylab topma") shu ikkisini birga qollashni togridan-togri talab qilgani uchun bloklanmadi. Batafsil asoslash: OrderUpdatePoster.java klass javodoci. QA shu talqinni tekshirsin (agar biznes qaror boshqacha bolsa — erp/ sessiyasida hal qilinishi kerak, chunki bu kontrakt+doc prozasidagi haqiqiy nomuvofiqlik). Test qamrovi: 15 ta test (OrderUpdateControllerTest) — created/received/ready_to_deliver ijobiy, in_progress/picking/cancelled 409, qisman/toliq rezerv bosatish, qator ochirish, yangi qator narxi vs snapshot, R15/R8b qayta tekshiruv, dublikat variant, huquq, 404. STOCK_BUSY (qulf tortishuvi, 2 marta retry) uchun alohida concurrency test YOZILMADI — SetAssemblyService bilan aynan bir xil isbotlangan naqsh qayta ishlatildi, vaqt cheklovi sababli haqiqiy parallel-lock testi qoldirildi (bilingan bosh joy).

coder-ep-10-t02-s03 qabul mezonini belgiladi

✓ Miqdor oshirilganda holat `ready_to_deliver` -> `in_progress` ga qaytadi (E4)

coder-ep-10-t02-s03 qabul mezonini belgiladi

✓ Miqdor kamaytirilganda ortiqcha rezerv bo'shaydi va `stock.qty_reserved` mos kamayadi

coder-ep-10-t02-s03 qabul mezonini belgiladi

✓ `in_progress` va undan keyingi holatlarda tahrir rad etiladi

coder-ep-10-t02-s03 fayllarni qayd etdi

7 ta fayl qayd etildi

coder-ep-10-t02-s03 statusni o'zgartirdi Backlog → Ishlanyapti

Agent ishni boshladi

coder-ep-10-t02-s03 ishga oldi

pm-agent yaratdi

Buyurtma tahriri — faqat created/received (R20, §4.3c)