POST /orders/{id}/split — buyurtmani bo'lish (R17, F6)

finalize-ep-10 yangiladi

Yangilandi: commit_sha, pr_url

qa-ep-10-t06-s01 statusni o'zgartirdi Review → Bajarildi

qa-ep-10-t06-s01 izoh qoldirdi

QA 3-raund (yakuniy), commit 782def4 — O'TDI. D1 MEXANIZMI TO'G'RI. OrderService.java:1016-1018 — split() endi ayni biznes tranzaksiyasida orderOutboxRepository.enqueueIfAbsent(EVENT_ORDER_READY_TO_DELIVER, OUTBOX_OBJECT_TYPE_ORDER, newOrder.getId(), dedupKey, OUTBOX_EMPTY_PAYLOAD) yozadi. TransactionSynchronizationManager/afterCommit/NotificationPort maydoni va importlari BUTUNLAY yo'q (ko'z bilan tekshirildi: qolgan NotificationPort grep hitlari — 173/217/219/810/954/1163/1407 — faqat javadoc matni, o'lik kod emas). Naqsh cancel() (OrderService.java:1125-1127) bilan bir xil: dedup kaliti {event_type}:{object_type}:{object_id} (V34 QAT'IY formati), object_type='order'. OrderService dagi 9 ta enqueueIfAbsent chaqirig'ining hammasi shu naqshda. AR-3 / CROSS_CUTTING F.1 bajarildi. MIGRATSIYA/WORKER TEGILMAGAN (talab shu edi): git diff 917dd2a..782def4 -- src/main/resources/db src/main/java/uz/erpbom/orders/worker/ BO'SH. V34__order_outbox.sql:113 CHECK ro'yxatida 'order.ready_to_deliver' bor; OrderOutboxWorker.java:118 (service/ papkasida) uni default shoxobcha orqali NotificationPort ga yetkazadi. REGRESSIYA YO'Q — 2-raund topilmalari joyida: payment_term_days_snapshot=45 vs shartnoma payment_term_days=30 (test:110 vs :103, ataylab farqli); price_type_id real qiymat (test:357 insertPriceType, NULL emas); order_number 4 tekshiruvi saqlangan (test:155 split'dan OLDIN DB read-back, :189 ^ORD-\d{6,}$, :190 otanikidan farqli, :191-192 ota raqami o'zgarmagan DB read-back). TEST (bloklovchi, flock ostida, izolyatsiyalangan worktree): OrderSplitControllerTest tests=5 failures=0 errors=0; OrderCancelControllerTest tests=8 failures=0 errors=0 (S02 buzilmagan). MUTATSIYA 6/6 O'LDI (izolyatsiyalangan worktree /tmp/qa-EP-10-T06-S01-r3, javap bilan bytecode tasdiqlangan): - M-D1 enqueueIfAbsent olib tashlandi -> QIZARDI (expected 1, was 0); javap: split() bytecode'ida enqueueIfAbsent = 0 ta. - M-D1b event turi order.cancelled ga (dedup_key ready_to_deliver qoldirildi — event_type ni izolyatsiya qiluvchi kuchliroq shakl) -> QIZARDI (expected 1, was 0); javap: ldc_w String order.cancelled. Ya'ni test event turini HAQIQATAN tekshiradi, qator sanamaydi. - M-D2 setPaymentTermDaysSnapshot(30) qattiq qiymat -> QIZARDI (expected 45, was 30). - M-D3 Order.java dan @Generated olib tashlandi -> QIZARDI (order_number "null", ^ORD-\d{6,}$ ga mos emas); javap: hibernate/annotations/Generated = 0 ta. - R1 parent.setTotalAmount(...subtract(...)) olib tashlandi -> QIZARDI (expected 300000.00, was 620000.00). - R2 .filter(OrderLine::fullyReserved) olib tashlandi -> QIZARDI (2 ta test: expected 320000.00 was 620000.00; expected 409 CONFLICT was 201 CREATED). Mezonlar 3721/3722/3723 o'lchov bilan tasdiqlandi, is_met:true qoladi. TOZALIK: mutatsiya faqat worktree'da; worktree o'chirildi; asosiy daraxtda grep -rn MUTANT src/ bo'sh, *.orig yo'q, git status toza, git worktree list — faqat asosiy daraxt, HEAD 782def4.

coder-ep-10-t06-s01 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-10-t06-s01 yangiladi

Yangilandi: commit_sha

coder-ep-10-t06-s01 fayllarni qayd etdi

2 ta fayl qayd etildi

coder-ep-10-t06-s01 fayllarni qayd etdi

1 ta fayl qayd etildi

coder-ep-10-t06-s01 izoh qoldirdi

3-urinish — QA D1 topilmasi TASDIQLANDI va TUZATILDI (kod bilan mustaqil tekshirildi). Dalil: OrderReceiveReservationService da @Transactional UMUMAN yo'q (grep bo'sh), processReceived faqat OrderOutboxWorker.java:115 va OrderRecheckPort dan chaqiriladi -> allaqachon chidamli outbox qatori ortida, istisno AbstractOutboxWorker retry/failed ga tushadi. Demak u producer emas, worker yetkazish oyog'i va split() uchun namuna EMAS. V34__order_outbox.sql CHECK ro'yxatida order.ready_to_deliver BOR (113-qator), OrderOutboxWorker#process uni allaqachon NotificationPort ga yetkazadi -> worker/migratsiya o'zgarmadi. Tuzatish: OrderService.java:1015-1018 — afterCommit + NotificationPort#notify OLIB TASHLANDI, o'rniga ayni tranzaksiyada orderOutboxRepository.enqueueIfAbsent(EVENT_ORDER_READY_TO_DELIVER, "order", newOrder.getId(), dedupKey, {}) — cancel() naqshi bo'yicha, dedup kaliti order.ready_to_deliver:order:{new_order_id} (V34 qat'iy formati). Faqat shu uchun qo'shilgan notificationPort maydoni va TransactionSynchronization* importlari olib tashlandi (ishlatilmaydigan bog'liqlik qolmadi). Javadoc AR-3/CROSS_CUTTING F.1 ga moslandi va eski xato izoh sababi bilan qayd etildi. Test: OrderSplitControllerTest dagi events[] assertion order_outbox read-back ga ko'chirildi (count=1, event_type, object_type, object_id, dedup_key) + ota-buyurtmaga qator YOZILMASLIGI. In-memory RecordingNotificationPort test-double olib tashlandi. Natija (bloklovchi, flock ostida, asosiy daraxt): OrderSplitControllerTest 5/5, OrderCancelControllerTest 8/8 — BUILD SUCCESS, Tests run: 13, Failures: 0, Errors: 0. Mutatsiya tasdig'i: enqueueIfAbsent chaqirig'i olib tashlandi -> OrderSplitControllerTest.java:220 qizardi (expected: 1, but was: 0), keyin cp bilan tiklandi. grep -rn MUTANT src/ bo'sh, .orig fayl yo'q, git status faqat 2 ta kutilgan fayl. Mezonlar 3721/3722/3723 va ularni qoplaydigan fixture (payment_term_days_snapshot=45 vs shartnoma 30, real price_type_id, order_number read-back) TEGILMADI. S02/S03 kodiga, openapi/ va erp/docs ga tegilmadi. commit: 782def4

coder-ep-10-t06-s01 statusni o'zgartirdi Tayyor → Ishlanyapti

Agent ishni boshladi

coder-ep-10-t06-s01 ishga oldi

system statusni o'zgartirdi Ishlanyapti → Tayyor

Avtomatik bo'shatildi: 60 daqiqa signal yo'q

system bo'shatdi

Avtomatik bo'shatildi: 60 daqiqa signal yo'q

qa-ep-10-t06-s01 statusni o'zgartirdi Review → Ishlanyapti

qa-ep-10-t06-s01 izoh qoldirdi

QA 2-raund (qa-EP-10-T06-S01, commit 4bd9657, izolyatsiyalangan worktree). VERDIKT: QAYTARILDI (in_progress) — uchala mezon (3721/3722/3723) O'LCHOV bilan TASDIQLANDI va is_met=true qoldirildi, LEKIN D1 tuzatishi cross-cutting AR-3 buzilishini kiritdi. == D2/D3 — YOPILDI == Birinchi raundda TIRIK qolgan ikkala mutant endi O'LDI. M-D2 setPaymentTermDaysSnapshot(30) -> QIZARDI (expected: 45; javap: bipush 30 + Integer.valueOf split() ichida, offset 202). Fixture endi snapshot=45 != shartnoma=30. M-D2b setPriceTypeId(null) -> QIZARDI (expected: 1L; javap: aconst_null, offset 211). price_type_id endi NULL emas, real qiymat. M-D3 entity/Order.java dan @Generated olib tashlandi -> QIZARDI (actual "null" ^ORD-\d{6,}$ ga mos emas; javap -v: orderNumber maydonida faqat jakarta.persistence.Column qoldi, org.hibernate.annotations.Generated YO'Q). M-D3b yangi buyurtmaga ota raqami berildi -> QIZARDI (ORD-000001 != ORD-000001; javap: setOrderNumber chaqiruvi split() ichida). Regressiya: M-R1 parent.setTotalAmount(subtract) olib tashlandi -> QIZARDI (expected 300000.00, was 620000.00). M-R2 .filter(fullyReserved) olib tashlandi -> 2 test QIZARDI (320000 vs 620000; 409 o'rniga 201). Jami: 7 mutant, 7 o'ldi (0 tirik). Testlar (bloklovchi, flock ostida, /tmp/qa-EP-10-T06-S01-r2 worktree'ida): mvn -Dtest=OrderSplitControllerTest,OrderCancelControllerTest test -> Tests run: 13, Failures: 0, Errors: 0 (Split 5, Cancel 8). S02 buzilmagan. == D1 — TUZATILMAGAN, MEXANIZM NOTO'G'RI (qaytarish sababi) == QAMROV bor: M-D1 (notification chaqirig'i olib tashlandi) -> QIZARDI (OrderSplitControllerTest:254, events []; javap: registerSynchronization 0 marta, anon klass yo'q). Ya'ni test hodisani QO'RIQLAYDI. LEKIN mexanizm nomuvofiq. OrderService.java:1024-1031 (split) TransactionSynchronizationManager#afterCommit + NotificationPort#notify TO'G'RIDAN-TO'G'RI ishlatadi — bu butun kod bazasida biznes tranzaksiyasidan order.* hodisa chiqaradigan YAGONA joy, outbox'siz. Dalil (kod havolalari): 1) OrderService dagi qolgan 7 ta order.* producer'ining HAMMASI outbox: enqueueIfAbsent OrderService.java:691 (order.received), :856 (order.repriced), :1138 (order.cancelled — AYNI SHU COMMIT'da, split'dan 110 qator pastda), :1201 (order.picking_started), :1527 (order.delivering), :1728 (order.delivery_failed), :1923 (order.delivered). 2) Coder asos qilgan naqsh — OrderReceiveReservationService.java:222-225 — PRODUCER EMAS, WORKER'ning yetkazish oyog'i. Bu klassda @Transactional UMUMAN yo'q (grep: 0 ta), va processReceived FAQAT ikki joydan chaqiriladi: OrderOutboxWorker.java:115 (order.received outbox qatorini ishlayotgan worker ichidan) va OrderRecheckPortImpl:27 <- ProductionOutboxWorker (07 outbox'i). Ya'ni u yerdagi notify ALLAQACHON chidamli outbox qatorining ortida turadi: notify tashlansa AbstractOutboxWorker qatorni retry'ga (attempts+1, next_attempt_at), oxirida status='failed' ga o'tkazadi. split() dagi afterCommit'da bunday himoya YO'Q — JVM commit bilan afterCommit orasida o'lsa yoki notify tashlansa hodisa BUTUNLAY yo'qoladi (retry yo'q, failed qator yo'q, adminga qaytarish yo'q). 3) Spec: CROSS_CUTTING F.1 so'zma-so'z — 'outbox qatori biznes yozuv bilan birga COMMIT bo'ladi ... publish-after-commit qoidasi ENDI KERAK EMAS'. Coder aynan publish-after-commit'ni yozgan. AR-3 — 'Asinxron ish = outbox jadvali (biznes yozuv bilan bir tranzaksiya) + @Scheduled worker; retry/failed holati jadvalda'. F.10 (coder keltirgan band) WORKER qoidasi ('worker avval qatorni sent qilib COMMIT qilmaydi...') — outbox qatori BOR deb faraz qiladi, uni o'tkazib yuborishga ruxsat bermaydi. 4) Yo'l allaqachon to'liq ulangan: V34__order_outbox.sql CHECK ro'yxatida 'order.ready_to_deliver' BOR, va OrderOutboxWorker.java:118 order.received'dan boshqa HAMMA event_type'ni to'g'ridan-to'g'ri NotificationPort'ga uzatadi. Worker'ga o'zgarish KERAK EMAS. NIMA QILISH KERAK: a) OrderService.java:1024-1031 dagi TransactionSynchronizationManager bloki o'rniga (cancel bilan bir xil): String dedupKey = EVENT_ORDER_READY_TO_DELIVER + ":" + OUTBOX_OBJECT_TYPE_ORDER + ":" + newOrder.getId(); orderOutboxRepository.enqueueIfAbsent(EVENT_ORDER_READY_TO_DELIVER, OUTBOX_OBJECT_TYPE_ORDER, newOrder.getId(), dedupKey, OUTBOX_EMPTY_PAYLOAD); b) OrderService.java:359-365 dagi yangi notificationPort maydonini va TransactionSynchronization/TransactionSynchronizationManager importlarini olib tashlash. c) OrderSplitControllerTest: RecordingNotificationPort/@TestConfiguration o'rniga order_outbox qatorini DB'dan tekshirish — OrderCancelControllerTest.java:860-870 dagi AYNI naqsh (dedup_key = 'order.ready_to_deliver:order:<newOrderId>', status='pending'). Test M-D1 darajasida kuchli qolishi SHART. d) OrderService.java:174-179 va :945-967 javadoc'lari 'OrderReceiveReservationService bilan AYNAN bir xil naqsh' deb yozgan — bu FAKT jihatidan noto'g'ri (yuqoridagi 2-band), tuzatish bilan birga to'g'rilansin. Asosiy daraxt tozaligi: grep -rn MUTANT src/ -> bo'sh; *.orig -> bo'sh; git status --short -> toza; worktree /tmp/qa-EP-10-T06-S01-r2 o'chirildi; HEAD 4bd9657.

qa-ep-10-t06-s01 qabul mezonini belgiladi

✓ Ikkala buyurtma ham ASL `payment_term_days_snapshot` bilan yuradi (E11)

qa-ep-10-t06-s01 qabul mezonini belgiladi

✓ Yangi buyurtma O'Z `order_number` ini oladi, ota-buyurtmaniki o'zgarmaydi (R25)

qa-ep-10-t06-s01 qabul mezonini belgiladi

✓ Split dan keyin yangi buyurtma `ready_to_deliver`, ota `in_progress`; summalar yig'indisi asl summaga TENG (AC9)

coder-ep-10-t06-s01 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-10-t06-s01 yangiladi

Yangilandi: commit_sha

coder-ep-10-t06-s01 fayllarni qayd etdi

1 ta fayl qayd etildi

coder-ep-10-t06-s01 fayllarni qayd etdi

1 ta fayl qayd etildi

coder-ep-10-t06-s01 izoh qoldirdi

QA qaytarishi tuzatildi: D1 (order.ready_to_deliver notification split() da endi yoziladi, OrderReceiveReservationService naqshi AYNAN takrorlangan, TransactionSynchronizationManager#afterCommit bilan commit-dan keyin kafolatlangan), D2 (fixture payment_term_days_snapshot 45 vs shartnoma 30 ataylab farqli + price_type_id real qiymat, mutant sinovi bilan tasdiqlangan), D3 (order_number null/format/farqlilik + ota raqami o'zgarmaganligi DB read-back bilan, mutant sinovi bilan tasdiqlangan). Kuzatuvlar ham tuzatildi: test javadocidagi noto'g'ri stock.qty_reserved da'vosi va STOCK_BUSY erishilmasligi haqida qayd. Testlar: OrderSplitControllerTest 5/5 yashil. Mutatsiya tekshiruvi: payment_term_days_snapshot=30 qattiq qiymat va order_number=null (@Generated olib tashlash) mutantlari alohida-alohida testni qizartirdi, keyin tiklandi (git diff Order.java toza, OrderService.java/testda MUTANT izi yo'q). Commit 4bd9657.

coder-ep-10-t06-s01 qabul mezonini belgiladi

✓ Ikkala buyurtma ham ASL `payment_term_days_snapshot` bilan yuradi (E11)

coder-ep-10-t06-s01 qabul mezonini belgiladi

✓ Yangi buyurtma O'Z `order_number` ini oladi, ota-buyurtmaniki o'zgarmaydi (R25)

coder-ep-10-t06-s01 statusni o'zgartirdi Tayyor → Ishlanyapti

Agent ishni boshladi

coder-ep-10-t06-s01 ishga oldi

system statusni o'zgartirdi Ishlanyapti → Tayyor

Avtomatik bo'shatildi: 60 daqiqa signal yo'q

system bo'shatdi

Avtomatik bo'shatildi: 60 daqiqa signal yo'q

qa-ep-10-t06-s01 statusni o'zgartirdi Review → Ishlanyapti

qa-ep-10-t06-s01 izoh qoldirdi

QAYTARILDI (qa-EP-10-T06-S01). Baza: OrderSplitControllerTest 5/5 yashil (izolyatsiyalangan worktree, 3c611f2, real Postgres 16, Testcontainers). Mutatsiya tekshiruvi: 8 mutant, 6 KILLED, 2 SURVIVED (ikkalasi ham bytecode bilan tasdiqlangan). === MEZONLAR === [3721] OK. OrderService.java:944 newOrder.setStatus(STATUS_READY_TO_DELIVER), ota holati o'zgarmaydi; :957 parent.setTotalAmount(parent.getTotalAmount().subtract(movedAmount)); movedAmount = SUM(OrderLine.lineAmount()). Fixture xilma-xil (4x50000 + 3x40000 ko'chadi, 10x30000 qisman qoladi), kutilgan raqamlar qo'lda yozilgan: 320000/300000/620000. Mutantlar: "ota.total ayirilmaydi" KILLED; "yangi buyurtma in_progress" KILLED; ".filter(OrderLine::fullyReserved) olib tashlandi" KILLED (2 failure). [3722] QOPLANMAGAN. Kod TO'G'RI (Order.java:59-62 — order_number DB DEFAULT next_order_number(), insertable=false, @Generated(INSERT); split uni yozmaydi; parent uchun updatable=false), LEKIN test buni ISBOTLAMAYDI. OrderSplitControllerTest.java:156 faqat newOrderNumber != parentOrderNumber ni tekshiradi; yangi buyurtmaning raqami HAQIQIY ekani hech qayerda tekshirilmagan. MUTANT: Order.java:60 dan @Generated olib tashlandi -> yangi buyurtma javobda order_number = null -> 5/5 TEST YASHIL QOLDI (SURVIVED). Bytecode tasdig'i: Order.class dagi org/hibernate/annotations/Generated havolasi 1 -> 0. KERAK: yangi buyurtma uchun assert qo'shilsin — order_number null EMAS, DB read-back qiymatiga TENG, va AC17 formatiga mos: matches("ORD-\\d{6,}"). [3723] QOPLANMAGAN — FIXTURE BIR XILLIGI. Kod TO'G'RI (OrderService.java:940 parent.getPaymentTermDaysSnapshot() ko'chiriladi, qayta o'qilmaydi), LEKIN test uni farqlay olmaydi: OrderSplitControllerTest.java:300 da buyurtma snapshot'i 30 QOTIRILGAN va :290 da mijoz shartnomasi ham payment_term_days = 30 (insertActiveContract(customerId, 30, ...)). E11 ning butun mazmuni — "snapshot KO'CHIRILADI, kontraktdan QAYTA O'QILMAYDI" — bu fixture bilan sinalmaydi. MUTANT: newOrder.setPaymentTermDaysSnapshot(parent.getPaymentTermDaysSnapshot()) -> setPaymentTermDaysSnapshot(30), ya'ni kontraktdan qayta o'qishga AYNAN teng natija -> 5/5 TEST YASHIL QOLDI (SURVIVED). Bytecode diff tasdig'i: invokevirtual Order.getPaymentTermDaysSnapshot -> bipush 30. (Eslatma: payment_term = null mutanti KILLED — ya'ni test faqat "bo'sh emas"ni tekshiradi, "ASL qiymat"ni emas.) KERAK: fixture'da snapshot != kontrakt (mas. orders.payment_term_days_snapshot = 45, customer_contracts.payment_term_days = 30) va ikkala buyurtmada ham 45 kutilsin. XUDDI SHU muammo price_type_id da: :300 da NULL qotirilgan -> "price_type_id ko'chirilmadi" mutanti ham tirik qolardi; non-null, kontraktdan farqli qiymat berilsin. === DEFEKT (kod) === [D3] Split'dan chiqqan yangi buyurtma ready_to_deliver ga o'tganda order.ready_to_deliver notification YOZILMAYDI (OrderService.java:913-965 — outbox/notificationPort chaqiruvi yo'q). Bu BIR XIL holat o'tishining IKKI XIL ishlashi: rezerv yo'lida OrderReceiveReservationService.java:222-225 notificationPort.notify(EVENT_READY_TO_DELIVER, OBJECT_TYPE_ORDER, orderId, ...) chaqiriladi (OrderReservationApplyPoster.java:189-192 becameReady natijasi bo'yicha). Spec buni HOLAT bo'yicha talab qiladi, mexanizm bo'yicha emas: 06_orders.md §4.2 (415-qator) "Notification (10_notifications): order.ready_to_deliver — buyurtma yig'ishga tayyor bo'lganda admin/sotuv mas'uliga push" va §10 (967-qator) "06 chiqaradigan hodisalar" ro'yxatida order.ready_to_deliver (admin/sotuv — §4.2). Split'dan chiqqan buyurtma aynan §4.2 dagi ready_to_deliver ish navbatiga tushadi va admin uni ko'rishi kerak. Coder javadoci (OrderService.java:900-910) buni "ataylab qoldirilgan, spec bo'shlig'i emas" deb yozgan — bu noto'g'ri: spec §4.2/§10 talab qiladi. KUTILGAN: OrderReceiveReservationService dagi naqsh bilan bir xil hodisa yozilsin + testda tekshirilsin. === KO'RIB CHIQILDI — DEFEKT EMAS === 1) Rezervni order_lines.order_id ni YANGILASH bilan ko'chirish (stock ga tegilmaydi) — §4.3(d) invariant 2 ni BUZMAYDI. Invariant received/in_progress/ready_to_deliver/picking/picked buyurtmalar bo'yicha sanaydi; ota in_progress da qoladi, yangisi ready_to_deliver — IKKALASI ham ro'yxatda, qatorlarning qty_reserved QIYMATI o'zgarmaydi, faqat order_id o'zgaradi -> SUM o'zgarmaydi. To'g'ri muhandislik qarori. 2) source = internal_user, created_by_user_id = principal — SPEC BO'SHLIG'I EMAS: kontrakt orders.yaml 56-58 va 1916-1921 aniq yozgan — "server source ni token aud idan aniqlaydi (customer -> customer_app, aks holda internal_user, R1)". Split faqat ichki kanal (order.split rule, mijoz ilovasida yo'q) -> internal_user yagona to'g'ri qiymat. Ikkala ustun ham NOT NULL (V32__orders.sql:98,100). blocked SABABI EMAS. === KUZATUVLAR (bloklamaydi, lekin tuzatilsa yaxshi) === - OrderSplitControllerTest klass javadoci "stock.qty_reserved ga TEGILMAYDI (§4.3(d) invariant 2)" qamrovini DA'VO qiladi, lekin test hech qachon stock qatori yaratmaydi va o'qimaydi — da'vo asossiz. Yo javadocdan olib tashlansin, yo haqiqiy stock read-back asserti qo'shilsin. - Kontrakt OrderSplitConflict (orders.yaml ~1842) STOCK_BUSY kodini sanaydi, lekin implementatsiya stock ni umuman qulflamaydi -> bu kod hech qachon qaytarilmaydi. Xavfsiz yo'nalishdagi og'ish, lekin kontrakt bilan koddagi haqiqat farq qiladi. === CROSS-CUTTING / KONTRAKT === @Transactional OK (OrderService.java:912). tenant_id yo'q OK. Migratsiya o'zgarmagan OK. Fizik DELETE yo'q OK. Log'ga token/parol yozilmaydi OK. Kontrakt: 201 CREATED OK, parent_order/new_order snake_case OK, 409 INVALID_STATUS_TRANSITION va BUSINESS_CONFLICT kodlari kontraktga mos OK (test 8 ta noto'g'ri holat uchun ham tekshiradi), 403/404 OK. Qisqasi: bitta kod defekti (D3 notification) + ikkita testni kuchaytirish (3722 order_number haqiqiyligi, 3723 fixture snapshot != kontrakt). Mutatsiya asosiy daraxtda EMAS, /tmp dagi izolyatsiyalangan worktree da o'tkazildi va worktree o'chirildi; asosiy daraxtda MUTANT/.orig qolmagan.

qa-ep-10-t06-s01 qabul mezonini belgiladi

✗ Ikkala buyurtma ham ASL `payment_term_days_snapshot` bilan yuradi (E11)

qa-ep-10-t06-s01 qabul mezonini belgiladi

✗ Yangi buyurtma O'Z `order_number` ini oladi, ota-buyurtmaniki o'zgarmaydi (R25)

qa-ep-10-t06-s01 qabul mezonini belgiladi

✓ Split dan keyin yangi buyurtma `ready_to_deliver`, ota `in_progress`; summalar yig'indisi asl summaga TENG (AC9)

coder-ep-10-t06-s01 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-10-t06-s01 izoh qoldirdi

Split: to'liq rezerv qatorlar order_id o'zgartirish orqali yangi ready_to_deliver buyurtmaga ko'chadi (nusxa emas, satr ko'chishi — id/reserved_at saqlanadi). stock.qty_reserved'ga tegilmadi (invariant 2, ikkala status ham "band" ro'yxatida). Yangi buyurtma header/snapshot maydonlari (org/warehouse/customer/contract/payment_term/price_type) otadan ko'chirildi; source=internal_user, created_by_user_id=split qilgan admin (spec aniq belgilamagan NOT NULL ustun uchun muhandislik qarori). Ataylab qamrovdan tashqarida qoldirilgan: order.ready_to_deliver notification/outbox (spec_ref faqat §4.1/§4.3/§5 R17/§6 F6/§9 E11/R25 — §10 emas). Test: OrderSplitControllerTest, 5/5 yashil; fixture 3 qator (2 to'liq turli qty/narx + 1 qisman) F6 summasi va R17 filtri chin sinov ostida — mutatsiya bilan tasdiqlandi (filtr olib tashlanganda 2 test qizil chiqdi).

coder-ep-10-t06-s01 yangiladi

Yangilandi: branch, commit_sha

coder-ep-10-t06-s01 qabul mezonini belgiladi

✓ Ikkala buyurtma ham ASL `payment_term_days_snapshot` bilan yuradi (E11)

coder-ep-10-t06-s01 qabul mezonini belgiladi

✓ Yangi buyurtma O'Z `order_number` ini oladi, ota-buyurtmaniki o'zgarmaydi (R25)

coder-ep-10-t06-s01 qabul mezonini belgiladi

✓ Split dan keyin yangi buyurtma `ready_to_deliver`, ota `in_progress`; summalar yig'indisi asl summaga TENG (AC9)

coder-ep-10-t06-s01 fayllarni qayd etdi

4 ta fayl qayd etildi

coder-ep-10-t06-s01 statusni o'zgartirdi Backlog → Ishlanyapti

Agent ishni boshladi

coder-ep-10-t06-s01 ishga oldi

pm-agent yaratdi

POST /orders/{id}/split — buyurtmani bo'lish (R17, F6)