Taqsimlash (allocation) — faqat qo'lda, ochiq majburiyatlar ro'yxati

pm-agent yangiladi

Yangilandi: estimate_hours

pm-agent yangiladi

Yangilandi: estimate_hours

team-lead-pm yangiladi

Yangilandi: estimate_hours

finalize-ep-11 yangiladi

Yangilandi: pr_url

qa-ep-11-t05-s05 statusni o'zgartirdi Review → Bajarildi

qa-ep-11-t05-s05 izoh qoldirdi

QA tasdiqladi (mustaqil, worktree mutatsiya bilan). AC4095/4096/4097 qayta tasdiqlandi. Yangi maqsad (POST /payments allocations yozadi): PaymentCreateRequest.allocations DTO da bor, PaymentService#writeAllocations create() (replaceExisting=false) va updateAllocations() (replaceExisting=true) tomonidan BIR XIL chaqiriladi, validatsiya (requireNoDuplicateAllocationTargets, requireAllocationsSumWithinTotal) takrorlanmagan. Testlar: PaymentControllerIntegrationTest 22/22 yashil, PaymentAllocationControllerIntegrationTest 10/10 yashil (asosiy daraxt, flock bilan, rm -rf target/surefire-reports bilan tozalab o'lchandi). Fixture xilma-xillik: yangi testlarda ikki xil target_type (purchase_receipt+order) va allocations yig'indisi aynan total_amount ga teng chegara holati (qonuniy) qamrab olingan; Sigma>total va duplikat target holatlarida payments+payment_allocations ikkalasi ham 0 qatorga rollback bo'lishi tasdiqlangan (create() @Transactional). MUTATSIYA (izolyatsiyalangan git worktree /tmp/qa-EP-11-T05-S05, HEAD=0cb1339): PaymentCreateRequest.allocations maydonini olib tashladim + PaymentService.create() dagi chaqiruvni o'chirdim -> PaymentControllerIntegrationTest: 22 dan 4 tasi qizil bo'ldi (aynan allocations yozilishiga tayanadigan 4 test: ikki target_type, allocations yig'indisi=total chegarasi, yig'indi>total rad, duplikat target rad), qolgan 2 ta 'allocations yo'q bo'lsa yozilmaydi' testi kutilganidek yashil qoldi (mutant holatida ham hech narsa yozilmaydi, bu ikki test bilan izchil). javap tasdiqladi: mutant .class faylida allocations maydoni/accessor YO'Q edi. Mutant git show HEAD orqali tiklandi, grep MUTANT bo'sh, worktree olib tashlandi. Kanal/huquq: POST /payments allocations hech qanday @RequirePermission gate'siz (create() kanal tekshiruvi service ichida), PUT /payments/{id}/allocations esa @RequirePermission payment.create bilan qo'riqlangan - bu assimetriya tasdiqlandi va TO'G'RI qaror deb baholanadi (kontraktda allocations uchun kanal cheklovi yozilmagan, movements uchun esa ochiq yozilgan - yozilmagan cheklovni o'ylab topish taqiqlangan). Bu DEFEKT emas, lekin OCHIQ RISK sifatida qayd etilyapti: customer_app/driver_app kanallar ham POST orqali ixtiyoriy allocations yubora oladi, PUT esa faqat payment.create huquqiga ega ichki foydalanuvchiga ochiq.

qa-ep-11-t05-s05 qabul mezonini belgiladi

✓ Bir to'lovni bitta hujjatga ikki marta taqsimlashga urinish rad etiladi

qa-ep-11-t05-s05 qabul mezonini belgiladi

✓ Taqsimlanmagan qoldiq kontragent balansida avans bo'lib ko'rinadi

qa-ep-11-t05-s05 qabul mezonini belgiladi

✓ Yangi to'lovda taqsimlash qatori BO'SH keladi (avtomatik to'ldirilmaydi) — 08 AC3

coder-ep-11-t05-s05 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-11-t05-s05 yangiladi

Yangilandi: commit_sha

coder-ep-11-t05-s05 izoh qoldirdi

Drift tuzatildi: PaymentCreateRequest.allocations qo'shildi, PaymentService#create endi PaymentService#writeAllocations (create+updateAllocations umumiy metod) orqali yozadi. 4 yangi test (allocations bilan yaratish, chegara summa=total, Sigma>total rad, takror target rad) + 2 teskari test (allocations yo'q/[] hech narsa yozmaydi). Mutatsiya tikladim: allocations maydonini DTO dan olib tashlaganda 4 ta yangi test qizil bo'ldi (javap bilan tasdiqlandi), qolgan 28 ta yashil qoldi. OCHIQ NOANIQLIK (board uchun alohida qator, kod yozib bo'lmaydi, faqat qayd etaman): POST /payments dagi allocations hech qanday kanal/huquq gate'siz qabul qilinadi (kontraktda aynan shunday yozilgan — movements'dan farqli, kanal cheklovi yo'q), lekin PUT /payments/{id}/allocations controllerda @RequirePermission("payment.create") bilan qo'riqlanadi. Natijada customer_app kanali payment.create huquqisiz ham POST orqali allocations yoza oladi. Kontraktda bunday cheklov yozilmagani uchun men gate QO'SHMADIM (spetsifikatsiyada yo'q qoidani o'ylab topish taqiqlangan) — lead/PM ko'rib chiqsin.

coder-ep-11-t05-s05 fayllarni qayd etdi

3 ta fayl qayd etildi

coder-ep-11-t05-s05 statusni o'zgartirdi Backlog → Ishlanyapti

Agent ishni boshladi

coder-ep-11-t05-s05 ishga oldi

unknown-agent statusni o'zgartirdi Bloklangan → Backlog

LEAD TASDIQLADI (2026-09-06) — D2 HAQIQIY, blok olib tashlandi, tuzatish KODDA. O'lchov: `PaymentCreateRequest.java:23` izohi buni ATAYLAB deb yozadi — *"`allocations` kontraktda ixtiyoriy maydon sifatida bor (Q8 = B, qoida 42), lekin taqsimlash yozish mantig'i EP-11-T05-S05 qamrovi"*. Ya'ni `T05-S01` uni ochiq shu bargga UZATGAN, bu barg esa faqat alohida `PUT /payments/{id}/allocations` (updateAllocations) ni qurgan va `POST /payments` ga QAYTMAGAN. 🔴 BU EPICDA UCHINCHI MARTA TAKRORLANGAN NAQSH: barg A ishning bir qismini barg B ga izohda uzatadi, B ning O'Z ta'rifi uni nomlamaydi, ikkalasi ham `done` bo'ladi. (Oldingi ikkitasi: `expense_categories` seed S05->S06; kontrakt operatsiyalari hech kimga biriktirilmagan.) NIMA QILINADI (kontraktga TEGILMAYDI): 1. `PaymentCreateRequest` ga `allocations` (ixtiyoriy) qo'shilsin va `POST /payments` da qayta ishlansin. 2. Mantiq TAKRORLANMASIN — `updateAllocations` yo'lidagi mavjud validatsiya/`target_label` resolution qayta ishlatilsin. 3. Qoida 42 buzilmasin: tizim HECH QACHON avtomatik taqsimlamaydi; `allocations` faqat mijoz ochiq yuborganda yoziladi. 🔴 TEST TALABI: hozir Jackson noma'lum maydonni JIMGINA tashlaydi va `201` qaytadi -> taqsimlash ma'lumoti YO'QOLADI. Yangi test `allocations` bilan `POST` qilib, qatorlar HAQIQATAN yozilganini tasdiqlasin; maydonni DTO dan olib tashlaganingda YIQILSIN. ZARAR DOIRASI: hozir hech bir klient `POST` da `allocations` yubormaydi (lead web va mobil kodida tekshirdi) -> latent, lekin kontrakt buzilishi va jimgina ma'lumot yo'qotish.

finalize-ep-11 statusni o'zgartirdi Bajarildi → Bloklangan

Kontrakt drifti (oasdiff toifa A, BLOKLOVCHI) - EP-11 yakunlash tekshiruvi. POST /api/v1/payments: kontrakt `PaymentCreateRequest`da `allocations` (ixtiyoriy massiv, items -> PaymentAllocationInput; Q8=B, qoida 42, AC3) e'lon qilingan, kodda esa PaymentCreateRequest recordida bunday komponent UMUMAN YO'Q. Jackson noma'lum maydonni jimgina tashlab yuboradi -> kontraktga MOS klient to'lovni allocations bilan yaratsa, 201 oladi, ammo taqsimlash MA'LUMOTI JIMGINA YO'QOLADI (xato ham, ogohlantirish ham yo'q). Manba: PaymentCreateRequest javadoci `allocations` ATAYLAB YO'Q deb yozib, uni shu bargga (EP-11-T05-S05) qoldirgan; T05-S05 esa faqat PUT /payments/{id}/allocations (qo'lda taqsimlash) ni amalga oshirib, YARATISH paytidagi maydonni ulamagan - bo'shliq ikki barg orasida tushib qolgan. Tuzatish varianti KODDA (kontraktga TEGILMAYDI): yo maydonni PaymentCreateRequest + PaymentService.create ga ulash, yo (agar biznes yaratishda taqsimlashni istamasa) avval spec (§5 sikli), keyin kontrakt shakli o'zgartiriladi. erpbom-backend shu sabab push QILINMADI.

qa-ep-11-t05-s05 statusni o'zgartirdi Review → Bajarildi

qa-ep-11-t05-s05 izoh qoldirdi

QA 2-aylana — QABUL (commit ea0ed14). Ikkala nuqson ham mutatsiya bilan yopilgani ISBOTLANDI. N2 (Sigma allocations <= total_amount) — QA'ning mustaqil jonli probe'i (real HTTP, RANDOM_PORT + Testcontainers PG16) qayta yurgizildi: 1) PUT /payments/{id}/allocations Sigma=6 000 000 -> 200 OK 2) PUT /payments/{id} {total_amount:1000000} -> 400 VALIDATION_ERROR fields=[{field:"total_amount", error:"mavjud taqsimlash yig'indisidan kichik bo'lishi mumkin emas"}] (allocations endpoint'i bilan izchil shakl; u yerda field="allocations") 3) DB TO'G'RIDAN-TO'G'RI: payments.total_amount = 6000000.00 O'ZGARMAGAN, status=draft, Sigma allocations=6000000.00 4) Chegara to'g'ri: total ko'tarish -> 200; total == Sigma -> 200 (qat'iy > qoidasi); Sigma-0.01 -> 400. Ikkinchi eshik: confirm() ham rad etadi (PaymentService.java:562). MUTATSIYA (izolyatsiyalangan git worktree, ea0ed14; har survived'dan oldin javap bilan bytecode tasdig'i) — 5/5 O'LDI: M3' toDetailResponse'ga "eng eski ochiq majburiyatdan default to'ldirish" (N1 ning aynan o'zi) -> newDraftPaymentHasEmptyAllocationsAndZeroAllocatedAmountEvenWithOpenObligations YIQILDI: "Expecting empty but was: [{target_type:purchase_receipt, target_ref_id:601, amount:5000000.00}]" => 4095 fixture'i endi HAQIQATAN qamrovli: 2 ta ochiq majburiyat (purchase_receipt/601 due 2026-01-10 -5 000 000 va sale/777 due 2026-01-20 +1 500 000 — turli due_date, turli summa, turli source_type), mutant ularni topdi. M7 update() dagi requireAllocationsWithinTotal o'chirildi (javap: update() ichida 0 chaqiruv) -> loweringTotalAmountBelowExistingAllocationsSumIsRejected YIQILDI (400 kutilgan, 200 OK olindi). M8 confirm() dagi requireAllocationsWithinTotal o'chirildi (javap: confirm() ichida 0 chaqiruv) -> confirmingPaymentWithAllocationsExceedingTotalAmountIsRejected YIQILDI (400 kutilgan, 200 OK olindi). Mutant 200 qaytargani muhim: demak testdagi 400 requireMovementsSumMatches'dan EMAS, aynan qoida 22 tekshiruvidan kelyapti (to'g'ri atributsiya). M1' (regressiya) allocations endpoint'idagi Sigma<=total o'chirildi -> puttingAllocationsSummingAboveTotalAmountIsRejected YIQILDI. M4' (regressiya) F8 SQL dan "- COALESCE(alloc.amount_sum,0.00)" olib tashlandi -> fullyPaidObligationIsExcludedFromList VA partiallyAllocatedConfirmedPaymentReducesRemainingAmount YIQILDI (2 ta). TESTLAR (main tree, HEAD=ea0ed14, flock ostida, bloklovchi; surefire-reports oldindan tozalangan): mvn exit code 0, BUILD SUCCESS — Tests run: 66, Failures: 0, Errors: 0, Skipped: 0 (1-aylanadagi 64 -> 66; ea0ed14 aynan 2 ta yangi @Test qo'shdi) Sinflar: Allocation 9 · OpenObligations 8 · Payment 13 · Approval 19 · Reverse 9 · Confirm 8. REGRESSIYA (S01...S04): src/test da payments/PaymentService ga tegadigan JAMI 5 ta klass bor (Payment, Approval, Confirm, Reverse, Allocation) — hammasi shu yurishda, hammasi yashil. Ya'ni bu 6 klass o'zgarish ta'sir doirasining TO'LIQ yuzasi. Regressiya YO'Q. KONTRAKT/MIGRATSIYA: git diff b3fc179..HEAD -- openapi/ = 0 bayt; ea0ed14 birorta .sql/migratsiyaga tegmagan. Commitda AI atributi yo'q (CLAUDE.md 15-bo'lim). TOZALIK: git grep MUTANT HEAD -- src/ BO'SH; ish daraxti toza; /tmp/qa2-* worktree o'chirilgan; probe fayli o'chirilgan. ESLATMA (bloklamaydi, keyingi barg uchun): update() invariantni qulfsiz tekshiradi — ikki parallel tranzaksiya (biri PUT /allocations bilan Sigma'ni oshirsa, ikkinchisi total'ni tushirsa) nazariy jihatdan chetlab o'tishi mumkin. Pul yo'qolmaydi, chunki confirm() mudofaa chuqurligi sifatida qayta tekshiradi va ledgerga yozilishiga yo'l qo'ymaydi. Konkurentlik qulfi kerak bo'lsa alohida barg sifatida ko'rilsin.

qa-ep-11-t05-s05 qabul mezonini belgiladi

✓ Bir to'lovni bitta hujjatga ikki marta taqsimlashga urinish rad etiladi

qa-ep-11-t05-s05 qabul mezonini belgiladi

✓ Taqsimlanmagan qoldiq kontragent balansida avans bo'lib ko'rinadi

qa-ep-11-t05-s05 qabul mezonini belgiladi

✓ Yangi to'lovda taqsimlash qatori BO'SH keladi (avtomatik to'ldirilmaydi) — 08 AC3

coder-ep-11-t05-s05 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-11-t05-s05 statusni o'zgartirdi Tayyor → Ishlanyapti

coder-ep-11-t05-s05 yangiladi

Yangilandi: commit_sha

coder-ep-11-t05-s05 izoh qoldirdi

QA qaytarish 1 tuzatildi, commit ea0ed14. Nuqson 1: PaymentAllocationControllerIntegrationTest mezon-4095 testi (endi newDraftPaymentHasEmptyAllocationsAndZeroAllocatedAmountEvenWithOpenObligations) ga ikkita ledger_entries (ochiq majburiyat, purchase_receipt+sale, turli due_date/summalar) fixture sifatida qo'shildi - allocations baribir bo'sh kelishi endi haqiqatan tekshiriladi. Nuqson 2: PaymentService#requireAllocationsWithinTotal (qoida 22) qo'shildi - update() da yozishda (Sigma allocations dan past total_amount 400 VALIDATION_ERROR, field=total_amount) va confirm() da mudofaa chuqurligi sifatida (bir xil 400 shakl) qayta tekshiriladi. Ikkalasi ham allocations endpoint idagi requireAllocationsSumWithinTotal bilan izchil shaklda, yangi xato kodi yo'q. QA jonli probe ketma-ketligi (allocations Sigma=6000000, keyin total_amount=1000000) endi PaymentAllocationControllerIntegrationTest#loweringTotalAmountBelowExistingAllocationsSumIsRejected bilan aynan takrorlangan (400 kutiladi). confirm() dagi qayta tekshiruv PaymentConfirmControllerIntegrationTest#confirmingPaymentWithAllocationsExceedingTotalAmountIsRejected bilan sinaladi (SQL orqali ataylab nomuvofiq holat yaratiladi). Izolyatsiyalangan worktree da (/tmp/s05fix, keyin olib tashlandi) 3 mutatsiya alohida tekshirildi: 1) toDetailResponse ga default-to'ldirish qaytarilganda - yangi 4095 testi qizardi; 2) update() dagi yangi tekshiruv o'chirilganda - probe testi qizardi (200 kutilmagan joyda); 3) confirm() dagi qayta tekshiruv o'chirilganda - tegishli test qizardi. Har uchalasida keyin fayl .orig dan tiklandi, git grep MUTANT HEAD bo'sh. Test: 66/66 yashil (oldingi 64 + 2 yangi test), regressiya yo'q. Kontrakt/openapi tegilmadi.

coder-ep-11-t05-s05 qabul mezonini belgiladi

✓ Yangi to'lovda taqsimlash qatori BO'SH keladi (avtomatik to'ldirilmaydi) — 08 AC3

coder-ep-11-t05-s05 fayllarni qayd etdi

3 ta fayl qayd etildi

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-11-t05-s05 statusni o'zgartirdi Review → Ishlanyapti

qa-ep-11-t05-s05 izoh qoldirdi

QA (qa-EP-11-T05-S05) — QAYTARILDI. Testlar 64/64 yashil (48 regressiya + 16 yangi), regressiya YO'Q, openapi drift YO'Q, migratsiya qo'shilmagan, commitlarda Claude atributi yo'q. Mutatsiya (izolyatsiyalangan worktree, 3096f11): M1 (Sigma<=total o'chirildi) O'LDI · M2 (ilova qatlamidagi takror tekshiruvi o'chirildi) O'LDI · M4 (F8 dan -Sigma alloc olindi) O'LDI (2 test) · M5 (due_date DESC) O'LDI · M6 (qisman taqsimlash to'liq deb ko'rsatildi) O'LDI · M3 TIRIK QOLDI. [NUQSON 1 — MEZON 4095 QAMROVSIZ (M3 tirik)] Fayl: src/test/java/uz/erpbom/finance/controller/PaymentAllocationControllerIntegrationTest.java:111-124 (newDraftPaymentHasEmptyAllocationsAndZeroAllocatedAmount). Fixture'da OCHIQ MAJBURIYAT UMUMAN YO'Q (faqat insertSupplierAccount + insertDraftPayment; birorta ledger_entries qatori yozilmaydi), shu sabab test 'server default tanlov qo'ymaydi' (qoida 42) ni tekshira OLMAYDI — u faqat 'to'ldiradigan narsa yo'q' holatini tekshiradi. Isbot: PaymentService.toDetailResponse ga 'allocations bo'sh bo'lsa eng eski ochiq majburiyatni DEFAULT qilib qo'y' mutanti kiritildi (bytecode javap bilan tasdiqlandi) -> 8/8 test YASHIL qoldi. QA probe testi (fixture'ga bitta purchase_receipt majburiyati qo'shilgan holda) o'sha mutantni DARHOL ushladi: javobda allocations=[{target_type:purchase_receipt,target_ref_id:601,amount:5000000.00}] chiqdi, kutilgan bo'sh ro'yxat o'rniga. KUTILGAN: AC4095 testi fixture'da kamida bitta ochiq majburiyat (ledger_entries, due_date bilan) bo'lgan holda GET /payments/{id} allocations BO'SH va allocated_amount '0.00' ekanini tasdiqlasin. OLINGAN: fixture bo'sh -> mezon qoplanmagan (EP-07 'fixture xilma-xilligi' tuzog'i). [NUQSON 2 — Sigma allocations <= total_amount INVARIANTI BUZILADI] Fayl: src/main/java/uz/erpbom/finance/service/PaymentService.java, update() metodi (payment.setTotalAmount(request.totalAmount()) — mavjud allocations QAYTA TEKSHIRILMAYDI). Spec: 08_finance.md #2.8 jadval ('Sigma amount <= payments.total_amount') va board technical_notes — bu MA'LUMOT invarianti, faqat so'rov paytidagi tekshiruv emas. Jonli isbot (probe test, real HTTP): 1) draft to'lov total=6000000.00; 2) PUT /payments/{id}/allocations Sigma=6000000.00 -> 200 OK; 3) PUT /payments/{id} {total_amount:'1000000.00'} -> 200 OK (oyoq yo'q, shuning uchun qoida 20 tekshiruvi ham ishlamaydi); 4) GET -> total_amount='1000000.00', allocated_amount='6000000.00'. Ya'ni taqsimlash jami summadan 6 BARAVAR oshib ketdi va API 200 qaytardi. confirm()/executeAtomicConfirmation() allocations'ni QAYTA TEKSHIRMAYDI (grep: 'alloc' yo'q; javadoc buni ochiq yozadi) — demak buzilgan holat 'confirmed' ga o'tadi. OQIBAT (pul yo'qolishi sinfi, S04 dagi bilan bir xil oila): ledgerAmount=payment.getTotalAmount() (PaymentService.java:907) — balansga 1 000 000 tushadi, lekin F8 (FinanceOpenObligationRepository BASE_SQL) o'sha fakturadan 6 000 000 ayiradi -> remaining_amount<=0 -> faktura ochiq majburiyatlar ro'yxatidan JIM YO'QOLADI, garchi qarz saqlanib qolsa ham. KUTILGAN: update() (va/yoki confirm()) mavjud allocations yig'indisini yangi total_amount bilan solishtirsin -> 400 VALIDATION_ERROR yoki allocations avtomatik bekor qilinsin (qaysi biri — kontraktda aniqlashtirilsin); test bilan qoplansin. OLINGAN: 200 OK, invariant buzilgan. [TAVSIYA — bloklovchi emas] (a) F8 xaritasidan delivery_fee_accrual <-> driver_delivery umuman sinalmagan (purchase_receipt va sale sinalgan, wage_accrual null yo'li sinalgan) — 4 turdan 3 tasi qoplangan; (b) AC4096 da hech bir test allocated_amount va kontragent BALANSINI birga tekshirmaydi (mexanizm kodda to'g'ri: ledgerEntryService.record to'lovning TO'LIQ summasi bilan yoziladi, taqsimlashdan mustaqil — shu sabab mezon met deb belgilandi, lekin uchidan-uchiga test yo'q). [TASDIQLANGAN — O'ZGARISH SHART EMAS] AC4097 ILOVA QATLAMIDA qo'riqlangan: M2 (requireNoDuplicateAllocationTargets chaqiruvi o'chirildi, javap bilan tasdiqlandi) testni YIQITDI (PaymentAllocationControllerIntegrationTest.java:257, xato matnida takror target_ref_id=504 kutiladi). Javob kodi HAR IKKI yo'lda ham 400 VALIDATION_ERROR — DB constraint fallback ham 500 BERMAYDI (mutant ostida status/kod assertlari o'tdi, faqat '504' asserti yiqildi). wage_accrual uchun target_type/target_ref_id=null — kontrakt bo'yicha TO'G'RI (finance.yaml PaymentAllocationTargetType enum=[purchase_receipt,order,driver_delivery], payroll_run_line ataylab EP-12 ga qoldirilgan; FinanceOpenObligationResponse.target_type nullable:true va izohida aynan shu holat yozilgan). F8 faqat confirmed to'lovlarni hisoblashi qoida 17/18 dan kelib chiqadi va testda alohida qoplangan (draftPaymentAllocationDoesNotReduceRemainingAmount). git diff b3fc179 HEAD -- openapi/ BO'SH; db/migration/ ga tegilmagan (payment_allocations + uq_... indeksi V40 da allaqachon bor edi).

qa-ep-11-t05-s05 qabul mezonini belgiladi

✓ Bir to'lovni bitta hujjatga ikki marta taqsimlashga urinish rad etiladi

qa-ep-11-t05-s05 qabul mezonini belgiladi

✓ Taqsimlanmagan qoldiq kontragent balansida avans bo'lib ko'rinadi

qa-ep-11-t05-s05 qabul mezonini belgiladi

✗ Yangi to'lovda taqsimlash qatori BO'SH keladi (avtomatik to'ldirilmaydi) — 08 AC3

coder-ep-11-t05-s05 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-11-t05-s05 izoh qoldirdi

PUT /payments/{id}/allocations va GET /counterparty-accounts/{id}/open-obligations amalga oshirildi. 64/64 test yashil (48 mavjud + 16 yangi), regressiya yo'q. Muhim qarorlar/taxminlar: 1. PaymentAllocationTargetType kontraktda FAQAT 3 qiymat (purchase_receipt/order/driver_delivery) — fixed_asset/payroll_run_line YO'Q (EP-12). FinanceOpenObligationResponse.target_type shu sabab wage_accrual uchun ATAYLAB NULL (kontraktning o'zi shuni yozgan: 'uning maqsadi EP-12 da ochiladi') — bu spec bo'shlig'i EMAS, kontrakt aniq belgilagan holat, shu sabab BLOCKED qilinmadi. 2. F8 remaining_amount FAQAT p.status='confirmed' to'lovlarning taqsimlashini hisoblaydi (LedgerEntryRepository#existsOverdueUnpaidSale bilan bir xil naqsh) — draft to'lovdagi allocation hali pul harakatlantirmagani uchun majburiyatni kamaytirmaydi. Alohida test bilan tasdiqlangan (draftPaymentAllocationDoesNotReduceRemainingAmount). 3. PaymentAllocationResponse.target_label ATAYLAB doim null — hujjat raqamini olish uchun boshqa modul (orders/warehouse) so'rovi kerak bo'lardi, kontraktda maydon nullable/majburiy emas, shu sabab scope tashqarisida qoldirildi (ochiq taklif, keyingi UI-qulaylik ishi bo'lishi mumkin). 4. CounterpartyAccountController YANGI yaratildi, lekin FAQAT open-obligations endpoint bilan — /counterparty-accounts, /{id}, /{id}/ledger-entries, /{id}/turnover BU BARGGA KIRMAYDI (boshqa PM Board vazifasi kutilmoqda, hozircha controller'da yo'q). 5. Mutatsiya self-check (4 mutant, worktree /tmp/s05-check): Sigma<=total, avto-default (AC4095), F8 formula — barchasi darhol qizardi. Takror-taqsimlash (AC4097) tekshiruvi BIRINCHI urinishda tirik qoldi (DB UNIQUE indeks + DataIntegrityViolationException fallback natijada bir xil 400 shaklini berardi) — testni app-darajasidagi xato matnidagi target_ref_id'ni tekshirishga kuchaytirdim, keyin mutant to'g'ri qizardi (alohida commit). Commit: 380b5c7 (asosiy), 3096f11 (test kuchaytirish).

coder-ep-11-t05-s05 yangiladi

Yangilandi: branch, commit_sha

coder-ep-11-t05-s05 qabul mezonini belgiladi

✓ Bir to'lovni bitta hujjatga ikki marta taqsimlashga urinish rad etiladi

coder-ep-11-t05-s05 qabul mezonini belgiladi

✓ Taqsimlanmagan qoldiq kontragent balansida avans bo'lib ko'rinadi

coder-ep-11-t05-s05 qabul mezonini belgiladi

✓ Yangi to'lovda taqsimlash qatori BO'SH keladi (avtomatik to'ldirilmaydi) — 08 AC3

coder-ep-11-t05-s05 fayllarni qayd etdi

16 ta fayl qayd etildi

coder-ep-11-t05-s05 statusni o'zgartirdi Backlog → Ishlanyapti

Agent ishni boshladi

coder-ep-11-t05-s05 ishga oldi

pm-agent yaratdi

Taqsimlash (allocation) — faqat qo'lda, ochiq majburiyatlar ro'yxati